วิธีที่ดีที่สุดในการแก้ไขข้อบกพร่องในกระบวนการ Scrum? [ปิด]

ฉันได้ศึกษาและอ่านเกี่ยวกับ Scrum ในช่วงสองสามวันที่ผ่านมาและอ่านเกี่ยวกับ Sprint Planning และงานต่างๆ ปัญหาหนึ่งที่ผุดขึ้นมาในใจของฉันคือวิธีจัดการกับจุดบกพร่องใน Scrum Henrik Kniberg แสดงวิธีการจัดการกับปัญหานี้ในหนังสือScrum และ XP ที่ดีมากของเขาจาก Trenches :

1. เจ้าของผลิตภัณฑ์พิมพ์รายการ Jira ที่มีลำดับความสำคัญสูงที่สุดนำไปที่การประชุมวางแผนการวิ่งและวางไว้บนผนังพร้อมกับเรื่องราวอื่น ๆ (ดังนั้นการระบุลำดับความสำคัญของรายการเหล่านี้โดยปริยายเมื่อเทียบกับเรื่องราวอื่น ๆ )
2. เจ้าของสินค้าสร้างเรื่องราวที่อ้างอิงถึงรายการจิระ ตัวอย่างเช่น "แก้ไขข้อบกพร่องการรายงานส่วนหลังที่สำคัญที่สุด Jira-124, Jira- 126 และ Jira-180"
3. การแก้ไขข้อบกพร่องถือเป็นสิ่งที่อยู่นอกเหนือจากการวิ่งนั่นคือทีมรักษาปัจจัยโฟกัสที่ต่ำพอ (เช่น 50%) เพื่อให้แน่ใจว่าพวกเขามีเวลาแก้ไขจุดบกพร่อง จากนั้นสันนิษฐานง่ายๆว่าทีมงานจะใช้เวลาส่วนหนึ่งในแต่ละ sprint เพื่อแก้ไขข้อบกพร่องที่ Jira รายงาน
4. ใส่สินค้าค้างส่งใน Jira (เช่นทิ้ง Excel) ปฏิบัติกับจุดบกพร่องเช่นเดียวกับเรื่องราวอื่น ๆ

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

นี่เป็นคำถามที่ดีมากและฉันมีข้อสังเกตเกี่ยวกับวิธีการต่างๆในการแก้ปัญหานี้

1. การจัดการกับข้อบกพร่องทั้งหมดอย่างเท่าเทียมกันกับรายการที่ค้างอยู่อาจดูเหมือนเป็นแนวคิดที่ดีในทางทฤษฎี (ติดตามงานในที่เดียว) แต่ไม่ได้ผลดีในทางปฏิบัติ ข้อบกพร่องมักจะอยู่ในระดับต่ำและมีจำนวนมากกว่าดังนั้นหากคุณสร้างเรื่องราวของผู้ใช้แต่ละคนสำหรับข้อบกพร่องแต่ละข้อเรื่องราว "จริง" จะถูกบดบังในไม่ช้า
2. เวลาที่ชัดเจนในแต่ละ sprint ที่สงวนไว้สำหรับการแก้ไขนั้นใช้ได้หากทำในลักษณะที่เจ้าของผลิตภัณฑ์มองเห็นได้ ควรกล่าวถึงข้อบกพร่องในระหว่างการต่อสู้ประจำวันและการอภิปรายเกี่ยวกับข้อบกพร่องที่ได้รับการแก้ไขแล้วควรเกิดขึ้นในระหว่างการตรวจสอบการวิ่ง มิฉะนั้นเจ้าของผลิตภัณฑ์จะไม่ทราบว่าเกิดอะไรขึ้นในโครงการ
3. การใส่เครื่องมือติดตามข้อบกพร่องทั้งหมดในระบบนำไปสู่ชุดปัญหาเดียวกันกับข้อ 1 ยิ่งไปกว่านั้นตัวติดตามข้อผิดพลาดส่วนใหญ่ไม่ได้ออกแบบมาโดยคำนึงถึง Scrum และการใช้เพื่อจุดประสงค์นี้อาจทำให้เจ็บปวดได้

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

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

จริงๆแล้วฉันคิดว่าสิ่งที่ดีที่สุดคือคำตอบของjpeacockจากคำถามนี้คุณนับชั่วโมงที่ใช้ในการแก้ไขข้อบกพร่องต่อการต่อสู้หรือไม่?

ให้ฉันอ้างอิง:

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

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

สินค้าคงคลังเป็นของเสีย การติดตามข้อบกพร่องคือสินค้าคงคลัง การติดตามข้อบกพร่องนั้นสิ้นเปลือง

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

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

อย่าติดตามข้อบกพร่องในรายการค้นหาและแก้ไข - Mary Poppendieck

อันที่จริงหากสินค้าคงคลังสิ้นเปลืองแล้วสินค้าคงคลังที่มีข้อบกพร่อง ...

นั่นเป็นเหตุผลที่ฉันพยายามใช้ความคิดแบบStop-the-Lineด้วยการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและการบูรณาการอย่างต่อเนื่องเพื่อให้เราค้นหาและแก้ไขข้อบกพร่องส่วนใหญ่แทนที่จะวางไว้ในรายการทำซ้ำ

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

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

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

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

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

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

ทำไม?

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

คำถามที่ดีกว่าคือฉันจะหยุดสร้างจุดบกพร่องในขั้นตอนการพัฒนาได้อย่างไร ดู -> http://bit.ly/UoTa4n

หากคุณกำลังระบุและบันทึกข้อบกพร่องคุณจะต้องตรวจสอบและแก้ไขในอนาคต สิ่งนี้นำไปสู่ ​​"การป้องกันการสั่นไหวของ sprints" คือการวิ่งเพียงครั้งเดียวเพื่อแก้ไขข้อบกพร่อง หรือคุณสามารถเพิ่มกลับไปที่ Backlog และจัดลำดับความสำคัญให้เป็นส่วนหนึ่งของการวิ่งในอนาคต นอกจากนี้ยังหมายความว่าคุณจะจัดหาและคาดว่าจะได้รับการลงชื่อออกและเผยแพร่ซอฟต์แวร์ที่มีข้อบกพร่องที่เป็นที่รู้จัก (P3 & P4 aka cosmetic and minor)

นี่มันไม่คล่องตัวจริงเหรอ?

ฉันได้จัดทำแนวคิดในโครงการของเราเพื่อแนะนำการวิ่งแก้ไขข้อบกพร่องสั้น ๆ ทุก ๆ การวิ่งครั้งที่สาม การวิ่งปัจจุบันของเราคือสามสัปดาห์

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

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

มีใครลองใช้หรือมีข้อเสนอแนะเกี่ยวกับวิธีที่พวกเขาคิดว่าสิ่งนี้อาจได้ผล?

ไชโยเควิน