摘要：
知道什么是挨踢項目吧？什么！不知道？那IT項目知道了吧？為了不讓客戶踢、不讓老板踢、項目組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓項目成功，也至少不會死得那么慘吧！我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計划篇為你分享。
什么叫挨踢項目？
IT項目，特別是軟件開發項目，都屬於“挨踢”項目的范疇。挨踢項目的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不“挨踢”都難！
作者：
什么是“漂亮”的設計？
一些關於軟件設計的資料提到，咱們的設計需要高效、可靠、易用、安全、可擴展、兼容性強、移植性強……
每次看到這樣的文字，我的第一反應就是頭暈，這些基本就是廢話嘛！
軟件設計是為軟件服務的，要服從項目的商業目標。一味追求所謂的優雅設計，項目可能會死的很慘。客戶購買的是軟件而不是你的設計。如果你在客戶面前介紹你的設計如何精妙、如何OO、如何依賴注入？那客戶只能當你是火星人看了，客戶並不會因為你的設計如何精妙而原諒你的推遲交付和增加費用。如果為了節省時間，忽略設計或者粗略設計，項目同樣很可能會死得很慘！沒有想清楚就動手，就相當於冒着大霧往前走，可能走錯方向，可能跌入懸崖……
我認為“漂亮”設計應該是這樣的：
1.能命中需求。
2.符合項目的戰略。
（什么是戰略？請參考《挨踢項目求生法則-戰略篇》：http://www.cnblogs.com/umlonline/archive/2011/11/04/2228308.html）
3.做適度的設計。
當然以上內容可能仍然不夠清楚，請繼續閱讀下文。
為什么需要設計？
以前公司過ISO的時候，其中一個我覺得比較厭煩的問題是：軟件的實際設計已經和設計文檔不符了，ISO內審員要求我去更新設計文檔。為了避免這些麻煩，我試圖將設計文檔寫得比較粗和通用，這樣就大大降低了需要更新文檔的機會。如果將設計進一步抽象化，我完全可以寫出一個N層架構的設計出來，這樣的設計可以復用到n多項目上，每個項目的設計文檔復制這個設計就可以了。但問題是：我們的軟件設計就是為了得到一個不用怎樣修改的文檔嗎？況且這樣粗的設計對項目實際工作有什么實用價值呢？
在某項目管理培訓中我展示了某項目的某模塊的詳細設計文檔，但有學員提出了質疑，從他的經歷看來，無法讓程序員寫出類似這樣的文檔。寫不出文檔，是因為沒有能想清楚？還是因為不會中文呢？軟件設計並不是寫文檔，而是通過探索和思考，想出解決問題的方案，文檔寫不出了沒有關系，關鍵是你有沒有解決方案？哪怕這個方案存在與你的腦袋當中，你能不能清晰的表達出來？表達的方式不一定是文檔，可以是口頭表達，可以是通過Demo來展示等等。
現在可以來回答“為什么需要設計？”這個問題了，我的觀點如下：
1.需求解決做什么的問題，而設計是解決怎樣做的問題。
2.如何更簡單、更少工作量地解決怎樣做的問題，是設計工作的重點。
3.需求工作決定了軟件的價值，而設計決定了軟件的成本。
4.寫設計文檔並不等同於軟件設計，軟件設計在於探索、思考、實踐，摸索出有效的解決方案、具體做法等。
5.Word文檔僅是軟件設計的其中一種表現形式而已。
6.設計不是一次成型就不變的，而是需要持續優化和改進。
我們需要做什么設計？
設計包括概要設計和詳細設計，這是我們慣常的認識，但我將設計分為以下幾方面的內容：架構設計、模塊設計、數據庫設計、用戶體驗設計。
架構設計可以近似看作是概要設計，架構設計是通盤考慮了所有軟件需求后的一個宏觀設計，我通常會用UML的部署圖、組件圖和包圖進行架構設計，設計的粒度會達到組件及模塊級別。
模塊設計是指在架構設計的基礎上，在軟件系統划分成n個模塊，每個模塊進行詳細設計。我通常會用UML的類圖、順序圖來進行模塊設計，設計的粒度會達到類、類的方法和屬性、類之間的調用關系等。
數據庫設計這個不用多解釋，粒度要達到最終實現的程度，而用戶體驗設計可能需要多加解釋了。
用戶體驗是指用戶使用軟件時的整體感覺，用戶體驗設計需要考慮清楚軟件的整體界面規划、界面先后關系、文字表達、軟件與用戶如何交互等等。說到用戶體驗設計，很多人直接反應就是美工的事情，這是不對的，美工僅是用戶體驗設計的一小部分內容而已。一個軟件如果內部實現很爛，但用戶體驗設計做得很好，那么這個軟件仍然會很受歡迎。相反，一個軟件的用戶體驗設計很爛，哪怕軟件的內部設計很精妙，客戶也不會賣賬。從這個角度上看，用戶體驗設計是相當重要的，但用戶體驗設計往往是被忽略的。很多軟件公司沒有專門的用戶體驗設計職位，往往由程序員自己設計軟件與用戶的交互，做出來的軟件非常不人性化。
我在以前的公司做項目，一個項目一般會有1份架構設計文檔，1份或者多份模塊設計文檔，1份數據庫設計文檔和1份用戶體驗設計文檔。我想說明的是，以上提到的四種設計並不是非要對號入座，每種設計對應一份或多份文檔，而是軟件設計應該包含這四方面的內容，至於文檔的數量和形式沒有規定，你可以一個文檔包含四個方面的內容。另外還要說明的是，並不是軟件所有的模塊都需要寫詳細的設計文檔的，如果該模塊的實現方法已經很成熟，成為項目組的“常識”，這些內容沒有必要額外再寫文檔。
法則1：需求驅動設計
以前曾經參加某項目的某設計文檔的評審，大家圍着一個局部的技術問題進行討論，但爭論的內容僅僅是一些軟件設計上的大道理，每個人對這些大道理詮釋不同而已。於是我問：大家知道這個項目的需求嗎？能不能列出設計中需要重點考慮的需求是哪些？居然沒有人能答出來！
我去評審設計文檔很簡單，就是事先將需求搞清楚，列出設計中需要重點考慮的需求，然后看看設計文檔是如何考慮這些需求的實現。設計就是用來滿足需求的，用需求來檢驗設計文檔，這是很基本的“常識”，但這個常識往往被我們忽略。編寫設計文檔的為“節省”時間，不去全面深入理解需求就去寫設計文檔，參加設計評審的為“節省”時間也不去了解需求，這樣設計和設計評審就變成了走形式、浪費時間的事情。
前面提到設計決定了軟件的工作量，在設計時間上“節省”時間，你的代價就是將會花數倍甚至數十倍以上的項目工作量。認真地需求驅動地做好設計工作，這是必須的。下面簡單介紹一下什么需求驅動什么設計：
1.架構設計是通盤考慮全部需求后設計出來的，所以可以說：全部需求驅動架構設計。
2.模塊設計是在架構設計的基礎上，針對局部需求的具體實現設計出來的，也就是說：局部需求驅動某模塊設計。
3.數據庫設計是整理了全部需求當中的業務數據，思考這些業務數據如何在數據庫中存取后設計出來的，也就是說：業務數據驅動數據庫設計。
4.用戶體驗設計需要考慮業務流程、業務數據等，為滿足客戶的業務目標，我們設計出來的系統與用戶之間的交互細節等，也就是說：業務流程、業務數據、業務目標等驅動用戶體驗設計。
“需求驅動設計”這句話還不夠具體，還要進一步細化，什么需求驅動什么設計！上述幾點是我以往工作的簡單總結。
關於需求，請參考《挨踢項目求生法則-需求篇》：
http://www.cnblogs.com/umlonline/archive/2011/11/15/2239181.html
法則2：不要誤解“簡單設計”
極限編程中提到“簡單設計”，有些朋友很興奮，終於可以用“簡單設計”作為不寫設計文檔的理由了！
什么是“簡單設計”呢？以下情況是不是簡單設計呢？
1.簡單想一下，然后快速做一個設計。
2.沒有設計文檔的設計，就是簡單設計。
3.不設計就是最簡單的設計。
4.編碼就是設計。
極限編程對“簡單設計”的詮釋可以總結為兩點：
1.不要考慮太長遠，僅考慮當前的需求。
2.用最簡單的辦法來實現。
我基本認同這個觀點，但問題一些朋友的理解可能出現了偏差。第2點“用最簡單的辦法”這是很難做到的，將事情簡單化這是難度很高、很考驗智慧的事情。“簡單想一下”是很難想出“最簡單的辦法”的，隨便想一下想出來的辦法，往往是工作量巨大的辦法！簡單設計的意思是指要讓項目工作變得簡單，而不是將設計的思考過程簡單化。軟件設計是一種智力投資，多花一小時想清楚如何讓項目工作變得更加簡單，會節省你更多的項目時間。
法則3：做高性價比的設計
在符合項目戰略的情況下，用盡量少的工作量來實現需求，這基本上就是“高性價比”的意思。
實際上我們不太可能做出一個“最好”的或者說“完美無缺”的設計，因為有以下的條件限制：
1.有限的項目工期。
2.有限的項目預算。
3.項目成員的能力條件限制。
軟件設計是高難度的技術活，需要你做出適當的取舍和平衡，做出一個合適的設計。
但高性價比的設計意味着：
1.公司項目的利潤更加大，公司賺錢更多了，咱們能分到的錢也就更多了。
2.項目工作更加簡單，項目組不需要加班或少加班就能完成工作。
3.高性價比設計是挑戰智力的工作，會讓你的工作更加有愉悅感和成就感。
所以為了公司好、你好、大家好，向“高性價比設計”的目標進發吧！
法則4：人人都是軟件設計師
有這樣一種觀點：由軟件設計師設計出詳細的設計，程序員按“圖紙施工”便可。
我不喜歡將軟件研發工作變成流水線的工作，將研發過程分割為需求、設計、編碼、測試等幾個環節，每個環節有專職的人員，他們做好本職工作就可以了。這樣的工作模式有以下幾個問題：
1.人變成了機器，沒有創造力可言。
2.每個人對工作職責負責，而不是對項目成功負責。
3.這樣的模式不可能產生創意，也意味着不可能完成復雜的、需要創造力的項目。
我認為項目組中每個人都可以是軟件設計師，不要剝奪程序員思考的機會，不要將他們變成按圖紙施工的機械人。
在我的項目中，我是這樣做的：
1.架構設計和數據庫設計由富有經驗的程序員負責，其他項目成員參與學習和評審該設計。
2.模塊設計由將來負責該模塊編碼的程序員負責，架構設計師來評審該設計。
3.用戶體驗設計由測試工程師或實施工程師負責，程序員參與。
法則5：設計文檔應該先己后人
一些QA通常用這樣的理由來說服項目組編寫設計文檔：
1.為了讓將來接手項目的同事搞清楚狀況，設計文檔是必須的。
2.將來你自己也很可能需要改程序的，現在寫下文檔對你將來的工作有用。
以上的做法，就好象你對一個正在挨飢荒的人說：現在多存點糧食吧，對你將來有用。聽你勸說的人肯定氣死了，恨不得吃掉你充飢！
所以以上的理由是不能驅動項目組寫設計文檔的，設計文檔應該達到這樣的效果：對項目當前的工作有用，能幫助我立刻解決問題！如果設計文檔不能達到這樣的效果，就不能驅動項目組寫好設計文檔。
設計文檔必須先保證對自己、對項目組本身的當前工作有用，在這前提下有條件才去考慮對自己的將來有用、對別人有用。也只有立足於這個出發點下，才可能寫出有實際價值的文檔，文檔不是擺設，是要立馬在工作中用上的。
法則6：設計文檔不一定是Word文檔
以前曾經遇到一個挺郁悶的事情：
某項目用SQL Server數據庫，我直接在SQL上進行設計，也就是說數據庫的設計與實現一起做了。在數據庫上做設計的好處有：
1.設計馬上得到驗證。
2.以利用數據庫的特性做很多設計上的探索，讓設計做得更好。
3.設計完成了，數據庫也建成了，不需要再做一次，節省很多時間。
我很喜歡這樣做，但QA認為我沒有數據庫設計文檔，不符合ISO的要求。我覺得很郁悶，數據庫這個文檔就是數據庫設計文檔，干嘛非要寫一個Word文檔？后來迫於要ISO審核，我用復制粘貼大法寫了這個數據庫設計的Word文檔。如果項目使用的數據庫只有一種，我覺得直接在該數據庫上做設計沒有什么不妥，當然如果你的項目需要支持多種數據庫時，該做法可能不妥。
通過這個例子我想說明的是：設計的表現形式可以很多，不一定是Word文檔，怎樣的方式對當前項目工作最有效，就應該采用怎樣的方式。當然有人會說，寫下Word文檔對將來的人有好處，但前面的法則說了，要“先己后人”而不是“先人后己”，如果我現在就餓死了，你讓我現在存糧有啥意義？況且Word文檔並不一定是所有軟件設計的最佳表現形式。
法則7：不是所有地方都需要有設計文檔
有這樣一種觀點：代碼沒有設計文檔是不符合CMMI要求的。
你認為是不是所有代碼都應該對應有詳細設計文檔呢？
數據庫四輪馬車的操作如果你們公司已經駕輕就熟了，你們項目組閉着眼睛都能做了，你還會寫一份詳細的設計文檔，然后對着該文檔編碼嗎？
並不是所有的地方都需要設計文檔，僅在需要的地方才寫設計文檔，我的做法通常是這樣的：
1.架構設計文檔一般不可缺。
2.數據庫設計文檔一般也不可缺。
3.並不是所有模塊都要寫設計文檔的，一般在以下情況下才寫該模塊的詳細設計文檔：
1）算法比較復雜；
2）想法不太成熟；
3）負責該模塊的程序員是新人等。
4.用戶體驗設計文檔一般也不可缺，但文檔的內容一般不會覆蓋軟件的全部內容，成為“常識”的內容不需要寫。
法則8：“編碼即設計”是合適的，但爛代碼除外
“編碼即設計”這個觀點我支持，我要進一步修正，應該是“好的編碼即設計”。架構設計文檔、數據庫設計文檔或不可缺，但詳細設計文檔是可以直接通過編碼來代替的，但前提條件是該程序員的編程素質足夠好才行。
中國計算機教育培養出來的程序員，大多數是編程基本功不過關，在校沒有寫過多少代碼。這是一大問題，而另外一大問題是這些編程基本功很水的人士，大多不會認識到自己的問題所在，還自認為自己水平不錯，編程是小菜一碟的事情。遇到不願意寫或者寫不出設計文檔，又自認為自己編程水平很行但實際很差的項目組成員，就需要項目管理者多花心思來引導了。
有時候遇到一些編程新手，死活寫不出設計文檔，我會讓他直接通過編碼來思考。文檔可能沒有辦法讓他理清思路，那么直接編碼來理清思路吧，你可以通過他的代碼來了解他的想法並給出針對性的指導，幫助他提升水平。
如果本文對你有幫助，麻煩點擊一下“推薦”，謝謝！
--------本篇完-------
轉載請注明作者及出處，否則請不要轉載，謝謝！
作者：