Gestão
7 dicas de desenvolvimento ágil para CIOs
Por CIO
Compartilhe:
O consultor George Dinwiddie, da iDIA Computing, sugere usar um gráfico burn-down para acompanhar o progresso do projeto. O gráfico mostra como o progresso está convergindo (ou não) para a “linha do gol” [?meta] e permite que um gerente saiba quando tomar uma atitude. “Esta atitude pode ser mover a linha ou mudar o modo como o software está sendo produzido para tentar acelerá-lo.”
Quando um desenvolvedor pergunta ao cliente da área de negócio sobre um recurso, recebe feedback relativo ao objetivo pretendido. O cliente pode ver, a partir da evolução incremental do software, quão bem ele funciona. “O feedback deve ser gerado com o mínimo de demora possível. A redução do tempo entre o momento em que uma decisão é tomada e validada compensará em termos de redução do desperdício”, comenta Dinwiddie.
Outro efeito é maior colaboração... contanto que a gerência reconheça seus efeitos colaterais. “Todos na organização devem colaborar tendo em mente os objetivos organizacionais finais, em vez de se fechar e executar isoladamente as tarefas que lhes foram designadas”, diz Steven Gordon, coach autônomo de desenvolvimento ágil de software.
Observação: esta colaboração traz à tona uma série de questões, problemas e obstáculos reinantes na organização. Não mate o mensageiro, implora Gordon. O desenvolvimento ágil não está gerando nada isso, apenas tornando mais evidente. Os CIOs têm que priorizar e resolver os problemas. “Se a organização der sinais de que ignora estes aspectos depois que eles vêm à tona, as pessoas vão começar a acreditar que os princípios ágeis não fazem diferença e vão voltar a se fechar e trabalhar isoladamente.”
No sentido mais amplo, um efeito de longo prazo do desenvolvimento ágil pode ser a honestidade. “Não medirei minhas palavras: se você não puder ser honesto, não conseguirá fazer desenvolvimento ágil com êxito”, declara Mishkin Berteig, presidente da Berteig Consulting. “A honestidade é a base das práticas, é a base até mesmo dos princípios. Se você observar o Manifesto Ágil, verá que a idéia da honestidade é o alicerce da comunicação, das interações humanas, da construção e das relações entre cliente e fornecedor.”
Berteig se surpreende com a freqüência com que este conceito é uma revelação para os executivos. “A maioria das culturas organizacionais no mundo corporativo são baseadas na desconfiança e na falta clara de honestidade. A mudança para a cultura da honestidade é profunda, demorada e difícil – como qualquer outra mudança de cultura!”
Ainda assim, pergunta Borteig, como você pode aprender com os inevitáveis erros sem a cultura da honestidade? Como pode uma organização criar relações com clientes mutuamente benéficas? Como você pode ter certeza de que, no fim de cada iteração, não só a equipe está realmente entregando o que diz que está entregando, como também as partes interessadas realmente querem o que dizem que querem? “Processos e procedimentos burocráticos tradicionais, freqüentemente, são resultado da falta de honestidade e da tentativa de compensar esta falta”, acrescenta Berteig.
4. Ágil não significa que o “caos é bom”
Os gerentes que se sentem confortáveis com metodologias “um passo de cada vez” podem se sentir desconfortáveis com a natureza iterativa do desenvolvimento ágil. Mas desenvolvimento ágil não significa desorganização.
Embora o método ágil contemple seus adeptos com a capacidade de reagir a condições do mercado e repriorizar requisitos, não exclui planejamento de longo prazo, arquitetura, padrões ou gerenciamento de projeto, ressalta Isaac Sacolick, vice-presidente de tecnologia da BusinessWeek e, antes disso, fundador da TripConnect. “As empresas têm que avaliar como e onde aplicar o desenvolvimento ágil.”
O como e o onde importam. Poucos desenvolvedores acreditam que a metodologia ágil é apropriada para todos os tipos de projetos e equipes – e esperam que o CIO saiba quando deixá-la de lado. “O modelo ágil de desenvolvimento é ideal para mudanças de requisitos rápidas e caóticas”, ensina Marshall Presnell, arquiteto de desenvolvimento da Village Voice Media.
Gary Rowe, programador de aplicações Web Java do Landmark Information Group, recomenda o método ágil para projetos nos quais os requisitos de clientes são incertos ou mudam.
Onde seria uma escolha errada? Segundo John Miano, proprietário da Colosseum Builders, o método ágil não é adequado para projetos que terão uma longa vida útil e exigem confiabilidade total.
As organizações que adotam os princípios ágeis não mudam os fundamentos da definição de problemas. “Desenvolvimento ágil não significa que você não faça análise de requisitos e design”, diz Mike Emeigh, gerente de garantia de qualidade da Deltacom. Boas equipes ágeis fazem análise de requisitos e design, opina Emeigh. “Elas só não desperdiçam muito tempo com quilos de papel, nem obrigam um bando de indivíduos que, possivelmente, não são capazes de captar todas as questões, tentar estudá-as e entendê-las antes de entregar software funcional.”
Mas. Certamente. não é fácil para um gerente acompanhar a natureza iterativa do desenvolvimento ágil, em que desenvolvedores e usuários trabalham juntos para projetar e criar a aplicação. Os CIOs querem conhecer o status de cada projeto na empresa, mas ágil implica que requisitos e cronogramas estão sempre mudando. Os adeptos insistem que é um pressuposto errado.
Conheça os 100 melhores CIOs do país
60 melhores empresas de TI e Telecom para trabalhar
A elite do RH de TI e Telecom no Brasil
Computerworld e Instituto GPTW apresentam as Melhores Empresas de TI e Telecom para Trabalhar 2009.
Veja o Especial
