穿越银河的火箭队——alpha阶段问题总结随笔

穿梭在银河的火箭队团队 2022-06-04 17:40:15

这个作业属于哪个课程	2022年福大-软件工程、实践-W班
这个作业要求	团队作业——beta冲刺+事后诸葛亮
这个作业的目标	各组对于软件工程的“Learning by doing”的意涵了解的还不深刻，遇到的问题也不少。停一停，开个总结会，来个事后诸葛亮，为了下一步走得更好
其他参考文献	项目管理 - 事后诸葛亮会议

设想和目标

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

卷王自习室——为缺少学习兴趣的福大学子提供一种辅助的自习软件，缓解学习的乏味，增添趣味性。为福大学子提供地图化方式查询福大空教室，提供联机和单机自习模式，通过数据可视化分析自身学习习惯，从而更高效的学习

定义清楚，针对福大学子的学习需求，引入空教室模块并且可查看当前空教室人数来进行软件的规划

典型用户和典型场景：
```
 1.独自学习枯燥乏味的同学通过联机自习模式有了学习的激情和乐趣
 2.想要去人少的空教室自习的同学通过卷王自习室的地图模块查看空教室人数
 3.想要将自己学习过程记录下来的同学通过卷王自习室记录，并在个人中心查看记录以及分析
```
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

alpha阶段计划的功能总体完成，但是还存在一些需要改进的地方，如锁机和计时问题
按照原计划交付时间交付
暂未推广
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

团队软件工程的质量提高了，在对于人员的分配上有了变化。本来之前的后端人员照样都参与beta 阶段的后端代码的编写，现因此次beta阶段后端代码部分相对较轻，所以人员规划有所改变，所以减少了后端代码编写的人员，调入其他部分。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

目前暂未对外开放用户测试，但我们认为离目标更近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

在做计划时，应该对细节摸索清楚，考虑到位，这样在执行计划的过程中才可以减少意外的发生，因此对于下阶段的计划要好好详细规划

计划

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

有充足的时间做计划，不仅在各个阶段的时间段规划，在休整的时间内有也思考如何做出更合理的规划
团队在计划阶段是如何解决同事们对于计划的不同意见的？

根据投票情况来采取最终结果，团队尊重大家提出的意见，也鼓励大家提出意见
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

原计划的工作总体都有完成，但是存在一些bug需要解决，这些bug是在测试阶段发现的，在alpha阶段来不及处理，所以会在beta阶段处理
有没有发现你做了一些事后看来没必要或没多大价值的事?

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

是，根据功能的实现情况来定义和衡量
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

大部分按照计划进行，但过程中有进行调动，比如alpha阶段教室模块不需要单独一个人编写，就将原来的人员调动到文职部分。当时由于对福大教务处的空教室接口没有调查清楚，因此对于人员的分配上有些不完善，所幸发现的早，调动的早，所以基本上没有影响
在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，用于对于阶段的汇总以及发现问题
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

由于临近期末，所以会在考试逼近的时候适当的空出时间用于团队成员复习

资源

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

在进行最初规划的时候，有参考到alpha和beta阶段的展开时间，alpha阶段期间时间比较富足，而beta阶段临近期末周，所以安排alpha阶段任务量较大，beta阶段任务量较轻。因此都有足够的资源完成各项任务
各项任务所需的时间和其他资源是如何估计的，精度如何?

根据各项任务的划分的子任务来估计，精度较准
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试时间比较紧迫，所以测试开始后也在很紧迫的修改bug
人力和软件/硬件资源足够
低估了美工设计/文案的难度
你有没有感到你做的事情可以让别人来做（更有效率）?

如果让实力更强的人来做，确实会更有效率，但是也过于负重，也不是团队合作的理念。团队配合本来就是各自合作学习成长的过程。

变更管理

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

是的，通过群公告的方式或者开会时公布确保大家都收到变更消息
我们采用了什么办法决定“推迟”和“必须实现”的功能?

提出意见，开会讨论，看有无异议
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

实现了功能以及计划实施完全
对于可能的变更是否能制定应急计划?

是的，对于不确定的因素和变更需要应急的计划处理，遇到突发情况小组讨论解决
员工是否能够有效地处理意料之外的工作请求？

大家都能够为了项目的成果去处理意外请求

设计/实现

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

在需求分析、系统设计和概要设计阶段小组成员共同完成，时间合适位于冲刺之前，成员也合适，有助于成员对项目更加了解
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

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

使用单元测试和UML和Postman等工具进行设计和实现，有效的帮助团队工作的进行，通过这些工具，成员能够及时发现存在的问题以及对项目的认知。
一些细节（如属性，方法的增删）进行了变化，但是整体上差别不大，比如原先设想中用户走学校的登录验证，但在后续的开发中改变了原有的设计思路转换成了正常的登录注册
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

在自习模式功能模块发现的bug最多
1：定位问题比较难以精确，导致的原因：测试定位时没有详细测试
2：用户自己修改手机时间导致记录不合理，导致的原因：确实没有联想到用户可以手动篡改系统时间
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

IDEA，WebStorm有提供第三方的代码规范插件，使用这些插件可以对代码进行格式化，保证代码大致的规范，细节部分由编写人员，负责人进行两重校验，严格执行代码规范

测试/发布

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

团队有测试计划，在alpha阶段的最后几天全组成员进行测试，并且成员测试兴趣高昂，热衷于发现各种不寻常的bug，比如手动修改系统时间造成的时长差异
是否进行了正式的验收测试？

全组成员参与软件的运行测试，确认最终发布版本
团队是否有测试工具来帮助测试？

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

一开始使用PostMan对后端的接口进行测试，在每个接口本地测试完成之后，会由负责人合并后再次进行测试，最后部署到服务器上给予前端测试；由于我们的项目采用APP开发，我们软件成功之后还使用了Fiddler抓包工具分析app请求以便确保软件正常运行；因为aop软件出现问题后手机上很难看出来，我们只能在虚拟机上尝试再次复现bug，显得非常麻烦；从第一次冲刺，后端的测试很重要但是我们做的还是过于薄弱，有很多验证（比如非法学号等等）都不够完善，也不够合规，没有很好的设计测试用例
在发布的过程中发现了哪些意外问题？

暂时没有

团队的角色，管理，合作

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

首先先由各成员填写前后端意向，最后由组长和pm将人员分配前端还是后端，若有想调动的人员可自行找寻愿意调换的成员，再由各成员自己领取愿意承担的任务。
我们发现实力更强的成员往往也会主动领取更难的任务，人尽其才
团队成员之间有互相帮助么？

团队成员互帮互助，当有人遇到问题时，都有人热心帮忙解决
比如对于额外的任务，比如前端组长和后端组长，基本上都有人愿意承担
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

各成员提出方案，投票解决