一个小团队TDD游戏及实践
2014-03-10 22:24
302 查看
介绍的这个游戏是自己根据目前带的团队的实际情况来制定的, 在游戏实践过程中,收到了较好的效果,故打算把这个游戏分享出来,一是分享一下实践,而是集思广益,不断完善,更好的利用游戏来锻炼队伍。下面就将游戏规则,游戏制定说明,游戏适用人数,以及实践情况一一分享。
游戏规则:
团队成员自己排好顺序,轮流进行TDD。TDD三个环节中,只进行测试编写和实现两个环节,故意不设置重构环节。每个人每次只进行一个环节。以此类推。如果团队人数为奇数,则每个人每次进行的环节都会和上一次进行的不一样。如果为偶数,则要重新排列一下,保证每个人每次进行的环节和上次不一样。
不管是编写测试,还是实现,时间要求尽量在5分钟内完成。 如果完成了,得5分。如果没有完成,扣掉2分。
如果编写的测试有错误,其他成员发现了,则测试扣2分,发现者加2分。
如果因为测试步子太大导致实现没有完成,则扣掉编写测试的人2分。
如果实现或者编写测试的人,对代码进行了重构,则加2分。
以上就是整个游戏的规则。
规则设置说明:
采用TDD轮流的方式,已经有较多的人实战过或者了解过,再次就不多说明了。
限定时间,一是为了限定步子不能太大了,二是模拟实际工作中,项目进度压力。
故意不要重构的环节是为了检验是否有人会主动重构,这在项目中很重要。同时辅以加分引导重构。
其他的加分和扣分都是为了朝正确的方向引导。
多人进行轮流TDD,是模拟实际工作中,代码集体所有。
游戏适宜人数:
自己认为3-4人较好,人多了,节奏会没有那么快。
简要的实践情况说明:
这个游戏由团队5人进行的,在最开始几轮,每个人都有被扣分。团队协作不好,没有明确的目标,走一步算一步。
在这个过程中,不断有人挖坑,因为时间的关系,只有一个人重构过一次。但势单力薄啊。
团队的利益,和个人的利益相比,还是个人利益优先啊。
在挖坑和被坑过程中,笑料不断。
传说中没法继续做下去的代码出现了。才几轮过后,就这样了, 超乎我的想象。
在没有办法的情况下,在团队中找了一个人停下来进行大的重构,花了一些时间。
在重构后,5个人分析了一下原因,开始在总的目标和详细设计上先达成了一致,然后按照设计的方式一步一步进行。
这之后,进展明显比之前推进的更平顺,也较少出现扣分,就这样一直持续到最后。
在关键实现上,出现了超过时间的情况,这符合实际情况。
回顾:
在团队协作上存在的问题,团队目标,计划和实施等环节的问题都暴露出来了。
代码集体所有,如果有人挖坑,同时也没人维护代码质量,代码腐烂的程度超乎你的想象。
增强了团队的凝聚力,增加了不少的笑料。
采用的技术多样化,相互之间进行了交叉学习。
个人目标和团队目标的权衡,还真是难题啊。
这次游戏取得的效果,还是比较令人满意的。这个游戏本身也是第一次制定出来,第一次实战,还有不完善的地方,期望有兴趣的同仁一起来参与实践和改进。
游戏规则:
团队成员自己排好顺序,轮流进行TDD。TDD三个环节中,只进行测试编写和实现两个环节,故意不设置重构环节。每个人每次只进行一个环节。以此类推。如果团队人数为奇数,则每个人每次进行的环节都会和上一次进行的不一样。如果为偶数,则要重新排列一下,保证每个人每次进行的环节和上次不一样。
不管是编写测试,还是实现,时间要求尽量在5分钟内完成。 如果完成了,得5分。如果没有完成,扣掉2分。
如果编写的测试有错误,其他成员发现了,则测试扣2分,发现者加2分。
如果因为测试步子太大导致实现没有完成,则扣掉编写测试的人2分。
如果实现或者编写测试的人,对代码进行了重构,则加2分。
以上就是整个游戏的规则。
规则设置说明:
采用TDD轮流的方式,已经有较多的人实战过或者了解过,再次就不多说明了。
限定时间,一是为了限定步子不能太大了,二是模拟实际工作中,项目进度压力。
故意不要重构的环节是为了检验是否有人会主动重构,这在项目中很重要。同时辅以加分引导重构。
其他的加分和扣分都是为了朝正确的方向引导。
多人进行轮流TDD,是模拟实际工作中,代码集体所有。
游戏适宜人数:
自己认为3-4人较好,人多了,节奏会没有那么快。
简要的实践情况说明:
这个游戏由团队5人进行的,在最开始几轮,每个人都有被扣分。团队协作不好,没有明确的目标,走一步算一步。
在这个过程中,不断有人挖坑,因为时间的关系,只有一个人重构过一次。但势单力薄啊。
团队的利益,和个人的利益相比,还是个人利益优先啊。
在挖坑和被坑过程中,笑料不断。
传说中没法继续做下去的代码出现了。才几轮过后,就这样了, 超乎我的想象。
在没有办法的情况下,在团队中找了一个人停下来进行大的重构,花了一些时间。
在重构后,5个人分析了一下原因,开始在总的目标和详细设计上先达成了一致,然后按照设计的方式一步一步进行。
这之后,进展明显比之前推进的更平顺,也较少出现扣分,就这样一直持续到最后。
在关键实现上,出现了超过时间的情况,这符合实际情况。
回顾:
在团队协作上存在的问题,团队目标,计划和实施等环节的问题都暴露出来了。
代码集体所有,如果有人挖坑,同时也没人维护代码质量,代码腐烂的程度超乎你的想象。
增强了团队的凝聚力,增加了不少的笑料。
采用的技术多样化,相互之间进行了交叉学习。
个人目标和团队目标的权衡,还真是难题啊。
这次游戏取得的效果,还是比较令人满意的。这个游戏本身也是第一次制定出来,第一次实战,还有不完善的地方,期望有兴趣的同仁一起来参与实践和改进。
相关文章推荐
- 许多游戏公司都是先布置办公室,让开发团队在里面协同工作,刻苦努力多年创造出新知识产权 (IP),然后将产品交给零售店和直接分销网站出售,Steam 就是一个典型的例子。但愿能获得利润,这样他们就可以再
- TDD在Unity3D游戏项目开发中的实践
- 爬虫在游戏数据分析的一个实践
- 或许对你有帮助的一个独立游戏团队的2015创业总结
- 一个游戏团队的惨败教训:错误连着错误(转)
- 游戏设计的艺术:一本透镜的书——第二十三章 设计师通常和一个团队一起工作
- 知乎问题"房间里100个人,每人1000元,他们玩一个游戏,每轮游戏中,每个人拿出1元,随机给另一个人,最后他们的财富分布是怎样的"实践解答
- Game Engine Architecture阅读 1.1 一个典型游戏开发团队的结构(Structure of a Typical Game Team)
- 玩一个Tennis TDD的编程操练游戏
- 一个游戏团队15年的创业总结:熬着 活下来
- 自定义View实践-一个简单的棋类游戏
- css3d动画学习心得2:一个小游戏实践
- Game Engine Architecture by Jason Gregory:1.1 一个典型游戏团队的结构
- 一个新手的TDD实践
- 爬虫在游戏数据分析的一个实践
- 如何打造一个创业团队
- 一个python游戏源码
- 黄金点游戏 - 团队排名
- 希望大家踊跃参加"开源项目团队",打造一个高质量的Team
- 向游戏圈内同仁推荐一个BLOG