slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br) PowerPoint Presentation
Download Presentation
Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)

Loading in 2 Seconds...

play fullscreen
1 / 34

Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br) - PowerPoint PPT Presentation


  • 142 Views
  • Uploaded on

Uma proposta de melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum. Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br). “...estimar é uma arte das melhores...” K. Beck e M. Fowler. Sobre. Flávio Almeida

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Uma proposta de melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum

Flávio Almeida Araújo Sobrinho

(faas@cin.ufpe.br)

sobre
Sobre...

Flávio Almeida

  • Estudante do 9º período de Ciência da Computação no CIn
  • Colaborador da Pitang / C.E.S.A.R.
  • Sócio da Proativa (incubada no Centro de Inovação Microsoft)
  • Participou de duas competições internacionais em 2009
    • Imagine Cup
    • I2P
  • Áreas de interesse: Eng. de Software, Gestão de Projetos e Scrum
motiva o
Motivação
  • Experiência pessoal com desenvolvimento de software e Scrum
  • Adaptação do Scrum à organização
  • Busca por Sprints mais controláveis
  • Entender a aplicação de técnicas tradicionais X ágeis para estimativa
contexto
Contexto

Desafio da previsibilidade de projetos de software:

Fonte: StandishGroup (2001)

Um ponto-chave sobre estes dados: “Estimativa”

estimativa
Estimativa
  • Uma estimativa é um cálculo aproximado sobre algum fenômeno
estimar tamanho de software
Estimar tamanho de software
  • Um dos mais intensos desafios da Engenharia de Software
  • É um passo fundamental para o andamento do projeto
    • Permite derivar esforço, tempo, custos...
  • O sucesso do projeto depende do nível de precisão das estimativas
t cnicas de estimativa tradicionais
Técnicas de estimativa tradicionais
  • A seguir, uma visão geral sobre
    • Análise de Pontos de Função (APF)
    • Pontos de Caso de Uso (PCU)
an lise de pontos de fun o apf
Análise de Pontos de Função (APF)
  • Desenvolvida em 1979 por Albrecht, trabalhando na IBM
    • Medir o sistema pela suas funcionalidades e não pelo volume de código
  • Em 1986, criado o InternationalFunctionPointUserGroup (IFPUG)
  • Norma ISO/IEC 20.926
    • Manual de contagem dos pontos
  • Uma das primeiras métricas a medir o tamanho do software com alguma precisão
an lise de pontos de fun o apf1
Análise de Pontos de Função (APF)
  • Os objetivos da APF, de acordo com a IFPUG, são:
    • Medir o que foi requisitado e recebido pelo usuário
    • Prover uma métrica para a qualidade e análise de produtividade
    • Estimar o tamanho do software independentemente da tecnologia
pontos de caso de uso pcu
Pontos de Caso de Uso (PCU)
  • Técnica para estimar tamanho de software baseada na APF
    • Resultado de uma tese de doutorado de Karner (1993)
  • Voltada para sistemas construídos com OO
    • Projetos orientados a objetos podem ser medidos diretamente através dos diagramas de casos de usos
  • Utilizada em empresas como, Rational e SUN
    • Mas, sem disponibilização de novas versões
t cnicas de estimativa geis
Técnicas de estimativa ágeis
  • Dia Ideal
  • Pontos de estória do usuário
  • PlanningPoker
dia ideal
Dia Ideal
  • Definido por K. Beck (1999) como “Ideal Engineering Time”
    • Tempo necessário para concluir uma estória do usuário “sem interrupções ou reuniões”
  • Os desenvolvedores fazem outras atividades durante o dia
    • Isso dificulta a estimativa real
  • Representa uma grandeza de tamanho, não de tempo de calendário
pontos de est ria
Pontos de Estória
  • Apresentada por M. Cohn (2004) procura sanar alguns problemas do Dia Ideal
    • Unidade arbitrária e indivisível relativa à complexidade
    • Mapeamento no tempo de calendário
  • Analogia entre estórias
    • Estórias semelhante recebem a mesma pontuação
  • Para evitar falsa precisão usar seqüências esparsas
pontos de est ria1
Pontos de Estória
  • A velocidade do Time pode ser medida em Pontos de Estória completados por iteração
  • Pode facilitar negociações com o cliente
    • Evita confusão de tempo ideal x tempo de calendário
planning poker
PlanningPoker
  • O objetivo é evitar que a estimativa seja “manipulada” por uma pessoa
  • Estudos de Haugen (2006) mostram uma melhora na eficiência das estimativas
vis o geral do scrum
Visão geral do Scrum
  • Segundo Schwaber (2004)Scrum é:
    • "... o mais perplexo e paradoxal processo para gerenciamento de projetos complexos. Porém, Scrum é  incrivelmente simples. [...] Scrum não é um processo prescritivo; ele não descreve o que fazer em cada circunstância. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo que irá acontecer."
processo de estimativa em scrum
Processo de estimativa em Scrum
  • Todo o ProductBacklog é estimado
    • Pontos atribuídos através do PlanningPoker
    • Procura-se a menor estória
    • As demais estórias são pontuadas por analogia
  • É selecionada um conjunto de estórias que irão compor o SprintBacklog
    • A partir do segundo Sprint a quantidade de pontos que serão desenvolvidos no Sprint deve ser a mesma do Sprint anterior
proposta
Proposta

Metodologia

  • Melhorias aqui apresentadas são fruto da observação e estudo da metodologia Scrumao longo de cerca de doze Sprints
  • Um resultado empírico envolvendo a vivência do autor
proposta1
Proposta

Organização

  • Pitang – empresa da qual o autor é colaborador
    • Sobre o projeto estudado
      • Em andamento
      • Estimado em cerca de R$ 2 milhões em dois anos
      • Possui 11 participantes
proposta2
Proposta

Melhoria 1: Pontos de estória e planningpoker

  • Existem algumas variações de ponto de vista
  • Neste trabalho
    • Os pontos serão aplicados em planejamento de Sprint e Realease
    • Com planningpoker
    • Porém os pontos terão uma unidade e o poker sofrerá uma leve mudança
proposta3
Proposta

Melhoria 2: Pontos de estória com uma unidade de medida

  • Utilizar a noção de Dia Ideal
    • Unidade: homens-dia
  • Conferir uma unidade “concreta” para medida
    • Percebida dificuldade dos desenvolvedores com medida abstrata
  • Alta rotatividade da equipe
    • Depreciação do fator histórico
proposta4
Proposta

Melhoria 3: Apenas uma rodada de planningpoker

  • Três ordens de grandeza para estimativa (Hohman, 2005)
  • Aumentar a performance das reuniões de planejamento
proposta5
Proposta

Melhoria 4: Velocidade do time e Fator de Ajuste da Produtividade

  • Fator de Ajuste da Produtividade (FAP) é o percentual de tempo útil da equipe
    • Varia no intervalo [0, 1]
  • Pode ser iniciado com um valor qualquer para o primeiro Sprint
proposta resumo
Proposta (Resumo)
  • O time estima o ProductBacklog em pontos de estória
    • Os pontos de estória equivalem à unidade “Homens-dia”
    • O número de pontos de uma estória representa quantos “dias ideais” um homem trabalhando sozinho levaria para completá-la
    • É utilizado o planningpoker para esse processo – só deverá ocorrer uma única rodada; caso a equipe não seja unânime nesta rodada, será efetuada a média aritmética entre a maior e menor estimativa
proposta resumo1
Proposta (Resumo)
  • O ScrumMaster instancia o Fator de Ajuste de Produtividade para o time do Sprint
    • Caso seja o primeiro Sprint, pode-se usar qualquer valor. Por exemplo, 0,7
    • Caso contrário, o FAP é calculado de acordo com a velocidade do time no Sprintanterior
proposta resumo2
Proposta (Resumo)
  • O ScrumMaster calcula a velocidade do time para conclusão de estórias com base no FAP e no tamanho do Sprint
  • A equipe dá continuidade ao SprintPlanning, escolhendo as estórias que irão compor o Sprint com base na velocidade do time
considera es finais
Considerações finais
  • O gerente ficou muito satisfeito com as mudanças
  • O time sentiu o Sprint mais transparente
  • Apesar de ter sido aplicado com equipe iniciante no projeto, os resultados foram excelentes
    • Um dos melhores Sprints
  • O segundo Sprint está em andamento
    • Somente aí teremos consolidação dos resultados
  • Ficou claro que o time estava com problemas de estimativa
considera es finais1
Considerações finais
  • Apresentada uma proposta de melhoria no processo de estimativa de tamanho de software para projetos que utilizam Scrum
  • Preenchidas necessidades que foram observadas no contexto específico
    • É possível que se aplique a outros contextos
    • Uma compilação das técnicas já utilizadas com algumas modificações
  • Técnicas mais tradicionais não se encaixam muito bem
    • Estimativas são feitas por uma única pessoa (em geral o gerente)
    • Requisitos mutantes
    • Alto custo gerencial
trabalhos futuros
Trabalhos futuros
  • Estudo de caso controlado com projetos implementando as indicações deste trabalho
    • Aperfeiçoar e sugerir um novo modelo para estimativas
  • Levantamento e categorização de projetos de software
    • Efetuar um mapeamento das metodologias de estimativa de tamanho para as categorias de projetos conhecidas
    • Sugerir um padrão para estimar software
refer ncias bibliogr ficas
Referências Bibliográficas
  • Albrecht, A. J. (1979). Measuring Applications Development Productivity. Proceedings of IBM Applications Development Join SHARE/GUIDE Symposium. Monterey, CA.
  • Beck, K. (1999). Extreme Programming Explained: Embrace Change (1 ed.). Addison-Wesley.
  • Cohn, M. (2002). An Overview ofScrum. Acesso em 27 de novembro de 2009, disponível em MountainGoat Software: http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum-january---in
  • Haugen, N. C. (2006). An Empirical Study of Using Planning Poker for User Story Estimation. Proceedings of the Conference on AGILE 2006 (pp. 23-34). Washington (DC): IEEE Computer Society. 
  • Hohman, M. M. (2005). Estimating in Actual Time. Proceedings of the Agile Development Conference. IEEE Computer Society.
  • Karner, G. (1993). Use Case Points - Resource Estimation for Objectory Projects.Thechnical Report, Objective Systems SF AB (Rational Software).
  • Schwaber, K. (2004). Agile Project Management with Scrum (1 ed.). Microsoft Press.
  • StandishGroup. (2001). ChaosReport 2001. Acesso em 20 de novembro de 2009, disponível em TheStandishGroupInternational : http://www.standishgroup.com/chaos/introduction.pdf
slide34

Uma proposta de melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum

Flávio Almeida Araújo Sobrinho

(faas@cin.ufpe.br)