实例化需求的威力

标签: 敏捷 ATDD 书评 实例化需求 | 发表时间:2013-04-15 19:36 | 作者:juvenxu
出处:http://www.juvenxu.com

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 说要借助实例的力量!他还进一步总结了一套非常清晰的 关键过程模式

实例的作用真的那么强大?这一 关键过程模式是否有效?我基于本书的结构组织了一个主题为ATDD [1] 的workshop,邀请到了很多产品负责人、测试人员、程序员以及项目经理的参与。我把大家分成几个组,各组都包含不同的角色,简单介绍了实例化需求的基本概念和目的之后,我挑选了书中的一个简单例子,给出商业目标和范围,让各个小组协作制定需求说明、举例说明、进一步提炼并使用Gherkin语言 [2] 描述。一个半小时之后,最终的结果超出了大家的预期,所有组都认为对于需求大家达成了清晰的共识,很多人总结时都说体验到了实例的强大,编写代码自动化验证这些实例看起来也不是什么难事,还有一些人则饶有兴致地讨论起用哪一种工具实施自动化更有趣。

有了这样的经验,我就更有信心给所有软件开发从业人员推荐《实例化需求》了。不过对于项目经验缺乏或者是喜欢看代码的人来说本书可能会显得艰涩,在前言里作者就说了:

本书没有源代码,也不介绍任何工具。

因此想了解工具的人需要找其他书籍补充,但缺乏项目经验会比较麻烦,因为书中有大量的案例分析和访谈、涉及了各种各样的角色和场景,这些内容对于有经验的软件从业人员极具参考价值,但也会让新手摸不着头脑。

根据我的经验,很多人,尤其是程序员,在刚接触实例化需求或ATDD的时候,会过多的关注工具而忽于协作。事实上开发人员和用户之间良好的协作远比选择使用Cucumber还是Fitness来得重要,不要忘了,我们更应该关心是如何让F-16战斗机能够更容易从战斗中逃脱,而不是花上很大的代价非要让它的飞行速度达到2.5马赫。

[1]: 你可以大致把ATDD理解成实例化需求的另一个名字,反之亦然。
[2]: Gherkin语言是实例化需求工具Cucumber的一部分,通过及其简单的Given/When/Then语法及表格帮助描述业务人员能轻易理解的需求说明。

本文已经首发于《程序员》2013年3月刊,版权所有, 如需转载,请务必附带本声明,谢谢。

相关 [实例 需求] 推荐:

实例化需求的优点

- - 技术改变世界 创新驱动中国 - 《程序员》官网
文/Gojko Adzic. 在互联网时代,交付速度是当今软件开发的主题. 十年前,项目通常要持续好几年,并且项目阶段是以月来衡量的. 如今,多数团队的项目周期是按月来衡量的,而项目阶段则减少到几周甚至几天. 任何需要长远规划的东西都将被抛弃,比如大量的前期软件设计和详细的需求分析. 超过项目阶段平均周期的任务将不复存在.

实例化需求的威力

- - Juven Xu
2011年12月份上海的AgileTour大会上,Gojko Adzic 发表了一个题为 Take the business along for a ride 的演讲. 演讲中的一个故事我至今印象深刻,故事的主角是F-16战斗机,它的最初的设计需求是飞行速度要达到2-2.5马赫,首席设计师 Hillaker 询问美国空军为何需要如此快的飞行速度,答复是“飞机必须能从战斗中逃脱”,然而,意外的是,Hillaker 的最终设计并没有达到2马赫,但通过无框气泡式坐舱盖、倾斜的座位、侧装式控制杆等等诸多创新技术,飞行员可以非常敏捷地从战斗中逃脱,并且这样的设计生产成本更低.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.

[原]Dubbo实例

- -
Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案. Remoting: 网络通信框架,实现了sync-over-async 和 request-response 消息机制. RPC: 一个远程过程调用的抽象,支持负载均衡、容灾和集群功能. Registry: 服务目录框架用于服务的注册和服务事件发布和订阅.

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.