更敏捷之旅

在看了一些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。但是产品上线经常也要花费不少精力。这些没法体现。

 

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