本文要点
- 真正实现敏捷转型需要多年的努力,不能急于求成
- 人员意识是我们曾面临的最大挑战
- 创建一个敏捷至上的文化有助于解决文化方面的问题
- 开源价值观与敏捷宣言交相呼应,拥抱它们!
- 向SaaS的迁移让更多团队转向敏捷
从传统基于预定义工作角色的瀑布模型转变到团队成员人人有责的模型,对于大多数人来说是一个痛苦的经历。但是,越来越多需要向云计算迁移的团队和产品项目都会遭遇这种经历。云部署,体现为以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,对我们非常有帮助的一点是,我们拥有一种独特的文化,它超越了个人文化。这种文化聚焦于社区和开源价值,而这与敏捷宣言的价值观和精神非常契合。我认为,为团队带来或形成一种包容性文化将有助于解决个体文化差异所带来的问题。我们欢迎团队的多样化,而且这种多样化帮助我们成长并相互学习。
来源: http://www.infoq.com/cn/articles/agile-red-hat