scrum: o sucesso nos projetos através da gerência Ágil objetivos

“um framework para desenvolver produtos

complexos em ambientes complexos”

Rafael Sabbagh, CSM, CSP

Marcos Garrido, CSPO

Um pouco de história...

• Década de 50: a gestão de projetos é reconhecida

como disciplina, nascida a partir da administração

• Henri Fayol:

– Seu trabalho é a base para a gestão de projetos

tradicional

– O gestor possui 5 funções básicas:

• O gráfico de Gantt é adotado como ferramenta para

listar, acompanhar e controlar a execução das tarefas

contidas em um projeto.

Planejar Organizar Comandar Controlar Coordenar


• Até então a gestão de projetos é voltada para grandes projetos de engenharia e construção civil.

• Década de 60: o desenvolvimento de software começa a ganhar complexidade.

• Para gerenciar projetos de software, as empresas utilizam a medotologia tradicional antes aplicada a projetos de engenharia e construção civil.

• Winston Royce (1970): artigo criticando aabordagem tradicional para a gestão de projetos de software, que fica conhecida como waterfall.


• Waterfall, por Winston Royce (1970)


• Waterfall segue o conceito Big Design Up Front (BDUF).

• Os defensores do BDUF acreditam que o tempo gasto revisando exaustivamente a especificação garante a ausência de mudanças críticas na fase de execução.

• McConnell (1996): “corrigir erros ainda na fase de especificação gasta entre 50 e 200 vezes menos tempo do que se o erro fosse encontrado durante a execução do projeto”.


• DeGrace & Stahl (1990): Fatores que tornam questionável o uso de BDUF para projetos de software:

– Requisitos não são completamente compreendidos no

início do projeto;

– Usuários só sabem exatamente o que querem após ver

uma versão inicial do software;

– Requisitos mudam durante o processo de

desenvolvimento;

– Novas ferramentas e tecnologias tornam a estratégia

de desenvolvimento imprevisível.

• BDUF é considerado adequado apenas para projetos estáveis, com pouca ou nenhuma mudança.


• Recente pesquisa no Brasil com gerentes de projeto aponta a mudança de escopo(71%) como o fator principal para insucesso em projetos de software.

• Meredith & Mantel: “problemas de comunicação e entendimento do que deve ser feito são responsáveis por falhas nos projetos”.

• Metodologias tradicionais sugerem que:

– Mudanças devem ser evitadas a todo custo.

– Se não for possível evitá-las, o gerente de projetos deve gerenciá-las.

• Para as metodologias tradicionais, a mudança tem um efeito devastador


• Ken Schwaber (2007):

• Não há mais soluções simples de software.

• Quando requisitos complexos encontram tecnologias complexas, a complexidade da solução cresce exponencialmente.


Fonte: Standish Group

Agilidade

Manifesto Ágil

"Estamos descobrindo maneiras melhores de desenvolver software 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

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

itens à esquerda."

2001 - representantes de processos leves de

desenvolvimento de software se reuniram para discutirem o

que seus processos possuíam em comum.

O resultado foi o Manifesto Ágil:

Princípios Ágeis

• Satisfação do cliente através da entrega rápida e frequente de produto funcional

• Produto funcional é a principal medida de progresso do projeto

• Mudanças são vistas como parte natural do processo e são bem-vindas

• Cooperação diária entre a equipe de projeto e o pessoal de negócios

• Comunicação aberta dentro da equipe

Princípios Ágeis

• Equipe de pessoas motivadas, com o suporte necessário e confiança

• Atenção contínua para o bom design e excelência técnica

• Simplicidade. Nada de desperdícios!

• Equipes autogerenciadas: Empowerment!

• Foco maior nas pessoas do que nos processos

• Melhoria contínua

Aplicação

Métodos Ágeis não servem apenas para desenvolvimento de software!

Aplicação

Métodos ágeis podem ser utilizados em projetos em que há:

- Ambiente de mudanças frequentes- Requisitos

- Tecnologia

- Leis e regras

- Ambiente de incertezas

- Necessidade de entrar rapidamenteno mercado- Oportunidades

- Responder a uma ameaça

Aplicação

Exemplos:

• Alexandre Magno (CST): Scrum

Executivo – mudança organizacional

• Projetos de Marketing

• Projetos de Hardware

• Infra-estrutura

• Jogos olímpicos, Copa do mundo…

O que é Scrum?

Scrum...

• ...é um framework para desenvolvimento de produtos complexos em ambientes complexos;

• ...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas;

• ...utiliza abordagem iterativa e incremental para melhorar a predizibilidade e o controle de riscos;

• ...gera entrega frequente de valor para o cliente;

• ...torna transparentes problemas das práticas de desenvolvimento, para que se possa melhorá-las;

• ...utiliza inspeção e adaptação para melhoria contínua, em ciclos de feedback.

Scrum: Origens

• Ken Schwaber: www.controlchaos.com

• Jeff Suttherland: jeffsutherland.com

• Mike Beedle: www.mikebeedle.com

• “The New New Product Development

Game”, de Takeuchi e Nonaka

• Sistema de Produção da Toyota: modelo

enxuto e just-in-time

http://www.controlchaos.com/

http://jeffsutherland.com/

http://www.mikebeedle.com/

Processos Definidos X Empíricos

• Processo definido

– Ambientes controlados – ex: linhas de produção

• Processo empírico:

– Complexos e imprevisíveis

• Scrum é embasado na teoria de controle de

processos empíricos

• Três pilares sustentam a teoria de controle

de processos empíricos: Transparência,

Inspeção e Adaptação

Pilares

Os Pilares do Scrum

• #1: Transparência

– Aspectos que afetam o resultado do

projeto devem ser visíveis para os

que gerenciam estes resultados

– O que é visto deve ser compreendido:

se quem inspeciona o processo

acredita que está pronto, isso deve

corresponder à definição de pronto

utilizada

Os Pilares do Scrum

• #2: Inspeção

– Deve haver inspeção no processo

com frequência suficiente para se

detectar variações inaceitáveis

Os Pilares do Scrum

• #3: Adaptação

– Ao se detectar variações

inaceitáveis, o processo deverá ser

ajustado o tão rápido quanto

possível para se minimizar desvios

ainda maiores

Introdução ao

Ciclo do Scrum

O Ciclo do Scrum

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA

INCREMENTO DO PRODUTO

POTENCIALMENTENTREGÁVEL

2-4 SEMANAS

24 HORAS

O representante do cliente, o PRODUCT

OWNER, levanta com o cliente requisitos

mais prioritários no momento

Ele então insere estes requisitos

em uma lista priorizada, chamada

BACKLOG DO PRODUTO

A equipe então se reúne com o

representante do cliente e decide, a partir

dessa lista de requisitos, o que será feito

no próximo ciclo de desenvolvimento:

o BACKLOG DA SPRINT

A equipe faz o trabalho no ciclo de

desenvolvimento, chamado de SPRINTEm cada dia, a equipe faz uma reunião de

15 minutos para promover visibilidade e

comunicação

Ao final do ciclo de desenvolvimento, a

equipe terá produzido um incremento no

produto, que significa valor para o cliente

A equipe então se reúne com o

representante do cliente na REUNIÃO DE

REVISÃO e apresenta o que foi feito

E, em seguida, se reúne para a

RETROSPECTIVA, onde verifica o que

funcionou bem e o que pode melhorar no

próximo ciclo de desenvolvimento

Papéis

Papéis no Scrum

• ScrumMaster:

– responsável por garantir que o processo

é entendido e seguido

• Product Owner:

– responsável por maximizar o valor, para

o cliente, do trabalho que o Time de

Scrum faz

• Time de Scrum:

– é a equipe, que faz o trabalho

propriamente dito

Papéis no Scrum: O ScrumMaster

• Garante a adesão do time aos valores do Scrum, práticas e regras

• Ajuda o Time de Scrum e a organização a adotarem o Scrum

• Remove os impedimentos que atrapalham o trabalho do Time de Scrum

• Ajuda o Time de Scrum a usar o auto-gerenciamento e a multidisciplinaridade, a ser mais produtivo e a ter mais qualidade

• O ScrumMaster não gerencia o Time de Scrum: o Time de Scrum é auto-organizável

Papéis no Scrum: O Product Owner

• Gerencia a lista de requisitos (Backlog do Produto) através do contato frequente com o(s) cliente(s), e garantir sua visibilidade a todos

• Assegura o valor do trabalho realizado pelo Time de Scrum: garante o ROI do cliente

• Gerencia a visão do produto: estabelece, mantém e comunica

• Gerencia as entregas do produto para o cliente

• É sempre uma pessoa, e não um comitê. Mas pode ser aconselhado/influenciado por outras pessoas

• Suas decisões devem ser respeitadas: ninguém mais pode mudar as prioridades

Papéis no Scrum: O Time de Scrum

• É a equipe de desenvolvimento do projeto, com 5 a 9 membros, que:

• Transformam a lista de requisitos (Backlog do Produto) em incrementos de funcionalidades potencialmente entregáveis em cada iteração

• São multidisciplinares: todo conhecimento necessário para gerar o incremento

• Não há títulos no Time de Scrum

• Gerenciam a iteração de desenvolvimento

• São auto-organizáveis: ninguém diz ao Time de Scrum como transformar o Backlog do Produto em incrementos entregáveis.

O Ciclo do

Scrum

Backlog do Produto

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

O Product Owner levanta com o(s)

cliente(s) os requisitos mais prioritários

naquele momento

Backlog do Produto

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

O Product Owner levanta com o(s)

cliente(s) os requisitos mais prioritários

naquele momento

O Product Owner insere estes

requisitos no BACKLOG DO

PRODUTO

O que é o Backlog do Produto?

• É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento

• A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade

• Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto

• O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto

• Nunca está completo – evolui à medida que o produto e o ambiente evoluem

• Seus itens possuem descrição e estimativa em pontos de esforço. Itens do alto da lista são de menor granularidade e mais detalhados

Reunião de Planejamento da Sprint

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

O Time de Scrum então se reúne com o

Product Owner e decide, a partir do

Backlog do Produto, o que será feito no

próximo ciclo de desenvolvimento:

o BACKLOG DA SPRINT

O que é a Reunião de Planejamento da Sprint?

• Planejamento da iteração:– Time de Scrum e Product Owner defininem que

itens do Backlog do Produto serão implementados na Sprint e os quebram em tarefas - Backlog da Sprint

• 1a. Parte: O quê?– Escolha de itens mais prioritários do Backlog do

Produto a serem implementados

– Definição da Meta da Sprint

• 1a. Parte: Como?– Time de Scrum quebra itens em tarefas e estima

o tempo que levará para realizar cada tarefa

O que é o Backlog da Sprint?

• Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas

• Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint

• Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint

• O Backlog da Sprint é modificado ao longo da Sprint –estimativas são atualizadas, tarefas podem surgir para os itens já existentes

• Deve ter alta visibilidade

• Pertence ao Time de Scrum

A Sprint

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

O Time de Scrum faz o trabalho no ciclo

de desenvolvimento, a SPRINT

O que é a Sprint? (1/2)

• Sprint é a iteração (ciclo) de desenvolvimento– Reunião de Planejamento da Sprint

– Trabalho de Desenvolvimento

– Revisão e Retrospectiva da Sprint

• Cada Sprint deve ter uma Meta

• Tem duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra– Duração deve contemplar horizonte curto suficiente

para que mudanças não alterem a Meta

• ScrumMaster deve assegurar que não seja feita nenhuma mudança que afete a Meta da Sprint

O que é a Sprint? (2/2)

• Cada Sprint deve ter como saída um

incremento do produto

potencialmente entregável

• A Sprint pode ser cancelada se a

Meta da Sprint perder o sentido –

somente Product Owner pode decidir

• É muito raro a Sprint ser cancelada

A Reunião Diária

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

Em cada dia, o Time de Scrum faz uma

reunião de 15 minutos para promover

visibilidade e comunicação

O que é a Reunião Diária?

• Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora. – Visibilidade

– Comunicação

– Decisão rápida

• Cada membro do Time de Scrum detalha:

– O que ele completou desde a última reunião diária;

– O que ele vai fazer antes da próxima reunião diária;

– Quais obstáculos estão em seu caminho.

• O ScrumMaster deve remover os obstáculos encontrados

• O gráfico de BURNDOWN deve ser atualizado!

O que é o Burndown da Sprint?

• É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo

– Y: tempos estimados restantes

– X: dias da Sprint

• Serve para acompanhar o progresso em direção ao final de um sprint

• É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint

Incremento no Produto

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

Ao final da Sprint, o Time de Scrum terá

produzido um incremento PRONTO no

produto, que significa valor para o cliente

O que significa Pronto?

• Ao final da Sprint, o trabalho desenvolvido deve estar pronto

• Mas o que significa “pronto”?

• O Time de Scrum e o Product Owner devem definir o que significa “pronto”

• Quando alguém diz que algo está “pronto”, todos devem entender o que isso significa

• Ex. de software: codificado, testado e documentado

A Reunião de Revisão da Sprint

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

O Time de Scrum então se reúne com o

Product Owner e apresenta o que foi feito

na REUNIÃO DE REVISÃO DA SPRINT

O que é a Revisão da Sprint?

• Reunião onde o Time mostra aos

stakeholders o que foi feito durante a Sprint:

– Product Owner presente

• Time de Scrum demonstra o que fez e

responde a perguntas

• Product Owner verifica o que foi e o que não

foi feito na Sprint

• Deve prover entradas para a Reunião de

Planejamento de Sprint seguinte

A Reunião de Retrospectiva

BACKLOG DO

PRODUTO

BACKLOG DA SPRINT

REUNIÃO DIÁRIA



2-4 SEMANAS

24 HORAS

E, em seguida, o Time de Scrum se reúne

para a RETROSPECTIVA, onde verifica o

que funcionou bem e o que pode melhorar

na próxima Sprint

O que é a Retrospectiva da Sprint?

• Reunião para inspecionar como correu a

Sprint com relação às pessoas,

relacionamentos, processos e ferramentas:

– Product Owner não deve estar presente

• Identificar e priorizar:

– O que foi bem?

– O que pode melhorar?

• Identificar ações para melhorias - adaptação

E o ciclo recomeça...

BACKLOG DO

PRODUTO

2-4 SEMANAS

Scrumvs.

Métodos Tradicionais

Desperdício

Metodologias não-ágeis afirmam que devem ser gerados

inúmeros documentos para o sucesso do projeto

Termo de

Abertura

Declaração

Preliminar

de Escopo

Plano de

Gerenciamento

do Projeto

Pedidos de

Mudança

Relatório de

Progresso

Relatório de

Desempenho

Relatório de

Aceite

Relatório de

Encerramento

Cronograma

Detalhado

Análise de

Earned Value

Documento de

Lições

Aprendidas

Diagramas de

SequênciaDiagrama de

Componentes

Diagrama de

Colaboração

Diagrama

de Estados

Diagrama de

Casos de Uso

Diagrama

de Pacotes

Diagrama de

Atividades

...algo

mais?

Desperdício

Metodologias não-ágeis afirmam que devem ser gerados

inúmeros documentos para o sucesso do projeto

Termo de

Abertura

Declaração

Preliminar

de Escopo

Plano de

Gerenciamento

do Projeto

Pedidos de

Mudança

Relatório de

Progresso

Relatório de

Desempenho

Relatório de

Aceite

Relatório de

Encerramento

Cronograma

Detalhado

Análise de

Earned Value

Documento de

Lições

Aprendidas

Diagramas de

SequênciaDiagrama de

Componentes

Diagrama de

Colaboração

Diagrama

de Estados

Diagrama de

Casos de Uso

Diagrama

de Pacotes

Diagrama de

Atividades

...algo

mais?

O custo de produção e manutenção

destes documentos compensa?

Quantos destes documentos se

manterão atualizados?

Quantos serão realmente úteis para o

desenvolvimento do projeto?

Desperdício

Fonte: Standish Group CHAOS Report

Em projetos típicos, 50% do tempo é gasto

com requisitos, arquitetura e especificação

Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção

e isso tudo é feito antes de se

construir qualquer funcionalidade!

Desperdício

Fonte: Standish Group CHAOS Report

• 35% dos requisitos mudam

• 65% das funcionalidades nunca ou

raramente serão utilizadas

Em projetos típicos, 50% do tempo é gasto

com requisitos, arquitetura e especificação

Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção

e para

piorar...

Desperdício

Afinal, o objetivo do projeto é o

produto, e não a documentação!

Com Scrum, o projeto deve ter somente a

documentação suficiente e necessária.

Ou seja, adote somente o que será usado.

Desperdício

Com Scrum, o Product Backlog é

dinâmico, pois ele deve sempre

acompanhar as necessidades do cliente, que

mudam ao longo do projeto.

Assim, o que for entregue, deverá ser usado pelo cliente.

Sempre serão feitas as funcionalidades que

são de maior importância para o cliente no

momento anterior ao início de cada sprint.

Maior Valor Primeiro

Em metodologias não-

ágeis, o cliente só percebe

retorno ao investimento no

final do projeto.

Entrega


No Scrum, O Product

Owner deve sempre

alimentar e reordenar o

Product Backlog,

priorizando os itens de

maior valor para o cliente.

Assim, Scrum garante que

os itens de maior valorsejam entregues primeiro,

gerando ROI para o

cliente frequentemente.


• A priorização do Product Backlog pelo maior

valor permite à organização:

– entregar resultados para seu cliente mais

rápido que a concorrência

– colocar em produção funcionalidades que

agregam maior valor a seu negócio mais

rapidamente

– lançar produtos e novas versões no mercado

mais rapidamente

Mudanças Frequentes

Como as metodologias tradicionais lidam

com a mudança?

Mudança é

indesejada!

Mudança é

arriscada!

Mudança é

cara!

Mudança

deve ser

negociada!

Como quase todo o planejamento é feito

no começo do projeto, há pouquíssimo

espaço para mudanças!


Como as metodologias tradicionais lidam

com a mudança?

O contrato com escopo amarrado deve nos

defender! O cliente vai querer mudar tudo!

Cada mudança deve ser negociada com o

cliente! Seu impacto deve ser quantificado!

Cada mudança deve ser revista, aprovada,

planejada, documentada e gerenciada!


Gerenciamento da mudança é fonte de

estresse em projetos que utilizam

metodologias não-ágeis.

Estresse no relacionamento de longo

prazo com o cliente.

Estresse no dia-a-dia da equipe de

desenvolvimento.


Como o Scrum lida com a mudança?

Scrum encara a mudança como parte naturaldo processo de desenvolvimento

Manifesto ágil: “responder às mudançasmais que seguir um plano”


Como o Scrum lida com a mudança?

...e assim, mudanças já podem ser

introduzidas no produto na sprint seguinte!

A resposta rápida à mudança pode se

transformar em vantagem competitiva!

O Product Backlog é constantemente

atualizado pelo Product Owner...

Comunicação

O cliente percebe o projeto como

uma grande caixa preta, cujo

conteúdo será revelado apenas no

final do processo

Em um projeto waterfall, quando o cliente

é encorajado a participar?

Análise de Requisitos Especificação / Arquitetura Implementação ManutençãoTestes

Testes de Aceitação

Comunicação

Assim, ao final do

projeto, o resultado

dificilmente atenderá às

necessidades do cliente

naquele momento!

Comunicação

Como o Scrum lida com a comunicação?

O Product Owner está em frequente

contato com o cliente para

levantar suas necessidades...

...e assim manter o Product Backlog

constantemente atualizado e

priorizado.

Comunicação


O cliente recebe frequentemente

novas versões...

...e assim pode mais rapidamente

dar feedback para a equipe, via

Product Owner.

Comunicação


Desta forma, o cliente se sente

envolvido em todo o processo...

...compartilhando com a equipe a

responsabilidade sobre o projeto...

...aumentando seu grau de

confiança na equipe e no processo.

Comunicação

A relação com o cliente deixa de ser

meramente comercial, e passa a contemplar:

Parceria Cumplicidade Satisfação Fidelidade

E assim, cria-se uma relação de longo

prazo com o cliente.

Comunicação

Em metodologias não-ágeis, como se

promove a visibilidade no projeto

para seus stakeholders?

de Estados

Principalmente através de documentação...

...que dá

muito

trabalho

...que não é

eficiente

...que não

se mantém

atualizada

...que acaba

deixada de

lado

Comunicação

No Scrum, a visibilidade no projeto é

constantemente promovida!

Reuniões

diáriasKanban

Equipe em

um mesmo

ambiente

Envolvimento

do cliente

Gráficos de

Burndown

Entregas

frequentes

Reunião de

Revisão

Retros-

pectiva

...são alguns exemplos.

Comunicação

Manter comunicação aberta entre os

stakeholders do projeto é a melhor forma de

garantir que todos saibam o que deve ser

feito e o que está sendo feito.

Isso gera aumento de

produtividade!

Scrum na Petrobras

Case de Sucesso

Material para estudo

• Acesse: http://public.me.com/mgarridobr

• Material Disponível:

– Esta apresentação

– Guia do Scrum em Português

– Artigo sobre waterfall de Winston Royce

– Artigo “The New New Product Development

Game”, de Takeuchi e Nonaka

– CHAOS Report

– Scrum Executivo, por Alexandre Magno

– PPT: Por que Scrum é a melhor opção em

tempos de crise

• Material ficará disponível para download

durante a semana.

http://public.me.com/mgarridobr

Obrigado!

Rafael Sabbagh

[email protected]

Marcos Garrido

[email protected]

scrum: o sucesso nos projetos através da gerência Ágil objetivos

Documents