我經歷過這樣的情況：某個項目中，研發團隊由一個5年的研發帶隊，加上4位工作經驗在半年到1年之間的程序猿們組成。從一開始就在一個又一個的坑之中跳來跳去。

      在這種情況下進行敏捷開發，絕對是挑戰極限的行為，但如果沒有選擇，那么盡量做好以下幾點：

       1. 做好充足的心里準備，并明確告知領導或客戶（如有涉及）可能出現的后果，打好預防針，獲取理解和支持。不要隱瞞問題或者『把所有問題都自己扛』；

       2. 把迭代周期適當設定的長一些，不要過短（團隊HOLD不住，時間都會浪費在代碼分支合并，沖突檢測，發版上），也不要太長（否則失去了敏捷開發的意義）。每個發版時間在可以在標準值基礎上+30~50%時間，當然還要具體情況具體分析；

      3. 至少有給力的研發負責人帶隊，可以對整個團隊有所把控，準確處理非常『幼稚』的問題節省時間。如果團隊中不具備這樣的人，發揮人脈關系哪怕借一個來，也是非常有必要的。還是不行？不如放棄敏捷開發模式，以免拖垮團隊。同樣，在架構設計階段盡量一次到位，也就是滿足當前項目周期的里程碑目標即可；

      4. 產品部門的支持。和產品經理談談心，根據團隊現實情況，能否在產品設計上有所妥協。舉個極端的例子，注冊驗證碼都搞不定的的新人，就干脆去掉驗證這步吧。冗余功能或者優先級低的果斷砍掉，和產品團隊有良好的協調。當然這種情況指新品，如果是對已有產品進行大的版本更新，你要考慮的兄弟部門就更多了。

      5. 會議的重要性。這點所有敏捷開發都會強調，包括站會匯報各自進度情況。能力不足更要保持溝通，不要讓成員自鉆牛角尖再給項目雪上加霜。

       6. 明確一切開發背景，包括開發框架，語言數據庫服務器部署要求等等（尤其設計到客戶，一定要確定清楚，必要時有合同，郵件為證）。不要進行到一半發現完全不對路，團隊接收不了這樣的驚喜。

      7. 適當的說不。如果是為客戶服務，難免會受到各種各樣的干擾和額外的工作要求。要合理的拒絕，避免再牽扯更多精力。再糾纏？把項目經理電話給他。

      8. 給予適當的安撫。能力不足往往是團隊年輕，但年輕人充滿活力，加班到凌晨不眨眼，雖然解決的問題看似都『不值一提』。但長期如此消耗勢必對團隊成員的心里產生巨大的折磨和影響。端茶倒水零食飲料不能少，如果有『程序員安撫師』……想多了，有這預算不如在招個經驗豐富的人吧。

      一般來說，你會經歷2~3個月的折磨期，這期間大部分人的能力都在突飛猛進，沒準也可以顯露大牛天賦。隨著能力的提高和配合的加強，團隊會慢慢走上正軌。