สับสนเกี่ยวกับการแก้ไขงานค้างในระหว่างการวิ่ง


14

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

อย่างไรก็ตามฉันอ่านScrum และ XP จาก Trenchesและอธิบายส่วนของรายการที่ไม่ได้วางแผนไว้บน taskboard ดังนั้นฉันจึงค้นหาScrum Guideและมันบอกว่าในระหว่างการวิ่ง "ไม่มีการเปลี่ยนแปลงใด ๆ ที่จะส่งผลกระทบต่อเป้าหมาย Sprint" และในการอภิปรายของเป้าหมาย Sprint "หากงานนั้นแตกต่างจากที่คาดการณ์ไว้ทีมพัฒนา จากนั้นพวกเขาก็ร่วมมือกับเจ้าของผลิตภัณฑ์เพื่อเจรจาขอบเขตของ Sprint Backlog ภายใน Sprint " มันจะพูดในการสนทนาของ Sprint Backlog:

Sprint Backlog เป็นแผนที่มีรายละเอียดเพียงพอที่สามารถเข้าใจการเปลี่ยนแปลงในความคืบหน้าใน Daily Scrum ทีมพัฒนาปรับเปลี่ยน Sprint Backlog ตลอด Sprint และ Sprint Backlog ปรากฏในระหว่าง Sprint การเกิดขึ้นนี้เกิดขึ้นเมื่อทีมพัฒนาทำงานผ่านแผนและเรียนรู้เพิ่มเติมเกี่ยวกับงานที่จำเป็นเพื่อให้บรรลุเป้าหมาย Sprint

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

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

อย่างไรก็ตามมีผู้คนจำนวนมากที่ดูเหมือนจะยืนกรานว่าการเปลี่ยนแปลงใด ๆ ที่ค้าง backstarter จะไม่ตกลง ฉันเข้าใจตำแหน่งนั้นผิดหรือเปล่า? คนเหล่านั้นกำหนด backlog ที่วิ่งแตกต่างกันอย่างใด? ความเข้าใจของฉันเกี่ยวกับสิ่งที่ต้องทำในการวิ่งคือมันประกอบด้วยทั้งเรื่องราวและภารกิจที่พวกเขาแบ่งย่อยออกเป็น

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

คำตอบ:


10

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

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

แต่ถ้างานมีความสำคัญสำหรับงานใดงานหนึ่งในการวิ่งนี้คุณมีสองทางเลือก

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

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

จากนั้นในการวางแผนการประชุมครั้งต่อไปงานใหม่จะได้รับการวิเคราะห์และเพิ่มอย่างเหมาะสมในการวิ่ง (ตามความเหมาะสม)

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


คุณจะทำอย่างไรถ้ามีเพียงความเข้าใจผิดเช่นทีมคิดว่าสิ่งของมีความหมายอย่างหนึ่งในขณะที่เจ้าของผลิตภัณฑ์มีความหมายอย่างอื่นสมมติว่ารายการมีขนาดใกล้เคียงกัน เรื่องนี้เคยเกิดขึ้นจริงในที่ทำงานของฉันมาก่อนดังนั้นจึงไม่ใช่คำถามเชิงทฤษฎี ...
Maltiriel

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

10

ความสับสนเกิดจากภาษาที่คลุมเครือ

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

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

ดังนั้นจึงเป็นทั้งรายการของรายการคงค้างสินค้าและแผน (งาน) เพื่อส่งมอบ

ตอนนี้หลายทีมต้องการเพิ่มงานที่เสนอทั้งหมด (แผน) ที่จุดเริ่มต้นของ Sprint เพื่อให้พวกเขาสามารถติดตามแผนภูมิการเผาไหม้ตามชั่วโมงที่เหลือที่ต้องทำ ทีมอื่น ๆ ให้งานออกมาตามที่ต้องการ นี่คือเมื่อเพิ่ม OK ลงใน 'Sprint Backlog' เนื่องจากทีมต้องทำเช่นนั้นเพื่อตรวจสอบและปรับเปลี่ยนเพื่อส่งมอบรายการและบรรลุเป้าหมาย Sprint

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

ดังนั้นที่นั่นเรามีมัน; ใช่ ... ทีมเพิ่ม Tasks เข้าในแผน Sprint Backlog ตามต้องการ ไม่พวกเขามักจะไม่เพิ่มลงในรายการ Backlog Items ที่กำหนดขอบเขตของ Sprint

ฉันหวังว่านี่จะทำให้สถานการณ์ชัดเจนขึ้น


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

2

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

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


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

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

0

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

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

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

แนวคิด: ให้การจัดการ 3 สวิตช์เครดิตเพื่อใช้ในแต่ละไตรมาสเพื่อประนีประนอม


"ฉันเห็นด้วยกับคำตอบฉันจะชี้ให้เห็นว่าถ้าเรื่องราวได้เริ่มพัฒนาแล้วมันจะไม่หยุดจนกว่าจะเสร็จสิ้น" - ที่ไม่เป็นความจริง. ทีมสามารถตัดสินใจไม่ทำไอเท็มเรื่องราวให้เสร็จ เมื่อการวางแผนการวิ่งสำหรับการวิ่งครั้งต่อไปเริ่มต้นขึ้นแล้วไม่มีอะไรที่ต้องการให้พวกเขาดึงเรื่องราวนั้นไปสู่การวิ่งครั้งต่อไป ฉันชอบข้อความนี้มาก: "คุณภาพมาจากการโฟกัสและข้อบกพร่องมาจากการลดความคิดลง"
Bryan Oakley
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.