Você está na página 1de 56
Denis RoDRigues PeDRo Denisson VieiRa Scrum Definitivo As técnicAs e estrAtégiAs pArA você vencer usAndo

Denis RoDRigues PeDRo Denisson VieiRa

Scrum

Definitivo

As técnicAs e estrAtégiAs pArA você vencer usAndo o método ágil mAis fAmoso dA gAláxiA

Scrum Definitivo

2

Mindmaster Treinamentos

Apresentação

Antes de mais nada, permita-nos apresentar a MindMaster adequadamente.

Somos uma empresa de treinamento diferenciada, focada em formar profissionais com conhecimentos práticos e prontos para o mercado de trabalho. Criada por executivos de larga experiência no mercado de TI a MindMaster tem se destacado por oferecer os treinamentos que melhor acompanham as tendências do mercado. Já formamos mais de 4.000 alunos no Brasil e no exterior e ainda é só o começo.

Somos especializados em treinar nossos alunos para prática real dos métodos ágeis em seu dia- a-dia de trabalho, assim como, ajudá-los a obterem sua certificação profissional , consolidando ainda mais suas carreiras.

Se você está procurando um jeito de aprender Scrum e colocá-lo realmente em prática, você deve continuar a ler este livro e seguir cada uma das dicas apresentadas aqui.

Garantimos que ao se empenhar na realização de todas as práticas e na assimilação dos ensinamentos aqui prescritos, você poderá se tornar um verdadeiro Mestre Jedi do Scrum.

Que a Força esteja com Você!

Mestre Jedi do Scrum. Que a Força esteja com Você! Denis Pedro Denisson Vieira Co-founder Co-Founder
Denis Pedro Denisson Vieira Co-founder Co-Founder
Denis Pedro Denisson Vieira Co-founder Co-Founder

Denis Pedro

Denisson Vieira

Co-founder

Co-Founder

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

3

Mindmaster Treinamentos

Introdução

Há muito tempo atrás em uma galáxia muito, muito distante

Porque decidimos escrever este Livro

A esta altura você já deve até estar ouvindo a música tema de Star Wars, não é mesmo?

Realmente este épico filme foi marcante para várias gerações e usá-lo como tema para nosso Livro foi uma forma de apresentar o método ágil de gerenciar projetos de uma forma lúdica e também de fácil compreensão.

O Fato do Gerente de Projetos dos dias atuais ter que praticamente possuir poderes especiais para liderar projetos cada vez mais complexos, por certo exige que ele se transforme em um verdadeiro Jedi.

Cansados de ver centenas, porque não dizer milhares, de profissionais que ao procurar um jeito de aprender o Scrum para aplicar em seus projetos passam horas a fio no Google, apenas fazendo uma caça implacável a todo e qualquer material disponível para download, sem um norte ou linha de raciocínio lógico que o ensine os verdadeiros caminhos da Força, a forma elegante de estruturar projetos

em entregas ágeis, atendendo os objetivos de sua empresa, clientes e sim, da sua equipe, de um modo mais civilizado.

O Mundo mudou e o jeito ágil de entregar projetos de qualidade é

a nova tendência. É inevitável resistir, você não pode subestimar os

poderes do Scrum

:)

Continue aqui com a gente e aproveite cada parte deste livro. Ele é seu e vai te ajudar no caminho da agilidade.

Como este Livro está organizado

Na sequência dos capítulos do Livro você irá perceber que há algumas marcações importantes que te ajudarão a entender melhor os fundamentos do Scrum, bem como lhe ajudar a praticar e a iniciar a transição para o método ágil.

É importante que você absorva cada um dos conteúdos aqui relacionados, bem como, pratique cada um dos exercícios.

O Livro está dividido em 7 Capítulos:

1)

Os Fundamentos do Scrum

2)

O Time Scrum

3)

Eventos do Scrum

4)

Artefatos do Scrum

5)

Testes de Conhecimento

6)

Certificações Scrum

7)

Resumo

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

4

Mindmaster Treinamentos

nos primeiros 4 capítulos você irá encontrar as seguintes seções:

a Teoria sobre a Força

Nesta seção serão descritos fundamentos básicos que você deve aprender para assimilar de uma vez por todas o framework Scrum e suas características principais.

Aqui serão descritos os processos, eventos, papéis e responsabilidades do método ágil.

Como usar a Força

Nesta seção será apresentada qual a melhor forma de usar a força na medida certa e quais os benefícios reais de aplicabilidade de cada evento do Scrum. Afinal, de nada adianta você todo o conhecimento sobre a Força e não saber qual a melhor forma de aplica-la nos seus projetos.

entrar em ação

É a seção onde você colocará seus conhecimentos de Scrum na Prática. Aprendendo desde a iniciar a transição para o método ágil em sua empresa até a transformar um projeto regular para o método ágil.

Você será desafiado a vencer desafios específicos sobre Scrum e ao mesmo tempo verificar o seu progresso como profissional

Material para Baixar

Estarão a sua disposição uma série de modelos de documento para download. Embora muitos sigam a linha de que um bom Jedi faz o seu próprio Lightsaber, entendemos que ajudar você com material de apoio é apenas mais uma forma de ajudá-lo a compreender como colocar o Scrum na vida real. Você não apenas poderá baixar os arquivos, mas também será instruído sobre como utilizá-los.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

5

Mindmaster Treinamentos

Capítulo 1 Os Fundamentos do Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

6

Mindmaster Treinamentos

Capítulo 1: Os Fundamentos do Scrum

De acordo com o Scrum Guide, o Scrum é um framework para desenvolver e manter produtos complexos. Este livro apresenta a definição do Scrum, seus respectivos papéis, eventos, artefatos e as regras. Uma abordagem bastante objetivo seguirá, explicando de modo claro os conceitos e oferecendo ainda oportunidades de prática.

A Teoria Sobre a Força

o que é o scrum?

Scrum é um framework dentro do qual pessoas podem tratar e resolver problemas complexos de modo adaptativo, enquanto procuram entregar produtos com o mais alto valor possível do mais produtivo e criativo possível, sempre visando a satisfação do cliente.

O Scrum se diferencia de métodos tradicionais por ter as seguintes características:

• É um conjunto de processos Leve, que não demanda muito esforço ou ferramentas pesadas para sua prática

• É relativamente Simples de entender e praticar

• É Extremamente difícil de dominar, apesar de sua simplicidade,

o jeito de pensar ágil força o profissional a abrir mão de diversos

conceitos enraizados pelos métodos tradicionais e o força a pensar em qualidade e entrega contínua. Esta transição não tem de ser dolorosa e por meio da prática é possível perceber rapidamente os seus benefícios.

O Scrum é um framework estrutural que está sendo usada para

gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. A Melhoria contínua passa a ser seu companheiro constante.

Framework scrum

O framework Scrum consiste nas equipes do Scrum associadas a papéis,

eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

Neste livro vamos mencionar algumas ferramentas e técnicas do Scrum. Existem diversas estratégias específicas para o uso do framework Scrum e algumas são descritas em outros treinamentos específicos da MindMaster.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

7

Mindmaster Treinamentos

Teoria do scrum

O Scrum foi fundamentado nas teorias empíricas de controle de processo, ou empirismo.

O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

os 3 Pilares do scrum

Três pilares apóiam a implementação de controle de processo empírico:

transparência, inspeção e adaptação.

Transparência

Aspectos e informações relevantes do seu projeto devem estar sempre visíveis e claros para todos os participantes do projeto. Os responsáveis pelos resultados do projeto tem a solene responsabilidade de manter uma comunicação clara e promover constantemente a transparência.

Esta transparência deve ser promovida por um um padrão comum de apresentar as informações do projeto, de modo que qualquer observador possa ter o mesmo entendimento dos membros do time.

Por exemplo:

• Pode-se utilizar um quadro de tarefas, também como

conhecido como Kanban (será detalhado mais a frente) para apresentar a situação real do Product Backlog (Calma, você já vai aprender mais sobre isso :)

• Os requisitos da definição de pronto ou definition of

done (Isso é demais) deve ser compartilhada com toda equipe, especialmente com aqueles que receberão o produto do projeto.

• Os horários e locais das reuniões podem ser publicados em quadro de informações do projeto

• Um Burndown Chart pode ser apresentado para indicar

progresso e avanço do sprint (Tá ficando curioso com tanta informação nova?)

o

sprint (Tá ficando curioso com tanta informação nova?) o • Um quadro com as datas dos

• Um quadro com as datas dos releases

• E tantas outras formas de

transparência que puderem ser empregadas no dia-a-dia do seu

projeto que especialmente façam

a

diferença para sua organização.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

8

Mindmaster Treinamentos

inspeção

Os profissionais do time Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso do projeto a fim de detectar prontamente indesejáveis variações. Esta inspeção,não deve no entanto, ser tão freqüente que atrapalhe a própria execução das tarefas.

As inspeções quando realizadas de forma diligente, sem exageros, por profissionais especializados no trabalho de garantia de qualidade são normalmente as que obtém melhores resultados.

Por exemplo:

• A atuação de Testers ou Analistas de Testes em seu projeto

por certo podem contribuir demais com a inspeção da qualidade de seu projeto, dado o nível de especialização deste profissional.

• É de suma importância que você mensure os níveis de

qualidade do seu projeto, por exemplo, documentando e categorizando os bugs, que serão parte importante do dia-a-dia dos sprints que se seguirão à frente.

• Uma outra forma de promover a inspeção no seu projeto.

Ao iniciar a codificação de um projeto tenha em mente o uso de técnicas como o Test Driven Development e bibliotecas que o ajudem a rodar os testes unitários e identificar a respectiva cobertura de código, isto é, as classes de seu código podem e devem ser testados unitariamente e por meio de ferramentas práticas (e.g.: Sonar para projetos Java ou Ant para projetos .Net) é possível mensurar a inspeção através de testes unitários.

• Outro exemplo é a aplicação de integração contínua para evitar problemas no build da sua aplicação, isto é, na estruturação do seu ambiente de desenvolvimento.

adaptação

A adaptação é um dos pilares mais importantes do Scrum. Através deste prisma de tomada de ação, o projeto passa a ter mais foco na qualidade de entrega do produto do que normalmente ocorre em projetos tradicionais.

Um modo de se verificar a adaptação no mundo real é quando situações imprevistas acontecem na rotina do projeto e as datas acordadas junto aos nossos clientes ou mesmo os requisitos não mudam.

Por exemplo:

Se um Analista de Testes determina que um ou mais aspectos do produto que está sendo desenvolvido sofreu algum tipo de desvio para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo de desenvolvimento ou o próprio produto do projeto deve ser prontamente ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. Aqui é quando muitos alunos percebem a diferença do Scrum, pois embora haja uma certa liberdade com o compromisso da Auto-organização das equipes, ao identificar quaisquer desvios a equipe tem que se empenhar e adaptar-se às mudanças e eventuais desafios.

Dicas importantes:

O Scrum oferece quatro oportunidades formais para promover a transparência, inspeção e adaptação. Mais adiante no livro você terá mais detalhes, porém estes sãos os eventos onde você irá aplicar os pilares do Scrum.

• Reunião de planejamento da Sprint (O famoso Sprint Planning)

• Reunião diária (Daily Scrum ou Standup Meetings)

• Reunião de revisão da Sprint (Também conhecida como Sprint Review)

• Retrospectiva da Sprint

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

9

Mindmaster Treinamentos

o Manifesto Ágil

O Manifesto Ágil é o marco da criação de um jeito novo de se

desenvolver produtos. Uma nova forma focada exclusivamente em resultados e alta qualidade.

O manifesto pode ser encontrado www.agilemanifesto.org em diversos

idiomas.

Manifesto para Desenvolvimento Ágil de software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

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

Software em funcionamento mais que documentação abrangente

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

Responder a mudanças mais que seguir um plano

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

os nove principios do manifesto ágil

Abaixo seguem os principais itens que foram atualizados no Scrum Guide 2013 pelo Scrum.org. Você poderá baixar o guia e os conteúdos adicionais do Guia através do nosso site.

1 - Mudanças no Objetivo do Sprint

O texto que dizia que não são feitas mudanças que afetem o objetivo da Sprint, foi mudado para o que diz que não são feitas mudanças que possam por em perigo o objetivo da Sprint.

2 - Configuração Time Box Sprint Planning

Na versão 2011 a configuração da time-box da reunião de planejamento da Sprint era de 8 horas cravadas, já na versão 2013 o texto trás um “no máximo 8 horas”

3 - Transparência dos Artefatos

Há um reforço agora que os artefatos precisam ser transparentes para que todos tenham o mesmo entendimento dos artefatos.

4 - Participantes Sprint Planning

As questões que precisam ser respondidas ao final do planejamento da Sprint ganharam um novo item, o que deixa explicito que o Time precisa definir o Objetivo da Sprint.

5 - Time boxes

Foi deixado claro que os timeboxes são tempos máximos. O único timebox que não pode ser encurtado é o Sprint; os demais (daily, review e retrospectiva) podem ser finalizados, caso o seu propósito seja alcançado antecipadamente.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

10

Mindmaster Treinamentos

Além disso, foi deixado claro que, no final do sprint, no Sprint Review, o time colabora nos próximos itens que poderiam ser priorizados para otimizar o valor sendo entregue

6 - Equipe de Desenvolvimento

A regra que dizia: “A composição do Time de Desenvolvimento

permanece constante” foi retirada.

7

- Formato Reunião de Sprint Planning

O

formato da reunião de planejamento da Sprint na versão 2011

era de duas partes, onde na parte 1 era definido “o que” seria feito na próxima Sprint, e na parte 2 o Time definia “como” seria feito. Agora os autores mudaram para uma reunião só, com apenas uma parte, mas dividida em dois tópicos onde o “o que” e o “como” serão definidos.

8 - Participantes Sprint Planning

Os autores agora sugerem que os participantes desta cerimônia incluem o Time Scrum e os Stakeholders chaves convidados

9 - Daily SCRUM: As 3 Perguntas Alteradas

Foi ainda reforçada a importância do

atividade de planejamento, com foco em alcançar a meta da iteração. As três perguntas fundamentais do Daily Scrum foram modificadas para:

Daily Scrum como

O que fiz ontem que ajudou o time a atingir a meta

do sprint?

O que vou fazer hoje para ajudar o time a atingir a meta

do sprint?

Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint?

Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e continua de software com valor.

Acomodar mudanças de requisitos mesmo que seja ao final do desenvolvimento. Processos ágeis aproveitam as mudanças para dar vantagem competitiva ao cliente.

Entregar software funcionando frequentemente, o mais rápido possível.

Pessoas de negócios e desenvolvimento devem trabalhar juntos diariamente durante todo o projeto.

Criar projetos rodeado de indivíduos motivados, dê-lhes o ambiente e suporte necessários, e estabeleça confiança para que o trabalho seja feito.

Valores do sCRuM

Foco na Entrega

Transparência

Time-Box

Qualidade Total

Trabalho em Equipe

• Comunicação Constante

Comprometimento

AutoGerenciamento

• Trazer à tona os problemas

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

11

Mindmaster Treinamentos

o princípio da auto-organização

Este princípio é um dos mais difíceis para a transição ao método ágil, pois demanda confiança na equipe e por outro lado, a responsabilidade dos indivíduos para com as entregas comprometidas.

A maioria dos profissionais que atuam em métodos tradicionais desconfiam do pleno funcionamento deste princípio, porém, se não aplicado, não há Scrum, pois a equipe tem um papel fundamental na condução dos sprints e a sua atuação independente e responsável é o fator de sucesso que o projeto precisa.

a equipe deve ser capaz de se organizar e dividir o trabalho.

Não necessariamente o time todo deve ser Sênior, porém a auto- organização requer comprometimento e responsabilidade desde o primeiro dia de projeto.

Como no esporte, os membros da equipe são interdependentes e o Scrum Master fará todo o possível para manter a auto-organização, fator chave para o sucesso do projeto.

Times Scrum são auto-organizáveis e multifuncionais. Equipes auto- organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.

Times Scrum entregam produtos de forma iterativa e incremental, maximizando as entregas feitas em cada sprint.

Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

a Mitologia Ágil

Juntamente com o Scrum surgem diversas desconfianças, que na maioria das vezes se transformaram em mitologia em relação ao método ágil, isto é, mais do que preconceitos, são mitos gerados por profissionais que desconhecem o Scrum ou temem sua aplicação prática:

que desconhecem o Scrum ou temem sua aplicação prática: Todas as imagens, personagens e símbolos, são

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

12

Mindmaster Treinamentos

Entrar em Ação

Até aqui você aprendeu alguns conceitos importantes sobre o Scrum, especialmente sobre como ele foi estruturado e os seus respectivos pilares.

Trazendo você para o mundo real, utilize as questões abaixo, pensando em seu próprio projeto e faça um exercício prático da aplicação do Scrum. Não deixe de ponderar a respeito destas questões, que começarão a transformar seu ponto de vista para o método ágil.

Tendo aprendido até o momento os principais fundamentos do Scrum, quais são os principais desafios que você acha que encontrará para a transição para o método ágil, seja nos projetos em sua empresa ou mesmo para você?

Quais seriam as formas práticas de você promover transparência no seu projeto e quais são os seus receios?

De que forma a inspeção pode contribuir de modo prático com o seu projeto?

Qual o principal benefícios que você enxergaria em seu projeto ao promover o uso da adaptação?

Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste capítulo.

Entre com o seu login e senha e tenha acesso aos modelos de arquivo prontos para sua utilização.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

13

Mindmaster Treinamentos

Capítulo 2 O Time Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

14

Mindmaster Treinamentos

Capítulo 2: O Time Scrum

• Priorizar os itens do Backlog do Produto de acordo com a

visão do projeto, interesses da companhia e que com as metas e timing ideais para o projeto;

Agora aprenderemos um pouco mais, especialmente a respeito de um Time Scrum, seus papéis, funcionamento e como fazê-lo funcionar.

• Garantir que o Backlog do Produto seja plenamente compreensível e aceito por todos;

O Time Scrum é composto pelo Product Owner, a Equipe de

Desenvolvimento (Também descrito por diversos autores como DevTeam ou Scrum Team) e o Scrum Master .

A Teoria Sobre a Força

• Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário;

Aceitar ou rejeitar o trabalho entregue pelo ScrumTeam;

• •

É responsável por medir o retorno sobre o investimento do

projeto, entenda que o custo investido no projeto é uma parte da estratégia de rentabilização obtida através do lançamento deste projeto. Isso pode ser melhor compreendido por um produto

o Product owner

O Product Owner, ou dono do produto, é o

principal responsável pela entrega do projeto,

por maximizar o valor do produto, por garantir

o retorno sobre o investimento no projeto e

apoiar, em termos de escopo, o trabalho da

equipe de Desenvolvimento.

Diversas organizações podem tratar isso de modos distintos, mas algo que jamais muda em sua essência é a importância do PO para as tomadas de decisão no projeto, sendo que um Product Owner deve ter o poder necessário para conduzir o projeto de acordo com a visão e interesses da companhia e patrocinadores do projeto.

que será comercializado, por um projeto que trará economias ou que evitará desperdícios, produtos que podem trazer benefícios intangíveis ou de marketing e outras formas de benefícios que garantam o investimento no projeto.

É o senhor do Backlog, ninguém o altera sem o seu consentimento.

• Atua como ponto focal entre a equipe do projeto e os stakeholders (Os clientes) do projeto.

O Product Owner é a única pessoa responsável por gerenciar o Backlog

do Produto.

Por Exemplo:

• Expressar claramente os itens do Backlog do Produto, isto é, aquilo que se deseja que seja criado ou mantido;

O Desafio comum do Product Owner nas Organizações

O Product Owner é uma pessoa e não um comitê. Algumas empresas podem tender a delegar esta responsabilidade para um comitê, porém, para que isso funcione adequadamente, é necessário que um profissional seja o responsável por assumir tal papel e assim desempenhar os pilares do Scrum nesta função.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

15

Mindmaster Treinamentos

Embora o Product Owner possa representar o desejo de um comitê de demandas no Backlog do Produto, de acordo com a definição do Scrum aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Desta forma, esta é uma das funções de maior responsabilidade em um projeto Scrum.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto.

Ninguém deve ter permissão para as prioridades da Equipe de Desenvolvimento no projeto, e o Time de Desenvolvimento não tem

permissão para agir sobre o que outras pessoas disserem ou alterarem

o backlog por si mesmos.

o scrumTeam

O ScrumTeam consiste de

profissionais que realizam o trabalho de entregar uma versão funcional que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam tais componentes que incrementam o release do produto ao longo dos sprints. De uma maneira clara, ao longo de cada sprint a equipe de desenvolvimento ou ScrumTeam

é responsável por desenvolver partes do produtos que funcionam e

agregam valor ao projeto, oferecendo uma plena visão de progresso.

valor ao projeto, oferecendo uma plena visão de progresso. As Equipes de Desenvolvimento são estruturadas e

As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho, o que é conhecido como Auto-Organização.

A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as seguintes características:

• Eles são auto-organizadas. Ninguém (nem mesmo o Scrum

Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;

• Equipes de Desenvolvimento são multifuncionais, possuindo

todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

• O Scrum não reconhece títulos para os integrantes da

Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.

• Individualmente os integrantes da

Equipe de Desenvolvimento podem ter habilidades

especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo;

• Equipes de Desenvolvimento

não contém sub-equipes dedicadas a domínios específicos de conhecimento, como teste ou análise de negócios.

tais

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

16

Mindmaster Treinamentos

Tamanho do scrumTeam

A seguir vamos tratar de um dos temas polêmicos do Scrum. Muitas empresas tendem a desrespeitar anos de prática e pesquisa desvirtuando o que foi desenhado para este framework que é agil.

O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho.

Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Equipes de desenvolvimento menores podem

encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem.

o scrum Master

Master não são incluídos nesta contagem. o scrum Master O Scrum Master é responsável por garantir

O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum esteja em harmonia com a teoria, práticas e regras do Scrum. O Scrum Master é um líder servidor para o Time Scrum.

Ele é ponto focal entre o ScrumTeam e o restante dos stakeholders Um das suas principais contribuições é a ajuda na comunicação adequada com o ScrumTeam, evitando quaiser viés de comunicação ou pedidos informais de alteração do product backlog.

o

scrum Master trabalhando para o Product owner

O

Scrum Master serve o Product Owner de várias maneiras, incluindo:

Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;

Tornando a visão do projeto bem clara e objetiva, ainda

esclarecendo dúvidas a respeito dos itens do Backlog do Produto

para a Equipe de Desenvolvimento;

Ensinar o ScrumTeam a criar itens de Backlog do Produto de forma clara, no padrão de qualidade adequado e concisa;

Compreender a estratégia de planejamento do Produto no

ambiente empírico e tornar isso realidade junto ao ScrumTeam;

É o guardião dos processos Scrum e age como apoio direto do Product Owner.

Facilitar os eventos Scrum conforme exigidos ou necessários.

o

scrum Master trabalhando para o scrum Team

O

Scrum Master serve o ScrumTeam de várias maneiras, incluindo:

• Treinar a Equipe em auto-gerenciamento e disciplina de entrega;

• Ensinar e liderar a Equipe de Desenvolvimento na criação de

produtos de alto valor; Isso pode incluir a aplicação de técnicas de

qualidade, desenvolvimento e gerenciamento do tempo

• Remover impedimentos para o progresso do ScrumTeam;

• Facilitar os eventos Scrum exigidos ou necessários (Reuniões);

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

17

Mindmaster Treinamentos

• Treinar a Equipe de Desenvolvimento em ambientes

organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

• Transmitir a visão da estratégia de desenvolvimento do produto e as respectivas expectativas do Product Owner

o scrum Master trabalhando para a organização

O Scrum Master serve a Organização de várias maneiras, incluindo:

• Responsável pela transição para o modelo ágil;

• Liderando e treinando a organização na adoção do Scrum;

• Planejando implementações Scrum dentro da organização;

• Ajudando funcionários e partes interessadas a compreender e

tornar aplicável o Scrum e o desenvolvimento de produto empírico;

• Causando mudanças que aumentam a produtividade do Time Scrum; e,

• Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações.

Entrar em Ação

Agora que você assimilou os papéis e responsabilidades do Scrum, qual seria a maior dificuldade de se estabelecer um time Scrum em sua equipe?

Imagine que você é o Scrum Master do seu time. Pelo o que aprendeu até agora, qual seria sua principal contribuição para o sucesso do Scrum Team?

Dado que você já domina alguns fundamentos do Scrum, qual seria a melhor estratégia para você montar uma equipe ágil?

Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste capítulo.

Entre com o seu login e senha e tenha acesso aos modelos de arquivo prontos para sua utilização.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

18

Mindmaster Treinamentos

Capítulo 3 Eventos Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

19

Mindmaster Treinamentos

Capítulo 3: Eventos Scrum

O Scrum se utiliza de uma série de eventos ou cerimônias a de se criar um padrão de comunicação e também colocar os seus pilares em ação, minimizando assim a necessidade de reuniões adicionais ou excessivas.

O Scrum usa eventos time-boxed, isto é, todo evento tem uma duração máxima. Isto garante que uma quantidade adequada de tempo seja gasta no planejamento evitando desperdício de tempo e garantindo maior agilidade.

Os Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

As Sprints são compostas por uma reunião de planejamento da Sprint (Sprint Planning), reuniões diárias (DailyScrums), o trabalho de desenvolvimento, uma revisão da Sprint (Sprint Review) e a restrospectiva da Sprint.

Durante a Sprint:

• Não são feitas mudanças que podem afetar o objetivo da Sprint;

Além da Sprint, que é um evento base para as demais cerimônias, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar. Se não aplicar tudo o que o Scrum prescreve em seu framework, em termos de eventos, a produtividade e agilidade estarão ameaçadas.

• A composição do ScrumTeam permanece constante;

• As metas de qualidade não diminuem; e,

• O escopo pode ser clarificado e renegociado entre o Product

Owner e a Equipe de Desenvolvimento quanto mais for aprendido.

e a Equipe de Desenvolvimento quanto mais for aprendido. Cada Sprint pode ser considerada um projeto

Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição muito clara do que é deve ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

A Teoria Sobre a Força

sprint

Este é o coração do Scrum. É a Sprint, um time-box de normalmente um mês ou menos, durante o qual um produto potencialmente utilizável é criado.

De acordo com o Scrum Guide, as Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer, isso é a essência da entrega contínua e com qualidade do Scrum.

Durante a Sprint fica claro que a parte do produto ou incremento deve estar “Pronto”, significando que seguiu os critérios mínimos de qualidade para aquela entrega incremental e priorizada .

Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção a meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

20

Mindmaster Treinamentos

Cancelamento da sprint

Reunião de Planejamento da sprint

Uma Sprint pode ser cancelada antes do time-box da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do ScrumTeam ou do Scrum Master.

O trabalho a ser realizado na Sprint é planejado na reunião de

planejamento da Sprint (Sprint Planning). Este plano é criado com o trabalho colaborativo de todo o Scrum Team.

A reunião de planejamento da Sprint é uma time-box de oito horas para

uma Sprint de um mês de duração. Para Sprints menores, este evento deve ser proporcionalmente menor. Por exemplo, uma Sprint de duas semanas terá uma reunião de planejamento de Sprint de quatro horas.

A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto.

Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.

A reunião de planejamento da Sprint consiste em duas partes, cada uma

sendo uma time-box de metade do tempo de duração da reunião de planejamento da Sprint. As duas partes da reunião de planejamento da Sprint respondem as seguintes questões, respectivamente:

Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado

e “Pronto” é revisado. Se

uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são re- estimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente re-estimado.

deprecia rapidamente e deve ser frequentemente re-estimado. • O que será entregue como resultado do incremento

• O que será entregue como resultado do incremento da próxima Sprint?

• Como o trabalho necessário para entregar o incremento será realizado?

Parte Um: O que será Pronto nesta Sprint?

Nesta parte, a Equipe de Desenvolvimento trabalha para definir as funcionalidades que serão desenvolvidas durante a Sprint. O Product Owner apresenta os itens de Backlog do Produto ordenados para

a Equipe de Desenvolvimento e todo o Time Scrum colabora com o entendimento do trabalho da Sprint.

O cancelamentos de Sprints consome recursos, já que todos tem que se

reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para

o ScrumTeam, e são muito incomuns.

Os artefatos de entrada da reunião de planejamento da Sprint são: O Backlog do Produto ou Product Backlog, o mais recente incremento do

produto, a capacidade projetada da Equipe de Desenvolvimento durante

a Sprint e o desempenho anterior da Equipe de Desenvolvimento ou o respectivo índice de velocidade.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

21

Mindmaster Treinamentos

O

número de itens selecionados do Backlog do Produto para a Sprint é

O

Product Owner pode estar presente durante a segunda parte da

o

único trabalho do ScrumTeam nesta reunião. Somente o ScrumTeam

reunião de planejamento da Sprint, para clarificar os itens do Backlog

pode avaliar o que pode ser completado ao longo da próxima Sprint.

do Produto selecionados e para ajudar nas decisões conflituosas ou eventuais dúvidas.

Após o ScrumTeam estimar os itens de Backlog do Produto que irá entregar na

Sprint, o Time Scrum determina a meta da Sprint.

A meta da Sprint é um objetivo que será conhecido dentro da Sprint

através da implementação do Backlog do Produto, fornecendo a informação do que será o output ou produto que será produzido após a

conclusão do sprint.

Parte Dois: Como o trabalho escolhido será Pronto ?

Tendo selecionado o trabalho da Sprint, a Equipe de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint.

O ScrumTeam frequentemente inicia o desenho do sistema e do

trabalho necessário para converter o Backlog do Produto em um incremento utilizável do produto. O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante a reunião de planejamento da Sprint pelo ScrumTeam prever

o que esta acredita que poderá fazer durante a próxima Sprint. Com o

trabalho planejado pelo ScrumTeam para os primeiros dias da Sprint, este é decomposto em unidades de um dia de duração ou menos até

o final desta reunião. O ScrumTeam se auto-organiza para realizar

por todo o trabalho do Backlog da Sprint, tanto durante a reunião de planejamento da Sprint quanto no que for necessário durante a Sprint.

Se o ScrumTeam determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner. O Scrum Master também pode convidar outras pessoas para participar desta reunião de forma a fornecer opinião técnica ou de domínios específicos.

No final da reunião de planejamento da Sprint, o Scrum Team deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto- organizada para completar o objetivo da Sprint e criar um incremento previsto.

objetivo ou meta da sprint

O

alguma flexibilidade em relação as funcionalidades a serem implementadas dentro da Sprint.

objetivo da Sprint dá a Equipe de Desenvolvimento

Sprint. objetivo da Sprint dá a Equipe de Desenvolvimento Conforme o ScrumTeam trabalha, ela mantém o

Conforme o ScrumTeam trabalha, ela mantém

o

satisfazer o objetivo da Sprint, ela implementa

a funcionalidade e a tecnologia.

objetivo em mente, e no caminho de buscar

Caso o produto entregue seja diferente do esperado pelo Product Onwer, então os membros do ScrumTeam colaboram para negociar o escopo do Backlog da Sprint dentro da Sprint.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

22

Mindmaster Treinamentos

Reunião Diária ou Daily scrum

A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para

que o ScrumTeam possa sincronizar as atividades e criar um plano para as próximas 24 horas.

Esta reunião é facilitada pelo Scrum Master e é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária.

A Reunião Diária é mantida no mesmo horário e local todo dia para

reduzir a complexidade. Durante a reunião cada integrante da Equipe de Desenvolvimento esclarece:

• O que foi completado desde a última reunião?

• O que será feito até a próxima reunião?

• Quais os impedimentos que estão no caminho?

O ScrumTeam usa a Reunião Diária para avaliar o progresso em direção

ao objetivo da Sprint e para avaliar se o progresso tende para completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade da Equipe de Desenvolvimento atingir o objetivo da Sprint

O ScrumTeam pode se encontrar imediatamente após a Reunião Diária,

para re-planejar o restante do trabalho da Sprint.

Todos os dias, a Equipe de Desenvolvimento deve estar apta a esclarecer para o Product Owner e para o Scrum Master como pretendem trabalhar em conjunto, como um time auto-organizado, para completar o objetivo e criar um incremento previsto desejado no restante da Sprint.

O Scrum Master assegura que o ScrumTeam tenha a reunião, mas

a Equipe de Desenvolvimento é responsável por conduzir a Reunião

Diária. O Scrum Master ensina a Equipe de Desenvolvimento a manter

a Reunião Diária dentro da time-box de 15 minutos. Esta parte é uma das mais importantes a fim de se manter a ordem e obter ganhos de produtividade.

O Scrum Master reforça a regra de que somente os integrantes do ScrumTeam participem da Reunião Diária. A Reunião Diária não é uma reunião de status, é voltada para as pessoas que transformam os itens do Backlog do Produto em um incremento.

Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam

e promovem rápidas tomadas de decisão, e melhoram o nível de

conhecimento da Equipe de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.

A Utilização de um quadro Kanban na reunião também pode ser aplicável.

Revisão da sprint (sprint Review)

A Revisão da Sprint é executada no final da Sprint para inspecionar o

incremento e adaptar o Backlog do Produto se necessário.

Durante a reunião de Revisão da Sprint o ScrumTeam e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que precisam ser prontas.

Esta é uma reunião informal, e a apresentação do incremento destina-se

a motivar e obter comentários e promover a colaboração.

Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint de um mês. Proporcionalmente um tempo menor é alocado para Sprints menores. Por exemplo, uma Sprint de duas semanas tem Reuniões de Revisão de duas horas.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

23

Mindmaster Treinamentos

a Reunião de Revisão inclui os seguintes elementos:

• O Product Owner identifica o que foi “Pronto” e o que não foi “Pronto”;

• A Equipe de Desenvolvimento discute o que foi bem durante a

Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;

• A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as

questões sobre o incremento;

• O Product Owner discute o Backlog do Produto tal como está.

Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data; e,

• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de Revisão da

Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint.

para a Reunião de Planejamento da próxima Sprint. O resultado da Reunião de Revisão da Sprint

O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.

Retrospectiva da sprint

A Retrospectiva da Sprint é uma oportunidade para o ScrumTeam

inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da

reunião de planejamento da próxima Sprint. Esta é uma reunião time- boxed de três horas para uma Sprint de um mês. Proporcionalmente um tempo menor é alocado para Sprints menores.

O propósito da Retrospectiva da Sprint é:

• Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas;

• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,

• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo

do framework do Scrum, o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para a próxima Sprint. Durante

cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar

a qualidade do produto, adaptando a definição de “Pronto” quando apropriado.

Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento.

Em resumo o Sprint Review foca na revisão do produto e a Retrospectiva na revisão do processo.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

24

Mindmaster Treinamentos

Como Usar a Força

Como planejar um sprint

O planejamento de sprint é uma reunião muito importante, e talvez seja

um dos eventos mais importantes no Scrum.

O propósito da reunião de planejamento do sprint é dar à equipe

informação suficiente para rodarem o projeto por algumas semanas, e para dar ao product owner confiança e dados suficientes para avaliar o desempenho do Sprint.

De modo prático temos o seguinte na agenda de reunião de Sprint Planning:

Agenda da Reunião de Sprint Planning

Participantes:

Data, Hora e Local:

Listar o Objetivo do sprint.

Uma lista de membros da equipe (e seus níveis de comprometimento).

Um sprint backlog (= uma lista de estórias inclusas no sprint).

Uma data definida para a conclusão do sprint.

Data e local definidos para o Daily Scrum.

agenda JeDi para a reunião de planejamento do sprint

Para ficar ainda mais claro, segue aqui um exemplo real de uma reunião de planejamento de Sprint, deste modo, você poderá gerenciar o tempo adequado para sua reunião.

Reunião de planejamento do sprint: 13:00 – 17:00 (10 minutos de intervalo a cada hora)

13:00 – 17:00 (10 minutos de intervalo a cada hora) Esta agenda é apenas um exemplo

Esta agenda é apenas um exemplo e não precisa ser executada à risca.

O Scrum Master pode aumentar ou diminuir os tempos conforme necessário.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

25

Mindmaster Treinamentos

Entrar em Ação

Se você chegou até aqui é porque já aprendeu a respeito dos eventos do Scrum. Sendo assim, descreva abaixo como você organizaria o seu primeiro Sprint Planning?

Durante o Sprint Planning o que você faria para garantir um bom planejamento do sprint eliminando quaisquer viés de comunicação?

Qual o real objetivo do Sprint Planning?

Quem são os responsáveis pela estimativa de cada item do backlog?

Qual a função do Sprint Review?

Porque é preciso realizar a Retrospectiva do Sprint ?

Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste capítulo.

Entre com o seu login e senha e tenha acesso aos modelos de arquivo prontos para sua utilização.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

26

Mindmaster Treinamentos

Capítulo 4 Artefatos do Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

27

Mindmaster Treinamentos

Capítulo 4: Artefatos do Scrum

Como um (Função), eu gostaria de (Funcionalidade) para que (Benefício)
Como um (Função), eu
gostaria de (Funcionalidade)
para que (Benefício)

Os artefatos do Scrum são excelentes ferramentas de apoio para a prática dos pilares do Scrum, bem como, apoiar as tomadas de decisões do Scrum Master e Product Owner e prover informações significativas para o ScrumTeam.

A Teoria Sobre a Força

Backlog do Produto

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.

Uma definição teórica a respeito do Product Backlog

A rigor, um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto

quanto o produto e o ambiente no qual ele será utilizado evoluem.

O Backlog do Produto é dinâmico; mudando constantemente para

identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir.

O Backlog do Produto lista todas as características, funções, requisitos,

melhorias e correções (Todos os Bugs) que formam as mudanças que

devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos da descrição, ordem e estimativa (Que é única e exclusivamente provida pelo ScrumTeam).

O Backlog do Produto é, geralmente, ordenado por valor, risco, prioridade e necessidade.

Os itens no topo da lista ordenada do Backlog do Produto determinam as atividades de desenvolvimento mais imediatas. Quanto maior a ordem (topo da lista) de um item, mais o item do Backlog do Produto deve ser considerado, e mais consenso existe em relação a ele e ao seu valor.

Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas com base na maior clareza e maior detalhe; Quanto menor a ordem na lista, menor são os detalhes. Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima Sprint são mais refinados, tendo sido decompostos de modo que todos os itens possam ser “Prontos” dentro do time-box da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pela Equipe de Desenvolvimento dentro da Sprint são considerados como “disponíveis” ou “executáveis” para seleção na Reunião de Planejamento da Sprint.

para seleção na Reunião de Planejamento da Sprint. Requisitos nunca param de mudar, então o Backlog

Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto.

Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. O Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto para o grupo de itens é então aplicado.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

28

Mindmaster Treinamentos

A constante preparação e o cuidado dado ao Backlog do Produto é a

ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo em que o Product Owner e o ScrumTeam colaboram nos detalhes dos itens do Backlog do Produto. Durante a preparação do Backlog do Produto, os itens são analisados e revisados. Contudo, eles podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.

Preparar o Backlog do Produto é uma atividade de tempo parcial, durante a Sprint, entre o Product Owner e o ScrumTeam.

Geralmente o ScrumTeam tem o domínio do conhecimento para realizar a preparação por si próprios. Como e quando a preparação é considerada pronta é uma decisão do Time Scrum. Esta preparação usualmente não consome mais de 10% da capacidade do ScrumTeam.

O ScrumTeam é responsável por todas as estimativas. O Product Owner

deve influenciar o Time, ajudando no entendimento e eventualmente em esclarecimentos a respeito de Itens de Backlog.

Monitoração do Progresso a Caminho do objetivo

Em projetos ágeis a necessidade de constante inspeção e monitoração de desempenho é essencial.

O Product Owner acompanha

o total do trabalho realizado

especialmente a cada Reunião de Revisão da Sprint. O Product Owner compara este valor com

o trabalho restante na Reunião

de Revisão da Sprint anterior, para avaliar o progresso em relação ao que se havia previsto.

avaliar o progresso em relação ao que se havia previsto. Esta informação deve ser transparente para

Esta informação deve ser transparente para todas as partes interessadas.

Várias artefatos podem ser utilizados, porém os de maior eficácia são os gráficos burndown e burnup que demonstram claramente o status do progresso do projeto.

Backlog da sprint

O Backlog da Sprint é um conjunto de itens do Backlog do Produto

selecionados para a Sprint, visando atingir o objetivo da Sprint. O Backlog da Sprint é a previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do trabalho necessário para entregar a funcionalidade.

O Backlog da Sprint define qual trabalho o ScrumTeam realizará para converter os itens do Backlog do Produto em um incremento “Pronto” do Produto ao final do Sprint. O Backlog do Produto torna visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint.

O Backlog da Sprint é um plano com

detalhes suficientes que as mudanças em progresso sejam entendidas durante a Reunião Diária. A Equipe de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o ScrumTeam trabalha segundo o plano e aprende mais sobre o

trabalho necessário para alcançar o objetivo da Sprint.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

29

Mindmaster Treinamentos

Sempre que um novo trabalho é necessário, o ScrumTeam adiciona este item ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o ScrumTeam pode alterar o Backlog da Sprint durante a Sprint, contudo eles não estão autorizados a retirar nenhum item priorizado pelo Product Owner.

O Backlog da Sprint é altamente visível, uma imagem em tempo real do

trabalho que a Equipe de Desenvolvimento planeja completar durante a

Sprint, e pertence exclusivamente à Equipe de Desenvolvimento.

Monitorando o Progresso da sprint

O ScrumTeam monitora o total do trabalho restante pelo menos a

cada Reunião Diária. A Equipe de Desenvolvimento acompanha estes resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint juntamente com o Scrum Master.

O Scrum não considera o tempo gasto trabalhando nos itens do Backlog da Sprint. O trabalho restante e a data são as únicas variáveis que interessam, sendo que a data do Sprint é um compromisso do ScrumTeam que deve ser perseguido sob toda e qualquer circunstância.

que deve ser perseguido sob toda e qualquer circunstância. o Kanban: uma excelente forma de se

o Kanban: uma excelente forma de se monitorar o andamento da sprint

Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”. É um conceito relacionado com a utilização de cartões

(post-it e outros) para indicar o andamento dos fluxos de produção em empresas de fabricação em série. Nesses cartões são colocadas indicações sobre uma determinada tarefa, por exemplo, “para executar”, “em andamento” ou “finalizado”.

A utilização de um sistema Kanban permite um controle detalhado de

produção com informações sobre quando, quanto e o que produzir. O método Kanban foi inicialmente aplicado em empresas japonesas de fabricação em série e está estreitamente ligado ao conceito de “just in time”. A empresa japonesa de automóveis Toyota foi a responsável pela introdução desse método devido a necessidade de manter um eficaz funcionamento do sistema de produção em série.

a existência de uma parede cheia de postís é uma das características mais marcantes dos projetos ágeis

O Quadro Scrum pode ser de grande valia para além de controlar o fluxo

de trabalho dentro de um Sprint, também fornecer transparência nas reuniões diárias e também eliminar quaisquer tipos de ansiedade em relação ao andamento do projeto.

Você poderá baixar um modelo em powerpoint para pronta utilização na seção de Downloads.

incremento

O incremento é a soma de todos os itens do Backlog do Produto completados ao final das Sprints. Ao final da Sprint um novo incremento

deve estar “Pronto”, o que significa que deve estar na condição utilizável

e atender a definição de “Pronto” do Time Scrum. Este deve estar na

condição utilizável independentemente do Product Owner decidir por

liberá-lo realmente ou não para produção. Em resumo é o produto entregue a cada Sprint até se ter a versão final do produto.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

30

Mindmaster Treinamentos

Definição de “Pronto” ou Definition of Done

Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa.

Embora, isso varie significativamente de um extremo ao outro para cada ScrumTeam, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.

Em projetos Scrum um item que é considerado Pronto deve estar realmente pronto.

A

definição de pronto é ponto chave para garantir qualidade do produto

e

um dos itens necessários para garantir um processo de entrega à

expectativa do Product Owner.

Neste ponto é onde se demonstra a necessidade de auto-gerenciamento e maturidade por parte dos times Scrum, uma vez que um item do Product Backlog jamais será considerado concluído se não estiver realmente “Pronto”.

A equipe de Desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, assim o Product Owner pode escolher por liberá-lo imediatamente. Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.

Com um ScrumTeam maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade.

Para ser mais específico segue um exemplo simples de uma Definition of Done.

1. Código concluído ( todos os ‘to dos’ no código devem

estar concluídos)

2. Código comentado, checked e rodando em linha

contra a versão mais atualizada

3. Revisado em Pares (ou produzido em programação

em partes) de acordo com os padrões de requisitos e desenvolvimentos acordados.

4. Builds sem nenhum erro

5. Cobertura de Testes superior a 90% no código com

testes escritos e passando.

6. Código publicado em um ambiente de testes e com

resultados de testes com 90% de sucesso ou superior.

7. Testes de Aceitação concluídos com sucesso e aceitos

de acordo com os requisites do produto.

8. Qualquer Quebra de Build, Mudanças de Configuração

ou na Documentação devem ser claramente comunicadas.

9. Documentação relevante ou Diagramas produzidos

devem estar atualizados.

10. Horas restantes registradas para a tarefa devem estar

zeradas e a tarefa fechada.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

31

Mindmaster Treinamentos

Como Usar a Força

Como gerar um Product Backlog como um Jedi

O product backlog é o ponto nevrálgico do Scrum. É uma lista de requisitos, estórias ou desejos. O melhor jeito de fazer um product Backlog é ter sempre em mente a visão do cliente em relação ao produto.

O Product Backlog é uma lista de items, que também são conhecidos como estórias.

Geralmente estas estórias incluem os seguintes campos:

iD – Uma identificação única, um número sequencia ou código. Cada estória deve ser única e facilmente identificável.

nome – Um nome ou descrição curta para a estória. Por exemplo, “Ver o histórico de acessos”. Claro o suficiente para que o ScrumTeam e o Product owner entendam sobre o item mencionado e claro o bastante para distingui-la das demais estórias. Normalmente recomendamos o uso de de 2 até 10 palavras.

grau de importância – Isso é opcional, porém pode dar um certo peso para a estória. Recomendo utilizar um escala clara, uma pontuação numérica ou escala de menos importante até muito importante. Toda o grau de importância deve ser definido pelo product owner.

estimativa inicial – As estimativas iniciais são providas pelo ScrumTeam, que proveem quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/ dias” ideal. Esta “métrica inicial” é realizada de modo subjetivo mesmo, perguntando para o time que em uma situação ideal, sem distúrbios, qual seria a o número ideal de pessoas para atuar e concluir esta estória e quanto tempo. Questiona-se ainda, baseado no escopo desta estória, após quantos dias vocês apresentarão uma implementação pronta,

demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala, sem interrupções, levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória.

O importante não é ter estimativas absolutamente precisas (por exemplo, dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim cumprir o que foi combinado, afinal o Cavaleiro Jedi deve sempre cumprir com sua palavra.

notas – Você pode informar quaisquer outras informações, esclarecimentos, referências a outras fontes de informação que possam contribuir com algo, contanto que sejam breves.

exemplo de um Product Backlog – Seguem abaixo apenas alguns exemplos para demonstrar na prática os itens descritos até aqui.

PRODUCT BACKLOG (exemplo)

os itens descritos até aqui. PRODUCT BACKLOG (exemplo) Todas as imagens, personagens e símbolos, são marcas

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

32

Mindmaster Treinamentos

o acesso ao Product Backlog

Você pode utilizar várias ferramentas, ou ainda usar uma planilha excel compartilhada na rede e até uma planilha no Google Docs por exemplo.

O Importante é que o aceso seja compartilhado com todo o ScrumTeam

e priorizado devidamente pelo ProductOwner.

Entrar em Ação

Construindo seu Product Backlog

Você pode usar os modelos product backlog que estão na área de downloads ou mesmo escrever o seu Product Backlog à mão. Se preferir fazer à mão apenas para iniciar, você vai precisar de um monte de cartões de anotação e algumas canetas.

De qualquer modo, seria muito bom ter algumas pessoas que puderem

te

ajudar neste exercício. A Idéia é você poder contar com pessoas para

te

ajudar a escrever o escopo do produto, especialmente o cliente do seu

projeto pode ajudar bastante.

As regras do exercício são simples, você DEVE escolher o seu projeto, pode utilizar o projeto do exercício anterior ou mesmo utilizar outro projeto, fica a seu critério, porém recomendo seguir os seguintes passos:

Uma estória por cartão ou uma idéia em cada linha da planilha – Um item para cada idéia que deve constar no product backlog

O formato para as suas estórias devem ser escritas da seguinte forma:

• Insira um Título (Este título pode ser repetido para cada estória, de modo que você pode agrupá-lo depois)

• COMO UM (descrever o papel do usuário),

• EU GOSTARIA DE (ter algo específico no produto do projeto),

PARA QUE (Justifique o porque do item específico no produto).

(Justifique o porque do item específico no produto). • Segue aqui um exemplo de estória para

Segue aqui um exemplo de estória para você se basear:

Como um < Cliente da companhia área > eu gostaria de < Fazer check in no site da empresa > para que < fique menos tempo na fila>

É isso aí, simples assim. As estórias podem ser tão complexas ou simples como você preferir. Elas podem estar relacionadas ou não , detalhadas ou simples. Você escolhe a melhor forma de fazer.

Experimente-o com um projeto que você está prestes a começar. Experimente-o com um projeto pessoal que você está adiando porque está com medo de planejar a entregar. O Ideal seria fazer algo que poderemos usar ao longo do curso.

Você vai notar de imediato que o escopo do projeto torna-se mais claro, que ao invés de se focar em tarefas e encadeamentos de atividades, o foco é total no usuário, no que você precisa fazer e naquilo que trará maior benefício.

Quando você terminar de escrever tudo , leia cada estória em voz alta para todos e tente eliminar todas as estórias duplicadas. As discussões com sua turma serão muito legais. Se for fazer o exercício sozinho, tente vislumbrar o que você estará entregando ao final do projeto.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

33

Mindmaster Treinamentos

Dinâmica de grupo: uma boa opção para implantação do scrum em sua equipe de projeto.

Assista o vídeo o abaixo e desenvolva esta dinâmica com o time Scrum de seu projeto e aprendam juntos de maneira bastante divertida.

seu projeto e aprendam juntos de maneira bastante divertida. Qual o ponto mais importante na utilização

Qual o ponto mais importante na utilização de product Backlog

O que você acha que pode utilizar para monitorar o progresso do projeto adequadamente

Pensando em seu projeto, apresente uma definição de pronto que esteja de acordo com as expectativas do seu Product Owner.

Preencha o Product Backlog e visualize o produto potencialmente entregável ao final da Sprint

Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste capítulo.

Entre com o seu login e senha e tenha acesso aos modelos de arquivo prontos para sua utilização.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

34

Mindmaster Treinamentos

Capítulo 5 Teste seu Conhecimento

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

35

Mindmaster Treinamentos

Capítulo 5: Teste seu Conhecimento

Neste capítulo serão apresentadas 30 questões para você testar o seu conhecimento ágil com as respostas comentadas ao final do capítulo.

Q1. Imagine uma empresa de desenvolvimento de software que deseja adotar o método ágil. Será necessário discutir o método Scrum com os clientes e receber sua aprovação antes de antes de usar nos projetos?

A.

Sim, pois isso muda a forma de entregar os projetos.

B.

Sim, pois isso aumenta o retorno sobre o investimento.

C.

Não, pois é uma forma interna de gerenciar o projeto.

D.

Não, pois o uso do Scrum é sempre uma forma aceitável de

trabalho.

Q2. Uma empresa de desenvolvimento de software está pensando em colocar o Diretor de Marketing como Product Owner de um projeto. Porém ele é novo na empresa e não tem conhecimento técnico. Deve ser escolhida outra pessoa para a função?

A. Sim, pois precisamos de um especialista que possa participar

ativamente com a equipe técnica no trabalho e seja capaz de se comunicar com o cliente.

B. Sim, pois precisamos de um especialista que possa participar

ativamente com a equipe técnica no trabalho e que possa fazer parte do time de desenvolvimento.

C. Não, pois ele não precisa ser um especialista já que vai ter outros

especialistas na equipe.

D. Não, pois ele não precisa ser um especialista desde que

conheça do negócio.

Q3. Nós estamos na dúvida entre escolher a Maria ou o Antônio como Scrum Master para o nosso projeto. Maria conhece bastante sobre Scrum, mas ela é muito nova e não possui muita experiência no mercado de trabalho. Antônio não conhece Scrum, mas tem vários anos de experiência como Gerente de Projetos. Qual a melhor escolha?

A. Maria, pois ela conhece Scrum

e não precisa gerenciar o projeto.

B. Maria, pois ela conhece Scrum

e irá aprender gerenciamento de projeto em breve.

C. Antônio, pois ele conhece

gerenciamento de projetos e não precisa saber Scrum.

gerenciamento de projetos e não precisa saber Scrum. D. Antônio, pois ele conhece gerenciamento de projetos

D. Antônio, pois ele conhece gerenciamento de projetos e irá

aprender Scrum em breve.

Q4. Considerando que temos um número limitado de recursos, ao relacionar a equipe que atuará no projeto Scrum, qual a melhor escolha entra as seguintes opções: 1) alocar 8 profissionais part-time (algumas horas por dia) que também atuem em outros projetos da empresa. 2). Rearranjar a estrutura da empresa para alocar 4 profissionais full-time (tempo integral) e contratar uma nova pessoa para o time.

A.

Primeira, pois o custo é menor.

B.

Primeira, pois cria um ambiente mais colaborativo.

C.

Segunda, pois aumenta o número de profissionais da

empresa.

D. Segunda, pois cria um time mais focado.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

36

Mindmaster Treinamentos

Q5. Em nosso projeto de desenvolvimento de software, ninguém no time sabe como testar profissionalmente, e nós precisamos disso como requisito para o sucesso do projeto. O que devemos fazer?

A. Adicionamos mais um membro ao time, com especialização

ou plena expleriência em testes de software.

B. Solicitamos ao time de testes, que não faz parte do

ScrumTeam, que cuide disso.

C. Terceirizamos os testes com uma outra empresa

D. Está muito cedo para pensar emu ma tarefa que vai ser feita

só final do projeto

Q6. Quem deve estimar o volume de trabalho de cada item do backlog?

A. O Product Owner, porque ele tem total responsabilidade pelo

Product Backlog e conhece os itens mais que todo mundo

B. O Scrum Master, porque é

dele a responsabilidade de planejar

tudo

C.

O Scrum Team, porque eles

que deverão realizar o trabalho e eles conhecem a melhor forma de entregar cada um dos itens de acordo com o que foi requirido.

D. Todos os papés acima são

responsáveis por estimar o trabalho

de um modo democrático.

por estimar o trabalho de um modo democrático. Q7. Estamos em um Sprint de requisitos e

Q7. Estamos em um Sprint de requisitos e uma semana já passaou e menos da metade do product backlog foi concluída. O Product Owner acredita que o melhor a se fazer é começar logo o primeiro Sprint (Desenvolvimento) com a informação que temos à mão, ao invés de ficar esperando concluir para que todos os requisitos já estejam coletados. Como Jedi Scrum Master você deve orientar o time. O que eles devem fazer?

A.

Sim, é um bom momento para iniciar o primeiro Sprint

B.

Não, nós devemos esperar para completer todo o Product

Backlog antes de dar início aos Sprints

Q8. Na questão anterior, quem deve ajudar o Scrum Master a tomar a decisão correta?

A.

Product Owner

B.

Scrum Master

C.

Scrum Team

D.

Não há um papel específico para isso, todos devem

compartilhar a decisão.

Q9. Estamos prestes a iniciar o primeiro Sprint. Qual deve ser o primeiro passo?

A.

Finalizar as estimativas dos itens do Product Backlog

B.

Sprint Initiation

C.

Sprint Startup

D.

Sprint Planning

E.

Daily Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

37

Mindmaster Treinamentos

Q10. Estamos prestes a formar o Sprint Backlog. O ScrumTeam prefere escolher 100 storypoints para o primeiro Sprint, mas o Product Owner acredita que eles devem selecioanr pelo menos 150 pontos. Como Jedi Scrum Master comandante da unidade o que você recomenda eles a fazer?

A.

Todos devem discutir e chegar a um consenso

B.

Tem que fazer os 100 storypoints

C.

Tem que fazer os 150 storypoints

D.

O Scrum Master deve decidir

Q11. Vamos decidir a duração dos Sprints. Algumas pessoas preferem duas semanas e outros acreditam que o ideal seriam 3 semanas. Todos esperam uma decisão do Jedi Scrum Master. O que é o certo a fazer?

A. Começar com os dois

e mudar posteriormente se

necessário.

B. Começar o primeiro Sprint

e então ver quanto tempo sera necesário

C. O Scrum Master tem a

palavra final neste assunto

D. O Product Owner tem a

palavra final neste assunto

assunto D. O Product Owner tem a palavra final neste assunto Q12. O Product detectou algumas

Q12. O Product detectou algumas expectativas novas junto ao cliente. Quando será uma boa hora para inserir isso no Product Backlog?

A. Assim que for detectado

B. Depois do Sprint

C. Antes do próximo Sprint

D. No próximo Sprint Planning

Q13. Alguns membros do Scrum Team não estão seguros a respeito do entendimento de alguns itens do Sprint Backlog items. O que o Jedi Scrum Master deve recomendar?

A. Eles devem tentar entender por si mesmos

B. Eles devem entrar em contato com o cliente e pedir maiores

informações

C. Eles devem pedir ao Scrum Master que lhes dê maiores

informações

D. Eles devem perguntar ao Product Owner

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

38

Mindmaster Treinamentos

Q14. O ScrumTeam percebe que o volume de trabalho para um dos itens do Sprint Backlog está estimado incorretamente, e o volume atual de trabalho totaliza 130 horas ao invés das 100 horas projetadas inicialmente. Eles alertar a seu Scrum Master e pedem por ajuda. Como um Jedi Scrum Master o que você vai orientá-los a fazer?

A. Eles devem devolver alguns itens ao Product Backlog a fim de

manter o Sprint Backlog com o volume projetado de 100 horas.

B. Eles devem pedir mais tempo ao Scrum Master para concluir

este Sprint

Q16. Todos estão desapontados com o pequeno número de itens completados do primeiro Sprint. The CEO Imperador solicita ao Scrum Master uma explicação, especialmente sobre quem é o responsável por isto. O que o nosso herói, o Jedi Scrum Master, deve responder a respeito de quem é o responsável?

A.

Os 3 papéis são responsáveis.

B.

O ScrumTeam é responsável

C.

Dois membros do ScrumTeam que estavam doentes durante

o Sprint são os responsáveis.

C.

Eles devem pedir ao Product Owner para decidir sobre isso

 

D.

O Product Owner detém a responsabilidade maior

D.

Eles não devem fazer nada agora

Q15. O ScrumTeam percebe que se focarem nos ultimo 3 itens que estão quase finalizados e estenderem o Sprint por apenas 2 dias, eles estarão aptos a completar ambos. O que o Jedi Scrum Master recomenda a ser feito?

A. Expandir a duração do Sprint e comepletar os 3 itens

B. Expandir a duração do Sprint, se o cliente aceitar

C. Expandir a duração do Sprint, se ambos, Scrum Master e

Product Owner, aceitarem.

D. Não expandir a duração do Sprint

Q17. Chegou o momento do Sprint Review. O ScrumTeam acredita que eles devem apresentar apenas o único item concluído, mas o Product Owner entende que eles devem também demonstrar os 3 itens que estão quase concluídos. Qum está certo?

A. O ScrumTeam está certo

B. O Product Owner está certo,

uma vez que produtos que estão quse concluídos podem ser

apresentados.

C. O Product Owner está certo,

sendo assim, o Scrum Team deverá mencionar durante o Sprint Review que estes 3 itens não estão completos ainda, mas estarão no

futuro.

3 itens não estão completos ainda, mas estarão no futuro. Todas as imagens, personagens e símbolos,

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

39

Mindmaster Treinamentos

Q18. O novo representante do cliente (aquele que serve de interface com o Product Owner) solicita ao Chefe do seu Departamento uma reunião urgente com o Gerente do Projeto (O seu projeto). Quem é o Gerente do Projeto?

A. Product Owner

B. Scrum Master

C. ScrumTeam

D. Nenhum

Q19. De acordo com a questão anterior, quem deve participar da reunião com o representante do cliente?

A. Product Owner

B. Scrum Master

C. ScrumTeam

D. Product Owner e o

Scrum Master

E. Todos

C. ScrumTeam D. Product Owner e o Scrum Master E. Todos Q20. O novo representante do

Q20. O novo representante do cliente pede ao Chefe do seu Departamente que introduza seu próprio Analista de Testes e agende uma reunião com eles para discutir alguns tópicos importantes. O que deve ser feito? Quem deve comparecer a esta reunião?

A. Apresentar formalmente a pessoa do ScrumTeam que é

especialista em Testes e enviá-lo a reunião.

B. Apresentar formalmente a pessoa do ScrumTeam que é

especialista em Testes e enviar todo o ScrumTeam à reunião para

trabalhar como uma equipe.

C. Não apresentar ninguém como responsável por Testes e

enviar todo o ScrumTeam para a reunião.

D. Não apresentar ninguém como responsável por Testes e

enviar o Product Owner para a reunião.

Q21. O ScrumTeam pede um dia folga depois de concluir o primeiro

Sprint (Para educação, pesquisa, interagir com outros times

a companhia não aceita. Quem deve discutir isso com a direção da empresa e pegar sua aprovaçãol?

), mas

A. Product Owner

B. Scrum Master

C. ScrumTeam

D. Todos

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

40

Mindmaster Treinamentos

Q22. Itens incompletos do Sprint anterior (7 itens de 8) estão retornando para o Product Backlog. O ScrumTeam entende que estes itens devem ser selecionados para o próximo Sprint, sendo assim, eles podem se manter focados e concluí-los rapidamente. Entretanto, o Product Owner acredita que alguns itens são mais importantes agora. O que devemos fazer agora?

A. Selecionar os itens pendentes assim o ScrumTeam pode

otimizar a velocidade de entrega.

B. Selecionar os itens pendentes porque não podemos começar

nada bovo anters de concluir todas as tarefas

C. Selecionar os novos itens porque o Product Owner assim

deseja

D. Selecionar novos itens porque é uma boa idéia iniciar um

novo Sprint com itens novos.

Q23. O ScrumTeam decidiu cancelar as Daily Scrums até o resto do Sprint, para economizer tempo e entregar as coisas mais rapidamente. Como Jedi Scrum Master, qual sua opinião?

A. Aceitável, porque a entrega de produtos é nossa prioridade

principal

B. Incorreto, mas aceitável, uma vez que eles chegaram a

esta decisão e assumem a responsabilidade por suas próprias

entregas.

C. Inaceitável, porque Daily Scrum são requeridas no Scrum

D. Inaceitável, porque 15 minutos por dia não impacta em nada

Q24. O Scrum Master percebe que o Product Owner está indo a todas as Daily Scrums e questiona o ScrumTeam sobre suas tarefas e dá direcionamentos específicos diariamente. Como comandante Jedi, o que o Scrum Master deve achar disso?

A. Está errado, o Product Owner não

deve participar do Daily Scrum

B. Está errado, o Product Owner não

deve falar no Daily Scrum

C. Está OK, o Product Owner pode

fazer isso

D. Está OK, é recomendado ao

Product Owner dar direcionamento

Está OK, é recomendado ao Product Owner dar direcionamento Q25. O Product Owner percebe que o

Q25. O Product Owner percebe que o cliente solicitou mudanças significativas nos itens do Sprint Backlog que está em andamento. Estas mudanças alteram completamente os itens. O que o Product Owner deve fazer?

A. Pedir ao ScrumTeam para parar todo o trabalho nestes itens

e focar nos demais itens do Sprint Backlog

B.

Alterar estes 5 itens no Sprint Backlog tão logo seja possível

C.

Cancelar o Sprint

D.

Fazer nada, permitir que o Sprint seja concluído

normalmente.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

41

Mindmaster Treinamentos

Q26. Nós não conseguimos concluir a maior dos itens do Sprint Backlog nos últimos dois Sprints. O que devemos fazer?

A.

Reduzir a capacidade dos Sprints

B.

Aumentar a duração dos futuros Sprints

C.

Ambos acima, uma vez que estamos ainda decidindo qual o

tempo correto para um Sprint.

D. Nenhuma das anteriores

Analise o Burndown chart abaixo e responda:

das anteriores Analise o Burndown chart abaixo e responda: Q27. Quantos Sprints foram feitos até agora?

Q27. Quantos Sprints foram feitos até agora?

A.

Um

B.

Seis

C.

Nove

D.

Dezesseis

E.

Não é determinado pelo Gráfico

Q28. Qual foi nossa estimative inicial para o número de Sprints requeridos para este projeto?

A.

Um

B.

Seis

C.

Nove

D.

Dezesseis

E.

Não é determinado pelo Gráfico

Q29. Quantos Sprints provavelmente serão necessaries para completer o projeto?

A. Provavelmente 9 sprints

B. Provavelmente 10 sprints

C. Provavelmente 11 sprints

D. Provavelmente 14 sprints

E. Provavelmente 16 sprints

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

42

Mindmaster Treinamentos

Q30. Ainda com base no Burndown Chart. O cliente deseja adicionar novas funcionalidades com cerca de 400 storypoints para o projeto e espera que o ScrumTeam lhe forneça uma estimative adicional. Qual é a sua idéia? (Dica: Use a resposta da Q29)

A.

Provavelmente 4 sprints

B.

Provavelmente 5 sprints

C.

Provavelmente 7 sprints

D.

Provavelmente 9 sprints  

as Respostas do assessment

Para ter acesso às respostas clique no link ou digite

http://www.mindmaster.com.br/livro-scrum/ entrando com seu login e senha.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

43

Mindmaster Treinamentos

Capítulo 6 As Certificações Ágeis

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

44

Mindmaster Treinamentos

Capítulo 6: As Certificações Ágeis

As certificações basicamente servem para atestar o seu conhecimento sobre determinado assunto., ou seja, é um diploma que vai atestar que você sabe usar a força.

Os profissionais com certificações nas áreas em que são especialistas são mais satisfeitos em suas posições e mais confiantes quanto a suas habilidades para fazer seus trabalhos do que seus pares. Além de possuírem uma grande vantagem competitiva no mercado de trabalho.

As principais certificações no mundo ágil são regidas basicamente pelos 3 órgãos a seguir:

ágil são regidas basicamente pelos 3 órgãos a seguir: scrum alliance: CSM (Certified Scrum Master ),

scrum alliance: CSM (Certified Scrum Master ), CSPO (Certified Scrum Product Owner) e CSD (Certified Scrum Developer)

scrum.org: PSM (Professional Scrum Master), PSPO (Professional Scrum Product Owner) e PSD (Professional Scrum Developer)

PMi: ACP (Agile Certified Practitioner)

Cada qual tem suas particularidades como veremos a seguir.

Scrum Alliance

A Scrum Alliance é uma entidade sem fins lucrativos com o objetivo de

promover a adoção efetiva do Scrum ao redor do mundo.

de promover a adoção efetiva do Scrum ao redor do mundo. A comunidade de membros da

A comunidade de membros da Scrum Alliance já ultrapassa o número de 300 mil pessoas ao redor do globo.

As certificações que são oferecidas pela Scrum Alliance são as seguintes:

que são oferecidas pela Scrum Alliance são as seguintes: Fonte: scrumalliance.org A certificação da Scrum Alliance

Fonte: scrumalliance.org

A certificação da Scrum Alliance que é mais difundida é a CSM (Certified

Scrum Master). Os requisitos para a certificação são:

• Participar de 2 dias de treinamento em metologias ágeis

• Fazer uma prova on-line de 35 perguntas, onde é exigido o mínimo de 70% de aproveitamento.

Prós

onde é exigido o mínimo de 70% de aproveitamento. Prós A dificuldade da prova de certificação

A dificuldade da prova de certificação é menor se comparado

com a prova da Scrum.Org. São menos questões e um índice de aproveitamento mínimo menor, facilitando a vida do candidato.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

45

Mindmaster Treinamentos

Contras

Scrum Definitivo 4 5 Mindmaster Treinamentos Contras Como é pré-requisito que o candidato tenha participado de

Como é pré-requisito que o candidato tenha participado de treinamento presencial de 2 dias em uma instituição afiliada à Scrum Alliance, o custo deste certificação é o mais alto de todas e vai variar de acordo com a instituição de treinamento escolhida.

Sendo este treinamento presencial de somente 2 dias, normalmente as instituições apresentam somente o básico do Scrum, sem aprofundar em casos práticos.

Scrum.Org

A Scrum.Org é também uma entidade sem fins lucrativos, mais voltado

para a disseminação do uso do Scrum no Desenvolvimento de Software.

do uso do Scrum no Desenvolvimento de Software. A missão da Scrum.Org é melhorar a prática

A missão da Scrum.Org é melhorar a prática do desenvolvimento de

software por meio do Scrum.

As certificações oferecidas pela Scrum.Org são as seguintes:

Professional Scrum master: Atesta os conhecimentos Professional Scrum master: fundamentais para o profissional que deseja assumir o papel de Scrum Master. fundamentais para o profissional que deseja assumir o papel de Scrum Master.

Professional Scrum Developer: Atesta os conhecimentos do desenvolvedor de software que está inserido no contexto de um projeto Atesta os conhecimentos do desenvolvedor de software que está inserido no contexto de um projeto Scrum.

software que está inserido no contexto de um projeto Scrum. Professional Scrum Product owner: Atesta os

Professional Scrum Product owner: Atesta os conhecimentos fundamentais para o profissional que deseja assumir o papel de Product Owner.

Dentre as certificações da Scrum. Org, a mais difundida é a PSM.

Os requisitos para obter esta certificação são:

• Fazer uma prova online de 80 questões em um tempo de 60 min.

• O índice de aproveitamento mínimo é de 85%

Prós

min. • O índice de aproveitamento mínimo é de 85% Prós A Scrum.Org não exige que

A Scrum.Org não exige que você tenha feito um curso em instituições credenciadas como a Scrum Alliance. Desta forma as instituições que ministram estes cursos preparatórios não precisam pagar nenhuma taxa de credenciamento como acontece com as instituições afiliadas à Scrum Alliance, fazendo com que o custo do curso seja muito inferior nos treinamento preparatório para PSM (Scrum.Org) do que para CSM (Scrum Alliance).

Caso o candidato sinta-se confortável com seu conhecimento sobre Scrum, este pode se submeter ao teste sem ter feito curso algum, bastando apenas pagar a taxa da prova de US$ 100,00.

Contras

bastando apenas pagar a taxa da prova de US$ 100,00. Contras Prova onde são atestados conhecimentos

Prova onde são atestados conhecimentos teóricos sobre o Scrum, mas que não representam que o candidato saiba aplicar na prática.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

46

Mindmaster Treinamentos

PMI

O Project Management Institute (PMI) é uma instituição internacional

sem fins lucrativos que associa profissionais de gestão de projetos. É considerada uma das maiores associação do gênero no mundo, e possui mais 500.000 profissionais certificados em cerca de 170 países.

500.000 profissionais certificados em cerca de 170 países. O PMI é famoso pela publicação do PMBOK

O PMI é famoso pela publicação do PMBOK (Project Management Body

of Knowledge), que é considerado o guia principal das melhores práticas de gerenciamento de projetos tradicionais. Pautado no PMBOK, a certificação mais famosa do PMI é o PMP.

Além do PMP, recentemente o PMI tem avançado com sua nova certificação ágil, a PMI-ACP.

tem avançado com sua nova certificação ágil, a PMI-ACP. PMI-ACP é, atualmente, a menos difundida no

PMI-ACP é, atualmente, a menos difundida no mundo ágil, talvez por ser a mais recente, porém vem ganhando força a cada dia.

Os requisitos para se obter a certificação são:

• Comprovar pelo 2.000 horas de experiência em projetos

obtidas nos últimos 5 anos mais 1.500 horas trabalhadas em

projeto ágeis nos últimos 3 anos.

• 21 horas de contato com capacitação formal em treinamentos ágeis

• Prova presencial, em local aprovado pelo PMI, com 120 questões e 3 horas de duração.

• É necessário um aproveitamento mínimo entre 70% e 80% para passar.

Prós

aproveitamento mínimo entre 70% e 80% para passar. Prós A certificação leva a chancela da maior

A certificação leva a chancela da maior e mais reconhecida instituição de gerenciamento de projetos do mundo, que é o PMI.

Aborda diversas técnicas de metodologia ágil que vão além do Scrum.

Contras

de metodologia ágil que vão além do Scrum. Contras Exige uma experiência anterior de 4.500 horas

Exige uma experiência anterior de 4.500 horas em projetos, o que pode impossibilitar a certificação para profissionais iniciantes.

Por abordar diversas técnicas além do Scrum, o nível de conhecimento exigido é maior dos as demais certificações. Porém a prova não é tão rigorosa quanto à Scrum.Org.

O custo desta certificação também é um pouco alto, pois a prova deve ser feita presencialmente em um local credenciado pelo PMI.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

47

Mindmaster Treinamentos

Capítulo 7 Resumo

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

48

Mindmaster Treinamentos

Capítulo 7: Resumo

Entregar software de qualidade de um modo ágil, criativo e que atenda as expectativas do cliente não é algo para qualquer um, isso é trabalho para um verdadeiro Jedi.

Neste livro abordamos conceitos, práticas e highlights importantes sobre o método ágil na prática.

Você deve ter percebido que muitas das coisas aqui ensinadas são oportunidades únicas para você aplicar com seu time no trabalho e ver os resultados por si mesmo.

A seguir vou listar uma sequencia de itens que resumem os principais conceitos do Scrum.

Se desejar, informo também ao final como aprender tudo isso de modo prático e divertido através de um treinamento online totalmente inovador.

Esperamos que tenha gostado do livro e acima de tudo

Que a Força esteja com Você!

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

49

Mindmaster Treinamentos

1-Product Backlog

O Product Backlog contém uma lista de desejos com todas as User Stories que tornarão o produto especial

Como um (Função), eu gostaria de (Funcionalidade) para que (Benefício)
Como um (Função), eu gostaria
de (Funcionalidade) para que
(Benefício)

Em Scrum funcionalidades são conhecidas como User Stories e são escritas sob a perspectiva do usuário final. O Product Owner representa os usuários clientes e decides quais User Stories ou itens devem ser priorizados no Product Backlog

2-Release Backlog

A Meta principal de cada iteração é entregar uma parte importante do Product Backlog, conhecida como Release Backlog.

do Product Backlog, conhecida como Release Backlog. Depois de identificar quais User Stories irão em cada

Depois de identificar quais User Stories irão em cada Release, estas User Stories se tornam parte do Release Backlog

estas User Stories se tornam parte do Release Backlog Depois as User Stories são estimadas pelo

Depois as User Stories são estimadas pelo ScrumTeam que fornecem a quantidade de tempo em horas para o desenvolvimento de cada item.

de tempo em horas para o desenvolvimento de cada item. Todas as imagens, personagens e símbolos,

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

50

Mindmaster Treinamentos

3-sprint Backlog

A cada Sprint (Um Marco do Projeto de curta duração) uma parte do Release Backlog é desenvolvida e uma parte potencialmente entregável, passível de demonstração, é concluída.

sprints geralmente tem uma duração de 2 a 4 semanas, entretanto, podem chegar até 30 dias.

Ao final de cada Sprint você deverá ter um produto plenamente testado com todas as funcionalidade do sprint 100% concluídas

4-Burndown Charts

Data estimada de Término Velocidade O Progressso do Projeto é monitorado utilizando o Burndown Chart,
Data estimada de
Término
Velocidade
O Progressso do Projeto é monitorado utilizando o Burndown Chart,
uma das melhores ferramentas para prover visibilidade e garantir o
progresso do projeto de modo transparente. O Burndown chart provê
uma visão dia-a-dia da medida de progresso e do que ainda está por se
fazer em um referido Sprint.
Média de Produtividade = 25h/Dia
Linha Tendência
geral
a linha vermelha ou Velocidade é a média da
produtividade de cada dia.
Trabalho restante / Produtividade =
Dias para Conclusão
Trabalho RestanteTrabalho
Restante

Saber qual é o ponto do projeto e sua tendência de progresso pode ser determinante para eventuais ajustes necessários para tornar o projeto em dia novamente.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

51

Mindmaster Treinamentos

5-Daily standups

As rápidas reuniões de Daily Standup Meetings (Também conhecidas como Daily Scrums) garantem que tudo está sob controle e que todos tem todas as ferramentas que necessitam. É uma ferramenta de informação essencial para prover um fluxo de informação importante entre os membros do projeto.

de informação importante entre os membros do projeto. Os membros do ScrumTeam listam o trabalho que

Os membros do ScrumTeam listam o trabalho que eles completaram desde a última reunião, qualquer impedimento em seu caminho e o que eles farão até a próxima reunião.

isto é o que Fiz desde nossa última reunião. estes são os obstáculos que encontrei.
isto é o que Fiz
desde nossa última
reunião.
estes são os
obstáculos que
encontrei.
isto é o que estou
planejando fazer
hoje.

6-sprint Retrospectives

Depois de cada Sprint uma reunião de Retrospectiva visa ajustar e aprimorar os processos.

de Retrospectiva visa ajustar e aprimorar os processos. Este é um momento para cada membro do

Este é um momento para cada membro do time refletir sobre o que foi certo e quais são as oportunidades de melhorias.

o que foi certo e quais são as oportunidades de melhorias. o que funcionou? o que
o que funcionou? o que não funcionou? o que podemos melhorar para o próximo Sprint?
o que funcionou?
o que não
funcionou?
o que podemos
melhorar para o
próximo Sprint?

Acima de tudo, o Scrum é um método de desenvolvimento ágil flexível que oferece melhoria contínua e ajustes para todo o time.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

52

Mindmaster Treinamentos

Bibliografia Sugerida

5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br
5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br
5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br
5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br
5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br
5 2 Mindmaster Treinamentos Bibliografia Sugerida Sites interessantes sobre Scrum www.mindmaster.com.br

Sites interessantes sobre Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

53

Mindmaster Treinamentos

Glossário do Scrum

scrum Master

O ScrumMaster é o responsável por garantir que o Scrum Team se

orienta pelos valores e práticas do Scrum. O ScrumMaster protege o

time certificando-se de que os membros não se comprometam com compromissos além dos que eles conseguem cumprir dentro de um sprint.

Product owner

O Product Owner (dono do produto) representa os interesses de

todos os envolvidos (stakeholders), define as funcionalidades do produto e prioriza os itens de Product Backlog.

scrum Team ou Time de Desenvolvimento

O Scrum Team constrói o produto que o cliente irá utilizar

Product Backlog

Lista de desejos que incrementar o produto a ser desenvolvido

sprint

Representa um ciclo de desenvolvimento do

produto com timebox pré-

determinado

TimeBox

Uma escala de tempo que restringe o Sprint. Tempo dedicado para o cumprimento do Sprint.

o Sprint. Tempo dedicado para o cumprimento do Sprint. sprint Backlog Lista de histórias a serem

sprint Backlog

Lista de histórias a serem desenvolvidas em uma sprint

sprint Planning

A reunião Sprint Planning é onde o Scrum Team e o Product Owner

determinam quais funcionalidades e atividades serão realizadas

no próximo Sprint.

Daily Meetings ou standup meetings

É uma reunião diária e rápida com todos os membros do Scrum Team e o Scrum Master

sprint Review

Todo Sprint se encerra com a Reunião Sprint Review, onde o Scrum Team demonstra o incremento de produto potencialmente utilizável.

Retrospectiva

É o mecanismo principal para a visibilidade que o Scrum proporciona a áreas que potencialmente necessitam de melhorias, transformando-as em resultados.

Release

Plano de alto nível sobre o desenvolvimento

Release Planning

Planejamento do projeto em relação a Sprints, processos, reuniões e etc.

Burndown Chart

O Sprint Burndown Chart é uma representação gráfica do trabalho

restante no Sprint

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

54

Mindmaster Treinamentos

Como posso aprender isso tudo na Prática

Acesse o site abaixo e descubra uma maneira 100% prática de aprender Scrum e implementar em seu projeto.

Surpreenda-se com o material e Agilize sua Carreira, Torne-se um Gerente Agil

agora: http://www.mindmaster.com.br/curso-scrum-master Todas as imagens, personagens e símbolos, são marcas

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Scrum Definitivo

55

Mindmaster Treinamentos

Que a Força esteja com Você!

contato@mindmaster.com.br

com Você! www.mindmaster.com.br contato@mindmaster.com.br Todas as imagens, personagens e símbolos, são marcas

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.