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

مقدمه

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

برنامه ریزی اسپرینت

این جلسه دو بخش اصلی دارد : بخش اول به آنچه که قرار است در اسپرینت بسازیم (هدف و بک لاگ های اسپرینت) و بخش دوم به چگونگی دستیابی به آن می پردازد. این دو بخش کاملا به هم وابسته هستند.

بهتر است چه بحث هایی در این جلسه انجام شود؟

بحث هایی که در این جلسه صورت می گیرد باید شامل طراحی محصول (product design) و طراحی نرم افزار(software design) باشد، طراحی محصول  معمولا بین مالک محصول و تیم توسعه شکل می گیرد و شامل بحث هایی مانند ترکیب” داستان ها” (story) ، بهینه کردن ارزش “داستان” ها برای مشتری و تفسیر باز خورد‌های کاربر می شود. طراحی نرم افزار معمولا بین افراد تیم توسعه شکل می گیرد بحث هایی مثل تکنولوژی به کار رفته، معماری،کارهای فنی ویژگی( feature) جدید، استفاده مجدد از کد موجود و….خروجی هر دو موضوع رسیدن به فهم بهتر از هدفی است که قرار است در طول اسپرینت به آن برسیم.

روش های برنامه ریزی اسپرینت

• Note Cards
• Tools

استفاده از Note Cards: دراین روش روی برد فیزیکی در سمت راست “داستان کاربرها” (user story) را می چسبانیم و درمقابل آن تسک های مربوط و تخمین آن ها را قرار می دهیم. مزیت مهمی که این روش دارد درگیر کردن تمام اعضای تیم در زمان برنامه ریزی اسپرینت است و عیب آن بهره مند نبودن از امکانات Tools مانند محاسبه ی اتوماتیک ظرفیت و نگهداری تاریخچه اسپرینت ها و …. است.

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

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

• مبتنی بر سرعت
• مبتنی بر ظرفیت

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

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

نکاتی در رابطه با شکستن(خرد کردن) تسک های بک لاگ اسپرینت

• تسک ها باید مرتبط با بک لاگ و دارای ارزش برای پروژه باشند
• با جزییات نوشتن تسک ها تا زمانی که برای تیم عادت شوند
• تسک زدن جلسات
• مدیریت وابستگی ها
• تسک اسپایک

تسک ها باید مرتبط با بک لاگ و دارای ارزش برای پروژه باشند:

تسک ها باید برای بک لاگ و در نهایت برای پروژه ارزش ایجاد کنند مثل تست، تحلیل، طراحی و… نه جواب دادن ایمیل ها اول صبح، جلسه با مدیرعامل و….

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

برای مثال وقتی تیم جدید است و تسک تست خودکار در تیم هنوز جا نیفتاده لازم است نوشته شود بعد‌ها که جزئی از کار همیشگی تیم شد می توان آن را با تسک بک اند ادغام کرد. برای مثال ابتدا دو تسک می زنیم:

• نوشتن کوئری لیست تراکنش ها 2- نوشتن تست کوئری لیست تراکنش ها

بعد ها که تست برای تیم جا افتاد و برایشان شرطی شد که هر کوئری که نوشته می شود قطعا تستش هم نوشته می شود، در این زمان می توانیم یک تسک بزنیم:

1-نوشتن کوئری لیست تراکنش ها

تسک زدن جلسات:

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

مدیریت وابستگی ها:

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

آیا این مسائل یاعث می شود پروژه، بیشتر از زمان مورد نیازش طول بکشد؟ به احتمال زیاد خیر چون در اصل بسیاری از این تسک ها از یک بک لاگ به بک لاگ دیگر انتقال پیدا کرده اند و هنگام انجام بک لاگی که بخشی از تسک هاش در بک لاگ دیگر انجام شده، کار بک لاگ سریع تر پیش می رود اگر تسک جا به جا شده نسبتا کوچک باشد تاثیر چندانی ندارد ولی اگر خیلی مهم و بزرگ باشد بهتر است یا اولویت ها جا به جا شوند و یا بک لاگ ها مجدد “برآورد”  (Effort) شوند.

تسک اسپایک:

شکستن برخی از بک لاگ ها به تسک ها مشکل هستند مثلا چه روشی برای انجام کار انتخاب شود که کمترین زمان را بگیرد و بهترین نتیجه را بدهد؟ فرض کنید می خواهیم قطعه کدی را تغییر دهیم ولی از تاثیراتش در جاهای دیگر اطمینان نداریم.اگر فقط یک جا تاثیر داشته باشد 6 ساعت زمان می گیرد ولی اگر جاهای دیگری از کد را نیز تحت تاثیر قرار دهد 12 ساعت زمان می برد ولی نمی توانیم مطمئن بگوییم 6 ساعت زمان می برد یا 12 ساعت.دراین حالت دو تسک در نظر می گیریم:

• بررسی تاثیرات تغییر کد: 2 ساعت(تسک اسپایک)
• اعمال تغییرات: 12 ساعت

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

نکاتی در رابطه با تخمین تسک ها

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

• گروهی تخمین زدن
• طراحی تا حدودی قابل قبول است
• بهترین اندازه برای تسک ها

گروهی تخمین زدن:

بهترین زمان را کسی می دهد که کار را انجام می دهد ولی بهتر است تخمین تسک گروهی انجام شود زیرا تسک ها  هنوز به کسی واگذار(assign) نشده اند. دلیلی ندارد که فرد خاصی فقط آن را تخمین بزند، حتی اگر شخص خاصی تسک را انجام می دهد و به او واگذار شده باشد باز هم دلیلی بر این نیست که بقیه تیم نظری راجع به تخمین آن ندهند و باید بین اعضای تیم بحث و چالش انجام شود تا تسک را گروهی تخمین بزنند. کلا بحث کردن در این رابطه که تسک چه زمانی طول می کشد تا انجام شود، به فهم تیم از بک‌لاگ و شناسایی بخش های از آن که توسط تیم درست درک نشده است کمک می کند حتی اگر “برآورد” “داستان ” بد باشد،  مشخص می شود.

طراحی تا حدودی قابل قبول است:

تا حدی بحث های طراحی در زمان تخمین تسک ها قابل قبول است اگر اصلا بحث نکنیم که نمی دانیم تسک چیست که بخواهیم آن را تخمین بزنیم ولی نباید خیلی در طراحی در زمان تخمین تسک ها عمیق شد، مالک محصول، تحلیلگر و طراح واسط کاربری می توانند بحث های طراحی محصول داشته باشند و این که چگونه ویژگی(feature) پیاده سازی می شود و چگونه برای کاربر متناسبتر است و تیم توسعه درباره‌ی چگونه  پیاده سازی آن بحث می کنند هر دو نوع بحث طراحی  درزمان تخمین زدن لازم است، اما هیچ وقت در این جلسه نمودار کلاس( class diagram ) رسم نمی شود و تا این حد در طراحی عمیق نمی شویم زیرا جلسه متوقف می شود و بیش از حد مجاز زمان می برد .

بهترین اندازه برای تسک ها:

تخمین تسک ها باید تا حد امکان دقیق باشد و هر توسعه دهنده بتواند در میانگین یک روز کاری آن را تمام کند، خیلی اوقات تسک هایی با سایز بزرگتر وجود دارند که می توانند بعدا با تسک هایی جا به جا شوند مثلا تسک 16 ساعته ای را موقع plan می زنیم ولی وقتی شروع به پیاده سازی کردیم و درک بهتری پیدا کردیم می توانیم آن را با تسک های کوتاه تری جا به جا کنیم.

منابع:

• Agile Estimating and Planning By Mike Cohen
• User Stories By Mike Cohen