Acabei de voltar de férias, já comecei a recuperar o atraso do meu Google Reader e não demorei muito para me deparar com a polêmica do momento…
Sei que muitos já fizeram isso mas não poderia deixar de comentar sobre o post do James Shore sobre o declínio e queda das metodologias ágeis. Recomendo a leitura do post, ou no mínimo do resumo do InfoQ.
O ponto do James Shore é muito simples: as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que a princípio podem não fazer muito sentido – como por exemplo exigir que o cliente esteja presente – mas no final fazem uma diferença enorme.
Outra polêmica muito grande é sobre a “popularização” do Scrum e seu mal uso. Como disse o Uncle Bob em um excelente post, usar uma metodologia ágil pura e simplesmente não faz com que você faça algo bom automaticamente. É perfeitamente possível fazer desgraças de design usando XP e com toneladas de código gerado com TDD, por exemplo. Será que ainda não deu para perceber que o caminho não é se apegar a metodologias e nomes? Elas são simplesmente uma porta de entrada!
Acho que isso tudo aconteceu porque com o “surto” de adoção e procura das metodologias ágeis, do dia para a noite surgiram milhares de especialistas ágeis. Esses agilistas espertalhões surgiram com dezenas de teorias malucas, princípios absurdos e uma quantidade incontável de barbaridades. O mais triste é ver que essas barbaridades são tantas que podem ser encontradas facilmente em listas de discussões, cursos, revistas, blogs e por todos os lados!
Estão pipocando comentários indignados (e com razão) sobre a deturpação de Agile, como o Christiano Milfont que comentou sobre a combinação estranha de Agile e CMMI, do Fernando Meyer sobre as pessoas não terem o pé no chão em relação ao Scrum, do Rafael Mueller, Phillip Calçado, Ivan Sanchez, José Papo e muitos outros comentando sobre o post do James Shore… Parece que muitas pessoas na comunidade – asssim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento.
É realmente triste ver as metodologias ágeis sendo estupradas, é vergonhoso ver pessoas falando abobrinhas gigantescas sobre Scrum sem terem a menor idéia de como funciona e é enojante ver mensagens nas listas de discussões de pessoas que conseguem quebrar todos os valores do manifesto ágil em menos de um parágrafo. O triste resultado disso é que já dá para perceber em algumas pessoas o início de uma rejeição à metodologias ágeis…
Seja XP, Scrum, Lean ou qualquer outra, as metodologias ágeis serão tão boas e darão resultados tão bons quanto as pessoas que as usam.
Cuidado com os falsos agilistas, eles estão por todos os lados!
34 replies on “Agile indo para o buraco?”
Creio que essa “queda” na percepção de Agile na verdade representa um amadurecimento depois do hype.
Metodologias ágeis trazem várias ótimas práticas e idéias que podem contribuir muito para o sucesso de projetos de software. Entretanto, como você falou, o nível das pessoas envolvidas é mais importante do que o valor de qualquer metodologia.
Um bom time encontrará formas de entregar bom software com qualquer metodologia. O que eu julgo mais importante é buscar sempre o equilíbrio do time, de forma que ele renda da melhor forma possível.
Entender as pessoas e a estrutura de um time e saber o que fazer para ele render de forma ótima é muito mais importante do que defender metodologia X, Y ou Z.
Eu gosto muito de metodologias ágeis, e torço para que esses movimentos atuais sejam um passo no sentido de valorizar ainda mais as pessoas em vez de discutir metodologias.
Nice post GC []s
É verdade, isso pode representar algum tipo de evolução.
Eu estava lendo em algum lugar hoje (que infelizmente não me lembro mais qual é) que essa “queda” poderia ser a fase de deseilução do Gartner Hype Cycle: http://en.wikipedia.org/wiki/Hype_cycle.
[ ]s, gc
Guilherme, concordo com você e o Bruno sobre como as pessoas ficam presas a nomes de metodologias sem entendê-las e acham que estão com toda razão. Também gosto muito das metodologias ágeis quando bem utilizadas. Infelizmente as pessoas olham de forma simplista para as metodologias ágeis sem olhar seus valores e práticas, acham que fazer programção em par estão usando XP ou então não conseguem adaptar tais metodologias a sua realidade, o que leva ao fracasso de vários projetos e consequentemente a resposabilizarem as metodologias ágeis por isso.
[…] pode se atualizar no post original do Jim Shore, ou então também nos comentários do Manoel ou do Guilherme, para citar alguns entre […]
um ponto muito interessante é que algumas empresas acham que o uso de uma metodologia ágil é a solução para todos os problemas.
na empresa que trabalho atualmente (privatizada há alguns anos) a palavra da vez é Lean. todo um trabalho de marketing sobre como ser produtivo e tudo mais. e a meu ver, a empresa continua utilizando as mesmas práticas burocráticas do tempo que era uma estatal.
a empresa em questão luta pra perder a imagem de fábrica de horas extras, mas enquanto seus gerentes continuarem falando para os recém contratados que Lean é um saco, isso não vai acontecer.
definitivamente, não são metodologias que vão resolver os problemas das empresas do futuro.
A maioria das pessoas adora terceirizar. Principalmente, responsabilidades e esforços. Graças a isso crescem consultorias de três letrinhas, fasts-foods, visual studios, tecnologias bala de prata, certos cultos, etc. Assim fica mais fácil continuar o mesmo (inércia, preguiça), não enxergar/confrontar as próprias deficiências (cegueira) e culpar alguém quando dá merda (imaturidade). A valorização das pessoas pelas metodologias ágeis revela a necessidade de deslocar o foco para aquilo que não se compra em prateleira, qualidades humanas.
Concordo completamente. Em poucas palavras todos os problemas acontecem quando as pessoas se apegam as práticas sem conhecer os princípios, dessa forma perdem a essência da agilidade. A forma permanece mas a alma morre. Acho que isso acaba acontecendo com qualquer coisa que se torna o hype do momento.
Espero que tenha aproveitado bem as férias.
Grande abraço.
Primeiramente espero que tenha recarregado bem as baterias! 😉
Pode parecer besteira, mas boa parte dos “falsos agilistas” são frutos de cursos de final de semana que se certificam como “Scrum Masters” da vida. Recentemente pude perceber que implementar uma metodologia ágil em alguns times “cascateiros” da vida que existem por aí não é tarefa fácil. Requer do líder muito preparo para tal e com certamente estes profissionais certificados não darão conta do recado.
@Marcos,
Obrigado, estou “recarregado” 🙂
Sobre os “cursos de fim de semana”, tb tenho essa impressão. Já cansei de ouvir várias pessoas que se acham especialistas em Scrum só porque fizeram o curso de dois dias. O pior é quando essas pessoas falam várias coisas estúpidas e ainda dizem “ah, mas o fulano (que deu o curso) falou que é assim que se faz”.
Essas pessoas muitas vezes não leram um livro sequer ou nunca se preocuparam em aprender nada na Internet sobre o assunto e já se acham experts.
O título “_Certified_ Scrum Master” é forte demais para um curso de dois dias, e acaba fazendo com que essas pessoas fiquem achando que sabem alguma coisa. Uma vez eu estava discutindo com alguém sobre Scrum e dizendo que o cara não sabia o que estava falando, quando ele teve a cara de pau de me dizer assim: “Como assim eu estou errado? Como eu não sei de nada? Eu sou tão certificado quanto você!”.
E ninguém venha me dizer que não é bem assim que funciona porque eu falo isso tudo com a segurança e experiência de quem conhece pessoalmente _vários_ exemplos disso que estou falando.
Infelizmente você está certo. Esses cursos são sim parte do problema.
[ ]s, gc
Bom, as metodologias ágeis estão aí, e isso é fato… Se estão sendo mal utilizadas, aí é outro ponto.
Não sei se é por uma visão minha pessoal, mas acho que as metodologias ágeis são muito validas para a implementação(desenvolvimento) de produtos, mas são pouco razoáveis quando estamos lidando com questões como inovação, marketing, ou seja, reflexões que levam e consideralção que o produto final não precisa somente funcionar, mas sim agregar valor e receita para as empresas, após serem disponibilizados para os usuários finais.
Vejo a cada dia as entregas sendo mais superficiais, sempre com os mesmos argumentos de sempre dos desenvolvedores : não dá tempo, não é possível, enfim. Mas também entregar somente produtos fabricados com prazos rasos limita bastante a possibilidade de fazer produtos inovadores e rentáveis. Fazer rápido não deve significar fazer óbvio, mas sim, fazer o melhor, o mais rentável (lucro), em menos tempo.
Usar as metodologias ágeis para fazer coisas simples, gastando menos tempo, e dizer que se produz com agilidade, não dá!
@Danibrow
Desculpe mas vc está equivocado 🙂
As metodologias ágeis não servem de forma alguma pra fazer alguma coisa em menos tempo ou fazer somente coisas simples. Alguns dos objetivos são: tornar o processo de desenvolvimento menos burocrático, entender que software é feito por pessoas e não por robôs ou operários de uma fábrica no melhor estilo fordista, fazer o que é mais importante em primeiro lugar, antecipar o retorno sobre o investimento, criar software que seja fácil de ser modificado, dentre outras coisas.
As entregas podem ser tão superficiais quanto se desejar. Aliás, nenhuma metodologia ágil entra nesse mérito pois quem faz as histórias com o nível de profundidade que desejar é _você_.
Por tudo que você está falando você não trabalha num time ágil de verdade. Em times ágeis não existe essa história de não dá tempo, de não ser possível inovar e de não ser possível agregar valor e receita para as empresas – aliás, é justamente ao contrário.
Como eu disse anteriormente no post, as metodologias ágeis serão tão boas e darão resultados tão bons quanto as pessoas que as usam. O problema certamente não está nas metodologias, mas no seu time 😉
[ ]s, gc
Olá Guilherme!
Concordo com você no que diz respeito a possibilidade de estarmos em declínio pelo mau uso das práticas ágeis. No entanto, você citou que diversos lugares escrevem absurdos sobre o assunto.
Não me considero o maior conhecedor sobre agilidade (longe disso…), mas estou sempre em busca de melhora (inspeção e adaptação) e quando posso procuro passar minha experiência para ajudar outros colegas, assim como vocês ai na Globo.com fazem também. Acho que nesse caso temos um ganha-ganha.
Recentemente fundamos aqui em SP um grupo de arquitetura focado principalmente em .NET (http://www.dotnetarchitects.net) e ontem fiz uma apresentaçãozinha pro grupo a respeito de scrum (http://blog.tucaz.net/2008/11/22/slides-apresentacao-encontros-e-desencontros-na-adocao-de-scrum/). Posto no blog a respeito, participo de grupos de discussão e também escrevi recentemente na MundoNET Edição 11 a respeito de Scrum.
Acredito que esteja indo no caminho certo, pois meus resultados tem melhorado desde o início da aplicação das práticas ágeis.
O único ponto que eu não gosto muito desse bla-bla-bla a respeito do declínio da agilidade é que todos que postaram a respeito e compartilham da mesma opinião não apontaram onde estão os absurdos ou os pontos errados. Tenho certeza que o intuito desse post, assim como os outros parecidos, é fazer com que as pessoas pensem bem e analisem se realmente estão sendo ágeis antes de falar. Concordo que críticas são excelentes, mas para que esse movimento de declínio ágil tenha algo de positivo é preciso dizer onde está o erro (honestidade). Se ninguém der o primeiro passo e mostrar onde as pessoas estão errando todo esse bla-bla-bla não vai servir pra nada.
[…] você não sabe do o título se refere, acesse o blog do Guilherme e leia um bom resumo do que aconteceu nessa última […]
Não conheço o suficiente pra falar, mas muita gente boa diz que RUP é bom… o problema é que ele é muito mal aplicado e hj é visto como algo que não funciona… Será que estamos indo pelo mesmo caminho com os métodos ágeis!?
[…] Guilherme Chapiewski: […] muitas pessoas na comunidade – assim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento. […]
Guilherme,
Primeira vez que comento por aqui. Parabéns pelo blog, que é sempre muito esclarecedor.
Eu acho que entendi seu ponto de vista e de certa forma concordo. No entanto, tenho algumas dúvidas. Veja, a partir do momento que qualquer coisa se populariza, é natural que hajam desvios da idéia inicial. Aliás, nem sempre os desvios são negativos ou trazem prejuízos. Muitas vezes os desvios levam a evolução.
Quando penso em qualquer metodologia, sempre surgem dúvidas no momento de aplica-las uma vez que existe um ponto crucial a ser considerado e que nem sempre determinadas metodologias explicitam : o contexto da organização (empresa). Entendo que aí comece a variação.
Eu mesmo tento de diversas formas aplicar algumas metodologias, mas nem sempre consigo o resultado “by the book” pois a equipe nem sempre reage da forma esperada. Muitas vezes abro mão de alguns passos em função do aumento da produtividade. Tem coisas que simplesmente os desenvolvedores não querem fazer, outra vezes não entendem e por fim, muitas vezes não conseguem absorver.
Entendo que muitas vezes haja uma distorção do que é determinada metodologia, mas entendo também que essa distorção nem sempre é prejudicial ou sinal de incompetência.
Para exemplificar, trabalho com desenvolvedores na matriz japonesa, americanos, brasileiros e diversas outras naturalidades. O que cai bem para um time, nem sempre vale para outro. Chega a ser uma questão cultural muitas vezes.
Para quem está liderando um time, abrir mão do protocolo e focar no resultado não é nada raro de acontecer. Talvez, como produto final, eu esteja fora do que a metodologia rege, mas se o cliente está satisfeito, eu também fico satisfeito.
Saudações,
Fernando.
GC, eu vejo um certo “problema paralelo” além dos já citados, falsos agilistas e etc, acho que está se criando um processo concorrente de agile-burocrático, pra atender empresas que não conseguem aderir ao mínimo necessário para um bom processo ágil na empresa, mas querem ter esse “selinho” de agilistas porque pode ser bom comercialmente. Vejo (ouço e leio) empresas completamente burocráticas e waterfallzeiras criando adaptações e distorções incríveis do SCRUM, passando por cima de todos os itens do manifesto ágil, para atender suas necessidades arcaicas de trabalho.
Como até comentei outro dia numa lista, será que teremos em breve um agile for skatistas e um agile for “enterprise”?
Grande post!
[]’s
@Luiz Aguiar,
desde o JustJava 08 que não sai da minha cabeça a palavra “cascateiro”, dita pelo Yoshima. 🙂
E hoje leio os comentários desse post do GC e vejo “waterfallzeiras” e “agile for skatistas”. Poxa, agora tenho mais novidades para o meu vocabulário anti-waterfall! Muito obrigado! 🙂
Bem, o texto do post é pertinente e verdadeiro. Até hoje também não consigo esquecer o e-mail enviado pelo Vinicius Manhães para a lista XPRio. Nesse e-mail, ele cita que é difícil mudar o pensamento arcaico e antiquado das empresas e pessoas, que ainda preconizam este tipo de metodologia.
Temos que mudar esse cenário e fazer algo já, quem sabe o movimento “Agile for Skatistas”!
na globo.com veio para ficar.
@javalijr
Woohoo! Felizmente estamos no caminho certo 🙂
Ótimo post.
Gostei do post do James Shore.
Acho que um dos problemas é que as pessoas que querem aprender (ou pelo menos chegar na porta de entrada) uma metodologia ágil não sabem onde começar.
Abraço.
Nada tira da minha cabeça que o problema disso tudo ainda continua no fato das pessoas estarem sempre buscando a “Bala de Prata”. Tentaram com RUP, tentaram com várias ferramentas de gestão, controle x, controle y. Agora chegou a vez do Agile. Imagino que muitos devem ter pensado: “Agora achamos a solução definitiva pra todos os nossos problemas. Basta seguir a risca o manual do SCRUM e tudo vai dar certo”. Infelizmente parece que isso vai continuar se repetindo a cada coisa nova que surgir …
[…] Guilherme Chapiewski Enviar por e-mail | Hits para esta publicação: […]
Eu vejo como a coisa mais natural do mundo. Todos nós conhecemos profissionais ruins que lideram projetos grandes.
Formas inovadoras de desenvolvimento nascem de profissionais bons que tem as boas idéias, outros profissionais bons que não tiveram a mesma idéia reconhecem a boa idéia e adotam a forma, tornando-a popular.
Então ela se torna acessível aos profissionais ruins, que a aplicam mal e então chegamos ao ponto atual. Eu penso que as metodologia ágeis tentem a prevalecer, contudo as equipes que vão se destacar serão aquelas onde o líder é um bom profissional.
Grande Guilherme,
Acredito fielmente que o maior problema de todos seja o mal uso da metodologia. Infelizmente nós seres humanos tentamos na maioria das vezes obter o resultado muito rápidamente tentando fazer a coisa de qualquer maneira ou da maneira mais fácil. E ainda existe a outra parte que tenta implementar a metodologia sem mesmo ter o entendimento necessário para a implementação da metodologia ágil.
Não adianta simplesmente dizer que utiliza metodologia ágil porque baniu qualquer tipo de documentação ( inclusive nenhuma metodologia ágil manda fazer isso ! ), então acredito que mais uma vez a falta de entendimento, e a falta de vontade de entender estão causando mais uma vez um problema sério na nossa área.
Vi isso acontecer com o RUP…. pois o mesmo é um framework muito interessante, só que mais uma vez as pessoas descambaram para uma implementação tôsca e bizarra, gerando assim muita coisa ruim, burocracia e projetos que foram pro buraco. Hoje em dia todo mundo q ouve “RUP” vem na mente “burocracia”.
O grande lance é os profissionais e empresas estudarem bem, absorver as boas práticas e abraçar o desenvolvimento ágil em sua implementação correta. Mas isso já é outra estória 🙂
Como comentei em um post do shoes, não menosprezando a metodologia claro. Mas agile virou cool, se agile fosse música tocaria todos os dias na rádio e muita gente não saberia nem porque toca.
Ainda não sei como não vendem camisetas nos camelos: I’m agile! O mundo virou ágil, como conversava com o consentino outro dia, existiu uma época em que se você não usasse rup você estava fora, agora é agile.
No fim tudo se resume a um gado, que escolhe uma direção e vai de forma alienada até ela, sem saber nem porque.
[…] como The Decline and Fall of Agile começarem a fazer sentido na comunidade. Como disse o Guilherme Chapiewski, as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. […]
[…] para suas práticas convencionais e muito buzz vai surgir de que é o fim das metodologias ágeis, como já aconteceu em 2008. Tb vamos ver várias empresas tendo sucesso na implementação destas metodologias e com isso mais […]
[…] disse o Chapiewski, os programadores estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. […]
[…] do desenvolvimento de software estudam as coisas pela metade e acabam falando besteira, usando técnicas de forma errada, dizendo o que não […]
Olá,
Acredito que o grande problema em formar equipes ágeis é supor que todos os membros da equipe atual serão “convertidos”.
Os métodos que usamos na metodologia ágil de nada servem se as pessoas não entenderem o porquê desses estarem sendo utilizados. Com base em algumas experiências eu posso afirmar que se a equipe ágil não tiver os valores do manifesto ágil de nada vão adiantar as técnicas impostas para construção do software.
A grande questão é que nada pode ser feito mecanicamente, tudo em qualquer metodologia possui um conceito por trás que deve ser entendido pelos integrantes da equipe.
Na metodologia ágil as pessoas são importantes, e se eles não estiverem comprometidas e interessadas nenhum projeto que use ágil vai dar certo.
Abraços!
[…] Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco). […]
[…] Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco). […]
[…] do desenvolvimento de software estudam as coisas pela metade e acabam falando besteira, usando técnicas de forma errada, dizendo o que não […]