การประชุมวางแผนการวิ่งระยะเวลานานเท่าไร

16

จากประสบการณ์ของคุณการประชุม Sprint Planning ควรจะนานเท่าไร 8 ชั่วโมง? หรือควรสั้นลง (กระชับ) และควรมีการวางแผนการสนทนาเพิ่มเติมในฐานะส่วนหนึ่งของการวิ่ง Sprints ของเรามีความยาว 10 วัน

agile scrum planning

— wleao
แหล่งที่มา

4

8 ชั่วโมงต่อการวิ่ง 10 วันฟังดูมากเกินไปสำหรับฉัน การอภิปรายที่ไม่ต้องการทีมงานทั้งหมดควรถูกแยกออกจากเซสชันแยกต่างหากเฉพาะสำหรับสมาชิกที่เกี่ยวข้อง

— PéterTörök

1

ดังนั้นคุณวางแผนการประชุมอื่นแทนที่จะพูดคุยทุกอย่างในการวางแผน จุดสังเกต

— wleao

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

— rwong

31

ตามคู่มือการแย่งชิง :

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

ที่ใช้งานได้โดยทั่วไปสำหรับฉัน

— Matthew Flynn
แหล่งที่มา

5

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

— โธมัสโอเวนส์

6

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

— Matthew Flynn

@MatthewFlynn จุดดี

— HA

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

— Zymus

27

ตราบใดที่มันต้องการที่จะอยู่ได้ไม่น้อยไปกว่านี้อีกแล้ว สิ่งอื่นใดที่ไม่ใช่ Agile

หากคุณมีทีมงานของนักพัฒนา 2 - 3 คนและกำลังทำอะไร 1 สัปดาห์การวิ่งอะไรมากกว่าชั่วโมงก็น่าจะมีประสิทธิผล

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

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

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

SCRUM นั้นเกี่ยวกับการปรับกระบวนการในการวนซ้ำให้มากที่สุดเท่าที่จะเป็นการปรับปรุงรหัสของคุณในการวนซ้ำ

ดูเหมือนว่าเวลาหนึ่งชั่วโมงจะสั้นสำหรับนักพัฒนา 3 คน / 1 สัปดาห์ จากนั้นอีกครั้งฉันเพิ่งเสร็จสิ้นโครงการขนาดเล็กที่เราวางแผนการวิ่งสัปดาห์ละ 5 นาที ขึ้นอยู่กับโครงการและบนบัตรเพราะบางครั้งจำเป็นต้องมีการอภิปรายมากกว่า (หรือน้อยกว่า) ระหว่างการวางแผนการวิ่ง

— กำหนดค่า

2

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

— Matthew Flynn

7

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

— MattC
แหล่งที่มา

1

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

— JeffO

3

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

จาก Scrum Primer ( PDF ):

การปรับปรุง Backlog สินค้า

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

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

— ฮิวโก้
แหล่งที่มา

@GottliebNotschnabel: ขอบคุณนั่นเป็นเรื่องใหม่ ฉันได้เปลี่ยนลิงค์สำหรับไม่ต้องการเข้าสู่ระบบ

— Hugo

2

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

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

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

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

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

— David Pritchett
แหล่งที่มา

1

ในการประชุมวางแผนการวิ่งทีมต้องพิจารณาสองชุด:

A) สิ่งที่จะได้รับการพัฒนาโดยทีมในช่วง Sprint นี้

B) จะพัฒนาอย่างไร

การประชุมครั้งนี้จะต้องลงในกล่องเวลาสูงสุดสองชั่วโมงสำหรับแต่ละสัปดาห์ของ Sprint แบ่งเท่า ๆ กันสำหรับแต่ละส่วน (ส่วน A และส่วน B) ของการประชุม

ดังนั้นสำหรับ Sprint 4 สัปดาห์การประชุมนี้ควรไม่เกิน 8 ชั่วโมงถึง 4 ชั่วโมงสำหรับส่วน A และ 4 ชั่วโมงสำหรับส่วน B

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

ในส่วน B ทีมพัฒนาจะหารือเกี่ยวกับวิธีการพัฒนาเรื่องราวของผู้ใช้ที่ท้าทายยิ่งขึ้นซึ่งเลือกไว้เพื่อพัฒนา ส่วนใหญ่ทีม dev จะไม่มีเวลาพอที่จะพูดคุยเกี่ยวกับวิธีการพัฒนาเรื่องราวของผู้ใช้ที่เลือกทั้งหมดดังนั้นทีมจะต้องเลือกเรื่องราวของผู้ใช้ที่ท้าทายที่สุด

ในช่วง Sprint ทีม dev มีเวลาเพียงพอในการอภิปราย

— GEN
แหล่งที่มา

-1

ตามคู่มือการแย่งชิง :

เหตุการณ์การต่อสู้

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

— เลนิน
แหล่งที่มา

คุณช่วยอธิบาย downvote ได้หรือไม่เมื่อฉันคัดลอก / วางย่อหน้าจาก Scrum Guide เท่านั้น

— เลนิน