此文是《談談精益（上篇）——Lean Manufacturing》的續(xù)篇。
先說說精益軟件開發(fā)
制造業(yè)的成功，已經證明了精益思想的強大。非常自然地，軟件行業(yè)的從業(yè)者，也希望能夠汲取精益的理念，來消除軟件開發(fā)中存在的浪費，從而能夠成功的交付客戶價值，獲得更高的軟件成功率。這其中的先驅者，當屬Mary and Tom Poppendieck夫婦。他們出了一本書，名字就是《Lean Software Development》，內容則是如何將精益思想落地于軟件行業(yè)中，來影響現(xiàn)有軟件開發(fā)行業(yè)的形勢。
這里，我們參考制造業(yè)的DOTWIMP，來思考對應軟件行業(yè)的DOTWIMP。希望通過這些原則，來具體指導如何精益地做軟件開發(fā)——消除浪費（Eliminate Waste）
Defect (Defect)
軟件行業(yè)中的缺陷，是一個非常普遍的概念。代碼或者系統(tǒng)中任何與預期不符的情況，都可以稱為缺陷。很明顯，缺陷是一種不為客戶帶來價值，反而會造成巨大浪費的事物。發(fā)現(xiàn)缺陷，會造成QA的工作量，修復缺陷，會帶來開發(fā)的重復工作。根據(jù)Lean的原則，我們需要從根本上去除缺陷的產生，而不是事后花費成本修補。并且，當我們捕捉到一個未覆蓋的缺陷時，我們需要發(fā)現(xiàn)缺陷背后的根本原因，從而保證這個缺陷不會再次出現(xiàn)，不會引入重復的浪費。
單元測試和集成測試，就是保證代碼從一開始不引入缺陷的實踐之一。誠然，自測試代碼中的測試部分，本身確實對于客戶來說，沒有價值，也是一種浪費。但是，這種開發(fā)級別引入的浪費，是為了避免后期更大的浪費出現(xiàn)。在軟件開發(fā)的開發(fā)部署流程中，一個缺陷越晚被發(fā)現(xiàn)，定位并修復的成本會越高，也就意味著浪費會更大。
Extra features (Over-production)
作為開發(fā)，總是抑制不住沖動，希望軟件不僅能夠滿足當下的需求，當未來有新的需求出現(xiàn)時，也能成功應對。但是，額外的需求功能，也是一種浪費，因為它沒有對客戶產生價值，但仍需要開發(fā)人員花費成本維護和測試。
埃里克萊斯是《精益創(chuàng)業(yè)》一書的作者，書中說到：
最大的浪費是構建沒人在乎的東西。
做一個能賣出去的產品，而不是賣一個做出來的產品。
Handoff 交接 (Transportation)
任何曾工作在瀑布軟件開發(fā)方式下的人都對“交接”這個詞印象深刻。BA在寫好一個很大的需求文檔之后，交接給架構師；架構師在做好設計并完成設計文檔之后，交接給開發(fā)團隊；開發(fā)寫完代碼之后，交接給QA團隊。在每次交接的過程中，知識不可能全部傳下去，會丟失相當一部分。這樣，開發(fā)人員腦子中的需求，和BA的理解可能大相徑庭。
這就是為什么敏捷團隊和SCRUM都倡導全功能團隊：團隊中應包含各個角色，BA、DEV、QA、PM、UX。這樣避免了交接帶來的浪費，促進了不同角色之間知識的充分分享。
Delay (Wait)
項目進行中任何拖延，都是一種浪費。比如當團隊某成員提出一個問題，而能夠回答這個問題的人并不能輕易的被找到的時候，這時候Delay產生了，從而浪費也產生了。
Partially completed work (Inventory)
從BA開始準備一個Story的需求描述，到最后達到能夠達到上線的狀態(tài)，中間過程中的Story都被看做是未完成的工作。除非上線，否則不論Story處于任何狀態(tài)，都沒有為客戶產生價值。未完成的工作，還有可能推遲了發(fā)現(xiàn)問題的時間。
Task Switching (Motion)
沒人什么事情比讓一個人同時做多件事，更能降低一個人的效率的了。當開發(fā)人員同時做好幾個Story的時候，頻繁的切換上下文，會造成額外的消耗，但并不增加任何價值。提高效率的最好辦法，就是集中精力解決一個問題，然后再解決下一個問題。
Unneeded processes (Processes)
你有沒有曾經遭遇過這樣的經歷，為了對生產環(huán)境做出一點微小的環(huán)境改變，但需要經歷一個漫長的審批過程，等待好幾個人的簽字？很多公司都有這樣冗長的機制，并且經歷過的人都知道，為了完成一點點的改變，過程是多么的痛苦。這種不必要的流程，沒有為客戶增加過多的價值，但是卻引入了相當大的浪費。
什么是看板方法
看板方法是用于管理軟件開發(fā)流程的新技術。看板方法源自豐田的“及時生產”（JIT=just-in-time）系統(tǒng)（在前文中我對JIT解釋如下：Just-In-Time努力將生產過程中每一步的庫存量盡量降到最低，最好為0。換句話說，這意味著只需要在合適的時間、合適的地點，提供適量的原材料。去除庫存帶來很多好處：不僅可以節(jié)省成本，還去除了商品被廢棄或者損壞，久置的可能性。）
一個軟件開發(fā)的流程可以看作是一段自來水管道，特性需求從一端進入，經過開發(fā)的軟件從另一端涌現(xiàn)出來。
在管道內部，存在著各種各樣的工序，我們先假設一個最為簡單的階段性流程：
分析需求->開發(fā)代碼->測試軟件運行正常
在管道中的瓶頸會限制工作的流動。管道的整體吞吐量被限制為瓶頸的吞吐量。用我們的開發(fā)管道為例：如果測試人員每周只能測試5個特性，而開發(fā)人員和分析人員每周能夠生產10個特性，整個管道的吞吐量就只有每周5個特性 ，因為測試人員扮演了瓶頸角色。如果分析人員和開發(fā)人員不知道測試人員是瓶頸，那么測試人員的待辦工作就會越堆積越多。
影響就是前置時間增加。并且，就如同庫存一樣：位于管道中的工作會套牢投入的資金、產生與市場的距離、庫存中的產品（交付特性）會隨著時間逐漸失去價值。
看板系統(tǒng)
如果我們知道哪里有瓶頸，我們就能夠重新部署資源來解除它。我們怎樣才能知道在已知流程中哪里是瓶頸呢？當我們知道了瓶頸后會采取哪些措施呢？
《看板方法》一書中對看板系統(tǒng)的定義是這樣的：
看板（或卡片）的數(shù)量，等價于系統(tǒng)設置（核定）的流通能力。一張卡片與一個工作項關聯(lián)。每張卡片都充當一種信號機制。只有獲得一張自由卡片后，才可以開始新的工作項。這張卡片與該工作項關聯(lián)在一起，跟隨工作項在整個系統(tǒng)中一起流轉。當自由卡片沒有剩余時，就不能開始額外的工作。任何新到達的工作項必須在隊列中等待，直到可以獲得新的自由卡片。有了自由卡片，隊列中的新工作項就又可以啟動。
看板方法背后有兩條基礎性的原則：
僅當有可用產能時才通過信號卡傳遞機制來拉動工作的流動
只有系統(tǒng)具備了處理的能力才能拉入新工作項，而不是基于需求將工作項推入系統(tǒng)中。
另外一條是：
限制在制品的數(shù)量
恰當?shù)脑O置能力閾值，拉動系統(tǒng)就不會出現(xiàn)過載現(xiàn)象。
思考——如何設置WIP
根據(jù)某些研究和經驗觀察，每個知識工作者同時在2個工作項上工作是最優(yōu)的。同時考慮影響因素很多，比如說一些突發(fā)的情況，或者說團隊的成熟度情況，通常來說，我們將在制品限額設為每個人或者每個結對2個工作項。
在選擇WIP數(shù)值上，并沒有什么魔法公式。這個數(shù)值是通過試驗觀察不斷調整的，我們可以先選擇一個數(shù)值，然后觀察這個數(shù)值是否能很好地工作。WIP數(shù)值本身不是最重要的，在價值流中添加WIP限制帶來一種積極的壓力：這種積極的壓力迫使大家去面對軟件交付過程中的存在問題，并思考如何改進。
舉個例子
下面的看板展示了這樣一種情況：開發(fā)人員(Dev)和業(yè)務分析師(BA)正被阻止開展任何新工作（因為QA堆積的待辦工作項已經超過了限制的在制品數(shù)量），這種情況會持續(xù)直到測試人員(QA)空出了一個卡片位置并將下一個工作項拉到測試步驟中。
這時Dev和BA會開始尋找能夠幫助測試人員減輕負擔的方法。例如，BA可以幫忙測試，Dev開始進行自動化測試等等。
一旦QA完成了一個特性的測試，就會將卡片移走，并且在Testing->Ongoing列中空閑出一個卡片位置。
Testing->Ongoing列中空出來的位置可以用Development->Done列中的一個卡片補充進來。這時Development->Ongoing列就會空閑出一個卡片位置，下一張卡片就可以從Analysis列中拉進來。
前置時間(Lead Time)是指在當前迭代完成的用戶故事中，從需求進入IPM至需求交付的耗時，Lead Time通常用作改善流動的重要衡量標準——減少Lead Time就是減少等待的時間，加速價值的流動。
寫在最后：
看板是一種方法，它能夠為我們提供：
可視化的工作流，展示工作項的進度視圖
平衡需求能力，識別瓶頸
看板代表了精益的思維范式：每個團隊的情況不同，每個看板也會不一樣。尊重他人，持續(xù)改善的思想是一樣的，我們重視通過不斷地思考，頻繁且可靠地交付高質量軟件，幫助團隊在能力和組織成熟度方面得到不斷地提升。
相關閱讀：
《談談精益（上篇） - Lean Manufacturing》
本文作者萬學凡，ThoughtWorks首席咨詢師，武漢。作者保留本文一切權利，未經許可請勿轉載。
