به عنوان یک Agile Delivery Manager یا اسکرام مستر یا مدیر پروژه، شما با یک سؤال همیشگی و کلیدی سر و کار دارید: « این کار یا پروژه کِی تمام می‌شود؟»

اولین چیزی که معمولا به ذهن همه ما میرسد این است که: حجم کار باقی مانده در بک لاگ محصول را بر میانگین velocity تقسیم کنیم و یک تاریخ قطعی ارائه می‌دهیم. مثلا: «بر اساس میانگین ۲۰ story point در هر اسپرینت، این پروژه ۱۰۰ پوینتی در ۵ اسپرینت تمام می‌شود.» و درست در همین لحظه، واقعیت از راه می‌رسد. یک برنامه نویس کلیدی بیمار می‌شود. یک باگ غیرمنتظره خودش را نشان می‌دهد. یکی از نیازمندی‌ها پیچیده‌تر از چیزی بود که فکر می‌کردیم. ناگهان، پیش‌بینی «۵ اسپرینتی» ما، بیشتر شبیه یک حدس خوش‌بینانه به نظر می‌رسد تا یک تخمین مبتنی بر داده که حالا باید پاسخگوی آن نیز باشیم.

مشکل اینجاست که تخمین تک‌نقطه‌ای (single-point estimate) اکثرا به ما دروغ می‌گویند. این نوع تخمین زدن، مهم‌ترین واقعیت کار ما را نادیده می‌گیرد: تغییرپذیری (variability).

اما اگر راه بهتری وجود داشته باشد چه؟ راهی برای داشتن یک گفتگوی صادقانه و مبتنی بر داده درباره آینده که عدم قطعیت را به جای نادیده گرفتن، در آغوش می‌کشد؟ به این روش اصطلاحا Probabilistic Forecasting گفته می شود و موتور محرک آن، تکنیکی به نام شبیه سازی مونت کارلو است.

Monte Carlo Simulation یا شبیه سازی مونت کارلو چیست؟ تصور کنید توانایی تیم شما در انجام کارها، مانند یک تاس خاص و چندوجهی است. روی هر وجه این تاس، به جای اعداد ۱ تا ۶، عددی نوشته شده که نشان‌دهنده حجم کاری است که تیم شما واقعاً در یکی از اسپرینت های گذشته انجام داده است. عملکرد واقعی و تاریخی شما – با تمام روزهای خوب، بد و معمولی- در این تاس گنجانده شده است.

بیایید این موضوع را با یک مثال عملی بررسی کنیم.

سناریو: «پروژه ققنوس»

• هدف: ما باید «پروژه ققنوس» را که ۸۵ استوری پوینت کار باقیمانده دارد را تحویل دهیم.
• سؤال: «چند اسپرینت طول می‌کشد تا پروژه تمام شود؟»
• داده‌های ما: ما به عملکرد تیم در ۱۰ sprint گذشته نگاه می‌کنیم. این تاریخچه ماست:
  • تعداد استوری پوینتهایی که تیم ما در هر اسپرینت تکمیل کرده، به این صورت بوده است: { 18, 25, 15, 21, 23, 12, 19, 28, 17, 20 }

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

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

مرحله ۱: اجرای یک شبیه‌سازی (یک بار انداختن تاس)

ما قصد داریم یک آینده احتمالی را برای پروژه ققنوس شبیه‌سازی کنیم. برای این کار، در هر اسپرینت «تاس می‌اندازیم» (یعنی به صورت تصادفی یک عدد از مجموعه داده‌هایمان انتخاب می‌کنیم) و آن را از کل کار باقیمانده کم می‌کنیم.

• Sprint 1: تاس را می‌اندازیم و عدد ۲۱ می‌آید.
  • کار باقیمانده: ۸۵ – ۲۱ = ۶۴ پوینت.
• Sprint 2: دوباره تاس می‌اندازیم و ۱۵ می‌آید. (یک اسپرینت کندتر)
  • کار باقیمانده: ۶۴ – ۱۵ = ۴۹ پوینت.
• Sprint 3: دوباره می‌اندازیم و ۲۸ می‌آید. (یک اسپرینت فوق‌العاده!)
  • کار باقیمانده: ۴۹ – ۲۸ = ۲۱ پوینت.
• Sprint 4: دوباره می‌اندازیم و ۱۹ می‌آید.
  • کار باقیمانده: ۲۱ – ۱۹ = ۲ پوینت
• Sprint 5: دوباره تاس می‌اندازیم. هر عددی که بیاید کار را تمام می‌کند.
  • کار باقیمانده: ۰.
• در این یک واقعیت شبیه‌سازی‌شده، پروژه ۵ اسپرینت طول کشید.

اما اگر یک دور بدشانسی می‌آوردیم چه؟ یا یک دوره خوش‌شانسی مطلق؟ آن یک نتیجه به تنهایی کافی نیست تا سرنوشت پروژه را به آن گره بزنیم.

مرحله ۲: تکرار این بازی برای ۱۰,۰۰۰ بار

اینجاست که کامپیوتر کار سنگین را برای ما انجام می‌دهد. یک شبیه ساز مونت کارلو این بازی ساده را بارها و بارها تکرار می‌کند:۱۰,۰۰۰ بار، ۵۰,۰۰۰ بار یا حتی بیشتر. هر بار، به صورت تصادفی از داده‌های تاریخی شما نمونه‌برداری می‌کند و ثبت می‌کند که چند اسپرینت طول کشید تا ۸۵ پوینت تکمیل شود.

پس از اجرای هزاران شبیه‌سازی، ما به مجموعه‌ای غنی از نتایج احتمالی دست پیدا می‌کنیم.

مرحله ۳: تحلیل هزاران نتیجه

کامپیوتر حالا لیستی از ۱۰,۰۰۰ پاسخ مختلف را به ما می‌دهد. این لیست ممکن است چیزی شبیه به این باشد:

• پروژه در ۳ اسپرینت تمام شد: ۵۰۰ بار
• پروژه در ۴ اسپرینت تمام شد: ۲,۵۰۰ بار
• پروژه در ۵ اسپرینت تمام شد: ۴,۵۰۰ بار
• پروژه در ۶ اسپرینت تمام شد: ۱,۸۰۰ بار
• پروژه در ۷ اسپرینت تمام شد: ۷۰۰ بار

از نظر بصری، این نتایج اغلب شبیه به یک هیستوگرام نمایش داده می‌شوند، که در آن بلندترین ستون، محتمل‌ترین نتیجه را نشان می‌دهد.

این نمودار به تنهایی بسیار مفیدتر از یک عدد است! ما می‌توانیم ببینیم که اتمام پروژه در ۵ محتمل‌ترین حالت است، اما ۴ و ۶ sprint هم کاملاً امکان‌پذیر هستند.

مرحله ۴: تبدیل نتایج به احتمالات

در این مرحله ما این شمارش‌ها را به احتمالات تبدیل می‌کنیم. از داده‌ها می‌پرسیم: «چند درصد از شبیه‌سازی‌ها در X اسپرینت یا کمتر به پایان رسیدند؟»

• اتمام در ۳ اسپرینت یا کمتر: ۵۰۰ / ۱۰,۰۰۰ = ۵٪ شانس
• اتمام در ۴ اسپرینت یا کمتر: (۵۰۰ + ۲,۵۰۰) / ۱۰,۰۰۰ = ۳۰٪ شانس
• اتمام در ۵ اسپرینت یا کمتر: (۳,۰۰۰ + ۴,۵۰۰) / ۱۰,۰۰۰ = ۷۵٪ شانس
• اتمام در ۶ اسپرینت یا کمتر:(۷,۵۰۰ + ۱,۸۰۰) / ۱۰,۰۰۰ = ۹۳٪ شانس
• اتمام در ۷ اسپرینت یا کمتر:(۹,۳۰۰ + ۷۰۰) / ۱۰,۰۰۰ = ۱۰۰٪ شانس

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

گفتگوی جدیدی که می‌توانید آغاز کنید

به جای ارائه یک تاریخ قطعی و شکننده، که باعث ایجاد انتظارات غیر واقعی بشود، می‌توانید با اطمینان وارد جلسه با ذی‌نفعان شوید و بگویید:

• «ما عملکرد واقعی تیم را در ۱۰ اسپرینت گذشته تحلیل و هزاران شبیه‌سازی را اجرا کردیم. بر اساس این داده‌ها:
  • ما با اطمینان ۷۵٪ می‌توانیم بگوییم پروژه ققنوس در ۵ اسپرینت یا کمتر به پایان می‌رسد.
• اگر بخواهیم یک ذره محتاطانه عمل کنیم (مثلا به مشتری بیرونی میخواهیم یک زمان بدهیم)، با اطمینان ۹۳٪ پروژه در ۶ اسپرینت یا کمتر تمام خواهد شد.»
• نکته کلیدی: معمولا سطح اطمینان بالا (مثلا ۹۰ درصد) زمانی استفاده می شود که با دینفعان بیرونی تعامل دارید و بهتر هست زمانی که ارایه میدهید محتاطانه باشد چرا که هزینه ناامید کردن آنها معمولا زیاد است.

این رویکرد، بازی را کاملاً تغییر می‌دهد. چرا؟

۱. صادقانه و شفاف است: شما به صراحت در حال بیان عدم قطعیت هستید. تغییرپذیری و عدم قطعیت را پنهان نمی‌کنید، بلکه آن را به محور اصلی گفتگو تبدیل می‌کنید. این کار، اعتماد فوق‌العاده‌ای ایجاد می‌کند.

۲. قابل دفاع است: وقتی کسی پیش‌بینی شما را به چالش می‌کشد، می‌توانید بگویید: «این نظر شخصی من نیست. این یک پیش‌بینی آماری بر اساس عملکرد اثبات‌شده تیم ماست.»

۳. تصمیم‌گیری بهتر را ممکن می‌سازد: بحث از «آیا این تاریخ درست است یا غلط؟» به «ما با چه سطحی از ریسک راحت هستیم؟» تغییر می‌کند. اگر شانس ۷۵٪ برای یک ددلاین مهم کافی نیست، کسب‌وکار می‌تواند یک گفتگوی معنادار درباره کاهش دامنه کار یا تخصیص منابع بیشتر برای افزایش قطعیت داشته باشد.

۴. انجام آن به طرز شگفت‌آوری ساده است: نیازی به داشتن دکترای آمار ندارید. بسیاری از ابزارهای Agile (پلاگین‌های Jira، ActionableAgile، Kanbanize) این قابلیت را به صورت داخلی دارند. حتی می‌توانید یک نسخه ساده از آن را در یک اکسل بسازید.

بخش دوم: اما اگر تیم ما از Story Point استفاده نکند چه؟

مثال «پروژه ققنوس» که با استوری پوینت بررسی کردیم، بسیار قدرتمند بود. اما یک سؤال مهم پیش می‌آید: «تیم ما با Story Point کار نمی‌کند، یا تخمین‌های ما چندان دقیق نیست. آیا ما نمی‌توانیم از این روش استفاده کنیم؟»

خبر خوب این است که شما مطلقاً به Story Point نیاز ندارید. قدرت شبیه سازی مونت کارلو در واحد اندازه‌گیری شما نیست؛ بلکه در استفاده از داده‌های تاریخی و واقعی شماست. شما می‌توانید به جای تخمین زدن، فقط بشمارید. اینجاست که مفهومی به نام Throughput وارد می‌شود.

Throughput: هنر شمردن کارهای انجام‌شده

Throughput به ساده‌ترین شکل ممکن، یعنی تعداد کارهایی که تیم در یک بازه زمانی مشخص (مثلاً یک هفته یا یک sprint) به پایان می‌رساند.

این کارها می‌توانند User Story، تسک، باگ یا هر آیتم کاری دیگری باشند. شما دیگر نگران این نیستید که یک آیتم “۵ پوینتی” است یا “۸ پوینتی”. فقط می‌پرسید: «آیا تمام شد؟ بله یا خیر.» و در پایان بازه زمانی، تعداد آیتم‌های تمام‌شده را می‌شمارید.

بیایید ببینیم این رویکرد در عمل چگونه کار می‌کند.

سناریو جدید: «پروژه عقاب»

• هدف: ما باید «پروژه عقاب» که شامل ۴۰ آیتم کاری (User Story و تسک) در بک لاگ است را تحویل دهیم.
• سؤال:«چند هفته طول می‌کشد تا این پروژه تمام شود؟»
• داده‌های ما: این بار به جای شمارش استوری پوینت، تعداد آیتم‌هایی که تیم در ۱۰ هفته گذشته تکمیل کرده را بررسی می‌کنیم.
  • Throughput هفتگی تیم ما به این صورت بوده است: `{ 5, 8, 4, 7, 5, 9, 6, 8, 4, 6 }`

این مجموعه اعداد، «تاس» جدید ما برای پیش‌بینی است. هر وجه این تاس، نماینده تعداد کارهایی است که تیم در یک هفته معمولی به پایان رسانده است. همانطور که می‌بینید، یک هفته عالی با ۹ آیتم و هفته‌های کندتر با ۴ آیتم داشته‌ایم.

حالا، دوباره بازی Monte Carlo را اجرا می‌کنیم.

اجرای شبیه‌سازی با Throughput

روند دقیقاً مانند قبل است:

1. یک شبیه‌سازی: کامپیوتر به صورت تصادفی از داده‌های Throughput ما نمونه‌برداری می‌کند. مثلاً هفته اول `۷`، هفته دوم `۴`، هفته سوم `۹` و… این کار را آنقدر ادامه می‌دهد تا مجموع آیتم‌ها به ۴۰ برسد و تعداد هفته‌های مورد نیاز را ثبت می‌کند.
2. هزاران شبیه‌سازی: کامپیوتر این بازی را ۱۰,۰۰۰ بار تکرار می‌کند و نتایج هزاران آینده ممکن را جمع‌آوری می‌کند.
3. تبدیل به احتمالات: در نهایت، نتایج به صورت احتمالات به ما ارائه می‌شود. مثلاً خروجی شبیه‌سازی برای «پروژه عقاب» ممکن است به این شکل باشد:

• اتمام در ۴ هفته یا کمتر: ۱۰٪ شانس
• اتمام در ۵ هفته یا کمتر:۴۵٪ شانس
• اتمام در ۶ هفته یا کمتر:۸۵٪ شانس
• اتمام در ۷ هفته یا کمتر:۹۸٪ شانس

اکنون شما می‌توانید با همان اطمینان به سراغ ذی‌نفعان بروید و بگویید: «بر اساس تعداد آیتم‌هایی که تیم ما به صورت هفتگی تکمیل می‌کند، ما با اطمینان ۸۵٪ می‌توانیم بگوییم که پروژه در۶ هفته یا کمتر به پایان می‌رسد.»

همانطور که می‌بینید، منطق کار هیچ تغییری نکرد. تنها چیزی که عوض شد، واحد اندازه‌گیری ما بود: از تخمین (Story Point) به شمارش (Throughput).

مقایسه دو رویکرد: Story Point در مقابل Throughput

خب، کدام رویکرد بهتر است؟ حقیقت این است که هیچ‌کدام بر دیگری برتری ذاتی ندارند. بهترین انتخاب کاملاً به زمینه کاری، فرهنگ و ماهیت فعالیت‌های تیم شما بستگی دارد. بیایید تفاوت‌های عملی این دو را بررسی کنیم.

رویکرد Story Point حول محور ارزش گفتگو و مدیریت تغییرپذیری می‌چرخد. استوری پوینت واحدی برای سنجش زمان نیست؛ بلکه تخمینی نسبی از تلاش، پیچیدگی و عدم قطعیت است. نقطه قوت اصلی آن در خودِ فرآیند برنامه‌ریزی نهفته است. وقتی یک تیم بحث می‌کند که کاری ۵ پوینتی است یا ۸، اعضا ناچار می‌شوند فرضیات پنهان را آشکار کنند، ریسک‌ها را بشناسند و به درکی مشترک از کار برسند. همین ویژگی، استوری پوینت را برای تیم‌هایی که با کارهایی با اندازه‌های بسیار متنوع سر و کار دارند- از یک اصلاح کوچک ۱ پوینتی گرفته تا یک فیچر بزرگ ۱۳ پوینتی- بسیار مؤثر می‌سازد. با این حال، نقطه ضعف آن، ماهیت ذهنی (subjective) آن است. چیزی که یک نفر ۵ پوینت در نظر می‌گیرد، ممکن است از دید دیگری ۸ پوینت باشد. این ذهنیت می‌تواند به بحث‌های طولانی منجر شود و اگر به درستی استفاده نشود، ممکن است به اشتباه به ساعت ترجمه شده یا به ابزاری برای سنجش عملکرد افراد تبدیل شود که این امر هدف اصلی آن را تضعیف می‌کند.

از سوی دیگر، رویکرد Throughput بر پایه عینیت (objectivity) و سادگی بنا شده است. Throughput شمارشی مستقیم و انکارناپذیر از آیتم‌های تمام‌شده است. یک کار یا تمام شده یا نشده؛ جایی برای بحث وجود ندارد. این رویکرد نیاز به جلسات زمان‌بر تخمین را از بین می‌برد و به تیم اجازه می‌دهد تا بیشتر بر روی توسعه تمرکز کند. این یک سنجه خالص از نرخ تحویل تیم است. با این حال، دقت آن به یک فرض کلیدی وابسته است: اینکه آیتم‌های کاری شما اندازه‌ای تقریباً مشابه داشته باشند. اگر بک لاگ شما ترکیبی از Epic های غول‌پیکر و تسک‌های بسیار کوچک باشد، یک شمارش ساده می‌تواند گمراه‌کننده باشد. هفته‌ای که تیم یک فیچر عظیم را تکمیل می‌کند ممکن است Throughput کمتری نسبت به هفته‌ای داشته باشد که ده تسک کوچک را به پایان می‌رساند، حتی اگر در هفته اول ارزش بیشتری تحویل داده شده باشد. بنابراین، Throughput برای تیم‌های بالغی که در شکستن کارهایشان به قطعات کوچک و هم‌اندازه مهارت دارند، بهترین عملکرد را دارد.

در نهایت، انتخاب بین این دو، انتخاب یک «متریک درست» نیست، بلکه پیدا کردن یک معیار معنادار و باثبات برای تیم شماست. اگر تیم شما از گفتگوهای فنی عمیق که در جلسات تخمین شکل می‌گیرد ارزش کسب می‌کند و با کارهای بسیار متنوعی روبروست، استوری پوینت ابزاری قدرتمند است. اما اگر تیم شما فرآیندی ساده‌تر را ترجیح می‌دهد، در تقسیم کار به قطعات کوچک مهارت دارد و برای یک معیار کاملاً عینی ارزش قائل است، به احتمال زیاد Throughput انتخاب مناسب‌تری خواهد بود.

شما از چه شیوه برای تخمین زدن و مهم تر از آن برای برنامه ریزی ارایه و تحویل پروژه استفاده می کنید؟