怎么取名都不队-Alpha版本事后总结会议

设想和目标

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

我们的软件需要解决的是代码在部署上的困难，在典型用户和典型用户有清晰的描述

1. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

整体上达到了目标

• 原计划中的典型用户与典型场景全部可以满足
• 原计划中的功能完成度约为85%
• 计划的用户量实现了50%

1. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量与原先计划的不是很一致，其原因主要有两个部分

1. 一个是宣发的时间有些仓促
2. 其次是使用逻辑不够自然

但是我们的平台创造了一定的价值，离我们的目标是更近的

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

如果重来一次的话，我们可能会更换前端的技术选型，选择前端同学更熟悉的框架进行开发

同时将部分的研发人力转化为设计、用户体验上

计划

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

有充足的时间来做计划，包括整个系统的设计，以及各模块的功能范围以及交互接口API

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

争论不出结果的话，由PM敲定

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

日志功能和NodeJS的基础镜像没有完成，由于前后端对接出现了一定的延期风险

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

函数调用的鉴权功能，这一个功能实际上不完善，也没什么人用

1. 是否每一项任务都有清楚定义和衡量的交付件?

这个貌似是没有的

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

其中触发器模块的工作量比预期的要高，所以从缓冲区里面挤出了相对应的时间来完成。

没有估计到的原因是由于在设计阶段，仅对宏观的模块方向进行了设计，没有落到细节的地方

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

有留下缓冲区，发挥了大作用

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

将来的计划会更加细致一些，在设计阶段落实到选型与模块联动上

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

把计划的时间提前，留出来的时间用来增加缓冲区和开发时间

资源

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

在Alpha版本存在一定的短缺

首先是时间资源比较紧张

其次是硬件资源也比较紧张，东拼西凑才凑出了两台在一个VPC下的服务器，两台服务器还是一台arm一台amd64的

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

时间资源由PM估计，工作的消耗时间单位为h，消耗时间之外还有预计完成时间，单位为h

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

测试的时间比较紧张，但是我们的测试人员还是完成了预期的测试任务

人力和硬件资源相对短缺

而在启动前没有考虑到美工设计/文案的工作，没有分配对应的人力，有点手忙脚乱

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

PM觉得应该把PM的文档工作交给别人

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

重视UI/UX、文档等工作的人力资源分配，在有需要的时候不再需要挤出人力来

变更管理

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

变更落实到文档，在变更处撰写文档或文档修改处提及的功能实现了

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

重要且难，重要但简单，不重要且难，不重要且简单的排列优先级逐步递减

同时考虑这一功能是不是核心功能，如果不是核心功能不实现会影响多少其它功能

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

这个说实话是没有的，都是靠各个模块的owner自行判断是否准出

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

这个说实话也没有

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

这个问题遇到了，也比较好地处理了

但是实际上是没有预留人力来应对这一个问题的，需要改进

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

预留人力富余应对可能变更

设计/实现

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

设计工作是在项目的初期，由PM整体设计后，各模块的owner对内部实现再次进行设计的

时间合适、人也合适

但是对于开发小组的分配存在一定的问题，不应该在前后端上进行分组，应该按照模块分组，将模块内的前后端都整合为一个小组

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

在设计用户验证码认证的流程时有出现了模棱两可的情况，当时由后端开发同学编写了流程文档拉齐的

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

有利用单元测试例如pytest、gotest等

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

我们各模块的BUG都不是很多，前端在对接的时候出现了很多bug

问题出在技术选型并非前端同学擅长的框架导致

发布之后出现了两个bug

1. 在依赖项中填入python的内置依赖包会由于镜像源中并不存在对应镜像启动失败，这个是设计逻辑导致的，应更改依赖安装环节的位置

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

代码复审由模块owner实施

python代码规范：PEP 8: The Style Guide for Python Code

go代码规范：Effective Go - The Go Programming Language

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

在实现的过程中的对齐实际上以短会议的形式会更高效一些，在接下来的工作中应该提高会议的比例

测试/发布

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

有的亲，我们有测试专员

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

有的亲，我们有测试专员

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

有的

1. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

使用了jmeter，有用

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

发布后，因为PM偷懒想实时看数据库里面注册用户量没有关掉3306端口，导致数据库被偷家了

还好只是评审团偷的，没有造成大的事故

我们学到了什么? 如果重来一遍, 我们会做什么改进?

团队的角色，管理，合作

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

在Alpha阶段我们发布了期望角色问卷，在尽可能满足第一志愿的情况下，满足人类需求的安排

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

有的，Alpha阶段开发小组遵循老带新的分配，由一个开发经验较丰富的同学带领一个开发经验相对薄弱的同学进行开发。

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

找PM进行协调或重组

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

CMM中的可重复级，在Beta版本的计划中会沿用Alpha版本的基本流程进行开发

CMMI中的已管理的，过程为项目服务

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

在Alpha阶段是萌芽阶段，存在着分工未完全执行的情况

在Beta版本应该进入磨合的阶段

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

没有前一个里程碑qaq

你觉得目前最需要改进的一个方面是什么?

人力分配需要改进，人力是一些工作的基础

应该把人力分配到文档、UI/UX上

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

在触发器需求出现预期之外变化的时候，进行重新设计和执行，实现了能够良好配合其它模块实现功能的模块

• 原则7：可工作的软件是衡量进度的首要标准

不设置汇报，以MR和代码作为完成标准

• 原则9：坚持不懈地追求技术卓越和设计优越，以此增强敏捷的能力

追求模块稳定性

利用微服务设计实现单一模块的crash不会影响其他模块的基础功能

通过ORM框架转译避免SQL注入

利用自动化测试工具对软件进行功能以及压力测试

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 将go部分的代码加入测试与覆盖率统计的流程中，集成基础的go test/go conv/go fmt工具管理go代码的格式规范
2. 将程序的部署Kubernetes容器化，摆脱Docker单一副本部署的方式，利用Kubernetes的能力实现多副本部署与负载均衡，其中部分收益可以体现在访问延迟上，但是对于稳定性上暂无可以量化质量变化的方法
3. 项目管理中的模块管理更清晰地展现项目实施的依赖关系与先后顺序
4. 将原有的手工化查询调用次数的方法封装，可视化展示
5. 将文档同步为md文档放入仓库中以支持私有化部署
6. 提高短会议交流比例，弥补纯文档交流的局限性