Suas histórias incluem tarefas entre disciplinas? Como você faz o planejamento de capacidade?

5

Minha organização faz projetos na web e emprega algumas disciplinas como backend dev, frontend, BA, UX, design gráfico, QA. Nós temos pressionado para ter tarefas para cada disciplina em nossos sprints com dependências explícitas (não é possível construir uma página sem composições, não pode fazer composições sem fios, etc). Eu ouvi que algumas outras organizações dizem que o scrum é apenas para tarefas dev. Estamos latindo na árvore errada? E, se não, existem boas ferramentas para fazer planejamento de capacidade quando apenas certos recursos podem realizar certas tarefas?

    
por jiggy 25.03.2013 / 18:15
fonte

3 respostas

3

Talvez.

Já corri agile com tudo antes. Algumas coisas (design gráfico, UX, BA) são melhor divididas em diferentes equipes e, até certo ponto, diferentes histórias de usuários. Então a dependência difícil pode ser resolvida antes você retirar a história dependente do backlog.

Para coisas como documentação ou controle de qualidade, essas são coisas que realmente precisam ser feitas com desenvolvimento. Eles não são dependências muito difíceis como tarefas relacionadas que devem ser concluídas antes que algo possa ser "feito".

    
por 25.03.2013 / 18:32
fonte
1

Esta é uma pergunta complicada. A questão é que você precisa de alguns dos artefatos (como você mencionou composições, quadros de fios) como entrada para as outras tarefas (desenvolvimento). Com base nisso, eu diria que estimar as tarefas de desenvolvimento é difícil de ser feito sem essa entrada, o que obviamente é algo que você deseja evitar.

Eu posso ver duas abordagens para ajudar com isso:

Histórias separadas

Trate as tarefas para obter as informações necessárias para o desenvolvimento como histórias separadas, por exemplo, tem uma história para "UI da tela da conta" e uma segunda para "Conta da tela", com uma dependência entre si. Em seguida, a equipe de interface do usuário pode trabalhar na primeira história do Sprint X, e a equipe de desenvolvimento pode trabalhar na segunda história no Sprint X + n, já que a história da interface do usuário está concluída.

Você pode ter problemas com isso devido à dependência, por exemplo, se não está claro que existe uma dependência.

Trabalho da interface do usuário fora do Sprint

Nesta abordagem, trabalhe nas tarefas da interface do usuário fora do Sprint de desenvolvimento. Você ainda trata o trabalho da interface do usuário como uma dependência para o desenvolvimento, mas a equipe da interface do usuário não funciona como parte da equipe de desenvolvimento e não dentro do mesmo Sprint.

É assim que estamos trabalhando atualmente, já que temos algumas das mesmas dependências. Criamos uma Definição de Pronto , que define as informações que precisam estar disponíveis para que uma matéria seja considerada pronta , ou seja, pode ser transferida para o desenvolvimento. Uma parte nesta Definição de Pronto é que todas as histórias da interface do usuário têm modelos, capturas de tela ou wireframes anexados a elas. Como parte do Story Grooming, trabalhamos com a equipe de interface do usuário para percorrer as histórias, e eles criam modelos, etc. Uma vez que estes estão lá e a história tem critérios de aceitação, pode ser estimado (Planning Poker). Feito isso, está pronto .

Nesse modelo, o trabalho de preparação ou de interface do usuário também pode ser feito de maneira ágil, onde a equipe de preparação e / ou de interface do usuário está usando um processo ágil. Pode ser o Scrum, ou também o Kanban, que pode ser mais adequado para esse tipo de trabalho.

    
por 04.04.2013 / 10:51
fonte
1

Eu manteria suas equipes interdisciplinares. Se uma equipe é muito grande, eu dividiria o projeto em equipes Scrum separadas, com cada equipe sendo interdisciplinada. (Em um impulso, as pessoas podem dividir seus esforços em duas ou mais equipes, se necessário; você só precisa levar isso em conta ao estimar a velocidade.) Dividir equipes e histórias em design / prototipagem / desenvolvimento etc é contraproducente, acho , por razões que dei no comentário para @nwinkler: você só deve criar histórias que agreguem valor ao cliente.

Kanban ou Scrumban são boas abordagens que podem ajudá-lo a pensar nas dependências. Se você controlar criteriosamente seus limites de WIP, eles permitirão que você crie wireframes antes que o desenvolvimento ocorra, sem reduzir o tempo de retorno total de um recurso. Achei isso especialmente útil se as pessoas precisarem usar "chapéus" diferentes: por ex. se a coluna "teste" atingir seu limite de WIP, um BA ou um colaborador poderia colocar o chapéu de teste no dia.

    
por 04.04.2013 / 11:14
fonte

Tags