兵貴在精而不在于多。關(guān)鍵在于知人善用，以及合理調(diào)度。一個(gè)項(xiàng)目經(jīng)理在組建自己的團(tuán)隊(duì)時(shí)，必須要了解自己成員的人格特點(diǎn)與技術(shù)特點(diǎn)。在理想狀態(tài)下，如果項(xiàng)目經(jīng)理具有挑選成員的權(quán)利，會(huì)具有更大的成功率。如果項(xiàng)目過大，那么必須建立層級(jí)式的組織架構(gòu)，而在劃分出的各個(gè)小組中，卻應(yīng)該以扁平的平等架構(gòu)為佳。這樣能夠自由而不失于集中，平等而又不至于缺乏效力。當(dāng)然，具體的組織架構(gòu)應(yīng)依據(jù)企業(yè)文化、產(chǎn)品性質(zhì)、開發(fā)規(guī)模、團(tuán)隊(duì)成員特點(diǎn)等各個(gè)因素綜合考慮，不能死搬硬套。在安排人手時(shí)，要注意對(duì)技能型人才和管理型人才的使用，注意對(duì)領(lǐng)域?qū)＜液拖到y(tǒng)架構(gòu)師的使用，注意對(duì)開發(fā)人員和測(cè)試人員的使用，注意對(duì)編檔人員、QA、配置管理員的使用。此外，還需要養(yǎng)成從容不迫的心理，即使終期限火燒眉毛，迫在眉睫，仍然要保證對(duì)架構(gòu)的設(shè)計(jì)、對(duì)編碼的測(cè)試以及合理考慮產(chǎn)品性能、可用性和產(chǎn)品質(zhì)量。

5、開發(fā)環(huán)境的保護(hù)與基礎(chǔ)設(shè)施的維護(hù)。兵家云：天時(shí)、地利、人和。沒有一個(gè)好的開發(fā)環(huán)境，很難想象開發(fā)人員能夠高效率的工作。開發(fā)環(huán)境必須是相對(duì)獨(dú)立，又利于交流與溝通的工作室。具體的說，項(xiàng)目組的工作環(huán)境必須拒絕項(xiàng)目無(wú)關(guān)人員的干擾與破壞，但卻無(wú)阻于項(xiàng)目成員，特別是同一小組成員的交流。此外，會(huì)議室的數(shù)量非常重要。我在管理一個(gè)項(xiàng)目時(shí)，竟然常常為尋找會(huì)議室而東奔西走，將大量的時(shí)間浪費(fèi)在會(huì)議準(zhǔn)備上。此外，服務(wù)器、客戶機(jī)、網(wǎng)絡(luò)、打印機(jī)、白板、卡片，以及開發(fā)工具和軟件，例如IDE開發(fā)環(huán)境、版本控制工具、Bug管理工具等，都需要在團(tuán)隊(duì)建立之初要準(zhǔn)備好。對(duì)于計(jì)算機(jī)、網(wǎng)絡(luò)和相關(guān)工具，則必須保證在項(xiàng)目開發(fā)期間的穩(wěn)定性、暢通性。我曾經(jīng)在項(xiàng)目開發(fā)中，因?yàn)榫W(wǎng)絡(luò)中斷、病毒侵襲以及服務(wù)器壞掉從而破壞了SVN的版本管理等諸多突發(fā)事件，讓我在本來緊張的開發(fā)時(shí)間里，犧牲了不低于三天的時(shí)間，真是讓我抓狂不已！所以說，一個(gè)好的網(wǎng)絡(luò)管理中心、一個(gè)好的配置管理員，在關(guān)鍵時(shí)刻，可以抵得上半打高效的開發(fā)人員呢。如果你在項(xiàng)目開發(fā)過程中，頻繁遭遇這樣的問題，我的忠告是，趕緊準(zhǔn)備換一家公司吧。

6、合理控制需求變更。需求變更是軟件開發(fā)必然遭遇的暴風(fēng)雪，也是導(dǎo)致“沒有銀彈”的淵藪。傳統(tǒng)的瀑布開發(fā)模型在項(xiàng)目后期遭遇需求變更時(shí)，只能束手無(wú)策，但RUP與敏捷方法卻能夠坦然面對(duì)需求的變更，Kent Beck甚至在敏捷開發(fā)中提出了擁抱變化，真是足夠勇敢與足夠信心的宣言�。≡谲浖�開發(fā)中，若要應(yīng)對(duì)軟件開發(fā)，一般的做法是合理設(shè)計(jì)，以求系統(tǒng)與架構(gòu)具有足夠的可擴(kuò)展性；其次則是采用迭代的開發(fā)方式，通過定期甚至是短周期地交付可工作的產(chǎn)品，以印證需求與實(shí)現(xiàn)是否一致。同時(shí)，在項(xiàng)目中通過引入客戶的積極參與，使得項(xiàng)目組與客戶的交流能夠暢通無(wú)阻，從而避免因?yàn)楦糸u而導(dǎo)致需求分析產(chǎn)生的誤差，以及需求變更無(wú)法及時(shí)提出。此外，利用原型快速開發(fā)方式，可以盡快地交付一個(gè)無(wú)具體實(shí)現(xiàn)的產(chǎn)品框架或原型，以驗(yàn)證業(yè)務(wù)規(guī)則、業(yè)務(wù)流程以及客戶對(duì)GUI的要求。然而，需求變更不能無(wú)休止地進(jìn)行，這會(huì)導(dǎo)致迭代的永無(wú)眠日。即使是敏捷開發(fā)，我們?nèi)匀灰�設(shè)定客戶委托事項(xiàng)的基本線，一旦超出這一基本線，變更委員會(huì)（CCB）或其他擔(dān)負(fù)這一職責(zé)的角色必須提出異議，與客戶協(xié)商或探討這種變更是否是必須的�？刂菩枨笞兏�的一個(gè)實(shí)踐是，獲得客戶對(duì)分析出來的功能點(diǎn)的書面確認(rèn)。雖然在發(fā)生變更時(shí)，客戶的意見甚至可以無(wú)視這種書面文章，但至少可以在與客戶的談判中搶得先機(jī)。根據(jù)Mark Lines所說，通過變更控制的增強(qiáng)還可以降低項(xiàng)目風(fēng)險(xiǎn)。確實(shí)如此，在與客戶談判中，我們要學(xué)會(huì)說出“拒絕”兩個(gè)字。當(dāng)然，在對(duì)需求變更做出決定性意見之前，必須分析判斷這樣的變更是否合理，是否必要，或者優(yōu)先級(jí)高。一種折中的辦法則是，欣然承諾此次變更，但需要延遲后期限，或者放在下一次版本迭代之后。

7、預(yù)先評(píng)估風(fēng)險(xiǎn)。風(fēng)險(xiǎn)無(wú)處不在。Cockburn將軟件開發(fā)形容為攀巖或者穿越沼澤，已經(jīng)充分說明了軟件開發(fā)過程中的風(fēng)險(xiǎn)。孫子兵法云：夫未戰(zhàn)而廟算勝者，得算多也；未戰(zhàn)而廟算不勝者，得算少也。先預(yù)先著失敗的可能，方能夠謹(jǐn)慎地做好各種準(zhǔn)備，考慮各種風(fēng)險(xiǎn)以及驅(qū)避措施，方能夠大可能地取得勝利。軟件開發(fā)的風(fēng)險(xiǎn)有很多，其中至關(guān)重要的是進(jìn)度風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)、需求變更風(fēng)險(xiǎn)、成員變動(dòng)風(fēng)險(xiǎn)。

軟件是可以度量的嗎？看起來是，因?yàn)橐呀?jīng)有了很多方法來完成軟件的度量。從控制學(xué)的理論來看，你無(wú)法控制那些你無(wú)法度量的。因而軟件度量對(duì)于控制軟件開發(fā)而言，成為了關(guān)鍵。軟件度量甚至因此成為了一門學(xué)問。然而，我可以肯定地說，軟件的度量不可能準(zhǔn)確，尤其是對(duì)進(jìn)度的把握而言。即使一個(gè)項(xiàng)目的開發(fā)周期看起來是如此的充裕，以至于感受不到后期限的壓力，我們?nèi)匀灰獙?duì)軟件進(jìn)度的控制采取如坐針氈的謹(jǐn)慎態(tài)度，即使這樣在某些人的眼中，我成為了持懷疑論者，或者悲觀主義者，我仍然愿意背著這樣的名身惡意地懷疑項(xiàng)目時(shí)間不夠。原因有二。其一是我們的工作量估算無(wú)法做到精確，即使是經(jīng)驗(yàn)豐富的天才程序員，在估算項(xiàng)目的整體工作量時(shí)，都會(huì)出現(xiàn)偏差。是的，我們采用了分而治之的方式，對(duì)功能進(jìn)行分解，從小單元來評(píng)估工作量。但我們無(wú)法估算各個(gè)功能單元之間存在的各種顯式和隱式關(guān)系，以及各種非功能性需求帶給項(xiàng)目的影響。其二，我們無(wú)法事先完全預(yù)知開發(fā)過程中的各種風(fēng)險(xiǎn)。我們得為這種風(fēng)險(xiǎn)買上一份保險(xiǎn)，這樣才不至于在風(fēng)險(xiǎn)真正產(chǎn)生時(shí)要我們自己來買單，或者追悔莫及。

關(guān)于技術(shù)風(fēng)險(xiǎn)，佳方式莫過于事先進(jìn)行技術(shù)預(yù)演。不要揣測(cè)，或者從理論上去推導(dǎo)。在這個(gè)過程中，我們可以應(yīng)用經(jīng)驗(yàn)，但保險(xiǎn)的方式還是對(duì)系統(tǒng)中的核心問題以及關(guān)鍵問題進(jìn)行研究，創(chuàng)建技術(shù)原型。它才是規(guī)避技術(shù)風(fēng)險(xiǎn)的定心丸。

成員變動(dòng)風(fēng)險(xiǎn)是難以預(yù)知的，因?yàn)槿耸请y以通過數(shù)據(jù)分析得出正確結(jié)論的動(dòng)物。人的心理太復(fù)雜了，因此在軟件業(yè)中還專門誕生了“人件（Peopleware）”這門學(xué)問。在我們進(jìn)行項(xiàng)目開發(fā)過程中，誰(shuí)知道有多少人會(huì)因?yàn)楦鞣N各樣的因素，而萌生去意呢？此外，正所謂“人有旦夕禍福”，我們總不能預(yù)測(cè)哪些成員會(huì)在開發(fā)過程中生病或者失戀吧？若要解決這個(gè)問題，一個(gè)辦法是“結(jié)對(duì)編程”。雖然提出這一方法的目的并不是為了應(yīng)對(duì)成員變動(dòng)的風(fēng)險(xiǎn)，但事實(shí)上這種互相協(xié)作的方式確實(shí)能夠?qū)⒊蓡T離開所造成的損失降到低。以我的經(jīng)驗(yàn)，要發(fā)生那種編程開發(fā)的一對(duì)都離開項(xiàng)目的情形，實(shí)在是少之又少。還有一種辦法則是Constantine提出的“交叉培訓(xùn)”。在其《人件集》的《穩(wěn)步提升的質(zhì)量》一篇中，他提出“將交叉培訓(xùn)納入項(xiàng)目的組織形式中，……是有效、有影響的辦法之一。這種方法同時(shí)也增加了工作透明度。通過增加團(tuán)隊(duì)中面對(duì)面工作的機(jī)會(huì)，團(tuán)隊(duì)成員間自然也增加了相互學(xué)習(xí)的機(jī)會(huì)”。此外，他還提出 “在團(tuán)隊(duì)中進(jìn)行軟件開發(fā)角色輪循，也為成員增加了實(shí)踐的機(jī)會(huì)，可以幫助大家掌握更多的技巧和知識(shí)。”這里固然在說培訓(xùn)，但它帶來的結(jié)果是讓團(tuán)隊(duì)中各個(gè)成員都能夠了解彼此的工作，這能夠彌補(bǔ)因?yàn)槟承┏蓡T離開項(xiàng)目帶來的空白。

這里同樣牽扯出一個(gè)話題，是關(guān)于團(tuán)隊(duì)的培訓(xùn)。我的理解是，即使后期限泰山壓頂，也千萬(wàn)不要節(jié)省團(tuán)隊(duì)培訓(xùn)的時(shí)間，除非你的團(tuán)隊(duì)已經(jīng)熟悉了項(xiàng)目開發(fā)的所有領(lǐng)域知識(shí)，以及解決領(lǐng)域問題的所有技術(shù)知識(shí)，同時(shí)，這個(gè)團(tuán)隊(duì)已經(jīng)固定不變的合作過三個(gè)項(xiàng)目以上，因而團(tuán)隊(duì)成員已經(jīng)達(dá)到了一個(gè)微小動(dòng)作能夠心領(lǐng)神會(huì)的境界。有這樣的團(tuán)隊(duì)么？或許有，不過我還沒有看見。