تطوير البرامج بتقنية أجيل

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

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

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

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

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

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

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

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