此作业要求：[https://edu.cnblogs.com/campus/nenu/2019fall/homework/9861]
组名： 胜利点
组长：贺敬文
组员：王志文，位军营，彭思雨，杨萍
萌猿纵横字谜项目事后诸葛亮会议结果
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：首先我们的小程序叫萌猿纵横字谜，指在提高程序员计算机英语词汇。我们所提倡的就是趣味游戏与学习知识相结合，打破枯燥的死记硬背的模式，构建一种全新的趣味学习模式，在玩中学习。我们针对的用户主要是东北师范大学信息科学与技术研一学生，在翻译英文文献时用我们的小程序会提高单词词汇量。
2.是否有充足的时间来做计划?
答：目前感觉时间紧迫，虽然我们的小组从确定选题之前就已经开展了对这个项目的分析与调研，并在确定选题之后，我们就分析了Alpha阶段和贝塔阶段具体要做什么。分工明确，团队的每个人有各自擅长的强项，每个人对于项目的贡献都为之重要，但是在Alpha阶段结束后，原来的设计和做出来之后的成品还是有差距。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：在项目确定后，我们就就计划那个阶段要做什么，然后每天都有master立会，每个成员都会汇报各自进度，说出自己目前困难，大家一起解决，由当天的master整理成报告。
4.用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：我们本次项目的Alpha阶段实现了可以填写单词，并且错误单词会有红色提示，它也是我们产品的重要功能之一，你可以根据提示，填写单词。我们的产品在Alpha阶段共有名用38户，他们使用了我们的小程序，并给我们项目提出了宝贵的意见，比如输入单词不友好，没有返回键等，这些意见也使我们的产品更加完善，通过与用户的交流，我们可以及时的改善用户的需求，用户对于我们这个产品很看好，但是界面细节还有很大提高。
我们离目标确实更近了，目前已经实现了返回按钮，游戏规则功能。
经验教训是我们前期想的和后期做做来的成品还是有比较大的差距，在写代码时只考虑部分功能，最后添加功能时，非常费劲。
如果重来一遍， 我们会一起写代码，一起做其他任务，而不是把工作代码和其他工作分开进行，这导致我们后期有的开发人员不会项目代码，我们也会系统的学习这门语音而不是对于工程来说用到什么去学什么。 这对后面的开发有些困难，但是时间估计不允许。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：原计划的工作基本已经完成但是游戏引擎部分还没有完成，因为我们没有服务器。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：有，我们小程序添加了客服人员，本来想直接可以有客服服务，后来时间限制，直接把我们组内的二维码写到页面上，导致最后发布时因为商业活动审核不过。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。每个阶段开始前，我们会在第一次会议上通过讨论来确定项目的分配，每天的立会都要汇报自己的工作进度。
4.是否项目的整个过程都按照计划进行?
答： 是的，我们在任务开始前先开组会确定任务，分配给每个人任务，每个人去完成相应的模块，这种模式在后期也会延续。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们的项目预留了缓冲区。因为我们小组是按模块划分任务的，最后要留一个缓冲区测试一下各模块是否都能实现相应的功能，以及对已实现的动能进行讨论修改。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：每周的任务是在前一任务下进行的，我们在开始计划前都会开组会，对本周分配任务，在任务量大，或者有困难时，我们会及时调整计划。
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了如何采纳别人的观点，及时汇报自己进度，团队合作，处理矛盾。
资源
1.我们有足够的资源来完成各项任务么?
答： 网络上有各种教程教学文档，从整体上讲，资源比较丰富。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：任务是根据每个人的能力去分配的，每天大家都会汇报进度，在组会前也会有相应计划，对问题估算后会有完成的时间。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：有，我文字编辑能力差，如果写博客这部分别人来做，可能效率更高。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：经验教训是尽早讨论合理的安排各个任务，以确保能更快的投入工作，组长负责对整个项目进度把控，分配任务即事先看老师布置的作业。在开始之前一定要多沟通，尽早的投入项目的研发。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：是的。
每次会议大家都会汇报自己的工作进度，我们也有小群，变更问题都会在群里及时说。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：核心代码部分是必须实现的，在界面美观和界面友好性方面我们才取得推迟。
3. 项目的出口条件（ExitCriteria）有清晰的定义吗?
出口条件（ExitCriteria）清晰的定义：首先程序可以正常使用，其次友好性强，没有bug。
4.对于可能的变更是否能制定应急计划?
答：能。根据紧急情况会通过语言或者电话的方式紧急通知到各个人，根据任务的紧急情况来确定是否及时召开组会。
5.员工是否能够有效地处理意料之外的工作请求？
答：不能，因为大家都是第一次接触项目，对于突发事件，可能组内人员也解决步来，讨论几天，会向师兄师姐请教，这样整体进度就慢了下来。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：学会换位思考，可能有得问题你会，可是别人不一定可以理解，所以要站在别人得角度思考问题。
沟通，是相互学习得过程。
执行力与适应力是影响工作完成进度的标准，这方面的能力一定要训练好。
如果历史重来一遍，我们会更加积极的交流，遇到难题的时候大家讨论，在修改之后一定要及时通知大家，这是对项目的责任。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：在设计方面，由于时间比较仓促，我们对于游戏界面的设计没有花费太多心思，很普通的空白界面，这也是导致用户数量没有达到理想化的原因之一。在“尸体解剖”阶段，我们思考了这个问题，因为该微信小游戏是针对于东北师范大学信息科学与技术学院研一学生的产品，并且背单词对于大多数人来说都是枯燥乏味的，因此，UI设计更倾向于卡通、舒适的风格，这个任务的分配首先要了解组员们曾经在设计方面的经验，然后根据能力去分配适合的人物，结果也比较理想。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，但不多。在功能方面上出于对技术上的把握与游戏性能的平衡，我们对游戏模式的友好性如何实现感到犹豫不决，无法明确怎么才能最大化的影响用户，通过对市场的调研与演练，并且团队的讨论，投票，最终确定了合理的产品方向。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有运用上述工具帮助设计和实现，但是我们运用了燃尽图以及版本控制来辅助记录研发过程。测试的时候是小组内成员通过不断地试玩，提出改进意见的。通过这种方法，可以及时的发现很多问题，并且及时作出修正，比较有效。
4.什么功能产生的Bug最多，为什么？
答：就目前来说，萌猿纵横字谜在用户进入游戏界面，进行输入单词的时候，不能一气呵成将单词写完，而是需要一个一个点输入框进行输入，在用户友好性方面出现的Bug比较多，后来经过测试也更改修改了这个Bug。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：在确定选题之后，我们就确定了语言，并且按照这个语言的特点定制了相应的代码规范，这也对我们阅读起来有极大的方便，虽然有的习惯一时半会无法纠正，但是还是很严格的遵守我们的代码规范。至于代码复审，由于开发迭代周期短，所以并没有进行。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们意识到小组内组员任务分配以及组内人员沟通很重要，刚开始时，对于任务分配模糊不清，导致项目进展很慢。组内人员的沟通时会产生很多分歧，我们也都是逐一分析产生的分歧点在哪，最后选出一个最优解决方案。
如果历史重来一遍，我们会根据每个人的能力更加认真的考虑任务如何分配。还有就是对于用户需求要加深了解，因为用户需求是多样的，而一个产品的设计的好与坏不是开发者随意评判的，而是对适用的使用人群，是否有做过调研，用户想体会的功能，场景，环境是什么？如何去引导用户的使用体会。
如果历史重来一遍，我们会在设计阶段加深对用户需求的了解，使得做出的产品更贴合用户的心理，设计出让用户感兴趣的游戏界面，并且更加重视单元测试，基本完善游戏功能，满足用户需求，并且要严格执行代码规范。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：我们有测试计划，但是因为时间不充分，导致测试不全面。
2.是否进行了正式的验收测试？
答：没有。开发时间占用了大部分时间，还没有来得及做这项工作。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在PC端进行效能测试。从软件实际运行结果来看，这些测试工作很有用，我们可以通过运行结果看出游戏需要改进的地方在哪，同时给我们带来了很大收获，很有效的帮助了我们完善游戏的设计开发。
但是目前我们更多的时间都用在游戏的开发上了，后续我们计划多留出一些时间进行测试。
5.在发布的过程中发现了哪些意外问题？
答：在发布的过程中我们发现游戏选关不灵敏，第一关不反馈错误，真机测试不能通过，没有写好的功能键不能显示在界面上，小程序中不能贴二维码作为客服联系方式等等问题，后来我们通过对代码的测试输出打印，发现问题并解决了问题。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：在测试/发布阶段，我们学到了如何制定一个完整的测试计划，能够保证游戏在正式发布时功能完善，由于开发阶段的时间周期比较长，所以导致测试计划也不是很完善。
如果重来的话，我们会制定一个完整的测试计划，单元测试，效能分析等，来保证我们产品的质量。