Velocity در اسکرام چیست؟ – توضیح معیار سنجش موفقیت

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

Velocity در اسکرام به تیم توسعه اجازه می‌دهد تا موارد زیر بررسی شوند.

• مقدار کارهایی که می‌توان تا یک تاریخ مشخص به‌ انجام رساند را پیش‌بینی کند.
• قادر به تعیین تاریخی مشخص برای مجموعه‌ای از کارهای مشخص باشد.
• حین تعیین مقدار کارهایی که در یک اسپرینت انجام می‌شود و پیش از متعهد شدن به آن‌ها، محدودیت‌های خود را درک کند.

مثالی از Velocity در اسکرام

دستورالعمل‌هایی ساده برای تخمین زدن «شتاب» اولیه در تیم اسکرام شما، پیش از به پایان رسیدن نخستین برهه‌های توسعه وجود دارد. اما بعد از پشت سر گذاشتن این بازه، تیم شما می‌تواند از تخمین‌های پیشین و اثبات شده در فرایند برنامه‌ریزی برای اسپرینت استفاده کند. وقتی مجموعه‌ای از اسپرینت‌ها را پشت سر می‌گذارید، تخمین‌های مربوط به Velocity در اسکرام شکلی باثبات‌تر به خود می‌گیرند و تبدیل به فونداسیون قابل اتکا برای بهبود دقت پیش‌بینی‌های کوتاه‌مدت و همین‌طور بلند‌مدت در پروژه اسکرام شما می‌شوند.

در نظر داشته باشید که Velocity به معنای مقدار کارهایی است که تیم شما در جریان یک اسپرینت واحد به انجام می‌رساند و معیاری کلیدی در اسکرام به حساب می‌آید. برای محاسبه Velocity لازم است در انتهای هر اسپرینت، امتیازهای تمام «داستان‌های کاربر» به پایان رسیده را با یکدیگر جمع بزنید. با این حال امتیازهای مربوط به داستان‌های نسبتا به پایان رسیده یا ناقص را نباید در Velocity محاسبه کرد.

قدم اول: محاسبه شتاب در نخستین برهه توسعه (اسپرینت)

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

به عنوان مثال فرض می‌کنیم یک تیم توسعه چابک، برهه توسعه خود را آغاز کرده و می‌خواهد به داستان‌های الف و ب که ۲ امتیاز دارند و همین‌طور داستان پ که ۳ امتیاز دارد رسیدگی کند. در پایان اسپرینت، داستان‌های الف و ب به صورت ۱۰۰ درصدی به پایان رسیده‌اند، اما داستان پ تنها ۸۰ درصد کامل شده است. تیم‌های چابک معمولا تنها دو سطح از رسیدگی به امور را می‌شناسند: یک وظیفه یا ۰ درصد انجام شده و یا ۱۰۰ درصد. بنابراین داستان پ در «شتاب» محاسبه نمی‌شود و Velocity این اسپرینت، معادل ۴ امتیاز است.

قدم دوم: استفاده از شتاب برای محاسبه تعداد اسپرینت‌های مورد نیاز

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

فرض می‌کنیم که داستان‌های کاربری به ارزش ۴۰ امتیاز باقی مانده است. در این حالت، تیم توسعه پیش‌بینی می‌کند که برای به پایان رساندن تمام پروژه نیازمند ۱۰ برهه توسعه خواهد بود.

فیلم آموزش اسکرام Scrum – مفاهیم و تمرینات در فرادرس

کلیک کنید

ارتباط میان امتیاز داستان و Velocity در اسکرام

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

اما چطور Velocity را به امتیاز داستان پیوند بزنیم؟

1. تیم‌های توسعه معمولا نیازمند استفاده از «شتاب» به عنوان واحد اندازه‌گیری بهره‌وری هستند تا به افراد خارج از تیم بگویند که تیم اسکرام دقیقا چقدر سریع عمل می‌کند.
2. اگر تخمین‌های مربوط به امتیاز کاربر در سراسر پروژه درست از آب درآیند، منطقی خواهد بود که از امتیاز داستان برای نمایش Velocity استفاده کنیم.
3. اگر یکپارچگی را نه فقط در یک تیم، بلکه در تمام تیم‌ها ببینیم، Velocity نه‌تنها معیاری برای بهره‌وری خواهد بود، بلکه می‌تواند برای مقایسه وضعیت تیم‌های مختلف نیز به کار گرفته شود.
4. اگر مقدار امتیاز داستان باثبات باشد، می‌توان از آن به عنوان مرجعی برای برنامه‌ریزی‌های آتی استفاده کرد. برنامه‌های زمانی بالقوه را نیز می‌توان سپس مورد سنجش قرار داد.

امتیاز هر داستان کاربر چطور تعیین می‌شود؟

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

دو مقیاس مختلف برای تخمین زدن امتیازهای داستان کاربر داریم:

• مقیاس خطی (۶،۵،۴،۳،۲،۱،...)
• اعداد دنباله فیبوناچی (۱۳،۸،۵،۳،۲،۱،۰.۵،...)

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

در این مثال، از اعداد دنباله فیبوناچی برای تخمین امتیازهای داستانی استفاده شده:

چطور Velocity در اسکرام را دقیق‌تر تخمین بزنیم؟

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

مطالب پیشنهادی برای مطالعه:

• کانبان چیست؟ – توضیح و کاربرد به زبان ساده
• مدیریت چابک چیست؟ — Agile Management به زبان ساده و کاربردی
• توسعه محصول چیست؟ — توضیح از صفر و به زبان ساده
• مراحل توسعه محصول جدید چیست؟ — شرح فرآیند از صفر تا صد
• ترلو چیست و چگونه از Trello استفاده کنیم؟ — راهنمای رایگان و کامل
• شاخص کلیدی عملکرد (KPI) چیست؟ راهنمای جامع تنظیم

فرض می‌کنیم یک تیم اسکرام قصد دارد در نخستین اسپرینت خود، ۴۱ امتیاز داستانی را به پایان برساند. اما در انتها ۳۸ امتیاز داستانی به پایان می‌رسد و ۶ امتیاز داستانی هم به اسپرینت بعدی موکول می‌شود. بنابراین همان‌طور که در تصویر پایین می‌بینید، شتاب تیم اسکرام معادل ۳۸ خواهد بود:

میانگین‌گیری Velocity براساس عملکرد اسپرینت قبلی

همان‌طور که پیشتر نیز اشاره کردیم، تیم توسعه نباید وظایف ناقص را در شتاب خود محاسبه کند. در واقع تنها داستان‌هایی که برچسب «به پایان رسیده» خورنده‌اند در شتاب محاسبه می‌شوند، حتی اگر کار بسیار کوچکی برای انجام دادن روی یک داستان باقی مانده باشد.

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

تیم فرضی ما چهار اسپرینت را پشت سر گذاشته و در این اسپرینت‌ها به ترتیب قادر به نهایی کردن ۳۸ و ۲۹ و ۳۸ و ۳۹ امتیاز داستانی بوده است. بنابراین همان‌طور که در تصویر پایین می‌بینید، میانگین شتاب تیم موردنظر بعد از چهار اسپرینت، معادل ۳۶ است:

این میانگین که براساس چهار اسپرینت به دست آمده، بسیار کارآمدتر از محاسباتی ظاهر می‌شود که بعد از تنها یک اسپرینت به دست می‌آیند.

فیلم آموزش اسکرام برای مدیریت چابک فرایند توسعه اپلیکیشن های وب و موبایل در فرادرس

کلیک کنید

نمودار Velocity در اسکرام

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

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

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