รายการ Sprint จะใช้เวลานานกว่าที่คาดว่าจะแล้วเสร็จ เราควรทำอย่างไร

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

ในสถานการณ์เช่นนี้เราควร

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

ในอนาคตเราจะหลีกเลี่ยงสถานการณ์เช่นนี้ได้อย่างไร? เป็นเพราะการขาดการวางแผนล่วงหน้าหรือเราไม่ได้พยายามแบ่งรายการ sprint ออกเป็นรายการเล็ก ๆ ?

ด้วย "รายการ" ฉันคิดว่าคุณหมายถึง "งาน"

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

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

เราควรทำอย่างไรถ้ารายการในการต่อสู้ใช้เวลานานกว่าที่คาดไว้?

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

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

ในอนาคตเราจะหลีกเลี่ยงสถานการณ์เช่นนี้ได้อย่างไร?

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

• ทีมหรือสมาชิกในทีมบางคนมีสัปดาห์ที่ไม่ดี
• ทีมงานของคุณวางท่องานในแนวนอน (เช่นแบ็กเอนด์ -> ส่วนหน้า -> QA)
• เรื่องราวใหญ่เกินไปโดยไม่ตั้งใจ
• ทีม "จานทองคำ" เรื่องราวโดยการเพิ่มงานพิเศษที่ไม่จำเป็นสำหรับการจบเรื่อง
• เรื่องราวมีขนาดใหญ่มากในธรรมชาติคุณต้องใช้เวลานานขึ้น (ไม่น่าจะเป็น)
• ทีมประเมินเรื่องราวไม่แน่นอน (ต่อเนื่อง)
• โปรเจคมีจำนวนหนี้ที่เป็นเทคโนโลยีมาก / ฐานเน่าเสียและความเร็วของคุณต่ำเกินไป
• คุณไม่ได้วัดและประเมินความสามารถในการวิ่งอย่างถูกต้อง (หรือเลย)

ฯลฯ

คุณบอกว่าคุณจะไม่เสร็จ แต่ก็ไม่เลวนั่นเป็นเพียงข้อมูล

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

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

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

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

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

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

สิ่งที่เรามักจะทำใน บริษัท ของเราเมื่องานเริ่มใช้เวลานานเกินกว่าที่คาดไว้

ด้วยวิธีนี้เราจะไม่กล่าวโทษผู้พัฒนาเลยว่าช้าเกินไป แต่เราก็รับทราบว่างานนั้นออกแบบมาไม่ถูกต้อง

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