作者簡介：顧焱，2001年加入用友軟件股份有限公司，歷任NC資金開發部經理、NC供應鏈開發部經理、NC供應鏈開發總監，現任用友軟件股份有限公司助理總裁、NC產品本部副總經理、NC產品線開發總監。
前言：敏捷(agile)這個術語出自2001年2月美國猶他州雪鳥滑雪場的一個聚會，也就是后來著名的“雪鳥會議”。在這個會議上誕生了敏捷聯盟和《敏捷宣言》。敏捷宣言的內容如下：
我們正通過親身實踐和幫助他人實踐，來揭示更好的軟件開發方法。
通過這項工作，我們認為：
個體和交互 勝過 過程和工具
可用的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
雖然右邊的項也具有價值，但是我們認為左邊的項具有更大的價值。
可見，敏捷代表的是不斷探索的進取精神，宣言中“正通過實踐”“揭示更好的方法”，指明大家行進在探索之路。宣言中倡導的價值觀既要追求過程、工具、文檔，但敏捷更重要。
經過多年實踐和探索，我們發現很多方法需要結合自身特點(人員構成情況、不同開發角色比例、公司人力資源政策，甚至中國勞動力市場情況等等)逐步嘗試和推廣，從而建立自己的開發組織方式。Scrum、極限編程(xp)、特征驅動開發(Feature Driven Development，FDD)等敏捷方法學都屬于敏捷實踐，但未涵蓋敏捷全部。我們的目標：以更低的開發成本有效地組織大規模產品開發，產品開發過程更可靠，產品更準確反映用戶需求，實現更穩定交付質量可靠產品。
一直以來，通過收集開發實踐中有效的方法和經驗，并在產品研發部門內部推廣。這種方法逐步改善了開發過程，并推動整個開發組織向敏捷組織轉型。而這些開發實踐，目的都是為了克服大規模產品開發中出現的溝通和協作問題。
接下來，以需求、開發、測試三方面為例，來闡述研發過程中是如何持續進行轉變和改進的。
一、 業務場景主導需求文檔
傳統文檔往往重點描述產品功能，而對業務場景描述較少，在需求討論中對業務場景的討論也不夠充分。由此導致的問題是：程序員和測試人員通過文檔無法有效了解要解決的業務問題，最終都按照文檔完成工作。有時需求驗證通過后，還是有些很明顯的應用錯誤卻被忽略，從而滯后了問題被發現的時間。這樣導致的返工和補丁都大大增加了開發成本。
流程與任務改進后，需求工程師更貼近實際業務，更多傾聽用戶的聲音，這樣就比較容易把用戶的原始需求抽象成業務模型，在業務模型的基礎上再抽象出產品功能模型。在此基礎上，整理出來的詳細需求文檔，就能夠把各功能節點如何實現描述得更加清晰。
我們的實踐經驗是：
探討如何用文檔描述模型，希望通過文檔模板建立通用的描述方法，在文檔中強調需求場景的描述，讓人更容易從業務角度理解需求文檔要解決的問題，從而減少對文檔的誤解;
在概要需求層面整理完整的場景清單，能更好把握產品的方向，更容易把握產品在大解決方案上的能力，降低產品的學習難度，提高顧問學習的速度，并且使產品為將來提供行業預置方案打下基礎;
整理單獨的產品功能模型，需求更容易從業務角度確認產品功能的完整性，在整理過程中也使需求工程師能夠再次以一個完整的視角重新審視產品功能，發現以往忽略的盲區問題，使開發工程師和測試工程師更容易通過模型理解詳細需求的業務目標;
在需求變更管理上我們嘗試建立變更負責人制度，在每個領域內設立需求變更負責人，負責每周收集所有詳細變更清單并發給相關人員，有效地避免變更后文檔更新不及時導致的信息溝通不暢(比如架構師要求的產品目標被詳細需求變更打亂，直到集成階段才發現問題;詳細需求已變更，但測試工程師不知情，錯誤填寫bug導致開發工程師返工。后續計劃開發的需求管理系統，會從系統上徹底解決這個問題);
更多需求工程師到客戶現場調研，通過增加與客戶交流，更好的了解客戶的想法。
二、 “小迭代開發”模式，強化代碼質量和效率
如何保證大版本長周期(12個月以上)編碼的順利推進是在開發中嘗試解決的主要問題。
開發周期上推小迭代開發，周期可以是一周或兩周，根據所在二級部門團隊的情況自己選擇不同的周期，但最長小迭代周期不能超過兩周。在每個迭代周期里要明確具體開發內容，并完成對開發結果的確認。對于在小迭代周期里完成不了的任務也要分階段確認完成情況，避免數個迭代后才發現之前未完成的任務，導致發生大規模返工。
在小迭代中，當完成較大的業務需求后，就可以安排由需求工程師做產品演示。這個活動需要相關各角色(開發工程師、測試工程師、應用架構師、開發經理)都參加。這里明確了演示一定要由需求而不是開發工程師來做。因為需求做演示才能把產品的業務目標完成情況充分表現出來，也更容易發現問題。開發經理通過對每個小迭代的確認，也更容易明確當前的開發進度與整體計劃的偏差，對于風險的控制也更精確。可以快速解決問題，避免到聯調或集成階段再發現。讓發現問題的時間盡可能靠前，這是降低開發成本最有效的手段。
編碼過程，一直在推動開發工程師加強單元自測。但是如何加強，不同團隊理解是不一樣的。在一個全憑自覺的團隊里，加強單元自測只是開發工程師憑自己的責任心和自己對需求的理解進行的測試，也許只是寫完代碼后在開發環境里簡單操作一下就算做完了。但是對于一個訓練有素，協作良好的團隊來說，單元自測首先要知道：測什么，在哪里測，什么情況下算通過?
首先，測什么?不是僅憑開發工程師自己的理解進行測試，而是要與需求工程師和測試工程師充分溝通，并將結果體現在測試用例上。為了避免歧義，測試用例最好明確到具體數據。提倡在每個小迭代周期內編寫當前迭代的測試用例，而不是將所有測試用例寫完再評審，最好由相關的需求、開發、測試三人進行小規模評審，這樣可以快速完成評審，也可以使三人對需求和產品的理解一致，提高溝通的效率。
之所以一直強調溝通，是因為無論文檔怎么寫，對于同樣的一句話，不同的人會有不同的理解，這是在實際工作中會經常碰到的事情。是否需求寫到足夠細就可以更好的避免這個問題?對于開發來說，首先需求要把業務信息表達清楚，如果在此基礎上再細致的寫出所有明細，需求既要從業務方向把問題想清楚又要從邏輯上把所有細節描述清楚，這就像要求一個人文理都精通一樣，難度很高。另一方面。如果需求要撰寫所有業務和明細，這種工作量和時間也是目前資源承受不了的。因此，強調團隊協作，用比較經濟的方式來完成工作，是一種較好的模式。
其次，在哪里測?為什么一直強調在測試環境而不是在開發環境做單元測試?因為這其中有一個做安裝盤的過程。在做安裝盤的過程中，要提交代碼、編譯、導出腳本、打包、安裝，每一個環節都有可能出問題。如果每個環節出現的錯誤都是從測試反饋到開發，就會增加很多交流的時間成本;如果程序員自身簡單測試一下，這些問題就可以很快解決掉，這樣測試工程師就將發現簡單重復問題的時間節省下來，用于發現深入的邏輯問題，在有限的資源投入下，讓產品質量更上一個臺階。
最后，什么情況下算通過?只有測試在安裝盤構建的測試環境下，按照測試用例來測試未發現問題時，才算通過。這里，再次強調了安裝盤構建的測試環境，因為當一個問題補丁測試通過，這個補丁相關的代碼是否正確提交，以及后面一系列做盤的動作是否正確也是需要驗證的。
代碼編寫上通過規范代碼模板，讓新人可以快速學習如何完成工作，讓不同崗位的開發人員可以讀懂別人的代碼，在部分模塊資源緊張的時候從其他團隊調入的人員可以較容易的進入工作狀態，也讓完成的代碼在一個相當長的維護周期里更容易被維護。這里所說的代碼模板，是指完成某一功能需要編寫的代碼片段。代碼片段是需要通過領域內評審認為正確的代碼，但是不一定是最優的。
程序員需謹記：有規范代碼模板的就需要按照代碼模板編寫，不能根據自己的理解編寫自己認為更優化的代碼。在一個大規模的團隊中，可讀性和一致性好對于降低整體的開發成本和維護成本十分重要。程序員的創造性要放到復雜業務邏輯的開發中去，不要在簡單的功能代碼上浪費時間。為了更好的幫助程序員完成簡單的功能代碼，應不斷完善應用開發平臺，應用集成開發環境也即將正式發布。
三、 基于測試用例的產品測試，提升產品質量
產品測試主要解決的問題是如何有效快速的回歸測試，如何盡可能大的覆蓋所有需要測試的路徑，如何準確的判斷當前產品質量。
為了解決這些問題，首先加強了測試用例的管理，推出了測試用例系統。測試用例的編寫要求做了很大改變，要求明細到具體數據。
此舉目的:以前更多的依靠測試人員的能力保證產品質量，但是人員能力的培養是需要周期的，新人不斷加入，產品規模的快速擴大，使得這種保證質量的方式越來越吃力。需要對人員分層，讓初中級測試人員能夠快速具備深入發現產品問題的能力，讓高級測試人員從簡單工作中解放出來。通過明細到具體數據的測試用例，可以把高級測試人員的經驗固化，讓初中級測試人員可以通過執行測試用例快速發現問題，完成測試用例的回歸，從而使原來不可復制的核心資源問題，變成增加人力可以部分解決的問題，也為將來遠程測試資源的使用提供一種可行的工作方式。
另外，自動化測試也需要在數據明細具體的測試用例基礎上進行。測試數據準備、明確的測試預期結果、數據明確的測試用例，是自動化黑盒測試的有效支撐。通過大規模的測試用例整理和測試用例系統的支撐，使回歸范圍的計劃、統計和產品質量的評估都成為可能。
大型軟件產品的大規模研發，是一個持續改進的過程。敏捷的研發組織需要規范的管理和管理創新。在研發實踐中不斷地發現問題，總結解決問題的有效方案和方法，并在組織內有效的推廣，這是一個敏捷研發組織的原動力。整理/汽車座套廣告--www.qichezuotao.cn）
推薦閱讀
騰訊科技訊（明軒）北京時間3月20日消息，據國外媒體報道，美國互聯網公司AOL數字先知（職務）大衛-辛恩（David Shing）周一在倫敦表示，網站較基于應用的產品有著極大的優越性，應用是一種垃圾概念。 AOL數字先知大>>>詳細閱讀
地址：http://www.xglongwei.com/a/43/20120320/42486.html
網友點評
精彩導讀
科技快報
品牌展示