Grandes Empresas

“Agile”1 tornou-se um grande negócio. Liderados, sem dúvida, pela bem-sucedida oferta Certified ScrumMaster da Scrum Alliance, agora vemos centenas, talvez milhares dos chamados treinadores e treinadores “ágeis” e muitas frameworks e métodos concorrentes. Vemos treinamento de liderança “ágil”, ofertas de gerenciamento de projetos “ágeis” e assim por diante.

Bom para a empresa

Agora, muitas, talvez a maioria dessas ofertas não são coisas ruins, pelo menos para a empresa. As organizações que tentam melhorar geralmente melhoram e, portanto, mesmo que as ideias “ágeis” sejam mal aplicadas, tentar quase sempre proporcionará alguns benefícios para a organização. A organização deve, pelo menos, obter maior visibilidade do que está acontecendo, e isso muitas vezes levará até mesmo a gerência menos esclarecida a tomar melhores decisões. Isso é bom, e eu sou totalmente a favor.

Não é tão bom para desenvolvedores

A imagem não é tão atraente para os desenvolvedores, todas as pessoas envolvidas na construção dos produtos que as empresas “ágeis” estão realizando. Quando as ideias “ágeis” são mal aplicadas, elas geralmente levam a mais interferência com os desenvolvedores, menos tempo para fazer o trabalho, maior pressão e demandas para “ir mais rápido”. Isso é ruim para os desenvolvedores e, em última análise, ruim para a empresa também, porque fazer “Agile” mal resultará, na maioria das vezes, em muito mais defeitos e progresso muito mais lento do que poderia ser alcançado. Muitas vezes, bons desenvolvedores deixam essas organizações, resultando em uma empresa menos eficaz do que antes de instalar o “Agile”.

Seguro, não SAFe

Meu pensamento é retirado de algo que Kent Beck disse há mais de uma década. Eu gostaria que o mundo fosse seguro para os desenvolvedores. Na minha essência, sou um desenvolvedor, apesar de anos de gerenciamento, consultoria e escrita. Eu trabalhei com código hoje cedo, e faço isso toda semana, se não diariamente. Então, parte meu coração ver as ideias sobre as quais escrevemos no Manifesto Ágil usadas para piorar a vida dos desenvolvedores, em vez de melhorá-la. Também me entristece que a empresa não esteja obtendo o que poderia com o negócio, mas minha principal preocupação é com as pessoas que fazem o trabalho.

Ao longo de um período de anos, ouvi de muitos desenvolvedores que dizem que “Agile” é uma porcaria. (Geralmente eles dizem que “Scrum” é uma porcaria, porque a maioria das pessoas nas organizações que tentam fazer “Agile” estão em organizações tentando fazer Scrum.) Eu tentei ajudar essas pessoas a entender que sua organização está fazendo “Agile” errado: eles não estão fazendo o que os autores do Manifesto recomendaram, o que o Scrum recomenda, o que os muitos especialistas em Desenvolvimento de Software Ágil recomendam. Minha esperança era que as pessoas ao som da minha voz ajudassem a si mesmas, e suas organizações, a se aproximarem das ideias reais por trás do Manifesto Agile e se afastarem das muitas formas de Faux Agile ou Dark Agile que vemos ao nosso redor.

Isso não está realmente funcionando. Esforços como treinamento e certificações “avançados” do Scrum e esforços focados na liderança são bons e podem dar frutos ao longo do tempo, mas eles procederão, na melhor das hipóteses, lentamente e talvez nunca sejam realmente filtrados para os desenvolvedores pobres nas “Minas de Código de Ohio”.

É hora de tentar algo novo, e aqui está:

Os desenvolvedores devem abandonar o “Agile”

Lembre-se, os desenvolvedores continuarão a trabalhar sob condições Scrum ou em organizações que usam o SAFe. Alguns podem até encontrar abordagens “ágeis” mais obscuras, como “DAD”, ou, se tiverem sorte, abordagens mais esclarecidas, como “Modern Agile” ou “Heart of Agile”. Alguns podem até ter a sorte de se encontrarem fazendo Extreme Programming, também conhecido como “The Scrum That Actually Works”.

Desanexar de métodos nomeados

Seja como for, acredito que os desenvolvedores devem separar seu pensamento de qualquer método “Agile” em particular. Em vez disso, eles devem voltar sua atenção e aprendizado para maneiras de fazer desenvolvimento de software que funcionem dentro de qualquer um desses métodos “ágeis”. Essas abordagens de desenvolvimento, para mim, envolvem o uso de práticas como, mas não se limitando a, as de Extreme Programming. De forma mais geral, o trabalho dos desenvolvedores deve aderir aos princípios fundamentais que apoiam o Desenvolvimento Ágil de Software, como tínhamos em mente quando escrevemos o Manifesto. Hoje, eu resumiria as ideias da seguinte maneira:

Não importa qual estrutura ou método sua gerência acha que está aplicando, aprenda a trabalhar da seguinte maneira:

  • Produza software em execução, testado, funcional e integrado a cada duas semanas, todas as semanas. Desenvolva suas habilidades até que você possa criar uma nova versão totalmente operacional todos os dias, duas vezes por dia, várias vezes ao dia.
  • Mantenha o design desse software limpo. À medida que cresce, o design tenderá a se tornar complexo e crufty. Resista e reverta essa tendência conscientemente, refatorando em pequenos passos contínuos, o tempo todo, para que sua taxa de progresso seja a mais constante e consistente possível.
  • Use o incremento atual do software como base para todas as suas conversas com a liderança e o gerenciamento do produto. Fale em termos do que está pronto para ir e em termos do que eles gostariam que você fizesse a seguir.

Esta é a melhor esperança da equipe de desenvolvimento para uma vida razoável. Ao manter o software sempre pronto para ir, podemos atingir qualquer prazo com o melhor resultado possível. “Hoje é o prazo? Aqui está o que temos, está pronto para ser enviado.”

À medida que avançamos para o prazo e negociamos o que fazer a seguir, o software em execução em nossas mãos nos permite manter a conversa focada na próxima coisa mais importante a fazer, em vez da lista quase infinita de coisas que eles acham que querem. Não é fácil mudar o foco de “faça tudo isso” para “faça isso a seguir”, mas é a nossa melhor chance de uma vida decente, e muitas vezes é bem possível obter o foco para mudar, à medida que trabalhamos para colaborar com nossos líderes, em vez de apenas trabalhar sob eles.

Sob uma abordagem imposta

Muito comumente, a abordagem “ágil” que uma equipe usa foi imposta. Métodos “ágeis” em maior escala parecem realmente recomendar a imposição do processo. Incluo aqui o chamado método “SAFe”, Scaled Scrum e LeSS, entre outros. Estes são lançados para a empresa, e espera-se que a empresa os “instale” ou “implemente”.

Como desenvolvedor, você pode ter certeza de que esse lançamento não ocorrerá sem problemas nem de uma maneira verdadeiramente ágil. Você provavelmente não será treinado, muito menos educado, muito menos dada a ajuda real que você precisa para fazer o seu trabalho. Sua liderança talvez tenha sido treinada, talvez por até uma semana inteira (!), para prepará-los para trazer essa mudança radical na abordagem da organização ao desenvolvimento de produtos e software. É provável que a estrada seja um pouco esburacada.

Software real é a sua única esperança

  • Leia (comunicação privada)

Mas se você puder selecionar de forma confiável o trabalho a ser feito ao longo de um “Sprint” ou “boxcar” ou o que quer que seu condutor de trem de liberação comece a chamar o período de tempo, e realizar esse trabalho, embalando-o em uma nova versão do sistema em execução, testada, integrada e pronta para uso, você estará equipado para fazer o melhor que for possível fazer.

Diminua a velocidade para entregar

Se você não consegue gerenciar isso, eu aconselho você a assumir menos trabalho em cada período de tempo, até que você tenha assumido um lote pequeno o suficiente para que você possa realmente fazê-lo. Isso vai ser difícil! As pessoas vão empurrá-lo para “ir mais rápido”. Faça o seu melhor! Sob pressão para se inscrever para mais do que você pode fazer, eu sugiro que você trabalhe em um ou dois dos itens, complete-os inteiramente - totalmente embalados, testados e funcionando - e depois faça outro, para que no final do boxcar você tenha algo que você pode absolutamente chamar de concluído. Pegue o abuso inevitável por não completar tudo, e tente direcionar o planejamento e as expectativas da realidade, não a fantasia do que foi exigido, que você nunca teve a chance de fazer.

Não será perfeito e, pelo menos por um tempo, provavelmente não será divertido. É apenas a melhor chance que eu conheço de sobreviver nesse código meu. Ter uma fatia de produto em execução concluída é a melhor maneira que conheço de possivelmente reverter a situação. Em uma situação ruim, tudo o que podemos fazer é o nosso melhor e tentar ajudar as coisas a melhorar.

Claramente, em uma organização mais esclarecida, ou com aprendizado contínuo, as coisas se tornarão cada vez mais abertas a ideias reais do Manifesto Agile. A vida pode melhorar, e espero que melhore.

Eu estive nessas situações e, além de sair, o melhor que sei é fazer um bom trabalho, mantê-lo visível, funcionando, testado e integrado, e ajudar as pessoas a ver a realidade.

Escolhendo uma abordagem

O Manifesto pede equipes “auto-organizadas” e, no melhor dos casos, isso se resume à equipe escolher seu próprio processo. Se eu estivesse começando uma empresa, deixaria as equipes escolherem qualquer processo que desejassem.

Eu pediria resultados, não um processo específico

No entanto, haveria restrições, não sobre como eles escolhem trabalhar, mas o que eu preciso ver. Eu deixaria claro que, a cada duas semanas, no máximo, eu gostaria de rever a fatia do produto testado em execução. Eles me mostravam o que tinham planejado construir e o que construíam. Teria que realmente funcionar e conter capacidades visíveis que eu pudesse entender. Nós falaríamos sobre o que eles deveriam fazer no próximo intervalo. E eu deixaria claro que uma semana seria melhor do que duas, e que um dia seria melhor do que uma semana.

Eu forneceria ajuda

Eu lhes daria ajuda. Eu forneceria a alguém uma conexão sólida com as necessidades de negócios a serem atendidas pelo produto, o que os ajudaria a decidir qual fatia de trabalho fazer a seguir. Eu forneceria acesso a treinamento e apoio fazendo o trabalho que eles precisam fazer. Eu me certificava de que eles estavam equipados para fazer o que eu estava pedindo que eles fizessem.

Claro, eu faria isso porque eu sei como fazer essas coisas. Você pode ter a sorte de estar em uma situação um pouco semelhante a essa, pelo menos até o ponto em que você pode escolher seu próprio processo.

Shhh. Talvez XP!

Se você tiver a chance de escolher, eu recomendo que você comece com algo como Extreme Programming. Ele contém todos os ciclos de planejamento e feedback que você precisa, e inclui as práticas técnicas básicas que você precisa para fazer o que estamos falando aqui e fazer o que eu estaria pedindo.

E eu recomendo que você fique alerta em todos os momentos para sinais de todas as outras coisas que você precisa. “ATDD, TDD e Refatoração” são coisas que, na minha opinião, você precisa até saber algo melhor. Mas há dezenas, centenas, milhares de outras coisas que você precisa também. Fique alerta para eles e, quando identificá-los, obtenha-os.

A excelência na fabricação de software é uma atividade para toda a vida. Mesmo a Extreme Programming, a melhor abordagem oficialmente nomeada que eu conheço, apenas arranha a superfície. Avançar em direção à excelência depende de sua equipe e de seus membros.

Resumindo

Além de talvez uma orientação auto-escolhida para as ideias da Extreme Programming – como um espaço de ideias em vez de um método – eu realmente estou começando a pensar que os desenvolvedores de software de todos os tipos não devem ter adesão a qualquer método “ágil” de qualquer tipo. Como esses métodos se manifestam no terreno, eles são muito comumente o inimigo do bom desenvolvimento de software, em vez de seu amigo.

No entanto, os valores e princípios do Manifesto para o Desenvolvimento Ágil de Software ainda oferecem a melhor maneira que conheço de construir software e, com base na minha longa e variada experiência, eu seguiria esses valores e princípios, independentemente do método usado pela organização maior.

Ofereço essa opinião como conselho. Faça com ele como achar melhor.

Autor: Ron Jeffries

Artigo Original