Apostila Curso Gp Scrum Divus-V1.1

Gestão de Projetos com SCRUM

WWW.DIVUS.COM.BR Av. Carvalho Leal, N. 1336 – Térreo Edifício Empresarial Objetiva – Cachoeirinha. Tel (92) 3631.9081


2

Copyright © 2012 Divus Tecnologia, todos os direitos reservados

SUMÁRIO

FIGURAS .................................................................................................................................................. 4

Liderança ................................................................................................................................................. 5

1.1. Entendendo Coaching ................................................................................................................. 5

1.2. O que não é Coaching ................................................................................................................. 5

2. Facilitação ........................................................................................................................................ 6

3. Introdução a Agilidade .................................................................................................................... 6

3.1. Os Princípios do Manifesto Ágil .................................................................................................. 7

3.2. Alguns Pontos Fundamentais sobre a Agilidade ......................................................................... 8

3.3. Metodologias Ágeis ..................................................................................................................... 8

3.4. Produto do Ponto de Vista de Negócio ....................................................................................... 9

3.5. ROI ............................................................................................................................................. 10

3.6. Declaração de Visão .................................................................................................................. 10

3.7. Estimativa Inicial ........................................................................................................................ 11

4. Diferencial do Scrum ..................................................................................................................... 11

4.1. História ...................................................................................................................................... 12

4.2. Como Ganhar essa Vantagem Competitiva .............................................................................. 12

4.3. E na prática, como isso funciona? ............................................................................................. 13

5. O SCRUM ....................................................................................................................................... 13

5.1. O que é SCRUM ......................................................................................................................... 13

5.2. Papéis ........................................................................................................................................ 15

5.2.1. ScrumMaster ......................................................................................................................... 16

5.2.2. Product Owner ...................................................................................................................... 16

5.2.3. Time ....................................................................................................................................... 17

5.3. Gerenciamento de Escopo e Valor Agregado ao Negócio ........................................................ 18

5.4. Gerenciamento do Tempo ........................................................................................................ 19


3


5.5. Fluxo de Trabalho ...................................................................................................................... 19

5.6. Conceito de Sprint ..................................................................................................................... 20

5.7. Sprint Planning Meeting ............................................................................................................ 21

5.7.1. Daily Scrum Meeting ............................................................................................................. 22

5.7.2. Sprint Review Meeting .......................................................................................................... 22

5.7.3. Sprint Retrospective Meeting ............................................................................................... 23

5.8. Visibilidade, Inspenção e Adaptação ......................................................................................... 23

5.9. Ajudando o Trabalho da Equipe através da Remoção Contínua de Impedimentos ................. 24

5.10. Definição de Pronto............................................................................................................... 25

5.11. Melhoria Contínua ................................................................................................................ 26

6. Outros Conceitos ........................................................................................................................... 26

6.1. PDCA .......................................................................................................................................... 26

6.2. Kanban ....................................................................................................................................... 27


4


FIGURAS Figura 1 - Visão do Escopo do Negócio ................................................................................................. 10

Figura 2 - Exemplo de Mapa Mental ..................................................................................................... 11

Figura 3 - Visão Geral do Processo Scrum ............................................................................................. 14

Figura 4 - História do comprometimento x envolvimento .................................................................... 15

Figura 5 – ScrumMaster deve atuar como facilitador ........................................................................... 16

Figura 6 - Responsável pela Gestão do Product Backlog ...................................................................... 17

Figura 7 - Time Interdisciplinar.............................................................................................................. 17

Figura 8 - Framework Scrum na visão geral .......................................................................................... 20

Figura 9 - Baralho de Planning Poker .................................................................................................... 21

Figura 10 - Exemplo de um quadro KanBan .......................................................................................... 24

Figura 11 - Gráfico de Burndown do Projeto ........................................................................................ 24


5


Liderança

1.1. Entendendo Coaching

Toda pessoa busca em sua vida, profissional e particular, conseguir alcançar seus objetivos. Para

isto, este indivíduo cria metas que irão ajudá-lo durante o seu percurso no alcance de tais

objetivos. A meta, que em sua definição representa a maneira que escolhemos para chegar ao

nosso objetivo, ajuda as pessoas a terem um norte, mas muitas vezes o caminho para alcançar

estas metas é difícil.

Neste ponto, o papel de coaching é essencial para ajudar o indivíduo a trilhar o caminho para o

alcance das suas metas de uma forma mais simples. Um dos objetivos do coaching é ajudar a

desenvolver o potencial das pessoas ao qual ele orienta ou auxilia. Ele ajuda a remover os

obstáculos e faz com que cada indivíduo maximize o seu potencial.

Mas comumente, o coaching está associado aos esportes. Temos hoje em dia vários exemplos de

destaque em diversos esportes como o futebol e o vôlei. Em todos eles o técnico desempenha

um papel fundamental para maximizar o potencial do seu grupo levando estes aos seus

objetivos.

Neste processo é importante também destacar que a pessoa que irá desempenhar o papel de

coaching deve trabalhar com a sua equipe, estudando cada indivíduo e ajudando a melhorar os

seus pontos fracos, a desenvolver a capacidade de saber resolver os problemas e ajudar a

remover os obstáculos que o liderado irá encontrar em seu caminho.

Por isso, é importante entendermos que o Coaching não é somente a forma, mais todo um

conjunto de qualidades (orientador, colaborativo, influente e entendido) que uma pessoa deve

possuir para que possa guiar a sua equipe ou seus liderados para o alcance de suas metas.

1.2. O que não é Coaching

Neste processo de coaching, muitas vezes surgem conceitos equivocados. Também o que

acontece é que este processo é aplicado de forma incorreta prejudicando e confundindo as

pessoas que estão iniciando este aprendizado. A seguir uma explicação do que não é considerado

coaching.

• Consultoria – O coach não dá respostas. Ele não resolve os problemas. Ele busca ajudar

aos seus liderados a descobrir suas próprias respostas.


6


• Aconselhamento – O coach não dá conselhos e nem soluções prontas. O conselheiro

trabalha com o seu cliente, que está desconfortável ou insatisfeito com a vida, lhe dando

uma direção e conselhos.

• Treinamento – O coach não ensina aos seus liderados técnicas e ferramentas para

percorrer um caminho. Isto é interessante, pois um coach não precisa ser alguém mais

capacitado do que seus liderados no assunto a ser desenvolvido.

• Mentoring – Comumente, um mentor ensina tudo que sabe sobre um determinado

assunto. Assim, o liderado apenas aprende aquilo que o seu mentor sabe, sendo uma

espécie de modelo para o seu liderado.

• Tratamento psiquiátrico ou análise psicológica – O coaching não visa “corrigir

indivíduos” ou resolver alguma disfunção da mente. O coaching não é remediativo, ele é

generativo. O coaching não tem foco no passo, mas sim no futuro.

2. Facilitação

Facilitação é o processo ou abordagem que busca oferecer meios de tornar fácil e exequível

qualquer evento. Com isso, o facilitador busca realizar um trabalho coletivo, criativo e

complementar, sempre identificando as competências individuais.

Neste tipo de trabalho também podem surgir os indivíduos potencialmente conflitantes e é neste

momento que o facilitador, busca o bom senso permitindo que todos possam expressar suas

ideias.

Através desta prática, o facilitador também resolve os problemas de conflitos interpessoais, a

comunicação ineficiente da equipe e pouca clareza nos objetivos do evento. Isto permite que

todos possam participar e se tornar responsáveis por um determinado tema em discussão no

evento. Isto aumenta o foco das pessoas para o encalce dos objetivos e/ou metas.

Em um evento facilitado, é comum haver uma forte comunicação visual. A neurociência explica

que nosso cérebro possui dois hemisférios, onde o lado direito é considerado emocional e o lado

esquerdo é considerado racional. Com esta premissa, o uso de ferramentas para gerar uma

comunicação visual proporciona uma espécie de harmonia entre estes hemisférios, pois são

fornecidos subsídios para ajudar o raciocínio lógico a materializar e organizar as emoções e

sentimentos peculiares à construção de novas ideias.

3. Introdução a Agilidade

Há muito tempo, a maneira de desenvolver software vem evoluindo com a criação de novas

metodologias e processos, que visam facilitar o trabalho. Por muito tempo, tem-se usado o

processo de desenvolvimento em cascata, mas este mostrou que a maioria dos projetos

obtiveram fracasso, pois neste modelo as atividades são mais onerosas e mais burocráticas. Este


7


modelo segue a filosofia do conceito tradicional de desenvolver software, que consiste na ideia

de um conjunto de atividades e resultados associados. Outro problema neste modelo, é que a

medida em que o trabalho avança, ou seja, a medida em que as fases vão passando, o custo de

correção ou ajuste cresce de forma exponencial.

O desenvolvimento ágil é um fruto da constatação feita, de forma independente, por diversos

profissionais renomados na área de engenharia de software, de que, apesar de terem aprendido

segundo a cartilha tradicional, só conseguiam minimizar os riscos associados ao desenvolvimento

de software, pensando e agindo de forma muito diferente do que tradicionalmente está nos

livros.

Com esta ideia, foi criado o Manifesto Ágil que é um documento elaborado com o intuito de

determinar qual a visão de uma equipe de desenvolvimento de software e, foi assinado por

desenvolvedores e gestores de projetos do software respeitados no mundo todo.

Criado por um seleto grupo de pessoas da comunidade, o Manifesto Ágil é formado por

princípios e valores que devem servir como diretrizes para as equipes. No manifesto ágil,

valoriza-se:

• Indivíduos e interação entre eles, 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.

De forma mais direta, deve-se valorizar mais os itens em destaque. Mas isto não significa que os

itens sem destaque não devem ser valorizados, mas são menos prioritários.

É importante observar, que ser Ágil não quer dizer ser radical e nem quer dizer que existe apenas

uma solução para os projetos de desenvolvimento de software. Ser Ágil quer dizer, identificar e

focar em objetivos bem estabelecidos, cuidar para que haja conscientização dos membros da

equipe, unir a equipe e permitir a pró-atividade e auto gerenciamento, garantir feedback

continuamente, utilizar soluções simples para problemas simples e, por fim, inspecionar e

adaptar.

3.1. Os Princípios do Manifesto Ágil

• Garantir a satisfação do consumidor, entregando rapidamente e continuamente

softwares funcionais;

• Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);

• Softwares funcionais são as principais medidas de progresso do projeto;

• Até mesmo mudanças tardias de escopo no projeto são bem-vindas;


8


• Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;

• Projetos surgem através de indivíduos motivados, entre os quais existe relação de

confiança;

• Design do software deve prezar pela excelência técnica;

• Simplicidade;

• Rápida adaptação às mudanças;

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

• Software funcional mais do que documentação extensa;

• Colaboração com clientes mais do que negociação de contratos;

• Responder às mudanças mais do que seguir um plano.

3.2. Alguns Pontos Fundamentais sobre a Agilidade

Praticar agilidade é algo que todos buscam, mas antes de qualquer metodologia ou processo,

primeiramente é preciso observar alguns pontos fundamentais que ajudarão na adoção e prática

de agilidade. São estes:

• Fracassos não devem ser encarados como coisas ruins, mas sim como lições aprendidas e

assim não cometer o mesmo erro;

• É imprescindível saber que todos os resultados devem ser mensurados. Não para

encontrar culpados, mas para poder realizar melhorias na equipe ou pessoalmente. É um

processo de evolução;

• Dividir para conquistar. Para grandes coisas sempre procure dividir para resolver por

partes;

• Procure sempre trabalhar as ideias. Dê mais tempo;

• Quanto mais simples o software, mais barato, mais rápido para desenvolver e mais

agradável para o usuário. Quando surgir novas funcionalidades diga não;

• Garantir a satisfação do cliente, entregando rapidamente e de forma contínua o software

funcional;

• Projetos surgem através de indivíduos motivados, entre os quais existe relação de

confiança;

• Rápida adaptação às mudanças;

• Responder às mudanças mais do que seguir um plano;

• Até mesmo mudanças tardias de escopo são bem-vindas.

3.3. Metodologias Ágeis


9


Dentro de filosofia de agilidade, há diversas formas de se trabalhar. Ou seja, há diversos

processos e metodologias que atendem aos princípios do manifesto ágil e que estes devem ser

adaptados a realidade de cada um. Isto é um processo de inspeção e adaptação constante.

Os processos ágeis tiveram seu início na década de 90 e eram chamados de processos leves em

relação aos processos pesados e burocráticos como o modelo cascata. Dentre eles podemos

citar: FDD (Feature Driven Devlopment) , XP (eXtreme Programming), Scrum e Crystal. Abaixo

será explicado um pouco sobre cada metodologia.

• FDD – Desenvolvimento Orientado a Funcionalidades, metodologia criada entre 1997 e

1999 por um dos participantes do Manifesto Ágil, tem a sua base o método Coad

(metodologia completa para Análise, Desenho e Programação Orientada por Objetos

desenvolvida por Peter Coad) e as técnicas de gerenciamento interativo, incremental e

enxuto. A sua ideia principal é “Resultados frequentes, tangíveis e funcionais”;

• XP – (eXtreme Programming), metodologia criada em 1996 na corporação Chrysler para

ser utilizada por equipes pequenas e médias que irão desenvolver software com

requisitos vagos e em constante mudança. Segue os cinco valores fundamentais:

comunicação, simplicidade, feedback, coragem e respeito.

• Scrum, framework criado em 1993 para desenvolvimento interativo e incremental de

software. Sua principal ideia é propor um framework com boas práticas e papéis bem-

definidos para ajudar as equipes de desenvolvimento de software a realizarem o

desenvolvimento de projetos de forma mais eficiente. No scrum, o mais importante é a

atitude das pessoas envolvidas de querer fazer o projeto acontecer. Os principais papéis

no scrum são: Scrum Master, Product Owner e a Equipe.

3.4. Produto do Ponto de Vista de Negócio

Em termos comerciais de software, o produto resultante de um projeto de desenvolvimento de

software é o próprio software. Como profissionais de desenvolvimento de software, não

devemos e não queremos nos preocupar com os outros fatores que não sejam a qualidade e a

velocidade com o qual o software é entregue.

Mas do ponto de vista do cliente, este produto (software) será o responsável pela resolução de

alguma necessidade ou apenas irá melhorar o processo de negócio, trazendo benefícios

econômicos. Destes dois pontos de vista, pode-se observar que o software tem valores

diferentes, dependendo de vários fatores.

Diante destes pontos, podemos concluir que o ponto de vista do cliente é a meta que a equipe

de desenvolvimento de software deve alcançar e o ponto de vista da equipe (ou profissionais

desenvolvimento) é a forma como este software deverá ser desenvolvido, sendo que cada um

tem responsabilidades distintas, onde o primeiro ajuda a definir o que será o produto e seus

detalhes e o segundo deverá trabalhar em cima destas informações para gerar o produto final.


10


Figura 1 - Visão do Escopo do Negócio

Normalmente, o escopo vem definido através de termos de negócio. Cabe aos desenvolvedores

traduzirem isso para linguagem técnica de forma transparente e assim, ser capaz de praticar

sinergia para com o cliente.

Para a definição do escopo do produto no contexto do negócio, é essencial que seja definido um

representante do cliente que tenha uma visão completa do negócio.

3.5. ROI

O cliente deve sempre manter a sua visão de retorno de investimento sobre as aquisições que

ele realiza. Isto não seria diferente para software. Por isso, cabe a equipe de desenvolvimento

ajudar o cliente a definir o seu produto e desta forma, trabalhar para realizar este produto.

Também cabe a equipe, informar ao cliente quando algo que ele venha a definir ou solicitar traga

mais custos do que benefícios para o seu negócio.

Todo este processo é definido como ROI - Return Of Investiment (retorno sobre o investimento),

que é uma ferramenta de avaliação de desempenho sobre o investimento realizado. Através dela

o cliente poderá medir, junto com a equipe de desenvolvimento, os benefícios do

desenvolvimento de um software para o seu negócio.

3.6. Declaração de Visão

A visão do produto é a primeira atividade que qualquer cliente irá realizar antes de solicitar o seu

software. Esta visão se tornará a meta do projeto, que a equipe irá quebrar em objetivos

menores. Isto em alto nível fará com que todos da equipe de desenvolvimento saibam qual o

resultado esperado.

Deverá ser um documento sem ambiguidade e inteligível para que toda a equipe possa

compreender. Será de grande utilidade a construção de um modelo do fluxo de informações do

negócio. Desta forma será útil, principalmente para a equipe, que poderá utilizá-lo para saber

como irá adequar o software a realidade do cliente.


11


Mais especificamente, o documento de visão do produto deverá ser um documento com no

máximo duas (02) folhas. Deve abranger as partes mais importantes do produto e deverá ser

gerado pelo cliente ou representante deste. Podemos fazer uso também de outras ferramentas

para descrever a visão do produto, como por exemplo, a Modelagem de Mapas Mentais. Este

consiste de um diagrama contendo o objetivo, uma estrutura de funcionalidades, metas não

funcionais, critérios de sucesso e uma descrição superficial das tecnologias e arquitetura do

projeto.

Figura 2 - Exemplo de Mapa Mental

3.7. Estimativa Inicial

No momento da definição do software, o cliente deverá realizar a priorização das

funcionalidades que o produto irá conter. Isto significa que o cliente em conjunto com a equipe

deverá realizar uma lista de todas as funcionalidades e a ordem de classificação quanto a sua

importância para o negócio. Isso irá auxiliar a equipe no planejamento do desenvolvimento do

software.

As funcionalidades também poderão ser agrupadas ou então ordenadas em uma só lista, que

será considerada o principal documento para construção do software. Toda a equipe irá se

basear nesta lista, pois esta define os objetivos da equipe para o alcance da meta final (que é o

software construído).

Para esta estimativa inicial, não é necessário definir valores para cada funcionalidade (ou

requisito). Apenas será definida uma ordem de prioridade a partir da visão do cliente.

4. Diferencial do Scrum


12


O Scrum como qualquer outra ferramenta de gestão de projetos, tem como propósito ajudar no

desenvolvimento do software de forma mais eficiente e eficaz. Mais por que o Scrum se destaca

das outras? Isto será explicado nas próximas seções, onde serão abordados a história, as

características que tornaram este framework muito popular no campo do desenvolvimento de

software e que hoje já se estende para outras áreas.

4.1. História

Abaixo um histórico resumido da elaboração do framework Scrum:

• Em 1986 Hirotaka Takeuchi e Ikujiro Nonaka descreveram uma nova abordagem para o

desenvolvimento de produtos em que todas as fases do processo e a equipe trabalham

juntos em diferentes fases;

• Na década de 90, a metodologia Scrum foi introduzida em algumas companhias, como

por exemplo, Easel Corporation onde Ken Schwaber trabalhava. Neste mesmo ano Jeff

Sutherland, John Scumniotales e Jeff McKenna chamaram pela primeira vez este

processo de Scrum;

• Em 1995 Ken Schwaber e Jeff Sutherland descreveram e apresentaram para o público.

4.2. Como Ganhar essa Vantagem Competitiva

A primeira coisa que devemos observar é a forma como a equipe está trabalhando. Visualizar os

pontos fracos, para identificar se este processo realmente irá ajudar a permanecer no mercado.

Isto é necessário para que não afete a rentabilidade da empresa.

Vale ressaltar que esta avaliação do processo atual da empresa é muito importante, pois o que se

tem falado até o momento e também depois só fará sentido, se realmente o processo da

empresa precisar ser melhorado. Isto foi o mesmo sentimento que motivou há muito tempo

atrás a criação do “Manifesto Ágil”. Este material foi compilado a partir das boas experiências e

resultados positivos em diversos tipos de projetos.

As empresas que ainda possuem a visão antiga, de que focar em processo e documentação é a

única forma de melhorar o trabalho, estão tendo que rever seus conceitos para poder

acompanhar o mercado e se tornar competitivas.

A agilidade no desenvolvimento de software, está se tornando cada vez mais um grande

diferencial no mercado de software, pois com a velocidade das informações o software está cada

vez mais se tornando parte essencial para o negócio.


13


4.3. E na prática, como isso funciona?

Tudo isso é muito bom, parece ser a salvação das indústrias de software. Mas o que realmente

pode-se constatar é que essa maravilha toda não é tão fácil de implantar ou trazer resultados em

curto prazo.

Além das práticas e processos das metodologias ágeis, ainda há o fator humano envolvido.

Muitas vezes a implantação pode levar muito tempo ou até mesmo ficar inviável devido a cultura

da empresa e das pessoas envolvidas.

É importante lembrar, que as metodologias ágeis são uma filosofia, uma forma de trabalho bem

diferente do modelo tradicional, que vai depender das atitudes dos envolvidos no projeto para

que este venha a ter sucesso.

Atualmente muitas empresas conseguiram implantar e adequar o framework aos seus projetos,

gerando ótimos resultados. Mas há outras que ainda não conseguiram e ainda lutam para

quebrar paradigmas antigos que atrapalham muito esta nova forma de trabalho. Por isso é muito

importante que esta filosofia seja seguida desde a alta direção até o desenvolvedor, para que

todos possam ganhar com esta nova forma de abordagem de desenvolver software.

5. O SCRUM

5.1. O que é SCRUM

O scrum não é uma metodologia, não é uma nova tecnologia, não é uma ferramenta e nem um

cheklist de avaliação de processo. Trata-se apenas de um framework, que baseia-se em um

processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento

de qualquer projeto (Certified Scrum Master, 2009). Mas também deve ser considerada, uma

filosofia de trabalho que envolve a atitude das pessoas envolvidas no projeto.

Algumas características do Scrum:

• Processo empírico de gerenciamento e controle;

• Deve-se praticar a inspeção e adaptação em loops de feedbacks;

• Baseia-se na filosofia de entregas frequentes de funcionalidades com valor para o

cliente;

• Escalável a projetos distribuídos, grandes e largos;

• Extremamente simples, mas resistente.

O scrum é fundamentado na teoria de controle de processos empíricos, que emprega uma

abordagem iterativa e incremental para aperfeiçoar a previsibilidade e controlar riscos. Três

pilares sustentam qualquer implementação de controle de processos empíricos: Transparência,

Inspeção e Adaptação.


14


• Primeiro pilar é a TRANSPARÊNCIA

Este pilar informa que todo o processo que afeta o resultado deve transcorrer de

forma transparente, principalmente para aqueles que realizam a gestão. Além da

transparência este processo deve ser conhecido para que qualquer inspeção no

processo possa ser facilmente visto todos os pontos.

• Segundo pilar é a INSPEÇÃO

Este pilar informa que devem ser realizadas inspeções com frequência suficiente

para que variações inaceitáveis do processo possam ser detectadas, ou seja,

qualquer ponto de melhoria deve ser visualizado e corrigido o mais breve possível.

• Terceiro pilar é a ADAPTAÇÃO

Este pilar informa que caso seja encontrado algum ponto do processo fora dos

limites aceitáveis e que o produto resultante será inaceitável, deverá ser ajustado o

mais breve possível para minimizar desvios posteriores. Conforme o framework

Scrum, este possui três pontos de inspeção e adaptação. A primeira é a reunião

diária que é utilizada para avaliar o progresso do projeto em direção à Meta da

Sprint e também se pode realizar adaptações que otimizem o valor do próximo dia

de trabalho. Em seguida temos a reunião de Revisão da Sprint e de Planejamento da

Sprint que são utilizadas para inspecionar o progresso em direção à meta da versão.

Por último temos a reunião de Retrospectiva da Sprint, que tem o objetivo de avaliar

e revisar a Sprint passada, para definir as adaptações que tornarão a próxima mais

produtiva e gratificante.

O framework Scrum é formado pelo Time e outros papéis (que veremos em seguida), eventos

com durão fixa (conhecidos como Time-Boxes), os artefatos e regras.

Figura 3 - Visão Geral do Processo Scrum

O Time do Scrum é projetado para ser eficiente, tanto na sua produtividade quanto a sua

flexibilidade. Por este motivo, este time deve ser interdisciplinar, auto-organizado e que saiba

trabalhar em iterações.


15


Neste time os principais papéis são:

• Scrum Master: Responsável por garantir que todas as regras e atividades do scrum

sejam seguidas e sejam entendidos por todos os envolvidos;

• Product Owner: Responsável por definir as entregas e por maximizar o valor do trabalho

do time;

• Time: Responsável por executar o trabalho propriamente dito.

Geralmente o Time é formado por desenvolvedores com todas as habilidades necessárias que irão

garantir que todos os requisitos definidos na Sprint irão gerar um pedaço potencialmente entregável

em relação ao produto final.

Quanto a sua gestão de linha temporal, o scrum emprega eventos com duração fixa (time-boxes)

para criar uma regularidade. Mas dentro desta duração fixa, temos os principais elementos de

inspeção do Scrum dentro da linha de tempo do projeto que são: a Sprint, a Reunião Diária, a

Revisão da Sprint e a Retrospectiva da Sprint.

Já os artefatos que o Scrum trabalha são: Product Backlog, Sprint Backlog, Burndown da Sprint e um

Burndown do Projeto.

5.2. Papéis

Dentro do scrum, o time é formado pelos seguintes papéis: Scrum Master, Product Owner e pelo

Time. Dentro deste contexto temos antes que explicar qual a visão do framework scrum em relação a

todos estes papéis. Primeiramente vamos observar a figura abaixo:

Figura 4 - História do comprometimento x envolvimento

Como observamos, dentro do scrum temos aqueles papéis que são os comprometidos e os que são

apenas envolvidos. Como papel de comprometido, ou seja, aqueles que irão se comprometer com os


16


resultados e objetivos a serem alcançados tem o Time scrum. O restante é apenas envolvido no

projeto. Por isso dizemos que no projeto scrum, temos os “Porcos” e as “Galinhas”.

Com este conceito definido, pode-se dizer que as “Galinhas” não podem dizer aos “Porcos” como

estes devem fazer seu trabalho.

5.2.1. ScrumMaster

É o principal responsável por garantir que todos do time estejam aderindo aos valores do scrum,

como as práticas e regras. Ele também é o responsável por ajudar a organização e o time na adoção

do framework. Deve ter como visão a educação do time scrum no seu treinamento quanto ao scrum,

levando-o a ser mais produtivo e a desenvolver produtos com maior qualidade.

O ScrumMaster deve ajudar o time a ser autogerenciado e interdisciplinar. Como princípio o

ScrumMaster não gerencia o time, pois este deve ser auto-organizável.

Além destes pontos descritos anteriormente, o ScrumMaster deve ser um líder/facilitador, pois atua

fortemente na remoção dos impedimentos e principalmente protege o time das interferências

externas para que a meta de entrega seja alcançada.

Figura 5 – ScrumMaster deve atuar como facilitador

É interessante notar que o ScrumMaster trabalha junto aos clientes e gerentes da organização para

auxiliar na preparação e identificação de um Product Owner. O ScrumMaster facilitará o trabalho do

Product Owner e também servirá ao time de forma que o mesmo esteja protegido durante uma

Sprint.

5.2.2. Product Owner

É a pessoa responsável pela gestão do Product Backlog (que será falado nas próximas seções), por

garantir valor ao trabalho do time e por garantir o retorno sobre o investimento do projeto. Este


17


deve manter o backlog atualizado e disponibilizar a todos os envolvidos para que estes saibam onde

devem chegar e quais itens são prioritários.

Figura 6 - Responsável pela Gestão do Product Backlog

O product owner deve ser uma pessoa escolhida pelo cliente, mas jamais deverá ser um grupo ou

comitê. Isto não quer dizer que se o cliente define um grupo, este não possa influenciar ou apoiar o

product owner, mas só quem pode mudar a prioridade de um requisito é o Product Owner.

Como sugestão, pode ser um Gerente de Produto ou então um Gerente da função de negócios, por

estar mais próximo do cliente.

Um ponto importante para o sucesso do product owner em um projeto scrum é que toda

organização deve respeitas as decisões feitas pelo product owner.

5.2.3. Time

É o responsável por dividir o product backlog em incrementos de funcionalidades potencialmente

entregáveis em cada Sprint. A visão de cada membro do time é de ser interdisciplinar, ou seja, devem

possuir o conhecimento necessário para criar um incremento de trabalho.

Figura 7 - Time Interdisciplinar


18


Apesar de em muitos casos as pessoas do time atuarem em atividades especializadas como, por

exemplo, programação, arquiteto de software, projetista de banco de dados, analista de requisitos e

outros, o mais importante é que estes saibam pegar um requisito e transformá-lo em um produto

utilizável, mesmo que isso signifique ter que atuar em outra atividade. Os membros do time que não

se adequam a este tipo de filosofia não conseguem adaptar-se ao time.

Não há títulos em time, não divisão por funções todos são iguais, ou seja, muitas vezes um analista

de requisitos terá que testar ou até mesmo programar (claro isso irá requerer que este relembre a

programa ou até mesmo desenvolva esta habilidade.).

O time deve ser auto organizável, ou seja, nem mesmo o scrum master pode dizer como o time deve

trabalhar para transformar o product backlog em incrementos entregáveis. Isto é algo que o time

terá que fazer sozinho. Isto fica mais fácil ao aplicar a habilidade de cada membro em cima do

product backlog e com isso saberão o que será necessário fazer para realizar as entregas. Isto leva o

time a melhorar a sua eficiência e eficácia.

Em um time scrum, o número ideal de pessoas são sete (07) e mais ou menos duas (02). Caso o time

possua menos de cinco pessoas, isto pode causar menor interação entre as pessoas do time levando

a um menor ganho de produtividade. Mais do que o limite superior (de sete mais duas pessoas)

também não é bom, pois isto causará grandes problemas em coordenar este time muito grande.

5.3. Gerenciamento de Escopo e Valor Agregado ao Negócio

Para o projeto Scrum, um dos artefatos mais importantes é o Product Backlog que reúne a lista de

requisitos de forma priorizada realizada pelo Product Owner (como dito anteriormente). Para a

composição deste artefato, o ideal é usar as práticas da engenharia de requisitos.

Com as metodologias ágeis, através da sua abordagem simples e enxuta dos requisitos, pode ajudar

na especificação e definição dos requisitos, já que este framework incentiva a comunicação através

de um texto claro e usando uma linguagem única de negócios.

Uma das ferramentas utilizadas pelo scrum é a estória de usuário (user story). Esta ferramenta

oriunda da metodologia XP é utilizado para elicitação dos requisitos e sua estrutura é a seguinte: “

Como um(a) <PAPEL> gostaria /devo de <FUNÇÂO> para/por <VALOR DE NEGÓCIO> ”. Abaixo

vejamos alguns exemplo:

Como supervisor eu gostaria de

autorizar um desconto em uma

venda.

Como um instrutor eu devo apontar

a lista de presença dos alunos para

manter as informações do

treinamento atualizadas.


19


Depois de identificado estes requisitos estes deverão ser reunidos e priorizados no Product Backlog.

Este artefato representará a visão do produto e assim, o time poderá estabelecer uma estratégia

para as entregas.

A priorização dos itens do Product Backlog serão definidos através de uma nota numérica que é

definido pelo Product Owner. Esta pontuação é definida a partir da sua visão de importância para o

negócio. Abaixo veremos um exemplo de um Product Backlog:

Item Valor de Negócio

Como candidato gostaria de visualizar os cursos disponíveis pela

instituição

100

Como candidato gostaria de fazer minha inscrição no vestibular. 80

Como candidato gostaria de emitir o boleto para pagamento das

taxas de inscrição no vestibular.

60

5.4. Gerenciamento do Tempo

O principal paradigma oferecido pelo framework scrum é o conceito de TimeBox. Ele funciona como

uma caixa de tempo em vários níveis (diário, semana e mensal) e está presente em praticamente

todas as seções de trabalho do scrum.

Estes eventos de duração fixa no scrum são a Sprint, a Reunião de Planejamento da Sprint, a

Revisão da Sprint, a Restrospectiva da Sprint e a Reunião Diária.

Dentre estes eventos o que melhor representa o TimeBox é o Sprint, pois é uma iteração que será

realizada várias vezes durante o projeto, com o principal objetivo de entregar algo potencialmente

usável ao seu final.

5.5. Fluxo de Trabalho

O fluxo de trabalho do scrum oferece um processo bem simples de entender. Porém o mais difícil é

implementar este processo, pois incide na mudança de cultura da empresa onde se está adotando o

scrum. Abaixo uma visão de todo o framework.


20


Figura 8 - Framework Scrum na visão geral

5.6. Conceito de Sprint

A Sprint é um timebox de uma (1) a quatro (4) semanas de duração no qual o time do projeto irá

produzir uma parte do produto definida pelo cliente. Cada Sprint deve ter uma meta específica que

represente o desejo do cliente em incremento de software para aquele timebox específico e os

membros do time do Sprint são os responsáveis por estimar os itens que compõe o desejo do cliente

e dar a palavra final do que será possível ser desenvolvido naquele timebox.

Com isso a Sprint é uma iteração. Durante a Sprint o ScrumMaster garante que não será feito

nenhuma mudança que possa afetar a meta do Sprint. Tanto a composição do time quanto as metas

de qualidade que devem permanecer constantes durante a Sprint.

As sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product

Owner tem a autoridade de cancelar uma Sprint, embora ele possa fazer sob a influência de partes

interessadas e do ScrumMaster. Em geral, uma Sprint deve ser cancelada se ela não fizer mais

sentido dadas as circunstâncias atuais. A partir do momento que uma Sprint é cancelada, todos os

itens do Product Backlog que foram completados são revisados. Eles são aceitos se representarem

um incremento potencialmente entregável. O restante dos itens volta para o product backlog com as

estimativas iniciais.


21


5.7. Sprint Planning Meeting

A Reunião de Planejamento da Sprint (Sprint Planning Meeting) é quando a iteração é planejada. É

fixada em oito (08) horas de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se

para essa reunião aproximadamente 5% do tamanho total da Sprint e consiste de duas partes. Estas

duas reuniões são facilitadas ou lideradas pelo ScrumMaster.

Na primeira reunião, que tem duração de quatro (04) horas, o Product Owner apresenta os itens de

maior valor de negócio para o time, o time irá estimar o tamanho/complexidade desses itens e é

decidido o que será feito na Sprint. Todos os itens de backlog tem sua estimativa de esforço definidas

através de uma técnica chamada de planning poker. Esta técnica consiste em definir em conjunto

(time) o esforço necessário para realizar certa atividade em horas.

Figura 9 - Baralho de Planning Poker

A segunda reunião, que também de duração de quatro (04) horas, é quando o time entende como

desenvolverá essa funcionalidade de incremento do produto durante a Sprint, para cada item o time

irá criar tarefas que o time entende que precisa realizar para completar o item de backlog.

Estas duas reuniões podem ser dividas em “o quê?” e “como?”, ou seja, a primeira reunião irá se

definir o que será realizada na Sprint que se inicia. Este é um trabalho em conjunto com o time e o

product owner. O ScrumMaster é apenas o facilitador da reunião. Se for o primeiro Sprint, o item

que deve ser utilizado nesta reunião é o product backlog. Se for o segundo Sprint em diante deve-se

utilizar além do product backlog, a capacidade do time em desenvolver as tarefas em um Sprint

(quantos itens é possível realizar) e também o histórico de desempenho (velocidade).

Na segunda parte da reunião o time ira tratar da questão do “como” desenvolver os itens

selecionados e transformá-los em um incremento pronto. Neste momento, enquanto o time projeta

como serão realizado os itens, o time identifica as tarefas necessárias para realizar cada item do

Sprint. Estas tarefas devem ser decompostas para serem realizadas em menos de um dia e após a

conclusão destas atividades é que irá converter os itens do product backlog em pedaços funcionais

do produto final. Ao final teremos uma lista das tarefas do Sprint que serão chamados de Sprint

Backlog.


22


O Product Owner está presente nas duas reuniões, e se o time identificar nestas reuniões que há

trabalho de mais ou de menos, ele deve renegociar com o Product Owner.

O time também pode convidar outras pessoas para participarem da reunião para fornecer conselhos

técnicos ou sobre o domínio da questão.

5.7.1. Daily Scrum Meeting

Na Reunião Diária do Scrum (Daily Scrum Meeting) o time se encontra para uma reunião de 15

minutos e deve ser feita sempre no mesmo horário e local. Durante a reunião, que é conduzida pelo

ScrumMaster, cada membro deve responder a três perguntas:

• O que fizemos de ontem para hoje?

• O que iremos realizar de hoje para amanhã?

• Existe algum impedimento?

As reuniões diárias melhoram a comunicação, eliminam outras reuniões, ajudam a identificar e

remover impedimentos para o desenvolvimento do Sprint, ressaltam e promovem a tomada rápida

de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

O ScrumMaster deve garantir que o time realize a reunião e é responsável por conduzir a reunião.

Deve ensinar o time a manter a reunião em curta duração, reforçando as regras e garantindo que as

pessoas falem brevemente. Deve ser o facilitador da reunião.

A reunião diária não é para reportar status e sim, uma forma de inspecionar o progresso do time em

direção à meta do Sprint. Essa reunião é fundamental para inspecionar e adaptar o processo Scrum.

5.7.2. Sprint Review Meeting

A Reunião de Revisão do Sprint (Sprint Review Meeting) é o evento realizado ao final da Sprint. Para

Sprints de um mês, a reunião deverá ter uma duração de quatro (04) horas e para Sprint mais curtos

a reunião não deve tomar mais do que 5% do tempo total do Sprint.

Durante a revisão da Sprint o time apresenta o que foi realizado e desenvolvido durante a Sprint para

o Product Owner e também outros envolvidos (Stakeholders, caso haja necessidade). É uma reunião

informativa e também neste momento os stakeholders podem sugerir novos itens de backlog.

Nesta reunião inclui pelo menos os seguintes itens: O Product Owner identifica o que foi feito e o

que não foi feito durante a Sprint. O Time demonstra o trabalho que está pronto e responde a

questionamentos. O Product Owner discute o Product Backlog da maneira como ele se encontra. Ele

faz projeções de datas de conclusões prováveis a partir de várias hipóteses de velocidade. Em


23


seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer

em seguida. A Revisão da Sprint fornece várias entradas valiosas para as próximas reuniões de

Planejamento de Sprints.

5.7.3. Sprint Retrospective Meeting

A Reunião de Retrospectiva da Sprint (Sprint Retrospective Meeting) é realizada após a reunião de

revisão da Sprint e antes da próxima reunião de planejamento da Sprint. Nesta reunião com duração

fixa em três (03) horas, o ScrumMaster encoraja o time a revisar, dentro do modelo de trabalho e das

práticas do processo Scrum, o seu desenvolvimento, de forma a torná-lo mais eficaz e gratificante

para a próxima Sprint.

A finalidade desta reunião é inspecionar como ocorreu a última Sprint em se tratando de pessoas,

das relações entre elas, dos processos e ferramentas. É nesta reunião que o time tem a chance de

refletir o que aconteceu na Sprint que passou e responder as seguintes questões: “O que funcionou

bem?”, “O que não funcionou bem?” e “O que pode ser melhorado?”. É neste ponto que entra a

inspeção da adoção do processo.

Ao final da reunião o time deve ter identificado medidas de melhoria factíveis de se implementar na

próxima Sprint. Estas mudanças se tornam a adaptação para a inspeção empírica.

5.8. Visibilidade, Inspenção e Adaptação

O Scrum se apoia em três pilares (como já foi dito na seção 5.1 – O que é SCRUM) para realizar

entregas constantes: Visibilidade, Inspeção e Adaptação. Dentre estes, o mais interessante dentro

do processo Scrum e que realmente traz uma mudança forte no cotidiano é a visibilidade.

Com isso uma das principais missões do Scrum é tornar visível para a equipe e também outros

interessados como está o progresso e quais os problemas que precisam ser resolvidos para melhorar

os resultados.

Para isso, o Scrum oferece algumas opções muito interessantes para estimular uma comunicação

mais direta e simplificada dentro de um projeto. A partir deste ponto é necessário observar o desafio

cultural para promover as melhorias nas atitudes de cada membro do time, visto que agora qualquer

pequena variação do projeto será percebida dentro de uma Sprint.

Dessa forma, uma das principais ferramentas para promover essa visibilidade é o famoso KanBan

(quadro de atividades), que é uma herança muito interessante que as metodologias ágeis tiveram do

Pensamento Lean. Dentre outras coisas, essa ferramenta estimulará psicologicamente atitudes auto

organizadas para puxar itens para a produção e tornar visível o seu progresso ou qualquer

impedimento durante o trabalho. Abaixo um exemplo de quadro KanBan:


24


Figura 10 - Exemplo de um quadro KanBan

Outra ferramenta interessante e típica do Scrum é o gráfico de Burndown, que mostra quando de

valor de negócio, tamanho e esforço já foram realizados (entregues) durante a Sprint e do projeto

inteiro. Abaixo uma imagem do Burndown:

Figura 11 - Gráfico de Burndown do Projeto

5.9. Ajudando o Trabalho da Equipe através da Remoção Contínua de Impedimentos


25


Como é natural na área de Tecnologia da Informação, vivemos em um universo de problemas. Mas

Scrum tem uma maneira muito interessante de tratar estes problemas. Isto também pode ser visto

de outra forma, como impedimentos que atuam como barreiras para que o trabalho iniciado não vá

adiante.

Estes impedimentos podem ser de diversas naturezas como, por exemplo, questões técnicas,

políticas e pessoais.

O tratamento destes impedimentos é baseado em um dos princípios do modelo Toyota que estimula

o controle visual para permitir que qualquer problema esteja visível dentro do processo. Desta

forma, através deste controle visual (como mostrado no KanBan), o ScrumMaster poderá exercer

umas das suas responsabilidades que é de remover os obstáculos ou impedimentos. Isto não significa

que ele vai sempre saber como remover estes impedimentos, mas ele é o responsável por buscar

meios necessários para remoção destes.

5.10. Definição de Pronto

O Scrum, como framework ágil, estimula fortemente que se use o conceito de “Pronto” para nortear

quando os itens de uma Sprint estão realmente prontos e dentro da qualidade desejada para o

produto gerado. É importante compreender que essa definição de pronto é fortemente desenvolvida

quando se usa, junto ao Scrum, alguma metodologia que ofereça práticas fortes de engenharia como

XP ou FDD.

No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém a

presumir que ela está, pelo menos, codificada, refatorada, que tenha passado por testes unitários,

que tenha sido feito o build e que tenha passado por testes de aceitação. Outros podem presumir

que apenas o código tenha sido desenvolvido. Se ninguém sabe qual a definição de “pronto”, os

outros dois pilares do controle de processos empíricos não funcionam. Quando alguém descreve algo

como “pronto”, todos devem entender o que “pronto” significa.

“Pronto” define o que o Time quer dizer quando se compromete a “aprontar” um item de Backlog do

Produto em uma Sprint. Alguns produtos não contêm documentação, de forma que sua definição de

“pronto” não inclui documentação.

Um incremento completamente “pronto” inclui toda a análise, projeto, refatoramento,

programação, documentação e testes para o incremento e todos os itens do Backlog do Produto no

incremento. Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem como

testes não-funcionais como de performance, de estabilidade, de segurança e de integração. “Pronto”

inclui também qualquer internacionalização necessária, além disso, “Pronto” significa que o Product

Owner pode utilizar de alguma forma o item.

Alguns Times ainda não são capazes de incluir em sua definição de “pronto” tudo o que é necessário

para a implantação. Isto deve estar claro para o Product Owner. Esse trabalho restante deverá ser

feito antes que o produto possa ser implantado e utilizado.


26


5.11. Melhoria Contínua

De acordo com o manifesto ágil: “Em intervalos regulares a equipe reflete sobre como se tornar mais

eficaz e então ajusta seu comportamento de acordo”. Isso significa que em pequenos ciclos o time

aprende sobre seus erros e acertos para gerar melhoria na forma de trabalho do próximo ciclo.

Através desta idéia, que na agilidade chamamos de visibilidade, inspeção, e adaptação, temos uma

base sólida, com muita sinergia histórica e prática para a aplicação do ciclo PDCA (Plan, Do, Check e

Action) nas atividades de Planejamento, Execução, Verificação e Ações corretivas ou preventivas

dentro de projetos de desenvolvimento de software.

Esse ciclo PDCA é efetivo num projeto ágil (isso inclui Scrum), pois há um planejamento a cada Sprint

e a cada dia de trabalho de um time. Para assegurar esse ciclo, também fazemos uma verificação

constante em busca de melhoria no produto e no processo (forma de trabalho) a cada dia e ao final

de cada Sprint.

6. Outros Conceitos

Abaixo serão descritos mais conceitos importantes para o conhecimento da gestão de projetos com

Scrum. Estes conceitos ajudarão a entender melhor a filosofia por trás da ideia do framework scrum.

6.1. PDCA

O ciclo PDCA, ciclo de Shewhart ou ciclo de Deming, é um ciclo de desenvolvimento que tem foco na

melhoria contínua.

O PDCA foi idealizado por Shewhart e divulgado por Deming, quem efetivamente o aplicou.

Inicialmente deu-se o uso para estatística e métodos de amostragem. O ciclo de Deming tem por

princípio tornar mais claros e ágeis os processos envolvidos na execução da gestão, como por

exemplo, na gestão da qualidade, dividindo-a em quatro principais passos.

O conceito do Ciclo evoluiu ao longo dos anos vinculando-se também com a idéia de que, uma

organização qualquer, encarregada de atingir um determinado objetivo, necessitava planejar e

controlar as atividades a ela relacionadas.

O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são

executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e

repetidamente (ciclicamente), e toma-se uma ação para eliminar ou ao menos mitigar defeitos no

produto ou na execução.

Os passos são os seguintes:


27


Plan (planejamento): Deve-se estabelecer uma meta ou identificar o problema (um problema tem o

sentido daquilo que impede o alcance dos resultados esperados, ou seja, o alcance da meta); analisar

o fenômeno (analisar os dados relacionados ao problema); analisar o processo (descobrir as causas

fundamentais dos problemas) e elaborar um plano de ação.

Do (execução): Deve-se realizar e executar as atividades conforme o plano de ação.

Check (verificação): Deve-se monitorar e avaliar periodicamente os resultados alcançados, avaliar

processos e resultados, confrontando-os com o planejado, objetivos, especificações e estado

desejado, consolidando as informações, eventualmente confeccionando relatórios.

Act (ação): Deve-se agir de acordo com o avaliado e de acordo com os relatórios, eventualmente

determinar e confeccionar novos planos de ação, de forma a melhorar a

qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas.

6.2. Kanban

Kanban é uma expressão japonesa com origem nos cartões utilizados nas empresas japonesas para

solicitar componentes a outras equipes da mesma linha de produção, e que designa um método de

fabricação em série, desenvolvido pela Toyota Motor Company, aplicado aos processos de

aprovisionamentos, produção e distribuição, seguindo os princípios do Just-in-Time (JIT).

Podemos dizer que o método Kanban é um método que determina a produção a partir da procura:

de fato, o ritmo de produção é determinado pelo ritmo de circulação de Kanban’s, o qual, por sua

vez, é determinado pelo ritmo de saída dos produtos juntamente com o fluxo de produção.

Objetivos do método Kanban

Podemos identificar como principais objetivos do método Kanban os seguintes itens:

• Regular internamente as flutuações da procura e o volume de produção em cada seção de

forma a evitar a transmissão e ampliação dessas flutuações;

• Minimizar as flutuações dos estoques do produto acabado com o objetivo de reduzir os

custos de estocagem;

• Descentralizar a gestão da fábrica, criando condições para que as chefias diretas

desempenhem um papel de gestão efetiva da produção e dos estoques;

• Produzir as quantidades solicitadas no momento em que são solicitados.

Aplicação do método Kanban

Pelas suas características, o método Kanban apenas pode ser aplicado em sistemas de produção

repetitiva, em que os produtos são padronizados e a produção é relativamente estável, sendo

obrigatório que o processo de produção esteja organizado em série.

Documents

Apostila Curso Gp Scrum Divus-V1.1