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.cnblogs.com/xinz/archive/2010/11/27/1889935.html
5. 我們是在寫代碼解決問題呢，還是在搭建宏偉的架構?
請看：http://ourjs.com/detail/53dbb5292ee109090700000c
[i] VS2010以及之後的版本還提供了燃盡圖等功能，請參見相關同學的博客，例如
http://www.cnblogs.com/OMG-Team/archive/2011/09/30/2196150.html