作者 Kenji Hiranabe 譯者 苑永凱 發(fā)布于 2008年2月19日 上午3時(shí)0分
看板1是豐田生產(chǎn)方式（Toyota Production System，TPS）中用來(lái)支持非集中“拉動(dòng)式”生產(chǎn)控制（non-centralized "pull" production control）而使用的卡片。作為精益生產(chǎn)的工具，它現在已經(jīng)應用于世界各地的制造企業(yè)之中。如今在敏捷軟件開(kāi)發(fā)中，項目的可視化（例如在墻壁上放置任務(wù)卡片就是常見(jiàn)的實(shí)踐）往往被叫做“軟件看板”，或者“任務(wù)看板”。我們甚至可以看到一些產(chǎn)品維護團隊在類(lèi)似瀑布過(guò)程模型中使用看板系統。那么，看板到底是什么呢？為什么它會(huì )被用于軟件開(kāi)發(fā)環(huán)境之中呢？
在本文中，我首先解釋一下在精益生產(chǎn)中，尤其是TPS中的看板是什么樣子的，來(lái)理解下這個(gè)成熟行業(yè)中的實(shí)踐和法則，并圈定可以應用于軟件開(kāi)發(fā)的概念。其次，我將環(huán)顧我們的軟件開(kāi)發(fā)項目并指出看板應用的例子。然后，我會(huì )分析生產(chǎn)環(huán)境中的看板系統與軟件開(kāi)發(fā)中的看板系統有何異同，并嘗試提出觀(guān)點(diǎn)來(lái)有效地在軟件開(kāi)發(fā)中應用看板系統，其中還介紹了新近在kanbandev2討論列表中萌芽的“KSSE——持續工程的看板系統（Kanban System for Sustaining Engineering）”運動(dòng)。最后，我給出TPS的一個(gè)全景視圖，也就是看板這種工具的原始背景，軟件開(kāi)發(fā)仍可從中有所借鑒。
看板的目的是通過(guò)確保只有當下游工序需要時(shí)上游工序才生產(chǎn)零部件，進(jìn)而最大限度地減少工序（process）之間的在制品（Work-In-Process，WIP）或者庫存。“拉動(dòng)式”是指下游工人從他們的上游工序中領(lǐng)取或者“拉”出所需要的零部件。
圖1 看板和拉動(dòng)式生產(chǎn)
圖1是看板系統的抽象模型。圖中以?xún)蓚€(gè)工序，上游工序和下游工序為例，其中上游工序為下游工序供應零部件。為了給最終用戶(hù)提供產(chǎn)品，這一工序需要生產(chǎn)零部件并將其流向下游，但是不能生產(chǎn)太多，因為生產(chǎn)過(guò)剩被認為是最糟糕的浪費。為了避免生產(chǎn)過(guò)剩，上游工序不是將成品零部件“推”給下游工序，反而是下游工序主動(dòng)地從上游工序中拉出（拿）零部件。零部件存放的地方叫做“倉庫”（或者“超市3”——Taiichi Ohno首次提出看板的思想，是在他參觀(guān)了某個(gè)美國超市之后，在那里不是由商店售貨員而是由顧客自己去獲取他們想要的東西）。倉庫位于上游工序，作為在制品的“緩沖區”或者“隊列”。當一名來(lái)自下游工序的工人——叫做“物料管理員”——來(lái)到倉庫并拿到新近完成的零部件，同時(shí)他也反饋一個(gè)生產(chǎn)信號——也就是，下游從上游中獲取東西并在同時(shí)通過(guò)看板卡將信息推給上游。這是必須的，因為沒(méi)有來(lái)自下游工序的信號上游工序決不會(huì )生產(chǎn)零部件。
那么在圖1中有兩種類(lèi)型的看板一同工作：如圖1所示，領(lǐng)取看板循環(huán)于兩道工序之間，而生產(chǎn)看板循環(huán)于工序內部，并且兩者在倉庫內發(fā)生交換。讓我們稍微仔細的了解下這個(gè)交換細節。圖2顯示了在倉庫中是如何進(jìn)行“看板交換”。
你可以看到倉庫是由一個(gè)單獨的線(xiàn)程控制的、位于兩個(gè)工序之間的隊列（queue），它通過(guò)看板來(lái)交換物品和信息?？窗蹇ㄉ厦鎸?xiě)明了像零部件號碼、名稱(chēng)、數量、托盤(pán)類(lèi)型、倉庫位置這樣的信息，這樣物料管理員拿到卡片就知道去做什么了。
對于看板的運轉有著(zhù)嚴格的規定——被稱(chēng)作“看板六準則”：正如我們所了解到的，倉庫用作零部件的隊列，托盤(pán)用作零部件的載體，而看板卡用作客戶(hù)之所需的信息載體。通過(guò)維持“連續流通（continuous flow）”（消除等待帶來(lái)的浪費）和“最小化在制品（minizing WIP）”（消除生產(chǎn)過(guò)剩帶來(lái)的浪費）之間的平衡，它們共同形成了“拉動(dòng)式”系統。在超市中也是用同樣的機制來(lái)把從采購到銷(xiāo)售之間的流程中的在制品維持在“適當”數量，做好這一步是提高商店盈利率的關(guān)鍵。
目前為止，我已經(jīng)講述了看板是如何在制造業(yè)中工作的。注意以上是對真實(shí)看板系統的簡(jiǎn)化模型。這里沒(méi)有明確提及的另一件事是看板形象地向每一個(gè)工人展示了信息和產(chǎn)品的流程，并激勵在現場(chǎng)5（Gemba，指工作場(chǎng)所）的改善4（Kaizen，指工序改進(jìn)）。改善源于對現場(chǎng)中發(fā)生事件的關(guān)注。通過(guò)看板，每個(gè)工人（不是管理人員）都可以看到生產(chǎn)流程，進(jìn)而有機會(huì )發(fā)現其中的浪費，并建議改進(jìn)他們所在的工序。圖3為以上9個(gè)特性之間的相互影響，它顯示了如何將這些組成一個(gè)因果效應網(wǎng)絡(luò )。你從中可以看到看板的兩種含義，一是“在維持連續流通的同時(shí)限制在制品數量”，而另一種是“改善”。
圖3 看板的特性和作用
圖表右側說(shuō)明了如何在維持連續流通的同時(shí)，最大限度地減少在制品。如果倉庫中的在制品太少的話(huà)，下游工序不得不等待所需的零部件準備就緒，但是在制品還應該保證最小化以防止生產(chǎn)過(guò)剩。這樣看來(lái)這兩個(gè)目標是相矛盾的，而看板正被看作是解決這個(gè)難題的策略。看板附著(zhù)于零部件，并且可以被收集和重用，因此看板的數量是固定的。而且看板還可以直觀(guān)地指示下游工序僅當需要時(shí)才獲取零部件。這里有兩種限定在制品數量的機制。
第一個(gè)機制“附著(zhù)的看板”工作機制同“能量守恒定律”類(lèi)似。一旦根據產(chǎn)品市場(chǎng)銷(xiāo)售的速度和當前工序的內在變化規律確定了看板的數量，那么不管零部件的流入和流出如何，在制品的數量都被限制為看板數量的一定比例。在任何時(shí)候，看板（相當于系統中的“能量”）的最大數量都與在制品的上限保持守恒。在圖4中，你可以看到“系統”指的是上游工序和下游工序之間的庫存，也就是“倉庫”中的在制品。
圖4 限定在制品數量的看板機制
第二個(gè)機制——“拉動(dòng)式”——通過(guò)依據下游消耗速度來(lái)確定上游工序的生產(chǎn)速度，這種機制也限制了在制品的數量。第一個(gè)機制僅僅涉及到在制品的數量，而第二個(gè)則涉及到流程——流程的方向和速度。“方向”——僅由下游工序來(lái)驅動(dòng)生產(chǎn)。
“速度”——通過(guò)看板傳達下次生產(chǎn)的時(shí)機和數量。
通過(guò)確保上游工序的生產(chǎn)以下游工序首次衍生訂單中的消耗為依據，“拉動(dòng)式”限制了在制品的數量。通過(guò)在倉庫中交換看板，將生產(chǎn)控制信息從下游推到上游，這種依賴(lài)性便得以實(shí)現。
回到圖3：圖表左側說(shuō)明了如何促使工作自導向并促進(jìn)改善。通過(guò)查看張貼在面板上的看板卡，每個(gè)人都可以了解到發(fā)生了什么事，以及工序運轉的健康狀態(tài)。改善起始于對現場(chǎng)（Gemba）工作流的觀(guān)測。放置于面板之上的看板卡直觀(guān)地幫助工作在沒(méi)有中央控制管理之下自導向。為了支持改善，這種自治的工序向外提供其性能數據，并將管理重點(diǎn)從對具體工作的指派或者調度上轉移到改善活動(dòng)。
圖3中的箭頭最終都指向了三個(gè)結果，如其所示，看板的終極目標可以表示為“限制在制品數量”、“連續流通”和“改善”?？窗逑到y在維持“連續流通”的同時(shí)“限制在制品數量”。它緩沖由普通變因引起的變化情況，并暴露特殊變因引起的變化情況，以備改善。
現在，讓我們將視線(xiàn)回到我們自己的工作領(lǐng)域——軟件開(kāi)發(fā)。在敏捷軟件開(kāi)發(fā)中，通過(guò)在項目工作場(chǎng)所的墻上張貼卡片來(lái)呈現和分享項目狀態(tài)已經(jīng)成為一種常見(jiàn)的實(shí)踐。我已經(jīng)在我的上一篇InfoQ文章《用“看板圖”實(shí)現敏捷項目的可視化》[Hiranabe07]給出了很多例子。特別是，貼在墻上用來(lái)展示當前項目狀態(tài)的任務(wù)卡片有時(shí)也被稱(chēng)作“任務(wù)看板”或者“軟件看板”[Poppendieck03]。圖5是Change Vision公司的JUDE6開(kāi)發(fā)團隊所用的任務(wù)看板。
圖5 敏捷看板
在面板上，工程任務(wù)用卡片（即時(shí)貼）來(lái)代表，并通過(guò)把卡片貼在在面板中的不同區域來(lái)象征任務(wù)的狀態(tài)，這些區域被標注為“ToDo”、“Doing”和“Done”（標注的名稱(chēng)可能因地而異，比如“進(jìn)行中（In Progress）”、“已測試（Tested）”、“已驗收（Accepted）”、“停滯中（Blocking）”等等。）。這樣的看板面板有利于可視化地通知任務(wù)并限制在制品（處理中的任務(wù)）數量。不過(guò)在這里并沒(méi)有出現“工序”（上游或者下游），新出現的概念是“迭代”。對于每一次迭代，通過(guò)分解用戶(hù)故事識別出任務(wù)，并且將其張貼在面板的ToDo區域中。
這是一個(gè)拉動(dòng)式系統嗎？在制造業(yè)中，零部件由上游工序傳遞至下游工序。而在圖5所示的敏捷開(kāi)發(fā)中，并沒(méi)有看到“移交物”。一個(gè)看板卡片對應一個(gè)任務(wù)，上面寫(xiě)明了如下信息：任務(wù)編號、任務(wù)名稱(chēng)、估計時(shí)間以及任務(wù)領(lǐng)取人的名字。任務(wù)有狀態(tài)，可以是“ToDo”、“Doing”或者“Done”，狀態(tài)信息被分享給整個(gè)團隊。敏捷開(kāi)發(fā)重視在一起工作，并趨向于減少團隊內部的移交物。我稱(chēng)此為“敏捷看板”。
圖6是另一個(gè)看板面板實(shí)例，由Yamaha Motor Solution有限公司7所采用。
圖6 持續看板（Sustaining Kanban）
在這里，看板系統被用于帶有流程的傳統瀑布開(kāi)發(fā)模型。項目被分解成“設計”、“開(kāi)發(fā)”、“驗證”等連續的工序，而看板卡就在這些工序之間移動(dòng)。每張卡片代表需要修改或者添加的系統需求，也代表給下游工序的移交物。注意這不是一個(gè)標準的瀑布流程——標準瀑布流程中所有的需求在同一時(shí)間內完成“設計”，而“開(kāi)發(fā)”和“驗證”則在另一時(shí)間，這將使得所有的卡片作為一個(gè)整體進(jìn)行移動(dòng)。與標準的瀑布流程不同的是，這個(gè)項目中的卡片是一個(gè)接一個(gè)地移動(dòng)，就像制造業(yè)中的單件流（one-piece-flow）一樣。這里表現的是產(chǎn)品生命周期里穩定的“持續（sustaining）”階段，處在帶有流程的瀑布狀態(tài)轉換模型的管理之下。在這里，你可以清楚地看到“工作流程”的概念，而不同于敏捷中的“迭代”概念。它比敏捷看板看起來(lái)更像工廠(chǎng)中的看板，而且通過(guò)制定規則只允許下游工序移動(dòng)卡片8，可以使其成為拉動(dòng)式系統。我稱(chēng)其為“持續看板”，這與稍后章節中討論的David Anderson的“持續工程的看板系統”是類(lèi)似的。
圖7顯示的是另外一個(gè)例子——在整個(gè)產(chǎn)品開(kāi)發(fā)流程的價(jià)值流中使用看板的思想實(shí)驗（thought experiment）[Poppendieck 07]。
圖7 精益+敏捷看板
假設在一個(gè)產(chǎn)品開(kāi)發(fā)流中有客戶(hù)團隊、產(chǎn)品所有人、開(kāi)發(fā)團隊和QA團隊，他們使用隊列傳遞移交物來(lái)協(xié)調工作，以使得團隊之間能異步工作，并維持工作速度。每一個(gè)“DONE”空間是一個(gè)隊列，其工作方式就像制造工廠(chǎng)中的“倉庫”那樣，并且看起來(lái)非常像TPS看板系統。同時(shí)，它看起來(lái)就像每條工序內同步地使用敏捷看板，而在貫穿各個(gè)工序的整個(gè)價(jià)值流上異步地使用持續看板。我認為看板系統可以擴展至覆蓋整個(gè)價(jià)值流，在這種情況下，它是價(jià)值流的一個(gè)活生生的視覺(jué)表現。
在這里例子中，通過(guò)設定每一個(gè)區域的大小可以限制在制品的數量。而為了使其變成拉動(dòng)式系統，還需要一種機制來(lái)使下游工序以某種信號通知上游工序開(kāi)始工作。其中一種方法是制定一個(gè)規則只允許下游移動(dòng)DONE區域中的卡片來(lái)通知上游。另一種方法是定期召開(kāi)“迭代會(huì )議”，來(lái)同步團隊和團隊之間傳遞（通訊）的信息。這兩種通訊方式可能對應于我們在第一章節中討論的零部件領(lǐng)取的兩種信號，即領(lǐng)取看板的數量（a）和時(shí)間間隔（b）的可視信號。一次迭代中的一組用戶(hù)故事對應于迭代中托盤(pán)里的零部件，而零部件的數量對應于迭代中的項目“生產(chǎn)率”（昨日天氣[Beck00]）。我叫它為“精益+敏捷看板”，如下一個(gè)例子展示的那樣它可以與“敏捷看板”相結合。
圖8中是一個(gè)小型的“便攜式”看板系統，這是我在CENTRAL COMPUTER SERVICES有限公司的某個(gè)項目里發(fā)現的。在這個(gè)項目中，團隊被分為了幾個(gè)小型子團隊（通常是一對人）。整個(gè)團隊有一個(gè)與圖7概念相似的工作流，還有圖8所示的小型敏捷看板面板（ToDo、Doing、DONE）。 當一個(gè)子團隊選取了一個(gè)用戶(hù)故事，他們將其分解到任務(wù)并張貼在便攜式看板面板上。在這種情況下，看板系統由兩個(gè)層面組成，在項目層面一張卡片代表一個(gè)用戶(hù)故事，而在團隊（或者結對）層面一張卡片代表一個(gè)任務(wù)。
他們很喜歡這個(gè)便攜式小型看板系統，并命名為“看板nano”。
圖8 便攜式敏捷看板（“看板nano”）
如你所見(jiàn)，將看板的概念應用于軟件開(kāi)發(fā)有許多方式。“敏捷看板”用來(lái)在團隊中分享信息并使工作自導向，但它不支持流程。“持續看板”是另一種類(lèi)型的看板，能夠讓小批量的維護工作在幾個(gè)狀態(tài)之間流轉。這種結合便是“精益+敏捷看板”，使用“持續看板”貫穿價(jià)值流，同時(shí)在子流（sub-stream）中使用“敏捷看板”。
注意，圖5中的“敏捷看板”（在當今敏捷項目中隨處可見(jiàn)）僅僅可以看到價(jià)值流中的一個(gè)子流。當你考慮從客戶(hù)到客戶(hù)的完整價(jià)值流，經(jīng)常由處于同一流中的某個(gè)團隊遞交給你需求，而另一個(gè)團隊則交付你的工作結果給客戶(hù)。這篇文章的目的之一，就是要設法讓看板的應用超越“敏捷看板”，擴大看板在價(jià)值流中的應用范圍。
軟件開(kāi)發(fā)是不同于生產(chǎn)活動(dòng)或者制造活動(dòng)的。軟件工程師每次創(chuàng )造的產(chǎn)物都是不同的，而制造業(yè)總是周而復始的生產(chǎn)相同的東西。所以直接將兩者等同起來(lái)是危險的?？墒?，讓我們研究一下如何在軟件開(kāi)發(fā)看板中找到TPS看板中的特性。表1顯示了我們在章節1中總結的看板特性在我們已經(jīng)提及的兩種軟件看板中是否仍然有效。
圖6中的“持續看板”不僅可以限制在制品的數量，還可以以“單件（one-piece）”和“拉動(dòng)式”的方式控制流程，而不需要召開(kāi)迭代會(huì )議。在這種方法中，它的關(guān)注點(diǎn)是“限制在制品的數量”、“連續流通”和“拉動(dòng)式”，同時(shí)允許團隊（或者管理人員）借其改進(jìn)工序。
回顧一下圖3，我將看板的特性和作用分成圖9所示的兩個(gè)關(guān)鍵區域，以便上面提到的兩類(lèi)軟件看板概念的用途各得其所。圖10顯示了生產(chǎn)和開(kāi)發(fā)的頻譜圖。生產(chǎn)是成功幾率很高（高于99%）的工序，而開(kāi)發(fā)的成功幾率要低。當成功幾率在50%左右的時(shí)候敏捷是理想的開(kāi)發(fā)方法，而當成功幾率超過(guò)90%的時(shí)候瀑布式則是理想的開(kāi)發(fā)方式（依據Shannon理論，一個(gè)具有50%成功幾率的項目是最有價(jià)值的項目）。通常隨著(zhù)開(kāi)發(fā)進(jìn)入到支持維護狀態(tài)，修改缺陷和添加新功能的成功幾率逐步提高。
看板系統的“工序控制焦點(diǎn)（Process Control Focus）”適合在“高于90%”的成功率下工作，而“工序改進(jìn)焦點(diǎn)（Process Improvement Focus）”既適合在50%成功率也適合在90%成功率下工作。
值得注意的是，敏捷方法在產(chǎn)品維護狀態(tài)（sustaining mode ）下仍能工作良好，同樣看板的“工序改進(jìn)焦點(diǎn)”特性也在維護狀態(tài)下工作良好。
圖9 看板的特性和作用（2）
圖10 使用看板的方法頻譜
接下來(lái)，我介紹最近出現的一種軟件開(kāi)發(fā)精益應用。Agile2007會(huì )議時(shí)，我參加了David Anderson主持的關(guān)于軟件看板的一個(gè)會(huì )中會(huì )（Conference-Within-A-Conference，CWAC）。他在Corbis.com管理著(zhù)一個(gè)“維護狀態(tài)（maintenance mode）”類(lèi)型的看板系統，并發(fā)表了一篇相關(guān)論文——持續工程的看板系統[Anderson 07]。他的方法首先關(guān)注于看板的“限制在制品數量”特性——就像在圖4所示的抽象圖表那樣——也關(guān)注“自導向”特性以使得團隊自組織，減少自上而下的（top-down）管理。然后，通過(guò)看板觀(guān)察流程，找出整個(gè)工序流中的駐點(diǎn)（stagnation point）并調整人力資源，也就是在工序間調動(dòng)成員。這意味著(zhù)他的方法，像圖3表現的那樣，涵蓋了看板特性中從“限制在制品數量”、“自導向”到“改善”。
會(huì )議之后，Anderson啟動(dòng)了一個(gè)看板開(kāi)發(fā)郵件列表2，這里已經(jīng)成為將看板應用于軟件開(kāi)發(fā)的一個(gè)新興知識創(chuàng )新討論社區，名為“KSSE”——持續工程的看板系統，讀作Kiss-ee ;-)。Aaron Sanders還著(zhù)手創(chuàng )建關(guān)于看板的知識體系，并已經(jīng)開(kāi)始構建KSSE詞匯表。
KSSE對于通過(guò)隊列在工序間傳遞移交物、連續相接的多個(gè)工序運作良好。請注意KSSE不一定需要納入“迭代”的概念。使用KSSE的方式，我看到了另一種縮放（scaling）敏捷的可能性方式并且好過(guò)“scrum of scrums”。[Ladas07]
當通過(guò)看板從敏捷放大到精益時(shí)，一張看板卡應該代表什么東西呢？
在敏捷看板系統中，一個(gè)卡片是一個(gè)從“用戶(hù)故事”中分解出來(lái)的“任務(wù)”。在開(kāi)發(fā)團隊中，它作為工作的一個(gè)基本單元執行，因為團隊中每個(gè)人都能明白它的意思。但是，在看板系統中它貫穿了價(jià)值流中的多個(gè)工序（多個(gè)團隊），在其中流轉之物應該帶有客戶(hù)認可的價(jià)值。既然這樣，看板卡片就不是對應于“工作（work）”而是對應于“功能（feature）”，并且它不是WBS（任務(wù)分解結構，work breakdown structure）的組成部分，而是FBS（功能分解結構，feature breakdown structure）的組成部分。因此團隊中的每個(gè)人，甚至是客戶(hù)，都能夠理解看板的含義和流轉之物的價(jià)值。Jim Highsmith 在《敏捷項目管理（Agile Project Management）》[Highsmith04]書(shū)中所概述的原理也將FBS定位高于WBS。
“用戶(hù)故事”，“Backlog事項”或者“用例”都被抽象為“MMF”（最小可市場(chǎng)化功能，minimum marketable features），用來(lái)明確地聲明流轉之物具有客戶(hù)價(jià)值。于是精益開(kāi)發(fā)就可以說(shuō)成“使得MMF快速流過(guò)整個(gè)價(jià)值流。”圖5中“敏捷看板”的例子是一個(gè)工作的分解，它在團隊內部工作良好。圖6中“持續看板”的例子是一個(gè)功能的分解并且一張卡片代表一個(gè)MMF。圖7中“精益+敏捷看板”的例子與圖8一起展示了上級功能分解和下級工作分解的結合。
一旦建立起工作流程，五個(gè)“精益思想”[Womack1996]的核心概念就可直接應用于整個(gè)工序。精益工序的管理可以簡(jiǎn)單地遵循以下原則。以下內容相當于附錄，我在這一部分分享從TPS中學(xué)到，并發(fā)現可以適用于軟件開(kāi)發(fā)的知識。Mary和Tom Poppendieck已經(jīng)發(fā)現有效的軟件開(kāi)發(fā)方式和精益或者TPS方法有著(zhù)很多的相同點(diǎn)——不是在實(shí)踐層面，而是在原理層面上[Poppendieck03, 07]。讓我們從更高的角度回過(guò)頭來(lái)再看下TPS中的看板。
讀者很容易假定看板是整個(gè)TPS的中心，但其實(shí)并不是。圖11展示了TPS的概念結構，有時(shí)也叫做“TPS之屋（TPS House）”。它有好幾種版本，圖11是基于Toshiko Narusawa和John Shook的版本[Narusawa06]。在TPS中，看板僅僅是“拉動(dòng)式系統”實(shí)現準時(shí)制（Just-In-Time9）的一種方法。準時(shí)制可以解釋為“僅在需要的時(shí)候生產(chǎn)和交付所需要的東西，并且僅完成需要的數量”。它直接瞄準的是客戶(hù)的需要：“盡快以最低的價(jià)格提供最高質(zhì)量的產(chǎn)品。”注意，準時(shí)制是TPS的兩大支柱之一，另一個(gè)是Jidoka10（譯注：寫(xiě)作“自動(dòng)化/自?xún)P化”，但其含義與對應于A(yíng)utomation的中文的“自動(dòng)化”不同，詳見(jiàn)注釋?zhuān)?。制造業(yè)中的“Jidoka”即自動(dòng)停機（Autonomation）與軟件開(kāi)發(fā)中的測試驅動(dòng)開(kāi)發(fā)類(lèi)似。Mary和Tom Poppendieck把Jidoka解釋為“停止流水線(xiàn)文化（Stop the Line Culture）”。豐田工廠(chǎng)的工人真正地可以停止流水線(xiàn)而不是把次品推到下一個(gè)工序——它不僅是一種規定，也是豐田公司的一種文化，它的萌芽可以追溯到（豐田集團創(chuàng )始人）豐田佐吉時(shí)期。
圖11 TPS概念結構
準時(shí)制由以下三部分元素構成，“節拍時(shí)間（Takt time）”、“連續流通”和“拉動(dòng)式系統”。
也應該注意到兩個(gè)支柱依賴(lài)于改善和人。豐田一年生產(chǎn)近千萬(wàn)輛汽車(chē)，同時(shí)，他們通過(guò)在現場(chǎng)（也就是車(chē)間）中近1百萬(wàn)次的改善來(lái)完善他們的工序。形象化地表示出團隊正在做些什么，總是改善的出發(fā)點(diǎn)。
文中，我分析了看板在制造業(yè)的實(shí)施，接著(zhù)列出了看板的特性?？窗逑到y用以達到以下目標：
“敏捷看板”專(zhuān)注于#2，而“持續看板”專(zhuān)注于#1。我提出將兩者結合，來(lái)拓展可視化和“拉動(dòng)式系統”到整個(gè)價(jià)值流，以使得整個(gè)生產(chǎn)精益化。
Tom Poppendieck與Mary對本文進(jìn)行了通篇審校，并給出了許多見(jiàn)解和建議，在此我表示非常感謝。感謝Yamaha Motor Solution有限公司總裁Yasuharu Terai以及Ryuichi Sato允許本文中使用其看板系統的圖片。另外David Anderson也參與了本文的審校工作并且提出了一個(gè)更好的看板抽象層次來(lái)推進(jìn)KSSE的發(fā)展。KSSE概念最初來(lái)源于Kanbandev Yahoo團隊的討論。最后感謝Deborah Hartmann的最后校訂工作，使得我的表達更清晰。
Kenji HIRANABE是日本Change Vision公司的CEO。他是JUDE（一個(gè)集成了ERD、DFD和Mind Map的UML編輯器）和TRICHORD 11（一個(gè)集成了Burndown圖表和Parking Lots圖的敏捷項目管理看板系統）的創(chuàng )始人。他還把《Lean Software Development》、《XP Installed》、《Agile Project Management》以及其他XP/Agile書(shū)籍翻譯成日文。Kenji把軟件開(kāi)發(fā)看作是一種溝通游戲，并一直在尋求提高軟件開(kāi)發(fā)的生產(chǎn)效率、合作程度以及樂(lè )趣的途徑。
聯(lián)系客服
