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

به طور کلی پروژه ها را می توان در طیفی در نظر گرفت که در یکسوی آن پروژه های چابک (Agile) قرار داشته و در سوی دیگر آن پروژه های آبشاری (Waterfall) قرار دارند. در میانه این طیف هم پروژه های ترکیبی (Hybrid) یعنی ترکیبی از چابک و آبشاری به نسبت های مختلف قرار می گیرند.

پروژه های آبشاری ، پروژه هایی هستند که فازهای تشکیل دهنده چرخه حیات (Life Cycle) آن ها به دنبال یکدیگر قرار می گیرند.

به عنوان مثال احداث ساختمان دو طبقه بتنی، یک پروژه آبشاری است.

 ابتدا باید فونداسیون اجرا شود بعد طبقه اول و بعد طبقه دوم، فعالیت های هر یک از فازها نیز با کمی همپوشانی به دنبال یکدیگر انجام می شوند مثلاً در هنگام اجرای فونداسیون ابتدا باید خاکبرداری انجام شود بعد آرماتور بندی ، بعد قالب بندی و  بعد از آن بتن ریزی انجام خواهد شد.

پروژه های چابک ، پروژه هایی هستند که فازهای تشکیل دهنده چرخه حیات (Life Cycle) آن ها می توانند به صورت آبشاری در نظر گرفته نشوند.

بهترین مثال برای یک پروژه چابک، یک پروژه نرم افزاری کوچک مانند نوشتن یک اپلیکیشن است.

فازهای پروژه نوشتن یک اپلیکیشن به صورت آبشاری می تواند مشابه شکل زیر باشد:

اما نکته مهم آن است که فازهای پروژه نوشتن یک اپلیکیشن این قابلیت را دارند که مشابه شکل زیر به صورت آبشاری در نظر گرفته نشوند:

در حقیقت شکل فوق نمونه ای از چرخه حیات یک پروژه چابک است، بدین معنی که با اجرای قسمتی از یک فاز مانند تحلیل نیازمندی ها می توان وارد فازهای بعدی شد. به عنوان مثال با رویکرد مدیریت پروژه چابک، نوشتن یک اپلیکیشن می تواند در عمل بدین صورت انجام شود که به جای آنکه تحلیل نیازمندی ها، طراحی و کد نویسی، یکپارچه سازی  و تست و اجرا برای کل اپلیکیشن به صورت مراحل پی در پی (آبشاری) اجرا شود، اپلیکیشن بخش بندی شده و برای هر بخش مراحل فوق تکرار شوند.

مانیفست چابکی (Agile Manifesto)

در سال 2001 گروهی از متخصصین فعال در نوشتن پروژه های نرم افزاری با همکاری یکدیگر مانیفست چابکی را به شرح زیر تنظیم کردند:

(لینک ویکیپدیا: https://en.wikipedia.org/wiki/Agile_software_development)

• افراد و تعاملات مهمتر از فرآیندها و ابزارها هستند.
• نرم افزاری که کار کند مهمتر از مستندسازی گسترده می باشد.
• تعامل با مشتری مهمتر از مذاکرات قراردادی است.
• پاسخگویی به تغییرات مهمتر از پیروی از یک برنامه است.

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

مدیریت پروژه چابک با هدف سازگاری با تغییرات ایجاد شده است.

تمرکز روی تولید محصول

یکی از ویژگی های متمایز در پروژه های چابک آن است که به طور معمول تیم های چابک (Agile Teams) به خصوص تیم هایی که در زمینه نوشتن نرم افزار فعال هستند، بیشتر روی تولید محصول متمرکز هستند تا انجام پروژه؛ بدین معنی که تیم های چابک به طور معمول انتظار دوباره کاری زیادی را دارند یکی از شعارهای معروف تیم های XP (XP یکی از چارچوب های معروف مدیریت پروژه چابک است) آن است که” نباید از اینکه نرم افزاری را دور بیاندازید هراسی داشته باشید، اگر آن نرم افزار از کیفیت لازم برخوردار نباشد!” آن ها به این کار ساخت دوباره نرم افزار (Software Refactoring) می گویند که این به معنی بهینه سازی مستمر نرم افزار در حین نوشتن آن است. در حقیقت ایده پشت این موضوع آن است که خیلی ساده تر است که یک محصول را درست کرد و اگر کیفیت لازم را نداشت آن را دور انداخت! به جای اینکه از اول وقت خود را صرف برنامه ریزی همه جزئیات کرد!

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

در خصوص هزینه ها هم برنامه ریزی دقیق از ابتدا ضرورتی ندارد چرا که اگر در حین اجرای کار، ایده های جدیدی به ذهن مشتری یا برنامه نویس برسد که درخشان باشند! و مشتری حاضر باشد با رضایت کامل هزینه بیشتری برای تحقق این ایده ها بپردازد و حتی زمان بیشتری منتظر محصول مورد نظر خود بماند، این موضوع چه ایرادی می تواند داشته باشد! در این شرایط همه از نتیجه کار راضی هستند!

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

این دیدگاه بسیار جسورانه است و در تضاد با مفاهیم سنتی مدیریت پروژه یعنی لزوم برنامه ریزی، پایبندی و مدیریت محدودیت های اصلی پروژه مانند محدوده (Scope)، زمان (Time) و هزینه (Cost) قرار دارد! اما این موضوع هیچ اهمیتی ندارد، چرا که با کنار گذاشتن نگاه سنتی به مدیریت پروژه، نهایت انعطاف پذیری برای تحقق خواسته های مشتری و ایجاد یک محصول، با کیفیت مورد نظر مشتری فراهم شده است!

درآغوش کشیدن تغییرات!

یکی از شعارهای تیم های XP در آغوش کشیدن تغییرات (Embracing Changes) است. برای درک این موضوع تصور کنید که شما سفارش ساخت یک اپلیکیشن را به یک تیم چابک داده اید. از دیدگاه مدیریت پروژه چابک ایده آل، شما جدا از تیم نوشتن نرم افزار نیستید، شما می توانید نقش مالک محصول (Product Owner) را در تیم چابک بازی کنید! بدین معنی که انگار برنامه نویسان در تمام مدت در کنار شما نشسته است! شما می توانید هر تغییری را آزادانه مطرح کنید و برنامه نویسان از هر تغییری با آغوش باز استقبال می کند! یعنی برنامه نویسان به جای آنکه با خود بگویند ما با مشتری تعامل برقرار نمی کنیم چون از این موضوع نگرانیم که ممکن است مشتری با دیدن نحوه پیشرفت کار از نزدیک، ایده ها و تغییرات جدیدی مطرح کند و این موضوع می تواند دردسر زیادی برای ما ایجاد کند یا حتی تمام زحمات ما را زیر سوال ببرد یا باعث دوباره کاری بسیار زیادی برای ما بشود با خود می گویند مشتری عزیز لطفاً هر ایده و هر تغییری را که دوست می داری آزادانه مطرح کن! چرا که ما می دانیم هرچقدر تو بیشتر تغییرات مورد نظرت را مطرح کنی، احتمال اینکه ما بتوانیم نیازمندی های تو را در ارتباط با محصول در نهایت برآورده کنیم بیشتر می شود! و این یعنی موفقیت!

این دیدگاه جسورانه نیز در تضاد با رویکرد سنتی در مدیریت پروژه قرار دارد، چرا که در رویکرد سنتی، همواره تلاش می شود تا یک فاصله مناسب از مشتری یا کارفرما حفظ شود! تیم پروژه در ابتدای کار مشخصات کار (محدوده کار) را در قالب یک توافق یا قرارداد شفاف می کند و آن را به تائید مشتری یا کارفرما می رساند و قرار نیست در هر زمانی هر تغییری اعمال شود، تغییرات باید در قالب یک فرآیند از پیش تعریف شده و ترجیحاً رسمی مطرح شوند و تنها پس از تائید کمیته کنترل تغییرات توسط تیم پروژه اعمال خواهند شد (لطفا مقاله فرآیند مدیریت تغییرات را ملاحظه بفرمائید) البته این به معنی مخالفت رویکرد سنتی با مدیریت تغییرات نیست، اما قرار هم نیست کارفرما مرتب نظر خود را تغییر بدهد یا آنکه تیم پروژه با انبوهی از تغییرات غیر قابل پیش بینی از سوی کارفرما مواجه شوند!

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

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

رویکرد مدیریت پروژه چابک برای چه پروژه هایی قابل بکارگیری است؟

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

صرف نظر از تبلیغات گسترده و تحقیقات انبوه آکادمیک انجام شده، واقعیت آن است که بکارگیری رویکرد مدیریت پروژه چابک در پروژه هایی اثربخش می باشد که بتوان به سادگی در آن ها تغییرات مکرری را اعمال کرد و دوباره کاری و چند باره کاری ناشی از اعمال مکرر تغییرات را به آسانی انجام داد. می توان گفت که موفق ترین نمونه های بکارگیری رویکرد مدیریت پروژه چابک در پروژه های تولید محصولات دیجیتال (Digital Products) مانند تولید نرم افزار، تولید اپلیکیشن، ایجاد پایگاه های داده و موارد مشابه آن ها می باشد.

مدیریت پروژه چابک در صنعت ساخت

صنعت ساخت (Construction Industry) شامل طیف گسترده ای از پروژه ها مانند پروژه های احداث ساختمان، پل، راه، سد، نیروگاه، پالایشگاه، مترو و غیره می باشد (جهت مطالعه بیشتر به مقاله معرفی صنعت ساخت مراجعه فرمائید)

مقالات و پژوهش های آکادمیک زیادی در زمینه بکارگیری مدیریت پروژه چابک در صنعت ساخت انجام شده است اما واقعیت آن است که بکارگیری مدیریت چابک در عمل در صنعت ساخت بسیار دشوار است، زیرا اساساً ماهیت ذاتی چرخه حیات پروژه های صنعت ساخت آبشاری می باشد. شاید محتمل ترین امکان بکارگیری مدیریت پروژه چابک در این صنعت در فاز طراحی (Engineering) باشد، اگر فاز مهندسی پروژه های ساخت را یک پروژه مستقل تصور کنیم امکان تعریف برخی فعالیت های این فاز به صورت غیر آبشاری می تواند امکان پذیر باشد.

رویکرد چابک بهتر است یا رویکرد آبشاری؟

یکی از پرسش های مطرح فعالان حوزه مدیریت پروژه آن است که برای مدیریت پروژه ها رویکرد چابک بهتر است یا رویکرد آبشاری؟

در پاسخ به این پرسش باید گفت که بستگی به نوع پروژه دارد! یعنی برای برخی از پروژه ها رویکرد آبشاری بهتر عمل می کند و برای برخی دیگر رویکرد چابک می تواند اثربخش تر باشد.

نکته اصلی در ارتباط با این موضوع توانایی تعریف شفاف نیازمندی ها (Requirements) در ابتدای پروژه و ثابت بودن تقریبی آن ها در طول پروژه است.

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

اما اگر ماهیت پروژه به گونه ای باشد که تعریف شفاف نیازمندی ها در ابتدای کار امکان پذیر نباشد یا آنکه نیازمندی های شناسایی شده در ابتدای پروژه، در طول پروژه مرتباً تغییر کنند، در این شرایط بهترین گزینه رویکرد چابک خواهد بود!

می توان گفت دیدگاه های جسورانه مدیریت پروژه چابک در کنار گذاشتن مدیریت محدوده، مدیریت زمان و مدیریت هزینه پروژه به مفهوم سنتی آن، و در آغوش کشیدن تغییرات، می تواند در پروژه های با ماهیت نرم افزاری و دیجیتال بسیار کارساز باشد.

 تجربه نویسندگان این مقاله در تولید پروژه های نرم افزاری، نشان می دهد که در عمل نمی توان در ابتدای کار تمامی نیازمندی ها را به طور کامل شفاف کرد و در طول اجرای پروژه نیز کارفرما (مشتری) مرتباً نیازمندی های خود را تغییر می دهد. در مواجهه با این شرایط چه می توان کرد؟

تجربه نشان می دهد که اگر تیم تولید نرم افزار بر پایبندی به محدوده، زمان و هزینه تعیین شده در ابتدای پروژه و در چارچوب قرار داد امضاء شده توسط کارفرما، اصرار کند، نارضایتی گسترده ای در بدنه کارفرما ایجاد می شود که می تواند تمامی زحمات انجام شده را به کلی زیر سوال برده و در نهایت پروژه را با شکست مواجه کند!

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

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

مطرح ترین چارچوب ها در زمینه مدیریت پروژه چابک عبارتند از:

• اسکرام (Scrum)
• اکس پی (XP: Extreme Programming)
• کانبان (Kanban)
• کریستال (Crystal)
• و غیره

چارچوب اسکرام (Scrum)

یکی از مطرح ترین چارچوب های مدیریت پروژه چابک، چارچوب اسکرام (Scrum) می باشد. اسکرام نام یکی از انوع بازی راگبی است. دلیل استفاده از این نام آن است که در بازی اسکرام تمرکز تمام تیم روی گرفتن توپ می باشد! که در چارچوب اسکرام توپ معادل با محصول در نظر گرفته شده است.

این چارچوب اولین بار در سال ۱۹۸۶ توسط تاکوچی و نوناکا برای تولید نرم افزار مطرح شد.

روش کار بدین صورت است که دوره های زمانی کوتاه مدتی تحت عنوان اسپرینت (Sprint) که طول آن معمولاً 2 تا 4 هفته است در نظر گرفته می شود.

در ابتدای هر اسپرینت جلسه ای برگزار می شود، که در این جلسه تیم توسعه محصول همراه با مشتری، کارهایی را که باید در این اسپرینت انجام شوند، انتخاب می کنند. مشتری می تواند در طول پروژه نیازمندی های خود را تغییر دهد، اما این نیازمندی ها و تغییرات آن ها باید در ابتدای هر اسپرینت مطرح شوند؛ در طول هر اسپرینت نیازمندی ها تغییر نمی کنند، پس از پایان هر اسپرینت، تیم تولید محصول مجدداً جلسه ای با حضور مشتری برگزار می کند و نتیجه کار را برای مشتری ارائه می کند و مشتری می تواند آزادانه نظرات و تغییرات مورد نظر خود را مطرح کند. با این روش، محصول (مثلاً نرم افزار) به تدریج از طریق طی کردن دوره های تکراری (اسپرینت) تکمیل می شود. به همین دلیل گفته می شود که چارچوب اسکرام یک روش تولید محصول به صورت تکراری (Iterative) و با تکمیل تدریجی (Incremental) می باشد.

یک تیم اسکرام (Scrum Team) شامل نقش های زیر می باشد:

• اسکرام مستر (Scrum Master): فردی با تجربه است که رهبری تیم اسکرام را بر عهده دارد.
• مالک محصول (Product Owner): این نقش را معمولاً مشتری یا نماینده وی بر عهده می گیرد.
• تیم تولید محصول (Development Team): یک تیم 3 تا 9 نفری است که وظیفه انجام فعالیت های لازم برای تولید محصول را بر عهده دارند. (مثلاً برای یک محصول نرم افزاری وظیفه طراحی و کد نویسی، یکپارچه سازی و تست و اجرا می تواند بر عهده این تیم باشد)

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

• لاگ محصول (Product Backlog): که شامل فهرستی از داستان های کاربر (User Stories) همراه با اولویت بندی آن ها می باشد. منظور از داستان های کاربر نیازمندی های (Requirements) مطرح شده توسط کاربر (مشتری) می باشد که این داستان ها هدایت کننده پروژه می باشند. همچنین می توان گفت که لاگ محصول شامل فهرست اولویت بندی شده ای از تمامی ویژگی هایی (Features) است که باید برای تولید محصول ایجاد شوند.

• تخته وظایف (Task Board) که اسامی دیگر آن تخته اسکرام (Scrum Board) یا تخته کانبان (Kanban Board) می باشد که شامل فهرستی از فعالیت هایی هستند که باید توسط تیم انجام شوند.

• نمودارهای برن داون Burn-down Charts)): نمایش گرافیکی کار تکمیل شده و کاری که باید انجام شود بر محور زمان می باشد. علت استفاده از این اصطلاح آن است که کل کار باید مرحله به مرحله انجام شود (بسوزد-Burn به معنی سوختن است-) تا به صفر برسد.

• جلسات روزانه سرپایی (Daily Standup Meeting): به منظور هماهنگی بیشتر اعضای تیم با یکدیگر، بررسی کارهای انجام شده، تشریح کارهایی که باید انجام شوند، و همچنین رسیدگی به مشکلات و مسائل اعضای تیم، هر روز جلسات سرپایی با مدت زمان کوتاهی (مثلاً 15 دقیقه) برگزار می شود.

تذکر: باید توجه داشت که برخی از این تکنیک ها و ابزارها ممکن است در پروژه های آبشاری و هیبریدی نیز قابل بکارگیری باشند و بکارگیری یک یا چند مورد از این ابزارها در یک پروژه به معنی آن نیست که آن پروژه لزوماً چابک بوده یا رویکرد مدیریت آن پروژه، مدیریت پروژه چابک می باشد. (این اشتباه در برداشت متاسفانه بسیار دیده می شود)

همانطوریکه در این مقاله تشریح شد، ماهیت پروژه های آبشاری و چابک کاملاً از یکدیگر متفاوت است بنابراین آیا ترکیب دو رویکرد مدیریت پروژه سنتی و مدیریت پروژه چابک در عمل امکان پذیر است؟

برخی از فعالان حوزه مدیریت پروژه در دنیا سعی کرده اند این دو رویکرد را با یکدیگر ترکیب کنند، برخی از این فعالان می گویند ما می خواهیم مانند یک تیم چابک باشیم اما در عین حال یک برنامه مشخص همراه با مایلستون های تعریف شده از ابتدای پروژه داریم که مدیریت آن را تصویب کرده است و باید از آن پیروی کنیم و به آن برسیم! بنابراین بیایید دو رویکرد را با هم ترکیب کنیم و از هر دو استفاده کنیم!

رویکردهایی مانند ScrumBut (یعنی از Scrum استفاده می کنیم اما(But) …..) و AgileFall (یعنی Aglie+Waterfall) با این هدف مطرح شده اند و خیلی هم تبلیغ می شوند!

در این شرایط تصور کنید که شما زمان زیادی را صرف برنامه ریزی در ابتدای کار کرده اید اما تیم پروژه آزاد است که در مواجهه با تغییرات تمام برنامه ریزی انجام شده را دور بیاندازد!

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

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

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

نویسندگان :

رضا آتش فراز

محمد هادی صیرفی