作业要求【https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324】
组名:二次元梦之队
组长：刘莹莹
组员：潘世维、周昊、王玉潘、孙韦男、祝玮琦、朱珅莹、赵美增
二次元梦之队小组“I Do”项目
Postmortem结果
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：I Do游戏是一款结合了简单C语言知识的休闲解密益智小游戏；开发团队将产品清晰的定位为休闲益智游戏，而不是学习软件；将产品的用户群体定位为软件和计算机专业的低年级学生或者是对计算机语言有兴趣的非本专业人士或者单纯无聊寻求娱乐的，我们并不期待通过此款软件可以给用户带来丰富的计算机语言知识，只是让本领域的用户巩固知识，让非本领域的用户在使用此款游戏休闲娱乐的同时激发可能存在的对计算机领域的兴趣。
2.是否有充足的时间来做计划?
答：有充足的时间，在项目未进入正式流程之前，我们已经讨论决定了全组大团队在各个阶段要做的内容，需要完成的目标和这个软件需要达到的完善程度；并且根据个人的强项和兴趣点进行了任务的细分，比如潘世维同学负责对代码的整体把控，孙韦男同学主要负责美工的部分等。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：首先在每个阶段的开始之前本阶段需要完成的大目标计划是在其实的一到两次立会讨论决定好的。在每次的每日立会中，是在每日master的主持下讨论今日的任务以及成员所分配任务的进度汇报，包括遇到的困难，遇到个人或者小团队解决不了的困难，会有其他队员提供临时帮助，比如视频制作时的配音工作。
在团队讨论决定时遵循民主的原则，每个人都有权力发表对团队整体工作或他人工作的看法，包括成果是否需要改进，进度是否需要加快等等；当然在决策时，遵循适当的集中制，在团队大方向的问题决策时，实行少数服从多数。
4. 用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：在Alpha阶段发布初始版本以后，我们实现了除本组人员外的9名用户，由于我们的关卡没有实现完整，只实现了预计全部60关的前20关，鉴于软件的完善程度依然需要很多提高，所以这个用户量是可以接受的。我们在设计之初，重视的功能点是剧情走向，但是在用户的使用中更注重的是每关的程序，这与我们的设想有一定差别，分析原因可能是目前用户群体多为本领域内人员。
我们离目标更近了，程序的大体框架已经实现，风格也已成型，后续会继续添加关卡和故事情节。
经验教训就是，前期的调查研究一定要做的更加充分；在目标设定时不仅要对内容上有要求，也需要强调时间的限制，不至于在作业快要截至时才勉强完成，造成影响工作质量的潜在威胁。
如果重来一遍，我们会更加注重前期对于潜在用户的调查研究，找到真正能大幅提高软件质量和用户体验的着力点；其次就是在实际那的把控上也要更加的严格。
计划
1.是否有充足的时间来做计划?
答：是，在一个阶段开始前会有数次站立会议讨论整体目标和具体细节实现以及人员分工。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：是，上一个阶段的任务均已完成，且正计划Beta阶段的任务。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
答：存在，在某些对整体价值不大的微末细节上过多的讨论浪费了一些时间，并且对整体的工作意义甚微。
4. 是否每一项任务都有清楚定义和衡量的交付件?
答：是。在项目开始的时候就已经借助leangoo看板工具对具体的任务进行了明确。并且在每日提交的博文中也有所体现。
5. 是否项目的整个过程都按照计划进行?
答：是，在起始阶段项目的各个目标以及人员的分工已经明确，只要按部就班的完成就可以。当然，在某个人实现的过程中也遇到了一些困难，但是每日立会上成员可以提出自己的困难，会有其他的小组成员予以协助，这也正是团队合作的意义吧，所以在完备的计划和团队的通力合作下，项目的整个过程基本都在按照计划进行。
6. 在计划中有没有留下缓冲区，缓冲区有作用么?
答：没有。缓冲区的作用应该是让尽全力而不能按时完成的任务有所缓冲并且不知于影响其他或者后续工作。
7. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：学习设置缓冲区，使每次作业在提交时不至于太紧张；在各个任务阶段的时间分配上也要更加合理，比如视频和美工需要更多的时间。
8. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：学会了倾听别人的困难和需要的帮助，在组长的协调下根据各人的时间充裕程度和兴趣点相互帮助。如果重来，会更加注重时间的把控。
资源
1.我们有足够的资源来完成各项任务么?
答：资源是有的，但是有时需要大量的时间来收集和学习。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：在任务的分配时，成员选择自己叫熟悉的任务，所以自己会有一个时间诉求，然后经过全体成员的统筹分析讨论确定一个既能让成员完成，又不影响他人和整体进度的时间。精度会根据每天课余时间的多少有所不同，一般精确到天。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：足够
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有，成员的任务分配时根据个人的兴趣和能力进行的，也是充分尊重了个人的选择，任务交换或许也可以完成，但是效果会打折扣。
5.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：资源的手机利用上要投入更多，不要想当然。在资源的使用上，很多资源或许容易找到，但是在使用到项目上是也需要很多的修改会耗费很多的时间，比如视频制作是的特效加入。改进，更加合理的分配人员给此类需要大量时间的工作。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
答：能，每日立会可以很好的进行交流，在其他时间还有微信群随时交流信息。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：根据功能的重要程度和难易程度，如果是关系到后续工作或者其他同学工作的核心功能必须按时实现，以免拖慢整体进度。对于工作量很大但是并不影响其他工作和后续进行的可以适当推迟。这些功能的确定由小组讨论决定。
3.项目的出口条件（Exit Criteria）是否得到清晰的定义?
答：认为是项目实现了预期功能，本项目的预期就是先期实现20关的代码，情节，配图，选关，设置。
5. 对于可能的变更是否能制定应急计划?
答：能，很多任务都是分两人或三人小组进行合作，并且由于良好的平时沟通，彼此间的工作也都较为熟悉，在必要时可以紧急易人完成。
6. 员工是否能够有效地处理意料之外的工作请求？
答：能，首先大家在组内合作，关系融洽愿意江湖救急出手相助，其次大家的工作彼此也有所了解，在能力上也可以胜任。
7. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：良好的团队气氛对于项目的完成是十分重要的，让每个人在团队中都体现自己的价值，得到别人的认可；多多益善的交流，不仅有利于增进成员友谊，更加会增进对彼此工作的了解，在关键时刻可以顶上去，把任务拿下来。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：由本科学习过设计的同学提出构思再由主要负责代码的同学讨论实现的可行性，最后团队讨论确定。在现实的工作中证明，是合适的时间和人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，根据问题的性质，对于涉及到的软件核心问题，会有团队充分讨论后投票决定；对于他人对成员个人任务提出的异议，会充分尊重任务实现者本人的意见，充分讨论，结合最终对于整体的影响程度，据定应本人自行决定修改还是团队投票规定任务方向。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
答：没有，在开发过程中更多的是组内人员不断的试玩来确定改进。
4. 什么功能产生的Bug最多，为什么？
答：在背景图片的插入与屏幕适配上遇到了一些问题，在作图以及适配方式上都做了很多的修改。原因是图片格式不同意以及代码实现者对于适配方式不熟悉。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：因为需要代码的共享，所以开始制定了简单的代码规范，但是在开发进程中难度的增加，大家对规范都进入了置之不理的态度。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：一个好的产品开发并不是多多益善的功能堆积，而是需要在出事阶段进行的整体规划，这样才不至于在开发过程中代码庞大复杂、系统冗余。
如果历史重来遍，我们会在代码的编写上更加注重整体规划和细节的简洁实现。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
答：有测试计划，在项目的进行过程中，全体小组成员都是及时的跟进试用，并提出改进意见，在第一阶段定型后，所有人都进行了完整的对于各个功能的全流程测试。
2. 是否进行了正式的验收测试？
答：是，项目在项目发布后，我们收到了用户提出的很多宝贵意见，会是我们下一阶段努力的方向。
3. 团队是否有测试工具来帮助测试？
答：没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：目前没有进行正式效能测试，但是在开发和组内试用中也发现了一些问题，比如个别题目结果不正确；软件过大，比较占手机内存。
5. 在发布的过程中发现了哪些意外问题？
答：因为是安卓端的应用程序，股东要求在手机上实操，但是展示时准备的时在开发环境的模拟器上展示功能。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：在测试上显然是要花费更多的精力，才能更贴近真实的开发过程，当然还要可行的计划。
在发布展示上，要充分考虑到各位股东的诉求，尽量准备更符合他们习惯的展示手段；在陈述中重讲解功能，重展示，而不是讲解代码。