Olá, pessoal! Nessa série de artigos sobre Agile/Scrum, vou trazer pontos pelos quais acredito que todo Agilista tenha passado quando começou a falar de Agile para alguém ou para um time que segue a linha “no agile here”.

O que todo Agilista sofre:

• Vira motivo de risada: todos dão risada dele e dizem: “ele acha que a metodologia Agile é a bala de prata e vai mudar o mundo”. Na verdade o Agilista que deveria rir, porque ele conseguiu “mudar” e aqueles profissionais que são resistentes a qualquer tipo mudança estão com os dias contados;
• Ser ignorado: todo agilista é ignorado no início;
• No bugs: associam que um agilista acredita que, ao desenvolver um software usando metodologias ágeis, não se cria bugs. Ninguém realmente diz isso, porém a acusação sobre o coitado do agislita é servera;

O que os demais acreditam:

• Que a forma que têm usado até hoje é a correta, senão o projeto não existiria, porém se esquecem que se existe até hoje, talvez seja por consequência;
• Que software sem bug tem algo de errado e que alguma das funcionalidades não foi implementada, pois não é possível desenvolver software sem bug;
• Aumentar a cobertura de unit tests depois do código já escrito é sinonimo de qualidade.

Para começar, vamos falar sobre qualidade externa e interna de quando vamos desenvolver um produto. Vamos lá, me responda com sinceridade: algum cliente seu já pediu para você reduzir um pouco a sua estimativa para entregar alguma tarefa? Se sua resposta foi sim, você já sabe sobre o que vamos falar: como convencer o cliente que a qualidade não é negociável? Vou explicar em detalhes ao longo do artigo.

 Starting

Quem me acompanha aqui ou no twitter, já percebeu que eu tenho me dedicado ao mundo Agile. O que vou falar aqui não está só ligado a ele, mas foi onde eu consegui perceber isso de forma mais face-to-face com o cliente e de certo modo foi onde houve menos questionamentos por parte dele e até uma aceitação de mudanças sem muita discussão. Eu sempre sofri com esse mal (desde da época de freelance) do cliente pedir para mudar uma estimativa, porém ele não queria mudar o escopo dele e sabemos que isso não é nada bom. Mas, como contornar a situação sem gastar muito tempo? Para isso é preciso ter duas coisas bem claras em mente:

• Qualidade externa: aquilo que o cliente vê, tem acesso, que é o front-end, lentidão, etc.
• Qualidade interna: aquilo que o cliente não tem acesso, tais como: refactoring, covertura de testes, code clear etc.

Quando o cliente pede para reduzirmos a estimativa, ele está afetando a qualidade interna, algo como: “Sei que você tem a melhor equipe, com os melhores profissionais, será que não dá para fazer em 1 ou 2 dias a menos (isso aqui dá -16 hrs de trabalho, o que é muita coisa)?”.  Normalmente não dá para mudar isso, pois nós sabemos do impacto. E como  resolver isso?

Resposta ao cliente

Podemos perguntar ao cliente se o escopo não pode ser alterado, que aquela parte onde temos as mensagens iterativas com o usuário não poderia ficar para o futuro e que, por agora, trataríamos com mensagens mais simples possível, por exemplo. Ou mudar o nível de importância, assim isso impactará em outras e saberemos o que deve ser entregue primeiro e isso forçará o product owner mover o backlog. Mas abrir mão da qualidade interna é algo que não deve ser feito, pois já sabemos dos problemas que vamos encontrar e o cliente não vai levar em conta essa redução de estimativa quando os problemas surgirem, principalmente se estes afetarem o “bolso dele”. Pense: “uma vez que se penetra que uma base de código se deteriore, é muito dificil recuperar a qualidade mais tarde”.

Um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, porém um com baixa qualidade interna raramente terá uma qualidade externa alta, ou seja, não dá para construir algo bom se a base está pobre, então daí que dizemos que a qualidade interna simplesmente não é negociável.

Vou ficando por aqui. Espero que tenham gostado.

Abraços, see ya!