Jupiter Gestao de Projetosenfase em Metodologiaageispdf

Volte ao Sumário
Navegue entre os capítulos
GESTÃO DE PROJETOS
(ÊNFASE EM
METODOLOGIAS ÁGEIS)
1
Gestão de Projetos (Ênfase em Metodologias Ágeis)
Volte ao Sumário
Moura, Carlos André Gonçalves, 2019.

Gestão de Projetos (ênfase em Metodologias Ágeis) - Jupiter Press
São Paulo/SP.
30 páginas;
Palavras-chave: 1. Gestão de projetos; 2. Metodologia Ágil; 3. Manifesto

Ágil; 4 Metodologia Crystal; 5. Metodologia XP.
1
*
Volte ao Sumário
SUMÁRIO
INTRODUÇÃO...................................................................................................................................................3
1. VISÃO GERAL DO SCRUM ....................................................................................................................4
1.1 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE: UMA
VISÃO GERAL........................................................................................................................................4
s
2. PAPÉIS DO SCRUM...................................................................................................................................6
2.1 O SCRUM MASTER......................................................................................................................6
2.2 PRODUCT OWNER....................................................................................................................6
2.3 TIME DE DESENVOLVIMENTO............................................................................................7
3. ABORDAGENS E PRÁTICAS ÁGEIS DE GERENCIAMENTO DE PROJETOS..........9
4.INTRODUÇÃO AO MANIFESTO ÁGIL.............................................................................................11
4.1 O QUE É E QUAL A SUA HISTÓRIA?..................................................................................11
4.2 OS VALORES DO MANIFESTO ÁGIL?..............................................................................11
4.3 FERRAMENTAS DAS METODOLOGIAS ÁGEIS.........................................................12
.........................................................................................................................................................................12
5. PRINCÍPIOS E COMPARAÇÃO DA ABORDAGEM ÁGIL COM O MODELO
DE DESENVOLVIMENTO EM CASCATA..........................................................................................15
5.1 O QUE É A METODOLOGIA ÁGIL?....................................................................................15
5.2 O QUE É METODOLOGIA TRADICIONAL?.................................................................15
5.3 COMO SABER QUAL METODOLOGIA ADOTAR?..................................................16
6. ETAPAS E FERRAMENTAS DOS DIFERENTES MÉTODOS ÁGEIS: SCRUM............17
6.1 CERIMÔNIA ....................................................................................................................................17
6.2 ARTEFATOS.....................................................................................................................................20
7. ETAPAS E FERRAMENTAS DOS DIFERENTES MÉTODOS ÁGEIS: CRYSTAL..........23
7.1 O QUE É METODOLOGIA ÁGIL CRYSTAL?...................................................................23
7.2 PARÂMETROS CONFORME O TAMANHO..................................................................23
7.3 PARÂMETROS CONFORME NÍVEL CRÍTICO DO PROJETO.............................23
7.4 CARACTERÍSTICAS DA METODOLOGIA CRYSTAL.................................................24
8. ETAPAS E FERRAMENTAS DOS DIFERENTES MÉTODOS ÁGEIS:
PROGRAMAÇÃO EXTREME....................................................................................................................25
8.1 O QUE É METODOLOGIA ÁGIL XP?.................................................................................25
8.1 VALORES DO EXTREME PROGRAMMING..................................................................25
CONSIDERAÇÕES FINAIS.........................................................................................................................28
REFERÊNCIAS BIBLIOGRÁFICAS........................................................................................................29
* A navegação deste e-book por meio de botões interativos pode variar de funcionalidade dependendo de cada leitor de PDF.
2
Volte ao Sumário
INTRODUÇÃO
No decorrer das últimas décadas, as Metodologias Ágeis vieram se adaptando

às esferas do desenvolvimento de software e de criação de produtos de diversas
organizações com o intuito de incorporar valores aos negócios, atendendo às
contínuas transformações de normas de negócios, diferentemente do que ocorre
com o uso de metodologias tradicionais, a exemplo da metodologia cascata.
As Metodologias Ágeis vêm evoluindo em todos os espaços para propiciar a
evolução na comunicação, em meio aos envolvidos, em um processo de solicitação,
desenvolvimento e entrega. Produzindo projetos com funcionalidades inovadoras
e com qualidade dentro das expectativas do cliente, com custos reduzidos e
menos incidência do retrabalho. As metodologias ágeis não desrespeitam as
técnicas e práticas produzidas pelas metodologias tradicionais, no entanto,
valorizam a comunicação e a interação entre os indivíduos objetivando o alcance
dos resultados almejados.
Faremos estudos, no primeiro capítulo, acerca da “Visão geral do SCRUM”.
Em seguida, vamos aprender sobre os “Papéis do SCRUM”. Compreenderemos
as distintas “Abordagens e práticas ágeis de gerenciamento de projetos” e, logo
após, será apresentada uma “Introdução ao Manifesto Ágil” para fundamentar o
que será abordado nos demais capítulos.
No quinto capítulo teremos uma abordagem sobre os “Princípios e
comparação da abordagem ágil com o modelo de desenvolvimento em cascata”,
e logo em seguida apresentaremos as “Etapas e ferramentas dos diferentes
métodos ágeis: Scrum”, assim como as “Etapas e ferramentas dos diferentes
métodos ágeis: Crystal” e por fim as “Etapas e ferramentas dos diferentes métodos
ágeis: Programação Extreme”, completando, assim, os estudos sobre Gestão de
Projetos com ênfase em Metodologias Ágeis.
3
Volte ao Sumário
1. VISÃO GERAL DO SCRUM
1.1 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE: UMA

VISÃO GERAL
Refletindo-se sobre a rotina das organizações contemporaneamente, é visível
a necessidade da utilização de sistemas computacionais diversos na administração
de operações rotineiras desenvolvidas nas empresas. Tais suportes contribuem
para a otimização na efetivação de atividades do dia a dia da organização, assim
como é considerado um fator determinante para o aumento considerável na
produtividade de diversos processos de negócio.
Deste modo, o desenvolvimento da área de sistemas foi seguido pela
originação de diversas metodologias, estas englobam um conjunto de regras e
conceitos produzidos com o objetivo de orientar o processo de construção de
um software. Como de costume, não há uma receita pronta para se chegar a um
resultado final, ou seja, um método que acate todas as exigências e expectativas
dos usuários e possua a habilidade de funcionamento dentro de uma sucessão
de parâmetros considerados aceitáveis. A partir de técnicas e diretrizes com
resultados almejados alcançados, os profissionais que desenvolvem o projeto
adequam um modelo para a realidade na qual estão inseridos.
As noções de mudança representam uma etapa fundamental na elaboração
de aplicações do método. Mesmo que todos os métodos e esforços empregados
sejam finalizados, com o intuito de contemplar uma grande parcela de situações,
é muito difícil construir um software que em algum momento não necessite de
alterações. Sendo considerado comum e bastante corriqueiro a necessidade de
modificações durante a construção desta aplicação, o que leva a comprometer
uma parcela do tempo e até mesmo de recursos já distinguidos e designados
para a implementação de uma solução.
No que diz respeito ao modelo originário de Metodologia Ágil Tradicional:
O modelo em cascata (em inglês “waterfall”) foi, ainda na década de 1970,

um dos primeiros padrões a fornecer diretrizes para processos voltados
ao desenvolvimento de software. Esta metodologia é caracterizada por
fases que ocorrem dentro de uma sequência rígida, com o início das ati-
vidades de uma etapa acontecendo imediatamente após o término da-
quela que a precedeu. A implementação de um projeto que segue este
modelo é geralmente dividida nas seguintes fases: análise de requisitos,
projeto da aplicação, implementação, testes de validação, implantação e
manutenção (The Scrum Guide, 2017).
4
Volte ao Sumário
Esta abordagem é comparada por conta de suas semelhanças às da linha

de montagem clássica do mundo fabril. Na contemporaneidade, em que as
organizações estão envoltas de grandes e súbitas mudanças e transformações, as
maneiras lineares do modelo tradicional estabelecem regras de atuação dentro de
um projeto de software, tornando-se um fator limitante e dificultando a chegada a
certos resultados.
Posteriormente à fase inicial, na qual são apresentadas as expectativas em que
determinado escopo da aplicação será desenvolvida, a área que ficou responsável
pela solicitação do sistema avisará sobre o resultado do projeto apenas após o
término do projeto em questão. Eventuais mudanças em requisitos solicitados,
ou nas regras que definem o seu desenvolvimento, podem acarretar prejuízos
aos esforços empregados por meses. Ou, além de tudo, estas alterações podem
afetar negativamente o orçamento previamente estabelecido, resultando até
mesmo em uma ação que não é rara, que o produto resultante sequer chegue a
ser utilizado (por aquilo que não era almejado).
5
Volte ao Sumário
2. PAPÉIS DO SCRUM
2.1 O SCRUM MASTER

Scrum Master ainda não existia no início da década de 90, momento de
surgimento do Scrum. Ken Schwaber e Jeff Sutherland conduziam projetos pelo
mundo, os quais já mostravam alguns conceitos e procedimentos do Scrum.
Após algum tempo, foi observado que não deveriam existir profissionais que
possuíssem a habilidade de garantir a melhoria constante de seus processos,
caso não, as mudanças introduzidas pelos métodos ágeis nas organizações não
permaneceriam.
O nome Scrum Master é uma alusão aos jogos de RPG tão populares des-
de a década de 70, principalmente entre os profissionais de tecnologia.
Em tais jogos, o Dungeon Master (ou Game Master) é o senhor das regras
do jogo, um papel que facilita nas dinâmicas para que o jogo aconteça de
maneira proveitosa para todos envolvidos, com a dose certa de desafio,
recompensas e adaptação constante. Apesar de possuir poderes para
aplicar e mudar regras, o Dungeon Master não é um tirano, mas um líder-
-servidor que atua em prol do grupo de jogadores para que todos tenham
sucesso em seu objetivo: se divertir (TOOLS, 2016).
Semelhantemente, o Scrum Master pode ser visto como o senhor do Scrum.

Pois o indivíduo lidera todas as regras presentes no Guia do Scrum, no qual seu
objetivo principal é garantir o resultado, não somente do time, mas de toda a
organização. O Scrum Master é visto como líder-servidor, pois ele contribui na
“melhoria contínua e auxilia o time na obtenção dos melhores resultados possíveis
através da remoção de impedimentos e promoção de novas práticas e técnicas
que aproximem mais o time dos objetivos esperados” (TOOLS, 2016).
2.2 PRODUCT OWNER

Com o surgimento dos métodos ágeis de desenvolvimento de software, em
especial o framework Scrum, nos primórdios da década de 90, depara-se mais
uma vez com as dificuldades de comunicação que ocorriam entre o cliente e os
desenvolvedores do software designados. Desta maneira, qual a melhor forma de
se resolver este Gap (falha no processo)? Qual a função do Product Owner?
O Product Owner é o representante máximo dos desejos do cliente den-

tro do Time Scrum. É ele que conhece o problema, as “dores”, o retorno
esperado pelo projeto e ele é o papel responsável por usar toda sua ex-
pertise para guiar o Time de Desenvolvimento para que o seu trabalho
seja o mais otimizado possível, do ponto de vista de ROI (Return Over In-
vestment - Retorno Sobre Investimento). (TOOLS, 2016)
6
Volte ao Sumário
O Product Owner difere-se das metodologias tradicionais, as quais se limitam

a reuniões específicas e pontuais do projeto, isto quando não ocorrem somente
no início e no fim do projeto. O Product Owner é definido como um integrante
“full-time” deste Time Scrum, isto é, deve estar ao dispor dos desenvolvedores
do processo, seja para resolução de algum tipo de obstáculo do negócio, ou para
sanar dúvidas em relação a priorizar as atividades que são mais necessárias em
um determinado momento, trabalhando continuamente na melhor escolha do
Backlog de Produto e em seus desdobramentos: roadmaps e releases.
Sua função é de fundamental importância para a Sprint Planning, pois ele
irá fazer a apresentação dos objetivos futuros e as prioridades para o término
das atividades aculmuladas (Backlog). O Product Owner também deve estar
sempre trabalhando no planejamento e na organização dos próximos projetos,
enquanto o time de desenvolvimento ocupa-se com a Sprint em andamento. O
Product Owner também participa da Sprint Review, “onde geralmente ele recebe
o incremento de software que o time conseguiu criar ou apresenta o mesmo aos
stakeholders, caso ele já conheça o resultado da sprint” (TOOLS, 2016).
2.3 TIME DE DESENVOLVIMENTO

O Scrum determina que o Desenvolvedor é um profissional responsável pelo
desenvolvimento do produto ou pelo sistema que é de incumbência do time.
Porém, tal título não deve ser confundido com o de programador, pois há diversas
formas, maneiras (etapas) de se contribuir para o desenvolvimento de qualquer
produto: análise, programação, testes, design, etc. A hierarquia entre estes
profissionais é inexistente, pois cada um irá contribuir com a sua especialidade
e habilidades para o triunfo do Time Scrum em sua completude. É necessário
determinar um certo número de participantes em cada projeto, que varia de
acordo com Scrum Master e um Product Owner:
Enquanto existe apenas um Scrum Master e um Product Owner por Time

Scrum, o número de Desenvolvedores é bem maior, sendo recomendado
de 3 a 9 Desenvolvedores. Menos do que isso e você terá um overhead de
processos em um time muito pequeno. Mais do que isso e você terá difi-
culdade em conduzir o Scrum com qualidade, uma vez que a comunica-
ção não fluirá tão bem e as cerimônias ficarão mais complexas. Somando
SM e PO, teremos de 5 a 11 profissionais por Time Scrum (TOOLS, 2017).
Desta forma, é de muita importância salientar que responsabilidade

do desenvolvimento do produto é de todo o time, independentemente da
especialidade individual de cada um dos seus membros. Desta maneira, é indicado
que o time possua uma característica, a multifuncionalidade: se uma certa entrega
exige front-end, o time deve possuir este profissional em seu quadro, a exemplo,
pois não é possível que um analista entregue a análise sem que a programação
7
Volte ao Sumário
aconteça. Assim como se ocorrer a programação, mas os testes não serem

realizados. O Time Scrum não terá cumprido sua meta.
O Time de Desenvolvimento constitui seu trabalho seguindo todos os
processos determinados por meio do Scrum Master, que são: as cerimônias e os
artefatos do Scrum. Tais processos deverão ser seguidos, assim como qualquer
outra atividade deste processo, já que se utiliza tempo dos desenvolvedores
envolvidos, devendo se dar importância em suas estimativas, na definição de
escopo das sprints, no entanto, não justifica qualquer tipo de abandono ou desvio
do processo em questão.
8
Volte ao Sumário
3. ABORDAGENS E PRÁTICAS ÁGEIS DE

GERENCIAMENTO DE PROJETOS
Projetos com ótimos resultados dependem muito da metodologia da gestão

que é empregada. As metodologias tradicionais fornecem alternativas que já estão
bem estabelecidas, porém, recomenda-se que se procure por novas sugestões,
entre as quais, encontra-se a gestão ágil de projetos, que possui características
distintas a serem consideradas.
A gestão relaciona-se com a utilização de métodos que dão prioridade para
a comunicação e a atuação integrada. Ela busca a redução de tempo para obter
resultados positivos no processo. A gestão ágil de projetos difere-se muito das
metodologias clássicas. Em sua alcunha sustenta o seu maior objetivo que, por
sua vez, associa-se à redução do tempo na realização de várias atividades.
Os métodos que seguem a linha da abordagem ágil possuem, além de tudo
isso, o interesse por ofertar um desenvolvimento sucessivo para se chegar ao
produto. Neste sentido, suas principais características são:
• Interatividade: o Manifesto Ágil, que funcionou como base para a metodo-

logia, é enfático ao definir que a evolução depende muito do envolvimento
e comprometimento das pessoas envolvidas no projeto. Esta característica
busca instituir a ligação com os demais processos que, no seu decorrer, po-
dem sofrer mudanças. É de extrema necessidade que as pessoas do time es-
tejam conectadas em busca de um resultado em comum. Tudo isto concebe
uma forte interatividade. Segundo Tools (2016), “a equipe deve trabalhar de
um jeito consistente para obter bons resultados, otimizando essa caracterís-
tica”. Neste mesmo contexto, também é de muita importância que o cliente
esteja envolvido nesta abordagem interativa, testificando a realização de ex-
pectativas.
• Iteratividade: difere-se de interatividade. Apesar da semelhança ortográfica,
seus conceitos são diferentes, pois estes relacionam-se com “as entregas in-
crementais que acontecem em pequenos períodos” (TOLLS, 2016). Como
ocorre na gestão tradicional, as fases se dão em cascatas onde o produto só
é entregue ao finalizar o projeto. No gerenciamento ágil de projetos, o obje-
tivo é “buscar a atuação contínua em várias frentes, com uma fase gerando
influência na outra” (TOLLS, 2016). Estas entregas são realizadas em períodos
curtos, garantindo, assim, que o cliente acompanhe o andamento do proces-
so, deixando de avaliar somente os resultados.
• Flexibilidade: métodos tradicionais de gestão caracterizam-se pelo seu en-
gessamento, limitando as alternativas para resolução e otimização dos pro-
cessos. Neste método, com o planejamento e o escopo prontos, o trabalho
direciona-se a mantê-lo dentro do que foi determinado. Diferentemente dis-
to, possuindo os recursos ágeis, a flexibilidade virá como uma das mais impor-
tantes características. Se parte do pressuposto de que imprevistos e mudan-
9
Volte ao Sumário
ças acontecem no decorrer do desenvolvimento dos processos e o time deve

estar habilitado e preparado caso elas ocorram. Isso também pode significar,
desbravar o projeto, conforme ele for se desenvolvendo.
• ●Transparência elevada: Para a maior satisfação do cliente e para a obtenção

do êxito na consumação dos processos do projeto, faz-se necessário possuir a
transparência de forma otimizada. Assim como nas metodologias tradicionais,
é uma característica de muita relevância para os métodos ágeis.
10
Volte ao Sumário
4.INTRODUÇÃO AO MANIFESTO ÁGIL
4.1 O QUE É E QUAL A SUA HISTÓRIA?

Segundo Tolls (2016), o Manifesto Ágil é determinado como uma declaração
de valores e princípios necessários para a construção de um software. Em fevereiro
de 2001, foi criado a partir da reunião de 17 profissionais que já realizavam práticas
de métodos ágeis XP, DSDM, SCRUM, FDD, entre outros.
O Manifesto Ágil trata dos valores em que os profissionais, reunidos em
consenso, aceitam seguir e difundir.
Na primavera de 2000, líderes da comunidade de extreme programming

se reuniram para discutir as práticas do XP. Durante essa reunião também
foi debatido a relação entre o XP e os até então chamados Método Le-
ves. Esses tais de Métodos Leves eram os que hoje conhecemos como
SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Dri-
ven Development, Pragmatic Programming, entre outros (Método ágil,
2017).
Os métodos leves e do XP possuíam uma abordagem menos densa e menos

burocrática que os métodos mais pesados. Desta discussão, determinou-se que o
XP era a melhor alternativa como método específico. Entretanto, possui um local
em comum com os métodos leves. A partir deste debate, Robert Cecil Martin,
também nomeado como Tio Bob, criou um encontro para aqueles que possuíam
interesse nos Métodos Leves.
Como resultado dessa reunião, obteve-se o consenso da criação os
métodos de desenvolvimento de software, intitulando-o como “O Manifesto do
desenvolvimento de Software Ágil”, também chamado de “Manifesto Ágil”.
4.2 OS VALORES DO MANIFESTO ÁGIL?
●Indivíduos e interações mais que processos e ferramentas

Deve-se compreender que a atividade humana tem ação direta sobre o
desenvolvimento de um software. A qualidade da interação entre membros
é capaz de solucionar, ultrapassar diversos obstáculos na comunicação. Tais
processos e ferramentas são de muita relevância e devem ser caracterizados pela
sua simplicidade e utilidade.
Os clientes procuram por resultados e estes resultados desdobram-se no
bom funcionamento do software. Este é o maior indicador de um processo bem-
sucedido. A documentação, quando agrega valor, também é de muita importância.
11
Volte ao Sumário
Colaboração com o cliente mais que negociação de contratos

O cliente e o time (organização) devem sempre trabalhar em conjunto
e consenso, e não um contra o outro. Esse processo chama-se colaboração,
desdobra-se na tomada de decisões no coletivo e trabalho em equipe, objetivando
o mesmo resultado.
Responder a mudanças mais que seguir um plano
O desenvolvimento de software e produtos possui altas imprecisões e, por
tal motivo, não deve ser baseado em planos limitados. O que deve ser realizado é
absorver informações e feedbacks e adaptá-los ao plano.
4.3 FERRAMENTAS DAS METODOLOGIAS ÁGEIS
Figura 1: 12 PRINCÍPIOS DO MANIFESTO ÁGIL

Fonte: aprendeai.com
KANBAN
Figura 2: Kanban
Fonte: aprendeai.com
12
Volte ao Sumário
Segundo Spitaliere (2017), o termo vem do japonês “registro” ou “placa visível”.

É uma ferramenta criada com a intenção de elevar o nível de produção a partir de
uma representação clara do andamento de processos”, comumente possuindo
um quadro ordenado em “etapas da cadeia de valor”.
Gráfico Burndown
Fotografia 3: Gráfico Burndown

Fonte: guiadoexcel.com.br
O Burndown chart ou gráfico de Burndown é o gráfico usado por equipes

Scrum com o intuito de apresentar diariamente todo o progresso do trabalho em
desenvolvimento. O gráfico faz uma representação diária da parte do trabalho
finalizado, comparando-o com o trabalho em total já planejado. Este gráfico é
considerado o mais simples do Scrum.
ScrumBoard
O quadro de tarefas Scrum desdobra-se em um quadro no qual o time dispõe
as tarefas que precisam ser executadas do Backlog (requisitos do produto a ser
entregue). Atividades colocadas em post its de maneira organizada, objetivando
o cumprimento do seu objetivo, para serem fácil e rapidamente identificados em
qualquer estágio de andamento do projeto. Deve ser exposto em um local de fácil
acesso para todos.
13
Volte ao Sumário
Figura 4: 12 SCRUMBOARD
Fonte: patboard.com
14
Volte ao Sumário
5. PRINCÍPIOS E COMPARAÇÃO DA ABORDAGEM ÁGIL

COM O MODELO DE DESENVOLVIMENTO EM CASCATA
Os segmentos de mercado acompanham as tendências incorporadas aos

novos ciclos econômicos, sendo, nesse contexto, necessário ter medidas
adaptáveis, rápido aprendizado e adoção de estratégias modernas. A me-
todologia ágil é, portanto, um processo cada vez mais relevante no geren-
ciamento de projetos corporativos (Gaea Consulting, 2017).
5.1 O QUE É A METODOLOGIA ÁGIL?

Trata-se de uma matriz com a abordagem mais dinâmica, que procura
tornar os processos alinhados por meio de ações colaborativas, baseando-se na
velocidade e flexibilidade. Esta metodologia utiliza-se de softwares inteligentes,
possuindo capacidade de atuação ampliada. Neste método, os profissionais e
ferramentas irão operar interativamente, participando ativamente do time nas
tarefas.
As aplicabilidades mínimas alternativamente poderão ser entregues aos
clientes antes da finalização integral do projeto, podendo ser calculado em etapas
ou entregas parciais. Esta metodologia simplifica a solução de maneira mais
inteligente de programas para evitar possíveis falhas no projeto.
5.2 O QUE É METODOLOGIA TRADICIONAL?
Diferente da metodologia ágil, a tradicional opera com modelos de de-

mandas conhecidos como “cascata”, nos quais as etapas são mais rígidas
e programadas. Nesses modos, o processo é sequencial e focado no re-
sultado final, não há abertura para implementações em conjunto com o
cliente durante o desenvolvimento. Os requisitos são determinados na
fonte, de modo mais específico (Gaea Consulting, 2017).
Esta metodologia pode ser vista como uma ferramenta ultrapassada, no

entanto, ela pode representar uma importante alternativa para a estruturação do
planejamento nas empresas que lidam com equipes de grande número, projetos
singulares e em momentos de mudanças.
15
Volte ao Sumário
5.3 COMO SABER QUAL METODOLOGIA ADOTAR?

Não existe uma maneira para se definir integralmente que alguma
metodologia é perfeitamente apropriada para uma organização do outro tipo de
metodologia. Para que a Adesão de qualquer método seja realizada, é necessário
analisar minuciosamente o perfil do projeto a ser produzido, as capacidades que
o time possui e, por fim, a disponibilidade do cliente para desenvolvimento em
conjunto das metas do projeto.
A empresa deve verificar qual metodologia será mais eficiente em relação
aos seus projetos. Para isso, deve-se convocar profissionais habilitados para
reconhecimento e posterior direcionamento dos empreendimentos, baseados
nas metodologias apropriadas.
A metodologia possui inovação, criatividade e colaboração, características
de destaque no mundo atual. A metodologia tradicional pode ser aplicada em
casos mais específicos, no qual a metodologia ágil não é adequada. Para tanto,
é necessário aprofundar-se em cada método, conhecer as capacidades de cada
uma delas, para poder aplicá-las de maneira coerente e correta.
16
Volte ao Sumário
6. ETAPAS E FERRAMENTAS DOS DIFERENTES

MÉTODOS ÁGEIS: SCRUM
6.1 CERIMÔNIA
Já definidas e conceituadas as funções do Scrum Master, Product Owner e
Time de Desenvolvimento, é o momento de aprofundamento sobre como ocorre
a dinâmica de desenvolvimento iterativo-incremental dentro de times utilizando
o Scrum.
Abaixo é exemplificado o desdobrar de um processo de sprint a partir do
Product Backlog que será explanado mais à frente:
No decorrer de uma Sprint, acontecem uma sucessão de cerimônias, que
tem o intuito de assegurar a transparência e propiciar oportunidades para o
inspecionamento e adaptações, assim como são determinados nas bases do
Scrum. Estas cerimônias são distinguidas em: Sprint Planning, Daily Meeting,
Sprint Review e Sprint Retrospective.
Sprint Planning
Trata-se de uma cerimônia, como sugerido em seu nome, de planejamento
da Sprint. Ela sempre ocorre no início da mesma.
Nesta cerimônia traça-se o objetivo da sprint (Sprint Goal), o escopo de

trabalho (Sprint Backlog) e discute-se como que este trabalho será rea-
lizado, em linhas gerais. Esta cerimônia possui uma timebox de no máxi-
mo um dia de planejamento para cada trinta dias corridos de sprint, assim,
caso a sprint seja de menor duração, a Sprint Planning (TOOLS, 2016).
Quando se estima que já há quantitativos de tarefas suficientes para o

período de realização da sprint, o escopo pode ser fechado, dando início de seu
desenvolvimento. Cabe ao time de desenvolvimento produzir as estimativas, em
meio às prioridades do Product Owner, cabendo ao PO a tarefa de negociação
com os desenvolvedores.
Daily Scrum
Daily Scrum é definida como uma cerimônia de alinhamento. Para o seu bom
desenvolvimento, ela deve seguir as seguintes regras:
17
Volte ao Sumário
• Acontecer todos os dias;

• Duração máxima de 15 minutos com todos seus participantes em pé;
• Acontecer no mesmo local, mesmo horário, previamente combinado com a
equipe;
• Cada participante terá a sua vez de fala. Os demais, ouvem;
• Cada pessoa fala aos outros membros do time, não funciona como uma
“prestação de contas”;
• Não são discutidos detalhes durante seu andamento, apenas após.
Todas as regras devem ser seguidas de acordo com a psicologia. Todas elas
possuem finalidade, a exemplo:
• ●Caso não ocorra em pé, mas com as pessoas sentadas, inclinam-se a demorar
mais em sua fala, até mesmo perder o foco;
• ●O tempo de andamento pequeno evita que as pessoas reclamem.
Um framework bastante recorrente para desenvolvimento da Daily constitui-

se em cada participante realizar os seguintes questionamentos: o que eu fiz desde
a última Daily? O que eu vou fazer depois dessa Daily? Tem algo impedindo o meu
trabalho?
Estes questionamentos são importantes, pois expõe se o time está andando
corretamente pelo caminho previamente planejado e se algum membro da
equipe necessita de suporte. O Scrum Master e o Product Owner têm um papel
importante neste processo. Mesmo não possuindo atividades no Sprint Backlog,
eles são capazes de identificar problemas e desenvolver soluções.
Sprint Review
No andamento deste framework, “há a cerimônia chamada Sprint Review ou
Revisão da Sprint, um momento no último dia do ciclo de desenvolvimento onde
o Time Scrum se reúne com os stakeholders e apresenta o progresso” (TOOLS,
2016). As principais finalidades do Sprint Review são:
A sua primeira finalidade é efetuar uma entrega que conceda valor ao cliente.
Segundo Tools (2016), “o objetivo principal de toda sprint é gerar um incremento
de software com potencial de ser colocado em produção”.
A sua segunda finalidade é defendida que “principalmente em projetos de
inovação ou em ambientes complexos e adaptativos, deixar para fazer uma única
entrega ao final do projeto” não é aconselhável.
Desta maneira, o Sprint Review não é fechado por conta das mudanças
constantes do mercado. O produto desenvolvido pode nunca ter sido produzido
no mercado, logo, precisará de ajustes.
A Sprint Review é um excelente momento para receber feedback dos
18
Volte ao Sumário
stakeholders e ajustar o curso do projeto, garantindo a comunicação e diminuindo

o risco do projeto como um todo. Outra regra a ser seguida é a apresentação do
trabalho planejado x trabalho realizado, determinando as próximas etapas para
serem seguidas pelo Time Scrum, definindo o que o Product Owner planeja para
a próxima sprint. Nesta cerimônia deve-se:
• Mostrar itens do Sprint Backlog que estão DONE e os que não foram finaliza-
dos;
• Falar dos problemas enfrentados que impediram alguns itens de ficarem
DONE;
• Exibir o funcionamento e tirar dúvidas dos itens DONE;
• Falar do objetivo da próxima sprint, apresentando um esboço de Sprint Ba-
cklog;
• Rever orçamento, datas e prazos caso necessário.
A cerimônia deve durar até quatro horas para cada trinta dias de sprint e a
sprint obtém sucesso quando “Product Owner e stakeholders concordam que
o trabalho entregue foi satisfatório para esta iteração e o PO tem novos insights
para atualizar seu Product Backlog” (TOOLS, 2016).
Sprint Retrospective
A Sprint Retrospective é entendida como uma cerimônia que ocorre sempre
ao final da sprint, para finalizá-la. Durando no máximo três horas para cada trinta
dias de sprint, tem como mediador o Scrum Master. Todo time deve participar e
expor como a sprint ocorreu e as melhorias para as próximas.
Existem várias formas de conduzir esta dinâmica, mas todas possuem

como objetivo levantar uma espécie de matriz SWOT da equipe gerando
um plano de ação de melhoria contínua que deverá ser executado con-
comitantemente à sprint seguinte. Analisam-se processos, ferramentas e
relacionamentos para dizer o mínimo e é importante que exista um am-
biente seguro e sincero dentro do time para que de fato possamos re-
solver todos os problemas encontrados. É o Time Scrum resolvendo os
próprios problemas do Time Scrum (TOLLS, 2016).
O uso excessivo desta dinâmica pode se tornar enfadonha para o time,

perdendo, assim, seu objetivo. A partir daí cabe ao Scrum Masters procurar novas
alternativas para tal papel.
19
Volte ao Sumário
6.2 ARTEFATOS
Os artefatos e as cerimônias são as características mais peculiares dos

métodos ágeis. De reuniões em pé a quadros cheios de post its, eles es-
tão por toda parte e são um símbolo do informalismo criativo e colabora-
tivo que é a base da transformação cultural que eles trazem às empresas.
Falando especificamente do Scrum e, ao contrário do que muita gente
pensa, temos pouquíssimos artefatos. Apenas quatro, para falar a verdade
(TOOLS, 2016).
Os pilares, bases do Scrum, são essenciais para a existência dos artefatos. São
distinguidos como: Product Backlog, o Sprint Backlog, o Incremento e a Definição
de Pronto.
Product Backlog
O Product Backlog é definido como um dos artefatos do Scrum que, por sua
vez, auxilia e orienta o trabalho do time. Product Owner tem o papel de gerenciá-
lo, fazendo a determinação final sobre ele, pode se configurar em um processo
simples ou não tão simples. A técnica é considerada correta para a gestão do
Product Backlog quando obtém êxito em conservar o time bem alinhado e o
produto concedendo valor aos clientes, mesmo que não tenha uma técnica
definida:
Todo tipo de insight de negócio demanda de áreas estratégicas ou da

necessidade de mercado poder virar um item de Product Backlog, mas
somente o P.O. que pode priorizá-lo. Um Backlog priorizado, refinado e
acessível a todos os membros do Time Scrum é um pré-requisito para que
o pilar da Transparência do Scrum seja respeitado. Mais do que isso, so-
mente itens de backlog que estejam devidamente refinados e priorizados
que podem entrar para discussão em uma Sprint Planning (TOOLS, 2016).
O refinamento do Product Backlog consiste no detalhamento dos itens

de backlog que tem prioridade, e encontram-se no topo da lista, de forma
que os questionamentos do negócio tenham sido resolvidos, riscos técnicos
pesquisados e prováveis obstáculos para o entendimento do time solucionados.
É normal que as prioridades mudem após este refinamento. Neste caso, o P.O.
terá a responsabilidade de realizar tal refinamento com o auxílio das stakeholders
e de todo o Time Scrum.
20
Volte ao Sumário
Sprint Backlog
O Sprint Backlog é um artefato concebido em uma Sprint Planning. O

Product Owner obtém um Product Backlog organizado, com os elementos mais
no cume e minuciosamente detalhados para que dessa forma o time compreenda
as medidas que devem ser tomadas, selecionando-se um a um os elementos do
Product Backlog no decorrer da Planning. Estes elementos são apresentados,
discutidos, quebrados em atividades e acrescentados ao Sprint Backlog em
quantidade necessária para que “o Time de Desenvolvimento julgue adequada
para o tamanho da iteração que estejam utilizando” (TOOLS, 2017).
Ressalta-se que, casualmente, podem ser acrescentados elementos no
Sprint Backlog, que de início não eram previstos pelo Product Owner para
a sustentação do sistema, com a possibilidade de serem distinguidas como
evolutiva, adaptativa ou corretiva. Sempre tendo que haver um consenso entre o
Time de desenvolvimento:
Ao término da sprint, espera-se que todos os itens do Sprint Backlog te-

nham sido concluídos. Ao finalizarmos esta iteração com este artefato, te-
mos insumo para uma série de outras atividades como o escopo da Sprint
Review, alguns tópicos para a Sprint Retrospective, métricas para o Scrum
Master analisar (lead time, cycle time, etc.), dados para o Product Owner
atualizar no roadmap de produto e muito mais. Por isso, é importante ge-
renciar corretamente este artefato ao longo do desenvolvimento da sprint
(TOOLS, 2016).
Definição de pronto e o incremento

A cada iteração de desenvolvimento o objetivo do time deve ser gerar
um Incremento de software potencialmente entregável. Por potencialmente
entregável entenda que o software desenvolvido tem plenas condições técnicas
de ir para produção, mas que ainda pode ter seu deploy adiado em virtude de
questões de mercado, de negócios, etc., cabendo ao Product Owner decidir por
colocá-lo em produção ou não (TOOLS, 2016).
Esta determinação do ponto desdobra-se em um artefato do Scrum que
fortalece a transparência e é uma das bases principais da metodologia, uma
vez que se torna universal em meio aos participantes do time, o significado de
DONE. A DoD, por sua vez, determina um vocabulário coletivo, que apresenta em
que momento um elemento está DONE, ou seja, quanto ele está tecnicamente
finalizado para sua produção.
Segundo Tools (2016), “uma Definição de Pronto bem construída, que
tenha envolvido o Time Scrum inteiro, engloba aspectos de construção, teste e
homologação de cada item de backlog da sprint”. Esta definição é variável entre
os times, pois dependem do desenvolvimento de técnicas e testes, assim como
21
Volte ao Sumário
os aspectos burocráticos que, por sua vez, são inerentes a cada organização e
diferenciam as etapas de constituição de um produto e outro. Tools (2016) traz
um exemplo de Definição de Pronto:
• ●Codificado;
• Código Revisado (Code Review);
• Testes Unitários passando (Unit Tests);
• Testes Funcionais passando (manuais ou automatizados);
• Versionado (Git, por exemplo);
• Homologado (geralmente pelo Product Owner).
A definição deste ponto pode evoluir após as finalizações de um sprint para

o outro, resultando na qualidade do time, “seja tão alta quanto necessária e que
o empirismo inerente aos ciclos de melhoria contínua contribua para produzir
software com cada vez mais qualidade” (TOOLS, 2016).Hábitos contemporâneos
de desenvolvimento de produtos, assim como Lean Startup e Customer
Development:
Trabalham com a ideia de que quanto antes o Product Owner conseguir

ter o produto em produção, para testar com clientes reais, antes a empre-
sa irá descobrir o que de fato traz valor para o mercado e com isso reali-
mentar o processo gerando um produto de sucesso (TOOLS, 2016).
22
Volte ao Sumário

MÉTODOS ÁGEIS: CRYSTAL
7.1 O QUE É METODOLOGIA ÁGIL CRYSTAL?

O Crystal trata-se de uma família ou categoria de metodologias de
desenvolvimento de software e que, assim como um cristal, possui características
de cores diversas e rigidez, relacionando-se ao tamanho e até mesmo ao nível
crítico do projeto.
Criada por Alistair Cockburn e Jim Highsmith a fim de conseguir uma

abordagem de desenvolvimento de software que premia a “manobrabi-
lidade” durante o que Cockburn caracteriza como “um jogo cooperativo
de invenções e comunicação de recursos limitados, com o principal obje-
tivo de entregar softwares úteis funcionando e com o objeto secundário
de preparar-se para o jogo seguinte” (Leandro MTR, 2013).
Tais métodos têm foco nos talentos e habilidades dos indivíduos, dessa forma,
permite que a construção do processo seja moldada de acordo com características
particulares da equipe/time, combinando a cultura de trabalho com a abordagem
de desenvolvimento ágil. Os parâmetros para o desenvolvimento da metodologia
Crystal são: o número de pessoas envolvidas e o nível crítico.
7.2 PARÂMETROS CONFORME O TAMANHO

A metodologia Crystal é determinada por uma cor, de acordo com o número
de incluídos.
• Crystal Clear (metodologia leve): de uma a oito pessoas, chegando até doze;
• Yellow: equipes de dez a vinte participantes;
• Orange times: de vinte a cinquenta pessoas;
• Red: equipes de cinquenta a cem membros.
7.3 PARÂMETROS CONFORME NÍVEL CRÍTICO DO PROJETO

O Crystal utiliza algumas letras como representação de potenciais perdas
causadas por uma falha no sistema de desenvolvimento de software:
• ●C de Confort (Conforto): casos mais leves, os quais a falha do sistema resulta

na perda de credibilidade do usuário;
• D de Discretionary Money: são casos no quais a falha do sistema resulta em na
perda monetária. No entanto, inexpressiva, que não virá a ocasionar a falência;
• E de Essencial money (Dinheiro essencial): são casos em que a falha do sis-
tema resulta na perda de uma quantia necessária (grandes valores), os quais
podem ocasionar a falência da empresa;
23
Volte ao Sumário
• L de Life (vida): falhas no sistema que resultam em perda de vidas.
A magnitude do projeto irá definir os requisitos necessários, coordenação e

metodologias que exigem mais rigidez, ao contrário de projetos menores, ou o
nível de criticidade do software.
7.4 CARACTERÍSTICAS DA METODOLOGIA CRYSTAL

Seja qual for o Método Crystal escolhido, existem sete princípios-chave em
qualquer um:
• Entrega frequente: em que as partes interessadas podem visualizar as versões

intermediárias do processo, sendo apto de fornecer feedback;
• Feedback contínuo: é a reunião contínua não somente da equipe, mas tam-
bém a reunião regular entre a equipe e os clientes, evitando, assim, que pro-
váveis erros sejam descobertos somente no final do projeto;
• Comunicação Constante: tanto os projetos grandes quanto os de menor por-
te almejam possuir acesso constante às pessoas que determinam os requisi-
tos;
• Segurança: Crystal é algo único que foca na segurança no que diz respeito ao
desenvolvimento de software. Liberdade de comunicação durante o projeto,
sem temer retaliações. Outro aspecto que se refere à segurança e à distinção
entre as finalidades dos projetos;
• Foco: escolha de itens para ser priorizado
• Acesso para Usuários: propõe que o time desenvolvedor do projeto tenha
acesso a um ou mais usuários do sistema a ser constituído;
• Testes automatizados e Integração: são utilizados para verificar a funcionalida-
de do plano.
Já o ciclo de vida desta família de metodologia é baseado nas seguintes

práticas:
Staging (Planejamento do próximo incremento do sistema), Edição e re-
visão (Construção, demonstração e revisão dos objetivos do incremento).
Monitoramento (monitorado com relação ao progresso e estabilidade da
equipe), Paralelismo e fluxo, Inspeções de usuários, Workshops refletivos
(reuniões que ocorrem antes e depois de cada interação), Local matters
(procedimentos a serem aplicados), Work Products (Produtos de Traba-
lho), Standards (padrões de notação, convenções de produto, formata-
ção e qualidade usadas no projeto); Tools (Ferramentas mínimas utiliza-
das). (DevMedia, 2008)
24
Volte ao Sumário

MÉTODOS ÁGEIS: PROGRAMAÇÃO EXTREME
8.1 O QUE É METODOLOGIA ÁGIL XP?

Extreme Programming (XP) trata-se de uma metodologia de desenvolvimento
de software, criada nos EUA, ao fim da década de 90. Vem sendo popularizado
em diversos países por ajudar a criar sistemas de melhor qualidade, que são
produzidos em menos tempo e de forma mais econômica que o habitual. Tais
objetivos são alcançados através de um pequeno conjunto de valores, princípios
e práticas que diferem substancialmente da forma tradicional de se desenvolver
softwares.
Criada em 1997, o XP possui adeptos e outros que duvidam da sua real

utilidade, muitos por falta de conhecimento ou entendimento achando
que no XP apenas código é o que realmente interessa descartando o res-
to como planejamento, documentação, etc. O objetivo principal do XP
é levar ao extremo um conjunto de práticas que são ditas como boas na
engenharia de software. Entre elas, podemos citar o teste, visto que pro-
curar defeitos é perda de tempo, nós temos que constantemente testar
(DevMedia, 2013).
O XP tem diversos padrões e práticas, não se resumindo apenas ao testar,

mas a:
• ●Fazer testes continuamente;

• Revisar continuamente;
• Projetar e refatorar constantemente;
• Fazer teste de integração e integrar constantemente;
• Desenvolver soluções simples sempre;
• Realizar iterações curtas sempre.
8.1 VALORES DO EXTREME PROGRAMMING

Tais práticas do Extreme Programming XP são baseadas em valores, que são:
Comunicação:
O XP baseia-se em etapas que não podem ocorrer sem o uso da comunicação.
Deve haver uma comunicação entre os desenvolvedores e seus clientes.
25
Volte ao Sumário
De preferência, os clientes devem estar sempre presentes para criar His-

tórias de usuário e cliente on-site (CCC) ou ainda tirar dúvidas. Outra
forma de comunicação no XP é a Programação em pares, onde os de-
senvolvedores programam num mesmo computador, nesse formato de
programação ambos estão constantemente se comunicando e trocando
ideias. O Jogo do planejamento (planning poker) também é outra forma
de comunicação, visto que a equipe de desenvolvimento está dando sua
visão técnica; o cliente, por sua vez, está dando requisitos em prol do ne-
gócio e dando as prioridades (DevMedia, 2013).
A comunicação contribui para a eliminação de documentos (físicos) e

favorecendo a comunicação cara a cara, dando, assim, mais interatividade entre
os membros da equipe.
Simplicidade:
Algo simples e geralmente feito com mais rapidez. Neste sentido, o foco é
sempre realizar o que é mais simples, primeiramente, e o mais complexo em outros
momentos. Pois, em muitas ocasiões, as atividades com mais complexidade sequer
são utilizadas ou reutilizadas. Então, deve-se sempre ter o questionamento, o que
se é mais simples, mas realmente funciona. Neste sentido, a comunicação faz uma
relação com a simplicidade, pois cada vez em que a comunicação evolui entre os
membros do time, se estabelece confiança para fomentar a simplicidade.
●Feedback:
É comumente desenvolvido no time SCRUM por meio das reuniões
recorrentes, retrospectivas, reuniões para revisar os produtos, etc. Feedback é
um valor fundamental dentro deste modelo.
O XP foi o precursor a falar em feedback e afirma que ele possibilita que

o software evolua. O XP, como algo mais técnico que o SCRUM, diz que
devemos sempre “Perguntar ao software e não a um documento”, uma
forma de alcançar isso é através dos testes automatizados que permitem
feedback rápido. Os testes automatizados respondem de forma imediata
se aquilo que foi introduzido ainda está funcionando (DevMedia, 2013).
O Feedback necessita ser feito o mais cedo possível, pois este acompanha-
mento constante ajuda a verificar se o processo está acontecendo corretamente,
essas interações garantem, conjuntamente com o cliente, se o prazo é o planejado
e se o projeto está correto.
26
Volte ao Sumário
Coragem:
Em muitas ocasiões não realizamos certas mudanças por não termos coragem
de fazê-lo. O XP nos diz que se deve possuir coragem de colocar o cliente sempre
a par do que ocorre. Entre as ações que o XP define como corajosas, destaca-se:
• ○ Acreditar na capacidade e habilidade de reagir a mudanças;

• ○ Trocar de paradigma;
• ○ Aprender com os erros;
• ○ Dar e receber feedback sem medo das consequências;
• ○ Acreditar em feedback concreto;
• ○ Fazer o que necessita ser feito;
• ○ Descartar código ruim;
• ○ Descartar protótipos criados para testar ideias.
●Coach:
Fica responsável por repassar tais valores ao time, transformando-os
em práticas. Geralmente, possuem mais experiências e auxiliam as equipes
a implementarem o XP, além de monitorar se as regras estão sendo seguidas
corretamente.
27
Volte ao Sumário
CONSIDERAÇÕES FINAIS
A metodologia ágil não se trata somente de regras que devem ser

minuciosamente seguidas para um resultado satisfatório nos processos. Ela
também implementa valores, não só as práticas profissionais da pessoa, mas
também as práticas de vida cotidiana do profissional.
A metodologia ágil ganha força e valor à medida que é utilizada nas
organizações, onde se faz necessária para agilidade dos projetos e entregas
assertivas. Qual metodologia a ser utilizada fica como decisão do gestor e da
cultura organizacional.
Sendo assim, espero que o presente material seja um grande auxílio para
desenvolver seus conhecimentos em relação ao assunto e que ajude a tirar suas
dúvidas. Bons Estudos!
Reflexão
O que consigo produzir e organizar a partir de tudo que estudei sobre SCRUM e
outras metodologias?
28
Volte ao Sumário
REFERÊNCIAS BIBLIOGRÁFICAS
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível

em: <http://www.agilemanifesto.org> Acesso em 27 jan. 2019.
BENZECRY, Fernando Salztrager. Metodologias ágeis para gerenciamento
de projetos de inovação e pesquisa e desenvolvimento. Trabalho de conclusão
de curso (MBA em Gerenciamento de Projetos). Fundação Getúlio Vargas, 2017.
GAEA Cosunting. 2019. Disponível em: <https://gaea.com.br/>.
Leandro MTR Web Developer. Metodologia ágil Crystal. 2013. Disponível
em <http://www.leandromtr.com/>
Massari, Vitor L. Gerenciamento Ágil de Projetos. BRASPORT. Edição do
Kindle.
Método ágil. Método Ágil. 2017. Disponível em <https://www.metodoagil.
com/>
PICHLER, R. Gestão de Produtos com Scrum: implementando métodos
ágeis na criação e desenvolvimento de produtos. Rio de Janeiro: Elsevier, 2011.
152p.
Plataforma DevMedia. Disponível em: https://devmedia.com.br/uma-visao-
geral-sobre-o-scrum/24470
The Scrum Guide. 2017. Disponível em <https://www.scrum.org/resources/
scrum-guide>
TOLLS. Luiz. 2016. Scrum e Métodos Ágeis: Um Guia Prático.
29
Volte ao Sumário
Desenho Instrucional: Veronica Ribeiro

Supervisão Pedagógica: Laryssa Campos
Revisão pedagógica: Camila Martins
Design editorial/gráfico: Trayce Melo
2021
30

Jupiter Gestao de Projetosenfase em Metodologiaageispdf

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Jupiter Gestao de Projetosenfase em Metodologiaageispdf

Enviado por

Direitos autorais:

Formatos disponíveis

Volte ao Sumário

Navegue entre os capítulos

Moura, Carlos André Gonçalves, 2019.

Palavras-chave: 1. Gestão de projetos; 2. Metodologia Ágil; 3. Manifesto

No decorrer das últimas décadas, as Metodologias Ágeis vieram se adaptando

1. VISÃO GERAL DO SCRUM

1.1 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE: UMA

O modelo em cascata (em inglês “waterfall”) foi, ainda na década de 1970,

Esta abordagem é comparada por conta de suas semelhanças às da linha

2.1 O SCRUM MASTER

Semelhantemente, o Scrum Master pode ser visto como o senhor do Scrum.

2.2 PRODUCT OWNER

O Product Owner é o representante máximo dos desejos do cliente den-

O Product Owner difere-se das metodologias tradicionais, as quais se limitam

2.3 TIME DE DESENVOLVIMENTO

Enquanto existe apenas um Scrum Master e um Product Owner por Time

Desta forma, é de muita importância salientar que responsabilidade

aconteça. Assim como se ocorrer a programação, mas os testes não serem

3. ABORDAGENS E PRÁTICAS ÁGEIS DE

Projetos com ótimos resultados dependem muito da metodologia da gestão

• Interatividade: o Manifesto Ágil, que funcionou como base para a metodo-

ças acontecem no decorrer do desenvolvimento dos processos e o time deve

• ●Transparência elevada: Para a maior satisfação do cliente e para a obtenção

4.INTRODUÇÃO AO MANIFESTO ÁGIL

4.1 O QUE É E QUAL A SUA HISTÓRIA?

Na primavera de 2000, líderes da comunidade de extreme programming

Os métodos leves e do XP possuíam uma abordagem menos densa e menos

4.2 OS VALORES DO MANIFESTO ÁGIL?

●Indivíduos e interações mais que processos e ferramentas

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

4.3 FERRAMENTAS DAS METODOLOGIAS ÁGEIS

Figura 1: 12 PRINCÍPIOS DO MANIFESTO ÁGIL

Segundo Spitaliere (2017), o termo vem do japonês “registro” ou “placa visível”.

Fotografia 3: Gráfico Burndown

O Burndown chart ou gráfico de Burndown é o gráfico usado por equipes

5. PRINCÍPIOS E COMPARAÇÃO DA ABORDAGEM ÁGIL

Os segmentos de mercado acompanham as tendências incorporadas aos

5.1 O QUE É A METODOLOGIA ÁGIL?

5.2 O QUE É METODOLOGIA TRADICIONAL?

Diferente da metodologia ágil, a tradicional opera com modelos de de-

Esta metodologia pode ser vista como uma ferramenta ultrapassada, no

5.3 COMO SABER QUAL METODOLOGIA ADOTAR?

6. ETAPAS E FERRAMENTAS DOS DIFERENTES

Nesta cerimônia traça-se o objetivo da sprint (Sprint Goal), o escopo de

Quando se estima que já há quantitativos de tarefas suficientes para o

• Acontecer todos os dias;

Um framework bastante recorrente para desenvolvimento da Daily constitui-

stakeholders e ajustar o curso do projeto, garantindo a comunicação e diminuindo

Existem várias formas de conduzir esta dinâmica, mas todas possuem

O uso excessivo desta dinâmica pode se tornar enfadonha para o time,

Os artefatos e as cerimônias são as características mais peculiares dos

Todo tipo de insight de negócio demanda de áreas estratégicas ou da

O refinamento do Product Backlog consiste no detalhamento dos itens

O Sprint Backlog é um artefato concebido em uma Sprint Planning. O

Ao término da sprint, espera-se que todos os itens do Sprint Backlog te-

Definição de pronto e o incremento

A definição deste ponto pode evoluir após as finalizações de um sprint para

Trabalham com a ideia de que quanto antes o Product Owner conseguir

7. ETAPAS E FERRAMENTAS DOS DIFERENTES

7.1 O QUE É METODOLOGIA ÁGIL CRYSTAL?

Criada por Alistair Cockburn e Jim Highsmith a fim de conseguir uma

7.2 PARÂMETROS CONFORME O TAMANHO

7.3 PARÂMETROS CONFORME NÍVEL CRÍTICO DO PROJETO