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.
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.
Desenvolvimento evolutivo
by Fabio Santos,
Re: Desenvolvimento evolutivo
by Sergio Vellozo,
Desenvolvimento evolutivo
by Fabio Santos,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
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,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
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.