Estudos mostram que as metodologias de desenvolvimento ágil geram resultados melhores. Então porque tão poucos CIOs já a adotaram?
por Thomas Wailgum, CIO/EUA
O termo “programação ágil” significa coisas diferente para cada pessoa, mas todas as metodologias de desenvolvimento ágil têm os seguintes princípios básicos: os envolvidos da área de negócio são alocados em pequenas equipes autônomas de desenvolvimento; as equipes apoiam-se menos em requisitos e documentação e mais em conversas frente a frente; estas conversas resultam em um diálogo contínuo para design, teste e redesenho de software. O redesenho constante, dizem seus defensores, produz ferramentas de negócio mais oportunas e úteis.
O surgimento do método de desenvolvimento ágil foi uma resposta direta ao doloroso histórico de fracassos de projetos de software, custos superiores ao previsto e insatisfação do negócio com o modelo tradicional — a metodologia em cascata pela qual o desenvolvimento se desdobra lentamente em uma série de etapas, abrangendo análise de requisitos, design, implementação, teste, integração e manutenção.
Tudo isso leva a uma pergunta óbvia: se o desenvolvimento ágil é tão bom, por que não foi adotado universalmente?
CIOs de empresas de todos os portes dizem que abandonaram totalmente ou estão descontinuando aos poucos as metodologias tradicionais de desenvolvimento. Mas os processos cascata, na verdade, não ficaram para trás. Não por coincidência, os CIOs estão buscando ajuda para gerenciamento de projeto ativamente.
O problema do modelo ágil
O ritual do desenvolvimento de software está profundamente impregnado em TI. Nos processos tradicionais, o negócio atira os requisitos para os desenvolvedores por cima do muro, os desenvolvedores se escondem e começam a codificar como lhes convém. Um prazo de 18 meses pode parecer décadas. Tardes perdidas são lugar comum. Quem liga para o que os “lusers” (termo pejorativo com o qual os codificadores se referem aos “usuários”) querem realmente?
Conceitos errôneos sobre o desenvolvimento ágil ainda existem nas organizações de TI. Os mais deploráveis são: as equipes ágeis não planejam; pulam a fase de design; não testam; ágil significa inexistência de documentação. Por conta disso, arquitetos corporativos, gerentes de projeto e profissionais de garantia de qualidade também fizeram oposição ao métodos ágil. A preocupação dos arquitetos corporativos era a de que não houvesse design inicial suficiente e que a consequência disso fosse código espaguete. Equipes de desenvolvimento ágil são auto-gerenciáveis e a função de líder de projeto muda drasticamente — das ordens à facilitação. E, visto que o teste de QA acontece ao longo de todo o processo, e não só no fim, o pessoal de teste também costumava oferecer resistência.
Esses profissionais estão entre os que apostaram que o desenvolvimento ágil era apenas “mais uma onda”. Alguns simplesmente disseram: não vou fazer isso. Estes programadores estão levando uma rasteira do desenvolvimento ágil.
Tudo isso contribui para atrapalhar a aceitação do ágil, afirma John Scumniotales, um dos criadores do Scrum. “É fácil falar sobre o valor de criar software desta maneira, mas, se estou apostando minha empresa neste projeto, a gerência-sênior precisa ter alguns controles e visibilidade do processo”, observa. Scumniotales cita a necessidade de contar com uma ferramenta ágil específica que funcione como um gráfico de Gantt, ilustrando visualmente o progresso do projeto. “É onde precisamos chegar.”
Maior alinhamento
Há seis anos, os líderes de TI da Farm Credit Services decidiram “dar uma sacudida”. A equipe adotou o Scrum, que suporta repetições de instruções de duas semanas, reuniões diárias e análises e testes freqüentes, com o objetivo de ter produtos potencialmente prontos para liberação a cada duas semanas.
Resultado: na Farm Credit chegaram a existir seis equipes de desenvolvimento compostas de um analista de negócio, um líder de projeto, um desenvolvedor-chefe, dois ou três desenvolvedores, um engenheiro de banco de dado, um a três “donos” do negócio e um engenheiro de QA. Em vez de requisitos, as equipes de desenvolvimento escrevem “histórias de usuários” à medida que o projeto avança, detalhando melhorias de funcionalidade e tecnologia, sucessos e desafios. As histórias de usuários são o principal mecanismo para transmitir as necessidades do negócio. Antes, os projetos apresentavam a média de 100 defeitos por lançamento. A média, agora, fica entre zero e dois.
Comoo exemplo da Farm Credit Services demonstra, os métodos de programação ágil demandam diálogo contínuo entre o negócio e TI. O entrelaçamento dos membros das equipes de negócio e TI promove uma ligação que costuma estar ausente no desenvolvimento tradicional de software. Se algo não está indo bem, partilham com você no ato.
De acordo com os CIOs que adotaram métodos ágeis, as mudanças no relacionamento com a área de negócio podem ter resultados surpreendentes.
Tendo em vista que as equipes ágeis são grupos autônomos de agentes de rápida mudança que tomam decisões de negócio críticas “on the fly”, as leis antes imutáveis do gerenciamento de projeto passaram por uma transformação radical. Como o tempo de desenvolvimento de 18 a 24 meses, típico do modelo tradicional, é reduzido drasticamente para duas semanas, cada dia de desenvolvimento e cada conversa se torna crítica.
No departamento de TI da Farm Credit Services, as manhãs começam com uma reunião da equipe e uma lista do que cada um é responsável por fazer naquele dia. Eles não querem “perder dias.”
Por que tantos CIOs são indiferentes ao desenvolvimento ágil de software?
Scott Ambler, especialista em desenvolvimento ágil que trabalhou como líder de práticas na IBM, suspeita que muitos desenvolvedores, analistas de requisitos e profissionais de dados e teste estão preocupados com as consequências desta mudança na carreira. “Provavelmente participaram de um grande número de fracassos e, com frequência, têm menos poder para mudar as coisas. Pior ainda, a ameaça do outsourcing paira sobre suas cabeças”, diz Ambler.
A função do CIO é administrar a ansiedade e garantir que sua equipe enfoque a produção de software de ótima qualidade de maneira oportuna e eficaz em termos de custos. “Na comunidade ágil, a única medida de progresso de um projeto de desenvolvimento de software é a entrega de software funcional”, enfatiza Ambler. “A comunidade de desenvolvimento tradicional perdeu isso de vista.”
Mas ceticismo continua a ser a palavra mais usada quando perguntam a CIOs e analistas por que tantos líderes de TI têm mostrado indiferença em relação ao desenvolvimento ágil de software. Eles se deparam com este termo em conferências ou artigos e ele soa bem, mas poucos CIOs defendem de fato os processos de desenvolvimento ágil.
Sem o apoio do CIO e de personagens influentes da área de negócio, não é possível usufruir as eficiências de tempo e custo do gerenciamento de projeto e desenvolvimento de software da metodologia ágil. Na Farm Credit Services, a iniciativa ágil atraiu a atenção e o apoio do CEO. A mentalidade ágil proliferou no resto da organização. O CIO Dave Martin sabia que tinha tomado a atitude certa quando descobriu que as equipes de negócio estavam realizando reuniões diárias e espelhando as práticas de TI.
De CIO que nada sabia sobre desenvolvimento ágil nem conhecia ninguém que estivesse adotando desenvolvimento ágil, Martin transformou-se em um evangelista, disseminando a mensagem em conferências, feiras e cafés da manhã com CIOs. “Eu não posso nem pensar em voltar para a metodologia antiga. Os processos ágeis promovem desenvolvimento sustentável”, afirma.
Chegou a hora de mudar de ideia
Os resultados da pesquisa State of Agile Development Survey, realizada em 2011 com um total de 6.042 líderes de projeto, são mais uma prova de que ágil não é uma moda passageira. Mais da metade dos entrevistados pratica ágil há mais de 2 anos. Quase dois terços dos entrevistados disseram que até metade dos projetos de sua empresa foram executados com metodologias ágeis, e que sua empresa adotou práticas ágeis por 3 ou mais equipes.
Por outro lado, a pesquisa também revelou um aumento no número de empresas que atualmente não praticam ágil, mas pretendem fazê-lo no futuro (17% este ano, contra 13% no ano passado). Dos já praticando ágil, um terço vai continuar a fazê-lo, e apenas 3% disseram que não pretendem continuar.
Três fatores despontam como as principais razões para a adoção de abordagens ágeis para o desenvolvimento de software: acelerar otime to market, gerenciar as mudanças de prioridade e aumentar a produtividade.
Confira os resultados mais relevantes da pesquisa:
Fonte: http://cio.uol.com.br/gestao/2012/10/31/em-busca-de-agilidade/
