Um bom profissional normalmente deseja desenvolver software seguindo critérios de qualidade. Mas ainda existe uma visão de que ao fazer isso o processo demora mais. Será que isso é verdade? Ou será que, o que demora é aprender a desenvolver com qualidade?

Desenvolver software se tornou algo mais complexo ao longo das últimas décadas, e não porque está mais difícil programar ou porque não temos boas ferramentas, atualmente é mais simples programar e há ferramentas excelentes que contribuem em várias questões.

Um dos pontos que tornou mais complexo o desenvolvimento de software foi que na prática não se trata mais apenas de programar, trata-se geralmente de criar um produto, resolver um problema do mundo real e/ou inovar em algum negócio que talvez poucos dominem. Isso trouxe várias novas necessidades para o jogo, e por consequência vários outros papéis além do programador.

Além da complexidade, veio a maior exigência com relação ao software entregue, e isso tudo fez necessário o mundo do desenvolvimento de software amadurecer no tema qualidade.

E quando falamos de qualidade, ela está presente no produto final entregue, a qual é avaliada pelos usuários, e também durante o processo de desenvolvimento, onde ela pode ser determinante para o desenvolvimento de um software sustentável, escalável e de fácil mudanças e evoluções.

Sempre que a qualidade nestes dois aspectos são adotadas, muitos profissionais entendem que isso torna as coisas mais lentas, principalmente com relação ao processo de desenvolvimento, sendo este o foco da sequência do artigo.

Vamos considerar de forma geral algumas etapas que normalmente um processo de desenvolvimento tem:

1. Entendimento do negócio e personas.
2. Detalhamento de requisitos e histórias.
3. Definição e prototipação do produto.
4. Definição de arquitetura.
5. Escolha de linguagens e ferramentas.
6. Codificação.
7. Integração do código de todos os desenvolvedores.
8. Release de software.
9. Atualização em produção.
10. Liberação para o cliente.

Como citado no início, desenvolver software não é mais apenas programar, e cada etapa possui critérios de qualidade, e quando adotados podem dar uma primeira sensação de demora!

Isso ocorre por alguns motivos, e um dos principais é que ao iniciar a adoção de critérios de qualidade os profissionais terão que aprender a trabalhar com eles, logo a forma como fazem as coisas mudam, e no início é natural haver demora.

E aí temos um grande ponto de atenção, como há essa sensação de demora, muitos não aprendem corretamente e de forma completa como adotar a qualidade porque perdem o engajamento durante a fase de aprendizagem. Se não aprendem direito, não adotam e trabalham com os critérios de qualidade da forma inadequada, logo o resultado pode ser o pior dos cenários, realmente o time demora demais porque não está trabalhando da forma adequada e a “meia qualidade” adotada não gera o resultado esperado.

O desfecho é que quando isso acontece, tais critérios de qualidade são vistos com descrédito e normalmente abolidos.

Um outro ponto determinante é que quando não se adota critérios de qualidade, normalmente também não se mede:

• O tempo de cada etapa.
• Quantas vezes algo “vai e volta” no processo de desenvolvimento.
• O tempo gasto com bugs, correções, suporte, dentre outros.

Ou seja, muitos profissionais focam no código estar em produção e ignoram o quanto de retrabalho ele pode gerar.

A comparação adequada é medir o tempo utilizado de desenvolvimento + o retrabalho que depois normalmente a ausência de critérios de qualidade gera.

Vamos exercitar alguns cenários:

Cenário 1

Um time precisa desenvolver algo, e ignora as etapas de 1 a 5, ou seja, já começa codificando uma solução.

A possibilidade da solução codificada não resolver o problema se torna grande, ninguém pensou adequadamente sobre ela.

O resultado que normalmente ocorre é:

• O time gasta horas, dias, semanas codificando. O software vai para produção.
• Algumas pessoas acreditam que foram rápidas, mas na prática o software não resolveu o problema.
• Se o software não for utilizado, porque não resolveu o problema, tempo e dinheiro foram jogados fora.
• Se o time precisa refazer partes do software, volta-se para a etapa de codificação, o que pode custar um elevado tempo a cada alteração.

Em um cenário deste, bem comum, onde está a rapidez? Ser rápido mas não conseguir ultrapassar a linha de chegada porque precisa voltar a um ponto anterior, pode não dar a vitória (entrega).

Ou pior ainda. Ser rápido na “pista” errada, gera uma entrega de algo que não será utilizado.

Cenário 2

Outro time adota todas as etapas, mas não entende bem do negócio e as personas, cria histórias e protótipos “em papel de pão” que na prática não detalham nada, definem arquitetura, linguagens e ferramentas sem embasamento adequado.

Isso é semelhante ao cenário anterior, só que se gastou mais tempo para fazer algo que não seguiu critérios de qualidade.

O resultado normalmente é:

• O time acredita que está trabalhando melhor, mas o resultado não vai muito além do cenário anterior.

Utilizar etapas e aplicar temas sem adoção de qualidade, realmente tende a apenas demorar mais o todo, e sem os resultados esperados

Cenário 3

Outro time adota as etapas, e critérios de qualidade até a etapa 3, mas não pensa adequadamente na arquitetura, codifica de qualquer jeito, um código de pouca legibilidade e sem testes.

A solução planejada e detalhada pode ser boa, mas a possibilidade do software entregue conter bugs, não ser escalável, de difícil manutenção e até não resolver bem o problema é grande.

O resultado normalmente é:

• O código foi implementado rápido, mas tende a ser refeito várias vezes até que o mesmo não contenha mais bugs.
• A curto ou médio prazo a solução apresentará problemas de escala e manutenção.
• O tempo gasto em correção normalmente é grande e não é medido adequadamente.
• Essas correções impactam no tempo disponível para novas funcionalidades e/ou evoluções.

Adotar qualidade em apenas algumas etapas, pode ajudar, mas normalmente não gera o resultado máximo esperado.

Cenário 4

Outro time adota com critérios de qualidade até a etapa 6, pensando bem a arquitetura, usando boas ferramentas e gerando código legível e bem testado unitariamente, mas na hora de integrar o trabalho de todos os desenvolvedores não há testes de integração e/ou de aceitação, e o release do software é complexa e manual.

O software tende a ser melhor do que no cenário anterior, mas ainda assim mesmo com o bom trabalho individual, o todo que o time entrega e a forma como entrega podem fazer com que o software continue a ter bugs.

O resultado normalmente é:

• O time acredita que faz todo o trabalho com qualidade, mas ainda assim há problemas com as entregas.
• Muitos apenas pensam confirmar que a qualidade só torna o processo mais demorado.

O processo de qualidade envolve o trabalho individual e o coletivo, do início ao fim.

Cenário 5

Por fim, outro time adota critérios de qualidade em todas as etapas, a release do software está pronta, testada, validada, todos estão satisfeitos com o trabalho realizado e o release é simples de ser feito. Mas a atualização em produção e liberação ao cliente demora, seja por questões burocráticas, ações manuais ou até insegurança.

Nesse caso, o software provavelmente estará bom, resolverá o problema, mas ainda haverá a sensação de que a entrega demora.

O resultado normalmente é:

• As entregas são vistas como satisfatórias, mas ainda há dúvidas porque a qualidade não ajuda a ser mais rápido.

A qualidade é essencial, mas a entrega real é o cliente usando o software, e os critérios de qualidade precisam atuar até esse ponto final.

Os cenários apresentados, deixam a qualidade de lado em algum momento, e o resultado mais comum é ter que voltar a etapas anteriores para refazer parte do trabalho. Esse custo normalmente é ignorado

Embora adotar qualidade no desenvolvimento de software agregue mais etapas, que irão provavelmente demandar tempo no início, poderão diminuir o tempo gasto com as idas e vindas do software entre desenvolvimento e produção, e as intermináveis refatorações e correções de bugs.

Para adotar qualidade, voltamos a um ponto inicial: Aplicar as etapas adequadas e adotar os critérios de qualidade requer conhecimento e prática.

Ao adotar critérios de qualidade, o processo realmente irá demorar mais no início, porque as pessoas precisam aprender, ter prática e aplicar em todos os aspectos. Isso é o que normalmente demora, mas que depois viabiliza a qualidade com velocidade.

Agora vamos pensar em um último cenário:

O time já conhece e tem prática nas etapas aplicadas e critérios de qualidade adotados.

• Há um modelo de negócio definido e documentação de negócio publicada e clara a todos.
• Há um mapeamento das personas publicado a todos e as funcionalidades são elaboradas considerando-as.
• Os requisitos são detalhados, as histórias são exemplares e possuem critérios de aceite adequados.
• Existe prototipação para validar todas as ideias antes de iniciar a implementação.
• Os desenvolvedores recebem as histórias junto a cenários de teste de aceitação.
• Existe clareza do negócio e funcionalidades, então a arquitetura é pensada e planejada focando nisso.
• As ferramentas e linguagens são escolhidas considerando as necessidades do negócio e arquitetura planejada.
• A codificação foca nas funcionalidades necessárias, com clareza do negócio, respeitando a arquitetura, gerando código legível e extensível, com testes de componentes e integração e com alta cobertura dos testes, tanto quantitativa quanto qualitativa.
• A integração do código é facilitada já que todos respeitam a organização de cada etapa.
• São executados testes de integração e aceitação que garantem que a junção do código atende ao esperado e não há bugs, o release pode ser feito.
• Atualizar o ambiente de produção é uma tarefa automatizada, executada através de um gatilho ou apenas um comando.
• A liberação para os clientes se dá por mecanismo de Feature Toggle.

Todos os itens em negrito são critérios ou questões relacionadas à qualidade, e com isso o resultado normalmente é: O time sabe o que fazer, como fazer, e a qualidade esperada para a próxima etapa ou cliente. Cada etapa bem executada contribui na execução da próxima com maior eficiência e velocidade.

Para cada item destacado neste último cenário há vários outros tópicos, que para detalhar precisam de artigos próprios. Mas o destaque aqui é que quanto mais o time atuar em um cenário assim, mais rápido tende a ser.

Muitos times adotam qualidade pela metade, ou abandonam isso antes de chegar ao ponto onde o time se tornará rápido.

Para um time trabalhar assim, é necessário:

• Agregar pessoas que tenham esse conhecimento e prática.
• (Minha preferida) Treinar as pessoas que já estão no time e acordar o espaço e tempo para o aprendizado e prática.
• Apoiar e acreditar que é possível, tendo resiliência para não desistir no meio do caminho.

É fácil? Não!

É possível? Sim!

Qualidade com velocidade acontece em curto prazo? Depende do conhecimento e prática do time.

O mercado cada vez menos dá espaço para a ausência de qualidade no processo de desenvolvimento, e ela pode também contribuir na velocidade dos times!

A imagem principal foi composta a partir de ilustrações de: Fundo vetor criado por macrovector - br.freepik.com