SyntaxHighlighter

الاثنين، 6 يونيو، 2011

مقدمة عن الأجايل Agile كأداة لتخطيط وتنفيذ برمجيات ناجحة

سمعت وشاركت في الحوار التالي كثيرا وربما يدور الآن في مكان ما في هذا العالم بين مجموعة من المطورين المتحمسين وهم يتداولون:

"هنعمل المشروع ده صح المره دي. هانلم اللي عايزه ال User بالظبط ومش هاتتغير في النص ، ونعمل design document ما تخرش المية وهانسلم في الميعاد".

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

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

مشكلة أخرى تنتج عن هذا الأسلوب في التخطيط أن المصمم تكون مهمته هي وضع هيكل يناسب أي متطلبات مستقبلية ورغبة في اتباع الطرق المثلى (Best Practices) وفي غياب أي محددات فينطلق العنان للخيال ويتم وضع هيكل للتطبيق ولا هيكل سليمان وكثير من الكلمات الرنانة التي تنتهي بمقطع ity مثل Scalability, Customizability, Maintainability والنتيجة غالبا تصميم معقد يسقط مع بداية الضغوط لزيادة الإنتاجية واقتراب مواعيد التسليم فيبدأ التجاهل التدريجي لقواعد التصميم حتى يصبح في النهاية حبرا على ورق.

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

تنطوي عملية تطوير البرمجيات على مجموعة من النشاطات التي تتم بشكل متتالي في الأساليب التقليدية أما تحت مظلة الأجايل فإنها تتم بشكل مستمر ومتداخل كما نفصل في الفقرات التالية.

التخطيط

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

هناك أساليب أخرى للتخطيط تحت مظلة الأجايل مثل Kan-Ban والتي تتبنى عملية مستمرة التدفق مخالفة لأسلوب الدورات المغلقة في Scrum تستمد هذه الطريقة مبادئها من نظريات Lean في التصنيع والتي تعتمد على تقليل الإهدار والفاقد في الموارد وفي هذه العملية يتم تقسيم التطبيق إلى مجموعة من الميزات Features والتي يتم ترتيب أولوياتها ثم تعريف مجموعة منها كوحدة أقل قابلة للتسويق Minimum Marketable Features وتباعا يبدأ فريق التطوير العمل في البناء ولكن مع تحديد حد أقصى للمهمات المتوازية لتقليل الفاقد الناتج عن النقل ما بين المهمات والحفاظ على تركيز الفريق.

كما أن هناك طرق أخرى مثل Crystal والتي تركز على متطلبات فرق العمل الصغيرة والمشاريع القصيرة و XP التي تعرف مجموعة أكبر من الممارسات التقنية في التنفيذ وكانت في وقت من الأوقات مرادفا للأجايل.

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

التصميم

قضيت جزءا معتبرا من حيات العملية في دور المعماري وبشكل أدق no-coding Architect أعمل على برامج الورد والفيزيو وبرامج تصميم UML لوضع تصورات لما يجب أن يتبعه المطورون في كتابة التطبيقات ومانت هذه الفترة بلا منافس الفترة الأقل إنتاجية في حياتي وأزعم أنها كانت كذلك ليس لأني معماري فاشل ولكن لأن أفضل المعماريات لاتوضع ولكن تنمو من خلال من خلال التصميم المستمر الذي يستجيب لمتطلبات المستخدمين فعند وضع المعمارية Architecture للتطبيق في المراحل الأولى للتطوير حيث هناك حالة من الضبابية يحاول المصمم توقع العديد من السيناريوهات المحتملة بلا أساس واقعي للأولويات. ولكن مع التقدم في مراحل التطوير تبدأ المتطلبات الحقيقية في الوضوح والتي إما أن تكون مختلفة عن تصورات المصمم أو يكون التصميم معقد بدرجة تعوق الإنتاج فيبدأ التجاهل التدريجي له حتى النسيان التام بلا مردود واضح للتصميم على جودة أو كفاءة العمل.

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

ترتبط البساطة بمبدأ مهم عند التصميم هو YAGNI أو You Ain't Gonna Need It وهو أحد المبادئ الرئيسية لمنظومة XP او eXtreme Programming وهو مبدأ يقضي بأنه لا يجب بناء شيء على افتراض الحاجة المستقبلية له فإنه في الغالب لن تحتاجه أو ستحتاج شيء مغاير. لذلك فإن القرارات المعمارية يتم تأجيلها حتى الحظة المسؤولة الأخيرة Last Responsible Moment ولا بد من التفريق هنا بين اللحظة المسؤولة الأخيرة والوقت الضائع فالفارق يتمثل أن في الأولى يتم تأجيل القرار حتى وضوح العوامل المؤثرة فيه والتأكد من الاحتياج لهذا القرار مما يؤدي إلى زيادة احتماليات جودة القرار ودقته بينما الثانية مجرد إهمال.

التنفيذ

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

دفعت هذه الاحتياجات لابتكار عدد من الحلول التي تساعد الفرق في الاستجابة السريعة ومن أهمها عمليات الميكنة في الاختبارات Test Automation على عدة مستويات.

اختبار الوحدات Unit Testing:

والتي تهتم باختبار الوحدات الأصغر من البرنامج وهي غالبا method وحتى تكون فعالة فإنه يتم تشغيلها باستمرار من قبل المبرمج مع كل تغيير يقوم به ولذا فلا بد من أن تكون سريعة التنفيذ. وحتى تكون نتائجها دقيقة يجب فصل الوحدة عن المؤثرات الخارجية مثل قواعد البيانات لذا تأتي تقنية Mocking كجزء أساسي من التقنيات المساعدة وهي تعنى بتكوين Fake Objects تحاكي الاعتمادات الخارجية External Dependencies وتفصله عن الجزء الواقع تحت الاختبار مما يضمن أنه إذا فشل الاختبار فإنه ناتج عن مشكلة في هذه الوحدة ومما أيضا يسرع في عملية تنفيذ الاختبارات بإزالة التفاعل مع الموارد البطيئة مثل قواعد البيانات والاتصال عبر الشبكات.

اختبارات التكامل Integration Testing:

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

التكامل المستمر Continuous Integration:

عادة ما يتكون فريق العمل من مجموعة من المطورين يعملون بشكل متوازي لتنفيذ مهمات معينة يتم التكامل بينها لتكوين المنتج النهائي وهذا يشكل تحدي كبير حيث أنه كما أسلفنا فإن عملية التطوير تعتمد على الابتكار وحل مشكلات صعب التنبؤ بها مسبقا لذا فإن الاتفاق المسبق على شكل التكامل يمثل تحديا مما يؤدي إلى أن تكون عملية التكامل مستهلكة للوقت ويتجنب المطورين تنفيذها بشكل مستمر مما يفاقم المشكلة حيث تتراكم التغيرات وبالتالي صعوبة الربط بينها. تأتي تقنية التكامل المستمر كحل لهذه المشكلة لحث المطورين على الدمج المستمر لأي تغييرات يقومون بها وميكنة التأكد من نجاح التكامل عن طريق Build Scripts تنفذ في أوقات مختلفة فعادة يكون هناك Script يعمل مع كل تعديل يتم دفعه Check-in إلى مخزن المصدر الخاص بالفريق Source Control Repository وبالتالي لا بد أن يكون سريعا فعادة مايتأكد من صحة عملية الترجمة Compilation ونجاح اختبارات الوحدات وإذا فشلت عملية البناء يخطر فريق العمل حتى يتم إصلاح المشكلة والمحافظة على المصدر المشترك سليما باستمرار. وهناك عملية بناء ليلية Nightly Builds تنفذ يوميا ويزيد فيها عادة تشغيل اختبارات التكامل وتجهيز نسخة لفريق مراقبة الجودة للتأكد من صحة ما تم تطويره وأحيانا كتابة اختبارات تكامل جديدة.

في المقالات القادمة سأعمل على التفصيل بصورة أعمق عن هذه التقنيات على أمل المساعدة في تبنيها في فرق العمل العربية. تعليقاتكم هي الموجة الأساسي لمستقبل هذه المدونة لذا إن كان لكم أي استفسارات أو انتقادات أو اقتراحات أرجو كتابة تعليق يساعد في تحسين جودة المحتوى.

هناك 21 تعليقًا:

  1. تعليقى السريع هو الإنتباه لإستخدام همذات القطع و الوصل.
    أحسنت

    ردحذف
  2. مقال رائع الى الامام
    احسنت وشكرا

    ردحذف
  3. منتهى الروعة

    ردحذف
  4. من افضل المقالات التقنيه التي قرأتها باللغه العربيه
    ارجوا منك تخصيص المزيد من الوقت لهذه المقالات الرائعه

    ردحذف
  5. لا اقول سوى بارك الله فيك على هذه المعلومات المفيدة و ارجو المواصلة

    ردحذف
  6. بارك الله فيك إستفدنا

    ردحذف
  7. توضيح ممتاز وبسيط ... بارك الله فيك

    ردحذف
  8. مقدمه ممتازه
    يا ريت لو حد يعرف أماكن معقوله فى السعر و الكقاءه بيعطى كورسات agile
    يتواصل معى

    https://www.facebook.com/SystemDeveloper

    ردحذف
    الردود
    1. http://www.secc.org.eg/SECC_Training_Agile.asp

      حذف
  9. موضوع مهم لكن الكتابة فيه قلقة
    جزاك الله خيرا
    منتظرين الجديد

    ردحذف
  10. ششكرا جدا على المعلومات الرائعة ..
    هل من الممكن ان تضيف معلومات عن Agile xp

    ردحذف
  11. مقال رائع ومليئ بالمعلومات القيمه , شاكرين لك وننتظر جديدك .

    ردحذف
  12. رائع جدا مقدمة جيده جدا للأجايل
    جزيت الجنة

    ردحذف
  13. بارك الله لك مقال رائع جداً

    ردحذف
  14. بارك الله فيك: ارجو منك التوسع في طرح هذا الموضوع لان المقالات فيه قليلة .

    ردحذف
  15. أزال المؤلف هذا التعليق.

    ردحذف
  16. اجايل افضل دوره تدريبيه اخذتها بحياتي
    وعليها طلب قوي في السنوات القادمه 80 بالميه من مدراء المشاريع وقسم it
    وبرضو عليها شهادة عالميه من pmi المنضمه الامريكيه
    والله الموفق

    ردحذف
  17. الله يوفقك ويجزاك خير أحسنت أحسنت ، أتمنى قراءة المزيد من ماتكتب ماشاء الله

    ردحذف
  18. بارك الله فيك ... احسنت

    ردحذف