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

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

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

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

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

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

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

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

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

　　2.4 迭代產(chǎn)能的度量，計劃及其他

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

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

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

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

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

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

　　3、總結(jié)

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