使用Water-Scrum-Fall交付软件-InfoQ

Water-Scrum-fall 通常被描述成一种混合的敏捷工作方法。

根据 Andy Hiles 所说，Water-Scrum-fall 是一种封闭的、阶段性的软件交付方法，其中 Scrum 是最主要的开发管理方法。

然而，Hiles 相信它可以作为通向敏捷、成为活生生的敏捷组织的跳板。

Andy Hiles 在 Agile Greece Summit 首次峰会上发表了 _water-Scrum-fall, Unicorns and Rainbows_ 演讲。InfoQ 将会推出本次会议的新闻、Q&A 和文章。

InfoQ 采访了 Hiles，主要关于 Water-Scrum-Fall 的起源和他对 Water-Scrum-Fall 的定义，“实施”（doing）敏捷和“正在”（being）敏捷的区别，用敏捷满足客户期望，Water-Scrum-Fall 的优势和缺点，和 Scrum Master 在实现中的角色。

InfoQ**：Water-Scrum-Fall这一术语起源哪里？**

Hiles：我不清楚谁最初创造了这个术语，但是它已经被敏捷社区使用好几个年头了。我第一次听到时，它被用来描述一种混合的敏捷工作方法。那时，我并没有真正理解混合模型与 Water-Scrum-Fall 之间的界限。只有当我开始在 Water-Scrum-Fall 环境下工作时，我才真正理解这一术语的含义。

我有看过 Water-Scrum-Fall 被用来区分敏捷纯粹主义和实用主义之间不同的实现方法。对我而言，这种用法真的是一种挑衅，是为误解敏捷找的一种借口，尤其是 Scrum。

InfoQ：您对 Water-Scrum-Fall**** 的定义是什么？

Hiles：对那些不熟悉这一术语的人而言，它将软件交付划分为三阶段。首先，是一段详细设计和计划时间。接下来，Scrum 被用作主要的开发管理方法。最后，有一个对实时周期（live period）严格的管理服务交付 / 发布的保留。包含的三部分实践通常是封闭的，通过固定合同条款支配，并且其端到端非常非常的漫长。

InfoQ：您能分享一下“实施”敏捷跟“正在”敏捷之间的区别吗？

Hiles：实施定义为一个人从事或者执行的活动。我可以实施和执行所有烤蛋糕的活动，我可以添加原料，我可以搅拌生成黏糊糊的混合物，然后我可以把它放到烤炉内，但是这不意味着它味道会很好，事实上，最后我将得到一个蛋糕。这只是我看到 Mary Berry 执行的活动，我尝试模仿她。类比，不太认真地实施敏捷的现状与烤蛋糕是相似的。我经常听到人们说，‘某某组织是敏捷的’，我会想，“他们做什么了？”“哦，他们做站立会议和结对编程”这就是答案。但是什么使得他们变敏捷？这些是敏捷蛋糕中的活动，这是否意味着通过这么实施他们正在敏捷？

这里有一个明显的区别。

当我们说正在的时候我们是说存在和活跃的（existence and living）。对我而言，它意味着进化和变革。对我而言，正在敏捷就是抓住每次机会衡量、收集和使用反馈，从而指导变革（steering change）。从学习本质来讲，最重要的部分是拥有“专注持续过程改进”。我对每个质疑他们敏捷性的人说，如果他们拥有反馈驱动的专注持续过程改进，在我看来他们就是“正在敏捷”。我不能成为 Mary Berry，但是我可以尽我所能，通过从学习一杯茶和一块蛋糕的反馈回路中改进我的蛋糕。

InfoQ：敏捷旨在缩小客户预期与真实交付之间的差距。您能否解释一下这个差距，在您看来什么使得缩小这种差距变得如此困难？

Hiles：天哪，从哪开始说起。让我们首先从指责合同说起吧。那很容易做到，因为它设置了假设：一份签订的合同意味着‘末日铁三角’（固定的时间、成本和范围）已经在起作用，并且对此我们什么也做不了。

典型情况是销售人员带着客户签约这一目标走出去，为现有产品或者甚至为交付一个更好的、全新的、能歌善舞的产品合同从事签约活动。这种情况的危险性在于尽管销售人员知道他们在做什么，但是他们不是交付最终产品的人。这些销售的目标是将其转化成固定范围、时间和成本的项目。然后，这些项目获得继续推进的许可，并最终由业务开发经理、规划管理者、项目经理、产品设计师和架构师合作完成方案。等项目到达开发团队手中时，往往距离承诺的交付日期只剩下几个星期了。虽然在这种情况下，我们总是会觉得对不起开发团队（并且我们应该），但是我们居然忘记了品质保证员、发布和环境人员以及受铁三角承诺损失的终端客户。这是一个典型的瀑布式交付实践。

Donald Rumsfeld 有句名言：“众所周知，世上有我们知道我们知道的；世上有的事物我们知道我们知道。我们也知道世上有我们知道我们不知道的；这就是说我们知道这世上有我们不知道的事。但是也有不知道我们不知道的——那些我们不知道我们不知道的。”

这对我而言明确了我见过的每一个积压待办事项或者需求列表。如果我们的项目处于知道知道的区域，那么我们应该实施瀑布式。但是正如我们都知道，事情不断变化，总有不确定的东西，所以我们会不经意间变混乱，因此我们应该指导我们自己走向敏捷，管理这种变化。但是我们没有。

为了缩小期望和交付之间的差距，组织会希望变敏捷，通常他们会采用 Scrum 作为解决方案，但是仅仅是在开发部分。这就是 water-scrum-fall。

但是到那时，再利用从 Scrum 带来的计划和迭代中获取的反馈循环就为时已晚。Scrum 创造的角色和职责为我们正确地构建正确的事情提供了保证，虽然这种优势没有被显现出来。但是因为我们已经知道，所有预先做的大量的设计将会从不确定性中拯救期望差距，并且新的迭代过程将会实现更快和更廉价地交付产品，因此结果就是项目可以坚定不移地向前推进，

InfoQ：您知道如何部署敏捷，使其满足顾客期望？

Hiles：我不认为敏捷可以作为一个‘东西’被部署。我最喜欢描述敏捷的一个方法是：它就像海盗代码（参考引用了‘加勒比海盗’电影），“与实际规则相比，它更多的是你所谓的‘指导方针’”。

敏捷是一种思维定势，一套指导方针，Scrum 是一种可以部署的框架，它需要遵守严格的规则和事件，这两者是不一样的。敏捷思维暴露出我们不能快速交付的能力，它唤起了什么是客户真正想要的，并通过提供多个持续反馈的机会改进质量，反过来又迫使开发者专注如何正确地构建正确的事情。

有一些简单的事情你应该开始了解，并期待改变。

首先是协作。这应该从让你的客户参与其中开始，他们需要了解你是如何工作的，尤其是如果你将要使用 Scrum 或者仅仅是希望改变你的工作方式时。你的客户需要明白他能够胜任什么和他需要扮演什么角色。内部和外部协作是至关重要的。现在，将你的客户和团队看成一个大型团队。你们一起交付。与协作同时发生的还有反馈。合理利用反馈对产品质量、价值和指导是至关重要的。反馈是变革的驱动力，应该将其作为一种学习的机会持续拥抱。最后，尝试缩短交付周期。衡量工作从概念到产品的交付周期。将你的交付周期建模，寻找输入并为变革和中断做好准备。记住，缩短你的交付过程可以改进反馈和协作机会，反过来又会改进质量，和提高向客户实现交付价值的可能性。

InfoQ：您知道为什么有些组织为了敏捷决定使用 water-Scrum-fall**** 方法吗？

Hiles：我不认为是有人选择了 water-scrum-fall，它正好作为一种自然输出而发生，是走向敏捷动机的一部分。因为对于那些希望使用 Scrun 解决问题的组织，它是最流行的敏捷框架。那些组织认为他们存在问题，比如减少投放市场的时间。Scrum 不仅拥有可以遵循的，定义明确的框架，它还能通过基于角色的培训方法赢得市场，所以它成为事实上的敏捷。不幸的是，正如我们所知 Scrum 仅仅被组织看成一种开发实践，而不是‘在你的端到端产品中处理不确定性和变革的开发’实践。

InfoQ：您能谈论一些 water-scrum-fall**** 的优势吗？和它的一些缺点？

Hiles：除了将 water-scrum-fall 描述成通向敏捷的垫脚石，我正在努力寻找任何实际的优势。这个过程背后的结构并不真的是用来处理不确定性或者变革的，因为它意味着一个我们知道知道的情况，所以为什么为 Scrum 自寻烦恼呢？你可以从敏捷声明和原则中寻找灵感，从利用业务和开发团队之间的关系获得利益，但是公平地说，如果你对原则感兴趣，你就不会满足 water-scrum-fall 现状。

InfoQ：组织有时很难实现 Scrum Master**** 角色。您能否解释一下什么使得它如此困难？

Hiles：Scrum Master 有一个简短的描述。Scrum Master 是服务式领导、老师和 Scrum 过程的保护者。Scrum Master 就与团队进行有益的互动提出建议，和与产品负责人一起确保待办事项被管理且对业务有价值。听起来很简单吧？

我之前提过，Scrum 是革命性的，而 Scrum Master 也是如此。对变革而言，Scrum Master 需要独立于团队之外，确保过程被遵循和理解，同时又不对交付负责，这是很难做到的。Scrum 中的每个人都需要弄明白在框架内他们适合干什么，他们如何工作。

Scrum Master 往往是高执行力、性格开朗、自我激励的个体，专注于完成事情，降低周围事物的复杂度。Scrum Master 努力站在 1000ft 的高点观察，他们远离交付，寻找各种机会改变和改进周围的一起事物。

从我的经验来看，从事 Scrum 的组织经常忽略 Scrum Master 作为促进者和服务式领导的能力。他们希望项目经理、技术交付专家、测试人员、开发人员、发布工程师所有人合为一体成为很好的项目超级英雄。Scrum Master 知道它不是这么工作的。

InfoQ：您能给出一些案例，为了有效实施 Scrum Master**** 这一角色，组织可以做什么？

Hiles：做 Scrum。这么说感觉有点傻，但是‘Scrum but’规则适用于此处。Scrum 将会揭露一些真正好的东西，也会指出你应该在哪些方面为你的产品开发提供支持。Scrum Master 将会在那里，支持组织使用 Scrum，所以你应该信任这一角色和雇佣来完成这个工作的人员，你应该支持他们，支持他们代表的 Scrum 框架。

Scrum Master 处在管理者的期望和由此产生的顾客交付期望这么一个艰难的夹缝中间。所以，将他们作为顾问，从而确保在组织内遵循最佳 Scrum 实践。从他们的经验中获取知识，倾听他们的意见和变革想法，再一次支持这一角色和它的权威。

正如敏捷周围的一切事物。对我而言将其浓缩成一段短句是很容易的。不幸的是，与敏捷周围一切事物一样，我意识到这种建议有其自身实现的复杂性，并且这种改变非常的困难。

InfoQ：对于那些希望提高他们敏捷的组织，您有没有其它建议？

Hiles：这样说吧，没必要害怕 water-scrum-fall，尤其是如果把它看作一个过渡，或者了解组织如何围绕 Scrum 和敏捷运作的第一步时。

Water-scrum-fall 是一个良好的开端，它会暴露你工作效率低下的原因，暴露其政治，和你可能忽略的为了通往 Scrum 的所有事情。当你仍然静坐在 water-scrum-fall 周围，但是却正逐渐做敏捷项目业务时，这时警铃就应该开始响起。目标是使你成为一个活生生的敏捷组织，而且通过做 Scrum，这是你旅程的开端，而不是结束。

一名敏捷教练曾对我说过：“时间是缺乏弹性的”，我喜欢这种表述，作为参考铁三角的术语。我们总是朝着某些截止日期或者时间盒事件前行，在时间盒内的行为决定了我们能否成功。

关于受访者

Andy Hiles 是一名经验丰富的敏捷实践者、活动发言人和经过认证的 BCS 敏捷培训师，其工作在英国西南部。Andy 拥有为产品和服务机构服务的软件开发完整的‘端到端’经验。他对组织复杂性挑战和如何使敏捷转型成功有着透彻的理解。他是经过 Scrum 联盟认证的 Scrum 实践者，通过与一些大型国际组织的合作（比如 Intel 和 Nokia），他的职业生涯得到了提升。Andy 目前是 IBM 的敏捷负责人和 DevOps 顾问。其是伟大的团队构建伟大的产品的坚定相信者。Andy 努力追求成功，并且在每次项目中都是如此地展示他的经验和热情。