我为一家CMMI 5级认证公司工作，我讨厌的一件事是我们准备的文件数量（作为一名程序员，我已经讨厌文件）。我们有很多很多的文档，如PID（项目启动文档），业务需求，系统需求，技术规范，代码审查清单，问题日志，缺陷日志，配置管理计划，配置管理检查表，发布文档和批次...项目文件？
几乎90％的这些文档是为了QA审核而完成的:) ..您认为什么是项目最重要的文档？其他开发人员可以长期使用哪些文档？
请在这里分享你的良好做法。我希望将它们用于我自己的项目或我计划从长远角度开始的公司。
感谢
的关键文件是good functional spec.应该有有且仅有一个的系统参考文件。
过度使用文档在每次有人更改系统或界面时都会传播大量小规模和规范文档。对于任何复杂的系统，只要你的规范分布在几百个字，excel，visio甚至powerpoint文件中。发生这种情况时，您会失去对当前内容的清晰度，甚至无法确定您是否找到并识别了所有相关文档。
BRD-SRD-Tech规格级数基于业务签署BRD的假设，业务分析师根据BRD中记录的要求签署SRD，并且技术规范已与SRD签署。这会生成一个签名网页，包含多余信息的多个文档，并且使规格文档保持最新变得困难和笨拙。因此，后续需求文档往往采取一系列变更请求和补充需求和规格文档的形式，每一个都有自己的签核和审核流程。您获得CYA和审计线索（或至少出现审计线索），但您失去了清晰度。目前还没有关于该系统的明确参考文件，并且很难确定与任何特定活动相关的当前或相关内容。最终的结果是您的业务分析过程在法医研究中陷入困境，这增加了交货时间表的开销和延迟。
规范文档应该以对任何给定系统或子系统有一个明确引用的方式构建。该文件应该保持最新和版本。获取good technical documentation tool，如Framemaker,，这样您的过程就可以扩展，并且文档具有某些缺乏Word的排序结构完整性。
对我来说，我曾经使用过的唯一真实文档就是规范。越详细越好。但是它不需要一次完成，并且也不需要特别正式。对于我来说，比检查并签名，双重检查和双重签名的文档始终能够获取文档的最新版本更有用。并且能够与人们交谈他们写的内容，并在不明确的情况下做出决定。这对我来说比其他任何东西都更有用。总结：规范是我发现的唯一有用的文档，然而与让项目经理知道所提议的系统出来并且能够根据他们所知道的做出明智的决定相比，它相形见绌。
您认为什么是项目最重要的文件？
不同的人有不同的需求：例如，所有者需要的文件（例如商业合同）与QA需要的文件不同。
其他开发人员可以长期使用哪些文档？
IMO最重要的文件（除了源代码）是功能规格：因为什么软件是应该做的（而不是，它是做）是一两件事，不一定是反向工程。又见How does a good developer keep from creating code with a low bus hit factor?
用户故事，燃尽图，代码
从项目来看，最重要的文件是那些通常包含单词计划，如项目计划，配置管理计划，质量计划等等。
您所描述的内容在过程改进中很常见，通常会回应两个主要原因。一个是，这个系统实际上是过度的，阻碍了正在进行的实际工作。另一个问题实际上是在你的问题上回答的：并不是说文件只是为了审核而完成的，你的重点不应该仅仅是其他开发人员的文档是否有用，而应该是整个项目或公司的文档。
一个人通常从自己的角度看事物，有时需要看一般的图景。
文档就像豆腐一样 - 大多数人都讨厌它，直到他们意识到在合适的条件下它可以非常好。
问题是，你认为文档主要是为了文档的缘故。作为一名开发人员，您没有在您制作的文档中看到任何直接价值，因为您知道您可以在没有您需要制作的所有TPS报告的情况下完成工作。
不幸的是，我打算打赌，在一家公司里，你一直被迫吃生豆腐的事情并不多。你可能不得不把它吸了起来，写出你公司要求的文档，但你至少可以做一件事......你可以编写至少对你有用的文档你，你可以将它们传递与你的代码给其他人维护它。
除了内联文档，您可以设置一个wiki供您和团队中的人员使用。这种类型的文档是可搜索的，这对开发人员来说已经是一个很大的优势了，再加上它更像是一个活的文档，而不是像你写作业一样的纸。您已经发布到SO，所以只要将您的文档视为将您的知识集中在更有用的地方即可。
我的旧4种+ 1观点的风扇：
用例图（a/K/A用户故事）。有几种形式：适当的使用案例，未明确定义的前瞻性用例和需要分解的史诗。
逻辑视图。 “静态”视图。 UML类图等在这里很适合作为设计文档。这还包括各种协议的请求和响应格式。这里是我们记录RESTful请求和响应的地方。这包括REST URI设计。
流程视图。 “动态”视图。用于设计文档的UML活动图，顺序图和状态图等。在某些情况下，简单的叙述效果很好。在其他情况下，有一个状态设计模式，它需要类图和状态图的组合来显示有状态对象如何交互。
这也包括协议（例如REST）。这里是我们为各种REST请求定义任何特殊处理的地方。
这还包括认证或授权规则，以及任何其他交叉方面一样安全，日志等
组件视图。我们正在部署的部分。这包括我们依赖的东西，模块和包的结构等。这通常是一个简单的组件图或组件列表及其依赖关系。
部署视图。我们尝试从部署的代码中生成此代码。由于我们使用Python，我们使用epydoc来创建API文档。我们还使用Sphinx将模块文档导入该软件视图。
这还包括参数，设置和配置详细信息。
然而，这是不够的。
项目开始时，您必须通过一系列冲刺来解决这个问题。
第一个sprints构建的只是用例视图。
随后的sprint构建了一个“架构”来实现用例。体系结构文档具有4 + 1个视图，但处于高度抽象层次。它总结了模型模式的结构，请求和回复，RESTful处理，其他处理，预期的组件等。它从来没有一个部署视图。我们通常将操作员指南和API文档引用为体系结构的部署视图。
然后设计和施工冲刺为各种组件构建（并更新）详细的4 + 1视图文档。
然后释放sprints构建（和更新）部署视图。
请参阅http://stackoverflow.com/questions/522684/how-much-documentation-is-optimal-for-an-agile-project – 2009-02-11 11:49:27