Team--时代团队第一次迭代总结

一、设想和目标

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

      我们的软件《flappy bird》是一款全新动作类的游戏，与市面上的存在的游戏不一样的是，我们增加了很多功能。从传统的单人作战，转变为更有趣的团队作战。从传统的单一模式转变为可以选择的游戏模式。游戏因此变得紧张成刺激、节奏感强，玩家在游戏中便能获得更多的乐趣与成就感。从而既解决了flappy游戏相对比较枯燥无聊被动的问题，使玩家能够乐在其中，又不会像大型游戏一样占用玩家过多的时间精力，使玩家能够张弛有度。

       我们的软件《flappy bird》对我们所要解决的问题定义的非常清晰，整个一轮迭代过程中每个人都在为解决这一问题而添砖加瓦。无论是bird工作与技能，还是地图与道具的设计，都践行了我们的目标：既不会像原始bird一样相对枯燥无聊被动，又不会像大型游戏一样占用玩家过多的时间精力。

     我们的典型用户就是工作或者学习过程中想要放松的群体，他们只需一款可以消遣又耐玩的游戏，而我们的游戏恰好是以达成这一目标而努力的。（类似于蜘蛛纸牌）

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

      我们的团队在一轮迭代过程中用了整整一周的时间完成调研与游戏设计工作，并且在一周的冲刺开发过程中不断完善我们的游戏设计。

      但是完美的实现计划确实时间不够，因为这次毕竟是第一次团队的合作，正处于磨合期。所以效率上面不是很理想。外加除了这门课程之外还有其他的课程。所以第一轮迭代时间不是很充足。但是第二轮迭代应该就没有什么问题。

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

      每晚上我们在图书馆大厅会进行例会，会上大家会将自己的想法提出，每个人对于其他人提出的想法都会认真思考分析并提出自己的建议，大家一起商讨可行性之后，对于计划的是否实施与实施程度进行决策。

      在一些关键问题上面，我们采用匿名投票的方式。使得大家的意见可以完整的、无拘束的表述出来。除了开会之外，我们组建了专门的QQ群，如果有组员有什么新的想法，可以在QQ群里面快速提出，以方便对于项目决策的快速响应。我们认为这个也是敏捷开发的一个部分。

      更关键的是，所有的组员都有着高度的负责精神，即使出现了什么问题，大家也会一同解决，求同存异，一切以项目优先。

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

      在软件开发前期一定要将整个架构做好，否则在游戏整合过程中会出现各种问题，这次的一轮迭代我们的最后整合工作就花费了相关人员大量的时间与经历；每个成员的分工一定要落实到位，截止日期一定要明确，否则出现延期等情况是谁也不想看到的；团队一定要有明确的美工，否则每个人各自进行各自的美工会严重影响团队的效率，并会导致整个游戏的画风不一致等问题。

      如果历史重来一遍，那么我们无疑会改进上述问题：首先是明确美工，选出最适合美工的人来专职美工，提供各种素材与修改各种素材；定义好接口，为每个人提供最适合他的分工，第一轮迭代我们为了让每个人得到锻炼而基本让每个人都完成了差不多的代码量，但不可否认的是代码的质量参差不齐，所以第二轮迭代过程中为软件的质量和了整个团队的效率，团队成员应该各司其职，适合DEV的做DEV，适合Test的做Test。

———————————————————————————————————————————————————

二、 计划

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

     对比我们最初的原计划，我们基本完成，能完成计划主要有两个原因：

（1）第一次迭代的目标设置合适

      在对《Flappy bird》这款游戏最初策划的时候，团队中各位都对这款游戏提出了很多期望，除了最基本的设计以外，还包括小鸟选择、模式选择、音效选择的设计等等，但是    我冷静思考以后，提醒大家第一次迭代的目标应该要现实一点，大家都重新设计了第一次迭代的内容，最终达到了比较好的效果。

（2）团队协作，按照时间点完成

      我想，如果老师仔细看，就会发现我们团队和别的团队的最大不同就是，我们团队的scrum记录都是真实开发中的记录（如果你能明白我的意思），此外，我们从任务布置的当周开始就开始进行开发，而不是像其他团队等到了最后两天才忙碌起来。在整个过程中，团队的凝聚力都很强，虽然我们每个人都有很重的学业负担，但是都把软工这件事放到了很高的位置上。

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

      回顾之前，确实有一些没必要或没价值的事情。

      我们在设计的时候花了太多的时间在美工上，我认为这是不必要的，虽然美工对游戏非常重要，但是作为第一次迭代开发，逻辑功能的完备才是主要任务。更何况，按照我们的实际经历，美工的工作总是被不断的否决，不断的重做，不断的p图，花了大把时间。

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

      这一点我必须承认没有完成得非常好，在对开发的任务进行拆分以后，由于有很多的不熟悉，我们在划分好任务以后，并没有对每个模块进行很好的说明等，这里主要体现在我们没有给出一个很详尽的接口设计。

      我们有衡量交付件的标准，那就是在每个人都在最原始的框架下能够测试通过自己的模块。

2.4 是否项目的整个过程都按照计划进行?

      项目在整个过程中并没有完全按照计划进行，回头一看我们的记录可以看出来，过程中不断有队员有急事，或者感冒生病等。所以项目虽然整体上跟上步伐，但是细化到每一天，确实不完全按照计划进行。

      我们的补救方案也很简单，那就是没有做完的工作在每天的scrum meeting上面重新分配。我也是从这个细节上深深感受到了敏捷的思想。

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

      在计划中我们一直有留缓冲区的习惯，其实不仅仅是这次作业，每次任务，我们都会留下两天的缓冲区。这两天的缓冲区是有作用的，前面提到在整个过程中由于各种不可预期的事件，我们的计划会有推迟，缓冲区正是用来解决这个的。

2.6 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

      将来的计划主要会做以下几个方面的修改：

    1.在实际开发中会更加注重接口定义以及单元测试。

    2.缓冲区的时间需要留的更长一点，特别是在后期，还有操作系统、网络等大作业，大家的时间会更少，所以应该留够更长的缓冲区。

    3.加强build 工程的频率，这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。

    4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。

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

      总的来说，这次的软工，我们主要是感受了一下敏捷开发带来的高效能。记得以前做《数据库》作业的时候，4个人开发一个很简单的软件，却由于组织方法的疲软没有很好的动员好大家，搞到最后完全没有士气来做，最后一天还在赶作业。

      如果历史重来一遍，就像我刚才说的，我们会做四件事情：

    1.在实际开发中会更加注重接口定义以及单元测试。

    2.缓冲区的时间需要留的更长一点，特别是在后期，还有数据库，编译大作业，大家的时间会更少，所以应该留够更长的缓冲区。

    3.加强build 工程的频率；这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。

    4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。

---------------------------------------------------------------------------------------------

三、变更管理

3.1 每个相关的员工都及时知道了变更的消息?

      是的。团队互相见面沟通非常方便，PM可以选择互联网、短信、电话、面谈等多种方式与相关员工通知变更消息，确保消息通知及时。至于通知女生，PM一般先在QQ群上发布变更消息，如果员工没有回应，PM会发短信或打电话，确保变更消息通知及时。

3.2 我们采用了什么办法决定"推迟"和"必须实现"的功能?

    无论是例会还是紧急会议，我们只在会议上做出决定。

     首先，我们会对每个需要决定的功能进行集体讨论，大家各抒己见，在不断地剖析问题之后得出该功能实现的必要性。接下来，负责实现该功能的组员会根据自身情况分析实现该功能的难度。最终，团队将功能实现的必要性和难度综合考虑，决定"推迟"还是"必须实现"。

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

      团队的PM通常能够整合全队资源，针对变更制定应急计划。例如，如果有组员不能够及时完成自己的任务，PM会安排此段时间较为空闲的组员代为完成，保证项目的及时、顺利完成。

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

      员工一般能够有效处理意料之外的工作请求，但完成质量比较容易受到当时的环境影响。接到工作请求时，如果员工时间充裕，则会努力将其做到最好；如果和员工个人计划相冲突，则可能仅完成工作的基本要求。

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

      我们认识到了和个人项目不同的团队协作的重要性。在一般的个人项目中，计划的变更只要是自己协调好了就可以，如果遇到时间实在太紧，可以熬夜进行完成；但这在团队中是几乎不可能的，任何任务的拖延都会影响到其他组员的时间计划安排，所以应该尽力在规定的时间完成自己的部分，即使实在有困难，也必须要咨询其他组员，是否可以适应你的变更，始终要从团队的利益出发考虑问题。

      如果历史重来一遍，我们希望将计划的出口条件设定的更加明确一些，这样每个组员就可以以更高效的方式完成自己的部分，不需要进行反复地修改。但这作为项目经验较少的学生来说，有一定的困难，因为无法非常准确地进行结果的预估，而且也可能会一定程度上影响项目的灵活性。所以，希望通过团队的讨论找到一种较好的方法，使得每个人的部分可以很好地与全队项目相融合，做到"形散神聚"。

------------------------------------------------------------------------------

四、设计/实现

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

      设计工作是大家一起完成的。每个部分的设计详情可以参考我们的会议记录。应该说项目一拿到第一时间就是完成设计工作，而且每个模块的设计人员都是对那个模块很感兴趣，最后的设计都是很有意思的。

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

      项目中有些模块的设计确实碰到过模棱两可的情况，会随着项目的进展进行确定下来。

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

      单元测试很遗憾没成功。由于测试人员对于c#的单元测试功能不熟悉以及开发时间所限，没有做单元测试。在开发的过程中我们用到了UML图展现各个模块以及借口，这样让全体开发人员对于彼此间模块的关联都了解了一下，能大幅提升开发效率。

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

      在开发过程中图片的移动和小鸟的移动差生的bug是最多，很大程度上是因为对c#实现图片移动中Timer类的运用不得当。

      没有在设计/开发时想到这些情况的主要原因在于第一次这么多人一起合作写代码，工程量比较大，大家的经验不是非常的丰富，不能进行很好地判断。但这也让我们积累经验，以更好地进行下一轮开发。

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

      首先每个模块写完，负责的同学都会进行一次自我的代码复审。然后代码汇总后，再一次进行复审。

      我们并没有一个严格的代码规范，但是我们简要地说明了一些规则来保证代码的可阅读性，例如，变量名尽量起得比较有意义，要进行比较合适的注释，再提交自己部分的代码时要附上自己的测试代码等。

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

      最初设计的时候并没有很完整把整个框架都设计出来，这也导致了开发过程进行到了一半时各个模块的工作进度没有协调好。接口没有设计好，导致一些功能实现的难度增大。更重要的是，此次项目没有成功完成单元测试，这其实也有最初接口没有设计好的原因。如果重来一遍，我们在最初的设计中一定更加严格的遵守软件工程的要求。

 -------------------------------------------------------------------------------------------

五、测试/发布

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

没有一个十分完整的测试计划。第一轮迭代时间紧任务重，又因为大家都是第一次进行软件工程开发，经验欠缺，无法一开始就制定明确的测试计划。

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

进行了最后的验收测试。而且事实上在最后一天全团队都在进行测试。

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

这次迭代的测试基本上由手工实现。使用VS自带的单元测试工具。

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

软件实际运行时，在加载的时候没有预想的那么流畅，但是在加载之后不会出现卡顿的现象。没有发现跟踪软件效能的工具，主要还是凭借人工的操作和体验。因此，下一次迭代在这方面要做些功夫。

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

 软件的测试十分重要。如果少做测试或者不做测试，那么后期会花很大功夫在调试上。这点上我们确实也努力做了测试。但是未能使用一些专门的工具进行测试，这一点是不足的。而且设定一个测试计划应该能使整个测试过程显得更有安排、更不容易缺漏。对于软件效能，我们也会在后续的过程中寻找相关的测试工具帮助测量。

-------------------------------------------------------------------

六、总结

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

      正如CMM/CMMI中我们正处于第二阶段到第三阶段的过渡状态，目前团队正处于磨合到规范的过渡状态。在前两周的工作之中，我们团队相互磨合，已经较为成功的完成了整个项目的第一次迭代。并且在这之上我们定义了相关的文档，已经将程序部分规范化。大家协同作战，成员们就很多事情取得了一致。角色和职责定义得非常清楚。团队还进行过有趣的团队建设活动。

      但正如他人经验之谈，并不是当团队进入到了规范阶段，就万事大吉了。经验表明，很多情况下团队会由规范阶段回到磨合阶段，或者在两个阶段间徘徊。团队成员们必须努力工作，才能使团队保持在这一阶段, 他们同时还要抵御外界的压力，以免使团队分裂，或者回到磨合阶段。所以我们团队目前正处于两个阶段的过渡阶段。

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

      我们仍然处于一个过渡阶段，也就是虽然大部分的规范规则已经定义，但是仍然有不少东西还处于未定义、未规范化的状态。在6个人的小组开发内这个不会出现什么问题，但是这样子的成果可维护性、可移植性不是很高。所以我们下一步会更加的规范这一类的程序、文档。争取在第二次迭代中期进入CMM中第三阶段，使团队状态处于规范阶段。

6.3 对比敏捷的原则, 你觉得你们小组做得最好的是什么? 

    对比敏捷的原则，我们组做得最好的就是daily scrum了。在一周的实现周期里，我们基本上每天一面，总结前一天的完成量，计划第二天的任务。这也是我们在进度上紧跟时间安排的原因之一。

6.4 什么是在下个阶段要改进的地方?  越具体越好。

    这个阶段的不足，以及下个阶段要改进的地方，已经都在上文中列出了。主要的问题如下：

    1、正式开发前没有完全定义好接口，使得整合工作难度加大。主要原因在于本身这是一件比较难的事情，而在最开始团队中大多数成员基本没有游戏开发的经验，因此最后由一两个人定义出来的接口较为粗糙。经过第一次迭代之后，这个问题在M2阶段将很容易解决。

   2、分工上没有完全利用好团队资源。也是由于经验不足，我们在分工的时候确实对某些模块的工作量和难度有误判，使得能力较强的同学反而没有发挥的空间。同样由于第一次迭代的经验，这个问题也将不会在M2出现。

   3、对软件的测试和效能测量，没有使用专门的工具进行。下一阶段将寻找相应的方法专业化我们的测试。 

最后，愿我们Team--时代在第二轮迭代中，发扬优点，改正缺点，共同进步，友谊长青！

 

 

 

转载于:https://www.cnblogs.com/sulindong/p/3704900.html