团队Beta阶段事后分析
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决用户的休闲娱乐问题，为用户提供好玩的模拟经营类的游戏，游戏主题是软件开发公司的成长历程。对典型用户和典型场景有清晰的描述。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们的功能达到了基本目标，总共5个功能做了3个，但没有按照原计划按时交付延期发布，并因此用户没有达到基本目标。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，我们团队的关键工程质量有了提高，首先是文档更加齐全，主要完善了美工文档和策划文档，并重点更新、维护了策划文档；此外整体的风格更加统一了。衡量标准主要是github上的wiki文档的数量以及完备度。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量还在增长，也接受了我们做出的重大功能，与我们的预想基本一致，离目标更近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果要说经验教训的话，我们在当初设计的时候应该选择简单的益智类或者类似的游戏类型而不是模拟经营类游戏，因为模拟经营类游戏在短期来看我们没有良好的美术功底并不能做到在等待过程中很好的游戏体验。
计划
是否有充足的时间来做计划?
我们计划时间很充足，在beta阶段我们总共花了1周多的时间进行策划完善和设计计划。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们通过每天晚上的长时间的策划会议征集大家的意见，并最终由PM决定是否保留争论或者定下功能进行下一步的计划。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作到最后并没有全部做完，因为时间上不太充足，遇到了重大的技术障碍导致我们的工作效率严重下滑。Cocos creator不能支持多人同时开发UI并由于他的环境依赖无法做有效的测试这些都导致了后面开发过程十分缓慢的问题。
有没有发现你做了一些事后看来没必要或没多大价值的事?
在计划初期一直在横向广度上进行功能的探索而不是对于一个功能更加细致的进行设计规划。这个工作在第二周才开始，导致整体进度有些拖后。
是否每一项任务都有清楚定义和衡量的交付件?
是，我们每一项任务都有一个issue以及对应的文档写入或者代码签入可以衡量。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有按照计划进行。项目在中期出了美工开发进度没有赶上开发，这个主要是由于没有及时的督促、进度管理导致的；项目中后期出现了严重的技术问题，主要是当初选择的cocos creator框架的问题，当时没有估计到是因为对这个框架本身没有做过很细致的调查导致的。
在计划中有没有留下缓冲区，缓冲区有作用么?
我们留下了缓冲区，有些作用，但由于强大的技术风险缓冲区瞬间填满并没有发挥全部作用。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划上，加班是一定的，缓冲区上我们需要更加细致的定义，将预留时间改为频繁多轮迭代来设置缓冲区。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在选择框架等技术问题上需要货比三家，多加调研后再去决定，要不技术风险巨大又无法承受。如果历史重来一遍我们首先不会再使用cocos creator并多加调研使用更适合本项目的框架再去进行开发。
资源
我们有足够的资源来完成各项任务么?
我们的美工资源并不足够，组内没有足够的有美术功底的人进行总体的美工设计。其他资源足够完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务根据任务量的大小进行时间估计并写在issue上，并完成后在issue上评论实际所花时间来进行衡量，对下一次任务估计有所帮助。精度上基本都跟预测的一样，比较准确，只是任务量的估计上有些差错。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
在alpha阶段，我们对不需要变成的资源低估了难度导致没有出来好的需求设计等文档以供后续开发，开发流程上也有些混乱。这次我们投入了三个人进行策划设计，两个人进行美工设计，其余进行开发，人力、软件资源都足够，没有低估难度。
你有没有感到你做的事情可以让别人来做（更有效率）?
我感觉基本上没有，我把能让别人来做更有效率的事情尽可能分配了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在资源上我认为下次应该再招收有美术基础的人进行美工设计会更好。
变更管理
每个相关的员工都及时知道了变更的消息?
我们通过issue来进行任务分配，并在变更后在相应受影响的issue上进行评论来通知；同时在我们内部的群中进行通知来确保每个人都及时知道了变更的消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们采用优先级划分和任务时间推定的方式来评估每个功能的重要程度以及开发时间，来权衡各个任务是否推迟或者必须实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有明确定义。
我们游戏软件Beta版本的出口条件为：
基本无严重bug，能够正常运行游戏过程，基本功能完善。现在的版本除了Alpha阶段已有的功能以外，还增加了新玩法和全新游戏界面，基本流程能够正常运行。
对于可能的变更是否能制定应急计划?
我们制定了应急计划，比如集中开发，在发现严重的框架技术问题后进行快速地两人结对极限编程等等。
员工是否能够有效地处理意料之外的工作请求？
能有有效的处理意料之外的工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在功能实现上我们应该采用一个功能一个功能的迭代开发而不是同时开发合并的模式。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作分为两部分：策划需求设计和需求到架构的设计。策划需求设计由包括PM的三个人进行设计，主要工作是游戏玩法的设计，在beta阶段的最开始就进行；需求-架构设计由开发组组长进行设计，是在策划功能确定一个后马上开始转换以达到流水增加效率的目的。是合适的时间、合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有遇到模棱两可的情况，但遇到后成员马上在群里提出相关人员马上回复并更新文档，使得这种情况即使发生也没有影响整个开发过程。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们没有运用单元测试，TDD等工具进行测试，因为所使用的环境并不支持。UML文档上由开发人员自行维护，在更改后及时更新文档。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
独立开发功能产生的bug最多，因为这个功能是目前最复杂的功能，不但工作量庞大而且涉及到的其他模块的数量也较多，容易出现问题。在发布之后发现了某些机型没有办法加载图片资源的情况况，这是当时加载方式没有严格规定导致的问题，当时没有考虑到，因为认为框架应该都做好了兼容性的测试。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由组长进行，在后期通过结对编程的方式及时进行代码复审，严格执行代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
代码规范和实现规范我们应该需要考虑更加周全，及时发现问题并更新相应的文档。
测试/发布
团队是否有一个测试计划？为什么没有？
我们只有一个最终的总的测试计划，中间的细节的单元测试等计划是没有的，因为开发环境并不支持单元测试等测试方法，无法测试只能整合后进行综合测试。
是否进行了正式的验收测试？
进行了正式的验收测试，主要由策划组的人进行验收，查看是否达到了当初的设计目标。
团队是否有测试工具来帮助测试？
基本没有，因为环境不支持。在兼容性测试上，使用腾讯的wetest进行测试，加过良好。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们通过腾讯的wetest进行软件的效能测量跟踪。从软件实际运行的结果来看，测试工作有用因为可以确保基本的效能。可以再增加多分支的效能测试。
在发布的过程中发现了哪些意外问题？
打包apk后发布发现包名、版本号是不能改的，无法发布。最终经历了千辛万苦终于在其他ide中打包成功并发布。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
发布要尽可能早，所以下次开发我们先重点开发一个功能确保发布后再开发其他功能。
重申：不要再使用cocos creator。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
我们的分工如下，在刚开始是蔡帜是PM，后来他感觉力不从心更换PM为游心。总体来看是人尽其才的。
- PM：游心
- 策划组：游心、蔡帜、王子铭
- 美工组：王辰昱、赵晓宇
- 开发组：解小锐、陈鑫、李金奇、杨森
团队成员之间有互相帮助么？
有，在遇到问题时在群里反映，其他成员及时帮助以确保高效的开发。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
如果出现问题，首先由组长进行权衡，根本性上的问题比如项目管理上功能的增减等由PM征集大家的意见后做出统一决定，其他成员按照该决定进行工作。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
应该刚开始就更换PM，避免中间更换PM导致的些许混乱。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们应该勉强处于已管理的级别。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我感觉我们的团队基本经历了磨合阶段，即将踏入规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
完成了总的游戏玩法策划设计书，目前的玩法设计上还可以再进行一次或者两次迭代开发，这是一个重大的改进。
此外还更新了三个功能，并完善了美工UI界面，更加友善好看好玩了。
你觉得目前最需要改进的一个方面是什么?
游戏体验还有待提高，游戏的功能还可以再增加，界面可以再炫酷好看有趣一些。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
这条我们做的比较好，我们每天晚上都会集中进行讨论、开发，开发人员、策划人员、美工人员都在场所以开发、讨论的结果可以迅速吸收并投入到开发中，效率较高。
信任
我们完全信任每个人工作的能力并互相鼓励支持。例如在集中开发的时候在一个良好的环境（咖啡馆或者新主楼会议室）进行结对编程。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
我们每天都会开scrum会议进行反省和进度管理，并对下一步的工作进行规划调整。