敏捷方法需要文档吗?

有些人认为敏捷不需要文档，甚至不支持任何形式的文档化。在CIO杂志上的一个敏捷案例研究中声称，这是一个误解。Frans Bourmar最近写了一些关于敏捷方法与文档化的内容，而Ian Cooper据此写道：“该是拨乱反正的时候了”。

Ian首先从敏捷宣言讲起。敏捷宣言指出有价值且可工作的软件胜于详尽的文档。他指出，敏捷宣言是一套基本原则和标准，用于检验某个过程是否敏捷，而不是一个具体的方法论。他以下面三种开发过程方法为例，来解释这些原则是怎样发挥作用的：

要理解这个警示，必须记住非敏捷方法论常有文档驱动开发的特征，因为在写代码之前，它需要以大量的文档作为输入。很多情况下，软件开发团队执行相应的过程步骤，只是因为方法论要求他们这样做，尽管它们几乎没有什么价值。结果，很多开发团队完全放弃了这些方法论。敏捷试图避免漫无目标的文档产物，而再次把焦点放在软件开发过程的关键产物上，即代码。不幸的是，很多人没有认识到应该抛弃什么，从而使那种即兴而为式或纸上谈兵式的有限文档成了目标，这些人基本上没有对瀑布式过程（如SSADM）进行完整的实践。 (再次强调一下，如果连瀑布开发都作不好，更做不好RUP或敏捷等方法论。因为瀑布开发仍然是最简单和容易学习的软件开发生命周期模型)

回想一下水晶方法是如何处理文档：

水晶方法把开发看作是一系列的协作游戏，而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型，以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而，值得注意的是，这些文档没有模板，描述也可不拘小节，但其目标一定要清晰，那就是满足下次游戏就可以了。我总是将这些思想以下面的方式向我的团队成员表达：通过它们，你只要了解你明天加入这个团队所要知道的内容就行了。

而极限编程是如何对待文档的呢？

与水晶方法相比，XP认为在团队内外，文档都不必太多，并把它看作是需要交付给客户并由客户付费的故事。我觉得这样做的目标就是通过与其它特性集合进行对照评估，来减少多余的文档数量。XP更依重于开发人员之间的直接交流来传递相关的知识而不是依靠写好的文档，而结对编程使其成为可能：因为通过结对，你就可以和其它人分享对系统的理解，而消灭“死角”，也就很少需要文档来记录这些知识了。另外，代码与测试也被看作是描述软件实现细节的文档，它没有更新不及时的问题……总而言之，就是团队必需的东西或者客户想要的东西。

[回复1]即使是在XP中，文档也是必须的，成文的东西总是要比口头的东西来的实在！考虑极端的情况，如果小组的人全都离职了，这时候软件如何更新呢？总不能天天电话里跟那些离职的员工XP吧？我觉得关键在度的问题。文档要适度，不能成为小组工作的累赘，又要做到出现争议的时候有具可查。在我看来，至少有两份文档是必须的：需求文档和概要设计(Requirement and High Level Design)。需求文档的目的是告诉大家，我们开发的软件要做成什么样子要实现那些功能，这份文档应该是经常更新的，记录XP过程中最新达成的结论。概要设计的用处是让同志们在XP的过程中不会脱离开轨道，天马行空是没错，可马儿总得奔着青草跑吧？至于在细枝末节上的东西XP的过程能解决的很好。其实还有一份文档如果有，可能会效果更好，这份文档就是关于UI的文档。可用性(usability)对一个软件来说非常非常重要，就跟大家都喜欢美女帅哥一个理由。相比较来说这个文档可能只是个demo和一些简单的说明，它应该是很XP的。

[回复2]的确，文档是必须的。项目开发很大程度上是探索和管理的过程。没有文档，常常没有有效的累积，没有进一步改进的基础。逃避文档，往往是在逃避清晰准确的表达需求和目的的努力，逃避由于“白纸黑字”所带来的责任。文档应该精简，目标和思路最重要。文档应该分为多种层次和形式，应用场景描述、需求分析、架构设计、业务/流程建模、项目包、代码结构、方法名、注释、第三方包文档等都是文档。不同层次和形式的文档适合于表达不同的内容，在不同的条件、策略下保持更新。经过梳理和提炼的需求和设计文档至关重要，想想面对客户，你怎么和他沟通；新成员加入，你让他顺着什么思路快速了解情况，把握轻重... 毕竟，不是每个人都有着同样的思维，就是我们自己，也需要不断的清理、释放，才能放心的不断前进。