摘要
看板1是豐田生產(chǎn)方式（Toyota Production System诺凡，TPS）中用來支持非集中“拉動式”生產(chǎn)控制（non-centralized "pull" production control）而使用的卡片吗铐。作為精益生產(chǎn)的工具，它現(xiàn)在已經(jīng)應用于世界各地的制造企業(yè)之中。如今在敏捷軟件開發(fā)中结执，項目的可視化（例如在墻壁上放置任務卡片就是常見的實踐）往往被叫做“軟件看板”食拜，或者“任務看板”。我們甚至可以看到一些產(chǎn)品維護團隊在類似瀑布過程模型中使用看板系統(tǒng)亮蒋。那么扣典，看板到底是什么呢？為什么它會被用于軟件開發(fā)環(huán)境之中呢慎玖？
在本文中贮尖，我首先解釋一下在精益生產(chǎn)中，尤其是TPS中的看板是什么樣子的趁怔，來理解下這個成熟行業(yè)中的實踐和法則湿硝，并圈定可以應用于軟件開發(fā)的概念。其次润努，我將環(huán)顧我們的軟件開發(fā)項目并指出看板應用的例子关斜。然后，我會分析生產(chǎn)環(huán)境中的看板系統(tǒng)與軟件開發(fā)中的看板系統(tǒng)有何異同铺浇，并嘗試提出觀點來有效地在軟件開發(fā)中應用看板系統(tǒng)痢畜，其中還介紹了新近在kanbandev2討論列表中萌芽的“KSSE——持續(xù)工程的看板系統(tǒng)（Kanban System for Sustaining Engineering）”運動。最后鳍侣，我給出TPS的一個全景視圖丁稀，也就是看板這種工具的原始背景，軟件開發(fā)仍可從中有所借鑒倚聚。
TPS中的看板
在“拉動式”生產(chǎn)系統(tǒng)中二驰，看板是指示移動或者制造零部件的信號裝置（通常是放在透明塑料封套中的卡片），它是在豐田生產(chǎn)系統(tǒng)（TPS）中發(fā)明和發(fā)展起來的秉沼。在介紹軟件開發(fā)中的看板之前桶雀，我來詳細的介紹下看板最初的用法，也就是TPS中的看板唬复。
看板的目的是通過確保只有當下游工序需要時上游工序才生產(chǎn)零部件矗积，進而最大限度地減少工序（process）之間的在制品（Work-In-Process，WIP）或者庫存敞咧〖罚“拉動式”是指下游工人從他們的上游工序中領取或者“拉”出所需要的零部件。
圖1是看板系統(tǒng)的抽象模型休建。圖中以兩個工序乍恐，上游工序和下游工序為例评疗，其中上游工序為下游工序供應零部件。為了給最終用戶提供產(chǎn)品茵烈，這一工序需要生產(chǎn)零部件并將其流向下游百匆，但是不能生產(chǎn)太多，因為生產(chǎn)過剩被認為是最糟糕的浪費呜投。為了避免生產(chǎn)過剩加匈，上游工序不是將成品零部件“推”給下游工序，反而是下游工序主動地從上游工序中拉出（拿）零部件仑荐。零部件存放的地方叫做“倉庫”（或者“超市3”——Taiichi Ohno首次提出看板的思想雕拼，是在他參觀了某個美國超市之后，在那里不是由商店售貨員而是由顧客自己去獲取他們想要的東西）粘招。倉庫位于上游工序啥寇，作為在制品的“緩沖區(qū)”或者“隊列”。當一名來自下游工序的工人——叫做“物料管理員”——來到倉庫并拿到新近完成的零部件洒扎，同時他也反饋一個生產(chǎn)信號——也就是辑甜，下游從上游中獲取東西并在同時通過看板卡將信息推給上游。這是必須的逊笆，因為沒有來自下游工序的信號上游工序決不會生產(chǎn)零部件栈戳。
那么在圖1中有兩種類型的看板一同工作：
·領取看板（Withdraw Kanban）——是由物料管理員遞交給倉庫的購物清單岂傲。
·生產(chǎn)看板（Production Kanban）——指示上游工序為其下游工序生產(chǎn)零部件难裆。
如圖1所示，領取看板循環(huán)于兩道工序之間镊掖，而生產(chǎn)看板循環(huán)于工序內(nèi)部乃戈，并且兩者在倉庫內(nèi)發(fā)生交換。讓我們稍微仔細的了解下這個交換細節(jié)亩进。圖2顯示了在倉庫中是如何進行“看板交換”症虑。
1.位于下游的物料管理員收到領取零部件的信號。此信號由下游工序定義归薛，為下面兩種情況之一：
（a） 由收集到的領取看板的數(shù)量觸發(fā)信號
（b） 由定時時間間隔觸發(fā)信號
物料管理員帶著空托盤（pallet）和收集到的領取看板訪問上游倉庫谍憔，并將他收集的領取看板當作購物清單——其中標明了下游工序需要什么，需要多少主籍。
2.由上游工序完成的零部件用托盤裝著磺浙，并附上生產(chǎn)看板放入倉庫逃顶。（這些發(fā)生在一個單獨的線程中，和（1）是獨立的。）
3.物料管理員拿取領取看板（購物清單）中指定的零部件府怯，檢查是否與附在零部件上的生產(chǎn)看板相匹配，然后交換兩個看板。
4.他將生產(chǎn)看板放入“生產(chǎn)板（Production Board）”中——稍后當看板累計到一定的閥值時，它將直觀地觸發(fā)上游生產(chǎn)奥务。
5.物料管理員將所需的零部件附帶著領取看板一同從倉庫搬運至下游車間。
你可以看到倉庫是由一個單獨的線程控制的袜硫、位于兩個工序之間的隊列（queue）氯葬，它通過看板來交換物品和信息「缚睿看板卡上面寫明了像零部件號碼溢谤、名稱、數(shù)量憨攒、托盤類型世杀、倉庫位置這樣的信息，這樣物料管理員拿到卡片就知道去做什么了肝集。
對于看板的運轉(zhuǎn)有著嚴格的規(guī)定——被稱作“看板六準則”：
1.客戶（下游）工序精確按照看板上指示的數(shù)量領取產(chǎn)品瞻坝。
2.供應者（上游）精確按照看板上指定的數(shù)量和順序生產(chǎn)產(chǎn)品。
3.沒有任何產(chǎn)品在看板之外制造或者流動杏瞻。
4.每件產(chǎn)品每時每刻都要與看板相伴所刀。
5.質(zhì)量殘次和數(shù)量有誤的產(chǎn)品決不能發(fā)往下游工序。
6.謹慎地減少看板的數(shù)量來降低庫存并揭露問題捞挥。
正如我們所了解到的浮创，倉庫用作零部件的隊列，托盤用作零部件的載體砌函，而看板卡用作客戶之所需的信息載體斩披。通過維持“連續(xù)流通（continuous
flow）”（消除等待帶來的浪費）和“最小化在制品（minizing
WIP）”（消除生產(chǎn)過剩帶來的浪費）之間的平衡，它們共同形成了“拉動式”系統(tǒng)讹俊。在超市中也是用同樣的機制來把從采購到銷售之間的流程中的在制品維持在“適當”數(shù)量垦沉，做好這一步是提高商店盈利率的關鍵。
目前為止仍劈，我已經(jīng)講述了看板是如何在制造業(yè)中工作的厕倍。注意以上是對真實看板系統(tǒng)的簡化模型。這里沒有明確提及的另一件事是看板形象地向每一個工人展示了信息和產(chǎn)品的流程贩疙，并激勵在現(xiàn)場5（Gemba讹弯，指工作場所）的改善4（Kaizen，指工序改進）这溅。改善源于對現(xiàn)場中發(fā)生事件的關注组民。通過看板，每個工人（不是管理人員）都可以看到生產(chǎn)流程芍躏，進而有機會發(fā)現(xiàn)其中的浪費邪乍，并建議改進他們所在的工序。
看板的特性
根據(jù)前一節(jié)的詳細介紹，這里列出了從TPS最初的看板概念中總結(jié)的特性和作用庇楞。
·實體的：看板是實體的卡片榜配。可以拿在手中吕晌，可以移動蛋褥，可以放在某些東西上面或者里面。
·限制在制品數(shù)量：看板限制在制品的數(shù)量睛驳，也就是防止生產(chǎn)過剩烙心。
·連續(xù)流通：它會在倉庫耗盡庫存之前通知生產(chǎn)的需求。
·拉動式：下游工序從上游工序中抽取零部件乏沸。
·自導向（Self-Directing）：它有要完成的工作的所有信息淫茵，能以一種非集中的方式實行生產(chǎn)自治，并且不需要微管理（micro-management）蹬跃。
·可視化：堆放或者張貼著的看板直觀地展示了當前的狀態(tài)和進度匙瘪。
·信號：看板的可視化狀態(tài)為下一步的領取操作或者生產(chǎn)操作作出指示。
·改善（Kaizen）：可視化的流程觸發(fā)并刺激改善蝶缀。
·附著的（Attached）：看板附在所供給的零部件之上并隨其一同移動丹喻。
圖3為以上9個特性之間的相互影響，它顯示了如何將這些組成一個因果效應網(wǎng)絡翁都。你從中可以看到看板的兩種含義碍论，一是“在維持連續(xù)流通的同時限制在制品數(shù)量”，而另一種是“改善”柄慰。
圖表右側(cè)說明了如何在維持連續(xù)流通的同時鳍悠，最大限度地減少在制品。如果倉庫中的在制品太少的話先煎，下游工序不得不等待所需的零部件準備就緒贼涩，但是在制品還應該保證最小化以防止生產(chǎn)過剩巧涧。這樣看來這兩個目標是相矛盾的薯蝎，而看板正被看作是解決這個難題的策略。
看板附著于零部件谤绳，并且可以被收集和重用占锯，因此看板的數(shù)量是固定的。而且看板還可以直觀地指示下游工序僅當需要時才獲取零部件缩筛。這里有兩種限定在制品數(shù)量的機制消略。
第一個機制“附著的看板”工作機制同“能量守恒定律”類似。一旦根據(jù)產(chǎn)品市場銷售的速度和當前工序的內(nèi)在變化規(guī)律確定了看板的數(shù)量瞎抛，那么不管零部件的流入和流出如何艺演，在制品的數(shù)量都被限制為看板數(shù)量的一定比例。在任何時候，看板（相當于系統(tǒng)中的“能量”）的最大數(shù)量都與在制品的上限保持守恒胎撤。在圖4中晓殊，你可以看到“系統(tǒng)”指的是上游工序和下游工序之間的庫存，也就是“倉庫”中的在制品伤提。
第二個機制——“拉動式”——通過依據(jù)下游消耗速度來確定上游工序的生產(chǎn)速度巫俺，這種機制也限制了在制品的數(shù)量。第一個機制僅僅涉及到在制品的數(shù)量肿男，而第二個則涉及到流程——流程的方向和速度介汹。
“方向”——僅由下游工序來驅(qū)動生產(chǎn)。
“速度”——通過看板傳達下次生產(chǎn)的時機和數(shù)量舶沛。
通過確保上游工序的生產(chǎn)以下游工序首次衍生訂單中的消耗為依據(jù)嘹承，“拉動式”限制了在制品的數(shù)量。通過在倉庫中交換看板如庭，將生產(chǎn)控制信息從下游推到上游赶撰，這種依賴性便得以實現(xiàn)。
回到圖3：圖表左側(cè)說明了如何促使工作自導向并促進改善柱彻。通過查看張貼在面板上的看板卡豪娜，每個人都可以了解到發(fā)生了什么事，以及工序運轉(zhuǎn)的健康狀態(tài)哟楷。改善起始于對現(xiàn)場（Gemba）工作流的觀測瘤载。放置于面板之上的看板卡直觀地幫助工作在沒有中央控制管理之下自導向。為了支持改善卖擅，這種自治的工序向外提供其性能數(shù)據(jù)鸣奔，并將管理重點從對具體工作的指派或者調(diào)度上轉(zhuǎn)移到改善活動。
圖3中的箭頭最終都指向了三個結(jié)果惩阶，如其所示挎狸，看板的終極目標可以表示為“限制在制品數(shù)量”、“連續(xù)流通”和“改善”断楷∠谴遥看板系統(tǒng)在維持“連續(xù)流通”的同時“限制在制品數(shù)量”。它緩沖由普通變因引起的變化情況冬筒，并暴露特殊變因引起的變化情況恐锣，以備改善。
軟件開發(fā)中的看板
現(xiàn)在舞痰，讓我們將視線回到我們自己的工作領域——軟件開發(fā)土榴。在敏捷軟件開發(fā)中，通過在項目工作場所的墻上張貼卡片來呈現(xiàn)和分享項目狀態(tài)已經(jīng)成為一種常見的實踐响牛。我已經(jīng)在我的上一篇InfoQ文章《用“看板圖”實現(xiàn)敏捷項目的可視化》[Hiranabe07]給出了很多例子玷禽。特別是赫段，貼在墻上用來展示當前項目狀態(tài)的任務卡片有時也被稱作“任務看板”或者“軟件看板”[Poppendieck03]。圖5是Change Vision公司的JUDE6開發(fā)團隊所用的任務看板矢赁。
在面板上瑞佩，工程任務用卡片（即時貼）來代表，并通過把卡片貼在在面板中的不同區(qū)域來象征任務的狀態(tài)坯台，這些區(qū)域被標注為“ToDo”炬丸、“Doing”和“Done”（標注的名稱可能因地而異，比如“進行中（In
Progress）”蜒蕾、“已測試（Tested）”稠炬、“已驗收（Accepted）”、“停滯中（Blocking）”等等咪啡。）首启。這樣的看板面板有利于可視化地通知任務并限制在制品（處理中的任務）數(shù)量。不過在這里并沒有出現(xiàn)“工序”（上游或者下游）撤摸，新出現(xiàn)的概念是“迭代”毅桃。對于每一次迭代，通過分解用戶故事識別出任務准夷，并且將其張貼在面板的ToDo區(qū)域中钥飞。
這是一個拉動式系統(tǒng)嗎？在制造業(yè)中衫嵌，零部件由上游工序傳遞至下游工序读宙。而在圖5所示的敏捷開發(fā)中，并沒有看到“移交物”楔绞。一個看板卡片對應一個任務结闸，上面寫明了如下信息：任務編號、任務名稱酒朵、估計時間以及任務領取人的名字桦锄。任務有狀態(tài)，可以是“ToDo”蔫耽、“Doing”或者“Done”结耀，狀態(tài)信息被分享給整個團隊。敏捷開發(fā)重視在一起工作针肥，并趨向于減少團隊內(nèi)部的移交物饼记。我稱此為“敏捷看板”香伴。
圖6是另一個看板面板實例慰枕，由Yamaha Motor Solution有限公司7所采用。
在這里即纲，看板系統(tǒng)被用于帶有流程的傳統(tǒng)瀑布開發(fā)模型具帮。項目被分解成“設計”、“開發(fā)”、“驗證”等連續(xù)的工序蜂厅，而看板卡就在這些工序之間移動匪凡。每張卡片代表需要修改或者添加的系統(tǒng)需求，也代表給下游工序的移交物掘猿。注意這不是一個標準的瀑布流程——標準瀑布流程中所有的需求在同一時間內(nèi)完成“設計”病游，而“開發(fā)”和“驗證”則在另一時間，這將使得所有的卡片作為一個整體進行移動稠通。與標準的瀑布流程不同的是衬衬，這個項目中的卡片是一個接一個地移動，就像制造業(yè)中的單件流（one-piece-flow）一樣改橘。這里表現(xiàn)的是產(chǎn)品生命周期里穩(wěn)定的“持續(xù)（sustaining）”階段滋尉，處在帶有流程的瀑布狀態(tài)轉(zhuǎn)換模型的管理之下。在這里飞主，你可以清楚地看到“工作流程”的概念狮惜，而不同于敏捷中的“迭代”概念。它比敏捷看板看起來更像工廠中的看板碌识，而且通過制定規(guī)則只允許下游工序移動卡片8碾篡，可以使其成為拉動式系統(tǒng)。我稱其為“持續(xù)看板”筏餐，這與稍后章節(jié)中討論的David Anderson的“持續(xù)工程的看板系統(tǒng)”是類似的耽梅。
圖7顯示的是另外一個例子——在整個產(chǎn)品開發(fā)流程的價值流中使用看板的思想實驗（thought experiment）[Poppendieck 07]。
假設在一個產(chǎn)品開發(fā)流中有客戶團隊胖烛、產(chǎn)品所有人眼姐、開發(fā)團隊和QA團隊，他們使用隊列傳遞移交物來協(xié)調(diào)工作佩番，以使得團隊之間能異步工作众旗，并維持工作速度。每一個“DONE”空間是一個隊列趟畏，其工作方式就像制造工廠中的“倉庫”那樣贡歧，并且看起來非常像TPS看板系統(tǒng)。同時赋秀，它看起來就像每條工序內(nèi)同步地使用敏捷看板利朵，而在貫穿各個工序的整個價值流上異步地使用持續(xù)看板。我認為看板系統(tǒng)可以擴展至覆蓋整個價值流猎莲，在這種情況下绍弟，它是價值流的一個活生生的視覺表現(xiàn)。
在這里例子中著洼，通過設定每一個區(qū)域的大小可以限制在制品的數(shù)量樟遣。而為了使其變成拉動式系統(tǒng)而叼，還需要一種機制來使下游工序以某種信號通知上游工序開始工作。其中一種方法是制定一個規(guī)則只允許下游移動DONE區(qū)域中的卡片來通知上游豹悬。另一種方法是定期召開“迭代會議”葵陵，來同步團隊和團隊之間傳遞（通訊）的信息。這兩種通訊方式可能對應于我們在第一章節(jié)中討論的零部件領取的兩種信號瞻佛，即領取看板的數(shù)量（a）和時間間隔（b）的可視信號脱篙。一次迭代中的一組用戶故事對應于迭代中托盤里的零部件，而零部件的數(shù)量對應于迭代中的項目“生產(chǎn)率”（昨日天氣[Beck00]）伤柄。我叫它為“精益+敏捷看板”涡尘，如下一個例子展示的那樣它可以與“敏捷看板”相結(jié)合。
圖8中是一個小型的“便攜式”看板系統(tǒng)响迂，這是我在CENTRAL COMPUTER
SERVICES有限公司的某個項目里發(fā)現(xiàn)的考抄。在這個項目中，團隊被分為了幾個小型子團隊（通常是一對人）蔗彤。整個團隊有一個與圖7概念相似的工作流川梅，還有圖8所示的小型敏捷看板面板（ToDo、Doing然遏、DONE）贫途。
當一個子團隊選取了一個用戶故事，他們將其分解到任務并張貼在便攜式看板面板上待侵。在這種情況下丢早，看板系統(tǒng)由兩個層面組成，在項目層面一張卡片代表一個用戶故事秧倾，而在團隊（或者結(jié)對）層面一張卡片代表一個任務怨酝。
他們很喜歡這個便攜式小型看板系統(tǒng)，并命名為“看板nano”那先。
如你所見农猬，將看板的概念應用于軟件開發(fā)有許多方式∈鄣“敏捷看板”用來在團隊中分享信息并使工作自導向斤葱，但它不支持流程∫菊ⅲ“持續(xù)看板”是另一種類型的看板揍堕，能夠讓小批量的維護工作在幾個狀態(tài)之間流轉(zhuǎn)。這種結(jié)合便是“精益+敏捷看板”汤纸，使用“持續(xù)看板”貫穿價值流衩茸，同時在子流（sub-stream）中使用“敏捷看板”。
注意蹲嚣，圖5中的“敏捷看板”（在當今敏捷項目中隨處可見）僅僅可以看到價值流中的一個子流递瑰。當你考慮從客戶到客戶的完整價值流祟牲，經(jīng)常由處于同一流中的某個團隊遞交給你需求隙畜，而另一個團隊則交付你的工作結(jié)果給客戶抖部。這篇文章的目的之一，就是要設法讓看板的應用超越“敏捷看板”议惰，擴大看板在價值流中的應用范圍慎颗。
生產(chǎn)與開發(fā)
軟件開發(fā)是不同于生產(chǎn)活動或者制造活動的。軟件工程師每次創(chuàng)造的產(chǎn)物都是不同的言询，而制造業(yè)總是周而復始的生產(chǎn)相同的東西俯萎。所以直接將兩者等同起來是危險的≡撕迹可是夫啊，讓我們研究一下如何在軟件開發(fā)看板中找到TPS看板中的特性。表1顯示了我們在章節(jié)1中總結(jié)的看板特性在我們已經(jīng)提及的兩種軟件看板中是否仍然有效辆憔。
圖5所示的敏捷看板例子本身并沒有實現(xiàn)“限制在制品的數(shù)量”撇眯、“連續(xù)流通”和“拉動式”特性。敏捷看板更關注于實現(xiàn)任務虱咧、“可視化”和“自導向”熊榛，以便幫助團隊自治并改進其工序。為了使工序連續(xù)流通并限制在制品的數(shù)量腕巡，需要召開“迭代會議”交流信息玄坦。
圖6中的“持續(xù)看板”不僅可以限制在制品的數(shù)量，還可以以“單件（one-piece）”和“拉動式”的方式控制流程绘沉，而不需要召開迭代會議煎楣。在這種方法中，它的關注點是“限制在制品的數(shù)量”车伞、“連續(xù)流通”和“拉動式”转质，同時允許團隊（或者管理人員）借其改進工序。
回顧一下圖3帖世，我將看板的特性和作用分成圖9所示的兩個關鍵區(qū)域休蟹，以便上面提到的兩類軟件看板概念的用途各得其所。圖10顯示了生產(chǎn)和開發(fā)的頻譜圖日矫。生產(chǎn)是成功幾率很高（高于99%）的工序赂弓，而開發(fā)的成功幾率要低。當成功幾率在50%左右的時候敏捷是理想的開發(fā)方法哪轿，而當成功幾率超過90%的時候瀑布式則是理想的開發(fā)方式（依據(jù)Shannon理論盈魁，一個具有50%成功幾率的項目是最有價值的項目）。通常隨著開發(fā)進入到支持維護狀態(tài)窃诉，修改缺陷和添加新功能的成功幾率逐步提高杨耙。
看板系統(tǒng)的“工序控制焦點（Process Control Focus）”適合在“高于90%”的成功率下工作赤套，而“工序改進焦點（Process Improvement Focus）”既適合在50%成功率也適合在90%成功率下工作。
值得注意的是珊膜，敏捷方法在產(chǎn)品維護狀態(tài)（sustaining mode ）下仍能工作良好容握，同樣看板的“工序改進焦點”特性也在維護狀態(tài)下工作良好。
KSSE——持續(xù)工程的看板系統(tǒng)
接下來车柠，我介紹最近出現(xiàn)的一種軟件開發(fā)精益應用剔氏。Agile2007會議時，我參加了David Anderson主持的關于軟件看板的一個會中會（Conference-Within-A-Conference竹祷，CWAC）谈跛。他在Corbis.com管理著一個“維護狀態(tài)（maintenance mode）”類型的看板系統(tǒng)，并發(fā)表了一篇相關論文——持續(xù)工程的看板系統(tǒng)[Anderson 07]塑陵。他的方法首先關注于看板的“限制在制品數(shù)量”特性——就像在圖4所示的抽象圖表那樣——也關注“自導向”特性以使得團隊自組織感憾，減少自上而下的（top-down）管理。然后令花，通過看板觀察流程阻桅，找出整個工序流中的駐點（stagnation point）并調(diào)整人力資源，也就是在工序間調(diào)動成員彭则。這意味著他的方法鳍刷，像圖3表現(xiàn)的那樣，涵蓋了看板特性中從“限制在制品數(shù)量”俯抖、“自導向”到“改善”输瓜。
會議之后，Anderson啟動了一個看板開發(fā)郵件列表2芬萍，這里已經(jīng)成為將看板應用于軟件開發(fā)的一個新興知識創(chuàng)新討論社區(qū)尤揣，名為“KSSE”——持續(xù)工程的看板系統(tǒng)，讀作Kiss-ee ;-)柬祠。Aaron Sanders還著手創(chuàng)建關于看板的知識體系北戏，并已經(jīng)開始構(gòu)建KSSE詞匯表。
KSSE對于通過隊列在工序間傳遞移交物漫蛔、連續(xù)相接的多個工序運作良好嗜愈。請注意KSSE不一定需要納入“迭代”的概念。使用KSSE的方式莽龟，我看到了另一種縮放（scaling）敏捷的可能性方式并且好過“scrum of scrums”蠕嫁。[Ladas07]
創(chuàng)造價值流
當通過看板從敏捷放大到精益時，一張看板卡應該代表什么東西呢毯盈？
?在敏捷看板系統(tǒng)中剃毒，一個卡片是一個從“用戶故事”中分解出來的“任務”。在開發(fā)團隊中，它作為工作的一個基本單元執(zhí)行赘阀，因為團隊中每個人都能明白它的意思益缠。但是，在看板系統(tǒng)中它貫穿了價值流中的多個工序（多個團隊）基公，在其中流轉(zhuǎn)之物應該帶有客戶認可的價值幅慌。既然這樣，看板卡片就不是對應于“工作（work）”而是對應于“功能（feature）”酌媒，并且它不是WBS（任務分解結(jié)構(gòu)欠痴，work
breakdown structure）的組成部分迄靠，而是FBS（功能分解結(jié)構(gòu)秒咨，feature breakdown
structure）的組成部分。因此團隊中的每個人掌挚，甚至是客戶雨席，都能夠理解看板的含義和流轉(zhuǎn)之物的價值。Jim Highsmith
在《敏捷項目管理（Agile Project Management）》[Highsmith04]書中所概述的原理也將FBS定位高于WBS吠式。
“用戶故事”陡厘，“Backlog事項”或者“用例”都被抽象為“MMF”（最小可市場化功能，minimum marketable features）特占，用來明確地聲明流轉(zhuǎn)之物具有客戶價值糙置。于是精益開發(fā)就可以說成“使得MMF快速流過整個價值流∈悄浚”
圖5中“敏捷看板”的例子是一個工作的分解谤饭，它在團隊內(nèi)部工作良好。圖6中“持續(xù)看板”的例子是一個功能的分解并且一張卡片代表一個MMF懊纳。圖7中“精益+敏捷看板”的例子與圖8一起展示了上級功能分解和下級工作分解的結(jié)合揉抵。
一旦建立起工作流程，五個“精益思想”[Womack1996]的核心概念就可直接應用于整個工序嗤疯。精益工序的管理可以簡單地遵循以下原則冤今。
·從客戶的角度定義價值——確定和分類MMF
·明確價值流并消除浪費——找出駐點（停滯的任務）
·在客戶的拉動下創(chuàng)造價值流——制定看板的拉動規(guī)則
·關注員工并給予一定的權(quán)力——授權(quán)給在現(xiàn)場的團隊
·追求完美的持續(xù)改善——反省和改善
TPS全景視圖
以下內(nèi)容相當于附錄，我在這一部分分享從TPS中學到茂缚，并發(fā)現(xiàn)可以適用于軟件開發(fā)的知識戏罢。Mary和Tom
Poppendieck已經(jīng)發(fā)現(xiàn)有效的軟件開發(fā)方式和精益或者TPS方法有著很多的相同點——不是在實踐層面，而是在原理層面上[Poppendieck03,
07]脚囊。讓我們從更高的角度回過頭來再看下TPS中的看板龟糕。
讀者很容易假定看板是整個TPS的中心，但其實并不是凑术。圖11展示了TPS的概念結(jié)構(gòu)翩蘸，有時也叫做“TPS之屋（TPS House）”。它有好幾種版本淮逊，圖11是基于Toshiko Narusawa和John Shook的版本[Narusawa06]催首。在TPS中扶踊，看板僅僅是“拉動式系統(tǒng)”實現(xiàn)準時制（Just-In-Time9）的一種方法。準時制可以解釋為“僅在需要的時候生產(chǎn)和交付所需要的東西郎任，并且僅完成需要的數(shù)量”秧耗。它直接瞄準的是客戶的需要：“盡快以最低的價格提供最高質(zhì)量的產(chǎn)品〔爸危”注意分井，準時制是TPS的兩大支柱之一，另一個是Jidoka10（譯注：寫作“自動化/自働化”霉猛，但其含義與對應于Automation的中文的“自動化”不同尺锚，詳見注釋）。制造業(yè)中的“Jidoka”即自動停機（Autonomation）與軟件開發(fā)中的測試驅(qū)動開發(fā)類似惜浅。Mary和Tom Poppendieck把Jidoka解釋為“停止流水線文化（Stop the Line Culture）”瘫辩。豐田工廠的工人真正地可以停止流水線而不是把次品推到下一個工序——它不僅是一種規(guī)定，也是豐田公司的一種文化坛悉，它的萌芽可以追溯到（豐田集團創(chuàng)始人）豐田佐吉時期伐厌。
準時制由以下三部分元素構(gòu)成，“節(jié)拍時間（Takt time）”裸影、“連續(xù)流通”和“拉動式系統(tǒng)”挣轨。
節(jié)拍時間基于銷售率制定產(chǎn)品生產(chǎn)率。
連續(xù)流通與節(jié)拍時間相匹配轩猩，無停滯地在工序中生產(chǎn)部件卷扮。
拉動式系統(tǒng)在工序之間移動零部件并通知生產(chǎn)，同時限制庫存數(shù)量界轩。
也應該注意到兩個支柱依賴于改善和人画饥。豐田一年生產(chǎn)近千萬輛汽車，同時浊猾，他們通過在現(xiàn)場（也就是車間）中近1百萬次的改善來完善他們的工序抖甘。形象化地表示出團隊正在做些什么，總是改善的出發(fā)點葫慎。
結(jié)論
文中衔彻，我分析了看板在制造業(yè)的實施，接著列出了看板的特性偷办〖瓒睿看板系統(tǒng)用以達到以下目標：
更優(yōu)的工序控制——在限制在制品數(shù)量的同時保持連續(xù)流通
更優(yōu)的工序改進——使流程可視化并且激勵改善
“敏捷看板”專注于#2，而“持續(xù)看板”專注于#1椒涯。我提出將兩者結(jié)合柄沮，來拓展可視化和“拉動式系統(tǒng)”到整個價值流，以使得整個生產(chǎn)精益化。
感謝
Tom Poppendieck與Mary對本文進行了通篇審校祖搓，并給出了許多見解和建議狱意，在此我表示非常感謝。感謝Yamaha Motor
Solution有限公司總裁Yasuharu Terai以及Ryuichi Sato允許本文中使用其看板系統(tǒng)的圖片拯欧。另外David
Anderson也參與了本文的審校工作并且提出了一個更好的看板抽象層次來推進KSSE的發(fā)展详囤。KSSE概念最初來源于Kanbandev
Yahoo團隊的討論。最后感謝Deborah Hartmann的最后校訂工作镐作，使得我的表達更清晰藏姐。
關于作者
Kenji HIRANABE是日本Change Vision公司的CEO。他是JUDE（一個集成了ERD该贾、DFD和Mind Map的UML編輯器）和TRICHORD11（一個集成了Burndown圖表和Parking Lots圖的敏捷項目管理看板系統(tǒng)）的創(chuàng)始人羔杨。他還把《Lean Software Development》、《XP Installed》靶庙、《Agile Project Management》以及其他XP/Agile書籍翻譯成日文问畅。Kenji把軟件開發(fā)看作是一種溝通游戲娃属，并一直在尋求提高軟件開發(fā)的生產(chǎn)效率六荒、合作程度以及樂趣的途徑。
