11 سببًا شائعًا لاستخدام Scaled Agile Framework (SAFe) وكيفية معالجة ذلك باستخدام سكروم لا يتم تحجيمه

ولماذا هذا أكثر فعالية من استخدام SAFe

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

أفضل مثال معروف لهذه الأطر هو Scaled Agile Framework (SAFe). على مستوى زيادة البرنامج ، تقدم SAFe برنامج سكروم إلى الأمام كإحدى طرق إنشاء زيادات المنتج. مع ذلك ، غالبًا ما تكون النسخة المعدلة من سكروم جزءًا من SAFe.

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

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

بواسطة cocoparisienne في Pixabay

1. إدارة التبعيات بين الفريق لتقديم زيادة

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

لدى سكروم طريقة رائعة لإزالة هذه المشكلة:

"فرق التطوير متعددة الوظائف ، مع جميع المهارات كفريق ضروري لإنشاء زيادة في المنتج ؛" - دليل سكروم 2017

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

2. من الرؤية إلى المنتج / مواءمة مستوى المؤسسة مع مستوى الفريق

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

هذه هي الطريقة التي يمكنك حلها باستخدام سكروم:

"إن Product Backlog عبارة عن قائمة مرتبة بكل ما هو مطلوب في المنتج. إنه المصدر الوحيد لمتطلبات إجراء أي تغييرات على المنتج ". - دليل سكروم 2017

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

3. محاذاة صانعي القرار المنتج وصاحب المنتج

غالبًا ما تكون القرارات المتعلقة باتجاه المنتج بعيدة عن متناول مالك المنتج. تخدم SAFe هذا بأدوار مثل مالك الأعمال والمالك الملحمي.

إليك كيفية حلها باستخدام سكروم وحده:

"مالك المنتج مسؤول عن زيادة قيمة المنتج الناتجة عن عمل فريق التطوير". - دليل سكروم 2017

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

قد تكون في وضع مختلف الآن ، حيث يتم فصل مسؤولية المنتج والمسؤولية عن المنتج المتراكم. ولكن لتكون أكثر فعالية في بيئة المنتج مع فرق متعددة ، ضع في اعتبارك تغيير ذلك من خلال توسيع دور مالك المنتج.

4. إعطاء المستوى الأعلى من المنظمة آلية مراقبة

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

يوفر سكروم مكانًا مثاليًا - نقيًا وبسيطًا - لتقييم الحالة الحالية ومناقشة ما ستفعله بعد ذلك:

"خلال مراجعة Sprint ، يتعاون فريق Scrum وأصحاب المصلحة بشأن ما تم فعله في Sprint. بناءً على ذلك وأي تغييرات طرأت على Product Backlog أثناء Sprint ، يتعاون الحضور في الأمور التالية التي يمكن القيام بها لتحسين القيمة ". - دليل سكروم 2017

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

لا يهم دورك. إذا كنت ترغب في التأثير على اتجاه المنتج ، فانتقل إلى مراجعة Sprint!

5. مزامنة التسليم / دمج الزيادات

في بيئة المنتج مع فرق متعددة ، تتواجد قطارات الإصدار السريع من SAFe لمزامنة التسليم نحو الإصدارات لفرق متعددة.

مع سكروم ، لدى الفرق طرق متعددة لمزامنة عملهم. محوري في هذا:

"غالبًا ما تعمل فرق سكروم المتعددة معًا على نفس المنتج. يتم استخدام تراكم منتج واحد لوصف العمل القادم على المنتج ". - دليل سكروم 2017

هذا يعني ما يلي:

1 تراكم المنتج → 1 مالك المنتج → 1 زيادة المنتج → 1 مراجعة Sprint.

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

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

"إنهم يتعاونون ويتفاعلون من خلال بنيات التطوير المعقدة وبيئات الإصدار المستهدفة." - دليل سكروم 2017

6. تحسين الإنتاجية

يتم تقديم SAFe غالبًا لزيادة إنتاجية الفرق. يمكن أن يكون سبب انخفاض الإنتاجية مزيجًا من أي من المشكلات المذكورة أعلاه:

  • إدارة التبعيات بين الفرق لتقديم زيادة ؛
  • من الرؤية إلى المنتج / مواءمة مستوى المؤسسة مع مستوى الفريق ؛
  • إعطاء المستوى الأعلى من المنظمة آلية للرقابة ؛
  • مزامنة التسليم / دمج الزيادات.

وسيؤدي التحسين في هذه المجالات إلى تحسين الإنتاجية. تتم مقارنة تحسينات الإنتاجية إلى حد كبير مع مناهج تنفيذ المشروع التقليدية (في منطقة الشلال).

لقد ناقشت بالفعل كيف يمكن إجراء هذه التحسينات داخل سكروم بشكل فعال. ونتيجة لذلك ، يساعدك سكروم بالفعل على تحقيق تحسن كبير في الإنتاج. لهذا لا تحتاج إلى استخدام آمن.

7. زيادة تسليم القيمة

يتم تقديم SAFe كبديل لإدارة المنتجات التقليدية. باستخدام مبادئ وأطر Lean و Agile مثل Scrum ، تركز SAFe على بناء الشيء الصحيح. لدى SAFe لحظات من التفكير المنتظم لتكون قادرة على ضمان ذلك.

ومع ذلك ، فإن معظم لحظات التفكير هذه متأصلة بالفعل في سكروم. يستخدم Heck ، SAFe لحظات الانعكاس على النحو المحدد في Scrum (مثل مراجعة Sprint و Sprint Retrospective) ، التي تتطلب لحظات انعكاس إضافية فقط بسبب التعقيد الإضافي.

ما يميز سكروم هو أن لحظات التفكير هذه - مع أصحاب المصلحة الرئيسيين - من المحتم أن تحدث في كثير من الأحيان ، لأنها تحدث في كل سبرينت بدلاً من كل زوجين من سبرينت (مع SAFe). وهذا يسمح بمزيد من الرشاقة ، والمزيد من الخيارات للتكيف مع الرؤى الجديدة التي تؤدي بالتالي إلى فرص أكبر لزيادة تقديم القيمة الخاصة بك.

8. زيادة الجودة

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

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

تقدم SAFe إلى الأمام أن الجودة المدمجة هي أكثر من تعريف سكروم لـ "تم". انا اختلف مع هذا تعريف "تم" هو ما تصنعه منظمة التنمية منه. يمكن أن تتضمن نفس الأشياء مثل الجودة المضمنة في SAFe.

9. الهيكل التنظيمي - ماذا تفعل مع جميع الأشخاص الذين يعملون على المنتج؟

لدى SAFe إجابة ملائمة على السؤال الذي يناسب جميع الأشخاص من المؤسسة عند "العمل الرشيق". مع وجود العديد من الأدوار ، هناك دائمًا مكان للجميع (إدارة الأعمال ، وإدارة المنتجات ، ومهندسي النظام ، ومهندسي النظام ، ومهندس قطار الإصدار ، وأكثر من ذلك للحلول الأكبر).

إن وجود كل هذه الأدوار في SAFe يسمح بموقف "يتناسب بسهولة مع المنظمة القائمة". هذا يمكن أن يلغي الحاجة إلى إجراء تغييرات حقيقية - مؤلمة ولكنها ضرورية - على المنظمة. وبذلك يمكن أن يؤدي إلى منظمة تبدو "رشيقة" ولكن في الواقع لا تكون "رشيقة" ، وتفقد جميع مزايا العمل بطريقة رشيقة.

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

سكروم إطار عمل. يمنحك لوحة رسم وكيف تقوم بإنشاء لوحتك متروك لك. ولكن فيما يلي بعض الأمثلة لحل مشكلة من يذهب إلى أين:

  • يمكن أن يكون مدير المنتج مالك منتج سكروم أو أحد أصحاب المصلحة الرئيسيين ؛
  • يمكن أن يكون مهندس النظام جزءًا من فريق التطوير أو أحد أصحاب المصلحة الرئيسيين ؛
  • يمكن أن يكون مهندس النظام جزءًا من فريق التطوير أو أحد أصحاب المصلحة الرئيسيين ؛
  • يمكن أن يكون مالك المنتج كما هو محدد بواسطة SAFe (يعمل في فريق Backlog) جزءًا من فريق التطوير كخبير منتج أو أن يكون مالك المنتج.

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

10. إدارة برنامج مع منتجات متعددة

سبب آخر لتقديم SAFe هو إدارة برنامج مع منتجات متعددة مع الكثير من التبعيات.

قد تجادل بأنني ناقشت التبعيات بالفعل (يتبادر إلى الذهن الموضوعان 1 و 5). ومع ذلك ، أود أن أعرض هذا المثال على منتجات متعددة على وجه التحديد.

أول شيء هو: أليس هذا الخلط بين إدارة المشروع وإدارة المنتج؟

يعد كل من SAFe و Scrum حلين لتقديم منتجات قيمة. كلاهما ليست أطر إدارة المشاريع.

إذا كان لديك منتجات مختلفة مع العديد من التبعيات ، يجب عليك إعادة النظر في ما تحدده كمنتجك. إعادة تقييم تعريفك للمنتج ونتيجة لذلك يمكن أن تكون إعادة تقييم لمحفظة المنتج الخاصة بك في النظام. من المحتمل أن يؤدي ذلك إلى زيادة الشفافية (مثل المسؤول عن مالك المنتج) وسيزيل الحاجة الواضحة لاستخدام SAFe.

11. لمحاذاة العديد من مالكي المنتجات في اتجاه المنتج

غالبًا ما يُنظر أيضًا إلى SAFe كحل لمواءمة العديد من مالكي المنتجات المسؤولين عن المنتج. يمكن أن ينتقل العمل بعد ذلك من البرنامج أو المحفظة المتراكمة إلى العمل المتراكم للفريق ، مقسمًا على مالك المنتج.

تكمن المشكلة في أن المنتج يجب أن يكون له مالك منتج واحد فقط (1 منتج Backlog → 1 مالك المنتج). وبالتالي فإن امتلاك العديد من مالكي المنتجات لمنتج ما هو نمط مضاد. إذا استبعدت هذه المشكلة ، فستتخلص أيضًا من الحاجة إلى هذا النوع من المحاذاة كسبب لاستخدام SAFe.

الحد الأدنى

يأتي Scaled Agile Framework (SAFe) مع حلول للعديد من المشكلات الشائعة إذا كنت ترغب في الانتقال إلى طريقة للعمل بمزيد من المرونة. ومع ذلك ، لا تحتاج إلى جميع أجراس وصفارات SAFe إذا كنت ترغب في حل مشكلاتك. يمكنك حل نفس المشكلات مع Scrum ، إطار عمل خفيف الوزن حقًا. باستخدام سكروم وحده ، فإنك تتجنب التعقيد والتكاليف غير الضرورية.

نصيحتي هي تحديد ما هي احتياجاتك الحقيقية والبدء بشكل صغير.

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

سكروم هي إحدى طرق البدء الصغيرة. إذا كنت قد أتقنت سكروم بما فيه الكفاية وما زلت تشعر بأن هناك شيئًا مفقودًا ، فيمكنك دائمًا البحث عن طرق للتوسع. هنا SAFe هو أحد الخيارات ، ولكن هناك أيضًا LeSS و Nexus و Scrum @ Scale وغيرها.

ستندهش بقوة سكروم. ببساطة قم بالتوسع باستخدام سكروم وحده.

Scumed Scum لا يزال سكروم. بسيطة وقوية.
هل تريد الكتابة لـ Serious Scrum أو مناقشة Scrum بجدية؟