فصل ۹ — Kanban: اصول و بهبود Process | Learning Agile

عنوان اصلی اثر

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

عنوان این مقاله

فصل ۹ — Kanban: اصول و بهبود Process

عنوان بخش منبع

Chapter 9: Kanban principles and process improvement

نویسندگان

Andrew Stellman و Jennifer Greene

زبان اصلی

English

صفحات منبع

335 تا 358 از PDF

حق‌نشر منبع

Copyright © 2015 O’Reilly Media, Inc. — All rights reserved.

تاریخ ترجمه

1405/05/20 / 2026-08-11

اعتبار ترجمه

ترجمه با کمک هوش مصنوعی

فروش یا انتشار این ترجمه منوط به داشتن مجوز لازم از صاحب حقوق اثر است.

فصل ۹ — Kanban: Flow و بهبود مداوم Process

«Kanban یک Software Development Lifecycle Methodology یا رویکرد Project Management نیست. لازم است Processی از قبل وجود داشته باشد تا Kanban روی آن اعمال شود و همان Process پایه را به‌صورت Incremental تغییر دهد.» — David Anderson، Kanban

Kanban روشی برای Process Improvement است که Teamهای Agile از آن استفاده می‌کنند. Team ابتدا می‌فهمد امروز Software را چگونه می‌سازد و سپس به مرور Process را بهتر می‌کند. مانند Scrum و XP، Kanban به Mindset نیاز دارد؛ Mindset موردنیاز آن Lean Thinking است. Team با Lean به Work فعلی نگاه می‌کند، Waste از جمله muda، mura و muri را پیدا می‌کند و Kanban ابزار عملی بهبود تدریجی System را فراهم می‌کند.

واژهٔ kanban از Manufacturing می‌آید و David Anderson آن را برای Software Development تطبیق داد. Anderson رابطهٔ Kanban با Lean را چنین توضیح می‌دهد: Kanban Method یک Complex Adaptive System معرفی می‌کند که قرار است در Organization نتیجه‌ای Lean را Catalyze کند. می‌توان بدون Kanban از Lean Thinking استفاده کرد، اما Kanban یکی از رایج‌ترین راه‌های واردکردن Mindset Lean به Software Organization است.

تمرکز Kanban با Scrum و XP فرق دارد:

• Scrum عمدتاً Project Management و Delivery را سازمان می‌دهد: چه Scopeی انجام می‌شود، چه زمانی Deliver می‌شود و Outcome تا چه حد نیاز User و Stakeholder را برآورده می‌کند.
• XP عمدتاً بر Software Development و Habitهای Programming متمرکز است: Environment مناسب Development و Code ساده و Changeable.
• Kanban روی بهبود روش ساخت Software تمرکز دارد؛ Actionها، Interaction با Company، محل‌های Waste و Root Causeهای Inefficiency را Visible می‌کند و Team را قادر می‌سازد Process را به مرور بهتر کند.

Kanban از Agile Ideaهایی مثل Last Responsible Moment برای Process Improvement استفاده می‌کند و Adoption آن برای Team نسبتاً مستقیم است.

Foundational Principles و Core Practices

نسخهٔ Core Practices که در منبع نقل شده ابتدا سه اصل پایه دارد:

1. Start with what you do now — با چیزی که همین حالا انجام می‌دهید شروع کنید.
2. Agree to pursue incremental, evolutionary change — روی Change تدریجی و Evolutionary توافق کنید.
3. Initially, respect current roles, responsibilities & job titles — در ابتدا Roleها، Responsibilityها و Job Titleهای فعلی را محترم بشمارید.

سپس Core Practiceها:

• Visualize
• Limit WIP
• Manage Flow
• Make Process Policies Explicit
• Implement Feedback Loops
• Improve Collaboratively, Evolve Experimentally با استفاده از Modelها و Scientific Method

قرار نیست Team از روز نخست هر شش Practice را با عمق کامل اجرا کند. Implementationهای Partial «Shallow» نامیده می‌شوند و انتظار می‌رود با Adoption Practiceهای بیشتر، عمق و Capability افزایش پیدا کند.

روایت: پردهٔ دوم — Playing Catch-Up

Catherine و Timothy از Dan خسته شده‌اند. Deadline و اهمیت Work را می‌فهمند و حتی Pressure روی Manager را می‌پذیرند، اما تقریباً هر Project کوچک به چیزی تبدیل می‌شود که Dan آن را Intensive Care Unit mode می‌نامد؛ یعنی مرحله‌ای که Micromanagement شدید شروع می‌شود.

Feature فعلی Camera App باید Face دوستان را به Posterهای قدیمی «Wanted» تبدیل کند و با Social Networking System شرکت مادر Integrate شود. Project ساده تصور شده بود، اما Testing چند Bug پیدا کرده و Deadline در خطر است.

Timothy می‌گوید اگر Dan فقط اجازه دهد Team کارش را انجام دهد احتمالاً Feature به موقع تمام می‌شود. ساعت از هفت شب گذشته و آن‌ها باید به Evening Status Meeting بروند. Dan می‌گوید «Crunch Time» است؛ اما چون Deadlineها دائماً در خطرند، تقریباً همیشه Crunch Time است.

در Meeting، Dan می‌گوید دست‌کم سه Project در ICU هستند و Team Catherine را متهم می‌کند Progress ندارد. وقتی آن‌ها Bug را توضیح می‌دهند، Dan می‌گوید «همیشه یک Bug هست» و خودش باید وارد شود چون Project «Urgency» کافی ندارد.

Catherine برای نخستین بار آشکارا مقابله می‌کند: Problemها تکراری‌اند. Agreement روی UI Change هفته‌ها طول می‌کشد، ولی Team در نیمهٔ Discussion مجبور به شروع Code می‌شود و بعد زمان زیادی صرف Rework می‌کند. QA هر بار Bug پیدا می‌کند، بااین‌حال Schedule هیچ‌وقت Fix Time کافی ندارد. Dan بحث Waste را «منفی» می‌بیند و می‌گوید نباید Blame کرد. Catherine توضیح می‌دهد هدف Blame نیست؛ این Problemها بارها با Pattern یکسان رخ می‌دهند و Team در Meetingهای دوباردرروز مثل Broken Record دربارهٔ همان چیزها حرف می‌زند.

Dan در نهایت باز هم می‌گوید این موضوع‌ها برای Project بعدی خوب‌اند؛ فعلاً فقط باید زمان و Urgency بیشتری صرف شود. این همان Patternی است که Kanban می‌خواهد از حالت «Habit نامرئی» به «System قابل مشاهده و قابل تغییر» تبدیل کند.

Principles of Kanban

Start with what you do now

این اصل با رویکرد Methodologyهایی مثل Scrum فرق دارد. Adoption Scrum Roleهای جدید مثل Scrum Master و Product Owner، Activityهایی مثل Sprint Planning و Daily Scrum و Toolهایی مثل Task Board ایجاد می‌کند، چون Scrum یک System برای Manage و Deliver کردن Project است.

Kanban Project Management System نیست. Methodی برای بهترکردن Process موجود است. بنابراین قبل از هر Improvement باید Starting Point واقعی را بشناسید: چیزی که امروز انجام می‌دهید.

Starting Point را پیدا کنید و Experimentally Evolution کنید

Problemهای Habitual دقیقاً به این دلیل خطرناک‌اند که در لحظهٔ وقوع «Mistake» به نظر نمی‌رسند. Team ممکن است بعداً Root-Cause Analysis انجام دهد، اما اگر Choice مشابه دوباره ظاهر شود، بدون تغییر System همان Decision را تکرار می‌کند.

مثال: Programming Team بارها Software را تحویل می‌دهد و Userها در Meeting می‌گویند Featureهایی را که فکر می‌کردند وعده داده شده پیدا نمی‌کنند. شاید Developerها Forgetful باشند، اما احتمال قوی‌تر این است که Requirement Gathering یا Communication Process مشکل تکرارشونده دارد. هدف Process Improvement پیدا کردن Recurring Problem، تشخیص وجه مشترک و ساخت Tool برای اصلاح آن است.

اگر فرض کنیم «Developer حافظه ندارد» یا «User همیشه نظرش را عوض می‌کند»، Problem را عملاً Unfixable اعلام کرده‌ایم. اگر فرض کنیم Root Cause تکرارشونده‌ای وجود دارد، می‌توان آن را پیدا و اصلاح کرد.

Kanban از همین نقطه شروع می‌کند: روش کار فعلی را به مجموعه Stepهای Repeatable و Changeable تبدیل کنید. Kanban Teamها Ruleها و Stepهای تکرارشونده را Policies می‌نامند.

System را به جای افراد قضاوت کنید

نوشتن Ruleها دشوار است چون انسان‌ها Success را به Competence افراد و Failure را به Incompetence نسبت می‌دهند. این نگاه ناعادلانه است، چون همهٔ Variableهای Project در Control Team نیستند. Lean Value «See the Whole» می‌گوید System بزرگ‌تری وجود دارد.

هر Team یک System برای ساخت Software دارد، حتی اگر Chaotic، متغیر یا عمدتاً Tribal Knowledge باشد. شاید «همیشه اول با این Customer Representative حرف می‌زنیم»، «همیشه این Schedule را می‌سازیم»، «Story Card می‌نویسیم» یا «بعد از یک Meeting کوتاه Developer فوراً Coding را شروع می‌کند». این Ruleها حتی اگر نوشته نشده باشند، System هستند.

Kanban می‌گوید همین System موجود را بفهمید و بعد Small Improvement ایجاد کنید. این معنای Incremental/Evolutionary Change و Practice «Improve Collaboratively, Evolve Experimentally» است. Measurementهای Lean پایهٔ Experiment و Scientific Method هستند: Baseline بگیرید، Change مشخصی ایجاد کنید، دوباره Measure کنید و ببینید Effect مطلوب رخ داده است یا نه.

Amplify Learning نیز در اینجا وارد می‌شود. Feedback Loopها Data را از Outcome برمی‌گردانند و Experiment بعدی را شکل می‌دهند. به همین دلیل Implement Feedback Loops Practice مرکزی Kanban است.

چرا Roleهای فعلی در ابتدا حفظ می‌شوند؟

فرض کنید Project همیشه با Meeting میان Project Manager، Business Analyst و Programmer شروع می‌شود. حتی اگر Policy جلسه نوشته نشده باشد، Job Titleها نشان می‌دهند هر Role چه Perspective و Responsibility دارد. Roleها بخشی از System فعلی‌اند؛ حذف فوری آن‌ها قبل از فهم System، Information را از بین می‌برد. Kanban ابتدا آن‌ها را Respect می‌کند و Change را پس از Measurement و Learning انجام می‌دهد.

هیچ Silver Bullet یا «Best Practice واحد برای همه» وجود ندارد. حتی Team یکسان با Practiceهای یکسان ممکن است در یک Project موفق و در دیگری ناموفق باشد. بنابراین Kanban نسخهٔ آماده تحمیل نمی‌کند؛ System فعلی را می‌بیند و از آنجا Evolution را شروع می‌کند.

«پس Kanban نمی‌گوید Project را چگونه اجرا کنم؟»

خیر. Kanban از Team می‌خواهد بفهمد اکنون Project را چگونه اجرا می‌کند؛ این می‌تواند Scrum، XP، Better-than-not-doing-it Scrum، Waterfall مؤثر یا نامؤثر، یا Process کاملاً Ad Hoc باشد. پس از فهم System، Practiceهایی برای Improvement ارائه می‌دهد.

چرا با وجود Process موجود به Kanban نیاز داریم؟ چون Deliver کردن چیزی به‌تنهایی به معنی Efficient بودن نیست. ممکن است Time/Effort زیادی Waste شود، Work کم‌ارزش باشد یا Ruleها Problemهای Habitual بسازند. Waste می‌تواند از Interaction افراد کاملاً پرتلاش Emergent شود، حتی وقتی هیچ‌کس تنبلی نمی‌کند.

مثال Chapter 8 همین بود: همه دائماً Work می‌کردند، اما Lead Time برای Customer بسیار زیاد بود. هیچ فردی عمداً Wait ایجاد نمی‌کرد، ولی System Delay عظیم تولید می‌کرد. Kanban دقیقاً چنین Problemهایی را Target می‌کند.

پاورقی منبع: Kanban Project Management Method نیست، اما این به معنی بی‌ربط‌بودن آن برای Project Manager نیست. David Anderson دربارهٔ Project Management with Kanban نیز نوشته و آموزش ارائه کرده است.

Stories وارد System می‌شوند؛ Code خارج می‌شود

Systems Thinking سازمان را System می‌بیند و بررسی می‌کند اجزای آن چگونه با هم ارتباط دارند و کل Organization در طول زمان چگونه عمل می‌کند. — Tom و Mary Poppendieck

نخستین گام Improvement، پذیرفتن وجود System است. Lean این را Systems Thinking می‌نامد. هر System Input را به Output تبدیل می‌کند.

از این زاویه Scrum Systemی است که Product Backlog Item را به‌عنوان Input می‌گیرد و Working Code را Output می‌دهد. اگر Backlog عمدتاً Story باشد، می‌توان به‌صورت استعاری گفت Team «Story را به Code تبدیل می‌کند». این استعاره نباید انسان‌ها را Cog تصور کند؛ هدف دیدن Work به‌عنوان بخشی از یک System بزرگ‌تر است.

وقتی Systems Thinking روی Scrum اعمال می‌شود، Workهایی که به تبدیل Story به Code کمک نمی‌کنند آسان‌تر دیده می‌شوند. بهبود سؤال‌های Daily Scrum توسط Jeff Sutherland که در Chapter 5 مطرح شد نمونه‌ای از Incremental/Evolutionary Improvement یک System موجود است.

هر Software Team Systemی دارد، حتی اگر خودش نداند

انسان‌ها Rule می‌سازند و Unwritten Ruleها را سریع تشخیص می‌دهند؛ مخصوصاً وقتی عضو جدید آن Rule را می‌شکند. Value Stream Map ابزار Lean برای تبدیل بخشی از همین Ruleهای نامرئی به توصیف System است. MMF را از آغاز تا Code دنبال کنید و Path واقعی را رسم کنید.

ممکن است MMFهای مختلف Pathهای متفاوت داشته باشند، اما اغلب می‌توان تعداد کمی Value Stream یافت که اکثریت Work را پوشش دهند. همین Mapها Description نسبتاً دقیقی از System ایجاد می‌کنند. وقتی Whole دیده شد، Team می‌تواند Pathهای Wasteful را شناسایی و Change تدریجی ایجاد کند.

Kanban Software Methodology یا Project Management System نیست

یکی از Pitfallهای رایج این است که Kanban را Methodology ساخت Software تصور کنیم. Kanban در اصل Process Improvement Method است که Methodology فعلی را بهتر می‌کند.

Work Item با Task فرق دارد

تصاویر Kanban Board ممکن است شبیه Scrum Task Board باشند، اما Boardها Task Board نیستند. روی Kanban Board Work Item قرار می‌گیرد: واحد Self-Contained Work که می‌توان آن را در کل System Track کرد. Work Item معمولاً از Task بزرگ‌تر است؛ ممکن است Feature، Requirement، Story یا Scope Item بزرگ‌تر باشد.

Taskها Actionهایی هستند که People برای حرکت دادن Work Item در System انجام می‌دهند. اگر بخواهیم استعارهٔ Machine را ادامه دهیم، Taskها Cog هستند، نه انسان‌ها.

Value Stream Mapping با Workflow Mapping

Columnهای Kanban Board ممکن است شبیه Stageهای Value Stream باشند، اما بسیاری از Practitionerها این دو را جدا می‌کنند:

• Value Stream Mapping: Thinking Tool در Lean برای فهم System و Work/Wait.
• Workflow Mapping: تعیین Stepهایی که Work Item در Kanban واقعاً طی می‌کند.

Task Board Scrum بیشتر Scope داخل Sprint را می‌بیند: To Do، In Progress، Done. Kanban Board Life Cycle بزرگ‌تری می‌بیند: Work Item از کجا می‌آید؟ Product Owner چطور آن را Prioritize می‌کند؟ بعد از Completion چه Review/Deployment/Production Stepهایی دارد؟ Problem قبل یا بعد از Coding نیز روی Board قابل مشاهده می‌شود.

به همین دلیل Teamی ممکن است Code را عالی بسازد اما User ناراضی باشد؛ شاید Wrong Work Item انتخاب شده یا Delay طولانی در Review/Deployment وجود دارد. Kanban این بخش‌های خارج از View معمول Task Board را Visible می‌کند.

Kanban با Project Management رابطهٔ جدی دارد، چون Improvement Flow روی Planning و Scheduling اثر می‌گذارد. استفادهٔ عمیق از Metricهای Kanban می‌تواند Project Management Method را نیز تغییر دهد، اما هدف اولیه همچنان بهبود Process است.

Improving Your Process with Kanban

Process Improvement سنتی در Ideal Form خوب به نظر می‌رسد: Senior Sponsorship، Measurement، Problem Identification، Improvement، تکرار؛ و در نهایت Process Repeatable، Managed و تحت Statistical Control می‌شود. برخی Organizationها واقعاً موفق بوده‌اند.

اما تجربهٔ رایج Developerها اغلب چیزی شبیه Dilbert است: Committeeهای متعدد، Binderهای Process، Consultantهای گران، Flowchartهای فراوان و Training اجباری. Team Process جدید را چند دقیقه امتحان می‌کند، آن را Unnatural و Awkward می‌یابد و کنار می‌گذارد؛ ولی چون Senior Management Sponsor بوده، از نظر Political باید ظاهر Compliance حفظ شود. Scope Document، Statement of Work، Empty Test Report و Boilerplate Meeting Minute تولید می‌شود تا نشان دهد Process «اجرا شده است».

تفاوت بزرگ Kanban این است که Improvement در دست Team می‌ماند. Team خودش Problem Workflow را پیدا می‌کند، Improvement پیشنهاد می‌دهد، Result را Measure می‌کند و به Standardهای خودش پاسخگو می‌ماند.

Visualize the Workflow

اولین Practice برای Improvement، Visualize است. این کار سخت‌تر از چیزی است که به نظر می‌رسد.

فرض کنید Boss از Programmer می‌پرسد «Software را چطور می‌سازی؟» Programmer Flowchart می‌کشد. در حین رسم متوجه می‌شود Code Review قرار است همیشه انجام شود، اما در Reality همیشه انجام نمی‌شود. چون Code Review «ایدهٔ خوبی» است، آن را روی Diagram می‌گذارد تا شاید Team بعداً منظم‌تر انجامش دهد.

این کار Process Improvement را خراب می‌کند. Diagram حالا Aspiration را به جای Reality نشان می‌دهد. اگر Code Review به دلیل Busy بودن Seniorها Cancel می‌شود، آن Root Cause هرگز دیده نمی‌شود چون Diagram ادعا می‌کند Review همیشه رخ می‌دهد.

در Kanban، Visualize یعنی دقیقاً آنچه واقعاً انجام می‌دهید، با همهٔ نقص‌ها، ثبت کنید. این اجرای See the Whole است. هنگام Mapping Workflow زمان اصلاح آن نیست؛ Decide as Late as Possible می‌گوید ابتدا Information را کامل کنید و Change را در Responsible Moment بعدی انجام دهید.

Kanban Board برای Visualize کردن Workflow

Kanban Board معمولاً Whiteboard با Column و Sticky Note است. سه تفاوت مهم با Scrum Task Board:

1. Kanban Board Work Item/Story را نشان می‌دهد، نه Taskهای ریز.
2. Columnها از Teamی به Team دیگر متفاوت‌اند و باید Workflow واقعی همان Team را نشان دهند.
3. Columnها می‌توانند WIP Limit داشته باشند.

نمونهٔ David Anderson شامل Columnهایی مانند Input Queue، Analysis (In Prog)، Analysis (Done)، Dev Ready، Development (In Prog)، Development (Done)، Build Ready، Test و Release Ready است. این فقط Example است، نه Template استاندارد.

Team Meeting روزانه‌ای دارد که معمولاً Walking the Board نامیده می‌شود. State هر Work Item بررسی می‌شود و Board باید Reality فعلی System را نشان دهد. Sticky باید هنگام Completion Step به Column بعد Pull/Move شده باشد؛ اگر نشده، Meeting آن را Sync می‌کند.

Board دیگری را Copy نکنید

Kanban Board باید Workflow زیرین خود Team را Visualize کند. Copy کردن Board کتاب یا Organization دیگر برخلاف Principle «Start with what you do now» است. Context تعیین می‌کند Column درست چیست.

در مثال Lead Time فصل قبل، وقتی Workflow واقعی روی Board رسم شد، Team دید Stickyها در Manager Review جمع می‌شوند. چیزی که قبلاً فقط «احساس کندی» بود حالا Bottleneck بصری است.

Limit Work in Progress

Kanban برای کنترل Flow از WIP Limit استفاده می‌کند: سقفی برای تعداد Work Itemهایی که اجازه دارند هم‌زمان در یک Stage باشند.

انسان معمولاً می‌خواهد Item فعلی را هرچه زودتر به Step بعد Push کند. Developer Design یک Feature را تمام کرده و طبیعی است بلافاصله Coding آن را شروع کند. اما اگر Test Team همین حالا بیش از Capacity Work دارد، ساخت Feature جدید فقط Queue Test را بزرگ‌تر و Team را Overburden می‌کند.

Kanban در این لحظه Options Thinking را به کار می‌گیرد. Coding همین Feature Commitment نیست؛ Option است. Board Optionهای دیگر را نشان می‌دهد: Design Feature دیگری در Stage قبلی، Fix Bug در Stage بعدی، Technical Debt یا Work دیگری که Flow را بهتر می‌کند.

WIP Limit Optionها را محدود می‌کند تا Decision ساده‌تر و System سالم‌تر شود. اگر Development Column در Limit است، Item تازه وارد آن نمی‌شود؛ Developer Work دیگری را Pull می‌کند. این کار Average Lead Time را کاهش می‌دهد، چون Queueهای Work نیمه‌تمام بی‌حد رشد نمی‌کنند.

مثال Manager Review با WIP Limit = 10

در Example قبلی، Stickyها در Manager Review جمع می‌شدند. Team و Senior Managerها Policy جدیدی تعریف می‌کنند: فقط تعداد مشخصی Feature می‌تواند در این Column باشد. اگر Release معمولاً ۳۰ Feature دارد و Managerها می‌توانند سه بار در طول Release Review کنند، Starting Experiment می‌تواند WIP Limit = 10 باشد.

وقتی دهمین Item وارد Manager Review شد، Item یازدهم دیگر Push نمی‌شود. Team می‌تواند QA را کمک کند، Technical Debt را Fix کند یا Work دیگری در Columnهای باز انجام دهد. Agreement این است که رسیدن Column به Limit، Signal لازم برای Review Meeting است.

پس از Review، Queue باز می‌شود و Flow ادامه می‌یابد. Feedback اکنون خیلی زودتر از Final Release می‌آید. اگر Feature باید Bump شود، در ابتدای Project مشخص می‌شود نه بعد از صرف هزینهٔ کامل Development. Work کم‌ارزش ماه‌ها در Bumped Backlog کهنه نمی‌شود.

این Cycle، Feedback Loop است. وقتی Loop طول Release را دارد، Feedback دیر و Disruptive است و Work انجام‌شده را Waste می‌کند. WIP Limit Length این Feedback Loop را Shorter می‌کند. اگر Managerها ارزش Review زودهنگام را ببینند، می‌توانند Limit را مثلاً از ۱۰ به ۶ کاهش دهند و Frequency Feedback را بیشتر کنند.

چرا WIP Limit را 1 نگذاریم؟

Shorter Feedback Loop همیشه بهتر نیست. اگر Team بیشتر وقت را Meeting و Respond to Feedback کند تا Work واقعی، System وارد Thrashing می‌شود: Feedback آن‌قدر سریع وارد می‌شود که قبل از Response به Batch قبلی، Batch بعدی می‌رسد.

بنابراین WIP Limit باید Experimentally تنظیم شود تا Feedback به‌اندازهٔ کافی Frequent باشد ولی Team زمان Response نیز داشته باشد.

Itemهایی که بارها به عقب برمی‌گردند می‌توانند Loop را Clog کنند. Team می‌تواند Stickyهایی را که Backward Move داشته‌اند Mark کند تا Rework Visible شود. اگر Manager Review هر Feature را بارها به Backlog برگرداند، یکی از Slotهای WIP مجدداً اشغال می‌شود و Flow کند می‌شود.

Team می‌تواند Workflow را Linearتر کند: Manager یک Review اصلی انجام دهد، فقط Featureهای خاص به Backlog برگردند و برای بقیه After-Review Development/Test Step اضافه شود. Board شاید Columnهای بیشتری داشته باشد، اما Longer-looking Workflow می‌تواند Fast‌تر باشد اگر Lead Time Measurement نشان دهد Rework Loop و Overburdening کم شده‌اند.

نکات کلیدی این بخش

• Kanban یک Method برای Process Improvement مبتنی بر Lean Mindset است.
• Team با System واقعی امروز شروع می‌کند، نه با Ideal Process.
• Change باید Incremental، Evolutionary و Collaborative باشد.
• Roleهای فعلی در ابتدا حفظ می‌شوند تا System قبل از Change فهمیده شود.
• Systems Thinking ورودی، خروجی و تعامل کل Workflow را می‌بیند.
• Kanban Board Work Itemها را در Life Cycle بزرگ‌تر Visualize می‌کند.
• Workflow Teamها Context-Specific است؛ Board دیگری را Copy نکنید.
• WIP Limit Queue را کنترل می‌کند، Overburdening را کم می‌کند و Feedback Loop را تنظیم می‌کند.
• Limit خیلی بزرگ Bottleneck را پنهان می‌کند و Limit خیلی کوچک Thrashing ایجاد می‌کند؛ اندازه باید با Measurement Experiment شود.

شکل‌ها و تصاویر منبع

تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و به‌صورت دادهٔ داخلی Base64 جاسازی شده‌اند.