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

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)