回顧自己所經(jīng)歷的兩個項目，來對設(shè)計階段進行了總結(jié)，自己也算是個XPer，經(jīng)歷過的這兩個項目也基本都是采用XP的方式進展，大家都知道，XP在設(shè)計階段推崇的是群體設(shè)計，通過CRC來完成，在這里就對兩個項目執(zhí)行的情況做做總結(jié)。
項目A
一個大型項目，當(dāng)時的團隊相當(dāng)于是兩個設(shè)計師加上三個高程組成，迭代會議完成用戶故事分解、CRC設(shè)計以及任務(wù)分配，典型的XP方式，項目開展過程中應(yīng)該是整個過程都執(zhí)行的不錯，盡管現(xiàn)在回想當(dāng)時的CRC做的并不是很好，但應(yīng)該說在整個項目開展過程中并沒有出現(xiàn)多少問題，項目需求的實現(xiàn)都還算正常，整個團隊的提高也是非常的不錯，共同進步。
項目B
一個框架型項目，團隊成員是一個設(shè)計師、一個高程加上四個初程，同樣的XP方式的設(shè)計，項目開展過程中出現(xiàn)了不少問題，設(shè)計師不得不花大量的時間在技術(shù)支持上，而且最后項目的結(jié)果無論是需求上還是設(shè)計上都產(chǎn)生了不小的偏差，整個團隊的提高也沒達到期望的效果，而由于設(shè)計師過多的投入在技術(shù)支持上，使得架構(gòu)的完善一直存在偏離。
為什么同樣的過程在兩個不同的項目、不同的團隊中執(zhí)行的效果會相差這么遠呢？
首先從項目類型分析，項目A屬于實際項目，項目B屬于研發(fā)項目，兩個項目的關(guān)注點不同，項目A的關(guān)注點是客戶需求，項目B的關(guān)注點則更多的是擴展性和二次開發(fā)的易用性，在這兩類項目中設(shè)計幾乎是完全不同的，項目A更多的是業(yè)務(wù)的復(fù)雜度，而項目B更多的卻是技術(shù)的復(fù)雜度，從這個方面分析下來得出的結(jié)果其實就是項目A更重人員的業(yè)務(wù)能力，而項目B更重人員的技術(shù)能力，當(dāng)時項目A團隊中的人員對該項目的業(yè)務(wù)應(yīng)該說都屬于熟悉的那種，覺得這也是成功的原因之一，而項目B團隊中的人員技術(shù)相對項目要求來講是不足的。
接著從項目成員本身分析，項目A中的幾個成員基本都屬于能夠獨當(dāng)一面的人，而項目B中的成員水平參差不齊，覺得這也是在兩個項目中執(zhí)行效果不同的原因之一。
而最重要的一點問題我認為出在設(shè)計階段上了，XP在設(shè)計階段更多的是發(fā)揮群體智慧，在設(shè)計時基本是群體參與，而形成的CRC盡管已經(jīng)詳細，但通常都沒有一個良好的記錄，在項目A中由于團隊成員個人的能力即使在實現(xiàn)的過程中出現(xiàn)一些問題也能獨立解決，所以沒有暴露出什么問題，同時由于團隊成員能力的相當(dāng)，在CRC設(shè)計討論的時候大家基本能做到充分的交流，對于大家的提升都很明顯，而在項目B中則由于團隊成員能力的參差不齊，導(dǎo)致在CRC設(shè)計時基本沒有討論，都是設(shè)計師主導(dǎo)，而且最終由于沒形成足夠的文檔，在實現(xiàn)時團隊成員仍然是出現(xiàn)不少的問題，而需要設(shè)計師不斷的去指導(dǎo)，最終導(dǎo)致設(shè)計師在架構(gòu)上投入的不足，同時也導(dǎo)致團隊成員在實現(xiàn)時仍然出現(xiàn)不少問題；在設(shè)計階段的第二個問題則是由于在XP中實行簡單設(shè)計，當(dāng)然，簡單不等于簡陋，但這個時候的設(shè)計更多的其實是需要通過重構(gòu)去不斷完善的，在項目A的團隊中成員在完成任務(wù)后都會對自己的任務(wù)進行一定的重構(gòu)完善設(shè)計，而在項目B中卻沒法做到這一點，導(dǎo)致最后的實現(xiàn)在設(shè)計上出現(xiàn)過多不完善的地方。
在這樣的分析下，認為設(shè)計階段需要充分結(jié)合團隊情況而考慮開展方式，對于水平都相當(dāng)并且具有一定設(shè)計能力的團隊而言，群體設(shè)計的方式無疑會大大超過個體設(shè)計，對于整個團隊的協(xié)作、水平提升都會起到極佳的作用，而且這時我覺得也沒必要在設(shè)計上過多的追求，而應(yīng)該采用能想到的最簡單的解決方案，在成員實現(xiàn)解決方案的過程中成員可根據(jù)經(jīng)驗不斷的進行重構(gòu)完善設(shè)計，在這樣的情況下沒必要開始形成規(guī)范的設(shè)計文檔，可在一定的階段如迭代完成前的設(shè)計穩(wěn)定時形成規(guī)范的設(shè)計文檔，其實同樣，在這樣的團隊中沒有明顯的設(shè)計師和開發(fā)人員的區(qū)別，在這樣的團隊中對于需求的變化是可以快速進行響應(yīng)的，不用糾纏于規(guī)范的文檔格式，而可以通過代碼來表達出足夠的設(shè)計思想；而對于水平參差不齊的團隊而言，個人認為團隊中的系統(tǒng)設(shè)計師這時要充分擔(dān)當(dāng)設(shè)計師的職責(zé)，對于任務(wù)提供出詳細的設(shè)計文檔，通常來說，為了方便整個團隊的理解，需要形成規(guī)范性質(zhì)的文檔，而且在做設(shè)計時，設(shè)計師應(yīng)該盡量的考慮齊全，不能過多的去依賴后期的重構(gòu)來完善設(shè)計，同時，在將設(shè)計交由開發(fā)人員進行實現(xiàn)時要加強Code Review以及開發(fā)指導(dǎo)，在這樣形式的團隊中，自動生成代碼的形式以及開發(fā)代碼的模板會起到很好的幫助，或者設(shè)計師可以通過依賴設(shè)計工具如rose等的強大支持，將設(shè)計模型轉(zhuǎn)化為開發(fā)模型，從一定程度上限定和規(guī)范開發(fā)人員的開發(fā)，當(dāng)然，最佳的就是提供框架和框架的IDE，在這樣的方式下，就要求設(shè)計師對于設(shè)計有充分的把握能力和預(yù)見能力，否則在需求出現(xiàn)變化時會難以應(yīng)付，呵呵，就僅僅在規(guī)范的文檔格式方面都要投入不少時間，在這樣的情況下，設(shè)計師和開發(fā)人員的職責(zé)一定要界定清楚，設(shè)計師需要首先對架構(gòu)進行完善，在完善后開始詳細設(shè)計并交由開發(fā)人員實現(xiàn)，在這個過程中設(shè)計人員更多的是需要承擔(dān)起開發(fā)指導(dǎo)和設(shè)計Review的角色。
by the way：其實也可以看出，需要充分的對團隊成員進行了解來制定相應(yīng)的軟件過程，想做到流水線式的開發(fā)是要付出巨大的前期努力的。
ps：后續(xù)一文：系統(tǒng)設(shè)計方法和工具(爭取在年前完成)，^_^