documentation - 共享规格的软件/平台

你可以试试谷歌文档——我过去曾成功使用过它。它支持导入/导出到 MS Word，并且对多用户有很好的支持 - 请参阅http://www.brighthub.com/internet/google/articles/8236.aspx。
它支持版本控制，允许您与当前正在处理文档的其他人聊天，并向您显示其他人对文档所做的所有更改的列表（无需关闭/重新打开文档）。

如果您需要企业支持，Google 也提供了 - 请参阅Google Apps for business。

score 2 · Accepted Answer

我们使用 SharePoint——它并不理想，但它做得不错。如果我是你，我会认真考虑离开 SharePoint 2003 并转向 MOSS (SharePoint 2007)。它并不完美，但实际上要好得多。这里有一点关于将MOSS 用作 wiki 的内容。我认为总的来说，wiki 是让人们加快系统速度的好工具。我们过去常常传递“入门文档”，现在我们的开发人员门户中拥有所有这些类型的东西。

根据约翰的评论，我查阅了这个功能比较。我必须回去看看我正在使用的 WSS 中没有的功能——我可能正在为我不需要的许可证付费！:)

score 1 · Accepted Answer

我们使用电子邮件。我知道它并不复杂，但它很容易使用。每个人都安装了它，并且没有许可问题。所有规范更改都将发送到超级集电子邮件发行版，指示更新和网络共享上可以找到规范的位置。

score 1 · Accepted Answer

我们在其共享和资源管理器 Web 界面中使用Alfresco的社区版本。非常有用，带有文档库、wiki、论坛和日历。我们目前托管大约 1.8 Go，主要由文档组成，版本化，有时会自动转换为 PDF（通过创建自动内容规则）。FTP、WebDav 和网络共享也用于访问同一个存储库。

score 1 · Accepted Answer

你可以看看Microsoft Groove——微软几年前购买的协作软件。

它与 Microsoft Office 的高级版本免费捆绑。

您可以使用讨论板自定义工作区，并且可以相当无缝地存储协作编辑的 Office 文档。

score 1 · Accepted Answer

我们将MediaWiki用于 dos 和 specs。Wiki 绝对赢得了 Microsoft Word 或 SharePoint 之类的任何东西 - 它允许您以“先参考，然后描述”=“分而治之”的方式开发文档。非常适合开发人员——他们过去也有同样的想法。开发文档的过程几乎是理想的：从 TOC 开始，向下钻取，直到为之前放置的每个链接编写文档。

MediaWiki 是完全可定制的——那里有很多扩展。最需要的是：

源代码荧光笔 - CSO_Source
我们自己的模板将 wiki 与类参考集成。
其他是 InterWiki、FileProtocolLinks、YouTube（我们使用它的定制版本来显示高清视频）、ReCaptcha、SpecialDeleteOldRevisions、Maintenance。

这里有一些集成示例。

我们使用Google 问题跟踪器来跟踪问题。其主要优点：

输入可用性：添加\更改问题的过程在那里非常方便。早些时候我们尝试过Track Studio——同样的动作需要 2-3 倍的时间，所以它很快就死了，因为我们大多数人都讨厌使用它。
可定制的网格。请参阅示例。真的很有帮助。
Atom\RSS 支持。所以每个人都知道发生了什么。
有一个Gurtle工具将它与TortoiseSVN集成。真的很有帮助。

它的主要缺点是它不能从公共访问中关闭。这使得它在许多情况下根本无法使用。

score 1 · Accepted Answer

如果您想要一个类似于 Word 的 UI，为什么不将 Word 与 SharePoint 2007 一起使用？你在 2003 年，所以经验就在那里。升级到 SharePoint 2007，您可以拥有协作、Word 功能、文档共享等。

这是微软希望人们使用 Office 的目的，因此有大量关于如何配置 SharePoint 和 Office 环境以支持协作的文档。

score 1 · Accepted Answer

谷歌在这个方向做了一些事情，看起来很酷：wave.google.com。这将是合作的一大步，值得等待。

score 0 · Accepted Answer

这里我们使用 Google Docs，它让每个人都可以写或只读的文档，在有或没有 Google 帐户的人之间公开或私有，它还可以导入 Word 文档，更不用说它直接运行到浏览器中，所以它具有很高的零成本和零设置的可用性，也与计算机/操作系统无关，我们有很好的体验。

另外，也许您应该看看37Signals的 Basecamp 或 Backpack，其中任何一个都可能符合您的要求。

score 0 · Accepted Answer

我们将DocBook用于我们的所有规范（以及其他面向客户的文档）。DocBook 是一种 XML 格式，可让您轻松生成几乎任何格式的文档，包括 PDF，这是我们将内容分发给客户以让他们签署的方式。我们可以将文档分成文件（按部分）并将所有内容提交到我们的源代码控制系统（Subversion）。因为它都是 XML（即基于文本的），所以如果两个人处理同一个文件，Subversion 的自动合并和冲突解决非常有用。我们有一组所有文档都使用的样式表，因此所有文档共享完全相同的样式/格式，我们无需额外工作。

如果您不喜欢直接编辑 XML 文件，可以使用 GUI 前端来提供类似所见即所得的体验。我相信我办公室的大多数人都使用XMLMind。不过，我们碰巧都是技术人员，所以如果我们必须直接编写 XML，这不是问题。

作为旁注，我们还发布了发行说明。我们有一些 XSLT 可以让我们像这样编写文档：

<bugs>
    <bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug>
</bugs>

然后，我们有一个脚本，它运行在我们的 Subversion 存储库中，执行svn log从以前的发布标签到当前发布标签的操作，以及一些 Bugzilla 集成以即时自动生成发布说明。

（此外，对于大多数内部文档，我们使用MediaWiki，这也是一种很好的协作方式。）

score 0 · Accepted Answer

我们使用OnTime。它最初仅用于缺陷跟踪，但我们也开始使用它来跟踪特征。这些可用于记录功能在开发过程中的演变。可以将功能组合到冲刺或发布中，并且可以针对每个功能跟踪时间。如果您使用 SCRUM，您还可以为每个 sprint 绘制燃尽图。它还具有 wiki 功能。

documentation - 共享规格的软件/平台

12 回答 12

Related

Reference