《敏捷可执行需求说明 Scrum提炼及实现技术》—— 3.4 关注干系人的“愿求”

本节书摘来自华章出版社《敏捷可执行需求说明 scrum提炼及实现技术》一 书中的第3章，第3.4节，作者：（美）mario cardinal，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

正如我在第2章里提到的那样，构建软件是为了解决问题。这些问题的描述组成了需求说明的核心内容。对“问题”一词最有帮助的定义是我曾经从gerald weinberg和don gauss的书《are your lights on?》里看到的[5]：

“问题：就是愿望和感知之间存在的差距。”

根据这个定义，软件的存在就是为了满足这个愿望。没有不为了满足愿望而存在的软件。一个“愿望”是可展示的、对某个干系人或某些干系人群体有价值的一部分功能。但是愿望本身并不是证明这些需要的唯一动机。

weinberg和gauss突出了愿望和感知之间的矛盾关系。“感知”定义了什么是人们所需要的。这种矛盾关系很好地被新词“愿求”（desirement）表达出来，这个词是单词“愿望”（desire）和“需求”（requirement）的混合词。“愿求”是“一个非常重要的、因此被理解成需求的愿望。”这个杜撰的单词最初是由david starr [6]提出来的，他把愿求定义为“一个非编译的软件变更请求”。[7]

“愿求”是通过很早就开始、并持续在每个sprint结束时都交付有价值的、干系人愿意参与评价的软件来实现的。通过定期评价可运行的软件这种方式，干系人们的想法和愿望也会随着他们对软件的变更请求一起发生变化。

除非你既是软件的开发者又是唯一的用户，否则关于“愿求”的沟通是一个非常有挑战的任务。为了更好地理解这些挑战，让我们想象一下，在一间黑暗的大屋子里，开发者和干系人之间正在针对“愿求”进行沟通。因为没有灯光，因此，在这种情况下是没办法收集到任何有用的信息的。坦白地说，开发者们处在黑暗之中。干系人跟产品负责人一起也在这间屋子里，他们每个人都在描述着他们想要的功能。因为产品负责人几乎什么也看不见，他只能从一开始就仅依赖声音来判断，但他听到的都是持不同意见的噪音。想象一下另一种情况，即当每一个干系人在说话的时候都会发出一种有颜色的光。

当干系人们大声地说出他们的想法时，不同颜色的光点照亮了黑暗的屋子。一个人可能会发出绿色的光点，另一个人也许是发出黄色或者红色的光点，等等，直到大量的彩色光点飞舞在产品负责人身边，就像五颜六色的萤火虫。虽然所有这些光点都围绕着产品负责人，但是他仍然处在黑暗之中，因为并没有什么有意义的事情发生。

随着产品负责人试着去辨认这些点亮屋子的小光点，他通过询问干系人们的“愿求”来引导他们之间的谈话。他磨炼着自己的反应能力，当一个“愿求”从三个或者四个干系人嘴里重复说出来时，他便紧紧抓住不放。当那些关键的“愿求”被加进来时，这些不同颜色的光点就开始汇聚，直到都变成的白色光束。这些白色的光束就是团队可以继续下去的起点。仅仅依靠这些普通的要素，团队就可以逐渐看清干系人们期望的利益是什么。

通过收集这些合并过的“愿求”，团队就可以开始创建有价值的软件产品增量，并请求得到干系人的反馈。这些反馈也许是确定团队对需求的理解是成功的，或者会有一些干系人认为他们的“愿求”被误解了。通过这些反馈环，“愿求”被定义得更加清晰，产品负责人就可以从干系人那里收集更多的信息，继而开发出更棒的软件。反馈环每隔几周循环一次，在每个反馈环的结束点，产品增量就会交付到干系人手中。当这些增量被完成以后，又一个新的迭代就会从头开始。在这些干系人达成共识的过程中，那些白光会变得越来越亮，越来越充足。对于开发者来说，他们的目标就是达到整个房间都被点亮的状态。

使用敏捷软件开发，你会通过迭代的方法逐步网罗“愿求”从而消除不确定性。“愿求”也参与迭代过程了，它们促进了如何创建价值的讨论。通过将关注点从解决方案的属性转移到干系人的“愿求”上来，产生了更多有价值的对话。