各团队问题收集

已同步更新到班级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: 关键路径图有什么用?

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

posted @ 2021-04-25 23:25  Grey Zeng  阅读(63)  评论(0编辑  收藏  举报