ممارسة تطبيق Cumulative Flow في سياق Scrum وSAFe

في هذه المقالة أخطط لشرح كيف نطبق في ممارستنا Cumulative Flow Chart في Scrum أثناء العمل بإطار عمل SAFe

سأبدأ ربما برابط إلى هذه المقالة - هنا، في رأيي، تم وصف الغرض منها بشكل جيد في شكلها القياسي، أنصح بدراستها قبل قراءة مقالتي. أدناه سأصف كيف قمنا بتكييفها لعملية Scrum (في الأصل تُستخدم في Kanban) وما المشكلات التي تساعدنا على حلها عند العمل بالسبرنتات.

سابقًا، في مقالة عن Burn Down Charts تحدثت بالفعل عن أننا نرى هناك ظهور عمل جديد واحتراق العمل القديم. مشكلة Burn Down Chart هي أنها، على عكس Cumulative Flow Chart، لا نرى عليها حركة قصص المستخدم عبر الحالات. أما عندما نبدأ بمراقبة الحركة عبر الحالات في Cumulative Flow Chart، نبدأ برؤية التغييرات اليومية (قد لا يتغير Burn Down Chart لعدة أيام وفي بعض السياقات قد يكون هذا طبيعيًا تمامًا) ويمكننا ملاحظة مشكلات أكثر دقة.

هكذا قد يبدو ذلك في الديناميكية (في الصورة مخطط مبني على بيانات حقيقية).

في هذا المثال نرى ما يلي

• في الأيام السبعة الأولى من السبرنت يوجد حجم عمل صغير جدًا في الاختبار ولا يتغير
• من DOR (هنا هو مسودة) تنتقل قصص المستخدم إلى العمل بشكل متساوٍ إلى حد كبير - وهذا جيد.
• كما في Burn Down، نرى أنه وفقًا للاتجاه لن يتم إنجاز قصص المستخدم بحلول نهاية السبرنت

هذه الملاحظات الثلاث مجتمعة تؤدي إلى الاستنتاج التالي. هنا كان ينبغي بوضوح في المراحل المبكرة (في مكان ما في اليوم الثاني أو الثالث من السبرنت) أن يلفت Scrum Master الانتباه إلى طبقة "الاختبار" التي صغيرة جدًا ولا تتغير لفترة طويلة (والتأكد من السبب). يمكن الافتراض أن حجم العمل الجاهز للاختبار لا يمكن اختباره لسبب ما، لكن هذا يعني حينها أن المختبرين عاطلون، وهذا يعني على الأقل أنه يستحق الاستماع إليهم باهتمام أكبر في أقرب standup.

إذا تحدثنا عن ممارسة التطبيق، فأنا مثلًا أنشر يوميًا في دردشة الفريق جميع المقاييس قبل standup مع ذكر الفريق بأكمله.

بشكل عام، لا ينبغي أن ننسى أنه لا يزال يجب تفسير المقاييس بشكل صحيح. أن نكون قادرين على رؤية المشكلات النظامية الحقيقية إن وجدت وألا نعتبر مشكلات ما قد يكون في سياقكم حتى علامة إيجابية