إذا دخلت اليوم إلى أي فريق تقريباً يعمل في تطوير المنتجات أو الهندسة، وسألت أفراده عن منهجية العمل التي يتبعونها، فمن المحتمل جداً أن تسمع إجابة مثل: «نحن نعمل بأسلوب Agile ونستخدم Scrum». وغالباً ما يُذكر المصطلحان معاً وكأنهما اسمان لشيء واحد، أو كأن Scrum هو ببساطة الاسم الآخر لـ Agile. لكن الأمر ليس كذلك.
وهذا الخلط لا يقتصر على كونه خطأً في استخدام المصطلحات. فهو يفسر جزئياً لماذا تطبق بعض الفرق اجتماعات Scrum وممارساته بدقة شديدة، ومع ذلك لا تنجح في تبني جوهر Agile فعلياً. وفي المقابل، قد تتبنى فرق أخرى مبادئ Agile بصورة جيدة، ثم تكتشف أن القواعد التفصيلية لـ Scrum لا تتناسب مع طبيعة عملها، بل أصبحت تعيقها بدلاً من أن تساعدها.
وفهم هذا الفرق أهم بكثير مما قد يبدو للوهلة الأولى. فعندما تختار المؤسسة إطار العمل غير المناسب، أو لا تدرك بوضوح ما الذي تطبقه فعلياً، تظهر مشكلة مألوفة: اجتماعات Daily Scrum تُعقد في مواعيدها، ودورات Sprint تسير وفق الجدول، واجتماعات Retrospective تُجرى بانتظام، ومع ذلك يستمر الفريق في التأخر عن مواعيد التسليم، ويظل غير قادر على فهم احتياجات العميل بدقة، وتتكرر الأخطاء نفسها دون معرفة واضحة بأسبابها.
وفي الأكاديمية البريطانية للتدريب والتطوير، نرى هذا الخلل كثيراً لدى المؤسسات التي تفترض أن تطبيق Scrum وفق القواعد المعروفة يعني تلقائياً أنها تطبق Agile بصورة صحيحة.
لذلك، تهدف هذه المدونة إلى توضيح العلاقة بين Agile وScrum من أساسها، وشرح ما الذي يقدمه كل منهما، والأهم من ذلك، تحديد الظروف التي يكون فيها استخدام كل نهج منطقياً وملائماً لطبيعة العمل.
Agile فلسفة عمل، وScrum إطار لتطبيقها
أفضل طريقة لفهم العلاقة بين Agile وScrum ليست وضعهما في مواجهة بعضهما كخيارين متساويين، وإنما فهم العلاقة بينهما. فـ Agile تمثل مجموعة من القيم والمبادئ التي تحدد الطريقة التي ينبغي أن تتعامل بها الفرق مع الأعمال التي تتسم بالتغيير وعدم اليقين. وقد جرى التعبير عن هذه المبادئ بصورة واضحة في بيان Agile عام 2001، الذي ركز على أهمية الأفراد والتفاعل بينهم، والنتائج العملية، والتعاون مع العملاء، والاستجابة للتغيير.
ولا تحدد Agile مجموعة ثابتة من الاجتماعات أو الأدوار أو الإجراءات التي يجب على كل فريق اتباعها. فهي أقرب إلى فلسفة أو طريقة تفكير تحدد كيف ينبغي للفريق أن يتعامل مع العمل والتغيير والتعاون والتحسين المستمر.
أما Scrum فهو إطار عمل محدد يترجم جزءاً من هذه المبادئ إلى طريقة عملية ومنظمة لإدارة العمل. فهو يحدد أدواراً واضحة مثل Product Owner وScrum Master وDevelopment Team، ويحدد ممارسات واجتماعات مثل Sprint Planning وDaily Scrum وSprint Review وRetrospective، إلى جانب عناصر أساسية مثل Product Backlog وSprint Backlog وIncrement.
بمعنى أبسط: Scrum أحد الأطر التي يمكن من خلالها تطبيق Agile، لكنه ليس Agile نفسها. فهناك أطر أخرى تقوم على مبادئ Agile، مثل Kanban وExtreme Programming (XP) وLean، ولكل منها طريقة مختلفة في تنظيم العمل وتحقيق المرونة والتحسين المستمر.
من أين جاء الخلط بين Agile وScrum؟
من السهل فهم سبب شيوع هذا الخلط. فقد أصبح Scrum أحد أكثر الأطر انتشاراً لتطبيق Agile، ويرجع ذلك جزئياً إلى أن هيكله واضح ويمكن تدريسه وتطبيقه بصورة مباشرة، كما أن الحصول على التدريب والشهادات المرتبطة به أصبح متاحاً على نطاق واسع.
وبالنسبة إلى كثير من المتخصصين، يكون Scrum هو أول إطار عملي يتعرفون عليه عند دراسة Agile، وأحياناً يكون التجربة الوحيدة التي يخوضونها معها. ومع مرور الوقت، يصبح من الطبيعي أن يستخدموا المصطلحين وكأنهما يعنيان الشيء نفسه.
لكن المشكلة تظهر عندما يواجه الفريق نوعاً من العمل لا يتناسب مع طريقة Scrum. فإذا لم يكن الفريق مدركاً لوجود أطر وأساليب أخرى ضمن منظومة Agile، فقد يحاول إجبار العمل على التكيف مع Scrum، بدلاً من التساؤل عما إذا كان Scrum هو الإطار المناسب أصلاً.
ماذا تعني Agile عملياً بالنسبة للفريق؟
عند النظر إلى Agile بعيداً عن أي إطار محدد، فإنها تدفع الفريق إلى مجموعة من المبادئ الأساسية، من أهمها:
تقديم أجزاء قابلة للاستخدام من المنتج أو الخدمة بصورة متكررة، بدلاً من الانتظار حتى نهاية المشروع لتقديم كل شيء دفعة واحدة.
التعامل مع تغير المتطلبات باعتباره أمراً طبيعياً يمكن استيعابه، حتى في المراحل المتقدمة من العمل.
الحفاظ على تعاون مستمر مع العملاء وأصحاب المصلحة والأشخاص المتأثرين بنتائج المشروع.
مراجعة طريقة العمل بشكل دوري، وإجراء التغييرات اللازمة لتحسين أداء الفريق، وليس فقط تحسين المنتج.
منح أصحاب الخبرة والدافعية مساحة لتنظيم عملهم واتخاذ القرارات، بدلاً من إدارة كل مهمة بصورة تفصيلية من أعلى إلى أسفل.
لاحظ أن أياً من هذه المبادئ لا يفرض مدة محددة لدورة العمل، ولا يشترط وجود دور وظيفي باسم معين، ولا يلزم الفريق بعقد اجتماع يومي محدد الشكل.
يمكن لفريق أن يطبق مبادئ Agile بصورة حقيقية دون أن يعقد اجتماعاً واحداً يحمل اسم Daily Scrum.
ماذا يضيف Scrum إلى مبادئ Agile؟
يأخذ Scrum المبادئ العامة لـ Agile ويضعها داخل إطار عملي أكثر تحديداً، بحيث يصبح لدى الفريق إيقاع واضح وطريقة منظمة للتخطيط والتنفيذ والمراجعة والتحسين.
ومن أبرز ما يضيفه Scrum:
دورات Sprint محددة المدة: عادة ما تمتد من أسبوع إلى أربعة أسابيع، وتمنح الفريق فترة زمنية واضحة يركز خلالها على مجموعة محددة من الأولويات.
أدوار محددة بوضوح: يتولى Product Owner مسؤولية تحديد الأولويات، بينما يساعد Scrum Master الفريق على الالتزام بإطار Scrum وتحسين طريقة العمل، ويتولى فريق التطوير تنفيذ العمل المطلوب.
ممارسات واجتماعات منتظمة: تهدف إلى التخطيط للعمل، ومتابعة التقدم، ومراجعة النتائج، والتعلم من التجربة السابقة وإجراء التحسينات.
قائمة أعمال ذات أولويات: توفر مرجعاً واضحاً لما يحتاج الفريق إلى إنجازه، وما ينبغي أن يأتي بعد ذلك.
هذه البنية المنظمة هي في الوقت نفسه إحدى أهم نقاط قوة Scrum وأحد أسباب عدم ملاءمتها لبعض البيئات.
فهي تعمل بصورة جيدة عندما يكون الفريق بصدد تطوير منتج واضح الاتجاه، مع متطلبات تتغير من وقت إلى آخر، ولكنها لا تتغير بصورة تجعل خطة Sprint غير صالحة بعد أيام قليلة.
أما الفرق التي تتعامل مع تدفق مستمر وغير متوقع من الطلبات، والتي لا يمكنها الانتظار حتى بداية Sprint التالية لمعالجة العمل الجديد، فقد تجد نفسها في مواجهة مستمرة مع هذا الهيكل. وهذا أحد الأسباب التي تجعل فرق الدعم والصيانة والعمليات تواجه أحياناً صعوبة في تطبيق Scrum على طبيعة عملها اليومية.
متى يكون Scrum مناسباً فعلاً؟
يكون Scrum أكثر انسجاماً مع طبيعة العمل عندما تتوافر عدة عوامل، من بينها:
إمكانية التخطيط للعمل بصورة معقولة ضمن فترة زمنية قصيرة ومحددة، عادة من أسبوع إلى أربعة أسابيع.
وجود أولويات يمكن تعديلها عند الحاجة، ولكن ليس بصورة متكررة وعنيفة تجعل خطة Sprint تفقد قيمتها خلال أيام.
استفادة الفريق من وجود إيقاع ثابت للمراجعة والتقييم وتصحيح المسار.
وجود Product Owner لديه القدرة الفعلية على ترتيب الأولويات واتخاذ القرارات في الوقت المناسب.
عمل الفريق على منتج أو هدف مترابط، وليس على مجموعة متواصلة من الطلبات المنفصلة التي تصل من جهات مختلفة.
ولهذا السبب، يعد تطوير المنتجات، وخاصة تطوير البرمجيات، من أكثر البيئات ارتباطاً بـ Scrum. وهذا ليس مستغرباً، بالنظر إلى أن الإطار نشأ أساساً لمعالجة هذا النوع من العمل.
متى تكون مبادئ Agile أكثر ملاءمة من هيكل Scrum؟
هناك حالات تكون فيها مبادئ Agile مناسبة تماماً، بينما لا يكون هيكل Scrum المحدد هو الخيار العملي للفريق.
ومن أمثلة ذلك:
فرق الدعم والصيانة: تتعامل هذه الفرق مع تدفق مستمر وغير متوقع من الطلبات والتذاكر، ولذلك قد لا يكون منطقياً أن تلتزم بخطة عمل ثابتة لمدة أسبوعين بينما يمكن أن تظهر أولوية عاجلة في أي وقت.
الفرق الصغيرة ذات الخبرة العالية: قد تجد بعض الفرق المتمرسة أن عدداً من ممارسات Scrum يضيف عبئاً إدارياً دون أن يقدم لها فائدة حقيقية، خصوصاً إذا كانت قادرة بالفعل على التنسيق واتخاذ القرارات بصورة مباشرة.
الأعمال البحثية والاستكشافية: في بعض المشاريع لا يمكن معرفة الخطوة التالية قبل معرفة نتائج الخطوة الحالية. وهنا قد يكون فرض خطة Sprint مسبقة أقل ملاءمة لطبيعة العمل.
الفرق التي تعمل على مبادرات متعددة في الوقت نفسه: عندما تتوزع جهود الفريق بين مشروعات أو مبادرات مختلفة، قد لا تعكس قائمة أعمال واحدة الواقع الفعلي لتدفق العمل.
وفي مثل هذه البيئات، قد يكون Kanban أكثر انسجاماً مع طبيعة العمل. فهو أحد أساليب Agile التي تركز على رؤية تدفق المهام بوضوح، وتقليل عدد الأعمال التي يجري تنفيذها في الوقت نفسه، والحفاظ على تدفق مستمر للعمل بدلاً من تنظيمه بالكامل داخل دورات زمنية ثابتة.
ما السؤال الذي ينبغي طرحه قبل اختيار المنهجية؟
السؤال «هل نستخدم Agile أم Scrum؟» ليس دقيقاً في الأساس، لأنه يضع فلسفة عمل وإطاراً محدداً في المستوى نفسه.
السؤال الأكثر فائدة هو: كيف تصل الأعمال إلى فريقنا؟ وما مدى استقرار أولوياتنا؟ وما طبيعة الفريق وطريقة عمله؟ وأي إطار من أطر Agile يمكنه التعامل مع ذلك بصورة أفضل؟
قد تكون الإجابة Scrum، أو Kanban، أو XP، أو مزيجاً مصمماً بعناية من أكثر من نهج.
كما أن اختيار إطار العمل ليس بالضرورة قراراً يُتخذ مرة واحدة عند بداية المشروع ثم لا تتم مراجعته. فالفرق تتغير، وطبيعة العمل تتطور، والأولويات تتحول. ولذلك قد يكون الإطار الذي كان مناسباً تماماً قبل عام أقل ملاءمة لفريق أصبح أكبر حجماً أو تغيرت طبيعة مسؤولياته.
كيف تقارن بين الخيارات العملية؟
بعد فهم الفرق بين Agile وScrum، يصبح التحدي الحقيقي أمام كثير من الفرق هو تحديد الطريقة التي ينبغي أن تنظم بها عملها: هل تحتاج إلى الإيقاع المنظم الذي توفره Scrum؟ أم إلى التدفق المستمر الذي يركز عليه Kanban؟ أم إلى نهج هجين يجمع بين عناصر من الاثنين بما يتناسب مع طبيعة العمل؟
نتناول هذه المقارنة بالتفصيل في المدونة المرتبطة الاختيار بين Scrum وKanban والأسلوب الهجين لتنفيذ المشاريع داخل فريقك، بما في ذلك المؤشرات العملية التي يمكن أن تساعد في تحديد النهج الأكثر توافقاً مع طريقة وصول الأعمال وأولويات الفريق.
من معرفة الفرق إلى القدرة على الاختيار والتكيف
معرفة الفرق النظري بين Agile وScrum خطوة مهمة، لكنها لا تكفي وحدها لإدارة العمل بصورة فعالة. فالتحدي الحقيقي يكمن في معرفة متى لم يعد هيكل Scrum مناسباً للفريق، وكيف يمكن تطبيق Kanban بانضباط دون أن يتحول إلى ذريعة لغياب التخطيط، وكيف يمكن بناء نهج هجين يعكس طريقة العمل الفعلية بدلاً من مجرد جمع ممارسات مختلفة معاً.
وهذا ما تركز عليه دورات Scrum وAgile لإدارة وتنفيذ المشاريع في الأكاديمية البريطانية للتدريب والتطوير، من خلال تناول آليات Scrum، ومبادئ تدفق العمل في Kanban، إلى جانب تطوير القدرة العملية على اختيار أسلوب التنفيذ المناسب وتعديله عندما تتغير احتياجات الفريق أو طبيعة المشروع.
اختيار أسلوب التنفيذ المناسب
لا ينبغي أن يكون اختيار إطار العمل مبنياً على المصطلح الأكثر انتشاراً أو المنهجية الأكثر تداولاً في السوق. فالنهج المناسب يرتبط بطبيعة الفريق، ونوع العمل الذي ينفذه، ومدى إمكانية التخطيط له، وسرعة تغير الأولويات، وطريقة وصول الطلبات إليه.
وتقدم الأكاديمية البريطانية للتدريب والتطوير مجموعة من دورات إدارة المشاريع المصممة للمتخصصين في مختلف المراحل المهنية، بدءاً من المهنيين الذين يستعدون لتأسيس أول فريق Scrum، وصولاً إلى الممارسين ذوي الخبرة الذين يحتاجون إلى إعادة تصميم أسلوب تنفيذ لم يعد يتوافق مع احتياجات فرقهم.