Um dos aspectos mais importantes de qualquer esforço de equipe é a comunicação. Até mesmo um time de beisebol tem seu próprio conjunto de sinais manuais para os arremessadores e frases para gritar quando uma mosca está à solta. Os mesmos princípios são válidos para qualquer pessoa que trabalhe com desenvolvimento de software – garantir que todos usem uma linguagem compartilhada é de extrema importância, especialmente para a garantia de qualidade. Embora possamos pensar em certos termos como sendo preto e branco, a verdade é que muitas coisas geralmente são deixadas para interpretação. O desenvolvimento de uma linguagem compartilhada só será bem-sucedido se houver patrocinadores executivos que a apoiem e a apliquem. O patrocinador executivo – normalmente um CIO ou CTO – precisa garantir que todas as equipes saibam por que estão fazendo o trabalho e qual é o resultado aceitável. Vamos dar uma olhada em como liderar uma equipe para criar uma definição compartilhada para algumas palavras e expressões comuns na garantia da qualidade do software.
O que é qualidade?
Pense em como você usa a palavra “qualidade” na linguagem cotidiana. Ela sempre significa a mesma coisa? Será que um sanduíche de qualidade tem as mesmas características de uma casa com construção de qualidade? Não, esses termos são definidos com base no uso pretendido do item. O mesmo vale para a qualidade do software. O patrocinador executivo sabe por que o trabalho precisa ser feito com qualidade, mas o restante da equipe não tem a garantia de compartilhar suas definições e expectativas. Antes de uma equipe desenvolver ou testar o código, ou mesmo instalar produtos prontos para uso, ela precisa entender os requisitos desse aplicativo.
O que é um defeito?
Em uma discussão geral, a palavra “defeito” é usada para descrever qualquer problema em um software. Muitas vezes, ela é usada de forma intercambiável com “bug” ou “erro”. Entretanto, na metodologia ágil moderna, o significado é um pouco mais complexo. Em vez de ser qualquer problema com o software, às vezes só é considerado um defeito se o problema for descoberto depois que a funcionalidade tiver sido aprovada por um proprietário de produto. No entanto, se você tiver membros da equipe acostumados com o método em cascata, eles considerarão qualquer erro de codificação como um defeito. A verdade é que alguns defeitos são aceitáveis para o lançamento de um produto se o impacto for mínimo. Ter um entendimento compartilhado sobre quais defeitos precisam ser corrigidos evitará que sua equipe perca tempo com uma correção desnecessária e que lance produtos com padrões inaceitáveis.
O que realmente significa “feito”?
Esse é outro termo que pode parecer binário, mas pode ter vários significados diferentes com base em seu fluxo de trabalho. A metodologia em cascata diz que o projeto está pronto depois de ter sido analisado, projetado, codificado e testado. Entretanto, em um fluxo de trabalho ágil, há vários componentes criados durante cada etapa de um sprint. Como tudo está sendo feito com integração e implantação contínuas, usamos o conceito de Definição de Pronto para confirmar se algo foi concluído e está pronto para entrega. Cada tarefa terá a sua própria Definição de Pronto, o que significa que a equipe pode entregar algo que acha que está concluído quando o Patrocinador Executivo sabe que não está nem perto disso.
Sua equipe funciona melhor quando todos trabalham juntos. Não importa quantos exercícios de formação de equipe, passeios ou festas com pizza você faça, se não houver uma linguagem compartilhada, você estará morto. Um Patrocinador Executivo deve pegar as expectativas que ele conhece e usá-las para informar uma linguagem compartilhada para cada etapa do desenvolvimento, da integração e da implementação do software. Caso contrário, vocês podem acabar deixando que aquela bola no centro se transforme em uma derrota no jogo.
