這個月剛進入公司，加入了一個10人左右的團隊，用Java做一個網站后臺。
客戶是日本公司，他們做了項目的大部分分析(Requirements, Use cases, Domain model...)。我們負責的是詳細設計和開發。我是項目開始幾星期后才進的公司。Schedule也已經為我分配好了。大家都按照schedule上的安排工作著。
上星期開會的時候得知，日本這次采用的是agile過程。而我們的schedule更類似于RUP這樣的過程。RUP這個學院派和Agile這個造反派狹路相逢，問題也就出現了。
大家工作都很賣力，為了能按進度提交制品，有時還通宵達旦解決問題。我們這支團隊的戰斗力和信心是不容懷疑的。可是大家努力的結果換來的卻是用戶的抱怨。大家都困惑不解。問題究竟出在哪兒？
日方在項目中強調的是Agile過程，我們采用的則是傳統的過程。一開始，兩個過程方法之間的差異并不大；對我們提交的制品，客戶也沒有什么異議。但是，直到客戶提出問題之前，我們所提交的制品都是一些設計文檔。而我們的制品也僅限于此——沒有一個可用的EAR包、沒有寫過 test case。很明顯，我們犯了agile的大忌。
Agile所強調的是快速的構建、輕量級的迭代、TDD等。由于之前沒有寫test case，詳細設計也沒有test case可以參照。設計本身是不是合理，是不是testable也不得而知。致使在設計test case的時候無從下手，很多類甚至都沒有辦法測試。整個架構的可行性很難估算。
往后考慮。一次大規模的重構可能是少不了的。雖然agile過程本身提倡以TDD為基礎的重構。但是現在的重構可能造成的代價已經不是一次輕量級的增量迭代了。
說到這里，總結幾點，希望能在以后的工作中引起注意：
1. Agile很難管理，項目早期應該對各種風險有盡可能全面的評估，schedule的設置中應該定義好 test case 和 build 的時間點。
2. 設計不必太詳細，用頻繁的測試和重構完善設計。
3. Test case 優先設計，這樣在架構中就會對testability有足夠多的考慮。
4. 團隊內部對共同的難題應該及早進行討論和解決，問題的解決方案應該傳遞到每個組員，盡可能保證團隊的能力同步。