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

　　1、從問題談起

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

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

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

　　還有一些其他的問題，比如有的新人經(jīng)常碰到問題，然而出了問題并不會主動問其他人，而是在胡亂嘗試中浪費了時間。組里還有個開發(fā)人員非常激進，經(jīng)；〞r間去重構代碼，追求完美的架構設計，進度很讓人擔憂。組內的開發(fā)人員有時候還經(jīng)常被其他項目的事情打擾，因為有幾個人剛剛從上一個項目中調過來，上個項目的有些問題只有他們熟悉和有能力解決。她不止一次發(fā)現(xiàn)，有一個開發(fā)人員經(jīng)常在修復其他項目的bug。

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

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

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

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

　　2、可視化看板任務管理

 

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

　　先看看我們怎么樣能用這個狀態(tài)墻來管理迭代任務。說起來其實是一個很簡單的東西。

 

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

　　這樣一個簡單的工具，是如何幫助我們消除浪費、解決項目管理中的問題的？讓我們逐條分析一下看看。

　　2.1 如何減少返工帶來的浪費

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