福大軟工 · 第十二次做業 - Beta答辯總結

Part 0. 開篇

組長博客：戳我進入

• 小組成員：

短學號	名
2219	奇豪（組長）
2209	毓明
2226	淇
2204	水源
0236	禮亮
0215	翔宇
1124	熊
1123	志銘

產品宣傳視頻連接：戳我進入

• beta博客彙總
  beta1博客
  beta2博客
  beta3博客
  beta4博客
  beta5博客
  beta6博客
  beta7博客

• 燃盡圖

• 評估團隊中每一個人對本次做業的貢獻比例

姓名	得分（百分制比例%）
柯奇豪	26.25
黃毓明	23.25
蔣雄	14.25
黃志銘	9.25
丁水源	9.25
林翔宇	7.25
林淇	6.25
楊禮亮	4.25

GitHub 項目連接：戳我進入

Part 1. 原計劃、達成狀況及緣由分析

• 原計劃將什麼功能作到什麼程度

  完成項目原先設定的全部功能，並作到界面簡潔大方，操做友善，基本無bug，同時將其進行部署測試。

• 實際作得怎樣了

  項目的功能基本已經實現，但存在部分bug以及一些不友好的操做，咱們會盡快修復改善並優化界面。此外，咱們因爲某些特殊緣由，迭代掉了想法功能，但並不影響產品使用與定位。

• 若是沒有達成，反思是哪些因素影響的

  有一說一，從最後的結果看，做爲PM的我來講，前期在工做任務的統籌規劃上存在着問題，致使後續工做進度緊張，沒有可以及時的督促組員進度，同時沒有依據每一個人的能力分配任務，存在部分划水現象的出現以及工做完成不善的情形發生，這些都是項目進程中所遇到的問題點。

Part 2.Beta 版本展現

• 小組模塊(對於人員的編組，功能的執行對象)

• 共享編輯模塊(用於文章的多人編輯，做者進行審覈應用或者版本回退)

• 通知模塊(進行事項消息的通知確認工做)

• 個人模塊(我的信息欄以及軟件反饋處)

• 簽到模塊(進行定位+wifi的準確簽到)

• 詳情查看模塊(對於我的已發佈或參與的信息進行查閱)

Part 3 現場答辯得分

• 小組	評分
  第一組	76
  第二組	77
  第三組	80
  第四組	84
  第五組	74
  第六組	73
  第七組	79.5
  第八組	86
  最低分	73（第六組）
  最高分	86（第八組）
  有效分數	76，77，84，74，79.5，80
  最終平均得分	78.4

Part 4 Q&A

(由於問題中存在部分重複性的提問，故這裏作整理後進行統一答覆)

Q1: 界面展現中的部分數據是從數據庫實時獲取的仍是寫在前端頁面中的本地數據？若是是後者請進一步完善/體驗程序,有部分原生程序,是前端默認的數據吧,好像數據格式也不完整？/大家的功能是否真正實現,仍是隻是前端作好

A1:你好，所有都已實現，咱們沒有在前端聽任何的數據，寫一個靜態頁面只是浪費時間的事情，咱們也不可能拿一個原型去糊弄你們，所有都是經過受權後的openid從數據庫調用的數據，只是前端存在部分邏輯錯誤，如今咱們已經修正大部分，若是仍有質疑，能夠打開調試查看wxml，或者聯繫咱們。

Q2 :用戶權限的定義能夠更細緻一些嗎？

A2: 你好，用戶權限咱們正在優化，目前已經完成的權限，匿名投票的信息查看，小組管理，我的發佈信息查看，其餘的暫時在考慮，可能存在部分邏輯錯誤，咱們也在積極尋找bug

Q3: 考慮過如何推廣，增長用戶量嗎？

A3: 你好，咱們這是一個工具類軟件，而且藉助於微信小程序的平臺開發，須要域名備案及其餘相關雜項，相比於其餘平臺較爲繁瑣（也是咱們的準備不足），目前咱們已經經過初審，咱們將在小程序正式發佈以後進行推廣，從體驗用戶開始，咱們認爲校園會是這個小程序的較好應用場景。

Q4: 對下拉刷新的功能會進行修改嗎？

A4: 你好，咱們應該不會考慮下拉刷新，而是改成及時反饋，這次展現多是忘記添加reload函數。

Q5: 請問大家beta版本分工是怎樣的？/從alpha版本到beta版本，項目進度如此快，能夠介紹一下大家的分工及各個模塊具體花費的時間嗎？

A5：分爲兩組，各4人(加上新隊員)，一組負責投票、簽到、通知及用戶和分組三個功能和界面，其他負責共享編輯開發及部分前端美化，順帶博客與視頻。原定前端人員再作一些整體頁面的美化。此外，具體的時間並無統計，可是常常加班到凌晨

Q6: 在遇到任務分配不均的時候是怎麼樣處理的呢？

A6: 以前α版本的時候確實遇到過，那時候不清楚先後端工做量，前端工做較重，自從上一版本發現問題後就積極解決，後端參與到前端js界面參與接口和調用，前端更多的去重構和美化界面。

Q7:後期打算如何推廣,面對騰訊各類官方助手工具和WPS文檔編輯？/和一些大廠作的在線文檔相比，大家的優劣勢在哪呢

A7: 咱們主打的即是集成、便捷的辦公，咱們功能較全，同時比較方便，無需跨APP完成多種辦公需求！此外，共享編輯的功能是git類型，推廣的話，咱們認爲校園會是這個小程序的較好應用場景，劣勢的話，首要的即是用戶量及知名度，另外，咱們的開發能力有限，可能沒法考慮到更多的需求。

Q8: 在版本現場演示時給予用戶操做引導，是否會是更好的展現方式？

A8: 謝謝大家的建議，咱們會考慮的，此外，咱們在」個人「頁面加入了幫助文檔，供初次操做用戶學習。

Q9: beta階段相比alpha階段項目進度日新月異項目組是如何作到的？/針對beta衝刺有什麼感想嗎？

A9: 你好，咱們在alpha版本中踩了許多坑，致使效率低下，在beta版本中總結教訓，明確分工，此外，咱們的大部分後端在alpha版本中已經完成。說到感想的話，或許有時候踩過的坑會成爲一次經驗。分工明確也會是一個好的選擇

Q10: UI能夠進一步美化

A10: 謝謝大家的建議，咱們會考慮進一步再美化的，emmm，盡全力符合大衆口味

Q11: 定位簽到功能可否如期實現？

A11: 定位簽到功能目前咱們已經採用WIFI和位置簽到兩種方式，能夠說是基本實現該功能啦~

Q12: 團隊具體分工是怎麼樣的呢？

A12: 分爲兩組，各4人(加上新隊員)，一組負責投票、簽到、通知及用戶和分組三個功能和界面，其他負責共享編輯開發及部分前端美化，順帶博客與視頻。原定前端人員再作一些整體頁面的美化。此外，具體的時間並無統計，可是常常加班到凌晨

Part.5 我的部分

• 我的PSP

PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
· Estimate	· 估計這個任務須要多少時間	5	5
Development	開發
· Analysis	· 需求分析 (包括學習新技術)	5	5
· Design Spec	· 生成設計文檔	5	5
· Design Review	· 設計複審 (和同事審覈設計文檔)	5	5
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	10	10
· Coding	· 具體編碼	150	250
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	20	20
Reporting	報告
· Test Report	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	0	0
合計		200	300

• 我的學習進度條（每週追加）

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
11	N	N	25	126	整合完善，有那麼、成果，不負我花費的大把心血