Fin Goulding 专访：在普世管理中注入敏捷

近期在伦敦举办的 DevOps 企业峰会上，Aviva 首席国际信息官 Fin Goulding 做演讲介绍了如何在整个组织中使用 Flow 原则推进敏捷能力。InfoQ 采访了 Goulding，就演讲中的一些提法做了深入的探讨。

InfoQ： 您在演讲中提到“低效的离岸外包”。从您的经验看，导致离岸外包策略低效的原因何在？首席信息官及组织应如何正确处理合作伙伴关系难以按预期运作的问题？

Fin Goulding：有太多的企业将其离岸供应商视为一种增加员工的廉价方式。但我认为，该战略存在缺陷。我曾在布宜诺斯艾利斯的一个离岸部门任职多年。目前为止，最成功的团队可具有端到端的交付责任，包括产品所有权和生产部署。但这需要信任、可行的最低限度治理和真正的伙伴关系。组织确实需要找到合适的合作伙伴，让他们有机会证明自己具有端到端的能力，然后再做适当的扩展。

InfoQ：您并未掩饰自己对 Scrum 持不喜欢的态度。对于开始采纳敏捷方法的组织，要投身该领域的变革中并避开那些您认定是 Scrum 设下的陷阱，您有哪些建议？

Goulding：我并非厌恶 Scrum，而只是喜欢抨击它，因为我认为 Scrum 需要做重大的改进，并且很可能需要彻底的改头换面。但我必须坦白，我的妻子就是一位优秀的 Scrum Master 和敏捷教练，我们之间的确做了很多辩论！对我来说，Scrum（在某种程度上，包括 DevOps）的范围太过狭隘，过度专注于技术。实现 Flow 原则将灵活性扩展到业务团队和客户，从而为普世管理注入灵活性。要充分了解 Flow 原则等最新敏捷技术，需要对 Scrum 方法具有切身体验。但我不建议在扩展的框架中扮演（sheep-dig）每个角色，或是自上而下地推动敏捷期望。要实现最优工作方式，我们应支持团队做自管理（self-manage）、协作并改进。在我看来，一位优秀的敏捷教练是物有所值的，但应确保企业雇佣的人具备 Scrum、看板、流程和价值管理等广泛的技能。

InfoQ：在 DevOps 企业峰会上，多位演讲者都提出一家组织应成为学习型组织。但在很多组织看来，很难养成将学习嵌入到日常工作中的习惯。您是否可以给出一些建议，以便组织可以根据这些建议改进组织行为，养成学习的心态。

Goulding：从你自身做起。如果你的团队或同事看到你持续学习，通过 Meetup、以会议或博客写作方式给出各种话题等方法，这将会激励他们亦步亦趋。必须将团队或个人面临的每个问题都视为学习的机会，而不是责备的机会。要做到分享，存在着一些简单的做法，例如在每周站会（stand-up）上提出本周团队所学习的内容。还有一种寓教于乐的方式是帆船回顾会议 (Sailboat retrospective)。它可以解决最棘手的问题，推动学习的机会。

InfoQ：“敏捷已死。敏捷长存” 。读者应如何看待 Ron Jeffries 的文章？

Goulding：对于 Ron、Dave Thomas 以及其它几位敏捷宣言最初发起者撰写的这篇文章，我的解读是他们认为人们失去了指引敏捷方向的北极星。人们不再做到敏捷，而是借助那些缺失持续改进的工具和框架购买敏捷。因此我提到的“敏捷已死”，主要关注的是当前在方法论、职能、工具和领导行为上存在的一些不良方面，并给出使用 Flow 原则开展文化转型的优点所在。其中，Flow 是实现业务敏捷性的最小框架。事实上我总是讲，人们可在 Flow 中使用任何自己喜欢的工具、方法或技术，只要它们能为组织给出有价值、高质量的产出。在我看来，敏捷将摆脱 a 当前的局限后继续存活下去，此外别无选择。

InfoQ：您提到您管理着一个 DevOps 团队。在一些人看来，DevOps 团队是一种反模式，DevOps 应是每位员工的工作。您如何看？

Goulding：我们具有一些使用 DevOps 实践的 Flow 团队，我认为这就是事情的发展方向。大家应该看到，DevOps 现在已经使用了 10 年，其最初的目标是解决开发人员和运维人员间的问题。今天，我们看到 DevOps 扩展为更广泛的业务和技术团队，这就是为什么我更喜欢称之为“Flow 团队”，而不使用 DevOps 或 DevOps 2.0。我完全相信，这样的整体团队将成为未来最成功企业的核心。

InfoQ：许多组织在获取正确度量（甚至是任一度量）上步履维艰。您在演讲中提到你只关注交付时间（Lead Time）和循环时间，该结论是如何得出论的？如何使这些度量可见、可分享并可用？

Goulding：有一些度量为我提供了能直接改进之处，但也有一些度量所展示的问题是我无法直接改进的（例如转换率、NPS 或利润），所以我聚焦于其中一小部分关键度量。但在生产力目标的驱使下，一些度量会对团队造成打击，甚至更糟的是会影响到每个人。我一直关注的如何是确保工作项或 Story 具有统一的规模，进而易于确定工作流中存在的问题并加以改进。或许是某位团队新成员需要得到帮助，或许是某个 Sotry 过于复杂而需要做简化。而交付时间和循环时间可突出体现这些问题。在本次峰会的演讲中，我也着重提及了等待时间。该度量最好地衡量了生产力情况，时常能表明存在着过度的场景切换问题。我认为开发和运维间的等待时间，就是推行 DevOps 的一个驱动力。

InfoQ：如果人们觉得领导者并不了解 DevOps，并且没有表现出他们在 DevOps 领域中的期待行为（例如，剔除碍手碍脚者），那么人们应该怎么做？

Goulding：要了解高绩效组织的做事方式，Puppet Labs 发布的 DevOps 状态报告（State of DevOps）是一个非常强大的信息来源。我建议大家和领导者共同分享所有来自类似组织的报告实例。此外，不能表达任何商业价值的技术术语，的确会阻碍对 DevOps 的采纳。大多数领导者并不愿意承认他们在某些事情上缺乏理解。因此要得到领导者的支持，最好是帮助他们去理解这些事情。但是要做好准备，成功实施的全部荣誉都应归功于领导者！因此在实施 DevOps 过程中，应邀请领导者参加每周站会（stand-up），并让他们直接去处理那些碍手碍脚者。

InfoQ：您在演讲中提及“梳型技能”员工。您认为这类员工是否常见？是否每位员工都能成为“梳形技能”人才？

译者注：下图表示了“T 型技能”（T-Shaped）、“π型技能”（Pi-Shaped）和“梳型技能”（Comb-Shaped）。 

Goulding：多年来，我一直在推动一种我称之为“HR 2.0”的方式，并与许多 HR 专业人士探讨过“T 型技能”、“π型技能”和“梳型技能”。从技术领域看，很多人可以设计、编码、构建数据库，并测试和部署应用，所以我很疑惑，为什么每种技能都会演变为一种单独的工作职能？在许多企业中，技能已经成为划分工作职责的一种方式，或许不少企业正试图扩大这种做法。但我认为，诸如零工经济（Gig Economy）等新方式的出现，人们将得以摆脱单一技能的束缚，采用多种交易方式生活。要是能与 DevOps 2.0 或 Flow Teams（将 DevOps 扩展到更广泛的业务和技术团队中）相结合，那么人们将可成长为最有价值的人才。设想一下，如果企业家支持员工在传统的工作职责之外谋求发展，那么企业自身就可以培养“梳型技能”人才。

在任 Aviva 国际首席信息官之余，Fin Goulding 还合著了多本专业书籍，包括《Flow——改革者、独行侠、创新人士和领导者的手册》（“ Flow - A Handbook for Change Makers, Mavericks, Innovation Activists and Leaders ”）、《Flow 的 12 个步骤——业务敏捷的新框架》（“ 12 Steps to Flow: The New Framework for Business Agility ”）和《从 DevOps 到工作流——创建赢得未来的团队》（“ From DevOps to Flow: Creating Teams That Win the Future ”）。

查看英文原文：  Fin Goulding Injects Agility Into the Management of Everything