BT

O Agile realmente traz mais rapidez?

por Ben Linders , traduzido por Antonio Filho em 22 Mar 2013 |

Estudos mostram que projetos ágeis podem ser mais velozes, como o Projeto Columbus descrito na pesquisa "Provas de sucesso para projetos ágeis". Como o Agile pode ser usado para aumentar a velocidade das entregas?

No seu post Quem disse que o desenvolvimento ágil não pode ser rápido?, Matthew Heusser compartilha uma discussão que teve em uma conferência de testes ágeis:

No Dia de Testes Ágeis em Potsdam, na Alemanha, Lisa Crispin e Janet Gregory fizeram a afirmação ousada de que é um mito que o Agile signifique maior velocidade.

Mais tarde, na conferência, Janet Gregory explicou para Matthew Heusser o que quis dizer com isso:

"O objetivo do Agile não é a velocidade. Pode ser um subproduto dela, mas a aceleração não é certa de acontecer. ... Uma conversão para o Agile reduz a rapidez, pelo menos no curto prazo. E esse curto prazo pode ser de alguns anos."

Matthew Heusser, entretanto, fornece vários argumentos pelos quais considera que a agilidade pode aumentar a rapidez das entregas, e explica como se pode ignorar algumas exigências que não valem a pena, para economizar tempo. Ele também questiona algumas comparações com métodos tradicionais:

Comparar uma equipe ágil que não conseguiu entregar alguma coisa pronta em um ano com uma equipe mais tradicional é uma falsa comparação. Em um ano, a equipe tradicional terá dezenas de requisitos "prontos", um caos e nenhum produto entregável.

Matthew conclui explicando porque discorda e como acha que o Agile pode ajudar a tornar equipes mais rápidas:

Uma pergunta permanece: aumenta a rapidez? Crispin e Gregory argumentam que isso não importa. Focar em pura velocidade no curto prazo leva a atalhos, sofrimento e baixo desempenho no longo prazo. Mesmo assim, defendo que as equipes podem se concentrar em eliminar o desperdício, aumentando a velocidade e melhorando o processo.

No post Tornando o Agile mais rápido, Chris Turner considera os motivos para projetos ágeis se tornarem lentos. Ele descreve quatro razões frequentes e dá sugestões de como lidar com elas:

  • As pessoas erradas: remova as pessoas da equipe que não estão seguindo as boas práticas de engenharia ou que complicam coisas simples;
  • Colocar o processo primeiro: estabeleça uma comunicação aberta, e estimule a criação de equipes auto-organizadas e capacitadas;
  • Usar as tecnologias erradas: dê ao time autoridade para tomar decisões relacionadas à tecnologia e permita que escolhas tecnológicas sejam desfeitas se elas atrapalharem as entregas;
  • Tornar a arquitetura muita complexa: mantenha seu software tão simples quanto possível; refatore.

Neil Killick descreve como pedir a uma equipe ágil para acelerar além de certos limites pode retardar o desenvolvimento do software. Killick conta uma história sobre uma equipe ágil capaz de entregar em média 10 histórias em cada sprint de duas semanas, e que foi obrigada a aumentar o número de histórias entregues:

Imagine que pedimos à equipe para assumir apenas uma história a cada Sprint. Não podemos ter certeza absoluta, mas podemos considerar que uma história será entregue e que será de qualidade extremamente alta. Se pedirmos à equipe para entregar duas histórias por Sprint, provavelmente a equipe irá entregar, mas a probabilidade será menor que com uma história apenas. Então temos um pouco menos de previsibilidade.

Agora imagine que estamos sofrendo para atender a um prazo contratual, de modo que sentimos a necessidade de "acelerar". Pedimos para a equipe que entregue de 10 a 12 histórias, previsivelmente (acima da capacidade). Ou mesmo 14... O quanto "mais rápido", menos previsível se tornarão as entregas e prazos, e maior a probabilidade de a qualidade ser inferior.

Killick aconselha que as equipes trabalhem em um ritmo sustentável, que permita que a equipe encontre o equilíbrio correto e entregue software de alta qualidade dentro de sua capacidade. Com isso, um ciclo de sucesso será criado.

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.