Trabalhando como coach Agile, uma questão que aparece com frequência é: "implementamos uma abordagem ágil, e por que não funcionou?"
As pessoas que fazem essa pergunta se sentem realmente confusas. Acompanhei equipes que tiveram bastante trabalho para se reorganizar, reatribuir responsabilidades e redefinir processos, mas se decepcionaram ao perceber que a produtividade e moral pioraram após a adoção de uma metodologia ágil.
Cada organização tem suas próprias disfunções. Ao orientar equipes no uso de uma metodologia Ágil, passo constantemente por um processo de imersão nas equipes para observá-las de perto e compreender como trabalham. Mas, apesar das singularidades de cada equipe, os mesmos padrões se repetem. Em quase todos os casos, as equipes adotam o Agile pois encontram problemas reais como baixa produtividade ou qualidade e esperam que o Agile possa, milagrosamente, resolver esses problemas. O que não percebem é que Agile é uma abordagem sistemática de gerenciamento do desenvolvimento de software. O Agile visa algumas metas difíceis como: satisfazer clientes por meio da "satisfação de requisitos em constante mudança". Gerentes ficam empolgados ao ver essas metas e mal podem esperar para pegar uma carona com o Agile. O problema é que com o Agile vem muito trabalho: reuniões diárias, reuniões de planeamento e reuniões de retrospectiva.
Numa primeira impressão, a visão de um grupo de pessoas gravitando ao redor de um quadro branco pode fazer com que gerentes ingênuos pensem que tudo está funcionando. No entanto, falham em compreender que o Agile não sobrevive sem suporte gerencial e técnico significantes. No pior caso, equipes vão passar a odiar secretamente a carga de trabalho adicional e torcer para que as coisas voltem a ser como era antes.
Questões Gerenciais
Uma equipe, com a qual trabalhei no último ano, caiu na armadilha descrita anteriormente. A equipe era grande e foi dividida em 7 equipes Scrum. É possível imaginar o barulho no escritório a cada manhã com o daily scrum (reunião diária) de cada equipe acontecendo aproximadamente na mesma hora e um scrum do scrum das equipes acontecendo logo na sequência. A gerência estava animada, afinal de contas foi pago um bom dinheiro para que um coach implementasse o Agile.
Mas, logo as coisas começaram a mudar. Participei de algumas reuniões do Scrum durante as semanas seguintes e notei que uma equipe em particular estava continuamente bloqueada pelo mesmo problema técnico por vários dias. A equipe não conseguia avançar e, assim, começou a trabalhar em outra coisa. Isso resultou em uma grande quantidade de código que não podia ser testado e demonstrado.
No Agile, o Scrum Master deve remover obstáculos. Quando consultado, o Scrum Master desta equipe estava bastante frustrado. Apenas algumas pessoas da equipe compreendiam os detalhes técnicos relevantes para solução do problema, mas essas pessoas não faziam parte desta equipe neste scrum. Essas pessoas foram alocadas em equipes responsáveis pelo desenvolvimento de outras funcionalidade pela gerência.
Estes são alguns dos problemas típicos em equipes de desenvolvimento de software:
- O Agile defende que todos podem escolher qualquer tarefa do backlog, mas na realidade, algumas tecnologias pouco conhecidas são dominadas por apenas algumas pessoas. É difícil motivar outras pessoas a estudar e aprender essas tecnologias, especialmente quando se trata de tecnologias ultrapassadas. Mesmo pessoas que estão motivadas, quando se deparam com um backlog muito grande, tem dificuldade de resistir a urgência de resolver outros problemas para diminuir o backlog.
- O Scrum Master tem de mover montanhas para permitir que sua equipe evolua sem distrações. Na realidade, o Scrum Master frequentemente não tem o poder para garantir a eliminação dos bloqueios. Esse poder usualmente está com os gerentes e, como todos sabemos, o poder é viciante e é difícil abrir mão dele. Na prática, não aconselho organizações a realizarem mudanças no papel de seus gerentes caso exista resistência da parte destes em relação a mudança. Se um gerente se adéqua ao perfil de um Scrum Master, é perfeitamente possível que assuma algumas das responsabilidades de um Scrum Master: um gerente, normalmente tem maior experiência em adquirir recursos e gerenciar conflitos especialmente conflitos com outras equipes ou organizações.
No entanto, a equipe tinha problemas maiores. O gerente iniciou o desenvolvimento de uma funcionalidade separada e privada colateralmente - não havia nenhuma equipe Scrum alocada para nova funcionalidade e não era possível estabelecer seu progresso. Depois de sondar um pouco mais, descobri que as equipes de P/D e Produto não confiavam uma na outra. O gerente da equipe de produto "ordenou" à equipe de P/D que fizesse algumas coisas, mas a equipe de P/D reservou recursos para trabalhar em outras coisas que consideraram ser mais importantes.
Reunimos a equipe de gerenciamento de P/D e desenhamos o seguinte diagrama de causa e efeito em um quadro branco:
(Clique para aumentar a imagem)
O diagrama de causa e efeito é uma ferramenta poderosa. Enquanto os gerentes reclamavam que o Agile não funcionava para eles, o diagrama mostrava claramente que a raiz do problema estava em aspectos mais profundos. O digrama também tinha ciclos, que mostravam que, se a raiz do problema não fosse resolvida, vários outros ciclos viciosos continuariam.
Questões Técnicas
A equipe em questão agora, tinha completo apoio da gerencia, mas mesmo assim as coisas não funcionaram bem. Em particular, a integração contínua sempre falhava. A equipe tinha configurado uma tela grande para mostrar o status da integração contínua bem na entrada do escritório de forma que todos que estivessem entrando ou saindo pudessem saber o status atual do projeto. O status estava "verde" em média de 1 à 2 horas por dia. Isso, claro, reduziu muito a velocidade de progresso da equipe. Havia a regra de que o código não devia ser enviado ao repositório a não ser que a tela estivesse verde. No entanto, uma vez que as falhas eram frequentes, algumas pessoas enviam seu código para o repositório de qualquer forma, descumprindo a regra.
Gostamos de pensar que o desenvolvimento de software é diferente da manufatura tradicional. O desenvolvimento de software é mais "intelectual" em comparação com o ambiente tradicional da manufatura no qual trabalhadores apenas apertam parafusos sem pensar muito (isso remete ao filme Tempos Modernos de Charlie Chaplin). Na realidade, o desenvolvimento de software também é uma linha de montagem. No entanto, essa linha de montagem do software incorpora muitas iterações que servem para melhorar a qualidade do software. Como qualquer linha de montagem de manufatura, se uma dessas iterações tem uma redução de velocidade, haverá acumulo de trabalho e toda linha de produção vai diminuir sua velocidade.
Para essa equipe, a linha de montagem no nível da funcionalidade se parece com o representado no diagrama abaixo:
(Clique para aumentar o tamanho da imagem)
A linha de montagem tem muitos ciclos de realimentação. Quanto mais curto o ciclo de realimentação, melhor, pois o custo de corrigir erros também é menor. Os ciclos de realimentação entre "demonstração" e os passos de requisitos ou implementação são muito longos. Idealmente o ciclo de realimentação para os requisitos deveriam sempre vir de implementação e teste local. Mas, sempre há defeitos que não são descobertos nessa etapa, de forma que confiamos na automação de testes e no testes do controle de qualidade para fornecer informações de realimentação. Mas, no caso desta equipe, o processo de automação de build e deploy estava com sérios problemas. O problema se tornou ainda maior uma vez que as pessoas começaram a ignorar as regras e enviar código para o repositório, mesmo quando o status era vermelho, correspondendo a uma falha no processo de automação de build e deploy. Dessa situação resulta o congestionamento da linha de montagem.
Expliquei o conceito de linha de montagem para a equipe. Rapidamente surgiram ideias para ajustar a linha de montagem, incluindo o reforço das revisões de código e da regra de envio de código para o repositório. De qualquer forma, no quesito automação de testes, as opiniões dos membros da equipe divergiram. Alguns acreditavam que a automação de testes era impossível de se manter uma vez que o código fora escrito por terceiros com os quais a equipe perdeu contato. Se gastava mais tempo corrigindo bugs do código de teste do que na correção de bugs identificados pelo código de teste. Outros afirmaram que apesar da automação de testes apresentar problemas, era melhor do que nada e que o custo para reescrevê-la não poderia ser absorvido pelo controle de qualidade.
Pedi à equipe para fazer um cálculo simples de forma a determinar o mérito da automação:
Defeitos encontrados pela automação/bugs encontrados na regressão
O resultado foi que parte da automação de testes era muito boa, especialmente alguns testes unitários e testes de componentes, mas o resultado da automação fim-à-fim de interface de usuário foi miserável. A conclusão era clara: não era interessante investir tanto esforço em algo que trazia tão pouco benefício.
Também enfatizei que escrever e manter testes automatizados não era responsabilidade apenas do Controle de Qualidade. O código de testes fim-à-fim de interface é completamente dependente do código em produção. Em uma arquitetura orientada a serviços, se um serviço precisa mudar suas APIs, deveria notificar todos os serviços dependentes de forma que as mudanças necessárias sejam feitas por todos. O código de testes de elementos de interface depende completamente do código em produção: se o id ou nome de um elemento muda em produção, os testes de interface falham.
Para que a automação de testes seja robusta e flexível, o framework de automação tem de ser bem projetado. Terceirizar esse serviço não vai permitir a garantia de um framework bem projetado. Fazer com que o Controle de Qualidade escreva a arquitetura de automação também pode ser um problema. Depende das habilidades técnicas e dos tipos de Controle de Qualidade a serem executados. Para essa equipe, ficou óbvio que os engenheiros de Controle de Qualidade não tinham as habilidades avançadas necessárias em projeto de arquitetura de forma a projetar esse framework.
Assim, ficou decidido que os líderes técnicos de desenvolvimento escreveriam o framework de automação e que os membros da equipe das áreas de desenvolvimento e de controle de qualidade seriam responsáveis por manter a automação de testes de interface juntos. Esse acordo incluiu regras como: desenvolvedores não podem mudar ids ou nomes de elementos de interface a seu bel prazer.
Pode-se pensar que tudo isso aconteceu em apenas uma reunião tranquila. Na verdade, foi necessário muito suporte da gerencia e quase três meses de trabalho escrevendo um framework de automação que fosse rápido, estável e fácil de usar para escrever testes - é assim que resolvemos os problemas reais da vida.
O Ágil é uma abordagem sistemática para gerenciar o desenvolvimento de software
Precisamos voltar as origens para encontrar a essência do Agile. Em 2001, 17 gurus da área de software criaram o Manifesto Ágil que, em si, não diz o que fazer:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder à mudanças mais que seguir um plano
Eles também criaram 12 princípios, alguns dos quais de fato prescrevem o que fazer (por exemplo, trocar informações através de conversas diretas, pessoas ligadas ao negócio e desenvolvedores trabalhando juntos), mas em sua grande maioria tratam também de valores. Se olharmos com cuidado esses 12 princípios, veremos que eles formam uma pirâmide:
No topo está a meta principal "satisfazer clientes por meio da satisfação de requisitos em constante mudança". Essa meta pode ser atingida realizando "entregas de software funcional frequentemente". No entanto, para entregar software funcional, é necessário suporte técnico e gerencial significativo. Garantir que as mudanças de requisitos não quebrem o sistema é primeiramente um problema técnico: como projetar o sistema de forma que seja flexível e como criar automação para garantir que mudanças não vão quebrar partes do sistema. Para desenvolver habilidades técnicas as equipes devem ser motivadas a aprender a partir de seus erros e a se desenvolver.
Aliás, optei por interpretar a simplicidade referente ao princípio 10 na pirâmide da mesma forma que Steve Jobs ao enfatizar a importância da usabilidade:
"Simples pode ser mais difícil que complexo. Você tem que trabalhar mais para limpar sua mente e, assim, criar algo simples"
A transição para o Agile não é uma jornada fácil. Se não está funcionando, investigue. O Agile pode descobrir problemas fundamentais em sua equipe. Vá para o quadro branco e descubra o que está diminuindo a velocidade da equipe, use ferramentas Lean como diagramas de causa e efeito e os 5 Porquês para descobrir a causa raiz. Descoberta a causa raiz, corrija o problema e usufrua de todos os benefícios do Agile.
Sobre a autora
Chen Ping vive Shanghai, China e concluiu seu mestrado em Ciências da Computação em 2005. Desde então, já trabalhou para Lucent e Morgan Stanley. Atualmente trabalha para HP como gerente de desenvolvimento. No seu tempo livre, gosta de estudar Medicina Chinesa. Seu blog pode ser acessado aqui.