تیم بک لاگ

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

• این شامل تمام کارهای یک تیم چابک برای پیشبرد راه حل است و همه اعضای تیم را با یک هدف مشترک هماهنگ می کند.
• این فهرستی از خواسته ها است، نه تعهدات. موارد را می توان تخمین زد (ترجیحا) یا خیر، اما این فقط یک لیست سفارشی است و هیچ تعهد زمانی خاصی برای تکمیل وجود ندارد. به عبارت دیگر، عقب ماندگی مستقل از زمان است و به تیم انعطاف‌پذیری کلی در مورد اینکه چه چیزی و چه زمانی اجرا می‌شود، می‌دهد.
• همه اعضای تیم می‌توانند استوری‌ها را در بک لاگ وارد کنند.
• مالکی دارد – مالک محصول (PO) – که به تیم کمک می کند تا چالش چند ذی نفع را مدیریت کند که ممکن است دیدگاه های متفاوتی در مورد آنچه ضروری است داشته باشندPO، با نظرات تیم و سایر ذینفعان، مسئول اصلی ایجاد و حفظ عقب ماندگی تیم است.
  با این حال، هر عضو تیم می‌تواند یک مورد را برای بررسی وارد کند. (PO) کارهای عقب مانده را اولویت بندی می کند و نیازهای ذینفعان را متعادل می کند. همانطور که شکل ۱ نشان می دهد، سه ورودی اصلی برای عقب ماندگی تیم وجود دارد.

شکل ۱. منابع ورودی برای تیم بک لاگ

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

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

ساخت و پالایش بک لاگ

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

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

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

مدیریت بک لاگ با کانبان

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

متعادل کردن تحویل ارزش و سلامت سیستم با تخصیص ظرفیت

مانند ای آر تی، هر تیم چابک با مشکل ایجاد تعادل در کار داخلی – تعمیر و نگهداری، بازسازها و بدهی های فنی – با داستان های کاربر جدید که ارزش تجاری فوری تری را ارائه می دهند، مواجه است. در حالی که تمرکز صرفاً بر روی عملکرد تجاری ممکن است برای مدتی کارساز باشد، این رویکرد با افزایش بدهی فنی کوتاه مدت خواهد بود و در نهایت سرعت توسعه را کاهش می دهد. اجتناب از این خطر مستلزم سرمایه گذاری مستمر در توسعه باند معماری راه حل است و در عین حال مشتریان را با پیشرفت ها، عملکردهای جدید و رفع اشکال خوشحال می کند. درست کردن این تعادل عمر سیستم را افزایش می دهد و منسوخ شدن فنی را به تعویق می اندازد. اما اولویت بندی انواع مختلف کار می تواند چالش برانگیز باشد زیرا (PO) سعی می کند ارزش چیزهای متفاوت را با هم مقایسه کند: نقص‌ها، اصلاح‌کننده‌ها، طراحی‌های مجدد، ارتقاء فناوری و داستان‌های کاربران جدید. و هیچ حد بالایی برای تقاضا برای هیچ یک از این چیزها وجود ندارد. با همکاری تیم، (PO) تخصیص ظرفیت (شکل ۳) را برای هر نوع کالا اعمال می کند. سپس (PO)، تیم و معمار سیستم در طول برنامه ریزی، موارد با بالاترین اولویت را برای هر بخش تخصیص ظرفیت انتخاب می کنند. از آنجایی که بسیاری از داستان ها از ویژگی ها سرچشمه می گیرند، تعهدات برنامه ریزی (PI) ممکن است برخی از اولویت ها را از پیش تعیین کند. این حال، (PO) می تواند با مقایسه ارزش، اندازه و توالی منطقی، کار را از بافت محلی تیم اولویت بندی کند. همچنین، (PO) می‌تواند درصد تخصیص را برای هر نوع مورد کاری تنظیم کند تا سلامت سیستم و تحویل ارزش بلندمدت را بررسی کند. تیم ها باید دسته های تخصیص ظرفیت را در صورت نیاز تطبیق دهند. با این حال، این دسته بندی ها باید در بین تیم های ای آر تی سازگار باشند.

مدیریت بک لاگ با کانبان

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

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

شکل ۲. صفحه اولیه کانبان One Agile Team

متعادل کردن تحویل ارزش و سلامت سیستم با تخصیص ظرفیت

مانند ای آر تی، هر تیم چابک با مشکل ایجاد تعادل در کار داخلی – تعمیر و نگهداری، بازسازها و بدهی های فنی – با داستان های کاربر جدید که ارزش تجاری فوری تری را ارائه می دهند، مواجه است. در حالی که تمرکز صرفاً بر روی عملکرد تجاری ممکن است برای مدتی کارساز باشد، این رویکرد با افزایش بدهی فنی کوتاه مدت خواهد بود و در نهایت سرعت توسعه را کاهش می دهد. اجتناب از این خطر مستلزم سرمایه گذاری مستمر در توسعه باند معماری راه حل است و در عین حال مشتریان را با پیشرفت ها، عملکردهای جدید و رفع اشکال خوشحال می کند. درست کردن این تعادل عمر سیستم را افزایش می دهد و منسوخ شدن فنی را به تعویق می اندازد.
اما اولویت بندی انواع مختلف کار می تواند چالش برانگیز باشد زیرا (PO) سعی می کند ارزش چیزهای متفاوت را با هم مقایسه کند: نقص‌ها، اصلاح‌کننده‌ها، طراحی‌های مجدد، ارتقاء فناوری و داستان‌های کاربران جدید. و هیچ حد بالایی برای تقاضا برای هیچ یک از این چیزها وجود ندارد. با همکاری تیم، (PO) تخصیص ظرفیت (شکل ۳) را برای هر نوع کالا اعمال می کند.
سپس (PO)، تیم و معمار سیستم در طول برنامه ریزی، موارد با بالاترین اولویت را برای هر بخش تخصیص ظرفیت انتخاب می کنند. از آنجایی که بسیاری از داستان ها از ویژگی ها سرچشمه می گیرند، تعهدات برنامه ریزی (PI) ممکن است برخی از اولویت ها را از پیش تعیین کند. با این حال، (PO) می تواند با مقایسه ارزش، اندازه و توالی منطقی، کار را از بافت محلی تیم اولویت بندی کند. همچنین، (PO) می‌تواند درصد تخصیص را برای هر نوع مورد کاری تنظیم کند تا سلامت سیستم و تحویل ارزش بلندمدت را بررسی کند. تیم ها باید دسته های تخصیص ظرفیت را در صورت نیاز تطبیق دهند. با این حال، این دسته بندی ها باید در بین تیم های ای آر تی سازگار باشند.

شکل ۳. نمونه های معمولی از دسته های تخصیص ظرفیت (داستان های کاربر، توانمندسازها و نگهداری در این مورد)

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