Desenvolvimento Ágil de Software

Curso Regular de Engenharia de Software
Prof. Diego Carvalho – Aula 03
TODOLOGIAS Á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 esquisas métodos e desenvolvimento e
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.
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 ndivíduos.
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 152

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 abilidades ndividuais o
trabalho em equipe são inseparáveis em rojetos 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 ncionamento o nico
indicador do que, e 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 aloriza-se mais o software em funcionamento.
Por que valorizar mais colaboração com o cliente do que negociação de

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 laborativamente , 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 rojeto deve balancear o
planejamento om mudança, dependendo o ível e 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 ermitem ue mudanças ossam er
rapidamente inseridas no rojeto, de forma que atendam às novas necessidades.
Por fim, o manifesto enfatiza que os tens direita têm eu alor, tretanto os tens
à esquerda são ais alorizados! 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.
Isso um orme equívoco! rimeiro, ilidade é 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 é
tricampeão olímpico, mundial, etc... ou seja, ele é geralmente o mais rápido, mas
ele tem um problema: sua largada! Ele reage mais ento ue seus dversários

a) A aplicação de método ágil para desenvolvimento de grandes sistemas pode

enfrentar dificuldades que o tornem inviável.
b) O documento de requisitos, apesar de abordar um conjunto pequeno de

funcionalidades, deve especificar toda a necessidade do usuário.
c) O sistema é construído em pequenos blocos, que irão compor uma versão a

ser entregue aos usuários.
d) A documentação de projeto deve ser feita pelo próprio desenvolvedor,

seguindo padrões simplificados.
e) Para atingir os objetivos de agilidade exigidos, os desenvolvedores devem

seguir processos simplificados para a construção do software.
Comentários:
a) Correto. Aqui temos a teoria e a prática: no início, tanto a teoria quanto a prática
não recomendavam que as metodologias ágeis fossem aplicadas a sistemas
grandes. No entanto, atualmente, isso já não é mais uma limitação. Hoje em dia, as
metodologias ágeis adquiriram maturidade suficiente para desenvolver sistemas
grandes e complexos. Porém, isso ainda está na teoria, por isso as questões ainda
cobram.
b) Errado. Em metodologias ágeis, há uma documentação abrangente no início e

detalhada somente o necessário durante o projeto conforme os objetivos das
iterações e releases. No entanto, não existe um "Documento de Requisitos" - isso é
coisa de metodologias tradicionais. Além disso, nenhum documento nunca
conseguirá especificar todas as necessidades dos usuários.
c) Correto. Não vislumbro qualquer erro nesse item. Ora, metodologias ágeis são
iterativas e incrementais, dividindo o sistema em pequenas partes e sempre
entregando versões que agreguem valor aos usuários. Se você errou esse item, fique
tranquilo - o vacilo foi da banca!
d) Errado. Documentação de Projeto? Isso é coisa de metodologias tradicionais. E,

pensa comigo, o Product Backlog (do Scrum) é feito pelo desenvolvedor? Não, as
histórias de usuário são escritas pelo Product Owner (Cliente).

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
“ - d s k
para ajudar no processo, mas eles são pcionais.
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 é sado
ambientes mplexos, nde os equisitos as rioridades mudam onstantemente.
O que eria exatamente ambiente omplexo? Existe uma coisa chamada Modelo
Cynefin que explica bem s ipos e 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 em efinido, tremamente acoplado, ão em iberdade e
não istem uitas pções de como ealizar m rabalho. 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.

realizado o mais breve possível para minimizar mais desvios. Como udanças
sempre ocorrem, recomenda-se a adaptação em vez de evitá-las.
Vamos esumir s rês pilares que sustentam osso ramework! udo o crum
deve ser ransparente 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)2. É
responsável or tregar rodutos de forma iterativa incremental, aximizando
as portunidades 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! O crum rega que, o m e cada sprint, eve-se entregar m
incremento otencialmente funcional o roduto ente. 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 ome desses
ciclos e 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.
2
Os times de desenvolvimento não contêm subtimes dedicados a domínios específicos de conhecimento, tais
como teste ou análise de negócios. O Scrum não reconhece títulos para os integrantes do time de
desenvolvimento além do desenvolvedor, independentemente do trabalho que esteja sendo realizado.

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 etirar os mpedimentos ue aparecem o decorrer do
nosso rojeto. 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 isso, que vai razer demanda do no a Casa,
entender que ele quer e passar de maneira simples, c ara e objetiva para a Equipe
de Pedreiros. 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 ue será feito o ue não será feito. ocê o esponsável pelo ue 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 ra que vai riorizar o ue deve ser ito rimeiro. Você
éo a que coloca ou ira atividades da lista atividade a serem ealizadas. 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 ontrole
sobre essas tividades é descentralizado, u eja, no a Casa não nterfere na
parte técnica dos edreiros, que não nterferem no trabalho do Mestre de Obras.
Pensem em uma repartição pública que contém uma Coordenação dividida em 4

gerências. Ora, o ntrole e gestão são escentralizados, itos or a gerência
esmo que todas as enham que responder ao oordenador. Bem, acredito que
dessa forma consegui convencê-la e fazê-la entender melhor o papel de cada um
desses caras. Ficou mais claro agora?

Um x plo de visão obre um roduto: “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 ue a visão do roduto, e forma geral, deve permanecer stável

durante todo o rojeto. 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 rimônia não-oficial apesar de muito mum) c amada 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.
É omum er árias estrições, reocupações e dependências, c mo atas
importantes, tens ntratuais, logística, tre 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 inimizar
a necessidade de reuniões não efinidas pelo crum. 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.
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 e inicia imediatamente após conclusão da
sprint ior e tem durações coerentes em todo o esforço de desenvolvimento.
Durante a sprint é proibido realizar mudanças que afetem eta.
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 ode ser celada antes e seu ime-box erminar isso somente pode ser

feito elo roduct 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 nsiste em duas artes e elas evem
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 s ncionalidades

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, roduct Owner nsegue 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 o e Histórias de Usuário
(User Stories), nós utilizamos Pontos de História (Story Points).
Trata-se de uma unidade de medida relativa que leva em onsideração o s orço

necessário ara realizar ma 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 eio e uma

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?
As Reuniões Diárias elhoram a comunicação tre os ntegrantes, 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, corre a Revisão da Sprint (Proporcional 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!
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 roblemas as oluções pós
demonstração do incremento, espondem-se quaisquer dúvidas dos presentes.
A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team

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

claramente quais são s assos ínimos ara a conclusão e um tem u

funcionalidade potencialmente entregável.
Serve, mais ou menos, como um contrato entre a Equipe de Desenvolvimento e o

Product Owner, garantindo que todo roduto erado elo rojeto tará dentro
dos adrões de qualidade estabelecidos iormente. 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 contece exatamente o contrário: finition of Done (DoD) é um c ecklist de

critérios c rdados ara que o roduct Owner ossa aceitar ma 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 adurecimento rganizacional e a habilidade do
time de resolver mpedimentos odem zer m ue alguns tens ejam
acrescentados. Diferentemente do Definition of Ready, é imperativo haver um
Definition of Done. Compreenderam?

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, s nidades utilizadas ão e esforço
(em horas) planejado pelo tempo decorrido.

Por fim, é salutar enfatizar que o ciclo de vida do nosso framework é baseado em
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.

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 011 C alista de Informática nalista 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 010 PU - alista de Informática alista 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
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 mpíricas ontrole ocesso
emprega uma abordagem iterativa incremental (maximizando as oportunidades de
feedback) para aperfeiçoar a previsão e controle de riscos.

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 013 A INE A alista 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 010 U alista 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.
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.

XTREME 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 oas práticas ejam evadas o x remo! 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 e desenvolvimento e software para equipes

pequenas, coesas e multidisciplinares cujos projetos ossuem equisitos agos 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. Aliás, a codificação é a atividade principal no XP!
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 rogramadores 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 istema e um este unitário ode então
ser projetado ara 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 estes de aceitação são obtidos de histórias de usuários mplementadas como

parte e uma versão e 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! User tories
são tefatos de desenvolvimento tilizados 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 e trata de uma especificação mpleta 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 etalhes das istórias e usuário ão turados os estes
automatizados e aceitação que são osteriormente usados ara validar
implementação a 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 ma história precisa ser decomposta em artes menores para
caber ma 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 ravessam erticalmente a arquitetura do roduto

normalmente elas ão ão cadas em m ubsistema 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.

 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!

Galera, não onfundam alores Fundamentais com rincípios ásicos! les também
são 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 anças: mudanças devem ser bem-vindas e ocorrerão de acordo

com o melhor entendimento do projeto.

 Presumir implicidade: todo problema deve ser tratado para ser resolvido da
forma mais simples possível.
 Mudanças ncrementais: 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 ovas ersões de software podem ser compiladas

várias ezes 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 oftware será aceita somente se todos s estes 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 udanças
antecipadas uitas ezes 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-
se cada vez mais difíceis de implementar. O Extreme Programming lida com este
problema defendendo que o software deve passar or efatoramento
constantemente.
Isso significa que a equipe de programação rocura por ossíveis elhorias o

software, mplementando-as mediatamente. 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?

EATURE DRIVEN DEVELOPMENT (FDD)
Vamos ar gora sobre o eature Driven velopment (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 oeso de princípios e práticas tanto para a Gestão e Projetos uanto para
a Engenharia de Software, e se harmoniza bem com abordagens mais especialistas,
como Scrum.
Ela se fundamenta em écnicas de gerenciamento e 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? Trata-se de uma funcionalidade ou

característica valorizada pelo c ente, ue pode ser mplementada em uas emanas
ou enos. 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:
 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 adoção e um njunto e melhores práticas para que o

método inja seus bjetivos rincipais, são eles: modelagem de objetos de domínio;

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 arcos meçam ser onitorados pelo erente do rojeto 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.

EST-DRIVEN DEVELOPMENT (TDD)
O Test-Driven Development (TDD 5) é um método gil de desenvolvimento de

software que se baseia na repetição de um ciclo de desenvolvimento curto, focado
em estes nitá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 udar 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
passe no teste e execute novamente (agora ele deve passar no teste). Então
adicionamos m ovo este e rodamos este anterior 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, ia-se um ódigo ais impo, isto ue o ódigo ara passar os estes
deve ser astante simples. Há mais segurança na correção de eventuais bugs;
5
Eventualmente chamado de Test-Driven Programming (TDP).

Professor, isso já caiu em prova discursiva? Sim, prova pedia para dizer
vantagens do mprego o DD elação outras etodologias 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 odo o código desenvolvido, ue 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 s princípios a Metodologia XP poiados 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 ode apoiar e princípio or rnecer etalhes para a realização os estes

de unidade de funcionalidade, ue são mportantes 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.

d) III − IV − V − VI − I − II.
e) III − IV − VI − V − I − II.
Comentários:
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 013 /MT alista 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 III 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.

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

desenvolvimento de software que se baseia a comunicação ntre clientes do
negócio, esenvolvedores 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 a captura de requisitos estes de aceitação os tiliza ara

guiar o desenvolvimento o istema. 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 ormalmente concluem ue a enas o a o e

se definir estes de aceitação discutir equisitos esulta numa melhor
compreensão estes equisitos. 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 nal,
resultado estará alinhado às expectativas do cliente.

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

problemas. Sacaram?
O Kanban é construído sobre os conceitos e 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 deal ara
utilização njunto om processos istentes, que podem ser desde o Scrum até
Cascata. Ele também é excelente em situações em que estruturas organizacionais
inibem mudanças radicais.
O Kanban é construído rincipalmente sob o onceito e elhoria 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 mece a usar crum
utilizar anban para impulsionar udanças turas. Os projetos com Kanban,
apesar de não insistirem no compromisso com iterações planejadas, são muito bem

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 úmero de tarefas e damento eterminado ponto do processo,
maior o empo 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, sso ão
existe! ão á um úmero ágico, necessário descobrir o amanho
empiricamente de acordo com o contexto a 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, tilizo Trello ara minhas ividades
pessoais profissionais recomendo astante!). Há também o KanbanFlow,
Kanbanery, Leankit, Visual WIP, entre outras! Baixem e divirtam-se...

e) Os stakeholders, indivíduos e grupos interessados no processo e no software,

fazem parte da equipe Scrum.

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.

e) III − IV − VI − V − I − II.
10. (FGV 013 /MT alista 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 015 RT/MG alista 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.
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.

Desenvolvimento Ágil de Software

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento Ágil de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Curso Regular de Engenharia de Software

Prof. Diego Carvalho – Aula 03

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. 4 de 152

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. 5 de 152

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

Isso um orme equívoco! rimeiro, ilidade é diferente de velocidade. A

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

a) A aplicação de método ágil para desenvolvimento de grandes sistemas pode

b) O documento de requisitos, apesar de abordar um conjunto pequeno de

c) O sistema é construído em pequenos blocos, que irão compor uma versão a

d) A documentação de projeto deve ser feita pelo próprio desenvolvedor,

e) Para atingir os objetivos de agilidade exigidos, os desenvolvedores devem

b) Errado. Em metodologias ágeis, há uma documentação abrangente no início e

d) Errado. Documentação de Projeto? Isso é coisa de metodologias tradicionais. E,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 152

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

O Scrum é um framework baseado em código, para gerenciar projetos, produtos e

Querem um exemplo? O McDonalds é um ambiente complexo? Não, é um ambiente

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 152

O Scrum define o conceito de Time Scrum, que é um time auto-organizável (escolhe

Entregas incrementais de produto “pronto” garantem que uma versão

O Scrum realiza ciclos completos de desenvolvimento de duração fixa em que, ao

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 152

Os pedreiros estão desmotivados, distraídos, descuidados? Ele irá arrumar uma

A Equipe de Construção de Casas é o Scrum Team; a Equipe de Pedreiros é o

Pensem em uma repartição pública que contém uma Coordenação dividida em 4

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 152

Um x plo de visão obre um roduto: “Para turistas usuários de smartphone, que

Lembremos ue a visão do roduto, e forma geral, deve permanecer stável

Há outra rimônia não-oficial apesar de muito mum) c amada Release Planning

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

Além disso, é proibido mudar a composição da equipe ou diminuir as metas de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 152

feito elo roduct Owner (sob influência de stakeholders, equipe de

1. O que será entregue como resultado do incremento da próxima Sprint?

Na primeira parte, a Equipe de Desenvolvimento tenta prever s ncionalidades

Feito isso, é hora de estimar o esforço de desenvolvimento de cada item do backlog.

Trata-se de uma unidade de medida relativa que leva em onsideração o s orço

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 152

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

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

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

As Reuniões Diárias elhoram a comunicação tre os ntegrantes, eliminam a

No final da sprint, corre a Revisão da Sprint (Proporcional horas). Embora seja

Vocês se lembram do filme O Gladiador? Pois é! A Revisão da Sprint é o momento

A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 152

claramente quais são s assos ínimos ara a conclusão e um tem u

Serve, mais ou menos, como um contrato entre a Equipe de Desenvolvimento e o

Aqui contece exatamente o contrário: finition of Done (DoD) é um c ecklist de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 41 de 152

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 42 de 152

1) Pré-Planejamento (Pre-game Phase):

2) Desenvolvimento (Game Phase):