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

技術(shù)與系統(tǒng)構(gòu)架
系統(tǒng)采用J2EE技術(shù)，系統(tǒng)基本上是三層（3-tier）結(jié)構(gòu)，即Web接口（web presentation），應(yīng)用邏輯（application logic）和后端服務(wù)器（backend）。

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

項(xiàng)目團(tuán)隊(duì)與工作地點(diǎn)
項(xiàng)目組有14個(gè)開發(fā)人員，2個(gè)業(yè)務(wù)分析人員（business analyst），一個(gè)項(xiàng)目經(jīng)理。主要開發(fā)組在英國(guó)（10個(gè)開發(fā)人員），項(xiàng)目經(jīng)理和其余人員則在客戶所在地（與英國(guó)有一小時(shí)的飛行的距離）。

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

第一周
開發(fā)組成員逐步聚集到項(xiàng)目組所在地。我們十來個(gè)人都坐在一起，邊上一個(gè)大白板。這種坐位設(shè)置非常利于交流，特別是Cockburn所稱的“滲透”式交流。各成員的技能方面也各有所專，如Java，EJB，JSP等。
項(xiàng)目有個(gè)時(shí)間錄入跟蹤系統(tǒng)（time tracker/timesheet）。每人需錄入每天所做的任務(wù)和時(shí)間。這主要用于項(xiàng)目管理，而這些歷史數(shù)據(jù)也是對(duì)新任務(wù)進(jìn)行規(guī)劃評(píng)估的基礎(chǔ)。
這周的主要工作是設(shè)置工作環(huán)境。每人一個(gè)Windows NT或XP 2000作為工作站。我們選用的 IDE（Integrated Development Environment）是NetBeans。選用NetBeans的主要原因是經(jīng)費(fèi)問題（NetBeans是開放式源碼并免費(fèi)）。源碼控制是用的Microsoft SourceSafe。源碼庫放在一個(gè)項(xiàng)目所用的專門服務(wù)器上。而項(xiàng)目的文檔材料，如需求分析，系統(tǒng)架構(gòu)以及開發(fā)管理文件，如時(shí)間進(jìn)度表等。
雖然項(xiàng)目已決定使用J2EE技術(shù)，但具體的系統(tǒng)架構(gòu)仍然需要建立。初步的選擇是一個(gè)應(yīng)用框架（application framework）。這個(gè)框架是由我以前參加的一個(gè)項(xiàng)目發(fā)展而來，我對(duì)它的起源和演化都相當(dāng)了解，因此我也開始對(duì)這個(gè)框架進(jìn)行評(píng)審（review）。
我注意到?jīng)]有單元測(cè)試環(huán)境，便開始作一些這方面的工作，因?yàn)榻M里只有我有過建立及使用單元測(cè)試的經(jīng)驗(yàn)。

第二周
我建立了一個(gè)基于JUnit的單元測(cè)試框架，并寫了一份2頁紙的簡(jiǎn)短介紹，包括單元測(cè)試的概念與實(shí)踐，以及一種稱之為“Mock Object”的技術(shù)，因?yàn)槲艺J(rèn)為我們的系統(tǒng)需用到這種技術(shù)。
本周有一次角色分配。一位精于JSP的同事將主要負(fù)責(zé)前端（front-end presentation），兩位對(duì)項(xiàng)目所涉的后端有較多知識(shí)并參加過可行性研究的同事將更多地與在客戶地點(diǎn)的business people （業(yè)務(wù)人員）打交道，一位對(duì)編碼標(biāo)準(zhǔn)（coding standards）有濃厚興趣的同事負(fù)責(zé)收集大家在編碼方面的問題并執(zhí)筆編碼標(biāo)準(zhǔn)文檔，還有一位精于Ant的同事主要做工具開發(fā)與配置管理（configuration management），等等。
我們的編碼標(biāo)準(zhǔn)主要是以Sun Microsystem的“Java Code Conventions”為藍(lán)本。另外，客戶要求源碼中所有的public and protected methods必須要有JavaDoc說明。一些與我們的特定系統(tǒng)有關(guān)的問題，如命名慣例（naming convention），將隨著開發(fā)進(jìn)程不斷地編入文檔中。
大家對(duì)現(xiàn)有的“故事板”進(jìn)行的討論分析，并分解出一些具體任務(wù)，然后大家根據(jù)自己的角色和興趣sign up（“認(rèn)購”）任務(wù)并開始設(shè)計(jì)與編碼。
關(guān)于源碼控制與源碼庫，大家同意每天早上更新自己的工作版本（working copy）。如果要修改或加入文件，在check in之前，一定要保證整個(gè)源碼能通過編譯。

第三周
大家繼續(xù)上周的設(shè)計(jì)與編碼工作。同事們似乎都是Cockburn所說的“good citizen”，工作中人人爭(zhēng)先，個(gè)個(gè)奮勇。
隨著編碼的進(jìn)展，一個(gè)問題開始出現(xiàn)了。我們這里沒有后端系統(tǒng)，所以不能對(duì)開發(fā)的程序進(jìn)行完整的測(cè)試與集成。
星期四，項(xiàng)目安排了一次電視會(huì)議（video conference），參加者是我們這邊的成員與在客戶那邊的成員。兩邊的同事通過電視見見面，每人作一簡(jiǎn)短的自我介紹。然后主要是討論了當(dāng)前開發(fā)中的問題。最嚴(yán)重的問題包括需求與規(guī)范文檔沒能按時(shí)簽發(fā)（signoff），以及我們這邊沒有測(cè)試環(huán)境。

第四周
由于客戶對(duì)我們選用的應(yīng)用框架（application framework）仍有疑慮，應(yīng)客戶要求，我們公司找了一位有著非常豐富的開發(fā)經(jīng)驗(yàn)的、并且在我們目前所用的應(yīng)用框架（application framework）上做出過系統(tǒng)的技術(shù)權(quán)威向客戶解答他們的問題。
新來的技術(shù)權(quán)威是位敏捷方法（agile methodology）的熱心者，我們?cè)谒慕ㄗh下準(zhǔn)備采用類似XP的過程，首要目標(biāo)是向客戶，也是向我們自己顯示出我們能出活（we can deliver）。周一下午，全組開了一個(gè)兩小時(shí)的會(huì)議：
確定了要實(shí)現(xiàn)的一個(gè)很基本的功能，該功能其實(shí)大部分的編碼已完成。
圍繞這個(gè)功能，分解出若干需完成的任務(wù)，如：源碼審查（code review），源碼修改， 單元測(cè)試，建立“啞”（dummy）后端以作為初步功能測(cè)試與集成，找一臺(tái)空機(jī)器以作 系統(tǒng)建造與演示，等等。
大家根據(jù)自己的特長(zhǎng)與興趣來“瓜分”把這些任務(wù)。
根據(jù)每人對(duì)完成自己任務(wù)所需時(shí)間的估計(jì)制訂出工作流程與進(jìn)度，以0.5天為一單元。
根據(jù)進(jìn)度表，“交貨”時(shí)間為下周四中午12:00點(diǎn)。屆時(shí)，我們需提供一份release notes， 上面將列出系統(tǒng)安裝的步驟。按照這些步驟，我們需要：
在一臺(tái)只有操作系統(tǒng)的空機(jī)器上建立運(yùn)行系統(tǒng)所需的環(huán)境；
編譯源碼并安裝系統(tǒng)；
運(yùn)行系統(tǒng)并演示所完成的功能。
因?yàn)橄轮芤恢芏偶伲☉c祝女王登基五十周年），時(shí)間非常緊迫。大家開足馬力，開始工作。

第五周
盡管大家盡了最大努力，星期四的期限沒能完全達(dá)到，其主要原因是系統(tǒng)安裝上有些沒預(yù)料到的 困難。但最終在星期五中午完成了所有的要求并進(jìn)行了系統(tǒng)演示。
星期五下午全組會(huì)議，主要是對(duì)這一周期中的開發(fā)過程進(jìn)行討論，特別是那些感到最困難的事情。 大家發(fā)現(xiàn)以下這些任務(wù)花的時(shí)間比預(yù)想的多：
熟悉應(yīng)用框架和系統(tǒng)架構(gòu)；
建立“啞”后端服務(wù)系統(tǒng)以作測(cè)試環(huán)境
建立單元測(cè)試
系統(tǒng)安裝。

第六周
根據(jù)上周的討論，編碼標(biāo)準(zhǔn)（coding standards）進(jìn)行了更新。
對(duì)第二三周所作的工作重新進(jìn)行了討論并制訂了新的進(jìn)度表。這個(gè)周期的工作其實(shí)包含了 三個(gè)use case（或“故事板”），每塊“故事板”基本上由兩個(gè)人負(fù)責(zé)。其他人則主要完善 單元測(cè)試框架及建造“啞”后端系統(tǒng)。
本周工作中發(fā)現(xiàn)，有一處設(shè)計(jì)/模型需修改以適應(yīng)新的功能。多數(shù)人被吸引到討論中并提出 了若干方案。我提出用一種“角色模式（role pattern）”，因?yàn)槲艺J(rèn)為它非常適用我們 現(xiàn)在的情形。

第七周
關(guān)于修改模型的討論繼續(xù)。

討論與思考
下面的討論將主要圍繞一些XP的實(shí)踐原則展開。

用戶在場(chǎng)（On site custome r）
盡管開發(fā)組的一部分在客戶地點(diǎn)，但主要的開發(fā)工作卻是在公司本部進(jìn)行的。這里沒有用戶，沒有業(yè)務(wù)分析人員。這點(diǎn)顯然與XP的原則相違背，而其造成的不利影響貫穿于項(xiàng)目始終。首先是對(duì)制訂計(jì)劃與進(jìn)度表的影響。一般來說，在制訂計(jì)劃之前，開發(fā)人員需要花一兩天讀一個(gè)“故事板”，然后作出初步估計(jì)。故事板簡(jiǎn)單易讀，能使人很快地大致了解一個(gè)功能模塊的需求。但是，很多地方比較模糊，有些地方在閱讀文檔中仔細(xì)一點(diǎn)就能看出來。這時(shí)最好有用戶/業(yè)務(wù)人員在場(chǎng)，馬上就能澄清。象我們靠電話和email，時(shí)間花的多，還不見得能說得很清楚。

第二個(gè)影響要更嚴(yán)重一些?！肮适掳濉敝械牟淮_定性有些在讀故事板時(shí)能發(fā)現(xiàn)，而有些就只能到了編碼的時(shí)候才能暴露出來。由于業(yè)務(wù)分析人員在客戶那邊，只能靠電話和email，其質(zhì)量當(dāng)然不如面對(duì)面的討論好。特別是當(dāng)不能及時(shí)得到答案而時(shí)間又緊迫時(shí)，程序員往往得靠經(jīng)驗(yàn)和“推理”作一些假定。如果是錯(cuò)的話，就只能在功能測(cè)試和用戶接收測(cè)試時(shí)再改了。

另外一個(gè)類似問題是與后端系統(tǒng)通訊的規(guī)范說明，這是由另一個(gè)項(xiàng)目組提供。那么我們與他們之間也是有個(gè)溝通的問題。而糟糕的是該項(xiàng)目組也是在客戶那邊，因此只能靠電話和email?？傊矣X得這個(gè)項(xiàng)目的實(shí)踐是從反面證明了用戶在場(chǎng)的重要性。

制訂計(jì)劃與進(jìn)度
如上所言，制訂計(jì)劃和進(jìn)度表是從閱讀“故事板”和規(guī)范說明開始。經(jīng)過若干電話與email的往來后，制訂出一個(gè)計(jì)劃，主要是把需完成的模塊進(jìn)一步分解成一些任務(wù)，以及估計(jì)完成每個(gè)任務(wù)要花的時(shí)間，以0.5天為一個(gè)
單元。該計(jì)劃是一個(gè)spreadsheet文件，放在項(xiàng)目的文檔服務(wù)器上，大家隨時(shí)可查看。

“并行開發(fā)”
我們的項(xiàng)目有一點(diǎn)和正規(guī)的use case driven的過程不太一樣。一般是一個(gè)周期主要是做一個(gè) use case。在我們項(xiàng)目中，一個(gè)“故事板”大概算一個(gè)use case。如在“工作筆記”中所言，在項(xiàng)目走上“正軌”后（從第六周開始），一般是2－3人做一個(gè)“故事板”。所以，一般同時(shí)可能有兩三個(gè)“故事板”在進(jìn)行。每個(gè)“故事板”的周期約3－4周。這樣做的好處是提高了生產(chǎn)率，但我覺得這樣做的前提條件是每個(gè)開發(fā)人員必須是有足夠的經(jīng)驗(yàn)與技能，還有就是熟悉開發(fā)過程（第4－5周的實(shí)踐是非常重要的）。

單元測(cè)試
單元測(cè)試是客戶的一個(gè)要求。在前兩個(gè)月，我們做還有些“過分”。我們是用NetBeans提供的工具對(duì)每個(gè)類（class）都生成相應(yīng)的JUnit測(cè)試類（test class）。對(duì)一個(gè)類而言，其中的每一個(gè) public和protected method都在test class中有對(duì)應(yīng)的一個(gè)test method。而這個(gè)test method 里只有一個(gè)fail語句。這樣強(qiáng)迫你用測(cè)試來替換這個(gè)fail（當(dāng)然你也可以把它刪掉）。結(jié)果我們發(fā)現(xiàn)花了很多時(shí)間去寫getter和setter的測(cè)試，實(shí)在不值得，因?yàn)檫@些methods非常簡(jiǎn)單。我們因此說服客戶，允許我們不用對(duì)getter和setter些測(cè)試。不過，我
倒是發(fā)現(xiàn)，對(duì) getter的測(cè)試，實(shí)際上是在測(cè)試相應(yīng)attribute的初始值。設(shè)置初始值常常被忽略，而會(huì)在運(yùn)行中引起一些問題，如最常見的NullPointerException。

單元測(cè)試通常要求把被測(cè)的對(duì)象孤立起來，即測(cè)試不要用到其他的類。而實(shí)際中，一個(gè)類往往要用到其他的class提供的服務(wù)來完成自己的功能，最常見的如使用數(shù)據(jù)庫或一個(gè)遠(yuǎn)程服務(wù)。單元測(cè)試需要切斷這種依賴性，即一次只測(cè)試某個(gè)我們需要測(cè)的類。這可以利用Mock Object （“模擬對(duì)象”）技術(shù)來達(dá)到，例如，用一個(gè)mock service來代替真正的service，而我們可以很方便地對(duì)這個(gè)mock service進(jìn)行狀態(tài)設(shè)置。在我們的單元測(cè)試中就大量地運(yùn)用了這種技術(shù)。網(wǎng)上有一些工具可用來幫助產(chǎn)生mock objects，如MockMaker，可以節(jié)省一些時(shí)間。

總的來說，單元測(cè)試的確提高了源碼質(zhì)量。那些逐步建立起來的test cases，我感覺是起到了一張 “警戒網(wǎng)”的作用。源碼修改需要作改動(dòng)時(shí)，這種作用特別明顯。不過，我們也注意到，對(duì)一個(gè)類進(jìn)行完整的單元測(cè)試所花的時(shí)間往往不少于編碼的時(shí)間。因此，一個(gè)很重要的問題是決定測(cè)試到什么程度。XP的建議是對(duì)“可能會(huì)出問題”的地方要重點(diǎn)測(cè)試。但什么是“可能會(huì)出問題”的地方則需視具體情況而定。

系統(tǒng)集成與功能測(cè)試
由于我們這里沒有一個(gè)真正的后端系統(tǒng)，因此沒辦法作真正的集成與功能測(cè)試。在項(xiàng)目的前半期，我們?cè)⒘艘粋€(gè)“啞”后端，這的確對(duì)我們的測(cè)試/調(diào)試起到了很大作用。但是，當(dāng)越來越多的功能加入后，“啞”后端變得越來越負(fù)責(zé)和不可維護(hù)。最后，我們只得放棄這種做法。

項(xiàng)目的管理層曾作了很大努力，想使我們這里能直接連上客戶那里的后端系統(tǒng)，這在技術(shù)上是完全沒有問題的（畢竟這是網(wǎng)絡(luò)時(shí)代）。但不幸的是，這個(gè)合理要求沒能得到滿足。所以項(xiàng)目后半期，當(dāng)一個(gè)“故事板”的的編碼與單元測(cè)試完成后，一般由編碼者或測(cè)試者飛到客戶那里去做集成與功能測(cè)試。

結(jié)對(duì)編程（pair programming）
在我們這個(gè)項(xiàng)目的實(shí)際中，pair programming與“傳統(tǒng)”上的意義有些不同。首先，因?yàn)槲覀冏枚己芸拷?，如果某人有什么問題，只要一叫，一般就會(huì)有人跳起來跑過去幫忙。這可算是一種 “基于解決問題”的pair programming。

另外一種更主要的是方式是編碼與單元測(cè)試的結(jié)對(duì)。由于測(cè)試者對(duì)于如何使用一個(gè)（待測(cè)試）的類一般不會(huì)有著與編碼者完全一致的思路，這樣對(duì)于發(fā)現(xiàn)問題是很有幫助的。另外，由于測(cè)試者一般都會(huì)在測(cè)試時(shí)詳細(xì)閱讀源碼并與編碼者討論，這對(duì)于改進(jìn)一個(gè)class的細(xì)部設(shè)計(jì)與實(shí)現(xiàn)也是很有用的。但這種審閱與源碼有所不同，這里主要是著重“邏輯”的正確與有效，而源碼審閱則偏重于源碼的風(fēng)格與標(biāo)準(zhǔn)的統(tǒng)一。

還有一種方式可稱之為“結(jié)對(duì)排故”（pair debugging），我發(fā)現(xiàn)這種情況多在系統(tǒng)功能測(cè)試中出現(xiàn)。如果在測(cè)試中出現(xiàn)一個(gè)問題（bug），找來找去找不到（因?yàn)檫@時(shí)涉及的東西的較多），搞得昏頭脹腦。那么最好是抓一個(gè)同事到屏幕邊上（最好不是和你搞同一個(gè)部分的），然后給他講講是怎么回事。他可能會(huì)一眼看出問題所在（如果他曾遇到過類似的問題），或者會(huì)從另一個(gè)角度來提供一個(gè)思路。另外，常常也有這種情況，來幫忙的可能只是聽著，而你在講的時(shí)候可能就自己發(fā)現(xiàn)問題了。我想這是因?yàn)槟阍诮o其他人解釋一件事的時(shí)候，你實(shí)際上是在強(qiáng)迫你自己清理自己的思路，而這肯定是有助于找到問題的（特別是在昏頭脹腦的時(shí)候）。

編碼標(biāo)準(zhǔn)（coding standards）
項(xiàng)目開始的時(shí)候，我們就決定采用Sun的“Java Code Conventions”作為我們編碼標(biāo)準(zhǔn)的藍(lán)本。隨著項(xiàng)目的進(jìn)行，大家不斷地討論并同意加入一些與項(xiàng)目有關(guān)的標(biāo)準(zhǔn)，例如：
所有的classes和所有的public and protected methods都必須要有JavaDoc注釋；
對(duì)于packages,classes,variables的命名標(biāo)準(zhǔn)；
如何使用集合（collection）類型，如變量的類型需是interface，如Map而非HashMap；
如何使用實(shí)數(shù)類型，如規(guī)定用double而非float；
如何使用logging（我們使用log4j）；
如何處理exceptions，等等

源碼審閱（code review）
源碼審閱一直是項(xiàng)目的要求之一。但在項(xiàng)目的前半期，這點(diǎn)做得不是很正式。當(dāng)然，一個(gè)主要的原因是大家想盡快地做出一些功能。這樣造成的一個(gè)后果是源碼開始有些雜亂并且不一致。項(xiàng)目后半期開始比較嚴(yán)格地進(jìn)行源碼審閱，并且規(guī)定一個(gè)“故事板”的源碼在進(jìn)入系統(tǒng)測(cè)試之前一定要有正規(guī)的源碼審閱。

進(jìn)行源碼審閱時(shí)，審閱者一般是根據(jù)編碼標(biāo)準(zhǔn)上所列的條款對(duì)源碼進(jìn)行檢查，看是否符合標(biāo)準(zhǔn)。同時(shí)，也可對(duì)一些具體實(shí)現(xiàn)上提出自己的看法。這些意見用一張專門的表格一項(xiàng)一項(xiàng)地記錄下來，交給編碼者修改或給出進(jìn)一步的說明。最后，審閱者對(duì)源碼復(fù)查，對(duì)每一項(xiàng)進(jìn)行核對(duì)，滿意之后簽字認(rèn)可。我們的經(jīng)驗(yàn)表明，這樣的源碼審閱大大地提高了源碼的質(zhì)量以及可讀性和可維護(hù)性。另外一個(gè)作用是使refactoring得以經(jīng)常及時(shí)的進(jìn)行。

源碼重整（refactoring）
我們項(xiàng)目里，refactoring基本上是與編碼標(biāo)準(zhǔn)和源碼審閱同步進(jìn)行的。項(xiàng)目的前半期，基本沒有refactoring，盡管有些不好的碼段或?qū)崿F(xiàn)被不斷的發(fā)現(xiàn)并記錄在案。當(dāng)然，主要原因還是由于大家想集中精力先做出一些功能。在項(xiàng)目的后半期，開始和源碼審閱一起較嚴(yán)格地執(zhí)行。和源碼審閱一樣，這樣做的結(jié)果是大大地提高了源碼的質(zhì)量。

以上這些就是對(duì)這個(gè)項(xiàng)目的一些觀察與思考?？傊瑢?duì)開發(fā)人員來說，這個(gè)項(xiàng)目有許多的不確定性，這主要反映在需求與規(guī)范文件上，也反映在相關(guān)項(xiàng)目組之間的協(xié)調(diào)（或扯皮）上。項(xiàng)目組分散兩地，測(cè)試環(huán)境的缺乏都是開發(fā)中
的很大問題。在這種情況應(yīng)用XP的實(shí)踐原則，如密切溝通，單元測(cè)試，源碼審閱與重整，能有效的（也許是艱苦地）推進(jìn)項(xiàng)目的進(jìn)展。

后記
記得幾年前曾看過一篇文章是講中國(guó)的MBA的教育的。大意是說工商管理是個(gè)實(shí)踐性很強(qiáng)的專業(yè)，做MBA的一項(xiàng)主要工作是做大量的個(gè)案分析。而目前中國(guó)似乎還沒有足夠的個(gè)案，有待于現(xiàn)在的MBA們畢業(yè)后在工作中去積累。這些積累起來的個(gè)案將是今后MBA們一筆寶貴資源。由此想到軟件開發(fā)，何嘗不是如此。軟件開發(fā)是個(gè)實(shí)踐性很強(qiáng)的群體/團(tuán)隊(duì)工作，這點(diǎn)從三十幾年前“軟件工程”的提出時(shí)，人們就已經(jīng)認(rèn)識(shí)到了。提出的方法也是層出不窮，但真正在實(shí)踐中運(yùn)用的并不多。這幾年出現(xiàn)的以XP為代表的agile方法興起，主要原因就是在于它們是從工程實(shí)踐中提煉出來，而其可行性至少在一定條件下或范圍內(nèi)又為他人的實(shí)踐所證明。那么我覺得現(xiàn)在最重要的不是高談闊論，而是扎扎實(shí)實(shí)的實(shí)踐，即在了解這些原則后如何在工程實(shí)踐中加以運(yùn)用。更進(jìn)一步，如果能把這些實(shí)踐記錄下來，加以總結(jié)，這對(duì)自己和同道都是一件好事?；谶@樣的想法，在下不避瑣碎，把自己對(duì)一個(gè)項(xiàng)目的觀察與思考寫下來，期望能拋磚引玉，看到更多的同道能把自己的經(jīng)驗(yàn)寫下來，與大家共享。

【?發(fā)表評(píng)論?0條?】