BugPhobia開發終結篇章：Beta階段第XI次Scrum Meeting

0x01 ：Scrum Meeting基本摘要

Beta階段第十一次Scrum Meeting
敏捷開發起始時間	2015/01/06 00：00 A.M.
敏捷開發終止時間	2016/01/10 07：00 A.M.
會議基本內容摘要	ü  溝通方面，此階段的溝通工做基本完成，不管是與數據組的Solr平臺映射或是與學霸APP組的共用後端方面均完成溝通，近期因爲考期等相關事務逐漸結束，所以遲滯許久的Scrum Meeting終於最終開啓，團隊工做進入最終階段的收尾共組 ü  後端方面，從新梳理搜索結果接口和問答接口，並完成部分jQuery文檔、Django文檔的整理工做 ü  前端方面，主要交付團隊的架構人員負責，負責完成先後端的總體工做；考慮到在架構初期，先後端工做相互分離然後端依據單元測試保證其接口的正確性，所以對接工做穩步執行，至筆者截稿時瞭解信息，團隊對接工做基本完成，開始正式進入產品發佈階段 ü  在測試和流量部署方面，Django各接口模塊的單元測試工做已經完成，並交付測試人員進行驗收和進一步白盒測試；同時，服務器方面從新部署壓力、安全測試等方面的工做也順利完場；而關於代碼質量的測試計劃，因爲團隊在兩輪迭代中完成了多框架的整理和遷移工做，目前成型的版本代碼質量較高，且可讀性和規範均相對完善，此部分的質量監管工做將以定量的形式的完成數據展現
參與討論人員	除金東禾沒法聯繫外，全員參與

 

0x02 ：Scrum Meeting任務狀況說明

團隊成員	已完成任務
馮志睿 趙庶宏 王文基	ü  【#38】實現用戶管理的第三方登錄式的推廣（100%）：考慮到正式的工做量，此部分的第三方登錄功能在這次Beta開發階段不予支持 ü  【#52】完成主頁面「標籤雲」遷移工做（100%）： 在ReactJS的總體架構中，與jQuery的衝突相對較爲嚴重；所以，考慮到標籤雲的工做與右側的導航欄衝突較爲嚴重；所以，最終決定放棄標籤雲功能，而優化右側標籤欄的UI細節 ü  【#73】完成用戶管理接口的單元測試工做（100%） ü  【#71】完成Django用戶管理模塊的代碼複審工做（100%） ü  【#47】完成jQuery學習文檔的備案（100%） ü  【#54】完成問答部分的後端數據接口（結對編程）（100%） ü  【#69】完成Django用戶管理模塊的單元測試工做（100%）
李入雲 李雲濤	ü  【#55】完成搜索結果頁面的測試和複審工做（100%） ü  【#46】完成Semantic UI的學習文檔備案（100%）
錢林琛	ü  【#67】完成網站流量統計的部署工做（100%）：應用CNNZ的第三方流量統計網站完成流量統計工做，具體實現過程能依據http://help.cnzz.com/tongji/a/shezhiyuguanli/kuaisuanzhuangrumen/2012/0525/59.html完成相關配置 ü  【#68】完成總體代碼質量的定量分析和定性分析部署（100%）：此部分工做考慮到工做量最終並未執行，所以沒法根據具體的數據給出代碼質量的檢測結果，而在後續的答辯的過程當中將給出代碼質量的「直觀」認識
王鹿鳴	ü  【#43】完成用戶管理頁面的代碼遷移（100%）
金東禾	ü  鑑於此成員Scrum Meeting的參與率（0）和積極程度，團隊決定放棄此成員，同時團隊自己至今沒法聯繫上此成員，但依據此前Team C#團隊反饋的意見，可能會分配Django框架、Semantic UI框架的學習文檔的整理任務，方便後續繼續開發的團隊可以儘快上手此團隊的項目（項目自己學習成本相對較高，所以望謹慎考慮並接受）

 

0x03 ：任務進展過程當中遇到的困難

n  關於項目自己的時間緊迫性：團隊在近期的Scrum Meeting重點探討了工做量燃盡和時間的總體關係，在後端方面，因爲須要確保Dream團隊與BugPhobia團隊共用的後端接口存在必定的測試周期，所以在近期的工做量將重點圍繞後端的開發工做和後端的單元測試工做，保證在交付後端接口時可以優先保證後端質量；而前端方面，在處理完用戶的登錄問題後，其餘部分的對接工做將以高效的燃盡方式快速開展，所以近期項目經理也應快速調研流量統計、宣傳的文案設計工做，保證開發工做和宣傳工做的對接工做； n  關於項目自己的時間緊迫性：其實隨着開發效率的逐步提升，龐大的技術棧的消化工做已經基本完成，各部分工做已基本進入高效的燃盡狀態，而惟一困擾的問題在時間的緊迫性；僅談項目的自己的可擴展性，不管是針對分佈式的優化方向，或是先後端單頁應用模式的快速開發，均能適應軟件工程團隊項目自己的開發效率和進度；不得不認可，在開發前期，軟件工程的開發始終處於分割狀態，而其餘課程設計的工做量也急劇增大，在這一過程當中團隊未能合理估計自己的困難程度，而選擇大面積的重構工做，雖然說最後取得效果相對較好，但其中開發的工做量也呈現指數級增加，這裏不妨給出軟件工程課程自己對Alpha階段和Beta階段的建議： l  Alpha階段工做量：Beta階段工做量建議比例爲3：1，甚至更高；Beta階段儘量僅針對UI優化、性能優化部分給出必定解決方案，而不要重構 l  特別地，對於學霸系統的四個團隊，務必在Alpha階段完成最重要的對接工做，若某組重構必須快速完成其對接工做

 

0x03 ：Burn Down燃盡圖

圖 1 Beta階段第XI次Scrum Meeting燃盡圖

圖 2 Beta階段Team@OSC團隊Beta階段任務看板總體說明

圖 3 Beta階段團隊成員貢獻圖說明

 

0x04 ：代碼/文檔簽入記錄

 

圖 4 Github自己的commit記錄

圖 5 Team@OSC團隊管理自己的動態記錄（因爲上傳、建立等動態過多，所以不予展現，僅將一部分截圖進行展現）

 

0x05 ：再見，無憂時光

圖6 BugPhobia團隊會議留影~