Seleção de recursos (planejamento do sprint – primeira parte)
Muitas equipes definem uma meta geral para a iteração para ajudar a orientar a seleção de recursos. No início da reunião, os recursos de maior prioridade são normalmente selecionados no release plano. Se a iteração tiver um objetivo abrangente, alguns recursos de prioridade mais baixa podem ser selecionados se estiverem mais alinhados com o objetivo. A velocidade prévia é crítica para permitir que a equipe agende uma quantidade realista de trabalho.
Por exemplo, se a equipe planejou anteriormente obter 40 pontos de história em recursos do produto, mas entregou com sucesso apenas 30 pontos de história, então 30 pontos de história devem ser considerados a velocidade atual para a próxima iteração. As estimativas de velocidade anteriores comparadas aos números reais são úteis no nível de iteração, no nível do recurso e no nível da tarefa. Tudo isso ajuda a equipe a determinar quanto pode se inscrever na próxima iteração. Se a iteração estiver lotada, o cliente precisará selecionar quais recursos precisam ser adiados para uma iteração futura. Durante a reunião de planejamento da iteração, o cliente discutirá os recursos com a equipe e tentará responder a quaisquer perguntas da equipe.
Planejamento de tarefas (planejamento do sprint – parte dois)
A equipe dividirá os recursos em tarefas. Os desenvolvedores então se inscrevem para tarefas e as estimam. As tarefas geralmente variam em tamanho de quatro horas a dois dias, com a maioria das tarefas podendo ser entregues em um dia. Tarefas maiores que dois dias geralmente devem ser divididas em tarefas menores. Ocasionalmente, durante o planejamento da tarefa, determina-se que um recurso foi terrivelmente subestimado no original release plano. Nesse caso, a equipe precisará trabalhar com o cliente para fornecer uma estimativa corrigida e determinar qual recurso ou recursos podem precisar ser adiados como resultado.
Ajustes de iteração
Durante a iteração, se houver tempo restante após a entrega de todos os recursos, a equipe pode solicitar que o cliente identifique recursos adicionais para adicionar à iteração. Se, por outro lado, for óbvio que nem todos os recursos podem ser entregues, a equipe trabalhará com o cliente para determinar quais recursos podem ser adiados ou talvez divididos para entregar o maior valor dentro do prazo de iteração.
Sinais de aviso
- Se durante uma série de iterações a equipe continuar a lançar recursos para o futuro, é um sinal de que a equipe deve prestar mais atenção à sua velocidade anterior para minimizar o overbooking contínuo e maximizar a precisão do planejamento.
- Se a equipe continuar avançando com os mesmos recursos a cada iteração, pode ser um sinal de que a equipe está evitando propositadamente certas funcionalidades e as causas principais devem ser exploradas.
- Se a equipe estiver mergulhando em muitos detalhes e projetando cada recurso por completo, pode haver uma oportunidade para aumentar o foco na identificação do trabalho de tarefa necessário.
Perguntas Frequentes:
Como lidamos com as dependências entre as tarefas?
Esta questão surge um pouco. Como parte do planejamento da iteração, a equipe deve se esforçar para minimizar as dependências de tarefas à medida que dividem os recursos. Técnicas específicas abundam no excelente livro de Mike Cohn Histórias de usuários aplicadas. Em seguida, a equipe deve se esforçar para colaborar para minimizar os efeitos de dependências inevitáveis. As equipes Agile geralmente adotam designs simples, flexíveis e adaptáveis que minimizam as dependências. Um excelente recurso para conceber e refinar tais arquiteturas é o livro seminal de Bob Martin Desenvolvimento Agile de Software: Princípios, Padrões e Práticas. As equipes Agile também usam técnicas, ferramentas e práticas que lhes permitem trabalhar simultaneamente em subsistemas e módulos interdependentes. Desenvolvimento orientado a testes, arreios de teste automatizado e objetos fictícios ajudam as equipes a minimizar e lidar com interdependências de tarefas. A colaboração contínua e próxima pode ser fundamental aqui; equipes co-localizadas acham mais fácil resolver os desafios de dependência juntos durante a iteração de maneira just-in-time.
As iterações são tão longas, reduzindo o risco de que uma única dependência oculta elimine o projeto. Gráficos PERT e CPM, embora potencialmente valiosos em termos de compreensão geral do sistema, têm uma tendência muito alta de desmoronar sob o estresse do desenvolvimento de software iterativo e de alta velocidade. O tempo e o esforço adicionais gastos para criar um modelo de dependência para uma iteração de duas semanas raramente valem a pena. Testes e códigos automatizados fornecerão feedback mais preciso e executável pelo menos com a mesma rapidez.
Por quanto um membro da equipe deve se inscrever?
Um membro da equipe raramente deve se inscrever para mais do que a estimativa total das tarefas que conseguiu concluir na iteração anterior. Se as tarefas não estiverem sendo inscritas durante o planejamento da iteração, será dada mais ênfase para garantir que a equipe não se inscreve para muito trabalho comparando com o recurso e a velocidade da tarefa da iteração anterior.
Como você planeja iterações se o tamanho da equipe varia?
Sem a capacidade de contar com o esforço consistente da equipe, nenhuma abordagem de projeto, ágil ou não, oferece muito insight. No entanto, com o desenvolvimento iterativo de software, pelo menos normalmente há algum histórico que é construído ao longo do tempo para ser usado como base para o planejamento. Com desenvolvimento iterativo, se você entregou várias iterações com uma equipe de dez com uma velocidade média de 20 dias ideais ou 200 horas por iteração e sua equipe foi cortada pela metade, um cálculo simples deve levar você a planejar não mais do que dez dias ideais para a próxima iteração (pelo menos inicialmente). Se o pessoal-chave foi removido, ou você acha que está errado, você descobrirá nas próximas semanas e poderá ajustar rapidamente para futuras iterações.
Como você contabiliza as despesas gerais (reuniões, e-mail, etc.)?
As equipes geralmente não gastam muito tempo rastreando itens indiretos menores. Ao longo de algumas iterações, essas interrupções são refletidas em valores reais de velocidade cada vez mais consistentes (embora inesperados). Algumas equipes incorporam interrupções e interrupções maiores em seus planos de iteração explicitamente, para reduzir o risco e aumentar a visibilidade.
Como você explica 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 bugs como entrada explícita para o planejamento da iteração, priorizando-o e estimando as tarefas envolvidas. Bugs e recursos são unidades de trabalho essencialmente equivalentes para fins de planejamento. Algumas equipes optam por rastrear bugs separadamente fora de seu processo de iteração. Isso é um pouco mais arriscado: se o esforço de correção de bugs varia entre as iterações, a velocidade da equipe varia de acordo, descartando estimativas e 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 ter sempre o mesmo comprimento?
As iterações com comprimentos iguais ou muito próximos fornecem um ritmo no qual as equipes confiam para estimativas e planejamento. Sem iterações de comprimento fixo, pode ser difícil alcançar e medir a velocidade constante. A disciplina de cortar a produção no final de uma iteração concentra as mentes de todos, aplicando pressão para manter os designs simples e resistir ao revestimento de ouro ou aumento do escopo. A organização inteira rapidamente se acostuma a um zumbido constante de entrada, planejamento, execução, saída e retrospecção. Sem esse ritmo, a equipe é menos eficiente. Ocasionalmente, haverá boas razões para estender ou comprimir iterações específicas, para ajustá-las a prazos, grandes interrupções ou feriados. Mas estes devem ser a exceção, não a regra.
Como contabilizar o tempo de teste e documentação?
As atualizações de teste e documentação devem ser priorizadas, estimadas e planejadas como qualquer outra atividade importante que requer o tempo de um desenvolvedor. Eles geralmente são criados como tarefas em recursos específicos, mas também podem ser agrupados como seu próprio recurso.
As estimativas de recursos devem ser revisadas durante o planejamento da iteração?
As estimativas de recursos só devem ser revisadas durante o planejamento da iteração se a estimativa original estiver muito errada e o novo nível de esforço tiver um impacto significativo na capacidade da equipe de concluir outro trabalho.
As estimativas de tarefas devem ser revisadas durante uma iteração?
A estimativa da tarefa original 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 no mesmo cronograma de iteração?
Há vantagens em ter todas as equipes trabalhando no mesmo cronograma de iteração. O acúmulo de status de iteração entre as equipes só é significativo se as equipes estiverem no mesmo cronograma. Não é útil acumular nenhum status numérico em 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ção está em iniciar e encerrar as iterações ao mesmo tempo. Se recursos comuns (por exemplo, um cliente ou gerenciamento) forem compartilhados entre projetos, eles podem apreciar um cronograma de iteração escalonado entre as equipes.
