metodologia agil

Prévia do material em texto

20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 1/16
Estimado(a) estudante, neste roteiro, iremos abordar dois momentos especí�cos na história da
construção de software. Num primeiro momento, iremos revisitar as abordagens clássicas
(cascata e incremental). Esses modelos clássicos também são chamados de modelos
tradicionais. Logo em seguida, vamos conhecer um pouco mais sobre os métodos ágeis e focar
em três boas abordagens desses métodos (Scrum, Kanban e eXtreme Programming). Ao re�etir
sobre o modelo clássico e o modelo ágil, você irá compreender quais os benefícios de cada
prática e porque os métodos ágeis se tornaram a opção de maior adesão em novos projetos de
software, garantindo, assim, entrega de valor de forma constante.
Caro(a) estudante, ao ler este roteiro você vai:
conhecer os modelos tradicionais de criação de software;
conhecer sobre o manifesto ágil;
conhecer sobre Scrum, seus artefatos, cerimônias e papéis;
conhecer sobre o método Kanban, a visualização do �uxo e algumas métricas;
conhecer sobre a programação extrema e suas principais práticas.
Introdução
A ciência da computação estuda métodos e técnicas visando à automatização de processos e
criação de soluções que processam dados. Ela é recente quando comparada às demais
ciências. A partir de 1945, com o �m da segunda guerra mundial, os avanços tecnológicos
foram enormes, tanto na parte de peças físicas, denominadas hardware, como na parte lógica,
denominado software. Essa evolução gerou novos estudos e aprendizados os quais culminaram
Metodologia de Desenvolvimento Ágil
Roteiro deRoteiro de
EstudosEstudos
Autor: Esp. Wagner Mendes Voltz
Revisor: Ma. Amanda de Britto Murtinho
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 2/16
na criação de duas novas engenharias, a da computação e a do software. Neste material, vamos
passar por uma sequência de momentos da engenharia de software, abordando os modelos
clássicos até os dias atuais.
Manifesto Ágil
Um estudo conduzido pelo The Standish Group International, em 2001, revelou os seguintes
pontos:
em média, os atrasos representaram 63% mais tempo do que o estimado;
os projetos que não cumpriram o orçamento custaram, em média, 45% mais; e
no geral, apenas 67% das funcionalidades prometidas foram efetivamente entregues.
Esse estudo foi nominado e publicado como CHAOS Report e considerou dados de 280 mil
projetos de software nos Estados Unidos. Com a análise destes dados, foi identi�cada uma
crise do software.
Motivados por esse cenário de crise, um grupo de 17 engenheiros de software se reuniram
para compartilhar o que eles estavam fazendo para fugir desta crise. Vários deles estavam
experimentando maneiras diferentes de produzir software.
A �loso�a por trás dos métodos ágeis está re�etida no manifesto ágil, criado
por desenvolvedores líderes desses métodos. O manifesto diz: 
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o
nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,
passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda (SOMMERVILLE, 2019, p. 60).
Um processo de desenvolvimento de software que se baseia no manifesto ágil é denominado
metodologia ágil. Dentre elas, temos o Scrum, XP (eXtreme Programming) e outras.
Agora, estimado(a) estudante, re�ita sobre as metodologias ágeis. Utilize o texto de apoio para
entender  como ele está fundamentado num conjunto de doze princípios.
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 3/16
LEITURA
Princípios por Trás do Manifesto Ágil
Autores: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Je�ries, Jon Kern, Brian
Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Je� Sutherland, Dave Thomas
Ano: 2001
O texto representa os 12 princípios do manifesto ágil. Os 4 valores são os pilares de
sustentação e os princípios são considerados como embasamento e fundamentação para as
metodologias ágeis.
A C E S S A R
Modelo Cascata x Modelo Ágil
A produção de um software segue etapas bem de�nidas e com seus contextos bem claros. O
primeiro modelo de processo para desenvolvimento de software a ser publicado foi o modelo
cascata. Conforme a Figura 1, percebemos a existência de um conjunto de etapas
sequenciadas para a produção de um software.
Figura 1 - Modelo em cascata
Fonte: Sommerville (2019, p. 33).
Este modelo traz como benefício o foco no processo e execução por meio da especialização das
atividades, ou seja, cada pessoa atua numa etapa e faz o seu melhor. Quando o trabalho
termina, começa o trabalho da outra pessoa, na etapa em sequência.
[...] modelo em cascata é adequado somente para alguns tipos de sistema, tais
como: 
https://agilemanifesto.org/iso/ptbr/principles.html
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 4/16
1. Sistemas embarcados [...]
2. Sistemas críticos [...]
3. Grandes sistemas de software [...] (SOMMERVILLE, 2019, p. 34-35).
O autor também sugere em quais cenários o modelo em cascata não é recomendado: “O
modelo em cascata não é recomendado para situações em que a comunicação informal do
time é possível e nas quais os requisitos de software mudam rapidamente” (SOMMERVILLE,
2019, p. 35).
Para reduzir os problemas de lentidão e burocracia, foi criado um segundo modelo de processo
de desenvolvimento, o qual busca entregas menores e incrementais. Sommerville (2019, p. 35)
cita: “O desenvolvimento incremental se baseia na ideia de desenvolver uma implementação
inicial, obter feedback dos usuários ou terceiros e fazer o software evoluir através de várias
versões até alcançar o sistema necessário”.
O modelo incremental é a base para todas as abordagens ágeis, mas nem todas as
abordagens incrementais são ágeis, pois o modelo incremental está mais focado no processo
de execução e não nas pessoas e cliente, como é o que prega as metodologias ágeis.
O Quadro 1 apresenta uma comparação completa sobre os modelos tradicionais (incluindo o
modelo incremental) e os métodos ágeis.
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 5/16
Quadro 1 - Comparativo entre modelos tradicionais e métodos ágeis
Fonte: Prikladnicki, Willi e Milani (2014, p. 22).
  Tradicional Metodologias Ágeis
Pressupostos
fundamentais
Sistemas totalmente
especi�cáveis, previsíveis;
desenvolvidos a partir de
um planejamento
extensivo e meticuloso
Software adaptativo e de alta
qualidade; pode ser desenvolvido
por equipes pequenas utilizando os
princípios da melhoria contínua do
projeto e testes orientados a rápida
resposta a mudança.
Controle Orientado a processos Orientado a pessoas
Estilo de
gerenciamento Comandar e controlar Liderar e colaborar
Gestão do
conhecimento Explícito Tácito
Atribuições de
papéis
Individual - favorece a
especialização
Times auto-organizáveis - favorece
a troca de papéis
Comunicação Formal Informal
Ciclo do projeto Guiado por tarefas ouatividades
Guiado por funcionalidades do
produto
Modelo de
desenvolvimento
Modelo de ciclo de vida
(cascata, espiral ou
alguma variação)
Modelo iterativo e incremental de
entregas
Forma/estrutura
organizacional
desejada
Mecânica (burocrática com
muita formalização)
Orgânica (�exível e com incentivos
a participação e cooperação social)
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller6/16
LEITURA
Engenharia de Software
Autor: Ian Sommerville
Editora: Pearson Addison Wesley
Ano: 2019
Estimado(a) estudante, re�ita sobre como esses modelos poderão ajudar você na resolução do
estudo de caso. Para saber mais sobre esses modelos, faça uma leitura, em especial, do
capítulo 2 desse livro.
Disponível na Biblioteca Virtual da Laureate.
Scrum
O Scrum é uma framework ágil, criado por Ken Schwaber e Je� Sutherland (ambos signatários
do manifesto ágil), baseado nos estudos de Takeuchi e Nonaka, que   a�rmam que equipes
pequenas e multidisciplinares produzem os melhores resultados. Takeuchi e Nonaka
associaram estas equipes à formação scrum do rugby, já que, nesta formação, cada jogador do
mesmo time tem uma especialidade e, juntos, eles conseguem resultados melhores (no caso, a
conquista da posse de bola).
O Scrum é fundamentado no empirismo que a�rma que o conhecimento vem da experiência e
da tomada de decisões baseadas no que é conhecido. Scrum possui três pilares:
transparência, inspeção e adaptação.
O framework Scrum possui:
três papéis;
três artefatos;
quatro cerimônias.
Os papéis
Dono do produto / product owner (PO)
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 7/16
“O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto
resultado do trabalho do Time de Desenvolvimento (SCHWABER; SUTHERLAND, 2017, p. 6).
Scrum Master (SM)
“O Scrum Master é responsável por promover e suportar o Scrum como de�nido no Guia
Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e
os valores do Scrum” (SCHWABER; SUTHERLAND, 2017, p. 7).
Equipe de Desenvolvimento
O Time de Desenvolvimento consiste de pro�ssionais que realizam o trabalho
de entregar um incremento potencialmente liberável do produto “Pronto” ao
�nal de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint.
Somente integrantes do Time de Desenvolvimento criam incrementos
(SCHWABER; SUTHERLAND, 2017, p. 6-7).
Os artefatos
Um artefato dá uma visão do andamento do projeto e das sprints. Eles são divididos em:
backlog do produto / product backlog
backlog da Sprint / sprint backlog
incremento do produto
Backlog do produto / product backlog
É uma lista ordenada de funcionalidades que precisam ser desenvolvidas.
Backlog do Sprint / Sprint backlog
O backlog do sprint é o conjunto de itens que foram selecionados para serem implementados
durante o sprint.
Incremento do produto
O incremento é o resultado �nal de cada sprint.
As cerimônias
As cerimônias são eventos de duração �xa (timebox). Cada cerimônia é uma oportunidade para
inspeção e adaptação e deve ocorrer em intervalos regulares.  No scrum, temos as seguintes
cerimônias que acontecem durante um sprint:
reunião de planejamento;
reuniões diárias;
reunião de revisão;
reunião de retrospectiva;
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 8/16
Sprint
É um ciclo completo de desenvolvimento de sistema com duração �xa de tempo (timebox).
Aconselha-se a utilização de intervalos de 1 a 4 semanas de duração. Utilizar mais que 4
semanas não é aconselhável.
Agora, estimado(a) estudante, você conhece um dos métodos ágeis mais utilizados nos dias
atuais. Para se aprofundar no tema, é recomendada a leitura do texto e do artigo a seguir
descrito juntamente com o livro Scrum e Agile em Projetos, do autor Fábio Cruz, que está
disponível na Biblioteca Virtual da instituição.
LEITURA
O framework Scrum na visão de Fábio Cruz
Autor: Fábio Cruz
Ano: 2017
O artigo apresenta um resumo do framework Scrum na visão de uma das referências citadas 
A C E S S A R
Método Kanban
O método Kanban foi criado por David Anderson e é inspirado no modelo Toyota de produção
(kanban). Os nomes são semelhantes, mas quando usamos Kanban com a letra maiúscula,
estamos fazendo referência ao método criado por David Anderson, que é aplicado ao processo
de desenvolvimento de software. Quando usamos kanban com a letra minúscula, estamos nos
referindo ao modelo Toyota de produção, criado por Taiichi Ohno.
Kanban valoriza o �uxo das atividades, entrega contínua, visualização do trabalho, eliminação
do desperdício e melhoria contínua.
http://fabiocruz.com.br/o-framework-scrum-na-visao-de-fabio-cruz-2/
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 9/16
Tudo inicia com um mapa visual das etapas de trabalho. Com essa visualização, é possível
adicionar cartões representando quais alterações estão sendo realizadas no software.
Geralmente, usamos cartões com cores para diferenciar as alterações que representam
defeitos e das novas funcionalidades.
Ao visualizar o �uxo, é possível enxergar os possíveis acúmulos de trabalho em alguma etapa.
Esse excesso de trabalho é chamado de gargalo, que torna a entrega de uma tarefa mais lenta.
Para resolver o gargalo, o time deverá se reorganizar a �m de eliminar a sobrecarga de
trabalho numa das etapas e não começar uma nova atividade. Ao começar uma nova atividade,
o �uxo de trabalho só �cará mais sobrecarregado, engargalado e com desperdício.
Kanban trabalha com a visão de trabalho puxado e não empurrado (como é no Scrum). Os
cartões que já começaram a ser trabalhados são considerados como WIP, que signi�ca work in
progress. À medida que um item é �nalizado, o WIP diminui e um espaço de trabalho é liberado.
Com isso, uma nova tarefa poderá ser feita, caracterizando um sistema puxado de trabalho.
Limitar o trabalho em progresso (WIP) é importante para que, de fato, não haja excesso de
trabalho dentro do �uxo. Ao limitar o WIP, a entrada de novas tarefas é baseada na
disponibilidade de espaços de trabalho no �uxo e não é baseado na capacidade de trabalho do
sprint.
No Kanban, não há timebox para entrega de tarefas (sprint), ela é contínua. Se o cartão chegou
na etapa �nal, o cliente já pode utilizar. No Scrum, é necessário esperar o �nal do sprint.
Em projetos Kanban, devem ser adotadas métricas para avaliar a evolução do modelo. São
exemplos de métricas:
diagrama de �uxo cumulativo (Cumulative Flow Diagram, ou CFD);
lead time;
tempo de ciclo (cycle time);
throughput (vazão);
Agora, estimado(a) estudante, você conhece mais um método ágil que irá ajudar você na
entrega de software de valor. Para se aprofundar no tema, é sugerida a leitura de um e-book. O
material, fornecido por Herik Kniberg e Mattias Skarin, apresenta como unir o melhor do
Kanban com o Scrum para entregar software de valor de forma contínua.
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 10/16
LEITURA
Kanban com o Scrum
Autor: Herik Kniberg e Mattias Skarin
Editora: C4Media Inc
Ano: 2009
A C E S S A R
LEITURA
Vamos falar sobre métricas Kanban?
Autor: Ricardo Shikota
Ano: 2018
O artigo a seguir apresenta, de forma detalhada, as principais métricas utilizadas no Kanban.
Neste artigo, você entenderá como é a forma de cálculo de cada métrica e como utilizar no
processo de desenvolvimento de software.
A C E S S A R
eXtreme Programming (XP)
Enquanto Scrum é focado nas práticas de gerenciamento e organização e o Kanban é focado no
�uxo, o eXtreme Programming (XP) dá atenção à programação.
https://jkolb.com.br/wp-content/uploads/2013/09/Kanban-e-Scrum.pdf
http://www.matera.com/blog/post/vamos-falar-sobre-metricas-kanban
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 11/16
Entretanto, talvez a abordagem mais importante para mudanças de cultura no
desenvolvimento de software tenha sido o desenvolvimento da Programação
Extrema (do inglês Extreme Programming, ou XP). O nome foi cunhado por Kent
Beck com base na ideia de que essa abordagem leva a níveis "extremos" boas
práticas reconhecidas, como o desenvolvimentoiterativo (SOMMERVILLE, 2019,
p. 61).
O XP foi criado por Kent Beck, Ward Cunningham e Ron Je�ries, todos signatários do manifesto
ágil. XP é considerado um dos primeiros métodos ágeis.
O XP busca a constante satisfação do cliente. Com ele, o time de desenvolvimento deve abraçar
as mudanças e aceitar mudanças a todo o momento. Ele enfatiza o trabalho em equipe.
Gestores, clientes e desenvolvedores são parceiros de igual peso em um time colaborativo. O
XP possui quatro valores e doze práticas.
Valores
Feedback
“O Extreme Programming é organizado em ciclos curtos de feedback que possibilitem aos
usuários solicitar funcionalidades e aprender sobre elas através de software funcionando em
prazos curtos” (TELES, 2005, p. 59).
Comunicação
Projetos XP procuram envolver ativamente seus usuários (ou ao menos um
representante dos mesmos) fazendo com que se tornem parte integrante da
equipe de desenvolvimento. Na prática, isso signi�ca que o usuário (ou seu
representante) está presente no mesmo local onde os desenvolvedores
trabalham, possibilitando que eles tenham acesso rápido e direto a um ou mais
especialistas no domínio do negócio (TELES, 2005, p. 61-62).
Simplicidade
Além disso, equipes XP se baseiam no princípio de que funcionalidades extras
adicionam complexidade e não �exibilidade. Sendo assim, procuram adiar a
inclusão de qualquer funcionalidade até que ela realmente seja priorizada e
solicitada pelo cliente (TELES, 2005, p. 65).
Coragem
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 12/16
Equipes XP reconhecem os temores dos clientes e dos desenvolvedores e
buscam formas de lidar com eles de maneira corajosa. Ter coragem em XP
signi�ca ter con�ança nos mecanismos de segurança utilizados para proteger o
projeto (TELES, 2005, p. 67).
Práticas para codi�cação
As práticas do XP somadas com os valores irão garantir a entrega de software de valor e a
satisfação do cliente. As práticas podem ser veri�cadas no Quadro 2:
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 13/16
Prática Descrição
Propriedade
coletiva
Os pares de desenvolvedores trabalham em todas as áreas do
sistema de modo que não se desenvolvem “ilhas de conhecimento”,
e todos os desenvolvedores assumem a responsabilidade por todo o
código. Qualquer um pode mudar qualquer coisa.
Integração
contínua
Assim que o trabalho em uma tarefa é concluído, ele é integrado ao
sistema completo. Após qualquer integração desse tipo, todos os
testes de unidade no sistema devem passar.
Planejamento
incremental
Os requisitos são registrados em “cartões de história”, e as histórias
a serem incluídas em um lançamento são determinadas de acordo
com o tempo disponível e com sua prioridade relativa. Os
desenvolvedores decompõe essas histórias em “tarefas” de
desenvolvimento.
Representante do
cliente
Um representante do usuário �nal do sistema (o cliente) deve estar
disponível em tempo integral para o time de programação. Em um
processo como esse, o cliente é um membro do time de
desenvolvimento, sendo responsável por levar os requisitos do
sistema ao time, visando sua implementação.
Programação em
pares
Os desenvolvedores devem refatorar o código continuamente logo
que sejam encontradas possíveis melhorias para ele. Isso mantém o
código simples e de fácil manutenção.
Refatoração
Todos os desenvolvedores devem refatorar o código continuamente
logo que sejam encontradas possíveis melhorias para ele. Isso
mantém o código simples e de fácil manutenção.
Projeto (design)
simples
Deve ser feito o su�ciente de projeto (design) para satisfazer os
requisitos atuais, e nada mais.
Lançamentos
pequenos
O mínimo conjunto útil de funcionalidade que agregue valor ao
negócio é desenvolvido em primeiro lugar. Os lançamentos do
sistema são frequentes e acrescentam funcionalidade à primeira
versão de uma maneira incremental.
Ritmo sustentável
Grande quantidade de horas extras não é considerado aceitável, já
que o efeito líquido muitas vezes é a diminuição da qualidade do
código e da produtividade no médio prazo.
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 14/16
Quadro 2 - Práticas da programação extrema 
Fonte: Someerville (2019, p. 63).
Ao aplicar estas práticas, espera-se maior qualidade no código fonte produzido e entrega
contínua de software que atende a expectativa dos usuários.
LEITURA
Scrum and XP from the Trenches
Autor: Henrik Kniberg
Ano: 2007
Editora: C4Media Inc
Estimado(a) estudante, você conhece mais um método ágil, com foco na produção do software
e não tanto no processo de desenvolvimento. Para se aprofundar no tema, é sugerida a leitura
de um e-book. O material fornecido por Herik Kniberg, apresenta como unir o melhor do XP
com o Scrum para entregar software de valor de forma contínua.
A C E S S A R
Conclusão
Criar softwares pode e deve seguir um processo com etapas bem de�nidas e, durante os
diversos anos da existência da engenharia de software, modelos foram sendo apresentados e
praticados. Cada um desses modelos trouxe aprendizados para os dias atuais. Um dos maiores
aprendizados foi entender que produzir um software não é um trabalho repetitivo, como um
processo industrial, e que as pessoas envolvidas na concepção, construção e validação são
Desenvolvimento
com testes a priori
(test-�rst)
Um framework automatizado de testes de unidade é utilizado para
escrever os testes de um novo pedaço de funcionalidade antes que
ela própria seja implementada.
http://wwwis.win.tue.nl/2R690/2019-2020_Q1/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 15/16
mais importantes do que os processos engessados e burocráticos. Ao olharmos as
metodologias ágeis, encontramos as pessoas (clientes, usuários e time de desenvolvimento)
como sendo o foco do modelo de trabalho. Isso garante que sejam feitos softwares simples e
usados pelo cliente em sua integralidade, gerando valor e prosperidade.
Referências Bibliográ�cas
ANDERSON, D. J.; CARMICHAEL, A. Kanban Essencial Condensado. Lean-Kanban University,
2016. Disponível em:  https://leankanban.com/guide/essential-kanban-condensed-portuguese/.
Acesso em:  15 jan. 2020.
BECK, K et al. Manifesto para Desenvolvimento Ágil de Software: princípios por trás do
manifesto ágil. Agile Manifesto, 2001. Disponível em:
https://agilemanifesto.org/iso/ptbr/principles.html. Acesso em: 20 jan. 2020.
CRUZ, F. O framework Scrum na visão de Fábio Cruz. Scrum framework. Fábio Cruz, jul. 2017.
Disponível em: http://fabiocruz.com.br/o-framework-scrum-na-visao-de-fabio-cruz-2/. Acesso
em: 20 jan. 2020.
CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. São Paulo: Brasport, 2018.
KNIBERG, H. Scrum and XP from the Trenches. C4Media Inc., 2007. Disponível em:
http://wwwis.win.tue.nl/2R690/2019-2020_Q1/doc/ScrumAndXpFromTheTrenchesonline07-
31.pdf. Acesso em: 20 jan. 2020.
KNIBERG, H.; SKARIN, M. Kanban e Scrum: obtendo o melhor de ambos. InfoQ, 2009. Disponível
em:  https://www.infoq.com/br/minibooks/kanban-scrum-minibook/. Acesso em: 15 jan. 2020.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software.
Porto Alegre: Bookman, 2014.
SHIKOTA, R. A. Vamos falar sobre métricas Kanban? Let’ create the future, 2018. Disponível
em: http://www.matera.com/blog/post/vamos-falar-sobre-metricas-kanban. Acesso em: 20 jan.
2020.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. Um guia de�nitivo para o Scrum. As regras do
jogo. 2017. Disponível em: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-
Guide-Portuguese-Brazilian.pdf.  Acesso em: 15 jan. 2020.
SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Addison Wesley, 2019.
https://leankanban.com/guide/essential-kanban-condensed-portuguese/https://agilemanifesto.org/iso/ptbr/principles.html
http://fabiocruz.com.br/o-framework-scrum-na-visao-de-fabio-cruz-2/
http://wwwis.win.tue.nl/2R690/2019-2020_Q1/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf
https://www.infoq.com/br/minibooks/kanban-scrum-minibook/
http://www.matera.com/blog/post/vamos-falar-sobre-metricas-kanban
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf
20/04/2020 Roteiro de Estudos
https://fadergsead.blackboard.com/webapps/late-Course_Landing_Page_Course_100-BBLEARN/Controller 16/16
TELES, V. M. Um estudo de caso da adoção das práticas e valores do extreme
programming. 2005. Dissertação (Mestrado em Informática) – Núcleo de Computação
Eletrônica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005.Disponível em:
https://www.desenvolvimentoagil.com.br/xp/dissertacaoXP.pdf. Acesso em: 15 jan. 2020.
https://www.desenvolvimentoagil.com.br/xp/dissertacaoXP.pdf