Danilo Sato

Qual a melhor forma de medir o sucesso de uma equipe? Os Métodos Ágeis promovem um processo empírico para desenvolvimento de software, baseado na colaboração e no feedback trazido por ciclos curtos de inspeção e adaptação. Encontrar maneiras eficazes de avaliar o processo e a equipe não é uma tarefa simples. O senso comum leva à decomposição e à proliferação de diversas métricas baseadas na premissa de que se cada parte do processo for otimizada, os resultados do processo como um todo serão otimizados também. Quando critiquei o modelo hierárquico do IO-Map, minha preocupação era justamente essa. Ao tentar micro-otimizar partes de um sistema por meio de diversas métricas, o objetivo verdadeiro se perde em meio a tantos outros substitutos e a equipe perde sua capacidade de tomar decisões num nível mais macro.




Um outro problema com métricas bastante conhecido (o Vinícius comenta sobre isso em um dos seus podcasts) é que as pessoas geralmente se comportam de acordo com a forma que são avaliadas. Robert Ausin, no livro Measuring and Managing Performance in Organizations, discute os problemas da avaliação de desempenho baseada em métricas e destaca que sua principal vantagem (“Você tem o que você mede”) é também sua principal desvantagem (“Você tem exatamente o que você mede, e nada mais”). Métricas manipuláveis serão manipuladas. Esse é o lado triste da história.




Por isso queria aproveitar esse post curto para discutir uma classificação interessante, que pode te ajudar a refletir quando estiver pensando em utilizar uma nova métrica.

Métricas Organizacionais

Também conhecidas como “métricas de avaliação” na abordagem Lean. São as métricas que medem o sistema como um todo, no nível mais alto. Elas medem o quanto de valor seu processo consegue entregar. A abordagem Lean sugere uma prática conhecida como Measure Up, onde você usa uma medida de avaliação que foge do controle de qualquer sub-parte do processo, incentivando a colaboração entre os indivíduos de diferentes equipes e evitando a micro-otimização. Essas métricas-chave devem ser geralmente escolhidas pelo cliente ou quem quer que espera extrair algum valor do sistema. Como consequência dessa prática, você acaba ficando com um número muito menor de métricas. Recentemente apresentei na XP@Rio alguns exemplos de métricas organizacionais:

• Cycle Time: métrica Lean mais conhecida que mede o tempo médio para que seu processo atenda uma nova requisição. Essa métrica geralmente surge depois que a equipe entende seu Value Stream Map e o conceito importante é que ela começa a contar com o cliente e só termina quando o cliente é atendido.
• Métricas Financeiras: o investimento de muitos projetos de software é justificado com base na melhoria de alguma métrica financeira. Essa métrica pode ser o Retorno de Investimento (ROI), Net Present Value (NPV), uma matriz de lucros e perdas ou coisas desse tipo. Como uma equipe consegue melhorar esses números de outra forma que não seja entregando o software?
• Satisfação do Cliente: Se você está preocupado em entregar valor para seu cliente, o quão satisfeito ele está? Uma métrica sugerida pela Mary e pelo Tom para medir isso é o Net Promoter Score, uma medida simples que verifica se seus clientes recomendariam seu produto para outro cliente.

Métricas de Acompanhamento

Também conhecidas como “métricas de diagnóstico”, “indicadores” ou “métricas informativas”. Elas são medidas internas da equipe que auxiliam na melhoria do processo, através dos ciclos de inspeção e adaptação. Essas métricas agregam dados, mas não os associam com nenhum indivíduo, assim como não devem ser atreladas ao valor que está sendo entregue. Seu ciclo de vida também é geralmente mais curto. Uma vez que o processo evoluiu, elas se tornam desnecessárias e devem ser descartadas. Novas métricas de acompanhamento deverão surgir conforme a equipe avança e o ciclo continua, em busca da melhoria contínua.

Um exemplo amplamente utilizado desse tipo de métrica é a velocidade. Espera-se que, após um certo tempo, a velocidade do time se estabilize (se nenhum fator externo acontecer, como mudança de membros da equipe ou mudança da linguagem de programação). Uma vez que a velocidade se torna “conhecida”, a equipe geralmente não precisa mais medí-la.

Como esse tipo de métrica surge em diferentes contextos e problemas, podemos pensar em diversos outros exemplos. Supondo que a equipe está tentando melhorar nas práticas de teste, pode utilizar a cobertura de código como métrica de acompanhamento. Se querem melhorar a integração contínua, podem medir o tempo entre commits, ou o número de linhas alteradas em cada commit. E por aí vai…

Propaganda Descarada

Aproveitando o assunto (que oportuno!), vou fazer uma propaganda descarada da defesa da minha dissertação de mestrado, na próxima sexta-feira. As informações para quem estiver interessado em assitir são:

Título: “Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software”

Orientador: Alfredo Goldman

Local: Instituto de Matemática e Estatística (IME/USP)

Sala: 256 Bloco A

Data: 29 de Junho de 2007

Horário: 9:30hs

No último dia da conferência, um tutorial pela manhã e um workshop de tarde. Alguns dos temas do dia foram: barreiras invisíveis, teoria das restrições e área de trabalho informativa.

How to Overcome Invisible Barriers – Christoph Steindl e Christian Federspiel

Esse tutorial da parte da manhã foi o mais fraquinho dos que participei. Apesar disso, pude aproveitar algumas das idéias apresentadas e acho que elas podem trazer valor na hora de discutir um problema invisível. Como o Tom de Marco disse: “Não importa qual o problema, é sempre um problema com pessoas”. Algumas das ferramentas apresentadas e exercitadas ao longo da sessão foram:

• 5 Por Quês?: Essa é uma excelente ferramenta que a Toyota usa quando precisa encontrar a verdadeira causa de um problema. Corrigir sintomas não curam a causa, então ao perguntar o “Por Quê?” do “Por Quê?”, você quase sempre chega na raíz. Essa ferramenta eu já conhecia e posso dizer que ajuda muito.
• Diagrama de Resolução de Conflitos (Conflict Resolution Diagram ou CRD): Uma forma de estruturar um conflito de idéias entre membros da equipe e explorar as suposições que estão por trás daquilo. Apesar de não ter gostado muito da forma como o modelo te obriga a preencher alguns poucos quadradinhos, tirei duas idéias boas do exercício: ele te força a pensar no objetivo em comum por trás das suposições dos pontos de vista opostos e ele te força a usar palavras extremas e exageradas ao defender as diferentes suposições. Com isso, você acaba chegando em frases do tipo: “Tecnologias tradicionais NUNCA são arriscadas”, “A ÚNICA forma de motivar os desenvolvedores é utilizando tecnologias de ponta” ou “As novas tecnologias são SEMPRE o MAIOR risco”.
• Mapa de Objetivos Intermediários (Intermediate Objective Map ou IO-Map): Uma árvore para estruturar os fatores críticos de sucesso e as condições necessárias para atingir um objetivo (raíz da árvore). Acredito que é fácil utilizar essa ferramenta do jeito errado (quebrando o objetivo em diversos fatores de sucesso e sub-otimizar as partes ao invés do todo), no entanto tirei uma lição do exercício prático: mesmo não sendo muito eficaz, ela te força a pensar sobre o objetivo e a expressar essas idéias, levando a um maior entendimento a respeito do objetivo (ou mesmo encontrando um objetivo melhor).

Além dessas ferramentas, o palestrante comentou rapidamente sobre outras (nem vale a pena citar, pois achei muito complicado e estranho) e sobre a Teoria das Restrições, que é uma boa forma de tratar um problema sistêmico (ao invés de otimizar partes, você precisa focar na sua maior restrição). Eu já conhecia um pouco sobre a Teoria das Restrições e acho que ela é muito alinhada com os valores Lean.

Reface Your Team Space – Patrick Kua

Um workshop excelente do Patrick Kua, da Thoughtworks de Londres. Em uma atividade interativa e criativa, discutimos em equipes diversas formas de exibir informações no espaço de trabalho. Como podem ver pelas fotos, passamos boa parte do tempo rabiscando e discutindo várias formas de tornar o progresso visível e ajudar a equipe a entender o andamento do projeto (tanto da iteração atual quanto do projeto como um todo).

Na segunda parte do workshop, sentamos em uma espécie de “mesa-redonda” (sem a mesa no meio) e discutimos diversas práticas e ferramentas que utilizamos em projetos passados. Levantando idéias que deram certo e outras que não deram certo, aprendi bastante com a experiência das outras pessoas. Algumas das coisas que compartilhei que as pessoas gostaram:

• Retrospectivas fora do ambiente de trabalho: quando a retrospectiva é feita no mesmo (ou próximo do) ambiente de trabalho, eles tendem a se concentrar menos, pois estão no seu habitat natural. Ao invés de rearranjar ou refatorar o ambiente para diversos propósitos, as vezes é melhor trocar de ambiente. Essa técnica funcionou muito bem para mim.
• Humorômetro: já utilizei essa técnica em diversos projetos e todo mundo parece gostar e adotar. A idéia é japonesa, e se chama Niko-niko calendar. Cada membro da equipe tem uma linha num calendário e, ao final do dia, cola um adesivo colorido ou desenha um smiley que representa seu humor naquele dia. Esse indicador geralmente não serve para a comunicação com gerentes ou pessoas externas (Não é para virar algo do tipo: “Em média, o Fulano é mais triste que o Siclano”), mas sim como um fator de motivação dentro da equipe. As pessoas tendem a soltar a criatividade e eu diria que 99% dos projetos que começaram a usar decidiram continuar com essa prática.
• Combinados ao invés de regras: essa foi uma idéia que o Cícero, da Paggo, compartilhou com a gente na última palestra no IME. Ao invés de definir regras para a equipe, ele define “combinados” pois é algo que as pessoas concordam em seguir e soa menos como uma imposição. E outra coisa: quando você combina alguma coisa, sua responsabilidade em cumprir o combinado é muito maior do que quando quebra uma regra alheia.

E agumas coisas legais que aproveitei e vou testar:

• Mantra do dia: a equipe tem uma pilha de “mantras” e a cada dia, na reunião em pé, uma é escolhida e compartilhada na área de trabalho.
• Diferentes materiais: estou trazendo comigo post-its em forma de setinhas que são muito legais. Além disso, conheci uma folha de papel com estática (não sei o nome certo) que gruda na parede e serve como quadro branco improvisado. Infelizmente não sei se vou conseguir achar um desses no Brasil. Outra idéia boa de material é usar uma espécie de cera (ou massinha) para grudar os cartões na parede.
• Sinais sonoros: quando o build quebra, ao invés de mandar e-mail (que na minha experiência não é uma boa mídia, pois as pessoas ignoram depois de um tempo) ou usar uma lava-lamp (que é legal, mas hardware X10 no Brasil é muito caro), usar algum sinal sonoro para avisar que tem algo errado. Pensei na trilha do plantão da globo, pois essa é uma música que sempre me assustou e me fez prestar atenção. :-)
• Tokens: além do token da reunião em pé e da integração, que já utilizei em algumas ocasiões, conheci outros tipos de tokens: um peixe, para quando alguém começa a desviar do assunto você arremessar e “pescá-lo” de volta; um timer de tomate (aqueles de cozinheiro), para usar como estimativa e para servir como cronômetro e focar o trabalho durante um certo período de tempo (olha que divertido: “Essa história eu estimo em 4 tomates”).
• Sino da História: um sino que é tocado sempre que um par termina uma história. Numa equipe grande isso pode ser uma boa forma de mostrar que as coisas estão andando.
• Nariz de Palhaço: esse pode ser um pouco ofensivo, mas se o seu build estiver quebrando frequentemente, considere premiar alguém com um desses. :-)

Na discussão, surgiram assuntos relacionados ao espaço físico da equipe. Uma idéia interessante foi a existência de um espaço coletivo, onde a equipe pareia, e um espaço privatido onde cada um pode fazer coisas pessoais e falar no celular. O Kent Beck descreve um ambiente assim no segundo livro de XP. Outra idéia foi utilizar as janelas para colar post-its ou cartões. Eu já testei e é uma boa forma de ganhar espaço quando o número de quadro brancos é restrito. Só não deixe os post-its colados por muito tempo (mais que 10 minutos) pois eles tendem a cair. A gravidade atrapalha. :-)

Por fim, uma pequena discussão sobre a eficácia das informações visuais espalhadas pela área de trabalho: se alguém não está mais olhando alguma coisa (ou atualizando), se você tem muitas coisas espalhadas ou muitas informações, geralmente é um bom sinal para refatorar seu espaço de trabalho. As reuniões de retrospectivas são um bom momento para discutir coisas desse tipo e descobrir o que está sendo realmente útil e o que é apenas “barulho visual”.

Conclusões e Próximos Passos

Essa conferência foi muito proveitosa. Pelo fato de ser bem menor que a Agile (esse ano foram aproximadamente 200 participantes), tive a oportunidade de ficar muito mais perto de pessoas importantes como Kent Beck, Joshua Kerievsky, Mary e Tom Poppendieck, dentre outros. Além disso, conheci muitas pessoas da comunidade XP na Europa e tive a chance de compartilhar experiências e aprender bastante. Esse tipo de evento é sempre empolgante e estimulante, pois saímos com diversas idéias novas. Espero poder compartilhar algumas dessas idéias com a comunidade ágil do Brasil e volto no final de semana com vontade de fazer um monte de coisas novas por aí. Me aguardem… :-)