Agilidade com Pontos de Função é um Paradoxo? Agile Brazil 2015

522 visualizações

Publicada em

Existem contextos, como nas contratações do Serviço Público ou de governança restritiva, em que técnicas como Pontos de Função podem garantir a sustentabilidade sem ferir a agilidade? Reflexão sobre o uso de técnicas paramétricas de estimativa em contratos ágeis a partir da observação de um processo de fábrica de software no qual já foram realizados mais do que 20 projetos em mais de 100.000 horas de trabalho, em diferentes clientes. No processo apresentado a técnica de Pontos de Função é utilizada para controle do projeto a nível contratual, ficando a cargo de cada time do projeto estabelecer sua forma de trabalho no planejamento das releases e iterações. A sustentabilidade é encontrada pela necessária dissociação entre as métricas em cada um destes níveis.

Publicada em: Software
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
522
No SlideShare
0
A partir de incorporações
0
Número de incorporações
12
Ações
Compartilhamentos
0
Downloads
7
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Agilidade com Pontos de Função é um Paradoxo? Agile Brazil 2015

  1. 1. Agilidade com Pontos de Função é um paradoxo? Outubro/2015 Eduardo Meira Peres
  2. 2. Detalhamento antecipado dos requistos não diminui os riscos, e oportunidades não aproveitadas... 1.000 + 1.500 500 change requests Contexto O mito da estimativa perfeita 1.000
  3. 3. O mito da estimativa perfeita Seria a procura da resposta certa para a pergunta errada?
  4. 4. Não é viável encontrarmos [cedo] estimativas para requisitos de software com acurácia para [certos] projetos. Estimativa Cliente Estimativas viram compromissos... Compromisso Estimatrix
  5. 5. ...que às vezes não são cumpridos.
  6. 6. Podemos definir estimativas para suportar a execução de projetos através de ciclos curtos de entregas, feedback e mudanças. Uma alternativa Paradoxo do barco de Teseu 1.000 1.000 O que o cliente pediu O que o cliente realmente necessita, em um ambiente de negócios que requer design
  7. 7. Aprendizado em um caso real 9 hrs/pt Licitação Pública Contrato de 15.000 pontos de função | 3 anos Até aqui: 40.000 horas trabalhadas | 17 meses Pico de 30 pessoas
  8. 8. Quando utilizamos métodos ágeis temos que evitar tudo o que restringe a adaptabilidade. Regra de Ouro
  9. 9. Modelos paramétricos originalmente criados para abordagens preditivas podem ser integrados a métodos ágeis para sem restringir sua natureza adaptativa. medir objetivamente valor entregue apoiar estimativas orçamentárias planejar e controlar iterações viabilizar governança corporativa O que Porque Como Quem Quand o Onde Quanto
  10. 10. Paradoxo da Agilidade com Pontos de Função Engajamento, Flexibilidade, Transparência diária, Autonomia. Produtividade, Custos, Densidade de defeitos, Previsibilidade, Governança, Taxa de entrega. Um olhar para fora e um para dentro O quê?
  11. 11. Pontos de Função podem ser utilizados no apoio à tomada de decisão para previsões orçamentárias. Olhar para Fora Expectimativas Contagem Estimada Expectativas Contagem Detalhada Final Expectimativa: Alinhamento das expectativas do cliente em relação às estimativas. +25% -10%
  12. 12. Olhar para Fora Pontos de Função podem ser utilizados como métrica para remuneração e gestão de contratos.
  13. 13. Olhar para Dentro Pontos de Função NÃO devem ser utilizados para orientar o planejamento interno à iteração. Negociação orientada a pontos de função Contagem de pontos de função no início da sprint
  14. 14. Sprints de 1 mês Time reduzido Pontos de Função & Story Points Projeto SPJ Projeto ASCPontos de Função (9,22 hrs/PF) Story Points (5 hrs/SP) Pontos de Função (9,02 hrs/PF) Story Points 12 hrs/SP)
  15. 15. Algumas organizações necessitam planejar e aferir o trabalho realizado através de critérios objetivos. Precisamos reduzir o overhead emocional e de esforço na realização de estimativas. Métricas objetivas não substituem relações de confiança. O que Porque Como Quem Quando Onde Quanto
  16. 16. Mínimo Release VIável Excesso Sobra Features Trade-offs Constantes O que Porque Como Quem Quando Onde Quanto
  17. 17. Gestão do Backlog da Release Estimativa orçamentária 884 pontos entregues O compromisso não é com uma lista de requisitos de software, mas com objetivos de negócio.
  18. 18. Estimativa orçamentária inicial: 855 pontos de função Backlog na sprint 12 (607+470): 1.077 pontos (+26%) Questão analisada: Restringir o escopo? Decisão: Manter aumento de tamanho em até 25% Situação do projeto na sprint 12 de 22 Gestão do Backlog da Release Resultado real ao final da sprint 22: 25%
  19. 19. sprint 1 sprint 2 sprint 3 sprint 4Pre- game postgame Backlog do Produto Fluxo de Trabalho do Contrato Contagem sprint 1 Pagamento sprint 1 Contagem Backlog (estimada)
  20. 20. Pregame = Contagem Estimada Remuneração do Pre-game - 10% da contagem estimada (mínimo 4 pontos de função) Resultado do Pregame - Backlog inicial do produto - Visão e plano da release - Contagem estimada + reserva (20%) Contagem detalhada = documentação detalhada = mindset preditivo
  21. 21. sprint 1Pre- game Backlog do Produto Game Pontos de função detalhados Pontos de função estimados Story Points ou o que o time decidir #NoEstimates
  22. 22. Como Gerenciar as Mudanças? Meus pais “tipo confiam” em mim, preciso estar em casa até a meia noite.
  23. 23. Impacto das Mudanças Após a sprint - 0,25 (mudança planejada) - 0,50 (mudança não planejada) Dentro da sprint - 10% de buffer - Acima é remunerado Retrabalho tem custo + Feedback, - Desperdício, + Envolvimento... Retrabalho é ruim?
  24. 24. Impacto das Mudanças Contar funcionalidades englobadas em mais de uma sprint apenas ao final? - Influencia decisões de projeto e afeta adaptabilidade - Estimula conflito por mais pontos, menos pontos Fornecedor: postergar mudanças, Cliente: antecipar mudanças. Mudanças dentro da release não devem ser remuneradas? - Estariam dentro da evolução prevista de requisitos (preditivo?) Não existe mudança sem custo - Deixar o processo adaptativo fluir - Reconhecer e valorizar a mudança - Sem mudança é mais caro!
  25. 25. Escopo planejado Mudanças Mudanças planejadas 63% a 72% Métricas de Mudanças 27% a 37% 0% a 1%
  26. 26. O que Porque Como Quem Quando Onde Quanto Necessário equipe especializada, em ambos os lados. Realização de contagem em conjunto pelo especialista e analista de negócios. Capacitar os analistas de negócios e sistemas para realizar contagens. O time de desenvolvimento e testes não precisa envolver-se com pontos de função.
  27. 27. O que Porque Como Quem Quando Onde Quanto Estimativa orçamentária após a visão (PreGame). Contagem detalhada ao final das sprints. Realizar contagens no início das sprints, aceite de requisitos,... Tentar o detalhamento antecipado dos requisitos. Evitar o encaminhamento de requisitos em definição para não emergirem muitas mudanças.
  28. 28. O que Porque Como Quem Quando Onde Quanto Pode ser realizada em grande parte a distância. Atividades presenciais são importantes para refinamento, esclarecimentos e desenvolvimento das relações de confiança.
  29. 29. O que Porque Como Quem Quando Onde Quanto Esforço médio para contagem + reunião de validação: 1 iteração de 50 pontos (2 semanas) = 8 hrs 1,5% do esforço do projeto Evitar orientação econômica dentro da iteração Desvios devem ser analisados e passíveis de acordo Preserva equipe de desenvolvimento custo financeiro e custo emocional
  30. 30. eduardop@dbserver.com.br

×