Treinamento Básico de Scrum, utilizando internamente na Módulo para treinamento em Scrum

1. Outubro 2015
Treinamento
Ágil & Scrum
Módulo Security Solutions

3. Agenda
❖ Um pouco de Contexto
❖ Por que ágil?
❖ Agile Manifesto
❖ Agile Mindset
❖ Scrum
❖ Papeis
❖ Cerimônias
❖ Artefatos
❖ Mitos e Fatos
❖ Falácias da Agilidade
❖ Questões Polêmicas
❖ Resources

4. Por que precisamos nos preocupar com isso?
❖ De forma geral, a taxa de sucesso em projetos sempre foi muito baixa. Segundo
o PMI esse número gira em torno de 30% (onde sucesso = projetos acabando no
escopo, no prazo, no custo, na qualidade e com o cliente “satisfeito”).
❖ Com projetos de desenvolvimento de Software esse número é ainda pior.
❖ Normalmente a necessidade/demanda é variável no tempo;
❖ O custo de manutenção é muito mais baixo, logo sua “manutenção” as
vezes equivale a refazer todo o projeto;
❖ A tecnologia evolui muito mais rápido nas ciências/engenharias novas do
que nas tradicionais (Lei de Moore);
❖ Sistemas de Computação e Ciência de Computação ainda são “ciências”
muito “novas" quando comparadas às suas contra-partidas tradicionais.

5. Problema 1 - Você conhece a sua necessidade?
❖ Antes de mais nada, na engenharia tradicional, quase sempre, sua demanda/
necessidade é conhecida e se mantém (relativamente) estável ao longo da vida do
projeto
❖ Se você quer construir uma ponte, a) o cliente sabe exatamente o que ele quer, e
b) a necessidade dele é (quase) a mesma no início do projeto e 2 anos depois.
❖ Quando você desenvolve um produto/sistema de software, na grande maioria das
vezes, você só entende/realiza o que realmente quer, depois de ver alguma coisa
pronta.
❖ E se o projeto leva 2 anos, é CERTO que o que você queria 2 anos atrás é 100%
diferente do que você quer hoje.
❖ Para piorar, muitas vezes quando você coloca seu produto de software na “rua"
você descobre que a demanda para ele é bem diferente do que o que você imaginou.

6. O Cone da Incerteza
O cone da incerteza
descreve a quantidade de
incerteza ao longo da
vida de um projeto. No
começo, pouco se sabe e
a incerteza é grande. À
medida que progredimos
no projeto, aprendemos
mais e a incerteza
diminui. Antes do início
de um projeto de
desenvolvimento de
software a incerteza
quanto ao tempo e ao
custo pode variar de 4
vezes a até 1/4 do
inicialmente estimado.

7. Problema 2 - O custo da mudança é baixo
❖ Quando você constrói uma hidrelétrica (ou um prédio comercial inteiro, por exemplo), você faz
muitas manutenções ao longo da vida útil da construção, mas nenhuma delas faz a hidrelétrica
virar uma termo-elétrica, ou o prédio virar uma usina de refino de açúcar.
❖ Quando isso acontece, quase sempre é “encarado" como uma NOVA obra/projeto, onde você
“destrói” tudo que foi feito e começa do zero novamente. (você não transforma uma ponte
normal em uma ponte levadiça, mesmo sendo “só uma funcionalidade a mais na ponte”).
❖ Na maioria das vezes você troca uma peça desgastada por uma nova, ou coisa parecida.
❖ Quando você constrói um produto de tecnologia (software), muitas vezes a manutenção muda a
forma como todo o sistema funciona. É comum termos mudanças “estruturais" no produto (as
famosas mudanças de “arquitetura”).
❖ Dificilmente um cliente aceita fazer um “novo" produto (uma nova obra) para mexer em
questões estruturais do software. É esperado que você faça a mudança.
❖ Dificilmente você re-cria as coisas do Zero.

8. Problema 3 - Rápida evolução tecnológica
❖ Lei de Moore : Sua capacidade de processamento dobra a cada 18 meses.
❖ Hoje, o “computador" que existe no seu smartphone é mais potente do que era o supercomputador
de 1980.
❖ Em 1988, o IBM PC “top de linha” tinha 8MHz de velocidade, 100 Kb de memória e 8 Mb de Disco.
❖ Hoje você tem o equivalente a 8 vezes 3.6 GHz de velocidade (dual-quad core), 16 Gb de memória e
4 Tb de Disco.
❖ Estamos falando de um computador ORDENS DE GRANDEZA mais rápido, em 25 anos.
❖ A tecnologia que permeia o desenvolvimento de software evolui MUITO, mas MUITO mais rápido que
a tecnologia que permeia as engenharia tradicionais.
❖ Uma ponte hoje é construída quase que com as mesmas técnicas e processos que eram usadas a 30,
40 anos atrás (porém com materiais muito melhores).
❖ Seu computador hoje vai ser peça de museu daqui a 10 anos.
❖ Isso faz com que o perfil de profissional que utilizamos na confecção de produtos/sistemas de software
seja completamente diferente do tipo de profissional que é utilizado em engenharia tradicionais

9. Problema 4 - Ciência nova
❖ A ciência da computação, em comparação com as demais ciências tradicionais ainda é
muito nova.
❖ O 1o computador pessoal é do final da década de 70 (1972).
❖ O primeiro IBM PC é de 80 (1981).
❖ A internet surgiu no início da década de 80.
❖ A World Wide Web é de meados de 90 (1994).
❖ O smartphone (como conhecido hoje) é de 2004 (o primeiro iPhone é de 2006)
❖ Por outro lado, as demais engenharias tem bem mais experiência… A construção civil
por exemplo é de “antes de cristo”.. Tem mais de 2000 anos.
❖ Quando você junta uma ciência nova e uma tecnologia em franca e acelerada evolução,
com demandas extremamente voláteis e com necessidades “de momento”, a forma
tradicional de desenvolver software “quebra".

10. Precisamos resolver problemas diferentes, ou seja,
ter soluções diferentes.

11. Agilidade é uma proposta de
solução para esses problemas

12. O Manifesto Ágil

13. Indivíduos e interações
mais que
processos e ferramentas
Fonte: http://www.starwarsreport.com/2015/02/18/the-jedi-twl-118/

14. Software em funcionamento mais que documentação
abrangente

15. Colaboração com o cliente mais que negociação de contratos

16. Responder a mudanças mais que seguir um plano

17. Princípios
❖ Nossa maior prioridade é satisfazer o cliente através
da entrega contínua e adiantada de software com
valor agregado.
❖ Mudanças nos requisitos são bem-vindas, mesmo
tardiamente no desenvolvimento. Processos ágeis
tiram vantagem das mudanças visando vantagem
competitiva para o cliente.
❖ Entregar frequentemente software funcionando, de
poucas semanas a poucos meses, com preferência à
menor escala de tempo.
❖ Pessoas de negócio e desenvolvedores devem
trabalhar diariamente em conjunto por todo o projeto.
❖ Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário e confie
neles para fazer o trabalho.
❖ O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de
desenvolvimento é através de conversa face a face.
❖ Software funcionando é a medida primária de
progresso.
❖ Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores
e usuários devem ser capazes de manter um
ritmo constante indefinidamente.
❖ 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 realizado--é
essencial.
❖ As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.
❖ Em intervalos regulares, a equipe reflete sobre
como se tornar mais eficaz e então refina e ajusta
seu comportamento de acordo.

18. Agilidade não é o CAOS, nem anarquia

19. Na verdade é muito mais disciplinado do que você pode imaginar

20. Agilidade é um mindset que permeia todas as decisões
ao longo do desenvolvimento do projeto/produto
Sem o mindset correto, de nada adianta seguir os
métodos e as cerimônias a risca.
Melhoria continua permeia todo o mindset ágil. Sem ele
você não chega a lugar nenhum no longo prazo.

21. Mindset Ágil
❖ Por quê dizem que Ágil é contra documentação?
❖ Muitos dos documentos gerados ao longo do
processos de desenvolvimento não agregam
valor ao produto e são difíceis de serem
mantidos atualizados ao longo do ciclo de
desenvolvimento
❖ A documentação que agrega valor para o
usuário e/ou para o produto, deve sim ser
produzida.
❖ Por quê os ciclos são curtos?
❖ Por que assim se força a entregar coisas
funcionando com mais frequência, facilitando
o feedback e a adaptação do produto às
necessidades de negócio
❖ Além disso, você diminui o risco da necessidade
do cliente mudar e você não ficar sabendo em
tempo hábil suficiente para fazer as mudanças
necessárias
❖ Por quê o Big Design Up Front é ruim?
❖ Você consegue prever o futuro? Fazer todo o
design no início implica a premissa que você sabe
como vai ser o futuro.
❖ Pressupõe que o sistema não sofrerá grandes
alterações ao longo do seu ciclo de
desenvolvimento ou que você sabe quais as
mudanças vão ocorrer - de modo a planeja—las
desde o início, o que dificilmente ocorre na prática.
❖ Quando você pensa em TODO o sistema no início,
você toma muitas decisões que dificultam
mudanças nos estágios não iniciais do projeto, e
nesses casos o custo da mudança fica muito alto.
❖ Outro ponto é que isso significa que você passa os
primeiros meses de um projeto sem entregar nada
de valor para o seu usuário
❖ O design emergente permite que o sistema evolua
e se adapte conforme a necessidade do produto se
altera

22. Mindset Ágil
❖ Sempre é possível entregar alguma coisa de
valor, mesmo em sprints muito curtos (de 1
semana por exemplo). A questão fundamental é
como se encara “valor”.
❖ O mindset tradicional encara que valor é só o
que está pronto para ser realmente usado pelo
cliente e o que ele vê
❖ O mindset ágil encara como qualquer
incremento de produto que permita agregar
algum valor ao produto ou no pior dos casos
que permita verificar que o time está andando
no caminho certo.
❖ Nem sempre valor se resume a histórias de
usuário. Questões de performance e
escalabilidade por exemplo, agregam muito
valor ao produto, mas as vezes passam
desapercebidas para o usuário final.
❖ Entre aumentar um sprint e fatiar uma história, o
mindset ágil sempre vai optar por fatiar as
histórias.
❖ No mindset ágil, ao perceber que uma história não
será entregue, a primeira alternativa é sempre
diminuir o ESCOPO e não a QUALIDADE.
❖ No mindset ágil, o time se cobra e se ajuda o
tempo todo. Não existe distinção entre o PO, SM e
o resto do time. Estão todos buscando a alta
performance, e entregar um produto sensacional.
❖ No mindset ágil não existe o EU, só o NÓS. Se a
história não foi entregue, nunca é culpa de uma
pessoa, mas responsabilidade de todos (inclusive
do PO e do SM).
❖ O mindset ágil privilegia as PESSOAS, e suas
relações. Não os processos de comando em
controle tradicionalmente usados.

23. Mindset Ágil
É principalmente uma grande mudança de paradigma
Cascata (Waterfall) >>> Ágil
Desenvolvimento em cascata >>> Desenvolvimento Iterativo
Escopo Fixo (tempo e qualidade variáveis) >>> Tempo e Qualidade Fixos (escopo variável)
Orientado a planejamento, comando e controle >>> Orientado a transparência, inspeção e adaptação
Orientado a processo >>> Orientado a pessoas
Times de especialistas >>> Times Multidisciplinares
Organização do time é imposta >>> É decidida on spot pelo time (e pode mudar ao longo do
tempo)
BDUF / Mudanças são custosas >>> Mudanças são bem vindas, a qualquer tempo
Sem busca pela melhoria continua >>> Busca constante da melhoria continua

24. Agile vs Tradicional
Crédito: Material cedido pela Knowledge21

25. O que é o Scrum?
❖ É uma metodologia de gestão de projetos de software
que se baseia no mindset ágil.
“Scrum is a management and control process that cuts through complexity to focus on
building software that meets business needs. Management and teams are able to get their
hands around the requirements and technologies, never let go, and deliver working software,
incrementally and empirically.
Scrum itself is a simple framework for effective team collaboration on complex software
projects. Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain
Scrum clearly and succinctly.”
(Ken Schwaber : https://www.scrum.org/resources/what-is-scrum)

26. O que é o Scrum
❖ O Scrum é um método estruturado e baseado nos princípios ágeis.
❖ Como qualquer método é baseado em papeis/perfis e e atividades (chamadas
no Scrum de Cerimônias).
❖ E com um conjunto “pequeno" de regras de conduta / operação para garantir
que as coisas funcionam.
❖ Baseado na “Teoria de Controle de Processo Empíricos”
❖ Tem por pilares: Transparência, Inspeção e Adaptação
❖ Processos Empíricos :
❖ Complexos & imprevisíveis
❖ Diferentes entradas, diferentes saídas

27. O objetivo do Scrum é conseguir entregar o
máximo de valor, no período mais rápido possível.
Não necessariamente todo o projeto/produto será
entregue, isso depende basicamente da relação de
custo/benefício entre o valor agregado ao
produto/serviço e seu custo para desenvolvimento
Por isso o Scrum é obcecado com a palavra
VALOR. Ela deve permear tudo que o Product
Owner faz.

28. Teoria do Scrum
❖ Abordagem incremental e
iterativa para
❖ Maximizar a previsibilidade
❖ Gerenciar o risco
❖ Baseado em
❖ Transparência & Visibilidade
❖ Inspeção
❖ Adaptação

29. Papeis do Scrum
❖ Product Owner (PO)
❖ Scrum Master (SM)
❖ Development Team
❖ São COMPLETAMENTE não
relacionados com a hierarquia e com
cargos e posições da empresa.
❖ Não existe hierarquia definida no
time Scrum. Ninguém manda no time

31. O Product Owner
❖ Define a visão do produto e por
gerenciar o Product Backlog
❖ É responsável por maximizar o
valor do produto e por
❖ Prioriza e “fatia" o trabalho a
ser feito pelo time
❖ É uma pessoa, não um comitê
❖ Para ter sucesso, precisa ter
autonomia e suas decisões
respeitadas
❖ Não é o dono nem chefe do time
❖ Defini o que, e em que ordem
preferencialmente, mas não
define o COMO, nem o de que
forma
❖ Não é um proxy dos
stakeholders
❖ Pode aceitar ou rejeitar o que foi
feito pelo time
❖ Deve estar disponível para o
time durante todo o sprint

33. O Scrum Master
❖ Responsável por fazer o trabalho
andar de forma fluída e sem
sobressaltos
❖ É o facilitador do time, que remove os
impedimentos que aparecem ao longo
do sprint
❖ Garante que a metodologia é seguida,
por intermédio das cerimônias, as
conduzindo
❖ Ajuda o time em seu processo de
crescimento e amadurecimento
❖ Protege o time de interferências
externas
❖ Não é o dono nem chefe to time
❖ Não interfere nas decisões técnicas,
nem nas decisões de produto
❖ Não é o representando do time
(para fora do mesmo)
❖ Não é responsável por criar/
definir as histórias ou por pontua-
las
❖ Ajuda o time e o PO em suas
respectivas tarefas, servindo o time
como um todo

35. O Time de Desenvolvimento
❖ Apesar de “Development”, envolve
todas as pessoas que fazem o
incremento de produto acontecer
❖ É quem implementa, testa, coloca
em produto, etc..
❖ É responsável por pontuar, e
entregar as histórias no maior nível
de excelência e qualidades possível
❖ Pode ter 1 ou mais líderes técnicos
❖ Responsável por elaborar as tarefas
/atividades necessárias para
entregar as histórias
❖ Não “responde"
hierarquicamente ao PO nem so
SM
❖ Não tem autoridade para definir
o produto, ou a visão do produto
(no máximo ele influência o PO e
os stakeholders para isso)
❖ Não define o como, nem o que,
nem o porque.
❖ Idealmente tem entre 5 e 9
pessoas.

36. Ritos e Cerimônias do Scrum
❖ Sprint
❖ Planejamento de Sprint
❖ Planning Poker
❖ Reunião Diária
❖ Revisão do Sprint
❖ Retrospectiva do Sprint
❖ Refinamento do Backlog
❖ Release

37. Sprint
❖ Um sprint é uma quantidade
fixa de dias (um time-box),
normalmente de 1 a 3 semanas
❖ Nunca maior que 1 mês
❖ Nesse período é produzido
alguma coisa “pronta" e
“usável”, que pode ou não ser
liberado para o usuário
❖ Tem um objetivo: o que será
entregue?
❖ Ao longo de um sprint
❖ Nenhuma mudança de escopo
acontece
❖ Sua qualidade não é sacrificada
para “entregar"
❖ O escopo pode ser “clarificado"
conforme se entende mais do
problema
❖ Se o escopo não cabe no time-
box, diminui-se o escopo, MAS
NÃO SE AUMENTA O PRAZO

38. Planejamento do Sprint
❖ É a primeira cerimônia do Sprint
❖ Reunião onde o time (PO,
Desenvolvedores e Scrum
Master) planejam o que será feito
no sprint
❖ Qual o objetivo do sprint?
❖ Quais histórias serão feitas?
❖ Qual o esforço estimado do
trabalho?
❖ Como vamos saber que o que
foi feito está "entregue"
❖ As histórias “candidatas" são
detalhadas, até o time ter
conforto em fazer uma
estimativa de esforço
❖ Uma história quanto estimada
em mais da metade do ciclo,
idealmente deve ser quebrada
❖ Se o time acha que a história
não faz sentido, ou ainda que
ela está mal definida ou
confusa, ele pode “recusar" a
história

39. Estimativas de Esforço - Planning Poker
❖ Cerimônia que tem por objetivo alcançar
um consenso em torno das estimativas de
esforço para as histórias
❖ E que ocorre DENTRO da cerimônia de
planejamento do sprint.
❖ As estimativas são feitas em termos
abstratos, usando o “conceito de pontos”
❖ NÃO se usa Dia, ou Horas
❖ NEM se dá um prazo
❖ Todo o time de desenvolvimento se
envolve na pontuação das histórias
❖ A pontuação se refere ao esforço (trabalho
e complexidade) de implementação das
histórias
❖ O planning poker é um processo iterativo, onde
depois de todos terem entendido o que é para
ser feito na história, cada membro do time
estima uma quantidade de pontos para a
mesma, ao mesmo tempo.
❖ As pontuações individuais são discutidas e após
a discussão, chega-se a um consenso sobre a
pontuação da história.
❖ As estimativas discrepantes são discutidas e
após seus racionais entendidos, uma nova
rodada de pontuação é feita.
❖ Normalmente se usa uma pontuação padrão
(como a sequência de Fibonacci).
❖ A pontuação deve ser encarada como a mediana
da sequência (ou seja, se a pontuação for 5,
significa que a estimativa pode variar entre 3 e 8)

40. Estimativas de Esforço - Pontos vs Duração
❖ Por que usar pontos e não horas?
❖ Direciona o foco em tamanho, complexidade e esforço e não em duração.
❖ Usando hora/dia marcara performances individuais distintas, com pontos
essas questões tendem a serem normalizadas
❖ Tarefas similares tendem a diminuir o hora/dia com o tempo
❖ Ao entrar uma pessoa nova no time, ao se usar hora/dia, se tem a
impressão de um aumento imediato e irreal de produtividade
❖ Evita/minimiza a pressão externa em torno de dadas e prazos
❖ Minimiza os efeitos da Síndrome do Estudante e da Lei de Parkinson
❖ Minimiza a falsa sensação de “previsibilidade”. Falar em datas e prazos é
sempre mais “preciso" do que falar em pontos (é abstrato por definição)

41. Reunião Diária
❖ Todo dia, em horários pré-
combinados, todo o time se
reune.
❖ Essa reunião é curta, não
devendo durar mais de 15, 20
min.
❖ Cada integrante do time fala na
reunião, com foco em 3 pontos
❖ O que eu fiz ontem
❖ O que vou fazer hoje
❖ Tenho algum impedimento?
❖ Tem por objetivo sincronizar as
atividades do time e criar um
“plano" para as próximas 24 hr
❖ Além disso, tem por objetivo
mitigar riscos e desenvolver
planos de ações que permitam
atingir o objetivo do sprint
❖ A reunião não tem por objetivo
RESOLVER os problemas, mas sim
IDENTIFICAR os problemas
❖ A solução é feita pelo time em
reunião ad-hoc posteriores

42. Revisão do Sprint
❖ Ao final do sprint, o time
inteiro se reune, e apresenta o
que foi desenvolvido
❖ Nessa reunião de apresentação,
o time coleta feedback sobre o
que foi entregue com o PO e
com outros stakeholders
relevantes
❖ Só pode ser considerado
entregue, o que respeita a
definição de “PRONTO" do
time
❖ Com o resultado da reunião de
revisão, o Product Backlog pode ser
adaptado/revisado
❖ Essa não é uma reunião de
progresso, e sim uma reunião para
se obter feedback e facilitar a
colaboração
❖ Nessa reunião, e com base no
feedback, o time responde as
perguntas que existirem
❖ Essas discussões servem de input
para o planejamento do próximo
sprint

43. Retrospectiva do Sprint
❖ A retrospectiva é a cerimônia que provê
ao time, a oportunidade de se
inspecionar e criar planos de melhoria
para serem utilizados no sprint seguinte
❖ Enquanto a revisão do sprint é focado no
que foi entregue no sprint, a retrospectiva
é focada no processo de auto-organização
e performance do time
❖ É onde o time faz uma auto-crítica para
entender como o time pode melhorar (em
todos os aspectos) e pensa no plano de
ação para isso
❖ Essa cerimônia deve ocorrer após a
revisão e antes do planejamento do sprint
seguinte
❖ De forma geral a retrospectiva tem por
objetivo responder 3 aspectos:
❖ Entender o que deu certo e que pode e
deve continuar a ser feito?
❖ Entender o que deu errado, e por que?
Como isso pode ser evitado
❖ Entender quais os pontos de melhoria
que podem ser implementados? Quais
as ferramentas, processos e dispositivos
podem ser usados para implementar os
pontos de melhora?
❖ Apesar de melhorias poderem ser feitas a
qualquer momento, a retrospectiva fornece
uma oportunidade forma e estruturada
para isso.

44. Refinamento do Backlog
❖ É uma reunião onde o time se reune com o PO, ANTES do
planejamento do release, para levantar pontos de dúvida e atenção
nas histórias candidatas a serem implementadas no sprint seguinte
❖ Tem por objetivo permitir tanto ao PO quanto ao Time, se preparar
melhor para a reunião de planejamento
❖ Pode ser feita a qualquer tempo, mas normalmente é feita no meio
do sprint.
❖ Pode ser feita com todo o time, ou com membros individuais

45. Release
❖ Ao longo dos sprints são gerados incrementos de
produtos.
❖ Cabe ao Product Owner identificar quando esses
incrementos podem ser efetivamente liberados para os
usuários / clientes.
❖ O Release pode ter um conjunto fixo ou não de sprints.

46. O processo do Scrum

47. Artefatos do Scrum
❖ Histórias de Usuário
❖ Backlog de Produto
❖ Backlog do Sprint
❖ Burn Charts
❖ Incremento de Produto
❖ Taskboard

48. Backlog de Produto
❖ É uma lista ordenada de tudo que é
supostamente necessário para o produto
❖ É responsabilidade do Product Owner manter o
backlog de produto atualizado, ordenado e
priorizado
❖ Para isso deve conversar com clientes, e demais
stakeholders para conseguir entender os
requisitos e demandas de negócio
❖ Por definição, o backlog de produto nunca está
completo, uma vez que as necessidades do
produto evoluem com o tempo
❖ O backlog é vivo, conforme o mercado muda e
os clientes tem suas necessidades alteradas, o
produto para se manter competitivo também
precisa mudar, e com isso, o backlog também
muda
❖ O detalhamento do backlog consistem em
adicionar detalhes e informações relevantes aos
itens do backlog, além de re-ordena-los.
❖ Conforme o detalhamento avança, o time
prepara estimativas preliminares para ajudar o
PO a priorizar a geração de valor das mesmas
❖ Quanto mais alto na lista de prioridade, mais
detalhado e bem definido deve ser item do
backlog. Inclusive com definições de “Pronto”
mais completas.
❖ Os itens mais alto, são os primeiros candidatos a
serem desenvolvidos nos sprints subsequentes
❖ O backlog pode ser re-priorizado e re-ordenado
a qualquer hora, visando a geração de valor a
partir do sprint subsequente.

49. Backlog do Sprint
❖ Sprint a sprint, o Product Owner define
o que deve ser feito, para se atingir a
visão do produto, ou seja é o conjunto
de itens do backlog de produto que
foram selecionados para aquele sprint
❖ Conforme o sprint se aproxima, o
detalhamento do que precisa ser feito
se aprimora, até o limite suficiente do
time entender:
❖ O que precisa ser feito
❖ Por que aquilo precisa ser feito
❖ Quais as alternativas para entregar o
que precisa ser entregue
❖ Os itens do backlog do sprint devem estar
devidamente detalhados (eventualmente
com wireframes de alto nível, exemplos de
uso, etc).
❖ O backlog do Sprint é a previsão do time
sobre qual funcionalidade será entregue ao
final do sprint
❖ Assim, o backlog dá visibilidade e
transparência ao trabalho necessário para
atingir o objetivo do Sprint
❖ O backlog do sprint deve ter detalhes o
suficiente de forma a ser possível monitorar
seu progresso ao longo das reuniões diária
❖ Idealmente, as definições de “Pronto" e
“Entregue”, também devem estar completas

50. Histórias de Usuário
❖ Uma história de usuário é um
incremento de produto que gera valor
para o usuário.
❖ É um formato comum que permite a
todos os envolvidos identificar o que
precisa ser feito (qual a
funcionalidade), para quem (qual
usuário do produto/sistema), e por
que (qual o benefício é esperado por
essa funcionalidade)
❖ É papel do Product Owner, ao
elaborar o Sprint Backlog garantir que
todas as histórias estejam formatas
como histórias de usuário.
❖ As histórias de usuário no Scrum
possuem o seguinte formato:
❖ Eu, como <PAPEL>, desejo <FAZER O QUE>,
para <QUAL O BENEFÍCIO ESPERADO>.
❖ Os detalhes do que precisa ser feito, e
como saberemos que aquele item foi
“entregue" segundo a ótica do time,
deve estar explicitada na “Definição de
Pronto”.
❖ Outra informação importante é o
“critério de aceite” da história, que
detalhe qual o critério de sucesso que a
história precisa atingir para ser
considerada “aceita" pelo PO.

51. Histórias de Usuário - Critério de Aceite
❖ Define os limites do que deve e do que não deve ser feito ao longo do
desenvolvimento da história
❖ Fornecem um conhecimento compartilhado (time, PO, SM) sobre o que deve ser
feito.
❖ Guiam o time para evitar a adição de características de baixo (ou nenhum) valor
agregado nas funcionalidades, focando os esforços em garantir desenvolver o
mínimo necessário para entregar o valor proposto.
❖ Normalmente são expressos em frases curtas e simples e adicionados às histórias
do usuário ao longo das sessões de refinamento do backlog, ou no máximo nas
reuniões de planning.
❖ São o principal guia dos testes de aceitação, também fazendo parte da definição de
“pronto” para a história.

52. Burn Charts & Velocidade
❖ É um gráfico que tem por objetivo acompanhar o progresso as atividades do
sprint
❖ Existem 2 “sabores" de burn charts:
❖ Burn Down: acompanha o trabalho que AINDA FALTA ser feito
❖ Burn Up : acompanha o trabalho que já foi feito
❖ O gráfico, na verdade, consiste de 2 gráficos juntos (um mostrando o
“esperado" e outro mostrando o “realizado), sendo que em um eixo temos o
trabalho e no outro o tempo
❖ Considerando que ao longo do sprint não temos nenhum trabalho
“adicionado”, é esperado que o burn chart seja uma curva “bem comportada”
seja para cima (burn up) seja para baixo (burn down)

53. Burn Charts & Velocidade
Burn Chart
❖ É um gráfico que tem por objetivo acompanhar o
progresso as atividades do sprint
❖ Existem 2 “sabores" de burn charts:
❖ Burn Down: acompanha o trabalho que
AINDA FALTA ser feito
❖ Burn Up : acompanha o trabalho que JÁ FOI
feito
❖ O gráfico, na verdade, consiste de 2 gráficos juntos
(um mostrando o “esperado" e outro mostrando o
“realizado), sendo que em um eixo temos o
trabalho e no outro o tempo
❖ Considerando que ao longo do sprint não temos
nenhum trabalho “adicionado”, é esperado que o
burn chart seja uma curva “bem comportada” seja
para cima (burn up) seja para baixo (burn down)
Velocidade
❖ Velocidade é uma medida de “capacidade” de
um time, indicando, na média, quantos pontos
um determinado time consegue entregar por
sprint.
❖ A velocidade é calculada somando todos os
pontos entregues pelo time no sprint, e
ajustando esse valor ao longo de sprints
sucessivos
❖ Por exemplo: se você diz que o time A tem
velocidade de 20 pontos, significa que na média
ele consegue entregar 20 pontos por sprints
❖ Muitos profissionais experiências no mundo
Ágil tem resistências com essa métrica, uma vez
que o ponto em sí já é uma abstração ruim (e
imprecisa) da capacidade do time.

54. Burn Charts

55. Incremento de Produto
❖ Incremento de produto é o resultado das histórias
entregues sprint a sprint.
❖ Esse incremento pode ou não ser disponibilizado para o
usuário / cliente final (seja em forma demo, beta ou mesmo
produto final).
❖ Essa decisão é tomada pelo Product Owner.
❖ O incremento de produto pode ser funcional ou não. Mas é
fundamental que ele agrega valor ao produto ou ao
usuário.

56. Taskboard
❖ Quadro físico ou virtual onde as
atividades e tarefas do sprint são
visualizadas e “gerenciadas”.
❖ Normalmente organizado em 3
colunas “básicas" : To-Do, Doing,
Done (ou variações dessas
colunas), mas pode ter mais
colunas conforme decidido pelo
time
❖ Deve mostrar claramente o
andamento/progresso do time,
inclusive seus (eventuais)
impedimentos

57. O processo do Scrum - Revisão

58. Mitos & Fatos - Mais Comuns
Sobre o papel do Product Owner
❖ Mito: O PO é o representante do cliente, as
vezes sendo o próprio cliente
❖ Mito: O PO deve cobrar do time o
compromisso que todos os itens escolhidos
para o Sprint sejam entregues
❖ Mito: A presença do PO é opcional
❖ Mito: O PO é o dono do time
❖ Fato: O PO deve balancear necessidades e
desejos de diferentes stakeholders, mas só ele
pode alterar o backlog do produto
❖ Fato: É responsabilidade do PO definir o
produto certo a ser desenvolvido
❖ Fato: Deve existir um e somente um PO
Sobre o papel do Scrum Master
❖ Mito: O SM é o dono do time
❖ Mito: O SM gerencia o trabalho do time
❖ Mito: O SM precisa ter experiência como
desenvolvedor
❖ Fato: O SM trabalha para remover todo e
qualquer impedimento do time
❖ Fato: Ao impor, opinar e/ou interferir nas
decisões de trabalho do time, o SM se torna
menos eficiente como facilitador
❖ Fato: A meta do SM desenvolver o time a
ponto dele mesmo ser desnecessário
❖ Fato: O SM trabalha para que o Scrum seja
devidamente seguido e utilizado.

59. Falácias da Agilidade
❖ O Product Owner não participa da
retrospectiva.
❖ E se o “problema" for o PO?
❖ “Escalar" agile é fácil, tem receita pronta
para isso.
❖ Agile é baseado em pessoas e não em
processos. Escalar um processo
baseado em pessoas é fácil?
❖ Agile não tem documentação.
❖ Em qual princípio isso está escrito?
❖ Agile é só um processo.
❖ E aquela questão de “people over
process”?
❖ Valor é só o que tem interface para o
usuário.
❖ Quer dizer que se você deixar o
sistema 100x mais rápido e conseguir
atender 100x mais usuários, isso não
tem nenhum valor?
❖ Ágil é "coisa" só para TI.
❖ O mindset é só de uma classe de
profissionais? Por que?
❖ Ágil só funciona em startup
❖ Não é isso que o FBI ou a Federal
Express, ou ainda o Salesforce dizem
não…

60. Algumas questões polêmicas
❖ Scrum vs PMBoK : É um erro preconizar o fim do PMI ou do PMBoK. Eles servem a
propósitos diferentes. Scrum é mais eficiente para projetos de tecnologia cercados de
incerteza (o que não significa que não pode/deve ser usado em outros domínios).
❖ Mas muitas das ferramentas descritas no PMBoK são muito úteis e oferecem um
ferramental mais estruturado para a gestão de projetos
❖ Os papeis do Scrum existem por uma razão. Então se você não tem os papeis sendo
seguidos você não está fazendo Scrum.
❖ Parte do “problema" do Scrum é que ele é prescritivo (ao invés de descritivo). Ou seja,
ele dá muita liberdade para o time se organizar para atingir os objetivos do sprint e do
release. Onde está o problema?
❖ Se o time é imaturo, ele demora muito (se conseguir), até conseguir se auto-
organizar, e começar a atuar como um time de verdade. E maturidade não tem a ver
com qualidade técnica.

61. Resources
❖ Scrum Alliance (http://www.scrumalliance.org)
❖ Scrum Org. (scrum.org : Ken Schwaber)
❖ Scrum Log (http://jeffsutherland.com/)
❖ Meta Frameworks para “escalar" métodos ágeis:
❖ SAFe
❖ LeSS
❖ Nexus
❖ Scrum @ Scale

62. Alberto A. Caeiro Júnior, CSPO, CSM, PMP
Head of Engineering, Módulo Security Solutions
Obrigado!