从敏捷宣言诞生二十年来，敏捷开发方法越来越被企业组织所认同并持续发展。SCRUM作为一种轻量级的，清晰的敏捷框架，在企业组织的敏捷转型过程中，往往会成为大家优选的方法。
但是，纵观企业的敏捷转型效果，很多组织往往事倍功半，中途夭折者更是数不胜数。为什么企业组织的敏捷转型会这么难？
今天，拿SCRUM框架的实施为例，和大家分享一下在SCRUM实施中，经常会误踩的一些坑以及应对措施，希望大家能够有所启迪。
坑1：迭代周期，随心所变
大家对于SCRUM的第一印象，往往就是“敏捷迭代开发”。但是在SCRUM的具体实施中，尤其是一些新手Scrum Master，误踩的第一个坑往往就是“迭代周期，随心所变”。具体表现有哪些呢？
首先呢，团队也定义了一些迭代周期，但是有些时候，当碰到计划任务比较多，在迭代结束时还完成不了时：“迭代差一天就结束了，可是还有2个需求没启动呢，怎么办”？管理者眉头一皱，哦，那迭代再延长两天吧。
诸如此类，迭代周期没有固定，而是按照管理者的意志随意变换。可能在管理者的意识里，开发周期不就延长一点吗？有什么大不了!
嗯，如果有了这种想法，那么，很遗憾，这种方式已经触碰了SCRUM的底线！
为什么呢？我们知道，SCRUM是一种基于固定迭代（SCRUM中，称为sprint）周期的敏捷开发框架。时间盒是它的一个基础概念。
“时间盒”，时间是不可见的，盒子是可见的，在SCRUM中，用时间盒这个概念对开发中的事件进行了有效管理。
比如，每日站会，SCRUM建议是控制在15分钟内，迭代计划会、回顾会根据迭代周期可以设定对应的时间盒长度，比如，2周的迭代周期建议设定在2个小时。
那么，为什么SCRUM会有时间盒的概念和要求呢？我们来看Sprint的中文翻译“冲刺”。SCRUM认为或者期望，每一次迭代周期，团队都是在进行一次冲刺，从而实现迭代交付。
那么为什么迭代周期要固定呢？因为要保持节奏感。只有保持了节奏感，团队成员的工作状态才能保持在一个较佳的水平上，而保持了节奏感，团队也容易与外部组织更好地进行协同。
所以，怎样防止第一个坑：迭代周期，随心所变。很简单，一旦设定了迭代周期，要尽量固定。当然，不是说一旦设定了周期，就无论如何都不能更改，敏捷崇尚拥抱变化，迭代周期也可以变化，但是不要随意更改。
坑2：迭代没有交付
我们在一些实施SCRUM的团队中，当迭代结束总结回顾时，经常会发现这样一种现象：某某需求，本迭代完成了70%；某某需求，本迭代完成了95%，诸如此类，不一而足。
我们在谈论敏捷开发方法的优势时，经常会和传统的瀑布方法作比较。下图是一个明显的对比，大家看到下图都会侃侃而谈SCRUM迭代开发相对瀑布开发的优势。
图 SCRUM迭代开发与瀑布开发的对比
SCRUM框架相对瀑布开发的一个巨大的优势就是在于，它把漫长的产研周期迭代化切割，同时，要求在每个迭代周期，都有一定的交付产出，这在SCRUM中称为迭代增量式交付。通过每个迭代的定期交付，团队第一能够快速产出，第二能够快速获得用户的反馈，从而调整后续的工作计划。所以，迭代交付具有重大的价值，无论对于用户还是团队。
当一个迭代结束时，所有进行中的需求工作，对于团队而言都是0。因为没有实现交付，没有产生价值。
所以对于团队，当需求较多时，应该“聚焦完成，停止启动”，应该聚焦于迭代完成，能够实现完成哪些高优先级需求。
在这里，给大家一个建议：将产品版本与迭代进行匹配。
首先，从产品层面，定义若干产品版本。
其次，产品版本和迭代进行适配。
这样，我们就把产品和研发迭代进行了有效的连接。
每个迭代的产出目标，也有了更加清晰的指向。
