برنامه ریزی اسپرینت و چالش ها(2)

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

برای برنامه ریزی مالک محصول با دو تا متغیر طرف است که متغیر اول ظرفیت تیم توسعه و متغیر دوم حجم کار های مورد نیاز برای تکمیل استوری ها می باشد.در اول هر اسپرینت مالک محصول با در نظر گرفتن این دو متغیر یک پیشبینی از Release محصول یا فیچر های آن به مدیران بالا دستی ارائه می کند.حال بگذریم که در جامعه چابک اختلاف نظر های زیادی درباره دادن پیشبینی یا Forecast وجود دارد که موضوع این مطلب نمی باشد.

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

برای حل این چالش راهکار های مختلفی را می توان پیشنهاد داد.شاید ساده ترین راهکار تغییر ظرفیت کاری تیم توسعه می باشد.معمولا در تیم های چابک دیده می شود که ظرفیت کاری هر فرد بین 4 تا 6 ساعت در روز درنظر گرفته می شود،در حالی که افراد 8 یا 9 ساعت کاری را در شرکت سپری می کنند.در حقیقت با این روش یک شناوری برای فعالیت ها در نظر گرفته می شود تا بتوان برنامه ریزی را محقق کرد.البته باید در نظر گرفت که اجرای این راهکار باید متناسب با فرهنگ کاری شرکت و مدیران باشد.مدیران ممکن است تصور کنند که تیم توسعه از نیمی از ظرفیت خود دارد استفاده می کند و به عبارت درگیر کم کاری شده است.

شاید صورت بهتر این راهکار به این شکل باشد.از 8 ساعت کاری تیم توسعه 5 ساعت به توسعه محصول جدید اختصاص داده شود و 3 ساعت باقی مانده به فعالیت هایی از جنس پشتیبانی و رفع مشکلات اختصاص داده شود.قاعدتا برنامه ریزی توسعه نیز بر اساس همان 5 ساعت مطرح شده است.

برای حل بهتر این چالش باید برای هر یک از عوامل مطرح شده در مطلب قبلی یک نسخه ارائه داد که امیداوارم سودمند باشه.

1و 3-در مواردی که زمان واقعی اجرای تسک طولانی تر از پیشبینی شده، می شود یا تسک هایی را برای اجرای یک استوری در نظر نگرفته ایم،باید به سراغ تیم فنی بریم.در حقیقت این افراد تیم توسعه هستند که برای تسک های مختلف در ابتدای اسپرینت یک زمان تخمینی می دهند.برای دادن تخمین های دقیق تر ،بهترین راهکار خبرگی و آموزش تیم فنی است.از سوی دیگر خودم سعی می کنم وقتی قراره یک استوری را در هر اسپرینت پیاده سازی کنم در اسپرینت قبلی برای آن استوری یک تسک R&D در نظر بگیرم.با این کار تیم فنی با زوایای پیاده سازی استوری آشنا شده و تخمین های دقیق تری برای آن ارائه می کند.

2-در مواقعی که اتفاق های اضطراری مثل یک باگ به وجود می آید باید از قبل یک شناوری برای پیاده سازی تسک ها در نظر گرفته باشیم.شناوری که طی تجربه این چند وقت داریم در نظر می گیریم حدود 20% زمان است.

امیدوارم این دو مطلب منتشر شده برای شما سودمند بوده باشد.لطفا نظرات و پیشنهادات خودتون را در کامنت ها برام بنویسید.