在项目开发过程中，多少文档，什么程度的文档算是合适的文档？

而今眼目下，很多敏捷过程都提倡在项目开发过程中，保留合适的文档即可，但是什么是合适的文档，缺乏一个明确的标准，这给人一种事实而非的感觉，在执行过程中，也不好操控，这里，分享一下我的看法：

1. 对于项目团队沟通有意义的文档我们必须保留，比如我们需要对需求建模文档，目的是为了让业务人员，架构师和开发人员对系统实现的范围和具体的业务要求达成共识。当然，你可能会反问：如果项目成员都是业务专家，对业务都已经耳熟能详，那还需要这个文档吗？这里我认为就可以大大简化，比如通过几十字的简单范围界定即可，当然，极端的情况，你也可以不要，因为大家都明确，所以不存在再沟通的必要。另外，对于这类文档要尽可能少，并且一定要维护，保持同步。

2. 需要交付客户的文档，在项目开发过程， 客户常常会参与到项目的过程中，比如需求的确认，变更的确认等，这些都需要有正式的文档， 并且这些文档交付与客户时，一般都是比较稳定的，很多时候都是在里程碑结束时产生的，并将作为下一个阶段开发的基线。这里文档一旦产生就不能直接修改，如果系统一旦产生变化，就只能增补修订文档。

以上两类文档，我认为是必须的，但是上次去一个公司做培训的时候，他们认为关于公司管理要求的文档，在项目开发过程中也是必须的， 这里首先介绍一下这个公司的情况，这个公司有一个类似PMO的机构，对公司项目进行战略层面的管理， 然后才是项目组——对项目执行层面的管理， 公司PMO机构要求进行Agile开发的尝试，但是无形之中，也对新试点项目的管理有一定的要求——传统的管理就要求项目组必须提供这样或者那样的文档。 这里我认为这种做法是不正确的，主要原因有两个： 1，这种采用Agile方法的试点应该是一种全新模式的试点，那么就应该摒弃以前的管理模式，如果强行套上以前的管理模型，其实就相当于给Agile方式套上了紧箍咒，还是不是Agile方法就很难说了 2. 公司管理是配合项目执行，而不是项目执行配合公司管理，我认为公司管理机构很大层面上应该是一个服务机构，所以根据项目的不同，监视其不同的里程碑或关键环节，而不是在一个特定的管理规范下——尤其是战略层面的，去要求不同的项目来适应。另外，就过程改进试点本身来讲，也因该放开手脚，让试点组成员多方尝试，并获得改进经验，如果PMO不是特别放心，建议可以委派一个人参与到整个试点项目中。

Gary

转载于:https://www.cnblogs.com/YangGang/archive/2009/02/05/1384345.html