Beta阶段项目终审报告
先上图
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是用来解决玩狼人杀这款桌游时无牌、无法官、游戏流程不熟悉等情况的。我觉得我们对典型用户和典型场景描述的较为清楚，我们项目之前做了问卷调查，提出了一些功能，Alpha版本挑了用户较需要的几个功能重点实现，在Beta阶段我们也继续完善其余功能，增加了重置密码，查找好友等功能，并修复了前期的bug，同时优化了UI。
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
很遗憾，我们努力达成了大部分目标，但是仍然有目标没有达成
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
很遗憾没能上线。。我们当然是离目标更近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训是把精力都花在最主要的方面。
如果历史重来一遍，我们应该会努力让它上线
计划
-
是否有充足的时间来做计划?
有
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
大家意见很统一
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
有，因为不知道老师们都很默契地把所有大作业和考试都挤在那两周
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有
-
是否每一项任务都有清楚定义和衡量的交付件?
是
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
呃，后期有点崩坏，因为没什么时间以及越深入发现需要完善的东西越多
-
在计划中有没有留下缓冲区，缓冲区有作用么?
有
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
留下充足缓冲区。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
呃，联名要求学校下个学期再开这门课
资源
-
我们有足够的资源来完成各项任务么？
- 人力资源上：只有四个人，任务完成起来难度较大。
- 开发资源：很多技术文档都是英文，也有很多在网上根本查不到，需要自己摸索。为了改两个玄学bug，我们甚至修改了react native库源代码。
- 设备资源：设备还是比较紧缺，另外就算有了设备，一个测试人员也很难同时正确操控多个设备。
- 时间资源：这半个学期是上大学以来最忙的，时间比较紧。
-
各项任务所需的时间和其他资源是如何估计的，精度如何？
同样是根据任务量估计的，但Beta阶段的估计精度比之前好了很多，主要是因为对项目的理解程度加深了，估计得更准确了。
-
测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
前面也已经提到了，各种资源都是不太够得，其中最缺的还是人力资源。
在Beta阶段，由于美工和设计都已经成型，没有太大改动，所以这方面没有什么感觉。
-
你有没有感觉你做的事情可以让别人来做（更有效率）？
测试和开发可能需要分工更明确一点，有时候边测试边调bug感觉效率很低。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
多争取一些人力资源，分工更加明确。
变更管理
-
每个相关的员工都及时知道了变更的消息？
是的。每位成员更新代码后，都会上传至Github，并且在微信群通知大家；每位成员测试时发现接口文档有问题，都会及时更新并告知大家。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能？
从两方面考虑，一是需求，二是实现难度。用户需求高的功能和基础功能是“必须实现的”，用户不那么需求的和实现难度大的功能可以适当推迟。
-
项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
有。
- APP无崩溃、闪退等现象。
- 测试发现的Bug得到修复。
- 典型用户场景得到测试并无bug。
- 测试矩阵中的典型情况得到测试并无bug。
-
对于可能的变更是否能指定应急计划？
可以。比如发现了一个无法解决的bug，我们可以在github上回退至上一个正确的版本，再仔细寻找问题所在。
-
员工是否能有效地处理意料之外的工作请求？
可以。比如我们写完一个页面，准备提交成果之前，想花几分钟调一下页面的bug，但是往往调bug的时间超过了写页面的时间。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
越早开始越好。早些定义好基础功能，大家以这个为目标先努力做好，之后再加一些锦上添花的功能。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在Beta阶段开始的时候，我们一起商议了接下来等待完成的各个工作。对于新增接口，大家一起商定，由前后端人员分别实现。前端的美化由石浩然去完成，图片、声音和图标等素材由陈彦吉完成。测试则有韩青长先进行，其他人完成各自工作后进行辅助。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，比如对于某些新功能是否需要的问题，大家的意见不一致，我们的解决方法是先记录下来，如果最后有时间再去完成。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没有，我们这是一个游戏助手APP，不能简单的通过这些代码测试工具进行测试，需要使用设备来测试。而且使用设备更方便，同时能够找到前后端两边的问题，感觉在我们这种情况下，直接用手机测可能效率更高点。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
退出功能。因为退出功能会涉及到一系列数据的删除，如果少删或多删都有可能出问题，而且有些数据可能在之前就已经删掉了，所以也要加以判断。
当时写的时候主要关心的是实现这些功能，而对于这一个功能对其他部分的影响没有做全面的考虑。 -
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有，因为人手和时间不够。代码复审是由各自的编写者从头到尾进行重新审读的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在一开始做之前要充分商讨要做什么？怎么做？谁去做？不然到后面很可能就会被遗忘或者互相推诿掉。
开始做之后最好能写个纸面上的思路，并不需要太正规，可以当成是一个随笔。把思路写在在纸面上一定会比你直接用脑子去记要能够发现更多的问题，也能够想到更多的方法。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有，测试计划与之前类似，不过因为是Beta阶段，之前测过的没有改动或影响的接口可以暂时不测。
-
是否进行了正式的验收测试？
没有，因为时间比较赶只是将流程跑了一下看有没有什么问题。
-
团队是否有测试工具来帮助测试？
没有，采用的是人工测试。
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的效能主要是指并发性和压力测试，这一点由于设备和人力原因并没有测试。我们只是使用几台机器进行测试，效果还可以。
-
在发布的过程中发现了哪些意外问题？
服务器不稳定，可能会死机，正常运行时也有可能会被暂停，得人工重启，而这时之前正在进行游戏的玩家数据就会被清除。
APP直接退出可能会导致一系列问题。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为到了规范阶段。我们团队成员们就很多事情取得了一致。角色和职责定义得非常清楚。团队还进行过有趣的团队建(shua)设(ye)活动。
改进
- 通过Alpha阶段的相互了解，我们团队的成员之间更加了解，认识到彼此的特性，分配任务时也更贴合每个人特点了。比如某成员更适合找bug，我们就安排他去做测试人员。
- 团队的执行力更强了，虽然大家的时间都比较紧，但只要任务布置下来，都会挤出来时间去完成的。
团队目前最需要改进的地方
设计工作。我们这个项目可能已经没有机会重新设计了。但是如果以后要做新的项目时，一定要把设计工作做好，包括功能设计，整体的架构设计，模块之间联系，最好都做好，对后面开发工作意义重大。
