傳統(tǒng)團隊的一個常見組織方式是按照功能模塊劃分團隊成員，明確分離職責，這也會變相增長交付周期。這樣的團隊通常傾向于按照功能模塊來組織半成品任務，而不是按照可以交付價值的完成品來組織任務。習慣按照功能模塊來組織開發(fā)的團隊通常會階段性得“聯(lián)調”，不同模塊的人帶著自己的代碼合在一起調試，由于缺乏頻繁地集成，這種聯(lián)調活動的時間經常不可控。團隊在大部分時間內通常只擁有一大堆半成品，后續(xù)的測試和驗收活動沒有辦法進行，而只能等到團隊在某一刻組裝出一個完整的功能后才能測試，因此交付周期也會比較長。

　　因此，如果我們的需求都是按照軟件的功能模塊劃分，而不是按照面向用戶的價值來劃分的，那么我們在交付用戶價值這一目標上，一開始走錯了路。采用用戶故事能夠把需求以用戶能夠理解的價值來組織，這一點是我們縮短交付周期的一個重要基礎。

　　我們的狀態(tài)墻能夠揭示需求的交付周期。讓我們來看看這樣幾個場景。

　　如果我們的需求是按照軟件的功能模塊劃分的，那么通常單個模塊的編碼完成往往不可測。例如有的團隊喜歡將web應用的上層頁面部分和下層數(shù)據(jù)庫邏輯部分劃分到不同的模塊組，一個用戶的需求也會攔腰切成兩截，一部分交給上層團隊完成，一部分交給下層團隊。單個團隊的任務完成都不能開展這個需求的測試，于是這些任務會堆積在“待測試”這一欄。

　　如果我們的需求很大，以至于開發(fā)人員要花費很長的時間（超過1周）才能完成開發(fā)，那么這個需求會在“開發(fā)中”這一欄停留很久。大家可以猜到，當一個人同時進行多個任務時，這些任務也會比它們單個依次被開發(fā)時在“開發(fā)中”這一欄停留更久的時間。

　　任何一欄中的任務其實都是半成品，只有完成測試，交付到用戶手中的需求才是完成品。狀態(tài)墻上的每一欄都好比一個存放著各種零件的倉庫，每一欄中的卡片越多，停留的越久，說明當前半成品的庫存越多，是該得到團隊的認真關注的時候了。狀態(tài)墻將每個階段的半成品數(shù)量可視化呈現(xiàn)出來，讓虛擬的數(shù)量通過卡片這種物理介質的數(shù)量得以呈現(xiàn)。

　　通過狀態(tài)墻，我們可以計算出每一個需求的交付周期大概是多久。狀態(tài)墻上一個用戶故事從放到“待開發(fā)”這一欄，到它被移動到“完成”這一欄，這一個時間段是需求的整個交付周期的其中一段，也是很重要的一段。通過優(yōu)化從“待開發(fā)”到“完成”的這一個過程，我們可以縮短需求的交付周期。通過比較需求的交付周期和客戶對交付周期的要求，我們可以量化之間的差距，然后指導我們的改進。

　　在我們理解了狀態(tài)墻是如何呈現(xiàn)一個需求的交付周期后，我們不難理解瀑布方法是如何讓交付周期變長的。在瀑布模型中，全部開發(fā)完成之后才會進行測試工作，相當于所有的任務卡片都堆積到“待測試”狀態(tài)之后，才開始逐一測試。所有開發(fā)完成的半成品，都會留存在“待測試”這一倉庫中，一直等到所有開發(fā)活動結束的那一刻。

　　當出現(xiàn)庫存堆積的時候，是我們需要改進的時候。如果“待測試”這一欄有太多的任務卡片，那么說明我們的測試活動沒有跟上。有可能是我們的測試環(huán)境出了問題，或者是我們的測試人員人力不足。如果太多的卡片位于“測試完成”狀態(tài)，說明我們的發(fā)布和終交付過程出了某些問題。如果“待開發(fā)”這一欄中任務過多，說明我們的計劃有可能超出了當前團隊的開發(fā)能力，或者說反映了開發(fā)人員的不足。也有一種情況，那是“待開發(fā)”這一欄空了很久，這可能說明了另外一個問題，那是我們的分析師的分析速度匹配不上團隊的開發(fā)能力。一個良好的團隊，必然是各種角色協(xié)調配合，并行工作，同時他們之間的任務銜接也能夠比較流暢。

　　2.4 迭代產能的度量，計劃及其他

　　團隊在每個迭代所能完成的工作量，通常被成為迭代的velocity（速度），是衡量團隊每迭代產能的一個指標。這個指標能夠幫助團隊進行制定迭代計劃。根據(jù)團隊估計任務工作量的方法不同，迭代的velocity的單位也可能不同（例如故事點數(shù)）。通常，我們只需要在迭代結束的時候，數(shù)一數(shù)狀態(tài)墻上完成的任務工作量可以了。

　　當我們經歷了若干個迭代以后，通常團隊的迭代速度會趨于穩(wěn)定，我們在做下一個迭代的計劃的時候，會參考以往迭代的數(shù)據(jù)。如果上個迭代完成了15個點，那么下個迭代我們通常也

　　會計劃15個點左右的工作量，將這些卡片放到“待開發(fā)”這一欄中。也是說，每個迭代結束時，我們都會對狀態(tài)墻進行更新，將即將到來的迭代的卡片放到墻上，并且將一些處于半成品狀態(tài)的卡片進行適當?shù)恼{整。

　　前面提到，狀態(tài)墻上可能由三種卡片，除了需求，還可能有bug和技術任務。測試人員每次在迭代中測出一個bug，會將bug寫成卡片，放到“待開發(fā)”這一欄。當bug不多的時候，團隊可以在不太影響原有計劃的情況消化掉這些bug，確保軟件的質量持續(xù)地得到保證。如果bug太多，則需要做一些計劃，將bug分散到幾個迭代里去消化。然而到這個時候，團隊可能更需要及時反省一下為什么會出現(xiàn)這么多bug的原因了。

　　另一類技術任務也需要和bug以及需求卡片一起被考慮到迭代計劃中去。通常技術任務包括諸如搭建持續(xù)集成環(huán)境、準備測試環(huán)境、重構這樣的任務。它們雖然不直接給用戶帶來價值，但是卻是保證軟件質量、確保團隊效率的重要因素。比如重構類的任務，對于工作在遺留系統(tǒng)上的團隊來說可能是需要一直考慮的事情，為了保障新的需求的順利實現(xiàn)，可能需要有計劃地重構之前的一些遺留代碼。

　　bug和技術任務耗費團隊成員的時間資源，但是不直接產生用戶價值。如果我們衡量團隊每個迭代的總體生產能力，需要在計算迭代速度時考慮這三類任務。但是如果我們只考察團隊每迭代交付的用戶價值的量的大小，那么不應該包含技術任務和bug。當一個團隊在迭代中花了過多的時間在技術任務上，或者修復bug上，那么團隊需要回顧反省一下其中的原因，是否是團隊的基礎設施太差，或者是團隊在開發(fā)時過于粗心導致太多的bug，抑或是其他的一些原因。

　　3、總結

　　在本文中我們從項目管理中常常出現(xiàn)的一些問題著手，分析了其中的一些原因，然后介紹了如何采用狀態(tài)墻（看板）來可視化任務管理。在敏捷項目中，狀態(tài)墻作為一種有效的迭代任務管理工具，已經被廣泛地使用。團隊利用狀態(tài)墻這樣一種簡單的工具，將迭代開發(fā)中的日常工作透明實時地跟蹤管理起來，能夠幫助團隊及時發(fā)現(xiàn)問題，消除浪費，快速地交付用戶價值。希望這些文字，能夠對渴望嘗試敏捷、改善任務管理和日常運作的團隊帶來一些幫助。