as técnicas e estratégias para você vencer usando o método...

ScrumDefinitivo

As técnicAs e estrAtégiAs pArA você vencer usAndo

o método ágil mAis fAmoso dA gAláxiA

Denis RoDRigues PeDRo

Denisson VieiRa

Mindmaster TreinamentosScrum Definitivo 2

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

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ê!

Denis Pedro Denisson Vieira

Co-founder Co-Founder

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



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çõesScrum

7) Resumo



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.



Capítulo 1Os Fundamentos do Scrum



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.



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 o progresso e avanço do sprint (Tá ficando curioso com tanta informação nova?)

• 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.



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



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.

www.agilemanifesto.org



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 Daily Scrum como atividade de planejamento, com foco em alcançar a meta da iteração. As três perguntas fundamentais do Daily Scrum foram modificadas para:

Oquefizontemqueajudouotimeaatingirametado sprint?

Oquevoufazerhojeparaajudarotimeaatingirametado sprint?

Existealgumimpedimentoquenãopermitaamimouaotimeatingirametadosprint?

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



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:



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.

http://www.mindmaster.com.br/livro-scrum/




Capítulo 2O Time Scrum



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

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 .


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.

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;

• 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;

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

• 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 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 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.



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.

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, tais como teste ou análise de negócios.



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

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);



• 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







Capítulo 3Eventos Scrum



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.

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.


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.

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 .

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;

• 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.

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.

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.

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.



Cancelamento 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.

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.

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.

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.

Reunião de Planejamento da sprint

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 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:

• 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.

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.



O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do ScrumTeam nesta reunião. Somente o ScrumTeam pode avaliar o que pode ser completado ao longo da próxima Sprint.

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.

O Product Owner pode estar presente durante a segunda parte da reunião de planejamento da Sprint, para clarificar os itens do Backlog do Produto selecionados e para ajudar nas decisões conflituosas ou eventuais dúvidas.

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 objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em relação as funcionalidades a serem implementadas dentro da Sprint.

Conforme o ScrumTeam trabalha, ela mantém o objetivo em mente, e no caminho de buscar satisfazer o objetivo da Sprint, ela implementa a funcionalidade e a tecnologia.

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.



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.



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.

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.



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–13:30.OScrumMasterdáaberturaàreuniãoeinformaarespeitodaAgenda.

•OproductownerinformaedetalhaoobjetivodosprintetambémrepassacomoScrumTemaositensdoproductbacklog.OProductOwnerdefineolugar,dataehoradademonstraçãodoprodutoaserdesenvolvidonaqueleSprint.

•13:30–15:00.OScrumTeamestimaotempoequebraositensconformenecessário.Oproductownerpriorizarobacklogcombasenograudeimportânciaconformenecessário.Ositenssãoesclarecidos.ADefinitionofDoneérepassadaparatodos.

•15:00–16:00.OScrumTeamescolheasestóriasaseremincluídasnosprint.Calculamavelocidadeparaverificarseoplanejamentoficourealista.

•16:00–17:00.OScrumMasterinformaradata,horaelocalparaoDailyScrum.Sehouvertempoaindaépossívelusarosúltimosminutosparaesclarecimentosdedúvidas.

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

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



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







Capítulo 4Artefatos do Scrum



Capítulo 4: Artefatos do Scrum

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.


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.

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.

Como um (Função), eu gostaria de (Funcionalidade)

para que (Benefício)



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.

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.



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.

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.



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.



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)



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).

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.



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.

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








Capítulo 5Teste seu Conhecimento



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.

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.



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.

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



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

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



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

C. Eles devem pedir ao Product Owner para decidir sobre isso

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

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.

D. O Product Owner detém a responsabilidade maior

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.



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

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...), mas a companhia não aceita. Quem deve discutir isso com a direção da empresa e pegar sua aprovaçãol?

A. Product Owner

B. Scrum Master

C. ScrumTeam

D. Todos



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

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.



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:

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



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.




Capítulo 6As Certificações Ágeis



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:

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.

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:

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

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.



Contras

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.

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 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 Scrum.

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

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

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



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.

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.

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

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

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.



Capítulo 7Resumo



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ê!



1-Product Backlog 2-Release Backlog

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

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

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

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

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

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

(Benefício)



3-sprint Backlog 4-Burndown Charts

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.

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.

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.

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

Trab

alho

Res

tant

eTr

abal

ho R

esta

nte

Linha Tendência geral

Trabalho restante / Produtividade = Dias para Conclusão

Velocidade

Média de Produtividade = 25h/Dia

Data estim

ada de Térm

ino

a linha vermelha ou Velocidade é a média da produtividade de cada dia.Ao final de cada Sprint você

deverá ter um produto plenamente testado com todas as funcionalidade do sprint 100% concluídas



5-Daily standups 6-sprint Retrospectives

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.

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.

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

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

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

isto é o que Fiz desde nossa última

reunião. estes são os obstáculos que

encontrei.

isto é o que estou planejando fazer

hoje.

o que funcionou?

o que não funcionou?

o que podemos melhorar para o próximo Sprint?



Bibliografia Sugerida Sites interessantes sobre Scrum

www.mindmaster.com.br

www.scrumalliance.org

www.scrum.org

www.mountaingoatsoftware.com

www.agilesoftwaredevelopment.com

www.noop.nl


http://www.scrumalliance.org

http://www.scrum.org

http://www.mountaingoatsoftware.com

http://www.agilesoftwaredevelopment.com

http://www.noop.nl



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.

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



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

Acesse agora: http://www.mindmaster.com.br/curso-scrum-master

http://www.mindmaster.com.br/curso-scrum-master



Que a Força esteja com Você!www.mindmaster.com.br

[email protected]



Capa e Diagramação por:

Yuri Santos

yupastudio.com

http://www.yupastudio.com/




as técnicas e estratégias para você vencer usando o método...

Documents