一.设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件就是拿来娱乐休闲解闷的，能够在空闲时间玩一玩打发时间就好。定义的还是比较清楚的，也一直在往这方面努力。因为是小游戏，所以一直都有在往“方便”这方面改进，也感谢同学和老师的建议，我们有准备改进操作界面里面的麻烦操作。在需求分析中有对典型场景与典型用户有清晰的描述。
2.是否有充足的时间来做计划?
时间也就还行吧，最主要的是还是很会规划时间，导致时间都浪费了很多。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
有意见都会先收集起来，在每天的立会上会统一解决，把控好项目的方向。
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
目前版本阶段的用户极少，在小范围内传播。接受度倒是还行，有在事先的预想范围内，收到很多需要改进的反馈。距离目标是越靠近了。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
时间规划！大家总是没能找到很好的方法来规划时间做项目，虽然Alpha阶段也做完了，但是还是感觉有些遗憾，本来可以做得更好的，不过大家都有拖延症，再加上时间利用不高，导致时间浪费了很多。希望这一点能到β阶段有改进。
二、计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
计划内的任务基本完成，功能都有尽量完善，需要改进的部分，在β阶段内加以实现。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
有！就是同学们反应过的，背景颜色，我们发现那个功能其实加了也没多大意义，玩个俄罗斯方块谁还管你背景颜色自定义，一般来说，只要是舒服一点的颜色就没人管了，实在没必要专门给了功能设置背景颜色。实际上里面还有什么消除行时的颜色自定义也要去，网络格自定义也要去。我们计划好了，下个版本要变的更加简洁，看起来舒服。
3.是否每一项任务都有清楚定义和衡量的交付件?
基本都有，毕竟是java编写的，按方法，接口什么的来还是定义的很清楚的，一开始就已经规划好了，哪些功能有哪些类，类里面又该有哪些类，类之间的关系什么的，java就是这点好，很严谨。
4.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
一开始其实就出了意外，没有想到任务其实比想象的多，导致最开始几天是没有按计划完成的，后面几天加班加点才回到计划内。最主要的风险还是前面提到的时间规划，一开始没想到的，是因为以前都是自己做习惯了，每个人都有自己的时间安排，导致做项目的时间没有统一好，规划出现问题。慢慢磨合，才勉强能赶上进度。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
基本没什么缓冲区，每天组员能给出的时间也就刚刚好赶上计划。如果有缓冲区的话，大家估计就能更轻松了，不用每天急急忙忙赶进度了。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划基本不会怎么修改，因为比较清楚组员，就算本来有时间缓冲，最后也一定是刚好赶上。。。。加班是一定的。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
至少了解到了团队合作的不容易，好的团队需要大家一起努力才能实现。如果历史重来，希望大家都能更走心，不要拖，不要拖，不要拖。
三.资源
1. 我们有足够的资源来完成各项任务么?
资源的话不能说非常多，但是也基本上足够，大家五个人一起在做中学。虽然编程基础都没有特别好，但是在不断学习并且一起去朝着这个目标前进，也大体上完成了各项任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
主要还是按照先前alpha阶段开始之前大家协商好的时间段以及每日任务来进行的。精度基本上是比较准备，近乎是按照计划进行
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时人力还是比较足够的，美工设计/文案方面并没有去低估难度，毕竟这关系到用户体验啊。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
如果是技术方面的事情的话，编程技术强的人来做是肯定是会更有效率的，但是毕竟大家是一个团队。每个人都贡献出自己的一份力量，毕竟一个专业也就只有一个李嘉廉不是吗？
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训的话最明显的就是在做的过程中感受到了编程水平的不足，如果历史重来一遍我们肯定是要从大一开始就打好编程的基础，这样在后期的学习和工作中也不会那么辛苦了。
四.变更管理
1. 每个相关的成员都及时知道了变更的消息?
我们团队一共五个人，分别在两个宿舍，交流起来十分方便，并且建立了qq群，重要的事物都会在qq群上通知。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
推迟的功能主要是不影响使用的功能，那些锦上添花的功能，例如增加难度、设置排行榜等。必须实现的是实现游戏的正常运行，并且可以持续的玩下去。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们的定义就是能够顺畅的脱离Java平台玩这款游戏，并且不会轻易出现bug。
4. 对于可能的变更是否能制定应急计划?
我们对每个阶段都有一个备份，如果有必要的话，可以找到不同阶段的备份进行重新构建，但时间很可能不允许，还是要视情况而定。
5. 成员是否能够有效地处理意料之外的任务请求？
这实现起来还是比较困难，都说术业有专攻，我们小组成员也是根据自身情况制定的任务，要是收到意料之外的任务请求就会耗费很多额外的时间，总之如果没有特殊情况，是尽量避免的。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到的是如何更好的协调小组内的工作，一开始规划比较混乱，导致效率很低，如果重来一次，我们会仔细考虑分配的任务，尽可能的提高小组的工作效率。
五.设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
原型的设计一开始是由陈文俊和刘阳航两位同学设计的，一开始使我们大家一起讨论的，具体部分由他们两位同学设计出来。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有的，在一开始的设计中，我们有一些不是很必要的游戏功能，比如给俄罗斯方块染色这种，没有特别重要的作用，但是我们还是想让游戏功能更多一点。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没有，在冲刺阶段，每个人的任务都安排的很慢，先前计划中没有规划好要进行单元测试，我们学习进度也没有那么快，就没有用上单元测试。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在消除整行出现bug，因为消除完忘记讲所有行向下移动，发布之后出现的bug是随机生成障碍物时输入的数字没有上限，会超出去。一开始设计时没有想到会输出这么大数字的障碍物。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们按照代码审查清单来审查自己的代码，代码能够工作么，它有没有实现预期的功能，逻辑是否正确等。基本符合了代码规范。我们还检查了，是否存在多余的或是重复的代码，代码是否尽可能的模块化，是否有可以被替换的全局变量，是否有被注释掉的代码，循环是否设置了长度和正确的终止条件等等。
六.测试/发布
1. 团队是否有一个测试计划？
a阶段，团队在初期就开始逐步进行测试，从简单数据结构测试，边缘测试到最后试玩游戏，在b阶段会进行更加详细的测试并对软件进行完善。
软件测试(software testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是:在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
2. 是否进行了正式的验收测试？
还没有进行正式的验收测试，这将在b阶段开始进行
3. 团队是否有测试工具来帮助测试？
初步使用loadrunner进行测试
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
对于loadrunner的使用仍然不够熟练，无法从其运行结构分析出结构并对我们的软件进行优化，这些工作是有用的，只是我们水平不够，需要多加学习。
5. 在发布的过程中发现了哪些意外问题？
开始的时候，我们甚至不知道如何发布，在百度搜索了教程之后，学会了如何将.java文件封装成.exe文件
七、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得我们团队仍处于可重复级，这个阶段的评价标准是：“管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。”虽然侥幸完成工作并且成功发布，但是这其中很多请教了百度以及身边的大佬同学，可能存在着一些我们这些菜鸟测试都测试不出来的bug，希望在b阶段此能够进行改进，争取达到优化级。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
团队仍处于磨合阶段，部分队员对于团队工作仍存在积极性不高的问题。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
从对小游戏编程一无所知到成功发布小游戏，我觉得每个团员的付出都是有目共睹的，每个人也确确实实从中学到了东西。
4.你觉得目前最需要改进的一个方面是什么?
界面问题！界面很丑！然后就是需要对软件进行详细的测试。
八、团队会议照片
九、成员贡献
| 排序 | 姓名 | 可验证贡献 | 团队贡献分 |
|---|---|---|---|
| 1 | 刘阳航 | 编写俄罗斯方块游戏中的各个类的主体框架性代码 | 28 |
| 2 | 陈文俊 | Controler类与实现图形定时下落的事件监听 | 25 |
| 3 | 林庭亦 | 对各个类进行测试、图形定时下落 | 20 |
| 4 | 郑子熙 | 游戏结束的功能、图形数据结构 | 14 |
| 5 | 丁树乐 | 障碍物的消除、显示 | 13 |