Alpha階段事后分析
一、設想和目標
1、我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
解決問題是：幫助同學們高效的進行包括但不限於航概課程的背題，日常高效的進行學習。定義的較為清楚，有清晰的描述，詳見功能規格說明。
2、我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)
達到目標了，原計划alpha階段的功能已經全部完成上線，按照原計划時間交付了，注冊用戶數量達到了50，日活用戶達到10人以上，達到了原計划的用戶數量。
3、用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么?
實際上不是很一致，用戶高頻使用我們的核心基本功能，但是對我們的一些特色功能使用頻率並不高。
4、有什么經驗教訓? 如果歷史重來一遍,我們會做什么改進?
我們缺乏前期進行需求調研，導致我們的特色功能使用頻率較低，並且缺少安全性設計。
二、計划
1. 是否有充足的時間來做計划?
實際上我們覺得計划的時間略少，課程組給予的時間太少，並且我們也缺乏相關經驗。
2. 團隊在計划階段是如何解決同事們對於計划的不同意見的？
共同商議，pm(組長)拍板。
3.你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
都做完了。
4.有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
在項目前期，前端人員試圖本地運行后端進行測試，花了一些時間折騰后端環境，但是實際上后端馬上就部署到了服務器上，並不需要前端人員本地部署。
5. 是否每一項任務都有清楚定義和衡量的交付件?
開始時划分的任務顆粒度太大，很難確定具體的交付件。后面開發階段對任務進行不斷細化之后，就有一些明確的交付件，例如按鈕功能是否正常，頁面是否完善，跳轉是否正常。
6. 是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
基本按照計划，沒有出現什么意外。
7. 在計划中有沒有留下緩沖區，緩沖區有作用么?
留下緩沖區了，有作用，因為工作安排留了緩沖區，調整了工作進度和工作節奏，課程組給了一周的 時間進行測試與發布，我們再這個階段也進行了前端一個頁面的開發工作。
8. 將來的計划會做什么修改？（例如：緩沖區的定義，加班）
調整任務划分細粒度，組會的時候每個人要展示成果，讓每次組會都給人以ddl的壓力。
9.我們學到了什么? 如果歷史重來一遍,我們會做什么改進?
我們希望對任務進行更嚴格的ddl要求以達到提高開發效率的效果，有一組的方法非常好——線下集中開發，但這個方法並不適用於我們組這樣的復雜情況，每個人的時間安排都很緊，難以協調統一時間。
三、資源
1. 我們有足夠的資源來完成各項任務么?
服務器資源充足，但是人力*技術資源與時間資源不是很充足。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
佛系開發，估計的精度較差。
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試的時候硬件資源與人力資源足夠。我們低估了美工難度，我們沒有專門留出專門的界面設計人員。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
有，如果cy承擔更多的后端功能細節開發可能效率更高，但是cy同時承擔了pm的工作，所以在考慮下一階段更換pm，進行工作調整。
5.有什么經驗教訓? 如果歷史重來一遍,我們會做什么改進?
前端美工，界面設計，beta階段盡量均衡工作，均衡任務顆粒度。
四、變更管理
1. 每個相關的員工都及時知道了變更的消息?
知道，會在群里或者是開會時發布。
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
技術難度學習成本過高的功能且非核心功能的可以推遲，核心功能與特色功能必須實現。
3. 項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
基本條件就是可以正常使用，無明顯bug，前端頁面可以正常跳轉，可以給后端發送正確的消息，后端處理請求不報異常，返回正確的信息。
4. 對於可能的變更是否能制定應急計划?
可以
5. 員工是否能夠有效地處理意料之外的工作請求？
能，alpha由於時間緊，經常設計和開發一起進行，在需求和功能有所改變或者增加時，開發人員往往都可以快速進行修改與增加。
6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
在進行的一些規范或者接口文檔修改時，以及一些私聊決定的事情要在群里再發一遍，通知到每個人。
五、設計/實現
1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
功能設計在開發之前，接口設計與功能細節實在開發過程中設計的，有pm完成，是合適的時間合適的人。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有，討論解決。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
沒有使用單元測試，用postman進行后端的測試，沒有使用uml。alpha階段功能簡單時間緊急，所以就沒有采用單元測試以及uml。
4. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
設計時間的功能出bug比較多，因為當時有兩個data類，本地獲取的data類和從數據庫中讀寫的data類使用較為混亂，時間之間的比較也容易出問題，由於對java時間比較的理解不是很到位。發布之后沒有重要的bug。
5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
復審：前后端負責人檢查其他人寫的代碼，前端執行單文件組件規范，接口調用與vuex的使用都有相應的規范文檔，縮進格式按照編譯器標准格式。
6.我們學到了什么?如果歷史重來一遍,我們會做什么改進？
在開發過程中遇到的不確定的問題一定要及時測試及時解決，拖到最后解決會越發困難。
六、測試/發布
1. 團隊是否有一個測試計划？為什么沒有？
對於簡單的場景有基本的測試計划，我們的代碼功能比較簡單，每個人都會對自己寫的部分進行單獨的測試。
2. 是否進行了正式的驗收測試？
在上線之前的每次打包我們都一起進行了測試，每個人都盡量對所有功能以及情況都使用了一遍。
3. 團隊是否有測試工具來幫助測試？很多團隊用大量低效率的手動測試，請提出改進計划：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。
后端使用postman進行測試。團隊暫未使用自動化測試，預計beta階段的改進：使用cicd進行自動化單元測試。
4. 團隊是如何測量並跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
主要是通過服務器的響應速度來評判軟件的效能，壓力測試相關信息已經包含在測試文檔里，測試工作有用，通過測試工作我們發現對於我們的目標用戶量，我們的服務器完全可以經受得住考驗，在不配置負載均衡的情況下也不會有很大問題。
5. 在發布的過程中發現了哪些意外問題？
沒有
6.我們學到了什么?如果重來一遍, 我們會做什么改進
測試上我們做的還不夠好，缺乏單元測試，以及自動化的回歸測試。改進：將自動化單元測試加入cicd自動執行。
七、團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
在某方面有經驗的同學就完成該方面的工作，人盡其才。
2. 團隊成員之間有互相幫助么？
有，前端有經驗的同學，積極幫助其他同學快速學習和入手項目
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
例會上進行相關討論，並且由組長決定。
八、總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
管理級
你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
規范
你覺得目前最需要改進的一個方面是什么?
安全性問題，設計問題，強化階段檢查機制。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
盡早、持續交付，可持續開發，業務人員和開發人員在項目開發過程中每天共同工作。
什么是在下個階段要改進的地方？越具體越好。
- 加強前期調研，功能設計不再以腦補為依托
- 做好階段性檢查工作，嚴格控制進度。
- issue划分細粒度仍需加強控制。
- 加強測試，去除低效的手動測試，將單元測試集成進cicd自動進行回歸測試。
