مدخل إلى أجايل

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

ما هي أجايل؟

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

لماذا أجايل؟

لنعرف لماذا يجب أن نتبنى أجايل، يجب أن نستعرض آليات العمل التي كانت تتبع سابقاً، مثل أسلوب الشلال، ونموذج الإجراءات المعرّفة سابقاً، ونموذج الإجراءات التجريبية.

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

تسلسل تاريخي لنماذج الإدارة

الشهير أن ما قبل أجايل هو أسلوب الشلال Waterfall والذي يمكن أن يسمى أيضاً دورة الحياة التنبؤية (Predictive Life cycle) والتي تناسب مشاريع لا تنطوي على درجة عالية من عدم التيقن.

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

ألا تلاحظ من الصورة أعلاه أن الأمر أشبه بخط انتاج في مصنع؟

لكن السؤال الأهم: هل هذا ما يناسب طبيعة صناعة البرمجيات؟

أسلوب الشلال أيضاً تعود جذوره أكاديمياً إلى ما يلي:

1-نموذج الإجرائية المُعرَّف مسبقاً Defined process model

يستعمل في الأمور الواضحة جداً، مثل خط إنتاج في معمل.

2- النموذج الإجرائي التجريبي Empirical process model

المبني على التجريب، ويستعمل في مجالات البحث المعرفي، والبحث العلمي.

3- نموذج أجايل

نموذج الإدارة الرشيقة الذي ظهر في العام 2001، وهو منبثق عن نموذج الإجرائية التجريبية + مبادئ الإدارة المبسطة (لين lean).

ما هي التحديات التي تواجه صناعة المنتج الرقمي (البرمجيات)؟

الأسلوب المستعمل قبل أجايل هو أسلوب الشلال، وفيه تتدفق العمليات في اتجاه متسلسل كما يلي:

عيوب أسلوب الشلال

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

التحديات قبل أجايل

عدم وضوح المتطلبات

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

والنتيجة هي تطوير منتج لم يطلبه الزبون أو لا يخدم المستخدم النهائي بفعالية. المشكلة أننا لن نعرف هذا الأمر بشكل مبكر!

الفريق سيبني منتجاً كما طلب الزبون ومع ذلك لا يريده

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

” شكراً لقد بنيتم ماطلبت منكم بالفعل، ولكن ليس هذا ما يلزمني. “

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

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

دوام الحال من المحال

التغيرات في السوق وسرعة التطور التكنولوجي تستلزم استجابة بأسرع مايمكن، قد يكون التغير مفاجئاً مثل الهزات الاقتصادية السريعة، تقلب أسعار الصرف، جوائح صحية عالمية مثل كورونا، تغيير عادات المستخدم النهائي.

سلوك المستخدم النهائي

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

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

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

وبناءً على استطلاع رأي المستخدم النهائي سنقوم بتكرار التعديل والاختبار لنصل إلى منتج يرضيه.

المشكلة الشريرة أو المستعصية

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

يرجع ذلك إلى عدم التيقن الشديد في هذه المشاريع، المبنى على تكهنات و افتراضات (Assumptions) في البداية، وبالتالي ثمة مخاطر عالية في تنفيذ هذه المشاريع،

أجايل مفيدة في هذا النوع من المشاريع

كيف كان الحل بأجايل؟

يرجع ذلك إلى بنية أجايل المنبثقة عن نقطتين رئيستين:

النقطة الأولى

لأنّ أجايل مبنية على نموذج الإجرائية التجريبية Empirical process model، وهو عكس نموذج الإجراءات المُعرّفة مسبقاً Defined process model..

الإجرائية التجريبية تسير بتسلسل منطقي دائري عادة وتقوم على ما يلي:

1. تضع فرضية

2. بناء جزئية

3. اختبار ما تم بناؤه

4. أخذ التغذية الراجعة من العميل

5. موافق: ننتقل إلى الجزئية التالية (1.).

5 َ. غير موافق: – نعدل – نختبر (3.) – نأخذ إفادة العميل (4.) – (5.).

الإجرائية التجريبية تختبر وتقيس أثر كل إجراء في حينه، وتبلغ بالنتائج أولاً بأول في وقت مبكر لتسهيل الاستجابة لطلبات التغيير كلما لزم الأمر.

النقطة الثانية

البداية المبسطة غير المتكلفة بمزايا قد لا تكون مفيدة للمستخدم النهائي، وهذا هو جوهر مبادئ لين lean وعدم الهدر.

مبادئ لين قديمة جداً منذ بداية القرن التاسع عشر. وأشهر من عمل بها شركة تويوتا للسيارات lean manufacturing.

· مبادئ لين مرتبطة بـ ← عدم الهدر

· أجايل مرتبطة بـ ← الاستجابة للتغيرات السريعة

فلا عجب أن أجايل مستلهمة ومتأثرة بطريقة التفكير لين (Lean Thinking).

عقلية أجايل Agile Mindset

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

فمن خلال الجمع بين العقلية المرنة والعمليات والأدوات الملائمة، يمكن للفرق التكيف مع التغيير، وتقديم قيمة متزايدة لعملائها.

أجايل بالعربي الفصيح! 

نستذكر معاً معنى Agile حيث وجدناه ذهنية تفكير بالدرجة الأولى، ومنطق عمل.. 

وعلى النقيض منها كانت براغماتية فريدريك تايلور أبو الثورة الصناعية وخطوط الإنتاج، التي كانت تنظر للموظف نظرة ملؤها التشييء وكأنه قطعة غيار أو مجرد آلة إنتاج، لا يفكر ولا يشارك ولا يخطط! 

ومع ميلاد ثورة المعلوماتية في نهايات القرن العشرين، كانت غالبية المشاريع البرمجية تعتمد منهجية الشلال Waterfall التي تبنت نهج التايلورية taylorism حيث قسّمت المشروع إلى مراحل بحسب التخصص (الدراسة، التصميم، التطوير… إلخ) ولكل مرحلة فريقها المستقل.  

ولأنّ هذا التقسيم على طريقة خطوط الإنتاج في المصانع، قد أثبت عدم فاعليته في قطاع تطوير البرمجيات، فقد حدا ذلك بعديد من الباحثين والمهندسين الذين يعملون في المجال التقني، للبحث عن مناهج وآليات بديلة؛ فكانت منهجية الأجايل! 

إعلان أجايل Agile Manifesto 

في 2001 اجتمع 17 من كبار مهندسي تطوير البرمجيات في ولاية يوتا الأمريكية، وقاموا بصياغة إعلان موحّد أسموه: 

إعلان أجايل لتطوير البرمجيات 
Manifesto for Agile Software Development 

وقد مثّل إعلان الأجايل تحولاً في النموذج الفكري لإدارة وإنتاج البرمجيات، حيث عززت قيمه ومبادئه الاعتماد على الإنسان بتجاربه المتنوعة، كما ركزت على الاستفادة من ذكاء الفريق مجتمعاً، لتحقيق الكفاءة والفعالية في الإنتاج. 

تضمّن الإعلان 12 مبدأ رشيقاً، وهي ليست محض قواعد لممارسة العمل فحسب، بل هي مجموعة من المبادئ المساعدة في غرس التفكير السريع والمرن. 

قيم أجايل الأربعة

ينص إعلان أجايل لتطوير البرمجيات على القيم الأكثر أهمية من وجهة نظر المتوافقين عليه، كما يلي:

1. الأفراد وتعاملهم فيما بينهم فوق المنظومات والأدوات
2. الصالحة للاستعمال فوق التوثيق الكامل
3. تعاون ومشاركة العميل فوق التفاوض حول العقد
4. الاستجابة للتغييرات فوق الالتزام بمخطط عمل محدد

المبادئ الـ 12 خلف إعلان الأجايل

1- إرضاء العميل

“هدفنا الأسمى هو إرضاء العميل عن طريق التسليم المبكر والمتواصل لبرمجيات ذات قيمة”

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

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

تعرف أكثر على المبدأ الأول للإدارة الرشيقة هنا

---

2- الترحيب بتغيير المتطلبات

“الترحيب بتغيير المتطلبات ولو في مراحل متقدمة من التطوير. فمناهج الأجايل تُسخر التّغيير لصالح الميزة التنافسية للعميل.“

عند تبنّي هذا المبدأ عملياً، يُفترض أنّ الفريق لن يفكّر بالتغيير على أنه أمر خاطئ أو مزعج، ولن ينتهج نهجاً استعلائياً تجاه الزبون يَصِمُهُ بالجهل أو عدم معرفة ما يريده بالضبط! 

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

تعرف أكثر على المبدأ الثاني للإدارة الرشيقة هنا

---

3- تسليم برمجيات في فترات منتظمة

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

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

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

تعرف أكثر على المبدأ الثالث للإدارة الرشيقة هنا

---

4- التعاون

“يجب أن يعمل كلاً من المهنيين (العارفين بالمِهنة) والمطورين معاً بشكل يومي خلال فترة المشروع.”

التعاون اليومي بين المهنيين (business) والمطورين هو شرط رئيسي للنجاح في تطوير المنتج الرقمي، التعاون بين الطرفين سيؤدي إلى الحصول على فهم مشترك موحد للمطلوب إنجازه وسيردم الفجوة التقليدية بينهما.

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

5- الاعتماد على أفراد متحمسين

“الاعتماد في بناء المشاريع على أفراد متحمسين. مع توفير البيئة المناسبة والدعم اللازم، ومنحهم الثقة من أجل إنجاز العمل.”

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

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

6- التخاطب وجهاً لوجه

“أكثر الطرق فاعلية وتأثيراً لتواصل المعلومات إلى فريق التطوير وبين أفراده هي التخاطب وجهاً لوجه.”

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

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

7- المقياس الرئيسي للتقدم

“البرمجيات الصالحة للاستعمال هي المقياس الرئيسي للتقدم.“

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

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

8- الحفاظ على وتيرة ثابتة على الدوام

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

التطوير المستمر لبنية المنتج الرقمي البرمجية والتقنية هي الوسيلة التي ستساعد على تطوير المنتج الرقمي بوتيرة ثابتة، وجود فريق تطوير متفرغ و الاستثمار بالاختبارات المؤتمتة (Automated Tests) هي أحد الطرق العملية لتحقيق هذا المبدأ.

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

9- الاهتمام المستمر بالتفوق التقني

“الاهتمام المستمر بالتفوق التقني والتصميم الجيد يعزز درجة الأجايل.”

حفاظاً على جودة المنتج النهائية، لابد من السعي الدائم لتطوير وصقل المهارات التقنية للفريق.

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

10- البساطة

“البساطة — فن تقليص الأعمال غير الضرورية — أساسية.”

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

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

11- فرق العمل ذاتية التنظيم

“إن أفضل البنيات والمواصفات والتصميمات تنبثق من فرق العمل ذاتية التنظيم.”

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

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

12- فريق العمل يدقق ويضبط سلوكه

“يراجع فريق العمل على فترات منتظمة كيف يصبح أكثر فاعلية، ثم يدقق ويضبط سلوكه وفقا لذلك.”

وهذه من سمات فريق العمل ذاتي التنظيم، حيث يقوم بمراجعة آلية العمل والإجرائيات المختلفة المتبعة بهدف تطويرها المستمر.

تعرف أكثر على هذا المبدأ من خلال الرابط هنا

---

أطر عمل أجايل

ثمة أُطر متعددة وإجراءات وأدوات متنوعة تناسب الإدارة الرشيقة بحسب حجم المشروع، مثل:

• سكرم Scrum
• البرمجة القصوى Extreme programing
• كانبان Kanban

ومن الشائع عادة استخدام مزيج من الآليات السابقة.

الحلول المبنية على أجايل

• التسليم المتكرر للزبون بنهاية كل دورة عمل [سبرينت Sprint].
• التغذية الراجعة المبكرة من العميل Early Feedback.
• التكيف مع التغيير وقبوله.
• إعادة ترتيب الأولويات وصيانة المتطلبات بشكل دوري، لأنه مع كل نهاية دورة عمل (سبرنت) ستَرِدُ متطلبات جديدة، أو متطلبات قديمة ستتغير بحسب التغذية الراجعة.
• مما يؤدي إلى ضرورة إعادة التخطيط، فالتخطيط مستمر في أجايل.
• التحسين المستمر Continues improvement.
• تكرار جميع الحلول السابقة.

اختلاف الحلول الملائمة باختلاف أنواع المشاريع

هناك ربط بين نوعيات المشاريع وأسلوب العمل الملائم لكل نوع، ولأن نوعيات المشاريع تختلف، فبالتالي لكل نوع أسلوب عمل يناسبه.

طريقة تصنيف المشاريع

ننظر إلى نوعيات المشاريع من حيث:

1- مبدأ عدم التيقن الشديد.

2- عدم وضوح المتطلبات.

هل هذا المشروع روتيني أم مشروع مخصص (فيه تطوير متطلبات مخصصة custom development)؟

المشروع الروتيني

لا يحتوي على المبدأ الأول (مبدأ عدم التيقن الشديد) فهو مشروع واضح جداً من حيث متطلباته.

مثال عليه في المنتجات الرقمية: تصميم موقع وورد بريس، وهو منتج رقمي بسيط واضح روتيني، يمكن توقع الزمن اللازم له.

لذا يمكننا أن نستخدم فيه نموذج الإجراءات المعرّفة سابقاً Defined process model، بخطوات واضحة مثل:

1- اختيار القالب.

2- تصميم القالب.

3- تجهيز المحتوى.

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

مثال آخر على المشاريع المتوقعة التي يمكن أن تقاس بزمن يسهل تقديره، هو مشروع تركيب خادم البريد الإلكتروني Email Server، فهذا مشروع مثالي لقطاع الخدمات، أو ما يسمى: Professional Services

وليس فيه حالة عدم تيقن شديد.

المشروع غير الروتيني

على الطرف الآخر هناك مشاريع تتسم بالمخاطرة الشديدة، لعدم وضوح المتطلبات، حتى وإن اعتقدنا أنها واضحة. وهنا تقع مشاريع البرمجة المخصصة (custom development) أو تطوير المنتجات الرقمية التي يصعب تقدير زمن التسليم فيها.

وثمة نموذج شهير يوضح الفروقات بين المشاريع بحسب درجة عدم التيقن الشديد يدعى: complexity model Stacey

أسئلة شائعة

ختاماً..

لا بد من التأكيد أن أسلوب الإدارة الملائم ليس بالضرورة أن يكون أبيضاً بأجايل، أو أسوداً بغيره! بل يمكن استخدام مزيج هجين (رمادي) بينها، والاختيار متعلق أولاً بنوعية المشروع ومقدار درجة عدم التيقن.

وأنت، حدثنا في صندوق التعليقات عن المنهجية المفضلة لديك ولماذا، وهل سبق لك دمج عدة منهجيات للوصول إلى منهجيتك الخاصة؟