BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Bas Vodde的问与答 — Less框架:原则、实践及核心思想

| 作者 Savita Pahuja 关注 3 他的粉丝 ,译者 李清玉 关注 0 他的粉丝 发布于 2015年12月23日. 估计阅读时间: 12 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

Bas Vodde 和Craig Larman 设计并介绍了 大规模Scrum(Large Scale Scrum (LeSS)))),一种规模化模型。

大规模Scrum也是Scrum,适用于多个团队工作在同一个产品线上的情况。

LeSS不仅仅只是一系列的原则与试验。它还提供了附有规则的框架。LeSS 规则定义了LeSS是什么(以及不是什么),并且提供了应用LeSS的具体框架。有了LeSS框架,产品团队可以应用这些经验,并找到在特定时期最适合他们的方法。

LeSS提供了两种规模Scrum的框架:

  • LeSS:最多至8个团队(每个团队不超过8个人)
  • LeSS 巨型(LeSS Huge):同一产品线多达几千人。

InfoQ采访了Bas,并谈论了 LeSS和LeSS 巨型。

InfoQ:您可否为读者介绍一下LeSS

Bas:LeSS是一款产品开发的框架,用于两个以上团队构建同一产品的情况。框架是基于Scrum 规则,并为建立多团队的Scrum做了扩展。

扩展规则包括:

  1. 解释了多团队如何进行Scrum活动。
  2. 主要增添了有关产品开发组的结构(我们使用“产品开发组”表示构建产品的组织或者部门)。

规则之后,我们定义了十大LeSS原则。

原则有三种:

  1. 基于Scrum的原则,例如透明原则或经验过程控制。
  2. Meta原则,例如精益思想和系统思考,以及
  3. LeSS所特有的原则,例如关注整个产品以及以客户为中心。

LeSS还有大约50条指南,大多是解释在组织中如何应用LeSS框架以及需要什么类型的改变。

LeSS的最后一部分是LeSS试验,大约有600条,这些都是在规模化敏捷开发时可以尝试或避免的。

InfoQLeSS的核心思想是什么?

Bas它的实质是,LeSS试图忠于 敏捷宣言和Scrum,解决同一产品线上多个团队如何一起合作的问题。

在创立敏捷宣言的时候,敏捷宣言的共创者,Jim Highsmith杜撰了“刚刚足够的方法论(Barely Sufficient Methodology)”这一短语,它同样也适用于LeSS。现实的情况是,持续改进需要组织的所有人参与,你需要让团队拥有他们的流程。这就意味着摒弃计划与工作分开的科学管理理念。它还意味着放弃强大的、由科学管理理念演化过来的项目管理理念。

另外,我们想要管理产品是按照产品而非项目来管理。这样就会导致永久性的、长期性的团队一直拥有自己的工作并持续地改进。多个角色、工件、流程以及层次所带来的影响是团队并没有控制流程,而是流程控制了团队……在LeSS框架中,我们不想有更多,而是拥有少的角色少的工件,以及少的流程。这些内容的减少意味着更多的自主权、创新、改进和更多的目的。我们把这个原则称之为不只是LeSSMore With LeSS

InfoQ: 将精益思想和系统思考整合在LeSS框架的原则中 ,其目的是什么?

Bas: 嗯, 精益思想系统思考都深深地影响了我和Craig。我想让参与LeSS的所有人都知道这两个思考工具,他们阐明了LeSS是如何工作的并有助于你解决开发中的实际问题。

在过去,精益思想和系统思考都是“思考工具”的一部分,我们在第一本书《精益和敏捷开发大型应用指南》有描述过。当我们把它反映在LeSS原则上时,它贯穿我们的思想从而实现真正的原则,例如“全局优化”和“相互尊重”,但我们不这样做,而是保留他们现在的样子,只称他们为原则(然而他们更侧重于思考框架)。

如果你想学习有关更多“原则”的内容,我可以推荐自认为有价值的一些素材。对于精益思考,有很多现成的材料,但并不都是好的。我通常推荐寻找更贴近丰田起源的内容而非解释性的东西。通常来讲,Liker 和 Ohno的著作不会错。我特别喜欢Ohno编写的有关丰田生产的过程(Toyota Production Process),书名为《车间管理(Workplace Management)》。对于系统思考,Peter Senge 的著作永远不会过时。对于系统思考的其他应用,可以查看一下John Seddon或者Gerald Weinberg的书,Gerald Weinberg正在编写针对软件开发的系统思考应用的书籍。

InfoQLeSS框架有两个版本——LeSSLeSS 巨型。这两个版本有什么区别?

Bas对的,LeSS或者说基本的LeSS框架是针对2到8个团队,而LeSS 巨型框架则是针对8个以上团队的。LeSS 巨型是LeSS的扩展,是针对大型产品开发的。LeSS包含2页的规则,而LeSS 巨型则又多一页的附加内容。

有两个框架的原因是,当超过8个团队时,你需要一些额外的规模化技术,帮助产品负责人及产品待办目录的规模化。然而,如果你没有8个以上的团队,这些辅助的技术并不需要。他们只会让你的开发更加复杂。如果把它们应用在小的LeSS实施中,还会带来负面的影响。为了更加清晰,我们决定把框架分成LeSS和LeSS 巨型。你可以认为LeSS 巨型是多个LeSS堆叠在一起。

InfoQ:“LeSS就是扩展Scrum本身,目的是精简组织。”LeSS是如何做到的?

Bas当采用了LeSS,它就会影响到组织的结构。通常发生的是,组织问题是通过传统的、复杂的方式解决的。而在LeSS中则比较简单。每一个迭代都有小批量的可工作软件,这就移除了组织的复杂性,这些复杂性是在传统的开发方式中为了应对缺乏透明度而产生的,最好用一些例子来解释这一点。

传统上,组织使用项目来管理工作。一个项目,用敏捷/精益的视角来看,就是管理大批需求上线的一种方式。当关注在产品及持续为用户发布价值时,用项目的方式管理工作就变得很过时。而通过产品周期中的产品待办目录来管理小批量的工作则更加简单。投资人还可以基于预计与实现的客户价值来投资(预算)产品。因此,好的LeSS组织就通过移除项目和项目管理,通过不同方式解决管理工作的组织问题,从而精简了组织。

进一步,大型组织在同一大型产品内通常都有不同项目的项目组合。当把一个项目考虑成一大批需求,项目组合管理就意味着大批需求的优先级。这不是我们想要的。因此,取而代之的是,我们考虑产品的定义是可扩展的,而且倾向于广泛的,这样产品待办目录就扮演了项目组合中的类似角色,但它是简单的、细颗粒度的优先级。

InfoQLeSS也强调了技术卓越。它有多重要以及好处是什么?

Bas没有这个,你的开发很可能会失败。

Craig和我用“组织的敏捷性总是受制于技术敏捷性”来表达这一点。如果代码库没有灵活性,组织就不可能灵活,换句话说,如果你的代码一团糟,你就会慢。

我们认为,很少有组织认识到技术实践的重要性。大多数都是在口头上说说而已。当深入到代码库(这是我们最喜欢的事情之一),你在最“敏捷”的开发组内也会有惊奇地发现。如果代码一团糟、很多复制的内容、缺乏领域抽象以及没有自动化测试,那么代码改动就很痛苦,不管你怎么组织开发工作,都是不灵活的。

InfoQ:您可否谈一下您即将面世的书籍?

Bas好吧,我希望它再也不是即将到来。我们一开始认为这本书是一个小的项目,但实际上它变成了怪兽项目。不管怎样,这本书的名称是《Large-Scale Scrum: More with LeSS》,它描述了有助于实施LeSS 的一些LeSS规则和LeSS指南。与前两本书相比,它更加容易阅读,更加规范。它应该已经出版了,但实际要到2016年初才会出版。

再多分享一下这本书,这本书分成三个部分:1)结构,2)产品,3)Sprint。结构的部分讲述了产品组的设计、管理的角色和Scrum Master,以及实施。产品部分讲述了产品待办目录、产品负责人、产品目录修整以及完成定义。Sprint 的部分涵盖了Sprint规划会议、评审和回顾会议以及协调与整合。

InfoQ:请分享一些有关LeSS培训的信息。

Bas是啊,你参加了。我希望你喜欢!

我和Craig创建了两种认证培训,我们认为Certified LeSS Practitioner是主要的一个。这是为期3天的课程,深入介绍LeSS以及组织实施LeSS。之后,参与者就是认证的 LeSS Practitioner,并且会在less.works 网站上收到一个账号,这个网站列出了所有LeSS的内容。

我们正在建立一个培训网络,全世界各地都会有培训。

如果你感兴趣,可以在网站上看我们的课程安排。

InfoQ:对想要实施LeSS的组织有什么建议吗

Bas如果你想想寻求一种简单的改变,容易地实施以及提供快速的修复开发问题…请不要采用 LeSS。如果你对开发中长期改善的,而往往又不易控制的方法感兴趣,LeSS对你的组织正合适。

严肃的说,LeSS解决一些组织的结构问题会有显著的改进,但却并不容易。必须持久并且保持学习。

InfoQ 今年早期发布了一些文章。LeSS介绍Bas Vodde 谈LeSS框架 以及 功能性团队使用LeSS,每个迭代交付你的产品

如果你想了解更多有关LeSS的实施,请参考LeSS案例研究

关于受访者

Bas Vodde对敏捷方法,特别是Scrum指导工作有着丰富的经验,他也是Scrum Master认证培训师。Scrum之外,他也培训和指导团队的测试驱动开发(TDD)、回顾和敏捷计划等工作。他来自与荷兰,曾居住在中国、芬兰,目前居住在新加坡。在上世纪90年代,他曾作为一名开发人员在荷兰工作,他感觉到工作经验与“官方说你应该做什么”不符合。随着极限编程和其他常规的敏捷开发的引入,问题随之而解。在2001年初 ,他有了足够的“正常生活”,移居到了中国,开始在诺基亚工作。在那里,他获得了超大项目以及他们运行的传统方式的经历。经历这之后,他更加确信敏捷开发是正确的前进方向,并且适用于所有大小的项目。目前,他创建了自己的一家小型的、名为Odd-e的顾问咨询公司。

查看英文原文:Q&A with Bas Vodde on the LeSS Framework: Principles, Practices and Core Concepts

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT