Como você acompanha um documento de requisitos em uma equipe ágil?

Entendo que as Histórias de Usuário dominam o mundo ágil, mas como esses artefatos são armazenados, para que os novos desenvolvedores que se juntam à equipe possam acompanhar os requisitos?

E se a História do Usuário mudar posteriormente, como é atualizada e mantida como um artefato? Eu já vi muitas equipes abrirem um novo ticket / solicitação de recurso / relatório de erro em vez de acompanhar a história original.

Primeiro, quase nada na resposta do @ DXM corresponde à minha experiência com o Agile, e especialmente não com o Scrum.

O Manifesto Ágil afirma que, embora a documentação abrangente seja valiosa, o software de trabalho é MAIS valioso. Portanto, a documentação certamente não é uma coisa ruim, mas deve realmente servir a criação de software funcional.

Indivíduos e interações sobre processos e ferramentas

Software de trabalho sobre documentação abrangente

Colaboração do cliente sobre negociação de contrato

Respondendo a mudanças após seguir um plano

Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda.

Pregar todos os detalhes antes de começar a codificar provou ser um desperdício repetidamente, de modo que a documentação é geralmente tratada de maneira JIT (apenas a tempo). Ou seja, você documenta o que realmente vai codificar.

Uma das maneiras populares de fazer o Scrum é usar as Histórias de Usuário, que são mantidas pelo Dono do Produto e mantidas no Backlog do Produto. O Backlog do produto é uma lista de alto nível de todas as coisas que uma solução precisa fazer, e uma História do usuário geralmente é uma maneira adequada de descrever cada item da lista. As histórias de usuário não são obrigatórias, mas parecem ser uma boa maneira de não exagerar nos detalhes e inspirar colaboração.

Portanto, de qualquer maneira, quando uma história é concluída - a equipe criou, testou e implantou algo que atende aos critérios de aceitação, a história não é CHUCKED, é simplesmente marcada como concluída no backlog - para que o backlog tenha alguma indicação do que foi feito em cada corrida - histórias e os pontos associados a elas. É isso que permite calcular a velocidade e é uma documentação valiosa por si só.

Tudo isso dito, uma História de usuário pode ser toda a documentação necessária para entender um requisito, mas, mais provavelmente, é algo para gerar uma conversa entre o cliente e a equipe de desenvolvimento. Como tal, há várias coisas que você pode fazer em torno dessa conversa. Se for algo ad hoc cara a cara, como costuma ser, o analista / desenvolvedor pode (e possivelmente, dependendo da sua organização) deve escrever as decisões que foram tomadas e salvá-las em algum lugar, como Wiki ou repositório de documentação. Se for uma conversa por email, você pode salvar os emails. Se for uma sessão de quadro branco, tire uma foto do quadro com seu celular e salve-o. O ponto é que essas coisas são o que estão ajudando você a executar o código e podem ajudá-lo mais tarde, se precisar descobrir como ou por que você fez o que fez.

Outro método de capturar requisitos é incorporá-los imediatamente nos casos de teste (que eu acredito que é o que o DXM estava obtendo). Isso pode ser realmente eficiente, pois você precisa testar cada requisito de qualquer maneira. Nesse caso, você pode efetivamente armazenar seus requisitos em sua ferramenta de teste.

Se uma história for concluída (e aceita) e o usuário alterar sua necessidade, bem, provavelmente você precisará criar uma nova história. Se você usar um wiki para sua documentação, poderá vincular a nova história ao original e também vincular a história original às novas, para que alguém que a veja saiba que as coisas mudaram. Essa é a coisa legal dos wikis - é fácil e bastante indolor vincular coisas. Se você estiver adotando a abordagem orientada a testes, atualize o caso de teste para lidar com a mudança ou crie novos casos de teste para a nova história, se o novo e o antigo não forem mutuamente exclusivos.

No final, depende de qual é sua necessidade. Se o principal é acelerar o processo rapidamente, provavelmente é uma boa ideia alguém escrever um documento de integração para ajudá-lo. Então, alguém faça isso. Como mencionei, os Wiki são uma ótima ferramenta para manter esse tipo de coisa, então você pode considerar as soluções da Atlassian que podem integrar o Confluence Wiki com Jira e Greenhopper para rastrear suas histórias / tarefas / defeitos e gerenciar seu projeto em geral. Existem muitas outras ferramentas por onde escolher também.

[atualização # 1] Como o @MatthewFlynn apontou, sua experiência com o Agile e com muitos outros (incluindo o meu) é muito diferente da resposta que estou fornecendo aqui. A resposta aqui é baseada em minhas observações do que funcionou e não funcionou em minha própria equipe no passado, combinada com muitos livros e blogs que li sobre o assunto ...

a maior parte do caminho para o desenvolvimento ágil é voltada especificamente para a eliminação de documentos de requisitos.

O Agile tenta acabar com a maior parte da documentação e eu concordo com as idéias deles, mas, dentre todos os documentos, os requisitos têm de longe o maior olho de boi pintado sobre eles. A razão para isso (IMO) é que os documentos de requisitos estão mais distantes do código de trabalho real e de todos os documentos, o que os torna

• menos preciso
• mais difícil de manter
• menos útil

Para orientar a equipe sobre o que deve ser desenvolvido a seguir, o Agile substitui os documentos de requisitos por uma lista de pendências de histórias que identificam o que você deve trabalhar nos itens seguintes e de prioridade mais alta com maior retorno do investimento (retorno atual e futuro) normalmente são os primeiros nessa lista.

No entanto, uma lista não processada não deve ser confundida com um documento de requisitos:

• Em uma lista de pendências, apenas um número N de histórias deve ter detalhes preenchidos. Quanto mais longe uma história é, menos detalhes você deve colocar nela (ou seja, não perca seu tempo tentando definir algo que não acontecerá por meio ano )
• Além de um certo ponto, os itens de "requisitos" não devem ser colocados em lista de pendências se houver mais de dois ciclos de liberação (também conhecidos como possíveis incrementos entregáveis ​​(PSI)). Mesmo se você souber que o requisito é importante e deve ser concluído em algum momento, resista à tentação de adicioná-lo ao backlog. Se for realmente importante, alguém se lembrará disso no próximo lançamento. Se ninguém se lembra, provavelmente é porque não era tão importante assim.

Depois que uma história é concluída, ela é removida da lista de pendências e é CHUCKED ⁽¹⁾ . Novamente, histórias não são requisitos. Eles APENAS dizem à equipe no que trabalhar; eles não são para registro histórico.

No entanto, no processo ágil adequado, sempre que você entrega trabalho, parte dessa entrega deve ser testes de unidade / integração / aceitação. Esses testes são muito valiosos porque têm muitos propósitos. Não entrarei na lista completa, mas um desses propósitos é a documentação do seu software de produção atual.

Um teste documenta como o software deve se comportar, considerando um determinado conjunto de entradas e pré-condições. Ele também documenta como usar APIs públicas (e internas) do seu código. Ele também serve como uma rede de segurança para que, quando um novo desenvolvedor entre em uma equipe e quebre algo inadvertidamente, esse erro seja detectado assim que for feito o check-in.

Obviamente, o processo ágil promove o aproveitamento dos testes de unidade automatizados, tanto quanto possível, mas todos sabemos que nem tudo pode ser automatizado. Seu conjunto de software sempre terá um conjunto de testes que precisam ser executados manualmente. No entanto, a) seus desenvolvedores devem trabalhar ativamente na automação, tanto quanto possível eb) o conjunto manual de testes deve ser executado regularmente pela sua equipe de controle de qualidade, para que qualquer quebra de funcionalidade seja descoberta o mais rápido possível.

⁽¹⁾ - Desde que recebi várias respostas para a parte "jogada". Em cinco anos desde que mudei para o Agile, minha equipe nunca jogou fora uma única história, mesmo 30% daqueles que foram agendados, adiados e esquecidos. Meu chefe queria mantê-los "para referência" e, no entanto, ninguém nunca olhou para nenhuma dessas histórias.

As pessoas geralmente são anexadas aos seus dados e eu sei que é difícil imaginar jogar alguma coisa uma vez que você já a possui, mas manter o inventário (físico ou eleitoral) disponível não é gratuito e quanto mais eu penso sobre isso, mais eu concordo com o "chuck". Isso é de "Requisitos de software ágil: práticas de requisitos enxutos para equipes, programas e empresas" (p.190) - "As histórias de usuários podem ser descartadas com segurança após a implementação. Isso as mantém leves, as equipes amigáveis ​​e promove a negociação, mas os testes de aceitação persistem por toda a vida útil do aplicativo ... "

E se a História do Usuário mudar posteriormente, como é atualizada e mantida como um artefato? Eu já vi muitas equipes abrirem um novo ticket / solicitação de recurso / relatório de erro em vez de acompanhar a história original.

O gerenciamento de qualquer documentação pode ser difícil, independentemente de você estar usando histórias ágeis ou um grande documento inicial, e para reduzir a carga, a documentação deve ser mínima e atualizada de forma incremental para corresponder aos esforços que estão sendo feitos nos testes e na implementação. Como o OP aludiu, no entanto, simplesmente atualizar a documentação corre o risco de perder o histórico de como o software evoluiu ao longo do tempo.

Isso é realmente importante? Às vezes pode ser. Na maioria das vezes, você simplesmente deseja visualizar as histórias / UML / o que quer que seja junto com os testes e o próprio código no momento, no entanto, quando são levantadas questões sobre o motivo de um recurso ter sido implementado de uma maneira específica, geralmente pode ser útil olhar para a história, a fim de ver como o recurso mudou ao longo do tempo, para pintar uma imagem mais clara do porquê opção de implementação X foi escolhida em vez da opção Y .

Existem algumas maneiras pelas quais você pode acompanhar esses artefatos. Uma das melhores opções pode ser manter suas histórias em uma ferramenta que permita a versão do texto da história de maneira semelhante à versão do seu código-fonte. Os wiki tendem a ser muito bons nisso, assim como algumas das ferramentas de gerenciamento de projetos / problemas, como Trac ou Redmineque mantêm históricos de alterações nos próprios problemas, bem como nas páginas wiki desses sistemas. Isso pode ser levado um pouco mais longe, para melhorar a capacidade de rastrear alterações de um problema para um recurso, garantindo que novas histórias ou problemas estejam vinculados de alguma forma a problemas e histórias relacionados mais antigos. Isso pode ser tão simples quanto adicionar um ID de problema / história mais antigo ao texto de um problema / história mais recente, mas pode ser melhorado bastante com a inclusão de qualquer ID de problema ou de história no comentário do check-in sempre que você confirmar uma alteração no sistema de controle de versão . Esse método é de maior valor, no entanto, se seus commits forem frequentes e limitados a uma única história ou questão.

A maior dificuldade, é claro, é que esse tipo de abordagem exija atenção cuidadosa e um compromisso de cada membro da equipe para ser consistente e manter seus compromissos pequenos e frequentes, e para aqueles que gerenciam as histórias e / ou sistemas de rastreamento de problemas / projetos para manter na parte superior dos artefatos que fornecem links entre o estado atual da sua implementação e todas as alterações que ocorreram anteriormente.

Já foi dito antes, mas acho que o essencial é o seguinte:

• os requisitos podem cobrir muitas facetas e normalmente resultam em mais de uma história.

• uma história organiza o trabalho de uma equipe em pedaços pequenos o suficiente para caber dentro dos limites de tempo de um sprint.

• geralmente existem muitos detalhes que precisam ser definidos para que uma função específica funcione corretamente. É quando começa a ser útil manter essas definições em um documento de requisitos separado - para maior clareza, entendimento comum e referência posterior.

Considere o lendário exemplo de pet shop online:

• A história pode dizer "Como usuário, quero ver o IVA impresso no meu recibo, ...". Agora, o cálculo do IVA (imposto sobre valor agregado) pode ser uma questão complicada e provavelmente precisa de mais trabalho do que sugere esta história.
• Pode haver uma história adicional solicitando que o cálculo do IVA seja feito (por exemplo, multiplique o valor total da venda pela taxa do IVA ), mas é provável que não inclua todas as variações desse cálculo.
• Inicialmente, a equipe se concentraria em fornecer o módulo básico, digamos, pegar uma lista de mercadorias e seu preço de venda e devolver o valor do IVA. Isso é algo que uma equipe pode realizar dentro do período de tempo de um sprint.
• É provável que haja muito mais histórias para cobrir todos os casos possíveis para o cálculo do IVA.
• Para manter as muitas regras diferentes de cálculo do IVA visíveis para além de sprints únicos, faz sentido manter um documento de requisitos separado que lista todas as várias maneiras de calcular o IVA. Este documento pode evoluir com o tempo. De fato, adicionar uma nova seção a ela pode fazer parte da tarefa de uma história a ser concluída.

Você pode usar o freemind para reunir a lista de recursos. Como é feito, dê uma olhada neste tutorial (em algum lugar no meio).

Quando você tem uma lista de recursos, escreve histórias de usuários. Isso pode ser feito usando um arquivo de texto simples, um documento do Word ou algo tão complexo quanto uma ferramenta de gerenciamento ágil .

Quando você termina as histórias de usuários, elas são priorizadas. Posteriormente, a partir das histórias de usuários, as pessoas produzem tarefas, as executam e as implementam no código.

Tudo isso pode ser visto como o projeto ac # é gerenciado desde o início do outono das séries de elenco de vídeo ágil .