儘管這只是乙個小專案，耗時也很短，但個人覺得這個專案的整個過程還是值得回顧的，專案雖小，五臟俱全，專案經歷了兩個小的迭代，迭代過程中經歷了典型的需求調研、設計、開發&重構、整合測試過程，採用了現場客戶、tdd等實踐，這裡就以第一迭代來對這個專案的過程做些總結。
初期調研
初期調研階段確定了專案的範圍和邊界，同時對於其中一部分最為緊急的功能調研清楚了。
第一迭代
根據初期的調研，確定了第一迭代的功能目標，用rose簡單的劃分了use case，簡單的用mindmanger做了個第一迭代的工作計畫，由於此專案是基於原有系統的乙個擴充，所以未經架構設計過程。
在劃分了use case和工作計畫後，開工幹活，對於每天的工作同樣用mindmanager做了計畫，開始幹活時首先仍然是對use case做業務建模的工作，首先完成業務物件模型和業務實體模型的建立，在完成了此步工作後，直接將業務物件模型和業務實體模型轉化為了實際的**，而沒有進一步去做從業務模型到技術方面模型的工作，一方面是因為專案簡單，另一方面是因為採用hibernate自然減少了這塊的工作。
在建模完成後，開始對use case做業務過程分析，在業務角度是不存在什麼從介面提交給action，action到service什麼的，而只是完成此項業務功能的乙個過程，在做完業務過程分析後結合架構設計轉化為了對應的序列圖，通過序列圖完成了物件圖，到此use case的設計工作宣告完成，乙個人的專案不存在交流問題，自然沒形成什麼文件，設計時切忌過度設計，在架構的約束下先使用最為簡單的方法進行實現，到了需要在此基礎上擴充套件和新增新功能時逐步的重構，這個時候設計自然會不斷的提公升。
設計完成後，開始寫**了，根據設計開始寫測試**，建立介面，測試寫完後開始寫介面的實現，通過測試則繼續按照序列圖逐步完成所有類的實現，在這些過程完成後即可部署到系統中做整合測試了，在這個專案中，基本上沒碰到整合測試中出現什麼錯誤的現象，這得益於設計過程和tdd過程的較好的執行，如果不是這樣的話，在這個專案的開發過程中肯定會痛苦s，之前的系統啟動至少都需要3分鐘，如果依靠部署、測試、除錯、重啟這樣的過程的話，時間就會全部被消耗掉了。
儘管專案的架構有所限定，但在這個擴充上仍然突出了service大粒度的特徵，service作為use case級別功能的入口點，use case中的所有功能都能在service上找到對應，而service則會結合多個業務物件和dao來完成其他的工作。
現場客戶在這個迭代中儘管沒達到xp過程中期待的效果，但還是不錯的，現場客戶對於需求的把握以及其他一些方面的支援保證了迭代一的順利完工。
迭代一按計畫提前一天完工，到客戶方進行版本的演示，收集反饋，同時對第二迭代的功能進行了調研。
第二迭代同樣按照第一迭代的過程進行，同樣第二迭代也是順利的完工，進度比計畫稍有提前。
在這個小專案中，迭代版本的及時發布墊定了客戶方的信心，同時，結合迭代版本的調研更加準確的挖掘了客戶的需求，使得這個小專案得以很好的完成。
在這個小專案中，真正的著手提公升互動，這對於客戶以及自己而已都起到了很好的作用。
簡單總結下：
1、迭代版本的頻繁發布能很好的建立客戶方對於系統的信心；
2、結合真實系統的調研能夠更加準確的挖掘(引導)客戶的需求；
3、簡單而完整的設計過程和tdd能保證開發較好的完成；
4、把握設計的尺度，依靠重構來不斷的提公升設計。
5、提公升系統的互動對於客戶是直接而明顯的幫助。
當然，對於不同的專案在專案過程上是要有所不同的把握的，不能對於所有的專案都採用同樣的方法，就像不能對所有的客戶都採取一樣的方法建立關係一樣。
乙個人的專案組
開發部只有20來號人，卻有7 8個專案，苦命的產品經理，乙個專案組只有乙個人，奇葩啊。就這樣公司領導還提出要積極開拓外部市場，鼓勵內部創業。看來喊口號永遠是容易的。客戶給我打來 用的還是手機。依我的經驗，這一般來說，是有重要事情的，試著問問發生了什麼，對方沒說太多，但給我的感覺是事情很嚴重。下午急勿...
乙個人的專案 序
春節過後，部門經理給了乙個活兒。說是上面很重視，暫時只有一人年的經費。活兒是好活兒。幹了十年.net桌面程式開發後，終於來了乙個web開發的，並且是在公司乙個大型web平台之上開發。能接觸到很多優秀的開發，很多有勢的領導。無論技術還是管理，都會有很多新東西。但這也是乙個挑戰。習慣了團隊分工合作，自己...
乙個人的專案 序
春節過後，部門經理給了乙個活兒。說是上面很重視，暫時只有一人年的經費。活兒是好活兒。幹了十年.net桌面程式開發後，終於來了乙個web開發的，並且是在公司乙個大型web平台之上開發。能接觸到很多優秀的開發，很多有勢的領導。無論技術還是管理，都會有很多新東西。但這也是乙個挑戰。習慣了團隊分工合作，自己...