A cada dia que passa temos menos tempo para lançar novas features e atualização de nossos produtos em produção. Velocidade pode nos fornecer bastante valor nos negócios, porém somente se for acompanhada de qualidade.
Takt Time e Time to Market
Takt time é um termo de origem alemã que refere-se ao bastão utilizado pelos maestros, na hora de marcar a velocidade ou cadência de uma orquestra.
No sistema Lean Manufacturing, Takt Time simboliza o tempo necessário para que um produto seja produzido. Dentro do software, podemos dizer que Takt Time é o tempo necessário para que uma funcionalidade seja colocada em produção. Ou seja, é o tempo que um time precisa para que uma ideia de feature saia da especificação e vá para a utilização dos usuários.
Time to Market é o tempo que um produto leva até chegar ao mercado.
O risco de priorizar a velocidade (a curto prazo) perante a qualidade
É muito comum que as empresas,na ânsia da busca pelos seus concorrentes, acabem priorizando a velocidade perante a qualidade. De fato, é muito importante nos dias de hoje gerarmos valor para nossos clientes e usuários cada vez mais rápido.
Porém, quando ignoramos a qualidade para que tenhamos a falsa sensação de velocidade é que os problemas acontecem. Aquela condição que nos leva a fazer uma gambiarra ou não escrever aquele teste no nosso código pode fazer sentido de imediato, porém, não muito tempo depois você vai perceber que o sacrifício da qualidade naquele momento não trouxe nada além de ilusão. Dificuldade de manutenção, bugs e falta de performance, são alguns dos problemas de débito técnico que todos conhecem.
Vamos imaginar um projeto de software, em que devido a uma pressão para lançamento, não foi pensado e nem realizado da melhor maneira, uma série de gambiarras e códigos sem qualidade foram feitos sem pensar no futuro. Depois de 6 meses o projeto cresceu, uma série de funcionalidades já estão em produção, você precisa colocar uma nova atualização no ar e você se depara com esse código:
Imagine o tempo que você levará apenas para entender o que está acontecendo neste código, imagine arrumar ou implementar algo. Claro que eu usei um exemplo exagerado apenas para fins didáticos.
Abaixo, simulei um gráfico de throughput para entendermos o que acontece nesses casos.
No gráfico acima, ilustramos um caso (hipotético porém rotineiro) que no começo do projeto o time entregou mais tarefas, porém, com baixa qualidade. Dessa maneira, podemos observar que com o passar do tempo, a velocidade da equipe caiu drasticamente, por conta da dificuldade de manutenção do código.
Como equilibrar time-to-market e qualidade?
Como podemos ver, a falsa sensação de velocidade é péssima a longo prazo. Mas como podemos equilibrar a velocidade que precisamos para fazer do nosso negócio competitivo e manter a qualidade para que não a percamos durante o projeto?
Metodologias ágeis
O maior motivo de buscarmos essa falsa sensação é o desentendimento do que é realmente velocidade e geração de valor contínuo para o cliente. O que precisamos de verdade é fazer com que usuários possam experimentar novas funcionalidades o mais rápido possível. Ai que as metodologias ágeis como SCRUM e KANBAN entram, através de processos incrementais podemos lançar novas funcionalidade rotineiramente, dessa maneira não precisamos esperar 6 meses ou até mesmo 1 ano para descobrirmos se os usuários precisam ou não daquela nova feature.
Entregas contínuas
Para que possamos aproveitar 100% das metodologias ágeis precisamos automatizar aquele deploy em produção. Dessa maneira, conseguimos lançar novas funcionalidades praticamente em tempo real. Por exemplo, a Amazon, fez 1 novo deploy a cada 11,6 segundos em 2011, o que levou a companhia a testar muito mais com seus usuários.
Segundo o artigo citado no link acima, esses foram os benefícios que as empresas que automatizam seu deploy encontram:
- ~40% de redução de custo no desenvolvimento em geral
- ~140% novos programas em desenvolvimento
- 78% de redução no custo de desenvolvimento por programa
- 5x de aumento de recursos que impulsionam a inovação
Testes unitários
Para que as entregas contínuas funcionem, precisamos que o sistema esteja muito bem testado, dessa maneira, testes unitários são os mais simples e recomendados de serem implementados.
O que você acha dessa abordagem sobre time-to-market e qualidade? Já fez algum projeto que teve que ser reescrito? Ou já participou de algum projeto que demorou tanto tempo para ser concebido, que quando foi, já não fazia mais sentido existir? Conta pra gente nos comentários.
