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

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

Answer 3

我们使用SharePoint - 它并不理想，但它做得不错。如果我是你，我会认真考虑下载SharePoint 2003和MOSS（SharePoint 2007）。它并不完美，但它要好得多。这里有一点使用MOSS as a wiki。我认为一般来说wiki是一个很好的工具，可以帮助人们快速掌握你的系统。我们过去常常传递“入门文档”，现在我们在开发人员门户中拥有所有类型的东西。

Per John的评论，我抬头this feature comparison。我必须回过头来看看我正在使用哪些不在WSS中的功能 - 我可能会支付我不需要的许可证！：）

Answer 4

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

Answer 5

我们在其社区版本中使用Alfresco来自其共享和资源管理器Web界面。非常有用，包括文档库，维基，论坛和日历。我们主持大约1.8 Go主要包含docs，版本化，有时自动转换为PDF（通过创建自动内容规则）。 FTP，WebDav和网络共享也用于访问同一个存储库。

Answer 6

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

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

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

Answer 7

我们将MediaWiki用于dos＆amp;眼镜。 Wiki肯定会赢得像Microsoft Word或SharePoint这样的东西 - 它允许您以“首先引用，然后描述”=“分而治之”的方式开发文档。非常适合开发人员 - 他们曾经以同样的方式思考。开发文档的过程几乎是理想的：您从TOC开始并向下钻取，直到您为之前放置的每个链接编写文档。

MediaWiki非常可定制 - 那里有很多扩展。最必要的是：

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

一些集成示例是here。

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

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

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

Answer 8

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

这是微软希望人们使用Office的东西，因此有很多关于如何配置SharePoint和Office环境以支持协作的doco。

Answer 9

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

Answer 10

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

也许您应该在37Signals查看Basecamp或Backpack，其中任何一个也可能适合您的账单。

Answer 11

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

如果您不喜欢直接编辑XML文件，那么GUI前端可以提供类似WYSIWYG的体验。我相信我办公室里的大多数人都使用XMLMind。尽管如此，我们碰巧都是技术人员，所以如果我们必须直接编写XML，那就不是问题了。

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

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

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

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

Answer 12

我们使用OnTime。它最初仅用于缺陷跟踪，但我们也开始使用它来跟踪功能。这些可用于记录在开发过程中发展的功能。功能可以组合在一起形成冲刺或发布，并且可以针对每个功能跟踪时间。如果您使用SCRUM，还可以为每个sprint绘制刻录图表。它还具有维基功能。

共享规格的软件/平台

12 个答案: