挨踢項目求生法則（4）——設計篇

摘要：

知道什麼是挨踢項目吧？什麼！不知道？那IT項目知道了吧？爲了避免讓客戶踢、不讓老闆踢、項目組成員之間不互相踢，俺爲你們分享一些減小被踢機會的心得體會。就算不能讓項目成功，也至少不會死得那麼慘吧！我將分團隊建設篇、戰略篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇爲你分享。

什麼叫挨踢項目？

IT項目，特別是軟件開發項目，都屬於「挨踢」項目的範疇。挨踢項目的幾大特色：
1.需求不肯定。
2.技術不肯定。
3.工期限死。
4.預算限死
兩大不肯定和兩大限死，你想不「挨踢」都難！

 

 

什麼是「漂亮」的設計？

一些關於軟件設計的資料提到，我們的設計須要高效、可靠、易用、安全、可擴展、兼容性強、移植性強……
每次看到這樣的文字，個人第一反應就是頭暈，這些基本就是廢話嘛！
軟件設計是爲軟件服務的，要服從項目的商業目標。一味追求所謂的優雅設計，項目可能會死的很慘。客戶購買的是軟件而不是你的設計。若是你在客戶面前介紹你的設計如何精妙、如何OO、如何依賴注入？那客戶只能當你是火星人看了，客戶並不會由於你的設計如何精妙而原諒你的推遲交付和增長費用。若是爲了節省時間，忽略設計或者粗略設計，項目一樣極可能會死得很慘！沒有想清楚就動手，就至關於冒着大霧往前走，可能走錯方向，可能跌入懸崖……

我認爲「漂亮」設計應該是這樣的：
1.能命中需求。
2.符合項目的戰略。
（什麼是戰略？請參考《挨踢項目求生法則-戰略篇》：http://blog.csdn.net/u010825142/article/details/9026279）
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://blog.csdn.net/u010825142/article/details/9042125

 

 

法則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：「編碼即設計」是合適的，但爛代碼除外

「編碼即設計」這個觀點我支持，我要進一步修正，應該是「好的編碼即設計」。架構設計文檔、數據庫設計文檔或不可缺，但詳細設計文檔是能夠直接經過編碼來代替的，但前提條件是該程序員的編程素質足夠好才行。
中國計算機教育培養出來的程序員，大多數是編程基本功不過關，在校沒有寫過多少代碼。這是一大問題，而另一大問題是這些編程基本功很水的人士，大多不會認識到本身的問題所在，還自認爲本身水平不錯，編程是小菜一碟的事情。遇到不肯意寫或者寫不出設計文檔，又自認爲本身編程水平很行但實際不好的項目組成員，就須要項目管理者多花心思來引導了。
有時候遇到一些編程新手，死活寫不出設計文檔，我會讓他直接經過編碼來思考。文檔可能沒有辦法讓他理清思路，那麼直接編碼來理清思路吧，你能夠經過他的代碼來了解他的想法並給出針對性的指導，幫助他提高水平。

 

 

做者：張傳波

創新工場創業課堂講師
華爲某團隊高級顧問

《火球——UML大戰需求分析》做者

www.umlonline.org 創辦人