Agile هي منهجية لتطوير البرمجيات لبناء برنامج بشكل تدريجي باستخدام تكرارات قصيرة تتراوح من 1 إلى 4 أسابيع بحيث تتماشى عملية التطوير مع احتياجات العمل المتغيرة. بدلاً من التطوير لمرة واحدة لمدة تتراوح من 6 إلى 18 شهرًا حيث يتم التنبؤ بجميع المتطلبات والمخاطر مقدمًا، تتبنى Agile عملية تقديم تعليقات متكررة حيث يتم تسليم منتج عملي بعد تكرار من 1 إلى 4 أسابيع.
المهام والأدوار في Agile
Scrum Master
إن Scrum Master هو قائد الفريق والميسر الذي يساعد أعضاء الفريق على اتباع الممارسات الرشيقة حتى يتمكنوا من الوفاء بالتزاماتهم. مسؤوليات سيد سكروم هي كما يلي :
1 – لتمكين التعاون الوثيق بين جميع الأدوار والوظائف.
2 – لإزالة أي معوقات.
3 – لحماية الفريق من أي اضطرابات.
4 – للعمل مع المنظمة لتتبع التقدم والعمليات في الشركة.
5 – للتأكد من الاستفادة من عمليات Agile Inspect & Adapt بشكل صحيح والذي يتضمن (المواقف اليومية, الاجتماعات المخطط لها، عرض توضيحي، المراجعة، الاجتماعات بأثر رجعي، ولتسهيل اجتماعات الفريق وعملية صنع القرار).
Product Owner
مالك المنتج Product Owner هو الذي يقود المنتج من منظور الأعمال. المسؤوليات أو مالك المنتج هي كما يلي :
1 – تحديد المتطلبات وتحديد أولويات قيمها.
2 – لتحديد تاريخ الإصدار ومحتوياته.
3 – للقيام بدور نشط في تخطيط التكرار واجتماعات تخطيط الإصدار.
4 – للتأكد من أن الفريق يعمل على المتطلبات الأكثر قيمة.
5 – لتمثيل صوت العميل.
6 – لقبول قصص المستخدم التي تلبي تعريف معايير القبول المحددة والمحددة.
Cross-functional Team
يجب أن يكون كل فريق Agile فريقًا مكتفيًا ذاتيًا يضم من 5 إلى 9 أعضاء في الفريق وبخبرة متوسطة تتراوح من 6 إلى 10 سنوات. عادةً، يتكون فريق Agile من 3 إلى 4 مطورين، ومختبر واحد، ورئيس فني واحد، ومالك منتج واحد، ومدير سكروم واحد.
يعتبر مالك المنتج وScrum Master جزءا من واجهة الفريق، في حين أن الأعضاء الآخرين هم جزء من الواجهة الفنية.
كيف يخطط فريق Agile لعمله؟
يعمل فريق Agile في التكرارات لتقديم قصص المستخدمين حيث تتراوح مدة كل تكرار من 10 إلى 15 يومًا. يتم تخطيط كل قصة مستخدم بناءً على أولويات الأعمال المتراكمة وحجمها. يستخدم الفريق قدرته – عدد الساعات المتاحة مع الفريق للعمل على المهام – لتحديد مقدار النطاق الذي يتعين عليهم التخطيط له.
Point
تحدد النقطة مقدار ما يمكن أن يلتزم به الفريق. وتشير النقطة عادة إلى 8 ساعات. يتم تقدير كل قصة بالنقاط.
Capacity
تحدد القدرة مدى قدرة الفرد على الالتزام. يتم تقدير السعة بالساعات.
ما هي User Story ؟
قصة المستخدم هي مطلب يحدد ما يطلبه المستخدم كوظيفة. يمكن أن تكون قصة المستخدم في شكلين :
1 – باعتباري <دور المستخدم> أريد <الوظيفة> بحيث <قيمة الأعمال>
2 – من أجل <قيمة العمل> باعتبارها <دور المستخدم> أريد <الوظيفة>
أثناء تخطيط الإصدار، يتم تقديم تقدير تقريبي لقصة المستخدم User Story باستخدام المقياس النسبي كنقاط. أثناء التخطيط للتكرار، يتم تقسيم القصة إلى مهام.
العلاقة بين متطلبات المستخدم User Story والمهام
1 – قصة المستخدم تتحدث عن ما يجب القيام به. فهو يحدد ما يحتاجه المستخدم.
2 – تتحدث المهمة عن كيفية القيام بها. فهو يحدد كيفية تنفيذ الوظيفة.
3 – يتم تنفيذ القصص عن طريق المهام. كل قصة عبارة عن مجموعة من المهام.
4 – يتم تقسيم قصة المستخدم إلى مهام عندما يتم التخطيط لها في التكرار الحالي.
5 – يتم تقدير المهام بالساعات، عادةً من 2 إلى 12 ساعة.
6 – يتم التحقق من صحة القصص باستخدام اختبارات القبول.
حينما تنتهي متطلبات المستخدم
يقرر الفريق ما يعنيه القيام به. قد تكون المعايير :
1 – تم الانتهاء من جميع المهام (التطوير والاختبار).
2 – جميع اختبارات القبول قيد التشغيل وتم اجتيازها.
3 – لا يوجد عيب مفتوح.
4 – لقد قبل مالك المنتج القصة.
5 – قابلة للتسليم إلى المستخدم النهائي.
ما هي معايير القبول؟
تحدد المعايير الوظائف والسلوك والأداء الذي تتطلبه الميزة بحيث يمكن لمالك المنتج قبولها. فهو يحدد ما يجب القيام به حتى يعرف المطور متى تكتمل قصة المستخدم.
كيف يتم تحديد المتطلبات؟
يتم تعريف المتطلبات على أنها (قصة مستخدم، مع معايير القبول، و مهام تنفيذ القصة).