Desenvolvimento Ágil: o que seu chefe deve saber?

De acordo com um estudo da Evans Data (registro é necessário), mais da metade dos desenvolvedores americanos estão utilizando algum tipo de metodologia de desenvolvimento ágil. Parece que alguns chefes desta turma toda nem sequer conhecem os benefícios da abordagem ágil para o desenvolvimento de sistemas.

No Brasil, sempre pobre em estatísticas, não encontrei uma pesquisa que indicasse qual o porcentual dos desenvolvedores brasileiros que fazem uso de alguma metodologia ágil. Imagino que tenhamos um cenário semelhante ao dos E.U.A. Se você pesquisar no Google Scholar, verá que nossas universidadem produzem muita pesquisa sobre estas metodologias.

Neste artigo do CIO.com, o autor lista 7 pontos importantes que todo gerente de software (e desenvolvedor) deveria saber sobre métodos ágeis.

1. Permitem o Desenvolvimento de Software de Melhor Qualidade

Foco nas funcionalidade, no que o software irá fazer, revisões com pares (peer reviews), processos mais leves liberando o desenvolvedor da burocracia pesada das metodologias tradicionais… …tudo isto produz softwares de melhor qualidade.

2. Promove uma Mudança na “mentalidade” do time de desenvolvimento

Não é apenas um processo, metodologias ágeis promovem uma “nova atitude” na forma como o software é desenhado e implementado. Segundo o consultor Mike Sutton (Wizewerx.com), ocorre uma mudança da forma de pensar. A adoção é um processo, por vezes, doloroso pois “…força as organizações as organizações e indivíduos a confrontar o desperdício, ineficiência e falta de informação”. Ainda segundo ele, os desenvolvedores nerds vão precisar conversar uns com os outros e com o resto do mundo. Pasmem!

3. Mudanças ágeis além do tradicional “fluxo de desenvolvimento”

A adoção de metodologia ágil produzi um impacto na cultura da organização. intensa colaboração, feedback constantes, formas não tradicionais de acompanhamento de projeto, reuniões curtas e objetivas (meu sonho!)… …tudo isto é confrontado com um processo já estabelecido (o status quo).

Se problemas surgirem, e eles irão surgir, não culpem a nova metodologia. Eles já estavam aí, a nova abordagem apenas mostrou os problemas de forma mais explícita. Vejam o que afirma um outro consultor (Steven Gordon):


…collaboration brings to the surface a lot of issues, problems and obstructions in the organization. Do not kill the messenger, Gordon urges; agile is not creating these issues, only making them more apparent. CIOs have to prioritize and address the problems. “If the organization appears to be ignoring these issues after they are surfaced, people will come to believe that the agile principles make no difference and will go back to just minding their own business and doing their jobs in isolation…

4. Ágil não Significa “Caos é Bom”

Existe uma idéia pré-concebida de que tais métodos trarão uma “bagunça” para o processo. Agilidade não significa desorganização.

Por outro lado, nem todo projeto pode utilizar uma metodologia deste tipo. Esta abordagem se encaixa muito bem para aqueles desenvolvimentos (que precisam ser feitos) rápidos e cujos requisitos não estão claros(!).

(eu sei, todos nossos projetos também são assim…)

5. Benefícios de uma Metodologia Ágil Compensam a Espera

Como toda mudança os benefícios não serão vistos imediatamente. Segundo o artigo, quem adotou não quer voltar atrás.

Um grande benefício é que, devido a iterações mais curtas, a equipe de TI pode verificar os riscos mais cedo e as decisões de “go/no-go” serão feitas nas fases iniciais.

6. Não existe a “Bala de Prata”

Não se engane, a metodologia ágil não será a “salvação da lavoura”. Programadores ruins continuaram ruins. Veja outro trecho:


Give competent and invested people agile, and you’ll have happier
people doing better work more rapidly. Give incompetent, unempowered
people agile (or even worse, just the word agile), and you’ll still fail


7. Sucesso Depende das Pessoas

Ainda bem. Desenvolvedores gostam de ver suas criações em ação. Nada é mais frustante do que ver todo seu esforço criativo, para construir uma solução de software, ser arquivado ou abortado. Já participei de vários projetos de software que não tiveram continuidade. É altamente desmotivador.


Com um processo ágil o time que implementa pode ver o resultado mais rápido e isto motiva ainda mais, apesar de todos os problemas de requisitos incompletos e a eterna insatisfação dos usuários.