Reduzir escopo não é pecado

Estávamos atrasados. O time se comprometeu com um conjunto de funcionalidades e não atingimos nossa meta. Ainda podia ficar pior. Priorizamos errado e demos mais atenção a funcionalidades de menos importância. Precisávamos urgentemente mudar o rumo para atender às expectativas.

Estávamos trabalhando em uma tarefa e sua funcionalidade foi concluída. Faltava somente colocar algumas informações que poderiam ajudar o usuário a utilizá-la. Não era algo vital. Procurávamos os melhores ícones para as explicações ficarem mais simpáticas. Mas, o problema era um pouco maior. Nos apegamos a detalhes de uma tarefa de baixa prioridade enquanto uma funcionalidade importante ainda não havia sido acabada.

O Sprint havia estourado. Erramos na priorização e nos deixamos levar por detalhes minúsculos. Ao ser informado do erro que havíamos cometido mudamos os esforços da equipe para poder finalizar a tarefa de maior prioridade. Surgiu porém uma dúvida: como fica a tarefa de menor prioridade? Teoricamente ela estava incompleta.

Desenvolvimento de software é um processo complexo, não definido. Para gerenciar tal tipo de processo é necessário utilizar processos empíricos de controle¹. A adaptabilidade é uma das grandes ferramentas para poder se modelar ao caos emergente no processo de criação de um sistema.

Schwaber e Beedle¹ defendem que o time tem autoridade para mudar a funcionalidade do Sprint ao passo que a mudança alcance a meta do mesmo. Primeiro é necessário descobrir qual é o mínimo mais simples que atenda a demanda². Depois aprender a reduzir o escopo para atender esse mínimo quando o Sprint está em jogo.

Não entregar tudo o que foi planejado para uma tarefa não indica que a mesma não está pronta para produção. É assim que se pensa ao utilizar metodologias ágeis. As funcionalidades são incrementais. O desenvolvimento é evolutivo. No primeiro Sprint entregamos uma parte funcional que atenda a necessidade, em seguida melhoramos esta funcionalidade.

Mudamos o escopo da funcionalidade. Ela irá ao ar sem alguns detalhes que pensamos inicialmente, mas atenderá à necessidade. Haverão melhoras na mesma num Sprint posterior. A tarefa de maior prioridade está sendo terminada e será entregue no próximo release.

Sempre que for necessário altere o escopo de uma funcionalidade em prol da meta estabelecida.

E sempre fique atento à correta priorização das tarefas.