AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

Andreas Schliep 问答:关于 ScALeD——大规模敏捷和精益开发

  • 2015-01-13
  • 本文字数:3267 字

    阅读完需:约 11 分钟

Andreas Schliep 提到,在组织中引入和集成敏捷方法,应该认为是一个敏捷项目,并相应地去对待。ScALeD 的意义是大规模敏捷和精益开发(Scaled Agile and Lean Development),它提供了一系列原则,可以根据它们来检验敏捷方法或框架。Andreas 把 ScALeD 称为“一种参与者驱动的活动,可以帮助企业找到一种合理且平衡的方法来进行敏捷转型,解决大规模的问题”。

Andreas 将会在企业大规模敏捷会议2015 (将于2015 年1 月22 日在比利时布鲁塞尔举办)上发表关于ScALeD 的演讲。这次会议由比利时敏捷联盟发起,UNICOM 主办。InfoQ 将会参加这次会议,采访并发布新闻和文章。

InfoQ 采访了 Andreas,谈到了试图实施大规模敏捷时的陷阱,还讨论了 ScALeD,以及它和 Agility Path、LeSS、SAFe 和 DaD 之间的对比,此外还涉及到持续改进和大规模回顾会议。

InfoQ:在组织试图实施大规模敏捷的时候,会出现一些陷阱,可否请你对其进行一下描述?

Andreas:变得更加敏捷是一种挑战,而且是一项很危险的任务。很多组织都没有意识到这一点。有人听说在其他组织中获得了非常大的成功,所以想要在他们自己的环境中也引入并应用“成功攻略”,然后会很奇怪为什么没有得到想要的结果。这种努力和当年采用精益的历史类似,那时很多公司都试图复制丰田生产系统的实践,但却不知道其中的原则,也就没能获得想要的价值。精益和敏捷不一样,但在本质上却是一致的。缺少理解会导致在自身的环境中不适用,特别是在经常变化的环境形势下。对变化的情境做出快速调整的能力可以叫做敏捷性。如果你采用了这个流行语,但并不了解它的意义,那么任何不稳定的因素都会打破你看上去很美的结构。

一些典型的扩展陷阱都是由于缺少理解和不想变得敏捷造成的,如下:

  • 因为过程而进行角色分配:产品所有者并非真的是产品的所有者。Scrum 教练并不真的是要帮助自组织的团队变得更加成功,而只是项目经理戴了一顶新帽子。
  • 角色“优化”:大规模扩展看起来是一个很好的机会,可以节省“支持性”角色的成本。我们可以让一名 Scrum 教练支持四个团队。我们可以把团队主管和产品所有者的职责合并。
  • 远程控制:大规模扩展经常出现在分布式的工作情境之下。几名 Scrum 教练和产品所有者不会在同一地方和他们的团队一起工作,而是要和位于不同地点的团队协作。尽管这对产品所有者可能还有效,但对于 Scrum 教练和敏捷教练来说,肯定是不行的。
  • 不易变化的职位:某些敏捷方法,像 Scrum,要求组织从本质上改变。这是不可能的,这至少会受到层级关系和不同的职级的阻碍,像企业架构师、高级业务分析师、首席安全专家和项目经理等。
  • 错误的关注点:大规模敏捷或者对敏捷扩展都是可能做到的。但那可能并不是真实问题的解决方案。对很多公司来说,如果降低规模或者重新组织一下开发团队,就会变得好一些。敏捷产品开发是关于构建正确的产品来让客户惊喜的,而不是产出更差劲儿的产品。

InfoQ:在企业大规模敏捷大会上,你会发表关于 ScALeD 的演讲。可否请你简单说明它是什么?

Andreas:首先, ScALeD 即大规模敏捷和精益开发(Scaled Agile and Lean Development)并不是另一种大规模敏捷的框架。我们认为,ScALeD 主要是一种参与者驱动的活动,可以帮助企业找到一种合理且平衡的方法来进行敏捷转型,解决大规模的问题。它受到了精益和敏捷价值观的启发,由原则驱动,并通过各种实践和框架来完成。我们主要的任务是让组织中的人们意识到敏捷性意味着什么。

ScALeD 的核心是十三条原则,分为五大支柱。ScALeD 的支柱或者概要重新组合了主要的精益价值观:

  • 激动的客户
  • 幸福而高效的员工
  • 全员优化
  • 支持性的领导
  • 持续改进

原则来自于精益、敏捷软件开发宣言、Scrum 和系统化思考。不管你的组织生产的是什么,也不管它有多大,对于给定的情境,原则都可以应用。如果你阅读他们的话,会发现其中甚至都没有说太多关于大规模扩展的内容。所以,ScALeD 本身不会告诉你如何处理二十个团队共同开发一个产品的问题。但它可以帮助你确定,你的方法是否支持或者违反了基本原则。

InfoQ:团队和组织可以做些什么来保证,在试图实施大规模敏捷的时候持续改进?

Andreas:敏捷过程依赖于短促的反馈周期。即便你不想要或者不需要产品开发迭代,但我仍然强烈推荐定期进行检查和调整。这一般是通过回顾会议实现的。依据 ScALeD,以及下面将会提到的多种大规模框架,这种改善周期不能仅限于团队级别。把敏捷方法引入和集成到一个组织中,不应该依据计划实施一个框架,而应该认为其本身就是一个敏捷项目,并依此对待它。敏捷组织级开发假设下一次总有机会可以在某些方面做得更好。敏捷组织级开发需要一位负责人以及一位产品所有者,后者会关注并负责变化的规模和频度。它需要一个经常维护、按优先级排序的改善选项的有序 backlog。然后组织级的开发团队会以自组织的形式,解决那些改善方法、问题、事件,并为更好的组织产出产品的增量。

InfoQ:对于大规模敏捷有多种框架,像 Agility Path、LeSS、SAFe 和 DaD。可否请你提出建议,组织可以选择哪个来使用,从而调整和实施大规模敏捷?

Andreas:这些框架中有些从总体看起来非常好! ScALeD 总体上是空白的,但这真的是有原因的。我们建议每个人都要首先理解价值观和原则,然后再看框架和过程。在这些框架中有大量知识和智慧,但它们并不是“可以安装”的即时可用的产品,你可以买过来就能用。正如 George Box 所说:“所有模型都是错的,但有些有用。” 所有这些模型都有用。DaD 很强调软件的质量。SAFe 更适用于传统型组织,它有助于协调不同的组织模型。Agility Path 很强调原则驱动,在持续改善方面更强大。LeSS 和我们的 ScALeD 想法最为接近,Bas Vodde 和 Craig Larman 对 ScALeD 的基础有很大启发。

然而,所有这些模型都面对的是已经敏捷的组织,就像是塑化模型和真正的人体之间的关系。它们可以对其有启发,可以告诉你很多关于结构和解剖学的知识,但如果你对活体器官不了解,那么就无法正确地做事。然而,从另一个方面看,你仍然可以从 SAFe 和其他框架获得很多实践试验以及最初的组织设定方面的知识。我们总结出一些结果,根据他们对 ScALeD 原则的实现状况来对比大规模框架,那可以让你对每个框架的优势和弱点有初步的认识。例如,这个比较结果在持续改善方面会把 Agility Path 放在 DaD 前面,因为 Agility Path 把持续改善作为主要的敏捷转换开发周期,而 DaD 主要在团队级别包含了回顾会议,更依赖于经理和指标。

InfoQ:你对在大规模敏捷环境中使用回顾会议有何建议?

Andreas:对于成功的团队和组织范围内的持续改善来说,回顾会议是核心元素之一。为了更好地使用这种工具,我们需要确保在各个层级拥有技能丰富、训练有素的引导师。仅仅拥有企业敏捷教练、CSC 什么的并不够,他们只是偶尔会和整个产品组织一起执行很好的回顾。Jimdo 是正规回顾会议引导师教育的很好例子。不管特定的过程如何,每个团队都至少有一名成员能够执行回顾会议。团队回顾会议可以为组织级的变更 backlog 提供基础信息。理想状况下,他们会得到整理好的改善故事,以及“组织级的验收测试”。转型或者变更团队可以直接使用它们,对其排序,以获得组织中最好的可能出现的积极影响。

我的愿景是把“行为驱动组织级开发”确立为基本的 PDCA 循环。团队会提出改善建议。建议会在团队代表、利益相关者以及转型团队成员之间讨论。他们都会深刻了解执行项目,并且有清晰的验收测试。变更是由转型团队“创建”的,并给组织演示,以找到新的改善机会。这个循环会花费不超过二到四周。在演示了实现的组织变更之后,转型团队当然也会举行自己的回顾会议。这对于确保工作模型没有变得僵化依然敏捷非常重要。从而可以在组织级的情境中对意料之外的变更做出响应。

Andreas 为想要了解更多大规模敏捷和精益的人推荐了以下阅读链接:

查看英文原文: Q&A with Andreas Schliep on ScALeD – Scaled Agile and Lean Development

2015-01-13 04:381366
用户头像

发布了 340 篇内容, 共 130.1 次阅读, 收获喜欢 13 次。

关注

评论

发布
暂无评论
发现更多内容

设计千万级学生管理系统的考试试卷存储方案

贯通

架构实战营

虽不能至,心向往之|靠谱点评

无量靠谱

低代码/无代码和简单API

YonBuilder低代码开发平台

低代码

学习笔记之:05 | 数组:一秒钟,定义 1000 个变量

Nydia

学习

分布式锁

邱学喆

分布式锁 redis分布式锁 zookeeper分布式锁

梯度下降法 - DAY12

Qien Z.

5月日更 过拟合 梯度下降法

人工智能--野人过河

空城机

Java 算法 5月日更 大学笔记

关于爱情的碎碎念

穿过生命散发芬芳

520单身福利

多线程 VS 多进程(三)

若尘

多线程 Python编程 5月日更

NLog整合Exceptionless

yi念之间

.net core exceptionless nlog

🚄【Redis 干货领域】帮你完全搞定Cluster原理(架构篇)

洛神灬殇

redis redis集群 5月日更 redis架构

内卷是必然

ES_her0

5月日更

可以学习一下安全方面的知识

escray

学习 极客时间 安全 5月日更 安全攻防技能30讲

Node.js使用数据库LevelDB:超高性能kv存储引擎

devpoint

nodejs leveldb

WebContainers介绍:如何在浏览器运行原生的Nodejs

代码先生

大前端 webassembly 技术创新 WebContainers StackBlitz.com

华仔训练营模块4作业

方堃

Flink的分布式缓存

大数据技术指南

flink 5月日更

Docker 镜像和容器

飞跃

Docker 520 单身福利

打破固有思维(十六)

Changing Lin

5月日更

【LeetCode】增长的内存泄露Java题解

Albert

算法 LeetCode 5月日更

.Net Core Excel导入导出神器Npoi.Mapper

yi念之间

C# .net core npoi

架构实战营 模块四作业

netspecial

架构实战营

活性炭能去甲醛吗?

小天同学

科普 5月日更 活性炭

Mac电脑:安装cnpm(补充步骤)

三掌柜

5月日更

分布式锁中的王者方案 - Redisson

悟空聊架构

redis 分布式 分布式锁 redisson

拿金钱考验人性|靠谱点评

无量靠谱

520有感而发

yu

520 单身福利

Docker 入门

飞跃

聊聊一个普通程序员在520这天的心态

后台技术汇

520 单身福利

翻译:谁将在AI中赚钱?by Simon Greenman John 易筋 ARTS 打卡 Week 48

John(易筋)

ARTS 打卡计划

kube-controller-manager之PV Cotroller源码分析

良凯尔

Kubernetes 源码分析 Ceph CSI

Andreas Schliep问答:关于ScALeD——大规模敏捷和精益开发_研发效能_Ben Linders_InfoQ精选文章