文章标题格式。②号团队【扫黑除恶Team】-团队任务5:项目总结会
说明团队信息。在文章开头给出团队序号、开发的软件名称、今日整理人姓名与学号以及在团队中的职务。
- 我们是②号团队—扫黑除恶Team，我们开发的软件是飞机大战
- 给出团队项目的代码仓库地址。列出团队所有软件工程师的代码仓库地址并标注哪个是主仓库。
- 给出团队会议的时间、地点、成员参与情况与照片。
- 会议时间1：2019年6月20日上午9点
- 会议时间2：2019年6月24日下午2点
- 会议地点：图书馆三楼西厅
- 参与情况：全员参加
对设想与目标的回顾。
- 我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
- 码云仓库软件原型设计分支链接：https://gitee.com/MrLiu199903/seflash/tree/%E8%BD%AF%E4%BB%B6%E5%8E%9F%E5%9E%8B%E8%AE%BE%E8%AE%A1%E5%88%86%E6%94%AF/
- 我们软件的初衷是使用户轻松的获得成就感；
- 是，我们最开始的目标就是用我们的软件给用户很轻易的带来成就感，以达到放松的效果
- 典型用户：特别年幼的孩子需适度游戏益脑，疲劳游戏伤身
- 典型场景：为响应时代潮流，不支持WindowsXP及以下版本的操作系统
- 是否有充足的时间来做计划？
- 在第一次冲刺的时候，由于需要做的功能比较多，感觉时间不太充足
- 在第二次冲刺的时候，由于对一些知识掌握的不太熟悉，所以，耽搁了一些学习的时间，以至于影响了部分计划，但未影响整体进度
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 处理团队中的意见不合，其实非常简单，我们首先应分析这件事到底哪里产生分歧，这是非常重要的，如果找不到分歧的地方，那么就无法解决这一问题，能找到分歧的地方之后，我们再进行逐一击破，这是最好的办法
- 用户量、用户对重要功能的接受程度和我们事先预想一致么？我们离目标更近了么？有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 基本一致，
- 基本已达到目标，在第二次冲刺时，临时想出的排行榜【已经实现】，模式选择【由于时间关系，未能实现】
- 经验教训：对以前学过的知识点掌握的不够扎实
- 如果时间可以重来，我们会加强努力来实现模式选择功能
对计划的回顾。
- 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
- 目前都做完了，并且增加游戏排行榜功能；美中不足的是：没有游戏模式选择功能，由于这是后期才想到的，所以未能实现
- 有没有发现你做了一些事后看来没必要或没多大价值的事？
- 是否每一项任务都有清楚定义和衡量的交付件？
- 是否项目的整个过程都按照计划进行？
- 在第一次冲刺的时候基本上是按照计划进行，在第二次冲刺的时候由于对知识掌握的不足、实现有些功能的时候，未能按照计划进行
第一阶段冲刺甘特图：
第二阶段冲刺甘特图：
- 将来的计划会做什么修改？
- 根据用户的反馈信息来修改bug
- 定期发布调查问卷，适当的进行功能的维护与更新
- 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 团队合作中不是展示个人的能力有多么的强，而是团队的默契；当然也不能忽略个人的能力
- 如果时间可以重来，我们会节省出找素材的时间，来制定一个详细的计划
对资源的回顾。
我们有足够的资源来完成各项任务么？
各项任务所需的时间和其他资源是如何估计的，精度如何？
测试的时间、人力、和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
你有没有感到你做 的事情可以让别人来做（更有效率）？
- 没有，由于团队开始任务分工比较明确，所以，我们每个人度不可替代
有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 有时，由于网络网络环境的原因，未能及时上传测试报告，但都会及时补上传
- 以前，在未讲测试之前，我们都是针对某一功能进行测试，在讲测试之后，我们的测试方案分为黑盒测试和白盒测试
对变更管理的回顾。
- 每个相关的员工都及时知道了变更的消息吗？
- 我们采取了什么办法决定“推迟”和“必须实现”的功能？
- 经过团队商讨，不是特别紧急的任务，选择推迟，严重影响游戏效果的功能必须紧急实现
- 项目的出口条件（Exit Criteria—什么叫“做好了”）有清晰的定义么？
- 有，实现基本的功能，并且在实现常规的飞机大战的功能基础上增加特殊技能【空投】，来增加游戏的可玩性
- 对于可能的变更是否能制定应急计划？
- 首先，我们会对变更的需求进行合理化分析，觉得是否合理。如果不合理，方案直接被pass，先继续原来的工作，并和变更提出人进行解释；如果合理，将变更内容列入计划，紧急修改相关的文档，来确保变更的内容安排在计划中
- 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 通过本次合作，我们知晓了一个人的力量肯定比不过一个团结的团队的力量
对设计/实现的回顾。
- 设计工作在什么时候，由谁来完成？是合适的时间，合适的人么？
- 设计工作是在在2019年4月9日—2019年4月22日，由之前的产品经理刘新飞来完成，时间是我们第一次刚组建团队的时间，我们及时的选择了项目，并积极的进行用户调研，所以我们觉得时间和人都是非常合适的
- 设计工作 有没有碰到模棱两可的情况，团队是如何解决的？
- 由于队长对团队的要求非常高，一直没出现模棱两可的情况
- 团队是否运用单元测试（Unit Test）、测试驱动的开发（TDD）、UML或者其他工具来帮助设计和实现？这些工具有效么？
- 我们的测试步骤是：程序打包→以最快的速度运行到当日被测试的功能→比较实际结果和预期结果
- 我们用的打包的工具是pyInstaller，在打包之前先用jetbrains Pycharm查看代码是否有逻辑错误
- 这些工具在我们团队看来是有效的，因为可以简洁明了的查看错误的所在
- 什么功能产生的bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？
- 我们在开发飞机大战游戏的时候产生bug最多的地方就是暂停按钮，因为当按下暂停按钮时音乐还会继续播放，在修复这个bug上耽误很多时间，但是没有影响带项目的进度，在发布之后我们还没有测试出来有任何的bug，其实最初我们设计的时候有想过会出现很多bug，就是没有想到有的bug很棘手。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 我们复审的步骤是：编译→软件工程师自测→查看软件工程师上传到码云仓库的代码→两位软件测试工程师各抒己见→软件工程师对软件测试工程师提出来的问题进行解答→软件测试工程师商量意见
- 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 测试软件是否好用，我个人觉得首先要读懂软件工程师的代码；其次，才能领悟软件工程师到底想要做什么、实现什么；如果历史可以重来，我们将会多投入一些时间，来学习python跳转那一部分，因为我们在实现跳转的时候花费的时间过长
对测试/发布的回顾。
- 团队有没有测试计划？为什么没有？
- 没有，因为对于飞机大战这个游戏的开发来说，不好寻找测试用例
- 有没有做过正式的验收测试？
- 有，我们每天在软件工程师提交代码之后，都会在当天进行测试，并及时的把bug问题提交到issues
- 团队是否有测试工具来帮助测试？
- 如果非要说测试工具，那就是jetbrains Pycharm这个编辑器了，因为它能使一些代码高亮显示，更能直观的显示逻辑错误，并且jetbrains Pycharm这个软件，还能在里面安装一些pip不能安装的第三方库，使用方便。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试功能有用么？应该有哪些改进？
- 当天开发，当天测试；在产生bug时，还需及时测试之前的功能是否还能正常使用
- 从软件的实际运行结果来看，这些测试功能是有用的，因为我们可以在印象很深的时候，及时回归正轨，我们需要做的改进是，在测试的时候增加场景模式，例如Windows64位系统和Windows32位系统下，软件的差别在哪
- 在发布的过程中发现了哪些意外问题？
- 我们在发布软件的时候，为防止出错分别上传到了腾讯微云和百度云网盘，给大家提供链接进行下载，没有遇到问题。其次，我们组的组长是2018级的软件一班辅导员助理，并在他们的微信群，可以由组长向2018级软件一班的同学进行推广使用
- 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 软件测试工程师在教师讲过测试之后，撰写的测试文档更为规范；例如测试环境……。
- 如果历史重来一遍，我们将会从头到尾撰写规范的测试文档
对团队的角色、管理、合作的回顾。
每个团队有15分的贡献分配分。请团队共同讨论每个成员对团队贡献的大小，根据贡献大小为每个成员分配一定的贡献分。注意，不是每人15分，是一个团队15分，将15分分配给团队中的每个人。例如：团队有5个人，其中成员A的贡献最多，其他人的贡献按子目标顺序依次递减，成员E对团队没做出任何贡献。由此每人的得分是，A：7，B：5，C：2，D：1，E:0。贡献分将直接进入期末考试成绩，请认真给分。
| 刘新飞【软件测试工程师&&队长】 |
4 |
| 张宇情【软件工程师】 |
4 |
| 刘威骏【产品经理&&项目经理】 |
2 |
| 李梓宁【软件工程师】 |
2 |
| 张含涛【软件测试工程师】 |
1.5 |
| 任学斌【UI设计师】 |
1.5 |
②号团队【扫黑除恶Team】-团队任务5:项目总结会
原文：https://www.cnblogs.com/MrLiu199903/p/11077071.html
