EDITORIAL

N
esta edição a Engenharia de Software Magazine destaca como
tema de capa a agilidade no desenvolvimento e gerenciamen-
to de projetos de software. Para isto, trazemos duas matérias
muito interessantes. Na primeira delas, Métodos Ágeis de Desenvolvi-
mento de Software, são apresentados o histórico, o conceito, os valores
Ano 2 - 20ª Edição - 2010 Impresso no Brasil e os princípios que norteiam os Métodos Ágeis, assim como são des-
critos os métodos mais freqüentemente utilizados pelas organizações.
Também são exploradas as suas limitações, as indicações de aplicação e
Corpo Editorial os resultados obtidos por empresas que já os adotaram. Por fim, são dis-
cutidos os fatores críticos de sucesso de projetos de desenvolvimento
Colaboradores
Rodrigo Oliveira Spínola de software conduzidos com o uso desses métodos.
rodrigo@sqlmagazine.com.br No segundo artigo, Gerenciamento Ágil de Projetos de Software,
Marco Antônio Pereira Araújo serão apresentados o histórico, a definição, os valores, os princípios e
Eduardo Oliveira Spínola a estrutura de práticas do Gerenciamento Ágil de Projetos. Os projetos
Capa e Diagramação de desenvolvimento de software são normalmente caracterizados por
Romulo Araujo - romulo@devmedia.com.br um elevado grau de incertezas iniciais e, conseqüentemente, por uma
grande dificuldade de detalhamento do escopo e de elaboração de
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br um planejamento completo. Neste cenário de incertezas, abordagens
ágeis para gerenciamento de projetos de software têm sido vistas
Revisor e Supervisor como uma alternativa interessante. Conhecer tais abordagens pode
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
ser considerado fundamental.
Na Web Além destas matérias, esta edição traz mais quatro artigos:
www.devmedia.com.br/esmag
• Uso de Análise de Pontos de Função em Ambientes Ágeis
• Introdução ao Mantis
Apoio • Atividades Aliadas dos Testes de Software
• User Experience: Obtendo Dados com Testes de Usabilidade

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola

Atendimento ao Leitor rodrigo@sqlmagazine.com.br
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Se você tiver algum problema no recebimento do seu exemplar ou precisar de Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computa-
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de ção (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), ten-
bancas de jornal, entre outros, entre em contato com: do ministrado cursos na área de Qualidade de Produtos e Processos de Software,
Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação
Cristiany Queiróz– Atendimento ao Leitor do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
www.devmedia.com.br/mancad
(21) 2220-5338 consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Marco Antônio Pereira Araújo - Editor
(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
Publicidade
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
Para informações sobre veiculação de anúncio na revista ou no site entre em
Computacionais e Bacharel em Matemática com Habilitação em Informática pela
contato com:
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
Kaline Dolabella
publicidade@devmedia.com.br do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado
em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor
Fale com o Editor!
do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
Juiz de Fora, Colaborador da Engenharia de Software Magazine.
vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você
Eduardo Oliveira Spínola
(eduspinola@gmail.com)
gostaria de publicar:
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e
Rodrigo Oliveira Spínola - Colaborador
SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva-
editor@sqlmagazine.com.br
dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na
linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia
de Software e Aplicações).
 Caro Leitor
Caro Leitor,
Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da
Engenharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de
aulas publicadas pode ser vista abaixo:

Tipo: Projeto Tipo: Projeto

Título: Diagrama de Classes na Prática – Partes 14 e 15 – Estudo de Caso 3
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta aula é parte de uma série sobre a construção de diagrama
de classes da UML. O objetivo do conjunto de aulas é apresentar de forma
prática como elaborar o diagrama de classes a partir de diferentes estudos
de caso. Nestas aulas, é finalizada a elaboração do diagrama de classes para
o terceiro estudo de caso. Nesta etapa, serão identificadas as operações e os
relacionamentos que serão acrescentados ao diagrama.
Título: Diagrama de Casos de Uso na Prática – Partes 1 a 3 – Estudo de Caso 1
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta aula é parte de uma série sobre a construção de diagra-
ma de casos de uso da UML. O objetivo do conjunto de aulas é apresentar de
forma prática como elaborar o diagrama de casos de uso a partir de diferentes
estudos de caso. Nestas aulas, será feita uma breve introdução aos diagramas
de casos de uso e também será elaborado o diagrama de casos de uso para o
primeiro estudo de caso.

ÍNDICE

Abordagens Ágeis de Desenvolvimento

05 - Métodos Ágeis de Desenvolvimento de Software

Marisa Villas Boas Dias

22 - Gerenciamento Ágil de Projetos de Software

Marisa Villas Boas Dias

33 - Uso de Análise de Pontos de Função em Ambientes Ágeis

Célio Santana e Cristine Gusmão

Abordagens Tradicionais de Desenvolvimento

41 - Introdução ao Mantis
Renato de Freitas Matos, Letícia Dias da Silva e Evaldo de Oliveira da Silva

Validação, Verificação e Teste

48 - Atividades Aliadas dos Testes de Software
Melissa Barbosa Pontes e Luiz Fernando Rodrigues Corrêa de Barros

53 - User Experience
Antonio Mendes da Silva Filho

4 Engenharia de Software Magazine

Métodos Ágeis de Desenvolvimento de Software
C
omo uma resposta às crescentes
pressões por inovação em pra-
zos cada vez mais reduzidos, às
necessidades de constantes mudanças
de requisitos e ao mau desempenho de
grande parte dos projetos de desenvolvi-
mento de software, houve um movimen-
to na comunidade de desenvolvimento
de software que deu origem aos Métodos
Ágeis. Posteriormente, o conceito-base
deste movimento evoluiu, de uma abor-
dagem técnica para o âmbito gerencial,
criando um novo enfoque de gerencia-
mento de projetos – o Gerenciamento
Ágil de Projetos.
Neste artigo são apresentados o históri-
co, o conceito, os valores e os princípios
Marisa Villas Boas Dias que norteiam os Métodos Ágeis, assim
como são descritos os métodos mais
frequentemente utilizados pelas organi-
zações. Também são exploradas as suas
Edição 20 - Engenharia de Software Magazine
De que se trata o artigo?
Neste artigo são apresentados o histórico, o conceito,
os valores e os princípios que norteiam os Métodos
Ágeis, assim como são descritos os métodos mais
frequentemente utilizados pelas organizações. Tam-
bém são exploradas as suas limitações, as indicações
de aplicação e os resultados obtidos por empresas
que já os adotaram. Por fim, são discutidos os fatores
críticos de sucesso de projetos de desenvolvimento de
software conduzidos com o uso desses métodos.
Para que serve?
Apresentar uma visão abrangente sobre o cenário
atual envolvendo metodologias ágeis.
Em que situação o tema é útil?
Conhecer metodologias ágeis é cada vez mais
importante na medida em que lidamos cada
vez mais com projetos de características dife-
renciadas que exigem, muitas vezes, aborda-
gens não tradicionais de desenvolvimento.
limitações, as indicações de aplicação e
os resultados obtidos por empresas que
já os adotaram. Por fim, são discutidos
os fatores críticos de sucesso de projetos
de desenvolvimento de software condu-
zidos com o uso desses métodos.
5
Definição e Origem dos Métodos Ágeis de
Desenvolvimento de Software
Os Métodos Ágeis de Desenvolvimento de Software surgiram
como uma reação aos métodos clássicos de desenvolvimento1 e
do reconhecimento da necessidade premente de se criar uma
alternativa a estes “processos pesados”, caracterizados pelo
foco excessivo na criação de uma documentação completa
(BECK, et al, 2001). Em meados dos anos 90, integrantes da
comunidade de desenvolvimento de software começaram
a questionar estes processos, julgando-os pouco efetivos e,
muitas vezes, impossíveis de serem colocados em prática
(HIGHSMITH, 2002).
Sintetizando o pensamento deste grupo, Highsmith (Ibid.)
menciona que a indústria e a tecnologia sofrem modificações
tão aceleradas que acabam por “atropelar” os métodos clássi-
cos. Highsmith et al (2002) ainda acrescentam que os clientes,
na maioria das vezes, são incapazes de definir de forma clara e
precisa, os requisitos do software, logo no início de um projeto
de desenvolvimento, o que inviabiliza a adoção dos métodos
clássicos em muitos projetos.
Como resposta a esta situação, muitos especialistas criaram
métodos próprios para se adaptar às constantes mudanças
exigidas pelo mercado e às indefinições iniciais dos projetos.
O agrupamento desses métodos deu origem à família dos Mé-
todos Ágeis de Desenvolvimento de Software. Sendo assim,
“[...] os Métodos Ágeis podem ser considerados uma coletânea de
diferentes técnicas e métodos, que compartilham os mesmos valores
e princípios básicos, alguns dos quais remontam de técnicas introdu-
zidas em meados dos anos 70, como os desenvolvimentos e melhorias
iterativos” (COHEN et al, 2003, p.2).
De fato, Cockburn e Highsmith (2001a) já haviam afirmado
que a maioria das práticas propostas pelos Métodos Ágeis não
tem nada de novo e que a diferença recai principalmente sobre
o foco e os valores que os sustentam.
Segundo Cohen et al (2003), um dos primeiros questionamen-
tos aos métodos clássicos de desenvolvimento de software foi
feito por Schwaber, criador do Scrum. Para entender melhor os
métodos clássicos de desenvolvimento de software baseados
no SW-CMM, Schwaber (2002) elaborou um estudo junto aos
cientistas da DuPont, que tinha por objetivo responder a se-
guinte pergunta: “Por que os processos definidos e defendidos
pelo SW-CMM não promovem entregas consistentes”? Após
analisarem seus processos de desenvolvimento de software,
os cientistas chegaram à conclusão que, apesar do SW-CMM
buscar a consistência, a previsibilidade e a confiabilidade dos
processos de desenvolvimento de software, muitos destes
processos ainda eram, de fato, imprevisíveis e impossíveis de
serem repetidos. A explicação para tal recaía na complexida-
de dos processos propostos pelo SW-CMM, na consequente
1 Entre os métodos clássicos de desenvolvimento de software podem ser citados
o Modelo em Cascata e os modelos iterativos e em Espiral (COHEN et al, 2003).
6 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
dificuldade de aplicação e também na necessidade de mudan-
ças constantes e difíceis de serem antecipadas.
Schwaber (op. cit.) percebe que para que o desenvolvimento de
software seja realmente ágil, deve-se aceitar as mudanças, ao
invés de dar foco extremo à previsibilidade. Quase que simulta-
neamente, outros especialistas no assunto chegam à conclusão
de que métodos que respondam às mudanças, tão rapidamente
quanto estas venham a surgir e que incentivem a criatividade,
são a única maneira de enfrentar e gerenciar os problemas do
desenvolvimento de software em ambientes complexos (COCK-
BURN; HIGHSMITH, 2001a, SCHWABER, 2002).
Neste mesmo período, modelos de processos aplicados a
outras indústrias, começam a ser analisados para servir como
fonte de inspiração ao aprimoramento do processo de desenvol-
vimento de software (POPPENDIECK, 2001). O Modelo Toyota
de Produção2 foi alvo de atenção especial: enquanto as unida-
des fabris americanas trabalhavam a 100% de sua capacidade e
mantinham grandes volumes de inventário de matérias-primas
e de produtos acabados, a fábrica da Toyota mantinha o nível
de estoque suficiente para um dia de operação e produzia
somente o necessário para atender aos pedidos já colocados.
Este modelo traduzido no princípio da Lean Manufacturing,
visava à utilização mais eficiente dos recursos e a redução de
qualquer tipo de desperdício e estava totalmente alinhado à
filosofia da Administração da Qualidade Total3, criada pelo
Dr. Edwards Deming (POPPENDIECK, 2001; FERREIRA et al,
2002). Deming (1990) acreditava que as pessoas desejavam fazer
um bom trabalho e que os gerentes deveriam permitir que os
trabalhadores do chão de fábrica tivessem autonomia para a
tomada de decisões e a resolução de problemas. Além disso,
estimulava o estabelecimento de uma relação de confiança com
os fornecedores e defendia uma cultura de melhoria contínua
dos processos e dos produtos. Enquanto as unidades fabris
japonesas geravam produtos cada vez melhores e mais baratos,
as fábricas americanas não conseguiam fazer o mesmo.
Com base nesta avaliação, Poppendieck (2001) listou 10 prá-
ticas que tornavam a Lean Manufacturing tão bem-sucedida e
que, em seu entendimento, poderiam ser adaptadas e aplicadas
ao desenvolvimento de software:
1. Eliminação de gastos – eliminar ou reduzir diagramas e
modelos que não agregam valor ao produto final;
2. Minimização de inventário – minimizar artefatos interme-
diários, como documentos de requisitos e de desenho;
3. Maximização do fluxo – utilizar o desenvolvimento iterativo
para redução do prazo de entrega do software;
4. Atendimento à demanda – atender às mudanças de
requisitos;
2 Modelo Toyota de Produção – para maiores informações ver Correa e Gianesi
(1993) e Ferreira et al (2002).
3 A Administração da Qualidade Total ou Total Quality Management pode ser en-
tendida como a extensão do planejamento de negócios de uma empresa, abran-
gendo o planejamento da qualidade (JURAN; GRYNA, 1991, p. 210 – 214).
 M etodologias Ágeis

5. Autonomia aos trabalhadores – compartilhar a 3. A eliminação das mudanças pode significar menosprezar condi-
documentação e dizer aos programadores “o que” ções importantes do negócio, ou seja, pode levar ao insucesso de uma
precisa ser feito e não “como” deve ser feito; organização;
6. Atendimento aos requisitos dos clientes – trabalhar 4. O mercado espera um software inovador, com alta qualidade, que
perto dos clientes, permitindo que eles mudem suas atenda aos requisitos do negócio e que esteja disponível em prazos cada
opiniões ou seus desejos; vez menores.
7. Fazer certo da primeira vez – testar o quanto antes
e refazer o código se necessário; Manifesto para o Desenvolvimento Ágil de Software
8. Abolição da otimização local – gerenciar o escopo No início de 2001, criadores e representantes dos chamados Métodos
de forma flexível; Ágeis de Desenvolvimento de Software – Extreme Programming, Scrum,
9. Desenvolvimento de parceria com os fornecedores Dynamic Systems Development Method, Adaptative Software Develop-
– evitar relações conflitantes, tendo em mente que ment, Crystal Methods, Feature-Driven Development, Lean Development,
todos devem trabalhar juntos para gerar o melhor entre outros – se reuniram nos Estados Unidos para discutir alternativas
software; aos tradicionais “processos pesados” de desenvolvimento de software
10. Cultura de melhoria contínua – permitir que o (BECK et al, 2001). Estes especialistas foram enfáticos em dizer que não
processo seja melhorado, que se aprenda com os eram contra métodos, processos ou metodologias, sendo que muitos até
erros e se alcance o sucesso. mencionaram o desejo de resgatar o verdadeiro significado e a credibili-
dade destas palavras. Defendiam a modelagem e a documentação, mas
Highsmith (2002) afirma, que de forma independen- não em excesso. Planejavam, mas reconheciam os limites do planejamento
te, Kent Beck e Ron Jeffreis percebem a importância e da previsibilidade num ambiente turbulento (BECK et al, 2001).
dos princípios defendidos por Poppendieck (2001) A essência deste movimento é a definição de novo enfoque de de-
durante um projeto de desenvolvimento de software senvolvimento de software, calcado na agilidade, na flexibilidade, nas
na Chrysler e criam o projeto Extreme Programming habilidades de comunicação e na capacidade de oferecer novos produtos
(XP), um dos Métodos Ágeis de maior expressão atu-
almente. Simultaneamente, outras histórias começam
a ecoar pelo mundo, como a vivenciada por Alistair
Cockburn, que entrevistando profissionais do IBM
Consulting Group, percebe que equipes de projetos
bem-sucedidos se desculpavam por não ter seguido
os processos formais, por não utilizar as ferramentas
de alta tecnologia e por ter “simplesmente” trabalha-
do de forma próxima e integrada, enquanto membros
de projetos malsucedidos afirmavam ter seguido as
regras e processos e que não entendiam o que havia
dado errado. Com base nesta experiência, Cockburn
desenvolveu o Crystal Method, outro Método Ágil
(HIGHSMITH, 2002).
Face ao exposto, percebe-se que o mundo do
desenvolvimento de software passa por uma im-
portante transformação: os métodos clássicos são
vistos como não adequados a todas as situações e os
especialistas reconhecem a necessidade de criação
de novas práticas, orientadas a pessoas e flexíveis o
suficiente para fazer frente a um ambiente de negócio
dinâmico (COCKBURN; HIGHSMITH, 2001a). Os
principais desafios enfrentados e que devem ser en-
dereçados pelos novos métodos de desenvolvimento
de software são assim sumarizados por Cockburn e
Highsmith (Ibid.):
1. A satisfação dos clientes passar a ter precedência
frente à conformidade aos planos;
2. As mudanças sempre ocorrem – o foco deixa de
ser como evitá-las e passa a ser como abraçá-las e
como minimizar o seu custo ao longo do processo
de desenvolvimento;

Edição 20 - Engenharia de Software Magazine 7

e serviços de valor ao mercado, em curtos períodos de tempo
(HIGHSMITH, 2004, p. xix). Como agilidade deve-se entender
“a habilidade de criar e responder a mudanças, buscando a
obtenção de lucro, em um ambiente de negócio turbulento”
(HIGHSMITH, 2004, p. 16); ou ainda, “a capacidade de balan-
cear flexibilidade e estabilidade” (Id., 2002). A agilidade não
deve ser vista como falta de estrutura, mas está diretamente
relacionada à capacidade de adaptação a situações diversas e
inesperadas. Highsmith (2004, p. 16) enfatiza que a ausência
de estrutura ou de estabilidade pode levar ao caos, mas que
estrutura em demasia gera rigidez.
Como resultado do encontro, foi criada a Agile Alliance4,
sendo publicado o Manifesto para Desenvolvimento Ágil de
Software ou o Manifesto for Agile Software Development
(BECK et al, 2001), cujo conteúdo5 é apresentado abaixo:
“Nós estamos descobrindo melhores maneiras para desen-
volver software, praticando e auxiliando os outros a fazê-lo.
Através deste trabalho nós valorizamos:
- Os indivíduos e suas interações acima de processos e
ferramentas;
- Software em produção acima da documentação exaustiva;
- Colaboração do cliente acima da negociação de contratos;
- Respostas às mudanças acima da execução de um plano.
Ou seja, embora haja valor nos itens à direita, nós valorizamos mais
os itens à esquerda.”
Segundo Cohen et al (2003, p. 6), este Manifesto tornou-se
a peça-chave do movimento pelo desenvolvimento ágil
de software, uma vez que reúne os principais valores dos
Métodos Ágeis, que os distingue dos métodos clássicos de
desenvolvimento.
Além do Manifesto, foram definidos os princípios que regem
a maioria das práticas dos chamados Métodos Ágeis de De-
senvolvimento de Software (AGILE ALLIANCE, 2005). Estes
princípios são apresentados na Tabela 1 abaixo, de acordo com
a ordem originalmente proposta.
Pode-se dizer, então, que os Métodos Ágeis se caracterizam
por serem incrementais, cooperativos, diretos e adaptativos.
Incrementais, dadas as pequenas versões e ciclos rápidos de
desenvolvimento; cooperativos, por estimular a proximidade
com o cliente e a interação entre os programadores; diretos, pela
4 Agile Alliance – Organização sem fins lucrativos criada para auxiliar indiví-
duos e organizações que utilizam os Métodos Ágeis para o desenvolvimento
de software.
5 “We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
- Individuals and interaction over process and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation
- Responding to change over following a plan.
That is, while there is a value in the items on the right, we value the items on
the left more.”
8 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
simplicidade de aprendizado e de documentação; e, finalmente,
adaptativos, pela habilidade de acomodar mudanças ao longo
do projeto (ABRAHAMSSON et al, 2003; FOWLER, 2003).
Como principais diferenças entre os Métodos Ágeis e os
clássicos de desenvolvimento de software podem ser citadas
(FOWLER, 2003; CHIN, 2004):
• Os Métodos Ágeis são adaptativos e não preditivos: diferen-
temente dos enfoques clássicos que defendem o planejamento
integral do escopo no início do projeto e um controle rígido de
mudanças, os planos dos Métodos Ágeis são elaborados e adap-
tados ao longo do projeto, permitindo e, algumas vezes estimu-
lado, a incorporação das mudanças requeridas pelo cliente;
• Os Métodos Ágeis são orientados a pessoas e não a processos:
os processos clássicos têm desenvolvimento de software têm,
em geral, a pretensão de funcionar independentemente de
quem os executa. Já os Métodos Ágeis levam em consideração
os indivíduos, sendo elaborados para auxiliá-las.
Princípios
Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de um
software de valor
Pessoas de negócio e programadores devem trabalhar juntos, diariamente, ao longo de todo o
projeto
Aceite as mudanças de requisitos, mesmo que numa etapa avançada do desenvolvimento
Entregue novas versões do software frequentemente
O software em funcionamento é a medida primária de progresso do projeto
Construa projetos com pessoas motivadas. Ofereça a elas o ambiente e todo o apoio necessários e
acredite em sua capacidade de realização do trabalho
As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
O método mais eficiente e efetivo de distribuir a informação para e entre uma equipe de
desenvolvimento é a comunicação face a face
Processos ágeis promovem desenvolvimento sustentado
A atenção contínua na excelência técnica e num bom projeto aprimora a agilidade
Simplicidade é essencial
Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento
de acordo com os resultados
Tabela 1. Princípios dos métodos ágeis de desenvolvimento de software
(FONTE: AGILE ALLIANCE, 2005.)
Um ponto interessante a salientar é que enquanto alguns
defensores “radicais” dos Métodos Ágeis são categóricos em
criticar e apontar as falhas dos métodos clássicos de desenvol-
vimento de software, outros especialistas, representantes tanto
dos métodos clássicos quanto dos ágeis, têm uma postura mais
amena, enxergando até mesmo uma possibilidade de integra-
ção entre as duas abordagens (GLASS, 2001; COHEN et al, 2003;
PAULK, 2002; GLAZER, 2001; HIGHSMITH, 2004). Glass (2001)
apresenta uma análise do Manifesto para o Desenvolvimento
Ágil de Software e menciona que, apesar de concordar com os
pontos defendidos pelos praticantes dos Métodos Ágeis, não se
deve desprezar os modelos clássicos e que ambos os lados têm
pontos importantes a serem considerados e balanceados. Paulk
(2002) defende que os princípios dos Métodos Ágeis devem ser
seguidos por todos os profissionais que desenvolvem software,

mas lembra que formalismo e disciplina devem ser levados em
conta, especialmente quando o software a ser desenvolvido
envolve severos requisitos de confiabilidade. Paulk (Id., 2001)
analisa o Método Ágil Extreme Programming (XP) sob a ótica do
SW-CMM, apontando como este poderia auxiliar as organiza-
ções a alcançar os objetivos propostos pelo SW-CMM.
Principais Métodos Ágeis de Desenvolvimento de
Software
Dentre os principais Métodos Ágeis de Desenvolvimento de
Software podem ser citados: Extreme Programming, Scrum,
Dynamic Systems Development Method, Adaptative Software
Development, Crystal Method, Feature-Driven Development
e Lean Development (COHEN et al, 2003; UDO; KOPPEN-
STEINER, 2003). A seguir é feita uma breve explanação sobre
as suas principais características.
Extreme Programming (XP)
De acordo com Cohen et al (2003, p.12) “o Extreme Program-
ming (XP) é, indubitavelmente, o Método Ágil de maior ex-
pressão, criado nos últimos anos”. Por se tratar do Método
Ágil mais difundido é abordado com mais de detalhe neste
artigo.
O XP é um Método ágil para pequenas e médias equipes
desenvolverem software, em ambientes com requisitos ins-
táveis. Criado em 1998 por Kent Beck, Ron Jeffries e Ward
Cuninghan, a partir de um projeto piloto na Chrysler (BECK
et al, 1998), o XP vem ganhando cada vez mais adeptos, am-
pliando sua participação no mercado (HIGHSMITH, 2002).
Beck (2000, p.xv) explica que o termo Extreme (extremo) é
utilizado, dado que o XP reúne um conjunto de práticas de
desenvolvimento já existentes e reconhecidas como “boas
práticas” no desenvolvimento de software, mas as leva ao
extremo, ao limite. Juric (2002) comenta que o XP é uma
maneira eficiente, de baixo risco, científica e divertida de
desenvolver software.
A premissa básica do XP é que, ao contrário do que se
pensava há 30 anos, o custo de mudança de um software
não aumenta exponencialmente com o avançar do projeto
(BECK, 2004, p. 21-23). As novas técnicas desenvolvidas
pelos especialistas em software, como os bancos de dados
relacionais e a programação modular, entre outras, permiti-
ram uma redução no custo da mudança (ver Figura 1). Desta
forma, não se faz mais necessário evitar mudanças durante
o desenvolvimento, sendo possível abandonar o Modelo em
Cascata e usar o XP.
O XP baseia-se em 12 práticas ou regras concisas e diretas,
listadas abaixo (BECK, Ibid.; COHEN et al, 2003, p.12, BECK;
FOWLER, 2001, p. 72):
1. Jogo do planejamento: no início de cada interação, clientes,
gerentes e programadores se encontram para definir, estimar
e priorizar os requerimentos. A ideia é que se elabore um pla-
no aproximado no início no projeto e se faça um refinamento
à medida que as necessidades e requisitos se tornem mais
conhecidos;
M etodologias Ágeis
2. Programação em pares: dois programadores utilizando o
mesmo equipamento escrevem o código;
3. Pequenas versões: as versões devem ser tão pequenas quanto
possível e trazerem valor para o negócio. Uma versão inicial
do software deve ser colocada em produção após um pequeno
número de iterações e, em seguida, outras versões devem ser
disponibilizadas tão logo faça sentido;
4. Metáforas: clientes, gerentes e programadores criam metáfo-
ras ou conjunto de metáforas para modelagem do sistema;
5. Projeto simples: os programadores são estimulados a desen-
volver o código do software o mais simples possível;
6. Testes: os programadores devem criar os testes de unida-
de antes ou mesmo durante o desenvolvimento do código
do sistema. Os clientes, por sua vez, escrevem os testes de
aceitação. Ao final de cada iteração a bateria de testes deve
ser conduzida;
7. Refatoração: técnica que permite a melhoria de código sem
a mudança de funcionalidade (BRASIL, 2001b, p. 186), deve
ser executada pela equipe do projeto, o tempo todo;
8. Integração contínua: os programadores devem integrar os
novos códigos ao software tão rapidamente e com a maior
frequência possível;
9. Propriedade coletiva do código: o código do programa deve
ser propriedade de toda a equipe e qualquer integrante pode
fazer alterações sempre que for necessário;
10. Cliente no local: o cliente deve trabalhar com a equipe de
projeto a todo o momento, respondendo perguntas, realizan-
do testes de aceitação e assegurando que o desenvolvimento
do software esteja sendo feito a contento;
11. Semana de 40 horas: como trabalhar por longos períodos
reduz o desempenho, o conteúdo de cada iteração deve ser
planejado de forma a não haver necessidade de realização
de horas extras, fazendo com que os programadores estejam
renovados e ansiosos a cada manhã e cansados e satisfeitos
à noite;
12. Padrão de codificação: no início do projeto deve ser criado
um padrão de codificação, simples e aceito por toda a equipe,
que deverá ser seguido de forma a não permitir a identifica-
ção de quem desenvolveu determinada parte do código e a
auxiliar a condução do trabalho.
Custo da mudança do software
Há 30 anos
Hoje
Requisitos Análise Projeto Implementação Teste Produção
Figura 1. Custo da mudança do software (FONTE: BECK, 2004, p. 21-23)
Edição 20 - Engenharia de Software Magazine 9
 Característica Valores sugeridos

Especialistas concordam que o XP não é decorrência da
aplicação destas práticas isoladamente, mas sim do resultado
de sua combinação (COHEN et al, 2003, p.13). HIGHSMITH
(2002) ainda ressalta que cinco princípios constituem a
base do XP: comunicação, simplicidade, feedback, coragem e
qualidade de trabalho.
Cohen et al (2003, p.13) apresentam um resumo de carac-
terísticas principais que norteiam a aplicação do Extreme
Programming, retratado na Tabela 2.
Característica Valores sugeridos
Tamanho da Equipe Equipes formadas por 2 a 10 integrantes
Duração das iterações Duração usual de duas semanas por iteração
Equipes distribuídas Dada que a equipe deve trabalhar preferencialmente no mesmo
local físico, o XP não é indicado para equipes distribuídas
Aplicações de alta criticidade Pode ser utilizado no desenvolvimento de software de baixa,
média ou alta criticidade
Tabela 2. Características principais para utilização do XP (FONTE: COHEN
et al, 2003, p.13.)
Scrum
Criado por Ken Schwaber e Jeff Sutherland em 1996,
como um método que aceita que o desenvolvimento de
software é imprevisível e formaliza a abstração, o Scrum é
aplicável a ambientes voláteis (SCHWABER, 2002). É uma
abordagem empírica baseada na flexibilidade, adaptabili-
dade e produtividade, em que a escolha das técnicas de de-
senvolvimento fica a cargo dos programadores. Segundo
Udo e Koppensteiner (2003), o Scrum se destaca dos demais
Métodos Ágeis pela maior ênfase dada ao gerenciamento
do projeto. Há atividades específicas de monitoramento e
feedback, em geral, reuniões rápidas e diárias com toda a
equipe, visando à identificação e à correção de quaisquer
deficiências e/ou impedimentos no processo de desenvol-
vimento (SCHWABER; BEEDLE, 2001).
Schwaber (2002) sumariza assim os princípios-chave
Tamanho da Equipe O trabalho é dividido em equipes de até sete pessoas
Duração das iterações Duração usual de quatro semanas por iteração
Equipes distribuídas Como o projeto pode ser constituído por várias pequenas equipes, há a
possibilidade de que estas estejam distribuídas (descentralizadas)
Aplicações de alta criticidade Não há menção específica quanto à aplicabilidade do método
para desenvolvimento de software de alta criticidade
Tabela 3. Características principais pa ra utilização do Scrum (FONTE: COHEN
et al, 2003, p.16-17.)
Crystal Methods
Criado por Alistair Cockburn no início dos anos 90, a partir
da crença de que os principais obstáculos enfrentados no
desenvolvimento de produtos recaíam sobre os problemas de
comunicação, os Crystal Methods dão grande ênfase às pessoas,
à comunicação, às interações, às habilidades e aos talentos
individuais, deixando os processos em segundo plano (UDO;
KOPPENSTEINER, 2003; COCKBURN, 2004, COHEN et al,
2003). Correspondem a uma família de métodos organizados
por cores, de acordo com o número de pessoas envolvidas
(tamanho do projeto x necessidade de comunicação), com as
prioridades do negócio e com a complexidade e a criticidade do
software a ser desenvolvido, conforme mostra a Figura 2.
Apesar da estrutura proposta servir como um guia dos
processos mais adequados a uma determinada situação,
nos Crystal Methods, a definição final dos processos a serem
utilizados é responsabilidade da equipe de projeto. Mas duas
regras principais são sempre seguidas: ciclos de desenvolvi-
mento incrementais com duração de no máximo quatro meses
e reuniões de reflexão que estimulam a colaboração entre
integrantes da equipe de projeto (UDO; KOPPENSTEINER,
2003; COCKBURN, 2004; COHEN et al, 2003).
Metodologias diferentes para diferentes ocasiões
(tamanho do projeto, criticidade do sistema e prioridades)
Priorizado por responsabilidade legal
Priorizado por produtividade e tolerância
(defeitos causam perda de ....)

do Scrum: V6 V20 V40 V100 V200 V500 V1000

Vida (V)
• Equipes pequenas de trabalho, buscando a maximiza-
Criticidade

Dinheiro E6 E20 E40 E100 E200 E500 E1000

ção da comunicação e da troca de conhecimento tácito e Essencial (E)
D6 D20 D40 D100 D200 D500 D1000
informal e minimização de overhead; Dinheiro (D)
C6 C20 C40 C100 C200 C500 C1000
• Adaptação às solicitações de mudanças técnicas ou Conforto (C)

do cliente / usuário, assegurando a entrega do melhor

1-6 7-20 21-40 41-100 101-200 201-500 501-1000
software possível; Número de pessoas envolvidas (+20%)
• Entregas frequentes de versões que podem ser testadas,
Figura 2. Esquema dos Crystal Methods (FONTE: COHEN et al, 2003, p. 16)
ajustadas, executadas, documentadas e liberadas para
produção; Cohen et al (2003, p.15) apontam as características principais
• Divisão do trabalho e das responsabilidades da equipe de projetos que utilizam os Crystal Methods (Tabela 4).
de projeto em pequenas entregas;
• Habilidade em entregar um software pronto quando da Dynamic Systems Development Method (DSDM)
necessidade do cliente ou do negócio. Originário da Inglaterra, em meados dos anos 90, o Dynamic
Systems Development Method é controlado por um consórcio
As características principais que norteiam a aplicação de empresas. Criado a partir do RAD – Rapid Application
do Scrum são apresentadas na Tabela 3 (COHEN et al, Development, o DSDM é o único método ágil compatível com
2003, p.15). a ISO 9000. Seu ciclo de vida é divido nos seguintes estágios:

10 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software


a) Pré-projeto; b) Análise de Aderência; c) Estudo de Negó-
cio; d) Modelagem Funcional; e) Projeto e Desenvolvimento;
f) Implementação, e, g) Pós-implementação. A ideia central
do DSDM é que se deve primeiramente fixar o prazo e os
recursos para, em seguida, definir e ajustar o número de
funcionalidades a serem desenvolvidas (COHEN et al, 2003;
UDO; KOPPENSTEINER, 2003).
Característica Valores sugeridos
Tamanho da Equipe A família dos Crystal Methods acomoda equipes de qualquer
tamanho, preferencialmente compostas por pessoas talentosas
Duração das iterações Até 4 meses para projetos grandes e altamente críticos
Equipes distribuídas Os Crystal Methods foram concebidos para atender ao conceito de
equipes distribuídas
Aplicações de alta criticidade Os Crystal Methods atendem a projetos críticos, incluindo aqueles
que envolvem risco de vida e de valores monetários
Tabela 4. Características principais para utilização dos Crystal Methods
(FONTE: COHEN et al, 2003, p.15.)
Dadas a sua natureza, o DSDM não endereça um tamanho
de equipe específico e não possui durações pré-determinadas
para suas iterações (COHEN et al, op. cit.). Não foram encon-
tradas na literatura recomendações específicas para utilização
no desenvolvimento de aplicações de determinada criticidade
ou para equipes centralizadas ou descentralizadas.
Feature-Driven Development (FDD)
O Feature-Driven Development, criado por Peter Coad e
Jeff DeLuca em 1999, é um método de desenvolvimento
de software específico para aplicações críticas de negócio
(PALMER; FELSING, 2001). Diferentemente de outros Mé-
todos Ágeis, o FDD se baseia em processos bem definidos
e que podem ser repetidos. Sua abordagem se concentra
nas fases de projeto e construção, com maior ênfase na
modelagem, em um ciclo de vida iterativo e também em
atividades de gerenciamento de projetos (UDO; KOPPENS-
TEINER, 2003). Os princípios-base do FDD são apontados
abaixo (HIGHSMITH, 2002):
• Necessidade de se automatizar a geração de software para
projetos de grande escala;
• Um processo simples e bem definido é fundamental;
• As etapas de um processo devem ser lógicas e óbvias para
cada integrante da equipe de desenvolvimento;
• Bons processos atuam na retaguarda, permitindo que a
equipe se dedique ao alcance dos resultados;
• Ciclos de vida curtos e iterativos são mais indicados.
Um projeto conduzido pelo método FDD possui as se-
guintes etapas: a) Desenvolvimento de um modelo geral;
b) Construção da lista de funcionalidades; c) Planejamento
por funcionalidades; d) Projeto e desenvolvimento por
funcionalidades.
A Tabela 5 apresenta as principais características de um
projeto desenvolvido pelo método FDD (COHEN et al,
2003, p.18).
M etodologias Ágeis
Característica Valores sugeridos
Tamanho da Equipe Variável de acordo com a complexidade das funcionalidades a
serem desenvolvidas
Duração das iterações Até 2 semanas
Equipes distribuídas O FDD foi criado para trabalhar com equipes múltiplas e, apesar
de não haver indicação formal para equipes distribuídas, é
passível de adaptação
Aplicações de alta criticidade Indicado para desenvolvimento de software crítico
Tabela 5. Características principais para utilização do FDD (FONTE: COHEN
et al, 2003, p.15.)
Lean Development (LD)
Com raízes na indústria automotiva dos anos 80, em especial
no Modelo Toyota de Produção, o Lean Development é considera-
do o Método Ágil com maior foco estratégico. Iniciado por Bob
Charette, o LD tem como principais objetivos reduzir em um
terço o prazo, o custo e o nível de defeitos no desenvolvimento
de software. Para tanto, requer um grande comprometimen-
to da alta administração e uma predisposição a mudanças
radicais (COHEN et al, 2003; UDO; KOPPENSTEINER, 2003).
HIGHSMITH (2002) aponta como princípios fundamentais do
Lean Development:
• A satisfação do cliente é a prioridade principal;
• Prover sempre o maior valor possível para o dinheiro;
• O sucesso depende da participação ativa dos clientes;
• Todo projeto baseado no LD requer um esforço conjunto de
toda a equipe;
• Tudo pode ser mudado;
• Domine, não aponte as soluções;
• Complete, não desenvolva;
• Prefira uma solução a 80% hoje, a uma solução a 100%
amanhã;
• O minimalismo é essencial;
• A necessidade determina a tecnologia;
• O incremento do produto corresponde a um incremento de
funcionalidade e não de tamanho;
• Nunca force o LD além de seus limites.
Cohen et al (2003, p. 19) afirma que “[...] como o Lean Develop-
ment é mais uma filosofia de gerenciamento que um processo
de desenvolvimento”, os itens referentes ao tamanho da equipe,
à duração das iterações, ao tratamento de equipes centralizadas
ou distribuídas e à criticidade da aplicação não são diretamente
endereçados pelo método.
Adaptative Software Development (ASD)
Criado por Highsmith como uma evolução do RAD – Ra-
pid Application Development em 1992, o Adaptative Software
Development propõe uma forma alternativa de se enxergar o
desenvolvimento de software nas organizações (HIGHSMITH,
2002). O ASD foi projetado para lidar com ambientes repletos de
incertezas e complexos. Segundo Udo e Koppensteiner (2003),
o método estimula a aprendizagem durante o processo de de-
senvolvimento e a adaptação constante às novas realidades do
negócio e do projeto. Além disso, encoraja o desenvolvimento
Edição 20 - Engenharia de Software Magazine 11
iterativo e incremental, com a liberação constante de novas
versões. O ASD oferece estrutura e orientação suficiente para
evitar que os projetos se tornem caóticos, sem, entretanto,
trazer uma rigidez indesejada que venha a suprimir a criativi-
dade. Neste método, o papel do gerente de projetos é favorecer
a colaboração entre a equipe de desenvolvimento e o cliente.
De acordo com Highsmith (2002), o ASD é indicado para
equipes pequenas, mas pode ser adaptado para equipes maio-
res. Com relação aos demais atributos – duração das iterações,
apoio a equipes distribuídas e desenvolvimento de aplicações
de alta criticidade – não foi encontrada uma indicação precisa
na literatura.
Resumo das Características Principais dos Métodos Ágeis
Nos tópicos anteriores foram apresentadas as principais
características de alguns dos chamados Métodos Ágeis de
Desenvolvimento de Software. É importante mencionar que
estes métodos foram selecionados por serem os mais citados
na literatura.
Como visto, apesar dos Métodos Ágeis terem uma essência
ou valores em comum, há algumas diferenças significativas
entre eles. A Tabela 6 apresenta um resumo das principais
características dos Métodos Ágeis analisados, com uma linha
específica destinada à análise da incorporação ou não de prá-
ticas relacionadas ao gerenciamento de projetos.
Aplicação dos Métodos Ágeis nas Organizações
Há uma grande variedade de Métodos Ágeis de Desenvol-
vimento de Software, cada qual sugerindo práticas específi-
cas, cuja adoção traz mudanças às rotinas das organizações.
De acordo com Nerur et al (2005, p.74), “[...] as alterações nos
processos de desenvolvimento de software representam um
fenômeno complexo de mudança organizacional que não
pode ser alcançado pela mera substituição de ferramentas e
tecnologias”. Estas mudanças têm impacto significativo em
vários aspectos da organização: na estrutura, na cultura e nas
práticas gerenciais. Conhecer a amplitude deste fenômeno é
fator crítico para o planejamento e o gerenciamento destas
mudanças. Sendo assim, antes de uma organização adotar e
implementar qualquer um dos Métodos Ágeis é fundamental
que avalie a dimensão do impacto e a sua prontidão para tal
(AMBLER, 2002c; COHEN et al, 2003; FOWLER, 2003; NERUR
et al, 2005).
Para facilitar o entendimento e retomar as principais
características e diferenças entre os enfoques clássico e
ágil de desenvolvimento de software, é traçado paralelo
Característica XP Scrum
Tamanho da Equipe 2-10 1-7
Duração das iterações 2 semanas 4 semanas
Equipes distribuídas Não Adaptável
Aplicações de alta criticidade Adaptável Adaptável
Práticas de gerenciamento de projetos Poucas Muitas
Tabela 6. Características principais dos métodos ágeis selecionados (FONTE: Adaptado de COHEN et al, 2003, p. 23.)
12 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
entre eles na Tabela 7. Estas diferenças entre as abordagens
sugerem que as organizações devem repensar suas metas,
seus objetivos e reconfigurar seus componentes humanos,
gerencial e tecnológico, de forma a alcançar uma implemen-
tação bem-sucedida dos métodos ágeis (NERUR et al, 2005,
p.75). Enfocando o componente gerencial, estas diferenças
podem demandar até mesmo uma alteração no enfoque de
gerenciamento de projetos utilizado para as iniciativas de
desenvolvimento de software.
Ambler (2002c) discute os fatores que influenciam a adoção
bem-sucedida de Métodos Ágeis, enfatizando que o ponto mais
importante para que isto aconteça é a existência de uma com-
patibilidade entre os conceitos e valores da organização e dos
Métodos Ágeis, ou seja, o autor discute claramente a questão
da cultura da organização. Na mesma linha, Nerur et al (2005)
destacam que os valores, as normas e os padrões estabelecidos
e reforçados pelas organizações ao longo do tempo se refletem
nas políticas e nas rotinas da empresa e exercem considerável
influência nos processos de tomada de decisão, nas estratégias
de solução de problemas, nas práticas voltadas à inovação, nos
filtros de informação, nos relacionamentos interpessoais e nas
negociações. Como a cultura e a forma de pensar das pessoas
não são facilmente modificáveis, pode-se dizer que a adoção de
Métodos Ágeis seja indicada apenas a algumas organizações
(AMBLER, 2002; NERUR et al, 2005).
Um segundo fator importante a ser considerado quando da
decisão pela implementação de Métodos Ágeis, de acordo
com Ambler (op. cit.) é o projeto e as características do negócio.
Questões como – Os trabalhos têm sido conduzidos de forma
incremental? Qual é a motivação da equipe de projeto? Qual o
nível de apoio que a equipe de desenvolvimento pode esperar?
Os recursos adequados estão disponíveis? Quão voláteis são os
requisitos do projeto? – são fundamentais para esta avaliação.
Com relação ao último ponto, Bohem (2002) chega a sugerir que
os métodos clássicos deveriam ser preferidos quando o índice
de alteração de requisitos do projeto for inferior a 1% ao mês.
Um terceiro aspecto destacado por Ambler (op. cit.) é a neces-
sidade de definição de um champion, ou seja, de um profissional
que assuma os desafios do projeto, de forma que a equipe de
desenvolvimento possa trabalhar com tranquilidade. Amplian-
do esta análise, uma vez que os Métodos Ágeis valorizam e
depositam elevado grau de confiança no conhecimento tácito
e na capacidade de tomada de decisões de cada indivíduo,
Bohem (op. cit.) enfatiza a importância de se ter também uma
equipe de projeto bem treinada e composta por especialis-
tas. Com relação a este aspecto, apesar de concordar com a
Crystal Methods FDD ASD LD DSDM
Variável Variável Variável
< 4 meses < 2 semanas Não definido
Sim Adaptável
Todos os tipos Adaptável
Poucas Muitas Muitas

Enfoque Clássico
Premissa Fundamental O software é totalmente especificável e previsível e pode ser Software adaptativo e de alta qualidade pode ser construído por pequenas equipes, com o uso de
construído através de um planejamento meticuloso e extensivo princípios como a melhoria contínua do projeto e o desenvolvimento e testes baseados no rápido
Estilo de Gerenciamento Comando e controle
Distribuição de Papéis Individual, favorecendo a especialização
Papel do Cliente Importante
Modelo de Desenvolvimento Modelo de ciclo de vida – Modelo em Cascata, Espiral e iterativos Métodos Ágeis
Tecnologia Sem restrições
Tabela 7. Comparação entre os enfoques clássico e ágil de desenvolvimento de software (FONTE: ADAPTADO DE NERUR et al, 2005, p. 75.)
necessidade de formação de uma equipe especializada, Nerur
et al (2005) chama a atenção para que não se crie uma cultura
de elitismo dentro do grupo de desenvolvimento, que pode
afetar o moral e o comprometimento de outros profissionais
da empresa, não integrantes da equipe.
É inegável também que os Métodos Ágeis trazem consigo
uma mudança radical na relação cliente – fornecedor. Cock-
burn e Higsmith (2001a), Bohem (2002) e Nerur et al (2005)
apontam o envolvimento e a participação dos clientes como
fatores imprescindíveis para o sucesso da implementação dos
métodos ágeis. Os clientes devem estar totalmente compro-
metidos com o projeto, trabalhar com espírito de colaboração,
possuir o conhecimento necessário, ter autonomia para a
tomada de decisões, além de estar disponíveis para sanar as
dúvidas quando necessário. Entretanto, por se tratar de um
item extremamente crítico no processo e que demanda tempo,
paciência e esforço consideráveis para o estabelecimento de
um ambiente de respeito e confiança mútua entre clientes
e fornecedores, é mencionado por alguns autores, entre eles
Nerur et al (Ibid.), como um dos obstáculos à utilização dos
Métodos Ágeis.
Compartilhando os pontos discutidos nos parágrafos ante-
riores, Cohn e Ford (2003, p. 74) acrescentam que transição de
um processo clássico com ênfase no “planejamento – execução
– controle”, para um processo ágil, afeta não apenas a equipe
de desenvolvimento de software, mas também outras equipes,
departamentos, assim como o corpo gerencial da organização.
Tomando por base a experiência empírica de implementações
de Métodos Ágeis em várias organizações, abrangendo tanto
projetos simples como projetos complexos, equipes centrali-
zadas ou distribuídas, os autores sugerem uma abordagem
diferenciada junto aos principais envolvidos nos processos –
programadores, alta gerência e a área de Recursos Humanos
– para que se garanta uma implementação bem-sucedida deste
novo enfoque de desenvolvimento de software.
Segundo Cohn e Ford (2003, p. 74 - 75), usualmente os
programadores respondem à implementação de Métodos
Ágeis com um misto de ceticismo, entusiasmo, otimismo, ou
mesmo, resistência. Como este novo enfoque, o desenvolvi-
mento de software normalmente prioriza a entrega do código
à geração de uma documentação extensiva, a adaptação ao
planejamento completo e, as pessoas e suas interações aos
processos e ferramentas (BECK et al, 2001). Cohn e Ford (op.
M etodologias Ágeis
Enfoque Ágil (Métodos Ágeis)
feedback e na aceitação de mudanças
Liderança e colaboração
Equipes auto-organizadas, encorajando o intercâmbio de papéis
Crítico
Favorece a tecnologia orientada a objetos
cit.) afirmam que há sentimentos controversos entre os inte-
grantes da equipe durante o processo de transição: alguns se
sentem perdidos ou sem um direcionamento, pela ausência de
um cronograma formal ou de uma documentação completa
de requisitos; outros empolgados, pelo reconhecimento de
sua capacidade e pela autonomia concedida; alguns creem
erroneamente que a adoção dos Métodos Ágeis tem o intuito
de estimular a microgerência, dados os encontros e as reu-
niões constantes entre gerentes e equipe, em métodos como
o Scrum e XP.
Em face desta situação, Cohn e Ford (2003, p. 75), assim como
Ambler (2002c), defendem uma passagem gradual dos pro-
cessos clássicos de desenvolvimento para os Métodos Ágeis,
tornando o período de transição mais tranquilo.
A idéia de uma equipe formada por talentos, citada por
Boehm (2002) é ratificada por Cohn e Ford (2003, p. 75) e por
Ambler (2002c), que explicam ainda que diferenças grandes
de produtividade numa equipe podem trazer impactos ne-
gativos ao projeto, uma vez que num Método Ágil, a equipe
se dedica apenas às atividades essenciais para a entrega do
software. Não se deve esquecer, contudo, que uma pequena
queda de produtividade é esperada durante a transição, até
que toda a equipe esteja ambientada com a nova dinâmica
de trabalho. Fowler (2003) destaca que a equipe técnica não
pode ser responsável por todo o trabalho por si só, sendo
fundamental o papel dos gerentes, fornecendo o direciona-
mento, auxiliando a definição das prioridades de negócio,
removendo obstáculos e negociando os prazos de entrega.
Com esta colocação, Fowler (Ibid.) enfatiza a importância do
gerenciamento de projetos mesmo no desenvolvimento de
software conduzido com o uso de Métodos Ágeis.
Ao considerar a questão de equipes distribuídas, Cohn e
Ford (op. cit.) são enfáticos em dizer que, mesmo havendo
a necessidade de se organizar um projeto de forma descen-
tralizada, deve-se fazer o possível para que nas primeiras
semanas de trabalho, a maior parte da equipe esteja reunida
e somente após este período as equipes sejam distribuídas.
Os autores justificam este ponto ao afirmar que equipes que
trabalham segundo os Métodos Ágeis necessitam tomar de-
cisões de forma mais rápida que nos processos tradicionais,
mas para tanto, recorrem a uma comunicação mais frequente
e normalmente informal. Sem esta proximidade inicial, a
comunicação pode ser comprometida.
Edição 20 - Engenharia de Software Magazine 13
 Analisando outro grupo de interessados, Cohn e Ford (2003,
p.76) apontam que normalmente a alta gerência representa um
desafio singular à adoção dos Métodos Ágeis. Basicamente as
suas preocupações recaem sobre quatro pontos fundamentais,
extremamente vinculados à visão do Gerenciamento Clássico
de Projetos:
1. Como é possível prometer novas funcionalidades aos
clientes?
2. Como mensurar o progresso do projeto?
3. Quando o projeto acaba?
4. Como a utilização de um Método Ágil afetará outros
grupos?
Apesar de pertinentes, a origem destes questionamentos
está na dificuldade que muitos gerentes têm em abrir mão
do processo clássico de planejamento e controle, da solicita-
ção de compromissos formais de entrega, mesmo sabendo
que raramente estes objetivos são cumpridos pelas equipes
de desenvolvimento6. Cohn e Ford (2003, p.76) e Highsmith
(2004) salientam que g����������������������������������
erentes que temem que com os Méto-
dos Ágeis não seja possível a fixação de datas de entrega de
produtos a clientes, deveriam lembrar que, no passado, os
planos formais provedores de “garantias” de prazo, custo e
qualidade estavam usualmente errados, superestimados, ou
ambos. Em organizações com histórico de estimativas incor-
retas de projetos, convencer a alta gerência sobre os benefícios
dos Métodos Ágeis pode não ser algo difícil, bastando uma
avaliação dos resultados passados frente aos objetivos iniciais
de prazo, custo e qualidade e a apresentação dos benefícios
potenciais da nova abordagem. Já nos casos em que a equipe
de desenvolvimento entrega seus projetos sistematicamente
no prazo e no custo, a utilização dos Métodos Ágeis pode
ser justificada com vistas à redução de prazos de entrega, à
redução das equipes de trabalho, o que significaria um ganho
para a organização.
Apesar dos Métodos Ágeis proporem uma mudança do
paradigma de “comando e controle” para “liderança e cola-
boração”, conforme explica Nerur et al (2005, p.75), isto não
significa que sejam alheios à necessidade de mensuração do
progresso dos projetos. Segundo Cohn e Ford (2003, p.77),
os Métodos Ágeis podem oferecer um acompanhamento
adequado do projeto, por meio da utilização de relatórios
específicos a cada iteração, que contêm datas-chave, compara-
ção de resultados reais versus planejados, métricas principais
e até mesmo a identificação dos riscos do projeto. Estas são
práticas do gerenciamento de projetos, mas que neste caso, são
aplicadas a cada interação e não ao projeto como um todo.
Outra preocupação bastante comum à alta gerência, refle-
tida na terceira questão, é que aparentemente um projeto
realizado segundo um Método Ágil tende a não ter fim, uma
6 Pesquisa publicada pelo STANDISH GROUP INTERNATIONAL (2003), referente
a projetos de desenvolvimento de software, aponta que usualmente os projetos
ultrapassam em 82% os prazos inicialmente previstos. Em 1999, este índice de
atraso chegou ao valor aproximado de 222%.
14 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
vez que as iterações podem continuar enquanto houver itens
prioritários, definidos pelo cliente, a serem desenvolvidos.
Cohn e Ford (2003, p.77) apontam como solução para esta
questão, a definição de um intervalo de prazo e custo, vincu-
lado a um escopo macro, que servem como uma estimativa
preliminar do projeto, a ser considerada durante a execução
do projeto. A equipe deve buscar entregar uma versão básica
e funcional do software, no prazo mínimo deste intervalo
e, a partir daí, são negociadas entregas complementares
(outras iterações). Desta forma, Cohn e Ford (2003, p. 77),
afirmam que é possível minimizar o desconforto quanto à
finalização do projeto.
Considerando a quarta questão, a implementação de um
Método Ágil pode afetar além da equipe de desenvolvimen-
to, os gerentes, os clientes e, até mesmo, áreas ou departa-
mentos internos à empresa que, numa análise inicial, não
têm nenhum vínculo aparente com o projeto. Sendo assim,
é fundamental que a alta gerência tenha ciência de quais
grupos ou departamentos serão afetados pela adoção dos
Métodos Ágeis, para que se estabeleça um consenso quan-
to à forma de trabalho e se evite desgastes ou problemas
futuros. Neste contexto, deve-se destacar a importância da
participação da área ou departamento de Recursos Huma-
nos no processo de transição para a utilização dos Métodos
Ágeis (COHN; FORD, 2003, p. 78). Representantes desta área
devem ser envolvidos logo no início da implementação, para
que tenham ciência da nova forma de trabalho e forneçam
todo o apoio necessário, sanando dúvidas e amenizando
ansiedades dos envolvidos no processo de mudança.
Complementando esta análise, COHEN et al (2003, p. 31)
selecionam um conjunto de lições aprendidas, que consi-
deram úteis quando da decisão pela adoção de um Método
Ágil, algumas das quais rebatem as críticas mais comuns
atribuídas a este novo enfoque de desenvolvimento de
software:
• Os Métodos Ágeis podem ser aplicados a equipes de qual-
quer tamanho, entretanto, deve-se ter em mente que quanto
maior a equipe, maior a dificuldade de comunicação;
• Experiência é importante para que um projeto ágil seja
bem-sucedido, mas a experiência técnica em desenvolvimen-
to de software é muito mais importante que a experiência
prévia com os Métodos Ágeis;
• Os Métodos Ágeis requerem menos treinamento formal
que os métodos clássicos. Técnicas como a programação
em pares minimizam a necessidade de treinamento, pois
as pessoas aprendem umas com as outras. Os treinamentos
formais podem ser realizados por meio de auto-estudo;
• Um software crítico e de alta confiabilidade pode ser
construído com a utilização de Métodos Ágeis. Neste caso,
é fundamental que os requisitos de desempenho sejam ex-
plicitados logo no início do projeto e os níveis adequados de
teste planejados. Ao solicitar feedback constante, incentivar
a participação dos clientes e a definição de prioridade por
eles, os Métodos Ágeis tendem a antecipar resultados e
minimizar os riscos do projeto;

• Os três principais fatores críticos de sucesso para um projeto
ágil são: cultura, pessoas e comunicação. Os Métodos Ágeis
exigem uma compatibilidade cultural para serem bem-sucedi-
dos; profissionais competentes são fundamentais: os Métodos
Ágeis usam menos técnicos, porém mais qualificados; equipes
centralizadas facilitam a comunicação e a interação próxima
com cliente é fator base para seu funcionamento;
• Os Métodos Ágeis permitem a identificação rápida de
eventuais problemas no projeto, através de pequenos sinais,
como a queda da motivação da equipe nas reuniões diárias,
atrasos nas entregas das iterações e a geração de documentação
desnecessária;
• A documentação deve ser considerada um custo e sua
extensão deve ser determinada pelo cliente. Deve-se buscar
desenvolver uma comunicação mais efetiva, mantendo a do-
cumentação formal em um patamar mínimo necessário.
A forma como um Método Ágil é introduzido em uma orga-
nização e os cuidados tomados durante este processo podem
determinar o sucesso ou o fracasso da iniciativa. Outro im-
portante desafio enfrentado pelos gerentes das organizações
refere-se à escolha do Método Ágil mais apropriado para o
momento e o projeto em questão, em face da variedade de
métodos atualmente disponíveis no mercado (NERUR et al,
2005, p.77). Ambler (2002c) e Cohn e Ford (op. cit.) mencionam
que, se após uma análise detalhada, os Métodos Ágeis não
se apresentarem totalmente compatíveis com o projeto ou
com os princípios da organização, mas suas idéias ainda as-
sim despertarem interesse, pode-se partir para uma adoção
parcial. Nesta estratégia, deve-se identificar os pontos de
melhoria prioritários no processo clássico de desenvolvi-
mento de software e aplicar algumas práticas dos Métodos
Ágeis, visando ao aprimoramento. Obtendo-se um resultado
positivo, procede-se a uma nova seleção de áreas de melhoria
e implantação de novas técnicas, até que todo o Método Ágil
tenha sido adotado.
Por fim, Highsmith (2004), Cohn e Ford (2003) e Nerur et al
(2005) ressaltam que muitas das inseguranças e incertezas
inerentes a este processo de transição podem ser minimizadas
com a adoção de um enfoque de gerenciamento de projetos
adequado e compatível com o desenvolvimento de software
conduzidos com o uso de Métodos Ágeis.
Indústria # Empresas que utilizam Métodos Ágeis
Aeroespacial 1 1
Computação 2 3
Consultoria 1 2
Comércio Eletrônico 5 15
Pesquisa 1 1
Software 2 4
Telecomunicações 2 5
Total 14 31
Tabela 8. Características das empresas pesquisadas (FONTE: ADAPTADO DE REIFER, 2002, p. 15.)
M etodologias Ágeis
Resultados da Aplicação dos Métodos Ágeis
Como os Métodos Ágeis de Desenvolvimento de Software são
relativamente recentes, poucos são os dados empíricos disponí-
veis referentes aos resultados de sua aplicação nas organizações,
alguns dos quais são apresentados a seguir.
Pesquisa realizada por Reifer (2002, p. 14-17) em 32 organiza-
ções, representando 28 empresas de dez segmentos de mercado
distintos, apontou que dentre elas, 14 organizações adotavam
Métodos Ágeis, todas motivadas por um histórico de baixo de-
sempenho dos projetos de desenvolvimento de software quanto
ao cumprimento dos objetivos de prazo e custo. Surpreendente-
mente, a maioria das empresas analisadas era classificada como
nível dois ou superior, na escala de maturidade nos processos de
desenvolvimento de software proposta pelo SW-CMM, ou seja,
possuíam processos relativamente maduros. No entanto, estas
empresas buscavam algo novo, que pudesse reverter o quadro
de mau desempenho consistente de seus projetos. A distribuição
destas empresas entre os segmentos de atuação, assim como
alguns detalhes quanto ao início da prática, à quantidade de
projetos realizados com o uso dos Métodos Ágeis e ao estágio de
implementação do novo método são apresentados na Tabela 8.
Os projetos pesquisados são qualificados como de pequeno
porte (com menos de 10 participantes), em geral, internos, de
baixo risco, com duração menor que 12 meses, mas que exigiam
elevado grau de flexibilidade.
Com relação aos resultados, 50% das organizações que respon-
deram a pesquisa conseguiram mensurar os ganhos obtidos com
a utilização de Métodos Ágeis de Desenvolvimento de Software
de forma concreta, sendo que muitas, por possuírem métricas
anteriores, realizaram comparações bastante efetivas. Reifer (2002,
p.15) aponta como principais ganhos, já normalizados entre todos
os participantes, os seguintes itens:
• Incremento de produtividade: ganhos de 15% a 23% de produ-
tividade frente aos indicadores da indústria;
• Redução de custos: 5% a 7% de redução de custos quando com-
parado aos indicadores da indústria;
• Redução do tempo de entrega: 25% a 50% de redução de
prazo comparando-se com projetos anteriores realizados pelas
empresas;
• Melhoria de qualidade: cinco empresas que possuíam dados con-
cretos apontaram que a taxa de defeitos estava no mesmo nível dos
projetos anteriores quando da liberação de produtos e aplicações.
# de Projetos Início da Utilização de Métodos Ágeis Estágio da Implementação
2001 Descoberta
2000 Piloto
2000 Piloto
2000 Produção
2000 Piloto
2000 Produção
2000 Produção
n/a n/a
Edição 20 - Engenharia de Software Magazine 15
 As demais organizações analisadas, que não possuíam indi-
cadores formais, mensuraram seus ganhos através da opinião
dos principais interessados nos projetos, listando como benefí-
cios da utilização dos Métodos Ágeis, o alto grau de motivação
dos profissionais envolvidos, a elevação da moral da equipe e
alguns outros argumentos intangíveis.
De forma unânime, todas as organizações afirmaram sua
intenção de continuar ou mesmo de estender a utilização dos
Métodos Ágeis, considerando-a uma experiência bastante
proveitosa e bem-sucedida. Mas apesar dos resultados anima-
dores, Reifer (2002, p.15), chama a atenção para que não sejam
tiradas conclusões precipitadas, nem se faça uma generalização
dos resultados, dados o tamanho da amostra (14 organizações)
e o tipo de projetos envolvidos (projetos pequenos, de baixo
risco, em ambiente relativamente controlado).
Maurer e Martel (2002) relataram o caso de uma companhia
– Bitonic Solutions Inc. – sediada no Canadá, cuja equipe de
sistemas, composta por nove profissionais, desenvolveu uma
aplicação para comércio eletrônico. O processo de desenvol-
vimento foi iniciado segundo uma abordagem orientada a
objetos ad hoc, sendo adotado o método ágil Extreme Program-
ming (XP), depois de determinado período. Para a mensuração
da produtividade do desenvolvimento, os autores definiram
três indicadores principais, cujos valores foram divididos pelo
esforço despendido para execução (em horas), a saber:
• Novas linhas de código (NLOC)
• Número de novos métodos (# métodos);
• Número de novas classes (# classes).
Maurer e Martel (2002) coletaram métricas do desenvolvi-
mento nos dois períodos (anterior e posterior ao uso do XP) e
reportaram ganhos de produtividade que variaram de 66,3%
a 302,1%, conforme mostra a Tabela 9.
Indústria NLOC / esforço # Métodos / # Classes / esforço
esforço
Média anterior ao uso do XP 10,2 0,36 0,05
Média com uso do XP 17 1,45 0,21
% de Variação 66,3% 302,1% 282,6%
Tabela 9. Ganhos de produtividade com XP em projetos Web (FONTE:
ADAPTADO DE MAURER; MANTEL, 2002.)
Poole e Huisman (2001) relataram o uso bem-sucedido do Ex-
treme Programmming (XP) na companhia Iona Technologies, no
desenvolvimento de um middleware. Os autores mencionaram
que a empresa não possuía um processo de desenvolvimento
e manutenção de software definido, sendo que a falta de
qualidade no processo acabava por se refletir na qualidade
do produto. Um processo de reengenharia de software foi
iniciado em 1997 sem, entretanto, alcançar os resultados dese-
jados. Em 2000, a companhia decidiu implementar, de forma
gradativa, as práticas do XP em seu processo de manutenção
de software. A Iona Technologies alcançou excelentes resulta-
dos, reportando ganhos de produtividade na ordem de 67%, o
que possibilitou uma redução no seu quadro de pessoal de 36
16 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
para 25 profissionais. A empresa obteve também ganhos de
qualidade, com uma queda bastante significativa do número
de erros encontrados pelos clientes, que passaram de 33 erros
ao mês para quatro erros ao mês. Estes resultados foram atri-
buídos, principalmente, à adoção da prática de programação
em pares.
Em 2001, pesquisa conduzida pelo Cutter Consortium
(COCKBURN; HIGHSMITH, 2001b), com mais de 200 profis-
sionais de diferentes empresas dos Estados Unidos, Europa,
Índia e Austrália, sobre o uso dos métodos clássicos e ágeis
de desenvolvimento de software chegou a três conclusões
interessantes:
• Um aumento do número de empresas que utilizavam algum
Método Ágil de Desenvolvimento de Software, quando com-
parado à pesquisa similar realizada em 2000;
• Os projetos de desenvolvimento realizados segundo o en-
foque ágil apresentaram melhor desempenho em termos de
atendimento aos requisitos do negócio, satisfação do cliente e
qualidade, que os projetos conduzidos nos moldes clássicos;
• Os Métodos Ágeis receberam melhor pontuação no quesito
“moral dos profissionais”, resultado este considerado, na época,
surpreendente pelo fato de apenas 12% dos respondentes serem
analistas ou programadores.
Similarmente a Reifer (2002), Cockburn e Highsmith
(2001b) não generalizam estas conclusões, mas consideram,
em especial o terceiro item, um indício bastante positivo da
contribuição dos Métodos Ágeis em relação à motivação das
equipes de projeto.
A aplicação bem-sucedida do método Extreme Programming
(XP) no desenvolvimento de um sistema de missão crítica7,
voltado à coordenação de equipes da Hewlett-Packard dis-
tribuídas ao redor do mundo, foi relatada por Gawlas (2004,
p. 18-24). O autor aponta que o processo de desenvolvimento,
pelo método XP, foi dividido em sete etapas, cada qual com um
resultado e um prazo inicial pré-determinados. Várias adapta-
ções foram feitas ao longo do projeto. Além de destacar práticas
relacionadas ao XP, Gawlas (2004, p. 18-24) chama a atenção
para a abordagem de gerenciamento de projetos utilizada,
caracterizada como uma combinação entre o conhecimento e
a experiência da equipe de projeto e a necessidade de balan-
ceamento entre o enfoque ágil e o Gerenciamento Clássico de
Projetos adotado pela companhia. Após nove meses e dentro
do prazo previsto, o software entrou em produção com poucos
defeitos, que puderam ser corrigidos de forma rápida e tran-
quila. Gawlas (2004, p. 18-24) salienta também que um ponto
de destaque foi a motivação da equipe de projeto.
Bonato (2004, p. 107-172), por sua vez, apresenta um caso de
adoção do Extreme Programming (XP) em renomada empresa
jornalística brasileira, para o desenvolvimento de uma aplica-
ção que visava à reformulação do pagamento de bonificação às
7 Sistema (ou software) de missão crítica é aquele em que a vida, a saúde ou a
segurança das pessoas ou organizações podem ser comprometidas se a quali-
dade do software não for extremamente alta (TURK et al, 2005, p.29).

empresas publicitárias, garantindo maior controle ao processo.
O projeto foi iniciado segundo o enfoque clássico de desen-
volvimento de software, utilizado pela companhia. Contudo,
logo no início do projeto, a equipe se deparou com problemas
como a impossibilidade de detalhamento prévio de requisitos
e com a dificuldade de entregar o software no prazo, dada a
documentação bastante extensiva exigida pelo processo. Neste
momento, houve uma decisão pela adoção do XP, buscando
aliar qualidade e produtividade diante de requisitos instáveis.
Ao final, o projeto foi considerado um sucesso, com ganhos de
qualidade (mensurados por uma redução de 62,9% no número
de erros reportados pelos usuários após a implementação,
quando comparados com outros projetos conduzidos pelo
Jornal) e com ganhos de produtividade estimados em 4%,
quando comparados à média da indústria (BONATO, 2004, p.
131-135). Assim como nos outros relatos, Bonato (Ibid.) destaca
o elevado grau de motivação da equipe de projeto.
Apesar dos vários estudos expostos, não foi encontrada na
literatura uma pesquisa extensa o suficiente, que permita
a generalização dos benefícios resultantes do emprego dos
Métodos Ágeis. No entanto, não se pode negar que os estudos
realizados até o momento, alguns dos quais aqui retratados,
apontam que determinadas organizações estão de fato auferin-
do resultados positivos, quanto à qualidade, à produtividade e
à motivação de seus profissionais, com a adoção dos Métodos
Ágeis para o desenvolvimento de software.
Limitações dos Métodos Ágeis
Neste trabalho, tão importante quanto listar a aplicação e os
benefícios obtidos com o uso dos Métodos Ágeis, é apresentar
as limitações e obstáculos à sua utilização. Dentre os autores
que escreveram sobre os Métodos Ágeis de Desenvolvimento
de Software, alguns apresentaram e discutiram os princi-
pais conceitos e valores que regem este novo enfoque, como
Abrahamsson et al (2003), Bohem e Turner (2003), Glass (2001),
Cohen et al (2003), Cockburn e Highsmith (2001a; 2001b), Udo
e Koppensteiner (2003), Fowler (2003); outros, como Turk et
al (2003; 2005), Nerur et al (2005), Boger et al (2001) e McBreen
(2003), introduziram uma visão mais crítica, apontando limi-
tações ao emprego dos Métodos Ágeis.
Dentre as obras com enfoque crítico acima citadas, a de Turk
et al (2005) se destaca das demais por sua ampla abordagem,
voltada à identificação tanto dos pressupostos básicos sobre
os quais os princípios e práticas dos Métodos Ágeis estão an-
corados, quanto das limitações, decorrentes de sua aceitação,
conforme mostra a Figura 3. Com base nestes pressupostos,
identificados após análise detalhada de publicações referentes
aos diferentes Métodos Ágeis e dos valores e princípios defen-
didos pela Agile Alliance e retratados no documento Manifesto
para o Desenvolvimento Ágil de Software (BECK et al, 2001), Turk et
al (2003, p. 43-46) pontuam as limitações dos Métodos Ágeis.
Sendo assim, para que se possa entender tais limitações,
deve-se primeiramente visualizar os pressupostos identifica-
dos pelos autores (TURK et al, 2005, p. 22), que se encontram
retratados na Tabela 10.
M etodologias Ágeis
Baseados em
PRINCÍPIOS PRESSUPOSTOS
Derivados de
Sustentam Levam a
São baseadas
em
Têm
PRÁTICAS LIMITAÇÕES
Figura 3. Relacionamento entre princípios, práticas, pressupostos e
limitações (FONTE: TURK et al, 2005, p. 8.)
Ao abordar as limitações dos Métodos Ágeis, Turk et al
(2005, p. 23), iniciam a discussão afirmando que “[...] nenhum
processo ágil é uma bala de prata (apesar dos altos brados dos
entusiastas)”. Os autores defendem que, uma vez que os pres-
supostos apresentados acima não são atendidos por todas as
organizações ou por todos os ambientes de desenvolvimento,
os Métodos Ágeis em seus formatos atuais apresentam sim
limitações. Para minimizá-las, a depender do contexto, deter-
minados métodos necessitam de extensões ou incorporações
de práticas e princípios, usualmente associados os enfoques
preditivos e clássicos de desenvolvimento de software. As
principais limitações apontadas por Turk et al (2005, p. 23-34)
são apresentadas nos parágrafos a seguir.
A primeira limitação identificada diz respeito ao suporte a
equipes distribuídas. A dispersão geográfica acarreta vários
problemas que inexistem quando os integrantes da equipe
de desenvolvimento e do cliente encontram-se próximos. A
comunicação se torna mais difícil, há necessidade de ferra-
mentas e tecnologia especiais. Em ambientes distribuídos,
os pressupostos de interação com o cliente, comunicação da
equipe, comunicação face a face ficam comprometidos. O uso
de documentação formal pode se fazer necessário, para orga-
nizar o trabalho realizado em várias localidades por diferentes
equipes (TURK et al, 2005, p. 25-26).
Turk et al (2005, p. 26-27) apontam a questão da subcontratação
como outra limitação dos Métodos Ágeis, sendo que Nerur
et al (2005, p. 76) estendem a discussão para a negociação de
contratos de forma geral. A transferência do desenvolvimento
de software a um subcontratado pressupõe o estabelecimento
de um contrato de prestação de serviços bem definido. No
entanto, as bases de um contrato tradicional não são as mes-
mas utilizadas pelos Métodos Ágeis. Mesmo seguindo um
enfoque iterativo e incremental, os contratos de forma geral
prevêem marcos, um número fixo de iterações, com durações
e entregáveis pré-definidos e cláusulas restritivas a mudanças,
o que não se adequa a vários pressupostos dos Métodos Ágeis.
Turk et al (2005, p. 26-27) apontam como saída, a criação de
Edição 20 - Engenharia de Software Magazine 17
 Pressupostos
Pressuposto da visibilidade
Pressuposto da iteração
Pressuposto da interação com o cliente
Pressuposto da comunicação da equipe
Pressuposto da comunicação face a face
Pressuposto da documentação
Pressuposto da mudança dos requerimentos
Pressuposto do custo da mudança
Pressuposto da experiência da equipe
Pressuposto da auto-avaliação
Pressuposto da auto-organização
Pressuposto da garantia de qualidade
Pressuposto do desenvolvimento da aplicação específica
Pressuposto do redesenho contínuo
Tabela 10. Sumário dos pressupostos relativos aos princípios propostos pela Agile Alliance (FONTE: TURK et al, 2005, p. 22.)
um contrato contendo uma parte fixa e outra variável para
acomodar ambas as expectativas.
A dificuldade de apoio a grandes projetos e grandes equipes
é outra limitação apontada por alguns autores. Vários autores
apontam que quanto maior a equipe, maior a complexidade da
comunicação e menos ágil se torna o processo (HIGHSMITH,
2004; COHEN et al, 2003, TURK et al, 2005, p. 27-28; NERUR et
al, 2005, p.76). O tamanho das equipes restringe a eficiência e
a frequência das interações face a face, havendo necessidade
de uma maior estruturação e organização da equipe e da
definição de várias linhas e formas de comunicação. O volu-
me de documentação requerido é maior e, de forma geral, a
agilidade tende a diminuir. Isto não quer dizer que grandes
projetos não possam utilizar Métodos Ágeis, mas há que se
adotar práticas complementares para garantir o bom anda-
mento dos trabalhos.
Discutindo outro item, a geração de componentes total ou
parcialmente reutilizáveis (códigos de programas, documentos
de análise e desenho, entre outros) pressupõe a visão comple-
ta da solução (e não apenas do software a ser desenvolvido
naquele momento) e a ênfase no controle de qualidade. Os
Métodos Ágeis têm por premissa a manutenção de uma docu-
mentação mínima, o que dificulta a determinação do potencial
de reuso de um determinado artefato, além de ter por foco o
desenvolvimento de soluções para problemas específicos e
não o desenvolvimento de códigos mais genéricos e reutilizá-
veis. Desta forma, os Métodos Ágeis de Desenvolvimento de
Software não são os mais adequados à geração de artefatos
reutilizáveis (TURK et al, 2005, p. 28-29).
A adoção de Métodos Ágeis no desenvolvimento de sistemas
de missão crítica é outro ponto comentado por Turk et al (2005,
p. 29-30). Aplicações desta natureza requerem que a qualidade
18 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
Detalhamento
A visibilidade do projeto só pode ser alcançada através da entrega de um software funcionando
Um projeto pode ser sempre estruturado em iterações curtas e de períodos fixos
A equipe do cliente está disponível para interação frequente, quando solicitado pelos programadores
Os programadores estão localizados em local que permita a comunicação frequente e intensiva entre si
A comunicação face a face é o método mais produtivo de comunicação com o cliente e entre os
programadores
Desenvolver uma documentação extensiva e consistente (relativamente completa) e modelos de
software é contraproducente
Requisitos sempre sofrem modificações, devido a mudanças de tecnologia, necessidades dos
clientes, domínios de negócio ou mesmo aquisição de novos clientes
O custo da mudança não aumenta dramaticamente com o passar do tempo
Os programadores têm a experiência necessária para definir e adaptar seus processos apropriadamente
As equipes almejam a auto-avaliação
As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
A avaliação dos artefatos de software (produtos e processos) pode se restringir a entrevistas frequentes
e informais, revisões e testes de codificação
O reuso e a generalidade não devem ser objetivos do desenvolvimento de uma aplicação específica.
O software pode ser continuamente redesenhado e assim mesmo, manter sua estrutura e
integridade conceitual.
de todos os seus componentes seja intensivamente testada e
que estes sejam projetados de forma a não haver falhas que
impossibilitem a correção ou o uso seguro de um determinado
equipamento. Neste contexto, os pressupostos relacionados à
documentação, à garantia da qualidade e ao aprimoramento
contínuo dos Métodos Ágeis não são mais válidos. Uma es-
pecificação formal, testes intensivos e abrangentes e outras
técnicas de análise e avaliação dos métodos clássicos de de-
senvolvimento de software se tornam necessárias, apesar de
os autores ressaltarem que a adoção de algumas práticas dos
Métodos Ágeis seja interessante, para aumentar a qualidade e
a confiabilidade do produto final (TURK et al, Ibid.).
O desenvolvimento de um software grande e complexo, com
numerosas linhas de códigos (milhares ou milhões) e alto grau
de integração entre seus vários componentes é outra situação
em que a aplicabilidade dos Métodos Ágeis é contestada.
Segundo Turk et al (2005, p. 30-31), projetos deste porte reque-
rem elevado esforço de gerenciamento e controle, processos
estruturados e formais, para garantir o perfeito entendimento
do software e a integração de todas as suas partes. Os testes
também devem ser cuidadosamente planejados. De forma ge-
ral, não é possível o desenvolvimento deste tipo de software de
forma incremental e a adoção da premissa de desenvolvimento
contínuo pode ser comprometida, haja vista a complexidade e
a extensão do código.
Complementando a análise, Nerur et al (2005, p.76) e TURK et
al (2005, p. 13-15) chamam a atenção à questão da dependência
entre as organizações e suas equipes ágeis de desenvolvimento,
em especial no que diz respeito à gestão do conhecimento, vital
nos dias de hoje, e à relação de poder. Os Métodos Ágeis de
Desenvolvimento de Software encorajam o pensamento direto
e o corte em todo e qualquer esforço desnecessário, inclusive

na documentação. Sendo assim, no desenvolvimento ágil, o
conhecimento é tácito e reside apenas na mente de cada inte-
grante de equipe. Em alguns casos, as organizações tornam-se
dependentes desta equipe e muitas vezes há uma mudança no
balanço do poder, entre os gerentes e os programadores, sendo
os últimos os detentores das informações. Para minimizar este
impasse, Nerur et al (op. cit.) e TURK et al (op. cit.) sugerem que
seja claramente definido o que deve ser documentado e o que
pode ser mantido como conhecimento tácito.
O pressuposto de interação com os clientes é outro ponto
amplamente discutido e criticado por vários autores. Turk et al
(2005, p. 12) esclarece que os Métodos Ágeis pressupõem que
os clientes estão sempre disponíveis para participar, esclarecer
dúvidas e tomar decisões junto à equipe de desenvolvimento,
o que na prática nem sempre se mostra viável. Nerur et al (2005,
p. 76) complementam que o ambiente pluralista de tomada de
decisões (que envolve clientes e equipe de desenvolvimento),
estimulado pelos Métodos Ágeis, torna o processo decisório
mais lento e difícil, quando comparado ao enfoque clássico,
em que o gerente do projeto é o responsável por tal. Nerur et
al (Ibid.) destacam que o sucesso dos Métodos Ágeis depende
de se encontrar clientes que almejem e tenham disponibilidade
para uma participação ativa no processo de desenvolvimento,
que sejam colaborativos, representativos e comprometidos e
que disponham da autonomia e do conhecimento adequados
ao projeto
Há que se mencionar ainda, a questão da manutenção de
software, qualificada como algo tão problemática quanto o
desenvolvimento propriamente dito e ainda pouco abordada
pelos Métodos Ágeis (RUS et al, 2002; COHEN et al, 2003).
Todas estas limitações apontadas por autores e estudiosos do
assunto (TURK et al, 2003 e 2005; NERUR et al, 2005; BOGER
et al, 2001; McBREEN, 2003) devem ser avaliadas quando da
definição método de desenvolvimento de software a ser uti-
lizado. Contudo, apesar de sua importância, não podem ser
consideradas como única verdade, uma vez que a literatura
aponta exemplos de projetos conduzidos com o uso de Métodos
Ágeis que foram bem-sucedidos, apesar das condições teorica-
mente adversas à sua utilização. Entre estes exemplos podem
ser citados: o desenvolvimento de um software de missão
crítica com o uso do XP (GAWLAS, 2003) e a utilização do XP
e do Scrum em projetos com mais de 100 pessoas distribuídas
em mais de um continente (Fowler, 2003).
Fatores Críticos de Sucesso de Projetos de
Desenvolvimento de Software Realizados co m o Uso
dos Métodos Ágeis
Poucas são as referências na literatura que discutem a questão
dos fatores críticos de sucesso de projetos conduzidos com
o uso de Métodos Ágeis. Cohen et al (2003, p. 31) destacam
que são três os principais fatores críticos de sucesso para um
projeto conduzido segundo um enfoque ágil, a saber: cultura,
pessoas e comunicação.
Cockburn e Highsmith (2001b), autores que defendem uma
visão dos Métodos Ágeis centrada nas pessoas, identificam a
M etodologias Ágeis
competência individual como o fator primordial para o suces-
so de projetos conduzidos de acordo com os Métodos Ágeis.
Mencionam que “[...] se as pessoas forem boas o suficiente,
podem usar praticamente qualquer processo e atingir seus
objetivos. Se as pessoas não forem boas o bastante, não há
processo que possa reparar esta inadequação” (COCKBURN;
HIGHSMITH, 2001b, p. 131). A falta de apoio executivo e dos
principais usuários, por outro lado, é apontada como um
grande empecilho para o alcance do sucesso de um projeto,
levando até mesmo excelentes profissionais ao não cumpri-
mento de seus objetivos.
Em 2003, um estudo de caráter exploratório desenvolvido
por Lazaveric (classificado pelo próprio autor como “sem si-
milar” na área até aquele momento) identificou os principais
fatores críticos de sucesso de projetos de desenvolvimento de
software conduzidos com o uso de Métodos Ágeis (LAZARE-
VIC, 2003). A pesquisa foi realizada por meio da aplicação de
um questionário a profissionais que haviam gerenciado ou
participado de projetos com tais características, integrantes de
cinco grupos da internet especializados na troca de experiência
e na discussão dos principais Métodos Ágeis. Apesar de obter
uma taxa de resposta de apenas 4% (o autor acredita que este
número deva ser maior, dado que muitos dos integrantes dos
referidos grupos encontravam-se inativos), a pesquisa per-
mitiu a identificação de fatores críticos de sucesso para tais
projetos que se mostraram bastante alinhados às colocações
de autores como Cockburn e Higsmith (2001b), Cohen et al
(2003) e Reifer (2002).
A existência de programadores motivados foi identificada
como a chave para o sucesso dos projetos pesquisados, sendo
considerado o fator crítico mais importante para projetos
conduzidos com o uso de Métodos Ágeis. O segundo fator
crítico de sucesso identificado foi o grau de propriedade
coletiva do código. A propriedade coletiva pressupõe que
qualquer integrante da equipe pode alterar o código desen-
volvido por outrem e contribuir para a solução e encoraja a
sinergia, a colaboração e o trabalho em equipe. A descoberta
deste segundo fator está totalmente alinhada ao primeiro
item. Lazarevic (2003, p. 28) destaca que “[...] atingir um
estágio em que os resultados do grupo sejam melhores que
a contribuição de cada indivíduo é o coração de muitos
Métodos Ágeis”. Ainda, de acordo com Sutherland (2001),
quando os indivíduos se ajudam mutuamente e contribuem
para o todo, a equipe de desenvolvimento atinge o estado
de hiper-produtividade. O terceiro fator encontrado diz
respeito à entrega de um protótipo logo no início do projeto.
Para Lazarevic (Ibid.), a maioria dos respondentes interpre-
tou esta questão à luz das necessidades de mudanças de
requisitos, ou seja, da necessidade de um desenvolvimento
incremental do software.
Nesse mesmo estudo, Lazaveric (2003, p. 24) menciona que
os projetos desenvolvidos segundo os métodos Extreme Pro-
gramming (XP) e Dynamic Software Development Model (DSDM)
foram mais bem-sucedidos, mas este resultado não se mostrou
estatisticamente significativo.
Edição 20 - Engenharia de Software Magazine 19
 Como informação adicional desta pesquisa, tem-se que a
maioria dos respondentes possuía de um a quatro anos de
experiência em Métodos Ágeis, o que confirma que a utili-
zação destes métodos no desenvolvimento de software é um
fenômeno relativamente novo. O tamanho das equipes dos
projetos analisados variava entre quatro e vinte integrantes,
sendo que apenas 10% dos projetos tiveram mais de 50 parti-
cipantes (LAZAREVIC, 2003, p. 26).
Como muitos outros autores (REIFER, 2002; COCKBURN;
HIGHSMITH, 2001b), Lazarevic (2003, p. 29) não considera seu
estudo representativo, não devendo assim ser generalizado.
Mas o enfoque diferenciado de seu trabalho, em especial, sua
abrangência (obtenção de dados de diferentes projetos, de pro-
fissionais provenientes de distintas organizações), certamente
contribui para a ampliação do conhecimento na área.
Ampliando a visão dos fatores críticos de sucesso, Chin (2004),
assim como Cohn e Ford (2003), Highsmith (2004) e Nerur et
al (2005), ressaltam que não se pode esquecer o inegável valor
do gerenciamento de projetos na entrega de um projeto de
desenvolvimento de software bem-sucedido. Apesar de alguns
Métodos Ágeis já possuírem componentes de gerenciamento
de projetos inseridos em suas práticas, como por exemplo o
Referências
ABRAHAMSSON, P et al. New directions on agile methods: a comparative analysis. In: Proceedings
of the 25th International Conference on Software Engineering. [S.l.]. IEEE Software Society, 2003,
p. 244-254.
AGILE ALLIANCE. Manifesto for agile software development. Disponível em <http://www.
agilemanifesto.org/>. Acesso em janeiro, 2005.
AMBLER, S. W. Agile modeling: effective practices for extreme programming and the unified
process. John Wiley & Sons, Inc., 2002a.
AMBLER, S.W. Lessons in agility from internet-based development. IEEE Software, [S.l.], v. 19, n.
2, 2002b, p. 66–73.
AMBLER, S.W. When does(n´t) agile modeling make sense. Apr, 2002c. Disponível em <http://
www.agilemodeling.com/essays/whendoesAmWork.htm>. Acesso em julho de 2005.
AMBLER, S. W. Quality in an agile world. Software Quality Professional, [S.L.], v. 7, n. 4, sep. 2005.
BECK, K.Embrance Change with Extreme Programming.IEEE Computer Magazine, [S.l.], Oct 1999, p.70-77.
______. Extreme programming explained. Boston: Addison-Wesley, 2000.
BECK,Kent.et al.Chrysler goes to“extremes”.Oct,1998.Disponível em <http://www.xprogramming.
com/publications/dc9810cs.pdf>. Acesso em julho, 2005.
BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em <http://
www.agilemanifesto.org/>. Acesso em janeiro, 2005.
BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001.
BECK, Kent; MEE, R. Enhancing brazilian software’s global competitiveness. Jan, 2003. Disponível
em: <http://www.xispe.com.br/wiki/wiki.jsp?topic=EnhancingBrazilsSoftwareGlobalCompetiti
veness>. Acesso em novembro, 2004.
BOGER, M. et al. Extreme modeling. In: SUCCI, G.; Marchesi, M. (eds). Extreme programming
examined. Boston: Addison-Wesley, 2001.
20 Engenharia de Software Magazine - Métodos Ágeis de Desenvolvimento de Software
Scrum, o FDD e o ASD, Thomsett (2002, p. 17) indica a neces-
sidade de uma abordagem mais ampla e, preferencialmente,
em separado das questões técnicas.
Analisando os fatores críticos de sucesso identificados,
percebe-se que estão estritamente relacionados à valorização
da competência individual e à comunicação (REIFER, 2002;
COCKBURN; HIGHSMITH, 2001b; LAZAREVIC, 2003) e à
entrega rápida de valor (LAZAREVIC, 2003). Todos estes itens
correspondem a características marcantes dos Métodos Ágeis
de Desenvolvimento de Software e o também do Gerenciamen-
to Ágil de Projetos, o que pode sugerir que talvez este seja o
enfoque de gerenciamento de projetos mais apropriado para
o desenvolvimento de software conduzido com o uso de um
Método Ágil.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine
sobre e
tem que ser feita ao seu gosto.
s
ta
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
BOHEM, Barry. Get ready for agile methods, with care. IEEE Computer Magazine, [S.l.], Jan. 2002, p. 64-69.
BOHEM, Barry.; TURNER, Richard. Balancing discipline and agility: evaluating and integrationg
plan-driven methods. In: Proceedings of the 26th Conference on Agile Development. IEEE
COMPUTER SOCIETY, [S.l.], May 2004, p. 718-719.
BONATO, A. S. F. Uma experiência de aplicação do processo Extreme Programming em pequenos
projetos. São Paulo, 2004. Dissertação (Mestrado em Engenharia) - Programa de Pós-Graduação
em Engenharia, Escola Politécnica da Universidade de São Paulo.
BRASIL. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. Levantamento do
universo de Associadas Softex. Brasília - DF, 2001a.
______. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. Qualidade e
Produtividade no Setor de Software Brasileiro. Brasília - DF, 2001b.
CHIN, Gary. Agile project management: how to succeed in the face of changing project
requirements. NY: Amacon, 2004.
COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Addison-
Wesley, 2004.
______. Agile software development. Boston: Addison-Wesley, 2001.
______. Learning from agile software development – part one. Crosstalk, The Journal of Defense
Software Engineering, [S.l.], October 2002.
COCKBURN, A.; HIGHSMITH, J. Agile software development: the business of inovation. IEEE
Computer Magazine, [S.l.], p. 131-133, sep 2001a.
______. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-
133, nov 2001b.
COHEN, David et al. Agile software development: a DACS state of art report. NY: Data Analysis Center for
Software - Fraunhoufer Center for Experimental Software Engineering Maryland and The University of
Maryland, 2003. Disponível em <http://www.thedacs.com/techs/agile/>. Acesso em abril, 2005.

Continuação: Referências
COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA executivo. Trad. Afonso Celso da
Cunha Serra. Rio de Janeiro: Campos, 2002.
COHN, Martin. The scrum development process. Disponível em <www.mountaingoatsoftware.
com/scrum> Acesso em julho, 2005.
COHN, Martin; FORD, Doris. Introducing an agile process to an organization. IEEE Computer
Magazine, June 2003, [S.l.], p. 74-78.
DEMING, W. E. Qualidade: a revolução da administração. Rio de Janeiro: Marques Saraiva, 1990.
FERREIRA, A. A., REIS, A. C. F., PEREIRA, M. I. Gestão empresarial: de Taylor aos nossos dias. São Paulo:
Thomson, 2002, p. 146-164.
FOWLER, Martin. The new methodology. April, 2003. Disponível em <http://www.martinfowler.
com/articles/newMethodology.html>. Acesso em julho, 2005.
GAWLAS, J. Mission critical development with XP & agile process: common code ownership and
lots of testing. Dr. Dobb´s Journal, [S.l.], p. 21-24, Jan. 2004.
GLASS, Robert. Extreme programming: the good, the bad and the bottom line. IEEE Software, [S.l.],
Nov. 2001, p. 111-112.
GLAZER, H. Dispelling the process myth: having a process does not mean sacrificing agility or
criativity. Crosstalk, The Journal of Defense Software Engineering, [S.l.], Nov. 2001.
HIGHSMITH, Jim. Adaptative management: patterns for the e-business era. Cutter IT Journal, [S.l.],
v. XII, n. 9, sep. 1999.
HIGHSMITH, Jim. Agile software development ecosystems. Boston: Addison-Wesley, 2002.
______. Agile project management: creating innovative products. Boston: Addison-Wesley, 2004.
HIGHSMTIH, Jim et al. Extreme programming: e-business application delivery. Feb. 2002. Disponível
em <http://www.cutter.com/freestuff/ead0002.pdf>. Acesso em julho, 2004.
JURAN, J. M.; GRYNA, F. M. Controle da qualidade – handbook: conceitos, políticas e filosofia da
qualidade. São Paulo: Makron, McGraw-Hill, 1991
JURIC, R. Extreme Programming and its Development Practices. In: Proceedings of 22nd
international conference on information technology interfaces. 2002, p. 97–104.
LAZAREVIC, George. An exploratory study of the new product development utilized by software
companies using agile product development approach. Oct. 2003. Disponível em <http://www.
agilealliance.org/articles/articles/agileOct.pdf>. Acesso em agosto, 2005.
MAURER, Frank.; MARTEL, Sebastien. Extreme programming: rapid development for web-based
applications. IEEE Internet Computing, [S.l.], v. 6, n. 1, p. 86–90, Jan. 2002.
M etodologias Ágeis
______. On the productivity of agile software practices: an industrial case study. Abr. 2004.
Disponível em: <http://sern.ucalgary.ca/ milos/papers/2002/MaurerMartel2002c.pdf>. Acesso
em Agosto, 2005.
McBREEN, P. Questioning extreme programming. Boston: Addison-Wesley, 2003.
NERUR, S. et al. Challenges of migrating to agile methodologies: organizations must carefully
assess their readiness before treading the path of agility. Communication of the ACM, [S.l.], v.48,
n.5, p 73-78, May 2005.
PALMER, S. R.; FELSING, M. A practical guide to feature-driven development. [S.l.]: Pearson
Education, 2001.
PAULK, Mark. C. ExtremepProgramming from a SW-CMM perspective. IEEE Software, [S.l.], v. 18,
n. 6, p. 19–26, Nov. 2001.
______. Agile methodologies and process discipline. Crosstalk - The Journal of Defense Software
Engineering, [S.l.], v. 15, n. 10, p. 15–28, Oct. 2002.
POPPENDIECK. M. Lean programming. Software Development Magazine. May-June, 2001
Disponível em <http://www.agilealliance.org/articles/articles/LeanProgramming.htm>. Acesso
em julho, 2005.
POPPENDIECK. M.; POPPENDIDIECK. T. Lean software development. Boston: Addison-Wesley, 2003.
REIFER, Donald J. How good are agile methods? IEEE Software, [S.l.], p. 14-17, jul-ago, 2002.
RUS, I. et al. Process diversity in software maintenance – guest editors´s introduction. Software
Maintenance Research and Practice, Dec. 2002.
SCHWABER, K.; BEEDLE, M. Agile software development with scrum. NJ: Pretence Hall, 2001.
SCHWABER, K. Controlled chaos: living on the edge. 2002. Disponível em <http://www.
agilealliance.org/articles/articles/ap.pdf>. Acesso em junho, 2005.
THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002.
TURK, D. et al. Limitations of agile software processes. Jan, 2003. Disponível em <http://www.
agilealliance.org/articles/articles/LimitationsofAgile.pdf> Acesso em Agosto, 2005.
______.Assumptions underlying agile software development process.Colorado State University, 2005.
UDO, N., KOPPENSTEINER, S. Will agile change the way we manage software projects? Agile from a
PMBoK guide perspective. Projectway, [S.l.], 2003.
Edição 20 - Engenharia de Software Magazine 21
 Gerenciamento Ágil de Projetos de Software
Marisa Villas Boas Dias
22 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software
O
Gerenciamento Ágil de Projetos ou
Agile Project Management (APM)
foi criado a partir dos valores
e princípios dos Métodos Ágeis de De-
senvolvimento de Software, retratados
no Manifesto para o Desenvolvimento Ágil
de Software (BECK et al, 2001). Conectado
a iniciativas correlatas das indústrias
de construção civil e aeroespacial (uma
vez que o cenário de complexidades e
incertezas era comum a todos), o mo-
vimento para o desenvolvimento ágil
de software ampliou sua abrangência,
sendo estendido ao gerenciamento de
projetos (HIGHSMITH, 2004, p. xix).
Chin (2004, p.1) afirma que “[...] em pro-
jetos que envolvem tecnologia, balancear
os requisitos do gerenciamento clássico
de projetos e as necessidades de uma
equipe altamente capacitada e criativa é
mais uma arte que uma ciência”. Explica
De que se trata o artigo?
Este artigo apresenta o histórico, a definição, os
valores, os princípios e a estrutura de práticas do
Gerenciamento Ágil de Projetos.
Para que serve?
Abordagens ágeis de gerenciamento de projetos de
software surgiram com intuito de lidar com os prin-
cipais pontos fracos das abordagens tradicionais.
Conhecer estas alternativas ganha importância na
medida em que novos projetos surgem com carac-
terísticas diferenciadas que nos levam à necessida-
de de utilizar métodos mais “ágeis” para apoiar o
planejamento e acompanhamento das atividades
do projeto.
Em que situação o tema é útil?
Os projetos de desenvolvimento de software são
normalmente caracterizados por um elevado grau
de incertezas iniciais e, conseqüentemente, por
uma grande dificuldade de detalhamento do esco-
po e de elaboração de um planejamento completo.
Neste cenário de incertezas, abordagens ágeis para
gerenciamento de projetos de software têm sido
vistas como uma alternativa interessante. Conhe-
cer tais abordagens é um passo fundamental neste
cenário.

que, se por um lado o excesso de formalidade e de processos
tende a inibir a equipe e bloquear a inovação, por outro, a falta
de estrutura pode fazer com que os objetivos do projeto nunca
sejam atingidos.
Por muitos anos, o gerenciamento de projetos se desenvol-
veu sobre uma sólida plataforma, capaz de dar suporte a
diferentes tipos de projeto, nos mais variados ambientes. As
organizações adotaram o Gerenciamento Clássico de Proje-
tos, propuseram e implementaram melhorias e adaptações,
criando seus próprios modelos e expandindo a plataforma
clássica de gerenciamento de projetos (CHIN, 2004, p. 1-3). No
entanto, Chin (Ibid.) explica que, como qualquer plataforma, o
Gerenciamento Clássico de Projetos apresenta restrições e ao
se aproximar do limiar de sua abrangência, estas restrições
se tornam mais visíveis e o seu desempenho, menos efetivo.
Continuar o desenvolvimento desta plataforma clássica,
segundo o autor, em alguns momentos é mais difícil do que
estruturar uma nova idéia.
Neste contexto, Chin (2004, p. 1-3) propõe a criação de um
novo modelo e não uma simples expansão do Gerenciamen-
to Clássico de Projetos. O Gerenciamento Ágil de Projetos
surge, então, como uma nova plataforma de gerenciamento
de projetos (Figura 1), aplicável a ambientes voláteis e desa-
fiadores, sujeitos a mudanças frequentes, em que o processo
prescritivo e padronizado não mais se adéqua (CHIN, 2004,
p. 1-3; HIGHSMITH, 2004, p. 5).
Segundo Highsmith (2004) e Chin (2004), o Gerenciamento
Ágil de Projetos se desfaz da postura antecipatória, fortemen-
te calcada no planejamento prévio de ações e atividades, típica
do gerenciamento clássico de projetos, e busca o desenvolvi-
mento da visão do futuro e da capacidade de exploração.
Enfocando este último ponto, Highsmith (2004, p. 6) afirma
que são cinco os objetivos principais para um bom processo
de exploração, que acabam por constituir a base para o Ge-
renciamento Ágil de Projetos:
1. Inovação contínua: entrega de produtos que atendam aos
requisitos dos clientes e agreguem valor ao negócio. A ideia
de inovação é associada a um ambiente organizacional cuja
cultura estimule o autogerenciamento e a autodisciplina;
Extensões do
Gerenciamento de
Projetos
Plataforma Clássica do
Gerenciamento de
Projetos
Figura 1. Relacionamento entre as plataformas de gerenciamento clássico e ágil de projetos (FONTE: CHIN, 2004, p.3)
metodologias ágeis
2. Adaptabilidade do produto: os produtos desenvolvidos devem
não só oferecer valor ao cliente no presente, mas ser também
adaptáveis às novas necessidades do futuro;
3. Tempos de entrega reduzidos: foco, direcionamento preciso
e capacidade técnica da equipe são fundamentais para a re-
dução dos prazos de desenvolvimento de produtos visando
ao melhor aproveitamento das oportunidades de mercado e
um melhor retorno sobre o investimento;
4. Capacidade de adaptação do processo e das pessoas: formação de
equipes cujos integrantes estejam confortáveis com mudanças
e que não as enxerguem como obstáculos e sim como desafios
de um ambiente dinâmico; estabelecimento de processos que
respondam rapidamente às alterações do negócio;
5. Resultados confiáveis: entrega de produtos de valor ao
cliente, garantindo a operação, o crescimento e aumento da
lucratividade da empresa.
O Gerenciamento Ágil de Projetos pode ser visto como
uma resposta de âmbito gerencial às crescentes pressões por
constantes inovações, à concorrência acirrada, à necessidade
de redução dos ciclos de desenvolvimento e implantação de
novos produtos ou serviços e à necessidade de adaptação a
um ambiente de negócio bastante dinâmico (HIGHSMITH,
Ibid.).
Definição, Valores e Princípios do Gerenciamento
Ágil de Projetos
Highsmith (2004, p.16) define o Gerenciamento Ágil de
Projetos como “[...] um conjunto de valores, princípios e prá-
ticas que auxiliam a equipe de projeto a entregar produtos
ou serviços de valor em um ambiente desafiador”. Os valores
e os princípios descrevem o porquê do Gerenciamento Ágil
de Projetos e as práticas descrevem como realizá-lo. Apesar
de ratificar a necessidade de entregar produtos confiáveis
aos clientes dentro de restrições de prazo e custos, comum
ao Gerenciamento Clássico de Projetos, Highsmith (2004,
p. 6) menciona que o Gerenciamento Ágil de Projetos pode
ser considerado “mais uma atitude que um processo, mais
ambiente que metodologia”.
Redução de eficácia e eficiência
da plataforma clássica de
gerenciamento de projetos
Plataforma -
Gerenciamento
Ágil de
Projetos
Edição 20 - Engenharia de Software Magazine 23
 Os valores principais deste novo enfoque de gerenciamento
de projetos endereçam tanto a necessidade de criação e entrega
de produtos ágeis, adaptáveis e de valor, como a necessidade
de desenvolvimento de equipes de projeto com as mesmas
características (HIGHSMITH, 2004, p.10). Os quatro valores
centrais do Gerenciamento Ágil de Projetos são:
1. As respostas às mudanças são mais importantes que o se-
guimento de um plano;
2. A entrega de produtos está acima da entrega de
documentação;
3. Priorização da colaboração do cliente sobre a negociação
de contratos;
4. Os indivíduos e suas interações são mais importantes que
os processos e as ferramentas.
Com relação ao primeiro valor, Highsmith (2004, p. 10-11)
afirma que os projetos exploratórios, alvo do Gerenciamento
Ágil de Projetos, são caracterizados por processos que enfati-
zam a visão do futuro e a exploração, ao invés do planejamento
detalhado e a respectiva execução. Highsmith (Ibid.) e Chin
(2004, p. 1-3) mencionam que não se trata apenas de absorver
pequenas alterações de escopo, prazo ou custo, mas sim, de
dar abertura à mudança completa de planos, requisitos, tec-
nologia e arquitetura no decorrer do projeto. Highsmith (op.
cit.) embasa seu ponto de vista, ao apresentar o caso de uma
companhia que, erroneamente, se recusou a mudar o plano
traçado inicialmente para um projeto de desenvolvimento de
software, orçado em aproximadamente US$125 milhões, o que
a levou a um grande e custoso desastre. Para Highsmith (Ibid.),
“[…] planejar o trabalho e executar o plano” não é um lema
adequado a uma grande variedade de projetos, em especial
para os projetos de desenvolvimento de novos produtos (ou
software) ou àqueles relacionados a qualquer tipo de inova-
ção tecnológica. Esta posição está alinhada às proposições de
Thomsett (2002) e Chin (2004).
Abordando o segundo valor, ao estabelecer a prioridade da
entrega de produtos sobre a preparação de uma documentação
exaustiva, Highsmith (2004, p. 11-12) argumenta que não se
trata de menosprezar a importância da documentação, mas
sim de assumir que os resultados só podem ser avaliados
pela equipe de projeto e pelo cliente quando algo concreto é
apresentado, ou seja, quando se tem um produto (ou softwa-
re) operante. Highsmith (Ibid.) defende a manutenção de um
patamar mínimo e suficiente de documentação para auxiliar o
processo de comunicação e colaboração, propiciar a transferên-
cia de conhecimento, preservar a informação histórica, servir
de base para a melhoria de produtos e processos e, algumas
vezes, atender aos requisitos legais.
O terceiro valor, por sua vez, tem por pressuposto o esta-
belecimento de uma parceria entre o cliente e a equipe de
projeto, na qual cada um tem papéis e responsabilidades
específicos e bem definidos, sendo cobrados por isso. Esta
parceria deve ser marcada por uma forte colaboração e não
por disputas contratuais (HIGHSMITH, 2004, p. 13). Apesar
de reconhecer a existência de diferentes partes interessadas
24 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software
no projeto, Highsmith (Ibid.) menciona que o cliente deve
“reinar soberano” e apresenta a seguinte definição de clien-
te: “[...] um indivíduo ou grupo de indivíduos que usa os
produtos ou serviços para gerar valor ao negócio”.
Considerando o quarto valor, Highsmith (2004, p. 13-14)
afirma que os processos servem como guias ou trilhas e as
ferramentas são utilizadas para melhorar a eficiência, mas
sem pessoas com qualificações técnicas e comportamentais
adequadas, nenhum processo ou ferramenta produz resultado
algum. O movimento ágil deposita elevado valor no indivíduo e
reconhece sua capacidade de auto-organização, autodisciplina
e sua competência.
Enfocando o sucesso na ótica do Gerenciamento Ágil de
Projetos, Highsmith (2004, p. 27) menciona que o sucesso é
direcionado pelas pessoas e suas interações e não por pro-
cessos e estruturas. As competências e habilidades indivi-
duais, as interações entre pessoas ou equipes tecnicamente
qualificadas e a capacidade da equipe aprender e aplicar os
conhecimentos adquiridos são determinantes para o sucesso
ou o fracasso de um projeto, estando estritamente ligados ao
atendimento das expectativas do cliente. Como as pessoas são
normalmente guiadas por um conjunto interno de valores,
desenvolver a agilidade depende do perfeito alinhamento
entre o ambiente e este sistema de valor de cada indivíduo.
Esta é a razão pela qual o Gerenciamento Ágil de Projetos é
fortemente calcado em valores e também o motivo por que
muitas vezes é impossível a aplicação do Gerenciamento Ágil
de Projetos em determinadas organizações ou equipes (tal
como ocorre com a adoção dos Métodos Ágeis de Desenvol-
vimento de Software).
Além dos valores, o Gerenciamento Ágil de Projetos possui
um conjunto de princípios mestres, que norteiam sua apli-
cação. De acordo com Larson e LaFasto (1989), a liderança
baseada em princípios é uma das características mais impor-
tantes das equipes de alto desempenho. Highsmith (2004, p.
27-28) estabelece seis princípios, divididos em duas categorias
(Tabela 1), que auxiliam as equipes de projeto a determinar
como proceder, ou seja, ajudam-nas a definir quais práticas
são mais apropriadas, a gerar outras práticas quando neces-
sário, ou mesmo, a avaliar algumas que venham a surgir e
implementá-las com agilidade. Embora cada princípio seja
útil se aplicado isoladamente, o sistema formado por eles cria
um ambiente que encoraja e produz resultados mais efetivos
(HIGHSMITH, Ibid.).
Categoria Princípio
Entregar valor ao cliente
Valor ao cliente Gerar entregas iterativas e baseadas em funcionalidades
Buscar a excelência técnica
Encorajar a exploração
Estilo de gerenciamento baseado na Construir equipes adaptativas (auto-organizadas e
liderança e colaboração autodisciplinadas)
Simplificar
Tabela 1. Princípios do gerenciamento ágil de projetos (FONTE: ADAPTADO
DE HIGHSMITH, 2004, p. 27.)

Ciclo de Vida e Fases do Gerenciamento Ágil de Projetos
Apesar dos processos não serem tão importantes quanto
as pessoas no Gerenciamento Ágil de Projetos, isto não sig-
nifica que não se dê importância a eles. Highsmith (2004, p.
79) e Chin (2004, p. 14) defendem que não se deve atribuir
aos processos uma conotação negativa, vinculada ao excesso
de documentação e padronização, à característica estática
e prescritiva, difícil de ser mudada, conforme alardeiam
alguns seguidores do movimento ágil. Segundo os autores,
os processos, como qualquer outro elemento de uma organi-
zação, devem estar estritamente alinhados aos objetivos de
negócio. Em se tratando de operações contínuas e repetiti-
vas, processos prescritivos são plenamente justificáveis. Por
outro lado, se o ambiente for dinâmico e volátil, a estrutura
de processos deve ser orgânica, flexível e facilmente adap-
tável (HIGHSMITH, op. cit..; CHIN, op. cit.).
Sendo assim, a estrutura de processos para o Gerenciamento
Ágil de Projetos deve ter por foco o conceito de agilidade
e englobar os princípios apresentados no tópico anterior,
assim como assegurar o alcance dos objetivos de negócio.
Para tanto, deve:
• Favorecer a exploração e a cultura adaptativa;
• Permitir a auto-organização e a autodisciplina;
• Promover a confiabilidade e a consistência possíveis, dados
o grau de incertezas e a complexidade inerentes ao projeto;
• Ser flexível e facilmente adaptável;
• Permitir visibilidade ao longo do processo;
• Incorporar o aprendizado;
• Englobar as práticas específicas de cada fase;
• Prover pontos de verificação.
Segundo Udo e Koppensteiner (2003, p. 5) e Highsmith (2004,
p. 81), um projeto típico do Gerenciamento Ágil de Projetos
possui uma etapa inicial, seguida por vários ciclos ou itera-
ções. A cada ciclo é feito um novo planejamento de escopo,
prazo, custo e qualidade, visando à entrega de produtos ou
resultados e possibilitando incrementos de funcionalidades
conforme a necessidade do negócio. Ao final das várias
•Planejamento a cada iteração
•Incrementos de funcionalidades ;
Nível de Atividade
•Mudanças de escopo;
•Aceites ao final de cada iteração;
Planejamento
Preliminar
Início Iteração 1
Figura 2. Fluxo do gerenciamento ágil de projetos (FONTE: ADAPTADO DE UDO; KOPPENSTEINER, 2003, p. 5)
metodologias ágeis
iterações tem-se o término do projeto. Este padrão ou fluxo
típico dos projetos ágeis, bem como o nível de atividade,
são apresentados na Figura 2. Esta estruturação favorece a
entrega de valor e a geração de um ambiente que propicie o
aprendizado contínuo (UDO; KOPPENSTEINER, op. cit.).
O Gerenciamento Ágil de Projetos está estruturado em cinco
fases assim descritas (HIGHSMITH, 2004, p. 81):
1. Visão: compreende a determinação da visão do produto e
do escopo do projeto, a identificação da comunidade do pro-
jeto (clientes, gerente de projeto, equipe de projeto e outras
partes interessadas) e a definição de como a equipe de projeto
trabalhará em conjunto;
2. Especulação: engloba a identificação dos requisitos iniciais
para o produto, a definição das atividades, o desenvolvimento
de um plano de projeto (contendo entregas, marcos, várias
iterações, cronograma de trabalho e alocação de recursos),
a incorporação de estratégias para mitigação de riscos, as
estimativas de custos e outras informações financeiras rele-
vantes. Nesta etapa é elaborado um planejamento preliminar,
seguido por planejamentos específicos a cada iteração;
3. Exploração: corresponde à entrega dos produtos planejados,
através do gerenciamento da carga de trabalho e do emprego
de práticas e estratégias de mitigação de risco apropriadas.
Estas entregas são feitas sob a forma de incrementos de
funcionalidades do produto e são divididas entre os ciclos
do projeto;
4. Adaptação: compreende a revisão dos resultados entregues,
a análise da situação atual e a avaliação do desempenho da
equipe e do projeto, para eventual adaptação. Esta revisão
objetiva não apenas uma comparação do “realizado versus
planejado”, mas principalmente do “realizado versus informa-
ções e requisitos atualizados do projeto”, para a identificação
das mudanças necessárias;
5. Encerramento: referente à finalização das atividades do pro-
jeto, à transferência dos aprendizados-chave e à celebração.
O relacionamento entre estas fases pode ser visualizado na
Figura 3.
Controle
Contínuo
Iteração 2 Iteração 3 Iteração 4 Encerramento
Edição 20 - Engenharia de Software Magazine 25
 Visão
Visão
Escopo
Comunidade do projeto Plano de
Equipe do projeto entregas
Especulação Exploração

Ações de
adaptação Funcionalidades
complementares
Adaptação
Lista de
funcionalidades Produto final
Encerramento

Figura 3. Fases do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 81.)

Após a fase Visão, as fases Especulação, Exploração e Adaptação
se alternam a cada iteração, no intuito de refinar o produto do
projeto. A etapa de Especulação é retomada com objetivo de
planejar o novo ciclo, levando em consideração os resultados
até então alcançados no projeto e os incrementos ou alterações
de escopo solicitados até o momento. Algumas vezes, o retorno
à fase Visão pode ser necessário, em especial quando se têm
modificações muito significativas no escopo projeto. Uma vez
obtido o produto final, segue-se o Encerramento do projeto
(HIGHSMITH, 2004, p. 85).
(HIGHSMITH, 2004, p. 86). O autor, entretanto, é avesso à ideia
da adoção de “melhores práticas”, ao afirmar que as práticas
são apenas maneiras de se executar algo e que podem ser
boas ou ruins, a depender do contexto em que estão inseridas.
Highsmith (Ibid.) menciona que as práticas do Gerenciamento
Ágil de Projetos se mostram úteis em uma grande diversidade
de situações e que também podem ser aplicadas no Gerencia-
mento Clássico de Projetos. Por outro lado, admite que outras
práticas, não mencionadas no modelo em questão, podem
trazer benefícios aos projetos ágeis.

Práticas do Gerenciamento Ágil de Projetos Práticas da Fase Visão

Assim como o PMI (2004) sugere uma série de processos de
gerenciamento de projetos, para cada fase do Gerenciamen-
to Ágil de Projetos existe um conjunto de práticas, que em
sua totalidade, formam um sistema de práticas. Este sistema
não só alinha os valores e os princípios do Gerenciamento
Ágil de Projetos, mas permite também a sua implementação
O propósito da fase Visão é identificar de maneira clara “o
que” precisa ser feito e “como” o trabalho será realizado. Para
tanto, suas práticas estão estruturadas em quatro categorias:
visão do produto, escopo do projeto, comunidade do projeto e abor-
dagem (HIGHSMITH, 2004, p. 88-92), que são apresentadas na
Tabela 2.

Categoria Prática Descrição

Visão do produto Visão do produto e “declaração de elevador” Desenvolvimento de um conceito de alto nível do produto do projeto, de uma forma concisa e
visual, com a utilização de um texto simples, garantindo a uniformidade de entendimento e de
discurso entre todos os envolvidos no projeto
Arquitetura do produto Desenvolvimento de uma arquitetura técnica do produto, que facilite a exploração e assegure
um direcionamento à condução dos trabalhos e à organização da equipe de projeto, visando ao
atendimento das expectativas dos clientes
Escopo do projeto (objetivos e restrições) Folha de dados do projeto Elaboração de um documento que sumarize os pontos-chave do projeto em termos de escopo,
prazo, custos, recursos, qualidade e riscos
Comunidade do projeto Escolha das pessoas certas Montagem da equipe do projeto e definição de sua organização, buscando sempre atrair e
selecionar os melhores talentos
Identificação dos participantes Identificação de todas as partes interessadas no projeto, de forma a melhor entender e
gerenciar suas expectativas
Interface entre a equipe do cliente e a equipe do projeto Estabelecimento do processo de colaboração entre a equipe do projeto e a equipe do cliente
Abordagem Adaptação de processos e práticas Definição de uma estrutura de processos e práticas com base em uma estratégia de auto-
organização, que estabelece a forma de trabalho em conjunto da equipe do projeto
Tabela 2. Práticas da fase “Visão” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 92-124.)

26 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software

 metodologias ágeis

Práticas da Fase Especulação
Segundo Highsmith (2004, p. 128-131), a fase Especulação tem por
objetivo a elaboração de um plano de entregas que represente o
melhor entendimento da equipe de projeto, em um dado momen-
to do projeto. A utilização da palavra especulação no lugar de
planejamento está estritamente relacionada ao reconhecimento
do elevado grau de incertezas e de mudanças que caracteriza
um projeto-alvo do Gerenciamento Ágil de Projetos. O plano
resultante desta etapa é construído a partir de informações da
especificação e da arquitetura do produto, dos riscos envolvidos,
do padrão de qualidade ou do nível de defeito estabelecido, das
restrições do negócio e dos marcos do projeto.
As práticas de fase Especulação, repetidas a cada ciclo ou
iteração, são divididas em duas categorias: estrutura analítica
do produto e planejamento de entregas (HIGHSMITH, 2004, p.
132-164), sendo retratadas na Tabela 3.
Práticas da Fase Exploração
A fase Exploração visa a entrega dos produtos planejados, a
cada ciclo do projeto, através do gerenciamento da carga de
trabalho e do emprego de práticas e estratégias de mitigação de
risco apropriadas (HIGHSMITH, 2004, p. 166-168). De acordo
com Highsmith (Ibid.) e Chin (2004, p. 69-81), �����������������
a essência do pa-
pel do gerente de projetos no Gerenciamento Ágil de Projetos
não é a elaboração de um cronograma detalhado e a preparação
dos relatórios de progresso (apesar de ambos fazerem parte de
seu trabalho), mas sim a criação e o desenvolvimento de uma
equipe de alto desempenho a partir de um grupo de pessoas
e estabelecer um estilo de liderança e gerenciamento que en-
coraje a inovação e incentive a aceitação de situações de risco
e de mudanças constantes.
Neste contexto, Highsmith (2004, p. 169-209) propõe um con-
junto de práticas divididas em três categorias: entrega segundo os
objetivos, práticas técnicas e comunidade do projeto. Estas práticas
podem ser visualizadas na Tabela 4.
Prática da Fase Adaptação
Se no cenário do Gerenciamento Ágil de Projetos os planos
são especulações acerca do futuro, então é grande a necessida-
de de feedbacks frequentes e efetivos para a validação das hipó-
teses assumidas (HIGHSMITH, 2004, p. 213-215). As adaptações
dependem do manuseio e entendimento de uma vasta gama
de informações, que incluem o progresso do projeto, os riscos
técnicos, a evolução dos requisitos do produto e a análise do
mercado. A equipe de projeto deve avaliar e tomar decisões
constantes sobre quatro pontos principais:
• Funcionalidades primárias, segundo a perspectiva da equipe
do cliente;
• Qualidade do produto, de acordo com as perspectivas da
equipe técnica;
• Desempenho da equipe do projeto;
• Progresso do projeto.
A fase Adaptação possui apenas uma prática – revisão do
produto / projeto / equipe e ações de adaptação – divida em várias
subpráticas, como mostra a Tabela 5 (HIGHSMITH, 2004, p.
211-231).
Prática da Fase Encerramento
O Encerramento do projeto é tanto uma fase como uma prá-
tica. Como recursos humanos qualificados são normalmente
escassos, há uma forte tendência por parte das organizações

Categoria Prática Descrição

Estrutura analítica do produto
Planejamento das entregas
Tabela 3. Práticas da fase “Especulação” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 131-164.)
Categoria
Entrega segundo os objetivos
Práticas técnicas
Comunidade do projeto
Tabela 4. Práticas da fase “Exploração” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 169-209.)
Lista de funcionalidades do produto
Cartões de funcionalidades
Cartões de requisitos de desempenho
Plano de entregas, marcos e iterações
Prática
Gerenciamento da carga de trabalho
Mudanças de baixo custo
Aconselhamento e desenvolvimento da equipe
Reuniões diárias de integração da equipe de projeto Realização de reuniões de integração com a equipe de projeto visando a coordenação diária das
Decisões participativas
Interações diárias com o cliente
Expansão da visão do produto, através da definição de seus requisitos, gerando uma lista de funcionalidades do produto
Criação de um documento padrão para o registro das funcionalidades e requisitos do produto e das estimativas
de prazo para seu desenvolvimento
Documentação dos requisitos de desempenho e operação do produto a ser entregue
Desenvolvimento de um plano que apresente o caminho a ser seguido pela equipe de projeto para entregar o
produto do projeto, de acordo com os objetivos de escopo, prazo e restrições delineadas na Folha de Dados do
Projeto. São planejados vários ciclos ou iterações para refinamento do produto do produto final do projeto
Descrição
Atribuição da responsabilidade pelo gerenciamento das atividades do dia-a-dia, necessárias para a
entrega das funcionalidades a cada iteração, aos próprios integrantes da equipe de projeto
Redução dos custos das mudanças ao longo das diferentes fases do ciclo de vida do produto, alinhada à
necessidade de entrega de valor ao cliente “hoje”, mas com vistas ao futuro
Desenvolvimento contínuo das competências, habilidades e domínio técnico e de negócio dos integrantes
da equipe de projeto, enfatizando a autodisciplina e o espírito de equipe
atividades do projeto
Fornecimento à comunidade do projeto de práticas específicas para entender, analisar e/ou tomar
decisões ao longo do projeto
Realização de reuniões ou interações diárias com o cliente para garantir que os esforços do projeto sejam
executados de forma a atender às suas expectativas

Edição 20 - Engenharia de Software Magazine 27

 Prática Descrição
Revisão do produto / projeto / equipe e O objetivo desta prática é garantir que o feedback - Grupo de foco com cliente
ações de adaptação constante e o aprendizado de alto nível ocorram em - Revisões técnicas
todas as dimensões do projeto.
Tabela 5. Práticas da fase “Adaptação” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 211-231.)
Várias organizações interessadas;
externas
Projetos operacionais Gerenciamento Clássico de Projetos
Projetos de desenvolvimento de novos produtos / Gerenciamento Clássico de Projetos / Gerenciamento Clássico de Projetos / Gerenciamento Ágil de Projetos
processos Gerenciamento Ágil de Projetos
Projetos de desenvolvimento de novas tecnologias / Gerenciamento Clássico de Projetos / Gerenciamento Ágil de Projetos
plataformas Gerenciamento Ágil de Projetos
Tabela 6. Aplicabilidade do gerenciamento ágil de projetos (FONTE: CHIN, 2004, p. 20.)
de transferi-los rapidamente para outra iniciativa, quando
do término de um projeto, sem estes profissionais recebam,
ao menos, os créditos pela realização. Entretanto, há várias
atividades a serem realizadas na etapa final de um projeto.
A primeira delas é a celebração, que tem dois propósitos
fundamentais: reconhecer aqueles que trabalharam muito
para que o projeto fosse entregue e marcar o encerramento
do projeto. A segunda, menos glamorosa, diz respeito à
limpeza de eventuais itens em aberto, à entrega da docu-
mentação final e à preparação dos relatórios financeiros e
administrativos requeridos. Por fim, tem-se a condução de
uma retrospectiva do projeto, visando à obtenção e à di-
vulgação das lições aprendidas entre as equipes de projeto
(HIGHSMITH, 2004, p. 231-232).
O encerramento de um projeto, seja ele gerenciado segundo
a abordagem ágil ou clássica, é fundamental e marca a tran-
sição do produto do projeto para a operação da organização
(HIGHSMITH, Ibid.).
Aplicações, Resultados e Limitações do Gerenciamento
Ágil de Projetos
Diferentemente dos Métodos Ágeis de Desenvolvimento de
Software, não foram encontrados estudos analisando a eficá-
cia, ou mesmo fornecendo indícios de resultados positivos (ou
negativos) da aplicação do Gerenciamento Ágil de Projetos.
Uma explicação para tal situação pode ser atribuída ao fato de
o assunto ser bastante recente. O que se têm são indicações de
alguns autores, como Thomsett (2002), Highsmith (2004) e Chin
(2004), acerca dos potenciais de aplicação deste novo enfoque
de gerenciamento de projetos.
Highsmith (op. cit.) e Chin (op. cit.) sugerem a aplicação do
Gerenciamento Ágil de Projetos em projetos de desenvolvi-
mento de novos produtos, ou outros que requeiram alto grau
28 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software
Subprática
- Avaliação do desempenho da equipe do projeto
- Relatório de progresso do projeto
- Acompanhamento do escopo e do valor do trabalho realizado1 a cada iteração
- Acompanhamento do cronograma de cada iteração
- Acompanhamento dos custos e da utilização dos recursos (custo estimado ao término do projeto)
- Acompanhamento da qualidade do produto do projeto
- Informação à equipe do projeto
- Ações de adaptação
Várias organizações interessadas;
Uma única organização interessada
internas
Gerenciamento Clássico de Projetos Gerenciamento Clássico de Projetos
Gerenciamento Ágil de Projetos
Gerenciamento Ágil de Projetos
de inovação, criatividade, que envolvam tecnologia de ponta,
equipes de alto desempenho, que estejam sujeitos a incertezas
ou inseridos em ambientes de negócio dinâmicos. Highsmith
(2004, p. 4) indica formalmente o uso do Gerenciamento Ágil
de Projetos para o desenvolvimento de software.
Chin (2004, p. 13-21) propõe um modelo, apresentado na Ta-
bela 6, para a verificação da aplicabilidade do Gerenciamento
Ágil de Projetos, levando-se em consideração duas dimensões-
chave, a saber:
• Tipo de projeto: projetos operacionais (projetos simples e que
ocorrem regularmente na organização); projetos de desen-
volvimento de novos produtos / processos; ou projetos de
desenvolvimento de novas tecnologias / plataformas;
• Organizações envolvidas: apenas uma organização interessada
no projeto; várias organizações internas interessadas no proje-
to; ou várias organizações externas interessadas no projeto.
Nas áreas onde há a possibilidade de escolha, Chin (Ibid.)
sugere que seja feita uma análise do contexto interno e externo,
considerando aspectos culturais e a prontidão da organização
e dos principais interessados no projeto para a adoção de um
enfoque ágil, antes da definição da melhor abordagem. Esta
colocação de Chin (Ibid.) é corroborada por Highsmith (2004)
e considera as ponderações de Ambler (2002c), Cohen et al,
2003; Fowler (2003) e Nerur et al (2005). Isto porque tanto os
Métodos Ágeis como o Gerenciamento Ágil de Projetos fo-
ram construídos sobre bases, valores e princípios similares e
ambos pressupõem que as organizações estejam preparadas
do ponto de vista cultural, organizacional e gerencial para a
sua adoção.
Apesar de não haver na literatura menção específica às
limitações do Gerenciamento Ágil de Projetos, as ressalvas
feitas por Turk et al (2005) e Nerur et al (2005) com relação aos

Métodos Ágeis, em especial quanto à participação dos clientes,
à questão da negociação de contratos, ao suporte a equipes de
projeto distribuídas e à dependência da organização perante
os integrantes da equipe de projeto, podem ser transpostas
para o Gerenciamento de Projetos, dados os valores e princí-
pios comuns.
Cabe fazer uma ressalva, porém, quanto ao tamanho do
projeto. Highsmith (2004, p. 85) afirma que os valores e os
princípios do Gerenciamento Ágil de Projetos são aplicáveis a
projetos de qualquer envergadura e, similarmente, as práticas
podem ser empregadas em projetos de diversos tamanhos,
havendo somente a necessidade de adaptação para equipes
com mais de 50 integrantes.
Comparação: Gerenciamento Clássico e
Gerenciamento Ágil de Projetos
Para finalizar a explanação sobre o Gerenciamento Ágil de
Projetos é interessante o estabelecimento de uma comparação
entre ele e o Gerenciamento Clássico de Projetos. Um possível
alinhamento entre os enfoques clássico e ágil de gerenciamen-
to de projetos pode ser feito através da comparação entre as
principais características dos grupos de processos propostos
pelo PMI (2004) – Iniciação, Planejamento, Execução, Monitora-
mento e Controle e Encerramento – e as fases do Gerenciamento
Ágil de Projetos – Visão, Especulação, Exploração, Adaptação e
Encerramento (HIGHSMITH, 2004). Esta comparação tem por
base o trabalho de Udo e Koppensteiner (2003, p. 3), sendo seu
resultado apresentado na Tabela 7.
A partir das informações da Tabela 7 acima e do exposto
ao longo deste artigo, é possível verificar que as diferenças
fundamentais entre o Gerenciamento Clássico de Projetos e o
Gerenciamento Ágil de Projetos residem fundamentalmente
em dois pontos: na relação “Planejamento x Especulação” e
na dualidade “Monitoramento e controle x Adaptação” (UDO;
KOPPENSTEINER, 2003; HIGHSMITH, 2004; CHIN, 2004).
O Gerenciamento Clássico de Projetos, estruturado se-
gundo uma visão de processos, conforme descrito pelo PMI
(2004) e, anteriormente, defendido por autores como Verzuh
(1999), Kerzner (2002), Maximiano (2002), Dinsmore e Neto
(2004), entre outros, deposita uma grande importância no
planejamento detalhado do projeto e nos processos formais de
monitoramento e controle. Por outro lado, no Gerenciamento
Ágil de Projetos, a ênfase é transferida do planejamento para
a execução, visando à entrega rápida de valor ao cliente e à
Grupo de Processos do Gerenciamento Clássico de Processos
Iniciação: Autorização de um novo projeto ou fase e definição do escopo preliminar do projeto
Planejamento: Planejamento integral e detalhado do projeto
Execução: Execução do plano do projeto
Monitoramento e Controle: Ênfase no controle do progresso dos trabalhos e no controle e Adaptação: Revisão dos resultados entregues e abertura para adaptações do escopo, visando o atendimento
gerenciamento de mudanças para minimizar os impactos no projeto
Encerramento: Formalização do aceite final do projeto
Tabela 7. Alinhamento entre os enfoques ágil e clássico de gerenciamento de projetos (FONTE: ADAPTADO DE KOPPENSTEINER e UDO, 2003, p. 3.)
metodologias ágeis
apresentação de resultados ao longo de todo o projeto; e do
controle para adaptação, permitindo alterações substanciais de
escopo a cada iteração, para atender às mudanças de requisitos
do negócio (THOMSETT, 2002; UDO; KOPPENSTEINER, 2003;
CHIN, 2004; HIGHSMITH, 2004).
Com relação às áreas de conhecimento, também é possível
traçar um paralelo entre Gerenciamento Clássico de Projetos
e o Gerenciamento Ágil de Projetos, em uma adaptação do
trabalho de Udo e Koppensteiner (2003, p. 6). A avaliação,
apresentada na Tabela 8, aponta que praticamente todas as
áreas de conhecimento são abordadas pelo Gerenciamento
Ágil de Projetos, porém com um enfoque diferenciado, dada
sua ênfase na entrega de valor ao cliente, na resposta rápida às
necessidades de mudanças e na valorização do indivíduo.
Considerações Finais
Os projetos de desenvolvimento de software são normal-
mente caracterizados por um elevado grau de incertezas
iniciais e, consequentemente, por uma grande dificuldade de
detalhamento do escopo e de elaboração de um planejamento
completo. Novos processos de negócio, linguagens de progra-
mação, ferramentas, arquiteturas e aplicações inovadoras são
constantemente introduzidos. Muitos autores afirmam que
neste cenário, ciclos rápidos de especificação, teste, validação
e implantação podem produzir resultados mais vantajosos que
o desenho e o planejamento integral de todo o projeto (AUER;
MILLER, 2002; BECK, 2000; BECK; FOWLER, 2001; JEFFRIES
et al, 2001; CHIN, 2004; COCKBURN, 2001; SCHAWABER,
2002; SCHWABER; BEEDLE 2001; HIGHSMITH, 2002; 2004;
POPPENDIECK; POPPENDIECK, 2003; AMBLER, 2002a;
COHEN et al, 2003; FOWLER, 2003; UDO; KOPPENSTEINER,
2003). Várias iterações em curtos períodos de tempo tendem a
maximizar o aprendizado da organização e a potencializar o
desenvolvimento da equipe de projeto.
Cohen et al (2003, p. 46-47) escreve que “[...] indubitavelmente
os Métodos Ágeis vieram para ficar”. Entretanto, estes autores,
assim como outros (PAULK, 2001; GLASS, 2001; THOMSETT,
2002; UDO; KOPPENSTEINER, 2003; HIGHSMITH, 2004) acre-
ditam que este novo enfoque não ocupará totalmente o espaço
dos modelos clássicos de desenvolvimento de software, mas
sim que as duas abordagens deverão trabalhar em sintonia
(simbiose) no futuro. Embora alguns praticantes enxerguem
uma grande distância entre os métodos ágeis e os clássicos,
outros acreditam que se pode construir uma ponte entre eles,
Fases do Gerenciamento Ágil de Projetos
Visão: Determinação da visão do produto e do escopo inicial do projeto
Especulação: Desenvolvimento de um plano inicial do projeto, seguido por planejamentos individuais a cada iteração
Exploração: Entrega das funcionalidades / produtos previstos a cada ciclo
aos novos requisitos do negócio
Encerramento: Aceites do cliente a cada ciclo ou iteração e formalização do encerramento do projeto ao final
dos trabalhos
Edição 20 - Engenharia de Software Magazine 29
 Áreas de Conhecimento
Gerenciamento da Integração do projeto
Gerenciamento do escopo do projeto
Gerenciamento de tempo do projeto
Gerenciamento de custos do projeto
Gerenciamento da qualidade do projeto
Gerenciamento de recursos humanos do projeto
Gerenciamento das comunicações do projeto
Gerenciamento de riscos do projeto
Gerenciamento das aquisições do projeto
Tabela 8. Comparação dos enfoques clássico e ágil de gerenciamento de projetos por área de conhecimento (FONTE: ADAPTADO DE UDO;
KOPPENSTEINER, 2003, p. 6.)
Gerenciamento Clássico de Projetos Gerenciamento Ágil de Projetos
Assegura a coordenação dos vários elementos do projeto A necessidade de coordenação formal é limitada devido à redução a nível
mínimo de estrutura e de processos
Assegura que o projeto contenha apenas o trabalho necessário para O escopo é fixo apenas quando as iterações estão em andamento. Não há
completá-lo de forma bem-sucedida. Foco na definição e controle do que controle formal do escopo ao longo do projeto, havendo a possibilidade de
está ou não está incluído no escopo do projeto e em um processo bem inclusão / alteração das funcionalidades do produto em cada iteração
estruturado de gerenciamento de mudanças
Foco na definição das atividades e estimativas de tempo para a elaboração O prazo é estabelecido apenas por iteração ou ciclo. Foco na entregar valor
do cronograma detalhado do projeto e no controle, para assegurar a (funcionalidades) o mais rapidamente possível. O cronograma geral é
finalização do projeto no prazo baseado em funcionalidades e não em atividades
Foco na elaboração do orçamento do projeto a partir da necessidade de Determinação do orçamento em função da funcionalidade do produto
recursos humanos e materiais e no controle, para garantir que o projeto seja requisitada. Os recursos, as funcionalidades e os prazos são balanceados e
encerrado dentro do orçamento aprovado há uma preocupação em medir o custo por atraso
Assegura que o projeto atenda às necessidades para as quais foi concebido. O sucesso do projeto é definido pelo cliente, que também apresenta seu
Foco na conformidade e na adequação às especificações e na satisfação das parecer ao final de cada iteração. Foco na execução da visão e do propósito
expectativas das partes interessadas no projeto do produto e na adequação ao uso
Processos para que se faça o uso mais efetivo de todas as partes interessadas Foco na equipe e não no indivíduo. Busca o desenvolvimento de equipes de
no projeto alto desempenho. Os incentivos são baseados na produtividade do grupo
Assegura a geração, a coleta, a disseminação e o armazenamento periódicos Foco na eliminação de gastos e de todas as padronizações, documentações
das informações do projeto e relatórios desnecessários. Garantia de acesso às informações a todos os
envolvidos no projeto
Foco na identificação, na análise e na proposição de respostas aos riscos do Não há uma maneira padrão sugerida para o tratamento de riscos. Cada
projeto projeto deve adotar a sua própria abordagem
Foco na aquisição de produtos ou serviços externamente à organização Segue os melhores princípios para aquisição de bens ou serviços dando
executora, para a realização do projeto maior ênfase à colaboração (estabelecimento de parcerias) do que à
negociação de contratos

possibilitando a troca constante de informações e experiên-
cias e, consequentemente, um aprimoramento do processo de
desenvolvimento de software.
Glass (op. cit.) destaca que os defensores dos métodos clássicos
têm muito a aprender com os adeptos dos métodos ágeis, ar-
gumentando que o processo clássico de desenvolvimento pode
ser enriquecido com a utilização de algumas das práticas pro-
postas pelos Métodos Ágeis. Em contrapartida, uma das razões
para que os Métodos Ágeis não se sobreponham totalmente ao
desenvolvimento clássico de software é que alguns processos
“antigos” ainda se fazem necessários. Lindvall e Russ (2000)
ilustram esta diferença ao mencionar que “ [...] desenvolver
um software para controlar um ônibus espacial não é o mesmo
que desenvolver um software para um torradeira”. Cohen et al
(2003, p. 45) complementam que aplicações que possam vir a
colocar em risco a vida humana devem passar por um rígido
controle de qualidade, sendo o enfoque clássico preferido para
seu desenvolvimento.
Com relação ao gerenciamento de projetos, as pondera-
ções seguem a mesma linha. O fato dos Métodos Ágeis de
Desenvolvimento de Software e do Gerenciamento Ágil de
Projetos terem a mesma origem e serem construídos sobre os
mesmos valores e princípios pode sugerir que, possivelmente,
o Gerenciamento Ágil de Projetos seja mais indicado para o
gerenciamento de software realizado com o uso de Métodos
Ágeis. Contudo, cabe salientar que não foram encontradas
evidências durante a revisão bibliográfica que comprovassem
(ou negassem) tal afirmação.
Thomsett (2002), Highsmith (2004) e Chin (2004) indicam
a utilização do Gerenciamento Ágil de Projetos em projetos
que requerem inovação e criatividade ou que estejam sujeitos
a alterações constantes dos requisitos do negócio, como por
exemplo, os projetos de desenvolvimento de novos produtos
(o desenvolvimento de software se enquadra nesta categoria).
Mas apesar de mencionarem que o Gerenciamento Clássico de
Projetos traz uma rigidez indesejada a projetos desta natureza,
estes autores reconhecem a importância do arcabouço de co-
nhecimentos aportado por este enfoque de gerenciamento de
projetos, chegando a afirmar que, em determinadas situações,
uma combinação do enfoque clássico com as novas práticas
propostas pelo Gerenciamento Ágil de Projetos é mais apro-
priada para que se alcance resultados cada vez efetivos.
Expandindo esta visão, Thomsett (op. cit.) chega a mencionar
que as práticas do Gerenciamento Ágil de Projetos podem
ser utilizadas até mesmo no desenvolvimento de software
conduzido segundo um método clássico. Num contraponto,
Paulk (2001) cita que os Métodos Ágeis e o SW-CMM (que
tem por base o Gerenciamento Clássico de Projetos) não são
incompatíveis, sugerindo que o Gerenciamento Clássico de
Projetos pode ser aplicado no desenvolvimento de software
realizado com o uso de Métodos Ágeis. Enfim, não há uma
opinião única sobre o assunto.

30 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software

 metodologias ágeis

Todavia, é consenso entre os autores pesquisados que se deve os benefícios de sua utilização, investigando diretamente a
fazer uma análise do ambiente interno (aspectos organizacio- questão relativa ao enfoque de gerenciamento de projetos
nais e culturais) e do contexto externo no qual o projeto está mais apropriado para o desenvolvimento de software com
inserido, para que se selecione o modelo de gerenciamento de o uso de Métodos Ágeis, o que aumenta a motivação para o
projetos (clássico ou ágil) e se defina o método de desenvolvi- desenvolvimento deste estudo.
mento (clássico ou ágil) e o respectivo conjunto de processos,
técnicas, ferramentas ou práticas a serem seguidos (AMBLER,
Dê seu feedback sobre esta edição! Feedback
2002c; THOMSETT, 2002; COHEN et al, 2003; COHN; FORD, eu

s
Dê
2003; FOWLER, 2003; UDO; KOPPENSTEINER, 2003; HIGHS- A Engenharia de Software Magazine

sobre e
MITH 2004; CHIN, 2005; NERUR et al, 2005). tem que ser feita ao seu gosto.

s
ta
Por serem assuntos relativamente novos (os primeiros Méto-
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
dos Ágeis, ainda incipientes, surgiram no final dos anos 90 e o Dê seu voto sobre este artigo, através do link:
embrião do Gerenciamento Ágil de Projetos surgiu em 2001),
www.devmedia.com.br/esmag/feedback
pouquíssimas são as pesquisas empíricas que versam sobre

Referências

ABRAHAMSSON, P et al. New directions on agile methods: a comparative analysis. In: Proceedings of the BOOCH, G. Developing the future. Communications of the ACM. ACM Press, [S.l.], v. 44, n. 3, p.
25th International Conference on Software Engineering. [S.l.]. IEEE Software Society, 2003, p. 244-254. 118–121, 2001.

AGILE ALLIANCE. Manifesto for agile software development. Disponível em <http://www. CHIN, Gary. Agile project management: how to succeed in the face of changing project
agilemanifesto.org/>. Acesso em janeiro, 2005. requirements. NY: Amacon, 2004.

AUER, K.; MILLER, R. Extreme programming applied. Boston: Addison-Wesley, 2002. COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Addison-
Wesley, 2004.
AMBLER, S. W. Agile modeling: effective practices for extreme programming and the unified
process. John Wiley & Sons, Inc., 2002a. ______. Agile software development. Boston: Addison-Wesley, 2001.

AMBLER, S.W. Lessons in agility from internet-based development. IEEE Software, [S.l.], v. 19, n. ______. Learning from agile software development – part one. Crosstalk, The Journal of Defense
2, 2002b, p. 66–73. Software Engineering, [S.l.], October 2002.

AMBLER, S.W. When does(n´t) agile modeling make sense. Apr, 2002c. Disponível em <http:// COCKBURN, A.; HIGHSMITH, J. Agile software development: the business of inovation. IEEE
www.agilemodeling.com/essays/whendoesAmWork.htm>. Acesso em julho de 2005. Computer Magazine, [S.l.], p. 131-133, sep 2001a.

AMBLER, S. W. Quality in an agile world. Software Quality Professional, [S.L.], v. 7, n. 4, sep. 2005.
BECK, K. Embrance Change with Extreme Programming. IEEE Computer Magazine, [S.l.], Oct 1999,
p. 70-77.
______. Extreme programming explained. Boston: Addison-Wesley, 2000.
BECK,Kent.et al.Chrysler goes to“extremes”.Oct,1998.Disponível em <http://www.xprogramming.
com/publications/dc9810cs.pdf>. Acesso em julho, 2005.
BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em <http://
www.agilemanifesto.org/>. Acesso em janeiro, 2005.
BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001.
______. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-
133, nov 2001b.
COHEN, David et al. Agile software development: a DACS state of art report. NY: Data Analysis
Center for Software - Fraunhoufer Center for Experimental Software Engineering Maryland and
The University of Maryland, 2003. Disponível em <http://www.thedacs.com/techs/agile/>.
Acesso em abril, 2005.
COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA executivo. Trad. Afonso Celso da
Cunha Serra. Rio de Janeiro: Campos, 2002.
COHN, Martin. The scrum development process. Disponível em <www.mountaingoatsoftware.
com/scrum> Acesso em julho, 2005.

BECK, Kent; MEE, R. Enhancing brazilian software’s global competitiveness. Jan, 2003. Disponível COHN, Martin; FORD, Doris. Introducing an agile process to an organization. IEEE Computer
em: <http://www.xispe.com.br/wiki/wiki.jsp?topic=EnhancingBrazilsSoftwareGlobalCompetiti Magazine, June 2003, [S.l.], p. 74-78.
veness>. Acesso em novembro, 2004.
DINSMORE, P. C. The AMA handbook of project management. New York: AMACON, 1993.
BOGER, M. et al. Extreme modeling. In: SUCCI, G.; Marchesi, M. (eds). Extreme programming
DINSMORE, P. C.; NETO, F. H. S. Gerenciamento de projetos: como gerenciar seu projeto com
examined. Boston: Addison-Wesley, 2001.
qualidade, dentro do prazo e custos previstos. Rio de Janeiro: Qualitymark, 2004.
BOHEM, Barry.;TURNER, Richard. Balancing discipline and agility: evaluating and integrationg plan-
FOWLER, Martin. The new methodology. April, 2003. Disponível em <http://www.martinfowler.
driven methods. In: Proceedings of the 26th Conference on Agile Development. IEEE COMPUTER
com/articles/newMethodology.html>. Acesso em julho, 2005.
SOCIETY, [S.l.], May 2004, p. 718-719.
GAWLAS, J. Mission critical development with XP & agile process: common code ownership and
BONATO, A. S. F. Uma experiência de aplicação do processo Extreme Programming em pequenos
lots of testing. Dr. Dobb´s Journal, [S.l.], p. 21-24, Jan. 2004.
projetos. São Paulo, 2004. Dissertação (Mestrado em Engenharia) – Programa de Pós-Graduação
em Engenharia, Escola Politécnica da Universidade de São Paulo.

Edição 20 - Engenharia de Software Magazine 31

 Continuação: Referências

GLASS, Robert. Extreme programming: the good, the bad and the bottom line. IEEE Software, [S.l.], ______. Agile methodologies and process discipline. Crosstalk - The Journal of Defense Software
Nov. 2001, p. 111-112. Engineering, [S.l.], v. 15, n. 10, p. 15–28, Oct. 2002.

GIGA INFORMATION GROUP. Lessons learned practicing agile development. Boston: Giga Group, POOLE, C.; HUISMAN, J. W. Using extreme programming in a maintenance environment. IEEE
Apr. 2002. Software Computer, [S.l.], v. 18, n. 6, p. 42–50, 2001.

GLAZER, H. Dispelling the process myth: having a process does not mean sacrificing agility or
criativity. Crosstalk, The Journal of Defense Software Engineering, [S.l.], Nov. 2001.
HIGHSMITH, Jim. Adaptative management: patterns for the e-business era. Cutter IT Journal, [S.l.],
v. XII, n. 9, sep. 1999.
POPPENDIECK. M. Lean programming. Software Development Magazine. May-June, 2001
Disponível em <http://www.agilealliance.org/articles/articles/LeanProgramming.htm>. Acesso
em julho, 2005.
POPPENDIECK. M.; POPPENDIDIECK. T. Lean software development. Boston: Addison-Wesley, 2003.

HIGHSMITH, Jim. Agile software development ecosystems. Boston: Addison-Wesley, 2002. PROJECT MANAGEMENT INSTITUTE - PMI. PMBOK guide: Um guia do conjunto de conhecimentos
do gerenciamento de projetos. Pennsylvania: Project Management Institute, 2000 ed, 2000.
______. Agile project management: creating innovative products. Boston: Addison-Wesley, 2004.
______. OMP3: Organizational project management maturity model. Pennsylvania: Project
HIGHSMTIH, Jim et al. Extreme programming: e-business application delivery. Feb. 2002. Disponível
Management Institute, 2003.
em <http://www.cutter.com/freestuff/ead0002.pdf>. Acesso em julho, 2004.
______. Guia PMBoK: Um guia do conjunto de conhecimentos do gerenciamento de projetos.
JEFFRIES, R. et al. Extreme programming installed. Boston: Addison-Wesley, 2001.
Pennsylvania: Project Management Institute, 3. ed, 2004.
KERZNER, Harold. Project Management: a systems approach to planning, scheduling and
______. São Paulo, Brasil Chapter, 2005. Disponível em <http://www.pmisp.org.br/home.asp>.
controlling. New York: Van Nostrand Reinhold, 1992.
Acesso em setembro, 2005.
______. Gestão de Projetos: as melhores práticas. Trad. Marco Antonio Viana Borges, Marcelo
SCHWABER, K.; BEEDLE, M. Agile software development with scrum. NJ: Pretence Hall, 2001.
Klippel e Gustavo Severo de Borba. Porto Alegre: Bookman, 2002.
SCHWABER, K. Controlled chaos: living on the edge. 2002. Disponível em <http://www.
LARSON, Carl E.; LAFASTO, Frank M. J.Teamwork: What must go right, what can go wrong. Newberry
agilealliance.org/articles/articles/ap.pdf>. Acesso em junho, 2005.
Park, CA: Sage, 1989
SUTHERLAND, J. Agile can scale: inventing and reinventing scrum in five companies. Cutter IT
MAXIMIANO, A. C. A. Administração de projetos: como transformar idéias em resultados. São Paulo:
Journal, [S.l.], v. 14, n. 12, 2001.
Atlas, 2 ed. 2002.
THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002.
McBREEN, P. Questioning extreme programming. Boston: Addison-Wesley, 2003.
TURK, D. et al. Limitations of agile software processes. Jan, 2003. Disponível em <http://www.
McCABE, R.; POLEN, M. Should you be more agile? Crosstalk, The Journal of Defense Software
agilealliance.org/articles/articles/LimitationsofAgile.pdf> Acesso em Agosto, 2005.
Engineering, [S.l.], Oct, 2002.
______. Assumptions underlying agile software development process. Colorado State University,
NERUR, S. et al. Challenges of migrating to agile methodologies: organizations must carefully
2005.
assess their readiness before treading the path of agility. Communication of the ACM, [S.l.], v.48,
n.5, p 73-78, May 2005. UDO, N., KOPPENSTEINER, S. Will agile change the way we manage software projects? Agile from a
PMBoK guide perspective. Projectway, [S.l.], 2003.
PAULK, Mark. C. ExtremepProgramming from a SW-CMM perspective. IEEE Software, [S.l.], v. 18, n.
6, p. 19–26, Nov. 2001. VERZUH, E. The fast foward in MBA in project management. John Wiley & Sons, Inc., 1999.

32 Engenharia de Software Magazine - Gerenciamento Ágil de Projetos de Software

Uso de Análise de Pontos de Função em
Ambientes Ágeis
Célio Santana
Celio.santana@scrum.org.br
Professor Assistente das Faculdades Integradas
Barros Melo e do Grupo Universitário Maurício
de Nassau. Mestre em Engenharia da Compu-
tação pela Universidade de Pernambuco e Pós
Graduado em Melhoria de Processo de Softwa-
re pela Universidade Federal de Lavras (UFLA).
Graduado em Ciência da Computação pela Uni-
versidade Federal de Pernambuco. É Certified
Scrum-Master (CSM), Certified Product-Owner
(CSPO) bem como Implementador do Modelo
de Melhoria de Processos do Software Brasileiro
MPS.Br (P2 MPS.Br)
Cristine Gusmão
cristine@dsc.upe.br
Professora do Departamento de Sistemas e
Computação da Escola Politécnica da Uni-
versidade de Pernambuco (POLI - UPE), onde
leciona várias disciplinas na graduação e
pós-graduação (especialização e mestrado).
Coordena o PROMISE Project Management
Improvements in Software Engineering - gru-
po de pesquisa na área de Gerenciamento de
Projetos e Engenharia de Software. É coorde-
nadora do Curso de Bacharelado em Sistemas
de Informação das Faculdades Integradas
Barros Melo. Doutora e Mestre em Ciência da
Computação pela Universidade Federal de
Pernambuco. Graduada em Engenharia Elé-
trica - Eletrotécnica pela Universidade Federal
de Pernambuco. Pesquisadora associada do
Núcleo de Telesaúde – NUTES – HC – UFPE.
“Há alguns anos atrás, antes de Bill Gates e seus
amigos fundarem a Microsoft, em 1604 para ser
preciso, William Shakespeare escreveu o livro Me-
dida por Medida, que retratava o relacionamento
entre justiça e misericórdia. O livro apresenta um
conto complicado envolvendo autoridades pom-
posas de inflexível certeza moral, de delegação de
poderes para indivíduos despreparados com iden-
tidades ocultas ou enganosas, abuso dos inocen-
tes, virtudes corrompidas, reputações arruinadas
e, claro, as sempre populares luxúrias e ganância.
Agora, todos concordam que Shakespeare era um
gênio, mas como ele pode descrever de forma tão
precisa o ambiente moderno de desenvolvimento
de software a quatrocentos anos atrás?”
[Brindley 2008]
C
omumente ouvimos falar que al-
gum projeto foi um sucesso por
ter sido finalizado “quase” no
prazo estipulado ou mesmo ter ultrapas-
sado “pouco” o custo original [DeMarco
1982]. Esta visão de sucesso está ligada
diretamente a uma série de fatores os
Edição 20 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo apresenta as principais questões sobre a
utilização de Pontos por Função em Ambientes ágeis
que utilizam a técnica de Pontos por Estória (Story
Points).
Para que serve?
Mostrar que mesmo tendo o propósito de ser apli-
cada em qualquer ambiente de desenvolvimento e
independente de tecnologia, essa técnica pode não
se mostrar útil em um ambiente ágil de desenvolvi-
mento, devido a características peculiares da técnica
de Análise de Pontos de Função.
Em que situação o tema é útil?
A procura pelo conhecimento e aplicação de meto-
dologias ágeis vem aumentando. Desta forma, este
artigo tem a finalidade de prover (i) um melhor en-
tendimento de como e o que acontece quando se uti-
liza Análise de Pontos por Função (APF) em ambien-
tes ágeis; e (ii) apresentar as principais divergências
entre estimativas ágeis e APF.
quais podemos identificar e mensurar,
e assim constatar o desempenho posi-
tivo ou negativo em um determinado
contexto.
33
 Na Engenharia de Software, podemos afirmar que o surgi-
mento desta preocupação com a obtenção de bons resultados
se deu a partir da conferência de Engenharia de Software da
OTAN, onde se percebeu uma grande quantidade de proble-
mas existentes no contexto do desenvolvimento do Software
àquela época, utilizando-se pela primeira vez o termo Crise
do Software [Bemer 1968].
Um pouco mais adiante na linha da história, foi percebida
a necessidade de se estabelecer um sistema de medição para
prover um mecanismo de quantificação do que acontece no
processo de desenvolvimento de software. Esta necessidade foi
formalizada por DeMarco [Demarco 1982] em sua famosa frase:
“Não podemos controlar aquilo que não podemos medir” e até mesmo
Edward Deming [Deming 1986] quando o mesmo criou o ditado:
“Em Deus nós confiamos, para todo o mais, tragam-me dados”.
Assim como Shakespeare acreditava que deveria existir um
balanceamento entre justiça e misericórdia, somos sabedores
que projetos de TI devem buscar um equilíbrio entre diver-
sos números observáveis, mensuráveis e sempre conflitantes
motivações e influências. Mas a observação mais comum em
ambientes de TI é culpar as métricas ou estremecer diante da
possibilidade de ser medido, e às vezes julgados, o que não
muda os resultados desastrosos que acontecem em empresas
de TI [Brindley 2008].
Por exemplo, os resultados divulgados pelo Standish Group e
os relatórios conhecidos como “Chaos Report” que mostraram
que quase 30 anos depois da Conferência da OTAN, os resul-
tados da indústria de software ainda não são considerados
um sucesso.
A Figura 1 mostra a evolução dos indicadores de sucesso
de projetos de acordo com o “Chaos Report”, onde Sucesso são
aqueles projetos que foram terminados sem estouro de custo,
prazo e com todos os requisitos desenvolvidos, Desafiados são
aqueles onde o custo foi maior do que se previa, ou aqueles
que foram entregues após o prazo, ou se entregou com menos
requisitos do que o desejado, enquanto projetos cancelados
(Falha) são aqueles finalizados antes da sua conclusão (abor-
tados ou nunca utilizados).
Figura 1. Resultados dos Projetos de Software de Acordo com Chaos Report
34 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes
O relatório aponta que ainda em 2006, apenas um terço dos
projetos de software foram finalizados com sucesso e, mesmo
com a evolução demonstrada desde a sua primeira edição
lançada em 1994, ainda existe uma sensação de atraso nesta
busca por resultados consistentes.
Acredita-se que um dos fatores para que a indústria de sof-
tware venha gradativamente melhorando os seus resultados do
ponto de vista comercial e gerencial é a utilização de métricas
[Jones 2008]. Contudo só podemos afirmar com segurança que
as métricas foram as responsáveis por mostrar o tamanho do
problema em que a indústria de software se encontra.
Evolução dos Métodos de Medição e Estimativa
A indústria de software está beirando a casa dos 60 anos, no
qual os 10 primeiros anos, entre 1947 e 1957, representaram a
fabricação de software muito pequena, raro eram aqueles que
ultrapassavam 1000 declarações em seu código fonte. Todos
estes programas eram escritos em linguagens de baixo nível,
seja assembly ou linguagem de máquina [Jones 2008].
As primeiras tentativas de se medir produtividade, em cerca
de 1950, utilizou a métrica conhecida como linha de código.
A técnica, como mostra seu intuitivo nome, era baseada em
contar a quantidade de linhas de código de um sistema, e assim
surgia a primeira métrica de qualidade chamada de Defeitos
por Mil Linhas de Código, que mostravam quantos defeitos
(bugs) um sistema possuía a cada mil linhas de código. Hoje
esse tipo de métrica é chamada pelo nome de Densidade de
Defeitos [Jones 2008].
Naquela época, codificar demorava 50% do tempo de cons-
trução do software, enquanto testar e depurar levava a outros
40% enquanto o restante das atividades consumia 10% do
desenvolvimento de software. Contudo, entre 1957 e 1967 esta
situação mudou drasticamente com a chegada das linguagens
de programação de alto nível que eram mais poderosas que as
linguagens de programação assembly [Jones 2008].
Então, linguagens como Fortran, COBOL e APL começaram a
gerar aplicações comerciais e bancárias que facilmente chega-
vam a 10.000 linhas de código podendo chegar a 100.000 linhas
de código. Assim, em 1967, a métrica de linhas de código já
era considerada problemática pois, naquele momento, a codi-
ficação já representava menos de 30% do total de esforço no
desenvolvimento de software enquanto requisitos, especifica-
ções, planejamento e confecção de documentação já passavam
dos 40% [Jones 2008].
Assim, com o aumento crescente de atividades que não ge-
ravam linhas de código e com o aumento drástico de linhas
de código promovido pelas linguagens de programação de
alto nível, a métrica de linha de código foi abandonada pela
indústria de grande porte [Jones 2008].
Devido às falhas apresentadas neste estágio pelas linhas de
código, a IBM designou Allan Albrecth e seus colegas para
definir uma métrica de software útil naquele contexto que era
independente de volume de código e da tecnologia utilizada, e
que podia medir qualidade e produtividade sem distorções. E
assim nasceu a técnica conhecida como Pontos de Função.

Análise de Pontos de Função
Após o esforço de muitos anos, Albretch e seus colegas
apresentaram à IBM um novo tipo de métrica conhecida como
Pontos de Função. Essa métrica é baseada em cinco aspectos
do desenvolvimento de software que são: Entradas, Saídas,
Requisições, Arquivos Lógicos e Interfaces [Jones 2008].
Após sua utilização por muitos anos na IBM, pontos de função
foi discutido em público pela primeira vez em um trabalho de
Albretch apresentado na Conferência SHARE/GUIDE/IBM na
Califórnia, em 1979.
Essa técnica mede o tamanho funcional do software quan-
tificando as funcionalidades do ponto de vista do usuário,
baseado apenas no projeto lógico e especificação funcional,
sendo seus principais objetivos [Albretch 1979]:
• Medir a “quantidade” de funcionalidade que o usuário
requer e recebe;
• Medir o tamanho do desenvolvimento de software e da
manutenção de forma independente de tecnologia usada para
o desenvolvimento;
• Prover uma unidade de medição normalizada entre projetos
e organizações.
Em 1983, a associação comercial de clientes da IBM (GUI-
DE) estabeleceu um grupo de trabalho em pontos de função,
mas apenas em 1986 se verificou a existência da massa crítica
de utilizadores da técnica, de tal forma que foi decidido criar
uma organização sem fins lucrativos voltada exclusivamente
para a utilização de pontos de função, e a propagação dos
resultados obtidos com os estudos realizados nesta época.
Esta nova organização foi chamada de International Func-
tion Point User Group (IFPUG). Essa organização foi originada
em Toronto e hoje se encontra nos Estados Unidos contendo
pouco mais de 3000 afiliados de vinte países diferentes.
O IFPUG atualiza de tempos em tempos o guia para con-
tagem chamado de Manual de Práticas de Contagem (CPM),
que hoje está na versão 4.2.1. Vale ressaltar que, para o
IFPUG, toda padronização da contagem deve ser indicada
pela versão do manual.
Devido à alta aceitação e padronização do método, o mes-
mo se tornou uma norma ISO (ISO 20926) no ano 2000. E,
como sua validação trata apenas dos requisitos funcionais,
a técnica é explicita em afirmar que ela mede o tamanho
funcional do código, e requisitos não funcionais não inter-
ferem na contagem [Jones 2008].
Desta forma podemos comparar o ponto de função com
a unidade de medida metro quadrado: o metro quadrado
é uma unidade padrão que é igual em todo o mundo, mas
construir um castelo de dez mil metros quadrados na pla-
nície é diferente do que construir este mesmo castelo em
montanhas irregulares. Esta diferença do tipo do terreno
equivale aos requisitos não funcionais no desenvolvimento
de software.
Outro fator a ser considerado, é que a pontuação de uma
determinada funcionalidade é dada pelo ponto de vista do
cliente, e não do desenvolvedor, ou seja, um ponto de função
metodologias ágeis
é uma unidade de media que expressa o valor de negócio
que uma funcionalidade de um sistema traz ao usuário.
Isso significa que se o cliente deseja realizar um cadastro que,
ao final, envia um email de confirmação ao usuário. Enquanto
nós programadores consideraríamos duas funcionalidades (ca-
dastrar e enviar email) o método considera que o enviar email
é um processamento a mais na funcionalidade de cadastro, não
podendo ser contado em separado.
Então, se mensurar o software de forma funcional está ligado
diretamente à medição de requisitos funcionais do software,
sendo este do ponto de vista do cliente, Pontos de Função ca-
tegoriza esses requisitos do usuário em cinco tipos:
• Arquivos Lógicos Internos;
• Arquivos de Interface Externa;
• Entradas Externas;
• Consultas Externas;
• Saídas Externas.
Cada uma dessas categorias possui seus critérios objetivos
de adequação para saber como um requisito ou funcionalidade
se encaixa em uma delas.
Após descobrir sua categoria, é necessário identificar a sua
complexidade. Para tal, também são usados um conjunto
de regras objetivas que indica o quão complexa é uma fun-
cionalidade. Para todas as categorias existem três níveis de
complexidade: Alta, Média e Baixa.
Então, cada um desses requisitos é mapeado com uma fun-
ção de negócio do usuário e segue os critérios para apontar
em qual categoria ele se ajusta. Após isso a complexidade é
determinada de forma objetiva. A identificação da categoria
e complexidade de um requisito determina o seu tamanho
através de uma pontuação [Albretch 1979].
Após a definição da categoria e complexidade de todos os ele-
mentos do sistema, é obtida a pontuação total do mesmo, sendo
essa pontuação conhecida como Pontuação Não Ajustada, pois
o sistema como um todo, sofrerá um ajuste na sua pontuação
de acordo com os requisitos não funcionais do sistema.
Esse ajuste baseado nos requisitos não funcionais é conheci-
do na técnica como Fatores de Ajuste. Esses fatores de ajuste
incidem na pontuação do sistema inteiro como um peso que
pode variar de 0,65 até 1,35. Assim, de acordo com as restri-
ções do sistema, a pontuação final, chamada de Pontuação
Ajustada, pode ser jogada para cima ou para baixo em relação
à pontuação original.
Dessa forma, Pontos de Função se torna uma métrica padroni-
zada, devido ao seu método objetivo de encontrar a pontuação
de um elemento, podendo servir de base comparativa entre
projetos diferentes e até mesmo equipes diferentes, sendo ela
classificada hoje como métrica para definição de “Tamanho”
do software.
Esta técnica, embora largamente utilizada, possui ainda
algumas lacunas que o manual de contagens não cobre como,
por exemplo: como contar uma animação em Flash ou como
contar algoritmos complexos que estão embutidos dentro de
outras funcionalidades?
Edição 20 - Engenharia de Software Magazine 35
Medições em Ambientes Ágeis
Já as metodologias ágeis foram formalizadas em 17 de feve-
reiro de 2001, por 17 líderes de desenvolvimento que utiliza-
vam metodologias que, até aquele momento, eram conhecidas
como metodologias “leves” [Koch 2005]. Essas metodologias
surgiram como descobertas de praticantes que mudavam o
foco do desenvolvimento baseado engenharia de software
tradicional orientada a processo por uma abordagem mais
orientada a pessoas [Boehm & Turner 2004].
Então podemos ver que esse novo conceito baseado em
resposta rápida a mudanças e pouca documentação seguia
um caminho antagônico ao pregado pela visão orientada a
planejamento oferecida pelos modelos tradicionais. Schuh
define Metodologias Ágeis como um contra movimento
para trinta anos de crescente uso de processos burocráticos
significando a remodelagem da programação dentro da En-
genharia de Software.
Já Mnkandla & Dwolatzky (2004) afirmam que o Movimento
Ágil marcou o surgimento de uma nova disciplina de enge-
nharia que modificava os valores do processo de desenvol-
vimento de software do mecânico (orientado a processos e
utilizando regras da ciência) para o orgânico (dirigido por
questões sobre pessoas e suas interações). Isso implicava
um desafio complexo para a Engenharia de Software e para
sistemas em ambientes de trabalho que são dinâmicos e
imprevisíveis.
Diante de tal quebra de paradigma, se fez necessária a
criação de novos métodos de estimativas de “tamanho” de
software para este tipo de abordagem, devido ao seu foco em
entregar software de valor ao cliente em detrimento de outras
atividades mais complexas e que tragam menos retorno ao
cliente [Cohn 2007].
Boehm & Turner (2004) afirmam que estimativas em projetos
que usam métodos ágeis são feitas de maneira diferente das
realizadas em projetos tradicionais por suas características
diferenciadas, como rápido feedback e iterações curtas. Desta
forma, projetos que utilizam abordagens ágeis podem não se
adequar facilmente às técnicas e métodos mais conhecidos
de estimativa de esforço.
As estimativas de tamanho utilizadas nas abordagens ágeis
são de cunho subjetivo onde se leva em conta a experiência
do time de desenvolvimento e da “métrica” base que pode
ser variável entre times diferentes. As métricas mais comuns
nas abordagens ágeis são [Beck 2000, Beck & Fowler 2000,
Beck 2004]:
• Ideal Days (Dias Ideais)
• Pair Hours (Horas por Par)
• Story Points (Pontos por Estória)
Dias Ideais
Quanto tempo o desenvolvedor demoraria a finalizar uma
funcionalidade, se:
• Não houvesse interrupções;
• Todo o necessário estivesse disponível;
• O tempo inteiro dele estivesse todo alocado para isto.
36 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes
Mesmo sabendo que esse ambiente ideal de trabalho não exis-
te, ele pode ser imaginado como base para estimar o tamanho
e esforço necessário para o desenvolvimento das funcionalida-
des de um projeto. Como não é possível identificar com exati-
dão qual a quantidade de tempo útil a equipe terá durante os
trabalhos, propõe-se trabalhar com a idéia de que todo tempo
de trabalho deve ser considerado útil, utilizando-se assim o
termo “ideal” para representar o máximo de produtividade.
Normalmente trabalha-se com duas unidades de “tempos
ideais” nas estimativas:
Dia ideal: um dia ideal é aquele onde, por exemplo, um
programador produz oito horas ininterruptas de código útil.
Dizemos que uma estória demoraria um dia ideal para ser
desenvolvida quando estimamos em oito horas produtivas de
trabalho para que essa estória seja finalizada.
Semana ideal: uma semana ideal é aquela onde as quarenta
horas de trabalho desta semana são totalmente produtivas.
Quando se estima o esforço de uma funcionalidade como
sendo o de uma semana ideal de trabalho significa dizer que
quarenta horas produtivas serão suficientes para finalizar o
desenvolvimento desta funcionalidade.
Por se tratar estimativa de esforço, e não de tamanho, esta
técnica de estimativa será desconsiderada na comparação com
a análise de pontos de função.
Horas por Par
Na segunda edição do livro Extreme Programming Explained
[Beck 2004], Kent Beck sugeriu uma unidade de medida efi-
ciente para projetos de iterações muito curtas, XP nesta edição
sugeria iterações de uma semana. Esta nova unidade de medida
representava a quantidade de horas que um par de programa-
dores conseguiria desenvolver aquela funcionalidade.
Essa unidade de medida se mostra simples e intuitiva, uma
vez que era mais fácil imaginar a quantidade de trabalho re-
alizada em uma semana e o esforço necessário para concluir
as tarefas.
Esta medição não chegou a ser largamente implementada, e
por ser uma estimativa de esforço e não de tamanho, também
será desconsiderada daqui em diante.
Pontos por Estória
Neste contexto, o método de medição de tamanho mais di-
fundido é a estimativa conhecida como Pontos por Estória (SP)
[Cohn 2005]. O Ponto por Estória segue o mesmo princípio da
APF, ambos determinam valor de negócio de uma funciona-
lidade porém, SP considera esse valor baseado na experiência
subjetiva do time, enquanto Pontos de Função mede elementos
de negócios que são padronizados de forma a não considerar
nenhum elemento subjetivo.
Ponto por Estória é uma unidade de medida que aufere a
complexidade de uma estória ou requisitos, e representa o
quão difícil é desenvolver aquele requisito. Neste caso, um
ponto é baseado na experiência da equipe, podendo variar de
um time para outro [Cauwenberghe 2005].

Percebemos que os pontos, como são chamados, são normal-
mente aplicados de forma relativa e, por esse comportamento
relativo, possuem valores diferentes entre equipes diferentes que
utilizam XP, ou seja, um “ponto” pode valer 8 horas de desen-
volvimento em uma equipe A ou 40 horas de desenvolvimento
em uma equipe B. Esse valor pode ser uma política da própria
equipe ou pode ser determinado para cada projeto, baseado em
comparação, como demonstrado abaixo [Cauwenberghe 2005]:
Extreme Programming [Beck & Fowler 2000] define aquilo que
conhecemos como User Stories, ou Requisitos do Usuário. Na
prática essas “estórias” são estimadas em pontos por estória, onde
1 ponto é o valor definido pela política da equipe, ou alcançado
por comparação.
Normalmente se sugere que, na primeira iteração, as estórias
sejam classificadas de acordo com sua complexidade. Atribua 1
ponto a de menor complexidade e 5 pontos a de maior e defina
valores intermediários para as outras estórias.
Estime estas estórias restantes de acordo com as estórias já
estimadas. Por exemplo, se uma estória é 2 vezes mais complexa
do que outra, ela vale o dobro de pontos da anterior. Essa com-
paração de estórias é conhecida como uma técnica chamada de
triangulação [Cauwenberghe, 2005].
Para definir a duração de cada estória é necessário identificar a
produtividade de cada desenvolvedor. Sempre que uma estória
for estimada por algum desenvolvedor, deve-se multiplicar pelo
seu fator de carga que inicialmente deve ser considerado com o
valor 1.
Normalmente esse fator de carga vai caindo (para números
reais como, por exemplo 0,850), o que significa que a velocidade
do programador é de 0,85 pontos por dia.
Outro conceito importante para estimativas é o Yesterday Weather
[Beck, 2000] que propõe estimar a velocidade da equipe na pró-
xima iteração baseado no que foi feito anteriormente. Na prática,
Yesterday Weather indica que, para calcular o número de pontos
que cada desenvolvedor irá fazer na próxima iteração, basta olhar
para o número de pontos que ele fez na ultima iteração e repetir
esse número.
Como podemos perceber, o método é totalmente subjetivo,
pois primeiro a equipe precisa definir o que é um ponto, e
essa definição não é baseada em critérios objetivos. Contudo,
o método não abre espaço para palpites e esta estimativa deve
envolver disciplina, experiência e a certeza do que deve ser
feito [Cohn 2004].
Se, por um lado, temos uma maneira padronizada para es-
timar o tamanho funcional de um software e, do outro lado,
temos uma maneira totalmente subjetiva para atingir o mesmo
objetivo, temos um problema por não existir qualquer evidência
prática que ambas podem ou não co-existir dentro de um mesmo
ambiente.
Utilizando Story Points e Pontos de Função no
mesmo ambiente
Não existem muitos trabalhos publicados com evidências
científicas a respeito da Análise de Pontos por Função em
Metodologias Ágeis.
metodologias ágeis
Podemos citar inicialmente o trabalho de Fuqua (2003). Aqui
o autor realizou um estudo da inserção de Metodologias Ágeis
e o uso de Story Points em projetos que utilizavam Pontos de
Função como técnica de medição.
Ele encontrou uma forte resistência em unificar os dois mé-
todos uma vez que, enquanto Pontos de Função era apegado
apenas às questões funcionais, em Story Points aspectos não
funcionais eram determinantes na estimativa ideal do tama-
nho. Assim, ele encontrou um conflito de objetivos nos dois
métodos, desaconselhando sua utilização em conjunto.
Em outro texto sobre o assunto, Caper Jones (2008) afirma
que, de acordo com sua base empírica, é notado que dois
Pontos de Função equivalem em média a um Story Point. Mas
vale ressaltar que essa medida é uma média empírica de sua
base de dados.
Uma vez que a quantidade de trabalhos acadêmicos na área se
mostrarem insuficientes para formar uma opinião a respeito do
que acontece quando ambas as abordagens estão em conjunto,
foi necessário recorrer à indústria para buscar novas evidências
do que acontece nesse tipo de ambiente.
Assim, todas as conclusões listadas daqui para frente foram
cedidas pela autarquia pública Agência Estadual de Tecno-
logia da Informação (ATI) do Estado de Pernambuco (www.
ati.pe.gov.br) que está utilizando Scrum em alguns de seus
projetos, bem como Pontos de Função.
Inicialmente a ATI considera que as técnicas de Pontos de
Função e Pontos por Estória têm o mesmo propósito dentro
da organização, que é mensurar o valor de negócio agregado
de uma funcionalidade/sistema. Então, a ATI está tentando
definir um relacionamento entre Pontos de Função e Pontos
por Estória baseado em sua base histórica, que possui pouco
mais de um ano de informações.
Contudo, as informações se mostram divergentes tanto em
valores absolutos, ou seja, a conta de quantos Pontos de Função
vale um Ponto por Estória, e na evolução dos indicadores, ou
seja, normalmente há uma tendência inversa de crescimento
entre esses dois indicadores.
A principal razão encontrada pela ATI é que Ponto de Função
difere de Ponto por Estória de forma perceptível nos seguintes
tópicos elencados abaixo.
Funcionalidades em Ponto de Função sempre são analisadas
do ponto de vista do cliente
Apesar da técnica Pontos por Estória também considerar as
estórias do usuário como requisitos, ela incentiva que estas
estórias sejam quebradas em estórias menores quando estas
sejam muito grandes. Por exemplo, no seguinte requisito:
- Para o cadastro de um usuário será necessário informar os
campos, CPF, nome completo, login e senha. O usuário só será
cadastrado se o seu CPF não apresentar problemas na Polícia
(nada consta), após o seu cadastro o usuário deve receber um
email.
Em Pontos por Estória o time seria incentivado a quebrar a
estória acima em três estórias menores:
Edição 20 - Engenharia de Software Magazine 37
1. Verificar CPF na base da Polícia;
2. Cadastrar usuário;
3. Enviar email ao usuário.
Ponto de Função considera a finalidade da ação (Cadas-
trar o usuário), sendo que esta possui uma validação (nada
consta) e um processamento (email), mas veja que ainda
continua sendo apenas uma funcionalidade.
Então requisitos muito grandes, se tornam muitas estó-
rias enquanto nem sempre se tornarão muitos elementos
considerados em Ponto de Função, sendo este o fator que
mais estimula divergências entre as técnicas.
Ponto de Função só considera requisitos funcionais nos
fatores de ajuste
Como foi mostrado anteriormente, Ponto de Função serve
para contar o tamanho funcional de um determinado re-
quisito do sistema. Se este requisito é construído de forma
simplória, ou de forma extremamente complexa, a sua
pontuação, na maioria dos casos, será a mesma, ou sofrerá
pequenas variações. Essa diferença será corrigida ao final
da contagem e este ajuste considerará todo o sistema, e não
apenas a funcionalidade medida.
Em Pontos por Estória temos que cada requisito é avaliado
de acordo com o seu tamanho, ou seja, quanto trabalho
aquele requisito representa dentro do desenvolvimento,
mas também é avaliado de acordo com a complexidade
das tarefas envolvidas.
Esse tipo de diferença de visão leva a vários problemas
na obtenção de uma função de conversão entre ambas as
abordagens. A seguir serão mostrados dois casos onde as
diferenças ficam latentes.
Para ilustrar o problema, vamos imaginar um sistema
de cadastro simples, onde serão cadastrados usuários e
documentos bem como todas as operações de manutenção
dessas entidades (Consultar, Remover, Atualizar), e uma
funcionalidade para ligar um usuário a um documento.
O cenário de uso (A) desse sistema solicita a construção
do mesmo em páginas web, sem restrições de desempenho,
confiabilidade e usabilidade. Enquanto no Cenário (B),
além de todo o desejado em (A), existe a restrição operacio-
nal para que sistema garanta até 100 acessos simultâneos,
com requisitos de acessibilidade (para deficientes visuais)
e internacionalização do site, com um menu de ajuda, e
que o sistema deve ser 24X7 com uma disponibilidade de
99,999% do tempo, e cada vez que um usuário é ligado a
um documento, este tem que sofrer um processo de au-
tenticação via certificação digital.
Estes dois cenários (A e B), no ponto de vista da técnica
de Pontos de Função, terão uma diferença pequena na
pontuação final, quando considerados os pontos não
ajustados.
Ao se considerar os fatores de ajuste, vemos que a
pontuação ajustada no cenário (A) fica muito parecida
com a pontuação não ajustada, enquanto no cenário (B) a
38 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes
pontuação ajustada será aproximadamente 30% maior do
que na não ajustada.
Na prática, percebemos que o sistema no cenário (B) é um
sistema totalmente diferente, do ponto de vista técnico, em
relação ao sistema do cenário (A), e sua pontuação final
será ajustada em no máximo 40%, ou seja, se o sistema em
(A) chegar aos 60 pontos, em B ele chegará ao máximo de
85 pontos.
Quando tratamos o mesmo problema em Pontos por Estória
vemos que o tamanho do sistema pode dobrar ou até mesmo
triplicar, uma vez que a complexidade do sistema em (B) é
muito maior do que em (A). Então, a questão dos requisitos
não funcionais do sistema pode, em determinado momento,
trazer uma variação disforme nas duas abordagens, dificul-
tando a identificação de um comportamento comum.
Atente-se para o fato de que neste caso Pontos por Estória
se aproxima mais da pontuação ajustada.
No segundo caso de desvio a ser observado, podemos
considerar um sistema similar mostrado no cenário ante-
rior, mas que, ao invés de duas entidades (Usuários e Do-
cumentos), apresente 10 entidades e que possua a mesma
funcionalidade de vincular um usuário a um documento
apresentada.
Contudo, especificamente para esse caso, apenas essa
funcionalidade (vincular documento a um usuário) terá
restrições de desempenho, usabilidade, ajuda on-line, con-
corrência, segurança, utilização de certificação digital e
envio de email de confirmação.
Nesse caso, os Pontos de Função não ajustados só apre-
sentam um prejuízo, podendo este ser muito grande, na
contagem da funcionalidade de vinculação do documento
a um usuário.
Quando se usa os fatores de ajuste, temos um prejuízo para
o comprador, pois o fator de ajuste foi utilizado no sistema
inteiro. Pelo que vemos nesse caso, são quarenta funcionali-
dades de cadastro (Cadastrar, Alterar, Consultar, Remover)
de dez entidades diferentes que também são ajustadas, na
mesma medida da funcionalidade de vinculação, embora
não se utilizem de nenhuma das restrições impostas naquela
funcionalidade.
O Ponto por Estória funcionará da mesma forma do que
no exemplo anterior, atribuindo pontuações simples às
funcionalidades de cadastro e a pontuação maior para a
vinculação. Mas ainda difere da pontuação não ajustada, e
difere ainda mais da pontuação ajustada.
Nesse caso específico, o Ponto por Estória tende a se
aproximar do fator não ajustado, o que difere do exemplo
anterior. Um problema é quando se aproximar de uma
pontuação ou de outra.
Mudanças
Mudanças trazem uma nova dificuldade quando se tenta
estabelecer uma relação entre Ponto de Função e Ponto por
Estória. Em Ponto de Função, uma alteração realizada no
sistema é tratada como uma contagem de manutenção que

hoje sabemos funcionar bem para manutenções evolu-
tivas do sistema, sendo não aconselhado o seu uso em
manutenções corretivas.
A questão nesse ponto é que neste tipo de contagem é
considerado no cálculo da pontuação todas as inclusões,
alterações e conversões necessárias para que a nova
funcionalidade do sistema fique disponível ao cliente.
Contudo, é considerada também toda parte do sistema
que precise ser excluída do mesmo, e esta deve ser con-
tabilizada no resultado final do sistema.
Então se, em uma nova funcionalidade desejada para um
determinado sistema é necessário criar uma entidade A,
modificar um tipo de dado de Inteiro para Real em uma
entidade B, ou excluir uma entidade C do sistema, serão
contadas na manutenção como se estas entidades A, B e C
tivessem sido criadas por completo neste momento.
Esse fator é agravado se ainda for considerada a criação,
alteração e exclusão das funcionalidades referentes a essas
entidades. Por isso que há casos que é melhor para quem
compra em Ponto de Função solicitar que uma funcionali-
dade seja desenvolvida por completo, do que alterar uma
funcionalidade parecida existente.
Este fator não é considerado em Ponto por Estória, pois
a técnica considera apenas o tempo e a complexidade de
ajustar a funcionalidade desejada. Pode acontecer tam-
bém, como já falamos anteriormente, que a técnica incenti-
va a quebra de estórias grandes em estórias menores, que
estórias de manutenção sejam quebradas tornando mais
difícil o mapeamento entre Pontos de Função e Pontos por
Estória. Esse tipo de dificuldade acontece em larga escala
em projetos ágeis que incentivam mudanças.
Lacunas do Manual de Contagens de Práticas
Outra dificuldade encontrada neste contexto, e que pode
ser considerada relevante, é que o Manual de Contagem
de Práticas fornecido pelo IFPUG não provê uma maneira
de contar todas as nuances existentes no desenvolvimento
de software, principalmente no tocante a requisitos não
funcionais.
Aspectos como Data Warehouse, Internacionalização,
Animações em Flash, Efeitos Sonoros, Sistema de Ajuda
On-Line, Criação de Interfaces, Relatórios disponíveis em
mais de um formato de arquivo e Manutenção Corretiva
são recomendados em Whitepapers do IFPUG, mas não
há uma opinião consolidada sobre como contar essas
particularidades.
Pontuação com a soma das partes não é a mesma da
pontuação final de um sistema em Ponto de Função
Em Ponto de Função, a soma das partes do sistema tem,
normalmente, uma pontuação maior do que a contagem
do sistema inteiro. Assim, não se pode comparar o total
de Pontos por Estórias realizados durante a concepção
inteira de um sistema e compará-lo com a pontuação final
em Pontos de Função.
metodologias ágeis
Assim, a única forma de realizar os mapeamentos é, a
cada iteração, fazer um mapeamento direto da quantida-
de de Pontos de Função versus Pontos por Estória, após
o término da iteração. Isto dificulta, principalmente no
começo, a utilização dos fatores de ajuste, uma vez que
restrições podem ser verificadas durante o desenvolvi-
mento do sistema.
Subjetividade da técnica de Ponto por Estória e
Experiência da Equipe
Vimos que o Ponto de Função, mesmo com algumas par-
ticularidades, é calculado de forma objetiva e sem espaço
pra ambiguidades. Mas, o Ponto por Estória tende a variar
durante o desenvolvimento, uma vez que ele depende
primeiro daquilo que a equipe definiu o que é um ponto,
e segundo, que o total de pontos de uma estória pode ser
mal interpretado por uma equipe, se tornando assim mais
susceptível a variações entre as diversas iterações.
Conclusão
Vimos que as técnicas Pontos de Função e Pontos por
Estória possuem o mesmo objetivo comum de medir a
quantidade de valor de negócio agregado ao sistema ou a
pedaços dele. Contudo, a diferença de cultura que envolve
estas abordagens as torna duas formas diferentes para
avaliar o mesmo indicador dentro do desenvolvimento
de software.
Nem na literatura nem na organização pesquisada se
encontrou uma forma de conversão entre as unidades,
nem sequer um comportamento comum entre variação
da pontuação entre as mesmas ao longo das iterações que
se seguem no projeto.
É verificado que o Ponto de Função se aproxima mais da
realidade financeira dos projetos, se tornando uma métri-
ca eficiente para controle de custos e produtividade dos
times. No caso da ATI, o Ponto de Função deveria servir
como uma régua, para medir a variação do tamanho do
Ponto por Estória, mas nenhum comportamento comum
entre as duas pontuações ainda foi identificado.
Já o Ponto por Estória se mostra uma técnica mais efi-
ciente no acompanhamento do projeto e na estimativa
de tempo e tamanho das estórias, uma vez que a equipe
sempre tem uma experiência maior em relação aos prazos
e à quantidade de trabalho possível em cada estória.
Feedback
Dê seu feedback sobre esta edição! eu
s
Dê
A Engenharia de Software Magazine
sobre e
tem que ser feita ao seu gosto.
s
ta
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 20 - Engenharia de Software Magazine 39
 Referências
[Albretch 1979] Albrecht, A. J. (1979) Measuring Application Development Productivity. In Proc.
IBM Applications Development Symposium. GUIDE Int and Share Inc., IBM Corp., Monterey, pp. 83.
[Beck 2000] Beck, K. (2000) Extreme Programming Explained: Embrace Change. Addison Wesley,
Reading.
[Beck 2004] Beck, K. (2004) Extreme Programming Explained Second Edition. Addison Wesley, Reading.
[Beck & Fowler 2000] Beck, K., Fowler, M. (2000) Extreme Programming Planned. Addison Wesley,
Reading.
[Bemer 1968] Bemer, R. W. (1968) Checklist for planning software system production. In P. Naur
and B. Randell, eds., Software Engineering, Report on a conference sponsored by the NATO SCIENCE
COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels,
Belgium, pp. 165-181.
[Boehm & Turner 2004] Boehm, B,.Turner, R. (2004) Balancing agility and discipline: A guide for the
perplexed 1° ed. Addison Wesley, pp. 165-194.
[Brindley 2008] Brindley, D. (2008) Foreword. In C. Jones, Software Applied Measurement, Mcgraw
Hill, Pp. XVIII.
[Cauwenberghe 2005] Cauwenberghe, P. V. (2005) Thinking for a Change: Story Points and Velocity.
http://blog.nayima.be/2005/07/24/story-points-and-velocity/ Março 2007.
40 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes
[Cohn 2004] Cohn, M. (2004) User Stories Applied: For Agile Software Development, Boston:
Addison-Wesley.
[Cohn 2005] Cohn, M (2005) Agile Estimating and Planning, Addison-Wesley.
[DeMarco 1982] DeMarco, T. (1982) Controlling Software Projects, Prentice Hall.
[Deming 1986] Deming, W. (1986) Out of the Crisis, The MIT Press.
[Fuqua 2003] Fuqua, A. (2003) Using Function Points in XP – Considerations. In Proceedings of
Extreme Programming and Agile Processes in Software Engineering, Springerlink XP 2003.
[Jones 2008] Jones, C. (2008) Applied Software Measurement, MCGraw Hill.
[Koch 2005] Koch, A. S. (2005) Agile Software Development - Evaluating the Methods for Your
Organization. Artech House, Boston.
[Schuh 2004] Schuh, P. (2004) Integrating agile development in the real world (pp. 1-6). MA:
Charles River Media.
[Mnkandla & Dwolattzy 2004] Mnkandla, E., Dwolatzky, B. (2004) Balancing the human and the
engineering factors in software development. Proceedings of the IEEE AFRICON 2004 Conference
(pp. 1207-1210).
Introdução ao Mantis
Gestão da Manutenção e Configuração de Software através do controle de
mudanças
Renato de Freitas Matos
redematos@hotmail.com
Atualmente é aluno do Curso Superior de Tecno-
logia em Análise e Desenvolvimento de Sistemas
no Centro de Ensino Superior de Valença (CESVA)
– Fundação Educacional D. André Arcoverde. Pro-
fessor de WebDesign e Programação em cursos
profissionalizantes. Desenvolve aplicações em Java
utilizando o banco de dados PostgreSQL, possui
interesse em Engenharia de Software, Banco de
Dados e desenvolvimento de sistemas em Java.
Letícia Dias da Silva
let-ds@hotmail.com evaldo@cesjf.br
Atualmente é aluna do Curso Superior de Tecno-
logia em Análise e Desenvolvimento de Sistemas
no Centro de Ensino Superior de Valença (CESVA)
– Fundação Educacional D André Arcoverde. Atua
na área de desenvolvimento de sistemas em Vi-
sual Basic, com experiência em Bancos de Dados
Firebird, PostgreSQL e Access. Tem como foco de
interesse o aprimoramento da linguagem SQL e
aplicações Java, além dos princípios de Qualidade
e Manutenção de Software.
Evaldo de Oliveira da Silva
Mestre e especialista em Ciência da Computação
pela Universidade Federal de Viçosa. Coordenador
do Setor de Tecnologia da Informação da Academia
- Colégio Cristo Redentor e do Centro de Ensino Su-
perior de Juiz de Fora (CES/JF). Atua também como
professor do curso de Bacharelado em Sistemas de
Informação e dos cursos de Especialização em Com-
putação do CES/JF, e no Curso Superior de Tecnolo-
gia em Análise e Desenvolvimento de Sistemas da
Fundação Educacional D. André Arcoverde (FAA).
Edição 20 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo aborda a importância da manu-
tenção e gestão da configuração de software,
apresentando os conceitos básicos sobre estas
áreas de estudo dentro da engenharia de sof-
tware. Destaca também a necessidade do uso
de aplicações de software para gestão da con-
figuração de software.
Para que serve?
O artigo demonstra como as mudanças em
software podem ser identificadas, controladas
e visualizadas com o uso de aplicações como o
Mantis. O Mantis é uma aplicação gratuita para
ser executada no ambiente Web. Tal ferramenta
implementa os conceitos da gestão de configu-
ração de software, fornecendo diversos recursos,
como registro e histórico das mudanças durante
a manutenção de software.
Em que situação o tema é útil?
Identificação, controle e visualização de
mudanças no contexto da manutenção
e configuração de software, utilizando
ferramentas de apoio para gestão destas
atividades.
41
 A manutenção de software é a fase do ciclo de vida de desen-
volvimento durante a qual ocorrem modificações no código
e em qualquer outro artefato de uma aplicação de software,
a fim de mantê-lo disponível e em constante evolução. A
manutenção é executada para corrigir falhas na codificação,
melhorar o desempenho do software, ou adequá-lo aos novos
requisitos conforme as necessidades dos seus usuários (DIAS
e ANQUETIL, 2005).
Desde o início da década de 90, a manutenção de software já
era considerada como uma atividade consumidora de grande
parte dos recursos financeiros, humanos e tecnológicos, dentro
das organizações produtoras de software. A literatura mais
atual sobre Engenharia de Software (ES) apresenta estudos
que esta fase representa cerca de 80% do orçamento total do
ciclo de vida de um software. Portanto, é considerada uma ati-
vidade economicamente estratégica durante a vida de qualquer
software (PRESSMAN, 2006).
Além desses dados, Dias e Anquetil (2005) enfatizam que
existe um preconceito em relação à atividade de manutenção
de software, pois não deve ser simplesmente considerada
como uma atividade de correção do código de uma aplicação.
Pesquisas mostram que apenas 20% dos projetos de manu-
tenção são de correção de erros, e que a grande maioria do
trabalho consiste em acrescentar novas funcionalidades a um
sistema existente, ou adaptá-lo a mudanças externas. Pode-se
considerar, diante destes percentuais, que a manutenção de
software é uma atividade imprescindível, e sem a qual os
sistemas existentes rapidamente se tornariam antiquados em
relação ao mundo real. Deste modo, a manutenção de software
permite que o software evolua, para continuar representando
fielmente a realidade que eles automatizam.
Pressman (2006) discute que um dos grandes problemas na
manutenção de software é a alta rotatividade da equipe de
desenvolvimento. Ou seja, é provável que a equipe ou pessoa
que fez o trabalho original não seja mais um desenvolvedor
naquele projeto. Ou várias gerações subsequentes de profis-
sionais modificaram a aplicação e não fazem mais parte da
equipe. Diante destes problemas, é importante destacar que
modificar um software é inevitável, sendo necessário desen-
volver mecanismos para avaliar, controlar, registrar e rastrear
tais modificações.
Outros problemas técnicos e gerenciais podem ser relacio-
nados: a complexidade do domínio do problema; obstáculos
para gerenciar e estabelecer um processo de desenvolvimento
e manutenção; tecnologias ultrapassadas presente nos sistemas
legados, que continuam em funcionamento e resistem às mo-
dificações ou evoluções.
Muito dos problemas citados acima são diferentes daqueles
vividos por desenvolvedores que participam da implementa-
ção de novos softwares. Durante a fase de manutenção é pos-
sível encontrar documentações mal elaboradas, ou nenhuma
documentação. Com isso, os desenvolvedores normalmente
gastam mais tempo analisando o software antes de modificá-
lo, prejudicando a entrega das demandas de modificações no
mesmo.
42 Engenharia de Software Magazine - Introdução ao Mantis
Existem outros problemas relacionados à manutenção de
software como, por exemplo, problemas culturais, ou seja, a
maioria dos profissionais é formada com uma visão essen-
cialmente focada no desenvolvimento de novas aplicações.
Esta afirmação pode ser constatada pelo fato dos modelos de
manutenção não serem, nem tão bem desenvolvidos, nem tão
bem compreendidos como os modelos de desenvolvimento de
software. Tal atividade também é reconhecida por sua impor-
tância, até mesmo como disciplina em cursos de graduação e
pós-graduação, mas recebe relativamente pouca atenção na
literatura técnica, onde novos processos são propostos para
melhorar o desenvolvimento de um software novo. É possí-
vel citar os processos iterativos baseados no paradigma da
orientação a objetos, e que muitas vezes pretendem resolver as
dificuldades da manutenção tratando-a apenas como mais uma
iteração. No entanto, estes novos processos não se aplicam em
sistemas legados, desenvolvidos com métodos ou tecnologias
ultrapassadas como, por exemplo, sistemas escritos em COBOL
(JACOBSON, 1999; SOMMERVILLE, 2003; DIAS e ANQUETIL,
2005; PRESSMAN, 2006).
Diante dessa discussão, a manutenção de software deve
ser tratada como uma disciplina, onde os profissionais de
TI (Tecnologia da Informação) estarão mais preparados para
conhecer a realidade do mercado, tendo conhecimento das
principais áreas de estudo da manutenção de software como,
por exemplo, a configuração de software, engenharia reversa,
redocumentação e modelos de gestão para controle de mudan-
ças. Tais áreas devem ser conhecidas e exploradas como forma
de amadurecer o processo de manutenção, obtendo o controle
da evolução do software.
Com base no relato desta seção e na importância da manu-
tenção como fase crítica do processo de desenvolvimento, as
próximas seções abordam o conceito de gerência da configura-
ção e suas principais atividades dentro da manutenção de sof-
tware. Em seguida, este artigo apresenta a ferramenta Mantis
utilizada por gerentes de configuração e desenvolvedores de
software no controle e acompanhamento de requisições das
mudanças em software.
Gerência de Configuração de Software
Configuração de um sistema de software é uma coleção de
versões específicas de itens de configuração (hardware, firmware
ou software) que são combinados de acordo com procedimen-
tos específicos de construção para servir a uma finalidade
particular. A Gerência de Configuração de Software (GCS ou
SCM – Software Configuration Management) é uma coleção de
atividades projetadas para controlar mudanças e identificar as
alterações feitas em softwares durante o seu desenvolvimento
e manutenção. Tais atividades se relacionam e contribuem
para definir mecanismos para gerenciar diferentes versões de
software em desenvolvimento, permitindo que seja feita a ras-
treabilidade e auditoria das modificações realizadas (SHARI,
HENDLER e PORTER 2007).
Segundo Dart (1991) a GCS é uma disciplina que visa con-
trolar a evolução de sistemas de software e propõe técnicas e

ferramentas para a gestão da manutenção de software. Além
disso, estabelece processos para gestão de mudanças com o
objetivo de registrar as solicitações para modificar o software,
tanto para manutenções corretivas ou preventivas, quanto para
controlar a inserção de novos requisitos. Basicamente, a GCS
tem por finalidade responder às seguintes questões básicas:
a) Quais são as mudanças registradas para o sistema?
b) Por que essas mudanças foram registradas?
c) Se o sistema continua íntegro após as mudanças?
Murta (2006) destaca ainda que a GCS é uma disciplina im-
portante dentro da ES, pois pode contribuir indiretamente para
atender a áreas chave de processo existentes em vários níveis
de maturidade como, por exemplo, prevenção de defeitos e
gerenciamento quantitativo do processo. Contudo, sua maior
contribuição está no nível 2 do CMM (Capability Maturity Mo-
del), em uma área chave de processo de mesmo nome.
Vários são os motivos para estudar e adotar a GCS. Atual-
mente, grandes aplicações necessitam do controle de versões,
pois os engenheiros de software devem gerenciar o desenvol-
vimento de várias aplicações que estão sendo modificadas ao
mesmo tempo e por equipes geograficamente distantes, sendo
pela inserção de novos requisitos, ou por que houve um erro
da aplicação em produção. Neste caso, a última versão da apli-
cação deve ser recuperada, e os componentes que acusaram os
erros devem ser corrigidos ou adaptados. Nessas situações, o
engenheiro de software deve estar atento, possuindo técnicas
e ferramentas de controle, pois os componentes corrigidos
devem ser alterados e colocados em produção, sem afetar a
integridade e o desenvolvimento da aplicação.
Outra motivação diz respeito às dependências que existem en-
tre os componentes de software. Tais dependências muitas vezes
são conhecidas localmente pelos desenvolvedores e analistas da
aplicação. Alguns desenvolvedores que possuem conhecimento
da configuração interna do software podem abandonar a equipe,
ou simplesmente serem realocados para outro setor ou fábrica
de software. Desta forma, devem existir meios de compartilhar
o conhecimento sobre essas dependências, a fim de facilitar a
manutenção do software por outros desenvolvedores.
De acordo com Dart (1991) as seguintes atividades sobre a
gerência de configuração devem ser consideradas:
1. Identificação: apóia na identificação dos componentes do
software e seus tipos, tornando-os acessíveis para a equipe de
desenvolvimento. A identificação também visa o mapeamento
das dependências entre os seus componentes;
2. Controle: estabelece o controle das atualizações e das mudan-
ças no produto de software no decorrer do seu ciclo de vida. A
atividade de controle deve possuir mecanismos para gerenciar
e garantir a integridade da configuração do software;
3. Geração de Estatísticas: é a geração dos relatórios de status
dos componentes e dos pedidos de mudanças. Tais relatórios
devem fornecer informações sobre a freqüência em que um
software é modificado;
4. Auditoria e revisão: validação da completude de um produto
e da integridade entre os componentes de software.
projeto
A GCS possui atividades que devem ser executadas por
diversos profissionais com papéis e funções bem distintas.
Por exemplo, deve existir em uma equipe de desenvolvimento
um gerente de configuração e testadores de software para
garantir a qualidade do produto que será entregue aos clientes
e aos usuários da aplicação.
Cada papel deve possuir, de forma bem definida, suas
próprias tarefas dentro do processo de gerenciamento da
configuração. Por exemplo, o gerente de projetos tem interes-
ses administrativos, como acompanhar e controlar os prazos
e custos, monitorando o progresso do desenvolvimento,
identificando problemas que possam gerar impacto nesse
progresso.
Os objetivos do gerente de configuração estão relacionados
ao cumprimento de procedimentos e políticas para a criação,
mudanças e testes nos códigos das aplicações, bem como tor-
nar as informações sobre os projetos mais acessíveis. Além
disso, esse profissional deve implementar técnicas para man-
ter o controle dos códigos atualizados, criando mecanismos
para oficializar os pedidos das mudanças, sendo responsável
também pela aprovação e autorização das mesmas. O gerente
de configuração cria e compartilha uma lista de tarefas para
os engenheiros de software, determinando o contexto do
projeto de manutenção do software. Além disso, armazena
e extrai estatísticas sobre os componentes de software, tais
como informações que determinam quais são os componentes
do sistema sofrem mais manutenção.
A meta dos engenheiros de software na gerência de configu-
ração é manter o desenvolvimento e a criação do produto de
software de forma eficiente. Os engenheiros de software usam
ferramentas que ajudam a construir um produto de software
consistente, comunicando e coordenando as tarefas que foram
concluídas. Um histórico da evolução de todos os componentes
deve ser mantido, com o registro dos motivos das mudanças
e o que realmente foi alterado. Eles também têm a responsa-
bilidade de manter as áreas de trabalho usadas para criar,
atualizar, testar e integrar os códigos das aplicações. Por fim,
devem controlar a produção e manutenção de código de acordo
com diversas demandas de novos requisitos e a necessidade de
correções geradas por erros do software em produção.
O testador de software tem o objetivo de certificar se o
produto de software foi desenvolvido de forma satisfatória.
Isto envolve testes na versão do produto de software e manu-
tenção do registro dos testes feitos nas versões do produto de
software e os resultados desses testes (DART, 1991).
Assim como em outras áreas de estudo da ES, a GCS
necessita de soluções de software capazes de auxiliar na
implementação das atividades relacionadas anteriormente.
Apesar disso, não existe uma definição universal sobre quais
funcionalidades e requisitos um sistema de GCS deve possuir.
Pode-se considerar que um software aplicativo que fornece
controle de versão é um sistema para gerência de configu-
ração. Outros softwares permitem registrar os pedidos de
mudanças, porém muitos não integram estas funcionalidades
ao controle de versão.
Edição 20 - Engenharia de Software Magazine 43
 De maneira geral, tais sistemas devem possuir os seguintes
requisitos: a) registro das versões dos componentes; b) locali-
zação das diferenças entre dois códigos modificados; c) reposi-
tórios e bibliotecas para armazenar e recuperar componentes;
e, d) informação sobre os diferentes tipos de componentes.
Outros requisitos podem ser definidos para um sistema de
GCS, como os requisitos de construção, controle, contagem,
processo e equipe.
Sobre os requisitos de construção, os usuários precisam
de meios mais fáceis de implementar o software, tendo a
funcionalidade de “congelar” o status do produto em algum
momento; mecanismos para otimizar os esforços da constru-
ção de sistemas a fim de reduzir a necessidade de recompilar
os componentes e economizar espaço; facilidades de fazer a
análise dos impactos e prever as ramificações das mudanças;
e facilitar de forma mais simples a recuperação e geração de
qualquer fase ou parte do produto a qualquer momento (DART,
1991; SHARI, HENDLER e PORTER 2007).
Em relação aos requisitos de auditoria, os usuários precisam
do histórico de todas as mudanças; rastreabilidade entre todos
os componentes do produto e suas evoluções; e o log de todos
os detalhes do trabalho feito.
No que diz respeito aos requisitos para contagem e estatís-
ticas, os usuários precisam de mecanismos que registrem as
estatísticas, para examinar o status do produto de software,
e gerar mais facilmente relatórios sobre todos os aspectos do
produto e processo.
Sobre os requisitos de controle, os usuários precisam de
acesso cuidadoso aos componentes do sistema para evitar
qualquer mudança errada ou conflito nas mudanças; suporte
on-line para os pedidos de mudança e relatórios dos problemas;
meios de acompanhar e controlar os erros encontrados nos
códigos e como, quando e quem desenvolveu o componente
com o defeito.
Em relação aos requisitos de processo, os usuários precisam
de suporte para seu ciclo de vida e suas políticas organi-
zacionais; a habilidade para identificar tarefas para serem
feitas e como e quando elas serão completadas; a habilidade
para comunicar informações apropriadas sobre os eventos
relevantes; e as facilidades para documentar o conhecimento
sobre o produto.
Finalmente, a respeito dos requisitos de equipe, os usuários
precisam de áreas de trabalhos específicas; a resolução de
conflitos quando as mudanças são alteradas ao mesmo tempo,
a fim de igualar ou mostrar as divergências entre os códigos
atualizados, e facilidades para suportar a criação e manutenção
de diversos produtos de software.
Com base nos conceitos apresentados anteriormente, a
próxima seção apresenta as principais características da fer-
ramenta Mantis, que pode ser usada para registrar incidentes
e modificações no software, identificando a mudança com o
Figura 1. Menu Principal do Mantis
44 Engenharia de Software Magazine - Introdução ao Mantis
preenchimento de diversas informações. Além disso, é pos-
sível usar o Mantis para acompanhar o processo de alteração
e execução das mudanças, bem como gerar relatórios sobre a
evolução dos pedidos.
A ferramenta Mantis
Mantis é um aplicativo desenvolvido para ser executado em
ambiente Web, e pode ser usado para registrar incidentes ou
mudanças durante a atividade de manutenção de software.
É um aplicativo de código aberto, e é disponibilizado gratui-
tamente desde novembro de 2000. É desenvolvido em PHP
podendo utilizar diversos bancos de dados relacionais, como
MySQL, MS-SQL Server, PostgreSQL ou DB2. O Mantis pode
ser executado em qualquer sistema operacional que suporta
a linguagem PHP, por meio do servidor Apache, podendo
funcionar no Windows ou Linux, por exemplo. As versões
do Mantis são liberadas sob os termos da GNU General Pu-
blic License (GPL) através do site http://www.mantisbt.org/
download.php.
O Mantis é considerado uma ferramenta para GCS, pois
permite registrar, acompanhar e gerar estatísticas das mu-
danças realizadas durante a atividade de manutenção de
software. A modificação é relatada, registrada e enviada
para a equipe de desenvolvimento, onde o gerente de confi-
guração pode acompanhar a execução e o detalhamento das
mudanças. Através do Mantis também é possível que seja
feito o gerenciamento de comunicações sobre os pedidos de
manutenção, por meio de envio de e-mails e notícias para a
equipe de desenvolvimento de um determinado projeto de
manutenção de software. Além destas características, esse
software permite o controle de nível de acesso aos pedidos de
manutenção, podendo ser criados perfis e níveis de acesso por
projeto de desenvolvimento e manutenção de software. No
entanto, este artigo visa apresentar apenas as funcionalidades
de abertura e controle de mudanças no Mantis, abordando
o registro das mudanças, o seu ciclo de vida e os relatórios
existentes. As próximas seções abordam estas funcionalida-
des de forma detalhada.
Abertura de mudanças
A abertura de mudanças no Mantis é tratada como um relato
de caso, sendo registradas por meio do menu “Relatar Caso”
existente no menu principal (Figura 1). Para que uma mudança
seja relatada, é necessário que a mesma esteja associada a um
projeto de software. Tal projeto deve estar previamente cadas-
trado pelo administrador do sistema. Além dessa característica,
o Mantis também permite a associação dos usuários inseridos
no sistema aos seus respectivos projetos, pois assim que uma
mudança for aberta, automaticamente todos os analistas ou
desenvolvedores daquele projeto de software receberão a
mudança registrada.
 projeto

Para iniciar o relato do defeito ao Mantis, o relator deve podendo servir de base de conhecimento sobre a documenta-
preencher os campos obrigatórios (identificados por um ção e evolução do software. O campo de “Informações Adicio-
*), isto ocorre porque esses campos são essenciais para a nais” permite adicionar questões relevantes sobre o software,
identificação ou classificação da mudança. Porém, pode ser sendo recomendável que o relator explique o passo a passo
necessário o preenchimento de outros campos que não são para demonstrar como realizar a mudança.
obrigatórios. O campo “Categoria” é geralmente definido A Figura 2 apresenta a tela para preenchimento da abertura
como um dos tipos de módulos do projeto de software, de uma mudança.
podendo conter opções como relatórios, cadastros ou cál-
culos, ou até mesmo alguma configuração específica do
software, ou seja, uma biblioteca de componentes. Para
obter as categorias específicas para cada projeto, o usuá-
rio administrador do Mantis deverá inseri-las por projeto
de software através do comando “Gerenciar” disponível
na barra de menu e, em seguida, selecionar “Gerenciar
Projetos”.
Logo após, o campo “Frequência” deve ser preenchido
caso haja necessidade. Esse campo normalmente é preen-
chido quando o pedido de modificação é em decorrência de
incidente de erro no software. Neste caso, existem opções
nesse campo que permitem delimitar se o incidente é rein-
cidente. Caso seja, pode-se escolher a opção “Sempre” ou,
se ele nunca ocorreu, a opção “N/D” pode ser escolhida.
O campo “Prioridade” também não é obrigatório, mas tem
impacto na classificação e identificação de uma mudança,
ou até mesmo para mensurar a quantidade de mudanças
aberta por prioridades. Existem três opções nesse campo
que devem ser escolhidas como Prioridade, são elas: “Alta”, Figura 2. Campos para identificação e registro de uma mudança.
“Média” ou “Baixa”. Esta classificação é muito importante,
porque é com base nela que a priorização para correção Quando o registro de uma mudança é finalizado, o gerente
do defeito ocorrerá. Desse modo, a classificação incorreta ou a equipe de software são notificados por email, podendo
poderá causar um atraso na ordem de correção do defeito, então realizar a confirmação, ou até mesmo, a rejeição da mu-
uma vez que defeitos com alta prioridade são geralmente dança. Se o gerente descartar o relato, o registro passa para o
corrigidos em um espaço de tempo menor que os outros. status de Fechado no sistema. Caso contrário, ele é confirmado
Em seguida, após o preenchimento do campo para defi- e atribuído para o desenvolvedor, que automaticamente será
nição da frequência, o campo “Gravidade” também serve notificado por um email. A Figura 3 mostra a tela de realiza-
para apoiar na identificação e definição de uma mudança ção da atribuição.
no projeto de software, podendo ser classificado como
Mínimo, Pequeno ou Grande. Este campo também não é
obrigatório, mas dependendo do seu conteúdo pode servir
para alertar ao gerente de configuração, quais mudanças
que possuem mais ou menos impacto para o projeto devido
ao nível de gravidade.
A escolha de um perfil permite que o registro de uma Figura 3. Tela para Atribuição de um Caso para um desenvolvedor
mudança esteja de acordo com as configurações do software,
ou seja, é possível criar um perfil com a plataforma, sistema Controle de mudanças
operacional (SO) e versão do sistema operacional usados Como visto anteriormente, o Mantis permite uma identifi-
pelo relator, ao invés de preencher os mesmos campos dis- cação detalhada de uma mudança. Além da identificação das
poníveis no relato de caso. Outros campos que também não mudanças, também é possível o controle por meio da seleção
são obrigatórios, mas que contribuem bastante na identifi- de status a cada alteração do ciclo de vida de uma mudança.
cação de uma mudança, são os campos “Build do Produto” A cada atribuição de status, a mudança recebe uma cor, fa-
e “Atribuir a”. O primeiro permite a digitação da versão do cilitando bastante a leitura da situação de uma mudança. A
software, já o segundo permite que a mudança seja direcio- alteração do status deve obedecer a uma ordem no ciclo de
nada a um analista ou desenvolvedor específico. vida, possibilitando a interação dos gerentes e desenvolvedo-
Finalmente, os campos “Resumo” e “Descrição” do defei- res, onde cada status tem uma finalidade bem definida, como
to contribuem para descrever do que se trata a mudança, mostra a Tabela 1.

Edição 20 - Engenharia de Software Magazine 45

 Nome Descrição
1. O relator descreve uma mudança, que é enviada com o
Novo Quando uma mudança está aberta status Novo;
Atribuído Quando uma mudança está atribuída a algum membro da equipe de software 2. O gerente é notificado pelo Mantis e atribui o caso a um
Retorno Quando a mudança foi retornada para o relator, e precisa de algum tipo de alteração desenvolvedor, onde o mesmo é notificado;
3. O desenvolvedor, opcionalmente, pode solicitar esclareci-
Reconhecido Quando a mudança é admitida na aplicação
mentos ao relator, onde a mudança é retornada com o status
Confirmado Quando mudança é confirmada e a correção é iniciada
de Retorno;
Resolvido Quando a mudança é resolvida pelo desenvolvedor 4. O desenvolvedor analisa e altera o produto de software, se
Fechado Quando a mudança já foi testada e o produto de software disponibilizado para produção nenhum retorno for necessário, a mudança é colocada com o
status Resolvido, onde o relator e o gerente são notificados.
Tabela 1. Status existentes no Mantis para controle do ciclo de vida de
uma mudança Para mudar o status de uma mudança, o desenvolvedor deve
utilizar a tela apresentada na Figura 5.
Os passos a seguir descrevem resumidamente o processo de
ciclo de vida de uma mudança aberta no Mantis. Em seguida, a Relatórios e Estatísticas
Figura 4 mostra um diagrama representando como os usuários Além da identificação e controle de mudanças em projetos
do Mantis podem interagir na resolução de uma mudança em de software, o Mantis permite aos gerentes e desenvolvedores
um produto de software. analisarem as mudanças por meio de relatórios detalhados ou
resumidos. Tais relatórios podem ser impressos ou exportados
para alguns aplicativos como o Microsoft Word, o Internet
Explorer, Microsoft Excel, ou podem ser gravados em formato
CSV. Também é possível a impressão de diversas mudanças ao
mesmo tempo. A Figura 6 mostra a visualização do relatório
de uma mudança.
Além da exportação e impressão de relatórios, o Mantis per-
mite a consulta e análise de todas as mudanças, tanto para um
projeto quanto por todos os projetos criados. Isso é possível
através do menu “Resumo” existente em seu menu principal
(Figura 1). O Mantis apresenta várias opções para análise das
mudanças, como as estatísticas do tempo de resolução e os
números sobre as mudanças atribuídas por desenvolvedor.
Estas funcionalidades podem contribuir para que o gerente
do projeto possa acompanhar o nível do serviço executado,
como também controlar e mensurar a quantidade de mudanças
e a eficiência da equipe de desenvolvimento e manutenção. A
Figura 4. Ciclo de Vida de uma mudança

Figura 5. Atribuição de status para uma mudança

Figura 6. Relatório de uma mudança

46 Engenharia de Software Magazine - Introdução ao Mantis


Figura 7 apresenta um exemplo da tela de resumo, listando
todos os projetos cadastrados. Em seguida, a Figura 8 mostra
dois quadros sobre as estatísticas de tempo para casos resolvi-
dos e estatísticas das mudanças por desenvolvedores.
Figura 7. Resumo de mudanças por projeto
Figura 8. Estatísticas de Tempo para Casos Resolvidos e Desenvolvedores
Considerações Finais
O Mantis é uma ferramenta que implementa várias funcionali-
dades que contribuem para a realização das atividades descritas
por Dart (1991) sobre a GCS. Ou seja, permite a identificação, o
controle e a extração de dados estatísticos sobre as demandas
realizadas. Esta ferramenta possui portabilidade entre vários
ambientes e sistemas operacionais, sendo amplamente utilizada
por equipes e empresas de tecnologia da informação. Tornando-
se muito útil para os profissionais de TI, o Mantis possibilita que
a fase de manutenção em um software seja realizada de forma
projeto
segura e com uma maior qualidade, registrando e controlando
as mudanças que ocorrem no software. Desta forma, os resul-
tados obtidos serão um processo de manutenção de software
com grandes melhorias, e um produto de software melhor, de
acordo com as necessidades dos usuários.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine
sobre e
tem que ser feita ao seu gosto.
s
ta
edição
Para isso, precisamos saber o que você,leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Referências
DART, Susan. Concepts in configuration management systems, Proceedings of the 3rd
international workshop on Software configuration management, p.1-18, June 12-14, 1991.
DIAS, Márcio Greyck Batista ; ANQUETIL, N. Proposta de uma disciplina sobre manutenção de
software nas graduações em computação. In:Workshop sobre Educação em Computação (WEI),
2005, São Leopoldo, RS. XIII Workshop sobre Educação em Computação, 2005.
JACOBSON, I., GRADY, B., RUMBAUGH, J. The Unified Software Development Process. Addison
Wesley Professional, 1999.
Mantis. Disponível em: http://www.mantisbt.org/. Acesso em: 25 de out. 2009.
MURTA, Leonardo Gresta Paulino. Gerência de Configuração no Desenvolvimento Baseado
em Componentes. 2006. 213 f. Tese (Doutorado em Engenharia de Sistema e Computação) –
COPPE-Universidade Federal do Rio de Janeiro, 2006.
PRESSMAN, Roger S. Engenharia de Software. São Paulo, 6 Ed. McGrawHill, 2006.
SHAHARI, Hamid Haidarian, HENDLER, James, PORTER, Adam Porter. Software Configuration
Management Using Ontologies. Proceedings of the 3rd International Workshop on Semantic
Web Enabled Software Engineering at the 4th European Semantic Web Conference (ESWC’07),
Innsbruck, Austria, June 6-7, 2007.
Sommerville, Ian. Engenharia de Software. 6ª. ed. São Paulo: Pearson Addison
Wesley, 2003.
Edição 20 - Engenharia de Software Magazine 47
 Atividades Aliadas dos Testes de Software
Melissa Barbosa Pontes
melissa.pontes@cesar.org.br
Mestre em Engenharia de Software do Cesar Edu.
Certificada em testes de software pelo ISTBQ (In-
ternational Software Testing Qualification Board),
atualmente trabalha como engenheira de testes
no CESAR (Centro de Estudos e Sistemas Avança-
dos do Recife), onde desempenha atividades de
definição de processos, liderança e consultoria. É
integrante do GrIT (Grupo Independente de Testes
do Cesar) através do qual realiza pesquisas e trei-
namentos em testes na organização. Possui artigos
e trabalhos publicados em eventos internacionais.
É membro integrante da comissão de organização
de EBTS - Encontro Brasileiro de Testes de Software,
que já se encontra na quarta edição. Ministra cursos
de Testes de Software em faculdades.
Luiz Fernando Rodrigues Corrêa
de Barros
luiz.fernando@cesar.org.br
Mestre em Engenharia de Software do Cesar.EDU,
especialista em Tecnologia da Informação pela
UFPE, especialista em Planejamento e Gestão Or-
ganizacional pela FCAP-UPE. Certificado em testes
de software pelo ISTBQ (International Software
Testing Qualification Board), certificado Sun Certi-
fied Programmer for the Java 2 Platform 1.4, atu-
almente trabalha como engenheiro de sistemas no
CESAR (Centro de Estudos e Sistemas Avançados do
Recife), onde desempenha atividades de identifica-
ção e desenvolvimento/adoção de ferramentas que
auxiliem na performance de times de testes.
48 Engenharia de Software Magazine - Atividades Aliadas dos Testes de Software
A
qualidade de um software pode
estar relacionada à existência
de defeitos inseridos durante
o seu desenvolvimento ou manutenção.
Entende-se por defeitos uma inconsis-
tência em um componente ou sistema
que o impeça de funcionar corretamente
(Grahan, et al. 2006).
Dependendo da severidade do defeito
encontrado em aplicações, diversos
podem ser os prejuízos que este pode
causar aos seus usuários. Alguns artigos
e sites chegam a enumerar o que autores
consideram os piores defeitos de todos
os tempos. Um exemplo é a lista feita por
Paul Bourdeaux, publicada em fevereiro
de 2009, com o título Top Ten Most Infa-
mous Software Bugs Of All Time.
Entre os defeitos enumerados nestes
sites e artigos estão:
De que se trata o artigo?
Este artigo apresenta diversas atividades que
podem ajudar no direcionamento das ativida-
des de testes de software. Para cada ativida-
de, é apresentada sua definição. Em seguida,
são apresentados alguns benefícios e algumas
dificuldades que podem surgir durante sua
realização.
Para que serve?
Fornecer a gerentes, líderes e demais integrantes
de equipes de desenvolvimento e testes de sof-
tware algumas opções para ajudar na condução
das atividades de testes.
Em que situação o tema é útil?
Conhecer e aplicar algumas das atividades
mencionadas neste artigo pode ajudar a
minimizar os custos de um projeto de de-
senvolvimento de software através do dire-
cionamento das atividades de testes.
• Erros de conversão de unidades, acar-
retando em grandes prejuízos financei-
ros como a perda da nave espacial Mars
Climate Orbiter da NASA, em setembro
de 1999;

• Desvio de rota da sonda Mariner 1, em curso para marte,
por erro na transcrição de uma fórmula;
• Desintegração do foguete Ariane 5 por causa de um defeito
em uma função aritmética.
Uma das maneiras de se identificar os defeitos é através
das atividades de testes de software. Testes de software são
atividades realizadas em um projeto com o objetivo principal
de contribuir com a qualidade dos produtos gerados. Para
alcançar este objetivo, a equipe do projeto deve alcançar
objetivos menores, como encontrar defeitos nos artefatos do
projeto, avaliar se o sistema foi construído como deveria,
analisar o desempenho do sistema em uso para verificar se
está de acordo com o esperado, ou verificar se tudo que foi
especificado foi realmente desenvolvido, etc. Esses objetivos
podem mudar de acordo com a estratégia de testes defini-
da, mas principalmente de acordo com as fases de testes.
Além disso, os testes de um sistema podem ser de tipos e
abordagens variadas. Isso faz com que as atividades de tes-
tes representem grande parte dos recursos de um projeto,
chegando a consumir entre 30% e 50% do esforço total de
desenvolvimento (Sommerville, 2004).
Por isso, quanto mais otimizado o esforço de testes em um
projeto, maiores são as chances de sucesso. Então, para contri-
buir com a efetividade das tarefas de testes, existem diversas
atividades que podem ser desempenhadas pela equipe. No
entanto, nem sempre o time de testes tem conhecimento da
existência dessas atividades, ou não conhece os benefícios que
elas podem trazer para um projeto.
O foco deste artigo é abordar diversas maneiras de aumentar
as chances de sucesso nos testes de um software, através do
desempenho de atividades como: análise de defeitos escapa-
dos, análise de causa raiz, taxonomia de defeitos, injeção de
faltas, predição e prevenção de defeitos em software. Para cada
uma das atividades mencionadas, são apresentados alguns
benefícios e algumas dificuldades. Não é o objetivo deste artigo
esgotar todas as possibilidades nesse levantamento.
Análise de Defeitos Escapados (Escaped Defects
Analysis - EDA)
De acordo com Gilleran (2002), análise de defeitos escapados
pode ser entendida como sendo a análise dos defeitos que es-
capam de uma fase de testes para outra, bem como a análise
dos defeitos que são encontrados pelos clientes. Entender o
motivo pelo qual os defeitos não foram encontrados no momen-
to adequado, isto é, na fase de testes adequada, possibilitam
subsídios para a melhoria de artefatos de testes e até a revisão
do processo seguido.
A primeira coisa a ser feita é entender o que motivou o
aparecimento do defeito. Dentre os diversos motivos, pode-
mos citar: falta de cobertura apropriada das suítes de testes;
falta de entendimento na execução dos casos de teste; falta de
conhecimento de funcionalidades do sistema; falta de tempo
para executar grande parte dos testes; inexperiência do time de
testes; erros em documentações do projeto; e indisponibilidade
Verificação & Validação
de um ambiente equivalente ao ambiente de produção, onde o
sistema será utilizado. Diante de tantas causas que podem levar
um defeito a chegar ao cliente, não se deve “culpar” o time de
testes por não ter encontrado todos os defeitos, principalmente
porque um dos princípios básicos de testes bem conhecidos na
literatura é que é inviável, praticamente impossível, assegurar
que a aplicação foi 100% testada e não apresenta defeito algum
(Grahan, et al. 2006).
Benefícios
• Ajudam a identificam falhas na cobertura que os ciclos de
testes dão ao sistema;
• Identificam pontos de melhoria no processo utilizado;
• Identificam necessidades de capacitação da equipe do pro-
jeto, não se limitando ao time de testes;
• Antecipam a identificação de defeitos similares aos que
escaparam, tornando sua correção menos custosa.
Desafios
• Obtenção de informações de defeitos abertos em todas as
fases de testes do projeto. O acesso a estas informações nem
sempre é possível;
• Falta de informação, tais como versão do software e hardware
onde o problema foi identificado. Apesar de serem informa-
ções simples, estes dados nem sempre são registrados como
deveriam;
• Interpretação adequada dos relatos de defeitos. Muitas ve-
zes os defeitos são relatados de maneira muito resumida, ou
confusa, dificultando a sua reprodução.
Taxonomia dos Defeitos
É a classificação de defeitos em categorias. Esta classificação
serve de base para a identificação dos tipos de defeitos que
acontecem no sistema e permite agrupá-los para conhecer
melhor o produto e suas áreas de maior risco. Um defeito
pode estar relacionado com uma ou mais categorias. À me-
dida que a análise é realizada, mais categorias podem surgir
para que a classificação seja o mais fiel possível à realidade do
projeto. Alguns exemplos de categorias onde defeitos podem
ser enquadrados são: omissão de informação, informações
inconsistentes, erro na geração da informação, pouco nível de
profundidade dos testes realizados, falta de entendimento dos
objetivos dos testes, dentre outras.
Benefícios
• Embasam a melhoria do processo utilizado no projeto (Ro-
binson, 2008) através do conhecimento dos problemas que
ocorrem com frequência;
• Ajudam a entender as características do produto;
• Identificam pontos de melhoria no código do sistema.
Desafios
• Acesso às informações do projeto. Deve haver uma garantia
de acesso sempre que necessário aos mesmos tipos de docu-
mento que serão analisados no decorrer do projeto;
Edição 20 - Engenharia de Software Magazine 49
• Estabelecimento da dimensão da classificação (Wagner, 2008).
Como geralmente são analisados diferentes tipos de artefatos,
deve haver uma padronização nas categorias definidas para
os defeitos.
Injeção de Faltas
Segundo Weber (2007), injeção de faltas em software é uma
técnica experimental de validação. Injetar faltas para avaliar o
comportamento do sistema pode ajudar a entender como este
se recupera de falhas. Esta atividade geralmente é realizada
através de ferramentas, e de maneira controlada. De outra
maneira, a análise pretendida poderia ter a sua qualidade
comprometida. Em artigo apresentado no REVVIS (Reunião
de Especialistas em Verificação e Validação de Software), no
ano de 2007, Weber menciona algumas ferramentas (injetores
de faltas) desenvolvidas por um grupo de pesquisas da UFRGS
(Universidade Federal do Rio Grande do Sul).
Benefícios
• Permite avaliar o comportamento do sistema na presença
de falhas reais;
• Permite otimizar o esforço de desenvolvimento, já que desen-
volvedores entendem melhor como os defeitos ocorrem;
• Permite otimizar o esforço de testes (Madeira, 2007);
• A injeção das faltas pode ser feita através de ferramentas.
Desafios
• Injetar faltas de maneira controlada;
• Discernir entre faltas que realmente são importantes de faltas
cuja análise não agrega valor.
A modificação de processos de testes para incluir atividades
de injeção de faltas já acontece há algumas décadas no Brasil
e em outros países do mundo. O assunto já era tratado na aca-
demia no final dos anos 80, mas o foco eram sistemas críticos.
Hoje em dia já é possível encontrar relatos de estudos de caso
em pequenos sistemas.
Predição de Defeitos
É a tentativa de antecipação da localização de defeitos em
uma aplicação, antes que eles ocorram, viabilizando ações
corretivas o quanto antes.
A predição de defeitos se dá através da aplicação de técnicas
variadas, que analisam informações coletadas dos projetos, e
tentam prever o comportamento de versões futuras do códi-
go. Modelos de predição podem identificar, por exemplo, se
determinado módulo da aplicação está ou não propenso ao
aparecimento de defeitos, estimar a quantidade de defeitos
que podem aparecer em um módulo, estimar a densidade de
defeitos ou ainda, identificar quais módulos podem apresentar
maiores quantidades de defeitos.
Benefícios
• Dá suporte a geração de informações para suporte ao plane-
jamento das atividades de testes;
50 Engenharia de Software Magazine - Atividades Aliadas dos Testes de Software
• Melhor direcionamento das atividades de testes para áreas
da aplicação que apresentam maiores riscos;
• Ide nt i f ic aç ão de p o nto s de mel hor i a no c ó d igo
desenvolvido;
• Análise do progresso do projeto, em termos de percentual
de defeitos encontrados;
• Planejamento de desenvolvimento de iterações futuras.
Desafios
• Garant ir que todos os defeitos encontrados serão
registrados;
• Dificuldade de isolamento da localização exata do módulo
onde ocorreu o defeito, quando as informações registradas
não estão muito precisas;
• Falta de acesso às informações do projeto, seja por confiden-
cialidade ou por falta delas;
• Indisponibilidade de recursos alocados. Esta atividade exige
uma criteriosa análise das informações obtidas, e é necessária
uma alocação formal para sua condução.
Confiança na qualidade dos dados coletados é fundamental
para a realização de um bom trabalho de predição de defeitos.
Por isso, a coleta de dados dos projetos deve ser planejada e
monitorada.
Mais detalhes sobre este tema podem ser encontrados no
artigo Predição de Defeitos em Software, publicado na Edição 17
da Engenharia de Software Magazine.
Prevenção de Defeitos
Segundo Lanier (2004), prevenção de defeitos é o processo
de analisar as causas que originaram estes defeitos com o
objetivo de prevenir a ocorrência do problema no futuro. Não
necessariamente as causas que levam a defeitos são analisa-
das em um projeto só em uma empresa. O ideal é que sejam
analisados vários projetos para identificar se os problemas se
repetem entre as equipes. Dessa maneira, ações de melhoria
em um projeto podem servir de exemplos para toda a empresa,
fazendo com que diminua o esforço gasto pelas equipes na
tentativa de resolver o mesmo problema diversas vezes.
Prevenir defeitos em um projeto é uma tarefa de melhoria
do processo de desenvolvimento. O nível de maturidade 5 do
CMMI inclui atividades de prevenção de defeitos e resume o
processo da seguinte maneira:
• É feito um planejamento das atividades de predição de
defeitos;
• As causas do aparecimento de defeitos são identificadas;
• As causas do aparecimento de defeitos são priorizadas e
eliminadas.
A eliminação dessas causas deve ser considerada uma ação pre-
ventiva. Espera-se com isso que este não ocorra mais no futuro.
Prevenção de defeitos é diferente de predição de defeitos. Na
prevenção, existem ações para que o defeito não ocorra. Na
predição, apenas tenta-se antecipar a localização do defeito
que já está no código.

Benefícios
• Espera-se uma diminuição no esforço com atividades de
correção de defeitos e manutenção do produto;
• Certamente haverá confiabilidade na imagem do produto
no mercado;
• Cada medida de prevenção tomada contribuirá para a me-
lhoria do processo de desenvolvimento.
Desafios
• Identificar oportunidades de treinamentos para a equi-
pe do projeto baseando-se nos tipos de defeitos que são
encontrados;
• Identificar ações que levam a defeitos antes que estes ocorram
(Chang, 2006).
Priorização de Testes de Regressão
Testes de regressão são os testes realizados em um sistema onde
um dos objetivos é verificar se a inclusão de novas funcionali-
dades ou a correção de defeitos e outros tipos de modificação
do código não provocaram efeitos colaterais, introduzindo
novos defeitos, ou fazendo com que funcionalidades deixem de
operar corretamente. Neste contexto, a regressão é feita através
da execução dos casos de testes existentes. Estudos relatam que
quando há priorização desses casos de teste, a taxa de detecção
de defeitos aumenta.
O ideal seria que num ciclo de testes de regressão fossem inclu-
ídos todos os testes das suítes do projeto e ainda todos os defeitos
já registrados, mas nem sempre isso é possível. Por isso, é comum
a prática de classificar os casos de teste de uma suíte em níveis de
prioridade. Por exemplo, pode-se classificar os testes com os níveis
variando de 1 a 5, onde os casos de teste que apresentam nível 1
podem testar áreas mais críticas do sistema. Dessa maneira, quan-
do há a necessidade da realização de testes de regressão e não há
tempo para a realização de regressão total, pode-se criar um ciclo
com os testes considerados mais importantes das suítes.
Mas nem sempre é suficiente simplesmente selecionar casos
de testes baseando-se em níveis de prioridade. Geralmente é
necessário selecionar um subconjunto de testes adequado a um
contexto específico. Vários autores apresentam técnicas de seleção
de casos de testes para regressão.
Alguns autores priorizam para testes os requisitos da aplicação,
e rastreiam quais casos de teste certificam os requisitos escolhi-
dos. Outros fatores servem como base para priorização, tais como:
áreas de risco, funções complexas, código muito modificado e
áreas do código que devem ser cobertas, por exemplo.
Benefícios
• Aumentam a efetividade da seleção de casos de teste (Li,
2007);
• Diminuem os custos da regressão, podendo até diminuir
a quantidade de testes executados em um ciclo, mantendo o
objetivo da execução;
• Permitem rápido feedback sobre a aplicação;
• Permitem a correção de defeitos mais graves o mais cedo
possível, já que os testes são priorizados por risco.
Verificação & Validação
Desafios
• Dependendo de como é realizada, pode se tornar uma
atividade cara para o projeto;
• Entender que fatores em um projeto influenciam na seleção
de casos de teste;
• Manutenção da suíte de testes para que o processo de se-
leção seja confiável.
Análise de Suítes de Teste
Periodicamente, é fundamental que seja feita uma aná-
lise das suítes de testes de um projeto, assim como deve
ser feita uma análise dos resultados das execuções das
mesmas e da estratégia de testes utilizada. Esta análise
busca identificar casos de testes problemáticos, testes que
estão sempre passando nas execuções, testes que checam
funcionalidades que já não existem no sistema ou que
tiveram o seu comportamento modificado.
Uma vez que os casos de testes são executados, algumas
inconsistências podem ser reveladas nos roteiros que devem
ser seguidos. Em geral, são encontrados problemas que não
são pegos em inspeções dos artefatos de teste como um
caminho errado a ser seguido pelo testador ou um compor-
tamento diferente do que está escrito no teste. Isso não quer
dizer, necessariamente, que o software apresenta defeito,
mas pode indicar que os testes estão com problemas.
Benefícios
• Identificar casos de testes que estão sempre passando nos
ciclos. Em situações em que é preciso priorizar testes para
a execução, talvez os casos de teste que há algum tempo
não ajudam a encontrar defeitos possam ser retirados do
escopo da execução;
• Identificar casos de testes que estão sempre falhando. Caso
os testes estejam sempre falhando e os defeitos no software
não sejam consertados, há a possibilidade de o teste está
verificando algo que não seja importante para a aplicação;
• Permite avaliar a qualidade da escrita dos casos de
teste.
Desafios
• Algumas vezes os resultados de testes de diferentes níveis e
fases são conflitantes. Por exemplo, em uma fase A, 65% dos
testes estão passando. Já na fase B, 95% dos testes passam.
Neste caso, uma análise mais aprofundada das suítes das
duas fases deverá ser realizada para avaliar qual das duas
está coerente com a qualidade apresentada pelo software;
• Suítes de testes muito grandes (contendo muitos casos
de teste) podem tornar custosa esta atividade;
• Manter uma matriz de rastreabilidade de requisitos para
casos de testes sempre atualizada. Dessa maneira, sempre
que alterações de escopo e funcionalidades forem feitas no
projeto, será menos custoso identificar quais testes devem
ser retirados de ciclos de execução, ou quais artefatos do
projeto devem sofrer modificações impactadas pela alte-
ração ocorrida.
Edição 20 - Engenharia de Software Magazine 51
Conclusões Referências
As atividades apresentadas neste artigo propõem alterna- Top Ten Most Infamous Software Bugs Of All Time
tivas para ajudar a aumentar a efetividade das atividades
TOMASZEWSKI, P.; GRAHN, H.; LUNDBERG, L. A Method for an Accurate Early Prediction of Faults
de testes de software, e como consequência, espera-se uma
in Modified Classes. In: 22nd IEEE International Conference on Software Maintenance, 2006,
contribuição melhor para a identificação de problemas no
Philadelphia, USA, 2006. p. 487-496.
produto desenvolvido. Entretanto, utilizar as informações
https://www.inf.fu-berlin.de/w/SE/DefectTaxonomy
adquiridas com a realização dessas atividades como única
fonte de direcionamento das atividades de testes pode Ferramentas de Injeção de Falhas de Comunicação para a Validação Experimental de Aplicações
acarretar em problemas para o projeto. Um exemplo é testar de Rede , revvis 2007
somente módulos da aplicação que foram indicados como
propensos ao aparecimento de defeitos. O risco é deixar Research on software V&V at University of Coimbra: injection of software faults, revvis 2007
escapar defeitos simplesmente por deixar de testar alguns System Test Case Prioritization of New and Regression Test Cases, Hema Srikanth, Laurie
módulos. Dessa maneira, as técnicas apresentadas devem Williams, Jason Osborne
ser utilizadas para priorizar áreas de risco e melhorar a Search Algorithms for Regression Test Case Prioritization, Zheng Li, Mark Harman, Robert M.
efetividade do processo de desenvolvimento, mas não Hierons, 2007.
devem ser o único direcionamento da equipe no momento
de testar. Inspeção de documentos de requisitos baseado em tecnica de leitura PBR: Experiência prática
no CPqD, Miriam Freitas

Dê seu feedback sobre esta edição! Feedback

eu A defect-driven process for software quality improvement, Brian Robinson, Patrick Franci,
s
Dê

Fredrik Ekdahl
A Engenharia de Software Magazine
sobre e

tem que ser feita ao seu gosto. Defect Classification and Defect Types Revisited, Stefan Wagner
s

ta
edição
Para isso, precisamos saber o que você, leitor, acha da revista! Experiences in Root Cause Analysis and Defect Prevention Methods, Kelly L. Lanier
Dê seu voto sobre este artigo, através do link:
CMMI http://isb.wa.gov/policies/portfolio/tr25/tr25_l5a.html - Defect Prevention a key
www.devmedia.com.br/esmag/feedback process area for level 5: Optimizing

Defect prevention in software processes: An action-based approach, Ching-Pao Chan and Chih-
Ping Chu

SOMMERVILLE, I. Software Engineering. Addison Wesley, 2004

52 Engenharia de Software Magazine - Atividades Aliadas dos Testes de Software

User Experience
Obtendo Dados com Testes de Usabilidade
Antonio Mendes da Silva Filho
antoniom.silvafilho@gmail.com
Professor e consultor em área de tecnologia
da informação e comunicação com mais de
20 anos de experiência profissional, é autor do
livros Arquitetura de Software e Programan-
do com XML, ambos pela Editora Campus/El-
sevier, tem mais de 30 artigos publicados em
eventos nacionais e internacionais, colunista
para Ciência e Tecnologia pela Revista Espaço
Acadêmico com mais de 60 artigos publicados,
tendo feitos palestras em eventos nacionais e
exterior. Foi Professor Visitante da University
of Texas at Dallas e da University of Ottawa.
Formado em Engenharia Elétrica pela Uni-
versidade de Pernambuco, com Mestrado em
Engenharia Elétrica pela Universidade Federal
da Paraíba (Campina Grande), Mestrado em
Engenharia da Computação pela University of
Waterloo e Doutor em Ciência da Computação
pela Univesidade Federal de Pernambuco.
O
projeto de qualquer produto re-
quer do projetista a habilidade
de examinar fatores que deter-
minam (1) o tipo de produto que você
quer desenvolver, (2) a informação que
será exibida, (3) a interface de usuário, (4)
o padrão de uso do produto e a (5) inte-
ração do usuário com o produto. Perceba
que esses fatores compreendem a base
do que é denominado “user experience”.
Mas, o que é user experience? Trata-se da
experiência do usuário quando interage
com produtos ou serviços. Aqui, produto
pode ser qualquer coisa como, por exem-
plo, um fogão, uma maçaneta de porta,
um painel de automóvel ou um software.
Edição 20 - Engenharia de Software Magazine
De que se trata o artigo?
Apresenta user experience, seus fatores e como
essas informações podem ser utilizadas na ob-
tenção de dados durante testes com usuário
para identificar problemas de usabilidade de
produtos.
Para que serve?
Orientar a usar teste com usuários como um mé-
todo de inspeção de usabilidade complementar
a outros métodos como, por exemplo, avaliação
heurística e percurso cognitivo (ou cognitive
walkthrough), bem como definir critérios quan-
titativos de avaliação da usabilidade de produ-
tos ou serviços.
Em que situação o tema é útil?
A avaliação da usabilidade de produtos ou
serviços pode ser feita utilizando-se avalia-
ção heurística e percurso cognitivo. Entretan-
to, esses métodos não identificam todos os
problemas de usabilidade em produtos como
sistemas de software e aplicações web com
grande quantidade de funcionalidades, exi-
gindo testes com usuários a fim de capturar
problemas de usabilidade não identificados
por outros métodos.
53
Qualquer desses produtos, ou até serviços (como oferecidos
em web sites), têm a usabilidade como atributo determinante
da qualidade perceptível aos usuários. Tudo isso nos remete a
uma característica importante a qualquer produto ou serviço:
simplicidade. Antoine de Saint-Exupery é preciso ao dizer:
“Você sabe que alcançou a perfeição no design,
Não quando nada mais você tem a adicionar,
Mas sim quando nada mais você tem a remover.”
Este artigo trata de user experience e como essa informação
pode ser usada no projeto e avaliação da usabilidade de
produtos.
Usabilidade
A usabilidade é uma característica de um produto ou ser-
viço que informa quão fácil de usar e aprender esse produto
(ou serviço) é. Em outras palavras, serve como um indicador
de quão intuitivo é utilizar aquele produto (ou serviço).
Perceba que essa característica influencia diretamente o
interesse do usuário em utilizar ou não esse produto ou
serviço. No entanto, em sistemas de software, assim com
em outros produtos, a usabilidade é avaliada não apenas
quando o produto está pronto, mas também durante todo
o processo de desenvolvimento visando assegurar o nível
desejado de usabilidade.
Observe que a interface de usuário é determinante em di-
versos aspectos. Um resultado direto disso é que as interfaces
bem projetadas aumentam o grau de eficiência com que o
usuário realiza as suas tarefas. Isto tem impacto direto na
produtividade de uma organização além de satisfação sub-
jetiva no uso do sistema pelo usuário. E mais, isso também
reduz os custos de apoio ao usuário tais como treinamento e
atendimento ao usuário. O projeto da interface de usuário de
um produto leva em consideração a experiência do usuário
na interação com o produto. Em que situações isso acontece?
Quando a interface de usuário se insere naturalmente no
ambiente de trabalho do usuário, tornando a realização de
tarefas eficiente.
User Experience
O projeto de um produto requer que você (projetista) consi-
dere um conjunto de fatores, listados abaixo:
1. O tipo de produto que você quer desenvolver;
2. A informação que será apresentada ao usuário;
3. A interface de usuário do produto (ou serviço);
4. O padrão de uso do produto (ou serviço);
5. A interação do usuário com o produto.
O objetivo ao apresentar esses fatores não é o de ser completo,
mas de identificar ‘fatores’ que contribuem e afetam a expe-
riência do usuário (user experience) no ‘uso’ de um produto ou
serviço. Costumo denominar esses fatores como a ‘pirâmide’,
que compreende a base da user experience, como ilustrado na
Figura 1.
54 Engenharia de Software Magazine - User Experience
Figura 1. Pirâmide da user experience
É importante ressaltar que os fatores acima estão diretamente
relacionados com a experiência do usuário na forma que o
usuário ‘percebe’ e interage com o produto ou serviço. Isso
compreende a user experience. Nielsen e Norman a definem
dizendo que:
“User experience compreende todos os aspectos da inte-
ração do usuário final com a organização, seus serviços e
seus produtos. O primeiro requisito para um experiência
de usuário é atender às necessidades exatas do cliente de
maneira objetiva. Além disso, há a simplicidade e elegância
que geram produtos que são atrativos para o uso. A verda-
deira experiência de usuário vai além de dar aos usuários
o que eles querem ou oferecer características de uma lista
de itens solicitados. Visando obter experiência de usuário
com qualidade nos benefícios de uma organização, deve
haver uma combinação de serviços de varias disciplinas,
incluindo engenharia, marketing, projeto industrial e design
gráfico, e projeto de interface.” [Nielsen& Norman Group]
 
Agora, se você necessita projetar um produto a ser utilizado
por usuários, você deve trabalhar com a premissa de que usa-
bilidade é um requisito essencial deste produto. Para tanto,
você deve considerar diretrizes de projeto (ou user interface
design guidelines), como alguns destacados no quadro de links
deste artigo, e heurísticas de usabilidade. Essas informações
servem para guiar o projeto durante seu processo de desen-
volvimento, bem como na inspeção de usabilidade.
Existem diversos métodos de inspeção de usabilidade que
podem ser empregados para avaliar aspectos relacionados
com a usabilidade de produtos a fim de detectar problemas
de projeto e fazer recomendações para a eliminação desses
problemas. Exemplos de métodos compreendem avaliação
heurística, percurso cognitivo (cognitive walkthrough) e testes
com usuário. Vale ressaltar que problemas de usabilidade
estão diretamente associados com aspectos da interface de
usuário do produto. Tais problemas podem resultar em difi-
culdade no aprendizado e uso do produto, bem como pode
causar insatisfação do usuário e até mesmo uso ineficiente
do produto.
Com isso em mente, você, engenheiro de software no papel
de projetista e avaliador da interface de usuário de um pro-
duto ou serviço, precisa justificar o que lhe motiva a fazer a
avaliação de usabilidade. A listagem abaixo destaca situações
onde você deve considerar fazer uma avaliação:

• Identificação dos principais problemas antes de se efetuar
testes com o usuário;
• Comparação entre projetos para escolher qual projeto
investir;
• Verificação de projeto visando determinar se atende a pa-
drões projeto e recomendações de guias de estilo;
• Apoio a preparação de testes com o usuário sobre questões
não verificadas no processo de avaliação.
No entanto, as avaliações como, por exemplo, avaliação
heurística e percurso cognitivo possuem limitações quanto
ao grau de ‘cobertura’ de problemas de usabilidade veri-
ficados. Nessas avaliações, observa-se a interdependência
entre heurísticas, o que requer a participação do usuário
para indicar qual melhor alternativa a ser adotada. Além
disso, as avaliações não são boas para tratar preferências
de grupos, diferenças de ‘culturas’, compromissos aceitá-
veis pelos usuários (como apresentação e classificação de
opções, rótulos usados), além de não prover informações
suficientes para refinamento de projeto. Essas limitações
de métodos de avaliação devem ser levadas em conta para
fazer testes com usuários, como apresentado a seguir.
Testes de Usabilidade
Teste de usabilidade é um método de inspeção da usabilida-
de que visa medir a taxa de sucesso que usuários conseguem
utilizar e/ou aprender a usar um produto ou serviço para
realizar tarefas.
Um teste de usabilidade objetiva avaliar se o projeto da
interface atende às necessidades dos usuários. A pergunta
que agora você pode estar se fazendo é:
Por que testar a usabilidade?
A principal motivação para realizar testes com usuário
é eliminar uma série de argumentos e discussões sobre
a forma apropriada de fazer algo. Para exemplificar isso,
lembre-se de que a usabilidade é um elemento norteador
do processo de desenvolvimento, isto é, o desenvolvimen-
to acontece sob a ótica do usuário, buscando apoiar de
maneira natural a realização de suas atividades. E, para
tanto, os projetistas consideram heurísticas de projeto de
interface, como as heurísticas propostas por Jakob Niel-
sen (disponíveis em http://www.useit.com/papers/heuristic/
heuristic_list.html):
• Exibir o estado do sistema, oferecendo visibilidade do
status;
• Fazer o mapeamento natural entre o sistema e o mundo
real;
• Prover suporte de controle e liberdade de escolha para
usuários;
• Prover consistência e seguir recomendações de padrões;
• Priorizar a prevenção de erros de usuários;
• Minimizar a necessidade de memorização dos usuários,
priorizando o reconhecimento à recordação;
Verifica ção e Validação
• Oferecer recursos de uso eficiente e rápido da interface, tor-
nando-a flexível e customizada às necessidades dos usuários;
• Eliminar informações irrelevantes, visando prover suporte
ao projeto minimalista e à estética;
• Oferecer aos usuários mecanismos de ajuda que lhe permi-
tam reconhecer, diagnosticar e tratar erros;
• Prover os usuários de documentação e recursos de ajuda
baseadas em tarefas dos usuários.
Mas, há interdependência entre elas, o que implica numa di-
ficuldade para você, em um momento como projetista e noutro
como avaliador, em escolher a melhor alternativa. Isso mostra
que o usuário é participante essencial do processo. E, nada
melhor existe para responder a intermináveis argumentos
(e até discussões) do que dados. Você substitui os argumentos
e opiniões por dados e números. Perceba que dados fazem as
opiniões sumirem se elas não estiverem baseadas em dados
e, como conseqüência, o tempo de reuniões de avaliação são
reduzidos. Seu tempo agora passa a ser empregado para ana-
lisar e interpretar os dados.
Agora, se você ainda não está convencido da importância de
realizar testes com usuários, lembre-se de que há situações que
envolvem o risco humano ou econômico, onde a participação
do usuário no processo de inspeção da usabilidade é essencial.
Em tais situações, é imperativo a realização de testes com o
usuário. Vale ressaltar que os testes são, muitas vezes, empre-
gados como atividade complementar no processo de inspeção
da usabilidade apoiados na análise e interpretação de dados
como apresentado a seguir.
Análise e Interpretação de Dados
De um modo geral, os testes de usabilidade têm por obje-
tivo coletar dados (durante o teste) os quais são analisados
e interpretados, munindo você (projetista) de informações
sobre a usabilidade de um produto ou serviço. Dessa forma,
quando você realiza testes com usuário, você precisa obter
dados, checando:
• Desempenho dos usuários (i.e. a velocidade na qual eles
conseguem realizar as tarefas);
• Taxa de erros cometidos pelos usuários quando executando
tarefas;
• Tempo de aprendizagem para uso do produto ou software,
no qual o usuário começa como iniciante até atingir domínio
no uso do produto;
• Grau de retenção das informações exibidas pela interface
ao longo do tempo e nível de satisfação subjetiva (quando
os usuários testados expressam sua satisfação em utilizar o
produto ou software).
Embora o teste de usabilidade ajude o projetista a verificar se
a interface de usuário atende aos critérios pré-definidos, o grau
de confiabilidade não é total, pois você pode estar testando
usuários atípicos e o resultado obtido não pode ser generaliza-
do para toda população de usuários. Além disso, o teste sempre
ocorre num ambiente (i.e. numa condição) artificial.
Edição 20 - Engenharia de Software Magazine 55
 Lembre-se de que quando você decide realizar testes com
usuários em complemento a outro método de inspeção de
usabilidade, você quer identificar áreas de problemas que não
foram capturadas antes, bem como necessita efetuar uma revi-
são ou ‘ajuste’ no projeto de modo a atender às necessidades
do usuário. Mas, como você deve fazer isso?
Note que você precisa de uma metodologia (isto é, um con-
junto de passos) descrevendo as atividades que você precisa
realizar, a ordem na qual essas atividades devem acontecer,
o que cada atividade requer e o que cada atividade produz.
Portanto, sua atividade de testes com usuários compreende
análise e interpretação de dados. Você deve entender estas
duas atividades como sendo atividades do tipo ‘guia’ dos
testes com usuários.
Nesse sentido, na etapa de análise de dados, você precisa
obter dados quantitativos que lhe permita aferir a usabilidade.
Para tanto, você deve levantar dados como, por exemplo:
1. Tempo para realizar uma tarefa;
2. Percentual de tarefa concluído;
3. Percentual de tarefa concluído por unidade de tempo;
4. Taxa de sucessos/falhas;
5. Tempo consumido com erros;
6. Percentual de erros;
7. Número de comandos utilizados;
8. Número de comandos disponíveis não utilizados;
9. Freqüência de uso de ajuda (help) ou documentação;
10. Quantidade de vezes que o usuário lembra comandos (isto
é, retenção ao longo do tempo);
11. Número de vezes que o usuário expressa satisfação ou
frustração;
12. Avaliação subjetiva do usuário quanto ao uso do produto
ou serviço.
Note que a coleta dos dados acima pode ser feita através de
observações em testes com usuários realizados em laboratório
(de usabilidade). Adicionalmente, pode ser feita a obtenção de
dados por meio da coleta automática do ‘log’ de acesso e uso
dos usuários. Tudo isso pode ser complementado com entre-
vistas e questionários com os usuários.
Todavia, é importante ressaltar que a participação do usuário
em testes é de caráter voluntário e deve ser precedida da devida
assinatura de termo de concordância em fazer parte do teste.
Também, você (na condição de avaliador) deve esclarecer aos
usuários participantes que o objetivo do teste é de avaliar o
produto ou serviço, e não o usuário.
Numa segunda etapa, você precisa interpretar os dados que
são obtidos com os testes. Portanto, você deve:
1. Avaliar os dados obtidos segundo critérios de usabilidade;
2. Priorizar problemas de usabilidade mais severos;
3. Identificar a criticalidade dos erros;
A fase de interpretação visa levantar informações que lhe
permita aferir a usabilidade da interface de usuário de um
produto ou serviço. Para tanto, você deve estar interessado em
avaliar dados baseados em critérios de usabilidade:
56 Engenharia de Software Magazine - User Experience
• (A velocidade de) desempenho do usuário;
• Tempo de aprendizado do usuário;
• Avaliação subjetiva do usuário;
• Retenção do usuário;
• Taxa de erros.
Na interpretação de dados (dos testes com usuários), você
(avaliador) deve priorizar os problemas mais severos. Mas,
você questiona:
Como posso determinar a severidade de um problema de
usabilidade?
A taxa de severidade de um problema da usabilidade (de um
produto ou serviço) pode ser determinada por um conjunto
de fatores que compreendem:
• Tempo exigido para completar uma tarefa;
• Número de usuários que tiveram ou encontram um
problema;
• Impacto negativo da percepção do usuário do produto ou
serviço;
• Grau de dificuldade para realizar tarefas usando o produto
ou serviço (onde você deve considerar difícil se mais de 70%
dos usuários não conseguem realizar tarefa).
Para determinar a criticalidade de erro, você considera que
a criticalidade é obtida pelo efeito combinado da taxa de seve-
ridade com a probabilidade de ocorrência, ou seja:
Criticalidade do erro = Taxa de severidade + Probabilidade
de ocorrência
Para exemplificar tudo isso que tem sido apresentado, neste
artigo o foco, deste ponto em diante, recai sobre a interface de
usuário de web sites. Para tanto, um conjunto de princípios
que devem ser considerados compreende:
1. Mantenha consistência no uso da linguagem e rótulos e
evite usar jargões;
2. Traga para o primeiro plano (isto é, a tela principal) as in-
formações mais importantes;
3. Ofereça palavras chaves para leitura rápida;
4. Evite usar animações ou sons;
5. Diferencie textos de elementos gráficos (como figuras e ícones);
6. Faça uso de links consistentes e previsíveis;
7. Agrupe conteúdo semelhante na mesma página.
Nos testes com usuários, você deve seguir um conjunto de
etapas com o objetivo de realizar os testes. E, para tanto, você
deve fazer:
• Planejamento dos experimentos;
• Determinação de tarefas típicas a serem executadas pelos
usuários;
• Determinação de protocolos e procedimentos a serem
seguidos;
• Condução da sessão de teste e registro de informações;
• Análise e interpretação das informações coletadas.
 Verifica ção e Validação

Entretanto, perceba que este artigo se concentra na última do projeto de modo a tratar os critérios de usabilidade cujo
etapa essencial para o teste com usuário. Considerando a resultado não tenha sido satisfatório.
análise e interpretação de dados de interfaces de usuário de Agora considere, por exemplo, a Figura 3 que ilustra parte
web sites, quatro propriedades analisadas e interpretadas de uma interface Web da biblioteca de uma universidade, no
compreendem: qual os usuários foram solicitados fazer renovação de livros
1. Usefulness – você verifica se o site ‘faz’ o que o usuário espera emprestados. Observe que todos os itens foram marcados para
e necessita que o web site faça para ele; renovação e o usuário simplesmente clica no botão renovar
2. Effectiveness – você verifica se o web site é fácil de usar de (indicado na figura).
modo a permitir que o usuário realize a tarefa desejada;
3. Learnability – você verifica se o web site é fácil de aprender a
usar, possibilitando ele (usuário) migrar de novato para perito
no uso do web site;
4. User Satisfaction – você verifica o quão ‘agradável’ o usuário
considera utilizar o web site.

Como visto, para você realizar um teste de usabilidade,

você precisa planejar as atividades a serem desenvolvidas e,
para cada atividade de teste, você deve selecionar as tarefas
que serão testadas, deve elaborar os procedimentos de teste,
além de preparar o ambiente no qual o teste será realizado. Figura 3. Fragmento de interface de usuário de um site
Outra questão essencial é a seleção dos usuários participantes
do teste. Após clicar no botão renovar, o usuário é levado para a tela
Considere a Figura 2 que capturou apenas parte de um site seguinte, mostrada na Figura 4.
de uma imobiliária. Num teste realizado com grupo de vinte
usuários, esses usuários foram solicitados a realizar a tarefa
de localizar informações de apartamentos disponíveis para
aluguel. Perguntou-se aos usuários: quais dos botões, dentre os
exibidos na Figura 2, você deveria clicar para realizar essa tarefa?
Este teste foi feito com pessoas já familiarizadas com consultas
na Internet, e, dentre elas, aproximadamente 50% sugeriu clicar
na opção “Como Alugar”, quase 40% sugeriu clicar em “Localize Figura 4. Fragmento de interface de usuário de um site
seu Imóvel” e os demais optaram por “Busca rápida”.
Observe que o sistema enviou um feedback informativo para o
usuário dizendo que os títulos haviam sido renovados. Entre-
tanto, quando o usuário pede para enviar um email (como com-
provante da renovação dos empréstimos dos livros), apenas o
botão “Enviar recibo por e-mail” fica desabilitado sem qualquer
outro feedback relativo à confirmação de envio do email, como
mostrado na Figura 5. Aqui, nos testes realizados com usuários,
Figura 2. Fragmento de interface de usuário de um site
novamente, cerca de 55% dos usuários expressaram que ficaram
Embora esse teste não tenha sido realizado num ambiente ‘perdidos’ sem saber se os itens haviam de fato sido renovados.
controlado (como, por exemplo, um laboratório), ele serve Alguns deles, inclusive, tentaram renovar novamente, mas sem
para mostrar como testes com usuários podem fornecer da- sucesso, já que os itens haviam sido renovados antes.
dos de quão intuitiva (isto é, quão fácil usar e aprender) uma
interface é.
Cabe ainda destacar que, do universo de usuários, metade
tenha escolhido a opção correta que era “Localize seu Imóvel”.
Outra alternativa para essa tarefa é “Busca rápida”, que oferece
um quantidade menor de recursos na busca, comparativamen-
te com “Localize seu Imóvel”, pois essa última oferece recursos
de consulta detalhada. Figura 5. Fragmento de interface de usuário de um site
Note que os dados obtidos com a realização de um teste são
usados para identificar problemas de usabilidade e, portanto, É importante observar que você deve procurar entender o
buscar corrigir para melhorar o desempenho dos usuários modelo mental do usuário a fim de prover o suporte adequado
por intermédio de um re-projeto, isto é, através da revisão às tarefas que ele precisa realizar. Para tanto, você pode usar

Edição 20 - Engenharia de Software Magazine 57

uma técnica chamada de card sort, como ilustrada na Figura 6, Conclusão
onde o usuário procura mostrar a seqüência natural para exe- User experience é considerar o usuário final de um produto,
cutar uma tarefa. Isso é útil em sites com grande quantidade ajudando-o a utilizar um produto e fazendo-o melhorar seu
de conteúdo. desempenho no uso do produto. Projetistas de interface de
usuário devem trabalhar em conjunto com o usuário, iden-
tificando suas necessidades, tentando capturar o modelo
mental do usuário através de técnicas como card sort. E testes
com usuários para aferir a usabilidade servem para identifi-
car problemas de usabilidade se eles existirem ainda, ou não
tiverem sido detectados por outros métodos de inspeção de
usabilidade.
A usabilidade impacta o desempenho e satisfação dos usu-
ários. Portanto, realizar testes com usuário não deve ser con-
siderado como um custo adicional, mas uma chance de maior
aceitabilidade do produto ou serviço.
Figura 6. Ilustração de card sort
Links
E o que um web site deve oferecer aos seus usuários para Useit.com – Jakob Niesen
passar num teste de usabilidade? O web site deve atender às http://www.useit.com
duas questões abaixo:
1. O Web site ajuda o usuário a utilizar a Internet? Ask Tog
http://www.asktog.com
2. O Web site ajuda o usuário a melhorar o uso da Internet?
Usability Gov
Se a resposta é sim às questões acima, então o web site deve http://www.usability.gov/
passar num teste com usuários. Um exemplo de web site que
Usable Web
passou nesse teste é o www.flickr.com, ilustrado na Figura 7. http://www.usableweb.com
É importante destacar que responder ‘sim’ às duas questões
acima é prover suporte a usabilidade e user experience. Bad Human Factors Design
http://www.baddesigns.com/

Dê seu feedback sobre esta edição! Feedback

eu

s
Dê
A Engenharia de Software Magazine

sobre e
tem que ser feita ao seu gosto.

s
ta
edição
Para isso, precisamos saber o que você,
leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback

Figura 7. Exemplo de site que provê suporte a usabilidade e user experience

58 Engenharia de Software Magazine - User Experience

Verifica ção e Validação

Edição 20 - Engenharia de Software Magazine 59

 Modéstia à parte, sua
melhor opção para
se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para Engenharia de Software:
Desenvolvimento .NET
profissionais de desenvolvimento
GRADUAÇÃO
e programação.
Engenharia de Computação
São programas voltados para a Análise e Desenv. de Sistemas
formação de profissionais de elite,
F ORMAÇÕES
com aulas 100% práticas, corpo
Desenvolvedor Java
docente atuante no mercado,
Desenv. Java: Sist. Distribuídos
acesso à mais atualizada biblioteca
Gestor de TI
de TI do Rio, laboratórios equipados
Desenvolvedor Web .NET 2008
com tecnologia de ponta, salas de
MCITP Server Administrator
estudo e exames.
SQL Server 2008

r/esti
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO

10 WebMobile Magazine - JavaFX Mobile: RIA para dispositivos móveis