此作业要求参见https://edu.cnblogs.com/campus/nenu/2019fall/homework/10005
组名：胜利点
组长：贺敬文
成员：王志文 位军营 徐丽君 彭思雨
事后诸葛亮会议
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述
我们的小程序叫做萌猿纵横字谜，主要提高计算机专业同学对于计算机专业术语单词词汇量，对典型用户和典型场景有清晰的描述，我们针对的用户主要是东北师范大学信息科学与技术研一学生，在翻译英文文献时用我们的小程序会提高单词词汇量。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们没有达到目标，原计划的功能我们完成了四个（选择关卡，联系我们，单词填写，前台背景优化），按照原计划时间交付了，原计划的用户数量达到了。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，质量没有得到提高，与上阶段持平，功能的完成和实现效率不高。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
预想基本一致，我们的用户量现在有65人，我们完成了选择关卡和填写单词等核心功能，光标跳转已经有了方向正在努力，离目标更近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训是我们应该抓住核心功能，在其他功能上浪费时间太多，时间分配应该更加合理，毕竟时间比较紧张。
计划
1. 是否有充足的时间来做计划?
目前感觉时间紧迫，虽然我们的小组从确定选题之前就已经开展了对这个项目的分析与调研，并在确定选题之后，我们就分析了Alpha阶段和Byte段具体要做什么。分工明确，团队的每个人有各自擅长的强项，每个人对于项目的贡献都为之重要，但是在Byte阶段结束后，原来的设计和做出来之后的成品还是有差距
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们每天都有master立会，每个成员都会汇报各自进度，说出自己目前困难，大家一起解决，由当天的master整理成报告。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
光标跳转没有完成，因为时间紧迫，一开始思路有问题。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是。每个阶段开始前，我们会在第一次会议上通过讨论来确定项目的分配，每天的立会都要汇报自己的工作进度。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
是的，我们在任务开始前先开组会确定任务，分配给每个人任务，每个人去完成相应的模块。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
我们的项目预留了缓冲区。因为我们小组是按模块划分任务的，最后要留一个缓冲区测试一下各模块是否都能实现相应的功能，以及对已实现的动能进行讨论修改。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
会把时间分配的更加合理，提高效率。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了如何处理别人与自己观点不一致的情况，小组讨论是非常有必要的。
1. 我们有足够的资源来完成各项任务么?
网络上有各种教程教学文档，还有师兄师姐可以请教，从整体上讲，资源比较丰富。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
任务是根据每个人的能力去分配的，每天大家都会汇报进度，在组会前也会有相应计划，对问题估算后会有完成的时间。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
足够，没有低估难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
没有。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训是尽早讨论合理的安排各个任务，以确保能更快的投入工作，组长负责对整个项目进度把控，分配任务即事先看老师布置的作业。在开始之前一定要多沟通，尽早的投入项目的研发。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
每个相关员工都能及时知道，我们每天都有立会，有时间微信群内也会及时告知。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据我们小程序的用途决定核心功能必须实现，界面优化可以推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
满足了客户的需求，能完成核心功能，没有bug。
4. 对于可能的变更是否能制定应急计划?
能制定。
5. 员工是否能够有效地处理意料之外的工作请求？
不能，因为大家都是第一次接触项目，对于突发事件，可能组内人员也解决不了。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：学到了站在对方角度看问题，可能有得问题你会，可是别人不一定可以理解，所以要站在别人得角度思考问题。学会沟通。
如果历史重来一遍，我们会更加积极的交流，遇到难题的时候大家讨论，在修改之后一定要及时通知大家，这是对项目的责任。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在开始时间，由组长完成，是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到过，团队进行开组会共同协商解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有运用上述工具帮助设计和实现，但是我们运用了燃尽图以及版本控制来辅助记录研发过程。测试的时候是小组内成员通过不断地试玩，提出改进意见的。通过这种方法，可以及时的发现很多问题，并且及时作出修正，比较有效。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
光标跳转功能产生的bug最多，原因是思路方向有问题，发布之后发现输入后正确的提示，在没有进行输入时按确认健也会有，因为时间紧张没有测试所以没有想到。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由组内成员共同审核，严格执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们意识到小组内组员任务分配以及组内人员沟通很重要，刚开始时，对于任务分配模糊不清，导致项目进展很慢。组内人员的沟通时会产生很多分歧，我们也都是逐一分析产生的分歧点在哪，最后选出一个最优解决方案。如果历史重来一遍，我们会在设计阶段加深对用户需求的了解，使得做出的产品更贴合用户的心理，设计出让用户感兴趣的游戏界面，并且更加重视单元测试，基本完善游戏功能，满足用户需求，并且要严格执行代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，我们发布体验版，小组成员进行试用 测试bug。
2. 是否进行了正式的验收测试？
没有。开发时间占用了大部分时间，还没有来得及做这项工作。
3. 团队是否有测试工具来帮助测试？
没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在PC端进行效能测试。从软件实际运行结果来看，这些测试工作很有用，我们可以通过运行结果看出游戏需要改进的地方在哪，同时给我们带来了很大收获，很有效的帮助了我们完善游戏的设计开发。
5. 在发布的过程中发现了哪些意外？
没有。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
在测试/发布阶段，我们学到了如何制定一个完整的测试计划，能够保证游戏在正式发布时功能完善，由于开发阶段的时间周期比较长，所以导致测试计划也不是很完善。
如果重来的话，我们会制定一个完整的测试计划，单元测试，效能分析等，来保证我们产品的质量。
总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI二级。有明确的分工。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
时间和任务分配更加合理。
4.你觉得目前最需要改进的一个方面是什么?
项目测试方面需要加强。
