การประยุกต์ใช้ Burn Down Charts ในบริบทของ SAFe และ Scrum

ในบทความนี้ผมวางแผนที่จะเล่าว่าในทางปฏิบัติของเรา เราใช้แผนภูมิเบิร์นดาวน์ (Burn Down Chart) อย่างไรในกระบวนการทำงานตามระเบียบวิธี SAFe

ผมขอเริ่มจากสิ่งที่น่าสนใจที่สุดก่อน นั่นคือการใช้แผนภูมินี้ใน SAFe ไม่ควรมีลักษณะเฉพาะใดๆ เมื่อเทียบกับการใช้แผนภูมินี้ใน SCRUM หรือว่าควรมี?

SAFe ของเรามีความแตกต่างตรงที่มีบทบาทอย่าง RTE, ต่างจาก SCRUM ที่ไม่มี Burn Down Chart - เป็นเครื่องมือติดตามปริมาณงานในสปรินต์ และจำเป็นก่อนอื่นสำหรับ ทีม SCRUM ไม่ใช่ สำหรับใครจากภายนอก ใช่ไหม?

ดังนั้น ผมจะกลับมาที่ว่าเราใช้ Burn Down Chart อย่างไร ไม่ว่าจะเป็นเช่นไร และ ในขณะที่ยังอยู่ภายในกรอบ SAFe

ผมอยู่ในบทบาท Scrum Master และ พยายาม แสดงแผนภูมินี้ทุกวัน ให้กับ Dev Teamทั้งหมด เครื่องมือ ที่ผมใช้คือแชทของทีม การแท็กทั้งทีม ผ่าน "@" และภาพหน้าจอสถานะปัจจุบันของแผนภูมิ การแท็กทั้งทีมเป็นเครื่องมือที่ ละเอียดอ่อนพอสมควร และสำคัญคือต้องใช้น้อยที่สุด (เพราะเราในฐานะ Scrum Master ต้อง ช่วยให้ทีม ทำงานได้อย่างสบายและมีสิ่งรบกวนสมาธิน้อยที่สุดเท่าที่จะเป็นไปได้ ใช่ไหม?)

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

• การปรากฏของงานที่ไม่ได้วางแผนไว้
• งานค้างอยู่ในสถานะยังไม่เสร็จเป็นเวลานาน
• การกันความเสี่ยงไว้มากเกินไป
• ความเข้าใจว่า - งานดำเนินไปด้วยจังหวะที่เหมาะสมหรือไม่

ต่อไปผมจะพยายามอธิบายแต่ละเหตุการณ์เหล่านี้และยกตัวอย่างจากประสบการณ์ของผม

การปรากฏของงานที่ไม่ได้วางแผนไว้

ในแผนภูมินี้เห็นได้ชัดเจนมากว่างานใหม่ปรากฏขึ้นอย่างไร (ในวันอังคาร ที่สอง ของสปรินต์สองสัปดาห์)

กรณีจากประสบการณ์: "นักพัฒนา ในฐานะสมาชิกของ ทีม scrum ที่ยึดหลัก agile ปฏิสัมพันธ์กับ Product ได้อย่างยอดเยี่ยมโดยตรง Product บอกเขาว่า อันนี้ต้องทำเร็วๆ นายก็รู้เองแหละ อันนี้เร็วและ ความเสี่ยงต่ำสุด

นักพัฒนาคนนี้เก่ง เขารู้ทุกอย่างเกี่ยวกับ agile และความสำคัญของการส่งมอบคุณค่าทางธุรกิจ เขาไป หยิบ story จาก backlog ใส่บนบอร์ด ทีมประเมินไว้ที่ 6 sp

สมาชิกที่เหลือของทีม (นอกจากนักพัฒนาและ Product) สังเกตเห็นสิ่งนี้ในการอัปเดตแผนภูมิ ตอนเช้า ใน standup ทีมตัดสินใจว่าจะจัดการกับสถานการณ์นี้อย่างไร เป็นไปได้มากว่า story นี้จะถูกเอาออกจากสปรินต์ ทีมทำให้ Product และนักพัฒนาเข้าใจว่า ทำ แบบนี้ไม่ได้ Product สามารถใส่ story นี้ในสปรินต์ถัดไปได้หากจำเป็น

แน่นอนว่าในอุดมคติทีมควรสังเกตเห็นการปรากฏของงานใหม่ใน standup ได้โดยไม่ต้อง ดูแผนภูมิ แต่ แผนภูมิเป็นตัวชี้วัดที่ดีที่ช่วยลดความเสี่ยงในการมองไม่เห็นการเปลี่ยนแปลงสำคัญต่อทั้ง ทีมให้เหลือน้อยที่สุด

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

งานค้างอยู่ในสถานะยังไม่เสร็จเป็นเวลานาน

ที่นี่เราจะเห็นว่างานยังไม่เสร็จแม้แต่บางส่วนเป็นเวลานานมาก สิ่งนี้อาจ บ่งชี้ถึง ปัญหาต่างๆ ฉันจะระบุบางส่วน

• การแบ่งงานที่ไม่ดี

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

• DOD ที่กำหนดไว้ไม่เหมาะสม

  DOD (Definition of Done) - คำอธิบายเกณฑ์ความพร้อมของ User Story ในสปรินต์ บางครั้ง ไม่มีเลยหรือถูกอธิบายแบบนามธรรมมากเกินไป สิ่งนี้อาจเป็นปัญหาได้ ซึ่ง แน่นอนว่า Scrum Master ควรช่วยแก้ไข

การกันความเสี่ยงไว้มากเกินไป

ในกรณีนี้เราจะเห็นสถานการณ์ที่ทีมกันความเสี่ยงไว้มากเกินไป

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

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

ความเข้าใจ - งานดำเนินไปในจังหวะที่ถูกต้องหรือไม่

ที่นี่ฉันอยากจะดึงความสนใจไปที่วิธีแสดงผล Burn Down Chart ที่ไม่ดีในเชิงกราฟิก

ในส่วนบนของภาพเป็นตัวอย่างการนำเสนอกราฟิกที่ไม่ค่อยดีนักด้วยสอง เหตุผลที่ฉันจะอธิบายด้านล่าง

• มองไม่เห็นการเพิ่ม SP ใหม่เข้าสู่สปรินต์

  ที่นี่ ในแผนภาพด้านบน แทบไม่เห็นว่ามีงานที่ไม่ได้วางแผนเพิ่มเข้ามา ในแผนภาพด้านล่างเห็นได้ชัดเจนกว่า

• การแสดงปริมาณงานที่เหลือแบบสัมพัทธ์ไม่ถูกต้อง

  ตามแผนภาพด้านบนยังเหลือเวลาทำงานอีก 3 วัน แต่ในความเป็นจริงเหลือ 2 วัน ใน วันหยุด อาจมีบางคนวางแผนจะพักผ่อน

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