چابک (Agile) مجموعه ای از ارزش ها و اصول جهت توسعه نرم افزار های کارا توسط تیم های خود سازمانده می باشد. ارزش ها و اصول چابک (Agile) در سال ۲۰۰۱ توسط ۱۷ نفر از اساتید معتبر جهانی صنعت توسعه نرم افزار طی یک بیانیه با عنوان بیانیه توسعه چابک تنظیم و ارائه گردید. اساس و هدف این اصول و ارزش ها ارائه نرم افزار کارا و یا محصول کارآ به مشتری می باشد.

چابک (Agile) مجموعه ای از ارزش ها و اصول جهت توسعه نرم افزار های کارا توسط تیم های خود سازمانده می باشد. ارزش ها و اصول چابک (Agile) در سال ۲۰۰۱ توسط ۱۷ نفر از اساتید معتبر جهانی صنعت توسعه نرم افزار طی یک بیانیه با عنوان بیانیه توسعه چابک تنظیم و ارائه گردید. اساس و هدف این اصول و ارزش ها ارائه نرم افزار کارا و یا محصول کارآ به مشتری می باشد.

اما چه نیازی به روش چابک بود؟! به عبارتی چه شد که این ۱۷ نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال ۲۰۰۱ اقدام به انتشار چنین روشی کردند!؟

جواب کاملا واضح است: ضعف های موجود در روش های سنتی باعث شد که این دوستان روش چابک را معرفی نمایند.

روش های سنتی و یا موجود چه مشکلاتی داشتند؟

روش های موجود آن زمان (و فعلی این زمان ایران) که بیشتر به صورتی فاز به فاز عملیات اجرا می شد و نتیجه کار از قبل به صورت یک طراحی اولیه دقیق (Up-front Design) پیش بینی می شد یک سری ایراد اساسی و کلی داشت :

صرف زمان زیاد و در واقع اتلاف زمان برای طراحی اولیه دقیق در فاز اولیه پروژه

مشخص نبودن و واضح نبودن نیازمندی ها بدلیل ارتباطات کاغذی به جای ارتباطات چهره به چهره و کج روی های متعاقب

بالا بودن هزینه تغییرات

به طول انجامیدن پروژه و گذر از زمان تعیین شده در حد بسیار زیاد در بسیاری از پروژه ها

عدم وجود زمان برای آزمایش محصول و متعاقبا محصولات پر از باگ و بدون کیفیت

عدم شفافیت در پروسه توسعه و تولید : هیچ کس حتی مدیر پروژه نمی دانست که چقدر از محصول مورد نظر تکمیل شده است؟ چه اهدافی باقی مانده است؟ و … .

بزرگترین مشکل این پروسه ها ناکارآ بودن محصولات اشان بود.  اما چرا محصولات این پروسه ها ناکارآ تشریف داشتند؟

به این دلیل که عملکرد این پروسه ها بر اصل Anticipation یا پیش بینی استوار بود. در پیش بینی یک سری موارد بر روی کاغذ و به عنوان قرار داد بسته جهت پیاده سازی تحویل تیم توسعه داده می شد و تیم توسعه موظف می شد در یک زمان مقرر و با یک منابع مشخص و ثابت این وظایف را پیاده سازی نماید. این اصل  همراه خود در بردارنده طراحی دقیق اولیه یا Big Design Up-Front بود (همان صحبت معروفی که شاید شنیده باشید :”ما اگر ۱ سال وقت داشته باشیم ۱۰ ماه آن را برای تحلیل و طراحی و  ۲ ماه آن را برای پیاده سازی صرف می کنیم).

طراحی اولیه دقیق (Big Design Up-Front) خوب است ولی در جایی که همه چیز ثابت باشد و نیازی به تغییر نداشته باشیم ولی آیا به راستی در جهان واقع و در اکثر پروژه هامان نیاز به تغییر نداریم؟!

زمانیکه در پروژه ای طراحی اولیه دقیق (Up-Front Design) می شود مسلما فاز تست آخرین فازی خواهد شد که بر روی محصول انجام می شود. ولی آیا این فاز تاثیر گذار می تواند باشد؟ محصولی که کامل ساخته شده است تزریق کیفیت به آن ساده نیست و در بعضی از موارد غیر ممکن خواهد بود. بهتر است به جای این , محصول با کیفیت ساخته شود و نه کیفیت به آن در آخر پروژه تزریق شود.

درکل اصل پیش بینی که متد های آن زمان , بر آن استوار بودند رابطه ی خوبی با تغییر نداشتند زیرا آن ها عادت داشتند همه چیز را از قبل پیش بینی کنند و تغییر برای آنها بسیار هزینه بر بود. اما چرا تغییر برای آن پر هزینه بود؟ زیرا آنها تغییرات و کج روی های خود را خیلی دیر متوجه می شدند (اکثرا در آخر پروژه) و در محور زمان هر چقدر تغییر و یا مشکل دیر کشف شود رفع و یا ایجاد آن مشکل تر – پیچیده تر و پرهزینه تر خواهد بود. به همین دلیل آنها تغییر را رد می کردند.

رد کردن تغییر به منزله ناکارآمد کردن محصول و خروجی پروژه می باشد. هر تغییر و یا اصلاحی که در محصول نیاز می شود برای تکمیل و کارآمدتر کردن آن می باشد : به این دلیل که مشتری نیازمند تغییر است (زیرا تجارت او در حال تغییر است و یا اصلا او در شناخت نیازها اشتباه کرده است و یا هر چیز دیگری)  و اگر تغییر انجام نشود محصول به درد تجارت و کسب وکار مشتری نخواهد خورد و اگر تغییر نیز انجام شود هزینه آن بالا خواهد بود , که در این صورت هم پروژه به صرف نخواهد بود.

یکی دیگر از معایب اصلی پیش بینی جلوگیری از به وجود آمدن  نوع آوری در محصول می باشد. یعنی عملا نوع آوری وجود نخواهد داشت.

مشکلات موجود در پروسه های موجود و خروجی های بی کیفیت و محصولات ناکارآ در آن زمان و بخصوص اتلاف و نارضایتی نیروی انسانی پروژه ها و ضررهای مالی کلان در حوزه فناوری اطلاعات این دوستان را بر آن داشت که روش جدیدی برای اصلاح پروسه توسعه نرم افزار معرفی نمایند که همه ما آن را با نام Agile یا چابک می شناسیم.

نقطه عکس حالت پیش بینی حالت Adaptation یا انطباق سازی می باشد که تفکر چابک بر آن استوار می باشد.

در انطباق سازی (Adaptation) به جای یک طراحی دقیق و برای سازگاری بیشتر محصول با نیاز های واقعی مشتری از Real-Time Planning و Emergent Design استفاده می شود. یعنی به حد کافی در زمان های مناسب نیازمندی هایی از طریق ارتباط چهره به چهره دائم و فیدبک مشتری دریافت می شود که فقط آنها بر اساس عکس بزرگ محصول برنامه ریزی و طراحی می شوند و نه بیشتر.

Iterative و Incremental بودن تفکر چابک فرصت مغتنمی برای ایجاد یک بستر انطباق سازی (Adaptation) به وجود آورده است. بدین صورت که محصول به صورت Incremental ساخته می شود و در Iterative های معلوم و کوتاه در اختیار مشتری قرار داده می شود  در هر تکرار و یا چرخش فیدبک های مشتری به عنوان نیازمندی های جدید وارد پروسه توسعه می شوند که بدلیل فیدبک های دائم و زود هزینه تغییرات بسیار پایین خواهد آمد.

علاوه بر این در چابک بدلیل Incremental بودن , پروسه آزمایش  و یا تست به صورت یکپارچه با توسعه بخش ها انجام می شود که این نوید دهنده یک محصول با کیفیت در هر Release خواهد بود. به عبارت ساده تر به جای تزریق کیفیت ,  بخش ها را با کیفیت می سازیم که این هم هزینه نگه داری هر بخش را کاهش می دهد و هم محصول نهایی با کیفیت می شود و هم تغییرات قابل اجرا خواهند بود. در حالی که در روش پیش بینی پروسه تست در فاز آخر انجام می شد.

به طور کلی برای ویژگی یک متد بر پایه انطباق سازی (Adaptation) می توان موارد زیر را بر شمرد :

Real-Time Planning

Emergent Design

Integrated Testing

Collaborative Discussions

Just-in-Time & Just-Enough Requirements

به طور خلاصه در تفکر چابک هدف این است که محصولی کارآمد تحویل مشتری داده شود و محصول کارآمد محصولی است که با نیاز های مشتری سازگار باشد.  برای همین اصول و ارزشهایی برای دست یابی به این مهم در بیانیه توسعه چابک آمده است.

ارزش های توسعه نرم افزار چابک

افراد و تعاملات بالاتر از فرآیندها و ابزارها
نرم افزار کارا بالاتر از مستند سازی جامع
همکاری مشتری بالاتر از قرارداد کار
جوابگویی به تغییرات بالاتر از پیروی یک طرح

با وجود اینکه در موارد سمت چپ ارزش هایی وجود دارد ولی
موارد سمت راست ارزش بیشتری برای ما دارند

ارزش افراد و تعاملات به معنی ایجاد یک محیط فعالانه و همکارانه بین اعضای تیم می باشد. ارزشهمکاری مشتری به معنی دست یابی به فیدبک های مشتری و ایجاد نوع آوری می باشد. ارزشجوابگویی به تغییرات هم نیز در جهت دست یابی به ارزش والای نرم افزار کارآ می باشد.

به عبارت ساده تر ما تیمی داریم که تعاملات خوبی بین اعضای آن در جریان است و این تیم با گرفتن فیدبک های مشتری به صورت متوالی و سازگار کردن محصول با نیازهای مشتری در حال توسعه نرم افزار کارآ می باشد.

همه این مواردی که ذکر شد ارزش هایی می باشند که انتظار می رود یک سازمان چابک برای خود داشته باشد. ولی اینها وحی منزل نیستند و سازمان ها می توانند ارزش های خود را برای چابک سازی خود داشته باشند.

در کنار ارزش های سازمان چابک ۱۲ اصل چابک نیز وجود دارد که سازمان های چابک برای دست یابی به ارزش های چابک می توانند پیرو آن اصول باشند:

اصول بیانیه چابک
ما از این اصول پیروی می کنیم :

بالاترین اولویت ما رضایت مشتری از طریق
تحویل به موقع و مداوم نرم افزار ارزشمند می باشد

پذیرائی از نیازهای در حال تغییر , حتی آن هایی
که در اواخر توسعه پدید آور می شوند. فرآیند های چابک
تغییرات را جهت رقابت بر سر مشتری مهار و کنترل می نمایند

تحویل نرم افزار کارکننده غالبا از چند هفته تا چند ماه
یک بار انجام می شود که زمانبندی کوتاه تر ترجیح داده می شود

ذینفعان تجاری و توسعه دهندگان باید هر روزه در
طول پروژه با هم کار کنند

پروژه ها را بر روی افراد با انگیزه بنا کنید. محیط لازم را
به آنها بدهید و از نیازهای آن ها پشتیبانی نمایید وبه
آنها اعتماد نمایید تا کارها را انجام بدهند

کارآمدترین و موثرترین روش برای انتقال و رساندن
اطلاعات به تیم توسعه , گفتگوی چهره به چهره و رودرو می باشد

نرم افزار کارکننده اصلی ترین معیار پیشرفت می باشد

فرآیند های چابک توسعه پایدار را ترویج می دهند.
حامیان مالی , توسعه دهندگان و کاربران باید قادر به
حفظ سرعت پیشرفت ثابتی براى یک مدت نامحدود باشند

توجه مداوم به برتری فنی و طراحی خوب باعث
افزایش چابکی می شود

اصل سادگی ضروری می باشد

بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های
خود سازمانده پدید آور می شود

در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید
و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید

جمع این ارزش ها و اصول در یک سازمان باعث چابک شدن آن سازمان می شود. البته به این نکته توجه نمایید که سازمان چابک کار نمی کند بلکه چابک می شود.

اما چگونه می توان چابک شد ؟

برای چابک شدن باید در پروسه توسعه و یا حتی سطوح کلان سازمان مانند مدیریت منابع انسانی پروژه و یا هر سطحی ارزش های و اصول چابک رعایت شوند و در نظر گرفته شوند. به عبارتی باید همه سازمان چابک شود و نه فقط بخش یا واحد توسعه نرم افزار. به همین دلیل حرکت سازمان به سمت چابک را تغییر یا Change گفته نمی شود و از اصطلاح Transformation یا تحول استفاده می شود. یعنی باید سازمان در راه چابک شدن متحول شود.

برای اینکه بتوان به سطحی از چابکی دست یافت می توان از متدهای Agile مانند اسکرام , XP , کریستال و یا … بهره جست . در همین رابطه پیشنهاد می کنم این مطلب را مطالعه کنید: ربط اسکرام با Agile.

نتیجه گیری

تفکر چابک یک تفکر ناب در زمینه توسعه نرم افزار می باشد که خروجی و هدف آن ارائه نرم افزار کارآ می باشد. در تفکر چابک هزینه توسعه بدلیل ناب (Lean) بودن و تحلیل و طراحی سازگار  پایین خواهد بود. در تفکر چابک بدلیل Iteration عمل کردن و ارتباط چهره به چهره دائم با مشتری و آزمایش یکپارچه شاهده محصول با کیفیت و کارآ خواهیم بود. در Agile به دلیل خود سازمانده بودن تیم ها شاهد نفرات و تیم های خوشحال و راضی خواهیم بود. و سازمان نیز بدلیل چابک بودن دارای سود بالایی خواهد بود.