Aula 1 a 16 Exercicios

Prévia do material em texto

Sumário 
 
AULA 1 EXERCÍCIO – CONCEITOS DA ENGENHARIA DE SOFTWARE ------------------------------ 2 
AULA 2 EXERCÍCIO – CONHECER AS FASES DO CICLO DE VIDA DE SOFTWARE ----------- 7 
AULA 3 EXERCÍCIO – CONHECER OS MODELOS TRADICIONAIS ----------------------------------- 12 
AULA 4 EXERCÍCIO – CONHECER MODELO INCREMENTAL ------------------------------------------- 17 
AULA 5 EXERCÍCIO – MODELOS TRADICIONAIS X MÉTODOS ÁGEIS ---------------------------- 22 
AULA 6 EXERCÍCIO – ANALISAR E DESENVOLVER PLANO DE PROJETO --------------------- 27 
AULA 7 EXERCÍCIO – MÉTODOS ÁGEIS -------------------------------------------------------------------------- 33 
AULA 8 EXERCÍCIO – ESPECIFICAÇÃO DE REQUISITOS FUNCIONAIS UTILIZANDO 
HISTÓRIAS DE USUÁRIO ------------------------------------------------------------------------------------------------- 41 
AULA 9 EXERCÍCIO – INTRODUÇÃO AO MÉTODO SCRUM --------------------------------------------- 49 
AULA 10 EXERCÍCIO – A EQUIPE E A SUA ESTRUTURA EM SCRUM ------------------------------ 55 
AULA 11 EXERCÍCIO – LIDERANÇA DE EQUIPE EM SCRUM ------------------------------------------- 62 
AULA 12 EXERCÍCIO – INTRODUÇÃO AO MÉTODO XP --------------------------------------------------- 70 
AULA 13 EXERCÍCIO – MÉTODO XP E SUAS PRÁTICAS ------------------------------------------------- 78 
AULA 14 EXERCÍCIO – MÉTRICAS DE SOFTWARE ---------------------------------------------------------- 88 
AULA 15 EXERCÍCIO – MÉTRICAS PARA GERENCIAMENTO DE PROJETOS E CÓDIGO-
FONTE ------------------------------------------------------------------------------------------------------------------------------ 93 
AULA 16 EXERCÍCIO – MANUTENÇÃO DE SOFTWARE --------------------------------------------------- 98 
 
 
Aula 1 Exercício – Conceitos da engenharia de software 
1. O que foi a Crise de Software? 
 
A. A Crise de Software permitiu o desenvolvimento de software de alta qualidade já que 
houve um aumento da concorrência. 
 
A Crise de Software não permitiu o desenvolvimento de software de alta qualidade. Ela 
representa um conjunto de problemas que ocorreram devido à baixa qualidade 
de software e problemas no processo de desenvolvimento. 
 
 
Resposta Certa B. A Crise de Software foi um termo que surgiu nos anos 70. O termo 
expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento 
da demanda por software. 
 
No Início dos anos 70, quando vivia-se a terceira era do software, houveram muitos 
problemas de prazo e custo no desenvolvimento de software, devido à baixa 
produtividade, baixa qualidade e difícil manutenção do software. 
 
 
C. A Crise de Software foi acompanhada pela Crise de Hardware, que acabou gerando 
inúmeros desempregos na década de 70. 
 
A Crise de Hardware não existiu. Na verdade, a Crise de Software expressou dificuldades 
do desenvolvimento de software que gerava baixa produtividade, baixa qualidade e difícil 
manutenção dos sistemas produzidos. 
 
 
D. A Crise de Software foi um termo criado para expressar momentos em que um sistema 
apresenta processamento lento. 
 
Embora a falta do uso de metodologias adequadas possam deixar um software lento, a 
Crise de Software foi criada para expressar um momento onde a criação de software não 
utilizavam métodos sistemáticos que ajudavam a manter a qualidade dos sistemas. 
 
 
E. A Crise de Software ocorreu após a Segunda Guerra Mundial quando 
nenhum software era vendido. 
 
O termo "Crise de Software" foi criado na década de 70, juntamente com a necessidade 
de uso de novas metodologias sistemáticas obtidas após a criação da Engenharia 
de Software. 
 
 
2. Qual foi o motivo da criação da Engenharia de Software? 
 
A. A Engenharia de Software foi criada porque nenhum software disponível antes da 
Engenharia de Software conseguia realizar cálculos complexos. 
 
Antes da criação da Engenharia de Software existiam softwares muito complexos e que 
conseguiam realizar cálculos complexos. No entanto, eram construídos sem uma 
metodologia adequada. 
 
 
Resposta Certa B. A Engenharia de Software foi criada para permitir o uso de elementos 
da engenharia de forma controlada e sistemática no desenvolvimento de software. 
Também para evitar a Crise de Software. 
 
A Engenharia de Software permitiu o uso de elementos da engenharia que eram 
amplamente utilizados em outras áreas, tornando a criação de software mais controlada, 
sistemática e padronizada. 
 
 
C. A Engenharia de Software foi criada para acelerar o desenvolvimento de software no 
Brasil. 
 
Embora a Engenharia de Software seja uma área muito forte, hoje, no Brasil, ela também é 
utilizada em todo o mundo. 
 
 
D. A Engenharia de Software foi criada para facilitar o uso de software. 
 
Este não foi o motivo pelo qual foram introduzidos elementos da engenharia na criação de 
software, embora a facilidade de uso seja uma consequência de um bom planejamento e 
modelagem de software. 
 
 
E. A Engenharia de Software foi criada para permitir que a produção de novos sistemas 
tivesse mais elementos gráficos e amigáveis ao usuário. 
 
A criação da Engenharia de Software não foi motivada pela utilização de elementos gráficos e 
melhores interfaces, mas sim pela necessidade de evitar a Crise de Software. 
 
 
3. Com a introdução da Engenharia de Software, o que mudou no processo de 
desenvolvimento de software? 
 
Resposta Certa A. Iniciou-se o uso de técnicas e metodologias sistemáticas e controladas 
já presentes na engenharia e amplamente utilizadas em outras áreas. 
 
Com a Crise de Software, foi proposta a Engenharia de Software para tornar a criação 
de Software mais sistematizada e controlada. 
 
 
B. A Engenharia de Software melhorou o entendimento do desenvolvedor na leitura dos 
requisitos de Software. 
 
A Engenharia de Software utilizou elementos da engenharia no processo de criação 
de software. A identificação dos requisitos de software é apenas uma etapa do ciclo de 
criação de software. 
 
 
C. Aumentaram as vendas de sistemas de software na década de 80. 
 
A Engenharia de Software incluiu elementos da engenharia no processo de 
desenvolvimento de software. 
 
 
D. Permitiu que mais pessoas pudessem ter acesso a sistemas de software. 
 
Embora a demanda estivesse aumentando durante a criação da Engenharia 
de Software, essa não foi uma ocorrência direta. 
 
 
E. Removeu da criação de software as técnicas e metodologias sistemáticas e controladas 
já presentes na engenharia e amplamente utilizadas em outras áreas. 
 
A Engenharia de Software incluiu técnicas e metodologias sistemáticas e controladas já 
presentes na engenharia e amplamente utilizadas em outras áreas. 
 
 
4. João, dono de uma empresa de software, tem que criar um sistema para um cliente. Até 
o momento, o cliente fez apenas uma ligação informando o tipo de software que ele quer. 
Qual a primeira coisa que João deve fazer? 
 
A. Ir para a sua empresa e começar a programar imediatamente. 
 
João ainda não sabe quais as necessidades do cliente e como o software deve ser 
criado. 
 
 
B. Modelar algumas telas do sistema e perguntar ao cliente a sua opinião. 
 
Embora seja importante criar um protótipo e mostrar ao cliente antes de implementar, 
nesse momento João ainda não teria informações suficientes para fazer algo. 
 
C. Contratar uma grande equipe de desenvolvedores para criar o software o mais rápido 
possível. 
 
João ainda não sabe o tamanho do sistema que terá que criar, então contratar 
desenvolvedores sem antes planejar seria um erro muito grande. 
 
 
Resposta Certa D. Entender o negócio do cliente e realizar reuniões para mensurar o que 
ele precisa. 
 
João deve entender o que o cliente precisa, como vai fornecer, o negócio do cliente e 
fazer uma análise dessas necessidades, conseguindo, então, estipular prazos e custos 
de acordo com as metodologias da Engenharia de Software. 
 
E. Informar para o cliente que em um mês o sistema estará em pleno funcionamento, além 
de informar qual seráo custo do sistema. 
 
João não poderia informar prazos e custos sem ao menos ter mais informações das 
necessidades do cliente. 
 
 
5. Qual é a base dos elementos da Engenharia de Software? 
 
 
A. Métodos. 
 
Os métodos envolvem tarefas como: comunicação, análise, modelagem, construção, 
testes e suporte. Não é a base das camadas, mas é a 3º camada. 
 
B. Ferramentas. 
 
Quando as ferramentas são interligadas temos um sistema que suporta o 
desenvolvimento de software. Não é a base das camadas, mas é a 4º camada. 
 
Resposta Certa! 
 C. Foco na qualidade. 
 
Foco na qualidade é a base das camadas da Engenharia de Software. Ele serve para 
promover uma cultura de aperfeiçoamento contínuo de processos. 
 
D. Processo. 
 
Eles servem para definir uma metodologia que deve ser estabelecida, visando ter uma 
entrega efetiva. Não é a base das camadas, mas é a 2º camada. 
 
E. Conceitual. 
 
Esta não é uma camada da Engenharia de Software. 
 
 
Aula 2 Exercício – Conhecer as fases do ciclo de vida de software 
 
1. O que é um ciclo de vida de software? 
 
Resposta Certa! 
A. Ciclo de vida de software refere-se aos estágios de concepção, projeto, criação e 
implementação de um software. 
 
O ciclo de vida de software é muito importante e deve ser devidamente analisado no 
início da criação do sistema. 
 
 
B. Ciclo de vida de software refere-se aos estágios de levantamento de requisitos. 
 
O Ciclo de vida de software engloba mais partes do processo, além do levantamento. 
 
 
C. Ciclo de vida de software refere-se ao tempo de implementação estimado pelo analista. 
 
O ciclo de vida de software possui uma maior abrangência, não se limitando ao 
desenvolvimento (implementação). 
 
 
D. Ciclo de vida de software refere-se aos estágios de análise do software. 
 
Embora o ciclo de vida de software tenha um momento dedicado para a análise, ele não 
se limita a este aspecto. 
 
 
E. Ciclo de vida de software ocorreu antes da Crise do Software, em 1970. 
 
O ciclo de vida de software foi utilizado dentro da Engenharia de Software para 
obter software de melhor qualidade, portanto não é um acontecimento datado e sim um 
processo. 
 
 
2. Em qual fase do ciclo de vida de software são definidas as questões técnicas, como 
banco de dados, localização, hardware e linguagens de programação? 
 
 
Resposta Certa A. Na fase de projeto. 
 
Projeto trata da construção das especificações detalhadas para o projeto selecionado. 
 
 
B. Na fase de levantamento de requisitos. 
 
O Ciclo de vida de software engloba mais partes do processo, além do levantamento. 
 
 
C. Na fase de implementação. 
 
O ciclo de vida de software possui uma maior abrangência, não se limitando ao 
desenvolvimento (implementação). 
 
 
D. Na fase de testes e manutenção. 
 
Embora o ciclo de vida de software tenha um momento dedicado para a análise, ele não 
se limita a este aspecto. 
 
 
E. Em nenhuma fase, estas questões são decididas pelo programador. 
 
O ciclo de vida de software foi utilizado dentro da Engenharia de Software para 
obter software de melhor qualidade, portanto não é um acontecimento datado e sim um 
processo. 
 
 
 
3. No ciclo de vida de software, o que é realizado na etapa de "levantamento das 
necessidades"? 
 
A. É realizada a implementação do sistema. 
 
A implementação é realizada após a etapa de projeto. 
 
 
Resposta Certa B. É realizada uma verificação de todas as necessidades do cliente. 
 
Essa etapa identifica as necessidades de informações da organização. 
 
 
C. É realizada a análise de requisitos. 
 
Essa etapa é realizada somente após o levantamento de necessidades. 
 
 
D. São realizados testes no sistema para verificar quais as necessidades de 
implementação. 
 
Em modelos clássicos, os testes são realizados após a etapa de implementação do sistema. 
 
 
E. É a etapa onde o sistema é entregue para o usuário/cliente. 
 
Ao contrário da entrega do software, o levantamento de necessidades é realizado logo no início 
do desenvolvimento do sistema. 
 
4. A figura ilustra um modelo de desenvolvimento de software no qual o fluxo é visto como 
um fluir constante através das fases. Esse modelo utiliza como entrada as informações 
obtidas nas fases anteriores e cada fase só inicia após o término da que antecede (não 
existindo fases em paralelo). Com base nessas informações, qual é o modelo apresentado 
na figura? 
 
 
A. Modelo V. 
 
O Modelo V virou um padrão da indústria de software depois de 1980 e, após o 
surgimento da Engenharia de Sistemas, tornou-se um conceito padrão em todos os 
domínios da indústria. Foi baseado no modelo descrito, porém a principal diferença é a 
integração entre as etapas. 
 
 
Resposta Certa B. Cascata. 
 
O modelo clássico ou cascata, que também é conhecido por abordagem "top-down", foi 
proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com 
aceitação geral. 
 
 
C. Espiral. 
 
A abordagem em espiral implementa os sistemas baseado no conceito de maior 
necessidade. Ela entrega o sistema em versões. O fluxo que esse modelo propõe é em 
formato de espiral. 
 
 
D. Prototipagem. 
 
O modelo de prototipagem descreve uma abordagem que tenta satisfazer as 
necessidades do usuário focalizando a interface do usuário. É diferente do modelo 
descrito, onde só existe implementação e entrega ao final do projeto. 
 
 
E. Incremental. 
 
undefined 
 
 
5. Qual é o maior problema encontrado no modelo cascata? 
 
A. Nenhum. O sistema cascata foi utilizado durante anos e até o momento não precisou 
de correções. 
 
O ciclo de vida em V foi proposto como a forma de corrigir os problemas de reatividade 
do modelo cascata. 
 
 
B. É um modelo bastante simples. 
 
Devido a sua simplicidade, ele facilita a estimativa de custo e tempo para o cliente. 
 
 
C. O sistema prevê a revisão das fases e é totalmente iterativo. 
 
Ao contrário, o sistema não prevê a revisão das fases, e isso o torna um sistema com 
problema. Por exemplo, se um requisito de software foi observado e levantado de forma 
incorreta, o erro se propagará até a implementação. Ou seja, a fase de levantamento das 
necessidades não é revista para corrigir possíveis problemas que podem ocorrer, ao 
contrário do ciclo de vida em V. 
 
Resposta Certa! 
D. Apresenta o problema de reatividade a mudanças. 
 
Não oferece oportunidades claras para entregas parciais de um sistema ou para a 
introdução de mudanças dentro do ciclo de vida. Apresenta o problema de reatividade a 
mudanças. 
 
 
E. O modelo cascata é top-down e isso faz com que o software seja construído de maneira 
incorreta. 
 
Ser um modelo top-down é apenas uma característica do modelo e não pode ser 
considerado um problema. 
 
Aula 3 Exercício – Conhecer os modelos tradicionais 
 
1. Qual o maior problema encontrado no modelo cascata? 
 
Resposta Certa! 
A. Dificuldade em detectar alterações e melhorias durante o desenvolvimento. 
 
Como o projeto segue uma forma linear, não existe feedback do usuário durante o 
desenvolvimento. Assim, só serão detectados problemas no final, após a entrega. 
 
 
B. Dificuldade em criar um protótipo. 
 
O uso de protótipo foi inserido apenas após a proposta do modelo prototipação. 
 
 
C. Alto custo de desenvolvimento. 
 
Como é um modelo mais simplificado e linear, o custo de desenvolvimento é reduzido se 
comparado com outros modelos tradicionais. Porém, mudanças posteriores podem ser 
mais custosas. 
 
 
D. Dificuldade de gerenciamento do projeto. 
 
O modelo cascata, devido a sua simplicidade, permite um gerenciamento mais simples 
quando comparado com outros modelos tradicionais. Porém, não prevê monitoramento, 
controle de mudanças ou replanejamento. 
 
 
E. Pouca documentação do produto. 
 
O modelo cascata foi projetado de uma forma que a documentação obtida ao final do 
projeto fosse suficiente. Além disso, cada etapa só inicia se a etapa anterior houver 
finalizado toda a documentação. 
 
 
2. O que o modelo prototipaçãotentou corrigir nos modelos anteriores? 
 
A. Falta de linearidade dos modelos anteriores. 
 
O modelo cascata foi desenvolvido totalmente linear. 
 
Resposta Certa! 
B. O problema de comunicação entre os usuários e os desenvolvedores. 
 
O uso de protótipo foi inserido apenas após a proposta do modelo prototipação. 
 
 
C. A falta de reúso de software. 
 
Como é um modelo mais simplificado e linear, o custo de desenvolvimento é reduzido se 
comparado com outros modelos tradicionais. Porém, mudanças posteriores podem ser mais 
custosas. 
 
 
D. A complexidade de criar software sem o uso de um modelo. 
 
O modelo cascata, devido a sua simplicidade, permite um gerenciamento mais simples quando 
comparado com outros modelos tradicionais. Porém, não prevê monitoramento, controle de 
mudanças ou replanejamento. 
 
 
E. Os testes eram realizados antes da implementação, então o modelo modificou a ordem. 
 
O modelo cascata foi projetado de uma forma que a documentação obtida ao final do projeto 
fosse suficiente. Além disso, cada etapa só inicia se a etapa anterior houver finalizado toda a 
documentação. 
 
3. Quais são as desvantagens do uso de um modelo prototipação? 
 
A. Dificuldade de comunicação com o usuário. 
 
O modelo busca justamente obter uma comunicação melhor com o usuário para atender às 
expectativas. 
 
 
B. Muita documentação. 
 
Uma das características do modelo prototipação é a baixa documentação. 
 
Resposta Certa! 
C. Alto custo de projeto e retrabalho. 
 
Devido à necessidade de diversas reuniões, implementação de protótipos, modificações e 
evolução, o modelo apresenta alto custo e também a necessidade de retrabalho. A maior parte 
do custos e concentra na fase de análise para compreensão e validação de requisitos. 
 
 
D. Ao final do projeto, os usuários geralmente não gostam do sistema. 
 
Com o uso dos protótipos, os usuários já saberão inicialmente como o sistema será e poderão 
solicitar alterações antes mesmo do desenvolvimento. 
 
 
E. O resultado geralmente é um sistema difícil de usar. 
 
Como o usuário terá contato desde o início do projeto com o sistema, ao final ele terá um sistema 
produtivo e que corresponda às expectativas. 
 
4. O modelo espiral combinou dois modelos, o cascata e o protótipo. Além disso, ele 
adicionou mais um elemento que forneceu mais segurança na criação de software. Qual 
elemento foi este? 
 
A. Criação de documentação. 
 
A criação de documentação já era prevista nos modelos anteriores. 
 
 
B. Análise de requisitos. 
 
A análise de requisitos já estava presente nos modelos anteriores. 
 
 
C. Testes de software. 
 
Os testes de software já estavam presentes nos modelos anteriores. 
 
 
D. Protótipo de software. 
 
O protótipo de software foi introduzido pelo modelo de prototipação. 
 
Resposta Certa! 
 E. Análise de risco. 
 
 
 
5. Qual a diferença do protótipo descartável e do evolutivo no modelo prototipação? 
 
Resposta Certa! 
A. O protótipo descartável é criado temporariamente e depois não é mais utilizado. Já o 
evolutivo utiliza o próprio sistema como protótipo e, ao longo do tempo, evolui até chegar 
no produto final. 
 
O modelo prototipação utiliza estes dois tipos de protótipo, sendo avaliado qual o 
melhor conforme características de cada projeto. 
 
 
B. O protótipo descartável utiliza o próprio sistema como protótipo e, ao longo do tempo, 
evolui até chegar no produto final. Já o evolutivo é criado temporariamente e depois não 
é mais utilizado. 
 
Estas definições não se encaixam com os respectivos modelos de protótipos. 
 
 
C. Nenhuma, os dois representam a mesma coisa. 
 
Existe uma diferença entre os dois tipos de protótipos e diferenciá-los é essencial para decidir 
qual opção é melhor para determinado projeto. 
 
 
D. Um deles depende da análise de risco para ser utilizado. 
 
A análise de risco não está presente no modelo prototipação. Ela foi introduzida no modelo 
espiral. 
 
 
E. O protótipo descartável precisa de testes de software enquanto o evolutivo não. 
 
O ideal é que mesmo sendo um protótipo, sejam realizados testes independentemente do tipo 
de protótipo. 
 
Aula 4 Exercício – Conhecer Modelo Incremental 
 
1. No primeiro incremento do modelo incremental, que tipo de solução é oferecida ao 
cliente? 
 
Resposta Certa! 
 A. São oferecidos elementos do sistema que permitem a operação básica ao usuário. 
 
Inicialmente são oferecidas as funcionalidades básicas do sistema, para que as outras sejam 
incrementadas posteriormente. 
 
 
B. É oferecido um sistema completo, com todas as funcionalidades. 
 
O sistema completo é entregue ao final do projeto. 
 
 
C. É oferecida apenas a documentação do sistema. 
 
O primeiro incremento deve oferecer uma solução funcional ao cliente, mesmo que com 
limitações. 
 
 
D. É oferecido apenas um protótipo de telas para o cliente saber como o sistema será 
implementado. 
 
O uso de protótipos é relacionado ao modelo prototipação. 
 
 
E. Não é oferecido um sistema funcional, já que este modelo linear só oferece o produto 
ao final de todo o projeto. 
 
O incremento entregue deve ser funcional, mesmo que o software seja feito em modelo linear e 
que a entrega completa seja apenas no final do projeto. 
 
2. O que é esperado do cliente ao término de cada incremento? 
 
A. Um manual de utilização do sistema. 
 
Um manual não daria o feedback necessário. 
 
 
B. Descarte do protótipo. 
 
O uso de protótipos de descarte é feito no modelo prototipação. 
 
 
C. Uso exaustivo do sistema para encontrar erros. 
 
Os testes devem ser realizados por uma equipe de testes para garantir bom funcionamento. 
 
Resposta Certa! 
D. Uso, avaliação e feedback sobre o sistema. 
 
Ao final de um incremento, o usuário deve dar um feedback para auxiliar no planejamento do próximo 
incremento e corrigir problemas no anterior. 
 
 
E. Pagamento pelo projeto. 
 
Os modelos de ciclo de vida de software não determinam como são os pagamentos. 
 
 
3. No final do último incremento, o que é esperado na entrega? 
 
A. Apenas uma parte, incremento ou uma funcionalidade básica do sistema que esteja em 
funcionamento e bem testada. 
 
Geralmente, partes do sistema são entregues nos incrementos anteriores como objetivo de 
verificar se o que está sendo produzido está de acordo com o esperado. 
 
B. Um sistema parcialmente funcional. 
 
Ao longo do desenvolvimento, é necessário a entrega de partes funcionais do sistema com o 
objetivo de validação e feedback. No entanto, ao final, o sistema não pode estar funcionando 
parcialmente. 
 
Resposta Certa! 
C. Espera-se um sistema completo e funcional. 
 
O último incremento marca o final do projeto, então o sistema deve atender todos os requisitos 
do projeto nesta etapa. 
 
D. Espera-se que o cliente tenha as funcionalidades básicas do sistema funcionando bem 
e testadas, mas não funções complementares. 
 
A entrega das funcionalidades básicas do sistema, funcionando bem e testadas, é prevista nas 
etapas iniciais do projeto de forma que ao longo do desenvolvimento exista uma entrega contínua 
de incrementos até completar os requisitos. 
 
E. Espera-se um sistema que não atenda a nenhum dos requisitos. 
 
Mesmo nas etapas iniciais do projeto, onde existe a entrega de incrementos que são referentes 
a funcionalidades básicas do sistema, existe a necessidade de seguir e orientar o 
desenvolvimento com o objetivo de resolver os requisitos de software. 
 
4. Qual destas é uma vantagem do modelo incremental? 
 
A. Podem surgir problemas com a integração de cada entrega incremental. 
 
Esta pode ser considerada uma desvantagem do modelo. 
 
Resposta Certa! 
B. Usuários podem solicitar modificações no sistema durante o desenvolvimento. 
 
Com os incrementos, os usuários conseguem utilizar e solicitar alterações e melhorias durante o 
desenvolvimento. 
 
 
C. Os usuários podem ver um protótipo de tela antes do desenvolvimento do sistema. 
 
O uso de protótipos é uma característica do modelo prototipação.D. O sistema é entregue somente no final do projeto de forma integral. 
 
No modelo incremental, o sistema é dividido e entregue em partes. 
 
 
E. O custo do projeto é sempre respeitado. 
 
Em alguns casos, o orçamento do projeto pode ser ultrapassado devido às solicitações do cliente. 
 
5. Qual destas opções é uma desvantagem do modelo incremental? 
 
Resposta Certa! 
A. O orçamento previsto do projeto pode ser ultrapassado. 
 
Em alguns casos as solicitações do cliente podem causar um aumento dos custos do projeto. 
 
 
B. O sistema é desenvolvido respeitando os prazos. 
 
No modelo incremental, o sistema é desenvolvido rapidamente já que existe um alinhamento 
constante com o usuário. 
 
 
C. Redução de riscos de atraso da entrega. 
 
Com a entrega incremental dos módulos, o atraso de entrega é reduzido neste modelo. 
 
 
D. As partes entregues durante os incrementos não oferecem integração. 
 
O modelo incremental prevê que os módulos sejam integrados conforme sua finalização, mesmo 
que possa ocorrer problemas de integração para o desenvolvedor solucionar. 
 
 
E. O projeto é alinhado com as necessidades do cliente. 
 
Como o cliente vai dando feedbacks durante o desenvolvimento, o projeto recebe o 
direcionamento e a avaliação constante do cliente. 
 
 
 
 
 
 
 
Aula 5 Exercício – Modelos Tradicionais x Métodos Ágeis 
 
1. O que foi o manifesto ágil? 
 
A. Foi uma manifestação política contra a criação de software. 
 
O manifesto ágil não foi criado para ir contra a criação de software. 
 
Resposta Certa! 
B. Foi um conjunto de princípios e valores criados para ajudar a desenvolver software de 
maior qualidade. 
 
O manifesto ágil declarava: 
"Ao desenvolver e ajudar outros a desenvolver software, desvendamos formas melhores de 
desenvolvimento. Por meio deste trabalho, passamos a valorizar: indivíduos e interações acima 
de processos e ferramentas. Software operacional acima de documentação completa. 
Colaboração dos clientes acima de negociação contratual. Respostas a mudanças acima de 
seguir um plano." 
 
 
C. Concentra-se na capacidade de se especificar software em um alto nível de abstração, 
que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma 
função significativa. 
 
A quarta geração na engenharia de software é que concentra-se na capacidade de se 
especificar software em um alto nível de abstração, que esteja próximo à linguagem natural ou 
de se usar uma notação que comunique uma função significativa. 
 
 
D. É um método que adota a filosofia do “serial para o que é amplo” e “iterativa para o que 
é particular” para o desenvolvimento de software. 
 
O Processo Unificado Ágil (AUP) é que adota a filosofia do “serial para o que é amplo” e “iterativa 
para o que é particular” para o desenvolvimento de software. 
 
E. É uma ferramenta organizada em quatro atividades metodológicas: planejamento, 
projeto, codificação e testes. 
 
O XP (Extreme Programming) é organizada em quatro atividades metodológicas: planejamento, 
projeto, codificação e testes. 
 
2. Os métodos ágeis possuem um conjunto amplo de ferramentas e técnicas. Um deles 
possui uma característica muito interessante, que é o uso de um quadro branco e 
pequenos papéis coloridos que representam tarefas. Ele é utilizado para ajudar o time a 
gerenciar as atividades que devem ser realizadas ao longo de um determinado período de 
tempo. Quais dos itens abaixo representa a técnica descrita? 
 
Resposta Certa! 
A. Kanban. 
 
O Kanban lhe ajuda a assimilar e controlar o progresso de suas tarefas de forma visual. É, 
normalmente, utilizado um quadro branco com alguns pequenos papéis colados, que 
representam as suas tarefas. 
 
B. Scrum. 
 
O Scrum enfatiza o uso de um conjunto de padrões de software que se mostrou eficaz para 
projetos com cronogramas apertados, requisitos mutáveis e aspectos críticos de negócio. Cada 
padrão de processo define um conjunto de tarefas de desenvolvimento e permite à equipe Scrum 
construir um processo que se adapte às necessidades do projeto. 
 
C. XP (Extreme Programming). 
 
Extreme Programming (XP) é o processo ágil mais amplamente utilizado. Organizada em quatro 
atividades metodológicas – planejamento, projeto, codificação e testes – a XP sugere várias 
técnicas poderosas e inovadoras que possibilitam a uma equipe ágil criar versões 
de software com frequência, propiciando recursos e funcionalidades descritos previamente e 
priorizados pelos envolvidos. 
 
D. Modelo cascata. 
 
O modelo cascata foi um dos primeiros elaborados para o desenvolvimento linear de software. 
No entanto, ele faz parte dos modelos tradicionais. 
 
E. Processo Unificado Ágil (AUP). 
 
O Processo Unificado Ágil (AUP) adota a filosofia do “serial para o que é amplo” e “iterativa para 
o que é particular” para o desenvolvimento de software. 
 
3. "É muito mais importante que o cliente esteja plenamente satisfeito com o software e 
que ele possa, durante o projeto, solicitar mudanças para obter vantagens competitivas 
do que ter um plano/projeto bem definido e seguí-lo até o final para depois entregar 
o software ao cliente". Dos valores expressos no manifesto ágil, qual deles que justifica 
essa afirmação? 
 
A. Indivíduos e interações mais que processos e ferramentas. 
 
Sempre construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e suporte 
necessário, e confiar que farão seu trabalho. 
 
B. Colaboração com o cliente mais que negociação de contratos. 
 
A maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software de 
valor. 
 
 
C. Software em funcionamento mais que documentação abrangente. 
 
Contínua atenção à excelência técnica e bom design, aumenta a agilidade. 
 
 
D. Documentação e controle do planejamento mais que fornecer um software de 
qualidade. 
 
Os valores ágeis não seguem esta afirmação, sendo mais importante entregar um software de 
qualidade e que satisfaça o cliente do que focar no processo. 
 
 
Resposta Certa! 
E. Responder a mudanças mais que seguir um plano. 
 
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se 
adequam a mudanças, para que o cliente possa tirar vantagens competitivas. 
 
4. No fluxo de processo do scrum, o que significa "backlog"? 
 
A. Consiste em unidades de trabalho solicitadas para atingir um requisito estabelecido no 
registro de trabalho e que precisa ser ajustado dentro de um prazo já fechado. 
 
Esta é a definição dos "sprints". 
 
B. São reuniões curtas (tipicamente 15 minutos), realizadas diariamente pela equipe 
scrum. 
 
Nessas reuniões, são feitas três perguntas-chave, respondidas por todos os membros da 
equipe: 
- O que você realizou desde a última reunião de equipe? 
- Quais obstáculos está encontrando? 
- O que planeja realizar até a próxima reunião da equipe? 
Mas o "backlog" é outra parte do processo. 
 
 
Resposta Certa! 
 C. É uma lista com prioridades dos requisitos ou funcionalidades do projeto que 
fornecem valor comercial ao cliente. 
 
Os itens podem ser adicionados a esse registro a qualquer momento (é assim que as alterações 
são introduzidas). O gerente de produto avalia o registro e atualiza as prioridades conforme 
solicitado. 
 
 
D. É a pessoa responsável por conduzir a reunião em equipe e avaliar as respostas de 
cada integrante. 
 
O Scrum master é a pessoa responsável por conduzir a reunião em equipe e avaliar as 
respostas de cada integrante. 
 
 
E. É a entrega do incremento de software ao cliente para que a funcionalidade 
implementada possa ser demonstrada e avaliada por ele. 
 
O "demo" é uma entrega do incremento de software ao cliente para que a funcionalidade 
implementada possa ser demonstrada e avaliada por ele. 
 
5. Qual é a preocupação que devemos ter ao utilizar os métodos ágeis? 
 
A. Em criar uma vasta documentação do produto. 
 
A documentação, embora seja importante, fica em segundo plano. 
 
Resposta Certa! 
B. Devemos analisar se as mudanças solicitadassão possíveis. 
 
É importante analisar se as alterações realmente irão melhorar o software, se não irão aumentar 
o custo do projeto ou trazer algum malefício para o produto final. 
 
C. Seguir os processos definidos no início do projeto. 
 
Os métodos ágeis permitem mudanças ao longo do desenvolvimento. 
 
 
D. Evitar reuniões com o time e conversas com o cliente para não desviar o foco do 
planejamento. 
 
A metodologia ágil suporta que a comunicação com os indivíduos é essencial para obter 
um software de sucesso. 
 
 
E. Entregar o software somente quando ele estiver perfeito e com todas as 
funcionalidades. 
 
A metodologia ágil permite a entrega gradual de software, mesmo com funcionalidades 
reduzidas, ao longo do desenvolvimento. 
 
Aula 6 Exercício – Analisar e desenvolver Plano de Projeto 
 
1. O que é um plano de projeto de software? 
 
Resposta Certa! 
 A. É um documento que contém um conjunto de informações e permite não apenas 
executar o projeto, mas também monitorar seu progresso e verificar se o executado 
está em conformidade com o planejado. 
 
É importante perceber a importância do plano de projeto como determinante para o 
sucesso de um projeto. 
 
B. Trata-se de um roteiro de utilização do sistema. 
 
O plano de projeto não é um manual de usuário. Ele é voltado para o 
desenvolvimento de software. 
 
C. Ele define e coleta medidas (do processo, do projeto e do produto). Auxilia na 
entrega do software de acordo com os requisitos; pode ser usada com as demais 
atividades (metodológicas e de apoio). 
 
Este conceito se refere à atividade de apoio de medição do processo de software. 
 
D. Engloba as atividades necessárias para criar artefatos como, por exemplo, 
modelos, documentos, logs, formulários e listas. 
 
Este conceito é relacionado à atividade de apoio chamada "Preparo e produção de artefatos 
de software" da Engenharia de Software. 
 
E. O plano de projeto é um documento nada essencial para o sucesso de um projeto 
e não é utilizado em nenhum momento do desenvolvimento. 
 
O plano de projeto é essencial para o sucesso de um projeto, e o gerente de projeto não se 
separa dele até o encerramento de todo o desenvolvimento. 
 
2. Projeto é a única maneira pela qual podemos transformar precisamente os 
requisitos dos envolvidos em um produto ou sistema de software finalizado. 
Qual elemento do plano de projeto descreve os objetivos do projeto a ser 
desenvolvido e as restrições que afetam seu gerenciamento? 
A. Análise de riscos. 
 
A seção introdução descreve brevemente os objetivos do projeto e define as restrições que afetam o 
gerenciamento do projeto. A seão organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. A seção análise de 
riscos descreve os possíveis riscos de projeto, a probabilidade desses riscos e as estratégias de redução 
de riscos propostas. A seção divisão de trabalho estabelece a partição do projeto em atividades e 
identifica os milestones e os resultados associados a cada atividade. Os milestones são estágios 
importantes no projeto, nos quais o progresso pode ser avaliado; os resultados são produtos de trabalho 
entregues ao cliente. A seção cronograma de projeto mostra as dependências entre as atividades, a 
estimativa de tempo necessário para chegar a cada milestone e a alocação das pessoas para as atividades. 
 
B. Organização do projeto. 
 
A seção introdução descreve brevemente os objetivos do projeto e define as restrições que afetam o 
gerenciamento do projeto. A seão organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. A seção análise de 
riscos descreve os possíveis riscos de projeto, a probabilidade desses riscos e as estratégias de redução 
de riscos propostas. A seção divisão de trabalho estabelece a partição do projeto em atividades e 
identifica os milestones e os resultados associados a cada atividade. Os milestones são estágios 
importantes no projeto, nos quais o progresso pode ser avaliado; os resultados são produtos de trabalho 
entregues ao cliente. A seção cronograma de projeto mostra as dependências entre as atividades, a 
estimativa de tempo necessário para chegar a cada milestone e a alocação das pessoas para as atividades. 
 
Resposta Certa! 
C. Introdução. 
 
A seção introdução descreve brevemente os objetivos do projeto e define as restrições que afetam o 
gerenciamento do projeto. A seão organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. A seção análise de 
riscos descreve os possíveis riscos de projeto, a probabilidade desses riscos e as estratégias de redução 
de riscos propostas. A seção divisão de trabalho estabelece a partição do projeto em atividades e 
identifica os milestones e os resultados associados a cada atividade. Os milestones são estágios 
importantes no projeto, nos quais o progresso pode ser avaliado; os resultados são produtos de trabalho 
entregues ao cliente. A seção cronograma de projeto mostra as dependências entre as atividades, a 
estimativa de tempo necessário para chegar a cada milestone e a alocação das pessoas para as atividades. 
 
D. Divisão do trabalho. 
 
A seção introdução descreve brevemente os objetivos do projeto e define as restrições que afetam o gerenciamento do 
projeto. A seão organização de projeto descreve a maneira como a equipe de desenvolvimento é organizada, as 
pessoas envolvidas e seus papéis na equipe. A seção análise de riscos descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. A seção divisão de trabalho estabelece a 
partição do projeto em atividades e identifica os milestones e os resultados associados a cada atividade. Os milestones 
são estágios importantes no projeto, nos quais o progresso pode ser avaliado; os resultados são produtos de trabalho 
entregues ao cliente. A seção cronograma de projeto mostra as dependências entre as atividades, a estimativa de 
tempo necessário para chegar a cada milestone e a alocação das pessoas para as atividades. 
 
E. Cronograma do projeto. 
 
A seção introdução descreve brevemente os objetivos do projeto e define as restrições que afetam o gerenciamento do 
projeto. A seão organização de projeto descreve a maneira como a equipe de desenvolvimento é organizada, as 
pessoas envolvidas e seus papéis na equipe. A seção análise de riscos descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. A seção divisão de trabalho estabelece a 
partição do projeto em atividades e identifica os milestones e os resultados associados a cada atividade. Os milestones 
são estágios importantes no projeto, nos quais o progresso pode ser avaliado; os resultados são produtos de trabalho 
entregues ao cliente. A seção cronograma de projeto mostra as dependências entre as atividades, a estimativa de 
tempo necessário para chegar a cada milestone e a alocação das pessoas para as atividades. 
 
 
3. Qual das características do plano de projeto permite que o time de desenvolvedores, 
analistas, gerentes e outros membros entendam qual seu papel no projeto? 
 
A. Um plano de projeto possui um roadmap dos artefatos a serem entregues. 
 
O plano de projeto compreende um roadmap dos artefatos a serem entregues. Neste plano, tudo 
é previsto e documentado. No entanto, esta característica não permite que as pessoas do time 
entendam seus papeis claramente. 
 
Resposta Certa! 
B. Um plano de projeto possui uma linguagem 'comum' para comunicação das atividades 
do projeto e responsabilidades do time, bem como a rastreabilidade e relatórios dessas 
atividades. 
 
O plano de projeto especifica todas as atividades, o time, responsabilidades e o que é esperado 
ao final do projeto. Ele permite que desde o cliente e todos envolvidos no projeto entendamperfeitamente o que será realizado, como e quando. 
 
C. Um plano de projeto possui mecanismos de resolução de conflitos e mitigação ou 
atenuação de riscos. 
 
No plano de projeto é muito importante a definição de resolução de conflitos e mitigação 
ou atenuação de riscos. No entanto, esta característica não está diretamente relacionada 
com o entendimento das tarefas pelo time. 
 
D. Um plano de projeto possui um escopo de projeto bem definido. 
 
É no plano de projeto que o escopo do processo deve ser bem definido para evitar 
problemas. Embora seja útil saber qual o escopo do projeto, nesta característica não fica 
especificado o detalhamento dos papeis do time. 
 
E. Um plano de projeto possui o código fonte do software. 
 
O código fonte não faz parte do plano de projeto. No plano de projeto é explicado como 
o software será desenvolvido e também diversos outros detalhes do projeto. 
 
4. Pedro é gerente de um projeto e criou, junto ao seu time, um plano de projeto para um 
novo software que será desenvolvido. Dos itens a seguir, quais podem estar presentes em 
um plano de projeto, ajudando Pedro a pensar, prever e talvez evitar possíveis problemas 
que podem ocorrer durante o projeto e afetar o resultado final? 
 
A. A descrição de como os processos de gerência serão utilizados. 
 
Este elemento não está relacionado com possíveis problemas. 
 
B. O monitoramento e controle das mudanças. 
 
O monitoramento e controle de mudanças permite o acompanhamento de alterações do rumo 
do projeto, mas não está diretamente relacionado com a questão de riscos. 
 
C. Os baselines para cronograma, custo e qualidade. 
 
As definições relacionadas ao cronograma, custos e qualidade permitem o controle do que será 
entregue e dos custos, mas não está relacionado com possíveis problemas que podem ocorrer. 
 
D. O calendário para recursos utilizados. 
 
O calendário dos recursos deve ser informado no plano de projeto. Este calendário não auxilia 
Pedro no seu objetivo de analisar possíveis problemas que podem surgir. 
 
Resposta Certa! 
E. O mapeamento de riscos de projeto. 
 
O mapeamento de riscos de um projeto permite que Pedro verifique possíveis problemas que 
podem impedir a entrega e o sucesso do projeto ao final. Exemplos: desastres naturais, perdas 
de informações, desistências do cliente etc. 
 
5. Um plano de projeto de acordo com o PMBOK é um documento formal e aprovado, 
utilizado para orientar a execução e o controle do projeto. Sobre plano de projeto podemos 
afirmar que: 
 
Resposta Certa! 
 A. Possuem mecanismos de geração de relatório, que são documentos gerenciais que 
devem ser produzidos para o projeto 
. 
Mecanismos de monitoração e geração de relatório definem os relatórios de gerenciamento que 
devem ser produzidos, quando devem ser produzidos e os mecanismos de monitoramento de 
projetos que serão usados. Organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. O Cronograma 
de projeto ilustra as dependências entre as atividades, a estimativa de tempo necessário para 
chegar a cada milestone e a alocação das pessoas para as atividades. Divisão de trabalho 
estabelece a partição do projeto em atividades e identifica os milestones e os resultados 
associados a cada atividade. Os milestones são estágios importantes no projeto, nos quais o 
progresso pode ser avaliado. A análise de risco descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. 
 
 
B. A organização de projeto descreve as seções do documento, os objetivos do projeto e 
os custos do projeto. 
 
Mecanismos de monitoração e geração de relatório definem os relatórios de gerenciamento que 
devem ser produzidos, quando devem ser produzidos e os mecanismos de monitoramento de 
projetos que serão usados. Organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. O Cronograma 
de projeto ilustra as dependências entre as atividades, a estimativa de tempo necessário para 
chegar a cada milestone e a alocação das pessoas para as atividades. Divisão de trabalho 
estabelece a partição do projeto em atividades e identifica os milestones e os resultados 
associados a cada atividade. Os milestones são estágios importantes no projeto, nos quais o 
progresso pode ser avaliado. A análise de risco descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. 
 
 
C. O cronograma estabelece a partição do projeto em atividades e identifica os milestones 
e os resultados associados a cada atividade. 
 
Mecanismos de monitoração e geração de relatório definem os relatórios de gerenciamento que 
devem ser produzidos, quando devem ser produzidos e os mecanismos de monitoramento de 
projetos que serão usados. Organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. O Cronograma 
de projeto ilustra as dependências entre as atividades, a estimativa de tempo necessário para 
chegar a cada milestone e a alocação das pessoas para as atividades. Divisão de trabalho 
estabelece a partição do projeto em atividades e identifica os milestones e os resultados 
associados a cada atividade. Os milestones são estágios importantes no projeto, nos quais o 
progresso pode ser avaliado. A análise de risco descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. 
 
 
D. A análise de riscos define as restrições que afetam o gerenciamento do projeto e mostra 
as dependências entre as atividades. 
 
Mecanismos de monitoração e geração de relatório definem os relatórios de gerenciamento que 
devem ser produzidos, quando devem ser produzidos e os mecanismos de monitoramento de 
projetos que serão usados. Organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. O Cronograma 
de projeto ilustra as dependências entre as atividades, a estimativa de tempo necessário para 
chegar a cada milestone e a alocação das pessoas para as atividades. Divisão de trabalho 
estabelece a partição do projeto em atividades e identifica os milestones e os resultados 
associados a cada atividade. Os milestones são estágios importantes no projeto, nos quais o 
progresso pode ser avaliado. A análise de risco descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. 
 
E. A agenda do projeto mostra a estimativa de tempo necessário para chegar a cada 
milestone e concluir todas as atividades. É utilizado também para calcular os custos dos 
envolvidos no projeto. 
 
Mecanismos de monitoração e geração de relatório definem os relatórios de gerenciamento que 
devem ser produzidos, quando devem ser produzidos e os mecanismos de monitoramento de 
projetos que serão usados. Organização de projeto descreve a maneira como a equipe de 
desenvolvimento é organizada, as pessoas envolvidas e seus papéis na equipe. O Cronograma 
de projeto ilustra as dependências entre as atividades, a estimativa de tempo necessário para 
chegar a cada milestone e a alocação das pessoas para as atividades. Divisão de trabalho 
estabelece a partição do projeto em atividades e identifica os milestones e os resultados 
associados a cada atividade. Os milestones são estágios importantes no projeto, nos quais o 
progresso pode ser avaliado. A análise de risco descreve os possíveis riscos de projeto, a 
probabilidade desses riscos e as estratégias de redução de riscos propostas. 
 
Aula 7 Exercício – Métodos ágeis 
1. O desenvolvimento de softwares utilizando métodos ágeis tem grandes chances de ser 
bem-sucedido, visto que as entregas são parciais, sendo auto-organizadas pela própria 
equipe. Com base nessa informação, assinale a alternativa corretaacerca do 
desenvolvimento ágil: 
 
A. É realizado com equipes monitoradas pelo próprio cliente. 
 
O desenvolvimento ágil é formado por equipes multidisciplinares que fazem sua autogestão e 
buscam priorizar as conversas em equipe ao invés de documentações que podem dar 
morosidade aos processos, não trabalhando com o modelo tradicional "cascata". Certamente, a 
comunicação com o cliente é contínua, no entanto, não é responsabilidade do cliente fazer o 
gerenciamento da equipe. Além disso, saiba que, na prática, pode existir em uma mesma equipe 
membros que estejam em todos os níveis (júnior, pleno e sênior) e não há restrição na 
quantidade de membros. É mais importante, entretanto, que a comunicação entre a equipe seja 
assertiva e harmoniosa. 
 
Resposta Certa! 
B. É realizado com equipes multidisciplinares. 
 
O desenvolvimento ágil é formado por equipes multidisciplinares que fazem sua autogestão e 
buscam priorizar as conversas em equipe ao invés de documentações que podem dar 
morosidade aos processos, não trabalhando com o modelo tradicional "cascata". Certamente, a 
comunicação com o cliente é contínua, no entanto, não é responsabilidade do cliente fazer o 
gerenciamento da equipe. Além disso, saiba que, na prática, pode existir em uma mesma equipe 
membros que estejam em todos os níveis (júnior, pleno e sênior) e não há restrição na 
quantidade de membros. É mais importante, entretanto, que a comunicação entre a equipe seja 
assertiva e harmoniosa. 
 
C. É realizado com equipes que têm os níveis júnior e pleno. 
 
O desenvolvimento ágil é formado por equipes multidisciplinares que fazem sua autogestão e 
buscam priorizar as conversas em equipe ao invés de documentações que podem dar 
morosidade aos processos, não trabalhando com o modelo tradicional "cascata". Certamente, a 
comunicação com o cliente é contínua, no entanto, não é responsabilidade do cliente fazer o 
gerenciamento da equipe. Além disso, saiba que, na prática, pode existir em uma mesma equipe 
membros que estejam em todos os níveis (júnior, pleno e sênior) e não há restrição na 
quantidade de membros. É mais importante, entretanto, que a comunicação entre a equipe seja 
assertiva e harmoniosa. 
 
D. É realizado com equipes que seguem o modelo cascata. 
 
O desenvolvimento ágil é formado por equipes multidisciplinares que fazem sua autogestão e 
buscam priorizar as conversas em equipe ao invés de documentações que podem dar 
morosidade aos processos, não trabalhando com o modelo tradicional "cascata". Certamente, a 
comunicação com o cliente é contínua, no entanto, não é responsabilidade do cliente fazer o 
gerenciamento da equipe. Além disso, saiba que, na prática, pode existir em uma mesma equipe 
membros que estejam em todos os níveis (júnior, pleno e sênior) e não há restrição na 
quantidade de membros. É mais importante, entretanto, que a comunicação entre a equipe seja 
assertiva e harmoniosa. 
 
E. É realizado com equipes compostas por, no máximo, cinco pessoas. 
 
O desenvolvimento ágil é formado por equipes multidisciplinares que fazem sua autogestão e 
buscam priorizar as conversas em equipe ao invés de documentações que podem dar 
morosidade aos processos, não trabalhando com o modelo tradicional "cascata". Certamente, a 
comunicação com o cliente é contínua, no entanto, não é responsabilidade do cliente fazer o 
gerenciamento da equipe. Além disso, saiba que, na prática, pode existir em uma mesma equipe 
membros que estejam em todos os níveis (júnior, pleno e sênior) e não há restrição na 
quantidade de membros. É mais importante, entretanto, que a comunicação entre a equipe seja 
assertiva e harmoniosa. 
2. O método XP (Extremming Programing) contém algumas práticas ou princípios. Analise 
as afirmativas a seguir, que tratam destas práticas, e classifique-as em verdadeiras (V) ou 
falsas (F): 
( ) Metáfora é uma prática que visa a compreender a linguagem do cliente. 
( ) Programação em par é uma prática que combina dois programadores para 
trabalharem juntos. 
( ) Ritmo acelerado é uma prática que busca a sustentabilidade de produção. 
( ) Reuniões em pé são uma prática que objetiva reuniões com, no máximo, 2 horas de 
duração. 
Marque o item que apresenta a sequência correta: 
Resposta Certa! 
A. V – V – F – F 
 
A metáfora é uma prática voltada para que as pessoas se coloquem no lugar do cliente. Sendo 
assim, você pode considerá-la uma prática que tem o objetivo de compreender a linguagem do 
cliente. Quanto à programação em par, ela é uma prática que combina dois programadores para 
trabalharem juntos, inclusive para um revisar o que o outro faz. A prática do ritmo sustentável 
defende um ritmo limitado de produção de 8 horas, de forma a não desgastar os programadores, 
logo não é correto defender o ritmo acelerado. Por fim, reuniões em pé são uma prática que 
objetiva reuniões de, no máximo, 15 minutos de duração. 
 
B. V – F – F – F 
 
A metáfora é uma prática voltada para que as pessoas se coloquem no lugar do cliente. Sendo 
assim, você pode considerá-la uma prática que tem o objetivo de compreender a linguagem do 
cliente. Quanto à programação em par, ela é uma prática que combina dois programadores para 
trabalharem juntos, inclusive para um revisar o que o outro faz. A prática do ritmo sustentável 
defende um ritmo limitado de produção de 8 horas, de forma a não desgastar os programadores, 
logo não é correto defender o ritmo acelerado. Por fim, reuniões em pé são uma prática que 
objetiva reuniões de, no máximo, 15 minutos de duração. 
 
C. F – F – V – V 
 
A metáfora é uma prática voltada para que as pessoas se coloquem no lugar do cliente. Sendo 
assim, você pode considerá-la uma prática que tem o objetivo de compreender a linguagem do 
cliente. Quanto à programação em par, ela é uma prática que combina dois programadores para 
trabalharem juntos, inclusive para um revisar o que o outro faz. A prática do ritmo sustentável 
defende um ritmo limitado de produção de 8 horas, de forma a não desgastar os programadores, 
logo não é correto defender o ritmo acelerado. Por fim, reuniões em pé são uma prática que 
objetiva reuniões de, no máximo, 15 minutos de duração. 
 
D. F – V – F – V 
 
A metáfora é uma prática voltada para que as pessoas se coloquem no lugar do cliente. Sendo 
assim, você pode considerá-la uma prática que tem o objetivo de compreender a linguagem do 
cliente. Quanto à programação em par, ela é uma prática que combina dois programadores para 
trabalharem juntos, inclusive para um revisar o que o outro faz. A prática do ritmo sustentável 
defende um ritmo limitado de produção de 8 horas, de forma a não desgastar os programadores, 
logo não é correto defender o ritmo acelerado. Por fim, reuniões em pé são uma prática que 
objetiva reuniões de, no máximo, 15 minutos de duração. 
 
E. V – F – F – V 
 
A metáfora é uma prática voltada para que as pessoas se coloquem no lugar do cliente. Sendo 
assim, você pode considerá-la uma prática que tem o objetivo de compreender a linguagem do 
cliente. Quanto à programação em par, ela é uma prática que combina dois programadores para 
trabalharem juntos, inclusive para um revisar o que o outro faz. A prática do ritmo sustentável 
defende um ritmo limitado de produção de 8 horas, de forma a não desgastar os programadores, 
logo não é correto defender o ritmo acelerado. Por fim, reuniões em pé são uma prática que 
objetiva reuniões de, no máximo, 15 minutos de duração. 
3. Sobre a metodologia scrum, metodologia ágil com grande aceitação, é possível afirmar 
que ela tem alguns personagens e ferramentas. 
Acerca disso, analise as afirmativas a seguir, que abordam conceitos do scrum,e 
classifique-as em verdadeira (V) ou falsa (F): 
( ) Product owner é um gerente que verifica se as regras são seguidas. 
( ) A reunião matinal para definir as metas do dia se chama burndown. 
( ) Sprint planning meeting é uma reunião feita ao começar um sprint. 
( ) Time box é uma caixa de tempo para desenvolver os sprints. 
Marque a alternativa queapresenta a sequência correta: 
Resposta Certa! 
A. F – F – V – V 
 
Sobre personagens e ferramentas que fazem parte da metodologia do scrum, saiba que 
o product owner define prioridades do backlog; o release burndown chart é uma análise de 
metas atingidas no fim de cada sprint; o sprint planning meeting é uma reunião feita ao começar 
um sprint e conta com a presença do product owner do scrum master e do scrum team; quanto 
ao time box, é uma caixa de tempo com um conjunto de metas. 
 
 
B. V – F – V – F 
 
Sobre personagens e ferramentas que fazem parte da metodologia do scrum, saiba que 
o product owner define prioridades do backlog; o release burndown chart é uma análise de 
metas atingidas no fim de cada sprint; o sprint planning meeting é uma reunião feita ao começar 
um sprint e conta com a presença do product owner do scrum master e do scrum team; quanto 
ao time box, é uma caixa de tempo com um conjunto de metas. 
 
 
C. V – V – V – F 
 
Sobre personagens e ferramentas que fazem parte da metodologia do scrum, saiba que 
o product owner define prioridades do backlog; o release burndown chart é uma análise de 
metas atingidas no fim de cada sprint; o sprint planning meeting é uma reunião feita ao começar 
um sprint e conta com a presença do product owner do scrum master e do scrum team; quanto 
ao time box, é uma caixa de tempo com um conjunto de metas. 
 
 
D. F – F – V – F 
 
Sobre personagens e ferramentas que fazem parte da metodologia do scrum, saiba que 
o product owner define prioridades do backlog; o release burndown chart é uma análise de 
metas atingidas no fim de cada sprint; o sprint planning meeting é uma reunião feita ao começar 
um sprint e conta com a presença do product owner do scrum master e do scrum team; quanto 
ao time box, é uma caixa de tempo com um conjunto de metas. 
 
E. V – F – F – F 
 
Sobre personagens e ferramentas que fazem parte da metodologia do scrum, saiba que 
o product owner define prioridades do backlog; o release burndown chart é uma análise de 
metas atingidas no fim de cada sprint; o sprint planning meeting é uma reunião feita ao começar 
um sprint e conta com a presença do product owner do scrum master e do scrum team; quanto 
ao time box, é uma caixa de tempo com um conjunto de metas. 
 
4. Alguns modelos de desenvolvimento influenciaram no surgimento dos métodos ágeis. 
O desenvolvimento incremental, por exemplo, é um desses influenciadores. Sobre esse 
modelo, é correto afirmar que: 
 
A. Atua com a entrega total do software, evitando dividi-lo em partes. 
 
O desenvolvimento incremental, como o próprio nome diz, é baseado nas entregas de 
um software em pedaços. Assim, saiba que cada pedaço representa uma parte inteira 
do software. Em seguida, o cliente é acionado para testar a parte criada e dar feedbacks. Além 
disso, em cada incremento, novas funcionalidades são adicionadas. É incorreto, portanto, afirmar 
que não há divisões do software em partes. Esse modelo também não prevê a priorização de 
algumas entregas. Além disso, as entregas não são organizadas para serem realizadas apenas 
semanalmente ou mensalmente. Logo, ocorrem sempre que determinado pedaço do software é 
finalizado. É claro que há previsões de entrega, mas são organizadas de acordo com a 
complexidade da entrega. 
 
B. Atua com a entrega total do software, priorizando algumas entregas. 
 
O desenvolvimento incremental, como o próprio nome diz, é baseado nas entregas de 
um software em pedaços. Assim, saiba que cada pedaço representa uma parte inteira 
do software. Em seguida, o cliente é acionado para testar a parte criada e dar feedbacks. Além 
disso, em cada incremento, novas funcionalidades são adicionadas. É incorreto, portanto, afirmar 
que não há divisões do software em partes. Esse modelo também não prevê a priorização de 
algumas entregas. Além disso, as entregas não são organizadas para serem realizadas apenas 
semanalmente ou mensalmente. Logo, ocorrem sempre que determinado pedaço do software é 
finalizado. É claro que há previsões de entrega, mas são organizadas de acordo com a 
complexidade da entrega. 
 
Resposta Certa! 
 C. Atua com a entrega do software em pedaços e cada pedaço é uma parte inteira. 
 
O desenvolvimento incremental, como o próprio nome diz, é baseado nas entregas de 
um software em pedaços. Assim, saiba que cada pedaço representa uma parte inteira 
do software. Em seguida, o cliente é acionado para testar a parte criada e dar feedbacks. Além 
disso, em cada incremento, novas funcionalidades são adicionadas. É incorreto, portanto, afirmar 
que não há divisões do software em partes. Esse modelo também não prevê a priorização de 
algumas entregas. Além disso, as entregas não são organizadas para serem realizadas apenas 
semanalmente ou mensalmente. Logo, ocorrem sempre que determinado pedaço do software é 
finalizado. É claro que há previsões de entrega, mas são organizadas de acordo com a 
complexidade da entrega. 
 
D. Atua com a entrega de partes do software mensalmente. 
 
O desenvolvimento incremental, como o próprio nome diz, é baseado nas entregas de 
um software em pedaços. Assim, saiba que cada pedaço representa uma parte inteira 
do software. Em seguida, o cliente é acionado para testar a parte criada e dar feedbacks. Além 
disso, em cada incremento, novas funcionalidades são adicionadas. É incorreto, portanto, afirmar 
que não há divisões do software em partes. Esse modelo também não prevê a priorização de 
algumas entregas. Além disso, as entregas não são organizadas para serem realizadas apenas 
semanalmente ou mensalmente. Logo, ocorrem sempre que determinado pedaço do software é 
finalizado. É claro que há previsões de entrega, mas são organizadas de acordo com a 
complexidade da entrega. 
 
E. Atua com a entrega de partes do software semanalmente 
 
O desenvolvimento incremental, como o próprio nome diz, é baseado nas entregas de 
um software em pedaços. Assim, saiba que cada pedaço representa uma parte inteira 
do software. Em seguida, o cliente é acionado para testar a parte criada e dar feedbacks. Além 
disso, em cada incremento, novas funcionalidades são adicionadas. É incorreto, portanto, afirmar 
que não há divisões do software em partes. Esse modelo também não prevê a priorização de 
algumas entregas. Além disso, as entregas não são organizadas para serem realizadas apenas 
semanalmente ou mensalmente. Logo, ocorrem sempre que determinado pedaço do software é 
finalizado. É claro que há previsões de entrega, mas são organizadas de acordo com a 
complexidade da entrega. 
 
5. A metodologia de sistemas dinâmicos (DSDM) é influenciadora dos métodos ágeis 
utilizados hoje em dia. Muitas de suas características podem ser vistas em métodos 
utilizados atualmente em grandes instituições.Sobre esse modelo, é correto afirmar que: 
 
A. As equipes entregam o produto (software) com muito espaço de tempo. 
 
No modelo DSDM, as equipes entregam o produto inicialmente como um protótipo e, em seguida, 
trabalham na evolução da ferramenta até ser considerado um sistema. Além disso, tenha em 
mente que os feedbacks do cliente são muito importantes, bem como suas sugestões de 
alterações na estrutura da aplicação. Isso significa que a comunicação com o cliente é decisiva 
para o sucesso do projeto. Entretanto, as entregas são realizadas em curto espaço de tempo, o 
que sobrecarrega as equipes. Geralmente, 80% do projeto é entregue em 20% do tempo. Em 
relação à qualidade, o software não é entregue em perfeito estado, pois podem existir alterações 
a serem realizadas, visto que pode não ter sido testado durante o seu desenvolvimento. 
 
 
B. As equipes entregam o produto (software) em perfeito estado, na metade do tempo. 
 
No modelo DSDM, as equipes entregam o produto inicialmente como um protótipo e, em seguida, 
trabalham na evolução da ferramenta até ser considerado um sistema. Além disso, tenha em 
mente que os feedbacks do cliente são muito importantes, bem como suas sugestões de 
alterações na estrutura daaplicação. Isso significa que a comunicação com o cliente é decisiva 
para o sucesso do projeto. Entretanto, as entregas são realizadas em curto espaço de tempo, o 
que sobrecarrega as equipes. Geralmente, 80% do projeto é entregue em 20% do tempo. Em 
relação à qualidade, o software não é entregue em perfeito estado, pois podem existir alterações 
a serem realizadas, visto que pode não ter sido testado durante o seu desenvolvimento. 
 
 
C. As equipes entregam o produto (software) completo, evitando os feedbacks do cliente. 
 
No modelo DSDM, as equipes entregam o produto inicialmente como um protótipo e, em seguida, 
trabalham na evolução da ferramenta até ser considerado um sistema. Além disso, tenha em 
mente que os feedbacks do cliente são muito importantes, bem como suas sugestões de 
alterações na estrutura da aplicação. Isso significa que a comunicação com o cliente é decisiva 
para o sucesso do projeto. Entretanto, as entregas são realizadas em curto espaço de tempo, o 
que sobrecarrega as equipes. Geralmente, 80% do projeto é entregue em 20% do tempo. Em 
relação à qualidade, o software não é entregue em perfeito estado, pois podem existir alterações 
a serem realizadas, visto que pode não ter sido testado durante o seu desenvolvimento. 
 
Resposta Certa! 
D. As equipes entregam o produto (software) como um protótipo e o evoluem para um 
sistema. 
 
No modelo DSDM, as equipes entregam o produto inicialmente como um protótipo e, em seguida, 
trabalham na evolução da ferramenta até ser considerado um sistema. Além disso, tenha em 
mente que os feedbacks do cliente são muito importantes, bem como suas sugestões de 
alterações na estrutura da aplicação. Isso significa que a comunicação com o cliente é decisiva 
para o sucesso do projeto. Entretanto, as entregas são realizadas em curto espaço de tempo, o 
que sobrecarrega as equipes. Geralmente, 80% do projeto é entregue em 20% do tempo. Em 
relação à qualidade, o software não é entregue em perfeito estado, pois podem existir alterações 
a serem realizadas, visto que pode não ter sido testado durante o seu desenvolvimento. 
 
 
E. As equipes entregam o produto (software) mesmo que o cliente sugira alterações na 
estrutura. 
 
No modelo DSDM, as equipes entregam o produto inicialmente como um protótipo e, em seguida, 
trabalham na evolução da ferramenta até ser considerado um sistema. Além disso, tenha em 
mente que os feedbacks do cliente são muito importantes, bem como suas sugestões de 
alterações na estrutura da aplicação. Isso significa que a comunicação com o cliente é decisiva 
para o sucesso do projeto. Entretanto, as entregas são realizadas em curto espaço de tempo, o 
que sobrecarrega as equipes. Geralmente, 80% do projeto é entregue em 20% do tempo. Em 
relação à qualidade, o software não é entregue em perfeito estado, pois podem existir alterações 
a serem realizadas, visto que pode não ter sido testado durante o seu desenvolvimento. 
 
 
 
Aula 8 Exercício – Especificação de requisitos funcionais utilizando 
histórias de usuário 
1. Uma das formas de especificar requisitos funcionais em métodos ágeis é a história de 
usuário. 
Com relação a essa forma de especificação, assinale a alternativa correta. 
A. Na estrutura de especificação de uma história de usuário, três perguntas devem ser 
respondidas: quem, o que e onde. 
 
Uma história de usuário deve responder a três perguntas: quem, o que e porque. O backlog do produto vai 
conter histórias em diversos níveis diferentes de detalhe. Uma história de usuário se baseia no princípio do 
cartão (declaração curta), conversa (para alinhamento) e confirmação (critérios de aceitação da história). A 
história deve ser pequena a ponto de poder ser implementada em uma sprint, mas seu entendimento 
ultrapassa o simples cartão ou Post-it®, ela pode conter documentos, fotos ou vídeos adicionais que 
agreguem entendimento. 
 
 
B. Um backlog do produto contém todas as histórias que devem ser implementadas, em 
nível de detalhe pronto para implementar. 
 
Uma história de usuário deve responder a três perguntas: quem, o que e porque. O backlog do produto vai 
conter histórias em diversos níveis diferentes de detalhe. Uma história de usuário se baseia no princípio do 
cartão (declaração curta), conversa (para alinhamento) e confirmação (critérios de aceitação da história). A 
história deve ser pequena a ponto de poder ser implementada em uma sprint, mas seu entendimento 
ultrapassa o simples cartão ou Post-it®, ela pode conter documentos, fotos ou vídeos adicionais que 
agreguem entendimento. 
 
Resposta correta! 
C. Uma especificação de história de usuário se baseia em três princípios básicos: cartão, 
conversa e confirmação. 
 
Uma história de usuário deve responder a três perguntas: quem, o que e porque. O backlog do produto vai 
conter histórias em diversos níveis diferentes de detalhe. Uma história de usuário se baseia no princípio do 
cartão (declaração curta), conversa (para alinhamento) e confirmação (critérios de aceitação da história). A 
história deve ser pequena a ponto de poder ser implementada em uma sprint, mas seu entendimento 
ultrapassa o simples cartão ou Post-it®, ela pode conter documentos, fotos ou vídeos adicionais que 
agreguem entendimento. 
 
 
D. Uma história deve ser pequena o suficiente para caber dentro de uma notinha adesiva 
de Post-it®. 
 
Uma história de usuário deve responder a três perguntas: quem, o que e porque. O backlog do produto vai 
conter histórias em diversos níveis diferentes de detalhe. Uma história de usuário se baseia no princípio do 
cartão (declaração curta), conversa (para alinhamento) e confirmação (critérios de aceitação da história). A 
história deve ser pequena a ponto de poder ser implementada em uma sprint, mas seu entendimento 
ultrapassa o simples cartão ou Post-it®, ela pode conter documentos, fotos ou vídeos adicionais que 
agreguem entendimento. 
 
 
E. A especificação da história de usuário é composta apenas por um cartão ou Post-it® 
para manter a agilidade. 
 
Uma história de usuário deve responder a três perguntas: quem, o que e porque. O backlog do produto vai 
conter histórias em diversos níveis diferentes de detalhe. Uma história de usuário se baseia no princípio do 
cartão (declaração curta), conversa (para alinhamento) e confirmação (critérios de aceitação da história). A 
história deve ser pequena a ponto de poder ser implementada em uma sprint, mas seu entendimento 
ultrapassa o simples cartão ou Post-it®, ela pode conter documentos, fotos ou vídeos adicionais que 
agreguem entendimento. 
 
 
2. Ambientes ágeis seguem os quatro valores fundamentais do Manifesto Ágil, 
independentemente do método ágil praticado. Considere que um usuário pede para a 
equipe de desenvolvimento criar uma funcionalidade muito importante. Só que isso vai 
fazer com que a equipe atrase a entrega de outra funcionalidade que já estava planejada. 
Considerando que se trata de um time comprometido com os valores e as práticas ágeis, 
qual é a melhor alternativa para a equipe? 
A. Agendar uma reunião com a gerência sênior para obter uma decisão oficial para definir 
a prioridade. 
 
Embora todas as alternativas pareçam adequadas, a melhor alternativa em um ambiente 
que presa pelos valores ágeis é conversar com o usuário para saber se ele entende que 
esta nova funcionalidade é tão importante que leve a paralisar a que já está em 
andamento. Reuniões com a gerência sênior devem ser utilizadas apenas em caso de 
conflitos maiores. Seguir com o planejamento atual é ignorar a voz do usuário. 
Simplesmente acatar e alterar a prioridade faz com que se perca a oportunidade de 
apresentar alternativas ao usuário. Iniciar um processo de controle de mudança não é a 
primeira ação em uma empresa ágil. 
 
B. Seguir o planejamento atual de forma que o prazo inicial seja atendido e priorizar a nova 
funcionalidade de modo que seja trabalhada na sequência. 
 
Embora todas as alternativas pareçam adequadas, a melhor alternativa em um ambienteque presa pelos valores ágeis é conversar com o usuário para saber se ele entende que 
esta nova funcionalidade é tão importante que leve a paralisar a que já está em 
andamento. Reuniões com a gerência sênior devem ser utilizadas apenas em caso de 
conflitos maiores. Seguir com o planejamento atual é ignorar a voz do usuário. 
Simplesmente acatar e alterar a prioridade faz com que se perca a oportunidade de 
apresentar alternativas ao usuário. Iniciar um processo de controle de mudança não é a 
primeira ação em uma empresa ágil. 
 
Resposta correta! 
C. Conversar com o usuário para descobrir se a funcionalidade é importante o suficiente 
para mudar o time de direção. 
 
Embora todas as alternativas pareçam adequadas, a melhor alternativa em um ambiente 
que presa pelos valores ágeis é conversar com o usuário para saber se ele entende que 
esta nova funcionalidade é tão importante que leve a paralisar a que já está em 
andamento. Reuniões com a gerência sênior devem ser utilizadas apenas em caso de 
conflitos maiores. Seguir com o planejamento atual é ignorar a voz do usuário. 
Simplesmente acatar e alterar a prioridade faz com que se perca a oportunidade de 
apresentar alternativas ao usuário. Iniciar um processo de controle de mudança não é a 
primeira ação em uma empresa ágil. 
 
D. Assumir que a nova funcionalidade deve ser implementada, uma vez que o usuário 
solicitou, paralisando a funcionalidade atual. 
 
Embora todas as alternativas pareçam adequadas, a melhor alternativa em um ambiente 
que presa pelos valores ágeis é conversar com o usuário para saber se ele entende que 
esta nova funcionalidade é tão importante que leve a paralisar a que já está em 
andamento. Reuniões com a gerência sênior devem ser utilizadas apenas em caso de 
conflitos maiores. Seguir com o planejamento atual é ignorar a voz do usuário. 
Simplesmente acatar e alterar a prioridade faz com que se perca a oportunidade de 
apresentar alternativas ao usuário. Iniciar um processo de controle de mudança não é a 
primeira ação em uma empresa ágil. 
 
E. Iniciar um processo de controle de mudança. 
 
Embora todas as alternativas pareçam adequadas, a melhor alternativa em um ambiente 
que presa pelos valores ágeis é conversar com o usuário para saber se ele entende que 
esta nova funcionalidade é tão importante que leve a paralisar a que já está em 
andamento. Reuniões com a gerência sênior devem ser utilizadas apenas em caso de 
conflitos maiores. Seguir com o planejamento atual é ignorar a voz do usuário. 
Simplesmente acatar e alterar a prioridade faz com que se perca a oportunidade de 
apresentar alternativas ao usuário. Iniciar um processo de controle de mudança não é a 
primeira ação em uma empresa ágil. 
 
3. O SCRUM é um framework para desenvolvimento ágil. Você está trabalhando em uma 
empresa de desenvolvimento de software que utiliza o SCRUM para a gestão de suas 
atividades. Analise as afirmativas a seguir, referentes aos papéis presentes 
nesse framework. 
 
I. O product owner é o responsável por gerenciar os itens do product backlog. 
II. O product owner pode ser um comitê de priorização em vez de uma única 
pessoa. 
III. O product owner é o responsável por realizar mudanças na sprint em 
andamento. 
IV. O scrum master é o responsável por gerenciar as atividades da equipe SCRUM. 
V. O scrum master é o único canal de comunicação com o product owner. 
 
Com base nas afirmativas acima, assinale a alternativa correta. 
A. As alternativas I, II, III, IV e V estão corretas. 
 
No SCRUM, o product owner é o responsável por gerenciar os itens do backlog de produto. O 
PO é uma pessoa e não um grupo de pessoas. Ele pode até representar um grupo de pessoas 
ou um comitê. Ninguém tem autoridade para alterar a sprint, apenas a equipe de 
desenvolvimento. O scrum master remove impedimentos que atrapalham a realização 
da sprint. Ele não é um gerente de projetos, pois a ideia é que a equipe SCRUM seja 
autogerenciada e autônoma. O scrum master não é o único canal de comunicação com o product 
owner. 
 
 
B. As alternativas I, II e III estão corretas. 
 
No SCRUM, o product owner é o responsável por gerenciar os itens do backlog de produto. O 
PO é uma pessoa e não um grupo de pessoas. Ele pode até representar um grupo de pessoas 
ou um comitê. Ninguém tem autoridade para alterar a sprint, apenas a equipe de 
desenvolvimento. O scrum master remove impedimentos que atrapalham a realização 
da sprint. Ele não é um gerente de projetos, pois a ideia é que a equipe SCRUM seja 
autogerenciada e autônoma. O scrum master não é o único canal de comunicação com o product 
owner. 
 
 
C. As alternativas I, III e IV estão corretas. 
 
No SCRUM, o product owner é o responsável por gerenciar os itens do backlog de produto. O 
PO é uma pessoa e não um grupo de pessoas. Ele pode até representar um grupo de pessoas 
ou um comitê. Ninguém tem autoridade para alterar a sprint, apenas a equipe de 
desenvolvimento. O scrum master remove impedimentos que atrapalham a realização 
da sprint. Ele não é um gerente de projetos, pois a ideia é que a equipe SCRUM seja 
autogerenciada e autônoma. O scrum master não é o único canal de comunicação com o product 
owner. 
 
Resposta correta. 
D. Apenas a alternativa I está correta. 
 
No SCRUM, o product owner é o responsável por gerenciar os itens do backlog de produto. O 
PO é uma pessoa e não um grupo de pessoas. Ele pode até representar um grupo de pessoas 
ou um comitê. Ninguém tem autoridade para alterar a sprint, apenas a equipe de 
desenvolvimento. O scrum master remove impedimentos que atrapalham a realização 
da sprint. Ele não é um gerente de projetos, pois a ideia é que a equipe SCRUM seja 
autogerenciada e autônoma. O scrum master não é o único canal de comunicação com o product 
owner. 
 
 
E. Apenas a alterativa IV está correta. 
 
No SCRUM, o product owner é o responsável por gerenciar os itens do backlog de produto. O 
PO é uma pessoa e não um grupo de pessoas. Ele pode até representar um grupo de pessoas 
ou um comitê. Ninguém tem autoridade para alterar a sprint, apenas a equipe de 
desenvolvimento. O scrum master remove impedimentos que atrapalham a realização 
da sprint. Ele não é um gerente de projetos, pois a ideia é que a equipe SCRUM seja 
autogerenciada e autônoma. O scrum master não é o único canal de comunicação com o product 
owner. 
 
 
4. A maior parte das empresas que utiliza métodos ágeis usa o framework SCRUM. 
Assinale a alternativa correta no que diz respeito aos 3 Cs das histórias de usuário. 
Resposta Correta! 
A. Cartão + Conversa + Confirmação. 
 
A base das histórias são os 3 Cs: cartão da história de usuário (declaração da história), conversa 
com os stakeholders e confirmação (critérios de aceitação). 
 
 
B. Cartão + Comunicação + Colaboração. 
 
A base das histórias são os 3 Cs: cartão da história de usuário (declaração da história), conversa 
com os stakeholders e confirmação (critérios de aceitação). 
 
 
C. Cartão + Critérios + Cooperação. 
 
A base das histórias são os 3 Cs: cartão da história de usuário (declaração da história), conversa 
com os stakeholders e confirmação (critérios de aceitação). 
 
 
D. Comunicação + Colaboração + Cooperação 
. 
A base das histórias são os 3 Cs: cartão da história de usuário (declaração da história), conversa 
com os stakeholders e confirmação (critérios de aceitação). 
 
 
E. Comunicação + Critérios + Cooperação. 
 
A base das histórias são os 3 Cs: cartão da história de usuário (declaração da história), conversa 
com os stakeholders e confirmação (critérios de aceitação). 
 
5. O SCRUM é o método mais usado por empresas ágeis. 
Com relação às cerimônias do SCRUM, assinale a alternativa correta. 
 
A. Sprint planning meeting (Reunião de planejamento da sprint): reunião realizada 
pelo product owner com os usuários, para planejar a sprint. 
 
Sprint planning meeting (Reunião de planejamento da sprint) é uma reunião realizada pelo time 
SCRUM para planejar a sprint. Daily SCRUM