مخطط إدارة المشروع الجزء 1: مقارنة شاملة بين Agile و Scrum و Kanban و Lean

ملخص

تستخدم العديد من المنهجيات في تطوير البرمجيات اليوم. ربما سمعت كلمات طنانة مثل Waterfall و Agile و Scrum و Kanban و Lean و Extreme Programming ، إلخ.

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

منهجية العجاف

أصول التصنيع الهزيل والضعيف

نشأ مصطلح "Lean" في التصنيع حيث تمت صياغته لوصف نموذج التصنيع المستند إلى نظام إنتاج Toyota (TPS) الذي طوره في الأصل Sakichi Toyoda و Kiichiro Toyoda و Taiichi Ohno الذين استلهموا في الأصل من هنري فورد. ركزت TPS على فلسفة "التخلص الكامل من جميع النفايات" وأحدثت ثورة في التصنيع في الخمسينيات وحتى السبعينيات. أصبحت TPS تُعرف باسم "Lean Manufacturing" في عام 1990 عندما تم نشر "الآلة التي غيرت العالم".

حددت TPS ثلاثة أنواع واسعة من النفايات في تويوتا:

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

  • المعالجة الزائدة: من سوء استخدام الأدوات أو تصميم المنتج

• موري: تُرجمت على أنها "تثقل كاهل". ينتج الموري عادةً عن mura ولكن يمكن أن ينتج عن muda. تتجلى موري نفسها في حالات الأعطال والتغيب وقضايا السلامة وما إلى ذلك.
• مورا: تُرجمت على أنها "تفاوت". يمكن العثور على Mura في التقلبات في طلب العملاء ، أو أوقات المعالجة لكل منتج أو اختلاف أوقات الدورات لمشغلين مختلفين. عندما لا يتم تقليل mura ، يزيد المرء من احتمالية حدوث Muri وبالتالي Muda. يمكن تقليل Mura من خلال خلق الانفتاح في سلسلة التوريد ، وتغيير تصميم المنتج ، وإنشاء عمل قياسي لجميع المشغلين.

عملت TPS على التخلص من النفايات من خلال تطبيق هذين المفهومين الأساسيين:

• Jidoka: ترجمت بشكل فضفاض إلى "أتمتة بلمسة إنسانية" تنص على أن "الجودة يجب أن تُبنى أثناء عملية التصنيع!" مما يعني أنه عند حدوث مشكلة ، تتوقف المعدات على الفور ، مما يمنع إنتاج المنتجات المعيبة.
• في الوقت المناسب: صنع فقط "ما هو مطلوب ، عند الحاجة ، وبالمقدار المطلوب".

مع تطور TPS ، بُنيت هذه الركائز والقيم الأساسية على مفاهيم Jidoka و JIT وأصبحت راسخة:

• تحسن مستمر:
  • التحدي: تكوين رؤية بعيدة المدى ومواجهة التحديات بشجاعة وإبداع لتحقيق الأحلام
  • كايزن: تحسين العمليات التجارية بشكل مستمر ، والسعي دائمًا للابتكار والتطور ، والقضاء على مشكلة واحدة في كل مرة
  • Genchi Genbutsu: ممارسة genchi genbutsu ، والذهاب إلى المصدر للعثور على الحقائق لاتخاذ القرارات الصحيحة ، وبناء الإجماع ، وتحقيق الأهداف بأفضل سرعتنا
• احترام الناس:
  • الاحترام: احترام الآخرين وبذل قصارى جهدنا لفهم بعضنا البعض ، وتحمل المسؤولية وبذل قصارى جهدنا لبناء الثقة المتبادلة
  • العمل الجماعي: تحفيز النمو الشخصي والمهني ، ومشاركة فرص التطوير ، وتعظيم الأداء الفردي والجماعي
• Andon: مؤشر مرئي للوضع أو المشكلة
• Heijunka: يعني التسوية أو تسوية الإنتاج
• هانسي: يعني التأمل الذاتي. لتحسين الكفاءة ، يجب على العمال تحدي الافتراضات الكامنة وراء العمليات الحالية للعثور على أفضل منها.
• كانبان: لافتة تستخدم كأداة مرئية للتحكم في الإنتاج
• Poka-yoke: يُشار إليه أيضًا باسم تدقيق الأخطاء أو تدقيق الأخطاء
• نظام السحب: يتم سحب المواد إلى محطة العمل كما هو مطلوب
• صعيري: هو المبدأ الذي يعكس الهدر. صعيري يفرض إزالة ما هو غير ضروري. هذا يشمل جميع النفايات السبع الأصلية من TPS
• التوحيد القياسي: ينظم جميع الوظائف المتعلقة بالحركة البشرية ويخلق تسلسلاً فعالاً للإنتاج بدون muda. هذا يساعد على تحقيق الجودة ، وتيرة ثابتة ، ويسمح بالتحسين المستمر.

يوضح الرسم البياني أدناه كيفية ارتباط المفاهيم الأساسية والقيم الأساسية ببعضها البعض.

الإدارة المنهجية

تطور نظام منتجات Toyota و Lean Manufacturing بمرور الوقت وتم تطبيقهما في عدد من المجالات بما في ذلك الإدارة.

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

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

تم إضفاء الطابع الرسمي على هذه المبادئ والجوانب الأخرى للإدارة اللينة عندما نشر Womack & Jones كتابه "Lean Thinking" في عام 1996.

تطوير البرمجيات العجاف

تم تطبيق Lean منذ ذلك الحين على الإدارة وتطوير البرمجيات وغيرها من المجالات.

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

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

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

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

في التسعينيات وأوائل القرن الحادي والعشرين ، نشر العديد من المؤلفين كتبًا حول تطبيق مبادئ اللين لتطوير البرمجيات. نشر الدكتور روبرت شاريت "Lean Software Development" في عام 1993 و "12 مبدأًا لتطوير برامج Lean" في عام 2003.

نشر توم وماري بوبينديك "Lean Software Development: An Agile Toolkit" في عام 2003. يعرض هذا الكتاب بالتفصيل سبعة مبادئ من Lean Development ، والتي ترتبط مباشرة بالأشكال السبعة للنفايات في Lean Manufacturing. تم توضيح أوجه التشابه والاختلاف بين المنشورين المختلفين Lean و Agile (التي تمت مناقشتها في القسم التالي) في الرسم التخطيطي أدناه.

الاختلافات بين Lean و Agile

وفقًا للدكتور شاريت ، فإن أحد الاختلافات الأساسية بين Lean و Agile هو أن Agile من أسفل إلى أعلى ، بينما Lean من أعلى لأسفل.

إطار رشيق

أصول Agile و Agile Manifesto

في نفس الوقت تقريبًا الذي نشر فيه Charette و Poppendiecks كتبهم ، تم إنشاء Agile Framework للمساعدة في حل نفس المشكلات. في فبراير 2001 ، اجتمعت مجموعة من رواد Agile في اجتماع Snowbird سيئ السمعة في Snowbird ، يوتا لمحاولة التوصل إلى حل.

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

ينص بيان Agile على ما يلي:

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

• الأفراد والتفاعلات على العمليات والأدوات
• برنامج العمل على التوثيق الشامل
• تعاون العملاء على التفاوض على العقد
• الاستجابة للتغيير على اتباع خطة

أي ، بينما توجد قيمة في العناصر الموجودة على اليمين ، فإننا نقدر العناصر الموجودة على اليسار أكثر. "

تتماشى القيم الموجودة في البيان مع المبادئ الاثني عشر وراء بيان Agile:

"نحن نتبع هذه المبادئ:

1. أولويتنا القصوى هي إرضاء العميل من خلال التسليم المبكر والمستمر للبرامج القيمة.
2. نرحب المتطلبات المتغيرة، حتى وقت متأخر في التنمية. تسخر العمليات الرشيقة التغيير من أجل الميزة التنافسية للعميل.
3. قم بتوصيل برامج العمل بشكل متكرر ، من أسبوعين إلى شهرين ، مع تفضيل على النطاق الزمني الأقصر.
4. يجب أن يعمل رجال الأعمال والمطورين معًا يوميًا طوال فترة المشروع.
5. بناء مشاريع حول دوافع الأفراد. امنحهم البيئة والدعم الذي يحتاجون إليه ، وثق بهم لإنجاز المهمة.
6. الطريقة الأكثر كفاءة وفعالية لنقل المعلومات إلى فريق التطوير وداخله هي المحادثة وجهًا لوجه.
7. يعمل البرنامج هو المقياس الأساسي للتقدم. عمليات رشيقة تعزز التنمية المستدامة.
8. يجب أن يكون الرعاة والمطورون والمستخدمون قادرين على الحفاظ على وتيرة ثابتة إلى أجل غير مسمى.
9. الاهتمام المستمر بالتميز التقني والتصميم الجيد يعزز خفة الحركة.
10. البساطة - فن تعظيم حجم العمل غير المنجز - أمر ضروري.
11. تظهر أفضل الهياكل والمتطلبات والتصاميم من فرق ذاتية التنظيم.
12. على فترات منتظمة ، يفكر الفريق في كيفية أن يصبح أكثر فاعلية ، ثم يقوم بضبط سلوكه وتعديله وفقًا لذلك ".

القيم والمبادئ المذكورة أعلاه هي تطبيقات لمبادئ Lean مثل Jidoka و JIT و Genchi Genbutsu و Kaizen و Hansei و Heijunka وتقليل النفايات.

تطبيق المبادئ الرشيقة على تطوير البرمجيات

Agile هو إطار شامل ينطبق على أي عملية تطبق مجموعة Agile من القيم والمبادئ.

بعض الأمثلة هي:

• البرمجة المتطرفة
• سكرم
• كانبان

سكرم

تاريخ موجز للحثالة

Scrum هو إطار عمل يطبق مبادئ Agile التي تم اختراعها بشكل منفصل من قبل عدة أشخاص ، وقع العديد منهم على بيان Agile:

• قدم هيروتاكا تاكيوتشي وإيكوجيرو نوناكا مصطلح "سكرم" في البداية في سياق التصنيع في ورقتهما البيضاء "لعبة تطوير المنتج الجديد". نُشر عام 1986 في مجلة Harvard Business Review.
• قام جيف ساذرلاند وجون سكومينيتاليس وجيف ماكينا بتنفيذ Scrum في شركة Easel Corporation في عام 1993.
• استخدم كين شوابر ما سيصبح سكرم في شركته ، أساليب التطوير المتقدمة في التسعينيات.

تعاونت Schwaber و Sutherland طوال التسعينيات لتطوير وتحسين إطار العمل في سياق تطوير البرمجيات ، وتحدثا في مؤتمرات مختلفة. عملت شوابر مع مايك بيدل لوصف الطريقة في كتاب "Agile Software Development with Scrum" في عام 2001.

استمر شوابر في إنشاء كل من المراجع المصدقة الرئيسية في Scrum:

• تحالف Scrum: تم إنشاؤه في عام 2001. إعداد سلسلة اعتماد Scrum المعتمدة.
• Scrum.org: تم إنشاؤه في عام 2009 بعد مغادرة Schwaber لتحالف سكرم. قم بإعداد سلسلة اعتماد Professional Scrum الموازية.

بمرور الوقت ، تم إنشاء العديد من أطر العمل / هيئات إصدار الشهادات لمعالجة توسيع إطار عمل Scrum للفرق والمشاريع الأكبر حجمًا حيث تم تصميم Scrum في الأصل للفرق الصغيرة (7 زائد أو ناقص 2 أعضاء):

• آمن: إطار رشيق متدرج
• LeSS: مقياس كبير Scrum
• Scrum @ scale: Scrum at Scale تم إنشاؤه بواسطة Jeff Sutherland

قيم سكروم

وفقًا لتحالف سكرم:

Scrum هي مجموعة بسيطة لكنها قوية بشكل لا يصدق من المبادئ والممارسات التي تساعد الفرق على تقديم المنتجات في دورات قصيرة ، وتمكين ردود الفعل السريعة ، والتحسين المستمر ، والتكيف السريع مع التغيير.

Scrum هو إطار عمل إلزامي ، تدريجي ومتكرر لتطوير البرمجيات التي تطبق مبادئ Agile. تم تحديد قيم ومبادئ Scrum في الرسوم البيانية أدناه ولها توافق كبير مع قيم ومبادئ Lean و Agile.

نظرة عامة على سكروم

ينقسم العمل إلى تكرارات قصيرة في مربعات زمنية تسمى سباقات السرعة والتي عادة ما تكون من أسبوع إلى ثلاثة أسابيع. هذا في تناقض صارخ مع التخطيط المتعمق للشلال. يتم اختيار العمل المخطط للسباق الحالي من أعلى مجموعة متراكمة ذات أولوية لعناصر العمل تسمى Product Backlog (Pull System ، Heijunka) ، ويتم إصلاحها بمجرد بدء السباق. الهدف هو الحصول على برنامج يعمل في نهاية كل سباق ، مما يتيح ردود فعل سريعة.

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

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

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

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

أدوار سكروم

Scrum له ثلاثة أدوار:

• Scrum Master : Scrum Master هو خادم قائد لفريق Scrum. إنهم مدرب الفريق الذي يساعد في تسهيل التعاون ، ويزيل العوائق ، ويفرض ويحمي عملية سكرم ، ويحمي الفريق. يعني هذا عادةً أنهم ينظمون ويسهلون طقوس العدو ، والتأكد من أن مالك المنتج لديه أولوية متراكمة معدة بشكل صحيح ، ويضمن عدم الضغط على الفريق للإفراط في الالتزام بالسباق ، ويضمن عدم إضافة النطاق إلى العدو السريع ، يضمن الالتزام بتعريف تم. لا يقومون بتعيين المهام لأعضاء الفريق (Genchi Genbutsu) وهم ليسوا مسؤولين عن تسليم المشروع
• مالك المنتج : مالك المنتج هو "العنق الوحيد القابل للعصر" المسؤول عن تسليم المنتج. يحدد مالك المنتج رؤية ما يريدون بناءه وينقل هذه الرؤية إلى الفريق والمؤسسة. يمتلك مالك المنتج متطلبات العمل والسوق ويعطي الأولوية لجميع الأعمال التي يجب القيام بها من خلال إنشاء وإدارة تراكم المنتج. يقررون الميزات التي سيتم شحنها ومتى. إنهم يعملون مع الفريق وأصحاب المصلحة الآخرين للتأكد من أن الجميع يفهم العناصر الموجودة في تراكم المنتج. يقبلون أو يرفضون العمل المنجز في سباق سريع في عرض السباق.
• عضو الفريق : فريق سكرم هو فريق منظم ذاتيًا متعدد الوظائف يتألف عادةً من خمسة إلى سبعة أعضاء. يعمل الجميع في المشروع معًا ويساعدون بعضهم البعض وليس بالضرورة أن يكونوا ملزمين بأدوار مميزة مثل المهندس المعماري أو المبرمج أو المصمم أو المختبِر. يكمل الجميع مجموعة العمل معًا. يخطط فريق Scrum لمقدار العمل الذي يمكنهم إكماله لكل سباق ويمتلك الخطة (Genchi Genbutsu).

تدفق سكروم والأنشطة والاحتفالات

كما نوقش أعلاه ، لدى سكرم تدفق محدد ومجموعة من الطقوس والأنشطة. تدفق العدو على النحو التالي.

التخطيط السريع:

قبل بدء السباق ، يقوم Scrum Master بتسهيل اجتماع مع فريق سكرم ومالك المنتج ، يسمى اجتماع تخطيط السباق ، حيث يحدد مالك المنتج أهداف السباق القادم ، ثم يخطط الفريق لعملهم وفقًا للأهداف.

يتم ذلك عادةً من خلال الأنشطة التالية:

• قدرة Sprint: يحدد الفريق سعة العدو ، مع مراعاة عدد الأيام وعدد أعضاء الفريق والعطلات وما إلى ذلك.
• أهداف Sprint: يحدد مالك المنتج أهداف السباق. من الأهمية بمكان أن يتم ترتيب أولويات العمل المتراكم على المنتج وفقًا للأهداف (على سبيل المثال ، تكون القصص ذات الصلة في المقدمة) ويتم إعدادها.
• اختيار العمل: يتم سحب القصص أو المهام من الجزء العلوي من الأعمال المتراكمة إلى السباق حتى الوصول إلى السعة المقدرة. عندما يتم سحب القصص ، سيشرح مالك المنتج القصة والإجابة على أسئلة الفريق ، وتحديث القصة حسب الحاجة ، حتى يكون لدى مالك المنتج وفريق Scrum فهم جيد ومشترك للقصة. بمجرد اكتمال هذا النشاط ، يكون لدى الفريق نطاق سريع أولي مقترح.
• تقسيم المهام: يناقش فريق سكرم كل قصة بالتفصيل مع التركيز على التخطيط لكيفية إكمالهم للقصة ومعالجة جميع معايير القبول ووزارة الدفاع. سيقومون بإعداد قائمة بالمهام الفرعية اللازمة لإكمال القصة. بمجرد اكتمال قائمة المهام الفرعية ، تتم مراجعة تقدير القصة وتحديثها إذا لزم الأمر.
• التزام Sprint: بمجرد تقسيم جميع القصص وتحديث التقديرات ، تتم مراجعة نطاق العدو الأولي المقترح. يمكن إزالة القصص من السباق وإعادتها إلى الأعمال المتراكمة و / أو إضافة قصص إضافية. بمجرد الانتهاء من ذلك ، يلتزم فريق Scrum فقط (وليس Scrum Master أو مالك المنتج) بإكمال العمل في السباق ، ويبدأ العدو.

يُقاس المبلغ الإجمالي للعمل أو النطاق الملتزم به في السباق بنقاط القصة.

تنفيذ Sprint

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

يتم تتبع التقدم باستخدام مخطط توقف يوضح مقدار العمل المنجز والمتبقي المقاس في نقاط القصة. تظهر نقاط القصة المتبقية على المحور ص ويظهر الوقت المتبقي على المحور س. يتم تحديث مخطط التوقف عند الانتهاء من القصص.

بشكل يومي ، يركز Scrum Master على:

• يسهل اجتماع الوقوف اليومي للتخطيط لليوم ومراجعة التقدم (انظر أدناه)
• يضمن أن الفريق لديه خطة لهذا اليوم
• يزيل حواجز الطرق
• يحمي نطاق العدو والفريق من الانحرافات
• يساعد الفريق في الحفاظ على مخطط الإنهاك وإحصائيات Scrum الأخرى

الوقوف اليومي

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

• ماذا فعلت البارحة؟
• ما كنت تخطط القيام به اليوم؟
• هل هناك معوقات تمنعك من إتمام عملك؟

يتيح ذلك للجميع معرفة ما يعمل عليه الجميع ، ومعرفة التقدم الذي يتم إحرازه أو عدم إحرازه ، وتحديد العوائق و / أو المساعدة المطلوبة.

إكمال Sprint

يسهل Scrum Master احتفالين لإغلاق السباق قبل التخطيط للسباق التالي.

سبرينت التجريبي

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

يتم حساب العدد الإجمالي لنقاط القصة المكتملة لكل عدو (السرعة) ويتم إغلاق العدو. تُستخدم السرعة لتتبع مستوى إخراج الفريق وتُستخدم لتقدير وقت اكتمال الميزات أو الإصدارات.

سبرينت بأثر رجعي

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

يتم إنتاج قائمة بعناصر إجراءات التحسين ، وفي بعض الأحيان ينتج عنها إضافة عناصر إلى تراكم المنتج ، أو تغييرات على DoD أو ميثاق الفريق ، وما إلى ذلك.

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

إنشاء سجل المنتج

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

الاستمالة المتراكمة

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

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

تقدير نقطة القصة

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

مقياس فيبوناتشي (1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21 ...) هو المقياس الأكثر استخدامًا حيث تكون كل زيادة تقريبًا ضعف الحجم السابق (على سبيل المثال ، القصة المكونة من خمس نقاط تكون أكثر أو أقل مرتين من كبيرة كقصة من ثلاث نقاط). في بعض الأحيان يتم استخدام مقاييس أخرى مثل أحجام القمصان (XS ، S ، M ، L ، XL) أو حتى الأسماك (المنوة ، السمكة الذهبية ، السلمون المرقط ، التونة ، الحوت ، إلخ). أي مقياس يسمح لك بمقارنة حجم شيء بالنسبة لآخر سيعمل.

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

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

يتم تقدير نقطة القصة أثناء اجتماعات الاستمالة وأحيانًا أثناء التخطيط السريع باستخدام Planning Poker:

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

مزايا تقدير نقطة القصة هي:

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

الافراج عن تقدير وتتبع

يتم استخدام تقدير نقطة القصة أيضًا في سياق تخطيط الإصدار باستخدام التقنية التالية:

1. قائمة كل القصص لتكون بحجمها
2. رتبهم من الأصغر إلى الأكبر
   • خذ قصة المستخدم الأولى والثانية.
   • قرر أيهما أكبر وضع الأكبر أدناه
   • ثم خذ التالي وحدد المكان المناسب نسبيًا للاثنين الآخرين
   • كرر العملية حتى تصبح جميع القصص الآن في القائمة (في تسلسل من الأصغر إلى الأكبر)
3. حجم القصص

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

المصنوعات اليدوية Scrum وشروطها

• Product Backlog: قائمة تراكمية لجميع عناصر العمل لمنتج معين والتي يمكن أن تتضمن ميزات (قصص) ، ومهام فنية ، ونوبات ، وعيوب
• Release Burn-up: مخطط رسومي يستخدم لإظهار التقدم على مستوى الإصدار والتنبؤ بموعد انتهاء الإصدار باستخدام Sprint Velocity. تظهر نقاط القصة المكتملة على المحور Y وتظهر سباقات السرعة على المحور X.
• Sprint Backlog: قائمة متراكمة لجميع عناصر العمل التي يتعين إكمالها في سباق معين. يتم الاتفاق على محتويات تراكم السباق خلال اجتماع تخطيط السباق.
• لوحة سكرم: لوحة على شكل طاولة تتعقب تقدم العمل المرتبط بالسباق. تظهر الحالات في الجزء العلوي في أعمدة رأسية ويتم نقل عناصر العمل عبر كل حالة حتى يتم الانتهاء منها. يتم ملء لوحة سكرم أثناء اجتماع تخطيط العدو وتتم إعادة تعيينها في نهاية السباق.
• Sprint Burndown: رسم بياني يوضح مقدار العمل المنجز والمتبقي المقاس في نقاط القصة على طول العدو. تظهر نقاط القصة المتبقية على المحور ص ويظهر الوقت المتبقي على المحور س.
• Sprint Velocity: عدد نقاط القصة التي يكملها فريق Scrum في سباق سريع.
• تراكم العوائق: قائمة بالعوائق التي يجب معالجتها بواسطة Scrum Master حتى يتمكن الفريق من مواصلة العمل. عندما يتم حظر أحد أعضاء الفريق ، فإنه سيضيف عنصرًا إلى تراكم العوائق لتوفير الرؤية للفريق و Scrum Master.
• الملحمة: الملحمة عبارة عن مجموعة كبيرة من الأعمال تتكون من قصص مستخدمين متعددة ذات صلة.
• قصة المستخدم: قصة المستخدم هي وصف لميزة البرنامج من منظور المستخدم النهائي. تصف قصة المستخدم نوع المستخدم وماذا يريد ولماذا. تساعد قصة المستخدم في إنشاء وصف مبسط للمتطلب ويتضمن معايير القبول. يتم إنشاء قصص المستخدم والاحتفاظ بها من قبل مالك المنتج.
• المهمة: المهمة هي جزء من العمل يتم إدخاله بواسطة Scrum Master أو عضو الفريق والذي قد يكون مرتبطًا بشكل مباشر أو غير مباشر بقصص المستخدم. عادة ما تكون تقنية بطبيعتها وستتضمن معايير القبول.
• Spike: هو نوع خاص من المهام يتم استخدامه عندما تحتاج إلى البحث و / أو النموذج الأولي و / أو المهندس المعماري في وقت ما قبل أن تتمكن من اتخاذ قرار بشأن كيفية تنفيذ أو تقدير قصة مستخدم.
• المهمة الفرعية : المهمة الفرعية هي مهمة يتم إدخالها كخطوة تنفيذ نحو إكمال قصة مستخدم أو مهمة. عادة ما يتم إدخالهم من قبل الفريق خلال اجتماع التخطيط السريع.
• تقديرات نقطة القصة: مقياس تقدير نسبي للحجم يعتمد على مقياس فيبوناتشي (1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21 ...)
• معايير القبول: قائمة العناصر المحددة للقصة والقابلة للاختبار المضمنة في كل قصة والتي يجب إكمالها قبل أن يقبل مالك المنتج القصة على أنها مكتملة.
• تعريف تم (DoD): قائمة بالخطوات أو المعايير الشائعة التي يجب إكمالها قبل اعتبار أي قصة منتهية. يوافق الفريق على هذا ويوثقه حتى لا يتم إدراجه في كل قصة.

مزايا وعيوب سكرم

الميزة الأساسية لـ Scrum هي تطبيق قيم ومبادئ Agile بالإضافة إلى مفاهيم Lean مثل Seiri و Jidoka و Just-in-Time و Kaizen و Genchi Genbutsu و Heijunka و Pull System و Iterations. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

كانبان

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.