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