事后诸葛亮分析

Author：六神花露水

Project：玩个球

一.设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件预期在做出一个好玩的，没有广告的小游戏，定位清楚。对用户和场景有描述。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

因为要实现记录用户信息，通关关卡，最高分等这一部分的时候涉及到云数据库、用户授权等知识，所以没有实现”记录用户游戏信息“模块，实现了预期的95%的功能。按照原计划时间交付了，已经在微信小程序发布。在发布的第一天注册用户346人，但接下来的几天人数增长有点慢，与预期的1000人还有点差距。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍,我们会做什么改进?

? 第一天就能有346的用户量已经超出了我们的预期，但是对接下来几天的用户量感到失望。接到了很多玩家对游戏的反馈，有人说不知道怎么玩，有人觉得太坑了，但同时也有人觉得游戏做得很好，极大鼓励了我们，用户的接受程度基本在预期之下。肯定离目标更近了。经验教训就是：一定要提前把任务分配好，规定好提交时间，必须把任务分配到个人身上，不然大家都会偷懒，任务不能按时完成。如果历史能重来，赶紧把任务分下去，按时和队友交流进度。

二.计划

1. 是否有充足的时间来做计划?

除考试时间外，大家都有充足的时间做计划。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

中和大家的意见，最后由队长拍板，选取较好方案。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

原计划的工作基本完成，游戏已发布，但是云开发模块由于程序调试的原因，没有继续进行。

4. 是否每一项任务都有清楚定义和衡量的交付件?

基本上符合，开发过程中会根据具体情况做出相应的修改。

5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

项目基本按计划进行，小意外的话是小程序无法支持横屏，所以有几个游戏关卡进行了调整。

6. 在计划中有没有留下缓冲区，缓冲区有作用么?

没有

7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

对软件开发的流程有更多的了解，队员间的合作能力明显提高。改进方面，在时间安排，与任务分配，以及人员安排等方面仍需要调整。

三.资源

1.我们有足够的资源来完成各项任务么?

UI资源方面：团队成员仅有一人负责地图方面的UI绘制，人手不足。

统计用户方面：我们没有足够的人脉资源和时间资源来完成我们的推广，以至于达不到原计划的用户数量。

引擎API方面：采用的Cocos引擎的官方文档注释不多，测试功能难度大。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

主要是根据任务量来估计的，但是对任务的难度欠考虑，致使有些任务的估计时间偏低。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间足够，硬件资源是引擎自带可测试的。而我们低估了UI资源绘制的难度。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

在队伍中，我的沟通组织能力不够优秀，更偏向于默默开发，有时候由别人来组织会更有效率，但这次的作业也很好地锻炼了我的相关能力。

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

分工希望能更加明确，能将最佳的人分配到最合适的位置上。

四、变更管理

1.我们采用了什么办法决定“推迟”和“必须实现”的功能?

通过讨论这项功能的在用户使用上的重要性以及用户需求的急迫性，并考虑对现有功能的影响以及时间是否足够。

2. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有定义，基本功能实现并且没有严重影响游戏玩法的bug即可出口。

3. 员工是否能够有效地处理意料之外的工作请求？

能，对于意料之外的工作请求我们的成员还是比较乐意接受的。

五.设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在需求分析和alpha冲刺阶段都有设计，经过大家共同讨论后主要由PM、产品和一名开发决定。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

没有出现，队员遇到模糊的地方会及时提出疑问，提出创意的队员会对应解答。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

我们有利用VISIO工具进行UML图的绘制，帮助项目设计和实现，这些工具使项目的模型更加清晰，大大提高了实现的效率。

4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

一组开发人员完成了相应的模块后由另外一组开发人员进行代码复审。所有开发人员均严格执行了项目初始阶段制定的代码规范。

六.测试/发布

1. 团队是否有一个测试计划？为什么没有？

有，用不同手机和模拟器进行游戏试玩，通过每一个关卡的试玩检测失误。

2. 是否进行了正式的验收测试？

是。

3. 团队是否有测试工具来帮助测试？

有。微信工作平台。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

各个模块的测试分配给各个相应的开发组员，这些组员进行用例测试。从软件实际运行的结果来看，测试工作是有用的。

5. 在发布的过程中发现了哪些意外问题？

项目云开发的未知错误。小程序发布中的申请和游戏大小限制。

七、团队的角色，管理，合作

1.团队的每个角色是如何确定的，是不是人尽其才？

? 按照我们各自的兴趣先主动选择，后面根据游戏开发需求分工开发，并且分出UI人员，人尽其才。

2.团队成员之间有互相帮助么？

? 有。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

? 因为分工明确，队长提前分配好任务，所以在合作这一块还是比较和谐，没有出现大问题。项目管理在比如GitHub提交出现冲突的时候一般由PM组织沟通好来解决。

八、总结:

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

? 规范阶段。

3.你觉得目前最需要改进的一个方面是什么?

? 测试的全面性

4.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 首先我们做到了可以尽早持续的交付有价值的软件。三个阶段中，我们都可以做到交付一个具有可玩性的小游戏供大家使用。
• 组内成员也都做到了精益求精，不仅仅将眼光放在完成布置的任务中，而是对整个小程序性能的提升做出一些建议，并且实现它

5.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

• 开发者必须严格按照流程进行代码编写和提交
• 复审过程像上述中的流程一样，有测试人员经手再通过管理人员发布。
• 严格按照代码规范文档，严谨地进行变量名的书写和格式等等。
• 如果结果不合格会进行一定程度的惩罚并且责任到人，再次进行修改。

6.其它软件工具的应用，应该如何提高？

? 我们在测试方面，需要使用软件工具，帮我们完成代码覆盖率和一些压力测试。在这些方面，我们缺乏调研，仅凭自己的判断就认为网站不需要覆盖率是不正确的想法。

5.项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

? 我们通过小程序开发者工具的后台工具查看，并借助云服务器查看登陆的用户

6.项目文档的质量如何提高？

对于文档来说，最好的方式就是有固定的统一的模板。并且文档是需要不断更新的，在一个阶段结束前需要更新该阶段的文档保证文档是不断扩充，不会落后于代码工程。

九、团队成员在Alpha阶段的角色和具体贡献：