Onboard：以數據驅動的敏捷軟件開發協同工具

陳 龍 葉 蔚 張世琨

(軟件工程國家工程研究中心(北京大學) 北京 100871)(chenlongpku@163.com)

?

Onboard：以數據驅動的敏捷軟件開發協同工具

陳 龍 葉 蔚 張世琨

(軟件工程國家工程研究中心(北京大學) 北京 100871)(chenlongpku@163.com)

Scrum是一種兼顧計劃性與靈活性的敏捷開發過程,能讓軟件開發團隊具有快速工作和響應變化的能力.軟件開發生命周期中每一個環節都會產生大量的數據，如果能記錄下這些數據進行分析，并通過可視化等手段展示和反饋，則能進一步促進團隊管理、項目管理，提高開發效率.現有的軟件開發管理工具中，項目管理和代碼管理往往是相互獨立的，這導致了數據的分散和未充分利用.為推廣以Scrum為核心、以數據為驅動的敏捷軟件開發過程，開發了一款基于云服務的Onboard敏捷軟件開發協同工具, 利用代碼提交和任務的關聯，創造性地將敏捷過程管理、源代碼管理和項目管理有機地整合到一起，支持端到端的軟件全生命周期管理，從而能記錄下軟件開發過程中產生的所有數據并提取有價值的信息，為中小軟件開發團提供一站式的敏捷開發管理與協同服務.1)介紹了Onboard的設計理念；2)圍繞著“如何利用軟件開發過程中產生的數據更好地支持敏捷開發過程”和“如何評估團隊成員貢獻度”兩大課題，全面介紹了數據可視化和數據分析在Onboard敏捷軟件開發協同工具中的應用，并針對一系列相關問題提出了解決方案；3)對值得進一步研究的問題進行了展望.

數據驅動;敏捷軟件開發;Scrum;軟件生命周期;數據可視化;代碼提交與任務關聯;貢獻度評估;代碼影響行數

20世紀60年代中期“軟件危機”的出現，使得人們不得不重新認識軟件開發的標準、方法和技術.2001年，17位軟件專家聚集在一起概括出了讓軟件開發團隊能夠快速工作、響應變化的價值觀和原則，進而產生了我們現在所熟知的《敏捷軟件開發宣言》[1].研究表明，由于軟件是迭代發布的，在一個迭代過程中變化容易得到控制，因此敏捷軟件開發過程能有效地減少需求變化產生的成本[2].

遵循敏捷價值觀和原則設計出來的軟件開發過程模型都是敏捷開發過程模型，其中近年來業界比較流行的是Scrum，一種兼顧計劃性與靈活性的敏捷開發過程.Scrum一詞的含義源自橄欖球[3]，在19世紀90年代由Sutherland及他的開發團隊提出，并在21世紀后由Schwaber和Beedle做了進一步的改進[4].Scrum開發過程從一開始就假定了混亂的存在[5]，因而使得使用它的敏捷開發團隊在必然存在的不確定性面前得以順利工作.Scrum團隊以短小的迭代(sprint)為單位進行工作，關于團隊中的角色和典型的迭代流程的介紹可參見附錄A.

然而Scrum方法并不是萬靈藥.國內第一位看板教練吳穹在《精益開發與看板方法》[6]一書的推薦序中指出，在他多年敏捷咨詢的過程中，經常需要進場拯救那些將Scrum實施成小瀑布的項目.Scrum方法中的看板和燃盡圖為項目負責人把握項目進度提供了最基本的工具，但僅僅有這些工具是不夠的，比如項目負責人無法利用看板和燃盡圖監控軟件的質量.軟件開發團隊需要利用更多更先進的工具促使開發過程達到敏捷的狀態.

經常困擾項目負責人的另一個問題是：如何公平、高效地對團隊成員的貢獻進行評估.如果需要手動去統計每個成員完成了幾個任務、提交了多少行代碼等，是非常瑣碎的.此外，一個軟件團隊往往還分成若干小團隊開發相關但相對獨立的子項目，尤其是在移動互聯網快速發展的背景下，一個團隊很可能同時開發Web端和多個移動端的產品，這無疑使手動的評估過程變得更加繁瑣.

事實上，軟件開發生命周期的每一個環節都會產生大量的數據，如果能記錄下這些數據并對這些數據進行分析，提取有價值的信息，并通過可視化等技術進行信息的展示和反饋，則能夠為開發團隊的建設、項目進度和質量的控制、工作流程的完善等提供有力的支持，也為自動化評估團隊成員的貢獻提供了可能.

團隊成員間合作和溝通的傳統媒介往往是非常樸素的，比如面對面的溝通、白板、海報板、索引卡和便簽等[7].這些手段無法將軟件開發過程中產生的數據積累起來并加以利用.近些年來，很多軟件開發管理工具被開發出來，但這些工具往往功能比較專一，比如缺陷管理、源代碼管理、任務管理等，導致軟件開發過程中產生的數據過于分散，未能被充分整合利用.

國內項目管理工具的領跑者Tower從去年(2015-07-09)在標準項目之外開始支持敏捷項目[8]，但其并沒有融入Scrum的流程即迭代.該產品也提供了團隊成員貢獻度的統計，但僅僅是計算了完成任務數量的百分比.此外，由于定位于一般的團隊項目管理，Tower并不支持源代碼管理.

Github是基于Git的代碼托管、版本管理和協同開發的云平臺，集成了issue(類似于缺陷)管理、持續集成等功能，是開源軟件社區協作開發的首選.Github本身不支持以任務為核心的項目管理，這點和開源軟件的開發特點比較吻合，但無法滿足敏捷軟件開發團隊的需求.

還有一些工具，試圖整合項目管理和代碼管理.國內比較知名的有Coding.Net，但它并不支持敏捷開發，并且項目管理和代碼管理是相對獨立的模塊，沒有能有效整合并利用軟件開發過程中產生的數據.

我們認為，對于軟件開發團隊來說，項目管理和代碼管理是不可分割的整體.為推廣以Scrum為核心、以數據為驅動的敏捷軟件開發過程，我們開發了一款基于云服務的Onboard敏捷軟件開發協同工具,利用代碼提交和任務的關聯，創造性地將敏捷過程管理、源代碼管理和項目管理有機地整合到一起，支持端到端的軟件全生命周期管理，從而能記錄下軟件開發過程中產生的所有數據并提取有價值的信息，為中小軟件開發團提供一站式的敏捷開發管理與協同服務.

本文結構如下:1)介紹了Onboard敏捷軟件開發協同工具的設計理念、功能及架構，并和市面上主流的幾款相關的項目管理軟件進行了對比；2)圍繞著如何利用軟件開發生命周期中各個環節產生的大量數據更好地支持敏捷開發過程、評估團隊成員的貢獻度，介紹了Onboard開發團隊在數據可視化和數據分析的實踐，著重討論了任務和代碼的關聯、代碼倉庫的可視化、團隊成員貢獻度自動化評估、缺陷預警和責任人推薦等問題；3)總結全文，列舉主要貢獻，并展望進一步的工作.

1 Onboard介紹

Onboard致力于做最專業的敏捷軟件開發協同工具.Onboard是注冊即用的云服務*http://onboard.cn，能夠通過Web，iOS和Android多種平臺使用，支持無處不在的開發協同.

Onboard核心價值觀是推廣以Scrum為核心的敏捷軟件開發過程.Onboard將產品設計、編碼、測試、持續集成、發布和運維等各階段進行有機地連接和集成，支持端到端的軟件全生命周期管理，提高軟件開發人員之間的協作效率，從而加速軟件開發，為中小軟件開發團打造一站式的敏捷開發管理與協同服務.

Onboard提供的各項功能從邏輯上可以分為3個類別，彼此緊密聯系.

1) 敏捷過程管理

① 通過看板來規劃敏捷軟件開發中的每一次的迭代，完美支持Scrum；

② 通過看板來追蹤需求、任務和缺陷的狀態；

③ 展示每一次迭代的燃盡圖，以及代碼行數和代碼提交等豐富的統計信息.

2) 源代碼管理

② 專業化的Code Review功能，對每一個代碼合并請求、每一次代碼提交、每一行代碼都能討論；

③ 需求、任務和缺陷與代碼有機關聯，可以看到所有相關的代碼提交；

④ 后臺整合了Sonarqueb代碼質量分析工具，網站通過訪問后臺的api展示分析的報告，其中包含技術債務等信息，便于團隊對代碼質量進行把關；

⑤ 后臺整合了Jenkins服務器，用戶可以在網站上撰寫自己的腳本，執行代碼的構建和測試，并可查看所有的歷史任務和執行結果，實現持續集成；

⑥ 利用Docker容器技術為用戶部署Web應用.

3) 項目管理

① 通過Git客戶端與系統進行交互，如關聯任務、完成任務等.

② 具備話題討論、任務分配、團隊日歷、在線文檔、文件共享、團隊管理這些通用的項目管理功能；

③ 項目所有相關活動都能夠清晰地自動記錄，并同過大量數據可視化，細粒度地展現項目的全貌；

④ 通過郵件和客戶端將團隊動態第一時間推送給團隊成員；

⑤ 為項目的所有關鍵信息建立了全文索引，提供了搜索功能.

此外Onboard還實現了功能的插件化，能讓用戶打造適合自己團隊項目的工具集.Onboard現已開源，其開源版本的源代碼可以在Github*https://github.com/sercxtyf/onboard上找到.

Onboard的整體架構如圖1所示.

Onboard在設計之初就考慮了數據的積累.從一句評論到一次代碼提交，凡是用戶在Onboard上進行的操作都會生成活動的日志.這為進一步做數據挖掘提供了數據來源，進而可以從數據中提取有價值的信息.

Onboard將敏捷過程管理、源代碼管理和項目管理有機地整合在一起，從而支持軟件全生命周期的管理，并對軟件開發過程中產生的數據進行收集和分析，在軟件工程業界是獨樹一幟的.表1把Onboard和其他一些業界主流的基于云服務的項目源代碼管理工具從功能上進行了對比.

Fig. 1 The system architecture of Onboard, an agile software development collaboration tool.圖1 Onboard敏捷軟件開發協同工具的系統架構圖

SaaSToolTaskManagementAgileProcessManagementSprintTaskVisualizationSourceCodeManagementCodeQualityAnalysisContinuousIntegrationGitCommitsStatisticsLinesofCodeStatisticsTowerYesYesNoYesNoNoNoNoNoCoding．NetYesNoNoNoYesYesYesYesNoMartianAgileDevToolYesYesYesNoNoNoNoNoNoGithubNoNoNoNoNoNoYesYesYesOnboardYesYesYesYesYesYesYesYesYes

2 代碼提交與任務關聯

敏捷開發強調的是對變化的快速響應，而實際開發過程中，Scrum敏捷開發團隊最容易進入的一個誤區就是把“敏捷”等同于“快速”，把“增量式地產出可工作的產品”等同于“盡可能按期完成迭代中的所有任務”——當對照燃盡圖發現進度落后時，團隊的第一反應是要加快開發速度、甚至加班加點趕進度，而不是去查找影響進度的因素.如此一味追求進度，導致對軟件質量的忽視，也就無怪乎劣質代碼入庫、產品“裸奔”上線等情況會頻頻發生.

軟件質量保障是軟件開發生命周期中不可缺少的一個環節，而軟件的質量主要體現在代碼的質量.Scrum方法所描述的軟件開發過程，以及常用的看板、燃盡圖等工具，都是著眼于進度管理的，無法輔助軟件質量的管理.因此，敏捷軟件開發團隊，需要這樣一款工具，能把敏捷過程管理和源代碼管理結合起來.

但是，僅僅把簡單敏捷過程管理工具和源代碼管理工具的功能加在一起是不夠的.一個需求是否被滿足、一項任務是否完成，取決于相關的代碼是否實現以及相關代碼的質量，兩者是密不可分的.因此需要有一種機制能把敏捷過程管理和源代碼管理有機地聯系在一起，發揮“1+1>2”的作用.敏捷過程管理是對需求和任務的管理，源代碼管理是對代碼的管理，鑒于此，我們提出了代碼提交與任務進行關聯的機制.這里的任務是廣義的，既包含滿足產品需求所要實現的具體步驟，也包含待修復的缺陷.

有2種途徑實現代碼和任務的關聯：1)將合并請求(pull-request)和任務關聯；2)將代碼提交(commit)和任務關聯.

代碼提交是指本地開發時增量保存當前新修改的代碼，同時在代碼提交注釋(commit message)中注明這些代碼的作用.一般建議是及時提交修改，以便發生錯誤時能快速復原代碼，故一個任務往往對應多次代碼提交.Github支持在commit message里面填寫#{issueId}，當代碼提交推送至Github時，系統自動識別#{issueId}，將代碼提交和相應的issue關聯.如果在#{issueId}之前添加關鍵詞close或fix，還可以自動關閉該issue.Github中的issue類似于缺陷，但不完全等同，因為issue還可以是討論或建議等.

相比之下，在敏捷開發過程中，將代碼提交和任務相關聯是更合適的選擇.迭代中的任務主要是需求分解成的具體實現步驟，Scrum方法提倡任務粒度細化，以小時為單位估計任務的工作量，故一次合并請求中可能包含多次代碼提交，并且對應著多個相關的任務.因此，無論在多個任務中關聯一個合并請求，或是在一個合并請求的描述中添加多個任務，都比較繁瑣.相反，一次代碼提交通常只對應一個任務，若借鑒Github的做法，利用代碼提交的commit message實現代碼和任務的自動關聯，則操作十分簡便.

我們在Onboard中采用了第2種途徑實現代碼和任務的關聯，并做了如下改進：

1) 迭代中的看板由“未開始”、“正在做”和“已完成”3個基本欄目構成，團隊可根據自身需要在“正在做”和“已完成”之間添加新的欄目，比如“等待測試”、“等待驗收”等.當commit message中的任務編號前添加了fix或close等關鍵字后，默認將該任務從當前欄目移動到下一個欄目，而非完成任務.

2) 若發生漏操作或誤操作，在倉庫所有代碼提交的列表頁面中，可以添加或解除任務關聯,亦可在某個任務的相關聯的代碼提交列表中解除關聯.

3) 創建合并請求時，默認將本次合并請求所包含的所有代碼提交的commit message合并為合并請求的描述，代碼審核者可點擊描述中的任務編號，便捷地打開相應的任務進行查看.這也間接地實現了合并請求和任務的關聯.

將代碼提交和任務關聯，從功能上打通了敏捷項目管理和源代碼管理，具有7點好處：

1) 團隊成員在提交代碼的同時就能改變任務的狀態；

2) 便于產品負責人跟蹤任務的進度和具體實現；

3) 提供關于任務更有價值的信息，便于項目負責人了解任務的工作量和質量；

4) 對于缺陷，能通過關聯的代碼提交準確定位到產生缺陷的代碼文件及具體位置；

5) 便于團隊知識的積累、分享和傳承.需求分解成了任務，任務關聯了代碼，如果有新的團隊成員加入，或者團隊成員之間互相學習等，希望了解一項功能是具體如何實現的，可以順著“需求→任務→代碼”這條線索，定位和功能相關的代碼，從代碼級別深入了解；

6) 能從任務和代碼2個維度共同刻畫出“開發者畫像”；

7) 可以更準確地判斷出有代碼關聯的任務的結束時間，從而更準確地描述任務尤其是缺陷的生存期.

3 敏捷開發過程的可視化分析

數據可視化主要是借助于圖形化手段，清晰有效地傳達與溝通信息.和計算機相比，人腦更善于理解視覺圖像并從視覺圖像中提取有價值的信息，因此，數據可視化技術能更有效地幫助人們理解數據.軟件開發生命周期的每一個環節都會產生大量的數據，可視化分析的方法是從這些大量的數據中提取有價值的信息的有效手段.

Onboard收集了用戶在開發過程中產生的所有數據，并通過可視化的技術進行信息的提取和展示，從而為開發團隊的建設、項目進度的控制、工作流程的完善、團隊成員貢獻的自動化評估提供有力的支持.

在可視化實踐的過程中，我們強調圖表的可交互性.可交互的圖表具有更好的用戶體驗，也能豐富圖表的語義，展現復雜、多維度的數據.比如，在Onboard提供的統計圖中，可以通過選擇不同的項目成員，對展示的數據進行篩選；也可以選擇查看不同時間區間的數據；響應用戶操作時，多張統計圖可以聯動地變化等.

在可視化的機制上，我們采用了先用Web Api從后臺獲取相關數據、后用Javascript在前端處理數據并繪圖展示的方式.我們在開發過程中使用了D3.js等第三方開源的Javascript庫.

由于可交互性的需求，在獲取一組數據時，先拿到了所有成員的數據，存儲在圖表對應的Javascript對象中，再根據用戶的操作篩選數據.這樣可以避免在切換成員時頻繁向后臺發送ajax請求，前端處理數據、繪圖的速度相對較快，用戶體驗較好；此外可以同時展示全體成員和個體的2張圖，進行對比.

下面將介紹在Onboard中，如何利用可視化分析支持敏捷開發過程.

3.1 活動記錄的Punch Card圖

Punch Card中文意思是穿孔卡，最早運用在IBM計算機上，通過在紙片上不同的位置上穿孔代表不同的數據.而在數據可視化領域，Punch Card又被賦予了新的含義.以活動記錄的Punch Card圖為例，縱軸刻度表示周一至周日，橫軸刻度表示0點至23點，于是平面上就由坐標軸形成了多個交點.每個交點上的一個圓代表數據點，數值為對應的一個小時內的活動記錄數量，圓的大小或顏色的深淺代表數值的大小.如圖2所示：

Fig. 2 User’s Punch Card of number of activities on Onboard.圖2 用戶在Onboard上活動數目的Punch Card圖

用戶在使用Onboard時，任何的操作都會生成一條活動記錄.獲取一段時間內用戶活動記錄的數目并繪制成Punch Card圖，可以發現一些有趣的信息，從而幫助項目負責人了解團隊成員的工作狀態.比如：

1) 假設每周五是開迭代評審會和反思會的時間，如果發現團隊成員的活動記錄突出集中在周五的前兩天，說明團隊中存在趕deadline的現象，平常可能有消極怠工，需要及時干預；

2) 可以了解團隊成員的偏好，如喜歡白天工作還是夜里工作；

3) 通過成員之間的對比，判斷整個團隊工作的步調是否一致，是否有良好的協作.

3.2 缺陷統計圖

缺陷的及時發現和修復是軟件開發過程中不可缺少的一個環節.一個成員發現缺陷數目和修復缺陷數目的多少，可以反映出該成員是否具有產品的主人翁精神.在缺陷管理模塊中，Onboard提供了對比團隊成員之間發現缺陷數目和修復缺陷數目的2張餅圖.

3.3 代碼提交數據可視化

代碼提交次數和行數是軟件開發團隊衡量工作量最重要的指標之一.Github為托管在上面的代碼倉庫提供了豐富的統計圖，非常值得參考，特別是Contributors,Commits和Punch Card.

如圖3所示，在Contributors統計圖中，可以在右上角切換3個統計量：增加的代碼行數、刪除的代碼行數、代碼提交的數目.左上方注明了倉庫存在的時間，時間下方是一句說明，意思是“只統計對master分支的貢獻，并且不包含合并請求時產生的代碼提交”.位于中間的第1張圖在時間軸上呈現了master分支上統計量隨時間的變化，時間軸的下方枚舉了不同貢獻者的數據.在第1張圖中可以用鼠標拉取時間窗，下方的不同貢獻者的統計圖會隨之變化，只展示時間窗內的數據.

在敏捷開發過程中，也需要統計團隊成員的代碼貢獻量.我們在Onboard中同樣做了代碼提交的可視化，和Github有相似之處，但也有創新.

最大的一點不同是，我們采用了多分支的統計而不是基于master單一分支的統計.這是考慮到了團隊項目和開源項目固有的區別.對于Github上的開源項目，任何人都可以創建新的分支，在上面修改或添加代碼并提交，這些代碼可能是重復的、不必要的甚至錯誤的.因此，判斷開發者是否對開源項目產生貢獻，比較合理的是看他提交的代碼有沒有被合并進master分支.而在敏捷開發團隊中，一般不會出現“無用功”的代碼，因此，凡是同步到Onboard上托管的中央倉庫的分支所包含的代碼提交都應計入工作量的統計之中.

另外，我們把代碼的增加行數(最上方的折線)和刪除行數(最下方的折線)并排顯示在折線圖中，同時顯示一條虛線(中間的折線)表示倉庫代碼總量的變化，并在圖的下方添加了團隊成員對比的餅圖，如圖4所示.

Fig. 3 Contributors graphs on Github (based on Apache Spark project).圖3 Github貢獻者統計圖(以Apache Spark項目為例)

Fig. 4 Code contribution graph on Onboard.圖4 Onboard中代碼行數統計圖

值得一提的是圖4中3個圖是聯動的：點擊任意餅圖中的切片，2張餅圖相應的切片都會突出，在上方的折線圖中則會相應顯示切片對應的用戶的統計數據.

代碼提交的次數則單獨制作了一張統計圖，與圖4類似.此外還繪制了代碼提交次數的Punch Card.

另一個創新的地方是在數據點的tooltip中顯示了數據點包含的代碼提交列表，而不僅僅是代碼總行數或總次數.點擊代碼提交的ID，會打開一個浮動的窗口，顯示這次代碼提交影響的代碼.這大大增加了統計圖的可交互性.如圖5所示.

Fig. 5 Punch Card of number of commits with enhanced tooltips.圖5 帶列表和導航的代碼提交次數Punch Card圖

我們額外維護了一張Git_email和Onboard_user的關聯表，目的是將代碼提交準確地和團隊成員對應，避免用戶在Git中設置的email和用戶在Onboard中設置的email不一致而產生的問題.

3.4 迭代總結報告

除了Scrum方法中常見的燃盡圖之外，我們在Onboard中還設計了一份詳實的迭代總結報告.報告中除了列舉本次迭代中已滿足的需求、完成的任務之外，還整合了燃盡圖、任務統計、代碼提交統計等統計圖.利用報告，在召開迭代總結會時能夠做到3點.

1) 確認迭代完成的質量；

2) 了解各個團隊成員的工作量和工作狀態；

3) 發現迭代中存在的問題，在下次迭代中進行改進.

有2點特別值得注意：1)這些統計圖是聯動的，可以同時切換顯示某個成員的統計數據；2)在后臺加入了snapshot(快照)的機制，一旦結束當前迭代之后，這份報告將永遠保存下來，里面的數據和統計圖都不會發生變化，以供日后回顧時查看.

4 團隊成員貢獻度評估

4.1 代碼影響行數(affected lines of code, ALOC)

代碼量是軟件開發團隊中衡量成員工作量的最重要的指標之一.在用Git進行版本管理的代碼倉庫中統計代碼量時，通常會計算2個指標:1)增加的代碼行數;2)刪除的代碼行數，對每次代碼提交分別計算再累加而成.Github和Onboard中的代碼統計都是這樣做的.那么，問題出現了：給出了增加的代碼行數和刪除的代碼行數，如何衡量代碼量呢？

在開發過程中，對代碼的改動無外乎3種情況：增加代碼、刪除代碼、重構代碼.在重構代碼時，既有代碼的增加，也有代碼的刪除，因而不能把增加的代碼行數和刪除的代碼行數簡單加在一起來衡量代碼量.若僅考慮代碼的增加量，有這樣一個缺陷：代碼重構時，常常會通過設計模式或更好的算法，用更精煉的代碼替換原有代碼，在這種情況下，用較少的新增的代碼行數，無法衡量減少了更大篇幅代碼所做工作的價值.

另一個需要考慮的問題是：刪除的代碼行數是否計算在工作量之內？我們認為，單純地刪除代碼不考慮在內.

此外，還有2種特殊情況需要區別對待：引入第三方庫，往往會增加大量的代碼行數；挪動一個代碼文件的位置會產生一對數值很大且相同的增加的代碼行數和刪除的代碼行數.

綜合以上考慮，我們提出了代碼影響行數ALOC的概念來衡量代碼量.把一次代碼提交的ALOC記為commitALOC，把一處代碼增量差異(diff)的ALOC記為diffALOC.我們是這樣計算commitALOC的：

若本次代碼提交是分支合并產生的合并結點,忽略不計；

對代碼提交中的每一處diff： 若只有代碼的增加,則diffALOC=增加的代碼行數；

若只有代碼的減少,則diffALOC=0；

若既有代碼的增加也有代碼的減少,則diffALOC=max(增加的代碼行數，刪除的代碼行數)；

若diffALOC超過了限制(如300行),則diffALOC=0；

累計所有diffALOC，得到一次代碼提交的commitALOC；

若commitALOC超過了限制(如3 000行)，則commitALOC=0.

在實際使用Onboard的過程中，驗證了ALOC是衡量代碼量的有效指標.

4.2 跨項目的團隊統計

Onboard允許一個團隊建立多個項目，一名團隊成員可以加入一個或多個項目.每個項目相對獨立，有自己的代碼倉庫和迭代等.第3節所介紹的數據可視化分析都是基于單個項目的.

實際調研后發現，一個開發團隊往往同時并行若干個子項目，特別是創業型的團隊，而項目負責人只有一個.例如Onboard團隊曾在某一段時間內，同時開發Web應用、安卓應用和蘋果應用.手動統計每個成員的工作量，比如提交的代碼行數等是一件非常繁瑣的事情.有了數據可視化工具的輔助，這項工作就大大簡化了，通常只要查看統計圖、在統計圖中進行一些交互操作即可.但在多項目并行的情況下，項目負責人若想比較團隊各個成員的工作量、了解團隊整體的動態，仍需要分別查看各個項目的統計數據再進一步匯總.因此，跨項目的團隊統計能夠進一步解決項目負責人的痛點.

在Onboard上的團隊統計頁面，我們提供了這樣一個可視化的統計工具，如圖6所示:

Fig. 6 Visualization tool of team statistics across projects.圖6 跨項目的團隊統計工具

該工具包含7項功能：

1) 有5個統計量供用戶選擇：活動記錄數量、完成的任務數量(狹義，指從需求分解出的任務)、修復的缺陷數量、代碼影響行數、代碼提交次數；

2) 可以自定義統計的日期范圍；

3) 可以選擇團隊所有項目匯總后的統計數據，也可以單獨查看某一個項目；

4) 提供了團隊成員之間數據對比的餅圖；

5) 點擊餅圖中的切片，可以選擇性地查看某一個成員的數據；

6) 提供了時間變化趨勢圖和Punch Card圖，可以進行切換；

7) 點擊數據點，右側顯示該數據點包含的具體內容.

4.3 團隊成員貢獻度的自動評估模型

軟件開發生命周期的每一個環節都會產生大量的數據，而Onboard支持軟件開發全生命周期的管理，并記錄了用戶所有的操作，這些數據的積累為建立團隊成員貢獻度的自動評估模型提供了可能.

我們做了這樣的實驗：選取若干次迭代為研究對象，獲取了迭代起止時間范圍內團隊成員的各類數據，分別計算出每個成員的5個統計量——活動記錄數量、完成的任務數量、修復的缺陷數量、代碼影響行數、代碼提交次數，作為自變量；從項目負責人那獲取了每個迭代中各個成員的評分(百分制，團隊成員互評+負責人打分)作為應變量，然后通過統計學的方法計算一個模型，能夠利用5個自變量預測評分.

為了讓模型有更好的解釋性，我們從線性回歸模型開始入手.

方案1.

Y評分～β0+β1X活動數+β2X任務數+β3X缺陷數+

β4X代碼影響行數+β5X代碼提交次數，β1～β5>0.

擬合后得到的結果并不是很理想.首先通過探索性分析發現，代碼影響行數和代碼提交次數存在很強的共線性，因此代碼影響行數和代碼提交次數在線性模型里面只能保留一個.保留代碼影響行數后，凡是出現系數β值為負數時，就把相應的變量從模型中剔除，如此反復計算，最后得到的模型中，系數β顯著不為0的變量僅僅只有代碼影響行數！顯然這個模型過于簡略，無法投入到實際應用中去，比如它無法評價沒有代碼提交卻有完成任務的成員的貢獻量.

由于我們要求模型要有好的解釋性，從而限制了β1～β5>0.其實β的含義是非常明確的，表示某一項指標在綜合考核指標中所占的比例.若再加上一條所有β之和為1的限制，可以把這個問題轉化為帶有約束的優化問題.

方案2.

定義變量P=

損失函數為

∑|Y評分-(β1P活動數+β2P任務數+β3P缺陷數+

β4P代碼影響行數)|；

約束條件為β1～β4>0,β1+β2+β3+β4=1.

編程求解過程中，可設系數β的最小步長為0.05，遍歷所有β1～β4的可能取值(3重循環)，返回使損失函數取值最小時β1～β4的取值.最后得到的結果是β1=0.55,β2=0.15,β3=0.15,β4=0.15.

將輸出的模型應用到評估團隊成員貢獻度，如圖7所示.圖7中用p1～p19表示團隊成員的姓名，同時存在不活躍的團隊成員.

Fig. 7 Demo of team member contribution evaluation.圖7 團隊成員貢獻評估示例

5 數據可視化和數據分析的更多應用

5.1 團隊成員關鍵詞詞云

詞云(word cloud)是一種有趣的、有獨特視覺效果的文本信息可視化工具，最早起源于標簽云，在20世紀末由Flickr等網站的大量使用而普及開來[9].詞云是在一定區域內不重疊地擺放一組不同字體大小的單詞形成的，字體的大小通常表示單詞的權重，如詞頻.單詞的顏色通常只是為了視覺效果的美觀，沒有其他含義.

將每個團隊成員的關鍵詞按一定權重制作成詞云，可以一目了然地展示該成員所關注的問題、曾參與開發的功能等信息，起到類似用戶畫像的作用.

如何提取團隊成員的關鍵詞并計算權重呢？如果把用戶看成一篇文章，把軟件開發過程中積累下來的和該用戶相關的文本信息的總和看成是文章的內容，那么就可以用文章關鍵詞自動提取的技術，實現用戶關鍵詞的自動提取.

從很長的文章中提取關鍵詞，涉及到數據挖掘、文本處理、信息檢索等很多計算機前沿領域，但有一個簡明、有效的經典算法——TF-IDF算法：

TF-IDF=詞頻(TF)×逆文檔頻率(IDF)；

詞頻(TF)=

逆文檔頻率(IDF)=

可以看到，TF-IDF與一個詞在文章中出現的次數成正比，與這個詞在整個語料庫中出現的次數成反比.

引申到提取團隊成員的關鍵詞，則：

詞頻(TF)=

引申后的TF-IDF可以表示對一個單詞對某一用戶而言的權重.

計算一個用戶所有相關單詞的TF-IDF并按降序排列，取前N個，就是該用戶的關鍵詞.

在代碼實現過程中，我們是這樣設計流程并優化的：

1) 在數據庫建立一張用戶-單詞關聯表，記錄用戶不同單詞的詞頻(單詞出現的次數)，當用戶在Onboard上操作時，就提取相關的文本(包括但不僅限于發起的討論、評論、完成任務的內容及相關聯的需求、修復的缺陷描述、代碼提交中的commit message、上傳文件的文件名等)，進行中英文分詞操作，并更新該用戶這些詞的詞頻以及所有團隊成員的這些詞的TF-IDF.

2) 向后臺請求用戶的關鍵詞列表時，后臺返回的是根據TF-IDF排序的、有數量上限的(如100個)關鍵詞列表.

3) 繪圖算法中，根據該用戶的關鍵詞數目，優化最小字體號，為了在關鍵詞數目較少時繪制的詞云不至于太過稀疏.

4) 點擊詞云中的關鍵詞，跳轉到搜索頁面，自動顯示和該用戶相關的這個關鍵詞的搜索結果.

我們用d3-cloud*https://github.com/jasondavies/d3-cloud第三方Javascript插件繪制關鍵詞詞云，展示在團隊成員的個人頁面，如圖8所示：

Fig. 8 Demonstration of keyword cloud of a team member.圖8 團隊成員關鍵詞詞云示例

5.2 缺陷生存期預警

缺陷是軟件開發團隊不愿意遇見的，但卻永遠無法避免的.缺陷一旦出現，最理想的狀態當然是越快修復越好，但這種“變化”很容易打亂團隊的開發計劃.實際開發中，嚴重、緊急的缺陷一般要盡快修復，而不是那么緊急的缺陷，有的團隊會指定專人負責修復缺陷；有的團隊習慣把缺陷擱置一旁，等累積到一定數目再集中時間修復；也有的團隊在計劃任務時會預留出修復缺陷的時間，將缺陷修復和新功能的開發交替進行.

Scrum方法中沒有具體說明如何管理缺陷，一般而言，可以把缺陷看作一類需求，在開迭代計劃會時和其他需求一并安排進入下一次迭代[3].我們建議，緊急程度較高的缺陷可以添加進當前迭代，在計劃會時可以根據經驗預留一定的工作量.

一個缺陷的重要程度是會隨時間發生變化的，如果存在的時間越長，就越應該引起團隊的重視.Onboard中設計了這樣一種機制：若一個缺陷存在的時間超過了歷史平均期限，就會高亮這個缺陷條目，以提醒開發團隊及時處理.

首先定義隨機變量T，表示缺陷的生存期，即缺陷從創建到修復的持續時間.如果缺陷有代碼提交與之關聯，則修復的時間點設置為最后一次提交的時間；否則，修復的時間點設置為缺陷狀態更改為“已修復”的時間.

其次，選擇合適的統計量描述隨機變量T分布的中間值.在統計學中有3個統計量可以描述一組隨機變量取值的中間值：平均數、中位數和眾數.眾數適用于隨機變量取值有限的情況，不適用于時間變量T.假設當前已有n個已經修復完成的缺陷，下面分別就采用平均數的和采用中位數的2種方案分別展開討論.

1) 采用均值和標準差

假設T服從正態分布N(μ,σ)，則當ti>μ，提醒用戶該缺陷存在的時間超過了歷史平均時長；當ti>μ+σ時，提醒用戶該缺陷存在的時間過長.其中μ和σ分別表示均值和標準差，由已修復的n個缺陷的t計算得到.

方案1的問題在于：1)均值容易受到異常值的影響；2)正態分布的假設不一定成立.

但方案1的優點在于均值和方差計算簡單，時間復雜度是O(N)，并且，均值和方差可以通過遞歸計算得到，證明如下：

對于正態分布，方差Dn(T)=σ2，期望En(T)=μ，因此，只需保存當前的En(T)和En(T2)，當有一個新的缺陷修復完成時，利用上面的公式就計算出En+1(T)和En+1(T2)，從而快速計算得到新的μ和σ，時間復雜度是O(1)的.

2) 采用分位數

利用基于快速排序的Top-K算法(在快速排序的過程中可得到第K大或第K小的數，不需要全部排序完成后就能得到結果)，計算出T的50%分位數t0.5(即中位數)和75%分位數t0.75，當ti>t0.5時，提醒用戶該缺陷存在的時間超過了歷史平均時長；當ti>t0.75時，提醒用戶該缺陷存在的時間過長.

和均值相比，分位數受異常值的影響很小，因而方案2更健壯.

平均情況下Top-K算法的時間復雜度是O(N)的.但是分位數需要排序才能找到，無法用公式表達，無法得到遞推關系式，因而在需要更新時不得不每次重新計算分位數，無法達到方案1的O(1)時間復雜度.

是否能設計一種算法，把上述2種方案的優點結合在一起呢？

考慮到距離現在越久遠數據對現在的指導價值越小，因此在計算分位數時可以只考慮最新的k個數據點構成的數組.當一個新的數據點插入數組時，把最老的數據點從數組中刪除，數組維持長度為k不變.以計算中位數為例，假設當前k個數據點的中位數為X0.5，最老的數據點值為Xold，插入的數據點為Xnew.若XoldX0.5且Xnew>X0.5，即當插入和刪除的數據點在數組排序后位于X0.5同一側時，X0.5的值不發生改變.

基于這樣的想法，可以提出方案2的改進版：

保存當前n個缺陷的T的50%分位數t0.5和75%分位數t0.75；

當第n+1個缺陷完成修復時，

若n

若n≥k，記最新的k個缺陷的T為tn-k+1～tn，比較tn-k+1，tn+1，t0.5，t0.75的大小：

若tn-k+1，tn+1同小于或同大于t0.5，則t0.5不變，不需要重新計算；

否則，遍歷tn-k+2～tn+1，

若tn+1

若tn+1>t0.5，找到比t0.5大的最小值，

記為新的t0.5；

類似地，可保留或更新t0.75的值.

在Onboard中采用了上述方案2的改進版，k=51，實現缺陷生存期的2級預警.

5.3 缺陷責任人推薦

一個缺陷生存期的長短取決于能否及時地將缺陷分配給一名合適的開發者.若將缺陷分配給了不合適的開發者，比如該名開發者不具備相關能力或沒有空余時間，則會延長缺陷的存在時間.傳統的缺陷跟蹤系統中，缺陷的責任人大多都是人工分配的.人工缺陷責任人分配是一項耗時耗力且瑣碎的工作，因而利用計算機進行缺陷責任人的自動分配成為了一個有意義的研究課題.

隨著SVN，Git等源代碼管理軟件的流行，建立缺陷和源代碼之間的聯系變得可行.如果說缺陷報告描述了一個缺陷是什么，那么源代碼中則包含了缺陷在哪里發生、什么時候被引入的信息.Shokripour等人[13]就另辟蹊徑，把預測誰來修復缺陷的問題轉化為了預測缺陷和哪些源代碼文件相關的問題：首先利用一個源代碼文件中的標識名稱(如類名、函數名等)、代碼提交的注釋、代碼中的注釋以及和這個源代碼文件相關聯的歷史缺陷報告這4類信息建立源代碼文件的詞頻矩陣，當有新的缺陷產生時，通過計算相似性來預測該缺陷和哪些源代碼文件相關，最后從源代碼管理軟件中獲得最近修改這些源代碼文件的開發者，作為該缺陷責任人的推薦名單.

缺陷責任人的自動分配問題還可以被看作是推薦系統問題——從大量的開發者中推薦若干開發者作為備選名單，再進行人工分配.不少文獻中均使用了Top-K召回率作為算法的評價指標之一，即算法針對輸入的一個缺陷給出K個可能的缺陷負責人，判斷這個缺陷實際的負責人是否在這份名單里面.

綜上，解決缺陷責任人的自動分配問題大致3種思路：判斷缺陷和缺陷之間的相似性(缺陷分類)、判斷缺陷和源代碼文件的相關性、判斷缺陷和開發者的相關性.

在Onboard敏捷軟件開發協同工具中引入缺陷責任人推薦的功能，需要針對應用場景的特殊性設計一套解決方案.1)和專門的缺陷跟蹤系統軟件相比，Onboard中提供的缺陷管理模塊對缺陷報告要求的字段比較單一，只需要缺陷的描述和復現步驟;2)和大型的開源項目相比，在使用Onboard的中小型開發團隊的項目中，需要創建缺陷報告的缺陷數目往往比較有限.也就是說，從缺陷報告中提取出來的詞頻矩陣比較稀疏，用于訓練的數據量也比較有限，因而不太適宜采用缺陷分類的思路，把問題轉化為文本分類的機器學習問題.但反過來，Onboard的優勢在于其記錄了軟件開發全生命周期的數據，這些數據遠遠比缺陷數據豐富得多，解決方案應當充分利用這些數據中所包含的信息.此外，還要求解決方案中的算法能夠增量迭代，即當新創建的缺陷的責任人被分配之后，算法應當同時利用這一信息以及之前的信息，給之后發現的缺陷推薦責任人.再者，在實現5.1節“團隊成員關鍵詞詞云”這一功能時已經得到了用戶的詞頻矩陣.綜合以上幾點考慮，我們采用了判斷缺陷和開發者的相關性的思路:

從新創建的缺陷報告中提取關鍵詞的詞頻向量；

對每一個當前處于活躍狀態的團隊成員：

從用戶的詞頻矩陣中得到這些關鍵詞的TF-IDF構成用戶的關鍵詞向量，計算和缺陷關鍵詞詞頻向量的余弦相似度；

將所有成員按余弦相似度從高到底排列，

若一個成員的余弦相似度明顯高于其他成員，

則推薦該成員作為該缺陷的責任人；

若有若干成員的余弦相似度比較接近，

則根據當前任務數目的多少、當前正在修復的缺陷的數目等推薦最可能有時間修復缺陷的成員.

我們還考慮過給任務也添加推薦責任人的功能.但是Scrum流程中有每日立會，并且敏捷價值觀第1條“個體與交互勝過過程和工具”講的就是團隊成員之間應當充分交流.一個敏捷開發團隊應當是自組織的，由成員互相討論分配任務，因而從方法論的角度看，這樣一個功能是沒有價值的.

6 總結及進一步的工作

我們利用代碼提交和任務的關聯，將項目管理和源代碼管理有機整合，繼而以Scrum方法為指導，開發了支持敏捷軟件開發全生命周期管理的Onboard敏捷軟件開發協同工具.此外，我們還提出要收集軟件開發過程中每一個環節產生的大量數據，并對這些數據進行分析，提取有價值的信息，進一步促進敏捷軟件開發過程的管理，并在Onboard項目中付諸實踐.這是本文描述的工作的兩大主要貢獻.此外，我們還提出了代碼影響行數ALOC的概念來衡量團隊成員貢獻的代碼量.

本文圍繞著“如何利用軟件開發過程中產生的數據更好地支持敏捷開發過程”和“如何評估團隊成員的貢獻度”兩大課題，全面介紹了數據可視化和數據分析在Onboard中的應用——豐富的、可交互的、具有洞察性的統計圖表，覆蓋了敏捷軟件開發的各個環節；為團隊成員貢獻度評估、缺陷責任人分配等問題設計了解決方案.

我們對敏捷軟件開發過程中產生的大量數據的分析還是比較初步的，還有更多有價值的信息值得深入挖掘.此外，還有5方面的工作正在或計劃進行：

1) 遍歷并統計Git代碼倉庫不同分支的所有代碼提交的算法優化

一個分支的代碼提交構成了一棵二叉樹，對二叉樹進行遍歷是高效的，加上緩存的使用，直接遍歷Git代碼倉庫中的代碼提交的時間成本在一定統計時間范圍內是可以接受的.然而，由于要統計所有分支上的代碼提交，在使用過程中我們發現，當統計的時間區間超過半年時，數據就返回得比較慢了.一種可行的替代方案是：在每次上傳代碼提交時，將新的代碼提交的信息及統計所需要的計算結果存進SQL數據表中，以空間換時間.但實際上計算效率是否提升、能提升多少，還有待進一步實驗驗證.

2) 一個項目不同迭代之間的對比

若選取一些指標，如延誤的任務數目比例、增加的代碼行數等，繪制橫軸為時間的折線圖，展現同一項目在不同迭代間的變化趨勢，可以進一步洞察開發團隊在Scrum敏捷開發過程中是否存在問題、是否有改進的地方等.

3) 自適應的團隊成員貢獻度評估機制

我們提出的貢獻度評估模型中，各個自變量的權重是根據我們團隊的實際情況計算出來的.然而各個團隊之間是有差異的，這種差異性很可能導致我們提出的評估模型并不是通用的.能否設計一種帶反饋的評估機制，使得團隊成員貢獻度評估模型能自我調整，適應使用Onboard的各個開發團隊的實際情況.

4) 代碼質量分析的進一步整合

Onboard中整合了Sonarqueb代碼質量分析工具，為用戶展示了初步的分析結果，特別是“技術債務”的分析為代碼質量的控制提供了有力的支持.目前代碼質量分析是相對獨立的功能，如何將其整合進敏捷開發過程中，還有待進一步研究和實踐.一種思路是：從包含技術債務的文件可以找到相應的代碼提交，從而找到關聯的任務和開發者，給予提醒.

5) 開發者畫像

如第2節所述，任務和代碼之間的關聯，使得可以從任務和代碼2個維度描繪一名團隊成員.每一行代碼都可以追本溯源到一個或多個團隊成員.根據一個團隊成員所修改過的代碼文件的文件名，可以判斷出代碼的類型，進而判斷出開發者擅長的技術；根據任務完成的時長和關聯的代碼，可以判斷出開發者的效率；根據代碼質量分析的結果以及代碼是否引入了缺陷，可以判斷出開發者的水平等，這些和個人關鍵詞詞云一起，能共同刻畫出“開發者畫像”.

[1]Beck K, Grenning J, Martin R C, et al. Manifesto for agile software development[EB/OL].[2016-08-15]. http://www.agilemanifesto.org

[2]Cockburn A, Highsmith J. Agile software development: The people factor[J]. IEEE Computer, 2001, 34(11): 131-133

[3]Chen Yong. Martian agile development manual[OL]. (2012-12-25)[2016-08-15]. http://blog.csdn.net/cheny_com/article/details/6616794 (in Chinese)(陳勇. 火星人敏捷開發手冊[OL]. (2012-12-25)[2016-08-15]. http://blog.csdn.net/cheny_com/article/details/6616794)

[4]Schwaber K, Beedle M. Agile Software Development with SCRUM[M]. Upper Saddle River, NJ: Prentice Hall, 2001

[5]Pressman R S, Maxim B R. Software Engineering: A Practitioner’s Approach[M]. 8th ed. Beijing: China Machine Press, 2015: 79

[6]Li Zhihua. Lean Software Development: Understanding Kanban Method[M]. 1st ed. Beijing: Tsinghua University Press, 2016 (in Chinese)(李智樺. 精益開發與看板方法[M]. 1版. 北京: 清華大學出版社, 2016)

[7]Cockburn A. What the agile toolbox contains[EB/OL].[2016-08-15]. http://alistair.cockburn.us/What%20the%20agile%20toolbox%20contains

[8]Tower. Feature log of Tower[EB/OL].[2016-08-15]. https://tower.im/roadmap (in Chinese)(Tower. Tower功能日志[EB/OL].[2016-08-15]. https://tower.im/roadmap)

[9]Feinberg J. Beautiful Visualization[M]. San Francisco, CA: O’Reilly Media, 2010: 37-41

[11]Ahsan S N, Ferzund J, Wotawa F. Automatic software bug triage system (BTS) based on latent semantic indexing and support vector machine[C] //Proc of IEEE ICSEA’09. Piscataway, NJ: IEEE, 2009: 216-221

[12]Xuan Jifeng, Jiang He, Hu Yan, et al. Towards effective bug triage with software data reduction techniques[J]. IEEE Trans on Knowledge and Data Engineering, 2015, 27(1): 264-280

[13]Shokripour R, Anvik J, Kasirun Z M. Why so complicated? Simple term filtering and weighting for location-based bug report assignment recommendation[C] //Proc of the 10th IEEE Working Conf on Mining Software Repositories. Piscataway, NJ: IEEE, 2013: 2-11

Chen Long, born in 1988. Currently PhD candidate in the School of Software & Microelectronics, Peking University. Student member of China Computer Federation. His main research interests include software engineering and machine learning.

Ye Wei, born in 1985. Received his PhD degree from School of Electronics Engineering and Computer Science, Peking University. Currently associate research fellow in National Engineering Research Center for Software Engineering, Peking University. His main research interests include Web-based software engineering, software architecture and application integration.

Zhang Shikun, born in 1969. Received his PhD degree from Department of Computer Science and Technology, Peking University. Professor and PhD supervisor in National Engineering Research Center for Software Engineering, Peking University. His main research interests include software engineering and cyber security.

附錄A

Scrum團隊中的主要角色包括：

Scrum Master——Scrum教練和團隊負責人，確保團隊合理地運作Scrum并幫助團隊移除實施中的障礙；

Product Owner——產品負責人，確定產品的方向和愿景，定義產品發布的內容、優先級及交付時間；

Team——開發團隊，通常為3～9人的小型團隊，團隊擁有交付可用軟件需要的各種技能.

Scrum團隊以短小的迭代(sprint)為單位進行工作，一個典型的Scrum迭代通常持續2～4周.

在日常工作時，產品負責人須維護一個按優先級排序的“產品需求列表”(product backlog)，即從客戶價值理解和描述中凝練成的產品功能條目.在每次迭代開始之前，產品負責人組織召開迭代計劃會(sprint planning meeting)，從優先級最高的需求進行講解，團隊成員就需求細節、完成標準等展開討論，并估算工時，直至該迭代期間內團隊工作量飽和，從而形成迭代需求列表(sprint backlog).一旦迭代開始，原則上迭代需求列表不再發生大的變化，可以使團隊能在短期內相對穩定地、高效地開展工作.然后，要把本次迭代的需求細分為以小時為單位的任務，在迭代期內，團隊成員將自主決定任務分配等，逐一完成任務.每天由團隊負責人組織進行一個簡短的站立會議(daily stand-up meeting)，一般不超過15 min，團隊成員相互溝通，主要回答3個問題——自上次站立會議以來完成了什么任務、遇到了什么困難、下一次站立會議之前計劃完成什么任務——以便更早地發現潛在的問題，促進團隊自我組織協調.

團隊以故事板(也稱作看板)的形式展示團隊的進度，比如將看板劃分為“未開始”、“開發中”和“待審核”3個并排的欄目，計劃會結束后所有任務都排列在“未開始”一欄下.隨著迭代的進行，一項任務處于哪種狀態，就將任務移動到相應的欄目下.關于看板的一條簡單規則，就是處于“開發中”的任務永遠不要太多，避免在迭代結束時出現大量“半成品”.團隊還維護一張“燃燒圖”(burn down chart)，即所有任務的累積剩余時間隨開發進程與日遞減的圖形，以觀察和預測所有任務是否會按期完成.如果有緊急的缺陷(bug)被發現，可以作為任務臨時添加進迭代.

在每個迭代的最后一天，團隊召開評審會(review meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，產品負責人做出判斷并給出改進意見.當天還會召開反思會(retros-pective meeting)，總結本次迭代中的不足之處，并在之后的迭代中加以改進.

Scrum整個流程如圖A1所示：

Onboard: A Data-Driven Agile Software Development Collaboration Tool

Chen Long, Ye Wei, and Zhang Shikun

(National Engineering Research Center for Software Engineering (Peking University), Beijing 100871)

Scrum is an agile software development process with a balance between schedule and flexibility, which empowers software development teams with the ability to work efficiently and respond to changes quickly at the same time. Each step in the software development process can generate tons of data, which can further facilitate team and project management and improve development efficiency if these data are captured, analyzed, displayed and fed back. However, these data are commonly scattered and under-utilized because project management and source code management are separated in existing software development management toolbox. To promote data-driven agile software development process with Scrum at its core, we create Onboard, an agile software development collaboration tool based on cloud service, which, by associating Git commits with tasks, creatively incorporates agile process management, source code management and project management into one integrated service for software development teams. Onboard supports end-to-end management of the whole software life cycle, thus it can collect all the data generated throughout the development process and extract valuable information. This paper first introduces the design principle and structure of Onboard, and then gives a comprehensive survey of data visualization and analysis applied in Onboard. In the survey, we propose solutions to a series of related problems on two topics: how to fully utilize the data generated to improve agile development process and how to evaluate the contribution of a team member. In the final analysis, the paper provides topics that need further research.

data-driven; agile software development; Scrum; software life cycle; data visualization; associating commit with task; contribution evaluation; affected lines of code (ALOC)

Fig. A1 Demonstration of Scrum software development process.圖A1 Scrum軟件開發流程示例

2016-08-16；

2016-10-24

葉蔚(wye@pku.edu.cn)

TP311.5