การเริ่มภารกิจย่อยที่จุดเริ่มต้นของการวิ่งแต่ละครั้ง

ฉันได้เข้าร่วมทีมใหม่ซึ่งใช้ Agile / Scrum และกระบวนการพัฒนาของพวกเขามีดังนี้:

1) นักพัฒนาตรวจสอบแต่ละเรื่องก่อนการวิ่งแต่ละครั้งเพื่อให้แน่ใจว่าจะไม่พลาดสิ่งสำคัญ มีสถานะทางการสำหรับเวิร์กโฟลว์

2) ในช่วงการแข่งขันสปรินท์ทั้งทีมทำการประเมิน (การวางแผนโป๊กเกอร์) ว่าจะให้คะแนนเรื่องราวกี่เรื่องในแต่ละเรื่อง

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

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

แต่ฉันก็พบว่าสิ่งนี้ต่อต้านการผลิตส่วนใหญ่เนื่องจากเหตุผลดังต่อไปนี้:

• ถ้าเป้าหมายคือการประมาณคร่าว ๆ จุดเรื่องราว (ขั้นตอนที่ 2) คือสิ่งที่ทำงาน มิฉะนั้นทำไมต้องกังวลกับเรื่องราวทั้งหมด - เพียงแค่ทำภารกิจย่อยเร็ว
• ถ้าจุดมุ่งหมายคือการให้ข้อมูลประมาณการที่ถูกต้องแล้วนี้เป็นตัวอย่างที่ชัดเจนของสิ่งที่อธิบายไว้ในงานของมนุษย์ช์พิจารณาอันตราย ฉันคิดว่านี่เป็นกรณีพิเศษสำหรับนักพัฒนาใหม่ที่เข้าร่วมทีมที่มีอยู่ในโครงการขนาดใหญ่ที่เข้าใจว่าต้องทำอะไรอาจต้องใช้เวลามากถึง 50% คุณจะต้องดูรายละเอียดของเรื่องราว # 1 จากนั้นเล่าเรื่องราวที่ 2, # 3 ฯลฯ ฯลฯ ซึ่งให้ข้อมูลจำนวนมากปั่นป่วน

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

สิ่งนี้ไม่เหมือนกันกับวิธีที่เราเรียกใช้กระบวนการแย่งชิงของเรา เรา

1. ประมาณการเรื่องราวที่อยู่ใกล้กับยอดค้างใน "จุดเรื่องราว"
2. เลือก / อธิบายเรื่องราวตามจุดเรื่องราวที่เราคิดว่าจะ "ทำ" การวิ่ง
3. แยกย่อยเรื่องราวออกเป็นงานด้านเทคนิคที่มีรายละเอียดมากขึ้น
4. ประมาณการงานด้านเทคนิคและเปรียบเทียบกับการคาดคะเนคะแนนเรื่องราวดั้งเดิม (เรารู้ว่าเวลาการพัฒนาเท่าไหร่ที่ปกติจะเท่ากับ)

แต่สิ่งที่คุณอยากรู้คือเหตุผลที่เราประเมินสองครั้ง!

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

เมื่ออ่านคำถามและความคิดเห็นของคุณฉันเห็นว่ามีความแตกต่างระหว่างเวิร์กโฟลว์ของเราและของคุณ

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

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

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

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

• คุณกำลังทำรายละเอียดแตกต่างกัน - ดังนั้นสมาชิกในทีมของคุณจะเรียนรู้จากสมาชิกอาวุโสของคุณอย่างไร แน่นอนว่าพวกเขาอาจเรียนรู้ทุกอย่างด้วยตนเอง - แต่พวกเขาจะเรียนรู้ได้เร็วขึ้นหากพวกเขาเป็นที่ปรึกษา สมาชิกในทีมจูเนียร์ใช้เวลานานในการแยกแยะสิ่งต่างๆหรือไม่? พวกเขาทำผิดพลาดหรือสิ่งต่าง ๆ ที่ต้องเสียเวลาในระยะยาวหรือไม่? การพังทลายเป็นทีมสามารถช่วยได้ที่นี่
• คุณกำลังทำการประเมินแบบเอกเทศ - เช่นเดียวกับจุดแรก แต่นอกจากนี้การประมาณการเหล่านี้มีความแม่นยำน้อยกว่าที่ควรเป็นหรือไม่
• ดูเหมือนว่างานจะได้รับมอบหมายเมื่อเริ่มต้นการวิ่ง แต่ถ้าเป็นกรณีนี้คุณจะพบว่ามันแพงแค่ไหนเมื่อคุณต้องเปลี่ยนการบ้าน? หากมีใครตกหลุมหรือป่วยมันเป็นเรื่องง่ายสำหรับคนอื่นที่จะไปรับงานของพวกเขา? พวกเขาต้องผ่านขั้นตอนย่อยสลายงานและพยายามเข้าใจพวกเขาโดยไม่ขัดจังหวะผู้รับมอบหมายเดิมหรือไม่ หากคุณแยกย่อยและประเมินเป็นทีมทุกคนน่าจะสามารถทำงานได้ทุกอย่าง!
• เรื่องราวของคุณใหญ่เกินไปไหม หากการพังทลายต้องใช้เวลา 50% เรื่องราวดูเหมือนว่าพวกเขามีส่วนร่วมมาก - บางทีพวกเขาอาจทำให้เล็กลงได้? เราเก็บเรื่องราวของเราภายใน 1 สัปดาห์ของการทำงาน
• งานของคุณเล็กเกินไปหรือเปล่า หากคุณใช้เวลานานในการจัดทำรายการงานบางทีคุณอาจต้องลงรายละเอียดมากเกินไป? เรามักจะมีงานระหว่าง 1 ถึง 8 ชั่วโมงที่ควรค่าแก่การทำงานเพื่อให้ทุกวันมีความคืบหน้าในการรายงานในอันดับต่อไป

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

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

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

นี่คือความคิดเห็นของฉัน ฉันขอแนะนำให้คุณลองด้วยตัวเองและวัดผลลัพธ์ - ดูว่าฉันทำอะไรที่นั่น :)

ฉันสมมติว่า Sprint Kickoff ของคุณหมายถึงการประชุม Sprint Planning ฉันคิดว่า Scrum Master ของคุณตีความผิดว่าการประชุมครั้งนี้จะเป็นอย่างไร คุณไม่เพียง แต่ตัดสินใจว่าจะพัฒนาเรื่องราวใดคุณยังต้องทดสอบความหมายของทีมให้พร้อมเพื่อให้แน่ใจว่าพวกเขาจะไม่พลาดอะไรเลย (โดยทั่วไปจะใช้INVEST ) และคุณแบ่งเรื่องราวเหล่านั้นออกเป็นงานต่างๆ เพื่ออ้างอิงMike Cohn (หนึ่งในผู้ก่อตั้ง Scrum Alliance);

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

ดังนั้นการทำลายเรื่องราวและประเมินพวกเขาเป็นส่วนหนึ่งของเซสชันการวางแผน Sprint ไม่ใช่หลังจากเซสชันการวางแผนเสร็จสิ้นและไม่ได้แยกกัน

เพื่อให้ข้อมูลเชิงลึกเพิ่มเติมเวิร์กโฟลว์ของเราในระหว่างการประชุม Sprint Planning มีดังนี้:

1. เรานำเรื่องราวจากยอดค้างของผลิตภัณฑ์และแยกมันออกเป็นงานต่างๆ โดยทั่วไปแล้วงานหนึ่งควรมีขนาดเล็กกว่าหนึ่งวัน

2. เราประเมินเรื่องราวที่ได้รับจากงานที่เราหัก หากเรื่องราวเปลี่ยนไปมากเราลองและแยกย่อยเรื่องราวออกเป็นเรื่องเล็ก ๆ

3. ล้างและทำซ้ำจนกว่าจะถึงจุดรวมทั้งหมดโดยประมาณ

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

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

"โดยหนังสือ" - นั่นคือปัญหาของคุณ คุณกำลังจมน้ำในกระบวนการมากกว่าที่คุณเคยเจอถ้าคุณทำงานน้ำตก

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

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

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

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

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

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

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