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