Software Development Process – Scrum

Software Development Process – Scrum


أدوار الـ SCRUM


الـ Business Analyst محلل الأعمال وتكون مهامه الأساسية باختصار كالآتي:

  • هو عبارة عن حلقة الوصل بين “مالك المنتج والأعمال” وبين الفريق التقني ويكون هو المرجع للفريق التقني في حال وجود استفسار يخص المالك
  • يتولى مسؤولية التنسيق مع “مالك المنتج والأعمال” لتلبية احتياجات العمل
  • يقوم مسؤولية ترتيب أولوية الـ Backlog وكتابة تفاصيل عناصره
  • يقوم بتحديد Scope الـ Sprint
  • يقوم باستلام عناصر الـ Sprint من الفريق التقني وفريق المختبرين ويتأكد من توافق العناصر مع احتياجات فريق “مالك المنتج والأعمال”

الـ Technical Leader القائد التقني وتكون مهامه الأساسية باختصار كالآتي:

  • يقوم بالإشراف على الفريق التقني وإدارته
  • يقوم بالموافقة على الـ User Story تقنيا بحيث يضمن أنها يمكن تنفيذها من الناحية الفنية
  • يقوم بالتحقق من تقديرات الوقت لأعضاء الفريق التقني
  • يكون مسؤول عن تسليم عناصر الـ Sprint للـ Business Analyst

الـ Developer المطور وتكون مهامه الأساسية باختصار كالآتي:

  • يقوم بتقسيم المهام بالتعاون مع الفريق ويقوم بوضع وقت تقديري لكل مهمة سيقوم بالعمل عليها
  • يكون مسؤول عن تسليم المهمات المعينة له في خلال الـ Sprint

الـ Tester المختبر وتكون مهامه الأساسية باختصار كالآتي:

  • يقوم بالموافقة على الـ User Story بحيث يضمن أنها يمكن اختبارها
  • يقوم باستلام الـ User Story من الفريق التقني واختبارها والتأكد من أنه تم تنفيذ خصائص القبول الخاصة بها والمتوافقة مع “مالك المنتج والأعمال”
  • يقوم بكتابة حالات الاختبار المتوافقة مع متطلبات محلل الأعمال لكل User Story

الـ Scrum Master يتكون مهامه الأساسية باختصار كالآتي:

  • يقوم بالتنسيق بين جميع أعضاء الفريق ليضمن سير العمل بدون عوائق ويساعد علي إزالتها
  • يقوم بتوجيه الفريق نحو الأهداف الصحيحة لكل فعالية تحدث
  • يقوم بتنظيم فعاليات الـ Scrum مع الفريق
  • يقوم بالتعاون مع الفريق ليضمن قيام كل دور بالمتفق عليه

دورة حياة الـ Sprint:


كيف يتم الإعداد قبل الـ Sprint:

  1. تحديد الـ Scope: يقوم محلل الأعمال بتحديد الـ User Stories التي لها الأولوية في العمل عليها في الـ Sprint مع كتابة الوصف الخاص بكل User Story.
  2. كتابة الـ User Stories: يقوم محلل الأعمال بكتابة خصائص القبول Acceptance Criteria لكل User Story ووضع كل التفاصيل التي من شأنها إيصال المعلومات بشكل واضح للفريق.
  3. اجتماع المراجعة التقنية: يقوم الفريق التقني مع فريق المختبرين بمراجعة ال User Stories التي تم كتابتها مع محلل الأعمال للتأكد من عدم وجود تعارض بين الـ User Stories ويتم تحسين الـ User Stories لتكون جاهزة للدخول في الـ Sprint.

كيف يتم كتابة User Story بكفاءة:

  1. كتابة العنوان واضح وغالبا ما يبدأ بفعل (مثال: إضافة مستخدم جديد)
  2. كتابة الوصف بشكل يساعد على فهم الفعل المطلوب والهدف من هذا الفعل مع توضيح ومن سيقوم بهذا الفعل (مثال: كمدير للنظام أريد أن أتمكن من إضافة مستخدم جديد حتى يتمكنوا من استخدام النظام)
  3. يجب أن تكون الـ User Story تمثل قيمة لمحلل الأعمال 
  4. يجب أن يكون المختبرين قادرين على اختبار الـ User Story
  5. يجب أن يكون التقنيين قادرين على وضع الوقت المناسب لتنفيذ الـ User Story
  6. من الأفضل أن تكون الـ User Story صغيرة يمكن إنجازها في يوم واحد
  7. يجب وضع تصميم سواء Design أو Wireframe لتوضيح خبرة المستخدم إلا في حالات استثنائية مثلا User Story لعمل Payment Gateway فيمكن الاستغناء عن التصميم
  8. معلومات توضيحية للـ User Story يتم تحديدها طبقا لنوعية المعلومات المطلوب توضيحها

متي يتم إنجاز الـ User Story؟

  1. عندما يتم عمل الـ Code الذي يؤدي الوظائف المطلوبة
  2. عندما تتحقق كل خصائص القبول
  3. عندما يتم اجتياز الـ Unit Test الخاص بها
  4. عندما يتم إطلاقها على بيئة الاختبار التي تماثل البيئة الحقيقية
  5. عندما تجتاز جميع سيناريوهات الاختبار الموضوعة
  6. عندما يتم حل جميع ال Bugs المتعلقة بها طبعا للـ Scope المتفق عليه
  7. عندما يتم استلامها من مالك المنتج والأعمال
  8. عندما يتم إطلاقها على الـ Production

ما هو مسار الـ User Story؟

  1. يقوم محلل الأعمال بإنشاء الـ User Story باتباع الخطوات الموضحة سابقا وتكون في وضع New
  2. يقوم فريق التقنية بإنشاء المهام المتعلقة بهذه الـ User Story
  3. يقوم فريق المختبرين بإنشاء حالات الاختبار المتعلقة بالـ User Story
  4. في حالة جاهزية ال User Story للدخول في الـ Sprint مع وجود الأولوية لها يتم دخولها للـ Sprint بحالة Open
  5. عندما يتم بدء العمل على المهام المتعلقة بها يتم انتقالها لحالة In progress
  6. عند انتهاء العمل عليها من الفريق التقني يتم انتقالها لحالة Ready on Dev وهذا يعني أنها تم اختبارها من خلال الفريق التقني وجاهزة للعمل عليها من خلال فريق المختبرين
  7. في حالة اجتيازها لمرحلة المختبرين يتم انتقالها لمرحلة Ready for UAT لفريق الـ Business ليقوم باستلامها UAT
  8. في حالة اجتيازها لمرحلة UAT يتم انتقالها لحالة Ready for Production
  9. يتم عمل اختبار BVT للنظام ومن ثّم إطلاق الـ User Story لتتحول لحالة Deployed
  10. في حالة عدم اجتيازها لأي مرحلة من المراحل السابقة يتم إعادتها طبقا للمرحلة Reopen مع التحقق من سبب عدم الاجتياز ليتم إصلاحه وإعادة الخطوات السابقة

ما هو مسار الـ Task؟

  1. يقوم فريق التقنية بعمل هذه الخطوات مع كل User Story
  2. يقوم فريق التقنية بإنشاء المهام المتعلقة بهذه الـ User Story ويتم ربطها بها
  3. يقوم فريق التقنية بتقييم الوقت لكل مهمة وتوزيع المهام على أعضاء الفريق
  4. يمكن فريق التقنية بإنشاء بعض المهام الغير متعلقة ب User Story محددة ولكنها تخدم المشروع بالكامل أو تكون بعض المهام متعلقة بأكثر من User Story فيتم ربطها بها
  5. عندما يتم بدء العمل على المهام تكون في حالة Open ويتم انتقالها لحالة In progress
  6. عند انتهاء العمل عليها من الفريق التقني يتم انتقالها لحالة Code Review  وهذا يعني أنها تم الانتهاء من عمل الـ Code الخاص بها وتنتظر مراجعة من شخص آخر غير الذي قام بها.
  7. عند انتهاء الـ Code Review العمل عليها من الفريق التقني يتم انتقالها لحالة Ready on Dev وهذا يعني أنها تم اختبارها من خلال الفريق التقني وجاهزة للعمل عليها من خلال فريق المختبرين ويقوم فريق المختبرين باختبارها إن كانت تحتاج لاختبار منفصل قبل اختبار الـ User Story
  8. يتم انتقالها بعد ذلك لحالة Done وهي الحالة النهائية بالنسبة للمهمة إلا إذا كانت مهمة متعلقة بالمشروع ككل ويجب انتقالها إلي حالة Ready for Production ليتم إطلاقها
  9. يتم عمل اختبار BVT للنظام ومن ثّم إطلاق المهمة لتتحول لحالة Deployed
  10. في حالة عدم اجتيازها لأي مرحلة من المراحل السابقة يتم إعادتها طبقا للمرحلة Reopen مع التحقق من سبب عدم الاجتياز ليتم إصلاحه وإعادة الخطوات السابقة

كيف يتم كتابة Bug بكفاءة:

  1. كتابة العنوان واضح
  2. كتابة الوصف بشكل يساعد على فهم الفعل المطلوب والهدف من هذا الفعل مع توضيح ومن سيقوم بهذا الفعل (مثال: كمدير للنظام أريد أن أتمكن من إضافة مستخدم جديد حتى يتمكنوا من استخدام النظام)
  3. يجب أن يكون التقنيين قادرين على وضع الوقت المناسب لتنفيذ الـ Bug
  4. يجب ربط الـ Bug بـالـ User Story إلا في حالات نادرة جدا كاستثناء كأن تكون الـ Bug عامة مثلا بتوقف النظام بالكامل
  5. يجب ربط الـ Bug بـالـ Test Case الخاصة بها داخل الـ User Story إلا في  حالات نادرة جدا كاستثناء كأن تكون الـ Bug عامة مثلا بتوقف النظام بالكامل
  6. يجب وضع فيديو أو صورة توضيحية للمشكلة حتي يتمكن الفريق التقني من إعادة إنتاجها مرة أخري ليعمل عليها
  7. يفضل وضع الرابط من داخل النظام من الصفحة التي حدثت بها المشكلة ليمكن سهولة تتبعها من خلال الفريق التقني

ماهي الـ Development Activates من خلال الـ SCRUM؟


الـ Backlog:

  • يكون الـ Product Owner أو من يقوم مقامه بالمساعدة مع الـ Scrum Master بترتيبه طبقا لأولوية الـ Business
  • يقوم الفريق بعمل Backlog Refinement ويضع في ذلك وقتا مناسبا (١٠ بالمئة) من وقت الـ Sprint والـ Refinement يكون بإصقال الـ User Story بالمعلومات المطلوبة بمرور الوقت وإضافة كل ما يتعلق بها حتى تكتمل وتكون جاهزة للـ Sprint

الـ Pre Sprint Planning:

  • يقوم بتنظيمه الـ Scrum Master بهدف عمل Refinement للـ User Stories التي يجب أن تكون جاهزة قبل ال Sprint
  • يفضل أن يكون جميع الفريق حاضرا من الـ Business والتقنية لكن يمكن أن ينوب عن كل فريق عضو فمثلا يمكن أن تتكون هذه الفعالية من محلل الأعمال وأحد المطورين وأحد المختبرين بشرط أن يكونوا جميعا علي دراية كافية وشاملة بالـ Business
  • يقوم الفريق بمناقشة الـ User Stories وإصقالها بالمعلومات اللازمة وحل أي تعارض تقني أو Business لتكون الـ User Story جاهزة للدخول في الـ Sprint Planning
  • يتم عمل هذا مع كل User Story يريد الـ Business وضعها في الـ Sprint

الـ Sprint Planning:

  • يقوم بتنظيمه الـ Scrum Master بهدف عمل تخطيط لمدة أسبوعين أو حسب ما يتفق الفريق علي المدة الثابتة للـ Sprint وأيضا بهدف التخطيط اليومي لكل يوم في مدة الـ Sprint
  • يقوم الفريق بالاتفاق علي هدف واضح للـ Sprint يقوم بتوضيحه الـ Product Owner أو من يقوم مقامه ويكون تركيز الفريق في خلال هذه المدة على تحقيق هذا الهدف
  • يتم عمل تقييم لكل User Story من خلال وضع تقييم وقتي لكل مهمة تابعة لها
  • ويتم تعيين الشخص المناسب لكل مهمة مع الأخذ في الاعتبار الـ Capacity الفعلية المتاحة لكل شخص في خلال هذه المدة (لا يتم احتساب وقت الاجتماعات الخاصة بالـ SCRUM وكذلك وقت الـ Deployment إن وُجٍد خلال الـ Capacity)

الـ Daily Standup:

  • يجب أن يقوم الفريق بعمل هذه الفعالية يوميا في وقت أقصاه ١٥ دقيقة
  • يكون الهدف منها هو مراجعة التخطيط الذي تم في الـ Sprint Planning والتأكد من إنهاء الـ User Stories كما المتفق عليه سابقا
  • أيضا يتم توضيح أي عقبات أو مشكلات متوقع أن تواجه أعضاء الفريق ليتم حلها سريعا قبل أن تقوم بتعطيل العمل علي المهام وبالتالي تعطيل تسليم الـ User Stories
  • كل عضو في الفريق يوضح ما هي نسبة الجزء الذي تم إنجازه من منظور الـ User Story فقط لا غير وليس من أي منظور آخر وكذلك يوضح ما يتوقع أن يقوم بإنجازه في اليوم الجديد

الـ Demo Meeting:

  • يقوم الفريق التقني باستعراض ما تم إنجازه علي الـ Production أو ما قبل الـ Production
  • يقوم فريق الـ Business بإعطاء الفيد باك إن وُجِد ويقوم بعمل ترتيب أولويات لخطة الـ Sprint القادم

الـ Retrospective Meeting:

  • يقوم الفريق بعقد هذه الفعالية بهدف المراجعة والتحسين المستمر في عملية التطوير ليتم الحفاظ علي نقاط القوة في الفريق ومعالجة القصور وإضافة تحسينات للفريق لدعمه وزيادة إنتاجيته

بعض التعليمات العامة الهامة:

  • الـ Business Analyst هو المسؤول عن تحديد الأولويات فقط ولا يحق لأي شخص تغيير الأولوية بدون الرجوع إليه
  • يجب على جميع أعضاء الفريق حضور الاجتماع اليومي Stand up في بداية اليوم وكذلك جميع فعاليات الـ SCRUM ويجب التنسيق مع الفريق في حالة التخطيط لعدم الحضور
  • لا يجب على أي من أعضاء الفريق العمل على مهمة غير مسجلة على الـ Task Management Tool في حالة فريقنا AzureDevops
  • لا يجب على أي من أعضاء الفريق العمل على مهمة بدون وضع وقت تقديري لها
  • يفضل أن يكون أقصي وقت تقديري للمهمة هو ٤ ساعات
  • الـ Technical Leader يجب أن يكون المسؤول عن Merge الـ Pull Requests في نفس اليوم الخاصة بجميع أعضاء الفريق التقني ويمكن أن يفوض من يقوم بذلك بإشرافه
  • يجب أن يتم مراجعة Review أي PR من عضو تقني آخر
  • يجب أن تكون بيئة الاختبار مماثلة تماما لبيئة الـ Production
  • غير مسموح بعمل Merge على بيئة الاختبار أو الـ Production إلا بعد اتباع التعليمات التالية:
    • يقوم المطور بعمل Branch جديد ليقوم بالعمل عليه فيما هو مطلوب منه
    • عند الانتهاء من العمل علي هذا الـ Branch يقوم بعمل Merge له علي بيئة التطوير Dev. Environment
    • يتم عمل الاختبار الأولي من المطور على بيئة التطوير لما قام بالعمل عليه ويمكن أن يستعين بأحد المختبرين ليساعده في هذا الاختبار الأولي
    • حين يطمئن المطور للاختبار علي بيئة التطوير يقوم بطلب الإذن من المختبرين لعمل Merge لهذا الـ Branch علي بيئة الاختبار التي تخص المختبرين
    • في حالة موافقة المختبرين (تتم الموافقة في حالة عدم احتياج المختبرين لهذه النسخة من النظام المتوفرة على بيئة الاختبار) يتم عمل الـ Merge على بيئة المختبرين
    • يقوم المختبرين بإجراء الـ Build Verification Test على بيئة الاختبار للتأكد من سلامة أساسيات النظام بعد عمل الـ Merge
    • في حالة التأكد من سلامة أساسيات النظام يتم إجراء الاختبار على الجزء الذي قام المطور بعمل Merge له
    • في حالة اجتياز الاختبار يتم عمل Merge على بيئة الـ Production بعد أخذ الإذن من مالك المنتج والأعمال
    • بعد عمل الـ Merge على الـ Production يقوم فريق المختبرين بإجراء الـ BVT علي بيئة الـ Production للتأكد من سلامة أساسيات النظام ثم عمل اختبار علي الجزء الذي تم عمل Merge له