「觀隅」在Beta階段整體上仍采用子產品式開發，即由每位團隊成員分别負責不同的子產品，分工簡介如下，詳細任務完成情況請參見後文的 工作量 一節。
成員
分工
子產品
備注
LYL
前端
首頁子產品
負責首頁的設計與實作
DSY
背景管理子產品
負責管理頁面的設計與實作，負責調通管理接口
LXY
登入子產品
負責登入頁面的設計與實作，負責調通登入接口
WPB
後端
解析引擎
文本和音頻資料集可視化子產品
使用者子產品
負責文本和音頻類型資料集的解析以及對應的前端展示頁面的實作
負責實作使用者系統以及相關接口
YZM
圖檔資料集的可視化子產品
負責增加圖檔資料集的數量
GTC
PM
負責與資料庫相關的各管理接口的實作
MR
部分其他子產品
參與單元測試的編寫
注：單元測試由後端成員同步完成。
進度管理
在Beta的計劃階段中，我們建立了數個 Milestone 和數十個對應的 Issue 對全部任務進行了分解，并為不同的 Milestone 設定了不同的 deadline ，以期對任務量進行合理的量化。在開發過程中，我們以燃盡圖的形式對現有進度進行實時跟蹤，并以此為基礎動态調整下一階段的開發速率，或是對部分功能進行一定的取舍。整體而言，Beta全過程的進度是有序而健康的。
圖1 Beta版本的各個Milestone
圖2 Beta版本開發和測試全過程的燃盡圖
分支管理
我們建立了完善的複審和 merge 機制，即每位開發人員在自己的 dev 分支上編寫和測試自己子產品的代碼，并在适當的時機送出 Merge Request，其通過CI的檢查并由前端或後端的另外一名開發人員亦或是WPB複審後方可并入 develop 分支。這樣的工作流程和複審機制在很大程度上保障了代碼品質，也保證了當問題出現時能夠及時找到對應的負責人進行修複。
「觀隅」的典型使用者為剛入門機器學習的高校學生、模型設計與模型優化等相關從業者、深度學習相關研究者、深度學習方面課程教師四大類，下面我們分類介紹「觀隅」如何滿足其相應的典型場景。
典型使用者一：剛入門機器學習的高校學生
典型場景：A同學在大二選修了一門叫“計算機導論”的課程，其大作業要求在某一經典資料集上實作某神經網絡模型的訓練，然而A同學不太了解所下發的資料集中的标注資訊的含義，于是他首先在「觀隅」的網頁端中搜尋公開資料集，無果後通過 pip 安裝并部署了「觀隅」的本地版本，根據”幫助“的引導正确導入了所下發的已完成标注的資料集，借助于「觀隅」所提供的的标注資訊可視化功能，A同學直覺快速地了解了标注的意義，同時還和其他同學一起檢視與讨論，對課程内容和大作業要求有了更深入的了解。此外，他還根據所下發資料集的标注類型和應用場景在「觀隅」網頁端中篩選并檢視了同一類型的其他資料集，達到觸類旁通的效果。
網頁端相關功能：資料集篩選與搜尋，資料集資訊介紹，資料集條目可視化總覽，資料集條目與标注資訊詳細可視化，資料集條目互動
本地端相關功能：幫助文檔，資料集管理，資料集條目可視化總覽，資料集條目與标注資訊詳細可視化，資料集條目互動
典型使用者二：模型設計與模型優化等相關從業者
典型場景：B工程師正在進行某一内部模型的調參工作，但目前該模型在某一資料集上表現不佳且難以找出原因。該工程師在已部署到公司内網上的「觀隅」本地端上添加了該資料集，并為數位研究人員準備了賬号，借助于「觀隅」所提供的服務，B工程師可以和其他數位研究人員一同檢視資料集中的标注情況，并對可能存在的問題和思路進行交流。同時，得益于「觀隅」完善的鑒權機制和本地部署版本的特性，他也無需對内部資料集的資料安全性有所擔憂。
本地端相關功能：幫助文檔，資料集管理，配置檔案管理，成員管理，資料集條目可視化總覽，資料集條目與标注資訊詳細可視化，資料集條目互動
典型使用者三：深度學習領域的研究者
典型場景：C研究員剛讀完頂會的最新paper，準備複現一下實驗，于是先下載下傳了資料集，在本地部署的「觀隅」上添加了該資料集并檢視了資料集中的标注情況，借助于「觀隅」提供的可視化功能，他可以很容易地擷取一些展示用圖檔，大大提高了準備組會和論文插圖的工作效率，「觀隅」使他更輕松的完成科研任務。此外，他還在「觀隅」的網頁版上篩選了其他同類資料集，開拓了思路。
典型使用者四：教授機器學習相關課程的教師
D講師本學期正在教授某機器學習方面的專業課程，他為了在課堂上展示資料集的标注工作，使用「觀隅」向同學們展示标注好的可視化資料集。借助「觀隅」提供的多種類型資料集的可視化功能和資料集條目可視化互動功能，同學們更容易地了解了資料集的标注工作，拉近了師生距離，「觀隅」使得教師們更輕松地完成了教學任務。
網頁端相關功能：資料集篩選與搜尋，資料集資訊介紹，資料集條目可視化總覽，資料集條目與标注資訊詳細可視化，資料集條目互動，資訊回報
我們的殺手級功能是：資料集可視化、資料集可視化互動、搜尋與篩選、資料集本地管理。
分别指的是對資料集的各個條目進行可視化、和在這個基礎上，可以選擇性顯示如蒙版(mask)，标簽(label)，物體(object)等标注情況的可視化結果、對資料集進行關鍵詞比對的搜尋和按标簽篩選以及依賴于本地端的資料集管理。
✔：完全實作相關功能，可以滿足使用者需求
✖：未實作相關功能，不能滿足使用者需求
⭕：部分實作相關功能，部分滿足使用者需求
功能
觀隅(Ours)
格物钛
各資料集簡介界面
資料集概述
✔
資料集條目詳細可視化
⭕（部分資料集缺少可視化）
⭕（隻對一部分做了可視化）
資料集條目互動
✖
資料集浏覽
資料集條目總覽
資料集搜尋
資料集管理
⭕
可以看出，我們相比于各資料集簡介界面，提供了聚合且豐富的可視化方案。而相比較于比較成熟的資料集可視化平台格物钛，我們做到了覆寫了常見的資料集種類，并且對于每一類資料集都存在着良好的可視化效果。并且存在差異化的資料集條目總覽功能，這是格物钛沒有的。
我們還提供了根據關鍵詞進行搜尋和按标簽進行篩選的功能，以友善使用者在多個資料集中根據需求準确查找到對應資料集。
并且我們提供更具安全性的資料集本地管理功能，可以在本地端進行私有資料集的管理和可視化，避免了不必要的學術風險和商業風險。
項目推廣
我們将開發環境伺服器的配置部署到生産環境，做針對性的配置優化，添加了首頁以促進推廣。
同時，我們還在朋友圈、QQ空間、機器學習交流群等管道分享項目引流。
幫助文檔
可以檢視快速上手以了解本地端使用方式
活躍使用者資料
2021/6/16
2021/6/17
2021/6/18
總計
日均
日通路量
37
29
43
109
36
日活躍使用者量
26
21
76
25
日下載下傳量（本地端）
13
10
14
12
使用者回報
功能回報
Bug回報
是否預期
缺少下載下傳資料集的地方
标簽欄标簽過多時會超過邊框
預料之外
原因：單元測試覆寫不夠全面
詳細的内部文檔
後端建立了資料庫設計文檔以較長的描述實體定義和實體之間的關系，有助于後端開發人員厘清概念，提高開發效率。
前端配備有詳實的開始文檔，展示了前端的基本工作流程，對前端開發人員的開發工作起到一定的指導作用。
資料集解析引擎以及配置檔案等相關内容也配備了詳細的說明文檔，有助于後端開發人員與資料集解析子產品進行對接。
使用成熟的 swagger editor 編寫接口文檔，并對各個接口和模型均進行了詳細定義，這有助于前後端成員了解接口和模型含義，提高相關對接工作效率。此外，我們還将該接口文檔部署到 develop 伺服器上，使其能夠對我們的真實後端接口發送請求，這一工作大大縮減了調通前後端接口上所花費的時間，也讓修改接口帶來的影響趨于最小，更加符合“靈活”的理念。
圖3 使用 swagger 編寫（左）和測試（右）接口
嚴謹的代碼規範
後端使用 <code>PyLint</code> 進行嚴格的代碼檢查，并規定當且僅當代碼得分達到 8 分時才能夠通過CI。在必要的時候，後端開發人員會暫停現有進度，并對一些不符合代碼規範的 warning 進行集體修複，最終 <code>PyLint</code> 分數為 \(9.97/10\) 。
圖4 PyLint報告
前端使用 <code>eslint</code> 工具對代碼規範進行檢查并在CI中進行配置，拒絕不通過檢查的代碼并入 develop 分支，在此基礎上使用prettier工具對代碼風格進行檢查，并配置相關指令進行自動修複，此外還采用husky設定GitHook，每次commit時都将觸發進行代碼格式的自動修複和Ts檢查
清晰的幫助文檔
為了幫助使用者快速上手部署和使用「觀隅」的本地端服務，我們編寫了簡約而清晰的幫助文檔和如何拓展，其中由淺及深地記錄了何如對「觀隅」本地端的基礎功能進行使用，以及如何獲得更高的可定制性。
完整的單元測試
我們使用 <code>django</code> 自帶的庫對後端代碼進行單元測試，并規定當且僅當覆寫率達到 90% 才能并入 develop 分支。在此基礎上，後端開發人員建構了完整的單元測試，整體覆寫率達到了96%。此外，「觀隅」期望在多平台都提供良好的本地服務，是以單元測試均分别在Windows和Linux下運作通過。
圖5 後端單元測試覆寫率報告
優秀的CI/CD流程
我們整體采用CI/CD加速工作流程，及時發現問題并持續內建。
後端項目采用CI/CD對每次送出進行代碼規範檢查和單元測試，及時發現基礎問題。同時檢查是否有沒送出的migration，保證部署的正常進行。在master和develop分支上的送出會，項目會在伺服器上自動建構，并推送友善部署的鏡像形式至騰訊雲鏡像服務倉庫，master分支和develop分支使用不同的鏡像。此外我們還配置了自動部署功能，develop分支的改動都會在開發伺服器上實時顯示供大家實驗，master分支的改動則釋出至生産伺服器，隻有在開發環境驗證過的内容才會移動至生産伺服器上。
前端項目也在develop和master分支上配置了類似的自動建構/部署功能。同時前端CI/CD會對文法和單元測試進行檢查并嘗試編譯，如果都沒有問題才會進入建構部署。
CI/CD的使用極大提高了項目整體的開發效率，前後端均可以在不掌握彼此部署方式的情況下完成開發和測試工作。
成員簡介
「觀隅」團隊成員簡介如下：https://www.cnblogs.com/RiddleMan/p/14655399.html
個人部落格位址：
位址
https://www.cnblogs.com/MondayCha/
https://www.cnblogs.com/miku-mylife/
https://www.cnblogs.com/lxy-oo/
https://www.cnblogs.com/VOIDMalkuth/
https://www.cnblogs.com/gottfriede/
https://www.cnblogs.com/namoe/
https://www.cnblogs.com/BUAA-City/
項目管理的改進
在Alpha階段開始之前，我們預采用了輪值PM的方式，即每周由不同的成員擔任PM，這樣能夠使得團隊所有成員都有從整體上對項目進行觀察的和具體投身開發工作的機會。但是，在具體實踐中這樣的方式出現了一些問題，造成了其效果與預期的偏離。這一偏離主要展現在，首周PM使用Swagger完成了接口API，這一工具有一定的上手難度，造成第二周開發過程中對API文檔進行修改的工作也大多是由第一周PM完成的。從結果上來看，第二周PM的工作僅是例會的組織與例會報告的編寫，而一些接口上的同步工作則由其他成員承擔，造成了PM名實不符的現狀。
在Beta階段中，我們直接指定了一名成員作為PM，負責所有的接口制定、文檔編寫、進度保證等工作，這樣的做法與Alpha階段相比無疑提高了工作效率，也在無形之中提高了最終的項目品質。
分工協作的改進
在Alpha階段中我們先後采用了任務分發制和任務池機制，并對任務分發制的不足進行了反思，肯定了任務池機制對提高項目開發效率的正面意義。是以，在Beta版本中，我們繼續使用類似的任務池機制，即每隔一個較長的時間段（例如兩到三次的例會間隔），時間段開始時團隊成員一起思考還有哪些工作尚未完成，取最近最迫切的一個大的任務闆塊進行任務細分工作，說明每一條工作要實作的東西，并放進在<code>gitlab</code>的一個文章中去（即一個任務池）。成員自己去任務池中領取相應的任務，并且标注<code>loading...</code>的字段與簽署個人名稱，表示自己會承擔這一部分的任務。将這樣的方式同整體上子產品式開發的思路相結合，有助于提高團隊成員的内部驅動力，是分工協作方面的一大改善。
溝通對接的改進
與Alpha版本類似，我們仍為前端和後端各指定一名<code>leader</code>，負責确立本部分的整體架構，是以，開發過程中前後端各自的開發人員僅和對應的<code>leader</code>進行溝通，而前後端之間的接口規範等由兩位<code>leader</code>和PM一起進行溝通，這樣的分層溝通方式提高了溝通效率，進而節省了寶貴的開發時間。此外，我們兩天一次的例會上更多采用漫談式的溝通，大家都會對下一步的目标發表自己的看法，詳情可見 謎語人隊 Scrum Meeting 部落格彙總。
項目實際進展
圖6 項目實際燃盡圖（左）和從5.31開始的燃盡圖（右）
觀察以上兩個燃盡圖，我們很容易發現以下結論：
在5.28~5.31這段時間内由于計網考試臨近，其項目進展為零，這嚴重影響了整體項目進度，即雖然後面的實際開發進度與預期進度相接近，但這段時間的零進度使得整體進度顯著落後于預期，同時也在客觀上導緻了測試和釋出階段時間上的局促。
整體而言燃盡圖表現出來的情況與我們實際的開發體驗比較相符，這說明在Alpha階段中出現的任務規劃潦草的問題在Beta階段有了很大的改善，我們充分吸取了Alpha階段中Issue粒度過大造成燃盡圖無法展現真實進度的經驗，對每一個任務都進行了更加具體的Issue分割，從結果上來看也是有益的。
各成員實際工作量與貢獻分
人員
崗位
工作量
貢獻分
完成了後端大部分的單元測試
完成了後端除可視化部分的大部分接口
完成了每周例會部落格的撰寫
51
參與了部分後端的單元測試撰寫
參與了部分後端接口的撰寫
47
引擎
完成了音頻類型資料集的解析接口
完成了統計子產品的單元測試
完成了首頁内容的編寫
代碼部分約700行
完成了Beta階段大部分部落格的撰寫
部落格部分約8000字
52
後端：對開源hugging-face工具所支援資料集的适配，CI的配置，下載下傳資料的記錄以及本地端pip包的制作
前端：添加文本和音頻類型資料集的可視化，完成資料集篩選内容，修複一些小bug後端：對開源hugging-face工具所支援資料集的适配，CI的配置，下載下傳資料的記錄以及本地端pip包的制作
前端：添加文本和音頻類型資料集的可視化，完成資料集篩選内容，修複一些小bug
53
完善前端JWT鑒權全局封裝、狀态管理等基礎元件
負責首頁子產品的設計與實作
項目整體風格統一與CSS樣式美化
49
修複畫廊欄bug
完成登入子產品
完成文本可視化子元件
完成回報頁面字數統計與警告
48
實作了管理頁面的布局設計
實作了資料集、配置檔案、人員、标簽四個部分的增添、修改、删除、檢視、排序的管理功能
增加了首頁到管理頁面的跳轉入口
50
開發前目标
總通路量達到1000人次，日通路量達到20人次，本地端下載下傳量達到30人次
預期功能
首頁
提供引導、功能入口
管理資料集
檢視，管理資料集
設定頁面
控制個性化選項
回報界面
使用者提供回報
資料集内容檢視
檢視資料集具體内容
資料集格式解析
形象解析資料集格式
釋出功能
具體描述
使用者可以在首頁畫廊中浏覽已經預支援的多種類型的多個資料集的概要資訊
使用者可以根據關鍵字查找所需的資料集
使用者可以在資料集的詳情頁中檢視資料集的概要資訊
使用者可以在資料集的詳情頁中檢視資料集條目可視化的總覽
目前共支援圖檔、文本、音頻三類資料集，應用場景包括了常見的
使用者可以顯式控制資料集條目内可視化圖層的具體顯示情況
資訊回報
使用者可以對現有功能和可能出現的Bug進行回報
資料集篩選
使用者可以根據标簽篩選所需的資料集
本地端安裝
使用者可以根據需要選擇安裝本地端
使用者可以添加、删除、修改本地端的資料集及資料集相關内容（包括标簽等），通過觀隅檢視其可視化效果
使用者管理與鑒權
添加了使用者系統，以控制使用者所擁有的權限
使用者評價