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

راهنمای جامع کانبان: از تابلوی ساده تا جریان کار قابل پیش‌بینی
در این مقاله می‌خوانید
  1. کانبان چیست و چه چیزی نیست
  2. تابلو را از روی کار واقعی بکشید، نه از روی قالب
  3. ستون یعنی مرحله، نه آدم
  4. یک چیدمان نمونه برای تیم نرم‌افزاری
  5. صف‌ها را جدا از کار فعال نشان دهید
  6. کارهای مسدود را علامت بزنید، جابه‌جا نکنید
  7. انواع کار را با برچسب جدا کنید، نه با تابلوهای موازی
  8. کارت: واحد کار را درست تعریف کنید
  9. محدودیت کار در جریان: قلب کانبان
  10. سیاست‌های صریح: قانون هر ستون را بنویسید
  11. اندازه‌گیری جریان: چهار عدد کافی است
  12. سن کار؛ سنجه‌ای که هر روز به کار می‌آید
  13. از میانگین به پیش‌بینی
  14. حلقه‌های بازخورد: چند جلسهٔ کوتاه، نه جلسه‌های بیشتر
  15. کانبان در کنار اسپرینت و نسخه
  16. تابلوی فارسی: راست‌به‌چپ را جدی بگیرید
  17. خطاهای رایج در شروع کانبان
  18. برنامهٔ یک‌هفته‌ای برای شروع
  19. جمع‌بندی
  20. منابع و مطالعهٔ بیشتر

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

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

کانبان چیست و چه چیزی نیست

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

دو منبع اصلی امروز کانبان را کمی متفاوت توضیح می‌دهند. «روش کانبان» که Kanban University نگهداری‌اش می‌کند، بر شروع از وضع موجود، تغییر تدریجی و چند رویهٔ عمومی تأکید دارد: دیداری کردن کار، محدود کردن کار در جریان، مدیریت جریان، صریح کردن سیاست‌ها، حلقه‌های بازخورد و بهبود مشارکتی. «راهنمای کانبان» (The Kanban Guide) کوتاه‌تر است و روی سه چیز تمرکز می‌کند: تعریف جریان کار، کنترل کار در جریان و اندازه‌گیری جریان. هر دو را در فهرست منابع آورده‌ام؛ تفاوت‌شان بیشتر در تأکید است تا در اصل.

آنچه کانبان نیست:

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

اگر هنوز مطمئن نیستید کانبان برای تیم شما مناسب‌تر است یا چارچوبی با اسپرینت‌های ثابت، پیش از ادامه نگاهی به مقایسهٔ اسکرام و کانبان بیندازید. بیشتر آنچه در ادامه می‌آید، در هر دو حالت به کار می‌آید.

تابلو را از روی کار واقعی بکشید، نه از روی قالب

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

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

ستون یعنی مرحله، نه آدم

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

یک چیدمان نمونه برای تیم نرم‌افزاری

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

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

صف‌ها را جدا از کار فعال نشان دهید

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

کارهای مسدود را علامت بزنید، جابه‌جا نکنید

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

انواع کار را با برچسب جدا کنید، نه با تابلوهای موازی

باگ فوری، قابلیت تازه و کار فنی (مثل به‌روزرسانی کتابخانه‌ها) از یک مسیر رد می‌شوند ولی سرعت و فوریت‌شان فرق دارد. به‌جای سه تابلوی جدا که هیچ‌کس هر سه را نگاه نمی‌کند، روی یک تابلو بمانید و نوع کار را با برچسب نشان دهید. بعدها همین برچسب‌ها کمک می‌کنند زمان چرخه را برای هر نوع کار جدا ببینید.

کارت: واحد کار را درست تعریف کنید

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

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

یک نمونه:

عنوان: خروجی اکسل از گزارش فروش ماهانه

چرا: واحد مالی هر ماه این گزارش را دستی از صفحه کپی می‌کند و ستون‌ها به هم می‌ریزد.

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

خارج از دامنه: خروجی PDF (کارت جداگانه).

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

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

محدودیت کار در جریان: قلب کانبان

اگر فقط یک کار از این راهنما انجام می‌دهید، همین باشد. محدودیت کار در جریان (WIP Limit) یعنی برای هر ستون فعال، حداکثر تعداد کارتی را تعیین کنید که هم‌زمان می‌تواند در آن باشد. وقتی ستون پر است، کسی کار تازه شروع نمی‌کند؛ اول کمک می‌کند کاری از همان ستون یا ستون بعدی جلو برود.

چرا این‌قدر مهم است؟ چون شروع کردن ارزان است و تمام کردن گران. تیمی که هر کدام از اعضایش سه چهار کار نیمه‌کاره دارد، مدام بین آن‌ها جابه‌جا می‌شود، هر جابه‌جایی هزینهٔ تمرکز دارد، و هیچ کاری زود به دست کاربر نمی‌رسد. محدودیت، تیم را از «بیا شروع کنیم» به «بیا تمامش کنیم» می‌برد.

رابطهٔ پشت این حرف را قانون لیتل (Little’s Law) بیان می‌کند. در یک سیستم نسبتاً پایدار:

average cycle time = average WIP / average throughput

فرض کنید تیمی پنج‌نفره به‌طور متوسط ۲۰ کار باز دارد و هفته‌ای ۵ کار تمام می‌کند. زمان چرخهٔ متوسط حدود ۴ هفته است. اگر همین تیم، با همان سرعت تحویل، کار باز را به ۱۰ برساند، زمان چرخه به حدود ۲ هفته می‌رسد. هیچ‌کس سریع‌تر کار نکرده؛ فقط کار کمتری هم‌زمان باز است. این رابطه برای میانگین‌ها و در شرایط پایدار برقرار است؛ ابزار فکر کردن است، نه فرمول پیش‌بینی دقیق.

برای شروع، عدد محدودیت را از تعداد آدم‌ها بگیرید: اگر سه توسعه‌دهنده دارید، محدودیت «در حال توسعه» را ۳ یا ۴ بگذارید. برای ستون‌های انتظار هم عددی بگذارید؛ صفی که سقف ندارد، فقط جای انباشتن مشکل است. دو هفته صبر کنید و ببینید کارت‌ها کجا جمع می‌شوند. عدد درست را تجربه پیدا می‌کند، نه فرمول.

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

سیاست‌های صریح: قانون هر ستون را بنویسید

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

برای هر ستون یک «شرط خروج» بنویسید و جایی بگذارید که همه ببینند؛ مثلاً در شرح یک کارت ثابت بالای ستون:

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

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

اندازه‌گیری جریان: چهار عدد کافی است

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

سنجه تعریف به چه پرسشی جواب می‌دهد
کار در جریان تعداد کارت‌هایی که شروع شده‌اند و هنوز تمام نشده‌اند چقدر کار باز داریم؟
توان تحویل (Throughput) تعداد کارهای تمام‌شده در هر بازهٔ زمانی هفته‌ای چند کار تحویل می‌دهیم؟
زمان چرخه (Cycle Time) فاصلهٔ شروع واقعی تا پایان واقعی یک کار یک کار معمولاً چقدر طول می‌کشد؟
سن کار (Work Item Age) مدتی که یک کار باز از شروعش گذرانده کدام کار دارد گیر می‌کند؟

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

سن کار؛ سنجه‌ای که هر روز به کار می‌آید

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

از میانگین به پیش‌بینی

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

نمودار جریان تجمعی (Cumulative Flow Diagram) همین داده را در طول زمان نشان می‌دهد: برای هر روز، تعداد کارت‌های هر ستون روی هم انباشته می‌شود. اگر نوار یک ستون مدام پهن‌تر می‌شود، آنجا گلوگاه است. اگر همهٔ نوارها موازی بالا می‌روند، جریان پایدار است. حتی اگر ابزارتان این نمودار را نمی‌کشد، شمردن هفتگی کارت‌های هر ستون در یک جدول ساده همان تصویر را می‌دهد.

حلقه‌های بازخورد: چند جلسهٔ کوتاه، نه جلسه‌های بیشتر

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

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

شیوهٔ برگزاری جلسهٔ روزانه را، طوری که به گزارش‌دهی تبدیل نشود، در استندآپ پای تابلو جداگانه نوشته‌ام.

کانبان در کنار اسپرینت و نسخه

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

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

تابلوی فارسی: راست‌به‌چپ را جدی بگیرید

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

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

خطاهای رایج در شروع کانبان

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

برنامهٔ یک‌هفته‌ای برای شروع

اگر می‌خواهید از همین هفته شروع کنید، این ترتیب را پیشنهاد می‌کنم:

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

یک ماه بعد، اولین مرور جریان را برگزار کنید. احتمالاً می‌بینید بیشترین انباشت در یکی از ستون‌های انتظار است، نه در ستون توسعه. این کشف، به‌تنهایی، ارزش کل کار را دارد.

جمع‌بندی

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

هیچ‌کدام از این‌ها به ابزار خاصی وابسته نیست. ابزار خوب فقط کمک می‌کند این عادت‌ها کم‌هزینه‌تر شوند.

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

کار تیم‌تان را روی BoardMug ببینید

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

درخواست دمو