منهجية الأسلوب الرشيق مقابل منهجية الشلال

• تتيح متطلبات المنتج التفصيلية والوثائق للمبرمجين الجدد الانضمام إلى البرنامج بسرعة وسهولة.
• توفر الوثائق نطاقًا واضحًا للمشروع، ما يتيح لمديري المشاريع التواصل بشأن الميزانيات والجداول الزمنية والمعالم الرئيسية للأطراف المعنية.

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

على العكس من منهجية الشلال، يتم تعريف منهجية الأسلوب الرشيق (Agile) من خلال نهجها التكراري لإدارة المشاريع. فبدلًا من صياغة متطلبات المشروع المطولة في البداية، يقوم الفريق الرشيق بتقسيم المنتج إلى ميزات محددة، ويعالجون كل ميزة منها ضمن قيد زمني محدد، يُعرف باسم شوط "Sprint" (دورة تكرارية سريعة).

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

كان هناك 17 فردًا وجدوا أن نظام إدارة المشاريع المتتالية غير فعال نهائيًا، وفي عام 2001، توجت أفكارهم حول عملية تطوير البرمجيات بوثيقة أنتجوها وعُرفت باسم Agile Manifesto. حيث سلطت هذه الوثيقة الضوء على القيم والمبادئ المحددة التي يجب إعطاؤها الأولوية ضمن مجالات عمل تطوير البرمجيات، وقد أسفرت عن عدد من الأطر الرشيقة الشائعة، مثل Scrum وKanban وFeature Driven Development (FDD) وExtreme Programming. ومنذ ذلك الحين، زادت شعبية تطوير البرمجيات الرشيقة، خاصة عند مقارنتها بنموذج الشلال.

مستوحاة من لعبة الرجبي، تؤكد Agile Scrum على العمل الجماعي لتحقيق المنجزات، على غرار الطريقة التي من خلالها يستطيع اللاعبون الأماميون التعاون معًا في تلاحم للحصول على حيازة كرة الرجبي. وتختلف مجموعة المهارات التي يتمتع بها فريق Agile Scrum، ولكنها عادةً ما تتضمن الأدوار التالية:

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

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

يتم تعريف منهجيات الأسلوب الرشيق أيضًا من خلال الطرق التي يجتمع بها الفريق معًا. وهناك اجتماعات محددة تساعد على تسهيل سير العمل بين أعضاء الفريق. يتضمن بعضها ما يلي:

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

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

• قد يفتقر الأسلوب الرشيق إلى التوثيق الشامل. وهذا يجعل من الصعب دمج المطورين الجدد، ووضع جداول زمنية للمشروع للأطراف المعنية، وتوفير تقديرات دقيقة للتكلفة.
• قد يكون من الصعب توسيع نطاقها.

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