Agile و Scrum و Kanban: ماذا تعني هذه الكلمات حقًا؟

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

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

رشيق

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

يشير مصطلح "Agile" إلى "تطوير البرامج الذكية" ، وهو نهج التطوير الذي يتبع مبادئ Agile. ولكن ما هي "المبادئ الرشيقة"؟ ألق نظرة على بيان Agile وعلى المبادئ الاثني عشر للرشاقة ، التي تضع أسس التطور السريع. من البيان:

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

ولكن ما سبب أهمية اتباع هذه المبادئ في عملنا؟

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

سكرم

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

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

ما هو سكرم؟ يعرّف دليل سكروم سكرم بأنه:

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

يتكون Scrum من الأدوار التالية: Product Owner و Scrum Master و Development Team.

هناك أيضًا أربعة احتفالات Scrum: اجتماع التخطيط ، و Daily Scrum ، و Sprint Review ، و Sprint Retrospective

والأدوات الثلاثة: Product Backlog و Sprint Backlog و Product Increment.

يتم تنظيم مشاريع سكرم في أطر زمنية منتظمة ، والتي نسميها سباقات السرعة. عادة ما تستمر أسبوعين.

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

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

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

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

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

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

كانبان

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

Kanban هي طريقة بسيطة تهدف إلى التسليم في الوقت المناسب مع عدم إثقال كاهل أعضاء الفريق. إنه مشابه لـ scrum في أن الهدف هو تقديم أقصى قيمة في النهاية ، لكنه أكثر مرونة من سكروم.

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

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

Backlog ← تحديد المواصفات ← جاهز للتطوير ← تطوير ← مراجعة الكود ← اختبار ← منتشر (← لا أحد يستخدمه بالفعل ← تمت إزالته تمامًا).

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

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

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

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

ما الذي يجب علي استخدامه؟

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

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

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

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

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