Como já falei em outros posts nesse blog, tenho interesses pessoais e profissionais em metodologias Ágeis. Pessoais porque desde que conheci o PMBOK e o RUP há dez mil anos atrás, sempre pensei: “tem que haver alguma maneira melhor e mais eficiente de se fazer isso!”, e profissionais porque a empresa onde trabalho vêm investindo tempo e recursos na transformação da nossa metodologia de desenvolvimento em uma metodologia Ágil. Por consequência desses dois fatos, me envolvi em listas de discussão, passei a ler blogs e pesquisar muito na internet sobre Ágil e suas vantagens. Um belo dia, quando estava navegando, me deparei com este artigo, sobre o qual vou fazer uma breve tradução comentada.
O BLOG da Rasmusson Software Consulting é uma fonte quase que inesgotável de assuntos sobre desenvolvimento de software, mas vou me focar neste artigo, que fala das muitas dificuldades em se comprovar a superioridade dos métodos ágeis.
Neste artigo, o dono da empresa relata os desafios que ele recebe quando tenta introduzir metodologias Ageis em empresas. O maior desafio é oferecer provas que os métodos ágeis são realmente melhores, justamente pelas características do trabalho de desenvolvimento de software: uma “coisa” subjetiva e emocional.
Existem as medidas tradicionais: tempo, dinheiro e o quão à risca foi seguido o planejamento inicial. Mas essas comparações são falsas, porque projetos ágeis e projetos não-ágeis entendem valores de maneira diferente.
Projetos ágeis não são somente sobre tempo, dinheiro e exatidão do planejamento inicial. Na verdade, exatidão no planejamento inicial chega inclusive a ferir um dos princípios de metodologias ágeis: o princípio que diz que o planejamento vai mudar ao longo do projeto. Se o plano não mudou, um especialista em metodologias ágeis certamente perguntaria: o que aconteceu de errado?
charge do Dilbert, sobre as mudanças nos requisitos de um projeto. Clique para ver maior.
Ao invés de provar ou aclamar Agile como uma metodologia melhor, o autor do artigo comenta que é mais eficiente e efetivo fazer com que as pessoas falem sobre projetos que foram realmente muito bem sucedidos. Durante essas conversas, é fácil perceber diversos pontos em comum entre esses “melhores projetos”:
- O time era próximo, integrado
- Existiam bons canais de comunicação
- Decisões eram tomadas rapidamente
- Havia forte colaboração entre os membros do time
- O(s) patrocinador(es) sempre estava(m) envolvido(s)
- Paixão e trabalho duro
- Respeito pelos colegas de trabalho
- Sentir que seu trabalho faz a diferença
- Sentido de urgência, necessidade
- um sentimento real de comprometimento
- orgulho dos resultados do trabalho
- diversão
Entretanto, nenhuma das características acima são particulares ou únicas a alguma metodologia específica. São características universais.
A razão pela qual o autor questiona os métodos tradicionais de “sucesso” em projetos se resume a uma simples afirmação: “Nunca ninguém chegou para mim e disse: ‘meu projeto foi terminado no cronograma e no orçamento planejado’ e depois jogou os braços para o ar e fez ‘whooohooo!!'”.
Normalmente as respostas das pessoas, quando questionadas a respeito dos seus melhores projetos, são mais ou menos nessa linha: “Nós engolimos o plano original, sentamos com o cliente e nos focamos em entregar exatamente o que eles (o cliente) queriam, realmente rápido e com um tempo de resposta entre eles e nós realmente rápido. Foi lindo”.
E depois dessa conversa toda, quando você pergunta a eles “porque isso não está sendo feito nesse projeto atual?”, eles terminam dando com os ombros. Todos nós sabemos que uma metodologia de software não faz ou quebra um projeto. Pessoas sim.
Uma característica única e inquestionável que eu vejo em projetos de sucesso onde as pessoas adoravam trabalhar é que eles contém muitas das características, práticas e princípios que são defendidos nos métodos ágeis.
A definição de Dilbert para “sucesso”. Genial!
Eu não posso provar que agile é a melhor maneira de desenvolver software (isso não é possível). Apenas vejo que, quando as pessoas me falam sobre seus projetos ideais, seus melhores projetos, eles contém vários elementos de medotologias ágeis.
Todas as imagens e referências ao personagem Dilbert são puramente ilustrativas, e foram coletadas de diferentes sites na Web. Todos os direitos sobre as imagens pertencem ao seu autor, Scott Adams.
Um ponto importante sobre metodologias ágeis é que elas foram criadas por pessoas que pensavam, executavam, viviam e melhoravam as praticas e valores nos projetos das quais participavam. Por isso acho mais efetivo. “Ei, eu vivi isso, testei, melhorei e vi que funciona.”
Algumas práticas não são tão naturais (como TDD) e outras soam absurdas para os executivos (como pair programming). Mas os conceitos e razões estão lá: TDD é mais do que apenas testar. É uma “ferramenta” para design limpo. É uma ferramenta para criar confiança entre o time. Pair Programming cria cumplicidade, evita distrações, retrabalho e espalha a posse do código entre a equipe.
Só que é difícil entender isso. Tem que pensar fora da caixa.
Ótimo artigo.
Não é diretamente “melhor” ,Metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos e a processos orientados a documentação.
Revolvemos um ponto e criamos problemas com outro ponto.