精益看板管理和敏捷軟體開發

前面寫過一篇TPS和專案管理，最近看了InfoQ上關於精益看板在軟體開發上的一些實踐和應用的文章，敏捷軟體開發借鑑了很多TPS精益生產的思想，雖然沒有完全提到看板的概念，但是看板在敏捷軟體開發實踐中是很有必要進行的。具體InfoQ的一些文章請參考:

將看板應用於軟體開發：從敏捷到精益
http://www.infoq.com/cn/articles/hiranabe-lean-agile-kanban

用“看板圖”實現敏捷專案的視覺化
http://www.infoq.com/cn/articles/agile-kanban-boards

精益管理在開發專案上三大精髓
http://news.csdn.net/n/20080519/116069.html

軟體開發中的準時化生產
http://news.csdn.net/n/20080519/116067.html

我們都知道看板的重要作用就是把傳統的推式生產轉變為拉動生產，通過按需生產來減少浪費。對於看板我們一方面需要控制在製品數量，一方面是要考慮整個看板工序形成的流動速率。敏捷利用故事卡做為資訊載體，採用拉動的方式組織開發。典型的資訊流動過程是這樣的：需求=>故事卡=>使用者驗收測試=>單元測試=>開發，這就是測試驅動開發的過程。故事卡是第一道看板，在開發過程中，看板是以測試的形式存在的，只有在看到失敗的測試時才開始編碼。故事卡既體現了客戶可識別的價值，又組織了團隊中所有角色的工作，這就像準時化生產中總裝車間的看板（要求生產一件成品的看板）的角色一樣，而使用者驗收測試和單元測試則類似總裝之前的各個生產單位的看板。故事卡與功能需求的不同之處就在於，故事卡試圖將團隊中所有角色（分析，測試，開發）的工作圍繞自己在一個迭代中展開，同時在迭代結束的時候完成自己的使命，而功能需求是長期存在的，需要分解轉化為故事卡之後才能指導團隊的開發工作。因此說，故事卡和測試驅動開發使得軟體開發可以通過拉動的方式展開。

有了拉動，我們就可以看到敏捷故事卡在整個看板上的流動，對於每一個工序我們都有(ToDo,Doing,End)三種狀態，每一個使用者場景在當前工序一完成後就會在看板上面進行移動，從上一個工序的End移動到下一個工序的ToDo，通過這種視覺化看板的工序移動我們就很清楚當前的專案狀態，以及當前的專案瓶頸出現在了哪個工序上面。

我們要意識到在軟體開發中的浪費沒有所謂的原材料，軟體開發最大的浪費就是人力資源的等待已經我們開發完成工件的返工。對於第一個問題我們需要對瓶頸工序進行分析重新配置各工序資源的比例，對於第二個問題則需要引入一直迭代和持續交付的機制。

前面講到了通過使用者故事卡將開發中各個階段的各個角色有機的串聯在一起，同時引入測試驅動開發實現真正的拉式生產。另外就是要通過對故事卡的分類形成多個迭代版本，以實現我們期望的持續整合，迭代開發和多次交付。這是和傳統瀑布開發的一個重要區別，敏捷開發強調持續、穩定地完成一個個對使用者有價值的，經過整合的可用功能，而不是看是否做完了全部的設計工作，或是試圖測量開發人員每天編寫了多少行程式碼、測試人員測了多少個Bug。每個使用者故事卡都是獨立可以交付的，能夠為創造使用者價值的功能點。故事卡在由各個看板組成的工序之間流動，故事卡很好的啟到了FDD特徵驅動開發的作用，產品的完成是迭代的而不是傳統的增量模式。

從精益看板到敏捷，除了強調故事卡為核心價值流和資訊流的載體，看板管理的核心要素外。我們還需要考慮以下問題以強化對看板的應用。

• 生命週期模型是如何的，工序如何劃分
• 如何通過歷史生產率確定資源的配置
• 專案的完成進度是否是以各個故事卡的最終完成比例確定的
• 是否對故事卡進行了群和組的劃分，以實現迭代交付
• 專案的實際進度和每個成員的在做工作在看板上都能夠體現
• 一個是團隊總的等待時間，一個是返工時間，如何消除浪費

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-438750/，如需轉載，請註明出處，否則將追究法律責任。