怎么取名都不队-Beta版本事后会议

1. 设想和目标

2. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

在Beta版本，我们的软件要解决的是在集群环境下部署服务的应用场景下，服务间的环境冲突的问题和，对CPU、内存、GPU等计算资源的分配问题。

1. 我们达到目标了么？

我们达到了我们的目标

• 我们向系统中集成了适配集群的服务管理系统、文件系统以及我们开发的服务
• 我们的软件可以让用户对集群中的CPU、Mem、GPU资源配额进行申请和使用。
• 并且加入了管理员角色，让有经验的人可以借助我们的系统为一个团队提供技术设施支持。
• 我们给出了便捷的部署方式，将部署耗时缩短至原来的1/10

1. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

我们提高了非常多。

在软件工程质量上，经由Alpha版本暴露出来的一些合作，协同和管理上的问题，在Beta版本都得到了很大的解决。同时，我们在Beta版本更加善于使用CI来保证团队软件工程的最低质量，使得每一份提交的代码都是满足如单元测试等要求之后才合并的。

因此，在后续测试人员测试时，在BUG发现和测试指标上，Beta版本相较于Alpha版本都有了长足的进步。

1. 计划

2. 是否有充足的时间来做计划?

有充足的时间来做计划，在Alpha版本的反思总结周，我们就开始着手计划Beta版本

完成了包括功能、技术规格；任务划分与依赖确认；分工；新版本前端与分工等计划。

1. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

先行沟通，沟通时看不到达成共识的希望则由PM敲定

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

除日志外其余的都完成了

日志功能存在现有功能可替代的特点，而且完成复杂度较高，性价比低，因为人力限制就取消了

1. 有没有发现你做了一些事后看来没必要或没多大价值的事?

在租赁机器部署虚拟机进行开发的时候并不是特别必要。

因为在Beta版本实际上我们已经从设计上保证了我们的软件是支持多节点部署的

可以直接在软件所提供的两台服务器上进行开发或者直接在本地单机进行开发

远程+虚拟机的开发体验并不佳

1. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

在开发阶段整个过程都在按照计划进行，但是在准备部署和展示的时候出现了意外

1. 国内访问Docker Hub速度很慢，不稳定，推拉镜像的时候容易卡住或断链
2. 最后做出来的ChatGLM镜像太大了，几乎不可能推到Docker Hub上，需要额外花费时间本地部署Harbor来装镜像

没有估计到的原因是对于部署没有进行提前准备和计划

1. 在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，吸收上次倒排需求的经验教训，这次使用了正排的需求，对需求预留了缓冲。

1. 将来的计划会做什么修改？

将来我们会对功能进行更加详细的设计，两个版本的开发由于时间关系，设计的粒度并不是很细致，在未来时间充裕的条件下，会进行更细粒度的设计，并争取将全流程（包括设计开发测试）的计划进行集成。

1. 资源

2. 我们有足够的资源来完成各项任务么?

有足够的以下资源来完成各项任务：

• 开发所需要的硬件资源
• 业务所需的技术储备
• 开发的人力资源

1. 各项任务所需的时间和其他资源是如何估计的，精度如何?

和Alpha版本又PM估计，精度精确到小时

1. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

由于时间有一定的压缩，测试的时间也同样受到了一定的压缩

对于其他的不需要编程的资源，我们并没有低谷难度，也分配了相应的人力来做

1. 你有没有感到你做的事情可以让别人来做（更有效率）?

在Beta版本，新一版的工作分配后就没有这个问题了

1. 变更管理

2. 每个相关的员工都及时知道了变更的消息?

是的，和前一个版本一样，这一版本我们也会为每一个变更留存文档和通知全体

1. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

面向典型用户与应用场景来看，如果在典型应用场景中出现的功能则为必须实现的功能，其余的辅助必须实现的功能就是可以推迟的功能。

1. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

出口条件为：通过测试人员为这一个方法/模块设计的所有测试样例

1. 对于可能的变更是否能制定应急计划?

能，Beta版本只通过仅会增加工作量的变更，如果需要对已出口的模块进行修改的变更是不予通过的

1. 员工是否能够有效地处理意料之外的工作请求？

可以的，如果工作只是临时性的，不需要花费太多时间的话

1. 设计/实现

2. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

Beta阶段的设计分为两个部分

• 项目结构设计：由PM在Beta阶段的开始进行设计
• Web页面设计：由UI/UX和前端负责同学在前端设计阶段设计

是合适的人选，也是合适的人

1. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计工作不存在模棱两可的情况，因为设计的人和实现的人存在重合

1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

团队运用了单元测试，但并未运用TDD和UML这些工具。单元测试有效，能够帮助发现一些可能的bug，节约联调时花费的时间。

1. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

项目相关的功能，因为他是最复杂的功能。发布之后未发现非常严重的BUG。

1. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

Code Review与Alpha版本一致，由前端/后端的小组负责人负责，负责人则由剩下的同学进行review

面对代码规范不一致的情况，在开发阶段需要被打回修改，但是在测试修复的时候执行有一定疏漏

1. 测试/发布

2. 团队是否有一个测试计划？为什么没有？

团队在Beta版本的测试方案Beta

1. 是否进行了正式的验收测试？

进行了正式的验收测试，并定义了出口条件，对照条件来验收我们的程序是否可行。但未作其他处理。

1. 团队是否有测试工具来帮助测试？

除了单元测试中常规使用的mock, fake, go test, pytest等相关框架。负载/压力测试部分使用了Jmeter进行测试与结果分析。

1. 在发布的过程中发现了哪些意外问题？

• Docker Hub连接不够文档，出现拉取镜像超时的情况
• 租用服务器时磁盘空间选太小了，存在了磁盘压力过高的情况

1. 团队的角色，管理，合作

2. 团队的每个角色是如何确定的，是不是人尽其才？

由Alpha版本各同学展现出来的擅长处决定，在Beta版本更大程度的人尽其才

1. 团队成员之间有互相帮助么？

有的，同技术栈内的调试等工作为互相帮助

1. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

需要由PM来协调

1. 总结:

2. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

• 在Beta版本的源代码中文档还是有所欠缺，应该对源代码进行整理和编写文档，并将散落在各地的源代码链接聚合在同一个仓库
• 代码复审时，目前仅对一些局部范围内的，可能出现错误的写法、边界条件的检查、代码风格等检查，应该对于函数调用的签名也熟悉一下，检查一下调用的检查
• 代码规范中Go的函数和方法分解不是特别清晰，应该更加注意

1. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

程序的可靠性上还有可以提高的空间

• Webshell的端口占用关系在本地维护，导致计算资源管理模块无法多副本部署，应该支持一些分布式缓存让计算资源管理模块也能够多部分部署，提高可靠性
• 例如MySQL、Redis、Rabbitmq没有配置分布式部署的机制，在未来应该可以配置主从，进行分布式部署，提高可靠性
• 衡量质量的提高主要看模块在不影响功能的前提下能够承受什么程度的事故，在Alpha版本满足了对于任意模块挂掉后不影响其他模块的功能，在Beta版本除了计算资源管理模块外，其它模块挂掉部分实例并不会影响该模块的功能

1. 其它软件工具的应用，应该如何提高？

可以提高飞书文档的使用灵活性，搭建更直观清晰、重点突出的进度看板等内容

1. 项目管理有哪些具体的提高？

相对于Alpha版本来说，Beta版本新增了PERT图来展现子功能之间的依赖关系

但是由于Beta版本的时间不确定性因素太多没有对各功能的时间区间进行约束

1. 项目文档的质量如何提高？

项目目前的可维护性仍然由代码的可读性、接口文档、部署文档支撑，应该补充上开发文档等内容

1. 对于人的领导和管理， 有什么具体可以改进的地方？

对人对领导和管理，应该不用对人的自驱力抱有期望，应该给出足够的输入、和给定输出的时间期限、规范标准，依赖自驱力很难产出符合要求的东西。

1. 设想和目标

2. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

在Beta版本，我们的软件要解决的是在集群环境下部署服务的应用场景下，服务间的环境冲突的问题和，对CPU、内存、GPU等计算资源的分配问题。

1. 我们达到目标了么？

我们达到了我们的目标

• 我们向系统中集成了适配集群的服务管理系统、文件系统以及我们开发的服务
• 我们的软件可以让用户对集群中的CPU、Mem、GPU资源配额进行申请和使用。
• 并且加入了管理员角色，让有经验的人可以借助我们的系统为一个团队提供技术设施支持。
• 我们给出了便捷的部署方式，将部署耗时缩短至原来的1/10

1. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

我们提高了非常多。

在软件工程质量上，经由Alpha版本暴露出来的一些合作，协同和管理上的问题，在Beta版本都得到了很大的解决。同时，我们在Beta版本更加善于使用CI来保证团队软件工程的最低质量，使得每一份提交的代码都是满足如单元测试等要求之后才合并的。

因此，在后续测试人员测试时，在BUG发现和测试指标上，Beta版本相较于Alpha版本都有了长足的进步。

1. 计划

2. 是否有充足的时间来做计划?

有充足的时间来做计划，在Alpha版本的反思总结周，我们就开始着手计划Beta版本

完成了包括功能、技术规格；任务划分与依赖确认；分工；新版本前端与分工等计划。

1. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

先行沟通，沟通时看不到达成共识的希望则由PM敲定

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

除日志外其余的都完成了

日志功能存在现有功能可替代的特点，而且完成复杂度较高，性价比低，因为人力限制就取消了

1. 有没有发现你做了一些事后看来没必要或没多大价值的事?

在租赁机器部署虚拟机进行开发的时候并不是特别必要。

因为在Beta版本实际上我们已经从设计上保证了我们的软件是支持多节点部署的

可以直接在软件所提供的两台服务器上进行开发或者直接在本地单机进行开发

远程+虚拟机的开发体验并不佳

1. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

在开发阶段整个过程都在按照计划进行，但是在准备部署和展示的时候出现了意外

1. 国内访问Docker Hub速度很慢，不稳定，推拉镜像的时候容易卡住或断链
2. 最后做出来的ChatGLM镜像太大了，几乎不可能推到Docker Hub上，需要额外花费时间本地部署Harbor来装镜像

没有估计到的原因是对于部署没有进行提前准备和计划

1. 在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，吸收上次倒排需求的经验教训，这次使用了正排的需求，对需求预留了缓冲。

1. 将来的计划会做什么修改？

将来我们会对功能进行更加详细的设计，两个版本的开发由于时间关系，设计的粒度并不是很细致，在未来时间充裕的条件下，会进行更细粒度的设计，并争取将全流程（包括设计开发测试）的计划进行集成。

1. 资源

2. 我们有足够的资源来完成各项任务么?

有足够的以下资源来完成各项任务：

• 开发所需要的硬件资源
• 业务所需的技术储备
• 开发的人力资源

1. 各项任务所需的时间和其他资源是如何估计的，精度如何?

和Alpha版本又PM估计，精度精确到小时

1. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

由于时间有一定的压缩，测试的时间也同样受到了一定的压缩

对于其他的不需要编程的资源，我们并没有低谷难度，也分配了相应的人力来做

1. 你有没有感到你做的事情可以让别人来做（更有效率）?

在Beta版本，新一版的工作分配后就没有这个问题了

1. 变更管理

2. 每个相关的员工都及时知道了变更的消息?

是的，和前一个版本一样，这一版本我们也会为每一个变更留存文档和通知全体

1. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

面向典型用户与应用场景来看，如果在典型应用场景中出现的功能则为必须实现的功能，其余的辅助必须实现的功能就是可以推迟的功能。

1. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

出口条件为：通过测试人员为这一个方法/模块设计的所有测试样例

1. 对于可能的变更是否能制定应急计划?

能，Beta版本只通过仅会增加工作量的变更，如果需要对已出口的模块进行修改的变更是不予通过的

1. 员工是否能够有效地处理意料之外的工作请求？

可以的，如果工作只是临时性的，不需要花费太多时间的话

1. 设计/实现

2. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

Beta阶段的设计分为两个部分

• 项目结构设计：由PM在Beta阶段的开始进行设计
• Web页面设计：由UI/UX和前端负责同学在前端设计阶段设计

是合适的人选，也是合适的人

1. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计工作不存在模棱两可的情况，因为设计的人和实现的人存在重合

1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

团队运用了单元测试，但并未运用TDD和UML这些工具。单元测试有效，能够帮助发现一些可能的bug，节约联调时花费的时间。

1. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

项目相关的功能，因为他是最复杂的功能。发布之后未发现非常严重的BUG。

1. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

Code Review与Alpha版本一致，由前端/后端的小组负责人负责，负责人则由剩下的同学进行review

面对代码规范不一致的情况，在开发阶段需要被打回修改，但是在测试修复的时候执行有一定疏漏

1. 测试/发布

2. 团队是否有一个测试计划？为什么没有？

团队在Beta版本的测试方案Beta

1. 是否进行了正式的验收测试？

进行了正式的验收测试，并定义了出口条件，对照条件来验收我们的程序是否可行。但未作其他处理。

1. 团队是否有测试工具来帮助测试？

除了单元测试中常规使用的mock, fake, go test, pytest等相关框架。负载/压力测试部分使用了Jmeter进行测试与结果分析。

1. 在发布的过程中发现了哪些意外问题？

• Docker Hub连接不够文档，出现拉取镜像超时的情况
• 租用服务器时磁盘空间选太小了，存在了磁盘压力过高的情况

1. 团队的角色，管理，合作

2. 团队的每个角色是如何确定的，是不是人尽其才？

由Alpha版本各同学展现出来的擅长处决定，在Beta版本更大程度的人尽其才

1. 团队成员之间有互相帮助么？

有的，同技术栈内的调试等工作为互相帮助

1. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

需要由PM来协调

1. 总结:

2. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

• 在Beta版本的源代码中文档还是有所欠缺，应该对源代码进行整理和编写文档，并将散落在各地的源代码链接聚合在同一个仓库
• 代码复审时，目前仅对一些局部范围内的，可能出现错误的写法、边界条件的检查、代码风格等检查，应该对于函数调用的签名也熟悉一下，检查一下调用的检查
• 代码规范中Go的函数和方法分解不是特别清晰，应该更加注意

1. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

程序的可靠性上还有可以提高的空间

• Webshell的端口占用关系在本地维护，导致计算资源管理模块无法多副本部署，应该支持一些分布式缓存让计算资源管理模块也能够多部分部署，提高可靠性
• 例如MySQL、Redis、Rabbitmq没有配置分布式部署的机制，在未来应该可以配置主从，进行分布式部署，提高可靠性
• 衡量质量的提高主要看模块在不影响功能的前提下能够承受什么程度的事故，在Alpha版本满足了对于任意模块挂掉后不影响其他模块的功能，在Beta版本除了计算资源管理模块外，其它模块挂掉部分实例并不会影响该模块的功能

1. 其它软件工具的应用，应该如何提高？

可以提高飞书文档的使用灵活性，搭建更直观清晰、重点突出的进度看板等内容

1. 项目管理有哪些具体的提高？

相对于Alpha版本来说，Beta版本新增了PERT图来展现子功能之间的依赖关系

但是由于Beta版本的时间不确定性因素太多没有对各功能的时间区间进行约束

1. 项目文档的质量如何提高？

项目目前的可维护性仍然由代码的可读性、接口文档、部署文档支撑，应该补充上开发文档等内容

1. 对于人的领导和管理， 有什么具体可以改进的地方？

对人对领导和管理，应该不用对人的自驱力抱有期望，应该给出足够的输入、和给定输出的时间期限、规范标准，依赖自驱力很难产出符合要求的东西。

会议截图