Uma visão de Scrum e Kanban.
Comparando e utilizando as duas visões combinadas para obter o melhor dos dois mundos.
Uma explicação rápida de quais os ganhos das duas formas de pensar e como eles podem ser combinados. A importância de não se limitar a um framework e adaptá-los ao dia a dia das empresas preparando-as para um ambiente escalável.
2. DAVID BARROS SANTOS RIBEIRO
36 anos – PE / SP / SC
Pós Graduação: Gestão Empresarial e Negócios (INPG)
Pós Graduação: Gestão de Projetos (SENAC)
Graduação: Sistemas de Informação (SENAC)
Técnico: Desenvolvimento de Software (IBRATEC)
Certificações:
• OKRs, AdministraManagement 3.0
• PSM I (Scrum.org)
• CSM, A-CSM, CSPO (Scrum Alliance)
• Scrum@Scale (Scrum Alliance / Scrum.inc)
• KMP I e II (Kanban University)
Cargo atual:
• Product Owner PagueVeloz
3. BASE DE TUDO - ???
Manifesto Ágil
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação
abrangente
Colaboração com o cliente mais que negociação de
contratos
Responder a mudanças mais que seguir um plano
4. FOCOS QUE SE DEVE TER
Scrum:
• Foco na entrega de valor
Kanban
• Foco na entrega do serviço
Hipnose (Plus)
• Foco nos seres humanos
6. KANBAN – POLÍTICAS / M. PUXADO / WIP / C. POINT
Cycle timeReaction time
PB (-)
•Estórias / Épicos
•Ideia
•Ordenado por valor
Análise (5~30)
•Doing:
•Estórias modelo
canônico
•Critérios de Aceite
•BDD
•Regras de
Negócio.
•Story Map
•Done:
•Estória “pronta”
•Critérios de aceite
•Story Map
Refinamento (5~20)
•Doing:
•Questionamento
do DT
•Estimativa do DT
•Quebra de estórias
•Done:
•Estimado pelos
Dev Team
•Story Points
(Fibonacci)
•Estórias quebradas
Sprint Backlog (20)
•Itens ordenados
por Valor
•Itens selecionados
para a Sprint
DEV (5)
•Doing:
•Desenvolvimento
•Pull Request
Review
•Critérios de aceite
automatizados
•Teste de unidade
•Teste funcional ou
de integração
•Validação do DoD
•Done:
•Testes
automatizado de
70% de cobertura
•100% de testes
com sucesso
QA (2)
•Doing:
•Mapeamento dos
critérios de aceite
•Teste das estórias
•Teste dos critérios
de aceite
•Done:
•Testado
•Validado
•Sem erros
UAT (20)
•Doing:
•Teste do PO
•Teste dos
Stakeholders
•Done:
•Testado
•Validado
•Sem erros
•Objetivo
alcançado
PRD (N/A)
•Testado por QA e
UAT
•Testes
automatizados
Lead time
Commitment Point
(ponto de comprometimento)
Modelo Puxado
(Observar de trás pra frente)
7. KANBAN – POLÍTICAS / M. PUXADO / WIP / C. POINT
Cycle timeReaction time
PB (-)
•Estórias / Épicos
•Ideia
•Ordenado por valor
Análise (5~30)
•Doing:
•Estórias modelo
canônico
•Critérios de Aceite
•BDD
•Regras de
Negócio.
•Story Map
•Done:
•Estória “pronta”
•Critérios de aceite
•Story Map
Refinamento (5~20)
•Doing:
•Questionamento
do DT
•Estimativa do DT
•Quebra de estórias
•Done:
•Estimado pelos
Dev Team
•Story Points
(Fibonacci)
•Estórias quebradas
Sprint Backlog (20)
•Itens ordenados
por Valor
•Itens selecionados
para a Sprint
DEV (5)
•Doing:
•Desenvolvimento
•Pull Request
Review
•Critérios de aceite
automatizados
•Teste de unidade
•Teste funcional ou
de integração
•Validação do DoD
•Done:
•Testes
automatizado de
70% de cobertura
•100% de testes
com sucesso
QA (2)
•Doing:
•Mapeamento dos
critérios de aceite
•Teste das estórias
•Teste dos critérios
de aceite
•Done:
•Testado
•Validado
•Sem erros
UAT (20)
•Doing:
•Teste do PO
•Teste dos
Stakeholders
•Done:
•Testado
•Validado
•Sem erros
•Objetivo
alcançado
PRD (N/A)
•Testado por QA e
UAT
•Testes
automatizados
Lead time
Commitment Point
(ponto de comprometimento)
Delivery Point
(ponto de entrega)
Modelo Puxado
(Observar de trás pra frente)
8. KANBAN - CLASSES DE SERVIÇO
Expedite (Urgentes) Fixed Date (Data Entrega)Standard (Dia a dia)
9. BASE DE TUDO - ???
Scrum
• Abertura (Conversar abertamente sobre os problemas)
• Coragem (Ter coragem para dizer que algo está errado)
• Respeito (Respeitar as pessoas que fazem parte da equipe)
• Foco (Foco no objetivo da entrega das Sprints)
• Comprometimento (Comprometimento em entregar o que foi combinado para a Sprint)
Kanban
• Visualize as etapas do trabalho
• Limite o trabalho em progresso
• Torne as politicas do processo explícitas
• Implemente mecanismos de feedback
• Melhore colaborativamente usando modelos e métodos científicos
11. OBTENDO O MELHOR DA EQUIPE
Ambiente Saudável
• Respeito
• Abertura
• Comprometimento
• Evitar ambientes extremamente políticos
Equipe
• Equipes pequenas
• Para o lado bom ou lado ruim, o time é responsável
Entregas
• Foco
• Coragem
• Evitar Mudanças de Contexto
• Explicitar objetivos
Métodos e Frameworks
• Observar como referência
• Aprofundar os processos
12. AO LONGO DO TEMPO...
A necessidade de ter um Scrum Master ou Product Owner próximo ao time diminui com o passar do tempo.
A necessidade do Scrum Master ficar próximo da equipe de desenvolvimento diminui (mas nunca acaba)
ao longo do tempo, já que a equipe vai entendendo cada vez mais como funciona o processo. Fazendo com que o
Scrum Master fique mais livre para verificar novos processos, melhorias e novidades ao invés de ficar
apenas ensinando a equipe como o Scrum funciona.
A necessidade do Product Owner ficar próximo da equipe de desenvolvimento diminui (mas nunca acaba)
ao longo do tempo, já que a equipe vai entendendo cada vez mais como funciona o negócio. Porém, o negócio muda
constantemente. Fazendo com que o Product Owner fique mais livre para verificar novos negócios e melhorar o
levantamento junto ao UX. Por exemplo: Fazendo reuniões, questionários e atualizando o Story Map.