Em uma tradução livre, Built-in quality significa “Qualidade integrada” ou “Qualidade embutida”. Quando confrontamos a tradução com o conceito, vemos que faz todo o sentido. Built-in quality é um conjunto de práticas que garante que cada parte de uma determinada solução, em cada incremento, tenha determinados níveis de qualidade ao longo de todo o processo de desenvolvimento.

Mas como aplicar isso? Confira neste artigo!

Origem do Built-in quality

Built-in quality é um termo muito utilizado dentro do contexto do SAFe® (Scaled Agile Framework®) e do Lean-Agile Mindset! Então quer dizer ele só pode ser aplicado se o projeto ou produto usar SAFe® ou Lean-Agile Mindset? Com certeza não! Neste artigo veremos que é possível tirar o melhor proveito do Built-in quality sem necessariamente seguir algum processo pré-determinado.

Por que utilizar as práticas do Built-in quality?

Testar isoladamente não melhora a qualidade de um software. Vamos imaginar que um sistema chegou na fase de testes e faremos todos aqueles que sejam possíveis. Provavelmente, vários erros serão encontrados, corrigidos e o software chega nas mãos do cliente para ser utilizado.

A primeira ideia que vem à mente é que o software terá uma qualidade invejável, considerando que ele foi submetido a uma bateria de testes intensa e que todos os bugs encontrados foram corrigidos. Ele pode, de fato, não ter erros, mas garantir que é um software de qualidade é equivocado. Mas por quê?

Como este software receberá novas implementações ao longo do tempo? Conseguimos abranger todas as partes do software com testes ou algumas ficaram de fora porque não foi possível testá-las? O software é de fato o que o cliente esperava? Uma manutenção neste software ou mesmo nos testes será fácil ou acarretará vários erros ou dificuldades? Esses são apenas alguns problemas que, possivelmente, o sistema possui e, por isso, não pode ser considerado um software de qualidade.

Quer saber como realmente construir um software de qualidade? Vamos lá!

Entendendo o Built-in quality

O built-in quality é composto por cinco dimensões (utilizando o SAFe® 5 como referência): fluxo, qualidade de design e arquitetura, qualidade de código, qualidade de sistema e qualidade de release.

1 - Fluxo

Todos concordamos que estabelecer um fluxo para qualquer coisa é extremamente importante, inclusive é um dos grandes pilares de sucesso do kanban. Mas onde o fluxo se encaixa no Built-in quality? Um fluxo saudável em um contexto de qualidade acaba removendo erros, reduzindo retrabalhos e desperdícios. 

Para otimizar o fluxo algumas técnicas são aplicadas:

• TDD (Test-Driven Development)
• Critérios de aceitação de Story e Feature com Behavior-Driven Development (BDD)
• A hipótese de benefício do recurso com Lean-UX
• Test first: test first também pode ser associado ao Shift Left Testing, que de uma forma bem resumida faz o time testar desde o início do processo de desenvolvimento. Importante comentar que, para ter melhores resultados, é necessário seguir os conceitos da pirâmide de teste.
• CI/CD: CI/CD não pode ser um gargalo, CI/CD precisa otimizar o fluxo. Se estiver sendo um gargalo, você provavelmente não estruturou uma pipeline da maneira correta, considerando o contexto de time, produto e tecnologia.

Parece mágica, não é? Mas ao aplicar essas técnicas, você consegue testar primeiro, garante que mudanças no software não introduzam novos erros e permite uma execução rápida…um fluxo!

2 - Qualidade de design e arquitetura

“Ah, a qualidade do meu software é o suficiente”. Ouço muito essa afirmação, mas ela é 80% errada por quê? Se focarmos apenas na qualidade do sistema e deixarmos a qualidade de outras partes em segundo plano, a primeira dificilmente será alcançada em sua totalidade. Parece contraditório ou mesmo confuso, mas vou explicar.

Qualidade em arquitetura habilita que futuros requisitos sejam fáceis de serem implementados e, principalmente, mais fáceis de serem testados. Processos tradicionais que obrigam decisões antecipadas resultam em escolhas que diminuem o fluxo, causando retrabalhos. Precisamos ter em mente que requisitos evoluem e, automaticamente, o design também precisa evoluir.

Mas e aí, o que fazer?

• Utilizar o SOLID: são princípios que ajudam o desenvolvedor a escrever códigos mais limpos, definindo responsabilidades, diminuindo acoplamentos e facilitando a refatoração assim como reaproveitamento do código.
• Design Patterns: são soluções generalistas para problemas recorrentes durante o desenvolvimento de um software;
• Testabilidade: a arquitetura do sistema deve possibilitar que todo ele possa ser testado de forma automatizada, de preferência.
• Componentes modulares: muito ligado à testabilidade. Quando definimos componentes modulares de forma apropriada, o time consegue substituir aqueles caros (por exemplo devices) ou lentos por dublês de teste (mocks, stubs, etc), o que facilita os testes e o desenvolvimento, em muitas ocasiões.

3 - Qualidade de código

A qualidade de código é um dos alicerces que precisam estar fortes pensando em qualidade. Imagine você dando manutenção em um código mal escrito? Imagine a quantidade de lixo e código inútil que um sistema inteiro pode conter? Um dos conceitos mais difundidos atualmente para combater estes problemas é o Clean Code que, de forma bem direta, se refere a um conjunto de boas práticas na escrita de software, difundida pelo querido “Uncle Bob”.

Porém o Built-in quality foca em alguns aspectos mais específicos que veremos a seguir:

• TDD: sim, o nosso querido TDD está na lista! Ele basicamente orienta a criação de testes de unidade antes da implementação correspondente estar de fato implementada. Em resumo, escrevemos o teste antes do código. Isso força os desenvolvedores a pensar mais amplamente sobre o problema, incluindo os casos extremos e as condições de contorno antes da implementação, criando apenas o código necessário. Melhor compreensão resulta em desenvolvimento mais rápido com menos erros e menos retrabalho, criando um fluxo e qualidade.
• Revisão: a revisão de código é essencial, tanto no código dos testes automatizados quanto no software em si.
• Trabalho em pares: é uma prática considerada polêmica para alguns. “Gastar” o tempo de duas pessoas para escrever o mesmo código? Esse provavelmente é o primeiro questionamento que surge, mas estudos já comprovaram que é muito mais prático, gera mais qualidade, menos retrabalhos e, no final, vale muito a pena.
• Padrões de codificação: o código precisa seguir as boas práticas da comunidade da tecnologia em questão.
• Propriedade coletiva: todos são responsáveis por todo o código do sistema! Tenha isso em mente.

4 - Qualidade do sistema

Enquanto a qualidade do código e do design garantem que os artefatos do software possam ser facilmente compreendidos e alterados, a qualidade do sistema confirma que ele opera conforme o esperado. As últimas peças do quebra cabeça estão sendo postas à mesa para serem encaixadas. Todas as práticas anteriores obviamente melhoram, e muito, a qualidade do sistema, mas as práticas aqui apresentadas são mais exclusivas para este objetivo. Vamos lá:

• Alinhamento: o alinhamento e o entendimento compartilhados reduzem os atrasos e o retrabalho do desenvolvedor, permitindo um fluxo mais rápido. Aqui, precisamos considerar um alinhamento de forma mais ampla, sempre que for necessário. O BDD é uma das maneiras que possibilita um alinhamento eficaz entre todo o time;
• Model-based systems engineering (MBSE): é a aplicação de sistemas de modelagem para explorar e documentar as principais características do sistema. Quando validamos as características do sistema, os modelos acabam facilitando o aprendizado de propriedades e comportamentos, permitindo feedback rápido sobre requisitos e decisões de projeto;
• CI/CD: escalar a agilidade resulta em muitos desenvolvedores fazendo alterações que devem ser continuamente verificadas para identificar conflitos e erros. As práticas de integração e entrega contínuas garantem um feedback rápido aos desenvolvedores. Cada mudança é rapidamente empacotada, integrada e testada em vários níveis. O CI/CD automatiza o processo para que cada pequena alteração passe pelos estágios previamente definidos e, claro, facilite a resposta em caso de uma falha.

5 - Qualidade da release 

É fato que, quanto mais rápido uma empresa consegue liberar versões no mercado ou em um ambiente específico para validação, mais rápido descobrimos se estamos entregando algum valor. Juntamente com isso, pequenas mudanças permitem releases mais rápidas, mais frequentes e com menos riscos.

Uma das principais práticas que habilita a qualidade na release é o Definition of Done (DoDs) escalável.

A seguir, temos cada um dos Definition of Done que o Built-in quality prega:

• Incremento no time: o time é a menor parte gerenciável. Neste nível é necessário definir DoDs pensando em um contexto do time e respondendo a pergunta: a minha implementação está pronta para ser integrada em um contexto de sistema?
• Incremento no sistema: um sistema pode ser composto por vários times. Neste ponto, já entendemos que, por exemplo, os requisitos não funcionais (este é um exemplo de DoD neste nível) devem ser considerados para que a implementação vá para o próximo nível;
• Incremento na solução: entende-se por solução um possível conjunto de sistemas. Neste ponto, já entendemos que, por exemplo, a solução precisa ter sido demonstrada e os feedbacks implementados quando aplicáveis (este é um exemplo de DoD neste nível) devem ser considerados para que a implementação vá para o próximo nível;
• Release: chegamos na release de fato. Aqui é o ponto que o sistema vai para a produção, para o ambiente final pretendido e finalizamos a construção de um sistema perfeito!

Conclusão sobre Built-in quality 

As práticas do Built-in quality são simples, porém muitas vezes o problema está em como implementá-las corretamente, ainda mais quando o SAFe® não é utilizado em sua totalidade. Neste caso os profissionais responsáveis pelo processo de qualidade precisam atuar, para que além da implementação das práticas também ocorra a coleta de métricas, acompanhamento efetivo e a disseminação das práticas. 

A grande mágica é que no mundo da tecnologia não necessariamente existe o certo ou errado. O que existe é a habilidade de adotar determinadas tecnologias, processos e ferramentas em contextos específicos. Por isso, o profissional precisa conhecer as opções disponíveis e saber quando e onde aplicá-las.

Vamos implementar o Built-in quality no seu time?