在項目中正式的執行XP中的過程，除了PP由于暫時沒實施，其他的都在實施中，雖然這點會被很多xper說，^_^，其實我也知道PP非常好，畢竟以前經歷過，但由于某些原因，在現在的team中我還不好去執行，以后找到機會，呵呵.....
自己接觸XP說起來也有兩年多了，而且在以前的團隊中也是采用這樣的過程，但現在自己帶team真的執行的時候卻發現碰到一些問題，一方面可能是因為自己太久沒溫習XP，^_^，有些過程都不是那么記得了，另一方面是在執行的時候有些步驟確實不好走，在這樣的情況下，回顧了手頭的幾篇XP的文檔，從XP中對于整個軟件過程的推行來看自己實施過程中的問題。
XP中對于整個軟件過程的推行是這樣的：
1、和客戶一起分析需求，產生User Story，User Story的定義為用戶對于需求的一段描述。
實際執行情況：由PM充當客戶，由Team Leader根據PM的描述進行User Story的編寫，而且由于User Story的定義不是那么明確，實際執行過程中有些迷惑，在這點上我現在的定義就是一個不可分解的獨立、成功業務場景，此場景由場景過程和業務規則共同構成，現在的做法是根據Use Case，拿出其中那些不可分解的獨立、成功的業務場景作為用戶故事。
2、由團隊中的Senior成員對User Story進行完成時間以及技術風險的評估，同時再給團隊中的Junior成員對User Story進行完成時間以及技術風險的評估，最后合并兩人的取平均值構成此User Story的完成時間以及技術風險的評估，如此時產生的User Story大于三周，則進行分解，如小于一周則進行合并。(注: 如出現無法評估的User Story，先進行Spike)
實際執行情況：之前對此過程不夠明確，所以沒有這么做，覺得以后可以考慮執行，不過疑問就在于Junior能做出評估嗎？
3、由客戶對用戶故事進行商業價值以及商業風險的評估。
實際執行情況：恩，這步可行。
4、根據用戶故事的技術風險、完成時間評估、商業價值、商業風險的評估來制定發布計劃，制定的原則為商業價值優先。
實際執行情況：由于現在缺少步驟2，所以只是依照商業價值來制定。
5、根據發布計劃以及用戶故事團隊共同想出系統隱喻。
實際執行情況：我認為系統隱喻其實就是架構設計，在這個步驟上在team中由架構設計小組完成。
6、根據發布計劃制定迭代目標以及迭代計劃，迭代控制在1－－3周。
實際執行情況：基本是這樣的。
7、Team對迭代中的User Story進行CRC設計和任務分解，任務控制在大于一天小于三天的范圍。
實際執行情況：由于沒做步驟2，在迭代會議上首先是列出User Story，但并不進行完成時間的估計，而是先進行CRC設計，CRC設計中也有個疑點，可能是執行的不好，我對于CRC的做法是拿出用戶故事中所出現的名詞，并構成名詞中的屬性和方法，此時進行情景測試，此時自然就受架構約束才能完成，比如UI--->Action--->Service--->Dao這樣一種過程才可通過情景測試(根據情景測試來彌補整個過程中不符合的設計)，就產生了CRC設計的UI、業務對象、Action、Service、Dao這些任務，在這個時候出現問題，就是在簡單的User Story中這些任務就同樣非常簡單，甚至所有任務合在一起也才1天的這種情況，這對于XP來說其實是不符合的，這個時候再去做合并任務、合并User Story發現不是那么好做.......
8、由團隊成員自行挑選任務。
實際執行情況：完整執行。
9、任務承擔者進行TDD實現，每天挑選Pair一起進行。
實際執行情況：TDD方面由于我的理解不是很好，未良好執行，今天專門看了手頭XP文檔中TDD的部分，發現以前的做法確實很不正確，以后一定好好執行，就像編寫一個簡單的增加用戶這樣的方法，在TDD中首先應該考慮這個方法到底有哪些功能，然后在單元測試中進行編寫，最后方法的實現完全根據單元測試來實現，而不編寫超出單元測試范圍的代碼，PP由于目前team以及環境的原因，暫未執行，在將來我決定推行。
10、提交代碼進行持續集成。
實際執行情況：完整執行，不過缺少TDD其實這塊的意義已經不顯得那么重要，不過我仍然覺得對于功能測試以及作為一個集成測試環境來講非常重要，畢竟這是自動的。
11、迭代任務完成后發布迭代版本。
實際執行情況：完整執行。
12、進入下一個迭代。
上面只是對XP過程的一個簡單描述，XP中還有很多重要的思想和原則都是值得分開了詳細闡述和分析的：
簡單、交流、反饋、勇氣、站立早會、TDD等等。
以后有時間的時候一個一個來寫寫感觸，呵呵。
在目前的團隊實施的軟件過程情況來看，個人覺得有幾個方面是有非常好的效果的：
1、早會。耗不了多長時間卻能起到很好的作用。
2、迭代會議。耗費時間是很長，但對于整個團隊任務完成的情況來看是非常值得的，增加了團隊的交流氣氛，從而提升了整個團隊的水平，讓團隊成員自行挑選任務可以讓團隊成員主動的去提高自己，提高工作方面的興趣。
3、持續集成。非常有好處，至少避免總是要依靠一個人去做集成，而且項目組所有成員都能看到項目的進展，對于團隊來說是種鼓勵，呵呵，我在持續集成中還生成項目網站，覺得這個對于項目組以及領導層來說都很有效果。
4、xplanner進行任務跟蹤。通過xplanner的任務跟蹤提升整個團隊對于任務完成時間的評估準確度，同時也比較準確的統計了團隊的工作量。
ps：總體看下來，自己在XP整個實施上還是存在很多的問題，要吸取教訓，以后努力改進，其實我一直堅持的一點，其實對于一個中小型項目來說，我真的不認為采用什么軟件過程必然就是最好的，關鍵是需要一套適合團隊的完整、規范的軟件過程，這個很重要。