O mundo ágil do SCRUM Alexsandro Marques 02/09/2009.

Apresentação em tema: "O mundo ágil do SCRUM Alexsandro Marques 02/09/2009."— Transcrição da apresentação:

1 O mundo ágil do SCRUM Alexsandro Marques 02/09/2009

2 Alexsandro Marques Coordenador de Projetos da Provider Sistemas
Scrum Master Graduando em Ciência da Computação Certified Scrum Product Owner Coordenador do User Group Scrum Recife

3 Metas Apresentar alguns conceitos chave do Scrum
Entender porque o Scrum é diferente Fazer com que vocês tenham mais interesse sobre o assunto

4 Motivação

5 32% Sucesso (no prazo, dentro do orçamento e com escopo completo)
* Fonte: Standish Group 32%  Sucesso (no prazo, dentro do orçamento e com escopo completo) 44%  Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo) 24%  Falharam (cancelados ou nunca usados)

6 Falta de envolvimento do usuário Falta de suporte da direção
Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos

7 Evite situações com grandes chances de resultar em falha

8 Manifesto Ágil Manifesto para o Desenvolvimento Ágil de Software
Há alguns anos, um grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo.

9 Indivíduos e interações mais que processos e ferramentas

10 mais que documentação abrangente
Software Funcionando mais que documentação abrangente

11 Colaboração do cliente mais que negociação de contratos

12 mais que seguir um plano
Responder às mudanças mais que seguir um plano

13 Princípios do de Software
Desenvolvimento Ágil de Software

14 12 Princípios Software funcionado
Construir projetos com pessoas motivadas Manter um ritmo constante Comunicação cara a cara Satisfazer o cliente Atenção contínua à excelência técnica 12 Princípios Avaliações regulares Equipes de negócios e desenvolvimento juntas Receber bem mudanças de requisitos Entregar software em menor tempo Simplicidade Equipes organizadas

15 SCRUM

16 Uma linguagem de programação Uma IDE de desenvolvimento

17 NÃO

18 iterativo e incremental
Scrum é um processo iterativo e incremental para desenvolvimento de produtos O Scrum foi criado oficialmente na década de 90, por Ken Schwaber e Jeff Shuterland, com a ajuda de Mike Beedle, John Scumniotales e Jeff McKenna. A sua criação foi na realidade feita de maneira completamente independente, em duas frentes: de um lado, Ken Schwaber, e do outro Jeff Shuterland. Em , Ken e Jeff se reuniram e documentaram o processo do Scrum como se conhece hoje em dia. Em 2001, Ken Schwaber e Jeff Shuterland fizeram parte do grupo de profissionais que assinou o Agile Manifest.

19 valor de negócio O objetivo é entregar o máximo de
possível no menor tempo

20 evidenciar os problemas
Ajuda à evidenciar os problemas

21 Cuidado!

22 O Scrum NÃO é a solução para os seus problemas

23 Projetos Scrum progridem em uma Um período constante leva
Sprints Projetos Scrum progridem em uma série de “sprints” Ocorre em um período de duas a quatro semanas Um período constante leva a um melhor “ritmo” O produto é projetado, codificado e testado durante o sprint

24 Scrum Framework Papéis Product Owner Scrum Master Time Cerimônias (reuniões) Sprint Planning 1 e 2 Daily Scrum Review & Retrospective Artefatos Product Backlog Sprint Backlog Burnup/Burndown Charts

25 Papéis e Responsabilidades

26

27 Product Owner Time Scrum Master

28 Porco Galinha Product Owner (dono do produto) Scrum Master
Team (Time/Equipe) Um Porco é alguém que tem sua pele em jogo. Mike Cohn se refere, muito felizmente, às pessoas com este papel como “Pessoas que têm seu bacon na linha.” Porcos são considerados os principais membros do time. Realizadores. Pessoas que fazem o trabalho. Galinha Presidentes Diretores Fonte:

29 Product Owner Define as funcionalidades do produto
Decide datas de lançamento e conteúdo Responsável pela rentabilidade (ROI)‏ Prioriza funcionalidades de acordo com as necessidades do cliente Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos O Product Owner, ou simplesmente PO, representa o cliente, patrocinadores e/ou financiadores do projeto.

30 Scrum Master Trabalhar com o Product Owner Cuidar do Time
Manter o processo funcionando Garantir a comunicação entre os envolvidos “comando e controle” Permitir que o time se auto-organize para realizar o trabalho Garantir que as vias de comunicação estejam livres e acessíveis Garantir e ajudar que o time siga o processo do Scrum Cuidar e proteger a equipe de interferências externas, de modo a garantir que a produtividade do time não seja a afetada Remover impedimentos (obstáculos) que o time encontrar Agir como facilitador na reunião de Daily Scrum

31 Time (2 - 9) Responsável por entregar os ítens do Sprint Backlog
Compromisso com as entregas Estimar os itens do Backlog Gerenciar o próprio progresso Auto organizados Permitir que o time se auto-organize para realizar o trabalho Garantir que as vias de comunicação estejam livres e acessíveis Garantir e ajudar que o time siga o processo do Scrum Cuidar e proteger a equipe de interferências externas, de modo a garantir que a produtividade do time não seja a afetada Remover impedimentos (obstáculos) que o time encontrar Agir como facilitador na reunião de Daily Scrum O time de Scrum é formado por pessoas comprometidas em realizar o trabalho proposto. Um time de Scrum tem diversas responsabilidades entre elas participar das cerimônias, as cerimônias são reuniões, formais ou não, que acontecem em momentos distintos da Sprint.

32 Cerimônias

33 Sprint Planning Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Sprint Retrospective

34 TIMEBOX!

35 Sprint Planning Planning - 4 horas 2 horas Planning 1 Planning 2

36 Definir o objetivo da Sprint
Planning 1 Participam Time Scrum Master Product Owner Reunião de estratégia Definir o objetivo da Sprint Comprometimento do Time

37 Planning 1 O Time, e somente o Time, pode decidir
e se comprometer a respeito do Trabalho que será executado.

38 Dividir as estórias em tarefas
Planning 2 Participam Time Scrum Master Reunião de planejamento tático Dividir as estórias em tarefas Reunião de designer de software

39 Reunião de curta duração(15 minutos)
Daily Scrum Reunião de curta duração(15 minutos) Reunião publica, onde todos participam Apenas os membros da equipe ScrumMaster E o Product Owner podem falar

40 Daily Scrum As três perguntas: #1 O que eu fiz desde a última reunião?
#2 O que eu vou fazer até a próxima reunião? #3 Quais os problemas estão impedindo a realização do meu trabalho? - Nos ajudam a analisar nossa velocidade/ritmo; - Fazem com que todo o time esteja a par do que está acontecendo em todo o projeto; - Identificam impedimentos; Integram diariamente o time; - E, principalmente, nos fornecem um termômetro sempre atualizado de "Como está o nosso projeto?"

41 Review Se preparar para a review Reunião com duração de 2 horas
Todos participam Apresentação dos resultados obtidos durante a Sprint Reunião informar, sem slides Se preparar para a review

42 Reunião com duração de 2 horas Reunião de portas fechadas
Retrospective Reunião com duração de 2 horas Participam Time Scrum Master Product Owner* Reunião de portas fechadas Detectar pontos de melhorias

43 Artefatos

44 Burnup/Burndown Charts
Product Backlog Sprint Backlog Burnup/Burndown Charts

45 Product Backlog O Product Backlog é uma lista de todas as funcionalidades desejadas no produto, estimadas pelo time e priorizadas pelo Product Owner. Nós as chamamos de estórias, ou algumas vezes apenas de itens do backlog.

46 Escrevendo ESTÓRIAS * User Stories

47 Uma estória de usuário, ou user story, é um requisito de sistemas de software formulado com uma ou duas sentenças em linguagem natural. Cada user story é limitada e pequena, de forma a caber perfeitamente em um pequeno papel de post-it. Isso é feito para de forma a garantir que estórias muito grandes sejam sempre quebradas e granularizadas. Se a sua estória esta grande demais para o post-it, diminua o post-it.

48 User stories são uma maneira rápida de lidar com requisitos do cliente
A intenção com a user story é ser capaz de responder mais rápido e com menos overhead as mudanças nos requisitos voláteis do mundo real.

49 Como “usuário do sistema” Quero “funcionalidade”
Para “valor de negócio” Mike Cohn

50 CRITÉRIOS DE ACEITAÇÃO
Na parte de trás da estória, normalmente são escritos os critérios de aceitação. Critérios de aceitação funcionam como um abalizador de entendimento do que é “pronto” entre o desenvolvedor e o cliente, para aquele requisito específico. Criam entendimento sobre quando a tarefa está pronta

51 Exemplo de uma User Story
Como Gestor, Quero que as informações pessoais dos clientes fiquem gravadas em formato criptografado no banco de dados, Para garantir a privacidade e a segurança dos dados dos meus clientes. Critérios de aceitação: - Ter os dados armazenados no banco de dados e arquivos de troca do sistema usando algoritmo de criptografia do tipo chave publica/chave privada. Mike Cohn

52 Sprint Backlog O Sprint Backlog é a lista de tarefas que o time se comprometeu com o Product Owner a implementar durante a Sprint, após a reunião de Sprint Planning 1 & 2.

53 Burnup/Burndown Charts
Os gráficos de Burndown e Burnup são a melhor ferramenta do time para manter registro da velocidade atual do trabalho.

54 Sprint Burndown

55 Sprint Burn Up

56

57

58 Problemas comuns na adoção de Scrum

59 Product Owner pouco presente
Sem Visão Sem release plan Sem product backlog

60 Falta estimativa Falta priorização Falta acompanhamento
Se o Product Backlog não é mantido Falta estimativa Falta priorização Falta acompanhamento

61 Se as cerimônias não acontecem
Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos

62 Sem retrospectivas Falta de uma maneira de melhorar o trabalho do time (lembram do ballpoint?) Mesmos erros acontecem sempre Impedimentos não são removidos

63 O que é difícil em Scrum? Detalhes podem escapar se não for gerenciado corretamente Criar e manter um Product Backlog requer trabalho

64 Então... Scrum é um processo ágil que permite manter o foco
na entrega do maior valor de negócio, no menor tempo possível. Isto permite a rápida e contínua inspeção do software em produção (em intervalos de duas a quatro semanas).

65 Então... As necessidades do negócio é que determinam
as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”.

66 Quem usa? Microsoft Yahoo Google Philips Siemens Nokia Globo.com
Provider Sistemas*

67 Curso de Gerenciamento de Projetos com Scrum
Próximos passos Curso de Gerenciamento de Projetos com Scrum 12 e 19 de Setembro

68 Perguntas

69 Dicas www.alexsandromarques.wordpress.com www.scrum.org.br