摘要：
知道什麼是挨踢專案吧？什麼！不知道？那it專案知道了吧？為了不讓客戶踢、不讓老闆踢、專案組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓專案成功，也至少不會死得那麼慘吧！我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計畫篇為你分享。
什麼叫挨踢專案？
it專案，特別是軟體開發專案，都屬於「挨踢」專案的範疇。挨踢專案的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不「挨踢」都難！
作者：
張傳波www.umlonline.org
什麼是「漂亮」的設計？
以前公司過iso的時候，其中乙個我覺得比較厭煩的問題是：軟體的實際設計已經和設計文件不符了，iso內審員要求我去更新設計文件。為了避免這些麻煩，我試圖將設計文件寫得比較粗和通用，這樣就大大降低了需要更新文件的機會。如果將設計進一步抽象化，我完全可以寫出乙個n層架構的設計出來，這樣的設計可以復用到n多專案上，每個專案的設計文件複製這個設計就可以了。但問題是：我們的軟體設計就是為了得到乙個不用怎樣修改的文件嗎？況且這樣粗的設計對專案實際工作有什麼實用價值呢？
在某專案管理
培訓中我展示了某專案的某模組的詳細設計文件，但有學員提出了質疑，從他的經歷看來，無法讓程式設計師寫出類似這樣的文件。寫不出文件，是因為沒有能想清楚？還是因為不會中文呢？軟體設計並不是寫文件，而是通過探索和思考，想出解決問題的方案，文件寫不出了沒有關係，關鍵是你有沒有解決方案？哪怕這個方案存在與你的腦袋當中，你能不能清晰的表達出來？表達的方式不一定是文件，可以是口頭表達，可以是通過demo來展示等等。
現在可以來回答「為什麼需要設計？」這個問題了，我的觀點如下：
1.需求解決做什麼的問題，而設計是解決怎樣做的問題。
2.如何更簡單、更少工作量地解決怎樣做的問題，是設計工作的重點。
3.需求工作決定了軟體的價值，而設計決定了軟體的成本。
4.寫設計文件並不等同於軟體設計，軟體設計在於探索、思考、實踐，摸索出有效的解決方案、具體做法等。
5.word文件僅是軟體設計的其中一種表現形式而已。
6.設計不是一次成型就不變的，而是需要持續優化和改進。
我們需要做什麼設計？
設計包括概要設計和詳細設計，這是我們慣常的認識，但我將設計分為以下幾方面的內容：架構設計、模組設計、資料庫設計、使用者體驗設計。
架構設計可以近似看作是概要設計，架構設計是通盤考慮了所有軟體需求後的乙個巨集觀設計，我通常會用uml的部署圖、元件圖和包圖進行架構設計，設計的粒度會達到元件及模組級別。
模組設計是指在架構設計的基礎上，在軟體系統劃分成n個模組，每個模組進行詳細設計。我通常會用uml的類圖、順序圖來進行模組設計，設計的粒度會達到類、類的方法和屬性、類之間的呼叫關係等。
資料庫設計這個不用多解釋，粒度要達到最終實現的程度，而使用者體驗設計可能需要多加解釋了。
使用者體驗是指使用者使用軟體時的整體感覺，使用者體驗設計需要考慮清楚軟體的整體介面規劃、介面先後關係、文字表達、軟體與使用者如何互動等等。說到使用者體驗設計，很多人直接反應就是美工的事情，這是不對的，美工僅是使用者體驗設計的一小部分內容而已。乙個軟體如果內部實現很爛，但使用者體驗設計做得很好，那麼這個軟體仍然會很受歡迎。相反，乙個軟體的使用者體驗設計很爛，哪怕軟體的內部設計很精妙，客戶也不會賣賬。從這個角度上看，使用者體驗設計是相當重要的，但使用者體驗設計往往是被忽略的。很多軟體公司沒有專門的使用者體驗設計職位，往往由程式設計師自己設計軟體與使用者的互動，做出來的軟體非常不人性化。
我在以前的公司做專案，乙個專案一般會有1份架構設計文件，1份或者多份模組設計文件，1份資料庫設計文件和1份使用者體驗設計文件。我想說明的是，以上提到的四種設計並不是非要對號入座，每種設計對應乙份或多份文件，而是軟體設計應該包含這四方面的內容，至於文件的數量和形式沒有規定，你可以乙個文件包含四個方面的內容。另外還要說明的是，並不是軟體所有的模組都需要寫詳細的設計文件的，如果該模組的實現方法已經很成熟，成為專案組的「常識」，這些內容沒有必要額外再寫文件。
法則1：需求驅動設計
以前曾經參加某專案的某設計文件的評審，大家圍著乙個區域性的技術問題進行討論，但爭論的內容僅僅是一些軟體設計上的大道理，每個人對這些大道理詮釋不同而已。於是我問：大家知道這個專案的需求嗎？能不能列出設計中需要重點考慮的需求是哪些？居然沒有人能答出來！
我去評審設計文件很簡單，就是事先將需求搞清楚，列出設計中需要重點考慮的需求，然後看看設計文件是如何考慮這些需求的實現。設計就是用來滿足需求的，用需求來檢驗設計文件，這是很基本的「常識」，但這個常識往往被我們忽略。編寫設計文件的為「節省」時間，不去全面深入理解需求就去寫設計文件，參加設計評審的為「節省」時間也不去了解需求，這樣設計和設計評審就變成了走形式、浪費時間的事情。
前面提到設計決定了軟體的工作量，在設計時間上「節省」時間，你的代價就是將會花數倍甚至數十倍以上的專案工作量。認真地需求驅動地做好設計工作，這是必須的。下面簡單介紹一下什麼需求驅動什麼設計：
1.架構設計是通盤考慮全部需求後設計出來的，所以可以說：全部需求驅動架構設計。
2.模組設計是在架構設計的基礎上，針對區域性需求的具體實現設計出來的，也就是說：區域性需求驅動某模組設計。
3.資料庫設計是整理了全部需求當中的業務資料，思考這些業務資料如何在資料庫中訪問後設計出來的，也就是說：業務資料驅動資料庫設計。
4.使用者體驗設計需要考慮業務流程、業務資料等，為滿足客戶的業務目標，我們設計出來的系統與使用者之間的互動細節等，也就是說：業務流程、業務資料、業務目標等驅動使用者體驗設計。
「需求驅動設計」這句話還不夠具體，還要進一步細化，什麼需求驅動什麼設計！上述幾點是我以往工作的簡單總結。
關於需求，請參考《挨踢專案求生法則-需求篇》：
法則2：不要誤解「簡單設計」
極限程式設計中提到「簡單設計」，有些朋友很興奮，終於可以用「簡單設計」作為不寫設計文件的理由了！
什麼是「簡單設計」呢？以下情況是不是簡單設計呢？
1.簡單想一下，然後快速做乙個設計。
2.沒有設計文件的設計，就是簡單設計。
3.不設計就是最簡單的設計。
4.編碼就是設計。
極限程式設計對「簡單設計」的詮釋可以總結為兩點：
1.不要考慮太長遠，僅考慮當前的需求。
2.用最簡單的辦法來實現。
我基本認同這個觀點，但問題一些朋友的理解可能出現了偏差。第2點「用最簡單的辦法」這是很難做到的，將事情簡單化這是難度很高、很考驗智慧型的事情。「簡單想一下」是很難想出「最簡單的辦法」的，隨便想一下想出來的辦法，往往是工作量巨大的辦法！簡單設計的意思是指要讓專案工作變得簡單，而不是將設計的思考過程簡單化。軟體設計是一種智力投資，多花一小時想清楚如何讓專案工作變得更加簡單，會節省你更多的專案時間。
法則3：做高價效比的設計
一些qa通常用這樣的理由來說服專案組編寫設計文件：
1.為了讓將來接手專案的同事搞清楚狀況，設計文件是必須的。
2.將來你自己也很可能需要改程式的，現在寫下文件對你將來的工作有用。
以上的做法，就好象你對乙個正在挨饑荒的人說：現在多存點糧食吧，對你將來有用。聽你勸說的人肯定氣死了，恨不得吃掉你充飢！
所以以上的理由是不能驅動專案組寫設計文件的，設計文件應該達到這樣的效果：對專案當前的工作有用，能幫助我立刻解決問題！如果設計文件不能達到這樣的效果，就不能驅動專案組寫好設計文件。
設計文件必須先保證對自己、對專案組本身的當前工作有用，在這前提下有條件才去考慮對自己的將來有用、對別人有用。也只有立足於這個出發點下，才可能寫出有實際價值的文件，文件不是擺設，是要立馬在工作中用上的。
法則6：設計文件不一定是word文件
有這樣一種觀點：**沒有設計文件是不符合cmmi要求的。
你認為是不是所有**都應該對應有詳細設計文件呢？
資料庫四輪馬車的操作如果你們公司已經駕輕就熟了，你們專案組閉著眼睛都能做了，你還會寫乙份詳細的設計文件，然後對著該文件編碼嗎？
並不是所有的地方都需要設計文件，僅在需要的地方才寫設計文件，我的做法通常是這樣的：
1.架構設計文件一般不可缺。
2.資料庫設計文件一般也不可缺。
3.並不是所有模組都要寫設計文件的，一般在以下情況下才寫該模組的詳細設計文件：
1）演算法比較複雜；
2）想法不太成熟；
3）負責該模組的程式設計師是新人等。
4.使用者體驗設計文件一般也不可缺，但文件的內容一般不會覆蓋軟體的全部內容，成為「常識」的內容不需要寫。
法則8：「編碼即設計」是合適的，但爛**除外
「編碼即設計」這個觀點我支援，我要進一步修正，應該是「好的編碼即設計」。架構設計文件、資料庫設計文件或不可缺，但詳細設計文件是可以直接通過編碼來代替的，但前提條件是該程式設計師的程式設計素質足夠好才行。
中國計算機教育培養出來的程式設計師，大多數是程式設計基本功不過關，在校沒有寫過多少**。這是一大問題，而另外一大問題是這些程式設計基本功很水的人士，大多不會認識到自己的問題所在，還自認為自己水平不錯，程式設計是小菜一碟的事情。遇到不願意寫或者寫不出設計文件，又自認為自己程式設計水平很行但實際很差的專案組成員，就需要專案管理者多花心思來引導了。
有時候遇到一些程式設計新手，死活寫不出設計文件，我會讓他直接通過編碼來思考。文件可能沒有辦法讓他理清思路，那麼直接編碼來理清思路吧，你可以通過他的**來了解他的想法並給出針對性的指導，幫助他提公升水平。
--------本篇完-------
作者：
張傳波www.umlonline.org
挨踢專案求生法則 需求篇
摘要 知道什麼是挨踢專案吧？什麼！不知道？那it專案知道了吧？為了不讓客戶踢 不讓老闆踢 專案組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓專案成功，也至少不會死得那麼慘吧！我將分戰略篇 團隊建設篇 需求篇 設計篇 編碼篇 測試篇 實施篇和計畫篇為你分享。作者 張傳波 www...
挨踢專案求生法則 計畫篇，計畫趕不上變化！
摘要 計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！說明 什麼叫挨踢專案？it專案，特別是軟體開發專案，都屬於 挨踢 專案的範疇。挨踢專...
挨踢專案求生法則 計畫篇，計畫趕不上變化！
摘要 計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！說明 什麼叫挨踢專案？it專案，特別是 軟體開發專案，都屬於 挨踢 專案的範疇。挨踢...