Ari Stopassola Junior arijunior@gmail.com @stopassola Daniel Michaelsen dnmichaelsen@yahoo.com @micaweb #

Apresentação em tema: "Ari Stopassola Junior arijunior@gmail.com @stopassola Daniel Michaelsen dnmichaelsen@yahoo.com @micaweb #"— Transcrição da apresentação:

1 Ari Stopassola Junior arijunior@gmail.com @stopassola
Daniel Michaelsen @micaweb #

2 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

3 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.

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

5 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

6 DETALHE DA ITERAÇÃO

7 AGENTES

8 PAPÉIS Scrum Master Product Owner Scrum Team
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

9 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

10 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

11 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

12 ARTEFATOS PRODUCT BACKLOG USER STORY PRODUCT BACKLOG ITEM (PBI)
RELEASE BACKLOG SPRINT BACKLOG SPRINT TASK BURNDOWN CHART

13 PRODUCT BACKLOG

14 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

15 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

16 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 para amigos Como administrador do site, eu quero poder atualizar o FAQ sempre que necessário

17 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

18 RELEASE BACKLOG

19 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

20 Cada Sprint representa um grupo de PBIs do Release Backlog
SPRINT BACKLOG Cada Sprint representa um grupo de PBIs do Release Backlog

21 Lista de Tarefas de um Sprint (exemplo 1)
SPRINT BACKLOG Lista de Tarefas de um Sprint (exemplo 1)

22 Lista de Tarefas de um Sprint (exemplo 2)
SPRINT BACKLOG Lista de Tarefas de um Sprint (exemplo 2)

23 SPRINT TASKS Especifica como fazer o “O que é?” do PBI
Requer um dia de trabalho ou menos Restante do trabalho é reestimado diariamente

24 REUNIÕES Sprint Planning Meeting Daily Scrum Sprint Review 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

25 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

26 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

27 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

28 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

29 BURNDOWN CHART

30 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

31 HTTP://ONTIMENOW.COM HTTP://SCRUMY.COM
FERRAMENTAS

32

33

34

35

36

37

38

39 REFERÊNCIAS Axosoft Scrum Reference Card
Desenvolveu Scrum Under 10 Minutes Scrum Reference Card by Michael James, CollabNet Inc.