【Beta階段】計劃階段要求 - 初始任務分配 - 靈境 | week12
阿新 • • 發佈：2022-05-22
| 專案 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 2022春季軟體工程（羅傑 任健） |
| 這個作業的要求在哪裡 | 團隊專案-Beta階段計劃要求 |
Part1 Beta階段總體規劃
- 完善Alpha階段的個人空間，首頁，個人主頁等功能。
- 完成好友聊天，樹洞，會議廳，高校場景的2個遊戲功能，人物模型DIY
| 需求 | 優先順序 | 開發階段 |
|---|---|---|
| 好友聊天 | ⭐⭐⭐⭐⭐ | Beta |
| 樹洞 | ⭐⭐⭐⭐⭐ | Beta |
| 會議廳 | ⭐⭐⭐⭐ | Beta |
| 高校場景TD人遊戲 | ⭐⭐⭐⭐⭐ | Beta |
| 高校場景鋼琴湖功能 | ⭐⭐⭐⭐⭐ | Beta |
| 人物模型DIY | ⭐⭐⭐⭐ | Beta |
Part2 任務分配
2.1 初始任務分配
| 分組 | 姓名 | 任務 | 子任務 | 預計時長（h） |
|---|---|---|---|---|
| 客戶端 | 客戶端小組 | 客戶端程式碼規範與協作 | 呼叫API介面方式規範確定 c#邏輯部分程式碼規範確定 與美工建模同學討論協作方法及UI設計統一 |
4 |
| 楊濡冰 | 高校場景鋼琴湖功能 | Unity 音遊遊戲製作學習 | 16 | |
| 羅楊一飛 | 會議廳功能 | 引入AR功能 | 8 | |
| 場景渲染優化 | shader的研究 | 16 | ||
| 李浩宇 | 樹洞製作 | 樹洞UI設計與資料對接 | 16 | |
| 訊息列表功能 | 訊息列表UI編寫 | 8 | ||
| 顧晨宇 | 高校場景TD人遊戲 | 多人線上遊戲資料同步學習 | 16 | |
| 人物模型DIY | 人物裝扮，膚色更換技術學習 | 8 | ||
| 服務端 | 服務端小組 | 服務端程式碼規範與協作 | API介面設計，文件規範 Java邏輯程式碼規範，測試程式碼規範 |
1 |
| 馮張馳 | unity雙人聊天服務搭建+訊息推送服務 | 搭建 | 20 | |
| 服務端維護 | 服務端介面維護，高併發部署探究 | 5 | ||
| 肖偉強 | 多人聊天 | 結合netty搭建後端訊息管理推送，設計相關表 | 10 | |
| 遊戲相關資料 | 設計相關表和介面 | 10 | ||
| 譚思齊 | 客戶端測試 | 學習Unity測試框架，進行客戶端測試 | 20 | |
| 服務端測試 | 繼續進行spring服務端功能測試，壓力測試等 | 6 |
2.2 後續待分配任務
| 分組 | 任務 | 預計時長（h） |
|---|---|---|
| 客戶端 | 首頁熱點/地圖功能 | 10 |
Part3 任務指派
第二次迭代 Beta階段
Part4 補充說明—Beta階段開發流程
4.1 衝刺階段開發流程
每日開發
以2天為單位，完成一次迴圈
- 開始開發前由PM進行需求分配，每個成員對應一個需求（需要遵守模板）。
- 每個成員將需求進度轉成進行中，將PM表述不清楚的部分按照自己理解進行完善補充，並將需求轉換為自己的具體任務，並根據實際情況確定每個任務優先順序和截止時間（原則上不晚於下一次例會的日期）。開發中完成了某個任務後，先自行對所完成任務進行測試，至少保證自己的任務的基本測試無誤。
- 在完成了兩日內全部任務的測試之後（或者認為已經做完了2日內的工作之後），將之前的需求設為已完成，同時釋出一個測試需求，完善每個需求對應功能的描述，指定任務物件為tsq，等待tsq進行功能測試。
- tsq測試如果遇到了bug，確認是和這個任務本身相關的問題，直接在對應的任務處留下評論並將相關任務設定為進行中，並通知相關人員進行相應修改。如果發現了與所在功能無關的其他bug，釋出一個缺陷給對應人員。（如果不知道給誰就先發給yrb）
- 在解決了某個任務的問題後，開發人員將任務設定為已完成。解決了某個缺陷需要將缺陷設定為關閉。
- 每兩日例會，例會之前每個人需要明確自己做了什麼，開會後需要大致明確之後兩天需要做什麼。同時釋出在平臺上，確認自己到底要做什麼，自己來給自己定任務
每週構建
- 每週開始之前PM確定本週的大致開發目標，並具體描述出來。
- 每週日內部發布內測版本，要求至少所有安卓使用者都需要進行產品試用，並提出相應缺陷。
4.2 需求模板
開發需求
標題格式為：開發需求-[簡要描述]
具體內容為對於這個開發需求的具體介紹，以一個數字列表形式呈現。
截止日期需要指定為下一次例會開始時間。
功能需求
此需求模板是針對一些奇思妙想的收集
標題格式為：功能需求-[簡要描述]
具體格式包括功能說明+可能的實現方式/技術方案兩個方面
測試需求
標題格式為：測試需求-[簡要描述]
具體內容為一個todo列表，內容為自己完成的功能的簡單描述和對應的issue。大致為功能具體描述：issue編號
截止時間需要指定為下一次例會時間。
4.3 任務模板
標題為：任務簡要描述，比如：聊天服務
每一個任務儘量是不可再分的，即如果再拆分對於自己沒有積極意義。
同時需要包含3個方面，任務具體描述，實現方案（包含設計和具體實現），簡單測試結果（簡單測試用例，在什麼樣的情況下測試無誤）
截止時間需要設定為某次例會時間。
4.4 缺陷模板
標題為bug的簡要描述
具體內容包含bug出現位置、觸發條件、出現頻率、嚴重性。