تويت
كثيرًا ما نسمع في أوراق المؤتمرات والمناقشات كيف يحل الناس مشاكل النهج الشلال من خلال تطبيق أساليب Agile و Scrum و XP و Kanban وجمیع الكلمات الرئيسية التي نسميها.
أولاً، نحتاج إلى تعریف النهج الرشيق والنهج الشلال.
ما هو النهج الرشیق (Agile)؟
هي واحدة من أبرز أساليب تطوير البرمجيات التي تتبع نهجًا تدريجيًا لأداء المهام. الفكرة هي تقديم المنتجات بشكل أسرع باستخدام تطبيقات تخطيط موارد المؤسسات مع الحفاظ على سلامة الطريقة. إنه نهج مشروع ينتج عن التفكير الخالي من الهدر حيث يتم دفع المتطلبات والحلول من خلال التعاون الجماعي بين الفرق والمستخدمين النهائيين. إنه نهج حديث للتنمية يركز على التعلم التطبيقي، والتسليم التدريجي، والتطوير المتکامل، والتكرار المستمر. يسمح هذا بإجراء تغييرات خلال دورة التطوير التي توفر المرونة لمراقبة تقدم المشروع وبالتالي تقليل مخاطر الفشل.
ما هو النهج الشلال (Waterfall)؟
هو نهج تقليدي يتبع عملية تصميم متسلسلة يمكن أن تكون صارمة في بعض الأحيان. تنقسم دورة التطوير إلى سلسلة من الأحداث بدءًا من متطلبات التوثيق وحتى تسليم المنتج. عند الانتهاء بنجاح من مرحلة واحدة، يُسمح للمطورين فقط بالاستمرار. قبل أن ينتقل المطورون إلى الخطوة التالية، يجب مراجعة كل خطوة بدقة والموافقة عليها من قبل العميل. على عكس الرشیق Agile، فإنه لا يسمح بإجراء تغييرات على دورة التطوير التي تجعل من المستحيل تقريبًا التراجع عن الکود، مما يجعل خطر الفشل أمرًا صعبًا. ومع ذلك، يمكن قياس التقدم بسهولة لأنه يتطلب من المطورين إنشاء تسلسل ورقي لكل مرحلة من مراحل دورة التطوير التي تسمح بسير عمل سلس ويمكن التنبؤ به.
ما هو بالضبط سبب تحول كثير من الناس من نهج “رشيق”؟ من خلال اتخاذ الأطر الشعبية يطبق الأفراد العمليات المرتبطة بها دون أي تغيير ثقافي أو تنظيمي أوسع. ومن الأمثلة الجيدة على ذلك عندما كان شخص ما في مؤتمر سعيدًا بالانضمام إلى نهج سكرم، كان التطوير في التكرارات الصغيرة سهلًا بالنسبة لهم بحيث يمكنهم التقاط الأشياء في الوقت المحدد. وعندما سئلوا عن كيفية إدارتهم لتقاريرهم، قالوا: “نحن لا نفعل ذلك، ولا تتغير أولويات التطوير وترتيبها بعد تحديد النطاق”. لذا بالنسبة للسؤال التالي تم طرحهم، أين هو النهج الرشيق، إذا كنت لا تهتم بالتغييرات المحتملة؟” قالوا: كيف لا تراهم؟ “نحن نفرض التكرار واللوائح.”
من الواضح أنه عند تنفيذ بعض الأساليب الرشيقة، لا تتسارع المؤسسات على الفور ومع ذلك لا يبدو أن تنفيذ ثقافة رشيقة حقًا يؤدي إلى هدف في بعض الحالات. هذا يتعارض مع ما يقال عن تنفيذ جميع أدلة وكتيبات Agile، لكن الشركات لا تزال تبحث عنه وهي سعيدة به بشكل مدهش!
لقد كانت نتيجة مثيرة للغاية أنه عندما تقوم المؤسسات بهذا الانتقال، فإنها لا تريد بالضرورة تنفيذ نهج الرشيق، بل تريد فقط الهروب من النموذج المتتالي. ويمكن أن يتخذ الهروب من النهج التعاقبي أشكالًا عديدة لذا فإن الفكرة العامة لمقارنة نهج “التعاقب” مقابل نهج “الرشيق” كأسلوبين متناقضين ليست صحيحة من الناحية المفاهيمية.
تاريخ ولغز نموذج الشلال
عند الإشارة إلى نموذج الشلال، نفكر دائمًا في صورة مكونة من 5 أو 7 مربعات واحدة تلو الأخرى، حيث يمثل كل مربع خطوة في عملية تطوير البرامج. من المفترض أنه في حالة اكتمال إحدى الخطوات، فلن نعود إلى الخطوة السابقة. في الوقت نفسه، إذا لم تكتمل الخطوة السابقة فلن تذهب العملية إلى أبعد من ذلك. بدلاً من ذلك، يتحدث الناس عن النهج الرشيق (مثل Scrum باعتباره أحد أكثر الأطر شيوعًا) حيث يتم التشكيك في مفهوم الخطوات. لكن هذه المقارنة ليست دقيقة بطبيعتها.
دعنا نلقي نظرة على الأساس المنطقي لاختيار نهج الرشيق للمشاريع. في نهاية اليوم، تدور إدارة المشروع بشكل أكبر حول إدارة المخاطر (عدم اليقين) في الطريق إلى النتيجة النهائية. بناءً على ذلك يمكن للأشخاص اختيار استراتيجية مختلفة: تحتاج بعض المشاريع إلى توقع أكبر قدر ممكن (نهج يمكن التنبؤ به)، ولديك كتاب تعليمات حول ما يجب القيام به في حالة حدوث أي موقف وبعد انتهاء المشروع. وبعض الأشخاص تميل إلى حل المشكلات عند الحاجة والاستعداد لها (نهج التطبيقي).
لذلك، في نموذج التنبؤ يحاول الناس التنبؤ بجميع النتائج المحتملة ولديهم خطة لكل منها. في النهج التطبيقي، يقولون إنه من المستحيل أو المستحيل القيام بذلك، لهذا يرون المزيد من إعادة التقييم وإعادة البرمجة كجزء طبيعي من العملية. يمكن أن يختلف استعداد المنظمات للتكيف بين المنظمات أو الصناعات أو الثقافات.
هذا يعني أنه بدلاً من مجرد مقارنة نهج الشلال مقابل نهج الرشيق، لدينا سلسلة كاملة من التغييرات في الخط الفاصل بين التنبؤ والتكيف. الشخص الذي يميل أكثر للتنبؤ يختار أيضًا إطارًا أكثر قابلية للتنبؤ.
هناك أفضل الممارسات والأطر لأجزاء مختلفة من المجال.
بالنظر إلى أننا نتحدث عن أفضل الممارسات و الأطر الراسخة، فإن الإجابة هي لا مكان. إذا عدنا إلى بداية الموضوع، فسيكون ذلك أقل إثارة للدهشة في عام 1970 نشر الدكتور وينستون دبليو رويس ورقته البحثية الشهيرة “إدارة تطوير أنظمة البرمجيات الكبيرة” إيذانا ببداية عصر نموذج “الشلال”.
توصيات ونقاط بارزة
أول ما يتبادر إلى الذهن عندما نسمع كلمة “شلال” لیس صحيح؟ دعونا نقارن هذه التوصيات مع “مشاكل الشلال” الشائعة، أي منها هو الأفضل للنهج الرشيق؟ فيما يلي بعض النقاط البارزة من مصادر مختلفة:
“التصميمات التي تبدو مجدية على الورق غالبًا ما تكون باهظة الثمن ويصعب تنفيذها وتتطلب إعادة تصميم، مما يؤدي إلى عدم وضوح الفروق الواضحة بين مراحل نموذج المتتالي التقليدي.”
“النقد الأبرز إلى حقيقة أنه في كثير من الأحيان لا يعرف العملاء حقًا ما الذي سيستخدمونه، أولاً ما يريدون يأتي من تفاعل متكرر ثنائي الاتجاه طوال المشروع.”
“عندما يكون البرنامج في مرحلة الاختبار، من الصعب جدًا العودة وتغيير شيء لم يتم التفكير فيه جيدًا في مرحلة المفهوم.
تكون تفاعلات العملاء أقل مشاركة أثناء إنتاج المنتج. بمجرد أن يصبح المنتج جاهزًا لا يمكن عرضه إلا للمستخدمين النهائيين. بعد إنتاج المنتج وفي حالة حدوث أي ضرر تكون تكلفة إصلاح مثل هذه الحالات عالية جدًا، لأنه يتعين علينا تحديث كل شيء من المستند إلى المنطق.
بالطبع، هناك جوانب شائعة لتطوير التوقعات قد تكون مزعجة أو تأتي بنتائج عكسية مقارنة بالتطور التطبيقي. النقطة المهمة هنا هي أن العديد ممن يطلق عليهم المشكلات الرئيسية في تطوير نهج المتتالي.
مع وجود معظم العمليات الرشيقة، التي تغرس ثقافة المسؤولية المشتركة والمشاركة الكاملة يمكن معالجة أوجه القصور في إدارة المشروع، مما يؤدي في النهاية إلى مشاريع أفضل. هذا يجعل العمليات أقل عرضية مما يضيف قيمة. لنكن صادقين فإن إدارة مشروع كبير يمكن التنبؤ به أمر صعب للغاية؛ هناك الكثير من الضغط على إدارة المشروع. عندما تتم مشاركة هذه المسؤوليات جزئيًا مع الفريق، واستبدالها بعمليات أخرى وإعادة فحصها أثناء جلسات التدريب كجزء من التحول سنرى بالتأكيد تحسينات في المنظمة.
أهمية موضوع الفرق بین النهج الرشيق والنهج الشلال
ليس من الممكن أن نقول على وجه اليقين تفكير الفوق صحيح، ولكنه يشرح بعض “التطورات الرشيقة” دون تنفيذ عقلية مقارنة بالفعل لا تخطئ هذا لا يعني تنفيذ إطار الرشاقة ليست ضرورية ويجب علينا جميعًا العودة بالزمن إلى الوراء والتخلص من كل الأوزان الثقيلة التي كانت لدينا بالفعل.
بدلاً من ذلك، يمكن أن نستنتج أنه عندما يكون لدينا مرض، فإننا نريد دائمًا فهم السبب وليس مجرد علاج الأعراض. في معظم الحالات، إذا تم فهم الأسباب فلن يتغير العلاج، ولكن في بعض الأحيان يتغير. نفس الشيء ينطبق على المنظمات.
من الأفضل فهم السبب وراء التحول السريع. هل لأن المنظمة تريد الانتقال إلى اليمين من حيث التنبؤ بالتكيف، أم لأن المنظمة تفتقر إلى الجودة وأفضل الممارسات في النموذج الحالي؟ إذا وضعناه على الرسم البياني فإنه يترجم إلى سؤال: هل تريد المنظمة التحرك على طول محور أفقي أم عمودي؟
إذا كانت الشركة تعاني من مشاكل ونتائج غير مرضية، فقد حان الوقت للتحول. لتحديد استراتيجية التغيير المناسبة يجب على الشركة فهم سياق التحول والاحتياجات الأساسية التي تدفعه (انظر نموذج مفهوم محلل الأعمال الأساسي). نحن كمحللين أعمال نحتاج إلى فهمها بشكل أفضل من أي شخص آخر.
سيساعد فهم أسباب التغيير في تنفيذه وتقليل بعض التكاليف غير الضرورية التي قد تتكبدها الشركة. من الأفضل دائمًا وضع الحقيقة في الاعتبار، مما يتجنب الارتباك والمحادثات المربكة اللاحقة.
يقدم صورة أكثر غموضًا لما يمكن أن يتوقعه العميل (العملاء) كمنتج نهائي.
الفرق بین النهج الرشيق (Agil) والنهج الشلال (Waterfall)
المرونة:
نموذج المتتالي هو طريقة تطوير برمجيات هيكلية. غير قادر على تحمل التغييرات اللاحقة، فهو يوفر مرونة أقل أو حتى لا يوفر أي مرونة. من ناحية أخرى فإن أحد الأسباب الرئيسية لتفضيل نهج رشيق هو مرونته العالية.
يسمح النهج الرشيق بإجراء تغييرات في احتياجات المشروع حتى بعد اكتمال التخطيط. لا يوفر نهج الشلال أي شروط لتغيير الاحتياجات بعد بدء تطوير المشروع.
تجزئة عملية كاملة:
تقسم طريقة Agile دورة التطوير بأكملها إلى سباقات السرعة. بدلاً من ذلك يتم تقسيم نهج الشلال إلى خطوات محددة من البداية.
أولوية الميزانية والموارد:
نظرًا لأنه يتم إبرام اتفاقية المخاطر في بداية عملية تطوير البرامج، فإن طريقة التعاقب تقلل من المخاطر الإجمالية في المشروع مع السعر الثابت.
لا يفضل نموذج Agile المشاريع ذات الأسعار الثابتة. بدلاً من ذلك، قد تزيد سيناريوهات السعر الثابت من الضغط على مشروع الرشيق. الطريقة الرشيقة هي أفضل طريقة للمشاريع ذات الميزانية غير الثابتة أو الوقت والمواد (T&M) Time&Material.
حدوث المراحل:
نظرًا لأن نموذج Agile يتبع نهج التطوير التكراري، فقد تحدث خطوات مختلفة مثل التخطيط والتطوير والنماذج الأولية أكثر من مرة خلال عملية تطوير البرنامج بأكملها.
في طريقة Waterfall لتطوير البرمجيات، يتم تنفيذ جميع الخطوات مرة واحدة فقط خلال العملية.
متطلبات التحضير:
مطلوب تحليل أعمال واسع النطاق لاتباع نهج الشلال لتلبية متطلبات تطوير مشروع البرمجيات. لا توجد مشكلة لأعضاء فريق التطوير في التعرف على متطلبات المشروع.
باتباع نهج الرشيق، يجتمع العميل وفريق التطوير كل يوم تقريبًا لتلبية احتياجات المشروع. وبالمثل يمكن لفريق الاختبار المشاركة في تغيير المتطلبات.
التركيز الرئيسي:
التركيز الرئيسي لنهج الشلال هو تحقيق المنتج. يركز نموذج Agile على رضا العملاء عن المنتج بالإضافة إلى تغيير المنتج وفقًا لاحتياجات العملاء المتطورة أو الأحدث.
وصف تفاصيل المشروع:
يمكن تغيير الأوصاف التفصيلية للمشروع في أي وقت أثناء عملية تطوير البرامج بالكامل في طريقة Agile.
هذا ليس هو الحال مع نموذج الشلال Waterfall حيث لا يوجد شرط لتغيير تفاصيل المشروع بعد بدء المشروع.
عرض المشروع:
مع نهج الشلال يُنظر إلى مشروع تطوير البرمجيات على أنه مشروع واحد. هذا على عكس طريقة نموذج Agile، والتي تنفذ مشروع البرنامج قيد التطوير كعدد من المشاريع الفرعية المختلفة.
تنسيق الفريق:
تنسيق الفريق أو التوافق في نهج الشلال محدود للغاية. لا يوجد تفضيل لحجم الفريق. في المقابل، يفضل نموذج Agile فريقًا صغيرًا ولكنه متخصص. وبالتالي فإن مستوى التنسيق بين أعضائها مرتفع للغاية.
القدرة على تغيير الفرق:
أعضاء الفريق قابل للتبادل. ومن ثم فإنهم يعملون بشكل أسرع. بالإضافة إلى ذلك يلبي نهج تطوير البرامج احتياجات مدير المشروع لأن الفريق بأكمله مسؤول عن إدارة مشروع تطوير البرمجيات.
مدير المشروع هو الشخص الذي له الكلمة الأخيرة في جميع مراحل تطوير البرمجيات بطريقة المتتالية. بالإضافة إلى ذلك، لا يمكن استبدال أعضاء الفريق.
اختبار:
يحتوي نموذج الشلال على مرحلة اختبار مخصصة يتم إجراؤها فقط بعد الوصول إلى المرحلة الناجحة. و في طريقة Agile يتم إجراء التجربة في وقت واحد مع تطوير البرامج.
أيضًا، نادرًا ما تتم مراجعة تصميم الاختبار في مرحلة اختبار النموذج التعاقبي. بدلاً من ذلك تتم مراجعة خطة الاختبار لمشروع الرشيق بعد كل تشغيل.
نوع المتطلبات:
المتطلبات في طريقة التعاقب محددة، مما يعني أن أي تغيير في نفس الحالة غير متوقع.
من ناحية أخرى، فإن أي مشروع من المتوقع أن يتغير أو يتطور أثناء عملية تطوير البرمجيات يحتاج إلى Agile من أجل التطوير المثالي.
طريقة الاقتراب من نهاية العملية:
يتبع نموذج Agile نهجًا تدريجيًا لتطوير الوظائف الإضافية للبرامج بشكل تدريجي ومن الممكن التنقل بين أجزاء مختلفة من عملية تطوير البرامج.
من ناحية أخرى، یتبع نهج الشلال عملية تصميم متسلسلة. لا يمكن الانتقال إلى المرحلة التالية من عملية التطوير إلا إذا نجحت المرحلة السابقة.
الکلام الأخیر
تعتبر أساليب Agile و Waterfall من الأشكال المتميزة لطرق تطوير البرامج. ومن ثم فإن كل واحد منهم ممتاز في بعض السيناريوهات بينما يكون غير عملي في حالات أخرى.
يتم إكمال مشاريع تطوير البرمجيات التي تتطور المتطلبات بشكل مثالي باستخدام طريقة Agile. على العكس من ذلك، فإن مشاريع تطوير البرامج الأصغر ذات المتطلبات المحددة تجعل من نهج الشلال الخيار الأفضل.
الملفات المرفقة
