منهجية الآجيل (Agile) بأصل فكرتها تعتمد على "مغايرة" ما قبلها من المنهجيات في صناعة البرمجيات والتي كانت معروفة بثقل الحركة تهتم بالرسميات ومراسم تحديد متطلبات العميل وتحليلها وتصميمها على الورق أولا واعتمادها قبل أن يُشرع أصلا في تنفيذ وتطوير الكود والبرنامج وبناء النظام. 

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

وذلك تطلب اختيار أدوات للعمل ووسائل لمواكبة هذه الخفة والسرعة في العمل والتسليم: فبدلا من كتابة المستندات الطويلة التفصيلية الرسمية ( وسائل كتابة المتطلبات وتصاميمها use cases & UML diagrams...) لجأت إلى كتابة المتطلبات بصورة مختصرة وسريعة لدرجة أنها تكتب على index cards & sticky notes (مجرد كروت صغيرة أصغر من كف اليد تتناول وظائف وخصائص صغيرة (في صورة حكايات المستخدم مع النظام user stories) قد تستغرق يوما أو ساعات من العمل) تكتب في عبارة أو عبارتين وتعلق على لوحة العمل وتتحرك عليها حسب الإنجاز. 

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

ثم تدخل هذه الـ user stories الصغيرة خفيفة الحركة في التنفيذ في دورات عمل تطوير البرنامج وهي دورات سريعة قصيرة كذلك لا تتعدى الأسبوع أو الأسبوعين sprints (في مقابل الشهور في منهجيات ما قبل الآجيل) ينتج عنها أجزاء أو إصدارات releases من المنتج (النظام) للعميل ومنها ما هو جاهز للتركيب في بيئة العمل والتشغيل مباشرة (وتلك إحدى مميزات العميل: أنه يتسلم العمل على مراحل متتابعة وليس مجرد أوراق طويلة عريضة وهي في الآخر مجرد حبر على ورق في المنهجيات القديمة) 

جميل جدا للآن ..

الآجيل طريقة فاعلة انتشرت جدا جدا في كل أنحاء العالم ومنطقتنا العربية منذ سنوات طوال الآن والحمد لله.

ولكن أهل علوم الـsystems thinking قد تثار ثائرتهم هكذا ويزداد قلقهم من كل ذلك "التقسيم" و"التصغير" إلى مقاطع وأجزاء يتم العمل عليها بشكل منفصل (فتصبح التكاملية  integrity ووحدة العمل ككل ووظائف البرامج ومكوناته أو أجزائها المترابطة ببعضها البعض في خطر هكذا إلى حد مقلق للغاية) خاصة وأن الـ user story تتحرك بالـtechnical tasks الخاصة بتنفيذها على البوورد بشكل منفرد كخاصية (feature أو حتى جزء من feature) مطلوب أن تنفذ وتسلم خلال أسبوع أو اثنين على الأكثر مع مجموعة من الـ stories الأخرى والسلام.

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

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

ومن أكثر الأدوات ووالوسائل الآجيلية التي أعجبتني ولاقت القبول الواسع من الكثيرين في الغرب هي كانت من اختراع خبير التصميم جيف باتون Jeff Patton وهو صديق وزميل لـ Alastair Cockburn والاثنان لهم الحضور المتميز في عالم الآجيل.

ماذا اخترع جيف وأبدع الحقيقة؟

اخترع وقدم وسيلة أو أداة فعالة للغاية تساهم في الحفاظ على الـ integrity الشمولية والتكاملية لأجزاء وأقسام النظام، فقدم: خرائط حكايات الاستخدام  STORY MAPs وهي تخذ صورة كما بالرسمة المبينة بحيث يتم التعامل مع الـ user stories لصغيرة هذه كنقاط أو قطع بازل أو أجزاء صورة ترسم وتكون كلية للنظام والبرنامج ككل. 

وهي أداة ووسيلة فعالة جدا (جدا جدا ما شاء الله) في كلٍ من "التحليل" (التقسيم والتصغير) وفي "التركيب" (التجميع والترابط بين الأجزاء وتصميمها) على سواء.

 فماذا عنك أنت إذا كنت عضوا في فريق عمل تطوير وبيت من بيوت صناعة البرمجيات ماذا تفعلون وتأخذون في الاعتبار موضوع أو نقطة الحفاظ على الـ integrity للنظام المصنع والبرنامج المطور ككل؟ (رجاء المشاركة لعموم الإفادة سواء بالرأي أو الأفكار المنفذة والأدوات المستخدمة عندكم بالفعل)