Desenvolvimento Ágil: 20 anos e 10 desafios

Em fevereiro de 2001, o Manifesto Ágil era publicado. O curto documento foi resultado dos muitos anos de experiência de seus dezessete autores na área de desenvolvimento de software, se tornando um divisor de águas nessa área profissional. O manifesto não criou novas práticas e metodologias, mas ajudou a direcionar o foco da comunidade para métodos iterativos, incrementais e com baixos níveis de burocracia corporativa. Oficializou-se ali a defesa do conjunto de práticas e princípios que ficaria conhecido como Desenvolvimento Ágil de Software.

Desde então, o desenvolvimento ágil foi adotado com diferentes níveis de sucesso por diferentes tipos de organizações. O que se manteve estável, obviamente, foi a natureza humana. Por mais que as práticas ágeis nos incentivem a questionar nossas próprias decisões e a sempre buscar a melhoria contínua, nossos vieses cognitivos quase sempre nos levam a tentar confirmar que nós já estamos certos e que os métodos que utilizamos já são os melhores.

Essas tendências levaram ao surgimento das mais diversas corruptelas dos métodos ágeis de desenvolvimento. Enquanto as boas práticas são teoricamente adotadas, as práticas/decisões diárias muitas vezes se mantêm mais próximas de métodos defasados (ou mesmo arcaicos) de trabalho. Por mais que as técnicas de desenvolvimento de software tenham evoluído, as demandas de mercado e os estilos gerenciais dificilmente tendem a acompanhar essas evoluções.

Os dez pontos listados abaixo falam um pouco sobre as principais limitações técnicas, metodológicas e gerenciais existentes em muitas organizações atuais, por mais que elas tenham adotado (ou tentado adotar) a filosofia ágil. Note que esses pontos são balizados por alguns dos doze princípios do desenvolvimento ágil.

1. Reflexão vs Burocracia

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Quando os ritos associados aos diversos métodos de desenvolvimento ágil (como reuniões de planejamento, dailies, retrospectivas, etc.) não dão os resultados que deveriam, muitas pessoas começam a questionar a necessidade desses ritos ao invés de questionar a forma de execução deles.

Por exemplo, se as reuniões de retrospectiva não estão sendo capazes de realmente gerar melhorias no processo, os membros da equipe podem passar a vê-las como mera burocracia e tentar eliminá-las. Porém, é preciso avaliar se elas realmente se tornaram desnecessárias (o que significa que as reflexões sobre pontos de melhoria estão sendo feitas em outro momento) ou se elas não estão sendo executadas com um nível adequado de profundidade e sinceridade.

No momento de falar sobre pontos de melhoria, a nossa tendência é a de sempre tentar apontar falhas em fatores externos antes de buscar pontos de ajuste em nosso próprio comportamento. Porém, o contrário é o mais recomendado, pois, na maioria das vezes, é mais fácil alterar fatores internos do que os externos. Uma vez que os fatores internos já foram todos abordados, aí sim os fatores externos devem se tornar o foco.

Isso exige um alto grau de maturidade, pois os membros da equipe precisam ser absolutamente sinceros não apenas uns com os outros, mas também com si próprios.

2. Equipe vs Conjunto de Pessoas

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Nem sempre uma equipe se comporta como uma equipe. Por exemplo, se os membros de uma equipe trabalham em atividades diferentes, com prioridades diferentes e se comunicam o mínimo possível, então isso não é realmente uma equipe. Eles podem até ser colegas de trabalho alocados em um mesmo projeto, mas não funcionam como um time. Nesses casos, é comum que cada membro trabalhe de forma completamente isolada, sem sincronia com os outros e sem uma visão clara de um objetivo em comum.

Além disso, a ideia de equipe auto-organizável pode fazer muitos líderes caírem em armadilhas. Se a equipe realmente é capaz de tomar decisões técnicas e dividir o trabalho entre os membros, isso é ótimo. Em caso contrário, o que vai acontecer é que a equipe supostamente auto-organizável ficará sem rumo e cada membro tentará “remar o barco” em uma direção diferente, podendo até gerar conflitos internos. A gerência precisa ser capaz de identificar essas situações e intervir no sentido de guiar as decisões e o processo de amadurecimento do time.

3. Comunicação vs Telepatia

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Cada membro de uma equipe precisa saber quais são as atividades dos outros, quais são os contextos dessas atividades e como elas se encaixam nos objetivos em comum do time. A ideia é que qualquer membro da equipe seja capaz de atuar, sugerir melhorias ou solucionar dúvidas nas atividades dos outros membros. Pessoas diferentes possuem níveis e tipos diferentes de experiência, e não faz sentido privar um membro de um time das experiências dos outros.

É importante que a comunicação ocorra da forma mais clara e explícita possível, sem deixar detalhes implícitos ou subentendidos. Muitas vezes, alguns dos membros de uma equipe podem partir do pressuposto de que outros membros já têm ou já deveriam ter um determinado conhecimento, sem se preocupar em transmiti-lo. É como se a pessoa precisasse saber, mas ninguém precisasse ensinar. Para evitar isso, é importante que os líderes e os membros mais experientes identifiquem gaps de conhecimento e lidem com eles de forma direta e decisiva.

Também é comum o erro de querer que novos membros do time aprendam as coisas da mesma forma que os membros mais experientes aprenderam. Por exemplo, se um membro mais experiente teve que quebrar a cabeça e se virar para aprender uma nova tecnologia, espera-se que os novos membros passem pelo mesmo processo (e pelos mesmos traumas) e cometam exatamente os mesmos erros até chegar ao mesmo nível de conhecimento.

Isso é um grande desperdício de recursos, pois os membros mais experientes poderiam ajudar os novatos a não cometerem os mesmos erros, o que os deixaria livres para cometer erros novos e gerar novos aprendizados para a equipe.

Em outras palavras, ao invés das “técnicas” do “ir aprendendo” ou “aprender por osmose”, é preciso haver um esforço planejado e didático para capacitar novos membros e diminuir as curvas de aprendizado.

4. Decisões de Negócio vs Decisões Técnicas

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Ainda existem os líderes de negócio que acreditam na diferenciação simples entre decisões de negócio e decisões técnicas, como se as áreas de TI fossem apenas os “bastidores” (ou a “cozinha”) da organização. Porém, a partir do momento no qual as decisões técnicas podem ser decisivas no sucesso ou no fracasso dos negócios, essa diferenciação não deveria existir.

Como regra geral, pode-se dizer que, enquanto ainda existem decisões de negócio que não possuem impacto técnico, todas as decisões técnicas possuem algum impacto no negócio, seja em termos de custos ou de qualidade na entrega para os clientes finais.

Além disso, a integração entre áreas de negócio (como produtos, atendimento ao cliente, comercial, etc.) e áreas técnicas também é vital para que as soluções para eventuais problemas sejam as melhores possíveis, combinando resolução técnica com comunicação com o cliente e estratégia de negócios.

Inclusive, é importante que as soluções adotadas por uma área sejam revisadas e questionadas por outras, pois algo que faz sentido tecnicamente pode não fazer sentido comercialmente, por exemplo. Da mesma forma, existem as decisões de negócio que não fazem sentido do ponto de vista técnico.

É importante que as equipes técnicas comuniquem riscos e limitações da forma mais clara possível para os executivos e para os demais gerentes de negócio, garantindo que a alta gestão não tome decisões completamente descoladas da realidade técnica dos projetos.

5. Gerente vs Mestre dos Magos

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessários e confie neles para fazer o trabalho.

Tipicamente, as tarefas de um programador se resumem a escrever comandos para processar dados e gerenciar recursos computacionais de uma forma que atenda as necessidades da organização. Além disso, ele deve combinar seu entendimento do negócio com seu entendimento das tecnologias para desenhar soluções que possam ser facilmente mantidas, escaladas e evoluídas. As tarefas dos gerentes de pessoas e de projetos são semelhantes, com a diferença de que, ao invés de levar em conta os recursos computacionais, eles precisam levar em conta os recursos humanos.

Os gerentes de tecnologia, de projetos e de pessoas precisam conhecer e entender os perfis dos membros da equipe e saber o que pode ser esperado de cada um deles. Mais que isso, a gerência precisa deixar claro o que é esperado da atuação de cada colaborador e prover as condições necessárias para que eles façam as entregas esperadas.

Ou seja, não basta ser um Mestre dos Magos; é preciso planejar, organizar, dirigir e controlar.

Se uma equipe não consegue fazer as entregas esperadas, o gerente não pode questionar apenas as escolhas feitas pela equipe, mas também as escolhas feitas por ele mesmo. As restrições de tempo e de outros recursos foram adequadas? Os perfis técnicos/comportamentais da equipe e de cada um de seus membros foi levado em conta? A equipe foi alocada para um projeto que corresponde ao seu perfil? Os gaps técnicos foram identificados e sanados?

Por mais que muitos dos gerentes atuais sejam bem compreensíveis e entendam as muitas complexidades envolvidas em um projeto de software, é preciso ter cuidado para que não se fique tão acostumado com os fracassos que se esqueça de potencializar as chances de sucesso.

6. Missão vs Construção

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Os gerentes que não têm a capacidade de (ou não estão interessados em) desenvolver e gerenciar equipes de desenvolvimento ágil acabam ficando dependentes de “super-desenvolvedores”. Esse tipo de desenvolvedor é bem conveniente para uma gerência mais distante, que se limita a dar uma “missão” e espera que, de alguma forma (ou de qualquer forma), ela seja cumprida. Isso significa que o “super-desenvolvedor” fica regularmente sobrecarregado e, muitas vezes, abandonado à própria sorte.

Os principais resultados disso (além de uma inevitável síndrome de burnout) são entregas ineficientes e de baixa qualidade, que irão funcionar relativamente bem por algum tempo e logo começarão a gerar problemas emergenciais. Esses problemas serão tratados o mais rápido possível, de formas improvisadas e sem levar em conta o longo prazo.

Essas resoluções, por sua vez, vão causar mais problemas emergenciais e um ciclo tóxico será estabelecido. Cada um dos problemas que ocorrem periodicamente será tratado como um caso isolado, ignorando-se o padrão de “problemas pontuais” que ocorrem toda semana ou todo mês.

Uma abordagem mais adequada não lida com o desenvolvimento de software como uma “missão”, mas sim como uma “construção”. Além de se estabelecer uma arquitetura bem planejada e revisada por várias pessoas, é preciso garantir que os alicerces serão bem estabelecidos e que as técnicas e ferramentas utilizadas serão as mais adequadas. Em um desenvolvimento iterativo e cadenciado também será possível revisar as decisões tomadas anteriormente e se adequar a eventuais mudanças nos requisitos.

7. Planejamento vs Reação

Contínua atenção à excelência técnica e bom design aumentam a agilidade.

O “desenvolvimento orientado a emergências” também provoca a criação de “bombas-relógio”: pedaços do software ou da arquitetura da solução que vão sendo negligenciados enquanto os desenvolvedores estão indo de uma emergência para outra. Os pontos negligenciados só vão receber alguma atenção quando finalmente “explodirem” e se tornarem a emergência da vez. Sem planejamento e reflexão, a tendência é que essa dinâmica se mantenha até o ponto no qual ocorra um erro do qual não é possível se recuperar.

Também é necessário levar em conta que, na maioria dos casos, um software não é algo que pode ser deixado de lado depois de ficar “pronto”. Em sistemas de missão crítica, a implantação de uma feature em produção está longe de ser a fase final de seu ciclo de vida. As disciplinas de SRE e DevOps surgiram justamente para aumentar a integração entre as equipes de desenvolvimento e as equipes de operação. Há, inclusive, os casos nos quais a própria equipe de desenvolvimento também é a responsável pela operação.

8. Qualidade vs Otimismo

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

As entregas constantes que se esperam de uma equipe de desenvolvimento ágil só são viáveis quando há a segurança provida por processos de garantia de qualidade confiáveis e bem estabelecidos. Sem eles, cada deploy se torna uma aposta na qual o futuro da organização está em jogo. Ao contrário do que muitos ainda pensam, garra e pensamento positivo não são substitutos válidos para testes funcionais e não-funcionais que sejam capazes de cobrir tanto os cenários “felizes” quanto os adversos.

Dessa forma, a existência de profissionais focados no controle de qualidade não é apenas algo “recomendável” ou “uma boa ideia”. Esse tipo de atuação é fundamental para viabilizar todo o processo de desenvolvimento de software. Dada a natureza subjetiva dos seres humanos e a natureza exata dos sistemas computacionais, que entendem os nossos comandos mas não as nossas intenções, contar com a sorte na área de TI significa contar com a toda a inclemência da Lei de Murphy.

9. Esforço vs Inteligência

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.

Há quem acredite que programador bom é programador preguiçoso. Isso porque o programador “preguiçoso” é aquele que faz o máximo possível para automatizar tarefas chatas e repetitivas, otimizando o uso de seu tempo e do tempo da equipe.

Por exemplo, ao invés de editar manualmente as centenas ou milhares de linhas de uma planilha, um programador “preguiçoso” tende a escrever um script que seja capaz de executar as alterações. Se a execução de tal script também se tornar uma tarefa repetitiva, então outros mecanismos podem ser configurados para disparar automaticamente o processamento dos dados.

Em nível organizacional, um produto do tipo MVP até pode ser desenvolvido com base em processos manuais. Os problemas tendem a surgir quando o produto viável mínimo passa a ser tratado como um produto final. Nesses casos, ao se tentar estender e escalar o software, também se estende e escala os processos manuais e o esforço humano para o sistema continuar funcionando. O que também pode ocorrer é a tentativa de melhorar o software às pressas, o pode resultar na criação das já citadas “bombas-relógio”.

Quando o desenvolvimento é feito sem planejamento e sem reflexão, a tendência é que a equipe precise aplicar cada vez mais horas de trabalho sem necessariamente aumentar o retorno final. O gerente inexperiente vai achar que a solução para isso é contratar mais pessoas e aplicar ainda mais horas de trabalho no problema. Na maioria das vezes, a verdadeira solução é trabalhar de forma mais estratégica e inteligente.

10. Intenção vs Realidade

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

Uma das maiores causas do fracasso na implantação de metodologias ágeis é a simples falta de experiência com as metodologias ágeis. Equipes que já trabalhavam há anos de formas menos equilibradas vão sempre tender a continuar trabalhando dessas formas. Ou pior: elas tentarão adotar o desenvolvimento ágil não da forma ou com os princípios que foram inicialmente propostos, mas sim com base em visões equivocadas e no que elas acham que o desenvolvimento ágil deveria ser.

Em outras palavras, existe a tendência de “mudar para permanecer igual”.

Ao contrário do que muitos pensam, as metodologias ágeis não oferecem soluções “empacotadas” que irão resolver todos os problemas da organização assim que forem implantadas. O que as práticas e ritos típicos do desenvolvimento ágil oferecem são oportunidades de gerenciamento, aprendizado e amadurecimento que irão levar ao estabelecimento de processos mais controlados, previsíveis e equilibrados.

Tudo isso parece ser muito teórico, abstrato e “paz e amor”. Porém, não existe como desenvolver uma equipe de alta performance e que garanta as necessidades do negócio com base apenas em ferramentas e tecnologias de alta qualidade. A qualidade que realmente importa é a das pessoas: tanto no nível técnico quanto no nível gerencial, os membros das equipes precisam estar dispostos a rever suas próprias ideias e atitudes enquanto buscam a excelência e o sucesso profissional.

Além do Desenvolvimento Ágil

Diante desses e de outros desafios na adoção do desenvolvimento ágil, propostas alternativas ou complementares já foram elaboradas. Uma das mais aceitas é a do Software Craftsmanship, que tenta realçar o caráter “artesanal” do desenvolvimento de software em contraponto às “linhas de produção” que várias metodologias tentam criar. Uma vez que o desenho de arquiteturas e a codificação de soluções envolvem altos graus de subjetividade e criatividade, o desenvolvedor passa a ser visto muito mais como um “artesão de software” do que como um “operário de fábrica”.

Esse é apenas um exemplo de como os valores e princípios do Manifesto Ágil podem ser aprofundados e resgatados mesmo depois de muitos anos de tentativas bem-sucedidas, tentativas fracassadas, críticas, polêmicas e muitas revisões. O importante é nunca esquecer que ferramentas, tecnologias e metodologias podem ser altamente úteis, mas são os seres humanos que desenvolvem o software.

Veja Também:

• Faca Na Caveira: Por Que Desenvolvimento de Software é Diferente de Operações de Esquadrões de Elite
• Mais Braço: Por que Desenvolver Software é Diferente de Colher Cana-de-Açúcar
• 15 Ótimos Filmes sobre Liderança