一、設想和目標
1.做這個項目的背景、意義是什么？要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
主要是提供一個一站式通知發布、接收平台以及簡單的備忘錄功能，詳見需求規格說明書。
2.項目達到目標了么（原計划的功能做到了幾個？在原計划之上是否有所拓展)
原計划的通知訂閱、發布，群組管理、備忘錄等主要模塊的功能基本都已實現。前端由於技術水平和沖刺時間所限，沒有做更多拓展，只是完善了錯誤提示。后端用了多個微服務和redis緩存數據庫，算是一種拓展。
3.和alpha階段相比，團隊軟件工程的質量提高了么？在什么地方有提高，具體提高了多少，如何衡量的？
在任務管理和進度跟蹤上有提高，通過吸取alpha階段使用看板的經驗，本次沖刺開始前大家都有在看板上填寫好自己的任務卡片，生成的燃盡圖也更符合預期。以及每天通過共享文檔收集組員的工作進度和工作時長，統計貢獻度起來更加輕松和准確。
4.設想用戶量是多少, 用戶對重要功能的接受程度和我們事先的預想一致么?
初期設想的用戶量不多，可能兩三百人左右。因為我們的項目核心功能就通知的訂閱、發布以及備忘錄，比較簡單，所以用戶基本能接受。
5.有什么經驗教訓? 如果歷史重來一遍，我們會做什么改進?
經驗教訓是功能的實現不能拘泥於原型，界面布局根據使用的組件庫以及要實現的功能，可以靈活調整，終極目標還是提升用戶體驗。
二、計划
1.和alpha階段相比，每天是否時間規划的更好?
每名隊員在開始項目前，為沖刺不同階段指定了相應計划以及時間。同時每天有相應插件統計時間和記錄。可以有效跟蹤各成員時間。
2.團隊在beta階段是如何解決隊友對於計划的不同意見的？
這次計划大家都按自己既定計划進行，沒有產生分歧。
3.你們原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
前端群通知管理和群成員管理在同一個頁面，業務邏輯和布局相對復雜一些，beta沖刺期限內來不及完成，但加班完成了。
4.是否每一項任務都有清楚定義和衡量的交付件?
前端模塊功能上能正確獲取數據並展示，頁面布局上在調整窗口大小時能達到一定限度的響應式的效果。
后端由於比較完善，所以對於每一項交付任務定義和衡量較為容易，交付過程輕松。
5.項目是否出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
沒有遇到什么大的意外。
6.在計划中有沒有留下緩沖時間，緩沖時間有作用么?
前端稍微加了兩天班來完善一些細節。
7.我們學到了什么? 如果重來一遍, 我們會做什么改進?
如果能重來會直接按、划分好具體任務項來分配工作，而不是先按功能模塊分，每個人再自己分任務項。
三、資源
1.有足夠的資源（可以是時間、開發資源等）來完成各項任務么?
前端時間不太夠，后端時間是足夠的。
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
前期在看板卡片上填寫預期工作量，使用wakatime插件統計編碼時間，每天開會時填寫到表格。精度比alpha階段靠人工估計要提高了很多。
根據Alpha的經驗來進行估計，大多數任務的實際花費時間少於預計時間。一方面可能由於Alpha階段項目完成度較高，使得部分任務花費時間較少，另一方面可能是組員設置的任務較為簡單。
3.和alpha階段相比，測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
前端時間不太夠，按模塊分配工作但各模塊工作量不同，導致每個人完成任務的時間點不統一。本次對於美工（頁面布局）雖然沒有低估難度，但仍然花了比較多的時間。
后端有了Alpha做的單元測試鋪墊，新功能可以很快驗證和測試。
4.變更的組員工作如何？如果未變更是否項目完成效率會更高？變更的組員學到了什么？對於可能的變更是否能制定應急計划?
新組員開發過程主要是以做中學加上其他人員幫助，同時后端給出清晰的開發流程，使得組員能很快適應，同時由於Alpha階段后端較為完善，某些復雜工作對於新組員是透明的。對於完成效率來說如果未變更自然會更高，但是由於后端比較完善，因此體現出來不會是很大差別。
5.有沒有感到某個成員做的事情可以讓別人來做（更有效率）?有什么經驗教訓? 如果歷史重來一遍, 你們會做什么改進?
換人雖然對后端那邊整體進度的影響不是很大，但如果沒有換人這個環節，被換的組員本人以及其他后端組員的負擔也會小一些。如果重來會勸說團隊中參與度低的組員主動申請換組。
四、設計/實現
1.項目是否經歷重構？為什么需要重構？
對於前端，在具體規划任務時發現很多功能都還不完整，所以是以完善功能為主，沒有更多的時間去考慮重構。
對於后端系統進行一定構架重構，從單體應用到微服務式的架構。在原來后端架構中，個別功能的變更就使得整個項目需要重新編譯、部署，各個業務都在一個應用中處理。通過將按業務划分微服務，各業務模塊可以獨立升級，並且一個服務出現錯誤也不會導致整個系統崩潰。
2.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的UML文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新UML文檔？
單元測試，有效，可以有效追蹤低對於功能的修改產生潛在影響。UML由於新增功能需要更新文檔內容。
3.什么功能產生的Bug最多，為什么我們在設計/開發的時候沒有想到這些情況?
前端頁面數據綁定如果綁定的是有返回值的方法，就會出現該方法在后台被一秒數十次調用的情況，原因是我們對Angular的了解還不夠深入。
4.代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
前端使用ng lint命令檢查后提交，后端有用阿里巴巴代碼規范插件等。
5.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
一定要跟組員強調提交的規范性和嚴謹性，不能因為是warning而不是error就選擇忽略。以及順手開啟IDEA內置的提交代碼前格式化代碼的選項，這樣即使每個人的代碼風格有不同，也能基本保證項目整體代碼風格的統一。
五、測試/發布
1.和alpha階段相比，測試工作有提高嗎？在哪些地方提高了？
前端還是采用人工來測試。后端測試工作需要應為微服務的引入而經行特殊的測試，因此通過構造相應微服務的樁模塊模擬對遠程微服務的調用。而通過API接口測試來實現對微服務之間調用的測試。
2.團隊是否有一個測試計划？
后端有比較完整的測試計划。前端工程模塊化程度較高，每名組員先負責自己模塊的測試，確定沒問題了才提交。在沖刺結束后也有安排互相測試模塊。
3.團隊是否有測試工具來幫助測試？
前端雖然Angular有集成測試工具，但限於開發水平，幾天的沖刺時間還是只能滿足功能的實現，所以沒有使用。
后端新引入了Mockito，為微服務測試打樁。
4.團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
前端：有通過瀏覽器內置的開發者工具來監測網絡請求、方法調用等，但對性能優化的幫助不是太大。如果改進的話應該要使用類似后端JProfile那樣的更專業的工具。
后端：通過單元測試來測試代碼是否能預期經行。這些測試工作可以檢驗新引入功能對原有功能影響。測試框架有時候不能很好的表現測試的目的，可能需要使用一些測試模擬真實環境測試的程序。
5.在發布的過程中發現了哪些意外問題？
部署的雲服務器是用的是很便宜的學生配置（單核，2G RAM），在測試訪問時有遇到卡頓等問題。
6.我們學到了什么? 如果重來一遍, 我們會做什么改進?
還是應該先保證功能的實現再考慮性能優化，穩扎穩打，否則可能適得其反。
六、團隊的角色，管理，合作
1.團隊的每個角色是如何確定的，是不是人盡其才？
每名組員的角色與alpha沖刺時是相同的。換入的新組員因為原來是做Android，對Java更熟悉些，由后端大佬帶着參與后端的完善和測試，也算是人盡其才。
2.團隊成員之間有互相幫助么？
和之前一樣，開發過程中遇到困難會在群里求助和討論。例如后端遷移到微服務后接口文檔和前端請求URL都發生了變化，后端組員專門錄屏給前端組員講解新后端項目的配置和接口文檔的使用，可以說是組內互助的典范了。
3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
一般直接私聊溝通，有需要大家一起討論的，就找相關組員方便的時間開語音或視頻分享來討論。
七、總結
1.組員們自我總結
- 葉博寧：在本次beta沖刺中我有以下收獲：1.在前端上的編碼能力得到了鍛煉，但對Angular框架的了解還是很皮毛，對一些需求的實現比較依賴現成組件；2.團隊管理和協作能力有一些提升，主要體現在對看板的利用更加有效。但在工作進度把控上還是常常缺乏緊迫感，一些時候反而是志峰在督促我去推進工作。
- 沈志峰：通過本次沖刺也意識到自己在相關領域的不足，同時工作中容易產生遺漏。在項目管理過程中還有很多需要向組長學習。
- 趙偉男：熟悉了微服務的相關概念和使用方法；更加深入地了解SpringBoot的郵件服務和文件上傳功能模塊；積累了團隊合作開發、團隊成員溝通的寶貴經驗，對軟件開發的整個流程也有了完整的體驗。
- 陳賜：通過本次沖刺學到了很多關於框架的知識，也體會到了良好的項目管理給開發帶來了很大幫助
- 鄭瀾：通過本次沖刺不僅在時間管理上有所收獲，學會了更好地規划自己的時間；同時也理解到了項目開發過程中不是把功能和界面做出來就完成了，后期還要進行不斷優化以改善用戶體驗。
- 岳逾先：通過本次沖刺讓自己得到了鍛煉，對前端和開發一個項目有了新的認識。
- 張必潤：在本次沖刺中意識到了自己對移動端適配還有很多不了解，因時間原因本次沖刺也沒有完善移端適配，對於這個會再進行學習和實踐。
2.你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
beta階段相比alpha階段有所提升，可以介於二級（管理級）和三級（定義級）之間。
3.你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
我覺得在規范階段，因為整個開發還是基於原型中設計的功能來實現，沒有條件做更多的突破。
八、提高軟件工程的質量
1.代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？
代碼質量管理通過平時邊跑邊測，保障每一個功能模塊正確性，而不是寫完某個功能模塊才來一次性測試。代碼通過規范檢查插件進行審核，同時后端有一套規范進行約束。
還是要強化組員在代碼規范上的自覺意識，即使自己敲代碼不注意空格、空行、換行，在提交前用快捷鍵順手格式化一下，對其他看代碼的組員來說也會友好很多。
2.整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？
前端把一些經常重復出現的組件屬性封裝成類來精簡代碼。比如table經常用到的data、pageSize、pageIndex、total、loading等屬性，封裝成一個TableParamModel類，只需要一行就可以初始化好所有的類屬性。
后端通過業務划分方法，分離成幾個微服務。但微服務內架構設計還是遵循原有的結構。通過按業務划分，將原本單體應用分成可獨立升級的服務模塊，使得各業務之間解耦，同時編譯部署更加獨立。
3.其它軟件工具的應用，應該如何提高？
應該多向原本代碼水平較高的同學學習其他輔助工具的使用經驗，比如wakatime編碼時間統計工具就是從被換出的一凡那里學習來的，在實際沖刺中對每天統計工作量起到很大幫助。
4.項目管理有哪些具體的提高？
對看板的使用更加熟練，沖刺開始前就督促組員添加好卡片並估計工作量，最終生成的燃盡圖比alpha沖刺時的更接近理想的一條斜線。
5.項目文檔的質量如何提高？
組員一起討論明確了每日任務文檔的收集項，將收集的數據直接用於編寫每日沖刺記錄博客，可以省時省力。
6.對於人的領導和管理， 有什么具體可以改進的地方？
不論是遇到需求變更還是bug，保持理性平和的溝通都是非常重要的。
九、項目展示
