متدولوژی های چابک و آبشاری هرکدام مزایا و معایب بی نظیری دارند. در اینجا جوانب مثبت و منفی هر یک از روش ها و چگونگی دانستن اینکه برای پروژه های سازمان شما مناسب است آورده شده است.
متدولوژی چابک چیست؟
اولین بار در دهه 1970 در مقاله منتشر شده توسط ویلیام رویس در مورد توسعه سیستم های نرم افزاری بزرگ به طور عمیق مورد بحث قرار گرفت، چابک یک روش مدیریت پروژه است که از چرخه های توسعه تدریجی کوتاه به نام “اسپرینت” تشکیل شده است. هر چرخه بر بهبود مستمر توسعه محصول یا خدمات متمرکز است. با راهنمایی چهار ارزش اساسی و 12 اصل در بیانیه چابک، یک رویکرد تکرارپذیر و مردم محور برای توسعه نرم افزار فراهم می کند و شامل فرایندهای زیر است:
- برنامه ریزی: این اولین قدم شامل مشتریان و ذینفعان اصلی است که برای ایده پردازی، بارش فکری، تعریف، اولویت بندی، منابع و بودجه یک پروژه با هم کار می کنند، سپس تصویب و آغاز می شود.
- طراحی: کارشناسان تجربه کاربری با کارشناس ارشد، مشتری، تیم محصول و سایر سهامداران اصلی Scrum همکاری می کنند تا محصول را از نظر ظاهری و سایر عناصر مورد نظر تعیین کنند.
- توسعه: در این مرحله ساخت، تیم توسعه از طریق تکرارهای مختلف به نام “اسپرینت” برای ایجاد محصولی مطابق با نیاز مشتری کار می کند.
- تست: این فاز محصول را مطابق با الزامات تضمین می کند. در صورت شناسایی نقص، محصول قبل از آزمایش مجدد، از طریق یک مرحله توسعه دوباره برطرف می شود. این چرخه تا رسیدن محصول به مشخصات یا اهداف مورد نظر ادامه می یابد.
- استقرار: پس از کامل شدن، محصول نهایی یا قابل تحویل به مشتری ارائه می شود.
- بازخورد: سپس تیم ها به کل روند کار نگاه می کنند تا ارزیابی کنند که چگونه محصول یا عملکرد تیم را بهبود ببخشند.
مهارت هایی که در توسعه چابک نقش دارند
تیم های چابک بسیار متمرکز بر مشتری هستند، به خوبی با تغییر شرایط سازگار می شوند و حتی در شرایط فشار نیز در تحویل محصول بسیار عالی عمل می کنند. توسعه چابک، نه تنها در مقابل تیم بلکه درمقابل مشتری به افرادی با حس کار تیمی و پاسخگویی قوی نیاز دارد. آنها در یک محیط سریع رشد می کنند و بر کیفیت و بهبود محصولات قابل تحویل و فرآیندها متمرکز هستند.
متدولوژی آبشاری چیست؟
روش آبشاری نیز در توسعه محصول استفاده می شود اما روند توسعه به دنبال یک توالی خاص از ابتدا تا انتها هنگام تحویل پروژه نهایی، خطی است. تیم های پروژه هر فرآیند یا چرخه زیر را به ترتیب دقیق و دقیق اجرا و کامل می کنند.
- جمع آوری و تجزیه و تحلیل الزامات: در اینجا اطلاعات مربوط به عملکرد، سیستم یا مشخصات فنی مورد استفاده در یک پروژه از مشتریان و سایر ذینفعان اصلی جمع می شود.
- طراحی: کارشناسان تجربه کاربر با مشتریان، تیم محصول و سایر ذینفعان کلیدی کار می کنند تا محصول را از نظر ظاهری و سایر عناصر مورد نظر تعیین کنند.
- تست: سپس عملکرد، سیستم ها و تست پذیرش کاربر برای اطمینان از مطابقت محصول با شرایط شناسایی شده انجام می شود. در صورت کشف نقص یا اشکال، قبل از انتشار رفع می شود.
- تحویل نهایی پروژه: هنگامی که محصول با مشخصات تعیین شده در ابتدای پروژه مطابقت داشت، محصول به مشتری تحویل داده می شود.
- تعمیر و نگهداری: پس از تحویل، مشتری می تواند تغییرات اضافی را برای افزودن و تأیید درخواست کند. این امر منجر به هزینه و زمان اضافی پروژه می شود.
مهارت های درگیر در روش آبشاری
تیم های پروژه آبشاری سنتی در یک محیط ساختاریافته که فرایندها و رویه ها به خوبی جا افتاده اند به خوبی کار می کنند. آنها به هیجان زیادی احتیاج ندارند و در عوض بدون آنها بهتر کار می کنند. آنها روشمند و بر نیازها متمرکز هستند. اعضای تیم می توانند با ذینفعان از بسیاری از مناطق مختلف سازمان و همچنین مشتریان همکاری خوبی داشته باشند و از سیاست ها و دستورالعمل های دقیق پیروی کنند.
چابک در برابر آبشار: جوانب مثبت و منفی
استفاده از چابک و استفاده از آبشار فواید زیادی دارد، از جمله موارد زیر:
|
آبشاری |
چابک |
|
|
· اگرچه این چرخه ها رسمی تر و متوالی تر هستند، اما برای تیم های کوچک و بزرگ فرآیندهای طولانی و مرتب آسان است. · چرخه های توسعه تعیین شده می توانند ثبات بیشتری را برای تیم های جدید آغاز کنند. · الزامات پروژه در ابتدا ایجاد می شود، و اجرای پروژه را با پیچیدگی کمتر و با اهداف متحرک کمتر می کند. · پروژه کامل از همان ابتدا بودجه بندی و منابع لازم را فراهم کرده و مدیریت انتظارات و خطرات را آسان می کند. |
· توسعه سریع و در عین حال انعطاف پذیر است. · با توجه به اسپرینت های تکرار شونده کوتاه و تمرکز بر کیفیت، تیمها قادر به شناسایی و رفع نقص بسیار سریعتر از آبشار هستند. · به تیم های کوچک مختلف می توان وظایف مختلفی را عهده دار شد که ممکن است جنبه ها یا مراحل مختلف توسعه را تأمین نکند. · تکرار اجازه می دهد تا در صورت لزوم، تغییرات سریع در حین تولید ایجاد شود. |
موافقان |
|
· توسعه به دلیل ماهیت متوالی، کندتر و از انعطاف پذیری کمتری برخوردار است و به اتمام مراحل قبلی بستگی دارد. · مسائل معمولاً بعداً در مرحله آزمایش کشف می شوند. · الزامات در آغاز پروژه تعیین و تأیید می شود. تغییرات دامنه بعید به نظر می رسد یک گزینه باشد. |
· چابک به یک استاد اسکرام احتیاج دارد که با اسپرینت تجربه داشته باشد و به دلیل سریع بودن تکرارها، به راحتی متلاشی نشود. · مشتریان ممکن است از بسیاری از درخواست ها برای بررسی تغییرات ناامید شوند. · اگر تیم ها به خوبی سازمان یافته یا خودگردان نباشند، چابک ممکن است مشکلاتی را برای تیم های دورکار مستقر در مناطق مختلف جهان در مناطق زمانی مختلف ایجاد کند. |
مخالفان |
|
· تیم هایی که به یک جدول زمانی پروژه قابل پیش بینی و متوالی تر نیاز دارند و بودجه مشخصی دارند. · تیم های پروژه با تجربه کمتر. · شرکت هایی که تحمل کمتری در برابر تغییر یا ریسک دارند. · شرکت هایی که مشتریانشان از نظر زمان و منابع محدود هستند و نمی توانند مرتباً همکاری کنند. · پروژه های ساده با الزامات ساده. · پروژه هایی که از امتیاز داشتن جدول زمانی طولانی تر بهره مند هستند. |
· تیم های توسعه نرم افزار با عملکرد بالا، به ویژه در زمینه توسعه نرم افزار. · سازمانهایی که بر روی محصولات قابل تحویل با کیفیت بالا و بهبود مستمر متمرکز هستند، به ویژه اگر کیفیت با پیشنهاد ارزش آنها یا تمایز رقابتی همسو باشد. · شرکت های بزرگ و پیچیده ای مانند IBM ، Cisco ، AT&T و Microsoft فرایندهای خود را ساده کرده و با استفاده از چابک سریعتر به تغییرات پاسخ می دهند. · تیم های پروژه ای که به طور منظم با مشتریان و دیگر طرف های خارجی همکاری نزدیک دارند. · تیم هایی که به بازخورد سریع در مورد محصولات قابل تحویل نیاز دارند تا اینکه منتظر بمانند تا یک پروژه کامل شود. |
ممتنعین |
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.