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

圖6中的“持續看板”不僅可以限制在制品的數量，還可以以“單件（one-piece）”和“拉動式”的方式控制流程，而不需要召開迭代會議。在這種方法中，它的關注點是“限制在制品的數量”、“連續流通”和“拉動式”，同時允許團隊（或者管理人員）借其改進工序。

回顧一下圖3，我將看板的特性和作用分成圖9所示的兩個關鍵區域，以便上面提到的兩類軟件看板概念的用途各得其所。圖10顯示了生產和開發的頻譜圖。生產是成功幾率很高（高于99%）的工序，而開發的成功幾率要低。當成功幾率在50%左右的時候敏捷是理想的開發方法，而當成功幾率超過90%的時候瀑布式則是理想的開發方式（依據Shannon理論，一個具有50%成功幾率的項目是最有價值的項目）。通常隨著開發進入到支持維護狀態，修改缺陷和添加新功能的成功幾率逐步提高。

看板系統的“工序控制焦點（Process Control Focus）”適合在“高于90%”的成功率下工作，而“工序改進焦點（Process Improvement Focus）”既適合在50%成功率也適合在90%成功率下工作。

值得注意的是，敏捷方法在產品維護狀態（sustaining mode ）下仍能工作良好，同樣看板的“工序改進焦點”特性也在維護狀態下工作良好。

圖9 看板的特性和作用（2）

圖10 使用看板的方法頻譜

KSSE——持續工程的看板系統

接下來，我介紹最近出現的一種軟件開發精益應用。Agile2007會議時，我參加了David Anderson主持的關于軟件看板的一個會中會（Conference-Within-A-Conference，CWAC）。他在Corbis.com管理著一個“維護狀態（maintenance mode）”類型的看板系統，并發表了一篇相關論文——持續工程的看板系統[Anderson 07]。他的方法首先關注于看板的“限制在制品數量”特性——就像在圖4所示的抽象圖表那樣——也關注“自導向”特性以使得團隊自組織，減少自上而下的（top-down）管理。然后，通過看板觀察流程，找出整個工序流中的駐點（stagnation point）并調整人力資源，也就是在工序間調動成員。這意味著他的方法，像圖3表現的那樣，涵蓋了看板特性中從“限制在制品數量”、“自導向”到“改善”。

會議之后，Anderson啟動了一個看板開發郵件列表2，這里已經成為將看板應用于軟件開發的一個新興知識創新討論社區，名為“KSSE”——持續工程的看板系統，讀作Kiss-ee ;-)。Aaron Sanders還著手創建關于看板的知識體系，并已經開始構建KSSE詞匯表。

KSSE對于通過隊列在工序間傳遞移交物、連續相接的多個工序運作良好。請注意KSSE不一定需要納入“迭代”的概念。使用KSSE的方式，我看到了另一種縮放（scaling）敏捷的可能性方式并且好過“scrum of scrums”。[Ladas07]

創造價值流

當通過看板從敏捷放大到精益時，一張看板卡應該代表什么東西呢？

在敏捷看板系統中，一個卡片是一個從“用戶故事”中分解出來的“任務”。在開發團隊中，它作為工作的一個基本單元執行，因為團隊中每個人都能明白它的意思。但是，在看板系統中它貫穿了價值流中的多個工序（多個團隊），在其中流轉之物應該帶有客戶認可的價值。既然這樣，看板卡片就不是對應于“工作（work）”而是對應于“功能（feature）”，并且它不是WBS（任務分解結構，work breakdown structure）的組成部分，而是FBS（功能分解結構，feature breakdown structure）的組成部分。因此團隊中的每個人，甚至是客戶，都能夠理解看板的含義和流轉之物的價值。Jim Highsmith 在《敏捷項目管理（Agile Project Management）》[Highsmith04]書中所概述的原理也將FBS定位高于WBS。

“用戶故事”，“Backlog事項”或者“用例”都被抽象為“MMF”（最小可市場化功能，minimum marketable features），用來明確地聲明流轉之物具有客戶價值。于是精益開發就可以說成“使得MMF快速流過整個價值流。”

圖5中“敏捷看板”的例子是一個工作的分解，它在團隊內部工作良好。圖6中“持續看板”的例子是一個功能的分解并且一張卡片代表一個MMF。圖7中“精益+敏捷看板”的例子與圖8一起展示了上級功能分解和下級工作分解的結合。

一旦建立起工作流程，五個“精益思想”[Womack1996]的核心概念就可直接應用于整個工序。精益工序的管理可以簡單地遵循以下原則。

• 從客戶的角度定義價值——確定和分類MMF
• 明確價值流并消除浪費——找出駐點（停滯的任務）
• 在客戶的拉動下創造價值流——制定看板的拉動規則
• 關注員工并給予一定的權力——授權給在現場的團隊
• 追求完美的持續改善——反省和改善

TPS全景視圖

以下內容相當于附錄，我在這一部分分享從TPS中學到，并發現可以適用于軟件開發的知識。Mary和Tom Poppendieck已經發現有效的軟件開發方式和精益或者TPS方法有著很多的相同點——不是在實踐層面，而是在原理層面上[Poppendieck03, 07]。讓我們從更高的角度回過頭來再看下TPS中的看板。

讀者很容易假定看板是整個TPS的中心，但其實并不是。圖11展示了TPS的概念結構，有時也叫做“TPS之屋（TPS House）”。它有好幾種版本，圖11是基于Toshiko Narusawa和John Shook的版本[Narusawa06]。在TPS中，看板僅僅是“拉動式系統”實現準時制（Just-In-Time9）的一種方法。準時制可以解釋為“僅在需要的時候生產和交付所需要的東西，并且僅完成需要的數量”。它直接瞄準的是客戶的需要：“盡快以最低的價格提供最高質量的產品。”注意，準時制是TPS的兩大支柱之一，另一個是Jidoka10（譯注：寫作“自動化/自働化”，但其含義與對應于Automation的中文的“自動化”不同，詳見注釋）。制造業中的“Jidoka”即自動停機（Autonomation）與軟件開發中的測試驅動開發類似。Mary和Tom Poppendieck把Jidoka解釋為“停止流水線文化（Stop the Line Culture）”。豐田工廠的工人真正地可以停止流水線而不是把次品推到下一個工序——它不僅是一種規定，也是豐田公司的一種文化，它的萌芽可以追溯到（豐田集團創始人）豐田佐吉時期。

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