项目回顾
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：我们的软件要解决俄罗斯方块游戏玩法老旧的问题；定义的很清楚；有清晰描述；
2.是否有充足的时间来做计划？
答：有，小组员都经历过很多次会议；
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：有少量不同意见，经过几次会议后达成一致；基本一致；离目标更近了；我获得的经验教训是：做事情要分轻重缓急，先将主要目标完成之后，才是考虑次要目标的时候；如果历史重来一遍，我会做好计划，优先完成项目的重要功能，其次再花时间做包装。
计划
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：主要任务全部完成，次要任务因为BUG问题没有完成；本人代码能力不强，需要花很多时间学习修复BUG；
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：有；耗费一周时间写完的次要任务被发现与主要任务产生“不良反应”。最后开会决定删除次要任务，保留主要任务。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：没有
4.是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?
答：否，从开发进程上看是有按照计划进行的，只是时间大多延后了；我们没有估计到组员变动的风险，因为事情来得太过突然，又是第一次学习本课程。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
答：有，如果在计划时间之内没有完成任务，就全员开会决定下一步该如何决定，共同商讨功能的去留问题。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答： 应该明确缓冲区的长度，空出一段时间；我学到的经验是：在开发过程中不会一帆风顺，要留下足够的时间处理“意外”；如果历史重来，我们会提早考虑人员的变动问题；
资源
-
我们有足够的资源来完成各项任务么?
答：有，我们早就做好充足准备；
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答： 估算的很精细，但是不够准确；
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：足够；没有低估难度，目前还没有将重心移到美工设计上。
4.你有没有感到你做的事情可以让别人来做（更有效率）? 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：没有；经验教训是“书到用时方恨少”，应该多加强自身能力；提前做好时间规划；
变更管理
-
每个相关的员工都及时知道了变更的消息?
答：对，我们有专用的通知群，每个组员都能第一时间获得信息。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：采用线下会议为主，线上会议为辅的方式，有困难有问题，大家一起商讨解决。让每一位组员都知道问题的所在和任务的进度。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：有。
4.对于可能的变更是否能制定应急计划?
答：是，线上会议可以马上召集大家开会，并制定出新的计划。
5.员工是否能够有效地处理意料之外的工作请求？我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答： 部分可行；意外随时都会发生，要做好每一步的规划；应该学会寻求他人帮助，而不是低效率的攻克难题。
设计 实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作在确定项目的第一周开始，由全员开会决定；是合适的时间也是合适的人；
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，在设计俄罗斯方块游戏时，我们无法确定新玩法是以增加难度为主旨，还是以增加休闲性为主旨；最终通过全员开会并寻求老师的帮助，得到一个令大家都满意的答案；
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
答：没有
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：黑幕功能的Bug最多，因为没有加载相应的java包和配置文件；在小组员发生变化以后，交接做得不够顺利导致项目有一定程度损坏。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：我们会对涉及主要功能的代码 进行注释，方便别人阅读理解。
测试 发布
-
团队是否有一个测试计划？为什么没有？
答：有
2.是否进行了正式的验收测试？
答：我们通过自己电脑进行测试。
3.团队是否有测试工具来帮助测试？
答：没有，俄罗斯方块游戏不需要专门的测试工具
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：我们的游戏还没有到达最终版本，所以没有进行大规模的测试。
5.在发布的过程中发现了哪些意外问题？我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答： 我们在游戏发布前已经做过详细的测试，所以在发布的过程中没有发生意外。
总结:
-
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
-
答：CMM
-
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
-
答：规范。组员们分工明确，互相帮助，已经度过磨合期很久。
-
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
-
答：这就是我们的第一个里程碑。
-
你觉得目前最需要改进的一个方面是什么?
-
答：增强自身代码能力。
