在敏捷开发工作过程中，我们经常遇到这样的场景：
测试（人员）在接收版本时喊：测试版本都已发布了，怎么需求（文档）还没出来，怎么测试啊
开发（人员）打开 bug 后，叫道：测试又提交了一个需求的问题，非 bug，取消
需求（人员）在验收版本时，苦笑着说：当初不是讨论过的功能需求，怎么说漏就漏了
。。。
这些场景，是否似曾相识，又或者又正在发生着。
《敏捷宣言》四大价值观之一：工作的软件 高于 详尽的文档。
坦白地说，我也曾遇到上述问题，也经常反复琢磨这句话，本身也不喜欢整天写文档，特别是事无巨细的文字描述多的需求，实在太啰嗦。但现在问题出现了，想想我们是否走偏了，或大家曲解了这句话的意思。
此时，我们不妨采访一下在喊的测试人员。
| 问（采访人） | 答（测试人员） |
|---|---|
| 为什么在收到测试版本时喊没有需求文档 | 因为流程上有定义，需求文档最迟必须在测试版本发布时提交 |
| 为什么流程上这样定义 | 因为详细需求经常变，只有代码编写完成，详细需求才能同步稳定 |
| 没有需求文档时，测试人员依据什么设计测试用例 | 依据讨论会上的需求信息 |
| 讨论会上的信息足够支撑写测试用例吗 | 通常不能，讨论会上的结论是大致的方向性的需求 |
| 拿着方向性的需求，可以写出测试用例吗 | 不能写全，只能提取测试点与测试思路 |
| 没有明确的测试用例，合适做测试执行吗 | 不太合适，因为有些测试用例的预期结果不明确，所以流程上要求最迟在测试版本发布时必须提交明确的需求。 |
上述的问答系统，逻辑上好像能自洽。但此流程对测试人员其实并不友好（后面他们需一边执行测试一边完善用例），同时，好像测试人员在喊主要是在捍卫流程。其实，主要还是测试人员对测试的充分性缺乏信心，因为测试不充分造成漏测，直接影响工作业绩（KPI）。
没有需求文档，对测试的工作影响，主要表现在：
用例设计缺少重要的依据， 过不了几天，讨论会上的信息忘掉了，自己也不清楚为什么这样写；
测试用例无法与需求建立追溯关系，需求覆盖率数据无从说起；
不利于评审，没有参加需求讨论会的人无法判断用例的正确性、完整性；
测试为什么喊，在采访表中已答复，在工程实践中或许是一个好方法，但是否适合每一个团队，需根据当下团队特点作调整，但不能破底线。即：敏捷文档=不写文档。
我们再来看看第 2 个，第 3 个问题，都与需求文档没有及时沉淀有关。
调查报告 An Information Systems Manifesto（作者为 James Martin ，由 Prentice Hall 于 1984 出版) 表明，56% 的缺陷其实是在软件需求阶段被引入的。据此，我们在需求阶段解决问题是性价比最高的。虽调查报告离现在已好久，但在工程实践我们都很清楚，解决问题越往左移，成本越低，这一原则适合软件开发任何时候。
敏捷开发中，敏捷文档≠不写文档，而什么时候写文档，最合适的莫过于当下，即此任务交付前。
原文链接：https://mp.weixin.qq.com/s/aJ4JHLoMkT3Z_Dlz_IhM5Q