การแย่งชิง: วิธีจัดการกับงานในมือที่มีความยาวมากกว่าหนึ่ง Sprint

ฉันเริ่มต้นด้วย SCRUM และฉันมีปัญหาในการทำความเข้าใจสิ่งหนึ่ง SCRUM จัดการรายการในมือที่ใช้เวลานานกว่าการวิ่งหนึ่งครั้งได้อย่างไร

ไอเท็มเหล่านี้เรียกว่า Epic และจะต้องแบ่งออกเป็นเรื่องราวเล็ก ๆ ของผู้ใช้ซึ่งสั้นกว่าจากนั้นจะมีการวิ่งเพียงครั้งเดียวและเนื่องจากสามารถวางแผนได้หรือธีมที่จะแบ่งออกเป็น Epics และเรื่องราวทั่วไป Epics และ Themes มีคุณสมบัติหลัก - ระดับความไม่แน่นอนสูง = ไม่สามารถประเมินได้อย่างถูกต้อง (โดยปกติแล้วค่าประมาณจะสูงมากและเนื่องจากไม่เหมาะสมในการวิ่งครั้งเดียว)

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

นอกจากนี้ยังเป็นไปตามโครงสร้างภูเขาน้ำแข็งของสินค้าที่ค้าง

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

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

เมื่อการแย่งชิงกันเป็นครั้งแรก "ประดิษฐ์" ค่าเริ่มต้นการวิ่งเป็นปกติ 4 สัปดาห์

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

เมื่อทีมมีความมั่นใจมากขึ้นด้วยการทะเลาะกันพวกเขาเรียนรู้วิธีการแบ่งงานในมือให้น้อยลงเป็นรายการเล็ก ๆ ที่จัดการได้ง่ายขึ้นและทีมพัฒนาก็ดีขึ้นโดยไม่ต้องออกแบบหน้ามากเกินไป แต่ทำได้ดีพอ

วันนี้ฉันเชื่อว่าทีมส่วนใหญ่จะพิจารณา 4 สัปดาห์เพื่อให้ได้ระยะเวลาในการวิ่งที่ยาวมาก ฉันรู้สึกว่า 2 สัปดาห์นั้นค่อนข้างปกติ ทีม XP ทำซ้ำเพียง 1 สัปดาห์และจบเรื่องราวของผู้ใช้ในการทำซ้ำแต่ละครั้ง

ดังนั้นคุณจะต้องดีกว่าในการแบ่งรายการในมือ (Backlog) ออกเป็นรายการเล็ก ๆ ซึ่งแต่ละรายการจะมีมูลค่าทางธุรกิจเพิ่มขึ้นเล็กน้อยกับผลิตภัณฑ์ขั้นสุดท้าย เป็นไปได้ที่ได้รับการพิสูจน์แล้ว (แม้ว่าฉันจะไม่ออกกฎว่าอาจมีโดเมนพิเศษมากซึ่งมันจะยาก)

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

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

นี่คือโปสเตอร์ที่ยอดเยี่ยมที่ช่วยในการแยกเรื่องราวมาจากเว็บไซต์ที่เรียกว่า agileforall.com และคุณสามารถค้นหาโปสเตอร์ได้ที่นี่มีประโยชน์มากที่จะได้สิ่งนี้เมื่อคุณปรับแต่งรายการในมือ:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

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