Flávio Almeida Araújo Sobrinho ([email protected])
-
Upload
noble-osborne -
Category
Documents
-
view
37 -
download
0
description
Transcript of Flávio Almeida Araújo Sobrinho ([email protected])
![Page 1: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/1.jpg)
Uma proposta de melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum
Flávio Almeida Araújo Sobrinho([email protected])
![Page 2: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/2.jpg)
“...estimar é uma arte das melhores...”K. Beck e M. Fowler
![Page 3: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/3.jpg)
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
![Page 4: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/4.jpg)
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
![Page 5: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/5.jpg)
Contexto
Desafio da previsibilidade de projetos de software:
27% de projetos finalizados no tempo e custo previstos (2001)
50% dos projetos custaram em média 180% a mais (2001)
16% dos projetos foram bem sucedidos (1994)
Fonte: Standish Group (2001)
Um ponto-chave sobre estes dados: “Estimativa”
![Page 6: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/6.jpg)
Estimativa
• Uma estimativa é um cálculo aproximado sobre algum fenômeno
![Page 7: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/7.jpg)
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
![Page 8: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/8.jpg)
Objetivo
Propor uma melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum.
![Page 9: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/9.jpg)
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)
![Page 10: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/10.jpg)
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 International Function Point User
Group (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
![Page 11: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/11.jpg)
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
![Page 12: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/12.jpg)
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
![Page 13: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/13.jpg)
Técnicas de estimativa ágeis
• Dia Ideal• Pontos de estória do usuário• Planning Poker
![Page 14: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/14.jpg)
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
![Page 15: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/15.jpg)
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
![Page 16: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/16.jpg)
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
![Page 17: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/17.jpg)
Planning Poker
• O objetivo é evitar que a estimativa seja “manipulada” por uma pessoa
• Estudos de Haugen (2006) mostram uma melhora na eficiência das estimativas
![Page 18: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/18.jpg)
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."
![Page 19: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/19.jpg)
Visão geral do Scrum
![Page 20: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/20.jpg)
Processo de estimativa em Scrum
• Todo o Product Backlog é estimado– Pontos atribuídos através do Planning Poker– 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 Sprint Backlog– A partir do segundo Sprint a quantidade de pontos que
serão desenvolvidos no Sprint deve ser a mesma do Sprint anterior
![Page 21: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/21.jpg)
Proposta
Metodologia• Melhorias aqui apresentadas são fruto da
observação e estudo da metodologia Scrum ao longo de cerca de doze Sprints
• Um resultado empírico envolvendo a vivência do autor
![Page 22: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/22.jpg)
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
![Page 23: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/23.jpg)
Proposta
Melhoria 1: Pontos de estória e planning poker• Existem algumas variações de ponto de vista• Neste trabalho
– Os pontos serão aplicados em planejamento de Sprint e Realease
– Com planning poker– Porém os pontos terão uma unidade e o poker sofrerá uma
leve mudança
![Page 24: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/24.jpg)
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
![Page 25: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/25.jpg)
Proposta
Melhoria 3: Apenas uma rodada de planning poker• Três ordens de grandeza para estimativa (Hohman,
2005)• Aumentar a performance das reuniões de
planejamento
![Page 26: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/26.jpg)
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
VS = FAP x ∑homens-dia disponíveis no Sprint
FAP = ∑pontos concluídos / ∑homens-dia disponíveis
![Page 27: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/27.jpg)
Proposta (Resumo)
1. O time estima o Product Backlog em pontos de estória1. Os pontos de estória equivalem à unidade “Homens-dia”2. O número de pontos de uma estória representa quantos
“dias ideais” um homem trabalhando sozinho levaria para completá-la
3. É utilizado o planning poker 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
![Page 28: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/28.jpg)
Proposta (Resumo)
2. O Scrum Master instancia o Fator de Ajuste de Produtividade para o time do Sprint1. Caso seja o primeiro Sprint, pode-se usar qualquer valor.
Por exemplo, 0,72. Caso contrário, o FAP é calculado de acordo com a
velocidade do time no Sprint anterior
![Page 29: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/29.jpg)
Proposta (Resumo)
3. O Scrum Master calcula a velocidade do time para conclusão de estórias com base no FAP e no tamanho do Sprint
4. A equipe dá continuidade ao Sprint Planning, escolhendo as estórias que irão compor o Sprint com base na velocidade do time
![Page 30: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/30.jpg)
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
![Page 31: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/31.jpg)
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
![Page 32: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/32.jpg)
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
![Page 33: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/33.jpg)
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 of Scrum. Acesso em 27 de novembro de 2009, disponível em Mountain Goat 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.
•Standish Group. (2001). Chaos Report 2001. Acesso em 20 de novembro de 2009, disponível em The Standish Group International : http://www.standishgroup.com/chaos/introduction.pdf
![Page 34: Flávio Almeida Araújo Sobrinho (faas@cin.ufpe.br)](https://reader035.fdocument.pub/reader035/viewer/2022062408/568130c5550346895d96e58d/html5/thumbnails/34.jpg)
Uma proposta de melhoria no processo de estimativa de tamanho de software para projetos gerenciados por Scrum
Flávio Almeida Araújo Sobrinho([email protected])