https://www.cnblogs.com/Klein-Wang/p/15586147.html

一、基本情況

1.1組長部落格連結

https://www.cnblogs.com/Klein-Wang/p/15586147.html

1.2現場答辯總結

• 現場答辯總結
  • 現場答辯就Alpha兩週衝刺成果進行了展示，完成了預計的初步演算法功能，採集資料並構建資料集，同時生成初步輸出視訊，且實現60%前後端的設計與架構。
  • ppt關於前端原型部分講解較少，但對演算法實現以及功能展勢部分的介紹較為詳細，演示視訊功能展示齊全，後續應加快前後端的實現與對接。
  • 答辯中無同學提問，老師提議應加快進度，確保按期完成。

1.3全組討論的照片

1.4評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例

二、總結思考

2.1設想和目標

2.1.1我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？

• 隨著經濟社會發展和物質消費水平大幅提高,生活垃圾產生量迅速增長,已經成為新型城鎮化發展的制約因素。城市中生活垃圾的產生量急劇增高，小區或宿舍垃圾存放點的負載逐漸增大。在垃圾桶數量多、分散廣的實際情況下，垃圾監管難、及時清倒難等一系列問題不斷湧現。針對上述痛點，我們提出了一種基於深度學習的垃圾投放狀態智慧檢測與識別方法。該方法以實時監控視訊作為基礎，使用目標檢測技術，對垃圾桶進行實時監測，檢視其空滿狀態以及是否存在異樣，並對投放垃圾的居民進行動作識別判斷其對垃圾是否按規定定點投放，採用人臉識別技術對投放垃圾行人進行記錄可追溯垃圾投放來源，並對不合規投放垃圾的人群加以標記，有效緩解了人手緊缺和監管不力等一系列問題。

• 定義清楚

• 本產品的可能應用場景還包括學生生活區、工廠園區、人流密集的公園垃圾點監測等。本產品面向社群管理者，於非正常狀態，系統對社群管理者發出提示，社群管理者只需對異常垃圾點進行清理即可，大大提升了監管效率。

2.1.2我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?

• 目標目前尚未全部完成。

• 經歷alpha衝刺我們小組採集了超過三千張多場景的資料集，包括白天、傍晚、夜晚與降雨等場景，並且運用視覺化的影象標定工具 LabelImg進行資料集的標註。已經實現

• 1. 系統對垃圾桶的邊緣輪廓以及空滿狀態進行深度學習，將其狀態分為正常狀態：蓋子已關。非正常狀態：蓋子未蓋、垃圾桶已滿、垃圾溢位。
  2. 對垃圾點附近單個或多個人群進行跟蹤，區分其是否進行垃圾投放，對垃圾投放的行人的運動軌跡進行記錄；
  3. 對行人投放垃圾動作是否合規進行分析，對不合規投放垃圾的人群使用人臉識別演算法加以記錄，當其記錄次數達到一定數量時對其進行警告及處罰；

• 我們的專案未按照原計劃交付，由於前端人員經驗不足、知識匱乏，前端開發還在進行中，由於考試等的原因還未完成前後端的對接。

• 本專案原計劃首先面向福州大學教師群體，該群體對新技術的接收能力高，同時在社會上有廣泛的影響力。高校創業團隊的身份， 則有利於我們與高校教師群體迅速建立信任，獲得支援。後期擴充套件到政府、事業單位、企業等。這種模式的成功實施，一方面有賴於產品效能優勢，另一方面在於建立信任和口碑效應。現如今還未完成。

2.1.3使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

• 沒有開發完全，暫時沒有使用者，使用者量未接近預想。

• 我國已經進入了垃圾管理的高負擔期，具有“存放點分散、用人成本高、存放點監管難、垃圾傾倒不及時”的特點。垃圾桶垃圾溢位，居民隨意投放垃圾等現象讓無數社群管理者頭疼。該產品可以做到管理者僅需監控攝像頭就能實現垃圾桶狀態實時知。我們組核心人員對重要功能可以接受。

• 接下來我們會進一步完善前後端的對接，實現我們預期的目標。

2.1.4有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

• 經歷了alpha衝刺我們小組總結了以下幾個經驗教訓：

  • 由於拍攝裝置與拍攝地點等問題，有部分資料集並不能很好模擬攝像頭的效果。

  • 在進行資料集標註時，由於團隊約定不夠明確，導致出現某些標註不合規範或標註名不同等問題。

  • 綜合幾個演算法時，需要找到每個演算法都能執行起來的環境，這個普適環境難以確定。

  • UI介面由於技術原因，一些控制元件與效果難以達到預期。

  • 組員之間要多進行溝通交流。

2.2計劃

2.2.1是否有充足的時間來做計劃?

• 有。目前專案主要功能已經基本實現，在beta衝刺階段進行前後端的對接以及演算法整合。

2.2.2團隊在計劃階段是如何解決組員對於計劃的不同意見的？

• 在會議上如果對於計劃有不同意見大家會當場提出，然後進行小組討論，達成共識。我們有一個QQ群，也可以在群裡進行交流。

2.2.3原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

• 原計劃還未全部做完，實現了60%左右。現在後端實現了使用者，意見反饋 日誌，video四個模組，還未實現前後端的對接。

• 原因：

  • 在一些功能的實現上，我們一開始預期太過於樂觀，在接觸後發現實現比預期要複雜以及困難，需要更多的時間來實現預期的功能。

  • 在alpha衝刺階段幾乎每個成員都有一門兩門的考試，大家都忙於準備考試。

  • 前端在學習ing

2.2.4有沒有發現做了一些之後看來沒必要或沒多大價值的事?

• 暫時沒有，在分工上每一個人都實現自己的功能，每一個功能都是這個專案所需要的。

2.2.5是否每一項任務都有清楚定義和衡量的交付件?

• 在每一次任務釋出時，我們都會對任務劃分成幾個模組進行分配，在最大程度上對每一項任務都進行了清楚的定義和衡量的交付件。

2.2.6是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

• 沒有完全按照計劃進行，在alpha衝刺階段預期實現前後端以及前後端的對接，但是現如今只實現了後端使用者，意見反饋 ，日誌， video四個模組，對於前端的實現也還未全部完成，前後端對接工作還未開展。

• 意外出現在沒想到考試全部聚集在alpha衝刺階段，每人都要準備他自己的考試，有人甚至有兩門考試，在緊湊的複習中暫時就把任務放下了。

• 前端的學習成本過高，訓練資料集的時候顯示卡不夠給力，訓練得有些慢

• 沒能預估到考試的風險和alpha衝刺工作量的強大。

2.2.7在計劃中有沒有留下緩衝區，緩衝區有作用麼?

• 在計劃中幾乎沒有留下緩衝區，對於一開始的資料採集就花費了較多的時間，採集完資料後就馬上開始對資料集標註，對於三千多張圖片在大家熬夜標註下也是花了大把的時間，在標註初期還出現了對標註進行改動，導致要重新修改標註。資料集標註結束後大家立馬開始學習前後端開發以及各個演算法的環境配置，顯得能夠預留緩衝區的時間少之又少。

• 緩衝區是有作用的，在一定程度上可以，調整了工作進度和工作節奏。

2.2.8將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

• 在將來的計劃中會規劃一到兩天的緩衝區用來調整工作進度以及工作節奏，成員可以利用緩衝區時間對自己的工作進行了解以及進一步的學習。

• 在alpha階段大家已經經歷了一次又一次的熬夜，在將來的工作中大家也會齊心協力，儘自己最大一份力將專案預期功能實現並且進行完善。

2.2.9學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 學習到了資料的採集，LabelImg進行資料的標註，YoloV5演算法對垃圾桶及附近垃圾進行識別與檢測，Insightface的人臉識別及MTCNN的人臉檢測演算法對投放垃圾行人進行記錄，YoloV5及DeepSort演算法的目標跟蹤技術，Openpose演算法的學習。

• 如果歷史重來一遍我們會考慮到考試等不可抗力的因素，將任務進行更加細緻的劃分進行交付。

2.3資源

2.3.1我們有足夠的資源來完成各項任務麼?

• 沒有。

• 一些所需的功能團隊大部分人都是沒有接觸過的，所以需要額外的時間來學習，而時間資源正是我們現在緊缺的。

2.3.2各項任務所需的時間和其他資源是如何估計的，精度如何?

• 首先由組長進行估計，在小組會議上大家再進行更加細緻的估計，但是每個人已有的技術水平和學習能力都不一樣，分配下去的任務能按時做完就已經很好了。

2.3.3測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

• 對於已經完成的部分，測試所需要的資源是足夠的。
• UI原型設計的難度確實是十分巨大的，設計人員不懂技術，其實並不能很好的還原我們想要做什麼或者能做什麼，只能慢慢修改。

2.3.4你有沒有感到你做的事情可以讓別人來做（更有效率）?

• 沒有。在分配專案的時候，大家都會爭取到最適合自己以及自己最願意去做的模組，在達成共識後每個人所做的部分都是自己最擅長的。

2.3.5有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?

• 對於時間的管理過於樂觀，到最後卻來不及。如果歷史重來一遍，對於時間資源，會更加細緻的計劃時間。

• 希望大家以後都能往全棧發展，各個領域都懂一點，再專精某個領域，才能更好地交流，更好地程式設計。

2.4變更管理

2.4.1每個相關的員工都及時知道了變更的訊息?

• 每個相關的成員都能在qq群裡看到變更的訊息，對於一些需要討論的變更會通過騰訊會議的方式大家一起討論最後達成共識。

2.4.2我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

• 看功能核心與否

2.4.3專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

• 基本條件就是預期功能全部實現，目標客戶可以正常使用，前端頁面可以正常跳轉，可以給後端傳送正確的訊息，後端處理請求不報異常，返回正確的資訊。

2.4.4對於可能的變更是否能制定應急計劃?

• 可以。一出現變更大家會通過線上或者線下的方式進行討論，制定應急計劃。

2.4.5組員是否能夠有效地處理意料之外的工作請求？

• 可以，比如寫部落格。

2.4.6學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 對於出現的變更，要及時提出並且分配給最適合這項工作的成員。

• 交流大於一切，不能做或者短時間內無法做出來的事情儘早告訴隊友，不要一個問題自己琢磨半天。

• 在專案初期應該進行一定的風險評估，預測到可能出現的變更，提前想好相應的應對措施，以便在之後工作的開展中對於突然的變更有所準備。

2.5設計/實現

2.5.1設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

• 設計工作於十月中旬構建專案時進行，由小組7人共同商討完成，時間和人員合適。

2.5.2設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

• 在介面設計討論時，實現方式摸稜兩可，後經二次討論達成統一標準。

2.5.3團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

• 暫時還沒有使用單元測試，後面會考慮。但是，用到了UML，感覺效果甚微。

2.5.4比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

• UML文件在設計中不斷更新，增加若干功能，且部分功能進行了改進；在推進中發現不合理的地方，並對設計進行了修改，故產生區別；UML文件應在推進中實時更新以確保設計合理性。

2.5.5什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

• 人臉識別功能產生Bug最多。由於Insightface沒有同一配置標準，在配置演算法時出現相容性問題多；釋出後發現演算法效能與執行時間較先前降低；由於整合後演算法功耗太大，目前裝置運算能力不足以完美承載，導致處理資料耗時較長。

• 設計與開發只是紙上談兵，是騾子是馬，程式碼跑起來才知道，程式碼的錯誤很多都是不可預知的。

2.5.6程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

• 程式碼複審由人工檢測核驗，確保執行無誤，嚴格執行了程式碼規範。

2.5.7學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

• 學習了軟體設計具體過程及演算法實現，增長了開發設計經驗。如果重來，在初始設計時應增加細節，避免不必要的修改與debug。

2.6測試/釋出

2.6.1.團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？

• 對各部分演算法效能及可行性進行了測試，未進行正式驗收測試。

2.6.2.團隊是否有測試工具來幫助測試？

• 後端有idea自帶的測試工具

2.6.3.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

• 根據資料流傳輸的速率及處理時間來評價軟體效能；有用，從測試中發現存在優化的空間；後續可對演算法魯棒性及速率進行優化。

2.6.4.在釋出的過程中發現了哪些意外問題？

• 由於前後端對接時出現問題，目前產品尚未釋出，僅為內測版，後續將繼續跟進。

2.6.5.學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 學習了對產品進行測試，且根據資料反饋進行效能改進。

2.7團隊的角色，管理，合作

2.7.1團隊的每個角色是如何確定的，是不是人盡其才？

• 根據大家學習的內容不同，以及擅長領域不同，進行前後端分工，以達到人盡其才。

2.7.2團隊成員之間有互相幫助麼？

• 有。在演算法配置執行處理時，成員互相協助，分享經驗；在標註處理資料時也進行了幫助與討論。

2.7.3當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝。學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 王業震：我感謝鄭浩彬對我的幫助。因為某個具體的事情：是他，與我共同奮戰到深夜，只因那一行行報錯的程式碼；是他，時而眉頭緊皺，時而眉頭舒展，與我共同尋找錯誤的根源。成功實現了insightface人臉識別演算法與mtcnn演算法，別學習了演算法相關知識。如果歷史能夠重來，我希望自己可以把bug一次改對。

• 毛長江：我感謝鄭浩彬對我的幫助，因為某個具體的事情：在配置演算法的時候，存在版本相容性的問題，安裝的pytorch無法正常執行，在交流與分享經驗後下載了適配版本，成功解決。學習了標註資料，安裝配置環境，從應用到原理層面理解演算法並改善，如果重來會在配置前多詢問他人經歷，減少不必要的失敗嘗試

• 鄭浩彬：我感謝黃志翔對我的幫助， 因為某個具體的事情:讓我明白整個開發軟體的大體流程，和各個模組的分工，讓本來腦海中架構混亂的我，變得清晰起來。

• 張靜：我感謝施可嫿對我的幫助， 因為某個具體的事情: 因為在程式碼測試時給我巨大幫助。學會了資料集的標註，演算法環境的配置。如果能夠重來一遍我會先精通語言，便於後續的學習。

• 陳志良: 我感謝鄭浩彬對我的幫助，因為他教了我對標題欄如何進行處理。學到了如何自定義標題欄。如果歷史重來一遍，我會對介面的美觀進行加工。

• 黃志翔: 我感謝王業震對我的幫助, 因為在專案開始的時候缺少了一個具體的方向, 在多個模組中猶豫不決, 他幫我確定了模組的優先順序後項目才能夠順利開始。本次的軟工衝刺從零到有開始學習了spring的使用, 在極短的時間內學習了後端的知識, 如果歷史重來一遍會更有針對性地去學習框架。

• 施可嫿：我感謝張靜對我的幫助，因為某個具體的事情：幫我解決了關於前端方面以及人工智慧演算法方面的疑惑。學到了頁面設計的規範及技巧、UI設計工具的使用、如何進行目標檢測以及前端的相關知識。如果歷史重來，我會提高學習效率，花更多時間學習前端知識。

2.8總結

• 王業震：通過Alaph衝刺，我成功實現了從0到1的突破。作為一個本科生，之前從未想過能把頂會頂刊的演算法重現，也從未想過人臉識別這種高大上的技術也能觸手可及。當演算法成功執行的拿一剎那，之前所有的壓力與焦慮全部都煙消雲散，只想對自己說一句666！
• 毛長江： 本次alpha有不少收穫，增加了不少開發經驗與實際性操作，同時藉此也對機器學習領域有了一定探索，希望下次也能在完善與嘗試中學到東西。
• 鄭浩彬：經過這次Alpha衝刺，我學習到了許多人工智慧方面的相關知識，比如如何標註資料集，如何使用Yolov5演算法訓練資料集等，也感受到了時間真的很少，每天都被很多事所困擾。真的希望時光能多倒回一點，讓我學習完軟工要用到的方方面面的知識，再來更好地軟工實踐。
• 張靜 ：在alpha衝刺階段，第一次跑開原始碼的一頭霧水，第一次學習環境配置以及對原始碼的學習。在無數的error之後終於跑出了第一個版本，上一次這麼興奮還是北京申奧成功。在這個階段還和隊友一起完成了榕創天眼的商業計劃書，還一同製作了alpha衝刺階段的ppt。在製作ppt和寫BP的時候，隊友要求事事完美並且格式一定要對齊的處女座情節給我影響最大，導致如今的我已經成功加入強迫症陣容。
• 陳志良：經過這次衝刺，我已初步掌握qt設計師這個頁面設計工具，也對前端有了更深的認識和理解。也感謝我的隊友，在我遇到問題而不知所措時給我的幫助。
• 黃志翔：本次的軟工衝刺從零到有開始學習了spring的使用, 在極短的時間內學習了後端的知識。本次軟工的作業極大的培養了我的團隊合作的意意識。提高了趕DDL的能力。提高了忙中摸魚的水平。
• 施可嫿：經過這次Alpha衝刺，我學到了很多，如前端的相關知識、頁面設計的規範及技巧、UI設計工具的使用、如何進行目標檢測等，也感受到了開發過程中Alpha衝刺的緊張感。同時也發現了自己的許多不足：掌握的知識、技巧還遠遠不夠多等，在今後的學習裡，我會努力學習，克服不足，提高開發水平。