【Alpha阶段】事后分析报告
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程 （罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-事后分析 |
| 团队在这个课程的目标是 | 完成项目的开发，并进行优化，达到较高的质量 |
| 这个作业在哪个具体方面帮助团队实现目标 | 反思上一阶段，对一些问题进行修正 |
一、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要先解决在移动端绘制图表的问题，主要针对基物实验的场景和用户，实验数据可以直接输入到手机上，绘制用户需要的图，并可将数据导出为csv或xls格式的文件。对问题和典型用户、典型场景已经有了清晰的定义。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
整体上达到了基本目标，实现了基础功能，包括功能规格说明书 基本文字输入、图表展示功能、模版功能、导出功能、数据分析功能。按照原计划交付时间交付，但是在使用中会存在一些bug，将在beta阶段修正，原计划的用户数量已经达到，具体日活情况可见项目展示 。
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
本次软件工程的质量整体上较好，完成了基本功能，并进行了单元测试，具体情况可见项目展示 。
- 用户量,用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对重要功能的接受程度符合预期，作为绘图的工具辅助，较为吸引用户，不过存在一些影响用户体验的bug，需要在下一阶段尽快修正完善。
- 有什么经验教训? 如果历史重来一遍，我们会做什么改进?
- 不能使用轮值PM，要有一个明确的PM，来督促大家的完成，安排测试等
- 接口设计一定要清楚，更新要及时通知大家
二、计划
- 是否有充足的时间来做计划?
计划时间较短，项目选题加功能设计给的时间都很短，并且由于经验的缺乏和对于技术的不了解，难以判断某一功能实现的难易程度，也就难以在前期给出详细的规划设计等，只能在实现过程中逐步调整。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队会在开会的时候进行讨论，有想法的同学进行发言，直到说服所有人，大家一致同意。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的功能已经基本实现，将会在beta阶段进行优化。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
图表的拖动和表格全选，没有考虑到这两个任务的工作量，做了但是很烂，不如不做。
- 是否每一项任务都有清楚定义和衡量的交付件?
团队有完整的数据库设计文档和前后端接口文档，对于项目的功能、整体结构都有清晰的定义，同时每一部分的计划和实现也可以在会议记录和gitlab的issue区找到。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有，项目延期了。风险主要有两点，一个是技术实现的风险，图的拖拽和表格
- 在计划中有没有留下缓冲区，缓冲区有作用么?
没有，时间比较赶。缓冲区能让项目的容错性更加高。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
会，由于前期时间比较赶，没有进行充分的测试计划。前后端会在beta阶段加入测试的计划，如果进度缓慢也会增加面对面开发的功能。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
alpha阶段中我们过于依赖人的自觉性了，没有有效的奖惩制度和明确的任务分配方案，beta阶段需要更加明确的团队管理流程和一个PM来进行推动。前期的技术调研要充分，难以实现的功能要尽可能规避掉。
三、资源
- 我们有足够的资源来完成各项任务么?
资源还是比较充分的，唯一比较欠缺的就是时间资源。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
由于在任务设计的初始阶段，对于时间以及功能进行了规划，并设置了issue，但是在对技术不了解和经验缺乏的情况下，时间估计存在较大的误差，在后续实现过程进行了修正。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于团队只有五个人，所有人都投入了代码的实现中，没有专门的测试人员，所以时间、人力存在欠缺，也导致存在一些bug需要后续修正。图表小程序表示非常需要一个美工！！！
- 你有没有感到你做的事情可以让别人来做（更有效率）?
当然让对技术栈更了解的同学完成某项工作是较快的，但是让该同学完成所有工作那必然是不快的，团队任务在分配好之后就需要每个人完成各自的工作，并按时交付，否则会影响整体进度。
- 有什么经验教训?如果历史重来一遍，我们会做什么改进？
任务要尽可能地划分细致，落到每个人头上。同时要有人进行整体调度，空闲的人要给他安排新的任务。不能靠别人的自觉性，要靠PM的管理。
四、变更管理
- 每个相关的员工都及时知道了变更的消息?
在文档的更新方面，由于更新次数多，存在着每个人用的版本不一样的问题，在之后会考虑采取在线共享文档同步修改。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们首先是按照功能的重要程度，杀手级的功能是必须要做的，其中功能比较复杂的我们进行延后。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义，具体情况可见测试报告。
- 对于可能的变更是否能制定应急计划?
可以制定，对于紧急情况，团队成员都能参与解决方案的制定过程。
- 员工是否能够有效地处理意料之外的工作请求？
可以处理，团队成员会根据各自目前的工作进行衡量，如果当前工作不是需要紧急完成，则可以处理这样的工作请求。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
接口，计划等变更一定要通知到所有人，并且有相应记录。
五、设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
功能的总体设计由团队全体人员参与，在Alpha计划阶段完成，设计过程有些仓促，不过主要功能都已经设计好，并且与后续实现情况基本一致。前后端的设计由各自开会完成。接口的设计由团队讨论协调后决定，后续也根据实际情况进行了修改。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计过程中遇到的问题主要在会议的讨论中解决，先拟定一个方案，后续在实现过程中根据实际情况进行修改。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
开发过程中使用了单元测试进行代码的测试，在设计过程中使用了UML，更好地表达结构和功能的设计，目前实现功能与预期基本一致，无需修改。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
表格功能bug最多，一方面是开发的表格本身的代码质量不高，另外一个方面是缺乏代码复审和单元测试，最后对接的时候才进行集中修复。发布之后
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有代码复审，没有相应的代码规范。会再beta阶段考虑引入代码规范工具。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
要有基本的代码复审和代码复核制度。
六、测试/发布
- 团队是否有一个测试计划？为什么没有？
没有，前期没有规划测试功能，后期进度又比较赶。
- 是否进行了正式的验收测试？
进行了正式的验收测试。
- 团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
后端采用postman和junit进行单元测试和压力测试，并使用CI自动进行单元测试。测试结果可见测试报告。
- 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
采用junit进行压力测试，并发用户数200，每个用户连续访问50次，对总共35个接口进行了测试，通过每个接口测试的吞吐量、平均延迟、最短延迟、最长延迟等指标测量效能，具体可见测试报告，测试结果良好。
- 在发布的过程中发现了哪些意外问题？
前期调研不充分，不知道测试版和发布版wx.request请求不一样，https在发布前才搞定。也没有考虑到审核的因素。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
需要有测试的计划，要有人进行督促。
七、团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队的每个角色是根据各自曾经学过的或者有经验的方向进行自主选择，从这个角度来看，每个人都做了自己擅长的事件，是人尽其才。
- 团队成员之间有互相帮助么？
团队成员存在非常多的相互帮助，不管是实现方面还是功能的理解方面，还有前后端的交流，都是非常多的。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队成员会开会进行讨论，提出各自的看法，互相说服，最后达成一致的意见。
八、总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
处于完成级，项目的目标和功能设计比较清晰，但过程中的规划和审查还存在欠缺。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
团队处于磨合阶段，正在向规范阶段前进，能各自在自己的角色中完成自己的职责，对于一些问题也能友好讨论达成一致，向着共同的目标努力。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
每个里程碑都记录了当前完成的一项工作。
- 你觉得目前最需要改进的一个方面是什么?
在用户的反馈中，存在一些影响用户体验的bug是最需要改进的，同时对于界面需要更加美观合理的排布方式。
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?
我觉得做得比较好是不断地关注比较好的技能，我们开发过程中探索了一些javascript的特性，利用这些特性对代码进行了简化。比如利用Promise封装wx.request
- 什么是在下个阶段要改进的地方？
整体缺乏组织和架构，分工不太明确。
