【观隅】Alpha阶段事后分析报告

项目	内容
这个作业属于哪个课程	2021学年春季软件工程（罗杰任健）
这个作业的要求在哪里	团队项目-事后分析
在这个课程的目标是	锻炼在软件工程中的团队协作能力
这个作业在哪个具体方面帮助我实现目标	对Alpha阶段中出现的问题和表现出的优点进行剖析，以期对Beta阶段进行一定程度上的指导

一、设想与目标

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

我们要解决纷繁复杂的数据集缺乏整合过的可视化方案的问题。该问题在Alpha阶段的开发过程中一直都有清楚的定义，所有功能的计划与实现均是紧密围绕该问题的。相关的典型用户和典型场景也有清晰描述，可以参见这里：典型用户，典型场景。

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

整体而言达到了预期目标。实现了在功能规格说明书的“系统功能”一节所列举的全部功能，按照原计划交付时间进行了交付，且日活达到33人，达到并超过了原定日活20的预期。

团队软件工程的质量如何？如何衡量的？

整体上质量较好。有关内容与衡量指标已在项目展示的“软工质量”一节进行了详细介绍。

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

用户量超过了团队的预期，且用户对重要功能的接受程度较为符合团队预期。具体可参见项目展示的“用户评价”一节。

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

在设计的最初，团队缺乏对深度学习相关从业人员的真实调研，需求分析上存在一定程度的臆想，虽然发布后从用户反馈上来说没有出现大的问题，但这样的做法是不可靠的。从事后诸葛亮的角度而言，在需求分析阶段，就应当充分调研和发掘真实用户需求，避免臆测。

二、计划

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

没有。一方面，课程组在选题和Alpha阶段计划之间的安排过于紧凑，导致我们确定题目后只剩下一天来进行相关计划的讨论；另一方面，我们缺乏项目规划与管理方面的经验，难以明确项目任务管理的具体形式，时间利用效率较低。

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

吨位决定，所以是WPB决定。（由公认的技术力较高的成员决定）

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

做完了。Alpha阶段的计划仅是完成最小可用版本，若存在没做完的工作则不能发布。

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

项目管理上，调研并尝试使用了jira和GitLab之间的联动，后因为现版本上兼容性太差而放弃。

前端技术栈上，选择了学习成本较高的 React + Typescript，不仅对前端开发人员进行了折磨，也对可能存在的前端人员转入造成了负面影响。

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

每一项任务我们都在GitLab的Issue区进行了清晰地定义。在交付时，我们要求该Issue关联到一个commit或merge request 上，并且会由指定人员进行复审，以保证交付的质量。

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

项目中期进度较慢，计划没有得到较好执行。其原因是五一期间原神更新了家园系统，分散了组内许多同学的注意力。

图1 五一期间开发效率低的罪魁祸首

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

对于任务完成所真实消耗的时长，我们允许其与预估时长存在一定的出入，这样的出入即可定义为我们的缓冲区。缓冲区极其重要，我们有一些关键性的工作是在缓冲区时间内才开发完成的。

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

由于缓冲区的存在，且组内是个人独自进行开发，造成了许多工作是在ddl之前才有所进展，在后续工作中我们希望对任务的预估时间进行更严格的约束。

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

首先，个人独自开发的流程效率较低，对API的修改通知、merge request的冲突处理等多方面都有不利的影响，所以，我们希望学习题士团队的线下开发流程，选出数个时间段进行集体冲刺开发，至少要求多数人（即4人，且前后端都有分布）到场，以提供更充分的讨论氛围，提高开发效率。

其次，轮值PM效果奇差，我们认为其原因在于轮值PM导致无法在产生对产品的不一致意见时给出准确答复，导致整体的概念统一性没有得到较好保证，此外Alpha阶段的计划不够明确，更是加剧了这一问题。在Beta阶段中，我们将指定一位成员全程担任PM。

三、资源

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

可支配的时间资源较少，且团队内较为缺乏领导资源。

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

限于时间紧迫，在时间估计上犯了经验主义的错误，造成各任务粒度差别较大，部分任务粒度过粗，难以在单位时间内解决掉，这也是燃尽图令人迷惑的一大原因。

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

测试上各资源均足够。但是我们对于沟通所需要的时间资源和领导资源都有所低估难度，团队内部往往对于某一细节争论不休，最终造成时间上的浪费和进度的拖延。

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

个人层面上存在这样的现象，即如果将后端的工作全交由WPB完成则整体而言会花费更少的时间。但在团队层面上来说，这样的做法在关键路径上耗时更长，即不存在这样的可能性。

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

Alpha阶段的计划过程中对任务时间的预估偏离的有些过于离谱，对各成员的能力也存在误解。需要对每一阶段中的任务重新进行划分，重视“单元任务”的概念，尽量避免粒度过大的任务的出现。

四、变更管理

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

没有做到，全过程中都存在沟通不够及时的问题。

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

依照最小可用原则，仅实现”不实现就不能发布“的功能，其他功能一律推迟。

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

出口条件有清晰定义，详情参见 Alpha阶段测试报告的“出口条件”一节。

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

能，可太应急了。换句话中，大多数功能都是在应急状态下实现的。

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

能。大家都知道这种“意料之外”的请求不做完就发布不了。

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

在具体开发过程中，及时沟通是最重要的一点。同上述第二部分，将通过线下集体开发尝试解决这一缺陷。

五、设计与实现

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

Alpha阶段的总体设计工作是在设计博客作业ddl前几个小时由团队全体成员开会讨论完成的。虽然是合适的人，但这一时间显然不合适，过于仓促，设计敷衍种下的恶果最终在开发阶段加倍奉还。

前端静态页面的设计由前端开发人员自行在开发早期完成，从结果来看，效果还挺好。

接口的设计由PM在开发阶段的前两天完成，时间上能够接受，但是个人完成的初版接口文档存在许多问题，造成了一定的迷惑性，事后看来，接口设计应当在前后端负责人的共同讨论下一起决定。

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

有。数据集解析引擎整体在设计阶段都处于薛定谔的状态，没有形成具体设计。团队选出WPB全权进行该模块的设计，并在后端派出一人YZM进行对接，尽量不对其他模块的开发造成影响。

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

开发过程中合理使用了单元测试和UML，但没有使用TDD。此外使用了Swagger进行接口文档的编写和维护，以上所使用的工具都非常有效。项目开始的UML文档与现在基本上没有区别，无需更新。

图2 使用Swagger完成的接口文档

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

数据集条目的具体可视化功能产生的Bug最多，其是本项目的核心功能，技术上存在一定的难度，容易出现Bug。在发布之后，前端出现了在100%缩放下数据集条目显示不能对齐的问题，这是因为前端开发人员全部使用125%的缩放，且在测试矩阵中没有注意缩放这一变量。

图3 在100%缩放下显示不能对齐

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

前后端均形成了成熟的merge pipeline，merge前由指定人员进行代码复审，且配置的CI/CD会严格执行代码规范检查eslint/pylint。

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

仅由PM个人设计接口会出现一些问题，其考虑的不周到会造成前后端开发人员的迷惑和被折磨，因此我们希望在定义接口时由前后端负责人共同细化讨论。

六、测试与发布

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

有测试计划，且正常执行。在项目展示环节没有被发现恶性Bug。

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

进行了正式的验收测试。

团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

本团队使用配置的CI/CD结合python的单元测试库进行后端代码的单元测试，且使用自行编写的Python脚本进行压力测试等，在测试上做的较好。

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

我们主要通过分析请求平均时间来测量软件效能，相关压力测试请参见 Alpha阶段测试报告的“压力测试”一节，这样的压力测试为我们的用户量设计提供了理论基础，但是现有的压力测试暂未触碰到极限负载，将在Beta阶段的测试中进行补充。

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

发布过程中发现前端的Loading动画没有实现，团队立即对相关代码进行了检查与修复，没有造成发布的延误。

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

我们认为本团队在测试上做的较好，会继续保持。

七、团队角色管理与合作

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

团队内部先确定岗位设置，再通过自荐的方式确定每个人的角色。由于团队成员之间比较了解，因此基本做到了“人尽其才”。

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

存在大量的互相帮助。在一些小问题上的互相帮助节省了大量的时间。

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

在例会上提出并进行讨论，最终由组长或PM定夺。

八、总结

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

完成级。

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

规范。

对于软件工程的理论，规律有什么心得体会或不同意见？

现有的做法	敏捷的做法
流程和工具	个人和交流
完备的文档	可用的软件
为合同谈判	与客户合作
执行原定计划	响应变化

这里列出了一些敏捷的做法和现有的做法的对比，我们在开发过程中先是以敏捷的做法尝试进行开发。但是发现“个人和交流”虽然可以充分释放个人的思维活力，但是“流程和工具”的缺少使得这部分思维活力不能沉淀下来，不仅不能被其他成员理解，甚至成员本身过一段时间也遗忘了这部分内容。

而在协同开发的过程中，以“可用的软件”为目的的开发，我们发现似乎造成了过多的无用迭代，之后我们引入了较为完备的文档，使得之后的迭代有迹可循，使软件的开发过程更加容易。

因此我们觉得现有的做法和敏捷的做法需要一个良好的trade-off，而不是直接选定其中一种方案死磕到底。

对比敏捷的原则，你觉得你们小组做得最好的是什么？

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意：我们在预期时间内发布了观隅的Alpha版本。针对Alpha版本我们进行了用户调研，调研了相关功能是否能充分满足用户需求，以及缺失了哪些功能。
面对面交谈：我们存在着高强度的、持续的线下沟通，每次针对当前的开发流程和需求实现情况考虑下一步的开发计划，并形成了集体共识。
可持续开发：我们为自己的项目建立了完善的前后端接口文档，数据库设计文档，前端pipeline流程描述文件。并且为前后端设置了代码规范。使得熟悉相关技术栈的人都可以快速上手。