各团队问题收集

已同步更新到班级Github

2021-04-27

Q: 关于团队分配问题，如果有分配不均的问题，你们怎么解决呢？

一个队长的回复：我们组任务轻的同学 例如两个pm会主动去找前后端同学商量需不需要帮忙写组件或者某种mapping，我们组任务分解完每个人其实都不多 我是有稍微看一下大家任务分配情况的 会主动去补位 就是项目刚开始搭建前端会稍微慢一些 需要熟悉一下环境以及规范之类的 后端已经写出挺多接口了

Q: 关于团队开发的一个tips

项目开始的时候，最好规定好自己的项目所需要的软件版本，比如jdk1.8还是jdk11，nodejs版本等，项目在搭建的时候，最好把大家电脑上的开发环境的版本统一，这样可以避免很多不必要的麻烦。

2021-04-26

Q: alpha冲刺和beta冲刺有界线吗？没有找到这两个冲刺的定义,我们目前是按模块分，alpha阶段完成哪些模块，beta阶段完成哪些模块？不知道alpha冲刺和beta冲刺有没有本质区别？

一个前提：alpha可以重点关注主要功能或者基本功能的完成，保证能用；beta重点关注所界定功能是不是完成或完善，保证好用。如果不能用，一切成空。
至于具体以什么划分，可以先将本软件的核心的几个功能先在alpha阶段搞定 大致可以体现出这个软件的作用 在beta阶段逐步完善整个软件。

北航的做法

2021-04-25

Q：如果团队作业出现返工次数多的问题 无用功要算作功吗 虽然我们组是按照完成进度和任务量双重评判 但是感觉还是很难协调

一个重要结论：返工次数多导致最后作业没有按时完成，它导致的直接结果肯定是团队作业的分数被扣掉。

接下来我们需要明确到底是什么问题导致了返工次数多，由后面的反馈可知，返工次数多的原因在于：

1. a任务需要在b任务完成后在写 比如说输入输出格式我们小组一开始按照原型写 后来接口设计出来后大幅修改 这是一开始负责人对输入输出模块不理解的原因 但是在理解后做针对这次作业来说很耗费时间
2. 工作态度和工作能力问题

那么我们有没有办法避免这两类返工问题呢？我认为可以通过如下的方式来避免：

1. a任务可以先用模拟数据，这样一来，a任务可以不依赖b任务，a和b就可以并行开发了。
2. 接口内容可能会变，但是接口规范可以事先定好（先于业务需求），接口规范定义好以后，可以最大限度防止大规模的接口设计修改，什么是接口规范？可以参考一下这篇文章
3. 团队有个贡献分，对于比较拖后腿的同学，分数没办法，只能打低一些。

Q：Github经常抽风的问题

解决方法有三个：

1. 合理上网
2. 改host
3. 多个时间段多试几次

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: 关键路径图有什么用？

关键路径图是项目管理中的一个工具，团队可以尝试使用，如何用好这个图，可以参考一下这篇文章