سلام دوستان و همراهان من از این که افتخار این را دارم که بار دیگر با شما در رابطه با چابکی صحبت کنم خوشحالم!
در مقاله قبلی راجع به این که اسکرام چی هست و به چه درد ما می خوره صحبت کردیم و قرار شد توی این مقاله مسئله اسپرینت را باز کنیم و ببینیم جریان در یک پروژه واقعی چیه!
مرحلهی چهارم: تهیهی سند اسپرینت (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 خواهد بود. اما چقدر کمتر؟ ما از اصطلاح ضریب تمرکز برای این کار استفاده میکنیم.
سرعت برآورد شده = ضریب تمرکز × نفر / روز در دسترس
ضریب تمرکز برآوردی از میزان تمرکز تیم است. اگر این عدد کم باشد یعنی تیم انتظار اختلالات زیادی را خواهد داشت. بهترین روش برای تعیین ضریب تمرکز نگاه به آخرین اسپرینت است (یا بهتر است به میانگین چند اسپرینت پایانی نگاه شود):
ضریب تمرکز = سرعت واقعی آخرین اسپرینت/ نفر/ روز
هوووف فکر می کنم وقتش باشه که برم یک لیوان آب بخورم و یکم بخوام این همه مفاهیم در یک مقاله قطعا سنگینه و شاید لازم باشه دو بار بخونیمش تا حسابی بفهمیم چی شده
توی مقاله بعدی باز هم راجع به اسپرینت صحبت می کنیم. با من همراه باشید!
reza
۷ آبان ۹۹، ۰۸:۴۲سلام داداش
دمت گرم فوق العاده بود مطلبت. فکر کنم تصاویر مشکل دارند چون هیچکدوم از تصاویر لود نمیشن.
حسین اصلانی
۱۱ آذر ۹۹، ۱۰:۴۴سلام عزیزم، امیدوارم خوب باشید!
حسین
۶ آبان ۹۹، ۰۹:۵۸سلام وقتتون بخیر
مطلبتون عالی بود.
فقط یک نکته تصاویری که توی متن ازش صحبت کردید وجود نداره توی متن!