Artigo que fala um pouco sobre gestão de softwares em equipes ágeis com utilização de métricas e indicadores como ferramenta de apoio e de tomada de decisão. Desenvolvido sobre um micro-processo simples de desenvolvimento de software.

1. DESENVOLVIMENTO DE UM MICROPROCESSO UTILIZANDO
MÉTRICAS E INDICADORES COMO AUXÍLIO A GERÊNCIA DE
PROJETOS ÁGEIS
Maicon Zerbielli1
Gustavo Bisognin2
Resumo
O constante crescimento da área de gestão da informação através de sistemas
computadorizados tem como consequência para as empresas de desenvolvimentos de
software uma exigência cada vez maior, entre essas exigências se destacam a qualidade do
produto e a agilidade na entrega. Esse artigo demonstra a partir da teoria do
desenvolvimento ágil de software e da gestão de projetos, extraídas a partir de pesquisa
bibliográfica, a grande importância da utilização de métricas e indicadores para auxiliar o
gerente de projetos na tomada de decisão, tendo como base informações coletadas por
gráfico, além de proporcionar uma visão abrangente do produto, da equipe, dos recursos e
capacidade de produção.
1 INTRODUÇÃO
A utilização de métricas e indicadores no âmbito do desenvolvimento de software não
é uma tarefa simples, Koscianski (2007) argumenta que entre as dificuldades de se medir
software pode-se citar duas: “a variedade de aspectos a considerar e a presença de muitos
elementos intangíveis”.
Em desenvolvimento de software ágil as métricas e indicadores se resumem na
maioria dos casos em um gráfico burndown. Para um gerente de projetos não é suficiente, é
preciso saber qual a saúde do seu produto, da sua equipe, onde exige maior investimento.
Com a utilização de boas métricas fornecendo números, o gerente de projetos passa a
trabalhar com fatos e não com adivinhações. Em um ambiente de desenvolvimento ágil de
software o gerente necessita de informações não apenas do produto mas também da equipe
que esta desenvolvendo o produto, pois nesse tipo de ambiente a agilidade e a qualidade no
desenvolvimento fazem toda a diferença, as métricas e indicadores podem então exercer um
papel muito importante.
Através da pesquisa realizada, esse artigo tem a intenção de exemplificar e explicar o
quão importante é o papel das métricas e dos indicadores como ferramenta de auxílio a
tomadas de decisões na gerencia de projetos em ambiente de desenvolvimento ágil.
Com base nos estudos realizados através da pesquisa bibliográfica, implementa-se um
micro processo de gerenciamento de projetos. Este micro processo é implementado em três
fases, iniciação, elaboração e validação. O micro processo é desenvolvido de maneira simples
buscando oferecer o máximo de clareza em seu objetivo.
Os resultados obtidos durante a execução do micro processo comprovam a
importância das métricas e indicadores durante o processo de desenvolvimento de software.
1 Bacharel em Sistemas de Informação. E-mail: zerbielli.maicon@gmail.com
2 Mestre em Computação Aplicada. E-mail: gbisog@gmail.com

2. 2
2 FUNDAMENTAÇÃO TEÓRICA
2.1 DESENVOLVIMENTO ÁGIL DE SOFTWARE
Em um modelo clássico de desenvolvimento do software, falando mais
especificamente do Modelo em Cascata, tendo como exemplo por ser o primeiro modelo de
processo de desenvolvimento de software publicado, cada fase do processo é encadeada com
outra fase, o resultado de cada fase deve ser devidamente documentado e aprovado para então
poder passar para a fase seguinte do processo, uma vez definido os requisitos no inicio do
processo, torna-se difícil reagir a mudanças exigidas pelos clientes. (SOMMERVILLE, 2007)
Com o constante crescimento/necessidade da tecnologia da informação juntamente
com a pressão por inovação, mudança de requisitos e prazos cada vez mais apertados, a
comunidade de desenvolvimento de software percebeu a necessidade de criar uma alternativa
para esses modelos pesados e inflexíveis, em meados de 1990 começou a surgir novos
frameworks, inicialmente conhecidos como “métodos leves”. (SBROCCO; MACEDO, 2012)
Em fevereiro de 2001 um grupo de dezessete profissionais de diversas linhas de
pensamentos sobre métodos de desenvolvimento do software, se reuniu em uma cúpula e
discutiram sobre melhorar a maneira de desenvolver software. A partir do encontro foi
redigido um documento contendo um conjunto de doze princípios nos quais foram definidos
quatro valores:
1. Indivíduos e interações mais que processos e ferramentas.
2. Software funcionando mais que documentação abrangente.
3. Colaboração com o cliente mais que negociação de contratos.
4. Respondendo a mudanças mais que seguir um plano. (AGILE ALLIANCE, 2014)
Esse documento assinado por todos os presentes no encontro foi então publicado e
nomeado “Manifesto Ágil”.
Nas metodologias tradicionais de desenvolvimento de software, o objetivo dos
métodos adotados é orientado a processos, ou seja, as pessoas devem se adaptar ao processo,
já nos métodos ágeis os objetivos é o oposto, nenhum processo pode ser equivalente à
habilidade dos integrantes da equipe, o processo é quem se adapta as pessoas. (SBROCCO;
MACEDO, 2012)
Agilidade é tornar a comunicação mais fácil dentro da equipe, proporcionar uma
rápida entrega de software, tornar o cliente como parte da equipe de desenvolvimento e
flexibilizar o plano de projeto. Em uma equipe ágil de desenvolvimento de software deve
estar em evidencia algumas características nas pessoas e na equipe em um todo, como cita
(PRESSMAN 2006).
• Competência. O membro da equipe deve ter talento inato, conhecimento específico do
software e do processo como um todo.
• Foco comum. O ideal é que os membros da equipe estejam focados em um objetivo
em comum, entregar um incremento de software no prazo estimado,
• Colaboração. Os membros da equipe precisam colaborar entre si, com o cliente e
também com os gerentes do projeto.

3. 3
• Capacidade de tomada de decisão. A equipe deve ter autonomia, liberdade para
tomada de decisão.
• Habilidade de resolver problemas vagos. A equipe será continuamente exposta a
modificações, as lições aprendidas na solução ou não de um problema podem ser benéficas
em outra ocasião.
• Respeito e confiança mútua. O respeito e a confiança devem estar entre os membros
da equipe.
• Auto-organização. A equipe deve ser auto organizada para melhorar e facilitar a
entrega do incremento de software, ou seja, deve ser capaz de definir as suas tarefas
diárias, organiza o cronograma de trabalho e organiza o processo para se adaptar ao seu
ambiente de trabalho.
Nesse conceito destacaram-se alguns modelos ágeis de processos para se desenvolver
software, todos satisfazem os princípios do Manifesto Ágil, mencionados anteriormente.
• Extreme Programming – XP;
• Desenvolvimento Adaptativo de Software – DAS (Adaptative Software Development -
ASD);
• Método de Desenvolvimento Dinâmico de Sistemas (Dynamic Systems Development
Method - DSDM);
• Scrum;
• Crystal;
• Desenvolvimento Guiado por Características (Feature Driven Development - FDD);
• Modelagem Ágil (Agile Modeling – AM)
Com base nos conceitos abordados anteriormente, se contextualiza a utilização de
modelos ágeis como apoio a gestão de projetos de software.
2.2 GESTÃO DE PROJETOS DE SOFTWARE
Gestão de projetos é um tema relativamente novo, porém é uma atividade exercida
desde os primórdios da humanidade em construções como as Pirâmides Egípcias, Muralha da
China, a construção de uma bomba atómica que ficou conhecido como Projeto Manhattan,
entre inúmeras outras. (VIEIRA, 2003)
“O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas
e técnicas às atividades de projetos a fim de atender aos seus requisitos”. (PMBOK, 2004)
“Os objetivos do gerenciamento de projetos é garantir o cumprimento do escopo, dos
prazos dos custos e da entrega dos produtos com a qualidade esperada pelo cliente”. (
VIEIRA, 2003)
Na área de informática, mais precisamente na construção de softwares, a gerência de
projetos de certa forma é muito importante, pois é um empreendimento complexo onde
envolve muitas pessoas trabalhando juntas durante um período relativamente longo.
(PRESSMAN 2006)
Na concepção do Guia PMBOK (2004), gerir um projeto inclui:
• Identificação da necessidade.
• Estabelecimento de objetivos claros e alcançáveis.
• Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo.
• Adaptação das especificações, dos planos e da abordagem as diferentes preocupações
e expectativas das diversas partes interessadas.

4. 4
Ainda para Pressman (2006), a gestão efetiva de projetos de software é focalizada em
quatro ‘Ps’, pessoas, produto, processo e projeto.
2.2.1 Pessoas
As pessoas são o maior património da organização, representam o capital intelectual, é
de inteira responsabilidade do gerente de software garantir que se obtenha o maior retorno
sobre o investimento aplicado nas pessoas, para isso o gerente de software precisa mantê-las
motivadas, engajadas e dispostas a aplicar seu talento no desenvolvimento do projeto.
Complementando com Sommerville (2007), se as pessoas não estiverem motivadas, “Elas
trabalharão lentamente, serão mais propensas a cometer erros e não contribuirão para as metas
mais amplas da equipe ou da organização”.
2.2.2 Produto
Definir objetivos, escopo, soluções alternativas, restrições técnicas e gerências devem
ser identificados antes de se iniciar o planejamento de um projeto, só assim é possível definir
estimativas de custo, avaliações de riscos e um cronograma gerenciavel do projeto para então
ter uma indicação de progresso.
2.2.3 Processo
”Quando você elabora um produto ou sistema é importante percorrer uma série de
passos previsíveis, um roteiro que o ajuda a criar a tempo um resultado de alta qualidade. O
roteiro que você segue é chamado de processo do software.”
Não existe um processo ideal, os processos evoluem para melhor explorar as
capacidades das pessoas envolvidas. (SOMMERVILLE, 2007)
2.2.4 Projeto
“Um projeto é um esforço temporário empreendido para criar um produto, serviço ou
resultado exclusivo.” (PMBOK, 2004)
Um bom gerenciamento pode não garantir sucesso de um projeto, no entanto um mau
gerenciamento acaba resultando em falha do projeto, como atrasos, alto custo e requisitos não
atendidos. Para garantir um bom gerenciamento do projeto é importante ficar atendo as
necessidades do cliente, ao escopo do produto, as modificações, aos prazos e as pessoas da
equipe. Depende também de um bom planejamento. (SOMMERVILLE, 2007)
Uma das características importantes dos modelos abordados é a forma de medição, na
qual implementa métricas e indicadores que poderão ser utilizados como base para o sucesso
do projeto.

5. 5
2.3 MÉTRICAS E INDICADORES
Assim como em qualquer Engenharia, a Engenharia de Software necessita de
medições que promovem uma visão abrangente da situação do projeto. Para entender melhor,
a Ilustração 1 demonstra o que cada elemento do gráfico representa. Logo é possível observar
que um elemento complementa o outro, a medida sozinha não promove informação alguma,
ao aplicar uma métrica já é possível obter uma grande quantidade de informação, com a
definição de um indicador é possível então definir a saúde do que se esta medindo.
Ilustração 1 – Medida, Métrica e Indicador
Fonte: SATO
As métricas fornecem uma parte importante de dados para a administração de um
projeto de software, através das métricas são extraídos os indicadores que dão ao gerente de
projeto as informações necessárias para a tomada de decisão. Para Martins (2007) podem ser
considerados dois tipos de indicadores na gerência de projetos de software, podem ser
indicadores de processo, também conhecido como indicadores de controle, quando incidem
diretamente no processo, alguns exemplos desse tipo de indicadores podem ser: quantidade de
erros detectados antes da entrega do produto, erros que chegaram ao cliente, esforço humano,
tempo, entre outros. O outro tipo de indicador é denominado, indicadores de projeto, esses
incidem diretamente no projeto (produto), esse tipo de indicador permite avaliar o
desempenho do software, a situação dos riscos, fluxo de trabalho, capacidade da equipe, entre
outros.
Para obter indicadores coerentes e confiáveis é necessário obter dados durante o
processo de desenvolvimento do projeto, para Pressman (2002) o ideal seria que esses dados
fossem coletados de modo progressivo para evitar uma investigação histórica de projetos.
Para Koscianski (2007), os dados históricos são essências para uma administração
precisa de projetos. “As informações coletadas por meio de métricas, tanto de projetos
anteriores quando de projetos em andamento, contribuem para que se exerça controle sobre os
trabalhos sendo realizados”. Conforme informações coletadas em um projeto anterior, como
duração e dimensões do projeto, o gerente pode fazer uma previsão mais concreta, permitindo
estabelecer cronogramas mais realísticos.
2.3.1 Qualidade das métricas
De nada adianta ter uma base histórica rica se as informações contidas nessa base não
são confiáveis, o trabalho de avaliação estaria em risco, uma vez que se o resultado obtido de

6. 6
uma medida servirá para julgar um software, esse resultado deverá ser confiável ou o software
será julgado incorretamente. No entanto existem métricas onde fica mais difícil estabelecer
uma informação confiável, como as que dependem de fatores externos, como habilidades do
usuário. (KOSCIANASKI, 2007)
Koscianski (2007) comenta que, é muito importante ao escolher métricas na gerencia
de projetos de software, estar atento a algumas características, como:
• As métricas devem ter significância. O resultado obtido deve ser util.
• As métricas devem ter custos e complexidades de aplicação compatíveis com a
avaliação a ser realizada.
• As métricas devem ser repetíveis.
• As métricas devem ser reproduzíveis.
• As métricas devem ser objetivas.
• As métricas devem ser imparciais.
• As métricas devem prover evidencias para sua validação.
No capitulo a seguir é apresentado e exemplificado alguns gráficos que podem ser
utilizados em um modelo de desenvolvimento ágil.
2.3.2 Exemplos de métricas para desenvolvimento ágil
No gerenciamento de softwares é muito importante a utilização de métricas e
indicadores, pois fornecem informações que permitem identificar a saúde o projeto, se a
equipe está trabalhando de forma ágil, produtiva, com qualidade, isso é possível através de
números fornecidos pelas métricas. Entretanto é muito importante saber identificar métricas
boas e descartar as métricas ruins, em um modelo de desenvolvimento ágil, é importante
seguir os princípios do Manifesto Ágil, descritos no capitulo 2.1, onde enfatiza resultados, e
valores para o cliente. É importante medir apenas o necessário.
Quando se fala em métricas em um conceito de desenvolvimento ágil, logo vem em
mente o famoso gráfico burndown. O burndown é um gráfico muito utilizado em
metodologias de desenvolvimento ágil, principalmente no SCRUM. Podemos observar na
Ilustração 1 um exemplo de gráfico burndown.

7. 7
Ilustração 2 - Gráfico Burndown
Fonte: HAZRATI
O gráficos burndown apresentado na Ilustração 2 indica sobre uma equipe de
desenvolvimento ágil, o trabalho exercido (eixo vertical) versus o tempo estimado (eixo
horizontal). Uma vez que o trabalho exercido é apresentado por uma unidade de medida que
pode ser horas, dias, semanas ou sprint. No eixo horizontal que apresenta o tempo, que pode
ser apresentado através de horas de trabalho ou pontos. As unidades são escolhidas conforme
realidade do projeto ou da equipe.
O burndown revela ao gerente de projetos, dados muito importantes sobre a equipe
como o andamento do projeto ou sprint, o quão bem está sendo planejado, o que poderia
melhorar para próxima sprint e o quanto a equipe é organizada.
No gráfico apresentado na ilustração dois, a linha na cor preta, indica o que foi
planejado, ou seja, a linha ideal. Essa linha é o chamado indicador, ele representa o valor de
referencia da métrica, indicando positivo ou negativo, sem o indicador não seria possível
identificar que a linha de cor roxa, linha dois, representa alguma deficiência, pois ela iniciou e
terminou no prazo planejado, porem teve grandes variações durante a sprint, com o indicador
fica evidente a deficiência.
Na linha de cor azul, linha um, não atinge o final da linha ideal, indicando que a sprint
foi mal planejada ou ouve fatores que influenciaram no não cumprimento do planejado, como
alterações de requisitos, inclusão de mais atividades no sprint ou até mesmo pode indicar que
a equipe não está unida e incapaz de se auto organizar.
Na linha de cor roxa, linha dois, evidencia que, mesmo atingindo a meta, durante a
sprint esteve bem longe do indicador, indicando que faltou uma atualização constante do
gráfico ou pode ter sido removido atividades durante a sprint.
Na linha de cor verde, linha três, indica que a equipe é auto organizada e que o
planejamento e execução das tarefas seguiram um padrão desde o inicio da sprint até sua
conclusão.
Outra métrica bem conceituada em metodologias de desenvolvimento ágil é o
Cumulative Flow. Um gráfico muito simples que demonstra a quantidade de serviços (tarefas)
acumuladas em diversas fazes, pode-se observar na Ilustração 3 um exemplo de Cumulative
Flow.

8. 8
Ilustração 3 - Cumulative Flow
Fonte: PEARSON
No gráfico apresentado na Ilustração 3, pode-se observar, no eixo Y (vertical), tem-se
a quantidade de serviço ou tarefas, já no eixo X (horizontal) tem-se a quantidade de dias.
A parte em cor azul (not done) é representada pela quantidade de tarefas novas
adicionadas ao backlog.
A parte de cor verde (ready) representa a quantidade de tarefas prontas para serem
desenvolvidas, ou seja, os requisitos já foram definidos, os prazos estabelecidos e aguardam
seu desenvolvimento.
A parte em amarelo (in dev) representa a quantidade de tarefas sendo desenvolvidas.
Na parte em vermelho (in test), como a descrição já se explica, representa a
quantidade de tarefas sendo testadas.
Por ultimo, e não menos importante, tem-se a parte em cor bege (done) representa a
quantidade de tarefas concluídas.
Com o gráfico é possível entender o tamanho do produto, o aumento do backlog, é
possível identificar gargalos no processo como, por exemplo, se no gráfico a parte em
amarelo estivesse com partes maiores do que o padrão indica que existe algum problema com
o desenvolvimento, e as tarefas não estão sendo finalizadas.
Outra métrica muito interessante pode ser observada na Ilustração 4, onde é
demonstrada a velocidade da equipe.

9. 9
Ilustração 4 – Tarefas entregas/Velocidade da equipe
Fonte: Elaborada pelo autor
O gráfico tem como medidas a quantidade de tarefas versus sprint, por exemplo, na
sprint um foram entregues e aceitas pelo cliente 20 tarefas. Com o decorrer das sprints é
possível observar a aceleração e desaceleração do gráfico, indicando o quanto a equipe está
empenhada e ágil.
Utilizando a mesma métrica e aplicando a quantidade de tarefas planejadas em cada
sprint tem-se o gráfico apresentado na Ilustração 5.
Ilustração 5 – Tarefas entregas/Tarefas planejadas
Fonte: Elaborada pelo autor
Com esse gráfico pode-se observar a capacidade da equipe em transformar tarefas e
produto para o cliente.
No gráfico a linha azul representa a quantidade de tarefas entregues ao cliente em cada
sprint, já a linha verde representa a quantidade de tarefas planejadas para a sprint, por

10. 10
exemplo, na sprint um foi planejado 18 tarefas, no entanto foram entregues 20 tarefas, isso
significa que a equipe conseguiu concluir as tarefas planejas e ainda adicionar a sprint mais 2
tarefas.
O gráfico pode indicar ao gerente de projetos que a equipe está pouco confiante de
forma que os tempos das estimativas estão alto demais, dessa forma as linhas do gráfico
andam sempre em paralelo, seria a oportunidade de incentivar a equipe a arriscar mais nas
estimativas e tentar entregar mais tarefas.
Quando há uma sequencia considerável de sprints cuja alinha azul está abaixo da linha
verde, pode significar que a equipe está pouco focada, sofrendo com impedimentos, o backlog
da sprint está sendo muito alterado ou a equipe não esta estimando corretamente as tarefas.
Nesse momento o gerente de projetos deve prestar atenção nos acontecimentos e tomar uma
decisão para melhorar as entregas ao cliente.
3 PROCEDIMENTOS METODOLÓGICOS
Diante objetivos que se pretende atingir com o artigo, a pesquisa foi realizada com
objetivo descritivo e explicativo, que segundo Duarte (2014), a pesquisa descritiva tem como
objetivo descrever características de um fenômeno ou de uma experiência e estabelece
relações entre as variáveis do objeto de estudo, a pesquisa explicativa por sua vez, tem como
objetivo explicar a razão e o porquê dos fenômenos. Quanto aos procedimentos técnicos
utilizados pode-se definir como bibliográfico. A pesquisa bibliográfica é feita a partir do
levantamento de referencias teórica já analisada, e publicada por meios escritos e eletrônicos,
como livros, artigos científicos, paginas de web sites. Qualquer trabalho científico inicia-se
com uma pesquisa bibliográfica, que permite ao pesquisador conhecer o que já se estudou
sobre o assunto. Existe porem pesquisas cientificas que se baseiam unicamente na pesquisa
bibliográfica, procurando referencias teóricas publicadas com o objetivo de recolher
informações ou conhecimentos prévios sobre o problema a respeito do qual se procura a
resposta. (FONSECA, 2002)
A pesquisa descritiva deste artigo foi apresentada na fase inicial, onde se pode
observar uma descrição breve de funções, atividades, métodos e artefatos no âmbito do
desenvolvimento de software e o relacionamento entre eles, dando ênfase ao objetivo do
artigo.
Com relação ao micro processo elaborado no presente artigo foi abordado uma
pesquisa descritiva de métodos, metodologias, conceitos e ferramentas aplicadas ao
gerenciamento de projetos no mundo ágil. Desta forma, foram abordados os seguintes pontos.
Iniciação Elaboração Validação
Na fase de iniciação, foram estudados os diversos modelos e métodos mais abordados
na prática para a construção de um micro processo de estimativas. Diante dos métodos
estudados o micro processo terá como base o SCRUM como modelo de processo, utilizando
artefatos e técnicas do modelo.
Na fase de elaboração, foram construídas as atividades e tarefas do micro processo
propostos, estipulado prioridade e definido estimativas de tamanho para as tarefas. Com os
resultados obtidos através das estimativas foram aplicados os dados em um gráfico burndown.
Na fase de validação, o micro processo passou por uma validação feita por um Gerente
de Projetos de uma empresa de Criciúma.

11. 11
1. Análise dos requisitos. Na fase de analise de requisitos foram definidos histórias de
usuários onde constituiu um backlog de cinco histórias.
2. Estimar prioridade. Diante de um backlog definido, é discutida juntamente com o
dono do produto uma prioridade de desenvolvimento das histórias.
3. Estimar tamanho. Com um backlog definido e priorizado a equipe se reúne para
estimar tamanho às tarefas. Para estimar o tamanho foi utilizada a sequência de
Fibonacci, transformando as histórias em pontos.
4. Composição do gráfico de estimativas e indicadores. Após estipular um backlog,
definir uma prioridade e estimar o tamanho de cada tarefa é aplicado as medidas no
gráfico Burndown e dado início a fase de desenvolvimento.
No capítulo seguinte apresenta-se os resultados obtidos durante a elaboração do micro
processo.
4 RESULTADOS ESPERADOS
Nesse capítulo são apresentados os resultados obtidos durante a execução do micro
processo. Na Tabela 1 é apresentado o backlog da sprint, a prioridade e o tamanho estimado
em pontos para cada história.
A estimativa de cada história foi definida através da sequencia de Fibonacci (1 – 2 – 3
– 5 – 8 – 13 – 21 ...), sendo que a menor história teve como pontuação 3 e a maior, pontuação
13.
Tabela 1 – Tarefas do micro processo
Backlog Prioridade Tamanho em pontos
História 1 História 2 13
História 2 História 1 3
História 3 História 4 13
História 4 História 3 8
História 5 História 5 13
Fonte: Elaborada pelo autor
A sprint totalizou 50 pontos, onde foram definidos 5, como a quantidade ideal de
pontos realizados por dia. Dessa forma a sprint deve estar concluída em 10 dias. Na Tabela 2
é apresentado os dados que compõem o gráfico burndown.
Tabela 2 – Dados para composição do gráfico
Dias Pontos restantes –
Ideal
Pontos restantes –
Realizados
Pontos realizados
0 50 50 0
Analise de
requisitos
Estimar
prioridade
Estimar
tamanho
Composição
do gráfico

12. 12
1 45 50 0
2 40 47 3
3 35 36 11
4 30 21 15
5 25 11 10
6 20 8 3
7 15 5 3
8 10 3 2
9 5 2 1
10 0 0 2
Fonte: Elaborada pelo autor
A Tabela 2 é composta pelos dias de duração da sprint, os pontos restantes ideal que
são subtraídos em 5 a cada dia da sprint, a quantidade de dias restantes realizados no qual é
composto do total de pontos da sprint subtraídos da quantidade de pontos realizados a cada
dia da sprint.
Aplicando os dados obtidos, em um gráfico burndown tem-se a seguinte situação,
apresentada na Ilustração 6.
Ilustração 6 – Gráfico burndown do micro processo
Fonte: Elaborada pelo autor
Com o auxílio de uma visão gráfica, é possível observar com clareza a situação do
andamento de uma sprint e a tendência de encerramento.

13. 13
5 CONCLUSÃO
O crescimento organizacional de empresas de software somado com as exigências dos
clientes na qualidade dos produtos oferecidos vem mudando o modo de se desenvolver
software.
Durante a elaboração deste artigo observou-se que modelos de desenvolvimento
clássicos como, por exemplo, o Modelo em Cascata, vem perdendo força dentro das empresas
de desenvolvimento, uma vez que o processo é considerado lento e pesado. Diante da
necessidade de mudanças os modelos de desenvolvimento ágil vêm tomando força e se
destacando continuamente como casos de sucesso.
A parte que se poderia dizer, mais importante, em um mundo de desenvolvimento ágil,
é justamente a agilidade na entrega e a qualidade do produto. Quando se necessita agilidade e
qualidade é vital estar atento aos acontecimentos dentro da equipe, qualquer impedimento
pode acarretar na agilidade e na qualidade da entrega do produto, transformando o que era pra
ser um modelo ágil em um modelo confuso e sem coerência.
Diante de uma equipe ágil, os acontecimentos ocorrem de certa forma, de maneira ágil
também, vem então a necessidade do auxílio de números, que se transformam em métricas e
indicadores. Perante o objetivo deste artigo, foi desenvolvido um micro processo onde foi
exemplificado a partir de requisitos de software, uma métrica e um indicador. Buscou-se com
a elaboração do micro processo mostrar o quão importante é para um gerente de software ter a
visão do andamento do seu projeto.
O presente artigo procurou descrever e exemplificar algumas métricas que podem ser
aplicadas em um modelo de desenvolvimento ágil, as métricas exemplificadas procuram de
maneira simples expor ao gerente do software informações vitais para o sucesso do projeto e
da sua equipe.
REFERÊNCIAS
ABREU, Thamine Chaves de; ARAÚJO, Marco Antônio Pereira; MOTA, Leonardo da Silva.
Métricas de Software: como utilizá-las no gerenciamento de projetos de software.
Engenharia de Software Magazine, Rio de Janeiro, ano II, 2. ed., p. 50-55, 2010.
AGILE ALLIANCE. The Agile Manifesto. Disponível em: <
http://www.agilealliance.org/the-alliance/the-agile-manifesto>. Acesso em: 29 de jul. 2014.
DUARTE, Vânia Maria do Nascimento. Pesquisas: Exploratória, Descritiva e Explicativa:
Disponível em: <http://monografias.brasilescola.com/regras-abnt/pesquisas-exploratoria-descritiva-
explicativa.htm >. Acesso em: 29 de jul. 2014.
FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002. Apostila.
http://www.ia.ufrrj.br/ppgea/conteudo/conteudo-2012-1/1SF/Sandra/apostilaMetodologia.pdf
HAZRATI, Vikas. Analisando gráficos de Burndown. Disponível em: <
http://www.infoq.com/br/news/2010/02/deciphering-burndown-charts>. Acesso em: 29 de jul.
2014.

14. 14
KOSCIANSKI, André; MICHEL, dos Santos Soares. Qualidade de Software: Aprenda as
metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo:
Novatec Editora, 2007.
MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de software.
Rio de Janeiro: Brasport, 2007.
PRESSMAN, Roger S., Engenharia de software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
PRESSMAN, Roger S., Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
PEARSON, Graham. Scrum For Team System Product Cumulative Flow. Disponível em:
< http://adiws.blogspot.com.br/2012/04/scrum-for-team-system-product.html >. Acesso em:
29 de jul. 2014.
SATO, Danilo. Artigo Engenharia de Software 12: Métricas de Acompanhamento para
Metodologias Ágeis. Disponível em: < http://www.devmedia.com.br/artigo-engenharia-de-software-
12-metricas-de-acompanhamento-para-metodologias-ageis/12562 >. Acesso em: 29
de jul. 2014.
SBROCCO, José Henrique Teixeira de Carvalho; MACEDO, Paulo Cesar de. Metodologias
ágeis: engenharia de software sob medida. 1. ed. São Paulo: Érica, 2012.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley,
2007.
Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK), 3.
ed., 2004, Project Management Institute, Four Campus Boulevard, Newtown Square, PA
19073-3299 EUA.
VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação. Rio de
Janeiro: Elsevier, 2003.