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