| 這個作業屬于哪個課程 | 2020春|S班（福州大學） |
|---|---|
| 這個作業要求在哪裡 | 團隊作業第六次——beta沖刺+事後諸葛亮 |
| 團隊名稱 | 學長幫幫組 |
| 這個作業的目标 | Alpha階段問題總結 |
| 作業正文 | alpha階段問題總結随筆 |
| 其他參考文獻 | 暫無 |
一、計劃
-
預計劃
| 時間 | 後端 | 前端 |
|---|---|---|
| 4.26 | 熟悉Pycharm的基本使用，閱讀代碼規範 | 熟悉Android Studio的使用，閱讀《第一行代碼》 |
| 4.27 | 資料庫的建構以及環境配置 | 完成登入 注冊 找回密碼等基礎功能 |
| 4.28 | 完成注冊、登入、找回密碼等基礎功能 | 完成認證 學業情況 筆記子產品布局 |
| 4.29 | 完成認證、擷取成績接口、筆記子產品等基本功能 | 完成修改頭像 個人中心 |
| 4.30 | 完成擷取頭像、擷取資料等使用者基本操作接口 | 完成釋出筆記 檢視筆記 我的筆記 輔導子產品布局 |
| 5.01 | 完成筆記子產品的基本功能以及輔導子產品的初始化建構 | 完成釋出輔導 檢視輔導 我的輔導 |
| 5.02 | 完成預約等基礎功能 | 完成輔導預約 |
| 5.03 | 完成輔導子產品所有功能 | 完成檢視輔導記錄 輔導評價 |
| 5.04 | 疊代更新完善接口代碼 | 完成輔導清單 輔導搜尋 |
| 5.05 | Alpha版本程式測試 |
-
每日程序是否與預定計劃吻合，當日任務未完成的原因？
根據alpha階段的每日站立式會議彙報，我們組的每日程序與預定計劃大部分吻合，這是因為組内在此之前已經明确分工了，每個組員在拿到任務之後立即投入狀态，一般都能在deadline之前完成自己的子產品。
其中有一些子產品細節沒有按時完成，追其原因是組内在配置設定任務是沒有客觀地預估某個子產品的工作量，并且後端用python編寫，組員在新技術的應用上經常遇到困難，需要查閱資料或者尋求組長幫助，這也是一個重要原因。
另外測試階段也耗費了比預估更多的時間，是因為沒有考慮到測試工具的學習以及測試文檔的編寫。
二、任務配置設定
-
alpha階段的任務是怎麼配置設定的？
我們在項目初期就已經确認了前後端分離的模式，并根據組員的意願進行分組，前後端再各選出一個組長。
在alpha沖刺階段由前後端組長劃分任務，然後組員自行領取，根據任務的工作量和難度配置設定貢獻比。由于兩位組長都是項目經驗比較豐富的同學，能更好的把握任務配置設定的粒度，不會出現某項任務過難或者過于簡單的情況。
同時，組員根據自己的工作能力和所掌握技術選擇自己擅長的子產品。這樣的好處是在具體實作的階段，不會出現不感興趣/任務難度與自身能力不比對的情況。
-
不合理性
- 一些組員比較内斂，沒有比對到适合自己的子產品，又與組長組員缺少溝通，導緻程序跟不上。
- 組員缺乏項目經驗，在采用新技術的時不能很好的學以緻用，出現了困難問題隻能找組長幫忙，導緻了組長任務過重的情況。
- 整體積極性不高，出現問題的第一時間沒有溝通解決。
-
啟示
前後端組長不要給自己配置設定給過多的任務，因為要抽出較多的時間進行團隊的管理。
把每個人每段時間要做的任務寫成文檔，該文檔最好是由任務的執行者來執筆，因為很多時候你給組員交代任務的時候，他看上去是聽懂了（他自己當時也認為是懂了），可是做到中途的時候，才發現是似懂非懂，模淩兩可，這時候他估算的時間自然也就不可靠了，整個項目的進度自然就比計劃的慢了。
每日例會時應該讓每個組員都有發言彙報的機會，發言内容為自己的當日計劃是什麼，實際完成度如何，哪些地方需要其他成員幫助，最後進行簡短總結。這樣一方面起到互相監督的作用，組員可以對比自己和其他人的任務進度/完成品質，進而進行自我調整。另一方面使得每天遇到的困難都能及時曝光解決，不會出現問題堆積的情況。
三、資源
-
人力資源
在人力資源方面，由于一開始的随機分組政策，每個小組是由8-9個人随機組隊，人員的任務按照先意願，後調劑的方法配置設定，組長根據本組的選題和開發需求确定前後端的人員分布。
有幾個同學偏向于前端的開發，但由于前端意向的人數衆多，是以有兩個同學被調劑到了後端。之後的開發都跟随各自的組長進行，而前後端的每日任務由前端組長和後端組長進行銜接之後制定。
在人員配置設定的部分較為合理，每日任務也穩步推進。
-
軟體/硬體資源
雖然由于疫情原因無法回校，但本組成員放假時均有将自己的筆記本電腦帶回家，家中網絡情況也十分穩定，是以硬體資源滿足。而對于相關的軟體資源，前端組長分享了《第一行代碼》，後端組長也分享了《Flask Web開發》等相關資源供組員進行借鑒學習，之後也參照着《建構之法》進行軟體管理。
是以在軟體/硬體資源方面較為充足，組員互幫互助，項目循序漸進。
-
經驗教訓
在開始沖刺之前應該更早地讓大家進行基礎知識的學習，盡量在alpha沖刺階段更完美的完成制定的計劃。
四、具體實作
-
設計
- 原型設計由小組對APP功能進行商讨後由負責原型設計的同學設計
- 資料庫設計由後端同學進行設計
- 接口設計由前端組長和後端組長商量設計
- 模型設計由前端小組進行設計
-
代碼複審
- 由于代碼規範在編碼之前制定，是以組員在編碼期間都有遵守相應的代碼規範。
- 代碼複審方面是由組内成員進行合作互審，但由于alpha沖刺階段對該方面重視度不夠，是以沒有進行規範的代碼互審，在之後的beta沖刺階段會加強對該方面的重視
-
原型設計較為粗糙，而之後的設計文檔編寫較為簡陋，導緻在開發過程中還經常修改原型與資料庫的設計，這是十分不好的習慣。之後應該注重一下設計文檔的編寫和原型的精确度，以便之後開發工作的順利推進。
五、測試/釋出
-
測試
前端界面/功能測試工具為Android Studio虛拟機/真機。後端用Postman測試接口。目前組内已經完成了使用者子產品、輔導子產品和筆記子產品的測試，其餘子產品需等實作後才能進行測試，測試文檔随時更新，釋出在：
測試随筆
在alpha沖刺階段測試主要是尋找前端不适配問題以及一些界面布局方面的問題。後端接口測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等。發現問題的話，送出給對應的組員進行修複。
-
目前發現的bug：
- 釋出輔導資訊無效，界面不顯示（已修複）
- 使用者筆記中插入的圖檔不能顯示（已修複）
- 下載下傳附件失敗（已修複）
- 聊天記錄退出清空（進行中）
- 界面不适配（進行中）
-
釋出
-
服務運作後,用戶端無法通路服務端,提示逾時
解決方法:進入阿裡雲控制台,将服務端口加入安全政策中開放通路
-
運作提示子產品未找到
解決方法:使用pip安裝缺失的依賴
-
六、個人總結
- 曾宏健：編寫代碼的時候要更加細心，要加強與後端的溝通合作
- 陳志達：團隊合作才能更使開發更加效率，應該加強軟體項目管理
- 鄭小華：不僅要多學習Android知識，更要注重團隊合作，原型設計也應該加強
- 李康華：在鞏固基礎、學習新技術的同時更要多加實踐才能深入了解，每個人都是團隊的一部分，要注重個人對團隊的影響。
- 王玉珊：拿到任務後要做好時間管理，遇到問題第一時間尋求組員幫助
- 何翺翔：寫代碼要細心，代碼複審環節應該加強
- 林琳：熟能生巧，注重細節，資料庫設計應該更加完善
- 林轶凡：知識要多學習并且多運用才能更好的掌握，團隊協作才能使項目穩步推進
- 沈明炜：在開發過程中要安排好時間，提前進行學習，在開發中熟練使用，文檔編寫也是十分重要的
七、改進
-
代碼管理
如同alpha沖刺階段那般，要求組員開發過程中對代碼規範進行熟讀并應用，改進自己的代碼風格，打規範的代碼；而代碼複審方面，是我們團隊需要加強的一部分，我們此次将采用組内成員合作輪流互審的方法，以求代碼風格統一。 -
程式架構
在beta沖刺階段，我們組打算使用MVVM架構進行軟體重構,這樣能夠有效降低項目中的代碼耦合,更有利于團隊合作開發。 -
工具應用
部分組員對于軟體開發工具的應用和軟體項目管理工具的應用還不是得心應手，在開發代碼的過程中還在不斷地查詢相關的知識，是以在此次beta沖刺階段我們将加強組員之間的交流，在每日例會中交流軟體應用的心得，以免有些組員重蹈覆轍。 -
項目管理
pm将與前後端組長一起推進項目進度，分工合作，攜手前行。 -
使用者資料
在項目跟蹤使用者資料方面,考慮接入友盟統計來實作日活周活等資料 -
文檔品質
關于文檔品質的提高，我們組主要是想通過pm的“質檢”來提高文檔品質，将任務截止日期設定得靠前一點，留給pm足夠的時間檢查文檔并督促組員進行完善。 -
人員管理
pm、前端組長和後端組長互相合作，為任務設定deadline，并督促組員完成任務。 -
心得體會
此次沖刺讓我們充分體會到了40-20-40規則，即在整個軟體開發過程中,編碼的工作量占20%,編碼前的工作量占40%,編碼後的工作量占40%。前期的設計階段留下的不足導緻編碼階段十分被動，這讓我們感悟到設計階段的工作更應該審慎完成。
八、會議截圖
