几乎经历的每个项目都会以scrum的方式开展,因为这样的方式最适合小工作室。人数在3-12人为最好,如果人数超过12人,每天的站立会议大家都会很“疲乏”。scrum的顺利开展需要组员对自己的工作有充分的理解,可是几乎没有这么完美的事情。
遇到不少问题:
1、人员
“新手”多:几乎不可避免,工作室几乎每天都有人员流动,无论是leader原因还是个人,组内始终有人进组、被调组、或者离职。每次变更就需要讲解一次流程以及工作内容。
因为是新技术、新平台,还需要开发人员熟悉我们的“引擎”开发模式。所以每次scrum内sprint开展都不可避免的需要顺延时间。
2、能力
scurm的开展也融合“瀑布”模式和“迭代”模式,需要有经验的开发人员对每个backlog理解清晰,并且能“正确”评估时间以及分解task。无奈的结果是几乎没有一次理想达到scrum提倡的“每日集成”概念:P。
3、时间
一个sprint结束验收时间基本是sprint开始时预估时间的2倍多(个别项目),即使每天大家都加班很晚才能完成task。
一般sprint都会以二个星期为开发周期,一周集成时间,一周调试和准备下一个sprint的时间。
4、配合
成员都需要时间磨合,产品方案在scrum开始前需要基本主体完结,按照理想美术工作也应该在scrum前基本结束,这样每个sprint才能顺利展开。无奈每个sprint都是美术和研发同学一起展开。最后导致的集成时间非常长。
遇到不少问题:
1、人员
“新手”多:几乎不可避免,工作室几乎每天都有人员流动,无论是leader原因还是个人,组内始终有人进组、被调组、或者离职。每次变更就需要讲解一次流程以及工作内容。
因为是新技术、新平台,还需要开发人员熟悉我们的“引擎”开发模式。所以每次scrum内sprint开展都不可避免的需要顺延时间。
2、能力
scurm的开展也融合“瀑布”模式和“迭代”模式,需要有经验的开发人员对每个backlog理解清晰,并且能“正确”评估时间以及分解task。无奈的结果是几乎没有一次理想达到scrum提倡的“每日集成”概念:P。
3、时间
一个sprint结束验收时间基本是sprint开始时预估时间的2倍多(个别项目),即使每天大家都加班很晚才能完成task。
一般sprint都会以二个星期为开发周期,一周集成时间,一周调试和准备下一个sprint的时间。
4、配合
成员都需要时间磨合,产品方案在scrum开始前需要基本主体完结,按照理想美术工作也应该在scrum前基本结束,这样每个sprint才能顺利展开。无奈每个sprint都是美术和研发同学一起展开。最后导致的集成时间非常长。