1  如何避免在產品開發后期不斷有重大修改，導致其它模塊的連鎖反應? 

DCR Tell mode vs. Ask mode設計變更

在項目早期，如果大家覺得要做一個設計變更，便可以采用告知模式（Tell-mode）的形式，也就是說，修改方必須通告所有關系人：“我在這里修改了某某界面, 我在某個API 增加了一個參數。”但是修改方不必取得其他關系人（或者模塊）的事先同意，就是說可以先行設計并編碼。當然，如果其他關系人不同意，修改還是不能簽入。

當項目進行到穩定階段，例如達到了代碼完成（CC）階段，Tell-mode 要改為請求模式（Ask-mode），這時，修改方必須先問“我是否可以在這里修改某某界面？”（當然還要有更詳盡和充分的理由），得到肯定的答復后，才能進行修改。這時的默認回答是“不”。

2  每周進度報告——還有多少事沒做完

小飛： 我們每天都在簽入新的代碼，每人都很忙，但是我總覺得不太對勁。感覺事情越做越多，我們離最終目標到底是更接近了，還是更遠了呢？

阿超： 這時我們可以看看各種報表，首要推薦的是TFS 的“Remaining Work”，可以看敏捷流程的“燃盡圖”（Burn down chart）。如果你看到每個人每天花費的時間在不斷增加，但是真正需要解決的任務（Task）和缺陷（Bug）都沒有變化，甚至緩慢增加，這意味著團隊離最后目標越來越遠了。

可以在TFS報表設置的控制板中，進一步選擇你要報告的內容，如：Iteration，選擇里程碑；Area，選擇項目的不同部分，也可以修改報告的起始和終止日期等[i]。

3  如何避免詫異的反應

問：     每次里程碑結束后，我們向客戶匯報的時候，客戶總是會驚訝地說，某某功能不是我們當初商量的那樣啊，而PM卻也同樣一臉詫異地說，不對啊，當時咱們就是這么說好的啊，有文檔為證?？蛻舨桓闪?，威脅不加/不改xx功能就如何如何，這時PM該怎么辦?

阿超： 我們在合同里要寫明到底我們要交付的是什么，這就要看PM的分析和說明能力了。有時要對客戶說“不”。同時，我們在需求說明中也要從用戶的角度去描述問題和解決方案，這樣用戶才能了解他們最終會得到什么，另一個方面是，當你給用戶演示一些界面的時候，要說明哪些界面只是示例而已，哪些界面是大家同意的最終設計。敏捷的開發流程鼓勵用戶經常參與設計和計劃，如果有條件這么做，那當然很好。

問：     項目開發中后期，開發人員用工具一統計，乖乖，足足xx萬行代碼，xx千個存儲過程，可是每到給客戶演示時，卻不時出現程序的各個功能相互不配合，不能自圓其說的尷尬場景，Dev leader很郁悶，想想自己可是沒少加班啊，代碼量也夠多，可是問題究竟出在什么方面呢？

阿超： 一個原因是每個人都沉浸在“我要寫出最強大的某某類或某某模塊”中，不停地優化一些沒有人用的功能，但是真正能夠為其他模塊使用的功能卻未能實現。他們忘了他們寫的代碼是給別人用的，而且是為了解決用戶問題的。所以這個時候我們要想想“用場景驅動”的方法，保證典型的用戶場景能夠實現。如果從“場景”出發，各個模塊的互相集成就能得到充分的測試，按照場景演示起來就更有保障了。

問：     在項目開始之前, 有很多隊員還沒有接觸過編程語言（例如C#），導致PM在分配任務時很難用時間來衡量，就拿寫一個Web Service這一模塊來說，一個熟練的程序員可能只需要兩個小時，而對于初學者來說，就得先花兩天來理解Web Service的實現機制和原理。在有限時間的催促下，導致一些緊急的任務不斷向高手集中，而初學者的任務越來越少。這時應該怎么辦？

阿超： 對于這些隊員，可以考慮在他們自己的任務估計值之上再乘以4。另外，如果你是寫一個商業項目，請不要讓連開發語言都沒有接觸過的隊員進行開發工作。并不是非得 “寫” 程序才是對項目有貢獻，有時不寫也有很好的貢獻。如果他們有熱情，就從測試開始學習吧。請參看前面提到的“大馬哈魚洄游模型“

4. 在這個時候是否碰到 “團隊成員不給力” 的問題?  請看別的同學的吐槽：

http://www.rzrgm.cn/xinz/archive/2010/11/27/1889935.html