事后诸葛亮会议
此作业要求参见：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2449
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：“飞词”游戏主要是为了改变包括小学、中学、大学的学生们枯燥乏味的背单词模式，旨在通过learning by playing的理念提高学生们的学习兴趣。
我们软件的主要功能是通过玩飞机大战的方式帮助广大同学快速记忆单词。
张三是一位正在准备英语4级的东北师范大学的大一学生。张三在考前容易出现焦虑、烦躁、自信心不足等悲观情绪，在这种状态下，他无法心平气和的准备即将到来的英语4级考试。而我们的“飞词”小游戏恰恰能弥补张三同学在这期间出现的种种负面情绪，并能帮助他有效的记忆英语4级的单词。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：我们有充足的时间做计划。我们花费了大量时间设想和决定在哪一个时间段该完成项目的哪些具体部分。
beta阶段计划的功能全都做到了
已经按照原计划交付了
原计划达到的用户数量已经达到
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
答：团队的质量有所提高：
团队整体的协作能力提高，因为在beta阶段解决一个问题的时候的我们发现发布解决方案的速度要比阿尔法阶段速度快，更能做到指哪打哪
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：我们项目的计划用户量在10个左右，而且实际上我们的用户量也达到了目标。我们预想的用户应该是玩过飞机大战或者类似的游戏的，而事实并非如此，又由于我们在飞机大战的基础上添加了记忆单词的功能，有很多用户一开始并不知道如何进行操作，这些是我们没想到的。
虽然如此，但是我们实现了最初对该项目的基本需求。因此，我们确实离目标更进一步了。
提出需求时不要一味的追求想象中的美好功能而不顾我们是否有做过此类项目的经验，在这一次经历中，我们发现预想的容易实现的功能需要大费周章才能在计划的时间内勉强实现。
如果历史重来一遍，我们可能会综合理想的需求和实际的项目经验，让需求变得更切合实际。
计划
1. 是否有充足的时间来做计划?
答：是的。我们每一项任务都会在leangoo看板上进行明确的划分，划分包括时间、人物
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：整个工程是按照计划进行的。这主要归功于团队里每个人都乐于沟通，加强了团队内部的合作
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：都完成了。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
答：我们打算继续保持现在的团队风气，互相督促。
5. 是否每一项任务都有清楚定义和衡量的交付件?
答：我们学会了按照各自的分工完成任务。如果重来一遍，我们会更加重视团队合作。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
因为每天都会举行立会，且参考了最后的beta的发布结果，所以整个项目都是按照计划进行。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
我们每天都会将之前的问题进行解决，所以我们在计划中没有留下缓冲区
缓冲区：缓冲区又称为缓存，它是内存空间的一部分。也就是说，在内存空间中预留了一定的存储空间，这些存储空间用来缓冲输入或输出的数据，这部分预留的空间就叫做缓冲区。缓冲区根据其对应的是输入设备还是输出设备，分为输入缓冲区和输出缓冲区。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来会对任务分工可能会有所改变，因为整体的贡献分配需要进行改变。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：有的时候会因为任务完成的时间问题使计划延后。如果重来一遍，我们会将时间精度考虑在内
资源
1. 我们有足够的资源来完成各项任务么?
答：资源是足够的。有很多问题可以通过上网百度解决。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
答：对于之前有过经验的任务，我们是通过经验估计任务所需的时间。没有经验的任务，我们尽最大可能为该任务分配足够多的时间。暂时没考虑时间精度。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：勉强足够。
没有低估其难度，都进行了准确评估。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
没有，因为我们组内所有人员都是按照个人的情况来进行分配的，所以我们组内的各项工作都是按照最高效率进行安排的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：有的时候会因为任务完成的时间问题使计划延后。如果重来一遍，我们会将时间精度考虑在内。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
微信群里都要求分配后都需要回复收到，如若未回复会由组长直接打电话告诉。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们会由组内进行投票表决决定“推迟”和“必须实现”的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有的，可以实现功能就是可以表示“做好了”。
4. 对于可能的变更是否能制定应急计划?
可以，因为我们的工作都是分配好的，所以变更会立马指定应急计划。
5. 员工是否能够有效地处理意料之外的工作请求？
可以，因为我们有过意料之外的工作变更，然后大家都很好的完成工作
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：有的时候会因为任务完成的时间问题使计划延后。如果重来一遍，我们会将时间精度考虑在内。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计由组长主要完成，完成后在团队成员中进行讨论，大家最后决定进行拍板
是合适的时间与合适的人
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
咨询设计专业的同学与有UI工作经验的人进行交流解决
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
运用了UML帮助设计
有效的
现在的用例图更加丰富和完善
因为是项目的新版本不断发布进而完成，产生区别的
需要进行更新
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
暂停阶段产生的bug比较多，因为这是之前没有想到的事情，在阿尔法阶段发生了，所以就重新立即进行修复了
打包成exe文件时出现了黑色的命令框
当时以为是正常情况，但是在展示时发生了问题，所以才发现了是bug出现
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
全体成员互相检查
是的
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
不要以为我们自己的东西就都是正常的，要多多参考别人的项目
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有
2. 是否进行了正式的验收测试？
没有
3. 团队是否有测试工具来帮助测试？
没有
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
直接人工手动进行并跟踪用户使用来跟踪软件效能
从结果看人工效果有用
考虑使用测试工具来帮助测试
5. 在发布的过程中发现了哪些意外问题？
出现笔记本与显示器接触不良，但是使用u盘进行效能展示进行了处理
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在测试阶段考虑使用测试工具来帮助测试
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据每个人的博客与个人意愿来进行确定，是人尽其才的
2. 团队成员之间有互相帮助么？
有
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们会在立会中提出并进行解决
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
王一可：https://www.cnblogs.com/wangyike/p/10064758.html
张帅：https://www.cnblogs.com/handsome-blog/p/10066043.html
徐常实：https://www.cnblogs.com/xvcs/p/10066063.html
赵佳璐：https://www.cnblogs.com/zhaojialu/p/10066120.html
王硕：https://www.cnblogs.com/LY0503/p/10065938.html
祁玉：https://www.cnblogs.com/qiyu023/p/10066080.html
范洪达：https://www.cnblogs.com/fanhongda/p/10066176.html
朱珅莹：https://www.cnblogs.com/zhushenying123/p/10066005.html
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们会举行一次团建来增加团队成员之间的联系
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI二级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
对于分配的工作的完成要比上一个阶段好
你觉得目前最需要改进的一个方面是什么?
对于整个团队的规范化需要进行进一步的改善
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
原则二：敏捷流程欢迎需求的变化，并利用这几种变化来提高用户的竞争优势
我们在各个开发发布时都会积极吸取课堂上给我们提出的意见来进行改善，并在下一次的版本发布时，会给大家来展示我们的改进成果，并对其完善的结果会对用户产生如何积极的影响来进行解读
原则六：无论团队内外，面对面的交流始终是最有效的沟通方式
我们每天都会举行立会然后对现在的问题进行解决
原则七：可用的软件是衡量项目进展的主要指标
我们在每个阶段的展示阶段都会发布具有新功能的可用软件，且新功能是我们上一阶段对这一阶段的新功能的承诺功能
博客要附上全组讨论的照片。
