خصوصية عمل فريق Agile في SAFe مقارنة بـ Scrum في الممارسة العملية

بعد النشر بين الأصدقاء للمقال الأول عن Burn Down Chart, كان أول سؤال طُرح في التعليقات: "سيكون من المثير للاهتمام معرفة المزيد عن تجربتكم مع SAFe". لذلك، سأحاول في هذه المقالة الكشف عن خصوصية العمل في SAFe مقارنة بـ Scrum في ممارستنا. أنا لا أدّعي الحقيقة المطلقة وسأكون سعيدًا بأي تصحيحات وتوضيحات من الزملاء.

أولاً سأذكر بإيجاز أهم ما يميز العمل في SAFe عن SCRUM، في رأيي.

• Increment في Scrum و Program Increment في SAFe
• ART - Agile Release Train
• عدد الفرق المتفاعلة
• PIPE
• SOS
• PO - ليس مالك العمل
• RTE
• السبرنت الخامس للتدريب
• System Demo

Increment في Scrum و Program Increment في SAFe. في الواقع مصطلحات مختلفة، لكن من السهل الخلط بينها لأن لا أحد يستخدم لدينا مصطلح Program Increment، الجميع يقولون ببساطة Increment - وهذا مصطلح آخر يُستخدم في SCRUM. لكن بشكل عام هما متشابهان إلى حد كبير من حيث المعنى، في رأيي. Increment في SCRUM - هو في جوهره المنتج الحالي + القصص المخطط لها للسبرنت في حالة منجزة (اجتازت DOD الفريق). Program Increment - هو الفاصل الزمني الذي يقدم خلاله القطار (Agile Release Train) قيمة تدريجية إلى الإنتاج. من حيث المدة لدينا 4 سبرنتات مدة كل منها أسبوعان للتطوير وسبرنت واحد للتدريب.

Agile Release Train - هو فريق من الفرق يعملون على تدفق واحد لإنشاء القيمة. نحن نسمي هذا ببساطة القطار، لكن وفقًا لإطار العمل الصحيح يجب تسميته "Solution". في حالتنا، هذه القاعدة لا تُلتزم بالكامل وغالبًا ما تعمل الفرق على منتجات مختلفة من الناحية التقنية، لأن معظم الميزات التجارية تُنفَّذ بشكل متكامل وتشمل عدة منتجات. هذا من الناحية التقنية. لكنني واثق من أن البعض يعتبر جميع أنظمة تقنية المعلومات منتجًا واحدًا للشركة، وربما هذا حتى أكثر صحة.

عدد الفرق المتفاعلة لدينا في SAFe أكبر بكثير، في المجموع يُوصى بما يصل إلى 125 شخصًا في قطار واحد. لدينا 3 قطارات وليس في كل منها تُلتزم هذه القاعدة، هناك قطارات بعدد أكثر من 125 شخصًا. SCRUM لا يصف كيفية التفاعل مع الفرق الأخرى، على حد علمي، على عكس SAFe، حيث توجد توصيات واضحة جدًا بهذا الشأن. أبرز أثر، في رأيي، لهذا هو Program Board.

عليه تُعرض العلاقات المتبادلة بين فرق القطار، ومن خلال مناقشته تُعقد الفعاليات الأسبوعية Scrum Of Scrums (SOS) لدينا.

تقريبًا كل 2.5 شهر (كل 5 سبرنتات) يحدث حدث PIPE - Programm Increment Planning Event. هذا عندما تجتمع جميع الفرق الموزعة في قاعة واحدة لمدة يومين وتخطط لأعمالها للـ 2.5 شهر القادمة. في عملية هذه الفعالية تظهر آثار مثل Program board، على سبيل المثال، الذي تُعرض عليه جميع تبعيات الفرق فيما بينها لكل قطار، وقد أظهرت أعلاه كيف يبدو. تتمثل مهمة Scrum Master لكل فريق في هذه الفعالية في تسهيل تحديد أكبر عدد ممكن من التبعيات، ثم إزالتها إن أمكن (عن طريق نقل الكفاءات شفهيًا، على سبيل المثال، من فريق إلى فريق أو عن طريق سحب التبعية من فريق إلى آخر حتى يتمكن الفريق من تنفيذ ميزته بشكل مستقل دون الاعتماد على أحد). في الممارسة العملية هذا ما يحدث لدينا. أولاً تُفكَّك الميزات إلى User Story، وتُوزَّع User Story على 4 سبرنتات. تُوضع الميزات على Program Board وتُحدَّد التبعيات من الفرق الأخرى كما هي. خلال الفعالية يُناقش هذا ويُصحَّح.

SOS - Scrum Of Scrum. تُعقد هذه الفعالية مرة في الأسبوع لكل قطار على حدة. يجتمع Scrum Masters لجميع فرق القطار عبر الإنترنت، ويُبث Program Board الخاص بالقطار وتُناقش حالات جميع التبعيات والميزات لفرق القطار المعني. في جوهرها هذه الفعالية ضرورية للمزامنة المركزية للفرق داخل القطار. شيء مثل standup، لكن مرة في الأسبوع وليس للفريق، بل لـ Scrum Masters.

PO (مالك المنتج) - ليس مالك العمل. هناك Product Manager - يعمل مع Business Owners للاتجاهات التجارية المقابلة وفي جوهره يوزع الميزات على مالكي المنتج. يعمل مالك المنتج بالفعل مباشرة في الفريق - يقسّم الميزات إلى User Stories (في حالتنا بالتعاون مع الفريق) وليس دائمًا يقسّم، لكن نحن نتقدم باستمرار في هذا الاتجاه.

RTE (Release Train Engineer - سائق القطار. سكرام ماستر سكرام الماسترات. يقود أحداث SOS لقطاره. يتفاعل مع مدير المنتج على مستوى الميزات. يسهّل PIPE.

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

System Demo. نتيجة PIPE يكون لدى كل فريق قائمة أهداف للإنكريمنت وكل هدف من هذه الأهداف يقيّمه Business Owner القطار على مقياس من 10 نقاط. هذا يُسمى Business Value. تُقسم هذه الأهداف إلى أساسية وموسّعة. الأهداف الأساسية هي الأهداف التي لا يرى الفريق أي مخاطر في تحقيقها. الموسّعة هي الأهداف التي توجد مخاطر في تحقيقها. جميع الأهداف إلزامية وحجم العمل يُخطط لجميع الأهداف. في System Demo يقبل Business Owner نتائج العمل عن الإنكريمنت. لنفترض أن الفريق كان لديه 3 أهداف أساسية بتقييمات 10، 6، 8 وهدفان موسّعان بتقييمات 10، 3. لنفترض أن Business Owner وضع التقييمات التالية على التوالي: 8، 6، 4، 2، 0. الآن يمكن حساب نسبة تحقيق الأهداف: تُؤخذ 100% من المجموع الأولي للنقاط للأهداف الأساسية، في حالتنا هذه 10+6+8=24. تُحسب النقاط المحققة مع مراعاة الأهداف الموسّعة (أي أن الفريق حقق 20 من 24)، أي في النتيجة ستكون نسبة تحقيق الأهداف لدى الفريق (20*100)/24 = 83.3%. النتيجة الطبيعية تُعتبر تحقيقًا من 80% إلى 100%.

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

تعليقات الزملاء من facebook

«جينيا، مرحبًا! رائع أنك تكتب، أحسنت! سأصحح قليلاً بخصوص القطارات - فهي لا تتشكل حول المنتج، بل حول تدفق خلق القيمة. وفي التجزئة لدينا من وجهة نظر SAFe ليس قطارًا، بل Solution. فقط لسهولة التواصل وتبسيط الفهم، نواصل تسميته قطارًا)»

– كونستانتين فورونين (ممثل مكتب المشاريع في Ingosstrakh)

«وحسنًا، ربما يلاحظ أحدهم أنه من وجهة نظر SAFe يتم تقييم الأهداف في I&A; (حيث تدخل SD كجزء، لكنها غير مرتبطة مباشرة بالتقييم) بينما يجب أن تُجرى SD نفسها كل سبرنت (بعد عروض الفرق). لكننا ما زلنا بعيدين عن ذلك، لذلك نسمي كل شيء بوعي كما هو مكتوب في مقالتك)»

– كونستانتين فورونين (ممثل مكتب المشاريع في Ingosstrakh)

«جينيا، تابع من فضلك، مفيد جدًا!»

– أليكسي إيونوف (مدرب معتمد في SAFe)