Danilo Sato

Fui convidado pelo Eduardo Fiorezi para a gravação do décimo episódio do seu podcast: Tudo que quero saber. O bate papo foi muito legal e contou com a participação do Marcos Tapajós da Improve It. O assunto foi “Disciplina em XP” e o áudio já está disponível em MP3.




Alguns dos assuntos tratados foram:

• Disciplina em XP e Métodos Ágeis em geral
• Resistência a práticas de XP
• Liderança e o papel do coach
• Abordagens para adoção de XP (artigo do Kent Beck)
• Sustentabilidade de mudanças
• Dojo e formas de aprendizado (Shu-Ha-Ri)
• Importância das retrospectivas (artigo do Alex)

Programadores não treinam. Essa é uma triste constatação para a grande maioria dos programadores. Apesar de não ser verdade para todos os casos, aprendi com o Scott Adams que é importante começar com uma boa frase de impacto. Agora que tenho a sua atenção, posso falar da minha tentativa de mudar essa realidade: O Dojo@SP.

O que é o Dojo?

O Dojo é um espaço onde programadores se reúnem para treinar e aprender. As reuniões são periódicas e centradas num desafio de programação. Apesar do desafio, o objetivo não é terminar o problema. A idéia é aprender com as experiências vivenciadas pelo grupo. O ambiente é inclusivo, seguro e convidativo.

Eu vejo vários princípios de XP na forma como o Dojo funciona: passos de bebê, humanidade, falha, redundância, qualidade, melhoria, dentre outros.

As reuniões geralmente são conduzidas em dois formatos: no formato Kata alguém resolve o desafio em casa e apresenta na reunião “ao vivo”, começando do zero e seguindo TDD. No formato Randori o problema é resolvido “ao vivo” pelos participantes, usando TDD e Programação Pareada em turnos. A cada turno, o piloto volta para a platéia, o co-piloto passa a pilotar e um novo co-piloto é convidado da platéia.

Um pouco de história

A idéia do Kata como exercí­cio de treinamento foi proposta originalmente por Dave Thomas numa série de posts do seu blog. No final de 2003, Laurent Bossavit levou a analogia um passo adiante e propôs a criação de um espaço de treinamento em grupo um Dojo. A partir daí­, juntamente com Emannuel Gaillot, eles fundaram o Dojo de Paris, que está em funcionamento desde 2003. Outros gostaram da idéia e começaram movimentos semelhantes em outras partes do mundo.

Depois de conhecer o Emannuel e a Emily no XP 2007, me motivei para começar um Dojo por aqui. Com o apoio deles e do wiki internacional, criado justamente para esse propósito, reuni alguns colegas e começamos a nos reunir no mês de Julho de 2007. Desde entnao estamos nos reunindo toda quarta-feira no Instituto de Matemática e Estatí­stica da USP.

No Brasil, o Ivan Sanchez foi o primeiro a trazer essa idéia, fundando o DojoFloripa. Nossa iniciativa é a segunda do Brasil e esperamos que a participação do público paulista cresca no futuro e que outros Dojos comecem a aparecer em outras localidades do país.

Update: Esqueci de mencionar o Dojo de Recife que começou suas atividades no mesmo mês que a gente.

Como posso participar?

Se você está em São Paulo, junte-se a nós! Leia um pouco mais sobre nossas experiências no wiki e entre no nosso grupo de discussão. Não é necessário ter profundos conhecimentos de Python, Ruby ou TDD. Caso não esteja seguro para programar “ao vivo”, participe como ouvinte para sentir o clima. Espero vocês lá!

Boa programação!

Estou há tempos devendo um post sobre o artigo do Ivar Jacobson (um dos inventores do RUP e pai da UML) e seus colegas, primeiramente publicado numa série de artigos da Dr. Dobb's e depois num paper no JOLT. No geral eu concordo com o seu ponto de vista, mas antes de ouvirem (lerem?) o que tenho a dizer, sugiro fortemente ler o artigo original. Pronto? Agora podem continuar a ler meus comentários…

Terminologia

Antes de falar sobre o artigo, queria esclarecer algumas coisas sobre o termo “processo”. Essa palavra geralmente vem carregada de uma série de significados que podem não ser os mesmos de pessoa para pessoa. Se você ler o Manifesto Ágil, verá que “Indivíduos e interações são mais importantes que processos e ferramentas”. Que tipo de processo o Manifesto se refere? Aquele mega-processo formalizado que todos precisam seguir ou, como diz o Tim Lister, processo é tudo aquilo que você faz no dia-a-dia, quando ninguém está olhando (ou avaliando) ou mesmo quando está sobre pressão? Recentemente, a Mary me fez repensar sobre o assunto e ela sugere a palavra “sistema” ao invés de “processo”. Como não é a primeira vez que ela me faz repensar algumas coisas, prestei atenção e concordo com a sua colocação, afinal de contas, independentemente de seguirmos algo padronizado ou não, todos acabamos fazemos alguma coisa no nosso dia-a-dia (alguns podem chamar isso de processo ou não). O “processo” do ponto de vista Lean e o “processo” na definição do Tim Lister não são o mesmo “processo” que o Ivar Jacobson está criticando. Daqui pra frente, quando eu falar em “processo”, estou me referindo ao mesmo processo do Ivar Jacobson.

O inventor do RUP está dizendo que o RUP não funciona?

Não sou o único que acredita que (e conhece) muitas empresas que implantaram o RUP de forma errada. Gostei do exemplo do Vinicius, comparando o RUP com um grande supermercado de processos, onde você faz suas compras (agora, com o OpenUP você pode fazer compras de graça) e coloca no carrinho as coisas que acha mais convenientes. Isso gerou uma série de malefícios na indústria, que vou tentar citar abaixo (alguns não são culpa direta do RUP e, pelo que vi, o OpenUP parece estar bem mais ágil):

• Processo pesado demais: “Não sei se preciso disso, mas na dúvida é melhor não ficar sem” (quando se trata de comida, minha mãe sempre disse que é melhor sobrar do que faltar) :-)
• Disfarce para Cascata: Incepção = Levantamento de Requisitos, Elaboração = Análise, Construção = Implementação/Testes e Transição = Implantação. Cabe aqui dizer que já ouvi gente reclamando que o RUP não lida com a fase de manutenção (que seria a próxima fase do Cascata que não aparece nos quadradinhos). Minha resposta para essa pergunta vale outro post, mas precisamos parar de pensar que desenvolver e dar manutenção são coisas totalmente diferentes. O software deve estar em constante manutenção.
• Processo pelo processo: “Que bom! Já tenho templates de documentos prontos para tudo! É só alocar alguém para prenchê-los”. Pior, eu já vi gente fazendo “RUP” escrevendo toda essa documentação DEPOIS só para seguir o processo. Alguém escreve Use Case depois que já tem algo implementado?!?!
• Decomposição em especialidades: “Sou apenas arquiteto, não escrevo código” ou “Esse documento é responsabilidade do arquiteto! Não ouse duvidar da sua validade, mero desenvolvedor”
• Gerenciamento voltado para alocação de papéis e tarefas: “Essas baleias fazem sentido. Não preciso de desenvolvedores no começo e o arquiteto vai estar livre para outro projeto na terça-feira da segunda semana do mês que vem…”
• Modelagem voltada para documentação: “Preciso gerar esses Use Cases. Preciso gerar os diagramas de classe. Preciso gerar os diagramas de seqûências, …”

Resumindo, concordo com o inventor do RUP que esse tipo de processo precisa acabar e que as pessoas não lêem os livros antes de aplicar os conceitos.

Meu processo é diferente do seu

Como é muito bem colocado no artigo, existem semelhanças entre os diversos processos. Mas o importante é que o processo seja “adaptativo, extensível e capaz de absorver boas idéias” (destaque meu). Ao estudar Lean, você verá que o processo existe apenas para ser desafiado. As pessoas devem ter o poder de mudá-lo sempre que encontrarem desperdícios ou pontos de melhoria. Se você estava atrás de um processo que resolveria todos os seus problemas, O processo que seria padrão da empresa, sinto informar que ele não existe (e não sou nem eu que estou dizendo, o Fred Brooks já disse isso há bastante tempo). Definir um comitê para definição DO processo é, no mínimo, um desrespeito ao intelecto das pessoas que irão seguí-lo. Como um grupo de pessoas que não está trabalhando (e usando o processo), pode definir o melhor jeito que algo deve ser feito?

Além disso, os Métodos Ágeis já sabiam dessas coisas há um certo tempo. Crystal coloca a reflexão como uma das bases da metodologia e, mais pra frente, as reuniões de Retrospectiva foram incorporadas em outros processos como Scrum e XP. Hoje em dia, utilizo retrospectivas em vários contextos! É uma ótima forma de aprender com nossos acertos e erros e de melhorar para o futuro.

Concordo com todas as críticas aos processos colocadas por Ivar Jacobson: que têm diversos pontos em comum, que nunca serão totalmente completos em todos os aspectos, que nunca serão adotados de forma completa ou by-the-book, que não transmitem o conhecimento de forma eficiente e que podem ser estúpidos em alguns casos.

Usem práticas!

A solução do Jacobson é não focar mais em processos completos e pesados, mas sim em catalogar uma coleção de práticas. Cada prática deve ser isolada e atacar um aspecto específico do desenvolvimento. Dessa forma, cada “metodologista” (como ele diz) pode montar (e mudar) o seu processo conforme suas necessidades. O que eu achei legal na definição dele é que cada prática deve se “auto-verificar”. Em outras palavras, ela deve estabelecer um objetivo claro e uma forma de avaliar se esse objetivo foi atingido. As métricas de acompanhamento podem ajudar bastante aqui.

Apenas práticas resolvem?

Apesar de eu concordar com a mudança de foco (processos para práticas), ainda acredito que só as práticas em si não são tudo. Em XP, as 12 práticas originais dobraram (13 práticas primárias + 11 práticas corolárias). E isso foi feito com base nos valores e princípios da metodologia. XP se baseia nos valores da comunicação, feedback, simplicidade, coragem e respeito. São a forma como avaliamos uma determinada situação (seja desenvolvendo software ou arrumando a casa). Valores são amplos, enquanto práticas são específicas. Não consigo convencer minha empregada a usar TDD ou Programação Pareada para limpar meu quarto, mas posso conversar de forma respeitosa e mostrar que não faz sentido guardar um pé do tênis junto com um pé do sapato. Você pode chamar isso da prática do Calçado Pareado se quiser :-)

Na segunda edição do livro de XP, Kent Beck define melhor ainda os princípios da metodologia, que ajudam a traduzir os valores (amplos) em práticas (específicas). Acredito que para adaptar um processo de forma consciente e eficiente, não basta olhar apenas para um repositório de práticas e sair escolhendo. Precisamos dessas ferramentas mentais para auxiliar a adaptação para nossa situação. No livro Lean Software Development, por exemplo, a Mary e o Tom se focam quase exclusivamente nos princípios. A GM e A Ford tentaram copiar as práticas da Toyota e não conseguiram atingir os mesmos resultados.

Eliminamos os processos. E as ferramentas?

Minha última crítica ao artigo do Jacobson é que ele dá todos os argumentos contra os processos e, no final, mostra uma nova ferramenta, o EssWork, para gerenciar o repositório das práticas (e seus cartões), para organizar a forma de trabalho da equipe (seu processo) e para integrá-lo com as ferramentas de desenvolvimento da equipe. Não que eu seja totalmente contra o uso de ferramentas, mas assinei o manifesto e prefiro valorizar indivíduos e interações. Até chegar nessa parte eu estava gostando da idéia dele de utilizar cartões para representar as práticas e para montar o processo da equipe. Digamos que me decepcionei um pouco no final, mas nada que invalidasse o resto das coisas que havia gostado.

Acredito que ouvir uma opinião dessas de um cara tão respeitado pelos mais “tradicionalistas” é muito encorajador para nós. Segundo ele mesmo coloca, estamos numa fase de transição para uma nova era da engenharia de software e acredito que os Métodos Ágeis servirão como uma excelente base para mudarmos o cenário da nossa indústria.

Como falei anteriormente, defendi minha dissertação de mestrado há pouco mais de 1 mês atrás. No entanto, como também alertei, eu geralmente me atraso com algumas coisas importantes, como revisar o texto e (o mais chato) montar o índice remissivo. Enfim, chega de desculpas! Algumas pessoas entraram em contato comigo interessadas em ler o meu texto, então resolvi disponibilizá-lo no site da AgilCoop. O título: “Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software”.




De maneira geral fiquei muito satisfeito com o trabalho e, principalmente, com o conhecimento que adquiri/refinei ao longo dos últimos 3 anos e meio. Muito do meu conhecimento em Métodos Ágeis veio a partir da leitura de diversos artigos, teses e livros (blogs, podcasts e vídeocasts também). Mas o que realmente valeu a pena foi a vivência prática: tanto participando e sendo monitor da disciplina de Laboratório de XP no IME, quanto trabalhando em projetos do “mundo real”, quanto ministrando palestras e cursos, quanto escrevendo artigos ou prestando consultorias.




Quem estiver interessado em ler minha dissertação e discutir algumas das idéias, é só entrar em contato comigo. Pode deixar um comentário aqui, me mandar um e-mail pessoal ou até discutir nas listas de discussão que participo, como a XP@Rio, agile-brasil, scrum-masters-brasil ou outras.




Ufa… que alívio :-)

Esse post de propaganda vai ser curto. Tenho duas novidades para compartilhar com vocês.

Treinamento de TDD na PyCon Brasil

Eu e o RBP vamos ministrar um treinamento de TDD na Pycon Brasil 3, em Joinville, SC. O treinamento será no dia 31 de Agosto (última sexta-feira do mês) das 9:00hs ao 12:30hs. Maiores informações podem ser obtidas no site do evento. Espero encontrá-los na conferência!

AgilVídeo

A AgilCoop está lançando uma nova série de vídeos das nossas palestras e treinamentos: o AgilVídeo. Já temos 7 episódios publicados de alguns de nossos cursos de verão do começo do ano. Mais vídeos estão em edição (valeu, Julian!) e devem aparecer por lá em breve! Por isso, assinem nosso novo RSS para acompanhar as novidades. Além disso, quem ainda não conhece pode ouvir também nossa série de podcasts: o AgilCast. Novos episódios também devem sair em breve. Aguardem!

Geralmente eu gosto de compartilhar notícias interessantes no meu “Shared Feeds” do Google Reader, mas essa eu acho que vale um post especial: o pessoal da Version One, do Google e da InfoQ estão apoiando um concurso de comerciais ágeis, que serão apresentados na Agile 2007 (esse ano, infelizmente, eu não vou)! Vale a pena conferir! Separei alguns dos meus favoritos:

Musical da ThoughtWorks UK:

Drama da ThoughtWorks UK:

Estilo “Mac vs. PC”, da OutSystems:

Como organizar melhor o seu tempo? Sabem aquela história do “Façam o que eu digo e não o que eu faço”? Então, as idéias desse post não estão amadurecidas por completo, mas qual a graça de ter um blog se você não pode divagar? O aviso já está dado, prossigam por sua conta e risco. :-)

A Teoria

A teoria é simples e a Mary já escreveu sobre o assunto: quando você tem várias tarefas para fazer, se fizer um pouco de cada, vai demorar mais para terminar tudo. Isso parece ir contra o senso comum, mas como o Phillip Calçado falou sábado passado: “O senso comum geralmente está errado”.

A figura mostra bem o que eu quero dizer: Se você tem 3 tarefas e quebrá-las em pedacinhos menores, ao trabalhar um pouco em cada pedaço, você perde um tempo com troca de contexto. No fim da primeira semana, você poderia ter terminado a “Tarefa 1″ por completo, mas acaba ficando sem nada terminado. Ponto. Simples. Só isso. Não faz sentido?

A Realidade

Acontece que no mundo real eu tenho fama de ser multi-processado. Comentários que costumo ouvir:

• “Como você consegue fazer tanta coisa ao mesmo tempo?”
• “Seu dia dura quanto tempo?”
• “Você dorme?”

Apesar de não concordar muito com essas coisas, acabo realmente fazendo muita coisa ao mesmo tempo. E mudar esse comportamento não é nada fácil. Acontece que eu conheço muita gente boa que também se comporta desse jeito. Chegamos em um paradoxo: a teoria diz que fazer muita coisa ao mesmo tempo é ruim, mas a prática me mostra pessoas boas fazendo muita coisa ao mesmo tempo. Tudo bem que meu paradoxo está um pouco furado, afinal “pessoas boas fazem muita coisa ao mesmo tempo” não implica “fazer muita coisa ao mesmo tempo é bom”. De qualquer jeito, tenho a impressão que existe alguma relação. O que vocês acham?

Explicando a Realidade

Dia desses me deparei com uma explicação que caiu como uma luva para minha situação: Procastinação Estruturada. Quem escreveu foi um professor de filosofia de Stanford, então não deve ser uma total baboseira. Ele fala que sofre de um mal parecido com o meu e aparentemente gosta de enrolar para fazer seus deveres.

All procrastinators put off things they have to do. Structured procrastination is the art of making this bad trait work for you. The key idea is that procrastinating does not mean doing absolutely nothing. Procrastinators seldom do absolutely nothing; they do marginally useful things . Why does the procrastinator do these things? Because they are a way of not doing something more important. If all the procrastinator had left to do was to sharpen some pencils, no force on earth could get him do it. However, the procrastinator can be motivated to do difficult, timely and important tasks, as long as these tasks are a way of not doing something more important.

Enrolar não significa “não fazer nada”. Se você tiver uma tarefa REALMENTE importante (pelo menos aparantemente), você poderá fazer muita coisa enquanto não a faz. Legal, não? Mais ou menos. Você pode pensar: mas então a tarefa do topo da lista nunca vai ser realizada. É aí que está o segredo. Você precisa escolher muito bem o que colocar no topo da lista.

The ideal sorts of things have two characteristics. First, they seem to have clear deadlines (but really don't). Second, they seem awfully important (but really aren't). Luckily, life abounds with such tasks.

No meu caso, uma dessas tarefas até a semana passada era “terminar o mestrado”. Na minha qualificação, em dezembro do ano passado, planejei que o texto final estaria pronto em fevereiro, para defender em março. Terminei semana passada, quase 3 meses atrasado. Atrasado? Acho que não. Durante esse tempo, fiz muitas coisas interessantes: publiquei 3 artigos, viajei para a Itália, Porto Alegre e Porto de Galinhas, ajudei a organizar o curso Verão Ágil na USP, trabalhei como coach no Ikwa. Isso sem contar tarefas-extra como tocar num show de última hora, por exemplo.

Refinando a Teoria

Apresentei essa teoria para vários amigos e tive várias discussões interessantes sobre o assunto. Uma coisa legal que conversei ontem com o Julian foi sobre a natureza das diversas tarefas. Nem sempre eu tenho uma única tarefa super-importante que me motiva a fazer as outras. Às vezes são VÁRIAS tarefas pendentes que fazem esse papel. No meu caso, algumas dessas tarefas estão em post-its no Dashboard, outras em e-mails no Inbox do GMail, outras num mini-wiki que uso para me organizar (ou tento usar) e outras estão na minha cabeça. Concordo que isso não é nada consistente e não recomendo que façam da mesma forma. No entanto, todas as tentativas de tentar unificar a lista foram em vão e acabei usando um pouco de cada idéia.

Como expliquei anteriormente, o resultado é que acabo enrolando um pouco de cada tarefa. E aí entra outra característica da minha personalidade: memória de curto prazo. Eu tenho facilidade para manter coisas no meu “cache primário” de memória. As tarefas de hoje, de amanhã e da próxima semana estão sempre frescas na minha cabeça. Meu dia-a-dia é adaptativo e esse “cache” ajuda a me organizar. As tarefas pendentes acabam ocupando espaço de memória no meu cérebro e isso me incomoda. Todas as que eu começo e não termino me atrapalham, então acabo tendo que terminá-las para conseguir “liberar espaço”.

Outra característica interessante que discutimos hoje: geralmente algumas dessas tarefas do topo, teoricamente importantes e inadiáveis, são aquelas que eu não quero fazer de qualquer jeito; que eu me preocupo com a qualidade do resultado e que imagino precisar de mais tempo alocado para fazê-la bem feito.

“Concluindo…”

Conforme puderam perceber, a forma como me organizo é caótica, inconsistente e questionável. Alguns dos fatores que influenciam meu dia-a-dia são: procrastinação, memória de curto prazo, incômodo com tarefas não-terminadas, malabarismo com as tarefas importantes e preocupação com a qualidade.

Ainda estou aprendendo e refletindo para descobrir se posso colocar mais ingredientes nessa mistura. Nada melhor que algumas perguntas para terminar um post não-conclusivo: E vocês, como organizam seu tempo pessoal? Como lidam com o problema de multi-tasking? Vocês se identificam com algo do que falei aqui?

Hoje tive a honra de ser entrevistado pelo Vinicius Teles e inaugurar a nova Série Experiências Ágeis no podcast da Improve It. Ele foi extremamente ágil e conseguiu terminar de editar e publicar o podcast no mesmo dia. Além dos assuntos mencionados no blog da Improve It, conversamos sobre Programação Pareada Promíscua, técnicas para criar e validar interfaces gráficas, AgilCoop e Métodos Ágeis no Brasil em geral. Aproveitem!




MP3 do Improvecast 7

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… :-)