تمرین تیم‌سازی در چارچوب Scrum

هنوز از Velocity استفاده می‌کنید؟ دوباره آن را مفید کنید

پژوهش‌ها نشان می‌دهد تخمین‌زنی گروهی نسبت به تخمین‌زنی فردی دقیق‌تر است. البته این دقت زمانی به‌دست می‌آید که گروه تنوع و استقلال داشته باشد و اقتدار/قدرت تصمیم‌گیری درون گروه متمرکز نباشد (غیرمتمرکز باشد). بهترین تصمیم‌ها زمانی شکل می‌گیرند که تعارضِ سازنده و ثمربخش وجود داشته باشد؛ یعنی همه‌ی دیدگاه‌ها شنیده شوند و گروه بتواند به اجماع برسد.¹⁰

۱۰. حکمت جمع (Wisdom of Crowds)، نوشته‌ی جیمز سوروویِکی (Anchor، ۲۰۰۵).

هنوز از Velocity استفاده می‌کنید؟ دوباره آن را مفید کنید

در پست قبلی، بررسی کردیم که Velocity اغلب چگونه به‌اشتباه تفسیر می‌شود.

  • میانگین‌ها تبدیل به تعهد می‌شوند
  • استوری‌پوینت‌ها به ددلاین تبدیل می‌شوند
  • و هدف واقعی تخمین‌زدن را از دست می‌دهیم؛ هدفی که چیزی نیست جز کمک به شکل‌گیری گفت‌وگوهای بهتر

اگر آن مطلب را از دست داده‌اید، از اینجا شروع کنید:
Velocity؛ آن چیزی نیست که فکر می‌کنید

این مطلب بر پایه‌ مقاله آغازین ما نوشته شده بود:
تخمین در اجایل خراب نیست؛ اما شاید طرز فکرمان خراب باشد

حالا که این زیربنا را ساخته‌ایم، سراغ تیم‌ها می‌رویم؛ دقیقاً همان‌جایی که هستند، و کمکشان می‌کنیم از همان‌جا رشد کنند.

بسیاری از تیم‌ها هنوز Velocity را دنبال می‌کنند و همچنان از Release Burndown استفاده می‌کنند.

آیا این‌ها ابزارهای عالی هستند؟ نه، راه‌های بهتری هم وجود دارد.
اما آشنایی، برای ما یک نقطه ورود می‌سازد.

تغییر گفت‌وگو

به‌جای تکیه بر یک عدد میانگین، از دانسته‌هایمان درباره‌ی عدم‌قطعیت استفاده می‌کنیم:

  • بهترین حالت
  • حالت معمول
  • بدترین حالت

در این نقطه، Velocity تبدیل به پیش‌بینی می‌شود، نه یک برنامه‌ی ثابت.

و به‌جای این‌که بپرسیم «آیا به تاریخ موردنظر می‌رسیم؟»، سؤال‌ها تغییر می‌کنند به:

  • چه چیزهایی را با اطمینان انجام خواهیم داد؟
  • چه چیزهایی در معرض ریسک هستند؟
  • حاضر به چه بده‌بستان‌هایی هستیم؟

موضوع، بی‌نقص‌بودن نیست.
موضوع، ایجاد شفافیت و همکاری بیشتر است؛
تا بتوانیم گفت‌وگوهای بهتری درباره‌ی انتظارات، ارزش و ریسک داشته باشیم.

کار را قابل مشاهده کنید

اغلب می‌بینیم تیم‌ها از Release Burndown استفاده می‌کنند.
اما به‌جای برخورد با آن به‌عنوان یک برنامه‌ی قطعی یا گزارش وضعیت، آن را با Cone of Uncertainty ترکیب می‌کنیم.

Release Burndown همراه با مخروط عدم‌قطعیت

همین تغییر کوچک، گفت‌وگو را جابه‌جا می‌کند:

  • اگر روند در ناحیه قرمز باشد، یعنی چه چیزهایی در معرض ریسک بالایی هستند
  • اگر داخل مخروط باشیم، یعنی (در صورت نبود تغییرات اساسی) سطح اطمینان بالاتری داریم

اینجا بحث قطعیت نیست؛
بحث مرئی‌کردن ریسک، تنظیم انتظارات و ممکن‌کردن همکاری است.

در این حالت، Burndown تبدیل می‌شود به یک گفت‌وگو درباره‌ی انتظارات، ارزش و بده‌بستان‌ها—
نه فقط سرعت تحویل.

از آنچه همین حالا دارید استفاده کنید

اگر تیم شما مدتی است از Velocity استفاده می‌کند، شما همین حالا داده‌ تاریخی دارید.
می‌توانید با طرح این سؤال‌ها، استفاده‌ بهتری از آن داده‌ها بکنید:

  • کمترین Velocity اسپرینت ما چقدر بوده؟
  • بازه‌ معمول ما چه‌قدر است؟
  • بیشترین Velocity چقدر بوده؟

این روش بی‌نقص نیست؛
اما نقطه‌ شروعی فراهم می‌کند برای پیش‌بینی با بازه‌ها به‌جای اعداد ثابت.

از Velocity به Flow

این رویکرد کمک می‌کند گفت‌وگو از «میزان تلاش» فاصله بگیرد و به سمت عدم‌قطعیت و ارزش حرکت کند.

وقتی این تغییر اتفاق افتاد، می‌توانیم یک قدم جلوتر برویم.
می‌توانیم به تیم‌ها کمک کنیم فراتر از Velocity بروند و روش‌های بهتری برای پیش‌بینی را با استفاده از داده‌های واقعی تحویل—مثل Throughput و Flow—کشف کنند.

ما می‌دانیم مقصد کجاست.
اما تغییر، یک‌شبه اتفاق نمی‌افتد.

گاهی فقط چند تلنگر به‌موقع و کمی تغییر ذهنیت کافی است.

در ادامه…

شاید استوری‌پوینت‌ها و Velocity از ابتدا هم بهترین راه پیش‌بینی نبوده‌اند.
در پست بعدی، یک آزمایش ساده را معرفی می‌کنیم تا به تیم‌ها کمک کند تخمین‌زدن را دوباره بازاندیشی کنند و جلوتر بروند.


منتورینگ رایگان مالکین محصول

«اگر در یک شرکت نرم‌افزاری مشغول به کارهای روزانه یک PO هستید و دوست دارید در مورد پیاده‌سازی اجایل، اسکرام و چالش‌های نقش PO در چهارچوب اسکرام یا تفکر استراتژیک در محصول، راهنمایی و مشاوره بگیرید، در خدمتتون هستم. یک وقت در adplist بگیرید.»


دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: اجازه کپی محتوا وجود ندارد