Seleção de recursos (Planejamento de sprint – parte um)
Muitas equipes definem um objetivo geral para a iteração para orientar a seleção de funcionalidades. No início da reunião, as funcionalidades de maior prioridade são normalmente selecionadas a partir do plano de lançamento. Se a iteração tiver um objetivo abrangente, algumas funcionalidades de menor prioridade podem ser selecionadas se estiverem mais alinhadas a esse objetivo. A velocidade de desenvolvimento anterior é crucial para permitir que a equipe planeje uma quantidade realista de trabalho.
Por exemplo, se a equipe planejou entregar funcionalidades do produto equivalentes a 40 pontos de história, mas entregou apenas 30, então esses 30 pontos de história devem ser considerados a velocidade atual para a próxima iteração. Comparar estimativas de velocidade anteriores com números reais é útil nos níveis de iteração, funcionalidade e tarefa. Tudo isso ajuda a equipe a determinar o quanto pode se comprometer na próxima iteração. Se a iteração estiver sobrecarregada, o cliente precisa selecionar quais funcionalidades devem ser adiadas para uma iteração futura. Durante o planejamento de iteração Na reunião, o cliente discutirá as funcionalidades com a equipe e tentará responder a quaisquer perguntas que a equipe tenha.
Planejamento de tarefas (Planejamento de sprint – parte dois)
A equipe irá dividir as funcionalidades em tarefas. Os desenvolvedores, então, se inscrevem nas tarefas e fazem suas estimativas. As tarefas geralmente variam de quatro horas a dois dias, sendo que a maioria pode ser concluída em um dia. Tarefas com duração superior a dois dias geralmente devem ser divididas em tarefas menores. Ocasionalmente, durante o planejamento das tarefas, percebe-se que uma funcionalidade foi subestimada significativamente na estimativa inicial. plano de lançamentoNesse caso, a equipe precisará trabalhar com o cliente para fornecer uma estimativa corrigida e determinar qual ou quais recursos podem precisar ser adiados como resultado.
Ajustes de iteração
Durante a iteração, se houver tempo disponível após a entrega de todas as funcionalidades, a equipe pode solicitar ao cliente que identifique funcionalidades adicionais para serem incluídas na iteração. Se, por outro lado, for evidente que nem todas as funcionalidades podem ser entregues, a equipe trabalha com o cliente para determinar quais funcionalidades podem ser adiadas ou divididas, a fim de maximizar o valor entregue dentro do prazo da iteração.
Sinais de aviso
- Se, ao longo de várias iterações, a equipe continuar adiando o lançamento de funcionalidades para o futuro, isso indica que ela deve prestar mais atenção à sua velocidade anterior, a fim de minimizar o excesso de projetos e maximizar a precisão do planejamento.
- Se a equipe continuar priorizando as mesmas funcionalidades a cada iteração, isso pode ser um sinal de que ela está evitando propositalmente certas funcionalidades, e as causas principais devem ser investigadas.
- Se a equipe estiver se aprofundando demais em detalhes e projetando cada funcionalidade por completo, pode haver uma oportunidade para aumentar o foco na identificação das tarefas realmente necessárias.
Perguntas
Como lidamos com as dependências entre tarefas?
Essa pergunta surge com bastante frequência. Como parte do planejamento da iteração, a equipe deve se esforçar para minimizar as dependências entre as tarefas ao dividir as funcionalidades. Técnicas específicas podem ser encontradas no excelente livro de Mike Cohn. Histórias de usuários aplicadasEm seguida, a equipe deve se esforçar para colaborar a fim de minimizar os efeitos das dependências inevitáveis. Equipes Agile geralmente adotam designs simples, com baixo acoplamento e adaptáveis, que minimizam as dependências. Um excelente recurso para conceber e refinar essas arquiteturas é o livro seminal de Bob Martin. Desenvolvimento Agile de Software: Princípios, Padrões e PráticasAs equipes Agile também utilizam técnicas, ferramentas e práticas que lhes permitem trabalhar simultaneamente em subsistemas e módulos interdependentes. Desenvolvimento orientado a testesFerramentas de teste automatizadas e objetos simulados ajudam as equipes a minimizar e lidar com as interdependências entre tarefas. A colaboração contínua e próxima pode ser fundamental nesse processo; equipes que trabalham no mesmo local acham mais fácil resolver os desafios de dependência em conjunto ao longo da iteração, de forma oportuna.
As iterações têm duração limitada, reduzindo o risco de que uma única dependência oculta comprometa o projeto. Diagramas PERT e CPM, embora potencialmente valiosos para a compreensão geral do sistema, tendem a falhar sob a pressão do desenvolvimento de software iterativo e de alta velocidade. O tempo e o esforço adicionais gastos na construção de um modelo de dependências para uma iteração de duas semanas raramente compensam. Testes automatizados e código automatizado fornecerão feedback mais preciso e executável, pelo menos na mesma velocidade.
Qual o valor da contribuição que um membro da equipe deve pagar?
Um membro da equipe raramente deve se comprometer com mais tarefas do que o total estimado para as que conseguiu concluir na iteração anterior. Se as tarefas não forem definidas durante o planejamento da iteração, a ênfase passa a ser garantir que a equipe não assuma trabalho em excesso, comparando a velocidade de desenvolvimento de funcionalidades e tarefas com a da iteração anterior.
Como planejar as iterações se o tamanho da equipe variar?
Sem a capacidade de contar com um esforço consistente da equipe, nenhuma abordagem de projeto, ágil ou não, oferece muita informação. Com o desenvolvimento iterativo de software, no entanto, pelo menos normalmente existe um histórico construído ao longo do tempo que serve como base para o planejamento. No desenvolvimento iterativo, se você entregou várias iterações com uma equipe de dez pessoas, com uma velocidade média de 20 dias ideais ou 200 horas por iteração, e sua equipe é reduzida pela metade, um cálculo simples deve levar você a planejar no máximo dez dias ideais para a próxima iteração (pelo menos inicialmente). Se membros-chave da equipe forem removidos, ou se você perceber que está errado, descobrirá isso nas próximas semanas e poderá se ajustar rapidamente para as iterações futuras.
Como você contabiliza as despesas gerais (reuniões, e-mails, etc.)?
Em geral, as equipes não dedicam muito tempo ao rastreamento de itens indiretos menores. Ao longo de algumas iterações, essas interrupções se refletem em velocidades reais cada vez mais consistentes (ainda que inesperadas). Algumas equipes incorporam interrupções e perturbações maiores em seus planos de iteração explicitamente, para reduzir riscos e aumentar a visibilidade.
Como você leva em consideração a correção de bugs durante o planejamento da iteração?
Existem algumas maneiras pelas quais as equipes lidam com a correção de bugs. Uma das mais simples é incluir os bugs como entrada explícita no planejamento da iteração, priorizando-os e estimando as tarefas envolvidas. Bugs e funcionalidades são essencialmente unidades de trabalho equivalentes para fins de planejamento. Algumas equipes optam por rastrear os bugs separadamente, fora do processo de iteração. Isso é um pouco mais arriscado: se o esforço de correção de bugs variar entre as iterações, a velocidade da equipe também variará, afetando as estimativas e os planos. Mas se o esforço de correção de bugs for mantido constante, esse método pode funcionar razoavelmente bem.
Por que as iterações devem sempre ter o mesmo comprimento?
Iterações com durações iguais ou muito próximas proporcionam um ritmo essencial para as equipes em suas estimativas e planejamento. Sem iterações de duração fixa, pode ser difícil alcançar e mensurar uma velocidade constante. A disciplina de interromper a produção ao final de cada iteração concentra a atenção de todos, pressionando a equipe a manter os projetos simples e a resistir a excessos ou ao aumento descontrolado do escopo. Toda a organização se acostuma rapidamente a um fluxo constante de entrada de dados, planejamento, execução, produção e retrospectiva. Sem esse ritmo, a equipe se torna menos eficiente. Ocasionalmente, haverá bons motivos para estender ou comprimir iterações específicas, para adequá-las a prazos, grandes interrupções ou feriados. Mas essas devem ser a exceção, não a regra.
Como devo contabilizar o tempo de teste e documentação?
Os testes e as atualizações de documentação devem ser priorizados, estimados e planejados da mesma forma que qualquer outra atividade importante que exija tempo do desenvolvedor. Frequentemente, são criados como tarefas vinculadas a funcionalidades específicas, mas também podem ser agrupados como uma funcionalidade independente.
As estimativas de funcionalidades devem ser revisadas durante o planejamento da iteração?
As estimativas de funcionalidades só devem ser revisadas durante o planejamento da iteração se a estimativa original se mostrar muito imprecisa e o novo nível de esforço tiver um impacto significativo na capacidade da equipe de concluir outras tarefas.
As estimativas de tarefas devem ser revisadas durante uma iteração?
A estimativa inicial da tarefa não deve ser revisada após a conclusão do planejamento da iteração. Por outro lado, as estimativas para iterações futuras devem ser revisadas continuamente para refletir uma avaliação precisa do trabalho restante.
Todas as equipes devem operar com o mesmo cronograma de iterações?
Há vantagens em ter todas as equipes trabalhando no mesmo cronograma de iterações. Consolidar o status das iterações entre as equipes só faz sentido se elas estiverem no mesmo cronograma. Não é útil consolidar o status numérico de uma equipe que está apenas começando sua iteração junto com outra que está prestes a terminar. A desvantagem de ter todas as equipes no mesmo cronograma de iterações reside no fato de que as iterações começam e terminam simultaneamente. Se recursos comuns (como um cliente ou a gerência) forem compartilhados entre os projetos, eles podem preferir um cronograma de iterações escalonado entre as equipes.
