پروژه هائی که با روش ها و رویکرد های سنتی (مانند رویکردهای آبشاری) مدیریت می شوند دارای ضعف هائی از قبیل اتلاف زمان زیاد جهت طراحی دقیق در فاز آغازین پروژه، بالا بودن هزینه تغییرات، ناکارآمد بودن محصول نهائی و … می‌باشند، وجود چنین ضعف هایی منجر به بروز مشکلاتی برای مدیریت پروژه های نرم افزاری که دارای تغییرات و اصلاح زیاد هستند، گردید.
رویکرد آبشاری در توسعه نرم افزار
این موضوع باعث شد در اواخر دهه ۱۹۹۰ روش های متعددی از ترکیب ایده های قدیمی و نوین به وجود آید که بیشتر آنها بر روش های هوشمندانه برای ساخت، تائید و ارائه محصول، تاکید داشتند.
در نهایت، اصطلاح و تفکر جدیدی به نام Agile در مدیریت پروژه های نرم افراری به وجود آمد، این تفکر در سال ۲۰۰۱ توسط تیمی متشکل از ۱۷ نفر از متخصصین نرم افزار، به عنوان Agile Manifesto (بیانه چابک) بطور رسمی معرفی گردید.
تفکر یا بیانه چابک (Agile Manifesto) دارای ۴ ارزش (Value) و ۱۲ اصل (Principle) می باشد که با استفاده از آنها می توان محصولات کارآمد، مشتری راضی و خوشحال و همچنین نیروی کار با انگیزه دست پیدا کرد.
ارزشهای متدهای چابک به شرح ذیل هستند:
Individuals and Interactions Over Process and Tools
- افراد و تعاملات آنها بالاتر (ارزشمند تر) از فرآبندها و ابزارها می باشند.
افراد مهم‌ترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می‌گردد و بر عکس افراد قوی تحت فرایند وضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران و تعامل درست و سازنده با سایر اعضای تیم خیلی مهم‌تر از این است که یک برنامه‌نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق‌تر هستند از تعدادی برنامه‌نویس عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می‌توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گران‌قیمت از برنامه رایگان کدباز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آنها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.
Working Software Over Comprehensive Documentation
- نرم افزار (محصول) کارا بالاتر (ارزشمند تر) از مستندات جامع است.
نرم‌افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را بر طبق کد برنامه به روز نمایید. اگر آنها متناسب با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آنها را به روز نمایید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می‌دهیم. ما آنها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می‌دهیم.
Customer Collaboration Over Contract Negotiation
- مشارکت مشتری بالاتر (ارزشمند تر) از مذاکرات قراردادی است.
نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می‌کند بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به‌طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند.
قراردادی که مشخص‌کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به‌طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
Responding To Change Over Following a Plan
- پاسخگوئی به تغییرات بالاتر (ارزشمند تر) از پیروی از یک برنامه است.
توانایی پاسخ به تغییرات اغلب تعیین‌کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازه کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد.
مسیر یک پروژه نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندیها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.
انتظار آن است که محصولی که با متد Agile تولید شده کیفیت بیشتری داشته باشد. رویکرد Agile در تولید نرم افزار را در شکل زیر ببینید.
در دوره آموزشی مدیریت چابک (Agile) شرکت کنید تا با این رویکرد فوق العاده آشنا شوید:
