Profissionais TI - Pra quem respira informação

Muitas equipes abraçam as metodologias e culturas ágeis em busca dos seus benefícios: aceitação das mudanças, ciclos de trabalho menores, arquitetura evolucionária e incremental, e tantas outras. O problema é que nem sempre as coisas saem como se imagina, e é muito comum que a metodologia esteja implantada nos fluxogramas e gráficos de workflow, mas não no dia-a-dia e na cultura de trabalho.

Um primeiro ponto que atrapalha as equipes e organizações a se tornarem ágeis, é a visão de que se trata apenas de uma metodologia quando, na verdade, é muito mais uma cultura e filosofia de trabalho. Pode ser entendido como metodologia no sentido que existe uma formulação formal de “como fazer”. Mas ver a cultura ágil como um corpo de regras apenas e não como uma cultura, não ajuda muito na sua assunção pelas pessoas.

Felizmente, os sinais de que uma abordagem ágil não está funcionando são fáceis de identificar e bem variados. Vamos comentar sobre 5 situações que acontecem com frequência.

1. Confundir “ser ágil” com “fazer ágil”

A diferença entre fazer e ser ágil é maior do que parece. Fazer ágil é encurtar o tempo de entrega, mas não se trata disso. A ideia por trás da cultura agile é de abraçar um novo modo e filosofia de trabalho, de abordagem dos problemas de desenvolvimento. Como um paradigma, uma cultura para o desenvolvimento de software, o fundamental é abraçar a filosofia desenhada no Agile Manifesto, fazer o mental shift do tradicional waterfall para às outras abordagens alternativas.

As técnicas e cerimônias específicas vem como um passo depois, e o “fazer ágil”, vem como consequência de “ser ágil”, e não o contrário.

2. Tratar User Stories como metas

Os features de um sistema a ser desenvolvido (do ponto de vista de usuário) é descrito na abordagem ágil por meio das User Stories. A essas histórias é atribuída uma pontuação para estimar o nível de esforço necessário para implementá-la. E aqui se encontra uma das grandes dificuldades ao se adotar uma abordagem ágil. 

A pontuação dada a uma User Story não é nem uma meta e nem uma espécie de promessa feita pelo desenvolvedor. Os pontos em si não possuem um significado inerente. Trata-se apenas de um acordo informal entre os desenvolvedores sobre o grau de complexidade daquela feature. Isso significa que a pontuação varia de time para time (dependendo da experiência e conjunto de habilidades dos membros).

Ver os Story Points como uma medida de sucesso do andamento dos trabalhos não condiz com seu papel de estimativa de esforço. Solucionar esse problema não é tão difícil, basta definir junto ao product owner qual será a medida usada para acompanhar o trabalho. Algumas empresas adotam as abordagens ágeis de forma mista com antigos cronogramas e processos baseados em marcos e entregas importantes. O importante é usar os Story Points como medida de esforço e definir uma outra medida adequada de “sucesso” ou acompanhamento que não se confunda eles (story points).

3. Comparar a velocidade de times e indivíduos

Olhar para métricas e fazer associações/comparações é um cálculo natural que a maioria dos programadores faz. No entanto, usar a velocidade do time (a média de user stories concluída por iteração), como um meio de comparação e determinação de sucesso, não é um bom sinal.

Comparar a velocidade entre duas equipes não faz sentido, pois os story points são estimados de forma diferente para cada time. Devido ao fato de as equipes serem únicas, comparar a velocidade dessa forma não é eficiente e pode acabar por fomentar competição entre as equipes ao invés de cooperação.

O mesmo se aplica a comparar indivíduos com base na “entrega de story points“. A métrica mais importante, que é a entrega de valor por meio de software funcional, não se enquadra nesse tipo de comparação. Novamente, user stories não são metas e user points são estimativas de esforço apenas.

4. Escrever tarefas ao invés de histórias

Do ponto de vista do objetivo final da abordagem ágil, que é entregar software funcional e de valor para usuários que esperam obter benefícios com ele, é importante desenvolver as user stories como elas devem ser, e não como tarefas. As user storires representam features, aspectos do sistema, do ponto de visto do usuário.

Apesar de que sempre vão haver estórias que se parecem com uma tarefa, é importante ter cada estória escrita em termos de um aspecto ou fração de uma feature junto com os benefícios que ele traz para o usuário. A ideia do user story é manter o desenvolvedor conectado ao usuário. Software sem usuários que vejam valor não possui utilidade. 

A distinção fundamental nesse caso, é que tarefas são feitas pensando nos desenvolvedores, mas user stories são feitas pensando no usuário.

5. Stand-up meetings intermináveis

Os stand-up meeting talvez seja a característica das abordagens ágeis mais conhecida. Os famosos encontros de 5 minutos (ou algo semelhante dependendo da equipe e das customizações) foram pensados como breves cerimônias nas quais os integrantes respondem três perguntas básicas:

• O que foi feito ontem?
• O que está sendo feito hoje?
• Quais problemas estão impedindo o trabalho de avançar? Precisa de ajuda?

E ponto final. A ideia não é discutir, saber os porquês, problematizar questões técnicas e muito menos fazer cobranças ou tomar decisões. A ideia é dar transparência ao que cada um está fazendo e possibilitar que o time se ajude. Detalhes devem ser discutidos em outro momento, depois do fim da reunião.

Por se tratar de um encontro entre pessoas, é fácil que o stand-up se estenda e se torne uma reunião tradicional. Se isto está acontecendo, é um sinal claro de que a metodologia ágil ainda não está assimilada pela equipe. Em geral, existe uma pessoa que é responsável por fazer valer os preceitos da filosofia ágil (um Scrum Master, por exemplo) e é importante que ela atue para lembrar os demais integrantes de se ater às perguntas básicas do stand-up e serem breves. 

Existem vários outros sinais no dia-a-dia que são um bom termômetro sobre como a cultura ágil está assimilada pela equipe. Para cada ponto do manifesto ágil pode-se apontar um exemplo de como “não ser ágil”. De forma mais ampla, a adoção de uma nova cultura de trabalho é sempre um desafio e é natural que um tempo de transição seja necessário. No caso das metodologias ágeis, o mais comum é que customizações e adaptações sejam feitas para se adequar às especificidades da área da empresa ou sua cultura anterior.

No entanto, deve-se ficar atento para que, se tomada a decisão de seguir uma abordagem ágil, realmente implantar os aspectos e preceitos básicos colocados no Manifesto. Uma ótima maneira de adotar uma metodologia ágil é exatamente saber como “não ser ágil”.