挨踢項目求生法則-設計篇

摘要：

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

什麼叫挨踢項目？

IT項目，特别是軟體開發項目，都屬于“挨踢”項目的範疇。挨踢項目的幾大特點：

1.需求不确定。

2.技術不确定。

3.工期限死。

4.預算限死

兩大不确定和兩大限死，你想不“挨踢”都難！

作者：

張傳波

www.umlonline.org

什麼是“漂亮”的設計？

一些關于軟體設計的資料提到，咱們的設計需要高效、可靠、易用、安全、可擴充、相容性強、移植性強……

每次看到這樣的文字，我的第一反應就是頭暈，這些基本就是廢話嘛！

軟體設計是為軟體服務的，要服從項目的商業目标。一味追求所謂的優雅設計，項目可能會死的很慘。客戶購買的是軟體而不是你的設計。如果你在客戶面前介紹你的設計如何精妙、如何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：“編碼即設計”是合适的，但爛代碼除外

“編碼即設計”這個觀點我支援，我要進一步修正，應該是“好的編碼即設計”。架構設計文檔、資料庫設計文檔或不可缺，但詳細設計文檔是可以直接通過編碼來代替的，但前提條件是該程式員的程式設計素質足夠好才行。

中國計算機教育培養出來的程式員，大多數是程式設計基本功不過關，在校沒有寫過多少代碼。這是一大問題，而另外一大問題是這些程式設計基本功很水的人士，大多不會認識到自己的問題所在，還自認為自己水準不錯，程式設計是小菜一碟的事情。遇到不願意寫或者寫不出設計文檔，又自認為自己程式設計水準很行但實際很差的項目組成員，就需要項目管理者多花心思來引導了。

有時候遇到一些程式設計新手，死活寫不出設計文檔，我會讓他直接通過編碼來思考。文檔可能沒有辦法讓他理清思路，那麼直接編碼來理清思路吧，你可以通過他的代碼來了解他的想法并給出針對性的指導，幫助他提升水準。

如果本文對你有幫助，麻煩點選一下“推薦”，謝謝！

--------本篇完-------

轉載請注明作者及出處，否則請不要轉載，謝謝！