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

ในบทความนี้ ผมวางแผนที่จะเล่าถึงการประยุกต์ใช้ Cumulative Flow Chart ใน Scrum ในกระบวนการทำงานตามกรอบ SAFe

ผมขอเริ่มต้นด้วยลิงก์ไปยัง บทความ นี้ - ในความเห็นของผม ที่นี่อธิบายวัตถุประสงค์ของมันในรูปแบบมาตรฐานได้ดี แนะนำให้ศึกษาก่อน อ่านบทความของผม ด้านล่างนี้ผมจะอธิบายว่าเราได้ปรับมันให้เข้ากับกระบวนการ Scrum อย่างไร(เดิมทีมัน ถูกใช้ใน Kanban) และมันช่วยเราแก้ปัญหาอะไรบ้างในการทำงานแบบสปรินต์

ก่อนหน้านี้ ใน บทความ เกี่ยวกับ Burn Down Charts ผมได้กล่าวไปแล้วว่าในนั้นเราเห็นการปรากฏของงานใหม่และการเผาผลาญงานเก่า ปัญหาของ Burn Down Chart คือ ต่างจาก Cumulative Flow Chart ตรงที่บนนั้นเราไม่เห็นการเคลื่อนไหว ของ User Story ตามสถานะ เมื่อเราเริ่มสังเกตการเคลื่อนไหวตามสถานะใน Cumulative Flow Chart เราจะเริ่มเห็นการเปลี่ยนแปลงรายวัน (Burn Down Chart อาจไม่เปลี่ยนแปลงหลายวัน และใน บาง บริบทก็อาจเป็นเรื่องปกติ) และเราสามารถสังเกตเห็นปัญหาเล็กๆ น้อยๆ ได้

นี่คือลักษณะที่มันอาจดูในเชิงพลวัต(ในภาพเป็นแผนภูมิที่สร้างจากข้อมูลจริง)

ในตัวอย่างนี้เราเห็นสิ่งต่อไปนี้

• 7 วันแรกของสปรินต์ มีงานอยู่ในขั้นทดสอบน้อยมากและไม่เปลี่ยนแปลง
• จาก DOR (ในที่นี้คือฉบับร่าง) User Story ถูกย้ายเข้าสู่การทำงานอย่างสม่ำเสมอพอสมควร - นี่เป็นสิ่งดี
• เช่นเดียวกับบน Burn Down เราเห็นว่าตามแนวโน้มแล้ว User Story จะไม่เสร็จสิ้นภายใน สิ้นสุดสปรินต์

ข้อสังเกต 3 ประการนี้เมื่อรวมกันนำไปสู่ข้อสรุปดังนี้ ในที่นี้เห็นได้ชัดว่าตั้งแต่ระยะแรกๆ (ประมาณ วันที่สอง-สามของสปรินต์) Scrum Master ควรให้ความสนใจกับชั้น "การทดสอบ" ซึ่ง น้อยเกินไป และไม่เปลี่ยนแปลงเป็นเวลานานพอสมควร(ตรวจสอบว่าสาเหตุคืออะไร) อาจสันนิษฐานได้ว่าปริมาณงานที่พร้อม สำหรับ การทดสอบไม่สามารถทดสอบได้ด้วยเหตุใดเหตุหนึ่ง แต่ถ้าเป็นเช่นนั้นก็หมายความว่านักทดสอบ ว่างงาน ซึ่งอย่างน้อยที่สุดก็ควรตั้งใจฟังพวกเขาให้มากขึ้นในการยืนประชุมครั้งถัดไป

หากพูดถึงการประยุกต์ใช้ ตัวอย่างเช่น ผมเผยแพร่ทุกวันในแชทของทีมซึ่งเมตริกทั้งหมดก่อน การยืนประชุม โดยกล่าวถึงทีมทั้งหมด

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