کانبان — وقتی اسکرام زیادی "ساختاریافته" است
اگر اسکرام را یک "قطار برنامهریزیشده" تصور کنید که در بازههای زمانی ثابت (اسپرینتها) حرکت میکند، کانبان (Kanban) یک "جریان آزاد" است که کارها در آن به صورت پیوسته و بدون بازه زمانی مشخص انجام میشوند. کانبان که ریشه در سیستم تولید تویوتا (TPS) در دهه ۱۹۴۰ دارد، یک روش مدیریت جریان کار (Flow Management) است که بر تصویرسازی کار، محدود کردن کار در جریان (WIP) و بهبود مستمر تأکید دارد. برخلاف اسکرام که نقشها و رویدادهای مشخصی دارد، کانبان بسیار انعطافپذیر و کمتشریفات است. در این مقاله، کانبان را از پایه آموزش میدهیم و آن را با اسکرام مقایسه میکنیم تا بدانید کدام برای تیم شما مناسبتر است.
تاریخچه جذاب کانبان — از کارخانه تویوتا تا تیمهای نرمافزاری
داستان کانبان از دهه ۱۹۴۰ در ژاپن شروع میشود. تایچی اونو (Taiichi Ohno) مهندس ارشد تویوتا، به دنبال راهی برای کاهش انبارداری و افزایش بهرهوری بود. او از سوپرمارکتهای آمریکایی الهام گرفت: در سوپرمارکت، قفسهها فقط به اندازه نیاز مشتریان پر میشوند — نه بیشتر، نه کمتر. اونو سیستمی طراحی کرد که در آن هر ایستگاه کاری فقط وقتی قطعهای را مصرف میکرد، یک "کارت سیگنال" (به ژاپنی: Kanban) به ایستگاه قبلی میفرستاد تا قطعه جدید بسازد. این سیستم Just-In-Time (JIT) تولید را متحول کرد: انبارها کوچک شدند، هزینهها کاهش یافتند، و کیفیت افزایش پیدا کرد. در سال ۲۰۰۷، دیوید اندرسون این مفاهیم را برای مدیریت کار دانشی (نرمافزار، بازاریابی، طراحی) تطبیق داد و "روش کانبان" (Kanban Method) را معرفی کرد.
اصول ششگانه کانبان
- با کاری که الان انجام میدهید شروع کنید: نیازی به تغییر ساختار سازمانی یا تعریف نقشهای جدید نیست. کانبان را به فرآیند موجود خود اضافه کنید.
- بهبود تدریجی و تکاملی را دنبال کنید: تغییرات کوچک، مستمر و کمریسک. نه انقلاب! هر هفته یک بهبود کوچک.
- فرآیندها، نقشها و مسئولیتهای فعلی را محترم بشمارید: نقشهای موجود ارزشمندند. آنها را حفظ کنید مگر اینکه دلیل قانعکنندهای برای تغییر باشد.
- رهبری را در تمام سطوح تشویق کنید: همه اعضای تیم میتوانند رهبر بهبود باشند، نه فقط مدیران.
- جریان کار را تصویرسازی کنید (Visualize): برد کانبان قلب سیستم است. همه باید ببینند کارها کجا هستند.
- WIP را محدود کنید (Limit WIP): مهمترین اصل کانبان. هر ستون حداکثر چند کار میتواند همزمان داشته باشد.
برد کانبان (Kanban Board) — قلب سیستم
سادهترین برد کانبان سه ستون دارد: To Do (برای انجام)، In Progress (در حال انجام)، Done (انجام شده). اما در عمل، برد کانبان متناسب با فرآیند تیم شخصیسازی میشود. مثال برای تیم نرمافزاری: Backlog → Ready for Dev → In Development → Code Review → Ready for QA → In Testing → Ready for Release → Done. هر ستون یک WIP Limit (محدودیت کار در جریان) دارد. مثلاً: In Development = ۳ (حداکثر ۳ کار همزمان). اگر این ستون پر باشد، نمیتوان کار جدیدی شروع کرد — باید اول یک کار تمام شود تا جا باز شود. این محدودیت WIP هسته اصلی کانبان است و از چندوظیفهای (Multi-tasking) که بهرهوری را کاهش میدهد، جلوگیری میکند.
WIP Limit — چرا باید کار در جریان را محدود کنید؟
تحقیقات نشان میدهد که چندوظیفهای (Multi-tasking) باعث کاهش ۲۰-۴۰٪ بهرهوری میشود. هر بار که بین کارها سوئیچ میکنید، مغز شما نیاز به "context switching" دارد که زمان و انرژی مصرف میکند. WIP Limit شما را مجبور میکند قبل از شروع کار جدید، کارهای نیمهتمام را تمام کنید. این مفهوم به "Stop Starting, Start Finishing" معروف است. مزایای WIP Limit: کاهش زمان Cycle Time (مدت زمان از شروع تا پایان یک کار)، افزایش کیفیت (تمرکز بیشتر روی کارهای کمتر)، شناسایی سریعتر گلوگاهها (اگر ستونی پر شود، یعنی گلوگاه آنجاست)، کاهش استرس تیم (به جای ۱۰ کار نیمهتمام، روی ۲-۳ کار تمرکز کنید).
متریکهای کانبان — اندازهگیری جریان کار
- Lead Time: کل زمان از لحظه ثبت درخواست تا تحویل نهایی. این معیار از دید مشتری است.
- Cycle Time: زمان از لحظه شروع کار روی یک آیتم تا اتمام آن. این معیار از دید تیم است.
- Throughput: تعداد آیتمهای تکمیلشده در یک بازه زمانی (مثلاً ۱۵ آیتم در هفته).
- Cumulative Flow Diagram (CFD): یک نمودار قدرتمند که وضعیت جریان کار را نشان میدهد. میتوانید ببینید آیا کارها در یک ستون انباشته شدهاند (گلوگاه) و میانگین Cycle Time چقدر است.
- قانون لیتل (Little''s Law): Cycle Time = WIP / Throughput. اگر WIP را نصف کنید و Throughput ثابت بماند، Cycle Time نصف میشود!
مقایسه کانبان و اسکرام — کدام برای شما مناسبتر است؟
| معیار | کانبان | اسکرام |
|---|---|---|
| بازه زمانی | جریان پیوسته (بدون اسپرینت) | اسپرینتهای ثابت (۲-۴ هفته) |
| نقشها | بدون نقش اجباری | PO، SM، Developers (اجباری) |
| تغییر در اولویتها | در هر لحظه ممکن است | فقط بین اسپرینتها |
| محدودیت کار | WIP Limit (تعداد) | Sprint Capacity (زمان) |
| جلسات | حداقل (فقط Daily و Replenishment) | چهار جلسه اجباری |
| تخمین | اختیاری (بدون Story Points) | اجباری (Story Points یا ساعت) |
| مناسب برای | کارهای مستمر و پشتیبانی | پروژههای با شروع و پایان مشخص |
| انعطافپذیری | بسیار بالا | متوسط |
| یادگیری | آسان (فقط مفهوم WIP) | متوسط (رولها و رویدادها) |
چه زمانی کانبان بهتر از اسکرام است؟
- تیم شما کارهای مستمر و بدون پایان مشخص انجام میدهد (مثلاً تیم پشتیبانی، DevOps، یا نگهداری).
- اولویتها دائماً تغییر میکنند و نمیتوانید برای ۲-۴ هفته برنامه ثابت داشته باشید.
- تیم شما در برابر تشریفات مقاوم است و نمیخواهد نقشهای جدید (SM, PO) تعریف کند.
- میخواهید بهبود تدریجی داشته باشید، نه یک تغییر اساسی ناگهانی.
آیا میتوان اسکرام و کانبان را ترکیب کرد؟ — Scrumban
بله! Scrumban یک روش هیبریدی است که بهترینهای هر دو را ترکیب میکند: اسپرینتهای اسکرام (اما کوتاهتر، مثلاً ۱ هفته)، WIP Limit های کانبان، بدون تخمین Story Points اجباری، بدون رولهای سفت و سخت اسکرام، تمرکز بر Flow مانند کانبان. Scrumban برای تیمهایی که از اسکرام به کانبان مهاجرت میکنند (یا برعکس) عالی است و یک گام میانی محسوب میشود.
جمعبندی
انتخاب بین اسکرام و کانبان به ماهیت کار تیم شما بستگی دارد. اگر پروژههای با شروع و پایان مشخص (مثل ساخت یک محصول جدید) دارید، اسکرام انتخاب بهتری است. اگر کارهای مستمر و جاری (مثل پشتیبانی، رفع باگ، نگهداری) انجام میدهید، کانبان مناسبتر است. نکته کلیدی: هیچکدام "بهتر" نیستند — هر کدام برای شرایط خاصی طراحی شدهاند. و فراموش نکنید: چه اسکرام چه کانبان، هر دو در نهایت به یک هدف میرسند: ارائه ارزش مستمر به مشتری با کیفیت بالا.