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

　　因此，如果我們的需求都是按照軟件的功能模塊劃分，而不是按照面向用戶的價(jià)值來(lái)劃分的，那么我們?cè)诮桓队脩魞r(jià)值這一目標(biāo)上，一開始走錯(cuò)了路。采用用戶故事能夠把需求以用戶能夠理解的價(jià)值來(lái)組織，這一點(diǎn)是我們縮短交付周期的一個(gè)重要基礎(chǔ)。

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

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

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

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

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

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

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

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

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

　　當(dāng)我們經(jīng)歷了若干個(gè)迭代以后，通常團(tuán)隊(duì)的迭代速度會(huì)趨于穩(wěn)定，我們?cè)谧鱿乱粋(gè)迭代的計(jì)劃的時(shí)候，會(huì)參考以往迭代的數(shù)據(jù)。如果上個(gè)迭代完成了15個(gè)點(diǎn)，那么下個(gè)迭代我們通常也

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

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

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

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

　　3、總結(jié)

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