Tarefas de desenvolvimento compartilhadas para histórias de usuários ágeis

Minha equipe usará o Visual Studio Team Services para um próximo projeto. As ferramentas Agile permitem organizar hierarquicamente histórias e tarefas do usuário da seguinte maneira:

Epic> Feature> História do usuário> Task / Bug

Digamos que estou projetando um sistema de gerenciamento da organização estudantil (clube) para estudantes e conselheiros do ensino médio. Estudantes e orientadores podem ingressar em clubes, ser dirigentes, organizar eventos, enviar anúncios etc.

Vamos usar o recurso Anúncios como exemplo:

Histórias de usuários:

• Como estudante, quero ler os anúncios dos clubes dos quais faço parte, para que eu esteja ciente das mudanças de horário.
• Como consultor, quero ler os comunicados dos clubes dos quais faço parte, para que eu esteja ciente das mudanças no cronograma.
• Como conselheiro, desejo enviar anúncios para os clubes dos quais faço parte, para que meus alunos estejam cientes das mudanças de horário
• Como administrador, desejo enviar comunicados a TODOS os clubes da escola para que eu possa informá-los sobre conflitos de agendamento.
• etc

Se assumirmos que essas são histórias de usuário bem escritas (que podem não ser), fico confuso quando minha equipe de desenvolvimento e eu nos sentamos para dividir esses itens em tarefas de desenvolvimento. Podemos cobrir partes de várias histórias de usuário com tarefas de desenvolvimento únicas. Por exemplo, temos uma ferramenta que gera ações CRUD para todas as camadas da interface do usuário ao DB simplesmente definindo as propriedades de um Anúncio. Portanto, as partes de várias histórias de usuário "enviar" e "ler" são concluídas em uma única etapa de desenvolvimento.

Pelo que li, cada história de usuário deve ser independente das outras e isso faz sentido. Mas cada uma de nossas histórias de usuário compartilha a tarefa "Gerar interface do usuário e banco de dados", porque é assim que criamos nossa interface do usuário de nível básico (antes de personalizá-la). Não devo escrever uma tarefa "Gerar interface do usuário e banco de dados" para cada história de usuário. Isso é muita redundância. Mas não sei como escrever uma tarefa "Gerar interface do usuário e banco de dados" que deve ser concluída antes que qualquer uma das histórias de usuário possa ser iniciada.

Eu tenho uma confusão semelhante com o nosso sistema de permissão. Temos diferentes tipos de conta, como Estudante, Orientador e Administrador, todos com acesso à página Anúncios, mas com funcionalidades diferentes dentro da página (eu capturei essa ideia com as Histórias de usuário acima). Podemos escrever o sistema de permissão para ser modular, para que possa ser usado para outros Recursos, mas não sei onde escrever a Tarefa para criar um "sistema de permissão modular".

Acho que toda essa história de usuário me confundiu. Sim, é ótimo para capturar a funcionalidade de um sistema, mas quando se trata de pensar nas tarefas de desenvolvimento, parece que não consigo entender. Qualquer conselho seria ótimo.

TL; DR: Algumas das programações que faço para uma história de usuário podem ser usadas em outras partes do nosso projeto para outras histórias de usuário (sistema de permissão, etc.). Como escrevo / organizo o Tasks for User Stories para ilustrar essa possibilidade?

Não devo escrever uma tarefa "Gerar interface do usuário e banco de dados" para cada história de usuário. Isso é muita redundância. Mas não sei como escrever uma tarefa "Gerar interface do usuário e banco de dados" que deve ser concluída antes que qualquer uma das histórias de usuário possa ser iniciada.

Você não fazer .

Você escreve suas histórias de usuário conforme as necessidades de alto nível - você chegou tão longe.

Então você escolhe a história do usuário (recurso) que você irá abordar primeiro. Neste ponto - dado o estado atual do produto - você decide a melhor forma de implementar esse recurso. Em seguida, você realiza o trabalho técnico mínimo necessário para implementar o recurso. Então você passa para a próxima história do usuário.

Isso pode funcionar da seguinte maneira:

• Nos sentamos para fazer a história 1 do usuário e identificamos que ela requer um banco de dados. Então, implementamos o banco de dados e depois o recurso.
• Nos sentamos para fazer a história 2 do usuário e identificamos que - ei - já temos o banco de dados, agora precisamos apenas estender a interface do usuário.

Ou no seu exemplo, pode até funcionar da seguinte maneira:

• Nos sentamos para implementar o envio de um anúncio. Criamos uma interface do usuário com uma caixa de texto e um botão de envio que faz uma postagem de formulário. Back-end, nada acontece. Legal. História do usuário concluída.
• Agora nos sentamos para implementar o recebimento de anúncios ... acho que é hora de começar a fazer algo com eles quando são enviados.

O objetivo desse processo é impedir que você tente projetar tudo de antemão e permitir que você tome decisões informadas sobre como implementar a próxima coisa, considerando o estado atual do software. Isso é diretamente incompatível com a tentativa de dividir todas as histórias em tarefas técnicas antes de iniciar qualquer uma delas.

Assim, você cria a solução apenas depois de captar a história e evolui seu design um recurso de cada vez. Você decide como (e até se) você documenta seu projeto técnico depois de começar a trabalhar em uma história.

Se dois desenvolvedores selecionam duas histórias ao mesmo tempo e compartilham requisitos técnicos, isso significa que você não pode executar essas tarefas em paralelo; portanto, escolha uma e faça com que o desenvolvedor faça outra coisa.

O objetivo aqui é implementar soluções simples e revisar seu design à medida que novos requisitos surgem.

E, mais importante, lembre-se: isso não é uma ciência .

Como você está inserindo cada sprint com uma lista priorizada de histórias, e cada história é dividida em tarefas técnicas separadas, todos os desenvolvedores devem trabalhar nas tarefas da história de maior prioridade antes de iniciar o trabalho na segunda história de maior prioridade. Por esse motivo, quando você começa a trabalhar na segunda história de prioridade, a tarefa 'Gerar interface do usuário e banco de dados' já deve ter sido concluída como parte da primeira história. Portanto, se durante o planejamento do sprint você descobrir que uma tarefa técnica está duplicada em várias histórias, atribua essa tarefa à história de maior prioridade para que seja concluída primeiro.

Se sua equipe tem o hábito de reorganizar as prioridades da história depois que o sprint é iniciado, você pode se beneficiar da inclusão de tarefas técnicas duplicadas em cada história e de fazer uma anotação sobre a tarefa que outras histórias o usam.

Pode ajudar a pensar no trabalho de uma lista de tarefas técnicas em vez de uma lista de histórias.