إنتوا بتعملوا Estimation إزاي؟ الـ Sizing بالـ Story Points
ساعات ولا Story Points؟ الـ Sizing النسبي بيشتغل إزاي، ومقياس Fibonacci بسيط، والـ Planning Poker في ٥ دقايق، وأخطاء بتبوّظ الـ Estimate. وإنتوا بتعملوها إزاي؟
ليه الـ Estimation بيبوظ؟
اسأل Developer "التاسك دي هتاخد قد إيه؟" هيقولك رقم بالساعات أو بالأيام. اسأله تاني بعد أسبوع هتلاقي الرقم اتغيّر. محدش كدب. الشغل كان فيه حاجات محدش شافها لسه.
أغلب مشاكل الـ Estimation جاية من هنا. الفريق بيتطلب منه وقت دقيق قبل ما يفهم الشغل، وبعدين الرقم ده بيتحوّل لوعد.
ساعات ولا Story Points؟
فيه طريقتين منتشرين للـ Estimation في فرق البرمجيات.
الـ Estimation بالوقت (ساعات أو أيام) سهل يتفهم، وسهل تعمل بيه Plan على الكالندر. بس بيقع لما الشغل يكون جديد، لأن الناس مش شاطرة في توقّع وقت حاجة ما عملوهاش قبل كده.
الـ Story Points نسبية. إنت مش بتقول "دي هتاخد ٦ ساعات". إنت بتقول "دي تقريبًا ضعف الـ Story اللي خلّصناها قبل كده". الـ Point بتجمع ٣ حاجات في رقم واحد: المجهود، والـ Complexity، ودرجة عدم الوضوح.
الـ Scrum Guide مش بيفرض أي واحدة فيهم. هو بيقول إن الـ Developers اللي هيعملوا الشغل هما المسؤولين عن الـ Sizing بتاعه. الـ Points والساعات والـ T-shirt sizes كلها اختيارات الفريق بياخدها.
الـ Sizing بالـ Story Points بيمشي إزاي؟
- اختار Story مرجعية. خُد Story صغيرة الفريق كله فاهمها كويس، واديها 2 أو 3. أي Story جديدة بتتقارن بيها.
- استخدم مقياس فيه فراغات. أغلب الفرق بتستخدم Fibonacci معدّل: 1، 2، 3، 5، 8، 13، 20. الفراغات بتكبر لأن الشغل الكبير أصعب في الـ Estimation الدقيق. محدش يقدر يفرّق بين 14 و 15.
- اعملوا الـ Estimation مع بعض. اللي هيعملوا الشغل هما اللي يعملوا الـ Estimation بتاعه، ومعاهم الـ QA. الـ Senior Developer لوحده هيحسب الكود وينسى الـ Testing.
- قسّم أي حاجة كبيرة. لو Story وصلت 13 أو أكتر، يبقى الفريق مش فاهمها كفاية. قسّمها لـ Stories أصغر قبل ما تدخل الـ Sprint.
الـ Planning Poker في ٥ دقايق
الـ Planning Poker أول واحد وصفه James Grenning سنة 2002، وبعدين انتشر على إيد Mike Cohn في كتاب Agile Estimating and Planning. ودي أشهر طريقة الفرق بتحط بيها الـ Points.
- الـ Product Owner بيقرا الـ Story ويجاوب على الأسئلة.
- كل واحد بيختار كارت لوحده من غير ما حد يشوف.
- الكروت كلها بتتقلب في نفس اللحظة.
- أعلى واحد وأقل واحد في الأرقام بيشرحوا وجهة نظرهم.
- الفريق بيصوّت تاني، غالبًا مرة أو مرتين، لحد ما الأرقام تقرّب من بعض.
إن الكروت تتقلب في نفس اللحظة دي نقطة مهمة. لو الـ Tech Lead اتكلم الأول، الباقيين هيمشوا ورا رقمه.
النقاش بين أعلى رقم وأقل رقم هو أهم جزء. اللي بيصوّت 8 والباقيين 3 غالبًا عارف حاجة عن Module قديم، أو API ناقص، أو مشكلة في بيئة الـ Testing.
أخطاء بتبوّظ الـ Story Points
- تحويل الـ Points لساعات. أول ما "1 Point = 4 ساعات" تبقى قاعدة، رجعت للـ Estimation بالوقت بس بخطوات زيادة.
- مقارنة الفرق بالـ Velocity. الـ Points نسبية للـ Story المرجعية بتاعة كل فريق. الـ 40 بتوع فريق والـ 25 بتوع فريق تاني مينفعش يتقارنوا.
- استخدام الـ Velocity كـ Target للأداء. لو الناس بتتقيّم بالـ Points، الـ Points هتنفخ. والرقم هيبطّل يعني أي حاجة.
- إعادة الـ Estimation بعد ما الشغل يخلص. الـ Estimate كان أحسن توقّع للفريق وقتها. سيبه زي ما هو، واتعلّموا من الفرق في الـ Retrospective.
LazyScrum فين من ده؟
LazyScrum بيعمل الـ Estimation جوه Sprint Planning لايف فوق داتا Jira بتاعتك. الفريق بيعمل الـ Estimation مع بعض في نفس الـ Session، وأعضاء الفريق بيدخلوا الـ Planning مجانًا، وبتشوف الـ Capacity والـ Timeline وإنت بتعمل الـ Estimation، عشان الـ Sprint اللي بتلتزم بيه يبقى الفريق قادر يخلّصه فعلًا.
LazyScrum فيه Free trial لمدة ٧ أيام. جرّبه من هنا.
ودلوقتي عايزين نسمع منك
إنتوا بتعملوا Estimation إزاي في فريقكم؟ Story Points، ولا ساعات، ولا T-shirt sizes، ولا من غير Estimation خالص؟ مين بيحضر الـ Session، وكل قد إيه الـ Estimate بيطلع قريب من الحقيقة؟
ابعت البوست ده لفريقك واسألهم نفس السؤال. الإجابات غالبًا هتفاجئك.
