BETA 版衝刺前準備

BETA 版衝刺前準備

隊名：第三視角

做業連接

組長博客

應做業要求爲了更加順利地開展beta版本的衝刺，上次的alpha版本展現後，咱們組對以前開發過程當中存在的各類問題進行了全面的討論，並對其進行了相應的調整和改善。

過去存在的問題

選擇了難度較大的開發工具

• 對於後端，在項目開始時對於wxpy庫和qqbot庫的調用難度估(qi)計(shi)不(shi)到(tai)位(cai)。受限於騰訊對外開放的接口數量以及接口的使用限制，部分功能(如單向好友檢測)的開發受到了不一樣程度的影響。
• 對於前端，在項目開始初期只考慮到先後端都使用python會更加方便對接就選擇了pyqt框架，可是卻缺乏了對pyqt學習難度的估計以及現有資料數量的考量，在開發過程當中才發現pyqt框架複雜、學習成本高且社區資料的貢獻度不高，整體開發難度大。

開發過程當中規範化程度不夠

• 開發過程當中組內只對數據庫方面編寫了接口使用文檔，對於其餘子功能模塊沒能較好地編寫接口規範文檔（註釋寫的不夠），致使先後端的對接難度加大。

討論問題效率不高

• 因爲人數較多，團隊思惟比較跳脫，咱們組平均每次開會都須要佔用兩個小時左右的時間，相比其餘組來講多了很多。緣由在於組內討論問題效率不高，常常對一個小問題進行過早的拓展和優化，沒能對問題先進行系統地分析。

團隊總體開發經驗不足

• 在工具的選擇以及整個開發過程中基本都是組內幾位水平較高的大佬在進行決策，其餘人沒能給出較爲權威的建議，整體來講團隊的開發經驗較爲不足。而且就算是大佬在以前也尚未碰到過多進程通訊的問題，可見整個團隊的開發經驗還不夠豐富。這樣的問題在工具選擇以及開發設計的時候也都有所體現。

團隊組織管理還不夠嚴謹

• 人數較多，任務難平均分配。儘管團隊內採起很是和諧的任務分配，可是有得必有失，這樣的作法致使任務的分配沒法作到很是的均勻，也致使沒法充分地使用人力資源。在部分組員完成了一個較爲簡單的任務後沒法立刻被分配到其餘的任務當中，而其餘組員可能由於獨自面對困難的任務而感到困擾。

暫未系統地進行功能測試

• 由於大三課業比較重，組內功能的開發一直處於比較緊張的狀態，故也沒有騰出足夠的時間給功能測試。對於大部分功能都只是在開發第一版完成後進行簡單的測試，未系統地進行功能測試。

用戶量暫時不夠多

• 目前爲止產品基本都只是組內人員在進行試用，沒有創建起比較堅實的用戶基礎，這與產品的開發進度以及宣傳策略是有必定關係的。

作出的調整和改進

選擇工具前作好充分的調研

• 咱們以後再選擇其餘工具前，會從易用性、社區文檔貢獻度、整體評價等方面對工具進行考量。選擇合適的工具進行開發。

進行設計文檔規範

• 我組將在接下來的開發過程當中對每一個功能接口以及先後端接口進行設計文檔規範，並由相應的組員進行文檔歸類和整理。從而作到對設計文檔的規範管理，方便先後端人員的交互以及代碼的複用。

優先考慮根本問題

• 對於討論效率不高的問題咱們組內已經進行了反思。在以後開展的會議中，組內會先擬定會議要點再逐項進行。對於手頭要進行分析的問題，會基於各個基本點進行討論，在有了大題框架和思路以後再對其餘細化展開的問題進行分析。

採起更靈活的分配方案

• 對於團隊組織管理上存在的問題，咱們將採起更加靈活的分配方案。對於已經處理完手頭任務的組員將根據具體狀況（該組員時間、其餘任務的人員需求）進行新的任務分配，在任務分配下去時也會更加嚴謹地考慮此任務的人員分配是否合理，作到充分地利用組內資源。

進行功能單元測試

• 以前受限於開發進度因此沒有進行比較系統的功能測試，在接下來的開發階段咱們組會對已完成的功能進行更爲標準的單元測試，作到及早發現代碼存在的缺陷以進行相應的完善。

展開宣傳

• 在項目基本功能封裝打包完成後咱們將對產品進行小範圍內的試點投放，同時藉助同窗的關係鏈進行宣傳造勢，爲最後的完整產品創造較好的用戶基礎。

Beta衝刺中將有的改進

對於非功能的問題都已經在上面提到了，此處再也不累贅

• 繼續優化前端界面，儘量統一界面風格
• 完善交互設計
• 完成對關鍵詞提醒功能的開發
• 完成對消息羣發功能的開發
• 對已經完成的熱詞分析功能進行優化
• 儘量改善單向好友檢測功能可能致使的封號問題
• 準備發佈Release版本