ممارسة استخدام مخططات الاحتراق في سياق SAFe وScrum

في هذه المقالة أخطط للحديث عن كيفية تطبيقنا في ممارستنا لمخطط الاحتراق (Burn Down Chart) أثناء العمل وفق منهجية SAFe

سأبدأ، على الأرجح، بالأكثر إثارة للاهتمام. وتحديدًا بأن استخدام هذا المخطط في SAFe لا ينبغي أن يكون له أي خصوصية مقارنة باستخدام هذا المخطط في SCRUM. أم ينبغي؟

يتميز SAFe لدينا بوجود دور مثل RTE، على عكس SCRUM حيث لا يوجد. مخطط الاحتراق (Burn Down Chart) هو أداة لتتبع حجم العمل في السبرنت وهو ضروري прежде всего لفريق SCRUM، وليس لأي طرف خارجي، أليس كذلك؟

وبالتالي، سأنتقل مع ذلك إلى كيفية استخدامنا لمخطط الاحتراق (Burn Down Chart)، بغض النظر عن كل شيء، ومع بقائنا داخل إطار عمل SAFe.

أنا في دور Scrum Master وأحاول إبراز هذا المخطط يوميًا لجميع أعضاء Dev Team. الوسيلة التي أستخدمها هي الدردشة الجماعية للفريق، والإشارة إلى الفريق بأكمله عبر "@"، ولقطة شاشة للحالة الحالية للمخطط. الإشارة إلى الفريق بأكمله هي أداة دقيقة جدًا ومن المهم استخدامها بأقل قدر ممكن (فنحن، مديرو Scrum، يجب أن نساعد الفريق على العمل في راحة وبأقل قدر ممكن من التشتيت، أليس كذلك؟)

نتيجة لذلك، يرى الفريق يوميًا الحالة الحالية للسبرنت وقادر على تتبع الأحداث التالية

• ظهور عمل غير مخطط له
• بقاء المهام معلقة طويلًا في حالة غير مكتملة
• المبالغة في تضمين المخاطر
• فهم ما إذا كان العمل يسير بالوتيرة الصحيحة

بعد ذلك سأحاول الكشف عن كل من هذه الأحداث وإيراد أمثلة من ممارستي.

ظهور عمل غير مخطط له

في هذا المخطط يظهر بوضوح شديد كيف يظهر عمل جديد (في الثلاثاء الثاني من سبرنت مدته أسبوعان).

حالة من الممارسة: "المطور، بصفته عضوًا في فريق scrum يشارك مبادئ agile، يتفاعل بشكل رائع مع Product مباشرة. يقول له Product إن هذا يجب أن يُنجز بسرعة، فأنت تفهم بنفسك، هنا الأمر سريع والمخاطر في حدها الأدنى.

المطور رائع، يعرف كل شيء عن agile وعن أهمية تسليم القيمة التجارية، يذهب ويضع على اللوحة قصة من الـ backlog، وقد قدّرها الفريق بـ 6 sp.

يلاحظ باقي الفريق (باستثناء المطور وProduct) ذلك في التحديث الصباحي للمخطط. في الـ standup يتخذ الفريق قرارًا بشأن كيفية التعامل مع هذا الموقف. على الأرجح، تُستبعد القصة من السبرنت، ويُوضّح الفريق لـ Product وللمطور أن هذا لا يجوز فعله، ويمكن لـ Product وضع هذه القصة في السبرنت التالي عند الحاجة.

بالطبع، في المثالي يجب على الفريق ملاحظة ظهور عمل جديد في الـ standup وبدون المخطط. لكن المخطط مؤشر جيد يقلل إلى الحد الأدنى من مخاطر عدم ملاحظة هذا التغيير المهم للفريق بأكمله.

من المهم هنا فهم أن السيناريو كان يمكن أن يسير بشكل مختلف حسب مستوى الفريق. في الفرق المتميزة، من غير المرجح أن يفعل مالك المنتج ذلك، وإن فعل، فلن يبرره بأن «هذا يمكن إنجازه بسرعة»، بل بأن «أقدّر باحتمال 55% أنه إذا أُنجز هذا الآن، فقد يزيد أرباحنا بنسبة 20% في الشهر التالي» أو بأي مقياس آخر قابل للقياس.

بقاء المهام معلقة طويلًا في حالة غير مكتملة

هنا نرى أن العمل لا يكتمل حتى جزئيًا لفترة طويلة جدًا. قد يشير هذا إلى مشكلات مختلفة، سأذكر بعضًا منها

• تحليل المهام بشكل سيئ

  في كثير من الأحيان تقول الفرق المبتدئة إن التحليل غير ممكن. لديها كل شيء يحترق في اليوم الأخير، والعمل لا يتم توزيعه بالتوازي، إلخ. بالطبع، يجب على سكروم ماستر العمل على ذلك وشرح قيمة التحليل للفريق.

• DOD غير مصاغ على النحو الأمثل

  DOD (Definition of Done) - وصف معايير جاهزية قصة المستخدم في السبرينت. أحيانًا لا تكون موجودة على الإطلاق أو تكون مصاغة بشكل مجرد جدًا. قد يكون هذا مشكلة بالفعل، والتي بطبيعة الحال يجب أن يساعد سكروم ماستر في حلها

المبالغة في تضمين المخاطر

في هذه الحالة نرى موقفًا حيث بالغ الفريق في تضمين المخاطر.

ربما تم المبالغة في تقدير بعض القصص. ربما تكون هذه مشكلة أكثر منهجية ويجب زيادة حجم العمل عند تخطيط السبرينت. في أي حال، هذا الموقف غير صحيح. فالأعمال كانت تخطط لأن يتم تنفيذ مهام السبرينت تحديدًا وبحلول نهاية السبرينت تحديدًا. اعتمادًا على كيفية تخطيط التبعيات، على الأرجح سيتعين هنا عقد اجتماعات لتصحيح التوقعات.

في تجربتي حدث هذا عندما وُجد حل أسرع مما تمت مناقشته عند التقدير. ناقشنا مع الفريق بأكمله أي قصة يمكننا إغلاقها بحلول نهاية السبرينت وفي الاستعراض اتفقنا على أننا سنحاول النظر إلى الكود أثناء الت grooming. اتضح أنه كان يكفي مجرد إلقاء نظرة على الكود لفهم أن الحل أبسط بكثير.

الفهم - هل يسير العمل بالوتيرة الصحيحة

هنا أود أن ألفت الانتباه إلى طرق العرض الرسومية غير الموفقة لمخطط Burn Down Chart

في الجزء العلوي من الصورة مثال على تنفيذ رسومي ليس الأكثر توفيقًا لسببين سأذكرهما أدناه.

• لا يُلاحظ دخول نقاط SP جديدة إلى السبرينت

  هنا، في المخطط العلوي، يكاد لا يُلاحظ أن العمل غير المخطط قد أُضيف. في المخطط السفلي هذا أوضح.

• يُعرض الرصيد النسبي للعمل بشكل غير صحيح

  وفقًا للمخطط العلوي تبقى 3 أيام عمل. في الواقع هي 2، في يوم العطلة، ربما يخطط شخص ما للراحة.

بالطبع، قد تبدو مثل هذه التفاصيل لبعضهم غير مهمة. لكن يجب أن نفهم أن كل عضو في الفريق سيلقي نظرة عابرة فقط على هذا المخطط ويجب أن ينقل أقصى قدر من المعلومات المفيدة.