Sunny图表——beta阶段总结反思
Posted Thousand_Sunny
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Sunny图表——beta阶段总结反思相关的知识，希望对你有一定的参考价值。
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程 （罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-事后分析 |
| 团队在这个课程的目标是 | 完成项目的开发，并进行优化，达到较高的质量 |
| 这个作业在哪个具体方面帮助团队实现目标 | 反思上一阶段，对一些问题进行修正 |
一、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要先解决两个问题，一个是在移动端绘制图表的问题，主要针对基物实验的场景和用户，实验数据可以直接输入到手机上，绘制用户需要的图，并可将数据导出为csv或xls格式的文件。另外一个问题是用户可以记录账单，可以记录账单，分析账单花费构成。对于典型用户和场景较为清晰。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
目标达到了，原来的功能都完成了，除了草稿箱由于存在bug注释掉，分析中的不确定度最后由于时间关系没有完成。但是两个都是属性某个功能模块下的小模块，对最终产品影响不大。原计划注册用户400人，达到目标。
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
有提高，后端单元测试覆盖率从93%提升到100%，同时对后端所有接口进行了充分测试，避免了alpha阶段接口出现问题，导致前后端都受到影响的情况。
- 用户量,用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对重要功能的接受程度符合预期，在基物实验上，由于表格输入效果不太佳加上基物实验发布时已经做完，导致用户收集受到影响，最终效果和预想存在偏差。账单功能上，反响比较好，受到许多用户好评，还有用户提出相应的改进建议。
- 有什么经验教训? 如果历史重来一遍，我们会做什么改进?
在需求分析阶段和开发阶段要持续和用户进行沟通，对用户需求有更加清晰把握。避免出现本次基物实验中发布用户已经考完，考试必须用纸记录的乌龙情况。
- 要继续基本测试 -> 给测试分配issue
- 代码覆盖 -> 多分支，有个人专门管理分支
- 没有充分的用户交流 -> 需要
二、计划
- 是否有充足的时间来做计划?
计划时间较为充足，但是做计划时没有为issue分配相应计划
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要通过每人阐述观点，最后如果都不统一，再投票决定。例如本来预计要开发的计算器分析界面，lsp同学就通过举例说明开发涉及的技术风险，说服大家取消了函数分析的功能。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本都做完了，只有数据分析中的不确定度还有草稿箱功能。不确定度由于开发该任务的同学前期进度较慢，同时又代码遗留了一些bug，最终修复完bug后时间不多，加上不确定度作为可选任务，安排靠后，且需要新写页面，最终没有完成。
- 语音输入完善度
- 开始没有考虑到特殊情况
- 开始没有仔细讨论
- 没有测试计划
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，beta阶段每个任务都落到实处
- 是否每一项任务都有清楚定义和衡量的交付件?
都有，开发任务需要提交代码，设计任务需要提交文档。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本按照计划进行，但是由于测试没有同步开发进行，有些bug还是留到了最后测试阶段修复，最后手机用户反馈和修改时间较少。还有一个风险就是基物实验必须要手写签字，beta阶段发布后基物实验已经结束了，这个是由没有进行充分用户沟通。还有一个就是表格美化的风险，表格使用的组件美化复杂程度比想象地高很多，最终导致表格实际输入效果一般，这是由于前期没有进行调研，也没有留下风险预估导致的。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
个人计划又预留缓冲区，但是团队计划没有每个阶段结束后预留一些缓冲区。我认为有两个作用，一个是为可能到来的风险留够时间进行调制，这个主要是团队缓存区的作用，另外一个是为每个开发者能够处理一些bug，冲突之类的情况，属于个人缓冲区的作用。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
要设置整体的团队缓存区，这段时间大家能处理一些新的用户需求之类。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
会在一开始花更多时间与用户进行沟通。前期需求分析阶段对技术还有其他风险要进行评估，能够对风险考虑一个预案。
三、资源
- 我们有足够的资源来完成各项任务么?
时间资源不足，只有五个人，感觉再多一个人会好得多。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
通过PM粗略估计和前/后内部讨论来确定，按照功能划分issue，issue时长在2-8小时区间，1-2天的时间粒度。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于团队只有五个人，所有人都投入了代码的实现中，没有专门的测试人员，所以时间、人力存在欠缺，也导致存在一些bug需要后续修正。图表小程序表示非常需要一个美工！！！
- 你有没有感到你做的事情可以让别人来做（更有效率）?
当然让对技术栈更了解的同学完成某项工作是较快的，但是让该同学完成所有工作那必然是不快的，团队任务在分配好之后就需要每个人完成各自的工作，并按时交付，否则会影响整体进度。
- 有什么经验教训?如果历史重来一遍，我们会做什么改进？
任务要尽可能地划分细致，落到每个人头上。同时要有人进行整体调度，空闲的人要给他安排新的任务。不能靠别人的自觉性，要靠PM的管理。同时PM在激发团队成员的积极性上有所欠缺，要让大家有热情投入到开发中。
四、变更管理
- 每个相关的员工都及时知道了变更的消息?
采用在线文档，PM在变更后在群内通知。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们首先是按照功能的重要程度，杀手级的功能是必须要做的，其中功能比较复杂的我们进行延后。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义，具体情况可见测试报告 。
- 对于可能的变更是否能制定应急计划?
可以制定，对于紧急情况，PM会进行调度，比如后期前端进度偏慢，xyl同学就承担了部分前端的功能。
- 员工是否能够有效地处理意料之外的工作请求？
可以处理，团队成员会根据各自目前的工作进行衡量，如果当前工作不是需要紧急完成，则可以处理这样的工作请求。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
对于文档也可以添加测试，由专门的人员对模板，接口等重要内容进行测试(人手足够的情况下)
五、设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
PM列出提纲，大家在beta阶段修复alph问题时开始讨论，是合适的时间和人。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计过程中遇到的问题主要在会议的讨论中解决，先拟定一个方案，后续在实现过程中根据实际情况进行修改。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
开发过程中使用了单元测试进行代码的测试，在设计过程中使用了UML，更好地表达结构和功能的设计，目前实现功能与预期基本一致，无需修改。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
表格和属性选择。
-
涉及输入
-
缺乏测试
-
涉及情况较多
语音输入，前期没有讨论充分。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
有代码复审，在每个人完成对于issue后在issue下添加评论，再由分配好的复审人进行复审。没有，没有指定代码规范，代码规范上没有出现问题，如果只是格式缩进之类的用相应格式化插件即可，其他复杂的规范也没有精力去指定。
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
引入测试计划，要给测试分配相应issue。
六、测试/发布
- 团队是否有一个测试计划？为什么没有？
没有，前期没有规划测试功能，后期进度又比较赶。
- 是否进行了正式的验收测试？
进行了正式的验收测试，具体情况可见测试报告
- 团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
后端采用postman和junit进行单元测试和压力测试，并使用CI自动进行单元测试。具体情况可见测试报告
- 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
采用junit进行压力测试，并发用户数200，每个用户连续访问50次，对总共50个接口进行了测试，通过每个接口测试的吞吐量、平均延迟、最短延迟、最长延迟等指标测量效能，具体情况可见测试报告 ，测试结果良好。
- 在发布的过程中发现了哪些意外问题？
没有
- 我们学到了什么?如果历史重来一遍，我们会做什么改进？
测试计划要具体划分issue，要一边开发一边进行。互审查要有人推进。
七、团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队的每个角色是根据各自曾经学过的或者有经验的方向进行自主选择，从这个角度来看，每个人都做了自己擅长的事件，是人尽其才。
- 团队成员之间有互相帮助么？
团队成员存在非常多的相互帮助，不管是实现方面还是功能的理解方面，还有前后端的交流，都是非常多的。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队成员会开会进行讨论，提出各自的看法，互相说服，如果最后还没有一致的意见话投票决定。
八、总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
处于已管理级，项目的目标和功能设计比较清晰，审查推荐和文档任务管理等也有秩序推进。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
团队处于规范阶段，正在向创造阶段前进，能各自在自己的角色中完成自己的职责，对于一些问题也能友好讨论达成一致，向着共同的目标努力。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
任务分配上，这次又PM进行整体把控，任务基本都是完成时间，粒度都有了较大改进。变更管理上也较上一个版本有了较大改进，文档统一管理，变更大家也都能收到。
- 你觉得目前最需要改进的一个方面是什么?
在小程序上界面还需要美化。在任务推进上测试计划能够做得更好。
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?
我觉得做得比较好是不断地关注比较好的技能，在界面美化过程中探索了组件样式修改统一方式，并进行记录。
其次还有通过尽早的、持续地交的交付有价值的软件，我们在任务完上按照用户需求重要性，每次完成相应的功能模块，且每次完成一个模块后基本都是可以直接交付的一个完整产品。
- 什么是在下个阶段要改进的地方？
测试计划需要更加详细地指定，需要一边开发一边测试。同时风险管理需要在前期进行充分考虑，对于一些没有预期到的分析要尽量考虑到或者留够缓冲区处理
九、讨论照片
以上是关于Sunny图表——beta阶段总结反思的主要内容，如果未能解决你的问题，请参考以下文章