BT

Novidades O InfoQ vem desenvolvendo uma série de novas funcionalidades para melhorar sua experiência com o site. Confira!

Seis maneiras em que o Ágil pode se tornar estático

| por Ronit Eliav Seguir 0 Seguidores , traduzido por Eduardo Kuwakino Seguir 0 Seguidores em 18 set 2017. Tempo estimado de leitura: 9 minutos |

Pontos Principais

  • Agilidade requer arquiteturas adaptativas. Se não há um processo de design formal, o código pode ser construído em cima de código legado e, até o resultado final, será um design inflexível.
  • Nem todas as ferramentas são criadas igualmente para a agilidade do desenvolvimento e de negócios. As duas necessidades precisam ser atendidas em uma ferramenta única para atender a todos os usuários.
  • O desenvolvedor “lobo solitário” está ultrapassado: evidências mostram que equipes mais diversificadas produzem trabalhos melhores, com colaboração sendo o fator chave para o sucesso.
  • Escalar projetos ágeis de larga escala envolve uma grande visibilidade e colaboração entre os múltiplos papéis e entre equipes.
  • Hoje em dia, projetos podem começar sem requisitos claros e definidos, por isso, Gerentes de Projeto devem buscar ter um planejamento contínuo e ciclos de feedback.

A transformação digital requer que as organizações de TI se tornem facilitadoras de negócios que entreguem experiências diferenciadas aos clientes, e que provenham retorno de investimento. Para se manterem atualizadas com inovação, e entregar resultados imediatos, muitas equipes de TI adotaram as metodologias de desenvolvimento ágil nas quais cadências de entrega são medidas em dias, não em trimestres, e a qualidade é garantida.

Este pode ser o Santo Graal, mas esse objetivo nem sempre é possível. Idealmente falando, desenvolvimento ágil tem todos os elementos corretos, mas não é aplicável a todos os projetos. Vamos considerar como ele funciona no melhor cenário possível.

O desenvolvimento ágil acelera a entrega de valor de negócio inicial por um processo de planejamento e feedback contínuos. Como resultado desses planejamentos iterativo e ciclos de feedback, as equipes são aptas a continuamente alinhar entrega de software às necessidades de negócio desejadas, se adaptando facilmente a mudanças de requisitos durante o processo, e medindo e avaliando a situação do projeto baseando-se numa visibilidade precisa do progresso atual de todos os estágios e com todos os envolvidos. Como resultado de processos ágeis, na conclusão de um projeto, o software atende melhor às necessidades do negócio e dos clientes.

Tudo pode soar lógico e racional, mas, geralmente, a realidade de projetos ágeis pode ser um pouco diferente. Metodologias ágeis nem sempre entregam os resultados esperados.

Aqui estão seis formas comuns que projetos ágeis podem falhar.

  1. Arquitetura insustentável - O Manifesto Ágil diz: "Contínua atenção à excelência técnica e bom design, aumenta a agilidade." e há uma forte tendência a "arquiteturas adaptativas". O segredo de ser ágil é ter apenas o suficiente de design antecipado. O problema é saber quanto de design é o suficiente. Se o processo de design é minimamente alterado, sem um processo formal, código pode ser gerado em cima de código legado, e até o resultado final será um design inflexível. Diferente da arquitetura em cascata, em que sistemas são rigidamente definidos antecipadamente, o desenvolvimento é uma atividade com data definida de início e fim. A arquitetura ágil é um processo contínuo que possibilita mudanças na arquitetura quando necessário. Um design pode ser coerente em uma sprint planning, mas pode não ser suficiente em um modelo de arquitetura formal e sustentável a longo prazo.
  2. Limitação das ferramentas - Metodologias ágeis são comumente limitadas a ferramentas existentes. Atualmente o mercado de ALM (Enterprise Application Lifecycle Management) é dominado por monolitos, na promessa de soluções com entregas em "cascata" e falta de elementos chave da metodologia ágil. Nesse meio tempo, a indústria de software foi pelo caminho das melhores abordagens com ferramentas ágeis como: Jenkins, VersionOne, e RallyDev, sendo que essas ferramentas não foram criadas para as necessidades de Corporações de TI. Elas foram desenhadas para serem usadas por engenheiros de software e não usuários de negócios que não são preparados, motivados, nem alocados em treinamentos formais para aprender como prover feedback de performance em testes funcionais. Além disso, esses sistemas podem ser custosos para aquisição ou manutenção, pois podem incluir funcionalidades que têm excessivos e desnecessárias demandas de computação e hardware.
  3. Lacuna Cultural - Alguns desenvolvedores acostumados a trabalhar de forma autônoma podem achar que toda colaboração requerida pelo desenvolvimento ágil pode atrasá-los. Muitos irão resistir às mudanças na forma de trabalhar em uma metodologia altamente colaborativa se estão acostumados a uma grande liberdade. Indivíduos brilhantes e altamente motivados geralmente só querem de você as ferramentas que precisam, e ser deixados para fazer seu melhor. Porém, eventualmente todos em um projeto ágil precisam ser mais flexíveis. O Quadrante Mágico do Gartner para Serviços de Testes em Aplicações de 2016 estima que até 2020, 60% dos recursos em testes necessitarão de um conjunto de habilidades de testes, habilidades em desenvolvimento de aplicações, e habilidades em processos de negócio ou de indústria. Dado o nível que as mudanças acontecem em um projeto hoje, a ideia do desenvolvedor "lobo solitário" sentado em algum lugar sem se comunicar com ninguém não faz sentido - colaboração é um fator chave de sucesso. Há muitas evidências de que quanto mais diversificada uma equipe, melhores resultados ela produz. Não faria sentido "colocar as pessoas no programa" e criar alguma habilidade social?
  4. Dificuldade em escalar - Metodologias ágeis são tradicionalmente mais populares em pequenas e médias organizações, mas recentemente têm se tornado padrão em grandes empresas. Comparado a pequenos projetos, onde o desenvolvimento ágil é o ideal, projetos grandes necessitam de coordenação adicional. Um problema particular em aplicar ágil em grandes projetos é como controlar a coordenação entre equipes. Ágil em larga escala envolve preocupações adicionais na comunicação com outras unidades organizacionais, como os recursos humanos, marketing e vendas, e gerenciamento de produto, pois a metodologia é amplamente dependente em relacionamentos de trabalho próximos e muito feedeback dos usuários. Conforme o projeto cresce a comunicação que flui deve aumentar exponencialmente. Além disso, conforme as empresas se expandem geograficamente, ou se fundem com outras organizações, projetos também são dispersos entre diferentes equipes em diferentes locações. Sem uma abordagem consistente nos locais e nas ferramentas de comunicação para visibilidade em tempo real dos ciclos de testes distribuídos por diversas equipes de desenvolvimento e testes, gargalos podem ocorrer e resultar em atrasos e custos adicionais ao projeto.
  5. Não ser o tipo correto de projeto - Métodos tradicionais (como cascata) funcionam melhor em projetos que estão no final dos dois espectros; requisitos claros e imutáveis que são estabelecidos ou a abordagem de uma nova tecnologia sem usuários anteriores que podem prover feedback. Apesar de que projetos longos estão se tornando menos prevalentes. A natureza VUCA (volatilidade, incerteza, complexidade e ambiguidade) de ambientes de negócios significa que mais de 60% dos requisitos irão mudar em um projeto de 12 meses, portanto o fim "fixado" do espectro é um mito. Não existem "requisitos claros e imutáveis" em sistemas desenvolvidos hoje - a tecnologia muda rapidamente, as necessidades dos clientes são emergentes, a legislação muda frequentemente e "Vou saber quando chegar" - "I'll know it when I see it" (IKIWISI - do Rapid Application Development, 1986) - é a realidade da necessidade dos usuários. Gerentes de projeto precisam avaliar projetos para analisar se um pequeno grupo de desenvolvedores autônomos pode ser mais adequado e uma solução de custo mais efetiva para projetos que acabam na metade. Projetos que possuem muitos e diversos grupos de usuários em uma matriz estruturada podem também não se adequar a metodologias ágeis. Por exemplo, em pirâmides estruturais, é comum o número de equipes trabalhando juntas acabam sendo maior que o projeto realmente necessita. O problema pode piorar quando os membros dessas equipes estão parcialmente alocados gerando menos comprometimento.
  6. Atolar-se em colaboração - Para as equipes de desenvolvimento se beneficiarem ao máximo das metodologias ágeis seus membros precisam ver, sentir e ouvir seus usuários numa base diária. Mas a realidade de muitos projetos hoje é que os diferentes membros não são tão próximos, ou não estão disponíveis para comunicação cara-a-cara. Depender de comunicação por e-mail pode retardar a comunicação e abrir a erros. Minha própria experiência com empresas mostra que mais de 50% das organizações estão utilizando Microsoft Office como Word ou Excel ou mesmo papel e caneta para gerenciar aspectos das entregas como testes. Quando equipes de diferentes localidades físicas, e geralmente geograficamente separadas usam ferramentas de comunicação para capturar todos os diferentes tipos de informação e acelerar o fluxo de informações, geralmente fazem melhoria no processo e resultado final, tornando as equipes mais fortes e produtivas. Ferramentas previnem processos de travarem, porque um único grupo de testes está responsável ou um usuário de negócios envolvido com testes de aceitação sai de férias sem se lembrar de executar os procedimentos. Uma vez que comunicação e coordenação - ambos, internamente e com clientes - é geralmente difícil devido a logística, localização e timing, um modelo de comunicação de ponta a ponta para colaboração de equipes ágeis é essencial para ajudar às pessoas a trabalharem juntas e mais efetivamente.

Desenvolvimento ágil no contexto correto permite que organizações disponibilizem software de alta qualidade, que muda rapidamente para avançar negócios. Só não funciona o tempo todo. Sucesso exige colaboração, transparência e visibilidade em tempo real dos riscos e qualidade do projeto.

Considere utilizar técnicas de mapeamento de histórias de usuário, mapas mentais e quebra de histórias de usuário para melhor divisão do que parecem soluções grandes e complexas em pequenas partes independentes que podem ser rapidamente implementadas para pegar feedback rápido do usuário. Você quer olhar para o futuro longe o suficiente para identificar e fazer o que for necessário para entregar valor agora e possibilitar entregar valor no futuro.

Mantenha as linhas de comunicação abertas e automatize a comunicação de todo feedback, incluindo resultados de testes, mudanças de prioridade, e retestes para fazer as coisas rodarem sem problemas. Ao mesmo tempo admita as limitações da metodologia e se seus especialistas insistem em trabalhar independentemente, e se uma matriz inchada torna todas as linhas de feedback ingerenciáveis, não há vergonha em admitir as limitações do Ágil e voltar à velha metodologia em cascata.

No final do dia estamos construindo produtos que nossos clientes podem usar e fazê-los felizes. Estar preparado para frequentemente adicionar novas funcionalidades baseadas no feedback dos clientes os tornará ainda mais felizes. Como cliente de software, não há coisa pior que investir em um produto que não funciona, não faz o que preciso fazer, e não posso ver um caminho para torná-lo melhor. Estou disposta a comprar a primeira iteração de um produto se sei que ele irá melhorar com o tempo. De fato, ao adotar metodologias ágeis, pode ser divertido ver o produto emergir conforme a equipe de desenvolvimento continuamente o melhora. Ágil nos ajuda a construir este tipo de parceria com nossos clientes, em que trabalhamos juntos para resolver problemas.

Apesar das complexidades das metodologias de desenvolvimento ágil, dadas as condições e ferramentas corretas, equipes de TI podem implementar metodologias ágeis que avançam negócios e solidificam relacionamentos duradouros com clientes.

Sobre a autora

Ronit Eliav é Diretora de Marketing de Produtos na Panaya, Reliav@panaya.com. Ronit é uma experiente líder pensadora em temas de transformação digital como Ágil e Entrega Contínua, DevOps, e otimização de processos de negócios, e uma líder de projetos na modernização de TI, em mobilização e integração de projetos. Da estratégia e análise ao lançamento em mercado, Ronit é a especialista e a proprietária de ponta a ponta do portfólio de Marketing da Panaya.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT