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