Prefácio

Desde 2001, quando o Manifesto Ágil foi publicado, até os dias de hoje, tenho acompanhado o crescimento da comunidade Agile no Brasil. Entre 2001 e 2007, o que chamo de "primeira onda", o Agile era um assunto limitado às catacumbas de um punhado de programadores XP, que viam no Kent Beck um modelo a ser seguido. Nessa gênese da agilidade, o fenômeno era local e bastante fechado.

Passado um tempo, em 2007, aconteceu o primeiro treinamento Certified Scrum Master aqui nas terras tupiniquins, com a presença de inúmeros líderes que até hoje influenciam o mercado. Eu estava lá e, após o treinamento, fizemos uma mesa redonda discutindo "como tomar o mercado das mãos dos tradicionalistas".

Depois desse marco, o ágil saiu de um ritual tribal de alguns desenvolvedores renegados para o grande mercado, e partir daí, bancos, telecoms e diversas organizações de software e serviços de TI começaram a tentar rodar seus sprints e a se adequar ao "mindset ágil". Essa foi a "segunda onda" Agile no país: de um assunto de programadores na primeira onda, o Agile se transformou em um assunto de gestão, em que o Scrum era seu maior expoente.

Quando as conversas migraram de código para gestão, agilistas martelavam ad nauseum as diferenças entre um processo prescritivo (geralmente atacando métodos tradicionais como RUP, PMBOK e CMMi) para um processo empírico (como o XP ou Scrum). Isso foi até positivo, pois educou o mercado um pouco sobre complexidade. Porém, o efeito colateral é que a falta de profundidade nesses estudos levou muitos agilistas a prematuramente afirmar que "desenvolvimento de software é complexo", e por isso a imprevisibilidade inerente desse tipo de sistema impedia qualquer tipo de planejamento, medição e projeção futura, já que no "complexo tudo pode acontecer".

Consequentemente, se desenvolveu no Agile uma alergia ou intolerância a números, estatística e qualquer tipo de avaliação quantitativa de seus ambientes. "Pessoas mais que processos", vociferavam.

Nem preciso dizer que tal narrativa sem planejamento, sem números, sem previsibilidade, sem hierarquia não colou para a maioria dos CIOs, executivos de TI, gerentes de projeto e líderes de equipes no país. Experimentar "o complexo", a inovação e ambientes sem restrições envolve risco e o perfil típico do gestor brasileiro é conservador, fruto de uma sociedade de baixa confiança (tente explicar o que é um cartório para um dinamarquês, americano ou suíço, e espere as risadas). O fato é que a agilidade precisa se reinventar aqui no Brasil para formar uma nova narrativa, e assim cumprir a missão de _tomar o mercado_.

A segunda onda continua e implementações ágeis vão continuar a pipocar aqui e ali de norte a sul do país. Entretanto, a partir de 2012, algumas coisas mudaram. Sob influência do Alisson Vale e da comunidade Kanban, um pequeno movimento tem emergido no Brasil e no mundo.

Esse grupo de pensadores tentam conciliar as complexidades dos ambientes de TI com métricas objetivas, visando principalmente melhoria contínua, garantia da qualidade, aumento da previsibilidade e também análise de risco. O ferramental desses pensadores se resume basicamente a entender seu ambiente de trabalho como um sistema passível de medição e alavancagem (Systems Thinking). Se essa é a terceira onda da agilidade no Brasil, só o tempo vai nos dizer. O que acreditamos é que deve existir um casamento entre soft skills e hard skills de gestão.

Fico muito feliz que este livro tenha sido escrito pelo Raphael Albino, um dos meus alunos de Kanban, pois nossas discussões sempre me renderam bons aprendizados. Creio que este texto serve como apoio a toda comunidade de desenvolvimento de software, não só de agilistas.

Taiichi Ohno, o criador do Sistema Toyota de Produção, e talvez um dos maiores pensadores de gestão do mundo, dizia: "Não é possível ter melhoria sem padrões". Este livro vai ensiná-lo a entender esses padrões e principalmente lhe oferecerá um ferramental que vai ajudá-lo a entender melhor seus problemas começando na próxima segunda-feira.

É muito empolgante ver que muito dos assuntos deste livro estão em constante evolução e as novidades aparecem a cada semana. Temos muito ainda o que aprender sobre a matemática e a estatística de um fluxo de trabalho. Creio que este livro será a literatura base para quem quiser entrar nessa "terceira onda".

- Rodrigo Yoshima

 

Introdução

Toda vez que penso em indicadores e métricas, recordo-me de uma frase de H. James Harrington que diz: “Metrificar é o primeiro passo para o controle e eventualmente para a melhoria. Se você não consegue medir algo, você não consegue entendê-lo. Se você não consegue capturá-lo, você não consegue controlá-lo. Se você não consegue controlá-lo, você não consegue melhorá-lo”.

Antes que você pense que estou fazendo qualquer apologia à cultura do comando e controle, gostaria de compartilhar que, para mim, controle é a capacidade que uma equipe tem de manusear e desenvolver ferramentas que promovam um ambiente de autogestão.

Desde que eu comecei a trabalhar com desenvolvimento de software, tenho lidado com dois pontos de vista quanto às métricas:

1. No primeiro, as métricas são aplicadas como ferramentas que buscam simplificar a equipe em números, e a única razão para coletá-las visa exigir respostas das pessoas e criar conflitos perigosos. Exemplos deste tipo de métricas são número de testes unitários escritos por desenvolvedor, velocidade individual etc.

2. No segundo, as métricas são utilizadas com o intuito de promover ações de melhoria contínua e, a partir das respectivas visualizações, trazem visibilidade sobre a saúde do processo ao time. Além disso, sua análise promove um ambiente em que os cenários dos prazos de entrega são projetados a partir de uma base consciente (interpretação) e consistente (histórico real da equipe).

Dado que estamos em um meio onde queremos entregar melhores produtos de software para os clientes e usuários, incluir em nosso repertório formas de monitorar a eficiência do processo de construção de software se torna algo relevante. Mas, afinal, por que você deve aprender sobre métricas e visualizações do processo de desenvolvimento software?

- Se você trabalha como Agile Coach ou desenvolvendo software em um ambiente ágil e tem interesse em discutir métricas que podem ajudar a analisar a saúde do seu processo de construção. Especialmente se você tem interesse em fugir de análises subjetivas.

- Se você é um Gerente de Produtos, ou Product Owner, e precisa administrar as expectativas dos stakeholders interessados no produto que está em construção ou operação, e está em busca de formas para projetar cenários para as entregas que estão sendo construídas a partir de dados históricos e não de achismos.

- Se você é um CTO ou CIO e busca propor aos times informações úteis para analisar o processo de desenvolvimento e atendimento de demandas, de forma concreta, quantitativa e analítica, buscando promover melhorias a partir de dados.

- Se você acaba de entrar em um departamento no qual o produto é um software e não tem a mínima ideia de quais métricas, variáveis ou visualizações levantar para compreender esse admirável mundo novo.

O livro está estruturado de uma forma que você possa: compreender o universo que suporta um processo ágil (capítulo 1); analisar os desafios de quem busca gerenciar o trabalho em progresso (capítulo 2); visualizar e interpretar o tempo que as demandas têm levado no seu processo (capítulo 3); acompanhar a cadência de entrega (capítulo 4); avaliar a saúde do seu processo (capítulo 5); e, por fim, acompanhar e projetar cenários para a entrega de um escopo (capítulo 6). No último capítulo, compartilharei algumas dicas e considerações finais sobre a temática métricas de processo.

Espero que você encare esta obra como um guia de aprendizado e boas práticas que lhe traga uma maior visibilidade do seu trabalho e aumente a previsibilidade das suas entregas. Sinta-se à vontade para escolher o capítulo que quiser e fizer sentido para o seu dia a dia.

Boa leitura.