Apostila Scrum

8/2/2019 Apostila Scrum

1/61


2/61

Blog do Abu Apostila de Apoio

Nelson Abu Samra Rahal Junior ([email protected]) - Pgina: 2

Contents

Autores .........................................................................................................................4Nelson Abu Samra Rahal Junior................................................................................4Neilza Andrea Abu Samra Rahal...............................................................................4

Scrum........................................................................................................................... 5Voc sabe o que Scrum?.........................................................................................5Framework Scrum.....................................................................................................7Papis no Scrum........................................................................................................ 8

Product Owner (PO)..............................................................................................8Scrum Mster (SM)............................................................................................... 8Equipe (EQ).......................................................................................................... 9

Viso do Produto ....................................................................................................11Executando a Viso do Produto........................................................................... 11Exemplo de Viso do Produto .............................................................................12

Product Backlog......................................................................................................13Exemplo de Product Backlog ..............................................................................13

Estimativas, Velocidade da Equipe, Quantidade de Sprints e Product Burndown

Chart.......................................................................................................................15Contando os Pontos.............................................................................................16Exemplo de Pontos Contados ..............................................................................17Determinando o Tempo do Projeto......................................................................17Product Burndown Chart..................................................................................... 18

Priorizao e Distribuio de Requisitos por Sprints .............................................. 20Executando a Priorizao .................................................................................... 20

Sprint, Planejamento da Sprint #1, Planejamento da Sprint #2, Sprint BurndownChart e Execuo da Sprint .....................................................................................22

Planejamento da Sprint #1...................................................................................23Planejamento da Sprint #2...................................................................................24Sprint Burndown Chart .......................................................................................24

Calculo de Velocidade da Sprint..........................................................................25Exemplo de Tarefas na Sprint..............................................................................25Exemplo de Ciclo de Vida de Uma Sprint ...........................................................26Executando a Sprint ............................................................................................28

Desenvolvimento e Reunies Dirias ......................................................................30Sete Fundamentos para reunies dirias eficazes ................................................. 30Impedimentos......................................................................................................31Dia a Dia da Reunio Diria................................................................................ 31

Review.................................................................................................................... 32Retrospectiva ..........................................................................................................33

Linha do Tempo (Timeline)................................................................................. 33Retrospectiva Rpida...........................................................................................37

Dia a Dia Aps a Retrospectiva...........................................................................38Release (Verses)....................................................................................................39Scrum de Scrum......................................................................................................41Potencializando Scrum............................................................................................ 43

picos, Temas e Historias ...........................................................................................45Carto de Historia ................................................................................................... 45

Exemplo de Carto de Historia............................................................................45Template de Carto de Historia ...........................................................................45Organizando Cartes de Historia .........................................................................46


3/61



Exemplos de Carto de Historia ..........................................................................48Escopo do Projeto ............................................................................................... 49pico, Tema e Historia........................................................................................50Trabalhando com Temas .....................................................................................51Exemplos de Testes criados para Cartes de Histria ..........................................52

Templates de Documentos ..........................................................................................55

Viso do Produto ....................................................................................................55Planejamento da Sprint #1.......................................................................................57Planejamento da Sprint #2.......................................................................................58Review.................................................................................................................... 59Retrospectiva ..........................................................................................................59

Softwares Para Gerenciamento gil de Projetos..........................................................61


4/61



Autores

Nelson Abu Samra Rahal Junior

Paulista de Assis

Professor universitrio desde 1996

Atuo na rea de desenvolvimento de software desde 1991

Especialista em gerenciamento de projetos geis

Graduado em Processamento de Dados

Ps-graduao em Didtica e Metodologia de Ensino

Ps-graduao em Gerncia de Projetos de TI (PMI)

Mestre em Cincia da Computao

Certificado ScrumMaster

Consultor da Innovit Gesto de Projetos e Processos

Neilza Andrea Abu Samra Rahal

Paranaense de Arapongas

Professora universitria desde 1998 Especialista em gerenciamento de projetos na rea de Teste de

Software

Graduado em Processamento de Dados

Ps-graduao em Didtica e Metodologia de Ensino

Ps-graduao em Gerncia de Projetos de TI (PMI)

Mestre em Cincia da Computao

Certificada em Teste de Software


5/61



Scrum

Voc sabe o que Scrum?

* Escrito em parceria com Marcelo dos Santos

Scrum um processo de gerenciamento de projetos geis, adaptadopara a rea de desenvolvimento de software, pelo especialista Ken Schwaber.Ken define Scrum, em um de seus livros, como: um processo gil ou ainda umframework para gerenciamento de projetos geis. um processo de gernciade projetos, certamente no uma metodologia, pois isto seria pesadodemais.

A primeira experincia com o Scrum ocorreu em uma fbrica deautomveis, onde se constatou que a utilizao de equipes pequenas e

multidisciplinares produzia melhores resultados. Em analogia a essas equipes,associou-se a formao do Scrum a de um jogo de Rugby. A partir de 1995,Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo emdesenvolvimento de software em todo o mundo.

Ilustrao 1 - Formao de Scrum em jogo de Rugby

Martin Fowler, um dos maiores estudiosos em desenvolvimento desoftware, comenta em seu artigo A Nova Metodologia que: Nos ltimos anos,

vem crescendo rapidamente o interesse em metodologias geis (ou "leves").Tambm caracterizadas como um antdoto contra a burocracia ou uma licenapara "hackear". Estas metodologias despertaram os interesses em toda aextenso da indstria do software.

Dentre as tcnicas de utilizao do Scrum, h a entrega de produtos emperodos de tempo pr-estabelecidos, nunca inferiores a uma semana ousuperiores a trinta dias.


6/61



Para estimular o contato entre empresa e cliente, os projetos sointerrompidos em perodos regulares de tempo. A essas aes d-se o nomede Sprint. Ao trmino de cada Sprint, o cliente recebe um conjunto defuncionalidades desenvolvidas e prontas para serem utilizadas. A melhormaneira de comprovar se o software atende s necessidades fazer com queo cliente o utilize, apontando as qualidades e o que falta ser aperfeioado.

Importante destacar que a participao ativa do cliente no processo dedesenvolvimento de software faz com que sejam atribudas a ele algumasresponsabilidades como definio das funcionalidades do produto, decisoquanto s datas de lanamento de contedo e ajuste de funcionalidades.


7/61



Framework Scrum

Ilustrao 2 - Framework Scrum


8/61



Papis no Scrum

Scrum possui apenas trs papeis, sendo eles: Product Owner, ScrumMaster e a Equipe.

Product Owner (PO)

Conhecido tambm como dono do produto o responsvel peladefinio do projeto, levando a equipe de desenvolvimento o que chamamos deViso do Produto.

Uma vez transmitida a Viso do Produto a equipe de desenvolvimento odono do produto responsvel pela priorizao dos requisitos e definio dosmesmos.

O Product Owner pode mudar as priorizaes, adicionar ou removernovos requisitos conforme as suas necessidades. Ele apenas no pode mudaro trabalho que j est em codificao pela equipe de desenvolvimento.

Uma das grandes chaves de sucesso do Scrum est no Product Owner,por intermdio da definio e clareza dos requisitos. Os requisitos no devemchegar parcialmente definidos a equipe de desenvolvimento, caso isso ocorra acapacidade de produo da equipe vai diminuir.

O Product Owner tambm responsvel pelo retorno de investimento(ROI) do projeto. difcil definir ROI, mas no Scrum ele se materializa com apriorizao dos requisitos e codificao dos mesmos. No Scrum a entrega omais rpido possvel ao Product Owner dos mdulos que ele tem necessidade

caracteriza ROI e o Product Owner com o sistema em funcionamento podeavaliar o que est sendo construdo ou at mesmo utiliz-lo o mais rpidopossvel.

Tambm uma das chaves de sucesso do Scrum com o Product Ownerest na sua disponibilidade a equipe de desenvolvimento de software. As vezester o Product Owner sempre disponvel difcil, mas uma meta a ser seguida.

Devemos lembrar que o Product Owner o representante do cliente e aequipe de desenvolvimento de software tem que atender as suas expectativase orientaes. O Product Owner tem o poder de aceitar ou rejeitar um trabalhorealizado pela equipe de desenvolvimento de software.

Scrum Mster (SM)

O Scrum Mster uma pessoa da equipe de desenvolvimento dosoftware que possui algumas responsabilidades diferentes dos demais. Entreas responsabilidades est a de manter o processo do Scrum ativo, garantindoque o projeto vai ser realizado seguindo as boas praticas do Scrum.

Tambm faz parte das responsabilidades do Scrum Master identificartodos os problemas que esto ocorrendo durante o desenvolvimento do


9/61



sistema, que faz com que a capacidade de produo da equipe diminua ou atmesmo no permita que a equipe continue trabalhando. Estes problemas noschamamos de obstculos ou impedimentos e devem ser solucionados peloScrum Master. Quando o Scrum Master no tem condies de solucionar oimpedimento ele deve buscar a pessoa que pode resolver o problemaidentificado.

A produtividade da equipe mais uma responsabilidade do ScrumMaster, pois ele deve fazer com que a equipe de desenvolvimento do sistemafique focada o maximo possvel na sua rea de atuao, que a construo dosoftware. Neste ponto nos falamos que o Scrum Master tem que ser umablindagem da equipe, no permitindo que eventos externos atrapalhem ostrabalhos que esto sendo realizados.

Um ponto importante que o Scrum Master no tem que ter autoridadesobre a equipe, isto , qualquer integrante da equipe de desenvolvimento desoftware pode ser o Scrum Master e at mesmo fazer um rodzio destaresponsabilidade. A troca de Scrum Master entre as pessoas da equipe deveser realizada com cautela, nunca a cada sprint (fase, ciclo ou iterao) de

desenvolvimento e sim por projeto ou por verses (releases) do sistema.Podemos ter tambm um Scrum Master coringa, para que caso o Scrum

Master do projeto no possa estar presente com a equipe, uma pessoa daequipe j saiba que ele o responsvel por executar as atribuies de trabalhodo Scrum Master.

Equipe (EQ)

a responsvel pela execuo do projeto, sendo protegida pelo ScrumMaster e tendo como foco o atendimento das necessidades do Product Owner.

Uma equipe em Scrum constituda de no mnimo 2 pessoas e no

maximo de 7 pessoas. As equipes so menores para potencializar uma dasmaiores armas do Scrum, a comunicao entre a equipe.

Trs pessoas nos temos uma comunicao direta entre cada integranteda equipe, conforme a equipe vai aumentando a complexidade decomunicao entre todos os integrantes vai aumentando.

Equipes enxutas chegam a ter a sua capacidade de produo melhorque equipes grandes. Este aumento de velocidade ocorre em virtude dapotencializao da comunicao entre os integrantes da equipe.


10/61



Ilustrao 3 - Complexidade da Comunicao

A formao da equipe multidisciplinar, sendo ela constituda de:Engenheiros de Software, Arquitetos, Programadores, Analista, Peritos emQualidade, Testadores, Web designers.

Mas em Scrum as equipes so generalistas e no especialistas. Todosos integrantes da equipe podem e devem desempenhar todos os papeis,conforme a necessidade e definio da equipe.

Nos utilizamos equipes multidisciplinares e generalistas para que oprojeto possa ter uma velocidade de execuo maior e uma reduo de riscoscom relao a definio do produto que est sendo realizado. Os generalistaspermitem com que todas as pessoas do projeto sempre executam qualqueratividade. Com a equipe generalista nos passamos a potencializar acapacidade de produo que o nosso projeto possui, removendo o risco de umintegrante da equipe ficar parado aguardando o trabalho que deve serexecutado ficar disponvel. Os multidisciplinares permitem a reduo do risconas definies do produto, permitindo a integrao das mais diversas reas nabusca de um produto melhor.

As equipes em Scrum so auto-organizadas, isto , elas definem a suaforma de trabalho e evoluem est forma de trabalho pela sua prpria avaliaode como est sendo executado o projeto.

Dentro da equipe de Scrum institudo o conceito de auto-gesto, ondea equipe passa a ter autonomia de tomada de deciso para o seu foco deatuao, que o de desenvolver o sistema solicitado pelo Product Owner.


11/61



Viso do Produto

Viso do Produto ou Escopo do projeto a apresentao daabrangncia do projeto a equipe de desenvolvimento do projeto. A viso doproduto no tem o objetivo de ser uma apresentao detalhada dos requisitos esim uma apresentao em auto nvel de todos os mdulos que vo ser

construdos. Nesta apresentao pode ser apresentado a equipe fatores desucesso, caractersticas de qualidade desejada, as metas e o que mais fornecessrio.

A viso do produto pode ser realizada varias vezes durante o projeto,no sendo uma regra a sua apresentao apenas no inicio do projeto. Comest reapresentao no decorrer do projeto diminumos o risco do desvio doentendimento dos nossos objetivos durante a execuo, fazendo com quetodos mantenham o alinhamento com a Meta do projeto, e no apenas noinicio do projeto.

Executando a Viso do Produto

Os participantes devem ser convidados com antecedncia. No conviteter o local da reunio, a hora, data e o assunto da reunio. Na sala de reuniesdeixar disponvel para todos os presentes etiquetas coloridas colantes (post-its), papel e canetas. A reunio pode ser filmada ou apenas o som gravado.

Durante a apresentao pode ser realizada a apresentao de slides,filmes, ou qualquer tipo de recurso que permita a transmisso deconhecimentos s pessoas que esto assistindo.

Est reunio no tem o objetivo de ser uma analise de sistemas, isto ,as pessoas que esto participando tem a liberdade de realizar perguntas, masno existe a necessidade de se fazer uma analise detalhada dos itensapresentados. O objetivo da reunio de apenas saber o que vamos fazer,quais as principais entregas, o que cada modulo em auto nvel eprincipalmente, fazer com que todos os envolvidos passem a ter conhecimentodo projeto, pois este conhecimento e a participao na reunio de viso doproduto leva a equipe a um comprometimento com o trabalho que vai serrealizado.


12/61



Exemplo de Viso do Produto

Dia XX hora YY encontra-se reunido na sala de reunies da empresaACME a equipe do desenvolvimento do novo projeto da empresa. Junto com aequipe tambm esta presente o representante do cliente, o nosso ProductOwner.

A apresentao do projeto realizada com alguns recursos visuais e oescopo do mesmo apresentado. O nosso projeto de um software de vendade livros pela internet.

O Product Owner apresenta nos slides dados do sistema atual e seusproblemas existentes e acrescenta as expectativas com relao ao novosistema a ser realizado.

Um dos focos de sucesso est no Carrinho de Compras, onde osistema atual apresenta problemas de usabilidade e de performance deexecuo. Tambm apresentado pelo Product Owner um risco para o projeto,onde o risco apresentado que se o Carrinho de Compras no for construdocom foco nas expectativas do cliente o projeto no tem porque continuar.

Mais um novo risco apresentado ao nosso projeto, nos temos umadata limite de construo do sistema, pois o cliente deseja colocar o novosoftware em funcionamento antes do perodo de compra de material escolar,para que ele O Cliente possa ter retorno do investimento que est sendorealizado no novo software com as vendas de seus produtos.

A equipe de desenvolvimento inicia a sabatina de perguntas ao ProductOwner, para que todos possam ter o mesmo entendimento do que deve serrealizado, quando as perguntas entram em partes bem especificas, isto , oentendimento aprofundado de um determinado modulo o Scrum Mster faz opapel de moderador e comenta que teremos o momento mais adequado para arealizao da analise dos requisitos do sistema a ser desenvolvido e que este

momento para que todos saibam a onde pretendemos chegar com o nossoprojeto.

Ao termino da reunio a equipe de desenvolvimento do sistema sai dareunio com as suas anotaes e uma tabulao rpida destas anotaespermite a criao de uma lista de requisitos em alto nvel do nosso projeto.

O Scrum Mster apresenta a todos os integrantes da equipe odocumento tabulado: Cadastro de Clientes, Cadastro de Produtos, Carrinho deCompras, Busca de Produtos, Categoria de Produtos, Histrico de Compras,Rastreamento de uma Compra, Pagamento por Carto de Credito, Pagamentopor Boleto Bancrio e Exportao de Dados de Vendas para um sistema deERP existente na empresa


13/61



Criar Backlog

2

PO

Product Backlog

Uma vez realizada a apresentao da Viso do Produto para osenvolvidos no projeto uma relao de requisitos deve ser elaborada para que osistema possa ser desenvolvido. Est relao de requisitos nos chamamos deProduct Backlog.

Podemos organizar a nossa lista de requisitos de varias maneiras, sendouma organizao apenas por requisitos referentes ao negocio a serdesenvolvido, ou uma lista com a relao de requisitos envolvendo o negocio aser desenvolvido mais os requisitos no funcionais do sistema.

A estimativa do tamanho do projeto realizada sobre os requisitosexistentes na nossa lista de Product Backlog, mas para a realizao destaestimativa nos utilizamos os requisitos em auto-nvel chamados de Temas.Um Tema um requisito que tem contido dentro dele requisitos menores. Nsvamos ver melhor a parte de requisitos no universo gil no tpico denominadode historias.

Todos os envolvidos no projeto podem adicionar requisitos a nossa lista

de requisitos do sistema, mas apenas o Product Owner pode priorizar osrequisitos.

A priorizao destes requisitos contidos no Product Backlog permite umaviso temporal de quando uma determinada funcionalidade vai ser realizada noprojeto. A principio pode ser considerado um desperdcio de tempo, pois nodecorrer do projeto est priorizao ir ser mudada conforme a necessidade doProduct Owner, mas ela ajuda a todos os envolvidos a terem a viso de como oprojeto vai ser executado j no incio do mesmo, mesmo sabendo quepodemos ter mudanas de prioridade.

Exemplo de Product Backlog

Nos j temos uma relao de requisitos identificados na Viso doProduto e a qualquer momento novos requisitos podem ser adicionados aoprojeto. O nosso Product Backlog no constitudo uma nica vez e simcontinuamente construdo.

O documento gerado pela Viso do Produto possui os requisitos emauto-nvel: Cadastro de Clientes, Cadastro de Produtos, Carrinho de Compras,Busca de Produtos, Categoria de Produtos, Histrico de Compras,Rastreamento de uma Compra, Pagamento por Carto de Credito, Pagamento


14/61



por Boleto Bancrio e Exportao de Dados de Vendas para um sistema deERP existente na empresa. Para cada requisito em auto-nvel, chamado deTema nos passamos a adicionar os requisitos menores, denominados dehistorias.

Devemos lembrar que jamais podemos ignorar um requisito identificado,mesmo na viso do produto se um requisito menor for apresentado ele deveser anotado e agrupado ao seu Tema principal.

O Carrinho de Compras com o processo de analise do sistema passa ater os requisitos menores: Adicionar produtos ao carrinho de compras, removerprodutos do carrinho de compra, custo da entrega dos produtos conforme omeu CEP, desconto existentes em cada produto e itens do carrinho de compradevem permanecer no sistema at o desejo do comprador.

Vrios requisitos menores foram criados pela prpria equipe dedesenvolvimento e o Product Owner vai validar cada um deles, desta maneiratodos os envolvidos no projeto passam a ser donos do produto a ser criado.

O Tema Cadastro de Clientes recebeu os requisitos menores:

Endereo do Cliente, Endereo de Entrega, Telefones de Contatos, Histricode Compras.

Podemos organizar o nosso Product Backlog em uma planilha com ascolunas: Tema, Historia, Pontos, Prioridade, Sprint. As colunas desta planilhavo ser definidas nos prximos tpicos.


15/61



Estimativas, Velocidade da Equipe, Quantidade de Sprints eProduct Burndown Chart

Procure

uma

histria de

2 pontos

Equipe

identifica a qtd

de pontos de

esforo para

cada Item do

Backlog

4SM EQ

Calcular a

Velocidade da

equipe

5

SM EQ

Definir a qtd

de Sprints

6

SM

Montar

Product

Burndown

Chart

7

SM

O ato de estimar o tempo necessrio para a concluso de um projetosempre tem uma poro de chute, ns apenas sabemos o tempo necessriopara a realizao de uma tarefa quando est tarefa j esta concluda.

Antes de sua concluso apenas temos uma noo do tempo que vai sernecessrio, ou apenas um desejo do que acreditamos ser possvel de serrealizado.

Um projeto de um ano, onde existe um erro de uma hora por dia detrabalho, ao trmino de um ano teremos mais de 200 horas de atraso.

Em desenvolvimento gil ns realizamos a estimativa de um projeto pelacontagem de pontos, onde um ponto uma forma de comparao de esforonecessrio para a realizao de um requisito.

Mas ns tambm temos uma estimativa em horas, que realizada naquantidade de tarefas existente em uma Sprint.

A estimativa em pontos busca a viso do esforo do projeto e deve serreestimada varias vezes durante o projeto, para corrigirmos imperfeiesiniciais. J a estimativa da Sprint, utilizando tarefas estimadas em horas tem oobjetivo de saber se a quantidade de trabalho identificado comportada pelaequipe.


16/61



Contando os Pontos

O cliente solicitou uma data de termino da entrega do projeto, para queele possa realizar uma analise de riscos com relao a data limite da entregado projeto e o inicio do perodo de vendas de material escolar.

A equipe se rene com o Product Owner para realizar as estimativas

necessrias. Os requisitos utilizados so os de tamanho de Temas.Com cada um dos requisitos escritos em papeis e colocados sobre a

mesa a equipe busca os de menos esforo de trabalho. Est busca tem oobjetivo de escolher um requisito que vai ser utilizado como ponto dereferencia, uma ancora em relao aos demais.

A participao do Product Owner fundamental, pois a cada requisitoem tamanho igual a um Tema a equipe pode solicitar maiores informaes eo Product Owner passa a responder estas informaes. Est reunio inclusive um timo momento de anotarmos mais requisitos contidos num Tema, paraatualizao do nosso Product Backlog.

A equipe por consenso identifica o requisito de tamanho menor, esterequisito o de Categoria de Produtos. Para facilitar o processo de contagemde pontos buscamos os requisitos que so um pouco maior que o menor, poissempre aparecem requisitos menores ao que nos estamos utilizando comobase, isto , ancora.

Por consenso a equipe escolhe o Cadastro de Clientes e este recebe ovalor igual a dois pontos. Dois pontos neste momento da tcnica de estimativano tem nenhuma correlao com o tempo necessrio para a relao doprojeto, apenas representa o tamanho do esforo necessrio para a construodeste Tema.

Com o requisito de tamanho igual a dois passamos a comparar este

requisito com os demais e atribuir aos demais os valores em pontoscorrespondentes. A escala de pontos utilizado a de Fibonacci, 1, 1, 2, 3, 5, 8,13, 21, 34, ?.

O processo de contagem de pontos, ns utilizamos o Planning Poker,baralhos com os pontos de Fibonacci, para que ningum da equipe influencie ooutro. Jogamos as cartas viradas para baixo e todos ao mesmo tempo viraramas cartas para cima, onde podemos realizar a analise dos pontos jogados.

Quando as cartas possuem valores iguais significa que a equipechegou a um consenso do tamanho do esforo, mas quando as cartaspossuem valores diferentes sinal que a equipe no esta fechada em umconsenso. Neste momento entra o Scrum Mster como um facilitador

perguntando a cada pessoa da equipe o porqu dos valores de suas cartas, oque cada pessoa est identificando de esforo a mais do que o outro colega detrabalho.

As duvidas, incertezas, requisitos que nos acreditamos ser verdadeiros econtidos no requisito de tamanho igual a Temas do requisito que est sendoestimado, nos devemos perguntar ao Product Owner, para que ele valide edeixe claro para a equipe a abrangncia do esforo necessrio.


17/61



No existindo mais duvidas as cartas so jogadas de novo e a equipebusca o consenso do esforo. O processo pode ser repetido quantas vezesforem necessrias, com o tempo a equipe acha o seu ponto de equilbrio nasestimativas.

importante sempre deixarmos como consenso do resultado doprocesso de Planning Poker as cartas de maior valor, para que todas aspessoas da equipe se sintam a vontade em executar o requisito estimado notempo que ela acredita ser exeqvel.

Exemplo de Pontos Contados

Tema Pontos

Cadastro de Clientes 2

Cadastro de Produtos 2

Carrinho de Compras 13

Busca de Produtos 2

Categoria de Produtos 1

Histrico de Compras 5

Rastreamento de uma Compra 8

Pagamento por Carto de Credito 8

Pagamento por Boleto Bancrio 13

Exportao de Dados p/ EPR 13

Total 67

Determinando o Tempo do Projeto

O primeiro passo para sabermos o tempo do projeto a definio dotamanho da nossa Sprint, lembrando que uma Sprint um tempo de trabalho,que pode ser de uma, duas, trs ou quatro semanas, mas uma vez definido otamanho da Sprint ela no deve ser modificada at o termino do projeto, parano termos que regramos grficos e informaes do projeto sobre o novotamanho da Sprint, o que ir gerar um re-trabalho.

A equipe junto com o Product Owner determina que a Sprint vai ser deuma semana. Uma vez sabendo o tamanho da Sprint perguntada a equipe aquantidade de pontos que a equipe consegue executar em uma Sprint. Estevalor est diretamente vinculado ao que tem que ser feito e a quantidade depessoas que a nossa equipe possui. Tambm neste valor est incluso o nossoprocesso de desenvolvimento do software, onde ele deve abranger tudo que fornecessrio, como testes de software, UML, documentao e o que for definidopela equipe e os interesses do cliente, representado pelo Product Owner.


18/61



A equipe definiu a quantidade de 10 pontos por Sprint, agora temoscondies de dar uma previso ao cliente do tempo necessrio para odesenvolvimento do sistema, bastando apenas pegar a quantidade de pontoscontados e dividir pela quantidade de pontos que a equipe capaz deexecutar. A quantidade de pontos que a equipe capaz de executar por Sprint a Velocidade da Equipe.

O resultado da operao matemtica chegou ao valor de: 67 / 10 = 6com resto de 7. Seis (6) a quantidade de Sprints necessrias para arealizao do projeto. Vamos arredondar para sete (7), pois temos o resto dadiviso. Sete semanas so iguais a aproximadamente dois meses de trabalho.

Podemos tambm realizar o calculo da Velocidade da Equipe com asinformaes coletadas aps a execuo da primeira Sprint e com este dadocalculamos o tempo de execuo do projeto.

Product Burndown Chart

Tambm conhecido como o grfico de ciclo de vida do projeto, que tem

o objetivo de mostrar como est o andamento do projeto inteiro.Colocamos no Eixo Y os pontos do projeto e colocamos no Eixo X a

quantidade de Sprints. Passamos uma reta mostrando a meta dos pontos aserem executados pela quantidade de Sprints do nosso projeto, respeitando aVelocidade da Equipe.

Uma segunda linha gerada a cada execuo de Sprint, com o objetivode mostrar se a nossa meta foi alcanada ou no. A cada execuo de Sprint anossa velocidade pode ser recalculada e conseqentemente o tempo doprojeto passa a sofrer alterao.

Este grfico fica muito bem disponibilizado em uma parede do lado da

equipe de desenvolvimento. Quando todas as pessoas envolvidas no projeto,direta ou indiretamente aprenderem a ler este grfico no existe mais anecessidade de responder aos interessados a pergunta: Como est indo oprojeto de Venda de Livros pela Internet?, pois a informao estdisponibilizada a todos, permitindo uma comunicao direta e rpida. Se oescopo do projeto passa a sofrer alteraes o grfico sofre a necessidade deser atualizado, mas este item vai ser visto melhor nos prximos tpicos destematerial.


19/61



Ilustrao 4 - Product Burndown Chart


20/61



Priorizao e Distribuio de Requisitos por Sprints

A priorizao do Backlog realizada pelo Product Owner. Estpriorizao realizada com o objetivo de selecionar os principais requisitospara construo.

Em Scrum a priorizao fundamental para a reduo do risco decancelamento do projeto, pois quanto mais rpido for entregue o que realmente importante ao Produtct Owner, menor o risco do projeto ser cancelado.

A priorizao faz com que o comprometimento do Product Owner sejamuito forte, pois o Product Owner o responsvel pelo retorno do investimento(ROI) e desta maneira ele que tem que ter a viso clara dos requisitos querealmente devem ser feito antes dos outros.

Com a priorizao nos passamos a ter um Tema do sistema, comoCadastro de Clientes, tendo seus requisitos sendo executados conforme odesejo do Product Owner e no todos os requisitos sendo executados de umanica vez.

Com este modelo de trabalho um Tema passa a receber maisfuncionalidades durante todo o desenvolvimento do projeto.

Executando a Priorizao

Uma boa tcnica a MoSCoW, onde os requisitos so distribudos porSprint respeitando a priorizao.


21/61



Ilustrao 5 - Priorizao com MoSCoW

Devemos executar primeiro todos os requisitos Must, isto Tem queter do nosso projeto. Quando no existir mais requisitos Must atacamos osrequisitos Should e assim por diante, at o termino de todos os requisitos queo nosso projeto possui.

Um ponto importante do Scrum, a cada nova Sprint o Product Ownertem a liberdade de escolher os requisitos que vo ser executado na Sprint.Com esta liberdade a priorizao dos requisitos no projeto planejada Sprint aSprint e nunca uma vez so no inicio do projeto.

Com a definio de prioridades dos requisitos que devem serexecutados a cada Sprint o Product Owner busca o resultado em seu ROI

(retorno de investimento), pois o cliente est recebendo sempre o que maisimportante para ele a cada Sprint.


22/61



Sprint, Planejamento da Sprint #1, Planejamento da Sprint #2,Sprint Burndown Chart e Execuo da Sprint

Tarefas

so em

Horas

Planejamento

da Sprint #2

11SM EQ

Montar Sprint

Burndown

Chart

12

SM

A execuo do projeto realizado em perodos de tempo que nsdenominamos de Sprint. Uma Sprint tem perodo maximo de tempo igual a 30dias e o perodo menor de tempo igual a uma semana.

Dentro de uma Sprint nos temos que executar o Framework do Scrum,com o planejamento da Sprint, as reunies dirias, a entrega do que foirealizado no final da Sprint e a Retrospectiva, que uma reunio de melhoriado processo pela equipe.

Devemos respeitar o perodo de tempo da Sprint como uma regrainegocivel, onde mesmo no tendo realizado todas as atividades necessriasda Sprint nos terminamos a mesma, para que mesmo com uma entrega parcialdos resultados obtidos, seja realizada a entrega.

importante sempre entregarmos o servio realizado na Sprint, mesmoque este servio no tenha sido concludo em sua totalidade.

A quantidade de servios, isto , requisitos que vamos implementardentro de uma Sprint determinada pela equipe e nunca pelo Product Owner.Quem vai realizar o trabalho deve se comprometer com a quantidade deservio que vai realizar e nunca se comprometer com o servio que foideterminado por outra pessoa.


23/61



Um dos segredos da Sprint est neste comprometimento, quando aequipe acredita que possvel realizar os requisitos acordados existe umaprobabilidade maior de recebermos o que foi combinado.

melhor trabalharmos com a realidade da velocidade de nossa equipedo que com o desejo que temos de velocidade. Uma equipe que sofre pressopara aumentar a velocidade acaba abrindo mo de alguma coisa e quasesempre o que a equipe abre mo da qualidade, para que ela possa atender avelocidade esperada.

O problema de abrir mo da qualidade que os requisitos e suas tarefasacabam no sendo fechados e retornam para a linha de produo. O nossoProduct Backlog acaba recebendo os erros gerados durante o desenvolvimentodas Sprint e os itens ainda no implementados. Est entrada de servios comdefeito acaba fazendo com que a equipe pare de desenvolver novos requisitose gaste energia na correo de requisitos j implementados e que esto comdefeito, o que pode levar o projeto a um fracasso.

Planejamento da Sprint #1

A reunio de planejamento da Sprint realizada com a Equipe e oProduct Owner e tem o objetivo do Product Owner apresentar a equipe osrequisitos que vo ser desenvolvidos na Sprint.

Este planejamento realizado com todos os integrantes da equipe dedesenvolvimento do projeto, onde passamos a ter analistas de sistemas,desenvolvedores, testadores, DBA, web-design e quem mais for necessrio.

Com a unio de todas estas especialidades passamos a ter um ganhomelhor de analise de sistemas e uma viso mais critica de como devemossolucionar os requisitos com a unio de todas ests especialidades. Oconhecimento tambm passa a ser compartilhado o que reduz os riscos da

perda de uma pessoa na equipe, independente do motivo. Tambm nestaunio de profissionais passamos a distribuidor e potencializar habilidades atodos, onde a ao de analise de sistemas passa a ser aprendida e realizadapor todos os profissionais.

Um dos grandes segredos desta reunio o Product Owner j vir comos requisitos bem definidos, para que a equipe tenha uma compreenso bemabrangente do que deve ser feito com o requisito.

o que eu chamo de requisitos quadrados e requisitos redondos, ondeum requisito quadrado aquele que no tem uma clareza na sua definio efaz com que a equipe tenha dificuldade de achar as tarefas necessrias para asua implementao e durante a execuo do requisito ele gera vrios

impedimentos. Estes impedimentos podem levar a equipe inclusive a umaimplementao parcial do requisito o que leva a uma no entrega do mesmo.

J os requisitos redondos a equipe consegue no planejamento umentendimento claro do seu objetivo, o que leva a uma definio muito boa dastarefas a serem realizadas e permite um desenvolvimento sem duvidas. Osrequisitos redondos aumentam a velocidade de desenvolvimento do sistemapela equipe, isto , ao invs de pressionarmos a equipe para uma velocidade


24/61



maior, devemos entregar a equipe requisitos melhores, que permitira umaumento de velocidade com qualidade do produto gerado.

Planejamento da Sprint #2

O planejamento da Sprint #2 passa a ser realizado apenas pela equipe,

sem a necessidade do Product Owner. Este planejamento tem o objetivo dedeterminar como vamos realizar os requisitos, isto , como vamos transformaro que foi recebido em forma de requisitos em software.

Nesta reunio definimos de maneira rpido como pode ser a tela de umsistema, o modelo de dados em auto-nvel, as classes necessrias a seremdesenvolvidas, as regras de negocio, etc.

Cada item identificado como sendo parte da soluo do requisito passaa ser chamado de tarefas e estas tarefas recebem uma estimativa de horas.

Uma boa pratica e ter tarefas com o tempo de no mnimo de 1 hora e deno maximo um dia de trabalho. Se tivermos tarefas menores de uma hora elaspodem ser agrupadas, para chegarem ao tempo de 1 hora. Uma boa dicatambm agrupar as tarefas para meio perodo de trabalho, isto , em um diade 8 horas meio perodo seria de 4 horas. Desta maneira no perdemos tempocom estimativas de tarefas pequenas, deixando elas agrupadas e rotuladascom um conjunto de horas. Tambm ter agrupamento de tarefas faz com queos integrantes da equipe peguem trabalho sempre para um perodo de tempoou um dia inteiro, no sendo necessrio o seu deslocamento para pegartrabalhos durante o seu dia de trabalho.

Um requisito passa a ter varias tarefas e cada tarefa passa a receber otempo necessrio para o seu desenvolvimento. A totalizao das horasnecessrias para a completude dos requisitos selecionados para odesenvolvimento da Sprint faz com que a equipe saiba se os itens

selecionados para trabalho so suficientes para o tempo existe ou maior,menor que o tempo que temos de trabalho.

Sprint Burndown Chart

Sprint Burndown Chart o grfico que mostra como est a execuodas tarefas dentro de uma Sprint.

Ns temos no Eixo Y a quantidade de horas necessrias para aexecuo da Sprint e no Eixo X o numero de dias da nossa Sprint. A nossavelocidade a quantidade de horas que a nossa equipe consegue executar pordia.


25/61



Ilustrao 6 - Sprint Burndown Chart

Calculo de Velocidade da Sprint

Ilustrao 7 - Calculo da Velocidade da Equipe na Sprint

A capacidade de produo da nossa equipe de 110 horas por Sprint e22 horas por dia. A quantidade de horas das tarefas identificadas no nossoPlanejamento de Sprint #2 no deve ser superior a 110 horas. Ns podemoster mais de 110 horas de tarefas na Sprint, mas isso so ocorre quando a equipeacredita ser capaz de executar s 110 horas mais o excedente.

Exemplo de Tarefas na SprintRequisito em Tema Requisitos em Historias Tarefas por Historias

Cadastro de Clientes Endereo do Cliente Validar CEP;

Validar camposobrigatrios;


26/61



Endereo de Entrega Copiar o endereo docliente;

Validar CEP;

Validar camposobrigatrios;

Pode ser diferente doendereo do cliente;

Telefones de Contatos Tipo de telefone (celular,fixo, faz);

Pessoal ou trabalho;

Telefone principal paracontato;

DDD;

Numero do telefone.

Histrico de Compras Este item um outrotema de historia e deveser tratado como tal.

Exemplo de Ciclo de Vida de Uma Sprint

O exemplo do ciclo de vida de uma Sprint apresentado tem o seu inicioem uma segunda feira, mas o inicio da Sprint pode ser em qualquer dia dasemana. Tambm neste exemplo foi definido um perodo de trabalho de 8horas, tendo o perodo da manha e o perodo da tarde, mas pode ter projetos

com perodos noturnos ou de apenas um perodo.Tambm foi colocada a reunio diria no horrio da manha, mas ela

pode ser realizada em qualquer horrio do dia, horrio este que tem que serdefinido com os integrantes da equipe.


27/61



Ilustrao 8 - Sprint de 2 Semanas

Ilustrao 9 - Sprint de 1 Semana


28/61



Executando a Sprint

Aps o planejamento da Sprint #1 e #2 a equipe pode iniciar o processode execuo da Sprint. Os requisitos e suas respectivas tarefas so colocadosno quadro de Taskboar, tambm chamado de quadro de Kanban.

Todo dia realizada uma reunio de alinhamento da Sprint, que vai ser

vista no tpico Reunio Diria. A execuo dos Requisitos deve ser realizadacom o conceito Todos Contra Um, onde a equipe inteira ataca o primeirorequisito, isto , suas tarefas.

Caso no tenha servio para todos, o segundo requisito aberto e osintegrantes da equipe que no estavam trabalhando no primeiro requisito vopara o segundo. Caso no tenha servio para todos, o terceiro requisito aberto e assim por diante.

Quando um requisito terminado ou no existe tarefa para todos, oprocesso de ajudar no prximo requisito ou abrir um novo requisito deve serseguido.

A tcnica de Todos Contra Um faz com que tenhamos ao termino daSprint sempre requisitos prontos para serem entregues. Quando colocamosuma pessoa em cada requisito, isto , Cada um por si ao termino da Sprintcorremos o risco de termos todos os requisitos 90% pronto, mas nenhumrealmente pronto.

Um ponto importante do Todos Contra Um que a equipe em Scrumrealmente uma equipe, no buscamos mais o individualismo e sim o coletivo.No existe mais o melhor desenvolvedor, o melhor arquiteto, o melhor testador,existe a equipe, que vai ser forte ou fraca pela unio do grupo.

Ilustrao 10 - Todos Contra Um

comum aparecer requisitos novos durante a execuo da Sprint queest sendo executada.

Requisitos novos so ocasionados por uma analise superficial dosrequisitos da Sprint, ou por uma necessidade nova do Product Owner. Orequisito no planejado ocasionado por uma analise superficial, um alerta que


29/61



no devemos jamais deixar de lado o bom trabalho de analise de sistemas.Estes requisitos no planejados vo atrapalhar a execuo da Sprint porintermdio de um impedimento de falta de definio de como o sistema deve secomportar.

Mas quando um requisito novo entra na Sprint, independente do motivo,ele deve ser colocado em um espao visvel e bem sinalizado, para que todosos envolvidos no projeto saibam que demandas novas esto consumindoenergia da equipe de desenvolvimento. Estas demandas no previstas podemlevar a uma entrega parcial dos requisitos acordados pela Equipe com oProduct Owner no inicio da Sprint.

Ilustrao 11 - Taskbord ou Kanban

A equipe tem autonomia de executar as tarefas do quadro de Taskboard,

no sendo necessrio uma pessoa ficar atribuindo estas tarefas as pessoasque vo executar.

Est autonomia ocorre porque desde o inicio do projeto todos osintegrantes da equipe de execuo do projeto estavam juntos entendendo oque deve ser feito. Tambm estavam juntos no Planejamento da Sprint #1 e #2.No existe necessidade de um controle manda faz, a equipe sabe o que deveser feito e no ter um controle sobre a equipe neste momento, potencializa acapacidade de execuo da mesma.

O controle dentro da Sprint passa a ser compartilhado por todos daequipe, no ficando a responsabilidade para uma pessoa. Isso o que noschamamos de auto-gesto.


30/61



Desenvolvimento e Reunies Dirias

uma reunio diria de acompanhamento de execuo do projetorealizada pela equipe. Nesta reunio participa com direito a falar apenas osdenominados porcos, frangos podem participar, mas no tem direito a falarnesta reunio.

Esta reunio deve ter no mximo 15 minutos de durao e deve serconduzida pelo Scrum Master. Recomenda-se que esta reunio seja realizadano perodo matutino, bem no inicio das atividades da equipe. Tambmrecomenda-se que os participantes fiquem de p. Esta reunio no parasoluo de problemas e sim de sincronismo entre os membros da equipe decomo est indo a execuo das atividades realizadas no Sprint.

Ilustrao 12 - Perguntas na Reunio Diria

Sete Fundamentos para reunies dirias eficazes

(Standups) by Stacia L. Broderick

O TIME acredita em auto-gesto e torna possvel a sua existncia.

Todos da equipe esto comprometidos (como um time!) para as metasdo Sprint.

Eles percebem a importncia da comunicao e esto utilizando o DailyScrum para ajudar a facilitar esta comunicao.

A equipe compreende e aceita que a ordem de, dependncias entre, enecessidades das tarefas ir mudar diariamente ao longo do ciclo doSprint. As reunies dirias da equipe permitem gerenciar essasmudanas e reagir em conformidade.


31/61



O TIME tem um lder efetivo "ScrumMaster" ou um lder que lhescompartilha permisses (poderes) para que eles possam tomar decisese assumir responsabilidade com credibilidade.

O TIME percebe a importncia de tornar o trabalho mais visvel;transparncia melhora a natureza do relacionamento entre o TIME e oresto da organizao, resultando em nveis mais elevados de confianae colaborao.

O TIME ir recordar durante os Eventos-marco de Processos(milestones) as definies tomadas durante a reunio diria (dailystandup meeting) para tornar estes eventos o mais efetivo possvel.

Impedimentos

Impedimento qualquer coisa que atrapalhe um membro da equipe deexecutar o trabalho. Os impedimentos podem ser identificados nas reuniesdirias, onde cada membro da equipe tem a oportunidade de comunicar oScrumMaster do impedimento existente. O ScrumMaster responsvel pela

soluo dos impedimentos. O ScrumMaster pode realizar reuniescomplementares para solucionar os impedimentos identificados quando asreunies dirias no permitirem a soluo.

Um dos fatores de potencializao da equipe Scrum est na ao deretirar da equipe de execuo do projeto a responsabilidade de resolver umimpedimento. Se deixarmos a equipe de execuo do projeto focado apenas naexecuo e passarmos todos os impedimentos ao Scrum Mster vamos ter umganho de velocidade e qualidade na execuo dos trabalhos.

Dia a Dia da Reunio Diria

Este o nosso momento de alinhamento das atividades executadas dosnossos requisitos. Mas alem do alinhamento o momento que temos delembrar as nossas metas. Nesta reunio vale a pena sempre lembrar ouperguntar para a equipe qual a nossa meta da Sprint, para que todos sempresaibam o valor de negocio que estamos implementando ao produtodesenvolvido.

Nossa meta no apenas fazer algoritmo e sim algoritmos alinhadoscom a expectativa do Product Owner, que est trazendo ganho ao sistemadesenvolvido.


32/61



16

Sprint Review

PO SM EQ

Review

Review, tambm conhecido como entrega dos trabalhos realizados naSprint pela equipe de execuo do projeto para o Product Owner.

A entrega dos trabalhos realizados ao Product Owner no deveria tersurpresas para o mesmo, se nos temos um Product Owner presente durante o

ciclo de desenvolvimento da Sprint, ele sabe o que nos estamos entregando eo que no estamos entregando. Ele tambm sabe os problemas que a equipeteve durante a execuo da Sprint, no sendo necessria a apresentao deum dirio de bordo com o check list de tudo que deu errado e que levou auma entrega parcial dos trabalhos.

Na reunio de entrega ser apresentado ao Product Owner o softwaredesenvolvido para que ele aceite ou no as funcionalidades implementadas, osgrficos, os requisitos selecionados para a Sprint, o que foi feito, o que no foifeito e caso o Product Owner so tenha participado ativamente da Sprint,devemos ter o dirio de bordo com os problemas que a equipe passoudurante a execuo da Sprint.

Uma boa dica para a realizao da entrega do software a equipe tertestado as funcionalidades antes de realizar a entrega, ter testado o ambienteque o sistema vai rodar e manter o foco na entrega de funcionalidades e nona evoluo do sistema que est sendo entregue. Devemos entregar o que foiacordado com o Product Owner, isto , requisitos implementados aderentes aoque nos foi passado.


33/61



SprintRetrospective

17PO SM EQ

Retrospectiva

A retrospectiva da equipe tem o objetivo de realizar uma melhoriacontinua no processo de desenvolvimento de software que a equipe estadotando. Est reunio realizada ao termino da Sprint, preferencialmenteaps a reunio de entrega (Review) ao Product Owner.

Eu particularmente gosto de colocar na retrospectiva todos os problemasque esto influenciando o projeto, tanto tcnicos, quanto processuais ou atemesmo de conflito entre integrantes da equipe.

neste momento que temos a oportunidade de resolver os problemasenfrentados durante a execuo de nossa Sprint e tomarmos aes realmenteefetivas para que estes problemas no ocorram mais.

Existem varias tcnicas para a realizao de uma retrospectiva, vamosmostrar apenas duas, mas tenho certeza que ests duas tcnicas vo ser maisdo que suficiente para uma boa retrospectiva de sua equipe.

Linha do Tempo (Timeline)

Propsito

Estimular lembranas do que aconteceu durante o desenvolvimento dotrabalho. Criar uma imagem do trabalho de muitas perspectivas. Examinandohipteses sobre quem fez o qu e quando. Ver padres ou quando os nveis deenergia mudaram. Use esse recurso para "apenas os fatos" ou fatos esentimentos.

Tempo Necessrio

Trinta a noventa minutos, dependendo do tamanho do grupo e otamanho das atividades executadas.

DescrioA equipe escrever cartas (post-its) para representar as lembranas, que

foram significativas para eles, ou outro evento significativo durante a iterao, aliberao, ou projeto e depois public-las em (aproximadamente) por ordemcronolgica. A retrospectiva apia o lder da equipe para discutir osacontecimentos e compreender os fatos e sentimentos durante a iterao,libertao, ou projeto.

Passos


34/61



[1]

Inicie a atividade, dizendo "Ns iremos preencher (completar) uma linhade tempo para criar uma figura completa desta iterao / release / projeto. Nosdesejamos identificar a perspectiva de cada colega de trabalho.

[2]

Dividir a equipe em pequenos grupos, no tendo mais que cincopessoas por grupo. Manter as pessoas que trabalharam em estreitacolaborao com todos os outros juntos (afinidade por grupos). melhor terdois pequenos grupos que representam uma afinidade do que um grandegrupo.

Todos devem pegar os post-its ou canetas, etc.

Certifique-se que cada pessoa tem uma caneta. Devemos lembrar aspessoas para escrever de maneira legvel, para que todos possam ler os post-its.

[3]

Descreva o processo.Pergunte as pessoas sobre o que ocorreu na iterao / release / projeto,

resgatando todos os pontos memorveis, significativos, eventos importantes,coisas ruins e registre esta informao em post-its um abaixo do outro. Cadapost-its s pode ter uma informao.

Relembre ao grupo que o objetivo de identificar muitas perspectivas.Caso no exista consenso sobre algum dos itens identificados em post-its notem importncia, pois se o item for importante para pelo menos uma daspessoas da equipe, j suficiente para o seu registro.

A atividade deve durar no mximo 10 minutos.

Pode ser utilizado post-its com cores diferentes, mas deve ser colocadauma legenda que explique o significado de cada cor.

Escrever em letras legveis.

[4]

Monitorar a atividade dos debates e a escrita dos post-its. Tomarcuidado para que a atividade consuma muito tempo de debate e desta maneirano gere post-its, caso isso ocorra lembre a equipe que deve iniciar o trabalhode escrever os registros nos post-its.

Quando o grupo j tiver uma pilha de cartes (post-its), convidar aspessoas para comear a public-las (veja a Figura).

[5]Quando todas as cartas (post-its) esto destacadas, convidar a equipa a

analisar a linha de tempo e ver o que outros j publicaram. Aps a verificaodos itens publicados, solicite para as pessoas adicionarem novos cartes, casoalgum lembre de algum evento importante e que no foi registrado.

[6]

Permitir uma pausa antes de realizar a analise da linha do tempo.


35/61



Variaes

possvel utilizar algumas variaes sobre a atividade de linha dotempo. Estas possibilidades podem ser de utilizar materiais como cartes, post-its, canetas coloridas, pontos, etc. Existem diversas formas de estimular oresgate dos fatos e sentimentos ocorridos durante a execuo do projeto.

Por exemplo: Cores para representar Sentimentos: Para se utilizado tanto para fatos e

sentimentos para representar estados emocionais.

o Azul = tristeza, raiva, mau

o Vermelho = desafiado, estagnou

o Verde = satisfeito, bem sucedido, energtico

o Amarelo = cauteloso, confuso

o Purple = diverso, surpresa, humor

o Salmo = fatigados, sublinhou

Cores para representar Eventos: Para ser utilizado para representartipos de eventos.

o Amarelo = tcnica ou tecnologia relacionados

o Pink = equipe ou pessoas relacionadas

o Verde = organizao relacionados

Cores para representar Funes: Para ser utilizado para representarfunes (Papeis no projeto).

o Azul = desenvolvedores

o Pink = clientes

o Verde = GQ e ensaios

o Amarelo = escritores tcnicos

Cores para representar Temas: Para ser utilizado quando a equipepretende concentrar em assuntos especficos, usar cores para identificareventos relacionados a temas especficos.

o Amarelo = equipe comunicao

o Azul = equipamento de utilizao

o Pink = relacionamentos com os clientes

o Verde = prticas de engenhariaVoc pode escolher o seu prprio esquema de cores com base nos

cartes e post-its disponveis para voc.

Materiais e Preparao

Quadro branco, papel de parede, fitas, canetas coloridas, post-itscoloridos, etc


36/61



Ilustrao 13 - Retrospectiva Linha do Tempo

Ilustrao 14 - Legenda Utilizada na Linha do Tempo

Resumo do Abu

Material

o Quadro

Organizao

Produtividade

Processo (Scrum)

Riscos

Tecnologia

Emocional

Evento

Sentimento


37/61



o Canetas Coloridas

o Post-its

Execuo

o Dividir as pessoas em equipes

o

Definir legenda dos carteso Executar a atividade de criar os cartes

o Criar uma coluna para todos os post-its e colar todos os post-itsnesta coluna

o Reviso da equipe para identificar se no falta nenhum evento ousentimento

o Dividir os post-its em colunas que representam as Sprints /Iteraes / Meses, etc

o Criar um espao abaixo das colunas para a adio de um grficoemocional

o Cada integrante da equipe desenha uma linha que represente oseu estado emocional no perodo (sprint)

Legenda

o Verde = Tecnolgico

o Amarelo = Emocional

o Salmo = Organizao

o Rosa = Produtividade

o Azul = Processual

o Roxo = Riscos

Retrospectiva Rpida

Est a segunda tcnica de retrospectiva que vou apresentar, maissimples e mais rpido de ser executado.

A tcnica simples, colocamos trs colunas na parede, contendo aspalavras Continuar, Melhorar e Parar e todos da equipe escrevem os post-its contendo apenas um Evento e o Evento escrito deve ser colocada nacoluna correspondente.

As colunas podem ser preenchidas simultaneamente ou coluna a coluna,

conforme a conduo do Scrum Mster.Continuar o que nos fizemos na Sprint e que vale a pena ser repetido

para as demais Sprint, at o momento que continue agregando valor aoprocesso.

Melhorar o que no est bom, mas importante para o processo edesta maneira no pode ser removido das atividades que realizamos nasnossas prximas Sprints.


38/61



Parar o que estamos executando durante a Sprint e no estagregando valor nenhum ao processo, simplesmente no serve para nada edesta maneira no deve ser repetido para as prximas Sprint, pois estconsumindo tempo da equipe e o processo ou produto no est ganhandonada com a sua execuo.

Ilustrao 15 - Retrospectiva Simples

Dia a Dia Aps a Retrospectiva

O documento gerado com o resultado da Retrospectiva deve seradicionado em local que permita a sua visualizao por todos da equipe.

Devemos lembrar todos os dias o que estamos buscando na nossa melhoria deprocesso e est busca por ser feita com as informaes disponveis a todos edentro da reunio diria.


39/61



Montar

Release

Burndown

Chart

8

PO SM

Release (Verses)

Release ou verso de software o nosso planejamento de entregas defuncionalidades. Em Scrum para a equipe de desenvolvimento do sistema oque nos buscamos so metas pequenas e possveis de serem exeqveis.

Porem para o Product Owner o que nos planejamentos so alocaes derequisitos distribudos ao longo do projeto, para que o Product Owner saibaquando ele vai ter disponvel a funcionalidade desejada.

Planejamento em Camadas

Estratgia

Portflio

Produto

Release

Sprint

Dia

Estratgia

Portflio

Produto

Release

Sprint

Dia

Ilustrao 16 - Planejamento de uma Release

O planejamento em camada de cebolas representa estes dois extremos,o planejamento da equipe de execuo e o planejamento do Product Owner.As duas extremidades so conduzidas at o encontro de ambas.

Quando a equipe planeja a sua Sprint, identifica as suas tarefas eexecuta as tarefas seguindo o seu planejamento ela esta direcionando oprojeto ao encontro dos interesses do Product Owner com o seu planejamento.


40/61



O foco do planejamento da equipe deve ser sempre metas exeqveis.Nos no focamos uma entrega do projeto inteiro ou de uma verso e simpassamos a focar as tarefas existentes em um requisito, os requisitosexistentes em uma Sprint. A equipe pensar em um planejamento de longoprazo de tempo faz com que a mesma perca o ritmo, isto , velocidade.

As tarefas quebradas em horas de no maximo um dia de trabalho fazcom que todos os integrantes da equipe ao executarem as suas tarefas do dia,j estejam mantendo o planejamento para a entrega total do projeto no perodoacordado com o Product Owner.

Ilustrao 17 - Sprint's por Releases

O Product Owner ao pensar em uma Release ele deve manter o foco noretorno de investimento que ele est realizando. Eu costumo dizer que entraum saco de dinheiro e do outro lado sai algoritmo implementado. Se oalgoritmo implementado no era o que o Product Owner desejava ele no vaiver ganho nenhum no que recebeu.

Valor de negocio, para obter um retorno de investimento sempre vaiestar nos olhos do Product Owner.


41/61



Scrum de Scrum

Scrum de Scrum a ferramenta que nos temos de realizar umalinhamento, sincronismo entre projetos.

Se voc perguntar a um integrante de um projeto A qual o projeto maisimportante na empresa ele ir responder que o projeto dele. Se vocperguntar a um integrante de um projeto B, ele tambm ir responder que oprojeto mais importante o dele.

No tem nada de errado com as respostas obtidas, muito pelo contrario,cada integrante de um projeto tem que ter a convico que o seu projeto omais importante para a empresa.

comum durante a execuo de projetos termos a necessidade de

ajuda para que o nosso projeto continue atendendo as expectativas do ProductOwner. Existem impedimentos que dentro de uma estrutura funcional de umaempresa o Scrum Mster no ter condies de resolver e ele necessitaescalar o problema para uma hierarquia funcional. Um bom exemplo anecessidade de recursos externos, pessoas de outras equipes ou um recursoque dever ser terceirizado. neste momento que o Scrum de Scrum vemajudar.

Scrum de Scrum funciona com a reunio de Scrum Mster paraalinhamento dos projetos, solicitaes de ajuda, visibilidade do caminho que aempresa est seguindo, remoo de impedimentos que o Scrum Mster noconsegue resolver sozinho e o que mais for necessrio.

O Scrum de Scrum tambm permite a troca de experincias, isto , oque uma equipe est fazendo que est dando certo ou errado, para quemodelos possam ser seguidos pelas demais equipes ou evitados por elas.

A execuo do Scrum de Scrum pode ser realizada todos os dias comouma reunio diria ou por perodos de tempo.

Tem empresas que preferem realizar no primeiro momento do dia areunio de Scrum de Scrum e depois desta reunio realizar as demais reuniesdirias das equipes, para que as informaes possam ser transmitidas a todos.Isso permite um alinhamento da empresa em um curto perodo de tempo.

J tem empresas que preferem aps a reunio diria das equipes, paraque os problemas sejam passados e o processo de soluo seja iniciado no

mesmo dia.Um Scrum de Scrum utiliza todas as ferramentas do Framework do

Scrum para gerenciar os projetos que esto nas equipes, uma tima maneirade gerar informao para levar as pessoas interessadas, que podemosmaterializar como exemplo: gerentes funcionais das mais diversas reas daempresa, diretrios, presidentes, clientes, etc.


42/61



Ilustrao 18 - Scrum de Scrum


43/61



Potencializando Scrum

A potencializao do processo Scrum j foi comentada neste material,mas no custa enfatizarmos mais um pouco sobre o assunto.

Jeff Sutherland um dos criados do Scrum, escreveu um artigo fantsticosobre a unio de Scrum e CMMI nvel 5, onde o artigo traz uma serie deprocedimentos necessrios para que este casamento seja possvel. Estesprocedimentos para atendimento do CMMI nvel 5 no fazem parte do escopodeste material.

Mas um destes procedimentos est a potencializao do Scrum para oque ele chamou de Entendendo o Sucesso do Scrum.

Jeff traz o conceito de Pronto e Feito, onde Pronto so requisitospossveis de serem implementados e Feito o requisito desenvolvido

conforme os critrios de aceitao do Product Owner.O Feito a nossa coluna de Done de um quadro de Kanban (tambm

chamado de Taskboard), que definido entre a equipe e o Product Owner.

Para aumentar a velocidade da equipe com os requisitos Prontos, osmesmos so escritos pelo Product Owner com o auxilio do Scrum Mster, elesjuntos realizam um trabalho de preparao do material da prxima Sprint equando este material chega ao planejamento da Sprint ele possui um nvel dematuridade maior, para que a equipe possa realizar a analise de sistemas domesmo e o seu planejamento de execuo.

Jeff faz a observao que: Pronto e Feito so simples de entender, mas

difcil de ser realizado e O segredo est no balanceamento apropriado entre oplanejamento e a execuo de atividades.

O link do material :

http://jeffsutherland.com/scrum/PracticalRoadmapMunich20091020.pdf

Os requisitos Prontos o que eu chamei neste material de requisitosquadrados e redondos. Onde um requisito quadrado traz problemas na analisede sistema, planejamento e execuo. J os requisitos redondos permitem asua analise, planejamento e execuo em velocidade e qualidade pela equipede desenvolvimento do projeto. Toda vez que um requisito quadrado entra naexecuo da Sprint ele um candidato a gerar impedimentos e

conseqentemente trazer problemas na execuo da Sprint, trazendo impactona velocidade de produo da equipe.


44/61



Ilustrao 19 - Trabalho em conjunto entre Product Owner e Scrum Mster


45/61



picos, Temas e Historias

Carto de Historia

Cartes de histria uma tcnica de captura de requisitos de sistemas,esta tcnica surgiu com a metodologia de desenvolvimento chamada de XP(extreme programming), porm podemos utilizar esta tcnica com qualquermetodologia de desenvolvimento de sistemas geis.

Como Cartes tm o objetivo de capturar os requisitos, eles seconcentram em quem, o qu e porqu de um recurso, e no como. Nesteponto ele igual a varias tcnicas de levantamento de requisitos, onde

tentamos identificar o que tem que ser feito e no como ser feito.O carto de histria tem que ser escrito a partir de uma perspectiva do

usurio. Desta maneira o carto no deve possuir jarges tcnicos ouinformaes de design, ou qualquer outra coisa que no seja informaes denegcio. Um carto deve ser escrito com a linguagem no negcio, para queseja compreendido por todos.

Exemplo de Carto de Historia

Como um professor, eu gostaria de lanar as notas de meus alunos, para que os

alunos possam saber como esto indo na minha matria.

Como um aluno, eu gostaria de visualizar as minhas notas de modo que eu

possa saber o meu desempenho nas disciplinas.

Observe que em ambos os casos estamos buscando um linguajar denegcio e buscando as necessidades do sistema (em nvel de negcio o quetem que ser feito), mas em nenhum dos exemplos entramos em umalinguagem tcnica e nem falamos como vamos fazer.

Template de Carto de Historia

Como um [usurio papel], quero [meta], para que eu possa [motivo].

A primeira vista podemos achar que a parte do [motivo] no necessria, mas a utilizao do [motivo] nos leva a um entendimento melhor doobjetivo pelo qual o carto til. Ele nos ajuda a entender melhor como orequisito funciona e nos da uma idia melhor para outras caractersticas dosistema.


46/61



Em Scrum ns buscamos identificar os cartes no incio do projeto, paraque ele de origem ao Procuct Backlog. Com os cartes identificados podemosdar origem a priorizao e a estimativa dos mesmos.

Uma vez os cartes priorizados para execuo em uma Sprint elesdevem ter os seus detalhes (tarefas) identificados. No devemos identificar osdetalhes de cartes que no fazem parte da Sprint, desta maneira evitamos ogasto de energia na Sprint corrente em trabalhos que fazem parte de outromomento temporal.

Organizando Cartes de Historia

Um carto de histria deveria ter pelo menos trs itens: Informaes docarto, dados de conversa com o usurio e testes de validao do carto.

Informaes do carto so: nome, descrio da histria, um nmero dereferencia, estimativa, etc.

Conversas so anotaes (lembretes) da histria e no umaespecificao completa. Estas anotaes servem de apoio para a obteno demais detalhes no momento de desenvolvimento, identificando como o softwaredeve funcionar. Tudo que ajude a explicar a funcionalidade deve ser colocadocomo um item de conversa. como um conjunto de palavras chaves, mas notem a necessidade de ficar restrito a uma palavra, pode ser colocada (escrito)como uma frase.

Confirmao (Testes) so os casos de testes no verso do carto. Ostestes possibilitam o entendimento melhor do carto, ajuda na busca decenrios que os usurios, desenvolvedores / analistas podem no ter pensado.Um carto (requisito) tem que ser possvel de ser testado.

Um carto de histria tem que possuir uma nica responsabilidade, ter

cartes de histria com mais de uma responsabilidade dificulta o entendimento,a estimativa e a priorizao. Cartes pequenos nos ajudam a realizar umaadministrao (gesto) do projeto.

Link de Referencia:

http://kw-agiledevelopment.blogspot.com/2008/01/user-stories-answers-on-postcard-please.html

http://kw-agiledevelopment.blogspot.com/2008/01/user-stories.html


47/61


48/61



Exemplos de Carto de Historia

Eu estou publicando uma relao de cartes de histria utilizados em umsistema de venda de livros pela internet. Estes cartes so apenas de exemplo.Eu tenho utilizado o tema Venda de Livros pela internet em meus treinamentosde Scrum.

Pode ser observado que alguns cartes possuem responsabilidadessimples e outros possuem uma complexidade muito maior.

MODELO: Como um [usurio papel], quero [meta], para que eu possa[motivo].

Clientes

Como um cliente, quero consultar os livros, para que eu possa encontraro produto que desejo comprar.

o Conversa: Titulo, ISBN, categoria, autor, gnero

Como um cliente, quero que o produto seja acompanhado com o valor

de desconto para compra a vista, para que eu tenha a visibilidade dadiferena monetria do produto a vista ou a prazo.

Como um cliente, quero que os produtos selecionados para comprafiquem armazenados como um carrinho de compras, para que eu possovisualizar todos os meus produtos e o preo total.

Como um cliente, quero que o sistema mostre o valor da postagem, paraque eu possa saber quanto vai ser a taxa de entrega.

Como um cliente, quero ter os comentrios referentes aos livrosconsultados, para que eu possa saber a opinio de quem j leu

Como um cliente, quero consultar a relao dos livros mais vendidos,

para que eu possa ter uma visibilidade dos livros preferidos pelomercado

Como um cliente, quero realizar o pagamento em bloqueto bancrio,para os pagamentos a vista

Como um cliente, quero realizar o pagamento por carto de credito, parapagamentos a vista e parcelados

Como um cliente, quero visualizar os produtos acompanhados por umafotografia, para que eu possa ter certeza que o produto que eu procuro

Como um cliente, quero ter acesso a uma rea privada, para que nestarea eu possa acompanhar a situao do meu pedido.

Como um cliente, quero ter acesso a uma rea privada, para que eupossa atualizar os meus dados pessoais

Como um cliente, quero ter acesso a uma rea privada, para que eupossa ter acesso as informaes de minhas compras anteriores

Como um cliente, quero ter os meus dados pessoais cadastrados, paraque estes dados possam ser utilizados como endereo de entrega dosprodutos


49/61



Como um cliente, quero poder determinar o endereo de entrega doproduto, para que eu defina o endereo do destinatrio

Administrador do Sistema

Como um adm, desejo cadastrar usurios para o sistema, para que eupossa ter controle das pessoas que possuem acesso as funcionalidades

Como um adm, desejo que o sistema gere log de todas as aesrealizadas no sistema, para que eu possa realizar um auditoria deincluso, alterao ou excluso de dados

Mdulo administrativo

Como um usurio administrativo, quero tirar um relatrio com a relaode produtos vendidos em um intervalo de tempo, para que eu possa tervisibilidade das vendas realizadas

Como um usurio administrativo, quero tirar um relatrio com omontante financeiro realizado por perodo, para que eu possa saber ofaturamento

Como um usurio administrativo, quero tirar um relatrio dos produtosmais vendidos, para que eu possa saber as tendncias do mercado

Como um usurio administrativo, quero cadastrar os parceiros(fornecedores), para que eu tenha informaes de contato

Como um usurio administrativo, quero importar a relao de novosprodutos fornecido pelo parceiro, para que eu no tenha que cadastraros produtos manualmente

Escopo do Projeto

Vamos fazer a definio das Categorias dos Cartes de Histria. Umprojeto possui um escopo e dentro deste escopo ns temos requisitos dotamanho de um pico, Tema ou Carto de Histria.


50/61



Ilustrao 22 - Escopo do Projeto

pico, Tema e Historia

pico um Carto de Histria muito grande.

Tema um conjunto de Cartes de Histria Correlacionados, isto , um carto de histria que possui vrios cartes de histria dentro dele mesmo,

mas que todas estas historias internas esto correlacionadas ao mesmoassunto.


51/61



Ilustrao 23 - pico com vrios temas e historias

Ilustrao 24 - Tema com as Historias correlacionadas

Trabalhando com Temas

Como trabalhar com cartes de Histria que possuem vrios requisitos?

Vamos pegar o exemplo:

Como um cliente, quero consultar os livros, para que eu possa encontraro produto que desejo comprar.

o Conversa: Titulo, ISBN, categoria, autor, gnero

Uma boa pratica sempre buscar o equilbrio das coisas, neste cartopodemos executar 2 tcnicas, onde a primeira gerar vrios cartes menores.

Exemplo: Como um cliente, quero consultar os livros por titulo, para que eu possa

encontrar o produto que desejo comprar.

Como um cliente, quero consultar livros por ISBN, para que eu possaencontrar o produto que desejo comprar.

Como um cliente, quero consultar os livros por categorias, para que eupossa encontrar o produto que desejo comprar.


52/61



Como um cliente, quero consultar os livros por gnero, para que eupossa encontrar o produto que desejo comprar.

Quebrar em cartes menores possibilita a criao de testes, oentendimento do carto e a negociao de escopo com o Product Owner.

A segunda tcnica deixar o carto original como ele est e por

intermdio de conversas identificarmos todos os detalhes (abrangncia) docarto.

Neste exemplo eu prefiro a primeira tcnica, no incio ele gera maistrabalho para a criao dos cartes com as funcionalidades mais granulares(unitrias), mas esta granularidade permite uma distribuio do servio pelaequipe, uma estimativa melhor, teste mais simples e negociao com o ProductOwner.

Exemplos de Testes criados para Cartes de Histria

Segue uma relao de exemplos de Testes para Cartes de Histria. Otemplate de como escrever os testes foi tirado do blog do Alexandre Magno.

Referencia: http://amagno.blogspot.com/2006/09/apresentandofdd.html

Template: [ao] [resultado] [objeto]

[Exemplo 1] [Carto de Histria]

Como um cliente, quero que o produto seja acompanhado com o valorde desconto para compra a vista, para que eu tenha a visibilidade da diferenamonetria do produto a vista ou a prazo.

[Testes] - Template: [ao] [resultado] [objeto]

Mostrar valor do desconto de venda a vista

Mostrar percentual do desconto de venda a vista

Mostrar o valor do produto sem desconto de venda a vista

Mostrar o valor do produto com desconto de venda a vista

Validar valor do produto maior que o valor do desconto para evitar umvalor de desconto maior que o valor de venda

Validar valor do produto maior que zero para evitar produtos sem preode venda

Mostrar valor do desconto de venda a prazo Mostrar percentual do desconto de venda a prazo

Mostrar o valor do produto sem desconto na venda a prazo

Mostrar o valor do produto com desconto na venda a prazo



53/61



Como um cliente, quero que os produtos selecionados para comprafiquem armazenados como um carrinho de compras, para que eu possovisualizar todos os meus produtos e o preo total.

[Observao] Carto de Histria muito grande, devemos quebrar emCartes menores e criar para cada Carto menor os testes correspondentes.

[Testes] - Template: [ao] [resultado] [objeto]- Cancelado


Como um cliente, quero que o sistema mostre o valor da postagem, paraque eu possa saber quanto vai ser a taxa de entrega.


Mostrar valor da postagem de correio para vendas realizadas na mesmacidade

Mostrar valor da postagem de correio para vendas realizadas no mesmo

estado Mostrar valor da postagem de correio para vendas realizadas em

estados diferentes

Mostrar valor da postagem de correio para vendas internacionais

Mostrar valor da postagem de correio para vendas isentas de taxa deentrega

Calcular valor da postagem de correio para cada produto existente nocarrinho de compras

Mostrar mensagem de erro para ceps invlidos

Mostrar mensagem de erro para ceps vazio[Exemplo 4] [Carto de Histria]

Como um cliente, quero ter os comentrios referentes aos livrosconsultados, para que eu possa saber a opinio de quem j leu


Mostrar comentrio realizado para livro

Mostrar mais de um comentrio realizado para o livro

Mostrar inexistncia de comentrio para um livro

Visualizar marcador de mais comentrios que o valor maximo permitidopara visualizao para o livro


Como um cliente, quero consultar a relao dos livros mais vendidos,para que eu possa ter uma visibilidade dos livros preferidos pelo mercado


Mostrar a relao dos 10 livros mais vendidos


54/61



Mostrar vazio a relao dos livros mais vendidos

Mostrar a relao dos livros mais vendidos conforme a customizao

Mostrar a relao dos livros mais vendidos com o valor de customizaode quantidade igual zero

Remover da relao dos livros mais vendidos os livros que possuemquantidade de venda inferior ao valor informado na customizao.

Este teste um forte candidato a carto de histria

Tambm nestes testes o conceito customizao apareceu, e esteconceito pode, ou melhor, deve dar origem a um carto de histria


Como um cliente, quero realizar o pagamento em bloqueto bancrio,para os pagamentos a vista


Gerar bloqueto com valor da venda

Checar se o valor do bloqueto igual ao valor da venda

Validar data de vencimento tem que ser igual a data de emisso dobloqueto

Gerar bloqueto para o Banco do Brasil

Gerar bloqueto para o Banco Caixa Econmica

Dica:

1 Padronizar os verbos, afinal mostrar e visualizar pode ter o mesmocomportamento.

2 Padronizar o objeto, desta maneira podemos j identificar nomesfortes que vo dar origem ao nosso modelo de domnio.


55/61



Templates de Documentos

Vou apresentar alguns documentos que eu criei para serem utilizados nonosso dia a dia de Viso do Produto, Planejamento de Sprint, Retrospectiva eReview.

Estes documentos devem ser adaptados realidade de cada projeto, apenas uma sugesto de uso.

Embora estes documentos no agreguem valor direto ao produto queest sendo desenvolvido, eles garantem uma comunicao e um certooficialismo na gesto do projeto. Termos o projeto bem documentado trazconfiana entre as partes. A documentao deve deixar claro o escopo, o quefoi acordado por Sprint, as entregas realizadas, as melhorias do processo de

desenvolvimento da equipe, as alteraes de escopo e requisitos e o que fornecessrio. A questo no deixar de documentar ou documentar ao extremoe sim a busca do ponto de equilbrio que permite o projeto fluir e ao mesmotempo termos os registros de como ele esta sendo executado.

Talvez alguns neste momento estejam achando este tpico destematerial inapropriado, mas eu como Gerente de Projetos e j tendo gerenciadovrios projetos como Gestor utilizando tcnicas do PMBOK ou como um ScrumMster de equipe, tenho a convico que melhor documentarmos do quedeixar de lado a documentao. No ter documentao mais cedo ou maistarde nos iremos nos arrepender de ter deixado de documentar e quando maisnecessitarmos no ter como recuperar os fatores histricos do nosso projeto.

Viso do Produto

Ata de Viso do Produto

Reunio: __/__/____

Participantes: ________, ________, ________, ________, ________,

Datas Importantes do Projeto

Final do Projeto: __/__/____

Release 1: __/__/____, Release 2: __/__/____, Release 3: __/__/____

Temas Apresentados

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

Expectativa de Temas por Release


56/61



_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

Critrios de Sucesso do Projeto

_________________________

Apostila Scrum

Documents

Transcript of Apostila Scrum