此作业要求：[https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324]
组名：拉格朗日2018
组长：王一可
组员：王硕，赵佳璐，范靖旋，祁玉，范洪达，徐常实，张帅
拉格朗日2018“飞词”游戏项目
Postmortem结果
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：“飞词”游戏主要是为了改变包括小学、中学、大学的学生们枯燥乏味的背单词模式，旨在通过learning by playing的理念提高学生们的学习兴趣。
我们软件的主要功能是通过玩飞机大战的方式帮助广大同学快速记忆单词。
张三是一位正在准备英语4级的东北师范大学的大一学生。张三在考前容易出现焦虑、烦躁、自信心不足等悲观情绪，在这种状态下，他无法心平气和的准备即将到来的英语4级考试。而我们的“飞词”小游戏恰恰能弥补张三同学在这期间出现的种种负面情绪，并能帮助他有效的记忆英语4级的单词。
2.是否有充足的时间来做计划?
答：我们有充足的时间做计划。我们花费了大量时间设想和决定在哪一个时间段该完成项目的哪些具体部分。比如：一周内完成游戏中带有字母的敌机随机出现。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：对于计划的不同意见，我们基本通过在立会上和微信讨论组里讨论并解决问题。当组员提出计划的不同意见时，我们会讨论并共同思考如何解决提出的问题。多数情况下，我们都能找到解决问题的办法。
4.用户量、用户对重要功能的接受程度和我们事先的设想一直吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：我们项目的计划用户量在10个左右，而且实际上我们的用户量也达到了目标。我们预想的用户应该是玩过飞机大战或者类似的游戏的，而事实并非如此，又由于我们在飞机大战的基础上添加了记忆单词的功能，有很多用户一开始并不知道如何进行操作，这些是我们没想到的。
虽然如此，但是我们实现了最初对该项目的基本需求。因此，我们确实离目标更进一步了。
提出需求时不要一味的追求想象中的美好功能而不顾我们是否有做过此类项目的经验，在这一次经历中，我们发现预想的容易实现的功能需要大费周章才能在计划的时间内勉强实现。
如果历史重来一遍，我们可能会综合理想的需求和实际的项目经验，让需求变得更切合实际。
计划
1.是否每一项任务都有清楚定义和衡量的交付件?
答：是的。我们每一项任务都会在leangoo看板上进行明确的划分，划分包括时间、人物。
2.是否项目的整个过程都按照计划进行?
答：整个工程是按照计划进行的。这主要归功于团队里每个人都乐于沟通，加强了团队内部的合作。
3.在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们在计划中没有设置缓冲区。
4.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：我们打算继续保持现在的团队风气，互相督促。
5.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了按照各自的分工完成任务。如果重来一遍，我们会更加重视团队合作。
资源
1.我们有足够的资源来完成各项任务么?
答：资源是足够的。有很多问题可以通过上网百度解决。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：对于之前有过经验的任务，我们是通过经验估计任务所需的时间。没有经验的任务，我们尽最大可能为该任务分配足够多的时间。暂时没考虑时间精度。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：勉强足够。
4.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：有的时候会因为任务完成的时间问题使计划延后。如果重来一遍，我们会将时间精度考虑在内。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：是的。我们在微信讨论组和每日立会上都会及时发布和汇报每个人的任务进程。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：我们在开会前列举出所有可能实现的功能，会上进行讨论，最后以举手表决的形式决定哪些是可以“推迟”的功能，哪些是“必须实现”的功能。
3.项目的出口条件（ExitCriteria）有清晰的定义吗?
答：有。我们认为能按顺序击落敌机是我们的出口条件。
4.对于可能的变更是否能制定应急计划?
答：能。
5.员工是否能够有效地处理意料之外的工作请求？
答：可以。在时间允许的范围内，我们大家是可以接受并且有效处理临时的分工的。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了如何在团队项目上进行有效沟通。如果重来一遍，我们会继续保持现在的风格。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作在编写代码前，由具有丰富游戏经历的成员来完成。我们认为是合适的时间，是合适的人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有模棱两可的情况。模棱两可的情况一般是现阶段可实现也可不实现的非核心功能，我们可以暂时搁置这样的情况。如果是核心功能有模棱两可的情况，我们会通过举手表决的形式解决。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：我们没有运用单元测试，测试驱动的开发、UML，或者其他工具。
4.什么功能产生的Bug最多，为什么？
答：有的字母一直不会出现在屏幕上。原因是我们没有把前面的字母清空。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：我们在变量和函数的命名上严格执行了代码规范，代码的可读性比较高。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了如何在写代码的方面进行团队合作。如果重来一遍，我们会在测试出问题时，及时告知团队所有成员，集思广益应该是最有效的办法。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划。我们在阿尔法阶段项目完成时，将项目交给不同的人进行测试，这些人大多是在读的学生或者刚就业的同学。
2.是否进行了正式的验收测试？
答：是的。我们收集了19个人的游戏体验，他们的反馈有很多是在我们意料之外的。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：我们暂时没有测量软件的效能。
5.在发布的过程中发现了哪些意外问题？
答：发布的过程中，股东发现程序运行时，会出现cmd控制台，这是我们的疏忽。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：在软件发布的过程中，发生了我们意想不到的问题，我们应该意识到测试的重要性。如果能重来一次，我们会做一个更详细的测试计划，尽可能避免意外问题的发生。