首次採用敏捷方式進行開發，我想把我們的做法與大家分享下，同時希望大家指出我們的不足和需要改進的地方，讓我們的專案進行的更順利，目前專案已過三分之一，客戶比較滿意，還算順利。
專案簡介：乙個dms小專案，預計時間14人月.客戶需求不是很明確，想一邊做一邊提，適合引入敏捷開發（實際上使用者的需求也一直在變，當他們看到每次的small release時都會有新的想法）。
team主要成員：乙個team leader（兼ba職責），兩個工程師，乙個ui設計師。
成員主要職責：team leader主要負責召開會議，明確每天的開發任務以及專案的總體大概程序，保持團隊成員清楚的知道專案目前的狀態，保持團隊溝通順暢讓團隊保持高昂的士氣。還有個作用是敢於對專案的成敗負責（當然團隊每個成員都有責任）。工程師的主要職責是開發，設計師主要職責是ui設計。
開發簡介：
一、迭代（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）
保持**和設計盡可能簡單是系統可擴充套件性和可維護性的重要保障。關於****** design的討論可見徐x的
agile 101: pair programming & ****** design
。kent beck用四個條件定義了簡單的系統**：執行所有的測試獲得通過、意圖明確、沒有重複、使用盡可能少的類和方法。我和accompanier也一直在向這個目標努力。
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.只允許編寫剛好能夠導致乙個失敗的單元測試通過的產品**。
這三條軍規我覺得太經典了，完全做到了才算tdd做到位了。
前幾個迭代週期我們沒有採用tdd,功能**寫了然後寫測試，兩個月後對系統進行了一次比較大的重構時，所有的測試都通過了，但是發布上去了還是由bug，所以這種乾法是不行的，測試不能達到令人滿意的覆蓋度。tdd完全可以使測試達到令人滿意的覆蓋度。基本上只要測試通過了，就能確定重構沒有對系統造成影響。
四、驗收測試（acceptance test）/客戶測試(customer test)
驗收測試我們是放在最後做的，由ba代客戶寫驗收測試，工程師使用selenium 進行驗收測試的實現，我們發現selenium對frame支援的不是很好，有這兒我想到採用至頂向下如：
使用selenium和castle進行測試驅動開發 進行tdd的話是最合理的，不知道大家是不是這麼做的？
五、pair 程式設計
pair的好處我就不說了，試過了就知道了。
首次敏捷專案開發實踐
首次採用敏捷方式進行開發，我想把我們的做法與大家分享下，同時希望大家指出我們的不足和需要改進的地方，讓我們的專案進行的更順利，目前專案已過三分之一，客戶比較滿意，還算順利。專案簡介 乙個dms小專案，預計時間14人月.客戶需求不是很明確，想一邊做一邊提，適合引入敏捷開發 實際上使用者的需求也一直在變...
記首次敏捷開發
二十天，四個迭代，四次presentation。迭代一作為前台，其餘5人反覆確認頁面設計需求，需要提供幾個引數，變變數名是什麼，分別以什麼形式傳遞，使用form表單的話，action路徑填什麼。第一次會懷疑自己的溝通能力，永遠都會有些許出入，後期再重新調整，但至少這還在可調整範圍內，有些人獨行慣了，...
敏捷開發實踐 pair programming
上週一是洋老闆d正式上班的第一天，我們三人小組開了乙個很短的會，會議的主題很簡單，依然是那不變的scrum 每日站立會議三段論 前一陣做了什麼？將要做什麼？有什麼問題？下午，我正在皺著眉頭解決乙個dojo的問題 剛接觸dojo,很具挑戰性啊 d問我是否準備好了pair programming.對於p...