【敏捷开发每日一贴】实例化需求常见问题

实例化需求常见问题
推动实例化需求，讲到这个例子时，经常会碰到这些问题：
6件可配吗？：例子中提到6件免运费，显然这个在系统中要可配的，不能在产品中硬编码（hard code）。但是这个需要在例子中讲清楚吗？
“否者我的开发团队又要说我需求没讲清楚，不过我总觉得这点意识他们应该有的？”，一个有着很多痛苦经历的PO问道。
没有一定的说法。记住！！最重要的是沟通，把需求澄清出，不要有歧义。
这不是Waterfall吗？：这是一个简单的例子，看上去很快就弄明白了。但是在实际中，有太多的需求要澄清呀？
“这样看上去和以前没有两样，还是要花好多时间来搞清需求，只是快了一点而已？”
不是的，在实际运作中，这是一个迭代式的不断澄清的过程，可以把最重要的先澄清。这里面还有一个很重要的是：就算在优先级最高的需求中也有不重要的小功能，这个用例子的方式很容易体现出来。
和用例有区别吗？：很多人初次接触这个时总觉得和用例没区别。
可能，但是我很少看到好的用例，用例很多时候关注在技术实现的步骤上了，所以有很多不必要的技术细节，不太适合产品经理来阅读。这儿我们要求的是一份大家都能容易读懂最少歧义的需求。
当然不排除你的用例很容易读，没有冗余，那往往就是实例化了。
如何实施
以前在估计时间时，团队很容易用含糊的原因解释。敏捷实施中又要求团队来估时间，常见的毛病就是：
我们需要1000人时（manhour），300人时是准备环境，400设计加开发，300人时是测试。
现在用实例化需求后，很容易的针对每个例子来估时间，PO也可以根据时间的代价来取舍。
认可了这种实践，实施起来也相对容易一点，下面列出几个要点。
循序渐进和现有流程的结合
我们可以不用改变现有流程的方式把实例化需求循序渐进的开展起来，这一点在企业中很重要，大的改变都很费周折。
在测试分析阶段，我们可以把简单的需求列出来，加上理解的一个最重要的例子就可以了。可以结合迭代式的方式，优先级高的先多花时间来写测试用例。
当然在写测试用例时，我们可以继续前面的格式，只是多加几个例子，并且持续地提炼需求说明，使得越来越清晰。
这样子，你现有的流程就不需要改变，如果你已经有现成的框架来做测试脚本，那就继续用下去吧，只要需求明白了，什么都好解决。
贴在墙上
把需求贴在墙上可视化一点也是非常有效果的，它可以减少浪费。企业最大的毛病就是会多，每个人都是认为自己的会重要，这是很浪费时间的。
只要我们把需求贴在墙上，团队就随时随地得可以了解最新的进展。随手拿个即时贴提建议：时间估计，架构的影响...
如果对某个需求需要讨论了，召集相关人（千万不要整个团队）在小房间搞清楚，然后立即更新需求。因为我们现在用上了自然语言的实例化的需求，任何时候团队成员应该很容易读懂，而且没有偏差；如果有，说明还不清楚。
课后练习
试着把身边最近工作过的一个需求用这种方式体会一下
小结
实例化需求是一种很棒的协作探索需求的好办法，它强调无时无刻地沟通的必要性，还有就是用例子来讲述需求更容易理解。但是要用熟练还是有难度的。
考阅读
1.  Book: Specification by example.http://manning.com/adzic
2.  Specification by example:http://specificationbyexample.com
3.  实例化需求中文书：http://www.ituring.com.cn/book/837