原因才是真正的关键问题

上世纪九十年代，我们在软件开发领域遭遇了史无前例的低迷局面。编程开始成为一种主流行业，而不再是少数天才的专利——这对我们来说非常可怕。但这一切在 2001 年得以转变，众多睿智头脑的激情碰撞开始给整个产业带来前所未有的重大影响——虽然我的这一论断未必能得到他们的认同。他们最终拿出的成果解答了上世纪九十年代困扰所有人的大问题——通过创建社区，让思路相近的人们一同探讨如何更好地实现软件交付。如今敏捷化开发趋势已经广泛铺开，我们也已经在软件开发方面获得一个又下一个辉煌的胜利——然而新的问题也由此产生。

给我（Gordon）印象最深的一句名言是“不要把交响乐谱写与音乐本身给人的触动混淆起来。”只有少数天才能够创作出震撼人心的交响作品，而作为普通人，我们只能安静欣赏并从中获得属于自己的灵感与喜悦。

也许有点跑题，但我个人认为这个比喻在软件开发领域也同样适用。在我看来，我们常常会把如何漂亮地解决代码问题、如何保质保量完成编码工作甚至是否利用正确设计或方式以正确的语言进行开发视为重点。请容我解释，这些当然很重要，但绝不能算作关键。真正决定一款软件是优秀还是伟大的因素不在于此。遗憾的是，这恰恰是很多软件工程师所关注的唯一因素。

困扰了软件项目与产品交付任务多年的一大难题在于，我们到底应该开发出什么样的成果。一般大家的回答会是“用户想要的”，但很多用户甚至根本不了解自己的需求，由此盲目推出的产品显然无法令人满意。

在大学里，一位导师给 Gordon 讲了一家美国汽车制造商的故事。当时这家企业进行过一项调查，询问人们希望在汽车里看到哪些设备以及印象中美国汽车应该具备哪些特色。最终结果？当然是彻底失败了。虽然这类开放性话题往往令答案变得非常复杂，但在这个案例中，我认为最大的问题在于汽车用户与汽车设计师之间存在本质差别。

同样的情况在计算机用户方面也有反映；他们大多能够肯定地指出自己不喜欢的产品设计，但却无法从零开始帮我们设计出完善的系统化产品。跟大部分人一样，他们善于从视觉或听觉角度做出主观评判。虽然开发人员也希望能从根本上实现这些终端感受，但却绝不会仅仅以“感觉”这种无法捉摸的角度进行产品设计。想根据这些角度的反馈定义出准确且具备操作性的开发方案几乎是不可能完成的任务。

在斯坦迪集团于 2002 年针对成功交付组织的调查中，我们发现 80% 的交付特性甚至从未或很少得到使用。即使这一数字并不完全准确——因为我不知道他们是怎么统计到这个结果的——我仍然表示赞同，因为就在我所使用的这款文档编辑工具中，就存在一大堆我从来没用过甚至根本没听说的功能与特性。我的朋友，同时也是软件交付创新领域的合作伙伴 Russ Miles 曾经通过记录发现，他“在 1987 年前后推出的 Mac 版微软 Word 1.04b 版本中即可实现目前的所有日常操作。”这可绝不只是“软件膨胀”的老调重弹了，而绝对是一种巨大的浪费。浪费金钱、浪费精力，而且最重要的是，它浪费了我们最宝贵的资源——生命。如果我们把注意力都集中在 Office 里的那个回形针吉祥物上，还能有什么空闲开发出真正革命性的划时代成果！

再举一个例子，我的手机上有很多同样毫无意义的特性。我要批评的并不是设备或者软件本身，而是替那些定义、编写并测试该特性的人们感到惋惜。即使是在最近十年来，全世界在软件开发方面投入的数万亿美元中有多少是毫无意义、毫无价值甚至是与开发目标背道而驰的？回头反思，这些开发出来的东西有用吗？也许《2010：太空奥德赛》真会成为现实。

我并不是说长久以来软件开发领域从未拿出过伟大的产品或者赢得过令人印象深刻的革命性进展。关键在于如今大部分软件特性都不具备实际意义。我得说这种状况就算不会令人抓狂也已经相当令人沮丧，尤其是对于那些真正有能力有意愿做出“交响乐”级别产品的人才而言。

敏捷已经成为主流，这种梦幻般的趋势有望推动我们将个体需求与交互感受提高到超越流程及工具本身的新层面。“敏捷宣言”是一种态度，旨在将最杰出的头脑与最成功的交付系统集中到软件开发领域中来。我们要做的是努力了解软件交付成功案例中的共性，例如协作负载、小批量开发以及定期对业务软件进行反思。这些因素能够最大程度保障软件交付获得成功，而不是被动接受大批量任务与大型项目所带来的高风险。

我担心的是接下来会发生什么。比如说，敏捷软件开发最终成为软件工程链条中的固有组成部分……然后整队出发！我们现在能够以惊人的效率实现产品交付，这是一次伟大的进步。数十年来，我们一直在努力将这一目标变为现实，也因此得到了理想的结果。然而正如 Russ 在他 QCon 伦敦 2013 大会上的发言所说，现在我们已经实现了“快速交付有价值软件”的目标，但接下来的目标应该放在如何完成“快速交付有价值变化”上。如果软件看似有价值实际却毫无用处该怎么办？如果软件定位只考虑到远景规划中的一小部分怎么办？也许我们已经花了十年时间打开水龙头、把嘴凑上去，却发现自己直接被呛到了……

产品交付周期的缩短与产品开发效率的提高令我们面临更大的危机——一旦出发点有误，速度越快结果就越糟糕。没错，利用高度协作等敏捷技术也能在更短的时间内迅速拨乱反正，但只抱着“我们的方向没问题”的心态就着手使用敏捷技术无疑太过幼稚。毕竟我们的开发团队还是由人组成，技术无法解决人身上存在的固有问题。

我们的朋友兼技术大师 Gojko Adzic 邀请我们参与到 2013 年二月的一次精彩聚会当中。他将一些最成功的软件业人士如今在一起，举办了这次仅持续一天却激情洋溢的研讨活动。我们花了很长时间讨论上述疑问，而 Gojko 则在他的博客中表达了自己的看法。

会议期间，其他与会者介绍了一些我们原先就关注过的技术以及从未在实际中见识过的新思路，他们每个人的观点都很清晰，而且努力帮助我们理解为什么 2001 年“敏捷宣言”成员无法认同“正确”软件交付方案这一说法——这也正是困扰我们的问题所在。每项技术都有自己的“正确性”视角及对背景的特定要求，因此我们需要牢牢抓住“原因”这个核心议题从事软件开发工作。

让 Gordon 最受触动的观点在于，技术人员需要利用可视化方法帮助企业领导者弄清为什么他们需要某种解决方案，而这一点在执行层面上难度极大。

这些都是在开发流程中真实存在的实践方案，帮助 XP 及 Scrum 尝试并最终实现理想中的敏捷诉求。这些框架同样也能帮助我们达到理想的效果。

此次为期一天的研讨会最终为良好的软件开发流程总结出以下几条原则：

1. 组织应专注于结果与影响，而非功能特性；
2. 团队根据来自产品用户的实时与直接反馈决定下一步方向；
3. 技术人员应该了解进行当前工作的原因；
4. 每位成员都拥有敬业精神。

我们将以上几条内容的顺序进行了重新调整，因为这样看起来才会有自然的承接关系。

这些原则完美体现了软件开发工作的全新关注重点，甚至足以成为我们改变业界规则的进军号角。套用一句比较通俗的说法，虽然站在“敏捷宣言”作者的肩膀上，我们以及整个业界其实才刚刚起步。但我们已经在交付工作上越走越远，这是个好现象。

现在是时候开始关注交付对象的正确性了，而这一切都要从反思自身交付软件的“原因”开始。正如 Russ 所说，“我们不（仅仅）是软件开发人员；我们要传递的是有价值的变化。”这就是软件开发业界在未来十年中的前进轨迹。要让这一点成为现实，其难度与推动敏捷开发成为主流方案不相上下，但对于未来的意义也同样重大。

欢迎走近成功软件交付的未来，而这一切的核心就是搞清“原因”。

作者简介

Russ Miles是 Simplicity Itself 首席顾问，并负责为客户持续提供有价值软件产品。Russ 的经历几乎涵盖了软件交付所有涉及的相关领域，包括金融服务、出版、国防、保险以及搜索等等。在超过十六年的咨询、指导及培训工作中，Russ 利用自己的一套历史性观点审视软件交流流程，借以寻求符合多方面持续改善需求的方案，其中包括开发者技能与实践；针对特定领域创建及改进最佳架构与设计；为各类企业管理工作提供精益与敏捷性建议，进而改善软件开发项目的投资回报率。Russ 还是一位国际性技术宣讲人，在向大家传播有价值软件交付经验的同时还撰写了由 O’Reilly 出版社出版的《深入浅出软件开发》一书。他目前正在努力撰写另外两本著作，其一为 O’Reilly 出版社的《编程之春》——书中首次公开 Simplicity Itself 技术所主张的“由测试驱动学习”这一观念；另一本则是《野外指南：软件交付团队成员持续改进》，其中搜集了各种可供专业软件开发者在持续改善工作中利用的思维工具与技术。

Gordon Weir是一位规模化敏捷与精益组织变革方面的专家。他自 1998 年以新西兰皇家海军身份获得年度新西兰年轻工程师荣誉起一路走来，曾经担任美国美林银行纽约分行技术部门主管，并在英国生活的十四年中先后从事过创业与银行投资顾问。这段漫长的经历令他对多元文化拥有深刻的认识，并了解如何帮助客户做出改变。

查看英文原文： http://www.infoq.com/articles/real-question-why

感谢杨赛对本文的审校。

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