在为客户提供教练服务过程中，我尝试过各种方法，发现其中有个方法提升团队的效率和质量最快速有效。简单概括就是实例化需求，但其实只用做一部分就可以有不错的效果。
为什么说这个方法快速有效？说快速是因为只需改变需求讨论会议或者Scrum中Product Backlog Refinement（PBR）的方式，通常就会在当前迭代看出效果来。有效是因为通常改善了团队的工作效率，减少了迭代内的bug，从而减少了开发和测试间的来来回回，提升了工作质量。过往的客户有做过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元
- 用业务的语言描述。验收条件应当是业务人员都能看懂的，因此描述的语言应该是业务语言，不应包含技术或操作细节。这样更容易沟通，同时避免过多的讨论实现细节，关注于“需求是什么”而不是“如何实现”
通常来说帮助团队实现1到3比较容易，团队多练习几次就能习惯4和5的表达方式。至于是否一定要用“假如……当……那么……”的格式，如果只是帮助大家澄清需求，那重要的是大家理解这样的结构化表述，对需求规则理解的表述包含了“条件-行为-结果”。当然，我更倾向于使用这样的格式来帮助大家习惯结构化的表述，同时也能方便以后自动化。
经过这样的需求讨论会议后，团队将带着这些验收条件来进行开发，开发一开始写代码的时候就知道测试将怎么测，测试不用来来回回重复测之前已经讨论的情况，可以花更多的时间来发现之前没法预测到的问题。
如果想要有更进一步的效果，那就需要将验收条件自动化，并且不会为了自动化改变原本验收条件的描述，最终形成活文档。当然这需要的投入就比仅改变讨论方式要多很多了，也比较难完全掌握。用实例化需求来实现从外向内的开发——从PBR到Acceptance Test Driven Development（ATDD），再到Unit TDD。这将极大改善产品开发。这些将在以后的文章中讲解，或者来参加我们的培训。:D