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

“طرح ها چیزی نیستند، طرح ریزی ها همه چیز هستند”، گفته دوایت آیزن هاور. این بینش کاملا مناسب طرح ارائه یا همان Release Plan خودمان می باشد. هر چند در اسکرام تیم ها مجبور نیستند که طرح ارائه داشته باشند، ولی آنها مجبورند که ارائه را طرح ریزی بکنند. در پروژه های بزرگ اسکرام، یا آنهایی که مجبور هستند با پروژه های دیگر، شرکاء یا تامین کنندگان هماهنگ باشند معمولا از یک طرح رسمی استفاده می کنند.

طرح ارائه مانند یک نقشه می باشد که ما را به سمت مقصدمان راهنمایی می کند. این پیش بینی می کند که محصول چگونه بدنیا خواهد آمد و نرم افزار چه زمانی ارائه خواهد شد. یک طرح ارائه نسخه پیشرفته برن داوون ارائه (Release Burndown) می باشد. البته اطلاعات بیشتری از یک برن داوون برای ما فراهم می کند ولی همچنان پیچیدگی بیشتری را نیز به همراه دارد.

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

طرح ارائه را نمی توان ثابت در نظر گرفت. این طرح با تکامل و درک کارهای لازم و بهبود سرعت تغییر می کند. جلسه بازبینی اسپرینت یا همان Sprint Review بهترین زمان برای ایجاد و آپدیت تعاملی طرح ارائه می باشد.

برای بدست آوردن بیشتر این طرح، معمولا من تمایل دارم قابلیت های موجود در هر ارائه را به صورت Theme یا اپیک نشان دهم.  نشان دادن داستان ها در طرح ارائه، ما را به سمت جزئی تر کردن آنها درسوق خواهد داد. آوردن هر اطلاعاتی برای هماهنگ شدن با دیگران در طرح ارائه می تواند مفید باشد و می توان تغییرات شناخته شده ای که بر روی سرعت تاثیر می گذارند را نیز ذکر کرد، مانند تغییر در ترکیب تیم ها یا سازمان پروژه. جدول زیر نشان دهنده یک طرح ارائه نمونه می باشد:

در مثال جدول بالا، پروژه در اسپرینت چهارم می باشد و انتظار می رود ارائه نسخه 1.0  بعد از چهار اسپرینت امکان پذیر شود. هر اسپرینت دو هفته می باشد. نسخه آلفا دو ریشه اساسی را پیاده سازی خواهد کرد که برای مشتری های انتخاب شده بعد از چهار اسپرینت ارائه خواهد شد.  نسخه بتا فراهم کننده دو ویژگی ریشه دیگر خواهد بود که بعد از شش اسپرینت ارائه می شود. هر چند این ارائه ها آلفا و بتا نامیده شده اند، اما آنها فرآورده های محصول می باشند و باید با تعریف تکمیل شد همخوانی داشته باشند. نسخه 1.0 بعد از هشت اسپرینت یا چهار ماه ارائه خواهد شد(اسپرینت دو هفته ای). در طرح بالا پروژه در سومین اسپرینت انتطار یک تدارک را دارد.

به طور کلی طرح ارائه سرعت واقعی را مستند می کند و یک پیش بینی برای اسپرینت های باقی مانده را نیز فراهم می سازد.

پیش بینی سرعت یا Velocity

برای پیش بینی سرعت، گام های زیر را دنبال می کنیم: اگر یک محصول جدید در حال توسعه می باشد، اگر تیم هرگز باهم کار نکرده اند یا ترکیب تیم به طور محسوسی تغییر کرده است، سرعت را معمولا بعد از انجام حداقل یک اسپرینت ( دو یا سه اسپرینت ترجیحا) ملاحظه می کنیم. معمولا دو یا سه اسپرینت طول می کشد تا سرعت تیم پایدار شود. با استفاده از رنج سرعت اسپرینت های گذرانده شده، سرعت اسپرینت های باقی مانده را حدس می زنیم. در طرح ارائه جدول بالا ، دلیل اینکه محدوده اسپرینت چهارم 20 تا 28 شده است این است که میانگین امتیازهای بدست آمده 24 بوده است.

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

برای بدست آوردن سرعت، میانگین بدست آمده از سه اسپرینت اول ، در مثال ما همان 24 را با ضرایب پایین و بالای مناسب و اشاره شده در جدول بالا ضرب می کنیم. نتیجه حد سرعت 21 – 28 می باشد.

بعد از اینکه تیم چهار یا پنج اسپرینت را انجام داد، می توانیم پیش بینی های قابل اعتماد تری را داشته باشیم.  فرض کنید در اسپرینت آخر یا همان اسپرینت 8 طرح ارائه جدول اول هستیم و اکنون می خواهیم سرعت تیم در ارائه بعدی را پیش بینی کنیم. سرعت اسپرینت های تکمیل شده به این صورت می باشد: 20 – 25 – 28 – 26 – 16 – 20 – 26 – 26. اکنون هر داده ای مربوط به اسپرینت های غیر معمول را به دور می اندازیم، مانند اسپرینتی که کل اعضای تیم مریض شده بودند یا برای چند روز مشغول نصب سرور یکپارچه ساز بودند. سپس ما لیست را به صورتی صعودی مرتب می کنیم : 16 – 20 – 20 – 25 – 26 – 26 – 26 – 28. سپس ما با استفاده از جدول زیر می توانیم برای اسپرینت های بعدی پیش بینی با صحت 90% داشته باشیم.

بدلیل اینکه فقط 8 اسپرینت را اجرا کردیم، دومین سرعت را در لیست مرتب کرده مان انتخاب می کنیم. این به ما نشان می دهد در رنج 20 – 26 سرعت متوسط مان 23 خواهد بود. با این جدول می توانیم مطمئن شویم که 90 درصد سرعت واقعی برابر با رنج پیش بینی شده خواهد بود.

ایجاد طرح ارائه

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

به جدول طرح ارائه یا همان جدول اول بنگرید. این جدول سرعت واقعی سه اسپرینت را 20 – 25 و 28 مشخص کرده است. پس سرعت میانگین به ازای اسپرینت 24 می باشد.  تیم اسکرام برای اسپرینت چهارم با توجه به جدول دوم حدود سرعت را 21 تا 28 امتیاز پیش بینی می کند. طرح ارائه همچنین برای اسپرینت های پنجم و ششم افت سرعت را پیش بینی می کند، جایی که برخی از اعضای تیم به مرخصی خواهند رفت.

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