การแย่งชิง - วิธีการนำเรื่องราวของผู้ใช้ที่สมบูรณ์บางส่วนไปยัง Sprint ถัดไปโดยไม่บิดเบือนการค้าง

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

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

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

c) ไม่ต้องกังวลกับ a หรือ b และคาดเดาต่อไปในระหว่างการวางแผน Sprint ว่าสิ่งต่าง ๆ เช่น "เรื่องราวของผู้ใช้อาจเป็นจุดเรื่องราว X แต่ฉันรู้ว่ามันเสร็จ 95% ดังนั้นฉันแน่ใจว่าเราสามารถใส่ได้"

ในทีมปัจจุบันของฉันเราทำค)

ความเร็วควรคำนึงถึงสิ่งที่ทีมทำเสร็จจริง ๆ ในการวิ่ง สิ่งที่ไม่ได้จัดส่งนั้นไม่มีค่าสำหรับลูกค้าดังนั้นเราจึงไม่นับคะแนนใด ๆ ทั้งสิ้นหรือทั้งหมด

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

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

แน่นอนว่าทางเลือกอื่น (และความชอบของฉัน) ก็คือใช้คะแนนเรื่องราวดั้งเดิมที่ประเมินไว้ซึ่งเป็นสิ่งที่ฉันเคยทำในอดีต สิ่งนี้ทำให้สมมติฐานที่ว่าการประเมินของคุณดีและเป็นที่ยอมรับ แต่คุณดึงงานมากเกินไปสำหรับการวิ่ง (เช่น - เรื่องนี้มีค่า 3 คะแนน แต่ปัญหาอยู่ที่ว่าคุณดึงลงมา 15 คะแนนเมื่อ คุณควรดึงออกมา 13) มันอาจเป็นข้อสันนิษฐานที่อันตรายหากคุณไม่มั่นใจในความสามารถในการประเมินของคุณ แต่อาจทำงานได้ตามทีมและกระบวนการของคุณ

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

การคิดมากเกี่ยวกับสิ่งนี้ทำให้ดูเหมือนซับซ้อนเกินกว่าที่จะเป็น ... จริงๆแล้วมันค่อนข้างง่าย:

ตัวเลือก C

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

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

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

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

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

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

ฉันไม่คิดว่าตัวเลือก A ถึง C นั้นดีเพราะส่วนใหญ่ (สิ่งที่ฉันคิด) ควรสำคัญที่สุดเกี่ยวกับความเร็วของทีมคือความเร็วเฉลี่ยและไม่ว่าความเร็วของการวิ่งใดก็ตามจะขึ้นหรือลง

เมื่อมีการกำหนดเรื่องราวของผู้ใช้ควรมีเกณฑ์การยอมรับ หากสิ่งใดในเกณฑ์การยอมรับไม่ได้ทำทีมก็จะไม่ได้รับคะแนนใด ๆ ถ้าเรื่องนี้ทำเสร็จแล้ว (เช่นเขียนทดสอบและยอมรับโดย PO) ทีมจะได้รับคะแนนทั้งหมด

วิธีนี้ใช้งานได้ดีเมื่อทีมมุ่งความสนใจไปที่ความเร็วเฉลี่ยมากกว่าความเร็วในการวิ่งที่กำหนด

เช่นเดียวกับ M. Cohn ในหนังสือของเขาฉันมักจะชอบฉากที่ไม่มีอะไรเลย ท้ายที่สุดพยายามประเมินว่าคุณทำเสร็จ 5 คะแนนจากเรื่องราว 8 จุดหรืออาจแค่ 6 หรือ 7 ก็จะจบลงด้วยการเป็นเกมเดาอีกเกม ... และอย่าลืมว่าคุณได้เริ่มต้นแล้ว ประมาณวิธีออก มันอาจจะดีกว่าถ้าคุณใช้วิธีที่ง่ายที่สุดและเมื่อได้คะแนนทั้งหมดหลังจากที่ทำเสร็จ

Quoting M. Cohn จากหนังสือของเขา emphasis (ความสำคัญของฉัน):

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

Est การประมาณและการวางแผนแบบว่องไวการประมาณเรื่องราวที่เสร็จสมบูรณ์บางส่วนหน้า 66

ทีมของฉันเคยพยายามกำหนดคะแนนบางส่วนแม้ว่าจะมีการคัดค้านบ้าง แต่ฉันก็ไม่คิดว่ามันจะทำงานได้ดีเลย (เราไม่ทำมันอีกแล้ว ... ไปคิดเลข) นี่เป็นกรณีพิเศษเพราะเรื่องราวควรจะได้รับการประเมินว่าเป็นทีมแต่ถ้ามีเพียงคนเดียวเท่านั้นที่ทำงานกับมันมันจะยากกว่าสำหรับทีมที่จะ รู้ว่าแต่ละคนได้เสร็จสมบูรณ์จริง ๆ Agile ให้ความสนใจกับความเร็วเฉลี่ยของทีมมากกว่าที่จะดูว่า "ดี" ในการวิ่งเร็วแบบใด

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

การประมาณการแบบรวมไม่จำเป็นต้องเท่ากับการประมาณการแบบเดิม ...

²เหมือนกันหน้า 66

คำแนะนำที่ดีกว่าสำหรับทีมคือการแบ่งเรื่องราวให้มีขนาดเล็กพอที่จะหลีกเลี่ยงปัญหาแบบนี้ได้³:

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

itt เหมือนกันหน้า 66

หวังว่านี่จะช่วยได้

ฉันประหลาดใจที่ดูเหมือนจะไม่ได้คำตอบตรงนี้ ฉันคาดหวังว่าจะมีการประสานของ "ตัวเลือก D, ดัมมี่"

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

เราตัดสินใจว่าการเก็บบันทึกเรื่องราวของผู้ใช้ที่เรานำมาใช้นั้นถูกต้องเป็นสิ่งจำเป็นเนื่องจากรูปแบบเหล่านี้เป็นพื้นฐานสำหรับการทดสอบของเราเอกสารการสนับสนุนและบันทึกประจำรุ่น - ออกกฎที่ตัวเลือก B

ต่อไปเราคิดว่าการสามารถวางแผนการวิ่งได้อย่างแม่นยำนั้นเป็นสิ่งจำเป็น

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

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

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

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

คำถามแรกที่ถามคือ Story Point หมายถึงอะไร หากคุณกำหนดจุดเรื่องราวเป็น "วิศวกรรมทำงานได้มากแค่ไหน" คำตอบใด ๆ ก็จะทำ อย่างไรก็ตามหากคุณกำหนดจุดเรื่องราวว่า "มูลค่าเท่าไหร่ที่ส่งมอบให้กับธุรกิจ" ดังนั้นสิ่งสำคัญคือต้องไม่ให้เครดิตจนกว่าเรื่องราวจะเสร็จสมบูรณ์ 100% ยอมรับและส่งมอบ 100% การแก้ไขจุดเรื่องราวหลังจากการวิ่งตามสิ่งที่เสร็จสิ้นแล้วจะซ่อนปัญหาที่แท้จริงเท่านั้น: a) ไม่มีความเข้าใจที่ชัดเจนในเรื่องข) เรื่องราวนั้นถูกกำหนดอย่างหยาบเกินไป c) เรื่องราวนั้นขาดเกณฑ์การยอมรับที่วัดได้, d ) ไม่ลึกพอที่จะเข้าใจภารกิจหรือการพึ่งพาเพื่อทำให้เรื่องราวเสร็จสมบูรณ์ e) ความพยายามที่จะทดสอบเรื่องราว f) ลดลงมามากเกินไปหรือ g) ... แทรกเหตุผลของคุณที่นี่ ...

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