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

محتوای حذف‌شده محتوای افزوده‌شده
خط ۴۱:
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.<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>
 
=== اصول چابک ===