Beta 事后分析

设想和目标

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

我们要解决的问题是目前编辑文档 markdown 文档中的缺陷。它包括三个部分：

• 对于文档内编辑，将 md 文档解析成一个树形结构，直观展示文章的架构。
• 对于联合编辑，将多个文档的树结构进行并行展示，然后编辑。
• 对于文档间编辑，展示多样性的文档间联系，并提供转换方式。

我们觉得经过多次打磨设计书，这里的定义是清楚且直观的。

对于典型用户和典型场景有清晰的描述。

2.我们达到目标了么？

我们原计划的功能全部完成了。

我们按照原计划交付了，但是实际上举例我们理想的完全版的开发，其实是差了大约 3 天的时间的。

用户数量远远超过我们的原计划。

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

我们认为是提高了的。

在团队管理合作方面，经过了 alpha 阶段的磨合，大家的合作更加顺畅了，比较明显的就是组会和线下结对的时间变短了。

在文档方面，文档去掉了 alpha 阶段的一些冗杂的狂想，更加务实和技术人员友好。

在实现方面，在扩大了实现的规模后，我们的代码质量依然和 alpha 的评分相近，说明了质量的提高。

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

用户量超过了预期。

用户对于重要功能的接受程度和我们预想得差不多，我们收到了多个对于特色的榕功能的称赞。

应该说我们离目标更远了。因为经过 beta 的发布后，我们意识到了更多会影响用户使用体验的东西，只能说，革命尚未成功，同志仍需努力。

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

不要发错宣传文案（手动狗头）。

我们觉得其实最大的经验教训是目前的选题还是工作量过大了。富文本编辑器本来就是软件开发的天坑，更何况是一个有特色功能的富文本功能编辑器。

如果历史重来一遍，我们会做出很多改进，比如说在 alpha 就可以避免一些盲目的踩坑，或者在 beta 预留出更多的缓冲时间。但是正如上文分析的，这个选题的工作量太大了，如果想真正的改进，那么其实应该减少工作量，比如去掉一些功能。

---

计划

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

是有的，我们 beta 阶段的计划做得十分充分，不仅更加详细务实，而且吸取了 alpha 阶段的教训。

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

我们的计划主要还是由 PM 和美工两个人来完成的，相对来说并不是完全民主的，架构师确保了计划的可行性问题。其他人的意见也会被考虑。

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

我们的计划功能都开发完全了，我们有一些遗留问题（一般是一些功能加强功能和像 feature 的 bug）：

• 没有开发出即时渲染功能，这是因为我们的能力只允许在“富文本模式”和“即时渲染模式”中选择一个开发。
• 一些渲染问题，这是 lute 插件本身的问题。
• 启动时的页面打开逻辑，这个部分工作量极大，我们就用了一个较为简单的逻辑。
• 榕图编辑过程中的刷新会导致视觉效果不佳，我们没有找到更加合适的插件。

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

没有很没有价值的事情，有一些事情确实是弯路，比如说我们在 alpha 的时候用的插件很烂，我们在 beta 的时候产尝试过很长一段时间去修他，后来直接换掉了这个插件。

但是并不能说前面这个插件是完全没用的，它让我们更加明确我们需要的插件是什么样子的，需要具有哪些特点。

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

是的，我们有使用测试，单元测试，issue 描述，文档定义等多个关卡把关。

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

我们有人阳了，有人夏令营，有人烤漆，有人竞赛。

我们预料到了夏令营和竞赛，但是烤漆提前和新冠确实没有估计到。

因为往年烤漆确实没提前，新冠这个我也不知道为啥没有估计到。

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

是留了缓冲区的。

缓冲区的作用是为了有可能的竞赛和夏令营事宜准备的，同时还有常规的普通缓冲区。是起了作用的，我们这些地方都出现了一些波动，所以用掉了缓冲区。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

接下来就没有缓冲区了，因为 beta 结束了，之后的维护就是大家在空闲时间做的。就没有冲刺阶段。

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

学到了“缓冲区永远不够用”。

其实已经没有办法了，在保证原有目标的情况下，我们只能接受这么大的缓冲区。

如果说一定要有改进，那么就是将目标变得更小一些吧。

---

资源

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

有足够资源，只是没有 alpha 多。时间、人力、设计、团结，都是有的。

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

是根据这个任务的难度还有 alpha 的实践估计的，我们的一些功能其实已经在 alpha 做过 demo 了。

精度还不错，基本上都是估计准确的。

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

发布前的测试的时间稍微显得不足，这是因为我们遭遇了新冠和烤漆提前的悲剧，所以测试的资源稍有不足。

没有太低估难度，因为 PM 就是负责估算难度的，他刚好不编程，他甚至高估了自己的难度（手动狗头）。

因为我们的设计，文案，宣发都是全组最肝的两个人负责的，所以基本上没有因为低估或者高估给其他人造成不利影响。

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

基本上没有，在 alpha 总结了经验，所以大家的分工很正常。

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

我们的分工比较“正交”，这导致如果一个人进度慢了，那么其他人没法很好的代替它的工作。

基本上没有办法改进，因为确实功能太多了。

---

变更管理

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

是的，我们有两种信息通知方式，一种是 github issue，一种是 notion ，这两种方式都可以绑定邮箱，很容易获取变更。

此外 PM 会关注大家的动态，如果工作进程没有表示出它知道了这个变更，PM 会私聊提醒。

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

采用实现人员和 PM 协商的方式，其基本原则是，如果不影响基本功能，都是可以推迟的。

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

是有的，我们的 PM 和架构师会规定好。

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

有缓冲区设计，也有应急计划（设置对于需求也有低版本计划）。

但是最后依然有一些小崩。

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

能，是可以的，这个部分我们做得很好，在 beta 开发阶段，经常有人会与我们提 issue 或者在用户群中反馈问题和需求，我们都能较好的处理，这和大家对于软件尽职尽责的态度是分不开的！

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

如果将出口条件再细致一些，也就是使用 bug 修好时的出口条件，这个部分没法再规划阶段做，所以做得较差。

---

设计/实现

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

设计工作是在 alpha 阶段完成了大部分，在 beta 阶段开始的一周完善了细节。

由 PM 和美工完成。

在具体实现钱完成，所以是合适的时间。

由对于产品设计理念有整体把握的 PM 实现，是合适的。

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

有的，PM 没有写清楚规格说明书。

负责实现的同学会向 PM 询问模糊的行为。

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

团队主要采用单元测试+集成测试的方法进行测试，使用了Uml绘制工具辅助实现。单元测试是最有效的，保证了在重构代码、增加功能等操作中不会出现严重问题；Uml文档作用有限，因为我们在项目开发中需求变化较为频繁，且对项目本身缺乏基于经验的认知。

与开发时候相比，我们UML文档已经产生了较大变动。这种变动来源于功能的增加，全新的需求导致架构上不得不进行响应的变动。但是项目整体架构因为初级进行了大量的调研，实际上变动不大，所以对UML文档的更新有限。

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

富文本渲染的 bug 最多，因为这个部分用户的自由度最高，会有很多的行为，而且这个部分是由其他人开发的，所以我们的控制力比较差。

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

我们通过 github 的 pull request review 机制进行。需要指定适合且对于 pr 较为了解到 reviewer。

严格执行了代码规范，我们这个部分是自动化风格，如果不能通过代码规范测试，则不能合并 pr。

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

富文本编辑器好难啊！

如果重来，可能我们的项目就变成了开发一个富文本编辑器，而不是用现有的富文本编辑器插件实现一个 Ficus。

---

测试/发布

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

是有的，我们很注重测试。

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

进行了，只不过稍微迟了一些，我们在 beta 先行版发布时仅进行了使用测试，但是没有进行全面的验收测试。

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

单元测试框架 mocha。

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

使用 chromium 自带的profiler，打开模板大文件，对软件性能进行测试，测量渲染时间、模式切换时间等。对于压力测试，多次复制模板大文件，检查软件是否崩溃并对性能进行检查。

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

发布的文案弄错了，把竞品分析放到宣发网站上了，又因为不知道为啥没法删帖子，蹲了一天给大家道歉。

---

团队的角色，管理，合作

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

根据之前的开发经历、个人喜好、能力和团队需要综合考虑进行确定。

应该是比较人尽其才的。比如我们的架构师是 OO 助教，对于整个软件开发很熟悉。美工又很好的美术素养。PM 比较有想法，而且擅长写文档和团结大家。主力实现人员都很肝。自由人啥都会。

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

当然有了，我们不仅有普通的互相帮助，我们还专门增设了“自由人”的岗位负责救火。

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

会议协商，讨论解决方案，挑选一个相对最优解。

---

总结

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

目前我们属于CMMI中的第三级，明确级。

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

我们目前处于创造阶段。我们拥有完善的开发、沟通和管理流程，团队成员知道自己的分工，具有自我驱动精神和能力。

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

团队的后续开发问题。

大家冲刺太累了，我们不确定还有没有足够的热情继续维护这个项目。

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

• 删除重复代码、简化复杂的代码、提取通用的代码
• 编写单元测试和集成测试
• 定期进行代码审查和反馈
• 提高代码覆盖率
• 增加注释。

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

• 更加丰富具体的文档。
• 更加优秀的代码架构。
• 更加明确的原型设计。
• 深度思考交互逻辑。

6. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

• 日活量。
• 我们目前没有办法，这个东西做出来可能会导致安全漏洞。

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

• 使用简洁、明确和易于理解的语言编写文档，确保文档有清晰的结构。
• 专人管理，其他成员校对的方式。

8. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

• 我们需要创造一个积极的、鼓励创新的工作环境。
• 培养团队精神，促进队员的密切合作。