การจัดการกับ sprints และกำหนดส่งที่ล้มเหลว

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

สิ่งนี้ดูดีมากจากมุมมองของนักพัฒนา แต่สมมุติว่าเรามี บริษัท ซอฟต์แวร์ " Scrum-Addicts LLC " กำลังพัฒนาบางสิ่งสำหรับลูกค้าที่จริงจัง (" Money-Bags Corporation "):

1. ผู้จัดการของ Scrum-Addicts แนะนำให้สร้างชิ้นส่วนของซอฟต์แวร์สำหรับ Money-Bags
2. พวกเขาตกลงในรายการคุณสมบัติและ Money-Bags ขอให้ระบุวันที่จัดส่ง
3. ผู้จัดการ Scrum-Addicts ปรึกษาทีมการต่อสู้ของพวกเขาและทีมบอกว่าจะใช้เวลา 3 สัปดาห์ในการเร่งความเร็วเพื่อให้คุณสมบัติทั้งหมดเสร็จสมบูรณ์
4. ผู้จัดการ Scrum-Addicts เพิ่ม 1 สัปดาห์เพื่อความปลอดภัยสัญญาส่งซอฟต์แวร์ใน 1 เดือนและเซ็นสัญญากับ Money-Bags
5. หลังจาก 4 sprints (กำหนดส่งพัสดุ) ทีมการต่อสู้สามารถส่งมอบคุณลักษณะ 80% เท่านั้น (เนื่องจากไม่มีประสบการณ์กับระบบใหม่จำเป็นต้องแก้ไขข้อบกพร่องที่สำคัญในคุณลักษณะก่อนหน้านี้ในสภาพแวดล้อมการผลิต ฯลฯ ... )
6. ตามที่ Scrum แนะนำไว้ ณ จุดนี้ผลิตภัณฑ์นั้นอาจมีความเสี่ยงต่อการเกิดประกายไฟได้ แต่ถุงเงินต้องการคุณสมบัติ 100% ตามที่ระบุไว้ในสัญญา ดังนั้นพวกเขาจึงผิดสัญญาและไม่จ่ายอะไรเลย
7. Scrum-Addicts กำลังจะล้มละลายเพราะพวกเขาไม่มีเงินจาก Money-Bags และนักลงทุนผิดหวังกับผลลัพธ์และไม่เต็มใจที่จะช่วย บริษัท อีกต่อไป

เห็นได้ชัดว่า บริษัท ซอฟต์แวร์ไม่ต้องการที่จะอยู่ในรองเท้าของ Scrum-Addicts สิ่งที่ฉันไม่เข้าใจเกี่ยวกับ Agile and Scrum คือวิธีที่พวกเขาแนะนำให้ทีมจัดการกับการวางแผนและกำหนดเวลาเพื่อหลีกเลี่ยงสถานการณ์ที่อธิบายไว้ข้างต้น ดังนั้นเพื่อสรุปฉันมี 2 คำถาม:

ใครจะไปโทษ?

1. ผู้จัดการเพราะเป็นหน้าที่ของพวกเขาในการวางแผนที่เหมาะสม
2. ทีมเพราะพวกเขามุ่งมั่นที่จะทำงานมากกว่าที่พวกเขาสามารถทำได้
3. คนอื่น

จะทำอะไร?

1. ผู้จัดการควรเลื่อนกำหนดเวลา 2x (หรือ 3x) ในเวลาช้ากว่าประมาณการของทีมดั้งเดิม
2. สมาชิกในทีมควรได้รับการสนับสนุนให้ทำงานทุกอย่างที่พวกเขาทำไม่ว่าจะเกิดอะไรขึ้น
3. ทีมควรปล่อย Scrum เพราะไม่เป็นไปตามนโยบายกำหนดเวลาของ บริษัท
4. เราทุกคนควรวางการพัฒนาซอฟต์แวร์และเข้าร่วมอาราม
5. ???

ฉันเห็นปัญหาการจัดการพื้นฐานหลายประการในตัวอย่างของคุณ:

• หากผู้จัดการของ Scrum-Addicts ลงนามในสัญญา "กำหนดเส้นตาย" แต่เพิ่มความปลอดภัยเพียง 33% ในสถานการณ์ที่ "มีระบบใหม่เข้ามาเกี่ยวข้อง" นั่นเป็นเรื่องที่ค่อนข้างประมาท

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

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

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

หนึ่งในคำแถลงมูลค่าของ " ประกาศสำหรับการพัฒนาซอฟต์แวร์ Agile " คือ:

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

ความจริงที่ว่าScrum-Addicts LLC ได้เจรจาต่อรองสัญญาแทนการสร้างความร่วมมือกับลูกค้าทำให้ฉันตั้งคำถามถึงความคล่องตัวของพวกเขา

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

มันเป็นความผิดของลูกค้าที่พวกเขาถูกขังอยู่ในฟองสบู่สัญญาของพวกเขาด้วยการพัฒนาตามกำหนดเวลา

ใครจะถูกตำหนิ?

ผู้จัดการฝ่ายกฎหมายนักบัญชี - เลือกของคุณ ...

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

ลูกค้าต้องการเค้กของพวกเขาและกินมัน - พวกเขายินดีที่จะยอมรับน้ำตก, น้ำตกขนาดเล็ก, เปรียว, la-la-land ตราบเท่าที่พวกเขาได้รับผลิตภัณฑ์ X สำหรับ $ Y ตามวันที่ Z

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

โครงการด้านไอทีที่จัดการกับราชวงศ์ ; บางส่วนของเหล่านี้ไม่ทราบแม้กระทั่งราชวงศ์ที่ไม่รู้จัก นั่นหมายความว่าอย่างไร?

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

• คุณรู้ว่าหุบเขาใหญ่แค่ไหน

• คุณรู้ว่าวัสดุของภูเขาความสูงความมั่นคง ฯลฯ

• คุณรู้ว่าคุณต้องการวัสดุเท่าใด

• คุณรู้จาก "โครงการ" ก่อนหน้านี้ว่าคุณใช้เวลานานในการสร้างสิ่งที่คล้ายกัน

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

ยกตัวอย่างขั้นตอนต่อไป:

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

• สมมติว่าคุณมีข้อมูลที่ใกล้เคียงกับโมเดลทิวทัศน์

• ข้อมูลเกี่ยวกับภูมิทัศน์คือว่ามีภูเขาสองลูกซึ่งดูเหมือนจะไม่ใหญ่เกินไป

• ความสอดคล้องของภูเขาอยู่ระหว่างหินและเจลลี่

• ค่าใช้จ่ายรวมมีสูงสุด 10 $

• สถานที่ทำงานมืดสนิทและไม่มีโอกาสได้แสง: คุณมีเพียง 8 กล่องเท่านั้น

• กำหนดเวลาคือ 3 ชั่วโมง

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

บริษัท ไอทีทุกแห่งควรรู้สิ่งนั้น พวกเขาต้องจัดการกับความเสี่ยงของโครงการ

1) มีหลายวิธีในการลดความเสี่ยง (การเงิน): ข้อตกลงอาจรวมถึงลูกค้าที่จ่ายสำหรับการเพิ่มขึ้นทุกครั้งที่ทำงาน ดังนั้นหลังจากส่งมอบส่วนเพิ่ม 1 จะต้องชำระอัตราบางส่วน ตราบใดที่Scrum-Addicts LLCส่งมอบมีความเสี่ยงทางการเงินน้อยที่สุด ยิ่งมีการวางแผนเป้าหมายการวิ่งอย่างละเอียดมากเท่าไหร่ความเสี่ยงโดยรวมของการวิ่งแต่ละครั้งก็จะยิ่งต่ำลงเท่านั้น นั่นหมายความว่าถ้าMoney-Bags Corporationได้รับ 80% ของสัญญาพวกเขาควรจ่ายอย่างน้อย 80% ของมูลค่าสัญญา หากพวกเขาปฏิเสธที่จะจ่ายเงินหลังจากการวิ่งล้มเหลวความเสี่ยงนั้นไม่สูงเท่ากับการปฏิเสธที่จะจ่าย 100%

2) Scrum-Addicts LLCมีปัญหากับผู้พัฒนา

ผู้จัดการ Scrum-Addicts ปรึกษาทีมการต่อสู้ของพวกเขาและทีมบอกว่าจะใช้เวลา 3 สัปดาห์ในการเร่งความเร็วเพื่อให้คุณสมบัติทั้งหมดผู้จัดการ Scrum-Addicts เพิ่มอีก 1 สัปดาห์เพื่อความปลอดภัยสัญญาส่งซอฟต์แวร์ใน 1 เดือนและเซ็นสัญญา กับกระเป๋าเงิน

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

ใครจะไปโทษ?

1) การจัดการ

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

2) ทีม

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

จะทำอะไร?

ตอนนี้: นำถุงเงินไปศาล

สำหรับอนาคต: อย่าทำสัญญาดังกล่าว

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

• จัดโครงสร้างวิธีการสื่อสาร (ผู้พูดคุยกับใครเมื่อเกี่ยวกับอะไร)

• เพื่อสนับสนุนให้นักพัฒนารายงานความล้มเหลวก่อน

• เพื่อแบ่งปัญหาในงานและงานย่อย

• เพื่อจัดโครงสร้างเวลาและความสามารถ (ใครทำงานเมื่ออยู่กับอะไร)

• เพื่อกระจายงานผ่านช่วงเวลา

• ทำให้คาดเดาไม่ได้มากขึ้นอีกเล็กน้อย (การวางแผนโป๊กเกอร์)

หรือโดยรวม: เพื่อลดความเสี่ยง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สิ่งนี้ดูดีมากจากมุมมองของนักพัฒนา แต่สมมุติว่าเรามี บริษัท ซอฟต์แวร์ "Scrum-Addicts LLC" กำลังพัฒนาบางสิ่งสำหรับลูกค้าที่จริงจัง ("Money-Bags Corporation"):

ผู้จัดการ Scrum-Addicts แนะนำให้ทำชิ้นส่วนของซอฟต์แวร์สำหรับ Money-Bags พวกเขาเห็นด้วยกับรายการคุณสมบัติและ Money-Bags ขอให้ระบุวันที่จัดส่งผู้จัดการของ Scrum-Addicts ปรึกษาทีมการต่อสู้ของพวกเขาและทีมบอกว่าจะใช้เวลา 3 สัปดาห์ - sprints ยาวเพื่อทำให้คุณสมบัติทั้งหมดของ Scrum-Addicts manager เพิ่ม 1 สัปดาห์เพื่อความปลอดภัยสัญญาส่งซอฟต์แวร์ใน 1 เดือนและเซ็นสัญญากับ Money-Bags หลังจาก 4 sprints (กำหนดส่งพัสดุ) ทีม Scrum สามารถส่ง 80% เท่านั้น ของคุณสมบัติ (เนื่องจากไม่มีประสบการณ์กับระบบใหม่ความจำเป็นในการแก้ไขข้อบกพร่องที่สำคัญในคุณสมบัติก่อนหน้านี้ในสภาพแวดล้อมการผลิต ฯลฯ ... ) ตามที่ Scrum แนะนำ ณ จุดนี้ผลิตภัณฑ์อาจมีความเป็นไปได้สูง คุณสมบัติตามที่ระบุไว้ในสัญญา ดังนั้นพวกเขาจึงผิดสัญญาและไม่จ่ายอะไรเลย

Scrum-Addicts กำลังจะล้มละลายเพราะพวกเขาไม่มีเงินจาก Money-Bags และนักลงทุนผิดหวังกับผลลัพธ์และไม่เต็มใจที่จะช่วย บริษัท อีกต่อไป

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

เห็นได้ชัดว่า บริษัท ซอฟต์แวร์ไม่ต้องการที่จะอยู่ในรองเท้าของ Scrum-Addicts สิ่งที่ฉันไม่เข้าใจเกี่ยวกับ Agile and Scrum คือวิธีที่พวกเขาแนะนำให้ทีมจัดการกับการวางแผนและกำหนดเวลาเพื่อหลีกเลี่ยงสถานการณ์ที่อธิบายไว้ข้างต้น

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

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

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

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

ดังนั้นเพื่อสรุปฉันมี 2 คำถาม:

ใครจะไปโทษ? ผู้จัดการเพราะมันเป็นงานของพวกเขาที่จะทำการวางแผนที่เหมาะสม
ทีมเพราะพวกเขามุ่งมั่นที่จะทำผลงานมากขึ้นกว่าที่พวกเขาจะทำได้
คนอื่น

ใคร ๆ ก็สามารถหยุดการเลียนแบบนี้ได้ก่อนที่เราจะลงไปหนึ่งเดือน

ฉันสามารถไปไกลเท่าที่โทษ บริษัท Money-Bags Corp สำหรับการว่าจ้างทีมที่เห็นได้ชัดว่าเป็นการฉ้อโกงกระบวนการน้ำตกอย่างฉับพลัน ตัวสัญญาเองทำให้ชัดเจนว่านี่ไม่ใช่ความคล่องตัว การวางแผนที่จะทำในหนึ่งเดือนนั้นไม่ได้ทำให้มันคล่องตัว

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

จะทำอะไร?

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

ผู้จัดการควรเลื่อนกำหนดเวลา 2x (หรือ 3x) ในเวลาช้ากว่าประมาณการของทีมดั้งเดิม

ตัวคูณกำหนดเวลามีประโยชน์เกี่ยวกับการตั้งค่านาฬิกา 15 นาทีก่อนดังนั้นคุณจะไม่สาย คุณสามารถหลอกตัวเองได้นาน ๆ ก่อนที่คุณจะรู้ตัวว่ากำลังทำอะไรอยู่

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

สมาชิกในทีมควรได้รับการสนับสนุนให้ทำงานทุกอย่างที่พวกเขาทำไม่ว่าจะเกิดอะไรขึ้น

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

Daniel Pink มีการพูดคุย TEDเกี่ยวกับเรื่องนี้ การพูดคุยเกี่ยวกับแรงจูงใจไม่ใช่ความคล่องแคล่ว แต่ฉันเห็นวิธีทำแผนที่จุดเหล่านี้อย่างคล่องแคล่ว:

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

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

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

เราทุกคนควรวางการพัฒนาซอฟต์แวร์และเข้าร่วมอาราม

ใช่เหมือนล็อคฉันไว้ในห้องห่างจากชีวิตจริงจะทำให้ฉันเขียนรหัสน้อยลง

ฉันได้แก้ไขคำตอบนี้ลงขนาดแล้ว หากคุณอยากรู้อยากเห็นอ่านประวัติการแก้ไข

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

คุณไม่สามารถให้วันที่จัดส่งได้ไกลเกินไปในอนาคต คุณให้ค่าประมาณ

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

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

ใครจะรู้บ้างในบางโครงการคุณอาจจัดส่งเร็วกว่านี้

คุณไม่สามารถว่องไวถ้าลูกค้าไม่ต้องการ

เป้าหมาย

ฉันเชื่อว่า "ตัวชี้วัด" สองข้อต่อไปนี้ควรเป็นพื้นฐานสำหรับการตัดสินใจทางธุรกิจ:

• เป็นงานที่ทำกำไรได้ (สำหรับลูกค้า)
• พวกเราทำงานอย่างมีประสิทธิภาพที่สุด

เหล่านี้เป็นสากลมาก แน่นอนว่ามันซับซ้อนมากขึ้นอย่างรวดเร็วตัวอย่างเช่นงานที่สร้างผลกำไรนั้นเกี่ยวกับผลิตภัณฑ์ที่ทำสิ่งที่ถูกต้องผู้ใช้สามารถใช้ผลิตภัณฑ์ผลิตภัณฑ์ที่วางตลาดอย่างถูกต้องเป็นต้น - สำหรับผู้เสพติด " Scrum-Addicts" LLC "ไม่รับผิดชอบ

ปัญหา

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

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

ในตอนท้ายของวันเราจะต้องเลือกการประนีประนอมซึ่งจะช่วยให้เราสามารถบรรลุเป้าหมายของเราให้ดีที่สุด

นี่คือวิธีการทำงาน

• มีสัญญาสำหรับบริการและทำงานแทนผลิตภัณฑ์
  • จะต้องยกเลิกในการแจ้งให้ทราบที่ค่อนข้างสั้น
• ทำงานร่วมกันอย่างใกล้ชิดเพื่อให้เกิดประสิทธิภาพสูงสุด
• เกี่ยวข้องกับทุกฝ่ายที่จำเป็นทั้งจาก " Scrum-Addits LLC " และ " Money-Bags Corporation " - "การติดต่อเพียงจุดเดียว" ในการขุดอุโมงค์ข้อมูลทั้งหมดจะไม่ทำงานที่นี่

โดยทั่วไปฉันเพิ่งพูดว่า "ว่องไว" ตอนนี้นี่คือเหตุผล:

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