WORKSHOPliveuniversity.com/downloads/Workshop - Material de Aula - Gestão... · Metodologia Ágil...

©2017 by Febracorp University. This work is licensed under the Creative Commons. If you want to use or share, you must give appropriate credit to Febracorp University.

GESTÃO ÁGIL DE PROJETOS PARA RH

Febracorp University

WORKSHOP

WORKSHOP GESTÃO ÁGIL DE PROJETOS PARA RH


2

Apresentações

1. Converse com a pessoa ao seu lado.

2. Aprenda algumas coisas sobre ele/ela: nome, profissão,

empresa onde trabalha, hobby, alguma curiosidade…

3. Apresente seu/sua colega para a classe.



Expectativas

3

O que você espera desse workshop? Compartilhe o que você quer aprender nesse curso.



Dificuldades em definir o escopo dos projetos?

Problemas na definição dos times e suas

responsabilidades? Falhas constantes de

comunicação? Aquisições realizadas no momento

inadequado? A Gestão Ágil de Projetos tem o intuito

de mitigar estes riscos através da divisão dos projetos

em ciclos, facilitando seu planejamento, operação,

controle e conclusão dos objetivos propostos.

Objetivo


Desenvolvimento Ágil Desenvolvimento Clássico


Clássico e Ágil


Video: Honda Accord


C:/Users/Professor/Desktop/A PIOR APRESENTA%C3%87%C3%83O DO MUNDO- SOAP e Marcos Mion no CONAREC 2009.mp4

C:/Users/Professor/Desktop/A PIOR APRESENTA%C3%87%C3%83O DO MUNDO- SOAP e Marcos Mion no CONAREC 2009.mp4



Metodologia Ágil - Definição

Conjunto de valores, princípios e práticas que auxiliam

equipes de projeto a entregar produtos ou serviços em

um ambiente complexo, instável e desafiador.

(Highsmith, 2004).

Plataforma de gerenciamento de projetos aplicável a

ambientes voláteis e desafiadores, sujeitos a mudanças

frequentes, em que o processo prescritivo e

padronizado acaba não apresentando-se como a

opção mais adequada (Chin, 2004).



Metodologia Ágil - Características

Rápida capacidade de adaptação às

alterações de requisitos.

Frequência nas entregas.

Colaboração estreita entre

stakeholders e equipe do projeto.

Indivíduos e interações.



Metodologia Ágil - Framework

Fonte: Highsmith, 2004.

Ações de

Adaptação

Lista de

Funcionalidades

Visão

Especulação

Produto

Final

Adaptação

Plano de

Entregas Exploração

Funcionalidade

Pronta

Encerramento



Metodologia Ágil - Ciclo de Vida

Fonte: Sliger & Broderick, 2008.

Projeto Ágil

Lançamento Ágil

ou Trimestre

Iteração Ágil

Trabalho Diário

Lançamento

ou

Trimestre

Lançamento

ou

Trimestre

Lançamento

ou

Trimestre

Retrospectiva

do Projeto

Retrospectiva

do Lançamento

Demonstração

de Iteração,

Revisão,

Retrospectiva

Atualização de

Progresso

Planejamento:

Visão, Roteiro

do Produto

Iteração Iteração Iteração Planejamento

do Lançamento

Trabalho

Diário Planejamento

de Iteração

Trabalho

Diário

Trabalho

Diário

Realização

de Tarefas Reunião Diária

Realização

de Tarefas

Realização

de Tarefas


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

ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

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

Software em funcionamento mais que documentação abrangente

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

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,

valorizamos mais os itens à esquerda.


Manifesto Ágil

Fonte: http://agilemanifesto.org/iso/ptbr/



12 Princípios do Manifesto Ágil

Fonte: http://agilemanifesto.org/iso/ptbr/

1 2 3 4 5 6

7 8 9 10 11 12

Nossa maior

prioridade é

satisfazer o cliente,

através da entrega

adiantada e contínua

de software de valor.

Aceitar mudanças de

requisitos, mesmo no

fim do desenvolvimento.

Processos ágeis se

adequam a mudanças,

para que o cliente possa

tirar vantagens

competitivas.

Entregar software

funcionando com

frequência, na escala

de semanas até

meses, com

preferência aos

períodos mais curtos.

Pessoas relacionadas à

negócios e

desenvolvedores

devem trabalhar em

conjunto e

diariamente, durante

todo o curso do

projeto.

Construir projetos ao

redor de indivíduos

motivados. Dando a

eles o ambiente e

suporte necessário, e

confiar que farão seu

trabalho.

O método mais

eficiente e eficaz de

transmitir informações

para, e por dentro de

um time de

desenvolvimento, é

através de uma

conversa cara a cara.

Software funcional

é a medida

primária de

progresso.

Processos ágeis

promovem um ambiente

sustentável. Os

patrocinadores,

desenvolvedores e

usuários, devem ser

capazes de manter

indefinidamente, passos

constantes.

Contínua atenção

à excelência

técnica e bom

design, aumenta a

agilidade.

Simplicidade: a

arte de maximizar

a quantidade de

trabalho que não

precisou ser feito.

As melhores

arquiteturas,

requisitos e

designs emergem

de times auto-

organizáveis.

Em intervalos

regulares, o time

reflete em como ficar

mais efetivo, então, se

ajustam e otimizam

seu comportamento

de acordo.


“As metodologias ágeis assumem que

nem o cliente nem a equipe de

desenvolvimento tem conhecimento

total dos requisitos do sistema no início

e que é importante ter mecanismos

que lhes permitirão aprender e evoluir

à medida que o conhecimento é obtido

– sem recriminação de parte a parte”.

Highsmith, 2002





Metodologia Clássica X Metodologia Ágil

Fonte: Sliger & Broderick, 2008

Guiado

por uma

visão de

valor Guiado

por um

plano

Variável

Fixo Requisitos/Escopo Recursos Cronograma

Recursos Cronograma Requisitos/Escopo

Clássica Ágil




Eu conheço todos os

detalhes sobre o que

deve ser feito

(detalha-se o plano e

requisitos).

Clá

ssic

a

Ág

il

Eu conheço a visão

do produto/projeto

(inicia com visão

geral definida e

requisitos de maior

valor).

Termina com

todos os

requisitos

entregues.

Termina ao

definir que os

goals da visão

foram

alcançados.

Inspeção e Adaptação

Guiado por

um plano

(Plan-Driven)

Empírico

Guiado por

uma visão de

valor

Fonte: Sliger & Broderick, 2008




Metodologia Clássica Metodologia Ágil

Objetivo

Principal Orientado por atividade e centrado em processo. Orientado por produto e centrado em pessoas.

Tipo de

Projeto Estáveis e com baixo nível de mudanças.

Projetos com mudanças constantes e que necessitam

de respostas rápidas.

Tamanho Aplicável em projetos de todos os tamanhos. Mais

eletivo em projetos de maior duração.

Mais efetivo em projetos pequenos (5-10 pessoas),

porém não existe restrições em ser implementado

em projetos de maior porte.

Gerente de

Projeto Controle total do projeto. Papel de facilitador ou coordenador.

Equipe de

Projeto Atuação com papéis claros e bem definidos.

Atuação colaborativa em todas as atividades do

projeto.

Cliente Participa das fases iniciais de requisitos e das

validações dos produtos.

Essencial. Deve ser parte integrante da equipe do

projeto.

Fonte: Chin, 2004.




Metodologia Clássica Metodologia Ágil

Planejamento Detalhado e os envolvidos têm o papel de validação,

não participam da elaboração do planejamento.

Curto e com a participação de todos os envolvidos

na elaboração do planejamento.

Arquitetura Definida com foco em todo o projeto e na

reusabilidade.

Aplicação de design simples. Evolui junto com o

projeto e baseia-se na refatoração.

Modelo de

Desenvolvi-

mento

Cascata, espiral e iterativo. Iterativo e incremental.

Comunicação Formal. Informal.

Controle de

Mudanças

Processo formal de identificação e aprovação entre

os envolvidos. Incorporação de novos requisitos

pode ser lento e caro.

Dinâmico e com rapidez de incorporação nas

iterações.

Fonte: Chin, 2004.


Reflexão: qual metodologia é melhor para gerenciar projetos? Clássica ou Ágil?



Não existe metodologia melhor e pior, mas sim a mais adequada para diferentes realidades e situações.





Metodologia Clássica ou Ágil: Quando Utilizar?

Fonte: Chin, 2004.

Múltiplas organizações

externas interessadas/

envolvidas

Múltiplas organizações

internas interessadas/

envolvidas

Uma única organização

interessada

Projetos Operacionais Clássico Clássico Clássico

Projetos de

Desenvolvimento de

novos produtos/processos

Clássico/Ágil Clássico/Ágil Ágil

Projetos de

desenvolvimento de novas

tecnologias/plataformas

Clássico/Ágil Ágil Ágil



Principais Metodologias de Gerenciamento Ágil

Scrum

FDD - Feature Driven Development (Desenvolvimento Guiado por

Funcionalidades)

Crystal Methods

MSF Agile

XP - Extreme Programming

ASD - Adaptive Software Development

AM - Agile Modeling

DSDM - Dynamic Systems Development Method

LD - Lean Development


Co-criado por Jeff Sutherland e Ken Schwaber, Scrum é um

framework, utilizado para organizar times e entregar

resultados de maneira mais produtiva e com alta qualidade.

Fundamentado na teoria de controle de processos

empíricos, emprega uma abordagem iterativa e incremental

para otimizar a previsibilidade e controlar riscos.

A inspiração inicial do Scrum foi o artigo “The New Product

Development Game” de Hirotaka Takeuchi e Ikujiro Nonaka,

publicado em 1986 pela HBR.

Baseia-se em três pilares: transparência, inspeção e

adaptação.


Scrum - Definição


O nome Scrum vem do Rugby. Durante uma partida, chama-se Scrum quando os jogadores dos dois times ficam frente à frente, de cabeça baixa, pressionando-se uns contra os outros na

disputa pela posse de bola.




Scrum - Processo


Revisão de Sprint Entrega do trabalho realizado

durante o Sprint e atualização do

Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe

Retrospectiva de Sprint Análise do Sprint encerrado e

definição de melhorias .

Reunião Diária Reunião de 15 min.

Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog

Quantidade de trabalho

que será entregue no

final do Sprint

Scrum Board

Product

Backlog

Release


Vamos simular um processo Scrum?




O Scrum pode ser tanto realizado com papel e post-its, quanto através de ferramentas online, que organizam todo o processo.


Scrum Board - Ferramentas Online

Agilo For Scrum - http://www.agiloforscrum.com/

Banana Scrum - http://www.bananascrum.com/

Daily Scrum - http://daily-scrum.com/

Eylean - http://www.eylean.com/

Trello - http://www.trello.com/

ScrumDesk - http://www.scrumdesk.com/

ScrumDo - http://www.scrumdo.com/

Scrumwise - http://www.scrumwise.com/

Scrumy - https://scrumy.com



Quem são as PESSOAS envolvidas no Scrum?




Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Product

Backlog

Release

Ativ

idad

es

Priorização

User

Stories

Sprint Backlog



final do Sprint

Scrum Board


PO - Product Owner (Dono do Produto)

É o responsável pelo financiamento do

projeto e por maximizar o retorno do

investimento (ROI).

É o PO quem decide/ajusta as

funcionalidades do produto, as prioridades,

as datas de lançamento e conteúdo.

É ele também o responsável por aceitar ou

rejeitar o resultado dos trabalhos


Ideia/Visão

Product Owner


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Product

Backlog

Release

Ativ

idad

es

Priorização

User

Stories

Sprint Backlog



final do Sprint

Scrum Board


Time/Equipe

Responsável pela realização do

trabalho.

Cross-functional

Multidisciplinar

Auto-organizado

Todos os skills e habilidades necessárias

para desenvolver o produto

Tamanho recomendado: 5 a 9 pessoas



Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Product

Backlog

Release

Ativ

idad

es

Priorização

User

Stories

Sprint Backlog



final do Sprint

Scrum Board


Scrum Master

Representa a gerência para o projeto.

É responsável pela aplicação dos valores e práticas do Scrum.

Atua como uma espécie de líder e facilitador.

Trabalha próximo ao PO e deve garantir que o time esteja

operando sob máxima eficiência e eficácia, seguindo as regras

e práticas do Scrum.

Remove obstáculos.

Garante a plena funcionalidade e produtividade da equipe.

Garante a colaboração entre os diversos papéis e funções.

É um escudo para interferências externas.



Os papéis das pessoas no Scrum mudam de projeto a projeto. O Scrum Master do projeto atual, por exemplo, não será, necessariamente, o Scrum Master do projeto seguinte.




Quais são os ARTEFATOS que o Scrum utiliza?




Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Product Backlog

Uma lista de todos os desejos/

requerimentos do PO no projeto.

PO é o dono deste artefato.

Existe do começo ao fim do projeto e não

é estático: caso o PO identifique novas

necessidades ao longo do projeto, pode

alterar o Product Backlog, incluindo,

excluindo ou alterando desejos.



Product Backlog - Exemplo


Projeto: reestruturar os serviços disponibilizados aos gestores

Banco de Horas e

Horas Extras Folha de

Pagamento

Controle de

Benefícios

Reembolso de

Despesas

Avaliação de

Desempenho Controle de Férias


Vamos definir um Product Backlog juntos?



Atividade

1. Organizem-se em três grupos.

2. Escolham um projeto de uma empresa do grupo.

3. Utilizando as folhas sulfites em branco e os post-its,

construam o Product Backlog como se vocês

fossem o Product Owner do projeto.

4. Apresentem o resultado e participem da discussão

em sala.

5. Guardem o Product Backlog produzido. Iremos

retomá-lo adiante.



Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Product Backlog Release

São os desejos/requerimentos

que o PO prioriza a partir do

Product Backlog para serem

trabalhadas pelo Time do Scrum

no próximo período de trabalho.

A priorização, idealmente,

considera o valor e importância

de cada item para o projeto e

pode ser refeita a cada ciclo de

trabalho, a medida que as

funcionalidades são executadas

e os desejos do PO sofrem

alterações.


Product Backlog Product

Backlog

Release

Priorização do PO



Product Backlog Release - Matriz de Priorização

Ris

co

Valor

Alto

Baixo

Baixo Alto

Evite Faça

Primeiro

Faça por

Último

Faça em

Segundo



Product Backlog Release - Priorização

Menor valor

Maior valor

Cada Sprint implementa as

funcionalidades de maior valor.

Funcionalidades podem ser

removidas a qualquer

momento.

Novas requisições são incluídas no

Backlog mediante priorização.

Repriorizações podem ser feitas a

qualquer momento.



Product Backlog Release - Exemplo

Projeto: reestruturar os serviços disponibilizados aos gestores

Menor valor

para os

gestores

Maior valor

para os

gestores

Product Backlog

Release

Banco de Horas

e Horas Extras

Folha de

Pagamento

Controle de

Benefícios

Avaliação de

Desempenho

Reembolso de

Despesas

Controle de

Férias


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


User Stories

As User Stories são levantadas pelo

time junto ao PO em entrevista, durante

o planejamento do ciclo de trabalho.

Tradicionalmente, elas são escritas na

forma: Como um <ator>, eu gostaria

de <ação>, para <motivo/valor de

negócio>.


Product Backlog Release

User Stories

Desdobramentos do Product Backlog Release em forma de necessidades/benefícios

ao usuário, de modo a aprofundar a compreensão e abrangência dos

desejos/requerimentos feitos pelo PO.


User Stories - Nível de Desdobramento

A User Story é o desdobramento do Product Backlog Release até o ponto de um

requerimento potencialmente entregável e implementável no projeto.

Antes de chegar ao ponto de User Story, o desdobramento pode passar por estágios

anteriores, chamados Theme e Epic.


“Como um <ator>, eu

gostaria de <ação>,

para <motivo/valor de

negócio>”

Theme

Epic

Epic

User Story

User Story

User Story


User Stories - Exemplo


Banco de Horas

e Horas Extras

Como cliente, eu

gostaria de

gastar menos

tempo

controlando

banco de horas

de minha equipe

Como cliente, eu gostaria de ter acesso às informações mais

facilmente

Como cliente, eu gostaria de gerenciar

não ter que ficar apontando horas

manualmente

Como cliente, eu gostaria de não ter que

ficar assinando autorização de hora-

extra a toda momento

Como cliente, eu gostaria de autorizar previamente um conjunto de horas-extras

Como cliente, eu gostaria que hora-extra não autorizada fosse automaticamente barrada

Como cliente, eu gostaria

que o RH melhorasse suas

ferramentas de controle de

hora-extra


de adicionar não gastar

tempo revisando as horas-

extras no final do mês

Product Backlog

Release

Epic Theme User Stories


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Atividades

Desdobramento da User Story em atividades necessárias para que o incremento

desejado seja entregue.


User Stories Atividades


Atividades


User Story

User Story

User Story

Atividade

Atividade

Atividade

Atividade

Atividade

Epic

Epic

Theme

É comum que as tarefas sejam quebradas e detalhadas a medida que o projeto é

desenvolvido e as coisas a serem feitas se tornam mais conhecidas.


Atividades - Exemplo


Banco de Horas

e Horas Extras

Como cliente, eu

gostaria de

gastar menos

tempo

controlando

banco de horas

de minha equipe

Como cliente, eu gostaria de ter acesso às informações mais

facilmente

Como cliente, eu gostaria de gerenciar

não ter que ficar apontando horas

manualmente

Como cliente, eu gostaria de não ter que

ficar assinando autorização de hora-

extra a toda momento

Como cliente, eu gostaria de autorizar previamente um conjunto de horas-extras

Como cliente, eu gostaria que hora-extra não autorizada fosse automaticamente barrada


que o RH melhorasse suas

ferramentas de controle de

hora-extra


de adicionar não gastar

tempo revisando as horas-

extras no final do mês

Melhorar relatórios de

controle

Gerar alertas automáticos

Product Backlog

Release

Epic Theme User Stories Atividade


Desdobramento de Atividades - Exemplo


Melhorar relatórios de

controle


A medida que o projeto é desenvolvido e as coisas se tornam conhecidas, é

comum as tarefas serem detalhadas.

Criar campo com quantidade total de horas realizadas no passado

Integrar relatório atual com sistema de cartão

Gerar reports automáticos diários sobre movimentação do dia anterior

Melhorar design dos relatórios

Utilizar BI para que os gestores possam cruzar informações de horas

Configurar sistema de ponto para gerar alertas por email automáticos

Criar algoritmo para processamento de alertas automáticos

Rodar piloto de alertas automáticos


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Sprint Backlog

Conjunto de atividades necessárias para

que a porção do Product Backlog que o

PO elegeu como mais importante no

momento seja realizada e entregue

pela equipe dentro do período de

trabalho estabelecido (Sprint).

Qualquer membro da equipe pode

adicionar, apagar ou mudar tarefas no

Sprint Backlog.



Sprint Backlog - Exemplo


Criar campo com

quantidade total de

horas realizadas no

passado

Integrar relatório

atual com sistema

de cartão

Gerar reports

automáticos diários

sobre

movimentação do

dia anterior

Melhorar design

dos relatórios

Utilizar BI para que

os gestores possam

cruzar informações

de horas

Configurar sistema

de ponto para

gerar alertas por

email automáticos

Criar algoritmo

para

processamento de

alertas automáticos

Rodar piloto de

alertas automáticos


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Scrum Board É um quadro de tarefas que garante visibilidade do

status das tarefas.

Auxilia a equipe a entender o que cada um está

fazendo, o que está em fila, em construção, em

testes, homologação, produção e outros status

necessários, oferecendo percepção de fluxo,

estoque e desperdício, essenciais para a boa

realização da reunião diária.

O Scrum Board costuma ter, no mínimo, 3 colunas -

to do (a fazer); doing (em execução); done (feito) -,

mas cada equipe pode criar quantas linhas e

colunas forem mais adequadas.

As User Stories selecionadas para o Scrum Board

devem ser iniciadas e concluídas dentro de um

período de trabalho estabelecido (Sprint).


Backlog A Fazer Em Execução Feito


Backlog A Fazer Em Execução Feito


Scrum Board - Exemplo

Configurar

sistema de

ponto para gerar

alertas por email

automáticos

Melhorar design

dos relatórios

Criar algoritmo

para

processamento

de alertas

automáticos Rodar piloto de

alertas

automáticos

Utilizar BI para

que os gestores

possam cruzar

informações de

horas

Gerar reports

automáticos

diários sobre

movimentação

do dia anterior

Criar campo

com quantidade

total de horas

realizadas no

passado

Integrar

relatório atual

com sistema

de cartão


Quais são e como são as CERIMÔNIAS do gerenciamento ágil por Scrum?




Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Sprint Ciclo de trabalho com duração fixa pré-

determinada de 1 a 4 semanas.

No Scrum, o projeto progride em uma série de

Sprints, que ocorrem sucessivamente, similar às

iterações do XP.

Idealmente, o time realiza entregas e

incrementos no projeto a cada Sprint.

Um período constante leva a um melhor “ritmo”.

A quantidade de Sprints necessárias para que o

projeto seja finalizado é bastante variável,

conforme complexidade do projeto, número de

pessoas envolvidas, velocidade de trabalho, etc.



Uma interrupção anormal de Sprint pode ser realizada, caso o PO decida que não faz sentido terminar o trabalho iniciado. Nesse caso, inicia-se um novo Sprint.




Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Sprint Planning (Planejamento de Sprint)


Reunião em que o PO informa o time sobre o

projeto e priorização do Product Backlog.

A partir das informações do PO, toda a equipe de

Scrum trabalha, de forma colaborativa, na criação

do Sprint Backlog, construindo as user stories,

desdobrando-as, identificando e estimando as

atividades.

Dentre as tarefas estabelecidas para o próximo

Sprint, cada membro da equipe escolhe o trabalho

que fará. As tarefas nunca são atribuídas.

Duração estimada: 1 dia.




Atividade Responsável Horas

Atividade 1 Rodrigo 8

Atividade 2 João 4

Atividade 3 Denise 2

Etc.

Release 1

Release 2

Release 3

User Story A User Story B

Atividade 1 Atividade 2



Atividade 7

Sprint

Backlog 1

Menor valor

Maior valor




Sprint 1 Sprint 2 em diante...

Atividade 1

Plano de Release

Atividade 2

Atividade 5

Atividade 4

Atividade 3

Atividade 8

Atividade 7

Atividade 6

Atividade 11

Atividade 10

Atividade 9


Como analisar a complexidade e estimar a duração das tarefas? Febracorp University




Sprint Planning: Planning Poker




Sprint Planning: Planning Poker - Definição

Também chamado de Scrum Poker, é uma

técnica de gamificação para estimar

complexidade, esforço e tamanho relativo.

O método foi definido e nomeado pela

primeira vez por James Grenning em 2002 e

mais tarde popularizado por Mike Cohn no

livro Agile Estimating and Planning.



Sprint Planning: Planning Poker - Como Funciona

1. Cada participante recebe um baralho de 11 cartas, sendo

uma “?”, uma “xícara de café” (pausa - opcional) e 9 cartas

numeradas com base na sequência de Fibonacci: 0; ½; 1; 2; 3;

5; 8; 13; 20; 40 e 100.

2. Uma pessoa, geralmente o PO, assume o papel de

moderador do jogo.

3. Para cada atividade a ser estimada, o moderador lê a

descrição correspondente e esclarece as eventuais questões

que os participantes tiverem.

4. Depois que todas as dúvidas forem esclarecidas, cada

participante escolhe secretamente uma carta que representa

a sua estimativa para a atividade analisada, colocando-a

sobre a mesa com a face numerada voltada para baixo.




5. Depois que todos os participantes tiverem feito suas

escolhas individuais, as cartas são reveladas, sendo todas

desviradas ao mesmo tempo sobre a mesa, de modo que

todos os participantes possam ver todas as estimativas

feitas.

6. Se as estimativas divergirem significativamente, as pessoas

responsáveis pela maior e pela menor estimativa

justificam suas escolhas.

7. As estimativas são então discutidas até que se chegue a

um consenso.

Atividade Valor

Planning Poker

Atividade 1 5

Atividade 2 20

Atividade 3 40

Atividade 4 40

Atividade 5 5

Atividade 6 40

Atividade 7 5




8. O time então decidirá quanto trabalho pode

realizar em determinado Sprint com base nas

estimativas. A partir das estimativas ao lado, a

equipe decide, por exemplo, que pode terminar

as Atividades 1, 2, 3 e 4 no primeiro Sprint, de

uma semana.

9. Quando o Sprint terminar, se a equipe tiver

realmente realizado as atividades 1, 2, 3 e 4, é

possível concluir que a equipe é capaz de

entregar uma estimativa de 105 em uma semana

– isto é chamado de Velocidade do time.

Atividade Valor

Planning Poker Sprint

Atividade 1 5 1

Atividade 2 20 1

Atividade 3 40 1

Atividade 4 40 1

Atividade 5 5 2

Atividade 6 40 2

Atividade 7 5 2


Velocidade: tempo em que um time consegue converter ítens do Product Backlog em produto funcional.

É estabelecida empiricamente a partir da capacidade do time de completar determinado conjunto de trabalho por iterações.






9. Com a realização sucessiva das rodadas

de Sprint e respectivos planejamentos, a

equipe aprenderá com a experiência e

será capaz de estimar com segurança o

número de horas necessárias para

executar cada atividade, de acordo com o

valor de complexidade atribuído pelo

Planning Poker.

Atividade Valor

Planning Poker

Estimativa

(Horas)

Atividade 1 5 8

Atividade 2 20 12

Atividade 3 40 20

Atividade 4 40 20

Atividade 5 5 8

Atividade 6 40 20

Atividade 7 5 8



Sprint Planning (Planejamento de Sprint) - Exemplo

User Story Atividade Respon-

sável

Valor

Planning Poker

Estimativa

(horas)

Como cliente, eu gostaria que o RH melhorasse suas ferramentas de controle de hora-extra

Melhorar relatórios de controle

Criar campo com quantidade total de horas realizadas no passado João 5 8

Integrar relatório atual com sistema de cartão João 20 12

Gerar reports automáticos diários sobre movimentação do dia anterior João 40 20

Melhorar design dos relatórios Juliana 40 20

Utilizar BI para que os gestores possam cruzar informações de horas Juliana 5 8


Configurar sistema de ponto para gerar alertas por email automáticos Rodrigo 20 12

Criar algoritmo para processamento de alertas automáticos Rodrigo 20 12

Rodar piloto de alertas automáticos Anderson 20 12


Atividade 1. Retomem os grupos e o Product Backlog produzido

na atividade anterior.

2. Façam uma reunião de Sprint Planning:

Priorizem e estabeleçam o Product Backlog

Release.

Escrevam as User Stories.

Definam as tarefas.

Estimem as tarefas utilizando Planning Poker.

3. Utilizem o material disponível: folhas, post-its, fita-

crepe, canetas, baralho de planning poker


em sala.

5. Guardem o planejamento produzido. Iremos

retomá-lo adiante.



Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Reunião Diária


Reunião diária de 15 minutos em que a equipe do

Scrum valida três questões:

O que foi feito ontem?

O que será feito hoje?

Há algum problema atrapalhando?

A reunião é regida pelo Scrum Master e cada

membro do time atualiza o status de seu trabalho,

utilizando o Scrum Board. O PO não participa.

Para que a reunião cumpra a proposta de ser ágil,

todos devem ficar em pé.

Caso a equipe aponte algum obstáculo, o mesmo

deve ser solucionado posteriormente.


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Revisão de Sprint


Reunião informal, sem slides, realizada ao final de cada Sprint, em que a equipe

apresenta as entregas do Sprint para o PO.

As entregas são avaliadas pelo PO, que pode aceitá-las ou recusá-las, demandando

mudanças e adaptações.

Toda a equipe participa.

Duração aproximada: 2 horas.


Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Retrospectiva de Sprint


Reunião ao final de cada Sprint em que a equipe analisa o que funcionou e o que não funcionou no Sprint recém encerrado:

Quais foram os pontos positivos?

O que podemos melhorar para a próxima Sprint?

Resulta em uma lista de ações a serem endereçadas no próximo Sprint.

Na Retrospectiva de Sprint, o Scrum Master é o facilitador.

Toda a equipe participa, mas a presença do PO é opcional.

Duração aproximada: 15 a 30 minutos.


“O que não é medido não é gerenciado.”

William Edwards Deming




Quais são as métricas do Scrum?




Scrum - Processo




Product Backlog

Ideia/Visão

Product Owner

Product Backlog

Time/Equipe




Scrum Master

Burndown Chart

Priorização

User

Stories Ativ

idad

es Sprint Backlog



final do Sprint

Scrum Board

Product

Backlog

Release


Burndown Chart


Demonstra o progresso das tarefas, quanto a

equipe já “queimou” das tarefas a serem

entregues em um período de trabalho

estabelecido (Sprint).

Apenas o Scrum Board não é capaz de

indicar a tendência entre previsão, aferição e

realizado. A única forma de ter esta

informação sem o Burndown Chart é

somando os post-its e analisando-os sob

diferentes aspectos.


Burndown Chart - Exemplo



Entregas

Est

imati

va e

m

Ho

ras

100

16

28

24

17

15

PROJETO Product 1 Product 2 Product 3 Product 4 Entrega Final

Ideal: 27h

Real: 28h

Ideal: 25h

Real: 24h

Ideal: 17h

Real: 17h Ideal: 13h

Real: 15h Ideal: 18h

Real: 16h


Burndown Chart - Exemplo


1. Retomem os grupos e o Sprint Planning produzido

na atividade anterior.

2. Simulem o processo de Scrum, realizando:

Reunião Diária

Revisão de Sprint

Retrospectiva de Sprint

Consolidação das métricas

3. Utilizem o template do Scrum Board e demais

materiais disponíveis: folhas, post-its, fita-crepe,

canetas.


em sala.


Atividade


O Gerenciamento Ágil e o Gerenciamento Clássico têm pontos em comum?





Ágil e Clássico: Comparativo

Gerenciamento da Integração

Clássico Ágil

Desenvolver o plano de

gerenciamento do

projeto

Planejamento do release

e iterações

Execução do plano de

projeto Trabalho iterativo

Monitorar e controlar o

trabalho do projeto

Facilitar, inspecionar,

adaptar, liderar,

colaborar

Realizar o controle

integrado das mudanças

Feedback constante e

Backlog priorizado

Gerenciamento do Escopo

Clássico Ágil

Definir o escopo Backlog e reuniões de

planejamento

Criar WBS (EAP

Criar FBS

Verificar o escopo

Definição dos critérios

de aceitação e

envolvimento do cliente

Controlar o escopo Feedback constante e

Backlog priorizado




Gerenciamento dos Custos

Clássico Ágil

Estimar os custos Plano de release

Determinar o orçamento Orçamento de

release/iteração

Controlar os custos Priorizar o Product

Backlog

Gerenciamento de Qualidade

Clássico Ágil

Planejar a qualidade Critérios de aceitação e

definição de pronto

Realizar a garantia da

qualidade

Qualidade como parte

intrínseca das atividades

do time

Realizar o controle da

qualidade

Definição dos critérios

de aceitação/pronto;

Testar cedo e

frequentemente




Gerenciamento do Tempo

Clássico Ágil

Definir as atividades Planejamento da iteração

Sequenciar as atividades Planejamento da iteração

Estimar os recursos das

atividades

Membros do time escolhem e

estimam as atividades

Desenvolver o cronograma Roadmap do projeto, planos

de release e iteração

Controlar o cronograma

Atualizar roadmap e planos

de release com base na

velocity

Gerenciamento dos Riscos

Clássico Ágil

Identificar os riscos:

análise qualitativa;

planejar as respostas

aos riscos

Planejamento

iterativo; Daily

Stand-ups e

Retrospectivas

Monitorar e

controlar os riscos

Stand-ups e

radiadores de

informação

altamente visíveis


Resumo da ópera...




Quando um Sprint termina, outro começa, e assim sucessivamente.





Para cada Sprint iniciado, realiza-se uma reunião de Sprint Planning. Durante o Sprint, acontecem tantas reuniões diárias quanto forem os dias de duração do Sprint. Ao final do Sprint ocorre uma reunião de Revisão de Sprint, para entrega e validação do que foi produzido. Em seguida, é feita a Retrospectiva de Sprint, para avaliar o ciclo de trabalho que se encerrou.



Na teoria, o Scrum é simples. Na prática, nem tanto. Mudança requer coragem, persistência e foco em melhoria contínua.

Envolva sua equipe!




Para uma implantação bem sucedida, é vital aliar as práticas ágeis de gestão com práticas técnicas (TDD, Refatoração, Pair Programming, integração contínua, etc.).




Vamos praticar o Scrum?





Scrum Lego


Atividade – Scrum Lego - ESCOPO


1. Construir uma cidade de Lego utilizando Scrum para gerenciar o projeto.

2. Tempo: 180 minutos.

3. Materiais: lego, post-its, canetas para vidro, baralho de planning poker.


Scrum Lego - Roteiro


Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum




Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum

Divisão de

grupos

Definição

dos papéis

Estação de

trabalho


Preparação


Divisão de grupos:

Organizem-se em 4 grupos.

Definição dos papéis:

Um aluno de cada grupo será escolhido pelo professor

para interpretar o papel de Scrum Master.

Os demais alunos de cada grupo serão o Time do Scrum.

O professor interpretará o Product Owner – ele é o decisor

do projeto. A cidade de Lego é DELE.

Estação de trabalho

Separem uma ou duas mesas de trabalho para cada grupo.

Posicionem a estação de trabalho próximo a uma

superfície de vidro (lousa ou janela).

Desenhem no vidro o Scrum Board e o Burndown Chart do

grupo pra utilizar durante a atividade.




Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum

Product

Backlog

Especifica-

ções Gerais

do Product

Backlog

Divisão do

Product

Backlog por

grupo


Atividade – Product Backlog


A lista de desejos/requerimentos do PO para o projeto

(cidade de Lego) é a seguinte:

1 escola

1 igreja

1 hospital

1 bombeiro

4 casas

4 prédios

4 lojas

6 árvores

1 ponte

1 passarela




Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum

Product

Backlog

Especifica-

ções Gerais

do Product

Backlog

Divisão do

Product

Backlog por

grupo


Especificações Gerais do Product Backlog


Product

Backlog Quantidade

Dimensão (comp. X largura

X altura)

Cor

Parede Telhado

Escola 1 6 X 16 X 6 2 cores: azul, amarelo, laranja, vermelho 1 cor: vermelho ou marrom

Igreja 1 12 X 6 X 8 1 cor: vermelho, laranja ou marrom 1 cor: vermelho ou marrom

Hospital 1 10 X 8 X 10 1 cor: branco Não

Bombeiro 1 8 X 8 X 12 1 cor: vermelho Não

Casa 3 6 X 8 X 5 1 cor: a escolher 1 cor: vermelho ou marrom

Prédio 3 8 X 8 X 13 1 cor: a escolher Não

Loja 3 6 X 10 X 5 1 cor: a escolher Não

Árvore 4 Altura: 8 Tronco - 1 cor: marrom ou laranja Copa - 1 cor: verde

Ponte 1 15 X 4 X 4 1 cor: a escolher -

Passarela 1 12 X 9 X 3 1 cor: a escolher -


Especificações Gerais do Product Backlog - Dimensão


Largura = número de

encaixes de Lego. Ex.: 6 Comprimento = número de

encaixes de Lego. Ex.: 6

Altura (inclui telhado,

quando houver) = número

de peças de Lego. Ex.: 3




Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum

Product

Backlog

Especifica-

ções Gerais

do Product

Backlog

Divisão do

Product

Backlog por

grupo


Divisão do Product Backlog por Grupo


Todos os times construirão um único

projeto - uma única cidade de Lego.

Os times não competem entre si, ao

contrário, eles trabalham para o

mesmo cliente/contratante.


Divisão do Product Backlog por Grupo


Para cada grupo caberá a seguinte responsabilidade de entrega de desejos/requerimentos do PO:

Igreja

Bombeiro

Hospital

Casa

Casa

Casa

Prédio

Prédio

Prédio

Loja

Loja

Loja

Árvore

Árvore

Ponte

Árvore

Árvore

Passarela

GR

UP

O 2

G

RU

PO

3

GR

UP

O 4

Escola Casa Prédio Loja Árvore Árvore

GR

UP

O 1




Preparação

Apresenta-

ção do

projeto

O Jogo:

Cerimônias

do Scrum


O Jogo: Cerimônias do Scrum


• Execução das atividades conforme

planejamento.

• Estimativa com planning poker.

•Desdobramento do product backlog

em user stories e atividades.

• Entrevista com PO.

• Priorização por sprint.

• Atribuição de responsabilidades.

Sprint

Planning (15-30

min)

Sprint (10 min)

Daily

Meeting

(3 min)

Sprint

Review

(3 min)

Início

•Atualização do Scrum Board

• Atualização do Burndown Chart

•Três perguntas: O que foi feito? O que

será feito? Há algum problema

atrapalhando?

• Entregas para o PO.

• Avaliação das entregas pelo PO.

• Aprovação/Reprovação das entregas

pelo PO.

• Reespecificação, se necessário.

3X


Referências Bibliográficas AMARAL, Daniel. Metodologias Ágeis em Gerenciamento de Projetos.

Disponível em: <http://pt.slideshare.net/amaraldn/magp-2011-versaoweb>.

Acesso em: 28 set. 2015.

BOSSIDY, Larry & CHARAN, Ram. Execução - A Disciplina para Atingir

Resultados. Rio de Janeiro: Elsevier, 2008.

CHIN, Gary. Agile Project Management: How to succeed in the face of

changing project requirements. New York: Amacom, 2004.

CRUZ, Fábio. Scrum e PMBOK unidos no gerenciamento de projetos. Rio de

Janeiro: Brasport , 2013.

HELDMAN, Kim. Gerência de Projetos: Guia para o exame oficial do PMI.

Rio de Janeiro: Elsevier, 2009.

HIGHSMITH, Jim. Agile Project Management: Creating Innovative Products.

Upper Saddle River: Addison-Wesley, 2010.

LACEY, Mitch. The Scrum Field Guide: Practical Advice for Your First Year.

Upper Saddle River :Addison-Wesley, 2012.

SLIGER, Michele & BRODERICK, Stacia. The Software Project Manager's

Bridge to Agility. Upper Saddle River: Addison-Wesley, 2008.


©2017 by Febracorp University. Este trabalho, incluindo todos os modelos, slides e textos estão sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional. Para ver uma cópia desta licença, visite http://creativecommons.org/licenses/by-nc-sa/4.0/ Você pode utilizar e distribuir esse material desde que a fonte “FEBRACORP UNIVERSITY” seja mencionada. Autorizações adicionais podem ser concedidas no âmbito desta licença pelo e-mail abaixo: [email protected] ©2017 by Febracorp University. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/ You must give appropriate credit to Febracorp University, provide a link to the license, and indicate if changes were made. You may not use the material for commercial purposes. If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

WORKSHOP: GESTÃO ÁGIL DE PROJETOS PARA RH COPYRIGHT

WORKSHOPliveuniversity.com/downloads/Workshop - Material de Aula - Gestão... · Metodologia Ágil...

Documents

Transcript of WORKSHOPliveuniversity.com/downloads/Workshop - Material de Aula - Gestão... · Metodologia Ágil...