qileilove

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

　　1、從問題談起

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

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

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

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

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

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

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

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

　　2、可視化看板任務管理

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

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

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

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

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

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

　　在傳統的瀑布流程中，我們往往是期望通過前期細致入微的工作來確保一個階段的工作被高質量完成之后才移交到下一階段。后來我們慢慢從失敗的經驗 中學習到，這種方法在變化的需求環境下實在是太過脆弱，不僅不能如愿保證質量，而且會造成更大的浪費，交付周期也不能滿足要求。于是我們引入了迭代式開發 方法，一個需求的分析、開發、測試、驗收成了一個小粒度地更連續的過程，在這個小的交付循環中，看板幫助我們以更細節的粒度來管理一個任務每個階段的工作 質量。

　　通常我們是這么做的。當我們把一張故事卡從“待開發”移動到“開發中”時，這張卡片必須是已經分析完成的。也就是說，當開發人員準備真正開始開 發這張故事卡之前，我們的需求分析師們必須保證這張卡片所包含的所有內容和細節已經被分析完成，不再有模棱兩可的細節，不再留給開發人員過多的自我發揮和 想象空間，而且這些細節必須和客戶確認過，而不只是團隊自己“設計”的結果。

　　這一道關看似很尋常，實際上很多項目會在這里出問題。很多時候開發人員開始開發的時候，需求還沒有分析完成，很多細節尚須澄清確認，實現上的技 術風險還沒有被完全排除。也有的分析師善于給開發人員留有大量自我發揮空間，需求過于言簡意賅。開發人員開始開發這樣的需求時，要么做不下去，要么按照自 己的理解做下去。做完了之后分析師一看發現不對，和我想的不一樣，于是開發人員返工。最糟糕的情形莫過于最后被客戶發現說，這不是我當初想要的東西。

　　由此可見，確保開發人員挪卡的時候，這張待開發的用戶故事已經被真正分析完成，是我們準確實現用戶需求的第一步。通過規定這一挪卡的前提，同時 輔以用戶故事的澄清（由分析師向開發人員澄清）或者反向澄清（由開發人員向分析師講述自己的理解），可以很大程度上將返工減少到最低。

　　還有一種浪費發生在測試過程中。測試人員經常會發現，處于“待測試”狀態中的一些故事卡，在測試的時候主要的流程都走不通，根本無法進一步展開測試，于是乎不得不將故事卡

　　打回到開發人員手中。而往往這個時候開發人員已經工作在另一個用戶故事上了。要么他停下手中的任務解決測試的問題，要么讓測試人員等到這些問題修復過后再測。無論哪種都是不好的選擇。

　　這種問題的一個主要原因是因為開發人員聲稱他已經“開發完成”，將故事卡從“開發中”挪到“待測試”時，實際上自己并沒有對這部分功能進行測 試。或者是因為疏忽，或者是因為懶惰，或者是因為過于自信。通過在這個狀態轉換階段引入用戶故事初驗，讓分析師在挪卡之前先到開發人員機器上看看是否該故 事卡包含的功能被實現了，可以很大程度上提升效率，減少浪費。若分析師在初驗過程中發現了問題，那么開發人員馬上能以最小的成本進行修復，而不用等到之后 測試人員發現時再來修復。而且，分析師初驗也提供了一個判斷實現是否良好的反饋點，這是我們能夠看到一個需求是否被實現并能夠真正工作的最早的時間點。

　　2.2 如何避免多任務并行

　　多任務之間的頻繁切換是一個常見的問題。表現在團隊里的成員，特別是開發人員，會在不同的任務間切換。就像前面的故事中提到的，可能這一刻還在 實現某一個需求，而下一刻馬上就會被叫走去修復某一個遺留版本的缺陷。又或者該人手頭被分配了多個任務，每個任務都在進行中，而沒有一個處于完成狀態。任 務切換是導致效率降低的一個重要原因，不同任務間的上下文的切換會導致頻繁地將任務當前狀態在頭腦中“壓棧”和“出棧”，這些操作會耗費時間。如果完成一 個任務需要一個人一天時間，那么兩天內這個人可以完成兩個任務，但是如果他在第一天同時開始并行工作在這兩個任務上，那么完成這兩個任務會需要大于兩天的 時間。

　　大家可能已經注意到了，在前面的看板圖中，處于“開發中”的所有任務卡片上都有一個小紙條，上面標記著正在這張卡片上工作的人的名字。如果說有 兩個人結對在一個卡片上工作，那么這張卡片上應該有兩個名字。這一小小的實踐可以幫助我們隨時發現團隊內某一時刻，是否每個人只工作在一個任務上。

　　我們在領取“待開發”狀態欄中的卡片時，保證每次每人只領一張卡片，不要多領，完成了這張卡片之后，再回來領下一張。當一張卡片被認領之后，我 們就會對這張卡片進行跟蹤，在站會上談論它的完成情況，談論實現過程中碰到的問題。當它的進度和估計的可能偏差較大時，我們能夠及時而不是在最后一刻察覺 到，提供需要的幫助，確保它能夠順利完成。這樣一種方式讓我們能夠將注意力集中到小粒度的需求（例如用戶故事）上，更多地關注這些用戶故事的流動速度。而 當每個小的用戶故事能夠順暢地流動起來時，整個項目的交付也得到了保障。

　　當然這一實踐并不能自動保證團隊內不再出現多任務并發、拖延、或者做和任務無關的其他事情等問題。可能有些人在做一個用戶故事的過程中，突然中斷去做了一些其他事情，但是

　　卻沒有及時在狀態墻上更新自己的狀態。重要的是團隊要有實現交付目標的共同愿景，能夠透明地暴露問題，并且善于利用狀態墻來發現和改進自身的問題。對于不成熟的團隊，這可能需要一個轉變的周期。

　　如果一個團隊的職責共享較好，代碼被所有人集體擁有，每個人都被鼓勵熟悉和工作在代碼的不同部分，那么在這樣的團隊內便不太會出現把一大塊任務 事先就明確給某一個人的情況。相反，所有人的工作事先不具體確定，大家會更容易形成某一時刻只領取一張卡片的情況，避免同時工作在多個任務上。實際上，狀 態墻的使用也可以幫助團隊走向職責共享之路，只需要在大家領取任務的時候有意地給人們分配一些之前沒做過的內容，同時安排好有經驗的人與其結對工作，一段 時間之后，團隊內的人便會逐漸體會到和之前只是專注在一個模塊內不同的工作方式。

　　2.3 如何減少半成品庫存，縮短交付周期

　　一個需求的交付周期（leadtime）是從它被識別到最終交付給用戶手中所耗費的時間。交付周期越短，意味著客戶從提出想法到能夠在軟件中實 際使用到這個點子的時間越短。從客戶的角度來看，更短的交付周期意味著自己的軟件能夠對市場變化的更快地響應，因而獲得更強的競爭力，同時也意味著能夠更 快地驗證自己的想法。

　　任務管理的粒度太大會直接導致交付周期變長。最極端的情況是將屬于某一模塊的任務在一開始就全部分給負責這個模塊的人，所有這個模塊相關的修改 都由他來實現。在一個按模塊劃分職責，每個人只負責自己具體模塊的團隊里，通常這個模塊的負責人會實現這個模塊的所有修改。不然，就是將一個可能需要做2 周到一個月的任務分給某個人。或者更好一點的情況是，單個任務本身不大，但是會將相關聯的任務成批地分配給某個人。如果你的團隊內也是采用大篇的“規格說 明書”等word文檔來組織需求的，那么就要小心，這種問題很可能在團隊內已經存在。整個團隊沒有小粒度頻繁交付的概念，習慣了大批量長時間地交付方式。 由于批量大，所以估計常常不準，而且時間跨度長，中間也會有更多地干擾因素出現，這些都導致任務不能在開始承諾的時間點交付。開發周期長同樣導致測試活動 的滯后，極端地滯后就演變為所有開發工作完成之后才能進行測試，這就是我們熟悉的瀑布模式。最終的影響就是需求的交付周期會很長。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3、總結

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