Maturidade 2 em Métodos Ágeis – Práticas Nascentes

Como discutimos no nosso post de  Aumento de Maturidade em Métodos Ágeis, a implantação de métodos ágeis é um processo gradativo e contínuo, baseado na inspeção e adaptação do que funciona e do que não funciona. Neste novo post, iremos discutir o efeito das práticas ágeis no desempenho de projetos tradicionais.

Compartilho uma experiência pessoal para mostrar como a forma tradicional de trabalho tende a gerar (imenso) desconforto para usuários finais. Fui nesta semana a uma operadora de telefonia para fazer a compra de um chip e uma mudança de plano. Cheguei 13:02 e fui informado que precisaria esperar quase 40 minutos para ser atendido. Com a variabilidade da fila e senhas preferenciais, somente fui atendido 14:12. Logo após ser atendido, o gerente da loja tentou durante 4 minutos me convencer a buscar um plano que não queria. Às 14:16 ele compreendeu o que eu queria. Ele preencheu um cadastro e então me fez a venda de um chip. Saí da loja 14:22, a tempo de ir para uma reunião que tinha 14:30 a um quarteirão de distância em um cliente. Felizmente cheguei a tempo, mas fiquei muito apreensivo de ter que desistir da compra por causa do meu compromisso as 14:30. Além disso, fiquei consideravelmente irritado com a longa espera.

Paradoxalmente, a perspectiva do gerente deve ter sido boa. Ele me atendeu em apenas 10 minutos e deve ter pensado: “Como sou eficiente. Fiz uma nova venda e conquistei um novo cliente em apenas 10 minutos”.

Esta pequena experiência cotidiana parece não ter a ver com métodos ágeis, mas tem forte relação. Considere aqui os conceitos de tempo de serviço, tempo de espera e tempo de ciclo (lead time). O meu tempo total de ciclo foi de 1:20 horas (80 minutos), embora o tempo de serviço tenha sido de apenas 12 minutos, sendo que destes apenas 8 foram realmente úteis. Esta relação foi de 10/1, muito ruim em minha opinião.

Curiosamente, a minha experiência na observação de times que trabalham em modelos cascata mostra coisas muito semelhantes. Os trabalhadores pontuais (analistas, arquitetos,  desenvolvedores, testadores e gerentes) acreditam que estão trabalhando pesadamente. E provavelmente estão. Mas as filas formadas no sistema geram um pesado efeito de espera para usuários finais. Curiosamente, a maior parte destes trabalhadores ignora este efeito (como o gerente da operadora). Os usuários de TI, entretanto, percebem pesadamente este efeito. Demandas de TI de apenas 16 ou 20 horas demoram semanas ou meses para serem entregues. Isso também é muito ruim, o que impacta pesadamente a imagem da TI para os usuários de negócio.

E como métodos ágeis podem ajudar?

Métodos ágeis são um arcabouço poderoso de princípios e práticas que podem ser agregadas a cultura de qualquer empresa. O mais interessante é que estas práticas não são prescritivas, i.e., você pode determinar que conjunto faz mais sentido na sua realidade e aplicar.

Por exemplo, vamos falar de filas. Filas nascem porque existem pessoas que estão trabalhando em compassos diferentes, porque a capacidade do ambiente não foi corretamente dimensionada, porque existem repasses desnecessários ou porque existem esperas artificiais. Por exemplo, vou voltar ao meu caso da operadora para ilustrar uma pequena mudança, que exigiria colaboração com o cliente.

  1. O cadastro que o gerente da loja preencheu tinha apenas os meus dados pessoais (e nada além). Eu poderia ter efeito este trabalho em um computador instalado na loja, gerando uma requisição. Cinco minutos, com folga para beber água.
  2. A requisição seria recebida por um atendente de pagamento, que pegaria o chip no estoque, me cobraria 12 reais em dinheiro e me desejaria boa tarde. Mais cinco minutos, com folga para o cafezinho do atendente.
  3. Dez minutos depois, teríamos o mesmo efeito financeiro para a loja, mas o cliente estaria muito mais satisfeito.

De volta aos métodos ágeis. Analistas, desenvolvedores e testadores que trabalham em silos, com comunicação baixa e baseada em papel geram filas, retrabalho e um pesado efeito de espera para os usuários finais.

Vamos buscar uma alternativa, baseada em colaboração. Já aprendemos que esperas e filas são seres do mal. Se você puder atacar apenas um vilão em sua empresa, este vilão seriam as esperas e filas que se formam . Ao eliminar os handoffs artificiais entre os papéis, eliminamos filas internas. Todos trabalham no mesmo ritmo, no mesmo compasso, preparando o mesmo entregável em base diária.

Esta prática de colocar pessoas no mesmo compasso é chamada de Todo o Time (Whole Team), amplamente usada no Scrum, XP e outros métodos ágeis. Assim como esta práticas, existem outras dezenas de práticas ágeis, que combatem outros males organizacionais.

E como posso implementar isso na minha realidade?

Trate cada princípio e prática como um experimento. Por exemplo, capture uma nova demanda e prepare um terreno diferente para sua execução.

Considere as seguintes ideias no seu experimento.

  1. Envolva o cliente para maior colaboração  e reduzir esperas nas dúvidas ao longo da demanda.
  2. Posicione o analista, desenvolvedor e o testador juntos, com contato visual e conversando como seres humanos. Nada de baias (para cavalos) ou comunicação através de email.
  3.  Tenha o analista, desenvolvedor e testador operando no mesmo compasso, capturando requisitos, desenvolvendo e testando micro-incrementos de produtos em base diária. Pense pequeno, mas pense de ponta a ponta com micro-entregas diárias.enha
  4. Estabelça um ritual diário para o time coordenar o seu trabalho.
  5. Tenha demonstrações frequentes para o usuário chave e colete feedbacks sobre o software executável sendo construído.

Faça um experimento rápido. Uma semana deve ser suficiente para o seu processo de análise da prática todo o time.

Avalie os resultados do experimento. Provavelmente você irá perceber alguns pontos positivos. E também perceberá coisas que você e o seu time ainda não fez tão bem. Talvez até exista uma falha do experimento. Isso é natural, pois o time está aprendendo a jogar um novo jogo.

Estabeleça no final da demanda um ritual chamado de kaizen, onde você irá avaliar o que funcionou bem e o que pode melhorar. Isto é a melhoria contínua.

Após o primeiro experimento, considere novos experimentos. Uma mesma prática pode ser repetida, de forma modificada ou mais elaborada. Ou você pode tentar outra prática.

Conheço times que fazem isto há meses, experimentando e adaptando práticas nascentes na sua organização. É a maturidade 2 da implantação dos métodos ágeis. Os resultados destes times são positivos, pois os problemas escondidos há anos surgem. E eles então devem ser resolvidos. À medida que eles começam a ver resultados, em base semanal, a confiança aumenta (e os resultados também). Menos defeitos, tempo de ciclo reduzido, mais colaboração, mais transparência. É o caminho para a eficiência monetária e satisfação sendo pavimentada na sua empresa.

No próximo post, iremos discutir a maturidade 3, que lida com a consolidação das práticas ágeis por times em uma organização

 

Maturidade 1 em Métodos Ágeis – Reconhecimento

Muitos times e organizações desconhecem que eles não desempenham bem. Isso é muito natural e faz parte da limitação humana em compreender o efeito das suas ações no desempenho dos sistemas onde estão inseridos.

Mas o que é um sistema? Convido você a investir alguns minutos do seu tempo para assistir o vídeo abaixo, que apresenta o conceito de forma brilhante: Em Um Mundo de Sistemas (YouTube).

O desenvolvimento de software é também um sistema. E um sistema complexo, infelizmente. Os efeitos das ações tomadas nem sempre geram os efeitos desejados.

Algumas ações comuns na indústria parecem muito naturais e eficazes, tais como:

. especificar todos os requisitos antes que a primeira linha de código seja construída;

. especializar funções e otimizar a comunicação através de emails e documentos;

. testar apenas quando o código estiver pronto;

. reduzir o custo do desenvolvimento de produtos através da contratação de pessoas mais baratas;

. comandar e controlar o trabalho das pessoas;

. adicionar pessoas a um projeto atrasado para colocá-lo no trilho novamente.

Curiosamente, todas estas ações acima geram efeitos contra-intuitivos, i.e, eles tendem a gerar efeitos destrutivos no sistema. Um exemplo (levemente mais elaborado que o vídeo anterior) é mostrado por Craig Larman no diagrama abaixo.

xsystemsp20thinking-15-pagespeed-ic-wns033qpdz

Fonte: Craig Larman – Pensamento Sistêmico

Embora o desenho pareça complicado, ele mostra que existe um efeito defasado no tempo e no espaço na qualidade de um produto a partir da contratação de desenvolvedores baratos, que por sua vez gera um efeito negativo na produtividade do produto. É um exemplo de uma dinâmica negativa, tomada por uma ação que parece correta (contratar mais pessoas, mais baratas, para aumentar a produtividade do produto).

Reconhecer, pois, as armadilhas dos métodos tradicionais é o primeiro ponto para aumentar a maturidade do seu trabalho e do seu time em direção à melhoria de produtividade trazida pelos métodos ágeis. Trabalhar este reconhecimento requer que você comece a desenvolver uma habilidade de “atenção correta”, i.e., perceber conscientemente o que acontece ao seu redor.

Uma dica simples para começar a ter ciência do seu ambiente é o uso de reuniões de lições aprendidas, que deve ser executada em base semanal ou base quinzenal. Nesta reunião você convida todo o seu time e executa a seguinte dinâmica:

  1. Primeiro, o time avalia o que funcionou. Os fatos positivos devem ser capturados e escritos em um quadro branco ou cartolina. Enquanto facilitador, você deve incentivar o seu time a relatar tudo o que foi bom durante o período da avaliação.
  2.  Depois, você avalia o que não foi tão bom. Os fatos negativos também devem ser capturados, mas sem julgamentos ou acusações. Assim como os fatos positivos, os fatos negativos também devem ser escritos em um quadro branco.
  3. Finalmente, cada ação marcada na lista dos fatos negativos deve gerar uma ou mais ações de melhoria. Esta lista é fundamental e será perseguida pelo time no próximo ciclo de trabalho.

Métodos ágeis são desenhados a partir das premissas que o sistema onde um software é desenvolvido não é linear, i.e, a sua dinâmica complexa emerge a partir das interações entre seus atores. Para lidar com este tipo de ambiente, métodos ágeis estão baseados em um processo contínuo de experimentação e adaptação. Instrumentos como as reuniões diárias, reuniões periódicas de demonstraçao (revisão) e a coleta de lições aprendidas (retrospectiva) são exemplos neste sentido.

Iremos abordar os  princípios e práticas fundamentais dos métodos ágeis no nosso próximo post, onde discutiremos o segundo nível de maturidade de métodos ágeis dentro de uma escala de maturidade de adoção de métodos ágeis.