將看板應用于軟件開發：從敏捷到精益(3)

這是一個拉動式系統嗎？在制造業中，零部件由上游工序傳遞至下游工序。而在圖5所示的敏捷開發中，并沒有看到“移交物”。一個看板卡片對應一個任務，上面寫明了如下信息：任務編號、任務名稱、估計時間以及任務領取人的名字。任務有狀態，可以是“ToDo”、“Doing”或者“Done”，狀態信息被分享給整個團隊。敏捷開發重視在一起工作，并趨向于減少團隊內部的移交物。我稱此為“敏捷看板”。

圖6是另一個看板面板實例，由Yamaha Motor Solution有限公司所采用。

圖6 持續看板（Sustaining Kanban）

在這里，看板系統被用于帶有流程的傳統瀑布開發模型。項目被分解成“設計”、“開發”、“驗證”等連續的工序，而看板卡就在這些工序之間移動。每張卡片代表需要修改或者添加的系統需求，也代表給下游工序的移交物。注意這不是一個標準的瀑布流程——標準瀑布流程中所有的需求在同一時間內完成“設計”，而“開發”和“驗證”則在另一時間，這將使得所有的卡片作為一個整體進行移動。與標準的瀑布流程不同的是，這個項目中的卡片是一個接一個地移動，就像制造業中的單件流（one-piece-flow）一樣。這里表現的是產品生命周期里穩定的“持續（sustaining）”階段，處在帶有流程的瀑布狀態轉換模型的管理之下。在這里，你可以清楚地看到“工作流程”的概念，而不同于敏捷中的“迭代”概念。它比敏捷看板看起來更像工廠中的看板，而且通過制定規則只允許下游工序移動卡片8，可以使其成為拉動式系統。我稱其為“持續看板”，這與稍后章節中討論的David Anderson的“持續工程的看板系統”是類似的。

圖7顯示的是另外一個例子——在整個產品開發流程的價值流中使用看板的思想實驗（thought experiment）[Poppendieck 07]。

圖7 精益+敏捷看板

假設在一個產品開發流中有客戶團隊、產品所有人、開發團隊和QA團隊，他們使用隊列傳遞移交物來協調工作，以使得團隊之間能異步工作，并維持工作速度。每一個“DONE”空間是一個隊列，其工作方式就像制造工廠中的“倉庫”那樣，并且看起來非常像TPS看板系統。同時，它看起來就像每條工序內同步地使用敏捷看板，而在貫穿各個工序的整個價值流上異步地使用持續看板。我認為看板系統可以擴展至覆蓋整個價值流，在這種情況下，它是價值流的一個活生生的視覺表現。

在這里例子中，通過設定每一個區域的大小可以限制在制品的數量。而為了使其變成拉動式系統，還需要一種機制來使下游工序以某種信號通知上游工序開始工作。其中一種方法是制定一個規則只允許下游移動DONE區域中的卡片來通知上游。另一種方法是定期召開“迭代會議”，來同步團隊和團隊之間傳遞（通訊）的信息。這兩種通訊方式可能對應于我們在第一章節中討論的零部件領取的兩種信號，即領取看板的數量（a）和時間間隔（b）的可視信號。一次迭代中的一組用戶故事對應于迭代中托盤里的零部件，而零部件的數量對應于迭代中的項目“生產率”（昨日天氣[Beck00]）。我叫它為“精益+敏捷看板”，如下一個例子展示的那樣它可以與“敏捷看板”相結合。

圖8中是一個小型的“便攜式”看板系統，這是我在CENTRAL COMPUTER SERVICES有限公司的某個項目里發現的。在這個項目中，團隊被分為了幾個小型子團隊（通常是一對人）。整個團隊有一個與圖7概念相似的工作流，還有圖8所示的小型敏捷看板面板（ToDo、Doing、DONE）。 當一個子團隊選取了一個用戶故事，他們將其分解到任務并張貼在便攜式看板面板上。在這種情況下，看板系統由兩個層面組成，在項目層面一張卡片代表一個用戶故事，而在團隊（或者結對）層面一張卡片代表一個任務。

他們很喜歡這個便攜式小型看板系統，并命名為“看板nano”。

圖8 便攜式敏捷看板（“看板nano”）

如你所見，將看板的概念應用于軟件開發有許多方式。“敏捷看板”用來在團隊中分享信息并使工作自導向，但它不支持流程。“持續看板”是另一種類型的看板，能夠讓小批量的維護工作在幾個狀態之間流轉。這種結合便是“精益+敏捷看板”，使用“持續看板”貫穿價值流，同時在子流（sub-stream）中使用“敏捷看板”。

注意，圖5中的“敏捷看板”（在當今敏捷項目中隨處可見）僅僅可以看到價值流中的一個子流。當你考慮從客戶到客戶的完整價值流，經常由處于同一流中的某個團隊遞交給你需求，而另一個團隊則交付你的工作結果給客戶。這篇文章的目的之一，就是要設法讓看板的應用超越“敏捷看板”，擴大看板在價值流中的應用范圍。

生產與開發

軟件開發是不同于生產活動或者制造活動的。軟件工程師每次創造的產物都是不同的，而制造業總是周而復始的生產相同的東西。所以直接將兩者等同起來是危險的?？墒?，讓我們研究一下如何在軟件開發看板中找到TPS看板中的特性。表1顯示了我們在章節1中總結的看板特性在我們已經提及的兩種軟件看板中是否仍然有效。

圖5所示的敏捷看板例子本身并沒有實現“限制在制品的數量”、“連續流通”和“拉動式”特性。敏捷看板更關注于實現任務、“可視化”和“自導向”，以便幫助團隊自治并改進其工序。為了使工序連續流通并限制在制品的數量，需要召開“迭代會議”交流信息。

原文轉自：http://www.anti-gravitydesign.com