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

Blog do Jonas

blogdojonas.com.br

Twitter

@jonastlc

E-Mail

jonas@blogdojonas.com.br