O elo perdido do Ágil que torna times ágeis em frágeis


No ano de 1.999 o Napster mudou o mundo da música quando apresentou uma nova forma de compartilhar músicas, as mais tocadas na época eram:
- "Baby one more time" da Britney Spears
- "Mambo No 5" do Lou Brega
- "I Want it that Way" do Backstreet Boys

Para concorrer no meio de tanta falta de criatividade que dominava na época, até o Pearl Jam lançou a música "Last Kiss", a primeira baladinha de corno gravada pela banda. Refrão:"Oh onde, onde o meu amor pode estar? O Senhor a levou de mim..." Fundo do poço para uma banda de rock.

O ramo de software, também sofria de falta de criatividade,  nesta época o mundo era dominado por Waterfall.

Mas o mundo em sua forma orgânica de reagir, assim como nosso corpo produz anti-corpos para combater um vírus, começou a produzir coisas boas para salvar o ano de 1.999! 

Neste ano foi o lançamento do filme Matrix, e no ramo de software, Kent Beck escreveu um paper sobre "Extreme Programming", falava sobre práticas de duas pessoas programando juntas, escrita de testes primeiro, antes de codificar, utilização de cartões para modelagem de objetos. No início as pessoas pensavam "Eww que esquisito!"

Mas de repente a indústria começou prestar mais atenção sobre este tópico, as conferências no EUA estavam dominadas por este assunto! Qualquer conferência de software no EUA que estivesse acontecendo, havia algum tópico falando de Extreme Programming. Todos falando: sim é disso que precisávamos, é maravilhoso! é sobre código! 

Kent Beck tinha uma visão:
Ele sabia que existia um vale que dividia o mundo de negócios do mundo de software, e havia pouca confiança entre eles. E pensou em processos mínimos para ajudar as pessoas de Negócios confiarem mais nos Desenvolvedores, sem pensar que eles eram criaturas estranhas e preguiçosas, e também ajudou Desenvolvedores a enxergar o pessoal de Negócios como pessoas sensatas, seres racionais e não de outro planeta.

Um processo diferente do grande e pesado waterfall, administrado apenas por burocratas. Mas principalmente um processo que era controlado, desenhado por desenvolvedores para desenvolvedores e negócios. Um processo que foca em valor de negócios, mas também em qualidade de código. Um processo que adota comunicação, uma quantidade massiva de comunicação entre negócios e desenvolvimento.

Ao final de cada iteração podemos integrar o incremento de código ao restante do sistema, realizando milhares de testes automaticamente, com mais segurança de que irá continuar funcionando de acordo com o esperado sem muitas "surpresas". Isto dará uma real agilidade a organização,  através de sistemas que permitem evoluir rapidamente, intensamente de acordo com as necessidades, sem se quebrar.

Mas por que o ágil perdeu este elo? Voltando a história do XP...

De 1.999 a 2001 as conferências e treinamentos de XP estavam cada vez mais lotadas por pessoas do mundo inteiro, pessoas criando testes+código, escrevendo histórias de usuário, programadores realizando iterações, ao final de cada iteração entregando código funcionando com testes automatizados, e todo mundo feliz.

Até que em 2001, Kent Beck resolve realizar um encontro de lideranças que gostavam de XP, apenas para todos estarem juntos. Onde vários destes líderes que também lideravam movimentos de Desing Patterns (Padrões de Design), em particular Martin Fowler e Uncle Bob, pensaram em criar uma organização que não falasse apenas de XP mas de Design Patterns como um todo, onde englobaria assuntos da comunidade de XP mas também de Scrum, FDD, DSDM, e todos estes outros processos leves. Este encontro se chamaria "Encontro de processos leves", enviaram e-mails convidando pessoas referências em processos leves, para se encontrarem em um resort de ski em Salt Lake City, em fevereiro de 2001.

No encontro, eles discutiram como chamariam aquela reunião, deram várias idéias até que o criador da técnica dos cartões CRC, Ward Cunningham, sugeriu chamar de "Ágil". Acontece em reuniões de se discutir sobre muita coisa e não sair com nada de concreto, até que no final Kent Beck decidiu escrever os tópicos discutidos baseado em sua visão, mostrando a divisão existente entre Negócios e Desenvolvimento, e todos concordaram resultando no que conhecemos como "Manifesto Ágil". Colocaram em um site e pediram para algumas pessoas acessar sem a menor pretensão de que aquilo fosse tomar alguma proporção. Até que ficaram atordoados, quando viram milhares e milhares de pessoas acessando o site, uma explosão!

Agile Alliance

Isso motivou eles a criarem uma organização a Agile Alliance, onde Uncle Bob foi o primeiro presidente ( que segundo ele, não fazia absolutamente nada hehe.. porque ele tinha outros negócios para tocar). Até que o próximo presidente foi o Ken Schwaber (co-criador do Scrum), onde decidiu criar uma forma de ganhar dinheiro com aquilo através de realização de mais conferências.

O próximo passo de Schwaber foi criar uma aula de "Certificação de Scrum Masters", Uncle Bob havia achado esta ideia um lixo. Porém mais e mais pessoas foram aparecendo às aulas, mais pessoas foram sendo "certificadas", e mais dinheiro foi entrando para o caixa da Agile Alliance. 

Mas, quem você acha que compareceu mais as aulas e queria tirar este certificado? Desenvolvedores? Claro que não! Desenvolvedores acham isto estúpido, eles nunca precisaram de certificado para poder programar. Uncle Bob que também era desenvolvedor e foi um dos criadores da Agile Alliance achava aquilo estúpido!
Então á quem se interessava este certificado? Gerentes de Projetos! Eles já faziam isto a anos, PMBok, BumBok, UniverseBok, Bok bok bok...
Até que a comunidade Scrum foi crescendo em grandes proporções principalmente através dos Gerentes de Projetos. Mas o problema era que desenvolvedores não estavam tirando o certificado de Scrum Master. Por motivos óbvios: o papel do Scrum Master diz que ele deve ser responsável principalmente pelo processo. E isto interessava mais a Gerentes de Projetos do que Desenvolvedores.

Assim, a glória do sucesso de um time começou a ser dada ao SCRUM MASTER! Para ter sucesso em seus projetos você precisa ter um ótimo SCRUM MASTER! Os gerentes de projetos queriam se tornar agora SCRUM MASTERS!

Você acredita que resolvemos o problema do vale que separa Negócios de Desenvolvimento? Simmm, agora rodamos SCRUM. Times Scrum se movem muito rápido! Entregas contínuas a cada 2 semanas! Entregas de qualquer coisa a cada 2 semanas, não importa o que, mas algo será entregue em 2 semanas! Porém isto tem um problema.

No curso de Scrum Master falta uma coisa, falar de práticas de desenvolvimento de software, como XP falava. Pair Programming, Design simples, TDD, Refactoring.. Tudo isto existe por alguma razão. Porque quando o time se move rápido, também precisa que as coisas se mantenham limpas, mantendo o código limpo, sem fazer muita bagunça, pois código ruim diminui a velocidade do time. 

Quando um time se move muito rápido, cada vez mais temos histórias Done, histórias Done, histórias Done.. Então quanto mais rápido o time se move, mais rápido o código pode apodrecer. E o que acontece após anos trabalhando assim? As coisas ficam muito lentas! Não porque seu time não está trabalhando duro, o time coloca muito esforço em tudo que faz, porém, a cada novo loop de iteração, as coisas ficam mais difíceis, mais difíceis, mais difíceis. A cada sprint as coisas ficam mais difíceis, porque o código está crescendo e ficando pior e pior e pior.

Até que Martin Fowler cunhou um termo para esta situação, chamou de "Scrum Flácido", que significa frouxo, sem firmeza, sem rigidez, mole.

O que acontece quando a velocidade de um time está diminuindo? O que é comum ver Scrum Masters fazerem? "Caras, a velocidade está diminuindo, precisamos aumentar! Precisamos de mais histórias done!". Ocorre mais pressão em cima nos desenvolvedores, e assim se instaura uma culpa sobre eles. 

O Elo Perdido

O que o Ágil esqueceu é que NÃO É POSSÍVEL TER VELOCIDADE SEM TER QUALIDADE.
Não se pode ter velocidade sem qualidade técnica.
Não se pode ter velocidade quando se está carregando muito débito técnico. Quanto mais débito técnico você carrega, mais lento você fica.

O Ágil tem falhado na visão inicial de Kent Beck sobre a divisão entre Negócios e Desenvolvimento, onde a própria comunidade ágil foi dividida! Um exemplo disto é o nascimento do movimento "Software Craftsmanship" que surgu para tentar curar esta divisão entre gestão e desenvolvimento.
http://manifesto.softwarecraftsmanship.org/#/pt-br
Não apenas software funcionando, mas SOFTWARE EM EXCELENTE QUALIDADE

A maior parte dos tópicos das conferências ágeis tanto no Brasil quanto no exterior, falam mais de técnicas de gerenciamento de projetos, produtos, times, etc. E pouco ou nenhum tópico sobre técnicas de desenvolvimento, no máximo 1 ou 2 tópicos por conferência. Então cada vez menos os desenvolvedores estão participando de conferências ágeis. Está ficando até comum, ver desenvolvedores dizerem que não gostam de ágil! "Afff.. ágil são apenas um monte de caras colando post-its na parede e gastando dinheiro em uma aula de 2 dias". 

Estas são evidências que a comunidade se dividiu. É necessário reascender os princípios de Extreme Programming que deram origem ao ágil. Quantos times estão rodando Scrum ou Kanban? Muitos! Mas quantos estão rodando Scrum e fazendo TDD ? Poucos! 
E BDD? Hein?! Em pleno ano de 2016 não sabe ou não usa BDD?
Não? Então você roda "Scrum Flácido" ou "Kanban flácido", o espiral da morte. Você não vai sobreviver por muito tempo sem uma arquitetura limpa, onde a cada iteração o risco de fazer alguma bagunça é sempre eminente. Você não conseguirá ficar mais rápido fazendo bagunças, você não ficará mais rápido evitando escrever testes, você não ficará mais rápido apenas apressando os desenvolvedores.

É necessário voltar as raízes que deram origem ao Ágil, que são práticas técnicas em CONJUNTO com práticas de gestão. Estas práticas precisam estar sempre ligadas, não podem estar separadas.

Agora após ler este texto, pode voltar ao seu trabalho e continuar com seu time escrevendo o próximo incremento de porcaria de código sem testes. Mas por favor, não diga que são ágeis apenas por rodar Scrum ou Kanban, porque vocês não são.



0 comentários:

Postar um comentário

 

Sobre

Agile Coach, Scrum Master, Eng. de Software com formação em Administração de Empresas em Análise de Sistemas.

Paixão por Software e Administração, foi como unir fogo com gasolina, combustão!

Comecei a programar aos 13 e nunca mais quis parar de respirar software.

Acordo todos dias até hoje com a mesma empolgação de um garoto de 13 anos para criar ou aprender algo novo.
A arte de criar formas de vida virtuais #Tron

Thiago Torricelly

Thiago Torricelly