در نظر داریم که به مهم ترین مسائل در این خصوص بپردازیم.
- کمی عقب ماندگی وجود دارد و برنامه ریزی مناسب نیست
تیم های چابک نسبتاً سریع متوجه می شوند که آلوده شدن کار های عقب مانده با هر ایده، درخواست یا مسئله فنی، فقط کار را برای صاحب محصول، استاد ارشد و تیم دشوارتر می کند. اگر تیم ها حجم انبوهی از کارهای مختلف را در ابزارهای چابک خود حفظ کنند، باید از تگ ها یا برچسب ها برای فیلتر کردن اولویت های کوتاه مدت در مقابل اولویت های بلند مدت استفاده کنند. - اسپرینت و اتمام آن از تعهدات عقب می افتد
تعهدات یک پیش بینی است و انتظار اینکه تیمها به طور مداوم اهداف خود را برآورده یا از آن عبور کنند واقع بینانه نیست. وقتی تیم های توسعه چابک متعهد می شوند که انتظارات کاربر را برآورده کنند، باید بتوانند با ناشناخته ها در مورد پیاده سازی، وابستگی به تیم و فرضیات فناوری مواجه شوند. - اسپرینت ها بدون دموی مناسب با حضور کامل اعضا به پایان می رسند
دستور کار جلسه بررسی اسپرینت نمایش قسمت های تکمیل شده کاربر برای صاحب محصول و ذینفعان و جمع آوری بازخورد اولیه است. نقد و بررسی Sprint باید به خوبی برگزار شود و تیم ها چیزهای زیادی برای نمایش داشته باشند. - نقص در حال افزایش در تولید یافت می شود
بسیاری از تیم های توسعه دهنده چابک آزمایش را به صورت خودکار انجام می دهند، خطوط لوله CI / CD را پیکربندی می کنند و زیرساخت ها را به عنوان کد برای بهبود قابلیت اطمینان انتشار و استقرار بیشتر تغییرات تولید گسترش می دهند. استقرار مکرر منطقی است تا زمانی خلاف آن ثابت شود. یک شاخص واضح که تیم های توسعه چابک به طور مکرر در حال استقرار هستند، این است که نقص در حال رشد در تولید وجود دارد. - تیم های چابک یا ذینفعان آنها راضی نیستند
مهمترین عامل برای در نظر گرفتن تغییرات این است که تیم چابک یا ذینفعان آنها راضی نباشند.
از دست دادن یک اسپرینت یا حتی انتشار آن نباید دلیلی برای هشدار باشد، اما رهبران باید روش هایی را برای گرفتن بازخورد به طور رسمی تعریف کنند. گفتگوهای یک به یک مفید است، اما سازمان های بزرگتر باید رضایت مشتری و نظرسنجی های هم تیمی چابک را در نظر بگیرند.
بیشتر بدانید: https://lnkd.in/dnPzyA4
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.