一、基本情況

1.1組長部落格連結

組長部落格連結

1.2現場答辯總結

• PPT部分頁面排版不是非常美觀，但內容比較充實，邏輯比較清晰。
• PPT講解到前端原型部分時略顯倉促，但整體講解得體到位，對於六輪Alpha衝刺的工作分配以及Alpha衝刺的任務完成度都有較好的評價體現。
• 演示視訊功能齊全，邏輯清晰，但是BGM由於本身片段長度不足，因此在視訊中間位置會進行第一遍與第二遍的切換，導致聲音忽低忽高，需要改進。
• 對於測試組對本組的提問/其他組或老師的提問都回答的比較合理，沒有出現答不上來或者回答不令人滿意的情況。
• 對於Alpha衝刺時整體的安排規劃沒有做的很好，希望在Beta衝刺中可以合理安排分工，圓滿完成前後端的任務。

1.3全組討論的照片

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

二、總結思考

2.1設想和目標

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

• 隨著非機動車數量的急劇增長，危險駕駛行為屢見不鮮，交通監管壓力日益沉重。《交通強國建設綱要》要求大力發展智慧交通，目前的非機動車監管過於依賴人力監管，在效能方面略顯遜色，需要智慧化>監管模式。現有攝像頭注重於監管機動車，而忽略了大量非機動車的資料，處於“存而不用”狀態。
• 我們的軟體可以為交管部門提供科技輔助執法的創新方式，一定程度上緩解過於依賴”人力監管“的難題，智慧化的資料統計分析、違規的篩查都是非機動車交通監管的有力武器。整體上說軟體要解決的問>題和功能定義得比較清晰。
• ”雲視界——基於深度學習的道路資訊檢測“能夠適用於公園、紅綠燈路口、高校、公司、社群、停車場、公園、景點等場景，應用廣泛。本軟體面向交管部門的人員，為他們提供更加方便、智慧的監管模式。
  
   

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

• 目標目前尚未全部完成。
• 經歷alpha衝刺我們小組完成了多個場景及晴雨晝夜情境下的資料收集及手動標註工作，學習使用yolov5訓練資料，實現了流量統計、脫把騎行、改裝監查、頭盔檢測、視訊摘要、闖紅燈檢測等功能。大部分功能的演算法都已經做到基本實現，能夠在多場景和晴雨晝夜條件下有較好的效果。
• 我們的專案未能按照原計劃交付時間交付，我們對資料收集標註和訓練的時間估計有很大的失誤，加之其餘課程大作業、考試的壓力專案沒能按照原計劃交付，前後端的完成度不是太好，API尚未編寫，也未能完成前後端對接。
• 原計劃是我們的產品面向交管人員，使用者群體比較難接觸推廣，因此暫時沒有做到推廣使用。
  
   

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

• 由於我們的專案針對的使用者群體是交管人員，且我們的專案因為一些意外完成度不是那麼好，尚未對專案進行推廣。
• 我們認為現今非機動車數量急劇增加，就本校而言已是如此，監管困難是一個顯而易見的難題。我們的專案能夠在一定程度上解放部分人力，對交通監管方式的優化有所幫助，相信能有較好的接受度。接下來的衝刺，我們將完成專案，達成我們的預期目標。
  
   

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

• 經歷了alpha衝刺我們小組總結了以下幾個經驗教訓：
  • 團隊的分工需要精確且細化，做到每個成員都明確自己的目標，併為完成目標制定完成期限，否則參差不齊的完成度可能會影響後續的進度。
  • 對於團隊專案需要定義合理的緩衝區，避免時間估計失誤和“突發狀況”的出現導致延誤專案。
  • 團隊內部成員需要多進行互相交流，如果各做各的很容易導致出現無效的工作，溝通是團隊工作的做好的一個重要因素。
  • 需要制定符合實際的計劃，過於理想化的目標容易打壓信心，產生挫敗感。
    
     

2.2計劃

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

• 有。團隊專案釋出的時間比較早，對於整個專案的規劃有充足的時間來完成，做計劃的時間是很充足的。在開始開發前的選題、需求分析、還有對UML圖的繪製都是我們對專案有了更加清晰的認識。
  
   

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

• 在計劃階段，其實大家的分歧並不多，當面對組員之間的不同意見時，我們都是開會討論，當面解決、達成共識的，會討論出一個大家都滿意的方案。
  
   

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

• 原計劃的工作並沒有100%完成，只實現了60%左右。
• 原計劃是希望在Alpha衝刺階段實現前端和後端還有前後端的對接，但是現實是後端只實現了演算法部署，前端的介面中動態圖表也沒有解決，前後端對接部分還沒有實現。
• 原因：
  • 一是因為這段時間大家都太忙了，忙著對付各種考試，而且還有別的大作業，沒有100%的時間和精力能夠投入在專案上。
  • 二是這個專案開始的計劃預想比較複雜，實現起來也不太容易，對於前後端的考驗都很大，而大家又都是初學者，實現起來比較困難。
    
     

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

• 暫時沒有，感覺做的每一個工作都是有必要的、有用處的，每一個任務的完成都是一種經驗的積累，為後續進展做鋪墊的。
  
   

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

• 在專案真正開始前的計劃階段，我們對專案的各項任務分工做了大致的分配，但是對進行過程中將會遇到的各項任務不能夠做到完全的估計和衡量，隨著專案的進行和每次任務的釋出，我們對於每個部分要做什麼更加清晰明確，基本上對每一項的任務都做出了清楚的定義並制定了衡量的交付件。
  
   

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

• 專案總體的推進不太符合預期，起先剛開始alpha衝刺第一次開會做了個大致的規劃，計劃能在alpha衝刺將前後端都基本實現並能夠成功對接，但事實上直到alpha衝刺結束前後端也未能完成好，對接更是沒有完成，這是我們專案進度估計上的失誤。
• 問題大概是在於過於理想化地估計工作進度且分工未能做到精確細緻，因此有時會出現對自身工作目標不是太明確的情況。
• alpha衝刺的過程本身具有較大的工作量，專案的意外是和大家圖形學和數學建模的考試撞上了，時間管理成為我們的一大難題，我們需要花大把時間應對考試。
• 起初對資料收集和標註工作量的估計不準確導致後續才發現需要大把時間放在這方面。
• 當時未能估計到的風險即考試的來臨和資料收集標註的時間消耗，原因就在於從0開始收集、學習標註，還沒有給足我們的專案足夠的緩衝時間。
  
   

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

• 在計劃中預留的緩衝區比較短，是針對學習資料標註、訓練，前後端開發學習、API的編寫學習預留的一些時間，衝刺的過程中由於有圖形學和數學建模考試的插入，緩衝區的時間顯得少之又少，加上對資料收集、標註、訓練所用時間的錯誤估計，我們在前期的這些工作上花費了大量時間，本組成員光是收集和標資料就衝了alph衝刺的大半個階段。
• 預留的緩衝區還是有一定的作用，但由於估計失誤和沒將備考放在規劃的考慮範圍內，緩衝區的作用顯得不是很大，還是需要切實有效的規劃。
  
   

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

• 由於alpha衝刺大部分時間處於專案的“資料準備”階段，真正的前端、後端編寫搭建還沒能全部完成。接下來的階段本組將把其他課的大作業、備考等事宜納入專案計劃的考慮因素內，切實合理安排時間，在衝刺前先召開小組會議，細化分工。
• 由於有部分成員對前端或後端不太熟悉，將再給出1~2天時間進行緩衝學習，前後端並行工作，爭取預留2天時間完成前後端的對接。
• 工作量較大，預計需要小組成員共同“熬夜加班”努力完成。為使專案順利完成，儘可能在下一輪衝刺前儘早開始其他課的大作業，以便在截止期限時能夠在短時間內收尾。
  
   

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

• alpha衝刺時本組成員學習了怎麼收集資料、使用labelimg標註資料、使用yolov5訓練資料集，學習如何實現流量統計、目標識別、跟蹤、視訊摘要演算法實現、關鍵點檢測演算法實現脫把騎行檢測等。總體來說學習了“資料準備“的過程以及完成專案功能的各種演算法，並應用到專案當中。
• 由於對資料收集標註工作的錯誤估計和其他學科的考試安排，我們對任務的限定時間規劃不合理，換句話說”理想很美好，現實很殘酷“，還是對軟工作業有太理想化的幻想。
• 如果歷史再來重來一遍，我們會對專案有更切合實際的估計，雖然無法在alpha衝刺完成專案，但我們認為更加有條理的規劃更能推動專案有條不紊的進行。
  
   

2.3資源

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

• 沒有。
• 我們團隊最需要的是人力和時間資源，但由於面臨考試時間緊張，這些資源都處於比較缺乏的狀態。
• 大部分成員缺乏專案開發經驗，需要一邊摸索學習一邊推進專案進度，花費時間精力學習個人分工的所需技能等，從學習成果來觀察，網路上的學習資源是比較充足的。
  
   

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

• 各項任務所需時間和其他資源由具備開發經驗的成員初步得出，經所有成員討論後確定。有較高的精度。
  
   

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

• 測試的時間、人力資源較為充足，測試需要的軟體/硬體資源不足。對於那些不需要程式設計的資源在一定程度上低估難度了。
  
   

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

• 沒有。團隊每個人都處於最合適的位置，能夠各揚所長，盡最大能力交付自己分配到的工作。因此，每個人都處於最有效率的位置，很難讓別人替代。
  
   

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

• 對專案整體開發的時間管控做的不好，如果更好地掌握時間進度來分配任務，將更有利於專案的開發。
  
   

2.4變更管理

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

• 當專案任務發生變更時，能夠及時地將變更的訊息通過Q群，或者以開會的方式通知給每個相關的組員，確保專案順利進行。
  
   

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

• 我們對專案的需求，以及實現功能的難易程度進行討論，將專案核心基礎功能作為“必須實現”的功能，將附加的額外功能作為“推遲”的功能。
  
   

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

• 軟體的每一個核心功能都達到預期效果，並能夠提供給他人使用。
  
   

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

• 若出現變更，我們能夠制定應急計劃並進行溝通討論，確定完整的方案來應對計劃變更。
  
   

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

• 能有效地處理意料之外的工作請求，我們是將工作請求分配給合適的組員，確保能夠完成請求。
  
   

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

• 學到了根據組員情況合理分配任務，以及對可能的變更制定應急計劃和解決辦法。
• 如果歷史重來一遍，會在專案初期需求分析階段，將產品的功能以及需求進行明確的考慮和分析，對意料之外的情況進行防範，減少後續專案的完成中產生變更。
  
   

2.5設計/實現

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

• 設計工作是在Alpha階段衝刺的時候開始的。由我們的組長領導，團隊成員一起討論來完成。是大多數設計人都有空並能進行當面討論的時間，是合適的人選。
  
   

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

• 有，當遇到模稜兩可的情況時，我們將在團隊內進行投票表決，得票高的方案將會通過。
  
   

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

• 有運用單元測試，UML測試，等測試工具。
• 這些工具很有效，大大的提高了測試的效率，降低了手工測試的工作量。同時有的測試工具還有提供一些小問題的解決辦法，為我們減輕了很多負擔。
• 測試出現的大多問題都會記錄下來然後團隊討論解決方案。
  
   

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

• 在頁面、功能方面的站臺有所變動，由於所實現的功能有小小變更，以及介面佈局頁變得更清晰。原則上是要更新UML文件的，但由於時間問題，在基本確定並實現變更後再進行UML的改動。
  
   

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

• 後端提供介面以及前端實現資料大屏時呼叫介面並提供實時資料改變的部分bug最多。發現了資料的改動不能及時獲取
  
   

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

• 由組長進行人工檢視。對大多程式碼都嚴格執行，有起到一定的程式碼規範作用。
  
   

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

• 學到了在完成工作的過程中一定要做好溝通，一定要了解互相之間的進度，組長要調動起所有組員，知道所有人的進，有人進度拉下的話要及時去催和了解情況。
• 歷史重來一遍的話，我們會往後端部分及時催促下進度，並向前端部分提前做些頁面上佈局的改變，並且組內多進行一些技術上的溝通交流，不要一個人蠻幹。
  
   

2.6測試/釋出

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

• 團隊目前沒有特別具體明確的測試計劃，因為專案的完成度還沒到需要測試的那個階段。暫未進行正式的驗收測試。
  
   

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

• 目前暫時沒有，後續開始測試的時候可能會藉助部分測試工具。
  
   

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

• 由於暫未到測試階段，測量和跟蹤軟體的效能的方法還未確定，所有無法得知測試工作是否有用，以及該進行何種改進。
  
   

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

• 由於專案目前進度只完成了60％左右，暫未到釋出的階段，所有釋出的過程中會發現哪些意外問題暫時無法得知。
  
   

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

• 由於測試和釋出這兩個階段目前都還沒有進行到，所以可以從中學到什麼暫未知曉。如果歷史重來一遍，會盡量讓完成度儘可以到達可以進行這兩個階段的程度。
  
   

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

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

• 根據每個人的特長和興趣來確定。比如有的成員對於美工比較擅長，在團隊中就是來製作原型；有的成員有學習過前端，並且對前端比較感興趣，在團隊中就擔任前端製作的角色；有的成員對演算法比較感興趣，並且比較擅長程式設計，負責的工作就是專案後端和介面的部分。
• 通過這樣的方式每個人都充分發揮著自己的特長，並且做著自己感興趣的事，有助於工作效率更高。
  
   

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

• 由於本組人員充足，在每個部分都有大於等於兩個以上的成員負責。
• 成員間對於程式碼上的bug有進行互相探討，並且合理分工，互相分享學習資源，提高實現專案的效率。
• 對於原型上的設計，兩人分工收集素材，避免在素材收集上花費太多的時間，並且互相結合隊友的意見，設計出更加合理美觀的介面。
  
   

2.7.3當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝

• 黃新成：我感謝韋巨集麟對我的幫助，因為某個具體的事情：在我特別忙的時候幫我做ppt，陪我一起熬夜，挺過一段艱難的時光。
   
• 江舒穎：我感謝李曉芳對我的幫助，因為某個具體的事情：幫助我檢視前端介面在不同解析度是否能正常顯示。
   
• 李曉芳：我感謝江舒穎對我的幫助，因為某個具體的事情：她在專案初期就開始做準備工作，推動了ddl驅動型的我儘快開展工作，減緩了ddl帶來的壓力。
   
• 林雨欣：我感謝方靜怡對我的幫助，因為某個具體的事情：在重新繪製原型時起初存在差異較大的想法，在一番溝通和共同商討共享素材後求同存異。
   
• 方靜怡：我感謝林雨欣對我的幫助，因為某個具體的事情：在優化介面時提供了很多很不錯的idea，在介面構圖中也提供了不錯的方案。
   
• 張妍：我感謝方靜怡對我的幫助，因為某個具體的事情：她給出了前端大概需要的資料內容，使得我對於介面的學習方向更為明確。
   
• 林志鋒：我感謝林雨欣對我的幫助，因為某個具體的事情：在進行紅綠燈訓練集進行標註時，替我分擔了部分的標註工作，為我減輕了壓力。
   
• 汪鴻宇：我感謝韋巨集麟對我的幫助，因為某個具體的事情：我在除錯環境的時候遇到了很嚴重的問題，無論怎麼除錯都無法正常執行，後來我請教了韋巨集麟，他不僅幫我解決了問題，還細心地告訴我報錯原因。
   
• 韋巨集麟：我感謝黃新成對我的幫助，因為某個具體的事情：在我熬夜寫程式碼一直找不出bug時他鼓勵我早點休息不要再找bug了第二天和我一起找，太溫暖了。
   
• 鄒其清：我感謝黃新成對我的幫助，因為某個具體的事情: 合理分配任務，在我不知道要做什麼時，能夠給我指明所需要完成的任務。
  
   

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

• 學到了在團隊中分工必須要明確，一開始就需要分工，任務需要早點指派，每個人各盡其職，在每個部分成員應該增強溝通並且互相配合。
• 如果歷史重來一遍,將會把每個部分實現的時間控制好。有些部分可能需要某個部分完成之後才可以開始進行，這樣會使某一組停滯不前很被動。例如B組實現功能需要依賴A組完成某個部分，則可以A組完成某個小部分時B組就可以開始進行，提高效率，保證進度。
  
   

2.8總結

• 黃新成：
  • 很高興在每次會議大家都很積極地討論，有困難也一起解決，讓我感受到了團隊的凝聚力。
     
• 李曉芳：
  • 本次Alpha衝刺中，我們遇到了許多困難，尤其體現在時間管理上，考試壓力、學生活動等等事情無一不阻擾專案的推進。但讓我感動的是，團隊成員都很努力地完成自己的工作，團隊溝通做得也比較好。
     
• 林雨欣：
  • 前期經過開會安排後分配大家收集和標註資料，說實話標資料這個工作不算太難，主要是太苦力了，alpha衝刺就是全組人的爆肝標資料。另外讓我覺得alpha衝刺非常痛苦的地方在於衝刺時間和數學建模考試的衝突，時間管理也太難了（甚至幻想如果老師們可以交流一下輪流佈置大作業和安排考試就好了，但這隻可能是幻想），我沒有想到大三竟如此忙碌。由於團隊對新原型的需求加之考試壓力，感覺非常無奈，畢竟沒有原型前端也會因此耽誤進度，可以說太難受了。開會討論工作事宜，安排工作量和工作進度在考試的施壓下也是沒有全部完成，希望在Beta衝刺能夠把我們的專案做出來吧，雖然工作量比較大的，難怪說選柯老闆的學生都能造火箭了。
     
• 方靜怡：
  • 在這段時間中我收集了資料、標註了資料，還優化了原型介面，學習繪製了前端。標註資料的工作是相當繁瑣的，因為資料很多；在優化原型介面時也遇到了困難，對於 這個專案不太好想前端應該放哪些功能，整個網頁的構圖是怎麼樣的，好在最後終於能畫出來。然後開始加入前端的研究，但是在實現動態統計圖的時候遇到了困難，還沒找到解決辦法。總的來說，這段時間，有很多事情堆在一起，使本就少的時間變得更少，拖慢了專案的進展，但還是能完成部分任務的。
     
• 江舒穎：
  • 關於前端頁面構建的過程中，由於vue框架的版本問題有很多bug網上都沒有很好的解決方法，只能嘗試幾種方法，找到對應的資料夾進性配置和修改。關於元件的相對位置與絕對位置和網頁的自適應問題對我而言算是前端工作中的兩個很重要的問題了，所以在寫程式碼時應當先解決這兩個問題。
     
• 林志鋒：
  • 在經歷了個人程式設計和結對程式設計之後，我以為團隊程式設計可以讓自己過的輕鬆一點，沒想到工作量還是那麼大，加上還要數學建模考試，天天覆習，導致自己對於自己理想的目標的完成度搞得很低，因此感到十分慚愧，慚愧不僅在於對於演算法和功能沒有進行太大的優化，還在於前幾次團隊任務中，沒有幫助好組長，多多建言獻策，組長一個人可能力有不逮，於是我們Alpha衝刺的規劃就比較散亂，最後也沒有完成我們理想的目標，希望在Beta衝刺中能夠改變這個現象，大家精誠合作，最後做出一個令人滿意的專案出來。
     
• 張妍：
  • 本次Alpha衝刺並沒有能很好的完成分配的任務，介面編寫的學習程度仍然還不夠編寫出我們軟體需要的介面，還需要繼續學習。但還是有很多收穫的，比如學會了如何使用labelimg標註資料集，對於介面有了更多的認識，對於介面編寫了也有了一定的瞭解，嘗試寫了幾個介面，可以實現文字的傳輸。我們軟體需要的介面需要帶有的功能是傳輸視訊，目前暫未編寫成功。
     
• 汪鴻宇：
  • 這次Alpha衝刺，我深深的感受到了學習的時間規劃非常關鍵，只有時間規劃好，才能更好的完成任務。更好的時間規劃意味著更好的時間利用率，也就意味著我能學到更多的知識，完成更多的任務。
     
• 韋巨集麟：
  • 在編程式碼前要做好設計、理清思路，如果沒有進行全域性的思考就直接打程式碼，速度一定不會快並且還會亂。遇到不會的地方要及時向隊友尋求合作，自己一個人干時遇到的錯誤可能隊友早就遇到過並且可以解決了，有隊友的幫助的話效率會高很多。
     
• 鄒其清：
  • 這次的alpha衝刺的階段收穫了很多，如能夠熟練使用labelimg工具對資料集進行標註，瞭解介面基本內容，學習了前後端整合的基本知識等等，但是由於以前沒有接觸過相關內容，並且時間不夠充足，因此重新開始學習花費的時間比較長，有的內容不能很好的理解，需要請教組內其他成員或上網查詢。對於接下來的beta衝刺，需要合理分配時間，和組員共同實現剩餘任務，完成專案內容。