Tempo e distância são os maiores inimigos do Agile

A gestão ágil de projectos pode ser uma óptima opção, mas o que você pode fazer para garantir que seu o projecto ágil não se torna frágil, questiona David Taber, CEO da SalesLogistix.

O surgimento do método de desenvolvimento ágil é uma resposta directa ao doloroso histórico de fracassos de projectos 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 numa série de etapas, abrangendo análise de requisitos, design, implementação, teste, integração e manutenção.

Embora seja um fanático por Agile, mesmo eu tenho que admitir que a agilidade tem as suas fragilidades. Até escrevi uma lista sarcástica das melhores maneiras de sabotar projectos á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 o projecto.

Vamos examinar os dois maiores inimigos da gestão ágil de projectos e ver como podem ser medidos.

Distância
O termo “programação ágil” significa coisas diferentes 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 equipas autónomas de desenvolvimento; as equipas apoiam-se menos em requisitos e documentação e mais em conversas frente a frente; estas conversas resultam num diálogo contínuo para design, teste e redesenho de software. O redesenho constante, dizem os seus defensores, produz ferramentas de negócio mais oportunas e úteis.

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

Com a distância física, vem a maior oportunidade para os mal-entendidos ou atrasos. Mesmo que os membros da equipa 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 equipas estão em países diferentes.

Por falar nisso, as coisas podem complicar-se muito quando a equipa 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 directa, mas a outra é muito subtil e se envergonha 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 equipa Agile prospera colmatando as lacunas e fazendo ligações directas entre desenvolvedores e utilizadores. Parte da magia é minimizar os “buffers” burocráticos que isolam os membros da equipa 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 projecto. 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, arquitectos e o pessoal de suporte executivo, e os desenvolvedores fora. Cada produto é especificado no local, ao lado do cliente, e codificado fora. Esta extensão do modelo ágil funciona bem para projectos maiores.

A melhor métrica, então, é saber a percentagem de membros da equipa 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 projectos de trabalho.

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

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

Para usar uma fraca analogia, ágil é como vegetais frescos, melhores para o seu consumo, mas 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 equipa, 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 projecto ágil suscitam questões mais profundas: o projecto não é tão importante, serve como um jogo político, tem objectivos que são um alvo em movimento ou foi simplesmente mal concebido.

Há uma consequência desagradável nos 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 obrigam a diálogo contínuo entre o negócio e as TI. O entrelaçamento dos membros das equipas de negócio e de TI promove uma ligação que costuma estar ausente no desenvolvimento tradicional de software. De acordo com os CIOs que adoptaram 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 orçamento. Mesmo que nada mude, o atraso multiplica a curva de aprendizagem e os custos de gestão de configuração. Iniciar e parar um projecto ágil com bastante frequência é fazer com que as derrapagens sejam inevitáveis.

Nesse 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 projecto já está em apuros.

Optimizar um projecto ágil significa minimizar  tempo e espaço. Se a distância e o atraso são realidades para a sua equipa, certifique-se de aplicar todas as medidas defensivas para que possa pensar e actuar em geriar as expectativas dos utilizadores e detentores do orçamento.

A função do CIO é administrar a ansiedade e garantir que a sua equipa se foque na produção de software de óptima qualidade de maneira oportuna e eficaz em termos de custos. Na comunidade ágil, a única medida de progresso de um projecto de desenvolvimento de software é a entrega de software funcional.
(CIO/IDG Now!)


Tags


Deixe um comentário

O seu email não será publicado