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