เวลาประมาณการเท่ากับสัญญาในการแย่งชิงกันหรือไม่?

หากการประมาณการไม่ใช่สัญญาจากนั้นในฐานะเจ้าของผลิตภัณฑ์ฉันจะส่งมอบโครงการโดยไม่ทราบว่าจะใช้เวลานานเท่าใด

ทีมการต่อสู้ทำงานอย่างมีประสิทธิภาพมากขึ้นหรือไม่หากเราปฏิบัติตามการประมาณการเวลาตามสัญญาหรือไม่

การวิจัย (การเตรียมการความพยายามในการเข้าใจปัญหา) ในเรื่องเท่าไหร่เพียงพอที่จะประเมินได้ถูกต้องหรือไม่

ปัญหาด้านเทคนิคที่ไม่คาดคิด (ปัญหาที่อาจทำให้การประมาณการเริ่มต้นของคุณยุ่งเหยิง) ที่เกิดขึ้นหลังจากที่คุณประเมินงานของคุณ?

การคาดคะเนไม่ได้สัญญาว่าจะจารึกด้วยหิน พวกเขาคาดเดาได้ดีที่สุดว่าทีมสามารถใช้ความพยายามในการทำงานให้เสร็จ

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

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

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

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

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

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

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

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

ขั้นตอนที่คุณให้คำมั่นสัญญาในการส่งมอบคือเมื่อคุณยอมรับเรื่องราวจากการค้างสินค้าไว้ใน Sprint คุณมีแนวโน้มที่จะส่งเรื่องราวเหล่านั้นภายในการวิ่ง

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

เมื่อทีมประเมินเสร็จพอพวกเขาจะทำได้ดีกว่า

คุณอาจต้องการดู ...

The Coder สะอาด (หนังสือ) - มีบทหนึ่งในหนังสือเล่มนี้ชื่อว่า "The Language Of Commitment" และบทที่เกี่ยวกับการประเมินซึ่งเป็นการเปิดหูเปิดตาจริงๆ

Kanban - Kanban เป็นรูปแบบการดึงมากกว่าการพัฒนาแบบวิ่ง - นอกจากนี้ยังมีการผสมผสานของ Scrum และ Kanban เรียกว่า "Scrumban" ซึ่งดึงมาจากแนวคิดทั้งสอง

เลขที่

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

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

และนั่นคือวิธีที่คุณมั่นใจได้ว่าทีมสามารถส่งมอบได้โดยไม่ต้องทำสัญญาแบบสุ่ม

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

เรากำลังมองไปข้างหน้าในเปรียว ภาระผูกพันไม่เพิ่มมูลค่าให้กับการวางแผนองค์กรมากกว่าการคาดการณ์

ขอแนะนำการประมาณการและการวางแผนแบบคล่องตัวของ Mike Cohn

หากการประมาณการไม่ใช่สัญญาจากนั้นในฐานะเจ้าของผลิตภัณฑ์ฉันจะส่งมอบโครงการโดยไม่ทราบว่าจะใช้เวลานานเท่าใด

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

ทีมการต่อสู้ทำงานอย่างมีประสิทธิภาพมากขึ้นหรือไม่หากเราปฏิบัติตามการประมาณการเวลาตามสัญญาหรือไม่

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

การวิจัย (การเตรียมการความพยายามในการเข้าใจปัญหา) ในเรื่องเท่าไหร่เพียงพอที่จะประเมินได้ถูกต้องหรือไม่

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

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

ปัญหาด้านเทคนิคที่ไม่คาดคิด (ปัญหาที่อาจทำให้การประมาณการเริ่มต้นของคุณยุ่งเหยิง) ที่เกิดขึ้นหลังจากที่คุณประเมินงานของคุณ?

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

หากการประมาณการไม่ใช่สัญญาจากนั้นในฐานะเจ้าของผลิตภัณฑ์ฉันจะส่งมอบโครงการโดยไม่ทราบว่าจะใช้เวลานานเท่าใด

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

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

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

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

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

ดังนั้นการประมาณการไม่ใช่สัญญา มันเป็นค่าประมาณ "สัญญา" คือความมุ่งมั่นที่ทีมทำเพื่อให้ได้ฟีเจอร์หรือเรื่องราวใน Sprint ที่เฉพาะเจาะจง

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