团队任务五：事后诸葛亮会议-第三组
1.三号团队-团队任务5：项目总结会
-
2.团队信息
- 团队序号：3
- 开发项目名称：守护·恶龙与骑士（兔窝保卫战）
- 整理人：崔凯（项目/产品）-2017035107186
-
3.团队项目地址
-
4.团队会议时间、地点、成员参与情况及照片
-
会议时间：2019.6.25 上午11：00
-
会议地点：图书馆外小凉亭
-
-
5.对设想与目标的回顾
-
墨刀原型地址：https://org.modao.cc/app/253041cbca863528c998c0b146cf5170
-
5.1 我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
-
我们最初想做一款相对独特的游戏，游戏人群定位青少年，并提出了故事游戏这个方向。
-
对于游戏的定义，我们决定了“守护·恶龙与骑士的主题”，通过UI风格的设计、背景音乐的挑选、故事的插入、皮肤的切换、模式玩法的开发等五个方面进行游戏制作。
-
基于游戏开发的网页模式，我们开发了手机版和电脑版。
-
典型用户：能上网的青少年。
-
典型场景：休闲时间，晚上可以一边游戏一边看游戏通关后的故事。
-
-
5.2 是否有充足的时间来做计划？
- 第一次冲刺时，目标相对明确，做一个简单的电脑版游戏框架内容，在任务的安排下进度相对符合。
- 第二次冲刺时，需要开发很多功能模块，并且做了一个手机版的游戏，任务的进度有些出入但也都完成了。
-
5.3 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 团队成员如果有意见会提出来，根据情况来讨论，大部分还是按照预定计划来完成。
-
5.4 用户量、用户对重要功能的接受程度和我们事先预想一致么？我们离目标更近了么？有什么经验教训？如果历史重来一遍，我们会做什么改进？
-
重要功能与设想一致。
-
在第二次冲刺Beta版本中，我们完成了UI风格的设计、背景音乐的挑选、故事的插入、皮肤的切换、模式玩法的开发等五个方面的功能开发。并且区分电脑版和手机版。
-
经验教训：任务分配和任务计划在实施时有一些不足的地方。
-
如果历史可以重来，相信我们可以把游戏做的更好、更完整。
-
-
6.对计划的回顾
-
6.1 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
- 功能方面已经是最终版本了。
- 但还是有一两个Bug未来得及修复，主要是时间和技术问题两个方面不足的原因。
-
6.2 有没有发现你做了一些事后看来没必要或没多大价值的事？
- 因为开发的进度都是按照计划，所有做的东西都有一定价值，只是耗费的时间不同，但都比较正常。
-
**6.3 是否每一项任务都有清楚定义和衡量的交付件？ **
- 码云看板链接：https://gitee.com/yxywudi/rabbit/board
- 除了Bug都已完成并且上传。
-
**6.4 是否项目的整个过程都按照计划进行？ **
-
是根据计划做东西，但在开发的过程中也会讨论修改计划。
-
第一次冲刺：
-
第二次冲刺：
-
-
**6.5 将来的计划会做什么修改？ **
-
要做到计划完整，时间进度明确。
-
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 加强团队成员的参与度，制定一个详细的计划。
-
-
-
7.对资源的回顾
-
7.1 我们有足够的资源来完成各项任务么？
- UI分支地址：https://gitee.com/yxywudi/rabbit/tree/UI设计/
- UI找了许多游戏中需要的图片及音乐。
-
**7.2 各项任务所需的时间和其他资源是如何估计的，精度如何？ **
- 时间安排参照甘特图，时间按天计算。
-
**7.3 测试的时间、人力、和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？ **
- 测试分支地址：https://gitee.com/yxywudi/rabbit/tree/项目测试/
- 主要是测试游戏的运行环境是否出现Bug等情况，反馈给软工。
- 测试需要每天根据软工的上传程序来完成对应的测试。
-
-
8.对变更管理的回顾
-
8.1 每个相关的员工都及时知道了变更的消息吗？
- 在第一次冲刺中，原成员李辰(测试)更换成新成员刘珂溢(UI)
- 成员顾志涛由软工更替为测试
- 成员杨星宇由产品/软工更替为软工
- 成员崔凯由项目/软工更替为项目/产品
- 成员张倩由UI更替为软工/UI
-
8.2 我们采取了什么办法决定“推迟”和“必须实现”的功能？
- 我们推迟了音乐和故事编写这两个任务
- 将功能实现和UI风格设计的图片优先完成，且必须实现
-
8.3 项目的出口条件（Exit Criteria—什么叫“做好了”）有清晰的定义么？
- 有，为了避免审美疲劳，开发了皮肤切换功能。
-
**8.4 对于可能的变更是否能制定应急计划？ **
- 对于变更我们团队是根据职位来分配任务，人的变更不会影响任务的进行。
-
8.5 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 团队的力量可以让我们做出来的东西更完美更多样。
-
-
9.对设计/实现的回顾
-
9.1 设计工作在什么时候，由谁来完成？是合适的时间，合适的人么？
- 最早的设计是团队成员杨星宇做的需求分析及用户调研。
- UI设计师：张鑫宇、张倩以及后加入的刘珂溢等成员，来围绕需求分析和主题设计游戏风格图片和音乐。
-
**9.2 设计工作 有没有碰到模棱两可的情况，团队是如何解决的？ **
- 设计的风格可能UI们有不同的想法，但最终还是按照最早的定位来制作（3D魔幻）。
-
**9.3 团队是否运用单元测试（Unit Test）、测试驱动的开发（TDD）、UML或者其他工具来帮助设计和实现？这些工具有效么？ **
- 我们的网页主要是基于谷歌浏览器来运行制作，测试谷歌运行的效果。
-
**9.4 什么功能产生的bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？ **
-
Bug最多的还是在游戏环节。
-
在设计/开发时也想到过这种情况，主要还是代码方面的问题，需要时间。
-
-
9.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 复审步骤：编译→软工自测→软工上传到码云→测试工程师测试→软工对测试工程师提出来的问题进行解答→发现Bug后列入修改计划
-
9.6 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 测试能保证一个软件它是否可以被展示，或者被成功使用。
- 一个好的测试需要给软工查缺补漏，所以要多学习，跟软工一起进行开发任务。
-
-
10.对测试/发布的回顾
-
10.1 团队有没有测试计划？为什么没有？
- 测试计划就是按照每日软工开发的进度来测试。
-
10.2 有没有做过正式的验收测试？
- 每次冲刺汇报前都会做验收测试，保证运行效果。
-
10.3 团队是否有测试工具来帮助测试？
- 测试基本上是查看谷歌浏览器上的运行效果，出现Bug找软工。
-
10.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试功能有用么？应该有哪些改进？
- 软工会有疏忽的地方，测试可以提高软工的完成度。
-
10.5 在发布的过程中发现了哪些意外问题？
- 冲刺二发布时，手机端的Bug未解决，时间上来不及了。
-
10.6 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 吸取教训后，开发进度应该可以更快的完成。
-
-
11.对团队的角色、管理、合作的回顾
-
11.1 团队的每个角色是如何确定的，是不是人尽其才？
- 队长 崔凯 项目/产品
- 队员 杨星宇 软工
- 队员 顾志涛 测试
- 队员 张鑫宇 UI
- 队员 刘珂溢 UI
- 队员 张倩 UI/软工
- 根据每个人的能力分配的职务。
-
11.2 团队成员之间有互相帮助么？
- 有，但很少会有出现问题的情况。
-
11.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 暂时没有出现类似问题，团队氛围比较和谐。
-
-
12.每个团队有15分的贡献分配分。请团队共同讨论每个成员对团队贡献的大小，根据贡献大小为每个成员分配一定的贡献分。注意，不是每人15分，是一个团队15分，将15分分配给团队中的每个人。例如：团队有5个人，其中成员A的贡献最多，其他人的贡献按子目标顺序依次递减，成员E对团队没做出任何贡献。由此每人的得分是，A：7，B：5，C：2，D：1，E:0。贡献分将直接进入期末考试成绩，请认真给分
- 张倩：3.5
- 崔凯：2.5
- 顾志涛：2.4
- 张鑫宇：2.3
- 杨星宇：2.2
- 刘珂溢：2.1
