测试驱动开发(TDD)和行为驱动开发(BDD)现在已经成为广泛应用的软件开发技术。然而,仅仅遵循BDD 和TDD 还是可能导致丧失业务机会,甚至可能对业务产生负面影响。TDD 和BDD 有两个无法回答的问题:如何衡量应用的使用状况?如何得到客户的反馈?
传统的用户调研方式并不一定完全具有说服力,可能要占用应用提供者和客户很多时间,而且会受到偏见影响。 Nathaniel Talbott 在 RubyConf 2009 大会中的演讲中提出了自己最初的想法:业务应该采纳 TDD 在开发中的方式,为客户提供反馈:
(图片来自 Labnotes )
软件开发主要的问题在于正确识别要解决的问题,从而避免“造成浪费的生产机器”。为此,我们需要一种新的方式来衡量事实,而不是意见(或自大),这样一来,我们就能更好地衡量我们的应用在真正工作时的使用状况了。
TDD 是为了设计并验证代码。EDD 以跟踪目标的方式来检查业务是否正常工作。
EDD 框架基于 A/B 测试,该测试起源于市场调研方法,会将基线受控样本与多种单个变量的测试样本进行对比,以判断哪两种选择会提升响应率。
Assaf Arkin 是 EDD 框架 Vanity 的作者,他这样描述 EDD :
EDD 是基于事实的软件开发。CEO 们告诉自己的小姨子、小舅子们一些公司里的故事,由此而产生的意见和看法会成为一些软件的需求来源。EDD 与此类开发方式完全相反。EDD 从想法开始,为了衡量这些想法,EDD 会征集真实人群的反馈:你的客户、网站的访问者、使用自己开发的软件的人等等。EDD 以迭代的方式寻找证据。 TDD 和 BDD 提供的工具能够帮助我们改善代码质量,并保证我们的代码能够完成规格说明的要求,而 EDD 帮助我们找出要开发哪些特性,以及从何入手:它帮助我们发现将会成为规格说明的东西。
使用 Vanity 这个 Rails 插件,A/B 测试可以通过以下 5 个步骤完成:
- 定义一个 A/B 测试: ```
experiments/price_options.rb
ab_test “Price options” do
description “Mirror, mirror on the wall, who’s the better price of all?”
alternatives 19, 25, 29
metrics :signup
end
2. 为用户展示不同的选择: ``` <h2>Get started for only $<%= ab_test :price_options %> a month!</h2>
- 使用 track! 方法衡量转换程度: ```
class SignupController < ApplicationController
def signup
@account = Account.new(params[:account])
if @account.save
track! :signup
redirect_to @acccount
else
render action: :offer
end
end
end
4. 生成报告: ![](https://static001.infoq.cn/resource/image/77/17/77b05fb54c30a1cf7ba4613c4bef5517.png) (图片选自 [Labnotes](http://labnotes.org/)) 5. 观察收集的数据,衡量表单的效率: ![](https://static001.infoq.cn/resource/image/42/ab/4285d9b2dfac0b70ad65b6b7a7a061ab.png) (图片选自 [Labnotes](http://labnotes.org/%C3%B7)) 为了了解更多 EDD 相关的内容,InfoQ 与 Assaf Arkin 进行了交流: **InfoQ:** 你是如何产生 EDD 这个想法的?是在为自己的新项目 [apartly](http://apartly.com/ "apartly") 尝试了 [A/Bingo](http://www.bingocardcreator.com/abingo "A/Bingo") 之后?还是通过 Nathaniel 的演讲? > [Nathaniel](http://blog.talbott.ws/ "Nathaniel") 提出了 EDD,我就是咖啡喝多了。 在 RubyConf 几周前,Nathaniel 逗留在旧金山,我们一起吃了午饭。那时,我正在为 Apartly 设置一系列试验。我使用 A/Bingo 分割测试,Google Analytics 做某些度量,用其他东西做数据库查询。 > > 设想一下,数据来自三个不同的地方,我得把它们弄到一起,生成报告。这可不容易,因为 Google Analytics 不知道 A/B 测试,而 A/B 测试也不知道 Google Analytics。每个试验中还存在代码测试路径的问题。这时你要如何测试你的试验和衡量指标呢? > > 喝过咖啡后,Nathaniel 把他要演讲的内容给我做了一个“电梯演讲”。听起来就像我当时正在做的,不过他已经提出了方法论,而我正在想办法东拼西凑。 > > 然后他提到了重点部分。EDD 是一个概念框架,一种通过试验思考、构建、度量和精化代码的方式。如果已经有了一个实际的框架能够完成纯体力活,这样我们仅仅写少数几行代码就能编写试验,那该多好?我听到之后,脑子里马上就有声音在不停告诉我:“官人我要~~” > > 从那时起,这个声音就一直在我脑中回荡,到 [RubyConf](http://labnotes.org/2010/02/04/how-tdd-missed-the-point-introducing-edd/ "RubyConf") 之前,我用不长的时间开发完成了一个框架。它必须是功能最小化、但是切实可行的 EDD 框架,带有足够好的文档,并在生产环境中使用一段时间。除非我相信它能在生产环境中使用,否则我不奢望别人使用这些代码。 > > 这就是 Vanity 产生的故事。 **InfoQ:** 目前主要是什么在驱动你的开发?测试?行为?试验?这个比率跟项目的成熟度有关么? > 我把 EDD 和 TDD 放在一起用,而且无法想象只用一个是什么状况。 我们是一个小创业公司,有很多雄心壮志,很多想法。把这些想法转化成完美的产品和可行的市场,需要一段时间。我们早期的一些直觉可能是对的,一些可能需要调整,有些方法可能被证明不靠谱。这是创业公司的常态。成功的关键在于快速迭代,在钱花光之前发现完美的 [产品和市场组合](http://www.amazon.com/Four-Steps-Epiphany-Steven-Blank/dp/0976470705 " 产品和市场组合 ")。 > > 那就得像忍者那样写代码。用最小的付出得到产出,这样就能测试当初的直觉正确与否,验证想法是否可行。 > > 我们没有时间让代码过度工程化,以应对所有的“万一”情况。大多数情况下,6 个月的时间内,我们就会在发展方向上做出改变,因为市场告诉我们这么做,而且突然间我们就得丢掉不需要的功能了。那时,你就会对自己当初没有过度开发感到庆幸。 > > 做到精益的另一方面在于去除多余的库存。我们不能承受垃圾代码和死亡特性的拖累。我们移除特性的速度和添加的速度一样快。 > > 看清脚下的路,这让我们能够自由试验不同的想法,因为犯错的后果没多严重。只要你没有进行大批量的前期开发,或是承诺在特性上维护多年,你就能随意尝试不同的东西。如果一种试验没有成功,扔掉它,再试试别的吧。 > > 要想这么做,代码必须易于改变,易于调试,而且足够可靠,才能做到持续部署。我们需要好的测试套件,以保证不出问题。现在我们的代码与测试之比为 1:3.4。我们有单元测试、功能测试和基础测试,它们在后台持续运行,这要感谢强大的持续集成服务器软件 Autotest,它帮我们发现开发机器上的 bug,还能在预发布服务器上运行,以应对部署方面的问题。 > > 因此,这些防线防止我们把有问题的代码送出去。TDD 在控制代码质量上就扮演这样的角色,并允许我们试验新想法,快速做出产品变更。但是你如何判断改变什么呢?哪些想法值得探索? > > 我们都从直觉开始,但仅有直觉永远不够。从纽约时报上读到创业公司的故事,看起来总是创始人们有了一个好主意,然后马上就挖到了第一桶金。这些故事让人感觉很好。可实际上,创始人们有无数的主意,其中大部分都是垃圾,有一些还算可以,只有最好的才能被人记住。成功的创业公司会倾听市场,然后追随少数几个可以胜出的想法。 > > 我们采取迭代的方式开发,但是我们的迭代不是为了完成下一个特性或是推进特性列表的开发。迭代是为了尝试,更多地了解客户,再使用这些知识判断下一个迭代要做什么。我们的进度度量使用 Eric Ries 所称的“[经验证的学问](http://www.startuplessonslearned.com/2009/04/validated-learning-about-customers.html " 经验证的学问 ")”。 > > 你的客户最关心哪些特性?哪些变化能让他们更开心?哪些功能没人关注,你可以放心移除?如果同一件事情有两种方式可以完成,你会采取哪一种? > > EDD 可以回答这些问题。它把一个想法放到实际情况中,查看反应情况,以此测试这个想法在实践中的实际情况。EDD 和 TDD 是互补的,没有 TDD,我们无法完成准时(Just-in-time)开发、快速迭代和多种试验。没有 EDD,我们也许能开发出质量极高、刀枪不入的代码,可是没有人用。EDD 能帮我们找到一款杰出软件的秘密配方。 **InfoQ:** 你认为 EDD 可以用在任何类型的软件开发之中么?有没有想过它是否适用于过度工程化的 Java 工程项目,或是类似于你之前在 Intalio 开发的应用?它是否仅仅适用于高访问量的网站? > 人们有个印象:A/B 测试讲的是渠道、转化率和登陆页面【译注 1】。市场研究的相关人员已经多年使用统计方法来分析和细分市场。他们把这些实践带到 Web 上,让我们无法逃避阅读 A/B 测试和登陆页面优化。 A/B 测试不仅仅是登录表单。实际上,大多数试验与登录表单或是市场活动没什么关系。 > > 作为软件开发人员,我们的工作不仅仅是构建功能特性并确定它们能正常工作。重点在于构建有用的功能,人们会使用这些功能并从中受益。如果你是软件开发人员,你是否仅仅为了构建而构建,还是为了某个客户而构建呢?你是否愿意开发没有人会去用的代码?还是愿意开发很多人都觉得有用的代码? > > 我们种很多人都有兼职项目,因为这让我们对某款软件的某个部分负有完全的责任,而且对我们的每次决策要完全承担其后果。 > > 我可以用一个问题总结我们在 Apartly 上的开发过程:“它能拨动指针吗?" > > 我们对好几个度量指标感兴趣,比如注册数(获得)、邀请数(推荐)、订阅数(收入)等等。这些都是指针。使用我们所能获得的有限资源而做的一切,都要在这些度量指标的某一个上取得成果。也许我们能得到更多的注册人数,也许是更多的回头访客,也许是 Twitter 上更多的击节赞叹。 > > 不仅每个人都能看到这些指标,而且它们也已经被植入到开发过程之中。度量指标和试验是代码库的一部分,它们被签入到源代码控制系统种,并经历测试和预发布过程。 > > 测试有限开发会让人先写一个失败的测试,然后开发必要的代码以通过测试。与之类似,我们会先从一个基线指标开始,然后编写代码让这个指标向期望的方向变化。(一般都是向上的,不过有些指标,比如每分钟的 WTF 个数【译注 2】,一定是要向下的。) > > 能否把这样的方法应用到大规模流量网站之外的应用?总是有一个度量指标能够说明问题的。当你用消息队列方式替换同步交互之后,能否改善响应时间?是否降低服务器在高负载下的故障发生几率?是否更易于部署新的服务?简而言之,是否有任何可度量的效应,或是以前浪费的工作量现在看起来更好了? > > 如果没有任何可度量的结果,那就会导致启动很多开发工作,因为解决问题听起来很有趣,而且继续存在,因为无法证明它所导致的效率低下,同时已经成本已经沉没下去了。只要引入度量指标,有趣工作的定义就变化了。突然之间,某些工作变得有趣,因为你能看到后果。 > > Nathaniel 提出的 EDD 框架需求列表的第二点就是“各个层面都能访问得到”。不能只是面向客户。我们希望在软件栈的各个层面都能度量。而且每个组件都要负责,证明它的价值。 **InfoQ:** 很难衡量 TDD 和 BDD 的 ROI,而且结果也许无法马上显现出来(当然更不可能是实时的了)。这样一来,可能很难说服管理层和决策人员利用 TDD 和 BDD 的好处。有没有可能 EDD 因为可以提供直接和可量化的数据,而被管理人员青睐? > 悲哀的是,我不认为 EDD 能够让你的猪头老板(Pig Head Boss)变得更聪明、更讲道理。 IT 部门,扩展到很多业务和企业软件公司,对于用户有一种偏执。当你不必听从用户的时候,有时就会树立起一种围绕着客户的文化,开支票的人或职位就是客户。客户总是对的,他们也不会容忍任何并非他们提出的变更,因此他们希望看到一个路线图,看到从 0 到 100% 的持续进度过程。这是典型的瀑布式方法。 > > 在另一端,有这样的公司和项目,他们无法强迫人们使用自己的软件。他们必须讨好自己的用户,让用户高兴,让用户的生活在某方面变得更好。衡量成功的方式不是看在财年结束时完成了多少功能,而是赢得了多少用户。 > > 当你以交付功能的方式度量成功时,绘制精美的甘特图就是你的指路明灯。还可能把甘特图放大,贴在办公室最大的那面墙上。如果以客户的满意度来度量成功会发生什么?让市场部门把自己的季度董事会报告在整个公司里面流传么?这在交付和反馈之间可是有三个月的延迟啊。 > > 有些公司会在角色扮演练习中产生用户原型,并围绕着这个想象出来的用户原型设计软件。其他公司已经想办法实施充满寓意的“吃你自己的狗食”,有些公司只开发自己内部也会用到的软件。可如果你的市场不是软件开发人员怎么办? > > 如果你理解软件的运作方式,就能知道按代码行数衡量工作效率毫无意义。通过特性或故事点数衡量软件也好不到哪里去。二者都是在衡量和优化优先级次高的效果。工作效率没告诉你多少有用的东西。 > > 反之,选取最重要的业务度量指标。Dave McClure 给它们起了个绰号:“[海盗的指标](http://www.slideshare.net/dmc500hats/startup-metrics-for-scottish-pirates-aarrr)”,包括获取率、激活率、保持率、推荐率和收入。雇佣最聪明的人,包括开发团队,找出如何提升获取率,提高保持率,增加收入。 > > 目的不是为了获得业务上的量化回报。如果量化回报必须从市场部门逐渐转向开发经理,再下放到团队主管,那就会出现带宽和延迟方面的问题。关键是要把开发人员直接放到第一线去,把度量指标植入流程之中,度量关键的业务目标。 > > 我将其称为“后敏捷”,因为它构建于敏捷的成功基础之上,但是用“可验证的学问和关键指标”替换“可工作的软件作为进度的基础度量方式”。EDD 之于“后敏捷”,就像 TDD 之于敏捷。 EDD 会在未来几年成为标准吗?它能否提供坚实有力的成效?还是仅仅是另外一个以 DD 结尾的缩略词?您怎么看? ** 查看英文原文:** [Experiment Driven Development - The Post-Agile Way](http://www.infoq.com/news/2010/02/edd-post-agile "Experiment Driven Development - The Post-Agile Way") ** 译注 ** 1. 渠道(funnel)、转化率(conversion)和登陆页面(landing pages):这三个词都是在线网络营销的常用词汇。funnel 表示网站方希望访问者为达到某个目标而使用的页面路径。详细解释可参考 [Google Analytics 的解释](http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55580)。网站转化率,是指将网站访问者转化为常驻用户的比率。登陆页面(landing page)是指网站访问者通过点击站外链接到达当前网站的页面,可能是主页,也可能是网站中其他页面;可参考 [Wikipedia 页面](http://en.wikipedia.org/wiki/Landing_page "Wikipedia 页面 ")。 2. WTF:粗口“What the fxxk”的简称,WTFs/m 的含义,可参考 [该页面](http://www.osnews.com/story/19266/WTFs_m)。Bob 大叔在自己的 [《Clean Code》](http://www.douban.com/subject/3032825/) 一书中对此也有引用。
评论