回顾
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：解决提高学习各个进制转换的兴趣，定义不是很清楚，对典型用户和典型场景没有清晰的描述（例如：没有对基础差的用户进行游戏提示和游戏帮助）
是否有充足的时间来做计划?
答：是，在做这个项目之前，我们进行了广泛的人群调研与需求分析，同时小组间对于本项目的需求，一起进行了详细讨论
团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：我们组内沟通不是很频繁，对于计划其他组员可能有一些不同的意见。但是还是以PM的产品原型为主。 所以没有意见上的冲突！
用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？
答：不一致，（因为我们想要用户通过这个小游戏，来不断提高自己转化进制的能力。而我们没有考虑到一些基础差的用户，没用对应的提示和帮助。所以在用户群体上发生了分化）我们离目标还有一定距离，沟通不足，没有彻底的需求分析。
如果历史重来一遍，我们会做什么改进？
答：在工作方面，团队积极讨论，以免产生不必要的分歧。
在代码方面，团队所有成员加强学习代码能力。
在能力方面，除之外我们还需利用其它时间来进行补充其它方面的能力。
以至于在团队整体提高了效率，对队员的工作方面也是一种很大的补充。
计划
你原计划的工作是否最后都做完了?
答：原定计划的工作最后都做完了。
有没有发现你做了一些事后看来没必要或没多大价值的事?
答：我们所做的事都很有价值，任务当初指定的时候就是为了完成我们的软件，每一件事都很重要.
是否每一项任务都有清楚定义和衡量的交付件?
答：不是，我们团队的每一项任务并没有经过讨论和协商确定，而且部分组内成员对于每个任务该的内容也都不是太清楚。
是否项目的整个过程都按照计划进行?
答：是的吧？项目整个过程大部分按照计划进行的。
在计划中有没有留下缓冲区，缓冲区有作用么?
答：应该有，但是组内人员缺乏沟通，缓冲区形同虚设。
缓冲区的作用：应该是对于各个组员的意见相互碰撞，而体现的区域。应该多次组内开会来来决定各个组员自己想法能否实施。其实就是不断开会，交换想法。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：成员之间想法交流，提高效率。加强组员协调性和团结性，减少理解、意见曲解的问题。
如果历史重来一遍，我们会做什么改进？
答：团队内沟通得体，任务计划合理分配。组员身份职务合理分配。
资源
我们有足够的资源来完成各项任务么?
答：我们有教课老师和专业老师的帮助，以及各种学习资料来完成我们的任务
各项任务所需的时间和其他资源是如何估计的，精度如何?
答：各项任务所需的时间一般是按照任务的难度进行估计安排的，精度低，任务比较笼统。
用户测试的时间，人力和软件/硬件资源是否足够?
答：都很足够
你有没有感到你做的事情可以让别人来做（更有效率）?
答：不清楚，因为当初分配职务的时候不知道怎么就分配了，也没对组内成员的能力进行了解
如果历史重来一遍，我们会做什么改进？
答：如果历史重来
- 我会根据能力合理分配职务，并且有相同能力的成员会建立专项小组。（解释：当有些比较按完成的任务的时候，单个组员优先完成，不能完成的提升为专项小组完成。还不能就全组人员参加完成。当然肯定是优先考虑完成简单任务之后）
变更管理
每个相关的员工都及时知道了变更的消息?
答：不及时，群内少有人员沟通。也没见到私聊分配任务。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：我们依据需求的重要性来分配必须实现的核心功能
项目的出口条件（ExitCriteria）有清晰的定义吗?
答：没有，对这个不是很了解，需要老师的指导
对于可能的变更是否能制定应急计划?
答：没有
- 员工是否能够有效地处理意料之外的工作请求？
答：不能，因为组员能力有限，可能无法应对，需要一起解决
如果历史重来一遍，我们会做什么改进？
答：如果历史重来一遍，我会要求定时进度汇报和任务发布，我发现只有加强组内成员的沟通。才能更好更快的完成项目。
设计和实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作是在选题结束后才进行的。由PM完成，不是合适的时间合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：没有，缺乏组内沟通由PM定下
团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有,不会用
什么功能产生的Bug最多，为什么？
答：1.游戏页面1在你点击帮助文档的时候计时器还在计时器还在计时，并且不是弹出的页面而是把当前游戏页面换个背景图，当你点击下一题的就能跳到下一题（但是游戏结束，没有提示你答对几道题）
代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：是由小组成员完成的，因为没学过，所以没有严格按照代码规范
如果历史重来一遍，我们会做什么改进？
答：如果历史重来，我们完善整体项目，精简一些功能。
并且严格按照代码规范进行编写代码，复审也将严格仔细认真查看！
测试和发布
团队是否有一个测试计划？为什么没有？
答：有测试计划，由软件测评师完成
是否进行了正式的验收测试？
答：没有，时间比较仓促
团队是否有测试工具来帮助测试？
答：有夜神模拟器来帮助
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。
从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，
改进主要还是从软件本身出发，争取能更优化下用户体验。
在发布的过程中发现了哪些意外问题？
没有发布
我们学到了什么? 如果重来一遍, 我们会做什么改进?
软件的开发过程中，测试这一环节是必不可少的。一款软件即使测试完毕发布后，仍然会出现或多或少的问题，
而测试也是需要有技巧性，有针对性的去测试你的软件，而不能照搬其他人的测试方式，软件都有各自独有的特点。
如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，
争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，
并且提前发布一个测试版，让一些用户来统一体验和反馈软件的用户体验。
总结
1.前期组内人员职务分配存在一些问题，没有按能力合理分配。导致后面任务实施困难。
2.组内成员没有沟通，没有例会，群内没有意见交流。使得组员意见不统一，想法不统一，态度不积极。
3.产品没有具体分析，使用群体、主要功能，导致组员对项目的功能、项目意义模糊。
