各團隊問題收集

已同步更新到班級Github

Q: 關于團隊配置設定問題，如果有配置設定不均的問題，你們怎麼解決呢？

一個隊長的回複：我們組任務輕的同學 例如兩個pm會主動去找前後端同學商量需不需要幫忙寫元件或者某種mapping，我們組任務分解完每個人其實都不多 我是有稍微看一下大家任務配置設定情況的 會主動去補位 就是項目剛開始搭建前端會稍微慢一些 需要熟悉一下環境以及規範之類的 後端已經寫出挺多接口了

Q: 關于團隊開發的一個tips

項目開始的時候，最好規定好自己的項目所需要的軟體版本，比如jdk1.8還是jdk11，nodejs版本等，項目在搭建的時候，最好把大家電腦上的開發環境的版本統一，這樣可以避免很多不必要的麻煩。

Q: alpha沖刺和beta沖刺有界線嗎？沒有找到這兩個沖刺的定義,我們目前是按子產品分，alpha階段完成哪些子產品，beta階段完成哪些子產品？不知道alpha沖刺和beta沖刺有沒有本質差別？

一個前提：alpha可以重點關注主要功能或者基本功能的完成，保證能用；beta重點關注所界定功能是不是完成或完善，保證好用。如果不能用，一切成空。 至于具體以什麼劃分，可以先将本軟體的核心的幾個功能先在alpha階段搞定 大緻可以展現出這個軟體的作用 在beta階段逐漸完善整個軟體。

北航的做法

Q：如果團隊作業出現返工次數多的問題 無用功要算作功嗎 雖然我們組是按照完成進度和任務量雙重評判 但是感覺還是很難協調

一個重要結論：返工次數多導緻最後作業沒有按時完成，它導緻的直接結果肯定是團隊作業的分數被扣掉。 接下來我們需要明确到底是什麼問題導緻了返工次數多，由後面的回報可知，返工次數多的原因在于： a任務需要在b任務完成後在寫 比如說輸入輸出格式我們小組一開始按照原型寫 後來接口設計出來後大幅修改 這是一開始負責人對輸入輸出子產品不了解的原因 但是在了解後做針對這次作業來說很耗費時間 工作态度和工作能力問題 那麼我們有沒有辦法避免這兩類返工問題呢？我認為可以通過如下的方式來避免： a任務可以先用模拟資料，這樣一來，a任務可以不依賴b任務，a和b就可以并行開發了。 接口内容可能會變，但是接口規範可以事先定好（先于業務需求），接口規範定義好以後，可以最大限度防止大規模的接口設計修改，什麼是接口規範？可以參考一下這篇文章 團隊有個貢獻分，對于比較拖後腿的同學，分數沒辦法，隻能打低一些。

Q：Github經常抽風的問題

解決方法有三個： 合理上網 改host 多個時間段多試幾次 PS：這裡也推薦大家可以多次commit，然後一次性push，不需要每次commit都要立即push

Q：有同學的項目是前後端是分離的，可否開兩個倉庫友善CI/CD和release？

沒問題，項目倉庫的組織方式有很多種： 分多個倉庫，比如：一些前後端分離的項目；微服務項目（每個微服務一個倉庫） 單倉庫模式。典型的如：Google，可以檢視這篇文章: Why Google Stores Billions of Lines of Code in a Single Repository 子子產品方式。 比如：Skywalking, 它的前端就是用子子產品方式管理的。 這些組織方式沒有絕對的好壞之分，團隊根據自己的情況選擇任何一種适合自己的方式都可以。

Q: 稽核工作大家是怎麼展開的呢 我們小組這次作業下設了負責人 然後在稽核階段沒有将出現問題的部分稽核出來 （可能是不認真）于是他提出 是否要讓參與的同學都稽核 因為部分工作負責人并沒有參與 不能明确是否合理 可是開會現狀是參與的同學隻會關注自己的闆塊有沒有問題

這個問題，可以引用群裡另外一個隊長回複： 稽核一般都讓負責那個子產品的人共同去負責吧，因為很難去讓所有人都能了解所有。就跟代碼規範一樣，讓他們自己先自己提前商量一個規範。盡量每個子產品有一個了解的較多的人進行負責。

Q: 關鍵路徑圖有什麼用？

關鍵路徑圖是項目管理中的一個工具，團隊可以嘗試使用，如何用好這個圖，可以參考一下這篇文章