为项目文档分配资源

Question

对于以下场景，您有什么建议：

十几个开发人员需要构建和设计一个复杂的系统。此设计需要为未来的开发人员记录下来，并且必须注意设计决策。这些报告大约需要每两个月提交一次。我的问题是，这个项目应该如何记录。

我认为有两种可能性。每个开发人员写下他们帮助设计和集成的东西，然后一个人将这些文档组合在一起。最后的文档有时可能是不连贯的或多余的，因为负责组装一切的人没有太多时间来调整每个部分。

假设每个开发人员的文档部分在截止日期前几天到达。协作系统(即维基)不会正常工作，因为直到截止日期前几天才会有任何东西可读。

或者，是否应该让几个人(2-3个)来编写文档，而团队的其他人则实际开发系统？开发人员需要一种方法来将他们的设计选择和结论传递给技术作者。怎样才能有效地做到这一点呢？

Answer 1

我们从两个方面着手，使用RUP风格的方法。在第一种情况下，您将有一个领域专家，他负责粗略地设计您要交付的内容-开发人员在必要时参与其中。在第二种情况下，我们使用技术作者-他们记录应用程序，因此他们应该很好地了解应用程序是如何挂在一起的，并且您可以让他们参与到整个设计和开发过程中。在这种情况下，他们可以帮助改进设计，并确保它与他们认为正在开发的内容相匹配。

Answer 2

我们使用confluence (atlassian的类似wiki的东西)并记录各种不同的“东西”。开发人员不断地这样做，我们互相推送文档--我们让同行的压力来决定什么是必要的。每当有新的人出现时，他/她的任务就是阅读所有内容，并找出哪些仍然是正确的。因此，不正确的内容将被删除或更新。当我们可以删除内容时，我们很高兴;)

这个过程的好处是，相关的内容保留下来，不相关的内容被删除。我们总是“摆脱”更形式化的需求，声称如果“他们”需要的话，我们总是可以构建他们想要的word文档。“他们”从来不需要他们。

Answer 3

我认为备选方案2的敏捷性较低，因为它意味着项目进入了一个新阶段(尽管它可能与测试并行)。

如果您处于敏捷模型中，那么只需添加文档(遵循指导原则)作为故事。

如果您使用的是阶段性方法，那么我仍然会要求开发人员按照一些指导原则编写文档，并在设计和代码的过程中审查文档。最终，你可能会有一个技术作者来检查每一件事，以获得正确的英语，但这将是一种“发布”活动。