Você está na página 1de 10

Mtricas de Acompanhamento para Metodologias geis

De que se trata o artigo?


Este artigo apresenta os conceitos relacionados s mtricas para auxiliar o tracker de uma equipe gil, discutindo denies, classicaes, diferentes abordagens para escolha das melhores mtricas e, por m, apresentando alguns exemplos que podem ser utilizados no acompanhamento de uma equipe gil. importncia est no fato de que possibilita um acompanhamento mais preciso das atividades do projeto. Em particular, mtricas podem ser uma tima ferramenta no apoio ao controle de projetos de desenvolvimento de software utilizando metodologias geis.

Em que situao o tema til?


Apoiar o responsveis pelo projeto na definio de abordagens mais precisas de acompanhamento de forma a possibilitar a melhoria dos trabalhos na organizao.

Para que serve?


Mtricas um tema muito discutido em toda a comunidade de engenharia de software. Sua

O
Danilo Sato
danilo@dtsato.com / www.dtsato.com

Danilo Sato Desenvolvedor, Coach e Consultor da ThoughtWorks UK. Com formao e mestrado em Cincia da Computao pelo IME/USP no tema Mtodos geis, tambm fundador do Dojo@SP e membro da AgilCoop. Danilo j ministrou cursos sobre diversos assuntos relacionados a Mtodos geis e palestrou em diversas conferencias,incluindo: XP 2007 (Itlia), Agile 2008 (Canad), Agiles 2008 (Argentina) e Falando em Agile (Brasil).

s Mtodos geis promovem um processo emprico para o desenvolvimento de software. Essa abordagem exige um ciclo constante de inspeo, adaptao e melhoria. Encontrar maneiras eficazes de avaliar o processo e a equipe de desenvolvimento no uma tarefa simples. Isso leva a uma proliferao de medidas baseadas na premissa de que se cada parte do processo for otimizada, os resultados do processo como um todo sero otimizados tambm. No entanto, essa premissa nem sempre verdadeira. Ao tentar micro-otimizar partes de um sistema por meio de diversas mtricas, o verdadeiro objetivo se perde em meio

a tantos substitutos e a equipe perde sua capacidade de tomar decises de balanceamento (trade-off) [15]. Alm disso, a preocupao com as medidas erradas pode gerar incentivos errados, levando a consequncias indesejveis. Goldratt diz que as pessoas se comportam de acordo com a forma com que esto sendo medidas: Diga-me como serei avaliado e eu lhe direi como me comportarei [1]. A escolha das melhores formas de medio uma tarefa do Time Completo e o tracker possui um papel especial. Jeffries [2] e Auer [3] descrevem o papel do tracker como algum responsvel por prover informaes para a equipe sobre o progresso

Engenharia de Software Magazine - Mtricas de Acompanhamento para Metodologias geis

METODOLOGIA S G EIS

do time, utilizando as mtricas apropriadas para destacar os pontos de melhoria e atualizando regularmente essas informaes nos grficos e psteres na rea de Trabalho Informativa, que Cockburn chama de radiadores de informao [4]. Este artigo apresenta os conceitos relacionados s mtricas para auxiliar o tracker de uma equipe gil, discutindo definies, classificaes, diferentes abordagens para escolha das melhores mtricas e, por fim, apresentando alguns exemplos que podem ser utilizados no acompanhamento de uma equipe gil.

Definies
Para discutir o papel das mtricas no acompanhamento de projetos geis, primeiro preciso definir alguns conceitos que nem sempre so usados da forma correta, com uma troca frequente de significados. Em particular, importante conhecer as diferenas sutis entre os conceitos de medidas, mtricas e indicadores. Segundo o IEEE, uma medida uma avaliao em relao a um padro [5]; McGarry diz que a avaliao de um atributo segundo um mtodo de medio especfico, funcionalmente independente de todas as outras medidas e capturando informao sobre um nico atributo [6]. Um exemplo de medida 5 cm: centmetro o padro e 5 a medida, que indica quantos mltiplos ou fraes do padro esto sendo representados. Em desenvolvimento de software, um exemplo de medida pode ser o nmero de linhas de cdigo. No entanto, no existe um padro universal para representar linhas de cdigo, pois as linguagens podem variar, assim como as regras para clculo de linhas de cdigo. Portanto, uma medida pode ser baseada em um padro local ou universal, mas o padro precisa ser bem definido. Uma mtrica um mtodo para determinar se um sistema, componente ou processo possui um certo atributo [7]. Ela geralmente calculada ou composta por duas ou mais medidas. Um exemplo de mtrica o nmero de defeitos encontrados aps a implantao: as medidas que compem essa mtrica so o nmero de defeitos e a fase (ou data) onde o defeito foi identificado. Um indicador um dispositivo ou varivel que pode ser configurado para um determinado estado com base no resultado de um processo ou ocorrncia de uma determinada condio. Por exemplo: um semforo ou uma flag [7]. Conforme a definio do IEEE, um indicador algo que chama a ateno para uma situao particular. Ele geralmente est relacionado a uma mtrica e prov a interpretao daquela mtrica numa determinada situao ou

contexto. Sempre que algum interpreta alguma mtrica, est considerando algum tipo de indicador, seja ele algum valor base ou outra mtrica. Por exemplo: um aumento substancial no nmero de defeitos encontrados na ltima verso pode ser um indicador de que a Qualidade do software piorou. O seguinte exemplo fictcio demonstra a relao entre medidas, mtricas e indicadores: ao trmino da primeira iterao de um projeto, constata-se que a equipe entregou 4 Histrias, somando um total de 20 pontos (Figura 1 (a)). Conforme a equipe vai terminando as prximas iteraes, percebe-se que o nmero total de pontos entregues aumenta aos poucos. Aps certo tempo, essa tendncia de subida interrompida e o nmero total de pontos entregues cai um pouco, atingindo um patamar (Figura 1 (b)). A Figura 1 (a) representa uma medida. Sem nenhuma outra informao para comparar ou uma tendncia para seguir, uma medida no prov muita informao. A Figura 1 (b) representa uma mtrica, nesse caso a velocidade da equipe. Uma mtrica composta por diversas medidas como o nmero de pontos entregues e o nmero da iterao terminada. Assim que a mtrica se estabiliza, a equipe pode considerar um patamar para sua velocidade. Esse valor base, apresentado na Figura 1 (c) representa um indicador. Ele d um contexto para a mtrica, servindo como base para comparao. Uma mtrica sempre interpretada sob um ponto de vista especfico. Por isso, possvel derivar diversos indicadores a partir da mesma mtrica. O significado de um indicador sempre depende de um contexto, portanto duas equipes podem analisar a mesma mtrica de forma diferente. Supondo outro cenrio, onde essa mesma equipe utilizasse como indicador um valor base inferior para sua velocidade (derivado de outros projetos, por exemplo). Nesse caso, a mesma mtrica Figura 1 (b) poderia ser interpretada como uma melhoria. No caso anterior, a equipe no tinha nenhum indicador prvio e houve apenas uma estabilizao para que esse valor base fosse descoberto. A palavra mtrica ser utilizada neste texto daqui em diante. No entanto, sempre que uma mtrica for interpretada, avaliada ou analisada, o conceito de um indicador estar sempre implcito. Da mesma forma, toda mtrica depende de medidas, portanto elas tambm esto sendo consideradas.

Classificaes
As mtricas podem ser classificadas segundo diferentes critrios. Esta seo apresenta algumas das possveis classificaes que um tracker precisa considerar quando utilizar uma mtrica.

Figura 1. Total de Pontos Entregues por Iterao

Edio 12 - Engenharia de Software Magazine

Objetiva/Subjetiva
Conforme discutido anteriormente, uma mtrica composta por medidas que avaliam atributos de um objeto. O valor de uma mtrica objetiva depende somente do objeto em questo e no do ponto de vista de quem a est interpretando. Por exemplo: nmero de commits no repositrio uma mtrica objetiva, pois obtida diretamente da ferramenta. Por outro lado, o valor de uma mtrica subjetiva depende do objeto em questo e tambm do ponto de vista de quem a est interpretando. Um exemplo de mtrica subjetiva a qualidade do cdigo, numa escala de 0% a 100%. Apesar da escala definir um intervalo numrico, a natureza da mtrica ainda subjetiva, pois depende do ponto de vista de quem est avaliando. Os critrios para definir a qualidade do cdigo variam de pessoa para pessoa. Mtricas objetivas so passveis de serem obtidas de forma automatizada.

Organizacional/Acompanhamento
Hartmann e Dymond sugerem outra categoria para classificao, distinguindo mtricas organizacionais de mtricas de diagnstico [10]. Neste texto, ao invs de usar o termo diagnstico usarei o termo acompanhamento por estar mais alinhado com o tema do artigo e por compartilhar as mesmas caractersticas de diagnstico propostas por Hartmann e Dymond. Mtricas organizacionais so aquelas que medem a quantidade de valor de negcio entregue ao cliente. Essa definio levanta algumas perguntas: em primeiro lugar, quem o cliente? Collins sugere que, no nvel organizacional, o cliente deve ser o dono ou o responsvel pelo produto (stakeholder) ou talvez o usurio final [11]. Isso deixa a segunda pergunta em aberto, o que valor? No seu livro, Collins discute os atributos e comportamentos em comum das empresas que passaram de um longo histrico de resultados medocres para um longo histrico de resultados extraordinrios. Ele mostra que as empresas que foram do bom para o timo escolheram um fator-chave nico de direcionamento econmico como mtrica para auxiliar na tomada de deciso. Idealmente, essa mtrica-chave deve ser definida pelos executivos da empresa, porm em projetos de cdigo aberto, onde o objetivo final nem sempre financeiro, outros fatores de sucesso como nmero de usurios ou a satisfao do usurio podem ser utilizados. A seo Mtricas Organizacionais apresentar com mais detalhes alguns exemplos de mtricas organizacionais. Mtricas de acompanhamento provem informaes que ajudam o time no entendimento e Melhoria do processo que produz valor de negcio. Uma vez que uma mtrica organizacional ampla definida, a equipe precisa de medies locais para auxili-los a atingir o objetivo. Essas mtricas agregam dados, porm no os associam a nenhum indivduo. Elas existem e tm validade dentro de um contexto particular, porm recomenda-se que elas sejam escolhidas com cuidado e utilizadas somente durante certo perodo de tempo. Mtricas de acompanhamento devem ser descartadas uma vez que tenham servido seu propsito. A meta mais ampla definida pela mtrica organizacional deve guiar a utilizao de diferentes mtricas de acompanhamento temporrias. Um exemplo de mtrica de acompanhamento j citado neste artigo a velocidade da equipe. Poppendieck utiliza uma nomenclatura diferente para as mtricas organizacionais e de acompanhamento, chamando-as de mtricas de avaliao de desempenho e mtricas informativas, respectivamente [12]. Apesar dos nomes serem diferentes, as caractersticas descritas nesta seo so as mesmas.

Quantitativa/Qualitativa
Alm da natureza objetiva/subjetiva, uma mtrica pode ainda ser classificada como quantitativa ou qualitativa. O valor de uma mtrica quantitativa pertence a um intervalo de uma certa magnitude e geralmente representado por um nmero. Tal estrutura permite que medidas quantitativas sejam comparadas entre si. A maioria dos exemplos utilizados at aqui neste artigo representam mtricas quantitativas, como o nmero de linhas de cdigo ou o nmero de defeitos encontrados. Por outro lado, valores de uma mtrica qualitativa so aqueles representados por palavras, smbolos ou figuras ao invs de nmeros [8]. Um exemplo de mtrica qualitativa o humor da equipe ou a satisfao do cliente. A maioria dos estudos empricos em Engenharia de Software usa uma combinao entre mtodos quantitativos e qualitativos. Uma das formas mais comuns de combinar ambas as estratgias a codificao, que consiste na extrao de valores quantitativos dos dados qualitativos para permitir o tratamento estatstico ou outra abordagem quantitativa [9]. Vale ressaltar que a classificao de uma mtrica como quantitativa ou qualitativa ortogonal classificao como objetiva ou subjetiva. Geralmente uma mtrica quantitativa objetiva e uma qualitativa subjetiva, mas isso no sempre verdade. O processo de codificao transforma uma mtrica qualitativa em quantitativa, mas no altera sua objetividade ou subjetividade. Por exemplo, considere a seguinte frase que constitui um fragmento de dado qualitativo: Joo, Maria e Pedro foram os nicos que participaram da reunio. Isso poderia ser transformado num dado quantitativo como: numero de participantes = 3. A informao continua objetiva aps a codificao. Alm disso, uma parte da informao perdida, pois no sabemos mais os nomes dos participantes. Considerando agora outro exemplo de dado qualitativo: Paulo disse que essa classe Java bem simples de entender e sua complexidade bem menor que as outras classes do sistema. Tal informao poderia ser codificada para o seguinte dado quantitativo: complexidade = baixa. Houve novamente perda de informao no processo de codificao e, apesar do valor quantitativo parecer mais objetivo, continua to subjetivo quanto antes.

O Que Medir?
Nesta seo so apresentadas algumas abordagens para escolher quais mtricas utilizar, apresentando tambm algumas das caractersticas de uma boa mtrica gil. Um tracker deve utilizar as abordagens apresentadas aqui juntamente com o conhecimento sobre sua equipe ao escolher as melhores mtricas para sua situao.

Engenharia de Software Magazine - Mtricas de Acompanhamento para Metodologias geis

METODOLOGIA S G EIS

Abordagem Objetivo-Pergunta-Mtrica (Goal Question Metric)


Uma das abordagens mais conhecidas e utilizadas em estudos empricos em Engenharia de Software a abordagem objetivopergunta-mtrica (Goal Question Metric ou GQM), proposta por Basili [13]. O modelo de medio proposto pelo GQM composto de trs nveis: Nvel Conceitual (Objetivo): Um objetivo definido para um objeto em relao a algum modelo de qualidade, a partir de diversos pontos de vista e para um ambiente especfico. Um objeto pode ser um produto (documento, cdigo-fonte, testes, etc.), um processo (especificao, entrevista, codificao, etc.) ou um recurso (pessoas, hardware, espao fsico, etc.); Nvel Operacional (Pergunta): Um conjunto de perguntas caracterizam a forma de avaliao e cumprimento do objetivo escolhido. As perguntas tentam relacionar o objeto de estudo com as caractersticas de Qualidade desejveis a partir do ponto de vista definido; Nvel Quantitativo (Mtrica): Um conjunto de dados associado com cada pergunta para tentar encontrar uma forma quantitativa de respond-la. Mtricas podem ser objetivas ou subjetivas. Esse modelo define uma estrutura hierrquica que comea com um objetivo claro. O formato proposto pela abordagem GQM para definir um objetivo composto de: uma motivao, uma preocupao ou tpico, um objeto e um ponto de vista. A partir desse objetivo, uma srie de perguntas definida e, a partir dessas perguntas, uma srie de mtricas escolhida. A mesma mtrica pode ser usada para responder diferentes perguntas. Da mesma forma, mtricas e perguntas podem ser utilizadas em mais de um modelo GQM para diferentes objetivos, porm a forma de medio deve levar em conta os diferentes pontos de vista de cada modelo. A Tabela 1 apresenta um exemplo de um modelo GQM. Segundo Basili, a definio de um objetivo deve se basear em trs fontes de informao [13]: a primeira fonte de informao so as polticas e estratgias organizacionais, de onde derivam a motivao e o tpico do objetivo; a segunda fonte so as descries dos processos e produtos da empresa, de onde deriva o objeto de avaliao; por fim, a terceira fonte de informao o modelo organizacional da empresa, de onde derivam os pontos de vista que sero levados em conta na avaliao do objetivo.

Objetivo

Motivao Tpico Objeto Ponto de vista

Melhorar o tempo gasto no processo de correo de defeitos sob o ponto de vista gerencial.

Pergunta Mtricas

Qual a velocidade atua de correo de um defeito? Tempo mdio de ciclo Desvio padro % de casos acima do limite mximo O processo de correo de defeitos est melhorando? (Tempo mdio de ciclo atual/Tempo mdio de ciclo desejado) * 100 Avaliao subjetiva do gerente responsvel

Pergunta Mtricas

Tabela 1. Exemplo de modelo Objetivo-Pergunta-Mtrica

Abordagem Lean
Ao adaptar os conceitos Lean que funcionaram bem para a manufatura, cadeia de suprimentos e desenvolvimento de produtos, Poppendieck prope uma abordagem para escolha das mtricas mais apropriadas [12, 15]. Conforme discutido na seo Organizacional/Acompanhamento, a abordagem Lean distingue bem as mtricas organizacionais das mtricas de acompanhamento e um de seus princpios para o desenvolvimento de software Otimizar o todo. Sua proposta para o uso de mtricas na avaliao de desempenho medir sempre um nvel acima. Uma tendncia natural para avaliao de desempenho a decomposio. O senso comum diz que se as partes de um sistema forem otimizadas, o sistema todo tambm o ser. No entanto a

micro-otimizao tende a degradar o resultado geral, pois no possvel medir tudo. Austin discute os problemas da avaliao de desempenho e destaca que sua principal vantagem (Voc tem o que voc mede) tambm seu principal problema (Voc tem exatamente o que voc mede, e nada mais). Fatores importantes acabam ficando fora da decomposio por no serem facilmente mensurados, como: criatividade, insight, colaborao, dedicao e preocupao com a satisfao do cliente [14]. Quando a avaliao de um indivduo realizada por uma mtrica que leva em conta apenas fatores dentro do seu campo de influncia, ele tende a trabalhar para otimizar essa mtrica, deixando de pensar no sistema como um todo. A prtica sugerida pela abordagem Lean medir sempre em um nvel acima. Quando a avaliao leva em conta o Time Completo ou a empresa toda, ela gera incentivos para que os indivduos trabalhem de forma colaborativa para atingir um resultado comum. Por isso, ao invs de criar diversas mtricas, mais importante reduzir o nmero de mtricas organizacionais, escolhendo uma que defina um objetivo amplo, gerando os incentivos que faro com que o comportamento dos subsistemas otimizem o todo [15]. Alm das mtricas organizacionais, a abordagem Lean tambm sugere o uso de mtricas de acompanhamento para auxiliar a equipe. No entanto, essas mtricas devem ser definidas de forma a ocultar o desempenho individual. Quando a contagem de defeitos leva em conta o indivduo que causou o erro, ela passa a ser uma mtrica de avaliao, gerando os incentivos errados. Deming diz que a baixa qualidade nunca responsabilidade de um indivduo, mas sim de um processo de gerenciamento que permite que a ausncia de defeitos seja impossvel [16]. Por isso, importante que uma mtrica de acompanhamento seja totalmente desassociada de qualquer avaliao de desempenho. Seu propsito deve ser meramente informacional.

Retrospectivas
Reunies de Retrospectiva encorajam a discusso constante sobre o processo e a forma de trabalho da equipe. Elas so o momento de Reflexo que deve fazer parte do ciclo de inspeo e adaptao proposto pelos Mtodos geis. Segundo Cockburn, o criador da Famlia Crystal onde a Retrospectiva prtica fundamental, elas ajudam a encontrar o processo mais aceitvel para a equipe [4].

Edio 12 - Engenharia de Software Magazine

O resultado de uma reunio de Retrospectiva costuma ser um pster destacando os principais pontos de melhoria que a equipe escolheu se concentrar na prxima iterao. A partir dessa discusso, o tracker pode escolher algumas mtricas de acompanhamento para auxiliar a equipe a entender o progresso em relao aos pontos de melhoria levantados. A seo Mtricas de Acompanhamento apresenta exemplos de mtricas de acompanhamento para auxiliar o tracker e a equipe nessa escolha.

Discusso
As abordagens apresentadas na seo O Que Medir? possuem vantagens e desvantagens e o tracker de uma equipe gil deve saber balance-las. O modelo GQM prope uma abordagem top-down para a definio de mtricas que por um lado esclarece os objetivos por trs de cada mtrica e evita a medio das coisas erradas, porm por outro lado sua estrutura hierrquica estimula a proliferao de diversas mtricas. J a abordagem Lean distingue bem os dois nveis de medio (organizacional/ acompanhamento) e estimula um menor nmero de mtricas organizacionais. A prtica de medir sempre um nvel acima evita a proliferao de mtricas e cria os incentivos para a colaborao entre todos os responsveis pelo Fluxo de entrega de valor do sistema. Apesar de ambas as abordagens funcionarem para a definio e escolha das mtricas organizacionais, no do muita direo em relao escolha das mtricas de acompanhamento. As reunies de Retrospectiva resolvem esse problema, fazendo com que a prpria equipe discuta e reflita sobre os pontos do processo que podem ser melhorados. Essa discusso auxilia a escolha das melhores mtricas de acompanhamento. Com base nas caractersticas apresentadas na seo Caractersticas de Uma Boa Mtrica gil, Hartman e Dymond sugerem que o tracker utilize uma lista de verificao ao escolher uma mtrica [10]. Levando em considerao a discusso sobre as diferentes abordagens, o autor prope uma adaptao dessa lista, apresentada na Tabela 2.

Caractersticas de uma boa mtrica gil


Com base em diversas fontes, Hartman e Dymond propem uma compilao de algumas das heursticas que um tracker deve considerar quando estiver escolhendo uma mtrica para sua equipe [10]. Uma boa mtrica gil deve: Reforar princpios geis: colaborao com o cliente e entrega de valor so princpios fundamentais para os Mtodos geis; Medir resultados e no sadas: ao valorizar a Simplicidade, os melhores resultados podem ser aqueles que minimizam a quantidade de trabalho realizado. Medir os resultados obtidos mais importante que medir as sadas das atividades do processo; Seguir tendncias e no nmeros: os valores representados por uma mtrica so menos importantes que a tendncia demonstrada. Ao medir a velocidade da equipe, melhor se preocupar com sua estabilizao do que com o valor absoluto que ela representa; Responder uma pergunta especfica para uma pessoa real: toda mtrica deve expor informao para um ponto de vista especfico. Se outra pessoa tem outra pergunta, melhor usar outra mtrica; Pertencer a um conjunto pequeno de mtricas e diagnsticos: impossvel medir tudo. Muita informao pode esconder o que realmente importa. Minimize o nmero de mtricas e mea o que mais importante; Ser facilmente coletada: para mtricas de acompanhamento objetivas e quantitativas, o ideal ter uma coleta automatizada; Revelar, ao invs de esconder, seu contexto e suas variveis: uma mtrica deve deixar claro os fatores que a influenciam para evitar manipulaes e facilitar a Melhoria do processo; Incentivar a Comunicao: uma mtrica isolada de seu contexto perde o sentido. Um bom sinal quando as pessoas comentam o que aprenderam com uma mtrica; Fornecer Feedback frequente e regular: para amplificar o aprendizado e acelerar o processo de Melhoria, as mtricas devem ser frequentemente atualizadas e disponibilizadas na rea de Trabalho Informativa; Encorajar um alto nvel de Qualidade: o nvel aceitvel de Qualidade deve ser definido pelo cliente e no pela equipe. Os Mtodos geis exigem sempre um alto nvel de Qualidade do software desenvolvido.

Exemplos
Esta seo apresenta alguns exemplos de medidas e mtricas organizacionais e de acompanhamento. Essa lista no pretende ser exaustiva, enumerando todas as possveis medidas e mtricas.

Medidas
As medidas apresentadas nesta seo sero separadas de acordo com sua respectiva classificao (conforme descrito na Seo Classificaes). Abaixo seguem exemplos de medidas quantitativas e objetivas. Por sua natureza, elas podem ser coletadas de forma automatizada. Total de Linhas de Cdigo (TLC): representa o nmero total de linhas de cdigo de produo do sistema, descartando linhas em branco e comentrios. comum a utilizao de variaes dessa medida, como contando aos milhares (Thousand Lines of Executable Code ou KLOEC) ou considerando o nmero de Linhas de Cdigo por Classe (LCC); Total de Linhas de Cdigo de Teste (TLCT): representa o nmero total de pontos de teste do sistema, conforme definido por Dubinsky [17]. Um ponto de teste considerado como um passo do cenrio de um teste de aceitao automatizado ou como uma linha de cdigo de teste de unidade automatizado, descartando linhas em branco e comentrios; Nmero de Linhas Alteradas: representa o nmero de linhas (no apenas cdigo-fonte) adicionadas, removidas e atualizadas no Repositrio de Cdigo Unificado; Nmero de Commits representa o nmero de commits efetuados no Repositrio de Cdigo Unificado;

10

Engenharia de Software Magazine - Mtricas de Acompanhamento para Metodologias geis

METODOLOGIA S G EIS

Lista de Verificao de uma Mtrica gil Caracterstica Nome Classificao Objetivo Pergunta Base de Medio Suposies Tendncia Esperada Quando utilizar? Quando parar de utilizar? Formas de Manipulao Cuidados e Observaes Descrio Deve ser bem escolhido para evitar confuso e ambigidade Conforme apresentado na Seo Classificaes Conforme definido no modelo GQM, incluindo uma motivao, uma preocupao ou tpico, um objeto e um ponto de vista Conforme definido no modelo GQM, toda mtrica deve estar associada a uma pergunta especfica Uma clara definio das medidas utilizadas para clculo da mtrica Devem ser identificadas para um claro entendimento do que os dados esto representando Uma idia de qual o comportamento esperado para a mtrica Deve esclarecer os motivos que levaram criao da mtrica e, caso a mtrica j tenha sido utilizada anteriormente, mostrar um pouco do seu histrico importante saber at quando uma mtrica ser til, antes mesmo de utiliz-la, principalmente para mtricas de acompanhamento Deve esclarecer como as pessoas tentaro alterar seu comportamento em funo da mtrica para gerar nmeros mais favorveis Recomendaes sobre outras mtricas similares, limites no uso e perigos associados m utilizao da mtrica

Tabela 2. Lista de verificao ao escolher uma mtrica, adaptado de [10]

Estimativas Originais: representa o total de pontos (ou horas) originalmente estimadas pela equipe para todas as Histrias da iterao. Beck e Fowler sugerem a utilizao de horas ideais [18] nas estimativas e controle da iterao, mas a unidade de medida efetivamente utilizada no importa tanto, contanto que seja usada consistentemente durante o projeto; Estimativas Finais: representa o total de pontos (ou horas, ou horas ideais) efetivamente reportadas como gastas para implementar as Histrias da iterao; Nmero de Histrias Entregues: representa o nmero total de Histrias implementadas e aceitas pelo cliente; Nmero de Pontos Entregues: representa o nmero total de pontos implementados e aceitos pelo cliente; Tempo: utilizado no clculo de diversas mtricas, pode ser utilizado como durao (em meses, semanas, dias, etc.) ou como nmero de iteraes; Tamanho da Equipe: geralmente utilizado no clculo de mtricas, representa a quantidade de pessoas na equipe; Esforo: uma medida que leva em conta o tamanho da equipe durante um certo intervalo de tempo, geralmente medido em pessoas-ms ou pessoas-ano; Complexidade Ciclomtica de McCabe (v(G)): mede a quantidade de lgica de deciso num nico mdulo de software [19]. Num sistema orientado a objetos, um mdulo um mtodo. Um Grafo de controle de fluxo descreve a estrutura lgica de um algoritmo atravs de vrtices e arestas. Os vrtices representam expresses ou instrues computacionais (como atribuies, laos ou condicionais), enquanto as arestas representam a transferncia do controle entre os vrtices [20]. A Complexidade Ciclomtica definida para cada mdulo como e n + 2, onde e e n so o nmero de arestas e vrtices do grafo de controle de fluxo, respectivamente; Mtodos Ponderados por Classe (Weighted Methods per Class ou WMC): mede a complexidade de uma classe num sistema orientado a objetos. Definida para cada classe como a soma ponderada de todos os seus mtodos [21]. comum utilizar v(G) como fator de peso, ento WMC pode ser calculada como ci, onde ci a Complexidade Ciclomtica do i-simo mtodo

de uma mesma classe; Falta de Coeso dos Mtodos (Lack of Cohesion of Methods ou LCOM): mede a coeso de uma classe e calculada atravs do mtodo de Henderson-Sellers [22]. Se m(A) o nmero de mtodos que acessam o atributo A, LCOM calculada como a mdia de m(A) para todas os atributos, subtraindo o nmero de mtodos m e dividindo o resultado por (1 - m). Um valor baixo indica uma classe coesa, enquanto um valor prximo de 1 indica falta de coeso; Profundidade da rvore de Herana (Depth of Inheritance Tree ou DIT): o comprimento do maior caminho a partir de uma classe at a classe-base da hierarquia; Nmero de Filhos (Number of Children ou NOC): o nmero total de filhos imediatos de uma classe; Acoplamento Aferente (Afferent Coupling ou AC): o nmero total de classes de fora de um pacote que dependem de classes de dentro do pacote. Quando calculada no nvel da classe, essa medida tambm conhecida como Fan-in da classe; Acoplamento Eferente (Efferent Coupling ou EC): o nmero total de classes de dentro de um pacote que dependem de classes de fora do pacote. Quando calculada no nvel da classe, essa medida tambm conhecida como Fan-out da classe, ou como CBO (Coupling Between Objects ou Acoplamento entre Objetos) na famlia de mtricas CK (Chidamber-Kemerer) [21]. Alguns dos fatores de desenvolvimento propostos por Boehm e Turner [23] servem como exemplos de medidas quantitativas e subjetivas: Dinamismo: A quantidade de mudanas de requisitos por ms; Cultura: Uma medida da porcentagem da equipe que prefere trabalhar em um cenrio catico ao invs de um cenrio ordenado, ou seja, a porcentagem da equipe capaz de aceitar mudanas durante o projeto; Criticalidade: O impacto causado por uma falha no software, podendo afetar desde uma quantia aceitvel de investimento at a perda de uma vida; Nvel Pessoal: A porcentagem da equipe que pertence aos diversos nveis propostos por Cockburn [4];

Edio 12 - Engenharia de Software Magazine

11

Aderncia s Prticas de XP: uma forma de medir o grau de utilizao de cada prtica de XP. Cada integrante d uma nota para o nvel atual e desejado da equipe em relao a cada prtica de XP. Por fim, alguns exemplos de medidas qualitativas (que podem ser codificadas para medidas quantitativas, conforme descrito na seo Quantitativa/Qualitativa) e subjetivas so: Moral da Equipe: mede o humor e a motivao de cada membro da equipe; Satisfao do Cliente: mede o nvel de satisfao do cliente com o produto desenvolvido.

mtrica atravs da entrega das funcionalidades mais fceis, ao invs das mais importantes. Definir poucos testes tambm far com que a funcionalidade esteja pronta mais rapidamente; Cuidados e Observaes: Medir funcionalidade entregue pode no refletir diretamente em valor de negcio. O excesso de funcionalidades , na verdade, um dos grandes inimigos do desenvolvimento de software. importante que as funcionalidades entregues no incio do projeto sejam as mais importantes e com maior valor de negcio.

Tempo Mdio de Ciclo (Cycle Time)


Classificao: Qualitativa e objetiva; Objetivo: Minimizar o tempo mdio de ciclo de um sistema, sob o ponto de vista do cliente final (usurio); Pergunta: Quanto tempo gasto do conceito ao retorno financeiro (concept to cash)? Ou entre uma ordem de compra de um cliente e sua realizao em forma de software entregue? Ou entre a identificao de um defeito em produo e sua resoluo? O importante no descobrir o quo rpido o sistema pode entregar valor, mas sim o quo rpido o sistema entrega valor de forma repetitiva e confivel; Base de Medio: Com base num mapa de Fluxo de valor do sistema todo (Value Stream Map), que sempre comea e termina com o cliente e, para cada parte do processo, mapeia quanto tempo gasto agregando valor ao sistema e quando tempo desperdiado em tarefas que no agregam valor [12]. O tempo de ciclo calculado de forma objetiva atravs da medio do tempo que uma ordem leva para passar pelo mapa de Fluxo de valor do sistema; Suposies: A equipe conhece as etapas do processo por onde uma ordem deve passar e o processo est mapeado num mapa de Fluxo de valor. O tempo total gasto para processar a ordem considera todos os tipos de desperdcio no sistema: falta de habilidades, atrasos, hand-offs entre diferentes equipes, etc.; Tendncia Esperada: O tempo mdio de ciclo do sistema deve diminuir gradualmente conforme o processo melhorado, at atingir um patamar mnimo. No entanto, a equipe tem autonomia para estar constantemente desafiando o processo e melhorando o continuamente, diminuindo ainda mais o tempo mdio de ciclo; Quando utilizar? Para avaliar o comprometimento das pessoas com o sistema todo. Ela exige que outras mtricas mais locais sejam otimizadas, porm o contrrio no verdade. A preocupao em otimizar subsistemas provavelmente far com que o tempo de ciclo aumente [15]; Quando parar de utilizar? Quando o sistema no precisar mais produzir valor. Formas de Manipulao: Por ser uma mtrica ampla, essa mtrica cria os incentivos para que as equipes cruzem barreiras do processo, exigindo que as pessoas colaborem para criar um produto de Qualidade. Dessa forma, fica difcil manipular essa medida; Cuidados e Observaes: O tempo mdio de ciclo tende a diminuir quando o sistema trabalha com peas pequenas (small batches). No caso do desenvolvimento de software, por exemplo, essas peas podem ser Histrias ou defeitos. Se

Mtricas Organizacionais
Esta seo apresenta quatro exemplos de mtricas organizacionais, que podem ser utilizadas para avaliao de uma equipe gil: Funcionalidades Testadas e Entregues uma mtrica proposta por Ron Jeffries [24], Tempo Mdio de Ciclo foi proposta pela abordagem Lean [12, 15], Retorno Financeiro uma mtrica mais amplamente citada [25, 15, 10] e Net Promoter Score foi proposta por Reichheld [26]. Elas sero apresentadas conforme o formato proposto na seo Discusso.

Funcionalidades Testadas e Entregues (Running Tested Features ou RTF)


Classificao: Quantitativa e subjetiva, pois o cliente define quando uma funcionalidade est pronta atravs dos testes de aceitao; Objetivo: Maximizar a quantidade de valor de negcio entregue em cada funcionalidade do sistema, sob o ponto de vista do cliente; Pergunta: Qual a taxa de valor de negcio entregue por funcionalidade testada e implantada? Quando o software deixa de ser inventrio e passa a agregar valor? Base de Medio: Requisitos so quebrados em Histrias (Funcionalidades). Testes de aceitao automatizados so definidos pelo cliente e servem como critrio para avaliar quando a Histria est pronta (Testada). Toda funcionalidade pronta deve estar integrada num nico produto, com a possibilidade de ser implantado e prontamente utilizado (Entregue); Suposies: O cliente deve trabalhar em colaborao com a equipe, definindo Histrias e cenrios de aceitao. Uma funcionalidade testada e pronta s poder trazer valor efetivo de negcio quando entrar em produo; Tendncia Esperada: RTF deve crescer linearmente logo aps o incio do projeto e at o seu trmino. As funcionalidades que trazem mais valor sero implementadas primeiro; Quando utilizar? Para avaliar a execuo de projetos geis. Para entregar funcionalidades testadas a partir do incio do projeto, a equipe vai precisar de prticas geis. Ela no ter tempo de fazer muito design prematuro (Big Design Up-Front), assim como no poder se esquecer dos testes automatizados; Quando parar de utilizar? Quando o projeto terminar ou o retorno financeiro no justificar seu prolongamento; Formas de Manipulao: Uma forma de manipular essa

12

Engenharia de Software Magazine - Mtricas de Acompanhamento para Metodologias geis

METODOLOGIA S G EIS

o tempo mdio de ciclo se estabilizar, isso no significa que a equipe chegou ao valor timo. Ela deve estar constantemente desafiando os padres atuais para encontrar formas de reduzir o tempo mdio de ciclo [15].

Retorno de Investimento (Return of Investment ou ROI)


Classificao: Quantitativa e objetiva; Objetivo: Minimizar o tempo gasto at um sistema trazer retorno financeiro, sob o ponto de vista do cliente; Pergunta: Qual a taxa de retorno financeiro do projeto? Quando ele comear a ser obtido? Qual o lucro esperado com o investimento num sistema de software? Base de Medio: Atravs de anlise do fluxo de caixa financeiro por iterao; Suposies: A entrega de valor ser realizada ao final da iterao, no entanto o retorno financeiro s ser obtido quando o software entrar em produo; Tendncia Esperada: As funcionalidades com maior valor e maior retorno sero entregues no incio do projeto e, conforme as outras funcionalidades vo sendo implementadas, o retorno obtido por funcionalidade vai reduzindo; Quando utilizar? Ao analisar, priorizar e executar projetos onde algum retorno financeiro esperado. Essa mtrica deve ser compreendida por todos os envolvidos no projeto; Quando parar de utilizar? Quando o investimento for retirado ou quando as funcionalidades deixarem de agregar valor financeiro justificvel; Formas de Manipulao: Entregar as funcionalidades menores, ao invs das que trazem mais valor financeiro, no incio do projeto para que o ROI comece a ser obtido rapidamente. Isso pode afetar a taxa de retorno financeiro esperada; Cuidados e Observaes: Assim que o software entra em produo, com um subconjunto das funcionalidades esperadas, o modelo de retorno financeiro deve ser reavaliado e as funcionalidades restantes re-priorizadas para levar em conta os dados reais de retorno financeiro. Alm disso, a equipe toda deve ser exposta ao modelo de lucros e perdas que afetar o resultado financeiro do projeto, para que tenham o conhecimento necessrio ao tomar decises de compromisso (tradeoff) durante o desenvolvimento. Outras mtricas para avaliao de retorno financeiro, como Net Present Value (NPV) ou Internal Rate of Return (IRR) tambm podem ser utilizados como mtrica organizacional.

questo para o cliente final: O quanto voc recomendaria a empresa ou o produto X para um amigo ou colega?. Uma nota de 0 (no recomendaria) a 10 (definitivamente recomendaria) obtida. Clientes com nota entre 9 e 10 so chamados de promotores, notas entre 7 e 8 representam clientes neutros, enquanto notas entre 0 e 6 representam clientes afastadores (retractors). O NPS calculado subtraindo a porcentagem de clientes afastadores da porcentagem de clientes promotores, podendo variar entre -100% e 100%; Suposies: Seu produto atinge pessoas com poder de influncia no pblico em geral; Tendncia Esperada: Valores negativos do NPS representam um srio risco. Dessa forma, a tendncia esperada para esta mtrica de crescimento. Empresas boas possuem um NPS mdio de 10%, enquanto empresas realmente boas conseguem NPS de 50% [26]; Quando utilizar? Quando o produto no possuir intenes financeiras (projetos de cdigo aberto, por exemplo) ou quando seu pblico alvo tiver influncia no sucesso do produto; Quando parar de utilizar? Quando o produto no estiver mais tentando penetrao no mercado ou quando for finalizado; Formas de Manipulao: Como a influncia da equipe nos clientes finais do produto praticamente nenhuma, fica difcil manipul-los para obter um NPS melhor; Cuidados e Observaes: O valor bruto do NPS no pode usado para comparaes diretas entre empresas ou linhas de produto devido a diferenas nos segmentos de mercado ou at a diferenas geogrficas e culturais entre os clientes finais. Ele deve ser usado como um indicador de tendncia dentro de uma nica empresa ou produto.

Mtricas de Acompanhamento
Nesta seo so apresentados trs exemplos de mtricas de acompanhamento, que podem ser utilizadas para auxiliar na Melhoria do processo utilizado pela equipe para trazer valor de negcio. A Velocidade uma mtrica amplamente utilizada por equipes geis [25, 18, 27, 10], enquanto o Fator de Integrao e o Fator de Teste foram propostos pelo autor que, apesar de no conhecer uma citao especfica na literatura, acredita que sua autoria no seja original. As mtricas sero apresentadas conforme o formato proposto na seo Discusso. Por sua natureza mais descartvel, o objetivo de uma mtrica de acompanhamento, no formato proposto pelo modelo GQM, deve ser sempre Melhorar a adoo da prtica X sob o ponto de vista da equipe.

Net Promoter Score ou NPS


Classificao: Quantitativa e subjetiva, pois depende da avaliao da satisfao do cliente; Objetivo: Maximizar a satisfao do cliente final (usurio), sob o ponto de vista do cliente (do projeto); Pergunta: Como distinguir entre um dlar de lucro do tipo bom, que trar crescimento, e um dlar de lucro do tipo ruim, que prejudicar o crescimento? Como avaliar a satisfao do cliente final de um projeto de software? Base de Medio: Calculada com base numa nica e simples

Velocidade
Classificao: Quantitativa e objetiva; Pergunta: Quanto software a equipe consegue entregar por iterao? Base de Medio: Pontos (story-points) ou horas ideais entregues por iterao. Suposies: A equipe est entregando software funcionando a cada iterao; Tendncia Esperada: A velocidade pode ser afetada por

Edio 12 - Engenharia de Software Magazine

13

diversos fatores, como: mudana na equipe, impedimentos, conhecimento das ferramentas e tecnologias utilizadas, etc. Um time estabilizado, durante um mesmo projeto e com todos os recursos necessrios disponveis tende a aumentar sua velocidade durante um certo tempo (geralmente no incio), at atingir um patamar, onde ela se estabiliza; Quando utilizar? A velocidade uma mtrica de acompanhamento muito til para a equipe conhecer seu limite e sempre conseguir atingir o objetivo de cada iterao. A velocidade informa a equipe e o cliente da capacidade de entregar software funcionando num ritmo constante e sustentvel; Quando parar de utilizar? Quando o projeto acabar ou quando, aps atingido o perodo de estabilizao, a velocidade se tornar conhecida pela equipe e pelo cliente; Formas de Manipulao: Estimar mais pontos para o mesmo trabalho far com que a velocidade aumente, por isso ela no pode ser usada para comparar diferentes equipes. Enquanto uma equipe estima 1000 pontos, uma outra pode estimar 600 pontos para fazer o mesmo trabalho, tornando a comparao invivel; Cuidados e Observaes: Velocidade no representa valor agregado. Um time pode ter excelente velocidade, entregando software frequentemente durante um certo tempo, porm sem trazer o retorno (financeiro ou no) esperado. Comparar a velocidade de equipes diferentes tambm pode ser um problema (conforme discutido acima). Da mesma forma, medir a velocidade por membro da equipe tambm pode gerar conflitos e atrapalhar. Ela deve sempre ser medida no nvel da equipe.

Quando utilizar? Quando os membros da equipe estiverem demorando muito tempo para sincronizar ou integrar cdigo novo no repositrio ou quando as alteraes forem muito grandes; Quando parar de utilizar? Assim que o fator de integrao chegar em um nvel aceitvel e a equipe deixar de ter problemas de sincronizao de trabalho; Formas de Manipulao: Essa mtrica pode ser manipulada se os integrantes da equipe resolverem fazer um commit no repositrio a cada pequena alterao, aumentando muito a quantidade de commits. Isso deve ser desencorajado pois toda alterao no repositrio deve mant-lo num estado consistente, ou seja, os testes automatizados devem continuar passando; Cuidados e Observaes: Essa mtrica no leva em conta a qualidade do cdigo que est sendo integrado ao repositrio. Conforme discutido acima, um grande aumento no nmero de commits pode piorar a Integrao Contnua e deixar o repositrio num estado inconsistente. Manter a qualidade do cdigo atravs de uma bateria de testes automatizados deve ser uma preocupao constante da equipe.

Fator de Teste
Classificao: Quantitativa e objetiva; Pergunta: Qual a relao entre cdigo de teste e cdigo de produo que est sendo produzido pela equipe? Base de Medio: O fator de teste Ti para a iterao i calculado como a razo entre o nmero de linhas de cdigo de teste e o nmero de linhas de cdigo de produo:

Fator de Integrao
Classificao: Quantitativa e objetiva; Pergunta: Quanto tempo a equipe demora para integrar com o repositrio? Quanto cdigo alterado antes de ser integrado no repositrio? Base de Medio: O fator de integrao IFi para a iterao i calculado da seguinte maneira:

onde: TLCTi = nmero total de linhas de cdigo de teste na iterao i TLCi = nmero total de linhas de cdigo de produo na iterao i Suposies: A equipe est desenvolvendo cdigo de produo e cdigo de testes automatizados para verificar a Qualidade do software produzido; Tendncia Esperada: Se uma equipe utiliza tcnicas como TDD desde o incio do projeto, o fator de testes ser alto (em muitos casos inclusive com valor acima de 1). Para equipes onde os testes no so desenvolvidos junto com o cdigo de produo, o fator de testes ser provavelmente baixo e a tendncia de melhoria; Quando utilizar? Quando a equipe estiver preocupada com a Qualidade do software produzido, ou estiver monitorando a melhoria de prticas como o Desenvolvimento Dirigido por Testes, a Integrao Contnua, o Design Incremental ou a Refatorao; Quando parar de utilizar? importante que a equipe tenha conhecimento da Qualidade do software produzido. Caso decidam parar de utilizar o Fator de Teste, importante substitu-lo por outra mtrica para avaliar a Qualidade e mant-la alta; Formas de Manipulao: Essa mtrica pode ser manipulada

onde: LAi = nmero total de linhas adicionadas na iterao i LRi = nmero total de linhas removidas na iterao i LUi = nmero total de linhas atualizadas na iterao i TCi = nmero total de commits na iterao i Suposies: A equipe utiliza um sistema de controle de verso, onde o cdigo integrado frequentemente pelos integrantes da equipe; Tendncia Esperada: Se a equipe est praticando a Integrao Contnua de forma correta, o fator de integrao deve ser baixo, indicando que h poucas linhas alteradas a cada commit. Dessa forma, a tendncia esperada para uma equipe que est aprendendo a Integrao Contnua de diminuio;

14

Engenharia de Software Magazine - Mtricas de Acompanhamento para Metodologias geis

METODOLOGIA S G EIS

atravs da produo de muito cdigo de teste que no verifica o comportamento esperado do sistema (testes sem assert, por exemplo). Da mesma forma, medir linhas de cdigo sempre pode gerar um incentivo para tornar o cdigo menos legvel, evitando quebras de linha que afetariam essa mtrica; Cuidados e Observaes: Um fator de teste maior que 1 no representa necessariamente o cenrio ideal, assim como no garante que o cdigo est totalmente testado ou com boa Qualidade. Apesar de influenciar a Qualidade do software produzido, essa mtrica no serve como medida objetiva de qualidade.

Referncias 1. Eliyahu M. Goldratt. The Haystack Syndrome: Sifting Information Out of the Data Ocean. North River Press, 1991. 2.Ron Jeffries,Ann Anderson,and Chet Hendrickson.Extreme Programming Installed.AddisonWesley Professional, 2000. 3. Ken Auer and Roy Miller. Extreme Programming Applied: Playing to Win. Addison-Wesley Professional, 2001. 4. Alistair Cockburn. Agile Software Development: The Cooperative Game. Addison-Wesley Professional, 2nd edition, 2006. 5. IEEE standard glossary of software engineering terminology, 1983. IEEE Std 729. 6.John McGarry,David Card,Cheryl Jones,Beth Layman,Elizabeth Clark,Joseph Dean,and Fred Hall. Practical Software Measurement: Objective Information for Decision Makers. AddisonWesley Professional, 2002. 7. IEEE standard glossary of software engineering terminology, 1990. IEEE Std 610.12. 8. Jane F. Gilgun. Definitions, methodologies, and methods in qualitative family research. Qualitative Methods in Family Research, 1992. 9. Carolyn B. Seaman. Qualitative methods in empirical studies of software engineering. IEEE Transactions on Software Engineering, 25(4):557572, 1999. 10. Deborah Hartmann and Robin Dymond. Appropriate agile measurements: Using metrics and diagnostics to deliver business value. In Agile 2006 Conference, pages 126131, 2006. 11. Jim Collins. Good to Great:Why Some Companies Make the Leap... and Others Dont. Collins, 2001. 12.Mary Poppendieck and Tom Poppendieck.Lean Software Development:An Agile Toolkit for Software Development Managers. Addison-Wesley Professional, 2003. 13.Vitor R.Basili,Gianluigi Caldiera,and H.Dieter Rombach.The goal question metric approach. Encyclopedia of Software Engineering, pages 528532, 1996. 14. Robert D. Austin. Measuring and Managing Performance in Organizations. Dorset House Publishing Company, Inc., 1996. 15. Mary Poppendieck and Tom Poppendieck. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley Professional, 2006. 16.W. Edwards Deming. Out of The Crisis. Massachusetts Institute of Technology, 1986. 17.Yael Dubinsky, David Talby, Orit Hazzan, and Arie Keren.Agile metrics at the israeli air force. In Agile 2005 Conference, pages 1219, 2005. 18. Kent Beck and Martin Fowler. Planning Extreme Programming. Addison-Wesley Professional, 2000. 19.Thomas J.McCabe and Arthur H.Watson.Software complexity.Crosstalk:Journal of Defense Software Engineering, 7:59, 1994. 20. Arthur H.Watson and Thomas J. McCabe. Structured testing: A testing methodology using the cyclomatic complexity metric.Technical report, NIST Special Publication 500-235, 1996. 54 21. Shyam R. Chidamber and Chris F. Kemerer. A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 20(6):476493, 1994. 22.Brian Henderson-Sellers.Object-Oriented Metrics: Measures of Complexity.Prentice Hall PTR, 1996. 23. Barry W. Boehm and Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional, 2003. 24. Ron Jeffries. A metric leading to agility. Disponvel em: www.xprogramming.com/xpmag/ jatRtsMetric.htm, 2004. Acessado em: 31/05/2007. 25. Kent Beck and Cynthia Andres. Extreme Programming Explained : Embrace Change. Addison-Wesley Professional, 2nd edition, 2004. 26.Fred Reichheld.The Ultimate Question:Driving Good Profits andTrue Growth.Harvard Business School Press, 2006. 27. Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall, 2001.
sobre e s

Consideraes Finais
Neste artigo discutiu-se o papel das mtricas nos Mtodos geis de desenvolvimento de software. Foram apresentadas as definies de medidas, mtricas e indicadores, assim como a forma que estes conceitos se relacionam na anlise, contextualizao e interpretao de uma mtrica. Diferentes formas de classificao foram discutidas, diferenciando mtricas de natureza objetiva/subjetiva, quantitativa/qualitativa e organizacional/acompanhamento. Essa ltima classificao tem papel particularmente importante neste artigo, separando as mtricas de acordo com diferentes objetivos. Enquanto uma mtrica organizacional avalia o desempenho geral, medindo a quantidade de valor de negcio entregue ao cliente, uma mtrica de acompanhamento tem natureza simplesmente informativa, provendo informaes locais que ajudam a equipe no entendimento e melhoria do processo que produz valor de negcio. Tais definies, conceitos e formas de classificao ajudam a formar uma base para discusso do papel das mtricas nos Mtodos geis. Alm disso, discutiu-se tambm trs diferentes abordagens para definio e escolha de uma mtrica. A combinao da abordagem GQM que esclarece o objetivo por trs de cada medio com a abordagem Lean que estimula um menor nmero de mtricas organizacionais e promove a medio em um nvel acima fornece uma boa base para escolha das mtricas organizacionais. Por outro lado, uma terceira abordagem auxilia a equipe a refletir e discutir os pontos do processo que podem ser melhorados, servindo como base para escolha das mtricas de acompanhamento. Por fim, foram apresentadas as caractersticas de uma boa mtrica gil, juntamente com uma lista de verificao que pode ser usada pelo tracker ao avaliar a possibilidade de utilizao de uma mtrica. Seguindo os tpicos propostos nessa lista de verificao, diversos exemplos de medidas, mtricas organizacionais e mtricas de acompanhamento foram apresentados, concluindo este artigo.

D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
D s

Feedback eu

edio ta

Edio 12 - Engenharia de Software Magazine

15