标签：style blog width strong http 2014
一、设想和目标
我们的软件《flappy bird》是一款全新动作类的游戏，与市面上的存在的游戏不一样的是，我们增加了很多功能。从传统的单人作战，转变为更有趣的团队作战。从传统的单一模式转变为可以选择的游戏模式。游戏因此变得紧张成刺激、节奏感强，玩家在游戏中便能获得更多的乐趣与成就感。从而既解决了flappy游戏相对比较枯燥无聊被动的问题，使玩家能够乐在其中，又不会像大型游戏一样占用玩家过多的时间精力，使玩家能够张弛有度。
我们的软件《flappy bird》对我们所要解决的问题定义的非常清晰，整个一轮迭代过程中每个人都在为解决这一问题而添砖加瓦。无论是bird工作与技能，还是地图与道具的设计，都践行了我们的目标：既不会像原始bird一样相对枯燥无聊被动，又不会像大型游戏一样占用玩家过多的时间精力。
我们的典型用户就是工作或者学习过程中想要放松的群体，他们只需一款可以消遣又耐玩的游戏，而我们的游戏恰好是以达成这一目标而努力的。（类似于蜘蛛纸牌）
我们的团队在一轮迭代过程中用了整整一周的时间完成调研与游戏设计工作，并且在一周的冲刺开发过程中不断完善我们的游戏设计。
但是完美的实现计划确实时间不够，因为这次毕竟是第一次团队的合作，正处于磨合期。所以效率上面不是很理想。外加除了这门课程之外还有其他的课程。所以第一轮迭代时间不是很充足。但是第二轮迭代应该就没有什么问题。
每晚上我们在图书馆大厅会进行例会，会上大家会将自己的想法提出，每个人对于其他人提出的想法都会认真思考分析并提出自己的建议，大家一起商讨可行性之后，对于计划的是否实施与实施程度进行决策。
在一些关键问题上面，我们采用匿名投票的方式。使得大家的意见可以完整的、无拘束的表述出来。除了开会之外，我们组建了专门的QQ群，如果有组员有什么新的想法，可以在QQ群里面快速提出，以方便对于项目决策的快速响应。我们认为这个也是敏捷开发的一个部分。
更关键的是，所有的组员都有着高度的负责精神，即使出现了什么问题，大家也会一同解决，求同存异，一切以项目优先。
在软件开发前期一定要将整个架构做好，否则在游戏整合过程中会出现各种问题，这次的一轮迭代我们的最后整合工作就花费了相关人员大量的时间与经历；每个成员的分工一定要落实到位，截止日期一定要明确，否则出现延期等情况是谁也不想看到的；团队一定要有明确的美工，否则每个人各自进行各自的美工会严重影响团队的效率，并会导致整个游戏的画风不一致等问题。
如果历史重来一遍，那么我们无疑会改进上述问题：首先是明确美工，选出最适合美工的人来专职美工，提供各种素材与修改各种素材；定义好接口，为每个人提供最适合他的分工，第一轮迭代我们为了让每个人得到锻炼而基本让每个人都完成了差不多的代码量，但不可否认的是代码的质量参差不齐，所以第二轮迭代过程中为软件的质量和了整个团队的效率，团队成员应该各司其职，适合DEV的做DEV，适合Test的做Test。
———————————————————————————————————————————————————
二、 计划
对比我们最初的原计划，我们基本完成，能完成计划主要有两个原因：
（1）第一次迭代的目标设置合适
在对《Flappy bird》这款游戏最初策划的时候，团队中各位都对这款游戏提出了很多期望，除了最基本的设计以外，还包括小鸟选择、模式选择、音效选择的设计等等，但是 我冷静思考以后，提醒大家第一次迭代的目标应该要现实一点，大家都重新设计了第一次迭代的内容，最终达到了比较好的效果。
（2）团队协作，按照时间点完成
我想，如果老师仔细看，就会发现我们团队和别的团队的最大不同就是，我们团队的scrum记录都是真实开发中的记录（如果你能明白我的意思），此外，我们从任务布置的当周开始就开始进行开发，而不是像其他团队等到了最后两天才忙碌起来。在整个过程中，团队的凝聚力都很强，虽然我们每个人都有很重的学业负担，但是都把软工这件事放到了很高的位置上。
回顾之前，确实有一些没必要或没价值的事情。
我们在设计的时候花了太多的时间在美工上，我认为这是不必要的，虽然美工对游戏非常重要，但是作为第一次迭代开发，逻辑功能的完备才是主要任务。更何况，按照我们的实际经历，美工的工作总是被不断的否决，不断的重做，不断的p图，花了大把时间。
这一点我必须承认没有完成得非常好，在对开发的任务进行拆分以后，由于有很多的不熟悉，我们在划分好任务以后，并没有对每个模块进行很好的说明等，这里主要体现在我们没有给出一个很详尽的接口设计。
我们有衡量交付件的标准，那就是在每个人都在最原始的框架下能够测试通过自己的模块。
项目在整个过程中并没有完全按照计划进行，回头一看我们的记录可以看出来，过程中不断有队员有急事，或者感冒生病等。所以项目虽然整体上跟上步伐，但是细化到每一天，确实不完全按照计划进行。
我们的补救方案也很简单，那就是没有做完的工作在每天的scrum meeting上面重新分配。我也是从这个细节上深深感受到了敏捷的思想。
在计划中我们一直有留缓冲区的习惯，其实不仅仅是这次作业，每次任务，我们都会留下两天的缓冲区。这两天的缓冲区是有作用的，前面提到在整个过程中由于各种不可预期的事件，我们的计划会有推迟，缓冲区正是用来解决这个的。
将来的计划主要会做以下几个方面的修改：
1.在实际开发中会更加注重接口定义以及单元测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有操作系统、网络等大作业，大家的时间会更少，所以应该留够更长的缓冲区。
3.加强build 工程的频率，这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。
4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
总的来说，这次的软工，我们主要是感受了一下敏捷开发带来的高效能。记得以前做《数据库》作业的时候，4个人开发一个很简单的软件，却由于组织方法的疲软没有很好的动员好大家，搞到最后完全没有士气来做，最后一天还在赶作业。
如果历史重来一遍，就像我刚才说的，我们会做四件事情：
1.在实际开发中会更加注重接口定义以及单元测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有数据库，编译大作业，大家的时间会更少，所以应该留够更长的缓冲区。
3.加强build 工程的频率；这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。
4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
----------------------------------------------------------------------------------------------
三、总结
正如CMM/CMMI中我们正处于第二阶段到第三阶段的过渡状态，目前团队正处于磨合到规范的过渡状态。在前两周的工作之中，我们团队相互磨合，已经较为成功的完成了整个项目的第一次迭代。并且在这之上我们定义了相关的文档，已经将程序部分规范化。大家协同作战，成员们就很多事情取得了一致。角色和职责定义得非常清楚。团队还进行过有趣的团队建设活动。
但正如他人经验之谈，并不是当团队进入到了规范阶段，就万事大吉了。经验表明，很多情况下团队会由规范阶段回到磨合阶段，或者在两个阶段间徘徊。团队成员们必须努力工作，才能使团队保持在这一阶段, 他们同时还要抵御外界的压力，以免使团队分裂，或者回到磨合阶段。所以我们团队目前正处于两个阶段的过渡阶段。
我们仍然处于一个过渡阶段，也就是虽然大部分的规范规则已经定义，但是仍然有不少东西还处于未定义、未规范化的状态。在6个人的小组开发内这个不会出现什么问题，但是这样子的成果可维护性、可移植性不是很高。所以我们下一步会更加的规范这一类的程序、文档。争取在第二次迭代中期进入CMM中第三阶段，使团队状态处于规范阶段。
对比敏捷的原则，我们组做得最好的就是daily scrum了。在一周的实现周期里，我们基本上每天一面，总结前一天的完成量，计划第二天的任务。这也是我们在进度上紧跟时间安排的原因之一。
这个阶段的不足，以及下个阶段要改进的地方，已经都在上文中列出了。主要的问题如下：
1、正式开发前没有完全定义好接口，使得整合工作难度加大。主要原因在于本身这是一件比较难的事情，而在最开始团队中大多数成员基本没有游戏开发的经验，因此最后由一两个人定义出来的接口较为粗糙。经过第一次迭代之后，这个问题在M2阶段将很容易解决。
2、分工上没有完全利用好团队资源。也是由于经验不足，我们在分工的时候确实对某些模块的工作量和难度有误判，使得能力较强的同学反而没有发挥的空间。同样由于第一次迭代的经验，这个问题也将不会在M2出现。
3、对软件的测试和效能测量，没有使用专门的工具进行。下一阶段将寻找相应的方法专业化我们的测试。
最后，愿我们Team--时代在第二轮迭代中，发扬优点，改正缺点，共同进步，友谊长青！
Team--时代团队第一次迭代总结,布布扣,bubuko.com
标签：style blog width strong http 2014
原文地址：http://www.cnblogs.com/sulindong/p/3704900.html
