Alisson Vale

Em desenvolvimento ágil, é muito comum as equipes estabelecerem uma espécie de "comprometimento de sangue" com seus clientes em se entregar tudo que foi planejado no início de uma iteração. Pode haver muita boa vontade nisso, mas certamente é uma prática pouco eficiente. Mas porquê é ruim criar um compromisso para entregar o que foi planejado? Quando um compromisso é estabelecido, não cumpri-lo pode resultar em frustração tanto do cliente quando da equipe e de sua liderança. O que ocorre na prática é que não há garantia de que os requisitos planejados no início de uma iteração realmente poderão ser concluídos até o seu final. 

Se a liderança do projeto, ou o cliente, estabelecerem uma relação de cobrança para com a equipe no que diz respeito a entrega ao fim de uma iteração dos requisitos planejados e acordados no seu início, fatores indesejáveis poderão atuar negativamente no processo, entre eles: (1) o aumento de trabalho over-time e do stress no dia-a-dia de trabalho; (2) a equipe começa a super-estimar as features com medo de assumir compromissos irreais (3) a  qualidade pode começar a ser sacrificada; (3) relaxamento na execução das práticas e (4) em um atraso iminente, a equipe começa a evitar o acionamento do cliente para obtenção de feedback (pois isso pode significar mais trabalho para ser entregue no mesmo tempo).

O que fazer então? Sem metas rígidas, como gerar ritmo e obter alguma previsibilidade no projeto? O segredo é não tentar impor controle sobre o processo, mas estudá-lo e observá-lo com o intuito de se ganhar a capacidade de aperfeiçoá-lo sistemicamente. O objetivo é conquistar (e não controlar) o ritmo e a previsibilidade desejada. Se as metas de implementações para a iteração continuamente não são alcançadas, pode ser que:

• As metas estão sendo mal-definidas (consciente ou inconscientemente). Normalmente devido ao desconhecimento da capacidade real de produção da equipe. Às vezes tenta-se impor metas mais arrojadas para tentar puxar o ritmo da equipe, mas o resultado acaba sendo pior;
• Os requisitos foram insuficientemente explorados durante a reunião de planejamento. Apesar de não ser uma boa prática detalhar em excesso o que será desenvolvido, é importante conhecer o suficiente sobre o que será desenvolvido, de modo a diminuir a margem de erro nas estimativas. Isso pode ocorrer quando as reuniões de planejamento são rápidas de mais ou muito superficiais;
• Eventos não planejados (veja "variações especiais" mais a frente no texto) ocorreram durante a iteração diminuindo a capacidade de produção da equipe.

Em todos os 3 casos, a culpa não é da equipe. Não adiantará, portanto, pressioná-la ou influenciá-la para produzir mais. Todo o projeto é um sistema. Sistemas que produzem abaixo do esperado, o fazem devido a causas sistêmicas, não pela existência de um ou mais "culpados".  Todo o sistema tem um rendimento e esse rendimento, segundo Deming, sofrerá de variações causadas por causas comuns ou por causas especiais. Especialmente quando falamos em projetos de software, há variações inerentes ao sistema e há variações especiais  que tornam seu rendimento imprevisível, mas controlável. O ato de medir esse rendimento continuamente gera o controle estatístico necessário para nos dar a condição de prever resultados com muito mais acuracidade do que os planejamentos adivinhatórios e impositivos que estamos acostumados a  ver. Assim, as expectativas devem ser trabalhadas com base em medições e não com base em compromissos irreais.   

Durante o estudo e a observação do sistema da qual faz parte o projeto, será possível detectar variações especiais, removê-las e, assim, otimizar seu rendimento. Quando todas as variações especiais forem removidas, o sistema poderá ser otimizado como um todo e, aí sim, haverá uma melhoria substancial na sua capacidade de avançar com mais velocidade, mantendo o alto nível de qualidade desejado.  Um projeto observado e aperfeiçoado com uma visão sistêmica pode oferecer muito mais controle e previsibilidade do que um projeto gerenciado com metas impostas de cima para baixo. 

Talvez as questões de garantia de qualidade estejam dentre os assuntos mais misteriosos para aqueles que ainda estão começando a trilhar os primeiros passos em métodos Ágeis. Muito se fala em testes de aceitação, TDD, testes unitários, mas é só isso? Qualidade em projetos ágeis se assegura somente com testes automatizados?

A resposta é não. Essas técnicas são importantes, mas há todo um universo conceitual por trás dos projetos ágeis que poderão lhe ajudar a não só explicar como isso se dá, mas também a aplicar pequenas melhorias que podem causar grande repercussão no seu processo. 

O primeiro ponto a se entender é que qualidade é um meio não um fim. A idéia é não procurar montar um processo cujo objetivo seja gerar um produto de qualidade. O ideal é fazer com que a própria busca pela qualidade oriente a formação do seu processo.

A forma como um projeto ágil lida com qualidade está muito sintonizada com as idéias de Edward Deming e com o modelo de administração e gerenciamento oriental (muito influenciado por ele). O modelo ocidental lida basicamente com o uso de inspeções em massa para assegurar qualidade. O mesmo modelo é utilizado pelos processos tradicionais de desenvolvimento de software. A idéia é mais ou menos a seguinte: Depois que está tudo pronto, vamos testar pra ver se funciona. Talvez por isso a idéia de se criar testes antes de se escrever o software seja considerada tão "excêntrica" por aqueles que ainda não conhecem a abordagem ágil. O modelo mental de se testar só depois que algo é considerado pronto é muito forte. Não foram poucas as vezes que eu ouvi me dizerem: "Mas pra quê eu vou testar agora se ainda não está pronto?"

Assim, para entender como se garante qualidade em projetos ágeis, há 5 pontos que acho serem fundamentais:

1. Não depender de inspeções para garantir qualidade: Se você inspeciona seu software com a expectativa de encontrar defeitos, seu processo ainda não tem qualidade. Então, invista em qualidade durante a produção, não depois. Inspeções são ineficientes porque não previnem o problema, apenas o encontram. Em quê ajuda encontrar um erro em uma inspeção? O erro já está lá! Inspeções são necessárias, certamente não vamos conseguir viver sem elas tão cedo. Mas encontrar erros em uma inspeção no final do processo é desperdício. Considere que há duas maneiras de evitá-las ou reduzir a dependência que você tem delas:

• Inserindo qualidade no produto. Aqui entra a figura dos testes automatizados.
• Antecipando as inspeções de modo que elas aconteçam antes que um defeito seja inserido no produto. Como? Muitas práticas ágeis já ajudam muito, cada uma da sua forma: Integração Contínua, times multi-disciplinares, shared workspaces,  daily meetings, pair programming, TDD, code e design Inspections e outras. Cada prática dessas traz consigo uma diferente forma de inspeção. Você também pode ajudar fazendo testes durante o processo de produção, não depois. Um exemplo é chamar alguém para testar o que foi feito, antes que o software saia da máquina do desenvolvedor. É o melhor momento para se encontrar um problema.  Se deixarmos pra testar tudo no final de uma iteração, as chances de não entregar nada no final são grandes.

2. Valorize a prevenção, não a detecção. Encontrar um defeito não pode ser algo comum. O processo de prevenção deve ser revisado imediatamente. A equipe não deve ir adiante enquanto houverem defeitos. Há várias formas de se trabalhar com prevenção, uma delas é a automação. Por exemplo, automatizar o deploy e a instalação do seu software é investir em prevenção. Um grande número dos problemas encontrados em ambientes fora da fronteira da equipe estão associados às configurações necessárias para se instalar e rodar o software produzido. Os próprios desenvolvedores devem ser capazes de incorporar os recursos que ele precisa para ser instalado. Assim, é o desenvolvedor que tem que indicar que scripts de banco devem ser rodados e que arquivos de configuração devem receber novas entradas. É comum o uso de uma gerência de configuração para isso. Mas é desnecessário quando há automação. Aqui no nosso projeto, o próprio desenvolvedor que produziu a funcionalidade configura tudo que será preciso ser executado quando da instalação do software. A automação elimina a necessidade de intermediação. Isso aumenta a qualidade porque elimina mais um hands-off do processo.

3. Não confie nas especificações como forma de garantir satisfação dos usuários. Se seu projeto ainda está atrelado à necessidade de se desenvolver para atender uma especificação, saiba que elas não são capazes de contar toda a história. Especificações não são bons instrumentos para descrever como um software deve funcionar. A melhor maneira de aumentar a qualidade que o seu cliente percebe no seu produto é envolvendo-o no processo. Ciclos de feedback geram aprendizado, confiança e ajudam o usuário a encontrar a melhor solução. Seguir uma especificação é separar o problema da solução e direcionar o cliente para apenas descrever o problema, enquanto você fica responsável pela solução. O ideal é que o problema e a solução estejam no mesmo contexto, e que eles sejam trabalhados em conjunto. Se, de alguma forma, o cliente contribuir para a solução, ele não só ficará mais satisfeito, como também se tornará seu cúmplice e o ajudará nos momentos difíceis pelos quais você pode chegar a passar.

4. Qualidade não se controla, se incorpora. Em caso de equipes de projeto, não acredito que bugs aparecem por causa de desenvolvedores ruins (talvez problemas de design ou de performance apareçam por causa de desenvolvedores ruins). Bugs aparecem porque a falta de qualidade do processo permitiu. Assim, medidas de punição ou recompensa, ou qualquer outra abordagem top-down para tentar reduzir bugs não funcionam a longo prazo. É injustificável ficar tentando controlar algo tão precioso - como é o caso da qualidade - quando é possível incorporá-la ao seu dia-a-dia.   

5. Treine a aquisição de habilidades, não o uso dos instrumentos. As pessoas são capazes de se tornarem multi-disciplinares. Basta treiná-las para isso. Você vai incorporar qualidade ao seu processo na medida que investe nas pessoas para que elas adquiram novas habilidades. Assim, treine:

• modelagem, não UML;
• padrões de arquitetura, não Webservices;
• design, não novos recursos da IDE;
• programação pragmática, não novos recursos de linguagem;
• a especificar testes, não a usar ferramentas de testes;

Enquanto que os itens a esquerda geram novas habilidades nas pessoas, os itens a direita podem ser resolvidos com 20 minutos de pesquisa no google.