الرشاقة

Scrum أم Kanban: أيّ منهجية رشيقة تناسب فريقك؟

بقلم Codevista Innovationsنُشر في 12 أكتوبر 2026حُدّث في 15 أكتوبر 20267 دقائق قراءة

ينظّم Scrum العمل في سبرينتات (Sprints) لا تتجاوز مدة الواحد منها شهرًا، مع ثلاث مسؤوليات (Product Owner وScrum Master وDevelopers) وأحداث ثابتة؛ أمّا Kanban فيدير تدفّقًا مستمرًا دون أدوار مفروضة، ويقوم على الحدّ من العمل الجاري. اختر Scrum حين يبني الفريق منتجًا ويستطيع حماية هدف واحد بضعة أسابيع، واختر Kanban حين تصل الطلبات دون سابق إنذار (الدعم، الصيانة، الاستغلال). أمّا Scrumban فيجمع بين الاثنين.

ما الفرق بين Scrum وKanban؟

تتقاسم المقاربتان المبادئ الرشيقة نفسها: جعل العمل مرئيًا، والتسليم على دفعات صغيرة، والتحسّن انطلاقًا من الوقائع. ويكمن الاختلاف في درجة الهيكلة. فـScrum إطار عمل موصوف في دليل Scrum (Scrum Guide)، بمسؤوليات وأحداث ومخرجات محدّدة. أمّا Kanban فمنهجية لتدبير التدفّق: يُجعل المسار الحالي مرئيًا، ويُحدّ من العمل الجاري، ثم يُحسَّن خطوة بخطوة.

• الإيقاع: سبرينتات بمدة ثابتة (شهر أو أقل) في مقابل تدفّق مستمر دون تكرارات إلزامية.
• الأدوار: Product Owner وScrum Master وDevelopers في مقابل عدم فرض أي دور جديد.
• الأحداث: السبرينت، وبداخله Sprint Planning وDaily Scrum وSprint Review وSprint Retrospective، في مقابل طقوس يختارها الفريق.
• الحدّ من العمل: ما يدخل في السبرينت في مقابل حدود للعمل الجاري (WIP) في كل مرحلة من مراحل التدفّق.
• القياس: بلوغ هدف السبرينت (وما سرعة الإنجاز إلا ممارسة شائعة) في مقابل مهلة التسليم والإنتاجية وعمر المهام.
• التغييرات: هدف سبرينت محميّ ونطاق قابل لإعادة التفاوض مع الـProduct Owner، في مقابل قبول أولوية جديدة بمجرد أن يتحرّر مكان.

سبرينتات أم تدفّق مستمر: الإيقاع والأدوار والأحداث

ما يفرضه دليل Scrum

السبرينت وعاء لجميع الأحداث الأخرى. مدته ثابتة ولا تتجاوز شهرًا، وكثير من فرق البرمجيات تختار سبرينتات أقصر. يحدّد Sprint Planning هدف السبرينت والعمل الذي يخدمه. ويتيح Daily Scrum، المحدود في 15 دقيقة، للـDevelopers فحص تقدّمهم نحو هذا الهدف وتعديل خطتهم. أمّا Sprint Review فجلسة عمل مع الأطراف المعنية حول النتيجة المحقَّقة وما يليها، لا مجرد عرض توضيحي. وتتناول Sprint Retrospective طريقة العمل نفسها.

الـProduct Owner مسؤول عن تعظيم قيمة المنتج وعن تدبير الـProduct Backlog، بما في ذلك ترتيب أولوياته. والـScrum Master مسؤول عن إرساء Scrum وعن فعالية الـScrum Team. أمّا الـDevelopers، أي كل من يُنتج الإضافة (Increment) أيًّا كانت مهنته، فيلتزمون بتسليم إضافة قابلة للاستخدام في كل سبرينت تستوفي «تعريف الإنجاز» (Definition of Done). ويشير دليل Scrum إلى أن الـScrum Team تضم عادةً عشرة أشخاص أو أقل.

ما يتركه Kanban حرًّا

لا يعيد Kanban تنظيم الفريق. تُرسم المراحل الفعلية للعمل (للتحليل، قيد الإنجاز، قيد المراجعة، مُسلَّم)، وتُكتب قواعد الانتقال بين الأعمدة، ثم يختار الفريق طقوسه: لقاء يومي أمام اللوحة، ومراجعة دورية للتدفّق. هذه المرونة تُسرّع الانطلاق، لكنها تصبح خطرًا إذا لم يتولَّ أحد مسؤولية التحسين.

حدود العمل الجاري والمؤشرات والتغييرات أثناء السبرينت

حدّ العمل الجاري (WIP، أي work in progress) هو جوهر Kanban. فإذا امتلأ عمود «قيد المراجعة» المحدود في ثلاثة عناصر، لا يدخله شيء جديد: وبدل الشروع في مهمة أخرى، يساعد الفريق على إنهاء ما ينتظر. فيتراجع تعدّد المهام وتظهر مواضع الاختناق. ويصوغ قانون ليتل (Little's Law) هذا الحدس: في تدفّق مستقر وبإنتاجية ثابتة، يعني ازدياد العمل الجاري آجالًا أطول في المتوسط.

• في Scrum: يُنظر أولًا إلى بلوغ هدف السبرينت وإلى اكتمال الإضافة فعلًا. ولا ينصّ دليل Scrum على سرعة الإنجاز (Velocity)؛ فهي أداة تنبّؤ داخلية، لا مقياس أداء للمقارنة بين الفرق.
• في Kanban: تجيب مهلة التسليم (lead time، من الطلب إلى التسليم)، وزمن الدورة (cycle time، من بدء العمل إلى التسليم)، والإنتاجية وعمر المهام الجارية عن سؤال كل صاحب طلب: «متى سيكون جاهزًا؟»

أمّا بخصوص التغيير، فدليل Scrum واضح: لا يجوز لأي تغيير أن يعرّض هدف السبرينت للخطر. ويمكن إعادة التفاوض حول النطاق مع الـProduct Owner، وهو وحده المخوَّل بإلغاء سبرينت فقد مبرّره. وفي Kanban، تُحسم الأولوية حين يتحرّر مكان: فيمرّ الحادث العاجل دون الإخلال بأي التزام.

Scrum أم Kanban: أيّ منهجية لأيّ فريق؟

المعيار الصحيح ليس حجم المقاولة ولا القطاع، بل طبيعة الطلبات التي تصل إلى الفريق.

• Scrum يناسب الفرق التي تبني منتجًا بهدف واضح: منصة SaaS، أو تطبيق أعمال، أو خدمة رقمية جديدة. فهي قادرة على عرض نتيجة قابلة للاستخدام في نهاية كل سبرينت وتعديل ما يليها.
• Kanban يناسب العمل المستمر وغير المتوقَّع: الدعم التطبيقي، والصيانة التصحيحية، والاستغلال، ومعالجة الملفات، أو الطلبات الداخلية لفريق الموارد البشرية أو التسويق.
• Scrumban يناسب الحالات التي يكون فيها الـBacklog مستقرًا لكن الطوارئ متكرّرة.

وداخل مديرية نظم المعلومات الواحدة، في الدار البيضاء كما في غيرها، يمكن أن تتعايش المنهجيتان: فريق يعيد بناء بوابة الزبناء بـScrum، وآخر يتولّى صيانة بيئة الإنتاج بـKanban. وحين تسلّم عدة فرق Scrum منتجًا واحدًا، يصبح السؤال متعلقًا بالرشاقة على نطاق واسع مع SAFe؛ أمّا الوظائف خارج تكنولوجيا المعلومات فانظر مقال الرشاقة خارج تكنولوجيا المعلومات.

Scrumban: متى نجمع بين Scrum وKanban

ليس لـScrumban مرجع يضاهي دليل Scrum: إنه ممارسة تحتفظ بجزء من هيكلة Scrum وتضيف إليه تدبير التدفّق. وثمة نقطتا انطلاق شائعتان.

• فريق Scrum يضيف Kanban: يحتفظ بالسبرينتات والأدوار والأحداث، لكنه يقود الـSprint Backlog بحدود للعمل الجاري ويتتبّع زمن الدورة.
• فريق Kanban يضيف إيقاعًا: يحتفظ بالتدفّق المستمر، لكنه يعتمد مراجعة وجلسة استرجاعية في موعد ثابت.

يفشل Scrumban حين يُتّخذ ذريعة لحذف كل ما يزعج: لا هدف، ولا حدود محترَمة، ولا جلسة استرجاعية. وإذا لم يعد الفريق قادرًا على تحديد القواعد التي يتّبعها، فما يمارسه لم يعد Scrumban.

الأخطاء الشائعة في Scrum وفي Kanban

الأنماط المضادة في Scrum

• Product Owner شكلي، لا يملك سلطة فعلية للحسم في الأولويات.
• Scrum Master في دور الكاتب، ينظّم الاجتماعات لكنه لا يزيل أي عائق.
• سبرينت بلا هدف، مجرد قائمة مهام تُخرجها كل حالة طارئة عن مسارها.
• سرعة الإنجاز مؤشرًا للأداء، مما يدفع إلى تضخيم التقديرات.
• جلسة استرجاعية بلا متابعة، تتكرّر فيها المشكلات نفسها سبرينتًا بعد سبرينت.

الأنماط المضادة في Kanban

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

قائمة تحقّق: كيف تختار بين Scrum وKanban

1. هل يمكن تجميع العمل حول هدف يُحافَظ عليه طوال سبرينت (شهر على الأكثر) دون مقاطعة دائمة؟ إن كان الجواب نعم، فScrum مرشّح جيد.
2. هل جزء مهم من الطلبات عاجل وغير متوقَّع؟ فضّل Kanban، أو سعة محجوزة في إطار Scrumban.
3. هل يوجد شخص قادر على الحسم في الأولويات بسلطة حقيقية؟ يحتاج Scrum إلى ذلك منذ البداية.
4. هل المؤسسة مستعدة لتغيير الأدوار والاجتماعات؟ إن لم تكن كذلك، يتيح Kanban البدء بالمسار الحالي.
5. هل يريد أصحاب الطلبات قبل كل شيء معرفة موعد الجاهزية؟ مؤشرات التدفّق تجيب عن ذلك مباشرة.
6. هل تعمل عدة فرق على المنتج نفسه؟ ستحتاج أيضًا إلى إطار للرشاقة على نطاق واسع.

أيًّا كان اختيارك، كوِّن الفريق ومن يحدّدون أولوياته معًا. تقترح Codevista Innovations تكوين Scrum وتكوين Kanban، حضوريًا في جميع أنحاء المغرب، أو بصيغة هجينة، أو عن بُعد، وملف تأهيلنا لتمويل عقود التكوين الخاصة (CSF) لدى مكتب التكوين المهني وإنعاش الشغل (OFPPT) قيد الإنجاز. ولاختيار التكوين المناسب، أو لبناء برنامج مُصمَّم على المقاس انطلاقًا من افتحاص للكفاءات، تواصلوا معنا.

أسئلة شائعة

هل يمكن الانتقال من Scrum إلى Kanban خلال المشروع؟

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

هل يناسب Kanban فريقًا لا يعمل في المعلوميات؟

نعم. لا يفترض Kanban وجود شيفرة ولا برمجيات: يكفي عمل يمرّ بمراحل يمكن تحديدها. ففريق موارد بشرية يدبّر عمليات التوظيف، أو مصلحة مشتريات، أو فريق تسويق، كلّهم يستطيعون جعل تدفّقهم مرئيًا، والحدّ من العمل الجاري، وتتبّع آجالهم. وغالبًا ما يكون Kanban أبسط مدخل إلى الرشاقة بالنسبة للوظائف خارج تكنولوجيا المعلومات.

هل يحتاج فريق Kanban أو Scrumban إلى Scrum Master؟

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

أيّ تكوين أختار بين Scrum وKanban؟

التكوين الذي يوافق العمل الفعلي للفريق. فتكوين Scrum يفيد الـProduct Owner أو الـScrum Master أو الـDevelopers في فريق منتج. أمّا تكوين Kanban فيفيد أكثر مسؤولي الدعم أو الاستغلال أو المصالح الداخلية. وفي مؤسسة ذات عمل مختلط، يُجنّب تكوين المدراء على المنهجيتين معًا تحويلَ اختيار المنهجية إلى صراع بين معسكرات.