其他分享
首页 > 其他分享> > 【观隅】Alpha阶段事后分析报告

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

作者:互联网

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

一、设想与目标

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

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

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

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

  1. 团队软件工程的质量如何?如何衡量的?

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

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

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

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

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

二、计划

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

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

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

​ 吨位决定,所以是WPB决定。(由公认的技术力较高的成员决定)

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

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

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

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

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

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

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

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

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

image

图1 五一期间开发效率低的罪魁祸首
  1. 在计划中有没有留下缓冲区,缓冲区有作用么?

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

  1. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

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

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

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

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

三、资源

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

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

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

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

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

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

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

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

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

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

四、变更管理

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

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

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

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

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

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

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

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

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

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

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

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

五、设计与实现

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

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

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

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

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

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

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

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

image

图2 使用Swagger完成的接口文档
  1. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

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

image

图3 在100%缩放下显示不能对齐
  1. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

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

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

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

六、测试与发布

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

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

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

​ 进行了正式的验收测试。

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

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

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

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

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

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

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

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

七、团队角色管理与合作

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

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

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

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

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

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

八、总结

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

​ 完成级。

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

​ 磨合。

  1. 对于软件工程的理论,规律有什么心得体会或不同意见?

​ 暂且按下不表。

  1. 对比敏捷的原则,你觉得你们小组做得最好的是什么?

尽早、持续交付。

面对面交谈。

可持续开发。

九、展望

什么是在下个阶段要改进的地方?越具体越好。

  1. 重视用户调研。在Beta阶段开始前通过发放问卷和点对点采访的形式进行用户调研,充分挖掘其潜在需求。
  2. 细化任务设计。在Beta阶段计划中吸取Alpha阶段的教训,使用粒度更小的任务作为Issue,充分考虑成员能力以估计任务所需时间。
  3. 集中PM职能。在Beta阶段开发的全过程指定唯一一个PM执行有关职能,以取代现有的轮值PM制度。
  4. 强化沟通作用。在Beta阶段开始时让前后端负责人均参与接口的设计,开发过程中尝试使用线下集中冲刺开发的方式。

十、关于分析会

​ 本博客由团队全体成员开会共同讨论得来,该会议开始于5.19 23:00,以线下会议为主,部分不能到场的同学通过腾讯会议线上参加,有关截图如下:

image

标签:观隅,事后,计划,阶段,测试,Alpha,团队,我们
来源: https://www.cnblogs.com/RiddleMan/p/14783468.html