إذا كنت تستخدم منهجية رشيقة agile لإدارة مشروعك - كإطار عمل سكروم Scrum -، وكان فريق سكرم الخاص بك يجد نفسه غير قادر على تسليم متطلبات المشروع بنهاية السبرنت sprint لأنها لا تزال قيد الاختبار، فإن هذه المقالة لك.
ممارسة شائعة - وخاطئة - بين فرق أجايل المبتدئة هي أن يقوم المطورون بإكمال تنفيذ جميع المتطلبات ومن ثم تسليمها إلى مهندسي ضمان الجودة أو المُختَبِرين (QA) قبل نهاية السبرنت. يتوقع المبرمجون أن يقوم مهندسو ضمان الجودة بالتحقق من صحة كل هذه المتطلبات في الأيام الأخيرة المتبقية من السبرنت، وهذا الاعتقاد غير واقعي ويؤدي إلى فشل السبرنت. دعونا نستكشف السبب الجذري لهذه المشكلة، والعواقب التي ستنجم عنها، وكيفية تعزيز التعاون الفعّال أثناء التعامل مع متطلبات المشروع.
المشكلة
هذا النمط من التعاون غالبًا ما يتضمن أن يقوم المطورون بالعمل على متطلب وبرمجته بالكامل وفقًا لمعايير القبول، ومن ثم تسليم المتطلب بأكمله إلى مهندسي ضمان الجودة للتحقق من صحته. هذه الطريقة تؤدي إلى نقل كمية كبيرة من العمل دفعة واحدة قبل نهاية السبرنت، مما يجعل من الصعب على مهندسي ضمان الجودة إكمال عملهم في الوقت المحدد (في الغالب ستجد أن جدول المشروع مقسوم إلى قسمين رئيسية: قسم لمهام التطوير، وقسم آخر لمهام الاختبار!). علاوة على ذلك، تعكس هذه الممارسة سوء فهم أساسي لمبدأ مهم في أجايل: التنفيذ غير المتسلسل.
التنفيذ غير المتسلسل يتضمن تقسيم المهام بحيث تتم جوانب مختلفة من المهام المطلوبة لتطوير الميزة - مثل التطوير البرمجي والاختبار - بشكل متزامن بدلاً من التتابع. هذا النهج يساعد على منع اختناقات العمل ويضمن أن جميع أعضاء الفريق منخرطون خلال السبرنت (سيتخلف شكل جدول المشروع عند اعتماد التنفيذ غير المتسلسل وسيصبح شكله "فوضوي" - إن شئت سمها فوضى خلاقة :) ، حيث ستجد أن مهام التطوير والاختبار يتم تنفيذها في وقت واحد). هذا المبدأ، الذي يدعو إلى "القيام بالقليل من كل شيء بدلاً من الكثير من شيء واحد"، هو مفتاح نجاح مشاريع أجايل. وإلا، فإن السبرنت ستتحول إلى مشروع كلاسيكي صغير - mini-waterfall project -، حيث يتم التطوير والاختبار في مراحل متتابعة صارمة، مما يقوض المرونة والقدرة على التكيف التي يوفرها إطار عمل سكرم والمنهجيات الرشيقة عموماً.
العواقب
فشل السبرنت: من المحتمل أن تفشل السبرنت، مما يؤدي إلى انخفاض معدل الالتزام للفريق. وسيكون أصحاب المصلحة محبطين لأنهم لم يحصلوا على المتطلبات المكتملة.
خمول مهندسي ضمان الجودة أثناء السبرنت: يظل مهندسو ضمان الجودة بدون عمل في بداية السبرنت، في انتظار أن يكمل المطورون عملهم. هذا يؤدي إلى عدم الكفاءة وانخفاض الانخراط المبكر لمهندسي ضمان جودة في المشروع.
ممارسات سيئة: ستلجأ بعض الفرق إلى ممارسات سيئة لا تتوافق مع قيم ومبادئ منهجيات إدارة المشاريع الرشيقة من أجل حل هذا الإشكال، مثل جعل مهندسي ضمان الجودة يعملون في سبرنت مستقل ومتأخر عن المطورين. هذا يؤدي إلى:
وصول متأخر إلى السوق: ستفقد المنظمة - خصوصاً إذا كانت المنظمة شركة ناشئة ومحاطة بالعديد من المنافسين - الميزة التنافسية لأن الميزات التي تريد إطلاقها إلى السوق تستغرق وقتًا أطول للتطوير - دورتي تطوير بدلاً من دورة واحدة -، فبالتالي سيزداد الوقت اللازم للوصول إلى السوق.
التبديل بين المهام context switching : بحلول الوقت الذي سيتلقى فيه المطورون التقييم لمخرجات عملهم، سيكون الكود قد "تبخَّر" من أذهان المطورين، مما يجعل معالجة الأخطاء البرمجية بسرعة وكفاءة أكثر صعوبة.
فقدان تماسك الفريق: يفقد الفريق العقلية المشتركة "نحن جميعًا في هذا معًا". قد يشعر المطورون أنهم أكملوا وظيفتهم، تاركين المختبرين يتحملون مسؤولية إكمال السبرنت.
الطريقة الصحيحة للتعاون بين المطورين ومهندسي ضمان الجودة
المشكلة هنا هي نقل كمية كبيرة من العمل دفعة واحدة. لتجنب ذلك، يجب على المطورين والمختبرين التعاون عن كثب من خلال نقل أجزاء صغيرة من المتطلب بشكل تدريجي.
ستكون البداية بمناقشة بين المطور والمُختَبِر على أي جزء من المتطلب يجب تطويره أولاً. ثم يقوم المطور ببرمجة هذا الجزء الصغير فقط، بينما يقوم المختبر في نفس الوقت بإنشاء حالات الاختبار، وإعداد بيانات الاختبار، وإذا أمكن، بأتمتة الاختبارات لهذا الجزء من المتطلب.
بمجرد أن يكمل المطور الجزء الخاص به، يتم تسليمه على الفور إلى المختبر. يكمل المختبر بعد ذلك أي عمل ضروري على حالات الاختبار الآلية ويقوم بتشغيل الاختبارات. يتم تحديد الأخطاء وإصلاحها قبل الانتقال إلى الجزء التالي من المتطلب.
ستكرر هذا العملية تدريجياً، مع كميات من العمل صغيرة ومتكررة وعمل متزامن حتى يتم إكمال جميع أجزاء المتطلب. هذا النهج يضمن أن الاختبارات تواكب التطوير، مما يقلل من احتمالية فشل السبرنت.
من المهم ملاحظة أن هذه الطريقة تركز على التطوير التدريجي incremental development حيث يتم تطوير كل جزء من الوظائف بالكامل واختباره قبل الانتقال إلى الجزء التالي. يضمن التطوير التدريجي تمكين الفريق من تسليم برامج تعمل في نهاية كل سبرنت. ابدأ بتطبيق هذه الخطوات في سبرنتك القادم، وشاهد كيف ستتحسن كفاءة فريقك وإنتاجيته.
