Вы находитесь на странице: 1из 21
www.nerdintelligence.info facebook.com/nerdintelligence project

www.nerdintelligence.info

facebook.com/nerdintelligence

www.nerdintelligence.info facebook.com/nerdintelligence project

project

www.nerdintelligence.info facebook.com/nerdintelligence project
o nerd intelligence é um projeto de compartilhamento de conteúdo relacionado a: ü   Negócios &

o nerd intelligence é um projeto de compartilhamento de conteúdo relacionado a:

üNegócios & üTecnologia da Informação

acreditamos que quanto mais pessoas tenham tais conhecimentos a nossa sociedade será atingida por um turbilhão de boas ideias. o projeto surgiu da não popularizada troca que conhecimentos através, principalmente, das redes sociais. por isso o nosso trabalho é fornecer conteúdos como este para incentivar o seu crescimento profissional como um verdadeiro nerd!

NÃO DEIXE DE COMENTAR E COMPARTILHAR NOSSO CONTEÚDO!

www.nerdintelligence.info

facebook.com/nerdintelligence

o nerd intelligence é um projeto de compartilhamento de conteúdo relacionado a: ü   Negócios &

Sumário

Sumário Scrum 1.   A história do Scrum 2.   O conteúdo Scrum 3.   Nossas

Scrum

1.

A história do Scrum

2.

O conteúdo Scrum

3.

Nossas referências

Sumário Scrum 1.   A história do Scrum 2.   O conteúdo Scrum 3.   Nossas
Sumário Scrum 1.   A história do Scrum 2.   O conteúdo Scrum 3.   Nossas
Capítulo 1 a história do Scrum 1.   2.   3.   4.   Introdução O
Capítulo 1 a história do Scrum 1.   2.   3.   4.   Introdução O

Capítulo 1

a história do Scrum

1.

2.

3.

4.

Introdução O papel Scrum A teoria Os pilares

Capítulo 1 a história do Scrum 1.   2.   3.   4.   Introdução O
Capítulo 1 a história do Scrum 1.   2.   3.   4.   Introdução O

Capítulo 1

Capítulo 1 B em popular em diversas equipes de desenvol- vimento em todo o mundo, a

Bem popular em diversas equipes de desenvol-

vimento em todo o mundo, a metodologia Scrum tem tomado força no mercado brasileiro de TI, fundamentado no desenvolvimento ágil. Após a elaboração do manifesto ágil para desenvolvimento de software; o Scrum começou a se popularizar no desenvolvimento de produtos complexos desde o início dos anos 90. De lá pra cá muitas organizações adotaram a metodologia visando a melhoria na performance dos processos.

SCRUM

NÃO

é um processo ou técnica de desenvolvimento de produtos

 
SIM
 

SIM

Capítulo 1 B em popular em diversas equipes de desenvol- vimento em todo o mundo, a

é um framework onde se pode empregar diversos processos e técnicas

PAPEL DO SCRUM: fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para melhorias.

A teoria

Fundamentado na teoria de controle de processo empíricos com uma abordagem interativa e incremental otimizando a previsibilidade e o controle de riscos. O Scrum está fundamentado sobre TRÊS pilares.

A teoria Fundamentado na teoria de controle de processo empíricos com uma abordagem interativa e incremental

Os pilares do

SCRUM

A teoria Fundamentado na teoria de controle de processo empíricos com uma abordagem interativa e incremental

Transparência

Inspeção Adaptação

Transparência

O Scrum garante que aspectos do processo que afetam o resultado estejam visíveis aos que

controlam os resultados. Nada que acontece no processo Scrum deve ser estranho para um membro do time. A transparência do Scrum diminui a incerteza do pronto 1 .

inspeção

No Scrum diversos aspectos são inspeciona- dos numa frequência que garanta a identificação no

mínimo de variação do processo. Qualquer processo pode ser modificado pela inspeção. Contudo a inspeção excessiva pode atrapalhar o processo, use-a com moderação.

Adaptação

Uma vez que a inspeção identifica variações no processo, o Scrum é capaz de adaptar-se rapidamente à nova realidade. O Scrum conta com alguns pontos de inspeção e adaptação que trataremos mais à frente:

As Reuniões de Planejamento, as Reuniões Diárias, as Reuniões de Revisão e as Reuniões de Planejamento.

Retrospective

Time-Boxes
Time-Boxes

Planning 2

Review

Planning 1

Capítulo 2 O Conteúdo do Scrum 1.   Conteúdo do Scrum 2.   Os times Scrum

Capítulo 2

O Conteúdo do Scrum

Capítulo 2 O Conteúdo do Scrum 1.   Conteúdo do Scrum 2.   Os times Scrum
Capítulo 2 O Conteúdo do Scrum 1.   Conteúdo do Scrum 2.   Os times Scrum

1.

Conteúdo do Scrum

2.

Os times Scrum

3.

Os papéis do Scrum

4.

Os elementos do Scrum

5.

Os artefatos do Scrum

6.

As regras do Scrum

7.

As Time-boxes do Scrum

Capítulo 2

Capítulo 2 A metodologia Scrum tem foco nas pessoas envolvidas, portanto os papéis, cerimônias artefatos e

A metodologia Scrum tem foco nas pessoas

envolvidas, portanto os papéis, cerimônias artefatos e regras que compõem o framework são fundamentais para a melhoria na performance do processo.

Regras

Scrum
Scrum

Papéis

Artefatos

Cerimônias

Os times SCRUM

Projetados para otimizar flexibilidade e

produtividade. Para tal, um time Scrum deve ser:

auto-organizável, interdisciplinar e trabalhar com interações.

O Desenvolvimento ágil é composto por pequenos ciclos de desenvolvimento. Estes pequenos ciclos permitem melhoria e precisão no monitoramento e controle do processo com entregas constantes ao cliente. O time Scrum deve ser coeso e comprometido com os objetivos do projeto; sucesso ou fracasso são de todos.

Os papéis do Scrum

Team Scrum Product Master Owner
Team
Scrum
Product
Master
Owner

Product Owner: Maximizar o valor do trabalho; Scrum Master: Garantir o entendimento de todos; Team: Executar o trabalho.

O Scrum empre- ga eventos de dura- ção fixa (as time- boxes) para gerar uma regularidade. Entre os elementos do Scrum que tem duração fixa temos a Reunião de Planejamento, as Reuniões Diárias, a Sprint, a Revisão da Sprint e a Retrospectiva da Sprint. O Coração do Scrum é a Sprint, uma iteração curta (no máximo de um mês) que consiste no esforço de desenvolvimento. Toda Sprint deve entregar um incremento de valor ao produto e, seguindo o desenvolvimento ágil, uma Sprint começa assim que a anterior termina.

Os principais artefatos do Scrum são:

Backlog do Produto: Uma lista priorizada com todos os requisitos à serem desenvolvidos de um determinado produto. Backlog da Sprint: Lista com um conjunto de requisitos do Backlog do Produto à serem desenvolvidos em uma Sprint. Burndown: Ferramenta de medida do Backlog em relação ao tempo. Há o Burndown do Produto e o Burndown da Sprint que relacionam o Backlog do Produto e o Backlog da Sprint, respectivamente, com o tempo.

As regras fazem

o

elo

entre os

papéis, os

eventos de duração fixa e os artefatos. Iremos descrever estas regras neste material além de

algumas técnicas para melhorar o processo Scrum baseados em experimentos reais.

Dica: Quando as regras não são declaradas, espera-se que os usuários de Scrum descubram o que devem fazer. Não tente descobrir uma solução perfeita, porque geralmente o problema muda rapidamente. Ao invés disso, tente algo e veja como se sai. Os mecanismos de inspeção-e-adaptação inerentes à natureza empírica de Scrum irão lhe guiar.

Motivação:

Uma galinha e um porco estão juntos quando a galinha diz:

“Vamos abrir um restaurante!” O porco reflete e então diz:

“Como seria o nome desse restaurante?” A galinha diz:

“Presunto com Ovos!” O porco diz: “Não, obrigado, eu estaria comprometido, mas você estaria apenas envolvida!”

Os principais artefatos do Scrum são: •   Backlog do Produto : Uma lista priorizada com

Product Owner (P.O.): Responsável em criar e gerenciar as estórias e o Backlog do Produto. O P.O. também deve apresentar o Backlog da Sprint priorizado aos membros do time apresentando o valor do mesmo. No final de uma Sprint o P.O. é responsável por dar o status de pronto à entrega. Scrum Master (S.M.): Garantir que o time, durante a Sprint, esteja conforme os valores e o Backlog da Sprint passados pelo P.O. O Scrum Master educa o time, treinando-o e levando-o a uma melhor produtividade com maior qualidade. Em equipes muito pequenas é comum que o S.M. faça parte do time como um desenvolvedor sênior. Team: Desenvolvem o Backlog da Sprint em incrementos de funcionalidade. Geram entregas de valor. São interdisciplinares de modo que o desempenho medido é do time; são auto-organizáveis, ninguém diz como realizar as atividades. Eles decidem como transformar o Backlog da Sprint em entregáveis conforme passado pelo P.O.

Planejamento do produto: Tem o propósito de estabelecer um plano e metas para o time. O planejamento da versão do produto deve responder as questões:

Como podemos transformar a visão em um produto

vencedor da melhor maneira possível? Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?

No planejamento do produto é apresentado o

Backlog do Produto junto com

os riscos, as

características gerais das funcionalidades, o tempo, custo e o escopo do que será entregue.

Product Owner (P.O.) : Responsável em criar e gerenciar as estórias e o Backlog do Produto.
Product Owner (P.O.) : Responsável em criar e gerenciar as estórias e o Backlog do Produto.

Sprint: É a iteração em si, Sprints contém todos os eventos de duração fixa. Durante a Sprint o S.M. garante que não haverá mudanças que afetem a meta planejada. Cada Sprint termina com uma entrega de valor para o produto, ou seja, novas funcionalidades ou correção de módulos importan- tes; estas entregas são de responsabilidade do time, uma vez negociadas com o P.O. Somente o P.O. tem autoridade para cancelar uma Sprint, ele está em contado direto com a alta gerência da organização. Planning 1: Responsável em apresentar “o que?” será entregue. Aqui o P.O. apresenta o Backlog do Produto em formato de Estórias e, junto com o time, definem o Backlog da Sprint composta com o que o time se comprometeu a entregar. O P.O. deve estabelecer os critérios de aceitação, o que dará o status de “pronto” para a entrega.

Planning 2: Responsável em apresentar “como?” realizar as atividades. Aqui, sem a participação do P.O., o time quebra as Estórias em tarefas simples. Sendo auto gerenciável, o time é que define a ordem de execução destas tarefas. Geralmente no Planning 1 o Backlog da Sprint é definido com 70-80% da capacidade do time; esta “folga” é deixada para eventuais atividades não planejadas, muitas destas atividades são identificadas no Planning 2.

Sprint : É a iteração em si, Sprints contém todos os eventos de duração fixa. Durante

Review: No final da Sprint é feita a reunião do time com o P.O. para as entregas planejadas. As Estórias são apresentadas e o P.O., baseado nos critérios de aceitação, dá ou não o status de “pronto” para a entrega. Caso uma Estória não seja aceite o P.O. a replaneja junto com o restante do Backlog do Produto para encaixá-lo em outra Sprint. A Review também é responsável pela análise do desempenho do time:

Planejado x Realizado

Baseado no desempenho do time, o P.O. tem dados para o próximo planejamento. Sobre esta análise o time pode expor os pontos positivos e negativos da Sprint para que na próxima haja algumas possíveis correções.

Retrospective: Antes da próxima Planning 1, o time Scrum, junto com o S.M., se reúnem para formalizar as lições aprendidas, o que foi sucesso, o que foi fracasso. É na retrospectiva que o time identifica pontos de melhoria. Na Retrospective o S.M. age como um técnico incentivando o time para mais uma Sprint, ele é o agente motivador. Como os ciclos do Scrum são de curta duração é comum que o time precise periodicamente de algo novo, algo que quebre a rotina e as reuniões de retrospectiva são ótimos momentos para isso.

Review : No final da Sprint é feita a reunião do time com o P.O. para

Daily Meeting: O time deve se encontrar diariamente por, no máximo, 15 minutos; a ideia é que todos fiquem de pé, se possível, pois a finalidade desta reunião é que cada membro resuma o que fez até aquele momento, o que fará a partir dali e quais os obstáculos à vista. As reuniões diárias devem ocorrer sempre no mesmo horário e no mesmo lugar. As Reuniões Diárias melhoram a comuni- cação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

Artefatos:

Os artefatos do Scrum incluem o Backlog do Produto, o Burndown da Versão para Entrega, o Backlog da Sprint e o Burndown da Sprint.

Backlog do Produto: Os requisitos para o produto que o time está desenvolvendo serão listados no Backlog do Produto. O responsável por este artefato é o P.O (representante do cliente), ele é responsável pelo conteúdo, pela disponibilidade e pela prioridade. O Backlog do Produto nunca está completo; ele evolui à medida que o produto vai “tomando forma”. O Backlog é dinâmico, pois está

em constante mudança com a identificação de novas necessidades para este produto. O Backlog chega ao fim quando o produto final é entregue e aceito.

Dica :

Os

itens

do

Backlog

do

geralmente representados como

Produto são

Estórias

de

Usuário. Casos de Uso também são apropriados, mas são mais adequados para desenvolvimento de softwares críticos em termos de vidas ou de desempenho.

O

poder

do

Backlog

do

Produto

está

na

priorização dada pelo P.O. A priorização deste Backlog deve está alinha com a necessidade do

negócio. Estas Estórias são detalhadas proporci- onalmente com sua prioridade.

Backlog da Versão para Entrega: Tem as mesmas especificações do Backlog do Produto, contudo aqui é focado nas versões do produtos. Versões de certo produto são constantemente desenvolvidas pelos times, portanto o cuidado do P.O deve ser com a priorização dos requisitos necessários numa versão.

Backlog da Sprint: Uma vez que o P.O tenha seu Backlog do Produto ou da Versão priorizado é possível pensar em “pacotes de entrega”. O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento “pronto”. Muitas delas são elaboradas durante a Reunião de Planejamento da Sprint. O Backlog da Sprint é todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Backlog da Sprint devem ser decompostos. A decomposição deve ser suficiente para que mudanças no progresso possam ser entendidas na Reunião Diária. Este Backlog pode ser alterado ao longo da Sprint, isto geralmente acontece ou quando muda a necessidade do negócio ou quando o time identifica que não dará conta de tudo que se comprometeu.

Burndown da Sprint: O trabalho do time deve ser medido de alguma forma. O Burndown do Backlog da Sprint é um gráfico da quantidade restante de trabalho do Backlog da Sprint em uma determinada Sprint ao longo do tempo da Sprint. Para criar esse gráfico, determine quanto trabalho resta somando as estimativas do Backlog a cada dia da Sprint. A quantidade de trabalho restante para uma Sprint é a soma do trabalho restante para tudo do Backlog da Sprint. Acompanhe essas somas diariamente e utilize-as para criar um gráfico que mostre o trabalho restante ao longo do tempo. Traçando uma linha através dos pontos no gráfico, o Time pode gerenciar seu progresso em completar o trabalho de uma Sprint. A duração é determinada no Scrum pelo tempo da Sprint, mas o foco é no trabalho restante.

Dica: Sempre que possível, desenhe o gráfico de burndown à mão em uma folha grande de papel exibida na área de trabalho do Time. É mais provável que o Time veja um gráfico grande e visível do que um gráfico de Burndown da Sprint no Excel ou em alguma ferramenta.

Uma das principais regras do Scrum está no objetivo de uma Sprint, que é o incremento de valor somado ao produto. Aqui aparece a figura do “pronto”; o Pronto só é dado pelo P.O, pois ele que tem a visão do produto como um cliente.

O Pronto: Scrum sugere que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potenci- almente entregável, pois o Product Owner pode optar por implantar a funcionalidade imediata- mente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Dica: Algumas organizações são incapazes de desenvolver um incremento completo dentro de uma Sprint. Elas podem ainda não ter infraestrutura automatizada de testes para completar todos os testes. Nesse caso, duas categorias são criadas para cada incremento: o trabalho “pronto” e o trabalho “não pronto”. O trabalho “não pronto” é a porção de cada incremento que terá que ser completada mais tarde. O P.O sabe exatamente o que ele está inspecionando ao final da Sprint, porque o incremento atende à definição de “pronto” e o Product Owner entende essa definição. O trabalho “não pronto” é adicionado a um item do Backlog do Produto chamado “trabalho não pronto”, de forma que ele se acumula e isso é refletido corretamente no gráfico de Burndown da Versão para Entrega. Essa técnica cria trans- parência no progresso em direção à entrega.

Compromisso Coragem Foco Scrum Respeito Abertura
Compromisso
Coragem
Foco
Scrum
Respeito
Abertura

Exemplo de um quadro do processo Scrum:

Exemplo de um quadro do processo Scrum:

Nossas

Nossas referências 1.   www.scrum.org 2.   www.scrumalliance.org 3.   improveit.com.br / scrum

referências

1.

www.scrum.org

2.

www.scrumalliance.org

3.

improveit.com.br/scrum

Nossas referências 1.   www.scrum.org 2.   www.scrumalliance.org 3.   improveit.com.br / scrum
Nossas referências 1.   www.scrum.org 2.   www.scrumalliance.org 3.   improveit.com.br / scrum
Nossas referências 1.   www.scrum.org 2.   www.scrumalliance.org 3.   improveit.com.br / scrum