小议scrum - 取消设计文档？

我不懂scrum。最近浏览JavaEye的帖子，越来越多的scrum字眼撞入了眼球，于是开始关注它、学习它。《Scrum敏捷项目管理》由Scrum的缔造者KenSchwaber撰写，算是Scrum相关的一本经典作品。书中确实总结了一些有效的敏捷方法，但阅读过程中也有一些疑惑。标题中提到的这个观点是我遇到的其中一个。

在该书中文版第109页中写到：

看到这里，我吃了一惊。取消设计文档？真的要颠覆传统吗？我知道开放的、面对面的交流很重要：大家能够从不同的角度评价问题，有利于全面地权衡解决方案的优劣；同时集中式讨论有助于迅速地发现问题，集体的智慧也提供了更快找到解决方案、找到更优解决方案的可能。但是，仅仅通过面对面的交流就够了吗？我有几点疑惑：

一、以这样的方式得到的解决方案肯定就是最优的方案吗？

二、解决方案肯定不会存在漏洞了吗？

三、解决方案在未来不可能扩展或改变吗？

四、过了一段时间后，大家仍能清晰地记得当初的解决方案吗？

如果以上疑惑中至少有一个是问题，我们该如何解决呢？把面对面的交流成果以书面的方式保存下来（比如写成设计文档），我们不用担心遗忘，我们可以冷静地重新审视方案，每位参与交流的成员都有机会知道自己的理解与团队的理解（在文档中反映）是否一致。如果不这样，我们得用什么方式来应对这些可能的问题呢？这些方式的代价会（比以书面的方式保存下来）低一些吗？

我知道一些朋友会提到一个观点：好的代码就是文档，或者类似的说法。但是代码不能代替文档，因为：一、与文档相比，代码与人类的普通逻辑思维差异甚大。二、因为第一点，代码只适合程序员阅读，而文档的适应范围更广。三、代码通常是散布的（比如一项使用Java开发的Web应用解决方案就可能涉及到数据库、用Java编写的组件及页面），而文档可以把这些内容组织为一个便于理解的整体。

或许还有朋友会提到：文档很难维护，容易过时，特别是设计文档。没错！代码最终是要转换成可运行的程序，并在交付给客户之前进行测试和验证。如果发现问题，代码必须修正。在这种外在的动力下，代码最终会与产品目标达到一致。但文档（特别是不需要交付给客户的文档，其中最特别的是主要由程序员使用的设计文档），在没有外在动力的情况下很可能不被维护而迅速过时、失效。在一次性的项目中（我的意思是指项目的产品仅用于某个特定的客户，后期的维护时间很短或维护内容不太复杂，团队也不需要在该项目的开发过程中积累更多的知识），文档失效可能并不是最突出的问题。此外，我个人有种感觉：找到代码写得很烂的程序员很容易，但找到文档写得很烂的程序员更容易！这或许得部分归咎于我们的教育吧？不管怎样，我始终认为文档的问题是一个管理上的问题，文档本身没有错。团队要生产好的代码，也要生产好的文档。

这两天在ScrumAlliance的网站上看到一篇访谈：ScrumMeetsWaterfall-AnInterviewwithMikeCohn(http://www.scrumalliance.org/articles/93-scrum-meets-waterfall)。Mike是ScrumAlliance的奠基人之一。在文中Mike提到：

看到这里，我想，这可以理解为对书中的那段话的一个修正吧。或许对于那句话我应该理解为，作者只是想在Service1st这个团队中取消设计文档？