رشيقة مقابل الشلال | الإيجابيات والسلبيات والاختلافات الرئيسية | الدليل

غالبًا ما يقارن الناس بين الشلال والرشاقة ويجادلون بأن أحدهما أفضل من الآخر. كما تدور المناقشات أيضًا حول المتطلبات البسيطة مقابل المتطلبات المعقدة، وإذا كانت بسيطة فالشلال، وإذا كانت معقدة فاستخدم أحد الأساليب الرشيقة. هل الأمر بهذه البساطة؟ هل المقارنة على أساس نوع المتطلبات صحيحة؟
هناك جدال آخر حول التنبؤي مقابل التجريبي وإذا كان تنبؤياً فالشلال ثم النهج الرشيق. يقوم الناس أيضًا بالمقارنة بين المشروع مقابل المنتج. إذا كان لديك مشروع (غالبًا ما يشار إليه بالوقت الثابت والتكلفة الثابتة) فاختر الشلال، وإذا كان لديك منتج يتم بناؤه بناءً على رد فعل السوق، فاختر أحد النهج الرشيقة. لا أرى أشخاصًا يأخذون بعين الاعتبار السياق الكامل وهذا يحيرني. دعونا نتحدث عن مشروع تنبؤي معقد مثل إعداد نظام التعافي من الكوارث، أو أتمتة المصنع، أو طرح الموارد البشرية في SAP في 28 دولة متعددة في وقت واحد أو أتمتة خط أنابيب التسليم.
لدينا هنا عمل تنبؤي مثل إعداد بيئة شبيهة بالإنتاج لنظام التعافي من الكوارث الذي يجب أن يعمل إذا لزم الأمر كما هو متوقع، وأتمتة المصنع وخط أنابيب التسليم الآلي لتحسين الجودة والإنتاجية، واعتماد ممارسات الموارد البشرية المرنة في جميع أنحاء الشركة من خلال SAP HR. ما هو النهج الذي تقترحه في هذه السيناريوهات؟ هل يجب أن يكون شلالاً أم رشيقاً؟ هل يمكن أن يكون لدينا إصدار تدريجي لكل هذه الأمور إذا اخترنا النهج الرشيق؟ إذا كانت الإجابة بنعم، هل ستكون هذه الإصدارات الصغيرة متاحة بسهولة في غضون شهر؟ إذا كانت الإجابة لا، فهل يجب أن نتبع نهج الشلال؟ أم يجب أن نجرب WaterScrumFall أو ScrumBan أو WaterKanban؟ أو ربما SAFe (إطار العمل الرشيق المتدرج) الذي يتحدث عن تنفيذ البرنامج من خلال تخطيط وتنفيذ أطول يعرف باسم قطار الإصدار الرشيق؟
أجايل عندما أقول أجايل يشير إلى بيان تطوير البرمجيات الرشيقة الذي حدده 17 مطورًا في فبراير من عام 2001 ويتكون من 4 قيم و12 مبدأ. يدعي الكثيرون أن طريقة عمل أجايل كانت موجودة قبل عام 2001 وأعتقد أن هذا صحيح لأن Scrum تم تقديمه من خلال ورقة HBR “لعبة تطوير المنتجات الجديدة” في عام 1986. أعترف بجهلي بأي شيء أبعد من ذلك، لذا سأتوقف عند هذا الحد. ومع ذلك، نرى الآن العديد من الإصدارات من أجايل مثل طريقة العمل الرشيقة، ورشاقة الأعمال الرشيقة للمؤسسات، وما إلى ذلك.
الشلال هو عبارة عن تنفيذ العمل على مراحل أو تسلسل كما نفعل في مركز البيانات – التخطيط والتصميم والبناء والتركيب والتشغيل والتحسين والتقييم، وما إلى ذلك، ويتضمن تخطيط السعة وتحليل التكلفة والأعمال المدنية والمشتريات والتركيب وشهادة التشغيل وما إلى ذلك. لا يمكن أن تسير هذه الأمور بالتوازي مثل ما نفعله في تطوير البرمجيات حيث يتم تنفيذ كل شيء بالتوازي أو بالتداخل. غالبًا ما يتم الاستشهاد بأول وصف رسمي لنموذج الشلال في مقالة كتبها وينستون دبليو رويس عام 1970، على الرغم من أن رويس لم يستخدم مصطلح الشلال في تلك المقالة. قدم رويس هذا النموذج كمثال على نموذج معيب وغير قابل للتطبيق؛ وهي الطريقة التي يستخدم بها المصطلح بشكل عام في الكتابة عن تطوير البرمجيات – لوصف وجهة نظر نقدية لممارسة تطوير البرمجيات الشائعة الاستخدام. ربما كان أول استخدام لمصطلح “الشلال” في ورقة بحثية كتبها بيل وثاير عام 1976. المصدر – ويكيبيديا
اكتشف أفضل شهادات Agile & Scrum لعام 2025. عزز حياتك المهنية مع أفضل البرامج التدريبية. اعثر على الشهادة المثالية لتطورك المهني! اعثر على الشهادة المثالية
يمكن أن يُنظر إليها بهذه الطريقة إذا قرأتها بشكل خاطئ، ولكن هل تروج للتخطيط والتنفيذ لمرة واحدة؟ الصورة أدناه تروج بوضوح للتخطيط والتنفيذ المستمرين وتتحدث عن المراقبة والتحكم المنتظمين. إنها تتحدث عن نفس دورة PDCA (التخطيط-التخطيط-التحقق-التنفيذ) التي تحدثنا عنها باسم التطوير الرشيق وتنص على أن البدء والإغلاق هو مرة واحدة وهذا أيضًا لا ينطبق على مستوى المشروع ولكن على جميع المراحل.
تتحدث مجموعة معارف إدارة المشاريع (PMBOK) عن مجالات المعرفة وأدوات العمليات والتقنيات. هذه المعرفة مفيدة حقًا حتى في سياق رشيق. يتعلق الأمر بالفهم فيما يتعلق بإدارة المتطلبات وإدارة النطاق وإدارة الجودة وإدارة المخاطر وإدارة أصحاب المصلحة. ستجد الكثير من الأدوات والتقنيات لإدارة العمل. يتحدث PMBOK عن خمس مراحل للمشروع وهي
إذا كنت تتحدث من حيث المشروع فلا يوجد خطأ في PMBOK ويناسب تمامًا المشروع المعقد التنبؤي. فهي تعرّف المشروع بأنه مسعى مؤقت يتم القيام به لإنشاء منتج أو خدمة أو نتيجة فريدة من نوعها. والتوقع هنا هو أن تكون المتطلبات واضحة (ربما معقدة ولكنها واضحة) ويتم تحديد التقنيات والعمليات والأدوات المعقدة المطلوبة للتنفيذ ومتاحة. وعادةً ما تستغرق هذه المشاريع ما بين 5 أشهر إلى 5 سنوات. يتعلق معظم المشاريع بإنجاز العمل وتسليمه إلى فريق العمليات لتشغيله وصيانته واستدامته.
إن منتج البرمجيات النموذجي لديه بعض التحديات الأساسية التي لا تتناسب مع هذه الدورة مثل المتطلبات المتغيرة بشكل متكرر لأنها تعتمد على دورة التغذية الراجعة وبالتالي تتطلب دورات أكثر تواتراً (من ماذا؟) والقيام بجميع الخطوات كما هو مذكور في PMBOK قد لا يكون ممكناً أو مطلوباً.
كما أن دورة تطوير المنتج مستمرة وليست مؤقتة ويستمر العمل في الظهور كلما تم تعلم المزيد عن توقعات العملاء، واحتياجات العمل المتغيرة، وحتى ترقية التكنولوجيا. يبدأ تطوير المنتج بفكرة ويستمر حتى تقاعد المنتج، لذا فإن التخطيط والتصور لدورة الحياة بأكملها مقدمًا غير ممكن.
حتى أن Scrum (نهج Agile الأكثر شيوعًا) يذكر المشروع وينص بوضوح على أن كل دورة (Sprint) يمكن اعتبارها مشروعًا.
وقد أظهرت الدراسات الحديثة في إدارة المشاريع اختلافًا كبيرًا في معدلات النجاح بين منهجيات أجايل ومنهجيات الشلال. على وجه التحديد، وُجد أن المشاريع الرشيقة أكثر نجاحًا بنسبة 28% تقريبًا مقارنةً بمشاريع الشلال.
يركز بيان أجايل بشكل أساسي على تطوير البرمجيات ويتكون من 4 قيم و12 مبدأ. أنا لا أقتبس هذه المبادئ هنا لأنها خاصة جداً بتطوير البرمجيات ولكن القيم المذكورة ذات صلة بالعديد من المجالات الأخرى ويمكن تفسيرها بسهولة من قبل أي شخص يفهم في تطوير المشاريع أو المنتجات.
يشجع البيان بأكمله على اتباع نهج يركز على الأشخاص بدلاً من وجود عمليات جامدة لمعالجة العمل التكيفي المعقد.
اكتشف لماذا تعتبر شهادة Scrum Master الخيار الأفضل لإدارة المشاريع الفعالة اليوم. ارتقِ بمهاراتك مع أفضل تدريب متاح، سجل اليوم!
كما ذكرت سابقًا، يعتمد الأمر على طبيعة العمل ولكن دعنا أيضًا نستكشف ما إذا كان النهجان يتعارضان حقًا مع بعضهما البعض أم أنهما يكملان بعضهما البعض. وجهة نظري حول هذين النهجين هي إذا كنت تتحدث عن إدارة المشاريع، فإن نهج معهد إدارة المشاريع يناسبك بشكل أفضل ولكن تبني قيم أجايل أمر منطقي.
على سبيل المثال، هل يمكن لفريق المشروع أن يكون أكثر تعاوناً في التعامل مع القضايا المعقدة من خلال محادثة بسيطة بدلاً من المرور عبر العمليات المعلنة؟ إذا كانت الإجابة بنعم، فلماذا لا تتبنى هذه القيم هناك؟ هل يمكننا الذهاب إلى أبعد من ذلك؟
نعم، يمكننا أن نتعلم بعض الممارسات الجيدة من إطار عمل سكروم حتى لو لم يكن لدينا زيادات قابلة للإصدار في نهاية سكروم ولا يمكننا الإنتاج. ولكن لا يزال بإمكاننا ممارسة سكروم اليومي، والمراجعة الشهرية، وقيم سكروم الخاصة بكل منها. إذا كنت تتحدث عن تطوير المنتجات المعقدة، فإن الأساليب الرشيقة مثل Scrum و XP و LeSS و Lean وغيرها من الأساليب المماثلة تكون أكثر منطقية. ولكن حتى في تلك الحالات، فإن مجالات المعرفة والتقنيات والأدوات من PMBOK مثل إدارة المتطلبات وإدارة الجودة وإدارة المخاطر وإدارة أصحاب المصلحة تضيف قيمة لأن هذه هي المعرفة وليست العملية وهذه المعرفة لا تزال مطلوبة ومفيدة.
ويتعلق هذا الأمر أكثر بالهيكل التنظيمي والعمليات والأشخاص داخل المنظمة لتبني النهج المرن من أجل الاستجابة للتغيرات السريعة في عالم VUCA. إن طريقة العمل الرشيقة هي أكثر بكثير من مجرد طريقة عمل رشيقة مقابل الشلال وتحتاج إلى مزيد من الوقت لفهمها وأعدك بالكتابة عنها في يوم آخر.
فالشلال هو نهج خطي متسلسل، في حين أن الأجايل هو نهج تكراري وتدريجي، يعزز المرونة والتحسين المستمر.
الشلال هو الأفضل للمشاريع ذات المتطلبات المحددة جيدًا وغير المتغيرة، وحيث تكون المراحل المتسلسلة ضرورية.
نعم، تجمع المناهج الهجينة مثل WaterScrumFall و ScrumBan بين عناصر من كلتا المنهجيتين لتناسب احتياجات المشروع المحددة.
نافين هو مدرب رشيق محترف ويعمل بشكل مستقل منذ فترة طويلة في منطقة آسيا والمحيط الهادئ. وهو يعمل مع فريق تطوير البرمجيات وفريق المنتج لتطوير منتجات رائعة بناءً على عمليات تجريبية.