团队Beta阶段事后分析
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决用户的休闲娱乐问题，为用户提供好玩的模拟经营类的游戏，游戏主题是软件开发公司的成长历程。对典型用户和典型场景有清晰的描述。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们的功能达到了基本目标，总共5个功能做了3个，但没有按照原计划按时交付延期发布，并因此用户没有达到基本目标。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，我们团队的关键工程质量有了提高，首先是文档更加齐全，主要完善了美工文档和策划文档，并重点更新、维护了策划文档；此外整体的风格更加统一了。衡量标准主要是github上的wiki文档的数量以及完备度。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量还在增长，也接受了我们做出的重大功能，与我们的预想基本一致，离目标更近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果要说经验教训的话，我们在当初设计的时候应该选择简单的益智类或者类似的游戏类型而不是模拟经营类游戏，因为模拟经营类游戏在短期来看我们没有良好的美术功底并不能做到在等待过程中很好的游戏体验。
计划
是否有充足的时间来做计划?
我们计划时间很充足，在beta阶段我们总共花了1周多的时间进行策划完善和设计计划。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们通过每天晚上的长时间的策划会议征集大家的意见，并最终由PM决定是否保留争论或者定下功能进行下一步的计划。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作到最后并没有全部做完，因为时间上不太充足，遇到了重大的技术障碍导致我们的工作效率严重下滑。Cocos creator不能支持多人同时开发UI并由于他的环境依赖无法做有效的测试这些都导致了后面开发过程十分缓慢的问题。
有没有发现你做了一些事后看来没必要或没多大价值的事?
在计划初期一直在横向广度上进行功能的探索而不是对于一个功能更加细致的进行设计规划。这个工作在第二周才开始，导致整体进度有些拖后。
是否每一项任务都有清楚定义和衡量的交付件?
是，我们每一项任务都有一个issue以及对应的文档写入或者代码签入可以衡量。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有按照计划进行。项目在中期出了美工开发进度没有赶上开发，这个主要是由于没有及时的督促、进度管理导致的；项目中后期出现了严重的技术问题，主要是当初选择的cocos creator框架的问题，当时没有估计到是因为对这个框架本身没有做过很细致的调查导致的。
在计划中有没有留下缓冲区，缓冲区有作用么?
我们留下了缓冲区，有些作用，但由于强大的技术风险缓冲区瞬间填满并没有发挥全部作用。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划上，加班是一定的，缓冲区上我们需要更加细致的定义，将预留时间改为频繁多轮迭代来设置缓冲区。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在选择框架等技术问题上需要货比三家，多加调研后再去决定，要不技术风险巨大又无法承受。如果历史重来一遍我们首先不会再使用cocos creator并多加调研使用更适合本项目的框架再去进行开发。
资源
我们有足够的资源来完成各项任务么?
我们的美工资源并不足够，组内没有足够的有美术功底的人进行总体的美工设计。其他资源足够完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务根据任务量的大小进行时间估计并写在issue上，并完成后在issue上评论实际所花时间来进行衡量，对下一次任务估计有所帮助。精度上基本都跟预测的一样，比较准确，只是任务量的估计上有些差错。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
在alpha阶段，我们对不需要变成的资源低估了难度导致没有出来好的需求设计等文档以供后续开发，开发流程上也有些混乱。这次我们投入了三个人进行策划设计，两个人进行美工设计，其余进行开发，人力、软件资源都足够，没有低估难度。
你有没有感到你做的事情可以让别人来做（更有效率）?
我感觉基本上没有，我把能让别人来做更有效率的事情尽可能分配了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在资源上我认为下次应该再招收有美术基础的人进行美工设计会更好。
