Ontem aconteceu em Recife, mais um evento do Spin, com organização da Teresa Maciel, para falar de desenvolvimento ágil de software. O tema desse ano foi "Agilidade na Prática".
Apesar de eu ter sido convidado para apresentar o case da Globo.com mais uma vez, quando vi o tema do evento, resolvi falar de algo que me preocupa muito ultimamente: A adoção do SCRUM pelo mainstream sem muita preocupação com os princípios e valores que estão por traz das práticas muito simples de serem explicadas e compreendidas.
O SCRUM pode ser facilmente explicado para um leigo no assunto com menos de 2 minutos e 2 ou 3 diagramas. Porém implementar o SCRUM e ter o time no que Jeff Sutherland chama de "Estado de Hiperprodutividade" é uma tarefa muito complexa.
Numa escala de complexidade que vai do simplório, passando pelo complexo, para chegar ao simples, eu classifico o SCRUM como um framework "simples".
Além de toda a teoria da produção puxada, teoria das restrições, lean, PDCA, teoria dos sistemas adaptativos complexos e do paper de Nonaka e Takeuchi, por trás dessa simplicidade do modelo, o SCRUM engloba 38 patterns organizacionais de 60 que foram constatados pela equipe de Pesquisas da Bell Labs nos EUA, durante a ultima década do ultimo século, em projetos de dúzias de empresas ao redor do mundo que tiveram sucesso fora do comum.
http://blog.bardusco.com
Scrum na Prática: Valores mais importantes que Práticas
1. SCRUM
Na Prática o que importa são os Valores.
Danilo Bardusco <bardusco@corp.globo.com>
Gerente Geral de Desenvolvimento
Monday, November 30, 2009
2. Abstract
Nessa palestra você vai descobrir por que os Princípios e Valores do
SCRUM são mais importantes do que as Práticas, e como práticas certas
no contexto errado podem simplesmente arruinar o seu projeto. Você
vai descobrir por que a prática certa executada pela pessoa errada pode
não ter efeito algum ou ainda, como o resultado das práticas sem o
conhecimento dos valores pode te levar a conclusões erradas.
Monday, November 30, 2009
15. Propósito do Burndown
• Radiador de informação sobre o andamento do Sprint.
• Alerta para replanejamento.
• Evita a síndrome do estudante.
• Prefira queimar Histórias e não tarefas.
Monday, November 30, 2009
24. Daily Meeting
O Daily meeting é uma reunião diária de
15min onde cada participante responde as 3
perguntas:
• o que eu fiz ontem?
• o que eu vou fazer hoje?
• o que está me impedindo de trabalhar?
Monday, November 30, 2009
25. umm entendi!
O Daily meeting é uma ferramenta de status report pro:
Monday, November 30, 2009
26. umm entendi!
O Daily meeting é uma ferramenta de status report pro:
• ScrumMaster.
Monday, November 30, 2009
27. umm entendi!
O Daily meeting é uma ferramenta de status report pro:
• ScrumMaster.
• Product Owner.
Monday, November 30, 2009
28. umm entendi!
O Daily meeting é uma ferramenta de status report pro:
• ScrumMaster.
• Product Owner.
• Time.
Monday, November 30, 2009
30. O que é o Daily Meeting?
É uma ferramenta que o time usa para se replanejar diariamente,
buscando alternativas para entregar mais rápido o Goal do Sprint.
Monday, November 30, 2009
31. O que é o Daily Meeting?
É uma ferramenta que o time usa para se replanejar diariamente,
buscando alternativas para entregar mais rápido o Goal do Sprint.
• Tirar uma foto do projeto
Monday, November 30, 2009
32. O que é o Daily Meeting?
É uma ferramenta que o time usa para se replanejar diariamente,
buscando alternativas para entregar mais rápido o Goal do Sprint.
• Tirar uma foto do projeto
• Descobrir dependencias/impedimentos
Monday, November 30, 2009
33. O que é o Daily Meeting?
É uma ferramenta que o time usa para se replanejar diariamente,
buscando alternativas para entregar mais rápido o Goal do Sprint.
• Tirar uma foto do projeto
• Descobrir dependencias/impedimentos
• Endereçar quaisquer necessidades dos indivíduos do time.
Monday, November 30, 2009
34. O que é o Daily Meeting?
É uma ferramenta que o time usa para se replanejar diariamente,
buscando alternativas para entregar mais rápido o Goal do Sprint.
• Tirar uma foto do projeto
• Descobrir dependencias/impedimentos
• Endereçar quaisquer necessidades dos indivíduos do time.
• Replanejar o trabalho diariamente.
Monday, November 30, 2009
35. Daily Meeting Sintomático
sintomas de que o time ainda não entendeu o objetivo do daily meeting.
Monday, November 30, 2009
36. Daily Meeting Sintomático
sintomas de que o time ainda não entendeu o objetivo do daily meeting.
• respostas genéricas e mecanizadas à 2 perguntas
Monday, November 30, 2009
37. Daily Meeting Sintomático
sintomas de que o time ainda não entendeu o objetivo do daily meeting.
• respostas genéricas e mecanizadas à 2 perguntas
• impedimentos nunca são levantados
Monday, November 30, 2009
38. Daily Meeting Sintomático
sintomas de que o time ainda não entendeu o objetivo do daily meeting.
• respostas genéricas e mecanizadas à 2 perguntas
• impedimentos nunca são levantados
• pessoas atrasadas.
Monday, November 30, 2009
39. Daily Meeting Sintomático
sintomas de que o time ainda não entendeu o objetivo do daily meeting.
• respostas genéricas e mecanizadas à 2 perguntas
• impedimentos nunca são levantados
• pessoas atrasadas.
• daily meeting semanal.
Monday, November 30, 2009
40. Sprint Review
“É uma reunião de 2 horas onde o time
apresenta o que foi produzido durante o
Sprint.”
Monday, November 30, 2009
41. Sprint Review
O propósito é causar a interação entre PO, as
pessoas as quais ele representa e o time.
Monday, November 30, 2009
42. Sprint Review
O propósito é causar a interação entre PO, as
pessoas as quais ele representa e o time.
• É o ponto de inspeção e adaptação do product owner
para otimizar o retorno sobre o investimento.
Monday, November 30, 2009
43. Sprint Review
O propósito é causar a interação entre PO, as
pessoas as quais ele representa e o time.
• É o ponto de inspeção e adaptação do product owner
para otimizar o retorno sobre o investimento.
• baseado no que foi descoberto, o PO reestrutura o
Product Backlog para o próximo sprint.
Monday, November 30, 2009
44. Sprint Review
O propósito é causar a interação entre PO, as
pessoas as quais ele representa e o time.
• É o ponto de inspeção e adaptação do product owner
para otimizar o retorno sobre o investimento.
• baseado no que foi descoberto, o PO reestrutura o
Product Backlog para o próximo sprint.
• Tomar decisões colaborativamente.
Monday, November 30, 2009
45. Sprint Review
O propósito é causar a interação entre PO, as
pessoas as quais ele representa e o time.
• É o ponto de inspeção e adaptação do product owner
para otimizar o retorno sobre o investimento.
• baseado no que foi descoberto, o PO reestrutura o
Product Backlog para o próximo sprint.
• Tomar decisões colaborativamente.
• Não é hora para julgamento.
Monday, November 30, 2009
46. Sprint Planning
“ é uma reunião de 4 horas para
planejar como será o trabalho da
próxima iteração ”
Monday, November 30, 2009
48. Sprint Planning
Falta de entendimento sobre produção puxada
Monday, November 30, 2009
49. Sprint Planning
Falta de entendimento sobre produção puxada
• estressa as pessoas
Monday, November 30, 2009
50. Sprint Planning
Falta de entendimento sobre produção puxada
• estressa as pessoas
• reduz a qualidade
Monday, November 30, 2009
51. Sprint Planning
Falta de entendimento sobre produção puxada
• estressa as pessoas
• reduz a qualidade
• diminui a velocidade
Monday, November 30, 2009
52. Sprint Planning
Falta de entendimento sobre produção puxada
• estressa as pessoas
• reduz a qualidade
• diminui a velocidade
• planejamento irreal
Monday, November 30, 2009
53. Sprint Planning
Falta de entendimento sobre produção puxada
• estressa as pessoas
• reduz a qualidade
• diminui a velocidade
• planejamento irreal
• Parkinson’s Law
Monday, November 30, 2009
54. Sprint Planning
“ O segredo do planejamento é definir
colaborativamente um Goal desafiador
baseado na capacidade real do Time. ”
Monday, November 30, 2009
55. Sprint Retrospective
“ É uma reunião de 2 horas para
discutir o que foi bem e o que pode
ser melhorado para o próximo Sprint “
Monday, November 30, 2009
56. Prime Directive
“ 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)
Monday, November 30, 2009
57. Sprint Retrospective
• Não é reunião para lavar roupa suja.
• Não é reunião para achar culpados.
• É preciso ter um ambiente 100% seguro.
• Falta de ação é um problema.
• Trocar o facilitador periodicamente é
interesante.
Monday, November 30, 2009
58. Product Owner
• Escreve as histórias
• Prioriza as histórias
• Mantém o Product Backlog priorizado
• Aceita ou rejeita uma funcionalidade no Sprint
Review
Monday, November 30, 2009
59. humm entendi...
então o Product Owner é:
Monday, November 30, 2009
63. Product Owner
• Responsável pelo sucesso ou fracasso do projeto.
• Expert de Domínio
• Maximizar ROI
• Cria uma visão compartilhada.
• Criar o Release Plan do Produto
• Representa os interesses de todos os stakeholders
• Criar as fronteiras para o Time (Tempo, Orçamento, Visão, Padrões, etc)
• Tem que estar disponível para o time
Monday, November 30, 2009
64. “O Product Owner
não é a pessoa que
conta história.
É a pessoa que
demanda a
funcionalidade! “
( Boris Gloger )
Monday, November 30, 2009
65. ScrumMaster
• Facilitador.
• Não tem autoridade sobre o time.
• Organiza reuniões e faz cumprir o time-box.
• Remove Impedimentos.
Monday, November 30, 2009
66. humm entendi...
então o ScrumMaster é:
Monday, November 30, 2009
71. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
Monday, November 30, 2009
72. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
Monday, November 30, 2009
73. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
•Criar um ambiente 100% transparente e seguro que encoraja a
cultura do feedback imediato.
Monday, November 30, 2009
74. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
•Criar um ambiente 100% transparente e seguro que encoraja a
cultura do feedback imediato.
•Ensina os valores e práticas ágeis de engenharia de software.
Monday, November 30, 2009
75. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
•Criar um ambiente 100% transparente e seguro que encoraja a
cultura do feedback imediato.
•Ensina os valores e práticas ágeis de engenharia de software.
•Alinhar as expectativas entre PO e Time, garantindo um clima de
parceria entre ambos.
Monday, November 30, 2009
76. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
•Criar um ambiente 100% transparente e seguro que encoraja a
cultura do feedback imediato.
•Ensina os valores e práticas ágeis de engenharia de software.
•Alinhar as expectativas entre PO e Time, garantindo um clima de
parceria entre ambos.
•Tem muito senso de urgência.
Monday, November 30, 2009
77. ScrumMaster
•É um agente de mudança.
•Garante que todos os papéis do Scrum estão sendo seguidos.
•Protege o time de interferências externas (não é paternalismo)
•Criar um ambiente 100% transparente e seguro que encoraja a
cultura do feedback imediato.
•Ensina os valores e práticas ágeis de engenharia de software.
•Alinhar as expectativas entre PO e Time, garantindo um clima de
parceria entre ambos.
•Tem muito senso de urgência.
•é o principal responsável pela performance do time.
Monday, November 30, 2009
78. “ Um bom ScrumMaster
é capaz de Implementar
mudanças positivas
significativas a cada
iteração. “
Monday, November 30, 2009