一、專案與團隊亮點

1.1 團隊成員分工簡介

​ 「觀隅」在Beta階段整體上仍採用模組式開發，即由每位團隊成員分別負責不同的模組，分工簡介如下，詳細任務完成情況請參見後文的 工作量 一節。

​ 注：單元測試由後端成員同步完成。

1.2 專案管理

• 進度管理

  ​ 在Beta的計劃階段中，我們建立了數個 Milestone 和數十個對應的 Issue 對全部任務進行了分解，併為不同的 Milestone 設定了不同的 deadline ，以期對任務量進行合理的量化。在開發過程中，我們以燃盡圖的形式對現有進度進行實時跟蹤，並以此為基礎動態調整下一階段的開發速率，或是對部分功能進行一定的取捨。整體而言，Beta全過程的進度是有序而健康的。

• 分支管理

  ​ 我們建立了完善的複審和 merge 機制，即每位開發人員在自己的 dev 分支上編寫和測試自己模組的程式碼，並在適當的時機提交 Merge Request，其通過CI的檢查並由前端或後端的另外一名開發人員亦或是WPB複審後方可併入 develop 分支。這樣的工作流程和複審機制在很大程度上保障了程式碼質量，也保證了當問題出現時能夠及時找到對應的負責人進行修復。

1.3 典型使用者場景

​ 「觀隅」的典型使用者為剛入門機器學習的高校學生、模型設計與模型優化等相關從業者、深度學習相關研究者、深度學習方面課程教師四大類，下面我們分類介紹「觀隅」如何滿足其相應的典型場景。

• 典型使用者一：剛入門機器學習的高校學生

  • 典型場景：A同學在大二選修了一門叫“計算機導論”的課程，其大作業要求在某一經典資料集上實現某神經網路模型的訓練，然而A同學不太理解所下發的資料集中的標註資訊的含義，於是他首先在「觀隅」的網頁端中搜索公開資料集，無果後通過 pip 安裝並部署了「觀隅」的本地版本，根據”幫助“的引導正確匯入了所下發的已完成標註的資料集，藉助於「觀隅」所提供的的標註資訊視覺化功能，A同學直觀快速地理解了標註的意義，同時還和其他同學一起檢視與討論，對課程內容和大作業要求有了更深入的理解。此外，他還根據所下發資料集的標註型別和應用場景在「觀隅」網頁端中篩選並查看了同一型別的其他資料集，達到觸類旁通的效果。
  • 網頁端相關功能：資料集篩選與搜尋，資料集資訊介紹，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動
  • 本地端相關功能：幫助文件，資料集管理，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動

• 典型使用者二：模型設計與模型優化等相關從業者

  • 典型場景：B工程師正在進行某一內部模型的調參工作，但目前該模型在某一資料集上表現不佳且難以找出原因。該工程師在已部署到公司內網上的「觀隅」本地端上添加了該資料集，併為數位研究人員準備了賬號，藉助於「觀隅」所提供的服務，B工程師可以和其他數位研究人員一同檢視資料集中的標註情況，並對可能存在的問題和思路進行交流。同時，得益於「觀隅」完善的鑑權機制和本地部署版本的特性，他也無需對內部資料集的資料安全性有所擔憂。
  • 本地端相關功能：幫助文件，資料集管理，配置檔案管理，成員管理，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動

• 典型使用者三：深度學習領域的研究者

  • 典型場景：C研究員剛讀完頂會的最新paper，準備復現一下實驗，於是先下載了資料集，在本地部署的「觀隅」上添加了該資料集並查看了資料集中的標註情況，藉助於「觀隅」提供的視覺化功能，他可以很容易地獲取一些展示用圖片，大大提高了準備組會和論文插圖的工作效率，「觀隅」使他更輕鬆的完成科研任務。此外，他還在「觀隅」的網頁版上篩選了其他同類資料集，開拓了思路。
  • 網頁端相關功能：資料集篩選與搜尋，資料集資訊介紹，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動

• 本地端相關功能：幫助文件，資料集管理，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動

• 典型使用者四：教授機器學習相關課程的教師

  • D講師本學期正在教授某機器學習方面的專業課程，他為了在課堂上展示資料集的標註工作，使用「觀隅」向同學們展示標註好的視覺化資料集。藉助「觀隅」提供的多種型別資料集的視覺化功能和資料集條目視覺化互動功能，同學們更容易地理解了資料集的標註工作，拉近了師生距離，「觀隅」使得教師們更輕鬆地完成了教學任務。
  • 網頁端相關功能：資料集篩選與搜尋，資料集資訊介紹，資料集條目視覺化總覽，資料集條目與標註資訊詳細視覺化，資料集條目互動，資訊反饋

1.4 特色功能

殺手級功能

我們的殺手級功能是：資料集視覺化、資料集視覺化互動、搜尋與篩選、資料集本地管理。

分別指的是對資料集的各個條目進行視覺化、和在這個基礎上，可以選擇性顯示如蒙版(mask)，標籤(label)，物體(object)等標註情況的視覺化結果、對資料集進行關鍵詞匹配的搜尋和按標籤篩選以及依賴於本地端的資料集管理。

競品比較

✔：完全實現相關功能，可以滿足使用者需求

✖：未實現相關功能，不能滿足使用者需求

⭕：部分實現相關功能，部分滿足使用者需求

可以看出，我們相比於各資料集簡介介面，提供了聚合且豐富的視覺化方案。而相比較於比較成熟的資料集視覺化平臺格物鈦，我們做到了覆蓋了常見的資料集種類，並且對於每一類資料集都存在著良好的視覺化效果。並且存在差異化的資料集條目總覽功能，這是格物鈦沒有的。

我們還提供了根據關鍵詞進行搜尋和按標籤進行篩選的功能，以方便使用者在多個數據集中根據需求準確查詢到對應資料集。

並且我們提供更具安全性的資料集本地管理功能，可以在本地端進行私有資料集的管理和視覺化，避免了不必要的學術風險和商業風險。

1.5 專案釋出

• 專案推廣

我們將開發環境伺服器的配置部署到生產環境，做針對性的配置優化，添加了首頁以促進推廣。

同時，我們還在朋友圈、QQ空間、機器學習交流群等渠道分享專案引流。

• 幫助文件

可以檢視快速上手以瞭解本地端使用方式

• 活躍使用者資料

• 使用者反饋

1.6 軟體工程質量

• 詳細的內部文件
  • 後端建立了資料庫設計文件以詳細描述實體定義和實體之間的關係，有助於後端開發人員釐清概念，提高開發效率。
  • 前端配備有詳實的開始文件，展示了前端的基本工作流程，對前端開發人員的開發工作起到一定的指導作用。
  • 資料集解析引擎以及配置檔案等相關內容也配備了詳細的說明文件，有助於後端開發人員與資料集解析模組進行對接。
  • 使用成熟的 swagger editor 編寫介面文件，並對各個介面和模型均進行了詳細定義，這有助於前後端成員理解介面和模型含義，提高相關對接工作效率。此外，我們還將該介面文件部署到 develop 伺服器上，使其能夠對我們的真實後端介面傳送請求，這一工作大大縮減了調通前後端介面上所花費的時間，也讓修改介面帶來的影響趨於最小，更加符合“敏捷”的理念。

• 嚴謹的程式碼規範

  • 後端使用 PyLint 進行嚴格的程式碼檢查，並規定當且僅當代碼得分達到 8 分時才能夠通過CI。在必要的時候，後端開發人員會暫停現有進度，並對一些不符合程式碼規範的 warning 進行集體修復，最終 PyLint 分數為 \(9.97/10\) 。

• 前端使用 eslint 工具對程式碼規範進行檢查並在CI中進行配置，拒絕不通過檢查的程式碼併入 develop 分支，在此基礎上使用prettier工具對程式碼風格進行檢查，並配置相關命令進行自動修復，此外還採用husky設定GitHook，每次commit時都將觸發進行程式碼格式的自動修復和Ts檢查

• 清晰的幫助文件

  ​ 為了幫助使用者快速上手部署和使用「觀隅」的本地端服務，我們編寫了簡約而清晰的幫助文件和如何拓展，其中由淺及深地記錄了何如對「觀隅」本地端的基礎功能進行使用，以及如何獲得更高的可定製性。

• 完整的單元測試

  ​ 我們使用 django 自帶的庫對後端程式碼進行單元測試，並規定當且僅當覆蓋率達到 90% 才能併入 develop 分支。在此基礎上，後端開發人員構建了完整的單元測試，整體覆蓋率達到了96%。此外，「觀隅」期望在多平臺都提供良好的本地服務，因此單元測試均分別在Windows和Linux下執行通過。

• 優秀的CI/CD流程

  ​ 我們整體採用CI/CD加速工作流程，及時發現問題並持續整合。

  ​ 後端專案採用CI/CD對每次提交進行程式碼規範檢查和單元測試，及時發現基礎問題。同時檢查是否有沒提交的migration，保證部署的正常進行。在master和develop分支上的提交會，專案會在伺服器上自動構建，並推送方便部署的映象形式至騰訊雲映象服務倉庫，master分支和develop分支使用不同的映象。此外我們還配置了自動部署功能，develop分支的改動都會在開發伺服器上實時顯示供大家實驗，master分支的改動則釋出至生產伺服器，只有在開發環境驗證過的內容才會移動至生產伺服器上。

  ​ 前端專案也在develop和master分支上配置了類似的自動構建/部署功能。同時前端CI/CD會對語法和單元測試進行檢查並嘗試編譯，如果都沒有問題才會進入構建部署。

  ​ CI/CD的使用極大提高了專案整體的開發效率，前後端均可以在不掌握彼此部署方式的情況下完成開發和測試工作。

二、專案與團隊總結

2.1 專案管理

• 成員簡介
  • 「觀隅」團隊成員簡介如下：https://www.cnblogs.com/RiddleMan/p/14655399.html
  • 個人部落格地址：

• 專案管理的改進

  ​ 在Alpha階段開始之前，我們預採用了輪值PM的方式，即每週由不同的成員擔任PM，這樣能夠使得團隊所有成員都有從整體上對專案進行觀察的和具體投身開發工作的機會。但是，在具體實踐中這樣的方式出現了一些問題，造成了其效果與預期的偏離。這一偏離主要體現在，首周PM使用Swagger完成了介面API，這一工具有一定的上手難度，造成第二週開發過程中對API文件進行修改的工作也大多是由第一週PM完成的。從結果上來看，第二週PM的工作僅是例會的組織與例會報告的編寫，而一些介面上的同步工作則由其他成員承擔，造成了PM名實不符的現狀。

  ​ 在Beta階段中，我們直接指定了一名成員作為PM，負責所有的介面制定、文件編寫、進度保證等工作，這樣的做法與Alpha階段相比無疑提高了工作效率，也在無形之中提高了最終的專案質量。

• 分工協作的改進

  ​ 在Alpha階段中我們先後採用了任務分發制和任務池機制，並對任務分發制的不足進行了反思，肯定了任務池機制對提高專案開發效率的正面意義。因此，在Beta版本中，我們繼續使用類似的任務池機制，即每隔一個較長的時間段（例如兩到三次的例會間隔），時間段開始時團隊成員一起思考還有哪些工作尚未完成，取最近最迫切的一個大的任務板塊進行任務細分工作，說明每一條工作要實現的東西，並放進在gitlab的一個帖子中去（即一個任務池）。成員自己去任務池中領取相應的任務，並且標註loading...的欄位與簽署個人名稱，表示自己會承擔這一部分的任務。將這樣的方式同整體上模組式開發的思路相結合，有助於提高團隊成員的內部驅動力，是分工協作方面的一大改善。

• 溝通對接的改進

  ​ 與Alpha版本類似，我們仍為前端和後端各指定一名leader，負責確立本部分的整體框架，因此，開發過程中前後端各自的開發人員僅和對應的leader進行溝通，而前後端之間的介面規範等由兩位leader和PM一起進行溝通，這樣的分層溝通方式提高了溝通效率，從而節省了寶貴的開發時間。此外，我們兩天一次的例會上更多采用漫談式的溝通，大家都會對下一步的目標發表自己的看法，詳情可見 謎語人隊 Scrum Meeting 部落格彙總。

• 專案實際進展

​ 觀察以上兩個燃盡圖，我們很容易發現以下結論：

1. 在5.28~5.31這段時間內由於計網考試臨近，其專案進展為零，這嚴重影響了整體專案進度，即雖然後面的實際開發進度與預期進度相接近，但這段時間的零進度使得整體進度顯著落後於預期，同時也在客觀上導致了測試和釋出階段時間上的侷促。
2. 整體而言燃盡圖表現出來的情況與我們實際的開發體驗比較相符，這說明在Alpha階段中出現的任務規劃潦草的問題在Beta階段有了很大的改善，我們充分吸取了Alpha階段中Issue粒度過大造成燃盡圖無法體現真實進度的經驗，對每一個任務都進行了更加具體的Issue分割，從結果上來看也是有益的。

• 各成員實際工作量與貢獻分

2.2 使用者場景

• 開發前目標

總訪問量達到1000人次，日訪問量達到20人次，本地端下載量達到30人次

• 預期功能

• 釋出功能

• 使用者評價