Agile یکی از متدلوژی های تولید نرم افزار است که دوره های کوتاه مدت و با تعداد زیاد را برای تولید نرم افزار توصیه می کند. همانطور که از اسم آن نیز مشخص است، این متدلوژی می کوشد در حقیقت تیم های چابک بسازد و از بسیاری از کارهای اضافه سایر متدلوژی ها مثل RUP بکاهد. Agile Manifesto در سال 2001 توسط نمایندگان گروه های مختلف مثل Scrum، XP و غیره نوشته شد. نگاهی به اسم کسانی که این مانیفست را نوشته اند بیندازید. Martin Fowler، Kent Beck، Andy Hunt, Dave Thomas ، Robert Martin از جمله بزرگترین افراد دنیای نرم افزار هستند که از خواندن مطالبشان لذت می برم. اینجا بحث من خود متدلوژی نیست بلکه نحوه پیاده شدن آن در محیطی است که قابلیت پذیرش آن را ندارد و بیشتر به یک جوک شبیه می شود.
4 ماه نخست همکاری من با شرکت در تیمی بود که پرچم دار Agile بود. در واقع یک ظاهر پوشالی برای تیمی که در یک سال هیچ خروجی نداشت. بهترین اسمی که می توانم برای کارهای مسخره آن موقع بگذارم Agile Rituals است.
این کارها عبارت بودند از:
- Standup Meeting: یکی از اجزای Scrum که توصیه می کند اعضای تیم در آغاز روز کاری دور هم جمع شوند و به طور خلاصه بگویند که امروز چه کاری می کنند تا با هم هماهنگ شوند. در مورد تیم ما این به یکی از مسخره ترین عادت ها تبدیل شده بود. در اوایل که 8 نفر بودیم کمی اوضاع بهتر بود. هر یک از اعضا یک دقیقه حرف می زد و معمولا کس دیگری نمی فهمید که چه می گوید و خیلی سریع سر و ته این قضیه تمام می شد. در زمان اوج درگیری 15 نفر بودیم و هر کسی 2 تا 3 دقیقه صحبت می کرد و هر روز حداقل نیم ساعت سر پا می ایستادیم. علاوه بر خستگی سر پا ایستادن با اصل Standup Meeting هم مشکل دارم. من متخصص Agile نیستم ولی حس می کنم این قضیه برای تیمی مفید است که اعضایش چند کاره باشند و تکنولوژی و مفاهیمی که سایر اعضا در موردش بحث می کنند را بدانند. در تیم ما که نیمی از اعضا مثل من یک سال سابقه کار دارند و بقیه هیچی و هرکسی روی یک تکنولوژی مجزا کار می کند، Standup Meeting چه معنی دارد: گوش کردن به حرف هایی که نمی فهمیم و صحبت کردن از چیزی که کسی نمی فهمد. به هر حال نظر مدیر پروژه احمق بر این بود که Ritual بدون کم و کاست باید ادامه یابد.
- ساعت کاری 8:30 : این هم یکی دیگر از مسایل احمقانه و روی اعصاب من بود. حس من این است که ساعت کاری ثابت هیچ کمکی به افزایش کارایی و بهبود محصول نهایی نخواهد داشت. فکر می کنم یکی از خصوصیات Agile انعطاف پذیر بودن آن است...
- Sitdown Meeting: بعد از مدتی مدیر پروژه که از نظر خود Agile Master محسوب می شد تصمیم گرفت بعد از ظهر ها پس از پایان ساعت کاری یک جلسه داشته باشیم و بگوییم که در طول روز چه کاری انجام دادیم. به هر حال با استراتژی کلی شرکت که آفتابه لگن هفت دست، شام و ناهار هیچی، مطابقت داشت! تقریبا اکثر زمان را در جلسات می گذراندیم.
- World Class Product: و از همه دردناک تر این کلمه بود. روزی که وارد شرکت شدم یک جلسه داشتیم که در آن اعلام شد که ما می خواهیم یک محصول جهانی داشته باشیم! من پرسیدم چیزی در حد اکلیپس؟ و مدیر پروژه جواب داد بله!
متاسفانه محصول جهانی یک Code Generator تخمی بود که اسمش هم SPL گذاشته بودن و هر روز می زدن تو سر ما که برای ساخت چنین محصولی باید Sitdown و Standup داشته باشیم وگر نه به جایی نمی رسیم. آنقدر ابعاد پروژه تخیلی بود و از همه بدتر ذهن بیمار Agile Master توهم بافته بود که جای هیچ گونه اعتراضی نبود. یک چیزی مثل لباس جدید پادشاه...
و خوب از Unit Testing، Code Review و سایر فعالیت های مفید و اساسی Agile خبری نبود چون اصولا کسی بلد نبود! پروژه خیلی زود تر از انتظار من از هم پاشید. مدیر پروژه یک ماه بعد از جدا شدن من از تیم دوام نیاورد و سپس از شرکت رفت.
آیا واقعا می توان با چند تا فارغ التحصیل دانشگاهی و Agile Practice توسط کسی که خودش فقط دو سال بیشتر از شما تجربه (آن هم مدیریتی و نه برنامه نویسی) دارد محصول جهانی ساخت؟ به نظر من کسانی که حس می کنند با Agile می توانند جای تحلیل، طراحی، برنامه نویس، ساپورت مالی، تست و سایر مولفه های ساخت نرم افزار را بگیرند برای همیشه محکوم به شکست هستند!
عالی بود این پستتون. من هم دقیقا در شرکت با همین مشکل روبرو بودم و نهایتا مثل شما از شرکت جدا شدم. :)
پاسخحذفبسیار پست جالبی بود، متاسفانه تو کشور ما هر کی اسم یه چیزی رو میشنوه فکر میکنه که اونو بلده و توش علامه شده، در ضمن خیلی برام جالب بود که از unit testing و TDD خبری نبوده اونم تو Agile چون Robert C.Martin میگه Agile بدون TDD و unit testing مثل رانندگی تو جاده کوهستانی با چشم بسته است. JESUS CHRIST
پاسخحذفکاملا موافقم که Agile بدون Unit Testing هیچ معنی نداره. موضوع اینه که Unit Testing یک جور طرز فکر و روشه و سالهاطول می کشه تا توی یک فرد و تیم جا بیفته. تمرین standup و sitdonwn برای تیمی که هسته Agile درستی نداره شکل مسخره ای پیدا می کنه. بعضی وقتا بهتره واقع بین باشیم و بدونیم توی ایران با یک تیم معمولی یک محصول معمولی داریم درست می کنیم. کم کم هم روش های مختلف رو تست کنیم و اگر می خواهیم Agile رو وارد کنیم بهتره از Unit Testing و سایر چیزهای پایه ای شروع کنیم!
پاسخحذفیکی از بهترین مثال هایی که می تونم بزنم اینه که فرض کنیم برای یک تیم فوتبال ایرانی لباس بارسلونا بخریم اونم از منیریه و بخواهیم تیم ما قهرمان اروپا بشه! تیم حتی قادر نخواهد بود بازی معمولی خودشرو انجام بده و این حس بارسلونا بودن که به این تیم القا شده همه پیشرفت آینده تیم رو می کشه.
یه کامنت طولانی نوشتم اینترنت قطع شد همه ش پرید. حال ندارم همه رو تکرار کنم، ولی در کل باهات موافقم. به نظرم خود فلسفه agile ایجاب می کنه که هر قسمتیش که تو کار مفید نیست حذف بشه یا تغییر کنه.
پاسخحذف