การวางแผนซอฟต์แวร์แบบ Agile: จะทำอย่างไรหากการวางแผน Sprint แบบคลาสสิก 2 สัปดาห์ใช้ไม่ได้ผลกับทีมของคุณ

ปัญหา
ในเดือนสิงหาคม ฉันได้ออกจากทีมที่ฉันทำงานด้วยมากว่าสามปี และกลายมาเป็นผู้จัดการผลิตภัณฑ์ของทีมใกล้เคียงที่ชื่อว่า Catalyst Catalyst เป็นทีมที่มีประสิทธิภาพสูงมาก มีวิศวกรสิบคน แปดคนเป็น "ซีเนียร์" วิศวกร” Catalyst เป็นทีมที่ตีหนัก
ในช่วงสองสัปดาห์ครึ่งย้อนหลังหลังจากที่ฉันเข้าร่วม มีคนพูดถึงประเด็นการวางแผน ของเรา พวกเขาไม่ทำงาน ทั้งทีมเห็นด้วย ข้อร้องเรียนหลักคือ:
- การวางแผนของเรานั้นยาวนานมาก เราทุกคนใช้เวลา 1 ชั่วโมงในการซูมโทรทุกวันจันทร์ (ในทางเทคนิคแล้ว เซสชันเหล่านี้สลับกันระหว่าง "การวางแผน" และ "การปรับแต่ง" ซึ่งเป็นส่วนหนึ่งของ "การวิ่ง 2 สัปดาห์") มีความยาว ไม่มีส่วนร่วมมากที่สุด และมีประสิทธิผลอย่างน่าสงสัย
- ตั๋วของเราส่วนใหญ่ไม่มีบริบท ยังไม่ชัดเจนว่าพวกเขาเชื่อมต่อกับเป้าหมายที่ใหญ่กว่าได้อย่างไร
- เรามีเวลากำหนดขอบเขต/วางแผนกลุ่มเล็กไม่มากพอ ผู้คนต้องการกระดานไวท์บอร์ด เซสชันสำหรับ 3-5 คน ซึ่งเราสามารถแยกย่อยสิ่งต่างๆ และออกแบบโซลูชัน/สถาปนิกได้
สิ่งที่เราพยายาม
ต่อมาพวกเราสามคนในคณะกรรมการพิจารณาข้อเสนอได้ประชุมกันและทบทวนปัญหา เราได้หารือเกี่ยวกับภาระที่แท้จริงของการวางแผน/ความเหนื่อยล้าในการประชุมที่สามารถก่อตัวขึ้นสำหรับวิศวกร และบั่นทอนประสิทธิภาพการทำงานของพวกเขาไปตลอดทั้งวัน (หรือมากกว่านั้น)
ตามหลักการแรกของ Agile เราพยายามถอยกลับและถามว่าทำไมเราถึงทำการประชุมวางแผน ทำไมเราถึงวิ่งสองสัปดาห์? เหตุใดเราจึงแยกการวางแผนและการปรับแต่งออกจากกัน ปัญหาใดที่สำคัญที่สุดสำหรับเราในการแก้ไขด้วยพิธีกรรมการวางแผนของเรา เราเพิ่งทำเพราะทีมอื่นส่วนใหญ่ทำแบบนี้หรือเปล่า? อะไรคือสิ่งที่ง่ายที่สุดที่เราสามารถพยายามจัดการกับปัญหาและค่านิยมของเรา
เราได้เขียนแถลงการณ์ที่เราต้องการให้เป็นจริงเกี่ยวกับระบบใหม่ของเรา:
- เราไม่ต้องการผูกติดกับสองสัปดาห์ เราต้องการระบบที่ขยายและย่อขนาดสัปดาห์ต่อสัปดาห์โดยขึ้นอยู่กับการวางแผนที่ทีมต้องทำจริงในสัปดาห์นั้น
- เราไม่เห็นความแตกต่างที่เป็นประโยชน์ระหว่างการวางแผนและการปรับแต่ง
- เราต้องการให้แต่ละคนสามารถเลือกเข้าร่วมหรือไม่เข้าร่วมการวางแผนตามความต้องการส่วนตัว ความสนใจ หรือข้อจำกัดด้านเวลา
- เราต้องการลดระยะเวลาที่เราทั้ง 12 คนจ้องไปที่กระดาน Trello ของเรา อย่างมาก เราเชื่อว่าสิ่งนี้ทำให้ทีมเหนื่อย และไม่เกิดผลมากนัก มีคนจำนวนมากเกินไปในห้องที่จะทำการวางแผนจริง ๆ ที่เราต้องการ
- เราต้องการปรับให้เหมาะสมสำหรับเซสชันการทำงาน 3-5 คน ซึ่งเราสามารถกำหนดขอบเขตการทดสอบและการแก้ปัญหา และเขียนใบสั่งงานได้
- ทุกวันจันทร์เหมือนกัน ไม่มีความแตกต่างระหว่างวันจันทร์ "วางแผน" และวันจันทร์ "ปรับแต่ง"
- เวลา 10.30 น. ทุกวันจันทร์ เราทุกคนเข้าร่วมการประชุม "พิธีเปิด" 30 นาที
- เรามีช่วงเวลาอีก 30 นาทีอีกสี่ ช่วงที่กำหนดไว้ทุกวันจันทร์ตลอดทั้งวัน: บล็อก A, บล็อก B, บล็อก C และบล็อก D
- ในพิธีเปิด PM และผู้จัดการฝ่ายวิศวกรรมนำเสนอข้อมูลล่าสุดเกี่ยวกับผลิตภัณฑ์ขนาดใหญ่และบริบทการจัดส่ง ใครก็ตามที่เป็นผู้นำการทดสอบหรือผลิตภัณฑ์ที่กำหนดจะให้การอัปเดตสั้นๆ มีคนให้ข้อมูลอัปเดตด้านสุขภาพทางเทคนิค
- จากนั้นกลุ่มจะตัดสินใจว่าจะใช้บล็อกที่ใช้ประโยชน์ได้สี่ก้อนในวันนั้นอย่างไรให้ดีที่สุด โครงการใดต้องใช้เวลาวางแผน?
- กลุ่มจะตัดสินใจว่า "พิธีปิด" คือเมื่อใด ระหว่างหนึ่งในบล็อกที่ใช้งานได้ หรือที่สแตนด์อัพในวันอังคาร (หากบล็อกหมด) ทุกคนแบ่งปันการอัปเดตใน Slack และในเอกสารการวางแผนร่วมกัน
- โครงการสามารถใช้ Blocks เป็นเวลาวางแผนกลุ่มย่อยได้ กลุ่มย่อยพูดคุยเป้าหมายโครงการ แบ่งงานออกเป็นงานย่อย และเขียนใบสั่งงานร่วมกัน
- พิธีปิดใช้เวลาเพียง 10–15 นาที กลุ่มย่อยแต่ละกลุ่มอัปเดตทีมเกี่ยวกับสิ่งที่พวกเขาทำ
- ในพิธีปิด ทีมงานจะตรวจสอบกำหนดเวลาที่กำลังจะมาถึงซึ่งจะแจ้งตั๋วโดยการจัดลำดับความสำคัญของตั๋ว
- เรากำลังทำงานเพื่ออะไร? เราตรวจสอบการทดสอบ ฯลฯ ที่เรากำลังดำเนินการ
สิ่งที่เราชอบเกี่ยวกับไอเดียนี้
มีบางสิ่งที่เราตื่นเต้นเป็นพิเศษเกี่ยวกับแนวคิดใหม่นี้
- กระบวนการนี้มีความยืดหยุ่นอย่าง สมบูรณ์ บางสัปดาห์เมื่อเรามีงานวางแผนมากมายที่ต้องทำ เราจะมีเวลาวางแผน 2.5 ชั่วโมงในปฏิทินอยู่แล้ว สัปดาห์อื่น ๆ เมื่อเรามีขอบเขตแล้ว เราสามารถเช็คอิน 15 นาทีที่พิธีเปิด จากนั้นจึงเสร็จสิ้น วิศวกรสามารถทำงานได้อย่างถูกต้อง
- เราลดการประชุมใหญ่ลงอย่างมาก และปรับให้เหมาะสมสำหรับเซสชันการทำงาน 3-5 คน
- เรามอบอำนาจให้อนาคตของเราในการตัดสินใจว่าจำเป็นต้องมีการวางแผน อะไรบ้าง ช่วงเวลาหนึ่งสามารถใช้สำหรับการคิดแบบฟ้าแลบ การกำหนดขอบเขตการทดสอบ หรือพูดคุยเกี่ยวกับหนี้เทคโนโลยี
Catalyst ลองใช้ Olympic Style Planning เป็นเวลา 3 สัปดาห์ จากนั้นทำแบบย้อนยุคอีกครั้งเพื่อสะท้อนให้เห็นสิ่งที่ได้ผลและไม่ได้ผล เราต้องการรักษาแผนโอลิมปิกหรือไม่?
ผลตอบรับเป็นบวกอย่างท่วมท้น ด้วยเหตุผลทั้งหมดที่เราตั้งทฤษฎีไว้ ทีมงานชอบการวางแผนสไตล์โอลิมปิกมากกว่าที่เราเคยทำมาก่อน
ปัญหาที่ใหญ่ที่สุดที่ผู้คนพบเจอคือ:
- หากคนๆ หนึ่งพลาดช่วงการวางแผนสำหรับผลิตภัณฑ์ที่พวกเขาสนใจ พวกเขารู้สึกสูญเสียอย่างสิ้นเชิงหลังจากนั้น และไม่รู้ว่าจะเสียบกลับเข้าไปใหม่ได้อย่างไร เราตระหนักว่าเราไม่ได้กำลังทำ “พิธีปิด” อยู่จริงๆ และมันก็ยากสำหรับ วิศวกรเพื่อติดตามเซสชั่นการวางแผนที่พวกเขาพลาดไป
- ถ้าคนๆ หนึ่งสนใจในทุกสิ่งที่เรากำลังทำอยู่ นั่นทำให้ทางเลือกที่ยากลำบากหรือการประชุมวันจันทร์ที่ยาวนานมาก
- หากเราไม่แน่นอนอย่างยิ่งเกี่ยวกับการประชุมในเวลาที่เหมาะสมและลิงก์การโทรเข้าที่เหมาะสม ผู้คนจะพบช่วงเวลาที่วางแผนได้ยากมาก
เพื่อแก้ปัญหา #1 เราละทิ้งแนวคิดของพิธีปิด แต่เราตัดสินใจเปิดเอกสาร “Olympic Planning” ซึ่งติดตามทุกสัปดาห์ว่าจะใช้บล็อกใดในหัวข้อใด เราตั้งกฎใหม่ที่กล่าวว่า:
- ทุกการบล็อกมีหน้าที่รับผิดชอบในการเพิ่มเอกสารการวางแผนของเราที่มีการพูดคุย และเพิ่มลิงก์ไปยังตั๋วใดๆ และทั้งหมด เอกสารการกำหนดขอบเขต และอื่นๆ ที่อัปเดตเป็นส่วนหนึ่งของเซสชันการวางแผน
บทเรียนที่ได้รับ
โดยรวมแล้ว Catalyst มองว่า Olympic Style Planning ประสบความสำเร็จอย่างมาก กระบวนการ ที่ ยืดหยุ่นซึ่งปรับให้เหมาะสมสำหรับการวางแผนรูปแบบเซสชันการทำงานคือสิ่งที่ Catalyst ต้องการในตอนนี้
มีคนถามในเรโทรล่าสุดของเราว่า "เราควรสร้างพิธีกรรมประจำสัปดาห์ใหม่ ในลักษณะเดียวกันนี้หรือไม่"
เราได้พูดคุยสั้น ๆ เกี่ยวกับกระบวนการปัจจุบันของเราสำหรับ Standup และ Retro และตัดสินใจว่าตอนนี้ยังไม่มีจุดปวดเมื่อย ดังนั้นเราจึงตัดสินใจที่จะไม่คิดค้นกระบวนการเหล่านั้นขึ้นมาใหม่
ฉันรู้สึกตื่นเต้นมากที่สุดเกี่ยวกับวิธีที่เราประกาศใช้คุณค่าของการประกาศแบบอไจล์โดยไม่ต้องพันรอบแอ็กเซิลมากเกินไปด้วยแนวทางปฏิบัติทั่วไปที่ปะปนกับแนวคิดของการพัฒนาแบบอไจล์
กาลครั้งหนึ่งนานมาแล้ว ทีมหนึ่งได้คิดค้นการวิ่งระยะสั้น 2 สัปดาห์ (โดยมีการวางแผนและการปรับแต่ง) เป็นกระบวนการที่ตอบสนองความต้องการและแก้ปัญหาของพวกเขา น่าเสียดายที่ฉันคิดว่ามีทีมจำนวนมากเกินไปที่ปรับใช้กระบวนการแบบนี้ภายใต้หน้ากากของอไจล์ โดยไม่ถามคำถามยากๆ ว่าจุดบอดของพวกเขาคืออะไร และผลลัพธ์ที่พวกเขาต้องการบรรลุผ่านการวางแผนคืออะไร
ถ้ามันฟังดูน่าสนใจสำหรับคุณ ฉันขอแนะนำให้ทีมที่ไม่ชอบพิธีกรรมการวางแผนของพวกเขาลองใช้การวางแผนสไตล์โอลิมปิก แต่นั่นไม่ใช่ประเด็นจริงๆ ประเด็นที่แท้จริงคือ เราทุกคนควรไตร่ตรองกระบวนการของเราอย่างต่อเนื่องและถามตัวเองว่า “สิ่งนี้ได้ผลสำหรับเราหรือไม่”
อัจฉริยภาพของ Agile ไม่ได้อยู่ในกระบวนการที่ซ้ำซากจำเจ มันกระตุ้นให้เราลองทำสิ่งที่ยิ่งใหญ่อย่างรวดเร็วโดยรู้ว่าจะไม่มีอะไรน่ากลัวเกิดขึ้นตราบใดที่คุณสามารถไตร่ตรองได้อย่างรวดเร็วว่าสิ่งนั้นใช้ได้ผลหรือไม่ (และเปลี่ยน/เปลี่ยนกลับอย่างรวดเร็วถ้าจำเป็น) การวนซ้ำอย่างรวดเร็วแจ้งโดยลูปป้อนกลับอย่างรวดเร็ว การเปลี่ยนแปลงที่รุนแรงจะน่ากลัวก็ต่อเมื่อคุณไม่สามารถแก้ไข/เปลี่ยนกลับได้อย่างรวดเร็ว
เรากำลังดำเนินการวางแผนสไตล์โอลิมปิกอยู่! มันจะยังคงเป็นวิธีการที่เราโปรดปรานในการวางแผนจนกว่าจะไม่เป็นเช่นนั้น