事後諸葛亮分析
設想和目标
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
軟體要滿足的是低年級學生練習四則運算的需求。需求定義得不太清楚，中途還經曆了一次變更，仍然需要在這方面進行改進。
2. 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃功能并未完全實作（排行榜），此次任務，花了較多時間磨合，是以進度較慢，故傳遞時間有延誤。
3. 和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
經過這次的項目，團隊成員對軟體工程的了解又進了一步，主要是在團隊協作以及測試方面有進步，從完全不了解到入門水準。
4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
在使用者量上我們并未取得較大進步。但是我們希望下一個版本的四則運算能夠取得較大進步，新版本将整合新模式以及新注冊方式，項目也将轉入閉源。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
計劃
1. 是否有充足的時間來做計劃?
并沒有，花了太少時間來進行計劃，導緻後期很多問題的發生。
2. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
投票，少數服從多數
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
還沒有，主要是因為時間不夠。
5. 是否每一項任務都有清楚定義和衡量的傳遞件?
沒有，仍需改進。
6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
項目途中組員認為軟體需求定義不清晰，中途讨論修改了軟體需求，并對軟體進行了較大改動。
資源
1. 我們有足夠的資源來完成各項任務麼?
我們最缺的資源就是時間以及注意力。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
資源的配置設定主要是靠空想來決定的，精度極其不準确。
變更管理
1. 每個相關的員工都及時知道了變更的消息?
是的，通知非常及時。
2. 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
不影響基本功能的運作的功能皆可推遲。
3. 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
沒有考慮到。
4. 對于可能的變更是否能制定應急計劃?
有，加班
測試/釋出
1. 團隊是否有一個測試計劃？為什麼沒有？
有，流程清晰。
2. 是否進行了正式的驗收測試？
是的。
3. 團隊是否有測試工具來幫助測試？
有，使用mocha來進行測試。
團隊的角色，管理，合作
1. 團隊的每個角色是如何确定的，是不是人盡其才？
根據各自擅長方向來決定的，人盡其才。
2. 團隊成員之間有互相幫助麼？
有的，溝通效率較高。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
通過小型會議來解決管理問題。
| 名字 | 角色 | 貢獻分 | 可驗證的貢獻 |
| 塗家瑜 | 組長 | 20 | 後端代碼 |
| 陳宏輝 | 隊員 | 40 | 前端代碼、文檔 |
| 張新磊 | 資料庫 | ||
| 姚燕彬 | 測試 | ||