AULA 2

GERENCIAMENTO DE ESCOPO,
RISCO E MUDANÇAS EM
PROJETOS ÁGEIS

Prof. Luciano Furtado C. Francisco

TEMA 1 – SCRUM

O início da década dos anos 2000 viu surgir o Manifesto Ágil, que foi uma
tentativa – bem-sucedida, é bom salientar – de conferir mais agilidade aos projetos
empresariais, sobretudo projetos de desenvolvimento e manutenção de software.
O Manifesto Ágil é um documento originado em uma reunião de diversos
profissionais de software, ocorrida em 2001 no estado norte-americano de Utah e
que é considerada um marco para as metodologias ágeis. Esses profissionais já
usavam metodologias ágeis como Scrum, eXtreme Programming (XP –
programação extrema), Feature Driven Development (FDD – desenvolvimento
orientado a requisitos), Dynamic System Development Model (DSDM – modelo
dinâmico de desenvolvimento de sistemas), Adaptative Software Development
(ADS – desenvolvimento de software adaptativo), entre outras técnicas. O
Manifesto surgiu em função de que essas metodologias – cada uma com suas
técnicas e características – reuniam princípios em comum, logo o Manifesto Ágil
é uma consolidação desses princípios.
Com o passar dos anos, o Scrum acabou se tornando a metodologia ágil
mais usada e não apenas em projetos de software, embora esse campo seja o
mais usual nas metodologias ágeis e para o próprio Scrum. Algumas razões
contribuíram para isso:

• Mostra-se eficiente na otimização das atividades dos projetos;

• É versátil, adapta-se com facilidade em muitas áreas, não somente àquelas
ligadas à tecnologia;
• É visível o aumento de eficiência em empresas que adotam o Scrum, o que
ocorre devido ao aumento de produtividade;
• A performance dos times de projeto aumenta em médio e longo prazo;
• Entregas são mais bem-sucedidas, com maior qualidade e com economia
de recursos.

Esses dados são ratificados pelo IGTI – Instituto de Gestão e Tecnologia

da Informação (entidade dedicada a pesquisas e estudos em T.I.), em pesquisa
de 2016, que mostra que 74% das empresas brasileiras que usam métodos ágeis,
o fazem por meio do Scrum.

2
Saiba mais

1. O nome Scrum se origina de uma das jogadas realizadas por um time no

jogo de rugby, em que o Scrum é uma formação utilizada para dar reinício ao jogo,
usando todos os jogadores, sendo, portanto, uma jogada essencialmente de
equipe, em que cada atleta tem um papel determinado, mas todos se ajudam para
o objetivo.
2. Leia no livro PMO ágil, de Fábio Cruz, a explicação sobre o Scrum, entre
as páginas 51 e 61.
CRUZ, F. PMO ágil – Escritório ágil de gerenciamento de projetos. Rio de
Janeiro: Brasport, 2016.
3. Acesse o link a seguir e assista a um vídeo com uma explicação do
especialista sobre o Scrum e suas vantagens:
SCRUM – Metodologia ágil: o que é e para que serve? Na Prática, 27 fev.
2019. Disponível em:
<https://www.youtube.com/watch?v=3jFhJXgURJw&feature=youtu.be>. Acesso
em: 3 dez. 2020.

1.1 Escopo no Scrum

Tal como qualquer metodologia de projetos, o Scrum também prevê

técnicas para tratar e gerenciar o escopo, tanto do projeto quanto do produto.
Embora as práticas do Scrum (escopo do projeto) possam ser adaptadas
em cada empresa (um dos princípios dos métodos ágeis), um dos seus
pressupostos é que o escopo do produto seja planejado e feito aos poucos. À
medida que novas informações sejam coletadas, novos requisitos se apresentam
ou mesmo novas estratégias são adotadas. O que foi produzido é testado,
entregue e colocado para funcionar. Em princípio, nenhum trabalho deve ser
perdido. Veremos adiante que a expressão em princípio faz todo o sentido aqui.
Não há um único responsável por formatar o escopo. Esse princípio
também segue a filosofia das metodologias ágeis. No entanto, existem diretrizes
e maneiras de registrar e gerenciar o escopo dentro de projetos Scrum.

1.2 Papéis no Scrum e suas relações com o escopo

Vamos entender, resumidamente, os papéis dentro de um projeto Scrum a

fim de entender o que eles têm a ver com o escopo.

3
1.2.1 Product owner (proprietário do produto)

Normalmente conhecido simplesmente por P.O., é o usuário do produto ou

quem o representa. Ele decide sobre as funcionalidades e requisitos e esclarece
as dúvidas sobre eles, sendo um construtor ou validador do backlog. Também é
o principal definidor das prioridades dos requisitos e mantém o time informado
sobre mudanças nesse aspecto. Por fim, aprova (ou rejeita) os requisitos
implementados.
Logo, em termos de escopo, é o seu principal definidor. Pode ser também
quem o registra, porém essa situação é mais rara nos projetos Scrum, ficando
essa tarefa de responsabilidade de outros integrantes do time.

1.2.2 Scrum master (mestre Scrum)

Trata-se de um facilitador para o time Scrum e um elo entre este e o P.O.

Não é alguém que tenha autoridade sobre a equipe nem um gerente de projetos
clássico, ele tem autoridade sobre os processos ágeis. Ele deve zelar pelos
princípios, práticas e valores ágeis. Procura adequar o Scrum ao projeto em
questão. Auxilia o time a superar barreiras que prejudiquem a produtividade. Por
exemplo, pode ser que o projeto necessite uma informação importante de outro
setor para poder prosseguir nas atividades, e essa informação, enquanto não for
conhecida, é um impedimento. Cabe ao Scrum master obter essa informação e
repassar ao time do projeto.
Em termos de escopo, ele identifica itens que possam alterar o andamento
do projeto, mudanças de requisitos, suas prioridades etc. Isso é feito pelo seu
contato com o P.O.

1.2.3 Time de desenvolvimento

Composto pelas pessoas que executam a construção dos requisitos,

normalmente são analistas de sistemas, de banco de dados, desenvolvedores,
analistas de projetos, analistas de testes e outros. Sua relação com o escopo é
principalmente de formatação, ou seja, transcrever os itens do backlog para os
artefatos previsto no Scrum, tais como sprints, estórias, dashboards etc.
No entanto, são os principais validadores e mantenedores de requisitos
técnicos.

4
Figura 1 – Time Scrum

Créditos: Ivector/Shutterstock.

TEMA 2 – ORGANIZAÇÃO DE ESCOPO – TEMAS E ÉPICOS

Ao se iniciar um projeto ágil, define-se principalmente o backlog do produto,

com suas prioridades, um nome e identificação sucintos. Nesse momento, ainda
não se tem uma ideia de como o desenvolvimento de cada item do backlog
efetivamente será feito, quanto tempo levará e, principalmente, se deverá ser
quebrado em entregas diversas.
Um bom indicativo para se saber o tamanho do requisito é a sua estimativa.
Normalmente aqueles itens de backlog com estimativas grandes são candidatas
a serem um épico.
Portanto um épico é um conjunto de trabalho que pode ser dividido em
pedaços menores (veremos adiante que esses pedaços são as sprints).
Por exemplo, um backlog de um projeto de um software de controle
financeiro pode conter os seguintes requisitos:

1. Controlar as entradas e saídas de dinheiro;

2. Gerar o fluxo de caixa;
3. Emitir os relatórios contábeis.

Você pode reparar que esses requisitos são bastante abrangentes. O

requisito “Emitir os relatórios contábeis” certamente se refere à emissão de
balanços, balancetes, demonstrativo de resultado de exercício etc. Desenvolver
todos eles em uma única sprint Scrum seria contraproducente, pois aí estaria se
fazendo o contrário dos métodos ágeis, construindo um grande módulo que
somente seria entregue completo e ao final de muito tempo.
Assim, esse requisito pode ser tratado como um épico e será dividido em
sprints, cada uma tratando de um pedaço do requisito. Por exemplo, na primeira
sprint seriam feitos os menus e as telas de interface desses relatórios; na

5
segunda, a geração do balancete; numa terceira, a geração do balanço e assim
por diante.
Para facilitar o entendimento do conceito de épico, pense nele como um
módulo, pois normalmente o sistema é dividido em módulos e estes agrupam
funcionalidades, que são disponíveis, em geral por interfaces gráficas.
Você também pode encontrar em projetos ágeis o termo tema de negócio.
Trata-se de uma divisão ainda acima do épico. Podemos dizer então que um tema
é um agrupamento de épicos (ou requisitos). Tudo depende de como o backlog
do produto é escrito. Como se recomenda que essa escrita seja não muito
detalhada, é normal extrairmos os temas e épicos do backlog.
Vamos usar como exemplo o software financeiro citado anteriormente.
Poderíamos ter um tema chamado controle de recursos, que agruparia os épicos
citados (controlar as entradas e saídas de dinheiro; gerar o fluxo de caixa; emitir
os relatórios contábeis)
O agrupamento de épicos em temas não é obrigatório (nas metodologias
ágeis, obrigatório é apenas seguir seus princípios e valores), no entanto dá uma
visão melhor de como deve ser a estrutura do produto, por isso é recomendável
sempre que possível

Figura 2 – Scrum

Créditos: Joreks/Shutterstock.

TEMA 3 – ORGANIZAÇÃO DE ESCOPO – SPRINTS

Você deve ter percebido que alguns termos das metodologias ágeis provêm
do esporte (Scrum, por exemplo, é uma jogada do rugby). Agora veremos mais
um desses termos, que é emprestado do atletismo: sprint.

6
 O termo sprint em inglês significa arrancada. No atletismo, refere-se aos
momentos finais das corridas de fundo e meio fundo (800 m ou mais), nos quais
os corredores aumentam bastante a velocidade de modo que os adversários não
consigam ultrapassá-los.
Segundo Sbrocco e Macedo (2012, p. 164), “sprint representa a unidade
básica de desenvolvimento do Scrum, entendida como um esforço dentro de uma
‘caixa de tempo’; em outras palavras, um esforço restrito a uma duração
específica”.
Os projetos que usam o scrum acontecem por meio de sprints sequenciais,
as chamadas iterações. Cada sprint deve gerar um entregável para o cliente, que
tenha valor. Em cada sprint são desenvolvidos um ou mais requisitos contidos no
backlog e, assim, quando todas as sprints previstas são finalizadas e entregues,
o produto todo está entregue.
Recomenda-se que uma sprint dure entre duas e quatro semanas. Isso
porque não é um tempo tão curto, de modo que o time produza pouco, nem um
período tão longo no qual o cliente tenha de ficar esperando muito tempo por uma
entrega de valor. Contudo, como ditam os princípios das metodologias ágeis, cada
empresa e cada projeto devem definir qual o tempo necessário de cada sprint.
Também é possível que num mesmo projeto haja sprints com tempos diferentes.
Como o scrum é organizado em cerimônias, uma sprint também tem as
suas, algo que deve ser seguido pelo time e coordenado pelo Scrum master. E
nessas cerimônias, o escopo é bastante abordado e gerenciado, como veremos
na sequência.

3.1 Planejamento das sprints - Divisão do backlog

Depois do P. O. ter definido, em conjunto com o restante do time, o backlog

organizado em temas e épicos, chega o momento de se fazer a lista de sprints
que vai organizar a construção do produto. Também deve ser planejada com o
time e o cliente.
Basicamente temos que o backlog é dividido da seguinte forma, como
mostra a Figura 3:

7
Figura 3 – Relação backlog x sprints

Fonte: Kniberg, 2007, p. 22.

Em geral, essa divisão é registrada em uma planilha ou software de

controle de projetos. O mais importante é que esse registro seja feito e
acompanhado ao longo do projeto. Aqui temos mais um elemento de
gerenciamento do escopo, e todos os integrantes do time devem ter acesso a esse
quadro.
Perceba que uma sprint, ela mesma tem seu backlog e pode abranger um
ou mais itens do backlog do produto. A ordem das sprints também deve ser objeto
de consenso antes de se iniciar o projeto. Em termos de gerenciamento do
escopo, o ideal é que apenas o P.O. e, excepcionalmente, o Scrum master façam
alterações nessa ordem. Evidentemente, sempre que houver qualquer alteração,
o time deve ser previamente comunicado.
Uma vez definido quantas sprints o projeto terá, chega o momento de iniciar
sua execução e aí entram as estórias de usuário, uma divisão das sprints.
Conforme Sbrocco e Macedo (2012, p. 163), “ao final de cada sprint um
incremento do produto deve ser apresentado ao cliente para que o time obtenha
uma retroalimentação. Caso algum defeito seja encontrado, deve ser adicionado
ao backlog do produto”. É um ciclo, que os autores expressam na Figura 4:

8
Figura 4 – Visão geral da dinâmica da metodologia Scrum

Fonte: Sbrocco e Macedo (2012, p. 163, citado por Cohen, 2008.

TEMA 4 – ORGANIZAÇÃO DE ESCOPO – ESTÓRIAS DE USUÁRIO

Uma sprint no Scrum é dividida em estórias. Sim, isso mesmo, com e, uma
convenção do Scrum, devido ao fato de que vem da palavra story em inglês (e
não history). Outros a chamam pelo seu nome em inglês, user stories. Podemos
dizer que as estórias são o backlog da Sprint.
Seja qual for a forma de chamar as estórias, fato é que elas orientam o
trabalho do time e é mais um dos itens em que o escopo se concretiza e é
gerenciado.
É conveniente, para registro do projeto, portanto, o registro do escopo e
que se tenha um mapa das estórias. De acordo com Massari (2018, p. 58):

Um mapa de user stories é bastante similar ao roadmap do produto [...],

mas lista as user stories na linha do tempo, e não as funcionalidades.
Utiliza os mesmos conceitos do roadmap do produto para classificar user
stories mandatórias para o funcionamento do produto (espinha dorsal) e
user stories essenciais para tornar o produto operacional (esqueleto).

O autor demonstra graficamente como seria esse mapa, conforme a Figura

5:

9
Figura 5 – Mapa de user stories

Fonte: Massari, 2018, p. 54.

Como registrar essas estórias e trabalhar com elas no scrum? Veremos na

sequência.

4.1 Escrevendo as estórias

A recomendação é que as estórias sejam escritas de modo simples e

compreensível por qualquer pessoa, mesmo as leigas no assunto ou no projeto.
Isto é, nenhum termo técnico tão específico deve ser usado (ou ao menos deve
evitar-se ao máximo) na escrita das estórias. Isso porque devemos lembrar que
em geral o P. O. é alguém leigo em assuntos técnicos. Normalmente é quem vai
usar o produto tão somente.
De modo que as estórias, vindas de itens do backlog, devem representar
as necessidades dos usuários.
Logo, qual seria um formato interessante para escrever estórias? No
Scrum, é amplamente utilizado o formato de enunciado – critérios de aceitação.
Veja um exemplo a seguir:
Enunciado
Eu, como analista financeiro, desejo ter uma tela onde eu possa cadastrar
todos os dados de uma conta a pagar, de modo que agilize minha atividade diária
de gestão de contas.

10
 Critérios de aceitação

1. Deve haver um item no menu principal do sistema chamado “Contas a

Pagar”, ao clicar nesse item, a tela deve ser aberta. Um protótipo desta tela
está em local;
2. Na tela aberta, o usuário deverá selecionar um fornecedor pelo seu CPF ou
parte de seu nome ou razão social;
2.1 Caso digite um CPF ou nome/razão social inexistente no cadastro de
fornecedores, deverá ter a opção de cadastrar o fornecedor, indo à tela de
cadastro de fornecedores e retornando com o fornecedor cadastrado;
2.2 Caso procure pelo nome, o sistema deverá exibir os nomes/razões sociais
que correspondam o nome digitado e o usuário deverá selecionar o
fornecedor em questão;
2.3. Caso digite um CPF inválido, deverá ser exibida mensagem de erro
indicativa.
3. O usuário poderá cadastrar os dados da conta a pagar, conforme protótipo
de tela existente no local, onde também estão descritas as validações dos
campos;
4. Não poderá ser cadastrada uma conta a pagar com data anterior à data da
operação;
5. Não poderá ser cadastrada uma conta a pagar com valor zero ou menor.

Nesse ponto, peço que você atente para algumas coisas:

• O formato de escrita da estória segue um padrão: Eu, como [ATOR]

quero/preciso/gostaria de [AÇÃO] para que [OBJETIVO];
• O ator é como se fosse um dono da estória, aquele que vai usar esse
requisito (funcionalidade). Aqui cabe salientar que não necessariamente
precisa ser uma pessoa. Poderia ser, por exemplo, um departamento;
• O objetivo é aquilo que o ator espera que ocorra, o benefício que ele terá
com a implementação do requisito; é algo opcional; pode ter mais de um
objetivo, contudo não mais do que dois, pois se houver muitos objetivos é
um indicativo de que a estória poderia ser quebrada em mais estórias.

Finalmente, é importante dizer que as estórias são elementos importantes

do escopo do produto. Isso porque elas detalham um pouco mais o backlog, que
é mais genérico por natureza.

11
 Mas perceba que, depois do enunciado, a estória traz ainda mais um
elemento, os critérios de aceitação, que veremos a seguir.

4.1.1 Critérios de aceitação

Convido você a ler novamente o enunciado da estória de exemplo do item

anterior. Convenhamos que apenas o enunciado seria insuficiente para que os
desenvolvedores soubessem com exatidão o que o P. O. deseja com a estória,
não é mesmo?
Sendo assim, é conveniente que a estória tenha um nível de detalhamento
ainda mais alto. Esse nível é representado pelos critérios de aceitação. No
exemplo do item anterior, temos os critérios da estória, num total de cinco.
Observe que com os critérios já se tem uma ideia muito mais clara do que deve
ser construído e quais as regras de negócio principais a serem observadas.
Trata-se, portanto, de uma lista de critérios que precisam ser atingidos, a
fim de que a estória atenda aos requisitos do P. O. para aquela funcionalidade. É
importante mencionar aqui que o P. O. em reuniões de entrega (adiante veremos
as cerimônias) precisa verificar um a um desses critérios para considerar a estória
como aceita. Qualquer critério não atendido deve retornar para correções e
ajustes necessários. Critérios de aceitação possuem informações
complementares, que, se fossem inseridas no enunciado, o deixariam extenso
demais.
Os critérios de aceitação têm por finalidade:

• Definir os limites de uma estória (o que fazer e o que não fazer);

• Auxiliar o P. O. no detalhamento de maior nível, do que é preciso para
entregar valor ao cliente;
• Proporcionar ao time de desenvolvimento uma compreensão maior da
estória;
• Ajudar na programação dos testes.

Um bom critério de aceitação deve, além de detalhar em menor nível o

enunciado, ser independente de implementações, informando o que fazer e não
como fazer.
Outra observação: veja que, no exemplo dos critérios anteriores, existe um
trecho [local] em momentos em que o critério aborda telas, campos, validações
etc. Nos projetos ágeis, é comum que exista um local – pasta de rede, por exemplo

12
– nos quais artefatos visuais estejam descritos. Dessa forma, os critérios não
ficam tão extensos.
Contudo, o como fazer também deve constar do projeto. Isso é feito por
meio das tarefas de uma estória. Vejamos na sequência.

4.2 Tarefas

Se repararmos como as estórias são escritas, vamos concluir que ela está
na linguagem do P. O., do cliente ou de um usuário, tão somente. Tanto que
qualquer pessoa consegue compreender o que ali está descrito, seja no
enunciado ou nos critérios de aceitação.
Já as tarefas é que especificam como as estórias serão implementadas.
Aqui entram aspectos técnicos, os quais o P. O., o cliente ou o usuário não
precisam saber. Fazem sentido para o time de desenvolvimento.
Quando uma estória é apresentada ao time, a atividade seguinte vai ser a
de escrever essas tarefas, que em geral são escritas em post-its, que depois serão
afixados em um quadro estilo kanban. Essa definição de tarefas da estória é feita
pelos integrantes do time técnico.

Saiba mais

Acesse o link a seguir e veja como funciona um quadro kanban em projetos

que usam o Scrum:
APRENDA Kanban em 9 minutos (desenvolvimento ágil de software).
Canal TI, 5 dez. 2017. Disponível em:
<https://www.youtube.com/watch?v=WjZBnYa58B4&feature=youtu.be>. Acesso
em: 4 dez. 2020.
Vamos usar o exemplo da estória do item anterior. Dessa maneira,
teríamos as seguintes tarefas:

• Implementar interface;
• Criar banco de dados;
• Escrever rotina de inclusão e validação de conta;
• Aplicar testes unitários;
• Entre outras.

13
 E quem deve fazer cada tarefa? Em geral, os times de desenvolvimento já
têm tacitamente acertado quem faz cada tarefa, porém as técnicas ágeis
preconizam que qualquer integrante, em tese, pode fazer qualquer tarefa.

TEMA 5 – CERIMÔNIAS SCRUM E SEUS IMPACTOS NO ESCOPO

Um projeto Scrum é executado não apenas por meio das tarefas, mas
também pelas chamadas cerimônias. Trata-se de eventos que devem acontecer
em períodos predeterminados, dentro de uma sprint. Vamos entender quais são
essas cerimônias e como elas impactam no escopo ágil.

Figura 6 – Quadro de tarefas (kanban)

Fonte: Cruz, 2016, p. 58.

5.1 Reuniões de planejamento

São reuniões que ocorrem no primeiro dia da sprint e têm as seguintes

funções:

• Apresentar a sprint e suas estórias ao time;

• Definir as tarefas das estórias e sua estimativa de duração (feito pelo time
de desenvolvimento);
• Negociar com o P.O. a alteração de ordem das sprints ou supressão de
estórias, caso o tempo estimado de todas as tarefas de todas as estórias
não sejam suficientes para o tempo da sprint

14
 Em geral, essas reuniões duram o dia todo, sendo a primeira (ou as duas
primeiras) dedicadas à apresentação da sprint, cerca de quatro ou cinco horas
para o planejamento do time e cerca de uma hora para a apresentação do time
sobre as estimativas e eventuais negociações. Caso uma ou mais estórias não
caibam no tempo da Sprint, normalmente passam para a sprint prevista seguinte,
o que cria um impacto no escopo do projeto.
Quanto ao escopo, o planejamento pode impactar em alteração na ordem
ou prioridade de requisitos, devido a fatores levantados pelo time de
desenvolvimento. Isso é comum em projetos ágeis. Portanto, o escopo deve ser
alterado quando isso ocorrer.

5.2 Reunião diária

Evento conhecido também como daily meeting (literalmente, reunião

diária). É realizada pelo time de desenvolvimento e, em casos excepcionais, conta
com a participação do P. O., em situações em que surge alguma questão que
precise de sua intervenção.
A prática ágil recomenda que essa reunião seja feita todos os dias em um
horário pré-determinado, dure no máximo 15 minutos e seja feita em pé. O objetivo
da daily é que cada integrante do time informe qual(s) tarefa(s) fará durante o dia
e qual(s) fez no dia anterior. Logo, uma boa recomendação é que a reunião seja
feita diante do quadro kanban, pois assim os post-its podem ser movidos entre as
colunas (a fazer -> fazendo -> feito).
Em termos de escopo, há pouco impacto, exceto se durante a execução
das tarefas o time detecte alguma questão mais complexa, que justifique
alterações no escopo.

5.3 Reunião de apresentação/Revisão

Cerimônia que ocorre ao final do último da sprint, normalmente no final do

dia. Nesse evento, o time apresenta ao P. O. – e eventuais outros interessados –
o resultado do desenvolvimento da sprint.
Os critérios de aceitação de cada estória são verificados. Caso o P. O.
aceite todos os critérios, a estória será aceita. Já se algum critério não for aceito,
o time deverá proceder ajustes e correções eventuais. Isso é particularmente

15
possível em projetos ágeis, dada a natureza mais genérica da descrição e
detalhamento de backlog, sprints, estórias e tarefas.
Assim, uma providência salutar em projetos Scrum de tecnologia (software,
sobretudo) é que essa reunião seja feita em quintas-feiras, porque assim a sexta-
feira seria usada apenas para tais correções e ajustes. Caso esses não existam,
esse dia é utilizado para ações de implantação em produção do que foi construído.

5.4 Reunião de retrospectiva

Também chamada de review, trata-se de uma reunião de cerca de uma

hora, na qual o time discute:

• Como foram os trabalhos na Sprint;

• Pontos negativos;
• Pontos positivos.

Tudo isso em relação às pessoas, processos, ferramentas etc. Tudo deve

ser anotado. Normalmente cada integrante anota pontos negativos em um post-it
vermelho e os positivos em azuis. Isso serve como subsídio para as próximas
sprints, porque os pontos positivos devem ser aprimorados e seguidos e os
negativos devem ter ações que os eliminem, alterem ou os neutralizem.
Isso leva a um amadurecimento contínuo dos times de projetos em relação
às metodologias ágeis.

16
REFERÊNCIAS

CRUZ, F. PMO ágil – Escritório ágil de gerenciamento de projetos. Rio de Janeiro:

Brasport, 2016.

KNIBERG, H. Scrum e XP direto das trincheiras. InfoQ, S.d. Disponível em:

<https://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches/>. Acesso em:
4 dez. 2020.

MASSARI, V. L. Gerenciamento ágil de projetos. 2. ed. Rio de Janeiro: Brasport,

2018.

SBROCCO, J. H. T. C.; MACEDO, P. C. Metodologias ágeis – Engenharia de

software sob medida. São Paulo: Érica, 2012.

17