O documento apresenta um grupo Scrum em Curitiba voltado para profissionais de TI, discutindo experiências e desafios na aplicação do Scrum. Destaca a importância do planejamento, comunicação e colaboração, além de introduzir conceitos como Product Owner, backlog e histórias de usuário. O texto também aborda métricas de sucesso e estimativas de esforço, enfatizando a necessidade de adaptação e melhoria contínua nos processos ágeis.

1. por Jonas Beto Rompkovski

2. Expectativas

3. Grupo Scrum Curitiba
Grupo direcionado aos profissionais de TI de Curitiba que trabalham com Scrum.
Este grupo foi criado para discutirmos sobre o Scrum e sobre as experiências que
cada um tem na sua empresa.
@ScrumCuritiba
http://scrumcuritiba.com.br

4. Onde estão os projetos?
 Quanto já foi gasto?
 Quanto ainda será?
 Quando termina?
 O que será entregue?

5. Desenvolvimento em Fases
Resultados Antecipados
Alto valor do Planejamento
Pouca Visibilidade

6. Mudanças se tornam mais
e mais caras
 Clientes não sabem o que
querem

7. SUCESSO em
apenas 34%
dos projetos
entregues
Longa duração
ADIA retorno
financeiro para
empresa
Fonte: Standish Report 2003

8.  52% dos
requisitos
entregues
 64% das
funcionalidades
são raramente
usadas
Fonte: Standish Report 2003

9. Watts Humphrey – Pai do CMMI
“O usuário não
saberá o que
ele quer até
utilizar o
sistema real
(talvez nem
assim).”

10. Paradoxo de COBB
“We know why projects fail, we know how to prevent
their failure –so why do they still fail?”
Martin Cobb

11. Guiados pelo atraso?

12. Telefone sem fio

13. Saia da Caixa

14. Princípios
 Satisfação do cliente
 Mudança
 Entregas Constantes
 Colaboração
 Motivação
 Ambiente adequado
 Comunicação face a face
 Software funcionando
 Ritmo sustentável
 Simplicidade
 Melhoria Contínua

15. Manifesto Ágil
Indivíduos e Interações Processos e ferramentas
Produto Funcionando MAIS Documentação abrangente
DO
Responder a Mudanças Seguir um plano
QUE
Colaboração com o Cliente Negociação de contratos
www.manifestoagil.com.br

16. Origem do SCRUM

17. Modelo do Ciclo de Vida

18. Fluxo do SCRUM

19. Papéis do SCRUM

20. Product Owner (PO)
Dono da Visão
do Projeto
Representa o
Cliente

21. Product Owner (PO)
Define funcionalidades
Prioriza as funcionalidade
Escolhe datas de
lançamento
Dá Feedback
Gerencia as partes
interessadas
Aceita ou Rejeita
resultados

22. Time
Pequeno
5-9 pessoas
Auto-organizado
Multi-disciplinar
Dedicado

23. Time
Define as tarefas
Estima o Esforço
Desenvolve o produto
Garante a Qualidade
Segrega os Processos

24. Scrum Master
Líder Servidor
Protetor do Time
Quebra-galho
Guia Scrum

25. Scrum Master
Remove Impedimentos
Previne Interrupções
Facilitador do Time
Suporta o Processo
Faz a Gestão

26. Visão do Produto
 Preparação do ambiente
 Identificar usuários
 Levantar requisitos
 Criar visão do projeto
 Planejar Releases

27. Visão do Produto
Para <público alvo> que <oportunidade ou necessidade>, o <nome
do produto> é um <categoria do produto> que <benefícios do
usuário>. Ao contrário <produtos concorrentes>, nosso produto
<diferenciais>.
Para um jornal que precisa necessidade disponibilizar seus serviços
na web, o sistema AgilePublisher é uma aplicação web que
disponibiliza publicadores de notícias, customização de templates,
agenda de compromissos (etc.). Ao contrário produtos dos produtos
concorrentes que o jornalista precisa retornar à redação para assim
ter sua notícia publicada, nosso produto permite ao jornanista que
pré-publique a notícia diretamente do seu smartyphone ou notebook
para que a redação aprove disponibilizando mais tempo para que ele
possa realizar mais matérias.

28. Product Backlog
 Lista de funcionalidade que o cliente
necessita
 Os itens da lista = itens do backlog
 1 Product Backlog = 1 PO
 Todos podem incluir itens de backlog
 Somente o PO pode priorizá-las
 PO deve entender cada história
 PO pode priorizar novamente
no início de cada Sprint.

29. Product Backlog (Exemplo)
ID Descrição
1 Como jornalista, gostaria de pré publicar as minhas matérias via smartyphone
para que eu não tenha que retornar a redação para que as matérias saiam mais
rapidamente na internet.
2 Como redator chefe, gostaria de aprovar ou não as notícias pré publicadas pelos
jornalistas para que tenhamos a garantia de que as notícias encaminhadas sejam
adequadas e não tenham erros de português.
3 Como gerente do recursos humanos, gostaria de um relatório dos jornalistas que
mais encaminham notícias com erros de português para que eu possa
providenciar cursos de reforço para nossos profissionais.

30. Histórias (User Stories)
 Funcionalidade que terá valor tanto aos usuários
quanto a quem estiver adquirindo o sistema.
 As histórias têm 3 aspectos (3C) segundo Ron Jeffries
 Cards – histórias são escritas em cartões ou post-its
(cards), naturalmente forçando as histórias a serem
pequenas.
 Conversation – A história escrita no cartão serve como um
lembrete, tornando-se um convite ao diálogo
(conversation).
 Confirmation – O cliente define (implícita ou
explicitamente) uma maneira de validar (Confirmation)
esse pedido. Geralmente com testes de aceitação.

31. Padrões de História
Como jornalista, gostaria de pré publicar as
Como um <usuário>, gostaria de minhas matérias via smartyphone para que eu
<funcionalidade> para <valor de não tenha que retornar a redação para que as
negócio>. matérias saiam mais rapidamente na internet.
Para que eu não tenha que retornar a
Para obter/alcançar <valor de redação para que as matérias saiam mais
negócio>, como um <usuario> eu rapidamente na internet, como jornalista
gostaria da <funcionalidade>. eu gostaria de pré publicar as minhas
matérias via smartyphone.
Idéia Corretor Ortográfico

32. E as estimativas?
Estimativa
Compromisso

33. E as estimativas?
 Tamanho x tempo

34. Tamanho
 Story Points
 Medida relativa do tamanho de uma história.
 Não existe fórmula
 É resultado do agrupamento de fatores: esforço
envolvido no desenvolvimento da funcionalidade,
a complexidade, riscos, etc.
 Ideal Days
 A história estimada será o seu único trabalho
 Tudo que você precisar estará disponível
 Não haverão interrupções

36. ID Descrição Estimativa
1 Como jornalista, gostaria de pré publicar as minhas matérias via 3
smartyphone para que eu não tenha que retornar a redação para
que as matérias saiam mais rapidamente na internet.
2 Como redator chefe, gostaria de aprovar ou não as notícias pré 5
publicadas pelos jornalistas para que tenhamos a garantia de que as
notícias encaminhadas sejam adequadas e não tenham erros de
português.
3 Como gerente do recursos humanos, gostaria de um relatório dos 5
jornalistas que mais encaminham notícias com erros de português
para que eu possa providenciar cursos de reforço para nossos
profissionais.

38.  É o total de story points entregues
em uma iteração pela equipe.
 Exemplo...
 Velocidade em conjunto com o
total de story points do projeto,
pode gerar um cronograma.
 Como vou descobrir a velocidade
da 1ª iteração?

39.  Velocidade da Equipe: 20
 Total de Story Points: 200
 Total de Iterações do Projeto: 200/20 = 10
 Duração da Iteração: 2 semanas
 Pode ser que eu tenha o produto em: 20
semanas.

42.  Priorização baseada em números
 Permite encaixe de funcionalidades “sem alterar” prioridades estabelecidas
anteriormente.
ID Descrição Estimativa Import.
1 Como jornalista, gostaria de pré publicar as minhas matérias via 3 8
smartyphone para que eu não tenha que retornar a redação para
que as matérias saiam mais rapidamente na internet.
2 Como redator chefe, gostaria de aprovar ou não as notícias pré 5 4
publicadas pelos jornalistas para que tenhamos a garantia de que
as notícias encaminhadas sejam adequadas e não tenham erros de
português.
3 Como gerente do recursos humanos, gostaria de um relatório dos 5 6
jornalistas que mais encaminham notícias com erros de português
para que eu possa providenciar cursos de reforço para nossos
profissionais.

44.  Duas a quatro semanas
 Timebox
 Nenhuma mudança
 Objetivo
 Local definido para reunião diária
 Disponibilidade de cada membro da equipe
 Data definida para apresentação do Sprint.

45.  SP 1: PO seleciona o que
será feito
 SP 2: Equipe decompõe o
que será feito
 Fornece informações
suficientes para equipe.
 Proporciona ao PO
confiança suficiente na
equipe.

46.  Estabelecer o objetivo do Sprint
 Não esquecer da velocidade da equipe
 O PO seleciona itens do Product Backlog
 O PO tira dúvidas sobre os itens
selecionados.

47. QUALIDADE EXTERNA
É percebida pelo cliente e pode ser
negociável.
QUALIDADE INTERNA
Afeta manutenibilidade e nunca
poderá ser negociada.

48. Tarefas identificadas e estimadas (1 a 8 horas)
De forma colaborativa, não é feito pelo Scrum
Master
Equipe compromete-se a concluir as tarefas
Construção do Sprint Burndown

51. Evitar síndrome dos 90%
Codificado, Comitado, Testado,
Publicado em Ambiente de
Testes, documentado e
funcionando
= DONE DONE

52. O que eu fiz
desde a última
reunião?
O que vou fazer
até a próxima?
Que coisas estão
atrapalhando
meu trabalho?
Todos podem
participar
Apenas o Time
fala
Não se resolvem
problemas
Máximo de 15
minutos
De pé

53. Satisfação do
Product Owner
Feedback do
Produto

54. Reflete, aprende e planeja melhorar
dentro de 3 questionamentos
básicos:
1. O que aconteceu durante o Sprint
que deve continuar?
2. O que aconteceu durante o Sprint
que precisa ser melhorado?
3. O que deve Parar?

56. Planejamento
Sucessivo e
Constante
Mini-projetos de
baixo risco

57. Permite

mudanças em
intervalos fixos
 Aprendizagem
a cada
liberação

58. Time to Market
Valor entregue de forma incremental

59. Testes acontecem
continuamente
Melhoria do Processo

61. Força
Disciplina
Coragem
Vigor
Paixão
Coaching
Times Estáveis
Multi-funcional
Cliente disponível

62.  Não há práticas de Engenharia
 Parece simples, mas...
 Não é Bala de Prata
 Não está completo
 Leva tempo

64. Blog do Jonas
blogdojonas.com.br
Twitter
@jonastlc
E-Mail
jonas@blogdojonas.com.br