چابک (Agile) چگونه شکل گرفت؟

در سال 2001 تعدادی از برنامه نویسان و توسعه دهندگان نرم افزار در آمریکا دور هم جمع شدند و به هم اعلام نمودند که طریق و روش سنتی مدیریت پروژه های نرم افزاری ره به جایی نخواهد برد و باید مورد بازنگری قرار بگیرد. آنان بیانیۀ چابک (Agile Manifesto) را نوشتند:

 

 

این بیانیه از 4 ارزش مرکزی و محوری ساخته شده است که در هر ارزش، دو قسمت با همدیگر مقایسه می شود. طرف راست و چپ با هم مقایسه شده و یکی را بر دیگری با ارزش تر و مهم تر و اساسی تر می پندارد:

• افراد و تعاملات آنها بالاتر هستند از فرآیندها و ابزارها
• نرم افزاری که کار می کند بالاتر است از مستند سازی انبوه
• تعامل با مشتری بالاتر است از مذاکرات قراردادی
• پاسخ به تغییر بالاتر است از دنباله روی از یک برنامه

 

در واقع این واژۀ بالاتر، ترجمه شدۀ واژگانی چون over یا than است که دو چیز را با هم مقایسه می کند و می گوید اگر چه نمی توان در ساختار چابک چیزی را از گذشته به طور کامل حذف و معدوم نمود بلکه باید اهمیت را سنجید و پی برد که یکی از دیگری با اهمیت تر است.

 

پس از نگارش بیانیۀ چابک و استخراج 4 ارزش، 12 اصل نیز از دل این بیانیۀ بیرون آمدند که به شرح زیر هستند.

 

---

۱۲ اصل تفکر چابک (Agile)

Our highest priority is to satisfy the customer

۱ – رضایت مشتری: بالاترین الویت است که از طریق تحویل به موقع و مداوم محصول (نرم افزار) محقق خواهد شد.

 

Welcome changing requirements, even late in development

۲- استقبال از تغییر: تغییرات در پروژه های نرم افزاری اجتناب ناپذیر هستند، حتی تغییراتی که در اواخر کار توسط مشتری درخواست شده است نیز از آنها استقبال می شود.

 

Deliver working software frequently, from a couple of weeks to a couple of months

۳ – ترجیح بر آن است که در تفکر چابک، محصولات در بازه های زمانی کوتاه ( بین چند هفته تا چند ماه) و بصورت مکرر، به مشتری تحویل داده شود (رویکرد Iterative  و Incremental).

 

Business people and developers must work together daily throughout the project

۴ – همکاری و مشارکت ذینفعان باید در طول چرخه حیات پروژه (بصورت روزانه) وجود داشته باشد.

 

Build projects around motivated individuals

۵ – انگیزه: پروژه ها را با استفاده از  افراد با انگیزه بسازید، به اعضای تیم خود اعتماد کنید تا احساس مسئولیت پذیری داشته باشند تا کارها به خوبی انجام شود.

 

Face-to-Face Conversation

۶ – گفتگوی رو در رو، موثرترین روش انتقال اطلاعات به تیم پروژه می باشد.

 

Working software is the primary measure of progress

۷- در تفکر چابک، تحویل محصول (نرم افزار) کاربردی به مشتری، عامل نهایی است که پیشرفت پروژه را اندازه گیری می کند.

 

Agile processes promote sustainable development

۸- حفظ توسعه پایدار: فرآیندهای چابک باید به سمت توسعه پایدار حرکت کنند بطوری که ذینعان تجاری،حامیان و کاربران قادر باشند سرعت پیشرفت را با روند ثابت در طول چرخه حیات پروژه حفظ کنند.

 

Continuous attention

۹- نظارت و توجه منظم باعث افزایش چابکی شده و به برتری فنی و طراحی خوب محصول منجر خواهد شد.

 

Simplicity

۱۰- سادگی یک ضرورت است، همه چیز ها را ساده نگه دارید و از انجام کارهای کم اهمیت اجتناب کنید.

 

Self Organized Teams

۱۱- تیم های چابک، خود هدایت و سازماندهی می شوند و نیازی به گفتن آنچه باید انجام شود، نیست.

 

Review the Work Regularly

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

---

به منظور پیاده سازی چابک، متدولوژی های مختلفی وجود دارد که در ادامه به اختصار معرفی خواهند شد. 

 

مشخصات اسکرام

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

 

هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: تحلیل نیازمندی‌ها، طراحی، کدنویسی، تست واحد، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذینفعان نشان داده می‌شود. این ریسک کلی را به حداقل رسانده و اجازه می‌ دهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار، قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار محصول (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند. تیم در یک پروژه چابک معمولاً خودسازمان‌ده است، بدون توجه به هرگونه سلسله‌ مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به‌طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می‌دهد، بر عهده می‌گیرند. آن‌ها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.

 

متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌ شده تأکید دارد. بیشتر تیم ‌های چابک در یک دفتر تک‌ واحدی به نام bullpen کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌ های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف مشترک یا در بخش ‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت ‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌ کند، افراد ارتباط روزانه‌ شان را از طریق ویدئو کنفرانس، صدا، ایمیل و… حفظ می ‌کنند.

 

مهم نیست چه دیسیپلین ‌های توسعه‌ای لازم است، هر تیم چابک، یک مالک محصول دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌ دهندگان باشد. در انتهای هر تکرار، ذی‌نفعان و مالک محصول پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه ‌سازی بازگشت سرمایه (ROI) مجدداً می‌ سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌ سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند.

 

این به‌طور خاص شامل نماینده مشتری و هر کدام از ذی‌نفعان علاقه‌ مند به عنوان ناظر می‌شود. در یک جلسه مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌ اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند. به این جلسات اسکرام روزانه یا Daily Scrum گفته می‌شود.

 

توسعه چابک بر کار نرم‌ افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت ‌بندی «خواسته‌ ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌ وکار مشاهده ‌شده در ابتدای تکرار (که با عنوان ارزش‌ محور شناخته می‌شود) ترغیب می‌کند.

 

ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر (Continuous Integration)، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی (۲-pair Programming)، توسعه آزمون ‌محور (Test Driven Development)، الگوهای طراحی، طراحی دامنه ‌محور (Domain Driven Development)، code refactoring  و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.

 

توسعه ‌چابک سبک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین شده را (از طیف وسیع ‌تری از پروژه‌ های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ ها و محیط‌ های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجه اول بر تجارب کاربر (User Experience) و واسط‌ های نرم‌ افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آن‌ها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌ سازی‌ های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف ‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.

 

در توسعه چابک نرم‌افزار، یک نمایانگر اطلاعات، صفحه‌ نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌ نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌ افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعه چابک نرم‌افزار» توصیف شد.