Como o gerenciamento de requisitos funciona a longo prazo com projetos Agile?

O gerenciamento de requisitos a curto prazo para projetos Agile parece ser um problema resolvido para mim.

Do ponto de vista do Scrum, novos requisitos ou alterações nos requisitos existentes são entregues através das Histórias de Usuário. E as Histórias de Usuário agrupadas em uma Epopeia ou Recurso facilitam a entrega de requisitos maiores e mais complexos.

Obviamente, uma história de usuário não é tecnicamente um documento de requisitos. É um agrupamento gerenciável de trabalho que mapeia para o que geralmente é chamado de Fatia Vertical de funcionalidade. E o escopo dessas histórias pode ser definido sem ambiguidade através do uso de Critérios de Aceitação (CA).

Portanto, embora as Histórias de usuário não sejam requisitos formais, a navegação nelas pode fornecer uma idéia bastante clara dos requisitos subjacentes. A curto prazo.

Digo a curto prazo porque, à medida que o projeto avança, o número de histórias de usuários aumenta. Assim, navegar por uma lista cada vez maior de histórias para encontrar um requisito se torna cada vez menos eficiente ao longo do tempo.

Esse problema é agravado quando você considera as histórias de usuário que se expandem, substituem ou até negam as histórias anteriores.

Agora, imagine um intervalo de 2 anos entre as iterações de desenvolvimento em um projeto (estável na produção). A equipe original se foi e todos os seus conhecimentos também.

Se a equipe original sabia que isso iria acontecer (por exemplo, é a natureza do negócio), então que medidas eles poderiam tomar para ajudar as equipes subseqüentes?

Certamente, o backlog fornecerá algumas informações, mas dificilmente poderá ser navegado facilmente.

Então, o que pode ser feito para ajudar as equipes subsequentes a entender o estado do projeto, incluindo o porquê e como ele chegou lá?

Na minha experiência, as seguintes coisas não funcionam:

• Preparação do backlog para excluir ou atualizar as Histórias de Usuário anteriores, para que o Backlog possa ser lido como um documento de requisitos.
• Sprints de documentação, onde os membros da equipe têm a tarefa de documentar o estado atual do sistema.
• Documentação através de testes de comportamento . Essa abordagem é a única que eu vi chegar perto de funcionar. Infelizmente, os testes de comportamento codificado são vítimas do problema de nomeação. Embora os testes possam documentar adequadamente o sistema, é quase impossível conseguir uma equipe flutuante de desenvolvedores para escrever seus testes seguindo a mesma terminologia, texto e estilo do domínio.

Então, para reiterar:

Como se gerencia os Requisitos do projeto Agile a longo prazo?

Parece-me o elefante não dito na sala com projetos Agile: como você evita que eles evoluam para o caos?

Vamos dar uma olhada no Manifesto Ágil por um momento. Desejos ágeis:

1. Entrega antecipada e contínua
2. Adotando requisitos em mudança
3. Entrega de software funcional com freqüência
4. Desenvolvedores e partes interessadas do negócio trabalhando juntos diariamente
5. Construir projetos em torno de indivíduos motivados, dando-lhes o ambiente e o apoio de que precisam e confiando neles para realizar o trabalho
6. Conversação cara a cara como o principal modo de comunicação
7. Software de trabalho como a principal medida de progresso
8. Desenvolvimento sustentável
9. Atenção contínua à excelência técnica e bom design
10. Simplicidade - Maximizando o trabalho que você não precisa fazer
11. A intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.

Eu destaquei os quatro últimos. Por quê? Porque são eles que impedirão que o projeto entre em colapso com seu próprio peso.

Desenvolvimento sustentável significa que você (espero) tem alguém que supervisiona o processo geral de desenvolvimento, alguém que pode orientar o navio além do crescimento do software um pouco de cada vez, alguém que tenha uma visão abrangente de todo o projeto, alguém com um profundo conhecimento de arquitetura de software, design de sistema, princípios de lógica de negócios e ergonomia da interface do usuário. Um arquiteto, em outras palavras.

O arquiteto diz: "Eu sei que você pediu isso, mas se criarmos outra coisa, podemos evitar esses outros três recursos que são apenas confusos e focar no requisito principal". Ele é quem dá tempo à equipe para reduzir a dívida técnica. Ele é quem traz uma estrutura e organização abrangente para o projeto. Ele é quem convoca reuniões nas quais a equipe se reúne e pergunta "Como podemos fazer as coisas melhor?"

E é ele quem mantém o documento de requisitos mestre.

No livro Mastering the Requirements Process , os autores sustentam que existem três tipos de clientes, três tipos de projetos de software: Coelhos, Cavalos e Elefantes. Coelhos são pequenos projetos de software que precisam apenas de requisitos informais; você trabalha diretamente com o cliente em pequenos sprints, o escopo do projeto é razoavelmente restrito e o software é executado em um prazo relativamente curto. Os elefantes são aqueles projetos gigantescos que exigem muito planejamento inicial, uma quantidade enorme de documentação e um longo horizonte de tempo. É possível que eles não sejam ágeis, embora você possa dividi-los em projetos menores que podem ser criados usando o ágil.

São os projetos Horse que são um tanto confusos do ponto de vista ágil. Eles ainda podem ser construídos iterativamente, você ainda pode usar sprints curtos, mas sem alguma disciplina nos processos de coleta e planejamento de requisitos, eles podem sair facilmente dos trilhos. Esses são os projetos que podem se beneficiar de um processo disciplinado de coleta de requisitos e, em seguida, cuidadosa adaptação e modificação desses requisitos à medida que o projeto cresce, mantendo uma visão abrangente de todo o projeto.

De uma perspectiva pessoal, trabalho com uma pequena equipe de cerca de uma dúzia de desenvolvedores. A qualquer momento, podemos estar trabalhando em três projetos de software ao mesmo tempo, variando de alguns milhares de linhas de código a mais de 100.000. Nosso cliente pensa que é um coelho, mas é realmente um cavalo. O cliente está envolvido, mas não diariamente.

De longe, nossa área mais fraca está reunindo requisitos específicos, testáveis ​​e mensuráveis ​​e gerenciando as expectativas do cliente em relação ao escopo do projeto. Mas estamos trabalhando nisso.

A questão não está completamente clara, mas parece que você está preocupado com a rastreabilidade dos requisitos . Uma ideia que tende a se perder no Agile, na minha experiência, é que os requisitos de negócios são o que o cliente deseja que o sistema faça, enquanto as histórias de usuários são realmente requisitos funcionais que indicam como o sistema funciona. "Como usuário, eu quero poder X." Mas isso é feito para satisfazer um requisito, que pode ser perdido na história do usuário.

O que funciona bem na minha experiência é vincular os requisitos de negócios e as histórias de usuários nas duas direções. A BR # 1 pode ser percebida pelas histórias A e B. A história C pode abranger as BRs # 2 e # 3. Coloque isso em seu rastreador de projeto, planilha, o que você estiver usando.

A longo prazo, isso ajuda a vincular o que o cliente está pedindo (BRs) com o que o sistema faz (histórias) para alcançar esses requisitos. Essa deve ser uma documentação razoavelmente mínima, que não é onerosa para manter, mantendo a mentalidade ágil de não produzir documentação que ninguém precisa e é uma tarefa fácil de manter atualizada.

Ele também fornece uma maneira de os novos membros do projeto acelerar, uma vez que têm algo a revisar para obter o histórico por trás do porquê do software fazer o que faz.

Na verdade, estou trabalhando em um projeto de manutenção de Kanban de uma grande loja virtual, onde os desenvolvedores originais não estão mais disponíveis.

todo arquivo de usuário / requisito / correção de bug possui um número de ticket e toda alteração de código-fonte é vinculada a um número de ticket no campo sourcecontrol-comment-field.

O sourcecontrol-checkin-s (svn) atualiza automaticamente o ticket correspondente para que no ticket eu tenha um link para todos os sourceconrtol-changesets.

Se um módulo / função for implementado recentemente, também haverá números de ticket no código-fonte.

No sistema de ticket (redmine), os tickets são vinculados entre si como (é duplicado, é bug, é refinamento de, ....)

para que você possa seguir os tickets e ver as alterações dos requisitos ao longo do tempo.

Exemplo: preciso alterar algo na "orderConfirmation-Web-page". No código-fonte da página, vejo um comentário: 'created for "# 4711"' para que eu possa vincular meu novo ticket ao antigo ticket "4711" ou a um de seus sucessores.

Pessoalmente, descarto as histórias de usuários como fonte de documentação sobre o que o sistema pode fazer. A menos que etapas ativas tenham sido tomadas para criar a documentação (o que fizemos para alguns de nossos clientes mais tradicionais), a base de aplicativos é realmente a melhor documentação existente.

Embora isso não seja novidade.

Se você estiver usando uma versão mais escalada do Agile (como o SAFe ), terá outros registros em atraso que não são o registro em execução da implementação. Basicamente, é assim:

1. Backlog de portfólio (planejamento estratégico de épicos e orçamentos)
2. Lista de pendências de programa / versão (recursos e épicos)
3. Backlog do projeto / equipe (histórias, picos, bugs)

Eu não recomendaria documentar no nível do Backlog da equipe. É muito granular e raramente alguém quer ir para esse nível de detalhe. Sem mencionar que pode haver histórias em um Release que contradizem histórias anteriores no backlog da equipe.

Em vez disso, recomendo trabalhar no nível do Backlog da versão para fornecer documentação no nível da versão. Essas histórias raramente surgem uma vez atribuídas a uma versão específica e podem ser uma maneira estável e rápida de revisar o que está sendo trabalhado em uma determinada versão.