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

29/03/2018 às 19h01

Agile_763394284.jpg
Foto:

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.

Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail