ThoughtWorks CTO Rebecca Parsons 专访

敏捷澳洲会议于2012 年5 月30-31 日在澳大利亚墨尔本举行。该会议吸引了800 多名来自澳大利亚和新西兰的从业人员，以及世界各地70 多名演讲者。Rebecca Parsons 正是其中一名演讲者——ThoughtWorks 全球CTO。来自InfoQ 的Shane Hastie 采访了Rebecca Parsons，并就以下内容展开了讨论：Rebecca 在会议上的专题，她在敏捷联盟委员会的工作及ThoughtWorks 对于持续交付相关的持续设计的展望。

InfoQ：大家下午好，我是 Shane Hastie。现在我正在澳洲墨尔本敏捷澳洲会议上与 Rebecca Parson 讨论此刻正在发生的事件，Rebecca 在敏捷联盟中参与的工作，以及她在 ThoughtWorks 的 CTO 角色。Rebecca，欢迎你的到来，非常感谢你今天能抽空到来，接受 InfoQ 的访谈。

Rebecca：谢谢你，Shane。

InfoQ：我们通过参与敏捷联盟已经相互了解得差不多了，但是可能大部分观众对你还不是太熟悉，你能简短地介绍下自己吗？

Rebecca：我在商业软件开发行业所呆的时间已经长得我都不愿承认了。我总是讨厌做数学，但是实际上我从 13 岁时就已经开始编程了，我也经常告诉人们，我已经尝试过我们这行多个方面，以至于我可以道出“任意一块草地是否是绿的”。我从 1999 年加入 ThoughtWorks，因此我是少数真正参与 1999 年 12 月 31 日庆祝活动的较高级技术人员之一。而我也正因为当时并无要职在身而获以参与的。 我现在的职位是 ThoughtWorks 的 CTO，该职位包含致力于培养 ThoughtWorks 内部的技术人员；和广泛参与到整个技术社区去，其中包括大量的演讲和参与到类似敏捷联盟委员会这样的事务中去。

InfoQ：那我们开始讨论一些关于敏捷联盟委员会的事吧。作为敏捷联盟委员会成员及你在 ThoughtWorks 的角色，你能谈论下敏捷的方向，及敏捷社区正在发生着什么？

Rececca：有趣的是，现如今敏捷几乎已经成为主流了。它已经不同于当初我们与潜在 ThoughtWorks 客户的讨论：“好吧，你可以讨论类似概念，但是不能将其定死。”更多的人开始接受敏捷了。但任意类似改变在被更广泛接受的同时，也伴随着“紧接着将发生什么”的问题。当越来越多人希望自己能说“我在执行敏捷”的同时，他们也开始经历随之带来的难以避免的失败。而原因在于，尽管他们表示自己正在敏捷，但并非在执行敏捷实践或使用敏捷原则。

现在我们面临的问题之一是如何帮助人们理解成功执行敏捷所真正需要的，这样他们能理解并在失败出现时迅速定位出问题所在。 就敏捷联盟而言，我觉得有意思的是，随着敏捷更加主流化，联盟本身也需在其定位上做出改变。

在早些日子，提倡采用敏捷既教育人们什么是敏捷流程，同时也帮助完善敏捷定义。观察软件开发生命周期各方面以发现那些需要的变化，需要开发的工具，以及如何将这些需求加入到敏捷因素，并具体分类到开发、质量管理、数据库管理或架构中去。

现在敏捷已达到它的主流点，而联盟也需对它的定位做出相应改变。提倡对敏捷的采用现在更多的是扩大它的应用广度：我们是否在教育更多的人敏捷到底意味着什么？

尽管如此，另一方面，对敏捷、敏捷流程、敏捷工具和技术的更深理解同样比对敏捷进行更宽领域的推广更重要。人们对敏捷的组成依然存在着思想上的差距，联盟也需做出相应选择——往广度上发展，还是关注于深度？或者将两者兼顾？

在我看来，对联盟来说，这是一个非常重要的决定，应与更多敏捷社区讨论以寻求合适的途径。

InfoQ: 其中有一点我明确地观察到，人们一直认为联盟只是组织会议的。而现在它也在越来越多地提出类似敏捷改善计划及其他倡议。对组织未来发展趋势，我们也将拭目以待。

Rebecca：你所说的敏捷改善计划是个非常好的例子；联盟确实为它的会员提供了参与多种项目和活动的机制，其中一些能非常容易地将敏捷应用推广到那些还未涉足的市场，或对新领域进行更详细的探索；我鼓励联盟成员去发现那些我们还未覆盖到的范围，以及哪些项目可以用来填充这些范围。

InfoQ：现在身在澳大利亚的你在敏捷澳洲会议进行演讲的同时，还要看望 ThoughtWork 本地员工。你能给我们讲些昨天你在会议专题讨论上所做的演讲吗？

Rebecca：当然了。我进行了关于 NOSQL 数据库的演讲。而这个演讲是受我们 ThoughtWork 一美国员工的内部演讲所启发的，它基于他们为一零售业客户所做的一些工作，通过使用 NOSQL 数据库设计数据展示所带来的便捷，以及该技术如何简化了他们的流程，以允许他们执行敏捷开发的时候持续设计他们的数据展示。

该演讲涉及了来自 ThoughtWorks 的 Pramod Sadalage 和 IBM 的 Scott Ambler 在他们书中阐述的重构数据库所依据的基本原则。这些原则适用于关系数据库，而我也在观察是否能提炼这些基本原则，然后研究不同类型的 NOSQL 数据库以寻求如何让敏捷和 NOSQL 数据库相互支持。

InfoQ：那是否已经从中获得了某些结论呢？

Rebecca：当然，其中一个问题是 NOSQL 数据库这一定义并非是个好名字。因为某种程度上它将很多并不相同的事物绑在一起了。NOSQL 数据库有 4 个大类型：键 - 值储存，列存储，文档存储，图形关系存储，尽管列存储，键 - 值储存和文档存储之间具有统一形式和相似性，但图形关系存储却大相径庭。

在演讲中，我通过关注 MongoDB 作为文档存储的例子，以及 Neo4J 作为图形关系存储的例子，来展示如何通过两种不同 NOSQL 数据库演变你的数据显示。

它们对哪些事物容易演变，哪些事物比较困难上给出了非常不同的视角。但总的来说，至少现如今技术本身肯定在引导自身进行数据模型的持续演变，而这也是敏捷软件开发生命周期一个重要部分。

InfoQ: 因此紧接着的将来会有一些有趣的事情发生。而现在在 ThoughtWorks 正发生着什么呢？

Rebecca：显然，紧接于 Jez Humble 与 Dave Farly（ThoughtWorks 前员工）的合著，我们最近正在讨论持续交付。持续交付确实获得了众多的市场认可，但是我们却关注持续交付之后会发生的，及为什么会希望更快地交付。

现在我们极力思考的事情之一是：如果将交付实际上看成是对某一假设的测试，而这假设正是商业人士对如何提高他们的业务可能有的设想。随之，你可以设置一循环，围绕所设想出的某一假设，伴随决定其是否正确的估量尺度，快速将其通过软件执行出来。然后通过持续部署和随之快速的持续交付来快速测试该设想。

但我们现在发现这几乎难以执行，只是原地打转而已。我们开始思考如何去融合持续设计概念，如何发展产品，如何提高客户体验，如何试图在一块代码中去实现客户的期望价值。

现在你有一循环：该循环将从设计构想开始，并贯穿执行于代码；紧接着有一个测试阶段将通过交付的真实结果以实质地验证该构想是否正确。然后根据这一真实用户使用产品产生的实际数据来开始循环。

因此我们现在正在思考这一结合持续设计和持续交付的方法，及如何将这些概念绑在一起，以使用于该循环。实际上关键部分在于，设计出什么样的分析来支持该验证或推翻该构想，及在这个循环中如何与业务分析人员更自然地合作。

InfoQ: 那与之相对应的工具呢，该循环并非那么容易就能发生的？

Rebecca: 是的，在我看来，相对于其他工具，针对持续交付的工具实际上确实更先进。显然你需要更强大的版本管理产品，同时我们也花费了很多精力构想如何让 ThoughtWorks Studios Product GO 去支持持续交付的各个方面。而针对自动化架构，现在已经有比如 Chef 和 Pupper 的各种工具，它们对合理维护各环境以使测试和部署更简单至关重要。各种测试自动化工具对于整个持续交付也同样重要。

因此对于持续交付部分我们已经有着比较丰富的工具了。

针对整个敏捷用户体验及围绕它的工具，依然存在着很多工作，不仅它自己本身还在发展，而且我们也要考虑如何正确地将这些事物结合在一起。敏捷分析领域也存在着更多地思考和创新。在 Ken Collier 的书中，他不仅讨论到将敏捷流程应用于较传统的数据库存储和商务智能，同时也讨论到通过采用敏捷方式，我们对分析将获得怎样不同于传统数据库存储方式的视角。尽管如此，我认为依然需要很多改进，并思考敏捷分析是由哪些组成的，以及如何去实际执行他们。

我们觉得在 NOSQL 数据库中有很多优点，它们为我们如何看待和处理数据带来很多灵活性，同时我认为还有有待提高的地方。同样传统数据存储销售商也意识到，值型关系数据库并非处理数据存储中正执行的历史数据的唯一正确方式。

在以下几点我们将遇到同样的情况：当我们需要收集哪种类型的数据来帮助处理这一循环，理解引进改变所带来的影响，以及我们需要做哪些来持续改进。

InfoQ: 对于参与进来的人，他们在技能上都需要有哪些变化呢？

Rebecca：我觉得还是协作上的持续强调。我相信敏捷的优点之一在于它关注于角色，而非某个人从事某一特定工作。而且我们也在不断引进新角色。现在我们有敏捷用户体验设计师通过另一种方式来和分析人员讨论该改变将在它的某些可控制行为上展现自己。

与商业人员不同，我们与用户体验设计者及业务分析师建立起有别于商业人员同他们建立的关系，以获取相应的帮助；比如，如何将我的想法以一种更为假设性的方式来表达呢？因此我认为很多是现有角色不同于以往的合作方式；而且很明显的是，持续交付这一特征很大程度上强调了开发团队和执行团队之间的关系；因此整个开发 - 运维运动在这里也得到很好的适应。

围绕持续交付的讨论所带来的优点之一在于它为开发团队强调了执行团队一直在处理的问题。尽管你并不需要执行持续交付来实现开发 - 运维，但开发 - 运维的整个理念为打破开发团队与执行团队之间疆界的这一想法带来了极大的可能性。

InfoQ：非常有趣的话题，我们稍稍改变下话题：对于 ThoughtWorks，它的下一发展方向是什么呢？

Rebecca: 从地理上看：我们已经在二月份前往非洲，在约翰内斯堡建立了一个办公室；在几个礼拜后，我们在乌干达首都坎帕拉开办了一个中心；而我正是从加纳首都阿克拉前来堪培拉的，我们在研究是否有可能在那开设一中心用以服务整个西非，包括尼日利亚这样相对大的国家。我相信在非洲五人中就有一个人是尼日利亚人，因此这是一个你不想忽略的市场。

另外，我们也花费了很多心思考虑什么是想要玩转这个循环所需要的东西；将持续设计和持续交付联合起来到底意味着什么，及它将如何影响我们的工作。

敏捷分析，也是我们的主要关注点之一：针对它的实际影响以及如何开始将企业所面临的重要商业智能问题融合到敏捷流程中去。

因此我认为这些点都是我们要关注的。我们在关注敏捷用户体验中的持续设计的同时也分开考虑持续交付。但是我们也非常兴奋地看到将持续交付放入这个循环的可能，它们将互相补充。

InfoQ：一段非常有意思的时光。Rebecca，非常感谢你今天在会议之余与 InfoQ 的对话。

Rebecca：非常感谢你，Shane。这是我的荣幸。

About the Interviewee

Revecca Parsons 博士是 ThoughtWorks 的 CTO。她拥有长达 20 多年的应用开发经验，涉及电信至新兴互联网服务。她曾发表文章于编程语言和人工智能等出版物上，服务于各种程序委员会，并为多个刊物进行审核工作。她在领导大规模分布式对象的应用创建和不同系统的集成上有着丰富的经验。 在加入 ThoughtWroks 之前，她曾是中弗罗里达大学的计算机科学助理教授，讲授编译，程序优化，分布式计算，编程语言，计算原理，机器学习和计算生物学课程。与此同时，她也在洛斯阿拉莫斯国家实验室任主任博士后研究员一职，并行研究以下课题：分布式计算，遗传算法，计算生物学和非线性动力系统。

Rebecca 于布拉德利大学获得计算机科学和经济学学士学位，于莱斯大学获得计算机科学硕士及博士学位。此处连接 Rebecca 的博客。

查看英文原文： An Interview with Rebecca Parsons - ThoughtWorks CTO

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。