问在开发方法文档中应该包括哪些内容？

EN

在我工作的一家公司里，我们采用了一种面向过程的方法，有很多文档(大多数文档都是项目经理要求填写的)。然而，尽管篇幅和解释都很长，但我意识到它很难用来帮助-the真正的开发人员。

因此，我决定以“帮助开发商”为具体目标，自食其力。最重要的是我开始收集最基本的问题-真正的常见问题。

我学到的是，对于大多数人来说，当他们想要采用某种过程时，遵循的是一些重要的事情，而许多事情他们可能没有事先的想法，但如果他们理解了逻辑，他们就会立刻感激。

以下是这类文档应该帮助的关键主题：

1. 开发到部署的过程--如何组织、编译和发布代码(以DLL、库、可执行文件、安装程序、网页的形式，以及如何部署和测试这些代码)？
2. 我们应该如何进行版本控制？(如果有新人的话，为什么？)了解存储库的结构、行为守则(当签入是可接受的、何时不能接受、版本/标记何时公布、修补程序、合并将如何应用、以及在声明补丁或发布时的清洁度期望是什么)。
3. 执行方法学--我们是敏捷的吗?我们是否进行预先设计，我们使用哪种方法？现在，考虑到这一点，它可能是一个固定的公司。现在，对于大多数人来说，他们想知道我们将如何为给定的项目实现它。这是非常具体的项目，将允许人们可视化不同的里程碑和什么是潜在的重要。在一个面向研究的项目中--我们希望在收缩包装中指出“在构建关键算法之前始终验证关键算法”，我将重点关注特性的正确性和重要性。
4. 沟通责任--定义你如何进行正式沟通--这并不取决于特定的人是否能相互交谈--但人们必须知道什么是足够重要的(问题、设计决定、功能冻结)，以便在开始实施之前进行宣布，甚至进行辩论。
5. 最后，我们必须对代码质量、编码标准以及一般认为卫生水平以下的内容有一个共同的理解。

我希望我能用这样的文档开始每一个项目-然而，这并不容易。但重要的是要解决所有与开发人员日常行为和选择有关的问题。当需要向市场提供多个版本时，这将大有帮助。

最后，我还建议尽量采取非正式做法。通常，面向流程的人不太喜欢非正式的文档，这些文档可能会在上下文之外被误解。但是，这样做应该将开发人员连接起来。

您所称的“开发方法文档”通常称为“软件项目管理计划”。(我也听说过它被称为软件项目计划或软件开发计划。)有了这些条款，你应该能够谷歌的一些样本是存在的。正如Victor Hurdugaci和Donal Fellows提到的，您编写的软件项目管理计划将(1)根据您的需要定制，(2)随着情况的发展而更新为一份活的文档。尽管如此，如果你以前从未写过，而且你不知道还应该写些什么，那么从头开始写一篇文章可能会很困难。

IEEE标准1058 (，1998)提供了一些指导。有一个标准的副本张贴在这里上。我发现这个计划相当重要，但它是一个获得想法的不错的地方--如果你想为一个离岸团队写作，你可能需要额外的份量。在一本关于传统(非敏捷)软件项目:Futrell、Shafer和Shafer的质量软件项目管理(，由Futrell，Shafer和Shafer)的书中，我也有一个很好的大纲--以及一些关于如何规划软件项目的精彩叙述。

我们公司最近使用的(类似的)文档超过80页，不包括编码标准/约定文档。

既然你已经有了一些文件(S)，那就是你的出发点。问问自己：

1. 在这份文件中什么是有用的？
2. 少了什么？
3. 为什么我要用这份文件？

在你得到答案后，剪掉不需要的部分，并添加缺失的部分。

文档的实际内容取决于可用的资源，我相信很难用所提供的信息来推测。

只是一个提示:随着时间的推移，你会想要调整这个文档，所以不要写太多;)