پنج معیار چابک که از آن متنفر نخواهید شد

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

توسط دن رادگان

مباحث را مرور کنید

بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت بازگشت

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

معیارها موضوعی لمس کننده هستند.

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

اما لازم نیست اینگونه باشد. ردیابی و به اشتراک گذاری معیارهای چابک صدا می تواند باعث کاهش سردرگمی و درخشش در پیشرفت تیم (و مشکلات) در طول چرخه توسعه شود. در اینجا چگونه است.

کسب و کار خود را بدانید

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

"معیارهای تجاری یک برنامه باید ریشه در نقشه راه آن داشته باشد."

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

نحوه استفاده از معیارهای چابک برای بهینه سازی تحویل خود

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

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

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

• این تیم زود هنگام اسپرینت را به پایان رساند زیرا آنها به کار کافی متعهد نیستند.
• این تیم بعد از Sprint پیش بینی خود را از دست می دهد زیرا آنها به کار زیادی متعهد هستند.
• خط Budown باعث می شود قطره های شیب دار به جای سوختگی تدریجی تر ، زیرا کار به قطعات دانه ای شکسته نشده است.
• صاحب محصول دامنه میانه را اضافه یا تغییر می دهد.

حماسه و انتشار برند

نمودارهای Dudown Epic and Release (یا نسخه) پیشرفت پیشرفت را بر روی بدنه بزرگتر از کار با Sprint Budown دنبال می کنند و برای تیم های Scrum و Kanban راهنمای را راهنمایی می کنند. از آنجا که ممکن است یک اسپرینت (برای تیم های Scrum) شامل چندین حماسه و نسخه باشد ، پیگیری پیشرفت هر دو اسپرینت های فردی و همچنین حماسه ها و نسخه ها مهم است.

"Cope Creep" تزریق نیازهای بیشتر به یک پروژه قبلاً تعریف شده است. به عنوان مثال ، اگر تیم وب سایت جدیدی را برای شرکت ارائه می دهد ، Scope Creep پس از ترسیم الزامات اولیه ، از ویژگی های جدید درخواست می کند. در حالی که تحمل خزش دامنه در حین یک تمرین بد است ، تغییر دامنه در حماسه ها و نسخه ها یک نتیجه طبیعی توسعه چابک است. با حرکت تیم از طریق پروژه ، صاحب محصول ممکن است تصمیم بگیرد که کار را بر اساس آنچه یاد می گیرد ، انجام دهد یا حذف کند. نمودارهای سوختگی حماسه و انتشار ، همه را از آب و هوا و جریان کار در حماسه و نسخه آگاه می کند.

• پیش بینی های حماسه یا انتشار به روز نمی شود زیرا تیم در طول کار خفه می شود.
• هیچ پیشرفتی در یک دوره از چندین تکرار حاصل نمی شود.
• خزش دامنه مزمن ، که ممکن است نشانه این باشد که صاحب محصول مشکلی را که بدنه کار در تلاش است تا حل کند ، کاملاً درک نمی کند.
• دامنه سریعتر از آنکه تیم بتواند آن را جذب کند رشد می کند.
• این تیم در طول توسعه حماسه ، نسخه های افزایشی را حمل نمی کند.

سرعت

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

بیایید بگوییم که صاحب محصول می خواهد 500 نکته داستان را در پشت پرده تکمیل کند. ما می دانیم که تیم توسعه به طور کلی 50 امتیاز داستان را در هر تکرار تکمیل می کند. صاحب محصول می تواند به طور منطقی فرض کند که تیم برای تکمیل کار مورد نیاز به 10 تکرار (دادن یا گرفتن) نیاز دارد.

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

ضد الگوی برای تماشای

هنگامی که سرعت در مدت زمان طولانی نامنظم است ، همیشه شیوه های تخمین تیم را مجدداً مورد بررسی قرار دهید. در طول گذشته نگر تیم ، سوالات زیر را بپرسید:

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

سرعت هر تیم بی نظیر است. اگر تیم A سرعت 50 و تیم B دارای سرعت 75 باشد ، به این معنی نیست که تیم B از توان بالاتری برخوردار است. از آنجا که فرهنگ تخمین هر تیم بی نظیر است ، سرعت آنها نیز خواهد بود. در برابر وسوسه مقایسه سرعت در تیم ها مقاومت کنید. سطح تلاش و خروجی کار را بر اساس تفسیر منحصر به فرد هر تیم از نقاط داستان اندازه گیری کنید.

نمودار کنترلی

نمودارهای کنترل بر زمان چرخه مسائل فردی متمرکز شده اند - کل زمان از "در حال انجام" تا "انجام شده". تیم هایی که زمان چرخه کوتاه تر دارند احتمالاً از توان بیشتری برخوردار هستند و تیم هایی با زمان چرخه مداوم در بسیاری از موضوعات در ارائه کار قابل پیش بینی تر هستند. در حالی که زمان چرخه یک معیار اصلی برای تیم های Kanban است ، تیم های Scrum نیز می توانند از زمان بهینه سازی چرخه نیز بهره مند شوند.

اندازه گیری زمان چرخه روشی کارآمد و انعطاف پذیر برای بهبود فرآیندهای تیم است زیرا نتایج تغییرات تقریباً بلافاصله قابل تشخیص است و به آنها امکان می دهد بلافاصله تنظیمات بیشتری انجام دهند. هدف نهایی صرف نظر از نوع کار (ویژگی جدید ، بدهی فنی و غیره) ، زمان چرخه مداوم و کوتاه است.

ضد الگوی برای تماشای

نمودارهای کنترل در ابتدا می توانند ناخوشایند به نظر برسند. اینقدر نگران هر چیز دیگری نباشید. به دنبال روندها باشید. در اینجا دو حوزه برای تماشای آنها وجود دارد:

• افزایش زمان چرخه - افزایش زمان چرخه ، تیم چابکی سخت درآمد خود را کاهش می دهد. در تیم گذشته نگر ، برای درک افزایش وقت بگذارید. یک استثنا: اگر تعریف تیم از Done گسترش یافته باشد ، احتمالاً زمان چرخه نیز گسترش می یابد.
• زمان چرخه نامنظم - هدف این است که زمان چرخه مداوم را برای موارد کار داشته باشید که دارای مقادیر مشابه داستان هستند. نمودار کنترل را برای هر مقدار نقطه داستان فیلتر کنید تا قوام را بررسی کنید. اگر زمان چرخه در مقادیر داستان کوچک و بزرگ داستان نامنظم است ، در گذشته نگر در بررسی اشتباهات و بهبود برآورد آینده ، وقت خود را صرف کنید.

نمودار جریان تجمعی

نمودار جریان تجمعی باید از چپ به راست صاف (ISH) به نظر برسد. حباب یا شکاف در هر رنگ نشانگر کمبود و تنگناها است ، بنابراین وقتی یکی را می بینید ، به دنبال راه هایی برای صاف کردن باند های رنگی در نمودار باشید.

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

حتی معیارهای بیشتر

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

• چه تعداد نقص یافت می شود:
  • در طول توسعه؟
  • بعد از آزادی به مشتریان؟
  • توسط افراد خارج از تیم؟

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

  بینش را در متن پیدا کنید

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

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

  • پیشرفت اسپرینت
  • مشکل تجزیه
  • تعهد اسپرینت
  • فراوانی استقرار
  • زمان چرخه

  از این معیارها برای بهینه سازی مداوم عملکرد تیم استفاده کنید. درباره بینش بیشتر بدانید.

  در نتیجه.

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

  این مقاله را به اشتراک بگذارید

  

  دن رایدیگان

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

  مورد بحث

  تصمیمات محور داده را بگیرید و ارزش بیشتری را به مشتریان تحویل دهید