NameNotFound 團隊
項目
内容
北航-2020-軟體工程（春季學期）
班級部落格
要求
Beta事後分析
課程目标
通過團隊合作完成一個軟體項目的開發
會議截圖
我們的軟體要解決的是兩個問題：
表單資料的生成
在各類表單識别和OCR服務的機器學習模型中，訓練資料占據很重要的地位。而真實表單中資料往往涉及使用者隐私，不能直接使用，是以需要花費大量的資金和人力僞造一些與真實表單各個字段值相近的“虛假”表單作為訓練資料。我們希望能夠設計一個表單資料自動化生成工具，它能根據使用者提供的空白表單和表單中各個字段的生成要求，自動随機生成多個滿足使用者要求的标注好的高品質表單，作為訓練資料以供各個表單識别項目開發者使用，進而節省花費在訓練資料上的人力物力。
自動化處理大量表單
微軟原項目Fott項目使用認知服務來識别表單。我們基于Alpha階段的資料生成，進一步把模型訓練和使用結合起來，使整個軟體有一個完整的流程，即：上傳->标注->資料生成->模型訓練->表單處理。
基于以上的流程，我們的軟體支援使用者批量處理同類表單，解決手工處理的麻煩。同時，為了友善使用者使用處理結果，我們對處理結果進行了整理，支援結果導出為Excel檔案，并且設計了可視化展示的接口，友善使用者直覺的觀察資料。
關于典型使用者和典型場景的描述見Beta項目展示
原計劃的功能如下：
功能
較長的描述
introduction頁面
增加項目描述和使用方法
train頁面
支援對生成好的頁面進行一鍵訓練；支援将訓練得到的結果進行處理，生成Excel檔案
data頁面
支援資料可視化檢視
tag頁面
支援錯誤畫出的框的删除
model頁面
支援曆史模型的顯示
new project
支援使用者選擇項目類型（空白訓練；五張訓練；根據Excel資訊批量生成表單等）
原計劃的功能除了model頁面沒有實作，其他的功能均已實作。model頁面是因為我們發現這一功能沒有需求，是以放棄了這一功能。
我們按照計劃傳遞了軟體，并且進行了穩步的測試。
原計劃的使用者數量并沒有達到，可能是以下幾個原因：
我們的軟體對于大家來說需求不是很明顯，是以可能大家嘗試的意願不高
考慮到臨近烤漆，大家都在複習，我們的軟體對于複習沒有幫助，是以不使用很正常
軟體本身還是不夠吸引人
和上一個階段相比，我們認為團隊的軟體工程品質有所提高。
項目的計劃：我們在Beta階段進行了更詳細的規劃，沖刺的任務也提前明确
項目管理：将issue和commit關聯起來，PM進行代碼複審
成員任務分工：前後端分離，每日例會更新明天的任務
文檔管理：将說明文檔和技術文檔都維護在GitHub的wiki頁面
整個流程下來，我們的開發速度相比Alpha階段有了很的提升，這一點在Beta階段的燃盡圖可以展現
燃盡圖
Beta——事後分析
從使用者的回報來看，使用者對于功能的整體還是比較滿意，主要的問題可能是軟體的使用速度存在一定的問題。這一點在項目展示進行了解釋。
如果重來，我們會選擇自己建構後端伺服器，而不是使用Azure的服務。因為Azure的服務在中國還是有一定的延遲。
我們在Beta階段是有比較充足的時間進行計劃，包括功能以及項目管理等，也正是因為計劃較為完善，是以開發速度有了很大的提升。
我們會就目前的技術和資源來衡量不同的意見，如果資源和技術可以滿足，且時間允許，那麼我們會投票接受意見。
如果是成員之間的意見不同，我們也是綜合所有人的意見來衡量是否采納。
原計劃的工作基本都做完了，有一項 <code>model頁面</code> 的計劃并沒有實作，這個是因為我們在開發階段發現這一功能不視用于需求的，沒有特别大的意義，是以沒有實作。
這個暫時沒有，因為我們會在每日例會進行靈活的調整，沒有做可能沒有價值的任務。
是的，我們把所有的issue和commit都聯合起來，在每日例會也較長的描述了每個人每天的工作。
整個過程基本都是按照計劃來的，期間遇到過伺服器無法正常使用，這個是因為微軟的Azure服務存在一些小問題，是一開始沒有預估到的。因為Alpha階段沒有遇到類似的問題，是以沒有預估到這一問題。
計劃中有留有一定的緩沖區。緩沖區是為了防止因為各種問題導緻的項目進度推遲，實際的項目過程，緩沖區還是起到了一定的作用，我們本來計劃的開發完成時間是早于沖刺結束時間的，結果是正好完成。這期間是伺服器和技術都遇到了一些小問題。
緩沖區确實應該在計劃中考慮，以防出現意外情況導緻項目進度被擱置；
如果按照目前計劃無法在時間點完成，那麼加班是有必要的。
我們會在計劃階段進一步明确每個人的分工，并且讓大家明白彼此工作之間的聯系，結合結對開發的模式，兩兩組隊開發。出現問題，PM盡快調控解決。
資源方面，我們的伺服器是zyc同學提供的，基本可以滿足我們的項目需求；唯一的問題是賬号資源，因為微軟的Azure服務需要使用Visa卡才可以新增賬號使用，我們隻有一個賬号，是以很多的功能其實都是進行了修改才能夠讓更多的人使用，尤其是認知服務的免費版本有次數限制，導緻我們無法進行大規模的測試。
任務的時間基本上是按照每個任務1-2天，然後在每日例會上進行調整；
除了幾個維護的任務，開發任務基本上是在估計時間内的，還是比較準确。
測試的時間較為充足，因為我們按照預期完成了開發。
人力資源和硬體資源足夠。
一定程度上低估了難度，尤其是文檔和部落格等，需要描述的很多，耗費的時間很大。
Beta階段我是轉為了PM，整個流程下來，感覺PM首先要對項目有一個整體的了解，以及明确項目的方向，合理的分工，推進項目進度。這一工作，其他成員應該也可以勝任，隻是需要花費一些時間熟悉。
可能我們會選擇采用自己搭建伺服器的方式來建構前後端，這樣消耗的資源也差不多，但是軟體的整體性會更好，性能會有很大的改善。
我們會在交流群及時通知各種消息，然後GitHub上也會對push等由郵件提醒。
民主集中制？😜
就是大家開會讨論某些功能是可以推遲的，某些功能是必須的，不能推遲。
這個我們在計劃階段就大概有個明确，是以實作的過程中很輕松的可以選擇。
由以下三部分組成：
Beta階段新功能實作
表單識别模型的訓練
自動化訓練模型
表單預測
表單預測結果自動化處理
資料結果可視化展示
Alpha階段功能完善
标注頁面資料同步問題
Introduction頁面
回歸測試+測試矩陣
我們認為是可以制定計劃的，從我們Beta階段的開發來看，中間是有進行過調整，修改計劃。
一個團隊的開發總是會遇到這種緊急情況，是以緩沖區是很有必要的。
經過Beta階段的開發，我們有資訊确認可以處理意料之外的工作請求。
這方面可能暫時沒有改進的地方。
設計工作是在每個階段的開始一周。
由全部成員一起商讨，并且聽取了zx老師的意見。
是合适的時間，而且借鑒了zx老師的意見，大家共同決定的軟體方向，是合适的。
有的，在解決自動識别的問題上，一開始遇到了很大的問題，不知道如何處理，甚至一度停滞，後來是我們連着兩天開會，讨論這個問題，商讨了一個初步的解決方案，最後不斷完善。
後端的開發時基于TDD進行的，采用Postman來進行測試，促進開發。TDD的開發很有效，個人感覺在一定程度上保證了代碼邏輯的正确性以及快速開發。
前端進行單元測試。保證了函數的基本功能正确性。
UML圖在Beta階段的開發過程中逐漸更新，最終确定為如下：
前端的tag頁面，因為這一塊涉及到資料同步，我們一開始沒有重視這個問題，導緻出現了很多的BUG。
釋出後沒有遇到重大的BUG。
前端是成員之間互相審查，之後合并分支，後端是PM審查，整理到代碼中。這裡并沒有使用GitHub的pr，需要改進。
我們嚴格遵守了代碼規範，前端遵守tslint，後端遵守pylint。
我們會用GitHub的PR來進一步管理項目。
有的，在開發階段，沒開發一個功能，都會去進行測試，完全開發完成後進行了驗收測試。
有的，場景測試+回歸測試+單元測試
見測試報告
前端：一套自動化測試架構，支援TypeScript，React，可以生成覆寫率報告。
後端：Postman，TDD開發，支援自動化測試。
因為适用了Azure服務，微軟的Azure面闆提供了函數的檢測，資源的使用情況，以及運作回報，這樣我們就可以監測軟體的運作效能。
我們在釋出前有進行壓力測試，但是因為認知服務的資源問題，壓力測試不算是很強力。
從實際的表現來看，我們也是發現了以下問題，比如tag頁面的同步問題，以及建立項目時可能會出錯。
改進的話，壓力測試應該更強一點（資源允許的話）。
釋出後，伺服器出現了不能使用的情況，是因為Azure服務發生了意外，不過這一問題很快解決了。
重視單元測試，回歸測試。整體的測試也是必不可少的。壓力測試對于軟體實際運作的效果很重要。
Beta階段的定位基本上維持了Alpha階段的分工，新成員頂替轉會的成員的工作，負責前端的開發。目前來看應該算是人盡其才。
有的，我在開發後端的伺服器時，遇到了臨時檔案通路的問題，研究了很久沒有解決，後來經過大佬的指導成功解決了此問題。
我們會商讨這一任務是誰負責的，然後看能否解決，如果不能就讓其他成員提供幫助，盡快解決。
成員
被感謝者
事情
ly
其他成員
感謝zyc幫助我解決記憶體通路的問題；感謝其他成員的辛苦付出！
zyc
ly，其他成員
感謝PM ly辛苦的推進項目，感謝所有成員的合作
lzh
ly，zyc
重點感謝pm小哥ly，他為項目整體設計規劃和文檔鞠躬盡瘁；以及前端夥伴zyc
dxy
感謝ly的幫助，和我讨論拼接字元的處理問題；感謝zyc的幫助，提供伺服器
wyk
作為前PM感謝大家的辛苦付出！
llj
感謝PM高效推進前後端對接，感謝大家的努力，有幸和大家一起見證了這個項目的成長👍
我們目前應該是屬于可重複級向已定義級過渡的階段。
我們目前處于規範的階段，成員之間磨合的應該算是可以，主要是處于規範階段。
團隊磨合：磨合得更好，整個團隊的開發速度有了進一步的提升
項目管理：項目管理更加規範
交流溝通：成員之間交流更加頻繁，互相之間能夠了解
應該是軟體的代碼管理方面，大家還是有些不适應使用GitHub，比如說Pull&Request的使用、commit的規範等等。
我們在Beta階段的目的就是把軟體的完整性實作，成為一個可用的表單識别功能，而不僅僅是資料生成。
我們在開發的過程發現model頁面并沒有想象的那麼有用，是以選擇暫時簡化，等之後再說。
我們在考慮如何實作自動處理時，選擇先實作一個簡化的版本，再根據需求逐漸更疊優化。
我們會在每日例會上反思最近的不足，在後續的工作中改進。一開始有成員在GitHub規範上出現了問題，後續進一步加強了規範的遵守。
利用GitHub來進行代碼管理。準備合理利用pull&request機制來進行代碼複審，代碼規範方面繼續遵守之前的約定，同時寫好文檔和注釋。
前端可以把沒有使用到的架構删除，後端遷移到自己的伺服器上建構。
通過測試軟體的使用速度以及流暢性來衡量性能的提高。
考慮到後續可能要把後端移植到伺服器上，需要使用一些自動化測試用的軟體。
項目管理，我們考慮是否可以采用輪換的PM，來讓大家都對項目有一個深刻的了解。
使用者資料方面，我們可以通過後端的控制台得知使用者的資料以及每日/每周活躍使用者。
這方面暫時的想法是開放一個回報通道，收集使用者的意見來進行調整。
直接利用使用者的資料可能無法得到有效的資訊。
考慮使用自動化文檔工具，規範代碼書寫，自動生成API文檔。
軟體的使用文檔也需要進一步更新，争取做到簡潔明了。
作為PM，我發現在最後整理的時候，績效的考核有時很難量化，這一點在算團隊成員貢獻分的時候遇到了，可以進一步改進的點是可以把工作進一步的記錄明确（可以使用任務管理工具并且與GitHub的issue同步），并且成員之間協定好不同任務的分數比重，最終計算的時候直接通過公式進行計算。
理論方面看書的時候總是以為看懂了，但在開發過程中感覺很多地方還是做的不到位，回過頭看，才能明白一些。比如說，我們在推廣的是時候發現使用者群體有一些不太适配學生，導緻較難推廣，這一點在計劃階段應該更認真的考慮，以及進行一些修正，可能就會好一些。