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