SlideShare uma empresa Scribd logo
1 de 41
Conceitos
Desenvolvimento Ágil
e
SCRUM
Robson Eduardo David, CTFL, PMP, CSM, ITIL
Nov/2016
robson.david@itau-unibanco.com.br
Evolução...
Scrum Guide
Manifesto Ágil
Scrum
Entrega de Soluções
• Necessidade de locomoção
• Não adianta entregar partes de uma solução (Roda, Chassi)
• Meios de locomoção parciais
• Feedback antecipado
O que é ser Ágil?
Responder a mudanças, sem traumasResponder a mudanças, sem traumas
• Bom para projetos parcialmente definidos.
• Requisitos mudam, e mudanças são bem-vindas.
• Sem neurose contratual.
Entregar mais rápido (freqüência)Entregar mais rápido (freqüência)
• O cliente não espera muito para ver resultados.
• Retorno sobre o investimento vem mais rápido.
• Visualização parcial dos resultados diminui o risco.
(Não significa necessariamente entregar mais
volume).
AssertividadeAssertividade
•Decisões baseadas em fatos.
•Ver algo pronto é melhor do que qualquer
previsão.
•Decisão distribuída entre os envolvidos no projeto.
Restrições
Só o escopo prioritário é atendido, prazo e custos são mantidos!
Gestão 3.0
• Gestão 1.0
 focada na hierarquia
 comando-e-controle
• Gestão 2.0
 estrutura top-down
 Gestão 1.0 “turbinada”
 Balanced Scorecards
 Six Sigma
 TQM
• Gestão 3.0
 focada na complexidade
 organizações com redes
 pessoas e relacionamentos
como foco na gestão
PMI ACP
Origem do Scrum
• Jogo Rugby
•Objetivo: recuperar a posse de bola
• Só 8 jogadores do time participam
• Todos fazem força juntos e ao mesmo tempo.
Scrum - Pilares
Papéis
Papéis
Papéis
Fluxo de Trabalho
Vision (Visão) é o que deve ser satisfeito ao fim do projeto. Ela é
definida pelo PO que colhe informações junto aos clientes, time e
stakeholders;
Product backlog (Backlog do Produto) é a lista inicial de
necessidades que precisam ser produzidas para que a Visão seja
atingida. Inclui conteúdo, disponibilidade e priorização. Todos
devem contribuir para sua confecção e é evoluído à medida que
as seus itens são desenvolvidos;
Sprint planning (Planejamento da Sprint) são reuniões em que o
time decide O QUE vai ser feito e COMO vai ser feito;
Sprint backlog (Backlog da Sprint) é o resultado da fase anterior,
contendo itens do backlog, suas respectivas tarefas e meta da
sprint (lembrando que, meta é o compromisso assumido pelo
time);
Fluxo de Trabalho
Sprint é a efetiva execução dos trabalhos, que pode durar entre 2
e 4 semanas. Durante as sprints, ocorre o daily meeting, que é
uma reunião diária com 15 minutos de duração onde o time
discute o que foi feito desde a última reunião, o que pretende
realizar e se está com algum impedimento;
Sprint review (Revisão da Sprint) é a fase em que o PO identifica
o que foi feito e o que não foi feito através de questionamento ao
time. Ela fornece inputs de valor para as sprints seguintes;
Retrospective (Retrospectiva da Sprint) é a última reunião do
time antes da entrega final do produto onde é discutido o que foi
bom, o que pode ser melhorado e as respectivas ações para
melhoria. PO nesta fase apenas se convidado pelo time.
Planejameno de Releases e Sprints
19
Sprint
Sprint
Sprint
Release
Release
Release
Sprint
Sprint
Sprint
Sprint
Sprint
Sprint
Sprint
Release
SprintSprint
• É frequente, ocorre repetidamente em períodos de 2 a 4 semanas.
• Entrega parte do produto pronto para entrar em produção
ReleaseRelease
• É o momento em que as partes do produto pronto entram em produção.
• O momento é definido de acordo com a estratégia de Negócios.
VisãoVisão
Planejameno de Releases e Sprints
20
Sprint são iterativas e incrementaisSprint são iterativas e incrementais
IterativoIterativo
(repetição):(repetição):
IncrementalIncremental
(aumento):(aumento):
Product Backlog
User Stories
Ex. Como um cliente quero pesquisar valores de
passagens aéreas para que eu possa fazer o
meu orçamento de viagem
Ex. Considero a história atendida se tiver uma
tela onde eu possa consultar voos e seus
respectivos valores
Frente:
Como <quem> <quando> <onde>,
eu <o que>, porque <por que>.
Verso:
Considero a história atendida se
<condição>
Planning Pocker
DoR (Definição Preparado) DoD (Definição Pronto)
Kanban
Burn Down Chart
Sprint Planning Meeting
27
•Determinar a meta da Sprint
•Determinar o Sprint Backlog
•Determinar as tarefas para atingir o Sprint.
Planejar o trabalho da sprintPlanejar o trabalho da sprint
ParticipantesParticipantes
•Product Owner – necessário
•Scrum Master – necessário
•Team – necessário
InputsInputs
•Product Backlog priorizado
•Velocidade do time
•Incremento do produto da Sprint Anterior.
AgendaAgenda
•Acontece ao início de cada Sprint
•8 horas divididas em duas partes de 4 horas.
Sprint Planning Meeting
28
1ª parte – 4 hs1ª parte – 4 hs
Determinar
meta
Ajustar
Prioridades
Determinar
velocidade
Selecionar
backlog
Revisar
estimativas
Sprint
Backlogt
A fazer Fazendo Pronto
Determinar
tarefas
Estimar
tarefas
2ª parte – 4 hs2ª parte – 4 hs
Sprint Planning Meeting
O sistema
deve
controlar os
clientes
8
O cliente
deve
conseguir
tirar um
Extrato
13
Meta:
Clientes
consultan
do extrato
Daily meeting (ou stand-up meeting)
30
•Todos tem oportunidade de saber como podem ajudar
• É atualizado o quadro de gestão visual e burndown
• O Scrum Master atua como mestre de cerimônia
Compartilhar informaçõesCompartilhar informações
ParticipantesParticipantes
•Product Owner – opcional
•Scrum Master – necessário
•Team – necessário
InputsInputs
•Informações sobre o trabalho de cada integrante do
time
AgendaAgenda
•Reunião diária.
•15 minutos, independente do tamanho da equipe
•Feita, de preferência em pé, para que seja rápida.
Daily Meeting
O que você fez desde a última reunião
diária, que ajudou a equipe para atender a
meta da sprint?
Os membros do time respondem às questões:Os membros do time respondem às questões:
O que você fará entre agora a próxima
reunião diária, que vai ajudar a equipe
para atender a meta da sprint?
O que impede você de realizar seu trabalho
com ao maior efetividade possível, para o
atendimento da meta da sprint?
Sprint Review Meeting
32
•Resultado é produto funcionando
•No ambiente mais próximo a produção e sem truques
•Quem apresenta, recebe elogios ou críticas é o time.
Apresentar os resultados da SprintApresentar os resultados da Sprint
ParticipantesParticipantes
•Product Owner – necessário
•Convidados do PO - opcionais
•Scrum Master – opcional
•Team – necessário
InputsInputs
•Incremento de produto funcionando
AgendaAgenda
•Ocorre ao final da Sprint
•Restrita a 4 horas de duração, mas pode durar menos.
•Quais foram suas impressões?
•Quais as mudanças desejadas?
•Qual é a prioridade dessas mudanças no Product
Backlog?
Ao final da apresentaçãoAo final da apresentação o Scrum Master solicitao Scrum Master solicita
aos stakeholders que relatem:aos stakeholders que relatem:
Sprint Review Meeting
Sprint Retrospective Meeting
34
•Todo ciclo de melhoria contínua tem um feedback
• Os pontos de melhoria são implementados já no
próximo sprint
Colher resultados para melhorarColher resultados para melhorar
ParticipantesParticipantes
•Product Owner – opcional
•Scrum Master – necessário
•Team – necessário
InputsInputs
•Informações da Sprint
AgendaAgenda
•Ocorre ao final da Sprint, após a Sprint Review meeting.
•Tem duração de 3 horas
Sprint Retrospective meeting
•O que foi bem sucedido durante o último Sprint?
•O que poderia ser melhorado no próximo Sprint?
Antes reunião,Antes reunião, o Scrum Master solicita aoso Scrum Master solicita aos
membros do time que preencham um formuláriomembros do time que preencham um formulário
dizendo:dizendo:
Considerações
Gestão tradicional Abordagem Scrum
Escopo O escopo é definido pelo Product Backlog e Sprint Backlog
Custos O custo é dado por Sprint, não por projeto. A priorização do
Backlog é voltada ao ROI, equipes fixas, tempos fixos.
Tempo Definição de time-boxes
Comunicação Fortemente baseada nas cerimônias. Não exige
planejamento, exige disciplinado Scrum.
Integração O próprio framework SCRUM força a integração das
disciplinas, pois aborda indiretamente todas elas.
Recursos Humanos Times auto-gerenciados. Papéis claros (scrum master,
product owner e time)
Qualidade Inspeção constante. Cerimônias de revisão e retrospectiva
Riscos Estratégia de aceitação. A abordagem é que, se tudo der
errado , o prejuízo máximo é de 1 mês de trabalho.
Aquisições Por não definir o escopo com rigidez, o tipo de contrato
firmado geralmente é “Time and Material”.
Coaching Ágil – Substituindo os fundamentos
básicos do gerenciamento de projetos
Analogia...
Cenário Tradicional Ágil
Metodologia RUP
Waterfall
Scrum
Órgão PMI Scrum Alliance
Guia de
Referência
PMBOK The Scrum Guide
Certificação PMP CSPO; CSM; CSD
Informações para consulta
Scrum Guide
http://www.scrumguides.org/
Manifesto Ágil
http://manifestoagil.com.br/
Scrum Alliance
http://www.scrumalliance.org/pages/what_is_scrum
PMI
http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx
Jurgen Appelo
http://jurgenappelo.com/
http://jurgenappelo.com/management-30/
” Nas grandes batalhas da vida,
o primeiro passo para a
vitória é o desejo de vencer. ”
Mahatma Gandhi
” Não se pode ensinar alguma
coisa a um homem; apenas
ajudá-lo a encontrá-lo dentro
de si mesmo. ”
Galileu Galilei

Mais conteúdo relacionado

Mais procurados

Scrum - Gestão Ágil de Projetos de Software
Scrum - Gestão Ágil de Projetos de SoftwareScrum - Gestão Ágil de Projetos de Software
Scrum - Gestão Ágil de Projetos de SoftwareLucas Gonçalves Nadalete
 
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Thiago Compan
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMLucas Vinícius
 
Seminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPSeminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPLays Lopes
 
Palestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPalestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPersonal
 
Scrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempoScrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempoFernando Fagonde
 
Estrategia de implementacao Scrum para Produtora Web
Estrategia de implementacao Scrum para Produtora WebEstrategia de implementacao Scrum para Produtora Web
Estrategia de implementacao Scrum para Produtora WebLuanna Eroles
 
Treinamento Scrum Ensinando.Com - Resumo de Aula
Treinamento Scrum Ensinando.Com - Resumo de AulaTreinamento Scrum Ensinando.Com - Resumo de Aula
Treinamento Scrum Ensinando.Com - Resumo de AulaEnsinando Treinamentos
 

Mais procurados (19)

Netshoes metodologia
Netshoes metodologiaNetshoes metodologia
Netshoes metodologia
 
Scrum - Gestão Ágil de Projetos de Software
Scrum - Gestão Ágil de Projetos de SoftwareScrum - Gestão Ágil de Projetos de Software
Scrum - Gestão Ágil de Projetos de Software
 
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
 
Antigo_Scrum
Antigo_ScrumAntigo_Scrum
Antigo_Scrum
 
Scrum - evolução contínua
Scrum - evolução contínuaScrum - evolução contínua
Scrum - evolução contínua
 
Seminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPSeminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XP
 
Palestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPalestra sobre metodologia Scrum
Palestra sobre metodologia Scrum
 
Scrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempoScrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempo
 
Lista de Práticas Ágeis
Lista de Práticas ÁgeisLista de Práticas Ágeis
Lista de Práticas Ágeis
 
Agile SCRUM
Agile SCRUMAgile SCRUM
Agile SCRUM
 
Estrategia de implementacao Scrum para Produtora Web
Estrategia de implementacao Scrum para Produtora WebEstrategia de implementacao Scrum para Produtora Web
Estrategia de implementacao Scrum para Produtora Web
 
Treinamento Scrum Ensinando.Com - Resumo de Aula
Treinamento Scrum Ensinando.Com - Resumo de AulaTreinamento Scrum Ensinando.Com - Resumo de Aula
Treinamento Scrum Ensinando.Com - Resumo de Aula
 
Scrum
ScrumScrum
Scrum
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Scrum - Teoria do Scrum
Scrum - Teoria do Scrum Scrum - Teoria do Scrum
Scrum - Teoria do Scrum
 
Scrum em 2 minutos
Scrum em 2 minutosScrum em 2 minutos
Scrum em 2 minutos
 
Gestao agil de projetos
Gestao agil de projetosGestao agil de projetos
Gestao agil de projetos
 

Semelhante a Compartilhando Conceitos Desenvolvimento Ágil e SCRUM

Aula 06 Scrum - parte II completo.ppt
Aula 06 Scrum - parte II completo.pptAula 06 Scrum - parte II completo.ppt
Aula 06 Scrum - parte II completo.pptAntonioVieiraMSc
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012Libia Boss
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
ENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdfENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdfssuserbe3ad6
 
Softdrops - Sprint Review Meeting
Softdrops - Sprint Review MeetingSoftdrops - Sprint Review Meeting
Softdrops - Sprint Review MeetingSheila Kimura
 
Curso "Scrum na Real" - Parte 4
Curso "Scrum na Real" - Parte 4Curso "Scrum na Real" - Parte 4
Curso "Scrum na Real" - Parte 4leobower
 
Aplicando métodos ágeis utilizando o Framework SCRUM
Aplicando métodos ágeis utilizando o Framework  SCRUMAplicando métodos ágeis utilizando o Framework  SCRUM
Aplicando métodos ágeis utilizando o Framework SCRUMSony Maia
 
Visão Macro do SCRUM
Visão Macro do SCRUMVisão Macro do SCRUM
Visão Macro do SCRUMRicardo Moura
 
Prévia básica do Scrum
Prévia básica do ScrumPrévia básica do Scrum
Prévia básica do ScrumIsaac Maciel
 
Treinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATELTreinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATELDaniel Calmazini
 
Apresentacao scrum
Apresentacao scrumApresentacao scrum
Apresentacao scrumUriel Valle
 

Semelhante a Compartilhando Conceitos Desenvolvimento Ágil e SCRUM (20)

Aula 06 Scrum - parte II completo.ppt
Aula 06 Scrum - parte II completo.pptAula 06 Scrum - parte II completo.ppt
Aula 06 Scrum - parte II completo.ppt
 
Agile testing
Agile testing Agile testing
Agile testing
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Scrum
ScrumScrum
Scrum
 
ENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdfENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdf
 
Softdrops - Sprint Review Meeting
Softdrops - Sprint Review MeetingSoftdrops - Sprint Review Meeting
Softdrops - Sprint Review Meeting
 
Curso "Scrum na Real" - Parte 4
Curso "Scrum na Real" - Parte 4Curso "Scrum na Real" - Parte 4
Curso "Scrum na Real" - Parte 4
 
Fazendo acontecer com Scrum e a Filosofia Ágil.
Fazendo acontecer com Scrum e a Filosofia Ágil.Fazendo acontecer com Scrum e a Filosofia Ágil.
Fazendo acontecer com Scrum e a Filosofia Ágil.
 
Aplicando métodos ágeis utilizando o Framework SCRUM
Aplicando métodos ágeis utilizando o Framework  SCRUMAplicando métodos ágeis utilizando o Framework  SCRUM
Aplicando métodos ágeis utilizando o Framework SCRUM
 
Visão Macro do SCRUM
Visão Macro do SCRUMVisão Macro do SCRUM
Visão Macro do SCRUM
 
SCRUM
SCRUMSCRUM
SCRUM
 
Prévia básica do Scrum
Prévia básica do ScrumPrévia básica do Scrum
Prévia básica do Scrum
 
Scrum
ScrumScrum
Scrum
 
Scrum fundamentos basicos
Scrum   fundamentos basicosScrum   fundamentos basicos
Scrum fundamentos basicos
 
Scrum desenvolvimento ágil
Scrum   desenvolvimento ágilScrum   desenvolvimento ágil
Scrum desenvolvimento ágil
 
Scrum - Visão Geral
Scrum - Visão GeralScrum - Visão Geral
Scrum - Visão Geral
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Treinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATELTreinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATEL
 
Apresentacao scrum
Apresentacao scrumApresentacao scrum
Apresentacao scrum
 

Último

EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 
Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORDRONDINELLYRAMOS1
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 

Último (7)

EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 
Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORD
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 

Compartilhando Conceitos Desenvolvimento Ágil e SCRUM

  • 1. Conceitos Desenvolvimento Ágil e SCRUM Robson Eduardo David, CTFL, PMP, CSM, ITIL Nov/2016 robson.david@itau-unibanco.com.br
  • 6. Entrega de Soluções • Necessidade de locomoção • Não adianta entregar partes de uma solução (Roda, Chassi) • Meios de locomoção parciais • Feedback antecipado
  • 7. O que é ser Ágil? Responder a mudanças, sem traumasResponder a mudanças, sem traumas • Bom para projetos parcialmente definidos. • Requisitos mudam, e mudanças são bem-vindas. • Sem neurose contratual. Entregar mais rápido (freqüência)Entregar mais rápido (freqüência) • O cliente não espera muito para ver resultados. • Retorno sobre o investimento vem mais rápido. • Visualização parcial dos resultados diminui o risco. (Não significa necessariamente entregar mais volume). AssertividadeAssertividade •Decisões baseadas em fatos. •Ver algo pronto é melhor do que qualquer previsão. •Decisão distribuída entre os envolvidos no projeto.
  • 8. Restrições Só o escopo prioritário é atendido, prazo e custos são mantidos!
  • 9. Gestão 3.0 • Gestão 1.0  focada na hierarquia  comando-e-controle • Gestão 2.0  estrutura top-down  Gestão 1.0 “turbinada”  Balanced Scorecards  Six Sigma  TQM • Gestão 3.0  focada na complexidade  organizações com redes  pessoas e relacionamentos como foco na gestão
  • 11. Origem do Scrum • Jogo Rugby •Objetivo: recuperar a posse de bola • Só 8 jogadores do time participam • Todos fazem força juntos e ao mesmo tempo.
  • 16.
  • 17. Fluxo de Trabalho Vision (Visão) é o que deve ser satisfeito ao fim do projeto. Ela é definida pelo PO que colhe informações junto aos clientes, time e stakeholders; Product backlog (Backlog do Produto) é a lista inicial de necessidades que precisam ser produzidas para que a Visão seja atingida. Inclui conteúdo, disponibilidade e priorização. Todos devem contribuir para sua confecção e é evoluído à medida que as seus itens são desenvolvidos; Sprint planning (Planejamento da Sprint) são reuniões em que o time decide O QUE vai ser feito e COMO vai ser feito; Sprint backlog (Backlog da Sprint) é o resultado da fase anterior, contendo itens do backlog, suas respectivas tarefas e meta da sprint (lembrando que, meta é o compromisso assumido pelo time);
  • 18. Fluxo de Trabalho Sprint é a efetiva execução dos trabalhos, que pode durar entre 2 e 4 semanas. Durante as sprints, ocorre o daily meeting, que é uma reunião diária com 15 minutos de duração onde o time discute o que foi feito desde a última reunião, o que pretende realizar e se está com algum impedimento; Sprint review (Revisão da Sprint) é a fase em que o PO identifica o que foi feito e o que não foi feito através de questionamento ao time. Ela fornece inputs de valor para as sprints seguintes; Retrospective (Retrospectiva da Sprint) é a última reunião do time antes da entrega final do produto onde é discutido o que foi bom, o que pode ser melhorado e as respectivas ações para melhoria. PO nesta fase apenas se convidado pelo time.
  • 19. Planejameno de Releases e Sprints 19 Sprint Sprint Sprint Release Release Release Sprint Sprint Sprint Sprint Sprint Sprint Sprint Release SprintSprint • É frequente, ocorre repetidamente em períodos de 2 a 4 semanas. • Entrega parte do produto pronto para entrar em produção ReleaseRelease • É o momento em que as partes do produto pronto entram em produção. • O momento é definido de acordo com a estratégia de Negócios. VisãoVisão
  • 20. Planejameno de Releases e Sprints 20 Sprint são iterativas e incrementaisSprint são iterativas e incrementais IterativoIterativo (repetição):(repetição): IncrementalIncremental (aumento):(aumento):
  • 22. User Stories Ex. Como um cliente quero pesquisar valores de passagens aéreas para que eu possa fazer o meu orçamento de viagem Ex. Considero a história atendida se tiver uma tela onde eu possa consultar voos e seus respectivos valores Frente: Como <quem> <quando> <onde>, eu <o que>, porque <por que>. Verso: Considero a história atendida se <condição>
  • 24. DoR (Definição Preparado) DoD (Definição Pronto)
  • 27. Sprint Planning Meeting 27 •Determinar a meta da Sprint •Determinar o Sprint Backlog •Determinar as tarefas para atingir o Sprint. Planejar o trabalho da sprintPlanejar o trabalho da sprint ParticipantesParticipantes •Product Owner – necessário •Scrum Master – necessário •Team – necessário InputsInputs •Product Backlog priorizado •Velocidade do time •Incremento do produto da Sprint Anterior. AgendaAgenda •Acontece ao início de cada Sprint •8 horas divididas em duas partes de 4 horas.
  • 28. Sprint Planning Meeting 28 1ª parte – 4 hs1ª parte – 4 hs Determinar meta Ajustar Prioridades Determinar velocidade Selecionar backlog Revisar estimativas Sprint Backlogt A fazer Fazendo Pronto Determinar tarefas Estimar tarefas 2ª parte – 4 hs2ª parte – 4 hs
  • 29. Sprint Planning Meeting O sistema deve controlar os clientes 8 O cliente deve conseguir tirar um Extrato 13 Meta: Clientes consultan do extrato
  • 30. Daily meeting (ou stand-up meeting) 30 •Todos tem oportunidade de saber como podem ajudar • É atualizado o quadro de gestão visual e burndown • O Scrum Master atua como mestre de cerimônia Compartilhar informaçõesCompartilhar informações ParticipantesParticipantes •Product Owner – opcional •Scrum Master – necessário •Team – necessário InputsInputs •Informações sobre o trabalho de cada integrante do time AgendaAgenda •Reunião diária. •15 minutos, independente do tamanho da equipe •Feita, de preferência em pé, para que seja rápida.
  • 31. Daily Meeting O que você fez desde a última reunião diária, que ajudou a equipe para atender a meta da sprint? Os membros do time respondem às questões:Os membros do time respondem às questões: O que você fará entre agora a próxima reunião diária, que vai ajudar a equipe para atender a meta da sprint? O que impede você de realizar seu trabalho com ao maior efetividade possível, para o atendimento da meta da sprint?
  • 32. Sprint Review Meeting 32 •Resultado é produto funcionando •No ambiente mais próximo a produção e sem truques •Quem apresenta, recebe elogios ou críticas é o time. Apresentar os resultados da SprintApresentar os resultados da Sprint ParticipantesParticipantes •Product Owner – necessário •Convidados do PO - opcionais •Scrum Master – opcional •Team – necessário InputsInputs •Incremento de produto funcionando AgendaAgenda •Ocorre ao final da Sprint •Restrita a 4 horas de duração, mas pode durar menos.
  • 33. •Quais foram suas impressões? •Quais as mudanças desejadas? •Qual é a prioridade dessas mudanças no Product Backlog? Ao final da apresentaçãoAo final da apresentação o Scrum Master solicitao Scrum Master solicita aos stakeholders que relatem:aos stakeholders que relatem: Sprint Review Meeting
  • 34. Sprint Retrospective Meeting 34 •Todo ciclo de melhoria contínua tem um feedback • Os pontos de melhoria são implementados já no próximo sprint Colher resultados para melhorarColher resultados para melhorar ParticipantesParticipantes •Product Owner – opcional •Scrum Master – necessário •Team – necessário InputsInputs •Informações da Sprint AgendaAgenda •Ocorre ao final da Sprint, após a Sprint Review meeting. •Tem duração de 3 horas
  • 35. Sprint Retrospective meeting •O que foi bem sucedido durante o último Sprint? •O que poderia ser melhorado no próximo Sprint? Antes reunião,Antes reunião, o Scrum Master solicita aoso Scrum Master solicita aos membros do time que preencham um formuláriomembros do time que preencham um formulário dizendo:dizendo:
  • 36. Considerações Gestão tradicional Abordagem Scrum Escopo O escopo é definido pelo Product Backlog e Sprint Backlog Custos O custo é dado por Sprint, não por projeto. A priorização do Backlog é voltada ao ROI, equipes fixas, tempos fixos. Tempo Definição de time-boxes Comunicação Fortemente baseada nas cerimônias. Não exige planejamento, exige disciplinado Scrum. Integração O próprio framework SCRUM força a integração das disciplinas, pois aborda indiretamente todas elas. Recursos Humanos Times auto-gerenciados. Papéis claros (scrum master, product owner e time) Qualidade Inspeção constante. Cerimônias de revisão e retrospectiva Riscos Estratégia de aceitação. A abordagem é que, se tudo der errado , o prejuízo máximo é de 1 mês de trabalho. Aquisições Por não definir o escopo com rigidez, o tipo de contrato firmado geralmente é “Time and Material”.
  • 37. Coaching Ágil – Substituindo os fundamentos básicos do gerenciamento de projetos
  • 38. Analogia... Cenário Tradicional Ágil Metodologia RUP Waterfall Scrum Órgão PMI Scrum Alliance Guia de Referência PMBOK The Scrum Guide Certificação PMP CSPO; CSM; CSD
  • 39. Informações para consulta Scrum Guide http://www.scrumguides.org/ Manifesto Ágil http://manifestoagil.com.br/ Scrum Alliance http://www.scrumalliance.org/pages/what_is_scrum PMI http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx Jurgen Appelo http://jurgenappelo.com/ http://jurgenappelo.com/management-30/
  • 40.
  • 41. ” Nas grandes batalhas da vida, o primeiro passo para a vitória é o desejo de vencer. ” Mahatma Gandhi ” Não se pode ensinar alguma coisa a um homem; apenas ajudá-lo a encontrá-lo dentro de si mesmo. ” Galileu Galilei

Notas do Editor

  1. Robson, trabalho a SQT, Gerência Testes Funcionais – Enoch e Camila Não sou expert no assunto; em 2010 ... CSM... Estudando... Em 2015 ... Prática no Itaú ... Novo Sispag – Canal + Core Venho conversando sobre este assunto com Gestores e Colegas, relação total com as Comunidades compartilhar essas informações com vocês Passar alguns conceitos Disponibilizar fonte para pesquisa Reflexões se pode nos ajudar: nossos projetos, nossa área e banco Perguntas, comentários e dúvidas = interromper a qualquer momento
  2. Um pouco da história ... Não é algo novo, mas agora sendo utilizando de forma mais intensa por grandes empresas no Brasil e no Mundo
  3. Based on the principles of Scrum and the Agile Manifesto, Scrum.org provides comprehensive training, assessments and certifications to improve the profession of software development. Throughout the world, our solutions and community of Professional Scrum Trainers empower people and organizations to achieve agility through Scrum.  Ken Schwaber, the co-creator of Scrum, founded Scrum.org in 2009 as a global organization, dedicating himself to improving the profession of software development by reducing the gaps so the work and work products are dependable.   Mission: To improve the profession of Software Development. Vision: A world in which all software developers love their work, and their customers love working with them. Goals and Strategies By 2020, Scrum.org will have made a positive and measurable impact on the development of software around the world, by working in partnership with others to: . Maintain the integrity and relevance of the Scrum framework, . Develop tools and curriculum that teach people how to use Scrum, . Teach organizations to deliver more value with the products and systems they build, . Develop a global community that supports professionalism in software development.
  4. Eu tinha um conceito equivocado.. Sem documentação, mão na massa, sem planejamento, retrabalho... NÃO É NADA DISSO !! - Em fevereiro de 2001, 17 pessoas que já trabalhavam com Extreme Programming, Scrum, ou outros dos chamados Métodos Leves (Lightweight Methods) de desenvolvimento de software reuniram-se em um hotel nas montanhas nevadas do estado norte-americano de Utah para trocar ideias sobre o que estavam fazendo. Todo o mundo da Engenharia de Software voltou sua atenção para a reunião, e muito foi especulado a respeito de seus resultados. Quando todos esperavam que o encontro resultasse numa nova “UML” (Booch, Rambaut e Jacobson), o resultado da reunião foi o esse manifesto. O único inglês da turma, Martin Fowler, foi quem sugeriu o termo &amp;quot;agile&amp;quot; para descrever aquilo que estavam, afinal, discutindo, mesmo preocupado com o fato de que os americanos tinham dificuldade em pronunciar tal termo. Depois de muitas conversas, esquiadas, comida e diversão, Martin apresentou a redação do Manifesto Ágil, assinado por todos os presentes e por muito mais pessoas a partir de então. Resumo: Decisão assertiva, baseada em algo real, materializado. Adotar uma postura mais flexível, onde todos estão comprometidos com o resultado.
  5. Adaptworks – Alexandre Magno – He was the first Certified Scrum Trainer of Brazil and have accumulated extensive experience in implement Scrum and other Agile methods for different areas of businesses such as: start-ups, financial institutions, marketing agencies, software factories, airlines companies and ISVs. Magno is also a Licensed Trainer for the Jurgen Appelo&amp;apos;s Management 3.0 course. SCRUM não é um processo ou uma técnica para o desenvolvimento de produtos. O Scrum é usado para reiniciar o jogo após uma paralisação, falta ou impedimento. O Scrum-half (tipo um meio de campo) do time que não cometeu a infração coloca a bola no meio do &amp;quot;túnel&amp;quot; formado pelas duas primeiras linhas de cada equipe com a finalidade de que os jogadores da sua equipe consigam ganhar (talonar) a bola. É como se fosse a “bola ao alto” do futebol. Não são todos os 15 jogadores que podem formar um scrum. Só oito jogadores de cada time podem participar. Os jogadores fazem força para empurrar o outro time e assim ganhar território e por consequência a posse da bola Scrum é um meio e não um fim em si mesmo: Objetivo é ganhar a bola e não fazer o scrum. No scrum todos os atacantes aprendem a atuar em conjunto ao serviço da equipe.
  6. Entrega constantes = valor para o cliente e oportunidade de validar e ajustar se necessário Entrega mensais &amp;lt;&amp;gt; aguardar semestres para o resultado final, que pode estar defasado Processos Ágeis são fortemente baseados numa abordagem iterativa e incremental. Dessa forma, ao invés de um processo faseado que só realiza a entrega total ao final de um projeto, o Ágil acontece através de ciclos menores de entrega durante um projeto. Dessa forma, cada ciclo entrega um pequeno incremento, onde os envolvidos no projetos podem ter um feedback antecipado sobre entendimento, a assertividade e o valor gerado por aquela pequena parte do trabalho. Essa abordagem é importante para ajudar a mitigar os riscos e as incertezas inerentes ao desenvolvimento de software. Através dos ciclos curtos, é possível validar se determinado requisitos está ou não aderente à necessidade de um cliente ou se, aquela solução proposta está ou não resolvendo o problema negócio para qual ela foi desenhada.
  7. A decisão fica distribuída entre os integrantes do projeto. Perguntar aos participantes: Por que os clientes acham que Scrum é mais rápido? Resposta: é uma falsa sensação devido ao fato do cliente “enxergar” os primeiros resultados mais rápido (tempo do primeiro Sprint), não tendo que esperar até o final do projeto para homologar o produto como um todo (waterfall).
  8. Tempo e Custo = fixo Escopo = variável (pode mudar sem problemas, podemos não entregar tudo, mas COM CERTEZA entregamos primeiro o que é mais importante e agrega mais valor – importância do PO Qualidade = objetivo constante para todos os projetos Podemos não entregar tudo do Product Backlog devido as restrições de recursos de Tempo e de Custo, mas entregaremos o que tem mais valor para o cliente primeiro!
  9. Gestor funcional ficar atendo a estrutura SCRUM, respeitando limites: - Acompanhamento atividades - Atribuição tarefas - Construção time = pessoas com perfil - Avaliação performance = mesmas metas X, diferenciando pelo Y -&amp;gt; autogerenciamento e comprometimentos Ser Auto-organizados Ser multifuncionais Ter entre 5 e 9 integrantes Ter espaço físico apropriado Ter metas e avaliação comum = Todos ganham ou todos perdem. = Energizar pessoas: pessoas são a parte mais importante de uma empresa, certo? Gerentes devem portanto fazer o que for possível para mantê-las ativas, criativas e motivadas. Empoderar times: times devem auto-organizar, mas para isso precisam empoderação, autorização e confiança da gestão. Alinhar restrições: auto-organização pode não funcionar, para diminuir esta possibilidade dê às pessoas um propósito claro e metas compartilhadas. Desenvolver competências: times não conseguirão atingir as metas caso alguns de seus membros não forem suficientemente capazes. Gerentes devem contribuir para o desenvolvimento de competências. Crescer a estrutura: muitos times trabalham dentro de um contexto organizacional complexo, portanto é importante considerar estruturas que promovam a comunicação. Melhorar tudo: pessoas, times, e organizações precisamos melhorar continuamente para evitar falhas sempre que possível.
  10. PMI... Renomado... e considerando Agile !! GAPCON – João Gama – 1º certificado no Brasil, final de 2011 é um entusiasta da abordagem Agile há pelo menos 15 anos quando conheceu o DSDM, uma metodologia criada no Reino Unido no começo dos anos 90 e considerada a precursora das metodologias Ágeis PMI-ACP em 2011, durante o programa piloto. É o primeiro PMI-ACP do Brasil e um dos primeiros do mundo.
  11. SCRUM não é um processo ou uma técnica para o desenvolvimento de produtos. O Scrum é usado para reiniciar o jogo após uma paralisação, falta ou impedimento. O Scrum-half (tipo um meio de campo) do time que não cometeu a infração coloca a bola no meio do &amp;quot;túnel&amp;quot; formado pelas duas primeiras linhas de cada equipe com a finalidade de que os jogadores da sua equipe consigam ganhar (talonar) a bola. É como se fosse a “bola ao alto” do futebol. Não são todos os 15 jogadores que podem formar um scrum. Só oito jogadores de cada time podem participar. Os jogadores fazem força para empurrar o outro time e assim ganhar território e por consequência a posse da bola Scrum é um meio e não um fim em si mesmo: Objetivo é ganhar a bola e não fazer o scrum. No scrum todos os atacantes aprendem a atuar em conjunto ao serviço da equipe.
  12. MOSTRAR: Tarefas, Resultados, Dificuldades, Erros VERIFICAR: Processos, Execução de tarefas, Aderência a padrões MELHORAR: Processos, Execução de tarefas, Qualidade do produto
  13. O Product Owner O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.  Expressar claramente os itens do Backlog do Produto;  Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;  Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;  Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,  Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.
  14. O Scrum Master O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.
  15. O Time de Desenvolvimento O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo. Os Times de Desenvolvimento tem as seguintes características:  Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;  Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.  O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.  Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e,  Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios.
  16. É um framework dentro do qual você pode empregar diversos processos e técnicas. Na figura são representados todos os aspectos do Scrum: Papéis, Cerimônias e Artefatos. é perfeitamente possível encaixar a MDS no framework do Scrum. O tamanho ótimo para um Time é de 7 pessoas, mais ou menos duas pessoas. Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade. Se há mais do que 9 membros, há simplesmente a necessidade de muita coordenação. Times grandes geram muita complexidade para que um processo empírico consiga gerenciar. - O Scrum Master tem o papel de facilitador para a equipe e não atua como gerente. Ele observa a equipe e orienta onde for necessário. O Team é auto-gerido, auto-organizado. Não existe hierarquia dentro do team. - O Scrum Master é o juiz, ele não joga e não faz parte do time. Ele não determina o que cada um deve fazer durante o jogo. Ele apenas direciona e retira impedimentos. Garante a execução do Scrum / Remove Impedimentos / Revela a realidade - O espírito do Scrum é: Todos ganham ou todos perdem. Para atuar em time Scrum é necessário um perfil adequado de pessoas que são auto-gerenciáveis, colaborativas e multi-disciplinar. Problemas de gerenciamento das atividades devem ser resolvidos pelo time, o Scrum Master irá apenas retirar impedimentos. D I S C I P L I N A !! A resposta está nas pessoas e como elas compartilham seus conhecimentos e trabalham juntas... É necessário método SEMPRE...e ter disciplina para executá-lo !!
  17. Explicação da imagem: É bem conhecido o fato de que na evolução biológica, mudanças ocorrem bruscamente após intervalos separados por grandes períodos de aparente estagnação. Simulações de computador mostram que, na verdade, as mudanças ocorrem na verdade após períodos de mudanças contínuas num organismo, mas as mudanças não são visíveis até que as mudanças em subsistemas (respiratório, circulatório, digestivo etc), se combinem e produzam uma mudança externa dramática. As mudanças contínuas seriam os Sprints. As mudanças dramáticas, perceptíveis ao usuário seriam as Releases. A visão é o objetivo final, onde as as evoluções pretendem chegar
  18. Desenvolvimento Iterativo e incremental é uma estratégia de planejamento, onde o projeto é construído em partes, ou seja, em ciclos (iterações), a cada iteração é feito um novo incremento (parte do software funcional) até completar o software. Iteração=repetição Incremento = pequena porção de evolução. Processo Iterativo é aquele que se repete. Processo incremental é aquele que entrega pequenas evoluções a cada repetição.
  19. Backlog do Produto O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo em que o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são analisados e revisados. O Time de Desenvolvimento decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro da Sprint são considerados como “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima. A palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. Para facilitar a semântica do artigo, traduzirei “Backlog Grooming” como “Organização do Backlog“, considerando que organizado é por consequentemente limpo e arrumado. Alguns autores preferem chamar de Refinamento de Backlog [4]. Organizar o backlog é uma processo contínuo que envolve: A descoberta de novos itens, assim como alteração e remoção de itens antigos [2]. Quebrar Estórias muito grandes (épicos) [1]. A priorização dos itens do backlog (trazendo os mais importantes para o topo) [2]. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento [2]. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas) [2]. Incluir Critérios de Aceitação [1].
  20. User Stories Podemos definir e organizar os requisitos de um sistema utilizando User Stories (histórias de usuário). User Stories são artefatos de desenvolvimento utilizados em sistemas geridos segundo metodologias ágeis. Frente: Como &amp;lt;usuário&amp;gt; eu quero &amp;lt;meta&amp;gt; para que eu possa &amp;lt;motivo&amp;gt; Ex. como um cliente quero pesquisar valores de passagens aéreas para que eu possa fazer o meu orçamento de viagem Verso: Considero a história atendida se &amp;lt;condição&amp;gt; Ex.considero a história atendida se tiver uma tela onde eu possa consultar voos e seus respectivos valores Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema. Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema.  Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa. Alguns aspectos importantes podem ser notados no uso de User Stories: Validar se a funcionalidade é realmente necessária antes de incluí-la Análise das necessidades reais do usuário Ajuda a priorizar o que deve ser feito É mais fácil estimar o esforço que será necessário para implementar a funcionalidade O interessante no uso de User Stories é o foco nas necessidades reais e práticas do usuário.
  21. O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa final. O Planning Poker é uma prática de estimativa de tarefas bem simples e inclusive divertida, mas muito eficiente. Muito utilizada no SCRUM, esta prática funciona da seguinte forma: – Ao invés de estimar horas exatas estima-se em pontos; – Os pontos utilizados no ‘jogo’ são parecidos com a sequencia do Fibonacci, ou seja, o próximo número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, … Para simplificar é muito utilizada esta sequencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Mas vai de cada um; eu por exemplo não chegaria até o 100 porque prefiro trabalhar com tarefas menores; – Porque números tão distante entre si? Porque quanto maior uma tarefa, mais difícil de prever com precisão quantos pontos a mesma terá (e muito menos horas). Isso significa que uma estimativa de 13 pode estar entre 8 e 21… Por isso que quanto menor as tarefas, melhor para serem estimadas e a variação de pontos é melhor administrada. Sempre procure chegar no menor nível de granularidade, evitando tarefas muito grandes; – O time do projeto se reúne com o responsável pelas regras de negócio (Analista, PO, Gerente, Cliente…) e cada um recebe as cartas do Planning Poker. Mas que isso não seja um impedimento! Se não tem cartas, improvise com os dedos (foi o que fiz, rsrs); – As funcionalidades/tarefas são apresentadas, uma a uma e as dúvidas do time são sanadas; – Atribui-se o peso 2 para a menor tarefa, para que esta sirva de comparativo para as demais (ex: uma laranja é maior que um morango? E que uma manga? E assim as tarefas são comparadas tendo essa de peso 2 como parâmetro); – Inicia-se com uma atividade (pode ser por ordem de prioridade), e todos jogam a carta ao mesmo tempo; – A ideia é discutir a variação de estimativa; porque Fulano estimou X e Ciclano estimou Y… e aí… só fazendo para ver o que acontece;  – No final a equipe chega a um consenso e define o peso da tarefa, partindo para a estimativa das demais, até que todas estejam estimadas;
  22. Definition of Ready   Having a Definition of Ready means that stories must be immediately actionable. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or PBI. The Team must understand the &amp;quot;done&amp;quot; criteria and what tests will be performed to demonstrate that the story is complete. &amp;quot;Ready&amp;quot; stories should be clear, concise, and most importantly, actionable. Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.
  23. KANBAN Importante ferramenta de gestão visual para controle. Permite o aumento da eficiência, redução de desperdícios e custos Criado pela Toyota . facilidade de controlar . Todos conseguem visualizar . Atualização real time . Melhora comunicação com equipe . Aumenta a qualidade e eficiência da gestão
  24. O Burndownchart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho em desenvolvimento. Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado.  É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do seu ritmo de trabalho, verificando se o ritmo está adequado para atingir a meta da sprint, cumprindo com o que foi planejado. O Burndown é o gráfico mais simples que há no Scrum e que muitas equipes nem sempre dão o devido valor as informações referente ao processo de trabalho que ele apresenta, indiretamente. Simplesmente traçar o gráfico pelo simples fato de traça-lo é desperdício, o importante é identificar nele o que há de errado com a estratégia, o processo de trabalho, adotado pela Equipe Scrum. 
  25. A entradas para esta cerimônia é: Product Backlog detalhado e priorizado pelo P.O. O Scrum Master realiza o papel de mestre de cerimônias.
  26. A reunião é realizada em duas partes Na primeira parte, o time cuida da questão “o quê?” O Product Owner apresenta os itens de maior prioridade do Product Backlog e propõe uma Meta. A decisão referente à quantidade de itens que o time seleciona cabe somente ao Time. Somente o time pode saber o que ele é capaz de fazer no sprint. A meta não é um subconjunto de itens do Backlog, é um objetivo de negócio atingido através desses itens. Pode ser que o time não complete todo o sprint backlog mas mesmo assim atinja a meta de negócio. Meta é uma descrição que orienta o time sobre o motivo pelo qual ele está produzindo esse incremento. A razão para definição dessa meta é dar ao time a flexibilidade necessária para desenvolver as funcionalidades que julgar necessária, mas sem perder o objetivo principal de vista. Metas devem estar relacionadas ao negócio e não devem ser numéricas nem de performance.
  27. Explicar o passo-a-passo para definição da META da Sprint, como selecionar os itens do Backlog para atender a meta definida e detalhar para cada item selecionado as Tarefas que deverão ser realizadas.
  28. Não se discute outro assunto durante a reunião de trabalho.
  29. Objetivo: atualizar o quadro e definir quem fará as outras atividades. Duração: 15 minutos. Tomar cuidado para essa reunião não se transformar em discussão do trabalho. O Scrum Master começa a reunião pela pessoa imediatamente à sua esquerda e prossegue em sentido horário. Apenas essas questões devem ser respondidas. Apenas uma pessoa fala por vez; Enquanto alguém fala, todos ouvem. Dúvidas e discussões sobre os temas comentados devem ser resolvidas após a reunião diária. Galinhas não tem permissão de falar. Galinhas ficam na periferia, fora do círculo formado pelo time. Galinhas não podem falar com membros do time após a reunião. Porcos ou galinhas que não concordem com essas regras podem ser excluídos do time ou das reuniões.
  30. É realizado para mostrar o resultado da Sprint. O time apresenta os resultados. O resultado final é sempre do time. Nesse momento pode-se solicitar o TRHI. Ocorre sempre ao final do Sprint.
  31. Para a dinâmica final do treinamento: neste momento pode-se definir quem será o Scrum Master de cada time utilizar o método Russo (cada um levanta a mão e ao mesmo tempo aponta para um do grupo, aquele que for mais “apontado” será o S.M.) entregar o crachá personalizado para cada S.M. escolhido pelo time.
  32. Reunião para definir melhoria contínua. Reunião de feedback, direcionada pelo Scrum Master. * Nesse caso é muito importante que o Scrum Master seja uma pessoa imparcial ao time, pois as melhorias podem afetar até mesmo a exclusão de pessoas do time.
  33. O Scrum Master começa a reunião com as respostas compiladas. O Time prioriza em que ordem serão discutidas as melhorias em potencial. Relembrar sobre os Pilares do Scrum: transparência, inspeção e adaptação.
  34. CSM = Certified Scrum Master / CSPO = Certified Product Owner / CSD = Certified Scrum Developer. São certificações concedidas pela Scrum Alliance, após treinamentos de 2 dias com um “CST – Certified Scrum Trainer”. O que chega mais perto do PMP do PMI, é o CSP, Certified Scrum Professional, na qual é necessária comprovação de experiência de pelo menos 1 ano atuando como Scrum Master. = Tradicional = Escopo, Custo e Prazo – Fixo -&amp;gt; Foco Processo Ágil = Custo e Prazo – Fixo / Escopo – Variável -&amp;gt; Foco nas Pessoas (times autogerenciáveis) = Gestão tradicional =&amp;gt; Abordagem Scrum Escopo =&amp;gt; O escopo é definido pelo Product Backlog e Sprint Backlog Custos =&amp;gt;O custo é dado por Sprint, não por projeto. A priorização do Backlog é voltada ao ROI, equipes fixas, tempos fixos. Tempo =&amp;gt;Definição de time-boxes Comunicação =&amp;gt; Fortemente baseada nas cerimônias. Não exige planejamento, exige disciplinado Scrum. Integração =&amp;gt; O próprio framework SCRUM força a integração das disciplinas, pois aborda indiretamente todas elas. Recursos Humanos =&amp;gt; Times autogerenciados. Papéis claros (scrum master, product owner e time) Qualidade =&amp;gt; Inspeção constante. Cerimônias de revisão e retrospectiva Riscos =&amp;gt; Estratégia de aceitação. A abordagem é que, se tudo der errado , o prejuízo máximo é de 1 mês de trabalho. Aquisições =&amp;gt; Por não definir o escopo com rigidez, o tipo de contrato firmado geralmente é “Time and Material”.
  35. Só o escopo é flexível Cliente recebendo valor para negócio Mudanças são bem vindas Entrega produto = valor agregado
  36. SCRUM - É um framework dentro do qual você pode empregar diversos processos e técnicas The Scrum Guide – guia projeto CSM = Certified Scrum Master / CSPO = Certified Product Owner / CSD = Certified Scrum Developer. PMI – Project Management Insntitute PMBOK – guia projeto PMP = Project Management Professional
  37. http://blog.andrefaria.com/sessoes-de-backlog-grooming-organizacao-do-backlog http://www.desenvolvimentoagil.com.br/scrum/product_backlog https://tipratica.wordpress.com/2012/01/04/planning-poker/ https://www.scruminc.com/definition-of-ready/ https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod) http://pt.slideshare.net/isoflex/gesto-visualkanban http://blog.myscrumhalf.com/2012/01/burndown-chart-medindo-o-progresso-de-sua-sprint-e-trazendo-indicativos-do-processo-de-trabalho-da-equipe/
  38. https://support.office.com/pt-br/article/Atalhos-de-teclado-para-uso-durante-uma-apresenta%C3%A7%C3%A3o-no-PowerPoint-2010-12f0ef03-d3f4-4901-8392-e6185d1ef8d6 Exibir um slide preto vazio ou voltar para a apresentação a partir de um slide preto vazio. E ou PONTO Exibir um slide branco vazio ou voltar para a apresentação a partir de um slide branco vazio. C ou VÍRGULA
  39. Pensar fora da caixa Atitude ATEC (Evoluir Inovar Construir) Apresentação diferente, fora dos padrões do banco (cor, logo, agenda)... Vocês perceberam? pode causar estranheza, mas atingiu o objetivo = auxílio na passagem da informação. Encontro ATEC 2012 = Industrialização SCRUM – MDS Ágil Eugênio Mussak – Encontro DSPF 2012 - síntese e estímulo para reflexão - pardadigma PARA ENCERRAR A APRESENAÇÃO... No início deste ano... apresentação Fabio Armani da Banco PF.. Bonomi (missão de construir o maior banco do planeta)... Albert Einstein... Fazer a mesma coisa e esperar resultado diferente... FAZER DIFERENTE !!