SCRUM
Um pouco de história
1950 Taiichi Ohno Um pouco de história
1986 1950 Takeuchi & Nonaka Taiichi Ohno Um pouco de história
1993 1986 1950 Ken Schwaber Takeuchi & Nonaka Taiichi Ohno Um pouco de história
1996 1993 1986 Jeff Sutherland 1950 Ken Schwaber Takeuchi & Nonaka Taiichi Ohno Um pouco de história
2001 1996 1993 1986 Jeff Sutherland 1950 Ken Schwaber Takeuchi & Nonaka Taiichi Ohno Um pouco de história
2001 1993 1986 1996 Jeff Sutherland Ken Schwaber 1950 Takeuchi & Nonaka Taiichi Ohno Um pouco de história 2007
Por que SCRUM?
Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
O último projeto simples foi em 1969 Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
Lei de Ziv Especificações nunca serão completamente compreendidas.
Lei de Humphrey O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).
Lei de Wegner / Teorema de Godel Um sistema interativo nunca estará completamente especificado e/ou testado.
É típico adotar a abordagem de modelagem teórica quando todos os fatores pelos quais um processo opera estão razoavelmente bem entendidos. Quando o processo é complicado demais para a abordagem teórica, uma abordagem empírica é a melhor escolha. Process Dynamics, Modeling, and Control, Ogunnaike e Ray, Oxford University Press, 1992
SCRUM uma visão geral
Processo de gestão e controle empírico
Processo de gestão e controle empírico Baseado em feedback
Processo de gestão e controle empírico Baseado em feedback Equipes auto-gerenciadas
Processo de gestão e controle empírico Baseado em feedback Equipes auto-gerenciadas Comunicação é fator crítico
Processo de gestão e controle empírico Baseado em feedback Equipes auto-gerenciadas Comunicação é fator crítico Escalável para projetos grande, longos e distribuídos
Processo de gestão e controle empírico Baseado em feedback Equipes auto-gerenciadas Comunicação é fator crítico Escalável para projetos grande, longos e distribuídos Aderente a CMM Nível 3 e ISO 9001
Processo de gestão e controle empírico Baseado em feedback Equipes auto-gerenciadas Comunicação é fator crítico Escalável para projetos grande, longos e distribuídos Aderente a CMM Nível 3 e ISO 9001 Simples e difícil
Requirements Design Code Test Source: The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986.
SCRUM Roles
A Equipe
Multi-disciplinar Auto-gerenciada 7 ± 2 Comprometida com o objetivo e com si mesmo Autoridade para fazer o que for necessário para atingir o objetivo Co-locada e aberta Comunicação constante
Dono do Produto
Fornece a visão do negócio Maximiza ROI ( valor agregado ) Prioriza ítens do backlog a cada iteração Decide datas de releases e seus conteúdos Aceita ou rejeita o que foi produzido Pode ser o próprio cliente ou (mais comum) um representante interno
ScrumMaster
Facilitador Conduz reuniões e eventos Não tem autoridade Resolve pepinos Protege a equipe Cão-pastor
Eventos
Reunião de Planejamento
Progress 900 Remaining Effort in Hours 800 700 600 500 400 300 200 100 0 5/3/2002 5/5/2002 5/7/2002 752 762 664 5/9/2002 5/11/2002 5/13/2002 5/15/2002 5/17/2002 619 304 5/19/2002 Date 264 180 5/21/2002 5/23/2002 5/25/2002 5/27/2002 5/29/2002 5/31/2002 104 20
Reunião Diária - Como um projeto consegue estar atrasado mais de 1 ano?! - Um dia de cada vez. Fred Brooks, The Mythical Man-Month
De pé, máximo de 15 minutos, não é para discutir/resolver problemas 3 perguntas: o que eu fiz ontem? o que farei hoje? tenho algum problema? Sincronização de conhecimento, atualização do burn-down Não é um relatório de status para o ScrumMaster Comprometimento com o time: Peer-pressure
Demo
A equipe mostra o que foi produzido Não requer uma preparação formal Clientes, usuários, dono do produto, equipe, avó, tia, cachorro e papagaio Crucial para obter feedback
Retrospectiva
Reunião interna da equipe Análise dos pontos positivos e negativos A equipe define e introduz melhorias no processo Não é apontagem de dedos
Reunião interna da equipe Análise dos pontos positivos e negativos A equipe define e introduz melhorias no processo Não é apontagem de dedos Completa o ciclo PDCA (Plan-Do-Check-Act)
Você agora já sabe quase tudo sobre SCRUM...
Desenvolvimento em ritmo sustentável
Earned Business Value Cumulative Business Value 900 800 700 600 500 400 300 200 100 0 Earned Business Value 1 3 5 7 9 11 13 15 17 Months
SCRUM não falha
Perguntas?