项目Postmortem
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
现在来看，我们的软件设计并没有一个清晰的目标，也就是说我们并没有一起认真地想过用户有什么需求，现有的产品有什么问题，我们的目标应该是什么如此之类。在描述典型用户和典型场景时，对于典型用户模式的构想基本靠编。 - 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
没有达到目标，功能上说原计划做的动画功能和员工培训功能没有实现，时间上说延迟了两天才交付。 - 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
用户量当时定义的目标是100，如今统计下载量达到了200，姑且算是达到了目标数量。但是我们目前没有对用户反馈进行系统地收集，所以并不清楚用户当前对项目的看法。从关注数量来看，有1/4的人关注了，应该还算不错。
计划
- 是否有充足的时间来做计划?
有大约一周的时间来进行计划，但是我们并不清楚如何做计划。 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
一般是一方说服或者听从另一方。 - 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有都做完，包括动画，需求分析，用户访谈等任务没有做。这类任务普遍来说比较模糊，制定的时候没有想清楚怎么做也没想清楚是不是真的必须做，真的执行起来有很大的惰性。 - 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。 - 是否每一项任务都有清楚定义和衡量的交付件?
大部分任务没有。 - 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
其实准确来说，我们一直没有一个清晰的计划，什么阶段应该完成什么任务，有什么样的评价标准，具体如何执行，分派给谁，分派多少，谁来负责监督都没有明确的定下来。因此出了意外也不奇怪了，有的成员在开会前都不知道自己接下来的任务是什么，稀里糊涂就来了，会议的主持(PM)也不知道开会有什么要讨论的东西，这次会议与我们的总的目标、当前的进展有什么联系。至于为什么会发生这种情况，我想最重要的一个原因就是一开始没有明确的设计目标，尤其是PM，没有这个目标造成的后果就是没有明确的字面上的需求，只有口头上的需求，开发不好分工，问题不好解决，没有依据，只能开发拍脑门。反过来说，PM对项目的功能到底是什么样的都已经不清楚了，对于开发和策划做了哪些改动也是一头雾水，就算和自己的预期不一样也没办法:是你没有给出需求，我们按自己的理解实现了，你又说不对？？ - 在计划中有没有留下缓冲区，缓冲区有作用么?
有，预期的作用是以防预期之外的问题，实际上成了拖延的空间。 - 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?- 在阶段性的任务开展之前，PM至少要了解要实现的东西，并且在进行讨论之前完成规格说明。在开发会议之前每个人应该都要有充分地了解要做的功能是什么。
- 分派任务时尽量确保每个人负责的功能独立的，或者至少和其他人的工作有明确的分割。
- PM应该明确告诉完成工作的人，，需要达到什么样的效果，并且至少中期检查一次，如果有问题及时解决。
- 接受工作的人如果完不成必须及时告知PM，如果不告知是执行者的责任，如果告知了则由PM接手。
资源
- 我们有足够的资源来完成各项任务么?
开发基本足够，但我们缺乏有经验的游戏设计人员和足够的美术人员。在进行项目的测试工作时发现我们使用的引擎CocosCreator相关资料还不够成熟。 - 各项任务所需的时间和其他资源是如何估计的，精度如何?
纯凭感觉，精度极差。 - 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
美工、设计和文案绝对低估了难度。 - 你有没有感到你做的事情可以让别人来做（更有效率）?
感到了，我其实不是一个合格的PM，因为之前积攒的拖延症还有一些不负责的习惯。虽然有所改进，但是如果让其他人来做PM可能会更有效率吧。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我会更多的一些不必要做的工作分担出去，平时更重视及时的把文案编写完成，花足够的精力和时间更进项目的进展。
变更管理
- 每个相关的员工都及时知道了变更的消息?
没有。 - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
基本上是看开发会议当天大家的心情、喜好。另外简单、容易实现的功能往往意味这“必须实现”，很有难度，没有做过的事情意味着“推迟”。 - 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有定义但不清晰，没有更多的判断标准。 - 对于可能的变更是否能制定应急计划?
没有，基本上是把不能做的功能推迟实现了。如果开发发现急着要一个功能一般都是先自己实现了再通知别人。 - 员工是否能够有效地处理意料之外的工作请求？
不能，或者即便处理了也会导致一些问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一定要明确大家阶段性的目标，有文案描述，一开始就要有，PM负责对文案的有效性进行保证。对于与文案不符的实现，PM一定要做出决定:是原来的设计还是新的设计更好，要么改变文案，要么就宁可放弃一部分工作量也要把不合理的变动改回来。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
理论上讲设计工作应该由PM在项目开始阶段制定完成，实际上因为低估了设计的难度和拖延的影响，在需要设计的时候也没有给出来。为了不耽误开发的进度，由团队共同讨论决定了大概的内容，实际开发过程中由具体负责开发的人决定其实现。 - 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，有的人会汇报给PM有的人会自行决定。 - 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 没有进行单元测试，因为之前提到的，所选用的引擎并不内在支持单元测试，又没有第三方工具来提供支持。
- 没有区别，一直没更新，新的改动都是讨论解决。文档没有自己的声音。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由一名成员专门负责代码复审，提出问题并汇报。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
将设计工作和PM工作分交给两个人。
测试/发布
- 团队是否有一个测试计划？为什么没有？
在发布之前的话，没有，因为大家都不知道发布的时候到底该有哪些功能。 - 是否进行了正式的验收测试？
没有，看起来觉得没问题了就发布了。 - 团队是否有测试工具来帮助测试？
目前没有好的测试工具。 - 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
效能跟踪没有做。 - 在发布的过程中发现了哪些意外问题？
- 打包环境变量出了问题，耽误了一天
- 发现我们没有图标，没有广告宣传图。是
- 我们没有提前申请开发者账号，但所幸申请比较快
- 我们的安装包命名与负责打包的人给我的不一样，上传失败，发现用的是默认的包名org.cocos.helloworld..
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
PM:自荐
架构:讨论
开发:讨论
美工:自荐
测试:讨论
我觉得美工和开发算是人尽其才了，但是其他人的位置都有些尴尬。
PM 痛点:一边负责管理项目一边负责设计，设计才进行了一部分又要来做管理，首尾难相顾，既落下了进度，实现的东西和当初的设计又不一样。
架构 痛点:等需求，等需求，等需求。
设计代码结构的时候没有需求很难写清楚，写不清楚的话开发没法实现，就亲自上阵。
测试 痛点:js脚本不像C语言，想进行单元测试很困难，组件的逻辑只能亲自运行，效率太低 - 团队成员之间有互相帮助么？
有 - 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
一般是工作有联系的人之间交流解决。
我感谢 解小锐对我的帮助， 因为某个具体的事情: 发布的时候，由于周末我没有及时完成工作，他指出了我的不足的同时完成了打包、注册开发者账号等事情，并将工作移交给我，之后也一直积极地解决出现的问题。
总结:
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级 - 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
我觉得可能没有太大改进。 - 你觉得目前最需要改进的一个方面是什么?
提升提出需求分析-软件说明，到软件说明-开发的效率，也就是说我们现在最主要的问题很可能不是已实现软件质量不高，而是最终预期的功能无法完全实现。 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
第6点吧，实际来说无论我们在开发还是设计过程中都有大量的线下合作完成任务的过程。