作為一個(gè)開(kāi)發(fā)團(tuán)隊(duì)的管理者，例如當(dāng)你是一個(gè)團(tuán)隊(duì)的項(xiàng)目經(jīng)理的時(shí)候，任務(wù)的完成情況通常是你關(guān)心的內(nèi)容之一，比如說(shuō)分配的任務(wù)是否能夠按時(shí)間完成，整個(gè)項(xiàng)目的進(jìn)度是否尚在計(jì)劃之中，團(tuán)隊(duì)內(nèi)的人是不是都在高效地工作，大家有沒(méi)有什么困難，這些是你經(jīng)常會(huì)關(guān)注的問(wèn)題。在軟件開(kāi)發(fā)團(tuán)隊(duì)中，任務(wù)的分配、跟蹤和管理通常是這個(gè)團(tuán)隊(duì)管理者的一個(gè)重要的工作內(nèi)容。

　　1、從問(wèn)題談起

　　我曾經(jīng)碰到過(guò)一個(gè)項(xiàng)目經(jīng)理，她管理著一個(gè)團(tuán)隊(duì)開(kāi)發(fā)一個(gè)web應(yīng)用，團(tuán)隊(duì)里開(kāi)發(fā)人員大概10個(gè)左右，測(cè)試人員3個(gè)，業(yè)務(wù)分析師1個(gè)人。對(duì)于任務(wù)的管理她是這么做的。通常，她會(huì)將需求分析人員分析得到的需求給每個(gè)人分一些。然后每個(gè)人在領(lǐng)到任務(wù)之后會(huì)給她承諾一個(gè)大致的時(shí)間點(diǎn)。整個(gè)項(xiàng)目大致的交付計(jì)劃用一個(gè)excel表管理著，根據(jù)客戶要求的交付時(shí)間點(diǎn)，并且考慮到一些需求之間的集成測(cè)試關(guān)系，定出了每個(gè)需求的大致交付時(shí)間點(diǎn)。只要每個(gè)開(kāi)發(fā)人員承諾的時(shí)間點(diǎn)和期望的相差不大，她都可以接受，每個(gè)開(kāi)發(fā)人員這樣知道自己應(yīng)該在什么時(shí)間點(diǎn)交付什么東西。

　　一切本該很完美，但是不和諧的問(wèn)題不斷出現(xiàn)。經(jīng)常發(fā)生的事情是大家在承諾的時(shí)間點(diǎn)快要到的時(shí)候不能按時(shí)交付，每次她詢問(wèn)進(jìn)度的時(shí)候，會(huì)被告知還差一點(diǎn)完成了。通常的說(shuō)法是“底層部分已經(jīng)做完了，或還差頁(yè)面部分可以搞定了”，然而實(shí)際情況是又過(guò)了相當(dāng)?shù)臅r(shí)間才真正完成。當(dāng)然也不是沒(méi)有按時(shí)交付的需求，但是她發(fā)現(xiàn)也許是大家經(jīng)常加班，已經(jīng)開(kāi)始疲倦了，有時(shí)候明明很簡(jiǎn)單的可以提前完成的需求，大家還是到后一刻才交付給測(cè)試。

　　也有的開(kāi)發(fā)人員拿到自己的那一批需求之后，會(huì)批量工作，把若干個(gè)類似的需求的底層邏輯全部實(shí)現(xiàn)，然后再實(shí)現(xiàn)上層內(nèi)容。她默認(rèn)了這種做法，像這位開(kāi)發(fā)人員說(shuō)的“這幾個(gè)需求都差不多，只要底層做好了，基本上都差不多完成了”。雖然這部分工作早點(diǎn)和其他人一起集成測(cè)試會(huì)比較好，但是他這樣做也只能推后集成測(cè)試的時(shí)間點(diǎn)了。還好承諾給測(cè)試團(tuán)隊(duì)的交付時(shí)間點(diǎn)還在1個(gè)月之后，只要1個(gè)月之內(nèi)能夠完成這些需求可以了。

　　還有一些其他的問(wèn)題，比如有的新人經(jīng)常碰到問(wèn)題，然而出了問(wèn)題并不會(huì)主動(dòng)問(wèn)其他人，而是在胡亂嘗試中浪費(fèi)了時(shí)間。組里還有個(gè)開(kāi)發(fā)人員非常激進(jìn)，經(jīng)常花時(shí)間去重構(gòu)代碼，追求完美的架構(gòu)設(shè)計(jì)，進(jìn)度很讓人擔(dān)憂。組內(nèi)的開(kāi)發(fā)人員有時(shí)候還經(jīng)常被其他項(xiàng)目的事情打擾，因?yàn)橛袔讉(gè)人剛剛從上一個(gè)項(xiàng)目中調(diào)過(guò)來(lái)，上個(gè)項(xiàng)目的有些問(wèn)題只有他們熟悉和有能力解決。她不止一次發(fā)現(xiàn)，有一個(gè)開(kāi)發(fā)人員經(jīng)常在修復(fù)其他項(xiàng)目的bug。

　　她會(huì)不定時(shí)地去詢問(wèn)每個(gè)開(kāi)發(fā)人員的開(kāi)發(fā)進(jìn)度，當(dāng)需求的計(jì)劃交付時(shí)間點(diǎn)逼近的時(shí)候，這種檢查會(huì)越來(lái)越頻繁，開(kāi)發(fā)人員感受到壓力，有時(shí)候甚至需要加班來(lái)完成開(kāi)發(fā)工作。然而盡管她花了很多精力去跟蹤和檢查每個(gè)需求的完成情況，還是有很多出乎期望的事情在不斷發(fā)生。盡管她一直相信說(shuō)，只要開(kāi)發(fā)人員們能夠完成任務(wù)，采用什么方式她是不干預(yù)的，而具體的時(shí)間也是由他們自己分配的。但是她漸漸感覺(jué)到，任務(wù)越來(lái)越不可控，計(jì)劃通常無(wú)法按時(shí)完成，每天對(duì)大家的檢查花了大部分時(shí)間，然而卻不能揭示出真正的問(wèn)題。

　　運(yùn)轉(zhuǎn)良好的項(xiàng)目都差不多，而問(wèn)題項(xiàng)目的問(wèn)題各有各的不同。盡管每個(gè)團(tuán)隊(duì)的問(wèn)題可能不完全相同，但是當(dāng)我們審視這些項(xiàng)目的運(yùn)作和管理方式的時(shí)候，不難發(fā)現(xiàn)一些諸如多任務(wù)并行等共性的問(wèn)題，這些問(wèn)題給軟件項(xiàng)目帶來(lái)了各種各樣的浪費(fèi)。當(dāng)一個(gè)團(tuán)隊(duì)采用瀑布開(kāi)發(fā)模式的時(shí)候，開(kāi)發(fā)階段全部結(jié)束之后測(cè)試人員才會(huì)介入，開(kāi)展測(cè)試活動(dòng)，在一個(gè)通常很漫長(zhǎng)的開(kāi)發(fā)階段內(nèi)，各種開(kāi)發(fā)活動(dòng)中的浪費(fèi)、估計(jì)的不準(zhǔn)確，以及成員自己的拖沓、被打擾、問(wèn)題阻塞等，都被掩蓋住了。只要在終時(shí)間點(diǎn)前能夠全部開(kāi)發(fā)完成，不管是前松后緊，還是加班熬夜，都已經(jīng)成了項(xiàng)目開(kāi)發(fā)的常態(tài)。項(xiàng)目經(jīng)理只能看到交付的終時(shí)間點(diǎn)，問(wèn)題不能及時(shí)的暴露，而等到問(wèn)題被暴露的時(shí)候，可以使用的調(diào)整手段也非常有限。

　　這樣的一種團(tuán)隊(duì)生存狀態(tài)在外部環(huán)境要求短交付周期，需求允許經(jīng)常變化的情況下顯示出了極度地不適應(yīng)。市場(chǎng)環(huán)境的變化驅(qū)動(dòng)了軟件需求的變化，這種變化催生了縮短交付周期的訴求，較短的交付周期使得人們可以不必去預(yù)期過(guò)于長(zhǎng)遠(yuǎn)的需求，具備根據(jù)市場(chǎng)的變化快速地制定和調(diào)整軟件需求的能力。而當(dāng)交付模型由幾個(gè)月的瀑布模型轉(zhuǎn)變?yōu)閿?shù)周甚至更短的迭代模型的時(shí)候，我們?cè)谇懊嬲劦降膱F(tuán)隊(duì)中的各種浪費(fèi)、低效、半成品堆積等問(wèn)題，會(huì)急劇地爆發(fā)出來(lái)。

　　熟悉敏捷方法的讀者可能都知道，敏捷方法包含一系列實(shí)踐來(lái)幫助團(tuán)隊(duì)實(shí)現(xiàn)短周期快速交付，更好地響應(yīng)需求變化。比如說(shuō)userstory方法，將需求從用戶價(jià)值的角度進(jìn)行組織，避免將需求從功能模塊角度劃分。小粒度的用戶故事可以在一兩周的迭代內(nèi)完成開(kāi)發(fā)和測(cè)試（并行開(kāi)發(fā)），從而可以縮短交付周期。問(wèn)題是，在敏捷團(tuán)隊(duì)內(nèi)，我們是如何有效管理大量小粒度userstory，同時(shí)避免上述項(xiàng)目管理中的問(wèn)題呢？下面我們結(jié)合敏捷開(kāi)發(fā)中的看板工具來(lái)看看敏捷團(tuán)隊(duì)是如何管理任務(wù)的。

　　2、可視化看板任務(wù)管理

 

　　看板源于精益生產(chǎn)實(shí)踐，敏捷將其背后的可視化管理理念借鑒過(guò)來(lái)，經(jīng)過(guò)一番改造，形成了有自己獨(dú)特風(fēng)格的可視化管理工具。曾有人總結(jié)過(guò)scrum和kanban的使用，而很多時(shí)候，我們也將它叫做迭代狀態(tài)墻。

　　先看看我們?cè)趺礃幽苡眠@個(gè)狀態(tài)墻來(lái)管理迭代任務(wù)。說(shuō)起來(lái)其實(shí)是一個(gè)很簡(jiǎn)單的東西。

 

　　通常一個(gè)迭代的狀態(tài)墻上反映了某一個(gè)迭代的計(jì)劃和任務(wù)進(jìn)展情況。狀態(tài)墻上按照一個(gè)迭代內(nèi)團(tuán)隊(duì)的典型開(kāi)發(fā)活動(dòng)分成幾欄，例如“待開(kāi)發(fā)”、“開(kāi)發(fā)中”、“待測(cè)試”、“測(cè)試中”、“測(cè)試完成”等。在一個(gè)迭代之初，我們會(huì)將計(jì)劃在本迭代完成的故事卡放到“待開(kāi)發(fā)”這一欄中？梢暬癄顟B(tài)墻的一個(gè)好處是所有團(tuán)隊(duì)成員都可以實(shí)時(shí)地了解到本迭代的計(jì)劃和進(jìn)展情況。開(kāi)發(fā)人員領(lǐng)取任務(wù)時(shí)，將他領(lǐng)取的故事卡片從“待開(kāi)發(fā)”移到“開(kāi)發(fā)中”，同時(shí)貼上帶有自己名字的小紙條。當(dāng)他開(kāi)發(fā)完成之后，將故事卡片移到“待測(cè)試”一欄。我們的測(cè)試人員看到這一欄里有待測(cè)的故事卡時(shí)，取下一張，移動(dòng)到“測(cè)試中”，開(kāi)始這個(gè)用戶故事的測(cè)試，測(cè)試完成后，將故事卡移動(dòng)到“測(cè)試完成”一欄。如果測(cè)試人員發(fā)現(xiàn)了一個(gè)bug，那么他可以用紅顏色的卡片記下這個(gè)bug，然后放到待開(kāi)發(fā)這一欄中。在狀態(tài)墻上，除了用戶故事、bug之外，還會(huì)有一些諸如重構(gòu)、搭建測(cè)試環(huán)境這樣的不直接產(chǎn)生業(yè)務(wù)價(jià)值的任務(wù)，這三類任務(wù)用不同顏色的卡片，放到狀態(tài)墻上統(tǒng)一管理。

　　這樣一個(gè)簡(jiǎn)單的工具，是如何幫助我們消除浪費(fèi)、解決項(xiàng)目管理中的問(wèn)題的？讓我們逐條分析一下看看。

　　2.1 如何減少返工帶來(lái)的浪費(fèi)

　　返工是軟件開(kāi)發(fā)過(guò)程中的一大嚴(yán)重浪費(fèi)。比如說(shuō)開(kāi)發(fā)人員開(kāi)發(fā)完成的任務(wù)交給測(cè)試人員測(cè)試的時(shí)候，關(guān)鍵流程不能走通，阻礙了測(cè)試進(jìn)程；交付給客戶的東西被客戶說(shuō)“這不是我想要的東西”；分析人員將還沒(méi)分析透徹的任務(wù)交給開(kāi)發(fā)人員，在后驗(yàn)收的時(shí)候發(fā)現(xiàn)開(kāi)發(fā)人員加入了自己的一些“發(fā)揮”。這些都會(huì)造成返工。返工意味著沒(méi)有一次性將事情做對(duì)，意味著流程中的上游沒(méi)有交付高質(zhì)量的工作，也可能意味著團(tuán)隊(duì)成員間的溝通出了問(wèn)題。