Equipes de desenvolvimento de software ágil têm que garantir que os produtos desenvolvidos tenham qualidade suficiente. Gestores frequentemente esperam que a velocidade do desenvolvimento seja gradativamente aprimorada, de forma a entregar um número maior de funcionalidades a seus clientes. Diversos autores exploraram a relação entre qualidade e velocidade e sugeriram maneiras de aprimorá-la.
Bob Galen escreveu sobre a importância da qualidade do software em relação a velocidade no post: "leia os meus lábios - ágil não é rápido".
Agile é um "Jogo de Qualidade " que se você jogá-lo com integridade, compromisso e equilíbrio, pode se tornar um incrível "Speed Play" (Jogador Veloz). Mas (velocidade) não vem de graça[...] Se você não jogar bem, sua adoção ágil pode até ser mais lenta que suas abordagens anteriores!
As equipes devem se comprometer a terminar o trabalho ao fim de uma iteração, o que implica atender a todos os critérios em sua definição de pronto:
Muitas equipes ágeis permitem que retrabalho, reparos de bugs, término da automação de teste, refatoração, ou designs pobres escapem de um sprint para outro. Mesmo a maioria das ferramentas ágeis permitem dividir histórias para capturar o trabalho que foi feito no sprint contra o trabalho adiado. Eu acho que isso envia uma mensagem errada para as equipes. Esse trabalho desviado para além do Sprint é aceitável.
Leia os meus lábios: isto não é aceitável! O Done (pronto) deve ser done mesmo!
Organizações não devem se esforçar para se tornarem mais rápidas, mas sim se concentrar em qualidade como Bob explica:
Então, da próxima vez que você ouvir alguém falando sobre implicações de velocidade do agile e deixar seu entusiasmo juvenil tomar conta da discussão, por favor, pare-o. Tente explicar que Agile não é um "jogo de velocidade", mas sim um "jogo de qualidade" que pode habilitar a uma maior velocidade.
Tim Ottinger escreveu em relação deste assunto no post "14 estranhas observações sobre a velocidade de um time no Agile". Uma de suas observações foi sobre a relação entre qualidade e velocidade:
Embora as pessoas muitas vezes reduzam a qualidade para fazer as coisas de forma mais rápida (no curto prazo), a velocidade em todos os sprints é reduzida caso a equipe encontre um código de baixa qualidade.
Velocidade não é um objetivo ou meta", Stephen Haunts descreve o que pode acontecer com a qualidade, quando os gestores estabelecem metas para a velocidade de suas equipes:
(...) de modo a entregar mais pontos para atingir uma determinada meta, a equipe sacrificará a qualidade do sistema, o que retarda a equipe no longo prazo e introduz dívida técnica. Você estará melhor situação se focalizar a qualidade do sistema que você está construindo, juntos dos processos (entrega e integração contínua, etc.) e as pessoas que constroem o sistema.
Os desenvolvedores de software precisam encontrar o equilíbrio entre a velocidade e a qualidade, como explica Blake Haswell no post "O que é a qualidade do código":
Muitas vezes há uma grande pressão externa para se inclinar em direção da velocidade, no entanto, se você não prestar atenção suficiente à qualidade, sua velocidade ficará paralisada e seu projeto poderá desmoronar. Dado que a qualidade do código de um projeto determina a facilidade com que este pode ser adaptado aos requisitos de mudança, desta forma, a coisa mais sensata a se fazer é passar uma parte de seu tempo cuidando da qualidade do código do seu projeto.
Blake apresenta uma lista de atributos qualitativos que podem ser utilizados para discutir a qualidade do código:
- Compreensíve: Código deve ser fácil de entender em todos os níveis. O ideal é que o software deva ser tão simples que seja simples de perceber que não existem deficiências.
- Testável: Código deve ser escrito de forma que seja facilmente testável.
- Correto: Código deve atender aos requisitos funcionais e não-funcionais.
- Eficiente: Código deve fazer uso eficiente dos recursos do sistema (memória, CPU, conexão de rede, etc.).
No post, "Os sintomas internos da baixa qualidade do software", Hugo Baraúna explica como o software pode "deteriorar" devido a mudanças, resultando em menor qualidade e velocidade:
Imagine que você está liderando a equipe de tecnologia ou produto de uma startup; você é o CTO. Você já lançou a primeira versão do seu produto e foi um sucesso. Seu modelo de negócio foi validado e, agora você está em uma fase de crescimento. Isso é incrível! Mas tem os seus custos e, trarão um novo conjunto de desafios. A primeira versão de seu produto está funcionando, mas a base de código não está da maneira que você vai precisar de agora em diante. Talvez a velocidade de sua equipe não é tão boa como deveria ser. Sua equipe continua reclamando da qualidade do código. O CEO e o diretor de produto deseja novos recursos, contudo suas projeções atuais não vão ao encontro das necessidades do negócio.
Ele fornece uma lista de sintomas indicando baixa qualidade, que te ajuda a decidir se é necessário reescrever ou refatorar:
- Tudo está difícil;
- Baixa velocidade;
- Suíte de testes lenta;
- Bugs que não desaparecem;
- Sua equipe está desmotivada;
- Conhecimento isolado em determinados membros do time;
- Demora para um novo desenvolvedor começar produzir;
E você leitor, como você equilibra qualidade e velocidade?