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