@lsmn
2017-01-25T00:27:18.000000Z
字数 3649
阅读 2069
采访Wesley Coelho：DevOps面临的挑战
敏捷 Agile DevOps
摘要
在敏捷2016大会上，InfoQ采访了Tasktop业务拓展高级总监Wesley Coelho，内容涉及DevOps固有的沟通障碍以及如何克服。DevOps和敏捷暴露出了组织筒仓以及需要自适应和自动化的瀑布式沟通流程。
正文
本文要点
- 对于一起办公的小型团队，敏捷&DevOps已经让部署非常高效；
- 一旦组织开始扩展规模，超出了小型团队的范畴，那么组织小组间的瀑布式交流通常会成为障碍；
- 你需要能够将敏捷&DevOps和组织的管理流程联系起来；
- 在和不同的小组沟通时使用他们自己的语言很重要；
- 自动化沟通流程和自动化部署实践一样重要。
在敏捷2016大会上，InfoQ采访了Tasktop业务拓展高级总监Wesley Coelho，内容涉及DevOps固有的沟通障碍以及如何克服。
InfoQ：您可以给我们简要地介绍一下Tasktop吗？它是个什么样的组织？做什么？
Wesley Coelho：当然。Tasktop是一个ALM和DevOps集成提供商。我们让组织可以从多个供应商那里选择最佳的工具组合，创建统一的软件和交付工具栈。
InfoQ：这样说来它是在上层，不管客户运行什么工具都没有关系。
Wesley Coelho：是的。所以会有相当多的选择。我们的集成网络支持多达40种不同的软件产品。所以你可以选择其中的任何组合，把它们串联成一个最佳的端到端解决方案，让实践者选择最适合他们的技术。
InfoQ：您在DevOps领域非常活跃，在实践中，都有些什么挑战？其中什么有效，什么无效？
Wesley Coelho：我认为，关于DevOps的现状，其中一件非常有趣的事情是，作为一个行业，我认为我们在DevOps领域的核心部分已经做得非常成功。所以，使用持续集成、持续交付的组织可以采用那些技术，并实现它们，而且，你会听到许多客户和公司夸耀他们1分钟发布5次的能力，或者1秒钟多次发布到生产环境。作为一种行业，我们在促成这件事上已经做得相当不错。
其中一些挑战来自DevOps和敏捷的交叉，更具体地说是敏捷管理方法。所以，当你在扩展敏捷时，其中一项挑战是，你必须将DevOps活动和敏捷管理方法联系起来。我所说的管理方法是指敏捷计划，或者测试管理，或者正式的需求管理。当你扩展敏捷时，所有那些组件都会有。对组织来说，信息在那些环节的流动是出问题的地方。所以，你仍然会看到一系列的瀑布式沟通，比如在需求和测试之间，在需求和开发之间。
InfoQ：但是，敏捷就是要把所有的都合并在一起。那么到底是怎么回事？
Wesley Coelho：你说得对。在一个七人团队里，墙上贴着卡片，你可以做得很好。当你有一个上千人的团队，成员分散在世界各地，都有自己专门的工具和技能，那时敏捷就不总是有效了。你将需要引入一些工具来达成目标。人们已经那样做了。你可以去找来你需要的工具。但缺少的是联系，那些工具之间的纽带。在许多情况下，那是导致敏捷转型失败的原因，那也是为什么有人觉得他们的开发速度在引入敏捷转型时实际上降低了。
我可以给你讲一点一家大型银行的例子。这家大型银行投入重资进行敏捷转型，他们走出去，花了几百万美元，培训了1000名开发人员，实现了敏捷转型，他们希望可以更快地交付价值。因此，他们将9个月的开发周期压缩成了4个周。然后，他们十分震惊地发现，他们的速度降下来了。
他们通过研究发现，得，先前9个月里发生的筒仓式科目，现在每个月都要计划一次。每个月有四分之一的时间花在了计划和协调那些不同的科目上。因此，他们认识到，需求、开发及其他科目之间缺少自动化，手动过程导致他们速度下降。所以，他们希望消除那些流程，真正能够达成ROI以及实施敏捷的根本目的。
InfoQ：那真得非常有趣，因为团队层面的敏捷主要是跟人相关。
Wesley Coelho：是的。我认为那也很重要。人是流程的根本，而且，我认为，如果你走出去，和敏捷顾问一起工作，那将是起点。他们会从人的问题开始，从流程的问题开始，那很重要。但是，当实际应用的时候，就需要大规模地引入工具，因为那些卡片不能跨大洲漂流。所以接下来，一旦你组织好了流程中的人，你就需要引入那些工具。你要允许人们灵活地选择最适合特定类型实践者的工具。
我们正在逐步实现目标。然后，作为一个行业，我们认识到，在那个阶段，我们还没有完成。为了获得敏捷的生产力，你接下来需要将那些工具粘合在一起，以便信息流可以在它们之间自动流动，那样，在规模很大的情况下，你已经将所有的一切都整合进了快速开发周期，而不再依赖低效的手动过程。
InfoQ：那么，当你开始贯通交付团队之外的团队，或者你的IT小组现在已经很好地践行着敏捷，并且运转良好，但是现在，我们想要开始真正地把业务需求放进去，让营销团队和我们保持一致，等等，那会怎么样？我们接下来要做什么？
Wesley Coelho：是这样。你然后会希望采用这个敏捷的概念，并超越DevOps的最初使命。所以希望引入业务DevOps，关于项目管理系统，你现在已经有了资源规划和投资组合，它们现在正在一端将需求输入到专用的开发需求工具中。另一方面，你希望开始引入ITSM。这些是服务台工具，也需要连接进来，形成一个完整的周期，并且自动化其与上述那些工具之间的流程。我们将此看作是下一个阶段或者是目标的演化，进一步在整个组织内推进。
一旦你达成了上述目标，也许不是按顺序，你就会希望像其他人正在做的那样，利用敏捷做其他有趣的事情，而不只是局限于组织内部。你希望跨组织。因此，如果你在实施敏捷，但是你正将其中一个软件组件外包，比如，外包给一个不同的组织，你就会希望消除发生在组织之间的瀑布式沟通。我们正在见证一个例子，一家豪华汽车制造商正在研发自己销售的汽车，上面会运行1亿行代码。
他们内部不会编写任何代码。所有那些代码被外包给了几十个供应商。所以，当他们把车开上赛道并发现其中有一项缺陷时，他们在自己的中央资料库中记录了这个缺陷，而且，他们使用了一项技术，一项类似Tasktop这样的自动化技术，转换并自动发送给生产这个有缺陷组件的供应商。现在，那个供应商使用他们自己的工具获得了使用他们的语言描述的缺陷信息。他们可以纠正并更新它。这些更新会流回到汽车制造商那里，后者会看到缺陷已经得到纠正，他们可以将汽车重新带回赛道，测试一下是否一切都已经如所说的那样运行正常了。
这就是我们正在见证的一些有趣的趋势，不只是在团队内扩展敏捷，还将敏捷扩展到组织之间。那里还存在大量的瀑布式沟通需要自动化，以便所有人都可以缩短他们的开发周期，而不会因为所有跨不同工具、不同筒仓的计划产生巨大的开销。
InfoQ：利用技术缩短人们之间的反馈循环，尤其是跨组织的。我们是只发送一个通知单，上面写着“修复这个问题”，还是会采取其他的做法？
Wesley Coelho：人们使用自己特定的“沟通货币（currency of communication）”。根据你作为实践者的类型，一旦你成为一定范围内的专业人士，你就会有沟通货币。如果你是一名测试人员，那可能会是一份缺陷报告。如果你是一名业务分析人员，则沟通货币可能是一份需求。而对于开发人员而言，那会是故事和缺陷。就是那些沟通货币，它们是那些实践者用来沟通的。现在，借助工具，人与人之间的沟通是自动的。通过使用你自己的沟通货币和自己的语言，你现在可以使用一种你懂的语言和相邻学科的人交互，以一种你可以报告、可以追溯的方式。
InfoQ：所以Tasktop是在上层，使得沟通既可见又可追溯？
Wesley Coelho：所以，有趣的是，它不是完全在上层。我们没有在上面引入一个新层。它更多的是说提供一个网络基础设施供这些东西在上面运行。不需要引入一个新的记录系统。你已经有工具做这些公司需要完成的工作，但是，他们无法访问所有他们需要访问的信息，因为那些信息在邻接的工具上，他们无法追溯到那些信息。这就是Tasktop技术的用途所在了，将那些工具彼此互连，同时，这些工具仍然是记录系统，你可以以它们为基础出具统合报表。
InfoQ：Wesley，非常感谢。
关于受访者
 | Wesley Coelho是Tasktop Tasktop Technologies业务拓展高级总监。在Tasktop，Wesley负责创建20多个组织的Tasktop集成网络，通过Tasktop的技术实现互操作性。在这一角色中，Wesley和Tasktop团队还和IBM、HP、CA Technologies等公司建立起10个OEM销售合作伙伴关系。Wesley是“生命周期协作开放服务（Open Services for Lifecycle Collaboration，OSLC）”倡议指导委员会的成员，该倡议旨在标准化软件生命周期工具彼此之间共享数据的方式。 |
