10 ago 09 O declínio dos métodos ágeis
Outro dia lendo o blog do James Shore (ele de novo!), me deparei com um artigo intitulado “The Decline and Fall of Agile“. Isso me chamou muito a atenção, uma vez que o autor é, declarado, um agilista. Após concluir a leitura, concordei com vários dos argumentos postos. Eis o que considero de principal:
Scrum mal aplicado
Não é culpa do Scrum. Desenvolvimento ágil não trata apenas de boas práticas de engenharia. É também sobre o reconhecimento da importância das pessoas no processo de desenvolvimento, formando equipes multidisciplinares, com comunicação em larga escala, constantemente refletindo e melhorando, entregando valor, e mudando planos para melhor aproveitar as oportunidades.
E Scrum inclui todos esses pontos. Diz, por exemplo, para colocar a equipe em um ambiente de trabalho compartilhado. Diz que no final de cada Sprint um produto de valor deve estar pronto para ser entregue, e diz também que a equipe deve se auto-organizar, descobrir impedimentos e removê-los.
Scrum também tem algumas poucas coisas mecânicas a respeito de Sprints mensais e Scrum diário. Coisas triviais comparadas com todo o resto. Mas, infelizmente, é essa a única parte que muitas pessoas adotam. Ciclos rápidos, mas nada daquelas boas práticas que fazem o ciclo rápido ser sustentável.Você está fazendo errado
Neste momento, há muitas equipes falhando com o desenvolvimento ágil. Esses times estão trabalhando em ciclos pequenos. A crescente freqüência de planejamento deu-lhes um maior controle sobre seu trabalho e eles estão descobrindo e consertando alguns problemas. Eles se sentem bem, e eles realmente parecem mais bem sucedidos do que eram antes.
Mas eles não estão trabalhando em ambientes de trabalho compartilhados, nem enfatizando a necessidade de comunicação de larga escala. Eles não mantêm os clientes por perto do local de trabalho. Eles nem mesmo terminam todas as suas Estórias até o final de cada Sprint, e certamente não utilizam boas práticas de engenharia.
Esses times se dizem ágeis, mas eles estão apenas praticando um tipo de “planejamento freqüente”. Ciclos curtos e capacidade de re-planejar são apenas os benefícios que o desenvolvimento ágil lhe dá. É a recompensa, não o método. Essas equipes pseudo-ágeis estão comendo a sobremesa toda noite e pulando o prato principal, os vegetais. Deixando de lado todo o resto (o ‘resto’ realmente ágil), elas estão bem encaminhadas para “dentes cheios de cáries”, “obesidade” e, conseqüentemente, estão fadados a falhar. No começo se sentem bem, mas isso não dura por muito tempo.
Resumindo, pare e pense: você está querendo pular o arroz-com-feijão, os brócolis e a salada, para ir direto a sobremesa? Se sim, você está, como muitos, deturpando os valores defendidos no manifesto ágil, e está no caminho errado.
Metodologias ágeis são tão boas quanto as pessoas que as usam!
Tags: Desenvolvimento Ágil, Scrum
25 abr 09 Escrever software é como… Escrever!
Bruce Eckel - autor da série de livros “Thinking in Java”, entre outros - escreveu esta semana em seu blog no site Artima Weblogs uma artigo a respeito de analogias ao trabalho de desenvolvimento de software.
Por quê precisamos de analogias? Programadores sabem o que estão fazendo, eles programam computdores! E eles sabem o que isto significa, simplesmente pelo fato de que eles o fazem.
Porém, para os stakeholders - gerentes, presidentes, clientes, parceiros - desenvolvimento de software é um mistério. Eles não estão interessados em saber tudo sobre o assunto, mas querem saber o bastante para fazerem previsões. Precisam então de uma abstração, uma analogia.
Matemática e Engenharia são duas analogias comumente utilizadas. Na primeira tudo pode ser matematicamente provado ou desmentido. Na segunda, o grau de previsibilidade é altíssimo e as técnicas de trabalho são consolidadas e padronizadas. É perfeitamente possível substituir um engenheiro por outro, e ainda assim obter-se resultados similares.
Olhando para tais considerações, identificamos grandes diferenças para os programadores. Mudar um programador significa mudar os resultados.
Segundo Eckel, programadores são - essencialmente - escritores.
Escritores como autores de livros, de novelas, de roteiros. Existem bons e maus escritores, e existem empresas que precisam de ótimos escritores, como também existem aquelas que precisam apenas de escritores, não tão bons assim. E mais, ter um bom escritor não implica na produção de um best-seller.
O que o autor defende, em resumo, é que esta analogia não ajuda a aumentar o grau de previsibilidade de o que fazem os programadores, mas, a exemplo da escrita, que é um trabalho artístico, estranho e difícil de medir, ajuda aos stakeholders a entenderem o quanto tal atividade é imprevisível.
Leia o artigo na íntegra clicando aqui.
