Beta階段衝刺前的準備

Beta階段衝刺前的準備

凡事預則立，在Beta開始前，以小組爲單位，在敏捷衝刺前發佈一篇博客，描述：

1. 討論組長是否重選的議題和結論

通過咱們小組在週二下午的會議中有從新認真的考慮了是否要更換組長的問題 咱們也提出了見解和建議 首先通過前半段的共同努力 咱們一致表示咱們組的組長秦玉是狀態很是好的 不管是從全局的掌握仍是具體事件上的安排 她都完成的很是好 也很大程度上提升了咱們組的效率 再次 若是換組長的話 這個角色誰來擔任更合適 是否在完成度上能夠達到更高的層次 使咱們組的狀態會變得更好 咱們本身也討論過 認爲沒有這樣比較能夠點面結合的人 最後 若是換組長的話 對咱們組的現實狀況來講可能不是好的狀況 對咱們工程的進度會有必定的影響 因此在咱們認真討論後 決定 咱們組不會更換組長

2. 下一階段須要改進完善的功能

木有須要完善的~以前的功能簡直是完美

3 下一階段新增的功能。

Beta階段新增的功能：

• 新增其餘學院的搜索引擎
• 實現網站的定時爬取以及es的自動同步
• 主界面設置最新通知播報欄
• 新增按時間篩選信息功能
• 擴大使用範圍至移動端
• 將項目部署到服務器

4. 須要改進的團隊分工（針對以前的不足，須要增強和改進團隊協做和分工的地方）

在Alpha階段的分工咱們是按照功能進行分配的，在通過Alpha階段的衝刺以後，咱們以爲這樣的分工仍是比較合理的。能夠充分調動每一個人的時間，讓你們能夠按照功能模塊一步一步的完善咱們的項目。
改進點：在任務劃分的時候要能夠更加具體與細緻，儘可能把任務細化，具體到實現到什麼程度。好比咱們提到的實現總體同步的批處理文件編寫，這個就能夠每次任務的時候具體到自動化到什麼程度，究竟是僅僅的數據庫更新爬取仍是完善到再進行同步es的部署。關於團隊合做，從過後分析能夠得出，多溝通，多交流，是團隊合做必不可少的，咱們組在溝通上是很積極的也很全面，每一個人的思想能夠基本達到同步，也沒有在實現上上出現沒辦法調和的問題。在Beta階段，咱們團隊會延續多討論，多交流的團隊模式，讓項目成員保持瞭解項目的進展的狀態，爭取在新增功能的實現上有新的成就。

5. 須要改進的工具流程（如版本控制、測試工具等）

咱們在Alpha階段主要用Learngoo管理燃盡圖，碼雲管理代碼（雖然有的時候用QQ羣代替了），可是毋庸置疑燃盡圖和碼雲是很好的協助工具，咱們在beta階段決定仍然使用這兩個工具。
在咱們搜索引擎的功能測試上，咱們目前尚未發現特別好的測試工具，只能如Alpha階段同樣繼續沿用咱們能夠完成的各個版本的瀏覽器測試，同時由於加入了移動端的應用，因此準備用移動端模擬器也進行測試。針對每次關鍵字的搜索的用時和cpu的開銷也繼續沿用以前的方法，將搜索用時打印出來來分析參考。由於新增了自動爬取和自動同步es的功能，那麼對於編寫的腳本從運行到完成的時間也能夠進行時間分析，調整代碼爭取作到時間消耗最小化。

6. 衝刺的時間計劃安排（衝刺時間爲期五天，安排在2018.11.30——2018.12.12之間）

團隊任務	預估時間	實際時間	完成日期
新增其餘學院的搜索引擎	300	——	——
實現網站的定時爬取以及es的自動同步	200	——	——
主界面設置最新通知播報欄	300	——	——
新增按時間篩選信息功能	340	——	——
將項目部署到服務器	200	——	——
擴大使用範圍至移動端	100	——	——
前端界面的美化	100	——	——
需求說明書的調整	60	——	——
搜索引擎測試	80	——	——
用戶使用調查	100	——	——
Beta階段發佈說明	200	——	——