Projetos ágeis com SCRUM

Introdução a Gestão de Projetos e ao SCRUM

Pilares
Papéis e responsabilidades de cada um do time
Cerimônias do Scrum
Quem participa do planejamento da Sprint?
Participam o PO, o Time de DEV e o Scrum Master
A reunião de planejamento tem duração de 8 horas, sendo nas primeiras 4 horas tem o objetivo
“O que fazer?” – O PO após priorizar o Backlog, vai explicar para o time o que deseja naquela
sprint, quais são as funcionalidades, o que o time vai entregar naquela sprint, explica as
funcionalidades, explica o porquê, o time de DEV deve tirar todas as dúvidas necessárias em
relação ao negócio para entender o que o PO quer nessa sprint.
Nas demais 4 horas “Como fazer?”, o time de DEV quebra as atividades, entende tecnicamente o
que deve ser feito, e o próprio time estima o tempo das atividades de “Como Fazer” o que o PO
deseja.

No Planejamento o time pode utilizar varias ferramentas ou técnicas, uma delas é “Planning
Poker” – Utilização de baralho mesmo onde cada um opina uma estimativa de cada tarefa e
entram em consenso para definir uma estimativa um esforço de cada tarefa.
Depois de estimada o esforço de cada tarefa o time verifica se tudo o que o PO quer pode ser
entregue na Sprint.
Reuniões Diárias (Daily Meeting) – Participam O Time de Desenvolvimento, O PO e o Scrum
master.
Nessa reunião, o time de DEV deve responder a três perguntas, O que fez no dia anterior, o que
está programado para o dia e se existe algum impedimento. A reunião é feita de pé, no mesmo
horário que o time define e no mesmo local, está reunião também é conhecida como stand up
meeting e dura no máximo 15 min.
(To Do / Doing / Done) – Conhecido como quadro “KanBan”, o próprio time vai atualizar as tarefas
que estão realizando, as tarefas que estão fazendo, que irão fazer e as concluídas. Está técnica dá
uma visibilidade e transparência para o time inspecionar se tudo está correndo como previsto.

Reunião da Sprint (Review) – Realizada no último dia da Sprint, o time de DEV apresenta o que
desenvolveu passo a passo para o PO, de forma que quando entrar em produção não haja
surpresas para o PO.
O que o time de deve apresenta o PO vai aceitar ou não, se positivo entra em produção.
Retrospectiva da Sprint – Realizada no último dia da Sprint também, o PO e Scrum master pode
participar, mas geralmente está reunião é entre o time de DEV, onde todos devem ser
transparentes para apontar os erros, seja no desenvolvimento, na review que foi apresentada,
seja no planejamento da Sprint ou algo que não foi questionado para o PO. Esta reunião é
importante para que todo mundo esteja comprometido, então a transparência é fundamental
para que a equipe tenha Lições Aprendidas para que na próxima Sprint estes mesmos erros não
ocorram novamente.

Gestão de Projetos Tradicional x Ágil

Papéis e responsabilidades - Product Owner
O PO é o profissional que visualiza o valor que será agregado para a empresa e para o cliente que
irá utilizar o produto construído. Ele também é quem define a ordem que as atividades serão
desenvolvidas, também é responsável por validar se esses itens estão sendo entregues nas Sprints
e estão agregando valor esperado, caso não estejam, ele deve planejar os ajustes nas próximas
Sprints a fim de manter o objetivo proposto. Na pior das hipóteses o PO também é responsável por
cancelar a Sprints, quando as atividades planejadas não puderem ser entregues ou quando o PO
entender que o valor esperado não será atingido. Nesse caso cabe ao PO replanejar a Sprint,
mantendo os dias para conclusão dela, com alguma entrega de valor possível, se nenhuma
entrega executável for possível, ele pode priorizar um estudo a fim de agilizar o desenvolvimento
da próxima Sprint, esse estudo é conhecido como Spyder.
É importante ficar claro que o papel do Scrum Master não é de secretário do time, e nem o Scrum
Master e o PO são chefes do time de desenvolvimento é de estrema importância que estes papeis
sejam pares, que não haja uma divisão hierárquica para não haver conflito de interesses.
O Scrum Master é responsável por disseminar a cultura ágil no time, ensinando todos os conceitos
do Scrum, ensinado o time a executar todas as cerimonias e principalmente ensinar o time a ser
mais independente e a se auto gerenciar.
 Cerimônia Refining – Está cerimónia não é oficial, mas ajuda muito para a qualidade das
plannings. É executada antes da Planning, na refining o PO apresenta previamente para o time as
histórias que serão apresentadas na planning. Até que a planning efetivamente aconteça, toda
mudança levantada é ponderada, o objetivo da refining é o time já saber previamente o que será
desenvolvido e poder fazer questionamentos para o PO e para os demais envolvidos, nessa
cerimônia é permitido a participação dos stakeholders. Caso o PO ou qualquer outro envolvido
não consiga responder a alguma dúvida do time o PO terá tempo suficiente para correr atrás de
uma resposta antes de iniciar a planning. O importante é que na planning ninguém saia com
dúvida e todas as regras de negócio estejam claras para o time. A planning deve ser dividida em
duas etapas, na Primeira parte o PO vai pegar os itens mais refinados e priorizados do backlog e
irá apresentar para o time, nesse momento é importante que o PO efetue a leitura completa das
histórias com time, para mais uma vez nenhuma dúvida fique em aberto e evitar o achismo por
parte do time de DEV, o time não deve pressupor absolutamente nada, qualquer coisa que haja
um entendimento diferente deve ser validado com PO. Assim que todas as histórias tiverem sido
apresentadas, lidas e aceitas pelo time, será executada a primeira análise para verificar o que
entra ou não na primeira Sprint. Só após este processo a planning pode iniciar sua segunda etapa.
A Segunda parte da planning é uma parte mais técnica é sugerido que o PO não participe para
não exercer influência sobre as atividades a serem desenvolvida e o time possa expressar suas
opiniões e discutir detalhes que normalmente não serão conversados na frente do PO, o time deve
analisar cada história e detalhar quais atividades devem ser desenvolvidas para que as histórias
sejam consideradas entregues, nela também o time pode efetuar um outro corte e diminuir ainda
mais as histórias a serem entregues, isso pois após analisar a história, verificar que esta é mais
complexa do que imaginaram anteriormente.
Com as histórias mapeadas e as atividades descritas, é definida o Sprint backlog, com essa
informação na mão o PO deve validar os quais os itens é considerado mais prioritário e que deve
ser considerado o objetivo principal da Sprint.

É importante entender que não é obrigatório ter uma Release ao final de uma Sprint, mas a cada
Sprint acumulada sem um lançamento, Release, aumenta a probabilidade, risco de ocorrer
problemas durante o Merge, que é a junção dos códigos fontes de cada Sprint e maior o tempo de
testes necessários para garantir que todas as funcionalidades estejam funcionando corretamente
após esse Merge.
Release Planning de Múltiplas Squads – São vários teases de desenvolvimento agrupados
realizando várias coisas distintas que podem ou não ter correlação entre as atividades, mas que
no final da Sprint devem ser agrupadas em uma só Release para ser implementadas em produção.
É um tipo de Release Planning técnica, não tem ação direta do PO, este deve ficar atendo aos
prazos que o time deve cumprir para entrega do código e acompanhar a homologação após o
Merge para certificar que as entregas serão cumpridas ao final da Release.
Release Planning de Projeto – Nessa Release o PO possui uma demanda muito grande é será
necessário o PO quebrar as entregas em varias histórias e consequentemente quebrar em várias
Sprints, neste ponto é importante que o PO tenha uma senioridade para compreender a real
dimensão da demanda, de cada história da demanda e quebrar o máximo possível. O PO também
é responsável por gerenciar as expectativas dos stakeholders, é importante que o PO tenha
discernimento, para que já na reunião que ele recebe a demanda, acalmar os ânimos dos
stakeholders e informar o tamanho da demanda e a possibilidade desta ser necessária varias
Sprints para entregar o produto, sem nunca informar quantas Sprints pois estás serão
dimensionadas ao decorrer do projeto. O PO deve quebrar e priorizar as histórias de acordo com
MVP de maior valor primeiro de forma que seja possível testar a solução com cliente e capitando
retorno para adaptar a solução ao longo do desenvolvimento.
A Release Planning talvez seja um dos pontos mais críticos que o PO tem que lidar, devido as
empresas estarem acostumadas com os métodos tradicionais de gestão de projeto, onde todo
planejamento é feito antes no início do desenvolvimento. Este ponto é o de maior dificuldade para
o PO, já que ele não terá a visão completa do projeto pois este irá se modificar ao longo do
processo.
O papel do PO durante o planejamento da Release consiste em:
- Definir as maiores entregas de valor para o cliente;
- Priorizar as maiores entregas de valor a serem desenvolvidas primeiro;
- Organizar as Sprints para que seja possível captar o retorno do cliente o mais breve possível;
- Com retorno dos clientes, ajustar as histórias para que estás para que estas entreguem mais
valor;
- E organizar quando as Releases serão realizadas para agregar mais valor.
Outro ponto importante no planejamento das Releases é entender quando a entrega em si traz
valor para o cliente, ou se a entrega será apenas estética ou funcional não alterando a dinâmica
do usuário do sistema.
Analisando escopo e definindo prioridades
Papel do PO na transformação digital

O Papel do PO na transformação digital é fundamental, representa a mudança na forma como os

projetos serão tratados, a maneira como o conhecimento é disseminado. O PO não é GP, ele será
apenas um orquestrador da comunicação entre o analista de projeto e o GP, será responsável por
juntar todas as pequenas partes e montar todo o planejamento do produto.
Conceitos e atividades essenciais para o sucesso de um projeto ágil
Aprenda sobre os conceitos e planejamento de tarefas
Basicamente uma Estória é um conjunto de tarefas e um Épico é um conjunto de Estórias.
Nós começamos pensando nos épicos do projeto, quando este projeto for priorizado nós
quebramos as estórias e neste momento se for necessário podemos quebrar os épicos em mais
épicos.
Quando as estórias forem priorizadas nas Sprints, essas estórias são quebradas em tarefas, e
neste momento podemos quebrar as estórias em mais estórias caso o time entenda ser o melhor
caminho.

A estória deve ser descrita em nível de negócio e serve para que o time de DEV entenda o objetivo
daquela atividade. É importante para que o time entenda o que deve ser feito, mas também para
que será usado e como será usado.
É o objetivo que aquela estória tem que concluir, se uma estória não tem critério de aceite,
provavelmente o PO não entendeu a demanda, ele apenas escreveu a estória para cumprir tabela.
Como PO a primeira coisa que precisa ser entendido de uma demanda é justamente qual o
objetivo dela, onde se quer chegar, qual objetivo queremos atingir.
Este método é o mais usado para fazer estimativas do tamanho das tarefas em times ágeis.
É de fato um jogo de cartas, cada membro do time de DEV recebe um deque contendo todos os
números da sequência de Fibonacci, quando todos estão prontos as estórias são lidas e as tarefas
são criadas, após a criação das tarefas todo time de DEV vota jogando uma das cartas falando
qual o tamanho daquela atividade, deve-se levar em conta a complexidade desta tarefa, o
trabalho manual em si e o tempo. Exemplo: Uma tarefa considerada muito simples de se fazer,
pode receber voto 1, uma tarefa muito difícil de se fazer pode receber voto 13, normalmente
quando uma tarefa recebe 20 pontos, os times entendem que a tarefa ou a estória está grande de
mais e deve ser quebradas em duas ou mais estórias e tarefas. Os membros do time que derem a
menor e maior nota, devem justificar o motivo de sua pontuação, pois eles podem ter verificado
algo que os demais membros do time, não consideraram, este é o maior ganho deste framework,
o time fica muito próximo e um acaba ajudando o outro.
Pode ser utilizado também o método de tamanho de camisa, sempre levando em conta o fator
complexidade versus esforço versus tempo e deve-se manter o processo de quem deu maior ou
menor pontuação justificando sua votação.

Conforme visto anteriormente, o Planejamento (Planning) deve ser dividido em duas etapas.
Na 1ª parte o PO vai selecionar os itens mais refinados e priorizados do Product Backlog e irá
apresentar para o time, como vimos o PO junto com time de DEV, lê as estórias e tira as dúvidas,
na 2ª parte da planning o time quebra as estórias e as estima. Nesta etapa é sugerido que o PO
não participe para não exercer influência sobre as atividades a serem desenvolvidas. Nesta o time
irá pegar cada estória e escrever quais atividades devem ser desenvolvidas para que a estória seja
considerada entregue. Durante a 2ª etapa o time pode fazer um outro corte e diminuir ainda mais
as estórias a serem entregues, visto que ao quebrar as estórias o time pode validar que estás são
mais complexas do que se imaginava anteriormente, isso é aceitável, pois isso a quebra das
atividades é executada na planning e não após o início da Sprint.
Com as estórias mapeadas e as atividades descritas, é definido o Sprint Backlog, com essa
informação na mão o PO deverá validar qual dos itens é considerado mais prioritário e que deve
ser considerado o objetivo principal da Sprint.
Rotinas de um time ágil
Daily
Executado diariamente na Sprint e deve ter um tempo total de 15 min.;
Ocorrer sempre no mesmo horário e mesmo local;
Presença de todo o time de DEV;
Scrum Master e PO não são obrigatórias;
O objetivo de existência é para o time de DEV saber o que cada um está fazendo, e se um membro
estiver com algum problema outro membro poça ajudar de alguma forma. É a cerimónia do Scrum
que agrega mais valor ao produto.
Três perguntas mágicas:
1. O que eu fiz ontem? 2. O que farei hoje? 3. Se possuo algum impedimento?
Retrospectiva
Acontece apenas uma vez na Sprint sempre após a conclusão da Sprint;
Participação Obrigatória do time de DEV e o Scrum Master. Nesta cerimônia a presença do PO é
muito importante, porém não é obrigatória;
É discutido os pontos que foram bons e ruins na Sprint, o que deve melhorar ou o não se deve
fazer e o que podemos tentar fazer na próxima sprint.
A essência da Daily e da Retro são exatamente as mesmas, a diferença é que a Daily está focada
nas tarefas do dia-a-dia e a Retro e focada na Sprint como um todo.
Refinamento
Acontece um passo antes da Planning no final da Sprint anterior;
Presença obrigatória de todo time Scrum;
Não é uma cerimônia oficial do Scrum, porém muito utilizada para que o Time de DEV juntamente
com PO discuta como será a próxima Sprint, quais serão os entregáveis e adiantar possíveis
dúvidas que normalmente apresentam na planning;
Tem a finalidade de aumentar o entendimento da demanda por parte do time, melhorar a
qualidade da entrega e aumentar o retorno esperado do projeto;
A ideia é facilitar a planning e torná-la muito mais efetiva e assertiva.
Review
Presença obrigatória do Time de DEV, PO, Scrum Master;
Nesta cerimônia são convidados todos os interessados na entrega, sejam eles os Stakeholders,
demandantes diretos, lideres técnicos e outros gestores;
Quem apresenta é o time de DEV;
Objetivo de apresentar o trabalho que cada um desenvolveu na Sprint anterior e poder tirar
qualquer dúvida técnica que o publico presente tenha em relação a solução. A ideia principal
dessa cerimônia é de fato ver o está sendo entregue, validar se está de acordo com a solicitação
inicial, validar se houve alguma mudança no meio do fluxo, bater com que foi definido no
refinamento e na planning e por fim e mais importante se agrega valor ao negócio.
Medir a maturidade do time através dos pilares do Scrum
Transparência
O time possuir transparência para o que acontece ao seu redor, transparência sobre as demandas
que estão por vir e possui transparência para saber se sua empresa está indo bem ou não, tem
muito mais capacidade e tranquilidade para poder desenvolver suas atividades.
Inspeção
O time que pode retornar para suas tarefas anteriores, verificar com resultado alcançado e cruzar
com os resultados esperados.
Adaptação
consegue entender melhor o comportamento do seu cliente ou usuário final e assim adaptar para
as novas entregas e fazê-la cada vez mais assertiva.