7組-Alpha衝刺-總結
一、基本情況
1.1 組長部落格連結：
1.2 現場答辯總結：
- PPT行間距存在問題
- 利用規則、規律提高“自習室場景”的識別準確性；
- 考慮座位識別區域的位置偏移，嘗試使用IOU進行自適應；
- 前端不夠優美，繼續優化美化；
- 後端由於伺服器選擇，存在穩定性問題，後續解決；
- 長期完善的角度看，需要提高小人頭的識別率，考慮小人頭演算法，使用小人頭資料集；
1.3 全組討論的照片：
1.4 貢獻比例
前端工作流程：
後端工作流程：
分工比例
二、總結思考
2.1 設想和目標（4分）
2.1.1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？
- 解決什麼問題：
- 解決高校圖書館學生佔座現象頻繁出現而管理員管理繁瑣、不規範、不及時、少證據、多勞動、難服眾的問題
2.1.2 我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃：
- 實現五個頁面，分別是：
- 賬號密碼登陸頁面；
- 首頁違規行為展示頁面；
- 違規行為查詢頁面；
- 人流量統計頁面；
- 設定頁面；
- 基本功能：
- 對於長時間（2h以上）在預約系統中處於“使用中”狀態但是空置的座位進行證據（圖片）記錄、向管理員提示、統計記錄（以日、周為單位）
實際完成：
- 頁面全部完成，基本功能實現。按時交付。無使用者數量需求。
2.1.3 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
- 使用者對專案的成果基本接受，並表示“人流量統計功能”，“空置座位設定功能”是他意料之外的功能，原來他以為只有“違規行為提示功能”。
- 我們離“一個完整完善的自習室智慧管理系統”這一目標更進一步了。
2.1.4 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
- 功能雖然出乎使用者意料，但是從開發者的角度看感覺功能有點少。
- 如果歷史重來一遍，考慮在完成首要功能後，再增加一些圍繞自習室這一場景的管理功能。
2.2 計劃（5分）
2.2.1 是否有充足的時間來做計劃?
- 計劃時間充足，並且儘量做到充分討論、考慮周全
。
2.2.2 團隊在計劃階段是如何解決組員對於計劃的不同意見的？
- 公開討論->頭腦風暴->各提意見->投票表決
- 投票中，將要負責相應部分的同學有更高的投票權重
2.2.3 原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 原計劃的工作最後都完成了。
2.2.4 有沒有發現做了一些之後看來沒必要或沒多大價值的事?
- 每個人都要寫的部落格內容其實不用都單獨發給負責部落格的人，直接使用騰訊文件多人線上編輯就行
2.2.5 是否每一項任務都有清楚定義和衡量的交付件?
2.2.6 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 專案整個過程基本按照計劃進行
- 後端和演算法方面在α5就提前完成了
- 前端在α6也完成了相應任務
2.2.7 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
- 留下了兩天的緩衝區
- 演算法和後端方面的工作在緩衝區之前就基本完成了
- 前端在緩衝區中繼續完成了前後端互動的工作。
2.2.8 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
- 本次衝刺中專案整體上在緩衝區前基本完成
- 因此將來的計劃中緩衝區大致仍然設定為兩天
- 並且儘量在專案中期完成大部分內容，避免趕DDL和加班
- 此外考慮額外設定一段時間用於測試專案
2.2.9 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
- 技術上，每個隊友都一定程度上學到了所負責方面所需的知識內容；
- 經驗上，磨合了團隊，使得隊友在團隊合作上有了進一步的經驗，並且對計劃、交接、維護流程有了更深刻的印象與體會；
- 會做什麼改進：增設測試、完善、拓展功能的計劃
2.3 資源（3分）
2.3.1 我們有足夠的資源來完成各項任務麼?
- 除了目標檢測模型的訓練需要的資源比較多（在雲伺服器上訓練非常花錢，後來選擇了使用本地GPU訓練）
- 專案其它部分所需資源相較而言都不算多，能夠滿足。
2.3.2 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 任務所需的時間和資源是交給每個方面（兩個人）中較有經驗的一個人通過列出：
- 任務具體內容
- 單個任務佔方面總任務的百分比
- 任務所需關鍵資源
- 任務難度/耗時估計
等資訊來估計的。- 後面每次開會確定接下來一輪的衝刺時，這一系列資訊起到關鍵作用。
- 精度方面，存在兩項任務（總共有十九項）沒有太大意義，其他任務的難度估計沒有太大偏差，基本在原估計難度的約0.7~1.3倍之間。
2.3.3 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 專案在計劃的時候有準備測試時間，但是實際執行中測試做得比較簡單倉促。
- 人力資源基本足夠，大部分人能在緩衝區前完成任務。
- 此外由於存在訓練模型的需求，所以硬體資源（說算力資源可能更準確一點）比較吃緊。
- PPT、企劃書、介紹視訊的難度存在一定的低估，但在加班後基本都較好地完成了。
2.3.4 你有沒有感到你做的事情可以讓別人來做（更有效率）?
- 沒有明顯感覺
- 重要的不是“讓別人來做更高效”，而是搞清楚“為什麼別人能那麼高效”，並虛心學習。
- 這個問題的進一步討論可以在2.7.1看到
2.3.5 有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
- 算力資源準備不充足，歷史重來考慮提前收集（白嫖）一些雲伺服器的代金券，用於後續訓練模型。
2.4 變更管理（4分）
2.4.1 每個相關的員工都及時知道了變更的訊息?
- 起初部分隊友訊息的接收存在一定的落後
- 後來經過提醒“多關注變更訊息”後，變更基本能及時讓相關隊友知道。
2.4.2 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
- 根據使用者的需求緊急度、功能必要性來決定功能實現的先後；
- 當前佔座矛盾較為突出，因此優先實現“佔座檢測”；
- 當前疫情防控狀態較好，因此可以稍微推遲“違規使用座位”的檢測。
2.4.3 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 出口條件：可以穩定執行（檢測），誤報率在10%以下，能夠抗基本干擾（戴帽子、趴在桌子上等）。
2.4.4 對於可能的變更是否能制定應急計劃?
- 首先儘量避免突然的大規模的變更
- 如果出現了就只能加班加點完成了。
2.4.5 組員是否能夠有效地處理意料之外的工作請求？
- 由於一開始的計劃和工作分配相對完備，沒有太多意料之外的工作請求。
- 有一兩次突發的工作請求也都被有效處理了。
2.4.6 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
- 在本次衝刺中，對突發變更的預案准備較少。
- 重來一遍的話會計劃留出更多的應急空間、應急工作分配方案，避免因為突然分配意料之外的工作而過度加班的情況。
2.5 設計/實現（4分）
2.5.1 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
- 設計工作在學期第八週、第九周由潘偉君、林經緯完成。
- 時間和選人相對合適。
2.5.2 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
- 首先隊長在選題分析、需求分析時就應當構建比較完整的專案流程和需求預期。
- 對於存在一部分模稜兩可的情況，首先由隊長和利益相關人員確認沒有利益衝突/損失；
- 然後由隊長和相應工作負責人共同決定具體方案：
- 隊長主要負責確定設計不會偏離使用者預期並且在專案整體開展上具有可行性
- 相應工作負責人主要負責確定在技術上設計的可行性
2.5.3 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
- 團隊主要使用UML來協助設計和實現
- 這些工具在一定程度上理清了專案的流程、隊友的實現思路，指導了專案的完成。
2.5.4 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
- 專案開始的UML和現在的狀態存在一定的偏差
- 偏差來源主要是使用的技術方法不同：
- 因為一開始製作UML時還沒有具體深入實現過程，但在實際實現過程中往往發現了更加便捷、合適的技術方法，隨之實現方法或邏輯結構也產生變化。
- UML文件計劃更新。
2.5.5 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
- 產生BUG最多的地方是在演算法方面的人頭檢測部分
- 這也是專案的重難點，即回答“這個東西是不是人頭”這個問題時，存在許多幹擾因素
- 專案釋出之後，發現對“頭戴連帽衫帽子”這一情況的識別準確率比較低
- 主要原因是連帽衫的帽子被戴上時，從側面看會遮住脖子面部、頭髮等“人頭”的特徵部位
- 設計/開發的時候考慮到了這種狀況，由於這種情況的發生概率相對較小，因此目前解決方案是：
- 系統在向用戶提醒違規行為時，會提供圖片給使用者進行輔助判斷。
2.5.6 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
- 程式碼複審交給隊友進行“分散式複審”；
- 程式碼規範執行得不夠嚴格，沒有使用統一的程式碼規範，僅要求詳細註釋介面和功能。
2.5.7 學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 學到了什麼：設計、實現、後續複審的方法很重要，很大程度上影響專案的完成和維護；
- 會做什麼改進：使用單元測試、測試驅動的開發輔助專案的設計和實現，制定嚴格程式碼規範，並且設定程式碼複審計劃，為程式碼複審留出時間；
2.6 測試/釋出（3分）
2.6.1 團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？
- 團隊有測試計劃；
- 但是在專案交付前沒有充足時間進行完整地執行測試計劃，僅進行了基本的測試；
2.6.2 團隊是否有測試工具來幫助測試？
- 暫時沒有使用測試工具
2.6.3 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
- 如何測量並跟蹤軟體的效能：通過給出不同的輸入，測試多種識別目標的識別效果與判別效度，使用適量的監控畫面進行檢測；
- 這些測試工作為優化和維護提供了方向，間接提高了軟體對多種情況的適應性與長期執行的穩定性；
- 應有哪些改進：提高識別效率、效度，進行影象優化
2.6.4 在釋出的過程中發現了哪些意外問題？
- 在前後端互動過程中出現了跨域問題
- 有時候向後端請求資料時沒有接收到資料，但是也沒有報錯
2.6.5 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
- 學到了什麼：軟體測試是釋出前重要的一環，應當被重視；
- 會做什麼改進：
- 將測試寫入日程
- 使用測試工具來幫助測試、分析效能
2.7 團隊的角色，管理，合作（3分）
2.7.1 團隊的每個角色是如何確定的，是不是人盡其才？
- 首先在團隊成員的自我介紹環節，成員需要介紹自己所擅長的技術、期望承擔的角色；
- 每個人期望承擔的角色基本符合原計劃的三個人負責前端，三個人負責演算法，三個人負責後端；
- 是否人盡其才：
- 我認為軟體工程主要是一個學習的過程，因此分角色的評判標準應該首要是成員的主觀意向，然後是成員的客觀能力；
- 因此分角色時本團隊將成員意願和能力綜合考慮，進行角色分配；
- 這其中或許存在一定的“最擅長某方面的人不在該方面”的現象，但這也是依據相應成員的意願做出的分配
- （比如：有的成員之前在其他專案負責過相關內容，有相關經驗，但是在這個專案中他希望能在其他方面鍛鍊一下自己，那麼在並不是非他不可時，我們團隊選擇尊重該成員的主觀意願）
2.7.2 團隊成員之間有互相幫助麼？
- 團隊成員的互相幫助既存在於每個方面內（相似內容的討論、互相學習幫助）
- 也存在於方面間（介面、互動部分的共同制定，使用方法的交流學習）
2.7.3 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （彙總至組長部落格）：
潘偉君：
我感謝林經緯，因為他對任務態度端正且精益求精，沒有強制要求的情況下仍然通宵完成了任務，此外還參與評估、評分，為貢獻度的評分提供了重要依據。
我感謝餘育洲，因為他幫我分擔了α衝刺的PPT，並且認真地評估、評分，為貢獻度的評分提供了重要依據。學到了企劃書的編寫流程，團隊管理流程，PPT、部落格、答辯的技巧。此外還對YOLOV5有了更深刻的瞭解以及應用。如果歷史重來一遍，我希望更多地參加演算法工作，收集更多趁手的API，學習更多高效有用的演算法。
林經緯：
我感謝 盧婧、俞志敏、許嘉濱 對我的幫助。因為前端小組群裡我們互相分享進度和前端經驗，互相監督進度，才讓我們前端從無到有、一點一點搭建起來。嘉濱教我使用Bootstrap工具，還在前後端對接時，教我這方面應該怎麼做，如何避坑。
學到了css html js前端程式設計。如果歷史重來一遍，應該會直接開始程式設計，不用去學任何前端知識，因為在使用過程中，基本上就掌握了很多操作。
在此次團隊作業中，我學到了一些新的前端框架和方法，能更有效率地寫程式碼，並且熟悉了前後端互動的相關知識並學會應用。如果歷史重來一遍，我會更早地學習相關框架和方法，更早地投入應用，並更早地嘗試向後端傳送請求，還是希望自己接下來能有更高的效率完成相關任務。
俞志敏：
感謝林經緯對我的幫助，因為在前端任務上幫我分擔了很多，也在前端學習方面給到了一些建議，讓我對前端的路線方向有大致瞭解。
學習到了bootstrap和各種前端頁面的編寫方法，如果重來一遍，學習效率會更高。
盧婧：
我感謝許嘉濱對我的幫助，因為當前後端互動出現問題時，他能耐心有效地進行討論並除錯，能積極地解決相關問題。
在此次團隊作業中，我學到了一些新的前端框架和方法，能更有效率地寫程式碼，並且熟悉了前後端互動的相關知識並學會應用。如果歷史重來一遍，我會更早地學習相關框架和方法，更早地投入應用，並更早地嘗試向後端傳送請求，還是希望自己接下來能有更高的效率完成相關任務。
黃榮濤：
我感謝劉昌隆對我的幫助，在學習yolov5時請教了劉昌隆許多問題
我感謝餘育洲對我的幫助，在進行標註區域人頭檢測時，學習了檢測的相關思路
我感謝許嘉濱對我的幫助，在與他交接工作時，幫助我解決了很多問題。
我感謝組長潘偉君，是個很負責任的人！
（排名不分先後）學習了yolov5演算法和檢測人頭的相關演算法。重來：我會加強學習yolo的原始碼，做進一步的改進。
劉昌隆：
我感謝餘育洲對我的幫助：給我在視覺化熱力圖實現方法上提供的幫助。
我感謝組長潘偉君對我的幫助，組長是個負責人的人，給我規劃好alpha衝刺個個時間段需要完成的任務，對於我這樣沒有push推動進度緩慢的人是非常大的幫助。
我感謝黃榮濤對我的幫助，我們是一起在團隊中負責功能演算法的實現，在alpha衝刺階段我們保持溝通，一起完成了基本功能。學習到了影象增強的各種方法和資料視覺化繪製熱力圖的方法，如果再來一次我想嘗試用深度學習處理增強影象方法，以及學習更多的知識
餘育洲：
我感謝劉昌隆對我的幫助，因為某個具體的事情:在標註資料集的時候幫我承擔了一部分工作量，在編寫權重檔案和yaml檔案時指出了一些錯誤。
學會了訓練一個目標檢測模型的全過程，以及對模型效果的後期優化。還把暑假時想學的openpose學了。如果歷史重來一遍，我一定會在編寫權重檔案的時候多看看網路上的經驗，對權重引數的不同組合的作用先有個大概瞭解，自己一點點debug和修參實在太痛苦了。
許嘉濱：
我感謝盧婧對我的幫助，在我後端伺服器一直炸掉的情況下能等待那麼久才進行測試。
學到了什麼：對一個軟體來說，測試環境和生產環境的衝突永遠是存在的。這次作業更換了兩臺伺服器，不適網路太差，記憶體過小，就是硬體不支援高版本cuda。如果一開始直接租一臺高效能伺服器可能事情會少一些，但沒錢租啊。如果歷史重來一遍我會多花些錢租個更好的伺服器，這樣就不會遇到例如記憶體溢位，cuda版本過低這樣的問題了。
黃澤華：
我感謝許嘉濱對我的幫助，因為某個具體的事情：承擔了一部分原先應該由我完成的工作，工作效率也很高
學到了後端通過flask搭建伺服器，如果重來，會加快工作速度，學習更多技能
2.8 總結（4分）
潘偉君：
本次α衝刺，團隊按照計劃相對平穩地完成了大部分工作。還有少部分工作由於交接、考試之類的原因有所推遲，計劃在β衝刺進一步完成。這次α衝刺非常感謝隊友們的配合以及積極的態度，大家都儘自己的能力、精力來完成手頭的專案，也有同學甚至額外花時間完成了分外的內容，一方面非常敬佩同學這樣的精神，另一方面也反思自己對工作專案的考慮是否充分。這次衝刺我學習了演算法方面的內容，主要是對YOLOV5的應用，各種API的使用，瞭解到了熱力圖，IOU等更好的技術。經過答辯也瞭解到了之後學習、改進的方向，感覺收穫頗豐。
林經緯：
一開始節奏沒跟上，到後期發現需要很多時間調整細節樣式，還有一些bug的修改。跟著小組的進度走，學到了很多，也不是說很難，只是有了畏難心理就很難實現。這次軟工實踐，忙的時候連夜趕過進度，也跑到自習室花了一個晚上畫座點陣圖，alpha衝刺的時候剛上手前端那段時間大夥也都很體諒我，很不好意思。最後做出成果的時候，能說我有做出過貢獻，感謝我們的團隊！
俞志敏：
一個是需求一定要一開始就和負責任溝通清楚，像我一開始設定介面的座位佈局是按ppt的設計的，與原型還有一定差距，做了一些無用功；
二是介面做完之後要在不同平臺進行測試，避免電腦端顯示正常而手機端排版混亂的情況；
三是遇到問題要及時和負責人溝通反饋；
盧婧：
在本次團隊專案中，我又鞏固了自己的掌握的前端知識，並學習了新的更高效的框架和方法，感覺真是收穫滿滿呢。此外，在本次作業中，我熟悉了一直想熟悉的前後端互動部分，能夠將學到的相關知識進行實踐，並且有人能一起進行除錯。當然，還得感謝一下週同學的熱心解惑。通過本次作業，我感受到了理論聯絡實際的重要性，光是掌握相關知識是不夠的，在寫程式碼的過程中還是有不少疑惑。在此次團隊任務中，我充分感受到了jquery的方便(不過似乎很少人用了）。我覺得自己還是得繼續學習，前端需要學習的知識還有很多，接下來，在繼續完成團隊任務的過程中，將繼續將所學進行實踐，並且在後續過程中還打算學好三大框架中的一種，並且讓自己能寫出更好用且更好看的頁面。
黃榮濤：
本次為期兩週的α衝刺與我三門考試、大作業撞上了，給我的任務帶來了很多困難，每天都很焦慮，擔心考試掛科、任務做不完，而且兩天都要進行一次提交，十分的痛苦！但也實實在在的促進了專案的進行與知識的學習，熬過來之後感覺收穫頗多，學習了很多新知識，增進了與隊友的感情。我也十分感謝其他成員對我的幫助，沒有他們的幫助我的任務不能順利完成。在接下里我也會進一步的優化，並增加新功能。
劉昌隆：
這次alpha衝刺的階段作為一個學習者看到了我們隊長對於任務進度的把控的能力，組員對於個人任務完成的信心以及能力，收穫頗豐。作為一個組員，按照計劃一步步的完成既定任務的時候還是有很高的滿足感。學習到了對於影象的增強方法，現在對於影象處理的方法真的非常多，現在的能力還只是採用了經典的Retinex方法，希望繼續學習一些深度學習處理影象的演算法；學習了資料視覺化繪製熱力圖的方法。但是像柯老師說的我在alpha衝刺階段對低光，模糊影象選取增強只是做到“人工”智慧的階段。在不影響團隊整體的專案結構，不做太多調整而只是更改權重檔案的情況下，在beta衝刺的時候考慮用圖片清晰度評價的方法，自動批量的對低質量的圖片進行增強替換原始圖片。
餘育洲：
這次團隊作業讓我學會了很多新知識，也把之前學過的一些知識進行了鞏固。最重要的是提升了我的debug能力，無他，唯手熟爾(實際就是菜，bug一堆)。另一方面就是讓我看到了團隊協作的力量，本以為很難的一個專案，在大家的不懈努力下一步步完善，使它從想象走向現實。最後，感謝隊友的付出，很高興能和你們一起組成一個團隊。
許嘉濱：
這次作業可以用一個詞形容：緊迫。如果沒有其它課程的作業，考試，比賽，那還是比較從容的嗎。但這些事情衝突的時候，為了最大化，考試是最重要的。
後端總體寫起來還是比較快的，沒有介面，專注於業務邏輯。但小問題比較多，比如資料庫讀寫一開始沒有選到最合適的框架，不會重新整理檔案讀寫快取，json資料過大。總結就是經驗不足，沒有了解工業上常用的解決方案。
對一個軟體來說，測試環境和生產環境的衝突永遠是存在的。這次作業更換了兩臺伺服器，不適網路太差，記憶體過小，就是硬體不支援高版本cuda。如果一開始直接租一臺高效能伺服器可能事情會少一些，但沒錢租啊。
黃澤華：
通過這次作業，學習到了很多知識，flask框架如何搭建伺服器、posthandler來獲取ip地址做到限定ip訪問等等，網上查閱資料的同時能學到很多知識，覺得自己也很多需要學習，自身能力也得到了提升，很感謝團隊成員的工作付出以及幫助，以後會更加努力學習更多技能