2011年12月份上海的AgileTour大会上，Gojko Adzic 发表了一个题为 Take the business along for a ride 的演讲。演讲中的一个故事我至今印象深刻，故事的主角是F-16战斗机，它的最初的设计需求是飞行速度要达到2-2.5马赫，首席设计师 Hillaker 询问美国空军为何需要如此快的飞行速度，答复是“飞机必须能从战斗中逃脱”，然而，意外的是，Hillaker 的最终设计并没有达到2马赫，但通过无框气泡式坐舱盖、倾斜的座位、侧装式控制杆等等诸多创新技术，飞行员可以非常敏捷地从战斗中逃脱，并且这样的设计生 产成本更低！看似明晰的“2.5马赫”并未有效地传达真正的需求，那只是一种解决方法，Hillaker 通过理解真正的需求而给出了更好的设计，这是成功产品设计的本质！
Gojko Adzic 是《实例化需求》的作者，该书在 Amazon.com 获得了超过了20条的几乎全五星的评价，而在今年的9月，本书又获得了软件开发图书领域最富盛名的 Jolt 大奖!这一奖项意味着《实例化需求》基本是上从2011年6月到2012年7月这一年中对软件行业影响最为重大的一本书。
这到底是一本什么样的书？它与我在本文看透提到的故事又有怎样的联系？在第一章 Gojko Adzic 就清晰地说到：
在过去的十年里，软件开发社区致力于使用“正确”的方式构建软件，关注使用技术实践和思想来确保质量。但是，正确地构建软件和构建正确的产品是两码事，我们要二者兼顾才能取得成功。
这是一本讲述如何构建正确产品的书。
我们的行业太需要这样一本书了！往身旁看看，程序员醉心于技术而不太关心为什么要开发手头的产品特性；客户说不清楚自己到底想要什么；业务分析师筋 疲力竭地试图理解客户真正的需求并传达给程序员；测试人员一遍又一遍地运行着手工测试。大家辛辛苦苦忙活好半年，出来的产品特性中有百分之多少有真正的业 务价值的？又多少产品特性其实是无法给项目干系人带来收益的？再看一看当今流行的敏捷方法论，例如极限编程和 Scrum ，在如何构建正确的产品方 面它们其实并没有太具体的论述。Scrum 是抽象的框架，定义的内容非常少，在如何与客户协作方面它只定义了几个角色的一些必要的会议；极限编程中有一条实践叫客户测试（也叫验收测试），但也定义 得很简单，具体怎么做？会遇到怎样的困难？需要多大的成本？这些都是大家更为关心的内容。
怎样的产品才是正确的产品？客户知道吗？也许知道一点；产品分析师知道吗？也许知道更多一点；测试人员的知识挺重要；程序员当然也少不了，但无法完 全依赖于他们。看来只有提炼各种角色人员的知识才能得到正确的产品，因此协作是必须的。当然大家都知道要协作，可说起来容易做起来难，怎样的协作方式效率 更高？Gojko Adzic 说要借助实例的力量！他还进一步总结了一套非常清晰的关键过程模式。
实例的作用真的那么强大？这一关键过程模式是否有效？我基于本书的结构组织了一个主题为ATDD1 的workshop，邀请到了很多产品负责人、测试人员、程序员以及项目经理的参与。我把大家分成几个组，各组都包含不同的角色，简单介绍了实例化需求的 基本概念和目的之后，我挑选了书中的一个简单例子，给出商业目标和范围，让各个小组协作制定需求说明、举例说明、进一步提炼并使用Gherkin语言2 描述。一个半小时之后，最终的结果超出了大家的预期，所有组都认为对于需求大家达成了清晰的共识，很多人总结时都说体验到了实例的强大，编写代码自动化验证这些实例看起来也不是什么难事，还有一些人则饶有兴致地讨论起用哪一种工具实施自动化更有趣。
有了这样的经验，我就更有信心给所有软件开发从业人员推荐《实例化需求》了。不过对于项目经验缺乏或者是喜欢看代码的人来说本书可能会显得艰涩，在前言里作者就说了：
本书没有源代码，也不介绍任何工具。
因此想了解工具的人需要找其他书籍补充，但缺乏项目经验会比较麻烦，因为书中有大量的案例分析和访谈、涉及了各种各样的角色和场景，这些内容对于有经验的软件从业人员极具参考价值，但也会让新手摸不着头脑。
根据我的经验，很多人，尤其是程序员，在刚接触实例化需求或ATDD的时候，会过多的关注工具而忽于协作。事实上开发人员和用户之间良好的协作远比 选择使用Cucumber还是Fitness来得重要，不要忘了，我们更应该关心是如何让F-16战斗机能够更容易从战斗中逃脱，而不是花上很大的代价非 要让它的飞行速度达到2.5马赫。
1. 你可以大致把ATDD理解成实例化需求的另一个名字，反之亦然。
2. Gherkin语言是实例化需求工具Cucumber的一部分，通过及其简单的Given/When/Then语法及表格帮助描述业务人员能轻易理解的需求说明。
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
