我在我的微博上說過這樣一段話，我想在這裡把我的這個觀點闡述地更完整一些。
@左耳朵耗子：聰明的程序員使用50%-70%的時間用來思考，嘗試和權衡各種設計和實現，而用30% – 50%的時間是在忙碌著編碼，調試和測試。聰明的老闆也會讓團隊這樣做。而傻逼的老闆，苦逼的程序員會拿出來100%-150%的時間來忙著趕進度，返工，重構，fix 大量的bug… 所以， 越差的團隊一般會越忙，而且還忙不完。
在現在這個浮躁的時期，再加上敏捷諮詢師們念的歪經，他們讓人感覺上就像是軟體產品是可以在很短的時間內高質量的完成的，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實驗中的狗看到了肉就像流口水那樣興奮。他們使用TDD，快速迭代，不斷重構，持續集成直至持續部署的方法在進行軟體開發。
軟體開發真是這樣的嗎？難道不需要花時間去思考嗎？對此，有些觀點在Todd的《“品質在於構建過程”嗎？》以及《Bob大叔和Jim Coplien對TDD的論戰》中談到過了。我只想想表達下面的觀點：
- 軟體的精髓在於設計，設計是一件很費大腦的事件。對於軟體來說，設計沒有完美的，它總是一件需要取捨需要權衡的事，比如：時間換空間，空間換時間，TCP或UDP，同步還是非同步，數據冗餘還不冗餘等等。那怕是一個小小的observers模式是pull方式還是push方式 都需要仔細討論。這些的東西需要時間和做前期嘗試。
- TDD、快速原型和迭代可能會對軟體和團隊產生負面影響。在一開始，你需要花很大的精力來讓你的軟體從無到有（做過軟體的人都知道，從零開始寫代碼是很痛苦的事），但是因為你沒有想好，先做再說，所以，後期你會面臨更多的質量問題而讓你需要花更多的時間精力。當然，那些諮詢師會讓你用持續集成和持續部署這樣的方法。但我想告訴你，這並不解決你軟體設計的缺陷。舉個例子——TDD、迭代、原型只關注功能性需求，其不會關注非功能性需求，比如性能問題，高可用性問題，系統維護問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟體設計重新來過。
- 重構是惡夢，重構應該越少越好。當你維護一個複雜的系統時你會知道重構是一件多麼恐怖的事情（參看《重構代碼的7個階段》）。如果一開始沒有想好，你要面臨的不單單是re-design, re-architect，還要面對時間和人力成本的增加，最難的是你還要面對的是團隊士氣因為不斷的rework而逐漸低落併產生厭倦和懈怠情緒。
所以，如果你能有多一些時間去和客戶討論一下需求和未來可能的變化，去調查一下實現的技術難點和細節，去和其他有經驗的人討論並推敲一下架構和設計，去思考設計上的缺陷，那麼，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構，於是，你會在未來少寫很多代碼，從而你的軟體開發會越來越輕鬆，直到技術開始換代。
我現在在做的項目，花了幾乎4個月的時間來做設計，在這個過程中，我們反覆思考、討論和權衡若干種實現方法，並儘可能地窮舉所有的場景和細節以及未來可能的變化（那怕是那些簡單的模塊），有個模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個團隊不斷地在和其它團隊討論，並在對系統不斷地認識中對系統進行簡化和優化，并力求達到完美。現在看來，沒有貿然使用Scrum是明智的。
這就好像我們修路造橋一樣，我們需要花大量的時間勘測地形地質，分析數據，思考可能出現的各種問題（各種自然災害），評估不同的設計方案，而不是先儘快建好再說。
所以，多一些時間，不是讓你多做幾次迭代，多完成幾個模塊，而是可以讓你少寫一些代碼，更快的交付一個更好的產品。
我相信你會有很多疑問，下面是我覺得你可能會有下面的一些觀點，讓我一條一條來回復：
- 首當其衝的一定會是項目的deadline，或是那種你沒有活語權的項目。比如做那種“甲乙方合同式的項目”，我把這種項目統一認為是“外包項目”，在這種項目性質下，你很難有話語權。對此，我覺得，1）作為乙方的你還是應該和甲方在項目計劃上爭取一下，曉之以情，動之以理。2）如果不行，只能在時間、需求範圍和質量上做一個權衡。另外，在這種情況下你要找一個方法，把你的壓力和痛苦分擔給用戶和領導。（找到這個方法的前提需要你找到用戶和領導他們害怕什麼，嘿嘿）
- 過度設計和紙上談兵。有人說會不會設計太多，造成過度設計，或是在設計上花太多的時間。這有可能。我上一家公司的一個項目團隊就花了1年多的時間來不停不停的開會和做設計，結果release的時候還有1000多個bug。這個問題的原因是，這個團隊的設計是在紙上談兵，開會是開神仙會，討論的設計都是浮雲。所以，設計並不是討論和思考，還需要去嘗試，我認為當你的設計完成的時候，你的骨幹核心代碼都基本完成了。
- 我的團隊成員水平太差，不會思考。首先，先恭喜你找到一堆碼農，當然，這不怪你，這是中國教育和大環境的問題，讓人不會思考。對於這樣的情況，我有兩個建議，1）量力而行，使多大的碗就吃多少飯。2）鼓勵思考，那怕那些想法很不靠譜，因為如果不開始，那麼將永遠不會思考。
- 必需使用快速迭代。很多公司都在強行上敏捷，他們希望產品越快release越好，而沒有充分的時間思考和討論。對於這種項目，我的建議是，1）找有豐富經驗的人來做。2）迭代過程中力求架構和程序邏輯的簡單，簡單，再簡單，力求代碼間的高內聚，低耦合。不然，重構的時候你就好玩了。
- 創業團隊必需要快。做得快就是做得好嗎？很多時候，不是誰快誰就能笑到最後的。這樣的例子太多了。第一個做出來的人並不一定就會佔領市場，其很有可能會成為先驅。
- 有錢的公司才會讓團隊用更多的時間去思考。錯了，你們沒有見過有錢的公司，有錢的公司可以招一堆幹不成活的人，可以把事搞亂了再新來過，甚至可以把做失敗的項目換個名字再重新立項。這些真正的有錢的公司只求快，只求人多，不怕做錯決定。像我們這些沒錢的人，幹什麼事都是小心翼翼地，生怕做錯決定。
關於軟體項目管理的文章，還可以參看《軟體公司的兩種管理方式》，最後，歡迎大家表達觀點。
