項目回顧：一個開發人員的觀察與思考

項目背景
這個項目的客戶是歐洲一家人壽保險公司。該保險公司目前進行的一個計劃是對現有的業務流程（business process）和IT系統進行較大規模的改造，以適應新的市場要求。我們的項目是這個計劃的一個組成部分，它的目標是建立一個瀏覽系統與保險公司的后端保險管理系統相連。這個瀏覽系統用Web瀏覽器作為用戶界面，以取代目前使用的字符終端界面。 2002年初，公司的有關部門（專門作金融服務）曾作了一些可行性研究工作。項目于2002年四月底正式啟動，主要的開發工作于10月底結束。然后由另一組人馬進行用戶接收測試（user acceptance test）。

技術與系統構架
系統采用J2EE技術，系統基本上是三層（3-tier）結構，即Web接口（web presentation），應用邏輯（application logic）和后端服務器（backend）。

系統需求與規范
該項目主要有兩種文檔提供給開發人員：一種是系統功能描述，由一系列的模塊組成。每個模塊類似于一個use case，主要給出了該模塊需實現的屏幕/窗口（screen shot），并一般地描述了這些屏幕上的操作以及它們之間的切換。這樣的模塊描述文件在項目中被稱之為“故事板”（story board）�！肮适掳濉庇蓸I務分析人員（business analyst）會同用戶產生。另一種文檔是與后端服務器接口的規范說明，如命令格式，數據格式等，由后端系統設計開發組提供。按照項目規定，兩種文件都需要經過充分討論并基本穩定下來之后，由相關負責人員簽發（sign off），然后交給開發組。

項目團隊與工作地點
項目組有14個開發人員，2個業務分析人員（business analyst），一個項目經理。主要開發組在英國（10個開發人員），項目經理和其余人員則在客戶所在地（與英國有一小時的飛行的距離）。

工作筆記
由于工作習慣，我一般每天都作工作筆記。而在這個項目中前兩個多月中，我也每周都寫一篇小結，主要是對項目運行的觀察（所計述的都是對我所在的公司本部開發組而言）以下便是稍作整理后的前十周的小結（略去了公司和人員的名字）。這些筆記可能顯得有些雜亂和瑣碎，列在這里的主要目的是想忠實地把我眼中的項目進展情況展現出來。

第一周
開發組成員逐步聚集到項目組所在地。我們十來個人都坐在一起，邊上一個大白板。這種坐位設置非常利于交流，特別是Cockburn所稱的“滲透”式交流。各成員的技能方面也各有所專，如Java，EJB，JSP等。
項目有個時間錄入跟蹤系統（time tracker/timesheet）。每人需錄入每天所做的任務和時間。這主要用于項目管理，而這些歷史數據也是對新任務進行規劃評估的基礎。
這周的主要工作是設置工作環境。每人一個Windows NT或XP 2000作為工作站。我們選用的 IDE（Integrated Development Environment）是NetBeans。選用NetBeans的主要原因是經費問題（NetBeans是開放式源碼并免費）。源碼控制是用的Microsoft SourceSafe。源碼庫放在一個項目所用的專門服務器上。而項目的文檔材料，如需求分析，系統架構以及開發管理文件，如時間進度表等。
雖然項目已決定使用J2EE技術，但具體的系統架構仍然需要建立。初步的選擇是一個應用框架（application framework）。這個框架是由我以前參加的一個項目發展而來，我對它的起源和演化都相當了解，因此我也開始對這個框架進行評審（review）。
我注意到沒有單元測試環境，便開始作一些這方面的工作，因為組里只有我有過建立及使用單元測試的經驗。
第二周
我建立了一個基于JUnit的單元測試框架，并寫了一份2頁紙的簡短介紹，包括單元測試的概念與實踐，以及一種稱之為“Mock Object”的技術，因為我認為我們的系統需用到這種技術。
本周有一次角色分配。一位精于JSP的同事將主要負責前端（front-end presentation），兩位對項目所涉的后端有較多知識并參加過可行性研究的同事將更多地與在客戶地點的business people （業務人員）打交道，一位對編碼標準（coding standards）有濃厚興趣的同事負責收集大家在編碼方面的問題并執筆編碼標準文檔，還有一位精于Ant的同事主要做工具開發與配置管理（configuration management），等等。
我們的編碼標準主要是以Sun Microsystem的“Java Code Conventions”為藍本。另外，客戶要求源碼中所有的public and protected methods必須要有JavaDoc說明。一些與我們的特定系統有關的問題，如命名慣例（naming convention），將隨著開發進程不斷地編入文檔中。
大家對現有的“故事板”進行的討論分析，并分解出一些具體任務，然后大家根據自己的角色和興趣sign up（“認購”）任務并開始設計與編碼。
關于源碼控制與源碼庫，大家同意每天早上更新自己的工作版本（working copy）。如果要修改或加入文件，在check in之前，一定要保證整個源碼能通過編譯。
第三周
大家繼續上周的設計與編碼工作。同事們似乎都是Cockburn所說的“good citizen”，工作中人人爭先，個個奮勇。
隨著編碼的進展，一個問題開始出現了。我們這里沒有后端系統，所以不能對開發的程序進行完整的測試與集成。
星期四，項目安排了一次電視會議（video conference），參加者是我們這邊的成員與在客戶那邊的成員。兩邊的同事通過電視見見面，每人作一簡短的自我介紹。然后主要是討論了當前開發中的問題。最嚴重的問題包括需求與規范文檔沒能按時簽發（signoff），以及我們這邊沒有測試環境。
第四周
由于客戶對我們選用的應用框架（application framework）仍有疑慮，應客戶要求，我們公司找了一位有著非常豐富的開發經驗的、并且在我們目前所用的應用框架（application framework）上做出過系統的技術權威向客戶解答他們的問題。
新來的技術權威是位敏捷方法（agile methodology）的熱心者，我們在他的建議下準備采用類似XP的過程，首要目標是向客戶，也是向我們自己顯示出我們能出活（we can deliver）。周一下午，全組開了一個兩小時的會議：
確定了要實現的一個很基本的功能，該功能其實大部分的編碼已完成。
圍繞這個功能，分解出若干需完成的任務，如：源碼審查（code review），源碼修改， 單元測試，建立“啞”（dummy）后端以作為初步功能測試與集成，找一臺空機器以作 系統建造與演示，等等。
大家根據自己的特長與興趣來“瓜分”把這些任務。
根據每人對完成自己任務所需時間的估計制訂出工作流程與進度，以0.5天為一單元。
根據進度表，“交貨”時間為下周四中午12:00點。屆時，我們需提供一份release notes， 上面將列出系統安裝的步驟。按照這些步驟，我們需要：
在一臺只有操作系統的空機器上建立運行系統所需的環境；
編譯源碼并安裝系統；
運行系統并演示所完成的功能。
因為下周一周二放假（慶祝女王登基五十周年），時間非常緊迫。大家開足馬力，開始工作。
第五周
盡管大家盡了最大努力，星期四的期限沒能完全達到，其主要原因是系統安裝上有些沒預料到的 困難。但最終在星期五中午完成了所有的要求并進行了系統演示。
星期五下午全組會議，主要是對這一周期中的開發過程進行討論，特別是那些感到最困難的事情。 大家發現以下這些任務花的時間比預想的多：
熟悉應用框架和系統架構；
建立“啞”后端服務系統以作測試環境
建立單元測試
系統安裝。
第六周
根據上周的討論，編碼標準（coding standards）進行了更新。
對第二三周所作的工作重新進行了討論并制訂了新的進度表。這個周期的工作其實包含了 三個use case（或“故事板”），每塊“故事板”基本上由兩個人負責。其他人則主要完善 單元測試框架及建造“啞”后端系統。
本周工作中發現，有一處設計/模型需修改以適應新的功能。多數人被吸引到討論中并提出 了若干方案。我提出用一種“角色模式（role pattern）”，因為我認為它非常適用我們 現在的情形。
第七周
關于修改模型的討論繼續，最后是決定采取一個簡單的方法（雖然hacking的味道很重），這主要是考慮到系統的特點和“簡單性”原則。（有趣的是，我離開項目組后，有位同事做后續開發，又來和我討論role pattern，并且決定使用一種更復雜的role pattern）
本周的開發工作中也發現了“故事板”的一些問題。因為“故事板”不是精確的規范說明，因此在編碼時會遇到一些含糊不確定的地方，需要詢問用戶或business analyst。
由于新的class naming conventions（取名規則），對有些部分的源碼進行了重寫。這是件很花時間與精力的事情，特別是要非常仔細（據說有些IDE支持這種工作）。
第八周
由于發現了一個utility class的潛在的問題，大家同意需要用新的方式來使用這個class，并對現有的源碼進行核查及修改。
在一個模塊的編碼和單元測試基本完成之際，最令人惱火的是發現描述這個模塊的“故事板” 還在更新，而這個“故事板”在我們決定開始干這個模塊之前是已簽發（signed off）了的。沒有辦法，只得重讀這塊“故事板”，并對源碼以及單元測試進行相應的修改。
第九周
這周的主要工作是在“啞”后端服務系統是建立新的“啞”功能和數據，以便能對新開發的模塊進行“集成”與功能測試。這實在是一件太花時間的活。
第十周
非常不想看到的需求改變又來了。又是重讀新的需求說明，修改相應的源碼。而在與業務分析員的討論中，又發現我們對一個“故事板”中的一處功能有不同的理解。最后，當然是得根據業務分析員的意見，對源碼進行修改。
最后，終于作了源碼審閱，并根據審閱者的意見對源碼作了整理，然后整理出設計文檔。把這些源碼與文檔傳給在客戶那邊的同事們去和真正的后端服務系統連接并測試。
第三至六月
第3－6月基本上是順著第6－10周的路子走，但也有一些明顯的變化：

系統調試。建立“啞”后端作測試被認為有些不值得，因為花的時間太多。最后兩個月的做法是等一塊“故事板”在我們這邊完成后（編碼、單元測試、源碼審閱），派一個或兩個人飛到客戶那邊去待3－5天作系統調試。這樣的花銷也很大，但客戶似乎并不十分在意。
源碼質量。源碼中需“重整”（refactoring）的地方被不斷的查找出來并寫入到文檔中，編碼也在不斷地增補，源碼審閱變得比較正規，并有一份專門的文檔。審閱者對源碼進行審讀后，需列出需修改或進一步說明的地方。程序員需對每一處進行相應的修改或說明，簽名后交給審閱者簽名確認。審閱的標準主要是編碼標準和源碼“重整”（refactoring）文檔。
進度規劃。隨著開發的進展，對每個新的“故事板”的規劃和進度表制訂越來越精確。