برای بررسی مانیفست چابک باید سفری کوتاه به ایستگاه اسکی کوهستان واساچ در ایالت یوتا داشته باشیم. در روزهای 11 الی 13 فوریهی سال 2001 (23 الی 25 بهمن ماه 1379) گروهی از توسعهدهندگان نرمافزار که از رویکرد سنتی آبشاری توسعه نرمافزار ناراضی بودند، به ایستگاه اسکی کوهستان واساچ در ایالت یوتا رفتند و جلسهای مهم را تشکیل دادند. شاید کسی در آن روزهای سرد زمستان فکرش را هم نمیکرد که اوضاع برای همیشه پس از این جلسه تغییر خواهد کرد…
همانطور که میدانیم رویکرد آبشاری یک رویکرد خطی برای توسعه است، که در آن هر مرحله از پروژه باید قبل از شروع مرحله بعدی تکمیل شود. این رویکرد میتواند صلب و انعطافناپذیر باشد و به محضی که پروژه را شروع کردیم امکان ایجاد تغییرات در آن سختتر و سختتر میشود.
مانیفست چابک (Agile Manifesto) یا مانیفست اجایل مجموعهای از ارزشها و اصول بنیادین را ارائه میدهد که میتواند برای هدایت توسعه پروژههای نرمافزاری استفاده شود. این ارزشها و اصول بر اهمیت افراد، ارتباطات، همکاری و انعطافپذیری تأکید دارند. تیمهای چابک میتوانند به سرعت به تغییرات پاسخ دهند و تحویل نرم افزار به مشتری بسیار سریعتر و کارآ تر از رویکرد آبشاری اتفاق بیفتد.
هرآنچه درمورد مانیفست چابک میخوانید
ارزشهای بنیادین چابکی در مانیفست چابک
ارزشهای بنیادین ذکر شده در مانیفست Agile عبارتند از:
- افراد و تعاملات مهمتر از فرایندها و ابزارها
- نرمافزار کارآمد مهمتر از مستندات جامع پروژه
- همکاری با مشتری مهمتر از مذاکره برای قرارداد
- پاسخگویی به تغییر مهمتر از پیروی از یک برنامه
این ارزشها نشان میدهند که اصول بنیادین اجایل برخلاف رویکرد آبشاری، بر افراد، ارتباطات، همکاری و انعطافپذیری تأکید دارد. این ارزشها به تیمهای Agile کمک میکنند تا نرمافزار را سریعتر و با کیفیت بالاتر به مشتری تحویل دهند.
اصول بنیادین Agile در مانیفست چابکی نشان دهندهی یک ذهنیت پویا و انعطافپذیر برای توسعه نرمافزار است که به تیمها کمک میکند تا با تغییرات در نیازهای مشتری و فناوری به سرعت سازگار شوند. این امر باعث میشود که رویکرد چابک یک انتخاب عالی برای پروژههایی باشد که در آن نیازهای مشتری مدام در حال تغییر، یا فناوری هرروزه در حال پیشرفت است.
پیشنهاد مطالعه
مدیریت پروژه چابک چیست؟ – راهنمای کامل و کاربردی مدیریت چابک
برای به دست آوردن تصویر واضحتری از این ماجرا اجازه دهید به ماجرای شرکتی نرم افزاری نگاهی بیندازیم که در نظر نگرفتن چهار اصل بنیادین مانیفست چابک مشکلات زیادی را برای آنان به بار میآورد و کار پروژهشان را به تعطیلی میکشاند. با هم ببینیم که چرا این اتفاق میافتد؟
شرکت Harold & Hann یک شرکت کوچک توسعه نرمافزار است که حدود 10 سال سابقه کار دارد. آنها دارای شهرت خوبی در زمینه تحویل نرمافزار باکیفیت در زمان و بودجهی مورد انتظار هستند. با این حال، اخیراً آنها در تلاش بودهاند تا با نیازهای متغیر مشتریان خود هماهنگ شوند اما به نظر میسد که مدام از آنها عقب میافتند و نیاز به قدمهای سریعتر و چابکتری دارند.
شرکت توسط یک مشتری بزرگ برای توسعه یک نرمافزار جدید استخدام شد. مشتری الزامات (Requirements) بسیار خاصی داشت و آنها تحت فشار زیادی برای تحویل نرمافزار به موقع قرار گرفتند چرا که درخواستهای مشتری حجم زیادی داشت و مدام تغییر میکرد. این تمرکز تیم روی تحویل به موقع نرم افزار تطابق محصول با انتظارات مشتری و در نهایت رضایت مشتری از محصول را سراسر تخریب میکرد.
پیامدهای بیتوجهی به ارزشهای بنیادین مانیفست چابک
شرکت تصمیم گرفت تا از رویکرد آبشاری سنتی برای توسعهی این نرمافزار استفاده کند. این رویکرد یک رویکرد خطی برای توسعه است که در آن هر مرحله از پروژه باید قبل از شروع مرحله بعدی تکمیل شود. رویکرد آبشاری اغلب برای پروژههایی استفاده میشود که الزامات آنها به خوبی تعریف شده است و یک جدول زمانی قابل پیشبینی دارند.
با این حال، شرکت ارزشهای اصلی چابکی را نادیده گرفت:
افراد و تعاملات مهمتر از فرایندها و ابزارها:
شرکت به جای تمرکز بر افراد و گسترش موثر تعاملات بر پیروی از یک فرایند انعطافناپذیر تمرکز کرد. این اتفاق میتواند منجر به تیمهایی شود که به صورت ایزوله شده عمل میکنند و به خوبی با یکدیگر ارتباط برقرار نمیکنند. طبیعتا این عدم توانایی در ارتباط منجر به عدم توانایی تیمها در انطباق با تغییر میشود که این خود میتواند یک مشکل بزرگ در دنیای توسعه نرمافزار باشد.
نرمافزار کارآمد مهمتر از جمع آوری مستندات جامع:
از طرفی شرکت به جای تمرکز بر تحویل نرم افزار کارآمد برای مشتری به شکل وسواسی به جمع آوری دقیق مستندات جامع پروژه تمرکز کرد. این کار میتواند منجر به صرف زمان و منابع زیادی توسط تیمها برای جمع آوری مستنداتی شود که هرگز استفاده نمیشود چرا که نسخههای متفاوت یک نرم افزار همواره در خطر منسوخ شدن و کنار رفتن از بازار هستند و مستندات جمع آوری شده هرقدر هم که کامل باشند پس از به پایان رسیدن چرخهی عمر محصول اعتبار خود را تا حد زیادی از دست می-دهند. بنابراین چنین رویکردی میتواند منجر به عدم تحویل نرمافزار کارآمد به مشتری شود، که در یک پروژهی تولید و توسعهی نرم افزاری مهمترین چیز است.
برای مثال تصور کنید که مایکروسافت به جای صرف زمان برای تولید و توسعهی ویندوز 7 به جمع آوری تمام مستندات جامع پروژهی ویندوز XP پرداخته بود!
همکاری با مشتری مهمتر از مذاکره برای قرارداد:
شرکت هارولد اند هان مشتری را در فرآیند توسعه درگیر نکرد و بازخورد آنها را در مورد نرمافزار مورد توجه قرار نداد تا زمانی که کار توسعهی آن به شکل کامل تمام بشود. این رویکرد میتواند منجر به عدم انطباق نرمافزار با نیازهای مشتری شود که این خود موجبات نارضایتی مشتری از نرمافزار را فراهم میکند، که خود میتواند یک مشکل بسیار بزرگ باشد.
بنابراین پیام دیگر این اصل بنیادین Agile برای ما این است که تیم باید تمام تلاش خود را برای برآورده کردن نیازهای مشتری انجام دهد و نسبت به درخواستهای او همگام و منعطف باشد تا به مهمترین هدف یک پروژهی نرم افزاری، یعنی رضایت کاربر از نرم افزار، دست پیدا کند.
پاسخگویی به تغییر مهمتر از پیروی از یک برنامه:
شرکت در طول اجرای پروژه حاضر به تغییر برنامه نبود، حتی زمانی که الزامات مشتری تغییر میکرد. این ذهنیت میتواند منجر به تحویل نرمافزار دیرتر از زمان تعیین شده یا با مبلغی بالاتر از بودجهی تعیین شده شود که درنهایت نارضایتی عمیق مشتری از محصول شرکت نرم افزاری را به دنبال خواهد داشت.
در جدول زیر تلاش کردهایم تا شمایی کلی از مانیفست چابک، تفاوت آن با رویکرد سنتی آبشاری و ارزشهای ترجیحی Agile، مزایای وفاداری به اصول بنیادین و معایب روی گرداندن از آن برای پروژههای نرم افزار به دست بدهیم:
| رویکرد سنتی آبشاری | ارزش ترجیحی Agile | مزایای انجام ارزشهای بنیادین | معایب رویگردانی از ارزشهای بنیادین |
|---|---|---|---|
| فرایندها و ابزارها | افراد و تعاملات | تیمها میتوانند بهطور مؤثر ارتباط برقرار کرده و همکاری کنند، و با تغییر سازگار شوند. | تیمها ممکن است نتوانند بهطور مؤثر ارتباط برقرار کرده و همکاری کنند، و همچنین ممکن است نتوانند با تغییر سازگار شوند. |
| مستندات جامع | نرمافزار کارآمد | تیمها میتوانند نرمافزار کارآمد را به مشتری در سریعترین زمان ممکن تحویل دهند. | تیمها ممکن است در تحویل نرمافزار کارآمد به مشتری در سریعترین زمان ممکن شکست بخورند. |
| مذاکره برای قرارداد | همکاری با مشتری | تیمها میتوانند مشتری را از ابتدا در فرآیند توسعه درگیر کنند و بازخورد مشتری را به طور منظم دریافت کنند. | تیمها ممکن است نتوانند مشتری را از ابتدا در فرآیند توسعه درگیر کنند و ممکن است نتوانند بازخورد مشتری را به طور منظم دریافت کنند. |
| پیروی از یک برنامه | پاسخگویی به تغییر | تیمها میتوانند با تغییرات سازگار شوند و در صورت لزوم مایل به تغییر برنامه هستند. | تیمها ممکن است نتوانند با تغییرات سازگار شوند و مایل به تغییر برنامه در صورت لزوم نباشند. |
پیشنهاد مطالعه
مقایسه مدیریت چابک و سنتی (کلاسیک): بازی تغییرات
شکست پروژه!!
با بی توجهی به مانیفست چابک، پروژه در نهایت به شکست انجامید. نرمافزار به موقع تحویل داده نشد و نیازهای مشتری را برآورده نکرد. مشتری بسیار ناراضی بود و قرارداد خود را با شرکت تمدید نکرد.
پیامدهای آموخته شده درمورد مانیفست چابک
هارولند اند هان از این تجربه درس مهمی گرفت. آنها آموختند که مانیفست چابک فقط مجموعهای از کلمات کلیدی نیست. این یک مجموعه از ارزشهای اصلی و سنگ بناهای ضروری یک طرز فکر است که میتواند با تغییر ریشهای ذهنیت تیمها در جهتی همگامتر و سازگارتر با بازار و به تیمها در تحویل پروژههای نرمافزاری موفق کمک کند.
شرکت همچنین آموخت که باید در رویکرد توسعه خود انعطافپذیرتر و سازگارتر باشد. چنانچه الزامات مشتری تغییر کند شرکت باید با انعطاف لازم خواستههای متغیر مشتری را پاسخ بگوید و همچنین مشتری را از ابتدا در فرآیند توسعه درگیر کنند.
دیدگاهتان را بنویسید