terça-feira, novembro 18, 2008

Declínio e Queda do Movimento Ágil?

Muita discussão aconteceu em torno de um segundo assunto nas listas e blogs de desenvolvimento ágil. O tópico se originou a partir do artigo de James Shore The Decline and Fall of Agile. Antes de dar minha opinião propriamente dita é interessante lembrar do livro de Edward Yourdon intitulado The Decline and Fall of the american programmer. Yourdon previu no livro que organizações de software e desenvolvedores americanos perderiam completamente seus negócios e empregos para desenvolvedores de outros países. É claro que isso não aconteceu e Yourdon até escreveu uma retratação de suas previsões no livro Rise and Ressurrection of the american programmer.

Poucos devem ter percebibo a semelhança do título do artigo de James Shore e do livro de Yourdon. Menos pessoas ainda devem fazer a alusão ao clássico livro de História de Edward Gibbon intitulado The History of the decline and fall of the roman empire. A grande diferença é que Gibbon escreveu seu livro posteriormente aos fatos relatados (por isso é História), enquanto Yourdon e Shore escreveramm como previsões (por isso é Futurologia). Esse comentário é só para lembrar que até grandes mestres e profundos conhecedores em determinados campos podem errar.

Mas vamos passar agora aos argumentos de Shore.

De acordo com ele, centenas de empresas estão aplicando mal o desenvolvimento ágil. Muitas estão falhando em atingir seus objetivos de iteração, estão tendo muito débito técnico e não conseguem testar suas aplicações. Segundo Shore, o problema está em que essas organizações e equipes usam apenas o que é mais fácil no Scrum (iterações e scrums) e ignoram as práticas de engenharia (como Test-Driven Development, Refactoring, Pair Programming, Testes de aceitação automatizados, Integração Contínua, etc). Concordo 100% com ele nesse sentido: equipes ágeis precisam adotar práticas de engenharia ágeis para realmente ter uma produtividade e qualidade acima dos padrões de mercado.

Shore acredita que, em parte, o problema desses acontecimentos tem a ver com o Scrum. Como o Scrum não possui práticas de engenharia em seu processo, isso levaria as pessoas a achar que TDD, Refactoring, Design emergente e outras não são importantes. Nesse ponto é que discordo com Shore. Como o próprio Ken Schwaber costuma dizer sobre Scrum: no início de sua adoção por uma empresa o que o Scrum fará é mostrar todos os problemas da sua equipe e da sua empresa. Scrum vai jogar toda a sujeira no ventilador e vai mostrá-la para todos os níveis hierárquicos. E isso é fundamental para entendermos o que queria Scwaber quando idealizou o Scrum. Talvez o problema é que isso seja pouco ou escassamente comentado por Scrum Trainers e por alguns consultores Scrum. É uma parte essencial do que prega o Scrum.

O Scrum força você a fazer entregas curtas de resultados em pequenos espaços de tempo. No início, isso levantará à tona dezenas ou centenas de problemas que a organização tem para alcançar essas metas curtas. E é a partir daí que as reuniões de retrospectiva no final de cada iteração e os próprios daily scrums mostram seu valor. Os problemas vão aparecer diariamente e a equipe, com o apoio da empresa, terá que atuar para resolvê-los. Nesse ponto é que um bom mentor de Agile deve entrar para ir aplicando, mentorizando e convencendo aos poucos sobre o uso de práticas técnicas de engenharia. Essa é a grande sacada do Scrum que talvez seja pouco esclarecida.

Seria ideal que as equipes já aderissem desde o início a um processo ágil recheado com práticas técnicas como o Extreme Programming, o Feature Driven Development ou ao OpenUP. O problema é que a maioria das pessoas aqui no Brasil já têm dificuldade de fazer e entender um simples planejamento iterativo, quanto mais desenvolver testes antes de código e refatorar continuamente seu trabalho.

Eu diria que o Scrum é apenas a porta de entrada para a agilidade. Uma equipe que não evoluir além disso, com certeza irá fracassar como o James Shore brilhantemente mostrou. Mas, ao mesmo tempo, adotar de cara um processo ágil mais completo também pode levar essas equipes a abandonar rapidamente suas tentativas, pois se eles não conseguirem usar acharão que agilidade não é para eles.

Portanto, para terminar falando de História novamente, vou parafrasear duas vezes Churchill para falar de Scrum:

- Scrum é a pior forma de metodologia, exceto por todas as outras que já foram tentadas de tempos em tempos...

- Não, Scrum não é o fim. Não é nem mesmo o começo do fim. Mas, provavelmente, é o fim do começo...

11 Comentários:

At 6:44 PM, OpenID pindureta disse...

Fazia tempo que eu não via um artigo causar tanta polêmica.
É sempre assim, poucos abrem mão do conforto e da inércia em troca de uma real melhora, usam só o que é fácil, fazem mal feito e no final a metodologia/framework é quem leva a má fama.
Ótimo post.

Abraço

 
At 2:49 AM, Blogger ClaudioX DevON disse...

Muito bacana o artigo, estou aqui meditando sobre ele, muito bom.
Já tenho seu blog nos meus favoritos e vou olhando sempre que sair coisas novas.

Parabens, e bons trabalhos.

 
At 10:21 AM, Blogger Richard Sabah disse...

Gostei muito do seu artigo. Sempre me causa preocupação quando aparecem soluções mirabolantes para salvar o mundo. Assim como desconfio de posições de apocalipse provocadas pelo surgimento de novas metodologias e técnicas.

O surgimento da metodologia Ágil demonstra que nem todas os problemas ou problemas novos podem ser resolvidos pelos métodos considerados tradicionais. As novas propostas de ação, como as propostas pela metodologia ágil, num primeiro momento introduzem mauito mais problemas do que resolvem os já existentes. Só o tempo e dedicação em pesquisa e uma atitude aberta e não ortodoxa podem mostrar qual será o futuro da metodologia.

Richard Sabah

 
At 12:02 PM, Blogger Jordano Gonzatto disse...

José Papo, suas colocações foram ótimas, e ressalto a importancia de que práticas ágeis em ambiente empresarial é como uma bomba se colocada em lugar impróprio para a explosão. Os cacos e pedregulhos saltam para longe.
Então, criticar métododologias, seja lá qual for, é provinciano, aplicá-los sem respeito é distração, é insucesso.

 
At 12:11 PM, Blogger Kenji disse...

metodologia ágil funciona prá time entrosado e maduro. ponto.

 
At 2:51 PM, Blogger IgorCouto disse...

Papo (se me permite o tratamento assim) ,

Concordo com seu ponto de vista.

Mas indo um pouco mais além, você concorda que o problema é falta de conhecimento? Principalmente entre a relação entre o manifesto ágil e o scrum ?

O manifesto ágil define um conjunto de valores para o melhor desenvolvimento de software.

O scrum preenche a necessidade de uma camada fina, essencial para o gerenciamento de projetos de software, aderente ao manifesto ágil (principalmente colaboração entre pessoas, simplicidade e preocupação com a entrega contínua de software). Trata da organização, comunicação e liderança do trabalho de desenvolvimento.

Mas somente adotar o scrum não é o suficiente para aderir a esses valores. Aí entram SCM,XP,DDD,BDD e outras técnicas (sempre com adaptação) para completar o processo.

Agilidade em essência: Mobilidade com velocidade. Em todo o processo produtivo.
Para o software: Ser capaz de responder rapidamente a mudanças, perseguir produtividade (velocidade), melhoria contínua.

Mas ai entram os perseguidores de tecnologias e metodologias (e podemos citar outras técnicas como SOA,BI, Web 2.0) que querem comprar alguma ferramenta ou treinamento para surfar na nova onda.

E entram os Scrum Trainers, em um dia, faturando alto e não passando a principal mensagem.

Abraços!

Continuo acompanhando teu blog!

 
At 5:20 PM, Blogger Fábio Desconsi disse...

José,
Ótimo artigo!! Parabéns.

Implantar puramente as práticas do Scrum é facil, são algumas cerimonias 3 papéis, 3 artefatos ... as regras são simples. Porém não podemos esquecer que as mesma estão baseadas em alguns princípios e estes sim são dificeis de aplicar :)

Gostaria de ressaltar um parte intressnate onde você diz que o Scrum pode ser a porta de entrada para a Agilidade. A minha experiência valida isso, estammos estruturando um processo aqui na empresa com as necessidades que surgiram (e estão surgindo) nas Daily Scrum e nas Scrum Retrospective.

Grande abraço
P.S. Este seu artigo vai para os favoritos.

 
At 3:25 PM, Anonymous Diego Carrion disse...

Este comentário foi removido por um administrador do blog.

 
At 8:42 PM, OpenID arrais disse...

Estou já muito tempo por fora da comunidade ágil mesmo. Não sabia sobre "O surgimento da metodologia Ágil [...]".

Como assim? "Ágil" agora é uma metodologia e não me avisaram? Preciso me atualizar mesmo. Onde será que botei meu Sommerville?

 
At 12:02 AM, Anonymous Luís Fernandes disse...

Fantástico !

Já tinha lido a respeito desse artigo polêmico, mas nenhum post tão completo e crítico com relação ao assunto. Concordo com o que você falou neste post.

A impressão que tenho é a dificuldade das pessoas em seguir valores e não um guia de passos, e principalmente de procurar culpados: "o Scrum não resolveu nada", sendo que este não é o papel do Scrum, mas sim das pessoas.

Abraços.

 
At 5:08 PM, Anonymous Anônimo disse...

O maior problema encontrado pela minha equipe é que ñ entendem que scrum master ñ é o chefe e o arquiteto ñ disputa espaço com ele. Terrível!!
Escondem-se erros, delega-se tarefa, pressiona-se a equipe...terrível.
Scrum se tornou para "inglês ver".

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas