We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(6)
+10⁶ 对于 Wiki,这是我迄今为止找到的文档(尤其是技术文档)的最佳解决方案。 IMO,“好的”Wiki 引擎相对于 VCS 中的 Office 文档的优势是(但您已经意识到这一点,因为此功能列表非常接近您的要求):
我在使用文档的 Wiki 的缺点是,很难在与代码同时对文档进行版本控制(即,您交付版本 xyz 并希望“锁定”该版本的文档)。我已经使用导出来解决这个问题,但它并不完美。
我已经与
TWikiFoswiki、Confluence 和 XWiki。它们都是“好的”Wiki 引擎(如上面所定义)并且都满足您的要求。因此,最终的选择可能仅取决于您的限制(许可证、定价、技术)和个人喜好。截至今天,如果可以选择商业工具,我会选择 Confluence,如果没有,我会选择 XWiki。
+10⁶ for a Wiki, it's the best solution I've found so far for documentation, especially technical documentation. IMO, the advantages of "good" Wiki engines over Office documents in a VCS are (but you're already aware of that as this features list is very close to your requirements):
The only issue I've faced when using a Wiki for documentation is that it's harder to version your documentation in the same time as your code (i.e. you deliver version x.y.z and want to "lock" the documentation of this version). I've used exports to solve this but it's not perfect.
I've already worked with
TWikiFoswiki, Confluence and XWiki. They are all "good" Wiki engines (as defined above) and all meet your requirements. So the final choice may just depend on your constraints (license, pricing, technology) and personal preferences.As of today, I'd choose Confluence if a commercial tool is an option, XWiki if not.
一个更另类的想法是查看 FitNesse。它是一个 wiki,主要旨在将业务规则(或验收要求)描述为测试。
A more off-the-wall idea is to look into FitNesse. It is a wiki, primarily aimed at describing business rules (or acceptance requirements) as tests.
我正在开发一个。
大约一年前,我在网上寻找需求管理软件,发现了至少 30 个软件,大约分为 3 个类别:
无价(例如在航空航天公司销售)
昂贵(例如每个席位 1000 美元),我的雇主从未选择使用它
便宜或免费,但缺少对我来说重要的功能
还有通用工具(例如 Wiki、电子邮件和 Word 文档和/或电子表格),这些工具也缺少在我看来很重要的功能。
您可以使用通用 Wiki 做一些事情:
但是,我认为有些事情是通用 Wiki 无法做到的,甚至是非常基本的事情:
帮助跟踪(当只有两个阶段时,跟踪不太困难,例如“需求”和“实现”;但是当有多个阶段时,例如“用例”、“功能规范”、“架构”、“实现细节”、“测试用例”、“测试结果”和“错误报告”)
支持结构化信息,即小节而不仅仅是顶级部分。
即使只是简单的编辑也没有达到应有的效果。商务人士可能更喜欢使用 MS Word UI 进行编辑:但 MS Word 生成文档,即“信息孤岛”;但如果您不使用 MS Word,那么您正在使用什么?所见即所得的浏览器内编辑器?或者markdown语法?
I am developing one.
About a year ago I looked for requirement management software on the 'net and found at least 30 of them, in approximately 3 categories:
Priceless (and marketed e.g. at aerospace companies)
Expensive (e.g. $1000s per seat), which my employers have never chosen to use
Cheap or free, but missing features which seem to me important
There are also general-purpose tools (e.g. Wiki, or emails and Word documents and/or Spreadsheets), which too are missing features which seem to me important.
There are things which you can do with a general-purpose Wiki:
But, there are some things which I think you can't do with a general-purpose Wiki, even pretty basic things:
Define custom attributes (e.g. "Date started", "Estimated cost", etc.); associate these attribute values with your features; list features (in a table or grid) with their attributes (so that they can be sorted, e.g. sorted by "Importance" or by "Difficulty")
Help with traceability (traceability not too difficult when there are only two stages, e.g. "requirements" and "implementation"; but it's harder when there are several stages, e.g. "use cases", "functional spec", "architecture", "implementation details", "test cases", "test results", and "bug reports")
Support structured information, i.e. subsections and not just top-level sections.
Even simply editing isn't a nice as it ought to be. Business people might prefer use an MS Word UI for editing: but MS Word produces documents, i.e. "information silos"; but if you don't use MS Word, then you're using what? A WYSIWYG in-browser editor? Or markdown syntax?
我喜欢使用 FogBugz 中内置的 Wiki 功能来实现此目的,假设您已经使用它来进行功能/错误跟踪。在同一个工具中包含这些信息很方便。
I like using the Wiki feature built into FogBugz for this, assuming you already use it for feature/bug tracking. It's handy to have that info in the same tool.
Drupal 满足您列出的要求,它具有高度可扩展性,具有大量模块(请参阅下面的一些内容),并且可以在 GPL 下使用。
Drupal meets your listed requirements, it is highly extensible with loads of modules (see some below) and it's available under GPL.
我们在之前的项目中使用 JIRA 来存储大约 750 个不同的业务规则。 JIRA 主要/有点是一个错误跟踪工具,但它非常强大且可定制,您可以将它用于各种工作流程/流程/知识库情况。 (顺便说一句 - 我不为生产它的公司工作)。
如果您决定走这条路,请提供一些提示...
这是一个很好的方法,我真的推荐它。
We have used JIRA on a previous project to store around 750 different business rules. JIRA is mostly/kinda-of a bug tracking tool, but it's so powerful and customisable that you can use it for all sorts of workflow/process/knowledge base situations. (BTW - I don't work for the company that produces it).
Some tips if you do decide to go down this path...
It's a great approach and I'd really recommend it.