SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL
SENAI/SC - FLORIANÓPOLIS
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
VINICIUS VERARDI ALVES DE OLIVEIRA
INDICADORES DE PROJETOS ÁGEIS APLICADOS EM UMA EMPRESA DE
SOFTWARE
Florianópolis (SC)
2013
VINICIUS VERARDI ALVES DE OLIVEIRA
INDICADORES DE PROJETOS ÁGEIS APLICADOS EM UMA EMPRESA DE
SOFTWARE
Trabalho de Conclusão de Curso apresentado à
Banca
Examinadora
do
Curso
Superior
de
Tecnologia em Análise e Desenvolvimento de
Sistemas da Faculdade de Tecnologia SENAI
Florianópolis como requisito parcial para obtenção
do Grau de técnico em informática sob a orientação
da Profa. Priscila Bastos Fagundes, Me.
Florianópolis (SC)
2013
VINICIUS VERARDI ALVES DE OLIVEIRA
INDICADORES DE PROJETOS ÁGEIS APLICADOS EM UMA EMPRESA DE
SOFTWARE
Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Superior de
Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia
SENAI Florianópolis em cumprimento a requisito parcial para obtenção do título Superior
Tecnólogo em Análise e Desenvolvimento de Sistemas.
APROVADA PELA COMISSÃO EXAMINADORA
EM FLORIANÓPOLIS, ___ DE ________________DE _____
Profª. Priscila Bastos Fagundes, Me., (SENAI/SC) –
Coordenador do Curso
Profª. Jaqueline Voltolinide Almeida, Esp., (SENAI/SC) –
Coordenadora de TCC
Profª. Priscila Bastos Fagundes, Me. (SENAI/SC) –
Orientador
Mauricio Seiji Rezende, Me. (SENAI/SC) – Examinador
Aos meus pais.
AGRADECIMENTOS
Agradeço primeiramente aos meus pais, Claudio Oliveira e Marisol Alves, pelo
apoio e educação que me deram para chegar até aqui.
À professora e coordenadora do curso, Priscila Fagundes, por me orientar ao longo
deste trabalho de conclusão de curso e pela sua dedicação perante aos alunos do SENAI.
À Vitor Pelizza e Débora Anselmo, meus tutores na empresa XPTO, responsáveis
por guiar os passos e o conhecimento necessário para a realização deste trabalho.
À todos entrevistados e a empresa XPTO, pelo auxilio e estrutura que possibilitaram
a existência deste trabalho.
“Insanidade: É fazer a mesma coisa repetidamente e esperar resultados diferentes.”
(ALBERT EINSTEIN)
OLIVEIRA, Vinicius Verardi Alves de. Indicadores De Projetos Ágeis Aplicados Em Uma
Empresa De Software.
Florianópolis, 2013. Trabalho de Conclusão de Curso - Curso
Superior de Tecnologia em Analise e desenvolvimento de sistemas. Faculdade de Tecnologia
do SENAI, Florianópolis, 2013.
RESUMO
As empresas de desenvolvimento de software estão mudando. O progresso acelerado da área
de TI passa a exigir grande demanda de respostas à essa evolução. A partir desta demanda, a
adoção de metodologias ágeis cresce muito nas empresas de desenvolvimento de software,
valorizando o feedback e colaboração constante junto aos clientes, ou seja, é importante
mostrar resultados. A abordagem incremental da metodologia ágil visa a realização constante
de revisões e melhoria continua do processo de desenvolvimento de software adotado,
gerando maior qualidade no produto final. Visando estabelecer melhorias constantes, há um
crescente enfoque na aplicação de indicadores e métricas que permitem validar esta evolução,
padronizando um ciclo de revisão e otimização dentro do processo de desenvolvimento de
software utilizado pelas empresas.
Palavras-chave: Metodologia ágil. Indicador. Métrica.
OLIVEIRA, Vinicius Verardi Alves de. Indicadores De Projetos Ágeis Aplicados Em Uma
Empresa De Software.
Florianópolis, 2013. Trabalho de Conclusão de Curso - Curso
Superior de Tecnologia em Analise e desenvolvimento de sistemas. Faculdade de Tecnologia
do SENAI, Florianópolis, 2013.
ABSTRACT
Software development companies are changing. The accelerated progress of IT starts
demanding regularly answers to this evolution. According to this appeal, there is a growing
adoption of agile methodologies on software development companies, valuing feedback and
constant collaboration with customers, in other words, is important to show results. The
incremental approach to agile methodology aims to constant revisions and continuous
improvement of the adopted software development process, generating sophisticated quality
in the final product. To establish continuous improvements, there is a rising focus on
application of metrics and indicators, which allows validate this growth, standardizing a
revision and optimization cycle inside the software development process assumed by these
companies.
Keywords: Agile methodology. Indicator. Metric.
LISTA DE FIGURAS
Figura 1 – Scrum ...................................................................................................................... 17
Figura 2 – Kanban Board ......................................................................................................... 22
Figura 3 - Medida ..................................................................................................................... 25
Figura 4 - Métrica ..................................................................................................................... 26
Figura 5 - Indicador .................................................................................................................. 27
Figura 6 - Sprint Burndown ...................................................................................................... 29
Figura 7 - Release Burndown ................................................................................................... 29
Figura 8 - Velocidade ............................................................................................................... 30
Figura 9 - Aceleração ............................................................................................................... 32
Figura 10 - Cumulative Flow ................................................................................................... 33
Figura 11 – Calculo Lead Time ................................................................................................ 34
Figura 12 – SLA ....................................................................................................................... 34
Figura 13 – Cycle Time ............................................................................................................ 35
LISTA DE GRÁFICOS
Gráfico 1 – Burndown Sprint 74 Equipe A .............................................................................. 43
Gráfico 2 – Burndown Sprint 1 Equipe B ................................................................................ 43
Gráfico 3 – Burndown Sprint 1 Equipe C ................................................................................ 44
Gráfico 4 – Histórico da Velocidade na Equipe A ................................................................... 45
Gráfico 5 – Evolução da Aceleração Equipe A ........................................................................ 46
Gráfico 6 - Cumulative Flow Equipe C .................................................................................... 48
LISTA DE ABREVIATURAS E SIGLAS
IT – Information Technology
MIT – Massachussets Institute of Tecnology
SAC – Sistema de Atendimento ao Cliente
SENAI – Serviço Nacional de Aprendizagem Industrial
TDD – Test-driven Development
TI – Tecnologia da Informação
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 14
1.1 JUSTIFICATIVA ............................................................................................................... 15
1.2 OBJETIVOS ....................................................................................................................... 15
1.2.1 Objetivo geral ................................................................................................................. 15
1.2.2 Objetivos específicos ...................................................................................................... 15
2 METODOLOGIAS ÁGEIS ................................................................................................ 16
2.1 SCRUM .............................................................................................................................. 17
2.1.1 Equipes Scrum ............................................................................................................... 18
2.1.2 Artefatos do Scrum ........................................................................................................ 18
2.1.3 Eventos Scrum ............................................................................................................... 19
2.1.4 Estimativas Scrum ......................................................................................................... 21
2.2 KANBAN ........................................................................................................................... 21
3 MEDIDAS, MÉTRICAS E INDICADORES.................................................................... 24
3.1 MEDIDAS E MÉTRICAS ................................................................................................. 24
3.2 INDICADORES ................................................................................................................. 27
3.3 MÉTRICAS E INDICADORES ÁGEIS ............................................................................ 28
3.3.1 Burndown........................................................................................................................ 28
3.3.2 Velocidade ...................................................................................................................... 30
3.3.3 Aceleração ...................................................................................................................... 31
3.3.4 Cumulative Flow............................................................................................................. 32
3.3.5 Lead Time ....................................................................................................................... 34
3.3.6 Cycle Time....................................................................................................................... 35
4 PROCEDIMENTOS METODOLÓGICOS ..................................................................... 36
5 ESTUDO DE CASO ............................................................................................................ 37
5.1 A EMPRESA ...................................................................................................................... 37
5.2 O PROCESSO DE DESENVOLVIMENTO DA EMPRESA ........................................... 38
5.3 AS MÉTRICAS E INDICADORES DA EMPRESA ........................................................ 41
5.3.1 Burndown........................................................................................................................ 42
5.3.2 Velocidade ...................................................................................................................... 44
5.3.3 Aceleração ...................................................................................................................... 46
5.3.4 Cumulative Flow............................................................................................................. 47
5.3.5 Lead Time ....................................................................................................................... 48
5.3.6 Cycle Time....................................................................................................................... 49
6 CONCLUSÃO...................................................................................................................... 50
REFERÊNCIAS ..................................................................................................................... 52
APÊNDICES ........................................................................................................................... 56
APÊNDICE A – ENTREVISTA SOBRE MÉTRICAS E INDICADORES DE PROJETOS
ÁGEIS ...................................................................................................................................... 56
ANEXOS ................................................................................................................................. 57
ANEXO A – GRÁFICO BURNDOWN SPRINT 75 EQUIPE A ............................................. 57
ANEXO B – GRÁFICO BURNDOWN SPRINT 76 EQUIPE A ............................................. 57
ANEXO C – GRÁFICO BURNDOWN SPRINT 2 EQUIPE C ................................................ 58
ANEXO D – GRÁFICO BURNDOWN SPRINT 3 EQUIPE C................................................ 58
14
1 INTRODUÇÃO
O processo incremental empregado pelos métodos ágeis gera um ciclo uniforme de
revisões, melhorias e atualizações. Se este ciclo não for devidamente padronizado, o
processo de otimização pode se tornar demorado e oneroso (SATO, 2009).
Medições de software são destinadas a determinar valores numéricos a atributos de
um determinado software ou processo de software. Confrontando esses valores, obtidos ao
longo de intervalos de tempo, é possível se chegar a conclusões sobre a qualidade do
software em questão ou dos processos aplicados em seu ciclo de vida (SOMMERVILLE,
2007).
Foi realizado um estudo de caso em uma grande empresa de desenvolvimento de
software, analisando como a empresa adota métricas e indicadores providos de metodologias
ágeis. Por questão de privacidade, não será revelada a identidade da empresa, assim
utilizaremos o nome fictício de empresa XPTO.
Será apresentado, neste trabalho, um estudo sobre metodologias ágeis, abordando os
frameworks do Scrum e Kanban. A seguir serão apresentados os conceitos sobre métricas e
indicadores atrelados a desenvolvimento de software. O tópico seguinte irá abordar os
conceitos referentes a métricas e indicadores ágeis aplicáveis ao processo de
desenvolvimento da empresa XPTO.
Um estudo de caso utilizará uma visão ágil ao desenvolvimento de software para
analisar a utilização das métricas e indicadores na gestão dos projetos de desenvolvimento da
empresa XPTO, indicando possíveis falhas e oportunidades de melhoria dentro do ciclo de
revisões da empresa.
15
1.1 JUSTIFICATIVA
O presente estudo visa aumentar a qualidade do processo de desenvolvimento de
software da empresa XPTO, analisando e propondo melhorias para medir a qualidade do
processo de desenvolvimento utilizado nos projetos que utilizam metodologias ágeis.
1.2 OBJETIVOS
Visando uma contextualização deste trabalho, os objetivos estão apresentados a
seguir, divididos em objetivo geral e objetivos específicos.
1.2.1 Objetivo geral
Comparar as métricas e os indicadores de projeto utilizados na empresa XPTO, com
as métricas e indicadores focados em projetos ágeis, identificando possíveis melhorias no
processo de desenvolvimento de software da empresa.
1.2.2 Objetivos específicos
a)
Analisar o framework Scrum, selecionando métricas e indicadores aplicáveis
aos projetos da empresa XPTO.
b)
Analisar a metodologia do Kanban, selecionando métricas e indicadores
aplicáveis aos projetos da empresa XPTO.
c)
Comparar o processo de desenvolvimento adotado pelas equipes com as
metodologias ágeis de desenvolvimento estudados.
d)
Construir uma comparativa entre as métricas e os indicadores utilizados na
empresa XPTO e as métricas e os indicadores estudados dentro das metodologias ágeis.
e)
Propor melhorias dentro do processo de desenvolvimento de software da
empresa XPTO.
16
2 METODOLOGIAS ÁGEIS
A palavra ‘Ágil’ é um termo de marketing criado para descrever um estilo de
trabalho. Esse estilo se concentra em trabalho colaborativo, resultados concretos, entrega de
valores e minimização de desperdícios (SHORE, 2008).
O Manifesto Ágil, criado em 2001 na cidade de Utah, descreve a essência de um
conjunto de abordagens baseado em diversas metodologias de desenvolvimento de produtos e
software, visando a criação de uma alternativa perante aos complexos e burocráticos
processos de desenvolvimento de software existentes na época.
Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o nós
mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a
valorizar:
a) Indivíduos e interações mais que processos e ferramentas.
b) Software em funcionamento mais que documentação abrangente.
c) Colaboração com o cliente mais que negociação de contratos.
d) Responder a mudanças mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda (BECK et al., 2001).
As metodologias ágeis se tornaram extremamente populares. Cada vez mais, grandes
companhias como IBM e Microsoft adotam as metodologias ágeis para gerenciamento de
seus projetos e equipes (SHORE; WARDEN, 2008).
O objetivo de todas as empresas é alcançar de alguma maneira, o sucesso
organizacional. Os métodos ágeis atingem este sucesso focando em agregar valor e diminuir
custos, o que será revertido em um retorno aumentado do investimento (SHORE; WARDEN,
2008).
De acordo com o Sétimo Estado Anual do Desenvolvimento Ágil, 84% das
companhias entrevistadas planejam utilizam ou planejam utilizar metodologias ágeis em seus
projetos (VERSION ONE, 2013).
Cohn (2011) cita alguns dos principais benefícios da adoção de métodos ágeis:
a) Maior produtividade e menores custos;
b) Maior engajamento e satisfação por parte dos colaboradores;
c) Tempo de colocação do produto no mercado mais rápido;
17
d) Maior qualidade;
e) Maior satisfação dos stakeholders1.
2.1 SCRUM
O Scrum é um framework criado para suportar o desenvolvimento e manutenção de
produtos, onde pessoas podem tratar e solucionar problemas complexos e adaptativos. O
framework consiste em equipes Scrum associadas a seus papéis, eventos, artefatos e regras
(SCHWABER; SUTHERLAND, 2011).
Figura 1 – Scrum
Fonte: Mountain Goat Software (2005)
Kniberg (2009) descreve o Scrum em breves tópicos:
a) Separar a empresa, em equipes pequenas, multifuncionais e auto organizáveis;
b) Dividir o trabalho, em uma lista de pequenas funcionalidades entregáveis, estime
o esforço de cada uma e organize por prioridade;
1
Um stakeholder, é uma pessoa ou organização ativamente envolvida em um projeto. Esta organização ou
pessoa possui interesses que possam ser positiva ou negativamente afetados pela execução ou conclusão do
projeto ou pode vir a exercer influência sobre o projeto, suas entregas e seus membros de equipe (BOURNE,
2009).
18
c) Dividir o tempo, em iterações pequenas e de tamanho fixo (1–4 semanas), sempre
com potenciais funcionalidades a serem entregues ao final de cada iteração;
d) Reorganizar as prioridades e seu plano de entregas em conjunto com seu cliente,
baseando-se no conhecimento obtido ao longo das iterações;
e) Otimizar e incrementar o processo, fazendo uma retrospectiva ao final de cada
iteração.
2.1.1 Equipes Scrum
As equipes Scrum são formadas por três papéis: um Product Owner, a Equipe de
Desenvolvimento e o Scrum Master (SCHWABER; SUTHERLAND, 2011).
O Product Owner é o responsável por maximizar o valor do produto e o trabalho da
equipe de desenvolvimento. Dentre suas atividades, a principal é gerenciar o backlog do
produto (SCHWABER; SUTHERLAND, 2011).
A Equipe de Desenvolvimento deve ser pequena, multifuncional e auto organizável
(KNIBERG, 2009).
Segundo Schwaber e Sutherland (2011), a função da Equipe de Desenvolvimento é
entregar uma versão tangível do que foi desenvolvido que potencialmente integrará o produto
“pronto” ao final de cada Sprint.
O Scrum Master tem a responsabilidade de fazer com que o Scrum seja entendido e
aplicado, garantindo que a equipe Scrum esteja em conformidade com a teoria, práticas e
regras do Scrum (SCHWABER; SUTHERLAND, 2011).
2.1.2 Artefatos do Scrum
Os artefatos do Scrum representam o trabalho ou o valor das várias maneiras que são
úteis no fornecimento de transparência e oportunidades para inspeção e adaptação
(SCHWABER; SUTHERLAND, 2011).
19
O Backlog do Produto é uma lista completa de funcionalidades pendentes de
desenvolvimento que farão parte do produto final. O Backlog do Produto é priorizado pelo
Product Owner para que a equipe Scrum primeiramente trabalhe em cima das funcionalidades
de alto valor. A maneira mais conhecida para criar um Backlog do Produto é por meio das
histórias de usuário, que são pequenas descrições de cada funcionalidade a partir da
perspectiva de um usuário ou cliente (COHN, 2013).
Outro artefato é o Backlog da Sprint, que é uma lista de funcionalidades, criada na
Reunião de Planejamento da Sprint pelos membros da equipe Scrum. Essas funcionalidades
serão a lista de afazeres da equipe durante a Sprint (COHN, 2013).
Existem outros artefatos importantes, como o Sprint Burndown Chart e o Release
Burndown Chart, que serão analisados no item 2.3.
2.1.3 Eventos Scrum
No Scrum, existem eventos pré-definidos e com uma duração máxima para
ocorrerem, eles garantem a transparência, adaptabilidade e inspeção do trabalho realizado. A
Sprint é o principal evento do Scrum, os outros eventos estão atrelados a seu planejamento,
inspeção e adaptação (SCHWABER; SUTHERLAND, 2011).
Kniberg (2009) recomenda que as equipes Scrum organizem suas Sprints em
iterações pequenas e de tamanho fixo (1 – 4 semanas), sempre com potenciais
funcionalidades a serem entregues ao final de cada iteração.
De acordo com Schwaber e Sutherland (2011), as Sprints são compostas por uma
reunião de planejamento, reuniões diárias, o trabalho de desenvolvimento, uma revisão da
Sprint e a retrospectiva da Sprint:
a) Reunião de planejamento;
Nas reuniões de planejamento, a equipe Scrum inteira fará sua colaboração. Nesse
plano serão definidas duas questões:
1) Quais itens do backlog do produto serão entregues como resultado do
incremento da próxima Sprint?
20
2) Como o trabalho deve ser executado para entregar o incremento?
b) Reunião diária;
É um evento diário, com duração de 15 minutos, em que a equipe de
desenvolvimento deve sincronizar as atividades realizadas e planejar as próximas 24 horas.
Cada membro da equipe esclarece três questões:
1) Desde a última reunião, o que foi finalizado?
2) Até a próxima reunião, o que será desenvolvido?
3) Existem impedimentos para a realização das atividades? Quais?
Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam
e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de
decisão e melhoram o nível de conhecimento da equipe de desenvolvimento.
c) Revisão da Sprint.
A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e
adaptar o Backlog do Produto, se necessário. A Reunião de Revisão inclui os seguintes
elementos:
1) O Product Owner identifica o que foi “Pronto” e o que não foi “Pronto”.
2) A Equipe de Desenvolvimento discute o desempenho da Sprint, salientando os
problemas ocorridos dentro da Sprint e como foram resolvidos.
3) A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e
responde as questões sobre o incremento.
4) O Product Owner discute o Backlog do Produto tal como está, projetando as
prováveis datas de conclusão baseado no progresso até a data.
5) O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de
Revisão da Sprint fornece informações importantes para a Reunião de
Planejamento da próxima Sprint.
21
2.1.4 Estimativas Scrum
Nesta seção, será introduzida a técnica de estimativa por pontos de história, uma
prática do Scrum para a realização das estimativas de esforço dos requisitos e funcionalidades
de um software.
Os pontos de história são uma unidade de medida para expressar o tamanho médio de
uma história de usuário, funcionalidade ou parte do trabalho. Quando é realizada a estimativa
por pontos de história, atribuímos um valor de ponto de história para cada item (COHN,
2006).
Ainda de acordo com Cohn (2006), os valores que serão utilizados para representar o
trabalho não importam; o essencial é manter a consistência na estimativa: uma história que
possui um valor de “dois” deve ser pelo menos duas vezes mais complexa do que a história
que vale apenas “um”. Pode-se representar que a atividade de valor “dois” simbolicamente
vale seis pontos de história, assim a atividade de valor “um” deveria ser estimada com valor
de três pontos de história. Dessa forma, há medidas consistentes.
2.2 KANBAN
Kanban é uma palavra Japonesa que significa “cartão visual”. Na Toyota, por
exemplo, Kanban é o termo utilizado para definir o sistema de sinalização físico e visual que
integra o sistema lean2 de produção. No desenvolvimento ágil de software, o Kanban é
considerado uma abordagem lean (KNIBERG, 2013).
A metodologia Kanban adota técnicas de melhoria contínua, baseada na visualização
do estado atual do planejamento de trabalho, tendo a gestão do fluxo de trabalho como a
principal medida de desempenho (AGILE ALIANCE, 2013).
Kniberg e Skarin (2010) definem o núcleo de trabalho do Kanban da seguinte
maneira:
O termo “lean” foi cunhado ao final da década de 1980 em um projeto de pesquisa do Massachusetts Institute
of Technology (MIT) sobre a indústria automobilística mundial. A pesquisa revelou que a Toyota havia
desenvolvido um novo e superior paradigma de gestão nas principais dimensões dos negócios (manufatura,
desenvolvimento de produtos e relacionamento com os clientes e fornecedores) (LEAN, 2013).
2
22
a) Visualização do fluxo de trabalho;
 Divida o trabalho em pequenas partes, escreva cada item em um cartão e cole
no mural.
 Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho.
b) Limitar o trabalho em andamento;
 Atribua limites de quantos itens podem estar em andamento dentro de cada
estado no fluxo de trabalho.
c) Mensurar tempo de ciclo (Cycle Time).
 Otimize o processo para tornar o tempo de cada ciclo cada vez menor e
previsível.
Figura 2 – Kanban Board
Fonte: Kniberg (2013)
Segundo Kniberg e Skarin (2010), os principais benefícios do Kanban são:
a) Possíveis gargalos tornam-se visíveis em tempo real. Isto levará as pessoas a
colaborarem na otimização de toda cadeia de valor, não apenas em suas partes
individuais;
b) Promove um modelo de evolução mais gradual de cascata para o desenvolvimento
ágil de software, ajudando empresas que anteriormente foram incapazes ou não
estavam dispostas a implementar métodos ágeis;
c) Fornece uma maneira para fazer o desenvolvimento ágil de software sem a
necessidade de utilizar iterações de tempo e compromissos fixos pré-
23
determinados. Útil para situações onde Sprints do Scrum não fazem sentido, como
em equipes de suporte, onde ocorre um alto grau de incerteza e variabilidade;
d) Tende a espalhar-se por toda empresa para os outros departamentos, como vendas
e RH, aumentando a visibilidade de tudo que está acontecendo na empresa.
O tópico seguinte aborda os conceitos de medidas, métricas e indicadores focados no
desenvolvimento de software.
24
3 MEDIDAS, MÉTRICAS E INDICADORES
Esta seção descreve os conceitos de medidas, métricas e indicadores dentro do
desenvolvimento de software. Em seguida, serão apresentadas métricas e indicadores focados
nos métodos ágeis de desenvolvimento de software.
3.1 MEDIDAS E MÉTRICAS
No contexto de gerenciamento de projetos de software, as preocupações iniciais são
relacionadas a métricas de produtividade dentro do processo de software e a qualidade do
produto em desenvolvimento (PRESSMAN, 1995).
Pressman (1995) lista cinco razões para que seja realizada a medição de software:
a) Indicar qualidade do produto;
b) Avaliar a produtividade das pessoas que produzem o produto;
c) Avaliar os benefícios derivados de novos métodos e ferramentas de
desenvolvimento de software;
d) Formar uma linha básica para estimativas;
e) Ajudar a justificar pedidos de novas ferramentas ou treinamento adicional.
De acordo com Sato (2009), métricas de software são padrões de medida, referentes
ao sistema, processo ou artefato. Elas podem ser calculadas sobre uma ou mais medidas. Por
exemplo, a quantidade de problemas encontrados após a implantação do software; neste caso
a métrica será composta pelo número de defeitos e a data onde foi identificado o defeito. A
Figura 3 representa a medida e seu valor no contexto de um gráfico.
25
Figura 3 - Medida
Fonte: O autor (2013)
Sato (2009) classifica as métricas em três grupos, uma mesma métrica pode estar
dentro de um ou mais grupos, pois eles abordam diferentes pontos de vista:
a) Objetiva/Subjetiva;
O valor de uma métrica objetiva depende somente do objeto em questão e não do
ponto de vista de quem a está interpretando. Por exemplo, o número de revisões no
repositório é uma métrica objetiva, pois é obtida diretamente da ferramenta.
O valor de uma métrica subjetiva depende do objeto em questão e também do ponto
de vista de quem a está interpretando. Por exemplo, a qualidade do código, numa escala de
0% a 100%.
b) Quantitativa/Qualitativa;
O valor de uma métrica quantitativa pertence a um intervalo de uma certa
magnitude e geralmente é representado por um número. Tal estrutura permite que medidas
quantitativas sejam comparadas entre si. Por exemplo, o número de defeitos encontrados.
26
Valores de uma métrica qualitativa são aqueles representados por palavras,
símbolos ou figuras em vez de números. Por exemplo, a satisfação do cliente, a qual pode ser
definida como baixa, média ou alta.
c) Organizacional/Acompanhamento.
Métricas organizacionais são aquelas que medem a quantidade de valor de negócio
entregue ao cliente.
Métricas de acompanhamento proveem informações que ajudam o time no
entendimento e Melhoria do processo que produz valor de negócio. Por exemplo, a
velocidade da equipe.
Uma métrica é a representação da evolução das alterações de uma medida mensurada
ao longo de um intervalo ou variação temporal. A linha azul na Figura 4 a seguir representa
uma métrica.
Figura 4 - Métrica
Fonte: O autor (2013)
27
3.2 INDICADORES
Um indicador é um valor que define uma situação em particular. No caso de um
projeto de software, podemos defini-lo como uma métrica definida pelo projeto como meta,
para fins de monitoria e acompanhamento, onde a cada iteração do projeto, esta mesma
métrica é extraída novamente, comparando-a ao indicador. Na Figura 5, o indicador está
representado pela linha amarela.
Figura 5 - Indicador
Fonte: O autor (2013)
Indicadores de projeto são instrumentos de avaliação que permitem comprovar
empiricamente e com objetividade a progressão de uma ou mais dimensões de um projeto
diante de metas estabelecidas (ARMANDO FILHO, 2010).
O indicador permitirá a realização de comparações históricas, com dados obtidos ao
longo do tempo, para avaliar as variações e o avanço do que está sendo observado, diante da
expectativa do que foi planejado no início do projeto.
28
3.3 MÉTRICAS E INDICADORES ÁGEIS
Este tópico aborda uma série de métricas e indicadores focados para equipes que
utilizam metodologias ágeis de desenvolvimento de software.
3.3.1 Burndown
O gráfico Burndown é um artefato enraizado no framework Scrum. Basicamente, ele
representa a quantidade de esforço que falta, para a conclusão das tarefas estimadas dentro de
uma iteração. Por ser flexível, ele pode ser aplicado em qualquer tipo de projeto
(VELAMAKANNI; SATHIANARAYANAN, 2009).
Quando o gráfico Burndown é utilizado para rastrear o desenvolvimento de um
produto, as equipes podem utilizar um gráfico Burndown para rastrear cada iteração (Sprint
Burndown Chart) e também um gráfico Burndown para rastrear o completo do projeto
(Release Burndown Chart) (KOCUREK, 2011). Sendo assim, é possível afirmar que, de
acordo com os grupos de classificação criados por Sato (2009), esta métrica é quantitativa e
de acompanhamento.
A criação do gráfico Burndown para acompanhamento de iterações é feita a partir de
duas medidas: tempo (eixo X) e trabalho restante (eixo Y). O tempo pode ser representado em
dias, já o trabalho deve ser representado em horas (Figura 6).
29
Figura 6 - Sprint Burndown
Fonte: French Scrum User Group (2013)
O gráfico Burndown, quando utilizado para acompanhamento de entregas, utiliza as
mesmas medidas, porém o tempo (eixo X) será representado pelo número de iterações do
projeto, o trabalho restante (eixo Y) pode ser representado por pontos de história, número de
funcionalidades e até mesmo horas/dias estimados (Figura 7).
Figura 7 - Release Burndown
Fonte: Mountain Goat Software (2013)
30
Quando atualizado diariamente, o gráfico Burndown fornece dados sobre precisão de
estimativas,
produtividade
da
equipe,
controle
de
processos
(VELAMAKANNI;
SATHIANARAYANAN, 2009).
3.3.2 Velocidade
Ao fim de cada iteração, a equipe verifica os pontos estimados que foram entregues
durante a iteração. A soma destes pontos é chamada velocidade (AGILE ALLIANCE, 2013).
Sato (2009) define que a velocidade é um indicador quantitativo e objetivo.
É possível gerar um gráfico da variação de velocidade (eixo Y) ao longo das
iterações (eixo X). Para isto, pode-se utilizar como medidas de velocidade: Pontos de história,
horas de trabalho ou dias, considerando apenas os itens concluídos em cada iteração (Figura
8).
Figura 8 - Velocidade
Fonte: Version One (2013)
A velocidade é uma métrica de acompanhamento que possibilita a equipe conhecer
seus limites e atingir os objetivos de cada iteração. Com a velocidade, é possível melhorar
capacidade de entregar software funcionando, a precisão das estimativas e o planejamento dos
projetos.
De acordo com Sato (2009), existem fatores que podem afetar a velocidade:
a) Mudanças na equipe;
31
b) Impedimentos;
c) Falta de conhecimento em ferramentas e tecnologias utilizadas.
É importante ressaltar que não há comparação significativa da velocidade de
diferentes equipes. Mesmo que todas as equipes utilizem a mesma medida para estimar
esforços, cada equipe emprega uma técnica diferente no momento de realizar a estimativa
(AGILE ALLIANCE, 2013).
3.3.3 Aceleração
A aceleração é um indicador calculado com base na velocidade da equipe ao longo
das iterações. É considerada uma solução interessante para comparar produtividade entre
diferentes equipes.
Ambler (2008) sugere que o cálculo da aceleração seja realizado desta forma:
(Velocidade da iteração 2 – Velocidade da iteração 1) / Velocidade da iteração 1 = Aceleração
da equipe.
É possível construir um gráfico do histórico da aceleração de uma equipe entre as
iterações, baseando-se na velocidade da equipe em cada iteração (Figura 9).
Exemplo do histórico de velocidade na equipe Y: Iteração 1: 17 pontos; Iteração 2:
18 pontos; Iteração 3: 18 pontos; Iteração 4: 19 pontos; Iteração 5: 21 pontos.
32
Figura 9 - Aceleração
Fonte: O autor (2013)
Também se calcula que a aceleração da equipe Y, partindo da iteração 1 para a
iteração 5 foi (21-17)/17 = 0,235294118 ou seja: 23,53%.
Na comparação entre diferentes equipes, é aconselhada a normalização da métrica:
Divide-se o resultado da aceleração pelo número de membros da respectiva equipe. Isto
possibilita obter a aceleração média por membro de equipe (AMBLER, 2008).
Ainda de acordo com Ambler (2008), monetizar este indicador pode ser uma solução
interessante: Sabendo a aceleração da equipe e quanto ela gasta por iteração, é possível
estimar quanto dinheiro está sendo economizado por iteração. Exemplo: A equipe Y possui a
aceleração de 3%. São gastos por iteração R$ 20000,00. Assim a economia por iteração é de
R$ 600,00.
3.3.4 Cumulative Flow
O gráfico Cumulative Flow é uma representação gráfica que exibe como as
atividades sofrem mudanças entre diferentes estados ao longo do projeto até serem finalizadas
(AGILE SHERPA, 2010).
33
O gráfico é formado pela variação da quantidade de trabalho (eixo Y) atrelado a seus
estados (categorias) ao longo do tempo (eixo X). Na Figura 10 as categorias estão
representadas por: atividades em backlog, atividades em progresso, e atividades finalizadas.
Figura 10 - Cumulative Flow
Fonte: Yoshima (2013)
A Agile Sherpa (2010) cita diversos fatores que a análise deste gráfico permite
visualizar ao longo do projeto:
a) Frequência de entrega ou não das atividades.
b) Onde se localizam os gargalos e impedimentos.
c) Quanto
tempo
leva
para
uma
atividade
percorrer
todos
estados
de
desenvolvimento (tempo de ciclo).
d) Frequência nas mudanças de escopo do projeto.
Dessa maneira, é possível revisar as etapas do processo de desenvolvimento de
software que precisam de reformas e melhorias.
34
3.3.5 Lead Time
Adaptado ao desenvolvimento de software, pode-se dizer que o lead time é o tempo
percorrido entre a identificação de um requisito até sua entrega efetiva (AGILE ALLIANCE,
2013).
O conceito do lead time visa eliminar desperdícios, excluindo o que não tem valor para o
cliente, imprimindo velocidade à empresa. O lead time é calculado pela formula: Trabalho em
progresso / Taxa de saída. (Figura 11) (VITOR, 2010).
Figura 11 – Calculo Lead Time
Fonte: Vitor (2010)
Em outras palavras, se uma equipe possui dezoito pontos de história em progresso, e a
cada hora que passa a equipe entrega três pontos, então o lead time da equipe é de seis horas.
Possuir um lead time estável, permite que empresas focadas na excelência do
atendimento ao cliente implementem acordos de nível de serviço (Figura 12).
Figura 12 – SLA
Fonte: Roock (2013)
35
3.3.6 Cycle Time
O cycle time é o tempo percorrido entre a ordem de implementação de uma atividade
até o momento de sua entrega (SATO, 2009).
Sato (2009) considera que o cycle time é importante para descobrir o quão rápido o
processo de desenvolvimento entrega valor de forma repetitiva e confiável.
Para descobrir o cycle time de um item de trabalho, basta medir o tempo corrido,
partindo do início da implementação da funcionalidade, até o momento em que é realizada a
entrega como incremento do produto final (Figura 13).
Figura 13 – Cycle Time
Fonte: Roock (2013)
Conforme o processo de desenvolvimento é melhorado, o cycle time deve diminuir,
até atingir um patamar mínimo (SATO, 2009).
Lankey (2012) determina uma série de ações que podem ser tomadas para melhorar o
cycle time do projeto. Dentre estas, é importante citar:
a) Estabeleça regras básicas com sua equipe, possibilitando maior comunicação
entre todos;
b) Defina claramente seu problema e o escopo do projeto;
c) Selecione adequadamente sua equipe, com pessoas engajadas e responsáveis;
d) Estabeleça um bom plano de projeto;
e) Agende previamente as reuniões de monitoramento e revisão com a equipe.
36
4 PROCEDIMENTOS METODOLÓGICOS
Este estudo baseia-se em uma análise qualitativa que, segundo Silva Casarin e José
Casarin (2011), explora uma metodologia predominantemente descritiva, reduzindo a
prioridade aos modelos matemáticos e estatísticos, onde a quantificação dos objetos da
pesquisa é deixada em segundo plano.
Foi realizada uma pesquisa exploratória, para desenvolver a capacitação e
contextualização do conteúdo abordado. Como fontes de pesquisa, foram consultados livros,
artigos científicos, material disponibilizado na internet, teses e dissertações. De acordo com
Silva e Casarin (2011), a pesquisa exploratória tem como objetivo proporcionar conhecimento
sobre determinado problema ou fenômeno.
Tratando-se de um estudo de caso, foram levantados dados subjetivos a partir de
entrevistas estruturadas. O estudo de caso é uma modalidade de estudo nas ciências sociais,
focando na coleta e registro de informações relacionadas a casos particularizados, elaborando
relatórios críticos organizados, possibilitando a tomada de decisões ou intervenções sobre o
objeto selecionado para a análise. As entrevistas são estruturadas quando o roteiro de questões
está previamente definido pelo entrevistador e não há liberdade para alterar os tópicos ou
incluir questões diante das situações (BARROS; LEHFELD, 2007).
37
5 ESTUDO DE CASO
Este capítulo apresenta o estudo de caso realizado na empresa XPTO, descrevendo
como as equipes pesquisadas trabalham com as metodologias ágeis e de que forma métricas e
indicadores são aplicados.
5.1 A EMPRESA
A empresa XPTO é uma companhia de grande porte focada no desenvolvimento de
soluções corporativas para segmentos específicos de negócios, como: Tribunais de Justiça,
Procuradorias, órgãos de infraestrutura, transportes e obras, universidades, empresas do ramo
da construção civil e organizações que adquirem financiamentos em bancos internacionais.
O cenário do estudo de caso foi realizado dentro de três equipes da área de
desenvolvimento da empresa. As equipes desenvolvem soluções especificas para Tribunais de
Justiça e Procuradorias. Para a análise, denominamos as equipe em A, B e C. Em cada equipe,
uma pessoa assume um papel gerencial e define como a equipe seguirá a metodologia de
desenvolvimento proposta pela empresa. As equipes possuem autonomia para aplicar técnicas
e métodos que permitam verificar e melhorar seu desempenho com o passar do tempo.
Na equipe A existem oito colaboradores atualmente. O entrevistado atua há dezoito
anos na empresa, hoje exerce a função de analista de negócios e coordenação da equipe. As
atividades relacionadas a metodologia de desenvolvimento da equipe são definidas em
conjunto da equipe, assim todos opinam na definição do processo.
A equipe B possui dezesseis colaboradores. O entrevistado desempenha a função de
gestor da manutenção e analista de sistemas. Ele é responsável pelas principais atividades
relacionadas ao desenvolvimento ágil dentro da equipe e trabalha na empresa há seis anos.
Na equipe C trabalham vinte e um colaboradores. A pessoa entrevistada ocupa o
cargo de gestor de projetos e trabalha na empresa há um ano e três meses, é responsável pelas
atividades de planejamento e acompanhamento dos projetos.
38
No primeiro momento são apresentadas as informações a respeito da utilização das
metodologias ágeis pelas equipes e logo após sobre a utilização de métricas e indicadores.
Desta forma é contextualizado o processo de desenvolvimento adotado pelas equipes,
permitindo a análise e proposta de melhorias.
5.2 O PROCESSO DE DESENVOLVIMENTO DA EMPRESA
A pesquisa realizada busca compreender o processo de desenvolvimento de software
utilizado por cada equipe e como os métodos ágeis são adotados neste processo. Esta seção
apresenta os questionamentos (APÊNDICE A – Entrevista sobre métricas e indicadores de
projetos ágeis) realizados sobre a utilização dos métodos ágeis de desenvolvimento nas
equipes.
Os tópicos abordados no questionário tratam de quais métodos ágeis são aplicados na
equipe, quais reuniões são realizadas durante o processo de desenvolvimento, como
funcionam as iterações e estimativas, e quais ferramentas são utilizadas para auxiliar este
processo.
Quando questionado sobre a adoção dos métodos ágeis, o entrevistado da equipe A
descreveu que a equipe utiliza técnicas do Scrum há mais de dois anos em seu processo de
desenvolvimento. São realizadas iterações com tempo fixo de quinze dias. Em relação as
reuniões, a equipe pratica uma reunião de planejamento de Sprint, onde todos os membros da
equipe reúnem-se para selecionar e estimar as atividades que serão desenvolvidas na próxima
Sprint, considerando que a priorização das demandas é feita pelo Analista de Negócios
atuando com o papel de Product Owner. Também são feitas reuniões diárias de
acompanhamento da Sprint com a participação da equipe inteira. Na equipe A, as estimativas
são realizadas em horas, que são traduzidas em pontos, por exemplo: duas horas possuem o
valor de um ponto, quatro horas valem dois pontos, quatro horas valem cinco pontos e assim
por diante. A ferramenta de acompanhamento das iterações é um quadro, onde estão dispostas
as atividades selecionadas para a Sprint em três divisórias: Na primeira estão as atividades
maiores referentes à entrega da Sprint, a segunda as atividades menores serem desenvolvidas
e na terceira seção as atividades finalizadas.
39
Ao abordar sobre a utilização de métodos ágeis na equipe B, o entrevistado informou
que há dois anos a equipe utiliza o Scrum em combinação com o Kanban. A equipe trabalha
com iterações com tempo fixo de três semanas. Dos dezesseis integrantes, são selecionados
nove membros da equipe que participarão da iteração e divididos em três times, com três
integrantes cada. Dois times trabalham com desenvolvimento de novas funcionalidades e um
time realiza as correções de erros identificados no sistema.
A equipe trabalha com uma dinâmica de reuniões adaptada a seu contexto: Antes da
Sprint, são realizadas duas reuniões de planejamento. Na primeira reunião, o coordenador da
equipe, que faz o papel de Product Owner, seleciona as atividades do Backlog que serão
desenvolvidas na Sprint, os analistas de sistema responsáveis pela especificação, repassam a
regra de negócio e a documentação de cada atividade para os desenvolvedores responsáveis
pela codificação. A segunda reunião é realizada internamente em cada time, onde as
demandas são divididas em atividades menores, para que os integrantes realizem suas
estimativas por atividade. De acordo com o entrevistado, a estimativa é mensurada em pontos
Fibonacci. Para cada time, é realizada uma reunião diária de acompanhamento da Sprint com
o acompanhamento de um analista mentor, que auxilia nos problemas ou dúvidas do time, ele
não faz parte dos times. Quem ministra a reunião diária dos times é o gestor da manutenção.
Na retrospectiva da Sprint, são coletadas informações sobre problemas ocorridos no
decorrer da Sprint e discutidas alternativas para prevenir os riscos e imprevistos. As
ferramentas de acompanhamento para a gestão da Sprint envolvem uma planilha de Excel e o
quadro onde as atividades ficam dispostas em três níveis: o primeiro representa os itens da
entrega, o segundo nível contém as atividades menores a serem desenvolvidas dentro das
entregas e o ultimo nível representa as atividades finalizadas.
Na equipe C, o gestor de projetos descreveu que o processo de desenvolvimento
adota metodologias ágeis há dois anos, onde são aplicadas técnicas do Scrum e Kanban,
aliados ao TDD (Desenvolvimento Orientado por Testes). A equipe possui iterações com duas
semanas de duração. São realizadas reuniões de planejamento da Sprint e reuniões diárias
para acompanhamento. Ao termino da Sprint, analistas e programadores realizam uma revisão
informal, para discutir problemas que podem ter ocorrido no desenvolvimento das atividades.
A equipe estima em horas de desenvolvimento e utiliza como ferramenta de acompanhamento
dos projetos uma planilha de Excel.
40
Após análise dos dados obtidos nas entrevistas, foi possível identificar oportunidades
de melhoria dentro do processo de desenvolvimento de software das equipes. Com base
nestas oportunidades serão feitas sugestões focadas na realidade de cada uma das equipes,
objetivando um aumento na qualidade do processo de desenvolvimento adotado pelas
mesmas.
No que tange a respeito das metodologias empregadas na equipe A, foi observado a
ausência de um mentor focado na revisão e melhoria dos métodos de desenvolvimento
empregados. Schwaber e Sutherland (2011) relacionam esta responsabilidade ao papel do
Scrum Master, que tem o dever de garantir que a equipe esteja em conformidade com a teoria,
práticas e regras do Scrum. Foi identificado na equipe A, a ausência da reunião de revisão da
Sprint, que ainda de acordo com Schwaber e Sutherland (2011), possibilita verificar o
trabalho que está pronto e discutir os problemas ocorridos dentro da iteração, identificando
maneiras de lidar com futuros contratempos nas próximas Sprints.
Considerando as abordagens empregadas pela equipe B, percebeu-se que o método
empregado na realização de duas reuniões de planejamento da Sprint corresponde aos
conceitos apresentados por Schwaber e Sutherland (2011) quanto à reunião de planejamento
da Sprint. A primeira reunião de planejamento permite detalhar a resposta da primeira questão
para a seleção do plano de entrega da Sprint: Quais itens do backlog do produto serão
entregues como resultado do incremento da próxima Sprint? Na segunda reunião realizada
dentro dos times de desenvolvimento, é respondida a segunda questão proposta por Schwaber
e Sutherland (2011), tornando o planejamento detalhado: Como o trabalho deve ser executado
para entregar o incremento? A segunda reunião, ainda permite a divisão do trabalho, que
Kniberg (2009) aconselha dividi-lo em uma lista de pequenas funcionalidades que podem ser
entregues.
O estudo sugere que as técnicas e reuniões de planejamento das Sprints utilizadas na
equipe B, sejam adotadas nas equipes A e C. Isto permitirá que as equipes visualizem o
incremento de maneira íntegra, compreendendo a maneira que o trabalho será executado para
concluir as atividades planejadas para desenvolvimento na iteração.
Ficou compreendido que as equipes adaptam o quadro dentro de sua realidade,
empiricamente focada ao Scrum. O estudo sugere que, além das necessidades de
gerenciamento de iterações, seja adaptada uma nova seção nos quadros, ou adotado um novo
41
quadro, onde estariam dispostos os itens do backlog da release, não apenas as atividades
selecionadas para a iteração. Segundo Kniberg e Skarin (2010), esta prática permitirá que
gargalos tornem-se visíveis para toda a equipe em tempo real. Serão observadas
funcionalidades que não são trabalhadas, pontos para melhoria do sistema e possíveis falhas
de conhecimento da equipe em determinadas tecnologias ou áreas de conhecimento.
Nos seguintes tópicos, serão abordadas as métricas e indicadores adotados pelo
processo de desenvolvimento de software das equipes A, B e C.
5.3 AS MÉTRICAS E INDICADORES DA EMPRESA
Esta etapa da pesquisa buscou entender quais métricas e indicadores são utilizados
pelas equipes analisadas. Serão apresentados os resultados dos questionamentos (APÊNDICE
A – Entrevista sobre métricas e indicadores de projetos ágeis) sobre quais métricas e
indicadores são utilizados e suas finalidades, qual a frequência de atualização e quem é o
responsável pelos artefatos. Desta forma foi possível a realização de uma análise das métricas
e indicadores aplicados nas equipes, possibilitando a sugestão de melhorias a serem aplicadas.
Ao questionar o entrevistado da equipe A, sobre a utilização de métricas e
indicadores, foi relatado que o único indicador adotado é o gráfico Burndown, objetivando o
acompanhamento das Sprints na equipe. A atualização do gráfico é realizada diariamente, a
responsabilidade de mantê-lo atualizado é revezada entre os membros da equipe ao longo das
Sprints. A equipe demonstra interesse em aplicar métricas e indicadores que auxiliem na
evolução do processo de desenvolvimento de software.
A entrevista realizada na equipe B, demostrou a utilização de gráficos Burndown,
planilhas de controle de atendimentos por cliente e a comparação de horas
estimadas/realizadas como indicadores adotados. O gestor da manutenção é responsável pela
atualização das métricas e indicadores, suas divulgações são realizadas semanalmente. O
entrevistado informou que há necessidade de melhoria nos indicadores e suas técnicas de
aplicação, pois atualmente o processo de desenvolvimento adotado pela equipe não é
otimizado. Atualmente as ferramentas utilizadas para acompanhamento dos projetos, como o
Sistema de Atendimento ao Cliente (SAC), quadro de atividades e o Excel, não possuem
42
integração, assim a atualização do indicador é comprometida, pois deve ser realizada
manualmente em diversos locais.
O assunto também foi abordado junto ao entrevistado da equipe C, onde ficou
compreendida a utilização de indicadores focados a realidade da equipe. Os indicadores
adotados são planilhas de Excel contendo informações dos atendimentos no SAC, gráfico
Burndown, gráfico de esforço previsto/realizado e gráfico de porcentagem de esforço
empregado por cliente. Todos indicadores possuem a finalidade de acompanhamento dos
projetos. O indicador é atualizado diariamente pelo gestor de projetos e está disponível aos
colaboradores em uma página web da equipe. Os indicadores são revisados apenas em caso de
falhas na iteração, neste caso os problemas encontrados são discutidos pela equipe. O
entrevistado relatou o interesse na aplicação de novos indicadores, inclusive a equipe possui
uma série de indicadores preparados para aplicação. O principal problema relacionado a
aplicação de indicadores compreende a dificuldade na coleta e atualização dos dados nas
diversas ferramentas utilizadas para a gestão dos projetos.
Diversos artefatos foram coletados para análise de dados nas equipes entrevistadas.
A partir destes artefatos, torna-se possível o cálculo e aplicação de novos indicadores, que
possivelmente tragam benefícios para o processo de desenvolvimento de software empregado
nas equipes.
As seções abaixo apresentam os artefatos obtidos em cada equipe e as propostas de
melhoria sugeridas pelo estudo.
5.3.1 Burndown
Na equipe A, os gráficos Burndown apresentados, representam a evolução do total de
pontos estimados ao longo dos dias percorridos na iteração. A linha marcada em preto
demonstra a evolução planejada e a marcação em vermelho exibe o trabalho realizado. No
rodapé fica anotado o trabalho realizado não planejado, este é somado junto aos pontos dentro
da evolução do trabalho realizado (em vermelho) (Gráfico 1).
43
Gráfico 1 – Burndown Sprint 74 Equipe A
Fonte: Empresa XPTO (2013)
O gráfico Burndown apresentado pela equipe B exibe o trabalho total estimado
decrescendo ao longo da iteração. Em azul está representado o indicador que é adotado como
meta estimada para a equipe, chamado de evolução prevista. Em vermelho está representada a
evolução dos pontos concluídos ao longo da iteração (Gráfico 2).
Gráfico 2 – Burndown Sprint 1 Equipe B
Fonte: Empresa XPTO (2013)
O gestor de projetos da equipe C disponibilizou gráficos Burndown detalhados. Estes
gráficos possuem a representação do trabalho total estimado decrescendo ao longo dos dias
passados durante as iterações. Os itens em azul mostram a evolução prevista da Sprint em
horas, os itens em vermelho representam a evolução total realizada em horas trabalhadas e as
marcações em verde indicam se ocorreu imprevistos nos dias marcados a quantidade de
tempo consumida para lidar com o problema. Os itens não planejados são cadastrados em
44
uma tabela abaixo do gráfico, para controle e revisão dos problemas durante e após as
iterações (Gráfico 3).
Gráfico 3 – Burndown Sprint 1 Equipe C
Fonte: Empresa XPTO (2013)
Após análise dos gráficos Burndown, ficou compreendido que as equipes realizam a
atualização constante de seus gráficos. Seguindo as diretrizes de Velamakanni e
Sathianarayanan (2009), quando o gráfico Burndown é atualizado diariamente, as equipes
visualizam dados sobre precisão de estimativas, produtividade da equipe e controle de
processos. Porém, considera-se importante que os gráficos sejam verificados por toda equipe
ao final de cada iteração, na reunião de revisão da Sprint, isto possibilita a compreensão de
falhas na equipe e problemas que podem ser evitados nas próximas iterações.
5.3.2 Velocidade
Segundo a Agile Alliance (2013), a métrica é obtida a partir da quantidade de horas
ou pontos estimados que a equipe efetivamente trabalhou. Os dados obtidos com base nos
gráficos Burndown permitem identificar a velocidade da equipe ao final de cada iteração.
Como estudo, foi aplicado o cálculo da velocidade média diária, com base nas
informações obtidas na equipe A, ao longo das iterações 74, 75 e 76. O Gráfico 1 exibido no
item 5.3.1 representa que a velocidade da equipe A na iteração 74 foi de 157 pontos. O Anexo
45
A – Gráfico Burndown Sprint 75 Equipe A, demonstra que a velocidade da equipe A na
iteração 75 foi de 125 pontos. O gráfico do Anexo B – Gráfico Burndown Sprint 76 Equipe A,
mostra a velocidade de 112 pontos. As iterações estudadas possuem 9 dias (Sprint 74) e 8 dias
(Sprints 75 e 76). Para que as velocidades sejam comparáveis, é necessário normalizar a
medida pelo número de dias corridos em cada Sprint. Desta forma a velocidade diária da
equipe é de: 157 pontos / 9 dias = 17,5 pontos por dia na primeira iteração, 125 pontos / 8 dias
= 15,625 pontos por dia na segunda iteração e 112 pontos / 8 dias = 14 pontos por dia na
terceira iteração. Realizada a normalização, pode-se calcular a velocidade média diária da
equipe: 17,5 + 15,625 + 14 = 47,125 pontos / 3 iterações = 15,708 pontos por dia (Gráfico
4).
Gráfico 4 – Histórico da Velocidade na Equipe A
Fonte: O autor (2013)
O estudo considera importante a utilização e atualização do indicador de velocidade
em todas as equipes. Sato (2009), explica que ao conhecer sua velocidade, permite à equipe
conhecer seus limites e atingir os objetivos planejados de cada iteração.
46
5.3.3 Aceleração
Após a compreensão da aplicação do indicador de velocidade, é possível mensurar a
evolução das equipes ao longo das iterações. Este tópico aborda a utilização da aceleração
como indicador de produtividade das equipes.
Com base nos artefatos estudados nas equipes, identificou-se a possibilidade de
simular o cálculo da aceleração de uma equipe entre duas iterações. De acordo com a situação
de cada equipe e cada iteração, podem ser identificadas normalizações a serem realizadas para
promover um cálculo consistente da aceleração.
Os dados da velocidade da equipe A, calculados no tópico 5.3.2, permitem a
aplicação do indicador de aceleração. Conforme a formula do cálculo da aceleração
apresentada por Amber (2008), foi realizado o cálculo da aceleração da equipe entre as
Sprints 74 e 75: (15,625 pontos – 17,5 pontos) / 17,5 pontos = -0,10 ou -10%; E a
aceleração entre as Sprints 75 e 76: (14 pontos – 15,625 pontos) / 15,625 pontos = -0,10 ou 10%. Desta forma, é possível concluir que a cada iteração que passa, a equipe diminui sua
capacidade de entrega em 10%. Este cenário (Gráfico 5) indica que a equipe está sofrendo
com problemas e imprevistos comprometem o desempenho da equipe.
Gráfico 5 – Evolução da Aceleração Equipe A
Fonte: O autor (2013)
Amber (2008) indica que é possível monetizar o indicador: Supondo que a equipe A
gasta onze mil reais por iteração, e sua aceleração média entre as iterações 1, 2 e 3 foi de -
47
10%, é possível compreender que a equipe pode estar custando cerca de mil e cem reais a
mais, para entregar a mesma quantidade de trabalho em relação à iteração anterior.
O estudo conclui que o indicador de aceleração é meramente o sinal da variação da
velocidade da equipe ao longo do tempo. Sua aplicação deve ser estudada e adaptada à
contextos e objetivos específicos. Um exemplo de aplicação seria para verificar quais equipes
aumentaram/diminuíram sua capacidade de entrega nas ultimas iterações, possibilitando a
identificação e análise de problemas (nas equipes que diminuíram a capacidade) e soluções
(nas equipes que aumentaram a capacidade) dentro do processo de desenvolvimento adotado
pela empresa.
5.3.4 Cumulative Flow
O gráfico Cumulative Flow representa mudanças situacionais ocorridas nas
atividades ao longo de um projeto até entrega. Utilizando as informações disponíveis sobre a
equipe C, foi construído um diagrama do Cumulative Flow referenciando o desenvolvimento
do trabalho da Sprint 1 (Gráfico 3), Sprint 2 (Anexo C – Gráfico Burndown Sprint 2 Equipe
C) e Sprint 3 (Anexo D – Gráfico Burndown Sprint 3 Equipe C).
O trabalho total estimado das três Sprints foi 484 horas de esforço e isto representa o
“Backlog” da equipe C neste intervalo de tempo. No início de cada Sprint as atividades
referentes a ela entram no estado de “Em andamento”. Todo o esforço realizado dentro de
uma Sprint muda para o estado “Encerrado” ao final da iteração (Gráfico 6).
48
Gráfico 6 - Cumulative Flow Equipe C
Fonte: O autor (2013)
A análise do Gráfico 6 possibilitou compreender que a frequência de entrega das
atividades da equipe ocorre sempre ao final de cada Sprint, pois o gráfico foi criado após o
término do projeto analisado. Desta maneira não foi possível levantar as informações em
tempo de execução do projeto, cruciais para a construção deste artefato. Segundo a Agile
Sherpa (2010), entende-se que a utilização e atualização constante deste indicador ao longo de
um projeto exibirá em tempo real os impedimentos e as mudanças ocorridas no escopo do
projeto.
5.3.5 Lead Time
A Agile Aliance (2013) descreve que o lead time é o tempo percorrido entre a
identificação de um requisito até sua entrega efetiva. Para realizar o cálculo do lead time é
necessário levantar informações sobre o momento em que as solicitações das demandas
estudadas foram realizadas oficialmente pelos clientes para a empresa prestadora de serviços,
em seguida é necessário calcular quanto tempo corrido no processo de análise, no
desenvolvimento e nos testes de cada uma das demandas estudadas. Devido às dificuldades
49
que surgiram no levantamento das informações necessárias para sua simulação do lead time,
não foi possível calcular o indicador para as equipes estudadas na empresa XPTO.
Em um cenário ideal, este indicador seria obtido a partir de um sistema com foco na
gestão e acompanhamento de projetos, onde as informações necessárias para o cálculo dos
indicadores são coletadas automaticamente na entrada das demandas que a empresa ou o
cliente realiza na ferramenta.
5.3.6 Cycle Time
Segundo Sato (2009) para calcular o cycle time de uma atividade é preciso saber
quanto tempo levou a partir da sua ordem de implementação até o momento da entrega.
Segundo as informações estudadas, foi possível simular o cálculo do cycle time para
a equipe A. Consideramos o fato de que a ordem para a implementação efetiva das atividades
da equipe são denominadas ao início de cada iteração e ao final de cada iteração, as atividades
concluídas são entregues ao cliente. Desta forma, foi concluído que o cycle time da equipe é a
média dos dias trabalhados em cada iteração.
Os gráficos estudados mostram que a Sprint 74 (Gráfico 1) o Cycle Time foi de nove
dias, as Sprints 75 (Anexo A – Gráfico Burndown Sprint 75 Equipe A) e 76 (Anexo B –
Gráfico Burndown Sprint 76 Equipe A) o cycle time foi de oito dias em cada Sprint. Com
base nestes dados, o cycle time médio da equipe nas três iterações foi de 8,4 dias. De acordo
com Sato (2009), se conclui que este valor representa o quão rápido o processo de
desenvolvimento adotado pela equipe entrega valor de forma repetitiva e confiável.
50
6 CONCLUSÃO
Este trabalho objetivou um estudo de caso comparativo, na empresa de sistemas de
gestão XPTO. Com base na análise e compreensão, por meio de pesquisa exploratória, das
metodologias ágeis de desenvolvimento de software, métricas e os indicadores aplicáveis aos
projetos da empresa XPTO. Desta forma, foi adquirido conhecimento técnico para a
realização do estudo de caso, onde foram realizadas entrevistas e coleta de artefatos dentro
das equipes de desenvolvimento de software da empresa XPTO, buscando compreender o
processo de desenvolvimento de software, os indicadores e as métricas adotadas por elas. Os
artefatos coletados durante as entrevistas possibilitaram construir a comparativa das
metodologias ágeis, os indicadores e as métricas estudados previamente com o processo de
desenvolvimento, as métricas e os indicadores utilizados nas equipes de desenvolvimento de
software da empresa XPTO.
O estudo comparativo entre as metodologias ágeis dos frameworks Scrum e Kanban
e o processo de desenvolvimento utilizado pelas equipes da empresa XPTO, permitiu
entender a importância dos métodos ágeis na qualidade e melhoria continua do processo de
desenvolvimento de software. Assim foram sugeridas técnicas a serem adotadas dentro do
processo de desenvolvimento de software das equipes na empresa XPTO.
Entre os indicadores e métricas estudados são citados o gráfico Burndown, a
Aceleração, a Velocidade, o gráfico Cumulative Flow, o Lead Time e o Cycle Time.
Compreender estes indicadores e métricas possibilitou a simulação de suas aplicações com
base em dados históricos obtidos nas pesquisas realizadas nas equipes da empresa XPTO. O
estudo notou a necessidade da aplicação de novos indicadores e métricas nas equipes, o que
pode tornar o ciclo de revisões e melhorias mais abrangente e otimizado dentro do processo
de desenvolvimento utilizado. Assim ficou compreendida a importância da adoção de dois
novos indicadores: o indicador de Velocidade, cujo objetivo é proporcionar que as equipes a
conheçam suas capacidades e limites para cada iteração; E o gráfico Cumulative Flow, que
permite visualizar a frequência de entrega das atividades das equipes e quando ocorrem
impedimentos ou mudanças de escopo no projeto.
51
Com base nas dificuldades ocorridas ao longo deste trabalho, foi percebido que no
caso da falta de insumos para suas aplicações, haverá necessidade da realização de esforços
específicos para a adoção de novas abordagens dentro do processo de desenvolvimento das
equipes. Entende-se que a aplicação de novas técnicas para mensurar, avaliar e revisar o
processo de desenvolvimento de software utilizado por uma equipe deve ser analisada no
quesito da viabilidade. Novos métodos e técnicas podem tornar o processo de
desenvolvimento da equipe oneroso e burocrático, se não forem devidamente avaliados e
compreendidos, pois podem exigir que recursos humanos e tecnológicos estejam focados
exclusivamente nestes assuntos.
O cenário estudado mostrou que as equipes da empresa XPTO utilizam técnicas e
métodos de desenvolvimento de software distintos entre si. Isto evidencia que mesmo em
empresas com processos padronizados, é possível que existam diferentes culturas e
abordagens relacionadas ao desenvolvimento de software dentro da mesma corporação.
Visando trabalhos futuros, este estudo de caso pode ser utilizado como base na
adoção das metodologias ágeis estudadas em projetos de desenvolvimento de software de
uma empresa, utilizando as métricas e indicadores propostas nos procedimentos de qualidade
e revisão realizados pelas equipes. Este trabalho dá abertura para a incorporação de novas
métricas e indicadores a serem utilizados junto aos propostos por ele, como também a
utilização de uma ferramenta especializada em gestão e acompanhamento de projetos. A
utilização de uma ferramenta pode possibilitar que a aplicação de métricas e indicadores seja
realizada de maneira transparente e automatizada, pois as informações necessárias para o
cálculo das métricas e indicadores são coletadas automaticamente na entrada das informações
de atividades e demandas que a empresa e o cliente realizam na ferramenta.
52
REFERÊNCIAS
AGILE ALIANCE (Org). Kanban [Periodico na internet]. Disponível em:
<http://guide.agilealliance.org/guide/kanban.html>. Acesso em: 5 maio 2013.
AGILE ALLIANCE (Org.). Lead Time. Disponível em:
<http://guide.agilealliance.org/guide/leadtime.html>. Acesso em: 10 maio 2013.
AGILE ALLIANCE (Org.). Velocity. Disponível em:
<http://guide.agilealliance.org/guide/velocity.html>. Acesso em: 10 maio 2013.
AGILE SHERPA (Org.). Cumulative Flow. Disponível em:
<http://www.agilesherpa.org/agile_coach/metrics/cumulative_flow/>. Acesso em: 04 ago.
2010.
AMBLER, Scott. Acceleration: An Agile Productivity Measure. Disponível em:
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/metric_accele
ration?lang=en>. Acesso em: 28 abr. 2013.
BARROS, Aidil Jesus da Silveira; LEHFELD, Neide Aparecida de Souza. Fundamentos de
Metodologia Científica. 3. ed. São Paulo: Pearson, 2007.
BECK, Kent; BEEDLE, Mike; BENNEKUM, Arie van; COCKBURN, Alistair;
CUNNINGHAM, Ward; FOWLER, Martin; GRENNING, James; HIGHSMITH, Jim;
HUNT, Andrew; JEFFRIES, Ron; KERN, Jon; MARICK, Brian; MARTIN, Robert C. ;
MELLOR, Steve; SCHWABER, Ken; SUTHERLAND, Jeff; THOMAS, Dave. Manifesto
para Desenvolvimento Ágil de Software. Disponível em:
http://www.agilemanifesto.org/iso/ptbr/. Acesso em: 28 abr. 2013.
53
BOURNE, Lynda. Who is a Stakeholder? Disponível em:
<http://blogs.pmi.org/blog/voices_on_project_management/2009/09/who-is-astakeholder.html>. Acesso em: 22 set. 2009.
COHN, Mike. Agile estimating and planning. New Jersey: Prentice Hall, 2006.
COHN, Mike. What is Scrum Methodology? Disponível em:
<http://www.mountaingoatsoftware.com/topics/scrum>. Acesso em: 30 abr. 2013.
FRENCH SCRUM USER GROUP (Org.). Burndown charts. Disponível em:
<http://www.frenchsug.org/display/FRSUG/Burndown+charts>. Acesso em: 23 maio 2013.
IMPROVE IT (Org.). Manifesto Ágil. Disponível em:
<http://improveit.com.br/xp/manifesto_agil>. Acesso em: 28 abr. 2013.
KNIBERG, Henrik. Kanban. Disponível em: <http://www.crisp.se/gratis-material-ochguider/kanban>. Acesso em: 5 maio 2013.
KNIBERG, Henrik. Scrum vs Kanban. Disponível em: <http://www.crisp.se/fileuploads/Kanban-vs-Scrum.pdf>. Acesso em: 30 abr. 2013.
KNIBERG, Henrik; SKARIN, Mattias. Kanban and Scrum: making the most of both.
Estados Unidos: InfoQueue, 2010.
KOCUREK, Dusan. Understanding the Scrum Burndown Chart. Disponível em:
<http://www.methodsandtools.com/archive/scrumburndown.php>. Acesso em: 2011.
LANKEY, Lori. How to Improve Project Cycle Time. Disponível em:
<http://www.isixsigma.com/methodology/project-management/how-to-improve-projectcycle-time/>. Acesso em: 16 jan. 2012.
LEAN (Org.). Lean Thinking (Mentalidade Enxuta). Disponível em:
<http://www.lean.org.br/o_que_e.aspx>. Acesso em: 02 jun. 2013.
54
MOUNTAIN GOAT SOFTWARE (Org.). Agile Burn Chart - Release Burndown Charts.
Disponível em: <http://www.mountaingoatsoftware.com/scrum/release-burndown/>. Acesso
em: 23 maio 2013.
MOUNTAIN GOAT SOFTWARE (Org.). Scrum. Disponível em:
<http://www.mountaingoatsoftware.com/system/asset/file/27/scrum1600x1200.png>. Acesso
em: 03 jun. 2013.
PRESSMAN, Roger S. Engenharia de Software, / Roger S. Pressman ; tradução José Carlos
Barbosa dos Santos ; revisão técnica José Carlos Maldonado, Paulo Cesar Masiero, Rosely
Sanches. São Paulo: Pearson Makron Books, 1995.
ROOCK, Stefan. Kanban: Definition of Lead Time and Cycle Time. Disponível em: <
http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycletime/>. Acesso em: 23 maio 2013.
SATO, Danilo Toshiaki. Métricas de acompanhamento para metodologias ágeis.
Engenharia de Software Magazine, v. 12, 2009.
SCHWABER, Ken; SUTHERLAND, Jeff. O Guia do Scrum. Disponível em:
<http://www.fabiocruz.com/wp-content/uploads/2012/01/Scrum_Guide_2011-PortugueseBR-Version-Scrum-org.pdf>. Acesso em: 30 abr. 2013.
SHORE, James. How To Be Agile. Disponível em: <http://www.jamesshore.com/AgileBook/how_to_be_agile.html>. Acesso em: 30 abr. 2013.
SHORE, James; WARDEN, Shane. A arte do desenvolvimento ágil. Rio de Janeiro: Alta
Books, 2008.
SILVA, Helen de Castro; CASARIN, Samuel José. Pesquisa Científica: da teoria à prática.
Curitiba: Ibpex, 2011.
55
SOMMERVILLE, Ian. Engenharia de Software, 8ª edição / Ian Sommerville; tradução:
Selma Shin Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa; revisão
técnica Kechi Kirama. –8. ed. – São Paulo : Pearson Addison-Wesley, 2007.
TERRIBILI FILHO, Armando. Indicadores de Gerenciamento de Projetos. Monitoração
Contínua/ Armando Terribili Filho. São Paulo : M. Books do Brasil Ltda., 2010.
VELAMAKANNI, Bharadwaj; SATHIANARAYANAN, Ramanathan. Burndown Analysis
for Managing Productivity & Schedules. Disponível em:
<http://www.infoq.com/articles/burndown-analysis>. Acesso em: 15 set. 2009.
VERSION ONE (Org.). 7th Annual State Of Agile Development Survey. Disponível em:
<http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf>.
Acesso em: 01 maio 2013.
VERSION ONE (Org.). Measuring the Velocity of your Scrum Team. Disponível em:
<http://www.versionone.com/Agile101/Agile-Scrum-Velocity/>. Acesso em: 23 maio 2013.
VITOR, Paulo. Cálculo do lead time em user stories. Disponível em:
<http://www.infoq.com/br/articles/lead-time-user-stories>. Acesso em: 23 abr. 2010.
YOSHIMA, Rodrigo. O Cumulative Flow Diagram. Disponível em:
<http://blog.aspercom.com.br/2012/04/03/cumulative-flow-diagram/>. Acesso em: 23 maio
2013.
56
APÊNDICES
APÊNDICE A – ENTREVISTA SOBRE MÉTRICAS E INDICADORES DE PROJETOS
ÁGEIS
Dados pessoais
Nome:
Papel:
Tempo de empresa:
Dados da equipe
Nome:
Número de colaboradores:
Gestão de Projetos
1) Quais são as metodologias utilizadas na gestão dos projetos da equipe? São
utilizadas há quanto tempo?
2) Quais são as reuniões (cerimonias) realizadas? Quem são os participantes
(envolvidos)?
3) São feitas sprints (iterações)? Qual o tamanho?
4) Como são realizadas as estimativas?
5) É utilizada alguma ferramenta para o acompanhamento (gestão) do projeto?
Métricas e Indicadores
1) Quais métricas e indicadores são utilizados e qual sua finalidade?
2) Qual a frequência e quem faz a atualização da métrica?
3) As métricas são utilizadas no encerramento da iteração? Qual a visibilidade para a
equipe?
57
4) A equipe tem interesse em aplicar novos indicadores? Em que isto agregaria?
ANEXOS
ANEXO A – GRÁFICO BURNDOWN SPRINT 75 EQUIPE A
ANEXO B – GRÁFICO BURNDOWN SPRINT 76 EQUIPE A
58
ANEXO C – GRÁFICO BURNDOWN SPRINT 2 EQUIPE C
ANEXO D – GRÁFICO BURNDOWN SPRINT 3 EQUIPE C