Upload
jrompkovski
View
890
Download
1
Embed Size (px)
DESCRIPTION
Palestra realizada por Jonas Beto Rompkovski no 1º Curitiba Scrum Day. Evento realizado pelo grupo Scrum Curitiba no dia 07/12/2010 na OPET
Citation preview
por Jonas Beto Rompkovski
Expectativas
Grupo Scrum Curitiba
http://scrumcuritiba.com.br
@ScrumCuritiba
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.
Quanto já foi gasto? Quanto ainda será? Quando termina?
O que será entregue?
Onde estão os projetos?
Desenvolvimento em FasesResultados AntecipadosAlto valor do PlanejamentoPouca Visibilidade
Mudanças se tornam mais e mais caras
Clientes não sabem o que querem
SUCESSO em apenas 34% dos projetos entregues
Longa duração
ADIA retorno financeiro para empresa
Fonte: Standish Report 2003
52% dos requisitos entregues
64% das funcionalidades são raramente usadas
Fonte: Standish Report 2003
Watts Humphrey – Pai do CMMI
“O usuário não saberá o que ele quer até
utilizar o sistema real (talvez nem
assim).”
“We know why projects fail, we know how to prevent their failure –so why do they still fail?”
Martin Cobb
Paradoxo de COBB
Guiados pelo atraso?
Telefone sem fio
Saia da Caixa
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
Princípios
Manifesto Ágil
Indivíduos e Interações
Produto Funcionando
Responder a Mudanças
Colaboração com o Cliente
Processos e ferramentas
Documentação abrangente
Seguir um plano
Negociação de contratos
MAIS
DO
QUE
www.manifestoagil.com.br
Origem do SCRUM
Modelo do Ciclo de Vida
Fluxo do SCRUM
Papéis do SCRUM
Product Owner (PO)
Dono da Visão do Projeto
Representa o Cliente
Product Owner (PO)
Define funcionalidades
Prioriza as funcionalidade
Escolhe datas de lançamento
Dá Feedback
Gerencia as partes interessadas
Aceita ou Rejeita resultados
Time
Pequeno5-9 pessoas
Auto-organizadoMulti-disciplinar
Dedicado
Time
Define as tarefasEstima o Esforço
Desenvolve o produtoGarante a QualidadeSegrega os Processos
Scrum Master
Líder Servidor
Protetor do Time
Quebra-galho
Guia Scrum
Scrum Master
Remove Impedimentos
Previne Interrupções
Facilitador do Time
Suporta o Processo
Faz a Gestão
Preparação do ambiente Identificar usuários Levantar requisitos Criar visão do projeto Planejar Releases
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 quedisponibiliza 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.
Visão do Produto
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.
Product Backlog
ID Descrição
1 Como jornalista, gostaria de pré publicar as minhas matérias via smartyphonepara 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.
Product Backlog (Exemplo)
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.
Histórias (User Stories)
Como um <usuário>, gostaria de <funcionalidade> para <valor de negócio>.
Para obter/alcançar <valor de negócio>, como um <usuario> eu gostaria da <funcionalidade>.
Idéia
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.
Para que eu não tenha que retornar a redação para que as matérias saiam mais rapidamente na internet, como jornalista eu gostaria de pré publicar as minhas matérias via smartyphone.
Corretor Ortográfico
Padrões de História
Compromisso
E as estimativas?
Estimativa
Tamanho x tempo
E as estimativas?
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
Tamanho
ID Descrição Estimativa
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.
3
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.
5
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.
5
É 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?
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.
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 smartyphone para que eu não tenha que retornar a redação para que as matérias saiam mais rapidamente na internet.
3 8
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.
5 4
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.
5 6
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.
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.
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.
QUALIDADE EXTERNA
É percebida pelo cliente e pode ser
negociável.
QUALIDADE INTERNA
Afeta manutenibilidade e nunca
poderá ser negociada.
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
Evitar síndrome dos 90%
Codificado, Comitado, Testado, Publicado em Ambiente de Testes, documentado e funcionando
= DONE DONE
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é
Satisfação do Product Owner
Feedback do Produto
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?
Planejamento Sucessivo e
Constante
Mini-projetos de baixo risco
Permite mudanças em
intervalos fixos
Aprendizagem a cada
liberação
Time to Market
Valor entregue de forma incremental
Testes acontecem continuamente
Melhoria do Processo
Força
Disciplina
Coragem
Vigor
Paixão
Coaching
Times Estáveis
Multi-funcional
Cliente disponível
Não há práticas de Engenharia
Parece simples, mas...
Não é Bala de Prata
Não está completo
Leva tempo