更敏捷之旅

baby00 2014-03-20

在看了一些scrum电子书之后,我开始尝试在团队内部推广这种敏捷方法。开始能采纳的也是小范围的动作,毕竟开始不知道如何走,没法把所有的流程一下子全部改掉。站会,scrum白板是我们主要的执行手段。可是,经过了一个月,我们发现站会用掉了我们非常多的时间,非常没有效率。于是,我们停止了敏捷的脚步。

过了半年,情况发生了变化,公司总部开始推广scrum方法,我这里很幸运的接受了两次培训。通过两次培训,从领导到团队成员,都有了敏捷的概念,有了统一的认识,都认真的按照敏捷的方法去操作。

经过了1年半的scrum运行,我们每2周发布一次,对于BU的角度来看,我们每次release都能出不少东西,效率上面跟其他的研发团队相比很是不错。在公司总部,我们是scrum成功运行的标杆,我们是很值得信任的。

 敏捷成了!且慢,在实际运行中,我们还是发现有很多不完善的地方。

首先,产品需求可不是定期来的。每个sprint当中都会有紧急task要求在短时间上线的情形。而且由于BU人员变动,需求文档质量一直不高,很多问题需要边开发边沟通需求。这样很多任务做做停停,需要拖延很长时间才能完成。紧急任务,大任务,这些都不是scrum标准的处理情形。我们又不愿意花费太多的时间在任务分解上面,该怎么办。。。

其次,scrum只规定了管理上面的一些process,但是对于研发流程本身没有任何的规定。我们准备补充design review, code review,但是该如何落实呢?我们只能开会的时候强调,再强调。。。

第三,scrum关于任务的估算是一个问题。我们按照故事点,团队打扑克的方式来定。但是以前团队成员和任务变化大,始终无法计算准确的开发速率。现在终于每个sprint故事点数保持恒定了,但是由于分解不细致,经常有任务跨sprint。我们无法拒绝紧急任务,那我们该如何衡量我们的生产效率呢?

第四,scrum在定义DoD上面,我们认为是QA tested。但是产品上线经常也要花费不少精力。这些没法体现。

为了尝试解决上面的问题,我们开始了更深入的敏捷之旅。

相关推荐