واژهٔ «مدیریت پروژه چابک (Agile Project Management)» بیشتر با مراسمش شناخته می‌شود: جلسهٔ روزانه، اسپرینت دو هفته‌ای، تختهٔ کارها. اما این مراسم‌ها فقط وقتی ارزش دارند که یک چیز را تغییر دهند: فاصلهٔ میان تصمیم و شاهد. در پروژهٔ نرم‌افزاری، پرهزینه‌ترین خطا این نیست که کدی باگ داشته باشد؛ این است که تیم مدت‌ها چیزی را بی‌نقص بسازد که کسی به آن نیاز نداشته. چابک، پیش از هر چیز، روش کوچک کردن همین هزینه است.
کوچک کردن اندازهٔ شرط‌بندی
در روش آبشاری (Waterfall)، تصمیم‌ها یک‌جا و در ابتدا گرفته می‌شوند و بازخورد در انتها می‌رسد. اگر فرض اولیه غلط باشد، کل بودجه پیش از آنکه کسی متوجه شود خرج شده است. چابک این شرط‌بندی بزرگ را به شرط‌بندی‌های کوچک می‌شکند: هر بازهٔ کوتاه، یک تصمیم را می‌آزماید و اجازه می‌دهد مسیر بر اساس شاهد عوض شود.
پس معیار خوب بودن یک تیم چابک، تعداد مراسم‌ها یا سرعت تولید قابلیت نیست؛ این است که هر چند وقت یک‌بار چیزی را در معرض قضاوت واقعی کاربر می‌گذارد.
هر آیتم بک‌لاگ یک فرضیه است، نه یک کار
بیشترین آسیب وقتی می‌رسد که بک‌لاگ (Backlog) را فهرستی از کارها ببینیم. «ساخت داشبورد گزارش‌ها» یک کار است و معلوم نیست درست باشد. در مقابل، جملهٔ زیر یک فرضیه است:
- «اگر گزارش‌ها را در یک نما و بدون خروجی اکسل نشان دهیم، سرپرست پشتیبانی هر هفته خودش آن را باز می‌کند و برای تیم تصمیم می‌گیرد.»
فرضیه سه بخش دارد: یک تغییر، یک رفتار قابل مشاهده، و یک معیار موفقیت. وقتی آیتم بک‌لاگ به این شکل نوشته شود، تعریف «تکمیل» هم روشن می‌شود و بازبینی اسپرینت به جای نمایش اسلاید، به یک آزمون واقعی تبدیل می‌شود.
برش عمودی بزنید، نه افقی
رایج‌ترین اشتباه در شکستن کار، برش افقی است: اول همهٔ جدول‌های پایگاه داده، بعد همهٔ رابط‌های برنامه‌نویسی (API)، بعد همهٔ صفحه‌ها. نتیجه‌اش این است که تا نزدیک پایان پروژه، هیچ چیز قابل استفاده نیست.
- برش افقی: یک لایه در تمام قابلیت‌ها؛ هیچ چیز از دید کاربر تمام نمی‌شود.
- برش عمودی: یک مسیر کامل و باریک از ورودی تا خروجی؛ کاربر می‌تواند همان تکه را استفاده کند.
مثال: در سامانهٔ تیکت، اولین برش عمودی نباید «مدیریت کامل تیکت‌ها» باشد؛ می‌تواند این باشد که یک کاربر واقعی تیکت باز کند، ضمیمه بگذارد، و پشتیبان پاسخ دهد. برش بعدی می‌تواند اولویت‌بندی باشد و برش بعدی، گزارش. در همین مسیر است که تجربهٔ استفاده از اسپرینت و تیکت در یک محصول واقعی معنا پیدا می‌کند؛ نمونه‌ای از این ساختار در سامانهٔ تیکتینگ و مدیریت پروژه با اسپرینت دیده می‌شود، جایی که خود ابزار کار روزمرهٔ تیم است.
اگر تازه می‌خواهید حداقل مراسم لازم را بچینید و از چابک نمایشی دوری کنید، پیشنهاد می‌کنم مقالهٔ مدیریت پروژه نرم‌افزاری چابک؛ حداقلی که واقعاً کار می‌کند را در ادامهٔ همین بحث بخوانید.
«انجام‌شده» را قبل از شروع تعریف کنید
تعریف انجام‌شده (Definition of Done) توافقی است که مشخص می‌کند یک آیتم چه وقت واقعاً تمام است. اگر این تعریف مبهم بماند، هر کسی معیار خودش را دارد و کار در ستون «در حال انجام» می‌ماند. یک نمونهٔ ساده و کارآمد:
- رفتار مورد انتظار با یک آزمون خودکار یا سناریوی مشخص سنجیده شده است.
- کد روی محیط آزمایشی مستقر شده و از بیرون قابل استفاده است.
- لاگ و پایش حداقلی وجود دارد تا خرابی در محیط واقعی دیده شود.
- مالک محصول از دید کاربر نهایی تأیید کرده است، نه از دید فنی.
نکتهٔ مهم این است که «استقرار» بخشی از تعریف انجام باشد. اگر تحویل به تأخیر بیفتد، بازخورد هم دیر می‌آید و همهٔ مزیت چابک از دست می‌رود.
بازبینی، پنجرهٔ یادگیری است نه جلسهٔ گزارش
در بازبینی اسپرینت (Sprint Review) سؤال اصلی این نیست که «چه ساختیم؟»؛ این است که «چه چیزی یاد گرفتیم؟». سه سؤال کوتاه، جلسه را از گزارش‌دهی جدا می‌کند:
- کدام فرضیه آزموده شد و چه شاهدی گرفتیم؟
- چه چیزی خلاف انتظار بود؟ همان‌جا محل بازنگری است.
- تصمیم بعدی چیست: ادامه، تغییر مسیر، یا توقف؟
گاهی پاسخ درست، توقف یک قابلیت است. تیمی که نمی‌تواند بگوید «این را نسازیم»، در واقع چابک نیست؛ فقط سریع‌تر پیش می‌رود.
بدهی فنی را در همان increments ببینید
هر برش عمودی، مقداری بدهی فنی (Technical Debt) با خود می‌آورد؛ میان‌برهایی که برای رسیدن سریع‌تر به بازخورد گرفته‌اید. اگر این میان‌برها ثبت نشوند، در چند اسپرینت به دیوار می‌خورید. یک عادت ساده کافی است: هر میان‌بر را در همان بک‌لاگ با یک برچسب مشخص کنید و برای بازپرداختش سقف بگذارید. روش نگه‌داشتن این دفتر در مقالهٔ مدیریت بدهی فنی؛ دفتری برای بدهی‌هایی که بهره می‌گیرند توضیح داده شده است.
کجا چابک انتخاب درستی نیست
چابک برای همه‌جا پاسخ نیست. یک راهنمای تصمیم سریع:
- عدم‌قطعیت در «چه چیزی»: چابک بهترین گزینه است؛ چون می‌توانید فرض را با هزینهٔ کم بیازمایید.
- الزام ثابت و تغییرناپذیر: مانند قواعد محاسباتی یا الزامات قانونی؛ این بخش‌ها پیش‌طراحی دقیق‌تری می‌خواهند، اما می‌توانند در دل یک برنامهٔ تحویل تدریجی بمانند.
- وابستگی سخت به سامانه‌های بیرونی: پیش از شروع اسپرینت، دسترسی و قرارداد با طرف مقابل را روشن کنید؛ وگرنه تیم هر اسپرینت منتظر می‌ماند.
- تیم بسیار کوچک با دامنهٔ مبهم: پیش از هر چیز مالک محصول مشخص کنید؛ بدون آن، چابک به آشوب تبدیل می‌شود.
جمع‌بندی
چابک یک سیستم تصمیم‌گیری است که با برش‌های کوچک و بازخورد زودهنگام، هزینهٔ اشتباه را پایین می‌آورد. اگر بک‌لاگ را فهرست فرضیه‌ها بدانید، برش را عمودی بزنید، «انجام‌شده» را از پیش تعریف کنید و در بازبینی دنبال شاهد بگردید، مراسم‌ها خودشان معنا پیدا می‌کنند؛ در غیر این صورت، فقط جلسه‌های بیشتری به تیم اضافه کرده‌اید.
