SCRUM - Metodologia Ágeis

Prévia do material em texto

1 
 
INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DO 
ESPÍRITO SANTO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E 
DESENVOLVIMENTO DE SISTEMAS 
 
 
 
 
 
 
 
 
LUANA FERREIRA BARBOSA 
MATHEUS DE ARAUJO NAZARETH 
YASMIN MENEZES NOGUEIRA 
 
 
 
 
 
 
 
 
 
SCRUM 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ALEGRE 2019 
 
2 
 
 
 
SUMÁRIO 
 
1 HISTÓRIA ............................................................................................................. 3 
2 SCRUM................................................................................................................. 4 
3 ATIVIDADE E ARTEFATOS PRINCIPAIS ............................................................ 5 
5 SPRINT................................................................................................................. 7 
6 PAPEIS SCRUM ................................................................................................... 9 
7 REVISÃO DE SPLINT x RESTROSPECTIVA DE SPLINT................................. 10 
8 REFERÊNCIAS .................................................................................................... 11 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
1 HISTÓRIA 
 
O Scrum foi concebido como um estilo de gerenciamento de projetos em 
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e 
Nonaka no artigo "The New Product Development Game" (Harvard Business Review, 
Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e 
multidisciplinares (cross-functional) produziram os melhores resultados, e associaram 
estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício 
do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna 
conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na 
empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento 
observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição 
de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo. 
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka 
Takeuchi e Ikujiro Nonaka. 
A função primária do Scrum é ser utilizado para o gerenciamento de projetos 
de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim 
como Extreme Programming e outras metodologias de desenvolvimento. Porém, 
teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas 
necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola 
pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um 
casamento. 
Mesmo que idealizado para ser utilizado em gestão de projetos de 
desenvolvimento de software ele também pode ser usado para a gerência de equipes 
de manutenção, ou como uma abordagem para gestão de programas: Scrum de 
Scrums. 
 
 
 
 
 
4 
 
2 SCRUM 
Scrum é uma metodologia ágil para gestão e planejamento de projetos de 
software. No Scrum, os projetos são divididos em ciclos chamados de Sprints. O Sprint 
representa um Time Box dentro do qual um conjunto de atividades deve ser 
executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou 
seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do 
Scrum (Desenvolvedor Àgil, 2014). 
Funcionalidades a serem implementadas em um projeto são mantidas em uma 
lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint 
Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner 
prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será 
capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint 
são transferidas do Product Backlogpara o Sprint Backlog. A cada dia de uma Sprint, 
a equipe faz uma breve reunião, chamada Daily Scrum. O objetivo é disseminar 
conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar 
o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as 
funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se 
uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. 
Assim reinicia-se o ciclo. (Desenvolvedor Àgil, 2014) 
 
 
 
5 
 
 
3 ATIVIDADE E ARTEFATOS PRINCIPAIS 
O Product Owner tem uma visão do que ele quer criar (o grande cubo). Como 
o cubo pode ser grande, por meio de uma atividade chamada Grooming, ele é dividido 
em um conjunto de funcionalidades que são compilados em uma única lista priorizada 
chamado de Product Backlog. 
Então é feito a primeira reunião de Planejamento de Sprint, para definir o Sprint 
Backlog, que contém todo o trabalho que será executado durante o Sprint. 
O Sprint tem duração média de 2 a 4 semanas e são feitas reuniões diárias de 
acompanhamento (Daily Scrum) do trabalho. 
 
Product Backlog 
No Scrum, sempre se faz o trabalho mais importante primeiro. O Product 
Owner, com ajuda do resto da equipe Scrum e as partes interessadas, é o responsável 
por determinar e gerir a sequência deste trabalho e comunicando-o na forma de uma 
lista de prioridades conhecida como o Product Backlog 
 
 
6 
 
O Product Owner, em conjunto com as demais partes interessadas no produto, 
define os itens do Product Backlog. 
Em seguida, ele garante que os itens do Backlog são colocadas na seqüência 
correta usando fatores como valor, custo, conhecimento e risco), de modo que os itens 
de alto valor, aparecerá no topo do backlog do produto e os itens de menor valor 
aparecer em direção ao fundo. 
O Product backlog é um documento que está constantemente evoluindo. Os 
itens podem ser adicionados, excluídos e revisto pelo Product Owner por conta 
de mudanças nas condições de negócios, ou conforme a compreensão da equipe 
Scrum sobre o produto aumenta. 
Em geral a atividade de criar e de refinar os itens do product backlog, estimando 
o tamanho e esforço de cada item, é chamada de Grooming. 
Antes de finalizar a priorização, ou refinamento do produto backlog, é preciso 
saber o tamanho de cada item. É importante que o Product Owner saiba o custo de 
cada item para que possa determinar a sua prioridade de forma adequada. O Scrum 
não especifica como você deve medir o tamanho dos itens do backlog. 
Na prática, muitas equipes usam uma medida de tamanho relativo, como Story 
Point ou dias ideais. 
Essa questão sobre estimativas é um capítulo à parte e cabe um post depois 
para explicar somente isso. 
 
 
7 
 
5 SPRINT 
O que é uma Sprint? 
Uma sprint é a unidade básica de desenvolvimento em Scrum. Sprints tendem 
a durar entre uma semana e um mês, e são um esforço dentro de uma faixa de tempo 
(ou seja, restrito a uma duração específica) de comprimento constante. A adoção de 
ciclos relativamente curtos permite entregas de partes dos sistemas, gerando valor 
para os clientes e permitindo uma avaliação dinâmica do trabalho. 
 Cada sprint é precedida por uma reunião de planejamento (Sprint 
Planning), onde as tarefas para a sprint são identificadas e um compromisso estimado 
para o objetivo da sprint é definido, e seguido por uma reunião de revisão ou de 
retrospectiva, onde o progresso é revisto e lições para as próximas sprints são 
identificadas. 
 Durante cada sprint, a equipe cria um incremento de produto 
potencialmente entregável (por exemplo, software funcionale testado). O conjunto de 
funcionalidades que entram em uma sprint vêm do Product Backlog, que é um 
conjunto de prioridades de requisitos de alto nível definidos pelo Product Owner. 
• Splint Planning 
O product backlog pode representar muitas semanas ou até meses de trabalho, 
o que é muito mais do que pode ser concluído em um único e curto sprint. 
Para determinar quais os subconjuntos de itens do Product Backlog mais 
importantes para construir no próximo sprint, o product owner, junto com o time de 
desenvolvimento e ScrumMaster, devem realizar o Sprint Planning (planejamento de 
sprint ). 
Durante o planejamento do sprint, a equipe de desenvolvimento e o product 
owner devem chegar a um acordo sobre qual o Objetivo do Sprint. 
Com este objetivo em mãos, eles determinam quais os itens do backlog devem 
ser priorizados para serem executados neste Sprint. 
A maioria das equipes Scrum que estão realizando Sprints de duas semanas a 
um mês de duração tentam completar o planejamento do sprint em cerca de4 a 
8 horas. Sprint de uma semana não deve tomar mais do que 2 horas para planejar. 
 
8 
 
• Daily Scrum 
Todos os dias, idealmente no mesmo horário, os membros da equipe de 
desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou 
menos), chamado Daily Scrum. 
 
Esta reunião também é muitas vezes chamada de Stand-Up Meeting, por causa 
de uma prática recomendada para que a reunião seja feita em pé (com a intenção de 
fazer com que a reunião seja rápida). 
 
 
 
9 
 
6 PAPEIS SCRUM 
O Scrum só e caracterizado caso tenham os seguidos papéis fundamentais que 
são eles, Product Owner, Scrum máster e Dev Team; 
• Product Owner (dono do produto) 
 O Product Owner representa a voz do cliente e é responsável por garantir 
que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens 
do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product 
backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa 
também ser um membro da equipe de desenvolvimento, recomenda-se que este papel 
não seja combinado com o de ScrumMaster. 
 
• Scrum Master 
 Scrum é facilitado por um Scrum Master, que é responsável pela 
remoção de impedimentos à capacidade da equipe para entregar o objetivo da sprint 
/ entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre 
a equipe e qualquer influência ou distração. O Scrum Master garante que o processo 
Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação 
das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e 
mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um 
líder-servo para reforçar essa dupla perspectiva. 
• Equipe de Desenvolvimento (Development Team) 
 A equipe de desenvolvimento é responsável pela entrega do produto. A 
equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que 
fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, 
documentos, etc.), recomenda-se que a equipe seja auto-organizada e auto-
conduzida, mas que muitas vezes trabalham com alguma forma de projeto ou gestão 
de equipe. 
 
 
10 
 
7 REVISÂO DE SPLINT x RESTROSPECTIVA DE SPLINT 
Revisão da Sprint, é executada no final da Sprint, para inspecionar o incremento 
e adaptar o backlog do produto se necessário. As partes interessadas colaboram 
sobre o que foi feito na Sprint e com base nisso, e em qualquer mudança no backlog 
do produto durante a sprint, os participantes colaboram naquilo que pode ser feito para 
otimizar o valor do produto. 
Retrospectiva, é uma oportunidade para o Time Scrum inspecionar a si próprio 
e criar um plano para melhorias a serem aplicadas, essa etapa ocorre no final de todos 
sprints. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
11 
 
8 REFERÊNCIAS 
DEGRACE, P.; STAHL L. H. Wicked problems, righteous solutions: a catalogue of 
modern software engineering paradigms. Nova Jersey: Yourdon Press, 1990. 
SUTHERLAND, J. Agile can scale: inventing and reinventing SCRUM in five 
companies. Cutter IT Journal, v. 14, p. 5-11, 2001. 
SUTHERLAND, J. Agile development: lessons learned from the first Scrum. Cutter 
Agile Project Management Advisory Service: Executive Update, v. 5, n. 20, p. 1-4., 
2004. 
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard 
Business Review, Boston, MA, Estados Unidos, v. 64, n. 1, p. 137-146, jan./fev. 
1986.