كانبان مقابل سكرام: دليلك الشامل لتحقيق المرونة في إدارة المشاريع

دقائق القراءة: 23

مقدمة إلى منهجيّات إدارة المشاريع الرشيقة

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

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

ما هي منهجية سكرام (Scrum)؟

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

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

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

ما هي منهجية كانبان (Kanban)؟

Kanban هي إطار عمل لإدارة المشاريع بصري، نشأ من عملية تطوير البرمجيات المرنة (Lean Software Development) ويُستخدم في إدارة المشاريع الرشيقة (Agile Project Management). كلمة Kanban هي كلمة يابانية تعني "لوحة الإعلانات"، وقد اشتُقت من أساليب التصنيع المرن (Lean Manufacturing) التي ابتكرتها شركة تويوتا (Toyota) اليابانية لتصنيع السيارات.

تُصوّر Kanban عملية العمل والتقدم المحرز من خلال لوحات Kanban Boards. تُستخدم للمنتجات أو الحلول التي تتطلب تسليماً مستمراً، وتهدف إلى موازنة الطلب مع القدرة المتاحة (نظام السحب Pull System) بدلاً من دفع المنتجات إلى السوق (نظام الدفع Push System). الهدف من استخدام Kanban هو إزالة الاختناقات خلال عملية الإنتاج لضمان تدفق المشروع بسلاسة مع الحفاظ على الميزانية. غالباً ما تُستخدم بالاشتراك مع منهجيات رشيقة أخرى مثل Scrum.

تاريخ تطور المنهجيتين

تطور سكرام (Scrum)

ذُكرت منهجية Scrum لأول مرة في مقال نُشر عام 1986 في مجلة Harvard Business Review بعنوان "The New New Product Development Game" (لعبة تطوير المنتجات الجديدة الجديدة) بقلم هيروتاكا تاكيوتشي (Hirotaka Takeuchi) وإيكوجيرو نوناكا (Ikujiro Nonaka). وصف المؤلفان هذه العملية، التي أطلقا عليها في البداية اسم "النهج الشمولي" أو "نهج الرغبي"، كعملية تطوير جديدة من شأنها زيادة سرعة ومرونة طرح المنتجات التجارية في السوق. رأوا أنها "جيدة في إحداث الابتكار بشكل مستمر، تدريجي، ولولبي".

شهد عام 1993 الاستخدام الأولي لهذه المنهجية من قبل جيف ساذرلاند (Jeff Sutherland) بالتعاون مع جون سكومنيوتاليس (John Scumniotales) وجيف ماكينا (Jeff Mckenna) في شركة Easel Corporation. بعد عامين، قدم ساذرلاند وكين شفايبر (Ken Schwaber) ورقة بحثية تصف منهجية Scrum في مؤتمر البرمجة الشيئية والأنظمة واللغات والتطبيقات لعام 1995 (OOPSLA '95) في أوستن، تكساس. كما كتب شفايبر أول نص عن Scrum في عام 2001 بالتعاون مع مايك بيدل (Mike Beedle) بعنوان "Agile Software Development with Scrum".

في العام نفسه، قام المؤلفان، بالإضافة إلى ساذرلاند و14 خبيراً آخر في Scrum، بصياغة بيان Agile Manifesto (البيان الرشيق) في يوتا، والذي حدد مبادئ وميزات وقيم هذه المنهجية. تأسس تحالف Scrum Alliance في عام 2002 بواسطة شفايبر لتوفير هيئة إدارية لمنهجية Scrum، بالإضافة إلى شهادة رسمية من خلال برنامج CSM (Certified ScrumMaster). غادر شفايبر التحالف لاحقاً في عام 2009 لتأسيس Scrum.org، وهي المسؤولة عن سلسلة اعتماد Professional Scrum Accreditation Series. منذ عام 2010، قدمت وثيقة تُسمى Scrum Guide (دليل سكرام) إرشادات لمنهجية Scrum وتمت مراجعتها بانتظام، مع إصدار أحدث نسخة في نوفمبر 2017.

تطور كانبان (Kanban)

بدأت Kanban كمنهجية تصنيع تم الترويج لها في مصانع تويوتا (Toyota) بواسطة تاييتشي أونو (Taiichi Ohno)، المعروف بأنه "أبو نظام إنتاج تويوتا" (Toyota Production System). كان أونو يبحث عن طريقة لزيادة الإنتاجية وتقليل الهدر خلال عملية تصنيع السيارات، مع تجنب إنتاج منتجات لا يمكن بيعها وتسبب خسائر للشركة.

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

كان جزء كبير من هذه العملية هو نظام الاتصال الذي استخدم بطاقات بصرية تُسمى Kanban، والتي وضحت للعمال في كل مرحلة من مراحل تصنيع السيارة ما يجب القيام به والمواد المطلوبة، بعبارات واضحة. كما عدلت عدد السيارات المصنعة ليتناسب مع طلب الجمهور بدلاً من استخدام كامل الطاقة الإنتاجية. عُرفت هذه العملية أيضاً باسم التصنيع المرن (Lean Manufacturing) أو الإنتاج "في الوقت المناسب تماماً" (Just in Time).

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

أصبحت Kanban شائعة في صناعات الخدمات والمعرفة بفضل عمل ديفيد جيه أندرسون (David J. Anderson). كان أندرسون معجباً بعملية التصنيع المرن، وطبق نظام سحب للتطوير متأثراً بفلسفة Kanban لأونو أثناء عمله مع مجموعة هندسة الدعم (XIT Sustaining Engineering) في مايكروسوفت (Microsoft) عام 2004. شهدت السنوات القليلة التالية قيام أندرسون وبعض زملائه بتشكيل ميزات ومبادئ منهجية Kanban. انتشرت منهجية Kanban من خلال مؤتمرات ولقاءات الإدارة، وبدأت المزيد من الشركات في اعتمادها. جمع أندرسون تجاربه مع Kanban في كتاب نُشر عام 2010 بعنوان "Kanban: Successful Evolutionary Change for your Technology Business"، والذي يُعتبر التعريف الأكثر شمولاً لمنهجية Kanban للعاملين في مجال المعرفة.

مبادئ وقيم سكرام (Scrum)

لوحة سكرام توضح سير العمل في مشروع رشيق

أصبحت منهجية إدارة المشاريع Scrum جزءاً من نُهج تطوير Agile التي انتشرت في أواخر التسعينيات وأوائل الألفينيات. كانت هذه الجهود تسعى لإيجاد حل لمعدل الفشل المرتفع في تطوير البرمجيات. كان نهج "الشلال" (Waterfall Development) الذي كان يُستخدم بشكل أساسي قبل هذه النقطة في صناعة البرمجيات جامداً وغير مرن – حيث كان تطوير المنتج يجب أن يتبع إجراءات ووثائق محددة بدقة. سمح Scrum لمطوري البرمجيات بالمرونة والحرية للاستجابة للتغييرات في التطوير. كما دعا إلى إشراك العميل في عملية التطوير بدلاً من أن يكون مجرد متفرج. انتشرت هذه المنهجية لاحقاً إلى صناعات أخرى.

أصبح Scrum الأكثر استخداماً بين منهجيات إدارة المشاريع الرشيقة – تشير الأبحاث إلى أنه يُستخدم في 66% من جميع المشاريع التي تدمج طرق تطوير Agile. Scrum سهل الفهم والمتابعة لأنه يتجنب التعليمات والإجراءات الصارمة. مع Scrum، يمكن للمؤسسات القيام بكل ما هو ضروري لإنجاز المشروع، والتكيف مع الظروف التي قد تنشأ فجأة. هذه المرونة هي أحد الأسباب التي تجعل إريك نايبرغ (Eric Naiburg)، نائب رئيس التسويق في scrum.org، يصف Scrum بأنه "عكس قائمة المهام" (opposite of a to-do list). تقسيم المشاريع إلى Sprints يجعلها مناسبة للمشاريع المعقدة، بينما يعزز إشراك العميل في عملية التطوير الشفافية.

بيان أجايل (The Agile Manifesto)

سعى بيان Agile Manifesto في عام 2001 إلى معالجة الإحباطات بين مطوري مشاريع البرمجيات، وخرج بأربعة مبادئ. اليوم، تُعد هذه المبادئ حجر الزاوية في فلسفة إدارة المشاريع Scrum وقد انتشرت خارج صناعة البرمجيات. تنص هذه المبادئ على أن المشاريع يجب أن تُقدّر:

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

أفضل ممارسات سكرام (Scrum Best Practices)

هناك بعض أفضل الممارسات التي تدعم منهجية Scrum:

  • ضمان رضا العملاء من خلال التسليم المبكر والمستمر للمنتج.
  • اختبار ودمج ملاحظات مالك المنتج (Product Owner) يومياً.
  • الترحيب بالمتطلبات المتغيرة والاستجابة لها حتى في مراحل متأخرة من عملية التطوير.
  • العمل جنباً إلى جنب مع العميل في عملية التطوير.
  • توفير الدعم والبيئة للأفراد المتحمسين لإنجاز العمل.
  • التركيز على التواصل وجهاً لوجه داخل الفريق ومع الفريق.
  • قياس التقدم من خلال حل/منتج عامل.
  • تعزيز التطوير بوتيرة مستدامة.
  • تحسين المرونة من خلال التفاني في التميز التقني والتصميم الجيد.
  • الفرق ذاتية التنظيم هي أفضل طريقة للحصول على أفضل بنية ومتطلبات وتصاميم.
  • إجراء مراجعات منتظمة لتحسين الفعالية من خلال مراجعات Sprint وتعديل الإجراءات لتناسب ذلك.
  • احترام التوازن بين الحياة المهنية والخاصة لأعضاء الفريق للحفاظ على الإجهاد عند الحد الأدنى.

فوائد سكرام (Benefits of Scrum)

تُعد منهجية Scrum الأكثر استخداماً في إدارة المشاريع الرشيقة للأسباب التالية:

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

عيوب سكرام (Drawbacks of Scrum)

مثل أي شيء آخر، فإن عملية Scrum لها حدودها. إليك بعض منها:

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

عملية سكرام (The Scrum Process)

فرق سكرام (Scrum Teams)

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

يجب ألا يزيد عدد أعضاء فريق Scrum المثالي عن 9 أعضاء لتعزيز روح الفريق والتقارب والفعالية. من المهم أيضاً أن يكون أعضاء الفريق في نفس الموقع الفعلي أو على الأقل متصلين بالإنترنت باستمرار إذا كانوا يعملون عن بعد. تقدم فرق Scrum الحلول بزيادات، مع دمج آراء مالك المنتج (Product Owner) في كل تكرار للمنتج. يضمن هذا التوفر المستمر لمنتج وظيفي.

هناك 5 قيم أو مبادئ يجب على كل فريق Scrum الالتزام بها ليكون فعالاً:

  • الالتزام (Commitment): العمل نحو أهداف الفريق في كل Sprint.
  • الشجاعة (Courage): القدرة على فعل الشيء الصحيح على الرغم من النزاعات والتحديات.
  • التركيز (Focus): التركيز حصرياً على أهداف الفريق و Sprint Backlog.
  • الانفتاح (Openness): الشفافية مع بعضهم البعض حول العمل وتحدياته.
  • الاحترام (Respect): احترام كل فرد من أعضاء الفريق.

أدوار سكرام (Scrum Roles)

هناك ثلاثة أدوار مميزة في أي فريق Scrum: مالك المنتج (Product Owner)، وسكرام ماستر (Scrum Master)، وفريق التطوير (Development Team).

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

أحداث سكرام (Scrum Events)

التواصل حيوي في إطار عمل Scrum. يتجسد هذا في الأحداث أو الاجتماعات الخمسة حيث يتم تبادل المعلومات حول عملية التطوير بانتظام:

  • تحسين قائمة مهام المنتج (Backlog Refinement): يراجع مالك المنتج بانتظام قائمة مهام المنتج (Product Backlog) التي تشير إلى قائمة ميزات المنتج، والعمل الذي يجب القيام به، وتسلسل التسليم. يتأكد من أن قائمة المهام مُعدّة بشكل صحيح بطريقة توصل لأعضاء الفريق ما يجب القيام به في كل Sprint. أحياناً، يجب تعديل ترتيب العمل بسبب ملاحظات العملاء أو مراجعات من فريق التطوير. تحدد مراجعة قائمة المهام، التي تتم بين اختتام Sprint وقبل بدء Sprint جديد، أولويات الميزات بناءً على عوامل مثل القيمة التجارية والمخاطر وتاريخ الحاجة إلى الميزات. عادة ما تسلم هذه المراجعة محتوى Sprint التالي.
  • تخطيط سبرينت (Sprint Planning): يتم هذا في بداية Sprint لتخطيط ما يجب على فريق Scrum العمل عليه. تُسمى الأجزاء الأصغر التي يُقسم إليها المشروع Sprints. يمكن أن تستمر من أسبوع إلى شهر. يختار الفريق في اجتماع Sprint، الذي يستغرق في المتوسط أربع ساعات لـ Sprint مدته أسبوعين، عناصر قائمة المهام (Backlog Items) التي يمكن إكمالها خلال Sprint، وكيف سيتم العمل عليها، والهدف من Sprint. يتم تضمين كل هذه في قائمة مهام Sprint (Sprint Backlog).
  • سكرام اليومي/الوقوف (Daily Scrum/Stand Up): هو اجتماع وقوف يومي سريع يستمر 15 دقيقة كحد أقصى. يتم مراجعة عمل اليوم السابق وتحديد التحديات من قبل الفريق وكذلك الأعضاء الفرديين. يتم تكليف فرد بالحصول على حلول لأي تحديات تم تحديدها، ويتم إبراز أي عمل غير مكتمل من اليوم السابق بواسطة Scrum Master على لوحة Scrum. لا يُسمح بالمناقشات التفصيلية خلال اجتماعات Scrum. يتم الاتفاق أيضاً على الاستراتيجية التي ستُستخدم لعمل اليوم.
  • مراجعة سبرينت (Sprint Review): يُستخدم هذا الاجتماع الذي يُعقد في نهاية Sprint لمراجعة أداء الفريق. إذا تم الانتهاء من عمل اليوم، يتم عرض تكرار المنتج ثم تقديمه للعميل/المستخدم النهائي جنباً إلى جنب مع قائمة مهام Sprint التي تحتوي على العناصر "المنجزة" للحصول على ملاحظاتهم. يمكن لمالك المنتج أيضاً إجراء تعديلات على قائمة مهام المنتج (Product Backlog) في هذه المرحلة. المدة الموصى بها للاجتماع عادة ما تكون أربع ساعات كحد أقصى.
  • الاستعراض الاسترجاعي لسبرينت (Sprint Retrospective): هذه فرصة لفريق Scrum للتفكير في مدى فعاليتهم وما يمكن تحسينه لزيادة الإنتاجية في المرة القادمة.

مخرجات سكرام (Scrum Artifacts)

يشير هذا إلى الأدوات الشائعة الاستخدام في عملية Scrum. هذه ثلاثة منها تُستخدم لتسجيل تقدم فريق Scrum بالإضافة إلى تفاصيل المشروع:

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

مبادئ وممارسات كانبان (Kanban Principles and Practices)

لوحة كانبان توضح مراحل سير العمل وحدود العمل قيد الإنجاز

مبادئ كانبان (The Kanban Principles)

هناك أربعة مبادئ أساسية تشكل حجر الزاوية لتطبيق ناجح لمنهجية Kanban:

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

ممارسات كانبان (Kanban Practices)

لكي يكون تطبيق Kanban فعالاً، هناك ست ممارسات Kanban يجب على الفرق تطبيقها:

  • تصوير عملية سير العمل (Visualize the Workflow Process): هذه هي الخطوة الأولى عند استخدام منهجية Kanban. يجب توضيح العملية المستخدمة لتقديم المنتجات/الخدمات من قبل المؤسسة، بالإضافة إلى تدفقها، على لوحة Kanban Board التي يمكن أن تكون مادية أو إلكترونية. تمثل كل خطوة في سير العمل عموداً على اللوحة. تُشار إلى عناصر العمل المختلفة ببطاقات Kanban Cards بألوان مختلفة. يمكن تجميع مجموعة من عناصر العمل ذات الصلة باستخدام ممرات Kanban Swimlanes. الهدف الرئيسي من هذه هو أن يفهم جميع الأطراف عمل عملية سير العمل من طلب العميل إلى تسليم المنتج/الخدمة النهائية، بالإضافة إلى تحسين التواصل والتعاون. بهذا، يمكن تتبع وتحليل مناطق مختلفة من عملية العمل لتحديد العوائق المحتملة التي يمكن العمل عليها.
  • تحديد العمل قيد الإنجاز (Limit the Work in Progress - WIP): مع Kanban، يجب العمل على عدد يمكن إدارته من عناصر العمل في وقت واحد مع وضع حد على العمل قيد الإنجاز (WIP) الذي يمكن التعامل معه. يجب إكمال العمل الحالي قبل الانتقال إلى "سحب" مهمة جديدة. تثبط Kanban تعدد المهام لأنه يؤدي إلى الهدر وعدم الكفاءة. تؤكد حدود WIP في لوحات الأعمدة على أهمية اختيار العمل الذي يجب على الفريق القيام به في الوقت الحالي بعناية نظراً لوجود قدرة محدودة يجب استخدامها بكفاءة. يساعد التركيز على WIP أيضاً على تقليل أوقات الدورة (Cycle Times) (المدة من طلب العميل إلى التسليم النهائي) لمنتج/خدمة معينة.
  • إدارة سير العمل (Manage the Workflow): مع منهجية Kanban، يتم إبراز مراحل سير العمل المختلفة وتقدم العمل في كل منها على لوحة Kanban Board. تؤكد Kanban على إدارة عملية سير العمل بدلاً من الإدارة الدقيقة للأشخاص، والهدف الرئيسي من تطبيقها هو تدفق عملية العمل بسلاسة على المستويات المثلى. يتيح هذا للفريق تحليل عملية سير العمل عن طريق قياس الإنتاجية/الكفاءة بمقاييس مثل وقت الدورة (Cycle Time) وأوقات الانتظار (Lead Times). هذا يجعل من السهل اكتشاف أي عوائق في عملية سير العمل. في معظم الأحيان، تكون هذه العوائق في مراحل الانتظار الوسيطة حيث يجب أن يتغير العمل، ولكن أحياناً تلعب عوامل أخرى مثل كفاءة العمال دوراً. أينما وجدت، يتم إجراء تعديلات في عملية العمل لإزالتها وتحسين سير العمل. سيمكن هذا من تقليل أوقات الدورة للمنتج أو الخدمة، مما يضمن سرعة الاستجابة وتقديم قيمة أفضل للعملاء.
  • توصيل سياسات العملية بوضوح (Communicate the Process Policies Clearly): جزء كبير من Kanban هو توصيل السياسات وقواعد العملية حول كيفية إجراء العمل بشكل صريح لجميع الأطراف المعنية بحيث يكون هناك فهم واضح لما هو متوقع من كل شخص. يساعد هذا في توفير معيار يمكن من خلاله قياس الأداء ويضمن اتساق الجودة في المنتج/الخدمة المقدمة. يجب أن تكون هناك قواعد وإرشادات لعملية العمل لكل عمود مثل من يسحب ماذا، ومعايير الدخول والخروج للعمود، ومتى يتم الانتهاء من المهمة، وما إلى ذلك، والتي يجب تصويرها على لوحة Kanban Board. هذا يبقي الجميع بمرجع بصري في المؤسسة وهم يعملون نحو هدف مشترك.
  • الحصول على ملاحظات بانتظام وتطبيقها (Get Feedback Regularly and Implement It): الملاحظات مهمة جداً لمنهجية Kanban. تُعد مراجعة وتحليل مراحل سير العمل على لوحة Kanban Board خلال اجتماعات الوقوف اليومية فرصة جيدة لذلك. يجب أيضاً مراجعة كل جانب من جوانب سير العمل المختلفة مثل التسليم والعمليات بشكل فردي لتتبع تقدمها. يجب على أعضاء الفريق أيضاً التعليق على ملاحظاتهم الفردية خلال اليوم السابق. يجب أن تكون هذه الاجتماعات اليومية قصيرة ومباشرة. يجب وضع الخطط موضع التنفيذ للعمل على جميع الملاحظات المستلمة. يساعد الحصول على كل هذه الملاحظات مبكراً في العملية على إجراء تحسينات سريعة لتحسين أوقات الدورة والإنتاجية التنظيمية.
  • التجربة والتحسين المستمر (Always Experiment and Improve): يتيح نمط التغيير التطوري في Kanban استخدام طريقة البحث العلمي التي تتضمن تشكيل نظرية، واختبارها، وتعديلها لتكون أفضل. يجب تقييم عملية سير العمل وتحسينها باستمرار. يمكن إدخال تقنيات جديدة بشكل تدريجي في عملية سير العمل ومراقبتها، ثم يجب اتخاذ قرار للاحتفاظ بها أو إزالتها اعتماداً على مقدار التحسين الذي تجلبه للعملية من خلال تقييم قياسات المقاييس. أحياناً، تحتاج هذه التقنيات فقط إلى بعض التعديل لتعمل على النحو الأمثل. التحسين المستمر هو حجر الزاوية في منهجية Kanban.

عملية كانبان (The Kanban Process)

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

لوحة كانبان (The Kanban Board)

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

تتكون لوحة Kanban Board عادة من ثلاثة أعمدة رئيسية:

  • للقيام بها (To Do): تُدرج هنا المهام التي لم يتم البدء فيها.
  • قيد التنفيذ (Doing): تُدرج هنا المهام التي يجري العمل عليها.
  • تم الإنجاز (Done): يتكون هذا من المهام التي تم إكمالها.

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

فوائد كانبان (Benefits of Kanban)

يتم اعتماد Kanban بسرعة من قبل المؤسسات في مختلف الصناعات عالمياً. تتضمن بعض أسباب ذلك ما يلي:

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

عيوب كانبان (Drawbacks of Kanban)

لمنهجية Kanban أيضاً حدودها:

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

أوجه التشابه والاختلاف بين سكرام وكانبان

تُعد Scrum و Kanban أكثر أدوات تحسين الإنتاجية اعتماداً على مستوى العالم، لكنهما ليستا بديلين مباشرين لبعضهما البعض كما يعتقد معظم الناس. لديهما بعض أوجه التشابه، ولكن هناك أيضاً اختلافات بينهما.

أوجه التشابه (Similarities)

كلا من Scrum و Kanban أدوات لتحسين الإنتاجية والكفاءة وتقليل الهدر. كلاهما يعتمد على تقنية إدارة المشاريع الرشيقة (Agile Project Management) التي تؤكد على المرونة والقدرة على التكيف مع التغييرات. كما أنهما يعملان على تقنية جدولة "السحب" (Pull Scheduling). كلاهما يرى أن تحسين جودة المنتج أو الخدمة وأوقات التسليم هو حجر الزاوية في كلتا التقنيتين. كلاهما يعتمد على روح التنظيم الذاتي حيث يتخذ أعضاء الفريق مبادراتهم وإجراءاتهم الخاصة، وكل عضو متساوٍ مع الآخر، ولا تأتي الأوامر من الخارج. عادة ما تُقسم المهام المعقدة إلى أجزاء أصغر يمكن إدارتها.

سكرامبان (Scrumban)

في العديد من المؤسسات اليوم، تُستخدم Scrum و Kanban معاً فيما يُعرف بـ Scrumban. تم إنشاء هذا في الأصل للفرق التي تنتقل من Scrum إلى Kanban، ولكنه أصبح منهجية لإدارة المشاريع بحد ذاتها. بموجب هذه المنهجية، تُستخدم عملية Scrum ولكن يُنظر إليها من خلال عدسة نظام تحسين Kanban. تُستخدم لوحة مشابهة للوحة Kanban Board مع بطاقات ملونة. يُقسم العمل إلى تكرارات. تُستخدم حدود العمل قيد الإنجاز (WIP Limits) هنا بينما يختار أعضاء الفريق المهام التي سيعملون عليها لأنهم ذاتيو التنظيم. يُعد التخطيط عند الطلب (On-demand planning) ميزة لـ Scrumban. هذا هو تطبيق تقنيات التخطيط عندما تتوفر مهام جديدة بدلاً من يومياً. يتم تحديد أولويات المهام بحيث يعرف أعضاء الفريق المهام المهمة.

الاختلافات (Differences)

هناك العديد من الاختلافات بين Scrum و Kanban. تتضمن هذه:

الميزة سكرام (Scrum) كانبان (Kanban)
التعريف إطار عمل بقواعد وتقنيات محددة. أداة لتصوير سير العمل تُستخدم جنباً إلى جنب مع نظام موجود.
التدريب والإدارة يتطلب الكثير من التعليم والتدريب، بالإضافة إلى إدارة ومحترفين ذوي خبرة. يمكن فهمها بسهولة من قبل الجميع مما يجعل تشغيلها وإدارتها أرخص.
عملية التغيير مناسبة للمؤسسات التي تحتاج إلى تغيير شامل وسريع. تشجع التغيير التدريجي ومناسبة للمؤسسات ذات هياكل سير العمل الجيدة والمستقرة.
الاستخدام أكثر فائدة للمشاريع الأكبر والأكثر تعقيداً. تُستخدم عادة للمشاريع الأصغر.
الأدوار ثلاثة أدوار محددة: Scrum Master، Product Owner، فرق التطوير (Development Teams). لا توجد أدوار محددة، حيث يمكن لكل عضو في الفريق تولي المهام المتاحة.
المدة تستمر عملية Scrum لمدة المشروع/التطوير وتبدأ من جديد مع مشروع جديد. جهد مستمر حيث يتم التعامل مع المنتجات/الخدمات التي يجب تسليمها باستمرار.
الفرق تدعو إلى فرق متعددة الوظائف. الفرق المتخصصة هي القاعدة.
المهام الجديدة/التكرارات لا يمكن إضافة عناصر جديدة خارج المهام المخطط لها مسبقاً لـ Sprint. يمكن العمل على مهام جديدة طالما أن القدرة متاحة.
الملكية يمتلك فريق Scrum واحد قائمة مهام Sprint. يمكن مشاركة لوحة Kanban Board من قبل أكبر عدد ممكن من الفرق.
قياس الإنتاجية تقيس الإنتاجية باستخدام السرعة (Velocity) خلال Sprints. تقيس الإنتاجية باستخدام وقت دورة المنتج/الخدمة (Cycle Time).
أهداف الفريق يركز الفريق على التعاون وإكمال مهمة محددة مسبقاً. يركز الفريق على تحديد الأهداف وتقليل أوقات الدورة.

الخلاصة التقنية

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

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

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *