怎样看待活文档“ATDD”---记敏捷中国2012 open space

为什么要有一份活文档？
在现实中有太多这样的情形：新介入一个项目，老人会丢过来一堆的文档或者链接地址，并告诉你说，这些是与这个项目相关的一些文档资料，这些资料里有些 内容是已经过时了的，项目有些最新的需求还没人补充，先借鉴着看吧，不看文档还好一点，看了文档更晕。产品经理闷着头吭哧吭哧写了半个月的需求说明，然后招集大家开会，在会上打出投影对几十页的需求说明一个字一个字的过，产品经理在上面讲的口吐白沫，下面的听会人员昏昏欲睡，4个小时过去了，文档终于过完了，开发工程师按进度完成开发任务了，提交测试，测试人员看着实现出来的功能直挠头，这不对呀，叫来产品经理三方对质，产品经理说，我写的需求说明要表达的意思是这样这样这样的，不是现在这个样子的，听完这句话，开发人员直接口吐白沫晕倒过去，产品经理叹气摇头“唉，这些东西我在那天的需求评审会上都说过的，怎么就不记呢，需求又有变更了，我还得抓时间把文档修改一下”，合上电脑悄然离开，挥一挥衣袖不带走一片云彩。
ATDD是什么？
ATDD即验证测试驱动开发，文邹邹的定义是“ 在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确
而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发 ”。
ATDD的开发过程：
简单来说，有新的需求时，产品、开发、测试三方坐在一起，先由产品人员讲解需求，解答开发与测试提出的疑问，三方对需求达成共识，即三方对需求的看法和达成的标准是一致的；
接下来，开发人员根据已有的设计、代码等设计开发策略，测试人员分析并列出验证的场景和标准；
开发人员与测试人员共同评审测试人员设计的验证测试场景和标准，就此达成共识；
开发人员就此设计单元测试用例，测试人员设计验收测试用例及测试数据；
开发人员完成开发，提交测试前先运行单元测试和已达成共识的验证测试，验证已完成的功能是否准确；
提交测试后，测试人员进行验证，就发现的问题向开发人员反馈；
如果想引入工具，现已有基于FitNesse的验收测试驱动开发 ，这个链接地址介绍的简单易懂，没必要再把人家的东西原样的搬过来了。简单说，就是在wiki中写出需求并举实例（也许应该说成是实例化需求吧），这些实例的列表可以通过某些手段直接与代码接口相连，代码完成后，但可“运行”这份需求文档来验证实现的是否符合标准。
ATDD的好处：
1.减少因为沟通不一致，而返工的时间浪费；
2.提高交付产品的质量；
3.可快速进行自动化测试；
4.提升个人在团队中的责任感；