7組-Beta衝刺-總結

一、基本情況

1.1 組長部落格連結：

https://www.cnblogs.com/Pollux-75/p/15606765.html

1.2 現場答辯總結：

• 考慮後端向前端傳輸圖片的安全性問題
• 前端搜尋框輸入提示
• 演算法對模糊影象二分識別
• 前後端互動的資源傳輸優化
• 根據座位框進行圖片分類識別
• 前端展示效果優化

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 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

• 後端和演算法方面在β4就提前完成了
• 前端的工作量估計出現了“低估”的情況，導致前端後期趕進度壓力大
• 團隊在前端方面的整體能力相對弱，前端出現意外是因為當時沒有估計到是因為少考慮了隊員的技術掌握程度

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

• 留下了一天的緩衝區
• 演算法和後端方面的工作在緩衝區之前就基本完成了
• 前端在緩衝區中繼續完成前後端互動的工作

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

• 本次衝刺中專案整體上在緩衝區前基本完成
• 因此將來的計劃中緩衝區大致仍然設定為一天
• 儘量在專案中期完成大部分內容
• 原則上不加班，儘量在最初規劃的時候就要留出足夠的時間，並且進行合理的規劃
• 此外考慮額外設定一段時間用於測試專案

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，學習更多高效有用的演算法。

β衝刺部分：
我感謝黃榮濤，耐心地和我討論座位框的自適應方法，確定具體實現方式
我感謝林經緯、盧婧、俞志敏、許嘉濱，在β最終階段組建了討論組進行衝刺，在答辯前加班加點最後成功完成前後端內容
我感謝餘育洲，幫我收集了組內的技術圖片和文件，為PPT的製作助力

學到了座位框的自適應方法。如果重來一遍，會給前端多分配一點人，緩解前端工作壓力。會多鼓勵隊友，發揮隊長的鼓舞作用。

林經緯：

α衝刺部分：
我感謝 盧婧、俞志敏、許嘉濱 對我的幫助。因為前端小組群裡我們互相分享進度和前端經驗，互相監督進度，才讓我們前端從無到有、一點一點搭建起來。嘉濱教我使用Bootstrap工具，還在前後端對接時，教我這方面應該怎麼做，如何避坑。

學到了css html js前端程式設計。如果歷史重來一遍，應該會直接開始程式設計，不用去學任何前端知識，因為在使用過程中，基本上就掌握了很多操作。
在此次團隊作業中，我學到了一些新的前端框架和方法，能更有效率地寫程式碼，並且熟悉了前後端互動的相關知識並學會應用。如果歷史重來一遍，我會更早地學習相關框架和方法，更早地投入應用，並更早地嘗試向後端傳送請求，還是希望自己接下來能有更高的效率完成相關任務。

β衝刺部分：
我感謝盧婧、許嘉濱對我的幫助，因為在修改前端bug、趕ddl的過程中他們給予了我非常大的幫助和支援。

學到了前後端介面和jquery互動。會更早和組內成員進行討論，商量需求，這樣任務進度會快很多，同時很多不符合需求的元件也不需要浪費時間寫。

俞志敏：

α衝刺部分：
感謝林經緯對我的幫助，因為在前端任務上幫我分擔了很多，也在前端學習方面給到了一些建議，讓我對前端的路線方向有大致瞭解。

學習到了bootstrap和各種前端頁面的編寫方法，如果重來一遍，學習效率會更高。

β衝刺部分：
我感謝林經緯對我的幫助，因為他對我的設定介面的樣式一體化做了最後的優化，當專案遇到困難時，我們的前端負責人組織了組員去空教室一起討論解決

通過本次衝刺使我對bootstrap框架更加熟練，審美也有了一定提高並能用ps對ui進行一些優化；如果重來一遍，會把介面一體化做的更好

盧婧：

α衝刺部分：
我感謝許嘉濱對我的幫助，因為當前後端互動出現問題時，他能耐心有效地進行討論並除錯，能積極地解決相關問題。

在此次團隊作業中，我學到了一些新的前端框架和方法，能更有效率地寫程式碼，並且熟悉了前後端互動的相關知識並學會應用。如果歷史重來一遍，我會更早地學習相關框架和方法，更早地投入應用，並更早地嘗試向後端傳送請求，還是希望自己接下來能有更高的效率完成相關任務。

β衝刺部分：
我感謝許嘉濱、黃榮濤和林經緯對我的幫助，因為在我寫的程式碼遇到bug一時無法解決時，大家都很熱心地幫助我一起查詢問題所在

通過這次衝刺，我對於前後端的互動有了更深的瞭解，對於前端的各種報錯有了一定的解決能力。如果歷史重來一遍，我會督促自己更早更快更高效地完成相關任務，並學習更多的相關技術，希望自己更好地完成前端和後端的互動。

黃榮濤：

α衝刺部分：
我感謝劉昌隆對我的幫助，在學習yolov5時請教了劉昌隆許多問題
我感謝餘育洲對我的幫助，在進行標註區域人頭檢測時，學習了檢測的相關思路
我感謝許嘉濱對我的幫助，在與他交接工作時，幫助我解決了很多問題。
我感謝組長潘偉君，是個很負責任的人！
（排名不分先後）

學習了yolov5演算法和檢測人頭的相關演算法。重來：我會加強學習yolo的原始碼，做進一步的改進。

β衝刺部分：
我感謝劉昌隆、餘育洲對我的幫助，在交流優化演算法的思路時，給了我很多有價值的建議。
我感謝許嘉濱對我的幫助，與後端交接時，給我提供了很多幫助。
我感謝潘偉君對我的幫助，在討論座位框自適應的演算法時，耐心為我講解。

優化了座位檢測演算法，實現了座位框的自適應。重來：重視座位框自適應演算法。

劉昌隆：

α衝刺部分：
我感謝餘育洲對我的幫助：給我在視覺化熱力圖實現方法上提供的幫助。
我感謝組長潘偉君對我的幫助，組長是個負責人的人，給我規劃好alpha衝刺個個時間段需要完成的任務，對於我這樣沒有push推動進度緩慢的人是非常大的幫助。
我感謝黃榮濤對我的幫助，我們是一起在團隊中負責功能演算法的實現，在alpha衝刺階段我們保持溝通，一起完成了基本功能。

學習到了影象增強的各種方法和資料視覺化繪製熱力圖的方法，如果再來一次我想嘗試用深度學習處理增強影象方法，以及學習更多的知識

β衝刺部分：
我感謝黃榮濤對我的幫助，因為對於優化標框自適應的功能我在alpha的負責不在這一塊，所以黃榮濤主動幫助我完成，我來提供一些測試資料，來檢測命中率效果

我學到更多的計算機圖形操作的技術，如影象評價，和SVM的一些原來實現。
如果重來一遍，因為這段時間中間我還有一門考試，如果再來一遍沒有考試，我希望可以做一些更多的任務，為隊友分擔壓力。

餘育洲：

α衝刺部分：
我感謝劉昌隆對我的幫助，因為某個具體的事情:在標註資料集的時候幫我承擔了一部分工作量，在編寫權重檔案和yaml檔案時指出了一些錯誤。

學會了訓練一個目標檢測模型的全過程，以及對模型效果的後期優化。還把暑假時想學的openpose學了。如果歷史重來一遍，我一定會在編寫權重檔案的時候多看看網路上的經驗，對權重引數的不同組合的作用先有個大概瞭解，自己一點點debug和修參實在太痛苦了。

β衝刺部分：
我感謝劉昌隆對我的幫助，因為某個具體的事情:由於個人的電腦出現了一點bug，重灌了系統，於是很多配置的檔案都沒了。所以在優化模型，增強遠處的人頭的檢測效果的時候，yaml檔案的編寫以及最後的訓練步驟都是由劉昌隆幫忙完成的。

學會了很多能夠增強檢測準確率的規則，這些規則很多都是我在之前的工作中沒有想到的。如果歷史重來一遍，我一定要在標註資料的時候先使用影象增強工具增強影象效果，否則標註較遠處資料的時候解析度會變得很低，給標註工作帶來很多困難

許嘉濱：

α衝刺部分：
我感謝盧婧對我的幫助，在我後端伺服器一直炸掉的情況下能等待那麼久才進行測試。

學到了什麼：對一個軟體來說，測試環境和生產環境的衝突永遠是存在的。這次作業更換了兩臺伺服器，不適網路太差，記憶體過小，就是硬體不支援高版本cuda。如果一開始直接租一臺高效能伺服器可能事情會少一些，但沒錢租啊。如果歷史重來一遍我會多花些錢租個更好的伺服器，這樣就不會遇到例如記憶體溢位，cuda版本過低這樣的問題了。

β衝刺部分：
感謝林經緯，盧婧等前端組成員的積極溝通，反饋。因此才能前後端交接順利以及快速改進

多考慮一些使用的情景，因為程式不是自己一個人在用的，寫後端也要考慮前端使用是否容易。歷史重來一遍可能會考慮加進更多人性化的功能

黃澤華：

α衝刺部分：
我感謝許嘉濱對我的幫助，因為某個具體的事情：承擔了一部分原先應該由我完成的工作，工作效率也很高

學到了後端通過flask搭建伺服器，如果重來，會加快工作速度，學習更多技能

β衝刺部分：
我感謝許嘉濱對我的幫助，因為某個具體的事情：個人能力很強，承擔了一部分原先應該由我完成的工作，工作效率也很高

學到了後端通過flask搭建伺服器，資料庫的應用，如果重來，希望能學習更多技能

2.8 總結（4分）

潘偉君：

α衝刺部分：
本次α衝刺，團隊按照計劃相對平穩地完成了大部分工作。還有少部分工作由於交接、考試之類的原因有所推遲，計劃在β衝刺進一步完成。這次α衝刺非常感謝隊友們的配合以及積極的態度，大家都儘自己的能力、精力來完成手頭的專案，也有同學甚至額外花時間完成了分外的內容，一方面非常敬佩同學這樣的精神，另一方面也反思自己對工作專案的考慮是否充分。這次衝刺我學習了演算法方面的內容，主要是對YOLOV5的應用，各種API的使用，瞭解到了熱力圖，IOU等更好的技術。經過答辯也瞭解到了之後學習、改進的方向，感覺收穫頗豐。

β衝刺部分：
本次β衝刺，非常感謝黃榮濤和我一起討論了座位框的自適應功能，也非常感謝前後端的成員加班加點完成了互動，還有餘育洲幫我在忙不過來的時候收集技術圖片和文件，助力PPT製作。這次β衝刺的主要問題是前端的工作量比較大，給前後端的成員帶來很大的壓力，如果歷史重來一遍，我應該會把演算法或後端抽一個人去前端幫忙。也很抱歉給前端成員帶來這麼大的壓力。隊長的工作方面，感覺如果我多說一些鼓舞的話，鼓勵大家、排解壓力會更好。

林經緯：

α衝刺部分：
一開始節奏沒跟上，到後期發現需要很多時間調整細節樣式，還有一些bug的修改。跟著小組的進度走，學到了很多，也不是說很難，只是有了畏難心理就很難實現。這次軟工實踐，忙的時候連夜趕過進度，也跑到自習室花了一個晚上畫座點陣圖，alpha衝刺的時候剛上手前端那段時間大夥也都很體諒我，很不好意思。最後做出成果的時候，能說我有做出過貢獻，感謝我們的團隊！

β衝刺部分：
beta階段任務一天結一次，時間太趕，然後又沒有實現前端的好方法，感覺心裡是很難受的，帶著很大的壓力，但是壓力會帶來壓力下的突破和知識吸收，這次收穫是蠻大的。

俞志敏：

α衝刺部分：
一個是需求一定要一開始就和負責任溝通清楚，像我一開始設定介面的座位佈局是按ppt的設計的，與原型還有一定差距，做了一些無用功；
二是介面做完之後要在不同平臺進行測試，避免電腦端顯示正常而手機端排版混亂的情況；
三是遇到問題要及時和負責人溝通反饋；

β衝刺部分：
首先，頁面樣式的優化是必要的，對使用者的體驗有直觀的提升；其次，頁面的佈局不僅要考慮自己負責的部分，也要和其他組員的樣式有一體化的管理；最後，遇到問題的時候可以找個地方一起討論解決，效率會高很多

盧婧：

α衝刺部分：
在本次團隊專案中，我又鞏固了自己的掌握的前端知識，並學習了新的更高效的框架和方法，感覺真是收穫滿滿呢。此外，在本次作業中，我熟悉了一直想熟悉的前後端互動部分，能夠將學到的相關知識進行實踐，並且有人能一起進行除錯。當然，還得感謝一下週同學的熱心解惑。通過本次作業，我感受到了理論聯絡實際的重要性，光是掌握相關知識是不夠的，在寫程式碼的過程中還是有不少疑惑。在此次團隊任務中，我充分感受到了jquery的方便(不過似乎很少人用了）。我覺得自己還是得繼續學習，前端需要學習的知識還有很多，接下來，在繼續完成團隊任務的過程中，將繼續將所學進行實踐，並且在後續過程中還打算學好三大框架中的一種，並且讓自己能寫出更好用且更好看的頁面。

β衝刺部分：
雖然在衝刺過程中有過焦慮和迷茫，但是好在有隊員和朋友們的幫忙，能夠及時地完成所有任務。通過這次衝刺，我感覺自己又掌握了更多的知識，我的精神世界也得到了昇華，能夠扛住更多的壓力與焦躁。很高興能加入比奇堡養老隊，感覺很棒。

黃榮濤：

α衝刺部分：
本次為期兩週的α衝刺與我三門考試、大作業撞上了，給我的任務帶來了很多困難，每天都很焦慮，擔心考試掛科、任務做不完，而且兩天都要進行一次提交，十分的痛苦！但也實實在在的促進了專案的進行與知識的學習，熬過來之後感覺收穫頗多，學習了很多新知識，增進了與隊友的感情。我也十分感謝其他成員對我的幫助，沒有他們的幫助我的任務不能順利完成。在接下里我也會進一步的優化，並增加新功能。

β衝刺部分：
因為本週沒有考試、其他科目的大作業，再加上α衝刺完成度較高，有足夠的時間去優化演算法、增加座位覆蓋率，但每天一提交屬實陰間，當專案沒有進展時也要被迫抽出一點時間編寫部落格提交，但這個推力也促進了專案的完成，對於我這種趕dll的人還是很有幫助的。本輪衝刺，對演算法更熟悉了，簡單實現了座位框的自適應，效果還是顯而易見，答辯時柯老師的建議也很好，後續可以繼續跟進實現。終於熬過來了！感覺收穫頗多，學習了很多新知識，增進了與隊友的感情。我也十分感謝其他成員對我的幫助，沒有他們的幫助我的任務不能順利完成。

劉昌隆：

α衝刺部分：
這次alpha衝刺的階段作為一個學習者看到了我們隊長對於任務進度的把控的能力，組員對於個人任務完成的信心以及能力，收穫頗豐。作為一個組員，按照計劃一步步的完成既定任務的時候還是有很高的滿足感。學習到了對於影象的增強方法，現在對於影象處理的方法真的非常多，現在的能力還只是採用了經典的Retinex方法，希望繼續學習一些深度學習處理影象的演算法；學習了資料視覺化繪製熱力圖的方法。但是像柯老師說的我在alpha衝刺階段對低光，模糊影象選取增強只是做到“人工”智慧的階段。在不影響團隊整體的專案結構，不做太多調整而只是更改權重檔案的情況下，在beta衝刺的時候考慮用圖片清晰度評價的方法，自動批量的對低質量的圖片進行增強替換原始圖片。

β衝刺部分：
在這次的Beta衝刺在一開始的時候因為在alpha衝刺的答辯現場效果不錯，加上自己考試加身，對Beta衝刺有些鬆懈，在考完後繼續投入Beta衝刺中的時候發現還有許多的細節需要優化，而且這些優化還是有一定的難度，最後在隊友的幫助下還是基本完成的Beta的任務。在這再次感謝我的團隊。我體會到了，對於一個專案來說，詳細的計劃，團隊之間相互的推動，有助於團隊進度推進，已經團隊氛圍的融洽

餘育洲：

α衝刺部分：
這次團隊作業讓我學會了很多新知識，也把之前學過的一些知識進行了鞏固。最重要的是提升了我的debug能力，無他，唯手熟爾(實際就是菜，bug一堆)。另一方面就是讓我看到了團隊協作的力量，本以為很難的一個專案，在大家的不懈努力下一步步完善，使它從想象走向現實。最後，感謝隊友的付出，很高興能和你們一起組成一個團隊。

β衝刺部分：
這次β衝刺時間雖短，卻也學到了許多東西，各種增強準確率的規則，以及自適應演算法。我覺得這些知識將會在將來給我帶來極大的幫助。同時也讓我對解決方法的思路更加廣闊，在遇到困難時不一定要死磕，轉換思路往往能取得很好的效果。

許嘉濱：

α衝刺部分：
這次作業可以用一個詞形容：緊迫。如果沒有其它課程的作業，考試，比賽，那還是比較從容的嗎。但這些事情衝突的時候，為了最大化，考試是最重要的。
後端總體寫起來還是比較快的，沒有介面，專注於業務邏輯。但小問題比較多，比如資料庫讀寫一開始沒有選到最合適的框架，不會重新整理檔案讀寫快取，json資料過大。總結就是經驗不足，沒有了解工業上常用的解決方案。
對一個軟體來說，測試環境和生產環境的衝突永遠是存在的。這次作業更換了兩臺伺服器，不適網路太差，記憶體過小，就是硬體不支援高版本cuda。如果一開始直接租一臺高效能伺服器可能事情會少一些，但沒錢租啊。

β衝刺部分：
β衝刺是真的衝刺，又苦又累，但進展也很快。沒想到到最後真能做出一個能用的軟體，完成度也很高。因為平時都是面向命令列程式設計，介面沒有寫太多，看到自己參與的軟體有介面又能用對我來說是很震撼的一件事。還有就是得注意休息了，熬夜寫程式碼不推薦。

黃澤華：

α衝刺部分：
通過這次作業，學習到了很多知識，flask框架如何搭建伺服器、posthandler來獲取ip地址做到限定ip訪問等等，網上查閱資料的同時能學到很多知識，覺得自己也很多需要學習，自身能力也得到了提升，很感謝團隊成員的工作付出以及幫助，以後會更加努力學習更多技能

β衝刺部分：
通過這次作業，學習到了很多知識，flask框架如何搭建伺服器、posthandler來獲取ip地址做到限定ip訪問、資料庫應用等等，網上查閱資料的同時能學到很多知識，覺得自己也很多需要學習，自身能力也得到了提升，很感謝團隊成員的工作付出以及幫助，以後會更加努力學習更多技能