عادة ما تكون الإجابة هي قسم ضمان الجودة أو مهندسي ضمان الجودة (Quality Assurance) و غالباً ما يفهم من جودة المنتج الرقمي.
وهذا الأمر يتم فعلاً ضمن آليات العمل في الإدارة التقليدية (Plan-driven Management) حيث يتم التأكد من جودة المنتج بعد أن يتم تطوير المنتج بالكامل
أما في فريق أجايل يتم إجراء فحص الجودة بالتزامن مع تطوير المنتج في كل دورة عمل (Sprint) وبالتالي الجودة هي جزء من بناء المنتج وليست مرحلة لاحقة
بالنسبة لفريق الإدارة الرشيقة، مسؤولية جودة المنتج الرقمي تقع على عاتق كامل الفريق وليس فقط مهندسي ضمان الجودة.
سيتم بناء الجودة كجزء من المنتج نفسه أثناء مرحلة تطويره المستمرة على دورات عمل عديدة (سبرنت) وسيتم اختبار ماتم انجازه في نهاية كل سبرنت و كل عضو في الفريق عليه جانب من المسؤولية تجاه جودة المنتج الرقمي الذي يساهم ببنائه.
كيف تكون جودة المنتج الرقمي جزء من مراحل تطويره ؟
لنبدأ من البداية!
1- قصص المستخدم- User Stories
تقع على عاتق مالك المنتج كتابة وصياغة قصص المستخدمين التي يجب أن يتم إنجازها في السبرنت، يجب أن تتسم قصص المستخدمين بالاختصار و أن تحوي الهدف الذي يريد المستخدم النهائي إنجازه، بعض الفرق تعاني من الحجم الكبير لقصص المستخدمين لذلك يجب أن يتم تجزئة القصص الكبيرة.
بالإضافة إلى التبسيط والتجزيء، يتم عادة وضع الشروط ومعايير يجب أن تتوفر في قصص المستخدمين ضمن ملف خاص يدعى تعريف جهوزية قصة المستخدم (Definition of Ready).
لا يجب أن يبدأ المطورين بالعمل على أي من المتطلبات مالم تلاقي الشروط الموجودة ضمن ملف تعريف الجهوزية
مثال على ما يمكن أن يحويه هذا الملف من شروط :
- أن يتم وضع توصيف نصي كافي
- في حال كان المطلوب له علاقة بتصاميم بصرية يجب توفيرها للمطورين قبل البدء بالعمل
- أن يتم وضع Acceptance criteria واضحة والتي ستساعد في تحديد متى تعتبر هذه المهمة أنجزت على أكمل وجه
إذن نستنتج من ذلك أنه على مالك المنتج جزء من المسؤولية تجاه جودة المنتج بأن تكون كل المتطلبات المطلوب إنجازها جاهزة بحسب ملف تعريف الجهوزية
كذلك اختبارات القبول (Acceptance Testing) تتم من قبل مالك المنتج في نهاية كل سبرنت (Sprint). عوضاً عن أن يقوم قسم خاص بالجودة في نهاية كامل المشروع بحثاً عن الأخطاء و العيوب كما يحدث في أسلوب الإدارة التقليدية.
2- متى تعتبر المهمة قد انتهت – (DOD)
بعد أن يستلم المطورين كل المتطلبات الجاهزة و المعرفة بشكل جيد، يبدأ المطورين بالعمل عليها ولكن السؤال الهام متى يقول المطور أن المهمة إنجزت، يجب أن يتوفر لدى الفريق ملف يحدد معايير إنتهاء المهمة يدعى ملف DOD = Definition of Done
مثال على ما يمكن أن يحويه هذا الملف من شروط:
- تم إرسال الكود البرمجي إلى مستودع التعليمات البرمجية (Code Repository)
- تمت مراجعة الكود من قبل مطور آخر وطلب التعديلات اللازمة
- تم تشغيل كود وحدات الاختبار بشكل تلقائي (Unit Tests)
- تمت الموافقة على دمج الكود مع الكود المركزي
إذن نستنتج أنه على مطوري المنتج جزء من المسؤولية تجاه جودة المنتج، تتمثل في إتباع المعايير المذكورة في ملف انتهاء المهمة DOD. كذلك يترتب عليهم بعض الواجبات المتعلقة بطريقة كتابة الأكواد البرمجية وأكواد الاختبار ولن أتحدث عنها في هذه المدونة بهدف الاختصار
إذن مسؤولية المبرمج لاتقتصر على تصميم البرنامج وكتابة أكواده!
3- مهمة مهندسي ضمان الجودة QA
سيقوم مهندسي ضمان الجودة بالتأكد من أن كل عمل منجز من القبل المطورين مطابق للشروط القبول المذكورة ضمن المتطلبات. كذلك سيشارك مهندسي ضمان الجودة بتصميم آليات الاختبار التلقائية (Automated Tests) المختلفة والتي تختصر الجهد والوقت اللازم لتكرار الاختبار اليدوي في كل مرة يقوم المطورين بتسليم مهمة منجزة جديدة.
لم أتحدث عن أدوار أخرى و أفراد آخرين بالفريق لهم دور رئيسي برفع جودة المنتج بهدف الاختصار فالهدف من التدوينة التأكيد على أن الجودة ليست على عاتق قسم الجودة فقط
ماذا لو كانت مسؤولية جودة المنتج الرقمي على عاتق مهندسي ضمان الجودة فقط مالضرر في ذلك؟
عندما يتم إسناد المسؤولية لمهندسي ضمان الجودة فقط، سيسبب هذا الأمر في وجود عنق زجاجة بمراحل بناء المنتج. بمعنى كل المصائب والمشاكل لن تظهر إلا عندما تصل لمرحلة الاختبار. بينما لو تشارك جميع أفراد الفريق هذا الواجب فسيتم اكتشاف الأخطاء في وقت مبكر وهذا سيوفر الوقت والجهد.
أيضاً قد يكون سبب في تكاسل باقي أعضاء الفريق تجاه جودة المنتج الرقمي في الوقت الذي سيعاني مهندسي ضمان الجودة من هذه المسؤولية لوحدهم.
أخيراً من أشد الأمور خطورة هو أن عزل المسؤولية تجاه جودة المنتج سيجعل جودة المنتج عبارة عن كرة لهب يتم رميها بين الحين والآخر بين أفراد ضمان الجودة و المطورين بالدرجة الأولى.
كل من يعمل في مجال تطوير البرمجيات يعرف هذه الحالة، وهذه الحالة غير صحية أبداً ومن شدة شيوع هذه الحالة يتم تبادل صور مضحكة على سبيل التندر للحالات التي تحدث بين المبرمجين و ال QA.
هذه الصورة الهزلية تعكس حقيقة بعض الفرق بالفعل، باختصار عزل المسؤولية وحصرها في قسم الجودة لن يؤثر فقط على جودة المنتج بل سيؤثر على ثقافة التعاون في الفريق وسيكون هناك فريقين أو حزبين منفصلين ضمن كل فريق ، حزب المبرمجين و حزب مهندسي ضمان الجودة
عوامل تساعد على زيادة الجودة في المنتج الرقمي
وجود أفراد فريق متعددي المهارات 💪🏻سيساهم برفع جودة المنتج الرقمي لأن متعددي المهارات أقدر على التعاون بينهم لفهم المهمة المطلوب إنجازها وكل فرد فيهم يفهم طبيعة عمل الفرد الآخر ويعي أهميتها.
وجود تطوير دورة تطوير سريعة للميزات وتوصيلها لقسم الجودة بأسرع وقت (Rapid Feature Delivery)
وجود مدير مشروع متعدد المهارات 😎 على علم بآليات الاختبار و آليات تطوير المنتج الرقمي على الصعيد التقني سيعزز من قدرة الفريق أيضاً على إنجاز منتج بجودة عالية.
هل لديك عوامل أخرى تساعد على زيادة الجودة، أو في حالك وجود أي تعليق أرجو ذكرها في التعليقات.