Ari Stopassola Junior arijunior@gmail @ stopassola

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

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 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 e-mail 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. SPRINT BACKLOG Cada Sprint representa um grupo de PBIs do Release Backlog

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

22. 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 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. FERRAMENTAS HTTP://ONTIMENOW.COM HTTP://SCRUMY.COM

32. HTTP://ONTIMENOW.COM

33. HTTP://ONTIMENOW.COM

34. HTTP://ONTIMENOW.COM

35. HTTP://ONTIMENOW.COM

36. HTTP://ONTIMENOW.COM

37. HTTP://ONTIMENOW.COM

38. HTTP://ONTIMENOW.COM

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