มหากาพย์ตายแล้ว นี่คือสิ่งที่เราควรทำแทน

สิ่งที่ยังไม่ได้รับการประกาศว่าตายแล้ว? Test Driven Development ถูกฝังไว้เมื่อหลายปีก่อน กระนั้นก็ยังคงแพร่ระบาด แน่นอนว่า Agile ก็ตายเช่นกัน แต่แม้แต่ บริษัท ดั้งเดิมก็เข้ามาติดต่อกับ Scrum คนตายยังคงมีชีวิตอยู่ต่อไป แต่การประกาศว่ามีบางสิ่งบางอย่างที่ตายแล้วเป็นเรื่องที่ดีสำหรับพาดหัวข่าวที่รวดเร็ว ในแง่นั้นขอเป็นสักขีพยานว่าฉันทำลายมหากาพย์เป็นวิธีปฏิบัติที่คล่องตัวได้อย่างไร

มหากาพย์คืออะไร?

คำนี้คลุมเครือ สิ่งนี้มีข้อดี มหากาพย์มีไว้เพื่อการสื่อสารมากกว่าข้อกำหนด ความคลุมเครือทำให้ใช้งานได้หลากหลาย แต่มีความเสี่ยงที่จะเข้าใจผิด. ฉันยึดติดกับคำจำกัดความของ Mike Cohn:

มหากาพย์การต่อสู้เป็นเรื่องราวของผู้ใช้จำนวนมาก (ที่มา)

ฉันใช้คำแบบนี้: มหากาพย์เป็นเรื่องราวที่ใหญ่เกินกว่าจะนำไปใช้ใน Scrum sprint รายการที่อยู่ด้านบนของ Backlog ผลิตภัณฑ์จึงไม่ใช่มหากาพย์ แต่เป็นเรื่องราวเล็ก ๆ น้อย ๆ คุณมักจะพบกับมหากาพย์ เมื่อเวลาผ่านไปมหากาพย์จะถูก "หั่น" เป็นเรื่องราวที่สามารถดึงเข้าสู่การวิ่งได้

นั่นคือสิ่งที่ฉันสอนมาหลายปีในหลักสูตรการฝึกอบรมของฉัน ดูเหมือนว่าจะเป็นฉันทามติทั่วไป ใช้งานง่ายในตอนแรก ฉันมาที่นี่เพื่ออธิบายว่าเหตุใดจึงไม่สามารถใช้งานได้จริง

3 วิธีที่ทำไม่ได้ในการจัดการกับมหากาพย์

จนถึงตอนนี้ฉันเจอสามวิธีที่ บริษัท จัดการกับมหากาพย์ ไม่มีใครใช้งานได้จริง เรียกพวกเขาว่า:

การสลายตัว

ลิงค์

ต้นไม้

1. การสลายตัว

หลักการของการละลายนั้นง่ายมาก มหากาพย์ถูกแบ่งย่อยออกเป็นส่วน ๆ โดยสิ้นเชิงเรื่องราวเล็ก ๆ น้อย ๆ

ตัวอย่างเช่นมหากาพย์ "จองเที่ยวบิน" ของพอร์ทัลเที่ยวบินออนไลน์สามารถแบ่งออกเป็นขั้นตอนของกระบวนการแต่ละขั้นตอน ดังนั้น "เข้าสู่ระบบ" "ค้นหาเที่ยวบิน" และอื่น ๆ ทุกขั้นตอนกระบวนการกลายเป็นเรื่องราว ทีมงานประมาณเรื่องราว ตราบใดที่มันใหญ่เกินไปทีมก็ยังคงเชือดมัน เมื่อเรื่องราวทั้งหมดมีขนาดเล็กพอที่จะใส่ลงในการวิ่งได้แล้วทีมงานจะลบมหากาพย์และเริ่มพัฒนาเรื่องราว

มันเป็นแนวคิดพื้นฐานของความสมบูรณ์ที่รบกวนจิตใจฉัน การเลิกกิจการแสดงให้เห็นว่าหัวข้อสามารถดำเนินการให้เสร็จสมบูรณ์ได้ด้วยขอบเขตที่กำหนดไว้ล่วงหน้า

แต่หากสามารถเปลี่ยนแปลงเรื่องราวได้ในระหว่างการพัฒนาคุณจะไม่สามารถกำหนดเรื่องราวทั้งหมดล่วงหน้าได้

คู่มือ Scrum กล่าวว่า:

สินค้าค้างส่งไม่เสร็จสมบูรณ์ […] ความต้องการไม่เคยหยุดเปลี่ยนแปลง

หากคุณต้องส่งขอบเขตคงที่ให้หยุดเสแสร้ง ลืมเรื่องมหากาพย์และอธิบายข้อกำหนดโดยละเอียดล่วงหน้า แค่อย่าอ้างว่าคล่องตัวแล้ว

2. ลิงค์

หากคุณไม่ได้ทำให้มหากาพย์ของคุณหายไปอย่างสมบูรณ์คุณควรใช้ลิงก์ มหากาพย์ยังคงอยู่ในค้าง คุณเชื่อมโยงเรื่องราวเล็ก ๆ น้อย ๆ ใหม่เข้ากับมหากาพย์ที่พวกเขาได้รับมา

ความเสี่ยงคือเมื่อเวลาผ่านไปปริมาณของมหากาพย์เพิ่มขึ้น งานค้างจะป่อง มันมีมหากาพย์ที่คุณไม่ต้องการอีกต่อไป ผู้มีส่วนได้ส่วนเสียไม่ได้อยู่ใน บริษัท อีกต่อไป หรือหัวข้อไม่เกี่ยวข้องอีกต่อไป.

แน่นอนคุณสามารถล้างสิ่งที่ค้างส่งออกเป็นครั้งคราวได้ ฉันถือว่าสิ่งนี้ไม่ใช่งานเพิ่มมูลค่า และคุณสามารถหลีกเลี่ยงได้ดังที่ฉันจะอธิบายในภายหลัง

3. ต้นไม้

อีกวิธีหนึ่งคือการพรรณนามหากาพย์และเรื่องราวเป็นต้นไม้:

คุณจัดกลุ่มเรื่องราวเล็ก ๆ น้อย ๆ ตามมหากาพย์ ไม่ใช่ความคิดที่ไม่ดี แต่สิ่งที่คุณเสียคือรายการสั่งซื้อของค้าง แล้วคุณจะกำหนดลำดับการนำไปใช้งานได้อย่างไร?

แน่นอนคุณสามารถใช้เครื่องมือดิจิทัลที่รองรับทั้งสองมุมมอง ความเสี่ยง: คุณใช้เวลาและความพยายามมากเกินไปในเครื่องมือ มีมุมมองอย่างไร? คุณลักษณะคืออะไร? โมเดลข้อมูลพื้นฐานคืออะไร? คำถามที่น่าสนใจ แต่ในแนวทางที่คล่องตัวพวกเขาไม่ควรมีลำดับความสำคัญสูง

โดยสรุปความคิดในการรวมกลุ่มเป็นสิ่งที่ดี แต่การทำมันใช้เวลานาน

ทางเลือกสำหรับมหากาพย์

มีทางเลือกมานานแล้ว มีการกล่าวถึงในบล็อกโพสต์เดียวกันโดย Mike Cohn ซึ่งฉันเชื่อมโยงไว้ข้างต้น

ฉันกำลังพูดคุยเกี่ยวกับรูปแบบ

ธีมสามารถคิดเป็นคุณลักษณะเพิ่มเติมของเรื่องราวได้ โดยปกติหลายเรื่องจะใช้ธีมเดียวกัน เรื่องราว "ค้นหาเที่ยวบิน" อาจมีธีม "จองเที่ยวบิน" ตัวอย่างข้อมูลจากงานในมืออาจมีลักษณะดังนี้:

ธีมไม่ได้รับการจัดการเป็นองค์ประกอบค้างแยกต่างหาก ซึ่งจะช่วยกำจัดงานล้างข้อมูลที่กล่าวถึงในบทลิงค์ ดีแล้ว.

แต่สิ่งที่คุณเสียไปคือขั้นตอนการปรับแต่งทีละน้อยจากมหากาพย์เรื่องใหญ่ไปจนถึงเรื่องราวที่สามารถนำไปใช้ในการวิ่ง เลวร้าย.

โชคดีที่มีแนวทางปฏิบัติที่ทำให้สามารถปรับแต่งนี้ได้นอกเหนือจากงานค้าง วิธีหนึ่งในการระบุธีมคือแผนภาพกรณีการใช้งาน:

สิ่งที่ดีเกี่ยวกับแผนภาพดังกล่าวคือแสดง "ภาพใหญ่" เนื่องจากมีนามธรรมอยู่ในระดับสูงและการแสดงภาพกราฟิก ด้วยเหตุนี้งานในมือจึงไม่เหมาะสม

ชื่อกรณีการใช้งานจะกลายเป็นธีมในรายการค้างในภายหลัง แต่คุณจะได้รับจากกรณีการใช้งานไปยังเรื่องราวอย่างไร? สำหรับสิ่งนี้การทำแผนที่เรื่องราวของ Jeff Patton นั้นเหมาะสม:

สองบรรทัดบนสุดของแผนที่ตัวอย่างจะแสดงกรณีการใช้งาน "จองเที่ยวบิน" และ "จัดการโปรไฟล์" และขั้นตอนพื้นฐาน ภายใต้แต่ละขั้นตอนทีมจะแขวนทางเลือกอื่น: กระบวนการอื่น ๆ ข้อผิดพลาดและอื่น ๆ บันทึกย่อสีเหลืองเหล่านี้เรียกว่างานของผู้ใช้

ในการปรับแต่ง Backlog ทีมจะได้รับเรื่องราวจากงานของผู้ใช้ งานสามารถใช้เป็นชื่อเรื่องได้ ทีมงานเพิ่มรายละเอียดเช่นเกณฑ์การยอมรับให้กับเรื่องราว

ผลที่ตามมา

การใช้แนวทางทางเลือกนี้มีผลตามมา ตัวอย่างเช่น Backlog ของผลิตภัณฑ์จะมีเฉพาะเรื่องราวสำหรับการวิ่ง 1-2 ครั้งถัดไป อาจจะประมาณ 10-20 เรื่อง

กิจกรรมทั้งหมดเช่นการจัดลำดับความสำคัญเพิ่มเติมการประมาณและการกำหนดเกณฑ์การยอมรับอย่างละเอียดจะเกิดขึ้นกับเรื่องราวเหล่านี้เท่านั้น ดังที่หลักการ Agile ข้อที่ 10 กล่าวไว้ว่า:

ความเรียบง่าย - ศิลปะในการเพิ่มจำนวนงานที่ไม่ได้ทำ - เป็นสิ่งสำคัญ

หากฝ่ายบริหารต้องการข้อมูลเชิงลึกเกี่ยวกับความก้าวหน้าของการพัฒนาสิ่งนี้สามารถทำได้ในสามระดับ:

  • ใช้แผนภาพกรณีหรือธีมให้มุมมองระยะยาวสำหรับการจัดการ เป็นเวลา 1 ปีหรือมากกว่านั้น แต่ไม่เหมาะสำหรับการระบุรายละเอียด
  • แผนที่เรื่องราวเป็นพื้นฐานสำหรับการวางแผนการเผยแพร่ ผู้มีส่วนได้ส่วนเสียที่สนใจในการเผยแพร่สร้างแผนที่เรื่องราวกับสมาชิกในทีม (เนื่องจากการค้นพบใหม่ขอบเขตอาจเปลี่ยนแปลงระหว่างการพัฒนา)
  • บรรดาผู้ที่ต้องการที่จะมีข้อมูลเชิงลึกลึกและมีอิทธิพลต่อรายละเอียดในระหว่างการพัฒนามีส่วนร่วมในSprint รีวิวและBacklog การปรับแต่ง

เราเห็นรายละเอียดที่ระดับความสูงต่ำเท่านั้น และ Backlog ของผลิตภัณฑ์ก็เหมือนกับรายการช้อปปิ้ง คุณจะเขียนสิ่งที่คุณต้องการซื้อในหนึ่งปีหรือไม่?

ประการสุดท้าย แต่ไม่ท้ายสุดการเสียชีวิตของมหากาพย์เป็นการประกาศถึงการตายของลัทธิบริโภคนิยม ถ้าคุณต้องการอะไรคุณต้องตกลงกับทีมและทำงานร่วมกันอย่างใกล้ชิด

ชันสูตร

ในการสนทนากับเพื่อนร่วมงานพวกเขาชี้ให้เห็นว่าแม้หลังจากการสลายหายไปของมหากาพย์ แต่ก็สามารถเพิ่มเรื่องราวเล็ก ๆ ได้ ถูกต้องและสำหรับฉันแล้วมันเป็นทางออกที่ยอมรับได้ อย่างไรก็ตามสิ่งที่หายไปในกรณีนี้คือ“ ภาพใหญ่” ที่ฉันแสดงไว้ในแผนภาพกรณีการใช้งาน

ในที่สุดความเหมาะสมของผลิตภัณฑ์สำหรับผู้ใช้จะเป็นตัวกำหนดความสำเร็จของผลิตภัณฑ์ ไม่ใช่วิธีการสร้าง สิ่งนี้ใช้กับแนวทางการพัฒนาทั้งหมดรวมถึงมหากาพย์

บางทีคุณอาจคิดวิธีที่สมเหตุสมผลในการจัดการกับมหากาพย์?

เรียนรู้วิธีจัดการ Backlog ผลิตภัณฑ์ของคุณอย่างมีประสิทธิภาพโดยไปที่หลักสูตรออนไลน์ของฉัน บทความนี้เผยแพร่ครั้งแรกใน HOOD Blog ในภาษาเยอรมัน