Daniel
This presentation is the property of its rightful owner.
Sponsored Links
1 / 39

Ari Stopassola Junior [email protected] @ stopassola PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

Daniel Michaelsen [email protected] @ micaweb. Ari Stopassola Junior [email protected] @ stopassola. #. CONCEITO DO SCRUM. Scrum é um framework de gerenciamento, com base em um desenvolvimento gradual do produto Provém uma estrutura para: Agentes Papéis Artefatos Reuniões

Download Presentation

Ari Stopassola Junior [email protected] @ stopassola

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ari stopassola junior arijunior gmail stopassola

Daniel Michaelsen

[email protected]

@micaweb

Ari Stopassola Junior

[email protected]

@stopassola

#


Conceito do scrum

CONCEITO DO SCRUM

Scrum é um framework de gerenciamento, com base em um desenvolvimento gradual do produto

Provém uma estrutura para:

Agentes

Papéis

Artefatos

Reuniões

Regras

Alternativa ao tradicional método WATERFALL

Trabalha com requisitos instáveis ou desconhecidos


Analogia

ANALOGIA

Nome é originário do rugby pois o Scrum é a forma de recomeçar o jogo após um impedimento.

O aglomerado do Scrum simboliza o trabalho em equipe dos agentes e papéis no método Scrum.


Waterfall

WATERFALL

Tradicional método Waterfall de desenvolvimento lida com fases e é o oposto do Scrum


Itera es

ITERAÇÕES

Scrum lida com iterações ao invés de fases como no Waterfall

O método Scrum mescla todas as atividades de desenvolvimento em cada iteração


Detalhe da itera o

DETALHE DA ITERAÇÃO


Agentes

AGENTES


Pap is

PAPÉIS

Scrum Master

Responsável por facilitar o processo

Fornece assistência ao Product Owner

Auxilia o Scrum Team e remove os impedimentos

Product Owner

Representa o cliente e detém os requisitos do produto

Trabalha em conjunto com o Scrum Team para fornecer esclarecimentos e aprovação em requisitos

Scrum Team

Responsável por completar o serviço e preencher os requisitos


Product owner

PRODUCT OWNER

Responsável pela maximização do Retorno No Investimento

Responsável pela visão do produto

Árbitro final em dúvidas sobre os requisitos

Aceita ou rejeita cada incremento do produto

Decide quando lançar o produto

Decide quando continuar o desenvolvimento


Scrum team

SCRUM TEAM

Mistura desenvolvedores e analistas nos Sprints iniciais

Auto-organizado e auto-gerenciado, sem papéis definidos externamente

Tem autonomia em como alcançar requisitos

Maior índice de sucesso quando tem todo o time localizado em um mesmo ambiente, principalmente nos Sprints iniciais


Scrum master

SCRUM MASTER

Cria um ambiente condutivo para a auto-organização do time

Captura dados empíricos para ajustes prévios

Blinda o time de interferências e distrações externas para manter o fluxo do time (a.k.a. the zone)

Aplica prazos

Mantém visível os artefatos do Scrum

Não tem autoridade gerencial sobre o time


Artefatos

ARTEFATOS

PRODUCT BACKLOG

USER STORY

PRODUCT BACKLOG ITEM (PBI)

RELEASE BACKLOG

SPRINT BACKLOG

SPRINT TASK

BURNDOWN CHART


Product backlog

PRODUCT BACKLOG


Product backlog1

PRODUCT BACKLOG

Representa a lista de desejos do cliente

A lista é transformada em funcionalidades do produto

Cada funcionalidade irá se tornar um PBI (Product Backlog Item)

Novas funcionalidades podem ser adicionadas regularmente dependendo do tamanho do projeto

Nesta etapa os PBIs ainda não sofrem priorizações


User story

USER STORY

Quando o Product Owner lança a lista dos desejos no Product Backlog, este desejo pode ser exposto na forma de User Story (Narrativa do Usuário)

Isto é necessário para maximizar a comunicação do que realmente o Product Owner deseja implementar

O time irá converter cada user story para uma ou mais funcionalidades técnicas conforme a situação

Uma user story sempre será um PBI

A prática do user story é opcional e a lista dos desejos pode ser composta diretamente na forma de funcionalidades técnicas


User story1

USER STORY

Exemplos de User Stories

Como um assinante do site, eu quero poder ver o perfil de outros assinantes como eu

Como um assinante do site, eu quero poder marcar meu perfil como particular, e apenas quem eu permitir pode ver ele

Como um visitante do site, eu quero poder enviar uma notícia por e-mail para amigos

Como administrador do site, eu quero poder atualizar o FAQ sempre que necessário


Ari stopassola junior arijunior gmail stopassola

PBI

Especifica “O que é?” mais do que “Como faz?”

Comummente escrito em forma de narrativa do usuário (User Story)

Prioridade pode ser classificada no tema:

Must, Should, Could, Won’t

Será quebrado em tarefas quando executado

Precisa ter uma estimativa de horas

Esta estimativa é a soma de horas de todas as tarefas do PBI


Release backlog

RELEASE BACKLOG


Release backlog1

RELEASE BACKLOG

Coleção parcial de PBIs do Product Backlog

Os PBIs são selecionados pelo Product Owner, seguindo um critério próprio

Os PBIs no Release Backlog vão sofrer uma priorização pelo Product Owner e podem ser constantemente repriorizados pelo mesmo

Após a priorização os PBIs serão agrupados para Sprints separados


Sprint backlog

SPRINT BACKLOG

Cada Sprint representa um grupo de PBIs do Release Backlog


Sprint backlog1

SPRINT BACKLOG

Lista de Tarefas de um Sprint (exemplo 1)


Sprint backlog2

SPRINT BACKLOG

Lista de Tarefas de um Sprint (exemplo 2)


Sprint tasks

SPRINT TASKS

Especifica como fazer o “O que é?” do PBI

Requer um dia de trabalho ou menos

Restante do trabalho é reestimado diariamente


Reuni es

REUNIÕES

Sprint Planning Meeting

Reunião de Planejamento do Sprint

Daily Scrum

Scrum Diário

Sprint Review Meeting

Reunião de Revisão do Sprint

Sprint Retrospective Meeting

Reunião de Retrospectiva do Sprint


Sprint planning meeting

SPRINT PLANNING MEETING

Realizada no começo de cada Sprint entre o Product Owner e o time

Propósito é para negociar quais PBIs do Release Backlog serão inclusos neste Sprint

Time é responsável em reconhecer quais tarefas possam ser inatingíveis no momento

Esta reunião não é diária, ocorre uma vez por Sprint para dar forma ao mesmo


Daily scrum

DAILY SCRUM

Todos os dias no mesmo local e horário, os membros do time passam um total de 15 minutos reportando um para o outro

Cada membro resume o que ele fez no dia anterior, o que vai fazer hoje e quais os impedimentos que ele está sofrendo

Recomenda-se ao time sempre anexar ao Daily Scrum uma lista de tarefas, burndown chart e lista de impedimentos

O Daily Scrum ocorrerá diariamente, até o término de todas as tarefas do Sprint

Após o Daily Scrum inicia a execução das tarefas novas ou em andamento do Sprint


Sprint review meeting

SPRINT REVIEW MEETING

Após a execução diária de tarefas do Sprint, o time demonstra o novo incremento do produto

Deve ser feita uma demonstração funcional e não um relatório

Após a demonstração, o Product Owner declara se considera o incremento como finalizado

Quando considerado não finalizado, retorna ao Sprint Backlog para repriorização ou retorna ao Release Backlog


Sprint retrospective meeting

SPRINT RETROSPECTIVE MEETING

Ao término do Sprint, ocorre uma retrospectiva onde o time:

Reflete sobre seu processo

Inspeciona seu próprio comportamento

Toma ações para se adaptar a futuros Sprints

A retrospectiva jamais deve fugir dos pontos desconfortáveis do desenvolvimento

Esta reunião não é diária, ocorre após finalização de todos os PBIs e tarefas de um Sprint


Burndown chart

BURNDOWN CHART


Burndown chart1

BURNDOWN CHART

Eixo vertical representa a soma total de horas estimadas de todos os PBIs no Release Backlog

Para cada PBI finalizado, o tempo dele é subtraido do total de horas restantes

Com a subtração diária de PBIs, é possível obter uma média diária de horas completadas do Release Backlog

Tracejando uma linha adjacente do eixo vertical para o horizontal, consegue-se ver visualmente uma estimativa de dias para o término do Release Backlog, identificando o Burndown Velocity

Pode ser aplicado também no Product Backlog ou no Sprint Backlog


Ferramentas

FERRAMENTAS

HTTP://ONTIMENOW.COM

HTTP://SCRUMY.COM


Http ontimenow com

HTTP://ONTIMENOW.COM


Http ontimenow com1

HTTP://ONTIMENOW.COM


Http ontimenow com2

HTTP://ONTIMENOW.COM


Http ontimenow com3

HTTP://ONTIMENOW.COM


Http ontimenow com4

HTTP://ONTIMENOW.COM


Http ontimenow com5

HTTP://ONTIMENOW.COM


Http ontimenow com6

HTTP://ONTIMENOW.COM


Refer ncias

REFERÊNCIAS

Axosoft

Desenvolveu http://ontimenow.com

http://youtube.com/user/axosoft

Scrum Under 10 Minutes

http://www.youtube.com/watch?v=XU0llRltyFM

Scrum Reference Card

by Michael James, CollabNet Inc.

http://www.collab.net/scrumtraining


  • Login