gerenciamento de projetos plano de aula - pmpartner.com.br€¦ · plano de aula aula conteúdo a...

1

Plano de AulaAula Conteúdo a ser Abordado Metodologia a ser

Utilizada20/11/13 Gerenciamento de Recursos Humanos: desenvolver o

plano de recursos humanos, mobilizar a equipe do projeto.Exercícios.

Aula Expositiva, apresentação em PowerPoint; Exercício.

25/11/13 Gerenciamento de Recursos Humanos: desenvolver a equipe do projeto, gerenciar a equipe do projeto.Exercícios.

Aula Expositiva, apresentação em PowerPoint;Exercício.

27/11/13 Gerenciamento das Comunicações: identificar as partes interessadas, distribuir as informações, gerenciar as expectativas das partes interessadas.Exercícios.


02/12/13 Gerenciamento das Comunicações: reportar o desempenho, planejar as comunicações.Exercícios.


04/12/13 Gerenciamento das Comunicações;Avaliação Final.

Aula Expositiva, apresentação em PowerPoint; Prova Final.

BI Analytics

Gerenciamento de Projetos

DANIEL AQUERE DE OLIVEIRA, MSc, MBA, PMP, ASM MBA BI Analytics – Gestão de Projetos

2


WHO ARE YOU????

3


WHO ARE YOU????

4


WHO ARE YOU????

5


WHO ARE YOU????

6


O QUE ACONTECE HOJE???

7



8


M U N D O L Í Q U I D O


9


A oposição entre o mundo sólido e o mundo líquido é a basedo pensamento de Zygmunt Bauman, sociólogo polonês, 90anos, professor da London School of Economics e um dosmais respeitados intelectuais da atualidade.

O mundo líquido entende que o mundo está sem forma, nopassado tínhamos certezas absolutas, hoje tudo se transformadinamicamente.

O conceito de mundo líquido substituiu o conceito de pós-modernidade.


M U N D O L Í Q U I D O

10


Zyg

mu

nt

Bau

man


alg

um

as o

bra

s

11



12


E N T Ã O . . .


13


ESTRATÉGIAS

PROJETOS

PROCESSOS

1

2

3

ESTRATÉGICO

TÁTICO

OPERACIONAL

PIRÂMIDE DE GESTÃO

14


antes,

ALGUMAS PROVOCAÇÕES

15

GERENCIAMENTO Á G I LÉ A

INSTITUCIONALIZAÇÃO DO

C A O SFonte: Mundo Corporativo

Por favor, guardem esta frase...

16

Uma pessoa não é aquilo que diz ser durante a última

conversa.Ela é aquilo que foi durante

toda a sua história.Fonte: Rikler, escritor inglês


17

Falta de iniciativa pode ser ruim.

Iniciativa sem conhecimento pode ser um desastre

Fonte: Peter Drucker


18


“Não há nada que seja maior evidência de insanidade do que fazer a mesma coisa dia após dia e esperar resultados diferentes”

Albert Einstein(14 de Março de 1879 — Princeton, 18 de Abril de 1955)

PROVOCAÇÃO

19


GERENCIAMENTO DE PROJETOS

1. O que é?

2. Quais benefícios em praticar?

3. Quais competências são necessárias?

20


TRIÂNGULO DE TALENTOS PMI

21



22



23



GERENTE DOPROJETO

CRONOGRAMA

COMUNICAÇÃO

ESTATÍSTICAS

DOCUMENTAÇÃO

PROCESSOS

TEMPO

METAS

ORÇAMENTOCUSTOS

EQUIPE

O CHEFE (SPONSOR)

STAKEHOLDERS

QUALIDADE

RISCOS

24


TECNOLOGIA

e

FERRAMENTAS

MÉTODOSe

PROCESSOS

PESSOASe

CHA

Competências

Habilidades

Atitudes


25


MUNDOS DIFERENTES

PORÉM, COM OS MESMOS OBJETIVOS...

26


REFERÊNCIAS

27


REFERÊNCIAS

28


REFERÊNCIAS

29


MUNDO REAL DA GESTÃO DE PROJETOS

• Waterfall management

• Por que os projetos fracassam?

• Aumentando a probabilidade de sucesso dos projetos

• Ciclo de vida de um projeto

30


WATERFALL MANAGEMENT

O quê acontece aqui?ENTREGA

1

2

3

4

5

6

CONCEPÇÃOANÁLISE

DEFINIÇÃOREQUISITOS

PLANEJAMENTODESIGN

EXECUÇÃOIMPLEMENTAÇÃO

PRODUÇÃOMANUTENÇÃO

AVALIAÇÃOVERIFICAÇÃO

1. Várias fases longas2. Escopo fechado3. Definição clara e objetiva do que deve ser

feito

4. Equipes distintas e “isoladas”5. Validações das entregas somente no final6. Foco em documentação ampla7. Testes no final

64% das funcionalidades não eram utilizadas

31


LINHA DO TEMPO


32



33


Usamos boas ferramentas Mas, “miramos” para o lado errado!

OS MEIOS PARA ALCANÇARA META...

34


1. Metas e objetivos mal definidos;

2. Muitas atividades e pouco tempo para executá-las;

3. Informações insuficientes ou de má qualidade;

4. Tempo insuficiente para planejamento;

5. O produtos finais não serem bem definidos;

6. Cronogramas não realistas;

7. Expectativas não alinhadas com a realidade;

8. Problemas de relacionamento com os stakeholders;

9. Falta de participação das equipes nas tomadas de decisões;

10. Pouca compreensão da complexidade do projeto;

11. Estimativas financeiras incompletas;

12. Sistema de controle ineficiente;

13. Falta de liderança;

14. Falta de gerenciamento das mudanças;

15. Não gerenciamento das expectativas dos stakeholders.

16. n...

OUTROS MOTIVOS:

a. Escopo, Tempo, Custo

b. Planejamento

c. Equipes (competências e conflitos)

d. Mudanças

e. Habilidades e competências do GP

f. Estratégia da empresa

g. Condições de mercado

h. Turnover

i. Maturidade das lideranças

j. Corporative game

POR QUE OS PROJETOS FRACASSAM?

35


Aumentando a probabilidade de sucesso dos projetos

EVITANDO O FRACASSO DE PROJETOS

INGREDIENTES:• 1 cup unsalted butter• 1/2 cup light brown sugar• 1/2 cup dark brown sugar• 3 large eggs• 3 tablespoons brandy, plus

extra for brushing the cake• one orange, juiced and zested• one lemon, just the zest• 3/4 cup ground almonds or

almond meal• 1 cup chopped mixed nuts

(such as hazelnuts, walnuts, pecans, or almonds)

• 1 1/2 pounds choppedcandied fruits (dried apricots, candied cherries, candied zest, figs, prunes, dates)

• 3/4 pound mixed dried fruit(such as raisins, sultanas, currants, dried cranberries)

• 2 cups all‐purpose flour• 1 teaspoon baking powder• 1/4 teaspoon salt

NÃO EXISTE!

36



TÉCNICAS

PESSOASDISCIPLINA

PRESENÇA

USAR:

1. Metodologias2. Ferramentas de gestão3. Processos de trabalho

claros e objetivos4. Comunicação eficaz5. Definição de atribuições e

responsabilidades6. Praticar a gestão e controle

(na medida certa)7. Habilidades interpessoais8. Liderança efetiva9. Escuta ativa10. “Leitura” ativa

NÃO GARANTE SUCESSO!

Aumenta a probabilidade de sucesso


37


TÉ

CN

ICA

S

PE

SS

OA

S

DIS

CIP

LIN

A

PR

ES

EN

ÇA

SUCESSO EMPROJETOS



38


PE

SS

OA

S

DIS

CIP

LIN

A

PR

ES

EN

ÇA



39


Tempo decorrido do projeto

Riscos e Incertezas

Custo para corrigir erros

Nív

el d

e A

tivi

dad

es

Atividades

Atividades

Início do projeto Organização e preparação Execução do trabalho do projeto Encerramento do projeto

Project Charter

Project Management

Plan

AcceptedDeliverables

ArchivedProject

Documents

Influência dosStakeholders

CICLO DE VIDA DE UM PROJETO

40


REFERÊNCIAS

41


MUNDO PMI

42


FASESETAPAS

ESTÁGIOSCICLOS

INICIAÇÃO PLANEJAMENTO

EXECUÇÃOMONITORAMENTO

eCONTROLE

ENCERRAMENTO

MUNDO PMI: GRUPOS DE PROCESSOS

43


MUNDO PMI

ÁREAS DO CONHECIMENTO

4. INTEGRAÇÃO

10.COMUNICAÇÃO

11.RISCOS

12.AQUISIÇÕES

9.RECURSOS

8.QUALIDADE

7.CUSTOS

6.CRONOGRAMA

5.ESCOPO

13.STAKEHOLDERS

PMBOK 6ª ed

49PROCESSOS

44


FUNDAMENTOS DOS PROCESSOS

MUNDO PMI

INFORMAÇÕESENTRADAS

FERRAMENTAS

E TÉCNICASSAÍDAS

INFORMAÇÕESTRABALHADAS

1. Documentos / informações existentes

2. Saídas de outros processos

3. Novas informações

4. Conhecimento técnico especializado

5. Histórico de outros projetos

6. Experiências do gerente do projeto

7. Exigências legais / restrições / premissas

1. Novos documentos / informações

2. Informações adequadas

3. Novas informações

4. Novas orientações de trabalho

5. Deliverables / final de “fases”

6. Restrições / premissas

7. Novas responsabilidades

45


MUNDO PMI vs PROCESSOS

Plan PlanejarDo FazerCheck VerficarAct Agir

CICLO PDCA

Esse ciclo é ligado porresultados:

o resultado de uma parte do ciclo se torna a entrada para

a outra parte.

46


Define e autoriza o projeto ou uma fase do projeto.

O que acontece nesta fase:1. Selecionar o Gerente de Projeto

2. Determinar a cultura da empresa e seus sistemas

3. Coletar os processos, procedimentos e informações históricas

4. Dividir grandes projetos em projetos menores

5. Identificar os Stakeholders

6. Documentar as necessidades de negócio

7. Determinar os objetivos de negócio

8. Documentar as premissas e restrições

9. Desenvolver o Project Charter

10. Desenvolver o escopo preliminar do projeto

• INICIAÇÃO


47


Processos (02):

• INICIAÇÃO

ÁREA PROCESSO

INTEGRAÇÃO 4.1 - Desenvolver o termo de abertura do projeto

STAKEHOLDERS 13.1 - Identificar os stakeholders

Define e autoriza o projeto ou uma fase do projeto.


48


Define e detalha os objetivos, planeja as ações necessárias para entregar oescopo do produto e do projeto.

O que acontece nesta fase:1. Determinar como o projeto será executado

2. Desenvolver o Escopo do Projeto

3. Determinar o time

4. Criar a WBS e o dicionário da WBS

5. Criar a lista de atividades

6. Criar o diagrama de rede

7. Estimar as necessidades dos recursos

8. Estimar Tempo e Custo

9. Determinar o caminho critico

10. Desenvolver o cronograma

11. Desenvolver o Budget

• PLANEJAMENTO


49


O que acontece nesta fase:12. Determinar o padrão de qualidade, processos e métricas

13. Determinar os papéis e responsabilidades

14. Determinar as necessidades de comunicação

15. Identificar os riscos, quantificar e qualificar e o plano de resposta

16. Interações

17. Determinar o que será adquirido

18. Preparar os contratos

19. Finalizar o plano de como executar e controlar todos os aspectos do projeto

20. Criar um processo de melhoria

21. Desenvolver o plano final do projeto e o baseline

22. Obter a aprovação formal

23. Fazer a reunião de kickoff

• PLANEJAMENTO



50


Processos (24):

• PLANEJAMENTO

ÁREA PROCESSO

INTEGRAÇÃO 4.2 - Desenvolver o plano de gerenciamento do projeto

ESCOPO 5.1 - Planejar o gerenciamento do escopo

ESCOPO 5.2 - Coletar requisitos

ESCOPO 5.3 - Definir o escopo

ESCOPO 5.4 - Criar a EAP

CRONOGRAMA 6.1 - Planejar o gerenciamento do cronograma

CRONOGRAMA 6.2 - Definir as atividades

CRONOGRAMA 6.3 - Sequenciar atividades

CRONOGRAMA 6.4 - Estimar durações das atividades

CRONOGRAMA 6.5 - Desenvolver o cronograma



51


Processos (24):

• PLANEJAMENTO

ÁREA PROCESSO

CUSTOS 7.1 - Planejar o gerenciamento dos custos

CUSTOS 7.2 - Estimar os custos

CUSTOS 7.3 - Determinar o orçamento

QUALIDADE 8.1 - Planejar gerenciamento da qualidade

RECURSOS 9.1 - Planejar o gerenciamento dos recursos

RECURSOS 9.2 - Estimar os recursos das atividades

COMUNICAÇÕES 10.1 - Planejar o gerenciamento das comunicações



52


Processos (24):

• PLANEJAMENTO

ÁREA PROCESSO

RISCOS 11.1 - Planejar o gerenciamento dos riscos

RISCOS 11.2 - Identificar os riscos

RISCOS 11.3 - Realizar a análise qualitativa de riscos

RISCOS 11.4 - Realizar a análise quantitativa de riscos

RISCOS 11.5 - Planejar as respostas aos riscos

AQUISIÇÕES 12.1 - Planejar o gerenciamento das aquisições

STAKEHOLDERS 13.2 - Planejar o engajamento dos stakeholders



53


Integra pessoas e outros recursos para executar o plano de gerenciamento doprojeto.

O que acontece nesta fase:1. Definir o time final

2. Executar o plano de projeto

3. Completar o escopo do produto

4. Recomendar mudanças, reparos, ações corretivas e preventivas

5. Enviar e receber informações

6. Implementar mudanças aprovadas e ações corretivas

7. Melhoria continua

• EXECUÇÃO


54


O que acontece nesta fase:8. Fluxo de processo

9. Team Building

10. Dar recompensas e prêmios

11. Fazer a reunião de progresso

12. Usar o sistema de trabalho autorizado

13. Solicitar RFP, RFI, RFC

14. Selecionar o(s) fornecedor(es)

• EXECUÇÃO



55


Processos (10):

• EXECUÇÃO

ÁREA PROCESSO

INTEGRAÇÃO 4.3 - Dirigir e gerenciar o trabalho do projeto

INTEGRAÇÃO 4.4 - Gerenciar o conhecimento do projeto

QUALIDADE 8.2 - Gerenciar a qualidade

RECURSOS 9.3 - Obter os recursos

RECURSOS 9.4 - Desenvolver a equipe do projeto

RECURSOS 9.5 - Gerenciar a equipe do projeto

COMUNICAÇÕES 10.2 - Gerenciar as comunicações

RISCOS 11.6 - Implementar as respostas aos riscos

AQUISIÇÕES 12.2 - Conduzir as aquisições

STAKEHOLDERS 13.3 - Gerenciar o engajamento dos stakeholders



56


Mede e monitora regularmente o progresso do projeto, identificando e corrigindoos desvios identificados.

O que acontece nesta fase:1. Medição da performance contra o baseline

2. Medição de acordo com o plano de gerenciamento

3. Determinar as variações e se eles querem ações corretivas ou mudança

4. Verificação do Escopo

5. Gerenciamento de configuração

6. Recomendar mudanças, reparos, ações corretivas e preventivas

7. Controle integrado de mudanças

8. Aprovar mudanças, reparos, ações corretivas e preventivas

• MONITORAMENTO E CONTROLE


57


O que acontece nesta fase:9. Auditoria de riscos

10. Reserva Gerencial

11. Usar registro de problemas

12. Auxiliar na resolução de conflitos

13. Medição da performance do time

14. Reportar a Performance

15. Criar forecast (budget ajustado)

16. Administrar os contratos




58


Processos (12):


ÁREA PROCESSO

INTEGRAÇÃO 4.5 - Monitorar e controlar o trabalho do projeto

INTEGRAÇÃO 4.6 - Realizar o controle integrado de mudanças

ESCOPO 5.5 - Validar o escopo

ESCOPO 5.6 - Controlar o escopo

CRONOGRAMA 6.6 - Controlar o cronograma

CUSTOS 7.4 - Controlar os custos

QUALIDADE 8.3 - Controlar a qualidade

RECURSOS 9.6 - Controlar os recursos

COMUNICAÇÕES 10.3 - Monitorar as comunicações

RISCOS 11.7 - Monitorar os riscos

AQUISIÇÕES 12.3 - Controlar as aquisições

STAKEHOLDERS 13.4 - Monitorar o engajamento dos stakeholders



59


Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou umafase a um final sem pendências.

O que acontece nesta fase:1. Desenvolver o procedimento de encerramento

2. Finalizar os contratos

3. Confirmar se o trabalho foi executado

4. Obter a aceitação formal

5. Reportar a performance final

6. Indexar e armazenar os registros

7. Atualizar as lições aprendidas

8. Entregar o produto finalizado

9. Liberar os recursos

• ENCERRAMENTO


60


Processos (01):

• ENCERRAMENTO

ÁREA PROCESSO

INTEGRAÇÃO 4.7 - Encerrar o projeto ou fase

Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou umafase a um final sem pendências.


61


ÁREAS DO CONHECIMENTO

PMBOK 6ª edição - PROCESSOS DE GERENCIAMENTO DE PROJETOS (49)Iniciação (02) Planejamento (24) Execução (10) Monitoramento e controle (12) Encerramento (01)

04 INTEGRAÇÃO

4.1 - Desenvolver o Termo de Abertura do Projeto

4.2 - Desenvolver o plano de gerenciamento do projeto

4.3 - Dirigir e gerenciar o trabalho do projeto

4.5 - Monitorar e controlar o trabalho do projeto

4.7 - Encerrar o projeto ou fase

4.4 - Gerenciar o conhecimento do projeto

4.6 - Realizar o controle integrado de mudanças

05 ESCOPO

5.1 - Planejar o gerenciamento do escopo 5.5 - Validar o escopo

5.2 - Coletar requisitos 5.6 - Controlar o escopo

5.3 - Definir o escopo

5.4 - Criar a EAP

06 CRONOGRAMA

6.1 - Planejar o gerenciamento do cronograma

6.6 - Controlar o cronograma

6.2 - Definir as atividades

6.3 - Sequenciar atividades

6.4 - Estimar durações das atividades

6.5 - Desenvolver o cronograma

07 CUSTOS7.1 - Planejar o gerenciamento dos custos 7.4 - Controlar os custos

7.2 - Estimar os custos

7.3 - Determinar o orçamento

08 QUALIDADE 8.1 - Planejar gerenciamento da qualidade 8.2 - Gerenciar a qualidade 8.3 - Controlar a qualidade

09 RECURSOS

9.1 - Planejar o gerenciamento dos recursos 9.3 - Obter os recursos 9.6 - Controlar os recursos

9.2 - Estimar os recursos das atividades9.4 - Desenvolver a equipe do projeto

9.5 - Gerenciar a equipe do projeto

10 COMUNICAÇÕES 10.1 - Planejar o gerenciamento das comunicações

10.2 - Gerenciar as comunicações

10.3 - Monitorar as comunicações

11 RISCOS

11.1 - Planejar o gerenciamento dos riscos11.6 - Implementar as respostas aos riscos

11.7 - Monitorar os riscos

11.2 - Identificar os riscos

11.3 - Realizar a análise qualitativa de riscos

11.4 - Realizar a análise quantitativa de riscos

11.5 - Planejar as respostas aos riscos

12 AQUISIÇÕES 12.1 - Planejar o gerenciamento das aquisições

12.2 - Conduzir as aquisições

12.3 - Controlar as aquisições

13 STAKEHOLDERS 13.1 - Identificar os stakeholders

13.2 - Planejar o engajamento dos stakeholders

13.3 - Gerenciar o engajamento dos stakeholders

13.4 - Monitorar o engajamento dos stakeholders D

AN

IEL

AQ

UE

RE

DE

OLI

VE

IRA

, MS

c, M

BA

, PM

P, A

SM M

BA

BI A

naly

tics

–G

estã

o de

Pro

jeto

s

62


63


COMPORTAMENTO TÍPICONAS EMPRESAS

64


EAP – WBSEstrutura Analítica do Projeto

65


1. A EAP é uma “árvore” orientada a tarefas ou produtos que pode definir o escopo detrabalho do projeto.

2. Quanto mais detalhada, menores serão os riscos incorridos na obtenção dos resultadosesperados.

3. Para utilização dessa ferramenta é necessário um entendimento perfeito do escopo doprojeto e do produto, de forma a possibilitar à equipe executar a decomposição deatividades em sub-atividades, essas em tarefas e por fim, em sub-tarefas que podem àsvezes, serem denominadas de pacotes de trabalho.

4. Um pacote de trabalho, na maioria das vezes, irá gerar um entregável, gerar umresultado claro e específico, mesmo que seja para outra fase/etapa do projeto.

5. A construção de uma EAP deve ser realizada, preferencialmente, pela equipe de projetoque, em uma reunião de planejamento específica para elaboração da EAP, se reunirápara delinear as atividades, sub-atividades, tarefas e sub-tarefas que serãonecessárias para obtenção dos resultados desejados.


66



Coletar Requisitos

Definir oEscopo

DefinirAtividades

PlanejarRecursos

DesenvolverCronograma

SeqüenciarAtividades

EstimarCusto

EstimarDuração

Elaborar o

Plano de Projeto

DesenvolverOrçamento

67


O processo criar a EAP deve gerar:

• A declaração do escopo devidamente atualizada

• A própria EAP

• O dicionário da EAP

• A linha de base do escopo do projeto

• O plano de gerenciamento do projeto atualizado

A EAP serve para:

• Elaboração do cronograma

• Elaboração do orçamento de custos

• Identificação e análise de riscos

• Identificação de recursos

• Controle dos trabalhos a serem executados

• Identificação dos entregáveis do projeto.


68


Documentação de apoio da EAP / WBS:

• Componentes do WBS são definidos em um dicionário

• Para cada work package (pacote de trabalho) definir:

1. Duração

2. Recursos

3. Custo

4. Responsável

5. Produtos que serão gerados (resultados)

6. Precursores e sucessores

7. Critérios de encerramento

8. * customizável


69


Sistema de aeronave

Gerenciamento do projeto

Gerenciamentode engenharia de

sistemas

Atividades de GP de apoio

Treinamento

Treinamento no equipamento

Treinamento nasinstalações

Treinamento emserviço

Dados

Pedidos técnicos

Dados de engenharia

Dados de gerenciamento

Veículo aéreo

Estrutura da aeronave

Motor

Sistema de comunicação

Sistema de navegação

Sistema de controle de

incêndio

Equipamentos de apoio

EA em nívelorganizacional

EA em nível de depósito

EA em nível de depósito

Instalações

Construçõesbásicas

Instalação de manutenção

Testes de avaliação

Mock-ups

Teste operacional

Teste de desenvolvimento

Teste de estabilidade

DECOMPOSIÇÃO


70


Não há folga, ou seja, se houver atraso... O projeto atrasa!

CAMINHO CRÍTICO

71


DIAGRAMA DE REDE

72


DIAGRAMA DE REDE

73


DIAGRAMA DE REDE

74


ORÇADO X PLANEJADO X REALIZADO

ESTA VISÃO DEVE SER UTILIZADA PARA OPEX e CAPEX

CAPEXSigla da expressão CAPital EXpenditure.São as despesas de capital ou investimento embens de capital e que designa o montante dedinheiro despendido na aquisição (ou introduçãode melhorias) de bens de capital de umadeterminada empresa.

OPEXSigla da expressão OPerational EXpenditure.São as despesas para manter os bens físicos daempresa, tais como equipamentos e imóveis.São despesas que não são classificadas comoativos da empresa, geralmente custos periódicos,como salários e licenças de uso de software.

75


antes ANO ATUAL ACUM

depois

ꞏꞏꞏ JAN FEV MAR ABR MAI JUN JUL AGO SET OUT NOV DEZJAN à OUT ꞏꞏꞏ

PLAN $ $ $ $ $ $ $ $ $ $ $ $ $$$ ꞏꞏꞏ

REAL $ $ $ $ $ $ $ $ $ $ $ $ $$$ ꞏꞏꞏ

STATUS

P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$ P$-R$

ESTA VISÃO DEVE SER UTILIZADA PARA OPEX e CAPEX

CAPEXSigla da expressão CAPital EXpenditure.São as despesas de capital ou investimento embens de capital e que designa o montante dedinheiro despendido na aquisição (ou introduçãode melhorias) de bens de capital de umadeterminada empresa.

OPEXSigla da expressão OPerational EXpenditure.São as despesas para manter os bens físicos daempresa, tais como equipamentos e imóveis.São despesas que não são classificadas comoativos da empresa, geralmente custos periódicos,como salários e licenças de uso de software.

LINHA DE BASE DE CUSTOS

76


AVALIANDO RISCOS


77

DANIEL AQUERE DE OLIVEIRA, MSc, MBA, PMP, ASM MBA BI Analytics – Gestão de ProjetosDANIEL AQUERE DE OLIVEIRA, MSc, MBA, PMP, ASM MBA BI Analytics – Gestão de Projetos

78


RISCOS DESCONHECIDOS

RISCOS CONHECIDOS, ALGUNS GERENCIADOS

AVALIANDO RISCOS

79


AVALIANDO RISCOS

Matriz de Probabilidade x Impacto

01

02

03

04

05

06

07

08

09

10

DESCRIÇÃO DO RISCO

Alto Baixo

Risco 5 Muito Alto Desprezível

Risco 4

Risco 1PROBABILIDADE IMPACTO

RISCO(S) IDENTIFICADO(S):

8,00CRITICIDADE (maior, mais crítico)

Desprezível Muito Alto

Risco 2 Baixo Alto

Risco 3 Moderado Moderado

12,00

10,00

7,00

4,50

80


AVALIANDO RISCOS

Matriz de Probabilidade x Impacto

AMEAÇAS OPORTUNIDADES MAPA DE RISCO‐0,05 ‐0,10 ‐0,20 ‐0,40 ‐0,80

0

OPORTUNIDADES

PROBABILIDADE

0,90

‐0,05 ‐0,09 ‐0,18 ‐0,36 ‐0,72 0,72 0,36

0,80 0,40 0,20 0,10 0,05 AMEAÇAS

0,70

‐0,04 ‐0,07 ‐0,14 ‐0,28

0,18 0,09 0,05

1

‐0,56 0,56 0,28 0,14 0,07 0,04

0,03

1 1

‐0,03 ‐0,05 ‐0,10 ‐0,20 ‐0,40

1

0,30

‐0,02 ‐0,03 ‐0,06 ‐0,12

0,40 0,20 0,10 0,05

0,50

‐0,24 0,24 0,12 0,06 0,03 0,02

1 0‐0,01 ‐0,01 ‐0,02 ‐0,04 ‐0,08 0,08 0,04

1 1

1

0,02 0,01 0,01

0,10

IMPACTODESPREZÍVEL BAIXO MODERADO ALTO MUITO ALTO

COMO SERÃO PONTUADOS OS DADOS DA MATRIZ

PROBABILIDADEDESPREZÍVEL BAIXO MODERADO ALTO MUITO ALTO

0,1

0,05 0,1 0,2 0,4 0,8

0,3 0,5 0,7 0,9

81


MUDANÇAS EM PROJETOS

82


SUBMETER SOLICITAÇÃO DE MUDANÇA PARA

ANÁLISE

INÍCIO

TÉRMINO

AVALIAR IMPACTOS

AFETA CUSTOS E/OU

CRONOGRAMA

?

??

??

REVISAR SOLICITAÇÃO DE MUDANÇA

SN


83


AVALIAR IMPACTO:

1. No negócio

2. Na operação

3. Na qualidade


84



Grupo 1 Grupo 2 Grupo 3

Grupo 4 Grupo 5 Grupo n

EFEITO

causa 1causa 2

causa n

85


REPLANEJAMENTO

IMPORTANTE

TODAS AS ÁREAS DO

CONHECIMENTO DEVERÃO SER REVISTAS, DE

FORMA A IDENTIFICAR O

IMPACTO DA MUDANÇA

86


COMUNICAÇÃO E STAKEHOLDERS

Necessidades dos stakeholders

Entregas Cronograma

Custos Qualidade

Equipes Riscos

IDENTIFICAR O QUÊ É VALOR PARA CADA STAKEHOLDER!

87


Nível de comunicação

PRESIDENTE

VICE-PRESIDENTE 1

DIRETORIA FINANCEIRA

GERÊNCIA 1 GERÊNCIA 2

DIRETORIA COMERCIAL

VICE-PRESIDENTE 2

DIRETORIA DE CLIENTES

DIRETORIA DE OPERAÇÕES

GERÊNCIA 3 GERÊNCIA 4

ASSESSOR

O nível de comunicação irá variar de acordo com a hierarquia.


88


Sempre existirão stakeholders a favor e contra o projeto!


Nível de comunicação

89


ANÁLISE DE PROJETOS - ESTRATÉGIA DE ABORDAGEM ANÁLISE DE PROJETOS - ESTRATÉGIA DE ABORDAGEM

1 WHAT O QUÊ SERÁ EXECUTADO 5 WHY JUSTIFICATIVA - PORQUÊ EXECUTAR

2 WHO QUEM IRÁ EXECUTAR 6 HOW PROCEDIMENTO - COMO SERÁ EXECUTADO

3 WHEN QUANDO IRÁ EXECUTAR - I / T 7 HOW MUCH QUANTO IRÁ CUSTAR (CAPEX / OPEX)

4 WHERE ONDE IRÁ ACONTECER 8 RISKS QUAIS OS RISCOS / O QUE PODE DAR ERRADO

WHAT WHO WHEN WHERE

WHYHOWHOW MUCHRISKS

1 2 3 4

5678

5W2H + R + Q

90


TÉRMINO DO PROJETO

• Pendências para encerrar um projeto

• Avaliação dos resultados do projeto

• Lições aprendidas

• Documentação

• TEP – Termo de Encerramento do Projeto

91


TÉRMINO DO PROJETO

Pendências para encerrar um projeto

1. Cliente reconhecer as entregas

2. Compromissos com fornecedores

3. Documentação

4. Repasse para outras áreas

5. Liberação de orçamento

6. Processos contábeis

7. Lições aprendidas

8. Comunicado oficial de “FIM”

92


Avaliação dos resultados do projeto

RESULTADO

1. Financeiro

2. Qualitativo

3. Expectativas

4. Colateral

5. Novas demandas

TÉRMINO DO PROJETO

93


Lições aprendidas

1. Processos internos

2. Cultura

3. Corporate Game

4. In / Out

5. GAP´s

TÉRMINO DO PROJETO

4. INTEGRAÇÃO

10.COMUNICAÇÃO

11.RISCOS

12.AQUISIÇÕES

9.RECURSOS

8.QUALIDADE

7.CUSTOS

6.CRONOGRAMA

5.ESCOPO

13.STAKEHOLDERS

94


Documentação

1. Quais documentos?

2. Qual o objetivo?

3. Quem irá utilizar?

4. Onde irá compartilhar?

TÉRMINO DO PROJETO

95


TEP – Termo de Encerramento do Projeto

1. Resolver as pendências2. Executar os processos de governança3. Saldar compromissos financeiros4. Obter o aceite do(s) cliente(s)5. Realizar repasse(s)6. Alinhar expectativas com stakeholders

TÉRMINO DO PROJETO

96


GERENCIAMENTO ÁGIL

• Tradicional vs Ágil• Ciclo Waterfall vs Ágil• Manifesto ágil• Valores ágeis• Benefícios dos métodos ágeis• Planejamento adaptativo• Mapa de Requisitos• O princípio YAGNI• Gestão à vista

97


GERENCIAMENTO ÁGIL

Antes... To Think...

98


GERENCIAMENTO ÁGIL


99


GERENCIAMENTO ÁGIL


100


Por que ÁGIL?

Com o aumento das exigênciasdos clientes e prazos cada vezmais curtos, encontrar opçõespara executar os projetos, comqualidade, e em menos tempo éfundamental.

GERENCIAMENTO ÁGIL

101


Tradicional vs Ágil

GERENCIAMENTO ÁGIL

102



1. Processos definidos

2. Planejamento rígido

3. Maior foco em processos do que no produto

4. Feedbacks não são essenciais

5. Documentação extensa

6. Inibe a comunicação entre as pessoas

7. Planejamento prevê um trabalho extenso, com a entrega do produto somente nos estágios finais do cronograma (não evita conflitos com cliente)

8. Conceito de que “entradas iguais sempre geram saídas iguais”

1. Processos empíricos

2. Maior liberdade no planejamento das ações

3. Menos formalidade e maior ênfase no produto

4. Feedbacks são essenciais

5. Documentação necessária

6. Estimula a comunicação entre as pessoas

7. Entregas de partes do projeto de forma contínua e incremental (iterações) com o objetivo de obter um rápido feedback do cliente sobre o andamento do projeto

8. Conceito de que “entradas iguais geram saídas diferentes”

Tradicional Ágil

GERENCIAMENTO ÁGIL

103


9. Atividades realizadas sequencialmente. Testes executados somente no final, quando “tudo” estiver pronto

10. Baseado na definição de todas as etapas do trabalho

11. Resistência a mudanças

12. Decisões tomadas em uma abordagem top-down

13. Forte centralização em torno da figura do gerente de projetos

9. Atividades realizadas paralelamente. Testes executados durante todo o processo, equipe de testes mais presente em todo os pontos de desenvolvimento

10. Baseado na experiência e controlado através de inspeção e adaptação contínua

11. Flexibilidade e postura positiva diante da necessidade de mudanças (mesmo em fases finais do projeto)

12. Liberdade para o time tomar decisões em conjunto

13. Responsabilidade compartilhada entre os membros da equipe, espírito de colaboração e time engajado

Tradicional Ágil


GERENCIAMENTO ÁGIL

104


14. Liderança que monopoliza toda a comunicação já que a preocupação é com o controle das ações

15. Líderes indicando “O que fazer” e “Como fazer”, ao invés de dizer o “Porquê”

16. Problemas geralmente escalados até a gerência

17. Longa fase de análise; em muitos casos parte da equipe é deixada de lado nesses estágios iniciais (já que considera que tais membros ingressarão apenas na fase de execução)

14. Comunicação fluída e livre entre os membros do time

15. Equipes auto organizáveis; a divisão do trabalho é resultado do entendimento do projeto e de um consenso entre o time

16. Atuação conjunta do time para a resolução de problemas

17. Reuniões diárias entre o time onde são discutidos o que será feito naquele momento, revendo o planejamento a médio e curto prazo, além de prováveis impedimentos

Tradicional Ágil


GERENCIAMENTO ÁGIL

105


18. Um forte enfoque na geração de documentos e no controle através desses artefatos

19. Maior envolvimento do cliente em estágios iniciais, com certo relaxamento de postura, uma vez que o projeto tenha se iniciado

20. Foco na “antecipação” (algo difícil em um ambiente sempre sujeito a mudanças repentinas)

18. Embora existam documentos e se estimule a criação dos mesmos, há um pragmatismo maior (sem conferir uma importância exagerada a esses artefatos)

19. Participação ativa do cliente, inclusive enquanto o projeto está sendo implementado

20. Ênfase na “adaptação” (requer “jogo de cintura”)

Tradicional Ágil


GERENCIAMENTO ÁGIL

106


Ciclo Waterfall vs Ágil

ANÁLISE

PLA

NEJAMEN

TO

EXEC

UÇÃO

TESTES

ONE‐OFF ACTIVITIESATIVIDADES ÚNICAS

WAT E R F A L L

Á G I L

CONTINUOUS ACTIVITIESATIVIDADES CONTÍNUAS

ANÁLISE

PLANEJAMENTO

EXECUÇÃO

ENTR

EGAS

TESTES

ENTREGAS

ENTREGAS

SUCESSIVAS

GERENCIAMENTO ÁGIL

107


Ciclo Waterfall vs Ágil

WAT E R FA L L

Á G I L

GERENCIAMENTO ÁGIL

108


Manifesto ágil

A história

Na primavera de 2000 um grupo de líderes da comunidade do Extreme Programming se reuniram naparte rural de Oregan, o intuito era discutir as várias questões que envolviam o processo dedesenvolvimento com XP (Extreme Programming).

Na reunião foi debatida a relação entre XP e processos semelhantes conhecidos inicialmente comométodos leves (Lightweight Methods), uma denominação aos novos métodos de desenvolvimento desoftware que começavam a surgir naquela época.

Os métodos leves seguiam uma reação adversa aos métodos pesados, que tinham comocaracterísticas a formalização exagerada nas documentações e regulamentações, sendo em umagrande maioria, influenciadas pelo tradicional e burocrático modelo em cascata.

Como consequência, concluíram que o XP era melhor como um método específico, porém,concordaram que havia um espaço comum entre o XP e os métodos leves.

Um dos presentes nesta reunião, Robert Cecil Martin, tio Bob, decidiu montar uma reunião compessoas interessadas nos métodos leves.

Uma ampla escala de pessoas foram contatadas, sendo elas, interessadas ou atuantes no meio.

Em fevereiro de 2001, uma reunião nas montanhas nevadas do estado norte-americano de Utah noresort de inverno e verão Snowbird, marcava o surgimento e propagação do paradigma dedesenvolvimento de softwares ágeis.

Infelizmente, muitas das pessoas que estavam dispostas a ir tiveram que se ausentar.

GERENCIAMENTO ÁGIL

109


Manifesto ágil

A história

Ao entanto, dezessete pessoas (incluindo o tio Bob) compareceram, elas dariam início naquelemomento - mesmo sem saber - ao manifesto ágil.

Ao decorrer da reunião um consenso comum sobre aspectos importantes em desenvolvimento desoftware fluíam.

Logo, todos acharam melhor elevar aquela reunião a um patamar maior.

Decidiram escrever um documento que serviria como grito de guerra aos novos processos dedesenvolvimento de software.

A primeira parte se resumia a encontrar um nome que expressasse bem o significado daquelemovimento, métodos leves deixou de ser uma opção válida, pois não traduzia o significado desejado.

Após considerar vários nomes decidiram que a palavra “ágil” melhor captava a abordagem proposta.

A segunda parte da reunião foi dedicada à escrita de um documento que desencadearia o manifestoágil, nele estaria contido a declaração das crenças e valores que aquelas dezessete pessoaspossuíam.

Na última parte e nos meses seguintes os princípios foram trabalhados.

O manifesto ágil se tornou um grito de guerra para a indústria de software e para aquelas dezessetepessoas. Ele consegue expressar claramente o que defende e o que opõe, deixando bem claro o queé, e o que não é ágil.

GERENCIAMENTO ÁGIL

110


Manifesto ágil

A história

Os profissionais que originaram o manifesto ágil foram:

GERENCIAMENTO ÁGIL

111


Manifesto ágil

Os 12 princípios do manifesto ágil são:

1. VALOR: Nossa maior prioridade é satisfazer o cliente através da entrega contínua eadiantada de resultados com valor agregado.

2. FLEXIBILIDADE: Aceitar mudanças de requisitos, mesmo no fim das entregas.Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagenscompetitivas.

3. FREQUÊNCIA: Entregar frequentemente algo útil e funcionando, de poucassemanas a poucos meses, com preferência à menor escala de tempo.

4. UNIÃO: Pessoas de negócio e equipes devem trabalhar diariamente em conjuntopor todo o projeto.

5. MOTIVAÇÃO: Construir projetos em torno de indivíduos motivados. Dando a eles oambiente e o suporte necessário, e confiando neles para fazer o trabalho.

6. COMUNICAÇÃO: O método mais eficiente e eficaz de transmitir informações para eentre equipes é através de conversas face a face.

GERENCIAMENTO ÁGIL

112


Manifesto ágil

Os 12 princípios do manifesto ágil são:

7. FUNCIONALIDADE: Entregas úteis são a medida primária de progresso.

8. SUSTENTABILIDADE: Os processos ágeis promovem execuções sustentável. Ospatrocinadores, equipes e usuários devem ser capazes de manter um ritmoconstante indefinidamente.

9. REVISÃO: Contínua atenção a excelência técnica e boas entregas aumentam aagilidade.

10. SIMPLICIDADE: A arte de maximizar a quantidade de trabalho não realizado éessencial.

11. ORGANIZAÇÃO: As melhores idéias, planejamento, formas de execução eentregas emergem de times auto-organizáveis.

12. AUTOAVALIAÇÃO: Em intervalos regulares, a equipe reflete sobre como se tornarmais eficaz e então refina e ajusta seu comportamento de acordo.

GERENCIAMENTO ÁGIL

113


Manifesto ágil

Com o manifesto ágil foi necessário uma organização que se configurassepermanente e o representasse. Então, no final de 2001, nasceu a Agile Alliance.

Trata-se de uma organização sem fins lucrativos que procura promover oconhecimento e discussões sobre os vários métodos ágeis, hoje, existentes nomundo.

Muitos dos membros do manifesto ágil, citados anteriormente, são integrantesdessa aliança (www.agilealliance.org).

Cada método ágil existente hoje carrega consigo os valores e princípios arraigadosno manifesto ágil, métodos como SCRUM, KANBAN e XP os trazem, por isso sãodenominados ágeis.

Para ter uma real dimensão do impacto e do peso do Manifesto, basta pensar que além de Robert Cecil Martin (tio Bob), nomes como Jeff Sutherland e Ken

Schwaber - fundadores do Scrum - estavam entre os dezessete signatários.

GERENCIAMENTO ÁGIL

114


Valores ágeis

Os 4 valores

Estamos descobrindo maneiras melhores de desenvolversoftwares/produtos fazendo-o nós mesmos e ajudando outros a fazê-lo.

Através deste trabalho, passamos a valorizar:

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

1

2

3

4

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

GERENCIAMENTO ÁGIL

115


Benefícios dos métodos ágeis

As metodologias ágeis trouxeram uma série de benefícios:

1. Elas permitem a entrega de produtos em prazos mais curtos;

2. Possibilitam um trabalho de criação com mais flexibilidade;

3. O desempenho e a qualidade de novas soluções são aperfeiçoados;

4. Aumenta a produtividade da equipe;

5. Maior qualidade nas entregas;

6. Clareza na priorização das entregas;

7. Redução dos riscos;

8. Maior controle dos custos;

9. Melhor aferição dos resultados;

10.Aumento da satisfação dos clientes.

GERENCIAMENTO ÁGIL

116


Planejamento adaptativo

GERENCIAMENTO ÁGIL

117


GERENCIAMENTO ÁGIL

• O que é ser ÁGIL?

“Ser ágil não tem a vercom rapidez ou velocidade, usarScrum ou não usar o Guia PMBOK®,conversar mais ou fazerdocumentação de menos, ser ágil tema ver com eliminar o desperdício.”

Fábio Cruz

118


GERENCIAMENTO ÁGIL

• O que NÃO é ser ÁGIL?

1. Fazer sem qualidade;

2. Gerar retrabalho;

3. Entregar o que o cliente nãodeseja;

4. Não atuar orientado à valor.

119


GERENCIAMENTO ÁGIL

• ÁGIL? Sério? É verdade?

1. Realmente tu estás preparado para trabalhar com métodos ágeis?

2. A empresa está preparada para isto?

3. Nossos gestores estão preparados?

120


GERENCIAMENTO ÁGIL

• Benefícios dos métodos ágeis

As metodologias ágeis trouxeram uma série de benefícios:

1. Elas permitem a entrega de produtos em prazos mais curtos;

2. Possibilitam um trabalho de criação com mais flexibilidade;

3. O desempenho e a qualidade de novas soluções são aperfeiçoados;

4. Aumenta a produtividade da equipe;

5. Maior qualidade nas entregas;

6. Clareza na priorização das entregas;

7. Redução dos riscos;

8. Maior controle dos custos;

9. Melhor aferição dos resultados;

10.Aumento da satisfação dos clientes.

121


GERENCIAMENTO ÁGIL

• O princípio YAGNI

O YAGNI (You Aren’t Gonna Need It) é o princípio do: você não precisa dele.

Muitas vezes, falando como desenvolvedor, pensamos demais no futuro do projeto e

acabamos colocando muitos componentes extras em nosso código.

E S Q U E Ç A ! ! !

Se você não o utiliza, você não precisa dele.

Incrementar recursos que não serão utilizados, muitas vezes, gera

complexidade, resultando em tempo desperdiçado e aumento de manutenção.

Segure a vontade de inserir recursos extras no projeto, e que no momento são

desnecessários, priorize o que realmente deve estar presente no sistema e se

concentre nisso.

Lembre-se: Se não está chovendo, para que ficar com o guarda-chuva aberto?

Talvez chova, mas no momento não está.

Então, você não precisa dele.

122


GERENCIAMENTO ÁGIL

• O princípio KISS

O princípio KISS (Keep It Simple, Stupid!) é muito famoso nos Estados Unidos, suatradução em português poderia ser: “Simplifique, estúpido!” ou “Mantenha issosimples, estúpido!”.

Indica que a mais simples solução deve ser adotada em qualquer situação, portanto,que a maioria dos sistemas/requisitos funcionam melhor se mantidos simples e nãocomplexos.

Quanto mais simples o seu código, mais fácil de ser mantido no futuro ele será.

Por vezes, o caminho mais trabalhoso e complexo é o mais óbvio para você, nessecaso, o meu conselho é que pare e reflita sobre o seu trabalho.

Será mesmo que esse caminho é o mais correto?

Esses recursos são mesmo necessários?

Essa é a melhor forma de fazer isso?

E se você não estivesse aqui, alguém conseguiria manter esse código?

Essas perguntas não te farão fazer o mais simples, mas poderão te fazer pensarapenas no necessário.

123


GERENCIAMENTO ÁGIL

• O princípio DRY

O princípio DRY (Don’t Repeat Yourself), que em português significa: não se repita,

afirma que cada pedaço de conhecimento deve ter uma única representação

inequívoca e autoritária dentro de um sistema.

Certamente, você já encontrou código duplicado em algum de seus projetos e sabe que

manter um código assim é uma tarefa árdua.

Se você aplicar o princípio DRY da maneira correta, provavelmente, reduzirá problemas

do tipo: Onde mais eu preciso alterar para esse modulo funcionar?

Ou seja, siga o DRY e você terá apenas uma única fonte de verdade, evitando alterar

lógicas em elementos não relacionados.

124


GERENCIAMENTO ÁGIL

• Gestão à vista

125


MÉTODOS ÁGEIS

• Qual método usar

126


FERRAMENTAS ÁGEIS

• Kanban

• Lean

• MoSCoW

• Valor agregado

• Melhoria contínua

• Liderança situacional

• Inteligência emocional

• Team Building

• Soft Skills

127


FERRAMENTAS ÁGEIS

• KANBAN

Kanban é uma palavra japonesa e seu significado literal é “cartão” ou “sinalização”.

O Kanban surgiu no final de 1940, através da Toyota, com o objetivo de gerir e melhorar aperformance da sua linha de produção.

Isso significa que é um framework iterativo e incremental, pois usa experiências anteriores paraaperfeiçoar controle de riscos e decisões futuras.

O Kanban está relacionado com o conceito de Pull Systems - sistemas de produção puxados.Um sistema de produção empurrada se caracteriza por iniciar a produção antes de ocorrer umareal demanda, ou seja, o processo recebe uma ordem de produção e executa, empurrando oresultado da operação atual para a operação seguinte.

Um sistema de produção puxado se caracteriza por iniciar a produção quando um item édemandado/vendido, gerando demanda para a fabricação de outro, assim cada operação doprocesso é alimentada pela demanda da etapa anterior.

Em setembro de 2006, o diretor sênior de engenharia da Corbis (empresa fundada por BillGates), David J. Anderson decide projetar um sistema Kanban que substituiria a então abordagemexistente para atualização de aplicativos. Em 2007 o método foi apresentado nas conferências,“Lean New Product Development” e “Agile 2007”.

128


FERRAMENTAS ÁGEIS

• KANBAN

129


FERRAMENTAS ÁGEIS

• KANBAN

IMPORTANTE: o Kanban busca a evolução, não a revolução.

Princípios fundamentais:

1. Comece com o que você faz agora

2. Concordar em buscar mudanças evolucionárias

3. Inicialmente, respeite os papéis, responsabilidades e cargos atuais

4. Incentivar atos de liderança em todos os níveis

Práticas fundamentais:

1. Visualizar o fluxo de trabalho (workflow)

2. Limitar a quantidade de trabalho em andamento (WIP - Work In Process)

3. Gerenciar e medir o fluxo

4. Tornar as políticas do processo explícitas

5. Implementar loops de feedback

6. Usar modelos para reconhecer oportunidades de melhoria

130


FERRAMENTAS ÁGEIS

• KANBAN

IMPORTANTE: o Kanban busca a evolução, não a revolução.

Classificação de itens e hierarquia:

1. Épicos (Epics)

2. Estória de usuário (User Story)

3. Tarefas (Tasks)

Evidenciando um quadro Kanban:

1. Buffer

2. Priorização de itens

3. Limite WIP

4. Raias

131


FERRAMENTAS ÁGEIS

• KANBAN

BACKLOG TO DO DOING TESTING APPROVED DONECLIENT

ACCEPTEDDELIVERED

BUG / BLOCK

BUG / BLOCK

BUG / BLOCK

BUG / BLOCK

BUG / BLOCK

PARK LOT

4

storie name

n

storie name

storie name1

STORIES

2storie name

3storie name

132


FERRAMENTAS ÁGEIS

• KANBAN

Benefícios do Kanban

1. Tempo de ciclo curtos, oferecendo recursos mais rapidamente;

2. Melhor gestão nas mudanças de prioridade;

3. Requer menos organização;

4. O processo é simplificado;

5. Maior visibilidade dos projetos;

6. Redução de desperdício;

7. Redução de custo;

8. Elimina atividades que não agregam valor para a equipe;

9. Melhora a motivação e desempenho da equipe.

133


• LEANLean é um modelo gerencial aplicado pormeio de princípios e técnicas operacionais,tendo como objetivo a redução dodesperdício, a melhoria da qualidade e amaximização do valor entregue ao cliente.

É uma filosofia orientada à eficiência eeficácia de processos, focada em criarmais valor com menos trabalho.

FERRAMENTAS ÁGEIS

134


• LEAN

Convencional Lean

Faça como eu digo!(diretivo)

O que você acha?(coach)

1º Comportamento 2º Comportamento

Convencional Lean

Apenas a equipe vai à campo Vá ver!

Filosofia

5º Comportamento

Convencional Lean

Se livre do problema! Passe

para frente!

Torne os problemas visíveis

e lide com eles

37 03 01

6º Comportamento

Convencional Lean

Especialistas resolvem

problemas

Todos resolvem problemas, usando métodos simples

A+B = C

3º Comportamento

Convencional Lean

Temos padrões, mas não sei

onde estão ou se são seguidos

Temos padrões simples, divulgados

visualmente em todos os processos

importantes

4º Comportamento

Convencional Lean

Movimente! Dê seqüência! Produza

quantidade!

Pare a execução (não passe defeitos

para frente)

STOP!

F I L O S O F I A – 0 6 C O M P O R T A M E N T O S F U N D A M E N T A I SF I L O S O F I A – 0 6 C O M P O R T A M E N T O S F U N D A M E N T A I S

Modelos mentais e Comportamentos esperados

FERRAMENTAS ÁGEIS

135


• LEAN

ASK WHY

SHOW THE RESPECT

GO SEE

FERRAMENTAS ÁGEIS

136


• LEAN

PERGUNTE PORQUÊ

DEMONSTRE RESPEITO

VÁ VER

FERRAMENTAS ÁGEIS

137


• LEAN

Os 6 desperdícios:

1. Super Produção: Executar mais ou antes do necessário

2. Movimentação: Deslocamentos desnecessários de pessoaspara cumprir as tarefas

3. Tempo de espera: Itens ou pessoas esperando no processo

4. Má utilização do capital Humano: Não utilizar completamentea capacidade das pessoas

5. Defeitos: Todo o erro que leva a um retrabalho

6. Super Processamento: Esforços que não agregam valor aocliente

O que exatamente é desperdício?

A maneira mais simples de descrever o desperdício é como “algo que nãoacrescenta valor sob a ótica do cliente”.

Nossos clientes não ficariam felizes em pagar por qualquer ação que tomemos quenão agregue valor ao que eles realmente querem.

Por que remover

desperdícios?

FERRAMENTAS ÁGEIS

138


• MoSCoW

Técnica utilizada para priorização de escopo, priorização de requisitos e classificação de mudanças.

Aplicando esta técnica, consegue-se, por exemplo, classificar e priorizar a execução com base no seu valor para o negócio.

Must Have (Deve Ter): Tudo o que é imprescindível para o escopo do projeto. Aquilo que não podedeixar de ter, que sem elas o projeto perderia totalmente o sentido.

Should Have (Deveria Ter): Tudo o que é importante ter no escopo do projeto, mas, que não sãoimprescindíveis. Funcionalidades que se por ventura não forem executadas, não farão com que oproduto/serviço perca o seu valor para o negócio.

Could Have (Poderia Ter): Tudo o que seria bom ter, mas, não são importantes. É mais ou menos comoa cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem cereja, até porque, bolossem cerejas são mais baratos.

Won’t Have for Now (Não Terá por Enquanto): Tudo o que não será executtado por enquanto, pois, asfuncionalidades classificadas com won’t have for now, não geram valor para o negócio no momento.

FERRAMENTAS ÁGEIS

M

S

C

W

139


• Valor agregado

1. Valor Agregado é expressão originária de finanças,do processo de Avaliação de Valor Agregado (doinglês, EVA), que mede performance.

Em sua forma abrangente, designa a percepçãoque um stakeholder tem do serviço ou produto quelhe é apresentado.

É sempre uma percepção comparativa, tendo comobase o preço do bem versus os atributos(funcionais ou não) percebidos.

A noção de valor agregado traz a ideia desuperação de expectativa em relação aosbenefícios funcionais do bem.

2. Valor Agregado também se entende por valoragregado o resultado de processos e atividadesadicionados a um item, produto ou serviço, que ovalorizam em relação ao que ele era antes de esseprocesso ou atividade estar presente.

FERRAMENTAS ÁGEIS

140


• Melhoria contínua

FERRAMENTAS ÁGEIS

141


• Liderança situacional

Baixo grau de apoioBaixo grau de direção

Alto grau de apoioBaixo grau de direção

Médio grau de direçãoAlto grau de apoio

Alto grau de direçãoAlto grau de apoio

Teoria de Paul Hersey e KennethBlanchard.

Liderança Situacional consiste naliderança que é moldada deacordo com a variação dassituações apresentadas, ou seja, olíder tem a capacidade deadequar-se ao momento e ao perfildas equipes, “guiando” osliderados de acordo com anecessidade de cada um.

FERRAMENTAS ÁGEIS

142


• Inteligência emocional

FERRAMENTAS ÁGEIS

143


• Team Building

O termo Team Building significa, em tradução livre, “Construçãode equipe” e é um recurso que as empresas usam para fazercom que o espírito de equipe se desenvolva no ambiente detrabalho melhorando, consequentemente, o desempenho eprodutividade de seus colaboradores.

FERRAMENTAS ÁGEIS

144


• Soft Skills

São as competências sociais e comportamentais que auxiliam na condução de situaçõese desafios do dia-a-dia. As empresas geralmente procuram estas características naslideranças, são elas:

1. Trabalho em equipe

2. Resolução de problemas

3. Atitude Positiva

4. Gestão do tempo

5. Capacidade de comunicação

6. Capacidade de aprender

FERRAMENTAS ÁGEIS

145


• Pilares

• Papéis

• Product Owner

• Scrum Master

• Scrum Team

• Rituais

• Sprint - plan / exec

• Daily Scrum

• Sprint Review Meeting

• Artefatos (documentos)

• Product Backlog

• Sprint Backlog

• BDC - Burn Down Chart

• DoD - Definition of Done

FRAMEWORK SCRUM

146


FRAMEWORK SCRUM

• Framework

147


• Pilares

O Scrum tem uma referência essencial para os seus entusiastas, o “Scrum Guide”, o guia éescrito e fornecido por Ken Schwaber e Jeff Sutherland, idealizadores do Scrum.

Os três pilares do Scrum:

TransparênciaConsiste no alinhamento entre os envolvidos sobre padrões que serão observados,linguagem que será usada no processo para entendimento de todos, clareza nasexecuções e aceitação, resultado do trabalho com definição de “Pronto” (Done) entendidopelos executores e demandantes do produto.

InspeçãoConsiste em inspecionar artefatos produzidos durante as sprints, no anseio de detectarinconformidades que possam prejudicar o objetivo da sprint, cabe pontuar que essasrevisões são mais efetivas quando feitas sem onerar a execução do trabalho.

AdaptaçãoTalvez seja o fator de maior criticidade se observarmos pelo ponto de vista de um processode desenvolvimento tradicional onde qualquer mudança requer todo um novoplanejamento do projeto inteiro.

FRAMEWORK SCRUM

148


• Pilares

Valores do Scrum

ComprometimentoEste valor representa o comprometimento de todos das equipes em alcançar seus objetivoscomuns. Compromisso em fazer o que for preciso para agregar valor ao seu trabalho, desdesaber quem tem a última palavra para melhor forma de obter os resultados até a obediência emcumprir os ritos/eventos do Scrum para estar ciente dos problemas que compete a todos.

CoragemEste valor já vem desde quando se estabelece que o Mindset será mudado, e se decide adotar oScrum. Aqui deve-se entender que os times devem ter coragem para tomarem decisões eenfrentarem as mais diversas situações que nem sempre serão fáceis. Contudo, isso já deveestar bem amadurecido dentro da cultura do cliente para dar assim a autonomia necessária àsequipes.

FocoTodos do time Scrum deve estar focados em alcançar o mesmo objetivo, comunicação constanteentre equipe e cliente, é essencial para o sucesso deste valor. Entender que problemas não sãoculpas individuais e sim responsabilidades coletivas, deve-se procurar ter o comportamento demosqueteiro. Um por todos e todos por um.

FRAMEWORK SCRUM

149


• Pilares

Valores do Scrum

AberturaDevemos considerar esse valor como a aceitação de todos os envolvidos que secomprometeram em praticar Scrum, entender pilares, valores, eventos, artefatos,papéis e acima de tudo estarem preparados para entrarem em algo novo, sabendoque os resultados virão com vivência. Equipes e clientes abertos a comunicação,andando juntos e, acima de tudo, trabalhando de mãos dadas para alcançarem osucesso na forma de trabalho.

RespeitoValor fundamental não só para o Scrum mas para a vida, nesse caso primamos pelorespeito entre os membros da equipe. Trabalhamos com pessoas de todos os jeitos eopiniões, por isso, é inevitável conflitos. Mas, esse cenário temos que evitar omáximo, e se mesmo assim houver problemas temos o papel responsável paramitigar esses conflitos caso isso aconteça, uma ótima sinergia entre os membros daequipe resulta em equipes eficientes e maduras.

FRAMEWORK SCRUM

150


• Papéis

I amPM

FRAMEWORK SCRUM

151


• Papéis - Product Owner

- 01 -Identificar as

necessidades dos usuários e

traduzir para a equipe

- 04 -Patrocinador

Maximizar o ROIGerenciar a restrição tripla

- 09 -Valida os critérios de

aceitação, as entregas e orienta ajustes para

atender às necessidades do cliente

- 08 -Prioriza o trabalho

da equipe

- 02 -Responsável pelo sucesso

do produto- 10 -

Se preocupa com as necessidades dos

usuários e os objetivos comerciais

- 06 -Colabora com a equipe de e

partes interessadas

- 03 -Guiar o projeto na direção

certa

- 07 -Defende o produto/resultado

em nome dos clientes

- 05 -Manter as partes interessadas

informadas da evolução do projeto

É o ponto central do projeto ágil e, exerce a liderança sobre o produto que está sendodesenvolvido.Ele é quem diz o que precisa e o que não precisa ser feito para entregar oprojeto/produto.

- 11 -Participa do

planejamento, conhece o negócio

FRAMEWORK SCRUM

152


• Papéis - Product Owner

Onde atua:

É a preparação e refinamento do Product Backlog, o que inclui: criar, atualizar, estimar e priorizar os itens.

FRAMEWORK SCRUM

153


• Papéis - Scrum Master

Ajuda todos a compreender os valores, princípios e práticas do Scrum.O Scrum Master age como um Coach tanto para a equipe de desenvolvimento quantopara o Product Owner.

Características pessoais de um bom Scrum Master:

FRAMEWORK SCRUM

154



O Dia-a-dia do Scrum MasterComo é a vida de um um Scrum Master durante um sprint?De acordo com Ken Rubin a distribuição do tempo de um Scrum Master durante umSprint ocorre conforme o gráfico abaixo:

FRAMEWORK SCRUM

155



Os 7 Hábitos dos Scrum Masters Altamente Eficazes:

1. Seja Proativo

2. Começar com o objetivo em Mente

3. Primeiro o Mais Imporante

4. Mentalidade Ganha-Ganha

5. Procure Primeiro Compreender, Depois ser Compreendido

6. Criar Sinergia

7. Afinar o Instrumento

Parafraseando a citação de Stephen R.Covey, autor do besteseller‘Os 7 Hábitos das Pessoas Altamente Eficazes’:

“Plante um pensamento, colha uma ação; plante uma ação, colha um hábito; plante um hábito, colha um caráter; plante um caráter, colha um destino.”

FRAMEWORK SCRUM

156


• Papéis - Scrum Team

Equipe executora do projeto que tem o objetivo de gerarr uma ou mais funcionalidadesdo produto em cada Sprint.Isto inclui: a Concepção, o Desenvolvimento, a Integração e os Testes.Desta forma, precisamos de uma equipe que seja hábil em todas essas tarefas.

Principais Responsabilidades

FRAMEWORK SCRUM

157



Profissionais T-Shaped (Modelo T)Habilidades em forma de T significa que um membro da equipe tem habilidadesprofundas em sua área, disciplina ou especialidade preferida.

PERFIL HORIZONTALHabilidade de compreender várias

disciplinas, porém sem aprofundamento em nenhuma área.

EIXO HORIZONTALHabilidade de compreender várias

disciplinas.

PERFIL VERTICALAprofundamento

em uma determinada área, desconhecimento

de outras disciplinas.

GENERALISTA

ESPECIALISTA

EIXO VERTICALConhecimentos sólidos em uma

disciplina específica.

T-Sharped

O objetivo é formar uma equipe com membros que têm as habilidades adequadas para cobrir asprincipais áreas de especialidade e, globalmente, ter alguma sobreposição de competências parafornecer flexibilidade ao time.

FRAMEWORK SCRUM

158



FRAMEWORK SCRUM

159



1

2

3

160


• Rituais - Sprint

SPRINT BACKLOG

É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint.

Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, combase nas prioridades definidas pelo Product Owner e a percepção da equipe sobreo tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serãotrazidos para o Sprint Backlog, já que é ela quem irá se comprometer aimplementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o pararefletir que tarefas são completadas e quanto tempo a equipe acredita que seránecessário para completar aquelas que ainda não estão prontas.

A estimativa do trabalho que ainda resta a ser feito no Sprint é calculadadiariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

FRAMEWORK SCRUM

161



SPRINT PLANNING MEETING

É uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo oScrum Team, bem como qualquer pessoa interessada que esteja representando agerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidadesde maior prioridade para a equipe.

A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar asfuncionalidades em tarefas técnicas, após a reunião.

Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no ProductBacklog.

Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode sersuficiente descrever apenas os itens de maior prioridade, deixando a discussãodos itens de menor prioridade para o próximo Sprint Planning Meeting.

O Scrum Team e o Product Owner definem um objetivo para o Sprint, que é umabreve descrição daquilo que se tentará alcançar no Sprint.

FRAMEWORK SCRUM

162



SPRINT PLANNING MEETING

O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting emrelação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamentepara conversar sobre o que eles escutaram e decidir quanto eles podem secomprometer a fazer no Sprint que será iniciado.

Em alguns casos, haverá negociação com o Product Owner, mas será sempreresponsabilidade da equipe determinar o quanto ela será capaz de secomprometer a fazer.

SPRINT RETROSPECTIVE

Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o quepode ser melhorado e que ações serão tomadas para melhorar.

FRAMEWORK SCRUM

163


• Rituais - Sprint - plan / execB

US

INE

SS

NE

ED

FRAMEWORK SCRUM

164


• Rituais - Sprint - plan / exec

FRAMEWORK SCRUM

165



Sprint é o momento de “mão na massa”, período onde as necessidadesidentificadas junto ao cliente, através do Product Owner (PO), serãotransformadas em “produto” de valor agregado.

Antes de começar a Sprint – Planejamento

1. Antes de iniciar a Sprint, é preciso definir que histórias do Product Backlog serãoimplementadas no ciclo que está para ser iniciado.

2. Para isso as estórias no Product Backlog devem estar em uma ordem de prioridadedefinida pelo PO e devem estar estimadas pela equipe de desenvolvimento.

3. Uma vez que o Product Backlog esteja priorizado e estimado, a equipe dedesenvolvimento realiza uma reunião de planejamento (Planning Session 1) paraselecionar as estórias que serão incluídas na Sprint de modo a acomodá-las dentro dotempo da Sprint e respeitando a priorização definida pelo PO.

4. Este conjunto de estórias incluídas na Sprint é chamado de Sprint Backlog.

5. Uma vez definido o Sprint Backlog, a Sprint pode então ser iniciada!

6. Neste momento a equipe de desenvolvimento parte para um segundo planejamento(Planning Session 2), no qual cada história é subdividida em tarefas menores a fim dese ter um maior controle sobre o desenvolvimento de cada estória individualmente.

FRAMEWORK SCRUM

166



Execução da Sprint

1. Durante a execução da Sprint, a equipe executa as tarefas para a realização dasestórias seguindo a ordem de prioridade definida pelo PO.

2. Ao longo da Sprint a equipe pode utilizar o gráfico de Burndown para ter noção seestá atrasada ou adiantada em relação ao objetivo da Sprint e tomar providênciasse for necessário.

3. Diariamente a equipe se reúne para falar o que foi feito no dia anterior, quais sãoseus impedimentos e o que será feito no dia atual (Daily/Stand up Metting).

4. Caso hajam impedimentos, o Scrum Master (SM) busca resolvê-lo o mais rápidopossível para que a equipe possa dar prosseguimento aos trabalhos da Sprint.

5. O SM também participa desta reunião diária, se for possível.

6. Recomenda-se que não haja qualquer alteração no tempo da Sprint nem nastarefas do Sprint Backlog.

FRAMEWORK SCRUM

Temos as estórias a serem implementadas e as tarefas à seremrealizadas para a implementação de cada história.

167



Após a Sprint – Reunião de Revisão e Reunião de Retrospectiva

1. Ao final da Sprint é realizada a reunião de Revisão (Sprint Review).

2. Nesta reunião, a equipe apresenta as estórias implementadas na Sprint,mostrando o seu resultado para o PO.

3. O PO então analisa o resultado de cada estória junto à equipe e decide se aprovaou não cada uma delas.

4. As histórias reprovadas retornam para o Product Backlog e ficam disponíveis paraserem incluídas em uma nova Sprint.

5. Nesta reunião, aproveitando que PO e equipe estão juntos, também podem serdiscutidas estórias do Product Backlog que não tenham sido bem compreendidaspela equipe de desenvolvimento.

FRAMEWORK SCRUM

A Sprint foi executada e o Product Backlog executado, conformeexpectativas do PO.

168



Após a Sprint – Reunião de Revisão e Reunião de Retrospectiva

6. Após a reunião de revisão a equipe junto ao SM fazem a reunião de Retrospectiva(Retrospective Meeting).

7. Nesta reunião a equipe compartilha a sua opinião e reflete sobre o que funcionoue o que não funcionou ao longo da Sprint.

8. É feita uma discussão sobre os pontos positivos e negativos da Sprint, com oobjetivo de reforçar o que foi bom e levantar soluções para o que foi ruim.

9. Assim, a cada Sprint a equipe vai aprendendo e melhorando o seu processo detrabalho.

FRAMEWORK SCRUM

A Sprint foi executada e o Product Backlog executado, conformeexpectativas do PO.

169


• Rituais - Daily Scrum

Tem como objetivo disseminar conhecimento sobre o que foi feito no diaanterior, identificar impedimentos e priorizar o trabalho a ser realizadono dia que se inicia (?).

1. As Daily Scrums normalmente são realizadas no mesmo lugar, namesma hora do dia.

2. Idealmente são realizados na parte da manhã, para ajudar aestabelecer as prioridades do novo dia de trabalho.

3. Todos os membros da equipe devem participar do Daily Scrum.

4. Outras pessoas também podem estar presentes, mas só poderãoescutar. Isso torna as Daily Scrums uma excelente forma parauma equipe disseminar informações sobre o estado do projeto.

5. A Daily Scrum não deve ser usado como uma reunião pararesolução de problemas.

6. Questões levantadas devem ser levadas para fora da reunião enormalmente tratadas por um grupo menor de pessoas quetenham a ver diretamente com o problema ou possam contribuirpara solucioná-lo.

FRAMEWORK SCRUM

170



7. Durante a Daily Scrum, cada membro da equipe provê respostaspara cada uma destas três perguntas:

1. O que você fez ontem?

2. O que você fará hoje?

3. Há algum impedimento no seu caminho?

8. Concentrando-se no que cada pessoa fez ontem e no que ela iráfazer hoje, a equipe ganha uma excelente compreensão sobre quetrabalho foi feito e que trabalho ainda precisa ser feito.

9. A Daily Scrum não é uma reunião de status report na qual umchefe fica coletando informações sobre quem está atrasado.

10.Ao invés disso, é uma reunião na qual membros da equipeassumem compromissos perante os demais.

11.Os impedimentos identificados no Daily Scrum devem ser tratadospelo Scrum Master o mais rapidamente possível.

FRAMEWORK SCRUM

Tem como objetivo disseminar conhecimento sobre o que foi feito no diaanterior, identificar impedimentos e priorizar o trabalho a ser realizadono dia que se inicia (?).

171



Roteiro Passo-a-Passo

Passo 1

Scrum Master organiza a reunião e avisa todos os envolvidos sobre o local, horário, pauta emodus operandi.

Passo 2

Scrum Master explica as regras do Daily Scrum, e passa o bastão para o Time deDesenvolvimento.

Passo 3

É comum um empasse no início para saber quem vai começar. Uma forma simples de resolverisso é usar a regra do “Quem chega por último, fala primeiro”.

Aqui entram as 3 perguntas básicas que devem ser respondidas:

1. O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?

2. O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?

3. Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimentoda meta da Sprint?

FRAMEWORK SCRUM

172



Roteiro Passo-a-Passo

Passo 4

1. O próximo em ordem de chegada fala a sua parte até que todos falem.

2. É importante definir uma regra (como a do “quem chega por último”) para que o próprio timesaiba quem é o próximo sem precisar da intervenção do facilitador.

3. Isso contribui para que a reunião não ultrapasse os 15 min.

Passo 5

1. O Scrum Master termina a reunião, atualiza o quadro de Kanban e o Burn Down Chart.

2. Além disso, o Scrum Master atualizado os registros de impedimentos que foram levantadospara que ele possa partir para tentar resolvê-los assim que a reunião acaba.

3. O Time de Desenvolvimento ou membros da equipe frequentemente se encontramimediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou re-planejar, o restante do trabalho da Sprint, mas isso é feito de forma isolada e não faz parteda Daily Scrum.

FRAMEWORK SCRUM

173


• Rituais - Sprint Review Meeting

1. Ao final de cada Sprint é feito um Sprint Review Meeting.

2. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint.Tipicamente, isso tem o formato de uma demonstração das novasfuncionalidades.

3. Os participantes do Sprint Review geralmente são o Product Owner, o ScrumTeam, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

4. Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint,determinados durante o Sprint Planning Meeting.

5. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidospara fazer parte do Sprint, mas o importante mesmo é que a equipe atinja oobjetivo geral do Sprint.

FRAMEWORK SCRUM

Reunião com o objetivo de verificar se o objetivo do Sprint foialcançado, se está de acordo com as expectativas do PO e atendendoàs necessidades do cliente.

174


• Artefatos (documentos) - Product Backlog

1. Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e osdescreve para a equipe.

2. A equipe então determina que itens será capaz de completar durante a Sprint que está porcomeçar.

3. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog.

4. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do SprintBacklog.

5. Isso ajuda a dividir o trabalho entre os membros da equipe.

6. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadasàs funcionalidades solicitadas.

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. Oconteúdo desta lista é definido pelo Product Owner.

O Product Backlog não precisa estar completo no início de um projeto.

Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento.

Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto eseus usuários.

FRAMEWORK SCRUM

175


• Artefatos (documentos) - Sprint Backlog

1. Cabe a equipe determinar a quantidade de itens do Product Backlog que serãotrazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

2. Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o pararefletir que tarefas são completadas e quanto tempo a equipe acredita que seránecessário para completar aquelas que ainda não estão prontas.

3. A estimativa do trabalho que ainda resta à ser feito no Sprint é calculada diariamentee colocada em um gráfico, resultando em um Sprint Burndown Chart.

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer emum Sprint.

Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nasprioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo queserá necessário para completar as várias funcionalidades.

FRAMEWORK SCRUM

176


• Artefatos (documentos) - GroomingA palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado.

O Product Backlog vai crescendo com o tempo e pode se tornar desorganizado.

É necessário dar atenção e de cuidados contínuos ao Product Backlog, afinal, é dentro deleque estão todas as funcionalidades que o produto irá possuir.

Foi pensando nesses cuidados que as reuniões de Backlog Grooming foram criadas, oobjetivo é de garantir que o Product Backlog esteja sempre organizado e possa ser cumprido.

O propósito das reuniões de Backlog Grooming (Refinamento do Backlog) é aprimorar oProduct Backlog.

Uma reunião de Backlog Grooming deve ser realizada próximo ao final da iteração, garantindoassim, que o Product Backlog esteja sempre pronto para a próxima.

Durante uma reunião de Backlog Grooming, a equipe e o Product Owner discutem osprincipais itens do Backlog.

Para a equipe é dada a chance de fazer perguntas que normalmente surgem durante oplanejamento da iteração, como:

• O que deve acontecer se o usuário inserir dados errados aqui?

• Todo usuário vai ter permissão para acessar essa parte do sistema?

• O que acontece se…?

FRAMEWORK SCRUM

177


• Artefatos (documentos) - Grooming

Organizar o Backlog Grooming envolve também:

Além da chance para a equipe fazer perguntas, a reunião de Backlog Grooming também envolve:

1. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;

2. Estimar e corrigir estimativas dos itens do Product Backlog (em caso de novas descobertas);

3. A descoberta de novos itens;

4. A alteração de itens existentes;

5. A remoção de itens antigos ou desnecessários;

6. A divisão de estórias muito grandes;

7. A priorização dos itens do ProductBacklog;

8. Incluir critérios de aceitação;

9. E tudo mais que envolverorganização, ordenação e“limpeza”.

FRAMEWORK SCRUM

178


• Artefatos (documentos) - DoD - Definition of Done

A Definição de Pronto (ou Definition of Done em inglês), busca orientar o time para que tenhaum entendimento comum à respeito do que significa uma entrega pronta.

Existem diversas formas de planejar a Definição de Pronto, o importante é você compreendero conceito e acima de tudo, adaptar à sua realidade, afinal este é um dos pilares do Scrum.

Existem diversas formas de planejar a DoD, o importante é vocêcompreender o conceito e acima de tudo, adaptar à sua realidade, afinaleste é um dos pilares do Scrum.

Pronto significa pronto mesmo…Não tem aquele de “Veja Bem….” ou “Sófalta uma coisinha…”

A DoD é um acordo formal do ScrumTeam que define claramente quaissão os passos mínimos para a conclusão de um item.

Serve como um contrato entre o ScrumTeam e o Product Owner,garantindo que todo o produto gerado pelo projeto estará dentro dospadrões de qualidade estabelecidos entre eles.

O documento de DoD pode evoluir ao longo do projeto, porém érecomendável que a primeira versão seja criada durante a 1ª Sessão deSprint Planning, isto é, antes de iniciar o 1º Sprint do projeto.

FRAMEWORK SCRUM

179


• Artefatos (documentos) - DoD - Definition of Done

É imperativo que a DoD seja revisitada a cada Sprint.

Um momento que pode ser útil para verificar se a DoD está adequada é o Sprint Review, afinal,se o produto apresentar qualquer “Desvio”, a probabilidade da culpa ser de uma DoD maldefinida é altíssima.

Benefícios da DoD1. O ScrumTeam e os demais stakeholders do projeto passam a utilizar

um vocabulário único, seguro e irrestrito para a palavra 'Pronto’;

2. A confiança dos demais stakeholders aumenta em relação aoScrumTeam;

3. Os Releases passam a ser mais previsíveis em termos de qualidade;

4. Qualquer impedimento é rapidamente identificado, tornado público eendereçado;

5. Os membros de toda a equipe passam a compreender melhor asexpectativas de entrega do Projeto e trabalham para cuidar que oproduto seja entregue com a qualidade esperada;

6. A Melhoria contínua passa a ser a cultura do projeto.

FRAMEWORK SCRUM

180


• Artefatos (documentos) – Burndown Chart

O Burndown chart é o gráfico utilizado pelas equipes Scrum pararepresentar diariamente o progresso do trabalho. Ou seja, após cadadia de trabalho o gráfico apresenta a porção de trabalho finalizada emcomparação com o trabalho total planejado.

As equipes podem usar 2 tipos de gráficos de controle de progresso: Burndown chart eBurnup chart.

Ambos os gráficos representam progresso do trabalho das equipes ágeis (na entrega dotrabalho).

Estes gráficos medem a velocidade média de entrega das equipes, ou seja, o quanto a equipeé capaz de entregar dentro de um prazo determinado.

Permitem identificar fatores que podem influenciar na alteração da produtividade: tarefasmuito complexas ou mal planejadas, ausência de membros da equipe, impactos externos, etc.

O fato de uma equipe não finalizar as histórias ao final da sprint podeser não por falta de comprometimento da equipe executora, mas pelaindisponibilidade do PO em ajudar a equipe no momento que ela maisprecisa, ou do Scrum Master que não resolve em tempo osimpedimentos que surgem em uma sprint.

FRAMEWORK SCRUM

181


• Artefatos (documentos) – Burnup e Burndown Charts

A diferença se dá na maneira como os gráficos são apresentados.

BURNUP CHART – demonstra o total que foi planejado e o quanto a equipe já progrediu paraalcançar o objetivo. É mais utilizado para medir a entrega do projeto como um todo. Mostra o que jáfoi feito até o momento, do todo.

BURNDOWN CHART – demonstra a performance da equipe comparando o que foi planejado com oque foi entregue, permite saber se a equipe está à frente ou atrás no cronograma, desta forma épossível adotar medidas para correções de rota. Mostra o quanto falta para atingir uma metaespecífica.

B U R N U P B U R N D O W N

FRAMEWORK SCRUM

182


• Artefatos (documentos) – Release

Scrum Release do Produto é a entrega de um ou mais Incrementos do Produtoprontos, gerados pelo time de execução em um ou mais Sprints sucessivos,para que sejam utilizados.

Projetos com Scrum realizam Releases frequentes, com intervalos máximos dealguns poucos Sprints entre elas.

A realização de Releases ao longo do projeto tem três objetivos principais:

1. Obter feedback frequentemente;

2. Prover retorno ao investimento dos clientes;

3. Dar um senso de progresso aos clientes.

FRAMEWORK SCRUM

Antes é preciso entender...

O que é a Release do Produto

183





FRAMEWORK SCRUM

184



FRAMEWORK SCRUM



185



Podemos ter burndown para release e para sprint.

Passos para criação do burndown chart

1. Backlog é priorizado, estimado e revisado;

2. A equipe define o que seria a primeira release;

3. É feita a estimativa e conta-se os pontos (de acordo com o consenso da equipe);

4. A equipe determina a velocidade de execução, de acordo com uma estimativapreviamente definida;

FRAMEWORK SCRUM

186



ATRASADO

ANTES DO PREVISTO

FRAMEWORK SCRUM

187



FRAMEWORK SCRUM

188



30

29

28

27

26

25

24

23

22

21

20

19

18

17

16

15

14

13

12

11

10

09

08

07

06

05

04

03

02

01

SPRINT 1 SPRINT 2 SPRINT 3

a. O eixo y (vertical) representa omontante de trabalho a serrealizado (que pode ser o totalde Pontos de Função);

b. O eixo x (horizontal) o tempoque temos para realizar otrabalho (geralmente aSprints).

c. Traça-se uma linha diagonalentre o topo o eixo y até o finaldo eixo x.

1

1. Sprint 1 deverá serrealizada em 6 pontos;

2. Sprint 2 deverá serrealizada em 12 pontos;

3. Sprint 3 deverá serrealizada em 12 pontos.

2

3

Eixo de T E M P O

Eixo de PRODUTIVIDADE

FRAMEWORK SCRUM

PONTOS: a equipe deverá definir como irá medir o avanço das sprints (dias,

pontos de função, etc)

189



FRAMEWORK SCRUM

190


[email protected]

pmpartner.com.br

34 9 9338-6887

CONTATOS