Artigo Engenharia de Software 12 - Métricas de Acompanhamento para Metodologias Ágeis

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo da Revista Engenharia de Software edição 12.

Esse artigo faz parte da revista Engenharia de Software 12 edição especial. Clique aqui para ler todos os artigos desta edição

Metodologias Ágeis

Métricas de Acompanhamento para Metodologias Ágeis

 

De que se trata o artigo: Este artigo apresenta os conceitos relacionados às métricas para auxiliar o tracker de uma equipe ágil, discutindo definições, classificações, diferentes abordagens para escolha das melhores métricas e, por fim, apresentando alguns exemplos que podem ser utilizados no acompanhamento de uma equipe ágil.

Para que serve: Métricas é um tema muito discutido em toda a comunidade de engenharia de software. Sua importância está no fato de que possibilita um acompanhamento mais preciso das atividades do projeto. Em particular, métricas podem ser uma ótima ferramenta no apoio ao controle de projetos de desenvolvimento de software utilizando metodologias ágeis.

Em que situação o tema é útil: Apoiar o responsáveis pelo projeto na definição de abordagens mais precisas de acompanhamento de forma a possibilitar a melhoria dos trabalhos na organização.

 

Os Métodos Ágeis promovem um processo empírico para o desenvolvimento de software. Essa abordagem exige um ciclo constante de inspeção, adaptação e melhoria. Encontrar maneiras eficazes de avaliar o processo e a equipe de desenvolvimento não é uma tarefa simples. Isso leva a uma proliferação de medidas baseadas na premissa de que se cada parte do processo for otimizada, os resultados do processo como um todo serão otimizados também. No entanto, essa premissa nem sempre é verdadeira. Ao tentar micro-otimizar partes de um sistema por meio de diversas métricas, o verdadeiro objetivo se perde em meio a tantos substitutos e a equipe perde sua capacidade de tomar decisões de balanceamento (trade-off) [15]. Além disso, a preocupação com as medidas erradas pode gerar incentivos errados, levando a consequências indesejáveis. Goldratt diz que as pessoas se comportam de acordo com a forma com que estão sendo medidas: “Diga-me como serei avaliado e eu lhe direi como me comportarei” [1].

A escolha das melhores formas de medição é uma tarefa do Time Completo e o tracker possui um papel especial. Jeffries [2] e Auer [3] descrevem o papel do tracker como alguém responsável por prover informações para a equipe sobre o progresso do time, utilizando as métricas apropriadas para destacar os pontos de melhoria e atualizando regularmente essas informações nos gráficos e pôsteres na área de Trabalho Informativa, que Cockburn chama de radiadores de informação [4].

Este artigo apresenta os conceitos relacionados às métricas para auxiliar o tracker de uma equipe ágil, discutindo definições, classificações, diferentes abordagens para escolha das melhores métricas e, por fim, apresentando alguns exemplos que podem ser utilizados no acompanhamento de uma equipe ágil.

Definições

Para discutir o papel das métricas no acompanhamento de projetos ágeis, primeiro é preciso definir alguns conceitos que nem sempre são usados da forma correta, com uma troca frequente de significados. Em particular, é importante conhecer as diferenças sutis entre os conceitos de medidas, métricas e indicadores.

Segundo o IEEE, uma medida é uma avaliação em relação a um padrão [5]; McGarry diz que é a avaliação de um atributo segundo um método de medição específico, funcionalmente independente de todas as outras medidas e capturando informação sobre um único atributo [6]. Um exemplo de medida é 5 cm: centímetro é o padrão e 5 é a medida, que indica quantos múltiplos ou frações do padrão estão sendo representados. Em desenvolvimento de software, um exemplo de medida pode ser o número de linhas de código. No entanto, não existe um padrão universal para representar linhas de código, pois as linguagens podem variar, assim como as regras para cálculo de linhas de código. Portanto, uma medida pode ser baseada em um padrão local ou universal, mas o padrão precisa ser bem definido. Uma métrica é um método 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 métrica é o número de defeitos encontrados após a implantação: as medidas que compõem essa métrica são o número de defeitos e a fase (ou data) onde o defeito foi identificado.

Um indicador é um dispositivo ou variável que pode ser configurado para um determinado estado com base no resultado de um processo ou ocorrência de uma determinada condição. Por exemplo: um semáforo ou uma flag [7]. Conforme a definição do IEEE, um indicador é algo que chama a atenção para uma situação particular. Ele geralmente está relacionado a uma métrica e provê a interpretação daquela métrica numa determinada situação ou contexto. Sempre que alguém interpreta alguma métrica, está considerando algum tipo de indicador, seja ele algum valor base ou outra métrica. Por exemplo: um aumento substancial no número de defeitos encontrados na última versão pode ser um indicador de que a Qualidade do software piorou. O seguinte exemplo fictício demonstra a relação entre medidas, métricas e indicadores: ao término da primeira iteração de um projeto, constata-se que a equipe entregou 4 Histórias, somando um total de 20 pontos (Figura 1 (a)). Conforme a equipe vai terminando as próximas iterações, percebe-se que o número total de pontos entregues aumenta aos poucos. Após certo tempo, essa tendência de subida é interrompida e o número total de pontos entregues cai um pouco, atingindo um patamar (Figura 1 (b)).

 

Figura 1. Total de Pontos Entregues por Iteração

 

A Figura 1 (a) representa uma medida. Sem nenhuma outra informação para comparar ou uma tendência para seguir, uma medida não provê muita informação. A Figura 1 (b) representa uma métrica, nesse caso a velocidade da equipe. Uma métrica é composta por diversas medidas como o número de pontos entregues e o número da iteração terminada. Assim que a métrica 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 métrica, servindo como base para comparação. Uma métrica é sempre interpretada sob um ponto de vista específico. Por isso, é possível derivar diversos indicadores a partir da mesma métrica. O significado de um indicador sempre depende de um contexto, portanto duas equipes podem analisar a mesma métrica de forma diferente. Supondo outro cenário, onde essa mesma equipe utilizasse como indicador um valor base inferior para sua velocidade (derivado de outros projetos, por exemplo). Nesse caso, a mesma métrica Figura 1 (b) poderia ser interpretada como uma melhoria. No caso anterior, a equipe não tinha nenhum indicador prévio e houve apenas uma estabilização para que esse valor base fosse descoberto.

A palavra métrica será utilizada neste texto daqui em diante. No entanto, sempre que uma métrica for interpretada, avaliada ou analisada, o conceito de um indicador estará sempre implícito. Da mesma forma, toda métrica depende de medidas, portanto elas também estão sendo consideradas.

Classificações

As métricas podem ser classificadas segundo diferentes critérios. Esta seção apresenta algumas das possíveis classificações que um tracker precisa considerar quando utilizar uma métrica.

 

Objetiva/Subjetiva

Conforme discutido anteriormente, uma métrica é composta por medidas que avaliam atributos de um objeto. O valor de uma métrica objetiva depende somente do objeto em questão e não do ponto de vista de quem a está interpretando. Por exemplo: número de commits no repositório é uma métrica objetiva, pois é obtida diretamente da ferramenta. Por outro lado, o valor de uma métrica subjetiva depende do objeto em questão e também do ponto de vista de quem a está interpretando. Um exemplo de métrica subjetiva é a qualidade do código, numa escala de 0% a 100%. Apesar da escala definir um intervalo numérico, a natureza da métrica ainda é subjetiva, pois depende do ponto de vista de quem está avaliando.

Os critérios para definir a “qualidade do código” variam de pessoa para pessoa. Métricas objetivas são passíveis de serem obtidas de forma automatizada.

 

Quantitativa/Qualitativa

Além da natureza objetiva/subjetiva, uma métrica pode ainda ser classificada como quantitativa ou qualitativa. O valor de uma métrica quantitativa pertence a um intervalo de uma certa magnitude e geralmente é representado por um número. Tal estrutura permite que medidas quantitativas sejam comparadas entre si. A maioria dos exemplos utilizados até aqui neste artigo representam métricas quantitativas, como o número de linhas de código ou o número de defeitos encontrados. Por outro lado, valores de uma métrica qualitativa são aqueles representados por palavras, símbolos ou figuras ao invés de números [8]. Um exemplo de métrica qualitativa é o humor da equipe ou a satisfação do cliente.

A maioria dos estudos empíricos em Engenharia de Software usa uma combinação entre métodos quantitativos e qualitativos. Uma das formas mais comuns de combinar ambas as estratégias é a codificação, que consiste na extração de valores quantitativos dos dados qualitativos para permitir o tratamento estatístico ou outra abordagem quantitativa [9].

Vale ressaltar que a classificação de uma métrica como quantitativa ou qualitativa é ortogonal à classificação como objetiva ou subjetiva. Geralmente uma métrica quantitativa é objetiva e uma qualitativa é subjetiva, mas isso não é sempre verdade. O processo de codificação transforma uma métrica qualitativa em quantitativa, mas não altera sua objetividade ou subjetividade. Por exemplo, considere a seguinte frase que constitui um fragmento de dado qualitativo: “João, Maria e Pedro foram os únicos que participaram da reunião”. Isso poderia ser transformado num dado quantitativo como: “numero de participantes = 3”. A informação continua objetiva após a codificação. Além disso, uma parte da informação é perdida, pois não 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 informação poderia ser codificada para o seguinte dado quantitativo: “complexidade = baixa”. Houve novamente perda de informação no processo de codificação e, apesar do valor quantitativo parecer mais objetivo, continua tão subjetivo quanto antes.

 

Organizacional/Acompanhamento

Hartmann e Dymond sugerem outra categoria para classificação, distinguindo métricas organizacionais de métricas de diagnóstico [10]. Neste texto, ao invés de usar o termo “diagnóstico” usarei o termo “acompanhamento” por estar mais alinhado com o tema do artigo e por compartilhar as mesmas características de “diagnóstico” propostas por Hartmann e Dymond. Métricas organizacionais são aquelas que medem a quantidade de valor de negócio entregue ao cliente. Essa definição levanta algumas perguntas: em primeiro lugar, quem é o cliente? Collins sugere que, no nível organizacional, o cliente deve ser o dono ou o responsável pelo produto (stakeholder) ou talvez o usuário 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 histórico de resultados medíocres para um longo histórico de resultados extraordinários. Ele mostra que as empresas que foram do bom para o ótimo escolheram um fator-chave único de direcionamento econômico como métrica para auxiliar na tomada de decisão. Idealmente, essa métrica-chave deve ser definida pelos executivos da empresa, porém em projetos de código aberto, onde o objetivo final nem sempre é financeiro, outros fatores de sucesso como número de usuários ou a satisfação do usuário podem ser utilizados. A seção Métricas Organizacionais apresentará com mais detalhes alguns exemplos de métricas organizacionais.

Métricas de acompanhamento provêem informações que ajudam o time no entendimento e Melhoria do processo que produz valor de negócio. Uma vez que uma métrica organizacional ampla é definida, a equipe precisa de medições locais para auxiliá-los a atingir o objetivo. Essas métricas agregam dados, porém não os associam a nenhum indivíduo. Elas existem e têm validade dentro de um contexto particular, porém recomenda-se que elas sejam escolhidas com cuidado e utilizadas somente durante certo período de tempo. Métricas de acompanhamento devem ser descartadas uma vez que tenham servido seu propósito. A meta mais ampla definida pela métrica organizacional deve guiar a utilização de diferentes métricas de acompanhamento temporárias. Um exemplo de métrica de acompanhamento já citado neste artigo é a velocidade da equipe.

Poppendieck utiliza uma nomenclatura diferente para as métricas organizacionais e de acompanhamento, chamando-as de métricas de avaliação de desempenho e métricas informativas, respectivamente [12]. Apesar dos nomes serem diferentes, as características descritas nesta seção são as mesmas.

O Que Medir?

Nesta seção são apresentadas algumas abordagens para escolher quais métricas utilizar, apresentando também algumas das características de uma boa métrica ágil. Um tracker deve utilizar as abordagens apresentadas aqui juntamente com o conhecimento sobre sua equipe ao escolher as melhores métricas para sua situação.

 

Abordagem Objetivo-Pergunta-Métrica (Goal Question Metric)

Uma das abordagens mais conhecidas e utilizadas em estudos empíricos em Engenharia de Software é a abordagem objetivo-pergunta-métrica (Goal Question Metric ou GQM), proposta por Basili [13]. O modelo de medição proposto pelo GQM é composto de três níveis:

·         Nível Conceitual (Objetivo): Um objetivo é definido para um objeto em relação a algum modelo de qualidade, a partir de diversos pontos de vista e para um ambiente específico. Um objeto pode ser um produto (documento, código-fonte, testes, etc.), um processo (especificação, entrevista, codificação, etc.) ou um recurso (pessoas, hardware, espaço físico, etc.);

·         Nível Operacional (Pergunta)"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?