|
== تاریخچه ==
=== سوابق ===
[[پرونده:Martin Fowler (2008).jpg|بندانگشتی|چپ|[[مارتین فولر]],، به عنوان یکی از بنیان‌گذاران کلیدی متدهای چابک شناخته می‌شود.]]
متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند.<ref name="craig2003"/> در سال 1974،۱۹۷۴، E.A. Edmonds در مقاله‌ای فرایند توسعهٔ تطبیقی نرم‌افزار را معرفی کرد.<ref name="edmonds1974">{{Cite journal| last=Edmonds| first=E. A.| title= A Process for the Development of Software for Nontechnical Users as an Adaptive System| journal=General Systems| volume=۱۹| year=۱۹۷۴| pages=۲۱۵–۱۸}}</ref> هم‌زمان و به طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم‌های [[شرکت تلفن]] نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ 1970،۱۹۷۰، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت.<ref name="EvolutionaryProjectManagement">http://www.gilb.com/Project-Management Evolutionary Project Management (EVO)</ref> در طول نیمه تا انتهای دههٔ 1970 Gielan به طور گسترده در [[ایالات متحده]] در مورد این متدولوژی، تجارب و فواید آن سخنرانی‌هایی ارائه داد.<ref name="craig2003">[[Gerald M. Weinberg]], as quoted in {{cite journal
|last=Larman | first=Craig |first2 =Victor R. |last2=Basili
|year=۲۰۰۳ | month=June
|title=Iterative and Incremental Development: A Brief History
|journal=Computer |volume=۳۶ |issue=۶ |pages=۴۷–۵۶ |doi=10.1109/MC.2003.1204375 |issn=۰۰۱۸-۹۱۶۲۰۰۱۸–۹۱۶۲
|quote=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 [[جان فون نویمان]],، 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. '}}</ref>
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند.
پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum (1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، 1995۱۹۹۵) می‌شود. بعد از انتشار مانیفست چابک در سال ۲۰۰۱، اکنون این‌ها به طور معمول به متدولوژی‌های چابک برمی‌گردند.<ref name="Larman2004">{{Cite book | last=Larman | first=Craig | year=۲۰۰۴ | title=Agile and Iterative Development: A Manager's Guide | publisher=Addison-Wesley | isbn=۹۷۸-۰-۱۳-۱۱۱۱۵۵-۴ | page=۲۷ | postscript=<!--None-->}}</ref>
== مانیفست چابک ==
در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهنده‌یتوسعه‌دهندهٔ نرم‌افزار، <ref>[[کنت بک]] ,، Mike Beedle, Arie van Bennekum, [[Alistair Cockburn]], [[وارد کانینگهام]] ,، [[مارتین فولر]] ,، James Grenning, [[Jim Highsmith]], [[Andy Hunt (author)|Andrew Hunt]], [[Ron Jeffries]], Jon Kern, [[Brian Marick]], [[Robert C. Martin]], [[Stephen J. Mellor]], [[Ken Schwaber]], [[Jeff Sutherland]], and [[Dave Thomas (programmer)|Dave Thomas]]</ref> در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعه‌یتوسعهٔ چالاک گفتگو کنند. ▼
آنها برای توصیف رویکردی که اکنون به عنوان « توسعه‌یتوسعهٔ چابک نرم‌افزار» شناخته می‌شود، مانیفستی برای توسعه‌یتوسعهٔ چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این مانیفست اتحاد Agile را ایجاد کردند کردند،<ref name="Agile Manifesto"/> ، یک سازمان غیرانتفاعی که توسعه‌یتوسعهٔ نرم‌افزار را بر اساس اصول مانیفست ترویج می‌دهند. ▼▲در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهنده‌ی نرم‌افزار، <ref>[[کنت بک]], Mike Beedle, Arie van Bennekum, [[Alistair Cockburn]], [[وارد کانینگهام]], [[مارتین فولر]], James Grenning, [[Jim Highsmith]], [[Andy Hunt (author)|Andrew Hunt]], [[Ron Jeffries]], Jon Kern, [[Brian Marick]], [[Robert C. Martin]], [[Stephen J. Mellor]], [[Ken Schwaber]], [[Jeff Sutherland]], and [[Dave Thomas (programmer)|Dave Thomas]]</ref> در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعه‌ی چالاک گفتگو کنند.
▲آنها برای توصیف رویکردی که اکنون به عنوان «توسعه‌ی چابک نرم‌افزار» شناخته می‌شود، مانیفستی برای توسعه‌ی چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این مانیفست اتحاد Agile را ایجاد کردند <ref name="Agile Manifesto"/>، یک سازمان غیرانتفاعی که توسعه‌ی نرم‌افزار را بر اساس اصول مانیفست ترویج می‌دهند.
تمام مانیفست چابک به شرح زیر است:
<blockquote>ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه هایراه‌های بهتری برای توسعه نرم‌افزار هستیم. از این کار به ارزش هایارزش‌های زیر میرسیم :
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار کار کننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.<ref name="Agile Manifesto"/></blockquote>
معنی آیتم‌های سمت راست مانیفست در مفهوم توسعه‌یتوسعهٔ چابک نرم‌افزار در زیر توضیح داده شده است:
=== افراد و تعاملات بالاتر از فرایندها و ابزارها ===
افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست میگردد و بر عکس افراد قوی تحت فرایند ضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه نویسیبرنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه نویسیبرنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویسبرنامه‌نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسیبرنامه‌نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال میتوانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آنها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.
=== نرم‌افزار کار کننده بالاتر از مستندات جامع ===
=== نرم‌افزار کار کننده بالاتر از مستندات جامع ===
نرم‌افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازیپیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می گیردمی‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می شوندمی‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می توانیممی‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال میدهیم. ما آنها را بخشی از تیم میکنیم و با تعامل نزدیک و رو در رو به آنها آموزش میدهیم.
=== مشارکت مشتری بالاتر از قرارداد کاری === ▼
▲=== مشارکت مشتری بالاتر از قرارداد کاری ===
نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می خواهیدمی‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می کند،می‌کند، بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می انجامدمی‌انجامد. پروژه هایپروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه هایبازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند.
قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم افزارنرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
=== پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه ===
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیرانعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد. ▼
مسیر یک پروژه نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه ریزیبرنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندی هانیازمندی‌ها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می دهند.می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمیکنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است. ▼▲توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
یک استراتژی خوب برای برنامه ریزیبرنامه‌ریزی این است که یک برنامه ریزیبرنامه‌ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزیبرنامه‌ریزی کلی برای سه ماه بعد.<ref name="abmmw">Ambler, S.W. [http://www.ambysoft.com/essays/agileManifesto.html "Examining the Agile Manifesto"]. Retrieved 6 April 2011.</ref> ▼▲مسیر یک پروژه نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندی ها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می دهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمیکنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
▲یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.<ref name="abmmw">Ambler, S.W. [http://www.ambysoft.com/essays/agileManifesto.html "Examining the Agile Manifesto"]. Retrieved 6 April 2011.</ref>
=== اصول چابک ===
بر اساس نظرات Kent Beck<ref name="manifestoprinciples">{{cite web
* نرم‌افزار کار زود به زود تحویل می‌شود (هفتگی به جای ماهانه)؛
* نرم‌افزار کار مقیاس اصلی پیشرفت است؛
* توسعه‌یتوسعهٔ پایدار، قادر به حفظ سرعت ثابت است؛
* همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
* مکالمه‌یمکالمهٔ رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
* پروژه‌ها در اطراف افراد باانگیزه، که باید به آنها اعتماد کرد، شکل می‌گیرند؛
* توجه مستمر به برتری فنی و طراحی خوب؛
* انطباق با تغییرات محدودیت‌ها به طور منظم.
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیه‌یاعلامیهٔ وابستگی» برای اصول [[مدیریت پروژه]] نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعه‌یتوسعهٔ نرم‌افزار پیش ببرد.<ref>{{cite web
|url=http://pmdoi.org
|first=David |last=Anderson
== مشخصات ==
[[پرونده:Pair programming 1.jpg|200px|بندانگشتی|چپ|برنامه‌نویسی دو جزئی، یکی از تکنیک‌های توسعه‌یتوسعهٔ چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.]]
متدهای توسعه‌یتوسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخه‌یچرخهٔ حیات پروژه را ترفیع می‌دهند.
متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که به طور مستقیم با برنامه‌ریزی‌های طولانی‌مدت درگیر نیستند. تکرارها فریم‌های (بسته‌های زمانی) کوتاه‌مدتی هستند که معمولاً بین یک تا چهار هفته طول می‌کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: [[تحلیل نیازمندیها]]، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذی‌نفعان نشان داده می‌شود. این، ریسک کلی را به حداقل رسانده و اجازه می‌دهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکراهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند.<ref name="embracing change">{{cite journal|
last=Beck|first=Kent|
pages=70–77|
doi=10.1109/2.796139}}</ref>
ترکیب تیم در یک پروژه‌یپروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان‌دهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می‌دهد، بر عهده می‌گیرند. آنها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.
متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین 5۵ تا 9۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌کند، افراد ارتباط روزانه‌شان را از طریق [[ویدئو کنفرانس]]، صدا، ایمیل و... حفظ می‌کنند.
[[مهم نیست]] چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد. <ref>{{cite web |url=http://www.planbox.com/resources/agile-artifacts#roles |title=What is scrum |publisher=Planbox |first=Alexandre|last=Gauthier|date=17 August 2011}}</ref> در انتهای هر تکرار، ذی‌نفعان و نماینده‌ینمایندهٔ مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیر رسمی،غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند.
این به طور خاص شامل نماینده‌ینمایندهٔ مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسه‌یجلسهٔ مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از 15۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»<ref>{{cite web|title=Daily Stand-up Meeting|url=http://www.planbox.com/resources/daily-scrum|publisher=Planbox}}</ref>
توسعه‌یتوسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.<ref name="PMBridgeToAgility">{{Cite book |last1=Sliger |first1=Michele |last2=Broderick |first2=Stacia |title=The Software Project Manager's Bridge to Agility |publisher=Addison-Wesley |year=2008 |isbn=0-321-50275-2 |page=46}}</ref>
ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعه‌یتوسعهٔ آزمون‌محور، [[الگوهای طراحی]]، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.
توسعه‌یتوسعهٔ کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجه‌یدرجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آنها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.
در توسعه‌یتوسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعه‌یتوسعهٔ چابک نرم‌افزار» در سال 2002۲۰۰۲ توصیف شد. <ref name="Cockburn, Information radiator">{{Cite web
|url=http://alistair.cockburn.us/Information+radiator
|title=Information radiator
|last=Cockburn |first=Alistair |authorlink=Alistair Cockburn
}}</ref><ref name=Ambler>{{cite book |title=Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process |first=Scott |last=Ambler |date=12 April 2002 |isbn=978-0-471-20282-0 |publisher=John Wiley & Sons |pages=12, 164, 363}}</ref>
ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.
== مقایسه با متدهای دیگر ==
متدهایی در زنجیره‌یزنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند. <ref name="boehm2004App">{{cite book|last=Boehm|first=B.|authorlink=Barry Boehm|coauthors=[[Richard Turner (software)|R. Turner]]|title=Balancing Agility and Discipline: A Guide for the Perplexed|publisher=Addison-Wesley|location=Boston, MA|year=2004|isbn=0-321-18612-5}} Appendix A, pages 165–194</ref> متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می‌کند، یک تیم انطباقی نیز تغییر می‌کند. یک تیم انطباقی به سختی توضیح می‌دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفته‌یهفتهٔ آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیه‌یبیانیهٔ مأموریت (برای آن انتشار) یا بیانیه‌یبیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد. ▼
در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم‌های پیشگویانه اغلب یک هیأتهیئت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود. ▼▲متدهایی در زنجیره‌ی بین انطباقی تا پیشگویانه وجود دارند. <ref name="boehm2004App">{{cite book|last=Boehm|first=B.|authorlink=Barry Boehm|coauthors=[[Richard Turner (software)|R. Turner]]|title=Balancing Agility and Discipline: A Guide for the Perplexed|publisher=Addison-Wesley|location=Boston, MA|year=2004|isbn=0-321-18612-5}} Appendix A, pages 165–194</ref> متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می‌کند، یک تیم انطباقی نیز تغییر می‌کند. یک تیم انطباقی به سختی توضیح می‌دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفته‌ی آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیه‌ی مأموریت (برای آن انتشار) یا بیانیه‌ی ارزش موردانتظار در مقابل هزینه را گزارش دهد.
متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیم‌های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.<ref name="black2009">{{Cite journal| last1=Black| first1=S. E.| last2=Boca.| first2=P. P.| last3=Bowen| first3=J. P.| last4=Gorman| first4=J.| last5= Hinchey| first5=M. G.| authorlink1=Sue Black (computer scientist)| authorlink3=Jonathan Bowen| authorlink5=Michael Hinchey| title= Formal versus agile: Survival of the fittest| journal=[[IEEE Computer]]| volume=49| issue=9| month=September| year=2009| pages=39–45}}</ref> ▼▲در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم‌های پیشگویانه اغلب یک هیأت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود.
متدهای چابک که از دهه‌یدههٔ 90-1980۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با « توسعه‌یتوسعهٔ سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند [[نمونه‌سازی سریع]] تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعه‌یتوسعهٔ چابک نرم‌افزار تشویق می‌کنند. ▼▲متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیم‌های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.<ref name="black2009">{{Cite journal| last1=Black| first1=S. E.| last2=Boca.| first2=P. P.| last3=Bowen| first3=J. P.| last4=Gorman| first4=J.| last5= Hinchey| first5=M. G.| authorlink1=Sue Black (computer scientist)| authorlink3=Jonathan Bowen| authorlink5=Michael Hinchey| title= Formal versus agile: Survival of the fittest| journal=[[IEEE Computer]]| volume=49| issue=9| month=September| year=2009| pages=39–45}}</ref>
در سال 2008۲۰۰۸ مؤسسه‌یمؤسسهٔ [[مهندسی نرم‌افزار]] (SEI) [[گزارش فنی]] «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچه‌ییکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن 1.3۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.<ref>[http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm TECHNICAL NOTE CMU/SEI-2008-TN-003 CMMI or Agile: Why Not Embrace Both]</ref><ref>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</ref> ▼▲متدهای چابک که از دهه‌ی 90-1980 توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعه‌ی سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند [[نمونه‌سازی سریع]] تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعه‌ی چابک نرم‌افزار تشویق می‌کنند.
یکی از تفاوت‌های بین چابک و آبشاری، این است که [[تست نرم‌افزار]] در نقاط مختلفی در چرخه‌یچرخهٔ عمر توسعه‌یتوسعهٔ نرم‌افزار انجام می‌شود. در [[مدل آبشاری]]، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به طور هم‌زمان با پیاده‌سازی انجام می‌شود. به طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشده‌یشناخته‌نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازه‌یاجازهٔ بلوغ تدریجی و پیاده‌سازی را می‌دهد. ▼▲در سال 2008 مؤسسه‌ی [[مهندسی نرم‌افزار]] (SEI) [[گزارش فنی]] «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچه‌ی قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن 1.3 شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.<ref>[http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm TECHNICAL NOTE CMU/SEI-2008-TN-003 CMMI or Agile: Why Not Embrace Both]</ref><ref>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</ref>
▲یکی از تفاوت‌های بین چابک و آبشاری، این است که [[تست نرم‌افزار]] در نقاط مختلفی در چرخه‌ی عمر توسعه‌ی نرم‌افزار انجام می‌شود. در [[مدل آبشاری]]، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به طور هم‌زمان با پیاده‌سازی انجام می‌شود. به طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشده‌ی زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازه‌ی بلوغ تدریجی و پیاده‌سازی را می‌دهد.
== متدهای چابک ==
متدهای معروف توسعه‌یتوسعهٔ چابک نرم‌افزار عبارتند از:
* مدل‌سازی چابک
* فرایند یکپارچه‌ییکپارچهٔ چابک (AUP)
* Crystal Clear
* متدهای Crystal
* متدهای توسعه‌یتوسعهٔ سیستم‌های دینامیک (DSDM)
* برنامه‌نویسی اکستریم (XP)
* توسعه‌یتوسعهٔ ویژگی‌محور (FDD)
* طراحی گرافیکی سیستم (GSD)
* توسعه Kanban
* توسعه Lean
* Scrum
* ردیابی سرعت
=== سازمان‌دهی متد ===
در ،در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی‌گردد، شامل «سازمان‌دهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب‌سازی متد به صورت زیر تعریف می‌شود:
<blockquote>فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعه‌یتوسعهٔ سیستم را برای موقعیت پروژه‌ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه‌ها، مفاهیم و قطعات متد تعریف می‌کنند.<ref name="Aydin2004">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</ref></blockquote>
به طور بالقوه، تقریباً تمام متدهای چابک برای سازمان‌دهی متد مناسب هستند. حتی متد DSDM نیز با این هدف به کار گرفته شده و با موفقیت در یک زمینه‌یزمینهٔ CMM سازمان‌دهی می‌شود.<ref name="Abrahamsson2003">Abrahamsson, P. , Warsta, J. , Siponen, M.T. , & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254</ref> اقتضای وضعیت، به عنوان یک مشخصه‌یمشخصهٔ متمایز بین متدهای چابک و متدهای توسعه‌یتوسعهٔ سنتی نرم‌افزار مطرح است، دومی نسبتاً جدی‌تر و تجویزی است.
پیاده‌سازی کاربردی این است که متدهای چابک به تیم‌های پروژه اجازه‌یاجازهٔ تطبیق روش‌های کاری را با نیازهای پروژه‌های منحصربه‌فرد بدهند. روش‌ها فعالیت‌ها و محصولات به هم پیوسته‌ای هستند که بخشی از یک چارچوب متد را تشکیل می‌دهند. در یک سطح خیلی بالاتر، فلسفه‌یفلسفهٔ پشت متد، شامل تعدادی اصول است که می‌توانند منطبق باشند (Aydin، 2004).<ref name="Aydin2004"/>
برنامه‌نویسی Extreme (XP) نیاز به انطباق متد را شفاف می‌کند. یکی از ایده‌های بنیادین XP این است که هیچ فرایندی برای تمام پروژه‌ها مناسب نیست، اما ترجیحاً روش‌ها باید برای هر پروژه‌یپروژهٔ منحصربه‌فرد سازمان‌دهی [مناسب‌سازی] شوند. انطباق جزئی روش‌های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش شده است.<ref name="Abrahamsson2002">Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. ''VTT Publications 478''</ref>
یک روش سازمان‌دهی پیشنهاد می‌کند که یک نقشه‌ینقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روش‌ها ارائه می‌دهد. روش RDP برای سفارشی‌سازی XP طراحی شده است. این روش، برای اولین بار در کارگاه APSO در کنفرانس ICSE 2008، به عنوان یک مقاله‌یمقالهٔ تحقیقاتی طولانی طرح شد، و اکنون نیز تنها متد طراحی‌شده و قابل‌اجرا برای سفارشی‌سازی XP است. اگرچه این روش به طور خاص راه‌حلی برای XP است، اما قابلیت توسعه برای سایر متدولوژی‌ها را دارد.<ref name="Aydin2005">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</ref>
در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می‌رسد، اما آزمایش‌ها با روش RDP می‌گوید این روش می‌تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینه‌یزمینهٔ پروژه در ابتدای یک پروژه داده می‌شود و در طول اجرای پروژه نیز ثابت می‌ماند. نتیجه یک تعریف استاتیک از زمینه‌یزمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه‌ها می‌توان تعیین کرد کدام قسمت متد ساخت‌یافته، بر اساس مجموعه‌ای از معیارهای از پیش‌تعیین‌شده، باید برای آن پروژه‌یپروژهٔ خاص به کار رود.
در مقابل، متد دینامیک انطباق، فرض می‌کند پروژه در یک زمینه‌یزمینهٔ نوظهور واقع شده است. یک زمینه‌یزمینهٔ نوظهور به این موضوع اشاره می‌کند که یک پروژه با فاکتورهای نوظهوری سر و کار خواهد داشت که بر شرایط مربوطه اثر می‌گذارند، اما قابل‌پیش‌بینی نیستند. همچنین به این معناست که زمینه‌یزمینهٔ پروژه ثابت نیست و در طول اجرا تغییر می‌کند. در چنین موردی نقشه‌های مسیر تجویزی مناسب نیستند.
مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغلب ناچارند در طول اجرای یک پروژه، قسمت‌های ساخت‌یافته را تغییر دهند یا حتی قسمت‌های جدیدی ابداع کنند (Aydin و همکاران، 2005).<ref name="Aydin2005"/>
=== چرخه‌یچرخهٔ عمر توسعه‌یتوسعهٔ نرم‌افزار ===
[[پرونده:SoftwareDevelopmentLifeCycle.jpg|بندانگشتی|چپ|چرخه‌یچرخهٔ عمر پشتیبانی از توسعه‌یتوسعهٔ نرم‌افزار<ref name="Abrahamsson2002"/>]]
متدهای چابک بر جنبه‌های متفاوتی از چرخه‌یچرخهٔ عمر توسعه‌یتوسعهٔ نرم‌افزار تمرکز دارند. بعضی از آنها بر روش‌ها (برنامه‌نویسی extreme، برنامه‌نویسی فعال مدل‌سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه‌های نرم‌افزاری تأکید دارند (مانند رویکرد scrum). هنوز، رویکردهایی وجود دارند که تمام چرخه‌یچرخهٔ عمر توسعه را پوشش می‌دهند (متدهای توسعه‌یتوسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آنها از فاز تعیین نیازمندیها مناسب هستند (مثلاً ویژگی‌محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعه‌یتوسعهٔ چابک نرم‌افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعه‌یتوسعهٔ نرم‌افزار ندارند، بقیه‌یبقیهٔ آنها با درجات متفاوت این نیاز را دارند. DSDM می‌تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می‌توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo، Rankainen & Warsta، 2002). <ref name="Abrahamsson2002"/>
== اندازه‌گیری میزان چابکی ==
اگرچه چابکی به عنوان ابزاری برای پایان دیده می‌شود، تعدادی رویکرد پیشنهاد شده‌اند که کیفیت چابکی را تعیین می‌کنند. اندازه‌گیری شاخص‌های چابکی (AIM) پروژه‌ها را برای کسب یک امتیاز کل، در مقابل تعدادی از فاکتورهای چابکی امتیازدهی می‌کنند. نام مشابه «شاخص اندازه‌گیری چابکی»، توسعه‌ها را در برابر 5۵ بعد یک پروژه‌یپروژهٔ نرم‌افزاری (مدت‌زمان، ریسک، تازگی، تلاش و تعامل) امتیازدهی می‌کند. تکنیک‌های دیگر مبتنی بر اهداف قابل‌اندازه‌گیری هستند.
مطالعه‌یمطالعهٔ دیگری با استفاده از ریاضیات فازی (fuzzy)، می‌گوید سرعت پروژه می‌تواند یکی از استانداردهای چابکی باشد. خودارزیابی‌هایی در چابکی وجود دارد که تعیین می‌کند آیا یک تیم از روش‌های چابک استفاده می‌کند یا خیر (آزمون Nokia، آزمون Karlskrona، 42۴۲ آزمون نکته‌ای).<ref>{{cite web|url=http://jroller.com/page/bokmann?entry=improving_your_processes_aim_high |title=David Bock's Weblog : Weblog |publisher=Jroller.com |date= |accessdate=2 April 2010}}</ref><ref>{{cite web|url=http://doi.acm.org/10.1145/1185448.1185509 |title=Agility measurement index |publisher=Doi.acm.org |date= |accessdate=2 April 2010}}</ref>
اگرچه چنین رویکردهایی برای اندازه‌گیری چابکی پیشنهاد شده‌اند، کاربرد عملی چنین معیارهایی هنوز دیده می‌شود.
از لحاظ تاریخی، در پروژه‌های چابکی که نتوانسته‌اند نتایج مطلوبی تولید کنند، [[کمبود داده]] وجود دارد. می‌توان مطالعاتی را یافت که پروژه‌ها را با پیاده‌سازی ناکارآمد یک (یا چند) متد چابک، ضعیف گزارش کرده‌اند، اما هیچ‌جا احساس نشد که به درستی اجرا شده‌اند و در تحویل تعهدات خود شکست خورده‌اند.<ref>{{cite web|url=http://www.smr.co.uk/presentations/measure.pdf |title=Assessing Agility |author=Peter Lappo |coauthors=Henry C.T. Andrew |publisher= |date= |accessdate=6 June 2010}}</ref><ref name="Kurian 2006">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.</ref><ref>{{cite web|url=http://agileconsortium.blogspot.com/2007/12/nokia-test.html |title=Nokia test, A scrum-specific test |author=Joe Little |publisher=Agileconsortium.blogspot.com |date=2 December 2007 |accessdate=6 June 2010}}</ref>
«این ممکن است یک دلیل بی‌میلی برای انشتار مقالات در مورد پروژه‌های ناموفق باشد، یا ممکن است نشان‌دهنده‌ینشان‌دهندهٔ آن باشد که وقتی متدهای چابک کار می‌کنند که پیاده‌سازی درست انجام شود.». اگرچه، داده‌هایی از ROI توسعه‌یتوسعهٔ چابک نرم‌افزار از CSIAC ROI Dashboard در دسترس است.<ref>{{cite web|author=Mark Seuffert, Piratson Technologies, Sweden |url=http://www.piratson.se/archive/Agile_Karlskrona_Test.html |title=Karlskrona test, A generic agile adoption test |publisher=Piratson.se |date= |accessdate=6 June 2010}}</ref><ref>{{cite web|url=http://www.agile-software-development.com/2008/01/how-agile-are-you-take-this-42-point.html |title=How agile are you, a scrum-specific test |publisher=Agile-software-development.com |date= |accessdate=6 June 2010}}</ref>).<ref name="CSIAC_ROI">[https://sw.thecsiac.com/databases/roi/ CSIAC ROI Dashboard] Retrieved 11 November 2011.</ref>
== آزمودگی و پذیرش ==
یکی از مطالعات اخیر که دستاوردهای کیفیت، بهره‌وری و رضایت کسب‌وکار با استفاده از متدهای چابک را گزارش می‌دهد، یک بررسی بود که توسط Shine Technologies از نوامبر 2002۲۰۰۲ تا ژانویه‌یژانویهٔ 2003۲۰۰۳ انجام شد. <ref>{{cite web |url= http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf |title= Agile Methodologies Survey Results |year=2003 |month=January |publisher= [http://www.shinetech.com Shine Technologies] |format=PDF |accessdate=3 June 2010 |quote=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}}</ref>
یک بررسی مشابه در سال 2006۲۰۰۶ توسط Scott Ambler (رهبر تمرین توسعه‌یتوسعهٔ چابک با گروه متدهای عقلانی IBM) انجام شد که همین فواید را بیان کرد. در بررسی انجام‌شده توسط VersionOne (یک تهیه‌کننده‌یتهیه‌کنندهٔ نرم‌افزار برای برنامه‌ریزی و پیگیری پروژه‌های توسعه‌یتوسعهٔ چابک نرم‌افزار) در سال 2008،۲۰۰۸، 55۵۵ درصد پاسخ‌دهندگان گفتند متدهای چابک در 90۹۰ تا 100۱۰۰ درصد موارد موفق بوده‌اند. <ref>{{cite web |url= http://www.drdobbs.com/architecture-and-design/191800169;jsessionid=2QJ23QRYM3H4PQE1GHPCKH4ATMY32JVN?queryText=agile+survey |title=Survey Says: Agile Works in Practice |first=Scott |last=Ambler |authorlink=Scott Ambler |date=3 August 2006 |work=Dr. Dobb's |accessdate=3 June 2010 |quote=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.}}</ref>
برخی دیگر ادعا می‌کنند متدهای توسعه‌یتوسعهٔ چابک بسیار جوان‌تر از آن هستند که نیاز به اثبات گسترده و علمی موفقیت‌شان داشته باشند.<ref>{{cite web |url= http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf |title= The State of Agile Development |year=2008 |publisher=VersionOne, Inc. |format=PDF |accessdate=3 July 2010 |quote= Agile delivers}}</ref><ref>{{cite web|url=http://www.agilemodeling.com/essays/proof.htm |title=Answering the "Where is the Proof That Agile Methods Work" Question |publisher=Agilemodeling.com |date=19 January 2007 |accessdate=2 April 2010}}</ref>
=== سازگاری ===
بخش وسیعی از توسعه‌یتوسعهٔ چابک نرم‌افزار به صورت یک زمینه‌یزمینهٔ تحقیقاتی پرکار باقی‌مانده است. به طور گسترده توسعه‌یتوسعهٔ چابک برای انواع مشخصی از محیط‌ها، شامل تیم‌های کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنه‌یدامنهٔ Embedded در اروپا مشاهده شده است. ▼
بعضی مواردی که ممکن است بر موفقیت یک پروژه‌یپروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از: ▼▲بخش وسیعی از توسعه‌ی چابک نرم‌افزار به صورت یک زمینه‌ی تحقیقاتی پرکار باقی‌مانده است. به طور گسترده توسعه‌ی چابک برای انواع مشخصی از محیط‌ها، شامل تیم‌های کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنه‌ی Embedded در اروپا مشاهده شده است.
* تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده است؛
▲بعضی مواردی که ممکن است بر موفقیت یک پروژه‌ی چابک، تأثیر منفی بگذارد، عبارتند از:
* تلاش‌های توسعهتوسعهٔ در مقیاس وسیعتوزیع‌شده (>20تیم‌های توسعه‌گرغیرهم‌مکان)،. اگرچهاستراتژی‌ها استراتژی‌هایدر مقیاس‌گذاری«پل‌بندی و مدارکفاصله» و «استفاده از فرایند چابک نرم‌افزار با بعضیتوسعهٔ پروژه‌هایدور بزرگ[دورکاری]» توضیح داده شده است؛
* تلاش‌های توسعه‌ی توزیع‌شده (تیم‌های غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعه‌ی دور [دورکاری]» توضیح داده شده است؛
* تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در آنها شکست، به هر قیمتی یک گزینه نیست (مثل نرم‌افزار کنترل ترافیک هوایی).
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند.
در شرایط برون‌سپاری توسعه‌یتوسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.».
متدهای چابک به طور گسترده برای توسعه‌یتوسعهٔ محصولات نرم‌افزاری به کار رفته‌اند، بعضی از آنها نیز از خصوصیات مشخصی از نرم‌افزار، مانند فناوری‌های موضوع استفاده می‌کنند. اگرچه این فناوری‌ها می‌توانند برای محصولات غیر نرم‌افزاری (مانند کامپیوترها، وسایل نقلیه‌ینقلیهٔ موتوری، وسایل پزشکی، خوراک و پوشاک) نیز به کار گرفته شوند.
همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایه‌یپایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:
{| class="wikitable"
|+ سازگاری متدهای متفاوت توسعه
|-
! پایه‌یپایهٔ اصلی چابک
! پایه‌یپایهٔ اصلی ارزش‌محور
! متدهای رسمی
|-
== نقد ==
ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند. <ref>{{cite journal|last=Barlow|first=Jordan B.|coauthors=Justin Scott Giboney, Mark Jeffery Keith, David W. Wilson, Ryan M. Schuetzler, Paul Benjamin Lowry, Anthony Vance|title=Overview and Guidance on Agile Development in Large Organizations|journal=Communications of the Association for Information Systems|year=2011|volume=29|issue=1|pages=25–44|url=http://aisel.aisnet.org/cais/vol29/iss1/2/}}</ref>
متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی بهتر به نظر می‌رسد. بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.<ref>[http://www.batimes.com/kupe-kupersmith/agile-is-a-fad.html Kupe Kupersmith, "Agile is a Fad"]</ref><ref>[http://anagilestory.com/2012/08/21/the-agile-management-fad Christopher R. Goldsbury, "The Agile Management Fad"]</ref><ref>[http://lukehalliwell.wordpress.com/2008/11/16/the-agile-disease/ Luke Halliwell, "The Agile Disease"]</ref>
{{wikibooks|Software Engineering with an Agile Development Framework}}<!--Wikibook under construction-->
<!--Official Web sites of founding organization, seminal documents, etc. -->
* [http://www.informationweek.com/two-ways-to-build-a-pyramid/6507351 Two Ways to Build a Pyramid], John Mayo-Smith (VP Of Technology At [[R/GA]]), October۲۲ 22,اکتبر 2001۲۰۰۱
<!--Articles, papers, essays-->
* [http://martinfowler.com/articles/newMethodology.html The New Methodology] [[مارتین فولر]]'s description of the background to agile methods
| 