作业要求参见：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2449
组名：二次元梦之队
组长：刘莹莹
组员：潘世维、周昊、王玉潘、孙韦男、祝玮琦、范靖旋、赵美增
二次元梦之队小组“I Do”项目
Beta阶段Postmortem结果
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
首先，我们的游戏是针对于对C语言有兴趣的同学朋友，在自己无聊的时候进行试玩，发觉自己的兴趣。为了增加游戏的趣味性，我们加入了丰富多彩的图片、背景故事和有序延展的故事情节，不是乏味的知识学习，只是无聊时的休闲游戏，期待给予玩家放松，也期待主线故事带来喧闹世界中的一点温馨和静谧。通过小熊仔i的一生展现我们大多数人可能也在经历的这样的一生，向大家传达这样一种价值观——人间值得！
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基于这样的想法，我们辛勤工作了大半个学期经历了两次发布，虽然还是漏洞百出，但是诚意之作也是初见其形。在上一阶段的发布进行后，我们通过自己内部成员的试玩和外部用户的反馈对界面进行了大幅改进，抛弃了原先黑色为主的主题设计，采用更加活泼明快的浅色背景。在背景音乐的选择上保留了原先的设计，积极向上的女声音乐。当然还有很多的部分没有完成，比如，原先设计实现的60关，目前为止还是实现了之前的20关，开始没有预计到创作需要如此多的灵感啊。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
技术上，由于经过了上一个阶段的开发，安卓开发工具的使用已经比较熟悉了。最大的困难就是素材的选取和修改了，故事的编辑和图片的制作着实费了不少功夫。在功能上，将音量的大小调节集成到了手机系统的音量调节上，并且增加了四个界面的背景音的开关按钮，选择更加自主。保留了清除数据按钮，让有兴趣的用户可以重新开始。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
目前的用户还是较少，没有达到预期目标；经过本阶段的改进，界面更加友好，题目更加多元化，基本实现了预期，离目标更加接近。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在目标设定时不仅要对内容上有要求，也需要强调时间的限制，不至于在作业快要截至时才勉强完成，造成影响工作质量的潜在威胁。
如果重来一遍，我们会更加注重前期对于潜在用户的调查研究，找到真正能大幅提高软件质量和用户体验的着力点；其次就是在实际那的把控上也要更加的严格。
在接下来要更加注重故事情节的完善。
计划
1. 是否有充足的时间来做计划?
有充足的时间，在项目未进入正式流程之前，我们已经讨论决定了全组大团队在各个阶段要做的内容，需要完成的目标和这个软件需要达到的完善程度；并且根据个人的强项和兴趣点进行了任务的细分。结合上一个阶段的经验，这一次的任务划分更加的合理和符合每个同学自己的兴趣和长处了。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在每个阶段的开始之前本阶段需要完成的大目标计划是在其实的一到两次立会讨论决定好的。在每日立会中，讨论今日的任务以及成员所分配任务的进度汇报，包括遇到的困难。在充分讨论的基础之上，进行人员和任务的微调，当然尽量避免出现争端、不满。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
上一个阶段计划的关卡数没有完成，原因是错误估计了故事创作的难度。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，经过上一阶段的经验，本次大家的讨论都是比较切合实际的，进本没有什么无用功。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是，每日的任务都已经在计划中明确，且都体现在leangoo看板工具和每日立会的报告里。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目基本是按照计划进行，意外就是故事没有添加完整，抱着宁缺勿滥的态度，没有将半成品添加进去。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
答：有，总结上次的教训设置了缓冲区，但是本次未有作用。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：将任务划分的更加合理，避免有成员太累；在测试上投入更加多的时间，避免出现显而易见的错误。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：将任务划分更加细致，在测试上投入更多。
资源
1. 我们有足够的资源来完成各项任务么?
答：资源是有的，但是将资源化成自己可用的部分所进行的修改花费了不少时间。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
在起初任务的分配时，就充分尊重个人意愿且结合上阶段的经验教训。设置一个最终时间，在此之前完成即可，精确到天。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：测试的 资源是够的，但是我们小视了测试的重要性和文案的难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有，基本做到了人尽其责，物尽其用。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：在测试和文案上投入更多的资源。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
答：能，每日立会的交流和微信群的沟通都比较顺畅。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：根据功能的重要程度和难易程度，如果是关系到后续工作或者其他同学工作的核心功能必须按时实现，以免拖慢整体进度。对于工作量很大但是并不影响其他工作和后续进行的可以适当推迟。这些功能的确定由小组讨论决定。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：以完成预期的设计预想为目标，完成了就是做好了，核心功能的完善是关键。
4. 对于可能的变更是否能制定应急计划?
答：能，很多任务都是分两人或三人小组进行合作，并且由于良好的平时沟通，彼此间的工作也都较为熟悉，在必要时可以紧急易人完成。
5. 员工是否能够有效地处理意料之外的工作请求？
答：能，首先大家在组内合作，关系融洽愿意江湖救急出手相助，其次大家的工作彼此也有所了解，由于大部分的工作难度并不是特别的大，在能力上也可以胜任。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：合理的任务分配和配套的资源投入才会是变更管理有意义，如果前期漏洞太多，后期挽回也还是会造成一些损失。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：经过上一阶段的开发，大家都渐渐进入正轨，所以本阶段的设计目标是大家结合上阶段教训和用户反馈合作讨论完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，和尚阶段一样，根据问题的性质，对于涉及到的软件核心问题，会有团队充分讨论后投票决定；对于他人对成员个人任务提出的异议，会充分尊重任务实现者本人的意见，充分讨论，结合最终对于整体的影响程度，据定应本人自行决定修改还是团队投票规定任务方向。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
答：没有应用专业的软件工程方法来进行测试，大部分测试时开发者在编写时的预览效果和后期的试玩完成测试。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：题目上出现了一些错误，影响了用户的体验，由于软件的图片较多，所以还出现了软件过大的问题。关于软件过大的问题，起先也意识到了，只是没有找到很好的解决办法。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：代码的复审和规范是编写者的自我监督，希望在实现功能后，代码也能写得更加漂亮，实际操作中也没有过多的要求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：学会了代码规范，接下来在代码的规范控制上要做的更多。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
答：有，主要进行的就是用户的使用和程序员的自我修正，由于项目规模不大时间较短所以没有制定特别周密的测试计划。
2.是否进行了正式的验收测试？
答：是，我们内部成员自己的测试和找到的用户的测试都进行了试用，基本实现预期的核心功能。
3.团队是否有测试工具来帮助测试？
答：没有
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：目前没有进行正规的效能测试，不过根据用户的使用来看，占用内存过大的问题依然存在。
5. 在发布的过程中发现了哪些意外问题？
答：没有预想到老师和同学会提出要求试玩，所以临时没有准备相应的链接供下载。不过课后及时提供了百度云链接下载。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：对题目的把控更加严格一点，提前一点完成，留出充足的时间来做测试。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
答：在任务分配时就是根据个人的意愿和特长进行分配的，所以进本做到了。
2. 团队成员之间有互相帮助么？
答：有，当有团队成员遇到问题解决不了的时候或者是有任务完成不了的时候都会在立会或者是微信群里及时的提出，再去协调更多的资源去完成任务。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
答：及时提出，详尽讨论，民主决定。
每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）：
刘莹莹：https://www.cnblogs.com/liuyy0817/p/10066134.html
孙韦男：https://www.cnblogs.com/swn321/p/10066056.html
赵美增：https://www.cnblogs.com/zhaomz853/p/10066330.html
范靖旋：https://www.cnblogs.com/fjingxuan/p/10066554.html
祝玮琦：https://www.cnblogs.com/zwqhh/p/10066023.html
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：团队的合作在任务分配时只是开始，相互帮助的解决问题才是根本的目的，允许有人落后，有人没有完成自己的任务，但是不允许团队里不尊重其它团队的成员努力，渺视他人的帮助。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：CMMI二级，有明确的任务分工，不会因为一些随机因素导致任务失败。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：产品的成熟度更好了，每日立会的效率更高了。
你觉得目前最需要改进的一个方面是什么?
答：开发过程的规范化程度需要提高。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
答：第四条，递增的变化，在设计初期我们的预期就是先以最初的20关为范例，以后的关卡以此来添加细节。
第九条，快速反馈，因为项目开始的时候老师就给了一些辅助开发的要求，例如看板，团队内部也有微信群的及时交流，所以认为相应的反馈做的比较好。
附上全组讨论的照片
