您使用什么软件/Wiki 来编写和分享您关于开发人员、测试人员和管理人员的规范？
您是否使用 Wiki 系统，如果使用，您使用什么 Wiki 软件？
或者您是否使用 Sharepoint 来管理和版本化规范？将 SharePoint 2003 作为规范平台的一个问题是很难在不同的人之间进行协作。
为了向后兼容，我还希望平台能够无缝导入 Microsoft Word。如果界面类似于 Microsoft Word，那肯定会有所帮助。
有什么想法吗？
【问题讨论】：
标签： documentation specifications collaboration
我们使用 SharePoint——它并不理想，但它做得不错。如果我是你，我会认真考虑离开 SharePoint 2003 并转向 MOSS (SharePoint 2007)。它并不完美，但实际上要好得多。这里有一点关于使用MOSS as a wiki。我认为总的来说，wiki 是让人们加快系统速度的好工具。我们过去常常传递“入门文档”，现在我们的开发者门户中拥有所有这类东西。
根据 John 的评论，我查找了 this feature comparison。我必须回去看看我正在使用的 WSS 中没有的功能——我可能正在为我不需要的许可证付费！ :)
【讨论】：
我在很多地方都使用过 Confluence，它是一个非常强大的 wiki，非常适合创建可以在各方之间共享的规范。见：
http://www.atlassian.com/software/confluence/
这里有更多关于使用 Confluence 的优势的信息：
https://stackoverflow.com/questions/170352/confluence-experiences
编辑：我已对此进行了更新，以处理您提到的 Microsoft Word 导入功能。 Confluence 通过 Office 连接器 支持这一点：
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
还有一个 Sharepoint 连接器：
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
加上一大堆插件：
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
其中一些也是用户贡献的。作为一个商业 wiki，我不能推荐 Confluence。
我也使用过 JSPWiki，它是开源的。还可以，但不如 confluence 好，见：
【讨论】：
我们使用电子邮件。我知道它并不复杂，但它很容易使用。每个人都安装了它，并且没有许可问题。所有规范更改都发送到超级集电子邮件发行版，指示更新和网络共享上可以找到规范的位置。
【讨论】：
我们在其社区版本中使用Alfresco，来自其共享和资源管理器网络界面。 非常有用，带有文档库、wiki、论坛和日历。 我们目前托管了大约 1.8 Go，主要由文档组成，版本化，有时会自动转换为 PDF（通过创建自动内容规则）。 FTP、WebDav 和网络共享也用于访问同一个存储库。
【讨论】：
你可以看看Microsoft Groove——微软几年前购买的协作软件。
它与 Microsoft Office 的高级版本免费捆绑。
您可以使用讨论板自定义工作区，并且可以相当无缝地存储协作编辑的 Office 文档。
【讨论】：
我们使用MediaWiki 来表示dos 和specs。 Wiki 绝对赢得了 Microsoft Word 或 SharePoint 之类的任何东西——它允许您以“先参考，然后描述”=“分而治之”的方式开发文档。非常适合开发人员——他们过去也有同样的想法。开发文档的过程几乎是理想的：从 TOC 开始，向下钻取，直到为之前放置的每个链接编写文档。
MediaWiki 是完全可定制的——那里有很多扩展。最需要的是：
一些集成示例是here。
我们使用Google issue tracker 来跟踪问题。其主要优点：
它的主要缺点是不能对公众开放。这使得它在许多情况下根本无法使用。
【讨论】：
您可以尝试Google docs - 我过去曾成功使用过它。它支持导入/导出到 MS Word，并且对多用户有很好的支持 - 请参阅http://www.brighthub.com/internet/google/articles/8236.aspx。
它支持版本控制，允许您与当前正在处理文档的其他人聊天，并向您显示其他人对文档所做的所有更改的列表（无需关闭/重新打开文档）。
如果您需要企业支持，Google 也提供 - 请参阅 Google Apps for business。
【讨论】：
如果您想要一个类似于 Word 的 UI，为什么不将 Word 与 SharePoint 2007 一起使用？你在 2003 年，所以经验就在那里。升级到 SharePoint 2007，您可以获得协作、Word 功能、文档共享等。
这是 Microsoft 希望人们使用 Office 来做的事情，因此有大量关于如何配置 SharePoint 和 Office 环境以支持协作的文档。
【讨论】：
Google 朝这个方向做了一些事情，看起来真的很酷：wave.google.com。这将是合作的重要一步，值得等待。
【讨论】：
我们在这里使用 Google Docs，它使每个人都可以只写或只读的文档，在有或没有 Google 帐户的人之间公开或私有，它还可以导入 Word 文档，更不用说它直接运行到浏览器中，所以它具有高可用性、零成本和零设置，而且它与计算机/操作系统无关，我们对它有很好的体验。
也许您还应该在37Signals 看看 Basecamp 或 Backpack，其中任何一个都可能适合您的账单。
【讨论】：
我们将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，这也是一种很好的协作方式。）
【讨论】：
我们使用OnTime。它最初仅用于缺陷跟踪，但我们也开始使用它来跟踪特征。这些可用于记录功能在开发过程中的演变。可以将功能组合到冲刺或发布中，并且可以针对每个功能跟踪时间。如果您使用 SCRUM，您还可以为每个 sprint 绘制燃尽图。它还具有 wiki 功能。
【讨论】：