我在我的微博上說(shuō)過(guò)這樣一段話,，我想在這里把我的這個(gè)觀點(diǎn)闡述地更完整一些。

@左耳朵耗子：聰明的程序員使用50%-70%的時(shí)間用來(lái)思考,，嘗試和權(quán)衡各種設(shè)計(jì)和實(shí)現(xiàn),，而用30% – 50%的時(shí)間是在忙碌著編碼，調(diào)試和測(cè)試,。聰明的老板也會(huì)讓團(tuán)隊(duì)這樣做,。而傻逼的老板，苦逼的程序員會(huì)拿出來(lái)100%-150%的時(shí)間來(lái)忙著趕進(jìn)度,，返工,，重構(gòu)，fix 大量的bug… 所以， 越差的團(tuán)隊(duì)一般會(huì)越忙,，而且還忙不完,。

在現(xiàn)在這個(gè)浮躁的時(shí)期，再加上敏捷咨詢師們念的歪經(jīng),，他們讓人感覺(jué)上就像是軟件產(chǎn)品是可以在很短的時(shí)間內(nèi)高質(zhì)量的完成的,，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實(shí)驗(yàn)中的狗看到了肉就會(huì)流口水那樣興奮,。他們使用TDD,，快速迭代，不斷重構(gòu),，持續(xù)集成直至持續(xù)部署的方法在進(jìn)行軟件開(kāi)發(fā),。

軟件開(kāi)發(fā)真是這樣的嗎？難道不需要花時(shí)間去思考嗎,？對(duì)此,，有些觀點(diǎn)在Todd的《“品質(zhì)在于構(gòu)建過(guò)程”嗎,？》以及《Bob大叔和Jim Coplien對(duì)TDD的論戰(zhàn)》中談到過(guò)了,。我只想想表達(dá)下面的觀點(diǎn)：

• 軟件的精髓在于設(shè)計(jì)，設(shè)計(jì)是一件很費(fèi)大腦的事件,。對(duì)于軟件來(lái)說(shuō),，設(shè)計(jì)沒(méi)有完美的，它總是一件需要取舍需要權(quán)衡的事,，比如：時(shí)間換空間,，空間換時(shí)間，TCP或UDP,，同步還是異步,，數(shù)據(jù)冗余還不冗余等等。那怕是一個(gè)小小的observers模式是pull方式還是push方式 都需要仔細(xì)討論,。這些的東西需要時(shí)間和做前期嘗試,。

• TDD、快速原型和迭代可能會(huì)對(duì)軟件和團(tuán)隊(duì)產(chǎn)生負(fù)面影響,。在一開(kāi)始,，你需要花很大的精力來(lái)讓你的軟件從無(wú)到有（做過(guò)軟件的人都知道，從零開(kāi)始寫(xiě)代碼是很痛苦的事）,，但是因?yàn)槟銢](méi)有想好，先做再說(shuō),，所以,，后期你會(huì)面臨更多的質(zhì)量問(wèn)題而讓你需要花更多的時(shí)間精力。當(dāng)然,，那些咨詢師會(huì)讓你用持續(xù)集成和持續(xù)部署這樣的方法,。但我想告訴你,，這并不解決你軟件設(shè)計(jì)的缺陷。舉個(gè)例子——TDD,、迭代,、原型只關(guān)注功能性需求，其不會(huì)關(guān)注非功能性需求,，比如性能問(wèn)題,，高可用性問(wèn)題，系統(tǒng)維護(hù)問(wèn)題（模塊的耦合問(wèn)題）,，等等,。而這些問(wèn)題往往都可以讓你的軟件設(shè)計(jì)重新來(lái)過(guò)。

• 重構(gòu)是惡夢(mèng),，重構(gòu)應(yīng)該越少越好,。當(dāng)你維護(hù)一個(gè)復(fù)雜的系統(tǒng)時(shí)你會(huì)知道重構(gòu)是一件多么恐怖的事情（參看《重構(gòu)代碼的7個(gè)階段》）。如果一開(kāi)始沒(méi)有想好,，你要面臨的不單單是re-design, re-architect,，還要面對(duì)時(shí)間和人力成本的增加，最難的是你還要面對(duì)的是團(tuán)隊(duì)士氣因?yàn)椴粩嗟膔ework而逐漸低落并產(chǎn)生厭倦和懈怠情緒,。

所以,，如果你能有多一些時(shí)間去和客戶討論一下需求和未來(lái)可能的變化，去調(diào)查一下實(shí)現(xiàn)的技術(shù)難點(diǎn)和細(xì)節(jié),，去和其他有經(jīng)驗(yàn)的人討論并推敲一下架構(gòu)和設(shè)計(jì),，去思考設(shè)計(jì)上的缺陷，那么,，你的coding會(huì)變得非常地直,，直到你一眼就看到盡頭，你的測(cè)試案例也會(huì)寫(xiě)得非常地好,，你會(huì)幾乎不需要重構(gòu),，于是，你會(huì)在未來(lái)少寫(xiě)很多代碼,，從而你的軟件開(kāi)發(fā)會(huì)越來(lái)越輕松,，直到技術(shù)開(kāi)始換代。

我現(xiàn)在在做的項(xiàng)目,，花了幾乎4個(gè)月的時(shí)間來(lái)做設(shè)計(jì),，在這個(gè)過(guò)程中，我們反復(fù)思考,、討論和權(quán)衡若干種實(shí)現(xiàn)方法,，并盡可能地窮舉所有的場(chǎng)景和細(xì)節(jié)以及未來(lái)可能的變化（那怕是那些簡(jiǎn)單的模塊），有個(gè)模塊被重寫(xiě)了至少三次，每次都是寫(xiě)到一半就被推翻重寫(xiě),，我們整個(gè)團(tuán)隊(duì)不斷地在和其它團(tuán)隊(duì)討論,，并在對(duì)系統(tǒng)不斷地認(rèn)識(shí)中對(duì)系統(tǒng)進(jìn)行簡(jiǎn)化和優(yōu)化，并力求達(dá)到完美?，F(xiàn)在看來(lái),，沒(méi)有貿(mào)然使用Scrum是明智的。

這就好像我們修路造橋一樣,，我們需要花大量的時(shí)間勘測(cè)地形地質(zhì),，分析數(shù)據(jù)，思考可能出現(xiàn)的各種問(wèn)題（各種自然災(zāi)害）,，評(píng)估不同的設(shè)計(jì)方案,，而不是先盡快建好再說(shuō)。

所以,，多一些時(shí)間,，不是讓你多做幾次迭代，多完成幾個(gè)模塊,，而是可以讓你少寫(xiě)一些代碼,，更快的交付一個(gè)更好的產(chǎn)品。

我相信你會(huì)有很多疑問(wèn),，下面是我覺(jué)得你可能會(huì)有下面的一些觀點(diǎn),，讓我一條一條來(lái)回復(fù)：

• 首當(dāng)其沖的一定會(huì)是項(xiàng)目的deadline，或是那種你沒(méi)有活語(yǔ)權(quán)的項(xiàng)目,。比如做那種“甲乙方合同式的項(xiàng)目”,，我把這種項(xiàng)目統(tǒng)一認(rèn)為是“外包項(xiàng)目”，在這種項(xiàng)目性質(zhì)下,，你很難有話語(yǔ)權(quán),。對(duì)此，我覺(jué)得,，1）作為乙方的你還是應(yīng)該和甲方在項(xiàng)目計(jì)劃上爭(zhēng)取一下,，曉之以情，動(dòng)之以理,。2）如果不行,，只能在時(shí)間、需求范圍和質(zhì)量上做一個(gè)權(quán)衡,。另外,，在這種情況下你要找一個(gè)方法，把你的壓力和痛苦分擔(dān)給用戶和領(lǐng)導(dǎo),。（找到這個(gè)方法的前提需要你找到用戶和領(lǐng)導(dǎo)他們害怕什么,，嘿嘿）

• 過(guò)度設(shè)計(jì)和紙上談兵,。有人說(shuō)會(huì)不會(huì)設(shè)計(jì)太多,，造成過(guò)度設(shè)計(jì),，或是在設(shè)計(jì)上花太多的時(shí)間。這有可能,。我上一家公司的一個(gè)項(xiàng)目團(tuán)隊(duì)就花了1年多的時(shí)間來(lái)不停不停的開(kāi)會(huì)和做設(shè)計(jì),，結(jié)果release的時(shí)候還有1000多個(gè)bug。這個(gè)問(wèn)題的原因是,，這個(gè)團(tuán)隊(duì)的設(shè)計(jì)是在紙上談兵,，開(kāi)會(huì)是開(kāi)神仙會(huì)，討論的設(shè)計(jì)都是浮云,。所以,，設(shè)計(jì)并不是討論和思考，還需要去嘗試,，我認(rèn)為當(dāng)你的設(shè)計(jì)完成的時(shí)候,，你的骨干核心代碼都基本完成了。

• 我的團(tuán)隊(duì)成員水平太差,，不會(huì)思考,。首先，先恭喜你找到一堆碼農(nóng),，當(dāng)然,，這不怪你，這是中國(guó)教育和大環(huán)境的問(wèn)題,，讓人不會(huì)思考,。對(duì)于這樣的情況，我有兩個(gè)建議,，1）量力而行,，使多大的碗就吃多少飯。2）鼓勵(lì)思考,，那怕那些想法很不靠譜,，因?yàn)槿绻婚_(kāi)始，那么將永遠(yuǎn)不會(huì)思考,。

• 必需使用快速迭代,。很多公司都在強(qiáng)行上敏捷，他們希望產(chǎn)品越快release越好,，而沒(méi)有充分的時(shí)間思考和討論,。對(duì)于這種項(xiàng)目，我的建議是,，1）找有豐富經(jīng)驗(yàn)的人來(lái)做,。2）迭代過(guò)程中力求架構(gòu)和程序邏輯的簡(jiǎn)單,，簡(jiǎn)單，再簡(jiǎn)單,，力求代碼間的高內(nèi)聚,，低耦合。不然,，重構(gòu)的時(shí)候你就好玩了,。

• 創(chuàng)業(yè)團(tuán)隊(duì)必需要快。做得快就是做得好嗎,？很多時(shí)候,，不是誰(shuí)快誰(shuí)就能笑到最后的。這樣的例子太多了,。第一個(gè)做出來(lái)的人并不一定就會(huì)占領(lǐng)市場(chǎng)，其很有可能會(huì)成為先驅(qū),。

• 有錢的公司才會(huì)讓團(tuán)隊(duì)用更多的時(shí)間去思考,。錯(cuò)了，你們沒(méi)有見(jiàn)過(guò)有錢的公司,，有錢的公司可以招一堆干不成活的人,，可以把事搞亂了再新來(lái)過(guò)，甚至可以把做失敗的項(xiàng)目換個(gè)名字再重新立項(xiàng),。這些真正的有錢的公司只求快,，只求人多，不怕做錯(cuò)決定,。像我們這些沒(méi)錢的人,，干什么事都是小心翼翼地，生怕做錯(cuò)決定,。

關(guān)于軟件項(xiàng)目管理的文章,，還可以參看《軟件公司的兩種管理方式》，最后,，歡迎大家表達(dá)觀點(diǎn),。