《軟體開發踐行錄——ThoughtWorks中國區文集》一一1.11．從問題談起

本節書摘來自異步社群出版社《軟體開發踐行錄——thoughtworks中國區文集》一書中的第1章，第1.1節，作者： thoughtworks中國，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

我曾經碰到過一個項目經理，她管理一個團隊開發一個web應用，團隊裡開發人員大概10個，測試人員3個，業務分析師1個人。對于任務的管理她是這樣做的。通常，她會将需求分析人員分析得到的需求給每個人分一些。然後每個人在領到任務之後會給她承諾一個大緻的時間點。整個項目大緻的傳遞計劃用一個excel表管理，根據客戶要求的傳遞時間點，同時考慮到一些需求之間的內建測試關系，她定出了每個需求的大緻傳遞時間點。隻要每個開發人員承諾的時間點和期望的相差不大，她都可以接受，這樣每個開發人員就知道自己應該在什麼時間點傳遞什麼東西。

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

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

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

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

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

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

熟悉靈活方法的讀者可能知道，靈活方法包含一系列實踐，來幫助團隊實作短周期快速傳遞，更好地響應需求變化。比如說使用者故事（user story）方法将需求從使用者價值的角度進行組織，避免将需求從功能子產品角度劃分。小粒度的使用者故事可以在一兩周的疊代内完成開發和測試（并行開發），進而可以縮短傳遞周期。問題是，在靈活團隊内，我們如何有效管理大量小粒度使用者故事，同時避免上述項目管理中的問題呢？下面我們結合靈活開發中的看闆工具來看看靈活團隊是如何管理任務的。