一、总结提纲

（一）Postmortem

1、设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
    我们的软件主要是给玩家用户提供一个休闲途径，我们的定义很明确，做一款躲避障碍的小游戏，在前面的博客中对典型用户和场景进行过明确的描述。
  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
    很遗憾，限于精力和时间，我们仅完成了大部分目标，原计划功能已实现的有游戏基础界面，正常游戏功能（小球旋转、障碍生成和碰撞检测），积分计算和菜单栏选项功能。由于一些小问题，我们比原计划交付时间晚了几天，因为没有进行相关推广，故没有达到原计划用户数量。
  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
    由于缺乏推广，用户量与预想不一致，另外通过其他团队对我们的评测复审，可以看出我们的项目游戏界面和玩法模式过于单一。因此我们离目标还有很远的一段路要走。

2、计划

  1. 是否有充足的时间来做计划?
    是的，有充足的时间进行计划。
  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
    先各自提出自己的想法，再由组长依据情况进行判断选择，或进行投票决定。
  3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
    基本工作都完成了，后面因为其他考试，限于时间精力，没有对一些完善游戏的功能进行整合
  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
    暂时没有。
  5. 是否每一项任务都有清楚定义和衡量的交付件?
    是的，交付件由组长和测试进行最终衡量
  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
    项目后期出了一些问题很难处理——游戏结束界面的生成，是因为前期设计的时候没有考虑好，导致后面完成该功能时会与项目整体框架发生冲突。主要原因还是缺乏项目经验吧。
  7. 在计划中有没有留下缓冲区，缓冲区有作用么?
    有，起到一定作用。
  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
    在设计项目的时候考虑更多点，将组件要求描述更加清楚方便开发人员进行开发。

3、资源

  1. 我们有足够的资源来完成各项任务么？
  • 人力资源：我们团队有6个人，除了PM外，有3名开发和2名测试
  • 开发资源：组长整理了部分开发所需的基础知识和技术文档
  • 设备资源：人手一台电脑，足够完成开发测试任务
  • 时间资源：有些紧张，其他课程也有实验课设作业和考试，软工的项目时间跨度和工作量有点大。
  1. 各项任务所需的时间和其他资源是如何估计的，精度如何？
    组长发布任务后，由组员先自我评估，组长再结合整个项目进行评估，主观评估因此精度不是很准。
  2. 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
    足够，美工设计上低估了难度，从其他人的复审可以看出，我们的界面过于单一。
  3. 你有没有感觉你做的事情可以让别人来做（更有效率）？
    一般来说开发人员编程后应顺手进行单元测试，这样会比让测试人员去测试更有效率，因为此时开发对代码的整个逻辑更为熟悉。

4、变更管理

  1. 每个相关的员工都及时知道了变更的消息？
    基本知道，成员更新代码后会上传至Coding.net，并在微信群通知一下大家。测试人员测试有问题时也会进行告知。
  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
    基础功能“必须实现”，次要功能或实现难度过大则可进行“推迟”。
  3. 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
    有，定义如下：
    • 软件不崩溃闪退
    • 测试发现的bug得到修复
    • 典型用户场景得到测试并无bug
    • 测试矩阵中的典型情况得到测试并无bug
  4. 对于可能的变更是否能指定应急计划？
    我们进行了良好的分支管理，对于提交的功能，经过组长和测试review发现没问题后再对项目分支进行合并。即使发生意外，也可以通过回退至上一个正确版本再进行问题解决。
  5. 员工是否能有效地处理意料之外的工作请求？
    可以，比如博客文章撰写工作量大的时候会进行轮流分配。

5、设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
    设计工作在项目开始的第一二周进行，主要由组长来完成，辅以成员讨论。时间充裕，人员合适。
  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
    进行开发时，开发人员与组长的预想实现方式可能不一样，一般这时候会进行讨论，选出最佳解决方案。
  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
    虽然仅是简单的一款小游戏，但我们运用过单元测试对功能模块进行测试以及利用UML进行需求分析和模块划分。
  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
    返回主界面和游戏结束界面，由于跟早期的设计理念有一定冲突。
    发布后发现图片资源无法正常加载，这导致了游戏界面过于单一。
  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
    由组长和测试进行Code Review，由于开发初期已制定代码规范，故对代码规范有做要求。

6、测试/发布

  1. 团队是否有一个测试计划？为什么没有？
    有，详见上一篇博客。
  2. 是否进行了正式的验收测试？
    进行过验收测试，但应该不够正式严格。
  3. 团队是否有测试工具来帮助测试？
    仅单元测试工具，如Junit
  4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
    软件的效能主要是指游戏过程中的流畅性和功能的正常运行，从实际结果看，开发工作和测试工作都完成得不错。
  5. 在发布的过程中发现了哪些意外问题？
    发布后发现界面的图片资源无法正常加载。

7、总结

  1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
  2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
    我认为到团队处于磨合和规范阶段之间，很多事情上能取得一致，但整个团队的规范仍需要完善。
  3. 你觉得目前最需要改进的一个方面是什么?
    功能模块的划分需要更清晰明确，方便开发人员进行开发，也减少Bug的发生。角色和职责定义要落到实处，避免出现成员间任务负担失衡。

（二）讨论照片

讨论照片

二、团队成员在Alpha阶段的角色及贡献

姓名 角色 团队贡献分 可验证贡献
张鸿 PM 23 撰写博客，功能代码编写
夏浚杰 DEV 19 撰写博客，功能代码编写
萧英杰 TEST 20 撰写博客，代码测试
谢嘉帆 DEV 22 撰写博客，功能代码编写
杨辉鹏 DEV 21 撰写博客，界面开发
陈嘉曼 TEST 15 撰写博客，代码测试