زمانیکه به اولین تجربه خودم در مورد اسکرام فکر می کنم , حسابی خنده ام می گیره . اسکرامی که من برای اولین بار یاد گرفتم و آن را درشرکت بر روی یک پروژه پیاده سازی کردم , اصلا اسکرام نبود . اسکرام ما کلا به یک Task Board من در آوردی ختم می شد . از جمله اشتباهاتی که در مورد اسکرام داشتم , می توانم به موراد زیر اشاره کنم :
- Top-Down Management : همانطور که می دانید یکی از اصول اصلی در Agile و اسکرام Self-Organize بودن نیروی کار(برنامه نویس) می باشد که ما به هیچ وجه چنین اجازه ای به نیروی کار نمی دادیم و شیوه Command-And-Control را با بدترین حالت ممکن به کار می بستیم .
- طرح ریزی تیمی : به دلیل وجود مدیریت بالابه پایین , این مورد هم که امکان نداشت انجام شود . یعنی بنده همه چیز رو طرح ریزی می کردم و به تیم تزریق می کردم که در محیط های چابک بدینگونه عمل نمی شود .
- تکرارهای کوتاه مدت : در اسکرام که حداکثر طول اسپرینت 4 هفته هست , ما اسپرینت 3 ماهه داشتیم .
- بازبینی عملکرد : بازبینی عملکرد تیم پس از هر اسپرینت طی جلسه retrospective تقریبا امری است ضروری که ما , سال به سال چنین کاری رو انجام نمی دادیم .
- همکاری با مشتری : همکاری ما خوب بود ولی مشکل ما این بود : ما باید یک نفر را به عنوان Product Owner داشتیم در حالی که ما 400 نفر Product Owner داشتیم . خاله مدیر شرکت هم نظر می داد .
- ارائه نرم افزار کارا : یکی از ارزش های اصلی Agile ارائه نرم افزار ارزشمند برای مشتری است به صورتی که نیازهای کسب و کار مشتری را برآورده کند ولی ما فقط در فکر سود و منفعت بیشتر برای شرکت بودیم و کاری نداشتیم که مشتری استفاده می کند یا نه .
- با انگیزگی تیم : برای توسعه نرم افزار خوب در محیط Agile حتما نیاز به نیروی کار با انگیزه بود ولی در محیط ما چیزی که وجود نداشت انگیزه بود . اعتصاب های گوناگون , تاخیر در پرداخت حقوق , تورم , سهمیه شده بنزین و … از عوامل کاهنده انگیزه نیروی کار بود .
- تست نرم افزار : یکی از کارهایی که هیچ وقت انجام نشد , نوشتن تست برای بخش های مختلف برنامه بود .
- تولید کدهای خوب : بدلیل عدم وجود Automate Tests و تغییرات زیاد در طول پروسه توسعه نرم افزار , ما در نهایت دارای یک سری کد کثیف بودیم .
- جوابگویی به تغییرات : یکی از مشکلات اساسی ما همین مورد بود . یا ما جواب نمی دادیم و اگر هم جواب می دادیم در دام Scope Creep می افتادیم . کدهای کثیف تولید می شد , برنامه قابلیت پشتیبانی را از دست می داد .
- و …
اگر اهل فن باشید حتما خواهید دانست که مشکل ما در دو سطح متفاوت قابل بحث می باشد . اول سطح اسکرام دوم سطح Agile . اولا مشکل ما این بود که اسکرام را کاملا بلد نبودیم ( در آن زمان منابع زیادی برای یادگیری وجود نداشت (چه انگلیسی و چه فارسی ) ) . ثانیا ربط اسکرام با Agile را درک نکرده بودیم . بی تعارف عرض کنم که ما اسکرام را یاد گرفته بودیم بدون اینکه بدانیم Agile چیست و از آن استفاده می کردیم؟؟!
برای همین است که یکی از دغدغه های من در این وبلاگ و یا آموزش این است که Scrum فقط Scrum نیست . اگر Scrum در خدمت Agile نباشد معنی نخواهد داشت و پیشنهاد من این است که برگردیم به متد قبلی که قبلا کار میکردیم . پس در آموزش خود سعی کنید که از Agile به سمت اسکرام حرکت کنید .
البته یادگیری اسکرام چیزی نیست , شاید در عرض 2 ساعت بتوانید کل اسکرام را یاد بگیرید . ولی درک و یادگیری Agile ومهمتر از همه , پیاده سازی تفکر Agile کاری است بس مشکل که با خواندن 1 عدد کتاب یا چند مقاله امکان پذیر نخواهد بود. پس اسکرام فقط اسکرام نیست و برای استفاده از آن باید Agile را هم درک کرده باشید .
یاشیاسیز
درست همین دیروز اولین اسپرینت ما به طور کامل پایان یافت و من متاسفانه در دو مورد اول به نتیجه کاملا عکس رسیدم. به طوری که تصمیم گرفتم در اسپرینت دوم از مفهوم self organized استفاده نکنم و همه Back Log Itemها را بررسی کرده و خودم تنهایی آنها را به Taskهای ریزتر بشکنم.
احتمال میدم چند تا اسپرینت بعدی کلا اسکرام رو بذارید کنار (:
در کارهایی که انجام می دید با دقت عمل بکنید تا بعدا پشیمان نشید . شاید یک تصمیم اشتباه ما (به عنوان کسی که در مورد نحوه عملکرد تیم , تصمیم گیرنده هستیم) منابع یک شرکت و یا سازمان را تلف بکند که از نظر انسانی و یا حرفه ای درست نیست ; البته من نمی توانم تصمیم شما را درست و یا نادرست بدانم ولی امیدوارم که اشتباه نکرده باشید .
موفق باشید