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?
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
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
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
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é
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