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

Dec 02 2022
ปัญหา เริ่มแรกในเดือนสิงหาคม ฉันออกจากทีมที่ฉันทำงานด้วยมานานกว่าสามปี และกลายมาเป็นผู้จัดการผลิตภัณฑ์ของทีมใกล้เคียงที่ชื่อว่า Catalyst Catalyst เป็นทีมที่มีประสิทธิภาพสูงมาก มีวิศวกรสิบคน แปดคนเป็น "ซีเนียร์"

ปัญหา

ในเดือนสิงหาคม ฉันได้ออกจากทีมที่ฉันทำงานด้วยมากว่าสามปี และกลายมาเป็นผู้จัดการผลิตภัณฑ์ของทีมใกล้เคียงที่ชื่อว่า 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. หากคนๆ หนึ่งพลาดช่วงการวางแผนสำหรับผลิตภัณฑ์ที่พวกเขาสนใจ พวกเขารู้สึกสูญเสียอย่างสิ้นเชิงหลังจากนั้น และไม่รู้ว่าจะเสียบกลับเข้าไปใหม่ได้อย่างไร เราตระหนักว่าเราไม่ได้กำลังทำ “พิธีปิด” อยู่จริงๆ และมันก็ยากสำหรับ วิศวกรเพื่อติดตามเซสชั่นการวางแผนที่พวกเขาพลาดไป
  2. ถ้าคนๆ หนึ่งสนใจในทุกสิ่งที่เรากำลังทำอยู่ นั่นทำให้ทางเลือกที่ยากลำบากหรือการประชุมวันจันทร์ที่ยาวนานมาก
  3. หากเราไม่แน่นอนอย่างยิ่งเกี่ยวกับการประชุมในเวลาที่เหมาะสมและลิงก์การโทรเข้าที่เหมาะสม ผู้คนจะพบช่วงเวลาที่วางแผนได้ยากมาก

เพื่อแก้ปัญหา #1 เราละทิ้งแนวคิดของพิธีปิด แต่เราตัดสินใจเปิดเอกสาร “Olympic Planning” ซึ่งติดตามทุกสัปดาห์ว่าจะใช้บล็อกใดในหัวข้อใด เราตั้งกฎใหม่ที่กล่าวว่า:

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

บทเรียนที่ได้รับ

โดยรวมแล้ว Catalyst มองว่า Olympic Style Planning ประสบความสำเร็จอย่างมาก กระบวนการ ที่ ยืดหยุ่นซึ่งปรับให้เหมาะสมสำหรับการวางแผนรูปแบบเซสชันการทำงานคือสิ่งที่ Catalyst ต้องการในตอนนี้

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

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

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

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

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

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

เรากำลังดำเนินการวางแผนสไตล์โอลิมปิกอยู่! มันจะยังคงเป็นวิธีการที่เราโปรดปรานในการวางแผนจนกว่าจะไม่เป็นเช่นนั้น