使用Wiki进行需求管理？

Question

我一直在寻找一种用于开发功能规范的协作工具。我正在寻找：

的能力

• 让多个用户参与规范。
• 提供某种形式的可追溯性，如果需要可以手动完成。
• 为用户提供添加评论和备注的功能。
• 上传并显示Visio文档
• 使用Balsamiq Mockup上传和显示模型屏幕。

我最初的印象是使用wiki可能是完成此任务的好工具。有没有人有使用维基创建功能规范的经验？使用像这样的工具而不是需求管理工具会有什么利弊？

非常感谢您的投入！

Answer 1

可以做你所描述的，以协作的方式开发需求，尽管使用wiki。关于维基范式的任何内容都不会有助于此过程。

我在Zend Framework项目上管理了一个wiki来跟踪组件的提议。 They're still using it.提案与功能规范不同，但用法与我认为相关的问题相似。

维基不会照顾自己。除非你有人负责管理它并确保有一些结构和一致性，否则很快就会变得一团糟。现实世界的类比是将你的每个团队交给一张白纸，并告诉他们写下他们的部分要求。问题是：

• 每个撰稿人都必须编写自己的文档结构，并以不同的顺序写下不同的东西。因此，将一个页面与另一个页面进行比较是不可能的。
• 没有“索引页面”来组织所有不同的贡献。没有人想要一个页面“崩溃”，但在一个wiki中，只要它写完就是任何页面的默认命运。
• 没有反馈循环来确保写作实际完成。

使其工作的方法是将一些流程应用于项目，并根据该流程使用wiki。

• 让人们能够在wiki中创建新页面，但只能通过自动将新页面链接到正确索引的界面。
• 定义文档的生命周期，以确保在适当的阶段起草，审核和批准。
• 为新页面提供模板。在每个页面中提供您需要的章节标题，并使审核过程的一部分得到确认，即头部已经充分填写。

Answer 2

“使用像这样的工具而不是需求管理工具会有什么优缺点？”

虽然这似乎是一个好主意，但你遇到的是那些不能也不会写的人。

无法写作的人 - 好 - 不能写。他们无法与电子邮件或维基或任何外部语音通信。

• 有些人“杂乱无章”。实际上，写作过于线性，他们不会线性思考。

• 有些人没有“给你的观众写信”并写下难以理解的东西。

• 有时你甚至无法弄清楚他们在谈论什么，更不用说他们所写的内容。他们用行话或代码说话。他们不太了解但坚持听到。

有些人不会写。

• 有些人拒绝作出承诺。即使在维基也可以收回。他们认为他们必须预先讨论一切。

• 有些人习惯于通过指导别人来做所有事情。他们要么不为自己写作，要么让人们在办公室里站着，听他们说话和打字。

• 有些人对任何类型的项目都有毒。他们在最后一分钟提出了新的要求。他们的第一反应是“永远不会奏效”。他们没有头脑风暴。当他们说它起作用，你求他们改进时，他们就没有。他们只知道它不会起作用。

我的经验是只有程序员才能成功使用Wiki。而且只有高级程序员。

• N00bz没有足够的经验从设计中剔除谣言和管理漏洞。

• N00bz并不总是具备清晰写作的语言技能。他们最终可能会，但是看一看他们的Javadoc评论表明他们正在努力解决写作的“清晰度”部分。

非常有吸引力。我希望人们能够更好地使用维基，因为我认为它可以比传统的方法有很多优势，一个人采访每个人并写下来。但它需要一定程度的信心和沟通技巧，而这似乎很少有人能够实现。

Answer 3

考虑研究Fog Bugz。他们吹嘘自己是最好的 最适合项目管理。考虑到乔尔的历史，我会给他们 假定其无过失或无罪。他们以你刚刚描述的方式使用维基。

如果你是认真的话，我建议你报名参加免费试用。 根据您的项目规模，购买它可能是一个非常好的 选项。

至少你可以看看他们是如何构建它的，或者阅读它 有关如何构建自己的精简版本的想法的论坛

Answer 4

专家工具有助于保持正常运转并引入固定的工作流程。这是重点，保持事物的重点和功能。使用像Wiki这样的通用工具对于一群程序员来说可能是很好的，但为“混合模式”工作引入一个可能很糟糕：

1. 事情可能会迅速蔓延并迅速偏离正轨
2. 媒体可能会丢失通信

看看像Basecamp这样的东西。它们可以被视为应用的wiki或协作工具。用于特定目的的通用工具需要精炼。我不知道MediaWiki或其他人是否有足够的自定义来保持清洁和专注。

也许收集您的需求管理工具（我知道递归）的要求以及您可以从维基文化和开放式沟通思维方式中获取哪些方面（沟通方面）。如果需求管理工具或wiki都不符合要求，请查看构建一个。可能是下一件大事。感觉就像说我可以使用wiki代替Bugzilla吗？

用于需求管理的固定工作流Web应用程序，具有开放式沟通重点，允许来自多个角色的人员查看和理解可能是好的！

Answer 5

我们在这种情况下使用过TWiki和现在的FosWiki。免费获得许多东西（版本控制，访问控制，基于Web的访问，搜索，远程管理，安全补丁......）。几分钟后，人们可以定义：

• 定义需求属性的表，
• 通过字段选择和验证创建交互式表单（您还可以在其中记录讨论和理由，嵌入图像，附加文档，链接到其他要求......），
• 然后查询这些“要求”并将其显示为可以分类，过滤，打印，报告等的表格（例如http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2）。

显然，人们可以在此过程中轻松使用超链接和Wiki链接。如果需要，FosWiki还具有可用于强制执行特定工作流的功能。支持用例和其他范例的表单也很容易（我们过去已经这样做了，而且效果很好）。

诸如FosWiki之类的Wiki是可扩展的，可以开发更多模块来解决与可追溯性管理和影响分析，基于表格的需求修改，整体包装等相关的弱点。

Answer 6

作为自由格式维基和需求管理工具之间的中间环节，请考虑使用structured wiki之类的Foswiki。我没有进行任何正式的需求管理（使用维基或其他方式），但我已经使用TWiki（Foswiki的前身）执行其他任务，并且它允许您根据需要定义工作流，表单字段等它们，同时在不需要正式结构时保持wiki的灵活性。

Answer 7

我同意上面所有（大多数）人的意见 - 使用维基可能听起来不错，但维基应该是现有信息并根据需要进行更新，而不是用作交互式项目管理工具。我强烈建议使用SmartSheet（我是该产品的强力支持者） - 它提供了一个类似于界面的电子表格，您可以在每个行/任务中存储多个文件，向用户发送自动更新并维护规范修订...... 另一种方法可能是使用Google电子邮件，文档和日历 - 一种自由友好的团队互动方式......我会回避用于项目管理的问题/错误跟踪工具 - 他们往往在重点上有所不同：PM工具在整个项目/资源/时间线和问题跟踪工具上针对特定输入的问题......

Answer 8

现在这可能有点老了，但我现在正在使用Atlassian的“Confluence”，它很棒。我目前在一个敏捷过程中扮演用户体验工程师，扮演“产品负责人”的角色。我可以记录离散接口的要求，允许多个用户的反馈和评论，并将每个接口与更大的上下文（例如用户故事）中的其他接口交织在一起。一切都是非常动态和模板驱动的。它非常适合我目前的需求。