الرشاقة

SAFe والرشاقة على نطاق واسع: متى وكيف تنتقلون من Scrum إلى Scaled Agile Framework؟

بقلم Codevista Innovationsنُشر في 12 أكتوبر 2026حُدّث في 15 أكتوبر 20268 دقائق قراءة

يصبح إطار SAFe (Scaled Agile Framework) مبرَّرًا حين تعمل عدة فرق رشيقة معًا على تسليم الحل نفسه، وتبدأ التبعيات والأولويات المتضاربة والإدماج المتأخر في إلغاء ما يكسبه كل فريق بفضل Scrum. فهو يضيف بنية تنظيمية هي Agile Release Train، وحدثًا مشتركًا للتخطيط هو PI Planning، وتدبيرًا رشيقًا لمحفظة المشاريع (Lean Portfolio Management)، مقابل أدوار وأحداث إضافية. وقبل اعتماده، تأكّدوا من أن مشكلتكم نابعة فعلًا من التنسيق بين الفرق، وأن الإدارة العليا مستعدة للانخراط بنفسها.

كيف تعرفون أن Scrum لم يعد كافيًا؟

صُمّم Scrum لفريق صغير قادر على أن يسلّم بمفرده زيادةً (increment) قابلة للاستعمال. وما دام المنتج يتّسع لفريق أو فريقين، فإن تحسين تطبيق Scrum أو الانتقال إلى Kanban يحلّ في الغالب جوهر المشكلات (راجعوا مقارنتنا Scrum أم Kanban). لكن طبيعة الصعوبات تتغير حين تشتغل عدة فرق على الحل نفسه:

• تبعيات متسلسلة: ينتظر فريقٌ واجهةَ API أو بيئةَ عمل أو مصادقةً من فريق آخر، فينتهي الـ sprint دون زيادة قابلة للاستعمال.
• أولويات غير منسجمة: يحسّن كل Product Owner قائمة أعماله الخاصة، ولا أحد يحكم بين الفرق، فيتلقى الجانب الوظيفي أجزاءً من وظائف لا فائدة منها منفصلة.
• إدماج مُرهِق: يعلن كل فريق أنه « أنهى » عمله من جهته، ثم يأتي التجميع في نهاية الفصل نسخةً طبق الأصل من مرحلة الإدماج القديمة في نموذج الدورة على شكل V.
• غياب أي رؤية لدى الإدارة، التي ينتهي بها الأمر إلى المطالبة بتخطيطات مفصّلة لستة أشهر، بما يتعارض مع منطق الـ sprints.

إليكم اختبارًا بسيطًا: أعيدوا قراءة العوائق التي طُرحت في آخر الاجتماعات الاسترجاعية (retrospectives). فإن كانت تتعلق أساسًا بالسير الداخلي لكل فريق، فالمشكلة ليست في الحجم. أما إن كانت تحيل باستمرار إلى فريق آخر، أو إلى تحكيم غائب، أو إلى إدماج متأخر، فإن مسألة الرشاقة على نطاق واسع تصبح مشروعة.

ما الذي يضيفه SAFe: Agile Release Train وPI Planning والمحفظة

لا يحلّ Scaled Agile Framework محلّ Scrum أو Kanban على مستوى الفرق، بل ينظّمها حول مسار قيمة مشترك. ويُنشر المرجع الرسمي، المعتمد في المصطلحات والمتطور من إصدار إلى آخر، على موقع scaledagileframework.com.

Agile Release Train (ART)

الـ ART فريق من الفرق الرشيقة، مستقر في الزمن، يتقاسم المهمة نفسها وقائمة الأعمال نفسها (ART Backlog) والإيقاع نفسه. ويبقى حجمه محدودًا عن قصد، في حدود 50 إلى 125 شخصًا حسب المرجع، حتى يتمكن الجميع من التخطيط في القاعة نفسها. ويتولى Release Train Engineer (RTE) تيسيره، بينما يرتّب Product Management أولويات الـ features، ويحمل System Architect الرؤية التقنية، ويمثّل Business Owners مصالح الجانب الوظيفي ويصادقون على الأهداف.

PI Planning

يضمّ الـ PI (Planning Interval، وكان يُسمّى سابقًا Program Increment) عدة تكرارات، تليها تكرارة للابتكار والتخطيط (IP Iteration). وفي بداية كل PI، تجتمع كل فرق القطار في PI Planning، عادةً على مدى يومين: تُقسّم الـ features، وتُظهر التبعيات على لوحة ART Planning Board، وتلتزم بأهداف PI Objectives. وخلال الـ PI، يعرض System Demo الزيادة المُدمجة للقطار بأكمله، ثم يُختتم الـ PI بجلسة Inspect & Adapt.

مستوى المحفظة

في صيغة Portfolio SAFe، يموّل Lean Portfolio Management مسارات القيمة بدل تمويل المشاريع واحدًا تلو الآخر، وتمرّ الـ Epics عبر Portfolio Kanban قبل المصادقة عليها. وهنا غالبًا ما يحدث التغيير الحقيقي بالنسبة للإدارة العامة، لأنه يمسّ الميزانية والحكامة، لا طريقة عمل الفرق فحسب.

ما كلفة SAFe من حيث الطقوس والتنظيم؟

لا تقتصر كلفة SAFe على فاتورة التكوين، بل تُقاس قبل كل شيء بالوقت والاهتمام:

• أدوار جديدة (RTE وProduct Management وSystem Architect)، يشغلها أشخاص متفرغون فعلًا لها، لا تُضاف إلى منصب ممتلئ أصلًا.
• أحداث إضافية: PI Planning وSystem Demo وInspect & Adapt، ومزامنات منتظمة بين الفرق، وتدقيق مسبق للـ features.
• لغة مشتركة ينبغي أن يتبناها التنظيم بأكمله، ما يعني تكوين الفرق والمدبّرين والمسؤولين.
• إطار مملوك: SAFe علامة تجارية لشركة Scaled Agile, Inc.، التي تمنح الشهادات الرسمية، وهذا ينعكس على ميزانية التكوين والإشهاد.
• خطر البيروقراطية إذا طُبّق الإطار بشكل آلي، أداةً بعد أداة، دون التساؤل عمّا تضيفه كل واحدة منها.

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

SAFe أم LeSS أم Scrum@Scale أم Kanban: ما البدائل؟

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

• LeSS (Large-Scale Scrum): Product Owner واحد وProduct Backlog واحد لعدة فرق، مع عدد قليل جدًا من الأدوار المضافة. وهو متطلّب من حيث النضج التقني وإعادة هيكلة التنظيم.
• Scrum@Scale: امتداد معياري لـ Scrum، يوسّع التنظيم عبر شبكات من الفرق المترابطة فيما بينها.
• Nexus: إطار Scrum.org لبضعة فرق Scrum تعمل على المنتج نفسه، مع فريق إدماج مخصّص.
• Kanban محكم على مستوى المحفظة: جعل كل المبادرات الجارية مرئية، وتحديد العمل الجاري على مستوى الإدارة، والتحكيم على فترات منتظمة. وهو غالبًا الخطوة الأولى الأقل كلفة، ويمهّد لأي إطار لاحق.

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

لماذا يفشل تطبيق SAFe؟

تتشابه أسباب الفشل من تنظيم إلى آخر:

• قطارات منظَّمة حسب الأقسام بدل مسارات القيمة: فتعيد إنتاج الحواجز بين المصالح تحت اسم جديد.
• فرق لا تتقن Scrum: فبدون تكرارات مستقرة ولا Definition of Done مشترك، يضخّم التوسيع الفوضى.
• PI Planning مفروض: تأتي الإدارة بنطاق وموعد محدّدين سلفًا، دون مراعاة القدرة التي أعلنتها الفرق.
• أولويات تتغير خلال الـ PI دون المرور عبر Product Management، ما يُفرغ PI Objectives من معناها.
• ممارسات تقنية ضعيفة: فبدون إدماج مستمر ولا اختبارات مؤتمتة، يعرض System Demo شاشات لا نظامًا مُدمجًا.
• إطار يُعتمد من أجل الصورة، دون قياس للتدفق ولا للنتائج الوظيفية.

لا يعود أيّ من هذه الأسباب إلى الإطار ذاته، بل هي أسباب تنظيمية. ولهذا فإن التحضير أهم من الاختيار بين SAFe ومنافسيه.

كيف تُحضّرون أول PI Planning؟

يُحضَّر أول PI Planning على مدى عدة أسابيع. وهذه هي المراحل الأساسية:

1. تحديد مسار القيمة والفرق التي تساهم فيه، بما في ذلك وظائف الدعم التي لا غنى عنها (الأمن، والاستغلال، والمطابقة).
2. تعيين الأدوار الرئيسية وتكوينها: RTE وProduct Management وSystem Architect وBusiness Owners، إلى جانب Scrum Masters وProduct Owners في الفرق.
3. بناء ART Backlog: features مرتّبة حسب الأولوية، مع معايير القبول وفرضية القيمة الوظيفية. وتُدرج فيه المتطلبات التنظيمية، مثل حماية المعطيات ذات الطابع الشخصي بموجب القانون 09-08، منذ البداية لا في نهاية الـ PI.
4. إعداد الرؤية التي ستعرضها الإدارة في الافتتاح: السياق الوظيفي، والأهداف، والقيود، والمحطات المعروفة.
5. حساب قدرة كل فريق، مع مراعاة العطل والأعياد والحصة المخصصة للصيانة.
6. تنظيم الجوانب اللوجستية: قاعة أو أداة تعاونية، ولوحة ART Planning Board، وجدول أعمال موقّت بدقة، وحضور أصحاب القرار من البداية إلى النهاية.

خلال الحدث

يتناوب السير النموذجي بين جلسات عامة وعمل داخل الفرق: عرض السياق الوظيفي ورؤية المنتج ورؤية البنية المعمارية، ثم ورشات يبني فيها كل فريق خطة تكراراته. وتتيح مراجعة الخطط المؤقتة وجلسة لحل المشكلات مع الإدارة تعديلَ النطاق. وفي اليوم الثاني، تعرض الفرق خططها النهائية، وتُعالَج المخاطر وفق منهجية ROAM (Resolved, Owned, Accepted, Mitigated)، ثم يُختتم التمرين بتصويت على الثقة. والتصويت الضعيف ليس فشلًا، بل هو إشارة إلى ضرورة إعادة التخطيط قبل الالتزام.

وحين تتوزع الفرق على عدة مواقع، في الدار البيضاء أو في مدن أخرى بالمغرب أو في الخارج، فإن صيغة هجينة مجهّزة جيدًا تؤدي الغرض، شريطة أن يظل Business Owners متاحين للتحكيم طوال اليومين.

ما الذي ينبغي أن تلتزم به الإدارة لإنجاح SAFe

لا يمكن تفويض SAFe إلى مديرية نظم المعلومات. فعلى الإدارة العامة أن:

• تشارك: يحضر Business Owners في PI Planning وSystem Demo وInspect & Adapt، ويُسندون قيمة وظيفية إلى PI Objectives.
• تموّل مسارات القيمة بدل المشاريع، ما يقتضي مراجعة الدورة الميزانياتية.
• تحمي الـ PI: لا استعجالات تُقحَم دون تحكيم، وعدد محدود من المبادرات المتوازية.
• تقود التحوّل: بتعيين فريق للقيادة، يسمّيه المرجع Lean-Agile Center of Excellence (LACE)، ومنحه الوقت والصلاحية.
• تتكوّن في القيادة الرشيقة، وتتقبّل أن الأمر يتطلب عدة PI قبل أن يجد القطار إيقاعه.

وتصبح وظائف الموارد البشرية والمالية والتسويق معنيةً بمجرد أن تعبرها مسارات القيمة (راجعوا الرشاقة خارج نطاق تكنولوجيا المعلومات). أما بالنسبة للمقاولات الصغرى والمتوسطة، فإن مقاربة أخف تنسجم في الغالب بشكل أفضل مع تحوّل رقمي تدريجي.

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

أسئلة شائعة

كم عدد الفرق اللازم لتبرير اعتماد SAFe؟

لا يوجد حدّ سحري. يجمع Agile Release Train عدة فرق رشيقة تسلّم الحل نفسه، في حدود 50 إلى 125 شخصًا حسب المرجع. ومع فريقين أو ثلاثة، تكفي في الغالب قائمة أعمال مشتركة أو مراجعات مشتركة أو إطار خفيف مثل Nexus أو LeSS. والمعيار الحاسم هو مستوى التبعية بين الفرق والحاجة إلى تخطيط مشترك مرئي للإدارة.

ما الفرق بين PI Planning وSprint Planning؟

يخصّ Sprint Planning فريقًا واحدًا وتكرارًا واحدًا. أما PI Planning فيجمع كل فرق Agile Release Train، مع Product Management والبنية المعمارية وBusiness Owners، للتخطيط المشترك لـ Planning Interval يضم عدة تكرارات. وهو يُظهر التبعيات ويُفضي إلى PI Objectives. ثم يحتفظ كل فريق بتخطيط تكراراته الخاص داخل الـ PI.

هل يجب إتقان Scrum قبل الانتقال إلى SAFe؟

نعم، وهذا موصى به بشدة. يعتمد SAFe على فرق قادرة على تسليم زيادة عاملة في كل تكرار، بأدوار واضحة وDefinition of Done مشترك. وإذا كانت الفرق تتعثر أصلًا في الأساسيات، فإن التوسيع يضخّم المشكلات بدل حلّها. لذا فإن ترسيخ Scrum أو Kanban على مستوى الفرق هو في الغالب الخطوة الأولى.

هل يمكن أن يموّل OFPPT تكوين SAFe في المغرب؟

تتيح عقود التكوين الخاصة (CSF) لمكتب التكوين المهني وإنعاش الشغل (OFPPT) للمقاولة استرجاع جزء من مصاريف التكوين. وملف تأهيل Codevista Innovations قيد الإنجاز، وإلى ذلك الحين لا يمكن تمويل برامجها، ومنها تكوين SAFe، بهذه الطريقة. ويحدد OFPPT شروط الاستفادة والمسطرة المتبعة، لذا تحقّقوا منها مباشرة لدى المكتب قبل الشروع في الإجراءات. ويشرح مقالنا حول تمويل CSF المبدأ بالتفصيل.