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