چطور سند اسپرینت تهیه کنیم؟!

سلام دوستان و همراهان من از این که افتخار این را دارم که بار دیگر با شما در رابطه با چابکی صحبت کنم خوشحالم!

در مقاله قبلی راجع به این که اسکرام چی هست و به چه درد ما می خوره صحبت کردیم و قرار شد توی این مقاله مسئله اسپرینت را باز کنیم و ببینیم جریان در یک پروژه واقعی چیه!



اگر یادتون باشه توی مقاله قبلی سه مرحله از مراحل توسعه چابک را مطرح کردیم، الان میریم سراغ مرحله چهارم:

مرحله‌ی چهارم: تهیه‌ی سند اسپرینت (Sprint Backlog)

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

نحوه برگزاری جلسه برنامه ریزی اسپرینت

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

این اتفاق بارها و بارها رخ می­دهد، به خصوص برای تیم­های جدید. یک راه حل این است که بگویید 10 دقیقه دیگر این جلسه به پایان می­رسد و ما هنوز برنامه اسپرینت را آماده نکرده ایم. آیا باید در وقت باقیمانده این کار را انجام دهیم یا اینکه یک جلسه برنامه ریزی 4 ساعته برای فردا ساعت 8 صبح داشته باشیم؟ می­توانید حدس بزنید که پاسخ آنها چه خواهد بود؟؟؟

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

دستور جلسه برنامه ریزی اسپرینت

داشتن برنامه ریزی از پیش تعیین شده برای جلسه، ریسک زیر پا گذاشتن زمانبندی را کاهش می­دهد. مثالی از دستور جلسه برنامه ریزی می تواند به شکل زیر باشد:

جلسه برنامه اسپرینت : 13:00 تا 17:00

1-      13:00 تا 13:30 : صاحب محصول هدف اسپرینت و خلاصه ای از داستان­های بک­لاگ را بیان می­کند. همچنین زمان و مکان دمو را تعیین می­شود.

2-      13:30 تا 15:00 : تیم زمان انجام کار را برآورد زده و در صورت لزوم داستان­ها را می­شکند. صاحب محصول میزان اهمیت داستان­ها را در صورت لزوم تغییر می­دهد. داستان­ها واضح­تر شده و نحوه دمو آنها تعیین می­گردند.

3-      15:00 تا 16:00 : تیم داستان­هایی که باید در اسپرینت باشند را انتخاب می­کنند. همچنین سرعت تیم به صورت واقعی برآورد می­شود.

4-      16:00 تا 17:00 : زمان و مکان جلسه اسکرام روزانه انتخاب می­شود. داستان­ها به وظایف شکسته می­شوند.

تعیین طول اسپرینت

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

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

تعریف هدف اسپرینت

معمولا به صورت مستقیم و غیر مستقیم در طول جلسه برنامه ریزی اسپرینت این سوال زیاد مطرح می­شود "هدف این اسپرینت چیست؟" به برخی دلایل حرکت در مسیر هدف اسپرینت قدری سخت و دشوار است. هدف اسپرینت می­تواند “کسب پول بیشتر” ، “تکمیل سه داستان با اولویت بالا” ، “تحت تاثیر قرار دادن رئیس” و هر چیز دیگری باشد، ولی حتما باید با ادبیات بیزنس باشد تا اعضای خارج از تیم آن را درک کنند. هدف اسپرینت باید به این سوال اساسی پاسخ دهد که چرا داریم این اسپرینت را انجام می­دهیم.

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

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

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

این موضوغ دو سوال را مطرح می­کند:

1-      چگونه تیم تصمیم گرفته است که کدام داستان­ها را در اسپرینت وارد کند؟

2-      چقدر صاحب محصول می­تواند نظرش را اعمال نماید؟

ابتدا به سوال دوم پاسخ می­دهیم. چقدر صاحب محصول می­تواند نظرش را اعمال نماید؟ بیایید فرض کنیم که در جلسه برنامه ریزی اسپرینت، وضعیت زیر را داریم:

صاحب محصول می­خواهد داستان D در اسپرینت قرار گیرد. او چه گزینه­هایی برای رسیدن به این خواسته دارد؟

گزینه اول دوباره اولویت بندی داستان­ها است. اگر او بالاترین اولویت را به آیتم D بدهد، تیم آن را در بالای بک لاگ اسپرینت قرار می­دهد. در این حالت داستان C از اسپرینت حذف می­شود. مطابق شکل زیر:

گزینه دوم تغییر دامنه است. کاهش دامنه داستان A تا زمانی که تیم متقاعد شود که داستان D را در اسپرینت قرار دهد.

گزینه سوم تقسیم داستان است. صاحب محصول ممکن است که به این نتیجه برسد که قسمت­هایی از داستان A خیلی مهم نیستند، بنابراین او داستان A را به دو داستان A1  و A2 با سطح اهمیت متفاوت تقسیم می­کند، مطابق شکل زیر:

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

برآورد اسپرینت

چگونه تیم تصمیم می­گیرد که کدام داستان­ها باید در اسپرینت باشند؟ دو تکنیک وجود دارد که عبارتند از روش تجربی و تکنیک محاسبه سرعت که در ادامه راجع به آن صحبت می کنیم.

برآورد با استفاده از روش تجربی

در این روش مدیر اسکرام هر بار یکی از داستان­ها را مطرح کرده و از اعضای تیم می­پرسد که آیا می­توانند آن را در این اسپرینت انجام دهند یا خیر. تا زمانی اعضای تیم با اطمینان داستا­نها را به اسپرینت وارد کنند، این رویه ادامه می­باید. داستان­هایی که احتمال تکمیل آن در اسپرینت بالا باشد وارد اسپرینت می­شوند. به محض اینکه به اولین داستانی که احتمال انجام آن کمتر از 50% است برسیم، بک­لاگ اسپرینت بسته می­شود.

برآورد با استفاده از محاسبه سرعت

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

شکل زیر مثالی را نشان می­دهد از سرعت برآورد شده در شروع یک اسپرینت و سرعت واقعی در پایان آن اسپرینت. هر مستطیل یک داستان است و  اعداد درون آنها بیانگر برآورد اولیه هستند.

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

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

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

روش دیگر برآورد کردن تکنیک محاسبه منابع است. فرض کنید که می­خواهیم یک اسپرینت 3 هفته ­ای (15 روز کاری) را با یک تیم 4 نفره برنامه ریزی کنیم. لیلا برای دو در تعطیلات است. تهمینه فقط 50% در اختیار است و یک روز به مرخصی می­رود. بنابراین جدول زیر را خواهیم داشت:

اعضای تیم

روزهای در دسترس

تهمینه

15

لیلا

13

سام

15

داریوش

7

کل نفر-روز در دسترس

50

جدول فوق می­گوید که میزان نفر-روز در دسترس برای این اسپرینت 50 است. آیا این عدد برآورد درستی برای سرعت است؟ مسلما نه! زیرا واحد برآورد ما Story Point است در حالی که در اینجا واحد نفر/ روز ایده ال است. یک نفر/روز یعنی میزان کار یک فرد، بدون وقفه و کاملا موثر در طول یک روز که خیلی بعید است این چنین شود. به علاوه باید چیزهایی مانند کارهای برنامه ریزی نشده، مریض شدن افراد و غیره را در نظر داشته باشیم. بنابراین سرعت برآورد شده کمتر از 50 خواهد بود. اما چقدر کمتر؟ ما از اصطلاح ضریب تمرکز برای این کار استفاده می­کنیم.

سرعت برآورد شده = ضریب تمرکز × نفر / روز در دسترس

ضریب تمرکز برآوردی از میزان تمرکز تیم است. اگر این عدد کم باشد یعنی تیم انتظار اختلالات زیادی را خواهد داشت. بهترین روش برای تعیین ضریب تمرکز نگاه به آخرین اسپرینت است (یا بهتر است به میانگین چند اسپرینت پایانی نگاه شود):

ضریب تمرکز = سرعت واقعی آخرین اسپرینت/ نفر/ روز


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

توی مقاله بعدی باز هم راجع به اسپرینت صحبت می کنیم. با من همراه باشید!


حسین اصلانی

حسین اصلانی

حسین اصلانی؛ رئیس سابق هیئت مدیره آرپینا
مدیرمحصول؛ پژوهشگر؛ مترجم و سخنران

نظر (۲)

wave
  • reza

    reza

    ۷ آبان ۹۹، ۰۸:۴۲

    سلام داداش 

    دمت گرم فوق العاده بود مطلبت. فکر کنم تصاویر مشکل دارند چون هیچکدوم از تصاویر لود نمیشن.

  • reza

    حسین اصلانی

    ۱۱ آذر ۹۹، ۱۰:۴۴

    سلام عزیزم، امیدوارم خوب باشید! 

    متاسفانه خیلی وقته نمی نویسم و تصاویر هم قدیمی شدن! برای همینه که لود نمیشن!

  • حسین

    حسین

    ۶ آبان ۹۹، ۰۹:۵۸

    سلام وقتتون بخیر

    مطلبتون عالی بود.

    فقط یک نکته تصاویری که توی متن ازش صحبت کردید وجود نداره توی متن!

ارسال نظر

wave
کاربران بیان میتوانند بدون نیاز به تأیید، نظرات خود را ارسال کنند.
اگر قبلا در بیان ثبت نام کرده اید لطفا ابتدا وارد شوید، در غیر این صورت می توانید ثبت نام کنید.
شما میتوانید از این تگهای html استفاده کنید:
<b> یا <strong>، <em> یا <i>، <u>، <strike> یا <s>، <sup>، <sub>، <blockquote>، <code>، <pre>، <hr>، <br>، <p>، <a href="" title="">، <span style="">، <div align="">
تجدید کد امنیتی

ESC را فشار دهید تا بسته شود