um framework para desenvolver produtos complexos em ambientes complexos

Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

Um pouco de histria...
Dcada de 50: a gesto de projetos reconhecida como disciplina, nascida a partir da administrao Henri Fayol:
Seu trabalho a base para a gesto de projetos tradicional O gestor possui 5 funes bsicas: Planejar Organizar Comandar Controlar Coordenar

O grfico de Gantt adotado como ferramenta para listar, acompanhar e controlar a execuo das tarefas contidas em um projeto.

Um pouco de histria...
At ento a gesto de projetos voltada para grandes projetos de engenharia e construo civil. Dcada de 60: o desenvolvimento de software comea a ganhar complexidade. Para gerenciar projetos de software, as empresas utilizam a medotologia tradicional antes aplicada a projetos de engenharia e construo civil. Winston Royce (1970): artigo criticando a abordagem tradicional para a gesto de projetos de software, que fica conhecida como waterfall.

Um pouco de histria...
Waterfall, por Winston Royce (1970)

Um pouco de histria...

Um pouco de histria...
Waterfall segue o conceito Big Design Up Front (BDUF). Os defensores do BDUF acreditam que o tempo gasto revisando exaustivamente a especificao garante a ausncia de mudanas crticas na fase de execuo. McConnell (1996): corrigir erros ainda na fase de especificao gasta entre 50 e 200 vezes menos tempo do que se o erro fosse encontrado durante a execuo do projeto.

Um pouco de histria...
DeGrace & Stahl (1990): Fatores que tornam questionvel o uso de BDUF para projetos de software:
Requisitos no so completamente compreendidos no incio do projeto; Usurios s sabem exatamente o que querem aps ver uma verso inicial do software; Requisitos mudam durante o processo de desenvolvimento; Novas ferramentas e tecnologias tornam a estratgia de desenvolvimento imprevisvel.

BDUF considerado adequado apenas para projetos estveis, com pouca ou nenhuma mudana.

Um pouco de histria...
Recente pesquisa no Brasil com gerentes de projeto aponta a mudana de escopo (71%) como o fator principal para insucesso em projetos de software. Meredith & Mantel: problemas de comunicao e entendimento do que deve ser feito so responsveis por falhas nos projetos. Metodologias tradicionais sugerem que:
Mudanas devem ser evitadas a todo custo.

Se no for possvel evit-las, o gerente de projetos deve gerenci-las.

Para as metodologias tradicionais, a mudana tem um efeito devastador

Um pouco de histria...

Um pouco de histria...
Ken Schwaber (2007): No h mais solues simples de software. Quando requisitos complexos encontram tecnologias complexas, a complexidade da soluo cresce exponencialmente.

Um pouco de histria...

Um pouco de histria...

Fonte: Standish Group

Agilidade

Manifesto gil
2001 representantes de processos leves de desenvolvimento de software se reuniram para discutirem o que seus processos possuam em comum. O resultado foi o Manifesto gil:
"Estamos descobrindo maneiras melhores de desenvolver software fazendoo ns mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar: Indivduos e interao entre eles mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda."

Princpios geis
Satisfao do cliente atravs da entrega rpida e frequente de produto funcional Produto funcional a principal medida de progresso do projeto Mudanas so vistas como parte natural do processo e so bem-vindas Cooperao diria entre a equipe de projeto e o pessoal de negcios Comunicao aberta dentro da equipe

Princpios geis
Equipe de pessoas motivadas, com o suporte necessrio e confiana Ateno contnua para o bom design e excelncia tcnica Simplicidade. Nada de desperdcios! Equipes autogerenciadas: Empowerment! Foco maior nas pessoas do que nos processos Melhoria contnua

Aplicao

Mtodos geis no servem apenas para desenvolvimento de software!

Aplicao
Mtodos geis podem ser utilizados em projetos em que h: - Ambiente de mudanas frequentes
- Requisitos - Tecnologia - Leis e regras

- Ambiente de incertezas - Necessidade de entrar rapidamente no mercado

- Oportunidades - Responder a uma ameaa

Aplicao
Exemplos: Alexandre Magno (CST): Scrum Executivo mudana organizacional Projetos de Marketing Projetos de Hardware

Infra-estrutura
Jogos olmpicos, Copa do mundo

O que Scrum?

Scrum...
... um framework para desenvolvimento de produtos complexos em ambientes complexos; ...no um processo ou tcnica: dentro de Scrum podem-se empregar diversos processos e tcnicas; ...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 prticas de desenvolvimento, para que se possa melhor-las; ...utiliza inspeo e adaptao para melhoria contnua, 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 Produo da Toyota: modelo enxuto e just-in-time

Processos Definidos X Empricos

Processo definido
Ambientes controlados ex: linhas de produo

Processo emprico:
Complexos e imprevisveis

Scrum embasado na teoria de controle de processos empricos Trs pilares sustentam a teoria de controle de processos empricos: Transparncia, Inspeo e Adaptao

Pilares

Os Pilares do Scrum
#1: Transparncia
Aspectos que afetam o resultado do projeto devem ser visveis para os que gerenciam estes resultados O que visto deve ser compreendido: se quem inspeciona o processo acredita que est pronto, isso deve corresponder definio de pronto utilizada

Os Pilares do Scrum
#2: Inspeo
Deve haver inspeo no processo com frequncia suficiente para se detectar variaes inaceitveis

Os Pilares do Scrum
#3: Adaptao
Ao se detectar variaes inaceitveis, o processo dever ser ajustado o to rpido quanto possvel para se minimizar desvios ainda maiores

Introduo ao Ciclo do Scrum

O Ciclo do Scrum
Ele ento do emfaz o trabalho compara A equipe seguida, se rene o O representante insereentoose reneno ciclo dea A equipe estes requisitos E, cliente, PRODUCT A equipe rene Ao final dia, ento se faz de desenvolvimento, Em cada do ciclo chamado de a partir em levanta com do a equipeondeumaSPRINT ade uma lista priorizada, chamada com o que OWNER, desenvolvimento, requisitos reunio representante o cliente e decide, cliente RETROSPECTIVA, verifica o representante PRODUTO incremento no equipe ter produzido um visibilidade e 15lista de no do promover ser feito minutos momento na BACKLOG DOparacliente queREUNIO DE mais prioritrios requisitos, o pode melhorar no dessa funcionou bem e o que REVISO apresenta o para o cliente produto, queesignifica valorque foi feito no prximo ciclocomunicao de de desenvolvimento prximo ciclo desenvolvimento: o BACKLOG DA SPRINT
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

Papis

Papis no Scrum
ScrumMaster:
responsvel por garantir que o processo entendido e seguido

Product Owner:
responsvel 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

Papis no Scrum: O ScrumMaster

Garante a adeso do time aos valores do Scrum, prticas e regras Ajuda o Time de Scrum e a organizao 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 no gerencia o Time de Scrum: o Time de Scrum auto-organizvel

Papis no Scrum: O Product Owner

Gerencia a lista de requisitos (Backlog do Produto) atravs 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 viso do produto: estabelece, mantm e comunica Gerencia as entregas do produto para o cliente

sempre uma pessoa, e no um comit. Mas pode ser aconselhado/influenciado por outras pessoas
Suas decises devem ser respeitadas: ningum mais pode mudar as prioridades

Papis 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 entregveis em cada iterao So multidisciplinares: todo conhecimento necessrio para gerar o incremento No h ttulos no Time de Scrum

Gerenciam a iterao de desenvolvimento

So auto-organizveis: ningum diz ao Time de Scrum como transformar o Backlog do Produto em incrementos entregveis.

O Ciclo do Scrum

Backlog do Produto
O Product Owner levanta com o(s) cliente(s) os requisitos mais prioritrios naquele momento

REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

Backlog do Produto
O Product Owner insere estes O Product Owner levanta com o(s) requisitos no BACKLOG DO cliente(s) os requisitos mais prioritrios PRODUTO naquele momento

REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que o Backlog do Produto?

uma lista incompleta e dinmica dos requisitos do produto, ordenados por prioridade de desenvolvimento A prioridade determinada por: valor que gerar ao cliente naquele momento, risco e necessidade Contm funcionalidades, correes de bugs, tecnologias e melhorias que constituem a mudana que ser implementada no produto O Product Owner o responsvel 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 descrio e estimativa em pontos de esforo. Itens do alto da lista so de menor granularidade e mais detalhados

O que o Backlog do Produto?

uma lista incompleta e dinmica dos requisitos do produto, ordenados por prioridade de desenvolvimento A prioridade determinada por: valor que gerar ao cliente naquele momento, risco e necessidade Contm funcionalidades, correes de bugs, tecnologias e melhorias que constituem a mudana que ser implementada no produto O Product Owner o responsvel 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 descrio e estimativa em pontos de esforo. Itens do alto da lista so de menor granularidade e mais detalhados

Reunio de Planejamento da Sprint

O Time de Scrum ento se rene com o Product Owner e decide, a partir do Backlog do Produto, o que ser feito no prximo ciclo de desenvolvimento: o BACKLOG DA SPRINT
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que a Reunio de Planejamento da Sprint?

Planejamento da iterao:
Time de Scrum e Product Owner defininem que itens do Backlog do Produto sero implementados na Sprint e os quebram em tarefas - Backlog da Sprint

1a. Parte: O qu?

Escolha de itens mais prioritrios do Backlog do Produto a serem implementados Definio 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 sero desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas Os itens so selecionados do Backlog do Produto na Reunio 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 so atualizadas, tarefas podem surgir para os itens j existentes Deve ter alta visibilidade Pertence ao Time de Scrum

O que o Backlog da Sprint?

Composto por uma lista dos itens que sero desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas Os itens so selecionados do Backlog do Produto na Reunio 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 so atualizadas, tarefas podem surgir para os itens j existentes Deve ter alta visibilidade Pertence ao Time de Scrum

A Sprint
O Time de Scrum faz o trabalho no ciclo de desenvolvimento, a SPRINT

REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que a Sprint? (1/2)

Sprint a iterao (ciclo) de desenvolvimento
Reunio de Planejamento da Sprint Trabalho de Desenvolvimento Reviso e Retrospectiva da Sprint

Cada Sprint deve ter uma Meta Tem durao fixa (de 2 semanas a 1 ms) e ocorrem uma atrs da outra
Durao deve contemplar horizonte curto suficiente para que mudanas no alterem a Meta

ScrumMaster deve assegurar que no seja feita nenhuma mudana que afete a Meta da Sprint

O que a Sprint? (2/2)

Cada Sprint deve ter como sada um incremento do produto potencialmente entregvel 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 Reunio Diria
Em cada dia, o Time de Scrum faz uma reunio de 15 minutos para promover visibilidade e comunicao
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que a Reunio Diria?

Reunio de 15 minutos realizada todo dia no mesmo local, mesma hora.
Visibilidade Comunicao Deciso rpida

Cada membro do Time de Scrum detalha:

O que ele completou desde a ltima reunio diria; O que ele vai fazer antes da prxima reunio diria; Quais obstculos esto em seu caminho.

O ScrumMaster deve remover os obstculos encontrados

O grfico de BURNDOWN deve ser atualizado!

O que o Burndown da Sprint?

um grfico 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 direo ao final de um sprint feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint

O que o Burndown da Sprint?

um grfico 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 direo ao final de um sprint feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint

Incremento no Produto
Ao final da Sprint, o Time de Scrum ter produzido um incremento PRONTO no produto, que significa valor para o cliente
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

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 algum diz que algo est pronto, todos devem entender o que isso significa Ex. de software: codificado, testado e documentado

A Reunio de Reviso da Sprint

O Time de Scrum ento se rene com o Product Owner e apresenta o que foi feito na REUNIO DE REVISO DA SPRINT
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que a Reviso da Sprint?

Reunio 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 no foi feito na Sprint Deve prover entradas para a Reunio de Planejamento de Sprint seguinte

A Reunio de Retrospectiva
E, em seguida, o Time de Scrum se rene para a RETROSPECTIVA, onde verifica o que funcionou bem e o que pode melhorar na prxima Sprint
REUNIO DIRIA

24 HORAS
BACKLOG DO PRODUTO BACKLOG DA SPRINT INCREMENTO DO PRODUTO POTENCIALMENT ENTREGVEL

2-4 SEMANAS

O que a Retrospectiva da Sprint?

Reunio para inspecionar como correu a Sprint com relao s pessoas, relacionamentos, processos e ferramentas:
Product Owner no deve estar presente

Identificar e priorizar:
O que foi bem? O que pode melhorar?

Identificar aes para melhorias - adaptao

E o ciclo recomea...

BACKLOG DO PRODUTO

2-4 SEMANAS

Scrum
vs.

Mtodos Tradicionais

Desperdcio
Metodologias no-geis afirmam que devem ser gerados inmeros documentos para o sucesso do projeto
Diagrama de Estados Cronograma Detalhado Diagramas de Sequncia ...algo mais? Termo de Abertura Declarao Preliminar de Escopo Plano de Gerenciamento do Projeto Relatrio de Aceite Anlise de Earned Value

Relatrio de Desempenho Diagrama de Componentes

Pedidos de Mudana

Relatrio de Progresso

Relatrio de Encerramento Diagrama de Colaborao

Documento de Lies Aprendidas Diagrama de Casos de Uso

Diagrama de Atividades

Diagrama de Pacotes

Desperdcio
Metodologias no-geis afirmam que devem ser gerados inmeros documentos para o sucesso do projeto
Diagrama de Estados Cronograma Detalhado Diagramas de Sequncia ...algo mais? Declarao O de produo e Plano de manuteno Relatrio de Termo de Preliminar Aceite Abertura destes documentosGerenciamento compensa? de Escopo do Projeto Anlise de Relatrio de destes documentos se Quantos Pedidos de Relatrio de Earned Value Desempenho Mudana Progresso mantero ?

custo

atualizados

Quantos sero teis Diagrama desenvolvimento do projeto? de Diagrama de Diagrama

Atividades de Pacotes Colaborao

Diagrama de Componentes

Relatrio de Encerramento realmente

Documento de Lies para o Aprendidas Diagrama de Casos de Uso

Desperdcio
Em projetos tpicos, 50% do tempo gasto com requisitos, arquitetura e especificao
Anlise de Requisitos Especificao / Arquitetura Implementao Testes Manuteno

e isso tudo feito antes de se construir qualquer funcionalidade!

Fonte: Standish Group CHAOS Report

Desperdcio
Em projetos tpicos, 50% do tempo gasto com requisitos, arquitetura e especificao
Anlise de Requisitos Especificao / Arquitetura Implementao Testes Manuteno

e para piorar...

35% dos requisitos mudam 65% das funcionalidades nunca ou raramente sero utilizadas
Fonte: Standish Group CHAOS Report

Desperdcio
Com Scrum, o projeto deve ter somente a documentao suficiente e necessria. Ou seja, adote somente o que ser usado.

Afinal, o objetivo do projeto o produto, e no a documentao!

Desperdcio Scrum, o Product Backlog dinmico, pois ele deve sempre

Com acompanhar as necessidades do cliente, que mudam ao longo do projeto.

Sempre sero feitas as funcionalidades que so de maior importncia para o cliente no momento anterior ao incio de cada sprint.
Assim, o que for entregue, dever ser usado pelo cliente.

Maior Valor Primeiro

Em metodologias nogeis, o cliente s percebe retorno ao investimento no final do projeto.

Entrega

Maior Valor Primeiro

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 valor sejam entregues primeiro, gerando ROI para o cliente frequentemente.

Maior Valor Primeiro

A priorizao do Product Backlog pelo maior valor permite organizao:
entregar resultados para seu cliente mais

rpido que a concorrncia

colocar em produo funcionalidades que agregam maior valor a seu negcio mais rapidamente

lanar produtos e novas verses no mercado

mais rapidamente

Mudanas Frequentes
Como as metodologias tradicionais lidam com a mudana?
Mudana indesejada! Mudana arriscada! Mudana cara! Mudana deve ser negociada!

Como quase todo o planejamento feito no comeo do projeto, h pouqussimo espao para mudanas!

Mudanas Frequentes
Como as metodologias tradicionais lidam com a mudana?
O contrato com escopo amarrado deve nos defender! O cliente vai querer mudar tudo!

Cada mudana deve ser negociada com o cliente! Seu impacto deve ser quantificado!
Cada mudana deve ser revista, aprovada, planejada, documentada e gerenciada!

Mudanas Frequentes
Gerenciamento da mudana fonte de estresse em projetos que utilizam metodologias no-geis. Estresse no relacionamento de longo prazo com o cliente. Estresse no dia-a-dia da equipe de desenvolvimento.

Mudanas Frequentes
Como o Scrum lida com a mudana? Scrum encara a mudana como parte natural do processo de desenvolvimento Manifesto gil: responder s mudanas mais que seguir um plano

Mudanas Frequentes
Como o Scrum lida com a mudana? O Product Backlog constantemente atualizado pelo Product Owner... ...e assim, mudanas j podem ser introduzidas no produto na sprint seguinte! A resposta rpida mudana pode se transformar em vantagem competitiva!

Comunicao
Em um projeto waterfall, quando o cliente encorajado a participar?
Anlise de Requisitos Especificao / Arquitetura Implementao Testes Manuteno
Testes de Aceitao

O cliente percebe o projeto como uma grande caixa preta, cujo contedo ser revelado apenas no final do processo

Comunicao
Assim, projeto, final do resultado dificilmente atender s necessidades do cliente naquele momento! ao o

Comunicao
Como o Scrum lida com a comunicao?

O Product Owner est em frequente contato com o cliente para levantar suas necessidades... ...e assim manter o Product Backlog

constantemente atualizado e priorizado.

Comunicao
Como o Scrum lida com a comunicao?

O cliente recebe frequentemente novas verses...

...e assim pode mais rapidamente dar feedback para a equipe, via Product Owner.

Comunicao
Como o Scrum lida com a comunicao?

Desta forma, o cliente se sente envolvido em todo o processo...

...compartilhando com a equipe a responsabilidade sobre o projeto... ...aumentando seu grau de confiana na equipe e no processo.

Comunicao
A relao com o cliente deixa de ser meramente comercial, e passa a contemplar:
Parceria Cumplicidade Satisfao Fidelidade

E assim, cria-se uma relao de longo prazo com o cliente.

Comunicao
Em metodologias no-geis, como se promove a visibilidade no projeto para seus stakeholders?

Principalmente atravs de documentao...

...que d muito trabalho ...que no eficiente ...que no se mantm atualizada ...que acaba deixada de lado

Comunicao
No Scrum, a visibilidade no projeto constantemente promovida!
Reunies dirias Grficos de Burndown Kanban Entregas frequentes Equipe em um mesmo ambiente Reunio de Reviso Envolvimento do cliente Retrospectiva

...so alguns exemplos.

Comunicao
Manter comunicao 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 Disponvel:
Esta apresentao Guia do Scrum em Portugus 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 opo em tempos de crise

Material ficar disponvel para download durante a semana.

Obrigado!

Rafael Sabbagh
sabbagh@gmail.com

Marcos Garrido
mgarridobr@gmail.com