撰寫詳細(xì)設(shè)計(jì)是一個(gè)逐步細(xì)化、深入的過程。沒有人能一次就設(shè)計(jì)出完美的東西，需要及時(shí)的溝通，包括與客戶的反饋，與其他項(xiàng)目組成員的討論，這樣有助于降低開發(fā)時(shí)偏離需求的風(fēng)險(xiǎn)。也就是說，在開發(fā)之前題，是建立在設(shè)計(jì)者的想法有客戶的確認(rèn)和開發(fā)人員的理解的基礎(chǔ)之上設(shè)計(jì)撰寫人必須與系統(tǒng)分析員反復(fù)討論，以透徹理解用戶需求；

一項(xiàng)需求可能有多種方式實(shí)現(xiàn)，設(shè)計(jì)者必須與系統(tǒng)分析員確定該需求將采用何種方式實(shí)現(xiàn)，將達(dá)到何種效果，以消除將需求映射為設(shè)計(jì)的歧義；討論過程中還可能會(huì)發(fā)現(xiàn)需求有不完備甚至錯(cuò)誤的地方，在需求重新確定后設(shè)計(jì)者需修正設(shè)計(jì)。設(shè)計(jì)文檔必須寫清楚各個(gè)模塊/接口/公共對(duì)象的定義，列明程序的各種執(zhí)行條件與期望的運(yùn)行效果，還要正確處理各種可能的異常。此外設(shè)計(jì)文檔應(yīng)該遵循一定的寫作模式與版面風(fēng)格，使用統(tǒng)一的術(shù)語或慣用語，使得小組成員很容易理解。以上這些活動(dòng)綜合起來將是一個(gè)很細(xì)致、很耗時(shí)的工作過程。就個(gè)人所知，一些公司的詳細(xì)設(shè)計(jì)通常是由程序主管或少數(shù)核心的程序員撰寫的，他們通常也是系統(tǒng)架構(gòu)的主要作者或維護(hù)者。因?yàn)樗麄冊(cè)陂_發(fā)團(tuán)隊(duì)中技術(shù)最為精湛，對(duì)架構(gòu)最為熟悉，他們最有資格評(píng)價(jià)現(xiàn)有架構(gòu)是否能適應(yīng)新的用戶需求，采用何種方式實(shí)現(xiàn)需求對(duì)架構(gòu)的沖擊最小。但是由少數(shù)人來負(fù)責(zé)所有的詳細(xì)設(shè)計(jì)可能造成開發(fā)過程中的瓶頸甚至是設(shè)計(jì)的錯(cuò)誤。當(dāng)任務(wù)比較集中的時(shí)候，設(shè)計(jì)者可能忙得透不過氣，而負(fù)責(zé)實(shí)現(xiàn)的同事反而在等米下鍋，比較清閑。于是為了讓自己不成為拖累進(jìn)度的“罪人”，某些設(shè)計(jì)者就會(huì)采用一種快捷方式來交付設(shè)計(jì)：他們會(huì)與系統(tǒng)分析員進(jìn)行初步的討論，然后撰寫一份粗糙的但仍然叫做詳細(xì)設(shè)計(jì)的文檔，把它交付給負(fù)責(zé)實(shí)現(xiàn)的同事，再通過討論、即時(shí)通工具、電子郵件等方式解答對(duì)方提出的疑問。但由于詳細(xì)設(shè)計(jì)本身不完備，他們不得不花費(fèi)更多的時(shí)間和精力與負(fù)責(zé)實(shí)現(xiàn)的同事溝通；而且他們卻很可能忘了把這些交流的成果更新到詳細(xì)設(shè)計(jì)中去！（或許是他們太忙，沒有足夠的時(shí)間，又或許是他們認(rèn)為既然產(chǎn)品已經(jīng)實(shí)現(xiàn)，那么詳細(xì)設(shè)計(jì)也就不必維護(hù)了。）其結(jié)果很可能是當(dāng)產(chǎn)品開發(fā)出來后，我們才發(fā)現(xiàn)它跟用戶要求的完全兩樣！原本在詳細(xì)設(shè)計(jì)階段就應(yīng)該發(fā)現(xiàn)的需求漏洞與在那時(shí)應(yīng)該確定的技術(shù)方案在實(shí)現(xiàn)階段甚至測(cè)試階段才暴露出來，而這時(shí)大家往往有木已成舟的感覺，改動(dòng)的難度比設(shè)計(jì)階段高數(shù)倍甚至十倍以上，畢竟任何再牛的人都有自己的局限。

對(duì)于以上問題我提出全員設(shè)計(jì)，全員設(shè)計(jì)的含義就是把詳細(xì)設(shè)計(jì)的工作進(jìn)行適當(dāng)?shù)胤纸?，把它們分?jǐn)偟叫〗M內(nèi)其它同事身上，讓大家都參與設(shè)計(jì)。這可以說明如下：

當(dāng)一組用戶需求基本確定下來后，程序主管需要估計(jì)需求的相關(guān)性、需求的優(yōu)先級(jí)、設(shè)計(jì)的難易程度、設(shè)計(jì)的工作量等，將該組需求分解為一或多項(xiàng)設(shè)計(jì)任務(wù)，并指定給適當(dāng)?shù)耐?。參與設(shè)計(jì)的每個(gè)人必須負(fù)責(zé)至少一項(xiàng)設(shè)計(jì)的撰寫任務(wù)。設(shè)計(jì)者從系統(tǒng)分析員處獲得詳細(xì)的用戶需求，并與系統(tǒng)分析員反復(fù)溝通以透徹理解用戶需求。他還要分析系統(tǒng)架構(gòu)及產(chǎn)品的已實(shí)現(xiàn)與/或已規(guī)劃部分，理解架構(gòu)的設(shè)計(jì)理念，理解產(chǎn)品不同模塊之間的協(xié)作關(guān)系，理解架構(gòu)與產(chǎn)品之間的約束和依賴。當(dāng)然對(duì)系統(tǒng)架構(gòu)和產(chǎn)品的分析不可能窮盡每一個(gè)細(xì)節(jié)，只要分析與即將開發(fā)的模塊相關(guān)的內(nèi)容即可。

一項(xiàng)設(shè)計(jì)任務(wù)，它可能需要多個(gè)程序員完成。比如用戶界面或網(wǎng)頁由某位或某組同事負(fù)責(zé)，而業(yè)務(wù)邏輯組件則由另一位或另一組負(fù)責(zé)，數(shù)據(jù)庫部分則又由其它同事負(fù)責(zé)。設(shè)計(jì)者必須考慮他們的立場(chǎng)，以各方面都相對(duì)容易理解的方式寫清楚主要的模塊/接口/對(duì)象定義，明確相應(yīng)的調(diào)用規(guī)則與主要邏輯處理。如果某項(xiàng)設(shè)計(jì)任務(wù)所涉及的內(nèi)容太專業(yè)化，設(shè)計(jì)者并不熟悉相關(guān)的內(nèi)容（比如某位C#程序員并不熟悉如何編寫一個(gè)存儲(chǔ)過程），他可以用描述性的文字說明該部分的設(shè)計(jì)要求，并知會(huì)相關(guān)的同事補(bǔ)充。其它同事在補(bǔ)充時(shí)可以對(duì)這些描述性的文字重新整理，以更加確切地表達(dá)設(shè)計(jì)內(nèi)容，更符合文檔的書寫慣例。在設(shè)計(jì)文檔完成后，設(shè)計(jì)者必須把他提交給程序主管或由程序主管指定的程序員審閱。個(gè)人推薦由其它程序員而不僅僅是程序主管來審閱。不用擔(dān)心等待多個(gè)人的審閱意見是否可能導(dǎo)致一份設(shè)計(jì)滯留很久。大家可以并行地工作，不必是A審閱后才能B審閱?？梢越徊鎸忛?，即A的設(shè)計(jì)由B、C審閱，B的設(shè)計(jì)由A、C審閱等。審閱意見可以用多種方式（如討論、即時(shí)通工具、電子郵件）反饋給設(shè)計(jì)者，設(shè)計(jì)者負(fù)責(zé)匯總這些意見并修正設(shè)計(jì)。以個(gè)人的經(jīng)驗(yàn)而言，通常設(shè)計(jì)交付審閱后半天內(nèi)就可以收到反饋意見了。設(shè)計(jì)經(jīng)過反復(fù)地修正直至沒有人再提出修正意見，這時(shí)就可以由程序員實(shí)現(xiàn)了。以個(gè)人的經(jīng)驗(yàn)而言，一份設(shè)計(jì)通常兩、三輪反饋后就可以定稿了。如果多次反饋后仍不能定稿，極有可能是：

a)需求尚未明確，各個(gè)方面（包括客戶、系統(tǒng)分析員或設(shè)計(jì)者）對(duì)需求的看法不統(tǒng)一

b)技術(shù)或系統(tǒng)架構(gòu)存在嚴(yán)重的限制，無法用較方便的方式實(shí)現(xiàn)

全員參與設(shè)計(jì)好處、風(fēng)險(xiǎn)與不適用的團(tuán)隊(duì)如下：

1.2.1 全員設(shè)計(jì)可以帶來以下明顯的好處

1.有助于平衡工作量，加快開發(fā)進(jìn)度。詳細(xì)設(shè)計(jì)的任務(wù)分解后，程序主管或核心程序員可以有更多的時(shí)間處理其它的事務(wù)，比如關(guān)注軟件的開發(fā)質(zhì)量或改善系統(tǒng)架構(gòu)。詳細(xì)設(shè)計(jì)的撰寫任務(wù)分解后它們可以并行地撰寫，這將極大地提高設(shè)計(jì)撰寫的進(jìn)度，節(jié)約時(shí)間。

2.有助于培養(yǎng)程序員的大局觀。每位撰寫設(shè)計(jì)的程序員不再僅僅只關(guān)心自己負(fù)責(zé)實(shí)現(xiàn)的模塊，他必須從更高的層次考慮和理解設(shè)計(jì)。

3.有助于加強(qiáng)同事之間的交流與協(xié)作。設(shè)計(jì)者需要與系統(tǒng)分析員、其它程序員、審閱者進(jìn)行反復(fù)的交流和溝通，實(shí)際上每份設(shè)計(jì)都是多人協(xié)作的成果。更多的溝通有助于集思廣益，有助于避免一、兩個(gè)人的傾向性意見導(dǎo)致錯(cuò)誤的設(shè)計(jì)。每位設(shè)計(jì)者都需要對(duì)自己撰寫的設(shè)計(jì)負(fù)責(zé)，他還要向其它同事的設(shè)計(jì)提供審閱意見或技術(shù)建議，彼此的工作是互相支持和依賴的，這有助于減少“只掃自家門前雪，不管他人瓦上霜”的想法。

1.2.2 推行全員設(shè)計(jì)的潛在風(fēng)險(xiǎn)

1.在某種意義上，全員設(shè)計(jì)可能增加交流的成本。兩個(gè)人之間有一條交流途徑，三個(gè)人之間最多有三條，四個(gè)人之間最多有六條。途徑越多，信息量就越大，而這些信息不見得都是有用的信息。詳細(xì)設(shè)計(jì)的任務(wù)分解后，不可避免地有更多的人參與交流和溝通，大家要花更多的時(shí)間來理解他人的想法，也可能要花更多的時(shí)間向他人闡述自己的觀點(diǎn)。特別是在并行撰寫詳細(xì)設(shè)計(jì)的過程中，系統(tǒng)分析員反而可能成為另一個(gè)瓶頸了。但從總體上來看，在設(shè)計(jì)階段花費(fèi)適當(dāng)?shù)拇鷥r(jià)發(fā)現(xiàn)更多的問題，比在實(shí)現(xiàn)階段或測(cè)試階段再發(fā)現(xiàn)問題，仍然是劃算的。

2.分解后的詳細(xì)設(shè)計(jì)可能引入沖突的設(shè)計(jì)內(nèi)容。由于設(shè)計(jì)由不同的程序員撰寫，他們考慮問題的角度和思維的方式不可能完全一致，這增大了不同的設(shè)計(jì)內(nèi)容之間的計(jì)算口徑或交互方式不一致的可能性。這需要設(shè)計(jì)者們盡可能遵循一致的設(shè)計(jì)原則，也需要審閱者們盡可能找到這些不一致的地方。

3.并不是所有的程序員都適合參與設(shè)計(jì)。很明顯，例如剛?cè)肼毜耐戮筒贿m合參與設(shè)計(jì)，他們對(duì)系統(tǒng)架構(gòu)還缺乏足夠的認(rèn)識(shí)。另外兼職的同事也不適合參與設(shè)計(jì)，他們的工作方式可能無法保證及時(shí)提交設(shè)計(jì)文檔與參與討論等。