关于Voke 公司报告的评论：敏捷方法提供了更高的客户满意度和质量

Voke report: Agile delivers higher customer satisfaction and quality

关于Voke公司报告的评论：敏捷方法提供了更高的客户满意度和质量

There’s been a lot of controversy generated by Voke’s Agile Realities report. SDTimes asked me to comment for their article covering the report, and so I got to read it in full. Obviously Voke want your money to read the whole thing so I am constrained by fair use as to what I can reproduce in this review, but my general conclusion is that the report represents a hatchet job on agile whose most important conclusions aren’t sustained by the (interesting and revealing) data they have gathered.

Voke公司（一家基于数据分析的公司，关注应用软件生命周期和它的全球化转换译者注）的报告“敏捷困境”引起了广泛的争议。SDTimes（一家软件行业新闻杂志译者注）要求我为其关于该报告的文章写一篇评论，所以我不得不读完整篇报告。显然Voke公司希望你付费来阅读他们的整篇报告，因此我在本评论中能够合理使用的报告原文就受到了限制，但是我的总的结论是：Voke的报告是对敏捷方法的恶意攻击，其报告中收集的数据——尽管很有趣也很有启发性——支持不了其报告中最重要的结论。

From the press release, we can discern that Voke draws the following conclusions from their research:

基于已发布的新闻，我们可以得出Voke公司的研究结论如下：

•“The average cost of software projects is rising dramatically, in spite of smaller teams working much shorter durations” – it is implied that this is due to agile adoption.

“尽管软件项目的团队小了，工作周期也缩短了，但是项目的平均成本却正在大幅上升”——报告暗示这是因为采用了敏捷方法造成的。

•“Survey participants shared their experiences with Agile, expressed confusion, and identified more real world challenges than benefits”

“被调查者分享了他们关于敏捷方法的经历，表达了他们的困惑，说出更多的是敏捷方法遇到的现实挑战而不是它的好处”

•“Given the impact of catastrophic software failures on the brand, we should be witnessing a movement toward increased quality.” – the implication being that Agile produces lower quality software.

“鉴于灾难性的软件故障对于品牌造成的影响，我们希望看到提高质量的运动”——言下之意，敏捷方法产生的是低质量的软件。

•Executives are buying agile because they think it means business agility. Voke, as we will see, think that this is nothing less than a bait-and-switch exercise by the Agile community.

管理者购买敏捷方法因为他们认为这意味着业务上的敏捷。Voke——我们将会看到——认为它不过是敏捷技术社区的一个偷梁换柱的把戏。

In the actual report, Voke make three further high-level claims. First, they say Agile is effectively a Trojan horse for developers to gain control over the software delivery process, so they can avoid doing boring things like documentation, design, and planning. Second, they say it is primarily a vehicle for consultants like me to sell services, training, and books (curiously, they omit that analysts do quite well out of it too). Finally, they claim that the useful core of Agile is nothing more than rapid prototyping – which is nothing new. So it’s fair to say Voke aren’t keen on Agile (and while I am paraphrasing here, I am attempting to faithfully preserve the tone of the original).

在实际的报告中，Voke进一步作了三个高层面的断言。首先，他们声称敏捷方法是一种有效的木马，让开发人员能够控制软件交付过程，这样他们就不用做写文档，设计，规划之类的无聊工作。其次，他们声称敏捷方法主要是像我这样的顾问用来出售服务，培训和书籍的一个工具（奇怪的是，他们无视了分析师们用它工作也非常管用的事实）。最后，他们宣称敏捷方法最有用的核心无非是快速原型——这也没什么新鲜的。因此，公平的说，Voke对敏捷方法可不怎么热衷（尽管改述了报告，我也尽量忠实的保留原报告中的口气）

However, while they say – correctly in my opinion – that companies are confused by Agile, Voke certainly aren’t in the business of helping. Voke make basic mistakes (or misrepresentations) in their opening discussion of Agile, Lean and Devops. The most egregious of these is around the role of quality in these movements, which they claim exclude QA and thus represent a move away from increased quality. In support, they cite the fact that the Agile Manifesto and the name “Devops” nowhere mention quality1. This ignores the fact that building quality in is central to every good discussion of lean and agile development. Indeed not only do agile methodologies emphasize the importance of cross-functional teams (including business, QA and operations): Agile practitioners pioneered engineering practices such as test-driven development, continuous integration and refactoring which (as the report acknowledges) substantially reduce the cost of discovering and fixing defects.

然而，尽管Voke声称敏捷方法令公司困惑，————在我看来事实也是如此————Voke也只能让公司更困惑。Voke在其开篇关于敏捷，精益与Devops（是一组过程、方法与系统的统称。译者注）的讨论中犯了一些最基本的错误（或者做了一些歪曲的陈述）。其中最严重的错误是关于敏捷运动中质量的角色，他们声称排除了QA就意味着远离了更高的质量。作为其结论的支持，他们引用了敏捷宣言和“Devops”这一名词中没有一处地方提及质量的事实（注1）。这个结论忽视了这样的事实，即把质量建立其中是所有好的精益与敏捷开发讨论的中心议题。确实，不仅是敏捷理论强调跨功能团队（包括业务，QA，运营）的重要性：敏捷测试的实践者们也开创了诸如测试驱动开发，持续集成与重构等工程实践，这些实践——正如Voke的报告中承认的——大幅降低了发现与修复缺陷的成本。

Let’s address another claim: that the cost of software development has increased substantially since 2008 – the date of an earlier “Agile Realities” report. What their numbers in fact show is that the average2 project cost has stayed the same whereas the average project duration has decreased. This subtlety aside, Voke are making the same mistake as many enterprises that treat IT as a cost center: focusing on development cost instead of return on investment. As noted by Douglas Hubbard, author of How to Measure Anything, “even in projects with very uncertain development costs, we haven’t found that those costs have a significant information value for the investment decision… The single most important unknown is whether the project will be canceled… The next most important variable is utilization of the system, including how quickly the system rolls out and whether some people will use it at all.” Thus getting a quality product that incorporates customer feedback for the same price as getting a mediocre one, but in a third less time (the numbers reported by Voke) represents an incredible deal. According to Voke’s own numbers, technology companies using Agile methodologies – uniquely – had zero projects abandoned after development.

让我们再解决一下报告的另一个断言：软件开发的成本自2008年——上一篇“敏捷困境”报告的日期——以来大幅提高。他们的数字事实上显示，项目开发的平均成本（注2）保持不变而平均项目周期却缩短了。撇开这个微妙的错误不谈，Voke犯了一个跟许多公司一样的错误，那就是把IT部门作为成本中心：关注软件开发花费的成本而不是投资回报。正如《如何衡量事情》一书的作者道格拉斯.哈伯德所指出的，“甚至在那些开发成本非常难以确定的项目里，我们也没有发现成本对于投资决策来说有什么重要的信息价值…唯一一项最重要的未知因素是项目是否会被取消…第二重要的变量是系统的效用，包括系统能多快推出和会不会有人用它。”因此，用与买一个平庸的产品相同的价格，买到一个包含了客户反馈的高质量产品，却还少用了三分之一（数字来自Voke的报告）的时间，是个不错的买卖。根据Voke自己的数字，只有采用敏捷方法的技术公司在项目开始开发后才达到了项目放弃数为零。

The real news – which Voke hide away towards the end of the report on p32 – is that technology companies and enterprises both report higher levels of customer satisfaction and lower levels of unfixed critical defects (so much for Agile’s quality problem) when their projects use Agile methodologies. However enterprises do worse than technology companies: a large majority of technology companies report customer satisfaction when using agile methodologies, compared with a smaller majority of enterprises3.

真实的消息被掩盖在Voke公司报告的第32页接近页末处，那就是技术公司和企业在项目运用了敏捷方法后，都报告了顾客满意度提升和未被解决的重要缺陷减少（关于敏捷的质量到此为止）。但是企业比技术公司的表现差强人意：技术公司中的绝大多数报告了应用敏捷方法的顾客满意度，报告顾客满意度的企业尽管也占多数，但是相较而言，比例较低。（注3）

Unfortunately the authors do not address the wider macroeconomic issues: in the period from 1958 to the present, the lifetime of an S&P 500 company has shrunk from 61 years to only 18 years. This period is contemporaneous with the rise of software development and the fall of traditional manufacturing. Today enterprises are being challenged by technology-powered start-ups which are able to leverage Lean and Agile methodologies to create a competitive advantage (most VCs wouldn’t consider funding a non-Agile start up). Thus the failure of many enterprises to implement Agile at scale, noted by the authors, is indeed a serious problem. However this problem cannot be addressed by recycling FUD from ten years ago, such as claims that Agile methodologies don’t believe in any documentation or design.

不幸的是，报告的作者们没有解决一个更广泛的宏观经济问题：自1958年至今，标普500成分股公司的生命周期已经从61年缩减到18年。这一时期是与软件开发的崛起和传统制造的衰落同步的。如今的企业正面临技术驱动初创企业的挑战，它们能够运用精益与敏捷方法创造竞争优势（大部分风投根本不会考虑资助非敏捷初创企业）。因此，很多企业大规模实施敏捷的失败，正如报告的作者们指出的，确实是个严重的问题。但是，这个问题并不能通过十年前的FUD的老把戏来解决（FUD:恐惧、不确定、怀疑的缩写，是指为了使计算机用户不愿采用竞争者的产品，而故意让他们认为其产品设计是不可靠的心理策略。），比如断言敏捷方法不相信任何文档或者设计。

The data in the report thus makes for interesting reading – although I would have liked to see more statistical analysis, correlation, and some graphs. Unfortunately the analysis is mostly worthless, except as an exercise in twisting the data to suit the authors’ agenda.

因此，这篇报告中的数据读起来很有趣——尽管我希望看到多点数据分析，相关性和图表。不幸的是，里面的分析大部分是毫无价值的，除了用来练习扭曲数据来迎合作者们自己的想法。

--------------------------------------------------------------------------------

1 Although the word “quality” doesn’t appear in the Manifesto, the 9th principle states that “Continuous attention to technical excellence and good design enhances agility.” One of Voke’s claims is that the Agile Manifesto is an inadequate guide to implementing Agile. While this is true, it was never the intention of the Manifesto to define how to implement Agile, or even to be a complete guide to Agile. The intention was to abstract out the core message of a number of “lightweight” methodologies that were gaining traction in 2001 (Martin Fowler and Jim Highsmith provide some history on the Manifesto, including a discussion of quality, here). It is of course these methodologies that provide the level of detail that Voke’s authors are missing. As Martin Fowler says, “Agile is a mind-set, described by values and principles – not what most people would understand as a methodology that would include practices and deliverables” – more in his RigorousAgile bliki entry.

1.      尽管“质量”一词在宣言中没有出现，第9项原则陈述了“对技术卓越和良好设计的持续关注提高了敏捷度。”Voke的断言之一是敏捷宣言对于实施敏捷是不充分的指南。尽管事实如此，但是宣言从来没有被用来定义如何实施敏捷的这项意图，甚至也没有作为敏捷的完全指南的意图。宣言的意图是抽象出2001年引起关注的许多“轻量级”方法论的核心信息。（(Martin Fowler和Jim Highsmith提供了宣言的一些历史，包括关于质量的讨论）。这些方法论当然能够提供出Voke的作者们想要的那些无关紧要的细节。正如Martin Fowler所言：“敏捷是一种通过价值和原则描述的心态——而不是大多数人所理解的那种包含实践和产出成果的方法论”-在他的RigorousAgile bliki条目中有更多内容。

2 Voke don’t say what kind of average they have used, nor do they provide standard deviations or correlate the data in any way. There aren’t even any graphs.

2.      Voke没有说出他们用什么样的均值，也没有提供任何方式的标准差或者相关性数据。甚至都没有任何图表。

3 I’m not going to give the actual numbers here because I think it crosses the line of fair use – you should buy the report if you want the full scoop.

3.      我在这里不会给出具体的数字，因为我认为这跨越了合理使用的界限——如果你想读整篇报告你应该自己买报告。

原文地址：http://continuousdelivery.com/2012/07/voke-report-agile-delivers-higher-customer-satisfaction-and-quality/

本文出自“shadowwalker”博客http://www.51testing.com/?622454，转载请保留出处