Gestão ágil de projetos

Apresentação em tema: "Gestão ágil de projetos"— Transcrição da apresentação:

1 Gestão ágil de projetos
Scrum Gestão ágil de projetos

2 Igor Macaúbas e Marcos Pereira

3 Metas para o treinamento
Metas para o seminário Explicar o que é Scrum Por que Scrum Mostrar que Scrum não é uma bala de prata Novo olhar sobre gestão de projetos

4 Veja Ouça Fale

5 “A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelo menos 50 anos. Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadas com a realidade, e são contra produtivas.” Peter Drucker ( )

6 53% custam o dobro do estimado
31% são cancelados 53% custam o dobro do estimado Apenas 16% são completados no prazo e custo estimados * dados do CHAOS report

7 Mas por que?

8 Requisitos e especificações incompletas
Falta de envolvimento do usuário Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos

9

10

11

12

13

14 Falhar é uma maneira muito forte de aprendizado, mas é preciso parar de apontar culpados

15 “Jogar a culpa dos problemas nas pessoas envolvidas é mais do que contra produtivo, é deixar uma situação ruim pior ainda.” Mary Poppendieck

16 Manifesto Ágil

17 Indivíduos e interação entre eles mais que processos e ferramentas

18 Software Funcionando mais que documentação abrangente

19 Colaboração mais que negociação de contratos

20 Responder às mudanças mais que seguir um plano

21 Olá, Scrum!

22

23 Scrum é um processo iterativo e incremental para desenvolvimento de produtos.

24 O objetivo é entregar o máximo de valor de negócio
O objetivo é entregar o máximo de valor de negócio* possível no menor tempo * Foco no ROI – Retorno de investimento

25 Scrum é também um meio de evidenciar os problemas
Scrum tenta deixar os problemas evidentes para percebermos que o projeto vai falhar. Ou, claro, corrigir os erros para que o projeto ande melhor.

26 Mas Scrum não é bala de prata*
* Não mata vampiros & afins * Exige trabalho duro e comprometimento

27 P D C A Plan, Do, Check, Act

28 Planejamento

29 Execução

30 Checagem

31 Retrospectiva e melhoria contínua

32 O processo não é avaliado enquanto está rodando
Para refletir depois de ações efetivas. Da reflexão vêm ações mais efetivas ainda. Drucker O processo não é avaliado enquanto está rodando

33 Ciclo Scrum

34 Tipos de Processos

35 “É típico adotar a abordagem de modelagem definida quando os mecanismos subjacentes pelos quais um processo opera são razoavelmente bem entendidos. Quando o processo é muito complexo para ser definido, a abordagem empírica é a escolha apropriada.” (Ogunnaike and Ray, Oxford University Press) Um modelo de processos definidos requer que cada parte do trabalho seja completamente bem entendido Dado um conjunto de entradas bem definidos, a mesma saída é gerada sempre.

36 Processo definido vs Processo empírico

37 Desenvolvimento de software não é um processo que gera as mesmas saídas para as mesmas entradas
Nós acreditamos que qualquer processo de desenvolvimento inserido em uma ambiente em mudança deve ser empírico, porque ele provê a melhor abordagem conhecida para se adaptar as mudanças.

38 Processos empíricos

39 Complexos, caóticos ou seus detalhes ainda não são conhecidos

40 Atividades podem ser cíclicas e tem duração com muitas variações

41 É difícil estimar tempos de execução

42

43 Fixar a maior quantidade possível de parâmetros

44 Parâmetros de contexto Parâmetros de entrada Parâmetros de saída
Tempo, Esforço, Time Parâmetros de entrada Backlog, Prioridades, Estimativas Parâmetros de saída Objetivos, Critérios de avaliação

45 Exatamente o que Scrum faz!
Aplique o PDCA para - Planejar as entradas - Trabalhar em um tempo fixo - Validar saídas Adicionar aprendizado para o próximo ciclo - Sprint Planning (Plan) - Sprint (Do) - Sprint Review (Check) - Sprint Retrospective (Act)

46 Timeboxing!

47 Ciclo Scrum Fonte:

48 Papéis e Responsabilidades

49 Fonte: http://www.implementingscrum.com

50 Scrum tem poucos papéis (não são cargos
Scrum tem poucos papéis (não são cargos!): Product Owner, Team, Scrum Master

51 Scrum Master* *Mãe, quando eu crescer, quero ser Scrum Master.

52 Trabalhar com o Product Owner
Cuidar do time Manter o processo funcionando Disseminar o Scrum Garantir comunicação

53 Product Owner* *Me dá, me dá, me dá, me dá!

54 Criar e compartilhar uma visão do projeto

55 Tomar decisões continuamente sobre os itens do product backlog

56 Escrever e priorizar itens de backlog

57 Validar software no final de cada Sprint

58 Estabelecer e manter o plano de entregas

59 Tomar decisões pensando no ROI do projeto
responsável pelo lucro

60 Time* *Tudo eu! Tudo eu!

61 Responsabilidades: Estimar itens do backlog
Se comprometer a entregar um incremento funcional de software Gerenciar o próprio progresso Auto organizados para entregar o que o PO quer As decisões de desenvolvimento são feitas pelo time. Ou seja, o time tem autoridade para fazer o que seja necessário para cumprir seus compromissos

62 Times Scrum

63 Como são compostos: Cross functional, sem papéis Multidisciplinares
Auto sustentáveis Todos os skills e habilidades necessárias para desenvolver o produto 7pessoas (mais ou menos 2)

64 Cerimônias de Scrum: Sprint Planning 1 Sprint Planning 2 Daily Scrum
Sprint Review Sprint Retrospective

65 Todas com timebox

66 Reunião de Estimativa:
Preparação para o Sprint Planning Estimar baseado no tamanho, nunca em tempo Atualizar Product Backlog com as estimativas Importante para o PO criar o release plan

67 Sprint Planning 1: Product Backlog Capacidade da equipe
Condições do Negócio Objetivos da Sprint Itens selecionados do backlog Aceite do time Revisa Considera Organiza

68 Sprint Planning 2: PO não precisa participar
É um planejamento tático da equipe Os itens selecionados do Product Backlog são destrinchados em tarefas Sprint Backlog

69 Daily Scrum: Deve responder as três perguntas:
O que fiz desde a ultima Daily Scrum? O que espero fazer até a próxima Daily Scrum? O que está impedindo o progresso? Impedimentos reportados aqui

70 Sprint Review: O que significa “pronto”?
Team deve ter um critério técnico para indicar o que significa pronto! Incrementos funcionais são apresentados ao Product Owner e interessados

71 Consequências do Review:
Estórias não concluídas voltam para o product backlog Atualizar Product Backlog para remover itens que a equipe implementou inadvertidamente Scrum Master trabalha para reformular a equipe

72 Consequências do Review:
Product Backlog é repriorizado para tomar vantagem dos incrementos apresentados Decidir se haverá ou não outra Sprint

73 Sprint Retrospectives

74 O que aprendizado é

75 O que aprendizado não é

76 Cometer os mesmos erros e esperar resultados diferentes

77 Aprender é desapontar expectativas, mas não procure culpados
O primeiro passo para aprender é respeitar o passado sem procurar culpados. As long as we blame someone or something for being the reason for our failure, we are not able to learn

78 Diretiva Primária

79 “Não importa o que descobrimos, nós entendemos e realmente acreditamos que cada um fez o melhor trabalho que pode considerando: O que era conhecido, suas habilidades, os recursos disponíveis e a situação no momento.” (Kerth, Project Retrospectives, 2001)

80 Passos para a Retrospectiva

81 Saídas da Retrospectiva:
Team Backlog (para ajustar o processo) Backlog de impedimentos (mudanças na empresa) Os backlogs devem ser ordenados por importância

82 Onde, Quando, Quem?

83 Quando as retrospectivas não funcionam

84 O facilitador controla demais a reunião

85 Little less conversation, more action, please

86 Conflito de interesses
O formato é muito repetitivo O facilitador não se prepara Itens de ação mal formulados

87 A Visão do Produto + Product Backlog
Planejamento Estratégico A Visão do Produto + Product Backlog

88 O que é estratégia? “O conceito de estratégia, em grego strateegia, em latim strategi, em francês stratégie...”

89 Plano de ação a longo prazo criado pra atingir um objetivo

90 Selected Backlog + Sprint Backlog
Planejamento Tático Selected Backlog + Sprint Backlog

91 Planejamento Tático é feito por Sprint

92 Em Scrum, as táticas são voláteis e de responsabilidade do time

93 O Product Backlog Emergente Priorizado e estimado
Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

94 O Product Backlog Priorizado e estimado Emergente
Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

95 O Product Backlog Maior prioridade, mais detalhes Emergente
Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

96 O Product Backlog Qualquer um pode contribuir Emergente
Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

97 O Product Backlog Priorização é tarefa do PO Emergente
Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

98 O Product Backlog Sempre visível Emergente Priorizado e estimado
Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

99 O Product Backlog Alinhado ao plano de negócios Emergente
Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

100 Escrevendo Estórias

101 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveis

102 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveis

103 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveis

104 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveisIndependentes

105 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveisIndependentesNegociáveis

106 TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveisIndependentesNegociáveis

107 Estórias com critérios de aceitação criam entendimento sobre quando a tarefa está pronta e ajudam o time a estimar e dividir a estória em tarefas

108

109 Scrum foca em tamanho e não em duração

110 Estimar em tamanho relativo é mais simples

111 Monitorando a Sprint

112 Sprint Burndown

113 Sprint Burn Up

114 Capacidade

115 Problemas comuns na adoção de Scrum

116 Product Owner pouco presente
Sem Visão Sem release plan Sem product backlog

117 Falta estimativa Falta priorização Falta acompanhamento
Product Backlog não é mantido Falta estimativa Falta priorização Falta acompanhamento

118 Se as cerimônias não acontecem
Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos

119 Sem retrospectivas Falta de uma maneira de melhorar o trabalho do time
Mesmos erros acontecem sempre Impedimentos não são removidos

120 Decomposição do trabalho
Planejamento a longo prazo Tempo para pesquisa e folga

121 O que é difícil em Scrum? Detalhes podem escapar se não
for gerenciado corretamente Criar e manter um Product Backlog requer trabalho

122 Resumo da ópera

123 É um embrulho para as práticas existentes de engenharia.
É um processo ágil para gerenciar e controlar trabalho. É um embrulho para as práticas existentes de engenharia. É uma aproximação coletiva, iterativa e incremental, onde requisitos mudam rapidamente.

124 Controla o caos de interesses e necessidades conflitantes.

125 obstáculos que entrem no
É uma forma de detectar e remover obstáculos que entrem no desenvolvimento e entregas

126 É melhorar a comunicação e
maximizar cooperação.

127 Não é uma metodologia completa
e com o carimbo de um fornecedor

128 Não é um ataque à documentação ou
às ferramentas case

129 Não confundir Scrum com XP: são diferentes, mas se complementam!

130 ?

131 Igor Macaúbas Marcos Pereira
Scrum Igor Macaúbas Marcos Pereira

132

133 http://delicious. com/macaubas http://delicious

134 Copiar, distribuir, exibir e executar a obra Criar obras derivadas
Este trabalho está licenciado através da “Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported” Você pode: Copiar, distribuir, exibir e executar a obra Criar obras derivadas Sob as seguintes condições: Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante. Uso Não-Comercial. Você não pode utilizar esta obra com finalidades comerciais. Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor. Nothing in this license impairs or restricts the author's moral rights.