Backlog orientado à Qualidade do Produto

Qualidade não é mais uma vantagem ou característica de um produto ou serviço. Qualidade é algo indiscutível e intrínseco. Deve permanecer a todo tempo na cultura da organização, no dia a dia do time, no pensamento do PO e certamente no Backlog.

Neste artigo, vamos apresentar como o Backlog pode e deve ser orientado à Qualidade do Produto, bem como suas definições e o trabalho do Product Owner no assunto.

 

Pingo nos Is

Antes de mais nada, é importante deixar claro a definição de Qualidade e Backlog:

A Qualidade é subjetiva a cada usuário que interage e utiliza o produto, pois está relacionada ao atendimento de suas necessidades. Podemos resumi-la como o atendimento às necessidades implícitas e explícitas dos usuários na melhor forma possível, de modo que seus objetivos sejam atingidos através do seu produto utilizando técnicas, ações e controle em todas as fases de desenvolvimento.

Temos um artigo exclusivo sobre o papel do PO na qualidade do produto.

Segundo o guia oficial do Scrum, o Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto… O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões.

Quer saber mais sobre Backlog do Produto? Acesse nosso artigo sobre o assunto.

 

Aplicação da qualidade em cada tipo de item no Backlog

Como podemos observar na definição de Backlog segundo o Scrum Guide, o “backlog deve listar todas as características, funções, requisitos, melhorias e correções…”. Isso mostra que, muitas vezes, falhamos em priorizar somente novas funcionalidades.

Algumas organizações têm o costume de alocar um time específico para atuar em assuntos de Operação. Porém, essa dinâmica vai contra a premissa de que cada produto deve ter apenas e somente 1 único backlog centralizado e priorizado.

Vamos mostrar a seguir os tipos de itens do backlog e como a qualidade do Produto deve estar contemplada em cada um deles.

Débito Técnico

Débitos técnicos são, basicamente, falhas na construção do produto que normalmente não são perceptíveis aos usuários e foram deixados para depois.

São dívidas técnicas deixadas para uma construção ou correção posterior. Pode estar associada a falhas não corrigidas no produto, limitação técnica/tecnologia obsoleta, baixa qualidade no código/estrutura, falta de cobertura de código, entre outros.

Os Débitos Técnicos não se corrigem sozinhos. Normalmente, a lista aumenta devido às necessidades constantes de se implementar novas funcionalidades de forma incompleta ou com qualidade inferior somada à procrastinação da completude.

As dívidas técnicas podem existir, mas não devem ser regras e também precisam ser priorizadas. Quanto mais se demora para corrigi-los, maior o seu tamanho e complexidade do produto para ajustar.

Remover débitos técnicos mitiga riscos para o produto, acelera o desenvolvimento ágil do produto e, consequentemente, reforça a qualidade.

O Dono do Produto precisa compreender, junto ao time/líder técnico, o risco operacional e técnico que cada um dos débitos técnicos oferece ao Produto e como estes podem influenciar negativamente os usuários a médio e longo prazo. Com base nisto, deve ser priorizado e discutido junto à organização e partes interessadas a importância desta atuação.

Bugs / Defeitos

Bugs ou defeitos são inconformidades das funcionalidades do produto com o que se espera. São características indesejadas por todos aqueles que interagem com o produto em questão.

Os defeitos de produto são desvios da uma característica de um item em relação aos seus requisitos, podendo afetar ou não a capacidade do item em desempenhar uma atividade.

Problemas no produtos são extremamente mal vistos pelos usuários, podendo ser identificados e reportados pelo time de desenvolvimento, usuários, partes interessadas, PO ou qualquer outra pessoa. Apesar de muitas vezes serem tratados de forma urgente e prioritária, podem também compor o Backlog e aguardar sua priorização.

O Dono do Produto deve entender muito bem o dano e imagem negativa que cada bug representa a este produto e quantificar o seu valor de correção em concorrência aos demais itens no Backlog. Uma vez identificado, o bug é organizado no Backlog e concorre com as demais características a serem melhoradas/corrigidas no produto.

Requisitos não funcionais

Requisitos não funcionais estão relacionados ao uso do produto em termos desempenho, disponibilidade, usabilidade, confiabilidade, segurança, manutenibilidade, eficiência, padrões, UX, normas legais e tecnologias envolvidas.

Estes requisitos estão relacionados sobre COMO o produto deve se comportar para atender suas funcionalidades e características (requisitos funcionais). Esse modo de comportamento também dita a qualidade percebida do produto.

Apesar destes requisitos serem percebidos pelos usuários em termos de qualidade, sua necessidade está implícita à característica do produto. A qualidade não funcional entregue por sistema, serviço ou objeto é o mínimo esperado pelos seus usuários.

Pelo fato de serem implícitos, são raramente tratados em termos de Backlog. Isso faz com que o PO se atente aos critérios de aceite mínimos de cada história ou feature do Backlog para contemplá-los.

Se identificado que o Produto não atende aos requisitos não funcionais expostos acima, estes devem fazer parte da lista do Backlog e priorizados de acordo com o seu valor de negócio e percepção de qualidade entregue aos usuários.

 

Qualidade nos itens de Melhoria do Backlog

Já mostramos anteriormente o Custo relativo para corrigir um defeito:

Por isso, é extremamente necessário reforçar que um Backlog orientado à qualidade também deve visar um levantamento de requisitos completo e bem feito.

 

Pesquisas e levantamento de requisitos

Aplicando técnicas de pesquisa como entrevista com usuários, workshop, brainstorming ou colhendo feedback com a área de relacionamento, é possível capturar reais necessidades que, mais tarde, serão transformadas em solução.

Através das habilidades de comunicação e empática, o Product Owner precisa ter a capacidade de moderar as pesquisas, bem como levantar as dores dos usuários e gerar soluções. Tudo isso vai cooperar para melhor atingimento da qualidade do produto a ser desenvolvimento ou ajustado.

 

Identificação das personas e usuários

O mapeamento da jornada destes usuários, bem como seus gostos, costumes, fluxo de processo que ele fará antes, durante e após interação com minha aplicação é importantíssimo na etapa de análise.

Já vimos por aqui que a qualidade é subjetiva a cada usuário que interage com o produto, pois está relacionada às percepções de cada indivíduo e diversos fatores. Por isso o PO precisa compreender muito bem cada persona e pensar em soluções que satisfaçam a maior parte delas.

 

Conclusão

Quando pensei em escrever esse artigo sobre o Backlog orientado à Qualidade do Produto, imaginei que iria criar um assunto revolucionário. A conclusão é que a aplicação da qualidade em cada item do Backlog não é inovação, mas sim uma premissa.

Não existe uma fórmula ou cálculo de quantos e quais tipos de itens devem ser priorizados. Seja dívida técnica, melhoria, bug ou requisito não funcional, a regra é a mesma: Maximizar o Valor do Produto visando a qualidade e satisfação dos usuários.

Finalizo esse artigo com a definição de qualidade sob a ótica da NBR ISO 8402:

O conceito de qualidade é “A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”.

 

Referências

• https://www.trt9.jus.br/pds/pdstrt9/guidances/concepts/supporting_requirements_B2C4D610.html
• https://www.atlassian.com/br/agile/software-development/technical-debt
• http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
• https://blog.zeev.it/qualidade-produto-qualidade-processo/