我们刚刚向销售小部件的客户启动了一个新项目。 该客户是全球领先的小部件提供商，因此该项目可以成就我们，也可以破坏我们。
该项目使用敏捷方法，产品负责人已经与团队进行了交谈。 他将向团队介绍该应用程序的最重要功能。
产品负责人： 该应用程序实质上是一个网站，展示了客户出售的小部件。 此应用程序最重要的功能是添加新的小部件功能。
团队：很 有道理。 毕竟，应用程序无法展示任何内容，除非可以将小部件添加到其数据库中。 您能告诉我们此功能的规格吗？
产品负责人： 好的。 干得好。
产品负责人向团队显示下图：
团队： …
让我们在这里停止。 该数字是否回答以下问题：
- 功能的目标是什么？
- 向数据库添加新窗口小部件需要什么步骤？添加新窗口小部件后会发生什么？
- 会发生什么类型的错误，以及应该如何处理这些错误？
不行 我们可以弄清楚，此功能的目标是向数据库添加新的小部件。 但是，该数字不能回答其他问题。
这个数字真的足够吗？
没有！ 这只是一个大声喊叫的用户界面模型！ 这不是规格！
但这是一个主意。 我们可以使用它，并将这个想法转化为敏捷规范。
从构思到规格
团队从产品负责人那里获得不完整规格的情况的最大问题是，团队在确定要执行的内容之前无法真正执行任何操作。
这意味着团队有两个选择：
- 向产品负责人提出其他问题
- 凑合
这两个选项都是有问题的。
如果团队决定继续与产品负责人对话，则需要花费一些时间来找出确切的要求。 这意味着他们编写的代码不如他们编写的那么多 。
如果团队决定即兴创作，那么他们实质上是在猜测必须实施的内容。 如果他们的猜测不正确怎么办？ 究竟。 他们造成了浪费 ，他们不得不重新实现该功能。
换句话说， 不完整的要求会扼杀团队的速度！
如果产品负责人确实希望最大程度地提高团队速度，则他必须向团队交付“启用规范”。 产品所有者的角色在称为“ 启用规范”的Scrum模式中进行了描述：
产品负责人应交付使能规范，以表示他或她在探索需求空间时已进行了尽职调查。 “启用规范”意味着该规范足够丰富，以至于该领域的技术人员可以在无需大量后续澄清的情况下实施解决方案。
当产品负责人向团队交付启用规范时，团队会将这些需求转换为代码。
从规范到代码
当球队获得授权规格时，球就在他们的球场上。 他们必须弄清楚如何实现该规范，但这不是他们要做的全部。 他们必须确保自己的代码满足规范的要求，并保留规范，以使下一个遇到其代码的人知道该做什么。
问题是没有人真正阅读过文档或对其进行过更新 。 这就是为什么编写文档显然不能解决问题的原因。
有一个解决此问题的方法：
我们必须将“启用规范”转换为“ 可执行规范” 。
进行此操作的最宣传的方法是使用“ 测试驱动开发” 。 老实说，我不在乎团队是在编写代码之前还是之后编写测试。
我关心的是团队遵循以下准则：
- 团队必须使用端到端测试（也称为集成测试）来指定功能要求。
- 团队必须编写单元测试，以指定每一层的要求。
如果满足这些条件，则团队将创建可随时运行的可执行规范。
这给我们带来了两个好处：
- 我们将立即知道该软件是否满足其要求。
- 如果我们想知道特定功能应该如何工作，我们可以阅读端到端测试并找出来。
我们不必花费无数小时来阅读过时的文档并从其他团队成员那里收集信息。 我们要做的就是阅读测试。
这听起来真对我好 。
尽你所能
这种方法背后的主要思想是：
我们应用程序的需求永远不会丢失，我们可以随时找到它们！
采用这种方法并不容易。 为了使一切正确，这需要大量的工作和纪律 。
产品负责人必须拥有产品并帮助团队为客户提供尽可能多的价值。 另一方面，团队必须确保在实施阶段不会丢失应用程序的需求。
我已经听到了很多借口，为什么不能做到这一点，但是所有这些借口都有一个普遍的问题：
我们的客户不在乎我们的内部问题 。 他为我们付出了很多钱，并期望从他的投资中获得丰厚的回报。
确保这是我们的工作吗？
翻译自: https://www.javacodegeeks.com/2014/01/from-idea-to-code-the-lifecycle-of-agile-specifications.html