CertiProf-Scrum-Master-Professional-Certificate-V072018A.pdf

SCRUM

MASTER PROFESSIONAL CERTIFICATE (SMPC)

S

E

F O

N A L C E R T

O S I

I F

I

C A

T

R

E

P

8 1 0 2 9 0 O Ã S R E V ) C P M S (

SCRUM MASTER S M P C

www.certprof.com CERTIPROF® é uma marca registrada da CerProf, LLC nos Estados Unidos e/ou outros países.

SCRUM

MASTER PROFESSIONAL CERTIFICATE (SMPC) Objevos de Aprendizagem do Curso 8 � Escopo, propósito, termos e definições principais para o Scrum Master Professional Cerficate 1 0 (SMPC) e como ele pode ser usado. 2 9 0 O Ã � Cerficação Profissional. S R E V ) C P ©2018 Ken Schwaber e Jeff Sutherland. Oferecido para licença sob a licença Atribuição ComparlhaIgual do Creave Commons, acessível M em hp://creavecommons hp://creavecommons.org/licen .org/licen ses/by-sa/4.0/le ses/by-s a/4.0/legalcode galcode (em inglês ) e também descrita descrit a de forma resumida em hp://creavecomhp://creavecom S ( mons.org/licenses/by-sa/4.0/ mons.org/licenses/bysa/4.0/ (em inglês) . Ao ulizar este Guia do Scrum, você reconhece e concorda que leu e concorda que está sujeito aos termos da li cença Atribuição ComparlhaIgual da Creave Commons.


Agenda Apresentações Introdução Tipos de Projetos Manifesto Ágil Aspectos e Pilares do Manifesto Princípios Por trás do Manifesto Ágil Princípios Declaração de Interdependência Interdependência Os 6 Valores da Declaração de Interdependência Interdependência O que é Agilidade? Como devemos ver a Agilidade? Por que Agile? Gerenciamento de Projetos Tradicional O que é Scrum? Usos do Scrum Teoria do Scrum Interavidade Três Pilares do Scrum Transparência Inspeção Adaptação Valores do Scrum A Essência do Scrum Papéis O Time do Scrum Product Owner Responsabilidades Responsabil idades do Product Owner Caracteríscas do Product Owner Scrum Master Responsabilidades Responsabilidades do Scrum Master para o Product Owner Responsabilidades Responsabilidades do Scrum Master para a Organização Responsabilidades Responsabilidades do Scrum Master para o Time de Desenvolvimento Desenvolvimento Time de Desenvolvimento Desenvolvimento Tamanho do Time de Desenvolvimento Desenvolvime nto Responsabilidades Responsabil idades do Time de Desenvolvimento Desenvolvime nto Caracteríscas do Time de Desenvolvimento Desenvolvimento Partes Interessadas Partes Interessadas são divididas em: Principais Conceitos Nível de Detalhamento Como é estruturada uma User Story?

3

5 6 7 8 8 9 10 11 11 12 12 13 14 15 15 16 17 17 18 18 19 20 21 22 23 24 25 26 27 28 29 30 31 31 32 33 34 34 35-37 38 38


Agenda

4

Estrutura de User Story Tarefa Como uma Tarefa é estruturada? Definição de “Pronto” Time-Boxing Vantagens do Time-Boxing Onde é ulizado o Time-Boxing? Eventos Formais Sprint Cancelando uma Sprint Reuniões do Scrum Reunião Diária do Scrum Daily Meeng (Daily Sprint) Reunião de Planejamento da Sprint O que pode ser Pronto nesta Sprint? Meta da Sprint Como o trabalho escolhido será Pronto? Planning Poker Reunião de Revisão da Sprint Retrospecva Retrospecva da Sprint Os 5 Estágios de uma Retrospecva Artefatos Backlog do Produto Refinamento do Backlog do Produto Backlog da Sprint Prioridade Monitoramento Incremento

39 39 40 40 41 41 42 43 44 45 46 47 48 49 50 50 51 51 52 53 54 54 55 56 57 58 59 60


Apresentações Apresen tações


Apresentações Bem vindos! Apresente-se no seguinte formato: Nome. Empresa. Cargo e experiência profissional. Familiaridade com os conceitos e a prática Scrum. Expectativas para este curso.

6


Introdução Os projetos são afetados por limitações de tempo, custo, escopo, qualidade, recursos, capacidade organizacional e outras obstáculos que os tornam difíceis de planejar, implementar, implementar, gerenciar e finalmente obter sucesso.

Tipos de Projetos No eixo horizontal, temos a experiência e o conhecimento conhecimento de uma ferramenta; no eixo vertical, há a clareza dos requisitos.

s o t i s i u q e R

C a ó t i C c o o m s p l e x S i o s m p l e s Ferramentas

7


Manifesto Ágil O Manifesto Ágil surgiu em 17 de fevereiro de 2001, quando dezessete críticos de desenvolvimento desenvolvimento de software se reuniram e definiram o termo "metodologia "metodologia Ágil" para definir os métodos que estavam surgindo como uma alternativa às metodologias formais. O Manifesto Ágil consiste em 12 princípios associados a 4 aspectos ou pilares. REF: http://agileman http://agilemanifesto. ifesto.org/ org/

Aspectos e Pilares do Manifesto Manifesto � � � �

Indivíduos e interações mais que processos e ferramentas. ferramentas . Software em funcionamento funcioname nto mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. Responder a mudanças mais que seguir um plano.

Documentação Abrangente

Processos e Ferramentas

Indivíduos e Interações

Software em Funcionamento

Colaboração com o Cliente

Resposta a Mudanças Seguir um Plano

Negociação de Contratos

8


Princípios Por trás do Manifesto Ágil � Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. � Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens vantagens competitivas. � Entregar software funcionando com frequência, na escala de semanas até meses, com preferência preferência aos períodos mais curtos. � Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. � Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. � O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Sasfação do cliente

Conversa direta

PRINCÍPIOS

Construir projetos ao edor de indivíduos movados

9

Mudanças de requisitos

Entrega connua de so�wares em funcionamento

Trabalho em equipe entre as pessoas e desenvolvedores responsáveis


Princípios � Software funcional funcional é a medida primária de progresso. progresso. � Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. � Contínua Contínua atenção à excelência excelência técnica e bom design, aumenta a agilidade. � Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. feito. � As melhores arquiteturas, requisitos requisitos e designs emergem de times auto organizáveis. � Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

So�ware funcional

O me reflete em como se tornar mais efevo

PRINCÍPIOS

Times auto organizáveis

10

Desenvolvimento sustentável

Excelência técnica

Simplicidade é Simplicidade essencial


Declaração de Interdependência A Declaração de Interdependência no gerenciamento de projetos foi escrita no início de 2005 por um grupo de 15 líderes de projetos como um complemento ao "Manifesto Ágil". Ele lista seis valores de gerenciamento necessários para fortalecer o desenvolvimento ágil da mentalidade, particularmente no gerenciamento de projetos complexos e incertos. http://pmdoi.org

[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]

Os 6 Valores da Declaração de Interdependência 1. Aumentamos o retorno do investimento, tornando o fluxo contínuo de valor o nosso foco; 2. Entregamos resultados confiáveis, engajando os clientes em iterações frequentes e propriedade compartilhada; 3. Esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação; 4. Promovemos criatividade e inovação reconhecendo que os indivíduos são a fonte última de valor e criamos um ambiente em que eles fazem a diferença; 5. Impulsionamos o desempenho por meio do compromisso do grupo em obter resultados e da responsabilidade compartilhada pela eficácia do grupo; Melhoramos a eficácia e a confiabilidade confiabilidade por meio de estratégias estratégias situacionais situacionais específicas, 6. Melhoramos processo e práticas”. http://pmdoi.org

11

[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]


O que é Agilidade? “Agilidade é a capacidade de criar e responder a mudanças para lucrar em um ambiente de negócios turbulento”. “Agilidade é a capacidade de equilibrar flexibilidade e estabilidade”. estabilidade”.

SCRUM

CRYSTAL

KANBAN

LEAN

XP

PDD

Agile ASD

DSDM

Como devemos ver a Agilidade? Em qualquer tipo de disciplina de gestão, ser ágil é uma qualidade, portanto, essa deve ser uma meta que devemos alcançar. O gerenciamento ágil de projetos envolve adaptabilidade ao criar um produto, serviço ou qualquer outro resultado.

12


Por que Agile? A Gartner previu que 80% de todos os projetos de software estarão usando o Agile. Quase três quartos (71%) das organizações relatam o uso de abordagens ágeis às vezes, frequentemente ou sempre. (Fonte: Project Management Institute).

13


Gerenciamento de Projetos Tradicional

Requisitos

Vantagens: Ordem lógica. Desvantagem: Pressupõe previsibilidade.

Análises Design Codificação Testes Operação

14


O que é Scrum? Scrum (n): Uma estrutura na qual as pessoas podem abordar problemas adaptativos complexos, entregando, entregando, de forma produtiva e criativa, produtos do mais alto valor possível. Scrum é: � Leve. • Simples de entender. • Difícil de dominar.

Usos do Scrum O Scrum foi originalmente desenvolvido para gerenciar e desenvolver produtos. Desde o início dos anos 90. O Scrum tem sido usado para desenvolver softwares, hardwares, softwares embarcados, redes de função de interação, veículos autônomos, nas escolas, nos governos, no marketing, no gerenciamento do funcionamento de organizações e em quase tudo que usamos em nosso dia a dia, como indivíduos e sociedades. O Scrum provou ser especialmente efetivo na transferência de conhecimento iterativa e incremental. O Scrum agora é amplamente usado para produtos, produtos, serviços e gerenciamento de matrizes de empresas.

15


Teoria do Scrum


Interavidade O Scrum é baseado na teoria empírica de controle controle de processos, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é conhecido. O Scrum emprega uma abordagem incremental e iterativa para otimizar a previsibilidade e controlar o risco.

Visão

Interação 1

Interação 2

Interação 3

Interação 4

Continuidade

Três Pilares do Scrum

� Transparência. � Inspeção. � Adaptação.

17


Transparência Aspectos significativos do processo devem ser visíveis para os responsáveis pelo resultado. A Transparência exige que esses aspectos sejam definidos por um padrão comum, de forma que os observadores compartilhem um entendimento comum do que está sendo visto.

Inspeção Os usuários do Scrum frequentemente devem inspecionar os artefatos do Scrum e progredir em direção a uma meta da Sprint para detectar variações indesejáveis. Sua inspeção não deve ser tão frequente de forma que atrapalhe o trabalho. Inspeções são mais benéficas quando executadas diligentemente por inspetores qualificados no ponto de trabalho.

18


Adaptação Um dos três pilares do controle do processo empírico; O feedback é usado para fazer um ajuste no produto de trabalho que está sendo desenvolvido ou no processo pelo qual ele está sendo desenvolvido.

Reunião de Planejamento da Sprint

Reunião Diária do Scrum

Reunião de Revisão da Sprint

Reunião de Retrospecva da

Sprint

Reunião de Refinamento do

Backlog

19


Valores V alores do Scrum � � � � �

Comprometimento. Coragem. Foco. Transparência. Respeito.

Os membros do Time do Scrum aprendem e exploram esses valores enquanto trabalham com os papéis, eventos e artefatos do Scrum.

COMPROMETIMENTO

FOCO

20

CORAGEM

TRANSPARENCIA

RESPEITO


A Essência do Scrum A essência do Scrum Scrum é um pequeno time de pessoas. O time individual é altamente altamente flexível e adaptável. Esses pontos fortes continuam operando seja em uma única equipe, em várias, ou até mesmo em redes de equipes que desenvolvem, desenvolvem, liberam, operam e sustentam o trabalho e os produtos de trabalho de milhares de pessoas. Quando as palavras "desenvolver" e "desenvolvimento" são usadas no Guia do Scrum, elas se referem a um trabalho complexo, como os identificados acima.

Planejamento Ágil a E s tratég i ia ól l i i o o P ort ó o P rodut o

ga a E n tre g

t S prin t

Diário

21


Papéis


Papéis Um conjunto coeso de responsabilidades que pode ser cumprido por uma ou mais pessoas. Os três papéis do Scrum são Product Owner, Scrum Master e Time de Desenvolvimento.

O Time do Scrum •

• •

•

•

O Time do Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master. Os Times do Scrum são auto organizados e multifuncionais. O modelo de Time no Scrum foi desenvolvido para otimizar a flexibilidade, a criatividade e a produtividade. produtividade. O Time do Scrum provou provou ser eficaz para todos os usos declarados acima e para qualquer trabalho complexo. Os Times do Scrum oferecem produtos de forma iterativa e incremental, maximizando as oportunidades de feedback. Entregas incrementais de produtos "Prontos" garantem que uma versão potencialmente útil do produto em desenvolvimento esteja sempre disponível.

m ru m c u r o s c m e d o t i m

23


Product Owner O Product Owner (PO) representa a voz do cliente e é responsável por maximizar o valor do produto. • • •

24

Um PO deve sempre manter uma visão dupla. Deve entender e apoiar as necessidades e interesses de todas as partes interessadas. Deve compreender as necessidades.


Responsabilidades Responsabili dades do Product Owner

25

Determinar as atividades gerais do início do projeto

Foco na criação de valor e geração de ROI

Auxiliar na definição da visão do projeto

Avaliar a viabilidade viabilidade e garantir a entrega do produto ou serviço

Assegurar os recursos financeiros do projeto

Representar o usuário ou cliente

Ajudar na escolha do Scrum Master e outros membros

Ser responsável pela gestão do Backlog do Produto

Auxiliar a criar e aprovar as User Stories

Explicar as User Stories para o Time de Desenvolvimento

Definir os critérios de aceitação

Participar do projeto e da Retrospectiva da Sprint


Caracteríscas do Product Owner

Conhecimento de negócios

Excelente capacidade de comunicação

Conhecimento do processo Scrum

Capacidade de negociação

Decisivo

Proativo

Acessível

26

Orientado para objetivos


Scrum Master

27

�

O Scrum Master é responsável por promover e apoiar o Scrum, conforme definido no Guia do Scrum.

�

Os Scrum Masters fazem isso ajudando todos a entender a teoria, as práticas, as regras e os valores do Scrum.

�

O Scrum Master é um líder-servo do Time do Scrum.

�

O Scrum Master ajuda aqueles que estão fora do Time do Scrum a entender quais de suas interações com o Time do Scrum são úteis e quais não são.

�

O Scrum Master ajuda todos a mudar essas interações para maximizar o valor criado pelo Time do Scrum.


Responsabilidades do Scrum Master para o Product Owner

Garantir que os objetivos, escopo e domínio do produto sejam compreendidos por todos do Time do Scrum

Encontrar técnicas para gerenciamento efetivo do Backlog do Produto

Encorajar a necessidade de ter um Release de produto Incremental, claro e conciso

Entender sobre planejamento de produto e ambientes empíricos

Ajudar o PO se envolvendo e fazendo as partes interessadas serem mais colaborativos

Entender e praticar Agilidade

Explica como realizar a pesquisa de performance para requisitos Agile

28


Responsabilidades Responsabili dades do Scrum Master para a Organização

Liderar e guiar a organização na adoção do Scrum

Planejar a implementação do Scrum na organização

Motivar mudanças para implementar a produtividade do Time do Scrum (PO e TD)

29

Auxiliar o Time do Scrum S crum (PO e TD) e as partes interessadas a entender e executar o Scrum

Trabalhar com outros Scrum Masters para aumentar a efetividade do Scrum


Responsabilidades Responsabili dades do Scrum Master para o Time de Desenvolvimento

Guiar o time para que sejam auto organizados e multifuncionais

Elimina impedimentos para o progresso da construção

30

Garante que o Board do Scrum se mantenha atualizado

Auxilia o Time de Desenvolvimento a criar produtos de alto valor

Garante um ambiente ideal para o Time de Desenvolvimento

Auxilia o Time de Desenvolvimento no desenvolvimento do Backlog da Sprint e do Gráfico Burn down da Sprint


Time de Desenvolviment Desenvolvimento o O Time de Desenvolvimento é formado por profissionais que realizam o trabalho de entregar um Incremento potencialmente liberável do produto "Pronto" ao final de cada Sprint. Um incremento "Pronto" é necessário na Revisão da Sprint. Somente membros do Time de Desenvolvimento criam o Incremento. Times de Desenvolvimento são estruturados estruturados e capacitados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia sinergia resultante otimiza a eficiência e a eficácia gerais do Time de Desenvolvimento.

Tamanho do Time de Desenvolvimento O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo dentro de um Sprint. Menos de três membros no Time de Desenvolvimento diminuem a interação e resultam em menores ganhos de produtividade. produtividade. Times de Desenvolvimento menores podem encontrar restrições de habilidades durante o Sprint, fazendo com que o Time de Desenvolvimento não consiga entregar um Incremento potencialmente potencialmente liberável. Ter mais de nove membros requer muita coordenação.

31


Responsabilidades Responsabili dades do Time de Desenvolvimento

Garantir um entendimento claro dos requisitos

Estimar User Stories aprovadas pelo PO

Desenvolver a lista de tarefas baseado nas User Stories aprovadas

Desenvolver o Backlog da Sprint e o gráfico Burn Down

32

Calcular os esforços para as tarefas identificadas

Criar entregáveis

Identificar oportunidades de melhoria

Criar entregáveis de alta qualidade

Identificar riscos e implementar ações para mitiga-los

Participar do projeto e da Retrospectiva da Sprint


Caracteríscas do Time de Desenvolviment Desenvolvimento o

Conhecimento do Scrum

Colaboração

Altamente motivado

Proativo

Especialistas técnicos

Auto organização

Bom trabalho me equipe

Independente

Responsável

Intuitivo

33

Orientado para metas


Partes Interessadas Uma pessoa, grupo ou organização que afeta ou pode ser afetada pelas ações de uma organização.

Partes Interessadas são divididas em: Cliente: O cliente é a pessoa ou organização que adquire o produto, serviço ou qualquer outro resultado do projeto. Usuário: O usuário é o indivíduo ou organização que usa diretamente o produto, serviço ou qualquer outro resultado do projeto; Além disso, em alguns setores, o cliente e os usuários podem ser os mesmos. Patrocinador: O patrocinador é a pessoa ou organização que fornece recursos e apoio para o projeto, o patrocinador é também a parte interessada para quem todos nós devemos reportar no final.

34


Principais Conceitos


Reunião Diária do Scrum Incremento de Produto Potencialmente Entregável

Execução da Sprint

Backlog da Sprint

Revisão da Sprint

Planejamento da Sprint

Retrospecva da

Sprint

Ideia de Produto

36

Backlog do Produto


Backlog do Produto


Épico: Uma grande história do usuário, talvez com muitos meses em tamanho, que pode abranger uma versão inteira ou vários lançamentos. Épicos são úteis como espaços reservados para grandes requisitos. Épicos são progressivamente refinados em um conjunto de histórias de usuários menores no momento apropriado. User Stories: Stories: As histórias são descrições curtas de uma pequena parte da funcionalidade desejada, escritas no idioma do usuário. Tarefa: Essa é uma representação do requisito que está no idioma do usuário, mas definido tecnicamente tecnicamente sobre como ele funcionará e quem participará.

Criar e reconhecer boas User Stories

37


Nível de Detalhamento

Requerimentos Agile

Épico

VISÃO

User Stories

Tarefa

PRODUCT BACKLOG BACKLOG

BACKLOG DA SPRINT SPRINT

TAREFAS DIÁRIAS

Como é estruturada uma User Story? Story?

38

Uma história de usuário deve consistir em 3 C's:

Recursos: modelo INVEST.

Cartão: Descrição escrita sobre o que o usuário precisa. Conversa: O PO e o TD esclarecem os detalhes. Confirmação: Permite que você determine o que é esperado.

� � � � � �

Independence (Independência). Negotiable (Negociável). Valuable (Valioso). Estimable (Estimável). Small (Pequeno). Tangible (Tangível). (Tangível).


Estrutura de User Story

Título Descrição Quem quero beneficiar Estimativa de prioridade

Critérios de Aceitação

Tarefa O trabalho técnico que um Time de Desenvolvimento executa para concluir um item do Backlog do Produto. A maioria das tarefas é definida como pequena, representando não mais do que de poucas horas até um dia de trabalho.

39


Como uma Tarefa é estruturada? Características do modelo SMART SMART:: ID:

S: Specific (Específico). S: Specific M: Measurable M: Measurable (Mensurável). A: Achievable A: Achievable (Atingível). R: Relevant (Relevante). T: Time-boxed T: Time-boxed (T ( Temporal).

Responsável: Descrição: Esmava:

Definição de “Pronto “Pronto”” Trata-se de acordos do PO com partes interessadas i nteressadas que contêm todas as condições condi ções que devem obedecer aos itens do Backlog do Produto para considerar uma Sprint concluída ou terminada.

Critérios de Aceitação

Pronto

É sobre os componentes desejados para a qual a funcionalidade de uma User Story é julgada.

40

Pronto é um conjunto de regras que se aplicam a todas as User Stories em uma determinada Sprint.


Time-Boxing Todos os eventos são time-boxed (duração máxima de tempo), de modo que todos tenham uma duração máxima.

15 Minutos


24 Horas 2-4 Semanas Product Backlog

Backlog da Sprint

Incremento do Produto Potencialmente Liberável

Vantagens V antagens do Time-Boxing Time-Boxing é uma prática crítica no Scrum e deve ser cuidadosamente aplicada. Um Time-Boxing Time-Boxing arbitrário pode levar a uma desmotivação desmotivação da equipe e pode resultar na criação de um ambiente apreensivo, por isso o Time-Boxing deve ser usado apropriadamente. Benefícios: � Processos de desenvolvimento eficientes. � Menos sobrecarga. � Alta velocidade para as equipes. � Ajuda a gerenciar com eficácia o planejamento e a implementação de projetos. projetos.

41


Onde é ulizado o Time-Boxing?

Reunião de Retrospectiva da Sprint

Sprint

TIME-BOXING Reunião de Revisão da Sprint

42




Eventos Formais O Scrum prescreve quatro eventos formais, contidos no Sprint, para inspeção e adaptação: � � � �

43

Planejamento da Sprint. Reunião Diária do Scrum. Revisão da Sprint. Retrospectiva da Sprint.

Evento Scrum

Time-Box (para Sprint de 1 mês)


8 horas

Scrum Master, Product Owner e Time de Desenvolvimento.


15 Minutos

Scrum Master (opcional), Product Owner (opcional) e Time de Desenvo Desenvolvimento. lvimento.

Revisão da Sprint

4 Horas

Scrum Master, Product Owner, Time de Desenvolvimento Desenvo lvimento e todas partes interessadas chave.

Retrospecva da Sprint

3 Horas

Scrum Master, Product Owner e Time de Desenvolvimento.

Parcipantes


Sprint

1a4 Semanas de duração.

Sprint

Definição O coração do Scrum é a Sprint, de aproximadamente um mês, no qual um incremento do produto potencialmente liberável é criado. Ação Uma Sprint contém e consiste em: •Reunião de Planejamento da Sprint. •Reunião Diária do Scrum. •Trabalho de Desenvolvimento. •Reunião de Revisão da Sprint. •Reunião de Retrospectiva da Sprint.

44


Cancelando uma Sprint Um Sprint pode ser cancelado antes do final do Time-Box da Sprint. Apenas o Product Owner tem autoridade para cancelar o Sprint, embora ele possa fazê-lo sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.

Ambiente Externo

Product Owner

Partes Interessadas

Time É uma mudança urgente?

SIM Cancelar a Sprint e recomeças com o Planejamento da Sprint

45

NÃO Mudanças serão feitas numa Sprint Futura

Não agir


Reuniões do Scrum Para qualquer projeto ser bem sucedido, a comunicação é importante. As equipes do Scrum empregam várias reuniões importantes para estruturar o trabalho da equipe: � � � �

Reunião Diária do Scrum. Reunião de Planejamento da Sprint. Reunião de Revisão da Sprint. Reunião de Retrospectiva da Sprint. Reunião de Planejamento da Sprint


Reunião de Refinamento do

Backlog


Reunião de Retrospecva Retrospecv a da

Sprint

46



1a4 Semanas de duração Definição O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint.

47


Ação • O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir atingir a meta da Sprint? • O que eu farei hoje para ajudar o Time de Desenvolvimento atingir atingir a meta da Sprint? • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?


Daily Meeng (Daily Sprint) � Inspeção e ponto de ajuste no Scrum. Max. 15 minutos. � A equipe se reúne para comunicar e entender os estados. � Essencial para conhecer o progresso contínuo e evitar bloqueios. � Ele não tem como objetivo relatar o progresso ao Product Owner, Scrum Master ou a qualquer outra parte interessada. interessada. � O Product Owner pode participar desde que sua participação seja passiva. � O Scrum Master certifica-se de que o Time de Desenvolvimento Desenvolvimento mantém a reunião, mas o Time de Desenvolvimento é responsável por dirigir a Reunião Diária do Scrum.


48



O Planejamento da Sprint é um time-boxed com no máximo oito horas para uma Sprint de um mês de duração. Definição O trabalho a ser feito durante a Sprint é planejado nesta reunião, cujo plano é criado com a colaboração de todo o Time do Scrum. Ao final, o Time de Desenvolvimento deve ser capaz de explicar ao PO e ao SM como pretende trabalhar como equipe auto organizada.

49

Reunião de Planejamen to da Sprint

Ação O planejamento da Sprint responde as seguintes questões: • O que pode ser entregue como resultado do incremento da próxima Sprint? • Como o trabalho necessário para entregar o incremento será realizado?


O que pode ser Pronto nesta Sprint?

Esta questão nos ajuda para o trabalho do Time de Desenvolvimento (TD) projetar a funcionalidade que será desenvolvida durante o Sprint, onde o objetivo do Sprint é definido.

META DA

SPRINT

O número de itens do Backlog do Produto selecionado para o Sprint depende apenas do Time de Desenvolvimento (TD).

Meta da Sprint

� A Meta da Sprint é um conjunto de objetivos para a Sprint que pode ser alcançada através da implementação do Backlog do Produto. � A Meta da Sprint dá ao Time de Desenvolvimento alguma flexibilidade em relação à funcionalidade implementada na Sprint. � A Meta da Sprint pode ser qualquer outra coerência que faça com que o Time de Desenvolvimento trabalhe em conjunto e não em iniciativas separadas.

50


Como o trabalho escolhido será Pronto?

Tendo definido definid o a Meta da Sprint e selecionado seleci onado os itens do Backlog do Produto para a Sprint, o Tim de Desenvolvimento decide como ele irá tornar essa funcionalidade em um Incremento do Produto “Pronto” durante a Sprint. Os itens do Backlog do Produto selecionados para esta Sprint, mais o plano para entregá-los, são chamados de Backlog da Sprint.

Backlog da Sprint

Planning Poker Esta é uma das técnicas Scrum mais reconhecidas, reconhecidas, porque é simples, divertida e eficaz, é onde o Time de Desenvolvimento (TD) estima, como um grupo, o esforço para fazer na Sprint.

51



Sprint 1

Time

Pronto!!!

Product Owner

� Os participantes incluem o Time do Scrum e as principais interessados convidados pelo Product Owner. � O Product Owner explica quais itens do Backlog do Produto foram "Prontos" e o que não foi "Pronto". � O Time de Desenvolvimento discute o que deu certo durante o Sprint, que problemas enfrentou e como esses problemas foram resolvidos. � O Time de Desenvolvimento demonstra o trabalho que realizou e responde a perguntas sobre o Incremento. � O Product Owner discute a situação atual do Backlog do Produto. Ele projeta datas desejadas e de entrega prováveis com base no progresso até o momento (se necessário). � O grupo inteiro colabora no que fazer a seguir, para que a Revisão da Sprint forneça informações valiosas para o Planejamento da Sprint subsequente. � Revisão de como o mercado ou o usuário potencial do produto pode ter mudado o que seria a coisa mais importante de se fazer em seguida. � Revisão do cronograma, orçamento, potencialidades e mercado para as próximas versões antecipadas de funcionalidade ou capacidade do produto.

52


Retrospecva Retr ospecva da Sprint � A Retrospectiva da Sprint é uma oportunidade para o Time do Scrum se inspecionar inspeciona r e criar um plano para melhorias a serem implementadas durante durante a próxima Sprint. � A Retrospectiva Retrospectiva da Sprint ocorre após a Revisão Revisão da Sprint e antes do próximo Planejamento da Sprint. � É uma reunião reunião de no máximo três horas horas para Sprints Sprints de um mês. Para Para sprints mais curtas, o evento geralmente é mais curto. O propósito da Retrospectiva da Sprint é: �

Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, relacionam entos, aos processos e às ferramentas;

�

Identificar e ordenar ordenar os principais itens itens que foram bem e as potenciais potenciais melhorias; melhorias; e,

�

Criar um um plano para implementar implementar melhorias melhorias no modo que que o Time Scrum Scrum faz seu seu trabalho. trabalho.

Retrospecva

da Sprint

53


Os 5 Estágios de uma Retrospecva

Os 5 Estágios de uma Retrospecva Coleta de Abertura dados

1

Insights

Ação

3

4

Encerramento

5

2

Artefatos Os artefatos do Scrum representam trabalho ou valor para fornecer transparência e oportunidades de inspeção e adaptação. Os artefatos definidos pelo Scrum são projetados especificamente para maximizar a transparência transparência das principais informações, para que todos tenham o mesmo entendimento entendimento do artefato. �

Backlog do Produto.

�

Backlog do Sprint.

� Incremento.

54


Backlog do Produto �

O Backlog Backlog do Produto é uma lista ordenada de tudo o que é conhecido como necessário no produto.

�

É a única fonte de requisitos para quaisquer alterações a serem feitas no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. ordenação.

�

O Backlog Backlog do Produto é dinâmico; Ele muda constantemente para identificar identifi car o que o produto precisa para ser apropriado, competitivo e útil.

�

O Backlog do Produto lista todos os recursos, funções, requisitos, aprimoramentos aprimorame ntos e correções que constituem as alterações a serem feitas no produto em versões futuras.

Entrega 1

Entrega 2

Backlog do Produto

55


Refinamento Refina mento do Backlog do Produto �

O refinamento do Backlog do Produto é o ato de adicionar detalhes, estimativas estimativa s e pedidos aos itens no Backlog do Produto.

�

Durante o refinamento do Product Backlog, os itens são revistos e revisados.

�

O Time do Scrum decide como e quando o refinamento é feito.

�

O refinamento refinamento geralmente geralmente não consome consome mais de 10% 10% da capacidade do Time de Desenvolvimento. No entanto, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério dele.

Esmava da Sprint

E D A D I R O I R P

Inclusão de Itens

Refinamento de Itens

Exclusão de Itens

56


Backlog da Sprint �

O Backlog da Sprint é o conjunto de itens do Backlog do Produto selecionado seleciona do para a Sprint, juntamente com um plano para entregar o Incremento Incremento do produto e realizar a Meta da Sprint.

�

O Backlog da Sprint é uma previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo Incremento e o trabalho necessário para entregar essa funcionalidade em um Incremento "Pronto".

�

O Backlog da da Sprint torna torna visível visível todo o trabalho que o Time de Desenvolvimen Desenvolvimento to identifica como necessário para atingir a Meta da Sprint.

META DA

SPRINT

Backlog do Projeto

57



Prioridade �

O Product Owner é uma pessoa, não um comitê.

�

O Product Owner pode representar os desejos de um comitê no Backlog do Produto, mas aqueles que desejam alterar a prioridade de um item de Backlog do produto devem se dirigir ao Product Owner.

�

Para o Product Owner ter sucesso, toda a organização deve respeitar suas decisões.

�

As decisões do Product Owner são visíveis no conteúdo e na ordem do Backlog do Produto.

�

Ninguém pode forçar o Time de Desenvolvimento a trabalhar a partir de um diferente conjunto de requisitos.

Backlog do Produto Solicitação

Prioridade 1 2 3

4

Product Owner

58


Monitoramento Monitoramento o Progresso a Caminho dos Objetivos. Monitoramento do Progresso da Sprint.

Sprint Burn Down Chart 120 100 s t n i o P y r o t S

80 60 40 20 0 1

2

3

4

5 6 Days

7

8

9

8

9

Total Story Points Planned Total Story Points Actual

Sprint Burn Up Chart 120 100 s t n i o P y r o t S

80 60 40 20 0 1

2

3

4

5 6 Days

7

Total Story Points Planned Total Story Points Actual

59


Incremento O Incremento é a soma de todos os itens do Backlog do Produto concluídos durante uma Sprint e o valor dos incrementos de todas as Sprints anteriores. No final de um Sprint, o novo Incremento deve ser "Pronto". Um incremento é um corpo de trabalho pronto possível de ser inspecionado, que suporta o empirismo no final da Sprint. O incremento deve estar em condições utilizáveis, independentemente de o Product Owner decidir liberá-lo.

Incremento do Produto

Backlog do Projeto

60


SCRUM

61


Colaboradores na revisão do SCRUM MASTER

PROFESSIONAL CERTIFICATE (SMPC)

Com sua ajuda nós sempre sempr e alcançamos

resultados extraordinários.

Obrigado!

SCRUM

MASTER PROFESSIONAL CERTIFICATE (SMPC)

cerprof.com

@Cerprof

@CerProf

CerProf

Certiprof_llc


CertiProf-Scrum-Master-Professional-Certificate-V072018A.pdf

Recommend Documents