Alpha阶段事后分析

Posted 2021-11-04 buaatbxl

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Alpha阶段事后分析相关的知识，希望对你有一定的参考价值。

设想和目标

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

我们的软件要解决的是安卓游戏的自动化异常检测问题，定义的足够清楚，对于典型用户的描述和典型场景的描述也足够清晰。

具体来讲，通过提供用户测试的选择，让用户自由对他的游戏进行黑盒测试，发现问题由本程序进行报告并提供操作记录，使用户能够针对性的从黑盒测试中寻找异常的成因。具体的用户详见[软件工程]功能规格说明书。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

alpha阶段的目标就是对核心功能的实现，即完成用户正常使用的程序，提供能够让用户自由组合的测试，捕获可能的异常且记录并生成报告提供用户使用。基本完成了原计划的功能。

按照原定计划交付，但用户数量没有达标。

反思：交付日期定的较晚，宣传时间不够；交付之后宣传力度不够；由于程序本身应用场景较为特殊，用户分散。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

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

预想中100的用户量确实较为困难，对功能的接受程度与事先预想较为一致。但同时也发现了其他问题，有一位用户在使用后通过问卷反馈报告的文件混杂在文件目录中不方便查看，这确实是最初没有考虑到的。我们认为我们离目标确实更近了。

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

强化对宣传工作的重视程度，本身由于身边没有明确的数量足够的用户群体，应该早些将产品向外推广。

计划

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

是的。我们在alpha阶段，pm在冲刺开始前，将所有的任务分解并且放到github上，每天对团队成员分配当天任务，在每日例会中汇报任务完成情况。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

对于不同意见我们通过讨论来解决，对于自己的任务有疑问或困难都可以向pm协商或者请求其他成员的协助，如果有原计划中不合适的项目将会在讨论后修改或者去除。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 绝大多数完成了
- 没做完的原因：
  - 当前阶段难度较大，延后
  - 基本没有用处的功能，剔除
有没有发现你做了一些事后看来没必要或没多大价值的事?

没有做没必要的事情，发现了对整体基本无用的功能(有计划过在是用界面由用户对测试报告进行修改，但是测试报告本意是让用户通过它去寻找异常的，没有必要进行修改)，在做之前将它剔除掉了。
是否每一项任务都有清楚定义和衡量的交付件?

交付件：
- PM：博客、issue、文档
- 后端：可以提供给前端的接口
- 前端：可以提供给用户的界面
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

是有按计划进行。

小意外和原因：
- 前后端接口方面超过预期，解决是通过学习socket完成两边对接，在最初没有考虑到。原因是没有相关经验，解决方案也是组员在对接过程中查到的。
- 封装过程中没有做好沟通，pm监督没有到位，导致出现了延误。
在计划中有没有留下缓冲区，缓冲区有作用么？

有留下缓冲区。作用是像上一个问题中的意外情况都能够在有缓冲区的情况下解决，以避免造成更大的损失。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

将前端的设计要求更加明确和具体。

调整任务分配方式，详见下一问。

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

最大的修改是本项第一条中的"每天对团队成员分配当天任务"，这一点要改成每一位成员都会提前分配至少一周的任务，可能会有的变动和问题再商讨中解决。如此，成员会对自己的任务有一个充分且系统的认知，同时在完成任务后也会考虑之后会有的可能的变化，同时自身机动调节轻重任务，更加高效，而不是每天分配任务的时候由pm指定。

资源

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

基本足够，时间稍欠缺，因为团队成员有的忙于课程，有的忙于准备考研等等。
各项任务所需的时间和其他资源是如何估计的，精度如何?

各项所需时间估计基本准确。不准确的项目就是如上文所说的对接出现的意外。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间，人力和软件资源足够，但是硬件上只有win10系统。对于自身制定的测试计划是足够的，但是经过指导后了解到这一方面有不足，在后文测试部分详细讲。

美工设计方面没有低估，在alpha阶段考虑到核心功能的难度因而放弃了对美工涉及方面的提高，这一部分将在接下来的阶段进行提升。
你有没有感到你做的事情可以让别人来做（更有效率）?

确实会有，但是每个成员都分配有自己的工作，也许不是最合适的，但是都是能解决的。当我们分工到个人，每个人的效率才会体现，而不是互相推脱。

变更管理

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

是的。我们有重大变化会及时通过微信进行通知，即使没有及时查看微信，至少每天的例会上也会当面讲清楚。
我们采用了什么办法决定“推迟”和“必须实现”的功能?

首先是pm在项目计划时指定核心功能和完成的内容，之后在实践过程中对功能有疑问或者意见及时反应后全员讨论决定。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有清晰定义，见[软件工程]功能规格说明书功能描述及验收标准。
对于可能的变更是否能制定应急计划?

能。若每日总结时发现有任务有困难，会及时对任务进行调整，添加临时任务或去除无用任务。
员工是否能够有效地处理意料之外的工作请求？

能。比如比如临时添加的任务socket的解决就顺利完成了。

设计/实现

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

设计工作在项目冲刺开始前，由pm完成，pm进行总体设计并与成员进行交流细分任务。

是合适时间合适的人选。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有遇到。因为在任务发布时只是将任务的名称发出，具体内容并没有完全写成文字，有时会有模棱两可的情况，此时由负责人协商解决或由pm协调。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

使用github进行项目管理，issue和燃尽图对项目进度进行监控，是很实用的工具。

其他的没有使用。将在beta阶段进行改进。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

后端各项功能的通信和连接。因为每个功能在提交时都要求开发人员自行完成部分测试因此各自本身没有太大问题，但是相互之间的信息传递在设计之初没有预料。

发布后发现路径带中文无法运行，因为在开发时直接用的代码和包装好的程序，没有额外进行完整的打包和对项目名字的纠结，因此没有发现路径的问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

由后端负责人进行。是严格执行了代码规范。

测试/发布

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

有测试计划。
是否进行了正式的验收测试？

如Alpha阶段测试报告。
团队是否有测试工具来帮助测试？

没有，一是对相应工具和流程不熟悉。二是在计划阶段没有考虑到使用工具，我们最初计划的是通过对完成品的各项黑盒测试验证其功能，在这一点上是设计的失误。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

由于是对成品的黑盒测试，我们的测试直接反映了实际运行的结果。改进是要增加单元测试、覆盖率测试等等。
在发布的过程中发现了哪些意外问题？

如上文：发布后发现路径带中文无法运行，因为在开发时直接用的代码和包装好的程序，没有额外进行完整的打包和对项目名字的纠结，因此没有发现路径的问题。

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

测试计划进行完善使它更加规范和系统，增加单元测试和覆盖测试等等一系列的验证性的测试，而不是仅仅通过使用实例。

团队的角色，管理，合作

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

通过个人意愿、实践经历和个人能力决定的。

我们认为做到了人尽其才。
团队成员之间有互相帮助么？

有。包括但不限于线上讨论、例会交流、直接面对面查看等等。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

不紧急的有因为麻烦而直接在例会反馈的，紧急的bug或者问题时候也有直接到宿舍找人的当面讨论的。