ينص المبدأ الأول من مبادئ إعلان أجايل الـ 12 على ما يلي:
“هدفنا الأسمى هو إرضاء الزبون عن طريق التسليم المبكر والمتواصل لبرمجيات ذات قيمة”.
لكن لنرجع بداية إلى ما هي الأجايل، وما هو إعلانها. وكيف نفهم هذا المبدأ الأول منه بشكل واضح، نظريّ وعمليّ في آن معاً؟..
هذا ما سنستعرضه في مقالنا الذي بين يديك من دليل أجايل للمنتجات الرقمية. وهو المقال الأول في سلسلة تفصّل مبادئ الأجايل الإثني عشر.
أجايل بالعربي الفصيح!
عندما تحدثنا عن معنى Agile في مقالٍ سابق يتناول مدخلاً إلى الإدارة الرشيقة. وجدنا منهجية قبلها تدعى منهجية الشلال Waterfall قسّمت المشروع إلى مراحل بحسب التخصص.
وقد رأينا أن هذا التقسيم على طريقة خطوط الإنتاج في المصانع، لم يثبت فاعليته في قطاع تطوير البرمجيات. مما حدا بعديد من الباحثين والمهندسين الذين يعملون في المجال التقني، للبحث عن مناهج وآليات بديلة؛ فكانت منهجية الأجايل!
إعلان أجايل Agile Manifesto
في 2001 اجتمع 17 من كبار مهندسي تطوير البرمجيات في ولاية يوتا الأمريكية، وقاموا بصياغة إعلان موحّد أسموه:
إعلان أجايل لتطوير البرمجيات
Manifesto for Agile Software Development
تضمّن الإعلان 12 مبدأ رشيقاً، وفي هذه المقالة سنتناول المبدأ الأول منها، ونصف كيفية ممارسته وتطبيقه على أرض الواقع.
إرضاء الزبون | المبدأ الرشيق الأول من مبادئ الأجايل
جاء في أول مبدأ من إعلان مبادئ الاجايل:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
هدفنا الأسمى هو إرضاء الزبون عن طريق التسليم المبكر والمتواصل لبرمجيات ذات قيمة
إنّ أفضل الطرق لإسعاد عميلك هي أن تقدّم له منتجه الرقمي المطلوب، الذي يحتوي على قيمة حقيقية، في وقت مبكر.
ولا يعني ذلك أن تسلّمه المنتج مكتمل الأركان في وقت واحد، فذلك سيطيل زمن تسليم المشروع. وسيؤخر الحصول على رأي الزبون (التغذية الراجعة)، وسيصعّب إمكانية التغيير. وحتى إن تم التعديل فسيحصل في وقت متأخر من حياة المشروع.
بل المطلوب أن تسلمه في نهاية كل دورة عمل جزءاً مكتملاً من المنتج. ثم عليك أنْ تُكَرِّر هذا الالتزام بالتسليم المبكر حتى نهاية دورات عمل المشروع. مع التأكيد على ضرورة الاستماع إلى رأي الزبون بعد كل عملية تسليم.
لينعكس ذلك كلّه على أداء الفريق بتلبية توقّعات الزبون، وتحسين المتطلبات باستمرار، وتعديلها كلّما لزم الأمر في وقت باكر.
وعلى عكس الأساليب التقليدية السابقة في قطاع تطوير البرمجيات. والتي كانت تشتهر بدورات تطوير طويلة، وتغذية راجعة متأخرة من الزبون. فإن مبادئ أجايل في الإدارة الرشيقة تشجع على تقليل الوقت بين التخطيط والإطلاق.
أو بعبارة أخرى يمكننا أن نعدّ جوهر الفكرة يكمن في تقديم منتج عامل بين يدي الزبون في أسرع وقت ممكن.
إن النجاح في تنفيذ هذا المبدأ، يعني إمكانية الحصول على منتج مصغر MVP مكتمل الخصائص الرئيسة، وقابل للإطلاق بسرعة، مما يؤدّي بالضرورة إلى الحصول على تعليقات من المستخدمين النهائيين الحقيقيين للمنتج.
وبعيداً عن أية افتراضات، فإنّ هذا الإنجاز لا يقدّر بثمن، لاسيما على مستوى جني الأرباح المالية من منتج يوائم متطلبات السوق بدقة!
ماذا يعني التسليم المتواصل ؟
لا بد من تكرار عملية التسليم المبكر، ففي كل مرة يجري بها تسليم مبكر، سنحصل على ملاحظات وتغذية راجعة من الزبون ومن مستخدميه النهائيين.
وبالتالي سيقوم الفريق بتضمينها بالتسليم القادم، ومن ثم تطوير المنتج وتحسينه مع كل نسخة من الإصدارات المستقبلية، وكذلك الأمر في كل مرحلة أو إصدار من الإصدارات اللاحقة لمرحلة المنتج المصغر Minimum Viable Product (MVP).
فوائد إرضاء الزبون عبر التسليم الباكر
إن كسب رضى الزبون، من خلال تقديم منتج رقمي فعّال وصالح للاستخدام، والالتزام بأوقات تسليم متقاربة، سينعكس إيجاباً على المشروع في عدة صور منها:
1- كسب ثقة الزبون
لأن الزبون سيسعد بالحصول على نتائج ملموسة متكررة في وقت مبكر، ثم برتم مستقر طوال دورات عمل المشروع.
2- معرفة رأي الزبون بوقت مبكر وتقليل المخاطر
لأن الزبون صاحب العمل شريك حقيقي في جميع مراحل المشروع، ويشارك في كل اجتماع، ويقدم رأيه وتغذيته الراجعة إلى الفريق بوقت مبكر بعد كل دورة عمل.
3- الملاءمة مع أي تغيير بمستوى عالٍ من التعاون
توفر هذه الخطوة درجة عالية من التعاون داخلياً بين أفراد فريق التطوير البرمجي، فيفهم كل عضو زوايا أخرى ينظر من خلالها زملاؤه في الفريق إلى المهمة، ويشتركون في غاية واحدة نهائية هي (إرضاء الزبون).
كذلك تعزز مستوى التعاون مع الزبون، فيأخذ الفريق فرصة جيدة لفهم وجهة نظر الزبون بصورة أوضح.
وبالمقابل يمنح الزبون فرصة ليقدّم رأيه وملاحظاته المباشرة أثناء النقاش المتواصل، فيعمل الفريق على تعديلها قبل أن يصبح التعديل متأخراً مكلفاً أو شديد الصعوبة.
4- مزيد من الثقة بمشروع ينمو سريعاً!
كل ما سبق سيعطي بالنتيجة ثقة أكبر من ناحية الزبون للفريق الذي ينجز مشروعه، كما سيتفهم الزبون أن مشروعه قيد العمل وينمو بسرعة أكبر في نهاية كل دورة عمل (سبرنت).
5- تسليم مبكر = إطلاقاً مبكراً!
وهذ يعني تقليل الهدر بالضرورة؛ لأننا اكتشفنا الخطأ أو التعديل بوقت مبكر. وكما أسلفنا فإن إرضاء الزبون لا يمكن أن يتم بترك الزبون ينتظر لفترات طويله دون أن يلمس شيئاً حقيقياً على أرض الواقع بين الحين والآخر، ويجري ذلك عبر التسليم المبكر والمتواصل لتطبيقات أو منتجات أو أعمال ذات قيمة، بحيث يلمسها الزبون ويتعامل معها.
فبعد كل مرحلة من مراحل المشروع المتعاقبة، سيَنتجُ منتجٌ أوليٌ قابل للاستخدام وللتحقق، مما يوفر فرصة كبيرة للزبون بأن يقوم بإطلاق مشروعه باكراً…
وبالتالي اختبار ردّات فعل الجمهور من المستخدمين النهائيين لمنتجه بسرعة وبوقت مبكر، ريثما يطلق النسخة النهائية وهي بأفضل تقبّل ممكن، وفقاً للتعديلات الضرورية والمطلوبة من الجمهور الحقيقي، دون هدر في تطوير خصائص غير مستعملة أو غير مفيدة.
أما بالنسبة للهدر، فلأننا اكتشفنا الخطأ في وقت مبكر، وقمنا بالتعديل في وقت مبكر قبل أن نكمل بناء الميزة بشكل كامل فسنوفر كثيراً من هدر الموارد وهدر الوقت. وهنا نجد تقاطعاً مع مبادئ لين Lean thinking.
كيف يمكن تطبيق المبدأ الأول من مبادئ الأجايل في الممارسة العملية ؟
لكي يتمكن فريق التطوير من التطبيق العملي لهذا المبدأ الرشيق، ينبغي له أن يكون هو بدوره سريعاً رشيقاً أيضاً فيما يلي:
1- الدمج المستمر للكود (Continuous Integrations) CI
يجري دمج الشيفرات البرمجية (الكود) المكتوبة من أعضاء الفريق، في شيفرة كود واحدة تضم كامل العمل المنجز.
وعندما يرغب المطورون بدمج الشيفرات التي يكتبونها ضمن كود واحد، لا بد أن يتم حل أية أخطاء أو تعارضات تتسبب بتعطل الكود Code broken.
ويجب أيضاً أن تتواصل هذه العملية كل يوم وباستمرار؛ لأن دمج الأكواد بعد يوم عمل واحد مثلاً، أفضل بكثير من الدمج بعد 6 أو 7 أيام فعندها ستكون الفروقات أكبر، وسينتج عنها دمج أصعب، يتخلله تعطل الكود بعدد مرات أكثر.
إذن فالدمج المستمر هو ممارسة مشتركة بين جميع أفراد الفريق، لتحقيق التكامل المستمر (Continuous Integrations) CI.
2- التسليم المستمر للكود (Continuous Deployment) CD
بعد الدمج المستمر continuous integration الذي تضمن كتابة الكود ودمجه وبناءه واختباره. سنصل إلى مرحلة التسليم، وذلك عبر رفع الشيفرة البرمجية المنجزة increment إلى الخادم (السيرفر). وهذه العملية ينبغي لها أن تكون آلية تماماً.
فمن غير المعقول أن مسؤول العمليات والتشغيل أو المطور المبتدئ. سيأخذ الكود أو المخرج increment ويرفعه يدوياً على السيرفر في كل مرة!
بل سيكون من العبثي أن ينقل الملفات الجديدة بالسحب والإفلات، بعدها يرى ما الملفات التي تغيرت والملفات التي لم تتغير!!
لأن عملية التسليم المستمر للكود هي عملية روتينية ومعقدة، لذلك يتوجب أتمتتها تماماً.
وهذا هو المعنى الحقيقي للتسليم المستمر (Continuous Deployment) CD.
3- تواتر دمج ورفع الشيفرة البرمجية المنجزة
عملية الـ CI/CD يجب أن تكون آلية دون تدخل بشري. ويفترض أن تنتهي خلال دقائق معدودات؛ لأنها عمل روتيني سيتكرر دورياً عدة مرات في كل دورة عمل (سبرنت).
وبحسب أسلوب البرمجة القصوى (eXtreme Programming) XP الشهير ضمن منهجية أجايل. فإن أحد معايير الفريق الرشيق ألاَّ تتجاوز هذه العملية كاملة مدة 10 دقائق فقط.
ما هو مفهوم CI/CD ؟
إذن في هندسة البرمجيات، وجدنا أن CI/CD أو CICD تشير إلى الممارسات المشتركة، للتكامل المستمر، والتسليم أو النشر المستمر.
ويجسّد مفهوم CI/CD الفجوات بين أنشطة التطوير وعمليات التشغيل والفِرَق، من خلال فرض التشغيل الآلي في بناء التطبيقات واختبارها ونشرها.
وهكذا ظهر مفهوم جديد يدعى DevOps تختفي فيه الحدود بين أنشطة التطوير Dev، وعمليات التشغيل Ops.
ما هو مفهوم DevOps ؟
تتضمن ممارسات DevOps الحديثة التطوير المستمر والاختبار المستمر والتكامل المستمر والنشر المستمر والمراقبة المستمرة لتطبيقات البرامج طوال دورة حياة التطوير.
فيما تشكل ممارسة CI/CD مكوناً رئيساً لعمليات DevOps الحديثة.
ختاماً إذا أعجبك هذا الشرح عن المبدأ الأول ألا وهو إرضاء العميل، فيسرنا دعوتك للاشتراك بالنشرة البريدية لموقعنا. حتى تحصل على شروحات مختلفة أخرى لبقية مبادئ الأجايل الاثني عشر، إضافة لأفكار وتطبيقات عملية متعددة عنها.
وإذا كان لديك أي استفسار فلا تتردد بطرحه في التعليقات أدناه، أو راسلنا به عبر عنوان البريد الإلكتروني الآن!