BT

Precisamos mesmo da iteração zero?

por Vikas Hazrati , traduzido por Fernando Ultremare em 08 Jul 2011 |

Existem geralmente diversas atividades que precisam ser realizadas antes do início de um projeto, para que então se passe a atividades que agregam valor de negócio para os clientes. Com esse objetivo, as equipes ágeis muitas vezes utilizam uma iteração inicial, conhecida como iteração ou sprint zero. Mas seria a maneira mais adequada?

George Dinwiddie explica que, por mais que as equipes tentem realizar todo o trabalho preliminar no sprint zero, perceberão que ainda restam muitas atividades desse tipo a serem executadas nos próximos sprints. Além disso, ao antecipar muitas tarefas, corre-se o risco de que as decisões estruturais, tecnológicas e funcionais definidas no sprint zero passem a determinar a direção geral do projeto.

Dwinwiddie recomenda que toda iteração necessariamente produza software funcional:

Pergunte-se o que é necessário para realizar uma primeira entrega. Divida esse trabalho em fatias ou fluxos menores e defina os exemplos que representam a aceitação desses fluxos. Caso tenha dúvidas que não possam ser sanadas em algum fluxo, deixe-o de lado por enquanto. Em seguida escolha o fluxo principal, que percorra o conceito do negócio do início ao fim (ou o mais próximo disso possível). Estime esse fluxo como a primeira iteração da equipe, sempre lembrando que as estimativas não precisam ser exatas, pois são apenas estimativas. Então comece a construir esse fluxo.

De acordo com Dinwiddie, essa é a melhor maneira para se começar. A equipe deve adquirir as habilidades necessárias sobre as tecnologias e construir gradualmente a infraestrutura do projeto, ao mesmo tempo em que desenvolve as funcionalidades de negócio.

Ainda restará trabalho de infraestrutura a ser feito, mas não há porque apressar-se nessa atividade. Apenas continue evoluindo a infraestrutura na medida em que isso aumente sua capacidade de entrega. Da mesma maneira, ainda restarão habilidades técnicas a serem desenvolvidas. Mantenha-se sempre experimentando e testando novas possibilidades técnicas. Por fim, ainda restarão funcionalidades a serem adicionadas ao backlog, refinadas, priorizadas, divididas em histórias e priorizadas novamente. Essa será a dinâmica ao longo de todo o projeto.

Na mesma linha, Artem Marchenko não recomenda a existência de uma iteração em que nada possa ser apresentado. Mesmo que, inevitavelmente, grande parte do trabalho da iteração zero seja realizado em atividades preliminares, Marchenko também acredita ser necessário validar o fluxo principal do sistema de ponta a ponta.

Alistair Cockburn opina,

Tenho a sensação de que alguém foi questionado sobre sua aplicação do Scrum ao realizar alguma atividade inicial sem valor de negócio aparente, e inventou “Isso foi o sprint zero!”, para livrar-se de pressões. Muitos consideraram esta uma boa resposta e passaram a utilizá-la... e isso se tornou parte da cultura.

Questionado sobre a equivalência entre a iteração zero e um planejamento inicial excessivo, George Dinwiddie afirma não acreditar em uma iteração zero sem que isso ocorra. Por outro lado, sugere a necessidade de aprofundamento da equipe na visão e nos objetivos gerais do projeto, o que não ocorre na maioria das vezes. Na prática, as principais atividades realizadas nessa etapa são o detalhamento do backlog e a criação da infraestrutura técnica do sistema.

De maneira similar, Ken Schwaber diz,

“Sprint zero” se tornou uma expressão mal usada para descrever o planejamento que ocorre antes do primeiro sprint. Uma vez que o planejamento geralmente produz artefatos que são alterados com frequência, essa atividade deve ser minimizada no início e depois ocorrer a cada reunião de revisão e de planejamento de sprint (constituindo o planejamento just-in-time)

Parece, portanto, haver um consenso de que é melhor evitar o sprint zero, sempre que possível, e de que o grande benefício está em agregar valor ao negócio desde o início.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Desenvolvimento evolutivo by Fabio Santos

O problema, para mim, não é o Sprint Zero ou Iteração Inicial. Este é apenas uma sintoma de um problema maior, que é a dificuldade de evoluirmos a arquitetura / modelagem de um sistema. Esta dificuldade se tornou muito mais evidente quando nos tornamos ágeis, pois colocamos software em produção muito cedo. E isso torna ainda mais difícil as mudanças (scripts de migração, etc).

Neste sentido, o Sprint Zero é uma tentativa de mitigar este problema, começando um projeto sem ser ágil para depois se tornar ágil. O problema é que não adianta não atacar o problema do desenvolvimento evolutivo e esta solução (o Sprint Zero) é apenas paliativa. Precisamos aprender e desenvolver técnicas que realmente nos permitam fazer o desenvolvimento evolutivo, entendendo as questões que isto trará para o andamento dos projetos e para as decisões que precisarão ser tomadas.

Mas não sejamos inocentes. Um dos grandes mitos do desenvolvimento evolutivo é que sempre é possível dar pequenos passos para continuar andando para frente. Só que esta premissa, pela minha experiência, é falsa. O desenvolvimento evolutivo não garante que a equipe não tome decisões que levem para um caminho sem saída, sendo necessário, de tempos em tempos, grandes refactorings para possibilitar a adição de pequenas funcionalidades. Isto gera insegurança nos gestores e esta insegurança é manifestada na necessidade de realização um planejamento maior no início do projeto.

Este medo, no entanto, não me parece justificado. Conheço projetos de sucesso que foram inteiramente reimplementados pelo menos 3 vezes, e o cliente sempre esteve satisfeito.

Re: Desenvolvimento evolutivo by Sergio Vellozo

Bem colocado. Quando se anda por um terreno desconhecido, olhamos para o chão a cada passo mas tambem olhamos para meta e ao redor a cada passo. Só olhar para o chão não basta.Entendo do jeito que o Ken Schwaber fala.É ingenuidade pensar que basta construir as histórias de um backlog na ordem que o PO coloca para se construir um sistema. Ocorre que para uma equipe com alta senioridade os cuidados são tomados naturalmente e sem muito custo.Mas não é sempre assim e os prejuizos podem ser bem grandes. Não basta fazer todas as cerimonias e usar as técnicas como TDD ou pair programming para garantir que sai um produto de qualidade. Há mais em fazer software que estas coisas.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT