说得很好。呵呵。mark it~
http://blog.csdn.net/quicknet/archive/2010/01/23/5249586.aspx
外一篇:Scrum再思考,游戏开发中使用敏捷方法的感受
1. 充分利用现有的工具,因为引入新工具的成本也许更大。
2. Lead Programmer 要当好需求的防火墙
玩法需求流动的路线(正规的开发):
策划1 ==\ /=> 程序1
策划2 ===> 主策划/主程序 ===> 程序2
... ...
程序改进需求流动路线(程序自我提高的主动性):
程序1 ==\
程序2 ===> 主程序 ==> 部分模块重构/推广到全组
...
3. 定期的玩法议题讨论(程序、美术对产品的主动性):
定期收集议题 ==> 每周定点讨论 ==> 策划收集、思考,那入下周计划
并不是每个成员都会对产品有高度热情,但我们要让有热情的成员有释放自己热量的机会。(敏捷方法期望的就是这种自主性,如果游戏团队本身缺少了这点热情,我觉得产品基本不可能成功)
4. 加班 is evil
从流程上改进,杜绝加班,除非情况特殊。
区分开加班和自觉提高自己,鼓励业余时间的自我提高,但不要让简单的体力活占用同学的业余时间。
5. 优质的团队氛围
团队同学如果觉得在这个团队工作,很快乐,ok,说明氛围营造得不错。
Leader要听取队员的反馈,定期反思自己。同时也要指出队员的不足,帮助其成长。
越写越偏离注意了,额~
最后再来一条:方法不是万能的,推广一种方法,可以逐步推荐,根据成员的反馈来不断调整。俗语言“方法是死的,人是活的“。
评论