团队作业第六周（盐酸队）---------事后诸葛亮分析报告

一、设想与目标

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

•  我们的软件主要是为了增强用户的游戏体验，增加更多的趣味性。

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

• 是，在做这个项目之前，我们进行了广泛的人群调研与需求分析，同时小组间对于本项目的各项功能是否有实用价值进行了深入的讨论。基于alpha阶段的工作，beta阶段吸取了之前的教训，效率上有所提高，时间相对充裕。

3. 团队在计划阶段是如何解决成员对于计划的不同意见的？

• 如果对于计划队员间有不同的意见，我们会请他们各自讲出自己意见的理由，然后考虑是否能有两全齐美的计划安排。如果没有，将由队员进行举手表决，最后由少数服从多数来进行安排。队员间有不同意见是难免的，我们会理性的进行兼顾各方的民主安排。我们会一起开会讨论，各抒己见，对于一些复杂的功能，实现不了的就放弃了，意见遵循少数服从多数的原则，综合考虑各种因素，我们手上所有的资源以及我们的实际能力，和能达到的水平都会一起讨论分析，成员们也都是非常乐意听取意见的人，在这方面问题不大。

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

• 团队成员之间的分工要针对个人所擅长的领域，避免事倍功半。个别成员参与度不高，这也是一个问题。如果历史重来，首先分工尽量明确，让每个人都有任务可以做并且是愿意做的，能做好而不是草草应付，或者说因为不擅长而做得很费劲。

   

二.计划

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

• 我们计划beta阶段完成游戏联网功能

2. 有没有发现你做了一些事后看来没必要或没多大价值的事?

• 这倒是没有，吸取了alpha阶段的教训，我们直奔主题，配合也越来越默契，效率也提高很多。

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

• 代码方面有所欠缺

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

• 基本按照计划，就是支付功能最终无法完整实现。一开始以为是可以的，高估自己的能力了。

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

• 没有考虑。缓冲区有作用，比如项目出现问题，可以缓一缓

6. 将来的计划会做什么修改？

• 会留缓冲区，应对紧急情况。成员之间建立起互相监督的机制，提高效率。

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

• 要及时完成计划中的任务。任务分配应该合理而明确。

三.资源

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

• 资源问题的话，说不够也不够说足够也足够。首先，不够的话，我们一开始有一些资源，就是老师给的参考代码，但是毕竟自己团队对代码的规范跟标准与别人的不一样，所以大部分都看不懂，资源也就差不多都没用上了。还有缺少就是时间资源吧，因为大三课程较多，尤其是实验课最多，除了课余的讨论时间，也就仅仅一两天时间去做项目。要说足够的话，我们最好的资源就是有一位在编程方面比较擅长的组长、还有擅长界面设计的队友、拥有PS技能的人员、擅长博客编写的人员；虽然时间资源不够，但是我们有丰富的精神资源，熬夜写代码，写博客，队友之间互相鼓励、支持。

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

• 每次做任务之前，组长会将每个人的任务分配好，基本是按一天完成几个任务，任务精度级算是精确到每天。

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

• 测试的话，之前有说过，我们在测试方面相对薄弱，因为我们是手动测试，找出bug再解决，测试方面的人力资源足够而软件资源有限，导致测试花费好多时间。对于美工设计我们还是相对比较重视，做出来的界面相对较美观，觉得其做起来也是并不容易，在文案方面也是相对重视，花费了好多时间在上面，包括博客撰写、任务分配等等。

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

• 没有觉得，因为每个人都有自己擅长的方面，该做测试的人员做测试，该美工的人员做美工，开发人员做开发，如果交换一下就不一定做得来了，所以还是每个人都做自己擅长的，能做得来的才能节省时间更有效率。若是不考虑效率光说做不做的来的话，我想互相教一教还是可以做的来，但是团队做项目，效率还是很重要的。

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

• 在这个阶段我们学到很多东西，在团队方面学会合作互相帮助，在项目上面，学会如何测试，如何美工，如何编程。如果历史重来一遍，分配时，应该更加明确些，具体到某一点的哪些内容，否则会出现队员做了相同的事，而产生了无用功浪费了人力物力。同时沟通真的很重要，队员间要多多加强沟通，防止因为误解队员的意里而产生误会。       

四.变更管理

1. 每个相关的成员都及时知道了变更的消息?

• 每个成员都及时知道项目进行中的变更信息。我们小组是由两个宿舍组成的，一个队友知道的变更消息，会告诉自己的舍友，传播速度快。除了这个，我们的的工作内容都发布在微信群上。小组成员都可以收到信息。为了保证，信息通知的灵活性，我们小组还有一个讨论组。每个人都可以及时通知和获得紧急信息。

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

• 在刚接手项目的时候，我们小组就开过会讨论，并确定了项目的核心功能。并且讨论了各个功能实现的难易。“推迟”和“必须实现”是这样界定的：1、核心功能中容易实现的必须在 alpha 版本实现；2、核心功能中有技术难点的推迟到 beta 版本实现。后来也是按照这个方法完成了项目。

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

• 小组对项目出口条件的定义是：项目能够满足《毕设导师智能分配系统》的需求。一定的用户先体验，反馈良好。

4. 对于可能的变更是否能制定应急计划?

• 对于重大的变更，我们暂时没有应对计划,但是，我们有应对数据库变更的计划。我们对数据库进行了备份，能够在需要的时候使用恢复备份以及扩展数据库。

5. 成员是否能够有效地处理意料之外的任务请求？

• 可以。如果得知意料之外的任务请求，我们会经过小组讨论接受挑战，争取完成任务。

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

• 学到了为防变更而制定应急计划，既对数据库进行备份。如果历史重来一遍，首先应明确整个开发过程大体要做哪些事，将较大的模块落实到个人负责，如文档由某成员专门负责。

五.设计/实现

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

•  设计工作是在Alpha阶段冲刺的时候开始的。由我们的队长领导，团队成员一起讨论来完成。在适合的时间，适合的人员中完成了适合的事情。

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

• 有的。原型设计的时候，每个人对于某一内容的实现方式有不同的想法，界面的风格，颜色的搭配，等有了很大的分歧，最终是通过投票进行选择的。

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

• 有运用单元测试，UML测试，等测试工具。这些工具很有效，大大的提高了测试的效率，降低了手工测试的工作量。同时有的测试工具还有提供一些小问题的解决办法。为我们减轻了很多负担。但测试出现的大多问题都会记录下来然后团队讨论解决方案。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

• 因为进行代码测试时，大家会把出现的问题记录下来共同解决。所以经过统计出现bug最多的是坦克的移动攻击，因为它实在有些复杂。而在发布之后发现功能并不能完全实现，不知道是什么问题。因为大家都是新手第一次做这样的项目，所以难免会不能考虑周全。在设计开发之前有过对此功能的预想设计但是仍然不够完备。

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

• 在代码开发之前我们就有规定代码编写的规范问题，所以为代码复审带来了很大的便利。代码复审的工作由参与代码编写的人员来执行，互相检查彼此的代码然后找出问题，再共同解决。因为参与开发的人员不多，所以能够严格执行代码的规范。

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

• 我们学习到了，人只有在不断的挑战自己的极限中才能得道最大的进步。不论是对工作任务上的挑战还是心理承受上的挑战，都能使我们得到成长。因为人的很多能力都是发掘出来的，只有去尝试才能够进步。而对于本次项目在代码编写或是博客编写的方面学到的东西更是不言而喻的。如果重来一次，我们会在事前做更完备的计划分析，不仅要考虑到每个人的任务，也要考虑到如果没能按时完成或某位成员更不上进度的解决方案。

六.测试/发布

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

• 有测试计划

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

• 有对每一部分功能进行正式的验收测试

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

• 有

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

• 各个模块的测试分配给各个测试组员，这些组员进行用例测试。从软件实际运行的结果来看，这些测试工作还是挺有用的，比如可以测试出一段JavaScript代码或PHP代码对于边界数据的处理是否合乎期望，测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。改进的方面就是大家应该在如何运用测试软件上多做些学习，这样可以保证正确的执行测试任务同时节约时间提高效率。

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

• 出现的意外有，发布的时候有晚点，在博客提交的时候完了一天。

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

• 我们学习到了要认真遵守规定，时间观念一定要重视。晚了就是晚了，即使是在学习任务上也不能说寄希望与别人给予通融。如果重来一遍我们会时刻注意应该完成的任务。然后养成良好的时间观念。

七、总结:

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

 游戏的基本功能已经实现，但流畅度还不是很好。

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

• 磨合过了，到了规范阶段了，经过alpha阶段队员们之间熟悉了很多，有问题也会直接指出，不以规矩不成方圆，凡事还是规范化做起来效率较高，不用顾虑太多其他因素，规则定在那里就去执行。

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

我们都在做自己擅长的虽然效率提高，但是也缺乏探索和创新能力，没有积极主动地去往自己不会的领域发展，多方面的发展自己。遇到难一点的东西做了失败了以后就会打退堂鼓，觉得不行了没法完成了也就没有再花时间去尝试到底能不能成功。缺乏一种钻研的精神。

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

名字	角色	团队贡献分	可验证贡献
黄国航	DEV	20	功能代码编写
黄宇航	PM	14	页面部分代码，分配工作
李密	TEST	18	部分代码编写，测试
卢泰佑	DEV	17	功能代码编写
赖少勇	TEST	15	测试，博客
陈舒标	DEV	16	功能代码编写