案例解析:你团队的迭代周期该如何设定?
您目前处于:敏捷  2017年07月02日

很多Scrum团队一开始不知道迭代周期设定多长合适。Scrum要求Sprint在1周到1个月以内的周期,而且一旦选定,Sprint的长度在整个开发过程中保持一致。新的Sprint在上一个Sprint完成之后立即开始。那么到底多长合适呢?

初始设定方法

首先,应该选择以周为单位,即:1周,2周,3周,4周,而不是以天为单位,e.g. 7天,12天,22天等。道理很简单,以周为单位方便管理和沟通。以天为单位,大家还得打开日历数天数。这种事务性管理的成本越低越好。

其次,对于每个独立交付产品的团队,自己定义Sprint的长度,不要整个公司或部门一刀切;对于一个项目有多个团队协同交付产品的情况,大家保持一个Sprint长度,方便跨团队计划和交付节奏对齐。此外,这样的大项目交付的情况里,每个团队有共同的语言,不至于你说的Sprint1是我团队的Sprint2。

再次,选择两周长度的Sprint启动,进行了1个Sprint后, 团队在回顾中讨论,Sprint长度是否合理,是否需要短一些,或者长一些。现在大部分团队的Sprint长度都是两周。为什么要选定两周的长度开始呢?下表列出了不同长度的Sprint的对比:

Sprint不同长度的对比

从上图可以看出,不同的Sprint长度,没有绝对的好或坏。两周Sprint的长度,各个维度处于居中的程度,因此,不必太过于纠结,可以从两周的长度开始,当团队发现一些问题的时候再调整。对于大部分团队,一个Sprint运转后,没有发现需要调整过。

调整迭代实操方法

案例1

某公司刚开展敏捷转型的时候,给每个团队一刀切定为两周。很快在一些团队遇到问题。

一个做互联网产品的团队,每次Sprint进行到中间的时候,经常出现更加紧急业务需求,而把原来规划的需求挤掉。团队跟产品负责人沟通,拒绝Sprint中间调整需求,导致团队与产品负责人关系变得紧张。

这个时候,Scrum master应该与产品负责人分析,这种情况发生的原因是什么。是由于产品负责人的工作没有做好,在Sprint启动前没有准备好需求,到了Sprint执行期间才临时发现需求?还是因为业务变化频繁,两周的Sprint偏长,产品负责人无法提前两周预见需求?如果是业务变化确实比Sprint频繁,可以考虑缩短Sprint周期。但是,要确定这种频繁的业务变化是常态。如果只是临时出现的情况,不需要调整Sprint的长度。

另一个做To B移动端App的团队也发现了问题。他们的移动端发布周期是三周一次,导致他们的Sprint周期与发布周期错位。每次Sprint结束的时候,产品不具备条件发布;而发布的时候,正式下一个Sprint的中期。团队与产品负责人商议,是否需要让发布周期更频繁,而产品负责人认为,对于他们的客户,三周的发布周期完全满足客户的期望,过于频繁反而增加客户的更新成本。因此,团队决定,调整Sprint的周期为三周,Sprint的结束的时候正式发布的时候。

此外,Sprint的长度也取决于团队的工程能力基础。对于那些没有任何自动化集成、自动化测试、自动化部署的“三无”团队,从瀑布转为两周的迭代周期,往往会发现迭代时间结束的时候,产品不具备可交付状态。在这样的情况下,迭代周期是否需要调整呢?

有两个选择:

a. 延长迭代周期至3周-4周的长度,在每个迭代计划的时候,将工程能力提升任务纳入Sprint Backlog, 确保每个迭代在交付特性的同时也对工程能力有投资。但是要记住,过了一段时间在工程能力有所提升之后,团队再次回顾迭代周期是否可以缩短。

b. 迭代周期不变,调整DoD(完成的定义),修改为在目前的迭代周期长度下,产品可以达到的程度。要小心的是,采取这个选择必然造成下个迭代在补上个迭代遗留的功课。

案例2:

某大型SaaS互联网软件产品由多个团队协作交付。在两周的迭代周期内,整个产品只能完成特性验证和基本回归验证,如果做全面的回归验证需要再花一周的时间。团队决定修改DoD的条件为:

a. 特性验证通过

b.系统级基本回归验证通过。

但是达到了这个DoD条件还不能发版。团队将系统级全回归验证放到了下一个迭代,在验证通过后发版,因此发版周期错后迭代一周时间。团队将如何缩短验证周期作为改进专项规划。需要注意的是,很多时候,貌似看起来测试周期长是测试的问题,究其根本原因是架构和代码的问题。团队每个迭代做一部分改进工作,直至一个迭代内可以达到发版条件。

由此可见,不管如何抉择,比迭代周期的初始设定更重要的,是团队在遇见问题后思考如何改进,并切实将改进任务纳入到每个迭代中去实施,逐步提升敏捷成熟度,达到迭代结束时产品具备可交付的状态。

不是一定要迭代到永远

迭代不是永远要有的。随着团队的敏捷成熟度的提升,当团队能够每天按需发布,甚至每天可以多次发布,即达到流式开发、持续交付的程度,那时候就可以抛弃迭代周期的约束,而迭代周期只作为团队计划的节奏,不再作为交付的节奏。


转载请并标注: “本文转载自 linkedkeeper.com (文/王明兰)”