你知道吗，一个方法就能立刻提升团队的效率和质量

今天我介绍一个实例化需求的使用方法，让你立刻提升团队的效率和质量。

深度和广度

先看看下面的情景你是否熟悉：

你是否有过，产品经理反复找你讨论需求的经历？

你是否有过，开发的时候发现有不明确的需求，要和产品经理再沟通的经历？

你是否有过，测试过程中测试人员依然存在对需求心存疑问的经历？

我们不是没有讨论需求，而是我们没有把产品设计的深度和广度区分开来。

产品生命周期中产品的设计是在验证需求的深度问题，交付过程是在验证场景是广度问题。

产品需求

从用户整体使用的角度，做深度的探索。

而用户在某个场景下的行为，做广度的探索。

在实际工作中我们可以用这两个维度留意一下，一个进入迭代队列里的需求是否讨论清楚了。

需求讨论

说这个方法见效快，是因为只需改变需求讨论会议或者Scrum中Product Backlog Refinement（PBR）的方式，通常就会在当前迭代看出效果来。有效是因为通常改善了团队的工作效率，减少了迭代内的bug，从而减少了产品、开发和测试间的来来回回，提升了工作质量。

步骤：

在开始开发前举行需求讨论会议。也就是Scrum中的PBR，通常在迭代的中间发生，用于讨论并澄清后续迭代的需求。

会议需要三个角色，产品经理或者Product Owner（PO），开发人员和测试人员。Scrum中就是PO和开发团队（包括了开发和测试等）

会议中产品经理简短介绍一下要讨论的需求，开发和测试用测试用例的方式描述需求，即验收条件。以5个需求和8人团队为例：

PO花10分钟左右简单介绍5个需求

团队分成3个2~3人的小组，每个小组选一个需求进行讨论，写出需求的验收条件。20分钟一个时间段。此时，PO应随时帮助团队澄清疑问。

再10分钟每个小组分享一下各自的验收条件，其他人给出反馈

再做一轮20+10分钟的讨论，可以根据反馈来调整验收条件。如没有调整，可以拿下一个需求讨论。

如果需要，可以再做一轮。但通常2个星期的迭代，2个小时足够完成整个会议。

用具体的例子来描述验收条件来减少产生误解的空间。比如，买3本书包邮的例子

买一本《实例化需求》和一本《用户故事与敏捷方法》，快递费是12元

买一本《实例化需求》，一本《用户故事与敏捷方法》和一本《单元测试的艺术》，快递费是0元

用业务的语言描述。验收条件应当是业务人员都能看懂的，因此描述的语言应该是业务语言，不应包含技术或操作细节。这样更容易沟通，同时避免过多的讨论实现细节，关注于“需求是什么”而不是“如何实现”

经过这样的需求讨论会议后，团队将带着这些验收条件来进行开发，开发一开始写代码的时候就知道测试将怎么测，测试不用来来回回重复测之前已经讨论的情况，可以花更多的时间来发现之前没法预测到的问题。

如果想要有更进一步的效果，那就需要将验收条件自动化，并且不会为了自动化改变原本验收条件的描述，最终形成活文档。我在前一篇

从自动化测试到产品的实例化需求

的文章里，介绍了一套敏捷开发流程，以及提供了使用Concordion实现BDD的工程实例。

几天前有同事联系我，问我自动化测试的事情

成品很美，

但细节更容易看到改进的真相，讲述的过程对我们的价值更大。

我们把内容的点滴分享到了知识星球，帮助你了解整个过程，也欢迎你发出你的声音和更多人一起来分享我们的经历。

这就是为什么我们叫他《联动iTalk》的原因。

我们是联动iTalk，从企业外部的视角重新审视企业商业模式、产品发展、组织结构的改进的催化师。

我们致力于分享敏捷过程改进、DevOps、工程实践、产品创新等新的技术和工具，帮助大家解决工作中遇到的问题，从而提升整体效率，让我们的收益最大化。

为了更快的和你建立联接，让我们之间发生更多的化学反应，欢迎大家通过微信公众号给我们留言，说出你的想法，从而让我们的工作和生活发生更好的改变。