A2 Trabalho pronto scrum Xavier

Prévia do material em texto

1 
 
FACULDADES METROPOLITANAS UNIDAS – FMU 
Campus Liberdade 
Departamento de Ciências Exatas e Gerenciais 
Curso de Gestão de Tecnologia da Informação 
 
 
 
 
 
 
 
 
 
 
 
GOVERNANCA EM TI 
SCRUM 
 
 
 
 
 
 
 
 
 
 
 
Orientador: WAGNER XAVIER 
 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
2016 
 
2 
 
SCRUM 
 
 
 
BIANCA PAES DA SILVA – RA: 6827381 
BRUNO WENDELL MARQUES FERREIRA – RA: 6324679 
GABRIEL DE SOUZA AGUIAR – RA: 6742115 
GABRIELA GIMENEZ FELISARI – RA: 5482783 
THONY LUCAS FERREIRA DA SILVA – RA: 6780106 
 
 
 
 
 
 
 
 
Faculdades Metropolitanas Unidas - FMU. 
 
Professor Orientador: WAGNER XAVIER 
 
 
 
 
SÃO PAULO 
2016 
 
 
 
3 
 
SUMÁRIO 
1.Conceito: O que é o Scrum? ................................................................................... 04 
2.Porque o Scrum não é considerado uma metodologia? .......................................... 04 
3.Origem: De onde veio o Scrum? ............................................................................ 04 
4.Manifesto ágil de desenvolvimento de software .................................................... 04 
5.Os autores do Manifesto Ágil são........................................................................... 05 
6.O manifesto contém quatro valores fundamentais ................................................. 05 
7.Responder a mudanças mais do que seguir um plano. ........................................... 05 
8.Papéis: O Time Scrum ............................................................................................ 06 
9.Time de desenvolvimento ....................................................................................... 06 
10.Product Owner ...................................................................................................... 06 
11.Scrummaster ......................................................................................................... 06 
12.Artefatos do Scrum ............................................................................................... 06 
13.Backlog do Produto .............................................................................................. 07 
14.Monitorando o Progresso a Caminho do Objetivo ............................................... 08 
15.Backlog da Sprint ................................................................................................. 08 
16.Monitorando o Progresso da Sprint ...................................................................... 08 
17.Incremento ............................................................................................................ 09 
18.Transparência do Artefato .................................................................................... 09 
19.Os Eventos do Scrum (TO DO) ............................................................................ 09 
20.Quadro Branco ...................................................................................................... 10 
21.Eventos do SCRUM ............................................................................................. 11 
22.Sprint .................................................................................................................... 11 
23.Time-boxed ........................................................................................................... 11 
24.Planejamento da Sprint ......................................................................................... 11 
25.Definição de “Pronto” .......................................................................................... 12 
26.Implementando o Scrum: Como começar? .......................................................... 13 
27.Objetivo do Sprint? ............................................................................................... 14 
28.Empresas que Utilizam o Scrum .......................................................................... 16 
29.Bibliografia ........................................................................................................... 17 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
1. Conceito: O que é o Scrum? 
 
“O Scrum é um framework ágil, simples e leve, utilizado para gestão do 
desenvolvimento de produtos complexos. Scrum é embasado no empirismo e utiliza uma 
abordagem interativa e incremental para entregar valor com frequência e, assim, reduzir os 
riscos do projeto. ” (SABBAGH, 2013) 
“O Scrum é um framework para projetos ágeis utilizado para o gerenciamento e 
desenvolvimento de produtos, com a característica de ser iterativo e incremental. “ (DIAS, 
2013) 
 
2. Porque o Scrum não é considerado uma metodologia? 
 
“Um dos erros mais comuns ao se falar em Scrum é defini-lo como uma metodologia, 
algo que de fato ele não é, e vou explicar porque. Uma metodologia é o estudo de métodos e 
técnicas embasados científicamente utilizadas em processos de investigação. Diferente de um 
processo mais tradicional o Scrum não irá te dizer o que fazer, você tem a liberdade para fazer 
o que melhor funcionar dentro da suas necessidades e possibilidades. Os pilares do Scrum, 
transparência, inspeção e adaptação é que nos fazem melhorar nosso processo e isso vem 
apenas com tempo, com as evidências de melhoria contínua. Isso já afirma que nosso 
processo necessita desses três pilares para garantir sua sustentabilidade e evolução. Sendo 
assim podemos dizer que não temos a solução nem mesmo a pretensão de prever tudo ou ter a 
resposta para todas as perguntas. Em uma metodologia todos os processos são conhecidos e 
previamente definidos, ou seja, prescritivos, diferentemente do Scrum onde o processo de 
aprendizado é empírico. Acreditamos que cada experiência traz um aprendizado que deve ser 
levado em consideração dentro do processo de controle. “ (CARLOS, 2011) 
 
3. Origem: De onde veio o Scrum? 
 
“Historicamente, o termo Scrum surgiu pela primeira vez em um atigo publicado por 
Hirotaka Takeuchi e Ikujiro Nonaka na Harvard Business Review de 1986. Neste artigo, 
intitulado “O novo jogo do desenvolvimento de produtos”, Takeuchi e Nonaka descreveram 
uma abordagem holística, na qual equipes de projeto são compostas de pequenas equipes 
multifuncionais, trabalhando com sucesso rumo a um objetivo comum, que os autores 
compararam à formação Scrum do rugby. ” (PHAM, 2012) 
 
4. Manifesto ágil de desenvolvimento de software 
 
“Iniciado em 2000 como resposta aos diversos fracassos nos projetos de softwares que 
utilizavam processos de desenvolvimento tradicionais, fadados ao fracasso por requisitos e 
especificações incompletas ou a falta de envolvimento do cliente no projeto, foi criado o 
manifesto ágil. Este foi um projeto que reuniu diversos profissionais de desenvolvimento de 
software com o objetivo de discutir melhores práticas no processo da construção destes. ” 
(OTÁVIO, 2015) 
 
5 
 
5. Os autores do Manifesto Ágil são: 
 
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn Ward Cunningham 
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt Ron Jeffries Jon Kern, Brian 
Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,Dave Thomas. 
 
6. O manifesto contém quatro valores fundamentais: 
 
Indivíduos e interação entre eles mais que processos e ferramentas; 
Software e funcionamento mais que documentação abrangente; 
Colaboração com o cliente mais que negociação de contratos, e 
 
7. Responder a mudanças mais do que seguir um plano. 
 
Não se trata, como poderia parecer à primeira vista,de um desprezo aos elementos e 
ferramentas tradicionais do desenvolvimento de software, mas sim do estabelecimento de uma 
escala de valores, na qual a flexibilidade e a colaboração são mais relevantes do que a rigidez 
de processos e planejamento clássicos. 
Os 12 princípios do desenvolvimento ágil são os seguintes: 
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua 
de software de valor; 
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis 
se adequam a mudanças, para que o cliente possa tirar vantagens competitivas; 
Entregar software funcionando com frequência, na escala de semanas até meses, com 
preferência aos períodos mais curtos; 
Pessoas relacionadas à 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. 
Com o manifesto ágil foi necessário criar uma organização que se configurasse 
permanente e o representasse. Então, no final de 2001, nasceu a Agile Alliance. Trata- se de 
uma organização sem fins lucrativos que procura promover o conhecimento e discussões 
sobre os vários métodos ágeis, hoje, existentes no mundo. Muitos dos membros do manifesto 
6 
 
ágil, citados anteriormente, são integrantes dessa aliança. Cada método ágil existente hoje 
carrega consigo os valores e princípios arraigados no manifesto ágil, métodos como SCRUM. 
 
8. Papéis: O Time Scrum 
 
9. Time de desenvolvimento 
 
“O time de desenvolvimento é responsável pelo desenvolvimento do produto. É este 
time que determina como o produto será desenvolvido, planeja o trabalho e acompanha seu 
processo.” (SABBAGH, 2013). 
“Time de desenvolvedores responsáveis por transformar o Backlog do produto em 
incrementos de funcionalidades que possam ser entregues ao cliente. Os membros deste Time 
dever ser interdisciplinares, possuindo todo o conhecimento necessário para criar um 
incremento no trabalho.” (CRUZ, 2013) 
 
10. Product Owner 
 
“O Product Owner é responsável por garantir e maximizar, a partir do trabalho do 
Time de desenvolvimento, o retorno sobre o investimento no produto para os clientes do 
projeto. Também define o produto e toma as decisões de negócios relativas a seu 
desenvolvimento a partir das necessidades dos clientes do projeto e demais partes 
interessadas, alinhado com ou em direção aos objetivos da organização.” (SABBAGH, 2013). 
“O Product Owner é o Dono do produto, ou seja, o responsável por entender o negócio 
do produto e entregar valor ao cliente, além de garantir que o Time compreenda o produto e 
entregue os itens priorizados.” (CRUZ, 2013) 
 
11. Scrummaster 
 
“O ScrumMaster trabalha par facilitar e potencializar o trabalho do Time. Ou seja, 
utilizando-se de seu conhecimento sobre Scrum, habilidade de lidar com pessoas, técnicas de 
facilitação e outras técnicas, o ScrumMaster ajuda o Product Owner e Time de 
Desenvolvimento a serem mais eficientes na realização do seu trabalho.” (SABBAGH, 2013) 
“É o responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, 
às práticas e às regras, ajudando o Time e a organização a adotarem o Scrum. Também educa 
o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de 
maior qualidade. O Scrummaster também ajuda o Time Scrum a entender e usar o 
autogerenciamento e a interdisciplinaridade. Apesar desta ajuda, o Scrummaster não deve 
gerenciar o Time Scrum, pois este deve ser auto-organizável.” (CRUZ, 2013) 
 
12. Artefatos do Scrum 
 
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de 
transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum 
7 
 
são especificamente projetados para maximizar a transparência das informações chave de 
modo que todos tenham o mesmo entendimento dos artefatos. 
 
13. Backlog do Produto 
 
O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no 
produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O 
Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, 
disponibilidade e ordenação. 
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas 
estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do 
Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. Ele é 
dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais 
apropriado, competitivo e útil, existirá enquanto o produto também existir. 
O Backlog do Produto lista todas as características, funções, requisitos, melhorias e 
correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Seus 
itens possuem os atributos de descrição, ordem, estimativa e valor. 
Enquanto um produto é usado, ganha valor, e o mercado oferece retorno, o Backlog do 
Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então 
ele é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou 
tecnologia podem causar mudanças no Backlog do Produto. 
Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do 
Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do 
Produto que agrupe itens pode ser então aplicado. 
Seu refinamento é a ação de adicionar detalhes, estimativas e ordem aos itens no 
Backlog do Produto. Este é um processo contínuo em que o Product Owner e o Time de 
Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o 
refinamento, os itens são analisados e revisados. O Time de Desenvolvimento decide como e 
quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% 
da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem 
ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner. 
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais 
claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são 
feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, 
menos detalhes. Os itens do Backlog do Produto que irão ocupar o desenvolvimento na 
próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro 
do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time 
de Desenvolvimento dentro da Sprint são considerados como “Preparados” para seleção no 
Planejamento da Sprint. 
O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner 
deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas 
as pessoas que irão realizaro trabalham fazem a estimativa final. 
 
 
8 
 
14. Monitorando o Progresso a Caminho do Objetivo 
 
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo 
pode ser somado. O Product Owner acompanha o total do trabalho restante pelo menos a cada 
Reunião de Revisão da Sprint; compara este valor com o trabalho restante na Reunião de 
Revisão da Sprint anterior, para avaliar o progresso na direção de completar o trabalho 
previsto, pelo tempo estimado para alcançar o objetivo. Esta informação deve ser transparente 
para todos os stakeholders. 
Várias práticas como burndown, burnup e outras práticas de estimativa tem sido 
usadas para prever o progresso. Estas tem se provado úteis. Contudo, não substituem a 
importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. 
Somente o que tem acontecido pode ser usado para uma tomada de decisão a respeito do que 
virá. 
 
15. Backlog da Sprint 
 
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para 
a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo 
da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual 
funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa 
funcionalidade em um incremento “Pronto”. 
O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento 
identifica como necessário para atingir o objetivo da Sprint. 
O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no 
progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica 
o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a 
Sprint. Este surgimento ocorre quando o Time de Desenvolvimento trabalha segundo o plano 
e aprende mais sobre o trabalho necessário para alcançar o objetivo da Sprint. 
Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao 
Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho 
restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são 
removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a 
Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o 
Time de Desenvolvimento planeja completar durante a Sprint, e pertence exclusivamente ao 
Time de Desenvolvimento. 
 
16. Monitorando o Progresso da Sprint 
 
Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do 
Backlog da Sprint pode ser somado. O Time de Desenvolvimento monitora o total do trabalho 
restante pelo menos a cada Reunião Diária. O Time de Desenvolvimento acompanha estes 
resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint. Com o 
rastreamento do trabalho restante em toda a Sprint, o Time de Desenvolvimento pode 
gerenciar o seu progresso. 
9 
 
 
17. Incremento 
 
O incremento é a soma de todos os itens do Backlog do Produto completados durante 
a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo 
incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e 
atender a definição de “Pronto” do Time Scrum. Este deve estar na condição utilizável 
independente do Product Owner decidir por liberá-lo realmente ou não. 
 
18. Transparência do Artefato 
 
Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são 
feitos com base na percepção existente do estado dos artefatos. Na medida em que a 
transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não 
são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e 
riscos podem aumentar. 
O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e 
outras partes envolvidas para entender se os artefatos estão plenamente transparentes. Há 
práticas para lidar com transparência incompleta, o Scrum Master deve ajudar todos a aplicar 
a mais apropriada prática na falta de uma transparência plena. O Scrum Master pode detectar 
transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo 
atentamente o que está sendo dito, e detectando diferenças entre o esperado e o resultado real. 
O trabalho do Scrum Master é trabalhar com o Time Scrum e organizar o aumento da 
transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e 
mudança. Transparência não ocorre de um dia para o outro, mas é um caminho. 
 
19. Os Eventos do Scrum (TO DO). 
 
Como medir a produtividade do SCRUM 
Um dos temas mais repetidos no Scrum é “melhoria contínua”, que depende do 
trabalho entregue e realizado pelo time. Segundo Patrick Lencioni, um time não pode ser 
considerado um time de verdade se o mesmo não é capaz de aferir os seus próprios resultados 
e reagir conforme a informação conhecida, ou seja, não é possível melhorar o seu processo se 
não há um histórico no qual se basear. A melhoria contínua só se torna realidade quando é 
possível concluir que aspectos do processo são passíveis de melhoria, através de métricas. 
Em muitas empresas, as métricas são vistas como vilãs pelos times, devido as mesmas 
serem utilizadas sem um propósito claro, e sim pelo simples fato de que elas deveriam existir 
ou buscar culpados por falhas e insucessos dos projetos, perdendo-se excelentes 
oportunidades de descobrir problemas antes que eles acontecessem. 
Escolher quais métricas usar em cada momento de um projeto é até mais importante 
do que fazer uma boa escolha de metodologia, é com base nas métricas que evoluímos e 
aperfeiçoamos a forma de trabalhar, escolhendo a inadequada corre-se o risco de parar no 
processo de melhoria continua. Métrica especificas podem ajudar em diversas situações 
distintas, como algumas listadas a seguir: 
10 
 
• Gráfico de Release Burndown; 
• Quadro Branco; 
• Quadro de Pareamento. 
O Release Burndown é um gráfico mantido pelo Product Owner e utilizado tanto pelo 
Product Owner quanto pelo time de desenvolvimento para monitorar o progresso no 
desenvolvimento em direção a uma entrega (Release). 
É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para 
medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do 
seu ritmo de trabalho, verificando se o ritmo está adequado para atingir a meta da sprint, 
cumprindo com o que foi planejado. 
O gráfico de Release Burndown não é parte do framework Scrum, mas pode ser útil 
quando se utiliza um Plano de Release, geralmente estabelecido em uma reunião de 
planejamento. 
Ao avaliar o gráfico, o Product Owner pode decidir mudanças de rumo, como 
mudanças no escopo ou na meta da release, adiamento da release ou até mesmo seu 
cancelamento. 
 
20. Quadro Branco 
 
Uma ferramenta que traz de brinde várias métricas bastante uteis e interessantes é o 
quadro branco –quando, claro, bem utilizado. Vejamos como um quadro bastante simples, que 
apenas contenha um quadro de acompanhamento, já nos ajudaria no problema abaixo: 
 Esse quadro também mostra a mesma informação que o burndown nos dá, mas além 
disso nos aponta algumas outras informações importantes. 
A primeira delas é que, apesar de faltar pouco para terminarmos, há três histórias 
pendentes. Isto é, embora tudo esteja sendo feito, as tarefas em andamentos comprometem 
três das cinco histórias planejadas; é um impacto muito grande naiteração, se não 
conseguirmos termina-las. 
A segunda, e talvez mais importante, é que a história mais prioritária da iteração não 
foi terminada, enquanto a última ficou pronta antes do último dia. Temos um problema de 
prioridade que passaria em branco se confiássemos apenas no gráfico de burndown. 
Quadro de pareamento 
Para fazer esse acompanhamento, é comum a utilização de um quadro de pareamentos 
como os seguintes? 
 Essa imagem nos indica um ambiente em que o pareamento está concentrado em dois 
pares de desenvolvedores: um, Luiz e Atoji, e o outro, Caires e Victor. Provavelmente haverá 
ilhas de conhecimentos limitadas a um par de pessoas, apesar de ser uma situação melhor que 
conhecimento isolado, é possível muda-la. 
Como o time está atento para a métrica, o problema é rapidamente identificável e 
solucionável: apenas uma questão de disciplina na troca mais frequente de pares. Aliado a 
outras técnicas, como code review e apresentações de discussões internas, as ilhas de 
conhecimentos podem ser minimizadas. 
11 
 
É preciso manter em mente a razão pela qual cada uma dessas métricas serve. Se umas 
delas deixar de fazer sentido, o time deve remove-la; se outro problema recorrente aparecer, o 
time deve buscar uma boa métrica para deixa-lo visível e, eventualmente, resolve-lo. 
 
21. Eventos do SCRUM 
 
22. Sprint 
 
No Scrum a Sprint é uma iteração e um evento time-boxed com duração fixa.Pelas 
regras do Scrum, as Sprints devem ter duração de duas a quatro semanas e possuir uma meta 
estabelecida com um objetivo claro. 
 
23. Time-boxed 
 
Os eventos com duração fixa no Scrum são chamados de time-boxed, mas não é só em 
relação ao tempo que este se aplica, mas ao trabalho também. 
Dividindo em duas partes para um melhor entendimento do significado e aplicabilidade, 
temos: 
• Time: significa que o evento tem uma duração fixa e deve ser encerrado quando este 
tempo terminar, por exemplo, uma reunião diária de quinze minutos deve ser encerrada ao 
final do 15° minuto e não se estender por mais trinta minutos ou uma hora. 
• Boxed: significa que é uma caixa fechada de trabalhos, ou seja, há uma definição de 
trabalho a ser realizada dentro desses eventos, e é imprescindível que seja realizado o trabalho 
proposto, nem a menos nem a mais. 
Sendo assim, temos o time-boxed como um evento com um trabalho fechado e determinado 
para ser realizado dentro de uma duração fixa. 
A Sprint contém e consiste em cerimônias do Scrum, que são: as reuniões de 
planejamento da Sprint, o trabalho de desenvolvimento, a revisão da Sprint e a retrospectiva 
da Sprint. Devem ocorrer uma após a outra, sem intervalos e na sequência correta. 
 
24. Planejamento da Sprint 
 
Na reunião de planejamento da Sprint a iteração toda é planejada. Este é um evento 
time-boxed, geralmente de oito horas, para uma Sprint de um mês de duração e deve ser 
utilizado para que o Time Scrum defina “o que será feito” e “como será feito”. 
Reunião Diária 
Este é o momento em que os times devem se encontrar diariamente para uma reunião de 
quinze minutos no máximo. O nome é originário do inglês Daily Meeting. 
Este é um evento time-boxed de quinze minutos, e a ideia é que esta cerimônia ocorra sempre 
no mesmo horário e no mesmo local durante as Sprints e tenha como objetivo principal de 
cada membro do Time explique brevemente: 
• O que ele realizou desde a última reunião diária. 
• O que ele vai realizar até a próxima reunião diária. 
• Quais obstáculos estão em seu caminho. 
12 
 
O foco das perguntas é um alinhamento do que foi realizado e do que será realizado, 
que poderá agregar valor aos trabalhos dos outros membros. A reunião não deve ser 
considerada ou usada como uma reunião de passagem de status. 
Revisão da Sprint 
A reunião de Revisão da Sprint, que vem do inglês Sprint Review, é também 
conhecida como Apresentação da Sprint, cujo objetivo maior é a revisão do Product Owner, 
ou do cliente, em todos os itens concluídos pelo time. 
Esta cerimônia é um evento time-boxed de quatro horas. Será possível conferir e 
avaliar o que está sendo considerado pronto, levando em conta o que está sendo entregue 
versus o que deveria ser entregue. 
Retrospectiva da Sprint 
É o momento mais indicado para o time voltar no tempo e inspecionar como ocorreu a 
última Sprint, levando em consideração as pessoas, as relações entre elas, os processos e as 
ferramentas utilizadas. 
Esta cerimônia é um evento time-boxed de três horas, e o objetivo da inspeção e identificar e 
priorizar os três seguintes grupos de itens: 
• Os principais itens que correram bem e devem ser mantidos para a próxima Sprint. 
• Os principais itens que podem ser ainda melhorados e serem ainda mais positivos na 
próxima Sprint. 
• Os principais itens que devem ser descartados e retirados da próxima Sprint. 
No final da reunião de retrospectiva, o time deve sair com uma identificação de medidas de 
melhoria factíveis que serão implementadas na próxima Sprint. 
É a principal cerimônia que influencia e provoca a melhoria contínua nos projetos e nos times. 
 
25. Definição de “Pronto” 
 
Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, 
todos devem entender o que o “Pronto” significa. Embora, isso varie significativamente de um 
extremo ao outro para cada Time Scrum, os integrantes devem ter um entendimento 
compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é 
a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho está 
completado no incremento do produto. 
A mesma definição orienta o Time de Desenvolvimento no conhecimento de quantos 
itens do Backlog do Produto podem ser selecionados durante a Reunião de Planejamento da 
Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente 
utilizáveis que aderem à definição atual de “Pronto” do Time Scrum. 
O Time de Desenvolvimento entrega um incremento de funcionalidade do produto a 
cada Sprint. Este incremento é utilizável, assim o Product Owner pode escolher por liberá-lo 
imediatamente. Se a definição de “pronto” para um incremento é parte das convenções, 
padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem 
segui-la como um mínimo. Se “pronto” para um incremento não é uma convenção de 
desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir 
uma definição de “pronto” apropriada para o produto. Se há múltiplos Times Scrum 
13 
 
trabalhando no lançamento do sistema ou produto, os times de desenvolvimento de todos os 
Times Scrum devem mutuamente definir a definição de “Pronto”. 
Cada incremento é adicionado a todos os incrementos anteriores e completamente 
testado, garantindo que todos os incrementos funcionam juntos. 
Com um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja 
expandida para incluir critérios mais rigorosos de alta qualidade. 
 
26. Implementando o Scrum: Como começar? 
 
Esta é uma descrição bem ampla do processo, mas deve ser suficiente para começar. 
Esta parte irá, de forma resumida, explicar o como. 
Escolha um Dono do Produto. Essa pessoa é a responsável pela visão do que você vai 
fazer ou conseguir. Ela leva em consideração os riscos e os benefícios, o que é possível, o que 
pode ser feito e o que desperta a paixão na equipe. 
Escolha uma equipe. Quem serão as pessoas que realmente trabalharão no projeto? 
Essa equipe precisa ter todas as habilidades necessárias para pegar a visão do Dono do 
Produto e transformá-la em realidade. As equipes devem ser pequenas; entre três e nove 
pessoas é o princípio básico.Escolha um Mestre Scrum. Essa pessoa vai orientar o restante da equipe em relação à 
estrutura do Scrum, além de ajudar a eliminar qualquer obstáculo que os esteja deixando mais 
lentos. 
Crie e priorize uma lista de Pendências do Produto. Trata-se de uma lista detalhada de 
tudo que precisa ser feito ou construído para transformar a visão em realidade. Essas 
Pendências existem e evoluem durante o desenvolvimento do produto; elas são o mapa dele. 
Em qualquer fase do projeto, são a única e definitiva visão de “tudo que precisa ser feito pela 
equipe a qualquer momento, em ordem de prioridade”. Só existe uma lista de Pendências; isso 
significa que o Dono do Produto precisa tomar decisões em relação a prioridade durante todo 
o processo; ele deve consultar todos os stakeholders e a equipe para se certificar de que elas 
representam tanto o que as pessoas querem quanto o que pode ser construído. 
Aperfeiçoe e faça estimativas para as Pendências do Produto. É crucial que as pessoas 
que irão realmente concluir os itens da lista façam as estimativas de quanto esforço eles 
exigirão. A equipe deve olhar para cada item das Pendências e ver se aquilo é factível. 
Existem informações suficientes para conclui-lo? Ele é pequeno o suficiente para ser 
estimado? Existe uma definição de “Feito”? Ele cria valor visível? Cada item deve poder ser 
mostrado, demonstrado e, esperançosamente, ser enviado. Não estime as Pendências em 
horas, porque as pessoas são péssimas nesse tipo de previsão. Faça isso usando uma 
classificação relativa por tamanho: Pequeno, Médio ou Grande. 
Planejamento do Sprint. Esta é a primeira das reuniões Scrum. A equipe, o Mestre Scrum e o 
Dono do Produto se reúnem para planejar o Sprint, que sempre tem uma duração 
definida de tempo menor que um mês. A maioria das pessoas define Sprints de uma ou de 
duas semanas. As equipes olham para as tarefas no topo das Pendências e estimam o quanto 
podem fazer naquele Sprint. Se a equipe já está trabalhando a alguns Sprints, ela deve pegar 
tarefas que totalizem o mesmo número de pontos do Sprint anterior. Esse número é conhecido 
como a Velocidade da equipe. 
14 
 
O Mestre Scrum e a equipe devem tentar aumentar o número de pontos a cada Sprint. 
Essa é outra chance para a equipe e o Dono do Produto se certificarem que todos entendem 
como os itens vão satisfazer a visão. Além disso, durante essa reunião todos devem concordar 
com um Objetivo do Sprint. 
Um dos pilares do Scrum é que, uma vez que a equipe se comprometeu com o que 
acredita ser capaz de fazer em um Sprint, é isso. Ele não pode ser mudado, nada pode ser 
acrescentado. A equipe deve trabalhar de forma autônoma durante o Sprint para concluir o 
que previu que conseguiu. 
Torne o trabalho visível. O melhor jeito para se fazer isso no Scrum é criar um Quadro 
Scrum com três colunas: A fazer, Fazendo, Feito. post-its representam os itens que precisam 
ser concluídos e a equipe os move pelo Quadro Scrum à medida que forem concluídos, um a 
um. 
Outro modo de tonar o trabalho visível é criar um Gráfico de Burn- Down. Um eixo é 
o número de pontos que a equipe definiu para o Sprint, e o outro é o número de dias. Todos os 
dias, o Mestre Scrum soma o número de pontos concluídos e os marca no gráfico. O ideal é 
que haja uma ladeira descendo pelo gráfico até chegar ao zero no último dia do Sprint. 
Reuniões Diárias ou Scrum Diário. Este é o ritmo do Scrum. Todos os dias, no mesmo 
horário, durante não mais do que 15 minutos, a equipe e o Mestre Scrum se reúnem para 
responder a três perguntas: 
 
O que você fez ontem para ajudar a equipe a concluir o Sprint? 
O que você vai fazer hoje para ajudar a equipe a concluir o Sprint? 
Existe algum obstáculo impedindo você ou a equipe de alcançar o 
 
27. objetivo do Sprint? 
 
Isso é tudo. A reunião inteira. Se ela levar mais do que 15 minutos, você está fazendo 
alguma coisa errada. Isso serve para ajudar a equipe inteira a saber exatamente em que ponto 
estão no Sprint. Todas as tarefas serão concluídas a tempo? Existem oportunidades para 
ajudar os outros membros da equipe a superarem os obstáculos? Não há designação de tarefas 
vindas de cima — a equipe é autônoma; são eles que fazem isso. Não há qualquer relatório 
detalhado para os gestores. O Mestre Scrum é responsável por resolver qualquer obstáculo ou 
impedimento para o progresso da equipe. 
Revisão ou Demonstração do Sprint. Trata-se da reunião na qual a equipe mostra o 
que conseguiu fazer durante o Sprint. Qualquer pessoa pode participar, não apenas o Dono do 
Produto, o Mestre Scrum e a equipe, mas também os stakeholders, os gestores, os clientes, e 
qualquer outra pessoa. Esta é uma reunião aberta na qual a equipe demonstra o que conseguiu 
colocar na coluna Feito. 
A equipe só deve demonstrar o que satisfaz a Definição de Feito. O que está total e 
completamente concluído e pode ser entregue sem qualquer trabalho adicional. Pode não ser o 
produto completo, mas deve ser um atributo concluído do produto. 
Retrospectiva do Sprint. Depois que a equipe mostrou o que conseguiu fazer no Sprint 
anterior — aquilo que está “Feito” e pode ser entregue para clientes para obtenção de 
feedback —, eles se reúnem e pensam no que deu certo e o que poderia ter sido melhor, e o 
15 
 
que podem melhorar no próximo Sprint. Qual é o aprimoramento no processo que eles, como 
uma equipe, podem implementar de forma imediata? 
Para ser eficaz, essa reunião requer certa dose de maturidade emocional e atmosfera de 
confiança. O importante é lembrar-se sempre de que você não está procurando culpados; está 
olhando para o processo. Por que aquilo aconteceu assim? Por que você não percebeu aquilo? 
O que poderia ter acontecido para sermos mais ágeis? É essencial que as pessoas na 
equipe assumam a responsabilidade pelo processo e seus respectivos resultados, e que 
busquem soluções como uma equipe. Ao mesmo tempo, elas têm de ter coragem de levantar 
as questões que realmente as incomodam, de forma que a solução seja orientada, em vez de 
acusadora. E o restante da equipe precisa ter maturidade para ouvir o feedback, absorvê-lo e 
procurar uma solução, em vez de assumir uma postura defensiva. 
No final da reunião, a equipe e o Mestre Scrum devem chegar a um acordo sobre um 
aprimoramento no processo que será implementado no Sprint seguinte. Tal aprimoramento no 
processo, às vezes, é chamado kaizen, e deve ser colocado nas pendências do próximo Sprint, 
acompanhado de testes de aceitação. Desse modo, será fácil para a equipe verificar se o 
aprimoramento realmente foi implementado, e que efeito ele teve sobre a velocidade. 
Comece imediatamente o próximo Sprint, considerando a experiência da equipe com 
os impedimentos e os aprimoramentos no processo. 
Utilização e comparativo: A melhor forma de gerenciar projetos e a junção do Scrum ao Guia 
PMBOK 
“O Scrum pode ser aplicado a qualquer projeto, de qualquer tamanho e de qualquer 
natureza, inclusive aqueles mais complexos. Seus resultados positivos são mais facilmente 
alcançados em projetos de natureza tecnológica e com equipes pequenas, geralmente de até 
dez integrantes. Esse framework costuma influenciar melhor projetos curtos e que utilizam o 
modelo de precificação Time & Material, também conhecido como Homem/Hora. Outro fator 
relevante para o uso do Scrum é que ele não possui referências para o gerenciamento de áreas 
como custos ou aquisições, tampouco para etapas como iniciação ou encerramento de 
projetos. A sua aplicação é bem direcionada e focada para a etapa de execução de um projeto, 
onde o Time precisa produzir e entregas produtos completados rapidamente. Portanto, o 
Scrum pode ser aplicado em projetos com configurações diferentesdas citadas anteriormente, 
porém a complexidade da sua aplicação e gerenciamento poderá ser aumentada em muitas 
vezes se o Time não for experiente o suficiente para se auto gerenciar com eficiência e 
eficácia, ou se receber mentoria ou coaching externo inviabilizando os objetivos do projeto ou 
comprometendo a confiabilidade do uso do próprio Scrum.” (CRUZ, 2013). 
“Muitos defendem que o uso do ágil é a melhor solução, principalmente na área de 
tecnologia, e outros afirmam que o tradicional funciona para qualquer projeto, além de ser 
muito mais seguro. Já um terceiro grupo diz que os dois anteriores estão certos e ao mesmo 
tempo também não estão. Porque um ambiente de projeto é muito mais complexo do que um 
modelo padrão, ou um conjunto de boas práticas, o gerente de projetos e sua equipe precisam 
usar a inteligência para enxergar o que é melhor em cada momento da sua gestão, que deve 
ser compartilhada. Seguindo essa terceira linha, o ágil não é melhor do que o tradicional, e 
muito menos o inverso. Sendo assim, o que se busca nessa visão é a união dos dois mundos 
para trazer mais força às equipes de gerenciamento de projeto e mostrar que a crença de que 
só um deles resolveria todos os problemas pode ser um grande risco.” (DIAS, 2013). 
16 
 
 
28. Empresas que Utilizam o Scrum 
 
SEFAZ – É a Empresa responsável pela RECEITA e DESPESA do Estado. 
Stefanini IT –Empresa de Desenvolvimento de Soluções, BPO, Outsourcing para Aplicativos 
e Infraestrutura 
UOl –Uol é uma empresa brasileira de conteúdo, produtos e serviços de Internet do 
conglomerado Grupo Folha 
LocaWeb – A LocaWeb é uma empresa brasileira de hospedagem de sites, serviços de 
internet e computação em nuvem, líder no Brasil e na América Latina 
Microsoft - é uma empresa transnacional americana com sede em Redmond, Washington, que 
desenvolve, fabrica, licencia, apoia e vende softwares de computador, produtos eletrônicos, 
computadores e serviços pessoais. 
SulAmérica Seguros – Saúde / Autos - A Sul América Seguros e Previdência oferece plano de 
saúde, seguro de vida, previdência ... residencial, entre outras opções para você, sua família e 
empresa 
Vivo - é uma empresa do Grupo Telefônica 
Visual Systems- é uma empresa de Serviços de Tecnologia da Informação, com mais de 20 
anos de mercado, especializada em ITSM, Datacenter, Cloud 
WebGoal - A Webgoal é uma empresa brasileira criada em 2008 para desenvolver softwares 
de maneira diferente. 
Synchro - A SYNCHRO Solução Fiscal Brasil é uma das maiores provedoras brasileiras de 
soluções 
Globo.com - é um portal e provedor de Internet pertencente ao maior grupo de mídia da 
América Latina, o Grupo Globo 
Aurum - Software Jurídico Aurum Software. Soluções para escritórios de advocacia, 
advogados autônomos e departamentos jurídicos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
17 
 
29. Bibliografia 
 
OTÁVIO, João. Introdução ao Scrum, 2015. Disponível em:< 
http://www.devmedia.com.br/introducao-ao-scrum/33724 > Acesso em: 11 de set. 2016. 
 
PINHEIRO, Pablo. Entendendo o Scrum, 2012. Disponível em: < 
http://www.devmedia.com.br/entendendo-o-scrum/24583 > Acesso em: 11 de set. 2016. 
 
Manifesto para o Desenvolvimento Ágil de Software. Disponível: < 
http://www.manifestoagil.com.br/ > Acesso em: 11 de set. 2016 
 
BERNARDO, Kleber. Manifesto Ágil: Como tudo começou. Disponível em: < 
http://www.culturaagil.com.br/manifesto-agil-como-tudo-comecou/ > Acesso em: 11 de set. 
2016. 
 
CARLOS, Miguel. Scrum é Framework e não Metodologia. Disponível em: < 
https://micajeho.wordpress.com/2011/12/15/scrum-e-framework-e-nao-metodologia/ > 
Acesso em: 11 de set. 2016. 
 
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. Disponível em < 
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf > Acesso 
em: 17 de set. 2016. 
 
BRUDER, David. Empresas que Utilizam o Scrum. Disponível em < 
https://mundodoanalista.wordpress.com/2011/05/20/empresas-que-utilizam-scrum/ > Acesso 
em: 18 de set. 2016. 
 
SABBAGH, Rafael. Scrum: Gestão Ágil para Projetos de Sucesso. São Paulo: Casa do 
Código, 2013. 
 
PHAM, Andrew; PHAM, Phoung-Van. Scrum em Ação: Gerenciamento e Desenvolvimento 
Ágil de Projetos de Software. São Paulo: Novatec, 2012. 
 
BROD, Cesar. Scrum: Guia Prático para Projetos Ágeis. São Paulo: Novatec, 2015. 
 
DIAS, Fábio. Scrum e PMBOK: Unidos no Gerenciamento de Projetos. São Paulo: Brasport, 
2013. 
 
SUTHERLAND, JEFF. Scrum: A arte de fazer o dobro do trabalho na metade do tempo. São 
Paulo: LEYA, 2014.