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.

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 menssagens dessa discussão
Comentários da comunidade

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

Receber menssagens dessa discussão

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

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT