4 - Gestão Ágil de Projetos

Gerenciamento Ágil de Projetos com Scrum
Isabella Fonseca
2021
Gerenciamento Ágil de Projetos com Scrum
Isabella Fonseca
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.
Gerenciamento Ágil de Projetos com Scrum – Página 2 de 179

Sumário
Capítulo 1. Introdução ............................................................................................... 5
Capítulo 2. Fundamentos do Scrum - Introdução às Metodologias Ágeis ............... 13
Manifesto Ágil¹ ................................................................................................... 15
Os doze princípios da Agilidade¹ ....................................................................... 15
Gestão Ágil e Desenvolvimento Ágil ..................................................................... 16
Fundamentos do Scrum .................................................................................... 18
Desenvolvimento Iterativo e Incremental ........................................................... 19
Lean Manufactoring ........................................................................................... 21
The New New Product Development Game ...................................................... 26
Teoria do Caos .................................................................................................. 29
Teoria dos Jogos ............................................................................................... 30
Teoria das Restrições ........................................................................................ 32
Capítulo 3. Métodos e Frameworks Ágeis ............................................................... 38
Capítulo 4. Framework Scrum ................................................................................. 50
Teste seu conhecimento! Mudança de paradigma ............................................... 58
Teste seu conhecimento! Cultura da organização ................................................ 59
Teste seu conhecimento! Motivação no trabalho .................................................. 64
Regras e Fluxo de Atividades do Scrum: .............................................................. 64
Artefato: Product Backlog ..................................................................................... 64
Sprint Planning Meeting 1: ................................................................................. 79
Planning Poker...................................................................................................... 82
Sprint Planning Meeting 2 ..................................................................................... 83
Artefato: Impediment Backlog ............................................................................... 88
Checklist ............................................................................................................... 98

Resumo do Planejamento de um Projeto Scrum ................................................ 100
Capítulo 5. Estimativa e Priorização Ágil e Scrum DNA ........................................ 104
Estimativas x “Exatimativa” .............................................................................. 112
Técnicas de estimativas: ................................................................................. 114
Medidas de Tamanho Ágeis: ........................................................................... 115
Conceitos importantes para estimativas de software....................................... 121
3a Etapa de Priorização: .................................................................................. 130
Leitura Complementar ........................................................................................ 133
GRE – Gerência de Requisitos: ....................................................................... 137
DRE – Desenvolvimento de Requisitos: .......................................................... 138
PCP – Projeto e Construção de Produto: ........................................................ 138
Gestão 3.0 – Expansão do agile nas organizações ............................................ 162
Referências ............................................................................................................ 177

Capítulo 1. Introdução
No contexto econômico atual, com novos segmentos de mercado, novos

modelos de negócio, constantes e contínuas, mudanças, globalização,
interdependência, competidores ferozes e avanço tecnológico; um novo tipo de
gestão se faz necessário.
Vivemos no mundo VUCA! VUCA é uma sigla que representa as diversas

situações do nosso dia a dia através de substantivos como: volatilidade (Volatility);
incerteza (Uncertainty); complexidade (Complexity); e ambiguidade (Ambiguity). Esta
é a forma como as empresas se veem agora e também em seu futuro. É claro,
portanto, que impacta muito fortemente na maneira que agimos, pois o significado de
um evento/situação atual pode não ser facilmente compreendido. Por isso, faz todo o
sentido olhar esse novo mundo sob à luz de novos conceitos. As práticas atuais
permanecem como o modelo mental de como se comportar, e até parecem ser, à
primeira vista, a saída; mas não foram criadas para apoiar funcionários que pedem
por uma liderança inspiradora. Cronogramas e planos muito detalhados nos dão uma
ilusória segurança tão almejada para transpor estas barreiras e foram criadas em
tempos mais previsíveis e controláveis. Mas e o mundo VUCA? Ele veio pedir para
sairmos de nossa zona de conforto e nos preparar para adaptar rapidamente a este
contexto, aprendendo a partir dos erros e procurando insistentemente novas formas
de atuação, dando valor à colaboração, às pessoas e suas interações. Como disse
Rodrigo Bastos em seu artigo no Linkedin: "O mundo VUCA chegou e todos estão
tocando violino no deck do Titanic."
“Nós estamos saindo de um mundo linear de saber a solução dos

problemas e tomar uma decisão clara, para um mundo dinâmico de entender o
sentido, de tomada de decisão baseada no risco, em condições VUCA.”
Greg Hutchins.

Conceitos ligados à agilidade - métodos e abordagens ágeis - surgiram para
preencher muitos "gaps" nesse sentido, por se basear na experimentação, na
resolução rápida de problemas, na inovação, nas equipes multifuncionais, na
comunicação direta e transparente, colaboração e no trabalho real de equipe. Ao
trabalhar com ciclos curtos, todos podem perceber o impacto do que está sendo feito,
sejam os mais envolvidos, empresas, clientes, etc. Quando as pessoas estão abertas
ao que está acontecendo, os problemas são resolvidos e add novas formas de
atuação aparecem. Os clientes se surpreendem ao descobrir que uma demanda
antes tida como mais prioritária, não precisa ser entregue ou que mesmo que outra
nem previamente declarada já foi atendida. Isso pode ser conseguido através de
muita parceria, comunicação sem ruídos e muita colaboração - contrato “ganha-
ganha”.
O ágil acredita que a pressão dos pares fortalece o real trabalho em equipe,
exatamente por descortinar as deficiências de cada um à todos, e promover a busca
por solução imediata; seja por treinamento, coaching, técnicas como pair
programming, etc. Tudo isso sem esconder ou adiar problemas, resolvendo de vez a
situação para quem está necessitando de auxílio. Em outro tipo de filosofia, este
problema ficaria escondido por um tempo maior ou talvez nem apareceria.
E, este cenário gera, portanto, uma grande necessidade de trabalho em

equipe. Equipe em seu sentido mais verdadeiro: de time comprometido,
interdependente e movido por um objetivo compartilhado - PROPÓSITO! Com isso,
este time aprende a se antecipar e entender os pontos fortes de cada um, sabendo
onde pode contribuir ou ajudar a melhorar, desenvolvendo um conjunto de habilidades
e ferramentas para lidar de forma positiva com as mudanças inerentes ao nosso dia
a dia e saber tirar melhor proveito deste contexto.
Dessa forma, a valorização da capacidade de se trabalhar em equipe se torna

cada vez maior. Pois, muito além de bom conhecimento técnico, é importante
aprimorar em seus funcionários características como colaboração, confiança mútua,

transparência e coragem. Sem isso, eles podem comprometer a produtividade de uma
empresa, gerando até mesmo prejuízos.
Outro ponto primordial de ser analisado é o surgimento das novas empresas,

novos funcionários e sua relação. Novas empresas com empreendedores de
gerações mais atuais que, é claro, visam o mesmo objetivo de maximizar lucros (“de
forma bem direta”), mas que, em sua maioria, também são preocupadas em medir
seu sucesso pelo impacto que causam na sociedade. Isso pelo fato de que acreditam
que, futuramente, terão uma vantagem competitiva de longo prazo, uma vez que
outros fatores, além do financeiro, como o social e emocional, também são levados
em consideração: o chamado "Capitalismo Consciente”. Por outro lado, há
funcionários também da nova geração que buscam prazer no que fazem e
alinhamento com o que pensam. De novo, o potencial humano sendo destacado e
colocando as pessoas e suas interações como o grande fator fundamental para se
alcançar resultados.
Portanto, gerenciar pessoas e se preocupar com um ambiente saudável e

motivador deve ser algo a se buscar. Pois são as pessoas que fazem uma empresa,
e não o contrário, por mais que pensemos ser diferente. Os atributos mais poderosos
de uma empresa surgem das situações pelas quais ela passa, de seus atores e
interação. Não vem de uma declaração de missão ou visão, por exemplo.
É claro que, para que mudanças culturais ocorram, pede-se tempo. Certos
hábitos gerenciais mudam mais lentamente, apesar de sabermos que já não
funcionam tão bem diante de um mundo VUCA. Tendemos a nos apoiar em políticas
e estruturas que acreditamos que auxiliam neste movimento acelerado pelo qual
passamos. Por isso, ainda assim, as mudanças acontecerão e nos levarão a ter que
pensar e agir de forma diferente para sobreviver. Como diz Peter Drucker, “é inútil
tentar ignorar as mudanças e fingir que o amanhã será como ontem.”
Para se manterem competitivas, as empresas devem estar na fronteira da

inovação. Para isso, é necessário estimular momentos de ideação com trabalho em
equipe (equipe, de novo, no foco!). É preciso ter muitas ideias ruins para surgirem

algumas boas. A equipe surge, principalmente porque precisamos de muita
colaboração para que apareçam novas ideias construídas a partir de outras, para
solucionar os problemas atuais. E, como o fracasso faz parte desta jornada, é preciso
perseverar. E, para isso, a liderança deve aparecer para que cada ciclo de
experimentação sirva de aprendizado.
Por tudo isso, o caminho possível para atuação nesse cenário é ter a
capacidade de se adaptar, agir usando um mindset ágil e interagir constantemente
para disseminar informações, em busca de um ganho contínuo e acelerado de
conhecimento pelas pessoas que realizam um projeto.
O planejamento de projetos no ágil difere do planejamento tradicional, que

usualmente tem foco no plano, nas entradas (inputs) e converge na geração de
cronogramas para o controle do projeto. Conforme já discutido, torna-se difícil
elaborar planos de projeto que reflitam com precisão todos os passos a serem dados
até o fim do projeto. Diante disso, uma abordagem mais atual e comprometida com a
situação constitui-se em criar uma visão, uma lista de requisitos ("backlog") e em
oferecer visibilidade constante dos resultados do projeto conseguido, frente a
objetivos de curto prazo como as entregas de cada iteração (foco em suas saídas -
outputs).
Já o monitoramento de projetos ágeis, constitui-se em acompanhar o

alinhamento frequente com uma visão/objetivo previamente definidos, com a
execução/completude dos itens do backlog priorizados e entregues a cada iteração.
Dessa forma, o controle do projeto pode ser realizado sobre produtos funcionais
entregues.
Afinal, o que é ser ágil?
“Capacidade de prover respostas rápidas e flexíveis às mudanças.” (Craig Larman)
“Habilidade tanto de criar quanto de responder as mudanças de forma a obter

ganhos em um ambiente de negócios turbulento.” (Jim Highsmith)

Fonte: https://www.slideshare.net/AgileNZ/ahmed-sidky-icagile.
Doing Agile x Being Agile?
Qual a diferença? Executar o ágil (Doing Agile) tem mais relação com utilizar
técnicas e ferramentas ágeis. Muitas vezes isso pode trazer melhores resultados, mas
não garante a correta institucionalização de seus valores e princípios. A cultura pode
estar tão arraigada que não permite que seja alterada, mesmo que lentamente. Ela
nos puxa, como uma âncora, para utilizarmos ferramentas que tentam predizer muito
o futuro (algo sem fundamento neste mundo atual), ou nos faz praticar formas mais
atuais de gerenciamento, mas nos cobra da mesma forma. Ou seja, é uma forma
perigosa de atuação, pois a empresa considera que já está dançando conforme a
música, mas não permite verdadeiramente a mudança necessária. Ir da direita para
a esquerda (do Doing Agile para depois atingir o Being Agile) pode ser desanimador
e nos levar a achar que estamos no caminho errado, e nos fazer voltar ainda mais.
Já o ser/estar ágil (Being Agile) diz respeito a mudar um mindset, a forma que
fazemos as coisas e interagimos com os participantes de qualquer processo. Indo por

este caminho, as percepções desse novo mundo nos levam a buscar a mudança de
paradigma e a pensar diferente, o que posteriormente leva a nos comportarmos de
forma diferente. A partir de então, tudo começa a fazer mais sentido. A repetição de
bons comportamentos gera novos hábitos que multiplicados desenvolvem uma nova
cultura organizacional, mais saudável para a empresa e seus funcionários. Sem
contar o que consegue ser repassado aos clientes! Este caminho é o que traz maior
ganho - da esquerda para a direita. Abaixo o ciclo da mudança explicado acima:
Fonte: https://www.kaizen-coach.com/en/hr-lean/come.
Algumas atitudes "Being Agile” dizem respeito sobre:
▪ Ter o cliente sempre por perto (de verdade!).
▪ Envolver os stakeholders significa que ele irá validar frequentemente e não

somente ao final de iterações, por exemplo, ou mesmo ao final do projeto.
▪ Entender o que ele realmente quer para que a entrega de valor seja melhor
planejada e entregue o mais cedo possível.
▪ Ter entregas regulares e prontas para serem validadas. Não adianta entregar
um incremento com coisas “por fazer”.
▪ Obter feedback real constante e aprender com os erros.

▪ Fazer reuniões de retrospectivas que tenham ações concretas para a melhoria
contínua.
▪ Ter coragem de dizer sempre a verdade sobre:
– Cronogramas atrasados e irreais;
– Prazos não factíveis;
– Não ter conhecimento sobre algo que você tem que resolver e pedir
ajuda.
▪ Equipe realmente comprometida com o projeto e não somente com sua

reputação.
▪ Todos auxiliam em tudo. Entendem o objetivo e pensam no todo.
▪ Criar tarefas objetivas e pequenas para que sejam terminadas rapidamente

(melhor monitoramento, WIP baixo e feedback imediato).
▪ Focar nas tarefas a serem executadas. Não adianta achar que multitasking é
efetivo.
▪ Experimentar novas formas de fazer - inspecionar e adaptar.
▪ Alternar papéis, alterar documentos, reunião, fluxos, etc.
▪ Demonstrar algo pronto ao final de cada iteração, algo que possa ser usado.
▪ Todo mundo deve saber de tudo. A saturação da comunicação acelera o

trabalho.
▪ Fazer uma reunião por dia. Verificar o trabalho da equipe e ver o que pode ser
feito para aumentar a velocidade (e criar plano de ação para isso).
▪ Simplicidade: para ser ágil. É necessário simplificar processos, seja de

definição, de aprovação, etc.

▪ Reflexão frequente e adaptação: como a mudança é uma constante no mundo
digital, é importante refletir constantemente sobre os esforços, ajustando-os
quando necessário.
▪ Lembrar que sucesso de um projeto não é atender ao famoso triângulo

"escopo, prazo e custo", e sim atender aos objetivos do cliente.
▪ Mudar a forma como cada um enxerga o seu cliente, o negócio dele e a própria
capacidade real de entregar software de valor agregado.
Como disse Steve Denning, "Delighting Customers”.

Capítulo 2. Fundamentos do Scrum - Introdução às Metodologias Ágeis
Origem do pensamento ágil para o desenvolvimento de software
A história da indústria de software teve sua origem por volta de 1960. Antes
dessa época, o software era considerado parte integrante do hardware e não havia
nenhuma comercialização desse produto como componente distinto das máquinas.
Portanto, o hardware era comercializado juntamente com o software e o preço era
estabelecido sobre o conjunto da solução. Entretanto, em certo momento, ficou
evidente que o desenvolvimento de software envolvia custos, os quais se haviam
tornado tão dispendiosos quanto o investimento total no hardware e, em alguns casos,
chegavam a superar o valor. Esse aspecto foi decisivo para que se iniciasse um
movimento para a apropriação de um valor comercial ao software, desmembrando-o
do valor inerente ao hardware.
Diante deste cenário, a indústria de software se viu na necessidade de buscar

incessantemente melhorias e um maior número de acertos na construção de seus
produtos. Já na década de 70, ocorreu a primeira grande mudança neste sentido: a
Análise Estruturada. Tratava-se de uma análise a ser desenvolvida com foco em suas
funções: decomposição dos processos da organização em estudo para, daí, serem
derivadas as estruturas de dados necessárias para o estabelecimento do sincronismo
entre essas funções. A década de 80 foi o momento de foco nos dados, conhecida
como Engenharia da Informação e a Análise Essencial. Iniciou-se o processo de
análise do software, identificando-se o modelo conceitual de dados - modelo que
representa a visão dos usuários sobre as informações necessárias, que é

decomposto nos conjuntos de dados do software (utilizando-se uma técnica
conhecida como "normalização") e, a partir desses conjuntos de dados, são
implementadas as operações que se aplicam sobre eles. Na década de 90, a Análise
Orientada a Objetos prevaleceu.
A evolução do conjunto de todas estas técnicas permitiu uma melhoria na

qualidade intrínseca dos produtos de software. Além das técnicas de construção
citadas acima, ferramentas de projeto e programação, metodologias, processos,
dentre outros, contribuíram para um maior amadurecimento e crescimento da
indústria de software. Entretanto, problemas relacionados ao controle sobre os
projetos de software permaneceram. Desvios no cronograma, custos excedentes,
insatisfação quanto aos requisitos levantados e produto entregue ainda eram (e são!)
algumas das dificuldades apresentadas. Aliado a estes problemas, os softwares
necessários e construídos pelas organizações deixaram de ser departamentais. Para
suprir as demandas do mercado, as empresas passaram a ter que desenvolver
softwares capazes de comunicar com outras fontes de informação – diferentes das
fontes internas conhecidas. Ou seja, as organizações passaram a ter necessidade de
interagir através dos sistemas com fornecedores, clientes, parceiros, etc. Dessa
forma, a comunicação e entendimento do que realmente é preciso fazer e o que é
realmente executado, se tornou um grande “gap“ que ainda deveria ser preenchido.
Com a Internet, as coisas ficaram ainda mais complexas em função do aumento do
número de variáveis, o aumento do número de usuários acessando (e o
desconhecimento destes: quem são, como estão acessando, de linha discada ou não,
qual a configuração da máquina, versão de software, etc.).
Os métodos ágeis foram se fortalecendo, dirigindo para este sentido de

entendimento de uma nova forma de se construir software, e se tornou uma vertente
que está complementando e expandindo o conhecimento do que é software.
Em 2001, um grupo interessado em métodos iterativos e ágeis - estes termos

estavam, na verdade, sendo ainda cunhados no contexto do desenvolvimento de
software - se reuniram para encontrar um denominador comum. Este movimento

gerou a "Agile Alliance" (http://www.agilealliance.com), com um manifesto e a
declaração de alguns princípios. Muitas das práticas concretas existentes atualmente
no universo ágil derivaram destes princípios.
Manifesto Ágil¹
Apesar de reconhecer que há valor nos itens da direita, valorizamos mais os itens da
esquerda:
Indivíduos e interação entre eles mais do que processos e ferramentas;
Software em funcionamento mais do que documentação abrangente;
Colaboração com o cliente mais do que negociação de contratos;
Responder a mudanças mais do que seguir um plano.
¹ Versão traduzida obtida de: <http://www.manifestoagil.com.br/>.
Os doze princípios da Agilidade¹
✓ Nossa maior prioridade é satisfazer o cliente através da entrega adiantada e

contínua de software de valor.
✓ Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos

ágeis se adequam a mudanças para que o cliente possa tirar vantagens
competitivas.
✓ Entregar software funcionando com frequência, na escala de semanas até

meses, com preferência aos períodos mais curtos.
✓ Pessoas relacionadas a negócios e desenvolvedores, devem trabalhar em

conjunto e diariamente durante todo o curso do projeto.

✓ Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente
e suporte necessário, e confiar que farão o trabalho.
✓ O método mais eficiente e eficaz de transmitir informações para, e por dentro

de um time de desenvolvimento, é através de uma conversa cara a cara.
✓ Software funcionando é a principal medida de progresso.
✓ Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários devem ser capazes de manter conversação
pacífica continuamente.
✓ A contínua atenção à excelência técnica e bom design, aumenta a agilidade.
✓ Simplicidade: a arte de maximizar a quantidade de trabalho não feito, é

essencial.
✓ As melhores arquiteturas, requisitos e projetos emergem de times auto-

organizáveis.
✓ Em intervalos regulares, o time deve refletir em como se tornar mais efetivo,

então, se ajustar e otimizar seu comportamento de acordo.
¹ Versão traduzida obtida de: <http://www.manifestoagil.com.br/>.
Gestão Ágil e Desenvolvimento Ágil
De forma geral, os métodos de desenvolvimento ágil aplicam iterações de

tempo fixo para evoluir um produto de software em incrementos, um planejamento
adaptativo, entregas evolutivas e outras práticas e valores que encorajam a agilidade
- rapidez e flexibilidade em resposta à mudança.
Por que planejar não é uma tarefa fácil?

Porque planejamos para um mundo próximo ao mundo real e esperamos
seguir um plano que quase sempre não é cumprido. Podemos definir um “Projeto
como um empreendimento temporário com o objetivo de criar um produto ou serviço
único. Temporário significa que cada projeto tem um começo e um fim bem definidos.
Único significa que o produto ou serviço produzido é de alguma forma diferente de
todos os outros produtos ou serviços semelhantes.
Desta maneira, podemos afirmar que “uma idealização e a construção de uma

casa, um desenvolvimento de software, a escrita de um livro ou até mesmo o
planejamento da vida, são projetos”. Podemos dizer isso pois construir uma casa,
desenvolver um programa ou mesmo planejar nossas vidas, ainda que sigam passos
semelhantes entre os diversos planos existentes, têm peculiaridades que apenas com
o andar da “implementação” afloram.
Observando-se tais semelhanças, muitos dos gerentes de projetos têm criado

metodologias próprias, que tentam organizar o caos existente na maioria dos projetos
e tentam garantir o sucesso do projeto, fato que nem sempre é muito fácil de executar.
Um grande exemplo desta dificuldade é apresentado por uma recente pesquisa, que
indica que a maioria absoluta dos projetos falha. Conforme última análise feita pelo
grupo Chaos, 52,7% dos projetos futuros e que não forem cancelados, mas que forem
levados a cabo falharão e terão em média um custo de 189% acima do esperado.
Segundo PMI Brasil - Benchmarking em Gerenciamento de Projetos, 2006,

chapters do PMI no Brasil, os problemas mais frequentes em gerenciamento de
projetos levantados são:
✓ Não cumprimento de prazos (72%);
✓ Problemas de comunicação (71%);
✓ Mudança de escopo (69%);
✓ Estimativa errada de prazo (66%).

Além dos problemas citados acima, ocorrem também problemas não somente
com os projetos de software, mas também com produtos desenvolvidos. Segundo
pesquisa do Standish Group em 2002:
– 64% das funcionalidades entregues: nenhum ou quase nenhum uso.
– 20% das funcionalidades entregues: uso constante ou muito frequente.
Fonte: http://www.softhouse.se/.
Com isso, planos evolucionários trazem maior possibilidade de acerto quando

requisitos ainda não são conhecidos, as mudanças acontecem em grandes volumes
e onde ainda se tem alto grau de incertezas que vão se dissipando somente com o
tempo, e informações que são acumuladas. Planos evolucionários podem ser
implementáveis através de processos iterativos e incrementais.
Fundamentos do Scrum
Para que possamos entender os conceitos que embasam o Scrum, abaixo

seus principais fundamentos serão detalhados:

O primeiro fundamento a ser abordado será o Desenvolvimento Iterativo e
Incremental.
Desenvolvimento Iterativo e Incremental
Os termos "iterativo e incremental", cunhados no contexto das abordagens

ágeis para desenvolvimento de software, possuem atualmente uma ampla utilização,
porém nem sempre carregando o significado que realmente merecem.
Quando dizemos uma abordagem "iterativa", queremos dizer que o produto

construído mediante esta abordagem será feito de forma gradual, iniciando-se a partir
de uma ideia inicial, não acabada, recebendo novas avaliações e aprimoramentos até
que esteja em condições aceitáveis em termos de valor para o cliente. A figura abaixo
demonstra uma evolução iterativa, a partir de uma visão inicial.6
Quanto ao termo "incremental", significa a produção do produto final por meio

de incrementos, criando oportunidades de análise e adaptação do processo de
produção do produto a cada novo incremento. A figura a seguir demonstra uma
abordagem incremental para construção, a partir de uma referência inicial.

Iterativo e incremental referem-se, portanto, a uma abordagem em que o
produto é construído gradualmente, em ciclos que buscam o alinhamento de
prioridades e necessidades conforme a evolução do produto alcançada até o
momento, permitindo, ao mesmo tempo, uma revisão constante do processo
mediante qual está sendo construído este produto.
Dito isso, para tentar resolver problemas de planejamento, prover feedback

constante e entregas curtas, o movimento acerca do Desenvolvimento Iterativo e
Incremental (IID) cresceu. IID é um processo de desenvolvimento de software que
prevê planejamento em estágios desenvolvendo e entregando o produto em
incrementos de software funcionais, promovendo em tempos regulares previsões
para reflexão. Têm-se, com isso, Múltiplos PDCAs: Plan - Do – Check – Act. O ciclo
de Deming tem por princípio tornar mais claros e ágeis os processos envolvidos na
execução, focando em Melhoria Contínua. A relação deste processo com Scrum é
clara no sentido de ir ao encontro de que as iterações são primordiais ao melhor
entendimento do que é software citado anteriormente. Cada iteração precisa passar
por todas as fases necessárias ao desenvolvimento de software. Precisa passar por
análise, projeto, desenvolvimento, testes e entregas continuamente. No Scrum:
− Cada sprint é uma iteração que segue o ciclo PDCA e entrega incremento de
software pronto;
− Cada dia de um ciclo Scrum tem um PDCA menor – Daily Scrum (será
explicado mais tarde.);
− Scrum permite a criação de equipes auto-organizadas, encorajando a

comunicação verbal entre todos os membros da equipe e entre todas as

disciplinas que estão envolvidas no projeto, focando na maximização da
habilidade da equipe de responder de forma ágil aos desafios emergentes.
Têm-se como exemplos de utilização de IID, o RUP e também os métodos

ágeis.
Abaixo, o Cone da Incerteza se tornou uma ferramenta interessante, que

prevê construções iniciais sem comprometimento total com estimativas de esforço,
custo e prazo. Enquanto não se conhece verdadeiramente o escopo, a tecnologia e
o cliente, faz necessário ter algumas fases de experimentação e iteração real com o
cliente e com o fornecedor, é (pelo menos, deveria ser) o principal interessado no
sucesso do projeto. Passadas estas iterações iniciais, têm-se:
− Conhecimento melhor do escopo, do cliente, da tecnologia;
− Melhoria de previsão de custo/prazo com a experimentação.
Fonte: Craig Larman – Agile & Iterative Development
Lean Manufactoring
Outro fundamento do Scrum é o Lean Manufactoring. O lean é uma

abordagem derivada do Sistema Toyota de Produção.

Segundo Gary Convis, presidente da Toyota Motor Manufacturing Kentucky,
o papel do gerente em um ambiente próspero e saudável de trabalho é "moldar a
organização não pela força de ordenar, mas através de exemplo, através de instrução
e através do entendimento e auxílio aos demais para que atinjam suas metas”.
Para contar um pouco de história, no início do século XX a Teoria Clássica

da Administração ficou conhecida como Administração Científica. O fundador desta
escola foi Frederick Taylor (1903) com inúmeros seguidores, dentre eles Ford, Gantt
e Gilbreth.
Entre suas principais características, têm-se:
✓ Ênfase na estrutura organizacional. Acreditava-se que as organizações

seriam mais eficientes e mais eficazes se tivessem uma estrutura hierárquica
baseada numa autoridade formal legalizada.
✓ Trabalhadores devem realizar o mínimo possível. Pode ser encarado como

objetivo de processo, mas temos que nos lembrar de que somos pessoas
inteligentes (seres pensantes e adaptáveis).
✓ Trabalhadores não devem se preocupar com a qualidade. Possuía ênfase nas

tarefas, onde se procurava reduzir o desperdício e elevar o índice de
produtividade.
✓ Os administradores determinavam o modo mais eficiente de realizar tarefas

repetitivas, e utilizavam um sistema de incentivos salariais: salário era
proporcional à produção.
✓ Estabilidade x Substituição de pessoas.
Max Weber fundou a teoria da burocracia, onde buscava a eficiência máxima

através da padronização do desempenho humano - ao ponto de ser possível a
previsibilidade do comportamento das pessoas na organização; o homem visto como
uma máquina. Elevou enormemente o desempenho das indústrias em que atuou,

todavia, igualmente gerou demissões, insatisfação e estresse para seus
subordinados e sindicalistas.
Mas os primeiros problemas surgiram como a dificuldade de adaptação. A

Ford começou a enfrentar problemas quando a GM introduziu o conceito de
“variedade”.
“As críticas à teoria clássica dizem que ela era mais adequada no passado,
quando as organizações estavam num ambiente relativamente estável e previsível,
do que no presente, quando os ambientes são mais turbulentos”. (STONER, 1985:28)
Por último, aparece a Teoria Neoclássica, também conhecida como o "Novo

Movimento" das Relações Humanas, que faz uma tentativa de integrar a teoria
clássica com a teoria das relações humanas. Entre seus principais representantes se
encontram Deming, Tom Peters, Peter Drucker e William Ouchi. Em geral, propõem
que para uma melhor administração, a organização deve procurar satisfazer seus
funcionários, possuir um processo de tomada de decisões participativo, ter uma
organização flexível e buscar sempre se atualizar com novos conhecimentos.
Após a 2a Guerra Mundial, o Japão começou a estudar a fundo sobre

processos produtivos e contratou Demming. Deixando que seus trabalhadores
adaptassem o processo, permitiu-se a real evolução na criação do processo. Em
1973, com a crise do petróleo, a Toyota teve seu maior crescimento e este tipo de
teoria ficou latente! Com nível de inovação e qualidade impressionante até os dias de
hoje. O foco é aumentar a qualidade e a produtividade e, consequentemente, reduzir
os custos.
A desaceleração econômica atual também está afetando a maior fabricante

de carros do Japão, mas suas sólidas finanças e uma nova frota com modelos que
consomem menos combustível podem suavizar os danos. Eles buscam, através do
conhecimento de seus processos e de inovação, sair dessa crise.
Esta última teoria se aproxima mais do que metodologias ágeis possuem

como princípios.

Princípios do Lean Manufactoring:
• Adicionar somente valor:
1. Eliminar o desperdício - Eliminar do processo tudo que não traga valor ao

produto final.
2. Minimizar inventário (estoques) - O inventário no desenvolvimento de

software corresponde à documentação que não é parte do produto final.
Documentações de requisitos e design devem ser mantidas em níveis
mínimos para maximizar o fluxo de desenvolvimento.
3. Fazer corretamente na primeira vez (incorporar o feedback) - Assegurar

que cada componente possui qualidade a cada entrega. Parar a produção
até que um produto de qualidade seja entregue (evitar criar frentes com foco
em retrabalho).
• Centralizar naqueles que adicionam valor:
4. Ampliar o poder daqueles que adicionam valor (decidir no nível mais

baixo possível) - Oferecer a autoridade e as ferramentas necessárias para
as pessoas no "chão de fábrica" tomarem as decisões necessárias
5. Criar uma cultura de melhoria contínua - Adotar abordagens que

favoreçam a execução do ciclo PDCA (Plan, Do, Check, Action) no ambiente
do projeto de software e entre projetos.
• Obter valor dos clientes:
6. Ir em direção aos requisitos do cliente (agora e no futuro) - A abordagem

de levantar, reunir e demandar do cliente uma assinatura sobre seus requisitos
é considerada atualmente falha, porque, ao invés de fomentar a colaboração,
tende a criar um ambiente de conflito entre clientes e desenvolvedores. A forma
mais eficiente de ir em direção aos requisitos do cliente é a adoção de uma
abordagem iterativa e incremental.

7. Puxar da demanda (decidir o mais tardiamente possível) - Buscar a
previsão perfeita pode não ser o caminho correto. O foco, portanto, deve ser
em responder à mudança, e não em predizer todas as necessidades do
produto.
8. Maximizar o fluxo - Identificar e reduzir as frentes de WIP (Work In Progress

- Trabalho em Andamento). Se o WIP for reduzido, então o tempo necessário
para cada ciclo será também reduzido.
• Otimizar o fluxo de valor:
9. Abolir as otimizações locais - Otimizações locais podem criar sub-

otimizações no processo total e devem ser evitadas.
10. Forme parcerias com os fornecedores (use aquisições evolutivas) -

relações de confiança com um número limitado de fornecedores podem
promover grandes vantagens. Com a diminuição do conflito entre fornecedor
de software e cliente para controle do escopo, os esforços podem ser
canalizados para a produção do melhor software possível para o cliente.
➢ Para saber mais: http://www.poppendieck.com/
Sobre Lean e Scrum, ambos buscam atender os requisitos do cliente se

aproximando dele e criando uma atmosfera saudável - uma relação de confiança!
Ambos também:
✓ Fornecem a visão do todo e buscam utilizar o intelecto dos trabalhadores.
✓ Pensam através de imagens – Obeya e Agile Radiator, incentivando a

colaboração e criando fórum para encontrar e resolver problemas.
✓ Buscam aprimoração contínua.
✓ Buscam simplicidade – encontrar a solução certa para o problema com o

menor esforço e despesa.

The New New Product Development Game
O terceiro fundamento que deve ser apresentado é a grande contribuição do

artigo de Nonaka e Takeuchi - “The New New Product Development Game”. Foi
publicado em 1986 na Harvard Business Review. Este artigo estuda as práticas de
gestão que diferenciavam as empresas Fuji Film, Toyota, 3M e Xerox, Epson, Brother,
NEC e Honda, e identificam diferenças chave entre empresas japonesas e
americanas inovadoras que se apresentavam tão à frente das demais.
Fonte: Takeuchi and Nonaka (1986) - The overlapping of phases does away with
traditional notions about division of labor.
Sob movimento de sequência e revezamento, o projeto segue passo a passo

as diferentes fases, mudando para a fase seguinte somente depois que todas as
expectativas da fase anterior estejam totalmente satisfeitas. Checar todos os itens
controla os riscos, mas ao mesmo tempo deixa pouco espaço para integração. Um
tumulto durante o processo pode vir a desacelerar ou mesmo parar o
desenvolvimento de todo o processo.
Sob a aproximação holística ou rugby, as fases se sobrepõem

consideravelmente, o que propicia ao grupo absorver a vibração ou
“confusão” criadas durante todo o desenvolvimento do processo.
Quando acontece um tumulto, naturalmente todo o nível de confusão
aumenta.

O processo não chega a se desfazer, porque o grupo consegue
administrar e levar adiante. (NONAKA & TAKEUCHI, 1986)
O grande ganho nas abordagens B e C é a paralelização das atividades. Ela

acaba antes, pois construo enquanto planejo. Na velha forma (tipo A), o processo de
desenvolvimento do produto desenvolveu-se como em uma corrida de revezamento,
com um grupo de especialistas em cada função passando o bastão para o próximo
grupo.
O projeto passou sequencialmente de uma fase a outra: conceito em

desenvolvimento, teste de viabilidade, desenho do produto, processo de
desenvolvimento, produto piloto e produto final. Desta maneira, as funções foram
especializadas e segmentadas: pesquisadores de mercado avaliaram as
necessidades e percepções do cliente no conceito de desenvolvimento do produto.
Na abordagem em forma de rugby (jogo britânico tipo o futebol americano), o

processo de desenvolvimento do produto surge a partir de constante interação, como
que de mãos dadas, onde um grupo extremamente disciplinado trabalha junto do
início ao fim. Em vez de um movimento definido, altamente estruturado em suas
fases, o processo se inicia com a interação do grupo. Um grupo de engenheiros, por
exemplo, pode começar o desenho do produto (3ª fase) antes de todos os resultados
do teste de viabilidade (2ª fase) estarem completos – ou o grupo de engenheiros pode
ser forcado a reconsiderar a decisão, como resultado de informação tardia. O grupo
não para, mas empenha em experimentar a interatividade. Isso continua até a fase
mais adiantada do desenvolvimento do processo.
A mudança da aproximação linear (tipo A) para a integrada (tipos B e C)

encoraja tentativas e erros. Ela estimula novas maneiras de aprender e de pensar
dentro da organização em diferentes níveis e funções. Muito importante, essa
estratégia de desenvolvimento do produto pode agir como agente de troca em uma
grande organização.

Estudando as práticas de gestão que diferenciavam as empresas japonesas,
os seguintes fatores de sucesso comuns foram encontrados:
✓ Instabilidade Interna;
✓ Times auto-organizados;
✓ Fases de Desenvolvimento Sobrepostas;
✓ Multi-aprendizado (MultiNível e MultiFuncional);
✓ Controle Sutil;
✓ Transferência de Conhecimento Organizacional.
“Cada elemento deste, por si não traz velocidade e flexibilidade. Mas,

tomados como um todo, formam características que podem produzir um poderoso
conjunto de dinâmicas que fazem a diferença.” (NONAKA & TAKEUCHI, 1986)
Entre as similaridades encontradas por este artigo, que preza a Gestão de

Conhecimento e o Scrum, têm-se:
✓ Visão holística: ambos acreditam em proporcionar a visão do todo para os

envolvidos, em busca do comprometimento e colaboração geral;
✓ Auto-organização, superação e troca de ideias;
✓ Times multifuncionais;
✓ Controle que estabelece checkpoints para prevenir instabilidade, sem

prejudicar a criatividade;
✓ Treinamentos e passagem de conhecimento;
✓ Reflexão sobre lições aprendidas.

Teoria do Caos
O quarto fundamento do Scrum a ser estudado é a Teoria do Caos. Ela estuda

o funcionamento de sistemas complexos e dinâmicos.
Esta figura explicita que processos preditivos não são adequados para o
desenvolvimento de softwares complexos. Se já se conhece integralmente o escopo,
as tecnologias e tudo mais que está envolvido no projeto de desenvolvimento de
software, então provavelmente o Scrum não é necessário. No gráfico acima, a
interseção dos tipos de complexidade ligados aos requisitos e à tecnologia definem a
complexidade total do projeto. Adicionando-se a esta análise a dimensão de pessoas,
a complexidade dos projetos de software amplia-se ainda mais, reforçando a visão de
que, atualmente, a quase totalidade dos projetos de desenvolvimento de software
constitui-se em processos complexos.
Projetos de software se apresentam na condição de Complexo em 63%. A

maior parte dos projetos corporativos na atualidade cai nessa categoria. Essa
informação é baseada na evolução constante da tecnologia – ela se torna difícil de
acompanhar e sofre com o grande número de variáveis que a tornam incapaz de
conseguir criar planos mais precisos e factíveis de serem entregues com sucesso.
Além disso, os requisitos também estão sofrendo com a variabilidade. Requisitos
mudam a uma velocidade muito grande, tornando a previsão quase imutável de um
grande planejamento inicial; pouco favorável na construção de um software que irá
trazer reais vantagens competitivas.

Estando usualmente em um estado quase caótico, projetos de software são
mais bem gerenciados por Processos Empíricos e Iterativos. O Scrum é
recomendado, portanto, para projetos complexos de desenvolvimento de software. O
Scrum permite que emerja uma ordem em um ambiente caótico ao habilitar que o
time se auto-organize.
A determinação do grau de complexidade do projeto pode auxiliar na

identificação dos benefícios da adoção de uma abordagem de controle empírico,
como o Scrum.
Sobre a Teoria do Caos e Scrum, têm-se como similaridades:
✓ Admitindo a imprevisibilidade inerente no desenvolvimento de software

complexos, utilizar uma abordagem preditiva não garante a previsibilidade
desejada.
✓ Scrum aceita que requisitos mudam com frequência, e por isso devem possuir
forma de trabalho iterativa e incremental.
Teoria dos Jogos
O quinto fundamento do Scrum é a Teoria dos Jogos. Esta teoria estuda e

analisa o CAS (Complex Adaptive System).
CAS é um sistema formado por uma rede dinâmica de agentes (os

quais podem ser células, espécies, indivíduos, firmas, nações, etc.)
atuando em paralelo, agindo e reagindo constantemente ao que os
outros agentes estão fazendo. O controle de um CAS tende a ser
altamente disperso e descentralizado. Se há alguma coerência no
comportamento do sistema, ele emerge da competição e cooperação
dos agentes. O comportamento geral do sistema é resultado de um
grande número de decisões tomadas a cada momento por cada
indivíduo. (Fonte: Wikipédia)

Aplicações da Teoria dos Jogos tentam encontrar equilíbrio nestes jogos,
como o “equilíbrio de Nash” em que nenhum jogador pode melhorar a sua situação
dada a estratégia seguida pelo jogador adversário. Agilistas consideram projetos de
software como um CAS!
Como tipos de jogos, têm-se os jogos de soma zero e jogos soma diferente
de zero. No jogo de soma-zero, o benefício total para todos os jogadores, para cada
combinação de estratégias, sempre soma zero. Um jogador só lucra com base no
prejuízo de outro. A maioria dos jogos clássicos de tabuleiro é de soma zero.
Muitos dos jogos estudados pelos pesquisadores da teoria dos jogos são
jogos de soma diferente de zero, porque algumas saídas têm resultados combinados
maior ou menor que zero. Ou seja, o ganho de um dos jogadores não
necessariamente corresponde à perda dos outros.
O dilema do prisioneiro é um problema da teoria dos jogos, é um jogo de

soma não nula.
“Dois suspeitos, A e B, são presos pela polícia. A polícia tem provas

insuficientes para condená-los, mas, separando os prisioneiros, oferece a ambos o
mesmo acordo: se um dos prisioneiros, confessando, testemunhar contra o outro e
esse outro permanecer em silêncio, o que confessou sai livre enquanto o cúmplice
silencioso cumpre 10 anos de sentença. Se ambos ficarem em silêncio, a polícia só
pode condená-los a 6 meses de cadeia cada um. Se ambos traírem o comparsa, cada
um leva 5 anos de cadeia. Cada prisioneiro faz a sua decisão sem saber que decisão
o outro vai tomar. O que vai acontecer?
Este jogo possui solução do ponto de vista Ótimo de Pareto a estratégia:
− A e B negam.
Este jogo possui como Equilíbrios de Nash a estratégia:
− A e B delatam: neste caso, é o Equilíbrio dominante.

As técnicas de análise da teoria de jogos padrão podem levar cada jogador a
escolher trair o outro, mas curiosamente ambos os jogadores obteriam um resultado
melhor se colaborassem. Infelizmente, cada jogador é incentivado individualmente
para defraudar o outro, mesmo após lhe ter prometido colaborar. Este é o ponto chave
do dilema. (Fonte: Wikipédia.)
Como similaridades entre a Teoria dos Jogos e o Scrum, têm-se como

grandes valores:
✓ Confiança;
✓ Comprometimento;
✓ Real trabalho em equipe;
✓ Medida de produtividade da equipe e não individual;
✓ Pensamento coletivo, etc.
Teoria das Restrições
O sexto fundamento a ser estudado é a Teoria das Restrições (TOC). TOC é

uma filosofia global de gerenciamento empresarial para contínua otimização do
desempenho de uma organização, através de ações nos elementos que a restringem.
A analogia é comparar a empresa com uma corrente. Se tracionarmos uma

corrente, onde ela quebrará? No seu elo mais fraco, sua restrição. A restrição é que
define o ganho máximo. Se quisermos aumentar o desempenho do sistema,
precisamos explorá-la. Se aumentarmos a resistência de qualquer outro elo que não
o mais fraco, não estaremos melhorando o desempenho da corrente como um todo.
“Usando esse processo podemos enfocar nossos esforços nos poucos pontos
de um sistema que determinam seu desempenho (nas suas restrições), e assim
podemos melhorar significativamente no curto prazo.”

Eliyahu Goldratt – A Meta:
Há cinco passos no processo de otimização contínua:
1. Identificar a(s) restrição(ões) do sistema;
2. Decidir como explorar a(s) restrição(ões) do sistema;
3. Subordinar tudo o mais à decisão acima;
4. Elevar a(s) restrição(ões) do sistema;
5. Se em um passo anterior uma restrição for quebrada, volte ao passo 1.
Voltando esta teoria para a construção de software, têm-se quatro variáveis

de controle que requerem cuidado em qualquer projeto:
▪ Recursos:
– Pessoas;
– Infraestrutura.
▪ Tempo;
▪ Escopo;
▪ Qualidade.
Não é interessante estabelecer todas estas variáveis como prioritárias em um

projeto simultaneamente. Segundo David J. Anderson, em seu livro “Agile
Management for Software Engineering”, há diversos tipos de projetos dado o
tratamento que podemos dar às variáveis de controle citadas acima.

Projeto Urgente
Projeto Urgente – fixa-se que o prazo e preço e escopo podem ser variáveis.
É considerado um tipo de projeto factível, pois não fixa as três variáveis que
influenciam no resultado, como de sucesso em um projeto. É preciso acompanhar de
perto, como em qualquer projeto, mas permite-se a negociação de escopo e de preço.
Projeto Crítico
Projeto crítico caracteriza-se por ter escopo fixo e preço e prazo

variáveis. Também é considerado realístico, pois aceita-se negociar as duas variáveis
citadas, podendo recorrer à inclusão de mais recursos humanos e ferramentais na
busca pela entrega do projeto; além de possível extensão do prazo. Lembrando que
segundo a Lei de Fred Brook's, adicionar pessoas a um projeto atrasado o atrasa
ainda mais. Portanto, a pessoa "reserva" somente faz diferença positiva se inserida
no início do projeto. Cuidado!
Já projeto sem orçamento, o preço é a variável fixa e as demais variáveis.

Tendo como diretiva o valor do projeto de software, há com isso, a possível
negociação de prazo e escopo, tornando possível uma relação saudável entre
fornecedor e cliente.

Sem Orçamento
Já como exemplos de projetos arriscados, têm-se:
Urgente e Crítico Crítico Sem Orçamento
Urgente e crítico tem como princípio ter escopo e prazo fixos, tornando a
“mistura“ perigosa enquanto projetos críticos e sem orçamento possuem escopo e
preço fixos. Estes dois tipos de projetos permitem pouca flexibilidade de negociação
e obrigam que decisões tão importantes tenham que ser acordadas em momentos
não adequados para o fornecedor e tampouco para o cliente. É um tipo de contrato
“perde-perde“, onde nenhum dos envolvidos ganha sobre o outro. O fornecedor se vê
obrigado a incluir margens para garantir sua rentabilidade e o cliente perde ao pagar
mais caro, e ainda ter que amargar os insucessos presentes nas entregas prometidas.
O tipo de projeto ainda mais arriscado é o que fixa as três principais variáveis:
prazo, preço e escopo. Ele é conhecido como Marcha para a Morte. O poder de
negociação é muito fraco e ambos (cliente e fornecedor) acreditam – isso mesmo,
acreditam – que tudo seguirá exatamente conforme o planejado. Conforme já

estudado, analisado e comprovado, isso não tem sido a realidade nos projetos de
software em todo o mundo e, portanto, não pode se constituir como elemento base
na relação entre os principais interessados.
Marcha para a Morte
Similaridades de Scrum e TOC:
Scrum faz com que todos identifiquem os obstáculos e que tracem um plano
de ação para resolvê-lo. TOC faz o mesmo. TOC faz com que as pessoas saibam
que as mudanças não devem ser traumáticas – eles existem - e com isso, acredita
em melhoria contínua. Durante as reuniões que o framework de processo possui
(reuniões de planning, review diário e ao final da iteração e de retrospectivas), é
possibilitado a identificação dos obstáculos e então a proposição de ações para
resolução dos mesmos.
Além disso, TOC não leva em consideração somente a capacidade individual

(elo) e sim o todo. Visão holística e compartilhamento de objetivos e metas!
Os princípios de agilidade e o alinhamento em relação ao conceito do TOC

levam a um importante questionamento. Em projetos de software, por que não ter
como meta na negociação de contrato, a manipulação do escopo, priorização correta
das demandas e entrega de software de valor ao cliente?

Qualidade
Abordagem Tradicional
▪ Escopo fechado
▪ Define-se custo e prazo
Escopo
Por que não...
▪ Prazo definido
▪ Custo fixo, em função do prazo
▪ Manter os níveis de qualidade
▪ Manipular o escopo?

Capítulo 3. Métodos e Frameworks Ágeis
Muito se fala sobre ser assim. O ágil como um grande guarda-chuva de tudo
que está abaixo, inclusive o Lean.
Fonte: https://www.versionone.com/agile-101/agile-methodologies/.
Mas outros definem de outra forma. Definem o Lean e Agile como filosofias,
e os demais como algo abaixo deles.
É fato que atualmente o Scrum é o método ágil mais utilizado, segundo a

pesquisa State of Agile 2017:

Fonte: http://stateofagile.versionone.com/.
Sobre o Scrum, que será visto com maiores detalhes no capítulo 4, pode-se
dizer que é um framework ágil muito simples, pouco prescritivo; possui 13 regras e é
descrito em 16 páginas em seu Scrum Guide. Ele foi criado para ser bastante
extensível e ser utilizado para desenvolvimento de novos produtos, sejam de software
ou não.
Tem como valores a coragem, foco, sinceridade, respeito e

comprometimento.
E como pilares da implementação do controle empírico de processos:

Transparência: os aspectos do processo que afetam o resultado devem
estar visíveis àqueles que estão controlando o processo. Além de visíveis, devem ser
também precisos (verdadeiros), uma vez que não há espaço para o engano das
aparências no controle empírico de processos.
Inspeção: os vários aspectos do processo precisam ser frequentemente

inspecionados de forma que variações inaceitáveis no processo sejam detectadas.
Adaptação: se a inspeção detectar que um ou mais aspectos do processo

estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o
processo ou o material sendo processado precisam ser ajustados. O ajuste deve ser
feito o mais rápido possível, para evitar novos desvios.
O Scrum endereça a complexidade de projetos de desenvolvimento de

software através da implementação desses três pilares, em um conjunto de práticas
e regras simples.
"As equipes precisam conhecer o básico do Scrum. Como você cria e estima
um product backlog? Como você o transforma num sprint backlog? Como você
gerencia um gráfico burndown e calcula a velocidade de sua equipe? As equipes
precisam conhecer práticas básicas que ajudam equipes a irem além de apenas
tentativas de praticar o Scrum para executá-lo bem.
Desenvolvimento iterativo é fundamental no Manifesto Ágil – entregue

software funcionando cedo e com frequência. Depois de anos de retrospectivas com
centenas de equipes de Scrum, a Nokia desenvolveu alguns requisitos básicos para
o desenvolvimento iterativo:
▪ As iterações devem ter um tempo fixo com menos de seis semanas de

duração;
▪ Ao final da iteração, o código deve ser testado pelo CQ e funcionar

corretamente.” (Jeff Sutherland - Ph.D., Co-Criador do Scrum)

O melhor e o pior do Scrum é que você é forçado a adaptar o
processo para sua situação específica. Dados relativos à resultado de
um ano de experiências numa equipe de desenvolvimento de
aproximadamente 40 pessoas. A empresa estava em uma situação
difícil com tarefas levando mais tempo que o previsto, problemas de
qualidade severos, constantes incêndios, deadlines estourados, etc.
Após um ano, implementamos Scrum em todas as camadas da
empresa, tentamos diferentes tamanhos de equipes (3-12 pessoas),
diferentes tamanhos de sprint (2-6 semanas), diferentes formas de
definir “pronto”, diferentes formatos para os product backlog e de
sprint backlogs (Excel, Jira, cartões), diferentes estratégias de testes,
etc. Também fizemos experimentos com práticas de XP e como
combiná-los com Scrum. (Fonte: Livro: Scrum e XP Direto Das
Trincheiras - Henrik Kniberg)
Extreme Programming:
Extreme Programming (XP) é um método ágil de desenvolvimento de

software bastante conhecido. Lançado em 1999 por Kent Beck, ele enfatiza
colaboração, criação rápida e antecipada de software e novas práticas de
desenvolvimento. Está fundamentada em quatro valores: comunicação,
simplicidade, feedback e coragem. Na segunda edição do seu livro-base, Extreme
Programming Explained: Embrace Change, de 2005, Kent Beck adicionou um novo
valor, que sustenta todos os demais: o respeito.
O XP encara o desenvolvimento de software em uma ótima pragmática e, ao

mesmo tempo, voltada para o negócio. Isto se materializa na forte busca da satisfação
do cliente, seja antecipando entregas de software operacional e com qualidade, seja
respondendo de forma adaptativa a requisitos em mudança, mesmo em fases
avançadas do ciclo de vida do projeto.
A proposta do XP para melhoria de projetos de software parte dos valores já

mencionados:

✓ Comunicação - programadores comunicam sempre com seus clientes e
colegas de projeto.
✓ Simplicidade - o design do software é mantido simples e limpo.
✓ Feedback - o feedback é obtido a partir dos testes que são realizados já no

primeiro dia do desenvolvimento e das entregas feitas aos clientes o mais
rapidamente possível.
✓ Respeito - cada contribuição individual da equipe é valorizada e respeitada

como parte importante do sucesso da equipe.
✓ Coragem - programadores podem responder com coragem frente a requisitos

em mudança e aos desafios das tecnologias.
Fonte: http://www.extremeprogramming.org/.
Devido à sua forte aderência à simplicidade e ao foco em satisfazer as

necessidades reais do cliente, XP também é conhecido como a "arte de maximizar a
quantidade de software que não precisará ser feito". De fato, entender a real
necessidade do cliente e focar no desenvolvimento que atenderá aos seus objetivos,

permite que as energias sejam mais bem direcionadas e sejam evitadas várias fontes
de desperdício.
O diagrama abaixo apresenta as regras do XP funcionando conjuntamente:
Fonte: http://www.extremeprogramming.org/.
Principais práticas do XP:
✓ Releases pequenas e frequentes: O desenvolvimento é feito em iterações

semanais. No início da semana, desenvolvedores e cliente reúnem-se para
priorizar as funcionalidades. O cliente identifica prioridades e os

desenvolvedores as estimam. Como o escopo é reavaliado semanalmente, o
projeto é regido por um contrato de escopo negociável. Ao final de cada
semana, o cliente recebe novas funcionalidades, completamente testadas e
prontas para serem postas em produção. Além disso, ocorre a liberação de
pequenas versões funcionais do projeto, o que auxilia muito no processo de
aceitação por parte do cliente, que já pode testar uma parte do sistema que
está comprando.
✓ Utilização de metáforas para o sistema: Procura facilitar a comunicação com o

cliente se adaptando a realidade dele. Conceitos são alinhados através desta
técnica. É preciso traduzir as palavras do cliente para o significado que ele
espera dentro do projeto.
✓ Design simples: Tem como foco construir códigos fáceis de serem entendidos
e alterados. Significa manter o design simples desde o início e melhorá-lo
continuamente, ao invés de tentar deixá-lo perfeito desde o início e então
congelá-lo.
✓ Testes: Composto de testes construídos pelo cliente em conjunto de analistas

e testadores, para aceitar um determinado requisito do sistema. E TDD:
Primeiro crie os testes automatizados e depois crie o código para que os testes
funcionem. Esta abordagem é complexa no início, pois vai contra o processo
de desenvolvimento de muitos anos. Testes de regressão, por exemplo, são
essenciais para que a qualidade do projeto seja mantida -> Maior segurança
para se efetuar refatorações.
✓ Refactoring frequente: É um processo que permite a melhoria contínua da

programação, com o mínimo de introdução de erros e mantendo a
compatibilidade com o código já existente. Refatorar melhora a clareza do
código, divide-o em módulos mais coesos e de maior reaproveitamento,
evitando a duplicação de código-fonte -> maximização do reúso.

✓ Propriedade do código compartilhada: O código fonte não tem dono e ninguém
precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto
é fazer a equipe conhecer todas as partes do sistema.
✓ Programação em pares: A dupla é formada por um iniciante na

linguagem/negócio e outra pessoa funcionando como um instrutor. Como é
apenas um computador, o novato é que fica à frente fazendo a codificação, e
o instrutor acompanha ajudando a desenvolver suas habilidades (o contrário
também é interessante). Desta forma, o programa sempre é revisto por duas
pessoas, evitando e diminuindo assim a possibilidade de erros. Com isso,
busca-se sempre a evolução da equipe, melhorando a qualidade do código
fonte gerado.
✓ Integração contínua: Sempre que produzir uma nova funcionalidade, nunca

esperar uma semana para integrar à versão atual do sistema. Isso só aumenta
a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar
de forma contínua permite saber o status real da programação.
✓ Ritmo sustentável: Trabalhar com qualidade, buscando ter ritmo de trabalho

saudável, sem horas extras. Há uma busca constante de trabalho motivado.
Para isso, o ambiente de trabalho e a motivação da equipe devem estar
sempre em harmonia.
✓ Time trabalhando junto: A equipe de desenvolvimento é formada pelo cliente e

pela equipe de desenvolvimento. Comunicação!
✓ Padrões de codificação: A equipe de desenvolvimento precisa estabelecer

regras para programar e todos devem seguir estas regras.

➢ Para saber mais:
• Referência online bastante completa sobre XP:

http://www.extremeprogramming.org.
• Jogo online para aprimorar as competências da equipe em XP:

http://industriallogic.com/games/electronicexplanations.html.
XP + Scrum:
A maioria das práticas do Scrum são compatíveis com o XP. A reunião diária
(Daily Scrum Meeting) é um refinamento da "reunião em pé" do XP, usando perguntas
especiais. Segundo Craig Larman [3], a ideia da reunião em pé do XP foi obtida por

Kent Beck a partir do Scrum. Ambos recomendam um espaço comum para a equipe
do projeto. A prática do Scrum relativa à demonstração aos stakeholders ao final de
cada iteração, aplica os princípios de feedback e comunicação do XP. O Backlog de
produto no Scrum e as abordagens de rastreamento do avanço do projeto
correspondem a variações pequenas em relação às práticas do XP.
A duração típica de uma iteração no Scrum - 30 dias - não é compatível com

o XP, um contexto em que é muito longa.
É uma prática do Scrum que haja somente um representante do cliente - o

Product Owner - que, em última instância, é o responsável pelos requisitos e
prioridades. No caso do XP, há uma ênfase na colaboração com um grupo de clientes,
evitando a restrição a uma só pessoa. Ambas as abordagens possuem suas
vantagens: no Scrum, conflitos de requisitos e prioridades ficam na esfera de negócio
e devem ser sanados pelo Product Owner. Já o XP, trata esse conflito na esfera de
desenvolvimento, envolvendo mais a equipe para a solução deste tipo de conflito.
“Ambos Scrum e Extreme Programming (XP) pregam que a equipe complete

alguma parte palpável de trabalho, que seja entregável ao fim de cada iteração. Essas
iterações são pensadas para serem curtas e com espaço de tempo definido.” (Mike
Cohn)
Kanban:
É um processo de gerenciamento de projetos ou desenvolvimento de

software. Introduz mudanças no ciclo ao mapear fluxo de valor e utilizar WIP (Work in
Progress) - atividades em andamento -> algo novo só deve ser iniciado quando uma
peça é liberada, por exemplo. Esta prática traz previsibilidade de tempo em ciclos.
Abaixo, um exemplo de quadro de acompanhamento de atividades Kanban com os
valores WIP indicados em cada fase do desenvolvimento de software:

Encorajamento de melhoria contínua:
Diminuição de inventário em função do WIP e de parar para concentrar toda

a equipe na solução do problema, e desbloquear o item restaurando o fluxo. Com
isso, consegue atingir níveis altos de qualidade e queda de retrabalho.
Por ter também características de reuniões curtas, pode tomar decisões mais
tardiamente sobre a próxima atividade a ser trabalhada, utilizando o conceito de
sistemas pull - puxam o sistema a medida da capacidade da equipe, e não é
empurrado como em um cronograma comum -, priorizando trabalho novo na entrega
de trabalho existente. Após cada iteração e demonstração de software entregável,
pode ocorrer atualização de prioridade de execução. No Kanban, iterações de
duração fixa não são prescritas. Pode-se escolher quando planejar, melhorar o
processo e entregar. As atividades podem ter uma periodicidade regular ou por
demanda.
Transparência:
Através do quadro, expõe-se métricas de velocidade, gargalos, filas,

variabilidade e desperdício. Com isso, incentiva discussões sobre melhorias e as
equipes às promovem rapidamente nos processos. O quadro também modifica o
comportamento e incentiva maior colaboração no trabalho, promovendo consenso
entre trabalhadores e colaboradores.

Kanban + Scrum:
São ambos altamente adaptativos, sendo o Scrum mais prescritivo que

Kanban.
O Scrum traz mais restrições. Por exemplo:
✓ O Scrum prescreve o uso de iterações de duração fixa, enquanto o Kanban

não;
✓ O Scrum prevê equipes multifuncionais, não obrigatórias no Kanban;
✓ O Scrum prescreve a necessidade de três papéis – PO, Scrum Master e

Development Team, o Kanban não determina seu time.
O Kanban tem como únicas restrições: “Visualize Seu Fluxo de Trabalho” e

“Limite Suas Atividades em Andamento”.
O raciocínio comum tanto em Scrum quanto em Kanban é: menos é mais!

Então, na dúvida, comece com menos!

Capítulo 4. Framework Scrum
Fonte: news.bbc.co.uk/sport1/hi/rugby_union/7048733.stm.
O que é o Scrum?
Para entendermos o que é o Scrum, vamos iniciar abordando aquilo que ele
não é:
▪ Processo prescritivo (que determina o que fazer em cada circunstância).
▪ Abordagem determinística para gerenciamento que utiliza planos detalhados,

gráficos de Gantt e cronogramas.

▪ Processo de pensar e planejar detalhadamente o que realizar, passo a passo,
e depois executar o trabalho mecanicamente.
"O processo de desenvolvimento de software é inteiramente intelectual e

todos os produtos intermediários são representações marginais dos pensamentos
envolvidos."
O Scrum auxilia a controlar projetos de desenvolvimento de software, porém

isto não significa que o projeto irá exatamente como esperado, produzindo resultados
idênticos àqueles esperados; o Scrum controla o processo de desenvolvimento de
software para guiar o trabalho em direção ao resultado de maior valor possível.
Seguem abaixo alguns tópicos para nos auxiliar a entender o que o Scrum é:
▪ Abordagem iterativa e incremental para o gerenciamento de projetos de

software.
▪ Processo empírico para gerenciamento de projetos complexos nos quais é

impossível predizer tudo que irá ocorrer.
▪ Processo criado para ampliar a probabilidade de desenvolver software com

sucesso.
▪ Processo de gerenciamento de projetos de software que permite antecipar e

avaliar com maior precisão o retorno do investimento.
▪ Oferece um arcabouço (framework) e um conjunto de práticas que mantêm

tudo visível.
▪ Permite aos seus praticantes saber exatamente o que está acontecendo e

realizar ajustes locais para manter o projeto movendo na direção de seus
objetivos.
▪ Permite exercitar constantemente o bom-senso.

Controle de processos definidos x Controle empírico de processos
Quando os mecanismos a partir dos quais um processo se realiza, são

razoavelmente bem conhecidos, a abordagem típica é a adoção de uma modelagem
definida, ou seja, a adoção de um modelo que possa representar e direcionar as
ações ao longo do processo, aplicando-o a diversas operações, com resultados
similares.
Neste caso, por meio da aplicação deste processo definido, pode-se ampliar
a quantidade produzida, mantendo em um padrão aceitável a qualidade para o cliente,
alcançando o que é chamado de "commodity". Quando um produto se torna uma
commodity, seus atributos e o processo para a sua produção são conhecidos e a
diferenciação passa a ser a produção pelo menor preço.
No entanto, se a repetição de um mesmo processo gera produtos de

qualidade inaceitável, ou seja, não há uma definição de processo que garanta
resultados de qualidade ou as atividades intermediárias são complexas a ponto de
não permitirem um modelo de processo definido, então torna-se recomendável a
adoção do controle empírico do processo. A longo prazo, fazer os produtos bem-
sucedidos pela primeira vez usando o controle de processo empírico, acaba por ser
muito mais barato do que refazer produtos mal-sucedidos com o controle do processo
definido.
Isto significa que, apesar do controle empírico ser mais caro que o controle
de um processo definido, é mais barato utilizá-lo para garantir a convergência de

projetos complexos do que corrigir os produtos gerados a partir de um processo
definido, mas que não é capaz de assegurar a qualidade em termos de valor de
negócio adicionado ao cliente.
O esqueleto do Scrum:
O Scrum sustenta todas as suas práticas em um esqueleto de processo

iterativo e incremental.
Fonte: http://en.wikipedia.org/wiki/Scrum_(development).
O ciclo inferior (30 dias), representa uma iteração de atividades de

desenvolvimento, que ocorrem em sequência, tendo como saída um incremento de
produto. O ciclo superior (24 horas) representa a inspeção diária que ocorre durante
a iteração, na qual os membros da equipe se reúnem para inspecionar as atividades
e encaminhar as adaptações necessárias. O que direciona a iteração é uma lista de
requisitos. O ciclo é repetido até que o projeto não tenha mais fundos.
O processo se desenvolve da seguinte forma: no início da iteração, a equipe

revisa o que precisa ser feito. Em seguida, seleciona aquilo que considera um
incremento entregável de produto para constituir-se no objetivo da iteração. A equipe
então foca no trabalho para produção do objetivo acordado; durante a iteração não
há alteração de prazo ou de objetivo. Ao final da iteração, a equipe apresenta o
incremento de software produzido, para que possa ser avaliado pelas partes

interessadas do projeto e, se necessário, adaptações necessárias no projeto possam
ser realizadas.
A produtividade do Scrum reside no processo criativo que se realiza dentro

de cada iteração. A equipe é responsável por organizar-se em torno do objetivo da
iteração, analisando questões tecnológicas, arquiteturais e de requisitos, conforme as
competências e habilidades de seus membros.
Papéis do Scrum
Há somente três papéis no Scrum: o Product Owner, a Equipe (ou Time) e o

Scrum Master. Todas as responsabilidades de gerenciamento estão divididas entre
esses três papéis.
O Scrum faz uma clara distinção entre os que estão efetivamente

comprometidos com o projeto-os que desempenham os três papéis descritos - e os
que estão interessados ou possuem algum envolvimento. Os que são responsáveis
devem possuir a autoridade para realizar o que for necessário para o sucesso do
projeto, enquanto os que não são responsáveis não podem interferir
desnecessariamente.
É importante notar que os papéis do Scrum são responsabilidades no

processo de desenvolvimento de software, e não posições na organização.
O Scrum é estruturado para regularmente tornar o estado do projeto visível

para os três gerentes: o Product Owner, o Scrum Master e o Time, de forma que estes

possam rapidamente ajustar o projeto para que atinja da melhor forma possível os
objetivos.
O quadro abaixo auxilia no entendimento de como o gerenciamento está

dividido entre cada papel no Scrum:
Product Owner Scrum Master Time
Gerenciamento Macro Facilitação Gerenciamento Micro

(negócio) (execução)
O Scrum Master:
O Scrum Master é o "gerente de projeto" que lidera o projeto Scrum. Provê

liderança, instrução e orientação. É o responsável por ensinar os demais como utilizar
o processo Scrum para lidar com as dificuldades encontradas durante o projeto. Em
Scrum, o termo "gerente de projeto" não é utilizado.
O Scrum Master é o responsável por assegurar que todos os envolvidos no

projeto sigam as regras do Scrum. Se as regras não são seguidas, as pessoas
perdem tempo pensando o que precisam fazer. Se as regras são debatidas em todo
momento, o tempo é perdido enquanto todos aguardam por uma resolução.

Se alguém quiser alterar as regras de trabalho da Equipe, deve utilizar a
reunião de análise retrospectiva da Sprint, momento específico para este tipo de
discussão. Mudanças nas regras devem surgir da equipe, não do gerenciamento.
Nenhuma regra deve ser modificada enquanto o Scrum Master não entender
que a equipe possui o entendimento, experiência e profundidade necessários para
realizar alterações de valor nas regras.
A tabela a seguir apresenta algumas diferenças entre o papel tradicional do

gerente de projetos e o papel do Scrum Master:
Gerente de Projetos Tradicional Scrum Master
Responsável por planejar, monitorar e Responsável por gerenciar o processo do

controlar o trabalho do projeto. Scrum (fazer o Scrum funcionar); para isso,
precisa de um entendimento profundo da
filosofia fundamental do Scrum.
É o responsável pelo sucesso do É o responsável pelo sucesso do projeto,

projeto, com autoridade direta. com autoridade indireta.
Geralmente é premiado pelo sucesso Não é premiado pelo sucesso do projeto,

do projeto. pois é apenas um facilitador.
Atribui atividades e controla sua Possui como responsabilidade mais alta

conclusão. assegurar o bem-estar da equipe e fazer tudo
que estiver ao seu alcance para que o Time
seja produtivo.
Gerencia. Lidera.

"Eu comparo o Scrum Master com um cão-pastor que faria tudo para proteger
o seu rebanho." [1] O Time deve perceber que há alguém fortemente empenhado em
protegê-lo e auxiliá-lo em tudo que for preciso.
As responsabilidades do Scrum Master podem ser sumarizadas nos

seguintes itens:
▪ Remover as barreiras entre o desenvolvimento e o Product Owner, de forma

que este possa direcionar diretamente o desenvolvimento.
▪ Ensinar o Product Owner como maximizar o ROI e atingir seus objetivos

através do Scrum.
▪ Melhorar a vida do time de desenvolvimento, facilitando a criatividade e a

delegação de poder.
▪ Ampliar a produtividade do time de desenvolvimento de todas as formas

possíveis.
▪ Aprimorar as práticas de engenharia e ferramentas de forma que cada

incremento de funcionalidade seja potencialmente entregável.

▪ Manter informação sobre o progresso do time visível e atualizada para todas
as partes.
Não é papel do Scrum Master gerenciar o Time; ele tem que se autogerenciar
para poder constantemente ajustar seus métodos e maximizar as chances de
sucesso.
Teste seu conhecimento! Mudança de paradigma
O Scrum Master de uma equipe de TI percorre o ambiente de trabalho da

equipe para realizar a reunião diária (Daily Scrum). Nesse processo, ele faz as
perguntas previstas nas regras do Scrum para cada membro da equipe:
▪ O que você fez neste projeto desde a última reunião diária?
▪ O que você planeja realizar neste projeto entre hoje e a próxima reunião diária?
▪ Que impedimentos existem para que você atinja seus compromissos para esta
Sprint e para o projeto?
As pessoas vão respondendo, enquanto o Scrum Master atualiza o status das

atividades.
Marque a alternativa correta a respeito da atividade desse Scrum Master:
a) Está seguindo as regras previstas para o Daily Scrum ao colocar para a

equipe as três perguntas e atuar como um facilitador.
b) Não está aplicando o Scrum.
c) Está equivocado, pois não deveria participar da Daily Scrum.
d) Está aplicando corretamente as práticas e regras do Scrum, mas deveria

dar maior independência ao Time.

O Scrum Master não entendeu a mudança de paradigma prevista no Scrum,
que o leva de controlador a facilitador, de chefe a orientador, e com isso falha em
aplicar o princípio da auto-organização e do autogerenciamento do Time. Resposta:
(b).
Teste seu conhecimento! Cultura da organização
O Scrum Master de uma equipe percebe, em uma reunião diária (Daily

Scrum), que há um grande impedimento para a conclusão do objetivo da Sprint atual.
Este impedimento corresponde a uma ordem direta da alta liderança da empresa, que
criou um evento de confraternização de toda a empresa, exigindo a presença de
todos, mesmo estando ciente de que isto impactaria os objetivos da Sprint atual.
O Scrum Master sai em defesa do time e dos objetivos da Sprint, batendo de

frente com a liderança da empresa, expondo seus argumentos e o impacto deste
evento para a Sprint e gerando conflitos.
Sobre a postura do Scrum Master:
a) Estava errada, pois no intuito de cumprir o papel do Scrum Master, feriu

os princípios e a cultura da organização.
b) Estava errada, pois, não é papel do Scrum Master argumentar com a alta
liderança da empresa, uma vez que é um facilitador.
c) Estava correta, pois atuou conforme suas responsabilidades e defendeu

o time e os objetivos da Sprint.
d) Estava correta, pois o Scrum deve ser aplicado por toda a organização
para que possa trazer os resultados esperados.
É papel do Scrum Master proteger o time de impedimentos durante a Sprint,

mas este deve operar em conformidade com a cultura e os valores da organização.

O Scrum é a arte do possível. O Scrum Master trabalha em uma linha tênue entre a
necessidade da organização de realizar mudanças assim que possível, e sua limitada
tolerância a mudanças. Em alguns casos, o Scrum Master deve aceitar restrições da
empresa em relação às mudanças trazidas pelo Scrum para que possa continuar seu
papel de fomentar essas mudanças gradualmente. Resposta: (a).
O Product Owner:
Em uma análise retrospectiva na história do desenvolvimento de sistemas, na

medida em que a complexidade das aplicações e tecnologias foi ampliando-se, mais
e mais as equipes de desenvolvimento foram distanciando-se das partes interessadas
no sistema que estava sendo produzido. Entre estas duas entidades foram
adicionados documentos, modelos, diagramas e, ainda, uma abordagem sequencial
que determinava que o cliente deveria aceitar toda a descrição dos requisitos antes
do início da implementação.
O Product Owner é o responsável por representar todos os interesses

daqueles envolvidos com o projeto ou com o sistema que será produzido por meio
deste. É responsabilidade do Product Owner obter a verba do projeto por meio da
criação dos requisitos gerais do sistema, os objetivos de retorno do sistema (ROI) e
os planos de entrega. O foco do Product Owner é o retorno do investimento (ROI).
A lista de requisitos é denominada Product Backlog. O Product Owner é

responsável por utilizar o Product Backlog para assegurar que as funcionalidades de

maior valor para o negócio são produzidas primeiro. Isso se realiza por meio do
sequenciamento adequado do Product Backlog para a próxima iteração.
O Product Owner deve concentrar-se em priorizar aquelas funcionalidades

que endereçarão os problemas de negócio mais críticos, bem como alavancar e
viabilizar o desenvolvimento de releases de funcionalidades cujo benefício ultrapassa
o custo do desenvolvimento. O papel do Product Owner é muito importante no fluxo
do Scrum, porque sua atuação adequada e focada permite a construção de um elo
forte com o negócio, na forma de resultados entregues rapidamente e comprovação
antecipada do retorno do investimento.
Faz parte do papel do Product Owner manter um contato frequente com o

cliente, com os stakeholders do projeto e também com o time. O fluxo de atividades
do Scrum garante que isto acontece pelo menos uma vez a cada Sprint, ou seja,
tipicamente uma vez a cada 30 dias. Em alguns casos, o Product Owner, em função
de restrições da cultura organizacional, por exemplo, pode ter dificuldades em
consolidar um backlog com os requisitos do produto e passá-lo para a equipe de
desenvolvimento durante o planejamento da Sprint; ainda assim, deve atuar como um
facilitador e fomentador da colaboração entre clientes e equipes de desenvolvimento,
de forma que as prioridades possam ser acordadas e o trabalho organizado para que
metas de curto prazo sejam atacadas pela equipe, em uma direção que trará a maior
satisfação possível dos clientes.
A entrega de incrementos de produto executável periodicamente a cada

Sprint, cria e amplia gradativamente uma credibilidade em torno da figura do Product
Owner, contribuindo para que clientes confiem no direcionamento do
desenvolvimento para as prioridades assinaladas por eles.
Além de projetos de software:
Não é incomum encontrar atualmente usuários do Scrum fora do ambiente de

desenvolvimento de software. Muitas vezes, sua abordagem de gestão empírica e
direcionada por fatos é utilizada no desenvolvimento de produtos de engenharia,

campanhas de marketing ou outras inusitadas aplicações. Nestes casos, o Product
Owner também tem a responsabilidade de consolidar um Backlog de produto que
represente claramente quais são as prioridades; o que precisa ser feito primeiro, como
meta de curto prazo e sem perder de vista uma visão alto nível do todo.
As práticas do Scrum permitem que o Product Owner e a equipe falem uma

mesma linguagem, que se entendam e consolidem um denominador comum, que é o
Product Backlog. O Scrum Master deve apoiar para que o time seja capaz de
conversar em linguagem de negócio, de forma a favorecer o entendimento com o
Product Owner.
O Time Scrum (Development Team):
De forma reversa ao observado nas práticas gerenciais tradicionais, o Scrum

faz com que o próprio time seja o responsável por gerenciar as atividades de
desenvolvimento.
A equipe, ou o time, é responsável por desenvolver as funcionalidades do

sistema. No Scrum, as equipes são autogerenciáveis, auto-organizáveis e compostas
de pessoas com diferentes níveis de habilidades e competências, trabalhando juntas
em direção a uma meta comum. É responsabilidade da equipe identificar como
transformar o Product Backlog em incrementos de funcionalidade em uma iteração, e
gerenciar o próprio trabalho para alcançar este objetivo.
A equipe é coletivamente responsável pelo sucesso de cada iteração e,

consecutivamente, do projeto como um todo.
Um aspecto novo do Scrum e, a princípio, não muito intuitivo, é que a equipe

é responsável por realizar o próprio gerenciamento. Utilizando a analogia dos "porcos"
(pessoas comprometidas) e das "galinhas" (pessoas envolvidas), todos os três papéis
do Scrum relacionam-se nesta analogia aos porcos, porque estão integralmente
comprometidos com o sucesso do projeto. Outras partes interessadas no projeto são
galinhas, e não possuem autoridade direta sobre a execução do projeto.

Por que a auto-organização e o autogerenciamento propostos pelo Scrum
funcionam? Parte da fundamentação para esta abordagem reside em algumas teorias
a respeito da motivação humana, conforme o quadro a seguir:
Teoria X e Y de McGregor Teoria de Herzberg
McGregor acreditava que todos os - Fatores Higiênicos: fatores higiênicos

trabalhadores se enquadravam em pobres podem destruir a motivação, mas
um dos grupos: X e Y. melhorá-los, na maioria dos casos, não irá
aumentar a motivação. Os fatores
- Teoria X: Gerentes que aceitam esta
higiênicos não são suficientes para motivar
teoria acreditam que as pessoas
as pessoas. Exemplos: condições de
precisam ser observadas a todo
trabalho, salário, vida pessoal,
minuto.
relacionamentos no trabalho, segurança e
- Teoria Y: Gerentes que aceitam esta status.

teoria acreditam que as pessoas
- Fatores Motivacionais: o que motiva as
querem trabalhar sem supervisão e
pessoas é o trabalho propriamente dito,
querem realizar. As pessoas podem
incluindo coisas como: responsabilidade,
direcionar seus próprios esforços.
autorealização, crescimento profissional e
reconhecimento.
O Scrum demanda e, ao mesmo tempo, convida fortemente a uma postura

ativa, interessada e participativa de todos os membros da equipe. Não pode haver
nada mais decepcionante para um membro do time do que sustentar-se em uma
reunião diária (Daily Scrum) em que não fez nada desde a última reunião e que não
sabe o que fazer, ou não está envolvido com o projeto.
Quando um time usa o Scrum, ele possui o poder para encontrar as próprias
formas de superar as situações complexas do projeto. Esta liberdade, somada à
criatividade que resulta dela, é um dos benefícios centrais do Scrum.

A habilidade do time em atacar e resolver os problemas é a alma do Scrum,
e a base para o aumento da produtividade da equipe com o Scrum. Não há ninguém
para delegar tarefas e falar para cada um o que fazer - nesse momento começa a
funcionar o time autogerenciável!
Teste seu conhecimento! Motivação no trabalho
Ken Schwaber, um dos fundadores do Scrum, afirma que "a transição de um

time que é gerenciado para um time que se autogerencia é difícil, mas o retorno em
produtividade e prazer ao trabalhar é impressionante." Você concorda com esta
visão? Reflita sobre os fatores motivacionais que podem promover esta mudança
Regras e Fluxo de Atividades do Scrum:
Artefato: Product Backlog
O Product Backlog é uma lista priorizada de requisitos funcionais e não

funcionais do projeto, com tempos estimados para transformá-los em funcionalidade
do sistema. As estimativas são em dias e devem ser mais precisas para os itens mais
altos, em termos de prioridade. A lista evolui, modificando-se na medida em que as
condições de negócio ou a tecnologia mudam.

"O Product Backlog é o coração do Scrum. É como tudo se inicia. O Product
Backlog é basicamente uma lista priorizada de requisitos, ou histórias, ou
funcionalidades ou qualquer outra coisa. Coisas que o cliente quer, descritas usando
a terminologia do cliente."
O Product Backlog pode ser composto de requisitos funcionais, requisitos não

funcionais e problemas, priorizados em ordem de importância para o negócio e
dependências e então estimados. A precisão da estimativa depende da prioridade e
granularidade do item, sendo que os itens de mais alta prioridade, que podem ser
selecionados para a próxima Sprint, têm estimativa bem granular e precisa.
O Product Backlog deve conter, além dos requisitos do produto, também os

requisitos do projeto, tais como a realização de auditorias da qualidade, preparação
de ambiente de produção, etc. Segue abaixo um exemplo de backlog de produto.
Requisitos Dados
Área Item Importância Est. Inicial Release Sprint
1 Interfaces Prova de conceito do 10 2 1 1

sistema de mensageria
2 Administração Controle de usuários, 9 3 1 1

permissões e auditoria
3 Produção Visualizar programação da 9 5 1 1

produção
4 Produção Executar etapa de 8 8 1 2

produção

5 Estoque Alterar posição de material 7 5 1 2
no estoque
Estimativas Iniciais do Product Backlog:
Abaixo, um detalhamento no conceito de Product Backlog:
Onde Product Backlog é uma pilha de requisitos contendo demandas de

todos os stakeholders:
✓ É mantida pelo Product Owner, que deve avaliar sugestões para o produto por
parte de qualquer stakeholder.
✓ Deve estar ordenada do mais importante para o menos, com base em seu valor
para o negócio da empresa, estipulado pelo PO em "Business Value" (BV) e
por seu tamanho.
✓ É atualizada continuamente, devendo os itens de Product Backlog estar tão

detalhados quanto mais prioritários estiverem na lista.

Release Backlog:
Trata-se apenas de um nome distinto para uma seleção de itens de Product

Backlog feita para uma Release. Não consiste em uma nova pilha.
É o escopo do projeto!
Selected Backlog:
Trata-se apenas de um nome distinto para uma seleção de itens de

Release/Product Backlog feita para um Sprint. Não consiste em uma nova pilha.
Sprint Backlog:
Pilha de tarefas (atividades), definida pelo time e para o time a partir dos itens
de Selected Backlog, contendo detalhamento em 2-3 itens de Sprint Backlog do que
deve ser feito em um Sprint. Esta atividade é primariamente feita durante o Sprint
Planning Meeting 2, sendo revisada diariamente durante o Daily Scrum.
✓ É utilizada para o Sprint Burndow Chart e não deve ser utilizada para
gerenciamento externo (realizado por resultados).
✓ Unidade em HH Previsto (Tamanho x Velocidade Atual).
O Sprint Backlog é uma lista de tarefas que define o trabalho da Equipe para
uma Sprint. A lista emerge durante o Sprint, sendo que uma primeira compilação é
gerada na segunda parte da reunião de planejamento da Sprint. É responsabilidade
da Equipe gerar e manter atualizado o Sprint Backlog. Cada tarefa identifica o
responsável por executar o trabalho e o esforço remanescente para concluir a tarefa
em um dia específico durante a Sprint. Tipicamente, uma tarefa possui estimativa
entre 4 e 16 horas, e tarefas com estimativa maior significa que ainda não foram
suficientemente detalhadas.
Existem várias maneiras práticas de se trabalhar com um Sprint Backlog,

desde planilhas Excel à sistemas de gestão baseados em Scrum. Um mecanismo

bastante simples e difundido, no entanto, é a utilização de um quadro de tarefas,
conhecido também como Agile Radiator, conforme exemplo abaixo.
Durante o projeto, itens a serem trabalhados nos Sprints devem estar melhor
definidos e possuir maior prioridade em relação aos demais. O desenho abaixo
confirma a granularidade maior do que itens do Product Backlog devem ter quando
estão planejados para serem executados durante o Sprint. Quando estão planejados
em uma próxima release, podem ter uma granularidade menor e em releases futuras,
menores ainda.
A priorização dos itens de um Product Backlog deve seguir premissas

estratégicas definidas pela organização, levando em consideração aspectos relativos
a custo, dificuldade de implementação (conhecimento da tecnologia), risco, ROI (valor
na entrega ao cliente), etc.

Exceto nos contextos em que um detalhamento arquitetônico e funcional mais
profundo é necessário para se chegar em estimativas com grau de precisão maior -
como é o caso, por exemplo, de propostas para RFPs de contratos de custo e prazo
fixos - em Scrum dedica-se um esforço moderado para as estimativas iniciais; dado
que, devido à natureza complexa do projeto, existe grande chance de um esforço para
detalhamento maior ser desperdiçado, pois mudanças sutis nas variáveis do
problema podem promover grandes alterações na forma de endereçá-lo e,
consequentemente, nas estimativas geradas inicialmente. Lembre-se do conceito
discutido acima – Cone da Incerteza.
No entanto, deve haver clareza e alinhamento entre o Product Owner, o Time

e o Scrum Master acerca do que realmente está contemplado por esta estimativa
inicial: todos os testes unitários, de integração, desempenho, etc., estão
contemplados? Está previsto esforço para desenvolvimento de testes automatizados
e refactoring do código? Este alinhamento é chamado conceito de pronto, e será
muito importante ao longo de todo o ciclo do Scrum.
Eventualmente, pode ser necessário mais uma iteração para percorrer

novamente os requisitos e refinar um pouco mais a estimativa, assegurando que a
base de avaliação das mesmas está entendida e é compartilhada por todos.
O planejamento do projeto deve evoluir conforme são vencidas as barreiras

iniciais do projeto. Após a primeira Sprint, o planejamento pode ser ajustado para

considerar com maior precisão a velocidade da equipe nas tecnologias envolvidas,
nas questões ambientais da empresa, etc. Isso permitirá ajustes como a alteração da
equipe, a revisão do escopo ou outras iniciativas que possam favorecer que o projeto
atinja as expectativas das partes interessadas.
Além das categorizações citadas acima – Product Backlog, Release Backlog,

Selected Backlog e Sprint Backlog - o Scrum também utiliza outros conceitos que
demonstram a granularidade de cada item. Quando sua descrição está no nível de
funcionalidade já suficientemente pronta para ser implementada, utilizando como
base a perspectiva do usuário, é chamado simplesmente de item do Product Backlog,
ou User Story. Para criar uma coleção de itens e agrupar os correlatos, pode-se criar
temas. Além disso, itens de granularidade menor (menos detalhado) e não prontos
para serem implementados, recebem o nome de Épicos.
Fonte: http://www.mountaingoatsoftware.com/.
Em Scrum, o planejamento é a forma de sincronizar as expectativas dos

stakeholders com as expectativas do Time. Em relação a cada parte envolvida, o
planejamento cumpre os seguintes objetivos:
Junto aos patrocinadores do projeto: detalhar que benefícios serão gerados e que
recursos serão necessários para a realização do projeto. O planejamento deve prover
detalhe suficiente para satisfazer os patrocinadores que o projeto é consistente, que
vai realizar determinadas entregas em determinados momentos, que os benefícios

serão superiores aos custos e aos riscos e que as pessoas que executarão o projeto
estão suficientemente capacitadas para executar este plano.
Junto aos futuros usuários do sistema sendo produzido: organizar o trabalho de

maneira que possam usufruir das funcionalidades que começarão a ser entregues.
O planejamento no Scrum difere do planejamento tradicional, que usualmente

converge na geração de um cronograma e planos para controle do projeto.
Assumindo um grau de complexidade alto, torna-se difícil elaborar planos de projeto
que reflitam com precisão todos os passos a serem dados até o fim do projeto; uma
abordagem mais eficiente, portanto, constitui-se em criar uma visão, uma lista de
requisitos ("backlog") do produto e oferecer visibilidade constante dos resultados do
projeto conseguidos frente a objetivos de curto prazo: as entregas de cada Sprint.
Dessa forma, o controle e direcionamento do projeto pode ser realizado sobre
produtos reais entregues, de forma a guiar o projeto para a obtenção dos melhores
resultados possíveis.
Os dois elementos essenciais (e mínimos) do planejamento de um projeto

Scrum, portanto, são:
✓ Visão - descreve por que o projeto está sendo empreendido e qual o estado
desejado ao final do mesmo.
✓ Product Backlog - define os requisitos funcionais e não-funcionais

necessários ao produto para que este atinja a visão desejada. Estes requisitos
são dispostos no backlog do produto de forma priorizada e dimensionada.
Portanto, um projeto Scrum ou Release se inicia com a visão do sistema a

ser desenvolvido. Provavelmente, esta visão será inicialmente vaga e descrita em
termos de necessidades de mercado ao invés de requisitos de sistemas, porém ficará
mais clara na medida em que o projeto avançar.
O planejamento não precisa ser plenamente completo para que se inicie o

trabalho em um projeto Scrum. No entanto, ele tem que ser adequado o suficiente

para prover os ciclos de inspeção e adaptação característicos do empirismo do
Scrum. Possuir informações de custo/benefício sobre os itens do backlog, por
exemplo, pode proporcionar que as adaptações do planejamento ao longo do projeto
sejam conduzidas de maneira mais consciente.
Processo básico do Scrum:
Abaixo, desenho que exemplifica o processo básico do Scrum que tem como
fases Pre-Game, Mid-Game e Post-Game.
No Pre-Game é executado o planejamento da Release e seus Sprints. O

Product Owner, através de seu trabalho contínuo, mantém sempre
priorizado/ordenado seu Product Backlog. Além disso, como uma de suas principais
atribuições, ele conhece os anseios e necessidades de seus clientes. Ele então
conhece o escopo desejado e pode planejar o cronograma macro da release. Para
isso, neste momento, o Product Owner deve fazer uma estimativa inicial de tamanho
de todos os itens previamente selecionados na pilha do Product Backlog (pode pedir
auxílio de especialistas), para verificar a viabilidade de entrega diante do prazo
planejado e também levar em consideração a velocidade da equipe a ser alocada. A
disponibilidade de recursos da equipe é levada em consideração para estruturar uma
distribuição dos itens do backlog nas Sprints, até que todo o backlog - conforme sua
situação no início do projeto - seja contemplado em Sprints e releases. Em função da
estimativa inicial ser necessária, a atividade de desenho em alto-nível também faz
parte desta fase.
O Product Owner também deve estabelecer o Release Goal durante o Pre-

Game, para que o objetivo maior da Release seja conhecido, comunicado, validado
e conhecido por todos os envolvidos. Portanto, determina a meta sobre o escopo da
Release e orienta o time na condução e entrega correta de maior retorno de valor.
Deve estar coerente aos itens de backlog da release – Release Backlog - e deve ser
comunicado durante a reunião de Release Planning.

Em uma Release Scrum, também há planejamento/acompanhamento de
todas as variáveis que compõem um projeto tido como convencional. Ou seja, o
Product Owner deve revisar aspectos relativos:
✓ Recursos Humanos: habilidades atuais da equipe x escopo planejado - prever

treinamentos formais, compra de livros, coaching, etc. Além disso, verificar
disponibilidade real da equipe (% de dedicação) e considerar que podemos ter
impedimentos durante a Release, retrabalhos, participação em reuniões,
dentre outras atividades que não nos permite trabalhar 8 horas diárias
dedicadas exclusivamente para o projeto.
IMPORTANTE: O Product Owner deve conhecer a velocidade de sua equipe –

como, por exemplo, número de Ideal Days (medida de tamanho a ser explicada
posteriormente) entregues por Sprint para conseguir validar a viabilidade de
comprometimento com o escopo planejado da Release.
✓ Recursos de infraestrutura: software e hardware necessário x escopo

planejado – verificar se é necessário adquirir algo dado o escopo definido.
✓ Cronograma Macro da Release: definição do número de Sprints necessários

para entrega do escopo (sem a obrigatoriedade de prévia alocação dos itens
do Product Backlog dentro de cada Sprint).
✓ Riscos da Release: em projetos Scrum, a equipe envolvida está diariamente

mitigando riscos, uma vez que realiza reuniões diárias de acompanhamento
levantando impedimentos existentes e validando (até mesmo visualmente
através de quadros de acompanhamento, chamado Agile Radiator) o
andamento planejado x realizado.
IMPORTANTE: Riscos x Impedimentos. Riscos são um conjunto de eventos que

podem ocorrer (sendo então necessário planejar, priorizar, definir plano de ação, etc.)

influenciando o objetivo do projeto, negativamente ou positivamente. Já
impedimentos formam um conjunto de eventos que JÁ ocorreram e serão
comunicados durante as reuniões diárias e que devem ser resolvidos pelo Scrum
Master o mais rapidamente possível, pois impedem o avanço do Sprint e
consequentemente da Release.
Impedimentos recorrentes poderão ser um indicativo de alteração de

prioridade (aumentando sua probabilidade ou impacto) de um risco já levantado, ou
até mesmo a criação de um novo risco não planejado inicialmente. Ele deverá ser
incorporado a Release, informando o tipo de ação adequada: mitigar, evitar, transferir
ou aceitar, além da ação que deverá ser executada caso ele ocorra – ação de
contingência.
Na reunião de Release Review, ocorre a demonstração do Development

Team do trabalho todo realizado e os backlogs planejados na fase de Post-Game.
Abaixo o exemplo do esqueleto de uma Release Scrum com a organização

cronológica de suas reuniões. Uma release tem como marcos naturais as reuniões
de:
– Release Planning – PLANEJAMENTO;
– Release Review – REVISÃO.

Além disso, é composta de N Sprints, que tem como marcos naturais as
reuniões de:
– Sprint Planning 1 e 2 – PLANEJAMENTO;
– Sprint Review e Retrospective Meeting – REVISÃO.
A release possui uma reunião de planejamento inicial, chamada Release

Planning e execução de três Sprints. Para cada Sprint, há uma reunião de
planejamento – Sprint Planning 1 e 2 e de fechamento – Sprint Review e
Retrospective Meeting. Além disso, ao final da Release, tem-se o fechamento da
Release através da reunião de Release Review e de Retrospective Meeting para
construção final da base de conhecimento do projeto em questão, consolidando as
lições aprendidas que surgiram durante o projeto. Todas as reuniões citadas acima
serão detalhadas nas seções seguintes.
Ainda no exemplo abaixo, foi sugerido Sprints sobrepostos da área de

Controle de Qualidade para testes ao final de cada Sprint, e também um Sprint final
de QA (Quality Assurance) para empacotamento da entrega da Release. Por isso, as
reuniões de Retrospective Meeting 2 na metade de cada Sprint, servem para
averiguação das funcionalidades desenvolvidas no Sprint anterior.

Fonte: http://www.powerlogic.com.br.
A abordagem acima pode funcionar de forma diferente para cada um,

restando reflexões e testes que se fazem necessários quando se utiliza um
framework. O Scrum prega a experimentação nestes casos, a fim de verificar a
adequação diante do contexto em que a organização se apresenta.
O trabalho do Product Owner (PO) é realizado em conjunto com o trabalho

do Development Team, e também com o do Controle de Qualidade (QC) – ver figura
abaixo simulando engrenagens que funcionam simultaneamente. O PO trabalha
continuamente visando a priorização dos itens de Product Backlog e entrega de maior
retorno ao cliente. O Development Team em entregar as funcionalidades planejadas
e o QC em verificar e comunicar qualquer inconsistência encontrada. Durante o sprint,

diversos PDCAs (Plan, Do, Control e Action) ocorrem para os diferentes papéis
envolvidos no processo de desenvolvimento.
Abaixo, temos um exemplo de sobreposição dos trabalhos dos três papéis

envolvidos (PO, Development Team e QC) ocorrendo durante os Sprints.
Pre-Game Mid-Game Post-Game
PO - Pre-Sprint PO - Pre-Sprint 2 PO - Pre-Sprint

1 3
ST - Sprint 1 ST – Sprint 2
QC – Pos-print
1
Mid-Game – antes do primeiro Sprint (este trabalho pode ser feito também no
Pre-Game):
✓ PO - Pré-Sprint 1: trabalho do PO planejando/detalhando os itens de backlog

do Sprint 1.

✓ O Development Team (ST) e Controle de Qualidade (QC) não estão
trabalhando neste momento para a Release em questão.
Mid-Game – Primeiro Sprint:
✓ PO – Pre-Sprint 2: Trabalho do PO – fazendo o Pre-Sprint do Sprint 2.
✓ ST – Sprint 1: O Development Team (ST) está atuando no Sprint 1.
✓ Controle de Qualidade (QC) não estão trabalhando neste momento para a

Release em questão.
Mid-Game – Segundo Sprint:
✓ PO – Pre-Sprint 3: Trabalho do PO – fazendo o Pre-Sprint do Sprint 3 ou

fazendo trabalho de Pre-Game do próximo Release.
✓ ST – Sprint 2: O Development Team (ST) está atuando no Sprint 2.
✓ QC – Post-Sprint1: Controle de Qualidade (QC) testando o Sprint 1. Para

experimentação: durante o Post-Game, o QC pode fazer testes do Sprint 2.
Release Planning:
Reunião onde o Product Owner apresenta para a Alta Gestão sua proposta
preliminar para uma Release e obtém alinhamento. Posteriormente, deve agendar
uma reunião com a equipe (conhecida também como kick-off do projeto), para
apresentar o Plano de Projeto – equipe envolvida, treinamentos necessários, número
de Sprints – cronograma macro, escopo, Release Goal, riscos, etc.

Abaixo, uma figura com as reuniões que compõem um Sprint:
Fonte: http://en.wikipedia.org/wiki/Scrum_(development).
Sprint Planning Meeting 1:
Reunião dedicada ao planejamento da Sprint, limitada a 8 horas de duração,

sendo estas divididas em duas partes de até 4 horas cada: a primeira parte é dedicada
à seleção dos itens do backlog do produto, que o time irá se comprometer a entregar
na Sprint, enquanto a segunda parte é dedicada à criação do Sprint Backlog. A
primeira é conhecida como Sprint Planning 1 e a segunda como Sprint Planning 2.
Características principais:
✓ Realizada todo início de Sprint, com duração de 4 (quatro) horas.
✓ Participação do Product Owner (PO), Scrum Master (SM) e Development

Team. Alguns stakeholders podem ser convidados, mas devem atuar como
"galinhas”.
✓ Passagem de entendimento sobre cada item do Selected Backlog pré-

selecionado do PO para o Development Team.
✓ O Development Team realiza a estimativa inicial de tamanho, para o cada item

do Selected Backlog.

✓ O PO estabelece o Sprint Goal.
IMPORTANTE: O Sprint Goal é uma meta "visionária" do Sprint estabelecido pelo

Product Owner ao final da reunião de Sprint Planning 1. É sempre verificado durante
a reunião de Sprint Review, confrontado com a demonstração do Development Team
e os itens de backlog (Selected Backlog) planejados e comprometidos.
A reunião de planejamento poderá ter uma duração menor, desde que isto
seja acordado entre Product Owner, Development Team e Scrum Master, e se
mantenha o limite acordado em todas as reuniões. A aplicação do conceito de etapas
delimitadas por tempo ("time-boxed") é muito importante no Scrum.
Nesta reunião, devem participar o Scrum Master, o Product Owner e o time.

Outras pessoas podem ser convidadas pontualmente, caso possam contribuir com
algum detalhe tecnológico ou do domínio de aplicação correspondente.
O Product Backlog deve estar preparado antes da reunião. Esta preparação

é muito importante para o correto desenvolvimento da reunião. Apesar do Scrum não
determinar detalhadamente o que significa esta preparação (define apenas que deve
ser uma lista de requisitos priorizada e estimada em alto nível), normalmente
considera-se um backlog pronto quando:
✓ Os requisitos funcionais e não-funcionais foram organizados na forma de uma

lista.
✓ A lista foi priorizada em virtude do retorno ao negócio (ROI).
✓ Os itens prioritários da lista (os candidatos a serem endereçados na próxima

Sprint) foram descritos na forma de Estórias (*).

✓ As Estórias foram detalhadas até o nível de "teste de aceitação", ou seja, uma
descrição um pouco mais detalhada do que se espera da funcionalidade, de
forma que esta possa ser validada ao final.
(*) Uma Estória é uma descrição textual de um requisito, que deve responder
às seguintes perguntas:
✓ Por quem - perfil de usuário de maior interesse na funcionalidade;
✓ O quê - descrição da funcionalidade esperada;
✓ Por quê - justificativa de negócio da funcionalidade.
Na ausência do Product Owner, o Scrum Master deve se responsabilizar pelo

preparo do backlog e pelo papel de Product Owner durante a reunião – prática não
recomendada e não deve ocorrer de forma recorrente.
O Time pode fazer sugestões, mas a decisão final sobre os itens do Backlog
a integrarem a Sprint é do Product Owner.
A reunião de planejamento da Sprint, na perspectiva do time, é o momento

em que começa o exercício de ser autogerenciável e auto-organizável, pois ninguém
chegará com uma lista de tarefas a serem delegadas para a equipe. As estimativas
iniciais dos requisitos no backlog do produto são revistas, ao serem abordados os
detalhes de cada um com o Product Owner. A técnica de estimativa mais popular que
pode ser utilizada durante esta reunião é conhecida como Planning Poker, explicada
a seguir.

Planning Poker
O "Planning Poker" é uma técnica de estimativa baseada em consenso,

criada a partir de um método denominado "Wideband Delphi", e que é utilizada para
estimar o tamanho de requisitos em projetos de software. Este método vem sendo
bastante utilizado, principalmente entre a comunidade ágil, como uma ferramenta
importante para a produção de estimativas acordadas entre os membros da equipe,
em um tempo significativamente reduzido, se comparado a discussões livres acerca
do esforço de cada requisito.
O Planning Poker não é parte integrante do Scrum, porém frequentemente é

utilizado durante as reuniões de planejamento da Sprint, para que a equipe elabore
uma estimativa mais detalhada dos itens do backlog do produto de forma a identificar
quais requisitos será capaz de entregar durante a Sprint. O grande benefício do
Planning Poker é que todos os participantes têm que expressar simultaneamente sua
estimativa de tamanho para determinado requisito, evitando que a opinião da maioria
se ancore a partir da opinião dos primeiros a se manifestar.

➢ Para saber mais: http://en.wikipedia.org/wiki/Planning_poker
http://www.planningpoker.com/
Saídas da reunião de planejamento da Sprint:
✓ Uma meta para a Sprint – Sprint Goal.
✓ Uma lista dos membros do time comprometidos.
✓ O Sprint Backlog.
✓ Uma data definida para a demonstração da Sprint (Sprint Review Meeting).
✓ Um horário e local definido para a reunião diária (Daily Scrum).
Sprint Planning Meeting 2
É realizada após o Sprint Planning 1, tem duração de quatro horas, sem a

participação do Product Owner e stakeholders. Tem como características principais:
✓ Auto-organização: planejamento do Development Team para seu próprio

trabalho: ele refina a análise de cada item do Selected Backlog, criando a lista
de Sprint Backlog – tarefas que irão implementar cada item.
✓ O time finaliza a estimativa iniciada no Sprint Planning 1. A estimativa pode ser

reavaliada durante a reunião (as discussões técnicas podem gerar alterações),
reportando ao Product Owner qualquer ajuste necessário.
✓ O Agile Radiator deve então retratar o Sprint corrente.

Artefato: Agile Radiator
É um quadro de acompanhamento de atividades tipicamente dentro de um

sprint – com atividades não iniciadas (previstas), atividades em andamento e
atividades concluídas. Um Agile Radiator auxilia no monitoramento de um projeto real.
Eles garantem visibilidade do projeto a todos os envolvidos. Não há como mascarar
o real andamento.
O quadro é atualizado diariamente durante as reuniões de Daily Scrum. É

neste quadro também onde os impedimentos devem ser anexados, além dos itens de
lições aprendidas como WWW e WCBI.
Não existe uma única forma de organizar este quadro, mas tipicamente tem-
se: uma coluna para incluir os itens planejados para a Sprint, mas ainda não iniciados;
outra para os itens em andamento; e outra para os itens concluídos. É comum,
também, a indicação em uma área separada dos itens que não estavam previstos,
mas que tiveram que ser endereçados durante a Sprint.
O goal fica afixado e os requisitos – através de Post-its - (Selected backlogs)

e seus desdobramentos (Sprint backlogs), são posicionados na situação onde se
encontram. Eles devem ser posicionados de acordo com a prioridade dos mesmos –
Business Value declarado pelo Product Owner. Post-its localizados no topo nos dizem
ser de maior prioridade que os posicionados no rodapé do quadro branco.

Fonte: Livro: Scrum e XP Direto Das Trincheiras - Henrik Kniberg
Exemplo de Agile Radiator:

Sprint:
Uma Sprint é uma janela de tempo definida, na qual o time cumprirá um objetivo
determinado ao seu início, entregando um incremento de produto que possa ser
apresentado e avaliado ao final deste período.
Considerando que as organizações e as pessoas possuem recursos

limitados, é sempre importante identificar as prioridades de forma a canalizar para
elas o foco de atenção dos recursos disponíveis. A Sprint, como janela de tempo
relativamente curta e com objetivos determinados, possui a virtude de criar um
contexto de canalização de energias para os itens selecionados como prioritários a
partir do Backlog do Produto.
As primeiras Sprints geralmente concentram um volume maior de atividades

de arquitetura e infraestrutura do sistema.
Incremento de Funcionalidade de Produto Potencialmente Entregável:
A cada Sprint, a equipe deve construir um incremento de produto de software

que seja potencialmente entregável, ou seja, que possa a qualquer momento ser
colocada em produção por determinação do Product Owner. Para isso, é necessário
que o produto de cada Sprint seja um software executável, cujo código seja bem
estruturado e bem escrito, tenha sido consistentemente testado e possua a
documentação necessária.

Daily Scrum Meeting:
A reunião diária do Scrum (Daily Scrum Meeting) é um rápido momento de

reunião de todos os membros do time, dedicado à resposta das três perguntas
mencionadas anteriormente, visando exercitar os conceitos da inspeção e adaptação
diariamente entre a equipe. Esta reunião tipicamente dura 15 minutos e acontece no
mesmo local e horário todos os dias. Realizá-la no primeiro momento do dia pode ser
uma boa alternativa para convidar os membros do time a refletir sobre o que realizou
no dia anterior e o que fará no dia de hoje.
Uma das grandes virtudes da reunião diária (Daily Scrum) é a criação de uma
plataforma de cooperação entre os membros do time em uma base diária.
Outro aspecto é a transparência que a Daily Scrum confere aos processos

que estão atualmente em execução na organização de forma que, caso haja algum
processo organizacional ou outra interferência, qualquer um que esteja presente
diariamente na reunião como um elemento impeditivo do avanço, caberá então uma
ação para eliminar este impedimento. O Scrum Master terá, desta forma, os
fundamentos necessários para acionar as engrenagens da empresa na busca do
melhor contexto para a produtividade do time.
Além disso, o Development Team deve promover a atualização do Agile

Radiator com as informações levantadas durante esta reunião.

Artefato: Impediment Backlog
✓ Comunicado durante a reunião diária – Daily Scrum – pelo Development Team.
✓ Pilha de impedimentos, sendo estes quaisquer eventos que impeçam o

progresso do Development Team em atingir o Sprint Goal.
✓ Pode ser mantido associado ao gráfico de Sprint BurnDown.
✓ Mantido pelo Scrum Master, responsável por agir e remover cada impedimento
dentro de uma meta das 24 horas.
✓ O Scrum Master pode, para remover impedimentos, pedir auxílio ao Product

Owner e/ou levar o problema ao gerenciamento da empresa.
Artefato: Gráfico Burndown
Gráfico de tendência do trabalho remanescente pelo tempo em uma Sprint,

uma release ou um produto. A fonte de dados é o Sprint Backlog e o Product Backlog,
com o trabalho remanescente rastreado no eixo vertical e os períodos de tempo no
eixo horizontal.
A figura abaixo mostra um exemplo de gráfico burndown. Além das horas

remanescentes, esta versão mostra também as tarefas iniciadas e finalizadas na
forma de barras.
Sprint BurnDown:
✓ Gráfico que exibe a quantidade de trabalho restante em hh (homem/hora)

dentro de um Sprint, baseado na pilha de Sprint Backlog.
✓ É atualizado diariamente após o Daily Scrum, pelo Scrum Master, para refletir
o progresso do Development Team naquele dia.

Exemplo de gráfico Burndown para uma release:
✓ Gráfico que demonstra a quantidade de trabalho restante dentro de uma

Release. Normalmente no eixo y a medida de tamanho (ideal day, story points,
etc.). É atualizado ao final de cada Sprint pelo Product Owner/Scrum Master e
Development Team.
Fonte:
http://epf.eclipse.org/wikis/scrumpt/Scrum/workproducts/release_burndown_chart_7E
6A4A45.html.

Exemplo de gráfico Burndown para uma Sprint:
Fonte:
http://epf.eclipse.org/wikis/scrumpt/Scrum/workproducts/sprint_burndown_chart_F64
7C347.html.
Exemplos reais:
Fonte: http://www.powerlogic.com.br/.

Sprint Review Meeting:
✓ Realizada após cada Sprint, com duração de entre 2 a 4 horas e participação

do Product Owner.
✓ O Development Team demonstra o trabalho realizado no Sprint e é avaliado

pelo Product Owner.
✓ A demonstração deve ser do produto funcionando e deve comprovar que os

itens de Selected Backlogs prioritários (e associado ao Sprint Goal), foram
realizados com objetivo de maximizar o ROI.
O time e o Product Owner devem estar em constante colaboração, definindo

em conjunto como atingir o maior valor ao negócio a partir das tecnologias
disponíveis. A reunião de apresentação da Sprint (Sprint Review Meeting) é um
momento muito oportuno e conveniente para que haja forte interação face a face entre
o time e os stakeholders, em um espírito de colaboração que traz um valor muito

maior do que qualquer relatório escrito; isso porque as ideias são trabalhadas em
cima de algo real, que é o software produzido durante a Sprint.
Um aspecto importante da Sprint Review Meeting é que, ao criar uma

oportunidade de colocar frente a frente, periodicamente, clientes e equipe de
desenvolvimento, cria-se um ambiente de colaboração e uma maior percepção nos
clientes de "resultados entregues" pela equipe de desenvolvimento. Em pouco tempo,
o que foi priorizado na última reunião encontra-se entregue na forma de software real,
e não de documentação intermediária que pouco ou nada interessa aos clientes. Este
ambiente de colaboração, se bem conduzido pelo Product Owner, tende a formar um
ciclo virtuoso entre equipe e clientes, ou ao menos diminuir os conflitos e reclamações
de insatisfação por parte de clientes.
Apesar de haver, em casos especiais, Sprints que produzem artefatos

intermediários como especificações ou ainda atividades de implantação, tipicamente
a Sprint produz software. O objetivo da Sprint review é apresentar este software em
funcionamento para todos os interessados que queiram e que seja conveniente a
participação.
O Scrum Master tem um papel importante de assegurar a participação de

todos os que devem participar.
Idealmente, o Product Owner já conhece o produto que está sendo

desenvolvido e não espera que haja surpresas na reunião de apresentação.
Sprint Retrospective Meeting

O objetivo da reunião retrospectiva da Sprint é promover reflexões e
alavancar adaptações e melhorias na equipe nas práticas do Scrum. O funcionamento
do processo na última Sprint é analisado e ajustado para funcionar melhor na próxima
Sprint. Estas reuniões são limitadas ao tempo de duas horas cada.
✓ Realizada após o Sprint Review, com duração de 1-2 horas -> lições
aprendidas.
✓ Timeline pode ser relembrado em grupo.
✓ Duas perguntas: "O que foi bem?" (WWW-What Went Well?) e "O que pode
ser melhorado?” (WCBI - What Can Be Improved?).
✓ Separação de responsabilidades pelo WCBI (organizacional e time) e

atualização no Agile Radiator.
Artefato: Retrospective itens
✓ Lista de WWW (What went well – o que deu certo) e WCBI (What could be
improved – o que pode ser melhorado), separadas por responsabilidade,
podendo ser "organizacional” onde a instituição (através do Product Owner)
deve ser informada para tomar ações de correção ou relativas ao "time”.
✓ O Product Owner é responsável por agir para a lista organizacional e o

Development Team pela lista "time".
Qual o papel do Scrum Master nas reuniões Retrospective Meeting?
Atuar como facilitador e guardião do processo a fim de:
▪ Evitar apontamento de culpados após o levantamento de itens de WCBI da

equipe;

▪ Favorecer identificação da causa raiz de cada WCBI levantado;
▪ Acompanhar as ações planejadas para que cada WWW se mantenha;
▪ Acompanhar as ações planejadas para que cada WCBI seja efetivamente

resolvido.
Release Review:
Reunião de validação do projeto como um todo. Funciona como a Sprint

Review, mas neste caso o Product Owner conduz a reunião para apresentação à Alta
Gestão dos trabalhos que a equipe realizou. Pode-se também, neste momento,
apresentar alguns indicadores sumarizados.
IMPORTANTE: Apesar de ser bastante comum e necessário o planejamento

das entregas de cada iteração utilizando as fases de Pre-Game e Post-Game, quando
são realizadas as reuniões de Release Planning e Release Review, o Scrum Guide
2011 retirou qualquer referência ao planejamento da release. Os cocriadores do
Scrum removeram a citação por entenderem que vai de encontro às fraquezas do
desenvolvimento de software, e que pode levar a não entrega de valor e a um não
desenvolvimento real incremental e iterativo. Maiores informações podem ser
consultadas na seção de Scrum Guide 2011.
Exemplos de indicadores de acompanhamento de Sprint e Release:
Gráfico Burndown: Indicador que mede o progresso do trabalho refletindo

diariamente seu trabalho. Sua curva indica se o Development Team está se
adaptando para o plano definido e comprometido por todos - Sprint Goal - e
conseguindo trabalhar de forma realmente iterativa ou sofrendo impedimentos em
excesso.

Histórico de sucesso de alcance de Sprint Goal: indicador simples de resultado de
alcance de goal por iteração, a fim de manter a equipe focada em melhorar seu
desempenho e comparar resultados anteriores. Além disso, de forma lúdica, pode-se
criar mecanismos de premiação em caso de alcances sucessivos.
Priorização por valor de negócio: indicador que mede a efetividade das entregas
em relação à liberação de máximo valor de negócio ao cliente. Dessa forma, deve-se
medir se o Product Owner está priorizando corretamente as demandas de trabalho
nas liberações ao longo do tempo.

Ao estabelecer um número de Valor de Negócio (BV ou Business Value)

juntamente com a Alta Gestão, para os grandes temas a serem desenvolvidos em um
produto, e ao desenvolver Requisitos (itens do Product Backlog) rastreados com estes
temas, e também priorizados por Valor de Negócio, o PO estabelece uma fórmula e
práticas para priorização que objetivam "maximizar o número de BVs liberados".
Este indicador mostra, ao longo do tempo, a cada iteração e projeto, o total

de BVs liberados. Deste modo, é um importante sinal sobre o trabalho de priorização
e concepção de ideias do Product Owner.
Tamanho previsto x realizado: indicador que mede a eficácia do

dimensionamento do tamanho dos requisitos ao longo do tempo (pode ser a cada
iteração). Dado os itens de Selected backlog do Sprint, compara tamanhos previstos
x realizados após a reunião de Release/Sprint Review.

Sprint Dashboard: indicador que acompanha diariamente a evolução de entregas de

BV e de esforço restante, consolida número de impedimentos, número de tarefas a
fazer e finalizadas, além dos gráficos Burndown e BurnUp.
Fonte: Revista Visão Ágil.

Gestão Ágil de Projetos com Scrum e FDD – Manoel Pimentel Medeiros.

Checklist
Existem alguns checklists que auxiliam na condução de equipes Scrum e

verifica se pontos importantes no framework foram seguidos.
Fonte: Henrik Kniberg – Traduzido para português –

http://www.slideshare.net/demetriusnunes/scrum-checklist-2766568.
Abaixo, parte do checklist, visto na figura acima, que contém os itens base que
formam a essência principal do framework Scrum:

Parte do checklist com itens essenciais e também importantes ao se utilizar o
framework – práticas que não devem ser descartadas:
Parte do checklist com itens recomendados, mas que podem ser

experimentados para verificar a adaptação ao ambiente organizacional:

Parte do checklist com itens para validar a efetividade de implementação do
Scrum dado uma equipe:
Resumo do Planejamento de um Projeto Scrum
O Product Owner é o responsável por obter os fundos necessários para que

o projeto entregue um sistema que atenda à visão concebida, de forma a maximizar
o ROI. Ele (ou ela) elabora um plano para realizar esta visão, criando o Product
Backlog. Esta lista de requisitos é então priorizada, de maneira que os itens de maior
valor para o negócio tenham maior prioridade e seja dividida em releases propostas.
O Product Backlog e a proposta de divisão em releases são neste momento

um ponto de partida, e certamente irão modificar-se no início do projeto.
Todo trabalho é realizado em sprints, que são iterações com tipicamente 30

dias de calendário, podendo variar em cada empresa. Uma Sprint é iniciada com uma
reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e a
equipe se unem para definir colaborativamente o que será realizado na próxima
Sprint. Partindo dos itens prioritários do Product Backlog, o Product Owner apresenta
as necessidades e a equipe identifica o que pode ser realizado. A reunião de
planejamento da Sprint é limitada por tempo ("timeboxed"), não devendo ultrapassar

a duração de oito horas, para evitar muita especulação sobre o que pode ou não ser
produzido; a meta é iniciar rapidamente o trabalho.
A Reunião de Planejamento da Sprint possui duas partes: a primeira é

dedicada à apresentação, pelo Product Owner, dos requisitos de mais alta prioridade
do Product Backlog para a equipe, que apresenta suas perguntas acerca desses
requisitos, tanto em relação ao entendimento quanto seu valor para o negócio e outros
aspectos. Ainda na primeira parte (dentro das primeiras quatro horas), a equipe
seleciona o maior número de itens do Product Backlog que ela acredita que será
possível desenvolver e entregar na próxima Sprint, comprometendo-se com o Product
Owner que fará o melhor possível.
A segunda metade da reunião é dedicada ao planejamento da Sprint pela

equipe, que gera um plano inicial, preenchendo o Sprint Backlog com as tarefas deste
plano. Novas tarefas podem emergir no decorrer da Sprint. A partir da segunda
metade da reunião, já está contando o tempo da atual iteração.
Diariamente, a equipe se reúne em uma reunião rápida de 15 minutos,

denominada Daily Scrum. Nesta reunião, cada membro da equipe responde a três
perguntas:
✓ O que você fez neste projeto desde a última reunião diária?
✓ O que você planeja realizar neste projeto entre hoje e a próxima reunião diária?
✓ Que impedimentos existem para que você atinja seus compromissos para esta
Sprint e para o projeto?
O objetivo desta reunião é sincronizar diariamente o trabalho de todos os

membros da equipe e agendar as reuniões necessárias para que a equipe avance
nas atividades.
No final da Sprint, uma reunião de avaliação é realizada (Sprint Review

Meeting). Esta reunião também é limitada por tempo, não devendo passar de quatro

horas de duração. Nesta reunião, a equipe apresenta o que foi desenvolvido durante
a Sprint para o Product Owner e outras partes interessadas que queiram participar.
Esta reunião tem o objetivo de reunir as pessoas para que, colaborativamente,
ajudem a equipe a determinar o que deve ser feito em seguida.
Após a apresentação da Sprint e antes da reunião de planejamento da

próxima Sprint, o Scrum Master conduz uma reunião de revisão ou avaliação da Sprint
com a equipe – Retrospective Meeting. Novamente, trata-se de uma reunião com
tempo fixo, que não deve ultrapassar três horas de duração. Nesta reunião, o Scrum
Master encoraja o time a revisar o processo de desenvolvimento realizado, tendo em
vista as práticas e processos do framework Scrum de forma a torná-lo mais efetivo e
agradável para a equipe na próxima Sprint.
Resumo das atividades por papel:
✓ O Product Owner deve:
– Manter continuamente seu backlog preparado e priorizado.
– Detalhar itens do backlog que serão explorados no próximo sprint.
– Estimar de forma macro os requisitos que deseja implementar e definir

o novo Sprint Goal.
– Alinhar as expectativas junto aos stakeholders.
✓ O Development Team deve:
– Refinar a análise e projeto dos itens de backlog do Sprint.
– Implementar os itens.
– Testar.
– Documentar.

– Integrar continuamente.
– Garantir a entrega de BV e atendimento ao Sprint Goal.
✓ O Controle de Qualidade (QC) deve:
– Validar a entrega de BV e atendimento ao Sprint Goal.
– Identificar retrabalhos e reportar a equipe responsável e PO – revalidar

se necessário.
– Automatizar testes que rodam na integração e geração de builds.
– Atuar nas etapas de verificação e validação dos artefatos produzidos:

código executável, documentação, etc.

Capítulo 5. Estimativa e Priorização Ágil e Scrum DNA
Ser ágil diz respeito à habilidade em responder rápido às mudanças: de

requisitos, prioridades, tecnologias e ferramentas, pessoas, complexidade de
desenvolvimento de software, etc. Para isso, utiliza conceitos como iteratividade,
técnicas incrementais, times multifuncionais, autogerenciamento e auto-organização.
Abaixo, importantes características de ser ágil:
Fonte: Mike Cohn – Agile Estimating & Planning.

PONTOS PRINCIPAIS: Planejamento constante x grande plano inicial.
O Scrum prega planejamentos constantes que levam a planos facilmente

modificáveis, e é contra um grande planejamento inicial. Defende também o escopo
aberto – conseguido através de negociação e trabalho em equipe com real
colaboração e comprometimento. O constante planejamento pode ser evidenciado
através da figura abaixo:
1. Primeiro nível de PDCA: Daily Scrum ocorrendo diariamente e sendo

acompanhado pelo Development Team – PDCA mais interno.
2. Segundo nível de PDCA: Sprint Planning ocorrendo a cada iteração (Sprint)

– período de 7 ou 15 dias podendo chegar no máximo de 30 dias. É feito pelo
Product Owner e executado pelo time.
3. Terceiro nível de PDCA: Release Planning ocorrendo a cada projeto

(Release) - sugestão de período a cada três meses. É feito pelo Product Owner
e apresentado para o time.
4. Quarto nível de PDCA: RoadMap do Produto ocorrendo a cada seis meses

para planejamento da visão do produto pelo Product Owner.
5. Quinto nível de PDCA: Visão do Produto ocorrendo anualmente executado

pelo Product Owner.

Algumas diferenças entre Planejamento Preditivos e Planejamento Ágil:
✓ Planejamento preditivos:
– Há a criação de um plano com atividades definidas.
– O gerenciamento/acompanhamento de atividades é feito conforme o

plano definido – através de Gráfico de Gantt, por exemplo.
✓ Planejamento ágil:
– Há a criação de entregas com conjunto de itens priorizados.
– O gerenciamento é executado via feedback e constante adaptação.
✓ Planejamento preditivos:
– Tradicional “Command and Control Strategy”.
– As decisões são executadas por autoridades.
– Atividades são delegadas.
– O gerente controla as atividades.
✓ Planejamento ágil:
– Agile, “Facilitation and Empowerment Strategy”.
– Decisões são feitas por aqueles que possuem maior informação sobre
o problema.
– O time se auto-organiza e adapta à situação atual.
– A organização assegura um ambiente de boas condições de trabalho.

Características ágeis importantes e essenciais para o correto gerenciamento de
projetos Scrum:
✓ Cliente sempre por perto, deve-se fazê-lo um participante ativo. É importante

que ele entenda suas responsabilidades e sua grande parcela de contribuição
para o sucesso do projeto.
✓ Iterações curtas levam ao feedback real e imediato dado pelo cliente, e como
resultado, auxiliam nos possíveis ajustes que não acontecem mais tardiamente
e garantem a entrega de software de valor.
✓ Atendimento ao goal x Controle da WBS.
✓ A identificação e o gerenciamento dos riscos em metodologias ágeis são feitas

em taxas diárias (através de reuniões curtas e diárias) e durante toda a
iteração.
✓ O controle da qualidade dos trabalhos é avaliado continuamente através de,

por exemplo, testes, revisão por pares, inspeção contínua e acompanhamento
pelo cliente.
✓ Impedimentos são levantados e estes devem ser resolvidos no prazo máximo

de 24 horas para garantir que ações de resolução rápidas são executadas e
para que todos conheçam os impedimentos que podem se tornar potenciais
riscos para o projeto.
✓ Mudanças no projeto são bem aceitas, pois elas existem e irão acontecer. É
por isso que o comprometimento de todos os envolvidos é tão importante em
um projeto. Caso o cliente queira mudar algo que solicitou ou o mercado peça
neste momento algo diferente, pode-se mudar o rumo rapidamente sem afetar
todo o projeto, pois o planejamento é refeito a todo o momento.

✓ E se uma iteração não foi conforme o esperado pelo cliente, pode-se mudar a
abordagem de levantamento de dados, os recursos envolvidos, a forma de
troca de informações e corrigir o rumo ainda a tempo do final do projeto.
Em qualquer projeto, quatro variáveis de controle requerem cuidado e devem

ser monitoradas continuamente:
– Escopo.
– Recursos.
– Tempo.
– Qualidade.
Dado isso, é importante analisar quais variáveis devem ser inegociáveis e

quais podem sofrer alterações durante o projeto – alinhado a Teoria de Restrições
explicada anteriormente.
✓ Mudanças no escopo: é a variável mais efetiva em ajustar.
– No lugar de fixar o escopo de um projeto, deve-se procurar negociar

entregas que trazem maior retorno de valor ao cliente. Entregas parciais
podem gerar retornos imediatos.
“É preferível se atingir uma data com um escopo parcial

implementado, do que com o escopo completo parcialmente terminado.”
Abaixo, segue uma figura que exemplifica formas de priorização do escopo:

o que fazer quando novos itens são levantados, removidos ou quando sofrem
alteração em sua ordenação. Itens de maior prioridade devem estar modelados em
maior detalhe para que possam ser implementados durante os Sprints de uma
release.

✓ Mudanças nos recursos: recursos são geralmente a variável menos efetiva
para se ajustar.
– Quando um projeto está atrasado, adicionar pessoas ao projeto servirá

apenas para atrasá-lo ainda mais.
– Devemos considerar o tempo que perdemos em gestão e comunicação

quando temos pessoas demais trabalhando em um projeto.
– Desenvolvimento heroico enfatiza indivíduos:
✓ As atividades são designadas individualmente.
✓ Projeto fica altamente dependente da performance dos

indivíduos envolvidos.
– Desenvolvimento colaborativo enfatiza o time -> Scrum:
✓ Um time auto-organizado define as atividades para se atingir as

metas estabelecidas.
✓ O time possui habilidades diversas (generalizing specialist –

Scott Ambler).

✓ Melhoria na comunicação e colaboração.
✓ Melhoria na flexibilidade.
✓ Menor risco.
✓ Mudanças no tempo (prazo): Prazo não é uma variável negociável no Scrum.

Deve-se manter ciclos de desenvolvimento tempo-fechado (time-boxed) para
garantir o fluxo do trabalho dos envolvidos. Somos todos já acostumados com
o tempo regendo nossas vidas. Dessa forma, criar uma cultura de ter reuniões
de planejamento às segundas a cada 15 dias, e reuniões de revisão às sextas
a cada 15 dias, por exemplo, faz com que a equipe se acostume com esta
prática e consiga se comprometer mais facilmente. Além disso, consegue-se
manter um histórico da velocidade da equipe se usarmos o mesmo período
continuamente.
✓ Mudanças na qualidade: Qualidade também é uma variável não negociada por

equipes Scrum. Ela deve ser intrínseca ao processo e a própria equipe deve
garantir sua manutenção através de acompanhamento contínuo, testes de
regressão, refactoring, etc. Combinação do Scrum + práticas de Engenharia
de Software como o XP.

Estimativas ágeis:
Estimativas já fazem parte de nosso dia a dia. Exemplos:
✓ Tempo para chegar ao trabalho – esta é uma estimativa que fazemos

diariamente. Há diversas variáveis que alteram a duração do trajeto entre
nossa casa e o trabalho. O clima, o trânsito (quantidade de carros, um carro
estragado, uma batida, sinal de trânsito apagado, motorista despreparado,
etc.), dia da semana, protestos em uma praça, período festivo, etc.
✓ Data do parto – por mais que especialistas calculem a data prevista do parto,
dificilmente ele acerta exatamente a data real da chegada do bebê. Isso ocorre
em função do grande número de variáveis envolvidas.
✓ Tamanho da salada em um restaurante: Ao pedir uma salada ceasar de

tamanho médio em mais de um restaurante, provavelmente experimentaremos
tamanhos diversos.
Estimativa de Software é a disciplina da Engenharia de Software que trata da

elaboração de estimativas de tamanho, esforço, prazo, custo e qualidade no
desenvolvimento de software. Estes indicadores são utilizados para correlatar contra
os desempenhos observados no passado e então criar previsões de desempenho
futuro.
Tamanho x Esforço:
O tamanho é “unitless” e é uma medida inicial que não leva em consideração

o recurso que implementará a atividade, enquanto o esforço é dependente do(s)
recurso(s) alocado(s) para desenvolvê-lo.

Imagine uma parede 1mx1m. Independente de quem a concebeu, ela
continuará tendo o mesmo tamanho. Por outro lado, seu tempo de entrega (esforço),
variará de acordo com o executor designado para tal. Esforço deriva de tamanho.
Exemplos de medidas de tamanho:
- Pontos de função.
- Pontos de caso de uso.
- Ideal Day.
- Story Point, etc.
A partir do tamanho, pode-se criar uma correlação direta com esforço. Por
exemplo, uma equipe Scrum demora 20 horas (esforço) para implementar um Ideal
Day (tamanho).
Custo e prazo podem ser calculados a partir do esforço e qualidade de um

conjunto maior além dos citados!!!
Estimativas x “Exatimativa”
Em 2008, foi publicado por Diego Pacheco, em seu blog, uma discussão
interessante entre estimativa e “exatimativa”. Não se pode deixar de estimar em
função das dificuldades que se enfrenta nesta atividade.
Estimativas sofrem influências diversas e carregam riscos inerentes:
✓ Tecnologia: mudança constante e por isso, pouco conhecimento e dado

histórico para auxiliar.
✓ Equipe (velocidade, domínio no negócio e tecnologia, etc.): mudança na

equipe, nas habilidades requeridas, experiência, contexto, etc.
✓ Tamanho e tipo do projeto.

✓ Maturidade dos requisitos – mudança: eles podem se apresentar instáveis ou
estáveis dependendo até do momento do projeto.
✓ Cliente: mudança de cliente e de prioridades.
Algumas iniciativas podem auxiliar em melhorar as estimativas, como:
✓ Experiência.
✓ Utilização de informações históricas.
✓ Coragem para comprometimento.
Ou seja, os inputs (variáveis) e outputs (estimativa) que são utilizados tem

que ser bem definidos, e utilizando uma técnica de estimativa adequada!
Quando fazemos uma estimativa, seja para o nosso dia a dia ou para o mundo
do desenvolvimento de software, não podemos defini-la como algo totalmente
previsível e que vamos acertar. Apesar disso, a estimativa é necessária. A dificuldade
principal consiste em se considerar a estimativa como uma “exatimativa“. O problema
é incluir a estimativa como parte de um contrato leonino onde ela é cartesianamente
cobrada. Há diversos problemas em acreditar nesta abordagem:
✓ Muitas vezes queremos determinar uma única data. Isso não é factível! Veja
se consegue responder com precisão alguma das perguntas abaixo:
▪ Qual é a área da superfície do sol?
▪ Qual é a área do continente africano?
▪ Qual é o valor total de circulação de dinheiro na china em 1945?
Possível solução:

▪ Utilizar PERT e consequentemente considerar um range de
valores para tentar aproximar do valor correto.
▪ Ao lidar com datas, deve-se utilizar checkpoints bem definidos

para tentar aproximar sua previsão, dado o contexto atual.
✓ Outro problema é planejar muito cedo, tendo requisitos e tecnologias

envolvidas ainda imaturas.
– Possível solução:
▪ Criar mecanismos, como contratos ágeis, por exemplo, para

mitigar riscos buscando conhecer o cliente, tecnologia antes
de estimar – Lembre-se do Cone da Incerteza em capítulos
anteriores!
Técnicas de estimativas:
✓ Contar, Computar e Julgar: consiste em contabilizar linhas de código, requisitos,

casos de uso, páginas em um sistema web, funções, etc.
– LOC, APF...
✓ Opinião do Especialista: consiste em utilizar a opinião do especialista com base

no seu conhecimento no domínio da questão. Podemos incrementar este método
utilizando fórmulas que vão do mais realista ao otimista, e até levando em
considerações margens de erro e outros métodos existentes como Cocomo.
✓ Decomposição e Recomposição: dividir para conquistar. Um exemplo é a forma

de construir a WBS. Consiste em quebrar o que deve ser entregue em pequenas
unidades de trabalho.

✓ Estimativas por Analogia: consiste em comparar comportamentos semelhantes,
como quando você já fez um software antes e está fazendo algo similar com o
anterior.
✓ Estimativas Baseadas em Proxy: é baseado em alguma escala e em um conjunto

de informações. Como exemplos: Story Points, T-Shirt Sizing, entre outras.
✓ Julgamento de Especialistas em grupo: consiste em realizar diversas estimativas

através de um grupo de pessoas especialistas. Como exemplo, o Planning Poker
do Scrum e o Wideband Delphi. Neste caso, utiliza-se ou as médias no caso do
Wideband, ou a votação no caso do Scrum.
Medidas de Tamanho Ágeis:
Conforme dito acima, não se deve estimar duração diretamente. Primeiro,

define-se o tamanho de um item de Product Backlog. A duração será derivada do
valor do tamanho pela velocidade.

Medidas de tamanho ágeis:
Story Points
Baseia-se no tamanho da estória levando em consideração:
✓ Sua dificuldade e complexidade.
✓ Conhecimento.
São “unitless”, times diferentes podem ter Story Points diferentes para uma
estória, dado ponto de referência que escolherem.
Como principais técnicas para estimar:
✓ Opinião de especialista (muito comum em métodos ágeis).
✓ Analogia.
✓ Quebra de estórias (menor granularidade).

É comum estimar com Story Points utilizando a série de Fibonacci ou
números múltiplos: 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 - 100. A sugestão a ser utilizada
tem o propósito de ser não linear. Quanto menor o item, mais precisa a estimativa –
por isso, utiliza-se quebra de estórias independente da medida ágil de tamanho
utilizada. Os tamanhos 40 e 100 devem ser utilizados somente para itens de menor
prioridade no Backlog, conhecidos como épicos.
Formas de iniciar a estimativa por Story Points:
✓ 1ª. – escolher uma estória que se espera ser a menor que será trabalhada e
estimá-la em 1 SP.
✓ 2ª. – escolher uma estória considerada de tamanho médio e associar um valor

de 5 SP (considerando range de 1 a 10 SP).
✓ A melhor maneira é tentar, experimentar!

Ideal Day:
Um Ideal Day corresponde à quantidade de trabalho que um profissional de

nível sênior, com fluência nas tecnologias e ferramentas envolvidas (Ideal Developer)
consegue realizar, em 8 (oito) horas de trabalho dedicadas (sem interrupções).
É importante que se compreenda que o "Dia Ideal", com 8 (oito) horas de

trabalho sem interrupções, de um "desenvolvedor ideal", raramente ocorrerá na
prática, e, portanto, deve ser utilizado unicamente como "moeda" estável para
quantificação de tamanho de referência, e balizador ideal de produtividade.
É uma estimativa empírica, executada por especialistas ("Expert Judment")

para desenvolvimento com base em "exploração adaptativa". Segundo estudos mais
recentes da escola ágil, a estimativa empírica é uma maneira sensata de se prever o
tamanho de requisitos em uma dinâmica de "requisitos evolucionários", com práticas
de "exploração e adaptação", especialmente se acompanhada por:
✓ Realimentação iterativa da "velocidade" a partir de dados históricos,

preferencialmente coletados durante o mesmo projeto, para a mesma equipe.
✓ Previsão sobre uma mesma "ordem de grandeza", em caso que não ultrapasse
o espaço de algumas horas para alguns poucos dias.
✓ Realização de consenso entre especialistas, com técnicas de comunicação e

convergência como a do Planning Poker.
✓ Utilização da técnica de PERT (Program Evaluation and Review Technique).
✓ Utilização de balanceamento como a técnica Cocomo (COnstructive COst

Model).
Irão contribuir para que um "Ideal Day" não aconteça, na prática, em um dia
típico:

✓ Natureza humana do desenvolvedor (comer, beber, alongar, socializar, sono,
mal-estar eventual, etc.).
✓ Deficiências técnicas do desenvolvedor (desconhecimentos do assunto ou

tecnologias específicas).
✓ Interrupções da empresa (reuniões administrativas, conversa com o 'chefe',

ligações de clientes).
✓ Interrupções pessoais.
✓ Etc...
Dessa forma, a equipe deve ter sua velocidade medida pelo tempo gasto para
se implementar um Ideal Day. Quanto menos tempo, maior a velocidade e maior a
produtividade da mesma. Na realidade, não é importante conhecer a velocidade
individual e sim a média da equipe. Para se manter uma unidade, não é interessante
expor se um integrante executa suas atividades em mais ou menos tempo. É uma
dinâmica do grupo! Ele deve aprender como interagir melhor para a busca de
entregas com maior retorno de valor para o cliente. Se for necessário utilizar de
técnicas como pair-programming para agilizar o desenvolvimento e validação de um
requisito, o time deve escolher este caminho. Também pode-se utilizar peer-review
para verificações e validações, assumir outro papel (trocar de “chapéu” dentro da
equipe), dentre outras práticas para convergir para o objetivo definido.

Planning Poker + PERT:
✓ A estimativa é realizada a partir das seguintes questões:
– Qual o tamanho mínimo em Ideal Days do item do Selected Backlog ao

considerar, por exemplo, um baixo impacto ou instabilidade provocados
pela sua implementação? – Melhor Caso.
– Qual o tamanho máximo em Ideal Days do Selected Backlog ao considerar

um maior impacto e instabilidade? – Pior Caso.
– Qual o valor mais provável?
– Fórmula a ser utilizada - (MC + 4xMP + PC) /6, onde MC é o Melhor Caso, MP
é o Mais Provável e PC é o Pior Caso.
Este tipo de análise contribui para a reflexão sobre situações limítrofes para
pior ou para melhor e mais provável, deste modo aprimorando o resultado ideal. Ainda
é aconselhável utilizar matrizes de rastreabilidade de requisitos para que se tenha

uma dimensão do impacto (número e artefatos afetados) do Selected Backlog a cada
estimativa ou alteração no requisito.
Conceitos importantes para estimativas de software
Disponibilidade da Equipe:
O cálculo da disponibilidade da equipe serve para identificar a quantidade de

trabalho que uma equipe consegue alocar dentro do Sprint.
Este valor deve ser calculado no início de cada Sprint pelo Product Owner, e
seu resultado deve ser apresentado nas reuniões de Sprint Planning 1. Toda e
qualquer indisponibilidade pode ser reavaliada neste momento! Não se deve planejar
8 horas de trabalho diárias e sim 5,5 a 6 hs/dia.
Esta perda poderá acontecer devido a:
✓ Impedimentos.
✓ Retrabalhos.
✓ Participação em reuniões.
✓ Alocação em outros papéis como Scrum Master, Gerente de Configuração, etc.
Exemplo prático:
✓ Tenho três recursos trabalhando em um Sprint de 15 dias:
– Fórmula: Número de recursos x número de horas do dia, x número

de dias úteis do Sprint.
– (3 x 8 horas) x 10 = 240 horas brutas.

Tendo em vista 240 horas para implementar o escopo do Sprint, é
necessário que as perdas citadas acima levem a um número de horas líquidas que
serão de fato consumidas. Por exemplo, pode-se reservar, em um primeiro
momento, 6% do tempo total para impedimentos. 8% do tempo total para
retrabalhos que possam vir a acontecer durante o Sprint, além de horas em
participação de reuniões.
✓ 240 horas: 6% para impedimentos {14,4} - 8% para retrabalho {19,2} –

horas nas reuniões – SP1, SP2, SR, Sretrosp, DS {(8+4+2,5)*3=43,5} =
162,9 horas reais!
Portanto, não devemos considerar 240 horas pelos três recursos alocados
no projeto. É mais realista utilizarmos as 162,9 horas calculadas acima!
Velocidade:
A velocidade corresponde ao número de horas para implementar um Ideal

Day. Como calcular a velocidade inicial da equipe:
✓ Utilize médias históricas.
✓ Faça uma previsão inicial e depois compare com resultados apresentados.
✓ “Rode” algumas iterações e verifique/meça o comportamento do time.
No fim da Release ou Sprint, deve-se armazenar a velocidade apresentada.
Velocidade = Num_horas/ID_realizados, ou seja, onde Num_horas é o

número de horas utilizadas para desenvolvimento dos itens de backlog entregues /
Número total de ID realizados.
* Deve-se retirar todas as horas que foram destinadas a impedimentos,

atendimentos, etc. Horas que foram gastas para retrabalho devem ser contabilizadas.

Segue abaixo um exemplo de um indicador que pode ser criado para
demonstrar o histórico de velocidade da equipe dentro dos Sprints:
Esforço:
Esforço é uma medida em horas (hh), enquanto tamanho é unitless!! Portanto,

para calcular o esforço através da velocidade da equipe, pode-se utilizar a fórmula
abaixo:
– Esforço = tamanho do item de backlog x velocidade média da equipe.
Produtividade:
A produtividade da equipe representa o número de Ideal Days

implementados, por exemplo, em um Sprint.
✓ Produtividade do Sprint = ID Realizados.
Ao final do Sprint, deve-se apurar novamente este número e fazer a média

entre Sprints, atualizando sempre esta informação.
✓ Produtividade da Release = ID Realizados/Número de Sprints.

Viabilidade da Release/Sprint:
É sempre muito importante para o correto acompanhamento de projetos,

verificar continuamente a viabilidade em atingir o Release e Sprint Goals definidos.
Abaixo, formas de cálculo de viabilidade do escopo planejado para uma Release ou
Sprint utilizando os conceitos apresentados acima.
Forma 1 – viabilidade da Release/Sprint através da disponibilidade da equipe

em horas:
Dado Select Backlog pretendido, deve-se calcular o somatório de Ideal Days dos
mesmos x velocidade da equipe. Confrontar o resultado com o número de horas do
cálculo de disponibilidade.
Forma 2 – viabilidade da Release/Sprint através da produtividade da equipe:
Dado a produtividade da equipe, confrontar o valor com número de Ideal Days

pretendidos.

Depois dos conceitos sobre estimativa de software estarem alinhados, segue
caso prático para validação do conhecimento adquirido:
Se sua equipe irá trabalhar 4 horas por dia, você deverá estipular sua baliza,
ou seja, 1 ID = 4 horas, e ainda determinar a velocidade média inicial de sua equipe,
por exemplo, ID = 10 horas. A primeira estimativa da velocidade da equipe é
realmente empírica, as demais serão baseadas em dados históricos.
1) Abaixo, uma lista resumida de itens do Selected Backlog já estimados via Ideal
Day durante o Poker Planning.
a. RF01 – Implementar carrinho de compras – 0,5 ID.
b. RF02 - Cadastrar livros – 0,3 ID.
c. RF03 – Consultar livros por autor– 0,1 ID.
d. RF04 - Implementar recomendação automática de livros – 0,4 ID.
2) Pelo conceito de pilha, cada membro deve retirar uma tarefa para executar e
apropriar as horas gastas ao final do dia. Este procedimento é necessário para
que, ao final do Sprint, seja possível determinar quantos Ideal Days foram
concluídos e o seu tempo de execução.
Note que o tamanho de um requisito nunca muda! O que muda é o esforço

do mesmo, que depende do recurso alocado - velocidade.
O recurso 1 irá implementar o RF01, que tem 0,5 ID de tamanho. Se for a

primeira vez e não se tem dados históricos para determinar o esforço do recurso,
utiliza-se a velocidade inicial determinada empiricamente de 10 horas.
Por isso, o requisito terá duração prevista de 5 horas.
Esforço = tamanho x velocidade.
Esforço = 0,5 x 10 = 5 horas.

De acordo com o número de horas que a pessoa trabalha (se ele trabalha
somente pela manhã), será necessário “quebrar” este requisito para que seja possível
concluí-lo em 1 dia de trabalho e mover o post-it de “em andamento” para “finalizado”,
evidenciando a evolução do trabalho.
Desse modo, atualizando o gráfico Burndown através da subtração do

tamanho (0,5 ID) de Ideal Days realizados, será possível acompanhar desvios entre
previsto e realizado de maneira efetiva e visual.
Com a apropriação do Sprint, obtêm-se dados para calcular a velocidade

padrão do grupo. A tabela abaixo exemplifica os dados apurados após
implementação.
Requisito Tamanho Previsto Recurso Horas real
RF01 0,5 ID Recurso 1 4,5 horas
RF04 0,4 ID Recurso 2 3 horas
TOTAL: 1,3 ID 11,5 horas
O recurso 1 implementou os requisitos RF01 e RF03, totalizando entrega de

0,6 ID. Já o recurso 2, os RF02 e RF04, totalizando 0,7 ID.
Para calcular a nova velocidade, após o Sprint:

Velocidade ID previsto ID realizado Horas real
inicial
Recurso 1 10 0,6 0,6 6
Recurso 2 10 0,7 0,7 5,5
As horas de retrabalho serão consideradas, mais tarde, após testes do

controle de qualidade, e terão um peso maior no cálculo da velocidade da equipe.
Fórmula para cálculo da velocidade = horas_realizadas + (horas_retrabalho *

1,3) / ID realizados.
Recurso 1 = 6 + 0 / 0,6 = 10 horas.
Recurso 2 = 5,5 + 0 / 0,7 = 7,8 horas.
Média da equipe = 8,9 horas.
No próximo Sprint, a média a ser considerada será a calculada no Sprint

anterior e não mais empiricamente.
A produtividade é extraída da avaliação do número de Ideal Days/Sprint. No

primeiro Sprint, a produtividade é igual ao número de Ideal Days entregues.
Produtividade da equipe = 1,3 ID
Considerando a produtividade da equipe, no próximo Sprint será possível

alocar itens do Selected Backlog que totalizem o número de Ideal Days entregues no
Sprint anterior – no nosso exemplo, 1,3 ID. Ao final do mesmo, deve-se apurar
novamente este número e fazer a média entre Sprints, atualizando sempre esta
informação.

Você deverá medir novamente e obter mais dados históricos para conhecer
a média de produtividade e de velocidade da equipe.
A produtividade da Release, pode ser calculada como:
Produtividade da Release = ID Realizados/ Número de Sprints.
Priorização Ágil:
Business Value (BV) ou Valor de Negócio, reflete a importância estratégica

de uma funcionalidade do produto para o mercado. O Product Owner deve manter a
lista de Product Backlog constantemente atualizada e avaliada com seu business
value atribuído, podendo ser revisado a qualquer momento.
1a Etapa de Priorização:
Esta prática faz parte da primeira etapa de priorização, que permite ao

Product Owner classificar os itens de maior valor para o mercado e que obtenha o
maior retorno para o negócio sobre o investimento. Ao iniciar uma Release, será
possível identificar e selecionar os possíveis itens do Product Backlog, que farão parte
do escopo a ser desenvolvido. É interessante estipular um valor limite para a
distribuição entre os itens da pilha. Cada funcionalidade deve ter seu valor
compreendido na escala estabelecida pela organização, por exemplo, de 0 a 100.
O gráfico abaixo exibe a quantidade de BVs entregues ao longo dos Sprints

de um Release. Este valor deve ser sempre maior nas primeiras iterações!
− 80% do valor de um software vem de 20% das funcionalidades – PARETO.
− 60% das funcionalidades entregues em projetos de sucesso são raramente,

ou nunca, utilizadas.

Outra variável que deve ser inserida na fórmula de priorização dos itens que
irão compor o escopo da Release (Release/Selected Backlog) é a facilidade de
implementação do requisito, executando assim a segunda etapa de priorização.
Quanto maior a facilidade, menor deve ser seu esforço de implementação.
Um gráfico de quatro quadrantes de itens do escopo que foram classificados

em função, seu BV e sua facilidade de implementação. Itens que se concentram no
quadrante superior direito são os que devem ser priorizados e, seguramente, são os
que mais representam a maximização do resultado.

As coordenadas do gráfico seguem os valores de BV determinados pelo
responsável do produto e a facilidade de implementação estimada em consenso pela
equipe de desenvolvimento. O tamanho de cada bolha representa proporção de valor
de negócio de cada item, considerando a lista em que ele está inserido. Caso seja
necessário, cabe a cada organização determinar um diferente “peso” para esta
representação. Portanto, esta etapa organiza a ordem de execução dos requisitos da
pilha selecionados e norteia a equipe de desenvolvimento.
Dado isso, a fórmula sugerida deve ser a seguinte:
✓ Priorização final da pilha = BV/ Tamanho do requisito.
Como critério de desempate, a criticidade pode ser considerada, uma vez que
ela determina o momento atual e pode ser utilizada como “alteração manual” dentre
a pilha de requisitos:
– 1 – Baixa.
– 3 – Normal.
– 5 – Alta.
– 7 – Urgência.
– 9 – Emergência.
A fórmula final sugerida de priorização para desempate deve ser

representada como:
– (BV/Tamanho do requisito) * criticidade.

Item de Product Backlog
Tamanho Retorno para Prioridade Ordem Ajustada
Negócio Calculada por diante da
(Em Ideal Day Fórmula criticidade
ou Story Point) (Em BV) “Alta”
BV / ID
Ex.: 20 Ex.: 200
Ex.: 10 * 5
Ex.: 10
Outro ponto a ser destacado e comum em projetos de manutenção de

produtos é a presença de erros que deverão entrar na pilha do Product Backlog.
Pode-se dar um “peso” e modificar a fórmula acima para contemplar este cenário.
Uma vez que BV diz respeito a valor de negócio que a inclusão da funcionalidade irá
prover para o mercado, e erro não acrescenta valor ao produto, sugerimos determinar
BV negativo para este caso. Para que este requisito entre corretamente na
priorização da pilha, deve-se aplicar seu valor absoluto.
A partir deste resultado, a equipe de desenvolvimento consegue determinar

prazos para cada entrega que contempla o escopo acordado. O número de Sprints
de implementação necessários é então comunicado ao responsável pelo produto. A
partir da definição de sua restrição – escopo, tempo, custo ou qualidade - ele tomará
uma decisão e definirá o objetivo maior da Release e do primeiro Sprint. O Scrum
prega o planejamento contínuo, portanto, as demais iterações serão planejadas
oportunamente.
Após esta definição, a equipe de desenvolvimento consegue implementar os

requisitos seguindo, rigorosamente, do topo para baixo da pilha.
Em sistemas enxutos (Lean) de "push", como o Scrum, resolve-se o problema

de dependências de "caminho crítico" simplesmente ajustando-se a ordem de
execução dos itens de Product Backlog: os que dependem são colocados abaixo de
suas dependências.

Segue abaixo uma imagem que exibe a distribuição ideal do tempo do
Product Owner para detalhamento e refinamento de requisitos, em função de sua
localização na pirâmide. A pirâmide segue a informação de que 20% do software
desenvolvido gera 80% do valor do software. Quanto mais alto na pirâmide, maior sua
prioridade definida. Portanto, é recomendável gastar 60% do tempo elicitando estes
20% dos itens do topo da pilha, e prepará-los para serem implementados e estarem
coerentes entre si, claros, sem ambiguidades e factíveis. Depois, gaste outros 30%
do tempo para os 20% dos itens do topo da pilha, e somente 10% do tempo para os
itens restantes.
Relembrando: em torno de 60% do software desenvolvido, é raramente, ou

nunca, utilizado!
Boa prática:
Projeto possui um escopo de tamanho total de 245 Story Points (SP) para ser
desenvolvido e business value total de 1.000 BVs.
É de suma importância desenvolver, respeitando as etapas de priorização

citadas acima. Por exemplo, no Sprint 1 desenvolveu-se itens do Product Backlog de
tamanho 48 SPs e entregou-se 400 BVs. Já no Sprint 2, desenvolveu-se outros 52
SPs e entregou-se 250 BVs. No Sprint 3, 55 SPs e 250 BVs. No Sprint 4, 40 SPs e
100 BV. Enquanto no Sprint 5, 50 SPs e 100 BVs.

É importante notar que o número de BVs foi decrescente, ou seja, maior
retorno valor ao cliente nos primeiros Sprints, independente do tamanho associado.
Leitura Complementar
A combinação entre a agilidade conseguida através de métodos ágeis e a

maturidade adquirida por meio de modelos de qualidade, como CMMI ou MPS.BR,
formam uma abordagem interessante na busca de resultados positivos para
processos de informática. Agilidade como sendo a habilidade de reagir a mudanças
e se manter na direção planejada inicialmente.
Modelo CMMI
Scrum e CMMI:
Um dos pontos frequentemente abordados, quando se começa a desbravar

os caminhos das abordagens ágeis, é como seria possível (ou melhor, se seria

possível) conciliar métodos de gestão como o Scrum e métodos tradicionais de
maturidade de processos, como o CMMI do SEI.
Quanto a este ponto, não existe regra definida e existe todo tipo de
experiência a respeito: implementações de CMMI que geraram a impressão de
burocratização da operação, implementações ágeis que vivenciaram problemas de
difícil endereçamento e, em alguns casos, conciliações interessantes.
No artigo "The Scrum Papers", Jeff Sutherland apresenta um caso em que a

otimização do CMMI com o Scrum apresentou um "resultado mágico", conforme
gráfico abaixo.
Logicamente, não se pode esperar resultados semelhantes em todos os

casos. Existem várias abordagens e cada empresa adota uma estruturação do CMMI
conforme seu contexto e cultura. O aspecto mais importante para a organização é
que concentre fortemente suas iniciativas naquelas frentes que trarão maior retorno
para o negócio, partindo da própria experiência da empresa e das inúmeras
referências disponíveis atualmente no mercado.

Scrum e MPS.BR:
Práticas de métodos ágeis como SCRUM e XP, podem ser mapeadas aos
processos do MPS.BR, por exemplo, levando às organizações a implementarem as
atividades necessárias para a implantação do modelo, e ainda continuar com as
vantagens e leveza dos métodos ágeis.
MPS.BR diz o que fazer, mas não diz como fazer. Metodologias ágeis são um
conjunto de melhores práticas que contém informações específicas de “como fazer”.
Para cada processo do MPS.BR, resultados esperados (REPs) e resultados de
atributo de processo (RAPs) devem ser atendidos e evidenciados para que ocorra a
certificação em determinado nível.
Abaixo, a correlação entre CMMI e MPS.BR:
Fonte: http://asrconsultoria.com.br/.
Áreas de processo MPS.BR:
GPR – Gerência de Projetos

Propósito: estabelecer e manter planos que definam as atividades, recursos
e responsabilidades do projeto, bem como prover informações sobre o andamento do
projeto que permitam a realização de correções quando houver desvios significativos
no desempenho do projeto. O propósito deste processo evolui à medida que a
organização cresce em maturidade, de forma que a gerência de projetos passe a ser
realizada com base no processo definido para o projeto e nos planos integrados.
Envolve várias atividades, como: desenvolver um plano geral de controle do projeto;
obter o comprometimento e mantê-lo ao longo de toda a execução do projeto; e
conhecer o progresso do projeto, de maneira que ações corretivas possam ser
tomadas quando a execução do projeto desviar do planejado.
GRI – Gerência de Riscos:
Propósito: O propósito do processo Gerência de Riscos é identificar, analisar,

tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de
projeto. Todo projeto de software envolve um conjunto de incertezas que podem levar
a resultados negativos. Na grande maioria dos casos, estes resultados podem ser
evitados ou reduzidos se houver preocupação em antecipar possíveis problemas
através do uso de práticas de gestão proativa, identificando e resolvendo os principais
riscos.
Abaixo, segue uma lista de práticas, artefatos e cerimônias (reuniões) que

mapeiam para as REPs e RAPs do processo GPR e GRI.
Por exemplo:
✓ Reuniões de planejamento – Sprint Planning 1 e 2, além das reuniões diárias

– Daily Scrum, para atendimento a REPs de planejamento e acompanhamento
de projetos.
✓ Conceitos de estimativas em Ideal Days/Story Points e prática de Planning

Poker para atender ao resultado de estimativa em tamanho do processo GPR.

✓ WWW e WCBI para controle de lições aprendidas.
✓ Product Backlog e Sprint Backlog para demonstrar de escopo do projeto.
✓ Sprint Review e Retrospective Meeting como marcos de fim de Sprint e

validação constante de viabilidade do projeto.
✓ Impediment Backlog como forma de criação e manutenção de riscos do

projeto.
Mapeamento para GPR e GRI
Product Scrum Developme

Owner Master nt Team
Agile Radiator - BurnDown
Daily Scrum
Impediment Backlog
Sprint Planning 1
Sprint Planning 2
Sprint Review
Retrospective Meeting
Ideal Day / Story Points – Business Value
Product e Sprint Backlog
Planning Poker
Equipes multidisciplinares e auto-organizadas
Velocidade de equipe
WWW e WCBI
GRE – Gerência de Requisitos:
Propósito: gerenciar os requisitos dos produtos e componentes do produto do

projeto, e identificar inconsistências entre os requisitos, os planos do projeto e os
produtos de trabalho do projeto. O principal objetivo é controlar a evolução dos
requisitos gerenciando todos os requisitos recebidos ou gerados pelo projeto,

incluindo requisitos funcionais e não funcionais, bem como os requisitos impostos ao
projeto pela organização. Outras atribuições do processo são documentar as
mudanças nos requisitos e suas justificativas, bem como manter a rastreabilidade
bidirecional entre os requisitos e produtos de trabalho em geral e identificar
inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do
projeto.
DRE – Desenvolvimento de Requisitos:
Propósito: O propósito do processo Desenvolvimento de Requisitos é

estabelecer os requisitos dos componentes do produto, do projeto e do cliente. Os
requisitos do cliente são refinados e descritos em termos técnicos, originando os
requisitos funcionais e não funcionais do produto e dos componentes do produto. Uma
definição desses requisitos, bem como dos cenários e conceitos operacionais
requeridos, também deve ser elaborados em um nível de detalhe que permita a
realização de projetos técnicos e a construção da solução do software para resolver
o problema em questão.
PCP – Projeto e Construção de Produto:
Propósito: O propósito do processo Projeto e Construção do Produto é

projetar, desenvolver e implementar soluções para atender aos requisitos. Além disso,
deve definir atividades que permitam a elaboração do projeto (design) do software e,
também, possibilitem a implementação da solução de projeto (design) para os
requisitos em questão.

mapeiam para as REPs e RAPs do processo GRE, DRE e PCP.
Por exemplo:
✓ Gerenciamento dos requisitos do projeto através da criação e manutenção dos

épicos, temas e do Product e Sprint Backlog.

✓ Reuniões de planejamento de Sprints – Sprint Planning 1 e 2 – para validação
dos requisitos levantados e comprometimento técnico.
✓ Para atender a REP de mudança de requisito, utilização da solicitação leve de

mudança – LightWeight Change Request.
✓ Utilização de Épicos se transformando em itens de Product Backlog se

desdobrando em itens do Sprint Backlog para refinamento de requisitos.
✓ Utilização do IDEA para prototipação e projeto antes do desenvolvimento

propriamente dito.
✓ Reuniões de planejamento de Sprints – Sprint Planning 2 – quando são

definidas as atividades que possibilitem a implementação da solução.
✓ Sprint Backlog – atividades que implementam os projetos necessários.
Mapeamento para GRE, DRE e PCP
Product Owner Scrum Master Development

Team
Épicos
Temas
IDEA
Sprint Planning 1
Sprint Planning 2
LightWeight Change Request
Aceitação de
requisitos
Propriedade coletiva de código
MED – Medição:

Propósito: coletar, analisar e relatar os dados relativos aos produtos
desenvolvidos e aos processos implementados na organização e em seus projetos,
de forma a apoiar os objetivos organizacionais. A medição tem como principal foco
apoiar a tomada de decisão em relação aos projetos, processos e atendimento aos
objetivos organizacionais. Nos níveis iniciais, a medição está focada em apresentar
dados do projeto e processo e, nos níveis mais avançados, ela irá predizer tendências
da qualidade. Assim, a organização poderá antever solução para melhoria de
processos, mesmo antes de problemas acontecerem.

mapeiam para as REPs e RAPs do processo MED.
✓ Indicadores em geral de planejamento e acompanhamento de projetos –

velocidade de equipe e Agile Radiator.
✓ Reunião de lições aprendidas – Retrospective Meeting – quando os

indicadores devem ser apresentados aos envolvidos.
✓ Medidas de estimativa – Ideal Day e Story Points – para tamanho dos

requisitos.
✓ Business Value para medida de valor de negócio.
Mapeamento para MED

Team
Agile Radiator - BurnDown
Velocidade de equipe
Ideal Day / Story Points – Business Value
GCO – Gerência de Configuração:

Propósito: estabelecer e manter a integridade de todos os produtos de
trabalho de um processo ou projeto, e disponibilizá-los a todos os envolvidos. A
Gerência de Configuração é a disciplina responsável por controlar a evolução de
sistemas de software. A Gerência de Configuração não se propõe a definir quando e
como devem ser executadas as modificações nos produtos de trabalho, papel este
reservado ao próprio processo de desenvolvimento de software. A sua atuação ocorre
como processo auxiliar de controle e acompanhamento.
ITP – Integração de Produtos:
Propósito: O propósito do processo Integração do Produto é compor os

componentes do produto, produzindo um produto integrado consistente com o projeto,
e demonstrar que os requisitos funcionais e não funcionais são satisfeitos para o
ambiente alvo ou equivalente. O processo Integração do Produto diz respeito,
portanto, a como integrar um produto e qual a sequência de integração a ser usada.
Trata, também, da criação de um ambiente operacional no qual se possa implantar o
produto satisfatoriamente; da documentação dos procedimentos e critérios de
integração do produto; de como assegurar a integração correta das partes; e da
entrega do produto.

mapeiam para as REPs e RAPs do processo GCO e ITP:
✓ LightWeight Change Request mapeando para as solicitações de mudança

necessárias para este processo.
✓ Integração Contínua como prática para garantir a integridade entre os

artefatos.
✓ Equipes multidisciplinares e auto-organizadas sendo capazes de trabalhar em

equipe e promover a integração entre os produtos.

Mapeamento para GCO e ITP

Team
Integração Contínua
LightWeight Change Request
GQA – Garantia da Qualidade:
Propósito: assegurar que os produtos de trabalho e a execução dos

processos estejam em conformidade com os planos e recursos predefinidos. Agrega
valor à equipe de projeto, ajudando-a à preparar e rever procedimentos, planos e
padrões, desde o início do projeto até o seu encerramento. Os objetivos principais
desse processo são: avaliar objetivamente os processos executados, produtos de
trabalho e serviços em relação à descrição de processos aplicáveis, padrões e
procedimentos; identificar e documentar itens de não conformidades; prover feedback
para a equipe do projeto e gerentes como resultado das atividades de Garantia da
Qualidade; e assegurar que as não-conformidades são corrigidas.
VER – Verificação:
Propósito: O propósito do processo Verificação é confirmar que cada serviço

e/ou produto de trabalho do processo, ou do projeto, atende apropriadamente os
requisitos especificados.
VAL – Validação:
Propósito: O propósito do processo Validação é confirmar que um produto ou

componente do produto atenderá a seu uso pretendido quando colocado no ambiente
para o qual foi desenvolvido. Validação é a confirmação, por exame e fornecimento

de evidência objetiva, de que os requisitos específicos, para um determinado uso
pretendido, são atendidos. Garantir que o produto correto está sendo desenvolvido.

mapeiam para as REPs e RAPs do processo GQA, VER e VAL:
✓ Revisão por pares é um método estático de verificação no qual um artefato é

examinado por qualquer integrante da equipe do projeto, exceto o autor do
artefato, com o propósito de detectar defeitos.
✓ Testes de toda a natureza (aceitação, regressão, etc.) e até mesmo TDD, para
auxiliar no processo de Verificação de Requisitos.
✓ Testes de aceitação para auxiliar no processo de Validação de Requisitos.
✓ Reunião de revisão - Sprint Review – quando ocorre a validação oficial dos

requisitos, quando o escopo do Sprint é apresentado e as expectativas são
alinhadas.
Mapeamento para GQA, VER e VAL

Team
TDD
Testes Funcionais, etc.
Teste de Aceitação
Sprint Review

GRH – Gerência de Recursos Humanos:
Propósito: O propósito do processo Gerência de Recursos Humanos é prover

a organização e os projetos com os recursos humanos necessários, e manter suas
competências consistentes com as necessidades do negócio. Auxilia na
disponibilização de pessoal qualificado e experiente para desempenhar diversos
processos a fim de atingir os objetivos da organização.

mapeiam para as REPs e RAPs do processo GRH:
✓ Reunião de planejamento – Sprint Planning 1 – quando o gerente de RH pode

participar e verificar se as competências necessárias para se desempenhar o
papel no projeto estão adequadas. Ele pode buscar treinamentos, coaching,
etc.
✓ Gestão de conhecimento:
‒ Pair Programming para compartilhamento de conhecimento;
‒ Equipes multidisciplinares e auto-organizada;
‒ Propriedade coletiva de código.
✓ Reunião de lições aprendidas – Retrospective Meeting – para

compartilhamento de informações (WWW e WCBI) e aprendizado em geral.

Mapeamento para GRH
Product Owner Scrum Master Development Team
Sprint Planning 1
Pair Programming
GRU – Gerência de Reutilização:
Propósito: O propósito do processo de Gerência de Reutilização é gerenciar

o ciclo de vida dos ativos reutilizáveis. Gerenciamento do ciclo de vida dos ativos
reutilizáveis de uma organização - procedimentos administrativos e técnicos de
armazenamento, recuperação e divulgação de ativos.
DRU – Desenvolvimento para Reutilização:
Propósito: O propósito do processo de Desenvolvimento para Reutilização é

identificar oportunidades de reutilização sistemática na organização e, se possível,
estabelecer um programa de reutilização para desenvolver ativos a partir de
engenharia de domínios de aplicação. É a especificação, projeto e implementação de
ativos de domínio que atendam a famílias de aplicações ou a domínios de
conhecimento específicos.

mapeiam para as REPs e RAPs do processo GRU e DRU.

✓ Técnicas para criação de uma gestão de conhecimento eficaz na organização,
a fim de servir de alicerce para práticas de reutilização em geral.
Mapeamento para GRU e DRU
Pair Programming
AMP – Avaliação e Melhoria do Processo Organizacional:
Propósito: O propósito do processo Avaliação e Melhoria do Processo

Organizacional (AMP) é determinar o quanto os processos padrões da organização
contribuem para alcançar os objetivos de negócio da organização, e para apoiar a
organização a planejar, realizar e implantar melhorias contínuas nos processos, com
base no entendimento de seus pontos fortes e fracos.
DFP – Definição do Processo Organizacional:
Propósito: O propósito do processo Definição do Processo Organizacional

(DFP) é estabelecer e manter um conjunto de ativos de processos organizacionais, e
padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio
da organização. Essa é a definição de processos organizacionais e processos
especializados para reúso de ativos.

mapeiam para as REPs e RAPs do processo AMP e DFP.

✓ Artefatos e cerimônias do Scrum para criação e manutenção do projeto de
melhoria de processos.
Mapeamento para AMP e DFP
WWW e WCBI
PlayBook para adoção do Scrum:
Passo 0 – Preparação da empresa:
É necessário definir um plano inicial do projeto de implantação e

acompanhamento do Scrum na organização com cronograma, atividades, recursos
envolvidos, marcos, etc. Dentro deste cronograma, também não se pode esquecer de
criar a atividade de prover treinamento para Product Owners, Scrum Masters e times
Scrum. Para isso, deve-se definir como será este primeiro contato: se será através de
treinamento formal externo, ou de coaching interno por um período determinado.
Também como outra atividade, é importante construir o Product Backlog em

projetos beta para avaliar impedimentos que possam ocorrer, e que servirá de base
para as mudanças dentro da organização.
Outro ponto essencial é estabelecer métricas para acompanhamento do

projeto, do novo processo e dos projetos piloto que estaram rodando este novo
processo.

Passo 1 – Experimentação dos projetos piloto:
Este passo é necessário para:
✓ Experimentar o processo em projetos reais para demonstrar os benefícios

positivos.
✓ Devem ter entre 3 e 6 iterações.
✓ Devem entregar incrementos de funcionalidades e identificar impedimentos.
✓ Devem criar planos de ajuste necessários.
✓ A cada fim de iteração, devem fazer as reuniões de retrospectiva avaliando

resultado da entrega, indicadores e impedimentos que surgiram.
✓ Devem entender os pontos que devem ser observados.
✓ Devem “desburocratizar” o novo processo de desenvolvimento de software

para adequar ao contexto organizacional.
Os Product Owners, Scrum Masters e o management devem estar atentos a

impedimentos organizacionais que surgirem neste momento. É necessário
categorizar os impedimentos, pois cada um requer diferentes habilidades de atuação.
Podem existir impedimentos do tipo:
1. Processo Scrum: que impedimentos estão ocorrendo que nos afastam do

processo Scrum? Exemplos:
‒ As pessoas chegam atrasados às reuniões;
‒ As reuniões levam mais tempo que o planejado;
‒ O Scrum Master dita questões técnicas e faz microgerenciamento;
‒ Time não atualiza o Agile Radiator.

2. Práticas dos envolvidos: que práticas estão ocorrendo que nos afastam de
desenvolver, suportar e usar produtos que maximizam o retorno? Exemplos:
‒ O time é interrompido e designado a trabalhar fora do Sprint;
‒ Times são isolados em uma sala;
‒ Membros estão envolvidos em diferentes projetos e times.
3. Práticas de Engenharia de Produtos: que práticas estão impedindo a

otimização de ROI ou de maximizar a missão da organização em relação à um
produto? Exemplos:
‒ O produto não é totalmente implementado e testado dentro do Sprint;
‒ Product Owner não está integrado ao time;
‒ Integração do sistema não faz parte do processo;
‒ Product Owner não refina o Product Backlog;
‒ Times não possuem membros para automatizar testes.
4. Questões organizacionais: que questões estão impedindo os times de entregar

software aos usuários mais rapidamente? Exemplos:
‒ Políticas de desenvolvimento de software levam a um processo

ineficaz;
‒ A alta gestão assume prazos, preço e funcionalidade fixos;
‒ A organização premia indivíduos e não times.
Para cada impedimento encontrado, deve-se identificar:
✓ Impacto do impedimento para o projeto – 0 (mais baixo) a 9.

✓ Custo para resolver o impedimento – 0 a 9.
✓ Responsável por resolver: Alta gestão, Product Owner, Scrum Master,

Development Team, etc.
Passo 2 – Comunicar resultado dos projetos piloto:
Além de rodar em projetos piloto, não se pode esquecer de comunicar

resultados dos projetos piloto aumentando a visibilidade e comunicando a situação
dos projetos que rodam Scrum em Agile Radiator.
Outra boa iniciativa é criar um portal para acesso à livros e artigos, para
encorajar a expansão do conhecimento sobre o assunto por toda a organização.
Passo 3 – Expansão na organização:
Após rodar em projetos piloto, é necessário expandir o uso do Scrum e seus

benefícios em outras áreas da organização. Dessa forma, deve-se procurar rodar o
mesmo processo definido em projetos de diferentes tamanhos e áreas, envolvendo
um maior número de envolvidos.
Passo 4 – Medir para criar planos de ajuste:
Há dois tipos de métricas que devem ser utilizadas:
✓ Métricas de processo:
‒ Indicadores qualitativos para medir a eficácia dos times em adotar

Scrum.

✓ Métricas de projeto:
‒ Indicadores para medir os resultados de um time Scrum em particular.

Alguns exemplos: número de defeitos, percentual de código coberto
com cobertura de testes de unidade, com testes de regressão, número
de itens do Product Backlog terminados, etc.

Passo 5 – Continuar a expansão:
Este passo busca manter a expansão do uso do Scrum dentro da

organização, visando a melhoria contínua do processo - escalar o seu uso para
diferentes áreas. Melhoria contínua e inspeção/adaptação ao novo processo.
Como escalar o Scrum?
Development Teams of Teams: Uma "Scrum de Scrums" é o mecanismo

usual que permite coordenar múltiplos times trabalhando em um único projeto. Uma
Scrum de Scrums é uma reunião diária (Daily Scrum) na qual participa um membro
de cada time em um projeto que envolve mais de um time.
Durante o planejamento do projeto, o trabalho é cuidadosamente analisado e

dividido entre os times para evitar ao máximo que haja dependências. Os times então
trabalham em partes da arquitetura do projeto que são ortogonais umas às outras.
Este mecanismo é eficiente somente quando há acoplamentos ou dependências
pequenos que requerem uma solução.
Em alguns casos, os projetos são tão complexos que requerem algo mais do
que uma implementação normal do Scrum. O Scrum "tradicional" não possui práticas
que endereçam as complexidades de todos os tipos de projetos. No entanto, a teoria
que fundamenta o Scrum deve ser resgatada pelo Scrum Master para que possa
encontrar as adaptações necessárias em cada caso.

O Scrum tem sido aplicado também à grandes projetos. Porém, os times
Scrum devem respeitar o tamanho (7+-2) e estarem em uma sala comum. Para isso,
é preciso decompor a arquitetura do produto em subsistemas que são capazes de
entregar BV de valor sozinhas. Abaixo, figura que demonstra três times construindo
um subsistema (parte de um sistema) em uma release de 3 Sprints.
CIO Playbook For Adopting Scrum
Fonte: Rally Software Development Corporation and Ken Schwaber-Scrum

Alliance.
Principais problemas decorrentes do escalonamento:
✓ Quando maior o número de equipes, maiores os desafios de gerenciamento e

comunicação entre os times. Maiores dificuldades:
‒ Reuniões.
‒ Integração entre subsistemas.
‒ Atividades de testes.
‒ Alinhamento.

Mas como coordená-los?
Criando um time do sistema: arquitetos, líderes de times, gerentes de produto

e equipe de garantia da qualidade que podem formar uma equipe para pensar e agir
como integradores. Devem utilizar o processo Scrum para criar atividades de
integração de subsistemas, demonstrações do sistema, criação de pontos de
qualidade e distribuição para assegurar que o sistema está indo conforme o
planejado.
Para resolver problemas de comunicação, ter um mecanismo de sincronismo

entre os trabalhos é essencial.
Para o gerenciamento do Product Backlog é interessante que seja utilizado

uma ferramenta para que todos conheçam a meta e escopo do projeto. A elaboração
e comunicação dos requisitos nesta ferramenta proporciona uma maior formalização
e seu versionamento. Além disso, todas as mudanças nos requisitos devem ser
armazenadas.
Para a visibilidade do andamento: o time irá precisar de uma ferramenta para

a entrada de tarefas completadas, horas restantes e burndown automatizado para
conseguir um resultado único e atual do andamento dos trabalhos.
Outro fator importante na coordenação é a utilização de testes: testes de

regressão automatizados são essenciais para a constante integração entre equipes.
Scrum Smells e erros mais comuns em equipes ágeis:
Esta seção é dedicada a explicar quais são os principais indícios de que o

Scrum não está sendo aplicado de forma efetiva dentro da organização. Pontos a
serem cuidadosamente observados:
✓ Perda de ritmo:
‒ Como verificar: os Sprints não têm a mesma duração.

‒ O problema: a finalização do sprint é definida por forças externas. Isso
dificulta o comprometimento do time em relação a selecionar itens do
PB.
✓ “Chicken” interrompendo:
‒ Como verificar: “chickens” participando do Daily Scrum perguntando e

fazendo observações.
‒ O problema: durante o Daily Scrum, somente “pigs” podem falar,

“chickens” podem somente observar. Este comportamento pode resultar
em interrupções desnecessárias.
✓ “Pigs” faltando:
‒ Como verificar: “pigs” não presentes em uma reunião de Daily Scrum.
‒ O problema: faz com que o Daily Scrum não ocorra diariamente e no

mesmo horário -> dificulta a manutenção do ritmo.
✓ Scrum Master delegando trabalho:
‒ Como verificar: o Scrum Master está delegando o trabalho no lugar de

dos próprios desenvolvedores.
‒ O problema: o conceito de auto-organização não está sendo respeitado.
✓ O Daily Scrum é para o Scrum Master:
‒ Como verificar: O Daily Scrum é encarado como feedback para o Scrum

Master.
‒ O problema: o Daily Scrum deve ser de todos! É mais um momento para

cada um do time se comprometer perante seus pares.
✓ Time especializado:

‒ Como verificar: o time tem cargos especializados como arquiteto,
designer, DBA, etc.
‒ O problema: perda do espírito de equipe e de comprometimento em

tarefas que ele não se considera responsável.
Todos estes pontos devem ser observados para que sejam cumpridos em
equipes Scrum. Após anos gerenciando equipes Scrum, estes foram os principais
problemas observados que influenciam no resultado final do trabalho. Além disso,
Henrik Kniberg levantou outros problemas mais comuns entre as equipes ágeis em
2008, assim categorizados:
✓ Bala de prata:
‒ Acreditar que todos os problemas serão resolvidos se utilizarmos um

método ágil.
‒ Focar na perfeição do processo e de que tudo tem que dar certo desde
o princípio.
‒ Focar na ferramenta e acreditar que ela será a solução.
✓ Definição de Done:
‒ Não ter a definição.
‒ Não a obedecer.
‒ A equipe não tem como resolver.
✓ Velocidade:
‒ Não é medida.
‒ Existe trapaça na medição - não são consideradas variáveis essenciais.

‒ Velocidade iô-iô – instável.
✓ Retrospectiva:
‒ Não acontece.
‒ Não resulta em melhorias – mudanças não são executadas e se forem,

não são verificadas.
‒ Penalização pelo WCBI.
✓ Comprometimento:
‒ Equipe pressionada – gerentes que não estimulam e que não interagem.
‒ Equipe desunida.
‒ Equipe que não consegue entregar.
‒ Pouco comprometimento.
✓ Trabalho em equipe:
‒ Papéis fixos.
‒ Itens de backlogs que não são coletivos.
‒ Pouca colaboração entre a equipe.
‒ Incentivos pessoais.
‒ Interferência externa.
✓ Integração de código fonte:
‒ Não há branch pronto.
‒ Não há regras de criação e integração de branches.

‒ Integração pouco frequente.
✓ Information Radiator:
‒ Não existe.
‒ Muito longe da equipe.
‒ Muito sofisticado e pouco útil.
‒ Não é atualizado diariamente.
‒ Não são feitas ações quando pontos de alerta são atingidos.
✓ Product Backlog e Product Owner:
‒ Não há.
‒ Não está visível.
‒ Backlog grande e que nunca tem fim.
‒ PO sem conhecimento do negócio.
‒ PO surpreendido no Sprint Review.
E quando o Scrum não funciona?
Mesmo com todos estes pontos observados, o Scrum não funciona. O que
fazer?
✓ Investigar se o Scrum está sendo utilizado de forma incorreta:
‒ Tomar cuidado ao acreditar que o Scrum puro é sempre a melhor

solução - Scrumdamentalism. Lembrar-se da lei de Frederick Brooks –
“There is no Silver Bullet”.

‒ Após verificar se o Scrum está sendo bem utilizado, mas o projeto
parece continuar falhando, o que fazer?
✓ Se o processo estiver ok, verificar se o Scrum está causando o problema:
‒ O Scrum é projetado para expor problemas. Por isso, não mate o

mensageiro.
‒ Scrum trouxe à tona que algo em seu projeto não era viável. Concentre-
se em resolver o problema.
Mas e se o problema parece ter sido causado pelo Scrum?
✓ É necessário rodar alguns Sprints para que o time se ajuste e comece a

efetivamente colaborar. Leva tempo para que a equipe erre e consiga aprender
com os erros.
‒ Pessoas impacientes podem chegar à conclusão de que o Scrum não

funciona. “Quando se está aprendendo a tocar guitarra e o som ainda
não parece estar muito bom, não significa que o instrumento não
funciona. Somente significa que você deve continuar praticando e
verificar a melhoria que ocorre ao longo do tempo.”
Mas e se já rodou diversos Sprints e o time ainda não conseguiu entregar?
✓ Caso você não tenha desanimado e venha fazendo vários Sprints de maneira
correta, talvez seja necessário adaptar parte do processo ao seu contexto
organizacional.
‒ Enfrentando o mesmo problema e não efetuando mudança -

sadoscrumism: crença de que a dor exposta pelo Scrum é sempre “boa”.
‒ Sim, você pode mudar o Scrum e deve fazê-lo caso tenha passado por
todos os passos acima.

Mas você efetuou as mudanças e ainda parece não estar funcionando?
✓ Após efetuar a mudanças:
‒ Há alguns contextos em que o Scrum não é realmente apropriado. É o

processo errado para um tipo de situação. Em projetos de manutenção,
prioridades mudam constantemente, e por isso, talvez o melhor
caminho seja utilizar Kanban.
Por fim, não culpe a ferramenta! São as pessoas que tomam decisões!
Gestão 3.0 – Expansão do agile nas organizações
É uma expansão do conhecimento do Scrum dentro das organizações. É

focada na complexidade e relacionada a imprevisibilidade. Prega que é necessária
uma gestão que auxilie e trabalhe em conjunto, e que a alta gestão (management) é
o maior obstáculo na transição para o desenvolvimento ágil. Por isso, seu novo papel
deve ser bem entendido. Não só o time Scrum precisa entender Agile, a organização
também.
Encare as organizações como redes e não como hierarquias. Pessoas e seus

relacionamentos deverão ser cuidadosamente estudados!
Acredite que Scrum Masters devem ser incentivadores da mudança, levando

a organização a alcançar melhores resultados. Além de gerenciar o processo Scrum
– o que já fazem normalmente, devem também permear as camadas de gestão
organizacional. Devem ajudar a empresas a mover-se para a gestão 3.0.
A pesquisa anual The State of Agile – resultado completo abaixo - apresenta

em seu relatório que os principais obstáculos para uma boa adoção de Agile nas
organizações são: sua cultura, a resistência a mudança, desenvolvimento de
competências e apoio da gestão. É aí que entra mais uma habilidade a ser
desenvolvida por Scrum Masters: eles devem ajudar a organização à entender o que

é ser ágil e quais são os benefícios que irão retornar. Além disso, considera-se que
gerentes organizacionais devem estar preparados para a mudança e precisam obter
as competências necessárias para o trabalho.
Dado este problema, a gestão 3.0 sugere que a gestão trabalhe com seis
visões:
Management 3.0 - Jurgen Appelo
Energizar pessoas:
Gerentes devem promover ações que gerem motivação, instiguem a

criatividade e mantenha as pessoas ativas.
‒ Comportamento = f (P,E)
O comportamento é uma função da personalidade

do indivíduo e de seu ambiente.
Kurt Lewin

Portanto, não sendo possível mudar a personalidade das pessoas, consegue-
se mudar seu comportamento através de mudanças no ambiente!
✓ Fatores que podem gerar motivação nas equipes:
‒ Promover reconhecimento imediato de boas ações.
‒ Celebrar SEMPRE os objetivos alcançados!
‒ Prover alinhamento das metas sendo estes relevantes, realistas,

simples, mensuráveis e com prazo factível!
‒ Dar poder de decisão à equipe.
‒ Criar metas desafiadoras e deixar que a equipe encontre formas de

implementá-las.
Dar poder aos times:
É necessário delegar, distribuir autoridade e controle, e ainda depositar real

confiança por parte da gestão após tomar estas ações. Os times devem se auto-
organizar e utilizar de criatividade na execução das atividades recebidas.
Um ponto importante: autoridade não é só relativa ao desenvolvimento de

software, mas também envolve outras questões, como de contratação, decisão de
compra de equipamentos, etc.
Esta é a verdadeira implementação do “Jogo de soma diferente de zero”, uma

vez que busca a melhor solução para todos os envolvidos e pratica o real trabalho em
equipe.
Times que trazem resultados positivos fazem seus gerentes também serem
bem-sucedidos. Todos saem ganhando, pois, o controle delegado aos times se
transforma em motivação e comprometimento, trazendo reais ganhos para a
empresa. Delegar não torna a gestão mais fraca, não é um jogo ganha-perde. É
ganha-ganha. Times poderosos fazem seus gerentes ainda mais poderosos.

Existem sete níveis de delegação:
✓ Dizer: você toma decisões e comunica.
✓ Vender: você toma decisões, mas tenta vender sua ideia para o time.
✓ Consultar: você convida o time a participar de uma decisão.
✓ Concordar: você convida o time a participar de uma discussão para que

cheguem a um consenso – todos têm o mesmo peso!
✓ Aconselhar: você tende a influenciar o time dando conselhos, mas permite que
decidam.
✓ Questionar: você permite que o time decida e depois fica atento ao caminho
seguido e pede que o mantenham informado.
✓ Delegar: você dá todo o controle ao time e não necessita saber que decisão foi
tomada.
Segue abaixo exemplo dos níveis de delegação retirado do livro Management

3.0 de Jurgen Appelo:

Alinhar as restrições:
A gestão 3.0 tem também como objetivo transformar um grupo de indivíduos

em um time com uma missão. Para isso, defende a definição, comunicação e
distribuição real de um propósito claro e metas compartilhadas alinhadas pela gestão
da organização.
Desenvolver competências:
A atenção ao desenvolvimento de competências deve ser contínua por parte

da gestão. Times que não conseguem atingir metas devem ser monitorados com
relação à suas habilidades.
Crescer estrutura de comunicação:
É importante considerar estruturas que promovam a comunicação, dado o

contexto organizacional complexo atual. A gestão deve criar formas simples que
proporcionem uma comunicação efetiva.
Times se unindo periodicamente para trocar experiências, definir padrões,

etc.

Melhorar continuamente!
Indivíduos, times e organizações devem melhorar continuamente para evitar

falhas. Para isso, reflexões são necessárias para prevenir que problemas se tornem
maiores e mais difíceis de resolver se acompanhados tardiamente.
Certificações Scrum:
Há duas grandes instituições: Scrum Alliance (SA) x Scrum.org.
Scrum Alliance tem hoje Mike Cohn como Chairman – fundado em 2002,
enquanto Scrum.org tem o Ken Schwaber fundado em 2010 – uma organização com
maior participação da comunidade. Abaixo, o pacote da Scrum Alliance para
certificações:
Certificações Scrum Alliance:
✓ Certified Scrum Master (CSM): treinamento sobre o framework, os

mecanismos e papéis do Scrum. Taxa de US$ 50, válida por 2 anos. Instrução
e exercícios em times.

✓ Certified Scrum Product Owner (CSPO): treinamento com o objetivo de tornar
efetivo o papel de Product Owner em projetos ágeis, através de otimização de
resultados de sua equipe e a satisfação de seu cliente.
✓ Certified Scrum Developer (CSD): treinamento similar ao do Scrum.org, mas

conjugado com outros, como CSM – mínimo de três dias de desenvolvimento
de software (técnico), um dia de introdução de Scrum + um dia de um
treinamento que pode ser escolhido de acordo com seu skill/papel que
desempenha. Taxa de US$ 150, válida por dois anos.
✓ Certified Scrum Professional (CSP): credencial para CSMs, CSPOs e CSDs,

que atesta a experiência do profissional na prática do Scrum. Mínimo de um
ano de prática Scrum. Deve ter alguma das certificações acima e CSP
application package, que será revisada por um comitê. Se aprovado, taxa de
US$ 250,00 por dois anos e depois, recertificação.
✓ Certified Scrum Trainer (CST): credencial para ministrar cursos de CSM e

CSPO. Precisa ser um CSP. Tem que atender a algumas premissas para ser
aprovado e passa por um comitê para sua aprovação. No mínimo cinco
referências de outros CSTs, entrevistas e experiência em treinamento e
coaching.
✓ Certified Scrum Coach (CSC): credencial de CSPs para fazer coaching que
guiam as pessoas que utilizam Scrum – na teoria e prática. Válida por três anos
– taxa anual de US$ 750,00. Mínimo de 1500 horas de coaching em Scrum e
duas cartas de recomendação de clientes.
O Scrum.org surgiu mais tarde trazendo novas certificações e lutando contra “Flacid
Scrum”.
“Em 2009, havia mais de 60.000 CSMs. Entretanto, menos de 50% dos que
usam Scrum estavam desenvolvendo em iterações incrementais, que são o cerne do
Scrum.” (Martin Fowler)

Ou seja, times estão usando o vocabulário Scrum mas não são capazes de
entregar incrementos de software em um único sprint.
Para isso, a Scrum.org resolveu:
✓ Criar o Scrum Developer Program: foco também nos desenvolvedores, apesar

de ser uma prática de gerenciamento.
✓ Formalizar o Scrum body of knowledge – remodelo do guia, contendo apenas

as regras do Scrum, deixando para outras literaturas catalogar estratégias e
outras dicas.
✓ Melhorar a qualidade e consistência dos treinamentos CSTs.
✓ Lançar processos modificações e extensões com participação da comunidade.

▪ Novas avaliações da Scrum.org para Scrum Masters:
✓ Scrum Open Assessment – free e disponível em https://www.scrum.org/open-

assessments/scrum-open/.
✓ Professional Scrum Master I (Fundamental) Assessment – sem necessidade

do PSM.
✓ Professional Scrum Master II (Intermediate) Assessment – PSM + Assessment

(US$ 500).
▪ Novas avaliações Scrum.org para Product Owners:
✓ Professional Scrum Product Owner (Fundamental) Assessment – necessário

PSPO.
✓ Professional Scrum Product Owner II (Intermediate) Assessment – PSPO +

Assessment (US$ 500).
✓ Mínimo 85% de acerto.

▪ Novas avaliações Scrum.org para Developers:
✓ Professional Scrum Developer Assessment – necessário PSD Java ou .Net.
✓ Mínimo 90% de acerto.
Certificações Scrum.org:
✓ Professional Scrum Foundation (PSF): treinamento introdutório do Scrum que

serve de base de conhecimento para os demais treinamentos - de dois dias e
público-alvo diverso.
✓ Professional Scrum Master (PSM): treinamento tido como a primeira

atualização significativa do curso de Certified Scrum Master (CSM). Prova
pode ser feita sem o curso (85% de acerto) e custa US$ 100 – PSM I. Duração
de 60 minutos.
‒ Curso em torno de R$ 1.200,00 (16 horas).
‒ Prova intermediária PSM II – taxa de US$ 500 e 120 minutos de

duração.
✓ Professional Scrum Product Owner (PSPO): treinamento que ensina como

maximizar o retorno de investimento (ROI) e otimizar o custo total de
propriedade (TCO) de produtos ou sistemas. Tem uma prova associada ao
curso (valor incluso) de 60 minutos.

✓ Professional Scrum Developer (PSD): treinamento para ensinar
desenvolvedores a usar práticas de engenharia de software para desenvolver
incrementos de software prontos para serem entregues.
‒ .Net ou JEE.
‒ Prova associada:

Certificação PMI-ACP
PMI Agile Certified Practitioner (PMI-ACP). Nova certificação Agile para GPs
que utilizam práticas ágeis em seus projetos.
https://www.pmi.org/certifications/types/agile-acp
Não precisa ser um PMP, mas precisa ter 2000 horas em times de projetos
nos últimos 5 anos. Deve ter comprovado 1500 horas em times de projetos ágeis nos
últimos 2 anos adicionais às 2000 acima. Deve ter feito treinamento em tópicos de
gerenciamento de projetos ágeis de no mínimo 21 horas e deve fazer prova para
atestar fundamentos ágeis. A prova contém 120 questões de múltipla escolha com
duração de 3 horas e seu conteúdo tem assuntos variados das metodologias ágeis
como Scrum, Kanban, XP, Lean, FDD, etc.
Vantagem Competitiva do Scrum para Contratos de Preço Fixo e Prazo Fixo
Uma dúvida comum quanto ao uso do Scrum em organizações que lidam com
concorrências para contratos de preço fixo e prazo fixo, diz respeito à como a empresa
deve estruturar sua proposta para aderir à solicitação de proposta (RFP - Request for
Proposal) em questão, de forma competitiva e atraente para o proponente.
Em [1], Ken Schwaber apresenta uma possível abordagem para tornar

competitiva uma proposta baseada no Scrum, que pode ser resumida nos seguintes
aspectos:
• Incluir na proposta o Product Backlog, obtido a partir do entendimento dos

requisitos da RFP e sua decomposição em arquiteturas e funcionalidades.

• O Product Backlog será utilizado não somente para demonstrar que os requisitos
foram entendidos, mas também demonstrar que a empresa entendeu a prioridade
dos requisitos em termos de geração de valor para o negócio.
• O processo de desenvolvimento deve ser descrito como iterativo e incremental,

no qual, ao invés de entregar o sistema todo de uma vez, o sistema será
desenvolvido e entregue incremento por incremento.
• Esta abordagem deve ser justificada indicando suas vantagens, por exemplo, a
validação mensal para assegurar que o projeto está na linha e o produto está
atendendo às necessidades de negócio do cliente; a possibilidade de mudança
para os requisitos ainda não selecionados para trabalho em uma Sprint; etc.
• Como conclusão, indicar que, conforme ocorre em muitos casos, 80% do valor do
sistema está contido em 20% de suas funcionalidades; desta forma, a empresa
proponente terá à sua disposição grande fatia do valor de negócio do sistema, em
um prazo significativamente reduzido.
É importante notar que, em alguns casos, a organização requisitante pode

não estar preparada para compreender ou aceitar uma abordagem desta natureza.
Scrum Q&A
Como fazer para evitar explosão de escopo em projetos usando o Scrum?
Para contratos de preço fixo, uma questão natural que surge é como deve ser
utilizado o Scrum ou que recursos este oferece para evitar que haja uma explosão de
escopo, caracterizada por excesso de mudanças e incorporação sem fim de novos
requisitos.
Não existe, nesse caso, bala de prata. Se o mecanismo de contratação não

prevê uma abordagem iterativa e incremental a partir de uma lista de requisitos
relativamente detalhada (Product Backlog), o caminho é trabalhar um detalhamento
inicial do projeto até o ponto em que seja possível o controle do escopo. Ou seja,

introduzir uma fase inicial ao Scrum, na qual haveria produção de documentação
sobre os requisitos e arquitetura em um nível de detalhe que permita a delimitação do
que corresponde, e do que não corresponde ao escopo do projeto.
Quais papéis do Scrum podem ser executados por uma mesma pessoa?
Idealmente, cada papel do Scrum deve ser executado por pessoas diferentes,
sendo que o time deve ter entre 5 e 9 pessoas. O Scrum Master fazer parte do time
ou o Product Owner fazer parte do time são cenários ruins, porém menos drásticos
do que o Scrum Master e o Product Owner serem a mesma pessoa, porque nesse
caso haveria muito poder centralizado em uma única pessoa.
Se a reunião de revisão da Sprint é informal, como é obtido o aceite das

funcionalidades entregues?
Na reunião de revisão da Sprint, o Product Owner deve informar à equipe se

a meta da Sprint foi ou não atingida.
Qual a diferença de Scrum e RUP? O que o Scrum traz de novo?
Scrum apresenta um framework simples, adaptável a cada empresa, que

deve complementar diversos pontos do seu processo de produzir software buscando
elementos fora do Scrum. O Scrum não se propõe a ser uma metodologia completa,
que diga a todo momento o que deve ser feito.
Como é o gerenciamento de riscos em projetos Scrum?
O Scrum não prevê um mecanismo formal de gerenciamento de riscos, porém

também não determina que este não possa ser realizado, utilizando as diversas
técnicas disponíveis no mercado.
O que o Scrum oferece para garantir que um sistema de software

complexo seja desenvolvido atendendo adequadamente aos requisitos
arquiteturais, uma vez que estes não são corretamente identificados pelo
cliente/Product Owner?

Itens técnicos/arquiteturais podem ser adicionados ao Product Backlog por
iniciativa do time, que deve, nestes casos, expor e convencer o Product Owner da
importância e prioridade do item para o negócio. Caberá ao Product Owner, em última
instância, definir a prioridade deste item no backlog.
Qual deve ser o tamanho ideal de um Time Scrum? Que competências devem
ser atendidas por este time?
O Scrum sugere um time de 5 a 9 pessoas, porque foram tentados outros

tamanhos de time e os melhores resultados foram obtidos de 5 a 9 membros. Esta é
uma das evidências do empirismo do Scrum. As competências necessárias à este
time serão fortemente dependentes do conceito de “pronto”, que será definido pelo
Product Owner, o Scrum Master e o time durante o estabelecimento da visão do
projeto. Geralmente, são necessários profissionais que sejam capazes de exercitar,
cada um em sua especialidade, as diversas disciplinas da Engenharia de Software.
Os times são multifuncionais e é fortemente recomendável que cada pessoa acumule
mais de uma competência, podendo ser útil durante todo o tempo da Sprint.
No Scrum não há o papel do gerente de projeto?
O termo "gerente de projeto" no Scrum foi intencionalmente suprimido para

enfatizar as diferentes responsabilidades que cabem ao líder do projeto, denominado
Scrum Master. Isso enfatiza a grande diferença de abordagem que os gerentes
deverão adotar, em relação aos padrões tradicionais de gerenciamento, para
poderem gerenciar um projeto com o Scrum.
O que fazer se, durante a primeira semana de uma Sprint, surgir uma
oportunidade de negócio que demanda uma resposta imediata da organização?
Se a oportunidade for realmente relevante a este ponto, a Sprint atual pode ser
interrompida, em caráter excepcional, e uma nova reunião de planejamento da Sprint
deve ser conduzida para que os novos itens do backlog sejam endereçados pela
equipe.

Referências
AMBLER, Scott. Agile Modeling (AM): Effective Practices for Modeling and
Documentation. Disponível em: <http://www.agilemodeling.com/>. Acesso em: 06 jul.
2021.
APPELO, Jurgen. Management 3.0. Disponível em: <http://www.jurgenappelo.com/>.

Acesso em: 06 jul. 2021.
BOEHM, Barry. Get Ready for Agile Methods, with Care. Computer, 2002.
BOEHM, Barry; TURNER, Richard. Balancing Agility and Discipline: A Guide for the
Perplexed. Addison-Wesley Professional, 2003.
COCKBURN, Alistair. Agile Software Development. Cockburn Highsmith Series

Editors, 2000.
Control Chaos. Disponível em: <www.controlchaos.org>. Acesso em: 06 jul. 2021.
CRISP. Henrik Kniberg. Disponível em: <http://www.crisp.se/henrik.kniberg/>. Acesso

em: 06 jul. 2021.
FONSECA, I. ALVES, M. e ALVES, F. Ideal Day e Priorização?. 6. ed. ESM, 2008.
FONSECA, I. CAMPOS, A. Por que SCRUM?. 4. ed. ESM, 2008.
LARMAN, Craig. Agile and Iterative Development: A Manager’s Guide. Addison-

Wesley, 2004.
LEADING ANSWERS. Agile Project Management Assessment Quis. Dez. 2006.

Disponível em:
<http://leadinganswers.typepad.com/leading_answers/2006/12/agile_project_m.html
>. Acesso em: 06 jul. 2021.

Métrica de agilidade da organização. Disponível em:
<https://scalingsoftwareagility.files.wordpress.com/2008/01/team-agility-assessment-
in-pdf.pdf>. Acesso em: 06 jul. 2021.
Mike Cohn’s Blog & lt. Disponível em:

<http://blog.mountaingoatsoftware.com/?p=15&gt>. Acesso em: 20 abr. 2020.
PACHECO, Diego. Estimativa não Exatimativa!. Diego Pacheco Tech blog, ago. 2008.
Disponível em: <http://diego-pacheco.blogspot.com.br/2008/08/estimativa-no-
exatimativa.html>. Acesso em: 06 jul. 2021.
PAULK, M. C. Extreme Programming from a CMM Perspective. IEEE Software, 18,

2001.
Pesquisa Agile 2011 – The State of Agile (Version One). Disponível em:
<https://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Resul
ts.pdf>. Acesso em: 23 nov. 2020.
POPPENDIECK, Mary and Tom. Lean Software development. Addison-Wesley, 2003.
Processo de Desenvolvimento de Software da Powerlogic (PDS_P&D_v19).
SCHWABER, Ken. Agile Project Management with SCRUM. Microsoft Press, 2004.
SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with SCRUM.

Prentice Hall, 2001.
SCRUM (SOFTWARE DEVELOPMENT). In: WIKIPÉDIA, a enciclopédia livre.

Flórida: Wikimedia Foundation, 2021. Disponível em:
<https://pt.wikipedia.org/w/index.php?title=Scrum_(desenvolvimento_de_software)&
oldid=61423474>. Acesso em: 06 jul. 2021.
Scrum Alliance. Disponível em: <www.scrumalliance.org>. Acesso em: 06 jul. 2021.
SCRUM CARTOONS. Michael Vizdos. Disponível em:

<https://www.implementingscrum.com/cartoons/>. Acesso em: 06 jul. 2021.

Scrum.org. Disponível em: <http://www.scrum.org/>. Acesso em: 06 jul. 2021.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard
BusinessReview, 1986.
XP123. Exploring Extreme Programming. Disponível em: <http://xp123.com>. Acesso

em: 06 jul. 2021.

4 - Gestão Ágil de Projetos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

4 - Gestão Ágil de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento Ágil de Projetos com Scrum

Gerenciamento Ágil de Projetos com Scrum – Página 2 de 179

Capítulo 1. Introdução ............................................................................................... 5

Capítulo 2. Fundamentos do Scrum - Introdução às Metodologias Ágeis ............... 13

Manifesto Ágil¹ ................................................................................................... 15

Os doze princípios da Agilidade¹ ....................................................................... 15

Gestão Ágil e Desenvolvimento Ágil ..................................................................... 16

Fundamentos do Scrum .................................................................................... 18

Desenvolvimento Iterativo e Incremental ........................................................... 19

Lean Manufactoring ........................................................................................... 21

The New New Product Development Game ...................................................... 26

Teoria do Caos .................................................................................................. 29

Teoria dos Jogos ............................................................................................... 30

Teoria das Restrições ........................................................................................ 32

Capítulo 3. Métodos e Frameworks Ágeis ............................................................... 38

Capítulo 4. Framework Scrum ................................................................................. 50

Teste seu conhecimento! Mudança de paradigma ............................................... 58

Teste seu conhecimento! Cultura da organização ................................................ 59

Teste seu conhecimento! Motivação no trabalho .................................................. 64

Regras e Fluxo de Atividades do Scrum: .............................................................. 64

Artefato: Product Backlog ..................................................................................... 64

Sprint Planning Meeting 1: ................................................................................. 79

Sprint Planning Meeting 2 ..................................................................................... 83

Artefato: Impediment Backlog ............................................................................... 88

Gerenciamento Ágil de Projetos com Scrum – Página 3 de 179

Capítulo 5. Estimativa e Priorização Ágil e Scrum DNA ........................................ 104

Estimativas x “Exatimativa” .............................................................................. 112

Técnicas de estimativas: ................................................................................. 114

Medidas de Tamanho Ágeis: ........................................................................... 115

Conceitos importantes para estimativas de software....................................... 121

3a Etapa de Priorização: .................................................................................. 130

Leitura Complementar ........................................................................................ 133

GRE – Gerência de Requisitos: ....................................................................... 137

DRE – Desenvolvimento de Requisitos: .......................................................... 138

PCP – Projeto e Construção de Produto: ........................................................ 138

Gestão 3.0 – Expansão do agile nas organizações ............................................ 162

Referências ............................................................................................................ 177

Gerenciamento Ágil de Projetos com Scrum – Página 4 de 179

No contexto econômico atual, com novos segmentos de mercado, novos

Vivemos no mundo VUCA! VUCA é uma sigla que representa as diversas

“Nós estamos saindo de um mundo linear de saber a solução dos

Gerenciamento Ágil de Projetos com Scrum – Página 5 de 179

E, este cenário gera, portanto, uma grande necessidade de trabalho em

Dessa forma, a valorização da capacidade de se trabalhar em equipe se torna

Gerenciamento Ágil de Projetos com Scrum – Página 6 de 179

Outro ponto primordial de ser analisado é o surgimento das novas empresas,

Portanto, gerenciar pessoas e se preocupar com um ambiente saudável e

Para se manterem competitivas, as empresas devem estar na fronteira da

Gerenciamento Ágil de Projetos com Scrum – Página 7 de 179

O planejamento de projetos no ágil difere do planejamento tradicional, que

Já o monitoramento de projetos ágeis, constitui-se em acompanhar o

Afinal, o que é ser ágil?

“Capacidade de prover respostas rápidas e flexíveis às mudanças.” (Craig Larman)

“Habilidade tanto de criar quanto de responder as mudanças de forma a obter

Gerenciamento Ágil de Projetos com Scrum – Página 8 de 179

Doing Agile x Being Agile?

Gerenciamento Ágil de Projetos com Scrum – Página 9 de 179

Algumas atitudes "Being Agile” dizem respeito sobre:

▪ Ter o cliente sempre por perto (de verdade!).

▪ Envolver os stakeholders significa que ele irá validar frequentemente e não

▪ Obter feedback real constante e aprender com os erros.

Gerenciamento Ágil de Projetos com Scrum – Página 10 de 179

▪ Ter coragem de dizer sempre a verdade sobre:

– Cronogramas atrasados e irreais;