改善敏捷实施_Scrum_Ben Linders



 写点什么

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

Scrum.org 的 CEO 和首席产品负责人 Dave West 认为：我们应当使用敏捷的方式去实施敏捷，而不是利用瀑布模型去实施敏捷，同时，我们要有愿意授权给团队的并建立一个支持他们的组织领导者。这个行业需要更多的实践来逐步实现敏捷性。

InfoQ 采访了 West，了解有关敏捷的实施、Scrum Studio 的应用、业界能够做些什么来增加对敏捷方式的理解、业界应该停止做什么、未来会给敏捷带来什么等内容。

InfoQ：请问，您如何看待敏捷的实施？

Dave West：问卷调查可能会显示大多数的项目或产品是敏捷的，但那些数据并不完整。敏捷正在被实施，但是，对很多人来说，它是采用瀑布模型的机械式敏捷实践。冲刺实际上只是瀑布模型中的一块。日常 Scrum 是状态汇报会议。产品负责人实际上是订单接收者，而不是下订单的人，同时，软件仍然是不定期地发布。

敏捷团队所处的工作环境变化一直很缓慢，由此，任何敏捷实施都会受到组织现有的文化和规范的破坏。但是，情况正在发生变化。其中有一些是因为如持续交付（Continuous Delivery）、PaaS、基础架构作为代码和其他授权技术的变化。通过对 Scrum 和敏捷方式更好的理解，另外一些变化正在实现。可以将其视作敏捷的成长。未来的敏捷团队将不只是打打钩，做表面文章，而是“成为”敏捷。

InfoQ：敏捷文化和 IT 企业中的“传统”文化有什么不同？

West：那可能需要有个单独的采访：）但是，如果我把重点放在巨大的差异上，那就是：

层级倒置：你不是为老板服务，而是老板为你服务来追求客户 / 价值。

更注重于成果和学习，而不是行动及风险。

计划允许有意外情况并且有应对方案。

一切都以频繁交付的东西为基础。这意味着要把事情分割成可以测量的小块。

团队是自我指导和自组织的。

信任团队取代信任流程。

我认为所有这些都源于经验主义和精益思想的基本概念。这两种想法看似简单，也不是什么重大变革，但是它们似乎改变了一切。

荷兰的一家养老金和投资管理公司分享了其在 Scrum Studio 采用敏捷原则的经验。他们在其组织中建立了一个独立部门，负责为客户提供端到端的业务价值：

我们的工作室（Studio）目前有三个团队，包括了产品经理、网络营销人员、内容创建者、网络编辑、社区管理者、数字架构师和技术专家。每个团队负责设立自己的目标，但也要和其他团队及工作室的目标联系起来，成为一个整体。

我们以 scrum Master 和产品负责人的角色使用 Scrum，但是产品负责人的职责根据专业知识部分授权给团队成员。我们迭代开发、部署和测试 MVP 的东西，比如一个新的抵押产品或我们的新 App，然后搜集所有的反馈和可测量数据以支持进一步的决策。

InfoQ：改变文化和实施敏捷有不同的方法，其中之一是 Scrum Studio。它是什么？如何工作的？

West：在传统的组织中很难实施 Scrum。试想一下，你试图频繁地交付工作软件、定期地计划，甚至建立一个自组织的团队，而你所在的公司却是根据任务计划工作、不经常交付以消除风险，并且试图避免做计划，因为那样做，太痛苦了。想象一下，在失去客户信任的组织内做 Scrum 吧。是的，这正是存在这么多 Scrum 团队的原因。尽管周围的环境如此不堪，那些 Scrum 团队还是生存了下来。

Scrum Studio 所引进的是来自其方法的根本性突破。与其试图重塑 Scrum 以支持一个不是为解决复杂问题而建立的组织，不如创建一个为 Scrum 而建的新组织。这和 John Kotter 在他最近关于企业变革的工作中提到的观点非常类似，这个观点可以从其《 Accelerate: Building Strategic Agility for a Faster Moving World 》一书中找到。

它有三个层面：

它为敏捷的蓬勃发展提供了实用的东西，包含技术基础设施、培训等。

它将显示组织对这一改变的承诺程度。这将不仅需要一些预算，更重要的是高管们为之付出的时间。

至少一开始，它将包括那些问题和适应敏捷方法的人员。

我们正越来越多地看到像 Scrum Studio 这样的东西出现在数字领域。这些基于 Scrum 的 Scrum Studio 也结合了很多设计思维（Design Thinking，客户是谁和他们想要什么）、精益创业（Lean Startup，我们是否能解决他们的问题，然后进行扩展）和敏捷交付。

有了这些数字 /Scrum Studio 我们所看到的是组织中的其他部门慢慢地改变以支持他们。我们开始看到财务、人力资源和其他业务部门能适应更好地服务这些以客户为中心、敏捷的企业。具有讽刺意味的是，很多这样的工作室是由业务驱动的，因为他们试图变得更有竞争力，但是对他们的最大挑战之一是现有的 IT 组织。也许通过实施 Scrum，能有助于建立这些团队之间的联盟，让敏捷变得不只事关 IT，而是一项商业计划。

InfoQ：为了增加对敏捷方法的理解，业界可以做些什么？

West：过去 22 年以来，我们一直试图让 Scrum 回归。但是，直到今天，我们得到的还是：“哦，Scrum 只是开发”和“我们实行 Scrum，因为我们每天会聚在一起开个站立会”。但我们正在看到改变。我们越来越多地看到人们“理解了它”；然而，这些人身处那些不实行 Scrum 的组织中。因此，我认为我们需要和管理人员更好地合作，帮助他们理解自身在变革中的角色。在 Scrum.org 中，那是创建专业敏捷领导（Professional Agile Leadership）阶层的部分动机，并且利用了像数字（Digital）这样的业务需求为价值提供了背景。当然，真正理解了的管理人员的例子有很多。有像 Spotify、Fitbit 和 Tesla 这样的新兴公司，也有像 ING、GE 和 KLM 这样的传统企业。在 IT 行业之外，还有一些有意思的经验，像 Ghana Police Force 实施 Scrum 以更好地为其国民服务。所有这些成功的企业都有愿意给团队授权并建立一个支持他们的组织的领导者。可惜的是，还不是全部都这么做。

我们说了太长时间的“敏捷太棒了，但是你们太蠢而做不到”。或者利用敏捷去打磨我们特定的工具，比如技术债务，或者更好的测试实践。相反，我们需要把敏捷和敏捷如何提高公司交付客户价值的能力及利用精益创业、设计思维联系起来。

InfoQ：是否也存在阻碍敏捷实施的因素？业界应该停止去做的事情？

West：我看到太多组织利用瀑布模型实施敏捷。意图很好，所有的都做得很到位，但是重点是在实施敏捷的举动而不是成果和价值。与其用瀑布模型实施敏捷，不如使用敏捷方法。注重价值，和客户建立联系，通过透明度进行检查和调整。

只要专注于敏捷价值观，你会发现实施容易得多。当然，还是有难度的，它会提出很多关于组织的难题，但至少，你会逐渐提供价值。我们也开始看到有组织这样做。例如，Ghana Police Force 没有时间或预算采用瀑布模型的敏捷性。相反，他们通过团队实施把重点放在团队上，并慢慢改变支持组织以便更好地为他们服务。

重要的是，我们业界开始越来越多地谈及实施问题。随着逐渐实现敏捷性，增加更多的实践。例如，利用 Scrum 在那些你为了实施增加采购积压、驱动变革且有愿景的产品负责人、让其流动起来的 Scrum Master 的地方实施 Scrum。这让我想起爱立信的敏捷实施，他们使用了敏捷来实施敏捷，并产生了相当令人兴奋的结果。

InfoQ：您认为未来会给敏捷带来什么？

West：考虑到我们是敏捷的，很难回答这个问题。未来充满可能改变一切的未知数。但是，我确实认为，敏捷性会得以延续。我也许有偏见：），但是我认为类似 Scrum 的方法会成为每个从事复杂工作的团队的基础。当然，用到的词可能不同，对很多人来说，他们不称之为 Scrum，但是人们会利用经验来做工作，也会在自组织的团队中工作。他们会把重点放在客户成果上，把他们的工作看作一系列需要证明或反证的假设。设计思维、精益 UX、精益创业和 DevOps 都是其中的一部分。我所看到的未来远比今天更难预测和更为复杂，大家都需要精益以生存下去。

阅读英文原文： Improving The Adoption of Agile

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。