توسعه نرم‌افزاری چابک
توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت می‌کند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. بیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.
تاریخچه
سوابق
متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند. در سال ۱۹۷۴، E.A. Edmonds در مقاله‌ای فرایند توسعهٔ تطبیقی نرم‌افزار را معرفی کرد. هم‌زمان و به‌طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم‌های شرکت تلفن نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ ۱۹۷۰، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت. در طول نیمه تا انتهای دههٔ 1970 Gielan به‌طور گسترده در ایالات متحده در مورد این متدولوژی، تجارب و فواید آن سخنرانی‌هایی ارائه داد.
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده‌است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند. پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum
(1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، ۱۹۹۵) می‌شود. بعد از انتشار بیانیهٔ چابک در سال ۲۰۰۱، اکنون این‌ها به‌طور معمول به متدولوژی‌های چابک برمی‌گردند.
بیانیه‌ی چابک
در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهندهٔ نرم‌افزار، در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعهٔ چالاک گفتگو کنند.
آنها برای توصیف رویکردی که اکنون به عنوان «توسعهٔ چابک نرم‌افزار» شناخته می‌شود، بیانیه‌ای برای توسعهٔ چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این بیانیه، اتحاد Agile را ایجاد کردند؛ یک سازمان غیرانتفاعی که توسعهٔ نرم‌افزار را بر اساس اصول این بیانیه ترویج می‌دهد.
بیانیهٔ چابک به شرح زیر است:
ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعهٔ نرم‌افزار هستیم. از این کار به ارزش‌های زیر می‌رسیم:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار کارکننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.
معنی موارد سمت راست این بیانیه در مفهوم توسعهٔ چابک نرم‌افزار در زیر توضیح داده شده است:
افراد و تعاملات بالاتر از فرایندها و ابزارها
افراد مهم‌ترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می‌گردد و بر عکس افراد قوی تحت فرایند وضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران و تعامل درست و سازنده با سایر اعضای تیم خیلی مهم‌تر از این است که یک برنامه‌نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق‌تر هستند از تعدادی برنامه‌نویس عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می‌توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گران‌قیمت از برنامه رایگان کدباز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آنها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.
نرم‌افزار کارکننده بالاتر از مستندات جامع
نرم‌افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نمایید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می‌دهیم. ما آنها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می‌دهیم.
مشارکت مشتری بالاتر از قرارداد کاری
نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می‌کند بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به‌طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند.
قراردادی که مشخص‌کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به‌طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
توانایی پاسخ به تغییرات اغلب تعیین‌کنندهٔ موفقیت یا شکست یک پروژهٔ نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازهٔ کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد.
مسیر یک پروژهٔ نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندیها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفتهٔ بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.
اصول چابک
بر اساس نظرات Kent Beck، بیانیهٔ چابک، بر ۱۲ اصل استوار است:
- رضایت مشتری از طریق تحویل زود و مداومِ نرم‌افزار مفید؛
- استقبال از تغییر نیازمندیها، حتی در اواخر توسعه؛
- تحویل زود به زود نرم‌افزار قابل استفاده (هفتگی به جای ماهانه)؛
- نرم‌افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است ؛
- توسعهٔ پایدار که قادر به حفظ سرعت ثابت است؛
- همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
- گفتگوی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
- پروژه‌ها در اطراف افراد باانگیزه، که باید به آنها اعتماد کرد، شکل می‌گیرند؛
- توجه مستمر به برتری فنی و طراحی خوب؛
- سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
- بهترین معماری‌ها، نیازمندیها و طراحی‌ها از تیم‌های خودسازمانده پدیدار می‌شوند ؛
- در فواصل منظم تیم بر چگونگی مؤثرتر شدن تامل وتفکر می نماید و سپس رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می‌کند.
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد..
مشخصات
متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می‌دهند. متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که به‌طور مستقیم با برنامه‌ریزی‌های طولانی‌مدت درگیر نیستند. تکرارها فریم‌های (بسته‌های زمانی) کوتاه‌مدتی هستند که معمولاً بین یک تا چهار هفته طول می‌کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: تحلیل نیازمندیها، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذی‌نفعان نشان داده می‌شود. این، ریسک کلی را به حداقل رسانده و اجازه می‌دهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند. ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان‌دهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به‌طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می‌دهد، بر عهده می‌گیرند. آنها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.
متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌کند، افراد ارتباط روزانه‌شان را از طریق ویدئو کنفرانس، صدا، ایمیل و... حفظ می‌کنند.
مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد. در انتهای هر تکرار، ذی‌نفعان و نمایندهٔ مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به‌طور خاص شامل نمایندهٔ مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسهٔ مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»
توسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.
ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعهٔ آزمون‌محور، الگوهای طراحی، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.
توسعهٔ کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آنها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.
در توسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم‌افزار» در سال ۲۰۰۲ توصیف شد. ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.
مقایسه با متدهای دیگر
متدهایی در زنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند. متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می‌کند، یک تیم انطباقی نیز تغییر می‌کند. یک تیم انطباقی به سختی توضیح می‌دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفتهٔ آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیهٔ مأموریت (برای آن انتشار) یا بیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد.
در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم‌های پیشگویانه اغلب یک هیئت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود.
متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیم‌های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.
متدهای چابک که از دههٔ ۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعهٔ سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند نمونه‌سازی سریع تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعهٔ چابک نرم‌افزار تشویق می‌کنند.
در سال ۲۰۰۸ مؤسسهٔ مهندسی نرم‌افزار (SEI) گزارش فنی «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.
یکی از تفاوت‌های بین چابک و آبشاری، این است که تست نرم‌افزار در نقاط مختلفی در چرخهٔ عمر توسعهٔ نرم‌افزار انجام می‌شود. در مدل آبشاری، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به‌طور هم‌زمان با پیاده‌سازی انجام می‌شود. به‌طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازهٔ بلوغ تدریجی و پیاده‌سازی را می‌دهد.
متدهای چابک
متدهای معروف توسعهٔ چابک نرم‌افزار عبارتند از:
- مدل‌سازی چابک
- فرایند یکپارچهٔ چابک (AUP)
- Crystal Clear
- متدهای Crystal
- متدهای توسعهٔ سیستم‌های دینامیک (DSDM)
- برنامه‌نویسی اکستریم (XP)
- توسعهٔ ویژگی‌محور (FDD)
- طراحی گرافیکی سیستم (GSD)
- توسعه Kanban
- توسعه Lean
- Scrum
- ردیابی سرعت
سازمان‌دهی متد
در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی‌گردد، شامل «سازمان‌دهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب‌سازی متد به صورت زیر تعریف می‌شود:
فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعهٔ سیستم را برای موقعیت پروژه‌ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه‌ها، مفاهیم و قطعات متد تعریف می‌کنند.
به‌طور بالقوه، تقریباً تمام متدهای چابک برای سازمان‌دهی متد مناسب هستند. حتی متد DSDM نیز با این هدف به کار گرفته شده و با موفقیت در یک زمینهٔ CMM سازمان‌دهی می‌شود. اقتضای وضعیت، به عنوان یک مشخصهٔ متمایز بین متدهای چابک و متدهای توسعهٔ سنتی نرم‌افزار مطرح است، دومی نسبتاً جدی‌تر و تجویزی است.
پیاده‌سازی کاربردی این است که متدهای چابک به تیم‌های پروژه اجازهٔ تطبیق روش‌های کاری را با نیازهای پروژه‌های منحصربه‌فرد بدهند. روش‌ها فعالیت‌ها و محصولات به هم پیوسته‌ای هستند که بخشی از یک چارچوب متد را تشکیل می‌دهند. در یک سطح خیلی بالاتر، فلسفهٔ پشت متد، شامل تعدادی اصول است که می‌توانند منطبق باشند (Aydin، 2004).
برنامه‌نویسی Extreme (XP) نیاز به انطباق متد را شفاف می‌کند. یکی از ایده‌های بنیادین XP این است که هیچ فرایندی برای تمام پروژه‌ها مناسب نیست، اما ترجیحاً روش‌ها باید برای هر پروژهٔ منحصربه‌فرد سازمان‌دهی [مناسب‌سازی] شوند. انطباق جزئی روش‌های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش شده‌است.
یک روش سازمان‌دهی پیشنهاد می‌کند که یک نقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روش‌ها ارائه می‌دهد. روش RDP برای سفارشی‌سازی XP طراحی شده‌است. این روش، برای اولین بار در کارگاه APSO در کنفرانس ICSE 2008، به عنوان یک مقالهٔ تحقیقاتی طولانی طرح شد، و اکنون نیز تنها متد طراحی‌شده و قابل‌اجرا برای سفارشی‌سازی XP است. اگرچه این روش به‌طور خاص راه‌حلی برای XP است، اما قابلیت توسعه برای سایر متدولوژی‌ها را دارد.
در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می‌رسد، اما آزمایش‌ها با روش RDP می‌گوید این روش می‌تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینهٔ پروژه در ابتدای یک پروژه داده می‌شود و در طول اجرای پروژه نیز ثابت می‌ماند. نتیجه یک تعریف استاتیک از زمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه‌ها می‌توان تعیین کرد کدام قسمت متد ساخت‌یافته، بر اساس مجموعه‌ای از معیارهای از پیش‌تعیین‌شده، باید برای آن پروژهٔ خاص به کار رود. در مقابل، متد دینامیک انطباق، فرض می‌کند پروژه در یک زمینهٔ نوظهور واقع شده‌است. یک زمینهٔ نوظهور به این موضوع اشاره می‌کند که یک پروژه با فاکتورهای نوظهوری سر و کار خواهد داشت که بر شرایط مربوطه اثر می‌گذارند، اما قابل‌پیش‌بینی نیستند. همچنین به این معناست که زمینهٔ پروژه ثابت نیست و در طول اجرا تغییر می‌کند. در چنین موردی نقشه‌های مسیر تجویزی مناسب نیستند. مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغلب ناچارند در طول اجرای یک پروژه، قسمت‌های ساخت‌یافته را تغییر دهند یا حتی قسمت‌های جدیدی ابداع کنند (Aydin و همکاران، 2005).
چرخهٔ عمر توسعهٔ نرم‌افزار
متدهای چابک بر جنبه‌های متفاوتی از چرخهٔ عمر توسعهٔ نرم‌افزار تمرکز دارند. بعضی از آنها بر روش‌ها (برنامه‌نویسی extreme، برنامه‌نویسی فعال مدل‌سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه‌های نرم‌افزاری تأکید دارند (مانند رویکرد Scrum ). هنوز، رویکردهایی وجود دارند که تمام چرخهٔ عمر توسعه را پوشش می‌دهند (متدهای توسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آنها از فاز تعیین نیازمندیها مناسب هستند (مثلاً ویژگی‌محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعهٔ چابک نرم‌افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعهٔ نرم‌افزار ندارند، بقیهٔ آنها با درجات متفاوت این نیاز را دارند. DSDM می‌تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می‌توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo، Rankainen & Warsta، 2002).
اندازه‌گیری میزان چابکی
اگرچه چابکی به عنوان ابزاری برای پایان دیده می‌شود، تعدادی رویکرد پیشنهاد شده‌اند که کیفیت چابکی را تعیین می‌کنند. اندازه‌گیری شاخص‌های چابکی (AIM) پروژه‌ها را برای کسب یک امتیاز کل، در مقابل تعدادی از فاکتورهای چابکی امتیازدهی می‌کنند. نام مشابه «شاخص اندازه‌گیری چابکی»، توسعه‌ها را در برابر ۵ بعد یک پروژهٔ نرم‌افزاری (مدت‌زمان، ریسک، تازگی، تلاش و تعامل) امتیازدهی می‌کند. تکنیک‌های دیگر مبتنی بر اهداف قابل‌اندازه‌گیری هستند.
مطالعهٔ دیگری با استفاده از ریاضیات فازی (fuzzy)، می‌گوید سرعت پروژه می‌تواند یکی از استانداردهای چابکی باشد. خودارزیابی‌هایی در چابکی وجود دارد که تعیین می‌کند آیا یک تیم از روش‌های چابک استفاده می‌کند یا خیر (آزمون Nokia، آزمون Karlskrona، ۴۲ آزمون نکته‌ای).
اگرچه چنین رویکردهایی برای اندازه‌گیری چابکی پیشنهاد شده‌اند، کاربرد عملی چنین معیارهایی هنوز دیده می‌شود. از لحاظ تاریخی، در پروژه‌های چابکی که نتوانسته‌اند نتایج مطلوبی تولید کنند، کمبود داده وجود دارد. می‌توان مطالعاتی را یافت که پروژه‌ها را با پیاده‌سازی ناکارآمد یک (یا چند) متد چابک، ضعیف گزارش کرده‌اند، اما هیچ‌جا احساس نشد که به درستی اجرا شده‌اند و در تحویل تعهدات خود شکست خورده‌اند.
«این ممکن است یک دلیل بی‌میلی برای انتشار مقالات در مورد پروژه‌های ناموفق باشد، یا ممکن است نشان‌دهندهٔ آن باشد که وقتی متدهای چابک کار می‌کنند که پیاده‌سازی درست انجام شود.». اگرچه، داده‌هایی از ROI توسعهٔ چابک نرم‌افزار از CSIAC ROI Dashboard در دسترس است.).
آزمودگی و پذیرش
یکی از مطالعات اخیر که دستاوردهای کیفیت، بهره‌وری و رضایت کسب‌وکار با استفاده از متدهای چابک را گزارش می‌دهد، یک بررسی بود که توسط Shine Technologies از نوامبر ۲۰۰۲ تا ژانویهٔ ۲۰۰۳ انجام شد.
یک بررسی مشابه در سال ۲۰۰۶ توسط Scott Ambler (رهبر تمرین توسعهٔ چابک با گروه متدهای عقلانی IBM) انجام شد که همین فواید را بیان کرد. در بررسی انجام‌شده توسط VersionOne (یک تهیه‌کنندهٔ نرم‌افزار برای برنامه‌ریزی و پیگیری پروژه‌های توسعهٔ چابک نرم‌افزار) در سال ۲۰۰۸، ۵۵ درصد پاسخ‌دهندگان گفتند متدهای چابک در ۹۰ تا ۱۰۰ درصد موارد موفق بوده‌اند.
برخی دیگر ادعا می‌کنند متدهای توسعهٔ چابک بسیار جوان‌تر از آن هستند که نیاز به اثبات گسترده و علمی موفقیت‌شان داشته باشند.
سازگاری
بخش وسیعی از توسعهٔ چابک نرم‌افزار به صورت یک زمینهٔ تحقیقاتی پرکار باقی مانده‌است. به‌طور گسترده توسعهٔ چابک برای انواع مشخصی از محیط‌ها، شامل تیم‌های کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنهٔ Embedded در اروپا مشاهده شده‌است. بعضی مواردی که ممکن است بر موفقیت یک پروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از:
- تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده‌است؛
- تلاش‌های توسعهٔ توزیع‌شده (تیم‌های غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعهٔ دور [دورکاری]» توضیح داده شده‌است؛
- تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در آنها شکست، به هر قیمتی یک گزینه نیست (مثل نرم‌افزار کنترل ترافیک هوایی).
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند. در شرایط برون‌سپاری توسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.». متدهای چابک به‌طور گسترده برای توسعهٔ محصولات نرم‌افزاری به کار رفته‌اند، بعضی از آنها نیز از خصوصیات مشخصی از نرم‌افزار، مانند فناوری‌های موضوع استفاده می‌کنند. اگرچه این فناوری‌ها می‌توانند برای محصولات غیر نرم‌افزاری (مانند کامپیوترها، وسایل نقلیهٔ موتوری، وسایل پزشکی، خوراک و پوشاک) نیز به کار گرفته شوند. همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:
| پایهٔ اصلی چابک | پایهٔ اصلی ارزش‌محور | متدهای رسمی |
|---|---|---|
| حساسیت پایین | حساسیت بالا | حساسیت شدید |
| توسعه‌دهندگان ارشد | توسعه‌دهندگان تازه‌کار | توسعه‌دهندگان ارشد |
| نیازمندیها اغلب تغییر می‌کنند. | نیازمندیها اغلب تغییر نمی‌کنند. | نیازمندی‌های محدود، خصوصیات محدود |
| تعداد کمی از توسعه‌دهندگان | تعداد زیادی از توسعه‌دهندگان | نیازمندیها می‌توانند مدل‌سازی شوند |
| فرهنگ پاسخ به تغییر | فرهنگ نیاز به نظم | کیفیت بسیار زیاد |
نقد
ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند.
متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی بهتر به نظر می‌رسد. بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.
منابع
- ↑ Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.
- ↑ Gerald M. Weinberg, as quoted in Larman, Craig; Basili, Victor R. (2003). "Iterative and Incremental Development: A Brief History". Computer. ۳۶ (۶): ۴۷–۵۶. doi:10.1109/MC.2003.1204375. ISSN ۰۰۱۸–۹۱۶۲.
We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann، so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for 'software development. '
; - ↑ Edmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems. ۱۹: ۲۱۵–۱۸.
- ↑ http://www.gilb.com/Project-Management بایگانی‌شده در ۱۴ آوریل ۲۰۱۲ توسط Wayback Machine Evolutionary Project Management (EVO)
- ↑ Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley. p. ۲۷. ISBN 978-0-13-111155-4.
- ↑ کنت بک، Mike Beedle, Arie van Bennekum, Alistair Cockburn, وارد کانینگهام، مارتین فولر، James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Cecil Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas
- ↑ Ambler, S.W. "Examining the Agile Manifesto". Retrieved 6 April 2011.
- ↑ Beck, Kent; et al. (2001). "Principles behind the Agile Manifesto". Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.
- ↑ Anderson, David (2005). "Declaration of Interdependence". Archived from the original on 27 January 2018. Retrieved 18 September 2019.
- ↑ Beck, Kent (1999). "Embracing Change with Extreme Programming". Computer. 32 (10): 70–77. doi:10.1109/2.796139.
- ↑ Gauthier, Alexandre (17 August 2011). "What is scrum". Planbox. Archived from the original on 25 March 2012. Retrieved 5 April 2013.
- ↑ "Daily Stand-up Meeting". Planbox. Archived from the original on 10 March 2013. Retrieved 5 April 2013.
- ↑ Sliger, Michele; Broderick, Stacia (2008). The Software Project Manager's Bridge to Agility. Addison-Wesley. p. 46. ISBN 0-321-50275-2.
- ↑ Cockburn, Alistair. "Information radiator".
- ↑ Ambler, Scott (12 April 2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons. pp. 12, 164, 363. ISBN 978-0-471-20282-0.
- ↑ Boehm, B. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5. Appendix A, pages 165–194
- ↑ Black, S. E.; Boca., P. P.; Bowen, J. P.; Gorman, J.; Hinchey, M. G. (2009). "Formal versus agile: Survival of the fittest". IEEE Computer. 49 (9): 39–45.
- ↑ TECHNICAL NOTE CMU/SEI-2008-TN-003 CMMI or Agile: Why Not Embrace Both
- ↑ CMMI Product Team, ; CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software Engineering Institute, Carnegie Mellon University, 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm
- ↑ Aydin, M.N. , Harmsen, F. , Slooten, K. v. , & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
- ↑ Abrahamsson, P. , Warsta, J. , Siponen, M.T. , & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254
- ↑ Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
- ↑ Aydin, M.N. , Harmsen, F. , Slooten van K. , & Stegwee, R.A. (2005). On the Adaptation of An Agile Information(Suren) Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
- ↑ "David Bock's Weblog: Weblog". Jroller.com. Archived from the original on 11 January 2006. Retrieved 2 April 2010.
- ↑ "Agility measurement index". Doi.acm.org. Retrieved 2 April 2010.
- ↑ Peter Lappo. "Assessing Agility" (PDF). Archived from the original (PDF) on 15 September 2009. Retrieved 6 June 2010.
- ↑ Kurian, Tisni (2006). Agility Metrics: A Quantitative Fuzzy Based Approach for Measuring Agility of a Software Process, ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, U.S.
- ↑ Joe Little (2 December 2007). "Nokia test, A scrum-specific test". Agileconsortium.blogspot.com. Retrieved 6 June 2010.
- ↑ Mark Seuffert, Piratson Technologies, Sweden. "Karlskrona test, A generic agile adoption test". Piratson.se. Archived from the original on 24 March 2012. Retrieved 6 June 2010.
- ↑ "How agile are you, a scrum-specific test". Agile-software-development.com. Archived from the original on 5 March 2010. Retrieved 6 June 2010.
- ↑ CSIAC ROI Dashboard بایگانی‌شده در ۹ مه ۲۰۱۳ توسط Wayback Machine Retrieved 11 November 2011.
- ↑ "Agile Methodologies Survey Results" (PDF). Shine Technologies. 2003. Archived from the original (PDF) on 21 August 2010. Retrieved 3 June 2010.
95% [stated] that there was either no effect or a cost reduction ... 93% stated that productivity was better or significantly better ... 88% stated that quality was better or significantly better ... 83% stated that business satisfaction was better or significantly better
; - ↑ Ambler, Scott (3 August 2006). "Survey Says: Agile Works in Practice". Dr. Dobb's. Archived from the original on 4 February 2011. Retrieved 3 June 2010.
Only 6 percent indicated that their productivity was lowered ... No change in productivity was reported by 34 percent of respondents and 60 percent reported increased productivity ... 66 percent [responded] that the quality is higher ... 58 percent of organizations report improved satisfaction, whereas only 3 percent report reduced satisfaction.
- ↑ "The State of Agile Development" (PDF). VersionOne, Inc. 2008. Retrieved 3 July 2010.
Agile delivers
- ↑ "Answering the "Where is the Proof That Agile Methods Work" Question". Agilemodeling.com. 19 January 2007. Retrieved 2 April 2010.
- ↑ Barlow, Jordan B. (2011). "Overview and Guidance on Agile Development in Large Organizations". Communications of the Association for Information Systems. 29 (1): 25–44.
- ↑ Kupe Kupersmith, "Agile is a Fad"
- ↑ Christopher R. Goldsbury, "The Agile Management Fad"
- ↑ «Luke Halliwell, "The Agile Disease"». بایگانی‌شده از اصلی در ۱ آوریل ۲۰۱۳. دریافت‌شده در ۵ آوریل ۲۰۱۳.
پیوند به بیرون
- Two Ways to Build a Pyramid, John Mayo-Smith (VP Of Technology At R/GA), ۲۲ اکتبر ۲۰۰۱
- The New Methodology مارتین فولر's description of the background to agile methods
- Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
- A look into the PMI-ACP (Agile Certified Practitioner)
- Agile Manifesto
- Agile Alliance