ฉันใช้เวลาวางแผนมากกว่า 5 ชั่วโมงในการวิ่งเป็นเวลาหนึ่งสัปดาห์ ดูเหมือนว่าจะมากเกินไป

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

เราจะจัดการกับสิ่งนี้ได้อย่างไร

ฉันควรพูดคุยรายละเอียดมากน้อยเพียงใดระหว่างการวางแผนเพื่อให้พอดีกับความยาวเพียง 2 ชั่วโมงต่อสัปดาห์

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

ดังนั้นคุณจะจัดการกับ Sprint Planning ได้อย่างไร

ในฐานะอาจารย์การต่อสู้ฉันจะทำตามขั้นตอนต่อไปนี้:

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

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

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

ขั้นตอนเพิ่มเติมอาจหลุดออกจากสิ่งเหล่านี้ แต่นี่จะเป็นจุดเริ่มต้นที่ดี

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

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

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

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

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

ฉันชอบคำตอบที่คุณได้รับจาก @ Thomas-Owens แต่ฉันจะเพิ่มอีกหนึ่งรายการ คุณคิดว่าการเขียนโปรแกรมจับคู่เป็นส่วนหนึ่งของการนำ Agile มาใช้หรือไม่?

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

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

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

ฉันเห็นธงสีแดงหลายอันในสิ่งที่คุณเขียน:

การวางแผนการวิ่ง 5 ชั่วโมง

นี่เป็นวิธีที่ยาวเกินไปสำหรับการวิ่งหนึ่งสัปดาห์

เป้าหมายของการวางแผนการวิ่งคือ AFAIR ถึง

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

Product Backlog itemsเพื่อที่จะทำทำเช่นนี้ได้อย่างมีประสิทธิภาพในแต่ละด้านมีที่จะเข้าใจ

เพื่อให้เข้าใจว่าProduct Backlog itemsงานในมือจะต้องอยู่ในสภาพดี

ในขั้นตอนการวางแผนคอนกรีตจะกลายเป็นProduct Backlog itemsSprint Backlog items

สาเหตุหนึ่งที่เป็นไปได้คือรายการเหล่านี้ไม่ได้รับการชี้แจง / กลั่นกรองอย่างเพียงพอ

อีกสาเหตุที่เป็นไปได้คือไอเท็มนั้นซับซ้อนเกินไปและออกจากห้องไปเพื่อการตีความมากเกินไป

สนทนาอย่างละเอียดมากในการวางแผนการวิ่ง

ดังกล่าวข้างต้นขั้นตอนการสนทนาจะสั้นลงเมื่อรายการมีรูปธรรมมากขึ้น

ในอีกทางหนึ่ง: การวางแผน Sprint คาดว่าจะมีพฤติกรรมแบบมืออาชีพจากผู้เข้าร่วมทุกคน ซึ่งรวมถึงการหลีกเลี่ยงการอภิปรายbikeshedding

บางทีสิ่งต่าง ๆ ชัดเจน แต่บางคนเริ่มถกเถียงกันเรื่องการขี่มอเตอร์ไซค์

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

เนื่องจากสมาชิกในทีมส่วนใหญ่ไม่อาวุโส

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

ข้อผิดพลาดของการใช้งานและการออกแบบใหม่ในระหว่างการวิ่ง

ดูเหมือนจะมีปัญหาพื้นฐานในการรวบรวมความต้องการตามด้วยการค้างสินค้าที่คลุมเครือมาก

ดังที่ฉันได้กล่าวไว้ข้างต้น: ตราบใดที่Product Backlogมีรูปร่างที่ดีก็ควรจะพลาดจุดยาก

ฉันไม่สามารถจินตนาการถึงสถานการณ์เช่นนี้:

»ในฐานะผู้ใช้ฉันต้องการเห็นลูกค้าไม่กี่คน! «

»โอ้คุณไม่ได้หมายถึงลูกค้า 2 ล้านคนของเราทุกคนใช่ไหม«

OTOH: การออกแบบบริบทหมายถึงอะไร หากนักพัฒนาเลือกอัลกอริทึมที่มีประสิทธิภาพช้านั่นหมายความว่าเป้าหมายต่อไปจะชัดเจน: เลือกอันที่มีประสิทธิภาพดีกว่า แต่นั่นไม่ใช่ "การออกแบบใหม่" นี่เป็นการเพิ่มประสิทธิภาพ

คำถามหลักของคุณ:

วิธีจัดการกับสิ่งนี้?

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

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

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

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

ฉันควรพูดคุยรายละเอียดมากน้อยเพียงใดในระหว่างการวางแผนให้พอดี 2 ชั่วโมงต่อการวิ่งหนึ่งสัปดาห์

คำตอบของ Salomonic: น้อยที่สุดเท่าที่จะเป็นไปได้และเท่าที่จำเป็น แต่ไม่มาก

TL; DR

• เลือกภาษาที่ง่าย (ถ้ามีประโยชน์ใช้ภาษาอังกฤษง่าย ๆหรือELI5) เพื่อหลีกเลี่ยงความเข้าใจผิด

• ปรับปรุงการรวบรวมความต้องการ

• ปรับปรุง Backlog

• เพิ่มความมั่นใจของสมาชิกในทีมในความสามารถส่วนบุคคลรวมถึงความสามารถในการทำงานเป็นทีม

• หลีกเลี่ยงการขี่ bikeshedding

• ปรับปรุงวินัยส่วนบุคคล

• อาจใช้กล่องระบุเวลาคงที่สำหรับทุกรายการเพื่อหารือ

• เสริมความแข็งแกร่งในตำแหน่งของscrum masterถึงปานกลางอย่างมีประสิทธิภาพ

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