SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL SENAI/SC - FLORIANÓPOLIS CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 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

2 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

3 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

4 Aos meus pais.

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

6 Insanidade: É fazer a mesma coisa repetidamente e esperar resultados diferentes. (ALBERT EINSTEIN)

7 OLIVEIRA, Vinicius Verardi Alves de. Indicadores De Projetos Ágeis Aplicados Em Uma Empresa De Software. Florianópolis, Trabalho de Conclusão de Curso - Curso Superior de Tecnologia em Analise e desenvolvimento de sistemas. Faculdade de Tecnologia do SENAI, Florianópolis, 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.

8 OLIVEIRA, Vinicius Verardi Alves de. Indicadores De Projetos Ágeis Aplicados Em Uma Empresa De Software. Florianópolis, Trabalho de Conclusão de Curso - Curso Superior de Tecnologia em Analise e desenvolvimento de sistemas. Faculdade de Tecnologia do SENAI, Florianópolis, 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.

9 LISTA DE FIGURAS Figura 1 Scrum Figura 2 Kanban Board Figura 3 - Medida Figura 4 - Métrica Figura 5 - Indicador Figura 6 - Sprint Burndown Figura 7 - Release Burndown Figura 8 - Velocidade Figura 9 - Aceleração Figura 10 - Cumulative Flow Figura 11 Calculo Lead Time Figura 12 SLA Figura 13 Cycle Time... 35

10 LISTA DE GRÁFICOS Gráfico 1 Burndown Sprint 74 Equipe A Gráfico 2 Burndown Sprint 1 Equipe B Gráfico 3 Burndown Sprint 1 Equipe C Gráfico 4 Histórico da Velocidade na Equipe A Gráfico 5 Evolução da Aceleração Equipe A Gráfico 6 - Cumulative Flow Equipe C... 48

11 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

12 SUMÁRIO 1 INTRODUÇÃO JUSTIFICATIVA OBJETIVOS Objetivo geral Objetivos específicos METODOLOGIAS ÁGEIS SCRUM Equipes Scrum Artefatos do Scrum Eventos Scrum Estimativas Scrum KANBAN MEDIDAS, MÉTRICAS E INDICADORES MEDIDAS E MÉTRICAS INDICADORES MÉTRICAS E INDICADORES ÁGEIS Burndown Velocidade Aceleração Cumulative Flow Lead Time Cycle Time PROCEDIMENTOS METODOLÓGICOS ESTUDO DE CASO A EMPRESA O PROCESSO DE DESENVOLVIMENTO DA EMPRESA AS MÉTRICAS E INDICADORES DA EMPRESA... 41

13 5.3.1 Burndown Velocidade Aceleração Cumulative Flow Lead Time Cycle Time CONCLUSÃO REFERÊNCIAS APÊNDICES APÊNDICE A ENTREVISTA SOBRE MÉTRICAS E INDICADORES DE PROJETOS ÁGEIS ANEXOS ANEXO A GRÁFICO BURNDOWN SPRINT 75 EQUIPE A ANEXO B GRÁFICO BURNDOWN SPRINT 76 EQUIPE A ANEXO C GRÁFICO BURNDOWN SPRINT 2 EQUIPE C ANEXO D GRÁFICO BURNDOWN SPRINT 3 EQUIPE C... 58

14 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 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 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 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 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 17 d) Maior qualidade; e) Maior satisfação dos stakeholders 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 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 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) 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 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 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 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 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 lean 2 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). maneira: Kniberg e Skarin (2010) definem o núcleo de trabalho do Kanban da seguinte 2 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).

22 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 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 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 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 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 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 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 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 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 30 Quando atualizado diariamente, o gráfico Burndown fornece dados sobre precisão de estimativas, produtividade da equipe, controle de processos (VELAMAKANNI; SATHIANARAYANAN, 2009) 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 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) 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 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, 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 representa que a velocidade da equipe A na iteração 74 foi de 157 pontos. O Anexo

45 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, = 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.