Aula 03: Engenharia de Software para Concursos - Curso Regular

Aula 03
Engenharia de Software para Concursos - Curso Regular

Professor: Diego Carvalho
Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 03
AULA 03
SUMÁRIO PÁGINA
Apresentação 01
- Metodologias Ágeis 03
- Scrum 14
- Extreme Programming (XP) 59
- Feature Driven Development (FDD) 84
- Test-Driven Development (TDD) 94
- Acceptance Test-Driven Development (ATDD) 103
- Kanban 104
Lista de Exercícios Comentados 56
Gabarito 68
16712855225
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 148

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
16712855225
Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

METODOLOGIAS ÁGEIS
Em meados de 2001, dezessete especialistas

proeminentes da área de desenvolvimento de software
se reuniram em um resort em Utah para discutir sobre
suas pesquisas e métodos de desenvolvimento de
software. Entre eles, estava Martin Fowler (foto ao
lado). Após diversos debates, eles redigiram o famoso
documento intitulado de Manifesto Ágil para
Desenvolvimento de Software, que trazia um conjunto
de definições a respeito sobre essa abordagem.
16712855225
Por que valorizar mais indivíduos e suas interações do que processos e

ferramentas?
Porque, em última instância, quem gera produtos e serviços são os indivíduos, que
possuem características únicas, como talento e habilidade. A programação de
computadores é uma atividade humana e, assim, depende de questões humanas
para seu sucesso. Highsmith afirma que são críticas para o sucesso dos projetos: as
habilidades, as personalidades e as peculiaridades dos indivíduos.

Eles são, muitas vezes, desorganizados e difíceis de entender, mas também são
inovadores, criativos e apaixonados. Vale dizer que quanto melhor a equipe
interage, mais fácil será a resolução dos problemas no desenvolvimento. O feedback
contribui bastante para melhorar essa interação. As habilidades individuais e o
trabalho em equipe são inseparáveis em projetos de desenvolvimento de software.
E quanto às ferramentas e aos processos? Ora, ambos são importantes para guiar e
apoiar o desenvolvimento, mas é a capacidade e o conhecimento dos indivíduos
que ajudam a tomar decisões críticas no projeto. Desde quando seguir processos e
usar ferramentas, apenas, é suficiente para criar bons softwares? Pois é, sempre são
necessárias as habilidades do indivíduo!
Por que valorizar mais software em funcionamento do que documentação

abrangente?
Porque clientes se interessam por resultados que entreguem valor ao negócio e,

não, por documentos abrangentes. O software em funcionamento é o único
indicador do que, de fato, a equipe construiu. Claro, não se exclui a necessidade de
documentação, que é bastante útil para o desenvolvimento, mas deve-se produzir
somente a documentação necessária e suficiente para a realização do trabalho.
Vou repetir, porque esse assunto cai em prova! No ágil, documentação é

descartável? Não! Ela é útil para ajudar a comunicação e colaboração na equipe,
melhorar a transferência de conhecimento, preservar informações históricas,
satisfazer necessidades contratuais ou legais, etc. A documentação é importante,
sim; mas valoriza-se mais o software em funcionamento.
Por que valorizar mais colaboração com o cliente do que negociação de

16712855225
contratos?
Porque é importante envolvimento contínuo do cliente. Aliás, desenvolvedores e

clientes devem estar sempre lado a lado, visto que possuem interesses em comum,
i.e., produzir um software que traga valor aos clientes. Galera, ambos são
fundamentais, o projeto não sai sem a colaboração com o cliente. Ambos devem
tomar decisões em conjunto – colaborativamente –, sem disputas contratuais.
Por que valorizar mais a resposta a mudanças do que seguir um

planejamento específico?

Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um

desenvolvimento contínuo do software. Todo projeto deve balancear o
planejamento com a mudança, dependendo do nível de incerteza inerente a ele.
Projetos são inerentemente incertos, logo manter-se preso a um planejamento
ultrapassado pode ser nocivo ao andamento do projeto.
Estamos no século 21! Uma empresa líder de mercado pode acabar de uma hora
para outra – a única certeza é a instabilidade! Logo, a equipe deve estar preparada
para mudanças no escopo, tempo, custo, tecnologia, arquitetura, entre outros.
Iterações curtas de desenvolvimento permitem que mudanças possam ser
rapidamente inseridas no projeto, de forma que atendam às novas necessidades.
Por fim, o manifesto enfatiza que os itens à direita têm seu valor, entretanto os itens
à esquerda são mais valorizados! A charge abaixo brinca com os mitos sobre
desenvolvimento ágil. Muitos acreditam que é um desenvolvimento caótico, sem
ordem, mambembe, improvisado, sem planejamento e sem documentação, mas
com foco em rapidez.
16712855225
Isso é um enorme equívoco! Primeiro, agilidade é diferente de velocidade. A

agilidade é a capacidade de responder adequadamente a mudanças (de software,
tecnologia, equipes). Quem realiza um desenvolvimento, de fato, veloz ou rápido é
o RAD (Desenvolvimento Rápido de Aplicações). Portanto, a agilidade está
relacionada a flexibilidade e capacidade de resposta.
Para entender essa diferença, eu gosto de utilizar dois exemplos! O Usain Bolt é
bicampeão olímpico, mundial, etc... ou seja, ele é geralmente o mais rápido, mas ele
tem um problema: sua largada! Ele reage mais lento que seus adversários quando

ouve o disparo de início da corrida (mudança), logo podemos dizer que ele é o mais
rápido, mas é menos ágil, i.e., ele demora mais a responder a mudanças.
Isso ocorre também quando você tem em disputa um carro muito potente e pesado
e um carro menos potente e mais leve. É provável que o carro mais leve, mesmo
sendo menos potente, tenha uma arrancada melhor, ou seja, ele é mais ágil. Apesar
de ser mais lento no decorrer da corrida, ele será mais ágil. Claro, pessoal, que esses
são exemplos genéricos – apenas para entender a ideia.
Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software.
Entretanto, para obtê-la, é essencial que seja projetado para que a equipe possa
adaptar e alinhar (racionalizar) tarefas; possa conduzir o planejamento
compreendendo a fluidez de uma abordagem do desenvolvimento ágil; possa
eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos.
Além disso, deve enfatizar a estratégia de entrega incremental, conseguindo

entregar ao cliente, o mais rapidamente possível, o software operacional para o tipo
de produto e ambiente operacional. Essa são as diretivas para que um processo de
software possa ser, também, ágil. Vocês podem notar que segue todos os princípios
que nós já vimos em aula.
Métodos ágeis são mais dinâmicos, adaptativos, interativos e colaborativos, eles se

adaptam às necessidades de um projeto e às suas mudanças no decorrer do
desenvolvimento; os tradicionais são mais preditivos/prescritivos, processuais,
formais, documentais e contratuais, eles valorizam mais o planejamento de todos
os aspectos do processo de desenvolvimento de software como um todo.
Entre os princípios do desenvolvimento ágil de software, nós temos: simplicidade;

rápida adaptação a mudanças; quaisquer mudanças no projeto são bem-vindas;
16712855225
softwares ou partes de softwares são entregues frequentemente; cooperação

constante entre a área de negócio e a área técnica; excelência técnica, entre outros.
Galera, já entraram no site do Manifesto Ágil? Entrem aí: www.agilemanifesto.org.
NÓS SEGUIMOS ESSES PRINCÍPIOS...
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de

software com valor agregado. As Metodologias Tradicionais preconizavam planos detalhados
do projeto; o Ágil busca se adaptar às necessidades dos clientes e entregar valor
continuamente.

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos

ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. As
Metodologias Tradicionais são preditivas – já vimos que esse cenário é ilusório.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com

preferência à menor escala de tempo. As Metodologias Tradicionais realizam, em geral, uma
única entrega – ao final do projeto,
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

projeto. As Metodologias Tradicionais não valorizavam essa colaboração intensa entre clientes
e desenvolvedores, como faz o Ágil.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte

necessário e confie neles para fazer o trabalho. As Metodologias Tradicionais se apoiavam
fortemente em processos e ferramentas, em detrimento das pessoas que, de fato, construíam
o software.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através de conversa face a face. As Metodologias Tradicionais utilizam
documentos, diagramas, relatórios, telefonemas para promover a comunicação no projeto.
Software funcionando é a medida primária de progresso. As Metodologias Tradicionais

propunham a entrega de artefatos (Ex: Documentação) que, em geral, não agregavam valor
algum aos clientes, como também uma forma de medir o progresso do projeto.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,

desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente. As Metodologias Tradicionais, muitas vezes, patrocinavam horas-extras de
forma a fazer a equipe produzir mais em menos tempo.
16712855225
Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias

Tradicionais acreditavam que, para se obter máxima velocidade e flexibilidade no
desenvolvimento de software, poder-se-ia sacrificar a qualidade deste software.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As

Metodologias Tradicionais, algumas vezes, recorriam a implementações desnecessariamente
complexas, a planejamentos exageradamente detalhados, entre outros.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As

Metodologias Tradicionais geralmente precisam de um gerente de projetos responsável por

organizar o trabalho da equipe como um todo, sendo também responsável pela tomada de
decisões.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo. As Metodologias Tradicionais muitas vezes são
engessadas, i.e., não revisitam frequentemente seu comportamento.
Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho

e complexidade? Segundo Sommerville: “Todos os métodos têm limites, e os métodos
ágeis são somente adequados para alguns tipos de desenvolvimento de sistema. Na
minha opinião, eles são mais adequados para o desenvolvimento de sistemas de
pequenas e médias empresas e produtos para computadores pessoais”.
Eu discordo dessa afirmação! Acredito que ela já foi válida tempos atrás, mas hoje
não é mais! Projetos Ágeis já são suficientemente maduros para serem aplicados a
projetos complexos e de grande porte. Pessoal, essa é só a minha opinião! Não é
possível saber ainda a posição das bancas caso isso seja questionado em provas de
concurso. Bacana? Vamos lá...
Professor, você pode citar algumas metodologias e frameworks de desenvolvimento

de software? Claro, vejam uma lista abaixo:
16712855225

(CESPE – 2012 – TCE/ES – Auditor de Controle Externo – Tecnologia da

Informação) Em virtude de as metodologias ágeis gerarem excessiva
documentação, a gestão do conhecimento depende diretamente dos
programadores envolvidos no projeto.
Comentários:

abrangente?
Vou repetir, porque esse assunto cai em prova! No ágil, documentação é descartável?
Não! Ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a
transferência de conhecimento, preservar informações históricas, satisfazer
necessidades contratuais ou legais, etc. A documentação é importante, sim; mas
valoriza-se mais o software em funcionamento.
Conforme vimos em aula, o Manifesto Ágil valoriza: Software em Funcionamento

mais do que Documentação Abrangente, portanto não é correto dizer que
metodologias ágeis geram excessiva documentação.
Gabarito: E
16712855225
(CESPE – 2011 – EBC – Analista de Sistemas) O que os métodos ágeis buscam é

como evitar as mudanças desde o início do projeto e não a melhor maneira de
tratar essas mudanças.
Comentários:
NÓS SEGUIMOS ESSES PRINCÍPIOS...

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos

ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. As
Metodologias Tradicionais são preditivas – já vimos que esse cenário é ilusório.
Conforme vimos em aula, Metodologias Ágeis são extremamente afeitas a

mudanças de requisitos, adaptando-se a novos contextos e respondendo a cada
modificação.
Gabarito: E
(CESPE – 2010 – BASA – Técnico Científico – Arquitetura de Tecnologia)

Desenvolvimento ágil de software (Agile Software Development) ou método ágil
é aplicado, principalmente, a grandes corporações, uma vez que permite
produzir grandes sistemas de forma ágil.
Comentários:
Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho

e complexidade? Segundo Sommerville: “Todos os métodos têm limites, e os métodos
ágeis são somente adequados para alguns tipos de desenvolvimento de sistema. Na
minha opinião, eles são mais adequados para o desenvolvimento de sistemas de
pequenas e médias empresas e produtos para computadores pessoais”.
A questão afirma que ela é aplicada principalmente a grandes corporações. De fato,

isso está errado! Ela ainda é aplicada principalmente a aplicações pequenas e
médias, mas permite – sim – produzir grandes sistemas de forma ágil.
16712855225
Gabarito: E
(CESPE – 2010 – TCU – Auditor Federal de Controle Externo – Tecnologia da

Informação) A agilidade não pode ser aplicada a todo e qualquer processo de
software.
Comentários:
Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software.
Entretanto, para obtê-la, é essencial que seja projetado para que a equipe possa
adaptar e alinhar (racionalizar) tarefas; possa conduzir o planejamento

compreendendo a fluidez de uma abordagem do desenvolvimento ágil; possa

eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos.
Conforme vimos em aula, a agilidade pode – sim – ser aplicada a qualquer processo
de software.
Gabarito: E
(CESPE – – UNIPAMPA – Analista de Sistemas) XP, Scrum e Cristal são

exemplos de modelos ágeis de desenvolvimento de sistemas.
Comentários:
Conforme vimos em aula, está perfeito!
Gabarito: C
16712855225
(CESPE - 2011 - EBC - Analista - Engenharia de Software) Considerando o

conceito de metodologia ágil em apreço, é correto afirmar que as seguintes
metodologias são ágeis: XP (Extreme Programming), Scrum, Crystal, FDD
(Feature Driven Development), DSDM (Dynamic Systems Development Method)
e Open Source Software Development.
Comentários:

Conforme vimos em aula, está perfeito!
Gabarito: C
(CESPE - 2013 - CNJ - Técnico Judiciário - Programação de Sistemas) O

desenvolvimento ágil de sistemas consiste em uma linguagem de modelagem
que permite aos desenvolvedores visualizarem os produtos de seu trabalho em
gráficos padronizados.
Comentários:
Não, desenvolvimento ágil de sistemas não é uma linguagem de modelagem. Quem

pode me dizer um exemplo de linguagem de modelagem? UML!
Gabarito: E
16712855225
(CESPE - 2011 - EBC - Analista - Engenharia de Software) É conveniente que o

contrato, entre cliente e fornecedor, para o desenvolvimento de um sistema
computacional, contenha a lista de requisitos para o software. Contudo, os
métodos ágeis de desenvolvimento preconizam que o referido contrato
estabeleça o preço, a ser pago pelo cliente, com base no tempo necessário para
o desenvolvimento do sistema e não com base no conjunto de requisitos.
Comentários:
Segundo Martin Fowler, pode-se fixar um orçamento para o software antes de

desenvolvê-lo. A abordagem ágil comum é fixar tempo e preço, deixando o escopo

variar (os requisitos são variáveis) de forma controlada. É o famoso: “Tempo fixo,
escopo variável”.
Gabarito: C
(CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Metodologias de

desenvolvimento ágil enfocam atividades de projeto e implementação,
desconsiderando as atividades de elicitação de requisitos e a produção de
documentação.
Comentários:

abrangente?
Porque clientes se interessam por resultados que entreguem valor ao negócio e, não,
por documentos abrangentes. O software em funcionamento é o único indicador do
que, de fato, a equipe construiu. Claro, não se exclui a necessidade de documentação,
que é bastante útil para o desenvolvimento, mas deve-se produzir somente a
documentação necessária e suficiente para a realização do trabalho.
Vou repetir, porque esse assunto cai em prova! No ágil, documentação é descartável?
Não! Ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a
transferência de conhecimento, preservar informações históricas, satisfazer
necessidades contratuais ou legais, etc. A documentação é importante, sim; mas
valoriza-se mais o software em funcionamento.
Conforme vimos em aula, é absurdo pensar que se desconsidera atividades de

elicitação de requisitos – não há o que se discutir nesse ponto. Além disso, o
16712855225
Manifesto Ágil afirma que, mesmo havendo valor na documentação extensa de

software, valoriza-se mais o software em funcionamento. Em outras palavras, é
errado afirmar que se desconsidera a produção de documentação, tendo em vista
que há uma codificação não formal.
Gabarito: E
ACERTEI ERREI

SCRUM
Alguém de vocês sabe de onde vem esse nome? Não? Então eu vou contar! Esse
nome vem do Rugby e é utilizado como uma metáfora para refletir o alto grau de
cooperação necessária para obter sucesso no alcance de algum objetivo. Imagino
que poucos de vocês entendam as regras desse esporte, portanto vou explicar de
forma bastante rápida e objetiva o porquê dessa metáfora ser utilizada.
No Rugby, um time pontua quando a bola cruza a linha de gol e toca o chão –
sendo carregada ou por meio de um passe. Caso o jogador seja derrubado, ele
deve soltar a bola, e a jogada se reinicia! Deve haver intensa troca de passes entre
os jogadores, de modo a deixá-los menos vulneráveis a serem derrubados por
outros jogadores. Tranquilo até aqui?
16712855225
Bem... cada jogada se inicia quando um scrum é realizado, isto é, forma-se uma
parede de força entre os jogadores, como pode ser visto na imagem acima.
Observem que os jogadores se reúnem de forma bastante próxima, unindo suas
forças e habilidades para trabalhar em conjunto e harmonicamente a fim de
conseguir recuperar a bola.

Percebam, portanto, que o time inteiro deve trabalhar para que a equipe possa
pontuar. Diferentemente do Futebol Americano (NFL), não há um quarterback ou
uma estrela no time – todos têm suas funções e responsabilidades, e são igualmente
importantes! Acredito que agora ficou mais fácil entender de onde vem esse nome.
Chega de papo e vamos à teoria...
Antes de iniciarmos, eu gostaria de fazer uma observação importante: guia oficial

do Scrum é um documento tão pequeno (são apenas 19 páginas!) que eu
recomendo fortemente que vocês o leiam por inteiro, porque ele é a fonte de
praticamente tudo que veremos aqui! Tem versão em português, é gratuito, é
enxuto, então não tem desculpas. Bem, agora sim vamos iniciar...
Scrum é um framework leve, simples de entender e extremamente difícil de dominar,

para desenvolver e manter produtos complexos e adaptativos, enquanto entrega
produtiva e criativamente produtos com o mais alto valor possível. Na minha época
de concurso, eu decorava essa definição (Obs: recomendo decorar definições!).
Fiquem calmos porque nós vamos esmiuçar cada parte desse conceito.
Primeiro, ele é um framework – isso significa dizer que ele agrega processos,
16712855225
métodos e técnicas. Fundamentalmente, ele possui pressupostos, conceitos, valores

e práticas, mas quem utilizá-lo pode incluir novidades (Ex: Pair Programming, do
XP). Ele não te dirá tudo o que fazer, você tem a liberdade para fazer o que melhor
funcionar dentro das suas necessidades.
Segundo, ele é um documento bastante enxuto! Vocês verão que, oficialmente e

obrigatoriamente, ele é composto por três papeis (Product Owner, Scrum Master e
Development Team); por quatro eventos (Sprint Planning, Daily Meeting, Sprint
Review e Sprint Retrospective); por três artefatos (Product Backlog, Sprint Backlog e
Product Increment); e por um fluxo (chamado Sprint).

Aqueles que já conhecem devem estar um pouco confusos! Professor, o Gráfico

Burndown não é um artefato? O Documento de Visão não é um artefato? Calma,
galera! São, sim! No entanto, oficialmente é possível utilizar o framework sem nada
isso! Isso tudo são espécies de “plug-ins” que podem ser adicionados ao framework
para ajudar no processo, mas eles são opcionais.
O Scrum é um framework baseado em código, para gerenciar projetos, produtos e

processos, focado na adaptação em vez de planejamento, que não utiliza muita
documentação e que adota processos mais simplificados, facilitando a adaptação às
mudanças de requisitos e permitindo entregas rápidas e menores. Ele é usado em
ambientes complexos, onde os requisitos e as prioridades mudam constantemente.
O que seria exatamente um ambiente complexo? Existe uma coisa chamada Modelo
Cynefin que explica bem os tipos de ambientes. Existem os ambientes simples,
complicados, complexos e caóticos. O que vocês precisam saber é que um ambiente
complexo é aquele que não é muito bem definido, não é muito acoplado, há muitas
mudanças, apresenta muitas formas de realizar um trabalho.
Querem um exemplo? O McDonalds é um ambiente complexo? Não, é um ambiente

simples! Ele é muito bem definido, extremamente acoplado, não tem liberdade e
o existem muitas opções de como realizar um trabalho. Em qualquer lugar do
mundo, o cardápio será praticamente o mesmo; o cara que faz o sanduba realiza
os mesmos passos; não há mudanças; não há várias formas de realizar um trabalho.
16712855225

O Scrum é um framework em que podem ser empregados vários processos e

técnicas. Pode ser definido como um conjunto de papéis, eventos, artefatos e regras
associadas a uma equipe. Ele é fundamentado em teorias empíricas de controle de
processo e emprega uma abordagem iterativa e incremental (maximizando as
oportunidades de feedback) para aperfeiçoar a previsão e controle de riscos.
O empirismo afirma que o conhecimento vem da experiência e da tomada de

decisões com base naquilo que é verdadeiro e conhecido. Para tal, ele emprega
uma abordagem iterativa e incremental para aperfeiçoar e otimizar a previsibilidade
e controle de riscos, fundamentando-se – para tal – em três pilares fundamentais:
Transparência, Inspeção e Adaptação (é o famoso T I A).
– Transparência: aspectos significativos (e padronizados) devem estar visíveis aos

responsáveis pelos resultados. Deve haver transparência dentro e fora da equipe,
permitindo a qualquer pessoa compreender o que realmente está ocorrendo,
ocasionando melhor comunicação e confiança. Ken Schwaber diz: “Scrum é igual
sogra: chega na sua casa e esfrega todos os seus problemas na sua cara
Se uma sprint falhar, todos ficam sabendo; se os feedbacks forem ruins, todos ficam
sabendo; se o projeto atrasou, todos ficam sabendo. O objetivo é encarar as
dificuldades de forma honesta e chegar a um consenso sobre como estes podem
ser ultrapassados. Os erros são inevitáveis e a equipe deve ser incentivada a encarar
esta premissa como uma base para aprender com os erros que são cometidos.
– Inspeção: também chamado verificação, os usuários devem frequentemente

inspecionar os artefatos e o progresso, para detectar indesejáveis variações (não
pode ser extremamente frequente ao ponto de atrapalhar a execução das tarefas).
Uma vez que todos os problemas ficam transparentes, é o momento de inspecionar
16712855225
o processo e o produto em busca de resolver o problema.
A ideia aqui é identificar rapidamente qualquer desvio sobre a meta que deve ser
atingida. Vocês verão que, na Reunião de Revisão e na Reunião de Retrospectiva,
tanto os produtos quanto os processos são inspecionados. As inspeções são mais
benéficas quando realizadas de forma diligente por inspetores especializados no
trabalho a se verificar.
– Adaptação: se um inspetor determina que um ou mais aspectos de um processo

desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável,
o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser

realizado o mais breve possível para minimizar mais desvios. Como mudanças
sempre ocorrem, recomenda-se a adaptação em vez de evitá-las.
Vamos resumir os três pilares que sustentam o nosso framework! Tudo no Scrum
deve ser transparente e facilmente acessível. Partindo dessa premissa, podemos
inspecionar e identificar problemas e oportunidades de melhoria do produto e/ou
processo – em geral, por meio de cerimônias. Feito isso, deve-se buscar ajustar e
adaptar produto e/ou processo para minimizar desvios. Simples, não?
O Scrum define o conceito de Time Scrum, que é um time auto-organizável (escolhe

qual a melhor forma para realizar seu próprio trabalho) e multifuncional (possui
todas as competências e não depende de outros de fora da equipe). É o responsável
por entregar produtos de forma iterativa e incremental, maximizando as
oportunidades de realimentação (feedback).
Entregas incrementais de produto “pronto” garantem que uma versão

potencialmente funcional do produto do trabalho esteja sempre disponível. É bom
entender isso aqui! Scrum prega que, ao fim de cada sprint, deve-se entregar um
incremento potencialmente funcional do produto ao cliente. O que seria
potencialmente funcional? É aquilo que tem potencial de entrar em produção!
O Scrum realiza ciclos completos de desenvolvimento de duração fixa em que, ao

final, temos incrementos potencialmente entregáveis do produto. O nome desses
ciclos de desenvolvimento é Sprint! Ela tem duração de até um mês, permitindo
feedbacks constantes quanto ao que está sendo desenvolvido. A Sprint é como um
contêiner para todos os outros eventos e cerimônias que veremos à frente.
16712855225

SCRUM: PAPEIS
O Scrum possui pouquíssimos papéis, mas eles são muito bem definidos. O Scrum
Team é composto por: Product Owner (PO), Scrum Master (SM) Development
Team (DT). Guardem a fórmula: ST = PO+SM+DT! Não confundam Development
Team com Scrum Team! Professor, pode haver sobreposição de papeis? Sim, SM
pode ser do DT e o PO pode ser do DT, mas um SM jamais pode ser o PO!
RESPONSABILIDADES E CARACTERÍSTICAS: PRODUCT OWNER (PO)

Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho da equipe de

desenvolvimento, sendo o único que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para o time de desenvolvimento,
mas ainda será considerado o responsável pelos trabalhos.
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que
serão implementados.
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre
Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente,
claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir.
Ele é responsável por garantir que o Time de Desenvolvimento entenda os itens do Product
Backlog no nível necessário.
O Product Owner é uma pessoa e não um comitê. Ele pode representar o desejo
16712855225
de um comitê no Product Backlog, mas aqueles que quiserem uma alteração nas
prioridades dos itens de backlog devem convencer o Product Owner. Para que ele
tenha sucesso, toda a organização deve respeitar as suas decisões e elas devem ser
visíveis no conteúdo e na priorização do Backlog do Produto.
Ninguém tem permissão para falar com o Time de Desenvolvimento sobre

diferentes configurações de prioridade, e o Time de Desenvolvimento não tem
permissão para agir sobre o que outras pessoas disserem. O Time de
Desenvolvimento só responde ao Product Owner. Além disso, só ele pode cancelar
uma sprint. Perfeito?

RESPONSABILIDADES E CARACTERÍSTICAS: DEVELOPMENT TEAM (DT)

Responsável pela micro-gestão e pela criação do produto.
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz ao Time de Desenvolvimento como
transformar o Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.
Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades
necessárias, enquanto equipe, para criar o incremento do Produto.
O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja
Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa;
Individualmente, os integrantes do Time de Desenvolvimento podem ter habilidades
especializadas, mas a responsabilidade pertence aos desenvolvedores como um todo.
-times dedicados a domínios específicos de
conhecimento, tais como teste ou análise de negócios.
Os Times de Desenvolvimento são estruturados e autorizados pela organização para
organizar e gerenciar seu próprio trabalho.
O Development Team deve ser pequeno o suficiente de forma a se manter ágil e

produtivo, e grande o suficiente de forma que a coordenação dos membros não
cause problemas. Com menos de três pessoas, há menor interação e pode haver
problemas em relação ao conhecimento durante a execução da sprint. Com mais
de nove, há muita complexidade no gerenciamento.
Em suma, a equipe deve ter entre 3 e 9 integrantes, de modo que não seja pequena
demais que haja restrições de habilidades nem grande demais que seja complicado
de gerenciar. Vou dizer de novo: não confundam Equipe de Desenvolvimento
(Development Team) com Equipe Scrum (Scrum Team)! O PO e SM não são
16712855225
incluídos nesta contagem, a menos que também façam parte do DT.
RESPONSABILIDADES E CARACTERÍSTICAS: SCRUM MASTER (SM)

Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para
garantir que o Time Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas
interações com o Time Scrum são úteis e quais não são.

O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo
Time Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product
Backlog.
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus
valores estajam sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo
isso sem o uso de qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar
os problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente,
utilizando técnicas de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar o time de desenvolvimento em autogerenciamento e interdisciplinaridade.
Ele treina o time de desenvolvimento em ambientes organizacionais nos quais o Scrum

não é totalmente adotado e compreendido.
Ele ensina o Time Scrum a criar itens do Product Backlog de forma clara e concisa.
Ele auxilia o PO na comunicação clara da visão, objetivo e itens do Product Backlog para
o time de desenvolvimento.
Certa vez, uma aluna me falou o seguinte: “Professor, na minha opinião, o controle
e gerenciamento do projeto não é descentralizado nesses três papéis. O Product
Owner responde pelo sistema, logo o gerenciamento e controle não é descentralizado
– é centralizado no PO!”. Eu resolvi, então, inventar uma metáfora para que ela
pudesse entender melhor. É mais ou menos assim...
Imaginem que João deseja construir uma casa. Para tal, ele contrata uma renomada
16712855225
empresa de engenharia. A empresa irá fornecer todo seu know-how por meio de
uma Equipe de Construção de Casas, que será composta por uma Equipe de
Pedreiros, um Mestre de Obras e... por você! Sim, você fará parte da Equipe de
Construção de Casas como principal parte interessada.
Vamos dar um nome para você? Você ocupará o cargo de Dono da Casa. Ora,
então, a Equipe de Construção de Casas será composta por uma Equipe de
Pedreiros, um Mestre de Obras e o Dono da Casa. E qual é a função de cada um?
Bem, a Equipe de Pedreiros é composta por 3 a 9 pedreiros multidisciplinares – i.e.,
todos dominam todas as atividades de um pedreiro.

Eles são os responsáveis por colocar a mão na massa, levantar parede, fazer o
concreto, alinhar o piso, etc. Já o Mestre de Obras é o grande facilitador! Como
assim, professor? Ele vai retirar os impedimentos que aparecem no decorrer do
nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele irá buscar uma
maneira de reduzir os impactos dessa ausência.
Os pedreiros estão desmotivados, distraídos, descuidados? Ele irá arrumar uma

maneira de solucionar isso. Um pedreiro saiu na porrada com outro? Ele irá
intermediar o conflito. Além disso, ele que vai trazer a demanda do Dono da Casa,
entender o que ele quer e passar de maneira simples, clara e objetiva para a Equipe
de Pedrei . Ele é o cara que mais deve conhecer os fundamentos do Scrum!
E, por fim, ele também irá treinar a equipe para que ela seja auto gerenciável e
interdisciplinar. E você? Qual a sua função? Você é o Dono da Casa – você que
gerencia o que será feito e o que não será feito. Você é o responsável pelo que será
entregue. A Equipe de Pedreiros responde a você! O Mestre de Obras responde
somente a você!
Você é o cara que tem que tentar fazer essa casa ficar o melhor possível (Máximo
Valor Agregado). Você é o cara que vai priorizar o que deve ser feito primeiro. Você
é o cara que coloca ou tira atividades da lista atividade a serem realizadas. Você é
o único cara que pode simplesmente cancelar determinada atividade. Pessoal, há
pequenas diferenças, mas a metáfora é evidente.
A Equipe de Construção de Casas é o Scrum Team; a Equipe de Pedreiros é o

Development Team; o Mestre de Obras é o Scrum Master; e o Dono da Casa é o
Product Owner. Bacana? Cada um desses tem atividades bem definidas. E o controle
sobre essas atividades é descentralizado, ou seja, o Dono da Casa não interfere na
parte técnica dos pedreiros, que não interferem no trabalho do Mestre de Obras.
16712855225
Pensem em uma repartição pública que contém uma Coordenação dividida em 4

gerências. Ora, o controle a gestão são descentralizados, feitos por cada gerência
– mesmo que todas elas tenham que responder ao coordenador. Bem, acredito que
dessa forma consegui convencê-la e fazê-la entender melhor o papel de cada um
desses caras. Ficou mais claro agora?

SCRUM: EVENTOS OU CERIMÔNIAS
Bem, vamos falar agora sobre as cerimônias ou eventos! Nós temos quatro eventos
descritos no guia oficial – nós veremos mais à frente. Antes disso, vamos falar de
um evento não-oficial, mas que geralmente é realizado: Reunião de Visão! O que é
isso, professor? É o momento que visa estabelecer um ponto no processo em que o
Product Owner deve expor os detalhes do produto a ser construído.
A saída dessa reunião deve ser uma visão sobre o produto, i.e., representa como os
clientes, usuários finais, gerentes, stakeholders, executivos, entre outros, visualizam
o resultado final do produto que será criado. Para tal, pode-se utilizar diversas
técnicas, tais como: Product Vision Box, Product RoadMap, Product DataSheet ou
Elevator Pitch Sentence.
Vamos ver um pouco dessa última técnica! Geoffrey Moore, no seu livro Crossing
the Chasm, apresenta um modelo interessante para a Visão do Produto, o chamado
“Teste do Elevador”. A ideia é que seja possível explicar o que é o produto durante
a subida de um elevador, ou seja, em um tempo bastante curto. Adaptado por Jim
Highsmith, esse modelo tem o formato apresentado abaixo.
16712855225

Um exemplo de visão sobre um produto: “Para turistas usuários de smartphone, que

desejam aproveitar melhor seus locais de destino, o MyTrip é um aplicativo móvel de
viagens que sugere roteiros diários flexíveis de acordo com seu perfil. Ao contrário de
guias de viagens com roteiros predefinidos, nosso produto elabora trajetos
personalizados e adaptáveis”.
Lembremos que a visão do produto, de forma geral, deve permanecer estável

durante todo o projeto. Ela é criada, gerenciada e compartilhada pelo Product
Owner, que garante que o Product Backlog esteja sempre alinhado a ela. No
entanto, as partes interessadas relevantes podem estar diretamente envolvidas no
refinamento dessa visão.
Há outra cerimônia não-oficial (apesar de muito comum) chamada Release Planning

Meeting. O que seria isso? Nós vimos que ao final da sprint, a equipe entrega um
incremento do produto potencialmente funcional, i.e., tem o potencial de entrar em
produção. Ora, muitas vezes é desejável esperar algumas sprints até juntas todas as
funcionalidades e entregar uma release (conjunto de funcionalidades).
Essa cerimônia serve para planejar como será essa release. Isso é extremamente
importante, porque vocês devem saber a criticidade de colocar algo em produção.
É comum ter várias restrições, preocupações e dependências, como datas
importantes, itens contratuais, logística, entre outros. Dessa forma, a equipe precisa
planejar suas entregar várias sprints à frente.
Prossigamos para as cerimônias oficiais! Os Eventos Scrum são eventos time-boxed

(isto é, com duração máxima predefinida) usados para criar uma rotina e minimizar
a necessidade de reuniões não definidas pelo Scrum. Lembrem-se de que a Sprint
tem um mês ou menos (em geral, duas a quatro semanas) e é iniciada
16712855225
imediatamente após a conclusão da sprint anterior.
As sprints são compostas por uma Reunião de Planejamento da Sprint, por Reuniões
Diárias, pelo Trabalho de Desenvolvimento, por uma Revisão da Sprint e pela
Retrospectiva da Sprint. Uma sprint se inicia imediatamente após a conclusão da
sprint anterior e tem durações coerentes em todo o esforço de desenvolvimento.
Durante a sprint é proibido realizar mudanças que afetem a sua meta.
Além disso, é proibido mudar a composição da equipe ou diminuir as metas de

qualidade, apesar disso o escopo pode ser sempre clarificado e renegociado. Uma
sprint pode ser cancelada antes de seu time-box terminar e isso somente pode ser

feito pelo Product Owner (sob influência de stakeholders, equipe de

desenvolvimento, entre outros).
Isso pode ocorrer caso o seu objetivo se torne obsoleto, mas ocorrem também
devido à curta duração e a cancelamentos, porém são raros os casos. O trabalho a
ser realizado na Sprint é planejado na Reunião de Planejamento da Sprint
(proporcional de 8 horas). Essa reunião consiste em duas partes e elas devem
responder adequadamente as perguntas:
1. O que será entregue como resultado do incremento da próxima Sprint?

2. Como o trabalho necessário para entregar o incremento será realizado?
Na primeira parte, a Equipe de Desenvolvimento tenta prever as funcionalidades

que serão desenvolvidas durante a Sprint. O Product Owner apresenta as histórias
de usuário mais priorizados do Product Backlog à Equipe de Desenvolvimento.
Como ele faz isso? Em geral, ele dá um valor de negócio para cada item do backlog,
organizando-os em forma decrescente de valor de negócio. Como assim, professor?
Imaginem que exista um item que o Product Owner deseja muito que seja
implementado – ele dá um valor de negócio de 1000; agora imagine que tem outro
item no Product Backlog que o Product Owner não liga tanto – ele dá um valor de
negócio de 10; e assim por diante. Dessa forma, o Product Owner consegue ordenar
os itens de acordo com o valor de negócio.
Feito isso, é hora de estimar o esforço de desenvolvimento de cada item do backlog.

Quando nós utilizamos histórias de usuário, é comum utilizarmos uma outra
unidade de medida para medir esforço, em vez do tempo – utilizado
frequentemente em metodologias tradicionais. No caso de Histórias de Usuário
(User Stories), nós utilizamos Pontos de História (Story Points).
16712855225
Trata-se de uma unidade de medida relativa que leva em consideração o esforço

necessário para realizar uma determinada funcionalidade. Se uma funcionalidade
requerer o dobro de esforço para ser implementada, ela receberá
aproximadamente o dobro de Story Points. Para fazer essa estimativa, a equipe de
desenvolvimento realiza uma comparação com outras histórias já estimadas.
Caso não haja ainda nada estimado no Product Backlog, a equipe localiza a história
de usuário com o menor esforço para desenvolvimento e o utiliza como base de
comparação. Uma das melhores formas de estimar Story Points é por meio de uma

técnica chamada Planning Poker, que não está no guia oficial, mas que é
frequentemente utilizada.
Essa técnica combina a opinião de experts, analogia e desagregação em uma

abordagem divertida na estimação de Histórias de Usuário, e elimina a influência
que um membro da equipe de desenvolvimento possa exercer sobre outros. Feita
a estimativa de cada história de usuário, a equipe de desenvolvimento decidirá a
quantidade de itens do backlog a serem realizadas na sprint.
Detalhe: algumas vezes as histórias de usuário são muito grandes para serem
desenvolvidas em uma sprint – são chamadas de Épicos. Elas precisarão ser
quebradas em partes menores. Mais que isso, em alguns projetos é necessário um
nível ainda maior que um épico – chamado de Saga – para features geralmente
mais complexas. Bacana?
Foram selecionados os itens? Ok! Agora a Equipe Scrum definirá uma meta para a
sprint que será o guia para a Equipe de Desenvolvimento sobre o que estará sendo
desenvolvido durante a Sprint. Na segunda parte, a Equipe de Desenvolvimento
decide como irá transformar os itens selecionados em um incremento durante a
Sprint e desenvolve o Sprint Backlog. Por falar nisso...
Qual a diferença entre Product e Sprint Backlog? O primeiro é uma lista de todos os
requisitos/funcionalidades de usuário levantados até o momento e mantidas pelo
Product Owner, que pode alterá-las a qualquer momento. O segundo é um
subconjunto do primeiro transformado em uma lista de tarefas técnicas e mantidas
pela Equipe de Desenvolvimento, que pode alterá-las a qualquer momento.
No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de

explicar ao Product Owner e ao Scrum Master como pretende trabalhar como
16712855225
equipe auto-organizada para completar o objetivo da Sprint e criar o incremento

previsto. Com o Sprint Backlog criado, define-se a meta da sprint, que nada mais é
que um objetivo definido para ser satisfeito ao final da sprint.
O Product Owner pode estar presente durante a segunda parte da reunião para
clarificar itens do Backlog do Produto. A Reunião Diária (Máximo de 15 minutos) é
um evento que busca criar um plano para as próximas 24 horas e inspecionar o
trabalho desde a última Reunião Diária. Deve ocorrer sempre no mesmo horário e
local (Em pé? Não é obrigatório!), e cada integrante deve responder três perguntas:

1. O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da

Sprint?
2. O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da

Sprint?
3. Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no

atendimento da meta da Sprint?
Reuniões Diárias melhoram a comunicação entre os integrantes, eliminam a

necessidade de outras reuniões, identificam e removem impedimentos, destacam e
promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento da
Equipe. Apesar de poder contar com a presença de outras partes, essa é uma
reunião da equipe de desenvolvimento para a equipe de desenvolvimento.
No final da sprint, ocorre a Revisão da Sprint (Proporcional a 4 horas). Embora seja

utilizada para demonstrar as novas funcionalidades durante a sprint, seu principal
motivo é o de inspecionar o que a equipe de desenvolvimento produziu e colher
opiniões e impressões dos presentes para, caso seja necessário, adaptar o plano
para a sprint seguinte. O foco é aprimorar o produto!
16712855225
Vocês se lembram do filme O Gladiador? Pois é! A Revisão da Sprint é o momento

em que o Product Owner valida () ou não () a sprint, de acordo com a meta que
tenha sido acordada com a equipe de desenvolvimento durante a reunião de
planejamento da sprint. Discute-se os problemas e as soluções e, após a
demonstração do incremento, respondem-se quaisquer dúvidas dos presentes.
A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team

inspecionar a si próprio e criar um plano de melhorias para a próxima sprint. Ela
inspeciona como foi a última sprint em relação às pessoas, às relações, aos

processos e às ferramentas. Pode identificar e ordenar os itens que se tornaram

potenciais de melhorias e cria um plano para implementar melhorias no trabalho.
16712855225

SCRUM: ARTEFATOS
Segundo o Guia do Scrum, o framework possui apenas três artefatos oficiais: Product
Backlog, Sprint Backlog e o Product Increment.
 Product Backlog:
Antes de tudo, o que é um backlog? O backlog é uma lista, um resumo histórico, de

acumulação de trabalho num determinado período de tempo, pode ser uma pilha
de pedidos que devem ser produzidos. Já o Product Backlog é uma lista ordenada
(por valor, risco, prioridade, entre outros) criada pelo Time Scrum de requisitos ou
funcionalidades que o produto deve conter.
É a origem única dos requisitos para qualquer mudança a ser feita no produto.
Costuma-se dizer que ele é um artefato dinâmico que nunca estará completo e
existirá enquanto o produto também existir. Por que? Porque sempre haverá novos
requisitos, novas necessidades e mudanças a serem incorporadas. Logo, ele é um
artefato vivo – sempre em movimento.
O Product Backlog evolui tanto quanto o produto e o ambiente no qual ele será
utilizado evoluem. Ele muda constantemente para identificar o que o produto
necessita para ser mais apropriado, competitivo e útil. Lembrando que somente o
Product Owner pode inserir, remover ou reordenar esses itens, incluindo seu
conteúdo, disponibilidade e ordenação.
Rafael Prikladnicki afirma que o formato mais utilizado para os itens são Estórias de
Usuário (User Stories) ordenadas de acordo com o critério escolhido pelo Product
Owner. Em geral, itens mais importantes ficam no topo e são implementados
primeiro. Na maioria das vezes, esses são os itens sobre os quais há maior
16712855225
conhecimento, logo são mais detalhados e refinados.
Itens que precisem de maior refinamento geralmente têm uma importância menor
e ficam mais abaixo. Não existe, no entanto, uma forma única para materializar esse
artefato e descrever seus itens. Além das Estórias de Usuário, podem ser utilizadas
descrições textuais de funcionalidades, cenários de casos de uso ou mesmo a técnica
que emergir para aquele projeto.
O Product Backlog apresenta itens de negócio (ou funcionais), itens não-funcionais,

itens arquiteturais e itens de infraestrutura. Também pode conter itens que
representem riscos a serem removidos. Durante o andamento do projeto, algumas

funcionalidades podem acabar perdendo a importância – não importando sob quais

circunstâncias isso ocorreu.
Isso é normal na maioria dos projetos, uma vez que é impossível saber, desde o
início, os detalhes de tudo o que queremos no produto. Assim, algumas
funcionalidades podem acabar até mesmo desaparecendo. Da mesma forma, novas
funcionalidades também podem ser adicionadas, de acordo com a necessidade.
Vejam o exemplo retirado do livro Métodos Ágeis para Desenvolvimento de Software:
Um detalhe importante quanto aos itens do Product Backlog é quando o item é

considerado como pronto para ser trabalhado (ou readiness Para que um item
possa ser incluído em um sprint, ele deve ser pequeno o suficiente para que caiba
em uma única sprint e deve deixar claro quanto a expectativa do Product Owner
(geralmente através de um critério de aceite).
Mas até que ponto estes requisitos precisam ser detalhados? Eles devem ser
16712855225
detalhados até atender o conceito de Definition of Ready (DoR), que significa que o
requisito tem informações suficientes para começar a ser desenvolvido
imediatamente. Esta definição é bastante específica de cada organização – não há
um padrão. Vou dar um exemplo para melhor entendimento...
Já trabalhei em um projeto em que as estórias de usuário eram entregues aos

desenvolvedores de forma muito pobres, pouco refinadas e demasiadamente
confusas. O Product Owner estava rejeitando as sprints declarando que não havia
sido feito o que ele havia pedido. Os desenvolvedores reclamavam que a
especificação era péssima e que nem o próprio Product Owner sabia o que queria.

A partir daí, modificamos nosso processo! A equipe combinou critérios explícitos e

visíveis do que uma estória de usuário deveria conter para ser aceita em uma sprint.
Como diz o ditado, combinado não sai caro! Logo, uma vez que todos haviam
concordado, as brigas reduziram bastante. É bom salientar que, apesar de ser uma
boa prática, não é oficialmente prevista pelo nosso framework.
 Sprint Backlog:
O Sprint Backlog é o conjunto de itens selecionados para serem implementados

durante a sprint mais o plano para transformá-los em um incremento. Assim, ao
final de cada Reunião de Planejamento, um novo Sprint Backlog é criado.
Normalmente, o plano é composto por tarefas técnicas necessárias para transformar
o item em um incremento do produto.
Vamos diferenciar Product Backlog e Sprint Backlog! O primeiro é uma lista

ordenada dos requisitos ou funcionalidades que o software deverá possuir.
segundo é uma lista de tarefas a serem executadas durante uma sprint para atingir
a sua meta. Trata-se do desmembramento de cada item selecionado do Product
Backlog em pequenas tarefas.
O Sprint Backlog torna visível todo o trabalho que o time de desenvolvimento

identifica como necessário para atingir a meta da sprint. Aliás, os membros do time
de desenvolvimento (e somente eles) podem adicionar novas tarefas caso
descubram, no decorrer da sprint, que mais trabalho seja necessário. Da mesma
forma, também podem remover tarefas caso estas se mostrem desnecessárias.
Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante

é atualizada. O Sprint Backlog é altamente visível, uma imagem em tempo real do
16712855225
trabalho que o time de desenvolvimento planeja completar durante a sprint, e

pertence exclusivamente ao time de desenvolvimento. Em qualquer ponto do
tempo na sprint, o total do trabalho remanescente dos itens pode ser somado.
O time de desenvolvimento monitora o total do

trabalho restante pelo menos a cada Reunião Diária.
time de desenvolvimento acompanha estes resumos
diários e projeta a probabilidade de alcançar o objetivo
da sprint. Com o rastreamento do trabalho restante em
toda a sprint, o time de desenvolvimento é capaz de
gerenciar o seu progresso. Vejam um exemplo abaixo...

 Product Increment
Ao final de cada sprint, a equipe de desenvolvimento entrega um incremento do

produto, resultado do que foi produzido durante a sprint. Esse é um dos conceitos
principais do framework e vai ao encontro da sua natureza empírica, já que permite
ao Product Owner perceber o valor do investimento e também vislumbrar outras
possibilidades. Perfeito?
Para a Equipe de Desenvolvimento, é importante entender que o incremento deve

ser algo potencialmente entregável – o cliente pode optar por colocar de imediato
em produção ou não. A equipe, portanto, deve produzir código que tenha
qualidade, e chegamos à Definition of Done (DoD) ou Definição de Pronto. O que
seria isso, professor? Vou explicar...16712855225
Pronto significa pronto mesmo! Quando uma equipe ágil diz que uma
funcionalidade está pronta, isso significa que não tem aquele “veja bem…” ou “só
falta uma coisinha, mas já está pronto…”. O DoD é um acordo formal que define
claramente quais são os passos mínimos para a conclusão de um item ou
funcionalidade potencialmente entregável.
Serve, mais ou menos, como um contrato entre a Equipe de Desenvolvimento e o

Product Owner, garantindo que todo produto gerado pelo projeto estará dentro
dos padrões de qualidade estabelecidos anteriormente. Vocês se lembram que a

Definition of Ready (DoR) é um checklist de critérios acordados para que a equipe

de desenvolvimento possa aceitar um requisito.
Aqui acontece exatamente o contrário: Definition of Done (DoD) é um checklist de

critérios acordados para que o Product Owner possa aceitar uma funcionalidade.
Ambos tratam de critérios de aceite, mas o primeiro trata do aceite dos requisitos
pela equipe de desenvolvimento e o segundo trata do aceite das funcionalidades
pelo dono do produto. Ficou bem tranquilo de entender agora, eu suponho.
Toda o Time Scrum deve entender o que significa um “pronto”. Uma funcionalidade
só é considerada pronta se tiver passado por todas as etapas definidas pela equipe
de desenvolvimento Uma funcionalidade que não esteja pronta ao final da sprint
deve retornar ao Product Backlog para que seja incluída em uma próxima sprint.
Esse critério é bastante específico, cada um escolhe o seu!
Por outro lado, é uma boa prática revisar essa definição a cada sprint. Ele pode
mudar ao longo do tempo. O amadurecimento organizacional e a habilidade do
time de resolver impedimentos podem fazer com que alguns itens sejam
acrescentados. Diferentemente do Definition of Ready, é imperativo haver um
Definition of Done. Compreenderam?
16712855225

Podemos citar outros artefatos, tais como: Gráfico Burndown, que torna visível a
evolução diária do trabalho da equipe de desenvolvimento, na medida em que
mostra a comparação entre o trabalho estimado inicialmente com a quantidade
restante estimada de trabalho. Via de regra, as unidades utilizadas são de esforço
(em horas) planejado pelo tempo decorrido.
Por fim, é salutar enfatizar que o ciclo de vida do nosso framework é baseado em
16712855225
três fases principais:
1) Pré-Planejamento (Pre-game Phase):
Define o sistema sendo desenvolvido. Cria-se o Product Backlog, que contém todos
os requisitos atuais e informações sobre o planejamento do projeto. Cria-se também
uma arquitetura de alto nível.
2) Desenvolvimento (Game Phase):

O sistema é desenvolvido em sprints, por meio de uma abordagem iterativa. A cada

sprint, novas funcionalidades são adicionadas de modo tradicional, i.e., análise,
projeto, implementação, etc.
3) Pós-Planejamento (Post-game Phase):
Após a fase de desenvolvimento são feitas reuniões para analisar o progresso do

projeto e demonstrar o software atual para os clientes. Aqui são feitas as etapas de
integração, testes finais e documentação.
16712855225

(CESPE - 2013 - ANP - Analista Administrativo - Área 5) De acordo com a

metodologia Scrum, a constituição ideal da equipe de desenvolvimento para que
o trabalho se mantenha ágil deve ser de menos de três pessoas.
Comentários:
Em suma, a equipe deve ter entre 3 e 9 integrantes, de modo que não seja pequena
demais que haja restrições de habilidades nem grande demais que seja complicado
de gerenciar. Vou dizer de novo: não confundam Equipe de Desenvolvimento
(Development Team) com Equipe Scrum (Scrum Team)! O PO e SM não são incluídos
nesta contagem, a menos que também façam parte do DT.
Na verdade, recomenda-se entre três e nove participantes. Com menos de três

participantes, reduz-se a interação, que gera um menor ganho de produtividade.
Gabarito: E
(CESPE - 2012 - ANAC - Analista Administrativo - Área 4) O único papel definido

pelo Scrum com autoridade para cancelar uma Sprint é o do product owner.
Comentários:
Ninguém tem permissão para falar com o Time de Desenvolvimento sobre

16712855225
diferentes configurações de prioridade, e o Time de Desenvolvimento não tem

permissão para agir sobre o que outras pessoas disserem. Time de
Desenvolvimento só responde ao Product Owner. Além disso, só ele pode cancelar
uma sprint. Perfeito?
De fato, apenas o Product Owner pode cancelar uma sprint.
Gabarito: C
(CESPE - 2012 - ANAC - Analista Administrativo - Área 4) Uma sprint do Scrum

tem duração prevista de 2 meses.

Comentários:
Prossigamos para as cerimônias oficiais! Os Eventos Scrum são eventos time-boxed

(isto é, com duração máxima predefinida) usados para criar uma rotina e minimizar
a necessidade de reuniões não definidas pelo Scrum. Lembrem-se de que a Sprint
tem um mês ou menos (em geral, duas a quatro semanas) e é iniciada imediatamente
após a conclusão da sprint anterior.
O Scrum fala que a Sprint deve ter um mês ou menos. Em geral, deve ter entre duas
e quarto semanas.
Gabarito: E
(CESPE - 2010 - Banco da Amazônia - Técnico Científico - Arquitetura de

Tecnologia) O Scrum é utilizado, como função primária, para o gerenciamento
de projetos de desenvolvimento de software, mas também tem sido usado como
extreme programming e outras metodologias de desenvolvimento.
Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um
grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum.
Comentários:
Questão perfeita! Scrum está para o PMBOK assim como o XP está para o RUP. Ele
pode ser utilizado, em teoria, em qualquer contexto em que se necessite atingir um
objetivo comum entre um grupo de pessoas.
Gabarito: C
16712855225
(CESPE - 2013 - ANTT - Analista Administrativo – Analista de Sistemas) Entre os

vários papéis do SCRUM, o product owner é a única pessoa responsável por
gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
Comentários:
Literalmente retirado do Guia Scrum! O PO é o mandachuva que gerencia o Product

Backlog e é responsável por maximizar o valor do produto e do trabalho da equipe
de desenvolvimento.

Gabarito: C
(CESPE - 2013 - SERPRO - Analista de Informática – Analista de Sistemas) Scrum

é um processo de desenvolvimento que tem como ponto de partida um
conjunto de requisitos bem definidos.
Comentários:
Conjunto de requisitos bem definidos? Não, o ponto de partida são requisitos pouco
definidos. Ao longo das cerimônias, melhora-se a definição dos requisitos. Se os
requisitos fossem bem definidos, o Product Backlog seria quase imutável e não é
isso que nós verificamos.
Gabarito: E
(CESPE - 2013 – TCE-RO - Analista de Informática – Analista de Sistemas) Na

metodologia Scrum, a equipe trabalha nos processos e não há cargos na equipe.
Como um dos papéis necessários, o Scrum Master deve garantir que o processo
seja entendido e atuar como facilitador para ajudar a equipe.
Comentários:
É exatamente isso! Lembrem-se de que não há cargos, mas papéis!
Gabarito: C
(CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) Em um

projeto gerido com a metodologia Scrum, um produto estará, ao final de cada
sprint, completamente testado, estando 100% completos todos os requisitos do
16712855225
product backlog.
Comentários:
Galera, nenhum produto estará nunca completamente testado, ademais o Product

Backlog também nunca estará completo.
Gabarito: E

(CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) O escopo,

a importância e a estimativa de um Sprint do Scrum são definidos pelo product
owner.
Comentários:
Opaaaa... Product Owner não trata de estimativas. Entendam: escopo e importância

são definidos pelo PO, no entanto quem define estimativas é a Equipe de
Desenvolvimento.
Gabarito: E
10. (CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) A

metodologia Scrum, ágil para gerência de projetos, baseia-se em ciclos de 30
dias, denominados sprints, em que se trabalha para alcançar objetivos bem
definidos.
Comentários:
Scrum é uma metodologia ágil para gerência de projetos? Sim. Baseia-se em ciclos
de 30 dias denominados sprints? Sim, o ideal seria a questão ter falado de duas a
quatro semanas, mas podemos relevar! Nas sprints, trabalha-se para alcançar
objetivos bem definidos? Sim, temos a meta da Sprint que deve ser alcançada.
Gabarito: C
11. (CESPE - 2011 – ECT - Analista de Informática – Analista de Sistemas) Para que
se obtenha sucesso na utilização do Scrum, o cliente deve se tornar parte da
equipe de desenvolvimento do software, participando diretamente do processo.
16712855225
Comentários:
Bem, o cliente não se torna parte da equipe de desenvolvimento. Há – sim – uma

forte integração, no entanto dizer que faz parte da equipe de desenvolvimento é
um completo absurdo. No entanto, o CESPE não entendeu dessa maneira.
Gabarito: C
12. (CESPE - 2011 – MEC - Analista de Informática – Analista de Sistemas) O

framework scrum engloba conceitos como times scrum, eventos com duração

fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração
fixa: a reunião de planejamento da versão para entrega, a sprint, a reunião diária,
a revisão da sprint e a retrospectiva da sprint.
Comentários:
Cara, a questão peca um pouco em dizer que é um evento com duração fixa. Por
que, professor? Porque o conceito de time-box é aquilo que tem uma duração
máxima fixa (Ex: Sprint <= 30 dias). Eu entendo que caberia recurso nessa questão.
Gabarito: C
13. (CESPE - 2011 – MEC - Analista de Informática – Analista de Sistemas) Produto

da metodologia Scrum, o documento product backlog contém os requisitos
definidos a partir da visão do cliente e é utilizado novamente no final do sprint
para revisão ou modificações dos requisitos inicialmente definidos.
Comentários:
Galera, nós temos o Documento de Visão, partimos para o Product Backlog e depois
para o Sprint Backlog. No final da Sprint, durante a cerimônia de Revisão da Sprint,
verifica-se se o que foi feito está de acordo com o que foi definido.
Gabarito: C
14. (CESPE - 2010 – MPU - Analista de Informática – Analista de Sistemas) Um

princípio chave do Scrum é o reconhecimento de que desafios
fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-
se uma abordagem tradicional de controle. O Scrum adota uma abordagem
16712855225
empírica, aceitando que o problema não pode ser totalmente entendido ou

definido, focando na maximização da habilidade da equipe de responder de
forma ágil aos desafios emergentes.
Comentários:
O Scrum é um framework em que podem ser empregados vários processos e técnicas.

Pode ser definido como um conjunto de papéis, eventos, artefatos e regras associadas
a uma equipe. Ele é fundamentado em teorias empíricas de controle de processo e
emprega uma abordagem iterativa e incremental (maximizando as oportunidades de
feedback) para aperfeiçoar a previsão e controle de riscos.

Questão perfeita, retirada do Guia Scrum! Foco no empirismo, compreendendo que

não se pode entender e prever absolutamente tudo em um processo!
Gabarito: C
15. (CESPE - 2010 – MPU - Analista de Informática – Analista de Sistemas) A

metodologia Scrum é facilitada por um scrum master, que atua como um
mediador entre a equipe e qualquer influência desestabilizadora, além de
assegurar que a equipe esteja utilizando corretamente as práticas de Scrum,
motivando e mantendo o foco na meta da sprint.
Comentários:
Conforme vimos em aula, a questão está perfeita! O Scrum Master é o cara

responsável por todas essas atividades: ele media conflitos; ensina as práticas
corretas; busca manter o foco na meta da Sprint.
Gabarito: C
16. (CESPE - 2012 – TER-RJ - Analista de Informática – Analista de Sistemas) A

metodologia scrum prega que a equipe complete e entregue partes do produto
final constantemente ao final de cada interação. Essa interação deve ser curta e
possuir tempo de execução definido previamente.
Comentários:
Já li isso 800x e as bancas continuam errando! Escreve-se ITERAÇÃO e, não,

INTERAÇÃO! A questão deveria ter sido anulada, mas não foi! De todo modo, se
16712855225
ignorarmos a palavra, a questão está correta. Recomenda-se sempre a entrega de

um incremento; a interação deve ser curta (2 a 4 semanas); possuir tempo de
execução definido, i.e., time-boxed.
Gabarito: C
17. (CESPE - 2013 – ANCINE – Analista de Sistemas) Na reunião de planejamento do

sprint backlog, se o product owner afirmar que todos os requisitos do produto
foram identificados, é correto concluir que o backlog do produto está completo,
visto que este é uma lista ordenada de todos os requisitos necessários para o
desenvolvimento do produto.

Comentários:
Galera, é correto concluir que o backlog do produto está completo? Não! O Product
Backlog nunca está completo, pois os requisitos estão sempre mudando.
Gabarito: E
18. (CESPE - 2013 – ANCINE – Analista de Sistemas) Se for averiguado, em uma

organização, que o Scrum Master gerencia o backlog do produto, é correto
afirmar que houve falha na execução de papéis, visto que cabe unicamente ao
product owner gerenciar o backlog do produto.
Comentários:
Perfeito! Somente o Product Owner pode gerenciar o Product Backlog. Aí um aluno,

certa vez, me colocou em uma sinuca de bico: “Professor, no Scrum Guide fala que
o P.O pode delegar essa função a qualquer membro do Scrum ou de fora”.
Ele pode, sim, delegar a função ao Scrum Master. Quando ele o faz, o Scrum Master
passa a ser PO (quando está fazendo o papel de PO) e Scrum Master (quando está
fazendo o papel de Scrum Master). Em outras palavras, o PO continua gerenciando
o Backlog do Produto! Se o Scrum Master (quando estiver fazendo papel de Scrum
Master) gerenciar o backlog do produto, isso é uma falha na execução dos papeis.
Deve-se dissociar o papel da pessoa e a pessoa dos papeis.
Gabarito: C
19. (CESPE - 2010 – MPU – Analista de Sistemas) Scrum é um processo ágil de

16712855225
produção de software que mantém o foco na entrega da maior parte do

produto, no menor tempo possível.
Comentários:
Galera, essa questão é polêmica! O Scrum preconiza que se entregue primeiro as

funcionalidades mais importantes (coincidentemente, as mais importantes podem
representar a maior parte, mas não necessariamente). Ademais, a questão dá a
entender que o Scrum busca entregas rápidas e, não, ágeis. Portanto, em minha
opinião está incorreta. No entanto, o gabarito oficial foi verdadeiro.

barito: C
(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e

Manutenção de Sistemas) No Scrum, o Product Owner (PO) é responsável por
definir a visão do produto e remover os impedimentos, enquanto o Scrum
Master (SM) é responsável por elaborar e manter o Product Backlog, bem como
por ajudar o PO a executar suas atividades diárias.
Comentários:
Os papeis estão invertidos, i.e., PO elabora e mantém o Product Backlog e define a

visão do produto. Já o SM remove impedimentos e auxilia o PO a executar suas
atividades diárias.
Gabarito: E
21. (CESPE - 2013 - ANP - Analista Administrativo - Área 5) O ciclo de vida da

metodologia Scrum se divide nas fases de pré-planejamento, desenvolvimento
e pós-planejamento. O documento denominado product backlog é gerado na
fase de desenvolvimento.
Comentários:
Na verdade, é na fase de Pré-Planejamento.
Gabarito: E
(CESPE - 2012 - TCE-ES - Auditor de Controle Externo - Tecnologia da

Informação) O Product Backlog, um dos artefatos utilizados na metodologia ágil
16712855225
denominada Scrum, constitui-se da lista priorizada de todos os requisitos do

produto final.
Comentários:
Sprint Backlog contém a lista de requisitos da sprint e o Product Backlog contém

todos os requisitos do produto final. Apesar do “todos”, está correta! Quando
dizemos que o Product Backlog nunca está completo, é porque ele é dinâmico –
ele muda!

No início, ele será pequeno, com o passar do tempo ele vai aumentando,
eventualmente diminuindo, e assim por diante. Em determinado momento,
provavelmente na última sprint, ele conterá todos os requisitos do produto final.
Gabarito: C
(CESPE - 2014 – ANATEL – Arquitetura de Soluções) O Scrum é um conjunto

simples e eficaz de regras e ferramentas que são utilizadas para maximizar
resultados. O ScrumMaster exerce o papel de facilitador e motivador da equipe,
além de garantir que as regras e as ferramentas sejam utilizadas com vistas à
criatividade do trabalho e ao retorno do investimento.
Comentários:
RESPONSABILIDADES E CARACTERÍSTICAS: SCRUM MASTER (SM)

Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para
garantir que o Time Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas
interações com o Time Scrum são úteis e quais não são.
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo
Time Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product
Backlog.
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus
valores estajam sendo seguidos. 16712855225
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo
isso sem o uso de qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar
os problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente,
utilizando técnicas de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar o time de desenvolvimento em autogerenciamento e interdisciplinaridade.
Ele treina o time de desenvolvimento em ambientes organizacionais nos quais o Scrum

não é totalmente adotado e compreendido.
Ele ensina o Time Scrum a criar itens do Product Backlog de forma clara e concisa.

Ele auxilia o PO na comunicação clara da visão, objetivo e itens do Product Backlog para
o time de desenvolvimento.
Conforme vimos em aula, ele é – de fato – o facilitador e motivador da equipe; ele

realmente garante que as regras e ferramentas sejam utilizadas para alcançar a
criatividade do trabalho e o retorno do investimento. A questão peca apenas em
um ponto: não se definem ferramentas. Scrum não utiliza ferramentas, professor?
Não foi isso que eu disse! Ele utiliza ferramentas, mas não se prescrevem quais
ferramentas devem ser utilizadas. Dessa forma, quando a segunda parte da questão
cita as ferramentas, está correta; mas na primeira parte da questão, está errado –
Scrum não é um conjunto de regras e ferramentas: “This Guide contains the definition
of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that
bind them together”.
Gabarito: C
24. (CESPE - - TCU – Analista de Sistemas Conforme a metodologia SCRUM,

Sprint Planning Meeting é uma reunião de planejamento em que o Scrum Master
prioriza os itens do Product Backlog e a equipe seleciona as atividades a serem
implementadas no período.
Comentários:
RESPONSABILIDADES E CARACTERÍSTICAS: PRODUCT OWNER (PO)

Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho da equipe de

16712855225
desenvolvimento, sendo o único que pode gerenciar o Product Backlog.

Ele pode até delegar as atividades de gerenciamento para o time de desenvolvimento,
mas ainda será considerado o responsável pelos trabalhos.
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que
serão implementados.
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre
Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.

Ele é responsável por garantir que o Backlog do Produto seja visível, transparente,
claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir.
Ele é responsável por garantir que o Time de Desenvolvimento entenda os itens do Product
Backlog no nível necessário.
Conforme vimos em aula, trata-se do Product Owner (PO) e, não, o Scrum Master
(SM). Vimos em aula que o Scrum Master comunica os itens à equipe, mas quem
prioriza é o PO.
Gabarito: E
ACERTEI ERREI
16712855225

(FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software) Um

dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software é a implantação de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco
previsíveis. Para tanto, o gerenciamento é distribuído por meio de três agentes
independentes que são:
a) Product Owner, Scrum Team e Scrum Master.

b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.
Comentários:
Guia Scrum diz que o Scrum Team é dividido em Product Owner, Scrum Master e
Development Team. No entanto, a FCC deu a resposta como correto. Por que? Não
faço ideia! =(
Gabarito: A
(FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte Os

16712855225
princípios Scrum são usados para guiar as atividades de desenvolvimento dentro

de um processo que incorpora as seguintes atividades de arcabouço: requisitos,
análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas
de trabalho ocorrem dentro de um padrão de processo chamado:
a) pendência.
b) iterator.
c) demo.
d) história de usuário.
e) sprint.

Comentários:
Conforme vimos em aula, trata-se de uma Sprint.
Gabarito: E
(FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação

Na fase de desenvolvimento do Scrum, o software é desenvolvido em processos
iterativos denominados:
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.
Comentários:
Conforme vimos em aula, trata-se também de uma Sprint.
Gabarito: C
(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas) Em

reunião, toda conversação é restringida às respostas dos elementos às perguntas
colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até
a próxima reunião?"
As Scrum meetings ocorrem:

16712855225
a) sempre que necessário.

b) ocasionalmente.
c) uma vez por semana.
d) duas vezes por semana.
e) diariamente.
Comentários:
Conforme vimos em aula, essa é uma das três perguntas feitas pelo Scrum Master
e a Scrum Meeting citada é a Daily Scrum Meeting ou Reunião Diária.

Gabarito: E
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI - A) Em relação às

regras do Scrum, é INCORRETO afirmar:
a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe
de trabalho não superior a 10 pessoas.
b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar

um novo Sprint, baseando num novo Sprint Backlog.
c) As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no

mesmo local e não devem durar mais que 30 minutos.
d) Toda conversação restringe as respostas dos participantes às três perguntas

do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades
encontrou durante o seu trabalho? O que planeja desenvolver até a próxima
reunião?
e) Com base nas respostas às três perguntas, o Scrum Master deve

imediatamente tomar decisões, quando necessárias, para remover todas as
situações que impeçam a agilidade do trabalho.
Comentários:
(a) Conforme vimos em aula, o período máximo é de 30 dias e a equipe de trabalho

varia de 3 a 9 pessoas; (b) Na verdade, não é correto! É possível dissolver uma sprint
e começar outra baseando-se em um no sprint backlog – quem pode fazer isso é o
Product Owner; (c) Essa questão foi MUITO POLÊMICA e eu acho ela sacanagem
16712855225
péssima! A Daily Scrum deve ter no máximo 15 minutos? Sim, mas a questão apenas
afirma que ela não deve durar mais que 30 minutos. Se ela dura no máximo 15
minutos, ela não dura mais que 30 minutos. Bem, eu não estou dizendo que
concordo com esse raciocínio! É o tipo de coisa que não se cobra em prova para
não dar polêmica, mas a FCC é mestre em cometer esses vacilos! Sendo bastante
estrito no julgamento, o item não está errado, mas isso prejudica quem estudou e
sabe que a reunião tem no máximo 15 minutos; (d) Na verdade, não é incorreto!
Essas são, de fato, as perguntas a serem feitas; (e) Também não é incorreto! É
exatamente isso que o Scrum Master deve fazer.
Gabarito: A

(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas) No

contexto das regras do SCRUM, é correto afirmar:
a) Durante a realização do Sprint, o Backlog pode ser modificado por qualquer

um dos elementos da equipe, desde que acordado nas reuniões semanais.
b) O Sprint deve ser realizado num período não superior a 30 dias e ter um
objetivo bem claro, baseado no Backlog.
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar

necessário, em qualquer momento no decorrer do Sprint.
d) Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um

rumo não desejável, novas funcionalidades devem ser implementadas para
garantir o prazo do projeto.
e) O foco na produtividade se estende às Scrum meetings e a conversação é

pautada em discussões por toda a equipe.
Comentários:
(a) Backlog? Qual Backlog? Da Sprint? Do Produto? A questão deveria ter dito! De
todo modo, o Product Backlog só pode ser modificado pelo Product Owner e o
Sprint Backlog só pode ser modificado pelo Development Team (em termos de
atividades e, não, objetivos); (b) Perfeito, é isso mesmo! (c) Scrum Master é apenas
um facilitador! Quem pode modificar o Product Backlog é o Product Owner; (d)
Não. É possível, sim, dissolver uma sprint; (e) Na verdade, as discussões ocorrem
mais entre as pessoas da equipe de desenvolvimento.
16712855225
Gabarito: B
(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas - B) No

SCRUM, o produto final, a data final e o custo do projeto são determinados ao
longo do projeto.
Comentários:
É isso mesmo – são todos definidos ao longo do projeto!

Gabarito: C
(FCC - – AFR/SP – Analista de Sistemas O conceito de sprint aplica-se ao

modelo ágil do processo de engenharia de software denominado:
a) Crystal.
b) XP.
c) DAS.
d) DSDM.
e) Scrum
Comentários:
Sprint? Trata-se do Scrum!
Gabarito: E
(FCC - – TRE/CE – Analista de Sistemas No SCRUM, sprint é:
a) um representante dos stakeholders e do negócio.
b) uma lista de requisitos que tipicamente vêm do cliente.
c) uma lista de itens priorizados a serem desenvolvidos para um software.
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software

pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.

16712855225
Comentários:
(a) Isso é o Product Owner; (b) Isso é o Product Backlog; (c) Isso é o Product Backlog;
(d) Isso, de fato, é uma sprint; (e) Isso é o Product Backlog.
Gabarito: D
10. (FCC - – TRT/SC – Analista de Sistemas SCRUM é um framework baseado

no modelo ágil. No SCRUM,

a) o scrum team é a equipe de desenvolvimento, necessariamente dividida em

papéis como analista, designer e programador. Em geral o scrum team tem de
10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou

histórias de usuários) são mantidas em uma lista chamada de scrum board.
c) o scrum master é um gerente no sentido dos modelos prescritivos. É um líder,

um facilitador e um solucionador de conflitos. É ele quem decide quais requisitos
são mais importantes.
d) um dos conceitos mais importantes é o sprint , que consiste em um ciclo de

desenvolvimento que, em geral, tem duração de 4 a 7 dias.
e) o product owner tem, entre outras atribuições, a de indicar quais são os

requisitos mais importantes a serem tratados em cada sprint . É responsável por
conhecer e avaliar as necessidades dos clientes.
Comentários:
(a) Esse é o Development Team, que não é dividido em papéis (é multifuncional) e

tem entre 3 e 9 pessoas; (b) Na verdade, são mantidas em uma lista chamada
Product Backlog; (c) Na verdade, quem decide os requisitos mais importantes é o
Product Owner; (d) Em geral, duração de 2 a 4 semanas; (e) Perfeito, é exatamente
isso.
Gabarito: E
11. (FCC - – TCE/SE – Analista de Sistemas) Aceita a imprevisibilidade do

16712855225
desenvolvimento de software e a contorna através da adaptação constante.

Destaca-se das demais metodologias ágeis por dar mais enfoque à área de
gerenciamento. Seu nome tem origem em um esporte quando jogadores de
cada time colaboram entre si numa tentativa de avançar juntos pelo campo
adversário. Tais características estão presentes no processo:
a) UP.
b) Crystal.
c) XP.
d) DSDM.
e) Scrum.

Comentários:
Galera, qual a palavra-chave para descobrir a opção correta? A questão falou em

gerenciamento. Claro, depois fica mais fácil ainda quando fala que o nome é
inspirado em um esporte!
Gabarito: E
12. (FCC - – DPE/SP – Analista de Sistemas) Na engenharia de software, um

processo iterativo denominado sprint, que segue o ciclo PDCA para entregar,
num período de 30 dias aproximadamente, um incremento do software pronto,
caracteriza a metodologia ágil:
a) SCRUM.
b) DSDM.
c) Crystal.
d) FDD.
e) XP.
Comentários:
Galera, qual a palavra-chave para descobrir a opção correta? A questão falou em

gerenciamento. Claro, depois fica mais fácil ainda quando fala que o nome é
inspirado em um esporte!
Gabarito: E
13. (FCC - – TRE- – Analista de Sistemas) Analise o texto:

16712855225
O Scrum enfatiza o uso de um conjunto de padrões de processos de software que

provaram ser eficazes para projetos com prazo de entrega apertados, requisitos
mutáveis e críticos de negócio. Cada um desses padrões de processos define um
conjunto de ações de desenvolvimento. Uma dessas ações consiste em manter
uma lista com prioridades dos requisitos ou funcionalidades do projeto que
fornecem valor comercial ao cliente. Os itens podem ser adicionados a esse
registro em qualquer momento. O gerente de produto avalia o registro e atualiza
as prioridades conforme requisitado.
A lista citada no texto é conhecida como:

a) urgências scrum.
b) registro ágil de requisitos.
c) alterações scrum.
d) registro pendente de trabalhos (Backlog).
e) registro iterativo de desenvolvimento (sprint).
Comentários:
Galera, isso é coisa do Pressman! Ele afirma: “O Registro Pendente de Trabalhos

(Backlog) consiste em uma lista com prioridades dos requisitos ou funcionalidades do
projeto que fornecem valo comercial ao cliente. Os itens podem ser adicionados a
esse registro em qualquer momento (é assim que as alterações são introduzidas). O
gerente do produto avalia o registro e atualiza as prioridades conforme requisitado”.
Gabarito: D
14. (FCC - – TRT/MG – Analista de Sistemas) Com relação ao Scrum, considere:
I. O Product Owner, ou dono do produto, é responsável por garantir que o

Scrum seja entendido e aplicado. Faz isso para garantir que o Time Scrum adere
à teoria, práticas e regras do Scrum. É um servo-líder para o Time Scrum.
II. O Scrum Master é o responsável por maximizar o valor do produto e do

trabalho do Time de Desenvolvimento. Como isso é feito pode variar
amplamente nas organizações, Times Scrum e indivíduos.
III. O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante

o qual um “Pronto", versão incremental potencialmente utilizável do produto, é
16712855225
criado.
Está correto o que consta APENAS em:
a) I e II.
b) III
c) II e III.
d) II.
e) I e III.
Comentários:

(I) Na verdade, o item trata do Scrum Master; (II) Na verdade, essa é uma
responsabilidade do Product Owner; (III) Perfeito, é exatamente isso!
Gabarito: B
15. (FCC - – TRT/RS – Analista de Sistemas) No Scrum, a lista de funcionalidades

a serem implementadas em cada projeto que apresenta uma visão dos requisitos
de forma mais voltada à maneira como a equipe vai desenvolvê-los, e não em
uma visão de alto nível voltada às necessidades diretas do cliente, é conhecida
como:
a) product backlog.
b) scrum backlog.
c) sprint backlog.
d) daily backlog.
e) daily sprint.
Comentários:
Opa, observem que a questão fala que não é uma lista de alto nível, i.e., é uma lista
mais detalhada. Portanto, estamos falando de... Sprint Backlog.
Gabarito: C
16. (FCC - – TRF/2 – Analista de Sistemas) Segundo Roger S. Pressman, em seu

livro Engenharia de Software, 7a edição, os princípios do Scrum são consistentes
com o manifesto ágil e são usados para orientar as atividades de
desenvolvimento dentro de um processo que incorpora as atividades estruturais
16712855225
de requisitos, análise, projeto, evolução e entrega. Em cada atividade

metodológica, ocorrem tarefas a realizar dentro de um padrão de processo
chamado:
a) process backlog.
b) scrum master.
c) product owner.
d) backlog.
e) sprint.
Comentários:

Ficou fácil, não? Esse padrão de projeto é a Sprint!
Gabarito: E
17. (FCC - – AL/PE – Analista de Sistemas) O Scrum define reuniões e eventos

que devem ser realizados de forma a oferecer oportunidades formais para
inspeção e adaptação, cujos tempos de duração são referenciais máximos
recomendados. Considere:
I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog

do Produto, se necessário.
II. É uma reunião time-boxed de 3 horas para uma Sprint de um mês, sendo uma
oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para
melhorias a serem aplicadas na próxima Sprint.
III. É um evento time-boxed de 15 minutos, para que a Equipe de

Desenvolvimento possa sincronizar as atividades e criar um plano para as
próximas 24 horas.
IV. É um time-box de 8 horas para uma Sprint de um mês de duração.
Estão de acordo com as definições I, II, III e IV, respectivamente, as

denominações:
a) planejamento da Sprint - revisão da Sprint - daily Scrum - retrospectiva da

Sprint.
b) revisão da Sprint - retrospectiva da Sprint - daily Scrum - planejamento da
16712855225
Sprint.
c) revisão da Sprint - planejamento da Sprint - 15 min break - retrospectiva da
Sprint.
d) retrospectiva da Sprint - planejamento da Sprint - short meeting - revisão da
Sprint.
e) planejamento da Sprint - retrospectiva da Sprint - daily Scrum - revisão da
Sprint.
Comentários:

(I) Trata-se da Revisão da Sprint; (II) Trata-se da Retrospectiva da Sprint; (III) Trata-
se da Daily Scrum; (IV) Trata-se do Planejamento da Sprint.
Gabarito: B
ACERTEI ERREI
16712855225

(ESAF - 2012 – CGU – Analista de Sistemas) No Scrum os projetos são divididos

em ciclos chamados de:
a) Sp-Cycles.
b) Springs.
c) Sprints.
d) Strengths.
e) Set-prints.
Comentários:
O Scrum realiza ciclos completos de desenvolvimento de duração fixa em que, ao

final, temos incrementos potencialmente entregáveis do produto. O nome desses
ciclos de desenvolvimento é Sprint! Ela tem duração de até um mês, permitindo
feedbacks constantes quanto ao que está sendo desenvolvido. A Sprint é como um
contêiner para todos os outros eventos e cerimônias que veremos à frente.
Conforme vimos em aula, os ciclos são chamados de sprints.
Gabarito: C
ACERTEI 16712855225
ERREI

EXTREME PROGRAMMING (XP)
Em 1996, Kent Beck desenvolveu um novo paradigma de

desenvolvimento de software que rompia com grande parte
das metodologias tradicionais e a batizou de Extreme
Programming. Por que extremo? Porque ele recomenda que
as boas práticas sejam levadas ao extremo! Ahn? Como
assim, professor?
 Testar é bom? Então vamos testar toda hora!

 Iterar é bom? Então vamos iterar toda hora!
 Integrar é bom? Então vamos integrar toda hora!
O XP é uma metodologia ágil de desenvolvimento de software para equipes

pequenas, coesas e multidisciplinares cujos projetos possuem requisitos vagos e em
constante mudança. Ele parte do princípio de que o código-fonte é a melhor
documentação, pois qualquer outra se torna rapidamente desatualizada e perde
sua confiabilidade.
No eXtreme Programming, todos os requisitos são expressos como cenários

(também chamados histórias do usuário), que são implementados diretamente
como uma série de tarefas. Os programadores trabalham em pares e desenvolvem
testes para cada tarefa antes da escrita do código. Sempre que há integração, há
novos testes e o usuário prioriza esses requisitos para o desenvolvimento.
A equipe de desenvolvimento avalia cada cenário e o divide em tarefas. Cada tarefa

representa uma característica discreta do sistema e um teste unitário pode então
16712855225
ser projetado para essa tarefa. Os Testes de Aceitação (ou Testes de Cliente) são
especificados pelo cliente e mantêm o foco nas características e na funcionalidade
do sistema total que são visíveis e que podem ser revistas pelo cliente.
Os testes de aceitação são obtidos de histórias de usuários implementadas como

parte de uma versão de software. O desenvolvimento incremental é apoiado por
pequenos e frequentes releases do sistema e por uma abordagem de descrição de
requisitos baseada nos cenários do cliente. Ademais, o envolvimento do cliente em
tempo integral facilita o desenvolvimento e melhora a qualidade do produto.

Galera, vamos falar um pouquinho mais sobre as histórias de usuário! er Stories

são artefatos de desenvolvimento utilizados em sistemas geridos segundo
metodologias ágeis. Nós podemos dizer que são uma descrição resumida de
alguma funcionalidade fornecida pelo sistema do ponto de vista de um usuário
desse sistema.
Uma História de Usuário representa uma pequena parte da funcionalidade do

sistema a ser construído. Não se trata de uma especificação completa de uma
funcionalidade. Uma História de Usuário é apenas um símbolo das conversas
passadas e futuras entre o cliente e os programadores. A presença do cliente no
local minimiza a necessidade de documentar extensamente cada história. Por que?
Porque os programadores podem simplesmente dar alguns passos e fazer suas

perguntas ao cliente. Os detalhes das histórias de usuário são capturados nos testes
automatizados de aceitação que são posteriormente usados para validar a
implementação da história. Poderá não ser necessário escrever descrições para
todas as histórias, visto que o nome de algumas irá fornecer informações suficientes.
O que indica uma boa História de Usuário? O cliente deverá se preocupar com ela.
A história deverá ter valor de negócio na visão do cliente, para que possa ser
priorizada. Às vezes uma história precisa ser decomposta em partes menores para
caber em uma iteração. Se por si só a história não fornecer valor de negócio, deverá
fornece no mínimo progresso em direção a uma funcionalidade de valor ao negócio.
As histórias de usuário atravessam verticalmente a arquitetura do produto –

normalmente elas não estão focadas em um subsistema específico. Casos de Teste
devem ser escritos para verificar se os programadores as implementaram
corretamente. Elas podem ser razoavelmente estimadas pelos desenvolvedores e as
histórias que não puderem ser estimadas deverão ser reescritas.
16712855225

Por fim, elas devem ser concluídas em até uma iteração. Uma história de usuário
que não caiba em uma iteração deverá ser decomposta em duas ou mais histórias
menores. Galera, as histórias criam um ambiente de propriedade do cliente em
relação aos recursos e prioridades em um ambiente incremental e iterativo de
desenvolvimento. Podemos ver alguns exemplos acima!
PROCESSO PARA DESENVOLVER UM INCREMENTO
Prática Descrição
Os requisitos são registrados em cartões de histórias e as histórias a

Planejamento serem incluídas em um release são determinadas pelo tempo disponível
16712855225
Incremental e sua prioridade relativa. Os desenvolvedores dividem essas histórias

em tarefas.
O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é
Pequenos desenvolvido primeiro. Releases do sistema são frequentes e
Releases adicionam funcionalidade incrementalmente ao primeiro release.
É realizado um projeto suficientemente simples de modo que atenda aos

Projeto requisitos atuais e nada mais. Deve-se lembrar que um código simples
Simples não é código fácil.

Um framework automatizado de teste unitário é usado para escrever

Desenvolvimento os testes para uma nova parte da funcionalidade antes que esta seja
Test-First implementada. Portanto, primeiro se escreve o teste, depois faz-se a
implementação.
Espera-se que todos os desenvolvedores recriem o código

Refactoring continuamente tão logo os aprimoramentos do código forem
encontrados. Isso torna o código simples de entender e fácil de manter.
Os desenvolvedores trabalham em pares, um verificando o trabalho do

Programação outro e fornecendo apoio para realizar sempre um bom trabalho. Eles
em Pares utilizam o mesmo mouse, teclado e monitor.
Os pares de desenvolvedores trabalham em todas as áreas do sistema,

Propriedade de tal maneira que não se formem ilhas de conhecimento, com todos os
Coletiva desenvolvedores de posse de todo o código. Qualquer um pode mudar
qualquer coisa.
Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao
Integração sistema como um todo. Depois de qualquer integração, todos os testes
Contínua unitários do sistema devem ser realizados.
Grandes quantidades de horas extras não são consideradas aceitáveis,

Ritmo Sustentável pois, no médio prazo, há uma redução na qualidade do código e na
produtividade. Trabalhar por longos períodos se torna
contraproducente (Recomenda-se 40 horas semanais).
A equipe se comunica sobre o desenvolvimento de software por meio
Metáforas de metáforas, caso consiga encontrar uma que realmente faça sentido
dentro do contexto e possa facilitar a comunicação.
16712855225
Um representante do usuário final do sistema deve estar disponível em

Cliente tempo integral para apoiar a equipe. No XP, o cliente é um membro da
On-site equipe de desenvolvimento e é responsável por trazer os requisitos do
sistema.
Reuniões são realizadas em pé para não se perder o foco nos assuntos,
Reuniões produzindo reuniões mais rápidas, somente abordando as tarefas
em Pé realizadas e tarefas a realizar pela equipe no futuro.

A equipe de desenvolvimento é formada por pessoas engajadas e

Time multidisciplinares, i.e., elas possuem habilidades para diversas áreas
Coeso do projeto.
Jogo do O planejamento de um release e das iterações são feitos com base nas
Planejamento histórias e conta com a colaboração de toda equipe de
desenvolvimento, inclusive o cliente, divididos em papeis: negócio e
técnico. Os clientes priorizam e os desenvolvedores avaliam e estimam.
Vejamos o Processo Extreme Programming! Sabe-se que a abordagem orientada a

objetos é o paradigma de desenvolvimento preferido do XP e envolve um conjunto
de regras e práticas constantes no contexto de quatro atividades metodológicas
principais: Planejamento, Projeto, Codificação e Teste. Observem-nas na imagem
abaixo como funciona:
16712855225
O XP apresenta cinco Valores Fundamentais1:
 Comunicação: para se desenvolver um sistema de software, exige-se comunicar

os requisitos de sistema para os desenvolvedores. Em metodologias formais de
desenvolvimento de software, esta tarefa é realizada por meio de
documentação. O Extreme Programming favorece projetos simples, metáforas
comuns, a colaboração dos usuários, programadores e outros stakeholders, a
comunicação verbal frequente e o feedback.
1
MNEMÔNICO: CorSim ComFeRe Coragem, Simplicidade, Comunicação, Feedback, Respeito.

 Simplicidade: XP incentiva que se comece com a solução mais simples.

Funcionalidades adicionais podem ser acrescentadas posteriormente. Alega-se
que desenvolver funções que não são necessárias hoje pode ser prejudicial, na
medida em que futuramente essa função pode não ser mais útil. Codificação e
projeto de necessidades futuras incertas implicam o risco de gastar recursos em
algo não mais necessários, embora talvez atrasando aspectos cruciais.
 Feedback: o feedback ocorre quando os testes unitários ou testes de integração

retornam o estado do sistema após a implementação das mudanças. Ademais,
como os clientes participam do desenvolvimento de testes, eles podem dar um
feedback instantâneo. Dessa forma, o cliente pode orientar o desenvolvimento
em uma possível recodificação do sistema. Quando o cliente traz um novo
requisito, recebe um feedback de tempo e orçamento.
 Coragem: a coragem permite que os desenvolvedores se sintam confortáveis

com ao refatorar o seu código, quando necessário. Eventualmente, há de se ter
coragem para jogar fora um código ou para remover um código obsoleto, não
importa quanto esforço e tempo se gastou para produzi-lo. Além disso, coragem
significa persistência, pois um programador pode se encontrar preso em um
problema complexo durante um dia inteiro sem conseguir resolver.
 Respeito: aqui se inclui o respeito pelos outros, assim como o auto-respeito.

Membros devem respeitar seu próprio trabalho, sempre se esforçando para
oferecer alta qualidade e buscando o melhor projeto para a solução através de
refatoração. Ninguém na equipe deve se sentir desvalorizado ou ignorado. Isso
garante um alto nível de motivação e incentiva a lealdade dentro da equipe. Este
valor é muito dependente dos outros valores.
Da mesma forma que há valores fundamentais, há também princípios básicos!

16712855225
Galera, não confundam Valores Fundamentais com Princípios Básicos! Eles também
são cinco e devem ser seguidos por equipes que forem usar XP em projetos. Os
princípios servirão pra ajudar na escolha de alternativas de solução de problemas
durante o curso do projeto. São eles:
 Feedback Rápido: retorno tempestivo do cliente, i.e., o sistema é apresentado e,

a cada mudança, há um novo retorno positivo ou negativo do cliente.
 Abraçar Mudanças: mudanças devem ser bem-vindas e ocorrerão de acordo

com o melhor entendimento do projeto.

 Presumir Simplicidade: todo problema deve ser tratado para ser resolvido da
forma mais simples possível.
 Mudanças Incrementais: a solução deve ser aperfeiçoada a cada iteração de

modo a satisfazer, ao fim, as expectativas do usuário.
 Trabalho de Qualidade: a qualidade jamais deve ser comprometida. Essa é uma

das razões para se ter a codificação dos testes antes da codificação do sistema.
No eXtreme Programming, as novas versões de software podem ser compiladas

várias vezes por dia e os incrementos são entregues para os clientes
aproximadamente a cada duas semanas. Quando um programador compila o
sistema para criar uma nova versão, ele deve executar todos os testes
automatizados existentes bem como os testes para a nova funcionalidade.
A nova compilação do software será aceita somente se todos os testes foram

executados com sucesso. Um preceito essencial da engenharia de software
tradicional é projetar mudanças. Em outras palavras, você deve antecipar mudanças
futuras para o software e projetá-lo de tal maneira que essas mudanças possam ser
implementadas facilmente.
O eXtreme Programming, contudo, descarta esse princípio alegando que projetar

para a mudança é, geralmente, um esforço completamente inútil. As mudanças
antecipadas muitas vezes não ocorrem e as solicitações de mudança realizadas são
completamente diferentes, causando diversos prejuízos ao sistema. Entenderam o
problema?
O problema com a implementação de mudanças não antecipadas é que elas

tendem a degradar a estrutura do software, fazendo com que as mudanças tornem-
16712855225
se cada vez mais difíceis de implementar. O Extreme Programming lida com este
problema defendendo que o software deve passar por refatoramento
constantemente.
Isso significa que a equipe de programação procura por possíveis melhorias no

software, implementando-as imediatamente. Portanto, o software deve sempre ser
fácil de compreender e alterar quando novas histórias de usuário são
implementadas. Essa agilidade é muito importante no desenvolvimento ágil de
software. Bacana?

(CESPE – – SECONT/ES – Auditor do Estado – Tecnologia da Informação)

Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente
para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos
de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses métodos está o extreme programming, que envolve um número de
práticas, como o planejamento incremental, a definição de um ritmo de trabalho
sustentável e a divisão das equipes de trabalho por meio da especialização de
seus membros.
Comentários:
A questão está quase toda correta, exceto pela última parte! O XP recomenda que
não haja especialização de membros, apresentando uma equipe coesa e
multidisciplinar, i.e., todos participam de todas as atividades.
Gabarito: E
(CESPE – 2012 – MPE/PI – Analista Ministerial – Cargo 6) O XP (Extreme

Programming) é um método ágil, que preconiza a criação de um caso de teste
unitário antes do início da codificação.
Comentários:
16712855225
O XP é, de fato, um método ágil que preconiza o Test-First Design como uma de

suas práticas, i.e., primeiro cria-se o teste para depois codificar a funcionalidade
referente a esse teste.
Gabarito: C
(CESPE – 2011 – EBC – Analista de Sistemas – Engenharia de Software) O XP

segue um conjunto de valores, princípios e regras básicas que visam alcançar
eficiência e efetividade no processo de desenvolvimento de software. Os valores
são cinco: comunicação, simplicidade, feedback, coragem e respeito.

Comentários:
De fato, esses são os valores preconizados pelo XP: Comunicação, Simplicidade,

Feedback, Coragem e Respeito.
Gabarito: C
(CESPE – 2010 – TRE/BA – Técnico Judiciário – Programação de Sistemas) Em XP,

a prática denominada programação em pares (pair programming) é realizada
por um desenvolvedor em dois computadores, com o objetivo de aumentar a
produtividade.
Comentários:
Na verdade, são dois desenvolvedores utilizando apenas um computador.

Observem que o intuito é aumentar a qualidade do software por meio da revisão
constante pelo par.
Gabarito: E
(CESPE – 2011 – STM – Analista Judiciário – Analista de Sistemas) O Extreme

Programming (XP), que se inclui entre os métodos ágeis, apresenta, entre outras,
as seguintes características: pequenos releases, projeto simples, refactoring,
programação em pares e propriedade coletiva.
Comentários:
Perfeito, todas essas são características do Extreme Programming.

16712855225
Gabarito: C
(CESPE – 2010 – ABIN – Oficial Técnico de Inteligência – Desenvolvimento e

Manutenção de Sistemas) Na Extreme Programming, os requisitos são expressos
como cenários e implementados diretamente como uma série de tarefas. O
representante do cliente faz parte do desenvolvimento e é responsável pela
definição de testes de aceitação do sistema.
Comentários:

Perfeito, os requisitos são expressos como cenários (ou estórias de usuário) e

implementados como tarefas. Ademais, recomenda-se o Cliente On-Site, i.e., um
representante do usuário final do sistema deve estar disponível em tempo integral
para apoiar a equipe. Além disso:
Pressman, 7ª Ed., pág. 77: “XP acceptance tests, also called customer tests, are
specified by the customer and focus on overall system features and functionality
that are visible and reviewable by the costumer. Acceptance tests are derived
from user stories that have been implemented as part of a software release”.
Gabarito: C
(CESPE - 2012 – ANAC – Analista de Sistemas) Para o método ágil de

desenvolvimento conhecido como extreme programming, todos os requisitos
funcionais são expressos como cenários (histórias do usuário) que são
implementados diretamente como uma série de tarefas.
Comentários:
Perfeito, é exatamente isso!
Gabarito: C
(CESPE - 2012 – ANAC – Analista de Sistemas) A técnica conhecida como

refactoring é constantemente aplicada no desenvolvimento baseado no método
ágil extreme programming.
Comentários:
16712855225
Perfeito, é uma técnica amplamente preconizada!
Gabarito: C
(CESPE - 2012 – ANAC – Analista de Sistemas) No modelo extreme

programming, os testes de software só são realizados na etapa final de
desenvolvimento do software e, somente nessa etapa, os programadores
trabalham, obrigatoriamente, em pares, utilizando cada um o próprio
computador.
Comentários:

Primeiro, Testes de Software não ocorrem somente na etapa final de

desenvolvimento, eles são realizados a todo momento. Ademais, programadores
trabalham em pares a todo instante: um computador para dois programadores.
Gabarito: E
10. (CESPE - 2012 – ANAC – Analista de Sistemas) Na metodologia ágil XP (extreme

programming), as metáforas são formas de transmitir ideias complexas de
maneira simples, ou seja, utiliza-se uma linguagem simples entre a equipe e o
cliente, com o objetivo de que, entre as inúmeras variáveis de controle em
projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco
no tempo, em detrimento do planejamento do release.
Comentários:
A primeira parte da questão está perfeita, i.e., metáforas ajudam a transmitir ideias
complexas de maneira simples. No entanto, o objetivo dela não é obter maior foco
no tempo. Ademais, o planejamento da release é dependente do tempo, logo não
há essa distinção de foco!
Gabarito: E
11. (CESPE - 2013 – ANTT – Analista de Sistemas) São práticas ou princípios

recomendados no modelo de desenvolvimento de software XP (eXtreme
Programming) proposto por Kent Beck: programação em pares; semana de
trabalho de 40 horas; refatoração sem piedade; desenvolvimento orientado a
testes TDD (Test Driven Development); e desenvolvimento de metáforas
arquiteturais. 16712855225
Comentários:
Vamos verificar? Programação em Pares, ok. Semana de 40 horas, ok.

Desenvolvimento orientado a testes TDD, ok. Desenvolvimento de metáforas
arquiteturais, ok. Refatoração sem piedade, como é? Sem piedade? Galera, não faço
ideia de onde o CESPE tirou isso! No entanto, é melhor não brigar com a banca.
Gabarito: C

12. (CESPE - – IPEA – Analista de Sistemas) A extreme programming (XP) é um

método de desenvolvimento ágil. Nele, os requisitos são expressos como
cenários implementados diretamente como uma série de tarefas.
Comentários:
Perfeito, essa é uma questão muito comum em concursos!
Gabarito: C
13. (CESPE - 2010 – MPU – Analista de Sistemas) Extreme programming (XP) é

embasado em requisitos conhecidos, definidos de antemão, que não sofram
muitas alterações, devendo ser usado por equipes de pequeno porte, formadas
por representantes de todos os stakeholders.
Comentários:
XP é um método ágil de desenvolvimento de software com requisitos vagos e em

constante mudança, devendo ser usado por equipes de pequeno a médio porte,
formadas – se possível – por representantes de todos os stakeholders.
Gabarito: E
14. ESPE - – TRE.MG – Analista de Sistemas - Extreme programming é um

método centrado no usuário, na produtividade do desenvolvimento e na
documentação de apoio.
Comentários:
16712855225
Centrado na documentação de apoio? Não!
Gabarito: E
15. (CESPE - 2009 – TRE.BA – Analista de Sistemas) A metodologia XP prevê valores

e princípios básicos para serem considerados durante o desenvolvimento de
software. Feedback, coragem e respeito são exemplos de valores; mudanças
incrementais, abraçar mudanças e trabalho de qualidade são exemplos de
princípios básicos.
Comentários:

Perfeito! Valores Fundamentais: Feedback, Coragem, Respeito, Comunicação e

Simplicidade; Princípios Básicos: Feedback Rápido, Abraçar Mudanças, Presumir
Simplicidade, Mudanças Incrementais e Trabalho de Qualidade.
Gabarito: C
16. (CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Os

quatro valores fundamentais da metodologia XP são: comunicação, simplicidade,
feedback e coragem.
Comentários:
Na verdade, são cinco valores fundamentais! Todos esses e mais um: Respeito. No
entanto, a banca deu como verdadeiro!
Gabarito: C
17. (CESPE - 2006 – TSE – Analista de Sistemas – Processos de desenvolvimento

que adotam o modelo ágil enfatizam a comunicação entre participantes, a
realimentação e a simplicidade. Para atingir tais práticas, o Extreme Programming
(XP) advoga práticas como a posse coletiva do código.
Comentários:
Perfeito, é isso mesmo!
Gabarito: C
16712855225
18. (CESPE - - ANAC - Analista Administrativo - Tecnologia da Informação)

Extreme Programming é um modelo de processo de desenvolvimento de
software para equipes com grande número de pessoas, que desenvolvem
software com base em requisitos vagos e que são modificados rapidamente.
Comentários:
Grande número de pessoas? Não, equipes de pequeno e médio porte!
Gabarito: E

19. (CESPE - - ANTAQ - Analista Administrativo - Informática) O extreme

programming (XP) constitui método ágil de desenvolvimento de software. Uma
das práticas que se enquadram nos princípios dos métodos ágeis é a
programação em pares, que promove o compartilhamento da autoria do código
do sistema. Além dessa vantagem, a programação em pares atua como processo
informal de revisão porque cada linha de código é vista por pelo menos duas
pessoas.
Comentários:
Perfeito! A Programação em Par promove a Propriedade Coletiva! Além disso, serve

como uma revisão informal.
Gabarito: C
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) O processo XP (extreme programming) envolve a
realização das atividades de planejamento, de projeto, de codificação e de teste.
Comentários:
Perfeito, essas são as atividades do Processo XP!
Gabarito: C
21. (CESPE - 2013 - STF - Analista Judiciário - Análise de Sistemas de Informação) XP

(Extreme Programming) é uma metodologia ágil voltada para equipes pequenas
e médias que desenvolvam software baseado em requisitos vagos e se
caracteriza por possibilitar modificações rápidas.
16712855225
Comentários:
Gabarito: C
(CESPE - 2013 - TCE-RO - Analista de Informática) No método XP (eXtreming

programming), os sistemas são concebidos a partir de uma metáfora e descritos
em estórias do usuário. Esse método busca facilitar a comunicação com o cliente,

entendendo a realidade deste e guiando o desenvolvimento com o uso de

estória simples.
Comentários:
Perfeito! Metáforas simplificam o entendimento!
Gabarito: C
(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) XP é um método

de desenvolvimento de software em que os requisitos são especificados em user
stories; requisitos, arquitetura e design surgem durante o curso do projeto; e o
desenvolvimento ocorre de maneira incremental.
Comentários:
Gabarito: C
24. (CESPE - – PRODEST - Analista de Sistemas) Projetar detalhadamente todo

o software antes de iniciar a sua implementação é uma prática recomendada
pelo XP. O software deve ser projetado para atender tanto aos requisitos atuais
quanto aos potenciais requisitos futuros. Para atingir esse objetivo, são
analisados os possíveis cenários de evolução futura e são empregados padrões
de projeto para facilitar a manutenção.
Comentários:
16712855225
Projetar detalhadamente? Não! O Manifesto Ágil já dizia: responder a mudanças é

mais valorizado do que seguir um plano específico.
Gabarito: E
(CESPE - – PRODEST - Analista de Sistemas) Constituem práticas

recomendadas pelo XP a colocação rápida de uma versão simples em produção,
a liberação das novas versões em curtos intervalos de tempo, a programação
em duplas, a refatoração (refactor) dos códigos produzidos, a adoção de
padrões para a codificação; a integração e o teste contínuos de códigos; a
limitação em 40 horas da carga de trabalho semanal.

Comentários:
Gabarito: C
(CESPE - – PRODEST - Analista de Sistemas) O XP é um processo que visa

a um desenvolvimento ágil e portanto não recomenda os testes de unidade, pois
eles consomem muitos recursos. Durante o desenvolvimento, o primeiro teste
recomendado é o smoke test que foca os detalhes de funcionamento. O smoke
test é realizado após as unidades serem integradas. Após o smoke test, é
realizado o teste de sistema.
Comentários:
Como é? XP recomenda veementemente a utilização de testes de unidade!
Gabarito: E
ACERTEI ERREI
16712855225

(FCC - 2012 - TST - Técnico Judiciário – Programação O XP (Extreme

Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele:
a) recomenda que duas pessoas trabalhem juntas para criar o código

correspondente a uma história.
b) recomenda que a equipe XP e os clientes trabalhem de forma separada para

não mudar o compromisso básico definido para a versão a ser entregue.
c) segue rigorosamente o princípio FDD - Feature Driven Development.
d) recomenda que depois que as histórias forem desenvolvidas e o trabalho

preliminar do projeto for feito, a equipe XP avance diretamente para o código.
e) inclui um conjunto de regras e práticas que ocorrem no contexto de 3

atividades de arcabouço: projeto, implementação e entrega.
Comentários:
(a) Correto, trata-se da programaçõ em pares; (b) Errado, recomenda-se o client on-
site, i.e., o cliente está sempre presente para auxiliar com seu conhecimento sobre
a área de negócio; (c) Errado, ela segue o TDD – Test-Driven Development; (d)
16712855225
Errado, Pressman afirma que se recomenda desenvolver testes unitários que

exercitarão as histórias; (e) Errado, Pressman afirma que XP inclui um conjunto de
regras e práticas que ocorrem no contexto de quatro atividades de arcabouço:
planejamento, projeto, codificação e teste.
Gabarito: A
(FCC - 2007 - TRE-SE - Analista Judiciário - Tecnologia da Informação Na XP

(eXtreme Programming):

a) deve-se usar o modelo em cascata para o desenvolvimento do software.
b) os programadores desenvolvem o software criando primeiramente os testes.
c) deve ser evitada a comunicação pessoal entre clientes e desenvolvedores,

sempre dando preferência a outros meios de comunicação mais formais.
d) os programadores desenvolvem o software fazendo todos os testes possíveis

no término do desenvolvimento.
e) deve-se projetar todas as funções possíveis com a máxima previsão do que

ocorrerá no futuro, antes do desenvolvimento do software, a fim de evitar
alterações desnecessárias.
Comentários:
(a) Errado, esse item não faz o menor sentido; (b) Correto, testa-se primeiro,
codifica-se depois; (c) Pelo contrário, deve-se estimular a comunicação pessoal
entre clientes e desenvolvedores e evitar outros meios mais formais; (d) Errado,
testes são feitos a todo momento; (e) Pelo contrário! XP lida bem com mudanças.
Gabarito: B
(FCC - 1 – TRE/RS - Analista Judiciário - Tecnologia da Informação) No

eXtreme Programming, XP:
a) o código é integrado e testado depois de alguns dias e, no máximo, até o final

da semana.
16712855225
b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes),

preferencialmente num único computador.
c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma

equipe pode adotar as regras de outra equipe.
d) releases quando complexos não podem deixar de fora os requisitos de

negócio de maior valor para o cliente.
e) módulos não são propriedade de nenhum desenvolvedor; todo

desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.

Comentários:
(a) Errado, recomenda-se a integração sempre que possível; (b) Errado, é feita por
um par de programadores; (c) Errado, as equipes são auto-organizáveis de acordo
com as suas habilidades, logo não faz sentido se organizar de acordo com outra
equipe; (d) Errado, releases devem ser simples e, não, complexas; (e) Correto, o
código é compartilhado.
Gabarito: E
(FCC - – TRT/MT – Analista de Sistemas NÃO se aplica à disciplina de

desenvolvimento de software extreme programming (XP):
a) Usa notações próprias para construir os diversos produtos de trabalho do

projeto.
b) Encoraja a refabricação para modificar um sofware sem alterar o

comportamento externo do código.
c) Recomenda que dois programadores trabalhem juntos no mesmo

computador para escrever um código.
d) Baseada em valores de simplicidade, comunicação, feedback e coragem.
e) Adota como um elemento-chave a criação de testes unitários antes da

codificação começar.
Comentários: 16712855225
(a) Errado, não há nenhuma notação própria; (b) Correto, trata-se do Refactoring;
(c) Correto, trata-se da programação em pares; (d) Correto, há também respeito; (e)
Correto, teste primeiro e codifique depois.
Gabarito: A
(FCC - – MPE/RN – Analista de Sistemas Refactoring, programação em

pares e Stand-up Meeting são características das práticas do:
a) PRINCE2.

b) Rational Unified Process.

c) Extreme programming.
d) PMBOK.
e) SCRUM.
Comentários:
Refactoring, Pair-Programming e Standup Meeting são todas práticas do XP.
Gabarito: C
(FCC - – MPE/AP – Analista de Sistemas O Extreme Programming (XP) é,

talvez, o mais conhecido e mais utilizado dos métodos ágeis. Dentre suas práticas
se encontram programação em pares, integração contínua, refatoração e:
a) propriedade coletiva, que garante uma participação nos lucros aos membros
da equipe de desenvolvimento, técnica que incentiva e aumenta o desempenho
de toda a equipe.
b) envolvimento do cliente apenas na fase final do sistema, fator que difere de

outras metodologias como SCRUM e TDD e confere agilidade ao processo de
desenvolvimento.
c) processo de desenvolvimento contínuo, em que a equipe se mantém focada

no sistema até que uma funcionalidade específica seja entregue, comumente
agregando horas extras ao turno de trabalho.
d) utilização de técnicas de ofuscação do código fonte, trazendo segurança e

garantindo que apenas a equipe de desenvolvimento poderá ter acesso a este
16712855225
código
e) desenvolvimento incremental e sustentado por meio de pequenos e

frequentes releases do sistema. Os requisitos são baseados em cenários ou em
simples histórias de clientes.
Comentários:
(a) Participação nos lucros? Quem dera! Essa prática significa que todos podem
visualizar e editar um código-fonte; (b) Errado, o envolvimento ocorre durante todo
o processo; (c) Errado, deve-se manter um ritmo sustentável, evitando horas-extras;

(d) Pelo contrário, quanto mais limpo o código, melhor; (e) Perfeito, não há nada a
acrescentar.
Gabarito: E
(FCC - – MPE/PE – Analista de Sistemas Dentre as práticas do método ágil

Extreme Programming (XP), está a prática de propriedade coletiva. É correto
afirmar que, nessa prática,
a) os trabalhos são desenvolvidos em conjunto, para que um programador possa

analisar o trabalho do outro.
b) cada projeto é realizado para atender às necessidades globais dos usuários,

focando na coletividade da distribuição da informação.
c) os pares de desenvolvedores trabalham em todas as áreas do sistema, de

modo que não se desenvolvam ilhas de expertise.
d) grandes quantidades de horas extras não são consideradas aceitáveis, pois o

resultado final, muitas vezes, é a redução da qualidade do código e da
produtividade a médio prazo, sendo que o indivíduo pode afetar o desempenho
de todo o time.
e) um representante do usuário final do sistema deve estar disponível todo o

tempo à equipe de desenvolvimento. Nesse modelo de desenvolvimento, o
cliente é membro da equipe e participa da responsabilidade do código
desenvolvido.
(a) Pair Programming; (b) Não sei o que é, mas não há relação com Propriedade
Coletiva; (c) Propriedade Coletiva; (d) Ritmo Sustentável; (e) Cliente On-Site. Alguns
afirmam que a terceira opção está mais para a prática de Pair Programming e, não,
para Propriedade Coletiva. Eu admito que é um pensamento razoável, mas
nenhuma outra opção se encaixa em Propriedade Coletiva. Dessa forma, deve-se
ter essa noção nas questões da FCC, i.e., marcar a mais correta ou a menos errada.
Gabarito: D

(FCC - – TCE/AL – Analista de Sistemas Originalmente, o único produto da

atividade de Projeto que é realizado como parte do processo XP (Extreme
Programming):
a) é a definição do caso de uso de contexto.

b) são os cartões CRC.
c) são os diagramas de objetos.
d) são os diagramas de seqüência.
e) é a codificação, feita em pares.
Comentários:
Pressman afirma: “Como o projeto XP praticamente não usa nenhuma notação e

produz poucos, ou nenhum produto de trabalho que não sejam os cartões CRC e as
soluções de ponta, o projeto é visto como um artefato provisório que pode e deve ser
continuamente modificado à medida que a construção prossegue”. Portanto, trata-
se dos Cartões CRC.
Gabarito: B
(FCC - – TRE/RN – Analista de Sistemas Considere as seguintes

características:
I. Propriedade coletiva.
II. Integração contínua.
III. Metáfora.
Dentre as práticas componentes da Extreme Programming, aplica-se o que consta

em: 16712855225
a) I, apenas.
b) II, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
Comentários:
Todas as opções estão corretas: Propriedade Coletiva, Integração Contínua e

Metáfora.

Gabarito: E
10. (FCC - – TRT/23 – Analista de Sistemas No desenvolvimento de software

em Extreme Programming (XP) há uma confiança muito grande na sinergia entre
as práticas, já que os pontos fracos de cada uma são superados pelos pontos
fortes de outras. Dentre elas, aquela em que o código fonte não tem dono e
ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim,
que a equipe conheça todas as partes do sistema, é chamada de:
a) Whole Team (Time Coeso).

b) Sustainable Pace (Ritmo Sustentável).
c) Pair Programming (Programação em Pares).
d) Collective Ownership (Posse Coletiva).
e) Coding Standards (Padrões de Codificação).
Comentários:
Fácil, não? Trata-se do Collective Ownership (Propriedade Coletiva).
Gabarito: D
11. (FCC - – TRE/RN – Analista de Sistemas Assegurar que a equipe se

concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite
fazer o que poderia vir a ser necessário, mas ainda não se provou essencial. Este
é um dos cinco valores fundamentais do XP (Extreme Programming),
denominado:
a) coragem. 16712855225
b) respeito.
c) comunicação.
d) simplicidade.
e) feedback.
Comentários:
Fazer o necessário e essencial é o valor da simplicidade.
Gabarito: D

12. (FCC - – TJ/PI – Analista de Sistemas XP (eXtreme Programming) é uma

metodologia ágil para equipes pequenas e médias que desenvolverão software
com requisitos vagos e em constante mudança. Para isso, adota a estratégia de
constante acompanhamento e realização de vários pequenos ajustes durante o
desenvolvimento de software. Para aplicar os valores e princípios durante o
desenvolvimento de software, a XP propõe uma série de práticas, sendo uma
delas: sempre que produzir uma nova funcionalidade, nunca esperar uma
semana para integrar à versão atual do sistema a fim de evitar o aumento da
possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática
é denominada:
a) Time Coeso.
b) Refatoração.
c) Integração Contínua.
d) Desenvolvimento Orientado a Testes.
e) Ritmo Sustentável.
Comentários:
Trata-se da Integração Contínua! É comum a utilização de servidores de integração

contínua que automatizam esse processo para os desenvolvedores.
Gabarito: C
13. (FCC - – TJ/PE – Analista de Sistemas Nos métodos ágeis XP e Scrum, as

entregas de partes funcionais do projeto são divididas em ciclos, geralmente
compreendidos no período de 1 a 4 semanas. Estes ciclos denominam-se,
respectivamente,
16712855225
a) iterações e sprint.
b) reunião de planejamento e backlog.
c) período de entrega e reunião de revisão.
d) backlog e planejamento da produção.
e) entrega e retrospectiva.
Comentários:
No XP, temos as iterações; no Scrum, temos a sprint.
Gabarito: A

ACERTEI ERREI
16712855225

FEATURE DRIVEN DEVELOPMENT (FDD)
Vamos falar agora sobre o Feature Driven Development (ou Desenvolvimento

orientado a Funcionalidades/Características). Essa é uma das seis implementações
de metodologias ágeis originais preconizadas pelo Manifesto Ágil – a ela se juntam
eXtreme Programming (XP), Adaptative Software Development (ASD), Dynamic
Systems Development Method (DSDM), Scrum e Crystal Clear.
O FDD foi criado em 1997 por Peter Coad e Jeff de Lucca como um grande projeto
de um United Overseas Bank – um banco local de Singapura. Ela oferece um
conjunto coeso de princípios e práticas tanto para a Gestão de Projetos quanto para
a Engenharia de Software, e se harmoniza bem com abordagens mais especialistas,
como Scrum.
Ela se fundamenta em técnicas de gerenciamento de projetos e de modelagem

orientada a objetos, equilibrando vantagens das metodologias rígidas
(contemplando – por exemplo – planejamento e modelagem) e das metodologias
ágeis (ciclos curtos, orientação ao cliente, ênfase em programação, etc). Eu diria que
ele é um meio-termo entre XP e RUP.
Professor, mas o que seria um Feature? ata-se de uma funcionalidade ou

característica valorizada pelo cliente, que pode ser implementada em duas semanas
ou menos. Alguns dizem ser similar a um requisito funcional que gera valor ao
cliente. À medida que há participação ativa do cliente no projeto, os resultados têm
bastante e rápida visibilidade.
O método oferece algumas características importantes:

16712855225
 Fornece uma estrutura adequada para equipes maiores;

 Enfatiza a produção de software de qualidade;
 Fornece informação de estado e progresso de forma simples;
 Agradam clientes, gerentes e desenvolvedores;
 Entrega resultados frequentes, tangíveis e funcionais;
 Planejamento detalhado e guiado para medição;
 Rastreabilidade e relatórios com precisão;
Ele recomenda também a adoção de um conjunto de melhores práticas para que o

método atinja seus objetivos principais, são eles: modelagem de objetos de domínio;

desenvolvimento por feature; posse individual do código; equipes de features;

inspeções; builds regulares; gerenciamento de configuração; relatório e visibilidade
de resultados.
Possui duas grandes fases: Concepção & Planejamento (ou Modelagem) – com três
processos; e Construção (ou Implementação) – com dois processos.
 Concepção & Planejamento: é uma parte crítica do processo, pois é nessa fase
que são listadas as características (Features) que serão desenvolvidas, e em um
primeiro momento é nessa fase que são definidas todas as características e fases
do sistema e projetos, respectivamente. Seus processos são:
Desenvolver um Modelo Abrangente: abrangendo todo o projeto, realiza-se

um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são
realizados estudos mais detalhados para cada área a ser modelada. Assim,
pequenos grupos são formados por membros do domínio do negócio e por
desenvolvedores, que comporão seus próprios modelos.
Os pequenos grupos apresentam seus modelos para serem revisados por

parceiros e para discussão. Um dos modelos propostos é selecionado por
consenso, tornando-se, assim, o modelo para aquela área do domínio do
negócio. Realiza-se, então, uma combinação do modelo da área do domínio
dentro de um modelo abrangente.
Construir uma Lista de Funcionalidades: abrangendo todo o projeto,

identificam-se todas as funcionalidades que satisfaçam os requisitos. Uma
equipe é formada para decompor funcionalmente o domínio em áreas de
negócio, atividades de negócio dentro delas e passos dentro de cada
atividade de negócio, formando uma lista categorizada de funcionalidades.
16712855225
Planejar por Funcionalidade: abrangendo todo o projeto, busca-se produzir

o plano de desenvolvimento. O gerente de projeto, o gerente de
desenvolvimento e os programadores-líderes planejam a ordem de
implementação, baseado nas dependências entre elas, na carga de trabalho
da equipe e na complexidade das funcionalidades a serem implementadas.
As principais atividades neste processo não são uma sequência estrita. Como
muitas atividades de planejamento, elas são consideradas em conjunto, com
refinamentos feitos a partir de uma ou mais atividades e então considerando

os outros novamente. Após isso, a posse das classes estará completada (além
das classes principais que já foram consideradas para posse).
 Construção: a implementação inicia agrupando features relacionadas e

agrupando dentro de uma pacote de trabalho, que deve ser completada dentro
de uma iteração. Um pacote de trabalho completo representa uma parte do
sistema que já pode ser utilizada pelo cliente.
Detalhar por Funcionalidade: abrangendo cada funcionalidade, busca-se

produzir o pacote de projeto para ela. Certo número de funcionalidades são
agendadas para desenvolvimento ao atribuí-las a um programador-líder. Ele
seleciona as funcionalidades para desenvolvimento a partir de sua caixa de
entrada de funcionalidades atribuídas.
Ele pode escolher diversas funcionalidades que utilizem as mesmas classes (e

portanto, desenvolvedores). Operacionalmente, com frequência acontece o
caso de conjuntos de funcionalidades serem agendados para
desenvolvimento de uma vez pelo programador-líder. Tal conjunto é
chamado de Pacote de Trabalho do Programador-Líder (PTPL).
O programador-líder forma uma equipe de funcionalidades, identificando os

proprietários das classes que provavelmente serão envolvidos no
desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz
diagrama de sequência para as funcionalidades atribuídas. O programador-
líder, então, refina o modelo de objetos e realiza-se uma inspeção no projeto.
Construir por Funcionalidade: abrangendo cada funcionalidade, busca-se

produzir uma função com valor para o cliente. Começando com o pacote de
projeto, os proprietários de classes implementam os itens necessários para
16712855225
que suas classes suportem o projeto para esta funcionalidade. O código passa
por testes e inspeções. Após isso, é promovido à versão atual (build).

O FDD pode facilitar imensuravelmente o fardo de reportar o status do projeto. Ele

permite que o rastreio do progresso do desenvolvimento possa ser feito através de
marcos definidos por funcionalidade, o que facilita a visualização do projeto como
um todo. Os marcos começam a ser monitorados pelo gerente do projeto a partir
da fase de construção. São eles:
 Walkthroughs do projeto;
 Projeto;
 Inspeção do projeto;
 Código;
 Inspeção de código;
 Progressão para construção.
16712855225

(FCC - 2010 – TRF/4 - Analista de Sistemas) A Feature Driven Development (FDD)

é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto
afirmar:
a) Não pode ser combinada a outras técnicas para a produção de sistemas.
b) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista

de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e
Implementar por Funcionalidade.
c) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de

cada categoria, os papéis são atribuídos a um único participante que assume a
responsabilidade pelo papel.
d) Mantém seu foco apenas na fase de modelagem.
e) Mantém seu foco apenas na fase de implementação.
Comentários:
(a) Como não? O próprio modelo é a combinação de ferramentas de diferentes

metodologias – elas interagem bem com outros modelos; (b) Perfeito, esses são de
16712855225
fato os cinco processos; (c) Na verdade, há diversos cargos e responsabilidades

entre as categorias principais (ou chave), de apoio e adicionais; (d) Não, o foco é
tanto na Modelagem quanto na Implementação; (e) Não, o foco é tanto na
Modelagem quanto na Implementação.
Gabarito: B
(FCC - 2014 – TRF/3 - Analista de Sistemas) Os modelos ágeis de desenvolvimento

de software têm menos ênfase nas definições de atividades e mais ênfase na
pragmática e nos fatores humanos do desenvolvimento. Um destes modelos
enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 −

Concepção e Planejamento e 2 − Construção. A fase de Concepção e

Planejamento possui três disciplinas (chamadas de processos): Desenvolver
Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por
funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos):
Detalhar por Funcionalidade e Construir por Funcionalidade.
O texto acima apresenta a metodologia ágil conhecida como:
a) XP.
b) SCRUM.
c) Crystal Clear.
d) ASD.
e) FDD.
Comentários:
Trata-se evidentemente do FDD.
Gabarito: E
(FCC - 2013 – TRT/9 - Analista de Sistemas) Os modelos de processos tradicionais

surgiram em um cenário muito diferente do atual, baseado em mainframes e
terminais remotos. Já os modelos de processos ágeis são adequados para
situações atuais nas quais a mudança de requisitos é frequente. Dentre os
modelos de processos ágeis mais comuns temos: Extreme Programming (XP),
Scrum e Feature Driven Development (FDD).
Algumas das práticas e características desses modelos de processo são descritas

16712855225
a seguir:
I. Programação em pares, ou seja, a implementação do código é feita em dupla.
II. Desenvolvimento dividido em ciclos iterativos de até 30 dias chamados de

sprints.
III. Faz uso do teste de unidades como sua tática de testes primária.
IV. A atividade de levantamento de requisitos conduz à criação de um conjunto

de histórias de usuários.

V. O ciclo de vida é baseado em três fases: pre-game phase, game-phase, post-

game phase.
VI. Tem como único artefato de projeto os cartões CRC.
VII. Realiza reuniões diárias de acompanhamento de aproximadamente 15

minutos.
VIII. Define seis marcos durante o projeto e a implementação de uma

funcionalidade: walkthroughs do projeto, projeto, inspeção do projeto,
codificação, inspeção de código e progressão para construção.
IX. Os requisitos são descritos em um documento chamado backlog e são

ordenados por prioridade.
A relação correta entre o modelo de processo ágil e a prática/característica é:
SCRUM FDD
II, V e VII II, IV e VIII VII e IX
I, III, IV e VI II, V, VII e IX VIII
II, VII e VIII III, IV, VI e IX IeV
II, VII e VIII I, III, IV e V VI e IX
I, III, IV e VI II, VIII, VII e IX V
Comentários:
(I) XP; (II) Scrum; (III) XP; (IV) XP; (V) Scrum; (VI) XP; (VII) Scrum; (VIII) FDD; (IX) Scrum.
16712855225
Vamos comentar apenas a que nos interessa: FDD define seis marcos durante o
projeto e implementação de uma funcionalidade: walkthroughs (travessia) do
projeto, projeto, inspeção do projeto, codificação, inspeção de código e progressão
para construção.
Gabarito: B
(FCC - 2011 – TRT/23- Técnico Judiciário) FDD (Feature Driven Development) é

uma metodologia muito objetiva, possuindo apenas duas fases:
a) Concepção & Planejamento e Construção.

b) Decomposição Funcional e Construção.

c) Análise dos Requisitos e Desenvolvimento.
d) Planejamento Incremental e Desenvolvimento por Funcionalidade.
e) Planejamento por Funcionalidade e Construção por Funcionalidade.
Comentários:
Trata-se da Concepção & Planejamento e Construção.
Gabarito: A
(FCC - 2010 - TRE- - Técnico Judiciário - Programação de Sistemas) São

algumas das metodologias de desenvolvimento de software consideradas ágeis
(Agile Software Process Models):
a) RUP, XP e DSDM.
b) Waterfall, RUP e FDD.
c) XP, FDD e RUP.
d) Scrum, XP e FDD.
e) Scrum, Waterfall e DSDM.
Comentários:
Fácil, não?! Scrum, XP e FDD.
Gabarito: D
ACERTEI ERREI
16712855225

(CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno) Há um

considerável debate sobre os benefícios e a aplicabilidade do desenvolvimento
ágil de software em contraposição aos processos mais convencionais de
engenharia de software. Relacione o modelo ágil de software com a sua
respectiva característica.
Modelo:
I - DAS II - DSDM III - FDD IV - XP
Característica:
(P)
Define um ciclo de vida que incorpora três fases: especulação, colaboração e
aprendizado. Durante a fase de aprendizado, à medida que os membros de uma
equipe começam a desenvolver os componentes que fazem parte de um ciclo
adaptativo, a ênfase está tanto no aprendizado quanto no progresso em direção
a um ciclo completo.
(Q)
O conceito característica é uma função valorizada pelo cliente, que pode ser
implementada em duas semanas ou menos. Este modelo define seis marcos de
referência durante o projeto e implementação de uma característica: travessia
16712855225
do projeto, projeto, inspeção de projeto, código, inspeção de código, promoção

para construção.
(R)
Fornece um arcabouço para construir e manter sistemas que satisfazem às
restrições de prazo apertadas por meio do uso de prototipagem incremental em
ambiente controlado de projeto. Essa abordagem sugere uma filosofia que é
emprestada de uma versão modificada do princípio de Pareto.
A relação correta é:

a) I - P, II - Q, III - R.
b) I - P, II - R, III - Q.
c) I - Q, III - R, IV - P.
d) II - P, III - R, IV - Q.
e) II - Q, III - P, IV - R.
Comentários:
Vamos comentar apenas o que nos interessa: FDD se refere à letra Q – com seus
marcos e funcionalidades/características.
Gabarito: B
ACERTEI ERREI
16712855225

TEST-DRIVEN DEVELOPMENT (TDD)
O Test-Driven Development (TDD2) é um método ágil de desenvolvimento de

software que se baseia na repetição de um ciclo de desenvolvimento curto, focado
em testes unitários, em que os casos de teste que verificam uma nova funcionalidade
são escritos antes mesmo da própria funcionalidade. Escreve-se o teste, encontre
uma falha e refatore-o, ciclicamente – conhecido como Red, Green e Refactor.
Vamos lá! Para cada parte da aplicação, adiciona-se um teste escrito antes mesmo
do desenvolvimento do código em si. Por que? Porque eles podem ajudar a reduzir
riscos de possíveis problemas no código. Executamos o teste e ele... falha! Ele deve
necessariamente falhar! Por que? Ora, porque ele é o primeiro teste e você nem
criou a funcionalidade ainda, logo ele não irá funcionar!
Então nós adicionamos uma nova funcionalidade ao sistema apenas para que ele
16712855225
passe no teste e execute novamente (agora ele deve passar no teste). Então
adicionamos um novo teste e rodamos o teste anterior e esse novo teste. Se algum
deles falhar, modifica-se o código da funcionalidade e rodam-se todos os testes
novamente, e assim por diante – a imagem abaixo mostra como funciona.
Galera, vocês percebem que o feedback sobre a nova funcionalidade é bem rápido?
Ademais, cria-se um código mais limpo, visto que o código para passar nos testes
deve ser bastante simples. Há mais segurança na correção de eventuais bugs;
2
Eventualmente chamado de Test-Driven Programming (TDP).

aumenta-se a produtividade, visto que se perde menos tempo com depuradores; e

o código se torna mais flexível, menos acoplado e mais coeso.
Em geral, utilizam-se Testes Unitários, Testes de Integração ou Testes de Aceitação

– sendo os primeiros os mais comuns. Algumas ferramentas que podem ser
utilizadas para implementar o processo de desenvolvimento orientado a testes:
16712855225
JUnit, TesteNG, PHPUnit, SimpleTest, NUnit, Jasmine, CUnit, PyUnit, etc. Enfim,
pessoal, essa abordagem permite diminuir eventuais riscos.
IMPORTANTE
O Test Driven Development (TDD) não é uma abordagem para realizar testes, é uma
abordagem para desenvolver softwares. Entenderam? Se alguma questão disser que trata-
se de uma técnica para realização de testes de software, está errado! É um processo para
desenvolvimento de software! Ok?

Professor, isso já caiu em prova discursiva? Sim, a prova pedia para dizer as
ntagens do emprego do TDD em relação a outras metodologias ágeis.
Poderíamos responder essa pergunta afirmando que o software desenvolvido, em
geral, apresenta maior qualidade, na medida em que é implementado direcionado
às expectativas do cliente;
Há a possibilidade de se testar todo o código desenvolvido, o que oferece maior

confiabilidade ao sistema; por fim, em geral, o código é mais modularizado, flexível
e extensível, visto que a metodologia requer que os desenvolvedores imaginem o
software como pequenas unidades que podem ser reescritas, desenvolvidas e
testadas de forma independente e integradas em momento posterior.
A prova também perguntava como os princípios da Metodologia XP apoiados pelo

TDD. Poderíamos afirmar que O Extreme Programming (XP) apresenta diversas
práticas que podem ser relacionadas com o TDD; a mais óbvia é o “Teste Primeiro”,
ratificando a característica básica recomendada veementemente pelo
desenvolvimento orientado a testes.
O TDD pode apoiar esse princípio por fornecer detalhes para a realização dos testes
de unidade e de funcionalidade, que são importantes e necessários. Ademais, o
desenvolvimento orientado a testes apresenta relação intrínseca com a Refatoração,
tendo em vista que confere ao programador maior segurança para identificar e
remover o código duplicado, e permite, assim, a melhoria contínua do programa.
16712855225

(CESPE – – INMETRO – Analista Executivo em Metrologia e Qualidade –

Desenvolvimento de Sistemas) A rotina diária dos desenvolvedores, ao empregar
processos baseados no TDD (Test-Driven Development), é concentrada na
elaboração de testes de homologação.
Comentários:
A rotina dos desenvolvedores é concentrada, na verdade, na elaboração de testes

unitários e, não, de homologação. Lembrem-se: constrói o teste, constrói a
funcionalidade e refatora a funcionalidade.
Gabarito: E
(CESPE – 2013 – INPI – Analista de Planejamento – Desenvolvimento e

Manutenção de Sistemas) Usando-se o TDD, as funcionalidades devem estar
completas e da forma como serão apresentadas aos seus usuários para que
possam ser testadas e consideradas corretas.
Comentários:
Pelo contrário, primeiro são feitos os testes e depois desenvolvem-se as

funcionalidades. 16712855225
Gabarito: E
(CESPE – 2013 – ANCINE – Analista de Sistemas) No desenvolvimento de

software conforme as diretivas do TDD (Test-Driven Development), deve-se
elaborar primeiramente os testes e, em seguida, escrever o código necessário
para passar pelos testes.
Comentários:
Perfeito! Primeiro, criam-se os testes, depois cria-se o software ou componente.

Gabarito: C
(CESPE – – INMETRO – Analista de Sistemas) Considerando uma

organização na qual a abordagem de Test Driven Development (TDD) esteja
implementada, assinale a opção correta.
a) Nessa organização, ocorre a execução de iterações com ciclo longo, isto é,

com duração de alguns meses.
b) No início de cada iteração, a primeira atividade realizada pela equipe de

desenvolvimento é produzir o código que será validado através de testes.
c) O refactoring é uma das primeiras atividades realizada no início de cada

iteração.
d) Entre as atividades finais de cada iteração, o desenvolvedor escreve casos de

teste automatizados, cuja execução verifica se houve a melhoria desejada ou se
uma nova funcionalidade foi implementada.
e) Há coerência e inter-relação com os princípios promovidos pela prática da

extreme programming (XP).
Comentários:
(a) Não, são ciclos curtos; (b) Não, são produzidos primeiramente os testes e, depois,
os códigos; (c) Não, a refatoração é uma das últimas atividades realizadas em uma
iteração; (d) Escrever casos de testes é uma das atividades iniciais; (e) Perfeito, TDD
é uma das práticas recomendadas pelo XP.16712855225
Gabarito: E
(CESPE – 2013 – MPOG – Analista de Sistemas) Ao realizar o TDD (test-driven

development), o programador é conduzido a pensar em decisões de design
antes de pensar em código de implementação, o que cria um maior
acoplamento, uma vez que seu objetivo é pensar na lógica e nas
responsabilidades de cada classe.
Comentários:

Maior acoplamento? Não, cria menor acoplamento!
Gabarito: E
(CESPE – 2013 – MPU – Analista de Sistemas) Na metodologia TDD, ou

desenvolvimento orientado a testes, cada nova funcionalidade inicia com a
criação de um teste, cujo planejamento permite a identificação dos itens e
funcionalidades que deverão ser testados, quem são os responsáveis e quais os
riscos envolvidos.
Comentários:
Perfeito, essa metodologia permite um aprendizado maior sobre o problema a ser

resolvido, permitindo (não é obrigatório) a identificação de itens, funcionalidades,
responsáveis e riscos.
Gabarito: C
(CESPE – 2013 – STF – Analista de Sistemas) No TDD, o primeiro passo do

desenvolvedor é criar o teste, denominado teste falho, que retornará um erro,
para, posteriormente, desenvolver o código e aprimorar a codificação do
sistema.
Comentários:
Perfeito, é exatamente isso!
Gabarito: C
16712855225
(CESPE – 2013 – TRT/17 – Analista de Sistemas) TDD consiste em uma técnica de

desenvolvimento de software com abordagem embasada em perspectiva
evolutiva de seu desenvolvimento. Essa abordagem envolve a produção de
versões iniciais de um sistema a partir das quais é possível realizar verificações
de suas qualidades antes que ele seja construído.
Comentários:
Galera! O CESPE afirma que esta questão está errada e, para uma questão estar
errada, é preciso que haja algum erro nela. Óbvio, não?! Pois é, o problema é que
eu não acho que haja nenhum erro no item. TDD é uma técnica? Sim! De

desenvolvimento de software? Sim! Com abordagem embasada em perspectiva

evolutiva? Sim, criam-se testes que vão encontrando erros e melhorando um código.
Essa abordagem envolve a produção de versões iniciais de um sistema? Sim. A partir
das quais é possível realizar verificações de suas qualidades antes que ele seja
construído? Sim, a partir dos testes e do entendimento do software, é possível
verificar a qualidade do sistema a ser construído. Enfim, discordo do gabarito!
Gabarito: E
(CESPE – 2013 – AL/RN – Analista de Sistemas) Um típico ciclo de vida de um

projeto em TDD consiste em:
I. Executar os testes novamente e garantir que estes continuem tendo sucesso.

II. Executar os testes para ver se todos estes testes obtiveram êxito.
III. Escrever a aplicação a ser testada.
IV. Refatorar (refactoring).
V. Executar todos os possíveis testes e ver a aplicação falhar.
VI. Criar o teste.
A ordem correta e cronológica que deve ser seguida para o ciclo de vida do TDD
está expressa em:
a) IV − III − II − V − I − VI.
b) V − VI − II − I − III − IV.
c) VI − V − III − II − IV − I.
d) III − IV − V − VI − I − II.
e) III − IV − VI − V − I − II.
Pessoal, acredito que essa questão não possui resposta! Percebam que a opção que
melhor se encaixa é a Letra C (VI − V − III − II − IV – I), no entanto o item V afirma:
Executar todos os possíveis testes e ver a aplicação falhar. Acredito que o correto
seria dizer: Executar os possíveis testes e ver se algum deles falha.
Gabarito: C
10. (FGV – 2013 – AL/MT – Analista de Sistemas) Com relação ao desenvolvimento

orientado (dirigido) a testes (do Inglês Test Driven Development – TDD), analise
as afirmativas a seguir.

I. TDD é uma técnica de desenvolvimento de software iterativa e incremental.
II. TDD implica escrever o código de teste antes do código de produção, um

teste de cada vez, tendo certeza de que o teste falha antes de escrever o código
que irá fazê-lo passar.
III. TDD é uma técnica específica do processo XP (Extreme Programming),

portanto, só pode ser utilizada em modelos de processos ágeis de
desenvolvimento de software.
Assinale:
a) Se somente as afirmativas I e II estiverem corretas.

b) Se somente as afirmativas I e II estiverem corretas.
c) Se somente as afirmativas II e III estiverem corretas.
d) Se somente a afirmativa III estiver correta.
e) Se somente a afirmativa I estiver correta.
Comentários:
(I) Perfeito, é iterativo e incremental (lembrando que, em sua imensa maioria,

metodologias ágeis são iterativas/incrementais); (II) Perfeito, escrevem-se os testes
antes, fá-lo falhar e só depois escreve-se o código da aplicação; (III) Não, ele é uma
metodologia independente.
Gabarito: A
11. (FCC – 2015 – TRT/MG – Analista de Sistemas) Um analista de TI está participando

16712855225
do desenvolvimento de um software orientado a objetos utilizando a plataforma

Java. Na abordagem de desenvolvimento adotada, o código é desenvolvido de
forma incremental, em conjunto com o teste para esse incremento, de forma
que só se passa para o próximo incremento quando o atual passar no teste.
Como o código é desenvolvido em incrementos muito pequenos e são
executados testes a cada vez que uma funcionalidade é adicionada ou que o
programa é refatorado, foi necessário definir um ambiente de testes
automatizados utilizando um framework popular que suporta o teste de
programas Java.

A abordagem de desenvolvimento adotada e o framework de suporte à criação

de testes automatizados são, respectivamente,
a) Behavior-Driven Development e JTest.

b) Extreme Programming e Selenium.
c) Test-Driven Development e Jenkins.
d) Data-Driven Development and Test e JUnit.
e) Test-Driven Development e JUnit.
Comentários:
A questão trata do TDD e JUnit.
Gabarito: E
ACERTEI ERREI
16712855225

ACCEPTANCE TEST-DRIVEN DEVELOPMENT (ATDD)
O Acceptance Test-Driven Development (ATDD) é um método ágil de

desenvolvimento de software que se baseia na comunicação entre clientes do
negócio, desenvolvedores e testadores. Ele se difere do TDD, na medida em que
possui um foco maior na comunicação entre os colaboradores. São utilizados testes
de aceitação a partir do ponto de vista dos usuários.
O ATDD é focado na captura de requisitos em testes de aceitação e os utiliza para

guiar o desenvolvimento do sistema. Ele ajuda a assegurar que todos os membros
do projeto entendam precisamente o que é necessário fazer e implementar,
estabelecendo critérios a partir da perspectiva do usuário e criando exemplos
concretos.
As equipes que experimentam ATDD normalmente concluem que apenas o ato de

se definir testes de aceitação ao discutir requisitos resulta numa melhor
compreensão destes requisitos. Os testes em ATDD nos forçam a chegar a um ponto
de acordo concreto sobre o exato comportamento que se espera que o software
deva ter. Entenderam?
A proposta do ATDD é favorecer uma colaboração e comunicação maior entre

todos os envolvidos no desenvolvimento de um produto, o que resulta em um
entendimento mais claro e refinado dos requisitos, possibilitando um acordo entre
ambas as partes do que será desenvolvido durante uma iteração/sprint. No final, o
resultado estará alinhado às expectativas do cliente.
16712855225

KANBAN
Kanban significa Cartão ou Placa Visual, em japonês. O Kanban é um método para

gestão de mudanças com foco na visualização do trabalho em progresso (Work In
Progress), identificando oportunidades de melhorias, tornando explícitas as políticas
seguidas e os problemas encontrados e, por fim, favorecendo uma cultura de
melhoria evolutiva.
Antes de continuar, eu tenho que fazer uma pausa! Há uma certa polêmica sobre
se o Kanban uma metodologia de desenvolvimento de software. David J.
Anderson, pioneiro do Kanban discorda desse argumento. No entanto, é bastante
comum ver algumas bancas tratando o Kanban – sim – como uma metodologia de
desenvolvimento de software. Vamos ver algumas declarações:
“Kanban is not a software development life cycle or project management methodology! It is not a way
of making software or running projects that make software!” – David J. Anderson
“There is no kanban process for software development. At least I am not aware of one. I have never
published one.” David J. Anderson
“It is actually not possible to develop with only Kanban. The Kanban Method by itself does not contain
practices sufficient to do product development.” David J. Anderson
O Kanban pode ser visto como um acelerador para a condução de mudanças ou

até mesmo um método para implantação de mudanças. Ele não prescreve papéis,
práticas ou cerimônias específicas (como faz, por exemplo, Scrum). Em vez disso,
oferece uma série de princípios para otimizar o fluxo e a geração de valor dos
sistemas de entrega de software. 16712855225
Como dito no início, Kanban também é uma espécie de cartaz ou placa visual
contendo vários post-its (aquele papelzinho colorido para colar lembretes). Ele
permite uma melhor visualização do fluxo de trabalho, favorecendo a transparência.
Ademais, permite mudar prioridades facilmente e entregar funcionalidades a
qualquer momento. Não há preocupação com iterações ou estimativas.
Como pode ser visto a partir da imagem abaixo, todo fluxo de trabalho se torna
visível no Kanban. Os limites do Work in Progress são estabelecidos. O fluxo é
contínuo sem requerer estimativas. A equipe assume a responsabilidade sobre o

processo e se auto-organiza para otimizá-lo e para ajudar a resolver seus

problemas. Sacaram?
O Kanban é construído sobre os conceitos de mudança evolucionária. Uma possível

abordagem é começar a entender como funciona atualmente seu sistema de
desenvolvimento de software. Quando conseguir visualizar, medir e gerenciar o
fluxo utilizado, melhore-o um passo por vez, aliviando seu maior gargalo, i.e., o
processo vai evoluindo aos poucos.
Isso é muito diferente do que ocorre, por exemplo, no Scrum – onde se começa
definindo papéis, processos e artefatos. Isso faz do Kanban um método ideal para
utilização em conjunto com processos existentes, que podem ser desde o Scrum até
Cascata. Ele também é excelente em situações em que estruturas organizacionais
inibem mudanças radicais. 16712855225
O Kanban é construído principalmente sob o conceito de melhoria contínua. Ele

somente utiliza mudanças radicais em situações especiais, nas quais mudanças
estruturais são necessárias ou quando sérias mudanças de desempenho precisam
ser realizadas. O modelo é uma boa opção tanto para desenvolvimento de software
quanto para operação e manutenção.
Kanban e Scrum não são opostos. Nada impede que se comece a usar o Scrum e
utilizar o Kanban para impulsionar mudanças futuras. Os projetos com Kanban,
apesar de não insistirem no compromisso com iterações planejadas, são muito bem

controlados, com cadência fixa, visualização permanente, medição do tempo de

ciclo, fluxo de tarefas e ciclos de feedback curtos.
Claro, há diferenças entre ambos: Scrum requer iterações; Kanban não necessitam
de iterações, mas sugere-se que haja uma cadência de entradas e entregas. Quando
o Kanban incorpora iterações, ele é tipicamente chamado Scrumban para diferenciar
do Scrum padrão, uma vez que Scrum não gerencia explicitamente o Work in
Progress e o Kanban não utiliza iterações.
PRINCÍPIOS OU RESTRIÇÕES DO KANBAN
- Comece com o que você tem hoje;
- Estimule a liderança em todos os níveis da organização;
- Visualize cada passo em sua cadeia de valor, do conceito geral até o software que se
possa lançar;
- Limite o Trabalho em Progresso (WIP), restringindo o total de trabalho permitido para
cada estágio;
- Torne explícitas as políticas sendo seguidas;
- Meça e gerencie o fluxo, para poder tomar decisões bem embasadas, além de visualizar
as consequências;
- Identifique oportunidades de melhorias, na qual a melhoria contínua é responsabilidade
de todos.
16712855225
PRÁTICAS DO KANBAN
- Implemente mecanismos de feedback;

- Gerencie e meça o Fluxo de Trabalho;
- Visualize o Processo;
- Limite o WIP (Work In Progress);
- Torne as políticas dos processos explícitas;
- Melhore colaborativamente e com métodos científicos.

Professor, o que é WIP? Galera, são as tarefas que estão em execução em

determinado ponto do processo. Por que devemos limitar o WIP? Porque quanto
maior o número de tarefas em andamento em determinado ponto do processo,
maior o tempo que a tarefa fica no fluxo. Então ele deve ser pequeno? Não, ele não
deve ser muito pequeno nem muito grande.
Em geral, se for muito pequeno, qualquer limitação pode parar o processo de

desenvolvimento; se for muito grande, i.e., muitas tarefas simultâneas levam a
grandes perdas e confusões. Professor, então qual o tamanho ideal? Bem, isso não
existe! Não há um número mágico, é necessário descobrir o tamanho
empiricamente de acordo com o contexto da organização.
Galera, nós poderíamos falar muito mais sobre Kanban! No entanto, revirei todos os
bancos de provas e só encontrei até hoje duas questões sobre esse assunto. Dessa
forma, acho melhor parar por aqui. Bem, eu utilizo o Trello para minhas atividades
pessoais e profissionais (recomendo bastante!). Há também o KanbanFlow,
Kanbanery, Leankit, Visual WIP, entre outras! Baixem e divirtam-se...
16712855225

(CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) Kanban é um

método de desenvolvimento de software que tem como uma de suas práticas o
gerenciamento do fluxo de trabalho, que deve ser monitorado, medido e
reportado a cada estado do fluxo.
Comentários:
PRINCÍPIOS OU RESTRIÇÕES DO KANBAN
- Comece com o que você tem hoje;
- Estimule a liderança em todos os níveis da organização;
- Visualize cada passo em sua cadeia de valor, do conceito geral até o software que se
possa lançar;
- Limite o Trabalho em Progresso (WIP), restringindo o total de trabalho permitido para
cada estágio;
- Torne explícitas as políticas sendo seguidas;
- Meça e gerencie o fluxo, para poder tomar decisões bem embasadas, além de visualizar
16712855225
as consequências;
- Identifique oportunidades de melhorias, na qual a melhoria contínua é responsabilidade
de todos.
Antes de continuar, eu tenho que fazer uma pausa! Há uma certa polêmica sobre se
o Kanban é uma metodologia de desenvolvimento de software. David J. Anderson, o
criador do Kanban discorda desse argumento. No entanto, é bastante comum ver
algumas bancas tratando o Kanban – sim – como uma metodologia de
desenvolvimento de software. Vamos ver algumas declarações do criador:

Como já foi explicado, o fluxo de trabalho é constantemente monitorado a cada

mudança, por meio de um quadro de fluxo.
Gabarito: C
(FGV - 2013 – MPE/MS - Analista de Sistemas) Kanban é um dos métodos ágeis

mais recentes e sofreu grande influência do movimento “Lean”, surgido nos anos
1980. São práticas comuns a esse método:
a) limitar o WIP (Work In Progress) e uma visualização explícita do fluxo de

trabalho.
b) integração Contínua e gerenciamento de configuração.
c) limitar o WIP (Work In Progress) e gerenciamento de configuração.
d) gerenciar o fluxo de trabalho e manter estimativas previamente definidas.
e) melhoria contínua e nunca limitar o WIP para evitar folgas no sistema de
trabalho.
Comentários:
PRÁTICAS DO KANBAN
- Implemente mecanismos de feedback;

16712855225
Conforme vimos em aula, as práticas são: limitação do WIP e visualização do fluxo

de trabalho.
Gabarito: A
(FGV - 4 – TJ/GO - Analista de Sistemas) Scrum e Kanban são metodologias

de gerenciamento de projetos de software populares entre praticantes do
desenvolvimento ágil. Um aspecto de divergência entre as duas metodologias é:
a) processo incremental;

b) processo iterativo;
c) uso de quadro de tarefas;
d) apresentação do estágio de desenvolvimento de uma tarefa;
e) valorização de feedback.
Comentários:
Claro, há diferenças entre ambos: Scrum requer iterações; Kanban não necessitam de
iterações, mas sugere-se que haja uma cadência de entradas e entregas. Quando o
Kanban incorpora iterações, ele é tipicamente chamado Scrumban para diferenciar
do Scrum padrão, uma vez que Scrum não gerencia explicitamente o Work in
Progress e o Kanban não utiliza iterações.
Conforme vimos em aula, Kanban não necessita de iterações.
Gabarito: B
(FGV - 4 – PROCEMPA - Analista de Sistemas – Kanban considera a

utilização de uma sinalização ou registro visual para gerenciar o limite de
atividades em andamento, indicando se um novo trabalho pode ou não ser
iniciado e se o limite acordado para cada fase está sendo respeitado.
Comentários:
PRÁTICAS DO KANBAN
- Implemente mecanismos de feedback; 16712855225

Conforme vimos em aula, a questão está perfeita.
Gabarito: C

(CESPE - 2015 - TCU- Analista de Sistemas) O método para a implantação de

mudanças denominado Kanban não prevê papéis nem cerimônias específicas.
Comentários:
O Kanban pode ser visto como um acelerador para a condução de mudanças ou até
mesmo um método para implantação de mudanças. Ele não prescreve papéis,
práticas ou cerimônias específicas (como faz, por exemplo, Scrum). Em vez disso,
oferece uma série de princípios para otimizar o fluxo e a geração de valor dos sistemas
de entrega de software.
Conforme vimos em aula, a questão está perfeita – não se prevê papéis ou

cerimônias.
Gabarito: C
ACERTEI ERREI
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

METODOLOGIAS ÁGEIS
(CESPE – 2012 – TCE/ES – Auditor de Controle Externo – Tecnologia da

Informação) Em virtude de as metodologias ágeis gerarem excessiva
documentação, a gestão do conhecimento depende diretamente dos
programadores envolvidos no projeto.
(CESPE – 2011 – EBC – Analista de Sistemas) O que os métodos ágeis buscam é

como evitar as mudanças desde o início do projeto e não a melhor maneira de
tratar essas mudanças.
(CESPE – 2010 – BASA – Técnico Científico – Arquitetura de Tecnologia)

Desenvolvimento ágil de software (Agile Software Development) ou método ágil
é aplicado, principalmente, a grandes corporações, uma vez que permite
produzir grandes sistemas de forma ágil.
(CESPE – 2010 – TCU – Auditor Federal de Controle Externo – Tecnologia da

Informação) A agilidade não pode ser aplicada a todo e qualquer processo de
software.
(CESPE – – UNIPAMPA – Analista de Sistemas) XP, Scrum e Cristal são

exemplos de modelos ágeis de desenvolvimento de sistemas.
(CESPE - 2011 - EBC - Analista - Engenharia de Software) Considerando o

conceito de metodologia ágil em apreço, é correto afirmar que as seguintes
metodologias são ágeis: XP (Extreme Programming), Scrum, Crystal, FDD
16712855225
(Feature Driven Development), DSDM (Dynamic Systems Development Method)

e Open Source Software Development.
(CESPE - 2013 - CNJ - Técnico Judiciário - Programação de Sistemas) O

desenvolvimento ágil de sistemas consiste em uma linguagem de modelagem
que permite aos desenvolvedores visualizarem os produtos de seu trabalho em
gráficos padronizados.
(CESPE - 2011 - EBC - Analista - Engenharia de Software) É conveniente que o

contrato, entre cliente e fornecedor, para o desenvolvimento de um sistema
computacional, contenha a lista de requisitos para o software. Contudo, os

métodos ágeis de desenvolvimento preconizam que o referido contrato

estabeleça o preço, a ser pago pelo cliente, com base no tempo necessário para
o desenvolvimento do sistema e não com base no conjunto de requisitos.
(CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Metodologias de

desenvolvimento ágil enfocam atividades de projeto e implementação,
desconsiderando as atividades de elicitação de requisitos e a produção de
documentação.
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (CESPE)

SCRUM
(CESPE - 2013 - ANP - Analista Administrativo - Área 5) De acordo com a

metodologia Scrum, a constituição ideal da equipe de desenvolvimento para que
o trabalho se mantenha ágil deve ser de menos de três pessoas.
(CESPE - 2012 - ANAC - Analista Administrativo - Área 4) O único papel definido

pelo Scrum com autoridade para cancelar uma Sprint é o do product owner.
(CESPE - 2012 - ANAC - Analista Administrativo - Área 4) Uma sprint do Scrum

tem duração prevista de 2 meses.
(CESPE - 2010 - Banco da Amazônia - Técnico Científico - Arquitetura de

Tecnologia) O Scrum é utilizado, como função primária, para o gerenciamento
de projetos de desenvolvimento de software, mas também tem sido usado como
extreme programming e outras metodologias de desenvolvimento.
Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um
grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum.
(CESPE - 2013 - ANTT - Analista Administrativo – Analista de Sistemas) Entre os

vários papéis do SCRUM, o product owner é a única pessoa responsável por
gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
(CESPE - 2013 - SERPRO - Analista de Informática – Analista de Sistemas) Scrum

é um processo de desenvolvimento que tem como ponto de partida um
16712855225
conjunto de requisitos bem definidos.
(CESPE - 2013 – TCE-RO - Analista de Informática – Analista de Sistemas) Na

metodologia Scrum, a equipe trabalha nos processos e não há cargos na equipe.
Como um dos papéis necessários, o Scrum Master deve garantir que o processo
seja entendido e atuar como facilitador para ajudar a equipe.
(CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) Em um

projeto gerido com a metodologia Scrum, um produto estará, ao final de cada
sprint, completamente testado, estando 100% completos todos os requisitos do
product backlog.

(CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) O escopo,

a importância e a estimativa de um Sprint do Scrum são definidos pelo product
owner.
10. (CESPE - 2012 – BASA - Analista de Informática – Analista de Sistemas) A

metodologia Scrum, ágil para gerência de projetos, baseia-se em ciclos de 30
dias, denominados sprints, em que se trabalha para alcançar objetivos bem
definidos.
11. (CESPE - 2011 – ECT - Analista de Informática – Analista de Sistemas) Para que
se obtenha sucesso na utilização do Scrum, o cliente deve se tornar parte da
equipe de desenvolvimento do software, participando diretamente do processo.
12. (CESPE - 2011 – MEC - Analista de Informática – Analista de Sistemas) O

framework scrum engloba conceitos como times scrum, eventos com duração
fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração
fixa: a reunião de planejamento da versão para entrega, a sprint, a reunião diária,
a revisão da sprint e a retrospectiva da sprint.
13. (CESPE - 2011 – MEC - Analista de Informática – Analista de Sistemas) Produto

da metodologia Scrum, o documento product backlog contém os requisitos
definidos a partir da visão do cliente e é utilizado novamente no final do sprint
para revisão ou modificações dos requisitos inicialmente definidos.
14. (CESPE - 2010 – MPU - Analista de Informática – Analista de Sistemas) Um

princípio chave do Scrum é o reconhecimento de que desafios
fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-
se uma abordagem tradicional de controle. O Scrum adota uma abordagem
16712855225
empírica, aceitando que o problema não pode ser totalmente entendido ou

definido, focando na maximização da habilidade da equipe de responder de
forma ágil aos desafios emergentes.
15. (CESPE - 2010 – MPU - Analista de Informática – Analista de Sistemas) A

metodologia Scrum é facilitada por um scrum master, que atua como um
mediador entre a equipe e qualquer influência desestabilizadora, além de
assegurar que a equipe esteja utilizando corretamente as práticas de Scrum,
motivando e mantendo o foco na meta da sprint.

16. (CESPE - 2012 – TER-RJ - Analista de Informática – Analista de Sistemas) A

metodologia scrum prega que a equipe complete e entregue partes do produto
final constantemente ao final de cada interação. Essa interação deve ser curta e
possuir tempo de execução definido previamente.
17. (CESPE - 2013 – ANCINE – Analista de Sistemas) Na reunião de planejamento do

sprint backlog, se o product owner afirmar que todos os requisitos do produto
foram identificados, é correto concluir que o backlog do produto está completo,
visto que este é uma lista ordenada de todos os requisitos necessários para o
desenvolvimento do produto.
18. (CESPE - 2013 – ANCINE – Analista de Sistemas) Se for averiguado, em uma

organização, que o Scrum Master gerencia o backlog do produto, é correto
afirmar que houve falha na execução de papéis, visto que cabe unicamente ao
product owner gerenciar o backlog do produto.
19. (CESPE - 2010 – MPU – Analista de Sistemas) Scrum é um processo ágil de

produção de software que mantém o foco na entrega da maior parte do
produto, no menor tempo possível.
(CESPE - 2013 - INPI - alista de Planejamento - Desenvolvimento e

Manutenção de Sistemas) No Scrum, o Product Owner (PO) é responsável por
definir a visão do produto e remover os impedimentos, enquanto o Scrum
Master (SM) é responsável por elaborar e manter o Product Backlog, bem como
por ajudar o PO a executar suas atividades diárias.
21. (CESPE - 2013 - ANP - Analista Administrativo - Área 5) O ciclo de vida da

metodologia Scrum se divide nas fases de pré-planejamento, desenvolvimento
e pós-planejamento. O documento denominado product backlog é gerado na
16712855225
fase de desenvolvimento.
(CESPE - 2012 - TCE-ES - Auditor de Controle Externo - Tecnologia da

Informação) O Product Backlog, um dos artefatos utilizados na metodologia ágil
denominada Scrum, constitui-se da lista priorizada de todos os requisitos do
produto final.
(CESPE - 2014 – ANATEL – Arquitetura de Soluções) O Scrum é um conjunto

simples e eficaz de regras e ferramentas que são utilizadas para maximizar
resultados. O ScrumMaster exerce o papel de facilitador e motivador da equipe,

além de garantir que as regras e as ferramentas sejam utilizadas com vistas à

criatividade do trabalho e ao retorno do investimento.
24. (CESPE - - TCU – Analista de Sistemas Conforme a metodologia SCRUM,

Sprint Planning Meeting é uma reunião de planejamento em que o Scrum Master
prioriza os itens do Product Backlog e a equipe seleciona as atividades a serem
implementadas no período.
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (FCC)

SCRUM
(FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software) Um

dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software é a implantação de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco
previsíveis. Para tanto, o gerenciamento é distribuído por meio de três agentes
independentes que são:
a) Product Owner, Scrum Team e Scrum Master.

b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.
(FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte) Os

princípios Scrum são usados para guiar as atividades de desenvolvimento dentro
de um processo que incorpora as seguintes atividades de arcabouço: requisitos,
análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas
de trabalho ocorrem dentro de um padrão de processo chamado:
a) pendência.
b) iterator.
c) demo.
d) história de usuário.
e) sprint. 16712855225
(FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação

Na fase de desenvolvimento do Scrum, o software é desenvolvido em processos
iterativos denominados:
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.

(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas) Em

reunião, toda conversação é restringida às respostas dos elementos às perguntas
colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até
a próxima reunião?"
As Scrum meetings ocorrem:
a) sempre que necessário.

b) ocasionalmente.
c) uma vez por semana.
d) duas vezes por semana.
e) diariamente.
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI - A) Em relação às

regras do Scrum, é INCORRETO afirmar:
a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe
de trabalho não superior a 10 pessoas.
b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar

um novo Sprint, baseando num novo Sprint Backlog.
c) As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no

mesmo local e não devem durar mais que 30 minutos.
d) Toda conversação restringe as respostas dos participantes às três perguntas

do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades
encontrou durante o seu trabalho? O que planeja desenvolver até a próxima
reunião? 16712855225
e) Com base nas respostas às três perguntas, o Scrum Master deve

imediatamente tomar decisões, quando necessárias, para remover todas as
situações que impeçam a agilidade do trabalho.
(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas) No

contexto das regras do SCRUM, é correto afirmar:
a) Durante a realização do Sprint, o Backlog pode ser modificado por qualquer

um dos elementos da equipe, desde que acordado nas reuniões semanais.

b) O Sprint deve ser realizado num período não superior a 30 dias e ter um
objetivo bem claro, baseado no Backlog.
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar

necessário, em qualquer momento no decorrer do Sprint.
d) Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um

rumo não desejável, novas funcionalidades devem ser implementadas para
garantir o prazo do projeto.
e) O foco na produtividade se estende às Scrum meetings e a conversação é

pautada em discussões por toda a equipe.
(FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas - B) No

SCRUM, o produto final, a data final e o custo do projeto são determinados ao
longo do projeto.
(FCC - – AFR/SP – Analista de Sistemas O conceito de sprint aplica-se ao

modelo ágil do processo de engenharia de software denominado:
a) Crystal.
b) XP.
c) DAS.
d) DSDM.
e) Scrum
(FCC - – TRE/CE – Analista de Sistemas No SCRUM, sprint é:
a) um representante dos stakeholders e do negócio.

16712855225
b) uma lista de requisitos que tipicamente vêm do cliente.
c) uma lista de itens priorizados a serem desenvolvidos para um software.
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software

pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.

10. (FCC - – TRT/SC – Analista de Sistemas SCRUM é um framework baseado

no modelo ágil. No SCRUM,
a) o scrum team é a equipe de desenvolvimento, necessariamente dividida em

papéis como analista, designer e programador. Em geral o scrum team tem de
10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou

histórias de usuários) são mantidas em uma lista chamada de scrum board.
c) o scrum master é um gerente no sentido dos modelos prescritivos. É um líder,

um facilitador e um solucionador de conflitos. É ele quem decide quais requisitos
são mais importantes.
d) um dos conceitos mais importantes é o sprint , que consiste em um ciclo de

desenvolvimento que, em geral, tem duração de 4 a 7 dias.
e) o product owner tem, entre outras atribuições, a de indicar quais são os

requisitos mais importantes a serem tratados em cada sprint . É responsável por
conhecer e avaliar as necessidades dos clientes.
11. (FCC - – TCE/SE – Analista de Sistemas) Aceita a imprevisibilidade do

desenvolvimento de software e a contorna através da adaptação constante.
Destaca-se das demais metodologias ágeis por dar mais enfoque à área de
gerenciamento. Seu nome tem origem em um esporte quando jogadores de
cada time colaboram entre si numa tentativa de avançar juntos pelo campo
adversário. Tais características estão presentes no processo:
a) UP. 16712855225
b) Crystal.
c) XP.
d) DSDM.
e) Scrum.
12. (FCC - – DPE/SP – Analista de Sistemas) Na engenharia de software, um

processo iterativo denominado sprint, que segue o ciclo PDCA para entregar,
num período de 30 dias aproximadamente, um incremento do software pronto,
caracteriza a metodologia ágil:
a) SCRUM.

b) DSDM.
c) Crystal.
d) FDD.
e) XP.
13. (FCC - – TRE- – Analista de Sistemas) Analise o texto:
O Scrum enfatiza o uso de um conjunto de padrões de processos de software que

provaram ser eficazes para projetos com prazo de entrega apertados, requisitos
mutáveis e críticos de negócio. Cada um desses padrões de processos define um
conjunto de ações de desenvolvimento. Uma dessas ações consiste em manter
uma lista com prioridades dos requisitos ou funcionalidades do projeto que
fornecem valor comercial ao cliente. Os itens podem ser adicionados a esse
registro em qualquer momento. O gerente de produto avalia o registro e atualiza
as prioridades conforme requisitado.
A lista citada no texto é conhecida como:
a) urgências scrum.
b) registro ágil de requisitos.
c) alterações scrum.
d) registro pendente de trabalhos (Backlog).
e) registro iterativo de desenvolvimento (sprint).
14. (FCC - – TRT/MG – Analista de Sistemas) Com relação ao Scrum, considere:
I. O Product Owner, ou dono do produto, é responsável por garantir que o

Scrum seja entendido e aplicado. Faz isso para garantir que o Time Scrum adere
à teoria, práticas e regras do Scrum. É um servo-líder para o Time Scrum.
16712855225
II. O Scrum Master é o responsável por maximizar o valor do produto e do

trabalho do Time de Desenvolvimento. Como isso é feito pode variar
amplamente nas organizações, Times Scrum e indivíduos.
III. O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante

o qual um “Pronto", versão incremental potencialmente utilizável do produto, é
criado.
Está correto o que consta APENAS em:

a) I e II.
b) III
c) II e III.
d) II.
e) I e III.
15. (FCC - – TRT/RS – Analista de Sistemas) No Scrum, a lista de funcionalidades

a serem implementadas em cada projeto que apresenta uma visão dos requisitos
de forma mais voltada à maneira como a equipe vai desenvolvê-los, e não em
uma visão de alto nível voltada às necessidades diretas do cliente, é conhecida
como:
a) product backlog.
b) scrum backlog.
c) sprint backlog.
d) daily backlog.
e) daily sprint.
16. (FCC - – TRF/2 – Analista de Sistemas) Segundo Roger S. Pressman, em seu

livro Engenharia de Software, 7a edição, os princípios do Scrum são consistentes
com o manifesto ágil e são usados para orientar as atividades de
desenvolvimento dentro de um processo que incorpora as atividades estruturais
de requisitos, análise, projeto, evolução e entrega. Em cada atividade
metodológica, ocorrem tarefas a realizar dentro de um padrão de processo
chamado:
a) process backlog.
b) scrum master.
c) product owner. 16712855225
d) backlog.
e) sprint.
17. (FCC - – AL/PE – Analista de Sistemas) O Scrum define reuniões e eventos

que devem ser realizados de forma a oferecer oportunidades formais para
inspeção e adaptação, cujos tempos de duração são referenciais máximos
recomendados. Considere:
I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog

do Produto, se necessário.

II. É uma reunião time-boxed de 3 horas para uma Sprint de um mês, sendo uma
oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para
melhorias a serem aplicadas na próxima Sprint.
III. É um evento time-boxed de 15 minutos, para que a Equipe de

Desenvolvimento possa sincronizar as atividades e criar um plano para as
próximas 24 horas.
IV. É um time-box de 8 horas para uma Sprint de um mês de duração.
Estão de acordo com as definições I, II, III e IV, respectivamente, as denominações:
a) planejamento da Sprint - revisão da Sprint - daily Scrum - retrospectiva da

Sprint.
b) revisão da Sprint - retrospectiva da Sprint - daily Scrum - planejamento da
Sprint.
c) revisão da Sprint - planejamento da Sprint - 15 min break - retrospectiva da
Sprint.
d) retrospectiva da Sprint - planejamento da Sprint - short meeting - revisão da
Sprint.
e) planejamento da Sprint - retrospectiva da Sprint - daily Scrum - revisão da
Sprint.
16712855225


SCRUM
(ESAF - 2012 – CGU – Analista de Sistemas) No Scrum os projetos são divididos

em ciclos chamados de:
a) Sp-Cycles.
b) Springs.
c) Sprints.
d) Strengths.
e) Set-prints.
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (CESPE)

EXTREME PROGRAMMING
(CESPE – – SECONT/ES – Auditor do Estado – Tecnologia da Informação)

Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente
para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos
de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses métodos está o extreme programming, que envolve um número de
práticas, como o planejamento incremental, a definição de um ritmo de trabalho
sustentável e a divisão das equipes de trabalho por meio da especialização de
seus membros.
(CESPE – 2012 – MPE/PI – Analista Ministerial – Cargo 6) O XP (Extreme

Programming) é um método ágil, que preconiza a criação de um caso de teste
unitário antes do início da codificação.
(CESPE – 2011 – EBC – Analista de Sistemas – Engenharia de Software) O XP

segue um conjunto de valores, princípios e regras básicas que visam alcançar
eficiência e efetividade no processo de desenvolvimento de software. Os valores
são cinco: comunicação, simplicidade, feedback, coragem e respeito.
(CESPE – 2010 – TRE/BA – Técnico Judiciário – Programação de Sistemas) Em XP,

a prática denominada programação em pares (pair programming) é realizada
por um desenvolvedor em dois computadores, com o objetivo de aumentar a
produtividade.
(CESPE – 2011 – STM – Analista Judiciário – Analista de Sistemas) O Extreme

16712855225
Programming (XP), que se inclui entre os métodos ágeis, apresenta, entre outras,
as seguintes características: pequenos releases, projeto simples, refactoring,
programação em pares e propriedade coletiva.
(CESPE – 2010 – ABIN – Oficial Técnico de Inteligência – Desenvolvimento e

Manutenção de Sistemas) Na Extreme Programming, os requisitos são expressos
como cenários e implementados diretamente como uma série de tarefas. O
representante do cliente faz parte do desenvolvimento e é responsável pela
definição de testes de aceitação do sistema.

(CESPE - 2012 – ANAC – Analista de Sistemas) Para o método ágil de

desenvolvimento conhecido como extreme programming, todos os requisitos
funcionais são expressos como cenários (histórias do usuário) que são
implementados diretamente como uma série de tarefas.
(CESPE - 2012 – ANAC – Analista de Sistemas) A técnica conhecida como

refactoring é constantemente aplicada no desenvolvimento baseado no método
ágil extreme programming.
(CESPE - 2012 – ANAC – Analista de Sistemas) No modelo extreme

programming, os testes de software só são realizados na etapa final de
desenvolvimento do software e, somente nessa etapa, os programadores
trabalham, obrigatoriamente, em pares, utilizando cada um o próprio
computador.
10. (CESPE - 2012 – ANAC – Analista de Sistemas) Na metodologia ágil XP (extreme

programming), as metáforas são formas de transmitir ideias complexas de
maneira simples, ou seja, utiliza-se uma linguagem simples entre a equipe e o
cliente, com o objetivo de que, entre as inúmeras variáveis de controle em
projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco
no tempo, em detrimento do planejamento do release.
11. (CESPE - 2013 – ANTT – Analista de Sistemas) São práticas ou princípios

recomendados no modelo de desenvolvimento de software XP (eXtreme
Programming) proposto por Kent Beck: programação em pares; semana de
trabalho de 40 horas; refatoração sem piedade; desenvolvimento orientado a
testes TDD (Test Driven Development); e desenvolvimento de metáforas
arquiteturais.
16712855225
12. (CESPE - – IPEA – Analista de Sistemas) A extreme programming (XP) é um

método de desenvolvimento ágil. Nele, os requisitos são expressos como
cenários implementados diretamente como uma série de tarefas.
13. (CESPE - 2010 – MPU – Analista de Sistemas) Extreme programming (XP) é

embasado em requisitos conhecidos, definidos de antemão, que não sofram
muitas alterações, devendo ser usado por equipes de pequeno porte, formadas
por representantes de todos os stakeholders.

14. (CESPE - – TRE.MG – Analista de Sistemas - Extreme programming é um

método centrado no usuário, na produtividade do desenvolvimento e na
documentação de apoio.
15. (CESPE - 2009 – TRE.BA – Analista de Sistemas) A metodologia XP prevê valores

e princípios básicos para serem considerados durante o desenvolvimento de
software. Feedback, coragem e respeito são exemplos de valores; mudanças
incrementais, abraçar mudanças e trabalho de qualidade são exemplos de
princípios básicos.
16. (CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Os

quatro valores fundamentais da metodologia XP são: comunicação, simplicidade,
feedback e coragem.
17. (CESPE - 2006 – TSE – Analista de Sistemas – Processos de desenvolvimento

que adotam o modelo ágil enfatizam a comunicação entre participantes, a
realimentação e a simplicidade. Para atingir tais práticas, o Extreme Programming
(XP) advoga práticas como a posse coletiva do código.
18. (CESPE - - ANAC - Analista Administrativo - Tecnologia da Informação)

Extreme Programming é um modelo de processo de desenvolvimento de
software para equipes com grande número de pessoas, que desenvolvem
software com base em requisitos vagos e que são modificados rapidamente.
19. (CESPE - - ANTAQ - Analista Administrativo - Informática) O extreme

programming (XP) constitui método ágil de desenvolvimento de software. Uma
das práticas que se enquadram nos princípios dos métodos ágeis é a
programação em pares, que promove o compartilhamento da autoria do código
do sistema. Além dessa vantagem, a programação em pares atua como processo
16712855225
informal de revisão porque cada linha de código é vista por pelo menos duas
pessoas.
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) O processo XP (extreme programming) envolve a
realização das atividades de planejamento, de projeto, de codificação e de teste.
21. (CESPE - 2013 - STF - Analista Judiciário - Análise de Sistemas de Informação) XP

(Extreme Programming) é uma metodologia ágil voltada para equipes pequenas
e médias que desenvolvam software baseado em requisitos vagos e se
caracteriza por possibilitar modificações rápidas.

(CESPE - 2013 - TCE-RO - Analista de Informática) No método XP (eXtreming

programming), os sistemas são concebidos a partir de uma metáfora e descritos
em estórias do usuário. Esse método busca facilitar a comunicação com o cliente,
entendendo a realidade deste e guiando o desenvolvimento com o uso de
estória simples.
(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) XP é um método

de desenvolvimento de software em que os requisitos são especificados em user
stories; requisitos, arquitetura e design surgem durante o curso do projeto; e o
desenvolvimento ocorre de maneira incremental.
24. (CESPE - – PRODEST - Analista de Sistemas) Projetar detalhadamente todo

o software antes de iniciar a sua implementação é uma prática recomendada
pelo XP. O software deve ser projetado para atender tanto aos requisitos atuais
quanto aos potenciais requisitos futuros. Para atingir esse objetivo, são
analisados os possíveis cenários de evolução futura e são empregados padrões
de projeto para facilitar a manutenção.
(CESPE - – PRODEST - Analista de Sistemas) Constituem práticas

recomendadas pelo XP a colocação rápida de uma versão simples em produção,
a liberação das novas versões em curtos intervalos de tempo, a programação
em duplas, a refatoração (refactor) dos códigos produzidos, a adoção de
padrões para a codificação; a integração e o teste contínuos de códigos; a
limitação em 40 horas da carga de trabalho semanal.
(CESPE - – PRODEST - Analista de Sistemas) O XP é um processo que visa

a um desenvolvimento ágil e portanto não recomenda os testes de unidade, pois
eles consomem muitos recursos. Durante o desenvolvimento, o primeiro teste
16712855225
recomendado é o smoke test que foca os detalhes de funcionamento. O smoke

test é realizado após as unidades serem integradas. Após o smoke test, é
realizado o teste de sistema.


EXTREME PROGRAMMING
(FCC - 2012 - TST - Técnico Judiciário – Programação O XP (Extreme

Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele:
a) recomenda que duas pessoas trabalhem juntas para criar o código

correspondente a uma história.
b) recomenda que a equipe XP e os clientes trabalhem de forma separada para

não mudar o compromisso básico definido para a versão a ser entregue.
c) segue rigorosamente o princípio FDD - Feature Driven Development.
d) recomenda que depois que as histórias forem desenvolvidas e o trabalho

preliminar do projeto for feito, a equipe XP avance diretamente para o código.
e) inclui um conjunto de regras e práticas que ocorrem no contexto de 3

atividades de arcabouço: projeto, implementação e entrega.
(FCC - 2007 - TRE-SE - Analista Judiciário - Tecnologia da Informação Na XP

(eXtreme Programming):
a) deve-se usar o modelo em cascata para o desenvolvimento do software.
b) os programadores desenvolvem o software criando primeiramente os testes.

16712855225
c) deve ser evitada a comunicação pessoal entre clientes e desenvolvedores,

sempre dando preferência a outros meios de comunicação mais formais.
d) os programadores desenvolvem o software fazendo todos os testes possíveis

no término do desenvolvimento.
e) deve-se projetar todas as funções possíveis com a máxima previsão do que

ocorrerá no futuro, antes do desenvolvimento do software, a fim de evitar
alterações desnecessárias.

(FCC - 1 – TRE/RS - Analista Judiciário - Tecnologia da Informação) No

eXtreme Programming, XP:
a) o código é integrado e testado depois de alguns dias e, no máximo, até o final

da semana.
b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes),

preferencialmente num único computador.
c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma

equipe pode adotar as regras de outra equipe.
d) releases quando complexos não podem deixar de fora os requisitos de

negócio de maior valor para o cliente.
e) módulos não são propriedade de nenhum desenvolvedor; todo

desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.
(FCC - – TRT/MT – Analista de Sistemas NÃO se aplica à disciplina de

desenvolvimento de software extreme programming (XP):
a) Usa notações próprias para construir os diversos produtos de trabalho do

projeto.
b) Encoraja a refabricação para modificar um sofware sem alterar o

comportamento externo do código.
c) Recomenda que dois programadores trabalhem juntos no mesmo

computador para escrever um código. 16712855225
d) Baseada em valores de simplicidade, comunicação, feedback e coragem.
e) Adota como um elemento-chave a criação de testes unitários antes da

codificação começar.
(FCC - – MPE/RN – Analista de Sistemas Refactoring, programação em

pares e Stand-up Meeting são características das práticas do:
a) PRINCE2.
b) Rational Unified Process.

c) Extreme programming.
d) PMBOK.
e) SCRUM.
(FCC - – MPE/AP – Analista de Sistemas O Extreme Programming (XP) é,

talvez, o mais conhecido e mais utilizado dos métodos ágeis. Dentre suas práticas
se encontram programação em pares, integração contínua, refatoração e:
a) propriedade coletiva, que garante uma participação nos lucros aos membros
da equipe de desenvolvimento, técnica que incentiva e aumenta o desempenho
de toda a equipe.
b) envolvimento do cliente apenas na fase final do sistema, fator que difere de

outras metodologias como SCRUM e TDD e confere agilidade ao processo de
desenvolvimento.
c) processo de desenvolvimento contínuo, em que a equipe se mantém focada

no sistema até que uma funcionalidade específica seja entregue, comumente
agregando horas extras ao turno de trabalho.
d) utilização de técnicas de ofuscação do código fonte, trazendo segurança e

garantindo que apenas a equipe de desenvolvimento poderá ter acesso a este
código
e) desenvolvimento incremental e sustentado por meio de pequenos e

frequentes releases do sistema. Os requisitos são baseados em cenários ou em
simples histórias de clientes.
(FCC - – MPE/PE – Analista de Sistemas Dentre as práticas do método ágil

16712855225
Extreme Programming (XP), está a prática de propriedade coletiva. É correto

afirmar que, nessa prática,
a) os trabalhos são desenvolvidos em conjunto, para que um programador possa

analisar o trabalho do outro.
b) cada projeto é realizado para atender às necessidades globais dos usuários,

focando na coletividade da distribuição da informação.
c) os pares de desenvolvedores trabalham em todas as áreas do sistema, de

modo que não se desenvolvam ilhas de expertise.

d) grandes quantidades de horas extras não são consideradas aceitáveis, pois o

resultado final, muitas vezes, é a redução da qualidade do código e da
produtividade a médio prazo, sendo que o indivíduo pode afetar o desempenho
de todo o time.
e) um representante do usuário final do sistema deve estar disponível todo o

tempo à equipe de desenvolvimento. Nesse modelo de desenvolvimento, o
cliente é membro da equipe e participa da responsabilidade do código
desenvolvido.
(FCC - – TCE/AL – Analista de Sistemas Originalmente, o único produto da

atividade de Projeto que é realizado como parte do processo XP (Extreme
Programming):
a) é a definição do caso de uso de contexto.

b) são os cartões CRC.
c) são os diagramas de objetos.
d) são os diagramas de seqüência.
e) é a codificação, feita em pares.
(FCC - – TRE/RN – Analista de Sistemas Considere as seguintes

características:
I. Propriedade coletiva.
II. Integração contínua.
III. Metáfora.
Dentre as práticas componentes da Extreme Programming, aplica-se o que consta

16712855225
em:
a) I, apenas.
b) II, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
10. (FCC - – TRT/23 – Analista de Sistemas No desenvolvimento de software

em Extreme Programming (XP) há uma confiança muito grande na sinergia entre
as práticas, já que os pontos fracos de cada uma são superados pelos pontos

fortes de outras. Dentre elas, aquela em que o código fonte não tem dono e
ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim,
que a equipe conheça todas as partes do sistema, é chamada de:
a) Whole Team (Time Coeso).

b) Sustainable Pace (Ritmo Sustentável).
c) Pair Programming (Programação em Pares).
d) Collective Ownership (Posse Coletiva).
e) Coding Standards (Padrões de Codificação).
11. (FCC - – TRE/RN – Analista de Sistemas Assegurar que a equipe se

concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite
fazer o que poderia vir a ser necessário, mas ainda não se provou essencial. Este
é um dos cinco valores fundamentais do XP (Extreme Programming),
denominado:
a) coragem.
b) respeito.
c) comunicação.
d) simplicidade.
e) feedback.
12. (FCC - – TJ/PI – Analista de Sistemas XP (eXtreme Programming) é uma

metodologia ágil para equipes pequenas e médias que desenvolverão software
com requisitos vagos e em constante mudança. Para isso, adota a estratégia de
constante acompanhamento e realização de vários pequenos ajustes durante o
desenvolvimento de software. Para aplicar os valores e princípios durante o
desenvolvimento de software, a XP propõe uma série de práticas, sendo uma
delas: sempre que produzir uma nova funcionalidade, nunca esperar uma
16712855225
semana para integrar à versão atual do sistema a fim de evitar o aumento da

possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática
é denominada:
a) Time Coeso.
b) Refatoração.
c) Integração Contínua.
d) Desenvolvimento Orientado a Testes.
e) Ritmo Sustentável.

13. (FCC - – TJ/PE – Analista de Sistemas Nos métodos ágeis XP e Scrum, as

entregas de partes funcionais do projeto são divididas em ciclos, geralmente
compreendidos no período de 1 a 4 semanas. Estes ciclos denominam-se,
respectivamente,
a) iterações e sprint.
b) reunião de planejamento e backlog.
c) período de entrega e reunião de revisão.
d) backlog e planejamento da produção.
e) entrega e retrospectiva.
16712855225


FDD
(FCC - 2010 – TRF/4 - Analista de Sistemas) A Feature Driven Development (FDD)

é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto
afirmar:
a) Não pode ser combinada a outras técnicas para a produção de sistemas.
b) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista

de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e
Implementar por Funcionalidade.
c) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de

cada categoria, os papéis são atribuídos a um único participante que assume a
responsabilidade pelo papel.
d) Mantém seu foco apenas na fase de modelagem.
e) Mantém seu foco apenas na fase de implementação.
(FCC - 2014 – TRF/3 - Analista de Sistemas) Os modelos ágeis de desenvolvimento

de software têm menos ênfase nas definições de atividades e mais ênfase na
pragmática e nos fatores humanos do desenvolvimento. Um destes modelos
enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 −
Concepção e Planejamento e 2 − Construção. A fase de Concepção e
Planejamento possui três disciplinas (chamadas de processos): Desenvolver
16712855225
Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por

funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos):
Detalhar por Funcionalidade e Construir por Funcionalidade.
O texto acima apresenta a metodologia ágil conhecida como:
a) XP.
b) SCRUM.
c) Crystal Clear.
d) ASD.
e) FDD.

(FCC - 2013 – TRT/9 - Analista de Sistemas) Os modelos de processos tradicionais

surgiram em um cenário muito diferente do atual, baseado em mainframes e
terminais remotos. Já os modelos de processos ágeis são adequados para
situações atuais nas quais a mudança de requisitos é frequente. Dentre os
modelos de processos ágeis mais comuns temos: Extreme Programming (XP),
Scrum e Feature Driven Development (FDD).
Algumas das práticas e características desses modelos de processo são descritas

a seguir:
I. Programação em pares, ou seja, a implementação do código é feita em dupla.
II. Desenvolvimento dividido em ciclos iterativos de até 30 dias chamados de

sprints.
III. Faz uso do teste de unidades como sua tática de testes primária.
IV. A atividade de levantamento de requisitos conduz à criação de um conjunto

de histórias de usuários.
V. O ciclo de vida é baseado em três fases: pre-game phase, game-phase, post-

game phase.
VI. Tem como único artefato de projeto os cartões CRC.
VII. Realiza reuniões diárias de acompanhamento de aproximadamente 15

minutos.
16712855225
VIII. Define seis marcos durante o projeto e a implementação de uma

funcionalidade: walkthroughs do projeto, projeto, inspeção do projeto,
codificação, inspeção de código e progressão para construção.
IX. Os requisitos são descritos em um documento chamado backlog e são

ordenados por prioridade.
A relação correta entre o modelo de processo ágil e a prática/característica é:
SCRUM FDD
II, V e VII II, IV e VIII VII e IX

I, III, IV e VI II, V, VII e IX VIII

II, VII e VIII III, IV, VI e IX IeV
II, VII e VIII I, III, IV e V VI e IX
I, III, IV e VI II, VIII, VII e IX V
(FCC - 2011 – TRT/23- Técnico Judiciário) FDD (Feature Driven Development) é

uma metodologia muito objetiva, possuindo apenas duas fases:
a) Concepção & Planejamento e Construção.

b) Decomposição Funcional e Construção.
c) Análise dos Requisitos e Desenvolvimento.
d) Planejamento Incremental e Desenvolvimento por Funcionalidade.
e) Planejamento por Funcionalidade e Construção por Funcionalidade.
(FCC - 2010 - TRE- - Técnico Judiciário - Programação de Sistemas) São

algumas das metodologias de desenvolvimento de software consideradas ágeis
(Agile Software Process Models):
a) RUP, XP e DSDM.
b) Waterfall, RUP e FDD.
c) XP, FDD e RUP.
d) Scrum, XP e FDD.
e) Scrum, Waterfall e DSDM.
16712855225


FDD
(CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno) Há um

considerável debate sobre os benefícios e a aplicabilidade do desenvolvimento
ágil de software em contraposição aos processos mais convencionais de
engenharia de software. Relacione o modelo ágil de software com a sua
respectiva característica.
Modelo:
I - DAS II - DSDM III - FDD IV - XP
Característica:
(P)
Define um ciclo de vida que incorpora três fases: especulação, colaboração e
aprendizado. Durante a fase de aprendizado, à medida que os membros de uma
equipe começam a desenvolver os componentes que fazem parte de um ciclo
adaptativo, a ênfase está tanto no aprendizado quanto no progresso em direção
a um ciclo completo.
(Q)
O conceito característica é uma função valorizada pelo cliente, que pode ser
implementada em duas semanas ou menos. Este modelo define seis marcos de
referência durante o projeto e implementação de uma característica: travessia
do projeto, projeto, inspeção de projeto, código, inspeção de código, promoção
para construção. 16712855225
(R)
Fornece um arcabouço para construir e manter sistemas que satisfazem às
restrições de prazo apertadas por meio do uso de prototipagem incremental em
ambiente controlado de projeto. Essa abordagem sugere uma filosofia que é
emprestada de uma versão modificada do princípio de Pareto.
A relação correta é:
a) I - P, II - Q, III - R.

b) I - P, II - R, III - Q.
c) I - Q, III - R, IV - P.
d) II - P, III - R, IV - Q.
e) II - Q, III - P, IV - R.
16712855225


TEST-DRIVEN DEVELOPMENT (TDD)
(CESPE – – INMETRO – Analista Executivo em Metrologia e Qualidade –

Desenvolvimento de Sistemas) A rotina diária dos desenvolvedores, ao empregar
processos baseados no TDD (Test-Driven Development), é concentrada na
elaboração de testes de homologação.
(CESPE – 2013 – INPI – Analista de Planejamento – Desenvolvimento e

Manutenção de Sistemas) Usando-se o TDD, as funcionalidades devem estar
completas e da forma como serão apresentadas aos seus usuários para que
possam ser testadas e consideradas corretas.
(CESPE – 2013 – ANCINE – Analista de Sistemas) No desenvolvimento de

software conforme as diretivas do TDD (Test-Driven Development), deve-se
elaborar primeiramente os testes e, em seguida, escrever o código necessário
para passar pelos testes.
(CESPE – – INMETRO – Analista de Sistemas) Considerando uma

organização na qual a abordagem de Test Driven Development (TDD) esteja
implementada, assinale a opção correta.
a) Nessa organização, ocorre a execução de iterações com ciclo longo, isto é,

com duração de alguns meses.
b) No início de cada iteração, a primeira atividade realizada pela equipe de

desenvolvimento é produzir o código que será validado através de testes.
16712855225
c) O refactoring é uma das primeiras atividades realizada no início de cada

iteração.
d) Entre as atividades finais de cada iteração, o desenvolvedor escreve casos de

teste automatizados, cuja execução verifica se houve a melhoria desejada ou se
uma nova funcionalidade foi implementada.
e) Há coerência e inter-relação com os princípios promovidos pela prática da

extreme programming (XP).

(CESPE – 2013 – MPOG – Analista de Sistemas) Ao realizar o TDD (test-driven

development), o programador é conduzido a pensar em decisões de design
antes de pensar em código de implementação, o que cria um maior
acoplamento, uma vez que seu objetivo é pensar na lógica e nas
responsabilidades de cada classe.
(CESPE – 2013 – MPU – Analista de Sistemas) Na metodologia TDD, ou

desenvolvimento orientado a testes, cada nova funcionalidade inicia com a
criação de um teste, cujo planejamento permite a identificação dos itens e
funcionalidades que deverão ser testados, quem são os responsáveis e quais os
riscos envolvidos.
(CESPE – 2013 – STF – Analista de Sistemas) No TDD, o primeiro passo do

desenvolvedor é criar o teste, denominado teste falho, que retornará um erro,
para, posteriormente, desenvolver o código e aprimorar a codificação do
sistema.
(CESPE – 2013 – TRT/17 – Analista de Sistemas) TDD consiste em uma técnica de

desenvolvimento de software com abordagem embasada em perspectiva
evolutiva de seu desenvolvimento. Essa abordagem envolve a produção de
versões iniciais de um sistema a partir das quais é possível realizar verificações
de suas qualidades antes que ele seja construído.
(CESPE – 2013 – AL/RN – Analista de Sistemas) Um típico ciclo de vida de um

projeto em TDD consiste em:
I. Executar os testes novamente e garantir que estes continuem tendo sucesso.

II. Executar os testes para ver se todos estes testes obtiveram êxito.
III. Escrever a aplicação a ser testada. 16712855225
IV. Refatorar (refactoring).

V. Executar todos os possíveis testes e ver a aplicação falhar.
VI. Criar o teste.
A ordem correta e cronológica que deve ser seguida para o ciclo de vida do TDD
está expressa em:
a) IV − III − II − V − I − VI.
b) V − VI − II − I − III − IV.
c) VI − V − III − II − IV − I.
d) III − IV − V − VI − I − II.

e) III − IV − VI − V − I − II.
10. (FGV – 2013 – AL/MT – Analista de Sistemas) Com relação ao desenvolvimento

orientado (dirigido) a testes (do Inglês Test Driven Development – TDD), analise
as afirmativas a seguir.
I. TDD é uma técnica de desenvolvimento de software iterativa e incremental.
II.TDD implica escrever o código de teste antes do código de produção, um teste

de cada vez, tendo certeza de que o teste falha antes de escrever o código que
irá fazê-lo passar.
III. TDD é uma técnica específica do processo XP (Extreme Programming),

portanto, só pode ser utilizada em modelos de processos ágeis de
desenvolvimento de software.
Assinale:
a) Se somente as afirmativas I e II estiverem corretas.

b) Se somente as afirmativas I e II estiverem corretas.
c) Se somente as afirmativas II e III estiverem corretas.
d) Se somente a afirmativa III estiver correta.
e) Se somente a afirmativa I estiver correta.
11. (FCC – 2015 – TRT/MG – Analista de Sistemas) Um analista de TI está participando

do desenvolvimento de um software orientado a objetos utilizando a plataforma
Java. Na abordagem de desenvolvimento adotada, o código é desenvolvido de
forma incremental, em conjunto com o teste para esse incremento, de forma
que só se passa para o próximo incremento quando o atual passar no teste.
16712855225
Como o código é desenvolvido em incrementos muito pequenos e são

executados testes a cada vez que uma funcionalidade é adicionada ou que o
programa é refatorado, foi necessário definir um ambiente de testes
automatizados utilizando um framework popular que suporta o teste de
programas Java.
A abordagem de desenvolvimento adotada e o framework de suporte à criação

de testes automatizados são, respectivamente,
a) Behavior-Driven Development e JTest.

b) Extreme Programming e Selenium.

c) Test-Driven Development e Jenkins.

d) Data-Driven Development and Test e JUnit.
e) Test-Driven Development e JUnit.
16712855225


KANBAN
(CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) Kanban é um

método de desenvolvimento de software que tem como uma de suas práticas o
gerenciamento do fluxo de trabalho, que deve ser monitorado, medido e
reportado a cada estado do fluxo.
(FGV - 2013 – MPE/MS - Analista de Sistemas) Kanban é um dos métodos ágeis

mais recentes e sofreu grande influência do movimento “Lean”, surgido nos anos
1980. São práticas comuns a esse método:
a) limitar o WIP (Work In Progress) e uma visualização explícita do fluxo de

trabalho.
b) integração Contínua e gerenciamento de configuração.
c) limitar o WIP (Work In Progress) e gerenciamento de configuração.
d) gerenciar o fluxo de trabalho e manter estimativas previamente definidas.
e) melhoria contínua e nunca limitar o WIP para evitar folgas no sistema de
trabalho.
(FGV - 4 – TJ/GO - Analista de Sistemas) Scrum e Kanban são metodologias

de gerenciamento de projetos de software populares entre praticantes do
desenvolvimento ágil. Um aspecto de divergência entre as duas metodologias é:
a) processo incremental;
b) processo iterativo;
c) uso de quadro de tarefas; 16712855225
d) apresentação do estágio de desenvolvimento de uma tarefa;

e) valorização de feedback.
(FGV - 4 – PROCEMPA - Analista de Sistemas – Kanban considera a

utilização de uma sinalização ou registro visual para gerenciar o limite de
atividades em andamento, indicando se um novo trabalho pode ou não ser
iniciado e se o limite acordado para cada fase está sendo respeitado.
(CESPE - 2015 - TCU- Analista de Sistemas) O método para a implantação de

mudanças denominado Kanban não prevê papéis nem cerimônias específicas.

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

METODOLOGIAS ÁGEIS
1 2 3 4 5 6 7 8 9 10
E E E E C C E C E
GABARITO DOS EXERCÍCIOS COMENTADOS (CESPE)

SCRUM
1 2 3 4 5 6 7 8 9 10
E C E C C E C E E C
11 12 13 14 15 16 17 18 19 20
C C C C C C E C C E
21 22 23 24 25 26 27 28 29 30
E C C E
GABARITO DOS EXERCÍCIOS COMENTADOS (FCC)

SCRUM
1 2 3 4 5 6 7 8 9 10
A E C E A B C E D E
11 12 13 14 15 16 17 18 19 20
E E D B C 16712855225
E B

SCRUM
1 2 3 4 5 6 7 8 9 10
C

GABARITO DOS EXERCÍCIOS COMENTADOS (CESPE)

EXTREME PROGRAMMING
1 2 3 4 5 6 7 8 9 10
E C C E C C C C E E
11 12 13 14 15 16 17 18 19 20
C C E E C C C E C C
21 22 23 24 25 26 27 28 29 30
C C C E C E
GABARITO DOS EXERCÍCIOS COMENTADOS (FCC)

EXTREME PROGRAMMING
1 2 3 4 5 6 7 8 9 10
A B E A C E C B E D
11 12 13 14 15 16 17 18 19 20
D C A

FDD
1 2 3 4 5 6 7 8 9 10
B E B A D 16712855225

FDD
1 2 3 4 5 6 7 8 9 10
B

TEST-DRIVEN DEVELOPMENT
1 2 3 4 5 6 7 8 9 10
E E C E E C C E C A
11 12 13 14 15 16 17 18 19 20
E

KANBAN
1 2 3 4 5 6 7 8 9 10
C A B C C
16712855225

Aula 03: Engenharia de Software para Concursos - Curso Regular

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Aula 03: Engenharia de Software para Concursos - Curso Regular

Título original:

Enviado por

Direitos autorais:

Aula 03

Engenharia de Software para Concursos - Curso Regular

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 148

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 148

Em meados de 2001, dezessete especialistas

Por que valorizar mais indivíduos e suas interações do que processos e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 148

Por que valorizar mais software em funcionamento do que documentação

Porque clientes se interessam por resultados que entreguem valor ao negócio e,

Vou repetir, porque esse assunto cai em prova! No ágil, documentação é

Por que valorizar mais colaboração com o cliente do que negociação de

Porque é importante envolvimento contínuo do cliente. Aliás, desenvolvedores e

Por que valorizar mais a resposta a mudanças do que seguir um

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 148

Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um

Isso é um enorme equívoco! Primeiro, agilidade é diferente de velocidade. A

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 148

Além disso, deve enfatizar a estratégia de entrega incremental, conseguindo

Métodos ágeis são mais dinâmicos, adaptativos, interativos e colaborativos, eles se

Entre os princípios do desenvolvimento ágil de software, nós temos: simplicidade;

softwares ou partes de softwares são entregues frequentemente; cooperação

NÓS SEGUIMOS ESSES PRINCÍPIOS...

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 148

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte

Software funcionando é a medida primária de progresso. As Metodologias Tradicionais

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,

Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 148

Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho

Professor, você pode citar algumas metodologias e frameworks de desenvolvimento

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 148

(CESPE – 2012 – TCE/ES – Auditor de Controle Externo – Tecnologia da

Por que valorizar mais software em funcionamento do que documentação

Conforme vimos em aula, o Manifesto Ágil valoriza: Software em Funcionamento

(CESPE – 2011 – EBC – Analista de Sistemas) O que os métodos ágeis buscam é

NÓS SEGUIMOS ESSES PRINCÍPIOS...

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 148

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos

Conforme vimos em aula, Metodologias Ágeis são extremamente afeitas a

(CESPE – 2010 – BASA – Técnico Científico – Arquitetura de Tecnologia)

Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho

A questão afirma que ela é aplicada principalmente a grandes corporações. De fato,

(CESPE – 2010 – TCU – Auditor Federal de Controle Externo – Tecnologia da

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 148

compreendendo a fluidez de uma abordagem do desenvolvimento ágil; possa

(CESPE – – UNIPAMPA – Analista de Sistemas) XP, Scrum e Cristal são

Conforme vimos em aula, está perfeito!

(CESPE - 2011 - EBC - Analista - Engenharia de Software) Considerando o

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 148

Conforme vimos em aula, está perfeito!

(CESPE - 2013 - CNJ - Técnico Judiciário - Programação de Sistemas) O

Não, desenvolvimento ágil de sistemas não é uma linguagem de modelagem. Quem

(CESPE - 2011 - EBC - Analista - Engenharia de Software) É conveniente que o

Segundo Martin Fowler, pode-se fixar um orçamento para o software antes de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 148

(CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Metodologias de

Por que valorizar mais software em funcionamento do que documentação