Alpha階段事後總結

Part1 設想和目標

1.1 產品

① 產品定位

『主打VR Chat功能的高校元宇宙』

主要考慮對於普通大學生和教師的社交，在設計之初沒有考慮到有許多單純想獲得樂趣的找樂子人。之後嘗試設計更多娛樂性功能，同時將娛樂功能和一些常見社交功能相結合進一步體現社交屬性。

② 典型使用者和場景

對典型使用者和典型場景的理解是否一致？

在alpha階段典型使用者和場景主要是為了寫而寫，沒有進行非常一致性的表述，沒有特別設計針對每種使用者的具體的功能。beta階段考慮將典型使用者場景與具體的功能進行繫結

③ 目標完成度

• 原計劃的功能做到了幾個？

  功能	描述	開發階段	完成情況
  使用者註冊	大學學生或教師使用自己的身份資訊進行註冊	Alpha	✔
  使用者登入	使用者使用手機驗證碼或者賬號密碼登入	Alpha	✔
  登入引導	登入後進行必要的引導	Alpha	❌
  個人資訊	個人資訊管理	Alpha	✔
  設定	app設定與身份資訊管理	Alpha	✔
  首頁學校地圖	選擇學校進入	Alpha	❌
  校園場景社交服務	本校/其他學校校園場景社交服務	Alpha	✔
  我的空間	個人自定義空間	Alpha	✔

• 按照原計劃交付時間交付了麼？

  由於各種bug延遲了接近2天

• 原計劃達到的使用者數量達到了麼？

  原計劃100，實際約60

④ 使用者反饋

使用者對重要功能的接受程度和我們事先的預想一致麼?

使用者對於高校場景的喜愛和體驗與我們事先預想一致，同時由於沒有太多具體功能，使用者粘性不夠也是事先預想到的。

設計併發布問卷，包含已有功能評價反饋，待做功能優先順序，對每個功能的需求程度，以此為依託確定beta階段的開發目標。

⑤ 經驗教訓

我們學到了什麼？如果重來一遍會做什麼改進？

• 前端程式碼規範
  • unity檔案的組織管理標準化
  • git版本控制流程的優化
• 服務端安全性
  • 對使用者鑑權進行細緻考慮和處理，構建隱私安全性更高的服務。
• 和中傳對接
  • 加強與中傳同學的交流，在我們自己的實際開發難度以及目標和他們的設計目標之間找到平衡點。
• 完善需求分析
  • 發問卷，調查已有產品缺陷，確定beta階段側重點。

1.2 計劃

• 是否有充足的時間來做計劃?

  由於各種原因，alpha階段的開發往往缺少一定的計劃，beta階段在開發自己分配的功能前，需要先進行詳細設計和技術調研，再繼續進行開發。

• 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

  主要依靠語音或者面對面交流交換彼此的意見，並不斷磨合形成最終的結論。比如以下例子：

  • 個人空間形態改了三版，主要是依靠yrb和中傳同學的反覆討論得出。
  • 首頁的形態經過多次會議的意見打磨。
  • lhy和fzc關於使用者資訊管理以及JWT安全認證的內容進行了多次討論，有問題及時進行語音交流，確保雙方對於同一個API的認知保持一致
  • fzc和xwq對於技術方案進行及時討論
  • 需求分析與初始計劃階段對於開發目標以及是否完全自行開發產生了一些問題，最後是由兩位PM向持有不同意見的同學進行了詳細的解釋，從而解決了問題。

• 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

  沒有完全做完，主要原因有：

  • 前期對unity的技術難度預估不足，真正開發之後需要解決很多技術問題，包括程式碼整合，3D場景內物品拖拽，unityUI的佈局，多人同步等難點。
  • 時間相對比較緊張，3周內團隊內成員存在時間不統一的情況。不能自始至終都有充足時間實現自己的任務。

  beta階段的解決是，前端同學加強溝通交流，將lyyf設定成救火隊員的角色，在完成自己任務之後在有空時加入其他部分開發。同時，由fzc負責文字聊天及訊息系統的開發，減輕前端同學壓力。

• 有沒有發現你做了一些事後看來沒必要或沒多大價值的事？

  部分同學對於一些細節過分較真，導致沒有從根本上解決問題

  沒有善用unity的資源商店提供的工具，一些功能的實現上重複造輪子了

  入口網站的管理系統，由於沒有人有空來進行維護，因此其實是質量很低的，也沒什麼價值

• 是否每一項任務都有清楚定義和衡量的交付件？

  任務的定義和交付仍然停留在較為模糊的表述，沒有非常清晰的描述，beta階段會制定嚴格的工作流程和需求-任務-缺陷描述規範。

• 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到？

  基本上沒出現重大意外，但是語音交流和ios釋出出現了些許問題，主要原因是實際需要時間與預估時間有較大差距。ios釋出當天蘋果官網還崩潰了。

• 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

  留下了一些靈活處理的空間，比如初始任務時給tsq分配的任務相對較少，從而在中後期測試和ios釋出時依靠他完成了很多工作。同時，類似文件編寫，安卓釋出，網站搭建等初始時都放置在緩衝區中，合適時間分配給合適的人做。

Part2 設計與實現

2.1 功能設計

• 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

  • 對於基本的功能由前端同學進行主導設計，後端同學輔助進行介面設計
  • 複雜的功能和中傳同學進行商議後進行確定

• 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

  • 在例會時進行解決，集合眾人的想法
  • 直接由當事人進行面對面或語音交流

2.2 bug分析

• 什麼功能產生的Bug最多，為什麼？

  • 使用者相關的介面。原因是使用者鑑權和資訊保護的處理相對較為繁瑣複雜，相應的邏輯也會帶來很多bug。
  • 個人空間。原因是3D物品拖拽和unity中的定位較為複雜，如果自己實現往往需要很多控制程式碼。
  • 好友管理相關功能。原因是新增好友—檢視申請列表—同意或拒絕整個流程較為複雜，需要前端後端對每一個API介面都保持完全相同的認知，才能實現好功能。

• 在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

  • 安全性問題：使用者可以檢視修改其他使用者資訊。
  • 不允許語音會導致app崩潰的問題
  • 個人主頁和好友訊息的點選與顯示出現了問題
  • 穿模，穿透點選問題。

  原因在於時間有限，往往是想著能跑起來即可的想法，沒有注重安全管理。同時缺少充分的測試，即使測出來了也可能會缺少解決辦法。

  ID	問題	優先順序		時間
  #149	滑鼠穿透bug	中		2022/05/14 20:46
  #148	完成對於版本號的判斷和獲取最新版本號	高	alpha總結與完善	2022/05/14 17:49
  #147	新增對於版本號的判斷操作	高	alpha總結與完善	2022/05/14 17:49
  #146	改介面	中		2022/05/14 19:28
  #145	介面異常	中		2022/05/14 19:28
  #144	需要新的獲取使用者資訊介面	中		2022/05/16 15:39
  #143	/user/getuserinfobyphonenumber介面邏輯錯誤	中		2022/05/16 15:39
  #142	關於token的處理	高	alpha總結與完善	2022/05/14 20:44
  #141	修改因為後端許可權驗證引起的變化	緊急	alpha總結與完善	2022/05/14 17:53
  #140	Model+Profession+School+Source+User介面許可權判斷	高	alpha總結與完善	2022/05/13 21:38
  #139	Friend,Hobby,Info,Message介面許可權判斷	高	alpha總結與完善	2022/05/13 21:38
  #138	修復好友申請介面的返回箭頭比其它返回箭頭偏大的問題	中	alpha總結與完善	2022/05/14 17:55
  #137	利用redis的管理員路由表在jwt prehandle方法內進行直接攔截	中	alpha總結與完善	2022/05/13 21:38
  #136	利用redis快取資料庫增加一個管理員路由表	中	alpha總結與完善	2022/05/13 20:00
  #135	優化註冊登入、個人資訊等靜態頁面效能，無更改時主事件迴圈要阻塞、不要輪詢刷幀，從而降低CPU佔用	中	alpha總結與完善	2022/05/13 19:14
  #134	後端實現完備的鑑權機制、消除非法請求的 500 Internal Error 問題	緊急	alpha總結與完善	2022/05/14 17:49
  #133	修復個人主頁按比例縮放導致文字過小的問題	高	alpha總結與完善	2022/05/13 18:51
  #132	修復首頁魔方點選不容易點上的問題	緊急	alpha總結與完善	2022/05/13 19:17
  #131	統一字型為“阿里普惠體”，統一程式碼檔案編碼為utf-8，規範字符串相關程式碼，修復iOS端獲取驗證碼後及選擇學校亂碼問題	緊急	alpha總結與完善

• 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

  • 目前是每次程式碼合併的時候由團隊內一位同學進行稽核，只有稽核通過才能合併到dev主分支。
  • 前後端都使用自動的程式碼風格檢查外掛，因此可以保證執行了程式碼規範。

2.3 變更管理

• 每個相關的員工都及時知道了變更的訊息?

  • 由於每兩天的組會大家都會闡述自己的任務完成進度和將要完成的事項，組內成員都能很好地通氣，及時獲知最新的任務以及專案進展。

  • beta階段將讓每個成員將coding和微信賬號繫結，從而可以在微信裡接受專案的一些通知和檢視todo

• 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

  • 首先充分尊重每個同學的意見，在例會時確定好最緊急的任務，以及需要推遲的任務。
  • 猶豫不決時，根據實際技術難度和alpha計劃階段定的優先順序，由兩位PM根據實際情況確定最終的計劃。

• 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

  • 對於每週日的產品體驗，只要沒有明顯bug（比如閃退，無法執行）就認為是達到了出口條件
  • 對於正式的釋出版本，需要等到已經沒有明顯bug可以修復的時候，不會有任何功能上的問題導致使用者使用體驗不佳，內部測試和稽核沒有問題之後進行釋出。

• 對於可能的變更是否能制定應急計劃?成員是否能夠有效地處理意料之外的工作請求？

  • alpha階段對於技術難度較大的部分我們也會採取解耦的方式，將每個人負責的部分分開，從而讓每個成員都能單獨地開發自己的部分，不會依託於其他成員的工作內容進行修補。因此遇到可能的變更也能以最小的代價讓成員切換到新的任務中。
  • 由於團隊內成員都比較負責，能力也較強，在遇到突然釋出的任務時都能做出很好地應對。

Part3 測試與釋出

3.1 測試計劃

團隊是否有一個測試計劃？

• 後端有一套完整的測試流程，即開發者自行簡單測試—單元測試—壓力測試，同時在和前端對接後進行及時的修改完善。
• 前端主要是進行功能測試，即執行之後對於自己所負責的功能進行功能體驗，並測試是否符合自己的預期。beta階段可以加入自動化測試手段，用工具對app進行自動模擬點選從而進行測試。

① 前端測試人員

我們安排了tsq同學完成QA和測試的工作，對於前後端的程式碼進行測試和質量保障。

② 缺陷規範

Coding平臺“缺陷”提出規範：至少包含bug出現位置、觸發條件、出現頻率、嚴重性等內容，此部分在第5部分進行嚴格定義，此處不再贅述。

③自動化測試工具

• 團隊是否有測試工具來幫助測試？很多團隊用大量低效率的手動測試，請提出改進計劃：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。

• 後端程式碼實現了持續整合部署，內含編譯，單元測試，推送伺服器部署三個過程。詳情可以參見【技術部落格】Coding平臺的Spring專案持續整合部署

• 前端使用unity的Unity Test Runner進行測試，參見官網測試指導

3.2 驗收測試

• 是否進行了正式的Alpha產品驗收測試？

  沒有進行。此部分將在beta階段由一篇驗收報告測試進行體現，主要由全員對功能規格計劃書中的驗收標準進行測試，同時最終由QA成員tsq進行確認和釋出。

• 服務端壓力測試：團隊是如何測量並跟蹤軟體的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

  tsq利用自動化工具ab對服務端的最複雜介面進行了大規模壓力測試，並確認了後端能夠支撐1000人級別的使用者規模。

  單元測試中也對於部分程式碼的效率進行了測試，起到了優化程式碼的作用。

• 在釋出的過程中發現了哪些意外問題？

  • 來自ch同學的hack導致一些alpha階段沒有解決的安全問題被暴露出來，我們及時進行了修復，目前的安全性和使用者鑑權得到了較大幅度的完善和提升
  • 釋出後大幅改動結果從而導致token不可用，使用者被迫重新安裝app。
  • 增量開發存在一些問題，由於C#本身是一種編譯型語言，無法直接在之前版本基礎上進行整合，只能重新更新版本。

3.3 經驗教訓

我們學到了什麼？如果重來一遍會做什麼改進？

yrb

收穫：學習了unity佈局方式，對3d建模和遊戲開發增進了解，實踐體驗軟工專案團隊合作

改進：unity中的版本管理和程式碼規範混亂，coding團隊管理功能待熟悉

fzc

收穫：學習瞭如何利用coding進行敏捷開發專案管理以及持續整合部署。同時熟悉了springboot後端框架，瞭解了redis，mybatis-plus，swagger，netty的基本用法，瞭解了jwt鑑權驗證和基於session的使用者驗證。學習瞭如何整合阿里雲的oss相關sdk以及騰訊雲的簡訊相關sdk。

改進：專案開發流程上需要進行優化，任務管理分配，程式碼複審，測試流程，質量保障都有待完善。

lyyf

收穫：學習了unity的多人網路同步、unity的語音服務

改進：後續攻克相關技術時應更帶有目的性，開發時的團隊協作也應更加規範

lhy

收穫：學習了Unity引擎的使用和C#語言的基本用法，實踐了一些設計模式。

改進：alpha階段對於新功能、新需求的制定流程不夠規範。在beta階段將制定合理的流程規劃每一個功能。

gcy

收穫：學習了unity的基本操作與指令碼的編寫

改進：開發規範有待提高，開發流程的時間分配不夠合理

xwq

收穫：學習了netty框架和jwt鑑權的基礎知識並且應用於專案之中

改進：後端程式碼規範約定不夠細緻，導致前後端中期一些處理沒那麼流暢。在alpha階段結束後重新制定並優化規範，在beta階段嚴格遵循。

tsq

收穫：學習了SpringBoot下使用MockMVC結合JUnit的單元測試方法，學習了使用ApacheBench傳送含header的POST請求進行壓力測試的方法。學習了Unity + XCode打包釋出iOS TestFlight APP的方法。

改進：發現問題之後要及時提issue，能夠提高bug修復的效率。

團隊整體總結

大家在alpha階段都對於自己負責的部分的技術都進行了較為深入的學習，都有了比較多的瞭解，對於敏捷開發的基本流程有了一定的認知。

beta階段需要更明確和完善的設計文件，分工，任務管理，開發測試流程

Part4 團隊角色和管理合作

4.1 分工

• 團隊的每個角色是如何確定的，是不是人盡其才？

  • 整體分工為前端4人，入口網站1人，後端2人，測試&QA一人
  • 基本上達到了較好的效果，每個人的任務基本都在自己的能力範圍內，開發時沒有人遇到了超出能力範圍的需求，也沒有人會覺得自己做的太多或者太少。

• 我們有足夠的資源來完成各項任務麼?各項任務所需的時間和其他資源是如何估計的，精度如何?

  • 由於分工得當，且事先考慮到了前端的難度，因此整體來說資源充足，每個人都能完成自己的目標
  • 時間的估計出現了一些不準確的情況，因為有些任務事先無法評估整體的時間需求，精度有待提升

• 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

  • 由於實際開發時美工設計與文案工作主要交給中傳的專業人員進行製作，所以整體沒有影響我們的開發進度。

• 你有沒有感到你做的事情可以讓別人來做（更有效率）?

  • 前端的部分同學在遇到一些場景內的UI自己不清楚怎麼做時，沒有及時求助lyyf和yrb，導致了自行開發效率較低的情況。後續需要更加統一組內資源，讓每個同學的技術能力得到更大限度的發揮
  • 一些後端介面在除錯和修改時出現了修改他人寫的介面的情況，導致了一些bug。後期需要更加明確後端，測試人員的職責。

前端主要功能需求分工

beta階段大致分工安排

前端

• TD線+人物模型繫結 gcy
• 鋼琴湖 yrb
• 樹洞 lhy
• 好友聊天 fzc
• 小房間（會議廳）+臉部 lyyf
• shader渲染調整 lyyf

後端

• 日常API編寫 xwq
• 伺服器維護與後端程式碼維護 fzc

QA&測試&釋出

• 前端每兩日一測 tsq
• 後端周測 tsq
• ios釋出 tsq
• 安卓釋出 lyyf

4.2 合作

團隊成員之間有互相幫助麼？

• lyyf對於技術的深入研究和調研讓專案沒有卡在關鍵技術難點上，先後解決了多人同步，模型載入，語音聊天等關鍵難題。
• yrb對於UI的接近於強迫症般的要求和佈局研究，帶來了較為統一的介面。同時也帶來了設計精巧的個人空間
• lhy對網路請求以及使用者鑑權和資訊管理的研究，讓前後端對接更加流暢，對於介面統一規範的堅持也讓後端的API定義部分程式碼得到了優化
• gcy持續的嘗試各種demo讓魔方，電影院等功能得以快速實現，同時對UI的統一化做出了重要貢獻
• tsq對後端測試框架的研究，讓嚴謹細緻的單元測試和併發壓力測試的實現成為了可能。同時對於ios端的瞭解也加速了ios端的產品釋出
• xwq對netty框架的研究，讓即時通訊服務得以實現。同時在前期用自己對於springboot開發框架的瞭解讓專案的API構建得以快速進行。
• fzc憑藉對於阿里雲，騰訊雲等的熟悉，以及對於coding平臺的瞭解，讓持續整合以及穩定的後端服務得以實現。同時也不斷跟進前端需求，解決了包括swagger，jwt在內的技術問題。

當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

• 前端指令碼程式碼規範，檔案組織管理需要提前確定好
• 後端制定更詳細的程式碼規範

4.3 每人說一說

• 你覺得目前最需要改進的一個方面是什麼?

  • yrb：程式碼規範，版本管理，要減少自己的強迫症
  • lyyf：明確功能優先順序，讓開發進度加速
  • gcy：個人時間安排需要更加科學合理。後端需要統一對一些介面返回資料的格式定義。
  • lhy：明確功能優先順序，讓開發進度加速
  • fzc：釋出階段需要各位都深入體驗產品，並及時修復bug。平時開發時也儘量安排好個人時間，跟進團隊的開發進度
  • xwq：後端需要協調好一些職責，debug時需要明確自己的修復範圍

• 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

此處採取打分和舉例的形式，滿分3星。在我們的這次開發中，為了描述方便，客戶可以認為是中傳為主的創業團隊。

1. 我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意

   打分：⭐⭐⭐

   舉例：我們在alpha階段通過持續的開發整合，最終釋出了版本，帶來了60多名使用者，使用者群人數達到80+，帶來了一定的使用者積累，同時讓使用者體驗到了初始版本，獲得了許多樂趣。

2. 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

   打分：⭐⭐⭐

   舉例：在設計之初，客戶提出了一些基本功能，而中途在他們的設計完善之後，加入了諸如AR換臉在內的功能，我們也做出了及時調整，讓產品更加有競爭力。

3. 經常性的交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。

   打分：⭐⭐⭐

   舉例：我們每週都會發佈一個新版本供內部包括中傳的美工UI建模同學以及開發人員進行內測。而且每週的版本都是可以正常執行使用的。同時每天服務端會進行一次持續整合，不斷進行單元測試和部署，為客戶端提供資料服務支援。

4. 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。

   打分：⭐⭐

   舉例：開發階段，我們和中傳的同學不斷試用產品，並提出自己的建議。不過由於大家的事務繁忙，並沒有做到每天都一起工作。

5. 圍繞被激勵起來的個人來構建專案。給他們提供所需要的環境和支援，並且信任他們能夠完成工作。

   打分：⭐⭐⭐

   舉例：團隊內部鼓勵成員深入挖掘技術，alpha階段一共有4名同學各自發布了1篇技術部落格，對自己研究的內容進行了深入探討，包含unityUI佈局，多人同步技術調研，後端持續整合部署等。我們信任每個個體，讓每個成員各司其職，並將自己負責的部分研究得透徹深入。

6. 在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。

   打分：⭐

   舉例：這一點做的並不好。因為各種原因，alpha階段我們並沒有做到定期面對面交流，更多的是語音交流，這樣會帶來一些效率問題。不過前端和後端對接時也常常採用語音聊天的形式及時跟進問題，高效解決問題。

7. 工作的軟體是首要進度度量標準。

   打分：⭐⭐

   舉例：alpha階段我們每到一定的階段就會由lyyf打包一個版本供大家使用，從而提升了整體的開發熱情。但是除了周釋出以外的產品並沒有做到都可以完全無明顯bug的執行。

8. 敏捷過程要保持可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。

   打分：⭐

   舉例：alpha階段出現了每週的進度不統一的情況，前期開發進度相對緩慢，第二週的進度卻明顯更快，一方面是由於第一週的技術攻關需要時間，另一方面也是我們沒有做到定期線下集體開發交流問題。

9. 不斷地關注優秀的技能和好的設計會增強敏捷能力。

   打分：⭐⭐⭐

   舉例：後端在開發之前就調研了併發框架，並確定了springboot+netty這一主流方案。使用者鑑權設計之初確定的是利用session，然而之後因為實際開發時發現基於session的認證已經不適用於客戶端服務端結構了，因此調整為更流行的jwt認證方案，從而加速了使用者鑑權功能的實現，提升了穩定性。前端在設計之初想過直接用websocket與後端相連的方式進行多人同步，但是之後發現這樣工作量較大，且自己實現的往往不穩定，因此經過調研使用了unity中的開源框架mirror，高效的解決了多人同步問題。

10. 簡單----使未完成的工作最大化的藝術----是根本的。

    打分：⭐

    舉例：設計之初對於一些功能的描述並不準確，沒有讓每個功能都簡單清晰。

11. 最好的構架、需求和設計出自於自組織的團隊。

    打分：⭐⭐

    舉例：我們團隊雖然是自組織，但是並沒有做到前端的良好架構，原因是一開始沒有確定嚴格的檔案組織規範。

12. 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

    打分：⭐⭐

    舉例：每次例會都會總結一段時間內的工作，但是並沒有每次都進行反省和及時提升。alpha總結階段大家通過線下交流和線上的聊天，暢所欲言，對過去遇到的問題進行了及時反思總結。做出了以下調整：1.完善了使用者鑑權以及服務端安全控制。2.釋出了使用者調查問卷，對需求分析做出完善。3.通過事後總結確定了beta階段的開發測試流程，以及確定了細緻的功能需求。

• 團隊在下一階段應該如何提高軟體工程的質量呢？

  • 程式碼管理的質量具體應該如何提高？ 程式碼複審和程式碼規範的質量應該如何提高？

    更加明確每個人各自的職責，定義清晰的檔案組織管理規範，每兩天做一次程式碼複審和測試。

  • 整個程式的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？

    前端的程式碼架構進行優化，清除無用的程式碼。

  • 其它軟體工具的應用，應該如何提高？

    使用相關外掛進行git版本控制

• 專案跟蹤使用者資料方面，計劃要提高什麼地方？例如你們是如何知道每日/周活躍使用者等資料的？

  記錄使用者每一次的請求日誌，將使用者日誌儲存到資料庫中，從而知道每天和每週的使用者活躍量。

• 專案文件的質量如何提高？

  通過分擔給多個人的方式提升每一部分文件的質量

  通過PM最後的稽核進行進一步美化和修改

• 團隊組織管理， 有什麼具體可以改進的地方？ （關於PM、“人件”、績效考核）

  平時需要更加細緻的使用coding自帶的資料統計功能進行團隊開發管理，細緻的安排需求，任務和程式碼稽核。

  分工上需要安排救火隊員，對於其他同學的技術問題做出及時的增援和回覆。

• 對於軟體工程的理論，規律有什麼心得體會或不同意見？ 請看閱讀作業“這個作業的期中閱讀”

  • 軟體工程其實是一個社會活動。對於我們的專案來說，從誕生之初就不僅僅是一個程式碼層面的工作，還要和包括老師，中傳，清華同學進行不斷地交流與合作，包括功能需求確定，美工UI建模的合作，團隊的宣傳，創業比賽的評審等，都遠遠超出了軟體開發的範圍。但是實際上在真正的軟體工程中，往往就是需要花大量時間來和客戶，使用者，以及除了開發人員以外的市場營銷，美術設計等各方面的同學打交道。這個時候，最好的做法就是定期交流，並不斷給他們釋出我們的體驗版本，讓大家都能有一個很強烈的參與感，及時瞭解專案的進度，都能成為專案的主人。
  • 軟體工程的程式碼質量控制與開發速度其實是一個trade-off。如果過分追求質量而忽視了速度，顯然達不到敏捷開發的持續整合部署的要求。而一味追求速度，短期內可以快速迭代出可用產品，長遠來看卻會帶來很多隱藏問題。因此較好的做法是，在開發之初確定一套相對寬鬆的程式碼稽核，測試，交付標準，在開發過程中根據開發技術的難度和實際情況，做出必要的調整。比如我們的專案在alpha階段，還處於一種技術探索和穩定的階段，因此對於程式碼複審，架構管理，存在些許問題。不過經歷了alpha階段，我們的產品功能更加清晰，技術難關也得到了大部分的解決，需要追求更高層次的程式碼質量問題，而不只是實現功能跑起來這麼簡單。
  • 精確的流程能帶來進度上的統一和更高的工程質量。軟體開發絕不僅僅是幾個人寫好各自程式碼，合併好再部署這麼簡單。而是需要有一個完善的機制來確保整個開發過程順利進行。
  • 面對面的交流很重要。一味的進行線上語音交流雖然能帶來一時的高效，但是帶來不了持久的高效。想要打造高質量的程式碼，需要更頻繁的線下開會交流，更多的面對面互相詢問與回答。

Part5 beta階段開發注意事項

5.1 衝刺階段開發流程

每日開發

以2天為單位，完成一次迴圈

• 開始開發前由PM進行需求分配，每個成員對應一個需求（需要遵守模板）。
• 每個成員將需求進度轉成進行中，將PM表述不清楚的部分按照自己理解進行完善補充，並將需求轉換為自己的具體任務，並根據實際情況確定每個任務優先順序和截止時間（原則上不晚於下一次例會的日期）。開發中完成了某個任務後，先自行對所完成任務進行測試，至少保證自己的任務的基本測試無誤。
• 在完成了兩日內全部任務的測試之後（或者認為已經做完了2日內的工作之後），將之前的需求設為已完成，同時釋出一個測試需求，完善每個需求對應功能的描述，指定任務物件為tsq，等待tsq進行功能測試。
• tsq測試如果遇到了bug，確認是和這個任務本身相關的問題，直接在對應的任務處留下評論並將相關任務設定為進行中，相關人員進行相應修改。如果發現了與所在功能無關的其他bug，釋出一個缺陷給對應人員。（如果不知道給誰就先發給yrb）
• 每兩日例會，例會之前每個人需要明確自己做了什麼，開會後需要大致明確之後兩天需要做什麼。同時釋出在平臺上，確認自己到底要做什麼，自己來給自己定任務

每週構建

• 每週開始之前PM確定本週的大致開發目標，並具體描述出來。
• 每週日內部發布內測版本，要求至少所有安卓使用者都需要進行產品試用，並提出相應缺陷。

5.2 需求模板

開發需求

標題格式為：開發需求-[簡要描述]

具體內容為對於這個開發需求的具體介紹，以一個數字列表形式呈現。

截止日期需要指定為下一次例會開始時間。

功能需求

此需求模板是針對一些奇思妙想的收集

標題格式為：功能需求-[簡要描述]

具體格式包括功能說明+可能的實現方式/技術方案兩個方面

測試需求

標題格式為：測試需求-[簡要描述]

具體內容為一個todo列表，內容為自己完成的功能的簡單描述和對應的issue。大致為功能具體描述：issue編號

截止時間需要指定為下一次例會時間。

5.3 任務模板

標題為：任務簡要描述，比如：聊天服務

每一個任務儘量是不可再分的，即如果再拆分對於自己沒有積極意義。

同時需要包含3個方面，任務具體描述，實現方案（包含設計和具體實現），簡單測試結果（簡單測試用例，在什麼樣的情況下測試無誤）

截止時間需要設定為某次例會時間。

5.4 缺陷模板

標題為bug的簡要描述

具體內容包含bug出現位置、觸發條件、出現頻率、嚴重性。