团队事后分析

Posted 2022-02-09 tbqjxjkwg

设想和目标

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

Gamma阶段原计划的密码找回功能，排名功能，移动端的适配功能等均做到了，按照时间交付了，原计划的目标用户200已经达到，目前Django后台记录的数目为243个用户。

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

整个团队的软件工程质量提高了，我们有WIKI来保存所有的完整文档，所有的文件均有完整的注释，并且通过Code Review，测试保证等方式确保了代码质量。

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

这个阶段我们确定了任务的优先级，改进了燃烬图，加了任务总量这条曲线，PM能更好地把控任务进度。因为家庭的原因，PM有段时间未在学校，如果重来一遍的话，PM应该会更加注重进度的把控，随时push团队成员。

计划

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

我们在每个阶段的末尾都会提前讨论下一阶段的任务，在阶段的开始又会再次确定好阶段任务，因此是有充足的时间来确定计划的。

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

我们都是当面讨论，讨论任务的可行性和复杂性，针对大家提出的考虑来判断是否要做这个任务。

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

都做完了，只是部分任务的完成度没有太高，因为时间还是有一定的不足。

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

前端的分页功能，实现起来太过于复杂，总是出问题，其实现在觉得让后端分页更简单。

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

有。每个任务都确定了优先级以及相关人员。

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

基本按照计划进行。安全性问题在Alpha初期没有考虑到，准备添加在Beta阶段任务中，但是在Alpha阶段末尾网站突然被攻击，因而采取了一定的紧急措施，恢复了网站的正常功能，避免了再次被攻击。

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

留下了一定的缓冲区。任务执行时出现突发情况时，缓冲区就能够避免任务总体进度出问题。

资源

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

完成所有基本功能的资源足够，但是在完成一些比较麻烦的功能例如移动端适配的时候，时间不太足够因而不太完美。

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

主要是由开发和测试人员依据Alpha，beta的经验来估计，精度比较准确。

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

资源足够，对移动端的适配低估了难度。

变更管理

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

我们组变更管理部分做的比较好，我们主要通过微信群进行交流，因此项目任务有变更时团队成员很快就能获知。

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

我们使用了自己设计的燃尽图，其中有一项是当前任务总数，PM能抓住重点，及时判断任务能否完成，进而将下一阶段的任务提前或者砍掉某个任务。当某阶段任务稳定并且全部完成后，就达到了该阶段的出口条件。

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

我们有一定的应急计划，比如我们在网站受到攻击时，应急修复，在1.5小时就让网站成功重新上线，尽可能减少了用户的损失。团队对于这类意料之外的任务处理起来也比较顺利，队员能主动认领，有效处理。

设计/实现

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

后端的设计工作是在后端的线上会议的时候敲定的。设计由后端的两位同学，结合项目具体情况，共同拟定。前端的设计工作是由UI和前端开发成员你一起决定的。

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

在设计中，我们遇到了这样的情况。比如，原项目中，并没有采取前后端分离的设计方式，而是由后端全部完成，返回html给前端。我们在发现了这个设计之后，经过讨论，觉得不符合我们的项目设计。决定更改整体的设计。

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

后端的代码复审，通常是一位后端的开发在完成了自己的任务后，通过issue或者即使通讯软件的形式，联系另一位后端开发同学，通知他开发已经完成。再交付测试同学之前，另一开发同学需要阅读实现了的代码，结合已经拟定好的后端接口文档，以及代码的规范要求，对于代码的功能已经标准性进行复查。如果遇到不合规范的情况，会在issue以及即时通讯工具中提醒，要求开发人员进行更改。

测试/发布

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

团队有完整的测试计划。也有测试工具，并且进行了验收

Gamma测试工作反思

没有考虑到测试样例执行速度的问题，虽然是放着跑一下就完事了，但会占着那么久电脑，而且每次跑都要跑那么久确实是个问题。
测试样例的管理问题，虽然我当初的理想是使用tag进行管理。但事实上对上百个样例使用tag来进行管理真的是个折磨。一套更方便的管理系统可能更好，这有助于在测试样例执行速度无法提升的情况下选择性地进行测试。
对需求变更的即时响应问题，虽然我使用了page object方便了同类测试样例的批发式编写，但问题是当page本身发生变更时，我的即时响应方面，虽然工作量不大，但存在较高的抽象复杂度。因为我和前端那边对页面的抽象方式不同，所以每次他们修改我都要想想怎么适配成我这边的逻辑。手工工作量是减少了，但思维工作量增加了。

总结

团队目前的磨合非常不错，处于“创造”阶段。整个Gamma阶段，在PM因特别原因的缺席下，也能不延期地完成所有任务。同时团队成员也注重了软件工程的质量等，对安全性测试，兼容性测试，以及使用自动化测试工具等都非常熟练，相比起Alpha阶段和Beta阶段来说，我们组已经成为一个相对“成熟”的软件工程团队~