SCRUM – ESTUDO

LIVRO 1 SCRUM ESSENCIAL – Kenneth S. Rubin.

Capítulo 1 - Introdução
Da perspectiva do esforço, com o desenvolvimento em Scrum precisamos de um décimo do
esforço (pessoas/mês) em comparação com nosso uso anterior de uma abordagem em cascata,
orientada a planejamento, para desenvolver uma quantidade comparável de features do
produto. O desenvolvimento em Scrum progrediu sete vezes mais rápido do que no
desenvolvimento em cascata significando que, por unidade de tempo, o Scrum produziu sete
vezes mais features valiosas do que no desenvolvimento em cascata. Experiência na Genomica.

Benefícios do Scrum: CLIENTES DESLUMBRADOS, RETORNO DO INVESTIMENTO MELHORADO,

CUSTOS REDUZIDOS, RESULTADOS RÁPIDOS, CONFIANÇA DE SER BEM-SUCEDIDO EM UM
MUNDO COMPLEXO, MAIS ALEGRIA.

O foco do Scrum em entregar features funcionais, integradas, testadas e valiosas para o negócio
a cada iteração faz com que os resultados sejam entregues mais rápidos. Não apenas os clientes
ficam deslumbrados, mas também as pessoas fazendo o trabalho que realmente gostam. Elas
gostam da colaboração frequente e significativa, levando a relações interpessoais melhores e
maior confiança mútua entre os membros da equipe.

FRAMEWORK CYNEFIN ( Snowden e Boone 2007): 5 domínios: Simples, Complicado, Caótico,

Complexo e Desordem.

O Desenvolvimento de software é um empreendimento rico, com aspectos que se sobrepõem

e atividades que caem em todos os diferentes domínios (Pelrine 2011). Domínio complexo é o
domínio da emergência (situações novas). Precisamos explorar para aprender sobre o problema,
e então inspecionar e adaptar baseados no que aprendemos. Trabalhar com domínios
complexos requer abordagens inovativas e criativas. Soluções de rotinas pré-prontas não
funcionam. Precisamos criar um ambiente safe-fail (falha segura) para experimentação de forma
que possamos descobrir informações importantes. Neste ambiente, altos níveis de interação e
comunicação são essenciais. SCRUM = Sondar (explorar), Sentir (inspecionar) e Responder
(adaptar).

O Scrum não é muito adequado a trabalhos orientados a interrupção. Nessa situação, você não
vai ser capaz de planejar confiavelmente iteração de uma sprint, por que não sabe qual o
trabalho que terá tão longe assim no futuro. E, mesmo se achar que conhece o trabalho, há uma
boa chance de um pedido de suporte de alta prioridade chegar e evitar quaisquer planos de
antecipação. Considerar uma abordagem KANBAN.

Capítulo 2 – Framework SCRUM

O SCRUM não é um processo padronizado onde segue-se metodicamente uma série de passos
em sequência que garantidamente geram um produto de alta qualidade no prazo e dentro do
orçamento e que deslumbre os clientes. Em vez disso, o Scrum é um FRAMEWORK para
organizar e gerenciar o trabalho. O FRAMEWORK SCRUM é baseado numa série de valores,
princípios e práticas que fornecem a fundação onde sua organização vai adicionar sua própria
implementação individual das práticas de engenharia relevantes e suas abordagens específicas
para a realização das práticas SCRUM.

O SCRUM é um framework simples e focado nas pessoas, baseado nos valores de honestidade,
abertura, coragem, respeito, foco, confiança, empoderamento e colaboração.
Papéis no SCRUM:

PRODUCT OWNER: DONO DO PRODUCT BACKLOG, responsável pelo que vai ser
desenvolvimento e em que ordem, gerencia a sequência e a comunicação do Product Backlog.
Obrigação de garantir que o trabalho mais valioso possível seja sempre realizado, decide quais
features e funcionalidades construir e a ordem na qual as construir.

SCRUM MASTER: DONO DO APITO, responsável por guiar a equipe em criar e seguir seu próprio
processo, baseado no framework scrum em geral. Ajuda a todos os envolvidos entenderem e
abraçarem os valores, princípios e práticas do SCRUM. Ajuda a organização através do
desafiador processo de gerenciamento de mudança que pode ocorrer durante a adoção do
SCRUM. Responsável por proteger a equipe de interferências externas e de remover os
impedimentos que inibam a produtividade da equipe

EQUIPE DE DESENVOLVIMENTO (DEVELOPMENT TEAM): responsável por determinar como

entregar o que o product owner pediu. A equipe se auto-organiza para determinar a melhor
maneira de realizar o objetivo definido pelo product owner. (cinco a nove pessoas). Seus
membro devem coletivamente ter todas as habilidades necessária para produzir um software
funcional de boa qualidade.

SPRINT: trabalho realizado em iterações ou ciclos de até um mês. O trabalho completado em

cada sprint deve criar algo de valor tangível para o cliente ou usuário. Devem ter uma data de
inicio e fim fixadas e devem ter a mesma duração (TIMEBOX). Como regra, durante um sprint,
não permitimos nenhuma mudança de escopo ou de pessoal que altere o objetivo.

Resultado do sprint: Incremento potencialmente entregável do produto (potentially shippable

product increment). Essa definição especifica o grau de confiança de que o trabalho completado
seja de boa qualidade e seja potencialmente entregável. POTENCIALMENTE ENTREGÁVEL é
melhor entendido como um estado de confiança que o que foi construído no sprint esteja
realmente pronto, significando que não há trabalho incompleto que seja materialmente
importante e que precise ser finalizado antes de podermos entregar os resultados do sprint, se
a entrega foi o desejo do negócio.

SPRINT PLANNING ≠ SPRINT BACKLOG

SPRINT PLANNING: A equipe de desenvolvimento deve determinar um subconjunto dos itens do

product backlog que ela acredita que pode completar. FORECAST (previsão) x COMMITMENT
(compromisso). Participam a equipe de desenvolvimento, product owner e scrum master.
Durante o sprint planning, o product owner e a equipe de desenvolvimento concordam em um
sprint goal que define o que o sprint deve alcançar.

Sprint de duas semanas a 1 mês – 4 a 8 horas de sprint planning

Sprint de 1 semana – 2 horas de sprint planning

Deve ser usada uma velocidade sustentável – velocidade na qual a equipe de desenvolvimento
possa trabalhar confortavelmente por um longo período de tempo. Divide-se os itens do product
backlog em tarefas, de acordo com uma estimativa do esforço necessária, executando um
planejamento just-in-time de como construir as features.

SPRINT EXECUTION: Após a finalização do sprint planning e a concordância com o conteúdo do

sprint, a equipe de desenvolvimento vai realizar todo o trabalho necessário para aprontar as
features no nível de pronto. Ninguém diz a equipe de desenvolvimento em qual ordem ou como
fazer o trabalho no nível da tarefa no sprint backlog. Os membros da equipe se auto-organizam
de qualquer maneira que se sintam melhores para alcançar o objetivo do sprint.

SPRINT BACKLOG: Descreve, através de um conjunto de tarefas detalhadas, como a equipe

planeja projetar, construir, integrar e testar as features selecionadas do product backlog durante
aquele sprint em particular.

DAILY SCRUM: A cada dia do sprint, idealmente na mesma hora, a equipe de desenvolvimento
realiza uma reunião de duração fixa (15 minutos ou menos). Daily Stand-Up. O Scrum Master é
o facilitador e os membros da equipe devem responder três perguntas: O que eu realizei desde
a última daily scrum? O que eu planejo trabalhar para a próxima daily scrum? Quais são os
obstáculos ou impedimentos que estão evitando que eu progrida?

Essencial para ajudar a equipe de desenvolvimento gerenciar o fluxo de trabalho rápido e flexível
dentro de um sprint. Atividade diária adaptativa de inspeção e sincronização que ajuda uma
equipe auto-organizada a fazer seu trabalho de forma melhor.

SPRINT REVIEW: Stakeholders e a equipe SCRUM inspecionam o produto sendo construído. O

resultado pode ser colocado no PRODUCT BACKLOG. A conversa é focada na revisão das features
que acabaram de ser feitas, no contexto do esforço geral de desenvolvimento. Uma revisão
bem-sucedida resulta num fluxo bidirecional de informações. As pessoas que não estão na
equipe SCRUM se sincronizam com o esforço de desenvolvimento e ajudam a guiar sua direção.

SPRINT RETROSPECTIVE: A equipe inspeciona o processo SCRUM sendo usado para criar o
produto. O resultado pode ser incluído como parte do processo de desenvolvimento da equipe.
Foco no melhoramento contínuo do processo necessário para ajudar uma boa equipe a se tornar
ótima. Definição de ações para melhoria do processo.

PRODUCT BACKLOG: Responsabilidade do Product Owner, lista priorizada (ordenada) dos

trabalhos de mais valor, os itens são feutures necessárias para atender a visão do product
owner. Pode conter também novas features, mudanças em features existentes, defeitos,
melhorias técnicas e assim por diante. Sequência correta: (valor, custo, conhecimento e risco).
ESTA EM CONSTANTE EVOLUÇÃO. Itens podem ser adicionados, deletados os revisados pelo
product owner. A atividade de criação e refinamento dos itens do product backlog, estimando-
os e priorizando-os, é conhecida como grooming. Antes de finalizar o ordenamento, é preciso
saber o tamanho (custo) de cada item no product backlog para determinação apropriada de sua
prioridade.

Capítulo 3 – Princípios Agéis

Processos orientados a planejamento (Cascata, tradicional, sequencial, antecipatório,
preditivo ou prescritivo) recebem esse nome porque eles tentam planejar e antecipar
todas as features que o usuário pode querer no produto final, e determinar como
construir da melhor maneira essas features. Funciona bem se você o estiver aplicando a
problemas que sejam bem definidos, previsíveis e com pouca probabilidade de
possuírem alguma mudança. Porém, desenvolver um produto raramente ocorre como
o planejado.
PRINCIPIOS: Variabilidade e incerteza; Predição e adaptação; Aprendizado validado;
Trabalho em processo (WIP); Progresso; Performance.
ABRACE A VARIABILIDADE ÚTIL: No desenvolvimento de produto, o objetivo é criar uma
instância única individual do produto, não manufaturar o produto. Cada feature que
construímos dentro de um produto é diferente de toda outra feature dentro daquele
produto, então precisamos da variabilidade.
EMPREGUE O DESENVOLVIMENTO ITERATIVO E INCREMENTAL: Desenvolvimento
iterativo reconhece que provavelmente vamos entender errado as coisas antes de as
entender corretamente, que vamos fazer as coisas de maneira pobre antes de as fazer
direito.
Desenvolvimento incremental estabelece a divisão do produto em pedaços menores
para que possamos construir uma parte dele, aprender como cada pedaço vai sobreviver
no ambiente onde ele tem de existir, adaptar baseado no que aprendemos e então
construir mais. Nos dá informações importantes que nos permitem adaptar nosso
esforço de desenvolvimento e mudar como procedemos.
REDUZA SIMULTANEAMENTE TODAS AS FORMAS DE INCERTEZA: Incerteza quanto ao
final: a incerteza acerca das features do produto final; Incerteza quanto ao meio:
Incerteza acerca do processo e das tecnologias usadas para desenvolver um produto.
Assim: abordagem holística em redução simultânea de todas as incertezas (fim, meio,
cliente). Não há definição prévia do que deve ser construído.
MANTENHA AS OPÇÕES ABERTAS: Último momento responsável: adia-se o
comprometimento e não são tomadas decisões importantes e irreversíveis até o último
momento responsável – quando o custo de não tomar uma decisão se torna maior que
o custo de tomar uma decisão. Porque decidir tomar as decisões mais críticas no início,
quando temos poucas informações disponíveis?

ACEITE QUE VOCÊ NÃO VAI ACERTAR DE PRIMEIRA: Produz-se alguns requisitos e planos de
antemão, mas apenas o suficiente e com a suposição de que vamos preencher os detalhes
desses requisitos e planos na medida em que aprendermos mais sobre os produtos que estamos
construindo.

FAVOREÇA UMA ABORDAGEM ADAPTATIVA E EXPLORATÓRIA: Escolhe-se ganhar conhecimento

ao fazer alguma atividade, tal como construir um protótipo, prova de conceito, realizar um
estudo ou conduzir um experimento. Quando confrontados com a incerteza, compramos
informações através da exploração. Antigamente fazia sentido econômico um processo em
estilo cascata que permitisse uma consideração cuidadosa do conhecimento atual e a predição
de incertezas numa tentativa de se chegar a uma boa solução.

ABRACE A MUDANÇA DE UMA MANEIRA ECONOMICAMENTE VIÁVEL: Assume-se que a

mudança é a norma. Não conseguimos prever a incerteza inerente que existe durante o
desenvolvimento do produto, ao trabalharmos mais tempo e mais duro de antemão. Deve-se
manter plana a curva custo da mudança – tornando sensato abraçar uma mudança tardia.
Produz-se muitos produtos de trabalho de uma maneira just-in-time, evitando a criação de
artefatos potencialmente desnecessários.

EQUILIBRE O TRABALHO PREDITIVO DE ANTEMÃO COM O TRABALHO ADAPTATIVO JUST-IN-

TIME: Reconhece-se que não é possível de antemão ter todos os requisitos e planos de forma
precisa, deve haver um equilíbrio. Ser preditivo demais requereria muitas suposições na
presença de grande incerteza. Ser adaptativo demais faz-se viver um estado de constante
mudança, fazendo com o que trabalho fosse considerado ineficiente e caótico. O framework
SCRUM opera bem no ponto de equilíbrio de ordem e caos (previsão x adaptativo).

APRENDIZADO VALIDADO: Valide rápido as suposições importantes – suposições representam

um risco significante no desenvolvimento. No SCRUM, tentamos minimizar o número de
suposições importantes que existem a qualquer dado tempo. Também não queremos deixar
que suposições importantes existam sem validação por muito tempo. APRENDIZADO
CONSTANTE É UMA CHAVE PARA O SUCESSO. SUPOSIÇÃO > CONSTRUÇÃO > FEEDBACK >
INSPEÇÃO > ADAPTAÇÃO. O SCRUM faz uso de diversos loops de aprendizado predefinidos. O
daily scrum é um loop diário e a sprint review é um loop no nível da iteração.

ORGANIZE O WORKFLOW PARA UM FEEDBACK RÁPIDO: Atividades geradoras de feedback que

ocorrem muito tempo depois do desenvolvimento têm efeitos colaterais infelizes,
transformando a fase de integração numa faz de testes e remendos. Feedback rápido fornece
benefícios econômicos superiores.

TRABALHO EM PROCESSO: Use tamanhos de lote economicamente sensatos (menores),

Reconheça o Inventário e gerencie-o para um fluxo bom. Apesar de precisarmos de alguns
requisitos, se vamos começar o desenvolvimento, não temos de ter todos os requisitos. Se
tivermos muito requisitos, vamos provavelmente experimentar um desperdício de inventário
quando eles mudarem. Por outro lado, se não tivermos um inventário suficiente de requisitos,
vamos interromper o fluxo rápido de trabalho, que também é uma forma de desperdício

FOQUE NO TRABALHO OCIOSO, NÃO NOS TRABALHADORES OCIOSOS: Trabalho ocioso é

trabalho que queremos fazer (construir ou testar algo), mas não podemos por que algo está nos
impedindo. Isto é mais caro que pessoas que têm uma capacidade disponível de fazer mais
trabalho por que não estão sendo utilizados 100% no momento. EXEMPLO: revezamento 4 x 100
– Olhe o bastão, não os corredores. Computador com 100% de utilização – teoria das filas. DEVE-
SE ENCONTRAR GARGALOS NO FLUXO DE TRABALHO E ELIMINÁ-LOS

CONSIDERE O CUSTO DO ATRASO: Custo financeiro associado com o atraso do trabalho ou

atraso em alcançar uma entrega. Ao reduzir desperdício com trabalhadores ociosos, aumenta-
se o desperdício com o trabalho ocioso na fila de espera, normalmente mais danoso.

PROGRESSO: objetivo é rapidamente replanejar e nos adaptar ao fluxo de informações

economicamente importantes que chegam continuamente durante o esforço de
desenvolvimento. Sucesso não é finalizar no prazo e no orçamento, mas não atender as
expectativas dos clientes. Sucesso é ser eficaz, eficiente e efetivo. Com o SCRUM, medimos o
progresso construindo recursos funcionais e validados que entregam valor. Os clientes devem
receber antecipadamente um fluxo contínuo de features de alto valor.

PERFOMANCE: Objetivo central é ser ágil, adaptável e rápido em um passo sustentável, sem
detrimento da qualidade. Cada incremento de valor criado é completado até um alto nível de
confiança, e tem o potencial de ser posto em produção ou enviado para os clientes. Eliminação
de formalidades desnecessárias: adota-se uma perspectiva econômica e cuidadosamente
revisa-se quais documentos serão criados. Se cria-se um documento que é só para guardar e
não trazer nenhum valor, desperdiça-se tempo e dinheiro criando um documento morto.

Capítulo 4 – SPRINT
Características Chaves: duração fixa (timebox), duração curta e consistente, objetivo que não
deve ser alterado uma vez iniciado e devem chega num estado final especificado pela definição
de pronto.

A sprint execution é apenas uma atividade que ocorre durante o sprint, juntamente com o sprint
planning, sprint review e sprint retrospective. Como regra, durante o sprint não são permitidas
mudanças que alterem a equipe ou o escopo do objetivo. Devem ter datas de inicio e fim.

TIMEBOX: Espera-se que a equipe trabalhe numa velocidade sustentável para completar um
conjunto escolhido de trabalho que se alinhe com o sprint goal.

Vantagens: Estabelece um limite de WORK IN PROCESS – trabalhos iniciados não terminados;

Força a priorização e realização da menor quantidade de trabalho que importa mais; Auxilia a
demonstrar o progresso ao completar e validar blocos importantes do trabalho até uma data
conhecida – não existe conformidade com o plano; Evita o perfeccionismo desnecessário ao
forçar o fim para um trabalho potencialmente não limitado; Motiva o fechamento ao aplicar
senso de urgência para os trabalhos entregáveis; Melhora a previsibilidade ao prever o trabalho
a ser entregue em curto prazo.

CURTA DURAÇÃO – Vantagens: Facilita o planejamento ao requerer menos esforço e aplicar

mais precisão; Geram feedback rápidos ao gerar mais oportunidades de inspecionar e adaptar
o produto; Apresenta a oportunidade de gerar renda antecipadamente; Limitam os erros ao
diminuir o risco de quantidade de trabalho errado; Aumenta a gratificação gerada por entregas
antecipadas frequentes ao renovar o interesse e o desejo de continuar em direção ao objetivo;
fornece muito mais checkpoints, aumentando a capacidade das pessoas de lidar com um
ambiente complexo.

A duração deve ser consistente, não modificada a cada sprint. Pode-se atender férias,
pagamentos de impostos ou datas importantes da empresa para a modificação dos sprints.
Deve-se ater ao benefícios da cadência e a simplificação do planejamento, principalmente para
datas de release fixada.