تجاربی از اسکرام

همان طور که می‌دانید اسکرام یکی از متودولوژی‌های جدید توسعه نرم‌افزار از خانواده Agile است. این روش مزایای زیادی، اقلاً برای ما، دارد و روز به روز رواج بیشتری در دنیا پیدا می‌کند. ما هم در مدت اخیر تصمیم گرفتیم از این روش برای یکی دو تا از پروژه‌های جدید استفاده کرده و مزایا و معایبش را به طور عملی لمس کنیم. یکی از این پروژه‌ها، پروژه‌ی کوچکی با ASP.NET بود که تعداد افراد درگیر با آن چه در نقش برنامه‌نویس چه در نقش Product Owner کمتر از ۵ نفر بوده و انجام فاز اول آن چیزی حدود ۱۰ هفته طول کشید. انجام این پروژه با اسکرام برای من که اسکرام را با کتاب Scrum and XP from the Trenches یاد گرفته بودم نکات و تجاربی را با خود به همراه داشت که ذیلاً می‌آیند:

۱- قوانین اسکرام برای غربی‌های منظم نوشته شده نه کشورهایی مثل ما. در نتیجه نمی‌توان از مثلاً افرادی مثل Product Owner انتظار داشت همیشه فهرست PBIهایش را به طور کامل و منظم به همراه داشته باشد.

۲- Self Organized بود تیم در اسکرام خیلی مورد توجه قرار گرفته ولی عموماً ایرانی‌ها عادت دارند یک نفر همیشه کارهایشان را به آنها یادآوری کرده و یک نفر دیگر انجام آن کارها را مدام چک کند. ضعف این خصیصه در افراد برنامه‌نویس خیلی از کیفیت کار در اسکرام کم می‌کند.

۳- روی برنامه و اصول پیش رفتن در نظر خیلی افراد یک کار لوکس (قرتی‌بازی) به نظر می‌رسد. مثلاً شکستن یک PBI به چند Task و یادداشت آن در Task Board یکی از آن کارهاست.

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

۵- ایرانی‌ها به طور کلی عاشق Customize کردن هستند. مثلاً دوست دارند موتور پیکان را روی بدنه پژو بگذارند و به اسم پژو آر-دی به بازارا بفرستند. یا این که مدام در فکر بومی‌سازی علوم و فناوری خارجی بپردازند. متاسفانه اسکرام هم از این قاعده سرطانی مستثنی نیست و افراد عاشق دستکاری قوانین آن هستند. مثلا در اسکرام گفته شده طول اسپرینت‌ها باید یکسان باشد ولی ما هم اسپرینت‌های یک هفته‌ای داشتیم و هم اسپرینت‌های دو هفته‌ای.

۶- …

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

‫Agile و استفاده از آن

اگر بخواهیم Agile را خیلی ساده و بدون استفاده از لغات دقیق و فنی و مرزبندی‌های مربوطه تعریف کنیم، آن وقت Agile یعنی یک نوع روش تولید نرم‌افزار که در آن عمده توجه به انعطاف‌پذیری تیم تولید در پذیرش تغییرات مداوم نیازمندی‌های اولیه نرم‌افزار است. این انعطاف‌پذیری در اثر iterative و incremental بودن این روش به وجود آمده است.

Agile در مجموعه مفاهیم مهندسی نرم‌افزار، هم‌خانواده مفاهیمی مثل RUP و SSADM است با این توضیح که این سال‌ها هم‌زمان با پیشرفت بحث‌های شی‌گرایی، Agile هم حسابی رواج پیدا کرده و در خیلی از پروژه‌ها جای RUP را گرفته است. Agile در مقایسه با متودولوژی‌هایی مثل RUP که predictive هستند، با اصطلاح adaptive توصیف می‌شود. adaptive یعنی این که روش مورد نظر می‌تواند خودش را به راحتی با تغییرات نیازمندی‌های تطبیق دهد. درست به همین دلیل هم است که نمی‌توان روند پیشرفت پروژه‌های Agile را با دقت پیش‌بینی کرد. از سویی دیگر روش‌هایی مثل RUP انطباق‌پذیری کمتری دارند ولی در مقابل چون تغییرات کمی دارند به خوبی predictive (قابل پیش‌بینی) هستند. Agile فقط شامل Scrum و XP نمی‌شود بلکه هر روشی را که با مانیفست Agile مطابقت داشته باشد را می‌توان Agile نامید، از جمله روش‌هایی که توسط مایکروسافت و بقیه ارائه شده‌اند.

به نظر می‌رسد Agile (با تکیه بر Scrum/XP) با همه راحتی‌هایی که دارد، برای اجرا در شرکت‌های ایرانی دچار مشکلات خاصی هم بشود:
۱- Agile اشتباهاً زیادی لوکس به نظر می‌رسد. مدیران شرکت‌ها دید خیلی خوبی نسبت به تشریفات آن نداشته و فکر می‌کنند یک جور کار غیر ضروری است. مثلاً Standingها (جلسات سرپایی مرور) یکی از آن موارد است.
۲- Agile اشتباهاً بی‌نظم و بی‌برنامه به نظر می‌رسد، چون Agile یک روش Adaptive است و نمی‌توان طرح‌های کاملاً دقیقی از روند پیشرفت کار ارائه داد. این موضوع می‌تواند بهانه خوبی در دست مخالفان Agile باشد. خصوصاً آنها که عاشق Gantt chart هستند. این طور افراد با اعمال گانت چارت و عدم تغییر گانت چارت عملاً Agile را از یک روش iterative و incremental به یک روش آبشاری مثل SSADM تبدیل می‌کنند.
۳- Agile اشتباهاً غیر مستند به نظر می‌رسد. بله درست است که Agile نسبت به روش‌هایی مثل RUP مستندات کمتری تولید می‌کند ولی این به خاطر تمرکز بیشتر بر ارائه خود محصول است نه بی‌اهمیتی آن نسبت به documentation.‏
۴- پایبندی به Agile اشتباهاً سخت به نظر می‌رسد. در Scrum که یکی از رایج‌ترین روش‌های Agile است، همه افراد تیم ملزم به تطبیق خود با بازه زمانی ۲ تا ۴ هفته‌ای به نام sprint هستند. در هر sprint ممکن است اولویت کارها عوض شود و taskهایی که در sprintهای قبلی با جدیت دنبال می‌شد کنار گذاشته شوند. در جلسات مابین sprint احتیاج به حضور و تعامل جدی نماینده کارفرما (product owner) هست. این‌ها باعث می‌شود تا بعضی افراد فکر کنند اجرای Scrum خیلی سخت است. ولی خوشبختانه واقعیت این است که با تعهد به این وظایف محصولی بهتر در زمانی کمتر تولید خواهد شد.

————–
منبع: مقالات و نوشته‌های مربوط به Agile و Scrum در ویکی‌پدیا و StackOverflow