Imagine o seguinte cenário: alguém chega com uma ideia e precisa de um time para desenvolvê-la. Esse cliente quer investir no projeto, conhecer melhor o mercado e o produto em si. Ele quer entender mais sobre quem vai usar o produto, e finalmente, deseja ter algum retorno para seu investimento.

O senso de urgência é evidente! Claro, a relação é bem simples. Quanto maior a demora para o cliente receber seu retorno, mais tempo ele passa gastando sem validação das expectativas. Parte desse custo é chamado de custo de espera (cost of delay).

Esse é um exemplo claro em que a demora para entregar software ao cliente gera prejuízos no ciclo de desenvolvimento de software.

Construir software, além de todo o trabalho técnico, é também um trabalho de gerenciamento de incertezas e expectativas. Quanto maior o intervalo entre o alinhamento da expectativa e a apresentação do software ao cliente, maiores são as chances de “desalinhamento”. Isso resulta em aumento de escopo e aumento do custo do desenvolvimento — entre outros custos que vão além do custo de espera que mencionamos antes.

Martin Fowler fala sobre o custo de espera no desenvolvimento de software no seu artigo sobre YAGN (You aren’t gonna need it) e representa bem outros custos que podem ser somados ao custo final, quando não construímos o software certo e com qualidade.

Desenvolver software não é uma tarefa fácil. Envolve muitos conhecimentos e inúmeras habilidades. Além da dificuldade de construção, é também uma atividade difícil de mensurar e tangibilizar, até que o produto seja lançado e utilizado por usuários reais.

Na indústria de software existem várias técnicas e abordagens que são usadas para resolver esse “problema”, mas podemos considerar isso mais uma característica do desenvolvimento de software do que de fato um “problema”.

Na Idopter Labs, a abordagem utilizada para diminuir os impactos da dificuldade de mensurar e tangibilizar o que desenvolvemos é simples: entregamos software rápido e continuamente. Nesse post iremos apresentar 5 dicas de como fazer isso e razões pelas quais, caso você siga essas dicas, suas chances de êxito podem ser enormes!

Frases comuns que precisamos evitar ao entregar software

É comum observarmos alguns cenários se repetindo no desenvolvimento de software, principalmente quando o desenvolvedor, ou o time, se deparam com a seguinte pergunta: “Está pronto?”, ou “Conseguiu terminar o que combinamos?”. E aí surgem respostas também comuns:

“Tá tudo pronto, só falta colocar no ar!”

“Terminei, só falta testar!”

“Terminei tudo, só falta aquela feature complicada”

“Terminei tudo que conversamos a 3 meses atrás, o que achou?”

“Estranho, na minha máquina funciona!”

Eu sei, você deve tá pensando, normal, em software é assim mesmo! Não, não precisa ser assim, vamos às 5 dicas que vão nos ajudar a evitar cada uma dessas respostas ao entregar software.

Dica 1 — Comece pela parte difícil

A primeira dica é orientar o desenvolvimento pelo OBJETIVO e não pelo ESCOPO. O time precisa ter clareza do objetivo que o cliente está buscando alcançar, assim todos os envolvidos poderão contribuir para o alinhamento e planejamento estratégico, para alcançar aquele objetivo, buscando soluções em conjunto que viabilizem entender melhor o produto durante os ciclos de desenvolvimento.

Quando o time alinha escopo com o cliente, as chances de perderem a visão do objetivo principal por focar na lista de coisas a serem feitas é grande, isso acaba tirando facilmente o time do trilho. O escopo é um reflexo da estratégia que o time e o cliente alinharam para alcançar um objetivo, se perceberem que existem outras maneiras de alcançar aquele objetivo, ou que pode ser feito algo melhor do que foi imaginado inicialmente, precisa planejar novamente e mudar o escopo.

Entenda bem o problema a ser resolvido e na sequência encontre e trabalhe nas partes que oferecem o maior risco. Recomendamos nessa fase de descobertas técnicas como: Lean Inception, Product Backlog Building, Story Mapping, Mapeamento de Personas, Mapa de Empatia, entre outras técnicas de discovery e design thinking. Quanto mais o time e o cliente tem clareza do problema melhores serão o planejamento e os resultados.

Trabalhar nas partes que oferecem maior risco vão ajudar a validar de forma antecipada problemas que podem inviabilizar o projeto, começar com isso vai ajudar a tirar antecipadamente possíveis barreiras para alcançar o objetivo. É comum no desenvolvimento de software os times planejarem partes complicadas para o final, porém isso só faz aumentar o prejuízo se descoberto tardiamente que não era bem o que se esperava.

Resumo da dica 1:

• Alinhe o OBJETIVO, não o ESCOPO
• Trabalhe primeiro nas partes que oferecem maior risco

Dica 2 — Automatize os seus testes

A dica 2 já foi um tema polêmico, acredito que hoje não seja tanto, mas ainda pouco praticado por desenvolvedores e times. É isso mesmo, automatize os testes da sua solução, assim irá potencializar a velocidade de entrega.

Testar software é uma atividade primordial para garantirmos que está tudo funcionando como esperado, é como avaliamos a qualidade do que foi construído. Mas existem várias formas de fazer isso, e em sua grande maioria, é feito de forma manual.

Então o desenvolvedor implementa a solução e depois simula o uso, para isso ele vai precisar simular exatamente o ambiente que o usuário final vai usar, com dados, integrações, etc. Sim, o tempo dedicado para isso é custoso, agora imagina ter que fazer isso sempre que finaliza uma parte do software, e ao testar e encontrar um problema, precisa repetir tudo novamente após a correção.

À medida que o software vai crescendo, mais custoso o teste manual vai ficar, e aí que você vai ter desejado ter esses testes automatizados desde o início. O custo da automação no início do projeto é maior, pois é preciso criar as estruturas que irão dar suporte a construção dos cenários de testes automatizados e isso tem sua complexidade, mas depois de pronta, basta reutilizar e é nesse momento que a automação passa a se pagar, não só pelo custo menor das próximas automações, mas principalmente pela velocidade de execução de todos os testes criados anteriormente.

A possibilidade de ter feedback de vários testes sendo realizados em questão de minutos, ou até segundos, apenas com um comando, traz grandes benefícios para a qualidade e velocidade do desenvolvimento. Como vimos no início desse post, quando falamos dos custos associados ao desenvolvimento, não basta ser rápido, tem que fazer direito.

Veja alguns outros benefícios que a automação dos testes proporciona:

• Ajuda a melhorar a qualidade da solução, pois a avaliação do funcionamento de várias partes do software é feita rapidamente.
• Traz segurança para melhorias e manutenção, com um bom conjunto de testes é possível identificar rapidamente como modificações afetam o comportamento do software e também auxiliam na resolução dos problemas.
• Aumenta a frequência de feedback, com a automação muitos testes podem ser executados e dão feedback rapidamente, diferente do teste manual, que possui um custo alto para execução e naturalmente o time acaba realizando menos. E como vimos antes, quanto mais demora o feedback em software, maiores são as chances de encontrar problemas e aumentar o custo do desenvolvimento.
• Base para integração contínua, ter um conjunto de testes automatizados para serem executados continuamente é a base da prática de integração contínua, que é nossa próxima dica!

Resumo da dica 2:

• Automatize os testes
• Teste sua solução frequentemente

Dica 3 — Integre continuamente

Integrar software continuamente é a prática que ajuda a evitarmos surpresas na hora que “tá tudo pronto”, mas quando vamos juntar as partes, elas não se encaixam. E quando trabalhamos em um time, várias pessoas alteram o software ao mesmo tempo, mas de forma separada, para depois juntar tudo, então essa prática se torna ainda mais necessária.

Quando integramos o software avaliamos se todas as partes continuam funcionando, se nada do que já estava construído foi afetado de forma negativa. Porém, quando não fazemos isso com frequência, temos um risco maior de encontrar problemas na hora de integrar o software.

Mais uma vez é possível observar que a integração contínua também é um exercício de coletar feedback de uma atividade do ciclo de desenvolvimento de software que é a integração. E como vimos antes, maximizar feedbacks potencializam a entrega rápida de software e diminuem os riscos com acúmulo de problemas desconhecidos e desalinhamentos.

Como Kent Beck menciona no livro eXtreme Programming Explained, se integrar software é tão bom, porque não vamos isso frequentemente?

Veja algumas dicas para iniciar a integração contínua nos seus projetos:

• Não trabalhe em tarefas grandes, minimize os tamanhos e maximize os entregáveis, assim você consegue aumentar a frequência do feedback.

• Envie suas alterações (commits) frequentemente e atualize seu trabalho com os demais (branch) frequentemente, assim você minimiza o risco dos impactos das modificações que estão sendo realizadas por outros membros do seu time.
• Use e abuse do controle de versão e automatize o fluxo a partir dele, desde a compilação, checagem estática (formatação, complexidade, code smell), checagem de segurança, execução dos testes automatizados, lembre-se que estamos buscando feedbacks que nos mostrem se o código novo não está quebrando, ou afetando o antigo, o mais rápido possível.

Resumo da dica 3:

• Integre seu trabalho continuamente
• Minimize os tamanhos das tarefas e maximize os entregáveis
• Automatize os feedbacks da integração

Dica 4 — Entregue continuamente

Uma boa referência para esta dica é, esteja sempre pronto para apresentar o software, ou seja, não basta integrar continuamente, é importante disponibilizar frequentemente também. Essa prática é conhecida como entrega contínua.

O princípio é o mesmo, maximizar os feedbacks e diminuir os riscos da publicação e disponibilização do software. Essa fase envolve, implantação em um ambiente, integração com outros componentes como, banco de dados, APIs, configurações de acesso, segurança, entre outras possíveis necessidades para ter o software funcional e disponível.

Para permitir realizar essa etapa de forma contínua, precisamos automatizar o fluxo de entrega desde o início, a um clique de distância, e mais uma vez o controle de versão será o gatilho para disparar o processo de entrega.

Ter essa “esteira automática de entrega” desde o início do projeto vai potencializar a velocidade e frequência de entrega do software ao cliente. Assim evitamos outra frase que vimos no início deste post: “Tudo pronto, só falta publicar!”

No desenvolvimento de software geralmente usamos alguns ambientes para nos ajudar a diminuir o risco de entregar software no ambiente em que o cliente, ou seus usuários, vão acessar. Temos ambiente de desenvolvimento, testes, validação/homologação, produção, é bem comum encontrar esses ambientes nos times de desenvolvimento de software.

Com tantos ambientes é fácil encontrar problemas como: “estranho, mas tá funcionando na minha máquina”. Então outra dica importante na entrega contínua é padronizar as configurações dos ambientes, assim você diminui o risco de problemas ao promover o software de um ambiente para o outro.

Muitos times acham que depois de implantado e entregue o trabalho acabou, mas ainda é preciso monitorar e ficar atento, mesmo com essas práticas precisamos lembrar que construir software é complexo, precisamos monitorar para continuar aprendendo sobre o comportamento da solução e melhorias que podem ser feitas, além dos bugs que podem ter escapado durante o processo!

Resumo da dica 4:

• Automatize o fluxo de entrega desde o início do projeto
• Use o controle de versão como gatilho e deixa a entrega a um clique de distância
• Padronize as configurações dos ambientes
• Monitore e aprenda

Dica 5 — Mostre seus avanços frequentemente

Com todas as dicas anteriores seu time vai se planejar e trabalhar estrategicamente para alcançar objetivos, vai investir em automação de testes e integração para construir com qualidade, minimizando os custos associados à construção do software e vai disponibilizar continuamente a solução para reduzir os riscos de publicação possibilitando demonstrar e usar a medida que o time vai avançando no desenvolvimento.

Mas para continuar alinhado estrategicamente com os objetivos do cliente, é preciso mostrar esses avanços frequentemente também, como mencionamos no início, parte do “problema” do desenvolvimento de software é que só vamos entender melhor sobre ele depois que foi construído e usado.

Então a última dica é mostrar os avanços frequentemente, é muito importante ter o cliente como parte do seu time, contar com ele para manter o alinhamento e entender cada vez mais sobre as suas expectativas, visão do produto, negócio, usuários, e avaliar se a solução está indo realmente para a direção certa.

Para aumentar a frequência, todas as dicas anteriores são essenciais, vamos ver mais algumas que vão ajudar a manter o alinhamento e aumentar as chances de construir algo realmente útil e atendendo as expectativas do cliente.

• Mantenha ciclos curtos de apresentação ao cliente, não maiores que 15 dias.
• Preferencialmente mostre o software funcionando no ambiente dos usuários, ou similar.

“software funcionando é a principal medida de progresso (Manifesto Ágil, 2001)”

• Alinhe expectativas e estratégias continuamente, sempre valide com o cliente se o que está planejado está no caminho certo.

“responder a mudanças mais do que seguir um plano. (Manifesto Ágil, 2001)”

• Colete feedbacks para refinar a solução continuamente.

Resumo da dica 5:

• Mantenha os ciclos de apresentação do progresso ao cliente não maiores que 15 dias.
• Preferencialmente mostre o software funcionando.
• Refine sua solução a partir dos feedbacks e alinhe a estratégia com o cliente continuamente.

Conclusão

Se voltarmos para as respostas comumente encontradas, quando o cliente pergunta se o software está pronto. E refletirmos um cenário com as dicas sendo realmente aplicadas no desenvolvimento de software, todas aquelas respostas dificilmente seriam usadas, pois muitos problemas seriam sanados no próprio uso dessas práticas durante o desenvolvimento. Não digo que são fáceis e simples de adotar, mas garanto que o ganho obtido vale muito todo o esforço.

Na Idopter Labs buscamos refinar nosso processo constantemente, essas são práticas que aplicamos e observamos diariamente o ganho que nos trazem para entregar software rápido e continuamente. Espero que este post ajude você a usufruir desses ganhos também!

A Idopter Labs é uma empresa de consultoria em desenvolvimento de software com o objetivo de transformar ideias em negócios digitais rentáveis. Prezamos pela transparência, objetividade e agilidade. Estamos no mercado desde 2016 e, desde então, ajudamos diversos clientes em suas iniciativas nas mais diferentes indústrias. Entre em contato conosco, será um prazer construir soluções incríveis com você.

‍