تخطيط السبرينت: أفضل ممارسات أجايل

أساسيات التخطيط

يحتاج تخطيط السبرنت الجيد إلى نهج منظم يبدأ بمراجعة السبرنتات السابقة، ثم تقدير ما يستطيع الفريق إنجازه فعلاً، ثم صياغة الأهداف صياغة واضحة. مزيد من المعلومات: برنامج إدارة مشاريع تكنولوجيا المعلومات لفرق تكنولوجيا المعلومات.

1. ينبغي أن يبدأ التحضير للتخطيط قبل موعده بوقت كافٍ. فعلى Product Owner أن يجهز backlog ويرتب أولوياته قبل الاجتماع بيوم واحد على الأقل، وأن تُتاح لفريق التطوير فرصة الاطلاع على قصص المستخدم مسبقاً وطرح ما لديه من أسئلة.
2. القاعدة الكلاسيكية في توزيع الوقت: ساعتان من التخطيط لكل أسبوع من السبرنت، أي أربع ساعات لسبرنت مدته أسبوعان، وإن كانت التجربة تبين أن تقسيم هذا الوقت على عدة جلسات قصيرة يأتي غالباً بنتيجة أفضل من اجتماع واحد طويل.

مرحلة التحضير

لا سبيل إلى تحسين تخطيط السبرنت من غير تحضير جيد، وهذه المرحلة كثيراً ما يُستهان بها مع أنها هي التي تحدد نجاح العملية كلها.

• Definition of Ready (DoR) تحدد الشروط التي يجب أن تستوفيها قصة المستخدم قبل إدراجها في السبرنت، فلكل قصة معايير قبول واضحة وتقدير لدرجة تعقيدها وتبعيات معروفة على المهام الأخرى. وإذا لم يُلتزم بـ DoR تحول التخطيط إلى فوضى، وانشغل الفريق باستيضاح المطلوب بدلاً من التخطيط للتنفيذ.
• Backlog refinement ينبغي أن يجري بانتظام طوال السبرنت، وألا يقتصر على الساعات التي تسبق التخطيط مباشرة. والمعتاد أن يُخصص له 10% من وقت السبرنت، ويمكن للفريق أن يعقد جلسات تنقيح قصيرة عدة مرات في الأسبوع يعمل فيها تدريجياً على قصص السبرنتات القادمة.
• تحليل Velocity يمنح الفريق صورة دقيقة عن قدرته الحقيقية على التسليم. ولا يكفي فيه الاعتماد على متوسط Velocity للسبرنتات الـ 3-5 الأخيرة، إذ لا بد أيضاً من مراعاة ما قد يؤثر على الإنتاجية في السبرنت القادم من إجازات مجدولة وعطلات رسمية وديون تقنية متراكمة وتبعيات خارجية.

جلسات التخطيط

يمر تخطيط السبرنت بمرحلتين: الأولى يتقرر فيها ما سيُسلَّم خلال السبرنت، والثانية يتقرر فيها كيف سيُنفذ العمل الذي وقع عليه الاختيار. ولكل مرحلة مدخلاتها ومخرجاتها الخاصة، والخلط بينهما يُضعف الاثنتين معاً.

1. يحدد الفريق، مع Product Owner، هدف السبرنت الذي تلتقي عنده جميع قصص المستخدم المختارة، ويجب أن يكون الهدف محدداً وقابلاً للقياس وذا معنى لكل المشاركين. هدف ضعيف: "تحسين تجربة المستخدم." هدف جيد: "سيتمكن المستخدمون من التسجيل عبر وسائل التواصل الاجتماعي بنقرة واحدة."
2. يقوم فريق التطوير بتقسيم القصص المختارة إلى مهام وتقدير كل منها بالساعات، وهنا تظهر التعقيدات والتبعيات الخفية التي لا تُرى على مستوى القصة. ويجب ألا تزيد مدة أي مهمة على 8 ساعات، وما يتجاوز هذا الحد يُقسم إلى مهام فرعية.

الأدوار والمسؤوليات

يتوقف نجاح تخطيط السبرنت على أن يعرف كل مشارك دوره بدقة وأن يعمل في حدوده.

• Scrum Master يدير العملية ويحرص على الالتزام بالإطار الزمني ويساعد الفريق على الوصول إلى قراراته، فهو لا يفرض الحلول، وإنما يطرح الأسئلة الصحيحة ويُبقي النقاش مثمراً.
• Product Owner مسؤول عن ترتيب أولويات backlog وعن تحديد الميزات التي تُنفذ أولاً، وعليه أن يكون مستعداً لشرح القيمة التجارية لكل قصة والإجابة عن أسئلة فريق التطوير بتفصيل يكفي لإجراء التقدير.
• فريق التطوير يلتزم بتسليم النتائج، ويجب أن ينبع هذا الالتزام من الفريق نفسه لا أن يُفرض عليه من الخارج، لأن الالتزام الذي يقطعه الفريق على نفسه يولّد من الحماس والشعور بالمسؤولية ما لا تولّده الأهداف المفروضة.

الأخطاء الشائعة

• المبالغة في تقدير قدرات الفريق هي أكثر أخطاء تخطيط السبرنت شيوعاً. فالفرق تأخذ على عاتقها في أحيان كثيرة عملاً أكبر مما تستطيع إنجازه، ولا سيما في بداية المشروع أو بعد سبرنت ناجح. والمبدأ هنا أن الالتزام بالقليل وتسليم الكثير خير من العكس، لأن الالتزامات التي لا يُوفى بها تهز ثقة أصحاب المصلحة وتُضعف حماس الفريق في السبرنتات التالية.
• غياب الوقت الاحتياطي خطأ هيكلي خطير. ينبغي أن تتضمن خطة السبرنت 10-20% من الوقت احتياطاً للمهام غير المتوقعة والأخطاء وطلبات الدعم التقني، ولا يُملأ هذا الاحتياطي مسبقاً بقصص إضافية، فوظيفته استيعاب العمل غير المخطط له الذي لا يخلو منه أي سبرنت.
• تجاهل التبعيات يخلق عوائق في منتصف السبرنت. لذلك يجب أن تُحدد جميع التبعيات الخارجية وتُحل أثناء التخطيط، وإذا كانت المهمة تعتمد على فريق آخر أو مورد خارجي فلا بد من الاتفاق على المواعيد مسبقاً والحصول على التأكيدات قبل بدء السبرنت.

مراقبة العملية

في ممارسة Agile الناضجة تخضع عملية التخطيط نفسها للتحسين المستمر، ولهذا يتناول الفريق في الاجتماعات الاسترجاعية نتائج تنفيذ السبرنت ويتناول معها جودة التخطيط بوصفها عاملاً مستقلاً يستحق التحليل.

المقاييس للتحليل:

• دقة التقدير — مقارنة الوقت المخطط بالوقت الفعلي لكل قصة ومهمة
• نسبة القصص المكتملة — نسبة ما سُلم بنهاية السبرنت من القصص التي التزم بها الفريق
• عدد التغييرات في السبرنت بعد التخطيط — مؤشر على ثبات الخطة ووضوح المتطلبات
• الوقت المستغرق في التخطيط — يُقارن بالوقت المعتاد لاكتشاف الإفراط أو التقصير المزمن

تتابع رسوم Burndown البيانية التقدم طوال السبرنت وتكشف المشاكل في وقت مبكر يسمح بتداركها، فإذا أظهر الرسم أن الفريق لن يُكمل العمل المخطط له وجب التدخل، إما بإعادة ترتيب أولويات المهام المتبقية أو بإخراج قصص المستخدم الأدنى أولوية من نطاق السبرنت.

تكييف التخطيط

• تحتاج الفرق العاملة عن بُعد إلى تكييف خاص لتخطيط السبرنت. فلا بد من توفير أدوات تعاون مناسبة، ومن الحرص على أن يحظى كل المشاركين عن بُعد بفرصة متساوية في النقاش. وقد ثبت مراراً أن توزيع التخطيط على عدة جلسات قصيرة بدلاً من اجتماع واحد طويل يرفع مستوى المشاركة وجودة النتائج لدى الفرق الموزعة.
• تتطلب البرامج الكبيرة التي تضم عدة فرق تنسيقاً على مستوى البرنامج. ويوفر Scrum of Scrums أو SAFe (Scaled Agile Framework) آليات واضحة لمواءمة تخطيط السبرنت بين الفرق التي تجمعها تبعيات مشتركة.
• مشاريع الصيانة التي يذهب فيها جزء كبير من وقت السبرنت إلى الدعم وإصلاح الأخطاء تحتاج إلى حجز صريح من القدرة للعمل غير المخطط له. والمعتاد أن يُخصص 30-50% من قدرة السبرنت لأعمال الدعم ويُترك الباقي لتطوير الميزات الجديدة، وبذلك يتجنب الفريق إخفاقات التسليم التي تقع حين يُعامل الدعم كعبء جانبي خارج الخطة.

مقالات ذات صلة:

لأطر إدارة المشاريع وموازنة القيود، اقرأ مثلث إدارة المشاريع: موازنة النطاق والوقت والتكلفة.

للاطلاع على نظرة عملية إلى لوحات Kanban وإدارة سير العمل المرئي، اقرأ ما هي لوحة Kanban؟ دليل لإدارة سير العمل المرئي.

ولمعرفة كيف تستعين فرق Agile بالشخصيات لتبقى على صلة باحتياجات المستخدمين الحقيقيين، اقرأ شخصيات Agile: تعزيز التطوير المتمحور حول المستخدم في مشاريع Agile. اقرأ المزيد: لوحة كانبان.

الخلاصة

يحتاج تخطيط السبرنت الناجح إلى نهج منهجي وتحسين مستمر يمارسه الفريق عن وعي طوال المشروع لا بعد انتهائه، والاجتماعات الاسترجاعية هي الأداة المناسبة لذلك، إذ يراجع فيها الفريق نتائج السبرنت ومعها قرارات التخطيط التي أدت إليها، فتخضع عملية التخطيط نفسها للتحسين التدريجي ذاته الذي يطبقه Agile على تطوير المنتج.