Um resumo sobre Scrum.

Rafael Vinicius Kuhn Toebe.

@rafaeltoebe

rafael_viny@hotmail.com

Conteúdo Por que os projetos falham? ......................................................................................................... 4

O que estamos fazendo de errado? .......................................................................................... 5

O que torna a forma atual de gerenciamento de projetos questionável? ............................... 6

O que é Scrum? ......................................................................................................................... 6

Como escolher uma metodologia/framework para usar na minha empresa? ............................. 6

Pilares do Scrum ............................................................................................................................ 7

Transparência: ....................................................................................................................... 8

Inspeção: ............................................................................................................................... 8

Adaptação: ............................................................................................................................ 8

Manifesto para o desenvolvimento ágil de software. .................................................................. 8

O Scrum é composto pelo seguinte: ............................................................................................. 8

Responsabilidades dos papéis definidas pelo Scrum. ................................................................... 9

Responsabilidades do Scrum Master: ................................................................................... 9

Responsabilidades do Product Owner: ................................................................................. 9

Responsabilidades do Time: ................................................................................................ 10

A visão. ........................................................................................................................................ 11

O tamanho das Sprints. ............................................................................................................... 12

A síndrome de Estudante: ................................................................................................... 12

Definindo o estado “Done” (Pronto). .......................................................................................... 13

Sobre o Done. ...................................................................................................................... 13

Definindo o estado “Ready” (Preparado).................................................................................... 13

O Product Backlog. ...................................................................................................................... 14

User Stories (procedente do XP). ................................................................................................ 14

Story – Writing Workshop. .................................................................................................. 14

O que é necessário para fazer um Story – Writing Workshop? .......................................... 14

EPIC. ............................................................................................................................................. 15

Há perigo para estimar um epic? ............................................................................................ 15

Themes. ....................................................................................................................................... 15

Sprint Planning Meeting. ............................................................................................................. 15

Estimando Story Points. .............................................................................................................. 17

Planning poker. ........................................................................................................................... 17

Execução da Sprint. ..................................................................................................................... 18

A reunião diária. .......................................................................................................................... 19

Importância da reunião diária: ............................................................................................ 19

Mudanças no Sprint Backlog durante sua execução. .................................................................. 19

Sprint Review. ............................................................................................................................. 19

Participantes em uma Sprint Review ...................................................................................... 20

Importância da Sprint Review. ................................................................................................ 20

Consequências da Review. .................................................................................................. 20

Retrospectiva. ............................................................................................................................. 20

Ciclo de vida de um projeto Scrum ............................................................................................. 21

Para refletir: ................................................................................................................................ 22

Diferença entre Problema e Impedimento. ................................................................................ 22

Em uma rápida pesquisa durante a certificação CSM foram detectadas os seguintes problemas:

Por que os projetos falham?

Em um documento (mais precisamente um relatório) formulado por grupo chamado Stanches Group

mostra uma realidade preocupante e que não mudou em nada (apenas piorou) nos ultimos anos:

Porcentagem de projetos concluidos, que tiveram mudanças e os que falharam.

AtrasosFalta de

comprometimento

Falta de Comunicação Retrabalho

Mudanças de escopo

entre outros

Como podemos ver nos dados acima, tivemos:

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)

Segundo o Gartner, 70% dos projetos falham no cumprimento de cronograma, custos e metas de

qualidade e 50% são executados acima do orçamento. Já o CHAOS divulgou que 50% dos projetos de TI

são cancelados, 82% são entregues com atraso e as pesquisas da KPMG destacam que menos de 40%

desses projetos alcançaram os objetivos de negócios um ano depois.

O que estamos fazendo de errado?

Na minha opinião um dos principais erros que todos cometem é usar um modelo de gerenciamento

desenvolvido a meados do século XVIII.

Durante aquela época era muito difícil encontrar mão de obra capacitada, então quem tinha certo nível de

conhecimento era colocado como chefe para ensinar aos menos capacitados como executar uma parte do

processo, e os chefes ficavam verificando se a execução foi feita corretamente.

Hoje em dia muitos colaboradores têm mais conhecimentos técnicos que seus respectivos chefes,

deixando o modelo mencionado acima defasado.

Outro erro é uma herança da engenharia civil, vamos à outra historinha:

Na engenharia civil as coisas são pouco complexas, por exemplo:

Vamos projetar um prédio:

Vai ter 10 andares, cada andar com quatro apartamentos, porcelana da marca fulana ou similar, cor

branca, etc.

Alguém já viu um cliente do engenheiro civil chegar quando está construindo o oitavo andar e falar:

Não era isso que eu queria, mudou as minhas necessidades, vai ter que ser dois quartos por andar! E

agora?

Ou seja, a engenharia usa o planning driver manager e funciona perfeitamente! Se tiver mudanças será a

troca da porcelana da marca fulana para a marca ciclano.

E agora eu pergunto: isso acontece no planejamento de software?

Hora de mudar de planning driver manager para value driver manager!

Gerenciar um projeto é um empreendimento, por sua natureza, cheio de incertezas

e mudanças então por que continuamos apenas focado no plano.

“Entregar algo de valor para o cliente é mais importante que seguir o plano.”

“O plano não paga seu salário, quem paga e seu cliente.”

“O que adianta cumprir o escopo do seu planejamento e não cumprir a necessidade de seu cliente.”

O que torna a forma atual de gerenciamento de projetos questionável?

1- Requisitos não são completamente compreendidos no inicio do projeto.

2- Usuários só sabem exatamente o que querem após ver uma versão inicial do software.

3- Requisitos mudam durante o processo de desenvolvimento.

4- Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível.

Se você não conhece o problema completamente para poder especificar como acontece na engenharia

civil vou ensinar uma técnica que funciona:

- Calculo Hipotético Utilizando Técnicas Estatísticas. (CHUTE)

O que é Scrum?

Uma definição simples de Scrum: consiste em um conjunto de papéis e práticas simples orientados para o

processo de gerenciamento de projetos, especialmente de software.

Uma definição que eu gosto muito é a seguinte: Scrum é um processo iterativo e incremental para

desenvolvimento de produtos e gerenciamento de projetos.

Alguns autores dizem que o Scrum seria um framework para gerenciamento de projetos, outros insistem

em que Scrum é uma metodologia então nada melhor que uma citação do próprio criador:

“Ken Schwaber disse; Scrum não é uma metodologia, é um framework. O que significa que Scrum não

vai te dizer exatamente o que fazer”.

Como escolher uma metodologia/framework para usar na minha empresa?

Muitas vezes o

plano pode nos

deixar cegos

Para esta escolha observe a complexidade dos seus processos.

Pilares do Scrum

Processos empiricos

Processos prescritivos

Transparência Inspeção Adaptação

Scrum

Complexidade

Transparência:

Aspectos que afetam os resultados do projeto devem ser visíveis para os que gerenciam estes resultados.

O que é visto deve ser compreendido: se quem inspeciona o processo acredita que está pronto, isso deve

corresponder à definição de pronto utilizada.

Inspeção:

Os vários aspectos do processo devem ser inspecionados com uma frequência suficiente para que a

variâncias inaceitáveis no processo possam ser detectadas

Adaptação:

Se a inspeção determinar que um ou mais aspectos do processo esta fora dos limites aceitáveis e que o

produto que resultara será inaceitáveis, ele deve ajustar o processo ou o material sendo construído, este

ajuste deve ser feito o mais rápido possível para evitar outros desvios.

Manifesto para o desenvolvimento ágil de software.

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando

outros a fazê-lo. Através deste trabalho, passamos a valorizar:

1. Indivíduos e interação entre eles mais que processos e ferramentas

2. Software em funcionamento mais que documentação abrangente

3. Colaboração com o cliente mais que negociação de contratos

4. Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Fonte: Manifesto Ágil.

O Scrum é composto pelo seguinte:

Responsabilidades dos papéis definidas pelo Scrum.

Responsabilidades do Scrum Master:

Permitir que o time seja auto

gerenciável.

Garantir que os caminhos para a

comunicação do time estejam abertos

permanentemente.

Garantir e auxiliar o time a seguir

corretamente as práticas do Scrum.

Remover qualquer impedimento que o

time encontre.

Proteger o time de interferências

externas para garantir que sua

produtividade não seja afetada.

Facilitar as reuniões do projeto

(Planning Meeting, Daily Meeting,

Review e Retrospectiva).

Responsabilidades do Product Owner:

Definir visão do produto.

Gerenciar retorno sobre investimento

(ROI).

Apresentar ao time os requisitos

necessários para entrega do produto.

Priorizar cada requisito de acordo com

seu valor para o negocio/cliente.

Gerenciar a entrada de novos requisitos

e sua priorização.

Planejar entregas.

Atuar como facilitador quando mais de

um cliente estiver envolvido no

projeto.

Colaborar com o time.

•Product Backlog

•Incremento de Funcionalidades

•Sprint Backlog

•Burndown Chart

•Scrum Master

•Product Owner

•Time

•Reunião diaria

•review

•retrospective

• Sprint Planning Meeting

• Tempo da Sprint de 2 a 4 semanas.

• tamanho do time .

• Não modificar o Backlog durante a Sprint.

• as reuniões devem ser ser diárias

Regras Eventos

ArtefatosPapéis

Responsabilidades do Time:

Auto-organizáveis.

Multidisciplinares.

Possuem de 5 a 9 membros.

Comprometidos com o trabalho.

Focado em metas.

Responsável por fazer o necessário

para atingir essas metas.

Comunicativos.

Organizados em um espaço físico

apropriado para o trabalho.

Responsável para a resolução de

conflitos.

A visão.

Procurando na internet por imagem que

mostram o fluxo do Scrum vejo que a maioria

começa pelo product backlog, porem todo

projeto Scrum deve iniciar pela visão.

Lembre-se:

A visão deve ter no mínimo o tamanho de um release.

Qualquer priorização sem visão é apenas ideia do P.O.

Visão fixa, product backlog variável.

A visão é um parâmetro que representa o que deve ser satisfeito no final do projeto.

Para a definição da visão o Product Owner colhe informações junto aos usuários finais, clientes, time,

executivos, stakeholders, envolvidos no projeto, etc.

O plano mínimo necessário para iniciar um projeto Scrum consiste de um documento de visão e um

product backlog. A visão descreve porque o projeto esta sendo implementado e o que se deseja no final.

Visão

Informações do Produto

Informações do Processo

Informações do proejto

Projetos sem

visão é

suicídio.

Uma visão efetiva deve responder os seguintes questionamentos:

Quem irá comprar o produto?

Quais os clientes que o produto foca em atender?

Quais são os usuários alvos?

Quem são os usuários alvos?

Quais necessidades do cliente e dos usuários o produto pretende satisfazer?

Quais atributos o produto deve possuir para satisfazer as necessidades do usuário?

Quais os atributos do produto garantirão o sucesso do mesmo?

Quais são os diferenciais do produto em vista dos concorrentes?

O tamanho das Sprints.

O tamanho recomendado pelo Scrum é de sprints com duração de 2 a 4 semanas, porem não devemos nos

deixar cegar seguindo a risca a “receita” do Scrum e ferindo um dos seus princípios de Agilidade:

A Adaptação.

Leve em consideração as seguintes situações para escolher o tamanho de sua Sprint:

Mudanças constantes no topo do Product backlog e equipes com síndrome de estudante devem

preferentemente trabalhar com sprints curtos.

Quando existe uma dificuldade em entregar valores aos interessados devem ser usado sprints

curtos.

Times e/ou clientes cansados de sprints curtos devem aumentar a duração das mesmas.

O cliente não sabe o que quer? Sprints curtos.

Sprints muito curto podem ser estressantes.

A síndrome de Estudante:

É a atitude que muitos estudantes têm de começar a se dedicar inteiramente a uma tarefa logo antes do

prazo final.

Dica:

Para saber se o time tem síndrome de estudante observe os dois primeiros e os dois últimos dias de uma

sprints, caso o primeiro dia for tranquilo e o ultimo um caos, sua equipe sofre deste problema.

Para descobrir se você tem síndrome de estudante pense em quantas vezes usa a opção soneca do celular

logo pela manha.

Lembre-se:

O objetivo da Sprint é definido pelo tamanho da mesma, e não o objetivo que define o tamanho

dela.

Após definir o tamanho da Sprint o mantenha por um largo tempo.

Definindo o estado “Done” (Pronto).

Definição de Done é uma premissa que visa garantir o que está sendo entregue REALMENTE atende as

necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnologia.

Exemplo:

- Implementações com boas práticas de engenharia (ex. testes automatizados).

- Implantações no ambiente de produção.

- Com documentação técnica e de usuário.

Sobre o Done.

Configurável de estória para estória, projeto para projeto de empresa para empresa.

É um compromisso entre o time e o product owner referente aos itens do product backlog.

A qualidade não é negociável na composição do estado Done.

O pronto deve ser definido apenas para coisas imprescindíveis.

Definindo o estado “Ready” (Preparado).

Uma definição que gosto muito é a Ready (esta não descrita no Scrum) e a ready, que nada mais é que um

compromisso do Product Owner com o time sobre os requisitos dos itens do product backlog.

Exemplos:

Para quem é importante a user history.

O que deve ser atendido na user history.

Porque da user history estar no backlog.

Protótipo de tela.

Estes são exemplos para que entendam a definição de “ready” que nada mais é que uma especificação

mínima necessária para que o time possa desenvolver seus trabalhos.

O Product Backlog.

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para que a visão do produto

seja alcançada.

Esta lista é definida pelo Product Owner e não precisa estar completa no início do projeto. Pode-se

começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog

cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Com a lista de itens do product backlog feita, o time prioriza e determinam quais destes itens poderão ser

concluídos durante a execução da Sprint.

Após a priorização tais itens são transferidos do Product Backlog para o Sprint backlog. Ao fazer isso, a

equipe quebra cada item da Sprint Backlog em uma ou mais tarefas, isso ajuda a dividir o trabalho entre

os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente

relacionadas às funcionalidades solicitadas.

User Stories (procedente do XP).

É uma técnica para representar requisitos em um product backlog. Ela descreve uma funcionalidade que

deve fornecer valor para o usuário ou cliente de um projeto de software.

Story – Writing Workshop.

São reuniões em que desenvolvedores, usuários, clientes, stakeholders, Product Owner e qualquer pessoa

que deseja contribuir e/ou estejam envolvidas no projeto com o objetivo de descobrir estórias.

O que é necessário para fazer um Story – Writing Workshop?

Folha de rascunhos.

Post-it.

Um quadro branco

Canetas para o quadro (varias cores).

Canetas e lápis.

E o principal, as pessoas.

Dicas:

Focar na quantidade, ao invés de qualidade (estamos em busca de ideias).

Não perca tempo com detalhes.

Não julgue as idéias.

Não se preocupe com as prioridades.

A estrutura de User Story pode ser:

UM [ator]

PODE [fazer algo]

ou o modelo tradicional

COMO [ATOR],

QUERO/DEVO/POSSO[FAZER]

ALGO/PARA[GERAR VALOR]

Cuidado:

Usuário não deve ser mencionado como perfil.

Detalhes, preferentemente os técnicos não entram nas user stories.

Pense sempre pela ótica do usuário.

Lembre-se:

Se quiser requisitos bem definidos não use user stories.

User stories são ótimas para comunicar uma idéia.

Responda essas perguntas tendo em mente a visão do produto.

EPIC.

São estórias possui muitas incógnitas para poder saber qual o esforço necessário para ela definida ou

seu esforço é muito grande para ser terminada em uma Sprint pode ser chamada de EPIC.

Há perigo para estimar um epic? Ao estimar um epic sem antes quebrá-la em varias estórias pequenas pode ser desastrosa pois

geralmente sempre existe uma diferença enorme entre o esforço estimado e o tempo total do epic.

Se for criado um orçamento a partir de um epic pode obrigar a equipe a concluir uma determinada

quantidade de trabalho desconhecida com um orçamento determinado.

Um exemplo:

Esta estratégia é semelhante a uma ida ao supermercado pensando em fazer uma refeição à noite com

uma quantia fixa de dinheiro para gastar, mas nenhuma idéia do que precisa ser comprado. É seguro

assumir que qualquer pessoa nessa situação teria muitas perguntas. O que estou fazendo? Quais são

os ingredientes? Se eu não posso pagar todos os ingredientes, quais são as mais importantes?

Basicamente, este cliente é deixado em uma posição difícil: Ele sabe que tem uma refeição para

preparar e ingredientes para comprar, mas, fora isso, ele está no escuro. O mesmo poderia ser dito do

Product Owner, que se compromete a estimar um epic.

Importante:

Epic não é um conjunto de estórias.

Sempre estão nas ultimas posição do backlog.

Epic sempre vão morrer (quando forem quebrados em estórias menores).

Themes.

É um conjunto grande de estórias relacionadas por um objetivo de negocio importante.

Estes themes podem ser um grupo de estórias pequenas agrupadas referentes a um assunto.

Sprint Planning Meeting.

A reunião Sprint Planning é quando o time e o Product Owner determinam quais funcionalidades e

atividades serão realizadas no próximo Sprint.

A reunião conta com a presença do Product Owner, Scrum Master e de todo time, e quaisquer

interessados, diretores ou representantes do cliente.

A Sprint Planning é dividida em duas partes:

Primeira parte: é decidido o que será feito na Sprint (Planejamento estratégico).

Segunda parte: é quando o time decide como construirá essas funcionalidades, e as tornará um

incremento do produto durante essa Sprint (Planejamento tático).

Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade para

o time, e o time faz perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais

atividades eles irão mover do Product Backlog para o Sprint Backlog.

Juntos, o time e o Product Owner definem um objetivo para o Sprint (Meta da Sprint), que é uma breve

descrição do que se pretende atingir na Sprint. O sucesso do Sprint será verificado posteriormente durante

a reunião da Sprint Review, baseado na meta da Sprint em vez de itens específicos do Sprint Backlog.

Depois da reunia de Sprint Planning, o time se reúne separadamente para discutir o que foi dito e decidir

o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações

com o Product Owner, mas será sempre prerrogativa do time determinar o quanto eles podem se

comprometer.

Considerações

O Product Owner não precisa descrever cada item do Product Backlog. Dependendo do tamanho do item

e da velocidade do time pode ser suficiente para descrever apenas os itens de maior prioridade, deixando

a discussão dos itens de menor prioridade para a próxima reunião Sprint Planning. Normalmente, na

medida em que o time avançar na lista de Product Backlog, ele terá melhor noção do que poderá ser feito

no próximo Sprint.

O tempo da Sprint planning geralmente é de 8 horas para Sprints de um mês ou 5% do tempo da Sprint

caso elas forem menores há um mês.

Lembre-se:

As metas são definidas pelo time.

O Product Owner deve vir com o Product Backlog priorizado.

Somente o time pode saber o que ele é capaz de fazer.

Conselho de W. Edwards Deming.

“Uma meta numérica leva a distorção e ao fingimento especialmente nas situações em que o sistema não

tem condição de atingir a meta”.

Explicação rápida:

Imagine que você esteja colocando como meta um número relacionado ao desempenho do time, então

este time sempre vai limitar seu Sprint backlog a este número, mesmo que seja capaz de ter um

desempenho melhor que a estabelecida.

Estimando Story Points.

Quando vamos planejar, normalmente nós não sabemos exatamente quem vai implementar quais partes

de quais estórias.

Estórias normalmente envolvem diversas pessoas e diversos tipos de habilidades (design de interface de

usuário, codificação, teste, etc.).

Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimento do quê trata a

estória. Pedindo para todos estimarem cada item, nós nos certificamos que cada membro da equipe

compreende do que cada item se trata. Isso aumenta a probabilidade de que os membros se ajudarão

durante o sprint. Isso também aumenta a probabilidade de que questões importantes sobre a estória surjam

cedo.

Quando pedimos que todos estimem uma estória, frequentemente descobrimos discrepâncias onde duas

pessoas da equipe têm estimativas bastante diferentes para a mesma estória. Esse tipo de

coisa é melhor ser descoberto e discutido o quanto antes.

Se você pedir à equipe para que gere uma estimativa, normalmente a pessoa que melhor entende a estória

será a primeira a revelar a sua.

Infelizmente, isso afetará fortemente as estimativas de todo o resto.

Planning poker.

Cada membro da equipe recebe um baralho de 13 cartas, 10 delas com números (seguindo a tabela de

Fibonacci) e as outras três são cartas especiais como descreveremos mais abaixo. Sempre que uma estória

deve ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo e coloca-a

virada para baixo sobre a mesa.

Após todos ter estimado a estória as cartas são reveladas, e caso houver uma grande divergência entre

duas estimativas, a equipe discute as diferenças e tenta chegar a uma visão comum do trabalho envolvido

na estória. Eles podem fazer algum tipo de decomposição de tarefas. Depois disso, a equipe faz

novamente à estimativa. Este processo é repetido até chegar a um consenso ou próximo a um.

É importante lembrar aos membros da equipe que eles devem estimar a quantidade total de esforço

envolvido na estória.

Caso deseje estimativas mais precisas, quebre as estórias em tarefas menores e estime-as.

Existem algumas cartas especiais:

0 = Estória feita ou que leve apenas alguns minutos para a sua conclusão.

? = Não se tem idéia do esforço envolvido para terminar essa estória.

Xícara de café = Pedido de pausa.

Lembre-se:

O esforço estimado para os itens do product backlog deve ser negociado entre o time e o Product

Owner.

Use o bom censo (Ambos, o time e o PO).

Estimar baseando-se em esforço e não em complexidade.

A quantidade de rounds recomendada para o planning poker é três rodadas, após isso é

desperdício de tempo.

O Planning poker estimula o dialogo entre os rounds.

A cada rodada os membros que mostram as estimativas mais extremas (tanto a menor quanto a

maior) devem explicar por que estimaram o item com aquele tamanho.

Você pode comparar as suas estimativas com o que já foi estimado e não com o que ainda falta

estimar.

Itens com tamanho 40 ou 100 são considerados EPIC e devem ser quebrados.

Na parte tática da Sprint planning Meeting, o time trata a questão de “como?”, ou seja, decide como

transformara aquela parte que foi selecionada do product backlog em um incremento pronto e

implementado.

Nesta parte da reunião as estórias são quebradas em tarefas, e as tarefas descompostas em atividades que

possam ser realizadas em menos de um dia, esta lista de tarefas são denominadas Sprint backlog.

Lembre-se:

É responsabilidade do time se auto-organizar para delegar e se encarregar das tarefas da Sprint

backlog.

O Product Owner deve estar presente nesta parte da reunião para esclarecer duvidas sobre os

itens e caso for necessário renegociar as estórias selecionadas para compor a Sprint Backlog.

Nesta parte da reunião podem estar presentes outras pessoas que tenham domínio sobre os

assuntos técnicos ou de negocio que envolve a Sprint backlog.

Meta da Sprint é o que o time tem o “compromisso” que alcançar.

Plano da Sprint é o que o time “pretende” alcançar.

No final da Sprint planning teremos:

Um conjunto de itens do product backlog que foram selecionados para fazer parte da nossa

Sprint backlog.

Os itens selecionados quebrados em tarefas.

A meta da Sprint.

Execução da Sprint.

A reunião diária.

Diariamente o time realiza uma reunião de 15 minutos na qual os membros devem responder a três

perguntas:

O que fiz desde a ultima reunião?

O que pretendo fazer até a próxima?

Tive ou estou tendo algum impedimento?

Importância da reunião diária:

Todos sabem o que todos estão fazendo (transparência).

Ajuda a remover impedimentos.

Ajuda a descobrir impedimentos.

Sincroniza o trabalho da equipe.

Estabelecer um compromisso do membro com a equipe sobre o que ele vai fazer até a próxima

reunião diária.

Mudanças no Sprint Backlog durante sua execução.

O que o time se comprometeu a entregar ao Product Owner é o que deve ser entregue.

As mudanças que alterem a meta não são permitidas.

Caso haja alguma mudança no Sprint backlog que torne a meta inalcançável ou mesmo mude a meta este

Sprint deve ser encerrado e imediatamente iniciar o planejamento para o próximo Sprint, isto também

ocorre caso o time perceber que não vai conseguir atingir a meta.

Sprint Review.

É uma reunião com duração de 4 horas para sprints de um mês, caso a Sprint for menor há um mês esta

reunião não deve durar mais que 5% do tempo da Sprint.

No final de cada Sprint uma reunião de revisão da Sprint é realizada. Durante esta reunião o time mostra

o que eles realizaram durante o Sprint. Normalmente, este assume a forma de uma demonstração das

novas funcionalidades do produto.

A reunião de revisão de Sprint é intencionalmente mantida muito informal, tipicamente com regras

proibindo o uso de slides do PowerPoint e não permitindo mais de duas horas de tempo de preparação

para a reunião. A reunião de revisão de Sprint não deve se tornar uma distração ou desvio significativo

para a equipe, mas sim, deve ser um resultado natural do Sprint.

Participantes em uma Sprint Review

Participantes na revisão de Sprint tipicamente incluem o time, o Product Owner, o Scrum Master,

gerência, clientes e desenvolvedores de outros projetos.

Importância da Sprint Review.

A equipe ganha crédito por suas realizações.

Outros aprendem o que sua equipe está fazendo.

A apresentação atrai feedback vital dos stakeholders.

Apresentações é (ou deveriam ser) um evento social onde equipes diferentes podem interagir

umas com as outras e discutir seu trabalho.

Fazer uma apresentação força a equipe a realmente terminar as coisas e liberá-las

Consequências da Review.

Devolver ao Product Owner funcionalidades não terminadas e priorizá-las.

Remover do Product Backlog atividades que foram realizadas antecipadamente.

Trabalhar com o Scrum Master para reformular as equipes.

Priorização do product backlog.

Lembre-se:

Não existe Review sem Product Owner.

A Review e focada em apresentar valor e não especificações técnicas.

A Review é a parte interativa do Scrum.

Retrospectiva.

Após a reunião de revisão de Sprint, a equipe e o Scrum Master se reúnem para a reunião de

retrospectiva. Durante esta reunião, a equipe considera três coisas: o que correu bem, o que não fez, e que

melhorias poderiam ser feitas no Sprint seguinte. Sem o Product Owner nesta reunião, os membros da

equipe podem falar francamente sobre os sucessos e fracassos. É uma oportunidade especialmente

importante para a equipe se concentrar em seu desempenho global e identificar estratégias para melhorar

seus processos. Além disso, ela permite que o Scrum Master observe impedimentos que tenham

impactado no desempenho da equipe, e em seguida, trabalhar para resolvê-los.

Lembre-se:

O objetivo da Retrospectiva é melhorar o processo Scrum.

A Retrospectiva é a parte incremental do Scrum.

Ciclo de vida de um projeto Scrum

Para refletir

Acho que vi isso em um livro. Creio que essa seja a melhor definição para o que são as metodologias

ágeis. Vale a pena tentar aprender, incentivar e ingressar em seus projetos seja eles os mais diversos.

"Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto

em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com

estabilidade". (Highsmith, Jim. Agile Project Management, 2002)

Diferença entre Problema e Impedimento.

Problema:

Um problema é uma dificuldade na obtenção de um determinado objetivo.

Os problemas devem ser resolvidos entre os membros da equipe, sem a interferência do Scrum Master ou

qualquer outra pessoa.

Impedimento:

Um impedimento é uma dificuldade na obtenção de um determinado objetivo, no qual a resolução do

mesmo não está nas mãos do time.

Nesta situação o Scrum máster deve tomar as atitudes para que este impedimento não atrapalhe a meta da

Sprint.