【观隅】Alpha阶段事后分析报告
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021学年春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-事后分析 |
| 在这个课程的目标是 | 锻炼在软件工程中的团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 对Alpha阶段中出现的问题和表现出的优点进行剖析，以期对Beta阶段进行一定程度上的指导 |
一、设想与目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要解决纷繁复杂的数据集缺乏整合过的可视化方案的问题。该问题在Alpha阶段的开发过程中一直都有清楚的定义，所有功能的计划与实现均是紧密围绕该问题的。相关的典型用户和典型场景也有清晰描述，可以参见这里：典型用户，典型场景 。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
整体而言达到了预期目标。实现了在 功能规格说明书 的“系统功能”一节所列举的全部功能，按照原计划交付时间进行了交付，且日活达到33人，达到并超过了原定日活20的预期。
- 团队软件工程的质量如何？如何衡量的？
整体上质量较好。有关内容与衡量指标已在 项目展示 的“软工质量”一节进行了详细介绍。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量超过了团队的预期，且用户对重要功能的接受程度较为符合团队预期。具体可参见 项目展示 的“用户评价”一节。
- 有什么经验教训? 如果历史重来一遍,我们会做什么改进?
在设计的最初，团队缺乏对深度学习相关从业人员的真实调研，需求分析上存在一定程度的臆想，虽然发布后从用户反馈上来说没有出现大的问题，但这样的做法是不可靠的。从事后诸葛亮的角度而言，在需求分析阶段，就应当充分调研和发掘真实用户需求，避免臆测。
二、计划
- 是否有充足的时间来做计划?
没有。一方面，课程组在选题和Alpha阶段计划之间的安排过于紧凑，导致我们确定题目后只剩下一天来进行相关计划的讨论；另一方面，我们缺乏项目规划与管理方面的经验，难以明确项目任务管理的具体形式，时间利用效率较低。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
吨位决定，所以是WPB决定。（由公认的技术力较高的成员决定）
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
做完了。Alpha阶段的计划仅是完成最小可用版本，若存在没做完的工作则不能发布。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
项目管理上，调研并尝试使用了jira和GitLab之间的联动，后因为现版本上兼容性太差而放弃。
前端技术栈上，选择了学习成本较高的 React + Typescript，不仅对前端开发人员进行了折磨，也对可能存在的前端人员转入造成了负面影响。
- 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务我们都在GitLab的Issue区进行了清晰地定义。在交付时，我们要求该Issue关联到一个commit或merge request 上，并且会由指定人员进行复审，以保证交付的质量。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目中期进度较慢，计划没有得到较好执行。其原因是五一期间原神更新了家园系统，分散了组内许多同学的注意力。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
对于任务完成所真实消耗的时长，我们允许其与预估时长存在一定的出入，这样的出入即可定义为我们的缓冲区。缓冲区极其重要，我们有一些关键性的工作是在缓冲区时间内才开发完成的。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
由于缓冲区的存在，且组内是个人独自进行开发，造成了许多工作是在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文档与现在基本上没有区别，无需更新。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
数据集条目的具体可视化功能产生的Bug最多，其是本项目的核心功能，技术上存在一定的难度，容易出现Bug。在发布之后，前端出现了在100%缩放下数据集条目显示不能对齐的问题，这是因为前端开发人员全部使用125%的缩放，且在测试矩阵中没有注意缩放这一变量。
- 代码复审（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流程描述文件。并且为前后端设置了代码规范。使得熟悉相关技术栈的人都可以快速上手。
九、展望
什么是在下个阶段要改进的地方？越具体越好。
- 重视用户调研。在Beta阶段开始前通过发放问卷和点对点采访的形式进行用户调研，充分挖掘其潜在需求。
- 细化任务设计。在Beta阶段计划中吸取Alpha阶段的教训，使用粒度更小的任务作为Issue，充分考虑成员能力以估计任务所需时间。
- 集中PM职能。在Beta阶段开发的全过程指定唯一一个PM执行有关职能，以取代现有的轮值PM制度。
- 强化沟通作用。在Beta阶段开始时让前后端负责人均参与接口的设计，开发过程中尝试使用线下集中冲刺开发的方式。
十、关于分析会
本博客由团队全体成员开会共同讨论得来，该会议开始于5.19 23:00，以线下会议为主，部分不能到场的同学通过腾讯会议线上参加，有关截图如下：
