此作业要求：[https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324]
组名：杨老师粉丝群
组长：乔静玉
组员：吴奕瑶、公冶令鑫、杨磊、杨金铭、刘佳瑞、卢帝同、张宇
杨老师粉丝群“弹球学成语”项目
Postmortem结果
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：首先我们的软件的名字叫弹球学成语，顾名思义，是基于PC端关于成语学习的一款趣味学习软件。这款软件所提倡的就是趣味游戏与学习知识相结合，打破传统的，枯燥的死记硬背的模式，构建一种全新的趣味学习模式，玩中有乐，乐中有玩。我们针对的用户主要是但不仅限于中小学生，这款软件所解决的问题是提高那些有兴趣学习成语的人的成语掌握程度，并且期望以此提高对中国传统文化的理解。
2.是否有充足的时间来做计划?
答：有充足的时间，我们的小组从确定选题之前就已经开展了对这个项目的分析与调研，并在确定选题之后小组讨论定义了典型场景、游戏各个关卡等内容，并且初步把整个项目分配为各个功能模块，分工明确，团队的每个人有各自擅长的强项，每个人对于项目的贡献都为之重要，我们团结一心会把项目做的更好。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：首先一周的计划是事先确定好的，在每日的立会中我们会把事先分配好当日的任务进行讨论，并且对于计划，每个人都可以表达自己的观点，对于一个即将确定的计划，每个人必须都要有观点表达，每个人都要表达出自己对于这个问题的意见与想法，然后我们通过讨论来加深每个人心中确定的观点，最后通过组长组织投票来确定问题的最终方案。我们在讨论中相互认知彼此的观点，多方面考虑问题，使我们进步，并且在讨论中我们会产生更好的想法，这种想法最后也被采纳。
4.用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：我们本次项目的Alpha阶段实现了小球在与挡板结合会跳转成语的功能，它也是我们产品的重要功能之一，是我们产品的学习模式，因为它不需要你的识别，你只需要去接小球。我们的产品在Alpha阶段共有30名用户，他们通过使用我们的产品掌握了一些成语，并给我们项目组提出了宝贵的意见，比如球比较大，成语的难易程度等，这些意见也使我们的产品更进一步，通过与用户的交流，我们可以及时的改善用户的需求，用户对于我们这个产品很看好，对当前的功能也很满意，并且期待我们的检验功能。这个结果与初期的设想相比，也比较理想。
我们离目标确实更近了，目前已经实现了成语的学习功能，后续会继续完善并开发成语检验功能。
经验教训是团队开发中要选择大家都比较熟悉的语言，我们这次用python去实现我们的项目，虽然python用起来简单方便，但对于我们来说是一门崭新的语言，需要大量时间去学习这门语言，并且我们组在本科期间编程经历都不是很多，所以大家要花大量时间在项目上下功夫。
在设计方面球体的体型偏大，导致游戏难度降低，我们初始觉得这样做是为了方便用户能更清晰的学习成语，但大多数玩家追求的是游戏难度，这也是我们在产品的开发中忽略的地方。
如果重来一遍， 我们会更全面的去了解客户的心理，并且在学习python的时候我们走了很多弯路，抠得太细，我们系统的学习这门语音而不是对于工程来说用到什么去学什么。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：原计划的工作已经完成，并且我们已经做了部分Beta阶段的工作。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：没有，所有做的事情对于项目都很有意义，也在我们的项目开发中经得起检验。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。我们对于项目的分配非常详细，我们会在会议上通过讨论来确定项目的分配，并在leangoo看板上具体制定了各项任务的负责人、截止时间、任务描述。组员每天都要汇报自己的工作进度，面对问题时我们也积极的通过讨论确定思路，组长负责监督每个人的工作进度。
4.是否项目的整个过程都按照计划进行?
答： 是的，我们通过对于问题的解剖，把项目分为各个模块，每个人去完成相应的模块，我们的计划不变，到目前为止也完成的很好。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们的项目预留了缓冲区。因为我们小组是按模块划分任务的，最后要留一个缓冲区测试一下各模块是否都能实现相应的功能，以及对已实现的动能进行讨论修改。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：每周的任务是看我们的完成情况制定的，在分配上也比较合理，将来的计划有可能会变动，比如比较困难的模块要多分配组员进来共同克服去解决，并且要多安排测试阶段的时间，预先对问题进行自我检测。
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了如何采纳别人的观点，正视别人的观点，如何在讨论中总结问题的核心，学会了人员和按照颗粒度分析任务，学会了如何根据组员能力划分相应擅长的任务。
资源
1.我们有足够的资源来完成各项任务么?
答： 网络上有关于Python的教学文档，从整体上讲，资源比较丰富。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：任务是根据每个人的能力去分配的，在分配时也给出了时间的度量，时间的把握上首先做这个东西需要对问题的度量（比如需要什么知识，需要新学习什么，需要完成度是多少），对问题估算后会有完成的时间，目前为止我们小组每个阶段的完成任务的情况都优秀，这也是我们每日互相监督与讨论的成果。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有。我们组在任务分配时就已经根据每个人的长处来最大化发挥自己对团队的贡献，所以每个人做的事情都是自己较为擅长的任务。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：经验教训是尽早讨论合理的安排各个任务，以确保能更快的投入工作，并且在自己绞尽脑汁之时要多于小组沟通，大家会根据问题讨论出办法，这也是团队的力量。
如果重来一遍的话在Alpha阶段开始前就应该对于问题进行分割，并且迅速分配各个任务，在开始之前一定要多沟通，了解每个人的优点，尽早的投入项目的研发。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：是的。
每次会议大家都会汇报自己的工作进度，并且晚上会对问题进行讨论。
面对问题时，尽早积极的与大家讨论，每个人在团多都最大化发挥自身的潜能。
代码方面每位同学在checkin之后会都在微信群里通知大家。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：
一个产品，吸引人的地方往往是它带来的对问题的解决方式，往往体现在它处理用户关心的问题的功能，所以核心功能绝不能推迟，我们如果造一辆汽车，初步想象的不是多么华丽的外壳，而是即使是只有两个轮子，也要让它跑起来。
每周发布的小组成员的任务都是必须实现的，当一项任务可以推迟的话我们会优先完成必须要完成的任务，指的是时间序列，它在这一周是可以推迟的，但下一周它会发布任务变为必须实现，所以具体的划分都是通过发布任务，每周的任务都是必须实现。
3. 项目的出口条件（ExitCriteria）有清晰的定义吗?
我们对于“项目做好了”的定义是：完成了预先设想的三个模式，以及游戏发布之后，使用者可以正常使用，不存在无法运行、显示错误等bug。
4.对于可能的变更是否能制定应急计划?
答：能。根据紧急情况会通过电话的方式紧急通知到各个人，根据任务的紧急情况来确定是开会还是线上讨论，并制定应急措施，这种措施往往都是立即执行的。
5.员工是否能够有效地处理意料之外的工作请求？
答：是的。任务都是根据组内成员不同的长处来分配的，所以大家都会比较熟练，组内的气氛特别融洽。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：永远不要强制别人，一定要换位思考，当一个问题你持自己的观点的时候是否也调查了这个观点在各个人群中的适应情况。
讨论，是一种互相进步升华的过程。
执行力与适应力是影响工作完成进度的标准，这方面的能力一定要训练好。
如果历史重来一遍，我们会更加积极的交流，遇到难题的时候大家讨论，在修改之后一定要及时通知大家，这是对项目的责任。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：在设计方面，因为针对于小学生的产品，所以UI更倾向于卡通，炫酷的风格，这个任务的分配首先要了解组员的设计方面的经历，然后根据能力去分配适合的人物，结果也比较理想。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，但不多。在功能方面上初于对技术上的把握与游戏性能的平衡，我们对游戏模式的犹豫不决，无法确切的确定怎么最大化的影响用户，通过对市场的调研与演练，并且团队的讨论，投票，最终确定了合理的产品方向。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有采用上述工具。但是运用了燃尽图以及版本控制等来辅助研发过程。测试的时候是小组内成员通过不断地试玩，提出改进意见的。通过这种方法，发现了很多问题，比较有效。
4.什么功能产生的Bug最多，为什么？
答：就目前来说，弹球学成语项目中练习模式的小球回弹的角度存在差异，我们在定义时的函数存在了一个问题，后来经过测试与更改修改了这个Bug。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：项目刚开始我们确定了语言，并且按照这个语言的特点定制了相应的代码规范，这也对我们阅读起来有极大的方便，虽然有的习惯一时半会无法纠正，但是还是很严格的遵守我们的代码规范。
至于代码复审，由于开发迭代周期短，所以并没有进行。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：产品的设计上不是你觉得好就是好，而是适配对应的使用人群，是否有做过调研，用户想体会的功能，场景，环境是什么？如何去引导用户的使用体会。
一个产品的迭代周期需要一个可持续的兼容框架，产品的设计需要可行性，可靠性。
如果重来一遍，我们会在设计的阶段更贴合用户的心理，并且更加重视单元测试，严格的执行代码规范。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划，但是因为时间不够充分，所以测试不全面。
2.是否进行了正式的验收测试？
答：没有。开发时间占用了大部分时间，还没有来得及做这项工作。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在PC端可以进行效能测试。从软件实际运行情况来看，这些测试工作给我们带来了很多收获，帮助我们改进完善软件。但是目前更多的时间放在开发上了，后续计划多留出一些时间进行测试。
5.在发布的过程中发现了哪些意外问题？
答：在发布的过程中我们在打包的时候遇到了很大的问题，当程序执行时就会出现闪退的场景，后来我们通过对代码的测试输出打印，发现问题并解决了问题。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：经验是要事先确定好一个完整的测试计划，这样产品的正式发布才会更完善，由于开发阶段的时间周期比较长，所以导致测试计划也不是很完善。
如果重来的话，我们会制定一个完整的测试计划，单元测试，效能分析等，来保证我们产品的质量。