让敏捷交付优秀的软件

在一篇为敏捷鸣冤的博客帖子中，Nic Ferrier 详细地阐述了他所认为软件的生产会失败的一个原因：那是因为有经验的程序员过于关注编程本身，而忽视了整个大局。按照他的观点，那些反对敏捷文化、认为编程就是一切的思想是无法解决软件产业目前所面对的问题的。程序员与业务人员应当投入时间与精力以寻求互相之间的理解，并且通过共同努力一起解决软件交付中的各种问题。

InfoQ 有幸采访了 Ferrier，谈论的内容包括了有效地实施敏捷、每日站会的目的、经理或 Scrum master 在敏捷中的必要性，以及在交付软件方面除了 sprint 之外的其它选择、为何专注于架构能够改善团队合作、以及如何通过技术帮助我们避免团队曾经经历过的某些组织结构方面的问题。

InfoQ：你在文中提到，没有证据可以表明敏捷是否有效，但有许多具体经验已经证明了它们是有效或是无效的。有没有什么方式可以让我们利用这些知识有效地实施敏捷呢？

Ferrier：改变工作实践的一大问题在于：很少有人已经做好准备，将自己的经验进行公开。很少有 IT 界的人士会宣称自己是非学术的，但对于 IT 部门的组织结构是很难学好的，因为这些组织不喜欢公开他们的数据。

最近有一本名为《软件工程中的精灵》（Leprechauns of Software Engineering）的优秀书籍出版了，其中列举了在软件业中没有说透彻的许多说法，例如 10 倍生产力（意指水平最高与最低的程序员之间的生产力差别可以达到 10 倍）等等，并且解释了这些说法是怎样产生的。在每个案例中，都没有真正的证据可以证明这种说法。

我们不知道如何衡量一些基本的东西，例如软件开发者的生产力，因为我们甚至都不知道好的编程方式是怎样的。因此要做的事就是对你所做的每一件事都加以批评。别让这摧毁了你的工作……但至少你可以变得更有批判性，表达出“这看上去并不是我们最佳的做事方法”的意思。

对我来说，敏捷的核心原则是常规地进行回顾。它让你得以了解你的表现更好了还是更差了。

InfoQ：如果事情确实变得更糟了，或者你被某些东西阻碍的时候，你又该怎么办呢？在此时实施一些优秀的实践是否能成为一种解决方案呢？

Ferrier：首先，如果你已经意识到事情在变糟，那就说明情况还不算太差，至少你还是得到了衡量的结果。我觉得，要从不断变糟或毫无起色这种状态中走出来，你需要不断地进行尝试。在这些尝试中你要做到对问题的开放性。不过如果你的问题是软件方面的问题，那么让开发者进行这种尝试大概也是无意义的，因为你知道你需要的是某种软件方面的解决方案。因特网是寻找这些解决方案的好地方，你可以向那些遇到过相同问题的人请教。但这并不意味着这些解决方案就一定适合你，对此你要做到心里有数，并且始终准备着尝试新的事物。

还要记住，没有什么能保证你一定成功。但我们能够做到的就是，尽力去完善那些你知道做得不够好的地方。

在 Ferrier 的博客帖子中，他对于每日站会有以下评论：

人们不会因为闲得没事干才去搞些新东西出来。每日站会的存在必定有着某种意义，而它也确实存在。在复杂的软件项目中，通常会有许多人参与，各自做着许多不同的事。因此让他们频繁地聚在一起交换信息是一种很好的方式。那么为什么要采取站立的方式呢？原本的意图是希望这些交流的时间不要过长，因为没有人喜欢长时间站着。

InfoQ：如果团队看不到每日站会的价值，而开始选择忽略它，这时应该怎么办？Scrum master或敏捷教练是否应该坚持推行每日站会？有什么替代的方式吗？

Ferrier：如果某个 Scrum master 坚持要做些什么事，那他就没有做好他的工作。对 Scrum master 的定义就是“仆人式领导”，因此独裁专政是绝对错误的做法。

你当然并非“一定”要进行每日站会，这种方式存在的意义就是每天聚会一次，让所有成员参与其中。你可以通过无数种其它交流方式取代它。我曾经试过使用视频聊天的方式进行“每日站会”，可以选择一个快速的视频电话，甚至只要让每个人在某个共享的编辑器中仔细地写下他们正在做什么就够了。

但是大多数组织无法做到这一点，原因在于他们的通信系统不够强大。在创业公司中，团队或许能够使用他们想要的任何东西，甚至是最先进的 webRTC 视频聊天工具。但在大型公司中通常很难做到这一点，因为有太多的限制存在。因此除了会议之外，你很难在其它场合让所有人一起参与通信。

关键在于，要想方设法实现信息的交换。之所以经常采取某种会议的方式，原因在于人们不会有意识地交换信息，除非有人要求他们这样做。多数情况下，人们只会在有人要求的情况下才去参加会议。但如果你换一种方式劝说人们进行信息交换，那么也能够实现目的。要注意的是，重要的不仅是写下你要分享的信息，你还必须阅读他人所分享的信息。正如在开会的过程中，你不仅仅要分享你的现状，聆听他人的现状也同样重要。这也是为什么会议（如果确实有招开的话）必须简短的原因。

你还要记住一点，每日站会并不只是由技术团队参与的，代表业务团队的产品负责人、测试人员、任何支持人员、以及任何参与了这项工作的人同样也需要出席。你必须找到一种方式，让所有参与了这项工作的人都能够出席，建议是每天一次。

InfoQ：你曾表示：“我不认为经理能够解决经济上的问题”。你能否详细地说明一下你想表达的意思？

Ferrier：Erik 的建议中有一条表示，我们可以让 IT 变成一种纯粹的命令与控制式的环境。他认为这样做很简单，只要让经理们告诉程序员去做什么，然后让他们照着做，就能最终产生利润了。

这种对于正确管理方式的看法显得很傻很天真，让人忍俊不禁。经理们确实会倾向于命令与控制式的管理方式，而这会让他们无法了解到软件生产的高度微妙性。你不能对开发者说：“我要一只金色的奶牛”，然后让开发者给你做一只出来。这是造物主才能完成的奇迹。开发软件不是造房子或是拉电线，它具有更强的可塑性。因此你必须以一种具有可塑性的方法来创建软件，让它对于不断变化的情况具有高度的适应性，这一点又称为敏捷。

InfoQ：管理者或经理在敏捷方法中还有存在的必要性吗？

Ferrier：并非一定有必要。Fred George 提到了程序员的某种混乱状态，在这种状态中程序员会自行判断当前要做些什么事。以这种方式动作团队的前提是，团队的成员都是非常出色的工程师（这表示他们了解所做的工作，并且不会过度设计），并且他们还要非常了解相关的领域知识。

大多数企业其实有能力做到这一点，只是他们没有勇气迈出这一步。这些企业中有许多 IT 团队的成员同时具备了大量的领域相关经验。我经常看到的现象是，企业中的产品负责人本身非常不成熟，对技术也一无所知。这些产品负责人大多数来自于业务领域，他们只关注于自己交付的内容，或者是他们的老板以及董事会所要求的内容。他们总是把自己的工作内容当成是一个“项目”，而对于精益开发知之甚少，也没有什么动力去学习如何创建更好的产品，许多观念都是事先形成的。

Scrum master 有也可能驱使团队做出错误的行为，正如 Ferrier 在他的博客帖子中所表述的一样：

你不需要在团队中设立一个 Scrum master，这反而会影响团队积极地进行自我管理的意愿。不过，如果你的开发者每天都被紧张的项目进度压得喘不过气来，如果此时有一位 scrum master 类型的人物，他能够更多地扮演仆人式领导，而不是项目经理的角色，那么或许他在帮助团队学习如何做事方面稍有帮助。

InfoQ**：如果 Scrum master对事情进行过多地监控，让团队成员将所有的事都交给 Scrum master去组织，我能够理解这种方式带来的潜在问题。有没有可能找到一种平衡，让 Scrum master**和团队成员以一种合作的方式共同进行组织管理方面的任务？

Ferrier：嗯，也许吧。但是在一个工作表现非常出色的团队中，没有哪一位成员的贡献会少于一位专职的 Scrum master。Scrum master 存在的理由之一是因为许多人已经习惯于被人管理了。

InfoQ：那么说来，或许在团队刚刚开始采用敏捷工作方式时确实有必要设立一位 Scrum master，但随着时间的推进，这一角色或许会显得多余？

Ferrier：正是如此，完全正确。这也是为什么有一些敏捷专家会倾向于让团队中具有技术知识的成员担任 Scrum master 的原因之一。因为这些成员会自然地找到一种方式让 Scrum master 这一角色消失。不过我也认为这种方式并不总是可行的，但其原因经常是因为业务经理不允许技术团队以一种敏捷式的方式成长。

Ferrier 在他的博客帖子中也解释了为什么他认为 sprint 对于团队来说是一种糟糕的解决方案，它或者只适合于成熟度最低的敏捷团队。

Sprint 对于生产软件来说绝对是一种愚蠢的方式，它经常会使你无法快速地进行交付。它总是鼓励程序员保存源代码、创建源代码分支，以及越来越多的流程方面的工作。

InfoQ：你能否推荐一种可以替代 sprint进行交付软件的流程？

Ferrier：有一种很著名的工作状态，叫做心流（flow）。在这种状态下的团队可以顺利地从产品负责人那边获取新特性的点子，并很快地实现它。要做到这一点有许多前提条件，产品负责人必须清楚下一个能够完成的功能是什么，并且要了解测试，明白如何证实某个功能的实用性。开发者必须高度工程化，测试团队必须能够正确地进行探索性测试，以上种种都要做好。但团队总是能够达到这一状态的。

但请让我把话说清楚，我并非建议你盲目急进。而是说如果你已经开展 Scrum 一年而毫无进展，那不是一种好现象。Scrum 不是一种终结状态，而是一种不断在培训中发展的敏捷车轮。

InfoQ：康威定律指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构。其结果就是某个系统的架构往往会反映出组织的结构。你是否同意这一点？这是一种问题吗？

Ferrier：这绝对是一种问题。我尝试这样解释这个问题：大型公司通常倾向于创建以公司为中心的系统，而不是以用户为中心的产品。他们只会创建在能力范围内的产品，选择接受内部的各种壁垒，而回避内部的依赖。这也意味着他们所创建的产品无法超越商业体或管理线。因此这种产品称不上产品，充其量只能称之为软件。创建产品的不同之处在于，公司会把这句话挂在嘴边：“亲爱的客户，这是我们为你所做的东西。”

InfoQ：你建议应当怎样应对这个问题？专注于架构能否帮助我们找到更好的方式，在软件开发中进行合作？

Ferrier：我认为过度的关注是有危险的，我也确实看到某些 IT 组织这么做的后果。许多大型组织中都设立了架构师团队，他们不会交付任何东西，只是为其他团队提供建议。我很质疑这种方式的价值。

但之所以架构管理在大型公司中能占据一席之地，一个原因是因为交付团队对架构不够关注。

我认为有一个十分严重的问题在于，人们似乎很难理解为什么架构级的变更会催生更好的交付实践。其原因在于有许多敏捷专家本身不具有很高的技术水平，他们只是一种非常了解人类心理的人。

为了说明我所说的内容，可以举一个很好的例子，就是依赖。在“事物“、业务流程、技术或其它任何东西之间存在的依赖都是很难处理的。而如果我们在团队之间也存在着依赖，那么事情将更加棘手。这也导致了我们进行项目管理、甘特图、协作等等，也导致了面临着失败的风险。

但依赖的产生是因为我们没有将事物进行足够的分解，也没有构建出合理的契约，让契约双方都能够顺利地取得进展。对于产品相关的问题来说，依赖依然是一个很难解决的问题（但不是无法解决的），但对于技术方面来说，这种问题基本上已经解决了。可以通过面向服务的方式促成代码重用，这些服务应该尽可能保持粗粒度，以避免依赖。我们也可以通过增量式（没有破坏性）变更的方式对服务的契约进行改变。

是的，我说的就是微服务，这是当前的趋势。但这里面的规则并不是新鲜的东西，微服务只是一种代码名称，其含义就是理解正确的粒度级别。

因此，很多时候我们看到项目经理出现在 scrum 团队中的原因，是由于我们对于架构失去了控制。

InfoQ：技术能够以怎样的方式帮助我们避免团队经历过的各种组织结构问题呢？

Ferrier：我认为实现技术上的正确粒度是非常重要的，它能够真正地解决组织结构上的问题。

但是实现的过程中会有许多来自于技术人员的阻力，我还没有完全弄清楚原因何在。有可能只是那些守旧派会天然地抵触那些“时髦的垃圾”，但我觉得有可能存在一种更深层次的原因，因为技术专家本身也需要接受新的技术与技能的能力。

技术专家在接受新技术这一点上为什么会表现得与非技术专家有所不同？我想原因是许多人在年青时找到了某些能够熟练掌握的东西，并且从那之后就停止了学习。这样一来，他们就会积极地抗拒任何新的事物，否则他们就必须去学习那些新事物……

而这一点对于解决问题来说是相当有害的。如果对某个问题的解决方案是一种新事物，那么你就无法从那些保守的技术专家那里获得任何支持。

关于受访者

Nic Ferrier是一位程序员，他相信我们能够从创建问题的过程中解决问题。他善于从实践中获取经验，并且在软件行业中已经具有超过 30 年的经验了。目前他将主要精力专注于为企业传授 DevOps 方面的知识。在休闲时，他喜欢通过编写软件解决自己的问题。

查看英文原文： Making Agile Deliver Good Software