敏捷实施中的管理层支持

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

随着 IT 深深扎根于业务过程，运营企业的每一个人都要知道 IT 会给日常运营带来什么样的变化，这至关重要。高级管理人员可以统观各个筒仓和团队，对整个系统施加影响。IT 经理和高管需要依赖业务经理的积极参与，这样，团队才能高效地工作。管理层承诺仍然是在公司范围内实施敏捷的关键。

“敏捷和DevOps 如何推动数据化就绪和转型”这项研究包含了对高级业务和IT 负责人敏捷和DevOps 实践的调查结果。这项调查是由Freeform Dynamics 为CA Technologies 做的。

对于调查中的问题“为了提高效率，下列每一项的改进优先级有多高？”82% 的受访者赋予“来自所有层面管理人员的更多支持和承诺”中高优先级。

Tony Lock 是 Freeform Dynamics 公司的项目负责人，同时也是一名杰出的分析师。 Ben Carey 是 CA Technologies 公司数字咨询与服务部门的高级主管。InfoQ 就敏捷实施中的管理层支持和承诺对他们进行了采访。

InfoQ：你们研究过敏捷和 DevOps 的结合如何推动数字化就绪和转型。为什么这很重要？

Tony Lock: 我们的调查仍然表明，根据组织报告，不管是敏捷方法，还是 DevOps 实践，它们都可以单独带来好处。同时，调查也反映出，有四分之三的受访者赞成或强烈赞成，敏捷和 DevOps 结合比单独实施更高效。

Ben Carey：受访者在敏捷和 DevOps 结合时看到了更高的价值，这不足为奇。敏捷和 DevOps 结合的真正好处是，让组织更接近推动企业级敏捷和数字化就绪所需的端到端响应性和灵活度。一般来说，术语敏捷和 DevOps 的定义广义上有很大的重叠，它们都需要文化和理念的转变。敏捷侧重于过程，而 DevOps 侧重于技术实践，如 CI、CD 和自动化，从而改进整个价值流的沟通与协作。DevOps 是把敏捷方法付诸实施的最有效的方法，而最终，你需要把两者结合起来向终端用户提供价值。

InfoQ：在这份报告中，有一个结论是“为了提高效率，需要来自所有层面的管理人员的更多支持和承诺”。你们是如何得出这个结论的？

Lock：在整个调查中，82% 的受访者认为“获得来自所有层面的管理人员的更多支持和承诺”具有中高优先级。除了这项研究之外，在和资深 IT 专家交流的过程中，他们都表示，随着 IT 深深扎根于大多数，即使不是全部，业务过程，参与企业运营的每个人都要知道 IT 是如何使用的，它可以为日常运营带来什么变化。没有整个组织管理层的承诺，事情也会变好，也会变化，但不是那么迅速或者高效。

Carey：按照设计，任何层面的管理人员都将对他责任范围内的东西进行优化——他们的部门、职能、业务单位等。获得高层管理者的理解和支持，意味着有人支持上述优化，并且可以跨越那些部分，统观各个筒仓和团队，对整个系统施加影响。

我们已经看到，我们较为高级的客户那里出现了一些领导模式——确切地说，那关乎你如何描述一名“领导者”。通常，我们较为高级的客户主张，谁有能力、权威和资源审查事情的运作方式，推动所需的变革，谁就有领导者头衔，同时也具备在组织中影响变革的能力。另外，我们经常看到给组织中低几个层级的领导者真正的授权。那些领导者管理着一个项目、小组或者部门，他们很懂得如何鼓励与其他小组的同事开展合作，开始通过互相合作打破筒仓。虽然这些领导者实际上领导着专门的小组，但他们也是变革代理人，自下而上推动了敏捷。

InfoQ：谁需要这种支持和承诺，他们为什么需要？

Carey：在许多情况下，激情推动变革的变革代理人会极力争取高管的支持，他们有客户导向的视野，了解如何提高能力，更快地交付价值——但是，他们受限于环境或文化问题，它们不支持变革。这种挑战主要来自于个别小组的领导者，他们无意优化他们那部分业务，在大型组织中尤其如此。我们看到，敏捷实践已经扩展到 IT 组织之外，扩展到了整个价值流，这些倡导者需要说服那些敏捷实施不成熟甚或不被理解的部门的领导者（如运营、市场、HR、财务）。此外，由于这些团队和小组的流程和 KPI 均不相同，这些变革代理人必须找到一种方法，把敏捷的好处翻译成可以引发这些团队共鸣的语言。这里是要让领导者对价值流有个全局的了解，从而支持变革，这是取得更大成果的关键所在。

Lock：IT 是日常业务运营的一部分，它不是一个独立的筒仓。IT 经理和高管们知道，要想他们的团队高效地工作，就需要业务管理人员伴随着事情的快速发展而积极参与。同时，业务管理人员现在期望 IT 能够响应他们的需求，几乎是在他们自己认识到自己有这种需求之前，但是，为了变革可以快速、安全地进行，并尽可能少地中断 IT 和业务运营，交互必须是双向的。

InfoQ：敏捷性更高的公司有同样的问题吗？或者，他们找到了应对措施？他们的做法有什么不一样？

Lock：所有的组织都面临挑战，只是在每家公司呈现出的特征有所不同。根本问题是人与人之间的沟通与协作。调查显示，那些敏捷和 DevOps 实施范围更广、层次更深的受访者，那些 Agility Master，与他们的同行相比，他们有两倍以上的可能成为文化上支持冒险且更具协作性的组织。在他们的公司里，IT 和业务高管也更可能就推动业务发展所需要采取的措施达成一致，并了解到他们的客户需要什么。事实上，结果显示，在整个公司而不是只有 IT 部门实施了敏捷的组织里，Agility Master 更可能有效。

Carey：可以说，冒险和协作是敏捷的同义词。敏捷性更高的公司往往更具协作性，因为他们已经知道，他们需要更多的协作来努力取得成果。他们也冒了更多的风险，因为他们可以更快地失败和学习——经常下小赌注，而不是偶尔下风险较小的大赌注，万一有东西不正常。管理层承诺仍然是关键，不管是在 Agility Master 那里，还是在更为主流的组织中。对于 Agility Master 组织，所需的承诺更多的是战略层面上的，因为那可能会影响整个组织，而不只是一个单独的部门筒仓。

至于常见的挑战，与公司大小或敏捷成熟度无关，我们知道，变革很困难，而且需要时间。尤其是在上千人或上万人的组织里，任何团队的复杂度都被放大了。不断地激励、启发团队，让他们专注于为什么推动变革非常重要。

InfoQ：关于让管理人员参与到敏捷转型，你们有什么建议？

Lock：我开始的时候总是会看一下，“我们现在在哪，我们什么做得好，什么需要快速变革？”我不建议一次性改变所有东西，而是采用一种更敏捷的方法，拟定第一优先事项，解决它们，检查一下是否符合预期，调整，重新开始做。但是，其中一个最重要的要素是，建立起良好的沟通。说明为什么事情在发生变化，它们做了什么调整，每个人对事情的影响。而且要记住，敏捷的核心是一种永不停止的变革过程，小变化，但频繁。那是一个连续循环。总是有东西可以改变，但是不要认为你可以一次性完成。拟定优先级、培训、交流、再讨论。

Carey：我赞成，我要补充的是，你需要能够给参与者展示什么是可能的。向他们展示转型之后存在的可能性，你的企业在采用这些工作方式之后会变成什么样子——那在开始时是一种激励，在整个过程中也可以提醒大家，我们为什么做这项工作。有时候，就是简单地走查已有的流程，比如价值流图，看下有多少浪费掉的时间可以通过压缩产品部署节省下来。还有些时候，是分享其他公司成功采用这些实践的真实案例以及他们取得的成果。通常，如果组织正在寻求转型，那是因为他们有一个令人信服的变革原因——要么是一个新的机会，要么是修复某个有问题的东西。关于组织和流程运转不畅的案例有许多。让团队和管理人员了解这些失败模式以及它们对环境的影响，有助于论证变革原因的正当性。

查看英文原文： Management Support in Agile Adoption