برنامه ریزی اسپرینت مبتنی بر سرعت یا "Velocity-Based Sprint Planning"  چیست؟

مهم ترین معیاری که یک تیم چابک در برنامه ریزی از آن استفاده می کند "سرعت (Velocity)"  آن است. درواقع Velocity مقدار کار انجام شده توسط تیم در هر سرعت است که به تیم کمک می کند تا تشخیص دهد که با یک سرعت مشخص چقدر می توانند پیشرفت داشته باشند. سرعت با اضافه کردن استوری پوینت"story points" های داده شده به هر داستان کاربر"user story"  که تا پایان اسپرینت کامل می شود محاسبه می شود. ما با استفاده از این روش تنها خروجی را می سنجیم،  نه نتیجه را ...!

مراحل  برنامه ریزی اسپرینت مبتنی بر سرعت به شرح زیر است:

• محاسبه سرعت متوسط تیم با استفاده از( تجربیات ما در 3 اسپرینت گذشته)
• انتخاب ایتم های بک لاگ محصول با توجه به سرعت متوسط  تیم 
• بررسی کنید که آیا وظایف مرتبط با داستان های کاربر"user story" انتخاب شده برای اسپرینت پیش‌رو مناسب هستند یا خیر
• تسک ها را با کمک تیم تخمین بزنید و بررسی کنید که آیا کل کار با سرعت های گذشته مطابقت دارد یا خیر

چرا به اسپرینت پلنینگ مبتنی بر سرعت نیاز داریم؟

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

علاوه بر این، ما می توانیم:

• تخمین بزنیم چه چیز هایی را می توانیم تا یک تاریخ مشخص تحویل دهیم
• تاریخ تحویل مقدار کار متعهد شده را تخمین بزنیم
• در حین تعیین میزان کاری که برای اسپرینت انجام می دهیم، اهداف خود را در اسپرینت درک کنیم

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

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

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

تخمین هرچه دقیق تر سرعت تیم معیاری است که در طول فرایند تخمین زدن باید به آن خوب توجه کنند .

چگونه سرعت اسپرینت"Sprint Velocity" را محاسبه کنیم؟

بیایید فرض کنیم که تیم در حال برگزاری اسپرینت یک هفته ای برای محاسبه سرعت است.

محاسبه سرعت در اسپرینت 1

فرض کنید تیم به 5  یوزر استوری "user story" متعهد شده است
همچنین فرض کنید هر یوزر استوری = 8 استوری پوینت "story points" باشد
بنابر این مجموع استوری پوینت ها در اسپرینت1 = 40 استوری پوینت خواهد بود
حال فرض کنید که تیم 3  یوزر استوری را از  5 یوزر استوری تا پایان اسپرینت 1 تکمیل کرده است

کل یوزر استوری های  تکمیل شده = 3
بنابر این مجموع استوری پوینت های تکمیل شده = 24 (تعداد کل یوزر استوری های  تکمیل شده x استوری پوینت آنها )  8x3=24

محاسبه سرعت در اسپرینت 2

حالا فرض کنید تیم به 7 داستان کاربر متعهد شده است
و هر یوزر استوری = 8 استوری پوینت امتیاز دارد
سپس مجموع استوری پوینت ها در اسپرینت2 = 56 استوری پوینت خواهد بود
بنابر این فرض کنید که تیم 4 یوزر استوری از 7 مورد تا پایان اسپرینت 2 تکمیل کرده است

کل یوزر استوری های تکمیل شده = 4 خواهد بود
مجموع استوری پوینت های تکمیل شده = 32 (تعداد کل یوزر استوری های تکمیل شده x استوری پوینت انها) 8x4=32

محاسبه سرعت در اسپرینت 3

مجددا فرض کنید تیم به 9 یوزر استوری  متعهد شده است
و هر یوزر استوری = 8 استوری پوینت باشد
سپس مجموع استوری پوینت ها  در اسپرینت3 = 72 استوری پوینت باشد
بنابر این فرض کنید که تیم 5 یوزر استوری از 9 مورد را تا پایان اسپرینت 3 تکمیل کرده است

کل یوزر استوری های تکمیل شده = 5
مجموع استوری پوینت های تکمیل شده = 40 (تعداد کل یوزر استوری های تکمیل شده x استوری پوینت ها ) 5x8=40

طبق مطالعات انجام شده ثابت شده است که سرعت همیشه در چند تکرار"iterations" اول از سرعتی به سرعت دیگر در نوسان است. یک تیم جدید برای رسیدن به یک سرعت ثابت زمان نیاز دارد. این نیز ممکن است به دلیل برخی تغییرات در یک تیم اتفاق بیفتد. این گزارش همچنین نشان داد که در بیشتر موارد، محاسبه سرعت احتمالاً پس از تکمیل حداقل سه iterations تثبیت می‌شود. بنابراین، خوب است که پس از انجام حداقل 3-5 اسپرینت، استوری پوینت های تکمیل شده را تجزیه و تحلیل کنیم.

محاسبه میانگین سرعت اسپرینت
ما اکنون سرعت های اسپرینت قبلی خود را می دانیم که در زیر آورده شده است:

اسپرینت 1: 24
اسپرینت 2: 32
اسپرینت 3 : 40

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

توجه داشته باشید: تعداد کل یوزر استوری های انجام شده در طول یک اسپرینت نباید از میانگین سرعت اسپرینت‌های گذشته تجاوز کند !!

دلایل نوسان سرعت:
فاکتور های زیر عوامل موثری در نوسانات سرعت"Velocity "  در یک پروژه خواهد بود:

• پیچیدگی پروژه
• اندازه تیم
• یکنواختی در عضویت تیم
• توانایی تیم برای تمرکز بر یوزر استوری ها  و فعالیت های اسکرام
• از دسترس خارج شدن سیستم
• عدم مشارکت مالک محصول
• غیبت ها و مرخصی های  غیرمنتظره در تیم

نمودار سرعت "Velocity chart" چه  کمکی به ما می کند؟

• وضعیت کلی پروژه را رهگیری می کند
  نمودار سرعت تعدادی از روندهای پروژه مانند داستان های پذیرفته شده بر اساس نوع، معیارهای نوسانات و سرعت تکرار را محاسبه می کند. این باعث می شود نمودار سرعت برای نظارت بر وضعیت کلی پروژه ایده آل باشد.
   
• عدم قطعیت و پیچیدگی ها را ردیابی می کند 
  نوسانات در پیچیدگی ها و عدم قطعیت معیاری برای پیش بینی پذیری است. دره‌ها و قله‌های مکرر از نمودار سرعت"velocity" پروژه‌ای غیرقابل پیش‌بینی را به شما نشان می دهند، در حالی که سرعت اگر سرعت در نمودار به شکل تکرار های مکرر و ثابت باشد  iteration-by-iteration حاکی از یک پروژه قابل پیش‌بینی است.
   
• روندهای سرعت را شناسایی می کند
  استوری پوینت های پذیرفته شده ممکن است برای یک تکرار خاص"specific iteration" کمتر باشد، زمانی که تعداد خورده کار یا تسک های ریز یا مشکلاتی مثل باگ وجود داشته باشد. این نمودار با نمایش افت سرعت تکرارها"iterations" همراه خواهد بود بنابر این با افزایش مشکلاتی مثل باگ ها، می توان افت سرعت را به وضوح در نمودار Velocity chart مشاهده کرد.

چگونه می توان سرعت اسپرینت بعدی را پیش بینی کرد؟

اگر داده های تاریخی سرعت"historical data of velocity" را داشته باشیم، پیش بینی سرعت"velocity" آینده آسان است. این یکی از مزایای داشتن تیم های پایدار است، زیرا آنها چنین داده های تاریخی مفیدی را ثبت کرده اند یا بخاطر دارند. اما، اگر تیم جدید باشد و با یکدیگر کار نکرده باشندبدون شک هیچ داده تاریخی نخواهند داشت، در این صورت چکار باید کرد ؟؟

در چنین حالتی ما چاره ای نداریم غیر از اینکه آن را تخمین بزنیم.

یک راه ساده برای پیش‌بینی سرعت یک تیم این است که برنامه‌ریزی اسپرینت مبتنی بر ظرفیت تیم را در نظر بگیریم تا تخمین بزنیم که چه ایتم هایی از بکلاگ محصول را می‌توانند در پایان هر اسپرینت تحویل دهند. اگر تعهد آنها قابل قبول به نظر می رسد، ما فقط می توانیم اندازه PBI  - product backlog item هایی را که متعهد شده اند اضافه کنیم و از آن به عنوان سرعت پیش بینی شده تیم استفاده کنیم.

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

اسپرینت پلنینگ مبتنی بر سرعت چه تاثیری به همراه دارد ؟
برنامه ریزی انتشار"Release planning" بدون سرعت امکان پذیر نیست. یک مالک محصول، با وجود تخمین سرعت، می‌تواند تعداد اسپرینت‌های مورد نیاز تیم را برای دستیابی به سطح مطلوبی از عملکرد پیش‌بینی کند. بنابراین، مالک محصول می‌تواند تاریخ خاصی را برای انتشار نسخه هایی از محصول با توجه به طول اسپرینت پیشبینی کند.

مترجم و نویسنده : علی امینی

اجایل شو شما را به مطالعه مقاله های زیر دعوت می کند :

برنامه ریزی انتشار (Release Planning) در اسکرام چیست ؟

معرفی 16 کتاب آموزشی اسکرام

اسپرینت پلنینگ مبتنی بر ظرفیت چیست ؟