ویکی‌پدیا

توسعه نرم‌افزاری چابک: تفاوت میان نسخه‌ها

نمایش تاریخچه به صورت تعاملی
→ تفاوت قدیمی‌ترتفاوت جدیدتر ←
محتوای حذف‌شده محتوای افزوده‌شده
دیداریویکی‌متن
FreshmanBot (بحث | مشارکت‌ها)
ربات‌ها
۱۳۳٬۲۴۲ ویرایش‌ها
جز اصلاح فاصله مجازی + اصلاح نویسه با ویرایشگر خودکار فارسی
خط ۱:
'''توسعه چابک نرم‌افزار''' یا '''توسعه نرم‌افزاری چابک''' گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت می‌کند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. بیانیه‌یبیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.<ref name="Agile Manifesto">{{cite web
|url=http://agilemanifesto.org/
|title=Manifesto for Agile Software Development |year=۲۰۰۱ |publisher=Agile Alliance
خط ۲۰:
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده‌است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند.
پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، [[اسکرام (توسعه نرم‌افزار)|Scrum]]
(1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، ۱۹۹۵) می‌شود. بعد از انتشار بیانیه‌یبیانیهٔ چابک در سال ۲۰۰۱، اکنون این‌ها به‌طور معمول به متدولوژی‌های چابک برمی‌گردند.<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 Cecil 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>
 
=== اصول چابک ===
خط ۷۸:
|title=Principles behind the Agile Manifesto|year=2001 |publisher=Agile Alliance
|author=Beck, Kent |author2=et al.
|accessdate=6 June 2010| archiveurl= http://web.archive.org/web/20100614043008/http://www.agilemanifesto.org/principles.html| archivedate= 14 June 2010 <!--DASHBot-->| deadurl= no}}</ref>، بیانیه‌یبیانیهٔ چابک، بر ۱۲ اصل استوار است:
* رضایت مشتری از طریق تحویل زود و مداومِ نرم‌افزار مفید؛
* استقبال از تغییر نیازمندی‌ها، حتی در اواخر توسعه؛
* تحویل زود به زود نرم‌افزار قابل استفاده (هفتگی به جای ماهانه)؛
* نرم افزار قابل استفاده اصلی تریناصلی‌ترین معیار سنجش پیشرفت است ؛
* توسعه‌یتوسعهٔ پایدار که قادر به حفظ سرعت ثابت است؛
* همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
* گفت‌و‌گویگفت‌وگوی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
* پروژه‌ها در اطراف افراد باانگیزه، که باید به آن‌ها اعتماد کرد، شکل می‌گیرند؛
* توجه مستمر به برتری فنی و طراحی خوب؛
* سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
* بهترین معماری‌ها، نیازمندی‌ها و طراحی‌ها از تیم‌های خود‌سازماندهخودسازمانده پدیدار می‌شوند ؛
* در فواصل منظم تیم بر چگونگی موثرترمؤثرتر شدن تامل وتفکر می نماید و سپس رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می‌کند.
 
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول [[مدیریت پروژه]] نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد.<ref>{{cite web
خط ۱۴۷:
* متدهای Crystal
* متدهای توسعهٔ سیستم‌های دینامیک (DSDM)
* [[برنامه‌سازی مفرط|برنامه‌نویسی اکستریم (XP)]]
* توسعهٔ ویژگی‌محور (FDD)
* طراحی گرافیکی سیستم (GSD)
برگرفته از «https://fa.wikipedia.org/wiki/توسعه_نرم‌افزاری_چابک»