آمن أو تحجيم إطار رشيق

ما هو آمن؟

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

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

واحدة من مزايا وعيوب SCRUM المهمة ، أعتبر أن الحجم المحدد للأوامر هو 7 + -2 (أو 3-9 بيانات أحدث من دليل Scrum ) بما في ذلك مالك المنتج.
بالطبع ، هناك 9 من المهنيين الراقيين والمتحمسين لديهم الكثير ، لكن في بعض الأحيان يكون من الضروري بناء شيء ما مع عدد كبير من الأيدي والرؤوس والعينين والأدمغة في النهاية. لتضخيم الفرق أمر سيء ، لذلك يجب زيادة عددهم ، وهنا تبرز مشكلة التواصل بين الفرق وتزامن العمل و SCRUM نفسها لا تقدم أي حل لهذه المهام. هناك محاولات لاستخدام SCRUM على مستوى إدارة أوامر SCRUM (كما ينصح جيف ساذرلاند ، أحد مؤلفي بيان Agile ،) ، هناك Scale Scrum ، وهناك منضبطة Agile Delivery ، هناك أكثر من ذلك بكثير ، ولكن هناك أيضًا SAFe - Scaled Agile Framework.

SAFe هو إطار عمل لإدارة الشركة يتطلب تنسيق العمل في مشروع معين أو مشاريع ذات صلة لـ 5 أو أكثر من فرق SCRUM. أي هذا هيكل فائق فوق SCRUM يسمح لك بإدارة فرق تضم 100 شخص أو أكثر

فائدة؟

بادئ ذي بدء ، بالطبع ، هناك حاجة إلى المنهجية من قبل أولئك الذين يبيعونها ويشاركون في التدريب. تحدث ديف توماس (أحد مؤلفي أجيل مانيفستو) جيدًا عن هذا الموضوع في معرض GOTO 2015 في عرضه Agile is Dead

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

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

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

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

جوهر

SAFe هي كعكة طبقة من مختلف تقنيات Agile. في المستوى السفلي ، يوجد SCRUM التقليدي تقريبًا ، مع سباق أسبوعين إلى ثلاثة أسابيع نموذجي ، وفرق من 3-9 أشخاص بما في ذلك مالك المنتج. جميع الطقوس النموذجية ، بدءا من التخطيط اليومي - الاستعداد وتنتهي مع استخلاص المعلومات بأثر رجعي. على الرغم من وجود اختلاف رئيسي واحد. توقف الأمر ليكون وحدة مستقلة تعمل بكامل طاقتها. وتوقف السباق لتكون فترة زمنية مستقلة مع دورة حياة كاملة. يتم الجمع بين سباقات السرعة في برنامج الزيادات التي تتكون عادة من 5 سباقات السرعة. أي إذا كنا في SCRUM الكلاسيكية لم نبني ما يحبه العميل ، فسنقوم بتصحيح المسار في السباق التالي ، ثم في SAFe نستمر في التوجه نحو الحافة حتى نهاية برنامج التزايد ، وفي أسوأ الأحوال ، الأربعة سباقات التالية (بالطبع سأبالغ فيها).

في المستوى التالي ، لدينا قطارات - ما يسمى قطار الإصدار الرشيق. هناك وظائف جديدة لإدارة 5 قطاعات سباق: مهندس نظام (الشخص الذي يمتلك الهيكل - أي أنه لم يعد فريقًا) ، مدير المنتج (الشخص الذي يتحكم في المنتج ، وليس مالك المنتج ، والأخير يذهب إلى مدير الإدارة للحصول على المشورة) و RTE - نفس PMP من العالم البعيد من الشلال. هنا ، يتم تطبيق بعض التطورات من Kanban ، على وجه الخصوص ، لوحة ، طريقة لتعيين الأولويات ، وبشكل عام ، مبدأ قياس الأداء التاريخي للفرق (السرعة) وتوقع ما سيتم بناؤه في نهاية الفاصل الزمني بدلاً من النهج مع التقديرات وتعيين المواعيد النهائية لوظائف ثابتة بالفعل ( نطاق). أحد الابتكارات هو أن آخر سباق 5 هو إعلان تنظيمي وخلاله يتم عقد اجتماعات ضخمة (جميع الفرق معًا - وهذا هو 100 شخص أو أكثر) ، ويتم إجراء تحليل للدين الفني ، ووضع خطط لتطوير الهندسة المعمارية ومزامنة عمل جميع الفرق.

فوق مستوى القطار ، لدينا التنسيق بين الإدارات والمديرين والعميل. هناك المزيد من الاقتراض من Lean Agile ، ولكن يتم الحفاظ على الأدوات نفسها من Kanban. هذا تحليل للجدوى الاقتصادية للتغيير. من الناحية المثالية ، تمر أي تغييرات من خلال تحليل أولي حيث يتم فرض فرضية قابلة للقياس حول التغيير القادم (على سبيل المثال ، إذا قمنا بإنشاء متجر عبر الإنترنت من مركز بيانات إلى الشبكة السحابية ، ثم زيادة السعات بسرعة في ذروة المبيعات الموسمية يمكننا زيادة عدد المعاملات بنسبة 10 ٪) ثم يتم تأكيد هذه الفرضية إما لا بالنسبة للشركات التي تقل قيمتها عن مليار دولار - قد يكون هذا هو الدور الأخير. يتم وضع خطط عمل لمدة تتراوح بين 12 و 36 شهرًا (مرحباً ، خطط الخمس سنوات للجودة والكمية ، إلخ.)

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

بقيادة الاستراتيجية كلها. لم يتم وصف الطريقة التي تم تعريفها من قبل الإطار.

الايجابيات

1. عدد كبير من الأدوات الجيدة جدًا (WSJF ، Kanban ، Gemba ، إلخ)
2. يضفي الطابع الرسمي ويصف خطوات SDLC من كتابة التعليمات البرمجية (المنصوص عليها في TDD) إلى إجراء عمليات المسح الثابتة و CI / CD وتبديل الميزة. ما إذا كان كل من الممارسات جيدة أم لا هو سؤال آخر ، ولكن على الأقل هناك خطة ويتبعها الجميع.
3. يمكن فهم العملية وتفسيرها وتنفيذها.
4. يتلقى كل شخص في إطار هذه العملية وظيفة محددة بدقة إلى حد ما.
5. يزيد من شفافية الشركة لأولئك الذين يعملون فيها.

العيوب

1. وقت طويل بما يكفي للرد على عدم تطابق الواقع مع التوقعات
2. يتم إنفاق مبلغ كبير من المال والمال على التواصل والاجتماعات
3. غالبًا ما تكون الحلول الموصى بها ضمن الإطار قديمة

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