Scrum Tudo que você precisa saber @REVISTAVIRTUALBR

Prévia do material em texto

Introdução
Num mundo cada vez mais competitivo e com uma necessidade imensa de entregar resultados,
conhecer e participar da gestão completa dos processo dentro de um departamento, empresa,
negócio ou órgão é de vital importância, seja para melhorar a entrega ou simplesmente para obter
maior retorno sobre o trabalho executado.
Com isso em mente e na experiência adquirida durante a execução e acompanhamento de
alguns projetos e até mesmo durante a elaboração deste material, acabamos selecionando uma
metodologia para efetuar a gestão de projetos voltada para as pequenas e médias empresas, no fim
do material teremos uma sessão com alguns itens que utilizo como ferramentas de suporte e de
desenvolvimento, não fazem parte da metodologia mas são dicas e instrumentos que ajuda a
efetivar o proposto neste material .
Para quem é esse material?
Para quem já lida com gestão de projeto e gostaria de conhecer uma nova metodologia ou ter
uma visão diferenciada sobre a aplicação do material em novas situações.
Para quem está iniciando e gostaria de ter um framework bem versátil e capaz de se moldar a
diversas situações do dia-a-dia.
Para quem queira ter uma material para seguir nos momento de dúvidas ou até mesmo para os
intervalos entre um projeto e outro.
Bibliografia
Formação acadêmica em Ciência da Computação, com ênfase em Governanca em TI e
Engenharia de Software.
Com 10 anos de experiência na área de Tecnologia da Informação, com conhecimento amplo
em gestão de equipes, gerenciamento de projetos, implantação e manutenção de sistemas e ativos
de TI, e implementação de melhorias e processos de negócio em instituições sindicais.
Gestor de TI no Município de Araras com 130.000 habitantes do interior do estado de São
Paulo, atuação na construção de planejamento estratégico com foco na qualidade de serviços
prestados e no resultado institucional, interface entre a área de Negócios e TI e otimização de
recursos do município.
Desenvolvimento de equipes, atuando em rotinas de orientação, formando profissionais de alta
performance e alinhados aos objetivos da Prefeitura.
Gerenciamento de projetos, seguindo as práticas do PMI, envolvendo o controle de demandas,
definição do cronograma, análise da viabilidade, negociação de prazos e escopo, assegurando o
cumprimento dos prazos, custos e qualidade.
Fanático por buscar conhecimento e multiplicar os mesmos, encontrei na gestão um caminho
que acabou me permitindo estar próximo de duas coisas que sempre gostei, interação entre
pessoas e solução de problemas.
Gosto de pensar na aréa de TI como o logo antes tudo converge, onde os processos podem ser
otimizados e ao mesmo tempo humanizados.
Junto a atribuições da Gestão em TI, o caminho para palestra surgir e agrega conhecimento,
permitindo receber e transmitir muito mais informações para uma massa maior de pessoas.
Definições
Em TI não existe nenhuma bala de prata, e sim ferramentas que têm uma maior adaptação para
cada cenário, ou seja não existe uma solução única e exclusiva para um problema, geralmente é
possível chegar no resultado com várias soluções.
Definindo isso e de que esse material tem a principal característica de transmitir os
ensinamentos de gestão de projetos de modo ágil, vamos utilizar a metodologia ou melhor
framework denominada SCRUM, mas antes definiremos o que são as duas coisas:
Metodologia, são métodos orientados para um fim específico, são aplicados em um ambiente
ou cenário, já consolidado, dessa maneira é uma solução X para um problema Y.
Framework, são conjunto de regras ou princípios, são aplicados em vários ambientes ou
vários cenários, não existe a obrigatoriedade de se seguir passo a passo ou todas as regras e
princípios, é uma solução que encontra vários caminhos para se chegar no resultado para resolver
o problema Y.
O que é um projeto.
Segundo o PMBOK(escrever a definição de PMBOK), um projeto é um esforço temporário
empreendido para criar um produto, serviço ou resultado exclusivo.
Temporário porque deve ter começo e término, resultado exclusivo pois deve no seu término
entregar algo que aquela equipe/instituição ainda não foi capaz de executar.
Exemplos de projetos, Construção de uma residência, criação de um treinamento ,
desenvolvimento de um software, elaboração de um desenho de arquitetura, confecção de um
vestido, escrever um livro, planejar uma viagem,etc.
Ainda segundo o PMBOK, o sucesso de um projeto é medido pela qualidade da entrega e do
proejto, pela pontualidade, pelo cumprimennto do orçamento e pelo grau de satisfação do cliente.
[2]
Gestão de projeto
A gestão de projetos existe a um bom tempo e com várias roupagem, o que se encontra e é
muito utilizada é a gestão de projetos utilizando o modelo de cascata ou do inglês Waterfall, este é
uma metodologia mais clássica e tradicional.
Todas as etapas da gestão são seguidas de forma linear e sequencial, sendo elas : definição de
necessidades(requisitos), planejamento, execução e validação.
Só é permitido que o projeto avance quando uma fase está completamente finalizada,
voltar,pular ou avançar etapas não é permitido. Uma vez definida as necessidade ou requisitos
elas vão sofrer nenhuma ou quase nenhuma alteração do início ao fim do projeto.
Vantagem desse modelo
Por já se saber quais as necessidade e de antemão ter a visão de que os mesmos não sofreram
modificações é muito mais seguro para se avaliar os pormenores do projeto, com essa informação
já definida é possível entregar prazos e custos bem mais previsíveis, o que torna o projeto mais
fácil de ser gerenciado já que as etapas estão bem definidas.
Para as equipes a compreensão também se torna mais facilitada, pois os fluxos das atividades
já estão bem delimitadas
Desvantagem
Muito rígido quanto ao cumprimento das etapas, refazer qualquer modificação nas
necessidade, significaria um custo elevado.
Acaba entregando os resultado após a conclusão de todas as etapas, ou seja se for solicitado
que se crie um produto, o cliente só poderá ter em mãos uma amostra do mesmo no fim do projeto.
As mudanças do escopo não são bem vindas e quando acontece acaba desencadeando 
aumentos no cronograma e nos custos, mesmo que as mudanças venham para melhorar a entrega.
Quando utilizar ?
Para projetos onde os requisitos e escopo é muito bem definido e que os mesmo dificilmente 
serão alterados, se todas as necessidades estiverem bem claras, dentro de projetos da construção
civil essa metodologia é muito bem aplicada, para a execução da construção de um novo modelo
de avião também é um exemplo perfeito para a aplicabilidade da mesma.
-------------
Métodos ágeis para gestão de projetos
São abordagem em entregar o quanto antes o produto/serviço utilizando para isso um
planejamento adaptativo e evolucionários, onde equipes trabalham de maneira auto-organizadas e
multidisciplinares, procurando entregar em um prazo curto sempre uma nova funcionalidade ou
uma parte concreta do produto/serviço.
A ideia por trás dos métodos ágeis vem da década de 90, onde procurou-se algo novo antes as
metodologias que até o momento se encontravam engessadas e letárgicas, com isso em mente 17
desenvolvedores de software se uniram e criaram o Manifesto Ágil no início dos anos 2000, para
contextualizar esse início de milênio teve um grande avanço tecnológico em se tratando de
software como serviço e um nova metodologia era mais do que necessária para acompanhar essas
mudanças.
O manifesto ágil se sustenta em 4 sentenças :
Indivíduos e interações mais que processo e ferramentas.
Software em funcionamento mais do que documentação abrangente.
Colaboração com o cliente mais que negociação de contratos.
Responder a mudanças mais que seguir um plano.[3]
E utiliza os 12 princípios :
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 softwarefuncionando com freqüencia, na escala de semanas até meses, com
preferência aos períodos mais curtos.
Pessoas relacionadas à 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 seu 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 funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.[4]
Vantagem
Por se tratar de papéis onde se permite um maior engajamento e como a tomada de decisão é
distribuída entre todos do time, isso torna as equipes mais coesas e com um senso de
responsabilidade e de entrega muito maior, tornando o ambiente muito mais colaborativo.
Por se ter as entregas de maneira incrementar os custos e seu gerenciamento pode ser limitado
a cada funcionalidade.
O cliente pode determinar a prioridade das entregas, assim a equipe pode focar em entregar o
que se tem mais valor para o projeto.
Dessa maneira se evita excessos e desperdícios, acaba se focando no que realmente o
produto/serviço deve ter como prioridade e fornece melhor qualidade para o escopo.
Desvantagem
Implantar algum método ágil em uma equipe que ainda não está acostumada a trabalhar junto
exige uma boa dose de gestão de pessoas, em uma equipe heterogênea a aceitação é muito mais
fácil, durante a leitura desse material será possível entender esse cenário e como contornar essa
situação.
Novamente se a equipe ainda não trabalho junta, fica difícil mensurar prazos até porque não se
sabe qual a capacidade de entrega da equipe.
Quando se existe várias equipes trabalhando em várias partes do projeto as equipes podem
perder a visibilidade do projeto como um todo.
Como a prioridade é qualidade e pessoas, a documentação acaba sendo deixada de lado em
troca da entrega .
Mitos e Verdades sobre gestão ágil
Agilidade é algo recente.
O próprio manifesto ágil data do início do século XXI, ou seja já estamos falando de algo com
quase duas décadas, a busca por metodologias mais rápidas é algo já datado do início dos anos 70
com o processo de industrialização japones e as otimizações dentro das montadoras americanas.
Não precisamos de documentação.
Documentação deve existir, o que não pode é que a mesma seja maior do que a criação do
produto/serviço, criar a apenas a documentação necessária é bem diferente de criar qualquer
documentação.Menor documentação é diferente de não documentar.
É Apenas sair executando sem planejar.
Planejamento será sempre a base para qualquer estrutura de gestão , o que temos nos métodos
ágeis é que o planejamento ocorre paralelo a execução ou seja caso alguma mudança no escopo
ocorra ele pode ser corrigido de maneira mais rápida e com menor impacto de custos e prazos.
A equipe faz o que bem entender
A equipe é auto-gerenciável,fato. Porém ela deve entregar o que foi proposto e com os prazos
que foram pré definidos, a equipe sabe como fazer, mas deve ser cobrada em como entregar.
Isso só funciona para projeto pequeno.
Existe uma máxima ótima para se definir aqui: “Dividir para conquistar”, ter várias equipes e
mantê las organizadas com cada uma sabendo qual a parte do todo elas devem entregar , facilita o
entendimento e diminui as redundâncias das entregas.
Só funciona para quem é de TI
Nasceu na TI, mas é possível aplicar em quase todos os cenários onde se tenha pessoas,
prazos e entregas em que o escopo possa ser variado.
Métodos ágeis vão salvar o mundo .
Não!!! É apenas mais um item na caixa de ferramenta para ser utilizada em projeto, cabendo
ao gestor decidir se essa ferramenta é capaz de suprir o problema apresentado.
--------------------------------------------------
Scrum é o melhor ?
A resposta é depende. Como te mostrei até o momento existem prós e contras , vantagens e
desvantagens para o uso de metodologia ágil e SCRUM por se tratar de um framework ágil pode e
deve ser utilizado conforme o cenário apresentado para o projeto.
Durante os próximos materiais vou detalhar um pouco mais sobre SCRUM e aí sim o leitor
poderá dizer se esse framework é útil para o teu dia-a-dia e onde pode aplicar os ensinamentos
desse material.
Porque SCRUM?
 
Tive meu primeiro contato com metodologia ágeis ainda na graduação, era um tema que ainda
estava engatinhando e não era tão consolidado no mercado, as boas práticas estavam sendo
moldadas pelo mercado, porém já me cativou por três fatores que sempre orientaram a minha
carreira, pessoas acima de processos; lidar, entender e acima de tudo compreender que cada
indivíduo é único já nos auxilia e muito em vários aspectos da vida;Possibilidade de entregar algo
concreto bem antes do todo estar pronto, isso sempre foi algo que me incomodava já na
graduação, o cliente precisa tocar/sentir/provar do seu produto antes de investir totalmente e
perceber se é esse caminho mesmo que ele está esperando;Facilidade de entendimento do
SCRUM; não quer dizer que seja simples aplicar o material , mas de que compreender os
entregáveis e os papéis do framework é de fácil assimilamento, como demonstraremos neste
material.
Vamos ao SCRUM. :D
SCRUM como um framework para implementação de metodologia ágil é constituído de três
elementos principais são eles :
Artefatos: Itens a serem criados ou entregues durante o projeto, geralmente utilizamos eles
como documentação e material para complice.
Time-Boxes: Como toda gestão de projetos envolvem reuniões e contratos o SCRUM tem as
suas, de maneira mais ordenadas e objetivas, com locais e tempos de duração bem definidos.
Pessoas: As obrigações, alinhamentos e papéis são bem claros e cada integrante deve saber
até onde pode ir e como ir para o sucesso do projeto , e é nessa parte que mais gosto do SCRUM.
Pessoas
Dentro da nossa gestão de pessoas no SCRUM existem três papéis bem definidos são eles :
O Time:
São todos os elementos responsáveis por criar, desenvolver, dar vida ao projeto, são as
pessoas que produzem. É o grupo de pessoas que na somatória de suas características e
habilidades devem entregar o que foi pedido pelo cliente.
As principais responsabilidades das equipes são executar a Sprint(falaremos dela mais
para frente), de maneira auto-organizada e decidir coletivamente como planejar, gestar , efetuar o
trabalho e informar o andamento do projeto.
Participar do planejamento da Sprint, a equipe é responsável por estabelecer os itens para
a próxima Sprint, dizer quais itens são prioritários para a entrega da Sprint a ser iniciada.
Deve ser capaz de desprender um tempo para ajudar o Product Owner a fazer um
refinamento ou limpeza dos Product Backlog, dizendo qual a estimativa de tempo e priorização
dos itens a serem entregues.
Um Time Scrum precisa ter alguns itens como indispensáveis para que o projeto tenha uma
entrega baseada na qualidade de na satisfação do cliente:
Multifuncional → A equipe tem que ser capaz de entregar uma funcionalidade ou
característica funcional no final de uma Sprint, e para isso é de vital importância que seus
membros sejam capazes de possuir o conjunto de habilidades para esse fim, se o Time constar em
seu quadro apenas pessoas com conhecimento de uma única área, podem apenas fazer parte do
trabalho, acabam tendo que entregar a outra parte para uma outra equipe prosseguir com essa
atividade.
Esse tipo de multifuncionalidade acaba apresentando melhores resultados emtermos de
inovação e soluções com melhores prazos.
Manter um nível de experiência dentro meio que equilibrado nas equipes é um item que
deve ser buscado, pois assim o novato acaba trazendo um frescor e o mais experiente demonstra
os caminho das pedras, fazendo com que o Time evolua junto.
Coesão → O Time deve entender que as entregas são de todos, e não de um indivíduo, que
se trabalharem juntos conseguiram efetuar as entregas que eles mesmo separaram e priorização la
na fase de planejamento da Sprint, uma das frases principais de um Time deve ser: Cara, eu
acredito que consigo resolver isso, posso ?
Capacidade de comunicação→ Por serem multifuncionais, precisarem de coesão, o Time
deve possuir uma comunicação bem efetiva entre seus integrantes e entre as figuras do Scrum
Master e do Product Owner. Trabalhar com a comunicação dentro do Time, melhora e muito o
processo de adaptação e tempo de respostas para as mudanças e otimiza as tomadas de
decisões.Essa inclusive é uma característica muito marcante dentro do manifesto ágil, a interação
entre as pessoas e de preferência pessoalmente .
Acima de tudo a comunicação deve ser sempre transparente e franca, evitando ruídos e
melhorando a confiança entre os membros do Time.
Tamanho certo da equipe
Existem várias possibilidades aqui, muitos autores sugerem que as equipe tenham de 3 a 9
integrantes, na minha experiência prefiro trabalhar com equipes de 4 a 6 pessoas, pois se gasta
menos tempo para coordenar essas equipes, as pessoas acabam se sentindo melhor ao trabalho
com equipes menores, a proximidade entre os indivíduos favorece o clima de união entre os
integrantes. Mas ter equipes pequenas não quer dizer necessariamente que em um cenário onde
temos 24 profissionais não saberíamos o que fazer com os mesmos, não pelo contrário,
otimizamos e contruimos 4 equipes de 6 pessoas e aplicamos os conceitos normalmente.
Entrosamento
Procuro sempre me referir ao Time como uma equipe, por isso é importante manter sempre as
peças chaves da equipe juntas, isso reflete em um maior entrosamento, em um ganho de confiança
entre os membros e principalmente a capacidade de prever onde o outro pode ajuda e onde pode
ajudar o outro, isso eleva a moral da equipe e carrega a produtividade de todos a um ótimo nível.
-------------
O Product Owner :
Este é o membro da equipe SCRUM que tem como principal definição de ser o elo de ligação
entre o cliente e o Time, é dele a obrigação de criar as estorias, dizendo exatamente qual a
funcionalidade esperada dessa entrega e principalmente garantir que se um item entrou na spring
este item é de necessidade para aquela entrega.É o único que tem o poder de dizer se uma estória
está finalizada, ele também responder por priorizar os itens no Backlog, permitindo que a equipe
saiba qual funcionalidade deve ser atribuída para a sprint.
Não deve ser encarado como apenas um cargo, é mais como um papel mesmo, de preferência
seja alguem que ja conheça as dores ou necessidades que as entregas vão sanar.
Comunicação → esta é a capacidade primordial para um Product Owner, se ele vai transitar
entre o cliente e o Time é de se esperar que saiba falar a linguagem dos dois grupos e que consiga
passar a imagem do que ambos os lados espera, o cliente quer ter suas necessidades supridas e
busca por melhores prazos em cima dos teus investimento e o Time procura solucionar da melhor
maneira possível com qualidade a estória apresentada. Durante o planejamento da Sprint o
Product Owner é responsável por responder e tirar todas as dúvidas do Time sobre os detalhes ou
funcionalidades da estória que estão entrando na Sprint.Deve dar uma visão bem clara do que se
espera de cada Sprint.
Lapidação das estorias → Após colher feedbacks de todos os envolvidos com o projeto,
deve manter, refinar e adicionar itens ao Backlog do produto, tendo sempre como prioridade
entregar valor ao cliente, aliado a prazos e custos para esses itens .
Dizer não → O Product Owner deve saber quando dizer não para o Time, não para o cliente e
para qualquer situação que não será benéfica para o produto/serviço que será entregue, um bom
Product Owner deve ter embasamento para mostrar o valor da sua decisão e como isso pode
impactar o projeto como um todo ou como esse item não vai entregar valor no final da Sprint.
Saber identificar essas peculiaridades e transmiti las a todos é uma maneira de otimizar e
valorizar o trabalho de todos.
Identificar o que o cliente quer → Este é o papel principal do Product Owner, entender o que
o cliente realmente tem em mente, qual o problema ou necessidade que ele está querendo ter
suprida e transformar isso em algo que o Time possa trabalhar, o Product Owner deve ter
autonomia total, para não acabar virando apenas um garoto de recado dentro do projeto, caso
contrário vai ficar apenas preocupado em atingir um prazo do que realmente a entrega da
funcionalidade.
Focado na entrega → Não deve confundir ser a voz do cliente com o ser o cliente, a entrega
da funcionalidade e dizer que ela está de acordo com o solicitado deve ser a principal razão do
Product Owner dentro do SCRUM.
-------------
O SCRUM Master :
Responsável por fazer o SCRUM acontecer e tem principal papel de garantir que todos
envolvidos no projetos conhecem e pratique os valores do SCRUM, não deve deixar que nada ou
ninguém cause impacto no Time e na sua entrega.
Se o Product Owner tem que garantir a entrega com qualidade das funcionalidades o SCRUM
Master deve ser um facilitador para que o Time entregue com qualidade as funcionalidades.
Deve sempre estar focado em potencializar o trabalho do Time, resolver impedimentos
Promover mudanças organizacionais,garantindo que os valores do SCRUm sejam aplicados da
maneira correta; ser neutro e saber o momento certo de dar um passo para trás e observar como
está o panorama do projeto como um todo para depois tomar a decisão; resolver conflitos de
interesse, tanto da equipe , como dos indivíduos de tal maneira que clima seja mantido e a Sprint
não seja prejudicada; Esse são algumas das funções de que o SCRUM Master deve executar no
seu dia-a-dia.
Resumidamente:
o Product Owner está focado em determinar e indicar o que é esperado como resultado do
produto, ele representa o que o cliente deseja receber na entrega.
O Scrum Team é uma equipe multidisciplinar que irá atuar no desenvolvimento do projeto,
incluindo arquitetura, codificação, testes, documentação e demais atividades objetivando entregar
as funcionalidades.
O Scrum Master é o responsável por manter as práticas Scrum, apoiar os outros papéis e
manter a comunicação e colaboração ativa.
----------------------------
Entregáveis
Como toda forma de controle de projetos dentro do SCRUM também existe os conceitos de
material entregável ou documentavel, esse material recebe o nome de artefatos e consta com itens
que são usados para se entender o que se espera da entrega da Sprint e ter uma visão geral do
acompanhamento seja por meios gráficos ou por datas de entrega.
Product Backlog
Se trata de uma lista contendo breves estorias com as funcionalidades desejadas e que permite
que a equipe inicie as interações da Sprint.
Durante a reunião de início da Sprint o Product Owner junto com o Time escrevem as estorias
que são de maior prioridade e colocam elas no Product Backlog. Os itens adicionados no Product
Backlog provavelmente sofreram mudanças e acréscimos no decorrer do projeto, a medida que se
entende mais sobre o cliente e sobre o produto/serviço a ser entregue.
Estorias
Sendo bem simplista estorias dentro das metodologias ágeis, é um descrição da funcionalidade
esperada após a interação dessa estorias. Não existe um caminho definido de como se escrever
uma boa estória, mas existem 3 perguntinhas básicas que se respondidas ajuda e muito a
construção das estorias : Quem? Nos diz o ator que precisa dessa funcionalidade.
O quê? Qual a funcionalidade que é preciso.
Por Quê? Está funcionalidade ira entregar o que de valor ?
Três exemplos são :
1. Como USUÁRIO, preciso que ao abrir uma porta, ela envia um sinal ao meu
smartphone de quanto tempo ficou aberta.
2. Como PROPRIETÁRIO, devo selecionar quais funcionários devem fazer escalas
dentro da empresa no período.
3. Como RH, preciso de um relatório com o total de horas extras por funcionários
dentro do mês.
Lembrando que toda estória deve entregar algo de valor, um estória coesa deve ser entendida
por qualquer pessoa, não importa o seu nível técnico.
Para completar as estorias os termos de aceite devem ser definidos, sem muito termo técnico e
detalhamento, deve descrever o suficiente para que a estória não tenha problemas de execução,
sempre pensando nas restrições, regras ou condições para que essa estória esteja dentro do
projeto.
Pensando nos três exemplo acima, os seguintes termos de aceite poderiam fazer parte:
1. Usuário :
1. Deve ter um smartphone cadastrado.
2. Porta deve contar com um sensor.
3. Tempo deve ser medido em segundos.
 
2. Proprietário
1. Pode escalar quantos funcionários precisar.
2. Feriados devem ter escalas diferentes.
3. Só pode existir um proprietário.
 
3. RH
1. Deve permitir selecionar qual o mês da pesquisa.
2. Relatório pode ser enviado por email, em pdf.
3. Precisa filtrar por área da empresa.
Pensando no peso de cada itens e nas suas prioridades a equipe oa montar e selecionar qual
item irá trabalhar deve levar em consideração as seguintes influências:
Relação entre os itens, se a função X for feita primeiro o item Z pode se tornar mais simples
de implementar;
Urgência, entregar item X vai permitir que o teste ocorra o mais próximo possível da
realidade;
Prioridade feita pelo cliente, a funcionalidade Z é de supra importância para que o cliente já
inicia os trabalho;
Dificuldade, pode ser que a equipe não tenha conhecimento ou até mesmo a estória não esteja
tão clara sobre a funcionalidade a ser entregue.
Outras entregas
Para cada Sprint, geralmente fazemos um SPrint Backlog, são as estorias ou itens divididos
para essa Sprint, com equipes já acostumadas com o SCRUM é fácil medir e selecionar quais
itens entram em uma Sprint, pois já conhecem a sua capacidade de entregar. Para equipes que
estão iniciando com o framework se recomenda que as Sprint iniciais sejam medidas no fim da tua
entrega e com essa valor em mãos nas próximas Sprints a equipe já seja capaz de mensurar o que
consegue entregar.
Não basta apenas construir o Product Backlog é preciso aprimorar e fazer com que ele esteja
sempre alinhado com as necessidades. O Product Owner é o responsável por garantir que as
últimas correções, feedbacks e novidades estejam atualizadas dentro do Product Backlog, esse
processo de atualização e de refinamento é chamado do Backlog Grooming, ou processo de
higienização.
Com esse procedimento é possível que o Product Owner consiga algumas respostas que
somente as interações não são suficientes para fornecer, permitindo que pára a próxima interação
o mesmo adicione ou entenda alguma funcionalidade que não foi incluída no Sprint Backlog.
Dentro do SCRUm uma maneira de monitorar o progresso é através de um gráfico de
Burndown, onde o eixo horizontal exibe o tempo da Sprint, do início até a sua conclusão estimada
e o eixo vertical mostra a quantidade de trabalho que ainda deve ser feito.
Alimentação deste gráfico, deve ser feita após a entrega de cada funcionalidade , criando um
ponto entre o eixo horizontal e vertical, existirá uma linha ideal
Com o uso desse tipo de gráfico é possível acompanhar o que foi planejado e o que está sendo
realmente entregue pela equipe, dessa maneira é possível corrigir prazos e prioridades dentro do
projeto.
_________________
Times boxes
Dentro do SCRUM existe um conceito de trabalhos executados por um determinado limite de
tempo já pré definido, é uma abordagem bem simples mas de supra importância para o
gerenciamento do projeto, pois sempre teremos um prazo ou uma data para todos os eventos ou
artefatos dentro do SCRUM.
Respeitar e entender esses prazos e suas limitações de tempo, ajuda o Time a focar no que é
mais importante a ser entregue, evitando desperdícios e distrações, melhorando assim a
responsabilidade do Time quanto a entrega do projeto.
Ao se adotar o conceito de Timebox algumas vantagens acabam aparecendo :
● O Time se sente mais motivado pois sabe que seu tempo é valorizado;
● As procrastinações são evitadas ao máximo, as tarefas difíceis são identificadas logo no
início;
● O Time tem total clareza de qual a tua capacidade de entrega e quanto é possível entregar
em uma Sprint.
● Reuniões e pautas são otimizadas, mais objetivas, com base em já se saber qual tempo
terá de duração.
Porém se for utilizado uma rigidez muito excessiva, pode se levar a desmotivação e com isso
o conceito de um ambiente propício à colaboração não é alcançado.
SPRINT
É o principal evento dentro do SCRUM, é nesse intervalo de tempo que serão aplicados os
demais eventos, aplicar os artefatos produzidos e desenvolver de fato o produto ou serviço para o
cliente, é dentro da SPRINT que as funcionalidades são criadas.
Sprint são como etapas de projetos, é um espaçamento de tempo onde tudo deve ocorrer e
depois é possível medir o teu projeto em SPRINT’S.
Uma SPRINT tem início com uma reunião de planejamento, com seu tempo fixado em até 8
horas para SPRINT com até 4 semanas de duração. Durante a reunião de planejamento o SCRUM
Master, deve garantir que o TIME entenda os propósitos e as funções de cada um dentro da
SPRINT.
Com a planejamento já executado a equipe parte para o desenvolvimento e criação das
funcionalidades que foram separadas do Product Backlog é foram colocadas dentro do Backlog da
SPRINT, ou seja as funcionalidades que serão entregues no fim do prazo de 4 semanas. O SCRUM
Master deve remover qualquer item ou dificuldade que impeça o TIME de conseguir entregar as
funcionalidades, deve remover todos os empecilhos.
Possui como prazo de 1 a 6 semanas, sendo 1 semana para projetos com equipes muito
reduzidas, e projetos com baixa complexidade. De 2 a 4 semanas para projetos onde a aplicação
de SCRUM já tem um grau de amadurecimento , e até 6 semanas para projetos maiores e que não
tenha possibilidade de tantas mudanças;
Reunião Diária
Não tem muito segredo a reunião diária (ou no Inglês Daily Scrum) como o próprio nome já
diz é um encontro entre os membros da equipe que deve ocorrer uma vez por dia sempre no
mesmo local, com prazo máximo de 15 minutos, onde os mesmo interagem e posicionam quanto
aos trabalhos executados e a serem executados e os impedimentos que emperram o avanço da
equipe.
Para quem está no início de aplicar esse framework, esse evento deve ser um dos primeiros a
ter o seu peso entendido pela equipe, mesmo que não se use exatamente como o Scrum recomenda,
mas apenas trazer a sua essência para as reunião cotidianos já melhor e muito o engajamento,
comunicação e o ganho de produtividade.
Com base nos três pilares do Scrum, a inspeção (referente ao progresso), a adaptação diária
(ajustar e se livrar do impedimentos) e transparência (todos devem conhecer o todo), a reunião
diária nos deixar com três perguntas que deve ser respondida por todos da equipe e na frente de
todos:
1. O que eu fiz ontem ?
2. O que eu farei hoje ?
3. Existe algum obstáculo que me atrapalha ?
Reuniões extensas são uma das piores maneira de se começar um dia, suga a energia das
pessoas e ficamos pensando o quanto falta para essa tortura acabar, pensando nisso o Scrum acaba
tornando essa reunião diária no formato time-boxed, ou seja com tempo fixo que no nosso caso é
15 minutos. Tornando a reunião produtiva e não permitindo que se perca o foco.
Uma recomendação interessante é que essa reunião seja em pé, evitando assim longas
respostas e ao mesmo tempo incentivando que os membros olham um nos olhos dos outros durante
as respostas.
Fazer esse evento sempre no mesmo local e horário (deve sempre começar no horário
estipulado,mesmo que um membro não tenha chego), condicionaa equipe a saber que nessa hora e
nesse ambiente o foco é total em responder às três questões iniciais, mais uma maneira de elevar a
comunicação entre os membros e tornar a reunião produtiva.
Dito isso uma reunião diária acontecer mais ou menos
com esse script :
É obrigação do Scrum Master, organizar para que essa reunião aconteça, deve separar o local
e disponibilizar o horário para todos da equipe.
Com tudo já preparado dá se início a reunião, geralmente o Scrum Master dá a palavra ao
membro mais próximo, do lado direito e este responde as perguntas (lembrando que as respostas
devem ser feitas direcionadas a equipe e não ao Scrum Master), assim sucessivamente até que
todos da equipe tenham respondido.
O Scrum Master atualiza o BurnDown Chart , e o Kanban , se eles existirem no contexto dessa
Sprint; Ele deve atualizar os seus registro de impedimentos e começar a trabalhar neles para
resolver assim que a reunião acabar.
Os integrantes da equipe podem conversar entre si, para discussões detalhadas ou até mesmo
para adaptar algo do trabalho na Sprint, porém isso não faz parte da reunião.
Pronto. Temos um roteiro básico para uma reunião diária.
Reunião de planejamento da Sprint
Para uma Sprint de 4 semanas se aplica uma reunião de 8 horas.
A reunião de planejamento da Sprint é um momento importante para decidir o que será
feito na próxima Sprint. Mas qual a importância desse momento existir?
Como vocês já sabem, uma Sprint começa logo após a conclusão da anterior, e esse início é
feito com as duas reuniões de planejamento da Sprint.
A decisão do que será feito na próxima Sprint é um acordo feito entre a equipe e o Product
Owner durante o planejamento, e o que for combinado deve ser apresentado no final da Sprint, na
reunião de Revisão.
É simples e é direto.
Existe uma reunião para decidir o que será feito na Sprint e ponto final. Aquilo precisa ser
entregue no final da Sprint.
O planejamento de Sprint não precisa ser um desafio, pois todos só precisam trabalhar em
conjunto para responder à pergunta “Com o que podemos nos comprometer?”
Normalmente acaba sendo uma oportunidade para toda a equipe de Scrum estabelecer o
espírito de camaradagem e entender como poderá se ajudar naquilo que tem pela frente.
Este é o momento do acordo que a equipe faz de compromisso com aquilo que será entregue.
Garantir um bom planejamento é incluir todos os detalhes da Sprint que vem pela frente,
elencando tudo que será feito e também o que não será feito.
Durante as Reuniões de Planejamento da Sprint, as Histórias de Usuários, que são aprovadas,
estimadas e comprometidas, são discutidas.
Cada membro da equipe Scrum faz uma estimativa rápida das tarefas usando ferramentas como
planejar o poker. Se as discussões começarem a levar mais tempo, isso significaria que as
histórias do usuário não estavam completamente prontas para serem tomadas para o Sprint.
A equipe chega a um consenso sobre a quantidade de trabalho que precisa colocar neste
Sprint.
Fazer um bom planejamento é importante para o sucesso da equipe durante a Sprint. Quanto
mais conhecimento a equipe tiver sobre o que deverá ser feito, mais fácil será para a equipe
concluir suas tarefas.
É possível que o planejamento da Sprint seja feito de forma equivocada ou então que
apareçam imprevistos durante a Sprint. Caso isso aconteça, é preciso rever o que foi acordado ou
até mesmo cancelar a Sprint.
As funcionalidades a serem implementadas em um projeto são mantidas no Product Backlog.
 
Reunião de revisão da Sprint
Sua janela de tempo é de 4 horas para uma Sprint de 4 semanas.
Ao final de cada Sprint, uma Revisão da Sprint é realizada. Durante esta reunião, o Time de
Desenvolvimento apresenta o que foi realizado durante a Sprint. Tipicamente, esta apresentação é
feita na forma de uma demonstração das novas funcionalidades. O projeto é avaliado baseado na
Meta da Sprint, determinado durante a Reunião de Planejamento da Sprint. O ideal é que a equipe
tenha concluído todos os itens do Backlog do Produto alocados para a Sprint, mas é mais
importante que eles alcancem a Meta da Sprint.
Participantes da Revisão da Sprint, tipicamente inclui o Product Owner, o Time de
Desenvolvimento, o Scrum Master e outros que se fizerem necessários, cujo feedback é
considerado importante.
O propósito da reunião da Revisão da Sprint não é o de se obter a aprovação formal dos
clientes sobre o que foi feito na Sprint, ou seja, polegar para cima ou carimbo de “aceito” no
contrato. Não é uma sessão de testes de aceitação, tampouco. A aprovação para se concretizar
uma entrega deve ser feita em outro momento, fora do contexto do Scrum.
O objetivo da reunião da Revisão da Sprint é de se obter feedback do cliente sobre
o Incremento do Produto gerado na Sprint e, com isso, poder frequentemente fazer ajustes de
direção, diminuindo os riscos do projeto. É trabalho — e obrigação — do Time de
Desenvolvimento e do Product Owner puxarem esse feedback dos clientes e demais partes
interessadas presentes. Convidá-los a usarem o produto ali mesmo. Instigar. Fazer perguntas.
Mostrar alternativas. O Product Owner utilizará o feedback obtido nessa reunião como matéria-
prima para modificar o Backlog do Produto para Sprints futuras. É, portanto, uma reunião de
inspeção e adaptação do produto.
Ou seja, o espírito da Revisão da Sprint não é:
● Cliente, o que fizemos está aprovado?
Mas talvez algo assim:
● Cliente, agora que você está tendo a oportunidade de ver funcionando (e
experimentar!) esse Incremento do Produto que fizemos para você nessa Sprint, o que
podemos modificar ou adicionar a ele para melhor atender às suas necessidades?
Uma vez que o foco da apresentação é colocado na Meta realizada, o Incremento do Produto
pode ser demonstrado como um todo. Alternativamente, muitos times apresentam e demonstram os
itens desenvolvidos durante a Sprint um a um, do mais importante ao menos importante. Clientes e
demais presentes trabalham colaborativamente com o Time de Desenvolvimento e com o Product
Owner, fazendo perguntas e obtendo respostas sobre o que lhes está sendo demonstrado, e
apresentando suas ideias sobre o que esperam do produto nas próximas Sprints.
É uma excelente prática convidar os presentes a experimentarem diretamente o produto. Isso
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/roles/scrum_team_8D8F2B3.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_planning_meeting_9F0B8F28.html
https://www.trt9.jus.br/pds/Scrum/workproducts/product_backlog_68345C16.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html
https://www.trt9.jus.br/pds/Scrum/roles/scrum_team_8D8F2B3.html
https://www.trt9.jus.br/pds/Scrum/roles/scrummaster_357FCB70.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/workproducts/potentially_shippable_product_incremement_69E6418C.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/roles/scrum_team_8D8F2B3.html
https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html
https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html
https://www.trt9.jus.br/pds/Scrum/workproducts/product_backlog_68345C16.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/workproducts/potentially_shippable_product_incremement_69E6418C.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/workproducts/potentially_shippable_product_incremement_69E6418C.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/roles/scrum_team_8D8F2B3.html
https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
os estimulará a fornecerem feedback e permitirá que esteseja mais profundo e preciso. No
entanto, a Reunião de Revisão não é uma reunião para testes do produto e, assim, não deve ser
utilizada para substituir práticas de testes que devam ser realizadas ao longo da Sprint.
É igualmente interessante perguntar aos presentes o que esperam ver pronto nas próximas
reuniões de Revisão da Sprint. Ou seja, estimulá-los a elaborar sobre quais são as próximas
necessidades de negócios mais importantes a serem atendidas.
Caso haja, na reunião de Revisão da Sprint, itens da Sprint não prontos de acordo com
a Definição de Pronto, eles podem retornar ao Backlog do Produto e reaparecerem no próximo ou
em alguma das próximas Sprint. Pode-se também decidir que sejam eliminados, se assim fizer
sentido a partir do feedback obtido ou de outras questões de negócio. É papel do Product Owner,
e apenas dele, decidir o destino desses itens.
 
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/guidances/concepts/definition_of_done_B24C5541.html
https://www.trt9.jus.br/pds/Scrum/workproducts/product_backlog_68345C16.html
https://www.trt9.jus.br/pds/Scrum/tasks/sprint_D001FECD.html
https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html
Reunião de Retrospectiva da Sprint
Com a Sprint de 4 semanas, essa reunião tem um Time Box de 4 horas
Uma retrospectiva no Scrum é basicamente o seguinte: no fim de cada Sprint, o time se reúne
para falar sobre o processo. O que funcionou? O que não deu certo? Como eliminar os obstáculos
no próximo Sprint?
Antes de reunir todo mundo em uma sala e desabafar sobre as frustrações, é importante
entender os papéis e as metas de uma retrospectiva no Scrum.
Um dos principais pilares da metodologia Ágil é a ideia da melhoria contínua na
produtividade da equipe.
Todo Sprint deveria ser um pouco mais eficiente do que o último. A única forma de fazer isso
é entendendo onde estão os pontos fracos do processo e implementando estratégias para superá-
los.
Há inúmeros métodos para fazer uma retrospectiva no Scrum, mas você precisa conhecer
alguns papéis e regras essenciais para que ela dê certo.
Funções e participantes
Facilitador: A pessoa que age na função de facilitadora dita o fluxo da reunião —
redirecionando os assuntos irrelevantes, fazendo perguntas instigantes e monitorando o tempo.
Tem que ser uma pessoa imparcial na reunião, dirigindo o assunto, mas sem participar.
Por mais que você ache mais seguro atribuir essa função a um gerente, Silvi acha melhor não,
pois as pessoas podem hesitar em apontar erros. “O ideal é ter alguém de fora da equipe que seja
imparcial.
Se não for possível, gosto de ter alguém de nível júnior ou intermediário, assim eles têm uma
oportunidade para desenvolver habilidades de liderança sem a responsabilidade do poder
hierárquico.”
Participantes: A retrospectiva não deveria ser uma reunião do tipo “aberta para todos”. Só
quem realmente precisa estar lá deveria estar. Silvi também recomenda que líderes de nível sênior
não estejam presentes para que ninguém se sinta desconfortável na hora de falar sobre erros.
Outras regras para o sucesso:
● Não usar celular ou notebook. Todos devem se concentrar na conversa.
● Não fazer anotações, exceto para definir os planos de ação como equipe para o próximo
Sprint.
● Este é importante: não apontar o dedo tentando achar culpados.
Ter certeza de que todo mundo na reunião pressupõe a melhor das intenções quer dizer que
todo mundo tem uma abordagem positiva na conversa.
https://br.blog.trello.com/dinamicas-retrospectivas-scrum/
https://blog.trello.com/br/como-fazer-reunioes-eficazes-sem-notebooks
Decidindo o assunto
Um erro comum, (além de atribuir culpa) nas reuniões de retrospectiva no Scrum, é tentar
fazer muita coisa. Inevitavelmente, seu time vai querer melhorar uma longa lista de processos, mas
tentar consertar todos em um Sprint não é nada realista. Seu time precisa decidir em grupo qual o
único item que querem tratar e como consertá-lo.
Depois, a equipe trabalha junto para dividir as anotações em categorias. Se três Post-Its tratam
da comunicação da equipe, eles ficariam juntos. Então, cada membro da equipe vote na categoria
que quer tratar no próximo Sprint. Ele media isso ao dar três adesivos para cada pessoa, que elas
usam para “votar” na categoria que mais querem discutir.
“É importante que o time vote em uma categoria que seja possível tratar e resolver,”
https://blog.trello.com/br/ferramenta-de-brainstorming
Debate
Assim que você contar os votos, já vai poder se preparar para debater o problema. A pessoa
agindo como facilitador tem um papel importante nessa parte da reunião, pois os debates tendem a
fugir um pouco do assunto. Podemos usar os “cinco por quês” — ouvir uma descrição de um
problema e perguntar “por quê” cinco vezes — para chegar até a raiz do problema.
“Estamos perdendo tempo criando coisas que não eram necessárias.”
“Por quê?”
“Porque não sabíamos que não eram necessárias.”
“Por quê?”
“Porque não nos comunicamos com o time de produto antes de começar o trabalho.”
“Por quê?”
E assim por diante.
Quando todos concordarem com o plano de ação, os itens podem ser registrados e
implementados no próximo Sprint, ajudando o time a agir com continuidade e agilidade.
De pequenos passos a grandes melhorias
Não dá para negar. Reuniões de retrospectiva no Scrum podem dar uma intimidada,
especialmente se você ainda está aprendendo o processo.
Lembre-se, você não está tentando resolver todos os seus problemas de uma só vez. A beleza
do Scrum é a melhoria gradual. Ao consertar continuamente os itens pequenos, seu time fica mais
feliz, mais produtivo e passa menos tempo lidando com dores de cabeça recorrentes.
 
---------------------------------------------
Apresentar isso no final
Resumidamente:
o Product Owner está focado em determinar e indicar o que é esperado como resultado do
produto, ele representa o que o cliente deseja receber na entrega.
O Scrum Team é uma equipe multidisciplinar que irá atuar no desenvolvimento do projeto,
incluindo arquitetura, codificação, testes, documentação e demais atividades objetivando entregar
as funcionalidades.
O Scrum Master é o responsável por manter as práticas Scrum, apoiar os outros papéis e
manter a comunicação e colaboração ativa.
 
 
[2]PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia para o
Conjunto de Conhecimentos em Gerenciamento de Projetos, Sexta edição, Pennsylvania: PMI,
2017.
http://amzn.to/2xiCc3X
[3]http://www.manifestoagil.com.br/
[4]http://www.manifestoagil.com.br/principios.html
	[2]
	[3]
	[4]