Thomas Wailgum - CIO (EUA)
Publicada em 07 de dezembro de 2007 às 11h57
Estudos mostram que as metodologias de desenvolvimento ágil geram resultados melhores. Então porque tão poucos CIOs já a adotaram?
A Farm Credit Services of America não parece ser uma organização do tipo que fomenta controvérsias. Esta cooperativa concede empréstimos a mais de 66.000 fazendeiros e pecuaristas da região centro-oeste dos Estados Unidos para a compra de bois, porcos, tratores, enxadas e outras coisas do gênero. Sua principal razão de existir — fornecer 11 bilhões de dólares em financiamento de capital operacional e imobiliário a quem alimenta a América — é tão acolhedora quanto as imagens de plantações de milho, pastagens verdejantes e fazendeiros rijos e determinados que adornam seu material de marketing.
A cooperativa está sediada em Omaha, Nebraska, região conhecida mais pelos filés do que pelo laboratório avançado de uma das metodologias de desenvolvimento mais comentadas em TI: a programação ágil. Mas agilidade foi exatamente o que a Farm Credit Services abraçou, e com força total.
A vantagem do ágil
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 apóiam-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. ( leia mais sobre o assunto em “O ABC da programação ágil”)
O surgimento do método de desenvolvimento ágil é 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. No entanto, apenas 17% das empresas norte-americanas e européias utilizam processos de desenvolvimento ágil, de acordo com a pesquisa “Enterprise Agile Adoption in 2006”, realizada pela Forrester Research.
Mas a Farm Credit Services recebeu bem a programação ágil. “Tínhamos os requisitos, criávamos as aplicações, mas ninguém ficava satisfeito no final”, diz Dave Martin, CIO da cooperativa. Um projeto em particular, a migração de um sistema de processamento de aplicações de clientes baseado em mainframe para uma versão Web chamada PinPoint, tinha mais de 200 páginas de requisitos e foi concluída em 2004, depois de transcorridos quase três anos. Neste ínterim, os requisitos e as necessidades de negócio mudaram e a maioria dos membros da equipe de negócio original já não estava mais lá. O sistema resultante, repleto de bugs, foi deixado de lado pouco depois de sua estréia questionável.
Isso nada tem de incomum. Segundo pesquisa sobre a situação do desenvolvimento ágil (“State of Agile Development”) realizada em 2006 pela Agile Alliance e pela Version¬One, apenas 29% dos projetos tradicionais foram ”razoavelmente bem sucedidos” ou “muito bem sucedidos”. Em comparação, 81% dos projetos ágeis alcançaram igual nível de sucesso.
O Standish Group, que compila o famoso relatório Chaos sobre fracassos de projetos de software, reportou na pesquisa de 2006 que somente 16% dos projetos feitos no modelo tradicional tiveram êxito, contra 41% dos projetos ágeis. Jim Johnson, chairman do Standish Group, estuda fracassos de projetos há anos e não entende por que as empresas ainda resistem ao desenvolvimento ágil. “Dizer que empresas ou CIOs estão relutantes em adotar o método ágil é o mesmo que dizer que eles não tomariam uma aspirina para dor de cabeça”, compara. “Além de não tomarem a aspirina, eles estão batendo a cabeça contra a parede e se perguntando por que dói.”
A adoção do ágil
Há dois anos, Martin, da Farm Credit Services, decidiu “dar uma sacudida”. Depois de receber uma leve cutucada de Lou Thomas e Beth Schmidt, diretores de desenvolvimento de aplicações, 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. “Nossa premissa é ter produtos potencialmente prontos para liberação a cada duas semanas”, explica Thomas.
Na Farm Credit existem 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”, diz Martin. Antes, os projetos apresentavam a média de 100 defeitos por lançamento. A média, agora, fica entre zero e dois. “Lançamos cinco produtos-chave com resultados fenomenais”, revela Martin. “Em todos os casos, os donos do negócio ficaram extasiados com o resultado final.”
Ágil em qualquer lugar? Nem tanto.
CIOs de empresas de todos os portes dizem que abandonaram totalmente ou estão descontinuando aos poucos as metodologias tradicionais de desenvolvimento. “Não sou do tipo que prometo tudo em 18 meses”, afirma Raymond Dury, CIO da Fifth Third Bancorp que adotou um método ágil chamado Extreme Programming.
Mas os processos cascata, na verdade, não ficaram para trás há tempos. Além do já mencionado estudo da Forrester (somente 17% usavam o ágil em 2006), uma pesquisa realizada em março de 2006 com leitores da revista Software Development e do Dr. Dobb’s Journal descobriu que 60% não estavam utilizando nenhuma metodologia ágil em suas organizações.
Não por coincidência, os CIOs estão buscando ajuda para gerenciamento de projeto ativamente. De acordo com a última pesquisa da CIO norte-americana, quase 75% dos leitores estão “extremamente interessados” ou “muito interessados” em descobrir como podem melhorar a disciplina de gerenciamento de projeto. Tudo isso leva a uma pergunta óbvia: se o desenvolvimento ágil é tão bom, por que não foi adotado universalmente?
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?
“Muita gente na arena de TI achou que ágil era apenas a ‘onda’ do mês”, lembra Martin. “Alguns simplesmente disseram: não vou fazer isso.” (Estes programadores, segundo Martin, levaram uma rasteira do desenvolvimento ágil). Arquitetos corporativos, gerentes de projeto e profissionais de garantia de qualidade também fazem oposição ao métodos ágil. A preocupação dos arquitetos corporativos é que não haja design inicial suficiente e que a conseqüência disso seja 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 costuma oferecer resistência.
Conceitos errôneos sobre o desenvolvimento ágil ainda existem nas organizações de TI. Eugene Nizker, ex-CIO de serviços financeiros e atualmente consultor, cita os mais deploráveis: as equipes ágeis não planejam; pulam a fase de design; não testam; ágil significa inexistência de documentação.
Além disso, os executivos podem se sentir distantes dos “scrums” e “sprints” diários da vida ágil, o que gera insegurança nos níveis mais altos. 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.”
Mas, dadas a magnitude dos fracassos das metodologias em cascata, os CIOs devem a si mesmos e às organizações tornarem-se ágeis. “O mundo não pára e espera 18 meses”, afirma Dury, da Fifth Third Bancorp.
Estudo de caso: chegada rápida no mercado
Dury não abandonou os processos tradicionais de desenvolvimento em sua empresa, que possui quase 100 bilhões de dólares em ativos. Alguns projetos de desenvolvimento, como os que afetam a infra-estrutura básica ou os projetos de SOA intensivos, simplesmente “não conseguem lidar com a forte mudança” que acompanha as metodologias ágeis. Mas ele está entusiasmado com a adoção de Extreme Programming.
O chefe da linha de produtos de varejo do banco conversou com o CIO sobre um novo produto que queria vender, uma ferramenta de investimento (batizada posteriormente de Stock Power CD) que oferecia aos clientes potenciais ganhos baseados no mercado de ações para seus certificados de depósito. Na realidade, o banco estava lutando para se recuperar. “Provavelmente estávamos para trás em relação ao mercado para este tipo de produto”, reconhece Dury, “e queríamos atuar no mercado”. Portanto, velocidade era fundamental.
Utilizando táticas baseadas em Extreme Programming, sua equipe debateu soluções que suprissem as necessidades do negócio rapidamente e fossem tecnicamente viáveis. Outras conversas ocorreram com o banco de varejo (muito tempo frente a frente, pouca documentação inicial). Duas equipes de desenvolvimento, trabalhando alinhadas entre si e com os departamentos de consumo e linha de varejo, foram formadas no âmbito de TI: a equipe de consultoria em investimento e a equipe de desenvolvimento do CD. As equipes trabalharam estreitamente ligadas às agências (que venderiam o Stock Power CD) e aos conselheiros de investimentos para satisfazer exigências legais e financeiras.
O Extreme Programming — reuniões diárias e input contínuo do negócio, bem como testes periódicos — “criou a urgência de fornecer este serviço para os clientes o mais rápido possível”, diz Dury. Apenas quatro semanas depois da primeira conversa, várias agências do Fifth Third começaram a oferecer o produto Stock Power CD. “Normalmente, a introdução de um novo produto de depósito levaria aproximadamente de 90 a 120 dias”, observa Dury, acrescentando que o produto gerou “depósitos adicionais significativos”.
Dury não podia imaginar nenhuma outra maneira de realizar este projeto. Além de acelerar o time to market, possibilitou “uma relação de trabalho mais estreita com o lado do negócio” e aumentou a confiança dos clientes internos “na capacidade da TI de estabelecer e cumprir expectativas”.
Maior alinhamento
Como as histórias de Martin e Dury demonstram, 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. “Eles estão junto com você”, diz Ajay Waghray, CIO da Verizon Wireless. “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. Waghray se recorda de conversas recentes com executivos-chave de operações e marketing nas quais ele usou uma abordagem mais ágil. O executivo avisou-os que não queria nenhum requisito. Bastava dizerem o que queriam e eles conversariam sobre o assunto. “Os executivos perguntaram se deveriam anotar o que desejavam. Eu respondi que não, não me dêem requisitos.” Era uma abordagem estranha para as pessoas.
O produto VZ Navigator, da Verizon Wireless, que oferece direções passo a passo suportadas por voz em seus dispositivos móveis e se tornou um dos serviços móveis mais populares da empresa, foi extremamente influenciado pela metodologia ágil. A equipe de Waghray consistia de profissionais de TI, vendas, atendimento ao cliente, marketing, treinamento e finanças. O foco principal, observa Waghray, foi desenvolver a solução “completa, porém simples” imediatamente e depois expandi-la e melhorá-la. “A solução teve êxito porque a metodologia ágil incentivou a comunicação contínua e o alinhamento entre todos os envolvidos, levando ao desenvolvimento paralelo não só da solução de TI, mas também de documentação sobre treinamento, casos de teste, desenvolvimento e validação de interface externa e comunicação com os usuários para prepará-los para o lançamento.”
Parra muitos executivos da equipe, os resultados foram surpreendentes. Eles disseram a Waghray que o projeto deveria ter demorado três vezes mais do que levou, oito semanas do começo ao fim. De acordo com Waghray, o projeto VZ Navigator “teve um impacto significativo e imediato sobre os resultados financeiros e promoveu a capacidade organizacional de fazer o mesmo com produtos similares.”É uma mudança cultural e de timing”, diz Waghray sobre o processo, “mas nunca tinha recebido tantos elogios para um projeto de negócio”.
Gerenciando a mudança ágil
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 de Dury, as manhãs começam com uma reunião da equipe e uma lista do que cada um é responsável por fazer naquele dia. “Não queremos conversar sobre o que será feito daqui a três semanas, mas sobre o que queremos fazer hoje”, ensina Dury. “Não queremos perder dias.”
É obrigação dos CIOs estabelecer novas expectativas — trabalho em equipe, franqueza, colaboração — para todos do grupo. “Existe uma expectativa de colaboração. Você não pode se limitar a trabalhar em seu pequeno mundo”, diz Martin, da Farm Credit Services. “Existe também uma boa visibilidade do trabalho e, em alguns casos, do não-trabalho.”
Os membros da equipe que resistirem, porém, provavelmente ficarão desempregados. (Um antigo ditado persa parece bem apropriado para os CIOs: “O cão ladra e a caravana passa”.) Scott Ambler, especialista em desenvolvimento ágil que trabalha 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 conseqüências desta mudança na carreira. “Provavelmente participaram de um grande número de fracassos e, com freqüê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.”
Por que tantos CIOs são indiferentes ao desenvolvimento ágil de software?
Ceticismo é 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 a pesquisa 2006 “State of Agile” mostra que apenas 5% dos entrevistados apontaram o CIO como o defensor inicial de processos de desenvolvimento ágil. Surpreendentemente, 11% disseram que o presidente ou CEO estava promovendo a aceitação do novo modelo.
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. “Quando as empresas não têm um executivo no nível do vice-presidente ou do CIO promovendo a adoção, elas enfrentam muitos obstáculos”, diz Schwaber, da Forrester. Na Farm Credit Services, a iniciativa ágil de Martin atraiu a atenção e o apoio do CEO. A mentalidade ágil proliferou no resto da organização. O CIO 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. “As unidades de negócio perguntavam como poderiam se tornar mais ágeis.”
A jornada ágil de Martin completou um círculo. 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.”
Fonte: CIO
Outras Referências:
InfoQ: Interview: Jim Johnson of the Standish Group
O 
