兵貴在精而不在于多。關鍵在于知人善用，以及合理調度。一個項目經理在組建自己的團隊時，必須要了解自己成員的人格特點與技術特點。在理想狀態下，如果項目經理具有挑選成員的權利，會具有更大的成功率。如果項目過大，那么必須建立層級式的組織架構，而在劃分出的各個小組中，卻應該以扁平的平等架構為佳。這樣能夠自由而不失于集中，平等而又不至于缺乏效力。當然，具體的組織架構應依據企業文化、產品性質、開發規模、團隊成員特點等各個因素綜合考慮，不能死搬硬套。在安排人手時，要注意對技能型人才和管理型人才的使用，注意對領域專家和系統架構師的使用，注意對開發人員和測試人員的使用，注意對編檔人員、QA、配置管理員的使用。此外，還需要養成從容不迫的心理，即使終期限火燒眉毛，迫在眉睫，仍然要保證對架構的設計、對編碼的測試以及合理考慮產品性能、可用性和產品質量。
5、開發環境的保護與基礎設施的維護。兵家云：天時、地利、人和。沒有一個好的開發環境，很難想象開發人員能夠高效率的工作。開發環境必須是相對獨立，又利于交流與溝通的工作室。具體的說，項目組的工作環境必須拒絕項目無關人員的干擾與破壞，但卻無阻于項目成員，特別是同一小組成員的交流。此外，會議室的數量非常重要。我在管理一個項目時，竟然常常為尋找會議室而東奔西走，將大量的時間浪費在會議準備上。此外，服務器、客戶機、網絡、打印機、白板、卡片，以及開發工具和軟件，例如IDE開發環境、版本控制工具、Bug管理工具等，都需要在團隊建立之初要準備好。對于計算機、網絡和相關工具，則必須保證在項目開發期間的穩定性、暢通性。我曾經在項目開發中，因為網絡中斷、病毒侵襲以及服務器壞掉從而破壞了SVN的版本管理等諸多突發事件，讓我在本來緊張的開發時間里，犧牲了不低于三天的時間，真是讓我抓狂不已！所以說，一個好的網絡管理中心、一個好的配置管理員，在關鍵時刻，可以抵得上半打高效的開發人員呢。如果你在項目開發過程中，頻繁遭遇這樣的問題，我的忠告是，趕緊準備換一家公司吧。
6、合理控制需求變更。需求變更是軟件開發必然遭遇的暴風雪，也是導致“沒有銀彈”的淵藪。傳統的瀑布開發模型在項目后期遭遇需求變更時，只能束手無策，但RUP與敏捷方法卻能夠坦然面對需求的變更，Kent Beck甚至在敏捷開發中提出了擁抱變化，真是足夠勇敢與足夠信心的宣言啊！在軟件開發中，若要應對軟件開發，一般的做法是合理設計，以求系統與架構具有足夠的可擴展性；其次則是采用迭代的開發方式，通過定期甚至是短周期地交付可工作的產品，以印證需求與實現是否一致。同時，在項目中通過引入客戶的積極參與，使得項目組與客戶的交流能夠暢通無阻，從而避免因為隔閡而導致需求分析產生的誤差，以及需求變更無法及時提出。此外，利用原型快速開發方式，可以盡快地交付一個無具體實現的產品框架或原型，以驗證業務規則、業務流程以及客戶對GUI的要求。然而，需求變更不能無休止地進行，這會導致迭代的永無眠日。即使是敏捷開發，我們仍然要設定客戶委托事項的基本線，一旦超出這一基本線，變更委員會（CCB）或其他擔負這一職責的角色必須提出異議，與客戶協商或探討這種變更是否是必須的。控制需求變更的一個實踐是，獲得客戶對分析出來的功能點的書面確認。雖然在發生變更時，客戶的意見甚至可以無視這種書面文章，但至少可以在與客戶的談判中搶得先機。根據Mark Lines所說，通過變更控制的增強還可以降低項目風險。確實如此，在與客戶談判中，我們要學會說出“拒絕”兩個字。當然，在對需求變更做出決定性意見之前，必須分析判斷這樣的變更是否合理，是否必要，或者優先級高。一種折中的辦法則是，欣然承諾此次變更，但需要延遲后期限，或者放在下一次版本迭代之后。
7、預先評估風險。風險無處不在。Cockburn將軟件開發形容為攀巖或者穿越沼澤，已經充分說明了軟件開發過程中的風險。孫子兵法云：夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。先預先著失敗的可能，方能夠謹慎地做好各種準備，考慮各種風險以及驅避措施，方能夠大可能地取得勝利。軟件開發的風險有很多，其中至關重要的是進度風險、技術風險、需求變更風險、成員變動風險。
軟件是可以度量的嗎？看起來是，因為已經有了很多方法來完成軟件的度量。從控制學的理論來看，你無法控制那些你無法度量的。因而軟件度量對于控制軟件開發而言，成為了關鍵。軟件度量甚至因此成為了一門學問。然而，我可以肯定地說，軟件的度量不可能準確，尤其是對進度的把握而言。即使一個項目的開發周期看起來是如此的充裕，以至于感受不到后期限的壓力，我們仍然要對軟件進度的控制采取如坐針氈的謹慎態度，即使這樣在某些人的眼中，我成為了持懷疑論者，或者悲觀主義者，我仍然愿意背著這樣的名身惡意地懷疑項目時間不夠。原因有二。其一是我們的工作量估算無法做到精確，即使是經驗豐富的天才程序員，在估算項目的整體工作量時，都會出現偏差。是的，我們采用了分而治之的方式，對功能進行分解，從小單元來評估工作量。但我們無法估算各個功能單元之間存在的各種顯式和隱式關系，以及各種非功能性需求帶給項目的影響。其二，我們無法事先完全預知開發過程中的各種風險。我們得為這種風險買上一份保險，這樣才不至于在風險真正產生時要我們自己來買單，或者追悔莫及。
關于技術風險，佳方式莫過于事先進行技術預演。不要揣測，或者從理論上去推導。在這個過程中，我們可以應用經驗，但保險的方式還是對系統中的核心問題以及關鍵問題進行研究，創建技術原型。它才是規避技術風險的定心丸。
成員變動風險是難以預知的，因為人是難以通過數據分析得出正確結論的動物。人的心理太復雜了，因此在軟件業中還專門誕生了“人件（Peopleware）”這門學問。在我們進行項目開發過程中，誰知道有多少人會因為各種各樣的因素，而萌生去意呢？此外，正所謂“人有旦夕禍福”，我們總不能預測哪些成員會在開發過程中生病或者失戀吧？若要解決這個問題，一個辦法是“結對編程”。雖然提出這一方法的目的并不是為了應對成員變動的風險，但事實上這種互相協作的方式確實能夠將成員離開所造成的損失降到低。以我的經驗，要發生那種編程開發的一對都離開項目的情形，實在是少之又少。還有一種辦法則是Constantine提出的“交叉培訓”。在其《人件集》的《穩步提升的質量》一篇中，他提出“將交叉培訓納入項目的組織形式中，……是有效、有影響的辦法之一。這種方法同時也增加了工作透明度。通過增加團隊中面對面工作的機會，團隊成員間自然也增加了相互學習的機會”。此外，他還提出 “在團隊中進行軟件開發角色輪循，也為成員增加了實踐的機會，可以幫助大家掌握更多的技巧和知識。”這里固然在說培訓，但它帶來的結果是讓團隊中各個成員都能夠了解彼此的工作，這能夠彌補因為某些成員離開項目帶來的空白。
這里同樣牽扯出一個話題，是關于團隊的培訓。我的理解是，即使后期限泰山壓頂，也千萬不要節省團隊培訓的時間，除非你的團隊已經熟悉了項目開發的所有領域知識，以及解決領域問題的所有技術知識，同時，這個團隊已經固定不變的合作過三個項目以上，因而團隊成員已經達到了一個微小動作能夠心領神會的境界。有這樣的團隊么？或許有，不過我還沒有看見。
