در آموزش گذشته گفتیم که در فوریه سال 2001 گروهی از توسعه دهندگان علاقمند به ایجاد متدولوژی های توسعه ی نرم‌افزار سریع و چابک دور هم جمع شده و مدلی به نام Agile را پایه ریزی کردند. این توسعه دهندگان دریافته بودند که هر بخش از فرایند توسعه ی نرم‌افزار می بایست با بخش‌های قبلی در ارتباط بوده، انعطاف پذیر، مؤثر و تیم-محور باشد تا در نهایت بتوان بهترین نتیجه را گرفت.
در همین راستا، یک مانیفست -یا مجموعه اصول و قوانین- برای اجایل نوشته شد که دربرگیرنده ی 12 اصل است که تیم های توسعه ی نرم‌افزار با پیروی از آن‌ها، خواهند توانست برچسب اجایل را روی خود بزنند. این 12 اصل را می‌تواند در 4 مورد خلاصه کرد که عبارتند از:
- افراد و تعاملات مابین آن ها نسبت به فرایند ها و فناوری ها ارجحیت دارند.
- یک نرم‌افزار قابل استفاده به مراتب نسبت به مستندات کامل و پیچیده بهتر است.
- مشارکت مشتری در فرایند توسعه به مراتب نسبت به بندهای قرارداد برتری دارد.
- اعمال تغییرات نسبت به پیروی از یک نقشه ی ثابت در اولویت است.
در 4 مورد بالا، آنچه در سمت راست به صورت بولد نوشته شده نسبت به آنچه در سمت چپ آمده است همواره می بایست برتری داشته باشد. به عبارت دیگر، یک تیم اجایل تمرکز خود را روی تعاملات مابین طراحان، برنامه نویسان، مشتری و مدیر پروژه می‌گذارد چرا که نرم‌افزار توسط افراد طراحی می‌شود نه ابزارهای برنامه نویسی! فناوری های توسعه ی نرم‌افزار می‌توانند به کمک افراد بیایند نه این که جایگزین افراد شوند.
ارزشمند تلقی کردن یک نرم افزاری که قابل استفاده است نسبت به مستندسازی قوی، در نقطه ی مقابل مدل آبشاری قرار دارد که قبلاً با این مدل آشنا شدیم. یک مستندسازی چندین صفحه ای، با تمامی جزئیات اگر منتهی به یک نرم‌افزار قابل استفاده نشود هیچ ارزشی ندارد. در مدل اجایل، مستندات به منزله ی ابزاری است که منجر به ایجاد یک نرم‌افزار بهتر می‌شود و تحت هیچ عنوان مستندات هدف اول و آخر پروژه نیست.
مدل اجایل تحت هیچ عنوان بندهای مندرج در قرارداد را نادیده نمی‌گیرد اما تیم های اجایل، به مشتری مداری ارجحیت بیشتری نسبت به پایبندی به بندهای قرارداد می دهندو برای مرتفع ساختن نیاز یا نیازهای مشتری، گاهی پا را فراتر از آنچه در قرارداد آمده می گذارند.
در فرایند توسعه ی نرم افزار، خیلی سخت است که ابتدای کار به کلیه ی قابلیت‌های نرم‌افزار فکر کرد و آن‌ها را در قرارداد آورد. به عبارت دیگر، پس از شروع کار است که بسیاری از بخش‌های نرم‌افزار یا اپلیکیشن مشخص می‌شوند و می بایست آن‌ها را کدنویسی کرد. علاوه بر این، دنیا دائماً در حال تغییر است و بالتبع نیازهای تجاری هم دستخوش تغییر می شوند. در همین راستا، تیم های اجایل عاشق تغییرات هستند و هر کجا که دیدند نیاز به تغییری هست، با آغوش باز از آن استقبال خواهند کرد و هرگز خود را وابسته به یک پلان اولیه با تعدادی قابلیت مشخص در آن نمی کنند.
برای درک بهتر این اصول و قواعد، می‌توان آن‌ها را در قالب 12 اصل در نظر گرفته که تحت عنوان The Agile Manifesto شناخته می شوند که عبارتند از:
- بالاترین اولویت، راضی نگه داشتن مشتری از طریق تبدیل پروژه ی اصلی به چندین بخش کوچک و تحویل تک تک آن بخش‌هایی که به خوبی کار می‌کنند و بدون باگ هستند در بازه های زمانی کوتاه.
- استقبال از تغییرات حتی در مراحل پایانی پروژه چرا که اعمال تغییراتی که منجر به بهبود نرم‌افزار شوند در نهایت منجر به رضایتمندی بیشتر مشتری خواهند شد.
- تحویل زود هنگام نرم افزاری قابل استفاده در بازه های زمانی چند هفته‌ای تا چند ماهه به طوری که هرچه این بازه های زمانی کوتاه‌تر باشد بهتر است.
- توسعه دهندگان و سفارش دهندگان نرم‌افزار می بایست به صورت روزانه با یکدیگر تعامل داشته باشند.
- از افراد باانگیزه در تیم توسعه ی نرم‌افزار خود استفاده کنید و به ایشان فضای لازم برای شکوفایی استعدادهایشان را داده و از ایده‌های ایشان حمایت کنید و به آن‌ها اعتماد داشته باشید که در نهایت آن را به بهترین شکل به انجام خواهند رساند.
- بهترین و اثربخش ترین راه برای تبادل اطلاعات در یک تیم توسعه ی نرم افزار، مکالمه ی رو در رو است.
- نرم افزاری قابل استفاده، اصلی‌ترین معیار سنجش پیشرفت پروژه است.
- یکی از پایه‌های ثابت فرایند های اجایل، توسعه ی پایدار است. به عبارت دیگر، مشتری، توسعه دهندگان و کاربران نرم‌افزار می بایست شاهد سرعت پیشرفت ثابتی در طول زمان باشند نه این که گاهی نرم‌افزار با سرعت پیش رفته و گاهی -به مدت چند ماه یا چند سال- از توسعه باز ایستند.
- زمانی می‌توان به معنای واقعی کلمه برچسب اجایل را روی یک تیم زد که به طور دائم به طراحی حرفه ای، استفاده از بهترین فناوری ها و آخرین دستاوردهای حوزه ی توسعه ی نرم‌افزار توجه کنند.
- سادگی شرط اول و آخر توسعه ی نرم‌افزار می بایست باشد و تیم های اجایل می بایست از هر گونه پیچیدگی -چه در فرانت اند و چه در بک اند- حذر کنند.
- بهترین ایده ها، ساختارها و طرح های نرم افزاری از دل تیم های خودکفا شکل می گیرند.
- در بازه های زمانی مشخص، اعضای تیم می بایست در مورد روش‌های بهتر شدن با یکدیگر بحث و تبادل نظر داشته باشند و در نهایت فرایند های کاری خود را بر اساس نتایج بحث، تغییر دهند.