http://www.barm.ag/2011/06/agile.html
سمعت وشاركت في الحوار التالي كثيرا وربما يدور الآن في مكان ما في هذا العالم بين مجموعة من المطورين المتحمسين وهم يتداولون:
"هنعمل المشروع ده صح المره دي. هانلم اللي عايزه ال User بالظبط ومش هاتتغير في النص ، ونعمل design document ما تخرش المية وهانسلم في الميعاد".
لو لم تسمع هذا الحوار من قبل أو استطعت فعلا الحصول على متطلبات لا تتغير وأنتجت التطبيق في الوقت المحدد بدون تغييرات جوهرية في التصميم الموضوع في بداية المشروع الذي اتبعه المطورون بحذافيره فلا داعي لاستكمال القراءة. فالمقال يقوم على فرضية أساسية أن هذا الأسلوب في إدارة عملية تطوير البرمجيات ببساطة فاشل. فإنه يقوم على فرضية أن المستخدم يعلم ما يحتاجه وبقضاء وقت كافي في مداولات وحوارات بين العميل ومحلل النظم يمكن الخروج بخطة دقيقة للشكل النهائي للتطبيق والوقت والتكلفة والمتطلبات التي سيحتاجها المستخدم بشكل كافي ليقوم معماري بتصميم بنية وهيكلية للنظام يتبعها المطورون لبناء نظام يقوم بالغرض المبني من أجله اتباعا لنفس طرق إدارة المشاريع في فروع الهندسة الأخرى.
أما ما خبرته في عالم البرمجيات وخبرات من هم أكثر علما مني أن ما يحدث في عالم تطوير البرمجيات أنه مهما كانت جدية محاولات التخطيط المنضبط والحيل والحوارات والمداولات وطول الحوارات والمراسلات فإن أول كلمه عندما يتعامل العميل مع التطبيق تسمع هذه الجملة الخالدة "لالا مش ده اللي أنا كنت عايزه خالص" أو عند الرأفة "هايل بس يعتي في شوية حاجات صغيرة محتاجة تتغير" وتفاجأ بأن هذه الأشياء الصغيرة هي دورة لا نهائية تجعل المطور يتمنى ألا يكون قد رأى لوحة مفاتيح في حياته.
مشكلة أخرى تنتج عن هذا الأسلوب في التخطيط أن المصمم تكون مهمته هي وضع هيكل يناسب أي متطلبات مستقبلية ورغبة في اتباع الطرق المثلى (Best Practices) وفي غياب أي محددات فينطلق العنان للخيال ويتم وضع هيكل للتطبيق ولا هيكل سليمان وكثير من الكلمات الرنانة التي تنتهي بمقطع ity مثل Scalability, Customizability, Maintainability والنتيجة غالبا تصميم معقد يسقط مع بداية الضغوط لزيادة الإنتاجية واقتراب مواعيد التسليم فيبدأ التجاهل التدريجي لقواعد التصميم حتى يصبح في النهاية حبرا على ورق.
السؤال هنا هل الفشل في تبني طرق وأساليب تبدو ناجحة في فروع أخرى وتعتمد على التخطيط المنضبط ناتج عن فشل الأشخاص في استيعاب هذه المبادئ وتطبيقها على البرمجيات أم في اختلافات بنيوية تسم حرفة البرمجة. أفترض هنا وبإيمان كامل أن الاختلافات بنيوية ولذا وجب تبني أساليب مغايرة لطرق الإدارة التقليدية للنجاح في تطوير حلول تلبي متطلبات المستخدمين. انطلاقا من هذه الفرضية تبنت مجموعة من خبراء البرمجيات مبادئ وممارسات الأجايل التي تحدثنا عنها في المقالة السابقة والتي نتجت عن خبراتهم في تطوير برمجيات ناجحة مقارنة بالأساليب التقليدية.
تنطوي عملية تطوير البرمجيات على مجموعة من النشاطات التي تتم بشكل متتالي في الأساليب التقليدية أما تحت مظلة الأجايل فإنها تتم بشكل مستمر ومتداخل كما نفصل في الفقرات التالية.
التخطيط
ما بين أسلوب اللاخطة الذي تتبناه فرق التطوير المبتدئة وأسلوب التخطيط الصناعي الذي تتبناه الشركات للسيطرة والتحكم في تكلفة ووقت التنفيذ والذي شهدت فشله في إنتاج تطبيقات تلبي حاجات المستخدمين فإن أسلوب الأجايل يتبنى نظرية التخطيط المستمر وينطلق أساسا من أن عملية التطوير تقوم على ابتكار حلول في خيال المستخدم ومحاولات استخراج تصورات دقيقة عن طريق حوارات ما بين محلل النظم والمستخدم غالبا ما تفشل في تكوين تصور دقيق لاحتياجاته. عوضا عن ذلك يتم تبني عدم التأكد في عملية التخطيط وهنا يأتي الخيط الرفيع بين ما بين التخطيط في فلسفة الأجايل والفوضى. فبدلا من أن يكون التخطيط مرحلة مستقلة تفترض أن نتائجها دقيقة فإن التخطيط يكون مستمرا ففي طريقة مثل سكرم Scrum يكون التخطيط بتقسيم مراحل التطوير إلى إصدارات Releases التي تمتد إلى بضعة أشهر والتي تقسم بدورها إلى مجموعة من الانطلاقات Sprints القصيرة والتي تدوم لأسبوع أو أسبوعين بحيث أن يكون فيها مجموعة من الميزات التي يتم إنجازها بشكل كامل وتكون قابلة للاختبار بواسطة المستخدمين. ويتم مراجعة الخطة بشكل يومي في اجتماع بين فريق العمل لمراجعة ما تم انجازه في اليوم السابق وما يخطط انجازه في اليوم الحالي وإذا ما كانت هناك معوقات تمنع أفراد الفريق من الإنتاج. في هذه الطريقة يتم مراجعة الخطة بشكل مستمر على المدى المتوسط عند التخطيط للإصدارات وعلى المدى القصير عند التخطيط للانطلاقات وصولا إلى التخطيط اليومي ولكن بتقييد دخول أي متطلبات جديدة أو تغييرات داخل الانطلاقة للحفاظ على تركيز الفريق.
هناك أساليب أخرى للتخطيط تحت مظلة الأجايل مثل Kan-Ban والتي تتبنى عملية مستمرة التدفق مخالفة لأسلوب الدورات المغلقة في Scrum تستمد هذه الطريقة مبادئها من نظريات Lean في التصنيع والتي تعتمد على تقليل الإهدار والفاقد في الموارد وفي هذه العملية يتم تقسيم التطبيق إلى مجموعة من الميزات Features والتي يتم ترتيب أولوياتها ثم تعريف مجموعة منها كوحدة أقل قابلة للتسويق Minimum Marketable Features وتباعا يبدأ فريق التطوير العمل في البناء ولكن مع تحديد حد أقصى للمهمات المتوازية لتقليل الفاقد الناتج عن النقل ما بين المهمات والحفاظ على تركيز الفريق.
كما أن هناك طرق أخرى مثل Crystal والتي تركز على متطلبات فرق العمل الصغيرة والمشاريع القصيرة و XP التي تعرف مجموعة أكبر من الممارسات التقنية في التنفيذ وكانت في وقت من الأوقات مرادفا للأجايل.
باختلاف التفاصيل فإن المشترك بين هذه الأساليب هو تبني عدم التأكد وأن ما سيتم إنتاجه لن يلبي متطلبات المستخدمين من المحاولات الأولى. لذا فإنها تستعيض عن محاولة تكوين خطة منضبطة بمد جسور أقوى مع المستخدم والاستجابة السريعة للتغيرات.
يمكن قراءة المزيد عن الموضوع على المدونة الخاصة بي http://www.barm.ag