?
首次采用敏捷方式進行開發，我想把我們的做法與大家分享下，同時希望大家指出我們的不足和需要改進的地方，讓我們的項目進行的更順利，目前項目已過三分之一，客戶比較滿意，還算順利。
?
項目簡介：一個DMS小項目，預計時間14人月.客戶需求不是很明確，想一邊做一邊提，適合引入敏捷開發（實際上用戶的需求也一直在變，當他們看到每次的small release時都會有新的想法）。
?
Team主要成員：一個team leader（兼BA職責），兩個工程師，一個UI設計師。
成員主要職責：team leader主要負責召開會議，明確每天的開發任務以及項目的總體大概進程，保持團隊成員清楚的知道項目目前的狀態，保持團隊溝通順暢讓團隊保持高昂的士氣。還有個作用是敢于對項目的成敗負責（當然團隊每個成員都有責任）。工程師的主要職責是開發，設計師主要職責是UI設計。
?
開發環境配備：硬件：兩個PC機兩個顯示器兩套鼠標鍵盤（工作的時候切換到一個PC機上pair編程，共享一個主機，用轉換器使一個主機上面接兩個顯示器，兩套鼠標鍵盤，這樣就不用擠在一個顯示器前搶一套鼠標鍵盤pair了），一個測試服務器，上裝svn服務器和cruisecontrol來管理代碼和實現定時自動化測試（測試一定要自動化，這樣可以讓機器來干它喜歡并擅長干的事情，讓工程師專注自己的業務；我們使用yahoo的一個模擬熔巖燈來監視測試結果。），一個發布服務器，客戶可以遠程及時適用后給出反饋意見和建議。
?
開發簡介：
一、迭代（Iteration）和發布（release）計劃
由于項目開發人員比較少，我們決定采用最短的迭代周期（一周），每個迭代前由BA評估story需求風險，開發人員評估story技術風險和COST，選出能在本輪迭代周期中完成的任務；每個迭代結束來一次small release
?
二、我們對實現XP價值觀所做的努力
1、? 溝通（communication）
再怎么強調溝通的重要性都不為過，尤其是在軟件行業。所以在XP中communication被放在首位也不為奇。
我們項目組每天早上開一次Standup Meeting，通報彼此昨天做了哪些工作，以便讓開發小組所有人了解各自的工作情況，然后確定今天要做的task，目前公司地牌兒還不夠遼闊，我們小組還沒有足夠的地兒掛白板，就把story和task寫在Excel表里面；每個星期一的早上（迭代開始前）會有一個IPM（迭代計劃會議），主要內容是大概確定本次迭代周期開發需開發的story，工程師評估每個story完成所需的時間開；每個周五下午（迭代結束前）會有一個Retrospective（迭代結束前會議），會議主要內容是對本次迭代做的好的方面以及待改進的地方進行總結；工程師pari編程。
2、? 簡單（simplicity）
3、? 反饋（feedback）
沒有持續的反饋，敏捷將無從談起。customer、accompanier、team以及test result的反饋給我們向用戶交付真正需要的系統提供了保證。我們的BA每天和客戶溝通，掌握用戶真正、迫切需要的功能和需求。由于我們的系統是一周發布一次，所以客戶也能在很短的時間內知道完成的新功能，并及時提出改進意見和建議（其實客戶的需求也是一直不停地在變的）。
4、? 勇氣（courage）
為了使代碼更加清晰、質量更好，對工作代碼進行大范圍的修改和重構需要勇氣，把某些代碼徹底拋棄需要勇氣，告訴客戶無法再添加新功能需要勇氣。我和accompanier目前都還有這樣的勇氣，希望系統越來越大、代碼越來越多的時候還有這樣的勇氣。
?
三、測試驅動開發（TDD）
關于TDD我們一直在嘗試尋找更爽的方法，目前采用的是webwork、spring、hibernate的組合框架，在大腦里無意識的已經存在了三層結構，我覺得采用TDD，這三層結構應該是最后被驅動出來產生的，而不是一開始就定好三層，然后再TDD編碼。
我們目前是分別對每層進行TDD，還是覺得service層驅動最有成就感，看到green bar 就令人興奮，action層老是mock來mock去的走流程實在屬沒啥意思。
最近又看到了
使用Selenium和Castle進行測試驅動開發 ，本想采納，但是使用Selenium進行至頂向下的驅動的話通過一個測試所需的時間太長了，我是對
green bar有點上癮了的人，不能忍受那么長時間的red bar，懷疑它會對偶的身心健康造成影響，所以就作罷，還是由底至上的方法使測試通過的實踐最短，不知道各位對這樣的三層結構是怎么TDD的？
?
Robert C. Martin大叔的TDD三條軍規如下：
1.除非這能讓失敗的單元測試通過，否則不允許去編寫任何的產品代碼。
2.只允許編寫剛好能夠導致失敗的單元測試。 （編譯失敗也屬于一種失敗）
3.只允許編寫剛好能夠導致一個失敗的單元測試通過的產品代碼。
對于任何功能，一定要從編寫它的單元測試開始；但是到了原則2，你就不能再為那個單元測試寫更多內容。只要一出現該單元測試代碼編譯失敗，或是斷言失敗，你就必須停下來開始編寫產品代碼；但是到了原則3，你就只能編寫產品代碼，直到讓測試編譯成功或通過斷言為準。
?
這三條軍規我覺得太經典了，完全做到了才算TDD做到位了。
?
前幾個迭代周期我們沒有采用TDD,功能代碼寫了然后寫測試，兩個月后對系統進行了一次比較大的重構時，所有的測試都通過了，但是發布上去了還是由bug，所以這種干法是不行的，測試不能達到令人滿意的覆蓋度。TDD完全可以使測試達到令人滿意的覆蓋度。基本上只要測試通過了，就能確定重構沒有對系統造成影響。
?
四、驗收測試（acceptance test）/客戶測試(customer test)
??? 驗收測試我們是放在最后做的，由BA代客戶寫驗收測試，工程師使用selenium 進行驗收測試的實現，我們發現selenium對frame支持的不是很好，有這兒我想到采用至頂向下如：
使用Selenium和Castle進行測試驅動開發 進行TDD的話是最合理的，不知道大家是不是這么做的？
?
五、pair 編程