usando um wiki para requisitos


9

Estou procurando maneiras de melhorar o gerenciamento de requisitos. Atualmente, temos um documento do Word publicado em um site. Infelizmente, não podemos (que eu saiba) analisar as alterações de uma revisão para a seguinte. Eu preferiria muito poder fazê-lo, muito parecido com um wiki ou VCS (ou ambos, como o wiki no bitbucket!).

Além disso, cada documento descreve as mudanças que os desenvolvedores devem cumprir dentro de um prazo determinado. Não há nenhuma coleção de recursos de aplicativos acumulados documentados em qualquer lugar; portanto, às vezes é difícil distinguir entre um bug e um recurso (mal projetado) ao tentar fazer correções rápidas nos aplicativos herdados.

Então, tive uma ideia sobre a qual gostaria de obter feedback. A respeito:

  1. Usando um wiki para que possamos rastrear quem mudou o quê quando (principalmente para ver se foram feitas edições desde a última vez que se olhou).
  2. Ter uma página da wiki, por exemplo, por produto, em vez de uma por prazo, acompanhando todos os recursos do produto e não as alterações que devem ser implementadas. Dessa forma, eu posso olhar para uma revisão específica da página para ver o que o aplicativo deve fazer em um determinado momento e verificar as alterações na página desde a última versão para os requisitos a serem implementados até o próximo prazo .

Waddayathink?

Respostas:


9

Sim, isso parece uma boa solução, se você organizar a página em uma estrutura simples e fácil de navegar.

Escolha um wiki com uma sintaxe simples. (O Dokuwiki é simples e não requer um banco de dados)

Editar: se você usa um sistema de controle de versão, que é SVN ou BZR, tente o Trac , onde é possível definir marcos, manter solicitações de bugs e recursos e definir seu próprio fluxo de trabalho para gerenciar um bug! Wiki está incluído!


O DokuWiki é ótimo, muito fácil de configurar e inclui suporte a LDAP se você estiver trabalhando em uma empresa.
precisa saber é o seguinte

2

Um wiki é um bom caminho a percorrer. Eu acho que seria melhor se os documentos ainda fossem versionados. Você pode ter uma documentação flutuante compatível com os recursos mais atuais. Mesmo assim, é fácil para quem olha para trás encontrar a documentação para esse software três versões atrás, sem precisar examinar o histórico do documento, feito para reversões rápidas e pouco adequado para anos ou meses atrás.

Comecei usando o Media Wiki, mas agora estamos usando o Xwiki. Ele tem um editor de GUI bastante bom que qualquer pessoa deve poder usar sem nenhum treinamento. Ele também tem uma ideia chamada 'espaços'; cada espaço cria um novo espaço de nome para que produtos diferentes possam ter uma página chamada "recursos", em vez de product_x_features ou algo bobo, isso reduz bastante a necessidade de gerenciar várias instalações de wiki. Também existem ferramentas para integrar o word e o xwiki, permitindo salvar documentos do word diretamente no wiki. Todos disseram que é muito mais rico em recursos.


1

Eu gosto da sua abordagem wiki por projeto. Você mencionou o bitbucket, presumo que você os esteja usando como host do repositório. Caso contrário, também daria uma olhada nas wikis do GitHub.

Se você estiver disposto a gastar um pouco de dinheiro, faça o check-out do Farol . É a minha maneira favorita de rastrear solicitações de recursos e bugs no momento. Também gosto bastante de usar o Pivotal Tracker, o pivotal era gratuito, mas agora está mudando para um modelo pago.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.