همه ی تیم هایی که در محیط های پیچیده به خصوص محیط های تولید و توسعه نرم افزار مشغول فعالیت هستند به دنبال بهبود عملکرد خود میباشند. این تیم ها با برگزاری جلساتی تحت عنوان Retrospective(بازاندیشی اسپرینت) سعی در شناسایی نقاط قابل بهبود تیم در اسپرینت های گذشته و تعریف اقدامات بهبودی جهت افزایش عملکرد خود میباشند. اما آیا بدون استفاده از متریک ها و مصور سازی آنها این امر ممکن است؟
در کتاب Agile Metric in Action به 4 متریک مهم اشاره شده که در ادامه به آنها خواهیم پرداخت.استفاده از این متریک ها و پایش دوره ای آنها به شما بینش و قدرت تصمیم گیری میدهد.
در استفاده از میتریک ها چند نکته حائز اهمیت است:
- از یک متریک جهت تصیمیم گیری استفاده نشود.(گاها تیم ها یک متریک را ملاک تصمیم گیری قرار میدهند که این مورد قابل اتکا نیست)
- روند اندازه گیری آنها پیوسته و به صورت مصور به تیم نمایش داده شود.
- اقدامات بهبودی متناسب برای آنها تعیین شود.
4 متریک مهم چابکی در توسعه محصول عبارتنداز:
- تخمین
- حجم کار Done شده
- باگ
- میزان کار برگشت خورده
- تخمین
اولین متریک که اکثر تیم ها با آن سر و کار دارند، تخمین است. تخمین به معنی پیش بینی میزان تلاش(کار) مورد نیاز جهت انجام یک واحد کاری است. هر چه پیش بینی تلاش(کار) نسبت به میزان واقعی تلاش(کار) به یکدیگر نزدیکتر باشد، تیم نسبت به وضعیت خود آگاه تر و در تصمیم گیری ها دقیق تر عمل میکند.
تخمین انجام کار در محیط های پر ابهام به خصوص تولید و توسعه نرم افزار بسیار پیچیده است لذا تیم ها با رویکردهای مختلف همانند استوری پوینت، ایده آل تایم و … و با کمک تکنیک های تخمین همچون پوکر پلنینگ، T-Shirt ، سری فیبوناچی و … این مهم را انجام میدهند.
در نمودار بالا، تیم با روش استوری پوینت میزان تلاش مورد نیاز در اسپرینت های مختلف را اندازه گیری و به صورت کمی در نمودار نمایش داده است.
حالت ایده آل این نمودار به صورت پیوسته و در اسپرینت های مختلف در یک شیب ثابت و نزدیک به خط صاف باید باشد.(در صورت عدم تغییر ظرفیت در تیم)
2. حجم کار انجام شده
بسته به ظرفیت هر تیم این میزان متفاوت است، اما در اسپرینت های متوالی، تیم باید آهنگ خود را نسبت به حجم کار و میزان Done شدن آنها پیدا کند.این متریک با اندازه گیری میزان کار انجام شده در انتهای هر اسپرینت قابل دستیابی است.
3. باگ
هر مشکل در محصول که توسط ذینفعان گزارش شود به عنوان باگ تلقی میشود. باگ ها اثرات مخرب بر محصول دارند و باعث کاهش رضایت مشتریان نهایی میشوند.لذا Track کردن روند آنها و به حداقل رساندنشان برای تیم، از اهمیت بالایی برخوردار است. اندازه گیری تعداد باگ ها،باعث بالا بردن کیفیت توسعه و مراحل آن میشود و برای هر تیم حیاتی است. روند باگ ها نیز به تنهایی، متریک قابل اتکایی نیست لذا در کنار مابقی متریک ها معنا و مفهوم پیدا میکند.
4. میزان بازگشت کار
یکی از متریک هایی که کمتر به آن توجه میشود میزان بازگشت کار میباشد. این متریک معمولا برای کارهایی از جنس توسعه که توسط توسعه دهنگان تیم انجام میشود قابل سنجش هست. فرض کنید تیم شما دارای سه برنامه نویس و یک تستر است. تمامی کارها پس از مراحل انجام به تستر انتقال پیدا میکنند و تایید و عدم تایید اولیه توسط تستر صادر میشود. هر چه میزان برگشت کار به توسعه دهنده بیشتر باشد مسلما عمده زمانش جهت رفع این موارد خواهد بود. و هر چه کیفیت کد بالاتر باشد میزان بازگشت به حداقل خواهد رسید.
چند نکته مهم در جمع بندی :
- هر چه داده های خام شما بیشتر باشد قدرت تحلیل شما از وضعیت توسعه محصول بالاتر میرود.
- یک DOD قوی باعث کاهش باگ احتمالی در محصول میشود .
- هدف نهایی از مصور سازی داده ها و نمایش به تیم، پیدا کردن نقاط قابل بهبود و تعریف اقدامات بهبودی متناسب با تیم میباشد.
- استفاده از Burn Down و Velocity نقطه شروع خوبی جهت Track کردن وضعیت تیم است اما سعی کنید موارد دیگری نیز به آن اضافه کنید.
- با بررسی روند هر یک از متریک ها، ظرفیت تیم نسبت به کارهایی که باید در اسپرینت انجام دهند تا حدودی مشخص و قابل برنامه ریزی میشود.
مراجع :
دیدگاهتان را بنویسید