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 |
| 丁水源 | |
| 林翔宇 | 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 | |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 10 | |
| · Coding | · 具體編碼 | 150 | 250 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 20 | |
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 200 | 300 |
- 個人學習進度條（每周追加）
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 11 | N | 25 | 126 | 整合完善，有那麼、成果，不負我花費的大把心血 |