我一直在寻找用于开发功能规范的协作工具。我正在寻找以下能力：
- 让多个用户参与规范。
- 提供某种形式的可追溯性，如果需要，可以手动完成。
- 为用户提供添加评论和注释的能力。
- 上传和显示 Visio 文档
- 使用 Balsamiq Mockup 上传和显示模型屏幕。
我最初的印象是，使用 wiki 可能是完成这项任务的好工具。有没有人有使用 wiki 创建功能规范的经验？与需求管理工具相比，使用这样的工具有什么优缺点？
非常感谢您的意见！
问问题
7875 次
8 回答
10
尽管使用 wiki ，但可以按照您的描述以协作的方式开发需求。wiki 范式在这个过程中没有任何帮助。
我在 Zend Framework 项目上管理了一个 wiki，以跟踪组件的建议。 他们仍在使用它。 提案与功能规范不同，但用法与您的问题足够相似，我认为这是相关的。
wiki 不会照顾自己。除非你有人负责管理它并确保有一些结构和一致性，否则它很快就会变得一团糟。现实世界的类比是给你的每个团队一张白纸，并告诉他们写下他们的部分需求。这方面的问题是：
- 每个贡献者都必须构建自己的文档结构，并以不同的顺序撰写不同的内容。因此，不可能将一页与另一页进行比较。
- 没有“索引页面”来组织所有不同的贡献。没有人希望页面“落入裂缝”，但在 wiki 中，这是任何页面一旦编写完成后的默认命运。
- 没有反馈循环来确保写作真正完成。
使其工作的方法是对项目应用一些流程，并按照该流程使用 wiki。
- 使人们能够在 wiki 中创建新页面，但只能通过自动将新页面链接到正确索引的界面。
- 定义文档的生命周期，确保它们在适当的阶段被起草、审查和批准。
- 为新页面提供模板。在每个页面中提供您需要的部分标题，并在审核过程中确认标题部分已充分填写。
于 2009-05-11T20:36:39.007 回答
7
“与需求管理工具相比，使用这样的工具有什么优缺点？”
虽然这似乎是一个好主意，但你遇到的是那些不会也不会写作的人。
不会写的人——嗯——不会写。他们无法通过电子邮件或 wiki 或任何外部声音媒介进行交流。
有些人“杂乱无章”。实际上，写作太线性了，他们不会线性思考。
有些人没有得到“写给你的听众”的意思，写出难以理解的东西。
有时你甚至无法弄清楚他们在说什么，更不用说他们在写什么了。他们用行话或代码说话。他们知道的不多，但坚持要被倾听。
有些人不会写。
有些人拒绝做出承诺。即使在可以收回的wiki中。他们觉得他们必须预先讨论所有事情。
有些人习惯于通过给别人指示来做每件事。他们要么不为自己写作，要么让人们站在办公室里听他们说话和打字。
有些人通常对任何类型的项目都是有毒的。他们在最后一刻提出了新的要求。他们的第一反应是“那永远行不通”。他们不能很好地进行头脑风暴。当他们说它有效，而你请求他们改进时，他们没有。他们只知道这行不通。
我的经验是，只有程序员才能成功使用 Wiki。而且只有高级程序员。
N00bz 没有足够的经验从谣言和管理绒毛中梳理出设计需求。
N00bz 并不总是具备清晰书写的语言技能。他们最终可能会这样做，但一看他们的 Javadoc 注释就可以看出他们正在为写作的“清晰性”部分而苦苦挣扎。
它非常吸引人。我希望人们能够更好地使用 wiki，因为我认为它比一个人采访每个人并写下来的更传统的方法有很多优势。但它需要一定程度的自信和沟通技巧，而这似乎很少有人具备。
于 2009-05-11T20:18:24.120 回答
4
考虑研究Fog Bugz。他们吹嘘自己是项目管理中的佼佼者。考虑到乔尔的历史，我会给他们怀疑的好处。他们以您刚才描述的方式使用 wiki。
如果您是认真的，我建议您注册免费试用版。根据您项目的规模，购买它可能是一个非常好的选择。
至少你可以看看他们是如何构建它的，或者阅读论坛以获取有关如何构建自己的精简版本的想法
于 2009-05-11T21:11:51.287 回答
2
专业工具有助于让事情保持正轨并引入固定的工作流程。这就是重点，让事情保持专注和功能。使用像 Wiki 这样的通用工具对一群程序员来说可能很好，但为“混合模式”工作引入一个可能很糟糕：
- 事情可能会迅速蔓延并偏离轨道
- 沟通可能会在媒体中丢失
看看像 Basecamp 这样的东西。它们可以被认为是一个应用的 wiki 或协作工具。用于特定目的的通用工具需要改进。我不知道 MediaWiki 或其他人是否有足够的定制来保持事情的清洁和专注。
也许收集您的需求管理工具的需求（我知道是递归的）以及您可以从 wiki 文化和开放式沟通心态中获得哪些方面（沟通方面）。如果需求管理工具或 wiki 都不符合要求，请考虑构建一个。可能是下一个大事件。感觉就像在说我可以使用 wiki 代替 Bugzilla 吗？
一个用于需求管理的固定工作流 web 应用程序，强调开放式沟通，让来自不同角色的人都能看到和理解，这可能是件好事！
于 2009-05-11T20:28:11.047 回答
2
在这种情况下，我们使用了 TWiki，现在使用了 FosWiki。有很多东西是免费的（版本控制、访问控制、基于 Web 的访问、搜索、远程管理、安全补丁……）。几分钟后，您可以定义：
- 定义需求属性的表，
- 它创建具有字段选择和验证的交互式表单（您还可以在其中记录讨论和基本原理，嵌入图像，附加文档，链接到其他要求......），
- 然后查询这些“需求”并将它们显示为可以排序、过滤、打印、报告等的表格（例如， http: //jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2） .
显然，一路上可以很容易地使用超链接和 Wiki 链接。如果需要，FosWiki 还具有可用于强制执行特定工作流的功能。支持用例和其他范式的表单也很容易（我们过去曾这样做过，而且通常效果很好）。
诸如 FosWiki 之类的 Wiki 是可扩展的，可以开发更多模块来解决与可追溯性管理和影响分析、基于表格的需求修改、整体打包等相关的弱点。
于 2010-10-16T14:43:23.760 回答
1
作为自由形式的 wiki 和需求管理工具之间的中间地带，可以考虑使用像Foswiki这样的结构化 wiki。我没有做过任何正式的需求管理（使用 wiki 或其他方式），但我使用 TWiki（Foswiki 的前身）来完成其他任务，它允许您根据需要定义工作流、表单字段等它们，同时在不需要正式结构时保持 wiki 的灵活性。
于 2009-05-11T21:17:25.070 回答
0
我同意上述所有（大多数）人的观点 - 使用 wiki 可能听起来不错，但 wiki 旨在提供信息并根据需要进行更新，而不是用作交互式项目管理工具。我强烈建议 SmartSheet（我是该产品的坚定拥护者）——它提供了一个类似电子表格的界面，您可以在其中为每行/任务存储多个文件，向用户发送自动更新并维护规范修订......另一种方法可能是使用谷歌电子邮件、文档和日历——一种免费的友好的团队互动方式……我会回避用于项目管理的问题/错误跟踪工具——它们的重点往往不同：整个项目管理工具针对特定输入问题的项目/资源/时间线和问题跟踪工具....
于 2009-05-11T22:50:24.777 回答
0
这现在可能有点老了，但我目前正在使用 Atlassian 的“Confluence”，它很棒。我目前是一名 UX 工程师，在敏捷过程中扮演“产品负责人”的角色。我可以记录离散界面的需求，允许多个用户的反馈和评论，并在更大的上下文（例如用户故事）中将每个界面与其他界面交织在一起。一切都非常动态和模板驱动。它非常适合我目前的需求。
于 2014-10-01T18:28:02.540 回答