Danilo Sato

Inspired by a post on the Lean Blog, Pat reminds us that you can’t measure everything effectively. Having written my Master’s thesis on metrics for Agile projects, I’ve learned and read about this in a lot of different places. One approach that is very known to Empirical Software Engineering researchers is the Goal-Question-Metric approach, first published by Vitor Basili et al. in the 90’s.

The GQM model suggests a hierarchical view of three levels to define which metrics to use:

• Conecptual level (goal): the motivation for measurement. Measuring things without a purpose and a thorough understanding of the problem will lead to meaningless metrics. This level imposes the hardest questions: what’s the purpose? what’s the object of measurement (your product, process, people)? what’s the motivation? who is interested in this goal? what are the quality attributes?
• Operational level (question): at this level, a set of questions are defined to try and correlate the object to the quality attributes we are interested in. These questions should help in understanding and assessing the current situation, but also in identifying ways to determine whether the goal is achieved.
• Quantitative level (metric): only then a set of metrics is associated to the questions, to try and find a quantitative way to measure and answer it. These can be objective (like code coverage), or subjetive (individual’s ranking of current code quality). Finding these metrics is not easy either.

It’s easy to try to cut corners and get into the things that are easy to measure first, specially when you can collect lots of quantitative data to work with these days. However, if you you don’t stop to think about the goals and motivations for measurement, it’s easy to forget the systemic complexity that surrounds us and look only for the easy-to-track numbers.

Lean management and problem solving is known for taking a very thorough and detailed approach in the understanding phase. To many people this is a paradigm-shift approach to management. Don’t let the numbers fool you, use them to your advantage.

Continuing with the series, this time I want to highlight a very dangerous anti-pattern: using velocity as a performance metric. Before getting into the examples of how it applies to velocity, I want to first explain my view on metrics. I am in favour of metrics and coming up with interesting ways of displaying data (information visualization is a very interesting topic). However, the problem lies in the way that these metrics are used. There are two main types of metrics that I like to categorise as:

• Diagnostics Metrics: these are informative measurements that the team uses to evaluate and improve it’s own process. The purpose of collecting them is to gain insight into where to improve, and to track whether the proposed improvements are taking effect. They are not associated to a particular individual or to how much value is being produced. They’re merely informative and should have a relatively short life-cycle. As soon as the process improves, another bottleneck will be identified and the team will propose new metrics to measure and improve that area.
• Performance Metrics: these are measurements of how much value your process is delivering. These are the ones you should use to track your organisation’s performance, but they should be chosen very carefully. A good approach is to “measure up”. Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed. There should also be just a few of these metrics. An example of one such metric would be a Net Promoter Score (that measures how much your custumer is willing to recommend you to a friend) or some financial metric like Net Present Value (read Software By Numbers if this interests you). As you can see, these are very much outside of a team’s control and to be able to score high on them, they should try and do a good job (instead of gaming the numbers).

Going back to velocity, a very common mistake is to use it as a performance metric instead of diagnostics. Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game (as mentioned in my previous posts). When approached as a performance metric, it’s common to see things like:

• Comparing velocity between teams: “Why is Team A slower than Team B?” Maybe because they estimate in different scales? Maybe their iteration length is different? Maybe the team composition is different? So many factors can influence velocity that it’s only useful to compare it within the same team, and even then just to identify trends. The absolute value doesn’t mean much.
• Measuring individual velocity: as highlighted by Pat, this is a VERY DANGEROUS use of velocity, and it can actually harm your process and discourage collaboration.
• A push to always increase velocity: it’s common to have a lower velocity in the beginning of a project, and that it tends to increase after a number of iterations. Inspite of that, I’ve seen teams pushing themselves to improve it when they reach a natural limit (Who doesn’t want to go faster, right?). Velocity measures the capability of your team to deliver and, as such, tends to stabilise itself (if you have a stable process and the number is not being gamed). A Control Chart could help you visualise that. As noted by Deming, in a stable process, the way to improve is to change the process.

It’s important to remember that velocity is a by-product of your current reality (your team, your processes, your tools). You can only improve your process once it’s stable and you know it’s current capacity. Velocity is just a health-check number that will tell your team’s capability. It will not tell you about how much value is being delivered or how fast you’re going. You can deliver a lot of points and make trade-offs on quality which, no matter how you measure it, will impact your ability to go fast in the long run. As uncle Bob says:

“The way to go fast, is to go well”

So let’s stop using velocity to measure performance and look at it as a diagnostic metric to improve our software delivery process.

In this session, Joshua Kerievsky (the founder of Industrial Logic and author of “Refactoring to Patterns”) shared his experiences about stepping away from using estimations and moving into what he called ‘Micro-releases’. What got me interested is that, although he claimed not to be following the recent kanban/iteration-less techniques, he arrived in something relatively similar through his own experiences.

He started talking about the usual confusion of using different units to estimate stories (using points and people converting it into time-units when estimating, using ideal hours and people interpreting it as real hours, and so on). This confusion is also reflected in the way people interpret the team’s velocity. Instead of using it as a measure of the team’s capacity, it’s easy to make it a performance measure. Improving velocity becomes a synonym to improving productivity, and we still don’t know how to measure productivity in software.

Another usual problem that he raised is “What to do with hang-over stories between iterations?”. Are they considered waste? Should they be counted in the team’s velocity? Why is it a hang-over? Is it because it’s close to be completed or is it actually much bigger than the team expected?

His proposed practice of ‘micro-releases’ is based on a high state of collaboration with the customer: there is a small, prioritized list of what should be done next and the team picks up a small and coherent set of stories and ‘guess’ the next micro-release date based on gut feel. He reports that slipping the end date of a micro-release is not such a big deal, because the next one is always close. In this model, the length of a micro-release varies, but usually between 1-6 days (with some outliers like 15, as I recall from his slides, but it’s not too different than that). Because of that, there’s not a stable measure of velocity and using it becomes useless. Feeding the input list with the next stories is done in a just-in-time fashion, and the value produced by the software is realized earlier, as soon as the micro-release is finished.

It’s important to note that he still values the heartbeat of iterations to gather feedback (like a customer showcase or a team’s retrospective). But he simply detaches the release life-cycle from the iterations. This opinion was reinforced by Ron Jeffries in the audience, when he said they were releasing to production twice per iteration in one of his projects. What an interesting point of view: we usually tend to see a ‘release’ as the result of a set of ‘iterations’, but he is reporting smaller ‘release’ cycles than ‘iterations’. Hmm…

But there are some important caveats that should be in place in order for these techniques to work:

• High collaboration with the customer
• Ability to break-down stories into small-but-still-valuable chunks: He reckons it’s very important to know how to break down requirements into “stories of the right size”. If they are too big, there’s no way for the team to guesstimate when they will be finished. He thinks this practice is one of the most important to any Agile project (using micro-releases or not).
• Easy to deploy: There’s no point in having a new release after 2 days if it takes 3 days to deploy it to production.
• Bargaining stories: Alongside breaking stories into small chunks, teaching the customer to bargain for features and avoid what he calls “Feature Fat” (building more that’s actually needed, or gold-plating requirements) is very important (again, this is something you can use regardless of the micro-releases approach).

Since the experiences started with Idustrial Logic’s internal product development, some people argued they are only capable of using that because they have enough experience with XP and Agile, but Joshua claimed he is introducing these ideas with success in their new client projects.

This seems like a common theme in the agile space lately, and you can follow up on the discussions on InfoQ, the XP mailing list, or here. :-)

I’ve found out recently that there’s an interesting timeless statement in the Agile Manifesto that we usually forget: “We are uncovering better ways of developing software…”. We should be open to alternatives and to discuss new ideas!

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

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

Muitas coisas aconteceram no último dia da main track: painel de discussão sobre certificações, artigos científicos, painel de discussão sobre “melhores práticas”, DSLs e keynote do Kent Beck. No terceiro dia de conferência diversos tópicos foram abordados e, daqui pra frente, participarei apenas de tutoriais e workshops, então espero que a densidade dos posts diminua :-)

Painel de Discussão sobre Certificação

 

Certificação no mundo ágil é um assunto que está na moda. A Agile Alliance anunciou recentemente sua posição sobre o assunto; Scott Ambler colocou sua opinião a favor num artigo da DDJ; além disso, muitos debates vêm acontecendo nas diversas listas de discussão, como scrumdevelopment@Yahoo, extremeprogramming@Yahoo e na nossa XP@Rio. A opinião dos participantes do painel estava dividida entre:

 

• Contra: Joshua Kerievsky e David Hussman
• A Favor: Jeff Patton e Boris Gloger
• Em cima do muro: Rachel Davis, representando a Agile Alliance

Uma das grandes discussões girou em torno do Certified Scrum Master. Joshua e David argumentaram que é um excelente treinamento (eu concordo), porém dá um título muito poderoso (para o observador desatento) para um curso de 2 dias sem uma prova no final. Em outras palavras, empresas procuram SCMs sem saber o que eles tiveram que fazer para se tornar um (está escrito na descrição do curso na Scrum Alliance). Do outro lado o Boris argumentou que, apesar de ser sim uma ferramenta de marketing (muito eficiente, por sinal), foi um programa que propiciou a criação de uma enorme comunidade interessada no Scrum e que, de uma forma ou de outra, contribuiu para o aumento na adoção dos Métodos Ágeis na indústria. Sobre esse tópico, estou um pouco mais pendente pro lado contra (apesar de ser um SCM) devido à fragilidade da nossa indústria. Infelizmente as empresas buscam profissionais certificados sem saber o que os torna certificados. Apesar disso, concordo com o argumento do Boris de que a formação de uma comunidade é importante. Acredito que uma estratégia de longo prazo para popularização dos Métodos Ágeis não deve ser tão ambiciosa a ponto de querer atingir quantidade e qualidade ao mesmo tempo. Olhando por esse lado, acredito que é mais fácil (e natural) conseguir a quantidade antes da qualidade. Por isso, acho que os treinamentos de SCM são importantes.

Dentre outras discussões sobre o tema, surgiu a idéia de ter uma “certificação” ágil mais parecida com o que fazemos na universidade: um curso muito mais longo, muito mais abrangente e que fornece uma base comum de conhecimento para que o aluno possa evoluir. Quando um aluno se forma na graduação, não espera-se que ele saia totalmente proficiente. Existe um consenso de que a experiência trará benefícios. Gostei dessa idéia de uma “faculdade ágil”. :-)

Outro ponto interessante da discussão foi a separação entre habilidade e certificação (ou treinamento). Ter uma certificação ou participar de um treinamento não é garantia de que o participante irá adquirir a habilidade necessária. Isso pareceu ser consenso. O único ponto do Joshua foi que ele prefere chamar isso de treinamento ao invés de certificação, pois é mais realista. Por outro lado, o Boris argumentou que qualquer programa de certificação gera um mercado mais atraente para empresas.

Outros assuntos interessantes foram abordados na discussão, mas esse espaço é muito curto (e minhas anotações muito sucintas) para expor de forma adequada. Acho que a discussão está boa e deve continuar…

Artigos Científicos

 

Após o debate, houve uma sessão de apresentação de artigos científicos, dentre eles o meu. Confesso que fiquei um pouco nervoso por ter que apresentar em inglês e um pouco mais nervoso quando vi o Kent Beck na platéia. Mas isso passou assim que comecei a falar (como costumava acontecer quando tinha que tocar piano na frente dos outros.. he he) e acho que correu tudo bem. Após a sessão fui conversar com o Kent Beck (sobre outro assunto) e ele me disse que gostou da minha apresentação, o que me deixou muito orgulhoso :-)

 

Dentre os outros papers apresentados, teve um que não gostei (nem o Boris.. he he) sobre um meta-modelo para modelar e medir a eficácia de processos ágeis. O exemplo usado foi o Scrum e me pareceu uma tentativa de fazer um framework-de-processos(RUP)-ágil-genérico, onde outras metodologias ágeis poderiam ser “instanciadas”. Enfim, não deu pra entender muito bem a motivação para usar aquilo (e eu também tenho um certo preconceito quando começam a falar de processos com caixinhas parecidas com UML, setinhas e coisas <<entre símbolos estranhos>>).

 

Por outro lado, os outros dois papers foram bem mais interessantes. O primeiro foi sobre o FitClipse, um plugin do Eclipse para execução e edição de testes de aceitação do FIT. Ele roda em cima do FitNesse e permite a distinção entre testes que falham por motivos aceitáveis (ainda não foram implementados) ou por motivos inaceitáveis (já foram verde e ficaram vermelho depois de um tempo), além de mostrar uns gráficos bonitinhos. O outro foi sobre o EzUnit, uma extensão do JUnit que permite a identificação mais precisa de qual pedaço de código pode ter causado uma falha. O framework permite a definição do(s) método testado(s) (Method Under Test ou MUT) com anotações (isso achei estranho) ou, para quem é preguiçoso como eu, escreve as anotações através de análise estática e dinâmica do código. Gostei da idéia, mas não tanto dessa parte das anotações/análise estática. Concordo com o comentário do Kent Beck no final de que a análise dinâmica, associada aos deltas das mudanças efetuadas mais recentemente, dão uma informação muito boa sobre onde uma possível falha pode estar localizada. Além disso, linguagens dinâmicas não permitem análise estática de qualquer forma. Acho/espero que no futuro vamos usar testes unitários como “compiladores” e ferramentas como essa podem facilitar a vida.

 

Painel de Discussão sobre “Melhores Práticas em Software”

 

Antes de mais nada, uma colocação da Mary: “Não existe uma MELHOR prática”. A partir do momento que consideramos algo como o melhor, deixamos de pensar em formas de melhorar, afinal de contas já temos O MELHOR. Muito bem colocado e os presentes no painel concordaram: Giancarlo Succi, Jutta Eckstein, Robert Beedle e Yael Dubinsky.

 

Os “painelistas” (como se escreve isso em português?) mostraram uma preocupação na definição e escolha de práticas muito técnicas. A agilidade propõe aspectos humanos que dificilmente são expressados em práticas específicas. Por outro lado, medir e avaliar a adoção de princípios e valores é complicado. Robert Beedle defendeu o ponto de que a prática mais importante é a colaboração. Ela inclui os valores humanos e dirige o resto do processo na direção certa. Segundo ele, sua primeira impressão sobre XP foi positiva pois servia como uma ferramenta cognitiva para compartilhamento de conhecimento que, mesmo sem saber explicar muito bem como, fazia com que as coisas certas acontecessem. Em outras palavras, se você seguisse as práticas (e suas sinergias e valores embutidos), você seria capaz de dirigir a produção do software certo, ao contrário da abordagem da engenharia de software tradicional que busca a forma certa de produzir software. Produzir certo vs. Produzir o software certo. Conceitos bem diferentes.

 

Por fim, houve uma discussão sobre como medir o sucesso nos projetos. O Giancarlo defendeu o ponto de que é preciso utilizar métricas e objetivos claros para avaliação do sucesso. Num debate sobre o valor de métricas quantitativas e qualitativas, Robert Beedle disse que para medir o lado humano dos Métodos Ágeis, métricas qualitativas são a única solução. Por outro lado, Giancarlo disse que é mais fácil entender dados quantitativos, apesar de serem facilmente manipuláveis ou mal-interpretados.

 

Birds of a Feather: Domain Specific Languages – Emily Bache

 

Apesar de não constar na programação oficial, a Emily havia mandado uma proposta de workshop que foi recusada e, mesmo assim, decidiu fazer uma sessão aberta para interessados em discutir DSLs. Eu achei muito louvável a atitude e, como não programaram nenhum Open Space na conferência desse ano, também demonstrou o poder da comunidade em adaptar o programa e compartilhar conhecimentos.

 

Nesse workshop, discutimos o conceito de uma DSL que, para minha surpresa, não era consenso. Eu ainda não tive muitas experiências utilizando uma DSL numa situação onde precisei de verdade, a não ser na definição de testes de aceitação. Porém, como disse para os participantes, já houve momentos na minha carreira (antes de saber o que era XP) onde consigo ver uma DSL ajudando a diminuir a distância entre especialistas e programadores. Após diversas discussões surgiram alguns aspectos do que seria uma DSL:

 

• Uma DSL deve maximizar a densidade semântica: em outras palavras, dependendo do público-alvo (os especialistas no domínio), usar muitos parênteses e símbolos de programação podem atrapalhar a legibilidade (particularmente em DSLs internas).
• Uma DSL deve ser executável: isso inclui a habilidade de edição e execução na frente do especialista do domínio, trazendo feedback imediato.
• Deve ser fácil e rápido alterar uma DSL: em outras palavras, o especialista de domínio deve ser praticamente capaz de escrever na DSL (ler é mais fácil que escrever).

Ainda no tópico da densidade semântica, houve uma pequena discussão sobre se uma DSL deve ou não ser obrigatoriamente legível para o cliente (ao invés do programador). Nesse caso, o rake não seria uma DSL.

Keynote de encerramento: Ease at Work – Kent Beck

 

Para não tornar um post longo ainda mais longo, não vou me estender muito sobre esse keynote. Kent Beck é O CARA. E dessa vez, ao invés de falar sobre aspectos técnicos, metodologias ou empresas, ele deu uma palestra quase como psicólogo (tudo bem que a esposa dele é psicóloga), para tentar fazer-nos refletir sobre nosso papel como programadores e como encaramos nosso trabalho. Em outras palavras, como fazer com que possamos nos sentir bem com nossas qualidades e defeitos?; como conviver e aceitar que não estaremos sempre no auge ou na lama?; como sair do trabalho com a consciência tranquila de que demos nosso melhor?; Como sustentar mudanças?; Como sermos mais responsáveis e transparentes no trabalho?

 

Como disse, espero que o post de amanhã seja mais resumido pois também cansa escrever esses relatos… brincadeira :-)

 

Boas novas! Meu artigo foi aceito e agora estou planejando minha viagem para Como na Itália para participar do XP 2007. Se você também está pensando em ir para a conferência, entre em contato ou deixe um comentário para combinarmos de nos encontrar por lá para dividirmos experiências e, quem sabe até, despesas de hotel. :-)

Conforme o Vinicius anunciou, esse ano promete para as conferências ágeis no mundo e, quem sabe, no Brasil também. As coisas estão esquentando por aqui ultimamente. Tivemos o nosso Curso de Verão da AgilCoop e já estamos planejando ministrá-lo novamente em horários melhores. Além disso, a Teamware está organizando novos cursos de Certified Scrum Master em São Paulo, Rio de Janeiro, Florianópolis, Brasília e Buenos Aires, e Certified Scrum Leader em São Paulo. A Heptagon está organizando um workshop sobre FDD. A ImproveIt está com um curso super interessante de Imersão Ágil.

Estamos semeando novos conceitos e paradigmas na indústria brasileira de software e tenho certeza que em breve teremos muitas empresas interessadas em adotar métodos ágeis. Não vamos deixar a bola cair!

Apesar das coisas parecerem paradas por aqui, estive bastante ocupado nos últimos meses. Nada melhor que aproveitar o pós-carnaval para voltar a escrever (um post curto) :-)

É claro que nada serve como desculpa para não escrever no blog, mas deixo aqui uma lista com algumas das coisas que me mantiveram ocupado desde o último post:

• Mestrado: O tema do meu mestrado é tracking de projetos ágeis (mais especificamente XP) e minha qualificação foi no dia 12 de Dezembro. O feedback recebido da banca de avaliação foi bastante positivo e enriquecedor. O texto da qualificação não está disponível pois está em fase de “refatoração+implementação” para a defesa, que deve ocorrer nos próximos meses.
• Artigos: Meu primeiro artigo científico foi aceito numa edição especial de uma das principais publicações da SBC, o Journal of Brazilian Computer Science. O artigo foi escrito em inglês, com o título “Experiences Tracking Agile Projects: an Empirical Study”. A versão impressa já deve sair em breve mas a versão online já está disponível aqui e no site da AgilCoop. Além disso, em Janeiro submeti outro artigo para a conferência XP 2007 que ainda não sei se vai ser aceito.
• Curso de Verão: A AgilCoop ministrou em Fevereiro dois cursos de uma semana (um teórico e outro prático) sobre Métodos Ágeis. Foi muito divertido preparar e apresentar esses cursos e o feedback que recebemos foi muito positivo. Devo falar um pouco mais sobre o curso em outro post, mas para quem estiver curioso, os slides estão disponíveis (com Copyleft) no site da AgilCoop.
• Coaching XP: Desde Dezembro, estou prestando consultoria em XP/Métodos Ágeis numa empresa start-up que tem potencial para ganhar o seu espaço na web brasileira: o Ikwa. A premissa básica do projeto é criar uma comunidade ao redor do tema “orientação profissional”, onde estudantes do ensino médio ao universitário possam explorar o seu futuro e traçar suas carreiras através de ferramentas que os auxiliam na busca pelo auto-conhecimento, desde a escolha do curso até a vida profissional. O trabalho está muito legal! Nós passamos por uma fase de entrevistas e testes para montar a equipe de desenvolvimento que acaba de ser completada. Devo falar mais sobre as experiências por lá em outros posts. Por enquanto os curiosos podem acessar o Ikwa Blog.

Por enquanto é só. Até breve! E, dessa vez, espero que seja breve mesmo :-)

Resumo do terceiro dia de conferência: uma sessão pela manhã, quatro na parte da tarde e eu descobri que estou ficando míope :-)

Storytelling with FIT – Steve Freeman e Mike Hill

Depois da sessão de ontem
com o Ward Cunningham sobre a importância dos testes para a evolução de um sistema, decidi assistir uma palestra
sobre o framework que ele inventou para testes de aceitação: FIT. O ponto principal
da palestra foi mostrar a importância dos testes de aceitação como meio de comunicar requisitos. Eu já ouvi muitas
conversas por aqui sobre a utilização da palavra “teste”, pois muitos podem achar que o único objetivo de um teste
é encontrar erros (e sabemos que, apesar de eficientes, testes não provam a ausência de bugs). Ao invés de “teste”,
os apresentadores tentaram usar o termo “documento”, pois os testes de aceitação no FIT são páginas HTML contendo
texto e tabelas com exemplos que especificam o comportamento esperado do sistema. O mais interessante é que o
documento é algo executável. Com isso você tem como especificar os critérios de aceitação de uma história antes de
ter a implementação pronta (a idéia de escrever testes antes do código aplicada num contexto mais amplo).
Ao implementar a funcionalidade esperada, você utiliza ferramentas como os testes de unidade e
TDD para garantir
a qualidade do código. Porém o desenvolvedor é também responsável por fazer o teste de aceitação passar. Para isso,
você precisa escrever um Fixture, que na verdade é uma classe
que será chamada pelo framework e te dará acesso aos dados escritos no documento FIT. A partir daí, você faz as
chamadas necessárias ao código da sua aplicação e avalia os resultados de acordo com as expectativas descritas no
documento FIT. Abaixo são duas tabelas que fizemos para especificar uma parte de um sistema de venda online de
serviços de internet:

Agile Quality: A Canary in a Coal Mine – Ken Schwaber

A sessão que escolhi participar depois do almoço foi do outro inventor do Scrum:
Ken Schwaber. Ele falou sobre a importância da qualidade como
atributo essencial num sistema de software: devemos nos preocupar com a qualidade desde o início. O custo para
colocar a qualidade depois é muito alto, podendo até levar um projeto ao fracasso no longo prazo devido à perda
de vantagem competitiva. Quando mais tempo você gasta lidando com defeitos no seu sistema, menos tempo sobre para
pensar no valor que ele está trazendo para o negócio. E o principal objetivo de qualquer sistema de software
deve ser agregar valor ao negócio. Na sua palestra, Ken tentou mostrar a importância da qualidade para um projeto de software e defendeu a idéia de que cortar qualidade deve ser uma decisão de negócio.

Agile Stories – Research Papers

Na segunda metade da tarde, resolvi assistir à apresentação de 3 papers, numa trilha chamada “Agile Stories”.
Falarei um pouco sobre cada um dos papers nos tópicos abaixo:

The Deployment Production Line – Jez Humble, Chris Read e Dan North

Esse artigo foi bem interessante: eles mostraram uma forma efetiva de estruturar e automatizar a implantação da sua
aplicação em diferentes ambientes (teste, integração, aceitação, …). O artigo explica de forma mais detalhada a idéia
da linha de produção que eles desenvolveram num projeto da ThoughtWorks. O interessante
é que eles automatizaram o processo de tal forma que qualquer pessoa podia fazer o deploy de qualquer versão do sistema
em qualquer ambiente com poucos cliques. É interessante ressaltar também o modo em que eles quebraram as dependências
para acelerar a execução dos testes nos diferentes ambientes, paralelizando em várias instâncias separadas do
Cruise Control a execução dos testes de unidade, testes de aceitação nos
cenários de sucesso (smoke tests, que rodam mais rápido), testes de aceitação nos cenários mais complicados (demoram
mais), testes de performance, etc. Com isso, um determinado build vai ganhando “medalhas” conforme passa em
cada etapa de teste, ficando fácil de saber quando ele pode ou não ser implantado em ambiente de produção.

The Cost of Code Quality – Yuri Kharmov

Essa apresentação foi, por enquanto, a pior da conferência. Foi o oposto da palestra do Ken Schwaber
que eu tinha acabado de assistir. O autor defendeu a idéia de que nem sempre precisamos
nos preocupar com a qualidade quando escrevemos código. O principal argumento dele é: toda preocupação com
qualidade tem um custo associado e você deve considerá-lo na hora de usar técnicas como TDD ou Integração Contínua,
em outras palavras, não é um grande problema ter um sistema cheio de bugs se eles não te atrapalham.
Duas coisas me incomodaram: em primeiro lugar ele transpareceu não entender a verdadeira essência de
TDD como uma
ferramenta que possibilita o Design Incremental.
Segundo, quando perguntaram para ele ao final da palestra quantas vezes ele discutia sobre qualidade de código com
o cliente, ele respondeu “Quase nunca”. Como ele pode julgar pelo cliente o valor da ausência ou não de bugs se ele
nunca discute sobre isso?

Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value – Deborah Hartmann e Robin Dymond

A última palestra do dia foi sobre métricas ágeis. Eu achei bem interessante a distinção entre “Diagnósticos” e “Métricas”
proposta pelos autores:

• “Diagnósticos”: são números que te ajudam a entender o andamento das coisas em relação ao processo. Por exemplo: medir a velocidade do time; interpretar o gráfico de “Burn-Down” para descobrir se o time irá terminar no prazo; ou saber a quantidade de defeitos. “Diagnósticos” dependem do contexto do time e devem ser temporários, ou seja, descarte-os assim que o processo estiver funcionando.
• “Métricas”: são números que medem o valor de negócio que seu sistema está produzindo. Por exemplo: retorno de investimento; lucro; ou presença de mercado. “Métricas” são mais difíceis de medir, por isso é bom escolher apenas uma.

É preciso tomar cuidado com as métricas que você escolhe para avaliar o desempenho de uma equipe ágil, afinal
“You get what you measure”. Outra coisa que eles mostraram foi um template para ser utilizado na hora de
criar uma métrica ágil, com pontos que te fazem pensar sobre o verdadeiro valor que aquela métrica irá representar
quando estiver medindo o sucesso do seu software.