تمرین استفاده از نمودارهای Burn Down در بستر SAFe و Scrum

در این مقاله قصد دارم توضیح دهم که در تجربه خودمان چگونه از نمودار سوزش (Burn Down Chart) در فرایند کار بر اساس متدولوژی SAFe استفاده می‌کنیم

بهتر است از جالب‌ترین بخش شروع کنم. یعنی از این نکته که استفاده از این نمودار در SAFe نباید هیچ ویژگی خاصی نسبت به استفاده از این نمودار در SCRUM داشته باشد. یا باید داشته باشد؟

SAFe ما با داشتن نقشی به نام RTEمتفاوت است، برخلاف SCRUM که چنین نقشی ندارد. Burn Down Chart ابزاری برای پیگیری حجم کار در اسپرینت است و پیش از هر چیز برای تیم SCRUM ضروری است، نه برای کسی از بیرون، مگر نه؟

بنابراین، با وجود همه این‌ها و در حالی که همچنان درون چارچوب SAFe هستم، به این می‌پردازم که چگونه از Burn Down Chart استفاده می‌کنیم.

من در نقش Scrum Master هستم و تلاش می‌کنم این نمودار را روزانه برای تمام Dev Teamنمایش دهم. ابزاری که استفاده می‌کنم چت تیمی است، منشن کردن کل تیم با "@"، و اسکرین‌شات وضعیت فعلی نمودار. منشن کردن کل تیم ابزار بسیار ظریفی است و مهم است که آن را تا حد امکان کمتر استفاده کنیم (چون ما، اسکرام مسترها، باید به تیم کمک کنیم در آسایش و با کمترین حواس‌پرتی ممکن کار کند، مگر نه؟)

در نتیجه تیم روزانه وضعیت فعلی اسپرینت را می‌بیند و می‌تواند رویدادهای زیر را پیگیری کند

• ظهور کار برنامه‌ریزی‌نشده
• ماندن طولانی وظایف در وضعیت ناتمام
• وارد کردن بیش از حد ریسک‌ها
• درک این که کار با سرعت درست پیش می‌رود

در ادامه تلاش می‌کنم هر یک از این رویدادها را باز کنم و مثال‌هایی از تجربه خودم بیاورم.

ظهور کار برنامه‌ریزی‌نشده

در این نمودار خیلی خوب دیده می‌شود که چگونه کار جدید ظاهر می‌شود (در سه‌شنبه دوم اسپرینت دو هفته‌ای).

موردی از تجربه: «توسعه‌دهنده، به عنوان عضو تیم scrum که اصول agile را می‌پذیرد، به‌خوبی مستقیماً با Product تعامل می‌کند. Product به او می‌گوید که این را باید سریع بسازیم، خودت هم می‌دانی، اینجا سریع است و ریسک‌ها حداقلی است.

توسعه‌دهنده خوب است، همه چیز را درباره agile و اهمیت تحویل ارزش تجاری می‌داند، می‌رود و یک استوری از بک‌لاگ را روی برد می‌اندازد، تیم آن را ۶ sp تخمین زده است.

بقیه تیم (به جز توسعه‌دهنده و Product) این را در به‌روزرسانی صبحگاهی نمودار متوجه می‌شوند. در استنداپ تیم تصمیم می‌گیرد با این وضعیت چه کند. به احتمال زیاد، استوری از اسپرینت بیرون انداخته می‌شود، تیم به Product و توسعه‌دهنده می‌فهماند که این کار درست نیست، و Product می‌تواند در صورت نیاز این استوری را در اسپرینت بعدی قرار دهد.

البته در حالت ایده‌آل تیم باید ظهور کار جدید را در استنداپ و بدون نمودار هم متوجه شود. اما نمودار نشانگر خوبی است که ریسک متوجه نشدن چنین تغییر مهمی برای کل تیم را به حداقل می‌رساند.

در اینجا مهم است درک کنیم که سناریو بسته به سطح بلوغ تیم می‌توانست متفاوت پیش برود. در تیم‌های قوی، مالک محصول به‌سختی چنین کاری می‌کرد، و اگر هم می‌کرد، دلیلش را نه با این که «این را می‌توان سریع ساخت»، بلکه با این که «من احتمال ۵۵٪ می‌دهم که اگر این را الان بسازیم، ممکن است ماه آینده سود ما را ۲۰٪ افزایش دهد» یا معیار قابل اندازه‌گیری دیگری توجیه می‌کرد.

ماندن طولانی وظایف در وضعیت ناتمام

در اینجا می‌بینیم که کار برای مدت بسیار طولانی حتی به‌طور جزئی هم کامل نمی‌شود. این می‌تواند نشانهٔ مشکلات مختلفی باشد، برخی از آن‌ها را برمی‌شمارم

• تجزیهٔ ضعیف وظایف

  اغلب تیم‌های تازه‌کار از عدم امکان تجزیه سخن می‌گویند. همه‌چیز آن‌ها در روز آخر می‌سوزد، کار موازی نمی‌شود و غیره. البته اسکرام مستر باید روی این کار کند و ارزش تجزیه را به تیم توضیح دهد.

• DOD نامناسب فرمول‌بندی‌شده

  DOD (Definition of Done) - توصیف معیارهای آمادگی User Story در اسپرینت. گاهی اصلاً وجود ندارند یا بسیار انتزاعی توصیف شده‌اند. این کاملاً می‌تواند مشکل باشد که طبیعتاً اسکرام مستر باید به حل آن کمک کند

بیش‌ازحد در نظر گرفتن ریسک‌ها

در این حالت وضعیتی را می‌بینیم که تیم ریسک‌ها را بیش از حد در نظر گرفته است.

احتمالاً برخی استوری‌ها بیش از حد برآورد شده‌اند. احتمالاً این مشکلی سیستمیک‌تر است و لازم است حجم کار در برنامه‌ریزی اسپرینت افزایش یابد. در هر صورت، این وضعیت درست نیست. چون کسب‌وکار برنامه‌ریزی کرده بود که دقیقاً وظایف اسپرینت و دقیقاً تا پایان اسپرینت محقق شوند. بسته به نحوهٔ برنامه‌ریزی وابستگی‌ها، اینجا به احتمال زیاد باید جلساتی برای اصلاح انتظارات برگزار شود.

در تجربهٔ من این‌گونه بود که راه‌حلی سریع‌تر از آنچه در برآورد بحث شده بود پیدا شد. با تمام تیم بحث کردیم که کدام استوری را می‌توانیم تا پایان اسپرینت ببندیم و در رتروسپکتیو توافق کردیم که تلاش کنیم هنگام گرومینگ کد را ببینیم. مشخص شد که کافی بود فقط نگاهی به کد بیندازیم تا بفهمیم راه‌حل بسیار ساده‌تر است.

درک - آیا کار با سرعت درست پیش می‌رود

در اینجا می‌خواهم به روش‌های گرافیکی ناموفق نمایش Burn Down Chart توجه کنم

در بالای تصویر نمونه‌ای از پیاده‌سازی گرافیکی نه‌چندان موفق به دو دلیل که در ادامه می‌گویم آورده شده است.

• افزودن SPهای جدید به اسپرینت دیده نمی‌شود

  در اینجا، در نمودار بالا، تقریباً دیده نمی‌شود که کار برنامه‌ریزی‌نشده‌ای اضافه شده است. در نمودار پایین این واضح‌تر است.

• باقی‌ماندهٔ نسبی کار به‌درستی نمایش داده نمی‌شود

  بر اساس نمودار بالا هنوز ۳ روز کار باقی است. در واقعیت ۲ روز است، در روز تعطیل، احتمالاً کسی قصد استراحت دارد.

البته ممکن است چنین جزئیاتی برای برخی ناچیز به نظر برسد. اما باید درک کرد که هر عضو تیم فقط گوشهٔ چشمی به این نمودار می‌اندازد و باید حداکثر اطلاعات مفید را منتقل کند.