O grupo de estudos da Lambda3 de Agilidade começou uma série de brown bags, encontros que fazemos para conversar sobre algum assunto durante o almoço, na Lambda3 sobre agilidade, como intuito de disseminar o conhecimento, estamos em um contexto que entraram muitas pessoas novas na empresa e então resolvemos voltar ao básico e fazer um sobre Agilidade. Nossos brownbags tem duração de uma hora, isso nos dá o tempo de aproximadamente 45 mim para falar sobre o assunto, por ser um tema tão amplo não permite explora-lo por completo, observei o que os novos colaboradores já tinham absorvido sobre agilidade (principalmente os técnicos como testes e processos de build e de cerimonias) e pontos que dentro deste contexto agregaríamos para a Lambda3, vamos então para os 4 tópicos que foi discutido:

•  De onde e porque a Agilidade nasceu e se faz necessária.

O Boom da Internet junto com o bug do milênio criou uma pressão de demanda muito grande na comunidade software que estava fazendo cair a qualidade, anterior a isso o crescimento da complexidade dos softwares exigiu que a comunidade desenvolvesse processos para facilitar a gestão do conhecimento e foi buscar paralelos em outras comunidades, um modelo que se consolidou foi baseado nas engenharias. Isso estava se mostrando como um caminho com muitos problemas pois estávamos desperdiçando a versatilidade do desenvolvimento de software. Dentro deste contexto, um grupo de pessoas que já vinham pensando nisso a muito tempo se reuniram para organizar um novo paradigma para a computação baseado mais em padrões de comportamento tratando mais o lado humano, deste encontro nasceu o Manifesto Ágil que é um conjunto de diretrizes e comportamentos que basearam as práticas ágeis.

Além disso muitos projetos de software falham e tem muitas funcionalidades não utilizadas você pode observar isso nas pesquisas do CHAOS REPORT.

• Ágil é ser rápido?

Não, a velocidade da metodologia ágil está muito mais em o “não fazer” do que em ser rápido, o foco é entrega de valor, uma equipe ágil deve focar nas funcionalidades que agregam mais valor, as 36% mais utilizadas como no gráfico a cima, e ter cuidado de dosar o tempo em tarefas que melhorem a produtividade e qualidade do código e preparação de funcionalidades que não serão entregues no momento com tarefas que gerem funcionalidades que o cliente veja funcionando na entrega parcial.

• Escolha de historias e tarefas

Para a escolha das histórias que agregam mais valor para o software tem dois pontos que temos que observar:

Valor de Negócio: É o quanto de benefício essa história vai trazer para o negócio, isso as vezes é um pouco difícil de extrair do cliente quando ele não está tão habituado aos processos ágeis, nesta situação normalmente para ele é “tudo importante”, existem técnicas para ajudar o cliente neste filtro, mas não vamos aborda-las aqui.

Complexidade de Implementação: É qual a complexidade de implementar a história, ou seja, qual vai ser o esforço para colocar a história em funcionamento é importante aqui tomar cuidado principalmente com áreas que não é a equipe que vai ser responsável em realizar as tarefas, como acesso a softwares de terceiros e questões de infraestrutura e segurança. Esses são pontos que deve ser constantemente revisitado pois há uma evolução do entendimento durante a evolução do desenvolvimento.

Esse gráfico mostra a relação entre complexidade de implementação e valor de negócio. No 1º quadrante temos alta complexidade e alto valor, no 2º alta complexidade e baixo valor e assim sucessivamente.

Dentro do que já falamos no começo deste post seria natural pensar que começar com as histórias do 4º quadrante pois temos baixa complexidade e alto valor, ou seja vamos entregar alto valor e rapidamente, mas não, devemos dar mais atenção e tentar atacar primeiro as histórias de 1º quadrante (alto valor e complexidade), pois são essas as histórias que podem trazer o fracasso ao projeto, está é a área critica do projeto, e como no gráfico do CHAOS REPORT sobre o uso das funcionalidades as histórias do 2º quadrante não devem ser implementadas.

• Projeção

Um dos grandes problemas que vejo nos times ágeis é o da projeção, isto é, quando um membro do time, ou o time como um todo tenta fazer o exercício de “pensar como” o cliente ou como o usuário e falha. É natural do ser humano quanto tenta fazer esse exercício falhar, o melhor que você tem a fazer é validar suas hipóteses e colher feedback constante do cliente e preferencialmente do usuário. Já ouvi diversos causos de softwares que demoraram muito para entrar em produção e depois de ter sido investido milhões descobriu que sua utilidade era questionável e até mesmo em situações mais simples onde eu mesmo recebi uma história do cliente e não validei com o usuário, depois de implementada tive retrabalho para adaptar a necessidade do usuário pois o cliente ainda não tinha o entendimento completo da história e achava que tinha.

É isso aí, essas são apenas algumas pequenas pílulas de agilidade, muito importantes para o seu projeto dar certo. Resumindo tudo isso em uma frase:

“Ser ágil está muito mais em ser pragmático do que ser rápido.”

Just Do it!

Roberto Rodrigues