لماذا ا؟ لا يمكن الانتظار بعض المهام حتى الأسبوع المقبل؟ هل من المهم إنهاء كل شيء قبل نهاية الأسبوع؟ لا ، هذا ليس مهمًا. وكل هذا يرجع إلى حقيقة أن "تنفيذ المهام أمر سيء".
سكروم لم يعد منهجية تطوير رشيقة
توصلت إلى استنتاج مفاده أن هناك الكثير من التركيز على عملية العمل في سكروم. أو ، على الأقل ، يولي الناس اهتمامًا كبيرًا به ، والذي يتم التعبير عنه في ما يلي:
- لا بأس في إنهاء قصة المستخدم في اليوم الأخير من السباق. لكن الانتهاء من العمل يوم الاثنين المقبل هو بالفعل "نقل مهمة".
- - ( , ), , , , , .
- , , , . , , , ( , ).
ونتيجة لذلك ، اتضح أن سكروم لم يعد يساعدنا على تحقيق الهدف. كانت طريقة إدارة المشروع هذه تحد لنا الآن.
مع كل ما سبق ، يمكنني أن ألاحظ أن أعضاء فريقي بدأوا يشعرون بعدم الرضا عما كان يحدث. هذا أثر على جودة ما أنشأناه. كان المبرمجون أكثر اهتمامًا بالوفاء بالمواعيد النهائية من تحقيق مستوى الجودة المطلوب.
في هذه المرحلة ، بدأنا في البحث عن طرق أخرى لتنظيم العمل ، والبحث عن إطار عمل رشيق آخر يناسب طريقة عملنا بشكل أفضل.
ثم وجدنا كانبان.
ما هو كانبان؟
Kanban هي طريقة لإدارة الإنتاج نشأت في تويوتا في الخمسينيات. في ذلك الوقت ، استخدمت تويوتا لوحة تحتوي على ثلاثة أعمدة: مخطط ، قيد التنفيذ ، مكتملة. سمح هذا الإطار لشركة تويوتا بتخصيص الموارد بشكل أكثر كفاءة في المواقف التي ظهرت فيها الاختناقات في مكان ما على طول خط الإنتاج.
ثم ، عندما أصبح من الواضح أن استخدام Kanban يمكن أن يزيد من سرعة تطوير البرمجيات ، تم نقل Kanban إلى ساحة التكنولوجيا.
مقارنة بين أطر سكروم وكانبان
في السنوات الأخيرة ، كان سكروم وكانبان يكافحان من أجل أن يصبحا الإطار الرشيق الرائد. على الرغم من حقيقة أن سكروم يحتل المرتبة الأولى ، فإن كانبان ينتشر تدريجياً أكثر فأكثر. ماذا لو قارنتهم؟
إذا أخذنا سكروم كأساس وقارنناه مع كانبان ، نحصل على ما يلي:
- , ().
- .
- «». , .
- , , .
- () -.
يمكن العثور على مقارنة أكثر تفصيلاً بين سكروم وكانبان هنا .
يمنح كانبان فريق التطوير مستوى عالٍ من المرونة. قصص المستخدم ، بالمقارنة مع سكروم ، يتم تنفيذها بطريقة أكثر حرية. لكن الحرية هي المسؤولية. في حين أن Kanban لا يتطلب من المطورين الالتزام بأنفسهم كل أسبوعين ، فإن استخدام هذه الطريقة في إدارة التطوير له ضوابط خاصة به. هذه ، على سبيل المثال ، مقاييس مثل وقت الدورة وإنتاجية النظام.
الأمر كله يتعلق بالمقاييس
من المستحيل تقييم فعالية (أو عدم كفاءة) العمل بدون مقاييس متخصصة. دعونا نلقي نظرة على المقاييس المستخدمة في سكروم وكانبان.
مقاييس umScrum
عند تطبيق سكروم ، يتم استخدام المقاييس والرسوم البيانية التالية:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
من غير المحتمل أن تساعدك هذه المقاييس على تحسين سير عملك.
"السرعة" لا تقيس معدل إطلاق الأنظمة الفرعية للمنتج النهائي. يقيس هذا المقياس فقط عدد خطوات العمل المكتملة ذات الصلة بقصة المستخدم. إذا كانت القصة تستغرق وقتًا أطول من المخطط لإكمالها ، فهذا المقياس لا معنى له.
لا يجب اعتبار "نسبة التزام المطور بحجم المهام المنجزة" مقياسًا على الإطلاق. يقارن هذا "المقياس" الالتزام بالنتائج. وغني عن القول ، يمكن أن يؤدي هذا إلى إغلاق الأشخاص وإعادة فتح المهام لمجرد إنجازها.
مخطط الإرهاق هو شيء لم أنتبه إليه شخصيًا أبدًا. ويرجع ذلك أساسًا إلى حقيقة أن مثل هذه الرسوم البيانية غالبًا ما تبدو مثل تلك الموجودة أدناه.
مخطط Burnout
لماذا هذا؟ لنفترض أنك تبدأ بلوحة فارغة وتبدأ في العمل بالتوازي ، على سبيل المثال مع ثلاث قصص مستخدم. من المرجح أن يتم العمل على هذه القصص بنفس المعدل ، ولهذا السبب يمكنك أن ترى مثل هذه الحركات الهبوطية القوية في مخطط الإرهاق. علاوة على ذلك ، إذا كان هناك اختبار واحد فقط في الفريق يجب عليه اختبار نتائج العمل في جميع المهام ، فسيكون هو عنق الزجاجة في الفريق.
مقاييس banكانبان
أعتقد أن المقاييس هي أهم نقاط قوة Kanban. لدى كانبان العديد من المقاييس المختلفة لمساعدتك على فهم ما يجري مع فريقك بشكل أفضل. فمثلا:
- إنتاجية الفريق عدد قصص المستخدمين التي تم إكمالها خلال فترة زمنية معينة.
- دورة الزمن عدد الأيام التي يستغرقها إكمال العمل التاريخي منذ بداية العمل. يتم استخدام مقاييس مثل فواصل الثقة هنا. الأكثر شيوعًا هو 85٪ ثقة.
- مخطط التدفق التراكمي يتيح لك هذا الرسم البياني تصور عملية حل المشكلات استنادًا إلى قصص المستخدمين. يجب أن يبدو هذا الرسم البياني شيئًا مثل المخطط الموضح أدناه.
مخطط التدفق التراكمي
هناك مكون إضافي لـ Jira يسمح لك بالاستفادة من جميع هذه المقاييس. هذا هو ActionableAgile لـ Jira - Agile Metrics . يساعد على استكشاف المقاييس ذات الصلة بأداء الفريق باستخدام نفس النظام الأساسي المستخدم لإدارة العمل.
التكيف Kanban
استخدام kanban "النقي" لا يوفر بعض العمليات المطلوبة عند استخدام سكروم. لكن هذه الطريقة في إدارة المشروع مرنة بما يكفي للسماح ، إذا بدت هذه الإجراءات مفيدة ، أن تضاف إلى سير العمل.
تعد الأحداث الرجعية من أهم أنواع الاجتماعات. في هذه الاجتماعات يمكن لأعضاء الفريق التحدث عما حققوه وما لم يسير على ما يرام وما يمكن تحسينه. الاسترجاع حدث هادئ حيث يمكنك التحدث عن مشاكلك وتهنئة أولئك الذين قاموا بعمل ممتاز على نجاحهم.
في حين أن ذكريات الماضي ليست ضرورية في Kanban (يتم الاحتفاظ بها في نهاية كل Sprint في Scrum) ، فقد وجدناها ذات قيمة ولم نرغب في تخطيها. في الواقع ، بدأنا في القيام بها أسبوعيًا ، بدلاً من كل أسبوعين كما اعتدنا. هذا سمح لنا بالتفاعل بسرعة أكبر مع حدوث أي مشاكل. نستخدم أيضًا هذه الاجتماعات لتحليل مقاييس الفريق والتحقق من سير العمل بحثًا عن المشكلات والاختناقات.
لقد حفظنا عنصرًا آخر من أوقات Scrum ، وهو أمر اختياري عند استخدام kanban. يتعلق الأمر بتقدير الوقت اللازم للعمل على قصة مستخدم. يتم ذلك في سياق توضيح المهام التي تدخل في التاريخ. يستخدم سكروم هذه التقديرات لفهم أفضل لما سيكون مناسبًا للسباق. قد تعتقد أنه نظرًا لعدم وجود سباقات سريعة في كانبان ، فإن تقييم القصة غير ضروري. ولكن في الواقع ليس كذلك.
يساعد تقدير الوقت الذي يستغرقه إكمال قصة المستخدم على ضمان أن جميع أعضاء الفريق لديهم نفس الفهم لنطاق المهام التي يجب إكمالها أثناء العمل على القصة. إذا أعطى شخص ما القصة درجة 8 ، وشخص آخر - 3 ، فمن الواضح أننا بحاجة إلى مواصلة مناقشة هذه القضية. قد يأخذ شخص ما ، عند تقييم التوقيت ، في الاعتبار بعض المشاكل التي لا يعرفها الآخرون. في فهم شخص ما ، يجب أن يتضمن نطاق عمل قصة المستخدم شيئًا لا يعتبره الآخرون كذلك.
في الواقع ، كل هذا يدفع أعضاء الفريق إلى المناقشات.
عندما يحدث شيء من هذا القبيل ، يصبح من الواضح أنه ليس لدى الجميع فهم واضح لكمية العمل التي يجب القيام بها في قصة مستخدم معينة.
هناك سيناريو شائع آخر يبدو على هذا النحو: يمنح الفريق بأكمله شدة القصة تصنيفًا مرتفعًا إلى حد ما (عادةً كل شيء يزيد عن 8 نقاط). هذا يتحدث عن عدم اليقين. هذا يعني أننا إما نتحدث عن الكثير من العمل ، أو عن حل مشاكل صعبة للغاية ، مما يجعل أعضاء الفريق غير سارة. في مثل هذه الحالة ، من الأفضل تقسيم قصة المستخدم إلى عدة قصص أصغر وتحديد أهداف العمل بشكل أكثر وضوحًا.
النتيجة
سيبقى سكروم إلى الأبد في قلوبنا كأول منهجية رشيقة واسعة الانتشار. ولكن مع تقدم الشركات نحو خطط النشر المستمر ، لم يعد استخدام العدو السريع محدودًا.
سيكون هناك دائمًا مشاريع خاصة يمكن لـ Scrum أن يؤدي فيها أداءً جيدًا. ومع ذلك ، وبالنظر إلى حقيقة أن الشركات تستخدم بشكل متزايد منهجيات رشيقة ، فإن كانبان سيأتي تدريجياً في المقدمة ، ليحل محل سكروم.
ما يناسبك؟ سكروم أم كانبان؟
