这个礼拜终于断断续续用了空档时间读完了一本买了却一直没时间坐下来好好研究的书

这本书给我一种很奇妙的读后感,因为书中既没有程式码,也不介绍任何工具,甚至实际软件例子也很少,篇幅最多的甚至是模糊的团队访谈。

但读完了以后,却让我在软件开发上流程上有了更大的启发。

交付错误的软件的原因

我是一名职业的软件开发者。前前后后写过的软件专案也有50 个, 60 个。目前也以开发软件为生。在我的职业生涯里面,其实我有一个从来没有跟人讲过的秘密困扰。这个困扰,我相信许多同业们可能也有。那就是— 一个专案开发下来,「我们竟然时常比我们的客户或PM,更了解它的生意逻辑与流程」

但这个问题带来更大的困扰是:「客户在它的Spec 里面却指定了完全不可行或者是成本效益极低的作法」。因为签了合约或领了老板的薪水,我们被迫在明知不可而为之的状况下,进行了一个彻底失败的专案。

技术很好,团队也强大,产品也有市场。但还是失败,因为– 「交付错误的软件」。

软件工程没教的课题: 交付正确的软件

市面上有很多书,教人如何敏捷开发,教人测试驱动开发(TDD)。它们可以带给开发者的好处是可以利用这些技巧将工程时间大幅缩短,降低软件内发生Bug 的频率。

这些技巧对于进行软件专案不是没有作用,因为早点完工(把功能实做出来),专案早点失败,专案可以及早轴转到较接近成功的方向。

对于正在营运中的公司,内部专案早点失败,及早轴转到较接近成功的方向。往往是可接受的。因为总体目标是尽快交付到贴近正确方向的软件。

但对于目标是交付一个软件的专案,「交付错误的软件」却往往是纠纷的起源。但却也是一个千古难解的课题。对于业主来说,他付钱是希望得到一个「正确的软件」。但于对于被委托的开发者也往往有苦难言,因为他们得到的指示是「按照业主精确的功能叙述去实作软件」,「正确与否」不是他们的最终责任。而是否「正确」通常往往也得等到上线之后,客户根据用户实测反应才能得知(虽然开发者往往是开发阶段就往往能猜测出是否失败的那一群人)。但这从来也不在合约的责任之内。

而这本书也就是在探讨这个课题:怎么样的软件流程,才能交付正确的软件。

大家没想到的答案: BDD

这本书绕了很多远路去讲解什么是Specification by example,但这也是作者的用意:刻意不使用专业定义字眼如「敏捷」、「测试驱动开发」去辅助解释,避免整个梳理的流程被大家脑海里面的术语印象所绑架。

但总体来说,这个结论毫无疑问就是Behavior Driven Development (BDD)。不过这个BDD 却跟我当初学到的BDD ( from Cucumber ) 印象很不一样。这也是为什么这次会花上几个小时誊下这篇心得。

里面有几段quote 我很喜欢,实际击中困扰的核心:摘录如下:

「实现范围(Implementation scope)含有对业务问题的解决方案或达成业务目标的手段。很多团队在开始实现软件之前(在此之前发生的一切往往被软件开发团队所忽略),期望客户、产品负责人或商业用户来确定工作的范围。在商业用户明确说明他们的需求后,软建交付团队就依此时现。这样本应该会让客户满意。但事实上,这正是构建产品开始出现问题的时候。

如果软件交付团队依赖客户给出用户故事、用例清单或其他相关信息,那么他们其实是在让客户设计解决方案。但是商业用户不是软件设计师。如果我们让客户去界定范围,那么项目就无法从交付团队已有的知识受益。这样开发出来的软件是客户所要求的,却不是他们真正想要的。

成功的团队不会盲目的接受软件需求,将其作为未知问题的解决方案,相反,他们会从目标中获取范围。他们以客户的业务目标为起始,然后通过协作界定可以实现目标的范围。团队与商业用户一起工作确定解决方案。商业用户专注于所需功能希望达到的目的,以及他们期望由此带来的价值,这样有助于所有人了解所需的功能。然后团队提议一个解决方案,这样比商业用户自己想出来的方案更实惠、更快,并且更容易交付或维护。」

「与我一起共事过的商业用户和客户,大多喜欢把需求描述成解决方案;他们很少会去讨论想要达到的目标,或者亟待解决的问题具有什么特殊性质。我见过太多的团队有一种危险的误解,他们认为客户总是正确的,客户要求的东西总是一成不变的。这导致很多团队盲目的接受客户建议的解决方案,然后竭尽全力去实现。」

「在构建正确软件产品的过程中,确定范围扮演着重要的角色。没有正确的范围,其余的工作只是在作无用功。」

「人们告诉你他们自己认为需要什么,通过问他们『为什么』,你可以找到背后的目标。许多组织不能明确地指出他们的商业目标。然而,一旦你获得了目标,就应该再反过来从已确定的目标上获取范围,可能你会丢弃掉原先假定出来的范围」

一个实际的例子:对VIP 免费送货的需求

Specification by example 强调的是对于需求,我们必须设计出一个可以被实现的方案,这个方案可以被单独测试验证。并且从这个方案与程式码中演化出LiveDocument。

原文链接:http://blog.xdite.net/posts/2012/10/01/specification-by-example/