Engenharia de software1 Unidade 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;
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:
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 de indiví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); 
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).
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.
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ática 9): 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. 
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 ExtremeProgramming 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; 
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.
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. 
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.
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 sprinte 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.
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 
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 software no 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 
sejamminimizadas 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.
Posteriormente se 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-seconsiderar 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 extremos que 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 dosmé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.