اسکرام یا کانبان؟ راهنمای انتخاب روش کار برای تیم شما

بحث «اسکرام بهتر است یا کانبان» معمولاً در تیم‌هایی شروع می‌شود که کارشان خوب پیش نمی‌رود. یک نفر کتابی خوانده یا در شرکت قبلی‌اش اسکرام دیده، نفر دیگری می‌گوید جلسه‌ها وقت‌کش‌اند و «ما فقط یک تابلو لازم داریم». چند هفته بعد تیم اسم روشش را عوض کرده، ولی همان مشکل‌ها سر جایشان مانده‌اند: کار نیمه‌تمام زیاد، اولویت‌هایی که هر روز عوض می‌شوند، و تاریخ‌هایی که کسی به آن‌ها باور ندارد.

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

دو روش، دو پرسش متفاوت

ساده‌ترین راه فهم تفاوت این است که ببینیم هر روش به چه پرسشی جواب می‌دهد.

اسکرام می‌پرسد: «در یک بازهٔ زمانی ثابت و کوتاه، چه چیز ارزشمندی می‌توانیم تحویل بدهیم و بعد از آن چه یاد گرفتیم؟» اسکرام زمان را تکه‌تکه می‌کند. هر تکه یک اسپرینت است با هدف مشخص، و در پایانش تیم نتیجه را نشان می‌دهد و روش کارش را بازبینی می‌کند.

کانبان می‌پرسد: «کار چطور از ورود تا تحویل جریان پیدا می‌کند و کجا گیر می‌کند؟» کانبان زمان را تکه نمی‌کند؛ جریان را قابل‌دیدن می‌کند، مقدار کار هم‌زمان را محدود می‌کند و با اندازه‌گیری، گلوگاه‌ها را پیدا می‌کند.

هر دو از یک ریشه می‌آیند: ارزش‌های بیانیهٔ چابک، یعنی تحویل مکرر، بازخورد زود و بهبود پیوسته. تفاوت در ساختاری است که برای رسیدن به این‌ها پیشنهاد می‌کنند. اسکرام چارچوبی با نقش‌ها و رویدادهای معین است؛ کانبان روشی است که روی فرایند فعلی شما سوار می‌شود و آن را قدم‌به‌قدم بهتر می‌کند.

اسکرام در یک نگاه

راهنمای رسمی اسکرام متن کوتاهی است و ارزش دارد یک بار کامل خوانده شود، چون بسیاری از چیزهایی که به اسم اسکرام اجرا می‌شوند در آن نیست. خلاصهٔ آنچه واقعاً در آن آمده:

سه مسئولیت

• مالک محصول: صاحب فهرست کارهای محصول و ترتیب آن است. تصمیم «اول چه بسازیم» با اوست.
• اسکرام‌مستر: مسئول این است که تیم اسکرام را درست بفهمد و به کار ببرد و موانع را بردارد. مدیر پروژه یا منشی جلسه نیست.
• توسعه‌دهندگان: کسانی که در هر اسپرینت بخش قابل‌استفاده‌ای از محصول را می‌سازند؛ برنامه‌نویس، تستر، طراح، هر کسی که در ساختن سهم دارد.

پنج رویداد

• اسپرینت: بازه‌ای ثابت، یک ماه یا کمتر، که همهٔ رویدادهای دیگر داخل آن اتفاق می‌افتند.
• برنامه‌ریزی اسپرینت: تیم هدف اسپرینت را تعیین می‌کند و کارهایی را که برای رسیدن به آن لازم است انتخاب می‌کند.
• جلسهٔ روزانه: پانزده دقیقه برای بازبینی پیشرفت به سمت هدف اسپرینت و تنظیم برنامهٔ روز.
• بازبینی اسپرینت: نتیجه به ذی‌نفعان نشان داده می‌شود و دربارهٔ قدم بعد بحث می‌شود.
• بازنگری اسپرینت (Retrospective): تیم به روش کار خودش نگاه می‌کند و یکی دو بهبود مشخص انتخاب می‌کند.

سه مصنوع و تعهدشان

فهرست کارهای محصول (با «هدف محصول»)، فهرست کارهای اسپرینت (با «هدف اسپرینت») و نمو محصول (با «تعریف انجام‌شده» یا Definition of Done). نکتهٔ مهمی که اغلب فراموش می‌شود: کاری که به تعریف انجام‌شده نرسیده، جزو نمو نیست. «تقریباً تمام» در اسکرام وجود ندارد.

اسکرام دربارهٔ تابلو، استوری‌پوینت، نمودار برن‌داون یا ابزار خاصی چیزی نمی‌گوید. این‌ها روش‌هایی هستند که تیم‌ها کنار اسکرام به کار می‌برند. اگر تیمی می‌گوید «اسکرام یعنی تخمین با استوری‌پوینت»، دارد دربارهٔ یک عادت حرف می‌زند، نه خود چارچوب. جزئیات عملی برنامه‌ریزی را در راهنمای جامع برنامه‌ریزی اسپرینت باز کرده‌ام.

کانبان در یک نگاه

کانبان در نرم‌افزار از سیستم‌های تولید کششی آمده، ولی امروز دو متن مرجع اصلی دارد که در فهرست منابع آمده‌اند. هستهٔ مشترکشان این است:

1. جریان کار را تعریف و قابل‌دیدن کنید. مراحل واقعی کار، از «درخواست رسید» تا «به دست کاربر رسید»، روی تابلو ستون می‌شوند. ستون‌ها باید مراحل واقعی باشند، نه آرزوها.
2. کار در جریان را محدود کنید. هر مرحله سقفی دارد. تا کاری از آن مرحله بیرون نرود، کار تازه‌ای وارد نمی‌شود. این قاعده است که تابلو را از یک فهرست رنگی به یک سیستم تبدیل می‌کند.
3. کارها را فعالانه مدیریت کنید. کارت‌هایی که بیش از حد در یک ستون مانده‌اند پیدا می‌شوند و تیم برای آن‌ها کاری می‌کند، نه اینکه منتظر بماند.
4. با اندازه‌گیری بهبود بدهید. چهار سنجهٔ پایه: تعداد کار در جریان، توان عملیاتی (چند کار در هفته تمام می‌شود)، سن کار (یک کارت باز چند روز است که در جریان است) و زمان چرخه (از شروع تا پایان چقدر طول کشید).

کانبان نقش جدید، جلسهٔ اجباری یا اسپرینت ندارد. از همان کاری که امروز می‌کنید شروع می‌کند و از شما نمی‌خواهد ساختار تیم را عوض کنید. همین هم نقطهٔ قوت آن است و هم خطرش: تیمی که فقط ستون‌ها را می‌کشد و سقف کار و اندازه‌گیری را کنار می‌گذارد، کانبان ندارد؛ یک فهرست کار دارد. برای جزئیات طراحی تابلو، راهنمای جامع کانبان را ببینید.

مقایسهٔ کنار هم

جدول را این‌طور بخوانید: هیچ ستونی «برنده» نیست. هر ردیف یک مبادله است. اسکرام با بستن درِ کارهای تازه در طول اسپرینت، تمرکز می‌خرد و بهایش انعطاف کمتر است. کانبان انعطاف می‌دهد و بهایش این است که اگر انضباط سقف کار را نداشته باشید، تمرکز را از دست می‌دهید.

کدام برای کدام تیم

به‌جای قاعدهٔ کلی، چند وضعیت آشنا را مرور می‌کنم.

تیم محصول با نسخه‌های منظم

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

تیم پشتیبانی یا عملیات

اگر بیشتر کار تیم درخواست‌هایی است که از بیرون می‌رسند و نمی‌شود دو هفته منتظرشان گذاشت (رفع خطای مشتری، درخواست دسترسی، تغییرات زیرساخت)، اسپرینت بیشتر مزاحم است تا کمک. کانبان با کلاس‌های خدمت (مثلاً «فوری» با یک خط جداگانه روی تابلو) این واقعیت را بهتر نشان می‌دهد.

شرکت خدماتی با پروژه‌های مشتری

در شرکت‌های خدماتی ایرانی، الگوی رایجی دیده‌ام: هر پروژه نسخه‌هایی دارد که باید به محیط آزمون مشتری برسند، مشتری چند روز تست پذیرش می‌کند و بعد نسخه روی سرور اصلی می‌رود. این کار ذاتاً «نسخه‌محور» است، ولی کارهای پشتیبانی پروژه‌های قبلی هم هم‌زمان می‌رسند. اینجا ترکیب جواب می‌دهد: تابلوی کانبان پیوسته برای جریان کار، به‌علاوهٔ ستون‌هایی که هر کدام یک نسخه با تاریخ‌های مشخص است. دربارهٔ اهمیت ثبت تاریخ ورود به آزمون پذیرش در مقالهٔ UAT نوشته‌ام.

تیم کوچک سه‌چهارنفره

اسکرام کامل برای سه نفر سنگین است؛ یک نفر هم مالک محصول است، هم اسکرام‌مستر، هم برنامه‌نویس. معمولاً کانبان با یک جلسهٔ کوتاه هفتگی برای اولویت‌بندی و یک بازنگری ماهانه کافی است. اگر هم ریتم انتشار لازم دارید، یک اسپرینت سبک بدون تشریفات کامل اشکالی ندارد؛ فقط اسمش را اسکرام نگذارید تا انتظار غلط ساخته نشود.

تیمی که هنوز نمی‌داند کارش چه شکلی است

تیم تازه‌تأسیس یا تیمی که مسئولیت تازه‌ای گرفته، اول باید بداند چه کاری، با چه حجمی و از کجا می‌رسد. کانبان با کمترین تغییر این را آشکار می‌کند. بعد از یکی دو ماه، با داده در دست، می‌شود دربارهٔ اسپرینت تصمیم گرفت.

هفت پرسش برای تصمیم

این پرسش‌ها را در یک جلسهٔ یک‌ساعته با تیم مرور کنید و جواب‌ها را بنویسید:

1. چه درصدی از کار هفتهٔ گذشته از قبل برنامه‌ریزی شده بود و چه درصدی ناگهانی رسید؟ (تخمین تقریبی کافی است.)
2. آیا ذی‌نفعان به تاریخ‌های ثابت تحویل نیاز دارند، یا به زمان پاسخ کوتاه به هر درخواست؟
3. آیا کسی هست که بتواند و بخواهد نقش مالک محصول را واقعاً بازی کند و دربارهٔ ترتیب کارها تصمیم بگیرد؟
4. کارها تقریباً هم‌اندازه‌اند یا از یک ساعت تا یک ماه پراکنده‌اند؟
5. آیا تیم فرصت جلسه‌های منظم دارد، یا هر جلسهٔ تازه با مقاومت روبه‌رو می‌شود؟
6. بزرگ‌ترین شکایت امروز چیست: «نمی‌دانیم کی تمام می‌شود» یا «همه‌چیز نیمه‌کاره است»؟
7. آیا انتشار نسخه به مراحل بیرونی وابسته است، مثل آزمون پذیرش مشتری یا پنجرهٔ زمانی استقرار؟

اگر بیشتر جواب‌ها به سمت «کار برنامه‌ریزی‌شده، تاریخ ثابت، مالک محصول در دسترس» رفت، اسکرام را امتحان کنید. اگر به سمت «کار ناگهانی، زمان پاسخ، کارهای ناهم‌اندازه» رفت، کانبان. اگر مخلوط بود، که اغلب هست، بخش بعد برای شماست.

ترکیب‌ها: اسکرام‌بان و «کانبان با نسخه»

اسکرام‌بان اسمی است که برای ترکیب این دو جا افتاده: تیم ریتم برنامه‌ریزی و بازنگری اسکرام را نگه می‌دارد، ولی داخل آن ریتم با تابلوی کانبان و سقف کار جریان را مدیریت می‌کند. برنامه‌ریزی وقتی انجام می‌شود که صف «آمادهٔ شروع» از حدی کمتر شود، نه لزوماً سر هر دو هفته.

یک الگوی دیگر که در تیم‌های نسخه‌محور خوب جواب داده، چیزی است که من «کانبان با نسخه» می‌نامم:

فهرست کارها | آماده | در حال توسعه (سقف 4) | بازبینی کد (سقف 2) | نسخهٔ v2.4 | نسخهٔ v2.5

کارها مثل کانبان جریان دارند، ولی وقتی کاری تمام شد، به ستونی می‌رود که نمایندهٔ یک نسخه است. آن ستون تاریخ شروع و پایان توسعه، ورود به آزمون پذیرش و انتشار دارد. این‌طوری هم جریان پیوسته دارید و هم کسی که می‌پرسد «این کار در کدام نسخه می‌آید و آن نسخه کی لایو می‌شود» جواب روشنی می‌گیرد. در بردماگ هر ستون را می‌شود به‌عنوان اسپرینت علامت زد و برایش نام نسخه و تاریخ برنامه‌ای و واقعی این چهار مرحله را ثبت کرد؛ سرستون وضعیت، روزهای باقی‌مانده و تأخیر را نشان می‌دهد.

هشدار: ترکیب وقتی جواب می‌دهد که هر دو بخش را جدی بگیرید. «اسکرام‌بان» نباید بهانه‌ای باشد برای حذف بازنگری از اسکرام و حذف سقف کار از کانبان؛ آنچه باقی می‌ماند هیچ‌کدام نیست.

اشتباه‌های رایج در هر دو

در اسکرام

• اسپرینت به‌عنوان ددلاین فشار. اگر هر اسپرینت با شب‌کاری تمام می‌شود، تیم دارد بیش از ظرفیت تعهد می‌دهد. چاره، تعهد کمتر است، نه اسپرینت کوتاه‌تر.
• تغییر محتوای اسپرینت هر روز. اگر اولویت‌ها واقعاً هر روز عوض می‌شوند، اسکرام مناسب کار شما نیست. یا اسپرینت را کوتاه کنید یا به کانبان بروید؛ هر دو صادقانه‌تر از تظاهر به اسپرینت‌اند.
• جلسهٔ روزانه به‌عنوان گزارش به مدیر. جلسهٔ روزانه برای هماهنگی خود تیم است. اگر همه رو به مدیر حرف می‌زنند، جلسه کارکردش را از دست داده. راهکارهای عملی‌اش را در مقالهٔ استندآپ پای تابلو آورده‌ام.
• حذف بازنگری چون «وقت نداریم». بازنگری تنها جایی است که خود روش بهتر می‌شود. حذفش یعنی تیم همان اشتباه‌ها را تکرار می‌کند.

در کانبان

• تابلو بدون سقف کار. رایج‌ترین اشتباه. ستون «در حال انجام» با بیست کارت یعنی هیچ‌چیز در حال انجام نیست. چرایی و روش تعیین سقف را در مقالهٔ محدودیت کار در جریان نوشته‌ام.
• «کانبان یعنی برنامه‌ریزی نداریم». کانبان برنامه‌ریزی دارد، فقط ریتمش جدا از تحویل است. کسی باید مرتب صف «آماده» را مرتب و اولویت‌بندی کند.
• ستون‌هایی که مرحلهٔ واقعی نیستند. ستونی به اسم «علی» یا «هفتهٔ بعد» مرحلهٔ کار نیست. ستون باید بگوید کار در چه وضعیتی است.
• بدون اندازه‌گیری. بدون دانستن زمان چرخه، نه می‌توانید بهبود را ثابت کنید و نه تاریخ قابل‌دفاع بدهید.

آزمایش چهارهفته‌ای: از دوشنبه شروع کنید

به‌جای بحث بیشتر، یک آزمایش محدود و قابل‌اندازه‌گیری طراحی کنید.

هفتهٔ صفر (همین هفته): وضعیت فعلی را ثبت کنید. چند کار باز داریم؟ در دو هفتهٔ گذشته چند کار تمام شد؟ میانگین تقریبی زمان از شروع تا پایان چقدر بود؟ این اعداد را جایی بنویسید که بعداً پیدایشان کنید.

هفتهٔ اول: روش انتخابی را با حداقل ساختار شروع کنید. اگر اسکرام است: یک اسپرینت دوهفته‌ای با یک هدف یک‌جمله‌ای، برنامه‌ریزی، جلسهٔ روزانهٔ پانزده‌دقیقه‌ای. اگر کانبان است: ستون‌های واقعی، سقف کار برای ستون‌های میانی (برای شروع، تعداد نفرات منهای یک)، و قاعدهٔ «اول تمام کن، بعد شروع کن».

هفتهٔ دوم: قاعده‌ها را نگه دارید، حتی وقتی ناخوشایندند. آن ناخوشایندی معمولاً همان مشکل واقعی است که تا حالا پنهان بوده. یادداشت کنید کجا قاعده شکسته شد و چرا.

هفتهٔ سوم: یک بازنگری کوتاه. سه پرسش: چه چیزی بهتر شد؟ چه چیزی بدتر شد؟ یک تغییر برای دو هفتهٔ بعد چیست؟

هفتهٔ چهارم: اعداد را با هفتهٔ صفر مقایسه کنید. کار باز کمتر شد؟ زمان چرخه کوتاه‌تر شد؟ تیم احساس تمرکز بیشتری دارد؟ تصمیم بگیرید: ادامه، تنظیم، یا امتحان روش دیگر.

این آزمایش وقتی ارزش دارد که اعداد هفتهٔ صفر را واقعاً ثبت کرده باشید. بدون آن، چهار هفته بعد دوباره به بحث سلیقه‌ای برمی‌گردید.

نقش ابزار در این تصمیم

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

و یک نکتهٔ انسانی: هر روشی که انتخاب کنید، اگر تیم دلیلش را نفهمد، به تشریفات تبدیل می‌شود. وقت گذاشتن برای توضیح «چرا»، مهم‌تر از جزئیات «چطور» است. دربارهٔ اینکه چطور هماهنگی تیم با جلسهٔ کمتر ممکن است، راهنمای همکاری در تیم نرم‌افزاری را ببینید.

جمع‌بندی

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

انتخاب را با داده بکنید، نه با سلیقه: وضعیت امروز را ثبت کنید، چهار هفته روش را جدی امتحان کنید و بعد مقایسه کنید. روشی که تیم با دلیل انتخاب کرده و می‌تواند بهبودش را اندازه بگیرد، تقریباً همیشه از روشی که از روی کتاب کپی شده بهتر کار می‌کند.

منابع و مطالعهٔ بیشتر

• The Scrum Guide — متن رسمی و کوتاه چارچوب اسکرام از نویسندگان آن؛ مرجع نقش‌ها، رویدادها و مصنوعات.
• The Kanban Guide — تعریف فشردهٔ کانبان، سه روش اصلی و چهار سنجهٔ جریان.
• Kanban University: The Official Kanban Guide — نگاه «روش کانبان» با اصول تغییر تدریجی و کلاس‌های خدمت.
• Scrumban — Wikipedia — پیشینه و شکل‌های رایج ترکیب اسکرام و کانبان.