توسعهٔ چابک نرم‌افزار چیست؟

روش‌های چابک توسعهٔ نرم‌افزار چند سال است که باب شده‌اند و به نوعی «مد روز» محسوب می‌شوند. اما توسعهٔ چابک نرم‌افزار دقیقاً یعنی چه؟ اگر در این باره در وب فارسی بگردید، تک و توک مطالب خوبی پیدا می‌کنید، مثل این یا این. اما در اینجا می‌خواهم چابکی در توسعهٔ نرم‌افزار را به روش خودم تعریف کنم:

روش‌های چابک تعدادی از فرضیات اساسی و رایج در توسعهٔ نرم‌افزار را زیر سؤال می‌برند.

این فرضیات چه هستند؟ برخی از مهم‌ترین آن‌ها را در ادامه آورده‌ام:

1. اگر بخواهیم اصولی نرم‌افزار تولید کنیم، باید فعالیت‌هایی مثل تحلیل نیازمندی‌ها، معماری و طراحی، پیاده‌سازی و آزمون را به ترتیب انجام دهیم. چند باور رایج زیر هم حالت‌های خاصی از همین فرض هستند:
1. باید همه یا عمدهٔ نیازهای مشتری در ابتدا معلوم شوند وگرنه نمی‌توان طراحی و پیاده‌سازی را شروع کرد.
   
2. باید اول طراحی را نهایی کنیم و بعد پیاده‌سازی را انجام دهیم. تغییر زیاد در طراحی در حین پیاده‌سازی خوب نیست و نوعی دوباره‌کاری است که باعث اتلاف وقت می‌شود.
3. تغییر زیاد در نیازمندی‌ها در حین طراحی و پیاده‌سازی خوب نیست و نشانهٔ این است که نیازمندی‌ها به درستی در ابتدا جمع‌آوری و تحلیل نشده‌اند.
   
4. باید مؤلفه‌های مختلف نرم‌افزار، اول تولید شوند و بعداً یکپارچه‌سازی شوند.
5. باید صبر کنیم تا پیاده‌سازی نرم‌افزار تمام شود تا بعدش آن را آزمون کنیم، وگرنه مجبور هستیم بعد از هر تغییر مرتباً همان آزمون‌های قبلی را دوباره انجام دهیم که دوباره‌کاری است و خوب نیست.
   
2. اگر بخواهیم اصولی نرم‌افزار تولید کنیم، باید فعالیت‌های مختلف توسعهٔ نرم‌افزار توسط متخصص آن فعالیت‌ها انجام شوند، یعنی مثلاً کار تحلیل را تحلیلگر انجام دهد و کار طراحی را طراح. وقتی کار بزرگ می‌شود، هر کدام از این فعالیت‌ها را باید به یک تیم تخصصی جداگانه داد.
   
3. نباید اجازه داد برنامه‌نویسان مستقیماً با مشتری/کاربر در تماس باشند، بلکه همهٔ روابط با مشتری/کاربر باید از طریق مدیر باشد.
4. هر تیمی نیاز به یک مدیر دارد تا وظایف اعضا را به آن‌ها تخصیص داده و پیگیری کند تا انجام شوند.
5. اگر بخواهیم اصولی نرم‌افزار تولید کنیم، باید توسعهٔ نرم‌افزار را مثل یک فرایند تولید صنعتی ببینیم و با فرایندهای تعریف شده و مشخص آن را انجام دهیم. برای مدیریت پروژه‌های نرم‌افزاری باید از تجربیات سایر صنایع در تولید انبوه و مدیریت پروژه‌های صنعتی الهام بگیریم.
6. هر چه تیم توسعهٔ نرم‌افزار بزرگ‌تر باشد، خروجی کار از نظر ویژگی‌ها، زمان، هزینه و کیفیت بهتر خواهد بود.
7. اگر مستنداتی مفصل از مدل‌های گرافیکی (مثلاً نمودارهای مختلف UML) برای تحلیل و طراحی تولید نکنیم، کار مهندسی نرم‌افزار را به درستی انجام نداده‌ایم. ایجاد این مدل‌ها یکی از مهم‌ترین فعالیت‌های توسعهٔ نرم‌افزار است.
   

فرضیات فوق در نگاه اول خیلی منطقی و اصولی به نظر می‌رسند، اما روش‌های چابک نشان می‌دهند که این فرضیات لزوماً همیشه درست نیستند. اما در ضمن یک نکتهٔ مهم دیگر هم وجود دارد:
فرضیات فوق بی‌ارزش نیستند و شمّه‌ای از حقیقت در همهٔ آن‌ها وجود دارد.
این نکته خیلی مهم است چون باعث می‌شود از آن طرف پشت بام نیفتیم: چابکی به معنای نفی انضباط و قاعده‌مندی، نفی دستاوردهای مهندسی نرم‌افزار، نفی تحلیل و طراحی و مدل‌سازی، نفی نیاز به مدیریت پروژه، نفی نیاز به متخصص و نفی نیاز به مستندسازی نیست!

تلاش می‌کنم در مطالب آینده به تک‌تک این فرضیات بپردازم و نشان بدهم که چرا این فرضیات در بسیاری از موارد یا حتی در اکثر اوقات غلط هستند.