Por que ainda discutimos se é bug ou melhoria?

Quem trabalha com desenvolvimento de produtos digitais sabe que pode ser difícil rotular um ticket como bug ou melhoria nas tarefas que devem ser repensadas ou corrigidas pelo time. A partir de uma discussão sobre o tema com Analistas de Qualidade na SoftDesign, Raphael Rodrigues realizou um SoftDrops* para detalhar as diferentes percepções que cada profissional pode ter sobre o tema.

O agilista iniciou sua apresentação explicando que, se pensarmos de maneira linear, um bug ocorre quando algo não funciona. Já uma melhoria é uma otimização para tornar uma determinada funcionalidade melhor ou mais bonita. Ainda assim, essa diferenciação pode não ser tão clara no desenvolvimento de produtos digitais, como veremos a seguir.

Alinhando conceitos

Antes de discutir a razão que torna o entendimento do que é bug ou melhoria mais complexo, Raphael apresentou alguns conceitos e contextualizou o cenário, para que todos os participantes estivessem alinhados.

– Defeito: é uma imperfeição ou deficiência em um produto de trabalho em que esse não atende seus requisitos ou especificações (Brazilian Software Testing Qualification Board – BSTQB);

– Requisito de software: é uma capacidade que dever ser atendida ou ofertada por um sistema ou um de seus componentes para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.

A identificação da funcionalidade dos requisitos, geralmente, pode ser atribuída ao Analista de Testes ou Quality Assurance – que avalia o software em relação aos dados coletados dos usuários ou nas especificações do sistema. Esse é um processo inerente ao desenvolvimento de software e tem como principal objetivo identificar falhas a serem corrigidas até que o produto alcance a qualidade esperada entre as partes interessadas. Essa seria uma das razões para discutir se alguma falha detectada é um bug ou uma melhoria.

Em relação ao significado de qualidade, o agilista ressaltou que não existe uma definição única na literatura do assunto, podendo ser descrita de diferentes formas. Por exemplo, Joseph Moses Juran, diz que qualidade é a adequação ao uso. Philip Crosby afirma que é a conformidade às especificações. Já Noriaki Kano fala que qualidade são produtos e serviços que atendem ou excedem as expectativas do consumidor.

Um breve histórico dos processos no Desenvolvimento de Software

Segundo Raphael, ocorreu que, quando se começou a pensar formas para desenvolver softwares, a inspiração veio – principalmente – da indústria. A partir disso, surgiu a Engenharia de Software. Nesse sentido, Teste de Software seria uma área de conhecimento da Engenharia de Software que procura garantir a qualidade do produto ou serviço digital a partir da definição e normatização dos processos de desenvolvimentos – como ocorre no setor industrial.

Assim, esse modelo passou a ser aplicado para garantir que um produto que satisfaça as expectativas do cliente, dentro do que foi acordado previamente. Desse formato clássico de sistemas de produção industrial bem resolvidos – como o da Toyota, por exemplo – veio a inspiração para que, no desenvolvimento de software, a conformidade fosse buscada. Isso remete ao modelo de trabalho conhecido como waterfall (ou cascata), que documentava todos os requisitos e acontecia conforme a figura abaixo:

Nesse formato, se utilizava o pensamento analítico, segundo o agilista. Isto é, as etapas eram quebradas e uma dependia da conclusão da anterior para o andamento do projeto, não permitindo espaço para erros ou inovação na solução de problemas. Por esse motivo, constatou-se que esse modelo não atende mais a realidade do desenvolvimento de software.  Para ilustrar esse momento, Raphael compartilhou uma conversa que teve com a Product Manager Karina Hartmann, que afirmou:

A grande mudança que está acontecendo é entendermos que copiamos o modelo errado dos engenheiros. Copiamos o modelo da PRODUÇÃO em massa (conformidade), quando deveríamos ter copiado o modelo de DESENVOLVIMENTO DE PRODUTO (experimentação, prototipação, espaço para aprendizado, foco em design/solução de problema do usuário etc.).

A partir disso, abriu-se um espaço para que o desenvolvimento seja realizado por meio de um pensamento sistêmico. Nesse cenário, o trabalho é realizado de forma iterativa e incremental, com experimentos constantes, como vemos abaixo:

Uma parte importante desse formato são os requisitos, contextualizados em histórias de usuários. Isso se dá a partir de conversas com quem de fato irá utilizar uma aplicação, o que possibilita a compreensão da necessidade do cliente final. A partir disso, o time conversa e busca formas para solucionar essas dores, quebrando-as em diversos itens, como critérios de aceite, por exemplo.

Mas, afinal, é bug ou melhoria?

A partir dessa contextualização, é possível constatar que, ao se utilizar histórias de usuários, as funcionalidades de um projeto passaram a ser discutidas verbalmente e não ficam tão detalhadas em sua descrição como nos modelos prescritivos. De acordo com Raphael, é nesse ponto que começam a surgir dúvidas sobre o que é um bug ou uma melhoria.

Ainda segundo o agilista, se pensarmos que defeito é o sistema não funcionando conforme os requisitos escritos, como identificar o que é cada demanda, uma vez que no modo atual escrevemos menos requisitos? No modelo tradicional, se estava descrito entre os requisitos, era um bug, se não estava, era uma melhoria. Já no modelo ágil, isso exige um senso crítico dos envolvidos, uma vez que o objetivo principal é aprender.

Raphael ainda ressaltou que, no formato atual, trabalhamos com conhecimento e somos valorizados por nossas capacidades e tomada de decisão. Não se busca mais somente a conformidade, há espaço para experimentar. Sendo assim, nesse contexto de entregas e feedbacks contínuos, talvez não faça mais sentido discutir o que é bug ou melhoria – aqui são excluídos times de sustentação, que possuem uma realidade diferente dos de desenvolvimento, pois lidam com incidentes. Caso seja necessário ter uma definição, a sugestão é combinar com o time as regras e especificações. O importante é ter em mente que o propósito é o aprendizado, o rótulo do ticket não irá afetar o resultado.

*O SoftDrops é um evento de troca de conhecimento que acontece todas as quartas-feiras, na sede da SoftDesign. A cada semana, um colaborador se predispõe a expor para os colegas algum tema de seu interesse, que tenha relação com os três pilares do nosso negócio: design, agilidade e tecnologia. A minipalestra dura em torno de trinta minutos e é seguida por um bate-papo entre os participantes.