برای درک موفقیت رویکرد توسعه ی نرم‌افزار اجایل، پیش از هر چیز نیاز است تا با رویکردهایی که در گذشته توسط برنامه نویسان و شرکت های برنامه نویسی برای طراحی نرم‌افزار مورد استفاده قرار می گرفته آشنا شویم. توسعه ی نرم‌افزار قدمتی بیشتر از ۵۰ سال دارد و در این بازه ی نسبتاً طولانی، متدولوژی های بسیاری به بازار نرم‌افزار ورود پیدا کرده‌اند که هر کدام دارای نقاط ضعف و قوت مخصوص به خود بوده‌اند و اجایل هم که در عصر حاضر مورد توجه قرار گرفته است، یکی از جدیدترین -و به نوعی بهترین- متودولوژی های توسعه ی نرم‌افزار است که جایگاه فعلی خود را مدیون مدل هایی است که در گذشته ابداع شده اند.

Code-and-Fix Model

یکی از رویکردهای اولیه در توسعه ی نرم افزار، روش Code-and-Fix به معنی «کد بزن بعد اگر مشکلی بود آن را حل کن!» بود. در چنین رویکردی، باگ های نرم‌افزار را یا خود برنامه نویس می یافت یا توسط کاربرانش و یا سایر برنامه نویسان پس از عرضه ی نرم افزار به بازار کشف می شد. چند ماه زمان برای توسعه ی نرم‌افزار گذاشته می‌شود و در نهایت نرم‌افزار به صورت کامل و جامع عرضه می‌شد و چیزی تحت عنوان فازبندی پروژه وجود نداشت.

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

Waterfall Model

به منظور پشت سر گذاشتن چالش های رویکرد Code-and-Fix، توسعه دهندگان اقدام به فازبندی پروژه های نرم افزاری کردند به این صورت که یک پروژه از گام اول شروع شده و به گام ششم ختم می شد:

Requirements
Design
Development
Intergration
Testing
Deployment

این سبک توسعه ی نرم‌افزار در دهه ی 50 میلادی رواج پیدا کرد و تا سال 1970 مورد استفاده قرار می‌گرفت و از آنجا که روال توسعه ی نرم‌افزار سلسله مراتبی بود و از بالا به پایین شروع می‌شد و در صورتی هم که اگر در یکی از مراحل بالایی نیاز به تغییر بود، این کار با دشواری فراوان صورت می گرفت، نامی همچون Waterfall Approach به معنی «روش آبشاری» برایش در نظر گرفته شد (در آبشار هم آب سرازیر شده را هرگز نمی‌توان به بالای آبشار هدایت کرد!)

در این مدل، در گام اول Requirements یا «ملزومات» پروژه مورد بررسی قرار می گرفت و کاملا مشخص می شد که نیازهای اصلی یک پروژه کدامند. در گام دوم Design یا «طراحی« و نمونه سازی پروژه صورت می گرفت تا مشخص شود که محصول نهایی قرار است چگونه به نظر برسد و در گام سوم هم Development یا «توسعه» ی پروژه شروع می شد. در گام بعد که Integration نام داشت، بخش های مختلف پروژه با یکدیگر ادغام شده تا عملکرد آن ها در کنار یکدیگر مشخص گردد و در گام پنجم هم که Testing نام داشت، نرم افزار تست می شد و اگر مشکلی نداشت در گام Deployment، به بازار عرضه می شد.

جالب است بدانیم که امروزه نیز بسیاری از تیم های توسعه ی نرم‌افزار کماکان از روش آبشاری استفاده می‌کنند اما این روش هم دارای نقاط ضعف خاص خود است که عبارتند از:

نیازهای مشتریان دائما در حال تغییر هستند و این در حالی است که در روش آبشاری -با توجه به این که مرحله ارزیابی نیازهای مشتری در گام های اولیه قرار دارد- به سادگی نمی‌توان این تغییرات را در پروژه اعمال کرد و اگر هم بتوان این کار را کرد، اعمال تغییرات منجر به عقب افتادن پروژه از زمان تعیین شده می گردد.
بخش Requirements یا «ملزومات» پروژه در مراحل اولیه ی مدل آبشاری قرار دارد و همین مسأله منجر به کاهش انعطاف پذیری تیم توسعه ی نرم‌افزار می گردد.
تست کردن نرم‌افزار در مراحل پایانی پروژه نیز منجر به این می‌گردد تا باگ های پروژه -از کوچک گرفته تا بزرگ- خیلی دیر مشهود شوند که همین قضیه منجر به دشواری بیشتر فرایند دیباگینگ می شود.
یکی دیگر از نقاط ضعف مدل آبشاری، عدم حضور مستقیم مشتری در فرایند توسعه ی نرم‌افزار است. این نبود حضور مستقیم مشتری در فرایند کدنویسی باعث خواهد شد تا نیازهای رو به رشد و در حال تغییر بازار را نتوان به سادگی در دل برنامه‌های نوشته شده گنجاند. تحقیقات حاکی از آنند که مشتریان در حین عقد قرارداد با شرکت های برنامه نویسی، چیزی در حدود 20 درصد از کل نیازهای برنامه ی مد نظر خود را به یاد می‌آورند و الباقی در طول زمان برای ایشان هویدا خواهد شد!

Spiral Model

در اواسط دهه ی 80 میلادی، توسعه دهندگان به دنبال روشی جایگزین برای مدل آبشاری بودند که در نتیجه مدل هایی عرضه شدند که بر آن اساس، نرم‌افزارها به بخش‌های کوچکی تقسیم می‌شدند و بازه های زمانی مشخص، این بخش‌های کوچک از کل پروژه که به درستی کار می‌کردند در اختیار مشتری قرار می گرفت. علاوه بر این، مدل های دیگری نیز بوجود آمد که بر اساس آن، توسعه دهندگان با دریافت فیدبک یا «بازخورد» هایی که مشتریان روی نرم‌افزار می دادند، اقدام به بهبود نرم‌افزار می کردند.

با این توضیحات، جامعه ی توسعه دهندگان در سال 1988 مدلی تحت عنوان Spiral (اسپیرال یا مارپیچ) که به منزله ی نقطه ی عطفی در متدولوژی های توسعه ی نرم‌افزار محسوب می‌شود را به دنیا عرضه کردند.

این مدل به منظور کاهش ریسک مدیریت پروژه های برنامه نویسی ابداع شد که به موجب آن یک نمونه ی اولیه از نرم‌افزار طراحی شده و در اختیار مشتری قرار می‌گرفت و پس از تأیید اولیه، در طول زمان بخش‌های کوچک‌تر از یک پروژه ی بزرگ به منظور دریافت بارخورد در اختیار مشتری قرار می گرفت.

این مدل، به‌ خصوص برای پروژه هایی مناسب بود که در بدو امر مشتری نمی‌دانست که از نرم‌افزار مد نظرش چه انتظاراتی دارد و این انتظارات در طول زمان شکل می گرفت. اگر برای این دست مشتریان مدلی همچون آبشاری در نظر گرفته می شد، بسیاری از Feature ها یا «قابلیت» های مد نظر مشتری در نطفه خفه می‌شدند اما در مدل اسپیرال، با توجه به این که فرایند های توسعه ی نرم‌افزار از یک سو و همچنین گرفتن بازخورد از مشتری و درک نیازهای رو به رشد وی از سوی دیگر در کنار یکدیگر مد نظر قرار داده می‌شدند -گویی این دو به صورت مارپیچ به همدیگر تنیده شده و ارتباط تنگاتنگی با یکدیگر داشتند- کلیه ی نیازهای مشتری محترم شمرده شده و تا حد قابل توجهی نیازهایش مرتفع می گشتند.

سایر مدل های توسعه ی نرم افزار

پس از رویکرد اسپیرال، در دهه ی 90 میلادی رویکردهای سریع و اثربخش دیگری به منظور جایگزین شدن مدل آبشاری ابداع شدند که از آن جمله می‌توان به مدل RAD که مخفف واژگان Rapid Application Development به معنی «توسعه سریع اپلیکیشن» است اشاره کرد. علاوه بر مدل RAD، مدل های دیگری همچون Scrum و مدل XP که مخفف واژگان Extreme Programming است نیز بوجود آمدند که هر دوی آن‌ها بر تحویل بخش‌های کوچک نرم‌افزار در بازه های زمانی کوتاه تمرکز داشتند تا در نهایت بتوانند پاسخگوی نیازهای بازار و فرایندهای توسعه ی نرم‌افزار باشند.

تا این که در نهایت در ماه فوریه ی سال 2001، گروهی از توسعه دهندگانی که علاقمند به ارتقاء مدل های سبک و سریع توسعه ی نرم‌افزار بودند گروهی تشکیل داده و نقطه نظرات خود را با یکدیگر به اشتراک گذاشته و به بحث و گفتگو در ارتباط با چگونگی بهبود روش‌های توسعه ی نرم‌افزار پرداختند تا این که در نهایت مدل Agile (اجایل به معنی چابک) ابداع شد که در آموزش‌های بعد، بیشتر با این مدل آشنا خواهیم شد.

رویکردهای توسعه ی نرم‌افزار در گذر زمان