實(shí)踐敏捷方法的六個(gè)關(guān)鍵點(diǎn)
51CTO推薦專題：初探敏捷開發(fā)
本文是敏捷和DSL領(lǐng)域的大師Martin Fowler關(guān)于敏捷開發(fā)和敏捷方法方面的文答實(shí)錄，這些問題一般發(fā)生在我們敏捷項(xiàng)目中，他的解答對(duì)我們實(shí)踐敏捷開發(fā)，解決項(xiàng)目中的常見問題很有幫助。
1、如何在常規(guī)業(yè)務(wù)中應(yīng)用敏捷方法？
常規(guī)業(yè)務(wù)（Business As Usual）是指使公司業(yè)務(wù)正常運(yùn)營而進(jìn)行的一些日常業(yè)務(wù)活動(dòng)，對(duì)于IT部門而言則包括系統(tǒng)維護(hù)、技術(shù)支持以及應(yīng)用更改。這些工作相對(duì)于獨(dú)立的軟件項(xiàng)目而言即瑣碎又零散，但又是不可或缺的?！叭绾卧诔Ｒ?guī)業(yè)務(wù)中應(yīng)用敏捷方法？”，這是我們向Martin提出的***個(gè)問題。Martin闡述道，首先需要澄清一下對(duì)項(xiàng)目的定義，傳統(tǒng)的項(xiàng)目運(yùn)作方式是集中一批業(yè)務(wù)人員、開發(fā)人員和管理人員進(jìn)行產(chǎn)品開發(fā)，開發(fā)完成后將產(chǎn)品交付系統(tǒng)運(yùn)行和支持部門，項(xiàng)目也就隨之結(jié)束了。在敏捷方法中，項(xiàng)目是一個(gè)持續(xù)性的過程，系統(tǒng)隨著業(yè)務(wù)的需要不斷地更改和重構(gòu)，參與項(xiàng)目的人員也相應(yīng)地在不斷地增加或者減少。筆者的理解是只要系統(tǒng)仍在支持業(yè)務(wù)運(yùn)營，項(xiàng)目就不會(huì)結(jié)束，因?yàn)闃I(yè)務(wù)幾乎不可能不變更，并且必要的重構(gòu)也不可避免，對(duì)于ThoughtWorks的顧問們來說這意味著他們和客戶的業(yè)務(wù)關(guān)系也不會(huì)結(jié)束，呵呵，雙贏的策略！
2、集中式辦公和分布式辦公
Martin強(qiáng)烈反對(duì)項(xiàng)目成員分散式辦公，甚至覺得如果你需要業(yè)務(wù)人員每天到你的辦公室來訪問你，那簡(jiǎn)直是不可接受的，至少你應(yīng)該每天都去拜訪他們?！癐t is a shame if the business stakeholders need to come to your office every day”大意如此。但是現(xiàn)實(shí)卻是，對(duì)于很多公司而言，將業(yè)務(wù)經(jīng)理、項(xiàng)目經(jīng)理、業(yè)務(wù)分析人員、開發(fā)人員和測(cè)試人員都集中在一個(gè)辦公室簡(jiǎn)直就是一件不可能完成的任務(wù)。筆者目前所在的項(xiàng)目有三個(gè)團(tuán)隊(duì)，一個(gè)在悉尼，兩個(gè)在墨爾本，每周進(jìn)行四次遠(yuǎn)程視頻會(huì)議，同時(shí)通過使用電話、即時(shí)消息系統(tǒng)、電子郵件、項(xiàng)目WiKi系統(tǒng)等手段來解決分布辦公帶來的溝通不及時(shí)和信息不透明等問題，影響敏捷方法的實(shí)踐。Martin***也不得不承認(rèn)，很多時(shí)候如果實(shí)在不能夠做到集中式辦公，那只有準(zhǔn)備好為此付出一定的成本。筆者認(rèn)為要做到完全的集中式辦公可能不太現(xiàn)實(shí)，不過可以盡可能在異地團(tuán)隊(duì)之間保持相關(guān)業(yè)務(wù)的對(duì)等溝通，比如在各個(gè)團(tuán)隊(duì)中都盡可能安排項(xiàng)目相關(guān)的各類角色，如：業(yè)務(wù)經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)人員等，讓這些人員與在異地的相同職能的人員溝通，然后再將信息在各自的團(tuán)隊(duì)內(nèi)消化和共享，這樣的效果也許會(huì)好于純粹的按照職能來分布團(tuán)隊(duì)。
3、交叉技能（Cross Skills）
這里主要講的是BA（Business Analyst 業(yè)務(wù)分析人員）和QA（Quality Assurance 質(zhì)量保證人員或測(cè)試人員），Martin說在理想的情況下，BA和QA的角色可以合并，開發(fā)人員和QA的角色也可以互換。因?yàn)锽A和QA都需要對(duì)系統(tǒng)功能有很清晰全面的了解，他們也是系統(tǒng)測(cè)試的主要參與者和鑒定者，他們用來定義系統(tǒng)功能的主要文檔是用戶故事（Story），而用來測(cè)試系統(tǒng)功能的則是功能測(cè)試代碼，測(cè)試人員和開發(fā)人員有責(zé)任將功能測(cè)試代碼寫得易于閱讀，特別是對(duì)于BA，如果他們能夠象閱讀用戶故事一樣閱讀功能測(cè)試代碼，將會(huì)提高他們測(cè)試系統(tǒng)的效率和興趣。這也是在功能測(cè)試中使用領(lǐng)域特定語言（Domain Specific Language）的目的，如果BA和QA都能夠閱讀和使用DSL編寫測(cè)試代碼，那該多好啊?。ㄣ裤街小?通過讓開發(fā)人員輪換地?fù)?dān)任QA的角色，可以幫助提高測(cè)試代碼的質(zhì)量，也可以讓開發(fā)人員真正從用戶的角度來考慮系統(tǒng)功能的設(shè)計(jì)，還可以建立相互信任、相互尊重（appreciate each others work）的良好氛圍。
4、設(shè)計(jì)和編碼
一位同事談到對(duì)業(yè)務(wù)模型缺乏了解會(huì)導(dǎo)致代碼難于理解，有時(shí)候即使代碼的質(zhì)量過關(guān)并且系統(tǒng)功能都在正常工作，但是系統(tǒng)的設(shè)計(jì)卻和業(yè)務(wù)模型出現(xiàn)很大的偏差?！?在實(shí)現(xiàn)設(shè)計(jì)之前，開發(fā)人員需要正確理解整個(gè)業(yè)務(wù)模型（The big picture）”，這是被經(jīng)常提及的解決方法之一。Martin對(duì)此卻不置可否，當(dāng)然能夠理解整個(gè)業(yè)務(wù)模型是最理想的情況，但是往往很少有人能夠做到這一點(diǎn)，即便能夠做到，業(yè)務(wù)模型也會(huì)隨著時(shí)間和具體情況而變更。Martin首先認(rèn)為設(shè)計(jì)和編碼不是兩個(gè)分離的過程，開發(fā)人員在設(shè)計(jì)過程中編碼，也在編碼過程中設(shè)計(jì)。開發(fā)人員在編碼的過程中實(shí)現(xiàn)自己當(dāng)前對(duì)業(yè)務(wù)模型的了解，首先讓功能模塊工作起來（Get it working），同時(shí)考慮如何讓代碼更便于日后的必要的重構(gòu)，隨著時(shí)間的推移，開發(fā)人員對(duì)業(yè)務(wù)模型的了解會(huì)不斷清晰和全面，只要代碼易于重構(gòu)，整個(gè)系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)將會(huì)不斷地、最終地符合業(yè)務(wù)模型。
5、公司內(nèi)部的開源項(xiàng)目，鼓勵(lì)用戶參與產(chǎn)品開發(fā)
很多公司里不同的IT部門可能會(huì)重復(fù)開發(fā)相同功能的產(chǎn)品，這樣會(huì)導(dǎo)致很大的資源浪費(fèi)，用戶也會(huì)面臨選擇的難題。再者，Martin發(fā)現(xiàn)很多IT部門對(duì)用戶提出的功能需求缺乏足夠快的響應(yīng)速度，主要原因是開發(fā)人員資源有限，即使再玩命地工作也不可能在用戶的預(yù)期時(shí)間內(nèi)處理完本來就很長(zhǎng)的功能需求隊(duì)列。典型的例子是：公司有兩個(gè)IT部門A和B，A部門需要B部門對(duì)郵政編碼的Web Service做一個(gè)功能更改，而B部門的開發(fā)人員正忙于處理n個(gè)之前提交的功能需求，所以A部門的需求只能在隊(duì)列中耐心等待直到B部門有開發(fā)人員空閑。如何縮短用戶的等待時(shí)間？Martin建議如果A部門有開發(fā)人員熟悉Web Services，他可以從B部門的源代碼庫中提取郵政編碼Web Service的代碼，并且編碼實(shí)現(xiàn)他需要的功能，完成之后生成代碼包提交給B部門審核和測(cè)試，通過后就可以將代碼合并到代碼庫中。這樣做的優(yōu)點(diǎn)是：1. 將功能需求由開發(fā)部門驅(qū)動(dòng)轉(zhuǎn)變?yōu)橛脩趄?qū)動(dòng)，因?yàn)橛脩羰钦嬲私獠⑿枰@個(gè)功能的人，所以用戶會(huì)更為迫切地運(yùn)用各種手段實(shí)現(xiàn)該功能，同時(shí)保證功能如其預(yù)期的那樣運(yùn)行。 2. 縮短開發(fā)周期，如果用戶不愿意等待的話他可以立即著手開始功能的實(shí)現(xiàn)，而不必等待B部門的人員。3. 有利于公司內(nèi)部的知識(shí)共享和交流，即便A部門的開發(fā)人員不熟悉Web Services但是愿意學(xué)習(xí)，B部門的開發(fā)人員可以通過結(jié)對(duì)編程（Pair Programming）的敏捷方法指導(dǎo)對(duì)方，待對(duì)方上手之后即可返回自己的工作，相對(duì)于B部門開發(fā)人員由始至終開發(fā)整個(gè)功能而言，這仍然可以大大縮短整個(gè)開發(fā)周期。當(dāng)然，公司內(nèi)部的開源策略需要一些前提，首先是部門之間應(yīng)該有共同的知識(shí)領(lǐng)域，代碼和文檔需要版本控制的支持，部門人員能夠理解和運(yùn)用結(jié)對(duì)編程。
6、選擇和運(yùn)用框架
“It is like you buying a new PC every 2 years” 當(dāng)Martin被問道“這么多的應(yīng)用框架層出不窮，我們?cè)撊绾芜x擇？”的時(shí)候如是回答。每幾年我們都會(huì)換一臺(tái)新電腦，是因?yàn)樾碌碾娔X內(nèi)存更大，處理速度更快，應(yīng)用軟件也更復(fù)雜，要求的系統(tǒng)資源也更多。我們使用框架的目的也是解決采用敏捷方法中業(yè)務(wù)相關(guān)的問題，只要是對(duì)業(yè)務(wù)有利的框架，都值得花一點(diǎn)時(shí)間去關(guān)注。 Martin鼓勵(lì)公司允許開發(fā)人員占用一定的工作時(shí)間來實(shí)驗(yàn)新的框架，因?yàn)椴贿@樣如何能夠知道它是否對(duì)提升業(yè)務(wù)價(jià)值有幫助。當(dāng)然框架在生產(chǎn)環(huán)境（Production Environment）中的表現(xiàn)是衡量的一個(gè)重要標(biāo)準(zhǔn)，因?yàn)椴唤?jīng)過生產(chǎn)環(huán)境中各種復(fù)雜情況的檢驗(yàn)，很難最終確定框架是否適用。
【編輯推薦】
