حدود ده دوازده سال پیش در شرکتی مشغول به کار بودم. آنجا هم مثل بسیاری دیگر از شرکتها متدولوژی مشخصی برای تولید نرم افزار نداشتیم و به قول معروف Code & Fix می کردیم. بابت این مساله هم گاهی در جلسات با مشتری شرمنده می شدیم و در جواب اینکه “از چه متدولوژی استفاده می کنید؟”، آسمان و ریسمان می بافتیم و توجیه می کردیم. تا اینکه اسم Agile به گوش مدیران شرکت خورد. آن زمان تازه متدولوژی های چابک مطرح شده بود و بخصوص XP مورد توجه بود.
با وجود واژه نوظهور Agile که به دامنه لغات تولید کنندگان نرم افزار اضافه شده بود، مدیران شرکت دیگر نیاز به توجیه در جلسات نداشتند و در پاسخ مشتری ادعا می کردند که متدولوژی تولیدشان Agile است. خیلی هم به روز و دهان پرکن! صرفا با استناد به یکی دو ایده از مفهوم چابک و بدون اینکه کوچکترین تغییری در روش کار شرکت ایجاد کرده باشند.
واقعیت این است که این مساله ربطی به این شرکت و آن زمان ندارد. هنوز هم بسیار اند شرکت هایی که درواقع متدولوژی تولید ندارند، ولی فکر می کنند که چابک کار می کنند. اما این تصور از کجا ناشی می شود؟ چرا مدیران فکر می کنند (یا تظاهر می کنند) که روش کارشان Agile است؟ یا بهتر است بگویم چه چیزی در مفهوم چابک هست که به مدیران و صاحبان شرکت های نرم افزاری اجازه می دهد خود را چابک بدانند؟
به نظرم این مساله دو دلیل اصلی دارد:
1- روش های چابک اولویت را به کدبرنامه می دهند تا مستندات. از آنجایی که در بسیاری از شرکت ها در پروسه تولید نرم افزار مستندات کافی تولید نمی شود، شرکت ها به Agile علاقه نشان می دهند و مستند تولید نکردن خود را به حساب چابک بودن خود می گذارند.
2- روش های چابک مانند روشهای سنتی فاز برنامه ریزی و تحلیل و مدل سازی اولیه جامع برای پروژه ندارند و با یک برنامه ریزی اولیه کار را شروع می کنند. سپس بر اساس بازخوردهای مشتری ادامه مسیر می دهند. این ویژگی متدولوژی های چابک باعث شده که شرکت هایی که بدون برنامه ریزی و تحلیل کافی دست به کد می برند، خود را چابک بدانند.
اما Agile بودن و چابکی ویژگی هایی دارد که اغلب این شرکت ها از آن بی بهره اند:
چابک بودن تولید مستندات را نفی نمی کند
چابک بودن مخالفتی با تولید مستندات ندارد. بلکه تاکید آن بر مستندات لازم و کارا است. تولید مستندات، اعم از مستندات طراحی، راهنمای کاربری و غیره بخشی از پروسه تولید نرم افزار است که گاه انجام آن امری ضروری است. شرکتی که هیچ مستندی حتی مستندات ضروری خود را نیز تولید نمی کند نمی تواند این را به چابک بودن خود نسبت دهد.
در متدولوژی های Agile نیازمشتری بر قرارداد پروژه ارجح است
در بسیاری از شرکت ها که ادعای چابک بودن دارند، همچنان قرارداد بعنوان اصلی ترین مرجع تصمیم گیری و شناخت در مورد محدوده و تعریف کار پروژه است. حال آنکه تاکید Agile بر پاسخگویی به نیاز مشتری است. صد البته که از نظر حقوقی و قانونی همچنان قرارداد معیار قضاوت و تصمیم گیری در مورد حسن انجام کار پیمانکار است. اما در اصل آنچه مهم است رضایت مشتری است و اینکه مشکلی از مشتری حل شود و در آینده نیز ارتباط کاری کارفرما و پیمانکار حفظ شود.
همچنین شرکتی که از متدولوژی چابک استفاده می کند، مشتریان او نیز باید شناخت و آگاهی کافی از این روش داشته باشند و از قبل نسبت به این روش تفهیم شوند و بکارگیری Agile درواقع یک تفاهم دوطرفه است.
متدولوژی های Agile نسبت به تغییرات گارد نمی گیرند
برعکس در متدولوژی Agile از تغییرات در همه مراحل پروژه استقبال می شود. اما در بسیاری شرکت ها، مشتری بعنوان مزاحم تلقی می شود. هرچند نمی شود منکر این شد که بعضا نظرات سلیقه ای و غیر کارشناسی نیز از سوی مشتری مطرح می شود. اما این مساله باید با تعامل بین تیم تولید و مشتری حل شود و آن هم با دلایل منطقی و نه صرفا به دلیل فنی و عدم امکان تغییر در کدهای نوشته شده.
در متدولوژی های Agile توجه به بهبود کد برنامه یک اصل است
بسیاری از پروژه ها با معماری اولیه به ظاهر بی نقص و کدهای تمیز و خوانا شروع می شوند. اما بعد از چند ماه، بر اثر فشار کار و تعدد برنامه نویسان با سلایق و تجربه های گوناگون، دیگر نمی شود از منطق حاکم بر کدهای برنامه سردرآورد. در این شرایط ایجاد تغییر در کد روز به روز دشوارتر می شود و بعد از هر تغییر باید منتظر عواقب و آثار آن بر سایر بخش های برنامه بود. حال آنکه در متدولوژی Agile بهبود و Refactoring کدهای برنامه یک اصل است که توسط همه اعضای تیم باید انجام شود. در همین راستا لازم است قوانین و استانداردهایی جهت کدنویسی وضع شود و ابزاها و روشهای نظارتی جهت حصول اطمینان از کیفیت کدها بکار گرفته شود. حال آنکه در بسیاری از شرکتهای داخلی چنین فرایندهایی وجود ندارد.
در متدولوژی های Agile تیم های تولید Cross-Functional و Self-Organizing هستند
سطح بندی شغلی و مهم تر شمردن برخی فعالیتها در فرایند تولید نرم افزار همچنان در بسیاری از شرکتها بسیار پررنگ است. اینکه افرادی با عنوان تحلیل گر و طراح، معماری و اجزای سیستم نرم افزاری را تعیین کنند و کدنویس بدون چون و چرا صرفا به پیاده سازی مدل ها بپردازد. چنین روشی با Agile بودن نسبتی ندارد.
واقعیت این است که مفهوم تیم به معنای مورد نظر چابک در بسیاری از شرکتها وجود ندارد. تیمی که در تخمین زمان انجام کار نقش داشته باشد و صفر تا صد کار را با کمترین وابستگی به سرانجام برساند.
توجه به تجارب گذشته و بهبود عملکرد بطور پیوسته از ویژگی های مهم Agile است
بطور کلی لازمه چابک بودن پویایی است. اینکه چگونه از تجارب گذشته خود بیاموزید و نکات مثبت خود را تقویت کنید و برای نکات منفی راهکاری بیندیشید و این شیوه را بطور پیوسته انجام دهید. طبیعی است چنین تیمی باید اولا بسیار پرانگیزه باشد. ثانیا خود سازمانده باشد تا بتواند تجارب گذشته را در بهبود عملکرد خود بکار گیرد. شخصا با توجه به شناختی که از شرکتهای نرم افزاری دارم، معتقدم تیم هایی اینچنین بسیار کمیاب اند و جز در شرکتهایی که واقعا از Agile بهره می گیرند یافت نمی شوند.
خلاصه اینکه چابک شدن آنقدرها هم که برخی مدیران فکر می کنند راحت نیست.
دی ماه 94