Fadak.IR راهکارهای فدک
English Русский العربية فارسی
مقالات مدیریت مطالعات زبان


/ مدیریت

مدیریت پروژه چابک


      مدیریت چابک
      مدیریت پروژه
      مدیران چابکی
      اجزای مدیریت چابک
      مزایای مدیریت پروژه چابک
      معایب مدیریت پروژه چابکی
      همه چیز درباره مدیریت پروژه چابک
      مدیریت پروژه چابک (APM)
      توسعه نرم‌افزاری چابک
      بیانیه‌ی چابک
      اصول چابک
      مشخصات
      مقایسه با متدهای دیگر
      متدهای چابک
      چرخهٔ عمر توسعهٔ نرم‌افزار

مدیریت چابک

مدیریت پروژه چابک، یک رویکرد تکراری برای مدیریت پروژه است که روی تقسیم و تجزیه‌ پروژه‌های بزرگ به تسک‌های قابل‌کنترل و کوچک‌تر تمرکز دارد. مدیریت چابک به تیم‌ها این امکان را می‌دهد که برای تغییر سریع جهت و تمرکز پروژه، از تجهیزات بهتری برخوردار شوند.
با توجه به پیشرفت مداوم کسب‌وکارها، روش مدیریت چابک می‌تواند چشم‌انداز موفقیت پروژه شما را تا حد زیادی افزایش دهد. رویکرد چابک به عنوان راهی برای تکمیل کارها در دنیای پیچیده و همیشه در حال تغییر، به سرعت در حال کسب محبوبیت است. رویکرد چابک در فرهنگ‌های سازگاری رشد می‌کند که اعضای تیم با سرعت تغییر ایجاد می‌کنند. در این راهنما، درباره مدیریت پروژه چابک، مولفه‌ها و اصول کلیدی آن و نحوه اجرای رویکرد چابک، نکات مفیدی خواهید آموخت.

مدیریت پروژه

مدیریت پروژه چابک یا اجایل (Agile Project Management - APM)، یک رویکرد تکراری برای مدیریت پروژه است که روی تقسیم و تجزیه‌ پروژه‌های بزرگ به وظایف (Task) قابل کنترل و کوچک‌تر تمرکز دارد؛ پروژه‌هایی که با تکرارهای کوتاه در طول چرخه عمر پروژه تکمیل می‌شوند. Agile برای تمرکز بر بهبود مستمر در توسعه محصول یا خدمات، از چرخه‌های توسعه کوتاه به نام اسپرینت (Sprint) استفاده می‌کند.
تطبیق پذیری؛ یعنی توانایی تغییر دادن یا تغییر کردن، متناسب با شرایط جدید و توانایی انطباق سریع و کارآمد با تغییرات، یک مهارت حیاتی برای رهبران است. این موضوع برابر با هنر انعطاف‌پذیری تحت تأثیر تغییر سریع شرایط خارجی است. رهبر چابک بودن به معنای انعطاف‌پذیری، پاسخگویی در برابر تغییرات و تمایل به یادگیری و اتخاذ راه‌های جدید است که منجر به بقای موثر و موفقیت در فضای رقابتی تجارت مدرن می‌شود. افرادی که از نظر سازگاری و توانایی چابکی امتیاز بالایی کسب می‌کنند، می‌توانند با تغییر کردن مقابله مثبت‌تری داشته باشند و می‌توانند رویکرد خود را برای تغییر نیازها تطبیق داده و اولویت‌های خود را تغییر دهند.
مدیریت چابک همان‌طور که از نامش پیداست، به تیم‌ها این امکان را می‌دهد که برای تغییر سریع جهت و تمرکز پروژه، از تجهیزات بهتری برخوردار شوند. شرکت‌های نرم‌افزاری و آژانس‌های بازاریابی، بیش از هر کسب‌وکار دیگری از تمایل ذینفعان پروژه به تغییر پروژه، آگاه هستند. رویکرد چابک، تیم‌ها را قادر می‌سازد تا کارهایی که انجام می‌دهند را دوباره ارزیابی کرده و تنظیم کنند تا مطمئن شوند با تغییر کار و چشم‌انداز مشتری، تمرکز تیم نیز تغییر می‌کند.
اگر در مدیریت پروژه چابک تازه‌کار باشید، ممکن است این روش در ابتدا برایتان یک سیستم پیچیده و دشوار برای مدیریت به نظر برسد. اما، چه متوجه آن شوید چه نشوید، در حال حاضر هم بسیاری از کارهایی را که به رویکرد چابک نیاز دارد، انجام می‌دهید. به این صورت که با وقوع چند تغییر سریع، به دنبال چرخه‌های توسعه کوتاه‌تر و عرضه محصولات کوچک‌تر و مکرر هستید.

مدیران چابکی

رویکرد چابک در مدیریت پروژه که در ابتدا برای توسعه نرم‌افزار و تیم‌های کسب‌وکارهای IT ایجاد شده بود، اکنون توسط انواع دیگری از کسب‌وکارها نیز مورداستفاده قرار گرفته‌است. بازاریابان، دانشگاه‌ها، ارتش و حتی صنعت خودرو نیز به دنبال مدیریت پروژه با رویکرد چابک هستند تا بتوانند محصولاتی نوآورانه را در محیط‌های نامشخص ارائه دهند.
در دنیای نرم‌افزار، وقتی تصمیم به ساخت یا توسعه بیشتر یک فناوری موجود گرفته می‌شود، تعریف محصول نهایی دشوار است. Agile این ابهام را به دلیل انعطاف‌پذیری در تغییر جهت پروژه، هم‌زمان با حرکت روند کار به سمت آینده، امکان‌پذیر می‌سازد.
هر تیمِ Agile منحصر‌به‌فرد است و درک اصول آن می‌تواند به شما کمک کند یک روش Agile که برای شما و تیمتان مناسب است را تنظیم کنید.

اجزای مدیریت چابک

هر پروژه‌ای که به روش چابک مدیریت می‌شود دارای پنج جزء کلیدی است. این اجزاء در قسمت‌های مختلف پروژه بررسی و به‌کار گرفته می‌شوند که در ادامه با آنها آشنا می‌شوید:
۱- داستان‌های کاربر (User stories): به زبان ساده، داستان کاربر تعریف سطح بالایی از درخواست کار است که شامل اطلاعات کافی برای این است که تیم بتواند برآورد معقولی از تلاش مورد نیاز برای انجام درخواست، ارائه دهد. این توضیح کوتاه و ساده از دیدگاه کاربر نوشته شده است و بر تشریح خواسته‌های مشتری شما (اهدافشان) و دلیل آن متمرکز است.
۲- اسپرینت (Sprints): Sprint در لغت به معنی «دوی سرعت» است؛ اما در مدیریت چابک، اسپرینت یک تکرار کوتاه از کار است که معمولاً بین یک تا سه هفته، در زمانی که تیم‌ها روی وظایف تعیین شده در جلسه برنامه‌ریزی اسپرینت کار می‌کنند، تکمیل می‌شود. ایده این است که هم‌زمان با پیش‌روی پروژه، این اسپرینت‌ها را به طور مداوم تکرار کنید تا محصول شما آماده شود. پس از اتمام هر اسپرینت، شما محصول را مرور می‌کنید تا ببینید چه چیزهایی کار می‌کنند و چه چیزهایی کار نمی‌کنند، تنظیمات مورد نیاز را انجام می‌دهید و دوباره یک اسپرینت دیگر را برای بهبود محصول یا خدمات خود شروع می‌کنید.
۳- جلسات استندآپ (Stand-up meetings): جلسات استندآپ روزانه که مدت آن معمولا زیر 10 دقیقه است و به آن «جلسات روزانه اسکرام» نیز می‌گویند، یک روش عالی برای اطمینان از این است که همه از تمام موضوعات مربوط به پروژه آگاه و در مسیر درستی هستند. این تعاملات روزمره به این دلیل با عنوان «استندآپ» شناخته می‌شوند که شرکت‌کنندگان باید در آن بایستند و کمک کنند که جلسات بصورت کوتاه و با پرداختن به موضوع هدف اصلی، برگزار شوند.
۴- تخته چابک (Agile board): استفاده از یک تخته چابک به تیم شما کمک می‌کند که پیشرفت پروژه را دنبال کنند. این تخته می‌تواند یک تخته سفید ساده با یادداشت‌های روی آن باشد و یا عملکردی در نرم‌افزار مدیریت پروژه شما.
۵- بک‌ لاگ (Backlog): همانطور که درخواست‌های پروژه از طریق سیستم ورودی شما دریافت می‌شوند، در موارد عقب مانده به داستان‌های برجسته تبدیل می‌شوند. در طول جلسات برنامه‌ریزی چابک، تیم شما امتیازات داستانی مربوط به هر کار را تخمین می‌زند. در طول برنامه‌ریزی اسپرینت‌ها، داستان‌های موجود در بک لاگ به درون اسپرینت منتقل می‌شوند تا در طول تکرار چرخه‌ اسپرینت تکمیل شوند. مدیریت بک لاگ‌ها برای مدیران پروژه در یک محیط چابک نقش حیاتی دارد.

مزایای مدیریت پروژه چابک

مدیریت پروژه چابک مزایای بی‌شماری را برای سازمان‌ها، تیم‌های پروژه و محصولات فراهم می‌کند. مزایای اصلی و چگونگی به حداکثر رساندن آنها به شرح زیر است:
۱- کیفیت بهتر محصول: متد‌های چابک دارای تضمینی برای اطمینان از بالاترین حد کیفیت محصولات را دارند که توسط عومل زیر ایجاد می‌شود:
-  اتخاذ رویکردی پیشگیرانه نسبت به کیفیت، برای جلوگیری از مشکلات محصول
- استفاده از مزیت‌های تکنولوژی، طراحی خوب و توسعه پایدار در پروژه‌ها
- تعیین و شرح دقیق به موقع الزامات و نیازمندی‌های پروژه، به طوری که اطلاعات موجود درباره‌ ویژگی‌های محصول، تا حد ممکن مرتبط باشد.
- آزمایش روزانه در فرآیند توسعه که به تیم توسعه، امکان حل مسائل تازه را می‌دهد.
- استفاده از ابزارهای تست اتوماتیک به منظور توسعه در طول روز
- بازنگری اسپرینت‌ها که به تیم اسکرام امکان بهبود مداوم فرآیندها و کار را می‌دهد.
۲- رضایت بیشتر مشتری: تیم‌های پروژه چابک مشتریان را از طریق روش‌های زیر، راضی نگه می‌دارند:
- در جریان نگه داشتن مشتریان در طول پروژه‌ها
- داشتن یک مالک محصول که در زمینه نیازهای محصول و نیازهای مشتری خبره باشد.
- به روزرسانی و اولویت‌بندی بک لاگ محصولات، به منظور پاسخ سریع به تغییرات
- نشان دادن عملکرد کار به مشتریان در هر اسپرینت
- عرضه سریع‌تر و بیشتر هر نسخه از محصولات به بازار
۳- روحیه‌ی تیمی بالاتر: عضویت در یک تیم خودگردان به اعضای آن اجازه می‌دهد که خلاق، نوآور و متخصص شناخته شوند. داشتن اسکرام مستر موانع را برطرف می‌کند و تیم توسعه را از تداخل خارجی محافظت می‌کند. کارکرد متقابل عملکردی به اعضای تیم توسعه این امکان را می‌دهد تا مهارت‌های جدید را بیاموزند و با آموزش به دیگران، رشد کنند.
۴- افزایش همکاری و مالکیت: تیم توسعه‌دهنده، مدیرمحصول و اسکرام مستر به طور روزانه با هم همکاری نزدیک دارند. جلسات اسکرام روزانه به تیم توسعه اجازه می‌دهد تا در مورد کارهای انجام شده، کارهای آینده و موانع بر سر راه، با یکدیگر مشورت و آنها را سازماندهی کنند. در طی بررسی‌های اسپرینت‌ها، تیم توسعه می‌تواند محصول را مستقیماً برای ذینفعان به نمایش بگذارد و در مورد آنها بحث کند.
۵- ساختارهای تیمی سفارشی: به دلیل اندازه محدود تیم‌های توسعه (پنج تا نه نفر)، پروژه‌های چابک می‌توانند چندین تیم اسکرام را درون یک پروژه داشته باشند. خودمدیریتی و محدودیت اندازه به این معنی است که پروژه‌های چابک می‌توانند فرصت‌های منحصر به فردی برای سفارشی‌سازی ساختارهای تیمی و محیط کار فراهم کنند.
۶- قابلیت بهتر مشاهده عملکرد پروژه: در پروژه‌های چابک، هر یک از اعضای تیم پروژه این فرصت را دارند که بدانند پروژه در هر زمان مشخص چگونه پیش می‌رود. جلسات روزانه‌ اسکرام، مرور روزانه اسپرینت و نمودارهای پیشرفت پروژه، روش‌های مشخصی را برای دیدن میزان پیشرفت پروژه ارائه می‌دهند.
۷- افزایش کنترل پروژه: فرصت‌های فراوانی که برای بازرسی و سازگاری در طول پروژه‌های چابک وجود دارد، به همه‌ اعضای تیم پروژه یعنی تیم توسعه‌دهنده، مدیر محصول، اسکرام مستر و ذینفعان، امکان کنترل و تولید محصولات بهتر را می‌دهد.
جمع‌بندی
موارد ذکر شده اساسی‌ترین قسمت‌های مدیریت پروژه جابک هستند. وقتی که شما روش مدیریت تیم خود را به متد چابک منتقل می‌کنید، این فرایندها، نرم‌افزار و ابزارها، نقش‌ها و اصول رویکرد چابک، به شما کمک می‌کنند که طرز تفکر خود را تغییر داده و کاری مشترک را شروع کنید تا انعطاف پذیرتر باشد و با تغییراتی که ایجاد می‌شود، سازگار شوید. مدیریت چابک برای همه مناسب نیست، اما تیم‌هایی که به درستی از آن استفاده می‌کنند، مزایای زیادی از جمله روند کار ساده و نوآوری سریع را تجربه می‌کنند.

به طور خلاصه مزایای این مدیریت شامل ایجاد سریع راه حل‌ها، استفاده موثر از منابع، انعطاف پذیری بیشتر و سازگاری با نیازهای متغیر، تشخیص سریع‌تر مشکلات و از این رو رفع سریع‌تر مشکلات است. همچنین از دیگر مزایای آن همکاری و تعامل با کاربران است که باعث می‌شود محصولاتی که به نیازهای کاربران بیشتر و بهتر پاسخ می‌دهد افزایش یابد.

معایب مدیریت پروژه چابکی

پروژه‌ها برای طی مسیر، اسناد کمتری دارند که در نتیجه کمتر قابل پیش بینی هستند.
ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند.
متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی مناسب است.
بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.

همه چیز درباره مدیریت پروژه چابک

مدیریت پروژه چابک یا همان Agile Project Management که آن را با نام اختصاری (APM) نیز می‌شناسند یک رویکرد با استفاده از تکرار برای پروسه برنامه ریزی و مدیریت پروژه است.
یک پروژه چابک درواقع درست مانند توسعه نرم افزار چابک، با بخش‌های کوچک تکمیل می‌شود که این بخش‌های کوچک تکرار شونده‌ها نامیده می‌شوند. هر بخش یا همان تکرار شونده توسط تیم پروژه بررسی و نقد می‌شود. اعضای این تیم باید متشکل از نمایندگان ذینفغان مختلف پروژه باشند. در نهایت بینش‌هایی که از نقد یک تکرار حاصل شده است، به منظور تعیین قدم بعدی هرچه بهتر در پروژه استفاده می‌شوند.
مزیت اصلی مدیریت پروژه چابک توانایی آن برای بررسی و حل مسائلی است که در طول دوره پروژه به وجود می‌آیند. ایجاد تغییرات لازم در پروژه در زمان مناسب باعث ذخیره منابع و در نهایت منجر به ارائه یک پروژه موفق در زمان درست و با بودجه کم می‌شود.

مدیریت پروژه چابک (APM)

درواقع روش مدیریت پروژه چابک، پروژه را به بخش‌های کوچک تقسیم می‌کند که این بخش‌ها در جلسات کاری، از مرحله طراحی تا تست و تضمین کیفیت اجرا و تکمیل می‌شوند. این بخش‌های کوچک یا همان تکرار‌ها «اسپرینت» نامیده می‌شوند و در یک تکنیک خاص و ویژه مدیریت پروژه چابک به نام « اسکرام» به کار برده می‌شود.
اسپرینت‌ها به طور کلی کوتاه هستند و بیش از چند روز یا چند هفته اجرا می‌شوند و معمولا ۲ تا ۴ هفته به طول می‌انجامند.
متد چابک تیم‌ها را قادر می‌سازد تا در طول تکمیل پروژه بخش‌های مختلف را رصد کنند که این برنامه کنترل مداوم بخش‌ها باعث می‌شود تا تشخیص دهند که آیا این بخش‌ها موفق عمل کرده‌اند یا خیر و در غیر اینصورت بلافاصله و به سرعت نقص‌ها را برطرف کنند. اعتقاد بر این است که این روش کمک می‌کند تا احتمال شکست در بخش‌های بزرگ و کلی تا حد زیادی کاهش یابد، زیرا بخش‌های کوچک در طول چرخه عمر پروژه به طور مداوم در حال بررسی و بهبود یافتن هستند.
تیم‌های مدیریت چابک، بازخوردهای خیلی سریع، سازگاری مداوم و بهترین شیوه‌ها در تکرار آن‌ها را می‌سازند.
آن‌ها شیوه‌هایی مانند استقرار مداوم و پیوستگی مداوم را با استفاده از تکنولوژی‌های خودکار برای سرعت بخشیدن به انتشار و استفاده از محصولات اتخاذ می‌کنند.
به علاوه، مدیریت پروژه چابک از تیم‌ها می‌خواهد که همزمان با انجام کار، به طور مداوم زمان و هزینه را برآورد و ارزیابی کنند. آن‌‌ها به جای نمودار گانت (Gantt Chart)، برای ارزیابی و اندازه‌گیری پیشرفت کار از نمودارهای burndown و burnup استفاده می‌کنند.
مدیریت پروژه چابک نیاز به حضور یا مشارکت یک مدیر پروژه ندارد. اگرچه در روش‌های سنتی مانند روش مدیریت پروژه آبشاری Waterfall (برای مدیریت بودجه، مدیریت پرسنل، دامنه پروژه، کیفیت، الزامات و سایر عناصر کلیدی) به منظور دستیابی به موفقیت حضور یک مدیر پروژه ضروری است، اما در روش مدیریت پروژه چابک، نقش مدیر پروژه در بین اعضای تیم تقسیم می‌شود.
به عنوان مثال، اهداف پروژه توسط صاحب محصول یا صاحب پروژه تعیین می‌شود و اعضای تیم برنامه ریزی، گزارش پیشرفت و سایر کارها را تقسیم می‌کنند. برخی از روش‌های مدیریت چابک پروژه لایه‌های دیگری از مدیریت را نیز اضافه می‌کنند مانند: استفاده از رویکرد اسکروم که به تعیین اولویت‌ها کمک می‌کند و می‌تواند پروسه تکمیل پروژه را بهبود بخشد.
با این حال در روش مدیریت پروژه چابک، مدیران پروژه هنوز منسوخ نشده‌اند و از آن‌ها استفاده می‌شود. بسیاری از سازمان‌ها به خصوص در پروژه‌های بزرگ‌تر و پیچیده‌ترهنوز برای این روش از مدیران پروژه استفاده می‌کنند. البته سازمان‌ها بیشتر این مدیران پروژه را در نقش هماهنگ کننده با مسئول پروژه به کار می‌گیرند.
حتما بخوانید: تفاوت بیزینس پلن (Business Plan) با پروپوزال (Business Proposal) چیست؟
با توجه به تغییر کار از مدیران پروژه به تیم‌های چابک، متد مدیریت پروژه چابک از اعضای تیم می‌خواهد که چگونگی کار در این متد جدید را بیاموزند. آن‌ها باید قادر باشند که با همان کیفیت که با کاربران در تعامل هستند با دیگر اعضای تیم نیز در تعامل باشند. علاوه بر این باید بتوانند با یکدیگر به طور صحیح ارتباط برقرار کنند تا پروژه‌ها در مسیر درست خود و با موفقیت پیش روند. همچنین باید توانایی انجام اقدامات مناسب در زمان مناسب را داشته باشند تا بتوانند با تحولات مداوم پروژه هماهنگ باشند.
روش مدیریت پروژه چابک در مقابل روش مدیریت آبشاری
روش مدیریت پروژه چابک با روش مدیریت آبشاری متناسب بوده و متناسب نیز خواهد ماند. درواقع روش مدیریت آبشاری یک رویکرد دقیق تدریجی به پروژه‌ها دارد. به طوریکه با جمع آوری تمام الزامات قبل از شروع کار آغاز می‌شود، منابع مورد نیاز محاسبه می‌گردد، جدول زمانی و بودجه برآورد می‌شود، کار واقعی انجام می‌شود، تست می‌شود و سپس پروژه به عنوان یک کار تکمیل شده ارائه می‌گردد.

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

توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت می‌کند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. بیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.[۱]
تاریخچه
سوابق
مارتین فولر، به عنوان یکی از بنیان‌گذاران کلیدی متدهای چابک شناخته می‌شود.
متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند.[۲] در سال ۱۹۷۴، E.A. Edmonds در مقاله‌ای فرایند توسعهٔ تطبیقی نرم‌افزار را معرفی کرد.[۳] هم‌زمان و به‌طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم‌های شرکت تلفن نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ ۱۹۷۰، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت.[۴] در طول نیمه تا انتهای دههٔ 1970 Gielan به‌طور گسترده در ایالات متحده در مورد این متدولوژی، تجارب و فواید آن سخنرانی‌هایی ارائه داد.[۲]
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده‌است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند. پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum
(1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، ۱۹۹۵) می‌شود. بعد از انتشار بیانیهٔ چابک در سال ۲۰۰۱، اکنون این‌ها به‌طور معمول به متدولوژی‌های چابک برمی‌گردند.[۵]

بیانیه‌ی چابک

در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهندهٔ نرم‌افزار،[۶] در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعهٔ چالاک گفتگو کنند.
آن‌ها برای توصیف رویکردی که اکنون به عنوان «توسعهٔ چابک نرم‌افزار» شناخته می‌شود، بیانیه‌ای برای توسعهٔ چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این بیانیه، اتحاد Agile را ایجاد کردند؛[۱] یک سازمان غیرانتفاعی که توسعهٔ نرم‌افزار را بر اساس اصول این بیانیه ترویج می‌دهد.
بیانیهٔ چابک به شرح زیر است:
ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعهٔ نرم‌افزار هستیم. از این کار به ارزش‌های زیر می‌رسیم:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار کارکننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.[۱]
معنی موارد سمت راست این بیانیه در مفهوم توسعهٔ چابک نرم‌افزار در زیر توضیح داده شده است:
افراد و تعاملات بالاتر از فرایندها و ابزارها
افراد مهم‌ترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می‌گردد و بر عکس افراد قوی تحت فرایند وضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران و تعامل درست و سازنده با سایر اعضای تیم خیلی مهم‌تر از این است که یک برنامه‌نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق‌تر هستند از تعدادی برنامه‌نویس عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می‌توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گران‌قیمت از برنامه رایگان کدباز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آن‌ها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.
نرم‌افزار کارکننده بالاتر از مستندات جامع
نرم‌افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آن‌ها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نمایید. البته آن‌ها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آن‌ها است. ما دانش خود را با نشستن در کنار آن‌ها و کمک کردن به آن‌ها انتقال می‌دهیم. ما آن‌ها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آن‌ها آموزش می‌دهیم.
مشارکت مشتری بالاتر از قرارداد کاری
نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آن‌ها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آن‌ها را برآورده می‌کند بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به‌طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می‌کند.
قراردادی که مشخص‌کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به‌طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
توانایی پاسخ به تغییرات اغلب تعیین‌کنندهٔ موفقیت یا شکست یک پروژهٔ نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازهٔ کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد.
مسیر یک پروژهٔ نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندی‌ها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفتهٔ بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.[۷]

اصول چابک

بر اساس نظرات Kent Beck[۸]، بیانیهٔ چابک، بر ۱۲ اصل استوار است:
رضایت مشتری از طریق تحویل زود و مداومِ نرم‌افزار مفید؛
استقبال از تغییر نیازمندی‌ها، حتی در اواخر توسعه؛
تحویل زود به زود نرم‌افزار قابل استفاده (هفتگی به جای ماهانه)؛
نرم‌افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است ؛
توسعهٔ پایدار که قادر به حفظ سرعت ثابت است؛
همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
گفتگوی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
پروژه‌ها در اطراف افراد باانگیزه، که باید به آن‌ها اعتماد کرد، شکل می‌گیرند؛
توجه مستمر به برتری فنی و طراحی خوب؛
سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
بهترین معماری‌ها، نیازمندی‌ها و طراحی‌ها از تیم‌های خودسازمانده پدیدار می‌شوند ؛
در فواصل منظم تیم بر چگونگی مؤثرتر شدن تامل وتفکر می‌نماید و سپس رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می‌کند.
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد.[۹].

مشخصات

برنامه‌نویسی دونفره، یکی از تکنیک‌های توسعهٔ چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.
متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می‌دهند. متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که به‌طور مستقیم با برنامه‌ریزی‌های طولانی‌مدت درگیر نیستند. تکرارها فریم‌های (بسته‌های زمانی) کوتاه‌مدتی هستند که معمولاً بین یک تا چهار هفته طول می‌کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: تحلیل نیازمندی‌ها، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذی‌نفعان نشان داده می‌شود. این، ریسک کلی را به حداقل رسانده و اجازه می‌دهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند.[۱۰] ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان‌دهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به‌طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می‌دهد، بر عهده می‌گیرند. آن‌ها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.
متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌کند، افراد ارتباط روزانه‌شان را از طریق ویدئو کنفرانس، صدا، ایمیل و... حفظ می‌کنند.
مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد.[۱۱] در انتهای هر تکرار، ذی‌نفعان و نمایندهٔ مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به‌طور خاص شامل نمایندهٔ مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسهٔ مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»[۱۲]
توسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.[۱۳]
ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعهٔ آزمون‌محور، الگوهای طراحی، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.
توسعهٔ کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آن‌ها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.
در توسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم‌افزار» در سال ۲۰۰۲ توصیف شد.[۱۴][۱۵] ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.

مقایسه با متدهای دیگر

متدهایی در زنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند.[۱۶] متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر می‌کند، یک تیم انطباقی نیز تغییر می‌کند. یک تیم انطباقی به سختی توضیح می‌دهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفتهٔ آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیهٔ مأموریت (برای آن انتشار) یا بیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد.
در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیم‌های پیشگویانه اغلب یک هیئت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود.
متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیم‌های چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.[۱۷]
متدهای چابک که از دههٔ ۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعهٔ سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند نمونه‌سازی سریع تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعهٔ چابک نرم‌افزار تشویق می‌کنند.
در سال ۲۰۰۸ مؤسسهٔ مهندسی نرم‌افزار (SEI) گزارش فنی «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.[۱۸][۱۹]
یکی از تفاوت‌های بین چابک و آبشاری، این است که تست نرم‌افزار در نقاط مختلفی در چرخهٔ عمر توسعهٔ نرم‌افزار انجام می‌شود. در مدل آبشاری، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به‌طور هم‌زمان با پیاده‌سازی انجام می‌شود. به‌طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازهٔ بلوغ تدریجی و پیاده‌سازی را می‌دهد.

متدهای چابک

متدهای معروف توسعهٔ چابک نرم‌افزار عبارتند از:
مدل‌سازی چابک
فرایند یکپارچهٔ چابک (AUP)
Crystal Clear
متدهای Crystal
متدهای توسعهٔ سیستم‌های دینامیک (Dynamic Systems Development Method)
برنامه‌نویسی اکستریم (Extreme Programming)
توسعهٔ ویژگی‌محور (Feature-driven Development)
طراحی گرافیکی سیستم (Graphical System Design)
توسعه Kanban
توسعه Lean
Scrum
ردیابی سرعت
سازمان‌دهی متد
در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی‌گردد، شامل «سازمان‌دهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب‌سازی متد به صورت زیر تعریف می‌شود:
فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعهٔ سیستم را برای موقعیت پروژه‌ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه‌ها، مفاهیم و قطعات متد تعریف می‌کنند.[۲۰]
به‌طور بالقوه، تقریباً تمام متدهای چابک برای سازمان‌دهی متد مناسب هستند. حتی متد DSDM نیز با این هدف به کار گرفته شده و با موفقیت در یک زمینهٔ CMM سازمان‌دهی می‌شود.[۲۱] اقتضای وضعیت، به عنوان یک مشخصهٔ متمایز بین متدهای چابک و متدهای توسعهٔ سنتی نرم‌افزار مطرح است، دومی نسبتاً جدی‌تر و تجویزی است.
پیاده‌سازی کاربردی این است که متدهای چابک به تیم‌های پروژه اجازهٔ تطبیق روش‌های کاری را با نیازهای پروژه‌های منحصربه‌فرد بدهند. روش‌ها فعالیت‌ها و محصولات به هم پیوسته‌ای هستند که بخشی از یک چارچوب متد را تشکیل می‌دهند. در یک سطح خیلی بالاتر، فلسفهٔ پشت متد، شامل تعدادی اصول است که می‌توانند منطبق باشند (Aydin، 2004).[۲۰]
برنامه‌نویسی Extreme (XP) نیاز به انطباق متد را شفاف می‌کند. یکی از ایده‌های بنیادین XP این است که هیچ فرایندی برای تمام پروژه‌ها مناسب نیست، اما ترجیحاً روش‌ها باید برای هر پروژهٔ منحصربه‌فرد سازمان‌دهی [مناسب‌سازی] شوند. انطباق جزئی روش‌های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش شده‌است.[۲۲]
یک روش سازمان‌دهی پیشنهاد می‌کند که یک نقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روش‌ها ارائه می‌دهد. روش RDP برای سفارشی‌سازی XP طراحی شده‌است. این روش، برای اولین بار در کارگاه APSO در کنفرانس ICSE 2008، به عنوان یک مقالهٔ تحقیقاتی طولانی طرح شد، و اکنون نیز تنها متد طراحی‌شده و قابل‌اجرا برای سفارشی‌سازی XP است. اگرچه این روش به‌طور خاص راه‌حلی برای XP است، اما قابلیت توسعه برای سایر متدولوژی‌ها را دارد.[۲۳]
در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می‌رسد، اما آزمایش‌ها با روش RDP می‌گوید این روش می‌تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینهٔ پروژه در ابتدای یک پروژه داده می‌شود و در طول اجرای پروژه نیز ثابت می‌ماند. نتیجه یک تعریف استاتیک از زمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه‌ها می‌توان تعیین کرد کدام قسمت متد ساخت‌یافته، بر اساس مجموعه‌ای از معیارهای از پیش‌تعیین‌شده، باید برای آن پروژهٔ خاص به کار رود. در مقابل، متد دینامیک انطباق، فرض می‌کند پروژه در یک زمینهٔ نوظهور واقع شده‌است. یک زمینهٔ نوظهور به این موضوع اشاره می‌کند که یک پروژه با فاکتورهای نوظهوری سر و کار خواهد داشت که بر شرایط مربوطه اثر می‌گذارند، اما قابل‌پیش‌بینی نیستند. همچنین به این معناست که زمینهٔ پروژه ثابت نیست و در طول اجرا تغییر می‌کند. در چنین موردی نقشه‌های مسیر تجویزی مناسب نیستند. مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغلب ناچارند در طول اجرای یک پروژه، قسمت‌های ساخت‌یافته را تغییر دهند یا حتی قسمت‌های جدیدی ابداع کنند (Aydin و همکاران، 2005).[۲۳]

چرخهٔ عمر توسعهٔ نرم‌افزار

چرخهٔ عمر پشتیبانی از توسعهٔ نرم‌افزار[۲۲]
متدهای چابک بر جنبه‌های متفاوتی از چرخهٔ عمر توسعهٔ نرم‌افزار تمرکز دارند. بعضی از آن‌ها بر روش‌ها (برنامه‌نویسی extreme، برنامه‌نویسی فعال مدل‌سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه‌های نرم‌افزاری تأکید دارند (مانند رویکرد Scrum ). هنوز، رویکردهایی وجود دارند که تمام چرخهٔ عمر توسعه را پوشش می‌دهند (متدهای توسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آن‌ها از فاز تعیین نیازمندی‌ها مناسب هستند (مثلاً ویژگی‌محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعهٔ چابک نرم‌افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعهٔ نرم‌افزار ندارند، بقیهٔ آن‌ها با درجات متفاوت این نیاز را دارند. DSDM می‌تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می‌توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo، Rankainen & Warsta، 2002).[۲۲]
اندازه‌گیری میزان چابکی
اگرچه چابکی به عنوان ابزاری برای پایان دیده می‌شود، تعدادی رویکرد پیشنهاد شده‌اند که کیفیت چابکی را تعیین می‌کنند. اندازه‌گیری شاخص‌های چابکی (AIM) پروژه‌ها را برای کسب یک امتیاز کل، در مقابل تعدادی از فاکتورهای چابکی امتیازدهی می‌کنند. نام مشابه «شاخص اندازه‌گیری چابکی»، توسعه‌ها را در برابر ۵ بعد یک پروژهٔ نرم‌افزاری (مدت‌زمان، ریسک، تازگی، تلاش و تعامل) امتیازدهی می‌کند. تکنیک‌های دیگر مبتنی بر اهداف قابل‌اندازه‌گیری هستند.
مطالعهٔ دیگری با استفاده از ریاضیات فازی (fuzzy)، می‌گوید سرعت پروژه می‌تواند یکی از استانداردهای چابکی باشد. خودارزیابی‌هایی در چابکی وجود دارد که تعیین می‌کند آیا یک تیم از روش‌های چابک استفاده می‌کند یا خیر (آزمون Nokia، آزمون Karlskrona، ۴۲ آزمون نکته‌ای).[۲۴][۲۵]
اگرچه چنین رویکردهایی برای اندازه‌گیری چابکی پیشنهاد شده‌اند، کاربرد عملی چنین معیارهایی هنوز دیده می‌شود. از لحاظ تاریخی، در پروژه‌های چابکی که نتوانسته‌اند نتایج مطلوبی تولید کنند، کمبود داده وجود دارد. می‌توان مطالعاتی را یافت که پروژه‌ها را با پیاده‌سازی ناکارآمد یک (یا چند) متد چابک، ضعیف گزارش کرده‌اند، اما هیچ‌جا احساس نشد که به درستی اجرا شده‌اند و در تحویل تعهدات خود شکست خورده‌اند.[۲۶][۲۷][۲۸]
«این ممکن است یک دلیل بی‌میلی برای انتشار مقالات در مورد پروژه‌های ناموفق باشد، یا ممکن است نشان‌دهندهٔ آن باشد که وقتی متدهای چابک کار می‌کنند که پیاده‌سازی درست انجام شود.». اگرچه، داده‌هایی از ROI توسعهٔ چابک نرم‌افزار از CSIAC ROI Dashboard در دسترس است.[۲۹][۳۰]).[۳۱]
آزمودگی و پذیرش
یکی از مطالعات اخیر که دستاوردهای کیفیت، بهره‌وری و رضایت کسب‌وکار با استفاده از متدهای چابک را گزارش می‌دهد، یک بررسی بود که توسط Shine Technologies از نوامبر ۲۰۰۲ تا ژانویهٔ ۲۰۰۳ انجام شد.[۳۲]
یک بررسی مشابه در سال ۲۰۰۶ توسط Scott Ambler (رهبر تمرین توسعهٔ چابک با گروه متدهای عقلانی IBM) انجام شد که همین فواید را بیان کرد. در بررسی انجام‌شده توسط VersionOne (یک تهیه‌کنندهٔ نرم‌افزار برای برنامه‌ریزی و پیگیری پروژه‌های توسعهٔ چابک نرم‌افزار) در سال ۲۰۰۸، ۵۵ درصد پاسخ‌دهندگان گفتند متدهای چابک در ۹۰ تا ۱۰۰ درصد موارد موفق بوده‌اند.[۳۳]
برخی دیگر ادعا می‌کنند متدهای توسعهٔ چابک بسیار جوان‌تر از آن هستند که نیاز به اثبات گسترده و علمی موفقیت‌شان داشته باشند.[۳۴][۳۵]
سازگاری
بخش وسیعی از توسعهٔ چابک نرم‌افزار به صورت یک زمینهٔ تحقیقاتی پرکار باقی مانده‌است. به‌طور گسترده توسعهٔ چابک برای انواع مشخصی از محیط‌ها، شامل تیم‌های کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنهٔ Embedded در اروپا مشاهده شده‌است. بعضی مواردی که ممکن است بر موفقیت یک پروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از:
تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده‌است؛
تلاش‌های توسعهٔ توزیع‌شده (تیم‌های غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعهٔ دور [دورکاری]» توضیح داده شده‌است؛
تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در آن‌ها شکست، به هر قیمتی یک گزینه نیست (مثل نرم‌افزار کنترل ترافیک هوایی).
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند. در شرایط برون‌سپاری توسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.». متدهای چابک به‌طور گسترده برای توسعهٔ محصولات نرم‌افزاری به کار رفته‌اند، بعضی از آن‌ها نیز از خصوصیات مشخصی از نرم‌افزار، مانند فناوری‌های موضوع استفاده می‌کنند. اگرچه این فناوری‌ها می‌توانند برای محصولات غیر نرم‌افزاری (مانند کامپیوترها، وسایل نقلیهٔ موتوری، وسایل پزشکی، خوراک و پوشاک) نیز به کار گرفته شوند. همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:

سازگاری متدهای متفاوت توسعه
پایهٔ اصلی چابک پایهٔ اصلی ارزش‌محور متدهای رسمی
حساسیت پایین حساسیت بالا حساسیت شدید
توسعه‌دهندگان ارشد توسعه‌دهندگان تازه‌کار توسعه‌دهندگان ارشد
نیازمندی‌ها اغلب تغییر می‌کنند. نیازمندی‌ها اغلب تغییر نمی‌کنند. نیازمندی‌های محدود، خصوصیات محدود
تعداد کمی از توسعه‌دهندگان تعداد زیادی از توسعه‌دهندگان نیازمندی‌ها می‌توانند مدل‌سازی شوند
فرهنگ پاسخ به تغییر فرهنگ نیاز به نظم کیفیت بسیار زیاد

مقالات
سیاست
رسانه‎های دیجیتال
علوم انسانی
مدیریت
روش تحقیق‌وتحلیل
متفرقه
درباره فدک
مدیریت
مجله مدیریت معاصر
آیات مدیریتی
عکس نوشته‌ها
عکس نوشته
بانک پژوهشگران مدیریتی
عناوین مقالات مدیریتی
منابع درسی (حوزه و دانشگاه)
مطالعات
رصدخانه - مردم و مراکز فرهنگی
رصدخانه شخصیت‌ها
رصدخانه - مؤسسات
رصدخانه- رویدادهای علمی
رصدخانه - کارها
رصدخانه - خبرگزاری
زبان‌ها
لغت نامه
تست زبان روسی
ضرب المثل روسی
ضرب المثل انگلیسی
جملات چهار زبانه
درباره ما | ارتباط با ما | سیاست حفظ حریم خصوصی | مقررات | خط مشی کوکی ها |
نسخه پیش آلفا 2000-2022 CMS Fadak. ||| Version : 5.1 ||| By:Fadak Solutions نسخه قدیم