使用wiki进行需求管理?

可以按照您的描述进行,以协作的方式开发需求, 尽管 使用维基。维基范式对这个过程没有任何帮助。

我在Zend框架项目上管理了一个wiki来跟踪组件的建议。 They're still using it. 建议不同于功能规范,但是用法与您的问题非常相似,我认为这是相关的。

一个维基并不关心它自己。除非你有人负责管理它并确保它有某种结构和一致性,否则它很快就会变得一团糟。现实世界中的类比是给每个团队一张空白的纸,告诉他们写下他们的需求部分。这方面的问题是:

• 每个贡献者必须组成自己的文档结构,并以不同的顺序写下不同的事情。所以不可能将一个页面与另一个页面进行比较。
• 没有“索引页”来组织所有不同的贡献。没有人想让一个页面“从裂缝中跌落”,但在wiki中,这是 违约 任何一页的命运一旦被写下来。
• 没有反馈循环来确保写作真正完成。

使其工作的方法是将一些过程应用到项目中,并根据该过程使用wiki。

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

“与需求管理工具相比,使用这样的工具有哪些优点和缺点?”

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

不会写字的人——嗯——不会写字。他们不能用电子邮件、wiki或任何媒介进行交流。

• 有些人是“无组织的”。事实上,写作过于线性化,他们不会线性思考。

• 有些人不会得到“给你的观众写信”和写一些不可理解的东西。

• 有时候,你甚至不知道他们在说什么,更不用说他们在写什么了。他们用行话或代码说话。他们不太了解,但坚持要被人听到。

有些人不会写信。

• 有些人拒绝作出承诺。即使在wiki中,它也可以被收回。他们觉得必须预先讨论每件事。

• 有些人习惯于做每件事都把方向交给别人。他们要么不为自己写作,要么让人们站在办公室里听他们说话打字。

• 有些人对任何项目都是有毒的。他们在最后一分钟提出了新的要求。他们的第一反应是“那永远不会奏效”。他们头脑风暴不好。当他们说这行得通,而你乞求他们改进时,他们却没有。他们只是知道这行不通。

我的经验是只有程序员才能成功地使用wiki。只有高级程序员。

• n00bz没有足够的经验从谣言和管理层的失误中找出需求。

• n00bz并不总是有清晰的语言能力。他们可能最终会这样做,但从JavaDoc的评论中可以看出,他们正在努力解决写作中的“清晰”问题。

很吸引人。我希望人们能更好地使用wiki,因为我认为它比传统的方法有很多优势,即一个人采访所有人并把事情写下来。但它需要的是沟通方面的自信和技巧,似乎很少有人拥有。

考虑研究 Fog Bugz . 他们吹捧自己是 最适合项目管理。考虑到乔尔的历史,我会给他们 怀疑的好处。他们按照你刚才描述的方式使用wiki。

如果你认真的话,我建议你报名参加免费审判。 根据项目的大小,购买它可能是非常好的 选择权。

至少你可以看看他们是如何组织的,或者阅读 论坛上的想法如何建立自己的精简版

专业工具有助于保持工作的正常进行,并引入固定的工作流程。这是一个要点,保持事情的重点和功能。使用像wiki这样的通用工具对很多程序员来说可能很好,但是为“混合模式”工作引入一个工具可能不好:

1. 事情可能会很快就偏离轨道
2. 媒体中的通信可能会丢失

看看大本营之类的东西。它们可以被认为是一个应用wiki,或者是一个协作工具。特定用途的通用工具需要改进。我不知道Mediawiki或其他公司是否有足够的定制来保持事物的整洁和集中。

也许可以收集需求管理工具(递归的,我知道)的需求,以及您可以从wiki文化和开放的沟通心态中获得哪些方面(沟通方面)。如果需求管理工具和wiki都不符合这个要求,那么就构建一个。可能是下一件大事。好像在说 我可以用wiki代替Bugzilla吗?

一个用于需求管理的固定工作流程webapp,具有开放的通信重点,允许来自多个角色的人看到和理解,这可能很好!

我们已经使用了twiki和foswiki。有很多东西是免费的(版本控制,访问控制,网络访问,搜索,远程管理,安全补丁…)。几分钟后,可以定义:

• 定义需求属性的表,
• 这将创建具有字段选择和验证的交互式表单(您还可以在其中记录讨论和理论、嵌入图像、附加文档、链接到其他要求…),
• 然后查询这些“需求”,并将其显示为可以排序、筛选、打印、报告等的表(例如, http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2 )

很明显,一路上可以很容易地使用超链接和wiki链接。Foswiki还具有一些功能,可以在需要时用于强制执行特定的工作流。支持用例和其他范例的表单也很容易(我们过去已经做过,而且通常工作得很好)。

像foswiki这样的wiki是可扩展的,可以开发更多的模块来解决与可跟踪性管理和影响分析、基于表的需求修改、总体打包等相关的弱点。

作为自由形式wiki和需求管理工具之间的中间地带,考虑使用 structured wiki 喜欢 Foswiki . 我没有进行任何正式的需求管理(使用wiki或其他方式),但是我使用了t wiki(foswiki的前身)来执行其他任务,它允许您根据需要定义工作流、表单字段等,同时在不需要正式结构时保持wiki的灵活性。

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

这可能有点旧了,但我现在使用的是亚特兰蒂斯的“汇合点”,它是伟大的。我目前是一名用户体验工程师,在敏捷过程中扮演“产品所有者”的角色。我可以记录离散接口的需求,允许多个用户的反馈和评论,并在更大的上下文(例如用户故事)中将每个接口与其他接口相互交织。一切都是动态的,模板驱动的。它非常适合我目前的需要。