一、專案總結與反思
1. 我們的軟體要解決什麼問題？是否定義得很清楚？
我們軟體主要解決校內人士在拾取到貴重物品時難以尋得失主的問題。我們對該專案有著清楚的定義，專注於失物招領功能
2. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼？我們離目標更近了麼？
使用者量在Alpha階段肯定沒有達到預期，畢竟功能沒有完全完善，但是使用者對重要功能的接受程度和我們事先的預想一致，離目標更近一步。
3. 和上一個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？
有所提高，主要在於程式碼的規範，功能的完善。
4. 我們達到目標了麼？
是
二、計劃
1. 是否有充足的時間來做計劃？
是，在每個任務前一週之內能夠有充足時間進行規劃
2. 計劃階段如何解決不同意見？
主要透過對內之間相互溝通，PM透過詢問對內個人意見進行統籌
3. 原計劃的工作是否最後都做完了？
是
4. 發現做了不需要或沒價值的事嗎？
剛開始的目標不應該設定過於困難的任務
5. 每一項任務是否有清楚定義和衡量的交付件？
是，任務都在leangoo或者專案需求說明書內定義
6. 專案過程是否按照計劃進行？
是
三、資源
1. 是否有足夠的資源來完成各項任務？
是，時間充足，並且有一定的開發經驗
2. 時間和其他資源的估計精度？
任務分解，經驗預估，精度較高。
3. 測試資源是否足夠？
測試人員、時間都較為充足
4. 工作效率提升建議？
在開發前應該每個人達到共識，認識到軟體的執行方式，框架應搭建完善
四、變更管理
1. 變更通知是否及時？
是，微信群內會準時通知
2. 如何決定“推遲”和“必須實現”的功能？
推遲：對於與主要功能無關的，暫時沒有能力完成的功能
必須實現：會影響主要功能，可能導致系統崩潰的功能
3. 出口條件是否清晰定義？
是
五、設計/實現
1. 設計工作的時機？
由任務釋出者決定，給出最後期限
2. 設計碰到模稜兩可的情況如何解決？
對內討論決定，如果意見有所分歧，由PM代為決定
3. 使用了哪些工具來幫助設計和實現？
前端技術：HTML, CSS, JavaScript
後端技術：Java (Spring Boot),Node.js 等。
資料庫：MySQL
4. 什麼功能產生的Bug最多？
關於失物增刪改查的Bug較多
5. 程式碼複審如何進行？
由測試人員進行復審
六、測試/釋出
是否有測試計劃？
是
是否進行了正式的驗收測試？
是，在軟體開發的最後階段，進行了正式的驗收測試。
測試工具的應用？
進行了效能測試，使用了效能測試工具用於驗證系統在高負載下的表現。
進行缺陷跟蹤，使用了缺陷跟蹤工具，用於記錄、跟蹤和管理發現的缺陷。
測量並跟蹤軟體效能？
計算響應時間和吞吐量，透過監控工具跟蹤系統響應時間、請求處理能力等。
測試了資源利用率，包括CPU、記憶體、網路頻寬等指標的監控，確保軟體在執行時不會過度消耗資源。
釋出過程中發現的問題？
開發、測試和生產環境的差異可能導致軟體在某些環境下無法正常執行。
在負載增加的情況下，可能會發現效能下降或資源瓶頸，影響系統的可用性。
七、團隊的角色、管理與合作
角色確定是否合理？
是，對內成員分為PM、後端、前端三大職責，每個人各司其職，能有保證專案的不同方面都能夠被照顧
團隊成員之間是否有互相幫助？
是，當某位團隊成員臨時有事時其餘人員能夠及時頂上完成任務
解決專案管理和合作問題的方式？
透過隊內溝通協商，管理方面由PM負責統籌各自的任務，確保合作正常
八、總結與展望
當前狀態屬於哪個檔次？
當前狀態：我們認為團隊目前處於CMM/CMMI的“規範”階段，各項工作已經逐步規範化。
最需要改進的一個方面？
程式碼開發階段需要更加規範，比如框架的搭建，前後端的銜接
對照敏捷開發的原則，做得最好的是哪些？
團隊協作方面，隊員溝通及時，發現問題速度迅速；
專案開發方面，隊員能夠很好的完成要求
下一階段如何提高軟體工程的質量？
透過完善沒有實現的功能，同時加強程式碼的規範性