此作业要求：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2449
组名：杨老师粉丝群
组长：乔静玉
组员：吴奕瑶、公冶令鑫、杨磊、刘欣、刘佳瑞、卢帝同、张宇
杨老师粉丝群“弹球学成语”项目
Postmortem结果
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：项目软件全名是弹球学成语，目的是让用户在PC端上实现边学习边娱乐的功能，通过趣味学习，不仅放松身心，而且学到了成语。打破常规学习成语的死记硬背的方法，通过一种趣味的游戏模式去学习成语，检测成语水平。我们针对的用户主要是中小学生，但是也面向所有人群，因为成语水平参差不齐，只要是有想法去提高成语水平的人，都可以通过我们的软件去学习。
2.是否有充足的时间来做计划?
答：有充足的时间来做计划。我们项目组在开始初期就做了大量的信息调查，通过网络搜集，做问卷调查等方式明确了各个阶段要实现的目标和计划。到目前为止一直按计划进行并没有发生问题。项目组内人员分工明确，每个人都有极高的热情，这对项目的成功有莫大的帮助。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：每周的计划每周定。阶段的计划会在站立会议中讨论。每日的立会我们都会分配每日的任务，对于每日要实现的计划，产生不同的意见就要在站立会议中直接提出，其他成员进行剖析与评价，每个人都可以阐述自己的观点，最终根据组长组织投票来决定最终的实施计划。我们在讨论中相互认知彼此的观点，多方面考虑问题，使我们进步，并且在讨论中我们会产生更好的想法，这种想法最后也被采纳。
4.用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：我们本次项目的Bata阶段实现了两个功能模式的选择，在实现第一版本小球学成语的功能之后，我们新增了成语检测的模式，在这个模式中我们会有两个小球，其中一个包含正确的成语，另一个是错误的成语，我们通过挡板去接住正确的小球获取积分，接到错误的小球或者正确的小球落地就是失败。这个阶段我们找了22名用户进行测试。他们之前通过第一版本学到了一些成语，这样他们进行第二个模式测试的时候，他们都有不错的反馈，很多用户都反应我们的模式设置的很新颖，和传统的弹球游戏相比更具可玩性，同时还可以真正的记住成语，这个确实不错。但是他们也提出了一些问题，就是球不能改变运动轨迹，这样的话会偏离“弹球”的意义。通过总结，总体上Bata阶段功能实现的比较完美，这个结果与初期的设想相比，比较理想。
我们离目标确实更近了，目前已经实现了成语的学习功能和成语的检测功能，后续会继续完善这两个功能。
经验教训是团队开发中要选择大家都比较熟悉的语言，我们这次用python去实现我们的项目，虽然python用起来简单方便，但对于我们来说是一门崭新的语言，需要大量时间去学习这门语言，并且我们组在本科期间编程经历都不是很多，所以大家要花大量时间在项目上下功夫。
在设计方面我们的开发是两个小球垂直落下，选择正确的接住。但是在后期用户测试中很大一部分人感觉这样的垂直而下的运动轨迹违背了“弹球”的意义，所以我们还是从开发者的角度没有站在用户的角度考虑到这个问题，这也是我们没有合格的工程观念，用户至上的理念还是不够强。
如果重来一遍， 我们会更全面的去了解客户的心理，要真正从用户的角度去体验这个产品，而不能通过开发者的角度去评价它的功能。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：原计划的工作我们都已经做完了，并且根据每个阶段的测评我们会更新一些用户比较喜欢的想法，然后去实现这个想法，这是我们原计划所没有的，但是符合我们产品的发展并且合乎用户的要求的。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：我们在做功能二的时候，看了许多python的语法，但多数都要应用模块里的知识，对于软件开发这个阶段的事情，影响的是效率，但还是很好的帮我们阅读代码，写代码。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。我们对于项目的分配非常详细，我们会在会议上通过讨论来确定项目的分配，并在leangoo看板上具体制定了各项任务的负责人、截止时间、任务描述。组员每天都要汇报自己的工作进度，面对问题时我们也积极的通过讨论确定思路，组长负责监督每个人的工作进度。
4.是否项目的整个过程都按照计划进行?
答： 是的，我们把整个项目进行解剖，规划出每个阶段应该做的模块，分配每个人最擅长的方面去克服困难，然后组成项目，最后进行评测。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们的项目预留了缓冲区。因为我们小组是按模块划分任务的，最后要留一个缓冲区测试一下各模块是否都能实现相应的功能，以及对已实现的动能进行讨论修改。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：我们的项目分配情况目前为止我们非常满意，对于项目的分配，我们小组分配的很详细，并且，我们会在会议上通过讨论来确定项目的分配，并在leangoo看板上具体制定了各项任务的负责人、截止时间、任务描述。组员每天都要汇报自己的工作进度，面对问题时我们也积极的通过讨论确定思路，组长负责监督每个人的工作进度。但是对于困难复杂的问题，应该多派些小组人员去克服，有的时候讨论产生的结果大于一个人苦战3小时的结果。
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学到了如何追踪用户的喜好，实时改变应对策略，使项目更加贴近吻合于用户。我们学会了如何在讨论中表达自己的观点，并且根据实际情况，与各方面的考察权重之后提取核心，并且善于聆听观点，表达观点。
如果历史重来一遍的话，我们会更加深度的交流，交流的过程，就是进步的过程。
资源
1.我们有足够的资源来完成各项任务么?
答： 有，网络上有关于Python的教学文档，不会的问题可以在网上查找是否有相应的解决办法。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：任务是根据每个人的能力去分配的，在分配时也给出了时间的度量，时间的把握上首先做这个东西需要对问题的度量（比如需要什么知识，需要新学习什么，需要完成度是多少），对问题估算后会有完成的时间，目前为止我们小组每个阶段的完成任务的情况都很优秀，这也是我们每日互相监督与讨论的成果。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有。我们组在任务分配时就已经根据每个人的长处来最大化发挥自己对团队的贡献，所以每个人做的事情都是自己较为擅长的任务，可以做到很好的互补。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：经验教训是尽早讨论合理的安排各个任务，以确保能更快的投入工作，并且要规定好截止时间。
如果重来一遍的话，在分配任务的时候，要更明确截止时间，让每个人在规定的时间内完成任务，这样更加可以节省时间。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：是的。
每次会议大家都会汇报自己的工作进度，并且晚上会对问题进行讨论。
面对问题时，尽早积极的与大家讨论，每个人在团队都最大化发挥了自身的潜能。
代码方面每位同学在checkin之后会都在微信群里通知大家。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：
一个产品，吸引人的地方往往是它带来的对问题的解决方式，往往体现在它处理用户关心的问题的功能，所以核心功能绝不能推迟，我们如果造一辆汽车，初步想象的不是多么华丽的外壳，而是即使是只有两个轮子，也要让它跑起来。
每周发布的小组成员的任务都是必须实现的，当一项任务可以推迟的话我们会优先完成必须要完成的任务，指的是时间序列，它在这一周是可以推迟的，但下一周它会发布任务变为必须实现，所以具体的划分都是通过发布任务，每周的任务都是必须实现。
3. 项目的出口条件（ExitCriteria）有清晰的定义吗?
我们对于“项目做好了”的定义是：完成了预先设想的三个模式，以及游戏发布之后，使用者可以正常使用，不存在无法运行、显示错误等bug。
4.对于可能的变更是否能制定应急计划?
答：能。根据紧急情况会通过电话的方式紧急通知到各个人，根据任务的紧急情况来确定是开会还是线上讨论，并制定应急措施，这种措施往往都是立即执行的。
5.员工是否能够有效地处理意料之外的工作请求？
答：是的。任务都是根据组内成员不同的长处来分配的，所以大家都会比较熟练，组内的气氛特别融洽。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：永远不要强制别人，一定要换位思考，当一个问题你持自己的观点的时候是否也调查了这个观点在各个人群中的适应情况。
讨论，是一种互相进步升华的过程。
执行力与适应力是影响工作完成进度的标准，这方面的能力一定要训练好。
如果历史重来一遍，我们会更加积极的交流，遇到难题的时候大家讨论，在修改之后一定要及时通知大家，这是对项目的责任。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：本阶段的设计工作在Alpha 阶段第一周就已经讨论出了初始模板，在Beta阶段第一次站立会议时细化了很多规则和细节的处理。由组内成员共同完成。
是合适的时间，是合适的人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，但不多。在设计功能二时，就小球的降落和回弹问题比较模棱两可。我们团队成员经协商一致认为能在技术上比较容易实现的方案才能被选择，最后经功能二开发成员的技术考核之后选定了合适的方案。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有采用上述工具。但是运用了燃尽图以及版本控制等来辅助研发过程。测试的时候是小组内成员通过不断地试玩，提出改进意见的。通过这种方法，发现了很多问题，比较有效。
4.什么功能产生的Bug最多，为什么？
答：功能二测试模式中产生的bug最多。因为涉及的函数最多。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：Beta阶段我们进行了面对面的代码复审。由具体功能的开发者控制流程，讲述编译和修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。
在开发过程中我们严格执行了代码规范。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：程序设计要注重用户体验，当时我们对有些苛刻的用户需求没有太过在意。但是当自己反复功能测试的时候有了体会，流畅美观的界面带给人心里的舒适感的确能够代替一些尚未开发完整的功能带给用户的遗憾。
如果历史重来一次，如果遇到技术实现问题，我们会自己查阅相关文档，在线发帖求助，汇总得到的解决方案，并且试遍所有解决方案。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划。
2.是否进行了正式的验收测试？
答：没有。开发时间占用了大部分时间，只进行了大量的黑盒测试。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在PC端可以进行效能测试。
从软件实际运行情况来看，这些测试工作帮助我们控制代码质量。
我们目前更多的时间放在开发上了，Final阶段计划多留出一些时间进行测试。
5.在发布的过程中发现了哪些意外问题？
答：有了Alpha阶段的经验，Beta发布过程中没有意外问题。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：由于技术层面的原因，我们本阶段的代码设计有些偏离需求，导致发布时功能实现不能尽如人意。我们学到了在开发过程中，无论如何不能舍弃重要细节，要考虑到用户的期待。
如果历史重来，我们会加强QA的力量，以及引入单元测试对代码进行控制。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队的组长是小组成员共同商议决定的，其他人的角色，根据划分的任务，每个人选择自己擅长的范畴，可以做到人尽其才。2. 团队成员之间有互相帮助么？
团队之间存在很多互相帮助。3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
如果出现问题，大家会在每天的站立会议上，及时反映并进行讨论，共同相处解决方法。4.每个成员明确公开地表示对成员帮助的感谢，链接整理如下：
乔静玉：https://www.cnblogs.com/qjy0330/p/10068442.html
吴奕瑶：https://www.cnblogs.com/wuyiyao694/p/10068336.html
公冶令鑫：https://www.cnblogs.com/gongylx/p/10068374.html
杨磊：https://www.cnblogs.com/yangl794/p/10068390.html
刘欣：https://www.cnblogs.com/liu-xin1995/p/10068393.html
刘佳瑞：https://www.cnblogs.com/Ljr6899/p/10068334.html
卢帝同：https://www.cnblogs.com/luditong/p/10068998.html
张宇：https://www.cnblogs.com/zy1122/p/10068359.html
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI二级，建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
大家更加能够明确自己要完成的任务，以及能更高质量的完成。4.你觉得目前最需要改进的一个方面是什么?
开发过程还需要进一步规范化。5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
原则四、六：业务人员和开发人员在项目开发过程中应该每天共同工作；进行面对面的交流：我们每天都要开一次站立会议，方便团队成员及时交流遇到的问题并尽快解决原则七：可用的软件是衡量项目进展的主要指标；我们在每一个阶段，都能发布可运行的项目，并且功能会在前一阶段进行更新。
博客要附上全组讨论照片
