مخطط إدارة المشروع الجزء 2: مقارنة شاملة بين Waterfall و DAD و SAFe و LeSS و Scrum @ Scale

ملخص

في الجزء الأول من مخطط إدارة المشروع ، غطينا منهجيات تطوير البرمجيات Lean ، و Agile ، و Scrum ، و Kanban وكيف تتبع جذورها جميعًا إلى Lean Manufacturing. عادة ما يتم نشر هذه المنهجيات على مستوى فريق واحد. ومع ذلك ، يزداد التعقيد مع زيادة حجم المشاريع وفرق المشروع ، وهناك حاجة إلى مناهج جديدة لتكون سريعة الحركة على نطاق واسع.

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

شلال

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

مراحل دورة الحياة الست لنموذج الشلال الأصلي هي:

1. المتطلبات: في هذه المرحلة ، يتم تحديد توقعات وأهداف المشروع ، ويتم تحليل المتطلبات وتوثيقها على نطاق واسع ، عادة من قبل محلل أعمال. تتم مراجعة المتطلبات والموافقة عليها قبل الخروج من هذه المرحلة.
2. التصميم: بعد الموافقة على المتطلبات ، يبدأ العمل في هندسة وتصميم المنتج لتلبية المتطلبات المعتمدة. يتم توثيق العمارة المادية ، وبنية المكونات ، وتصميم قواعد البيانات ، والمكونات التفصيلية ، وتصميم الوحدة ، وجوانب التصميم الأخرى بواسطة مهندس أو مصمم برمجيات. ثم تتم مراجعته والموافقة عليه قبل البدء في التنفيذ.
3. التنفيذ: بعد الموافقة على التصميم ، يتم تنفيذ البرنامج أو ترميزه حسب المتطلبات والتصميم من قبل مطوري البرمجيات.
4. التحقق: بعد اكتمال التنفيذ ، يتم اختبار البرنامج من قبل فريق الاختبار أو فريق ضمان الجودة للتأكد من تلبية المتطلبات والتصميم وتحقيق المستوى المطلوب من الجودة. تم العثور على العيوب ، وتسجيلها ، وفرزها ، وفي كثير من الحالات ، يتم إصلاحها.
5. الإصدار والصيانة: بعد اكتمال الاختبار والتصحيح ، يتم تحرير المنتج للعميل وتثبيته. في كثير من الأحيان ، تحدث جولة اختبار للتأكد من نجاح التثبيت. بعد تسليم المنتج ، يتم إجراء الصيانة والدعم لضمان استمرار المنتج في العمل كما هو مُصمم.

مزايا الشلال

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

إذا تم تطبيقه على النوع الصحيح من المشروع ، فإن بعض مزايا نموذج الشلال:

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

عيوب الشلال

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

تشمل عيوب نموذج الشلال ، والتي تتمحور في الغالب حول عدم قدرته على التكيف مع التغيير ، ما يلي:

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

التسليم السريع المنضبط (DAD)

تم إضفاء الطابع الرسمي على التسليم السريع المنضبط (DAD) من قبل سكوت أمبلر في شركة IBM و Mark Lines وتوسعت على أطر العمل المرنة والمرنة ، مع الاعتراف بأن الأجزاء غير الرشيقة من المنظمة تشارك عادة في بعض القدرات في تقديم مشروع برمجي. يتضمن هذا الإطار بشكل صريح أنشطة من عمليات تكنولوجيا المعلومات ، وبنية المؤسسة ، وإدارة المحافظ ، والتمويل ، والمشتريات في دورة حياة التسليم الكاملة. يهدف DAD إلى زيادة سرعة الأعمال بشكل عام بطريقة عملية.

المبادئ والمكونات الرئيسية

الأدوار

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

الأدوار الأساسية:

1. أصحاب المصلحة: شخص يعتمد على فريقك الذي ينهي المشروع: عميل أو مستخدم نهائي أو زميل داخلي.
2. عضو الفريق: الأشخاص داخل الفريق الذي يقوم بالفعل بالعمل المخطط له: المطورين والمصممين والمختبرين ، إلخ.
3. قائد الفريق: على غرار سيد سكرم ، يعمل قائد الفريق كقائد خادم للفريق من خلال إزالة العوائق ، وتسهيل تماسك الفريق ونشر القيم الرشيقة.
4. مالك المنتج: يُشار إليه أحيانًا باسم "صوت العميل". يمثل مالك المنتج أصحاب المصلحة ويحافظ على قائمة أولويات العمل الذي يتعين القيام به.
5. مالك العمارة: مسؤول عن التخفيف من مخاطر العمارة على نطاق واسع. عادة ما يتم شغل هذا الدور من قبل مطور كبير داخل الفريق لأنه يتطلب خلفية تقنية عميقة ومعرفة قوية بمجال الأعمال.

الأدوار الثانوية:

1. أخصائي: الأشخاص الذين ينضمون إلى الفريق مؤقتًا للمساعدة في دور متخصص. على سبيل المثال ، قد ينضم محلل البيانات لتوفير إمكانات بحثية في المراحل الأولى من المشروع.
2. خبير المجال: مستشارو الضرائب والمستشارون القانونيون وغيرهم من الأشخاص الذين لديهم خبرة في المجال ويساعدون الفريق في التحديات ذات الصلة.
3. خبير تقني: مسؤول قاعدة بيانات ، خبير أمان ، خبير بناء ، إلخ. يساعد هؤلاء الأشخاص أعضاء الفريق الأكثر عمومية في النقاط الرئيسية في دورة الحياة.
4. المُختبِر المستقل: بينما يكون المُختبِرون عادةً جزءًا من الفريق الرئيسي ، في بعض الحالات ، فإن المتطلبات التنظيمية للحياة أو الأنظمة المعقدة للغاية ، يعمل المُختبِرون المستقلون بالتوازي للتحقق من صحة عمل التسليم.
5. عامل التكامل: على نطاق واسع ، تعمل فرق مختلفة على أجزاء مختلفة من النظام بأكمله. يساعد المُتكامل الفريق على دمج الجزء الخاص به مع النظام بأكمله وإدارة التبعيات.

دعم دورة الحياة

تروج DAD لدورة حياة كاملة للتسليم ، ليس فقط جزء البرمجة والإصدار الذي يغطيها Agile / scrum ، ولكن أيضًا مرحلة البداية حيث يتم تحديد رؤية المشروع والموافقة عليها ومراحل الدعم والتقاعد بعد الإصدار. حاليًا ، يدعم DAD 6 دورات حياة مختلفة:

• The Agile Lifecycle: دورة حياة مشروع مبنية على Scrum
• The Lean Lifecycle: دورة حياة مشروع قائم على كانبان
• التسليم المستمر: دورة حياة رشيقة
• التسليم المستمر: دورة حياة بسيطة
• دورة الحياة الاستكشافية (بدء التشغيل البسيط)
• دورة حياة البرنامج لفريق من الفرق

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

أهداف العملية

يستخدم DAD نهجًا يحركه الهدف لإنشاء وتكييف العمليات الرشيقة. يحدد مؤلفو هذه المنهجية 21 عملية من أهم العمليات وأكثرها شيوعًا والتي ستواجهها معظم الفرق خلال دورات حياتها.

كل هذه العمليات لديها نقاط قرار موثقة تتطلب من الفريق أن يقرر كيفية هيكلة هذه العملية. توفر كل نقطة قرار تقنيات أو ممارسات مقترحة يمكن استخدامها لتنفيذ القرار. يمكنك رؤية مثال على ذلك في الصورة أدناه. عملية "تطوير رؤية مشتركة" لها 6 قرارات يجب اتخاذها. لكل من هذه القرارات من 2 إلى 5 ممارسات مقترحة. تشير الأسهم إلى أن مؤلفي DAD قد طلبوا القائمة مع كون العنصر العلوي هو أفضل ممارسة والعنصر السفلي هو أسوأ ممارسة في هذه القائمة. يشير النص _ المائل الغامق_ إلى نقاط بداية جيدة للفرق الجديدة ، التي بدأت للتو مع DAD.

تحجيم الأب

يقترب التسليم السريع المنضبط من القياس من زاويتين مختلفتين:

• خفة الحركة التكتيكية على نطاق واسع

• خفة الحركة الاستراتيجية على نطاق واسع

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

تحاول خفة الحركة الاستراتيجية معالجة التوسع من خلال تطبيق استراتيجيات رشيقة وخفيفة على نطاق واسع عبر المنظمة بأكملها من خلال توسيع إطار العمل لمعالجة مجالات مختلفة من المنظمة:

• DevOps المنضبط: يغطي استخدام DevOps لتقديم نتائج أكثر فعالية للمؤسسة.

• Agile IT (DAIT) المنضبط: يغطي كيفية تطبيق استراتيجيات Agile and lean على جميع جوانب تكنولوجيا المعلومات.

• مؤسسة رشيقة منضبطة :. يغطي كيفية تطبيق Lean و Agile في جميع أنحاء المؤسسة.

آمنة

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

كانت بداية SAFe هي كتاب Dean Leffingwell "Scaling Software Agility: Best Practices for Large Enterprises" ، الذي نُشر في عام 2007. Leffingwell هو الآن كبير المتخصصين في منهجية SAFe ، لكن العديد من الأشخاص الآخرين يساهمون أيضًا في هذا الإطار. حاليًا ، في الإصدار 4.6 ، يشبه إطار العمل هذا منتجًا برمجيًا مع الإصدارات والتوافق مع الإصدارات السابقة ومكونات مختلفة.

المبادئ والمكونات الرئيسية

الهدف الأساسي لـ SAFe هو تسهيل إنشاء ونمو مؤسسة Lean لأنها تدرك أن العديد من الأنواع المختلفة من الشركات هي ، جزئيًا ، شركات برمجيات تحتاج إلى تقديم قيمة باستمرار في أقصر فترة زمنية مستدامة.

تحاول SAFe for Lean Enterprises إنشاء مؤسسة Lean من خلال توفير قاعدة معرفية للمبادئ والكفاءات وأفضل الممارسات التي أثبتت جدواها.

يحدد SAFe 4.6 خمسة كفاءات أساسية للمؤسسة اللينة. كل كفاءة عبارة عن مجموعة من المعارف والمهارات والسلوكيات ذات الصلة ، والتي تمكن المؤسسات معًا من التفوق:

1. قيادة Lean-Agile : تصف كيف يقود القادة التغيير التنظيمي ويحافظون عليه من خلال التعلم والتعليم وتطبيق عقلية SAFe Lean-Agile.

2. سرعة الفريق والتقنية : يصف المهارات والمبادئ والممارسات اللازمة لإنشاء فرق أجايل عالية الأداء.

3. DevOps والإصدار عند الطلب : يصف كيف أن تنفيذ DevOps وخط أنابيب التسليم المستمر يوفران للمؤسسات القدرة على إصدار زيادات في المنتج في أي وقت ضروري لتلبية الطلب.

4. حلول الأعمال وهندسة الأنظمة الخالية من الهدر: يصف كيفية تطبيق مبادئ وممارسات Lean-Agile على مواصفات تطبيقات البرامج الكبيرة والمعقدة وتطويرها ونشرها وتطورها

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

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

كفاءة القيادة المرنة

الهدف الأساسي لكفاءة القيادة المرنة والمرنة هو المساعدة في تحويل المنظمة إلى مؤسسة رشيقة. يتم ذلك عن طريق التعلم والممارسة والتدريس عقلية وقيم ومبادئ وممارسات SAFe Lean-Agile.

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

1. المحاذاة : توصيل المهمة واستراتيجية المحفظة ورؤية الحل. قم بإجراء الإحاطات ذات الصلة ، والمشاركة في تخطيط زيادة البرنامج (PI) وصيانة الأعمال المتراكمة.

2. الشفافية : تصور كل الأعمال ذات الصلة.

3. الجودة المضمنة: الانخراط في الممارسات لتقديم الجودة طوال دورة الحياة. رفض قبول العمل منخفض الجودة. دعم الاستثمارات في الصيانة وخفض الديون الفنية.

4. تنفيذ البرنامج : المشاركة كأصحاب أعمال في تنفيذ PI وإثبات قيمة الأعمال. تأكد من أن النطاق يتماشى مع الطلب والقدرة. إزالة العوائق والمثبطات بقوة.

يتم دعم القيم الأساسية لـ SAFe من خلال تبني عقلية Lean-Agile وتطبيق مبادئ SAFe:

1. خذ وجهة نظر اقتصادية

2. تطبيق التفكير المنظومي

3. افترض التباين الحفاظ على الخيارات

4. قم بالبناء بشكل تدريجي باستخدام دورات تعلم سريعة ومتكاملة

5. ضع المعالم على تقييم موضوعي لأنظمة العمل

6. تصور العمل قيد التقدم والحد منه ، وتقليل أحجام الدُفعات ، وإدارة أطوال قائمة الانتظار

7. تطبيق الإيقاع والمزامنة مع التخطيط عبر النطاقات

   

8. أطلق العنان للدوافع الجوهرية للعاملين في مجال المعرفة

9. لامركزية صنع القرار

تشبه هذه المبادئ مبادئ Lean و Agile. أخيرًا ، يتم إنجاز تحويل المنظمة باتباع خارطة طريق التنفيذ الآمن.

كفاءة الفريق والرشاقة الفنية / مستوى الفريق

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

• رشاقة الفريق : تتبنى الفرق ممارسات ومبادئ Agile ، والتي تمكنهم من العمل والتعلم والتكيف مع إيقاع موثوق به

• المرونة التقنية : تطبق الفرق الممارسات التقنية الرشيقة التي تضمن جودة الكود والمكونات ، وقابلية الحفاظ على الكود الذي ينتجهون. الجودة هي تركيز كبير في الفريق وكفاءة المرونة التقنية. لتحقيق ذلك ، يتم تطبيق تقنيات الهندسة الرشيقة مثل التطوير المدفوع بالسلوك (BDD) والتطوير القائم على الاختبار (TDD) لزيادة الجودة والتدفق. يعتمد التدفق السريع على جودة البناء في جميع أنحاء النظام حيث يمكن أن تؤثر الأخطاء بشدة على التدفق وتؤخر عمليات التحرير.

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

DevOps والإفراج عن الكفاءة عند الطلب / مستوى البرنامج

تصف DevOps و Release on Demand Competency كيف أن "تنفيذ DevOps وخط أنابيب التسليم المستمر يوفران للمؤسسة القدرة على إصدار القيمة ، كليًا أو جزئيًا ، في أي وقت ضروري لتلبية متطلبات السوق والعملاء."

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

• توفر DevOps نهج الثقافة والأتمتة والتدفق الخفيف والقياس والاسترداد (CALMR) الذي يتيح التسليم المستمر والإصدار عند الطلب

• قطارات الإطلاق الرشيقة (ARTs) هي فرق من فرق أجايل منظمة لتقديم قيمة عند الطلب عبر خط أنابيب توصيل مستمر

يصف مستوى البرنامج في الرسم التخطيطي الأدوار والأنشطة اللازمة للتسليم المستمر عبر قطار الإصدار السريع (ART) . يعمل هذا المستوى بطريقة تكرارية مماثلة لمستوى الفريق ولكنه يدمج فرق أجايل متعددة ويتضمن المزيد من الدورات. ART عبارة عن فريق رشيق من فرق يتألف من 5 إلى 12 فريقًا (50 إلى 125 شخصًا) بما في ذلك الأدوار الرشيقة التقليدية بالإضافة إلى الأدوار الحاسمة في البرنامج مثل مهندس قطار الإصدار (RTE) وإدارة المنتج. يقدم ART زيادات في البرنامج (PI) من 8 إلى 12 أسبوعًا يتم التخطيط لها عبر تخطيط PI ويقودها مدير المنتج .

يتم تتبع التقدم المحرز في ميزات PI والملاحم وما إلى ذلك وإدارتها عبر لوحة برنامج Kanban. يعمل RTE باعتباره Scrum Master في ART. تتضمن اجتماعات المزامنة اليومية للفريق Daily Standups و Scrum-of-Scrums (RTE & Scrum Masters) و PO Sync (إدارة المنتج ومالكي المنتجات) و ART Sync (Scrum-of-Scrums و PO Sync معًا). يحتوي كل الباحث الرئيسي على عرض توضيحي للنظام واستعراض بأثر رجعي.

كفاءة حلول الأعمال وهندسة النظم اللينة / مستوى الحلول الكبيرة

تصف حلول الأعمال وكفاءة هندسة الأنظمة اللينة "كيفية تطبيق مبادئ وممارسات Lean-Agile لمواصفات وتطوير ونشر وتطور تطبيقات البرامج الكبيرة والمعقدة والأنظمة الفيزيائية السيبرانية".

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

يحتوي مستوى الحل الكبير على الأدوار والتحف والعمليات اللازمة لبناء حلول كبيرة ومعقدة. تعمل العديد من تقنيات ART معًا في قطارات الحلول لتقديم الحلول . الأهداف الأساسية هي:

• إدارة التكامل المتكرر

• معالجة مخاوف الامتثال باستمرار

• مهندس للمقياس ، والنمطية ، وقابلية الإصدار ، وإمكانية الخدمة

تتحكم إدارة الحلول في محتوى الحل ويوجه مهندس تدريب الحلول (STE) العمل. مهندس الحلول مسؤول عن الحفاظ على بنية جيدة لجميع ARTs في الحل. يتم استخدام تخطيط ما قبل وما بعد PI لتخطيط الحلول المقدمة عبر زيادات متعددة في البرنامج. يحتوي A Solution Backlog على إمكانيات وملاحم للحلول ويتم تعقبها عبر لوحة كانبان الحل

مستوى المحفظة / كفاءة إدارة المحافظ الضعيفة

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

تركز إدارة المحافظ الخالية من الهدر على المجالات التالية:

1. الإستراتيجية والتمويل الاستثماري: يربط المحفظة باستراتيجية المؤسسة ، وتدفق قيمة الأموال ، ويؤسس تدفق المحفظة

2. عمليات محفظة رشيقة: تنسق تدفقات القيمة ، ودعم تنفيذ البرامج ، والتميز التشغيلي

3. الحوكمة الرشيقة: تتنبأ بالميزانيات ، وتقيس أداء المحفظة ، وتفرض الامتثال

يحتوي مستوى المحفظة على المبادئ والممارسات والأدوار اللازمة لبدء وإدارة مجموعة من تدفقات قيمة التنمية. يحتوي Portfolio Backlog على Business Epics و Enabler Epics ويتم تعقبه عبر لوحة Portfolio Kanban *. ** تقرر إدارة المحفظة الخالية من الهدر (Lean Portfolio Management) ما هي تدفقات القيمة الموجودة في المحفظة وتتضمن أعلى صانعي القرار في المؤسسة. يوجه مهندس المؤسسة العمل وينسق عبر Value Streams.

أقل

تم إنشاء إطار عمل سكرم واسع النطاق (LeSS) بواسطة Craig Larman و Bas Vodde ، اللذين استندا إلى خبرتهما في الصناعات المالية والاتصالات السلكية واللاسلكية. كما يوحي الاسم ، يشجع LeSS على وجود أقل عدد ممكن من العمليات والإجراءات لجعل العديد من فرق Scrum تعمل معًا. القياس صعب لأن الناس يجعلونه معقدًا ، لذا فإن الهدف هنا هو جعله بسيطًا قدر الإمكان.

المبادئ والمكونات الرئيسية

"LeSS هو Scrum ، يتم تطبيقه على العديد من الفرق ، والعمل معًا ، على منتج واحد". يعتمد LeSS على عشرة مبادئ ستبدو مألوفة لأي شخص على دراية بمبادئ Lean-Agile:

1. Scrum على نطاق واسع هو سكرم

2. التحكم في العملية التجريبية

3. الشفافية

4. المزيد مع القليل

5. التركيز على المنتج بالكامل

6. تتمحور العملاء

7. التحسين المستمر نحو الكمال

8. التفكير المنهجي

9. التفكير الهزيل

10. نظرية الطابور

لدى LeSS دورين رئيسيين فقط ، وكلاهما مستعار من Scrum:

1. مالك المنتج: يعمل مع 2-8 فرق.
2. سيد سكرم: يعمل مع 1-3 فرق.

تعمل جميع الفرق مع نفس المنتج المتراكم في سباقات السرعة من 1 إلى 4 أسابيع. تعمل الفرق بالتوازي ، مما يعني أنها تبدأ وتنتهي في نفس الوقت. في نهاية السباق ، تقدم الفرق مجتمعة زيادة في المنتج . قد يبدو من المستحيل تقريبًا أن يعمل مالك منتج واحد مع 8 فرق. يعزز LeSS نقل مسؤولية توضيح عنصر تراكم المنتج إلى الفرق. في المقابل ، يجب أن تكون الفرق متعددة الوظائف ولا تحتوي فقط على كفاءات الترميز والتصميم والاختبار ولكن أيضًا على معرفة مجال الأعمال. والأهم من ذلك ، يجب تمكين الفرق لتكون قادرة على الوصول إلى العملاء.

Sprint Planning

ينقسم التخطيط إلى قسمين:

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

صقل تراكم المنتج

يتم تحسين تراكم المنتج (PBR) أثناء السباق لإعداد عناصر تراكم المنتج للتخطيط السريع. لا تقدم LeSS قواعد حول كيفية القيام بـ PBR وتترك الأمر للشركات لمعرفة أكثر عملياتها فاعلية بأنفسهم. تتضمن PBR ثلاثة أنشطة رئيسية:

1. تقسيم العناصر الكبيرة.
2. تفصيل العناصر حتى جاهزة.
3. تقدير.

نهاية السباق

في نهاية كل سباق ، تحدث ثلاثة أشياء:

1. مراجعة Sprint: عرض توضيحي مشترك لـ Sprint ، حيث تستكشف الفرق والعملاء ما تم القيام به أثناء Sprint وما يجب القيام به بعد ذلك.
2. بأثر رجعي: يحتفظ كل فريق بأثر رجعي لتحسين العملية.
3. بأثر رجعي شامل: تجتمع الفرق وأصحاب المنتجات وأساتذة سكروم معًا لفحص الممارسات التنظيمية وتكييفها لتكون أكثر فاعلية.

Scrum @ مقياس

يتم استخدام Scrum at Scale و Scrum @ Scale بالتبادل. تم تقديم هذه المنهجية بواسطة Jeff Sutherland في عام 2014 ، الذي أنشأ منهجية Scrum وكان أحد الموقعين على بيان Agile.

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

المبادئ والمكونات الرئيسية

Scrum @ Scale هو إطار عمل يبسط بشكل جذري القياس باستخدام Scrum لتوسيع Scrum. في سكروم ، "ماذا" (مالك المنتج) منفصل بوضوح عن "كيف" (سيد سكرم). يتم استخدام نفس الإستراتيجية في Scrum @ Scale بحيث يتم فهم الاختصاص والمساءلة جيدًا ، والقضاء على الهدر والصراع.

يحتوي Scrum @ Scale على دورتين لفصل السلطات القضائية بوضوح: دورة Scrum Master ودورة مالك المنتج بنقطتي اتصال: عملية مستوى الفريق وملاحظات إصدار المنتج.

دورة سكرم ماستر

دورة سكروم الرئيسية هي المسؤولة عن كيفية بناء الأشياء التي حددتها دورة مالك المنتج. في Scrum @ Scale ، يكون لفرق Scrum الفردية نفس الأدوار والتحف والأنشطة والاحتفالات مثل Scrum التقليدية.

يتم تجميع فرق Scrum في Scrum of Scrums (SoS) والتي تكون مسئولة بشكل مشترك عن إنتاج زيادة مشتركة في المنتج. يشاركون في الاستمالة المشتركة المتراكمة وتحديد الأولويات ، وعقد استعادات ، والحفاظ على تراكم العوائق ، ولديهم Scaled Daily Scrum (SDS) (مماثل في التنسيق إلى scrum اليومي) لتنسيق الفرق وإزالة حواجز الطرق. يحضر SDS ممثل واحد على الأقل (عادةً ما يكون رئيس سكرم للفريق) لكل من الفرق المشاركة ويقودها Scrum of Scrums master (SoSM) المسؤول عن التنسيق مع فرق سكرم وأصحاب المنتج.

إذا كانت هناك حاجة إلى مزيد من التحجيم ، فهناك مجموعة من سكراميل (SoSoS) التي تم إنشاؤها من عدة SoS والتي ستلتقي أيضًا يوميًا ، وما إلى ذلك. القائد العام هو فريق العمل التنفيذي (EAT) المسؤول عن تعزيز Agile في المنظمة ، وتنسيق فرق Scrum حسب الحاجة ، وكونها المحطة النهائية لإزالة العوائق.

دورة مالك المنتج

تكون دورة مالك المنتج مسؤولة عن المنتج أو الخدمة التي سيتم إنشاؤها وجميع الأنشطة اللازمة لدعم ذلك. يتم تعيين مالكي المنتجات لفرق Scrum ويقومون بجميع أنشطة دورهم كما هو محدد في Scrum. يتم تجميع مالكي المنتجات في فرق مالك المنتج التي يتم تعيينها إلى فرق SoS. تجتمع فرق مالك المنتج يوميًا في Meta Scrum لمناقشة استراتيجية عالية المستوى للفرق ، والتنسيق حسب الحاجة مع SoSM المقابل ومالكي المنتجات وأصحاب المصلحة الآخرين .. يقود Meta Scrums مالك المنتج الرئيسي (CPO) .

يتوسع مالكو المنتجات بطريقة مشابهة للدورة الرئيسية سكروم ، اعتمادًا على حجم المؤسسة ويبلغ ذروته في Meta Scrum التنفيذية (EMT) ، المسؤولة عن تحديد الأولويات على مستوى الشركة.

تنفيذ Scrum @ Scale

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

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

خاتمة

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

نظرًا لأن الشركات تواجه مشاريع أكبر وأكثر تعقيدًا بمتطلبات أو أهداف متغيرة باستمرار ، فإنها تتطلع إلى نهج أكثر رشاقة. نظرًا لأن Agile كان مخصصًا في الأصل للفرق الصغيرة المكونة من 5-9 أشخاص ، فقد أتى العديد من ممارسي Agile بطرق متعددة لتوسيع نطاق Agile من فرق فردية إلى فرق متعددة إلى المؤسسة بأكملها. في هذه المقالة ، قمنا بتغطية التسليم السريع المنضبط (DAD) ، وإطار العمل الرشيق المتدرج (SAFe) ، و Scrum على نطاق واسع (LeSS) ، و Scrum @ Scale.

في الجزء الأخير من مخطط إدارة المشروع ، سنغطي عددًا قليلاً من أطر إدارة المشاريع المحددة مثل PMP (PMBOK) و PRINCE2. سنستعرض أيضًا بعض عمليات وأطر الابتكار مثل "الوظائف التي يتعين القيام بها" (JTBD) و "التفكير التصميمي".