จะจัดการกับการวิ่งที่แย่กว่าค่าเฉลี่ย 50% ได้อย่างไร

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

1. ฉันเฉลี่ยจำนวนคะแนนที่เสร็จสมบูรณ์สำหรับการวิ่งหลายครั้งที่ผ่านมา

2. ปริมาณนี้คือความเร็วเฉลี่ยของเรา การเร่งความเร็วครั้งต่อไปเราจะทำเรื่องหลาย ๆ

นี่เป็นค่าเฉลี่ยดังนั้นหากประวัติศาสตร์ซ้ำรอยเดิมการวิ่งนี้มีโอกาส 50% ที่เราจดแต้มเรื่องราวน้อยเกินไปและ 50% มีแนวโน้มว่าเราจดแต้มเรื่องราวมากเกินไป

ในกรณี 50% เราได้ทำคะแนนเรื่องราวมากเกินไปเราสามารถ:

• ล้มเหลวในการวิ่งให้เสร็จ ซึ่งหมายความว่าเราจะล้มเหลวในการบรรลุข้อตกลงในการวิ่งครึ่งเวลา

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

ความเข้าใจของฉันเกี่ยวกับความเร็วเฉลี่ยและภาระผูกพันในการวิ่งถูกต้องหรือไม่?

ถ้าเป็นเช่นนั้นเราควรทำอย่างไรกับ 50% ของการวิ่งที่ต่ำกว่าค่าเฉลี่ย?

ถ้าไม่ฉันได้อะไรผิดไป

ความเข้าใจของฉันเกี่ยวกับความเร็วเฉลี่ยและภาระผูกพันในการวิ่งถูกต้องหรือไม่?

ใช่คุณมีส่วนสำคัญของมัน

ถ้าไม่ฉันได้อะไรผิดไป

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

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

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

ความเข้าใจของฉันเกี่ยวกับความเร็วเฉลี่ยและภาระผูกพันในการวิ่งถูกต้องหรือไม่?

น่าเสียดายที่คุณเข้าใจผิดเกี่ยวกับบางสิ่งเกี่ยวกับ Sprint Planning in Scrum อันดับแรกทีมพัฒนา (DT) คือ

... จัดโครงสร้างและเพิ่มขีดความสามารถโดยองค์กรในการจัดระเบียบและจัดการงานของตนเอง - คู่มือการแย่งชิง

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

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

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

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

ก่อนอื่นความเร็วของคุณมาจากการวิ่งครั้งก่อนหรือบางครั้งมาจากค่าเฉลี่ยของ Sprints ล่าสุด (Weather ของเมื่อวาน) และไม่ใช่ค่าเฉลี่ยของการวิ่งที่ผ่านมาทั้งหมด แน่นอนถ้าคุณไม่มีข้อมูลในอดีตจากทีมหรือ บริษัท ของคุณคุณจะต้องมีค่าที่เหมาะสมสำหรับการวิ่งครั้งแรกของคุณ ในการวิ่งครั้งที่สองของคุณคุณจะได้คะแนนเต็มในการวิ่ง ถ้าคุณวาดกราฟมันคุณอาจเห็นความแปรผันของการวิ่งสองสามครั้งแรก (ตัวอย่างเช่น 17 ในการวิ่งครั้งแรก, 22 ในวินาที, 26 ในสาม, 24 ในสี่) สิ่งนี้เป็นสิ่งที่คาดหวังเมื่อคุณทำให้การทำงานเป็นทีมและกระบวนการประมาณค่าของคุณเป็นปกติพร้อมกับทำความเข้าใจโครงการให้ดีขึ้น (เทคโนโลยีโดเมน)

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

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

ไม่ว่าคุณจะทำอะไรคุณไม่ควรทำงานช้าหรือช้าเกินไป สิ่งนี้เรียกว่าการก้าวที่ยั่งยืน ( Agile Alliance , Scrum Alliance )

ตัวชี้วัดที่อาจมีปัญหาคือถ้า:

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

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

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

1. ช่วยให้นักพัฒนาเคลื่อนไหว
2. เพิ่มความโปร่งใส
3. ช่วยในการสะท้อนและปรับปรุงกระบวนการอย่างค่อยเป็นค่อยไป

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

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

ความเข้าใจของฉันเกี่ยวกับความเร็วเฉลี่ยและภาระผูกพันในการวิ่งถูกต้องหรือไม่?

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

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

ในบางครั้งเจ้าของผลิตภัณฑ์อนุญาตให้ข้ามรายการสองรายการเพื่อให้สามารถเพิ่มได้อีก

บางครั้งทีมงานและเจ้าของผลิตภัณฑ์เห็นพ้องที่จะขยายรายการ

นี่เป็นคำถามที่ยอดเยี่ยมและเป็นสิ่งสำคัญมากสำหรับทีมที่จะต้องพัฒนา หัวข้อนั้นหลอกลวงและเข้าใจผิดอย่างกว้างขวาง จุดประสงค์ดั้งเดิมของการชี้เรื่องราวคือการหาวิธีที่รวดเร็วและแม่นยำในการประเมินระดับความพยายาม (LOE) ที่จำเป็นสำหรับการทำงานที่สมบูรณ์ซึ่งกำหนดไว้ในเรื่องราว วัตถุประสงค์โดยรวม: ให้ทีมคาดการณ์ล่วงหน้าหรือคาดการณ์ระยะเวลาที่ต้องใช้ความพยายาม (เช่นโครงการ) ความเข้าใจเรื่องความเร็วนั้นถูกต้อง: เป็นคะแนนเฉลี่ยต่อ Sprint ที่เสร็จสมบูรณ์ (ทำจริง) ดังนั้นถ้าคุณมีโครงการที่จะส่งมอบและมันคือ 250 คะแนนและทีมของคุณเฉลี่ย 25 ​​คะแนนต่อการวิ่งโครงการจะใช้เวลาประมาณ 10 sprints บวกหรือลบเวลาบัฟเฟอร์บางส่วน

ผู้ทรงคุณวุฒิบางคนเช่น Ken Schwaber แนะนำว่าความเร็วและแต้มจะใช้สำหรับการพยากรณ์ระยะกลางถึงระยะยาวเท่านั้น พวกเขาแนะนำให้ใช้ชั่วโมงงานเป็น“ การตรวจสอบสติ” ครั้งที่สองเกี่ยวกับสิ่งที่สามารถทำได้จริงในการวิ่ง ดังนั้นจำนวนคะแนนในการวิ่งแต่ละครั้งอาจแตกต่างกันไปตามความจุ คนอื่น ๆ (รวมถึงตัวฉันเอง) เชื่อว่าทีมที่เป็นผู้ใหญ่จะเข้าสู่รูปแบบการปรับขนาดที่สอดคล้องกันอย่างมากซึ่งสามารถทำนายความสามารถได้อย่างแม่นยำและในที่สุดชั่วโมงงานจะกลายเป็นภาระเพิ่มเติมที่ไร้ประโยชน์ (จำเป็นอย่างยิ่งที่จะต้องแสดงให้ทีมใหม่อย่างน้อย 6 ถึง 12 สปรินต์ IMHO จนกระทั่งความเข้าใจของทีมเกี่ยวกับคะแนนและการปรับขนาดเรื่องราวนั้นแม่นยำ)

ข้อผิดพลาดเล็กน้อยแรกของคุณคือคุณบอกว่าทีมควรรู้ความเร็วและนำประเด็นมามากมาย ที่จริงแล้วโค้ชจะแนะนำให้ทีมหัก 10% ถึง 20% และส่ง * ไปยังระดับนั้นแทน ดังนั้นหากทีมของคุณมีแนวโน้มที่จะทำคะแนนได้ 25 คะแนนต่อการวิ่งอย่าเติมเต็มการวิ่งเป็น 25 คะแนน แต่ให้หยุดที่ 20 ถึง 22 คะแนน โปรดจำไว้ว่า: เป็นเรื่องดีมากที่จะนำเรื่องราวมาเล่าเมื่อมีงานอื่นเสร็จ ดังนั้นคุณอาจ "ยอมรับ" ถึง 22 คะแนนและทำ 28 ให้สำเร็จ เพียงระมัดระวังที่จะไม่สนับสนุนให้ทีม "กระสอบทราย" และดำเนินการอย่างต่อเนื่อง ไม่มีอะไรผิดปกติกับการยืดเพื่อดูว่าเราสามารถทำอะไรได้มากกว่านี้

ทีนี้มาถึงประเด็นเกี่ยวกับความแปรปรวนระหว่างการวิ่ง มันเป็นรูปแบบที่ธรรมดามาก (แต่ไม่ใช่แบบที่เหมาะสมที่สุด) เพื่อดูทีมที่ทำ 20 คะแนนหนึ่งการวิ่งหนึ่งครั้งจากนั้น 50 และ 22 จากนั้น 45 จากนั้น 45 และ 15 จากนั้น 60 ถ้าคุณคำนวณการเบี่ยงเบน ถึง 100% sprint หลังจากการวิ่ง เหตุใดทีมจึงเล่นจนครบ 15 คะแนนในการวิ่งหนึ่งครั้งและอีก 60 ในอีกรอบ

อาจหมายถึงว่าทีมไม่รู้จริง ๆ ว่าพวกเขาสามารถทำได้ (เฮ้เราวิ่งครบ 50 คะแนนครั้งสุดท้ายเราทำได้อีกครั้งในการวิ่งครั้งนี้)

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

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

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

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

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

ที่นี่คุณเริ่มเห็น WAVES of Done vs Incept Complete สลับ sprint หลังจาก sprint หากทีมไม่ทราบว่าเกิดอะไรขึ้นรูปแบบนี้สามารถดำเนินต่อไปอีกหลายเดือน แต่โดยเฉลี่ยแล้วพวกเขาเสร็จประมาณ 24 คะแนนต่อการวิ่ง แล้วจะเกิดอะไรขึ้นเมื่อพวกเขาเลิกทำเกินไป?

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

เมื่อเวลาผ่านไปความเร็วจะเริ่มเพิ่มขึ้นโดยไม่มีการเปลี่ยนแปลงครั้งใหญ่ในงาน Done-vs-Incomplete

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