此作业要求参见：http://edu.cnblogs.com/campus/nenu/2019fall/homework/10005
组长:康哲
组员：付宇泽 都雪冬 齐文华 杨萍
事后诸葛亮会议：
设想和目标
1.在Beta阶段的软件质量提高了吗？是在哪里体现出来的？
答：别吃错了在beta阶段的质量取得了显著的提高，具体表现在以下几个方面：（1）游戏小人不用按住不松也可以移动。（2）现在可以吃错三个单词，不像一开始吃错一个游戏就结束了。（3）增加了游戏规则，对于从来没有玩过我们游戏的人又各简单介绍，可以更快了解我们产品。
2.在Beta阶段软件工程的质量提高了吗？具体表现在那些方面？
答：Beta阶段软件工程的质量也得到了提高。主要表现在一下几个方面：（1）代码进行了版本控制，并且每天都check in。（2）代码编写更加规范，根据制定的代码规范严格遵守。
3.用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：本项目Beta阶段共有15名用户，比预想用户多。用户在使用小程序的时候开始关注页面设计和页面展示效果是我们之前没想到的，比如小人手中的棒子要能挥动，背景图和我们游戏有什么关系。
我们离目标确实更近了，项目完成度已达80%，还剩一级要求：小人闪烁，小人手中的棒子要能挥动，二级要求：背景图片，吃错单词时要有个反馈，让用户可以知道那个单词吃错了。
经验教训是团队开发的时候版本控制一定要每天做，不能老是忘记。
如果重来一遍，一定会尽早定下题目方向，并且会定个熟悉的方向。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：不是。小人闪烁还没有完成，因为我们团队是使用微信小程序开发的，不是使用微信小游戏，所以小人闪烁问题还没有能解决。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：没有，所有的事情在后续工作中经过检验都是值得的。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。每一项任务都有明确的定义，都会由预先指定的人来完成。交付时也都是大家同意的情况下才算完成任务。
4.是否项目的整个过程都按照计划进行?
答：基本上。因为小组每天都会召开立会总结昨日工作，如果该项工作完成会继续制订今日计划；如果未完成，小组成员集体讨论未完成原因，确认是否该项任务有一定难度，会重新制订执行计划和执行方式。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
答：否。缓冲区为整个项目的按计划完成增加了保障。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：尽量设置缓冲区。着重解决bug，在已有功能核心bug解决的情况下在整合新添加的功能。
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：团队经验的重要性，团队里需要有一个带头人，思路清晰且有条理的解决项目问题以及团队合作问题。
花更多的时间来解决核心问题的bug，如我们组本次发布中的闪烁bug，已经影响用户体验。
资源
1.我们有足够的资源来完成各项任务么?
答：资源不是很充足，需要花时间来学习项目中各种问题的解决办法，因此有时候开发时间不够。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：各项任务的时间我们通过小组会议，通过组员对能力的把握来设置任务时间，精度到天。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有。我们组成员之间随着不断地熟悉在制订任务分配时有非常细致的分工，完全依据个人精力和能力来分配任务。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：各项任务和时间的设置一定要考虑各种因素。如果重新来一遍会使项目的时间分配更加合理。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：相关员工都及时知道了消息。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：通过团队成员们一起估计，哪个问题需要优先解决，优先级低的则选择推迟实现。
3.项目的出口条件（ExitCriteria）有清晰的定义吗?
答：有。吃错中文释义就会游戏结束。
4.对于可能的变更是否能制定应急计划?
答：能。
5.员工是否能够有效地处理意料之外的工作请求？
答：能。每个组员都有效的完成了非计划内的工作。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：进行有效的沟通可以使团队能够效率高的，达到预期的完成任务。
下一次，在遇到单个人或少数几个人不能快速解决的问题时。一定会及时让所有组员一起商讨解决方法。使计划顺利按期完成。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作由所有组员讨论完成。时间和人都合适。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：没有遇到。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有这些种类的工具帮助实现。
4.什么功能产生的Bug最多，为什么？
答：游戏中，屏幕闪烁最多。游戏界面的刷新频次高。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：编码人员多次复审，严格执行了代码规范。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：合理分配编码任务的重要性。重来一遍的话，会更合理的分配编码任务，使得有些代码问题更有效的解决。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划，但是由于团队人员对于项目已经比较了解，所以反馈比较少。
2.是否进行了正式的验收测试？
答：还没进行正式的验收测试。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：目前没有测试软件的效能。
5.在发布的过程中发现了哪些意外问题？
答：发布过程中，小程序的号的注册错误，使得发布的版本的项目名为“别吃错le”，没有使用预期的项目"别吃错喽”
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：准备充足的时间做测试很重要。重来一遍的话，我们会留出充足的时间进行测试，有效发现bug并解决，提高用户体验。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
答：每个阶段开始时的第一次站立会议，由组长整理本阶段任务量，组员根据个人兴趣和能力进行认领，同时小组成员之间也会适当调换。因此做到了人尽其才。
2. 团队成员之间有互相帮助么？
答：有。团队成员彼此之间关系融洽，一人遇到困难时会寻求组员帮助，其他组员看到问题会积极帮忙解决。若解决不了则会开会讨论。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
答：及时提出问题，大家共同讨论解决问题。
4.每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）：
杨萍：https://www.cnblogs.com/ping2yingshi/p/11872052.html
齐文华：https://www.cnblogs.com/qiwh/p/11880260.html
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：团队开发中比较重要的是合作。虽然有时候一个人就可以完成任务量，但是每个人在团队中根据自己能力、兴趣的不同扮演着不同的角色，彼此信任，相互合作才是一个较为成功的团队。我们小组在这一方面自我感觉做的不错，如果历史重来一遍，我们会更加注重高效的合作，尽早高质量的完成任务。
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：CMMI二级，有明确的任务分工，不会因为一些随机因素任务就失败了。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：规范。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：工作效率更高，不错的完成了本阶段的工作。
4.你觉得目前最需要改进的一个方面是什么?
答：找不是本项目的人员进行测试，以便更好的反馈项目问题。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
答：
1） 第六条“无论团队内外，面对面的交流始终是最有效的沟通方式”
站立会议确保了每天的面对面交流，每日会议每人汇报一下自己的进度，大家及时交流有困难的地方，共同讨论出解决方案。
2） 第十条“保持简明——尽可能简化工作量的技艺——极为重要”
如果解决问题的方法有多个，选择最简单的一个。