團隊計畫的任務都已經完成，計畫內容可以檢視我們的github issue，關閉的issue都是已經完成的任務計畫。根據前幾次部落格的燃盡圖也可以看出，我們團隊在alpha階段最開始進度慢於預期，主要是因為團隊成員對於前端頁面開發都不熟悉，邊學邊開發需要消耗大量時間，但是在alpha階段的後期我們團隊還是把進度肝上來，整體進度符合預期。
在alpha階段我們沒有較大的設計變更，大部分任務還是按照一開始發布的issue完成即可。這可能也是我們組嚴格按照敏捷開發的思路，細分任務issue，即使有些地方需要修改也不會波及大量其他模組程式的開發。我們的組員對於新需求都有著很快的反應處理能力。當然變更管理我們也有需要反思的地方，我們的「出口條件」非常模糊，這也造成了後面一些考慮不周到的網路安全問題。
首先是團隊內的人力資源，我們團隊不乏優秀的後端大佬，但是對前端和測試熟練的同學較少，但是大家在alpha階段還是克服了自身的知識經驗短板及時完成了所有的任務。機器資源上還是配置得很順利的，alpha階段我們使用nginx+uwgi+django在課程提供的華為雲伺服器上成功部署了服務。
對於各項任務的時間與資源的管理，我們是按照任務的難易度來管理的，在alpha階段也遇到了很多問題。在軟體開發過程中，任務所需要的時間有些時候並不完全和任務的難易度有關，也和組員的技術熟練度有關，我們一般有限將任務分配給對這個技術最熟練的組員，再從他實際操作實際出發來管理時間資源。
測試嚴格地說是一項永遠不會結束的工作。在alpha階段我們的測試人員是流動的，例如後期測試的李青陽同學在前期參加頁面邏輯設計等等，這主要是考慮到alpha階段是乙個從無到有的過程，測試也就順理成章地變成乙個前期任務很少後期任務很多地工作。另一方面我們在alpha階段發布**後，發現安全測試至關重要，包括ddos、惡意post、mysql注入等攻擊都要考慮在內，這也為我們beta階段的軟體工程開發提出了全新的信安需求。
Alpha階段事後分析
我們軟體要解決的問題在我們的專案功能規格書中定義得很清楚。對典型使用者和典型場景也有比較清晰的描述。但是問題在於我們在並沒有優先去實現課程評價 的最核心功能，所有工作任務的優先順序並沒有定義好。我們團隊花費了充足的時間來計畫每個任務，具體在專案管理可見。我們預估了每個專案的完成所需時間。我們alph...
考前自救題庫 Alpha階段事後分析
解決問題是 幫助同學們高效的進行包括但不限於航概課程的背題，日常高效的進行學習。定義的較為清楚，有清晰的描述，詳見功能規格說明。達到目標了，原計畫alpha階段的功能已經全部完成上線，按照原計畫時間交付了，註冊使用者數量達到了50，日活使用者達到10人以上，達到了原計畫的使用者數量。實際上不是很一致...
AiApe問答機械人Alpha階段事後分析
專案開發速度看似遠超出預期，但實際並不。並不是說issues沒有按時完成，而是缺少了應用測試的一步。可以理解為 骨架都有了，但血和肉太少。這一點是我作為pm有所失職的地方，我並沒有正確的估計任務量，或是正確的安排issue。也正是因為前期專注於搭建骨架，我們低估了新增血和肉的成本。這一點集中體現於 ...