Estimar ou #NoEstimates
•Télécharger en tant que PPTX, PDF•
0 j'aime•116 vues
O documento discute as abordagens de estimativas ágeis versus #NoEstimates. Apresenta os problemas com estimativas tradicionais, como serem feitas cedo demais e por pessoas erradas, e raramente serem atualizadas. Também discute como as estimativas causam pressão desnecessária e podem levar a equipes abandonarem bons processos. As estimativas ágeis usam pontos de história e Planning Poker para estimar o esforço de forma relativa em vez de prazos absolutos. #NoEstimates sugere reduzir a ê
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Estimar ou #NoEstimates
Similaire à Estimar ou #NoEstimates (20)
Plus de José A. Rodrigues Nt.
Plus de José A. Rodrigues Nt. (11)
Estimar ou #NoEstimates
- 1. Estimar ou #NoEstimates 18º Rio Agile Beer – Stefanini 2018 José Rodrigues – ScrumHalf Agile Manager
- 2. Sumário • Introdução • Estimativa Ágil • #NoEstimates • Conclusão
- 3. Sobre Estimativas em Software • A maioria das estimativas de software é feita no início do ciclo de vida. Isso faz sentido até percebermos que ocorre antes da análise de requisitos, quando entendemos o problema. Ou seja, estimativas são normalmente feitas fora de hora. • A maioria das estimativas é feita pela alta gerência ou pelo marketing, não pelas pessoas que irão construir o software ou seus gerentes. Assim, as estimativas são feitas pelas pessoas erradas. • Raramente estimativas são refeitas com o progresso do projeto. Dessa forma, essas estimativas feitas pelas pessoas erradas e na hora errada normalmente também estão erradas. • Como as estimativas são muito incorretas, não faz sentido se preocupar quando o projeto não respeita custos e prazos. Mas todos sempre se preocupam! • Pressão para atingir as metas estimadas é grande e faz com que programadores deixem de seguir um bom processo de software. Isso é um resultado absurdo causado por um motivo absurdo. Robert Glass
- 4. Estimar porque? • Prever custos • Prever prazos • Descobrir dependências • Melhorar entendimento • Definir escopo • Planejar capacidade
- 5. Para que não serve? • Determinar coisas de forma precisa • Estabelecer desafios • Fundamentar cobranças • Curar falta de comprometimento • Estabelecer confiança
- 6. Se não vai usar para tomar decisão, não estime • Essa história deve ser feita agora ou não? • O que conseguirei para a próxima entrega? • Qual o custo dessa feature? • Até quando poderei contar com a minha equipe para fazer algo, se alguém tem data para sair?
- 7. Estimativa Ágil • Mais comum • Pontos de História • Planning Poker
- 8. Estimando Product Backlog • Pontuar, quantificar o esforço necessário para implementar uma história. • Scrum foca em tamanho e não em duração
- 9. www.scrumhalf.com.br • Técnica para estimar histórias • Equipe trabalha na estimativa com a ajuda do Scrum Master • Usamos cartas com a seguinte pontuação: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 e ? Planning Poker
- 10. Fibonacci Modificado • Derivado do Delphi • Escala Linear resultado pior • Evitar proporções exatas • Está na Natureza
- 11. #NoEstimates
Notes de l'éditeur
- Prever custos Prever prazos Descobrir dependências Melhorar entendimento Definir escopo Planejar capacidade
- Alguns acham que pode haver outras formas de tomar decisão sem estimar. Eu já acho que você pode arrumar outras formas de estimar. Quando olhamos o movimento #NoEstimates, que busca outras formas de auxiliar na tomada de decisão, percebemos que o caminho de dividir o trabalho em pequenos pedaços iguais, não deixa de ser isso. Ao invés de “contarmos” quanto será fazer um determinado trabalho, “contamos” quantos pedaços de trabalho padrão deverão ser feitos.
- Para o primeiro planning poker a equipe deve avaliar todas as histórias do product backlog que estão mais detalhadas e preparadas para comporem sprints e escolher, de comum acordo, a que é mais simples, que demanda menos trabalho para ser concluida. Essa história será pontuada com 2 pontos e servirá de referência para comparação e pontuação das demais. Para cada história a equipe, após discutir o problema, joga a carta que acredita representar o esforço necessário para desenvolver a história Caso não haja concordância, discuti-se mais e joga-se de novo A estimativa deve ser encontrada por unanimidade Há discordâncias sobre a abordagem da unanimidade.
- Estimar não traz valor. Procurar alternativas para estimação. Contar histórias, não medir historias. Dividir em pequenos pedaços. Usar só 1,2 e 3 pontos. Ou toda história valer 1. Esses pedaços podem ser orientados a timeboxes. P. ex., minha história padrão terá sempre que ser feita em 3 dias.
- Quando o #NoEstimates reduz o tamanho das atividades para tamanhos bem pequenos, o foco é no trabalho a ser executado. No processo de construção. Na tecnologia. Quando na Estimativa Ágil procuramos estimar histórias como contadas pelo usuário, procuramos o entendimento mútuo, a concordância. Focamos no “O Quê”. Assim, o #NoEstimates tenta reduzir a dificuldade de estimar atando no tamanho do que deve ser estimado. Enquanto a estimativa ágil foca no melhor entendimento do que deve ser estimado. Analogia das pedras: Preciso carregar um ou mais blocos de pedra grandes. Um caminho é calcular quantos homens preciso para carregar cada bloco. Outra forma é quebrar os blocos em pedaços pequenos, todos carregáveis, e depois remonta-los. Stacey Matrix (Ralph Stacey, U. of Hertfordshire, UK) Cada um pode ser usado em um contexto. Dependendo da forma de trabalho, do conhecimento sobre a solução, do alinhamento com o cliente. Estimativa ágil ajuda muito no alinhamento. Em certas situações, #NoEstimates pode aumentar a predictabilidade do time. Mas se precisar algo além de curto prazo pode dificultar. Pessoal Kanban pode fazer bom uso. Buscamos valor aonde há valor.