เราจะให้การประมาณเวลาที่ถูกต้องในระหว่างการวางแผน Sprint โดยไม่ทำการออกแบบ "มากเกินไป" ได้อย่างไร

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

เมื่อเราพยายามที่จะคิดออกว่างานจะต้องใช้เวลานานแค่ไหนเรามักจะตกหลุมพรางของการออกแบบคุณสมบัติในระดับรหัส - เลย์เอาต์ของตารางอินเตอร์เฟสและอื่น ๆ เพื่อที่จะทราบว่าจะต้องใช้เวลานานแค่ไหน .

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

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

แก้ไข:

เพื่อชี้แจงเนื่องจากข้อคิดเห็น / คำตอบบางอย่างนั้นถูกต้องมาก แต่ฉันคิดว่าการตอบคำถามผิด

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

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

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

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

2. พิจารณาใช้การวางแผนโป๊กเกอร์เช่นคะแนน / หน่วยของ "ความพยายาม" แทนที่จะเป็น man-day เพื่อประเมินงาน พยายามทำลายเรื่องราวให้มากที่สุด เรื่องราวที่ซับซ้อนมากขึ้น / ยาวมากเท่าใดโอกาสที่คุณคาดการณ์จะแม่นยำก็จะน้อยลงเท่านั้น

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

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

ฉันคิดว่าปัญหาคือคุณพยายามประเมินเวลา อย่า

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

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

ผมขอแนะนำให้ไมค์ของ Cohn เรื่องที่ผู้ใช้สมัครแล้ว

ฉันรู้ว่าคำถามของคุณเกี่ยวกับการหลีกเลี่ยงการออกแบบในการวางแผนโดยเฉพาะ แต่นี้คือการจัดเรียงของปัญหา XY

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

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

เกณฑ์การยอมรับอัตโนมัติ

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

ตัวอย่างเช่น "เมื่อผู้ใช้คลิก 'เล่น' บน iPad ที่ใช้ iOS 6+ วิดีโอจะเริ่มเล่น" อาจเป็นเรื่องยากที่จะทำให้การทดสอบนี้เป็นจริงโดยอัตโนมัติ แต่เป็นเกณฑ์การยอมรับ (AC) ของเรื่องราวและก่อให้เกิดจุดหนึ่ง

เราใช้สเกลฟีโบนักชีและเราจะปัดเศษขึ้นเสมอ ดังนั้นหากเรื่องราวมีเกณฑ์การยอมรับอัตโนมัติสี่ข้อมันเป็นเรื่องราวห้าจุด

ขนาดจุดเรื่องราวสูงสุดของเราคือแปดจุด แต่เราไม่ค่อยมี หากเรื่องราวมีเกณฑ์การยอมรับอัตโนมัติมากกว่าห้ารายการเราจะหาวิธีแยกพวกเขาออก

Pre-เครื่องแต่งกาย

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

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

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

การ จำกัด งานระหว่างทำ

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

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

เมื่อเรื่องราวย้ายจาก Backlog ไปสู่การทำงานที่กำลังดำเนินอยู่เราจะอธิบายลักษณะของการเป็นหนึ่งในหลาย ๆ สถานะ:

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

จากนั้นเราจะใช้จำนวนเรื่องราวในแต่ละรัฐเพื่อขับเคลื่อนโฟกัสของทีม ตัวอย่างเช่นนักพัฒนาอาจพร้อมที่จะรับเรื่องใหม่ แต่ถ้าเรามีเรื่องราวมากมายในการทดสอบมันจะดีกว่าสำหรับพวกเขาที่จะช่วยเรื่องราวที่มีอยู่

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

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

มีสองสิ่งที่คุณสามารถทำได้ที่นี่

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

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

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

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

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

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

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