敏捷神话7：“敏捷意味着没有文档”

敏捷宣言说：“在综合文档中使用软件”，许多人认为敏捷几乎没有文档意义。 这不是真的。 一个运作良好的敏捷项目实际上会产生大量文档。 区别在于，敏捷从业人员有意识地创建实际上可读且有用的文档。 常识吧？ 但是对于许多软件开发资深人士来说，我们知道项目通常会产生大量浪费时间和精力的文档，因为它们在软件的创建和长期可维护性方面提供的帮助很少。

敏捷通过两种方式改进了文档：

• 谈话 后才 进行记录 。
  • 单凭言语常常会引起误解。
• 文档偏重于示例和测试用例 。
  • 利益相关者和开发人员通常会对他们对需求的解释产生争议。

以下是关于需求文档和技术文档通常如何浪费以及敏捷替代品的一些讨论：

需求文档

典型的项目方法学努力避免更改，因此他们尝试预先定义所有需求。 但是，对于任何大型项目，稳定的需求都是不可能的。 一方面，业务需求经常在项目中期发生变化–无论是由于竞争压力，法规变化还是客户偏好变化所致。 另一个原因是，项目涉众在看到并使用系统之前并不真正知道他们需要什么。 他们唯一意识到自己指定了错误要求的时间是他们实际对系统进行了试驾，而这通常是在项目结束时进行的。

与需求文档一起使问题更加复杂的是，纸上的文字不足以将利益相关者的意图传达给开发团队。 开发团队会去构建需求中的所有内容，但是当他们几个月或几年后向利益相关者介绍自己构建的内容时，每个人都会意识到需求被误解了，并且构建了一些对利益相关者不可用的东西，即使开发人员符合字母要求。 然后，责备游戏开始了，利益相关者指责开发人员对理解的不了解，而开发人员指责利益相关方提供了不良的文档。

你们中一些已经熟悉敏捷的人可能会说：“ 用户故事 ！” 作为这个问题的答案。 不，用户故事不是这里的魔术。 解决方案就是开发人员和利益相关者必须经常对话 ，以便他们共同构建系统。 利益相关者将讨论其不同用户的需求（用户案例），而开发人员则提出了解决这些需求的解决方案。 如果用户故事只是准备和传递的文档，而不是对话，那么它们就比传统需求文档更好。

好的，那么文档在哪里呢？ 交谈之后 ，利益相关者和开发人员就每种用户需求的解决方案达成共识（用户案例）。 但这并不止于此–利益相关者和开发人员随后就接受标准 ，甚至更好的接受测试达成了共识。

验收标准和验收测试是敏捷需求的核心。 验收标准和验收测试减少了围绕需求的歧义，提高了开发人员构建正确的事物，使利益相关者满意的机会。 只要满足标准/测试，它就可以使开发人员灵活地实现需求。

此外，它嘲笑了利益相关者之间对需求的不同解释–通常，当我们进入接受标准/测试对话时，即利益相关者意识到他们每个人对需求有非常不同的看法时，就会给他们一个他们有机会在团队建立之前就要求达成共识。

标准/测试成为开发人员和涉众之间的通用语言。 标准和测试成为讨论需求变更以及如何跟踪进度的基础。 此外，可以使用验收测试驱动开发（ATDD）工具（Concordion，Robot Framework，Fitnesse…确保将UI测试用于ATDD测试的使用最少，而在服务层上运行ATDD测试）来使这些测试自动化。

总而言之，敏捷需求的文档的核心是接受标准和接受测试，这些接受标准和接受测试来自于利益相关者与开发人员之间的对话。 当然，这是反复进行的-一次仅执行几个需求，以便利益相关者可以在添加更多需求之前定期查看和使用正在构建的内容。

技术文档

在许多情况下，技术文档可能会更浪费时间和精力。 技术文档旨在允许将来的开发人员维护系统，即使原始团队已经离开也是如此。 但是，很多技术文档（例如UML图）在解决日常开发问题中并不是很有帮助，并且常常与系统的实际行为不同步。

技术方面的最佳文档仍然是测试，尤其是自动化测试。 自动化测试能够验证指定的行为是否确实在代码中实现，而书面文档无法做到。

由于测试是文档，因此对于开发团队的成员来说， 以可读性和表达性的方式编写测试很重要，要意识到测试应该被其他人视为有效的文档阅读。

单元测试和集成测试

敏捷测试的根本和核心是通过测试驱动开发 （TDD）进行的单元测试。 TDD意味着，在程序员编写方法或更新方法的行为之前，程序员必须编写自动测试以指定方法的行为 。 这是一种非常刻意的编程方式，如果正确完成的话，它会生成许多有关每个组件行为的详细文档。

当一个新的程序员加入团队时，他/她可以非常快速地提高生产力，因为这些方法的用法和行为示例已在测试中。 并且（ 如果 ）在新程序员引入错误时，测试不仅会发现错误，而且（如果编写得当）会提供有用的信息，说明错误的原因和正确的行为。

集成测试是从单元测试到上级的。 它们与单元测试相似，只是它们一次测试一个以上组件的行为，通常包括数据库，应用程序容器或Web资源等外部系统。 集成测试如果做得好，将产生有关组件行为的类似丰富文档。

验收测试：自动化要求

单元测试和集成测试的缺点是它们仅会被技术人员赞赏，而不会受到业务涉众的赞赏。 这错过了利益相关者可以提供的宝贵反馈，这可以帮助避免开发人员在建立错误需求方面的浪费。 毕竟，根据调查，用户的参与始终被认为是项目成功或失败的首要因素。

让利益相关者参与项目的一种好方法是实践验收测试驱动开发（ATDD） 。 测试用例的编写方式易于业务利益相关者阅读和理解。 然后使用工具将测试用例连接到系统，并用成功或失败的天气注释测试用例。 ATDD允许利益相关者参与定义系统的行为，并帮助他们跟踪项目的进度。

当团队开始处理故事或功能时，测试人员和开发人员可以首先聚集在一起以定义和自动化验收测试。 这有助于在团队实施故事或功能时保持团队的注意力-团队专注于有助于达成利益相关者认可标准的事物，并避免被不感兴趣的事物分散注意力。

在进行ATDD时，重要的是将测试限制在涉众希望看到的范围内，并以一种易于理解的方式编写测试。 过于技术性或重复性太强的测试不应该包括在内。 这些方面仍应进行测试，但应采用其他方式。 ATDD的重点是利益相关者的参与。

我再次重申，大多数ATDD测试应针对服务层而非UI运行。 UI测试非常脆弱，因此在系统中进行任何微小更改都会导致维护它们的高昂成本。 由于专注于UI测试自动化，因此许多自动测试尝试都失败了。

其他测试

可以通过其他形式的测试来记录系统的许多其他方面。 可以使用JMeter或Load Runner之类的工具将性能约束写为自动化测试。 UI的行为（与系统的其余部分隔离）也可以通过自动或手动测试来记录。

并非所有测试都需要自动化。 某些测试更经济地手动运行。

翻译自: https://www.javacodegeeks.com/2015/09/agile-myth-7-agile-means-no-documentation.html