Engenharia de software I Unid III

Prévia do material em texto

86
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Unidade III
5 OS MODELOS E MÉTODOS ÁGEIS
5.1 Considerações e conceitos 
Os métodos ágeis, desde seu surgimento, na década de 1990, têm sido apontados como uma 
alternativa aos modelos clássicos ou tradicionais para o desenvolvimento de software. Dessa forma, 
discutem-se, há muito tempo, as diferenças e as semelhanças entre essas duas abordagens, e algumas 
características têm sido apresentadas para definir suas aplicações aos processos de software.
As abordagens tradicionais são consideradas pelos seguidores dos métodos ágeis como soluções 
complexas, pesadas ou fortemente calcadas no planejamento. Com certeza, a prática mostra que elas 
nem sempre conseguem atender aos projetos em que há muitas mudanças ao longo do desenvolvimento 
e quando não existe muita clareza nos objetivos e soluções que deverão ser implementados.
Como atender ao ambiente extremamente dinâmico que as organizações estão vivendo e responder 
rapidamente às demandas e expectativas do mercado e dos clientes? É para responder a essas indagações 
que surgiram os métodos ou modelos ágeis, com suas propostas inovadoras na forma de se construir 
software.
Uma definição consagrada de método ágil ou desenvolvimento ágil de software é: conjunto de 
atividades, métodos ou processos de desenvolvimento de software. Outra definição muito comentada 
seria: o desenvolvimento ágil, tal como qualquer processo de software tradicional, fornece uma estrutura 
conceitual e um conjunto de práticas para projetos de software (COSTA et al., 2013; AMBLER, 2004).
Os métodos ágeis originaram-se a partir da década, de 1990 e a principal razão apontada era o 
fato de que o modelo em cascata ou modelo clássico era visto como extremamente burocrático, lento 
e contraditório em relação à forma usual de os engenheiros de software realizarem seus trabalhos 
com eficiência. Têm muito em comum com as técnicas de desenvolvimento rápido de aplicação, RAD, 
da década de 1980, sugeridas por James Martin, Steve McConnell, entre outros autores. Mas o que 
propunha o desenvolvimento RAD?
•	 o	RAD	usa	o	mínimo	de	planejamento	em	favor	de	uma	rápida	prototipagem;
•	 o	planejamento	é	intercalado	com	a	escrita	do	software;
•	 geralmente,	a	falta	de	um	pré-planejamento	extensivo	permite	que	o	software seja escrito muito 
mais rapidamente;
Janete
Underline
Janete
Underline
Janete
Underline
Janete
Underline
87
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 torna	mais	fácil	aceitar	mudanças	de	requisitos	ao	longo	do	processo;
•	 é	uma	metodologia	que	inclui	o	desenvolvimento	iterativo	e	a	prototipagem	de	software;
•	 é	uma	combinação	de	várias	técnicas	estruturadas,	especialmente,	da	engenharia	de	informação,	
que é dirigida por dados, com técnicas de prototipagem para acelerar o desenvolvimento de 
sistemas;
•	 as	técnicas	estruturadas	e	a	prototipagem	são	usadas	para	a	definição	dos	requisitos	dos	usuários	
e para o design do sistema final.
Recentemente, a empresa americana Ambysoft fez uma pesquisa com a intenção de verificar como 
o mercado vê de que forma os times ágeis agregam valor ao cliente, e os resultados são apresentados 
na figura a seguir.
Trabalhando e produzindo software
Debates regulares com stakeholders
Identificação dos stakeholders e metas
Consideração da usabilidade
Definição do pronto (feito)
Melhoria do processo de negócio
Documentação de apoio (suporte)
Início do projeto
Mudança de pessoal
88%
74%
71%
70%
67%
58%
48%
40%
19%
Figura 23 – Como os times ágeis agregam valor aos stakeholders
O objetivo da pesquisa era explorar como as equipes ágeis adotaram os critérios ágeis, e as respostas 
da figura anterior, especificamente, questionavam como os times estão agregando valor ao cliente ou 
interessado.
Os resultados mostram, pelos percentuais, que os times consideram que o fator mais importante 
na entrega de valor ao cliente é produzindo software (88%). Todavia, outros fatores também 
foram bem-avaliados, como o debate regular com o cliente, a identificação dos objetivos dos 
clientes etc.
É interessante notar que poucos consideram que o início do projeto e mudanças de pessoal são 
fatores relevantes na entrega de valor ao cliente.
88
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
 Observação
Outras quatro questões foram colocadas na pesquisa: 
1) A equipe está validando o seu próprio trabalho? 
2) A equipe trabalha em estreita colaboração com os seus stakeholders?
3) A equipe se organiza?
4) O time melhorou seu processo?
Essas questões foram embasadas nos princípios dos métodos ágeis.
A história dos métodos ágeis se inicia formalmente em fevereiro de 2001, quando membros 
proeminentes da comunidade de software se reuniram em Snowbird (The Lodgeat Snowbirdski Resort, 
em Utah) e adotaram o nome métodos ágeis.
De acordo com Pressman (2006, p. 52), “nasceu o Manifesto Ágil, documento que reúne os princípios 
e as práticas desse paradigma de desenvolvimento”. 
Uma das observações mais importantes, ainda, na atualidade, é a que diz que os métodos ágeis 
são caracterizados como o oposto de metodologias guiadas pelo planejamento, ou denominadas 
disciplinadas ou preditivas. 
O manifesto contém quatro valores fundamentais:
•	 os	indivíduos	e	suas	interações,	mais	que	procedimentos	e	ferramentas;	
•	 o	funcionamento	do	software, mais que documentação abrangente; 
•	 a	colaboração	com	o	cliente,	mais	que	negociação	de	contratos;
•	 a	capacidade	de	resposta	a	mudanças,	mais	que	seguir	um	plano	preestabelecido.
Esses quatro valores, até os dias de hoje, provocam muitas discussões calorosas, e muitos especialistas 
consideram praticamente impossível a aplicação prática de todos esses valores na sua essência. 
Entretanto, a maioria dos métodos ágeis tenta minimizar o risco do desenvolvimento de software ou 
batalhar para eliminar a “crise do software” da seguinte maneira:
•	 usando	ciclos	 curtos	de	 tempo,	 chamados	de	 iteração,	 sprints etc. que vão de poucos até, no 
máximo, 30 dias;
•	 cada	iteração	ou	sprint, ou ciclo, é como um projeto de software em miniatura e inclui todas as 
tarefas necessárias para implantar o mini-incremento da nova funcionalidade:
Janete
Underline
Janete
Underline
Janete
Underline
Janete
Underline
Janete
Highlight
Janete
Underline
Janete
Underline
89
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
— planejamento, análise de requisitos, design, codificação, teste e documentação;
— não necessariamente documentados totalmente.
•	 métodos	ágeis	enfatizam	a	comunicação	em	tempo	real,	preferencialmente,	face	a	face,	no	lugar	
de documentos escritos;
•	 a	 partir	 dos	 valores	 do	Manifesto Ágil, também foram definidos os chamados Princípios dos 
Métodos Ágeis, que são:
— garantir a satisfação do cliente/usuário, entregando rapidamente, continuamente e 
adiantadamente softwares com valor agregado e funcionando; 
— softwares funcionando são entregues frequentemente (em dias, semanas, em vez de meses); 
— softwares funcionais são a principal medida de progresso do projeto; 
— até mesmo mudanças tardias de escopo no projeto são bem-vindas;
— cooperação constante (diariamente) entre pessoas que entendem do negócio e desenvolvedores; 
— bons projetos surgem por meio deindivíduos motivados, em uma relação de confiança; 
— simplicidade de projetos; 
— rápida adaptação às mudanças;
— transmissão de informações por meio de conversa face a face;
— em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então, refina e 
ajusta seu comportamento. 
•	 os	 métodos	 ágeis	 são,	 muitas	 vezes,	 confundidos	 com	 o	 modelo	 codifica-remenda	 no	
desenvolvimento de software, principalmente, em razão de:
— o método codifica-remenda ser a ausência de metodologias de desenvolvimento de software;
— essa forma de trabalho parecer semelhante à maneira pela qual as pessoas (times) utilizam os 
métodos ágeis.
Outro fator importante a se analisar é a aplicabilidade dos métodos ágeis que, em geral, pode ser 
examinada de múltiplas perspectivas: 
•	 da	 perspectiva	 do	 produto:	 os	 métodos	 ágeis	 são	 mais	 adequados	 quando	 os	 requisitos	 são	
instáveis (mudam rapidamente); 
Janete
Underline
Janete
Underline
Janete
Underline
Janete
Underline
90
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 da	perspectiva	organizacional:	a	aplicabilidade	do	método	ágil	pode	ser	expressa	examinando-se	
três dimensões-chave da organização: cultural, pessoal e de comunicação. 
O quadro a seguir mostra uma comparação do ambiente ideal para os processos de software, tanto 
os ágeis quanto os clássicos ou tradicionais.
Quadro 4 – Comparação do ambiente ideal para os processos de software
Desenvolvimento ágil Desenvolvimento orientado ao planejamento (métodos clássicos)
Baixa criticidade do software Alta criticidade do software
Desenvolvedores seniores Desenvolvedores juniores (equipes mistas)
Mudanças frequentes de requisitos Baixa mudança nos requisitos 
Pequeno número de desenvolvedores Grande número de desenvolvedores 
Cultura que tem sucesso no caos Cultura que procura a ordem por meio do planejamento
Com relação ao gerenciamento de projetos, os métodos ágeis diferem largamente dos métodos 
tradicionais no que diz respeito à forma pela qual são gerenciados, mas alguns métodos ágeis são 
complementados com guias para direcionar o gerenciamento do projeto, embora nem todos sejam 
aplicáveis. Contudo, diversos autores consagrados da engenharia de software fazem críticas ao método 
de desenvolvimento ágil:
•	 esse	método	é,	algumas	vezes,	criticado	como	codificação	cowboy (termo que indica uma forma 
não organizada de trabalho);
•	 o	início	da	programação	extrema	(XP)	soava	como	controverso	e	dogmático,	como	a	programação	
por pares e o projeto contínuo; alguns princípios dessa programação não foram fáceis de entender 
e aplicar à cultura vigente;
Muitas dessas críticas, contudo, têm sido vistas pelos defensores dos métodos ágeis como um mal-
entendido a respeito do desenvolvimento ágil.
 Observação
Diversos trabalhos apontam que as principais causas de falha na 
adoção de uma metodologia ágil são: boicote (falta de comprometimento 
das equipes; é preciso reconhecer que há espaço para melhorias e desejá-
las); conflito (filosofia ou cultura da empresa que conflitam com os valores 
e princípios dos métodos ágeis); suporte gerencial (falta de apoio para 
mudanças; é preciso desejar as mudanças); experiência (treinamento 
insuficiente no novo processo; é preciso tornar-se capaz de trabalhar de 
maneira ágil).
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
91
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Serão apresentados a seguir os principais métodos ágeis ainda vigentes e que merecem um estudo 
mais detalhado. Para efeito de comparação entre uma metodologia pesada (processos tradicionais ou 
clássicos) e uma metodologia leve (métodos ágeis) tem-se que uma metodologia pesada tem muitas 
regras, práticas e muitos documentos associados, enquanto uma metodologia leve apresenta:
•	 poucas	regras	e	práticas	que	são	fáceis	de	aplicar;
•	 o	ambiente	de	desenvolvimento	é	claro	e	conciso,	criado	pela	observação;
•	 faz	que	o	desenvolvimento	de	software seja rápido;
•	 os	programadores	se	sentem	criativos	e	livres,	porém	organizados	e	focados.
5.2 O método ágil eXtremme Programming (XP)
O	método	ágil	XP	é	uma	disciplina	leve	do	desenvolvimento	de	software, que é fortemente baseada 
nos seguintes princípios:
•	 simplicidade;
•	 comunicação;
•	 feedback;
•	 coragem.
A	disciplina	ou	método	ágil	XP	é	desenhada	para	uso	em	times	pequenos	e	para	quem	necessita	
desenvolver softwares de forma rápida, num ambiente de mudanças constantes de requisitos.
De acordo com Beck (2001), (considerado o “pai” ou criador do método), o sucesso metodológico da 
XP	vem	do	esforço	pela	satisfação	do	cliente.	O	método	ágil	XP,	quando	desenvolvido	por	Beck,	tinha	
como objetivos: 
•	 a	satisfação	do	cliente;
•	 o	atendimento	aos	requisitos	do	cliente;
•	 ser	fortemente	focado	em	trabalho	em	times;
•	 manter	todos	voltados	para	criar	software com qualidade.
A	disciplina	XP	enfatiza	o	trabalho	em	grupo,	incluindo	gerentes,	clientes	e	desenvolvedores,	todos	
fazendo parte do time dedicado a entregar um software de qualidade.
Janete
Underline
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
92
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Segundo	o	método	ágil	XP,	existe	uma	limitação	na	definição	do	grupo,	sendo	possível	um	grupo	de	
no máximo dez pessoas, incluindo gerentes e clientes.
 Lembrete
O	 método	 XP	 foi	 desenhado	 para	 funcionar	 com	 times	 pequenos,	
para o desenvolvimento rápido de software e para mudança constante de 
requisitos.
O	método	ágil	XP	é	baseado	em	12	práticas,	listadas	a	seguir.	
•	 P	1	(Prática	1):	o	processo	de	planejamento.	O	planejamento	do	projeto	no	método	XP	se	dá	por	
meio da técnica de reunião denominada “jogo do planejamento”. 
•	 P	2	(Prática	2):	o	projeto	ocorre	sempre	em	pequenas	versões.	Estas	são	produzidas	em	ciclos	curtos	
de desenvolvimento. De preferência, cada pedaço de software resultante deve ser executável e 
colocado em produção junto ao cliente. 
•	 P	 3	 (Prática	 3):	metáfora.	 Todos	 utilizam	 nomes	 comuns	 e	 uma	 linguagem	 comum	 nos	 seus	
códigos. A padronização na escrita dos códigos é fundamental para o sucesso do método. 
•	 P	4	 (Prática	4):	design simples. Não existe mais o “construir para o futuro”. O software resolve 
o problema de agora, sem perda de tempo estudando as futuras manutenções ou as novas 
funcionalidades. É uma proposta que quebra o paradigma tradicional, em que uma arquitetura 
deve ser trabalhada antes de se iniciar a codificação propriamente dita. 
•	 P	5	(Prática	5):	testes.	A	validação	do	software ocorre durante todo o tempo do desenvolvimento, 
e não no final da construção. Os códigos vão sendo construídos e testados de forma conjunta. 
•	 P	6	(Prática	6):	desenvolvimento	em	espiral.	O	método	XP	usa	o	desenvolvimento	iterativo.	O	ciclo	
curto se repete até que todo o software esteja pronto. 
•	 P	7	(Prática	7):	programação	em	pares.	O	código	é	desenvolvido	por	dois	programadores	trabalhando	
juntos. Essa prática faz que o código não tenha um único “dono” e resolve o problema da ausência 
de um dos desenvolvedores. 
•	 P	8	(Prática	8):	propriedade	coletiva.	Todo	o	código	pertence	a	todos	da	equipe.	Não	existe	“dono”	
do código, como nos métodos tradicionais. 
•	 P	9	(Prática9):	integração	contínua.	A	equipe	integra	o	software muitas vezes ao dia, na busca da 
solução dos problemas de integração, tão comuns nos métodos tradicionais de desenvolvimento.
•	 P	 10	 (Prática	 10):	 quarenta	 horas	 de	 trabalho	 semanais.	 De	 acordo	 com	o	 XP,	 programadores	
cansados cometem mais erros e prejudicam o andamento do projeto. 
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
93
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 P	11	(Prática	11):	cliente	fazendo	parte	da	equipe.	Um	projeto	XP	é	conduzido	por	um	cliente,	e	
decisões são definidas por ele o tempo todo.
•	 P	 12	 (Prática	 12):	 codificação-padrão.	Os	 códigos	 são	 escritos	 da	mesma	 forma	 por	 todos	 os	
envolvidos no projeto.
A seguir, a figura apresenta uma visão do método ágil sob o ponto de vista do ciclo de desenvolvimento.
Histórias de 
usuário
Requisitos
Erros
Cenários de 
testes
Aprovação 
do cliente
Pequenas 
liberações
Testes de 
aceiteLiberação
Plano de 
liberação
Arquitetura 
de risco
Metáforas 
do sistema
Plano de 
liberação
Próxima 
iteração
Última 
versão
Riscos
Estimativas 
incertas
Estimativas 
confidenciais
Nova história do usuário
Velocidade do projeto
Figura 24		–	Ciclo	de	desenvolvimento	do	método	XP	
Apesar	do	sucesso	do	método	XP,	principalmente,	nos	meios	acadêmicos	e	nas	pequenas	fábricas	de	
software, existem críticas ao método. 
O autor Matt Stephens, em seu livro Extreme Programming Refactored (STEPHENS; ROSENBERG, 
2003), faz uma revisão no método e apresenta as seguintes críticas:
•	 falta	 de	 estrutura	 e	 documentação	 necessárias:	 o	 método	 abriu	 mão,	 completamente,	 de	
documentos que registrassem qualquer fato a respeito do software construído; a única 
documentação é o próprio código-fonte;
•	 somente	 trabalhar	 com	desenvolvedores	de	nível	 sênior:	no	mercado,	fica	muito	difícil	 e	 caro	
montar equipes de desenvolvedores somente com alto nível de conhecimento; 
•	 incorporar	de	forma	insuficiente	o	projeto	de	software: como o software é construído para “agora”, 
quando se precisa fazer alguma manutenção, a arquitetura original nem sempre tem a estrutura 
necessária para as novas implementações; 
Janete
Highlight
Janete
Highlight
Janete
Underline
Janete
Underline
Janete
Underline
94
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 requer	a	adoção	de	mudança	cultural:	este	é	um	fator	importante	a	ser	considerado	quando	se	
pretende	adotar	o	método	XP;	
•	 poder	 levar	 a	maiores	 dificuldades	 nas	 negociações	 contratuais:	 como	 se	 sabe,	 os	 clientes	 se	
protegem	por	meio	de	contratos	formais	que	não	são	aceitos	no	método	XP	nem	fazem	parte	da	
sua estrutura, o que acaba contrastando com a realidade vivida pelas organizações.
 Saiba mais
Leia o seguinte trabalho:
TELES, V. M. Um estudo de caso da adoção das práticas e valores do 
Extreme Programming. 2005. 90 f. Dissertação (Mestrado em Informática) 
– Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005. Disponível 
em:	<http://desenvolvimentoagil.com.br/xp/dissertacaoXP.pdf>.	Acesso	
em: 16 abr. 2014.
Nesse trabalho, o autor faz uma apresentação profunda dos conceitos 
desse método ágil e desenvolve um estudo de caso em que foram aplicados 
os	valores	e	as	práticas	do	XP.
Diversos resultados foram descritos pelo autor, indicando que o projeto 
atendeu às expectativas do cliente e que a equipe foi capaz de conduzir o 
projeto com baixo nível de estresse. A qualidade foi demonstrada no uso do 
sistema por seis meses com apenas três erros identificados. 
5.3 O método ágil Scrum
O método Scrum, inicialmente, foi concebido como um estilo de gerenciamento de projetos ágeis 
em empresas de fabricação de automóveis e produtos de consumo (NONAKA; TAKEUCHI, 1986).
Na atualidade, existe uma discussão sobre o método Scrum que sempre vem à tona. Ele é um 
framework ágil para projetos de software ou uma metodologia de gerenciamento de projetos? Para 
responder de forma mais acadêmica, recorrendo aos principais dicionários (Aurélio, 1988; Houaiss, 
2012; e Michaelis, 2009), encontramos o conceito de metodologia:
•	 implica	 algo	 que	 define	 procedimentos,	 regras	 documentadas	 (ou	 o	 estudo	 destas),	 para	 a	
regulamentação de uma determinada disciplina;
•	 ensina-nos	a	pesquisar	e	estudar	algo.
Janete
Underline
Janete
Underline
95
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Analisando o dicionário de computação Computer Dictionary (2014), nota-se:
•	 metodologia	de	software é o conjunto organizado de procedimentos e diretrizes para uma ou 
mais fases do ciclo de vida do software, tais como análise ou design;
•	 muitas	 metodologias	 incluem	 uma	 notação	 de	 diagramação	 para	 documentar	 os	 resultados	
do processo; uma abordagem do tipo livro de receitas; passo a passo para a realização do 
procedimento; objetivo (de preferência, quantificado); e conjunto de critérios para determinar se 
os resultados do procedimento são de qualidade aceitável.
Com base nessas definições, pode-se afirmar que o método Scrum não se encaixa em nenhuma 
das definições anteriores. Isso porque o método não ensina a fazer pesquisa, não ensina ciência, 
nem responde a perguntas da engenharia de software que possam surgir no decorrer do ciclo de 
vida de um software. Essas definições descartam Scrum como metodologia de imediato, tendo 
em vista que se desenvolveu independentemente dos processos de software e pode ser aplicado, 
também, a outras realidades de projetos. Daí ser tratado, neste texto, como um método ágil de 
gestão de projetos.
 Saiba mais
Diversos artigos e considerações sobre o método Scrum podem ser 
encontrados no site	disponível	em:	<http://massimus.com/downloads/>.	
Em 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e 
implementaram o Scrum na empresa Easel Corporation, reunindo os estilos de gerenciamento observados 
por Nonaka e Takeuchi (1986). Em 1995, Schwaber formalizou a definição de Scrum e ajudou a implantá-
lo no desenvolvimento de softwares ágeis em todo o mundo. Já em 2000, implantou a metodologia na 
empresa PatientKeeper e, nos anos seguintes, lançou três livros, sendo o primeiro deles o Agile Software 
Development with Scrum, Schwaber (2002).
Uma característica importante do método é forçar as pessoas a seguirem passos predefinidos, com 
pouca flexibilidade para mudança. A abordagem é o oposto do modelo em cascata, iniciando-se na 
análise, assim que alguns requisitos estiverem disponíveis. 
O projeto começa com uma visão composta por requisitos e funcionalidades que concretizam uma 
lista de tarefas, denominada product backlog. As prioridades dos itens desse documento determinam 
o quanto de valor cada um gera para o negócio. Depois de priorizados os itens, antes de cada iteração 
(sprint), a equipe se reúne para dizer quantos itens é possível entregar em um sprint, que, segundo 
Schwaber (2002), deve durar cerca de trinta dias, como boa prática. 
Janete
Underline
Janete
Highlight
Janete
Highlight
Janete
Underline
Janete
Highlight
96
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Product
backlog
Sprint
backlog
Potentially 
shippable
product
increment
Itens a serem 
desenvolvidos 
no projeto
Itens a serem 
desenvolvidos 
no sprint
Reunião diária 
do time
Incremento 
entregável
2-4 
semanas
Figura 25 – Visão geral do processo de trabalho Scrum 
Ao final da iteração ou do sprint, conforme ilustra a figura anterior, o que foi desenvolvido é 
apresentado ao cliente em uma reunião, e, antes do início da próxima iteração, é feita uma reunião de 
retrospectiva, em que é possível extrair lições aprendidas, para a melhoria do processo Scrum daquele 
projeto.
O Scrum define diversos papéis a serem desempenhados durante o projeto, que são:
•	 product owner:
— pode ser definido como o dono do projeto, ou o responsável por este; é quem define e prioriza 
as funcionalidades do produto;
— o dono do produto provavelmente será um gerente de projeto ou um patrocinador, um membro 
da equipe de marketing ou um cliente interno.
•	 Scrum master:
— é o responsável por garantir os valores e as práticas do Scrum dentro do time de 
desenvolvimento. 
•	 Scrum team:
— equipe responsável por desenvolver o produto;
— time ligado diretamente ao trabalho.
•	 Sprint planning:
— uma reunião efetuada antes do início de um sprint, para o time alinhar com o product owner 
o que será feito dentro do próximo sprint.
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
97
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
O Scrum define um conjunto de fases que devem ser seguidas durante a execução do projeto, que 
são:
•	 sprint: é o ciclo de desenvolvimento de um conjunto de tarefas planejadas; pode ser entendido, 
também, como o tempo estimado pelo time para produzir, testar e homologar determinadas 
funcionalidades, que serão priorizadas pelo product owner no sprint;
•	 planning: de acordo com as práticas adotadas por Schwaber (2002), o planejamento do sprint 
deve defini-lo para ocorrer em trinta dias;
•	 daily Scrum: são reuniões diárias em que cada membro do time coloca em um quadro o que fez 
no dia anterior e o que fará no dia seguinte; direcionamentos no projeto devem ocorrer durante 
essas reuniões para reduzir as possibilidades de o sprint não dar certo ou não ser cumprido no 
prazo acordado;
•	 retrospective ou sprint review: é uma reunião de lições aprendidas que ocorre após a entrega 
de um sprint e tem como objetivo analisar se o que foi feito está de acordo e o que pode ser 
melhorado.
A figura a seguir mostra um exemplo do quadro daily scrum utilizado para ilustrar a situação dos 
trabalhos durante um sprint no método Scrum. 
Atividade
5
Item da
backlog Para fazer Em andamento
Sprint 1
Para verificar Concluído
Requisito
1
Requisito
2
Atividade
6
Atividade
7
Atividade
2
Atividade
1
Atividade
2
Atividade
3
Atividade
4
Atividade
1
Atividade
5
Jô
Lilica
José
Impedido
Figura 26 – As fases e as tarefas do Scrum
Para estimar o número de funcionalidades que serão produzidas por sprint, Schwaber (2002) propõe 
um método chamado pokergame, em que cada membro do time dá uma nota que equivale a um peso. 
Os pesos são denominados de acordo com uma progressão aritmética, ou seja, 1, 2, 3, 5, 8, 13 e 21.
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Sticky Note
cda numero eh a soma dos dois anteriores
98
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
O peso que se repetir mais vezes pelos membros do time é que valerá para a funcionalidade. Ao total 
de funcionalidades, os pesos são somados, e essa é a estimativa de entrega em um sprint. 
 Observação
O peso final das funcionalidades deverá ser convertido em horas, 
considerando-se a produtividade do time, medida ao longo do tempo.
O primeiro sprint, de acordo com Schwaber (2002) é destinado à definição da arquitetura 
do sistema e é o ciclo que baliza a velocidade (produtividade) do time. Cada sprint consiste de 
uma ou mais equipes executando as atividades de desenvolvimento, empacotamento do produto, 
revisão e ajustes.
O monitoramento do progresso do projeto é realizado por meio de dois gráficos principais: o product 
burn down chart e o sprint burn down chart. 
Os gráficos mostram, ao longo do tempo, a quantidade de trabalho que ainda resta para ser feito, 
constituindo um excelente mecanismo para visualizar a correlação entre a quantidade de trabalho que 
falta realizar (em qualquer ponto) e o progresso do time do projeto em reduzir esse trabalho (BARBOSA; 
LIBARDI, 2010).
A próxima figura mostra um exemplo do gráfico burn-down chart, onde se veem o progresso ideal 
e o progresso realizado ao longo de seis dias.
140
120
100
80
60
40
20
0
Ho
ra
s
Dia
1 2 3 4 5 6
Ideal
Realizada
Figura 27 – Gráfico burndown 
Janete
Highlight
Janete
Highlight
Janete
Underline
99
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
 Saiba mais
As informações constantes neste texto são, na maioria, retratadas nos 
livros de referência do Scrum:
Agile Development with Scrum, de Ken Schwaber (2002), apresenta 
os conceitos do Scrum e suas práticas; discute o porquê do Scrum, seu 
conceito e sua organização; Agile Project Management with Scrum, 
também de Ken Schwaber (2004), mostra exemplos reais em cada capítulo 
e discute a expansão do Scrum para projetos e equipes maiores, distribuídas 
geograficamente; e, no Apêndice E, o autor mostra como o Scrum pode 
atender às exigências do modelo CMM/CMMI de qualidade de software 
(visando ao Nível 3).
No artigo Análise do Ba durante o processo Scrum, os autores Conceição 
Silva, Roriz Filho e Nunes Silva (2010) demonstram a importância do Ba em 
equipes de projetos Scrum. 
O Ba (termo de origem japonesa que pode ser traduzido como 
“espaço”), corresponde ao ambiente propício para a criação do 
conhecimento, podendo ser dividido em quatro tipos: Ba de criação; Ba 
de interação; Ba virtual; e Ba de treinamento.
Não deixe de ler:
CONCEIÇÃO SILVA, M. A.; RORIZ FILHO, H.; NUNES SILVA, H. F. Análise 
do Ba durante o processo Scrum. In: SIMPÓSIO DE ENGENHARIA DE 
PRODUÇÃO, 17., 2010, Bauru. Anais... Bauru, 2010. Disponível em: <http://
massimus.com/download/analise-do-ba-durante-o-processo-scrum/>.	
Acesso em: 17 abr. 2014.
5.4 O método ágil Iconix
O Iconix é um processo de análise e desenvolvimento de software dirigido por casos de uso e aplica 
apenas cinco diagramas da UML, dos quais dois são adendos; utiliza prototipação desde o início da 
definição do software e é mais simples que o processo unificado Rational Unified Process (RUP), porém 
sem	a	simplicidade	do	método	ágil	XP.
A figura a seguir mostra uma visão das fases do processo envolvido no Iconix. 
100
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Prototipação
Revisão dos 
requisitos
Análise de 
requisitos
Requisitos
de software
Figura 28 – Visão da fase de requisitos do processo Iconix 
A próxima figura mostra a fase de construção do software.
Análise e 
projeto 
preliminar
Projeto
Revisão 
do projeto 
preliminar
Software
pronto
Requisitos
de software
Figura 29 – Fase de construção do softwareno Iconix 
Já na próxima figura, vemos a fase de implantação do software produzido no processo Iconix. 
Software
pronto
Revisão 
detalhada e 
crítica do projeto
Ajustes finos e 
implantação
Figura 30 – Fase de implantação do software do Iconix 
Durante as fases, os desenvolvedores aplicam os diagramas da UML propostos pelo método Iconix, 
como mostra a figura.
101
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Protótipo Modelo de 
caso de uso
Modelos dinâmicos
Modelos estáticos
Modelos de domínio Modelos de classes Código
Diagrama de robustez
Diagrama de 
sequência
Figura 31 – Visão da sequência da aplicação dos diagramas da UML no Iconix
Toda a proposta se inicia com a prototipagem, que é a forma de descobrir, detalhar e garantir 
os requisitos do software a ser produzido. Com o protótipo e os requisitos definidos, parte-se para a 
construção do diagrama de caso de uso, que conterá as funcionalidades a serem implementadas no 
produto de software.
Paralelamente, vai-se construindo o modelo de domínio do projeto, isto é, o modelo dos dados que 
serão armazenados no produto de software. Na fase de construção, utilizam-se o modelo de robustez, o 
diagrama de sequência e o diagrama de classes, para a construção efetiva dos códigos do software. Ao 
final, têm-se os códigos, que são validados, ajustados e colocados à disposição do cliente em produção 
ou implantação.
O método Iconix preconiza que os casos de uso sejam o mais simples possível, sem ambiguidades, 
podendo fazer referência aos objetos do protótipo.
 Lembrete
Casos de uso são diagramas da UML para representar as funcionalidades 
do sistema e a interação entre os usuários e o sistema. Os usuários são 
denominados de atores, e as funcionalidades são os casos de uso.
Os passos para se aplicar o processo e os diagramas da UML propostos pelo Iconix são:
•	 prototipar	a	interface	com	o	usuário;
•	 escrever	um	caso	de	uso	que	dê	ideia	de	como	a	interface	irá	se	comportar;
•	 esboçar	os	diagramas	de	robustez,	sequência	e	domínio:	
102
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
— diagrama de robustez: faz a derivação dos cenários dos casos de uso em uma visão de solução 
técnica dentro das camadas de interface, lógica da aplicação e camada de banco de dados; 
— diagrama de sequência: mostra a lógica das transações por meio da comunicação entre os 
objetos do sistema e a passagem de comunicação entre eles (mensagens); 
— diagrama de domínio: é a visão das entidades de dados no nível de negócio, com seus dados 
básicos e seus relacionamentos de alto nível.
•	 programar	a	interface	de	modo	que	ela	implemente	o	que	o	caso	de	uso	determina;
•	 retornar	ao	primeiro	passo	até	terminarem	as	interfaces	necessárias	ao	projeto;
•	 quando	a	análise	de	requisitos,	as	interfaces	e	a	construção	terminarem,	já	se	deverá	estar	num	
estágio de pré-entrega, faltando apenas pequenos ajustes.
Percebe-se que, mesmo não abrindo mão de alguns diagramas, o método ágil Iconix é razoavelmente 
simples e muito robusto. O processo permite que os erros de análise e as dúvidas dos clientes ou usuários 
sejam minimizadas conforme as iterações do processo ocorrem.
O processo utiliza o mínimo possível de ferramentas de desenvolvimento propostas pela linguagem 
UML, sem, no entanto, deixar de lado documentação razoável.
 Saiba mais
Todo esse texto foi uma interpretação do processo Iconix constante do 
livro:
ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development 
with Iconix process. EUA: Appress, 2005.
6 OUTROS MODELOS E MÉTODOS ÁGEIS
6.1 O método ágil Feature Driven Development (FDD)
O método ágil FDD já existia antes do Manifesto Ágil, que ocorreu em 2001. Foi concebido 
originalmente por Jeff de Luca, em Singapura, entre os anos de 1997 e 1999, com base no método 
Coad (criado por Peter Coad, nas décadas de 1980 e 1990) e nos processos interativos e Lean, 
já utilizados por ele; busca o desenvolvimento por funcionalidade, ou seja, por um requisito 
funcional do sistema; é prático para o trabalho com projetos iniciais ou projetos com codificações 
existentes.	Apesar	de	haver	algumas	diferenças	entre	os	métodos	FDD	e	XP,	é	possível	utilizar	as	
melhores práticas de cada um. 
103
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
O FDD atua bem em conjunto com o método Scrum, pois como este atua no foco do gerenciamento 
do projeto, e o FDD, no processo de desenvolvimento, eles se complementam.
Com relação ao FDD, este possui cinco processos básicos:
•	 desenvolvimento	de	modelo	abrangente	(análise	orientada	por	objetos);
•	 construção	de	lista	de	funcionalidades	(decomposição	funcional);
•	 planejamento	por	funcionalidade	(planejamento	incremental);
•	 detalhe	por	funcionalidade	(desenho	orientado	a	objetos);
•	 construção	por	funcionalidade	(programação	e	teste	orientados	a	objetos).
Assim	como	acontece	no	método	XP,	o	FDD	faz	uso	intenso	de	teste	de	software. Dessa forma, é 
possível utilizar, também, na codificação, o método TDD (é indicada a utilização deste para manter a 
qualidade do software). Daí temos a combinação do FDD, como processo, do Scrum, como gestão do 
processo, e do TDD, como ênfase na codificação dirigido por testes.
O pessoal que desenvolveu o método FDD acredita, assim como a teoria de sistemas afirma, que a 
soma das partes é maior do que o todo. Dessa forma, apesar de criar um modelo abrangente baseado no 
todo que será desenvolvido (ver o sistema completo primeiro), essa fase se inicia com o detalhamento 
do domínio do negócio, com divisão das áreas que serão modeladas. 
O modelo só estará pronto quando todos da equipe estiverem de acordo. O planejamento é feito 
com base na lista de funcionalidades ou requisitos do software. Trabalhando com FDD, em conjunto com 
o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de usuários a 
serem desenvolvidas.
Com base na lista de funcionalidades, deve-se planejar individualmente, de forma incremental. 
Isso, em conjunto com o Scrum, deve ser analisado como etapa de desenvolvimento do incremento, 
portanto, esse planejamento é feito com base no que será desenvolvido naquele incremento ou sprint.
Aplicando-se o Scrum e separando-se o que será feito no sprint, essas funcionalidades serão 
colocadas no seu backlog. 
O que está no backlog são funcionalidades que serão desenvolvidas durante o sprint (que pode ser 
de duas a quatro semanas, conforme sugere o método Scrum). Essas tarefas são então planejadas com 
maior rigor, e, nesse ponto, tem-se o planejamento incremental, ou seja, planeja-se apenas o que vai ser 
desenvolvido. Nessa etapa, os envolvidos no processo são apenas os componentes da equipe, ou seja, 
desenvolvedores, analistas, testadores etc. que vão atuar no processo. Eles devem selecionar os itens 
com base no tempo que possuem e nas qualificações atuais da equipe.
104
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Após o planejamento, é feito o detalhamento. Nessa fase, é de extrema importância que o desenho 
esteja de acordo com o que o cliente deseja, sendo mantido contato constante com esse cliente, como 
em todas as metodologias ágeis. Essa documentação é a base para o desenvolvimento: não se deve 
perder tempo com documentação que não será utilizada, mas é necessário registrar.
Posteriormentese inicia a fase de desenvolvimento e teste reais. O desenvolvimento também é 
incremental, e é indicada a utilização de testes do início ao fim do processo, além da utilização de 
integração contínua.
Um	ponto	que	diverge	do	método	XP	é	que,	no	FDD,	o	desenvolvedor	é	incentivado	como	o	único	
responsável	pelo	módulo	que	desenvolve;	já	no	XP,	o	código	é	comunitário.
 Saiba mais
Para saber mais sobre o método ágil FDD, leia: 
ROCHA, F. G. Introdução ao FDD – Feature Driven Development. [s.d.]. 
Disponível em: <http://www.devmedia.com.br/introducao-ao-fdd-feature-
driven-development/27971#ixzz2qOV6vIG1>.	Acesso	em:	13	fev.	2014.
A figura a seguir mostra a visão gráfica do conceito de integração contínua aplicado no método 
FDD.
Design ou 
projeto
Inspeção do design
Codificação
(sugere-se o TDD)
Testes
(sugere-se o TDD)
Integração
Inspeção de 
código
Build completo 
(entregável)
Processo FDD
cíclico e incremental
Figura 32 – Visão do conceito de integração contínua 
105
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Utilizar a integração contínua permite que a equipe esteja em contato constante com o cliente, 
tornando o processo ágil e com entregas também constantes.
Como cada fase apresentada na figura anterior é específica e curta, e como as fases se completam, 
são necessárias informações para manter o controle, bem como para analisar a quantidade de recursos 
que estão sendo desenvolvidos de modo semelhante ao burn down e ao burn up do Scrum.
Segundo o método FDD, o percentual de tempo gasto em cada fase é:
•	 levantamento	do	domínio	da	aplicação:	1%;
•	 projeto:	40%;
•	 inspeção	do	projeto:	3%;
•	 desenvolvimento:	45%;
•	 inspeção	do	código:	10%;
•	 integração:	1%.
 Saiba mais
Para saber mais sobre integração contínua, leia o artigo: 
CAETANO, C. Dividir, conquistar e integrar: conceitos de integração 
contínua para testadores ágeis. Linha de Código, [s.d.]. Disponível em: 
<http://www.linhadecodigo.com.br/artigo/1252/dividir-conquistar-e-
integrar-conceitos-de-integracao-continua-para-testadores-ageis.aspx>.	
Acesso em: 3 fev. 2014.
O método FDD aplica as chamadas melhores práticas, que indicam boas práticas ao desenvolver 
com o FDD: 
•	 modelagem	orientada	a	objetos	do	domínio;
•	 desenvolvimento	por	funcionalidade;
•	 classe	proprietária,	ou	seja,	a	unidade	é	feita	 individualmente,	evitando-se,	assim,	conflitos	na	
equipe;
•	 equipes	de	recursos:	são	pequenas,	destinadas	a	desenvolver	recursos	necessários	ao	projeto,	de	
forma secundária;
106
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 inspeção:	é	realizada	constantemente	para	garantir	a	boa	qualidade	do	código	e	do	projeto;
•	 gerenciamento	de	configuração;
•	 integração	contínua	para	demonstrar	constantemente	as	funcionalidades	ao	cliente.
6.2 O método ágil Adaptative Sofware Development (ASD)
O método ágil ASD, em português, “desenvolvimento adaptável de software”, possui as seguintes 
características:
•	 é	iterativo	e	incremental;
•	 pode	ser	aplicado	também	a	sistemas	grandes	e	complexos;
•	 é	considerado	um	arcabouço	para	evitar	o	caos;
•	 o	cliente	sempre	está	presente	durante	o	processo;
•	 desenvolvimento	 de	 aplicações	 em	 conjunto	 com	 a	 técnica	 de	 reunião	 Joint Application 
Development (JAD).
A próxima figura mostra os ciclos do processo ASD, que é constituído de três fases:
Aprender
Colaborar Especular
Figura 33 – Ciclos do método ASD 
As fases do método ASD são:
•	 especular	(speculate): fase em que se fixam prazos e objetivos, e se define um plano baseado em 
componentes;
•	 colaborar	(collaborate): fase em que se constrói de forma concorrente os vários componentes;
•	 aprender	 (learn): fase em que são efetuadas repetitivas revisões de qualidade e foco na 
demonstração das funcionalidades desenvolvidas (learning loop); conta com a presença do cliente 
e de especialistas do domínio.
107
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Os ciclos duram de quatro a oito semanas.
Com relação às propriedades, o ASD é:
•	 orientado	a	missões	(misson-driven): atividades são justificadas por uma missão que pode mudar 
ao longo do projeto;
•	 baseado	em	componentes	(component-based): construir o sistema em pequenos pedaços;
•	 iterativo	 (iterative): desenvolvimento em cascata (waterfall) só funciona em ambientes bem-
definidos e compreendidos; Para o método ASD é mais fácil refazer algum código do que investir 
muito tempo e recursos para fazer corretamente na primeira vez;
•	 com	prazos	prefixados	(time-boxed): força os participantes do projeto a definirem severamente 
decisões logo cedo;
•	 com	 tolerância	a	mudanças	 (change-tolerant): as mudanças são frequentes; é sempre melhor 
estar pronto a adaptá-las do que controlá-las; constante avaliação de quais componentes podem 
mudar;
•	 orientado	a	riscos	(risk driver): itens de alto risco são desenvolvidos primeiro.
Com relação a cargos e responsabilidades, o ADS não os descreve em detalhes, mas define:
•	 executivo	responsável	(executive sponsor);
•	 participantes	de	uma	sessão	(workshop) do desenvolvimento de aplicações em conjunto (JAD);
•	 facilitador	(facilitator): lidera e planeja as sessões;
•	 escriba	(scribe): efetua anotações;
•	 cliente	(customer): sempre presente;
•	 gerente	de	projetos	(project manager);
•	 desenvolvedores	(developers).
6.3 O método ágil Dynamic Systems Development Method (DSDM)
O método ágil DSDM, também chamado método dinâmico de desenvolvimento de software, é 
considerado	predecessor	do	método	ágil	XP	e	tem	como	características	principais:
•	 arcabouço	para	desenvolvimento	rápido	de	aplicações	(RAD);
108
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 fixação	de	tempo	e	recursos,	ajustando	a	quantidade	de	funcionalidades	a	serem	implementadas;
•	 utilizado	por	equipes	pequenas;
•	 suporta	a	mudança	de	requisitos	durante	o	ciclo	de	vida	do	desenvolvimento.
A seguir, a figura mostra como o método apresenta e aplica as fases de desenvolvimento.
Modelo 
funcional 
(iteração)
Implementação
Design e 
construção 
(iteração)
Viabilidade
Figura 34 – Fases do método DSDM 
O método ágil DSDM define um conjunto de cargos e responsabilidades que devem ser obedecidos 
pelos times participantes do processo de desenvolvimento e de suas fases:
•	 desenvolvedores	(equipes	de	desenvolvimento	de	softwares de níveis júnior, pleno e sênior);
•	 coordenador-técnico;
•	 usuário-embaixador;
•	 usuário-consultor;
•	 visionário;
•	 executivo	responsável;
•	 especialista	do	domínio;
•	 gerente	do	domínio.
O método propõe diversas práticas que devem ser aplicadas:
•	 usuário	sempre	envolvido	durante	o	ciclo	de	desenvolvimento;
•	 equipe	do	DSDM	autorizada	a	tomar	decisões;
•	 foco	na	entrega	frequente	do	produto;
109
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 adaptação	ao	negócio	define	o	critério	de	entregas;
•	 premissa	“construa	o	produto	certo	antes	de	construí-lo	corretamente”;
•	 desenvolvimento	iterativo	e	incremental;
•	 mudanças	são	reversíveis	utilizando-se	pequenas	iterações;
•	 requisitos	são	acompanhados	em	alto	nível;•	 testes	são	integrados	ao	ciclo	de	vida.
6.4 O método ágil Crystal
O método ágil Crystal/Clear faz parte de um conjunto de metodologias criadas pelo autor Cockburn 
(2004), editor da série Agile Software Development, com diversos livros publicados pela Addison-Wesley.
 Saiba mais
Mais informações sobre o método Crystal/Clear podem ser encontradas 
no	 endereço	 disponível	 em:	 <http://alistair.cockburn.us/crystal>.	 Esse	
endereço aponta para diversos artigos sobre os métodos ágeis e sobre o 
método Crystal/Clear.
As premissas apresentadas para esse conjunto de metodologias são:
•	 todo	projeto	tem	necessidades,	convenções	e	metodologias	diferentes;
•	 o	 funcionamento	 do	 projeto	 é	 influenciado	 por	 fatores	 humanos,	 e	 há	 melhora	 quando	 os	
indivíduos produzem melhor;
•	 comunicação	mais	efetiva	e	lançamentos	frequentes	reduzem	a	necessidade	de	construir	produtos	
intermediários do processo;
•	 o	 método	 Crystal/Clear	 foi	 direcionado	 para	 projetos	 pequenos	 com	 equipes	 de	 até	 seis	
desenvolvedores;
•	 assim	como	o	Scrum,	os	membros	da	equipe	têm	especialidades	distintas;
•	 existe	ênfase	na	comunicação	entre	os	membros	do	grupo;
•	 para	grupos	maiores,	existem	metodologias	diferentes	no	Crystal;
110
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 toda	 especificação	 e	 todo	 projeto	 são	 feitos	 informalmente,	 utilizando	 quadros	 publicamente	
visíveis;
•	 os	requisitos	são	elaborados	utilizando	casos	de	uso	(UML),	um	conceito	similar	às	histórias	de	
usuários	XP;
•	 cada	enunciado	de	requisito	se	torna	uma	tarefa	para	ser	executada;
•	 as	entregas	das	novas	versões	de	software são feitas em incrementos regulares de um mês;
•	 podem	existir	alguns	subprodutos	do	processo	que	são	responsabilidade	de	membros	específicos	
do projeto.
Grande parte do método é pouco definida e, segundo Cockburn (2004), isso é proposital. A ideia do 
Crystal/Clear é permitir que cada organização implemente as atividades que lhe pareçam adequadas, 
fornecendo um mínimo de suporte útil, do ponto de vista de comunicação e documentos.
6.5 método ágil Test Driven Development (TDD)
O método ágil TDD de desenvolvimento de software, que se baseia em um ciclo curto de repetições, 
caracteriza-se por: 
•	 primeiro,	 o	 desenvolvedor	 escreve	 um	 caso	 de	 teste	 automatizado	 que	 define	 uma	melhoria	
desejada ou uma nova funcionalidade;
•	 depois	 é	 produzido	 um	 código	 que	 possa	 ser	 validado	 pelo	 teste,	 para,	 posteriormente,	 ser	
refatorado para um código sob padrões aceitáveis.
Beck	 (2001),	 criador	 do	método	 ágil	 XP	 e	 considerado	 o	 criador	 ou	 o	 “descobridor”	 da	 técnica,	
declarou, em 2003, que o TDD encoraja designs de código simples e inspira confiança.
Por meio do TDD, programadores podem aplicar o conceito para melhorar e depurar código legado 
desenvolvido a partir de técnicas antigas. O TDD requer dos desenvolvedores a criação de testes de 
unidade automatizados antes de escrever o código da aplicação. 
O ciclo de desenvolvimento TDD abrange os seguintes passos:
•	 Adicionar	um	teste:
— no processo TDD, cada nova funcionalidade se inicia com a criação de um teste;
— esse teste precisa, inevitavelmente, falhar, porque é escrito antes de a funcionalidade ser 
implementada (se não falhar, a funcionalidade ou melhoria “proposta” será óbvia);
111
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
— para escrever um teste, o desenvolvedor precisa entender claramente as especificações e os 
requisitos da funcionalidade;
— o desenvolvedor pode fazer isso por meio de requisitos, casos de uso ou user stories que 
abranjam as funcionalidades e exceções condicionais;
— essa é a diferenciação entre desenvolvimento dirigido a testes e a forma tradicional, que é 
escrever testes de unidade depois do código desenvolvido;
— ele torna o desenvolvedor focado nos requisitos “antes” do código, o que é uma sutil, mas 
importante diferença;
— execute todos os testes e veja se algum deles falha;
— esse passo valida se todos os testes estão funcionando corretamente e se o novo teste não traz 
nenhum equívoco, sem requerer nenhum código novo;
— pode-se considerar que esse passo testa o próprio teste: ele regula a possibilidade de o novo 
teste passar;
— o novo teste deve, então, falhar, pela razão esperada: a funcionalidade não foi desenvolvida;
— isso aumenta a confiança de que se está testando a coisa certa, e de que o teste somente irá 
passar nos casos intencionados.
•	 Escrever	código:
— o próximo passo é escrever o código que irá ocasionar o teste a passar;
— o novo código escrito até esse ponto poderá não ser perfeito e, por exemplo, passar 
no teste de uma forma não elegante; isso é aceitável, porque posteriormente ele será 
melhorado;
— o importante é que o código escrito deve ser construído somente para passar no teste; 
nenhuma funcionalidade (muito menos não testada) deve ser permitida em qualquer 
ponto;
— execute os testes automatizados e veja-os serem executados com sucesso;
— se todos os testes passarem, o programador poderá ficar confiante de que o código possui 
todos os requisitos testados;
— este é um bom ponto que inicia o passo final do ciclo TDD.
112
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
•	 Refatorar	código:
— nesse ponto, o código pode ser limpo tanto quanto for necessário;
— ao executar novamente os testes, o desenvolvedor pode confiar que a refatoração não será um 
processo danoso a nenhuma funcionalidade existente;
— um conceito relevante nesse momento é o de remoção de duplicação de código, considerado 
um importante aspecto no design de um software;
— nesse caso, entretanto, significa remover qualquer duplicação entre código de teste e código 
de produção.
•	 Repetir	tudo:
— iniciando com outro teste, o ciclo é então repetido, empurrando a funcionalidade para frente;
— o tamanho dos passos deve ser pequeno – de uma a dez edições de texto entre cada execução 
de testes;
— se o novo código não satisfizer rapidamente um novo teste ou outros testes falharem 
inesperadamente, o programador deverá desfazer ou reverter as alterações, em vez do uso de 
excessiva depuração;
— a integração contínua ajuda a prover pontos reversíveis. 
 Observação
Estudos com a aplicação do TDD descobriram que programadores que 
escreviam mais testes tendiam a ser mais produtivos. Hipóteses relacionando 
a qualidade de código e uma correlação direta entre TDD e produtividade 
foram inconclusivas. Desenvolvedores usando TDD puramente em novos 
projetos reportaram que raramente necessitaram da utilização de um 
depurador. 
6.6 A modelagem ágil (MA)
A modelagem ágil ou MA tem sido proposta por diversos autores consagrados como um caminho 
alternativo para as pessoas que querem mais do que os métodos ágeis oferecem, todavia não podem 
abrir mão de um pouco de documentação, padrões e contratações formais.
113
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Para Ambler (2004), um dos signatários do Manifesto Ágil, tem-se:
A modelagem ágil se propõe a encontrar um meio-termo, o qual permita 
uma modelagem suficiente para explorar e documentar um sistema de 
modo eficaz, mas não a ponto de tornar-se isso um fardo e fatalmente 
torná-lo um fracasso (AMBLER, 2004). 
A figura a seguir apresenta uma visão sobre os extremosque as metodologias, os métodos e os 
modelos apresentam na atualidade.
Sem nenhuma 
modelagem
Frequentemente resulta 
em retrabalho quando o 
software demonstra ser 
mal-projetado
Faz que os esforços 
de desenvolvimento 
caminhem lentamente
Com excesso 
de modelagem
Extremos jamais 
são bons
•	Necessidades
•	Requisitos
•	Códigos
•	Testes
•	Arquitetura
•	Banco	de	dados
•	Transações
Análise
Implementação
Design
Figura 35 – Os extremos do desenvolvimento de software 
A modelagem ágil (MA), de acordo com Ambler (2004), é uma metodologia baseada na prática e 
na documentação eficazes de sistemas baseados em software. É um conjunto de práticas guiadas por 
princípios e valores para profissionais de software aplicarem em seu dia a dia. A MA não é um processo 
prescritivo.
A MA tem três objetivos, de acordo com o autor:
•	 definir	e	mostrar	como	colocar	em	prática	um	conjunto	de	valores,	princípios	e	práticas	relativas	
a uma modelagem eficaz e leve; esse objetivo segue os princípios dos métodos ágeis; 
•	 lidar	com	a	questão	de	como	aplicar	técnicas	de	modelagem	de	projetos	de	software adotando 
uma perspectiva ágil; esse objetivo visa a garantir um pouco da interação escrita nas formas de 
comunicação; 
•	 discutir	como	se	pode	melhorar	as	atividades	de	modelagem	adotando	uma	perspectiva	“quase	ágil”	
para equipes de projetos prescritivos; mudança de paradigma no desenvolvimento convencional e 
clássico.
A	MA	adota	os	valores	XP	de	Kent	Beck,	que	são:	comunicação,	simplicidade,	feedback e coragem. 
Mas adiciona um quinto valor, a humildade.
114
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
Humildade para admitir que você pode não saber tudo e que outros têm valor a acrescentar aos 
esforços no projeto. Ainda de acordo com os autores da modelagem ágil:
•	 um	modelo	ágil	é	suficiente,	pois:
— cumpre seu propósito;
— é compreensível;
— é suficientemente preciso;
— é suficientemente consistente;
— é suficientemente detalhado;
— proporciona valor positivo;
— é o mais simples possível.
 Resumo
Esta unidade teve início com a discussão sobre o aparecimento das 
propostas dos métodos ágeis na área de desenvolvimento de software e a 
motivação que levou diversos pesquisadores, especialistas e consultores a 
proporem uma nova abordagem para os processos de software.
São diversas as motivações que se apresentaram ao longo do tempo. As 
metodologias eram complexas, pesadas e burocráticas, e não estavam mais 
atendendo às novas necessidades dos clientes e das áreas de negócio, que 
eram, em essência, o dinamismo das organizações.
A partir das definições consagradas sobre os métodos ágeis, o texto faz 
um alinhamento entre esses métodos e o RAD, da década de 1980, que 
provavelmente deu inspiração para os criadores dos métodos ágeis. Isso 
ocorreu porque a proposta RAD era ousada para a época e já contemplava 
o planejamento não intensivo em troca da rapidez da programação. Logo 
são apresentadas a história dos métodos ágeis e a reunião de 2001, em que 
se criou o Manifesto Ágil, tornando-se este uma declaração de valores e 
princípios até hoje seguidos pela comunidade ágil. 
O texto mostra um quadro comparativo entre o desenvolvimento 
ágil e o orientado ao planejamento ou ciclo clássico de desenvolvimento 
de software, deixando claro que os métodos ágeis não são a panaceia 
115
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
do desenvolvimento de software e que, para serem bem-sucedidos, 
precisam ser aplicados em projetos que sejam aderentes às suas 
características.
Em seguida, o texto apresenta com detalhes os principais métodos 
ágeis atuantes nos mercados internacional e nacional, com ênfase nos 
métodos	XP	e	Scrum,	os	mais	usados	no	mercado	brasileiro.	O	método	
XP	é	voltado	para	as	boas	práticas	de	construção	ou	programação	de	
software, enquanto o Scrum é um método fortemente inspirado na 
gestão de projetos ágeis.
Esse	fato	é	percebido	pelos	objetivos	dos	dois	métodos:	o	XP	está	
baseado em 12 práticas, a maioria delas envolvendo as atividades de 
programação, com poucas preocupações gerenciais e de documentação 
dos artefatos do ciclo de vida de desenvolvimento. Em contrapartida, 
o método Scrum é todo voltado para práticas de gerenciamento de 
sprints, tais como o planejamento, o backlog do produto e do sprint, 
as reuniões diárias e as reuniões de avaliação e obtenção das lições 
aprendidas.
O “casamento” das práticas gerenciais do método Scrum com as práticas 
do	“como”	fazer	programação	do	XP	é	o	que	se	recomenda	na	adoção	dos	
métodos ágeis comprovadamente eficientes.
Dando continuidade, o texto apresenta outros métodos ágeis, tais como 
Iconix, FDD, ASD, DSDM, Crystal e TDD. 
O TDD pode ser considerado como um método complementar aos 
outros, já que atua especificamente nos processos de testes dentro do 
ciclo de desenvolvimento. Em contrapartida, a maioria dos métodos ágeis 
aparece na proposta da modelagem ágil que abre caminho alternativo para 
as empresas ou as pessoas que querem agilidade, mas não podem abrir 
mão de um planejamento mais efetivo de documentação do produto, até 
por razões comerciais.
Diversos autores foram utilizados para dar uma visão resumida e 
abrangente das abordagens ágeis no ciclo de vida dos produtos de software, 
e as empresas deverão estudar e aplicar as propostas que forem mais 
adequadas às suas realidades. 
116
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade III
 Exercícios
Questão 1. O Manifesto Ágil é um documento criado em 2001, em Utah, EUA, por diversos 
especialistas em processos de desenvolvimento, que reúne os princípios e os valores adotados para os 
métodos ágeis. A partir dessa constatação, têm-se os seguintes valores:
I – Os indivíduos e suas interações, mais que procedimentos e ferramentas. 
II – A capacidade de resposta às mudanças, mais que um time motivado. 
III – A colaboração com o cliente, mais que negociação de contratos. 
IV – O funcionamento do software, mais que documentação abrangente. 
V – A capacidade de resposta às mudanças, mais que seguir um plano preestabelecido. 
Assinale a alternativa correta: 
A) As afirmativas I, II e III estão corretas. 
B) As afirmativas II, IV e V estão corretas. 
C) As afirmativas II e IV estão corretas. 
D) As afirmativas I, III, IV e V estão corretas. 
E) As afirmativas I, II, III, IV e V estão corretas. 
Resposta correta: alternativa D.
Análise das afirmativas
I) Afirmativa correta.
Justificativa: de acordo com os quatro valores fundamentais do Manifesto Ágil.
II) Afirmativa incorreta.
Justificativa: essa afirmativa não faz parte do Manifesto Ágil, e um time motivado faz parte dos 
princípios dos métodos ágeis.
III) Afirmativa correta.
Justificativa: de acordo com os quatro valores fundamentais do Manifesto Ágil.
117
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
IV) Afirmativa correta.
Justificativa: de acordo com os quatro valores fundamentais do Manifesto Ágil. 
V) Afirmativa correta.
Justificativa: de acordo com os quatro valores fundamentais do Manifesto Ágil.
Questão 2. A partir da década de 1990, surgiram diversas propostas de mudança na forma de 
se desenvolver softwares, principalmente, nos Estados Unidos. Essas formas de trabalhar foram 
denominadas, na reunião de Utah, de 2001,como métodos ágeis. A partir dessa constatação, têm-se as 
seguintes afirmativas:
I	–	O	método	ágil	XP	preconiza	um	desenvolvimento	de	software fortemente baseado em simplicidade. 
II – O método ágil Scrum também pode ser entendido como uma metodologia completa de 
desenvolvimento de software. 
III – O método Scrum pode ser entendido como um processo particular das metodologias clássicas.
IV	–	O	método	XP	começa	com	uma	arquitetura	de	risco	e,	a	partir	dos	riscos,	desenvolve	soluções	
por meio de pequenas iterações. 
V	–	O	método	Iconix	é	semelhante	aos	métodos	XP	e	Scrum,	pois	trabalha	praticamente	com	os	
times se comunicando face a face e com quase nenhuma documentação.
Assinale a alternativa correta: 
A) As afirmativas I e III estão corretas. 
B) As afirmativas II, III, IV e V estão corretas.
C) A afirmativa I está correta. 
D) As afirmativas III, IV e V estão corretas. 
E) As afirmativas I, II, IV e V estão corretas. 
Resolução desta questão na plataforma.