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

این مطلب به درد چه کسی می خورد؟

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

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

تخمین

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

تخمین در تیم های برنامه نویسی

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

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

تخمین در تیم های گرافیکی

تخمین در تیم های گرافیکی، به خاطر ذات کارهای گرافیکی که نیاز به بررسی های مجدد و به اصلاح روتوش شدن کار بعد از پیاده سازی دارد، به راحتی در سیستم Scrum و Story point جا نمی گیرد. برای همین راه پیشنهادی من در ابتدا Scrumban یا در واقع استفاده از Kanban در کنار Scrum بود. این روش به نظر جواب گو بود اما بعد از مدتی متوجه شدیم، این روش هم با وجود تمام آزادی عمل هایش نمی تواند مفید باشد، چرا که کارها هنوز در چهارچوب مشخصی جا نمی شد و قابل پیش بینی نبود، در نهایت روشی که تقریبا جواب گو بود، چیزی شبیه به کاری بود که در تیم برنامه نویسی انجام شد، اضافه کردن زمان لازم برای روتوش و اصلاح مجدد تسک های گرافیکی به صورت ضمنی. در واقع گرافیست ما با در نظر گرفتن زمان کلی سپرینت و تجربه ی قبلی، زمان کلی برای نهایی کردن کار را، کاری که آماده برای ارایه به مشتریست، در نظر می گرفت و با توجه به این زمان برای سپرینت تسک انتخاب می کرد.

ادامه

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

hossein.ataeefard@gmail.com