本节书摘来自异步社区《超越需求：敏捷思维模式下的分析》一书中的第2章，第2.4节发现和交付，作者【美】Kent J. McDonald（肯特 J. 麦克唐纳），更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.4 发现和交付
第三种对分析分类的方法根据我们何时进行分析来分类。划分活动常常很有用，这可能是人们喜欢基于计划的方法所描述的各种阶段（分析、设计、开发和测试）的原因之一。将知识工作分解为不同活动有一定优势，因为没有哪一个人能擅长知识工作的每个方面，所以把活动分为不同的类别显然有助于把事情分解为可管理的工作，并把焦点集中于不同的方面。
但组织这些工作的最好方式是什么呢？当人们引用Winston Royce被视为瀑布计划之源头的论文（www.serena.com/docs/agile/papers/Managing-The-Development- of-Large-Software-Systems.pdf）时，通常直接聚焦到展示了几个不同阶段的图上，而这几个阶段是在创建大型系统时会发生的。但在第一页有一个很有意思且常被忽略的图，它只包含两个框，即“分析”和“编码”，并带有下面一段说明：
在所有计算机程序开发中，无论大小和复杂度如何，有两个基本步骤是一样的。如图1所示，首先是分析步骤，然后是编码步骤。如果工作量足够小并且最终产品由建造者进行操作，那这种非常简单的实现概念实际上就是所需要的全部工作——内部使用的计算机程序通常就是这样。这种开发工作也是大多数客户愿意付钱的，因为这两个步骤涉及真正的创造性工作，对最终产品的有用性产生直接贡献。
Royce继续说到这种方法完全不适合大型软件开发项目，并揭示了他对如何看待软件开发团队的一些哲学：
制造大型软件系统的实施计划如果只有这些关键步骤，注定将失败。很多额外的开发步骤是需要的，但没有步骤像分析和编码步骤一样直接贡献于最终产品，而且还推升了开发成本。客户通常不愿意为此付钱，开发人员也不愿意实施这些步骤。管理的首要职责就是把这些概念推销给这两组人，并在开发人员方面执行合规检查。
虽然我不同意这段话中的所有观点，但我发现Royce专注于分析和编码作为客户价值的两个活动很有意思。我一直在寻找一些简单直接的方式描述IT项目中的关键活动，根据经验，我倾向于把它分为“找出正确的事物来创建”和“正确地创建事物”。
Ellen Gottesdiener和Mary Gorman在他们2012年出版的《Discover to Deliver》一书中找到了合适的词语来传播这些概念。那就是：发现和交付。这两个词不仅具有头韵，而且两位作者进一步用一个无限符号包起来这两个词以表示这两个活动如何交互并彼此影响，从而进一步巩固了这些概念。终于有人听到了这些概念，Royce一定很欣慰。
这里是Gottesdiener和Gorman对发现和交付的定义，我将在本书中继续使用这样的定义。
发现：探索、评估并为潜在交付确认产品选项的工作。
交付：把一个或多个已选择的候选解决方案转化为产品可发布的部分或产品版本的工作。
这个概念最有用的方面是有一个标签与不同类型的活动关联。过去团队已经从交付角度跟踪进展，但经常没有可视化发现活动。跟踪寻找正确事物的进展和跟踪构建解决方案的进展一样有用，因而我常常将发现看板和交付看板分开，这将在第15章详细介绍。
知识工作的方方面面都涉及发现的因素。当我们在创建、测试并部署解决方案时，仍然在“发现”关于需要和解决方案的知识。区分这两个活动以强化每个活动的焦点是有益的。发现会增加针对需要和解决方案的理解，以便交付。交付主要是关于创建、测试和部署产出，而这些活动有助于进一步理解需要和解决方案，这反过来影响你的发现。当然，发现在交付过程中仍会发生，但主要工作是创建事物以帮助增进理解。
那么设计在哪里呢，为什么没有被称为一个单独的活动？一些设计发生在发现活动中，而一些设计发生在交付活动中。发现活动中的设计通过使用设计思维（design thinking）技术获得对用户更好的理解，通过模型、实例和验收条件（将在第14章介绍）描述解决方案。BABOK v3区分了需求和设计，如表2-5所示，然后说到：“需求和设计之间的区别并不总是那么清晰。同样的技术被用来需求获取、建模和分析这两者。需求会产生设计，这反过来可能推动发现并分析更多需求。两者间重点的转换往往是微妙的。”
团队基于技术选型和架构限制，在搞清楚如何在技术上实现用户故事的过程中，设计就会发生。团队针对设计展开初步讨论，但随着经验增加会修改对设计的理解，这一过程中设计活动与开发和测试交织在一起。
因此，把设计作为一个单独活动不会对整个流程增加任何价值，并且还会导致毫无意义的争论——一个活动条目是在发现活动、设计活动还是交付活动中，然而在发现（准备进行迭代）和交付（迭代交付）之间明确的划分会得到更加清晰的界限。
