Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

SCRUMTransformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

©2009 - Hélio Medeiros e Germano Carvalho


Quem somos ?

Hélio MedeirosAnalista de Sistemas

SINFO - UFRN

Blog: http://heliomedeiros.comEmail: [email protected]

mailto:[email protected]

mailto:[email protected]

Quem somos ?

Germano CarvalhoAnalista de Sistemas

Unimed Natal


NOSSO SOFTWARE FUNCIONA ?


?Será mesmo ?


ENTÃO OS PROJETOS DE SOFTWARE FUNCIONAM ?


? !


O MODELO ANTIGO NÃO FUNCIONA !!!


QUE TAL UM NOVO MODELO ?PRONTO PARA A PROPOSTA !!!


PROJETOS

COM MENOS STRESS !!!


QUE REALMENTE FUNCIONEM !



QUE CONDIZEM COM AS NECESSIDADES

DE FORMA ÁGIL E PRODUTIVA


Nossa Product Backlog

Parte 1 - Metodologias Ágeis

Parte 2 - Conhecendo o Scrum

Parte 3 - Experimentando agilidade com Scrum


Nosso Sprint Backlog


1 Metodologias Ágeis

Realidade da AGILE ?

Será que vai vingar ?

Será que não vai vingar ?

Vale a pena investir nisso?

Caso eu invista, conseguirei aproveitar algum conhecimento ?



entrevista fornecida para o Application Development Trends, Gabrielle Benefield - diretora de métodos e práticas do Yahoo!


200 equipes



Realidade da AGILE;

Por que precisamos de uma metodologia?

Introdução às metodologias ágeis;



Gato de Cheshire.Alice no país das maravilhas, de Lewis Carroll

Precisamos de metodologia ?Como escolher uma ?

ONDE se aplica

O QUE influencia

Quais as visões históricas empregadas aos projetos;

Qual o propósito de um processo de desenvolvimento;

Quais a estatísticas caóticas para projetos de software;


Precisamos de metodologia ?Como escolher uma ?

O que é projeto ?Apenas 3 décadas... mais várias visões diferentes

“Um projeto é um problema agendado para solução”

Dr. Joseph M. JuranO "pai" da qualidade, criador do

princípio de pareto (80-20)

David J. AndersonCriador do FDD e uma das maiores

mentes de Agile mundial

“Um projeto é uma coleção de valor agendada para realização”


O que é projeto ?Composição de um ambiente de um projeto de software


O que é projeto ?Exemplo de influência causada pelos itens do ambiente de projeto


CULTURA{ESPOSA JAPONESACARDÁPIO JAPONÊS

TRADIÇÕES JAPONESAS> MANTER SO COSTUMES

2ªSEXTA-FEIRA



FICAR DESEMPREGADOacontece...

encontrar seu amigo Steve... vegetariano...

na 2ª sexta e pedir emprego em um jantar... NA SUA CASA...

PODE SER BEM DIFÍCIL?


Eu conheço algum prato vegetariano ?

Eu tenho utensílios para preparar estes pratos ?

Será que minha esposa possui as técnicas necessárias ao preparo dos pratos ?

O que será que minha família está pensando enquanto a estas mudanças ? Estão felizes ? Receptivos ? Colaborativos ?


O que é projeto ?Características dos componentes

Pessoas- Conhecimento e habilidades

- Motivação e comprometimento-Reconhecimento

-Crescimento

Cultura- Personalidade coletiva

- Risco X Segurança- Ética

- O “jeito de ser” da empresa

Processos- Disciplina e coordenação

- Gerenciamento- Padronização

- Institucionalização

Ferramentas- Produtividade

- Controle- Eficiência

- Automação


Escolha um contexto qualquer e descreva resumidamente:

1. Que pessoas estão envolvidas ?2. Quais processos são observáveis ?3. Quais tecnologias são aplicadas ?4. Como a cultura influencia ou é influenciada ?

AtividadeAnalisando os componentes de um contexto qualquer


Precisamos de metodologia ?Como categorizar a complexidade de um projeto de software ?

Ogunnaike and Ray: Process Dynamics, Modeling and Control


Precisamos de metodologia ?O Chaos Report


0%

25%

50%

75%

100%

2004 2006 2009

33%35%33%

52%46%43%

15%19%24%

Falhou Necessitou adequações Bem sucedido



0

35

70

Adequações necessárias

Aumento nos custosAumento no tempoAlteração de funcionalidades

Isso significa que, se fabricássemos aviões...


32%pousariam sem problemas

44%pousariam com problemas

24%cairiam


COMO lidar com REQUISITOS;

COMO melhorar a COMUNICAÇÃO;

COMO estimar as ATIVIDADES;

COMO entregarmos os PRODUTOS;

COMO difundir o CONHECIMENTO;

QUAL o ciclo de vida do PRODUTO;

COMO organizar nossa PRODUÇÃO;

COMO conseguiremos QUALIDADE;

Precisamos de metodologia ?Quais itens analisar na escolha ?


Cite quais são os principais prob lemas no processo de desenvolvimento de software que você esteja envolvido.

Cite o que você espera de uma metodologia para desenvolvimento de software.

AtividadePor que precisamos de uma metodologia?




Realidade da AGILE;

Por que precisamos de uma metodologia?

Introdução às metodologias ágeis;


Introdução às abordagens ágeisO que NÃO é agilidade?


Introdução às abordagens ágeisO que é agilidade?

Jim HighsmithUm dos principais escritores sobre

AGILE e criador da ASD.

“Agilidade é a habilidade para criar e responder à mudança, para lucrar num ambiente turbulento de

negócios.”

“Agilidade é a habilidade para equilibrar flexibilidade e estabilidade.”


Introdução às abordagens ágeisOs princípios


Introdução às abordagens ágeisO manifesto Ágil

Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowlor, Ken

Shwaber e Jeff Sutherland;


Introdução às abordagens ágeisO manifesto Ágil

http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho

Indivíduos e a interação entre eles processos e ferramentas

Produto em funcionamento documentação abrangente

Colaboração com o cliente negociação de contratos

mais que

mais que

mais que

Responder a mudanças seguir um planomais que

http://agilemanifesto.org


custo fixo

conjunto de funcionalidades;

priorizado pelo cliente

podemos perder funcionalidades, nunca datas;

prioridades no “final da lista” podem ficar de fora;

Flexibilidade está nas funcionalidades, não no prazo ou no custo;

Introdução às abordagens ágeisDesenvolvimento iterativo



Produto

novo release a cada X meses

release 1 release 2 release 3 ... release n

novo iteracao a cada X semanas

iteração 1 iteração 2 iteração 3 iteração 4 ...



Produto

release 1

iteração 1 iteração 2 iteração 3 iteração 4 ...Func. AFunc. EFunc. G

Func. BFunc. FFunc. JFunc. Z

Func. CFunc. HFunc. L

Func. DFunc. I

O Release 1 terá as seguintes funcionalidades:

- Funcionalidade A- Funcionalidade B- Funcionalidade C- Funcionalidade D- Funcionalidade E- Funcionalidade F

- Funcionalidade G- Funcionalidade H- Funcionalidade I- Funcionalidade J- Funcionalidade L- Funcionalidade Z


Introdução às abordagens ágeisO ciclo de vida de projetos ágeis

Visão

EspeculaçãoAdaptação

Exploração

Fechamento

Visão do Produto

Funcionalidades Prontas

Produto Final©2009 - Hélio Medeiros e Germano Carvalho



2 Conhecendo o Scrum




O que é Scrum?O ciclo de vida do Scrum;Os papéis no Scrum;O conceito de Sprint: Entregando frequentemente software de valor;Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano;Sprint Planning Meeting: Planejamento na medida certa;Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes;Sprint Review: Apresentando o resultado;Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar;

O que é Scrum ?Depende de onde você está


Criada no início da década de 1990

Estados Unidos.

O que é Scrum ?O origem do Scrum

TOYOTA

Lean Management


O que é Scrum ?Scrum NÃO é uma bala de prata!


papéis bem difinidos, e é de fácil adaptação;

SCRUM APONTA OS ERROS !

Um dos aspectos positivos do Scrum é a sua adaptabilidade, portanto, o conhecimento das suas práticas é extremamente importante, por permitir a aplicação das mesmas de forma variada.

O que é Scrum ?A objetividade do Scrum


O que é Scrum ?Problemas com a adaptabilidade

Sprint Planning Meeting

Daily Meeting

Um dia inteiro sem produção ?

Horários ? Para que?


O que é Scrum ?Liderança-colaboração SIM ! Comando-controle NÃO !

Comando-Controle é muito lento porque:✓Não permite processar informações rapidamente;✓Não permite tomar decisões rapidamente;✓Não envolve ou motiva ao trabalho;✓Não propicia responsabilidade diária sobre o andamento à equipe;

Comando - Controle

Liderança - Colaboração


Explore a diferencça entre planejar uma viagem se cada sentença começa com:

AtividadeA arte do possível

“ Sim, mas ”

“ Sim, e ”


O ciclo de vida do SCRUM?

© 2007 Alexandre Magno - As Armadilhas do Scrum


O ciclo de vida do Scrum é baseado em iterações bem definidas de duas a quatro semanas, chamadas SPRINTS.

Antes de cada Sprint, realiza-se uma reunião de planejamento ( Sprint Planning Meeting ) em que o time (Team Members) de desenvolvimento tem contato com o cliente ( Product Owner ) para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint.

A próxima fase é a execução da Sprint.



Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias ( Daily Meeting ) de não mais de 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown.

Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão ( Sprint Review ), em que o time demonstra o produto gerado na Sporint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva ( Sprint Retrospective ), uma reunião de lições aprendidas, com o objetivo de melhorar o processo, time eou produto para a próxima Sprint.



Os papéis no Scrum Pigs e chickens são papéis no Scrum ?


Os termos pig ( porco ) e chicken ( galinha ) são utilizados em Scrum de forma informal.

Pig: Alguém que ocupa um dos três papéis do Scrum ( Team memeber, Product owner, Scrum Master) e tem um total comprometimento com o projeto.

Chicken: Alguém que tem interesse no produto a ser gerado, mas não ocupa nenhum papel formal do Scrum.

Os papéis no Scrum Pigs e chickens são papéis no Scrum ?


Os papéis no ScrumO Product Owner (PO)

O Product Owner representa o cliente ou patrocinador do projeto, e faz parte do time que entregará o produto.


Os papéis no ScrumO Product Owner (PO)

Define funcionalidadesFaz o plano de ReleaseProduct visionROIPriorizaçãoAjusta escopoAceita ou rejeita um SprintDisponibilização técnicos de domínio


Os papéis no ScrumO Scrum Master (SM)

O Scrum Master, diferentemente dos gerentes de projeto na maioria das práticas e metodologias, difere do tradicional “comando e controle”. Em Scrum, um SM trabalha com e, principalmente, para o time.


Responsável pelo processoGerenciamentoValores e princípiosRemove impediemntosGarante a produtividadeColaboração entre papéisProtege o time de Interferências

Os papéis no ScrumO Scrum Master (SM)


Os papéis no ScrumOs membros do time

Os membros do time são pessoas que estão comprometidos a fazer o trabalho necessário para atingir a meta de uma Sprint.

Em Scrum não temos arquitetos, testers ou programadores, temos sim, membros com perfis de arquiteto, de tester ou de programador... mas que podem atuar em papeis secundários para garantir o alcance da meta.


Suas responsabilidades são:

Definir a meta do Sprint;Estar comprometido com o trabalhoColaborar com outros membros do time e ajudar a torná-lo auto-gerenciado;Estimar itens do backlog de forma realista;Participar das reuniões diárias;Compartilhar conhecimento com a equipeManifestar impedimentos;

Os papéis no ScrumOs membros do time


Os papéis no ScrumFluxo simples

Product owner

Coloca itens (priorizados) Pega itens

Time

Coloca

Sprint Backlog

Product Backlog

O que sobrar...devolve

Scrum Master

Serve


2, 3 ou 4 semanas;Frequentemente entregando algo de valor para o cliente;Time multi-funcional com não mais que oito membros;Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-box específico;Os membros do time da Sprint são os responsáveis por estimar os itens que compõem o desejo do cliente e dar a palavra final sobre o que será possível ser desenvolvido naquele time-box;

O conceito de SprintCaracterístivas


Planejamento ( Sprint Planning Meeting ): Daily ScrumExecução ( The Sprint ):Revisão ( Sprint Review ):Retrospectiva ( Sprint Retrospective ):

O conceito de SprintComposição


O cancelamento de um Sprint antes de seu termino acontece nas seguintes condições:O time pode cancelar se sentir que não conseguirá atingir a sua meta, lembrando que cancelamentos consecutivos são falhas apontadas pelo Scrum, qual o problema ?Gerentes podem cancelar um Sprint caso fatores externos influenciem diretamente no valor da meta do Sprint;Caso um Sprint seja cancelado deve ser iniciado o planejamento do próximo Sprint imediatamente;

O conceito de SprintCancelamento


O Product Backlog representa em ítens a visão do produto e é o primeiro passo a ser dado em todo projeto Scrum;

O Product Backlog existirá por todo o ciclo de vida do projeto, e não da Sprint.

Este é regularmente atualizado pelo Product Owner para refletir mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias...

O Product Backlog pode ser composto por diferentes tipos de itens: funcionalidades, exploração técnica, estudo, documentação, bugs, requisitos de desenvolvimento...

Só exisite um Product Backlog durante todo o projeto.

Product BacklogEntendendo


Product BacklogA física do Product Backlog

Alta Prioridade

Baixa Prioridade

Cada Sprint implementa os requisitos de prioridade mais alta

Cada novo item é priorizado e inserido pelo PO a qualquer momento

Todos os itens podem ser repriorizados pelo PO

Itens podem ser removidos pelo PO a qualquer momento


Product BacklogExemplo

PRODUCT BACKLOGPRODUCT BACKLOG

Id Item Estimativa Prioridade12

34

5

6

7

8

9

Refatorar o banco de dados 32 10Relatório de Vendas por unidade e período 8 8

Suporte a cartão de crédito Visa no processo de Vendas 13 9Relatório Gerencial com Estatísticas de Vendas 5 7

Alterações na tela de entrada do sistema 5 6

Estudar nova versão da framework de mapeamento O/R 5 5

Consulta parametrizada de Vendas 3 4

Criação do Help 13 4

Implementar internacionalização 8 2Total 92 6


A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em cena no início de cada Sprint.

Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a participar em determinados momentos da reunião, desde que agreguem valor à mesa e tenham seu convite aprovado pelo Product Owner.

Sprint Planning MeetingRegras


Pela prática, é percebido que a duração desta reunião segue a seguinte tabela:

Sprint Planning MeetingRegras

DURAÇÃOSprint SPM #1 SPM #2

4 semanas3 semanas2 semanas

4 horas 4 horas3 horas 3 horas2 horas 2 horas


Na primeira parte, o Product Owner e o time, sendo facilitados pelo Scrum Master, realizamuma revisão no Product Baklog, discutindo sobre o propósito e metas de cada item e dando a oportunidade para que o PO exponha seus desejos. O time seleciona os itens que acredita que possam ser desenvolvidos na próxima Sprint e define a meta.

Sprint Planning MeetingSPM #1

PRODUCT BACKLOGPRODUCT BACKLOG

Id Item Estimativa

Prioridade1

2

34

Refatorar o banco de dados 32 10Relatório de Vendas por unidade e período 8 8

Suporte a cartão de crédito Visa no processo de Vendas

13 9Relatório Gerencial com Estatísticas de Vendas

5 7Total 58 9

Meta do Sprint:Refatorar o banco de dados e implementar relaórios de vendas necessáirios para as tomadas de decisões finais.


Velocidade é uma medida de produtividade do time;

Esta medida representa a taxa de trabalho que o time conseguiu completar durante um Sprint;


E serve de guia para o planejamento de Sprints. Por exemplo, se na Sprint anterior o time foi capaz de completar 55 pontos, esta quantidade de trabalho realizado passa a ser a velocidade do time e contribuirá durante o planejamento do próximo sprint;

Serve de guia para o planejamento de Releases e progresso de projeto. Ex.: Temos um Product Backlog de 165 pontos.



Product Backlog

Selecionar Sprint BacklogComo? Não sei nossa velocidade

Mini-Sprint BacklogExecutado com 13 pontos ( ou X horas)

Sprint BacklogVelocaidade Inicial: 34 pontos ( ou x * 3 horas )


Quantas bolas de tênis você e seu time conseguem colocar no mochila em 2 minutos ?

AtividadeJogo da Velocidade



Durante esta reunião o Product Owner ainda pode realizar alterações na priorização de itens;

Deve se discutir também sobre estimativas iniciais ou revisão/adaptação da estimativa dos itens;

O esforço estimado entre os itens selecionados deve ser negociado entre o time e o PO, sempre praticando o bom senso;



Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum. O Planning Poker é uma das mais populares, onde utilizam-se cartas numeradas seguindo a tabela de fibonacci.


Sprint Planning MeetingPlanning Poker...?

O Planning Poker:

vem sendo a melhor técnica utilizada em projetos que utilizam processos ágeis;

combina opinião de especialistas, analogias, bom senso e uma forma agradável para se gerar estimativas;

envolve todos os perfis de membros (programadores,testers, DBAs, analistas, designers entre outros);

utiliza-se dos números da sequência de Fibonacci;

deve ser aplicado para qualquer novo Item;


Sprint Planning MeetingComo funciona o Planning Poker ?

Cada participante deve possuir o seu conjunto de cartas contendo os valores válidos, de acordo com a escala adotada;

Para cada Product Backlog Item a ser estimado, o facilitador (normalmente o Product Owner ou Especialista de Négocio) deve realizar uma breve descrição;

Após todas as dúvidas sobre o item serem respondidas, cada membro do time deve escolher uma carta representando a sua estimativa. A carta selecionada não deve ser vista pelos outros membros do time enquanto todos ainda não tenham selecionado a sua;

Estimating & Planning - Mike Cohn©2009 - Hélio Medeiros e Germano Carvalho




Todos devem, ao mesmo tempo, mostrar sua carta de estimativa;

Se as estimativas divergem, os participantes que apresentaram carta com maior e menor valor devem explicar o motivo que o levaram a escolhê-la. Isto não deve de forma alguma ser feita de forma agrssiva, ou mesmo defensiva, mas apenas como uma troca de conhecimento entre visões diferentes sobre o esforço necessário para a conclusão do item. Estimating & Planning - Mike Cohn





Após as devidas explicações, inicie um novo Round repetindo o ciclo, até que haja um consenso quanto ao tamanho do item;

Normalmente, as estimativas entram em convergência já no segundo round, ou no máxima no terceiro. Mas caso isso não aconteça, o ciclo deve ser continuado.

1 2 3 5 13


VídeoExperiências com Planning Poker


Sprint Planning MeetingPor que o Planning Poker funciona ?

Estimating & Planning - Mike Cohn

Apresenta múltiplas opniões de especialistas quanto à estimativa de um item, e como Scrum trabalha com times multi-perfis temos praticamente todas as áreas de conhecimento cobertas;

Porque Planning Poker estimula o dialogo durante os rounds, e cada membro do time tem que explicar o porque de sua estimativa, ampliando o compartilhamento de conhecimento;

Estudos mostram que estimativas feitas em grupo vem sendo mas bem sucedidas que estimativas individuais;





A segunda parte da reunião de planejamento deve ocorrer imediatamente após a finalizar da primeira, sendo nela :

criada a lista de tarefas, por meio da decomposição dos itens do Product Backlog, chamada Sprint Backlog;

detalhada algum item ou removevida dúvidas quanto ao objetivo do mesmo, pelo PO ou especialista convidado;

elaborada a estratégia de desenvolvimento que será utilizada para que a meta da Sprint seja atingida. Sendo necessário responder como construirão as funcionalidades do produto durante o Sprint;



Os membros do time devem escolher suas tarefas e então estimá-las em horas;

Tarefas devem ter de 1 a 16 horas de duração. Tarefas maiores deverão ser quebradas em duas ou mais.


Sprint Planning MeetingCaracterísticas do Sprint Backlog

Itens do Product Backlog devem ser decompostos em tarefas (Tasks);

As tarefas devem ter estimativas de 1 a 16 horas;

Qualquer membro do time pode adicionar, remover ou alterar tarefas do Sprint Backlog;

As tarefas são escolhidas pelos membros do time, e não designadas a eles;


Sprint Planning MeetingCaracterísticas do Sprint Backlog

SPRINT BACKLOGSPRINT BACKLOG

Id Item Estimativa1 Refatorar o banco de dados 32

Mapear as tabelas que serão refatoradas 6hrs

Definir estratégias de refatoração 2hrsMontar/Gerar script de refatoração 8hrs

Aplicar script de refatoração 2hrs

Avaliar eficiência da refatoração 6hrsTotal 24 hrs


Scrum Daily MeetingSe reunir todo dia ? Impossível!

Uma vez iniciado o Sprint, inicia-se a realização das reuniões diárias (Scrum Daily Meeting);

Uma Daily Meeting é uma reunião com:

duração exata de 15 minutos

realizadas no mesmo local e horário

com participação do SM e membros do time;

não havendo um SM presente, deve ser definido o facilitador;


Scrum Daily MeetingSe reunir todo dia ? Impossível!

Cada membro deve relatar ao time sobre os progressos e obstáculos que encontrou em seu caminho. Em suma, três perguntas devem ser respondidas por cada um deles:

1. O que fiz (quanto andei) desde a última reunião diária ?

2. O que pretendo fazer ( quanto andarei ) até a próxima reunião diária ?

3. Estou encontrando impedimentos ? Quais ?


AtividadeArmadilhas das Reuniões !

Você está preparado para enfrentar as armadilhas das reuniões diárias ?


Avaliar eficiência da refatoração

Refatorar banco de dados

Scrum Daily MeetingO quadro de acompanhamento

Item Tarefas desejadas

Emanálise

Em desenvolvimento Horas

2413

Estimativa em complexidade

06Estimativa em tempo

Aplicar Script de refatoração 02

Montar script de refatoração

08

Definir estratégia refatoração

02

EmTeste Conluído

Mapear as tabelas que serão refatoradas

06


Scrum Daily MeetingO quadro de acompanhamento


Scrum Daily MeetingSprint Backlog

SPRINT BACKLOGSPRINT BACKLOG

Id Item

1julho/09julho/09julho/09

Refatorar o banco de dados 11 12 13Mapear as tabelas que serão refatoradas 6hrs 6 0 0

Definir estratégias de refatoração 2hrs 2 0 0Montar/Gerar script de refatoração 8hrs 0 8 0

Aplicar script de refatoração 2hrs 0 0 2

Avaliar eficiência da refatoração 6hrs 0 0 6Tota

l24 hrs 16 hrs 8 hrs 0 hrs


Scrum Daily MeetingSprint Burndown

Após a reunião diária, os membros atualizam o montante de tempo que resta para o cumprimento de cada tarefa no Sprint Backlog.

Esta informação é acrescida a um gráfico chamado Sprint Burndown.

Este gráfico mostra o projeto dia-a-dia

0102030405060708090

100

11/7 12/7 13/7 14/7 15/7

Ideal Real


Sprint ReviewE o resultado foi...

Durante o Sprint Review devemos:

avaliar que esta sendo entregue ?

realizar uma apresentação do produto que foi gerado durante a Sprint.

Devem participar do Sprint Review o PO, o SM e os membros do time, clientes e executivos desde que convidados pelo PO.

A apresentação dura 30 minutos


Sprint RetrospectiveAprendendo com os acertos... mas principalmente com os erros

A Sprint Retrospective é uma das ferramentas mais importantes para que você obtenha sucesso com Scrum;

Esta é a oportunidade que o time tem para discutir sobre o que funcionou e o que não durante a Sprint;

Product Owner, Scrum Master e os membros do time devem participar da retrospectiva. Uma boa estratégia é convidar alguém neutro para facilitar a reunião;


Sprint RetrospectiveAprendendo com os acertos... mas principalmente com os erros

A estrutura da Sprint Retrospective é bem simples. Divida um quadro branco ou poster em duas áreas com os seguintes títulos: “O que funcionou bem ?” e “O que pode ser melhorado ?”. Após isso, cada membro deve colocar post-its em cada uma das áreas indicando os itens que, em sua opnião, merecem estar ali;

Então, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para a próxima Sprint.




3 Experimentando agilidade com Scrum

AtividadeJogo do Planejamento

O Product Owner deverá entregar a cada equipe um Product backlog priorizado representando os desejos de seu cliente;

Planejamento (15 minutos)

1. O time deve estimar os itens do Product backlog ;2. O time deve selecionar os itens do Product backlog que poderão ser entregues no final do Sprint.

Execução (30 minutos)

1. O time deve executar as atividades da Sprint.

Revisão (2 minutos)

1. O time deve apresentar o que foi definido para o Sprint.


VOCES PODEM FAZER SOFTWARE QUE FUNCIONA

COM MENOS STRESS

EM UM AMBIENTE ÁGIL E PRODUTIVO

SE VOCÊS ACHAVAM QUE ISSO SERIA IMPOSSÍVEL...

EXISTEM MUITOS QUE JÁ O ESTÃO FAZENDO

Indivíduos e a interação entre eles

processos e ferramentas

Produto em funcionamento

documentação abrangente

Colaboração com o cliente

negociação de contratos

mais que

mais que

mais que

Responder a mudanças seguir um planomais que

http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:



PERGUNTAS ?


ISSO é TUDO PESSOAL !!


Hélio Cabral [email protected]://heliomedeiros.com/

Germano [email protected]

http://heliomedeiros.com

http://heliomedeiros.com

Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

Technology

Transcript of Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE