مکانیک مدیریت پروژه: مقایسه متدولوژی‌های آبشار، چابک و اسکرام

رایج‌ترین اشتباه در مدیریت پروژه مدرن، فرض بر این است که متدولوژی «چابک» (Agile) به طور کلی بر «آبشار» (Waterfall) برتری دارد. با توجه به پذیرش سریع توسعه تکراری توسط صنعت نرم‌افزار طی دو دهه گذشته، سازمان‌ها در بخش‌های مختلف برای اجرای چارچوب‌های چابک شتاب کرده‌اند؛ اما اغلب هنگام به‌کارگیری این چارچوب‌ها در مهندسی فیزیکی، ساخت و ساز یا استقرارهای سازمانی با دامنه ثابت، نتایج فاجعه‌باری به بار آمده است.

واقعیت این است که متدولوژی‌های مدیریت پروژه ارتقای تکاملی یکدیگر نیستند؛ بلکه ابزارهای مکانیکی متمایزی هستند که برای پروفایل‌های ریسک و ساختارهای نیازمندی کاملاً متفاوتی طراحی شده‌اند.[3][4]

هسته اصلی این سردرگمی، سوءتفاهم در مورد اینکه این متدولوژی‌ها در واقع چه چیزی را کنترل می‌کنند، است. متدولوژی آبشار، که اولین بار در سال ۱۹۷۰ برای سیستم‌های نرم‌افزاری در مقیاس بزرگ رسمی شد اما ریشه در تولید و ساخت و ساز دارد، «دامنه» پروژه را کنترل می‌کند.

این متدولوژی فرض می‌کند که نیازمندی‌ها می‌توانند قبل از شروع کار به طور کامل شناخته شوند و هزینه تغییر آن نیازمندی‌ها در مراحل بعدی بسیار بالا است. در مقابل، متدولوژی چابک «زمان و هزینه» را کنترل می‌کند در حالی که اجازه می‌دهد دامنه سیال باقی بماند. این متدولوژی فرض می‌کند که نیازمندی‌ها به ناچار با ساخت و آزمایش محصول تغییر خواهند کرد، و برنامه‌ریزی سخت‌گیرانه اولیه را به جای یک محافظ، یک عامل بازدارنده می‌داند.[2][3]

اسکرام، که اغلب با چابک اشتباه گرفته می‌شود، در واقع یک چارچوب خاص و تجویزی برای پیاده‌سازی اصول چابک است. در حالی که چابک یک فلسفه توسعه تکراری و همکاری با مشتری است، اسکرام سازوکارهای مکانیکی دقیقی را فراهم می‌کند: «اسپرینت‌های» زمان‌بندی‌شده، نقش‌های تعریف‌شده مانند اسکرام مستر (Scrum Master) و مالک محصول (Product Owner)، و مراسم‌های خاص مانند جلسه روزانه (Daily Standup) و بازنگری اسپرینت (Sprint Retrospective). درک تمایز بین فلسفه (چابک) و سازوکار (اسکرام) برای تیم‌هایی که تلاش می‌کنند از برنامه‌ریزی متوالی سنتی فاصله بگیرند، حیاتی است.[1][4]

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

با این حال، از آنجایی که آزمایش و بازخورد کاربر تنها در پایان چرخه رخ می‌دهد، ممکن است یک نقص اساسی در طراحی اولیه تا زمانی که ماه‌ها یا سال‌ها توسعه تأمین مالی و اجرا شده است، کشف نشود.[2]

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

بده‌بستان این روش، فقدان قابلیت پیش‌بینی بلندمدت است؛ یک تیم چابک می‌تواند تضمین کند که در دو هفته آینده چه چیزی را تحویل خواهد داد، اما نمی‌تواند به طور دقیق پیش‌بینی کند که محصول نهایی در یک سال آینده دقیقاً چگونه خواهد بود یا چقدر هزینه خواهد داشت.[3]

اسکرام این تحویل تکراری را از طریق زمان‌بندی سخت‌گیرانه (time-boxing) اجرا می‌کند. کار در قالب اسپرینت‌ها سازماندهی می‌شود که معمولاً دو تا چهار هفته طول می‌کشند. در طول یک اسپرینت، تیم متعهد به انجام مجموعه‌ای خاص از وظایف می‌شود که از لیست اولویت‌بندی شده محصول (Product Backlog) انتخاب شده‌اند. نکته حیاتی این است که پس از شروع یک اسپرینت، هیچ کار جدیدی نمی‌تواند به آن اضافه شود.

این امر یک پنجره تمرکز محافظت‌شده برای تیم توسعه ایجاد می‌کند، در حالی که همچنان به کسب‌وکار اجازه می‌دهد اولویت‌های خود را در شروع اسپرینت بعدی تغییر دهد. اسکرام مستر به عنوان داور عمل می‌کند و اطمینان می‌دهد که قوانین چارچوب رعایت می‌شوند و موانعی که سرعت تیم را کاهش می‌دهند، برطرف می‌کند.[1]

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

این ترکیب هیبریدی «آبشار-اسکرام-فال» اصطکاک عظیمی ایجاد می‌کند، زیرا تیم با سربار جلسات اسکرام مواجه می‌شود بدون اینکه استقلال لازم برای انطباق واقعی با نیازمندی‌های متغیر را داشته باشد.[3][4]

برعکس، به‌کارگیری چابک در پروژه‌هایی با هزینه‌های تغییر بالا – مانند ساخت یک پل یا تولید یک قطعه سخت‌افزاری فیزیکی – به همان اندازه مخرب است. در این محیط‌ها، هزینه تکرار بر روی یک نمونه اولیه فیزیکی به طور تصاعدی بالاتر از تکرار بر روی کد نرم‌افزار است. تأکید شدید آبشار بر طراحی اولیه و فرآیندهای سخت‌گیرانه کنترل تغییر، یک مصنوع بوروکراتیک نیست؛ بلکه یک مکانیسم دفاعی ضروری در برابر افزایش فاجعه‌بار هزینه‌ها در محیط‌هایی است که نمی‌توانید به سادگی یک فونداسیون بتنی را «مجدداً کامپایل» کنید.[2][4]

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