پیاده سازی رویکرد چابک (Agile) در مقایسه با رویکرد آبشاری (Waterfall)

اغلب در مقالات و گفتگوهای کنفرانس می‌شنویم که چگونه افراد مشکلات  رویکرد “آبشاری” خود را با اجرای رویکرد چابک، اسکرام، XP ، کانبان، و سایر کلمات کلیدی که  آنها را نامگذاری می‌کنیم، حل می‌کنند.
دلیل انتقال بسیاری از افراد از رویکرد “چابک”  دقیقا چیست؟ با در نظر گرفتن چارچوب‌های محبوب، افراد فرایندهای مربوط به آنها را بدون هیچگونه تغییر سازمانی فرهنگی یا گسترده تر اعمال می‌کنند. نمونه بارز آن زمانی بود که شخصی در یک کنفرانس از پیوستن به رویکرد اسکرام ابراز خوشحالی می‌کرد، توسعه در بخش‌های کوچک تکرار شوند (Iterations) قابل پیش بینی برای آنها آسان بود، بنابراین آنها می‌توانند به موقع موارد را تحویل بگیرند. وقتی از آنها پرسیدند که چگونه گزارش‌های خود را اداره می‌کنند، آنها گفتند: “ما این کار را نمی‌کنیم، اولویت‌ها و ترتیب توسعه پس از تعریف دامنه تغییر نمی‌کنند.” بنابراین برای سوال بعدی از آنها پرسیدند، “رویکرد چابک کجا است، اگر شما از تغییرات احتمالی مراقبت نکنید؟ آنها گفتند “چگونه  آنها را نمی‌بینید؟ ما تکرارها و آیین نامه را اجرا می‌کنیم”.
بدیهی است، هنگام اجرای برخی از روش‌های چابک، سازمان‌ها بلافاصله سریع نمی‌شوند.با این حال، به نظر نمی‌رسد اجرای فرهنگ چابک واقعی در بعضی موارد به هدف منجر شود. این با آنچه در مورد اجرای همه راهنما‌ها و کتابچه‌های راهنمای چابک گفته می‌شود متناقض است، اما هنوز هم شرکت‌ها به دنبال آن هستند و با کمال تعجب از اجرای آن خوشحال هستند!
این نتیجه بسیار جالب بود که سازمان‌ها وقتی این انتقال را انجام می دهند، لزوما نمی‌خواهند رویکرد چابک را پیاده‌سازی کنند، آنها فقط می‌خواهند از مدل آبشاری فرار کنند. و فرار از رویکرد آبشاری می‌تواند به اشکال مختلفی به وجود آید، بنابراین ایده کلی رایج برای مقایسه رویکرد “آبشاری” در مقابل “چابک” به عنوان دو افراط در مقابل هم از نظر مفهومی صحیح نیست. برای درک بهتر این مطلب پیشنهاد می‌شود مقاله “برداشت‌های نادرست از رویکرد مدیریت چابک” را نیز مطالعه کنید.

تاریخچه و معمای مدل آبشاری

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

بهترین شیوه‌ها و چارچوب‌هایی که مربوط به بخش‌های مختلف دامنه است، وجود دارد. سؤال اینجاست که مدل سازی “آبشاری” معمولی در این طیف کجا قرار دارد؟ با توجه به اینکه در مورد “بهترین شیوه‌ها” و “چارچوب‌های مستقر” صحبت می‌کنیم، پاسخ “هیچ جا” است. اگر به ابتدای موضوع برگردیم کمتر تعجب آور خواهد بود. در سال ۱۹۷۰ دکتر وینستون دبلیو رویس مقاله معروف خود را با عنوان “مدیریت توسعه سیستم‌های بزرگ نرم افزاری” منتشر کرد که آغاز دوران مدل “آبشار” محسوب می‌شود.

اگر قبلاً تصویر بالا را دیده‌اید (و احتمالاً بارها هم آن را دیده‌اید)، باید بدانید که این واقعاً از مقاله دکتر رویس سرچشمه گرفته است. با این حال، نویسنده در مورد رویکرد مطرح شده در بالا اینگونه صحبت می‌کند:
” موضوعی که در بالا توضیح داده شد ریسک پذیر است و باعث شکست می شود.” و نکته جالب تر:
“تغییرات طراحی الزامات احتمالاً آنقدر مختل کننده خواهد بود که الزامات نرم افزاری که براساس آن طراحی شده است و دلیل اصلی همه چیز بر اساس آن نقض می‌شود. در واقع روند توسعه به مبدأ برگشته است و می‌توان افزایش آن را تا بیش از ۱۰۰ درصد در برنامه و یا هزینه‌های بیش از حد انتظار داشت”
بنابراین دکتر رویس که به پدر مدل آبشاری معروف است، چه پیشنهاد می‌کند؟
_ ابتدا باید یک مرحله طراحی اولیه برنامه بین مرحله تولید الزامات نرم افزار و مرحله تجزیه و تحلیل درج شود تا اطمینان حاصل شود که نرم افزار به دلیل ذخیره‌سازی، زمان بندی و تغییرات داده‌ها (مانند ارزیابی امکان راه حل) خراب نخواهد شد و سپس طراحی مستند شود.
_ توصیه بعدی این است که حداقل دو بار این کار را انجام دهید! ابتدا یک نمونه اولیه بسازید، آن را آزمایش کنید، سپس روی آن تکرار کنید. سپس وی در مورد مدیریت و کنترل آزمایش‌ها صحبت می‌کند، به ویژه بر این نکته تاکید می‌کند که “بسیاری از قسمت‌های آزمایش توسط متخصصین آزمون که لزوماً در طرح اصلی نقش ندارند” انجام می‌شود و برای هدایت پروژه در نظر گرفته شده است.
_ آخر اینکه، او گفت که شخص باید مشتری را درگیر کند. باز هم خواهم گفت: “مهم این است که مشتری را به شکلی رسمی درگیر کنید تا او در نقاط قبل از خروجی نهایی متعهد باشد.”

آیا اولین چیزی که هنگام شنیدن “آبشار” به ذهنمان خطور می‌کند، درست نیست؟ بیایید این توصیه‌ها را با “مشکلات آبشاری” رایج مقایسه کنیم، راه‌حل‌های کدام یک در رویکرد چابک مطلوب است؟ فقط چند نکته برجسته از منابع مختلف را ببینیم:
_ “غالباً طرح‌هایی که بر روی کاغذ امکان پذیر به نظر می‌رسند، در عمل گران و دشوار هستند و نیاز به یک طراحی مجدد دارند و از این رو، تمایز‌های واضح بین مراحل مدل آبشار سنتی را از بین می‌برند.”
_ “برجسته ترین انتقاد به این واقعیت اشاره دارد که اغلب اوقات، مشتریان واقعاً نمی‌دانند قصد دارند ابتدا از چه چیزی استفاده کنند؛ بلکه آنچه را که می‌خواهند از تعامل دو طرفه مکرر در طول پروژه پدیدار می‌شود.”
_ “هنگامی که یک برنامه در مرحله آزمایش است، برگشت به عقب و تغییر چیزی که در مرحله تصور کلی به خوبی در مورد آن فکر نشده است، بسیار دشوار است.”
_ “تعاملات مشتری بسیار کمتری در طول تولید محصول درگیر است. پس از آماده شدن محصول، فقط می‌توان آن را برای کاربران نهایی نمایش داد. پس از تولید محصول و در صورت بروز هرگونه خرابی، هزینه رفع چنین مواردی بسیار زیاد است، زیرا باید همه موارد از سند تا منطق را به روز کنیم. “
این لیست می‌تواند ادامه پیدا کند. آیا آشنا به نظر می رسد؟ بله. آیا این چیزی است که در مقاله رویس مورد توجه قرار نگرفته است؟ خیر.
البته جنبه‌های معمولی توسعه پیش بینی وجود دارد که ممکن است در مقایسه با توسعه انطباقی آزار دهنده باشد یا ضد تولید به نظر برسد، اما اجازه دهید فعلاً آنها را کنار بگذاریم. نکته در اینجا این است که بسیاری از آنچه افراد مشکلات اصلی مربوط به توسعه رویکرد “آبشار” می‌نامند، قبلاً ابزارهایی برای حل مشکلات با توسعه یک نرم افزار پیش بینی در همان مقاله اول داشتند.
حال بگذارید در این باره فکر کنیم: بین تاریخ انتشار مقاله و اکنون حدود ۵۰ سال تفکر وجود داشته است. البته چارچوب‌های مدیریت توسعه یافته و پیشرفته‌تر شده و با دنیای مدرن سازگار شده است. بنابراین چرا ما هنوز در مورد همه مشکلات یکسانی که دکتر رویس درباره آنها صحبت کرد، مانند اینکه محصولات به صورت امکان پذیر طراحی نمی‌شوند، و یا مشتریان در تولید محصول درگیر نمی‌شوند، و یا کیفیت در طول طراحی و توسعه در نظر گرفته نمی‌شود، صحبت می کنیم؟ اما وقتی مردم فرایندهای چابک را اجرا می‌کنند، این مشکلات حل می‌شود حتی بدون اینکه واقعا با طبیعت سازگار شوند!
جواب واضح و بسیار غم انگیز است. آنچه شرکت‌ها با آن روبرو هستند، شیوه‌های نادرست مدیریت پروژه است و راه حل آنها، اجرای فرایندهای جدید است. که در واقع هدفی برای تبدیل شدن از پیش بینی کننده بودن به سازگاری ندارد. آنها در سمت چپ از زنجیره مدیریت عدم اطمینان، احساس اطمینان می‌کنند، که خوب است. اما آنها از عدم اجرای شیوه‌های مناسب ناشی از موقعیت آنها در پارادایم رنج می‌برند. چابک اکنون کلمه کلیدی اصلی است، بنابراین وقتی یک شرکت متوجه می‌شود که فاقد فرهنگ مدیریت پروژه است، اولین چیزی که به ذهن آنها خطور می‌کند این است: “ما باید چابک شویم”.
با وجود اکثر فرایندهای  چابک، که فرهنگ مسئولیت مشترک و مشارکت کامل را وضع می‌کنند، می‌توان نقص‌های مدیریت پروژه را اصلاح کرد، که در نهایت منجر به پروژه‌های بهتری می‌شود. این امر باعث می‌شود فرایندها کمتر موردی باشند، که ارزش به ارمغان می‌آورند. اجازه دهید صادق باشیم، اجرای یک پروژه بزرگ قابل پیش بینی بسیار دشوار است؛ فشار بر مدیریت پروژه زیاد است. هنگامی که این مسئولیت‌ها به طور جزئی در تیم پخش می‌شود، و با بخشی از فرایندهای دیگر جایگزین می‌شوند و در طی جلسات آموزشی به عنوان بخشی از یک تحول دوباره مورد بازبینی قرار می‌گیرند، قطعاً در سازمان شاهد پیشرفت‌هایی خواهیم بود.

اهمیت موضوع

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

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