使用维基来满足需求


9

我正在研究改善需求管理的方法。当前,我们在网站上发布了Word文档。不幸的是,(据我所知)我们无法查看从一个修订版到下一个修订版的更改。我非常希望能够做到这一点,就像使用Wiki或VCS(或两者,就像Wiki在bitbucket上一样!)。

而且,每个文档都描述了开发人员在给定的截止日期之前预期会遇到的变更。在任何地方都没有记录到的累积应用程序功能集合,因此,在尝试快速修复旧版应用程序时,有时很难区分错误和(设计不良)功能。

所以我有一个想法想要得到反馈。关于什么:

  1. 使用Wiki,以便我们可以跟踪谁更改了什么时间(主要是查看自上次查看以来是否进行了任何编辑)。
  2. 每个产品只有一个Wiki页面,而不是每个截止日期只有一个Wiki页面,以跟上产品的所有功能,而不是应实施的更改。这样,我可以查看页面的特定版本,以查看应用程序在给定时间点应执行的操作,并且可以查看 自上次发布以来对页面的更改,以在下一个截止日期之前实现要求。

Waddayathink?

Answers:


9

是的,这听起来不错,如果您以简单的结构组织页面,易于浏览。

选择具有简单语法的维基。(Dokuwiki是一个简单的数据库,不需要数据库)

编辑:如果您使用的是SVN或BZR版本控制系统,请尝试Trac,您可以在其中定义里程碑,保留错误和功能请求,以及定义自己的工作流程来管理错误!包括维基!


DokuWiki非常好,非常容易设置,并且如果您在企业内工作,它还包含LDAP支持。
旧帐户

2

Wiki是一个不错的选择。我认为最好还是对文件进行版本控制。您可以拥有具有最新功能的浮动文档。仍然以这种方式拍摄快照,对于某些人来说,回头查找三个版本之前该软件的文档非常容易,而不必浏览文档历史记录,因为历史记录是为了快速还原而设计的,因此不适合回顾几年或几个月。

我开始使用Media Wiki,但现在我们使用的是Xwiki。它有一个非常好的GUI编辑器,任何人都可以使用它,而无需任何培训。它还有一个称为“空格”的想法,每个空格都会创建一个新的名称空间,因此不同的产品都可以具有一个称为“功能”的页面,而不是product_x_features或一些愚蠢的东西,这大大减少了管理多个Wiki安装的需求。还有一些工具可以将word和xwiki集成在一起,使您可以将word文档直接保存到wiki。所有人都说它功能丰富得多。


1

我喜欢您的每个项目Wiki方法。您提到了bitbucket,我假设您将它们用作存储库主机。如果不是的话,我还要看看GitHub上的Wiki。

如果您愿意花一点钱,请查看Lighthouse。这是我目前最喜欢的跟踪功能请求和错误的方法。我也非常喜欢使用Pivotal Tracker,Pivotal是免费的,但现在正朝着付费模式发展。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.