O documento apresenta uma metodologia ágil SCRUM. Resume os principais conceitos do Scrum como papéis, artefatos e eventos. Explica termos como Product Backlog, Sprint, Daily Scrum e Planning Poker. Apresenta também uma comparação entre Scrum e PMBOK, destacando semelhanças no planejamento e gerenciamento de escopo e recursos humanos.
2. Agenda
Sobre
O que é Scrum ?
Papéis no Scrum
Principais artefatos do Scrum
Qual é o critério para decidir a estória que será
incluída no Sprint ?
Comparação Scrum Com PMBOK
Documentação
3. Sobre –Claudia Carolina Boletti
Paulista 25 anos
Editora e palestrante do grupo Net Coders
Graduação Sistemas de Informação(Fundação Santo
André)
Agile Coach
Atua na área desde 2008
Trabalhou em grandes empresas como: T-Systems,
Pirelli, Resource IT Solutions, e Usiminas.
“Unir-se é um bom começo, manter a união é um progresso,
e trabalhar em conjunto é a vitória”
Henry Ford.
4. Apresentação – Pablo Juan
1º Torneio de Robótica Lego Brasil
Técnico em Informática com ênfase em programação(Centro Paula Souza).
Graduação em Analise e desenvolvimento de sistemas(FIAP)
Mais de 7 Anos de experiência
CEO & Founder For Your System
Consultor .Net Sênior WorkInside
Consultor .Net Sênior P3Solutions
Microsoft Student Partner
“Que o teu orgulho e objetivo consistam em pôr no teu trabalho
algo que se assemelhe a um milagre”
Leonardo da Vinci.
5. Circulo de Apresentação
Uma bola ou um novelo que vai sendo jogado entre
eles sem ordenação.
O objetivo é um minuto por pessoa, para irem se
conhecendo cada vez melhor.
Cada um que recebe fala uma frase sobre um único
tema proposto, exemplos:
……. apelido, hobby e lazer
……. algo que fez profissionalmente e não faria
novamente
7. Por que surgiu o Scrum
Segundo o PMI Brasil, os problemas mais frequentes
são:
Não comprimento dos prazos
Problemas de comunicação
Mudança de escopo
10. O que é um SCRUM
Metodologias Ágeis vem sendo adotado de forma
acelerada por grandes empresas, como Microsoft,
Xerox, IBM, etc.
As metodologias ágeis aplicam uma coleção de
práticas, guiadas por princípios e valores que podem
ser aplicados por profissionais de software no dia a
dia.
11. O que é um SCRUM
Scrum possui seu foco no gerenciamento de projeto
da organização onde é difícil planejar à frente. É um
processo para construir software incrementalmente
em ambientes complexos, onde os requisitos não
são claros ou mudam com muita frequência.
12. O que é um SCRUM
É uma forma de planejar e gerenciar projetos
trazendo a autoridade da tomada de decisão a níveis
de propriedade de operação e certeza.
Scrum não é um processo prescribente, ou seja, ele
não descreve o que fazer em cada situação. Ele é
usado para trabalhos complexos nos quais é
impossível predizer tudo o que irá ocorrer
17. Sprint
É uma lista de objetivos ou requisitos bem definidos
cujo time de desenvolvimento irá trabalhar focado em
um período/ciclo de 1 a 4 semanas
19. Sprint Planning Meeting
Reunião onde SCRUM Team e o Product Owner
determinam quais funcionalidades e atividades serão
realizadas no próximo Sprint.
20. Sprint Review
O SCRUM Team e o SCRUM Master apresentam ao
Product Owner os resultados alcançados durante o
Sprint.
21. Sprint Retrospective
As Lições aprendidas
O que pode ser melhorado?
O que foi bom durante o Sprint?
23. Backlog do Produto
O product backlog é o coração do Scrum. É
aqui que tudo começa. O Backlog do Produto é
uma lista ordenada de tudo que deve ser necessário
no produto, e é uma origem única dos requisitos para
qualquer mudança a ser feita no produto. O Product
Owner é responsável pelo Backlog do Produto,
incluindo seu conteúdo, disponibilidade e ordenação.
24. Estoria, Tarefa Story Point
Estória é uma funcionalidade macro do Sistema
Tarefas são partes que compõe as estoria e que
devem ser implementadas pelo scrum team
Um Story Point é a estimativa relativa do "tamanho"
da atividade comparado com outra atividade no
projeto.
26. Estimativa
O princípio Lean do Nemawashi
decisões sejam tomadas lentamente
Imediatismo dos tempos atuais
Aguardar até o último momento para tomar uma
decisão representa sabedoria
As estimativas de tempo nos projetos Scrum seguem
os preceitos do Nemawashi.
28. Planning Poker
O Planning Poker é uma técnica estimativa
bastante utilizada em projetos ágeis que usam o
framework do SCRUM.A escala de
complexidade é baseada na sequência
de Fibonacci (0, 1, 2, 3, 5, 8, 13) e cada
participante do time que estiver comprometido
recebe um conjunto de cartas sendo cada uma
com o número de complexidade. o outro na
hora de mostrar as cartas.
30. O Cliente...
A Força Aérea deseja um novo avião O representante da entidade entrou em contato
com três empresas para analisar as propostas O representante deseja saber quantos
aviões vocês produziriam em TRÊS minutos Vocês tem 3 minuto para discutir e
passar a estimativa.
31. Analise da Proposta
A Força Aérea gostou das estimativas e vai
abrir concorrência Vocês deverão produzir um
protótipo do avião em três minutos. O escopo é:
- Deve possuir 12 janelas - Deve possuir uma
cabine - Deve possuir o símbolo das empresas
- Nas duas asas - Na traseira
32.
33. Com o escopo em mãos, agora é com
vocês! A empresa que mais produzir leva
o contrato. Vocês terão 3 sprints de 3
minutos para produzir. Terão mais 3
minutos para avaliar e adaptar o
processo, ao final dos sprints, visando
maior produtividade. Deverão dar uma
estimativa de produção a cada início de
sprint.
34. Os papéis
• Product Owner - Irá passar o escopo e aceitar o
produto
• Scrum Master - Não poderá produzir. Deverá
cuidar do time, avaliar o processo, remover
impedimentos e buscar matéria-prima.
• Equipe - Produzirá o produto e avaliará o
processo. Recebimento dos cartões, leitura
individual e devolução.
35. REGRAS
Sprints e replanejamento de 3 minutos cada minutos
Respeito incondicional ao tempo!
Conceito de linha de produção
O avião começa numa ponta e termina na outra
A engenharia a ser aplicada é de decisão do time
Não pode haver estocagem de matéria-prima.
O Scrum Master pode pegar 10 folhas quando a última
folha em estoque entrar na produção.
O produto precisa cumprir o escopo
Caso acabe o tempo e o produto estiver inacabado, ele
pode voltar para a produção no próximo sprint
37. Avaliando a dinâmica
Estimativas e limites de produção
Prototipação e geração de valor ao cliente
Gargalos e correções
Trabalho em equipe
Empowerment
Utilização de sprints
É melhor entregar todos aviões em 10 minutos ou uma %
a cada 3 minutos?
39. Sprint Backlog
Criado de acordo com os itens do product backlog
levantado pelo Product Owner, ou seja, de acordo
com os itens de maior prioridade é criado o Sprint
Backlog que a equipe terá a responsabilidade de
terminar até o próximo Sprint.
44. Daily SCRUM
É uma reunião com o SCRUM Team cujo propósito é
eliminar qualquer impedimento.
45. Daily SCRUM
Cada integrante deve responder a 3 perguntas:
1)O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?
2)O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?
3)Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento
da meta da Sprint?
47. Impedimentos Backlog
Lista de problemas que estão atrasando ou
atrapalhando as atividades do sprint
É tarefa do scrum master resolver esses problemas
48. Qual é o critério para decidir a estória que será
incluída no Sprint ?
50. Base da conversa
Base da conversa, é ideal quando a equipe não
possui histórico de sprints, ou seja, para equipes que
nunca trabalharam com SCRUM e não possuem
dados estátiscos para realizar o cálculo de
velocidade.
51. Base da conversa
A conversa gira em torno dos desenvolvedores, onde
o Scrum Master pergunta para cada membro do time
quanto tempo uma atividade do Backlog demora
para ser desenvolvida (em horas), e com base nisso
as horas necessárias para o projeto.
52. Velocidade dos sprints
Fórmula para velocidade estimada do Sprint:
(Dias de Recurso Disponível) = membro da equipe *
diasdisponiveis
(Dias de Recurso Disponível) * (Fator Foco) =
(Velocidade Estimada)
56. Gerenciamento do Escopo do Projeto
Estimar o Escopo do Projeto e produto
Product Backlog
Definir o Ciclo de Vida do Projeto
Scrum tem ciclo de vida vem definidos como foi mostrado
57. Gerenciamento de Recursos Humanos do
Projeto
Os recursos humanos para o projeto são
planejados considerando o perfil e o
conhecimento necessários para executá-lo.
O Scrum Master e o Product Owner são
responsáveis por garantir os recursos e a
continuação do projeto, através das
reuniões ao início de cada iteração e da
remoção de impedimentos levantados pelo
time.
58. Documentação SCRUM
E a documentação? Somente do que for estritamente
necessário.
Algumas perguntas podem ajudar:
A documentação reflete o sistema atual?
Se a resposta for não, então porque fazê-lo? Se a
resposta for sim, então há outra pergunta:
A documentação foi feita antes ou depois do
sistema pronto?
Geralmente a resposta é depois do sistema pronto.
Se esta é a resposta, então porque investir em
documentação antes do desenvolvimento?
59. Documentação
O SCRUM não é contra a documentação, o próprio
Product Backlog e o Sprint Backlog, podem ser
considerados documentações. Porém, outras
documentações, como casos de uso, diagramas e
tudo mais, são feitos daquilo que realmente se faz
necessário, e em paralelo ao desenvolvimento.
61. Exercício - Comando-ação x Auto-
Organização
Exercício número 1 : Equipe gerenciada por um
chefe, que ordenará os comandos “parar ou frente ou
direita ou esquerda” Cada integrante apenas pode
cumprir as ordens do gerente, sem questioná-las
Cada um que completar 20 passos levanta os braços
e fica parado
62. Exercício-Comando-ação x Auto-Organização
Exercício número 2 : Equipe auto gerenciada, 2
minutos de Planejamento antes de executar, quando
cada integrante fará o percurso com os mesmos
comandos, mas decididos por si só
63. Círculo de Feedback
Cada um precisa dar feedback a um colega sorteado
aleatoriamente.
Feedback com até 5 palavras sobre um ponto forte e
um a desenvolver.
Sugiro escreverem em PostIt e colá-lo no crachá ou
na roupa do colega.
Realizei esta ao final da retrospectiva, na ordem
inversa do quebra-gelo.
……. Ponto forte
……. Ponto a desenvolver
64. Exercicio Prático de Scrum
3 mins – As equipes se organizam e definem quem faz o que (quem faz design, escrita de
histórias, validações, a criação dos protótipos, tira dúvidas com o cliente, manter o tempo, e por aí
vai). Lembre que as equipes devem ser multidisciplinares. Então as pessoas podem se ajudar em
atividades.
7 mins – Apresentação do problema. Aqui você como facilitador usa sua imaginação e pensa em
funções que o caixa eletrônico vai ter, qual o público alvo e restrições do jogo, exemplo tempo
disponível para tirar dúvidas, e outras questões neste sentido.
15 mins – Primeira iteração. Nesta iteração, o time deve fazer planning (2mins de sugestão),
execução da iteração e retrospectiva. Na metade do tempo da iteração, deve fazer uma “diária”.
Então considere que cada dia termina depois de 7mins. E neste momento existe 1 min de reunião
diária para o time alinhar o que está ocorrendo. No décimo terceiro minuto, o time deve fazer sua
retrospectiva da iteração, para entender o que pode ser melhorado para a próxima iteração.
5 mins – Tirar dúvidas com os times e mostrar insights que foram vistos durante a primeira
iteração. Normalmente equipes focam demais em planejamento e não em execução. Outras
equipes focam demais em execução. Outras equipes não se organizaram e todos fazem de tudo e
não entregam nada. Aqui não se resolve nada muito profundo, o objetivo é dar pequenas dicas
para deixar visível aos times oportunidades de melhoria na sua comunicação e tática.
15 mins – Segunda iteração. Mesmo ciclo da primeira iteração, os times tentam entregar mais um
grupo de funcionalidades.
15mins – Retrospectiva do exercício, aqui serve como momento de reflexão e gerar uma discussão
com os participantes sobre agilidade e metodologias ágeis.
Usar a analogia que diz que um projeto atrasa um dia por vez
O princípio Lean do Nemawashi, estabelece que as decisões sejam tomadas lentamente, através de consenso, para que todas as alternativas relacionadas possam ser avaliadas e para que haja amplo comprometimento com relação ao que for decidido.
Isso soa um tanto estranho quando confrontado com o imediatismo dos tempos atuais. Nas culturas ocidentais, a demora do processo decisório costuma ser associada a algo negativo, como a hesitação.
Já nas culturas orientais, aguardar até o último momento para tomar uma decisão representa sabedoria. Por este motivo, as estimativas de tempo nos projetos Scrum seguem os preceitos do Nemawashi.
Procurar sites para essa dinâmica
Arrumar alguma dinamica para aplicar o Jogo a todos
Usar a analogia que diz que um projeto atrasa um dia por vez