考前自救題庫 Alpha階段事後分析

解決問題是：幫助同學們高效的進行包括但不限於航概課程的背題，日常高效的進行學習。定義的較為清楚，有清晰的描述，詳見功能規格說明。

達到目標了，原計畫alpha階段的功能已經全部完成上線，按照原計畫時間交付了，註冊使用者數量達到了50，日活使用者達到10人以上，達到了原計畫的使用者數量。

實際上不是很一致，使用者高頻使用我們的核心基本功能，但是對我們的一些特色功能使用頻率並不高。

我們缺乏前期進行需求調研，導致我們的特色功能使用頻率較低，並且缺少安全性設計。

實際上我們覺得計畫的時間略少，課程組給予的時間太少，並且我們也缺乏相關經驗。

共同商議，pm(組長)拍板。

都做完了。

在專案前期，前端人員試圖本地執行後端進行測試，花了一些時間折騰後端環境，但是實際上後端馬上就部署到了伺服器上，並不需要前端人員本地部署。

開始時劃分的任務顆粒度太大，很難確定具體的交付件。後面開發階段對任務進行不斷細化之後，就有一些明確的交付件，例如按鈕功能是否正常，頁面是否完善，跳轉是否正常。

基本按照計畫，沒有出現什麼意外。

留下緩衝區了，有作用，因為工作安排留了緩衝區，調整了工作進度和工作節奏，課程組給了一周的時間進行測試與發布，我們再這個階段也進行了前端乙個頁面的開發工作。

調整任務劃分細粒度，組會的時候每個人要展示成果，讓每次組會都給人以ddl的壓力。

我們希望對任務進行更嚴格的ddl要求以達到提高開發效率的效果，有一組的方法非常好——線下集中開發，但這個方法並不適用於我們組這樣的複雜情況，每個人的時間安排都很緊，難以協調統一時間。

伺服器資源充足，但是人力*技術資源與時間資源不是很充足。

佛系開發，估計的精度較差。

測試的時候硬體資源與人力資源足夠。我們低估了美工難度，我們沒有專門留出專門的介面設計人員。

前端美工，介面設計，beta階段盡量均衡工作，均衡任務顆粒度。

知道，會在群裡或者是開會時發布。

技術難度學習成本過高的功能且非核心功能的可以推遲，核心功能與特色功能必須實現。

基本條件就是可以正常使用，無明顯bug，前端頁面可以正常跳轉，可以給後端傳送正確的訊息，後端處理請求不報異常，返回正確的資訊。

可以能，alpha由於時間緊，經常設計和開發一起進行，在需求和功能有所改變或者增加時，開發人員往往都可以快速進行修改與增加。

在進行的一些規範或者介面文件修改時，以及一些私聊決定的事情要在群裡再發一遍，通知到每個人。

功能設計在開發之前，介面設計與功能細節實在開發過程中設計的，有pm完成，是合適的時間合適的人。

有，討論解決。

沒有使用單元測試，用postman進行後端的測試，沒有使用uml。alpha階段功能簡單時間緊急，所以就沒有採用單元測試以及uml。

設計時間的功能出bug比較多，因為當時有兩個data類，本地獲取的data類和從資料庫中讀寫的data類使用較為混亂，時間之間的比較也容易出問題，由於對j**a時間比較的理解不是很到位。發布之後沒有重要的bug。

複審：前後端負責人檢查其他人寫的**，前端執行單檔案元件規範，介面呼叫與vuex的使用都有相應的規範文件，縮排格式按照編譯器標準格式。

在開發過程中遇到的不確定的問題一定要及時測試及時解決，拖到最後解決會越發困難。

對於簡單的場景有基本的測試計畫，我們的**功能比較簡單，每個人都會對自己寫的部分進行單獨的測試。

在上線之前的每次打包我們都一起進行了測試，每個人都盡量對所有功能以及情況都使用了一遍。

後端使用postman進行測試。團隊暫未使用自動化測試，預計beta階段的改進：使用cicd進行自動化單元測試。

主要是通過伺服器的響應速度來評判軟體的效能，壓力測試相關資訊已經包含在測試文件裡，測試工作有用，通過測試工作我們發現對於我們的目標使用者量，我們的伺服器完全可以經受得住考驗，在不配置負載均衡的情況下也不會有很大問題。

沒有測試上我們做的還不夠好，缺乏單元測試，以及自動化的回歸測試。改進：將自動化單元測試加入cicd自動執行。

在某方面有經驗的同學就完成該方面的工作，人盡其才。

有，前端有經驗的同學，積極幫助其他同學快速學習和入手專案

例會上進行相關討論，並且由組長決定。

管理級規範

安全性問題，設計問題，強化階段檢查機制。

盡早、持續交付，可持續開發，業務人員和開發人員在專案開發過程中每天共同工作。

加強前期調研，功能設計不再以腦補為依託

做好階段性檢查工作，嚴格控制進度。

issue劃分細粒度仍需加強控制。

加強測試，去除低效的手動測試，將單元測試整合進cicd自動進行回歸測試。