Universidade Federal de Minas Gerais

Instituto de Ciências Exatas

Departamento de Ciências da Computação

ALEXANDRE COTA MOL

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

Belo Horizonte
2007
 Universidade Federal de Minas Gerais
Instituto de Ciências Exatas
Departamento de Ciências da Computação
Especialização em Informática: Ênfase: Engenharia de Software

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

por

ALEXANDRE COTA MOL

Monografia de Final de Curso

CEI-ES 0243-T11-2006-1

Prof. Dr. Rodolfo Sérgio Ferreira de Resende

Orientador

Belo Horizonte
2007
 ALEXANDRE COTA MOL

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

Monografia apresentada ao Curso de Especialização

em Informática do Departamento de Ciências Exatas
da Universidade Federal de Minas Gerais, como
requisito parcial para a obtenção do grau de
Especialista em Informática.

Área de concentração: Engenharia de Software

Orientador: Prof. Dr. Rodolfo Sérgio Ferreira de

Resende

Belo Horizonte
2007
Folha de aprovação: fornecida
pela secretaria do Programa de
Pós-Graduação em Ciências da
Computação, com as devidas
assinaturas do orientador e da
banca de avaliação do trabalho.
À todos aqueles que têm ensinado-me a ser uma pessoa melhor a cada dia,
pela confiança, por suas palavras motivadoras, pelo carinho,
o comportamento ético, a honestidade, a amizade e por atitudes admiráveis
que têm tornado exemplos e práticas em minha vida.
 AGRADECIMENTOS

Inicialmente agradeço a Deus pelos dons recebidos.

À minha esposa e aos meus filhos pelo amor incondicional.
Aos amigos e familiares por entenderem a minha ausência durante a especialização.
Aos meus colegas de curso, Felipe, Jefferson e Ricardo, pelas palavras de motivação.
À todos os colegas pela amizade e companheirismo.
Ao meu orientador, Prof. Dr. Rodolfo, pela sinceridade e agilidade em orientar-me.
A todos os professores pela dedicação em transmitir-nos os seus conhecimentos.
"A primeira e a melhor das vitórias é a conquista de si mesmo.”
Platão
 RESUMO

Os métodos ágeis surgiram quando os métodos tradicionais de desenvolvimento de

software começaram a ser questionados, devido, entre outros aspectos, ao grande volume
de documentação. Os métodos ágeis ganharam mais atenção com a publicação de um
manifesto em 2001. Métodos ágeis são essencialmente métodos iterativos, incrementais
e evolutivos de desenvolvimento de software, e uma de suas metas é aceitar as mudanças
de requisitos durante o processo de desenvolvimento, promovendo entregas progressivas
de software funcional o mais rápido possível. Os métodos ágeis têm como uma das suas
premissas a participação do cliente no processo de desenvolvimento de software. O
cliente define e prioriza o que será desenvolvido a cada etapa. Apesar de que os métodos
ágeis têm sido classificados como aplicáveis somente a pequenas equipes, existem
alguns exemplos onde foram aplicados a grandes equipes com uma centena de pessoas.
Este trabalho discute os seguintes métodos ágeis Adaptative Software Development,
Crystal Clear, Crystal Orange, Dynamic Systems Development Method, Extreme
Programming, Feature Driven Development, Lean Development e Scrum. Ao término
deste trabalho existem algumas comparações entre estes métodos e o Rational Unified
Process.

Palavras-chave: Método Ágil. Manifesto. Adaptative Software Development. Crystal.

Dynamic Systems Development Method. Extreme Programming. Feature Driven
Development. Lean Development. Scrum. Desenvolvimento de software iterativo
incremental.
 ABSTRACT

The agile methods appeared when the traditional software development started being
questioned, due, among several aspects, to the large volume of documentation. The
agile methods got more attention with the publication of a manifesto in 2001. Agile
methods are essentially iterative, incremental and evolutionary software development
methods, and one of their goals is to accept the changes of requirements during the
development process, promoting progressive deliveries of functional software as soon
as possible. The agile methods are based on the customer’s participation in the process
of software development. The customer defines and prioritizes what will be developed
at each phase. Although the agile methods have been classified as applicable only to
small teams, some examples exist where they were applied to teams consisting of
hundreds of people. This work discusses the following agile methods: Adaptative
Software Development, Crystal Clear, Crystal Orange, Dynamic Systems Development
Method, Extreme Programming, Feature Driven Development, Lean Development and
Scrum. At the end of this work there are some comparisons among these methods and
the Rational Unified Process.

Keywords: Agile Method. Manifesto. Adaptative Software Development. Crystal.

Dynamic Systems Development Method. Extreme Programming. Feature Driven
Development. Lean Development. Scrum. Iterative incremental development of
software.
 LISTA DE FIGURAS

FIG. 1 – EQUILÍBRIO ENTRE APERFEIÇOAMENTO E ADAPTAÇÃO (DE

COCKBURN E HIGHSMITH)....................................................................................29

FIG. 2 – AS METODOLOGIAS DO CRYSTAL SÃO NOMEADAS POR CORES

(EM INGLÊS)................................................................................................................36

TAB. 1 – MÉTODOS ORDENADOS PELO NÍVEL DE AGILIDADE E O

FORMALISMO (ADAPTAÇÃO DE BOEHM, 2003)...............................................60

TAB. 2 – ESCOPO DE APLICAÇÃO DO MÉTODO (ADAPTAÇÃO DE BOEHM,

2003)................................................................................................................................61

TAB. 3 – CICLO DE VIDA DE CADA ITERAÇÃO (ADAPTAÇÃO DE BOEHM,

2003)................................................................................................................................62

TAB. 4 – FORMALISMO IMPOSTO POR CADA MÉTODO (ADAPTAÇÃO DE

BOEHM, 2003)...............................................................................................................62
 LISTA DE SIGLAS

AM Agile Modeling
ASD Adaptive Software Develompent
DSDM Dynamic Systems Development Method
FDD Feature-Driven Development
IID Interactive Incremental Development
JAD Joint Application Development
LD Lean Development
OO Object-Oriented
OSS Open Source Software
PP Programatic Programming
PSP Personal Software Process
ROI Return Of Investment
RUP Rational Unified Process
TST Team Software Process
UP Unified Process
XP Extreme Programming
 LISTA DE TABELAS

FIG. 1 – EQUILÍBRIO ENTRE APERFEIÇOAMENTO E ADAPTAÇÃO (DE

COCKBURN E HIGHSMITH)....................................................................................29

FIG. 2 – AS METODOLOGIAS DO CRYSTAL SÃO NOMEADAS POR CORES

(EM INGLÊS)................................................................................................................36

TAB. 1 – MÉTODOS ORDENADOS PELO NÍVEL DE AGILIDADE E O

FORMALISMO (ADAPTAÇÃO DE BOEHM, 2003)...............................................60

TAB. 2 – ESCOPO DE APLICAÇÃO DO MÉTODO (ADAPTAÇÃO DE BOEHM,

2003)................................................................................................................................61

TAB. 3 – CICLO DE VIDA DE CADA ITERAÇÃO (ADAPTAÇÃO DE BOEHM,

2003)................................................................................................................................62

TAB. 4 – FORMALISMO IMPOSTO POR CADA MÉTODO (ADAPTAÇÃO DE

BOEHM, 2003)...............................................................................................................62
 SUMÁRIO

1 INTRODUÇÃO....................................................................................................................13

2 OS MÉTODOS ÁGEIS........................................................................................................16
2.1 O SURGIMENTO DOS MÉTODOS ÁGEIS.....................................................................................16
2.2 O MOVIMENTO ÁGIL............................................................................................................16
2.3 O MÉTODO ITERATIVO INCREMENTAL DE DESENVOLVIMENTO.....................................................18
2.4 O DESENVOLVIMENTO EVOLUTIVO..........................................................................................20
2.5 O DESENVOLVIMENTO ADAPTÁVEL.........................................................................................20
2.6 O DESENVOLVIMENTO ÁGIL..................................................................................................20
2.7 CONTRASTES ENTRE MÉTODOS ÁGEIS E MÉTODOS TRADICIONAIS...............................................22
2.7.1 Metas Básicas do Projeto..........................................................................................24
2.7.2 Tamanho do Projeto...................................................................................................24
2.7.3 Ambiente do Projeto..................................................................................................24
2.7.4 Relações com o Cliente.............................................................................................25
2.7.5 Planejamento e Controle...........................................................................................26
2.7.6 Comunicação no Projeto...........................................................................................26
2.7.7 Requisitos..................................................................................................................27
2.7.8 Desenvolvimento.......................................................................................................27
2.7.9 Testes.........................................................................................................................28
2.7.10 Clientes....................................................................................................................28
2.7.11 Desenvolvedores......................................................................................................29
2.7.12 Cultura.....................................................................................................................29
3 UM COMPARATIVO ENTRE DIVERSOS MÉTODOS................................................31
3.1 SCRUM...............................................................................................................................31
3.2 ADAPTATIVE SOFTWARE DEVELOPMENT (ASD)........................................................................33
3.3 LEAN DEVELOPMENT (LD)...................................................................................................34
3.4 CRYSTAL.............................................................................................................................35
3.4.1 Crystal Clear .............................................................................................................38
3.4.2 Crystal Orange...........................................................................................................41
3.5 EXTREME PROGRAMMING (XP) ............................................................................................43
3.6 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)............................................................51
3.7 FEATURE-DRIVEN DEVELOPMENT (FDD)................................................................................55
3.8 ALGUMAS COMPARAÇÕES ENTRE OS MÉTODOS ÁGEIS................................................................59
4 CONCLUSÃO......................................................................................................................63

REFERÊNCIAS......................................................................................................................65
 13

1 INTRODUÇÃO

Este trabalho é resultado de pesquisa bibliográfica de autores e pesquisadores que

têm publicado livros, dissertações e artigos científicos sobre o desenvolvimento ágil de
software. Entre esses autores, vale ressaltar Alistair Cockburn, Andrew Hunt, Barry Bohem,
Graig Larman, Jim Highsmith, Ken Schwaber, Kent Beck, Larry L. Constantine, Martin
Fowler, Pekka Abrahamson, Richard Turner, Robert L. Glass, Stephen Palmer e Ward
Cunningham. Veremos que o desenvolvimento ágil de software geralmente tem sido
conduzido por algum tipo de processo, ou método ágil. Segundo Aurélio Buarque de Holanda
Ferreira, em Novo Dicionário Aurélio – Século XXI, publicado pela Editora Nova Fronteira,
os significados do substantivo “método” e o adjetivo “ágil” são:
Ágil
[Do latim agile]
Adjetivo 2 g.
1. Que se move com destreza; destro, hábil, desenvolto.
2. Rápido, desembaraçado, ligeiro, veloz.
3. Ativo, expedito, diligente.

Método
[Do grego méthodos, ‘caminho para chegar a um fim’]
Substantivo masculino.
1. Caminho pelo qual se atinge um objetivo.
2. Programa que regula previamente uma série de operações que se devem realizar,
apontando erros evitáveis, em vista de um resultado determinado.
3. Processo ou técnica de ensino:
4. Modo de proceder; maneira de agir; meio.
5. Tratado elementar

Portanto podemos inferir que métodos ágeis devam prover processos, maneiras de
agir, para se alcançar o desenvolvimento rápido de software, de forma desembaraçada.
Conforme o Aurélio temos que:
Desembaraçado
[Part. de desembaraçar]
Adjetivo.
1. Isento ou livre de embaraços.
2. Ativo, diligente, expedito.
 14

3. Livre de acanhamento, de timidez; desinido.

Assim: “métodos ágeis fornecem processos e maneiras de agir para se alcançar o

desenvolvimento rápido de software, isento ou livre de embaraços para tal”. Partindo-se desta
hipótese, neste trabalho busca-se conhecer alguns métodos ágeis existentes atualmente, suas
características e fatores que possam contribuir para o desenvolvimento ágil de software. Esses
métodos geralmente possuem processos menos rígidos e um volume de documentação menor
que os métodos tradicionais, por isso costumam ser referenciados em algumas publicações
por métodos leves (lightweight). Ao contrário, métodos tradicionais, como é o caso do
Rational Unified Process (RUP), são chamados em algumas publicações de métodos pesados
(heavyweight) (LARMAN, 2003).
Os métodos tradicionais estão centradas em processos e costumam ser
especificados e construídos através de um meticuloso e extensivo plano, e têm o ciclo do
projeto guiado por tarefas ou atividades, como é o caso do RUP. Estão baseados na predição,
e funcionam bem se a concepção do software não sofre nenhuma alteração. Caso contrário, ao
perceber que uma definição não foi a mais acertada, costuma-se resistir às mudanças, o que
pode comprometer a evolução do desenvolvimento. Isso ocorre devido a alguns fatores que
dificultam a realização de especificações para o desenvolvimento de software que sejam
precisos para o futuro, pois conforme Graig Larman (LARMAN, 2003):
 Os clientes ou usuários não estão certos do que querem.
 Eles têm dificuldade para expressar tudo o que querem e pensam.
 Muitos detalhes do que eles querem somente serão revelados durante o
desenvolvimento.
 Os detalhes são geralmente complexos para pessoas.
 Quando eles vêem o desenvolvimento do produto, eles mudam seus
pensamentos.
 Forças externas, como produtos ou serviços de concorrentes, conduzem as
mudanças ou melhorias requeridas.
Os métodos ágeis, ou métodos leves, baseiam-se na adaptação às mudanças, pois
ao levar em consideração fatores como os citados acima, quanto mais se conhece sobre o
problema, melhores poderão ser as soluções encontradas. Os métodos ágeis estão mais
centrados na interação das pessoas envolvidas no desenvolvimento do software, como
desenvolvedores e representantes do cliente, e no compartilhamento de seus conhecimentos
(LARMAN, 2003).
 15

O que se percebe é que a indústria de software está otimista com relação aos
métodos ágeis, mas poucos dados estatísticos estão disponíveis, se comparados aos métodos
tradicionais. No entanto, não é objetivo desse trabalho induzir a utilização de métodos ágeis,
pois como disse Alistair Cockburn (COCKBURN, 2006; tradução nossa):
Um erro comum de um metodologista iniciante é acreditar que a última técnica que
ele acabou de aprender é a técnica mestre que todas as pessoas teriam que utilizar, [...]
há um número continuamente crescente de técnicas úteis no mundo, e portanto seria
de responsabilidade de cada profissional em sua especialidade aprender a usá-las. Não
faz nenhum sentido que o autor de uma metodologia a ser utilizada por um número
variado de pessoas e equipes em diferentes países, diferentes projetos, com diferentes
tecnologias deva legislar sobre qual funcionará melhor para essas pessoas e equipes,
isso é algo que cada pessoa e equipe deve pesquisar e decidir sobre.

Esse trabalho fornece uma visão geral dos métodos ágeis, que poderá servir de
base para uma pesquisa mais detalhada sobre cada método aqui apresentado, ou ter esse
trabalho como uma referência para a avaliação entre os métodos ágeis que mais se adequam
as necessidades e as características de uma organização. Por isso esse trabalho está dividido
da seguinte forma:
 O segundo capítulo fundamenta o que são as métodos ágeis.
 O terceiro capítulo fornece uma descrição dos métodos ágeis mais
utilizadas atualmente.
 O quarto capítulo traz a conclusão desse trabalho.
 16

2 OS MÉTODOS ÁGEIS

2.1 O Surgimento dos Métodos Ágeis

O surgimento dos métodos leves (leightweight) deu-se nos anos 90 quando os
métodos tradicionais (heavyweight) começaram a ser questionados, devido ao grande volume
de documentação que esses costumam gerar. Os métodos leves começaram a tomar força com
o Movimento Ágil, quando passaram a ser mais conhecidos por metologias ágeis (LARMAN,
2003). Um número crescente de organizações adotaram um ou mais métodos ágeis,
produzindo software com menos documentação, sob a condição de mudanças rápidas para a
satisfação dos clientes, mas outras organizações estão preocupadas com os riscos que podem
estar envolvidos com a redução do volume de documentação (BOHEM, 2003). No entanto a
rápida mudança da economia baseada na Internet demanda flexibilidade e velocidade dos
desenvolvedores de software, algo normalmente não associado com o desenvolvimento
tradicional, onde o problema das mudanças imprevistas é piorado pelos longos ciclos de
desenvolvimentos, que podem produzir códigos bem escritos, mas não atender as expectativas
dos usuários (BOHEM, 2003).

2.2 O Movimento Ágil

A indústria de software viu o movimento ágil ganhar espaço com a publicação do
Manifesto for Agile Software Development (Manifesto para o Desenvolvimento Ágil de
Software) em fevereiro de 2001, por um grupo composto por dezessete pessoas, entre
praticantes e consultores. Representantes do Extreme Programming (XP), Scrum, Dynamic
System Development Method (DSDM), Adaptive Software Development (ASD), Crystal,
Feature-Driven Development (FDD), Pragmatic Programming (PP), entre outros
simpatizantes da idéia de que precizavam encontrar uma alternativa aos processos conduzidos
por documentação, os quais possuem processos rígidos de desenvolvimento de software. Esse
grupo nomeou a si mesmos de The Agile Alliance, pois apesar de serem formados por um
grupo de pensadores independentes, e em algumas vezes competidores entre si, concordaram
com o título (CUNNINGHAM, 2007).
O grupo que elaborou o Manifesto foi composto pelas seguintes pessoas: Alistair
Cockburn, Andrew Hunt, Arie Van Bennekum, Brian Marick, Dave Thomas, James Grenning,
 17

Jeff Sutherland, Jim Highsmith, Jon Kern, Ken Schwaber, Kent Beck, Martin Fowler, Mike
Beedle, Robert C. Martin, Ron Jeffries, Stephen J. Mellor e Ward Cunningham.
Os valores defendidos por esse grupo são:
 Indivíduos e interações ao invés de processos e ferramentas.
 Software operacional ao invés de documentação compreensiva.
 Colaboração do cliente ao invés de negociação de contrato.
 Responder às mudanças ao invés do seguimento de um plano.

A partir desses valores eles criaram doze princípios nos quais estão embasados os
métodos ágeis:
1. Nossa mais alta prioridade é satisfazer o cliente entregando continuamente
e mais cedo software de valor.
2. As alterações de requisitos são benvindas, mesmo que mais tarde durante o
desenvolvimento. Pocessos ágeis aceitam as mudanças como uma
vantagem competitiva do cliente.
3. Entregar freqüentemente software operacional, em um par de semanas ou
um par de meses, com preferência por um período mais curto.
4. Pessoas de negócio e desenvolvedores devem trabalhar juntos diariamente
durante o projeto.
5. Construir projetos com indivíduos motivados. Dando a eles um ambiente e
apóio que eles necessitam, e confiando que eles concluirão o seu trabalho.
6. O método mais eficiente e efetivo de disseminar informação na equipe de
desenvolvimento está na conversação face-a-face.
7. Software operacional é a medida básica de progresso.
8. Projetos ágeis promovem desenvolvimento sustentável.
9. Os patrocinadores, fomentadores, e usuários deveriam manter um relativo
progresso, constante e indefinidamente.
10. Atenção continua para a excelência técnica e o bom desenho melhoram a
agilidade.
11. Simplicidade – a arte de maximizar a quantidade de trabalho realizado – é
essencial.
12. As melhores arquiteturas, requisitos, e desenhos emergem de uma equipe
auto-organizado.
 18

A intervalos regulares, a equipe reflete sobre como tornar-se mais efetivo, então
sintonizam e ajustam seu comportamento adequadamente.
Desta forma em cada iteração exige-se relativo esforço dedicado às diversas fases
do projeto – requisitos, desenho, implementação e teste - e ênfase nas mudanças. Métodos
ágeis são um subconjunto de métodos iterativos (LARMAN, 2003).
O desenvolvimento ágil de software requer inovação e responsabilidade, para
poder compartilhar os conhecimentos entre os integrantes da equipe de desenvolvimento e do
cliente, pois o que se objetiva é aproveitar o potencial dos clientes, usuários e
desenvolvedores, adotando um processo o suficiente para manter a qualidade e a agilidade.
(LARMAN, 2003).

2.3 O Método Iterativo Incremental de Desenvolvimento

O método Iterativo Incremental de Desenvolvimento (IID), é a essência de todos
os métodos ágeis, incluindo Scrum e XP. O IID baseia-se na construção de software através de
várias iterações durante o seu ciclo de vida. Cada iteração realiza um mini-projeto composto
por atividades como análise de requisitos, desenho, programação e teste. O objetivo de cada
iteração é a liberação de um um subconjunto do produto final de software, que seja estável,
integrado e testado, parcialmente é um sistema completo. A maioria das liberações são
internas, isto é, uma linha de base para controle da equipe de desenvolvimento. Somente ao
final de todas as iterações é que o produto estará completo, para ser liberado para o mercado
ou o cliente. Para métodos iterativos modernos a duração recomendada de um iteração está
entre uma a seis semanas. A qualidade é fator relevante, e deve ser considerada para o
software resultante em cada iteração, pois trata-se de um subconjunto do sistema final
(LARMAN, 2003).
Alistair Cockburn (COCKBURN, 2006) diz que um erro comum é assumir que
iterações muito curtas são geralmente boas. Uma iteração deveria, em teoria, permitir que:
 Os especialistas de negócio trabalhem nos detalhes das características a
serem construídas na iteração.
 Que os programadores possam programá-las.
 19

 Que os usuários, especialistas de negócio e testadores verifiquem se o que

foi construído está adequadamente correto, e discutir o que precisa ser
alterado.
 Os programadores alterem o software conforme o acordado.
 Que se repita os dois últimos passos acima até que os especialistas de
negócio, usuários, e patrocinadores tenham as características do software
prontas para entrega.
Pensamento linear, processos preditivos, unificados, e práticas invariáveis não
atendem a volatilidade dos ambientes de desenvolvimento de hoje, de maneiras que o
processo de desenvolvimento de software vêem mudando de antecipatórios para adaptativos.
Por isso, deve ser incorporado a mobilidade, experimentação, e velocidade no
desenvolvimento de software, e realizar várias iterações durante o ciclo de vida poderá
facilitar o processo de desenvolvimento (HIGHSMITH, 2004).
O planejamento das iterações deve ser conduzido pelos riscos do desenvolvimento
e pelas necessidades e prioridades do cliente. Quanto aos riscos, deve-se escolher os
elementos mais difíceis para serem realizados nas iterações iniciais. Enquanto o cliente é o
responsável por definir as características do que e o que se fará na próxima iteração. A
duração das iterações não precisam ser iguais, nem devem ser utilizadas para pressionar os
desenvolvedores a trabalhar longas horas por dia para cumprirem os compromissos até a data
final, mas uma iteração de três meses a seis meses é longa demais. O Scrum recomenda que
um iteração tenha trinta dias do calendário, mas a maioria dos métodos ágeis recomendam
entre uma semana a seis semanas (LARMAN, 2003).
Ambos os métodos IID e Ágil aceitam mudanças, mas não o caos, por isso que os
métodos IID estão comprometidos com a seguinte regra: uma vez que os requisitos para uma
iteração foram escolhidos e se está progredindo no mini-projeto, nenhum patrocinador externo
poderá alterar o trabalho (LARMAN, 2003).
Reflexão é um fator crítico de sucesso evolvendo uma metodologia de sucesso, da
mesma maneira que desenvolvimento incremental é um fator de crítico de sucesso para a
entrega software (COCKBURN, 2006).
 20

2.4 O Desenvolvimento Evolutivo

Os requisitos, planos, estimativas e soluções evoluem ou são refinados durante as
iterações, ao invés de completamente definidos e congelados para que num futuro se faça um
refinamento maior (LARMAN, 2003). As empresas necessitam obter resultados dos seus
esforços dedicados ao desenvolvimento de produtos, mas esses resultados não devem vir de
gastos com qualidade (HIGHSMITH, 2004).

2.5 O Desenvolvimento Adaptável

Os elementos se adaptam em resposta a avaliação do trabalho anterior realizado –
avaliação de usuários, desenvolvedores, testes, etc. O objetivo é semelhante ao
desenvolvimento evolutivo, mas sugere um mecanismo evolutivo de avaliação e resposta
(LARMAN, 2003).
Assim como os produtos precisam ser constantemente adaptados à realidade do
mercado, assim também ocorre com as pessoas e os processos. De fato, se nós queremos
produtos adaptáveis, nós primeiramente devemos construir uma equipe adaptável. Não
importa o quanto uma pessoa, equipe ou empresa possa prever o futuro, esse sempre será uma
surpresa para nós (HIGHSMITH, 2004).

2.6 O Desenvolvimento Ágil

Os métodos ágeis de desenvolvimento de software aplicam o desenvolvimento
iterativo e evolutivo, planejamento adaptável, promovendo entregas progressivas, além de
incluir outros valores e práticas que incentivam a agilidade – rápido e flexível em resposta às
mudanças (LARMAN, 2003). Segundo Aurélio Buarque de Holanda Ferreira, em Novo
Dicionário Aurélio – Século XXI, publicado pela Editora Nova Fronteira diz:
Agilidade
[Do latim agilitate]
Substantivo feminino.
1. Qualidade ou caráter de ágil.

Todo desafio em um mundo variável requer agilidade e disciplina. Isto é verdade

nos negócios, no desenvolvimento de software, nos esportes, etc. Jim Collins em seu livro
Good to Great apresenta uma escala bidimensional que descreve as características dos
negócios de sucesso. Uma dimensão é a disciplina, e a outra uma atitude empresarial, que em
 21

nosso contexto seria a agilidade. Se a pessoa tem disciplina forte, sem agilidade, o resultado é
burocracia e estagnação. Agilidade sem disciplina é o entusiasmo exacerbado de uma
companhia iniciante mesmo sem obter lucro. Grandes companhias têm ambos em medidas
apropriadas para as suas metas (BOEHM, 2003). Agilidade é mais uma atitude que processo,
mais ambiente que metodologia (HIGHSMITH, 2004).
Como os desenvolvimentos de software estão se tornando cada vez maiores e mais
complexos. O ambiente no qual o software é imaginado, especificado e criado está mudando.
Os aspectos de usabilidade e qualidade do software tornaram-se mais críticos. O tempo
necessário para liberação de um software para o mercado pode significar a diferença entre um
produto próspero ou falido (BOEHM, 2003).
Visando diminuir o tempo necessário para a liberação de um software, os métodos
ágeis são a conseqüencia da prototipação rápida e a experiência de desenvolvimento rápido,
como também o surgimento da filosofia que programar é uma arte ao invés de um processo
industrial (BOEHM, 2003).
A natureza da mudança rápida baseada na economia da Internet demanda
flexibilidade e velocidade por parte dos desenvolvedores de software, algo não usualmente
associado com o desenvolvimento conduzido por métodos tradicionais (BOEHM, 2003).
As mudanças ocorrem em quase tudo no software. Os requisitos mudam. Os
desenho muda. O negócio muda. A tecnologia muda. A equipe muda. Os membros da equipe
mudam. O problem não muda, porque a mudança irá acontecer; o problema, ao acontrário, é a
nossa inabilidade para tratar a mudança (BECK, 2004).
As práticas casadas para suportar esses valores variam de acordo ao método ágil
utilizado, mas geralmente baseiam-se em três áreas (BOEHM, 2003):
 Comunicação.
 Administração.
 Técnico.
Uma outra meta dos métodos ágeis é aceitar as mudanças. Se uma mudança é
determinada, como é na maioria dos projetos de desenvolvimento, então use de técnicas que
tirem proveito das mudanças. Se as exigências mudam rapidamente, tenha iterações curtas o
suficiente para atender as exigências atuais. Constantemente integre e faça testes de regressão.
Mantenha o cliente próximo e envolva-os nos processos de planejamento e validação.
Redesenhe quando necessário, mas não desenhe em demasia. Não desenvolva documentação
 22

para ser guardada. Concentre totalmente na iteração atual e entregue um produto que satisfaça
o cliente na hora certa (BOEHM, 2003).
Métodos ágeis em geral necessitam de relacionamento com o cliente e usuários do
software sob desenvolvimento. Os requisitos e a validação dependem da descrição do cliente,
priorização, e o refinamento de suas necessidades ao longo do desenvolvimento. O ciclo para
construir funcionalidade é altamente dependente de um cliente informado e envolvido. O
cliente também estabelece os critérios de aceitação e testes (BOEHM, 2003).
Os métodos ágeis exigem uma massa crítica de pessoas altamente motivadas e
instruídas. A documentação e o desenho são mantidos minimos (BOEHM, 2003).
A aceitação cultural dos métodos ágeis é também necessária para iniciar e manter
agilidade, mas há um ceticismo considerável em utilizar métodos ágeis no desenvolvimento
de grandes softwares, complexos ou de segurança crítica. Os métodos ágeis parecem ser a
melhor escolha para software menores. Embora haja grandes projetos documentados, a grande
maioria das experiências são de projetos relativamente pequenos, projetos de cinco a dez
pessoas. Pois em experiências com projetos ágeis utilizando-se cinquenta pessoas necessitam
que aspectos do processo de métodos tradicionais sejam integrados para se obter sucesso com
grandes projetos (BOEHM, 2003). Ao contrário dessa visão de Barry Bohem (BOEHM,
2003), veremos no capítulo 3 deste trabalho que métodos como o Crystal Clear aumentam a
cerimônia para que possam ser aplicáveis a grandes projetos (COCKBURN, 2006), assim
como o método XP tem sofrido adaptações para que possa ser aplicado a projetos maiores (
BECK, 2003).

2.7 Contrastes entre Métodos Ágeis e Métodos Tradicionais

O refinamento ininterrupto é o tema que vem sendo discutido para o
desenvolvimento sustentável de software. O desenvolvimento de software é complexo e tem
que evoluir continuamente através de um longo período de tempo, face as exigências dos
usuários, e um ecossistema composto por mercados, parceiros, tecnologias e concorrentes em
constante evolução. O que torna impossível ao início de um projeto é planejar todas as
mudanças exigidas. Portanto, as equipes têm que planejar-se para as mudanças e implementar
práticas que melhorem as suas habilidades para adaptarsem às mudanças. Essas práticas
devem cobrir como eles gerenciam os seus projetos, como projetam os seus produtos, e
também as práticas utilizadas para desenvolver os seus produtos. Para acomodar essas
mudanças, as equipes precisam do envolvimento do usuário e uma ênfase na reflexão,
 23

aprendizagem, e experimentação, mas também práticas desburocratizadas que possibilitem

manter o controle do progresso e dos riscos (TATE, 2005). Esses requisitos estão inseridos em
diferentes proporções nos métodos ágeis e tradicionais, e Barry Bohem e Richard Turner
contrastam esses métodos em BOEHM, 2003.
Neste trabalho os contrastes realizados a seguir estão baseados em BOHEM,
2003, pois alguns autores, que desenvolveram seus próprios métodos ágeis, podem não ser
imparciais como esperaríamos que fossem, e desse grupo cita-se aqui: Alistair Cockburn -
Crystal; Bob Charette – Lean Development (LD); James Highsmith – Adaptive Software
Development (ASD); Ken Schwaber e Jeff Sutherland - Scrum; Kent Beck – Extreme
Programming (XP); Jeff DeLuca e Peter Coad – Feature-Driven Development (FDD).
A grande variedade de métodos tornam a comparação entre métodos ágeis e os
métodos tradicionais muito difícil e imprecisa. O desenvolvimento de software depende de
vários fatores como (BOEHM, 2003):
 Características da aplicação:
o Metas básicas do projeto.
o Tamanho do projeto.
o Ambiente do projeto.
 Características da gestão:
o Relações com o cliente.
o Planejamento e controle.
o Comunicações no projeto.
 Características técnicas:
o Requisitos.
o Desenvolvimento.
o Testes.
 Características pessoais:
o Clientes.
o Desenvolvedores.
o Cultura.
 24

2.7.1 Metas Básicas do Projeto

As metas básicas de um método ágil são software pronto o mais rápido possível e
responsabilidade pela mudança. Métodos ágeis geralmente não analisam o retorno do
investimento (Return Of Investment – ROI) para determinar uma melhor alocação dos
recursos. Os métodos ágeis preferem entregar software rapidamente e aprender pelas
experiências, descobrindo quais as atividades e características adicionam maior valor
(BOEHM, 2003).
As metas básicas dos métodos tradicionais são preditivos, estáveis e de alta
garantia. Os planos, produtos funcionais, e estratégias de verificação e validação dos métodos
conduzidos por planos apoiam as metas básicas. A melhoria de processo foca na predição e a
estabilidade aumentando a capacidade do processo através da padronização, medição e
controle. A predição é baseada em medidas de atividades anteriores. O controle é realizado
quando o progresso atual estiver fora de tolerâncias esperadas (BOEHM, 2003).

2.7.2 Tamanho do Projeto

Atualmente os métodos ágeis parecem funcionar melhor para equipes pequenas ou
médias trabalhando em aplicações relativamente pequenas (BOEHM, 2003). O concenso geral
é que uma coordenação mais rígida e conhecimento compartilhado geralmente previne
equipes com mais de quarenta pessoas. No entanto tem havido alguns sucessos ocasionais
utilizando-se de métodos ágeis para equipes com mais de 250 pessoas. Um dos maiores
projetos que se tem conhecimento tinha mais de 800 desenvolvedores e utilizou Scrum. Um
projeto baseado em métodos ágeis precisam adotar planos tradicionais e especificações para
conseguirem tratar do aumento da complexidade e iterações multi-dimensionais entre os
elementos do projeto (BOEHM, 2003).
Métodos tradicionais conduzidos por planos lidam melhor com projetos grandes.
Os planos, documentação e processos provêem uma melhor comunicação e coordenação de
grandes equipes. Porém uma organização burocrática conduzida por planos que requeiram em
média uma pessoa-mês para obter um projeto autorizado e iniciado não será muito eficiente
em pequenos projetos (BOEHM, 2003).

2.7.3 Ambiente do Projeto

 25

Os métodos ágeis são mais aplicáveis a ambientes mais turbulentos e de muitas

mudanças, que tenham uma visão de que as organizações são um sistema complexo e
adaptativo, no qual requisitos surgem sem que possam ser previsíveis. Os métodos ágeis
concentram-se na entrega de um software específico, a tempo, que satisfaça completamente
um cliente. Desta forma geralmente o escopo foca-se no produto em mãos e geralmente
ignoram problemas que possam ocorrer mais tarde (BOEHM, 2003).
Os métodos tradicionais funcionam melhor quando os requisitos são amplamente
determináveis previamente (considerando-se prototipação) e permanecem relativamente
estáveis. A taxa de mudança dos requisitos de 1% (um porcento) ao mês é aceitável. Os
métodos conduzidos por planos também cobrem uma gama maior de atividades que os
métodos ágeis. Frequentemente adotados em desenvolvimentos de software contratados, eles
podem especificar as liberações, organizações, investimentos que ocorrem em múltiplos
projetos. Também antecipam (planejam para) as necessidades futuras através de uma
arquitetura e desenho expansível. Esses métodos desenvolvem capacitações em disciplinas
relacionadas como por exemplo engenharia de sistemas e fatores humanos e esperam impactar
um número abrangente de pessoas em diversos níveis na hierarquia organizacional, assim
como foca na melhoria quantitativa dos processos (BOEHM, 2003).

2.7.4 Relações com o Cliente

Os métodos ágeis dependem consideravelmente de que representantes do cliente
estejam dedicados e alocados junto da equipe de desenvolvimento para que se consiga obter
valores para a organização. O cliente representa e deve estar em sincronia com os usuários do
sistema e a equipe de desenvolvimento. O cliente e a equipe de desenvolvimento tratam dos
problemas previsíveis os resolvendo com antecedência e formalizando as soluções em um
acordo documentado. As vantagens são que a equipe de desenvolvimento sabe o que ela tem
que fazer. Os clientes sabem o que eles estão adquirindo. Isso mantém seu conhecimento
operacional e aumenta a sua eficiência ao exercitar protótipos ou rever os planos de progresso
do projeto (BOEHM, 2003).
O contrato torna a interface entre o desenvolvedor e o cliente o ponto mais crítico
para os métodos conduzidos por processo. Um contrato mais detalhado causa um atraso no
início e é mais difícil adaptar-se às mudanças. Enquanto um contrato impreciso pode criar
expectativas incompatíveis, levando a uma relação díficil e sem confiança entre o
desenvolvedor e o cliente. O peor caso é quando passa-se a disputa judicial. Para o projeto ter
 26

sucesso o patrocinador deve acreditar que a organização de desenvolvimento irá realizar o

trabalho necessário com os recursos disponíveis e acordados para tal (BOEHM, 2003).
Os métodos ágeis incentivam a participação do cliente para que haja confiança em
seus registros, os software(s) que desenvolvem e a experiência de seus profissionais, e por
isso tem sido mais usado em desenvolvimentos por equipes internas da organização
(BOEHM, 2003).
As pessoas dos métodos tradicionais confiam em seu processo de maturidade para
promover a confiança em seus trabalhos, mas não se deve assumir que um plano documentado
seja a garantia de que o projeto o seguirá (BOEHM, 2003).

2.7.5 Planejamento e Controle

Agilistas estimam que seus projetos demandam aproximadamente 20% (vinte
porcento) do seu tempo planejando e replanejando. A velocidade dos projetos ágeis e a
agilidade vêm em grande parte dos esforços de planejamento do grupo, baseado no
conhecimento compartilhado ao invés de conhecimento documentado como os representados
por planos e especificações. Quando mudanças imprevistas ocorrem, os colaboradores da
equipe podem compartilhar a visão dos objetivos do projeto e a sua compreensão do software
para desenvolver rapidamente e implementar a solução revisada. Porém assim que o projeto
cresce isso pode tornar-se mais difícil. (BOEHM, 2003).
Métodos tradicionais utilizam-se de planos para ancorar os seus processos e
prover uma comunicação mais abrangente. Os planos compõem uma grande porção da
documentação nesses métodos. Os métodos tradicionais confiam em uma abrangente
documentação e um amplo planejamento do produto para manter todos coordenados. Planos
individuais são frequentemente produzidos para atividades específicas e então são integrados
no “plano mestre”. Um esforço considerável é gasto para manter os dados históricos. O plano
é criado e ajustado constantemente. Os planos tornam explícitos as expectativas e os
relacionamentos entre os vários esforços do projeto (BOEHM, 2003).

2.7.6 Comunicação no Projeto

Os métodos ágeis dependem consideravelmente dos conhecimentos interpessoais
para os seus sucessos. Os métodos ágeis geralmente exigem comunicações mais frequentes e
bilaterarais de pessoa para pessoa, face-a-face. Poucas comunicações nos métodos ágeis são
 27

unilaterais, havendo uma preferência pela colaboração, o que facilita a disseminação do

conhecimento. Os métodos ágeis empregam documentação, mas eles enfatizam em criar o
mínimo essencial (BOEHM, 2003).
Nos métodos tradicionais as comunicações tendem ser unilaterais. As
comunicações são geralmente de uma entidade para outra, ao invés de entre duas entidades. O
conhecimento ao invés de ser compartilhado é normalmente documentado. Infelizmente o
volume de documentação é reforçada pela maioria dos regulamentos de aquisição de software
do governo (BOEHM, 2003).

2.7.7 Requisitos
A maioria dos métodos ágeis expressam os requisitos como ajustáveis e histórias
informais. Os métodos ágeis contam com seus ciclos rápidos de iterações para determinar as
necessidades de mudanças nas funcionalidades desejáveis e para corrigí-los na próxima
iteração. A determinação do conjunto de requisitos de mais alta prioridade a serem incluídos
na próxima iteração é feito de forma colaborativa entre os clientes e os desenvolvedores
(BOEHM, 2003).
Os métodos tradicionais geralmente preferem as especificações formais,
completas, consistentes e testáveis. Esses métodos geralmente têm sido muito mais lentos que
os métodos ágeis para assimilar novos conceitos como requisitos priorizados e a evolução
desses (BOEHM, 2003).

2.7.8 Desenvolvimento
A diferença primária entre práticas de desenvolvimento ágil e conduzidos por
processos estão entre o desenho e a arquitetura do software. Os métodos ágeis defendem o
desenho simples, onde a funcionalidade é implementada. Agilistas encorajam o desenvolvedor
a fazer um desenho mais simples, em toda oportunidade. Isto significa que se o desenho tem
funcionalidades que estão além das necessidades atuais do cliente ou que as antecipam,
dever-se-á gastar esforço extra para removê-las (BOEHM, 2003).
Os métodos tradicionais utilizam o planejamento e o desenho baseado em
arquitetura para acomodar mudanças previsíveis. Este esforço permite aos desenhistas
organizar o sistema de tal forma a tirar vantagem do re-uso de software através de uma linha
de produtos o que pode ter um maior impacto no desenvolvimento rápido (BOEHM, 2003).
 28

Enquanto o desenho simples e o desenho arquitetural são conflitantes, existem

algumas práticas de desenvolvimento ágil que podem rapidamente ser adotados pelos projetos
conduzidos por processos (BOEHM, 2003).

2.7.9 Testes
Os testes são uma forma de validação que os clientes têm especificado o produto
certo e que os desenvolvedores têm construído o produto certo. Isso requer que o código seja
desenvolvido e executado, o qual significa que para longos desenvolvimentos, problemas
serão descobertos mais tarde no ciclo de desenvolvimento, quando são caros para serem
corrigidos. Métodos ágeis tratam desse problema organizando o desenvolvimento em
pequenos incrementos, e aplicando programação em pares (no caso do XP) ou outras técnicas
de revisão para remover defeitos de código assim que são gerados. Os métodos ágeis também
desenvolvem testes executáveis para realizar testes de regressão. Testes automatizados são
recomendados pela maioria dos métodos ágeis (BOEHM, 2003).
Métodos tradicionais tratam de corrigir os problemas de desenvolvimento mais
tarde, e a verificação de consistência de requisitos e as especificações de requisitos o mais
cedo no processo de desenvolvimento. Esses métodos também investem em testes
automatizados planejando e preparando a execução dos testes. Isso cria muita documentação
que pode ficar desatualizada pela mudança dos requisitos. Os testes realizados mais tarde
perdem muitas vantagens em relação aos testes realizados mais cedo, como acontece nos
métodos ágeis (BOEHM, 2003).

2.7.10 Clientes
As maiores diferenças entre os métodos ágeis e os conduzidos por planos está em
que o primeiro enfatiza fortemente ter os representantes do cliente dedicados e alocados no
projeto, enquanto os métodos conduzidos por processos conta com acordos, onde o
desenvolvedor trabalhará baseado no plano contratual e as especificações. O risco para os
métodos ágeis é que seja alocado um representante do cliente que esteja mais disponível ao
invés do mais indicado, por isso é necessário estabelecer critérios para tal (BOEHM, 2003).
Os métodos tradicionais, conduzidos por processos, também necessitam de
representantes de cliente, e beneficiam-se também de suas participações em tempo integral e
em loco. O maior desafio para o cliente é manter o controle de falhas em suas mãos para
 29

evitar que gerentes de contratos burocráticos priorizem as cláusulas do contrato em

detrimento da obtenção de resultados do projeto (BOEHM, 2003).

2.7.11 Desenvolvedores
Fatores críticos para o sucesso dos projetos que utilizam métodos ágeis incluem a
amizade, talento, habilidade e comunicação. Os métodos ágeis e os tradicionais operam
melhores com uma mistura de habilidades e entendimento dos desenvolvedores, mas os
métodos ágeis precisam de uma predominância de pessoas altamente qualificadas (BOEHM,
2003).
Pesado

Metodologia Ágil Típica

Adaptação
(Habilidade, Entendimento)
Metodologia Rigorosa

Leve
Leve Pesado
Aperfeiçoamento
(Processo, Documentação)

FIG. 1 – Equilíbrio entre aperfeiçoamento e adaptação (de Cockburn e Highsmith)

2.7.12 Cultura
Em uma cultura ágil as pessoas se sentem confortável e motivadas quando há
muitos degraus de liberdade disponíveis para eles definirem e trabalharem nos problemas.
Onde confia-se em cada pessoa e no trabalho que têm a fazer para o sucesso do projeto. Isso
inclui uma procura for tarefas comuns ou não notadas, para completá-las (BOEHM, 2003).
Na cultura conduzida por planos, as pessoas sentem-se confortáveis e motivadas
quando houver políticas e procedimentos que definem o papel deles no empreendimento. Isso
é mais que um ambiente de produção em série onde as tarefas de cada pessoa são bem
definidas. A expectativa é que eles realizarão as tarefas conforme as especificacões, de forma
 30

que os produtos do trabalho deles serão integrados facilmente a outros, mesmo tendo um
conhecimento limitado do que os outros estão fazendo (BOEHM, 2003).
 31

3 UM COMPARATIVO ENTRE DIVERSOS MÉTODOS

3.1 Scrum
Scrum foi desenvolvido por Ken Schwaber e Jeff Sutherland (SCHWABER, 2002).
Scrum está baseado no conceito de que o desenvolvimento de software não é um processo
definido, mas um processo impírico com transformações complexas de entrada/saída que
pode ou não ser repetido em diferentes circunstâncias (BOEHM, 2003). Este processo resulta
em flexibilidade, adaptabilidade e produtividade. Scrum não define qualquer técnica de
desenvolvimento de software para a fase de implementação. Scrum concentra em como os
membros da equipe deveriam atuar em ordem para produzir sistemas flexíveis em uma
ambiente de constantes mudanças (ABRAHAMSON, 2002).
O Scrum oferece um meio de introduzir os métodos ágeis no ambiente de
disciplinas dos métodos tradicionais. Utilizando o Scrum para um ou mais componentes do
sistema, a gestão pode alcançar a sua efetividade sem alterar completamente a forma que a
organização normalmente realiza negócios. Scrum tem sido um dos poucos métodos ágeis que
tem sido empregado em projetos maiores. Isso tem sido realizado da mesma forma que
empresas integram equipes de produtos. Uma equipe individual do Scrum faz parte de uma
equipe de escalão mais alto de líderes que cuidam de vários produtos. Mantendo a
comunicação e prevenindo conflitos de desenvolvimento é controlado através da equipe de
coordenação (BOHEM, 2003).
O Scrum enfatiza o gerenciamento de projeto, que é feito pelo Scrum Master
(Scrum Mestre). O seu ciclo de desenvolvimento é de 30 dias, chamado Sprint, o qual é
precedido por uma atividade pre-Sprint (pré-Srpint) e outra atividade post-Sprint (pós-Sprint).
Um reunião diária com duração inferior a 30 minutos (geralmente 15 minutos) permite à
equipe monitorar problemas de estado do projeto e de comunicação. A principal idéia do
Scrum é que os sistemas de desenvolvimento envolvem diversos ambientes e variáveis
técnicas (por exemplo requisitos, prazos, recursos e tecnologias) que podem mudar durante o
processo. Isto torna o processo de desenvolvimento imprevisível e complexo, exigindo
flexibilidade dos processos de desenvolvimento de software para que sejam capazes de
responder às mudanças. Como resultado do processo de desenvolvimento, um software
produzido é útil quando entregue (ABRAHAMSON, 2002).
 32

O planejamento do projeto é baseado no Product Backlog, o qual contém

melhorias de funções e tecnologias imaginadas para o projeto. São feitas duas reuniões – uma
para decidir as melhorias para o próximo Sprint e uma outra para planejar as atividades. Um
Sprint Goal (Meta do Sprint) é estabelecida, a qual serve com um critério mínimo para o
Sprint e as ações para manter a equipe focada no objetivo como um todo, ao invés de focado
somente nas atividades sob sua responsabilidade (ABRAHAMSON, 2002).
O processo do Scrum inclui três fases: pre-game, development e post-game
(ABRAHAMSON, 2002).
A fase pre-game inclui duas sub-fases: Planejamento e Arquitetura/Desenho de
Alto Nível. O Planejamento inclui a definição do software que está sendo desenvolvido. Uma
lista do Product Backlog é criado, contendo os requisitos que são atualmente conhecidos. A
lista do Product Backlog é constantemente atualizada, com items novos ou adicionais,
estimativas mais precisas e novas prioridades. O Planejamento também inclui a definição da
equipe do projeto, ferramentas e outros recursos, riscos e aspectos de controle, necessidades
de treinamentos e gestão de verificação/aprovação. Em toda iteração, o Backlog do produto é
revisado pelo Scrum Team(s) de maneira a obter o compromisso deles para a próxima iteração
(ABRAHAMSON, 2002).
A fase development (também chamada de game phase) é a parte ágil do Scrum.
Esta fase é tratada como uma caixa-preta onde o imprevisível é esperado. As diferenças de
ambiente e as variáveis técnicas (como prazo, qualidade, requisitos, recursos, implementações
tecnológicas, ferramentas e mesmo os métodos de desenvolvimento) identificados no Scrum
são observados e controlados através de várias práticas do Scrum durante os Sprints
(ABRAHAMSON, 2002).
A fase post-game contém o fechamento da liberação do software. Atinge-se essa
fase quando certifica-se que as variáveis de ambientes como os requisitos foram completados.
Neste caso, não se aceita nenhuma melhoria nova ou adicional. O software está pronto para
ser liberado e a preparação para isso é feita, incluindo atividades como integração, testes e
documentação (ABRAHAMSON, 2002).
Scrum introduz os métodos ágeis em um abiente tradicionalmente disciplinado.
Utilizando-se Scrum o gerenciamento pode alcançar a sua efetividade sem alterar
completamente a forma como a organização realiza os seus negócios (BOEHM, 2003).
Scrum é um dos poucos métodos ágeis que tem alcançado progresso com projetos
maiores, da mesma forma como as organizações têm mantido equipes de produtos integradas.
O treinador individual de uma equipe Scrum faz parte de uma equipe de escalão maior que
 33

abrange vários outros produtos. A manutenção da comunicação e a prevenção de conflitos de

desenvolvimento são controlados por está equipe coordenada (BOEHM, 2003).

3.2 Adaptative Software Development (ASD)

ASD foi desenvolvido por James Highsmith. Muitos dos princípios do ASD estão
baseados nas pesquisas do Highsmith sobre métodos iterativos de desenvolvimento. O seu
antecessor é o RADical Software Development (ABRAHAMSON, 2002).
ASD foca principalmente nos problemas em desenvolvimentos complexos e
extensos. O método incentiva o desenvolvimento iterativo incremental (IID), com constante
prototipação. Fundamentalmente o objetivo do ASD é proporcionar um ferramental que
oriente os projetos para prevenir falhas que possam tornar-se em caos, sem suprimir a
emergência e a criatividade (ABRAHAMSON, 2002).
ASD não possui muitos detalhes de como as coisas são feitas, pois somente esboça
as oportunidades que a equipe de desenvolvimento tem que levar em conta. ASD e a sua
filosofia não colaborativa e não prescritiva podem dificultar o seu emprego em
desenvolvimentos grandes, críticos e relativamente estáveis (BOEHM, 2003).
Um projeto ASD é levado a cabo em ciclos de três-fases. Essas fases são:
Speculate (Especular), Collaborate (Colaborar) e Learn (Aprender). Esses ciclos dinâmicos
fornecem um contínuo ciclo de aprendizado e adaptação à fase do projeto. As características
do ciclo de vida do ASD é que esse está focado na missão, baseado na característica, iterativo,
conduzido por riscos e tolerante às mudanças (BOEHM, 2003). Speculate é utilizado ao invés
de Planejamento. Collaborate enfatiza a importância da equipe desenvolver software
altamente alteráveis. Learn realça a necessidade de reconhecer e reagir aos erros, e o fato que
requisitos também podem mudar durante o desenvolvimento (ABRAHAMSON, 2002).
O ASD é explicitamente orientado a componentes ao contrário de orientado a
tarefas. Isso significa que o foco está mais em seus resultados e qualidades que em tarefas e
processos usados para produzir o resultado. A forma que o ASD conduz isso é através dos
clicos de desenvolvimento adaptativo que contém a fase Collaborate, onde muitos
componentes podem estar sob desenvolvimento simultâneo. Planejamento dos cliclos é parte
do processo iterativo, como as definições dos componentes são continuamente refinados para
refletir alguma nova informação, e para suprir as mudanças nos requisitos dos componentes
(ABRAHAMSON, 2002).
 34

Bases para ciclos posteriores são obtidos das revisões repetitivas de qualidade, as
quais focam na demonstração de funcionalidade do software desenvolvido durante o ciclo.
Um importante fator das revisões é a presença do cliente, com um grupo de peritos, chamado
de customer focus-group (group focado no cliente). Porém, as revisões de qualidade são
escassaz, pois somente acontecem ao final de cada ciclo. A participação do cliente geralmente
se faz através de seções de joint application development (JAD), que é essencialmente um
workshop, onde desenvolvedores e representantes do cliente reunem-se para discutir as
características do produto desejado, e para melhorar a comunicação. ASD não propõe uma
agenda para as seções de JAD, mas ressalta a importância de que aconteça no início do
projeto (ABRAHAMSON, 2002).

3.3 Lean Development (LD)

O metodologia Lean Development foi desenvolvido por Bob Charette. Evoluiu
baseada em sua experiência na administração de riscos, princípios e visão dos conceitos
industriais magros de Womack, Jones, e Roos1. Ele entende a agilidade como tolerância a
mudança. Um conceito chave para tal é o “risk entrepreneuringship”, que define a habilidade
de transformar um risco em oportunidade (BOEHM, 2003).
O LD é derivado dos princípios de produção enxuta, a qual reestruturou a indústria
de automóveis no início de 1980. Em LD, Bob estende a tradicional visão de mudança como
um risco a ser controlado com práticas de gestão restritiva para uma visão de mudança como a
produção de “oportunidades” através de um empreendimento de risco. Ele vê o LD como um
veículo de implementação para construir organizações tolerantes às mudanças (HIGHSMITH,
2002).
O LD é constituído de três fases: startup (inicial), steady state (estado fixo) e
transition-renewal (transição-renovação). O LD adiciona a dimensão de domínio ou linha de
produtos, onde o software pode ser reutilizado em vários modelos de produtos genéricos. O
planejamento é realizado na fase inicial (startup), onde os casos de negócio e estudos de
viabilidade são completados. Steady state é a fase da concepção de desenho do software
composto de uma série de pequenos ciclos de desenvolvimento em espiral2. Uma vez

1
WOMACK, J.; JONES, D.; ROOS, D. The Machine That Changed the World : The Story of Lean Production.
New York: HarperCollins, 1991.
2
No ciclo de desenvolvimento em espiral o produto é desenvolvido em uma série de iterações. Cada nova
iteração corresponde a uma volta na espiral. Isso permite construir produtos em prazos curtos, com novas
características e recursos que são agregados à medida que a experiência descobre sua necessidade [FIL03, p. 12].
 35

entregue, o produto é mantido em uma constante fase de renovação e transição. A

documentação é desenvolvida e entregue na fase de transição (BOEHM, 2003).
Highsmith tem dito que LD representa o primeiro dos métodos ágeis a atingir os
alto executivos. As idéias baseadas em estratégicas, riscos e oportunidades ressoam com os
executivos e a administração. No entanto, o LD é um produto proprietário, da empresa de
Charette, ITABHI, o que pode dificultar a sua adoção, pois incorpora muitas das suas
características, mesmo assim, esse é um dos métodos mais focados em avaliar e alcançar valor
empresarial (BOEHM, 2003).

3.4 Crystal
Alistair diz que escolheu construir uma família de metodologias, junto com
princípios, para serem ajustados às necessidades. Crystal não é um kit de metodologia para
você ajuntar por conta própria, mais um conjunto de exemplos que você ajusta às suas
circunstâncias. Crystal é o nome de uma família de metodologias, e como os cristais, possui
diferentes cores e rigidez, referindo-se ao tamanho e ao nível crítico do projeto (COCKBURN,
2006).
As idéias básicas do Crystal incluem princípios que definem as metodologias que
preenchem os requisitos variáveis dos diferentes projetos (ABRAHAMSON, 2002). Essa
família é composta por membros que são alocados conforme as necessidades dos projetos:
Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, etc
(COCKBURN, 2006). Cada membro da família Crystal é identificado por uma cor –
transparente (Clear), amarelo (Yellow), alaranjado (Orange), vermelho (Red), etc - que indica
o tamanho do projeto e a metodologia que será utilizada, quanto mais escura a cor mais
rigorosa será a metodologia (ABRAHAMSON, 2002).
Crystal sugere que a escolha da cor da metodologia seja feita conforme o tamanho
e o nível crítico do projeto. Grandes projetos geralmente requisitam mais coordenação e
metodologias mais rígidas que projetos menores. Quanto mais crítico for o software que está
sendo desenvolvido, mais rigor será necessário (ABRAHAMSON, 2002). Além das cores, o
Crystal utiliza-se de algumas letras para representar potenciais perdas causados por uma falha
no sistema de desenvolvimento de software:
 ‘C’ de Confort (Conforto) - indica que o sistema falha devido a defeitos
causados por uma perda de credibilidade do usuário, assim como um
 36

defeito em um sistema crítico para a vida pode literalmente causar a perda

da vida.
 ‘D’ de Discretionary money (dinheiro disponível para uso conforme
necessário, cujo uso depende de decisão de alguém com poder de decisão).
 ‘E’ de Essencial money (dinheiro essêncial – dinheiro indispensável,
absolutamente necessário).
 ‘L’ de Life (vida).

A Figura 2 representa essas características. As cores representam os tipos de

projetos.

L6 L20 L40 L40

E6 E20 E40 E80

D6 D20 D40 D80

C6 C20 C40 C80

Orange Red
Yellow
Clear

FIG. 2 – As metodologias do Crystal são nomeadas por cores (em inglês)

Na Figura 2, movendo-se para a direita na grade significa coordenar mais pessoas,

os quais requerem uma metodologia mais rígida. Utilizando a metáfora do Crystal, movendo
para a direita corresponde a escolher uma cor mais escura (quartzo transparente, topaz, rubi,
safira) (COCKBURN, 2006).
Na Figura 2, movendo-se para cima na grade corresponde a uma maior
possibilidade de danos ao sistema e o uso de mais rigor e cerimônia. Utilizando-se a metáfora
do Crystal, movendo-se para cima incrementa-se a dureza (em escala de dureza mineral, o
diamante é a mais dura gema, recebe número de dureza 10 - máxima) (COCKBURN, 2006).
Observe que o quadro referente a E6 na Figura 2 está pontilhado, pois o Crystal
Clear não trata dos aspectos relacionados a projetos onde o dinheiro é essencial, mas a equipe
poderá extender o Crystal Clear para isso (COCKBURN, 2006).
 37

Foi também omitido os sistemas de vida-crítica (Life-critical) porque Alistair

Cockburn diz não ter trabalhado nisso ou entrevistado pessoas sobre projetos de vida crítica,
de maneiras que ele não possui informação suficiente para dizer exatamente como um projeto
ágil de vida crítica se parece (COCKBURN, 2006).
Há certas regras, características e valores que são comuns para todos os métodos
da família Crystal. O primeiro de todos é que os projetos sempre utilizam-se de IID com um
ciclo máximo de desenvolvimento de quatro meses, mas preferivelmente entre um a três
meses. A ênfase é a comunicação e a cooperação entre as pessoas. As metodologias do
Crystal não limitam a qualquer prática de desenvolvimento, ferramentas ou tipos de produtos
(software), o qual permite também a adoção de, por exemplo, práticas do XP e Scrum
(ABRAHAMSON, 2002).
Uma restrição das metodologias do Crystal é que elas atendem somente a equipes
situadas em um mesmo local (COCKBURN, 2006).
A filosofia principal do Crystal é que o desenvolvimento de software é usualmente
visto como uma iteração de invenção e comunicação, com um objetivo primário de liberações
de software úteis que funcionem, e um objetivo secundário de preparar a próxima iteração
(COCKBURN, 2006).
Membros da família Crystal compartilham :
 Valores e princípios.
 Afinação (ajuste) rápida.

O dois valores são que as metodologias do Crystal são intrinsicamente:

 Centrado nas pessoas e na comunicação.
 Altamente tolerante.

Isso significa que as ferramentas, software funcionais e processos existem para

suportar os componentes humanos. Enquanto reconhece-se a existência de culturas variadas
(COCKBURN, 2006).
Dentro da tolerância da família Crystal a equipe pode escolher trabalhar com um
alto nível de cerimônia ou alta disciplina (adotando partes de PSP ou XP, por exemplo)
(COCKBURN, 2006).
Alguns princípios das metodologias do Crystal são (COCKBURN, 2006):
 38

 A equipe pode reduzir o tamanho dos software(s) intermediários e com isto

produzir códigos executáveis mais frenquentemente e com isto utilizar
melhores canais de comunicação entre as pessoas.
 Porque todo projeto é diferente e evolui com o passar do tempo, o conjunto
de convenções que a equipe adota também deve ser amoldado e também
tem que evoluir.
 O deslocamento dos gargalos no sistema determinam o uso de trabalho
sobreposto e mantenedores de informações insistentes.

Duas regras comuns à família do Crystal são (COCKBURN, 2006):

 O projeto deve utilizar desenvolvimento IID, com incrementos de quatro
meses ou menos (e uma forte preferência seria de um a três meses).
 A equipe deve realizar reuniões de pré e pós reflexões a cada IID (com
maior preferência por relizar também reflexões na metade).

As duas técnicas básicas em Crystal são (COCKBURN, 2006):

 Utilizar técnicas para afinação da metodologia: fazendo entrevistas de
projeto e um seminário da equipe para converter uma metodologia básica a
uma metodologia própria para o projeto.
 Utilizar técnicas para suportar seminários de reflexão.

Alistair Cockburn diz que as duas técnicas podem ser substituícas, caso se tenha
uma outra alternativa para alcançar esses objetivos (COCKBURN, 2006).

3.4.1 Crystal Clear

Crystal Clear é uma metodologia para projetos de categoria-D6. Seria possível
extender o Crystal Clear para projetos de categorias E8 ou D10 com alguma atenção para a
comunicação e testes, respectivamente, mas seria difícil extendê-lo além disso, porque
Crystal Clear não contém estrutura de comunicação para mais pessoas que possa
convenientemente trabalhar em uma mesma sala, e nisso falta os elementos de validação
necessários para vida-crítica do sistema (COCKBURN, 2006).
 39

No Crystal Clear há somente uma equipe trabalhando em uma mesma sala ou

salas adjacentes (COCKBURN, 2006).
Os papéis que exigem pessoas separadas são:
 Patrocinador.
 Desenhista-programador sênior.
 Desenhista-programadores.
 Usuário (pelo menos em tempo parcial).

Uma dessas pessoas deverá assumir o papel de coordenador do projeto. Alguém

deve ser o especialista do negócio, e qualquer um dos dois, ou várias pessoas, compartilharão
o papel de cobrador dos requisitos.
O Desenhista-programador sênior é a pessoa chave da equipe. O outros
Desenhistas-programadores podem incluir iniciantes e nível médio, dependendo do que o
Desenhista-programador sênior e o problema podem suportar. Portanto contratar pessoas
experientes ajudará.
A política de padrões são (COCKBURN, 2006):
 O software é entregue incrementalmente e regularmente, a cada dois ou
três meses.
 O progresso é medido por marcos que consistem em entregas de software
ou maiores decisões, ao invés de documentos escritos.
 Há alguma quantia de testes de regressão automatizados que testarão as
funções da aplicação.
 Há duas revisões do usuário por liberação de software funcional.
 Atividades Downstream iniciam-se assim que as Upstream estejam
estáveis para serem revisadas.
 Os seminários de afinação do produto e metodologia acontecem no início e
na metade de cada iteração.
Os padrões de política são obrigatórios, mas substituições equivalentes são
permitidas, como seria o caso se o horário de trabalho do Scrum, XP ou as políticas do ASD
fossem usadas (COCKBURN, 2006).
Os produtos de cada iteração que são produzidos incluem:
 Liberação em seqüência.
 Agendamento das revisões dos usuários ou entregas.
 40

 Casos de uso anotados ou descrições de características.

 Esboços de desenhos e notas como necessário.
 Rascunhos das telas.
 Um modelo de objeto comum.
 Código executável.
 Código de migração.
 Casos de teste.
 Manual do usuário.

Os seguintes são deixados para serem mantidos pela equipe:

 Modelos para o produto funcional.
 Padrões de códigos e interface de usuário.
 Padrões e detalhes de testes de regressão.

O Crystal Clear requisita que a documentação do projeto seja criada. Do que

consiste a documentação não é detalhado pelo Crystal. Essa é uma decisão da equipe. A
equipe deve decidir como será apresentado as notas do desenho para os futuros membros da
equipe (COCKBURN, 2006).
As ferramentas mais importante que a equipe pode possuir, além de um
compilador, são esses (COCKBURN, 2006):
 Sistema de gestão de versão e configuração.
 Um ou vários quadros brancos.

Substituição de elementos por outras metodologias semelhantes é permitido. Por

exempo, a equipe poderia dicidir utilizar as iterações do Scrum ou do DSDM e políticas
dinâmicas de priorização, as reuniões em pé e diárias do Scrum, programação em par do XP,
etc (COCKBURN, 2006).
Crystal Clear é a metodologia mais tolerante, de baixa cerimônia, e para equipes
pequenas (COCKBURN, 2006).
 41

3.4.2 Crystal Orange

Crystal Orange é uma metodologia para projetos de categoria-D40: projetos com
até 40 pessoas, alocadas em um mesmo edifício, tralhando no desenvolvimento de um
software que possa causar perda de dinheiro discricionário (COCKBURN, 2006).
Crystal Orange demanda mais estrutura de equipe e mais coordenação da equipe
do que é necessário para um projeto de 20 pessoas, mas não possui estruturas de sub-equipes
que são necessárias para um projeto de 80 pessoas, e não possui as atividades de verificação
de desenho e código que seriam necessários para sistemas de vida-crítica (life-critical)
(COCKBURN, 2006).
O Crystal Orange tem sido caracterizado como útil para projeto de produção
média em uma instalação industrial, e as características desses projetos são (COCKBURN,
2006):
 10 a 40 pessoas.
 1 a 2 anos de duração.
 O tempo para o mecado é importante.
 Há necessidade de comunicação com o pessoal atual e futuro da equipe, e
uma necessidade em manter o tempo e o custo baixos.
 Sistemas que não são de vida-crítica (life-critical).

Para um projeto do tipo E50 deve-se extender o Crystal Orange com alguns
elementos de verificações adicionais dos testes ao invés de mover-se para o Crystal Red que
destina-se a projetos com 80 pessoas (COCKBURN, 2006):
Os papéis que exigem pessoas separadas são (COCKBURN, 2006):
 Patrocinador.
 Especialista de negócio.
 Especialista de uso.
 Facilitador técnico.
 Analista/desenhista de negócio.
 Gerente de projetos.
 Arquiteto.
 Mentor de desenho.
 Líder desenhista-programador.
 42

 Outros desenhistas-programadores.
 Desenhista de interface de usuário.
 Reuse point.
 Escritor.
 Testador.

Eles são organizados em muitas equipes (COCKBURN, 2006):

 Planejamento de sistema.
 Monitoramento de projeto.
 Arquitetura.
 Tecnologia.
 Funções.
 Infra-estrutura.
 Testes externos.

Os produtos de cada iteração que são produzidos incluem (COCKBURN, 2006):

 Documentação de requisitos.
 Sequencia de liberações.
 Agenda.
 Relatórios de estados.
 Documento de desenho da interface do usuário.
 Modelos comuns de objetos.
 Especificações entre equipes.
 Manual do usuário.
 Código fonte.
 Casos de testes.
 Código de migração.

Os padrões de políticas são identicas ao Crystal Clear, exceto que o período das
iterações pode ser extendido para três ou quatro meses. E como no Crystal Clear as políticas
padrões são obrigatórias, mas substituição equivalente é permitida (COCKBURN, 2006).
 43

Modelos de produtos funcionais, estilos de códigos, interfaces padrão de usuários,

e detalhes de testes de regressão são deixados como padrões locais para serem criados e
mantidos pela equipe (COCKBURN, 2006).

3.5 Extreme Programming (XP)

XP é um método bem conhecido; que enfatiza a colaboração, criação rápida de
software e iteração mais cedo, e práticas hábeis de desenvolvimento de software. Ele está
fundamentado em quatro valores (LARMAN, 2003):
1. Comunicação: para o XP os problemas de comunicação prejudicam a
maioria dos projetos. A comunicação entre programadores é promovido
através da programação em pares, reuniões em pé, e o planejamento. A
comunicação é promovida através do envolvimento do cliente (LARMAN,
2003). O XP foca em construir um mútuo entendimento do ambiente do
problema de pessoa-para-pessoa com um mínimo de documentação formal
e a máxima interação face-a-face (HIGHSMITH, 2002).
2. Simplicidade: XP recomenda realizar a coisa mais simples que possa
funcionar. Isso não se aplica somente ao desenho do software, mas a
requisitos e ferramentas de gestão de projetos (LARMAN, 2003).
3. Avaliação (feedback): o XP incorpora as mudanças através de uma
avaliação constante (HIGHSMITH, 2002). Essa prática fornece à equipe e
ao cliente uma avaliação do progresso (LARMAN, 2003). Isso permite
esclarecer e redirecionar as exigências (HIGHSMITH, 2002).
4. Coragem (courage): muitos podem definir coragem como fazer algo certo,
até mesmo quando é pressionado para fazer outra coisa. Se aos valores de
uma equipe não estiverem alinhados, seus membros não serão convencidos
que alguma prática é “certa”, e sem convicção, a coragem não parece tão
importante. É difícil trabalhar motivado para lutar por algo que você não
acredita (HIGHSMITH, 2002). É preciso ter coragem para desenvolver
rápido, e fazer as mudanças assim que surgem (LARMAN, 2003).

Em adição ao IID, ele recomenda as 12 práticas fundamentais (LARMAN, 2003):

1. Planejamento (Planning Game): são partes desse planejamento o curto
prazo, iterações de três semanas, atualização freqüente dos planos, e
 44

atribuição de histórias (uma história define uma característica específica de

um requisito e é descrita em simples cartões). Define o ponto de iteração
entre os clientes e os desenvolvedores, especifacando as responsabilidades
de ambos. O Planejamento inclui o plano de liberações até a liberação final
(HIGHSMITH, 2002).
2. Liberações pequenas e frequentes (Small Releases): toda liberação deve ser
a menor possível, contendo os requisitos mais valiosos para o negócio
(HIGHSMITH, 2002).
3. Metáforas do sistema (Metaphor): XP utiliza os termos metáfora em uma
tentativa de tentar definir um tema global coerente que desenvolvedores e
clientes possam relacionar-se a ele. A metáfora descreve a abrangência do
projeto, enquanto são utilizadas histórias (stories) para descrever
características individuais do projeto.
4. Desenho simples (Simple Design): possui duas partes (1) desenhe as
funcionalidades que tenham sido definidas, ao contrário de fazê-lo para
potenciais funcionalidades futuras, e (2) crie o melhor desenho – como o
mais simples - que permita entregar a funcionalidade. Não importa o
futuro, crie o melhor e mais simples desenho que possa ser entregue hoje
(HIGHSMITH, 2002).
5. Testando (Testing): XP utiliza dois tipos de testes: de unidade e funcional.
Entretanto a prática para os testes de unidade é desenvolvê-los antes de
escrever o código do software. Além disso os testes devem ser
automatizados. Uma vez que o código do software é escrito, é
imediatamente submetido aos testes (HIGHSMITH, 2002).
6. Recodificação frequente (Refactoring): esse é um dos aspectos que
diferencia o XP de outros métodos (HIGHSMITH, 2002). Enquanto RAD
está frequentemente envolvido com um pequeno desenho ou nenhum, XP
considera o desenho continuo, com muito mais atenção à recodificação
(HIGHSMITH, 2002). Para Kent Beck adicionar novas funcionalidades e
recodificar são duas atividades diferentes. A recodificação não alterará a
funcionalidade do software, mas melhora a sua estrutura interna (BECK,
2004).
7. Programação em par (Pair Programming): é um diálogo entre duas pessoas
sentadas enfrente ao mesmo computador, codificando ou programando
 45

simulataneamente, um entrando com código ou casos de testes, um outro

revisando e pensando, criam um contínuo e dinâmico intercâmbio,
refletindo como programar melhor. Programação em par é uma das poucas
práticas de engenharia de software que possui uma aceitação predominante
e que tem sido bem medidos, é inspeção de software. Os seus melhores
resultados são em inspeções em iterações colaborativas para o rápido
aprendizado muito mais que descobrir defeitos. Os seus piores resultados,
são em inspeções que degeneram-se em seções de ataques às pessoas
improdutivas (HIGHSMITH, 2002).
8. Propriedade coletiva (Collective Ownership): concede a qualquer um que
pertença à equipe do projeto a permissão para alterar qualquer código a
qualquer tempo. Essa prática encoraja a equipe inteira a trabalhar de forma
colaborativa (HIGHSMITH, 2002).
9. Integração contínua (Continuous Integration): construções diárias se
tornaram a regra em muitras empresas de software. Enquanto os
especialistas de XP dizem que as integrações diáras são ineficientes,
optando, ao contrário, por construções frequentes em um par de horas. Os
ciclos de avaliação do XP são rápidos – desenvolve o caso de teste,
codifica, integra e testa.
10. 40-horas por semana: corresponde ao desenvolvimento sustentável
(sustainable development) que é uma frase do Manifesto. As horas não são
tudo, mas a prática de 40-horas estabelece uma filosofia, que corresponde
geralmente a uma semana de trabalho (8 horas por dia, por 5 dias na
semana), e se há necessidade de trabalhar além desse período então há
alguma coisa errada, pois devido ao cansaço possívelmente as pessoas
estarão produzindo um trabalho peor. Ainda para Highsmith, sustentável
(sustainable) corresponde ao comprometimento voluntário das pessoas, se
elas gostam de ir para o trabalho, se elas terminam o dia com prazer. As
pessoas têm que trabalhar, mas elas somente obtém ótima performance
estando comprometidas com o projeto e o compromisso só surge de um
senso de propósito (HIGHSMITH, 2002).
11. Toda a equipe junta (On-site Customer): esta prática pede contínuo
envolvimento do usuário com a equipe do projeto (HIGHSMITH, 2002). A
contribuição do cliente inclui uma explicação detalhada das características
 46

resumidas nos story cards, participação em jogos de planejamento,

esclarecimentos, e escrever testes de aceitação em colaboração com o
programador (LARMAN, 2003).
12. Padrões de codificação (Coding Standards): com a propriedade coletiva,
frequente recodificacão, e trocas habituais de pares de programação, todos
precisam seguir o mesmo estilo de codificação (LARMAN, 2003).

A média de duração das iterações está entre uma e três semanas, o que é menor que
no Scrum. O XP também possui baixa escala de cerimônia, pois possui somente um pequeno
conjunto, informal, de artefatos, como cartões indexados para resumir características
requisitadas, chamados de story cards (cartões de história) (LARMAN, 2003).
Uma boa atualização da descrição original do XP foi a declaração das
aplicabilidades conhecidas: tinha sido provado que projetos envolvendo aproximadamente 10
desenvolvedores ou menos, e não era aprovado para sistemas críticos. Não obstante tem sido
aplicado com equipes maiores (LARMAN, 2003).
O XP criado por Kent Beck é um método IID que dá ênfase à satisfação do cliente
através do rápido desenvolvimento de software de alto valor, técnicas hábeis e sustentáveis de
desenvolvimento de software, e resposta flexível às mudanças. É indicado para projetos de
equipes relativamente pequenas, normalmente com datas de entregas inferiores a um ano. As
iterações são pequenas – usualmente uma a três semanas (LARMAN, 2003).
XP provê métodos explicitos para programadores, de maneiras que eles podem
mais confidentemente responder às mudanças de requisitos, mesmo mais tarde no projeto, e
ainda produzir código de qualidade. Esses incluem desenvolvimento conduzido por testes,
reescrita do código fonte para melhorar a consistência interna (refactoring), programação em
par, e integração contínua, entre outros. Em contraste a maioria dos métodos, algumas práticas
do XP são verdadeiramente adotadas pelos desenvolvedores (LARMAN, 2003).
XP é muito orientado à comunicação e à equipe; clientes, desenvolvedores, e
gerentes formam a equipe trabalhando em uma mesma sala de projeto para rapidamente
entregar software com alto valor para o negócio (LARMAN, 2003).
Embora muitos métodos evolutivos evitam detalhar especificações e planos que
cubram o ciclo completo da versão, a maioria deles incentivam documentá-los pelo menos
para a próxima iteração. Em contraste o XP enfatiza a comunicação oral para requisitos e
desenhos (LARMAN, 2003).
 47

A premisa do XP não é a codificação e conserto de programas; ao contrário sua

premissa é que há um novo, estruturado, e sustentável caminho para seguir com um foco na
produção de codificação rápida e comunicação oral, enquanto evita-se a maioria do overhead
(LARMAN, 2003).
A palavra “extreme” (extremo) no XP originou-se da convicção do Beck que é
muito difícil ter boas coisas no desenvolvimento de software. Que é: adote as boas práticas
conhecidas e “gire o discador até o 10”, ou o nível extremo (LARMAN, 2003). Por exemplo:
 Testes são bons, assim que escreva unidades de testes para (quase) todo
código, e testes de aceitação para todas as características.
 Revisões de códigos são bons – mesmo próximos das datas de criação –
assim que faça revisões dos códigos em tempo real e todo tempo via
programação em par.
 Integração frequente do código com todo os membros da equipe é bom,
assim que faça isso 24/7 com um processo de integração automatizado,
continuo em um computador dedicado.
 Iterações curtas e avaliação cedo são bons, assim que iterações com uma
ou duas semanas de duração, se possível.
 Maior envolvimento do cliente é bom, assim que traga o cliente para o
projeto em tempo integral, alocado na mesma sala comum do projeto.
 Comunicação é bom, assim que tenha todo mundo sentado juntos,
programação em par, incluído o cliente no local, e envolva o cliente
frequentemente no planejamento, guiando e avaliando.

Um ciclo de desenvolvimento surgiu com o XP: levantar os requisitos, testar,

codificar, e desenhar. Escute os clientes de perto, enquanto registra os os seus requisitos.
Desenvolva casos de testes . Códifique os objetos (usando pragramação em pares). Desenhe
(ou reconstrua o código fonte sem mudar a funcionalidade) como adicionar mais objetos ao
sistema (HIGHSMITH, 2002). Alguns comentários sobre os ciclos de vida do XP, conforme
definidos por Beck (LARMAN, 2003):
1. Como muitos projetos, XP pode iniciar com exploração. Alguns story
cards (cartões de histórias) podem ser escritos, com estimativas por alto.
 48

2. Nos Release Planning Game (Jogo de Planejamento de Liberações), o

cliente e desenvolvedores completam o story cards com estimativas por
alto, e então decidem o que fazer para a próxima liberação.
3. Para a próxima iteração, no Iteration Planning Game (Planejamento de
Iteração), clientes pegam histórias para implementar. Eles escolhem as
histórias baseados no estado atual, e em suas últimas prioridades para a
liberação. Desenvolvedores então quebram as histórias em várias atividades
pequenas e estimadas. Finalmente uma revisão de todas as atividades
estimadas. Horas extras são seriamente desencorajadas no XP; isto é visto
como um sinal de um projeto não funcional, com aumento da insatisfação
das pessoas, e diminuição da produtividade e qualidade.
4. Desenvolvedores implementa as histórias dentro do período acordado,
continualmente colaborando com o clientes em testes e detalhes de
requisitos.
5. Se não concluído para a liberação, retorna para o item 3 para a próxima
iteração.
Aqui alguns enganos e erros comuns que são cometidos com a utilização do XP
(LARMAN, 2003):
 Não ter o cliente no local; ao contrário, utiliza-se de especificações escritas
para a próxima iteração – é normal e aceitável criar especificações escritas
para as iterações se o método adotado é o Scrum, UP, Evo, etc. Um projeto
interativo ou ágil que toma essa decisão funcionam bem, mas é melhor
caracterizado como sendo baseado em outro método que permita requisitos
escritos. O XP evita especificações detalhadas, utiliza-se de comunicação
oral dos requisitos, e ter o cliente no local.
 Aplicar um subconjunto de práticas descompensadas; personalizar antes de
utilizar – muitas práticas do XP trabalham como um todo sinérgico, e é um
engano remover uma prática que compensa outra. É por isso que Beck
recomenda fazer tudo que recomenda o XP antes de tentar personalizá-lo.
 Não escrever primeiro os testes de unidade – é uma importante prática do
XP. Escrever os testes primeiro influencia como a pessoa concebe,
esclarece e simplifica o desenho.
 49

 O cliente não decide – XP é conduzido pelo cliente; eles precisam decidir

qual é o critério de aceitação, e quais as histórias entram em uma liberação
e iteração.
 O cliente não ser responsável pelos testes – o cliente não faz os testes de
aceitação, é um dos erros mais comuns.
 Ter somente um cliente alocado – o livro original do XP fala de um cliente
alocado na sala de projeto. Kent Beck e líderes do XP têm melhorado isso,
enfatizando que a equipe do cliente necessita ser considerado como um
todo, com requisitos chegando de talvez muitos clientes participando em
Planning Games. Por isso eles têm substituido a prática de cliente alocado
(onsite customer) com toda a equipe junto (whole team together).
 Permanecer com um mesmo par na programação em pares por muito
tempo – os pares no XP mudam frequentemente, frequentemente em dois
dias ou menos. Variações também ajudam a disseminar os conhecimentos.
 Clientes ou gerentes perseguidores – os programadores irão progredir
lentamente.
 Equipe de Garantia da Qualidade não integrado – muitas organizações
possuem uma equipe de garantia da qualidade separado. Uma ou mais
pessoas da equipe de garantia de qualidade necessitam ser envolvidos no
projeto durante todo tempo, normalmente devem escrever os testes de
aceitação em colaboração com o cliente.
 Desenvolvimento posterior a documentação está errado – XP não é anti-
documentação, mas prefere a programação se isso for suficiente para obter
sucesso. XP pode apoiar a criação de documentação do desenho para
refletir a base do código existente, uma vez que o programa esteja
completo.
 Diagramação é ruim – embora o conselho do XP seja modelagem ou
diagramação mínima, como quinze atas antes de programar, muito menos é
aceitável.
 Somente pares de programação jovens – alguns projetos de XP foram
prejudicados quanto a programação de pares quando a maioria dos
participantes eram jovens, sem a paciência ou maturidade para suportar o
trabalho junto de outros.
 50

 Um dos programadores vai muito rápido – quando na programação em par,

um mais rápido ou mais experiente que o seu parceiro deve ser sensível e
compreensível o suficiente para entender a diferença do seu parceiro, e
diminuir a velocidade das suas atividades e explicações.
 Não desejar aprender; não desejar explicar — para obter sucesso com a
programação em par, uma atitude aberta para aprender e explicar é
requerido.
 Reuniões em pé com duração muito longa ou sem foco – mantenha a
duração menor que vinte minutos, e um estado das atividades, não uma
discussão do desenho e requisitos.
 Não ter nenhum testador de aceitação dedicado – uma pessoa é necessária
para trabalhar com o cliente para transformar os seus critérios de aceitação
em testes executáveis. Uma excessão é para projetos muito pequenos –
nesse caso poderia ser uma dedicação de meio período.
 O cliente alocado e o líder do projeto não estão alinhados – o cliente e o
líder do projeto precisam estar alinhados.
 Iterações muito longas – no XP as iterações deveriam ser de uma a três
semanas.
 As iterações não estão limitadas a um bloco de tempo – é um engano
expandir a iteração quando parece que as metas não podem ser atingidas
no prazo original. A estratégia preferida seria remover ou simplificar as
metas da iteração. Então analisar por que as estimativas estavam fora.
 A iteração não termina em uma linha de base integrada e testada – uma
iteração não é considerada um sucesso somente se terminar na data
prevista. A meta é que todo o software tenha sido integrado, testado e
gerado uma linha de base.
 Planejamento preditivo – é um engano criar, ao começo do projeto, um
plano acreditando que se dispõe extamente das quantidade de iterações que
existirão ao longo do projeto, e o que acontecerá em cada uma delas. Isso é
contrastado com um planejamento ágil, um planejamento adaptável. A
equipe XP e o cliente planejam a próxima iteração, e então planejam as
adaptações de iteração a iteração, baseados na avaliação atual.
 51

3.6 Dynamic Systems Development Method (DSDM)

O Dynamic Systems Development Method (DSDM) originou-se em 1994 e se
tornou meta-modelo número um na Inglaterra para desenvolvimentos rápidos de aplicações
(Rapid Application Development – RAD) . É um meta-modelo não proprietário para
desenvolvimentos RAD. DSDM é mantido pelo DSDM Consortium (Consórcio DSDM).
DSDM possui uma significativa infra-estrutura, incluindo vários livros, cursos e grupos de
usuários em vários países, embora a maioria dos usuários estão na Europa (BOHEM, 2003).
Para o DSDM é fundamental fixar tempo e recursos para então ajustar a
quantidade de funcionalidades adequadamente, ao invés de fixar a quantia de funcionalidades
em produto para ajustar o tempo e recursos para tal (ABRAHAMSON, 2002).
O DSDM consiste de cinco fases (ABRAHAMSON, 2002):
1. Feasibility (estudo de viabilidade): é onde a conveniência de DSDM para o
determinado projeto é avaliado, julgando-se pelo tipo de projeto, assuntos
organizacionais e pessoal, a decisão é tomada, para usar DSDM ou não.
Além disso, essa fase está relacionada às possibilidades técnicas de realizar
o projeto, e os riscos disso. São preparados um relatório de viabilidade e
um plano de descrição para o desenvolvimento. Opcionalmente é
construído um protótipo rápido, caso o negócio e a tecnologia não sejam
bem conhecidos. Essa fase deve demorar poucas semanas.
2. Business Study (estudo do negócio): é onde as características essenciais do
negócio e tecnologia são analisados. A idéia básica é organizar workshops,
com um número suficiente de clientes experientes, para que sejam capazes
de considerar todos os aspectos relevantes do sistema, e concordar com as
prioridades. Os processos de negócio e os tipos de usuários são descritos
Business Area Definition (Definição da Área de Negócio). É produzido
também a Definição de Arquitetura, e o Esboço do Plano de Prototipação.
A identificação dos tipos de usuários afetados ajudam a envolver o cliente,
bem como as pessoas chaves. Um alto nível de descrição dos processos são
apresentados no Business Area Definition em um formato satisfatório –
Modelo de Entidade e Relacionamento, Modelos de Objetos de Negócio,
etc. Outros dois artefatos são produzidos: Architecture Definition
(Definição de Arquitetura), e o Outline Prototyping Plan (Esboço do Plano
de Prototipação). A Definição de Arquitetura é o primeiro esboço do
 52

software e é permitido alterá-lo durante o desenvolvimento do projeto

DSDM. O Esboço do Plano de Prototipação deverá declarar as Estratégias
de Prototipação para os estágios seguintes, e um Plano para a Gestão de
Configuração.
3. Functional Model Iteration (modelo funcional de iteração): essa é a
primeira fase iterativa incremental. Em toda iteração, os conteúdos e as
ações são planejadas para as iterações futuras, as iterações acontecem e os
resultados são analisados para futuras iterações. Analises e codificações são
realizadas. Protótipos são construídos. As experiências ganhas são
utilizadas para melhorar os modelos de análise. Os protótipos são
gradualmente melhorados. Um Modelo Funcional é produzido contendo o
código do protótipo e os modelos de análise. Testes também são essenciais
nessa fase. São também produzidos os seguintes artefatos: Prioritized
Functions (Funções Priorizadas) com a lista das funções que são entregues
no final de cada iteração. Functional Prototyping Review Documents
(Documentos de Revisão de Prototipação Funcionais) coleciona os
comentários dos usuários sobre o atual incremento, que funcionam como
entradas para subsequentes iterações. Non-Functional Requirements
(Requisitos Não-Funcionais) são listados, principalmente para serem
negociados na próxima fase. Risk Analysis of Further Development
(Analise de Riscos de Desenvolvimentos Futuros) é um documento
importante na fase do modelo funcional, pois na próxima fase será mais
difícil tratar os problemas encontrados.
4. Design and Build Iteration (projeto e iteração de construção) : é aqui que o
software é construído. Seu produto final é um software testado que
preenche pelo menos um mínimo de requisitos acordados. O Desenho e a
construção são iterativos, e o desenho e os protótipos funcionais são
revistos pelos usuários, e os desenvolvimentos seguintes sào baseados nos
comentários dos usuários.
5. Implementation (implementação): é a fase final onde o software é
transferido do ambiente de desenvolvimento para o ambiente de produção.
Os usuários são treinados, e o software entregue a eles. A implementação
pode ser também um fase iterativa. O manual do usuário e uma revisão do
projeto são escritos. Se o software atende a todos os requisitos então
 53

nenhum trabalho adicional é necessário, mas se houbve consideráveis

requisitos que não foram atendidos então o processo pode ser executado
novamente do começo ao fim. Se somente algumas funcionalidades críticas
foram otimidas, o processo pode ser executado novamente desde a iteração
do modelo funcional até as fases adiantes. Se alguns assuntos técnicos não
puderam ser implementados devido a limitação de tempo, agora eles
poderão ser feitos a partir da fase de desenho e construção.

As duas primeiras fases são seqüenciais e feitas uma só vez.

As três últimas fases são incrementais e iterativas. São as fases onde o trabalho de
desenvolvimento é feito (ABRAHAMSON, 2002).
Os ciclos do DSDM são pré-definidos por um período de tempo e as iterações
devem terminar dentro desse período. O tempo permitido para cada iteração a ser gasto é
planejado com antecedência. A duração típica de cada iteração está entre poucas dia e algumas
semanas (ABRAHAMSON, 2002).
O ciclo de vida do DSDM fornece forte ênfase às atividades de gestão de projeto.
Planejar é inerente a cada fase, como os planos evoluem baseados nos incrementos e
resultados desses. São definidos planos detalhados. A gestão do tempo é primordial para o
planejamento, monitoramento, e controle. Horários e custos são geralmente controlados
constantemente, com os requisitos a serem implementados. Requisitos são priorizados
utilizando-se de MoSCoW (Must have, Should have, Could have, Want)3. Artefatos são
definidos e descritos para cada fase do DSDM. É fornecido um processo de gestão de risco.
DSDM é projetado para equipes pequenas, mas pode ser escalado para qualquer tamanho de
equipe (BOHEM, 2003).
O DSDM define os usuários e desenvolvedores (ABRAHAMSON, 2002):
1. Desenvolvedores e desenvolvedores sênior: o nível sênior basea-se na
experiência nas atividades sob sua responsabilidade e indica um nível de
liderança na equipe, e apoiam todos da equipe de desenvolvimento –
analistas, desenhistas, programadores e testadores.
2. Coordenador técnico: definem a arquitetura do software. São responsáveis
pela qualidade do projeto, controle do projeto técnico como a utilização da
gestão de configuração.

3
Must have significa “tem que ter”; should have significa “deveria ter”; could have significa “poderia ter”; want
significa “quer”.
 54

3. Visionário: é o usuário participante que possui uma percepção mais precisa

dos objetivos do negócio, o software e o projeto. A atividade do visionário
é garantir que os requisitos essenciais sejam descobertos o mais cedo
possível, e que o projeto mantenha-se alinhado a esses requisitos.
4. Executivo Patrocinador: é uma pessoa e usuário da organização que tem a
autoridade e responsabilidade financeira. É quem tem toma a última
decisão.

O DSDM define a ideologia e as bases para todas as suas atividades através das
nove práticas (ABRAHAMSON, 2002):
1. É imperativo o involvimento de usuários ativos.
2. A equipe DSDM deve ter autonomia para tomar decisões.
3. O foco está frequentemente na entrega de produtos.
4. A condição a ser atendida para os propósitos do negócio é o critério
essencial para aceitação das liberações.
5. O desenvolvimento iterativo e incremental é necessário para convergir em
uma solução precisa de negócio.
6. Todas as mudanças durante o desenvolvimento são reversíveis.
7. Requisitos são a base em uma alto nível.
8. Testar e integrar através das iterações (lifecycle).
9. Um cooperativismo e uma colaboração proxima compartilhada por todos
os participantes é essencial.

O tamanho de uma equipe do DSDM está entre dois – pelo menos um

desenvolvedor e um usuário - a seis participantes, e pode existir muitas equipes em um
mesmo projeto. DSDM tem sido aplicado em projetos pequenos e grandes. O pré-requisito
para que DSDM possa ser utilizado em um grande projeto, é que um software grande pode ser
dividido em componentes para podem ser desenvolvidos em pequenas equipes
(ABRAHAMSON, 2002).
DSDM tem muitas semelhanças com RUP e TSP, e possui uma quantidade
significativa de estrutura e conta com seu uso de gestão de riscos para realizar para alcançar
maior agilidade que com processos tradicionais. DSDM possui um ênfase maior em uma
interpretação minimalista das suas orientações que no RUP ou TSP (BOHEM, 2003).
 55

A vantagem fundamental do DSDM é a sua infra-estrutura e o nível de

documentação disponíveis para implementá-lo. O método torna-se mais semelhante aos
métodos de desenvolvimento tradicionais e pode ser facilmente adotado em organizações
baseadas em processos (BOHEM, 2003).

3.7 Feature-Driven Development (FDD)

FDD foca em processos simples, modelagem eficiente, e pequena, ciclos iterativos
que entreguem valores para o cliente. Cresceu através das experiências de Jeff DeLuca e Peter
Coad no desenvolvimento de uma aplicação comercial complexa de empréstimos para o
banco de Singapura em 1997-1998. FDD depende consideravelmente de pessoas com bom
conhecimento da área da aplicação (domain knowledge), projeto e desenvolvimento. A sua
meta principal é ter o processo somente como apóio ao invés de dirigir a equipe (BOHEM,
2003).
FDD é um método ágil e adaptativo para desenvolvimento de software. FDD
consiste de cinco processos seqüenciais e provê os métodos, técnicas e diretrizes necessárias
para os patrocinadores do projeto entregarem o software. FDD inclui pápeis, artefatos, metas e
linhas de base necessárias no projeto. FDD se diz adequado para o desenvolvimento de
sistemas críticos. FDD foi usado pela primeira vez em projetos grandes e complexos para
bancos nos anos noventa (PALMER, 2002).
O desenho e a construção do sistema acontecem durante os cinco processos
seqüenciais. Nessa iteração de desenho e construção o FDD permite desenvolvimento ágil
com adaptações rápidas para mudança posteriores nos requisitos e as necessidades de negócio.
Normalmente a duração de uma iteração é de uma a três semanas (PALMER, 2002).
FDD consiste de um conjunto de melhores práticas que são (PALMER, 2002):
 Domain Object Modeling (Modelo de Objetos do Domínio): exploração e
explicação do domínio do problema.
 Development by Feature (Desenvolvimento por Característica):
desenvolvimento e acompanhamento do progresso através de uma lista de
pequenas funcionalidades decompostas e os benefícios das funções do
cliente.
 56

 Individual Class Ownership (Propriedade da Classe Individual): cada

classe tem uma única pessoa como responsável pela consistência,
performance e integridade referencial da classe.
 Feature Teams (Características da Equipe): refere-se a equipes pequenas
que são formadas dinâmicamente.
 Inspection (Inspeção): refere-se ao use a inspeção para garantir a utilização
de melhores práticas e mecanismos de detecção de defeitos
 Regular Builds (Construção Regular): construções regulares formam a
linha de base para a qual as características são adicionadas.
 Configuration Management (Gestão de Configuração): identificação e
acompanhamento histórico das últimas versões de cada arquivo de código
completado.
 Progress Reporting (Relatório de Progresso): o progresso é reportado para
todos os níveis da organização, baseado no trabalho completado.

Os cinco processos são descritos conforme Palmer (PALMER, 2002):

1. Develop and Overall Model (Desenvolva o Modelo Global): nesse
processo os especialistas do domínio estão cientes do escopo, contexto e
requisitos do sistema. É provável que os requisitos documentados como
casos de uso ou especificações funcionais existam nesta fase. Porém, o
FDD não trata especificamente da obtenção e gestão dos requisitos. A
descrição em alto-nível do sistema é feita pelos especialistas do domínio
através de uma seção de walktrhough. O domínio global é dividido em
diferentes domínios de áreas, e seções de walktrhough mais detalhados
acontecem. Após cada walkthrough a equipe de desenvolvimento trabalha
em grupos menores para produzir modelos de objetos para a área de
domínio em pauta. A equipe de desenvolvimento então decide sobre o
modelo de objeto para cada área de domínio. Simultaneamente um modelo
global é construído para o sistema (PALMER, 2002).
2. Build a Features List (Construa uma Lista de Características): os
walkthroughs, modelos de objetos e a documentação dos requisitos são
bons insumos para a elaboração de uma lista de características para o
sistema em desenvolvimento. A equipe apresenta nessa lista os “benefícios
 57

de cada função para o cliente” incluídos no sistema. As funções são

agrupadas por áreas de domínio.
3. Plan by Feature (Planejar por Características): inclui a criação de um plano
de alto-nível. O conjunto de características após sequenciadas de acordo
com suas prioridades e dependências, são atribuídas ao Programador Chefe.
As classes identificadas no processo “Develop and Overall Model” são
atribuídas aos desenvolvedores. Um cronograma também poderá ser
definido para o conjunto de características.
4. Design by Feature and Build by Feature (Projetar por Característica e
Construir por Característica): um pequeno grupo de características é
selecionado do conjunto de características. A equipe de desenvolvimento
das características selecionadas é constituído pelos proprietários das
classes. Esse processo é interativo, onde as características selecionadas são
produzidas. Poderá haver várias equipes trabalhando em características
específicas. Ess processo inclui atividades de como desenho de inspeção,
codificação, testes, integração e inspeção de código.

O FDD classifica seus papéis em três categorias (PALMER, 2002):

1. Key roles (Papéis Chaves): essa categoria possui seis papéis:
i. Project Manager (Gerente de Projeto): é o administrador financeiro e
líder do projeto. Tem a última palavra na definição do escopo,
cronograma e equipe do projeto.
ii. Chief Architect (Arquiteto Chefe): é responsável pelo desenho global
do sistema e a realização de seções de desenho com a equipe, e é quem
tomas a decisão final sobre todos os assuntos relacionados ao desenho.
iii. Development Manager (Gerente de Desenvolvimento): lidera o
desenvolvimento diário e deve resolver qualquer conflito que possa
ocorrer na equipe. É responsável por resolver problemas de recursos.
iv. Chief Programmer (Programador Chefe): é um desenvolvedor
experiente, que participa na análise dos requisitos, e o desenho do
projeto. É responsável por liderar pequenas equipes na análise, desenho
e desenvolvimento das novas características. Seleciona as
características do conjunto que serão desenvolvidas na nova iteração.
 58

v. Class Owner (Proprietário de Classe): trabalha sob a orientação do

programador chefe nas atividades de desenho, codificação, testes e
documentação. É responsável pelo desenvolvimento das classes que lhe
foram atribuídas.
vi. Domain Experts (Especialista de Domínio): pode ser um usuário, um
cliente, um patrocinador, um analista de negócio ou uma mistura
desses. Deve conhecer como os diferentes requisitos do sistema em
desenvolvimento deveriam funcionar. Eles passam esse conhecimento
para os desenvolvedores. Pode haver também o Domain Manager
(Gerente de Domínio) que liderará o Domain Experts e resolver suas
diferenças de opinião.
2. Supporting roles (Papéis de Suporte): essa categoria possui cinco papéis:
i. Release Manager (Gerente de Liberação): controla o progresso do
desenvolvimento, revendo os relatórios de progresso dos
programadores chefes e coordenando perquenas reuniões de progresso
com eles. Ele reporta o progresso para o Project Manager.
ii. Language Lawyer/Language Guru (Especialista em Linguagem): um
membro da equipe responsável profundamente conhecedor de uma
linguagem de programação ou tecnologia específica. É
consideravelmente importante quando a equipe está experimentando
uma nova tecnologia.
iii. Build Engineer (Engenheiro de Construção): é a pessoa responsável
pelas configurações, manutenção e executar o processo de construção,
incluindo as atividades de gerenciamento do controle de versão do
sistema e a publicação da documentação.
iv. Toolsmith (Ferramentista): é um papél para construção de pequenas
ferramentas para desenvolvimento, teste e conversão de dados.
Também pode trabalhar na configuração e manutenção de banco de
dados e sítios Internet para propósitos específicos do projeto.
v. System Administrator (Administrador de Sistema): suas atividades são
configurar, gerenciar e diagnosticar servidores, redes, estações de
trabalho dos ambientes de desenvolvimento e testes.
3. Additional roles (Papéis Adicionais): essa categoria possui três papéis:
 59

i. Testers (Testadores): verifica se o sistema que está sendo produzido

atende os requisitos do cliente.
ii. Deployers: trabalha com a conversão de dados existentes para o
farmato requisitado pelo novo sistema, e participando no entrega de
novas liberações.
iii. Technical Writers (Redator Técnico): prepara a documentação do
usuário.

Os autores do FDD, Palmer e Felsing (PALMER, 2002), recomendam que as

organizações deveriam adotá-lo gradualmente, até que seja inteiramente utilizado com o
avanço do projeto.
Podem ser projetados e implementados múltiplos pacotes através de várias
equipes, permitindo ao FDD ser empregado a equipes e projetos maiores muito mais
facilmente que alguns dos outros métodos ágeis. O FDD enfatiza a importância de bons
profissionais. Enquanto todos os métodos ágeis geralmente aderem às técnicas orientadas a
objetos (OO), FDD especificamente define seus processos e papéis com a tecnolgia OO em
mente (BOHEM, 2003).

3.8 Algumas Comparações entre os Métodos Ágeis

Baseado em Barry Bohem e Richard Turner (BOEHM, 2003) é apresentado a
seguir um comparativo entre os diversos métodos ágeis apresentados até aqui, além de
métodos conduzidos por processos. Os próprios autores reconhecem que pode haver
discordância com a classificação, mas consideram também que as suas classificações estão
próximas da realidade e podem ser úteis para uma avaliação geral dos métodos listados nas
tabelas a seguir. Nas tabelas foi adicionado o Rational Unified Process (RUP) para se
conseguir um comparativo mais amplo.
Na Tabela 1 a agilidade de cada método é classificada em ordem crescente, do
mais ágil até os conduzido por planos. Os métodos também estão classificados pelo nível de
formalismo exigido, quanto mais alto o nível maior a exigência por planejamento e
documentação (BOEHM, 2003).

Agilidade Método Formalismo

1o Scrum 1
2o Adaptive Software Development (ASD) 1, 2 e 3
 60

3o Lean Development (LD) 1, 2 e 3

4o Crystal 1, 2 e 3
5o Extreme Programming (XP) 2e3
6o Dynamic Systems Development Method (DSDM) 2, 3 e 4
7o Rational Unified Process (RUP) 2, 3 e 4
8o Feature-Driven Development (FDD) 3

Legenda do nível de formalismo

1 Muito baixo
2 Baixo
3 Médio
4 Alto
5 Muito Alto

TAB. 1 – Métodos ordenados pelo nível de agilidade e o formalismo (adaptação de BOEHM, 2003).
 61

A Tabela 2 mostra o escopo de aplicação de cada método para o qual fornece

orientação específica.

Projetos
Toda a Unidades de Projeto com
Método com multi- Individual
empresa negócio equipe única
equipes

Scrum N/A ~ ~ ~ ~
ASD ~ ~ ~ ~ N/A
LD ~ + ~ N/A N/A
Crystal N/A ~ + + ~
XP N/A ~ N/A + +
DSDM ~ + + + ~
RUP N/A ~ + + N/A
FDD N/A ~ + ~ ~

Legenda: tipo de orientação

N/A Não aplicável
~ Parcial
+ Detalhada

TAB. 2 – Escopo de aplicação do método (adaptação de BOEHM, 2003).

 62

A Tabela 3 mostra o ciclo de vida de cada iteração para o qual fornece orientação
específica.

Desenvolvi-
Método Conceituação Requisitos Desenho Manutenção
mento

Scrum ~ ~ ~ ~ ~
ASD ~ ~ ~ ~ ~
LD ~ ~ ~ N/A ~
Crystal ~ ~ ~ ~ ~
XP N/A + + + +
DSDM + + ~ ~ ~
RUP + + + + +
FDD N/A N/A + + ~

Legenda: tipo de orientação

N/A Não aplicável
~ Parcial
+ Detalhada

TAB. 3 – Ciclo de vida de cada iteração (adaptação de BOEHM, 2003).

A Tabela 4 mostra o formalismo que o processo impõe a cada tipo de atividade.

Gestão de Práticas Risco / Práticas de Interface com

Método
processo técnicas Oportunidade medição o cliente

Scrum + N/A ~ N/A ~

ASD ~ N/A + N/A ~
LD ~a+ N/A + N/A ~
Crystal ~a+ ~a+ + ~ ~a+
XP ~ + ~ ~ +
DSDM + ~ + ~ ~
RUP ~ ~ + ~ N/A
FDD ~ + N/A ~ ~

Legenda: tipo de orientação

N/A Não aplicável
~ Parcial
+ Detalhada
TAB. 4 – Formalismo imposto por cada método (adaptação de BOEHM, 2003).
 63

4 CONCLUSÃO

Parece ser consenso comum que as organizações, como os desenvolvedores de

software, gostariam que a produção de software fosse feita mais rapidamente, com qualidade e
isento de erros, e é por isso que os processos de melhores práticas visam atender a essas
expectativas, independente se os métodos utilizados são os ágeis ou tradicionais. Cada um
desses métodos possui vantagens e desvantagens. Normalmente as vantagens têm sido
ressaltadas e divulgadas pelos defensores e simpatizantes do próprio método. No
desenvolvimento deste trabalho foi identificado que nem sempre isso é verdade. Esses
defensores e simpatizantes normalmente ressaltam as suas vantagens através do que
consideram ser desvantagens dos outros métodos. Como disseram Barry Boehm e Richard
Turner (BOEHM, 2003; tradução nossa):
Agilidade e disciplina são de fato valores complementares no desenvolvimento de
software. Desenvolvedores conduzidos por planos (que utilizam os métodos
tradicionais) devem ser ágeis; desenvolvedores ágeis (que utilizam métodos ágeis)
devem ser disciplinados. A chave do sucesso é encontrar o equilíbrio entre os dois, o
qual varia de projeto para projeto de acordo às circunstâncias e os riscos envolvidos.
Desenvolvedores, atraídos para fins opostos através de argumentos comovidos, têm
que aprender a dar a cada um o seu valor devido.

É interessante ressaltar que Grady Booch, cientista chefe da IBM Rational

Software, ao prefaciar (BOEHM, 2003; tradução nossa) diz o seguinte:
Eu tenho pessoalmente vivenciado até este momento três guerras de gerações de
métodos. A era da análise estruturada e métodos de desenho, que inicialmente
encontraram ressonância em metodologistas como Tom DeMarco, Ed Yourdon, Larry
Constantine, Harlan Mills, Michael Jackson, e muitos outros. Há um método
estruturado essencial que se pode extrair de suas experiências coletivas, mas no meio
daquela era, houve uma verdadeira cacofonia de idéias competitivas. A época da
análise orientada a objetos encontrou ressonância em metodologistas como Jim
Rumbaugh, Ivar Jacobson, Peter Coad, Stephen Mellor, Watts Humphrey, eu mesmo
(Grady Booch), e muitos outros. Daqui também se pode extrair algumas essencias das
melhores práticas (das quais o Rational Unified Process é tudo sobre), mas ainda
assim, esta época foi caracterizada por duelos entre os métodos, cada um desejando a
predominância global. Agora encontramo-nos na era post-dot-bomb (posterior a
explosão da bolha Internet), e um modo novo de construção de sistemas surgiu, com
indivíduos como Kent Beck, Martin Fowler, Robert Martin, Jim Highsmith, e muitos
outros que dão voz a esse movimento. [...] De fato, é um sinal de saúde extrema para a
nossa indústria, a existência de tal comunidade vibrante, que lida com processos e a
experiência de desenvolvedor. Como cito frequentemente Bjarne Stroustrup, nossa
civilização funciona através do software. Construir software de qualidade que tenha
valor econômico tem sido, é, e continuará sendo uma coisa difícil de se fazer, e assim
a energia gasta para melhorar processos é a mesma energia que reduz o conflito entre
pessoas de desenvolvimento de software.
 64

Jim Highsmith diz em seu livro “Agile Project Management: Creating Innovative
Products” (HIGHSMITH, 2004) que agilidade é uma forma de pensar, ao contrário de um
conjunto de práticas e processos, e que equipes ágeis possuem o equilíbrio entre flexibilidade
e organização. Em princípio seria desejável que todo projeto pudesse contar com agilidade,
mas nem sempre equipes ágeis possuem o equilíbrio entre flexibilidade e organização, a
menos que um certo grau de formalismo dos processos e controle sejam adotados, o que
normalmente acontece nos métodos tradicionais, e que têm sido recomendados por alguns
métodos ágeis, como o Crystal e o DSDM.
Através do desenvolvimento deste trabalho ficou claro que existem várias outras
alternativas ao XP e ao RUP, e que, além dos métodos citados aqui, existem outros métodos
que merecem menção: Evo, Agile Modeling (AM), Pragmatic Programming (PP), Open
Source Software (OSS), Personal Software Process (PSP) e Team Software Process (TSP).
As fronteiras entre os métodos ágeis e os tradicionais têm sido reduzidas, pois
métodos como o Crystal, DSDM e FDD, classificados como métodos ágeis, trazem muitas
das características dos métodos tradicionais, como o RUP, sendo adaptáveis aos projetos onde
são aplicados. Apesar de serem citados somente esses métodos ágeis, aqui na conclusão, no
capítulo 3 podemos identificar outros métodos ágeis que possuem algumas características
similares aos métodos tradicionais. Para citar um exemplo de como as fronteiras estão sendo
reduzidas, podemos observar que o Crystal ganha mais formalismo à medida que é
empregado em equipes maiores. Os seus processos se tornam mais rígidos e documentados.
Em contrapartida, observa-se que alguns métodos tradicionais têm reduzido o seu volume de
documentação exigida, ganhando agilidade com a adoção de ferramentas que automatizam
esse processo.
Outros fatores também devem ser considerados, pois nem sempre o volume de
documentação é a causa fundamental da perda de agilidade, assim como processos muito
informais poderão dificultar a contratação dos serviços do desenvolvedor de software por
novos clientes. Alguns fatores poderão contribuir para o aumento da agilidade, como: adotar
padrões de desenvolvimento de software; utilizar ferramentas de desenvolvimento
automatizadas e integradas entre si; contratação de pessoal altamente qualificado; equipe com
cultura mais homogênea; gestão de treinamento e do conhecimento; processos motivacionais;
ambiente de trabalho agradável; liderança ativa; entre outros.
 65

REFERÊNCIAS

ABRAHAMSON, Pekka; SALO, Outi; RONKAINEN, Jussi; WARSTA, Juhani. Agile

software development methods: review and analysis. Oulu: Espoo, 2002. VTT Publications
478. 107p.

BECK, Kent. Extreme Programming Explained: embrace change. 2. Ed. Addison Wesley
Professional, 2004. 224 p. ISBN 0321278658.

BOEHM, Barry; TURNER, Richard. Balancing agility and discipline: A Guide for
Perplexed. Addison Wesley Professional, 2003. 304 p. ISBN 0321186125.

COCKBURN, Alistair. Agile software development: the cooperative game. 2. Ed. Addison
Wesley Professional, 2006. 504p. ISBN 0201760436.

CUNNINGHAM, Ward. Manifesto for agile software development. Disponível em:

<http://www.agilemanifesto.org>. Acesso em: 10 jan. 2007.

HIGHSMITH, Jim. Agile project managment: creating innovative products. Addison

Wesley Professional, 2004. 312 p. ISBN 0321219775.

HIGHSMITH, Jim. Agile software development ecosystems. Addison Wesley Professional,

2002. 448 p. ISBN 0201760436.

LARMAN, Graig. Agile & iterative methods: a manager’s guide. Addison Wesley
Professional, 2003. 368p. ISBN 0131111558.

PALMER, Stephen R.; FELSING, John M. A practical guide to Feature-Driven

Development. New Jersey: Printice-Hall, 2002. ISBN 0130676152.

SCHWABER, Ken; BEEDLE, Mike. Agile software development with Scrum. Printice
Hall, 2002. 158 p. ISBN 0130676349.

TATE, Kevin. Sustainable software development: an agile perspective. Addison Wesley

Professional, 2005. 264 p. ISBN 0321286081.