SlideShare uma empresa Scribd logo
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 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 
• 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 
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 
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 
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 
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 
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 
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 
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 
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 
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 
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 
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.

Mais conteúdo relacionado

Mais procurados

O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
Everton vitor
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Flávio Steffens
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitos
Eduardo Castro
 
Processos de software
Processos de softwareProcessos de software
Processos de software
Dann Volpato
 
Gestao Projetos - Aula 01
Gestao Projetos - Aula 01Gestao Projetos - Aula 01
Gestao Projetos - Aula 01
Robson Silva Espig
 
Modelos de Engenharia de Software
Modelos de Engenharia de SoftwareModelos de Engenharia de Software
Modelos de Engenharia de Software
Nathalia Sautchuk Patricio
 
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do ÓbvioUNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
Debora Modesto
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Elisangela Paulino
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
mpaf00 mpaf00
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Diógenes Almeida
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
André Luis Celestino
 
Escritório de projetos - Artigo
Escritório de projetos - ArtigoEscritório de projetos - Artigo
Escritório de projetos - Artigo
Hugo Silva
 
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeisUma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
s4nx
 
Metodos ageis
Metodos ageisMetodos ageis
Metodos ageis
Fábio Giordani
 
Crystal
CrystalCrystal
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamento
Otavio Siqueira
 
Gestão da Comunicação em Projetos
Gestão da Comunicação em ProjetosGestão da Comunicação em Projetos
Gestão da Comunicação em Projetos
Barbara Benedetti
 
Msf microsoft solutions framework - Apresentação
Msf  microsoft solutions framework -  ApresentaçãoMsf  microsoft solutions framework -  Apresentação
Msf microsoft solutions framework - Apresentação
cesaraks
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
Roberto Nunes
 
ISO IEC 12207
ISO IEC 12207ISO IEC 12207
ISO IEC 12207
Robson Silva Espig
 

Mais procurados (20)

O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitos
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Gestao Projetos - Aula 01
Gestao Projetos - Aula 01Gestao Projetos - Aula 01
Gestao Projetos - Aula 01
 
Modelos de Engenharia de Software
Modelos de Engenharia de SoftwareModelos de Engenharia de Software
Modelos de Engenharia de Software
 
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do ÓbvioUNIFESO 2019 - Gestão de Projetos Além do Óbvio
UNIFESO 2019 - Gestão de Projetos Além do Óbvio
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
Escritório de projetos - Artigo
Escritório de projetos - ArtigoEscritório de projetos - Artigo
Escritório de projetos - Artigo
 
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeisUma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
 
Metodos ageis
Metodos ageisMetodos ageis
Metodos ageis
 
Crystal
CrystalCrystal
Crystal
 
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamento
 
Gestão da Comunicação em Projetos
Gestão da Comunicação em ProjetosGestão da Comunicação em Projetos
Gestão da Comunicação em Projetos
 
Msf microsoft solutions framework - Apresentação
Msf  microsoft solutions framework -  ApresentaçãoMsf  microsoft solutions framework -  Apresentação
Msf microsoft solutions framework - Apresentação
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
 
ISO IEC 12207
ISO IEC 12207ISO IEC 12207
ISO IEC 12207
 

Semelhante a Desenvolvimento de um microprocesso utilizando métricas e indicadores como auxílio a gerência de projetos ágeis

Jucelir
JucelirJucelir
Jucelir
jucelir
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Fernando Palma
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
Daniel Wildt
 
Artigo aula4
Artigo aula4Artigo aula4
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
Sebastiao Sebastian
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
Priscilla Aguiar
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
Sergio Silva
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
Sergio Luiz da Silveira
 
Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.
Renato Breaking
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
pedrina4
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 
Tradução resumida do livro "The Elements of Scrum"
Tradução resumida do livro "The Elements of Scrum"Tradução resumida do livro "The Elements of Scrum"
Tradução resumida do livro "The Elements of Scrum"
Henrique Bueno
 
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoMétodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Claudia Hofart Guzzo
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
Kéllyson Gonçalves da Silva
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
Fábio Pio
 
Trabalho pds libre office 2
Trabalho pds libre office 2Trabalho pds libre office 2
Trabalho pds libre office 2
Edinaldo Mendes
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
Izabel Rodrigues
 

Semelhante a Desenvolvimento de um microprocesso utilizando métricas e indicadores como auxílio a gerência de projetos ágeis (17)

Jucelir
JucelirJucelir
Jucelir
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
Artigo aula4
Artigo aula4Artigo aula4
Artigo aula4
 
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
 
Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.Exercicio 1 engenharia de software.
Exercicio 1 engenharia de software.
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Tradução resumida do livro "The Elements of Scrum"
Tradução resumida do livro "The Elements of Scrum"Tradução resumida do livro "The Elements of Scrum"
Tradução resumida do livro "The Elements of Scrum"
 
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoMétodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
 
Trabalho pds libre office 2
Trabalho pds libre office 2Trabalho pds libre office 2
Trabalho pds libre office 2
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
 

Desenvolvimento de um microprocesso utilizando métricas e indicadores como auxílio a gerência de projetos ágeis

  • 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.