\

看新闻很累？看技术新闻更累？试试，每天上下班路上听新闻，有趣还有料！

\

CollabNet VersionOne公司发布了。报告中的一些结论表明，对客户和用户满意度的需求日益增加，越来越多的组织正在扩大敏捷性，分布式团队正成为敏捷软件开发的常态，许多组织已经开始或计划在未来的12个月内启动DevOps计划。

InfoQ就第12次敏捷报告的相关问题采访了CollabNet VersionOne的Lee Cunningham。

InfoQ：与之前的报告相比，2018年敏捷报告的主要变化是什么？

\

Lee Cunningham：我们在调查中跟踪的大多数趋势以增量的方式逐年发生变化，其中许多趋势表明，仍然有一些基本面问题有待解决。组织文化就是其中的一个例子。

\

\

不过，今年确实出现了一个重大变化，那就是将客户/用户满意度作为衡量成功程度标志的重要性，无论是在敏捷计划（转型工作本身）还是敏捷项目方面。在过去，我们已经看到了“准时交付”、“质量”和“商业价值”在影响客户满意度因素的排名中都是很靠前的。

\

InfoQ：为什么客户和用户满意度的需求增加了？

\

Cunningham：我认为（我当然希望）大多数人已经意识到，客户是价值流中最重要的实体。如果我们不关注我们的客户，也没有提供他们真正想要的东西，他们就会去别的地方。一旦客户离开了我们，那么我们是否及时提供服务、我们的服务是否有价值、是否出现了bug，这些都不重要了。

\

InfoQ：组织如何应用敏捷来支持这种需求？

\

Cunningham：敏捷宣言的第一条原则告诉我们，客户满意度是最重要的。我认为其他的原则都是用来支撑第一条原则的。所以，我建议组织能够重新审视这些原则，看看他们所做的事情会与这些原则产生怎样的偏差。比如，他们可能会问：“我们所做的变化是为了提升客户的竞争优势吗，还是说我们的优化只是围绕进度和资源管理而展开，但实际上却对变化造成了阻碍？”

\

InfoQ：组织采用敏捷技术的主要期望是什么？

\

Cunningham：今年的调查告诉我们，采用敏捷技术的五大理由是“加速软件交付”、“提高管理优先级的能力”、“提高生产力”、“改善业务和IT之间的协调一致性”以及“提高软件质量”和“提高交付可预测性”。

\

InfoQ：他们是否能够实现这些期望？是否因为采用了敏捷而获益？

\

Cunningham：这5个（其实是6个）期望其实是报告中所提及的能够带来价值的8大项中的一部分。这8大项还包括“项目可见度”和“团队士气”。当然，可见度和士气与其他方面的实施情况有很大关系。所以，似乎大部分受调者已经实现了这几个最受欢迎的期望。然而，我担心的是，那些在可预测性、去风险和质量等方面未做出改善的组织可能在敏捷转型的可持续性上存在问题。根据我的经验，如果问题在这些领域持续存在，那么敏捷转型可能会受到影响。

\

InfoQ：报告指出，扩展敏捷最有用的三个因素是内部敏捷教练、跨团队的一致实践和流程，以及跨团队工具。敏捷宣言一直强调基于过程和工具的个人互动，那么这些与敏捷宣言有什么关系吗？

\

Cunningham：一个常见的场景是，在一个大型组织中，随着时间的推移，形成了多个独立的基层敏捷工作，而每个工作都有不同的规范，并且使用了多种工具。企业希望以协调的方式横跨这些敏捷孤岛，把敏捷力量发挥到极致。到了那个时候，企业必须做出一些决策，确定哪些东西对企业来说是有意义的。那么问题就变成：“我们如何在这些团队中获得所需的实时可见性？”以及“我们如何在整个组织中培养足够的共同性，让我们都朝着同一个方向前进？”只要持续保持实践，工具就能发挥作用。最简单的例子就是Scrum团队与Kanban团队的合作。所有的团队可能被要求度量周期时间，以便为改善常见的系统性因素提供机会。为了做到这一点，领导需要做的是授权，而不是驱动，我们需要能够解释为什么要问那些问题。这就是为什么我认为理解实践背后的原则非常重要。我们需要愿意停下来做一些不起作用的事情。否则，我们可能会发现自己正试图通过流程和工具达成目标，而敏捷宣言并不希望我们这样做。

\

InfoQ：分布式敏捷团队正在成为常态，在79％的受访者当中，就有一些团队在实践敏捷。这将对敏捷的采用和应用产生怎样的影响？

\

Cunningham：我认为，这反映了在现实当中，有很多人在分布式的办公地点工作，也有很多人在旅途中甚至是在家里工作。换句话说，在同一时间点上，并不是每个人都在同一个位置。所以，如果敏捷对我们很重要，那么我们必须弄清楚如何让这种工作方式奏效。协作技术发展得很不错——至少比10年前要好，所以从技术上看，分布式敏捷具有可行性。我们看到一些组织已经实现了分布式敏捷，团队成员分布在不同的地址位置。所以，有可能出现这样的情况：四个团队成员在佛罗里达州，一个在得克萨斯州，另一个在阿拉斯加州。不过，如果团队成员分布在太多不同的时区，那么这种分布方式会相对麻烦。我们也看到了一些团队成功地在一个项目或培训中一起合作，而这些团队在地理上是分散的。我认为，一个组织能否成功地应用跨分布式团队的敏捷性，关键在于他们是否真的是敏捷团队。如果位置X的“Dev”团队要把工作交接给位置Y的“QA”团队，则会出现问题。

\

报告对敏捷技术类型进行了分析：



InfoQ：回顾是团队采用的五大敏捷技术之一。你知道是什么原因导致它有这么高的采用率？

\

Cunningham：我认为这表明了回顾（或适应性检查）是敏捷不可或缺的部分。

\

InfoQ：报告也提到了其他常见的工作区域，如Story映射和Agile/Lean UX。为什么这些技术没有那么高的采用率？

\

Cunningham：我不太确定，但我想说的是，UX仍然是一项非常专业的技能，而且通常多个团队会共用一到两名UX设计师如果缺乏共同工作领域，说明组织文化与敏捷价值相背离。众所周知，企业的设施部门一般不允许员工扰乱已制定好的座位安排。这其实是很糟糕的。我们可以从乐观的角度看待这件事情，因为团队可能是分布式的，成员甚至有可能不在同一大陆。尽管Story映射已经存在了一段时间，但我真的不知道人们是否真的了解它存在的意义。

\

InfoQ：在管理敏捷项目的工具方面，最大的变化是什么？

\

Cunningham：最突出的是看板取代了任务板。任务板仍然排在第三位，但我认为这表示人们正在从任务思维转变到交付思维。

\

InfoQ：71％的组织已经有DevOps计划或预计在未来12个月内启动该计划。他们对DevOps的期望是什么？

\

Cunningham：根据受访者如何看待DevOps计划的成功与否，前三个期望分别是“加快交付速度”、“提高质量”和“增加用户业务价值流量”，而 “提高客户满意度”排在第5个。我发现了一些与报告中提到的有关敏捷计划成功与否的标准不太一样的东西，这可能意味着，当调查对象认为“DevOps成功”时，他们主要考虑的是交付渠道效率，而当他们想到“敏捷成功”时，他们更多考虑的是更大的价值流（交付管道是其中的一部分）。

\

InfoQ：企业采用DevOps的好处是什么？

\

Cunningham：我们在今年的调查中没有提出这个问题，或许明天可以这么做。除了这项调查之外，我可以说，当DevOps被视为“概念到客户”价值流的一部分而不只是“IT价值流”时，DevOps似乎会对商业价值吞吐量产生更大的影响。

\

查看英文原文：