团队作业6——事后诸葛亮分析

这个作业属于哪个课程	班级的链接
这个作业要求在哪里	作业要求的链接
这个作业的目标	召开事后诸葛亮会议，发布一篇事后分析报告

团队会议图:

一、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  软件目标：开发一款魔塔游戏，旨在提供丰富的游戏体验，吸引广大玩家。这个问题定义得非常清楚。典型用户为魔塔游戏玩家，典型场景就是魔塔游戏的画面。
2. 我们达到目标了吗？
  目标完成90%，游戏玩法达到预期目标，但是由于时间问题，游戏地图设计略少，游玩时间较短。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  用户量未达到预期目标，但较为接近。用户对重要功能的接受程度和我们事先的预想一致。我们离目标十分接近。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  首先应明确整个开发过程大体要实现那些功能，那些功能可能会加入，在代码框架设计之初为需要的功能留下扩展空间，在后续添加新功能时不仅代码效率更高，还能减少bug的出现。

二、计划

1. 是否有充足的时间来做计划?
  是。
2. 团队在计划阶段是如何解决成员们对于计划的不同意见的？
  通过讨论，提问，综合成员意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
 原计划的工作未全部完成。在开发的过程中学习新技术来时间游戏玩法占了大量时间，游戏地图美工和数量未达到原计划。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
 没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
 是，对每项任务进行紧迫程度的评级，能让我们能够优先完成更重要的任务。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
 没有完美的按照计划进行，在开发的过程总是遇到各种问题。对开发难度低估，由于技术不够熟练总是出现奇奇怪怪的bug浪费时间。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
 有，为游戏开发预留缓冲时间来任务不那么紧迫。缓冲区在一定程度上缓解了项目压力

三、资源

1. 我们有足够的资源来完成各项任务么?
 有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
 由于课程任务多不能专注于软件开发，精度比较模糊,
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
 足够。没有低估美工设计/文案难度，开始就在准备但是由于经验问题仍有不足。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
 没有,成员选择的工作均是各自最擅长的。

四、变更管理

1. 每个相关的员工都及时知道了变更的消息?
 在发生变更时，团队内部通过微信群沟通来确保每个相关的队员都能及时知道变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
 我们可能采用了基于优先级、影响评估、实现难度等多种因素的综合考虑来决定“推迟”和“必须实现”的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
 我们在项目开始前可能已经对出口条件进行了明确的定义，以确保项目能够按照预定的目标和质量标准完成。
4. 对于可能的变更是否能制定应急计划?
 没有制定应急计划，团队内开发人员都具有一定应变能力来应对可能的变更。
5. 员工是否能够有效地处理意料之外的工作请求？
 能。有时候临时出现新的事物,成员能通过自学来了解新事物。

五、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
 由队长在项目开始之前完成，是。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
 没有。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
 没有。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
 人物移动和交互产生的BUG最多，因为人物时游戏操作的主体，几乎所有功能都要对人物进行相关操作。发布后发现连续点击小概率导致人物位移超出预期设置导致游戏崩溃。设计时没考虑到人物移动可能存在检测丢失，导致出现一次两格的位移。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
 由于代码全部都是队长完成编写，其一人进行代码复审，严格执行了代码规范，

六、测试/发布

1. 团队是否有一个测试计划？为什么没有？
 有测试计划。
2. 是否进行了正式的验收测试？
 是的，针对各项功能都进行了测试。
3. 团队是否有测试工具来帮助测试？
 用godot本身进行测试，通过多人游玩游戏来测试游戏bug。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
 在alpha版本完成后，对游戏的各个模块进行测试，且每个队员都游玩一次游戏。最后的运行结果证明了测试工作还是有用的，发现了一些之前没发现的潜在问题。
5. 在发布的过程中发现了哪些意外问题？
 没有意外问题。

七、总结

1.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
 磨合阶段，各成员分工明确，都能积极的去完成自己的任务,但成员之间缺少交流。
2.你觉得目前最需要改进的一个方面是什么?
  团队应多面对面交流,增强团队凝聚力和互动性。

八、团队成员在Alpha阶段的角色和具体贡献

名字	角色	团队贡献分	可验证的贡献
梁志聪	PM和dev	50	游戏整体框架设计，各模块相关代码的编写，修复bug，修改博客初稿
李永杰	test	35	地图设计，剧情设计，bug检测，大部分博客编写初稿
曾繁曦	dev	15	游戏素材寻找，项目复审