共享规格的软件/平台
您使用什么软件/ Wiki 来编写和分享有关开发人员、测试人员和管理人员的规范？
您使用 Wiki 系统吗？如果使用，您使用什么 Wiki 软件？
或者您是否使用 Sharepoint 来管理和版本化规范？ SharePoint 2003 作为规范平台的一个问题是不同人员之间的协作非常困难。
为了向后兼容，我还希望该平台能够无缝导入 Microsoft Word。 如果界面与 Microsoft Word 类似，那肯定会有所帮助。
任何想法？
What are the software/ Wiki you use to write and share your specs about the developers, testers and management?
Do you use Wiki system, and if so, what Wiki software you use?
Or do you use Sharepoint to manage and version the specs? One problem with SharePoint 2003 as specs platform is that it's very hard to collaborate among different people.
For backward compatibility sake, I would also like to have the platform able to import Microsoft Word seamlessly. And it would certainly help if the interface is similar to Microsoft Word.
Any idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我在很多地方使用过 Confluence，它是一个非常强大的 wiki，非常适合创建可以在各方之间共享的规范。 请参阅：
http://www.atlassian.com/software/confluence/
还有更多有关使用 Confluence 优势的信息：
https://stackoverflow.com/questions/170352/confluence-experiences
编辑：我已更新此内容以处理您提到的 Microsoft Word 导入功能。 Confluence 通过此处的 Office Connector 支持此功能：
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，请参阅：
http://www.jspwiki.org/
I've used Confluence at a number of places, it's a pretty powerful wiki and very good for creating specifications that can be shared amongst various parties. See:
http://www.atlassian.com/software/confluence/
There's some more information here on the advantages of using Confluence:
https://stackoverflow.com/questions/170352/confluence-experiences
EDIT: I've updated this to deal with the Microsoft Word import feature you mentioned. Confluence supports this through the Office Connector here:
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
There's also a Sharepoint connector:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
plus a whole bunch of plugins:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
Some of these are user contributed also. I can't recommend Confluence enough as a commercial wiki.
I've also used JSPWiki, which is open source. it's ok but not as good as confluence, see:
http://www.jspwiki.org/
您可以尝试 Google 文档 - 我过去曾成功使用过此方法。 它支持导入/导出到 MS Word，并且对多个用户有很好的支持 - 请参阅 http://www.brighthub.com/internet/google/articles/8236.aspx。
它支持版本控制，允许您与当前正在处理文档的其他人聊天，并向您显示其他人对文档所做的所有更改的列表（无需关闭/重新打开文档）。
如果您需要企业支持，Google 还提供 - 请参阅 Google Apps for Business 。
You could try Google docs - I have successfully used this in the past. It supports import / export to MS Word, and it has great support for multiple user - see http://www.brighthub.com/internet/google/articles/8236.aspx.
It supports versioning, allows you to chat with other people who are currently working on the document, and shows you a list of all the changes others have made to the document (without needing to close / reopen the document).
If you want corporate support, Google also provides that - see Google Apps for business.
我们使用 SharePoint——它并不理想，但它的表现还不错。 如果我是您，我会认真考虑放弃 SharePoint 2003 并转向 MOSS (SharePoint 2007)。 它并不完美，但已经好多了。 这里有一些关于使用 MOSS 作为 wiki 的内容。 我认为一般来说 wiki 是让人们快速了解您的系统的一个很好的工具。 我们过去常常传递“入门文档”，现在我们的开发人员门户中拥有所有此类内容。
根据约翰的评论，我查找了此功能比较。 我必须回去看看我正在使用的哪些功能不在 WSS 中 - 我可能会为我不需要的许可证付费！ :)
We use SharePoint -- it's not ideal, but it does a decent job. If I were you, I would seriously look at getting off SharePoint 2003 and on to MOSS (SharePoint 2007). It's not perfect, but it's substantially better. Here's a little bit on using MOSS as a wiki. I think in general wiki's are a good tool for getting people up to speed on your system. We used to pass around "getting started documents" and now we have all that type of stuff in our developer portal.
Per John's comment, I looked up this feature comparison. I have to go back and look at what features I'm using that are not in WSS -- I might be paying for licenses I don't need! :)
我们使用电子邮件。 我知道它并不复杂，但它很容易使用。 每个人都安装了它，并且不存在许可问题。 所有规范更改都会发送到超级集电子邮件发行版，指示更新以及可以在网络共享上找到规范的位置。
We use email. I know it isn't elaborate, but it is easy to use. Everyone has it installed and there are no licensing issues. All spec changes are sent to an super set email distro indicating the updates and the location on the network share where the spec can be found.
我们在其社区版本中通过其共享和资源管理器 Web 界面使用 Alfresco。
非常有用，有文档库、wiki、论坛和日历。
我们目前托管大约 1.8 Go，主要包含文档、版本控制，有时会自动转换为 PDF（通过创建自动内容规则）。
FTP、WebDav 和网络共享也用于访问同一存储库。
We use Alfresco, in its Community version, from both its Share and Explorer web interfaces.
Quite useful, with a document library, wiki, forum and calendar.
We curently host about 1.8 Go consisting mainly in docs, versionned and sometimes automatically converted to PDF (by creating an automatic content rule).
FTP, WebDav and network share are also used to access to the same repository.
您可以查看 Microsoft Groove - Microsoft 推出的协作软件几年前买的。
它与 Microsoft Office 高级版本免费捆绑在一起。
您可以使用讨论板自定义工作区，并且可以相当无缝地存储协作编辑的 Office 文档。
You could take a look at Microsoft Groove - the collaboration software that Microsoft bought a few years back.
It's bundled free with premium versions of Microsoft Office.
You can customize the workspace with discussion boards and can fairly seamlessly store collaboratively-edited Office documents.
我们使用 MediaWiki 来执行和执行操作。 眼镜。 Wiki 绝对比 Microsoft Word 或 SharePoint 更胜一筹 - 它允许您以“首先引用，然后描述”=“分而治之”的方式开发文档。 非常适合开发人员 - 他们曾经也以同样的方式思考。 开发文档的过程几乎是理想的：从目录开始，向下钻取，直到为之前放置的每个链接编写文档。
MediaWiki 是非常可定制的 - 有很多扩展。 最必要的是：
此处有一些集成示例。
我们使用 Google 问题跟踪器来跟踪问题。 它的主要优点：
它的主要缺点是无法关闭公共访问。 这使得它在许多情况下根本无法使用。
We use MediaWiki for dos & specs. Wiki definitely wins anything like Microsoft Word or SharePoint - it allows you to develop a documentation in "first refer, then describe" = "divide and rule" way. Perfect for developers - they used to think the same way. The process of developing a documentation is almost ideal: you start from TOC and drill down until you write the document for every link you put earlier.
MediaWiki is quite customizable - there are lots of extensions there. The most necessary ones are:
Some integration examples are here.
And we use Google issue tracker to track the issues. Its main advantages:
Its main disadvantage is that it can't be closed from the public access. This makes it simply unusable in many cases.
如果您想要类似于 Word 的 UI，为什么不将 Word 与 SharePoint 2007 一起使用呢？ 你现在是 2003 年，所以经验就在那里。 升级到SharePoint 2007，您可以拥有协作、Word功能、文档共享等。
这就是 Microsoft 希望人们使用 Office 的目的，因此有大量关于如何配置 SharePoint 和 Office 环境以支持协作的文档。
If you want a UI similar to Word, why not use Word with SharePoint 2007? You're on 2003 so the experience is there. Upgrade to SharePoint 2007 and you can have the collaboration, Word features, document sharing, and so on.
This is the kind of thing Microsoft wants people to use Office for, so there's a ton of doco out there about how to configure your SharePoint and Office environment to support collaboration.
Google 在这个方向做了一些事情，看起来非常酷：wave.google.com。 这将是合作中迈出的一大步，值得等待。
There is something that Google do in this direction and it looks really cool: wave.google.com. It would be a great step in collaboration and worth to wait it.
这里我们使用Google Docs，它使每个人都可以写入或只读文档，无论有或没有Google帐户的人都可以公开或私密，它还可以导入Word文档，更不用说它直接运行到浏览器中，因此它具有很高的性能。零成本和零设置的可用性，而且与计算机/操作系统无关，我们对此有很好的体验。
另外，也许您应该看看 37Signals 上的 Basecamp 或 Backpack，其中任何一个都可能适合您的需求。
Here we use Google Docs it makes the documents available to everyone write or read only, public or private among people that have or not Google accounts, it also can import Word docs, not to mention that it runs directly into the browser so it has high availability with zero cost and zero setup, also its computer/OS agnostic, we have a nice experience with it.
Also perhaps you should take a look at Basecamp or Backpack at 37Signals, any of then might also fit your bill.
我们对所有规范（以及其他面向客户的文档）使用 DocBook。 DocBook 是一种 XML 格式，可让您轻松生成几乎任何格式的文档，包括 PDF，这就是我们将内容分发给客户以让他们签字的方式。 我们可以将文档分成文件（按部分）并将所有内容提交到我们的源代码控制系统（Subversion）。 因为它都是 XML（即基于文本），所以如果两个人处理同一个文件，Subversion 的自动合并和冲突解决功能会非常有效。 我们有一组所有文档都使用的样式表，因此所有文档都共享完全相同的样式/格式，无需我们进行额外的工作。
如果您不喜欢直接编辑 XML 文件，可以使用 GUI 前端来提供类似所见即所得的体验。 我相信我办公室的大多数人都使用 XMLMind。 不过，我们碰巧都是技术人员，所以如果我们必须直接编写 XML，那也不是问题。
作为旁注，我们还发布了发行说明。 我们有一些 XSLT，可以让我们编写这样的文档：
然后，我们有一个脚本，该脚本通过我们的 Subversion 存储库运行，执行从先前版本标记到当前版本标记的
svn log，以及一些 Bugzilla 集成自动即时生成发行说明。（此外，对于大多数仅供内部使用的文档，我们使用 MediaWiki，这也是一个很好的方法合作。）
We use DocBook for all of our specifications (and other customer-facing documentation). DocBook is an XML format that lets you easily generate documents in just about any format, including PDF, which is how we distribute things to clients to get them signed off. We can divide a document into files (by section) and commit everything to our source control system (Subversion). Because it is all XML (i.e. text-based), Subversion's automatic merging and conflict resolution works great if two people work on the same file. We have a set of stylesheets that all of our documents use, so all documents share the exact same style/format, with no extra work on our part.
And if you don't like editing XML files directly, there are GUI front-ends that provide a reasonably WYSIWYG-like experience. I believe that most people in my office use XMLMind. Still, we happen to all be technical people so if we had to write XML directly it wouldn't be an issue.
As a sidenote, we also put out release notes. We have some XSLT that lets us write documents like this:
We then have a script that runs through our Subversion repository doing an
svn logfrom the previous release tag to the current release tag, and some Bugzilla integration to automatically generate release notes on-the-fly.(also, for most internal-only documentation, we use MediaWiki, which is also a great way to collaborate.)
我们使用OnTime。 它最初仅用于缺陷跟踪，但我们也开始使用它来跟踪功能。 这些可用于记录开发过程中演变的功能。 可以将功能分组到冲刺或发布中，并且可以根据每个功能跟踪时间。 如果您使用 SCRUM，您还可以为每个冲刺绘制燃尽图。 它还具有维基功能。
We use OnTime. It was originally only used for defect tracking, but we've started using it to track features as well. These can be used to document the feature as it evolves during development. Features can be grouped together into sprints or releases, and time can be tracked against each feature. If you are using SCRUM, you can also plot burn-down charts for each sprint. It also has wiki functionality.