چطوری می‌شه پروژه‌ای رو چابک پیش برد؟
قطعا تو حوزه مدیریت پروژه زیاد به عبارت چابک یا Agile می‌رسین و ممکنه تصور کاملی ازش نداشته باشین، حوصله‌ش رو هم نداشته باشین که منابع کامل رو بخونین و یاد بگیرینش. تو این مطلب می‌خوام سعی کنم چابک بودن رو به سریع‌ترین و ساده‌ترین حالت ممکن توضیح بدم.
چه وقتی باید چابک بود؟
وقتی از روش‌های چابک استفاده می‌کنیم که عدم قطعیت‌ها و تغییرهای پروژه خیلی زیاد باشن. مثال همیشگی من اینه: فرض کنین قراره یه بیمارستان بسازین. ممکنه خیلی تغییرات به پروژه اعمال بشه، حتی ممکنه تعداد طبقه‌هاش کم و زیاد بشه، ولی احتمالا در آخر باز هم یه بیمارستان خواهد بود و مثلا یه شهر بازی از آب در نمیاد. غیر از اینه؟ ولی تو بعضی پروژه‌ها این‌طور نیست. مثلا تو پروژه‌های نرم‌افزاری ممکنه کار رو برای تولید یه «بیمارستان» شروع کنین و وقتی تموم می‌شه ببینین یه «شهر بازی» ساخته شده. روش‌های چابک برای این نوع پروژه‌ها در نظر گرفته شدن.
در حال حاضر از روش‌های چابک عمدتا برای پروژه‌های نرم‌افزاری و تا حدی برای پروژه‌های تحقیقاتی و تغییر سازمانی استفاده می‌شه. مثلا اگه می‌خواین یه ERP یا یه سیستم مدیریت اسناد تو سازمانتون پیاده‌سازی کنین می‌تونین چابک پیش ببرینش.
چابک بودن چطوریه؟
چابک بودن یعنی این‌که تغییرات رو بپذیریم و فضایی به وجود بیاریم که هر تغییری که ممکنه بخواد رخ بده سریع‌تر اتفاق بیفته. هرچقدر تغییر بیشتر اعمال بشه، احتمالا محصول نهایی به اون چیزی که کارفرما نیاز داره نزدیک‌تره و این یعنی موفقیت.
برای این که بتونیم تغییرات رو کشف کنیم و برای این‌که جلوی دوباره‌کاری و هدر رفتن انرژی رو بگیریم، محصول پروژه‌های چابک رو به شکل متفاوتی تولید می‌کنیم: اون رو مرحله به مرحله و تدریجی تولید می‌کنیم، طوری که دایما نسخه‌های قابل استفاده‌ای از محصول نهایی رو داشته باشیم تا بهره‌بردار بتونه ازش واقعا استفاده کنه یا بتونه راحت آزمایشش کنه و به این ترتیب بفهمه که واقعا چه چیزی لازم داره. از بازخوردش برای برنامه‌ریزی‌های بعدی استفاده می‌کنیم. همین ماجراس که باعث می‌شه روش‌های چابک رو به راحتی نتونیم تو هر نوع پروژه‌ای استفاده کنیم، چون محصولش طوری نیست که به راحتی بتونیم ازش حالتی چند مرحله‌ای و تدریجی به وجود بیاریم.
چون تو پروژه‌های چابک همه چیز در حال تغییره، از ابتدا کل پروژه رو برنامه‌ریزی نمی‌کنیم. ممکنه چهارچوبی خیلی کلی براش داشته باشیم، ولی برنامه‌ریزی به معنی واقعیش، فقط برای آینده نزدیک انجام می‌شه. در هر حال هم برنامه‌ریزی‌ها تو محیط چابک ساده‌تر انجام می‌شن.
یعنی دقیقا چطوری پروژه رو انجام می‌دیم؟
مثلا تو اسکرام اینطوری پیش می‌ریم:
- لیستی از عملکردهایی که کارفرما نیاز داره تهیه می‌کنیم. این می‌شه گستره محصول. صبر نمی‌کنیم که لیست کامل بشه، همینقدر که یه مقدار از راه رو نشون بده کافیه، می‌ریم مرحله بعد. این لیست همیشه باید مرتب باشه، یعنی هرچقدر آیتمی مهم‌تره، بالاتر قرار بگیره.
- بر اساس ظرفیتی که از خودمون برآورد می‌کنیم تعدادی از آیتم‌ها رو از بالای لیست برمی‌داریم و می‌ذاریم برای «اسپرینت» پیش رو. هر «اسپرینت» یه مدت زمانه که از قبل برای کار مشخص می‌کنیم؛ مثلا یک ماه، یا دو هفته.
- تو مدتی که اسپرینت در حال پیش رفتنه آیتم‌هایی که انتخاب کرده بودیم رو تولید می‌کنیم و از طرف دیگه اگه تغییری کشف بشه هم به لیست محصول اعمال می‌کنیم، ولی یادمون می‌مونه که هیچ چیزی رو تو لیست اسپرینت تغییر ندیم، چون تمرکزمون رو از بین می‌بره.
- وقتی مدت زمان اسپرینت تموم می‌شه یه نسخه جدید از محصول ساخته شده که یه مرحله کامل‌تر از قبله. این محصول رو که فقط شامل آیتم‌های صد در صد کامله در اختیار کارفرما قرار می‌دیم و توضیح هم می‌دیم. بعد بازخورد کارفرما رو دریافت می‌کنیم و تو لیست محصول اعمال می‌کنیم. یادتون باشه که انقدر کار نمی‌کنیم که تمام آیتم‌های اسپرینت تولید بشن؛ مدت زمان اسپرینت ثابته و نه کمش می‌کنیم و نه زیاد. هرچقدر آیتم که بشه تو اون مدت زمان تولید می‌کنیم و اگه نشه هم نشده!
- اگه لیست محصول تموم شده باشه یا کارفرما به این نتیجه برسه که محصولی که تا همین مرحله تولید شده براش کفایت می‌کنه، پروژه تموم می‌شه. وگرنه برمی‌گردیم به مرحله ۲.
نکته: خیلی از جنبه‌های اسکرام تو این مراحل گفته نشدن.
پس اتفاقی که می‌افته اینه که یه تعدادی اسپرینت اجرا می‌کنیم، یعنی بازه‌های مثلا ماهانه، و تو هر اسپرینت محصول رو یه مرحله بالغ‌تر می‌کنیم. انقدر این کار رو ادامه می‌دیم که ببینیم محصول برامون به اندازه کافی خوبه و پروژه تموم می‌شه. یه لیست از گستره محصول داریم که دایما داره تغییر می‌کنه و لیست دیگه‌ای هم برای گستره اسپرینت داریم، که بر خلاف قبلیه ثابته.
ولی مگه هر پروژه‌ای تدریجی و مرحله به مرحله انجام نمی‌شه؟
نه به اون معنی که تو روش‌های چابک در نظر داریم؛ مشکل اصلی اینه که من معادل خوبی برای عبارت‌های iterative و incremental به نظرم نمی‌رسه فعلا. اون محصول باید طوری باشه که هر نسخه‌ش هرچند به شکل محدود قابل استفاده باشه. ما باید همیشه این آمادگی رو داشته باشیم که پروژه در پایان یه اسپرینت تموم بشه و محصولش بره برای استفاده نهایی. وقتی داریم یه بیمارستان می‌سازیم هم اینطوریه؟ قطعا نه؛ معمولا تا وقتی پروژه تموم نشه محصولش قابل استفاده نیست.
پروژه‌های نرم‌افزاری رو هم قدیم مثل بیمارستان پیش می‌بردن؛ طوری مرحله به مرحله تنظیمش می‌کردن که تا وقتی کل مراحل انجام نشده بود محصول قابل استفاده‌ای وجود نداشت. ولی الان به اون سبک پیش نمی‌ریم.
از طرف دیگه، تو پروژه‌های کلاسیک گستره و کیفیت رو ثابت در نظر می‌گیریم و سعی می‌کنیم با بالا و پایین کردن زمان و هزینه خودمون رو منطبق کنیم. گستره تو پروژه‌های چابک ثابت نیست و نهایتا ممکنه زمان رو ثابت بگیریم (مثلا تو متود Atern). کاری که می‌کنیم اینه که حواسمون به ارزشی که هر بخشی از گستره تولید می‌کنه هست و طوری پروژه رو پیش می‌بریم که بیشترین ارزش ممکن در زودترین زمان به دست بیاد. معمولا هم این ماجرا با قاعده ۲۰/۸۰ پیش می‌ره، یعنی حدود ۸۰ درصد ارزش با ۲۰ درصد هزینه و زمان و انرژی تولید می‌شه. وقتی چابک پیش می‌ریم زمینه‌ای رو فراهم می‌کنیم که این مسئله به خوبی درک بشه و پروژه در زمان مناسب پایان داده بشه؛ جایی که پروزه با ۸۰ یا ۹۰ درصد ارزش نهاییش، ولی با ۲۰ تا ۴۰ درصد زمان و هزینه و انرژی تموم می‌شه. اگه تجربه‌ای تو پروژه‌های تغییر سازمانی داشته باشین (مثلا راه‌اندازی سیستم مدیریت اسناد) می‌تونین خیلی خوب درک کنین که تمرکز نکردن روی ارزش و وقت صرف کردن برای ریزه‌کاری‌های کم ارزش چقدر می‌تونه پروژه رو دچار مشکل کنه.