جاء في المبدأ الثاني من مبادئ أجايل:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
” الترحيب بتغيير المتطلبات ولو في مراحل متقدمة من التطوير. فمناهج الأجايل تُسخِّرُ التّغييرَ لصالح الميزة التنافسية للعميل”.
إذن نستنتج مما سبق أن التغيير جميل، التغيير صديقك الصدوق ! ..
حسناً إن كنت مطوّر برمجيات ولم تصدّقني بعد، لكنك بعد إكمال قراءة هذا المقال الثاني من سلسلة مقالات مبادئ أجايل الـ 12 لا بدّ أنك ستتخذ موقفاً ما.
وأنا لا أعلم بعد كيف سيكون هذا الموقف، لكن لنجرّب ذلك على أي حال..
ضمن منهجية أجايل: ما معنى الترحيب بتغيير المتطلبات ؟
يعني ذلك ببساطة أنّ لدينا فريق تطوير برمجيات قد شارف على إنهاء ميزة معينة أو اقترب من تسليم المشروع بالكامل، فإذ بالزبون يباغته -من حيث لا يدري- ويطلب إلغاء الميزة تماماً، والالتفات إلى بناء خاصية أخرى..
الحقيقة أنّ هذا أمر طبيعي تماماً من حيث المبدأ – كما يدّعي إعلان أجايل ضمن المبدأ الثاني منه – بل إن رشاقة الشركة المنفذة للمشروع تُقاس بناءً على مدى سرعة فريقها في الاستجابة للتغييرات المطلوبة!
عند تبنّي هذا المبدأ عملياً، يُفترض أنّ الفريق لن يفكّر بالتغيير على أنه أمر خاطئ أو مزعج، ولن ينتهج نهجاً استعلائياً تجاه الزبون يَصِمُهُ بالجهل أو عدم معرفة ما يريده بالضبط!
لأنّ التغيير قد يخطر للزبون أثناء عرض تقديمي (Demo) من قبل أحد أعضاء الفريق نفسه خلال مراحل التنفيذ والتسليم المتسلسلة؛ أو قد يطرأ تغيُّرٌ مفاجئ في السوق يستوجب الاستجابة لهذا التغيير بسرعة.
لذا ينبغي لإدارة الشركة أن تبذل غاية الجهد لتوضيح هذه السياسة المهمة، كما ينبغي للفريق أن يكون صدره رحباً منفتحاً، وأن يرحّب بطلبات تغيير وتعديل المتطلبات، فهي فرصة لإنتاج منتجات رقميّة ناجحة وتلبّي حاجات حقيقية في هذه السوق ذات التنافسية العالية جداً.
آلية طلب التغييرات من طرف الزبون
على الرغم من ذلك، ينبغي للإدارة أن تحول دون وقوع الفريق فريسة سهلة تحت ضغط سوء إدارة التغييرات، بل يجب أن يكون هناك إدارة لهذا التغيير، وتحديد آليات تلقّي التغيير والاستجابة له بطريقة لا تشتت فريق التطوير.
ومن جهة أخرى يُتوقَّع من الزبون أن يراعي ما يلي:
- ألاّ يطلب تغييرات غير مفيدة لمنتجه وغير مدروسة.
- ألاّ يطلب تغييرات مفاجأة ومتناقضة أحياناً مع بعضها.
لكنَّ ذلك كلّه يجب ألاَّ يكون مدعاةً لبطء الاستجابة لهذه التغييرات المطلوبة بحالٍ من الأحوال، بل الأصل أن تتم مناقشتها بجدّية خلال أقرب اجتماع، مع العمل على جدولة المناسب منها وفق ترتيب وإعادة ترتيب الأولويات.
الترحيب بتغيير المتطلبات في تطوير المنتج الرقمي
هذا هو العنوان الرئيس للحل، أي كيفية تطبيق المبدأ الثاني من مبادئ أجايل عملياً، ويجري ذلك من خلال ما يلي:
- تدريب الزبون وكل أصحاب القرار المؤثرين على منهجيات الإدارة الرشيقة (أجايل) لكي يتعاون الجميع معاً على إدارة التغييرات.
- اعتماد أسلوب رشيق ضمن إطار عمل يلائم إدارة التغيير في المشروع، مثل سكرم (Scrum Framework).
على سبيل المثال: الفريق الذي يطبّق إطار العمل سكرم، سيقوم بتوثيق التغييرات المطلوبة، وجدولتها لدورة العمل القادمة Next Sprint إن أمكن، حتى لا تؤثر سلباً على خطة دورة العمل الحالية، وبالتالي فقد أوجد تنظيماً وإدارة لأية تغييرات قادمة تَرده وتُطلب منه.
- تبنّي بنية معمارية للبرمجية المكتوبة تتواءم مع معمارية الأجايل Agile Architecture، أي ألاّ تكون البنية المعمارية في التقنية المطبقة لتطوير المشروع معيقةً للتغيير.
الوصفة الجيّدة للإدارة الرشيقة في المنتجات الرقمية هي:
بنية معمارية برمجية تلائم أجايل + إطار عمل من أجايل = استجابة سريعة للتغيير
ما هي معمارية أجايل Agile Architecture ؟
تغير التكنولوجيا بشكل سريع كل يوم، وفي الوقت نفسه تتسارع وتيرة تغيُّرات السوق ومتطلباته؛ لذا فكلّ شركة على العموم، وكل شركة برمجية على الخصوص، يجب أن تتبنى المنهجيات والتقنيات التي تساعدها على الاستجابة لهذا التغيير بشكل أسرع وأسرع.
لا لشيء إلاً لهدف البقاء! البقاء كمنافس حقيقي له حصة من هذا السوق، الذي يتّسم بالتنافسية العالية والتغيّر السريع.
يقول ساتيا نادالا الرئيس التنفيذي لمايكروسوفت:
أي شركة هي شركة برمجة في الحقيقية!
دراسة حالة 1
(يمكن قبول التغييرات القادمة من الزبون، حتى وإن كانت بلا إدارة أو جدولة مسبقة؛ ولا يشترط علم مالك المنتج بها كلّ مرة).
- هذه حالة غير صحِّيَّة تَظهر لدى بعض الفرق التي تبني منتجاً رقمياً.
- مدير المشروع أو مدير الشركة يريد أن يكون مرناً مع الزبون..
- وتحت شعار نحن شركة تتبنّى مبادئ الإدارة الرشيقة، ونقبل بكل التغيرات القادمة من الزبون…
- فقد يتصل الزبون بالمصمم مثلاً ويطلب منه تعديلات على تصميم الواجهات.
- أو يتصل الزبون بمطور البرمجيات ويطلب تعديلاً معيناً في وظيفة ما (Functionality).
- ولأن مدير الشركة قد نبَّه على ضرورة المرونة مع الزبون وقبول التغيرات، سيتوجّب على أفراد الفريق قبول هذه التعديلات وتمديد السبرنت.️
- في الحقيقة إنَّ ما سبق ليس إدارة رشيقة على الإطلاق! بل فوضى عارمة ستجعل المشروع يهوي برشاقة نحو الهاوية!
إدارة التغيير في أجايل
أما الإدارة الرشيقة (أجايل) فيجب أن تقوم على إدارة التغيير والاستجابة له بآلية واضحة تضمن ما يلي:
- عدم تشتيت فريق التطوير أثناء عمله حتى لا تضيع بوصلة الهدف الذي تم اعتماده في دورة العمل الحالية (Sprint).
- جدولة التغيير الوارد.
- إعادة ترتيب الأولويات.
- وربما إعادة التقدير الزمني بحسب حجم التغيير المطلوب.
آلية إدارة التغيير من طرف مالك المنتج
لذلك يجب شرح آلية العمل هذه والاتفاق مع الزبون على تبنّيها بدقة لمصلحة الطرفين:
- يجب أن يمر التغيير مهما كان بسيطاً عن طريق مالك المنتج (Product Owner).
- مالك المنتج سيبحث مع فريق التطوير إمكانية تضمين التغيير ضمن دورة العمل الحالية إن أمكن.
- قد يتجنب مالك المنتج طرح الفكرة على فريق التطوير لعلمه المسبق بأن العمل الحالي ذو أولوية أعلى.
- قد يتم تضمين التغيير في دورة العمل الحالية (السبرنت) مقابل إزالة بعض الأعمال الأقل أولوية وتأجيلها إلى دورات عمل قادمة.
- لا مشكلة أبداً من حيث المبدأ من التواصل المباشر من قبل الزبون مع أفراد الفريق.
ضمن رحلة بناء المنتج الرقمي، يعدّ تدعيم دور مالك المنتج أمراً أساسياً لضمان وضوح وصيانة المتطلبات المتغيرة
دراسة حالة 2
(عدم وضوح المتطلبات بالوقت المناسب في بداية السبرنت، وبالتالي تتوارد تباعاً للفريق أثناء التنفيذ).
هذه ظاهرة شائعة في عملية تطوير المنتج الرقمي:
- مالك المنتج (Product Owner)، أو مدير المنتج، يقوم بإضافة كمية كبيرة من التوضيحات على ميزة معينة أثناء قيام فريق التطوير بتطويرها.
- وهذه الظاهرة إذا كانت زائدة عن حدّها المنطقي في إطار التوضيح، فهي دليل أن المتطلبات لم تكن واضحة منذ بداية السبرنت.
- وهنا يجب التأكيد على ضرورة عدم الخلط بين عدم وضوح المتطلبات في الوقت المناسب من جهة، ومبدأ الترحيب بتغيير المتطلبات في أي وقت.
كيف تُصنّف حالة (إضافة توضيحات هائلة على المتطلبات أثناء التنفيذ)؟
للأسف هي حالة سلبية بلا شك.
ما سبب ظاهرة التوضيحات الكثيرة على المتطلبات ؟
تعود لعدّة أسباب منها:
- عدم مناقشة المتطلبات بشكل كافٍ عند بداية دورة العمل، وبالتالي فقد أخذت الايضاحات تتوالى تباعاً على كل متطلب من المتطلبات، نتيجةً لنقاشات أخرى متأخرة تجري أثناء دورة العمل.
- المتطلبات لم تُفصَّل بما فيه الكفاية؛ لأنَّ بعض الإجابات معلّقة، أو غير مفهومة، أو غير واضحة بانتظار أن يرد الزبون أو صاحب المصلحة على استفسارات الفريق ابتداءً.
- قد يكون هنالك ضعف في قدرة مالك المنتج على صياغة المتطلبات بشكل واضح مفهوم قبل بداية التنفيذ.
- أو ربما يكون الزبون بطيئاً في الإجابة.
- لم يُعقد اجتماع التخطيط في بداية دورة العمل بشكل سليم.
- لم يحضر مالك المنتج اجتماع التخطيط، واكتفى بإرسال المتطلبات إلى فريق التطوير؛ فلم يحصل فريق التطوير على حقّه في الإجابة عن استفساراته ذات الأهمية القصوى.
- الافتقار إلى قدرٍ كافٍ من التعاون أو التفاهم بين مالك المنتج وفريق التطوير، فبالرّغم من أنّ المتطلبات تقع ضمن نطاق مسؤوليات مالك المنتج، إلا أنه من الأهمية بمكان أن يشرك فريق التطوير بصياغتها.
من المسؤول؟
كل هذه العناصر وكثيرٌ غيرها، لا تقع مسؤوليتها المباشرة على كاهل فريق التطوير، لكن بالرغم من ذلك، فإن أكثر ما يتكرّر سماعه في مجال صناعة البرمجيات هو قولهم:
- فريق التطوير متأخر!
- لا يعرف فريق التطوير كيف يقدّر الزمن المطلوب للتسليم!
- فريق التطوير ينتج برمجيات بجودة سيئة!
في الحقيقة هذه نتائج وليست أسباب؛ ولسنا بذلك نبرّأ ساحة المطورين تماماً من أية مسؤولية عن مثيلات تلكم النتائج، ولكن قبل لوم المطورين والتقنيين لا بد أن نتأكد من صحة الآليات المتبعة لإدارة فريق التطوير من جهة، وإدارة الإجراءات والعمليات من جهة أخرى.
الخلاصة
أجايل ترحب بالتغيرات حتى لو كانت في مرحلة مبكرة من التطوير، لكنّها لا ترحب بتوضيح التفاصيل في وقت متأخر؛ كذلك لا ترحب بقبول طلبات تغيير عشوائية بلا إشراف من مالك المنتج، وبلا جدولة أولويات صحيحة.
والآن أخبرنا عن رأيك بالمبدأ الثاني من مبادئ إعلان أجايل المتعلّق بقضية القبول بل و الترحيب بتغيير المتطلبات، هل واجهتك أية صعوبات في هذا الصدّد؟ حدثنا عنها على بريد الموقع أو في صندوق النقاشات أدناه.