Aurock

Always Done: desenvolvimento iterativo

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

Referência

[1] A Fórmula da Eficácia – Alisson Vale

Compartilhe nas Redes Sociais

Share on facebook
Facebook
Share on twitter
Twitter
Share on whatsapp
WhatsApp
Share on telegram
Telegram

OUTROS CASES DE SUCESSO

Damos valor à sua privacidade

Nós e os nossos parceiros armazenamos ou acedemos a informações dos dispositivos, tais como cookies, e processamos dados pessoais, tais como identificadores exclusivos e informações padrão enviadas pelos dispositivos, para as finalidades descritas abaixo. Poderá clicar para consentir o processamento por nossa parte e pela parte dos nossos parceiros para tais finalidades. Em alternativa, poderá clicar para recusar o consentimento, ou aceder a informações mais pormenorizadas e alterar as suas preferências antes de dar consentimento. As suas preferências serão aplicadas apenas a este website.

Cookies estritamente necessários

Estes cookies são necessários para que o website funcione e não podem ser desligados nos nossos sistemas. Normalmente, eles só são configurados em resposta a ações levadas a cabo por si e que correspondem a uma solicitação de serviços, tais como definir as suas preferências de privacidade, iniciar sessão ou preencher formulários. Pode configurar o seu navegador para bloquear ou alertá-lo(a) sobre esses cookies, mas algumas partes do website não funcionarão. Estes cookies não armazenam qualquer informação pessoal identificável.

Cookies de desempenho

Estes cookies permitem-nos contar visitas e fontes de tráfego, para que possamos medir e melhorar o desempenho do nosso website. Eles ajudam-nos a saber quais são as páginas mais e menos populares e a ver como os visitantes se movimentam pelo website. Todas as informações recolhidas por estes cookies são agregadas e, por conseguinte, anónimas. Se não permitir estes cookies, não saberemos quando visitou o nosso site.

Cookies de funcionalidade

Estes cookies permitem que o site forneça uma funcionalidade e personalização melhoradas. Podem ser estabelecidos por nós ou por fornecedores externos cujos serviços adicionámos às nossas páginas. Se não permitir estes cookies algumas destas funcionalidades, ou mesmo todas, podem não atuar corretamente.

Cookies de publicidade

Estes cookies podem ser estabelecidos através do nosso site pelos nossos parceiros de publicidade. Podem ser usados por essas empresas para construir um perfil sobre os seus interesses e mostrar-lhe anúncios relevantes em outros websites. Eles não armazenam diretamente informações pessoais, mas são baseados na identificação exclusiva do seu navegador e dispositivo de internet. Se não permitir estes cookies, terá menos publicidade direcionada.

Visite as nossas páginas de Políticas de privacidade e Termos e condições.

Nós armazenamos dados temporariamente para melhorar a sua experiência de navegação e recomendar conteúdo de seu interesse. Ao utilizar nossos serviços, você concorda com tal monitoramento.