Red Hat 的敏捷实践

本文要点

• 真正实现敏捷转型需要多年的努力，不能急于求成
• 人员意识是我们曾面临的最大挑战
• 创建一个敏捷至上的文化有助于解决文化方面的问题
• 开源价值观与敏捷宣言交相呼应，拥抱它们！
• 向 SaaS 的迁移让更多团队转向敏捷

从 Red Hat Mobile 团队的敏捷转型看 Red Hat 是如何拥抱敏捷的

从传统基于预定义工作角色的瀑布模型转变到团队成员人人有责的模型，对于大多数人来说是一个痛苦的经历。但是，越来越多需要向云计算迁移的团队和产品项目都会遭遇这种经历。云部署，体现为以 SaaS（Software As A Servie) 模型来构建和消费服务，越来越受客户的青睐和需要，而随机应变快速响应是核心商业价值之一。Red Hat 目前正经历这种转型，客户和消费者从以自我管理为前提的解决方案向高效灵活的云解决方案迁移。

对失去技术自主权的本能抵抗，以及快速开发节奏带来的越来越多的任务排期，是许多公司进行敏捷转型失败的一个主要原因。2014 年，Red Hat 收购 FeedHenry，一个基于 SaaS 的移动平台，将一个经验丰富的 SaaS 开发团队和一个经验丰富的瀑布开发模型质量管理团队融合在一起。这篇文章讲述了我们成功转型的故事，以及我们刚开始加入 Red Hat 大家庭时所面临的学习挑战。它也全面描述了相似的故事正在 Red Hat 的产品套件项目中不断重演。从操作系统到应用服务器，以及中间层节的产品，Red Hat 是一个真正敏捷的组织并以开源的形式进行这种转变。

收购

FeedHenry 是一个源自爱尔兰 Waterford 的创业项目，以一个在移动领域非常成熟的 SaaS 产品崭露头角。2014 年秋天，它被 Red Hat 收购。前 FeedHenry 团队习惯于以非常快的节奏工作，对于每周发布多个版本得心应手，能够迅速发布满足客户需求的新功能，并且每时每刻都以那种疯狂的创业心态工作。

被 Red Hat 收购是前 FeedHenry 所有员工的梦想，但他们在收购事宜落地的最初几个月里仍照常工作，因为他们仍然有客户需求和开发路线图需要实现。同时，Red Hat 也开始为 FeedHenry 投放资源。Red Hat 引入了几个支持团队来协助 FeedHenry 团队推演产品并帮助它转变成 Red Hat 移动应用平台（RHMAP，Red Hat MobileApplication Platform）。被引入到 RHMAP 的团队包括：资深安全专家团队，这个团队保护 Red Hat 的客户免受安全漏洞的威胁；国际化团队，这个团队将平台内容翻译成日文；Red Hat 原有的开源移动（Aerogear 项目）团队，这个团队曾负责开源的移动工具。

一个更严格的质量管理（QE）团队的加入，对于 FendHenry 来说可能是最大的帮助。这个 QE 团队负责所有事项的质量控制，从测试套件工具化到版本发布的确认。Red Hat 的质量管理和其它公司的常规质量保证（QA）工作有所不同。QE 更多地关注测试套件的创建和维护、测试执行的自动化以及产品的整体质量指数。另一方面，QA 通常是一种软件验证，按照一系列步骤来验证 bug 确实是被修复了，或者是按照一系列步骤来确认新功能确实被添加了。从质量的角度来看，QE 更有价值，它提供了更多的保证。当然，这并不是否定 QA 工作的重要性。FeedHenry 目前拥有一个更严格的质量管理团队，这让 FeedHenry 的产品和客户能够从中获益。

这对于双方来说都是一个很好的学习机会。前 FeedHenry 团队带来许多关于 SaaS 平台该如何运作的领域知识，包括丰富的移动端领域知识，Node.js 语言、生态和概念、DevOps 和网络运营中心（NOC，Networks Operation Center）的关键作用，这与 Red Hat 原有的典型的自我管理或角色提前固定的开发方案可能有所不同。在第一年，他们旨在提升支持团队在移动领域的技能，侧重于从语言到流程的信息交换，帮助框架成功落地。另一方面，需要让 FeedHenry 团队适应在一个拥有庞大支持网络的开源公司的生活。其中一个变化是放弃一些作为创业公司本来不得不提升和掌握的领域。目前，Red Hat 的专业团队各负其责，可以让 FeedHenry 团队集中于他们的强项。对于 FeedHenry 的成员来说，获取开源并分享他们的领域知识的机会是巨大的。他们拥抱开源，同时也坚持保留创业公司的精神。这种转变正是 Red Hat 擅长解决的问题，FeedHenry 团队从 Red Hat 获得的支持令人震惊。

敏捷转型

我们经常被问到，你们是如何向敏捷转型的？答案是，慢慢来！不幸的是，并不存在魔法按钮，可以一键转换，也没有一个预先定义好的转换路线图。这个旅程本身会随着你跨越的每一个障碍而变得逐渐清晰，但是旅程的开始是最重要的，你知道做出转型是必需的，而更重要的是，你可以时常回头看看你已经走了多远。

对于 Red Hat 移动应用平台（RHMAP）来说，在收购结束 12 个月之后，蜜月期已经完美结束。主要由 QE 团队驱动的 Red Hat 支持团队，已经熟悉 FeedHenry 平台，并且已经通过发布一些 RHMAP 的小版本来适应工作流程。Red Hat 主导的第一个主版本，我们曾承诺的 3.6 版本，预计将在 QE 周期停留 20 天。我们花费了超过 3 个月的时间来让这个版本成型。在这个周期内，编码工作还会继续，因为需求还在变动而且整个团队也很难对忠实的用户说不。QE 正试图发现问题，而且由于他们从开发瀑布的下游开始工作，因此变动的成本很高。由于发现问题时已经过去了一段时间，需要切换到过去的上下文，然后在一片几周前开发的功能中定位到一个 bug，因此修复问题工作进展很慢。整个团队已经受够这种情况了。我们有必要根据自己的参考点做出积极的改变。我们知道我们必须快速发布，同时我们也理解严格的 QE 周期的必要性，因为产品质量是 Red Hat 引以为豪的地方。我们知道如何从根本上弥合开发和 QE 之间的预期差距，因此我们努力向敏捷的方向转变。这些都需要一些帮助，幸运的是，正好 Griffin 在这个时间点加入团队来协助指导敏捷转型。我们设置了各种完美的预期，完整的转变将需要 12 个月的时间。

我们从两个角度进行转变：团队和管理层。

团队转型

前六周用于产品启动以及回顾版本发布背后扣人心弦的故事。我们获得了很多背景资料、建议和意见，由于 Red Hat 是一个精英团队而每个人都有自己的想法，每个人的声音都是平等的，但最后只有最棒的想法能够胜出！我做了一些笔记，然后从一个局外人的角度来观察情况，并且观察那些启动敏捷之旅的团队或产品的典型精神，然后做了一些修改，从七个团队中选择其中一个开始敏捷转型。这个团队已经习惯于松散的 Scrum 方式，因此我们继续坚持 Scrum，但也开始实施一些 Scrum 仪式并让人们意识到这些仪式的价值。我们对“完工”进行了定义，帮助弥合 QE 和工程师在质量保证方面的预期差距。这时，团队开始意识到工作不能简单地越过质量控制。QE 团队对整个团队带来巨大价值，教给其他人关于质量过程的知识并花费大量时间在构建回归套件和工具来帮助保证产品质量。我们将枯燥耗时而又不得不做的手动 QA 工作分摊给团队成员。质量控制人人有责，这是敏捷之旅的一盏明灯。在接下来的时间里，我们看到功能开发速度的巨大提高以及团队整体幸福感的提升，这些都有助于非常关键的收购决策。这就允许我们加快我们的计划，越来越多的团队开始敏捷转型，直到和我们合并的七个 QE 和工程团队都遵循敏捷方法。

管理层转变

我们经常说人员意识是转变最困难的部分。硬件和软件的转变都很简单，但是人员意识的转变，你就要当心了。在和管理层和高层人物打交道时，就更是如此。他们中的许多人的工作都是基于决策和流程，而你推行的敏捷转型可能会与这些决策和流程产生冲突！要记住，向敏捷方法论的转变需要得到各级人员的认可，而不能让管理人员强制执行这种转变或者用自下而上的方法推行。当你向管理人员和工程师推荐敏捷方法时，需要将你的想法开诚布公。我们在解释敏捷方法好处的同时，也必须声明这个转变过程中可能面临的各种不适。我们必须鼓励团队进行试错（当然也不能毫无意义地犯错！），并从中学习进步。其实，我们必须不断调整期望并让团队和管理层找到他们的平衡点。幸运的是，在 Red Hat，责任感是我们的核心价值观之一。整个团队迅速意识到他们可以根据自己的决定来选择冒险或者保持安稳。凭借这种美德和 Red Hat 的管理风格，我们团队转向敏捷的道路变得容易了许多。作为人员管理者，我们在 Red Hat 承担很多责任和期望。我们经常与团队一起工作，有很多机会去指引、训练和指导他们，这些成为我们每天生活的一部分。从一个敏捷教练的角度来说，这是一份理想的工作。我们可以看到积极而真实的变化，与各个团队和个人紧密协作，我们的管理风格与互动向每个管理者传播并一直扩散到执行层。我们拥有管理层的全力支持来进行敏捷转型，我们的成功也让我们的想法和流程得以在 Red Hat 广泛传播。每一个小的改变和每一步小的进步最终造就了 Red Hat 盛大的敏捷革命，我们为曾经参与其中而感到自豪。

敏捷促进

引入敏捷 12 个月以后，Red Hat Mobile 的所有团队都遵循敏捷方法论，大部分采用修改过的 Scrum 框架，另外一些作为 Kanban 团队运行。这并不意味着转变已经结束，我们仍然需要做出一些调整。 在经过了敏捷实践的最初阶段之后，我们对这段旅程进行了更严格的回顾，而周年庆典成为其中一个重要的时间点。我们的回顾结果，引导我们去探寻我们自身方法中存在的问题，然后集中精力去改善这些领域。当团队要将功能改善、功能需求和 bug 修复添加到主版本中时，我们实践了 Scrum 的一种变体来保证平衡。这让我们更好地掌控版本发布。冲刺时间点被调整到星期三，取代了传统的星期五。我们发现，许多团队成员在周五离开，特别是遇到银行休假日，而这严重影响了与冲刺结束相关的 Scrum 事件。我们采用了每周三段冲刺的时间安排，这样我们可以更容易应对外部影响、预料外的人员休假、外部会议，并且更高效地对我们客户的需求作出反馈。我们可以看到单周的开发速度的提升。

当敏捷转型已经在七个团队中都达到了一定的成熟度，我们开始在一些小的临时团队中进行尝试。我们用比固定团队更慢的速度推进，凭借深厚的技术功底和对每个团队特定的要求，让员工的变动最小化。随着时间的推移，我们打破了信息和技能的界限，跨技能的团队让我们能够以一个更全面的视野来看待团队的组成。我们开始为合适的职位在特定的时间点组配合适的技能，发掘出团队的真实潜力。功能交付得更快，团队变得比以往更活跃，与客户的互动更强。我们花费了很长的一段时间，逐渐实现每一个小变动，达成每一个小目标，帮助团队从敏捷的变体转变成在思想和行动都是真正的敏捷。这段转变之旅还远没有完成，我们的目标不断变换并驱动我们去吸收新的思想来改进我们的敏捷实践。

经验总结

如果仅仅说我们收获了很多，有点轻描淡写，因此我们将试着把收获的经验集中在三个方面。

第一个方面，需要打破敏捷的负面含义。我们遇到的许多痛苦，都是由员工过去所在公司尝试敏捷转型失败的负面经历引起的。他们转变的步伐太快，进行了一天的培训就期望团队能够转变过来并顺利执行，敏捷给了他们当头一棒。我最初的几周用来和每个团队成员保持一对一交流和回顾，理解他们的工作背景以及他们对敏捷工作方式的消极态度。

第二个方面，以人为中心。只要你的人保持正确的态度，你就能实现世界上任何技术和流程，即使你一无所有。敏捷转型需要能够自我驱动、变革创新、开放思维、具有团队精神而且最重要的是擅长沟通的人。在 Red Hat，我们非常重视人员，这是我们的核心哲学以及引以为傲的地方。作为一名敏捷教练或服务者，令人印象深刻的是，我能够和所有内部关联团队平等地交流。这对于敏捷转型意味着，我们能够给予和收到所有积极和消极的反馈。我们需要合理解释和支持我们的决策，并在决策失误时坦然接受。我们作为服务者有时会犯错，但在发生错误时，最重要的是要做出更有利于团队健康以及项目转变的举措。注意语气，展现尊敬，不要咄咄逼人，注意倾听。

第三个方面，支持团队的重要性。我们非常幸运地在 Red Hat 偶然发现了一个敏捷教练组。我们因此有一个安全的地方可以相互交谈，分享经验、问题和知识。一个志同道合的团队对我来说意义重大，它可以给予我更多的信息和见解，并带给整个团队。由于 FeedHenry 融入 Red Hat 已经 12 个月，这使得我们能够适应那些在开源世界工作生活所带来的细小差异：来自社区的挑战和产品期待、开源开发者的心态和 Red Hat 生态的互动等。如果没有一个强大开放的志同道合的团体相互交流，我们不能实现这些目标。我过去经常鼓励敏捷倡导者去寻找一个本地聚会（或者发起一个！），或者参加一些例如 Agile Cambrige 这样的大型峰会，这样可以遇到一些志同道合的人，然后将一些新的东西带回团队。敏捷转型对你个人和你所在的团队或产品都是一次转变之旅。寻找风格相近的志同道合的产品、公司和团队，真的有助于你和你的团队完成手头的任务。

文化是越来越多公司在敏捷之旅中不得不关注的问题。不同的文化将支配团队内的互动和行为。来自不同背景、不同文化的人会有不同的观点，而且当团队成员进行异地办公时这些差异会更严重。Red Hat 有远程办公的文化，是一家由大量遍布全球的才华横溢的人组成的公司。我们一半的成员是在一起办公的，另外一半则分布在其他地区。我们必须为我们的远程团队成员保持良好的沟通通道，一有机会就让他们参与其中，就像他们与我们在同一个办公室一起办公一样。我们通过每周与所有远程团队成员一对一交流来解决这个问题。我们认为以人性来联结团队成员是非常重要的，而太多公司和管理人员仅仅将他们的团队成员看作一种资源。资源通常是一台笔记本电脑或者一个云主机实例。我们的团队是由众多才华横溢的人组成的，每个人都独具个性，为团队引入新的技能栈。你必须利用这些特点来构建成功的团队。你必须与团队沟通，理解他们的背景，更重要的是，他们每个人擅长做什么工作。我们所有的会议都在远程通信工具上召开，即使 99% 的团队成员都在办公室，我们也拒绝召开一个线下的会议，而让剩下的 1% 的人拨号接入。相反，我们都在自己的办公桌旁打电话并采取远程接入来保证团队内部的平等。

我们虽然每周都为此投入大量时间，但获得了回报，收获了团队和产品的成功。在 Red Hat，对我们非常有帮助的一点是，我们拥有一种独特的文化，它超越了个人文化。这种文化聚焦于社区和开源价值，而这与敏捷宣言的价值观和精神非常契合。我认为，为团队带来或形成一种包容性文化将有助于解决个体文化差异所带来的问题。我们欢迎团队的多样化，而且这种多样化帮助我们成长并相互学习。

作者简介

Dr. Leigh Griffin 是总部位于爱尔兰 Waterford 的 Red Hat Mobile 的一名工程部经理。Griffin 过去十年中在工业、学术和研究领域有广泛的编程背景。近年来，他作为敏捷转型专家，在大型项目中实践敏捷转型。

Brendan O’Farrell 是总部位于爱尔兰 Waterford 的 Red Hat Mobile 的一名工程部经理。O’Farrel 拥有超过 25 年的多行业业务和流程管理经验。后来，他转向软件工程，目前帮助 Red Hat 更多团队进行敏捷转型并分享他在敏捷转型方面的渊博知识。

查看英文原文： Agile at Red Hat

感谢薛命灯对本文的审校。