Recursos/White Papers

Gestão

Dois maiores inimigos do gerenciamento ágil

Agile pode ser uma ótima opção, mas o que você pode fazer para garantir que não seja a mais frágil?

David Taber, CIO/EUA

Publicada em 31 de março de 2018 às 07h55

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 Waterfall, 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.

Embora seja um fanático de carteirinha por Agile, tenho que admitir que ele tem suas fragilidades. Até escrevi uma lista sarcástica das melhores maneiras de sabotar projetos ágeis. Mas essa lista era mais sobre um monte de sintomas a evitar, em vez de algo que realmente podemos medir para definir limites para um projeto.

Vamos examinar os dois maiores inimigos do gerenciamento ágil de projetos e ver como eles podem ser medidos.

1 - Distância
O termo “programação ágil” por significar coisas diferentes de acordo com o interlocutor, mas todas as metodologias de desenvolvimento ágil têm os seguintes princípios básicos: participantes das áreas de negócio alocados em pequenas equipes autônomas de desenvolvimento; equipes apoiadas menos em requisitos e documentação e mais em conversas frente a frente; conversas que 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.

Como consequência, a proximidade física ajuda. Recomendamos que os membros da equipe não estejam fisicamente distantes uns dos outros.

Com a distância física, vem a maior oportunidade para o mal-entendido ou atrasos. Mesmo que os membros da equipe estejam em andares diferentes do mesmo edifício, você precisa de mais postos de controle e de comunicação redundantes para manter todos em sincronia.

O horário de trabalho escalonado também torna a comunicação muito mais difícil. É preciso considerar a questão de fusos horários quando as equipes estão de países diferentes.

Falando nisso, as coisas podem complicar muito quando a equipe extrapola as fronteiras nacionais. Não é apenas uma questão de linguagem. A cultura de gestão e a capacidade de se comunicar tendem a ser pontos dolorosos. Isto é particularmente problemático quando uma cultura é muito direta, mas a outro é muito sutil e se vergonha de comunicar qualquer informação negativa.

Há ainda um outro eixo de distância que não deve ser desconsiderado: a distância no organograma. Uma equipe Agile prospera colmatando as lacunas e fazendo conexões diretas entre desenvolvedores e usuários. Parte da magia é minimizar os buffers burocráticos que isolam os membros de equipe e tornam a colaboração mais vulnerável.

Claro, técnicas e truques de gestão podem atenuar cada uma dessas questões. É incrível o quão eficaz até mesmo serviços gratuitos como o Google Drive e o Google Hangouts podem melhorar a colaboração remota. Mas cada uma dessas técnicas requer um pouco de disciplina e envolve algum custo para o projeto. Quando você tem que levar todos os custos em conta, a flexibilidade e a velocidade do Agile podem ser postas à prova.

Para nós, estar no local acaba por ser um melhor negócio para o cliente e, ao mesmo tempo, menos doloroso do que a tentar gerir os recursos offsite .

Outros grandes desenvolvedores ágeis, no entanto, têm uma abordagem diferente: mantêm no local analistas de negócios, arquitetos e o pessoal de suporte executivo, e os desenvolvedores fora. Cada produto é especificado no local, ao lado do cliente, e cofificado fora. Esta extensão do modelo ágil funciona bem para projetos maiores.

A melhor métrica, então, é saber o percentual de membros da equipe que não estão no mesmo prédio. Qualquer coisa abaixo de 20% é insignificante, algo entre 20% e 49% requer uma atenção especial, e qualquer coisa acima de 50% requer processos específicos, ferramentas e redundâncias para manter os projetos de trabalho.

Agile

Tempo
É irônico que a velocidade e a capacidade de resposta do desenvolvimento ágil possa ser a raiz de vulnerabilidades.Se você atrasar um projeto ágil apenas algumas semanas, você pode precisar redefinir prioridades. Por quê?

Em qualquer processo de negócio importante, as coisas evoluem, às vezes muito rapidamente. Se um projeto ágil foi concebido, e em seguida, congelado, enquanto o processo de negócio e o organograma evoluíram, então a os requisitos que definiam as prioridades para um sprint podem ter sido definidos incorretamente ou até mesmo de forma irrelevante.

Para usar uma analogia ruim, ágil são como vegetais frescos, melhores para o seu consumo, mas eles não têm o prazo de validade dos alimentos enlatados.

Este efeito é particularmente grave quando os orçamentos permanecem imutáveis. O que você pensou que iria custar antes de todas as interrupções, alterações de membros da equipe, modificações limiares, critérios e valores da lista de opções não é o que vai custar no final, mesmo que nenhum dos requisitos seja alterado.

Atrasos e longas interrupções de um projeto ágil suscitam questões mais profundas: o projeto não é tão importante, serve como um jogo político , tem objetivos que são um alvo em movimento ou foi simplesmente mal concebido.

Há uma consequência desagradável em atrasos e interrupções. Eles corroem a confiança e a credibilidade, de todos. As empresas têm uma memória muito curta, mesmo que as pessoas tenham uma impressão duradoura. Uma vez que a confiança é o ingrediente fundamental de colaboração e a colaboração estreita, por sua vez, é o fundamento do desenvolvimento ágil, os atrasos são devastadores.

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. 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.

Claro que o atraso faz com que a data de conclusão seja protelada, mas também provoca aumento do escopo. Mesmo que nada mude, o delay multiplica a curva de aprendizado e os custos de gerenciamento de configuração. Iniciar e parar um projeto ágil com bastante frequência é fazer com que as derrapagens sejam inevitáveis.

Ness caso, a melhor métrica está na percentagem de interrupções e do atraso cumulativo. Qualquer coisa abaixo de 50% é desprezível, principalmente se você tem ciclos de duas semanas, qualquer coisa entre 50% e 150% requer uma atenção especial, e qualquer coisa acima de 150% indica que o projeto já está em apuros.

Otimizar um projeto ágil significa minimizar  tempo e espaço. Se a distância e o atraso são realidades para sua equipe, certifique-se de aplicar todas as medidas defensivas para que você possa pensar e atuar em gerenciar as expectativas dos usuários e detentores do orçamento.

A função do CIO é administrar a ansiedade e garantir que sua equipe foque na 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.



Reportagens mais lidas

Acesse a comunidade da CIO

LinkedIn
A partir da comunidade no LinkedIn, a CIO promove a troca de informações entre os líderes de TI. Acesse aqui