IBM Evan Leybourn谈敏捷约束理论

IBM Agile 敏捷

摘要

Evan Leybourn将在即将到来的敏捷雅加达大会上发表演讲。他向InfoQ介绍了他的敏捷约束理论、方案中的价值定义、敏捷预算和#NoProjects。

正文

InfoQ正在对将在即将到来的敏捷雅加达2017大会上发表演讲的演讲者进行一系列的访谈。其中一位演讲者是Evan Leybourn，他目前在IBM新加坡公司工作。Evan经常在全球各地的敏捷大会上发表演讲。近日，他在纽约组织了业务敏捷性大会。他负责IBM在新加坡的敏捷实践。

InfoQ：Evan，请向我们简要地介绍下您自己？

我总是让自己保持忙碌。截至目前，我在IBM已经工作了将近18个月，并且将继续享受这种挑战——如何让那种规模的一家公司成为一个“敏捷组织”！就个人而言，我认为自己最满意的还是我在纽约创立的业务敏捷性大会。那太棒了。此外，我的第二本书（这本是关于#noproject）就要完成了，我希望在今年年中向出版商提供审查用副本。

InfoQ：过去这些年，您在敏捷社区一直很活跃，您的行程安排让人印象深刻。您觉得在全球范围内敏捷世界有哪三个主要的发展？

虽然我有偏见，但业务敏捷性是第一位的。人们认识到“要”敏捷，组织必须将敏捷融入其整个系统、流程和部门，从HR到财务和PMO。排在第二的应该是作为主要推动因素不断发展的技术敏捷性——从DevOps到CD及其他。最后是，敏捷不再局限于传统的软件组织，成功进入了10年前被认为无法变得敏捷的组织——银行和政府。

InfoQ：是的，您似乎是有偏见，但听上去仍然是一个有价值的行动方案。为什么让整个组织变得敏捷很重要？

我在文章“Evan的敏捷约束理论”中讨论过，这里我应该向Eliyahu Goldratt表示歉意。

“组织的敏捷性取决于其最不敏捷的部门！”

非常简单，约束理论就是说任何过程中都有一个制约因素。更重要的是，总是会有一个制约因素。敏捷约束理论是说，在一个组织内，总是会有一个业务敏捷性制约因素。20年之前，那是IT，是你的软件团队。那就是为什么我们说敏捷在那个领域出现是合乎逻辑的。如今，IT不再是敏捷性的制约因素，现在的制约因素反而是PMO、HR、财务或法律部门。

InfoQ：是这样的，所以是从IT开始实施敏捷，现在可以根据用户的实际需求增量交付更好的软件了。看起来，敏捷性受到PMO的限制，后者仍然按照旧有的方式运作，年度预算，固定的计划周期，采购管理仍然会延缓购买过程，因为老一套程序不够灵活。但是，为什么企业希望改变这一切，为什么他们希望变得“敏捷”？

不只是PMO，还有许多组织的DNA，但你的观点是对的。由于同样的原因，软件30年前变得敏捷了——可预见性的谬误。敏捷组织不能再舒服地认为他们的5年计划是正确的。相反，他们有能力（和管理方法）迭代并适应市场变化。就是反应性，仅此而已，一个敏捷组织也是引领市场的组织。

InfoQ：其中有个主题我没有听到多少解释，就是“定义价值”。产品经理应该根据给用户或客户带来的价值来排定工作的优先级。产品经理该如何做？

这取决于它是否容易量化。在大多数情况下，你无法量化一个特性的财政收益，因此，我们需要使用定性度量。我最喜欢的是价值点。和故事点类似，价值点是一个特性相对于另一个特性的相对价值度量。如果我们想要知道“先做哪个特性”，则价值点可以帮助我们确定。

InfoQ：对于我们这些新手，您能简单地介绍下如何计算故事点或价值点吗？

它们是对复杂度或价值的相对度量。从基准故事（假如我们称之为X，并指定其故事点为1）评估相对的工作量或复杂度。如果Y的难度是X的2倍，则它的故事点为2。如果Z的难度是Y的2倍，则它的故事点为4。价值点的计算方法类似，但由产品经理负责。

InfoQ：如果我们度量一个特性相对于另一个特性的价值，那么我们如何将这个价值转换成业务价值，转换成交付给用户的价值？您有没有什么好的产品示例，产品经理真的是从用户出发排定优先级及定义价值（而不是由团队感知价值）？

首先要理解评估价值和实现价值的差异。这两个数值有天壤之别。但那就是我们为什么要实施敏捷——所以，我们有一个恒定的反馈循环，让我们可以做出相应的调整。一旦产品增量发布，成功做到这一点的组织就对实际的业务价值有了清晰的测量方式并进行主动测量。我将在演讲中介绍的“成果档案（Outcome Profiles）”就是其中一种实现方式。

InfoQ：类似地，组织如何计算敏捷转型的ROI？请您介绍一些跟踪了解敏捷价值的最佳指标？

我认为，这是个不恰当的问题。请先问一下你为什么想要变得敏捷？为此定义一份成果档案（描述、度量标准、基准、目标、依赖项和所有者）。然后，ROI基于具体的成果进行计算。每个组织都不一样。那可以是与质量、人员保持力、市场品牌、客户期望、上市时间甚或（不适当地）速度相关的任何东西。

InfoQ：好的，假如我的企业希望变得敏捷是因为以下三个原因：A.我们希望变得“更像初创企业”，推出更具创新性的产品；B.构建更好的软件（也就是说，传统的瀑布式方法并不能保证提供质量满足预期的软件，所以我们希望改进）；C.提高员工满意度。以我们为例，针对上述目标，您会如何开展计算工作？

只要你能够定义业务成果的度量标准，它就有效。它们可以是直接度量标准，也可以是间接度量标准。例如，对于C.提供员工满意度，你可以通过满意度调查进行直接度量，也可以通过员工流失进行间接度量。

InfoQ：许多大型组织都使用传统的预算和计划周期。我们如何改变预算才能适应成果交付的敏捷方法？

对于这个问题，我只能说对不起了。我没法用一两段话回答这个问题。:-)

可以读一下InfoQ上的文章“超越预算”、Pat Reed的“敏捷账目管理”和我的“#noprojects”。

InfoQ：关于#noprojects，您谈了许多。这对您来说意味着什么，而那对组织而言为什么重要？

对我而言，这很重要，因为“临时性尝试”的每个概念都是违背敏捷性的。对于真正有竞争性的组织而言，他们需要能够提供持续的价值和变化。这里的关键词是持续。由于需求和工作可能会有变化，所以应该不断地分配资源，以便维护、增强和支撑大多数的IT系统。如果处理得当，那么你应该永远都不需要启动一个“升级”项目、一个“版本2”项目、一个“运维”项目、一个“全新”项目或一个“重建”项目。即使是第一次创建的东西，一个革命性的变化，而不是一个渐进式的变化，项目结构也要明确定义边界；一个标志着项目或产品完成的点。更准确地说，应该清楚，每一种产品都是不断地变化和改进的。你可以及早加派人手，但是，借助良好的管理和产能规划，在面对不同的需求时，这是可以做到的。

从根本上讲，这就是#noprojects。这种方法、结构、策略和技术可以成功提供持续的变化。从根本上讲，#noprojects以活动和成果的一致性为基础，以价值来衡量，以指导原则为约束，以持续交付技术为支撑。

我目前正在写一本和这个主题有关的书，幸运的话，再有一两个月应该就可以完成。

InfoQ：下个月，您将在敏捷雅加达大会上发表演讲；您会谈些什么内容？

我将从实用的角度介绍业务敏捷性。从组织设计（敏捷组织如何自我设计？）、转型（如何让1000名员工与敏捷组织的愿景保持一致？）到治理（敏捷组织如何确保完成正确的工作？）和领导力（成为一名敏捷负责人意味着什么？）。

查看英文原文： Evan Leybourn of IBM on the Theory of Agile Constraints