问使用Wiki进行需求管理？

EN

即使使用wiki，也可以按照您的描述，以协作的方式开发需求。在这个过程中，没有任何关于wiki范例的帮助。

我在Zend项目上管理了一个wiki来跟踪组件的建议。他们还在用呢。建议与功能规范不同，但用法与您的问题非常相似，因此我认为这是相关的。

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

• 每个贡献者都必须建立自己的文档结构，并以不同的顺序写出不同的东西。所以不可能把一页和另一页作比较。
• 没有“索引页”来组织所有不同的贡献。没有人想要一页“从裂缝中掉下来”，但在wiki中，这是任何页面一写就默认的命运。
• 没有反馈循环来确保实际的写作完成。

使其工作的方法是将某些过程应用到项目中，并按照该过程使用wiki。

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

考虑研究雾Bugz。他们吹嘘自己是项目管理中最好的人。考虑到乔尔的历史，我会给他们一点怀疑的好处。他们用你刚才描述的方式使用wiki。

如果你是认真的，我建议你申请免费审判。根据您的项目规模，购买它可能是一个非常好的选择。

至少，您可以查看它们是如何构建的，或者阅读论坛中关于如何构建您自己的精简版本的想法。

专家工具有助于保持工作正常进行，并引入固定的工作流程.这就是重点，保持事物的专注和功能。使用诸如Wiki这样的通用工具对一群程序员来说可能很棒，但为“混合模式”工作引入一种工具可能会很糟糕：

1. 事情会变得缓慢，而且很快就会偏离轨道。
2. 在媒介中可能会失去沟通。

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

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

一个固定的工作流的需求管理网络应用程序，一个开放的沟通重点，让人们从许多角色看到和理解可能是好的！