1 / 34

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

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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)

  2. “...estimar é uma arte das melhores...” K. Beck e M. Fowler

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

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

  5. Contexto Desafio da previsibilidade de projetos de software: Fonte: StandishGroup (2001) Um ponto-chave sobre estes dados: “Estimativa”

  6. Estimativa • Uma estimativa é um cálculo aproximado sobre algum fenômeno

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

  8. Objetivo

  9. 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)

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

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

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

  13. Técnicas de estimativa ágeis • Dia Ideal • Pontos de estória do usuário • PlanningPoker

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

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

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

  17. PlanningPoker • O objetivo é evitar que a estimativa seja “manipulada” por uma pessoa • Estudos de Haugen (2006) mostram uma melhora na eficiência das estimativas

  18. 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."

  19. Visão geral do Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  34. 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)

More Related