توسعه نرم‌افزاری چابک: تفاوت میان نسخه‌ها
محتوای حذف‌شده محتوای افزوده‌شده
FreshmanBot (بحث | مشارکت‌ها) جز اصلاح فاصله مجازی + اصلاح نویسه با استفاده از AWB |
|||
خط ۱۱:
[[پرونده:Martin Fowler (2008).jpg|بندانگشتی|چپ|[[مارتین فولر]]، به عنوان یکی از بنیان‌گذاران کلیدی متدهای چابک شناخته می‌شود.]]
متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند.<ref name="craig2003"/> در سال ۱۹۷۴، 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> هم‌زمان و
|last=Larman | first=Craig |first2 =Victor R. |last2=Basili
|year=۲۰۰۳ | month=June
خط ۱۸:
|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 [[جان فون نویمان|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. '}}</ref>
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف
پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum (1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، ۱۹۹۵) می‌شود. بعد از انتشار مانیفست چابک در سال ۲۰۰۱، اکنون این‌ها
== مانیفست چابک ==
خط ۳۲:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار
۳- مشارکت مشتری بالاتر از قرارداد کاری
خط ۴۳:
=== افراد و تعاملات بالاتر از فرایندها و ابزارها ===
افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست
یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال میتوانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به
=== نرم‌افزار
نرم‌افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به
=== مشارکت مشتری بالاتر از قرارداد کاری ===
نرم‌افزار
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای
قراردادی که
=== پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه ===
توانایی پاسخ به تغییرات اغلب
مسیر یک پروژه نرم‌افزاری
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.<ref name="abmmw">Ambler, S.W. [http://www.ambysoft.com/essays/agileManifesto.html "Examining the Agile Manifesto"]. Retrieved 6 April 2011.</ref>
خط ۸۵:
* همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
* مکالمهٔ رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
* پروژه‌ها در اطراف افراد باانگیزه، که باید به
* توجه مستمر به برتری فنی و طراحی خوب؛
* سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
* تیم‌های خودسازمان‌دهی؛
* انطباق با تغییرات محدودیت‌ها
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول [[مدیریت پروژه]] نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد.<ref>{{cite web
خط ۱۰۰:
[[پرونده:Pair programming 1.jpg|200px|بندانگشتی|چپ|برنامه‌نویسی دو جزئی، یکی از تکنیک‌های توسعهٔ چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.]]
متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می‌دهند.
متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که
last=Beck|first=Kent|
year=1999|title=Embracing Change with Extreme Programming|
خط ۱۰۶:
pages=70–77|
doi=10.1109/2.796139}}</ref>
ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان‌دهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم
متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل میکند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار میکند، افراد ارتباط روزانه‌شان را از طریق [[ویدئو کنفرانس]]، صدا، ایمیل و... حفظ می‌کنند.
مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد میکند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد.<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) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند.
این
توسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب میکند.<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 متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز میکند و برای تحویل
در توسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم‌افزار» در سال ۲۰۰۲ توصیف شد.<ref name="Cockburn, Information radiator">{{Cite web
خط ۱۳۷:
در سال ۲۰۰۸ مؤسسهٔ [[مهندسی نرم‌افزار]] (SEI) [[گزارش فنی]] «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و 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،
== متدهای چابک ==
خط ۱۵۹:
<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>
پیاده‌سازی کاربردی این است که متدهای چابک به تیم‌های پروژه اجازهٔ تطبیق روش‌های کاری را با نیازهای پروژه‌های منحصربه‌فرد بدهند. روش‌ها فعالیت‌ها و محصولات به هم پیوسته‌ای هستند که بخشی از یک چارچوب متد را تشکیل می‌دهند. در یک سطح خیلی بالاتر، فلسفهٔ پشت متد، شامل تعدادی اصول است که می‌توانند منطبق باشند (Aydin، 2004).<ref name="Aydin2004"/>
برنامه‌نویسی Extreme (XP) نیاز به انطباق متد را شفاف میکند. یکی از ایده‌های بنیادین XP این است که هیچ فرایندی برای تمام پروژه‌ها مناسب نیست، اما ترجیحاً روش‌ها باید برای هر پروژهٔ منحصربه‌فرد سازمان‌دهی [مناسب‌سازی] شوند. انطباق جزئی روش‌های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش
یک روش سازمان‌دهی پیشنهاد میکند که یک نقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روش‌ها ارائه می‌دهد. روش RDP برای سفارشی‌سازی XP طراحی
در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می‌رسد، اما آزمایش‌ها با روش RDP می‌گوید این روش می‌تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینهٔ پروژه در ابتدای یک پروژه داده می‌شود و در طول اجرای پروژه نیز ثابت می‌ماند. نتیجه یک تعریف استاتیک از زمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه‌ها می‌توان تعیین کرد کدام قسمت متد ساخت‌یافته، بر اساس مجموعه‌ای از معیارهای از پیش‌تعیین‌شده، باید برای آن پروژهٔ خاص به کار رود.
در مقابل، متد دینامیک انطباق، فرض میکند پروژه در یک زمینهٔ نوظهور واقع
مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغلب ناچارند در طول اجرای یک پروژه، قسمت‌های ساخت‌یافته را تغییر دهند یا حتی قسمت‌های جدیدی ابداع کنند (Aydin و همکاران، 2005).<ref name="Aydin2005"/>
=== چرخهٔ عمر توسعهٔ نرم‌افزار ===
[[پرونده:SoftwareDevelopmentLifeCycle.jpg|بندانگشتی|چپ|چرخهٔ عمر پشتیبانی از توسعهٔ نرم‌افزار<ref name="Abrahamsson2002"/>]]
متدهای چابک بر جنبه‌های متفاوتی از چرخهٔ عمر توسعهٔ نرم‌افزار تمرکز دارند. بعضی از
== اندازه‌گیری میزان چابکی ==
خط ۱۹۳:
=== سازگاری ===
بخش وسیعی از توسعهٔ چابک نرم‌افزار به صورت یک زمینهٔ تحقیقاتی پرکار
بعضی مواردی که ممکن است بر موفقیت یک پروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از:
* تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده است؛
* تلاش‌های توسعهٔ توزیع‌شده (تیم‌های غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعهٔ دور [دورکاری]» توضیح داده شده است؛
* تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند.
در شرایط برون‌سپاری توسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.».
متدهای چابک
همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:
| |||