Durante muito tempo, grande parte dos softwares produzidos (e muitos outros produtos) utilizavam um modelo em cascata, onde cada processo, quando terminado, dava inicio a um novo processo, mantendo o fluxo do desenvolvimento contínuo e em uma única direção. Um exemplo seria: Levantamento -> Planejamento -> Desenvolvimento -> Testes -> Implantação -> Utilização.
Como o modelo é contínuo e em uma única direção, o feedback do que é construido se torna muito lento, sendo, em casos, entregue só quando fluxo é completo. Apesar da previsibilidade do ponto de vista gerencial, é muito facil construir a “coisa errada”. A passagem por esses processos não é rapida o suficiente para acompanhar a evolução do mercado ou mudanças dentro do cliente.
A ideia de desenvolvimento iterativo tem como objetivo central encurtar o ciclo de feedback. Ao inves de entregarmos uma única vez todo o produto, entregamos partes dele de cada vez, podendo receber um feedback em cada entrega e validando o que foi desenvolvimento. Dessa maneira, se torna mais facil uma alteração e o acompanhamento das necessidades do cliente conforme o software é construido.
Um conceito muito comum atualmente, e popularizado pelo Facebook é o de “falhar cedo”, ou seja, se for pra errar, que seja rápido e com algo facil de ser substituído. A teoria é sim, muito bonita, e faz todo sentido: podemos validar o que é construido enquanto construímos e podemos mudar de direção caso necessário.
Na prática isso passa a ser um pouco mais complexo. Muitos desenvolvedores, gerentes, e profissionais de TI, acabam por entender que um ciclo de feedback curto é o melhor caminho e passam a encurtar cada vez mais as iterações. Nesse processo podemos perder o que realmente é o sentido de tudo isso: a entrega de valor ao cliente. Quando encurtamos muito o ciclo, se torna muito dificil entregar algo de real valor, já que o tempo é muito curto para que a equipe desenvolva algo que posso ser útil ao cliente.
Mas qual o tamanho ideal da iteração? É ai que o conceito de “Always done” se encaixa. O objetivo é, ainda entregar o software de maneira iterativa e incremental, porém, cada iteração DEVE entregar uma solução real, resolvendo ao menos o problema central. O exemplo mais comum (e citado no livro [1]) é o do transporte: O cliente vai andando para o trabalho todo dia, porém, isso toma muito tempo e energia. O nosso objetivo é facilitar a ida e volta do cliente para o trabalho.
Iniciamos o projeto, discutimos algumas ideias e rapidamente desenvolvemos uma tabua de madeira com 4 rodas que pode resolver o problema do cliente, mesmo que apenas de maneira parcial. O batizamos de “skate” e entregamos. O cliente utiliza, gosta da solução mas tem alguns problemas: ainda demanda certo esforço nas subidas, ter de ficar em pé, equilibrio e falta de segurança, já que é muito facil cair.
Vamos para a próxima iteração, trabalhando nos problemas que o cliente nos relatou na ultima iteração. Mesmo levando um pouco mais de tempo do que a primeira iteração, desenvolvemos um novo produto, com duas rodas, um banco. O que chamamos de “bicicleta”. Fazemos a entrega e logo o cliente nos retorna: o esforço diminuiu consideravelmente, não é mais necessário ficar em pé, é muito mais facil manter o equilibrio, porém, ainda demanda esforço físico e o cliente chega ao trabalho todo dia coberto de suor.
Na terceira iteração, decidimos aprimorar apenas um pouco a ultima ideia e adicionamos um motor na bicicleta, a transformando em uma “motocicleta”. Nosso cliente fica muito feliz com a entrega e não possui nenhuma reclamação. Até que um belo dia, chove muito no horário em que ele deveria ir ao trabalho. E agora?
Já com experiencia no assunto e embalados pelo sucesso anterior, logo bolamos um plano, que demora um pouco a ser construído mas resolverá o problema. Por fim, entregamos um “carro” ao cliente, e recebendo um feedback positivo, finalizamos o projeto.
Nessa pequena história, alguns pontos são importantes:
- Em todas as iterações, o problema central foi resolvido, mesmo que de forma não otimizada;
- Nenhuma das iterações, necessáriamente, teve o mesmo tempo;
- Cada iteração não inicia o projeto do 0, mas trabalha de acordo com o feedback recebido, resolvendo os problemas encontrados na iteração anterior.
Sprints
Em SCRUM temos o conceito de “sprints”, onde definimos um período fixo de tempo em que o ciclo de desenvolvimento deve acontecer, incluindo as cerimonias caracteristicas como planning e review. Os sprints também são uma forma de desenvolvimento iterativo. Ao final de cada sprint, uma entrega é feita, e o produto validado pelo cliente (PO). Porém, o grande valor dos sprints vem da criação da previsibilidade, do controle e a definição de uma cadência. Os sprints são melhor utilizados “da porta para dentro”, como uma ferramenta de organização interna e o funcionamento das equipes. Já o desenvolvimento iterativo “always done” é melhor “da porta pra fora”. É possivel utilizar sprints e entregas iterativas e incrementais de maneira conjunta, sendo cada um no seu ponto forte.
MVP
O conceito de MVP (Minimum Viable Product), segue a risca o conceito de “falhar cedo”, onde é construido o mínimo necessário para que a idéia do projeto possa ser testada, possibilitando a adequação do planejamento e os “pivots” (mudanças na direção do produto). Os MVPs são utilizados de maneira estratégica, principalmente no desenvolvimento de novos produtos e conceitos, onde o mercado e até o próprio resultado ainda é bastante incerto. O grande segredo é saber quando usar. Nem todos os projetos precisam dessa validação de conceito. Grande parte dos projetos vem de uma “dor existente” do cliente, onde, muitas vezes, o “como resolver” é proposto pelo próprio cliente. Nesses casos, MVPs causam mais problemas do que soluções. Porém, ainda assim, o projeto pode se beneficiar de um processo iterativo e incremental, principalmente se seguirmos o conceito de “always done”.
O que usar
Como toda e qualquer escolha dentro do desenvolvimento de software, vai do feeling e das preferencias da equipe.
“There are no solutions, only tradeoffs” – Paul M. Jones
