Um bom time de Scrum tem que estar preparado para que qualquer sprint possa ser a última sprint do projeto.
É claro que o anúncio repentino de que a sprint atual será a última, certamente causa efeitos, pois as pessoas estão tão sintonizadas com o projeto/produto que gostariam de continuar trabalhando nele e ver mais coisas funcionando. Porém, não se pode ter lamentos do tipo: “poxa aquele framework que estamos desenvolvendo não serviu para nada” ou “deixamos tudo preparado para novas demandas que nem vão acontecer”. Se esses lamentos aparecem, é sinal de BDUF (Big Design Up Front).
Evite o BDUF
Com métodos ágeis, queremos evitar o BDUF, pois acreditamos no design emergente. É claro que as grandes decisões arquiteturais foram tomadas no início: linguagens; orientação a serviço ou não; web ou app etc… Já os detalhes devem ser decididos mais tardiamente, a medida que o projeto avança e as necessidades vão surgindo.
Ao evitar o BDUF temos várias vantagens:
- Antecipamos entrega com foco no negócio
- Melhor conhecimento do cenário para tomar uma decisão arquitetural
- Ciclo mais curto de feedback entre criação e uso
- Menor o risco de criarmos algo que nunca será usado (alguém já viu isso?)
- Orientação a resultado
Priorização é Tudo
A cada planejamento de sprint, todos deveriam se questionar:
“Se essa fosse a última sprint do mundo, o que entregaríamos?”
Nesse caso, não faz sentido entregar uma biblioteca, ou um POC (Proof Of Concept), ou uma camada de acesso aos dados, ou design detalhado do produto ainda não funcional.
Temos que entregar algo que agregue valor!
Mas em que momento criamos uma biblioteca ou uma nova camada de acesso aos dados?
Isso deve acontecer progressivamente, essa biblioteca ou camada deve ser criada a medida em que ela for sendo necessária.
E se quisermos fazer uma grande alteração arquitetural no projeto, o que fazer?
Faça uma transição suave. Já tratamos desse assunto em outro post: “Nova Versão do Sistema”
Uma boa priorização deve ser principalmente baseada em decisões de negócio.
É responsabilidade do time criar um design emergente coerente (a prática de refactoring deve ser estimulada para se manter a qualidade interna), mas com orientação a resultado de negócio.
Orientação a Resultado de Negócio
Em nossos clientes, muitos já abraçaram a agilidade: processo iterativo, melhoria contínua, gestão visual etc… Porém, ainda encontramos alguns exemplos de esforço não orientado a resultado, por exemplo: criação de framework que não está visível para o negócio há quase um ano, design que não é colocado à prova por meses etc…
P.O., time, ScrumMaster e líderes em geral, lembrem-se de se perguntar a cada planejamento:
“Se essa fosse a última sprint do mundo, o que entregaríamos?”
