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

ابتدا می خواهیم بپرسیم چرا از متریک های قابل اندازه گیری اسکرام استفاده  می کنیم و برای رسیدن به اهداف و گزارش به ذینفعان از چه معیارهایی باید استفاده کرد؟

در این مقاله یاد خواهید گرفت:

• چگونه می توان از رویدادهای متدلوژی اسکرام برای جمع آوری اطلاعات مهم در مورد پیشرفت تیم استفاده کرد
• 4 معیار اسکرام که می تواند به اندازه گیری تحویل"delivery" به مشتریان کمک کند
• 4 معیار اسکرام که می تواند به اندازه گیری اثربخشی"effectiveness" تیم در دستیابی به اهداف تجاری کمک کند
• 3 معیار اسکرام که می تواند برای اندازه گیری سلامت تیم و فرآیند استفاده شود
• از کدام معیارها برای گزارش دادن به ذینفعان "stakeholders" استفاده کنید
• و در نهایت به معیار گمشده در پروژه های توسعه اسکرام یعنی (کیفیت نرم افزار) بپردازیم

قبل از هرچیزی بیاید ی مرور کنیم ببینیم اصلا اسکرام چیه !

بطور کلی اسکرام یک متدولوژی چابک برای مدیریت پروژه های توسعه است که از مفهوم محدوده زمانی برای ساختار و تخمین کار"estimate" استفاده می کند. یک تیم اسکرام در مراحل کوچکی به نام اسپرینت"sprint" که معمولا بین 1 تا 4 هفته ممکن است طول بکشد تشکیل شده است. دامنه کار با توجه به اینکه تیم احساس می کند می تواند در یک اسپرینت به چه دستاورد هایی برسد، تعریف می شود. در هر اسپرینت، کار های قابل تحویل باید آماده تحویل به مشتریان باشد.

رویدادهای اسکرام و ارزش آنها برای اندازه گیری پیشرفت

Scrum چندین رویداد تکرار شونده "recurring events" دارد که به مدیریت تکرارها"iterations" و ارائه کنترل فرآیند کمک می کند. هر یک از اینها می تواند به ارائه معیارها و داده های معنی دار به تیم و مدیریت کمک کند، برای مثال:

• برنامه ریزی اسپرینت "Sprint planning"- جلسه ای در شروع یک اسپرینت است که در آن شرح داستان"story descriptions" های سطح بالا به وظایف دقیق"detailed tasks" تقسیم می شوند و تخمین دقیقی را برای محدوده کاری که می توان در طول اسپرینت انجام داد ارائه می دهد.
• دیلی "Daily scrum" - یک جلسه ترجیحا ایستاده است که روزانه در آن اعضای تیم پیشرفت و مشکلاتی را که با آن روبرو هستند به اشتراک می گذارند و گزارشی در مورد ساعت‌های باقی‌مانده برای انجام کارهای اسپرینت ارائه می‌کنند که به تولید معیار برندان "sprint burndown metric" در اسپرینت کمک می‌کند.
• گذشته نگر اسپرینت "Sprint retrospective" - یک جلسه از خلاصه سرگذشت اسپرینت تمام شده در پایان هر اسپرینت است که برای به اشتراک گذاشتن آنچه خوب بوده، آنچه کمتر خوب پیش رفت و ایده هایی برای بهبود و اطلاعات کیفی را ارائه می دهد که می تواند به ارزیابی سلامت تیم اسکرام و فرآیندها کمک کند.

اما Scrum Metrics و KPI های آن چیست ؟

معیارهای Scrum و KPIها بخشی از خانواده گسترده تری ازKey performance indicators (KPIs) های چابک"agile" هستند. معیارهای چابک شامل معیارهای لین "lean" است که بر جریان ارزش یک سازمان به مشتریانش متمرکز است و معیارهای کانبان"Kanban" که بر گردش کار و انجام وظایف تمرکز دارد. در حالی که بیشتر معیارهای اجایل برای تیم‌های اسکرام قابل اجرا هستند، معیارهای خاص اسکرام بر تحویل نرم‌افزار قابل پیش‌بینی"predictable software delivery" تمرکز می‌کنند و مطمئن می‌شوند که تیم‌های اسکرام حداکثر ارزش را در هر تکرار"iteration" به مشتریان ارائه می‌دهند.

در مجموع KPIهای اسکرام سه هدف عمده دارند:

1. برای اندازه‌گیری محصولات تحویلی"deliverables" تیم اسکرام و درک میزان ارزشی که به مشتریان ارائه می‌شود.
2. برای سنجش اثربخشی"effectiveness" تیم اسکرام؛ سهم آن در کسب و کار از نظر بازگشت سرمایه"ROI"، زمان ورود به بازار"time to market" و غیره.
3. برای اندازه‌گیری خود تیم اسکرام به منظور سنجش سلامت آن و مشکلاتی مانند بازدهی تیم، فرسایش تیم و توسعه‌دهندگان ناراضی.

معیار های قابل اندازه گیری اسکرام"Scrum Metrics" و اندازه گیری ایتم های قابل تحویل"Measuring Deliverables" :

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

1. موفقیت هدف اسپرینت "Sprint Goal Success"
هدف اسپرینت بخشی اختیاری از چارچوب اسکرام است. همانطور که توسط Scrum.org تعریف شده است، به سه سوال پاسخ می دهد: چرا ما در این اسپرینت فعالیت می کنیم و پیش می رویم؟ چگونه به هدف اسپرینت برسیم؟ چه معیاری به ما می گوید که هدف محقق شده است؟ به عنوان مثال، هدف یک اسپرینت ممکن است ارائه یک ویژگی"feature" جهت پرداختن به یک ریسک یا آزمایش یک فرضی باشد.

با تعریف اهداف اسپرینت و سپس اندازه گیری تعداد اسپرینت هایی که به هدف رسیده اند، می توانید یک ارزیابی کیفی از کار تیم اسکرام دریافت کنید. نه فقط تعداد استوری پوینت"story point" های تکمیل شده، بلکه تعداد دفعات برآورده شدن اهداف کسب و کار.

2. دیفکت ها و تراکم انها

Escaped defects یک معیار بسیار مهم است که نشان می‌دهد کاربران در چرخه تولید نرم افزار چه تعداد باگ را تجربه کرده‌اند. در حالت ایده‌آل، یک تیم اسکرام باید داستان‌ها را"stories" به طور کامل آزمایش کند و از نقص‌های از زیر دست در رفته کاملاً اجتناب کند. در واقعیت، به ندرت اتفاق می‌افتد، اما روند نقص‌های شناسایی شده، سیگنال خوبی از کیفیت محصول است.

تراکم نقص "Defect density" نیز ارزش تماشا را دارد - تعداد عیوب را در هر اندازه از نرم افزار اندازه گیری می کند، به عنوان مثال در هر خط کد (LOC). در حالی که این معیار را می توان به راحتی منحرف کرد، در پروژه هایی که به سرعت در حال حرکت هستند، بررسی اینکه آیا رشد نقص ها "طبیعی" است یا نه، با توجه به رشد پایه کد اساسی، ارزشمند است.

3. سرعت تیم (Team Velocity)

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

در حالی که سرعت"velocity" یک معیار کلیدی برای مشاهده در هر پروژه اسکرام است، کارشناسان نسبت به استفاده از آن به عنوان یک هدف یا استفاده از سرعت برای مقایسه تیم ها با یکدیگر هشدار می دهند. سرعت یک معیار ذهنی (بر اساس تعریف هر تیم از story points) است که پیشرفت تیم را نشان می دهد. تلاش برای افزایش مصنوعی سرعت می تواند باعث از بین رفتن اعتماد و کاهش شفافیت بین تیم ها و مدیریت شود.

4. اسپرینت برندان چارت "Sprint Burndown"

نمودار برندان"BurnDown Chart" یا به ترجمه فارسی نمودار فرسودگی اسپرینت ، نمایش کلاسیک پیشرفت در یک اسپرینت را نشان می دهد. تعداد ساعت‌های باقی‌مانده برای تکمیل داستان‌های برنامه‌ریزی‌شده"stories planned" برای اسپرینت فعلی را برای هر روز در طول اسپرینت نشان می‌دهد. برندان چارت در یک نگاه نشان می دهد که آیا تیم در برنامه ریزی برای تکمیل محدوده اسپرینت موفق بوده است یا خیر.

معیار های قابل اندازه گیری اثربخش در اسکرام

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

1. زمان عرضه به بازار (Time to Market)
زمان عرضه به بازار زمانی است که یک پروژه برای شروع ارائه ارزش به مشتریان یا زمانی که طول می کشد تا شروع به تولید درآمد کند. اولین مورد را می توان با در نظر گرفتن طول تعداد اسپرینت ها قبل از اینکه یک تیم اسکرام برای تولید عرضه کند، محاسبه کرد. بسته به استراتژی تست آلفا و بتا سازمان، دومی می تواند طولانی تر باشد.

2.بازگشت سرمایه (ROI) 
Return on Investment یا بازگشت سرمایه (ROI) برای یک پروژه اسکرام کل درآمد حاصل از یک محصول را در مقابل هزینه اسپرینت های مورد نیاز برای توسعه آن محاسبه می کند. اسکرام این پتانسیل را دارد که نسبت به روش‌های توسعه سنتی ROI بسیار سریع‌تر ایجاد کند، زیرا نرم‌افزار کارکننده "working software" می‌تواند خیلی زود به مشتریان تحویل داده شود. با هر اسپرینت، تیم‌های اسکرام ویژگی‌های بیشتری ایجاد می‌کنند که می‌تواند منجر به رشد درآمد شود.

3. جابجایی سرمایه (Capital Redeployment)
بازتخصیص سرمایه، اگر ارزش ادامه پروژه را داشته باشد، یا اگر ارزش اقتصادی پروژه از هزینه های آن بیشتر باشد، قابل اندازه گیری می باشد. در این مورد، تیم باید به پروژه‌های سودآورتر دیگری اساین شود.

برای تعیین توزیع مجدد سرمایه، ارزش درآمد ایتم های بکلاگ پروژه (project backlog)، هزینه واقعی (actual cost) اسپرینت های مورد نیاز برای تکمیل آن موارد و هزینه فرصت (opportunity cost) کار محصول جایگزین را که تیم می تواند انجام دهد را باید محاسبه کنید. برای انجام این کار:

V = ایتم های بکلاگ پروژه (project backlog)

AC = هزینه واقعی (actual cost)

OC = هزینه فرصت (opportunity cost)

 هنگامی که V <AC + OC، پروژه باید پایان یابد و اعضا تیم برای پروژه های دیگر درنظر گرفته شوند.

4. رضایت مشتری (Customer Satisfaction)
چندین معیار شناخته شده برای سنجش رضایت مشتری وجود دارد. یکی از آنها امتیاز خالص پروموتر ( Net Promoter Score - NPS) است، که اندازه گیری می کند آیا کاربران نرم افزار را به دیگران توصیه می کنند یا کاری انجام نمی دهند یا مخالف آن را توصیه می کنند. استفاده از معیار رضایت مشتری ثابت و اندازه‌گیری آن برای هر نسخه، نشان می‌دهد که آیا تیم اسکرام به هدف نهایی خود یعنی ارائه ارزش به مشتریان دست می‌یابد یا خیر.

معیارهای اسکرام - نظارت بر تیم اسکرام

این معیارها می تواند به تیم اسکرام کمک کند تا بر فعالیت خود نظارت کند و مشکلات را زودتر شناسایی کند، قبل از اینکه روی توسعه تأثیر بگذارد:

1. دیلی و رترو
این دو رویداد اسکرام، اگر به طور منظم با نتیجه گیری های مستند سازی شده انجام شوند، می توانند اندازه گیری کیفی مهمی از پیشرفت تیم و سلامت فرآیند ارائه دهند.

2. رضایت تیم (Team Satisfaction)
بررسی دوره ای تیم اسکرام برای مشاهده میزان رضایت آنها از کار خود می تواند سیگنال های هشدار دهنده ای در مورد مسائل فرهنگی، تضادهای تیمی یا مسائل فرآیند ارائه دهد.

3. عملکرد اعضای تیم (Team Member Turnover)
فعالیت کم (جایگزینی اعضای تیم) در تیم اسکرام نشان دهنده یک محیط سالم است، در حالی که فعالیت زیاد می تواند برعکس آن را نشان دهد. همچنین این معیار را عملکرد کلی شرکت مقایسه کنید، که می تواند بر تیم اسکرام تأثیر بگذارد.

کدام معیارها را به ذینفعان گزارش کنیم؟

مهمترین چیزی که ذینفعان باید در مورد پروژه اسکرام شما بدانند این است که آیا در مسیر درست قرار دارد یا خیر. معیارهای زیر ممکن است به ارتباط این موضوع کمک کند و انحرافات از مسیر پروژه مورد انتظار را توضیح دهد:

• Sprint and Release Burdown - به ذینفعان دیدی از پیشرفت شما در یک نگاه می دهد.
• سرعت اسپرینت (Sprint velocity) - مروری تاریخی از میزان ارزشی که ارائه کرده‌اید.
• تغییر دامنه (Scope change) - تعداد داستان‌هایی که در طول انتشار به پروژه اضافه می‌شوند، که اغلب دلیل تأخیر است (بسیاری از ابزارهای چابک می‌توانند این را به طور خودکار نشان دهند).
• ظرفیت تیم (Team capacity) - چند توسعه دهنده تمام وقت در تیم هستند؟ آیا ظرفیت کاری تحت تأثیر تعطیلات یا مرخصی استعلاجی قرار گرفته است؟ توسعه دهندگان به پروژه های جانبی کشیده شدند؟
• نقص های دیده نشده (Escaped defects) - تصویری از عملکرد نرم افزار شما در تولید ارائه می دهد.

متریک های از دست رفته  - کیفیت نرم افزار
یک چیز در تمام معیارهای اسکرام که ما پوشش دادیم کم بود - کیفیت نرم افزار. معیارهای عیوب دیده نشده "escaped defects metrics" به تنهایی دیدی از کیفیت را ارائه می دهند و این یک معیار ناقص است که مسائل کیفیت را تنها پس از عرضه به تولید شناسایی می کند.

کیفیت برای پروژه های اسکرام بسیار مهم است. داستان‌های تکمیل‌شده ارزشی ارائه نمی‌کنند مگر اینکه آزمایش شوند و همانطور که مشتری انتظار دارد کار کنند. ابزار موجود فقط آمارهای پراکنده مانند پوشش تست واحد"unit test"  و تعداد تست‌های اجرا شده را ارائه شده - تصویر خوبی از وضعیت کلی کیفیت ارائه نمی‌کند.

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

مترجم و نویسنده: علی امینی

منبع

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

User Story Life Cycle چیست ؟

معرفی 16 کتاب آموزشی اسکرام

User Story چیست ؟