Desenvolvimento ágil funciona?

SÃO PAULO - No mundo do desenvolvimento de software, metodologias ágeis como scrum e extreme programming são a onda do momento. Mas será que elas funcionam mesmo?

Para tentar responder a pergunta, conversamos com Fabio Akita, um especialista no tema. Gerente de produtos da Locaweb e autor do blog Akita on Rails, ele trabalhou como desenvolvedor, integrador e gerente em diversos projetos de software.

Confira a seguir algumas das ideias que ele defende e tenta colocar em prática no seu dia-a-dia como gestor de projetos:

De onde surgiu a ideia de desenvolvimento ágil?

A crise do software vem desde a década de 70, não é recente. Desde os projetos militares da década de 60 todo mundo já sofria com os mesmo problemas. Mas a gente sempre vem fazendo do mesmo jeito desde então. Nos anos 90 diversos pensadores da área de engenharia de software se juntaram para tentar encontrar a metodologia correta para lidar com software e não chegaram a uma conclusão. Mas chegaram a um conjunto de valores importantes, que deram origem ao que chamamos de manifesto ágil.

Scrum e extreme programming são algumas metodologias ágeis que estão em voga no momento. Elas refletem o espírito deste manifesto ágil?

Com a nossa cultura de fast food, de querer achar uma receita mágica para tudo, o mundo ágil ganhou força dentro de um certo nicho de desenvolvimento. A gente ouve falar muito hoje de scrum, de extreme programming, mas se usam essas ferramentas apenas como ferramentas. Isso não funciona. Tem gente que até discute se o pico recente de scrum não foi mais negativo que positivo, porque muita gente está aplicando e não atinge os resultados, simplesmente porque usa o raciocínio antigo com ferramentas novas. Os valores não foram entendidos. Scrum é um template. Ele te diz que você tem esse papel chamado product owner, você tem este tempo chamado sprint, tem essa atividade chamada scrum diário, e essas coisas chamadas retrospectiva e backlog. Ele te dá nomes e elementos que você aplica. Mas não é só aplicar e ponto. Isso é só o começo. A grande mensagem da forma ágil de pensar é que o procedimento não é importante. É irrelevante se eu chamo o meu tempo de trabalho de sprint ou o dono do projeto de product owner. É absolutamente irrelevante, se eu não entendi os valores que são entregar valor ao cliente, criar uma organização de aprendizado, acreditar nas pessoas e dar suporte a elas. Esses princípios é que são importantes, mas não são explícitos. Em vez disso eu tenho papéis, cargos e atividades. Não se explicam os porquês e não entendendo os porquês você vai fazer exatamente a mesma coisa, mas em vez de chamar o sujeito de gerente de projeto você vai chamá-lo de product owner. Mas nada mudou.

• Complementando as dúvidas: - não há nenhuma distinção em termos de projetos "grandes" ou "pequenos". Lembrando que projetos grandes simplesmente são um portfolio de projetos menores que podem ser feitos sequencialmente ou em paralelo por uma ou mais sub-equipes. Cada uma delas seguindo normalmente me preceitos ágeis. É um mito que que ágil só serve para projetos pequenos. - o problema de sistemas grandes que ficaram ruins de dar manutenção não é por falta de documentação e sim por falta de disciplina dos desenvolvedores. Apenas Scrum não é suficiente, você precisa de técnicas de Extreme Programming e, claro, de desenvolvedores sênior. Não, uma equipe de desenvolvedores júniors sempre vai fazer sistemas ruins. Você precisa, no mínimo, de uma mistura igual de sêniors e júniors, pareando entre si. Pair programming é importante, Test Driven Development é essencial, Integração Contínua é vital, etc. O código precisa ser refatorado constantemente, os testes precisam rodar sempre. Em se desenvolvendo da forma correta, o código mantém muita da sua flexibilidade em manutenção e inclusive na coesão do seu design sem que se precise fazer Big Design Up Front (BDUF), que é sempre ruim. Detalhe: é sempre uma má idéia começar fazendo o diagrama de todas as centenas de tabelas que se "acha" que vai precisar. Design incremental, acompanhado de testes, com constante refatoração sempre funciona melhor, independente do tamanho do projeto. - Documentação por burocracia é totalmente desnecessário. Não quer dizer que "qualquer" documentação seja ruim. Veja qualquer projeto open source, no mínimo existe um README que dá uma visão geral do sistema. Em muitos casos só isso já é suficiente. Em outros casos temos Wikis que detalham um pouco mais alguns aspectos mais importantes do projeto. Agora, documentação de tudo é irrelevante porque, por definição, toda documentação ficará obsoleta e dessincronizada com o código. Isso não é um "talvez", é um axioma. A única "documentação" realmente efetiva é "Código Limpo", ou seja, código bem testado, bem refatorado. O próximo programador deve conseguir ver o mínimo de documentação (o README), rodar os testes e saber começar a se inteirar com o código diretamente pelo código. Manutenção sem testes é suicídio, e isso também é um axioma.
  enviado por: Fabio Makoto Akita em 02/07/2009 - 10:32
• Concordo como Gilberto que um mínimo de documentação é necessário, mas não concordo que metodologias ágeis não funcionem. Como o Akita bem falou, o SCRUM é um template, que define algumas coisas, e como você vai usá-las que é o “pulo do gato”. Não existe uma metodologia que se sirva como uma luva para uma empresa. É necessário analisar a cultura da empresa, a equipe e sua história (por onde cada desenvolvedor passou por exemplo) e decidir quais práticas são aplicáveis e que trarão um benefício. O importante é ter na cabeça que se eu desenvolvo guiado pelo maior benefício do cliente, em ciclos pequenos e tenho as pessoas como peças principais para o sucesso do projeto, eu estou sendo ágil. Ser ágil não é acabar com documentação...
  enviado por: Marcos Antonio Ferreira Domingues em 01/07/2009 - 14:05
• Ótimo, realmente ótimo, mas não funciona! Já vi diversos projetos desenvolvidos com métodos ágeis que no momento em que precisaram de uma manutenção evolutiva, simplesmente tiveram que ser reescritos, pois era impossível entender o que já estava pronto para evoluir, já que não havia nenhuma documentação. Não sou contra métodos ágeis, mas existe sempre a necessidade de se adotar um mínimo de documentação a respeito do negócio, análise e projeto. Hoje, da maneira com que as pessoas estão encarando o SCRUM, a documentação se torna algo completamente desnecessário, mas o alto custo dessa estupidez, me perdoem a palavra, será pago de médio a longo prazo. Será que vale a pena? Digo e repito, metódo ágil é algo interessante, deve ser estudado, mas não deve excluir a necessidade de documentar o projeto.
  enviado por: Gilberto Junior em 01/07/2009 - 11:20
• Quando tive a oportunidade de atuar como gerente de projetos tentei implementar uma metodologia ágil e posso afirmar com certeza que poucas empresas estão prontas para adotar este tipo de desenvolvimento. Concordo plenamente com o entrevistado, o que as empresas fazem é apenas adaptar novas ferramentas a pensamentos antiquados.
  enviado por: Newmar Richard Barbosa Costa em 01/07/2009 - 01:07
• Sou programador a 10 anos e concordo com o autor! Nada mais a complementar.
  enviado por: freddy em 30/06/2009 - 20:36
• Excelente entrevista. Dá quase um artigo! rss... Eu acredito que o desenvolvimento ágil é uma tendência e que as empresas que não se adequarem vão, no mínimo, perder dinheiro. Discordo do Anônimo no sentido de que todo projeto, grande ou pequeno, pode ser subdividido em partes menores. Como disse o entrevistado na matéria, isso é mitigar os riscos. Quem garante as peças se "encaixando" no final de cada módulo é a arquitetura do projeto, não a forma de gerenciamento do mesmo. Entretanto, infelizmente a quebra de paradigmas é fundamental nesse processo de mudança e muitas empresas não estão dispostas a isso.
  enviado por: Diego Marcos Miranda em 30/06/2009 - 15:26
• Ótima a entrevista! Mantenho ainda uma opinião que é divergente do Anônimo. Projetos grandes são os que podem mais se beneficiar com práticas ágeis. Participei de alguns projetos grandes com mais de 2 anos de duração e quando aplicamos práticas ágeis como Daily Meetings, Sprint Plannings e Sprint Retrospective a qualidade aumentou muito e o tempo de desenvolvimento foi significativamente reduzido. Porém, uma coisa é fato, não é fácil implementar práticas ágeis, além de força de vontade é necessário que a equipe seja muito comprometida, caso contrário as práticas irão fracassar em pouco tempo. Tem até um artigo que fala, desenvolvimento ágil não é para preguiçosos http://visaoagil.wordpress.com/2009/06/07/agile-nao-e-para-preguicosos
  enviado por: Marcos Sousa em 30/06/2009 - 12:49
• Legal a entrevista. Continuo com a impressão de que desenvolvimento ágil funciona em projetos pequenos, onde toda burocracia usual, citada pelo entrevistado, acaba por inviabilizar o trio preço/qualidade/prazo. Mas em projetos grandes, como garantir que as peças irão se encaixar no final? Porque terei que trabalhar em várias frentes. Alguns projetos ou são entregues no prazo ou não servem para nada (produtos sazonais, promoções, ...); então prazo é algo muito importante e não pode esperar e inspiração.
  enviado por: Anônimo em 30/06/2009 - 11:39
• Grande entrevista! Conheço muito do trabalho do Akita, e este é um cara que admiro muito, pela sua iniciativa em métodos ágeis e a tecnologia Ruby on Rails. Ele esteve no último FISL aqui em Porto Alegre, infelizmente não pude ir, mas gostaria muito de conhecer esta figura. Aguardo uma nova oportunidade! Abraço.
  enviado por: Nicolas Faccin Iensen em 30/06/2009 - 08:49

comentar