Anda di halaman 1dari 60

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

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

C
omo uma resposta às crescentes críticos de sucesso de projetos de desenvolvimento de
pressões por inovação em pra- software conduzidos com o uso desses métodos.
zos cada vez mais reduzidos, às
necessidades de constantes mudanças Para que serve?
de requisitos e ao mau desempenho de Apresentar uma visão abrangente sobre o cenário
grande parte dos projetos de desenvolvi- atual envolvendo metodologias ágeis.
mento de software, houve um movimen-
to na comunidade de desenvolvimento Em que situação o tema é útil?
de software que deu origem aos Métodos Conhecer metodologias ágeis é cada vez mais
Ágeis. Posteriormente, o conceito-base importante na medida em que lidamos cada
deste movimento evoluiu, de uma abor- vez mais com projetos de características dife-
dagem técnica para o âmbito gerencial, renciadas que exigem, muitas vezes, aborda-
criando um novo enfoque de gerencia- gens não tradicionais de desenvolvimento.
mento de projetos – o Gerenciamento
Ágil de Projetos.
Neste artigo são apresentados o históri- limitações, as indicações de aplicação e
co, o conceito, os valores e os princípios os resultados obtidos por empresas que
Marisa Villas Boas Dias que norteiam os Métodos Ágeis, assim já os adotaram. Por fim, são discutidos
como são descritos os métodos mais os fatores críticos de sucesso de projetos
frequentemente utilizados pelas organi- de desenvolvimento de software condu-
zações. Também são exploradas as suas zidos com o uso desses métodos.

Edição 20 - Engenharia de Software Magazine 5


Definição e Origem dos Métodos Ágeis de dificuldade de aplicação e também na necessidade de mudan-
Desenvolvimento de Software ças constantes e difíceis de serem antecipadas.
Os Métodos Ágeis de Desenvolvimento de Software surgiram Schwaber (op. cit.) percebe que para que o desenvolvimento de
como uma reação aos métodos clássicos de desenvolvimento1 e software seja realmente ágil, deve-se aceitar as mudanças, ao
do reconhecimento da necessidade premente de se criar uma invés de dar foco extremo à previsibilidade. Quase que simulta-
alternativa a estes “processos pesados”, caracterizados pelo neamente, outros especialistas no assunto chegam à conclusão
foco excessivo na criação de uma documentação completa de que métodos que respondam às mudanças, tão rapidamente
(BECK, et al, 2001). Em meados dos anos 90, integrantes da quanto estas venham a surgir e que incentivem a criatividade,
comunidade de desenvolvimento de software começaram são a única maneira de enfrentar e gerenciar os problemas do
a questionar estes processos, julgando-os pouco efetivos e, desenvolvimento de software em ambientes complexos (COCK-
muitas vezes, impossíveis de serem colocados em prática BURN; HIGHSMITH, 2001a, SCHWABER, 2002).
(HIGHSMITH, 2002). Neste mesmo período, modelos de processos aplicados a
Sintetizando o pensamento deste grupo, Highsmith (Ibid.) outras indústrias, começam a ser analisados para servir como
menciona que a indústria e a tecnologia sofrem modificações fonte de inspiração ao aprimoramento do processo de desenvol-
tão aceleradas que acabam por “atropelar” os métodos clássi- vimento de software (POPPENDIECK, 2001). O Modelo Toyota
cos. Highsmith et al (2002) ainda acrescentam que os clientes, de Produção2 foi alvo de atenção especial: enquanto as unida-
na maioria das vezes, são incapazes de definir de forma clara e des fabris americanas trabalhavam a 100% de sua capacidade e
precisa, os requisitos do software, logo no início de um projeto mantinham grandes volumes de inventário de matérias-primas
de desenvolvimento, o que inviabiliza a adoção dos métodos e de produtos acabados, a fábrica da Toyota mantinha o nível
clássicos em muitos projetos. de estoque suficiente para um dia de operação e produzia
Como resposta a esta situação, muitos especialistas criaram somente o necessário para atender aos pedidos já colocados.
métodos próprios para se adaptar às constantes mudanças Este modelo traduzido no princípio da Lean Manufacturing,
exigidas pelo mercado e às indefinições iniciais dos projetos. visava à utilização mais eficiente dos recursos e a redução de
O agrupamento desses métodos deu origem à família dos Mé- qualquer tipo de desperdício e estava totalmente alinhado à
todos Ágeis de Desenvolvimento de Software. Sendo assim, 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
“[...] os Métodos Ágeis podem ser considerados uma coletânea de um bom trabalho e que os gerentes deveriam permitir que os
diferentes técnicas e métodos, que compartilham os mesmos valores trabalhadores do chão de fábrica tivessem autonomia para a
e princípios básicos, alguns dos quais remontam de técnicas introdu- tomada de decisões e a resolução de problemas. Além disso,
zidas em meados dos anos 70, como os desenvolvimentos e melhorias estimulava o estabelecimento de uma relação de confiança com
iterativos” (COHEN et al, 2003, p.2). os fornecedores e defendia uma cultura de melhoria contínua
dos processos e dos produtos. Enquanto as unidades fabris
De fato, Cockburn e Highsmith (2001a) já haviam afirmado japonesas geravam produtos cada vez melhores e mais baratos,
que a maioria das práticas propostas pelos Métodos Ágeis não as fábricas americanas não conseguiam fazer o mesmo.
tem nada de novo e que a diferença recai principalmente sobre Com base nesta avaliação, Poppendieck (2001) listou 10 prá-
o foco e os valores que os sustentam. ticas que tornavam a Lean Manufacturing tão bem-sucedida e
Segundo Cohen et al (2003), um dos primeiros questionamen- que, em seu entendimento, poderiam ser adaptadas e aplicadas
tos aos métodos clássicos de desenvolvimento de software foi ao desenvolvimento de software:
feito por Schwaber, criador do Scrum. Para entender melhor os 1. Eliminação de gastos – eliminar ou reduzir diagramas e
métodos clássicos de desenvolvimento de software baseados modelos que não agregam valor ao produto final;
no SW-CMM, Schwaber (2002) elaborou um estudo junto aos 2. Minimização de inventário – minimizar artefatos interme-
cientistas da DuPont, que tinha por objetivo responder a se- diários, como documentos de requisitos e de desenho;
guinte pergunta: “Por que os processos definidos e defendidos 3. Maximização do fluxo – utilizar o desenvolvimento iterativo
pelo SW-CMM não promovem entregas consistentes”? Após para redução do prazo de entrega do software;
analisarem seus processos de desenvolvimento de software, 4. Atendimento à demanda – atender às mudanças de
os cientistas chegaram à conclusão que, apesar do SW-CMM requisitos;
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- 2 Modelo Toyota de Produção – para maiores informações ver Correa e Gianesi
de dos processos propostos pelo SW-CMM, na consequente (1993) e Ferreira et al (2002).
3 A Administração da Qualidade Total ou Total Quality Management pode ser en-
1 Entre os métodos clássicos de desenvolvimento de software podem ser citados tendida como a extensão do planejamento de negócios de uma empresa, abran-
o Modelo em Cascata e os modelos iterativos e em Espiral (COHEN et al, 2003). gendo o planejamento da qualidade (JURAN; GRYNA, 1991, p. 210 – 214).

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


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 simplicidade de aprendizado e de documentação; e, finalmente,
(HIGHSMITH, 2004, p. xix). Como agilidade deve-se entender adaptativos, pela habilidade de acomodar mudanças ao longo
“a habilidade de criar e responder a mudanças, buscando a do projeto (ABRAHAMSSON et al, 2003; FOWLER, 2003).
obtenção de lucro, em um ambiente de negócio turbulento” Como principais diferenças entre os Métodos Ágeis e os
(HIGHSMITH, 2004, p. 16); ou ainda, “a capacidade de balan- clássicos de desenvolvimento de software podem ser citadas
cear flexibilidade e estabilidade” (Id., 2002). A agilidade não (FOWLER, 2003; CHIN, 2004):
deve ser vista como falta de estrutura, mas está diretamente • Os Métodos Ágeis são adaptativos e não preditivos: diferen-
relacionada à capacidade de adaptação a situações diversas e temente dos enfoques clássicos que defendem o planejamento
inesperadas. Highsmith (2004, p. 16) enfatiza que a ausência integral do escopo no início do projeto e um controle rígido de
de estrutura ou de estabilidade pode levar ao caos, mas que mudanças, os planos dos Métodos Ágeis são elaborados e adap-
estrutura em demasia gera rigidez. tados ao longo do projeto, permitindo e, algumas vezes estimu-
Como resultado do encontro, foi criada a Agile Alliance4, lado, a incorporação das mudanças requeridas pelo cliente;
sendo publicado o Manifesto para Desenvolvimento Ágil de • Os Métodos Ágeis são orientados a pessoas e não a processos:
Software ou o Manifesto for Agile Software Development os processos clássicos têm desenvolvimento de software têm,
(BECK et al, 2001), cujo conteúdo5 é apresentado abaixo: em geral, a pretensão de funcionar independentemente de
quem os executa. Já os Métodos Ágeis levam em consideração
“Nós estamos descobrindo melhores maneiras para desen- os indivíduos, sendo elaborados para auxiliá-las.
volver software, praticando e auxiliando os outros a fazê-lo.
Através deste trabalho nós valorizamos: Princípios
- Os indivíduos e suas interações acima de processos e Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de um
ferramentas; software de valor
- Software em produção acima da documentação exaustiva; Pessoas de negócio e programadores devem trabalhar juntos, diariamente, ao longo de todo o
- Colaboração do cliente acima da negociação de contratos; projeto
- Respostas às mudanças acima da execução de um plano. Aceite as mudanças de requisitos, mesmo que numa etapa avançada do desenvolvimento
Ou seja, embora haja valor nos itens à direita, nós valorizamos mais Entregue novas versões do software frequentemente
os itens à esquerda.” 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
Segundo Cohen et al (2003, p. 6), este Manifesto tornou-se
acredite em sua capacidade de realização do trabalho
a peça-chave do movimento pelo desenvolvimento ágil
As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
de software, uma vez que reúne os principais valores dos
O método mais eficiente e efetivo de distribuir a informação para e entre uma equipe de
Métodos Ágeis, que os distingue dos métodos clássicos de
desenvolvimento é a comunicação face a face
desenvolvimento.
Processos ágeis promovem desenvolvimento sustentado
Além do Manifesto, foram definidos os princípios que regem
a maioria das práticas dos chamados Métodos Ágeis de De- A atenção contínua na excelência técnica e num bom projeto aprimora a agilidade
senvolvimento de Software (AGILE ALLIANCE, 2005). Estes Simplicidade é essencial
princípios são apresentados na Tabela 1 abaixo, de acordo com Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento
a ordem originalmente proposta. de acordo com os resultados
Pode-se dizer, então, que os Métodos Ágeis se caracterizam
Tabela 1. Princípios dos métodos ágeis de desenvolvimento de software
por serem incrementais, cooperativos, diretos e adaptativos. (FONTE: AGILE ALLIANCE, 2005.)
Incrementais, dadas as pequenas versões e ciclos rápidos de
desenvolvimento; cooperativos, por estimular a proximidade Um ponto interessante a salientar é que enquanto alguns
com o cliente e a interação entre os programadores; diretos, pela defensores “radicais” dos Métodos Ágeis são categóricos em
criticar e apontar as falhas dos métodos clássicos de desenvol-
4 Agile Alliance – Organização sem fins lucrativos criada para auxiliar indiví- vimento de software, outros especialistas, representantes tanto
duos e organizações que utilizam os Métodos Ágeis para o desenvolvimento dos métodos clássicos quanto dos ágeis, têm uma postura mais
de software. amena, enxergando até mesmo uma possibilidade de integra-
ção entre as duas abordagens (GLASS, 2001; COHEN et al, 2003;
5 “We are uncovering better ways of developing software by doing it and helping PAULK, 2002; GLAZER, 2001; HIGHSMITH, 2004). Glass (2001)
others do it. Through this work we have come to value: apresenta uma análise do Manifesto para o Desenvolvimento
- Individuals and interaction over process and tools; Ágil de Software e menciona que, apesar de concordar com os
- Working software over comprehensive documentation; pontos defendidos pelos praticantes dos Métodos Ágeis, não se
- Customer collaboration over contract negotiation deve desprezar os modelos clássicos e que ambos os lados têm
- Responding to change over following a plan. pontos importantes a serem considerados e balanceados. Paulk
That is, while there is a value in the items on the right, we value the items on (2002) defende que os princípios dos Métodos Ágeis devem ser
the left more.” seguidos por todos os profissionais que desenvolvem software,

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


M etodologias Ágeis

mas lembra que formalismo e disciplina devem ser levados em 2. Programação em pares: dois programadores utilizando o
conta, especialmente quando o software a ser desenvolvido mesmo equipamento escrevem o código;
envolve severos requisitos de confiabilidade. Paulk (Id., 2001) 3. Pequenas versões: as versões devem ser tão pequenas quanto
analisa o Método Ágil Extreme Programming (XP) sob a ótica do possível e trazerem valor para o negócio. Uma versão inicial
SW-CMM, apontando como este poderia auxiliar as organiza- do software deve ser colocada em produção após um pequeno
ções a alcançar os objetivos propostos pelo SW-CMM. número de iterações e, em seguida, outras versões devem ser
disponibilizadas tão logo faça sentido;
Principais Métodos Ágeis de Desenvolvimento de 4. Metáforas: clientes, gerentes e programadores criam metáfo-
Software ras ou conjunto de metáforas para modelagem do sistema;
Dentre os principais Métodos Ágeis de Desenvolvimento de 5. Projeto simples: os programadores são estimulados a desen-
Software podem ser citados: Extreme Programming, Scrum, volver o código do software o mais simples possível;
Dynamic Systems Development Method, Adaptative Software 6. Testes: os programadores devem criar os testes de unida-
Development, Crystal Method, Feature-Driven Development de antes ou mesmo durante o desenvolvimento do código
e Lean Development (COHEN et al, 2003; UDO; KOPPEN- do sistema. Os clientes, por sua vez, escrevem os testes de
STEINER, 2003). A seguir é feita uma breve explanação sobre aceitação. Ao final de cada iteração a bateria de testes deve
as suas principais características. ser conduzida;
7. Refatoração: técnica que permite a melhoria de código sem
Extreme Programming (XP) a mudança de funcionalidade (BRASIL, 2001b, p. 186), deve
De acordo com Cohen et al (2003, p.12) “o Extreme Program- ser executada pela equipe do projeto, o tempo todo;
ming (XP) é, indubitavelmente, o Método Ágil de maior ex- 8. Integração contínua: os programadores devem integrar os
pressão, criado nos últimos anos”. Por se tratar do Método novos códigos ao software tão rapidamente e com a maior
Ágil mais difundido é abordado com mais de detalhe neste frequência possível;
artigo. 9. Propriedade coletiva do código: o código do programa deve
O XP é um Método ágil para pequenas e médias equipes ser propriedade de toda a equipe e qualquer integrante pode
desenvolverem software, em ambientes com requisitos ins- fazer alterações sempre que for necessário;
táveis. Criado em 1998 por Kent Beck, Ron Jeffries e Ward 10. Cliente no local: o cliente deve trabalhar com a equipe de
Cuninghan, a partir de um projeto piloto na Chrysler (BECK projeto a todo o momento, respondendo perguntas, realizan-
et al, 1998), o XP vem ganhando cada vez mais adeptos, am- do testes de aceitação e assegurando que o desenvolvimento
pliando sua participação no mercado (HIGHSMITH, 2002). do software esteja sendo feito a contento;
Beck (2000, p.xv) explica que o termo Extreme (extremo) é 11. Semana de 40 horas: como trabalhar por longos períodos
utilizado, dado que o XP reúne um conjunto de práticas de reduz o desempenho, o conteúdo de cada iteração deve ser
desenvolvimento já existentes e reconhecidas como “boas planejado de forma a não haver necessidade de realização
práticas” no desenvolvimento de software, mas as leva ao de horas extras, fazendo com que os programadores estejam
extremo, ao limite. Juric (2002) comenta que o XP é uma renovados e ansiosos a cada manhã e cansados e satisfeitos
maneira eficiente, de baixo risco, científica e divertida de à noite;
desenvolver software. 12. Padrão de codificação: no início do projeto deve ser criado
A premissa básica do XP é que, ao contrário do que se um padrão de codificação, simples e aceito por toda a equipe,
pensava há 30 anos, o custo de mudança de um software que deverá ser seguido de forma a não permitir a identifica-
não aumenta exponencialmente com o avançar do projeto ção de quem desenvolveu determinada parte do código e a
(BECK, 2004, p. 21-23). As novas técnicas desenvolvidas auxiliar a condução do trabalho.
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
Custo da mudança do software

o desenvolvimento, sendo possível abandonar o Modelo em


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


M etodologias Ágeis

Característica Valores sugeridos


a) Pré-projeto; b) Análise de Aderência; c) Estudo de Negó-
cio; d) Modelagem Funcional; e) Projeto e Desenvolvimento; Tamanho da Equipe Variável de acordo com a complexidade das funcionalidades a
f) Implementação, e, g) Pós-implementação. A ideia central serem desenvolvidas
do DSDM é que se deve primeiramente fixar o prazo e os Duração das iterações Até 2 semanas
recursos para, em seguida, definir e ajustar o número de Equipes distribuídas O FDD foi criado para trabalhar com equipes múltiplas e, apesar
funcionalidades a serem desenvolvidas (COHEN et al, 2003; de não haver indicação formal para equipes distribuídas, é
UDO; KOPPENSTEINER, 2003). passível de adaptação
Aplicações de alta criticidade Indicado para desenvolvimento de software crítico
Característica Valores sugeridos
Tamanho da Equipe A família dos Crystal Methods acomoda equipes de qualquer Tabela 5. Características principais para utilização do FDD (FONTE: COHEN
et al, 2003, p.15.)
tamanho, preferencialmente compostas por pessoas talentosas
Duração das iterações Até 4 meses para projetos grandes e altamente críticos Lean Development (LD)
Equipes distribuídas Os Crystal Methods foram concebidos para atender ao conceito de Com raízes na indústria automotiva dos anos 80, em especial
equipes distribuídas no Modelo Toyota de Produção, o Lean Development é considera-
Aplicações de alta criticidade Os Crystal Methods atendem a projetos críticos, incluindo aqueles do o Método Ágil com maior foco estratégico. Iniciado por Bob
que envolvem risco de vida e de valores monetários Charette, o LD tem como principais objetivos reduzir em um
Tabela 4. Características principais para utilização dos Crystal Methods terço o prazo, o custo e o nível de defeitos no desenvolvimento
(FONTE: COHEN et al, 2003, p.15.) de software. Para tanto, requer um grande comprometimen-
to da alta administração e uma predisposição a mudanças
Dadas a sua natureza, o DSDM não endereça um tamanho radicais (COHEN et al, 2003; UDO; KOPPENSTEINER, 2003).
de equipe específico e não possui durações pré-determinadas HIGHSMITH (2002) aponta como princípios fundamentais do
para suas iterações (COHEN et al, op. cit.). Não foram encon- Lean Development:
tradas na literatura recomendações específicas para utilização • A satisfação do cliente é a prioridade principal;
no desenvolvimento de aplicações de determinada criticidade • Prover sempre o maior valor possível para o dinheiro;
ou para equipes centralizadas ou descentralizadas. • O sucesso depende da participação ativa dos clientes;
• Todo projeto baseado no LD requer um esforço conjunto de
Feature-Driven Development (FDD) toda a equipe;
O Feature-Driven Development, criado por Peter Coad e • Tudo pode ser mudado;
Jeff DeLuca em 1999, é um método de desenvolvimento • Domine, não aponte as soluções;
de software específico para aplicações críticas de negócio • Complete, não desenvolva;
(PALMER; FELSING, 2001). Diferentemente de outros Mé- • Prefira uma solução a 80% hoje, a uma solução a 100%
todos Ágeis, o FDD se baseia em processos bem definidos amanhã;
e que podem ser repetidos. Sua abordagem se concentra • O minimalismo é essencial;
nas fases de projeto e construção, com maior ênfase na • A necessidade determina a tecnologia;
modelagem, em um ciclo de vida iterativo e também em • O incremento do produto corresponde a um incremento de
atividades de gerenciamento de projetos (UDO; KOPPENS- funcionalidade e não de tamanho;
TEINER, 2003). Os princípios-base do FDD são apontados • Nunca force o LD além de seus limites.
abaixo (HIGHSMITH, 2002):
• Necessidade de se automatizar a geração de software para Cohen et al (2003, p. 19) afirma que “[...] como o Lean Develop-
projetos de grande escala; ment é mais uma filosofia de gerenciamento que um processo
• Um processo simples e bem definido é fundamental; de desenvolvimento”, os itens referentes ao tamanho da equipe,
• As etapas de um processo devem ser lógicas e óbvias para à duração das iterações, ao tratamento de equipes centralizadas
cada integrante da equipe de desenvolvimento; ou distribuídas e à criticidade da aplicação não são diretamente
• Bons processos atuam na retaguarda, permitindo que a endereçados pelo método.
equipe se dedique ao alcance dos resultados;
• Ciclos de vida curtos e iterativos são mais indicados. Adaptative Software Development (ASD)
Criado por Highsmith como uma evolução do RAD – Ra-
Um projeto conduzido pelo método FDD possui as se- pid Application Development em 1992, o Adaptative Software
guintes etapas: a) Desenvolvimento de um modelo geral; Development propõe uma forma alternativa de se enxergar o
b) Construção da lista de funcionalidades; c) Planejamento desenvolvimento de software nas organizações (HIGHSMITH,
por funcionalidades; d) Projeto e desenvolvimento por 2002). O ASD foi projetado para lidar com ambientes repletos de
funcionalidades. incertezas e complexos. Segundo Udo e Koppensteiner (2003),
A Tabela 5 apresenta as principais características de um o método estimula a aprendizagem durante o processo de de-
projeto desenvolvido pelo método FDD (COHEN et al, senvolvimento e a adaptação constante às novas realidades do
2003, p.18). 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 entre eles na Tabela 7. Estas diferenças entre as abordagens
versões. O ASD oferece estrutura e orientação suficiente para sugerem que as organizações devem repensar suas metas,
evitar que os projetos se tornem caóticos, sem, entretanto, seus objetivos e reconfigurar seus componentes humanos,
trazer uma rigidez indesejada que venha a suprimir a criativi- gerencial e tecnológico, de forma a alcançar uma implemen-
dade. Neste método, o papel do gerente de projetos é favorecer tação bem-sucedida dos métodos ágeis (NERUR et al, 2005,
a colaboração entre a equipe de desenvolvimento e o cliente. p.75). Enfocando o componente gerencial, estas diferenças
De acordo com Highsmith (2002), o ASD é indicado para podem demandar até mesmo uma alteração no enfoque de
equipes pequenas, mas pode ser adaptado para equipes maio- gerenciamento de projetos utilizado para as iniciativas de
res. Com relação aos demais atributos – duração das iterações, desenvolvimento de software.
apoio a equipes distribuídas e desenvolvimento de aplicações Ambler (2002c) discute os fatores que influenciam a adoção
de alta criticidade – não foi encontrada uma indicação precisa bem-sucedida de Métodos Ágeis, enfatizando que o ponto mais
na literatura. importante para que isto aconteça é a existência de uma com-
patibilidade entre os conceitos e valores da organização e dos
Resumo das Características Principais dos Métodos Ágeis Métodos Ágeis, ou seja, o autor discute claramente a questão
Nos tópicos anteriores foram apresentadas as principais da cultura da organização. Na mesma linha, Nerur et al (2005)
características de alguns dos chamados Métodos Ágeis de destacam que os valores, as normas e os padrões estabelecidos
Desenvolvimento de Software. É importante mencionar que e reforçados pelas organizações ao longo do tempo se refletem
estes métodos foram selecionados por serem os mais citados nas políticas e nas rotinas da empresa e exercem considerável
na literatura. influência nos processos de tomada de decisão, nas estratégias
Como visto, apesar dos Métodos Ágeis terem uma essência de solução de problemas, nas práticas voltadas à inovação, nos
ou valores em comum, há algumas diferenças significativas filtros de informação, nos relacionamentos interpessoais e nas
entre eles. A Tabela 6 apresenta um resumo das principais negociações. Como a cultura e a forma de pensar das pessoas
características dos Métodos Ágeis analisados, com uma linha não são facilmente modificáveis, pode-se dizer que a adoção de
específica destinada à análise da incorporação ou não de prá- Métodos Ágeis seja indicada apenas a algumas organizações
ticas relacionadas ao gerenciamento de projetos. (AMBLER, 2002; NERUR et al, 2005).
Um segundo fator importante a ser considerado quando da
Aplicação dos Métodos Ágeis nas Organizações decisão pela implementação de Métodos Ágeis, de acordo
Há uma grande variedade de Métodos Ágeis de Desenvol- com Ambler (op. cit.) é o projeto e as características do negócio.
vimento de Software, cada qual sugerindo práticas específi- Questões como – Os trabalhos têm sido conduzidos de forma
cas, cuja adoção traz mudanças às rotinas das organizações. incremental? Qual é a motivação da equipe de projeto? Qual o
De acordo com Nerur et al (2005, p.74), “[...] as alterações nos nível de apoio que a equipe de desenvolvimento pode esperar?
processos de desenvolvimento de software representam um Os recursos adequados estão disponíveis? Quão voláteis são os
fenômeno complexo de mudança organizacional que não requisitos do projeto? – são fundamentais para esta avaliação.
pode ser alcançado pela mera substituição de ferramentas e Com relação ao último ponto, Bohem (2002) chega a sugerir que
tecnologias”. Estas mudanças têm impacto significativo em os métodos clássicos deveriam ser preferidos quando o índice
vários aspectos da organização: na estrutura, na cultura e nas de alteração de requisitos do projeto for inferior a 1% ao mês.
práticas gerenciais. Conhecer a amplitude deste fenômeno é Um terceiro aspecto destacado por Ambler (op. cit.) é a neces-
fator crítico para o planejamento e o gerenciamento destas sidade de definição de um champion, ou seja, de um profissional
mudanças. Sendo assim, antes de uma organização adotar e que assuma os desafios do projeto, de forma que a equipe de
implementar qualquer um dos Métodos Ágeis é fundamental desenvolvimento possa trabalhar com tranquilidade. Amplian-
que avalie a dimensão do impacto e a sua prontidão para tal do esta análise, uma vez que os Métodos Ágeis valorizam e
(AMBLER, 2002c; COHEN et al, 2003; FOWLER, 2003; NERUR depositam elevado grau de confiança no conhecimento tácito
et al, 2005). e na capacidade de tomada de decisões de cada indivíduo,
Para facilitar o entendimento e retomar as principais Bohem (op. cit.) enfatiza a importância de se ter também uma
características e diferenças entre os enfoques clássico e equipe de projeto bem treinada e composta por especialis-
ágil de desenvolvimento de software, é traçado paralelo tas. Com relação a este aspecto, apesar de concordar com a

Característica XP Scrum Crystal Methods FDD ASD LD DSDM


Tamanho da Equipe 2-10 1-7 Variável Variável Variável

Duração das iterações 2 semanas 4 semanas < 4 meses < 2 semanas Não definido
Equipes distribuídas Não Adaptável Sim Adaptável
Aplicações de alta criticidade Adaptável Adaptável Todos os tipos Adaptável
Práticas de gerenciamento de projetos Poucas Muitas Poucas Muitas 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


M etodologias Ágeis

Enfoque Clássico Enfoque Ágil (Métodos Ágeis)


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
feedback e na aceitação de mudanças
Estilo de Gerenciamento Comando e controle Liderança e colaboração
Distribuição de Papéis Individual, favorecendo a especialização Equipes auto-organizadas, encorajando o intercâmbio de papéis
Papel do Cliente Importante Crítico
Modelo de Desenvolvimento Modelo de ciclo de vida – Modelo em Cascata, Espiral e iterativos Métodos Ágeis
Tecnologia Sem restrições Favorece a tecnologia orientada a objetos

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 cit.) afirmam que há sentimentos controversos entre os inte-
et al (2005) chama a atenção para que não se crie uma cultura grantes da equipe durante o processo de transição: alguns se
de elitismo dentro do grupo de desenvolvimento, que pode sentem perdidos ou sem um direcionamento, pela ausência de
afetar o moral e o comprometimento de outros profissionais um cronograma formal ou de uma documentação completa
da empresa, não integrantes da equipe. de requisitos; outros empolgados, pelo reconhecimento de
É inegável também que os Métodos Ágeis trazem consigo sua capacidade e pela autonomia concedida; alguns creem
uma mudança radical na relação cliente – fornecedor. Cock- erroneamente que a adoção dos Métodos Ágeis tem o intuito
burn e Higsmith (2001a), Bohem (2002) e Nerur et al (2005) de estimular a microgerência, dados os encontros e as reu-
apontam o envolvimento e a participação dos clientes como niões constantes entre gerentes e equipe, em métodos como
fatores imprescindíveis para o sucesso da implementação dos o Scrum e XP.
métodos ágeis. Os clientes devem estar totalmente compro- Em face desta situação, Cohn e Ford (2003, p. 75), assim como
metidos com o projeto, trabalhar com espírito de colaboração, Ambler (2002c), defendem uma passagem gradual dos pro-
possuir o conhecimento necessário, ter autonomia para a cessos clássicos de desenvolvimento para os Métodos Ágeis,
tomada de decisões, além de estar disponíveis para sanar as tornando o período de transição mais tranquilo.
dúvidas quando necessário. Entretanto, por se tratar de um A idéia de uma equipe formada por talentos, citada por
item extremamente crítico no processo e que demanda tempo, Boehm (2002) é ratificada por Cohn e Ford (2003, p. 75) e por
paciência e esforço consideráveis para o estabelecimento de Ambler (2002c), que explicam ainda que diferenças grandes
um ambiente de respeito e confiança mútua entre clientes de produtividade numa equipe podem trazer impactos ne-
e fornecedores, é mencionado por alguns autores, entre eles gativos ao projeto, uma vez que num Método Ágil, a equipe
Nerur et al (Ibid.), como um dos obstáculos à utilização dos se dedica apenas às atividades essenciais para a entrega do
Métodos Ágeis. software. Não se deve esquecer, contudo, que uma pequena
Compartilhando os pontos discutidos nos parágrafos ante- queda de produtividade é esperada durante a transição, até
riores, Cohn e Ford (2003, p. 74) acrescentam que transição de que toda a equipe esteja ambientada com a nova dinâmica
um processo clássico com ênfase no “planejamento – execução de trabalho. Fowler (2003) destaca que a equipe técnica não
– controle”, para um processo ágil, afeta não apenas a equipe pode ser responsável por todo o trabalho por si só, sendo
de desenvolvimento de software, mas também outras equipes, fundamental o papel dos gerentes, fornecendo o direciona-
departamentos, assim como o corpo gerencial da organização. mento, auxiliando a definição das prioridades de negócio,
Tomando por base a experiência empírica de implementações removendo obstáculos e negociando os prazos de entrega.
de Métodos Ágeis em várias organizações, abrangendo tanto Com esta colocação, Fowler (Ibid.) enfatiza a importância do
projetos simples como projetos complexos, equipes centrali- gerenciamento de projetos mesmo no desenvolvimento de
zadas ou distribuídas, os autores sugerem uma abordagem software conduzido com o uso de Métodos Ágeis.
diferenciada junto aos principais envolvidos nos processos – Ao considerar a questão de equipes distribuídas, Cohn e
programadores, alta gerência e a área de Recursos Humanos Ford (op. cit.) são enfáticos em dizer que, mesmo havendo
– para que se garanta uma implementação bem-sucedida deste a necessidade de se organizar um projeto de forma descen-
novo enfoque de desenvolvimento de software. tralizada, deve-se fazer o possível para que nas primeiras
Segundo Cohn e Ford (2003, p. 74 - 75), usualmente os semanas de trabalho, a maior parte da equipe esteja reunida
programadores respondem à implementação de Métodos e somente após este período as equipes sejam distribuídas.
Ágeis com um misto de ceticismo, entusiasmo, otimismo, ou Os autores justificam este ponto ao afirmar que equipes que
mesmo, resistência. Como este novo enfoque, o desenvolvi- trabalham segundo os Métodos Ágeis necessitam tomar de-
mento de software normalmente prioriza a entrega do código cisões de forma mais rápida que nos processos tradicionais,
à geração de uma documentação extensiva, a adaptação ao mas para tanto, recorrem a uma comunicação mais frequente
planejamento completo e, as pessoas e suas interações aos e normalmente informal. Sem esta proximidade inicial, a
processos e ferramentas (BECK et al, 2001). Cohn e Ford (op. comunicação pode ser comprometida.

Edição 20 - Engenharia de Software Magazine 13


Analisando outro grupo de interessados, Cohn e Ford (2003, vez que as iterações podem continuar enquanto houver itens
p.76) apontam que normalmente a alta gerência representa um prioritários, definidos pelo cliente, a serem desenvolvidos.
desafio singular à adoção dos Métodos Ágeis. Basicamente as Cohn e Ford (2003, p.77) apontam como solução para esta
suas preocupações recaem sobre quatro pontos fundamentais, questão, a definição de um intervalo de prazo e custo, vincu-
extremamente vinculados à visão do Gerenciamento Clássico lado a um escopo macro, que servem como uma estimativa
de Projetos: preliminar do projeto, a ser considerada durante a execução
1. Como é possível prometer novas funcionalidades aos do projeto. A equipe deve buscar entregar uma versão básica
clientes? e funcional do software, no prazo mínimo deste intervalo
2. Como mensurar o progresso do projeto? e, a partir daí, são negociadas entregas complementares
3. Quando o projeto acaba? (outras iterações). Desta forma, Cohn e Ford (2003, p. 77),
4. Como a utilização de um Método Ágil afetará outros afirmam que é possível minimizar o desconforto quanto à
grupos? finalização do projeto.
Considerando a quarta questão, a implementação de um
Apesar de pertinentes, a origem destes questionamentos Método Ágil pode afetar além da equipe de desenvolvimen-
está na dificuldade que muitos gerentes têm em abrir mão to, os gerentes, os clientes e, até mesmo, áreas ou departa-
do processo clássico de planejamento e controle, da solicita- mentos internos à empresa que, numa análise inicial, não
ção de compromissos formais de entrega, mesmo sabendo têm nenhum vínculo aparente com o projeto. Sendo assim,
que raramente estes objetivos são cumpridos pelas equipes é fundamental que a alta gerência tenha ciência de quais
de desenvolvimento6. Cohn e Ford (2003, p.76) e Highsmith grupos ou departamentos serão afetados pela adoção dos
(2004) salientam que g����������������������������������
erentes que temem que com os Méto- Métodos Ágeis, para que se estabeleça um consenso quan-
dos Ágeis não seja possível a fixação de datas de entrega de to à forma de trabalho e se evite desgastes ou problemas
produtos a clientes, deveriam lembrar que, no passado, os futuros. Neste contexto, deve-se destacar a importância da
planos formais provedores de “garantias” de prazo, custo e participação da área ou departamento de Recursos Huma-
qualidade estavam usualmente errados, superestimados, ou nos no processo de transição para a utilização dos Métodos
ambos. Em organizações com histórico de estimativas incor- Ágeis (COHN; FORD, 2003, p. 78). Representantes desta área
retas de projetos, convencer a alta gerência sobre os benefícios devem ser envolvidos logo no início da implementação, para
dos Métodos Ágeis pode não ser algo difícil, bastando uma que tenham ciência da nova forma de trabalho e forneçam
avaliação dos resultados passados frente aos objetivos iniciais todo o apoio necessário, sanando dúvidas e amenizando
de prazo, custo e qualidade e a apresentação dos benefícios ansiedades dos envolvidos no processo de mudança.
potenciais da nova abordagem. Já nos casos em que a equipe Complementando esta análise, COHEN et al (2003, p. 31)
de desenvolvimento entrega seus projetos sistematicamente selecionam um conjunto de lições aprendidas, que consi-
no prazo e no custo, a utilização dos Métodos Ágeis pode deram úteis quando da decisão pela adoção de um Método
ser justificada com vistas à redução de prazos de entrega, à Ágil, algumas das quais rebatem as críticas mais comuns
redução das equipes de trabalho, o que significaria um ganho atribuídas a este novo enfoque de desenvolvimento de
para a organização. software:
Apesar dos Métodos Ágeis proporem uma mudança do • Os Métodos Ágeis podem ser aplicados a equipes de qual-
paradigma de “comando e controle” para “liderança e cola- quer tamanho, entretanto, deve-se ter em mente que quanto
boração”, conforme explica Nerur et al (2005, p.75), isto não maior a equipe, maior a dificuldade de comunicação;
significa que sejam alheios à necessidade de mensuração do • Experiência é importante para que um projeto ágil seja
progresso dos projetos. Segundo Cohn e Ford (2003, p.77), bem-sucedido, mas a experiência técnica em desenvolvimen-
os Métodos Ágeis podem oferecer um acompanhamento to de software é muito mais importante que a experiência
adequado do projeto, por meio da utilização de relatórios prévia com os Métodos Ágeis;
específicos a cada iteração, que contêm datas-chave, compara- • Os Métodos Ágeis requerem menos treinamento formal
ção de resultados reais versus planejados, métricas principais que os métodos clássicos. Técnicas como a programação
e até mesmo a identificação dos riscos do projeto. Estas são em pares minimizam a necessidade de treinamento, pois
práticas do gerenciamento de projetos, mas que neste caso, são as pessoas aprendem umas com as outras. Os treinamentos
aplicadas a cada interação e não ao projeto como um todo. formais podem ser realizados por meio de auto-estudo;
Outra preocupação bastante comum à alta gerência, refle- • Um software crítico e de alta confiabilidade pode ser
tida na terceira questão, é que aparentemente um projeto construído com a utilização de Métodos Ágeis. Neste caso,
realizado segundo um Método Ágil tende a não ter fim, uma é fundamental que os requisitos de desempenho sejam ex-
plicitados logo no início do projeto e os níveis adequados de
6 Pesquisa publicada pelo STANDISH GROUP INTERNATIONAL (2003), referente teste planejados. Ao solicitar feedback constante, incentivar
a projetos de desenvolvimento de software, aponta que usualmente os projetos a participação dos clientes e a definição de prioridade por
ultrapassam em 82% os prazos inicialmente previstos. Em 1999, este índice de eles, os Métodos Ágeis tendem a antecipar resultados e
atraso chegou ao valor aproximado de 222%. minimizar os riscos do projeto;

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


M etodologias Ágeis

• Os três principais fatores críticos de sucesso para um projeto Resultados da Aplicação dos Métodos Ágeis
ágil são: cultura, pessoas e comunicação. Os Métodos Ágeis Como os Métodos Ágeis de Desenvolvimento de Software são
exigem uma compatibilidade cultural para serem bem-sucedi- relativamente recentes, poucos são os dados empíricos disponí-
dos; profissionais competentes são fundamentais: os Métodos veis referentes aos resultados de sua aplicação nas organizações,
Ágeis usam menos técnicos, porém mais qualificados; equipes alguns dos quais são apresentados a seguir.
centralizadas facilitam a comunicação e a interação próxima Pesquisa realizada por Reifer (2002, p. 14-17) em 32 organiza-
com cliente é fator base para seu funcionamento; ções, representando 28 empresas de dez segmentos de mercado
• Os Métodos Ágeis permitem a identificação rápida de distintos, apontou que dentre elas, 14 organizações adotavam
eventuais problemas no projeto, através de pequenos sinais, Métodos Ágeis, todas motivadas por um histórico de baixo de-
como a queda da motivação da equipe nas reuniões diárias, sempenho dos projetos de desenvolvimento de software quanto
atrasos nas entregas das iterações e a geração de documentação ao cumprimento dos objetivos de prazo e custo. Surpreendente-
desnecessária; mente, a maioria das empresas analisadas era classificada como
• A documentação deve ser considerada um custo e sua nível dois ou superior, na escala de maturidade nos processos de
extensão deve ser determinada pelo cliente. Deve-se buscar desenvolvimento de software proposta pelo SW-CMM, ou seja,
desenvolver uma comunicação mais efetiva, mantendo a do- possuíam processos relativamente maduros. No entanto, estas
cumentação formal em um patamar mínimo necessário. empresas buscavam algo novo, que pudesse reverter o quadro
de mau desempenho consistente de seus projetos. A distribuição
A forma como um Método Ágil é introduzido em uma orga- destas empresas entre os segmentos de atuação, assim como
nização e os cuidados tomados durante este processo podem alguns detalhes quanto ao início da prática, à quantidade de
determinar o sucesso ou o fracasso da iniciativa. Outro im- projetos realizados com o uso dos Métodos Ágeis e ao estágio de
portante desafio enfrentado pelos gerentes das organizações implementação do novo método são apresentados na Tabela 8.
refere-se à escolha do Método Ágil mais apropriado para o Os projetos pesquisados são qualificados como de pequeno
momento e o projeto em questão, em face da variedade de porte (com menos de 10 participantes), em geral, internos, de
métodos atualmente disponíveis no mercado (NERUR et al, baixo risco, com duração menor que 12 meses, mas que exigiam
2005, p.77). Ambler (2002c) e Cohn e Ford (op. cit.) mencionam elevado grau de flexibilidade.
que, se após uma análise detalhada, os Métodos Ágeis não Com relação aos resultados, 50% das organizações que respon-
se apresentarem totalmente compatíveis com o projeto ou deram a pesquisa conseguiram mensurar os ganhos obtidos com
com os princípios da organização, mas suas idéias ainda as- a utilização de Métodos Ágeis de Desenvolvimento de Software
sim despertarem interesse, pode-se partir para uma adoção de forma concreta, sendo que muitas, por possuírem métricas
parcial. Nesta estratégia, deve-se identificar os pontos de anteriores, realizaram comparações bastante efetivas. Reifer (2002,
melhoria prioritários no processo clássico de desenvolvi- p.15) aponta como principais ganhos, já normalizados entre todos
mento de software e aplicar algumas práticas dos Métodos os participantes, os seguintes itens:
Ágeis, visando ao aprimoramento. Obtendo-se um resultado • Incremento de produtividade: ganhos de 15% a 23% de produ-
positivo, procede-se a uma nova seleção de áreas de melhoria tividade frente aos indicadores da indústria;
e implantação de novas técnicas, até que todo o Método Ágil • Redução de custos: 5% a 7% de redução de custos quando com-
tenha sido adotado. parado aos indicadores da indústria;
Por fim, Highsmith (2004), Cohn e Ford (2003) e Nerur et al • Redução do tempo de entrega: 25% a 50% de redução de
(2005) ressaltam que muitas das inseguranças e incertezas prazo comparando-se com projetos anteriores realizados pelas
inerentes a este processo de transição podem ser minimizadas empresas;
com a adoção de um enfoque de gerenciamento de projetos • Melhoria de qualidade: cinco empresas que possuíam dados con-
adequado e compatível com o desenvolvimento de software cretos apontaram que a taxa de defeitos estava no mesmo nível dos
conduzidos com o uso de Métodos Ágeis. projetos anteriores quando da liberação de produtos e aplicações.

Indústria # Empresas que utilizam Métodos Ágeis # de Projetos Início da Utilização de Métodos Ágeis Estágio da Implementação
Aeroespacial 1 1 2001 Descoberta
Computação 2 3 2000 Piloto
Consultoria 1 2 2000 Piloto
Comércio Eletrônico 5 15 2000 Produção
Pesquisa 1 1 2000 Piloto
Software 2 4 2000 Produção
Telecomunicações 2 5 2000 Produção
Total 14 31 n/a n/a
Tabela 8. Características das empresas pesquisadas (FONTE: ADAPTADO DE REIFER, 2002, p. 15.)

Edição 20 - Engenharia de Software Magazine 15


As demais organizações analisadas, que não possuíam indi- para 25 profissionais. A empresa obteve também ganhos de
cadores formais, mensuraram seus ganhos através da opinião qualidade, com uma queda bastante significativa do número
dos principais interessados nos projetos, listando como benefí- de erros encontrados pelos clientes, que passaram de 33 erros
cios da utilização dos Métodos Ágeis, o alto grau de motivação ao mês para quatro erros ao mês. Estes resultados foram atri-
dos profissionais envolvidos, a elevação da moral da equipe e buídos, principalmente, à adoção da prática de programação
alguns outros argumentos intangíveis. em pares.
De forma unânime, todas as organizações afirmaram sua Em 2001, pesquisa conduzida pelo Cutter Consortium
intenção de continuar ou mesmo de estender a utilização dos (COCKBURN; HIGHSMITH, 2001b), com mais de 200 profis-
Métodos Ágeis, considerando-a uma experiência bastante sionais de diferentes empresas dos Estados Unidos, Europa,
proveitosa e bem-sucedida. Mas apesar dos resultados anima- Índia e Austrália, sobre o uso dos métodos clássicos e ágeis
dores, Reifer (2002, p.15), chama a atenção para que não sejam de desenvolvimento de software chegou a três conclusões
tiradas conclusões precipitadas, nem se faça uma generalização interessantes:
dos resultados, dados o tamanho da amostra (14 organizações) • Um aumento do número de empresas que utilizavam algum
e o tipo de projetos envolvidos (projetos pequenos, de baixo Método Ágil de Desenvolvimento de Software, quando com-
risco, em ambiente relativamente controlado). parado à pesquisa similar realizada em 2000;
Maurer e Martel (2002) relataram o caso de uma companhia • Os projetos de desenvolvimento realizados segundo o en-
– Bitonic Solutions Inc. – sediada no Canadá, cuja equipe de foque ágil apresentaram melhor desempenho em termos de
sistemas, composta por nove profissionais, desenvolveu uma atendimento aos requisitos do negócio, satisfação do cliente e
aplicação para comércio eletrônico. O processo de desenvol- qualidade, que os projetos conduzidos nos moldes clássicos;
vimento foi iniciado segundo uma abordagem orientada a • Os Métodos Ágeis receberam melhor pontuação no quesito
objetos ad hoc, sendo adotado o método ágil Extreme Program- “moral dos profissionais”, resultado este considerado, na época,
ming (XP), depois de determinado período. Para a mensuração surpreendente pelo fato de apenas 12% dos respondentes serem
da produtividade do desenvolvimento, os autores definiram analistas ou programadores.
três indicadores principais, cujos valores foram divididos pelo
esforço despendido para execução (em horas), a saber: Similarmente a Reifer (2002), Cockburn e Highsmith
• Novas linhas de código (NLOC) (2001b) não generalizam estas conclusões, mas consideram,
• Número de novos métodos (# métodos); em especial o terceiro item, um indício bastante positivo da
• Número de novas classes (# classes). contribuição dos Métodos Ágeis em relação à motivação das
equipes de projeto.
Maurer e Martel (2002) coletaram métricas do desenvolvi- A aplicação bem-sucedida do método Extreme Programming
mento nos dois períodos (anterior e posterior ao uso do XP) e (XP) no desenvolvimento de um sistema de missão crítica7,
reportaram ganhos de produtividade que variaram de 66,3% voltado à coordenação de equipes da Hewlett-Packard dis-
a 302,1%, conforme mostra a Tabela 9. tribuídas ao redor do mundo, foi relatada por Gawlas (2004,
p. 18-24). O autor aponta que o processo de desenvolvimento,
Indústria NLOC / esforço # Métodos / # Classes / esforço pelo método XP, foi dividido em sete etapas, cada qual com um
esforço resultado e um prazo inicial pré-determinados. Várias adapta-
Média anterior ao uso do XP 10,2 0,36 0,05 ções foram feitas ao longo do projeto. Além de destacar práticas
Média com uso do XP 17 1,45 0,21 relacionadas ao XP, Gawlas (2004, p. 18-24) chama a atenção
% de Variação 66,3% 302,1% 282,6% para a abordagem de gerenciamento de projetos utilizada,
caracterizada como uma combinação entre o conhecimento e
Tabela 9. Ganhos de produtividade com XP em projetos Web (FONTE: a experiência da equipe de projeto e a necessidade de balan-
ADAPTADO DE MAURER; MANTEL, 2002.)
ceamento entre o enfoque ágil e o Gerenciamento Clássico de
Poole e Huisman (2001) relataram o uso bem-sucedido do Ex- Projetos adotado pela companhia. Após nove meses e dentro
treme Programmming (XP) na companhia Iona Technologies, no do prazo previsto, o software entrou em produção com poucos
desenvolvimento de um middleware. Os autores mencionaram defeitos, que puderam ser corrigidos de forma rápida e tran-
que a empresa não possuía um processo de desenvolvimento quila. Gawlas (2004, p. 18-24) salienta também que um ponto
e manutenção de software definido, sendo que a falta de de destaque foi a motivação da equipe de projeto.
qualidade no processo acabava por se refletir na qualidade Bonato (2004, p. 107-172), por sua vez, apresenta um caso de
do produto. Um processo de reengenharia de software foi adoção do Extreme Programming (XP) em renomada empresa
iniciado em 1997 sem, entretanto, alcançar os resultados dese- jornalística brasileira, para o desenvolvimento de uma aplica-
jados. Em 2000, a companhia decidiu implementar, de forma ção que visava à reformulação do pagamento de bonificação às
gradativa, as práticas do XP em seu processo de manutenção
de software. A Iona Technologies alcançou excelentes resulta- 7 Sistema (ou software) de missão crítica é aquele em que a vida, a saúde ou a
dos, reportando ganhos de produtividade na ordem de 67%, o segurança das pessoas ou organizações podem ser comprometidas se a quali-
que possibilitou uma redução no seu quadro de pessoal de 36 dade do software não for extremamente alta (TURK et al, 2005, p.29).

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


M etodologias Ágeis

empresas publicitárias, garantindo maior controle ao processo. Baseados em


O projeto foi iniciado segundo o enfoque clássico de desen- PRINCÍPIOS PRESSUPOSTOS
volvimento de software, utilizado pela companhia. Contudo, Derivados de
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 Sustentam Levam a
momento, houve uma decisão pela adoção do XP, buscando
São baseadas
aliar qualidade e produtividade diante de requisitos instáveis. em
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 Têm
PRÁTICAS LIMITAÇÕES
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 Figura 3. Relacionamento entre princípios, práticas, pressupostos e
limitações (FONTE: TURK et al, 2005, p. 8.)
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 Ao abordar as limitações dos Métodos Ágeis, Turk et al
a generalização dos benefícios resultantes do emprego dos (2005, p. 23), iniciam a discussão afirmando que “[...] nenhum
Métodos Ágeis. No entanto, não se pode negar que os estudos processo ágil é uma bala de prata (apesar dos altos brados dos
realizados até o momento, alguns dos quais aqui retratados, entusiastas)”. Os autores defendem que, uma vez que os pres-
apontam que determinadas organizações estão de fato auferin- supostos apresentados acima não são atendidos por todas as
do resultados positivos, quanto à qualidade, à produtividade e organizações ou por todos os ambientes de desenvolvimento,
à motivação de seus profissionais, com a adoção dos Métodos os Métodos Ágeis em seus formatos atuais apresentam sim
Ágeis para o desenvolvimento de software. limitações. Para minimizá-las, a depender do contexto, deter-
minados métodos necessitam de extensões ou incorporações
Limitações dos Métodos Ágeis de práticas e princípios, usualmente associados os enfoques
Neste trabalho, tão importante quanto listar a aplicação e os preditivos e clássicos de desenvolvimento de software. As
benefícios obtidos com o uso dos Métodos Ágeis, é apresentar principais limitações apontadas por Turk et al (2005, p. 23-34)
as limitações e obstáculos à sua utilização. Dentre os autores são apresentadas nos parágrafos a seguir.
que escreveram sobre os Métodos Ágeis de Desenvolvimento A primeira limitação identificada diz respeito ao suporte a
de Software, alguns apresentaram e discutiram os princi- equipes distribuídas. A dispersão geográfica acarreta vários
pais conceitos e valores que regem este novo enfoque, como problemas que inexistem quando os integrantes da equipe
Abrahamsson et al (2003), Bohem e Turner (2003), Glass (2001), de desenvolvimento e do cliente encontram-se próximos. A
Cohen et al (2003), Cockburn e Highsmith (2001a; 2001b), Udo comunicação se torna mais difícil, há necessidade de ferra-
e Koppensteiner (2003), Fowler (2003); outros, como Turk et mentas e tecnologia especiais. Em ambientes distribuídos,
al (2003; 2005), Nerur et al (2005), Boger et al (2001) e McBreen os pressupostos de interação com o cliente, comunicação da
(2003), introduziram uma visão mais crítica, apontando limi- equipe, comunicação face a face ficam comprometidos. O uso
tações ao emprego dos Métodos Ágeis. de documentação formal pode se fazer necessário, para orga-
Dentre as obras com enfoque crítico acima citadas, a de Turk nizar o trabalho realizado em várias localidades por diferentes
et al (2005) se destaca das demais por sua ampla abordagem, equipes (TURK et al, 2005, p. 25-26).
voltada à identificação tanto dos pressupostos básicos sobre Turk et al (2005, p. 26-27) apontam a questão da subcontratação
os quais os princípios e práticas dos Métodos Ágeis estão an- como outra limitação dos Métodos Ágeis, sendo que Nerur
corados, quanto das limitações, decorrentes de sua aceitação, et al (2005, p. 76) estendem a discussão para a negociação de
conforme mostra a Figura 3. Com base nestes pressupostos, contratos de forma geral. A transferência do desenvolvimento
identificados após análise detalhada de publicações referentes de software a um subcontratado pressupõe o estabelecimento
aos diferentes Métodos Ágeis e dos valores e princípios defen- de um contrato de prestação de serviços bem definido. No
didos pela Agile Alliance e retratados no documento Manifesto entanto, as bases de um contrato tradicional não são as mes-
para o Desenvolvimento Ágil de Software (BECK et al, 2001), Turk et mas utilizadas pelos Métodos Ágeis. Mesmo seguindo um
al (2003, p. 43-46) pontuam as limitações dos Métodos Ágeis. enfoque iterativo e incremental, os contratos de forma geral
Sendo assim, para que se possa entender tais limitações, prevêem marcos, um número fixo de iterações, com durações
deve-se primeiramente visualizar os pressupostos identifica- e entregáveis pré-definidos e cláusulas restritivas a mudanças,
dos pelos autores (TURK et al, 2005, p. 22), que se encontram o que não se adequa a vários pressupostos dos Métodos Ágeis.
retratados na Tabela 10. Turk et al (2005, p. 26-27) apontam como saída, a criação de

Edição 20 - Engenharia de Software Magazine 17


Pressupostos Detalhamento
Pressuposto da visibilidade A visibilidade do projeto só pode ser alcançada através da entrega de um software funcionando
Pressuposto da iteração Um projeto pode ser sempre estruturado em iterações curtas e de períodos fixos
Pressuposto da interação com o cliente A equipe do cliente está disponível para interação frequente, quando solicitado pelos programadores
Pressuposto da comunicação da equipe Os programadores estão localizados em local que permita a comunicação frequente e intensiva entre si
Pressuposto da comunicação face a face A comunicação face a face é o método mais produtivo de comunicação com o cliente e entre os
programadores
Pressuposto da documentação Desenvolver uma documentação extensiva e consistente (relativamente completa) e modelos de
software é contraproducente
Pressuposto da mudança dos requerimentos 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
Pressuposto do custo da mudança O custo da mudança não aumenta dramaticamente com o passar do tempo
Pressuposto da experiência da equipe Os programadores têm a experiência necessária para definir e adaptar seus processos apropriadamente
Pressuposto da auto-avaliação As equipes almejam a auto-avaliação
Pressuposto da auto-organização As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
Pressuposto da garantia de qualidade 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
Pressuposto do desenvolvimento da aplicação específica O reuso e a generalidade não devem ser objetivos do desenvolvimento de uma aplicação específica.
Pressuposto do redesenho contínuo O software pode ser continuamente redesenhado e assim mesmo, manter sua estrutura e
integridade conceitual.
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 de todos os seus componentes seja intensivamente testada e
acomodar ambas as expectativas. que estes sejam projetados de forma a não haver falhas que
A dificuldade de apoio a grandes projetos e grandes equipes impossibilitem a correção ou o uso seguro de um determinado
é outra limitação apontada por alguns autores. Vários autores equipamento. Neste contexto, os pressupostos relacionados à
apontam que quanto maior a equipe, maior a complexidade da documentação, à garantia da qualidade e ao aprimoramento
comunicação e menos ágil se torna o processo (HIGHSMITH, contínuo dos Métodos Ágeis não são mais válidos. Uma es-
2004; COHEN et al, 2003, TURK et al, 2005, p. 27-28; NERUR et pecificação formal, testes intensivos e abrangentes e outras
al, 2005, p.76). O tamanho das equipes restringe a eficiência e técnicas de análise e avaliação dos métodos clássicos de de-
a frequência das interações face a face, havendo necessidade senvolvimento de software se tornam necessárias, apesar de
de uma maior estruturação e organização da equipe e da os autores ressaltarem que a adoção de algumas práticas dos
definição de várias linhas e formas de comunicação. O volu- Métodos Ágeis seja interessante, para aumentar a qualidade e
me de documentação requerido é maior e, de forma geral, a a confiabilidade do produto final (TURK et al, Ibid.).
agilidade tende a diminuir. Isto não quer dizer que grandes O desenvolvimento de um software grande e complexo, com
projetos não possam utilizar Métodos Ágeis, mas há que se numerosas linhas de códigos (milhares ou milhões) e alto grau
adotar práticas complementares para garantir o bom anda- de integração entre seus vários componentes é outra situação
mento dos trabalhos. em que a aplicabilidade dos Métodos Ágeis é contestada.
Discutindo outro item, a geração de componentes total ou Segundo Turk et al (2005, p. 30-31), projetos deste porte reque-
parcialmente reutilizáveis (códigos de programas, documentos rem elevado esforço de gerenciamento e controle, processos
de análise e desenho, entre outros) pressupõe a visão comple- estruturados e formais, para garantir o perfeito entendimento
ta da solução (e não apenas do software a ser desenvolvido do software e a integração de todas as suas partes. Os testes
naquele momento) e a ênfase no controle de qualidade. Os também devem ser cuidadosamente planejados. De forma ge-
Métodos Ágeis têm por premissa a manutenção de uma docu- ral, não é possível o desenvolvimento deste tipo de software de
mentação mínima, o que dificulta a determinação do potencial forma incremental e a adoção da premissa de desenvolvimento
de reuso de um determinado artefato, além de ter por foco o contínuo pode ser comprometida, haja vista a complexidade e
desenvolvimento de soluções para problemas específicos e a extensão do código.
não o desenvolvimento de códigos mais genéricos e reutilizá- Complementando a análise, Nerur et al (2005, p.76) e TURK et
veis. Desta forma, os Métodos Ágeis de Desenvolvimento de al (2005, p. 13-15) chamam a atenção à questão da dependência
Software não são os mais adequados à geração de artefatos entre as organizações e suas equipes ágeis de desenvolvimento,
reutilizáveis (TURK et al, 2005, p. 28-29). em especial no que diz respeito à gestão do conhecimento, vital
A adoção de Métodos Ágeis no desenvolvimento de sistemas nos dias de hoje, e à relação de poder. Os Métodos Ágeis de
de missão crítica é outro ponto comentado por Turk et al (2005, Desenvolvimento de Software encorajam o pensamento direto
p. 29-30). Aplicações desta natureza requerem que a qualidade e o corte em todo e qualquer esforço desnecessário, inclusive

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


M etodologias Ágeis

na documentação. Sendo assim, no desenvolvimento ágil, o competência individual como o fator primordial para o suces-
conhecimento é tácito e reside apenas na mente de cada inte- so de projetos conduzidos de acordo com os Métodos Ágeis.
grante de equipe. Em alguns casos, as organizações tornam-se Mencionam que “[...] se as pessoas forem boas o suficiente,
dependentes desta equipe e muitas vezes há uma mudança no podem usar praticamente qualquer processo e atingir seus
balanço do poder, entre os gerentes e os programadores, sendo objetivos. Se as pessoas não forem boas o bastante, não há
os últimos os detentores das informações. Para minimizar este processo que possa reparar esta inadequação” (COCKBURN;
impasse, Nerur et al (op. cit.) e TURK et al (op. cit.) sugerem que HIGHSMITH, 2001b, p. 131). A falta de apoio executivo e dos
seja claramente definido o que deve ser documentado e o que principais usuários, por outro lado, é apontada como um
pode ser mantido como conhecimento tácito. grande empecilho para o alcance do sucesso de um projeto,
O pressuposto de interação com os clientes é outro ponto levando até mesmo excelentes profissionais ao não cumpri-
amplamente discutido e criticado por vários autores. Turk et al mento de seus objetivos.
(2005, p. 12) esclarece que os Métodos Ágeis pressupõem que Em 2003, um estudo de caráter exploratório desenvolvido
os clientes estão sempre disponíveis para participar, esclarecer por Lazaveric (classificado pelo próprio autor como “sem si-
dúvidas e tomar decisões junto à equipe de desenvolvimento, milar” na área até aquele momento) identificou os principais
o que na prática nem sempre se mostra viável. Nerur et al (2005, fatores críticos de sucesso de projetos de desenvolvimento de
p. 76) complementam que o ambiente pluralista de tomada de software conduzidos com o uso de Métodos Ágeis (LAZARE-
decisões (que envolve clientes e equipe de desenvolvimento), VIC, 2003). A pesquisa foi realizada por meio da aplicação de
estimulado pelos Métodos Ágeis, torna o processo decisório um questionário a profissionais que haviam gerenciado ou
mais lento e difícil, quando comparado ao enfoque clássico, participado de projetos com tais características, integrantes de
em que o gerente do projeto é o responsável por tal. Nerur et cinco grupos da internet especializados na troca de experiência
al (Ibid.) destacam que o sucesso dos Métodos Ágeis depende e na discussão dos principais Métodos Ágeis. Apesar de obter
de se encontrar clientes que almejem e tenham disponibilidade uma taxa de resposta de apenas 4% (o autor acredita que este
para uma participação ativa no processo de desenvolvimento, número deva ser maior, dado que muitos dos integrantes dos
que sejam colaborativos, representativos e comprometidos e referidos grupos encontravam-se inativos), a pesquisa per-
que disponham da autonomia e do conhecimento adequados mitiu a identificação de fatores críticos de sucesso para tais
ao projeto projetos que se mostraram bastante alinhados às colocações
Há que se mencionar ainda, a questão da manutenção de de autores como Cockburn e Higsmith (2001b), Cohen et al
software, qualificada como algo tão problemática quanto o (2003) e Reifer (2002).
desenvolvimento propriamente dito e ainda pouco abordada A existência de programadores motivados foi identificada
pelos Métodos Ágeis (RUS et al, 2002; COHEN et al, 2003). como a chave para o sucesso dos projetos pesquisados, sendo
Todas estas limitações apontadas por autores e estudiosos do considerado o fator crítico mais importante para projetos
assunto (TURK et al, 2003 e 2005; NERUR et al, 2005; BOGER conduzidos com o uso de Métodos Ágeis. O segundo fator
et al, 2001; McBREEN, 2003) devem ser avaliadas quando da crítico de sucesso identificado foi o grau de propriedade
definição método de desenvolvimento de software a ser uti- coletiva do código. A propriedade coletiva pressupõe que
lizado. Contudo, apesar de sua importância, não podem ser qualquer integrante da equipe pode alterar o código desen-
consideradas como única verdade, uma vez que a literatura volvido por outrem e contribuir para a solução e encoraja a
aponta exemplos de projetos conduzidos com o uso de Métodos sinergia, a colaboração e o trabalho em equipe. A descoberta
Ágeis que foram bem-sucedidos, apesar das condições teorica- deste segundo fator está totalmente alinhada ao primeiro
mente adversas à sua utilização. Entre estes exemplos podem item. Lazarevic (2003, p. 28) destaca que “[...] atingir um
ser citados: o desenvolvimento de um software de missão estágio em que os resultados do grupo sejam melhores que
crítica com o uso do XP (GAWLAS, 2003) e a utilização do XP a contribuição de cada indivíduo é o coração de muitos
e do Scrum em projetos com mais de 100 pessoas distribuídas Métodos Ágeis”. Ainda, de acordo com Sutherland (2001),
em mais de um continente (Fowler, 2003). quando os indivíduos se ajudam mutuamente e contribuem
para o todo, a equipe de desenvolvimento atinge o estado
Fatores Críticos de Sucesso de Projetos de de hiper-produtividade. O terceiro fator encontrado diz
Desenvolvimento de Software Realizados co m o Uso respeito à entrega de um protótipo logo no início do projeto.
dos Métodos Ágeis Para Lazarevic (Ibid.), a maioria dos respondentes interpre-
Poucas são as referências na literatura que discutem a questão tou esta questão à luz das necessidades de mudanças de
dos fatores críticos de sucesso de projetos conduzidos com requisitos, ou seja, da necessidade de um desenvolvimento
o uso de Métodos Ágeis. Cohen et al (2003, p. 31) destacam incremental do software.
que são três os principais fatores críticos de sucesso para um Nesse mesmo estudo, Lazaveric (2003, p. 24) menciona que
projeto conduzido segundo um enfoque ágil, a saber: cultura, os projetos desenvolvidos segundo os métodos Extreme Pro-
pessoas e comunicação. gramming (XP) e Dynamic Software Development Model (DSDM)
Cockburn e Highsmith (2001b), autores que defendem uma foram mais bem-sucedidos, mas este resultado não se mostrou
visão dos Métodos Ágeis centrada nas pessoas, identificam a estatisticamente significativo.

Edição 20 - Engenharia de Software Magazine 19


Como informação adicional desta pesquisa, tem-se que a Scrum, o FDD e o ASD, Thomsett (2002, p. 17) indica a neces-
maioria dos respondentes possuía de um a quatro anos de sidade de uma abordagem mais ampla e, preferencialmente,
experiência em Métodos Ágeis, o que confirma que a utili- em separado das questões técnicas.
zação destes métodos no desenvolvimento de software é um Analisando os fatores críticos de sucesso identificados,
fenômeno relativamente novo. O tamanho das equipes dos percebe-se que estão estritamente relacionados à valorização
projetos analisados variava entre quatro e vinte integrantes, da competência individual e à comunicação (REIFER, 2002;
sendo que apenas 10% dos projetos tiveram mais de 50 parti- COCKBURN; HIGHSMITH, 2001b; LAZAREVIC, 2003) e à
cipantes (LAZAREVIC, 2003, p. 26). entrega rápida de valor (LAZAREVIC, 2003). Todos estes itens
Como muitos outros autores (REIFER, 2002; COCKBURN; correspondem a características marcantes dos Métodos Ágeis
HIGHSMITH, 2001b), Lazarevic (2003, p. 29) não considera seu de Desenvolvimento de Software e o também do Gerenciamen-
estudo representativo, não devendo assim ser generalizado. to Ágil de Projetos, o que pode sugerir que talvez este seja o
Mas o enfoque diferenciado de seu trabalho, em especial, sua enfoque de gerenciamento de projetos mais apropriado para
abrangência (obtenção de dados de diferentes projetos, de pro- o desenvolvimento de software conduzido com o uso de um
fissionais provenientes de distintas organizações), certamente Método Ágil.
contribui para a ampliação do conhecimento na área.
Dê seu feedback sobre esta edição! Feedback
Ampliando a visão dos fatores críticos de sucesso, Chin (2004), eu

s

assim como Cohn e Ford (2003), Highsmith (2004) e Nerur et A Engenharia de Software Magazine

sobre e
al (2005), ressaltam que não se pode esquecer o inegável valor tem que ser feita ao seu gosto.

s
ta
do gerenciamento de projetos na entrega de um projeto de
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
desenvolvimento de software bem-sucedido. Apesar de alguns Dê seu voto sobre este artigo, através do link:
Métodos Ágeis já possuírem componentes de gerenciamento
www.devmedia.com.br/esmag/feedback
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 BOHEM, Barry. Get ready for agile methods, with care. IEEE Computer Magazine, [S.l.], Jan. 2002, p. 64-69.
of the 25th International Conference on Software Engineering. [S.l.]. IEEE Software Society, 2003,
BOHEM, Barry.; TURNER, Richard. Balancing discipline and agility: evaluating and integrationg
p. 244-254.
plan-driven methods. In: Proceedings of the 26th Conference on Agile Development. IEEE
AGILE ALLIANCE. Manifesto for agile software development. Disponível em <http://www. COMPUTER SOCIETY, [S.l.], May 2004, p. 718-719.
agilemanifesto.org/>. Acesso em janeiro, 2005. BONATO, A. S. F. Uma experiência de aplicação do processo Extreme Programming em pequenos
AMBLER, S. W. Agile modeling: effective practices for extreme programming and the unified projetos. São Paulo, 2004. Dissertação (Mestrado em Engenharia) - Programa de Pós-Graduação
process. John Wiley & Sons, Inc., 2002a. em Engenharia, Escola Politécnica da Universidade de São Paulo.

AMBLER, S.W. Lessons in agility from internet-based development. IEEE Software, [S.l.], v. 19, n. BRASIL. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. Levantamento do
2, 2002b, p. 66–73. universo de Associadas Softex. Brasília - DF, 2001a.

AMBLER, S.W. When does(n´t) agile modeling make sense. Apr, 2002c. Disponível em <http:// ______. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. Qualidade e
www.agilemodeling.com/essays/whendoesAmWork.htm>. Acesso em julho de 2005. Produtividade no Setor de Software Brasileiro. Brasília - DF, 2001b.

AMBLER, S. W. Quality in an agile world. Software Quality Professional, [S.L.], v. 7, n. 4, sep. 2005. CHIN, Gary. Agile project management: how to succeed in the face of changing project
requirements. NY: Amacon, 2004.
BECK, K.Embrance Change with Extreme Programming.IEEE Computer Magazine, [S.l.], Oct 1999, p.70-77.
COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Addison-
______. Extreme programming explained. Boston: Addison-Wesley, 2000.
Wesley, 2004.
BECK,Kent.et al.Chrysler goes to“extremes”.Oct,1998.Disponível em <http://www.xprogramming.
______. Agile software development. Boston: Addison-Wesley, 2001.
com/publications/dc9810cs.pdf>. Acesso em julho, 2005.

BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em <http:// ______. Learning from agile software development – part one. Crosstalk, The Journal of Defense
www.agilemanifesto.org/>. Acesso em janeiro, 2005. Software Engineering, [S.l.], October 2002.

BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001. COCKBURN, A.; HIGHSMITH, J. Agile software development: the business of inovation. IEEE
Computer Magazine, [S.l.], p. 131-133, sep 2001a.
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 ______. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-
veness>. Acesso em novembro, 2004. 133, nov 2001b.

BOGER, M. et al. Extreme modeling. In: SUCCI, G.; Marchesi, M. (eds). Extreme programming COHEN, David et al. Agile software development: a DACS state of art report. NY: Data Analysis Center for
examined. Boston: Addison-Wesley, 2001. 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.

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


M etodologias Ágeis

Continuação: Referências

COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA executivo. Trad. Afonso Celso da ______. On the productivity of agile software practices: an industrial case study. Abr. 2004.
Cunha Serra. Rio de Janeiro: Campos, 2002. Disponível em: <http://sern.ucalgary.ca/ milos/papers/2002/MaurerMartel2002c.pdf>. Acesso
em Agosto, 2005.
COHN, Martin. The scrum development process. Disponível em <www.mountaingoatsoftware.
com/scrum> Acesso em julho, 2005. McBREEN, P. Questioning extreme programming. Boston: Addison-Wesley, 2003.

COHN, Martin; FORD, Doris. Introducing an agile process to an organization. IEEE Computer NERUR, S. et al. Challenges of migrating to agile methodologies: organizations must carefully
Magazine, June 2003, [S.l.], p. 74-78. assess their readiness before treading the path of agility. Communication of the ACM, [S.l.], v.48,
n.5, p 73-78, May 2005.
DEMING, W. E. Qualidade: a revolução da administração. Rio de Janeiro: Marques Saraiva, 1990.
PALMER, S. R.; FELSING, M. A practical guide to feature-driven development. [S.l.]: Pearson
FERREIRA, A. A., REIS, A. C. F., PEREIRA, M. I. Gestão empresarial: de Taylor aos nossos dias. São Paulo:
Education, 2001.
Thomson, 2002, p. 146-164.

FOWLER, Martin. The new methodology. April, 2003. Disponível em <http://www.martinfowler. PAULK, Mark. C. ExtremepProgramming from a SW-CMM perspective. IEEE Software, [S.l.], v. 18,
com/articles/newMethodology.html>. Acesso em julho, 2005. n. 6, p. 19–26, Nov. 2001.

GAWLAS, J. Mission critical development with XP & agile process: common code ownership and ______. Agile methodologies and process discipline. Crosstalk - The Journal of Defense Software
lots of testing. Dr. Dobb´s Journal, [S.l.], p. 21-24, Jan. 2004. Engineering, [S.l.], v. 15, n. 10, p. 15–28, Oct. 2002.

GLASS, Robert. Extreme programming: the good, the bad and the bottom line. IEEE Software, [S.l.], POPPENDIECK. M. Lean programming. Software Development Magazine. May-June, 2001
Nov. 2001, p. 111-112. Disponível em <http://www.agilealliance.org/articles/articles/LeanProgramming.htm>. Acesso
em julho, 2005.
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. 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.
HIGHSMITH, Jim. Adaptative management: patterns for the e-business era. Cutter IT Journal, [S.l.],
v. XII, n. 9, sep. 1999. RUS, I. et al. Process diversity in software maintenance – guest editors´s introduction. Software
HIGHSMITH, Jim. Agile software development ecosystems. Boston: Addison-Wesley, 2002. Maintenance Research and Practice, Dec. 2002.

______. Agile project management: creating innovative products. Boston: Addison-Wesley, 2004. SCHWABER, K.; BEEDLE, M. Agile software development with scrum. NJ: Pretence Hall, 2001.

HIGHSMTIH, Jim et al. Extreme programming: e-business application delivery. Feb. 2002. Disponível SCHWABER, K. Controlled chaos: living on the edge. 2002. Disponível em <http://www.
em <http://www.cutter.com/freestuff/ead0002.pdf>. Acesso em julho, 2004. agilealliance.org/articles/articles/ap.pdf>. Acesso em junho, 2005.

JURAN, J. M.; GRYNA, F. M. Controle da qualidade – handbook: conceitos, políticas e filosofia da THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002.
qualidade. São Paulo: Makron, McGraw-Hill, 1991 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.
JURIC, R. Extreme Programming and its Development Practices. In: Proceedings of 22nd
international conference on information technology interfaces. 2002, p. 97–104. ______.Assumptions underlying agile software development process.Colorado State University, 2005.

LAZAREVIC, George. An exploratory study of the new product development utilized by software UDO, N., KOPPENSTEINER, S. Will agile change the way we manage software projects? Agile from a
companies using agile product development approach. Oct. 2003. Disponível em <http://www. PMBoK guide perspective. Projectway, [S.l.], 2003.
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.

Edição 20 - Engenharia de Software Magazine 21


Gerenciamento Ágil de Projetos de Software

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

O
Gerenciamento Ágil de Projetos ou software surgiram com intuito de lidar com os prin-
Agile Project Management (APM) cipais pontos fracos das abordagens tradicionais.
foi criado a partir dos valores Conhecer estas alternativas ganha importância na
e princípios dos Métodos Ágeis de De- medida em que novos projetos surgem com carac-
senvolvimento de Software, retratados terísticas diferenciadas que nos levam à necessida-
no Manifesto para o Desenvolvimento Ágil de de utilizar métodos mais “ágeis” para apoiar o
de Software (BECK et al, 2001). Conectado planejamento e acompanhamento das atividades
a iniciativas correlatas das indústrias do projeto.
de construção civil e aeroespacial (uma
vez que o cenário de complexidades e Em que situação o tema é útil?
incertezas era comum a todos), o mo- Os projetos de desenvolvimento de software são
vimento para o desenvolvimento ágil normalmente caracterizados por um elevado grau
de software ampliou sua abrangência, de incertezas iniciais e, conseqüentemente, por
sendo estendido ao gerenciamento de uma grande dificuldade de detalhamento do esco-
projetos (HIGHSMITH, 2004, p. xix). po e de elaboração de um planejamento completo.
Chin (2004, p.1) afirma que “[...] em pro- Neste cenário de incertezas, abordagens ágeis para
jetos que envolvem tecnologia, balancear gerenciamento de projetos de software têm sido
Marisa Villas Boas Dias os requisitos do gerenciamento clássico vistas como uma alternativa interessante. Conhe-
de projetos e as necessidades de uma cer tais abordagens é um passo fundamental neste
equipe altamente capacitada e criativa é cenário.
mais uma arte que uma ciência”. Explica

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


metodologias ágeis

que, se por um lado o excesso de formalidade e de processos 2. Adaptabilidade do produto: os produtos desenvolvidos devem
tende a inibir a equipe e bloquear a inovação, por outro, a falta não só oferecer valor ao cliente no presente, mas ser também
de estrutura pode fazer com que os objetivos do projeto nunca adaptáveis às novas necessidades do futuro;
sejam atingidos. 3. Tempos de entrega reduzidos: foco, direcionamento preciso
Por muitos anos, o gerenciamento de projetos se desenvol- e capacidade técnica da equipe são fundamentais para a re-
veu sobre uma sólida plataforma, capaz de dar suporte a dução dos prazos de desenvolvimento de produtos visando
diferentes tipos de projeto, nos mais variados ambientes. As ao melhor aproveitamento das oportunidades de mercado e
organizações adotaram o Gerenciamento Clássico de Proje- um melhor retorno sobre o investimento;
tos, propuseram e implementaram melhorias e adaptações, 4. Capacidade de adaptação do processo e das pessoas: formação de
criando seus próprios modelos e expandindo a plataforma equipes cujos integrantes estejam confortáveis com mudanças
clássica de gerenciamento de projetos (CHIN, 2004, p. 1-3). No e que não as enxerguem como obstáculos e sim como desafios
entanto, Chin (Ibid.) explica que, como qualquer plataforma, o de um ambiente dinâmico; estabelecimento de processos que
Gerenciamento Clássico de Projetos apresenta restrições e ao respondam rapidamente às alterações do negócio;
se aproximar do limiar de sua abrangência, estas restrições 5. Resultados confiáveis: entrega de produtos de valor ao
se tornam mais visíveis e o seu desempenho, menos efetivo. cliente, garantindo a operação, o crescimento e aumento da
Continuar o desenvolvimento desta plataforma clássica, lucratividade da empresa.
segundo o autor, em alguns momentos é mais difícil do que
estruturar uma nova idéia. O Gerenciamento Ágil de Projetos pode ser visto como
Neste contexto, Chin (2004, p. 1-3) propõe a criação de um uma resposta de âmbito gerencial às crescentes pressões por
novo modelo e não uma simples expansão do Gerenciamen- constantes inovações, à concorrência acirrada, à necessidade
to Clássico de Projetos. O Gerenciamento Ágil de Projetos de redução dos ciclos de desenvolvimento e implantação de
surge, então, como uma nova plataforma de gerenciamento novos produtos ou serviços e à necessidade de adaptação a
de projetos (Figura 1), aplicável a ambientes voláteis e desa- um ambiente de negócio bastante dinâmico (HIGHSMITH,
fiadores, sujeitos a mudanças frequentes, em que o processo Ibid.).
prescritivo e padronizado não mais se adéqua (CHIN, 2004,
p. 1-3; HIGHSMITH, 2004, p. 5). Definição, Valores e Princípios do Gerenciamento
Segundo Highsmith (2004) e Chin (2004), o Gerenciamento Ágil de Projetos
Ágil de Projetos se desfaz da postura antecipatória, fortemen- Highsmith (2004, p.16) define o Gerenciamento Ágil de
te calcada no planejamento prévio de ações e atividades, típica Projetos como “[...] um conjunto de valores, princípios e prá-
do gerenciamento clássico de projetos, e busca o desenvolvi- ticas que auxiliam a equipe de projeto a entregar produtos
mento da visão do futuro e da capacidade de exploração. ou serviços de valor em um ambiente desafiador”. Os valores
Enfocando este último ponto, Highsmith (2004, p. 6) afirma e os princípios descrevem o porquê do Gerenciamento Ágil
que são cinco os objetivos principais para um bom processo de Projetos e as práticas descrevem como realizá-lo. Apesar
de exploração, que acabam por constituir a base para o Ge- de ratificar a necessidade de entregar produtos confiáveis
renciamento Ágil de Projetos: aos clientes dentro de restrições de prazo e custos, comum
1. Inovação contínua: entrega de produtos que atendam aos ao Gerenciamento Clássico de Projetos, Highsmith (2004,
requisitos dos clientes e agreguem valor ao negócio. A ideia p. 6) menciona que o Gerenciamento Ágil de Projetos pode
de inovação é associada a um ambiente organizacional cuja ser considerado “mais uma atitude que um processo, mais
cultura estimule o autogerenciamento e a autodisciplina; ambiente que metodologia”.

Redução de eficácia e eficiência


da plataforma clássica de
Extensões do gerenciamento de projetos
Gerenciamento de
Projetos

Plataforma -
Gerenciamento
Plataforma Clássica do
Ágil de
Gerenciamento de
Projetos
Projetos

Figura 1. Relacionamento entre as plataformas de gerenciamento clássico e ágil de projetos (FONTE: CHIN, 2004, p.3)

Edição 20 - Engenharia de Software Magazine 23


Os valores principais deste novo enfoque de gerenciamento no projeto, Highsmith (Ibid.) menciona que o cliente deve
de projetos endereçam tanto a necessidade de criação e entrega “reinar soberano” e apresenta a seguinte definição de clien-
de produtos ágeis, adaptáveis e de valor, como a necessidade te: “[...] um indivíduo ou grupo de indivíduos que usa os
de desenvolvimento de equipes de projeto com as mesmas produtos ou serviços para gerar valor ao negócio”.
características (HIGHSMITH, 2004, p.10). Os quatro valores Considerando o quarto valor, Highsmith (2004, p. 13-14)
centrais do Gerenciamento Ágil de Projetos são: afirma que os processos servem como guias ou trilhas e as
1. As respostas às mudanças são mais importantes que o se- ferramentas são utilizadas para melhorar a eficiência, mas
guimento de um plano; sem pessoas com qualificações técnicas e comportamentais
2. A entrega de produtos está acima da entrega de adequadas, nenhum processo ou ferramenta produz resultado
documentação; algum. O movimento ágil deposita elevado valor no indivíduo e
3. Priorização da colaboração do cliente sobre a negociação reconhece sua capacidade de auto-organização, autodisciplina
de contratos; e sua competência.
4. Os indivíduos e suas interações são mais importantes que Enfocando o sucesso na ótica do Gerenciamento Ágil de
os processos e as ferramentas. Projetos, Highsmith (2004, p. 27) menciona que o sucesso é
direcionado pelas pessoas e suas interações e não por pro-
Com relação ao primeiro valor, Highsmith (2004, p. 10-11) cessos e estruturas. As competências e habilidades indivi-
afirma que os projetos exploratórios, alvo do Gerenciamento duais, as interações entre pessoas ou equipes tecnicamente
Ágil de Projetos, são caracterizados por processos que enfati- qualificadas e a capacidade da equipe aprender e aplicar os
zam a visão do futuro e a exploração, ao invés do planejamento conhecimentos adquiridos são determinantes para o sucesso
detalhado e a respectiva execução. Highsmith (Ibid.) e Chin ou o fracasso de um projeto, estando estritamente ligados ao
(2004, p. 1-3) mencionam que não se trata apenas de absorver atendimento das expectativas do cliente. Como as pessoas são
pequenas alterações de escopo, prazo ou custo, mas sim, de normalmente guiadas por um conjunto interno de valores,
dar abertura à mudança completa de planos, requisitos, tec- desenvolver a agilidade depende do perfeito alinhamento
nologia e arquitetura no decorrer do projeto. Highsmith (op. entre o ambiente e este sistema de valor de cada indivíduo.
cit.) embasa seu ponto de vista, ao apresentar o caso de uma Esta é a razão pela qual o Gerenciamento Ágil de Projetos é
companhia que, erroneamente, se recusou a mudar o plano fortemente calcado em valores e também o motivo por que
traçado inicialmente para um projeto de desenvolvimento de muitas vezes é impossível a aplicação do Gerenciamento Ágil
software, orçado em aproximadamente US$125 milhões, o que de Projetos em determinadas organizações ou equipes (tal
a levou a um grande e custoso desastre. Para Highsmith (Ibid.), como ocorre com a adoção dos Métodos Ágeis de Desenvol-
“[…] planejar o trabalho e executar o plano” não é um lema vimento de Software).
adequado a uma grande variedade de projetos, em especial Além dos valores, o Gerenciamento Ágil de Projetos possui
para os projetos de desenvolvimento de novos produtos (ou um conjunto de princípios mestres, que norteiam sua apli-
software) ou àqueles relacionados a qualquer tipo de inova- cação. De acordo com Larson e LaFasto (1989), a liderança
ção tecnológica. Esta posição está alinhada às proposições de baseada em princípios é uma das características mais impor-
Thomsett (2002) e Chin (2004). tantes das equipes de alto desempenho. Highsmith (2004, p.
Abordando o segundo valor, ao estabelecer a prioridade da 27-28) estabelece seis princípios, divididos em duas categorias
entrega de produtos sobre a preparação de uma documentação (Tabela 1), que auxiliam as equipes de projeto a determinar
exaustiva, Highsmith (2004, p. 11-12) argumenta que não se como proceder, ou seja, ajudam-nas a definir quais práticas
trata de menosprezar a importância da documentação, mas são mais apropriadas, a gerar outras práticas quando neces-
sim de assumir que os resultados só podem ser avaliados sário, ou mesmo, a avaliar algumas que venham a surgir e
pela equipe de projeto e pelo cliente quando algo concreto é implementá-las com agilidade. Embora cada princípio seja
apresentado, ou seja, quando se tem um produto (ou softwa- útil se aplicado isoladamente, o sistema formado por eles cria
re) operante. Highsmith (Ibid.) defende a manutenção de um um ambiente que encoraja e produz resultados mais efetivos
patamar mínimo e suficiente de documentação para auxiliar o (HIGHSMITH, Ibid.).
processo de comunicação e colaboração, propiciar a transferên-
cia de conhecimento, preservar a informação histórica, servir Categoria Princípio
de base para a melhoria de produtos e processos e, algumas Entregar valor ao cliente
vezes, atender aos requisitos legais. Valor ao cliente Gerar entregas iterativas e baseadas em funcionalidades
O terceiro valor, por sua vez, tem por pressuposto o esta- Buscar a excelência técnica
belecimento de uma parceria entre o cliente e a equipe de Encorajar a exploração
projeto, na qual cada um tem papéis e responsabilidades Estilo de gerenciamento baseado na Construir equipes adaptativas (auto-organizadas e
específicos e bem definidos, sendo cobrados por isso. Esta liderança e colaboração autodisciplinadas)
parceria deve ser marcada por uma forte colaboração e não Simplificar
por disputas contratuais (HIGHSMITH, 2004, p. 13). Apesar
Tabela 1. Princípios do gerenciamento ágil de projetos (FONTE: ADAPTADO
de reconhecer a existência de diferentes partes interessadas DE HIGHSMITH, 2004, p. 27.)

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


metodologias ágeis

Ciclo de Vida e Fases do Gerenciamento Ágil de Projetos iterações tem-se o término do projeto. Este padrão ou fluxo
Apesar dos processos não serem tão importantes quanto típico dos projetos ágeis, bem como o nível de atividade,
as pessoas no Gerenciamento Ágil de Projetos, isto não sig- são apresentados na Figura 2. Esta estruturação favorece a
nifica que não se dê importância a eles. Highsmith (2004, p. entrega de valor e a geração de um ambiente que propicie o
79) e Chin (2004, p. 14) defendem que não se deve atribuir aprendizado contínuo (UDO; KOPPENSTEINER, op. cit.).
aos processos uma conotação negativa, vinculada ao excesso O Gerenciamento Ágil de Projetos está estruturado em cinco
de documentação e padronização, à característica estática fases assim descritas (HIGHSMITH, 2004, p. 81):
e prescritiva, difícil de ser mudada, conforme alardeiam 1. Visão: compreende a determinação da visão do produto e
alguns seguidores do movimento ágil. Segundo os autores, do escopo do projeto, a identificação da comunidade do pro-
os processos, como qualquer outro elemento de uma organi- jeto (clientes, gerente de projeto, equipe de projeto e outras
zação, devem estar estritamente alinhados aos objetivos de partes interessadas) e a definição de como a equipe de projeto
negócio. Em se tratando de operações contínuas e repetiti- trabalhará em conjunto;
vas, processos prescritivos são plenamente justificáveis. Por 2. Especulação: engloba a identificação dos requisitos iniciais
outro lado, se o ambiente for dinâmico e volátil, a estrutura para o produto, a definição das atividades, o desenvolvimento
de processos deve ser orgânica, flexível e facilmente adap- de um plano de projeto (contendo entregas, marcos, várias
tável (HIGHSMITH, op. cit..; CHIN, op. cit.). iterações, cronograma de trabalho e alocação de recursos),
Sendo assim, a estrutura de processos para o Gerenciamento a incorporação de estratégias para mitigação de riscos, as
Ágil de Projetos deve ter por foco o conceito de agilidade estimativas de custos e outras informações financeiras rele-
e englobar os princípios apresentados no tópico anterior, vantes. Nesta etapa é elaborado um planejamento preliminar,
assim como assegurar o alcance dos objetivos de negócio. seguido por planejamentos específicos a cada iteração;
Para tanto, deve: 3. Exploração: corresponde à entrega dos produtos planejados,
• Favorecer a exploração e a cultura adaptativa; através do gerenciamento da carga de trabalho e do emprego
• Permitir a auto-organização e a autodisciplina; de práticas e estratégias de mitigação de risco apropriadas.
• Promover a confiabilidade e a consistência possíveis, dados Estas entregas são feitas sob a forma de incrementos de
o grau de incertezas e a complexidade inerentes ao projeto; funcionalidades do produto e são divididas entre os ciclos
• Ser flexível e facilmente adaptável; do projeto;
• Permitir visibilidade ao longo do processo; 4. Adaptação: compreende a revisão dos resultados entregues,
• Incorporar o aprendizado; a análise da situação atual e a avaliação do desempenho da
• Englobar as práticas específicas de cada fase; equipe e do projeto, para eventual adaptação. Esta revisão
• Prover pontos de verificação. objetiva não apenas uma comparação do “realizado versus
planejado”, mas principalmente do “realizado versus informa-
Segundo Udo e Koppensteiner (2003, p. 5) e Highsmith (2004, ções e requisitos atualizados do projeto”, para a identificação
p. 81), um projeto típico do Gerenciamento Ágil de Projetos das mudanças necessárias;
possui uma etapa inicial, seguida por vários ciclos ou itera- 5. Encerramento: referente à finalização das atividades do pro-
ções. A cada ciclo é feito um novo planejamento de escopo, jeto, à transferência dos aprendizados-chave e à celebração.
prazo, custo e qualidade, visando à entrega de produtos ou
resultados e possibilitando incrementos de funcionalidades O relacionamento entre estas fases pode ser visualizado na
conforme a necessidade do negócio. Ao final das várias Figura 3.

•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 Controle
Contínuo

Início Iteração 1 Iteração 2 Iteração 3 Iteração 4 Encerramento

Figura 2. Fluxo do gerenciamento ágil de projetos (FONTE: ADAPTADO DE UDO; KOPPENSTEINER, 2003, p. 5)

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 (HIGHSMITH, 2004, p. 86). O autor, entretanto, é avesso à ideia
se alternam a cada iteração, no intuito de refinar o produto do da adoção de “melhores práticas”, ao afirmar que as práticas
projeto. A etapa de Especulação é retomada com objetivo de são apenas maneiras de se executar algo e que podem ser
planejar o novo ciclo, levando em consideração os resultados boas ou ruins, a depender do contexto em que estão inseridas.
até então alcançados no projeto e os incrementos ou alterações Highsmith (Ibid.) menciona que as práticas do Gerenciamento
de escopo solicitados até o momento. Algumas vezes, o retorno Ágil de Projetos se mostram úteis em uma grande diversidade
à fase Visão pode ser necessário, em especial quando se têm de situações e que também podem ser aplicadas no Gerencia-
modificações muito significativas no escopo projeto. Uma vez mento Clássico de Projetos. Por outro lado, admite que outras
obtido o produto final, segue-se o Encerramento do projeto práticas, não mencionadas no modelo em questão, podem
(HIGHSMITH, 2004, p. 85). 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 O propósito da fase Visão é identificar de maneira clara “o
gerenciamento de projetos, para cada fase do Gerenciamen- que” precisa ser feito e “como” o trabalho será realizado. Para
to Ágil de Projetos existe um conjunto de práticas, que em tanto, suas práticas estão estruturadas em quatro categorias:
sua totalidade, formam um sistema de práticas. Este sistema visão do produto, escopo do projeto, comunidade do projeto e abor-
não só alinha os valores e os princípios do Gerenciamento dagem (HIGHSMITH, 2004, p. 88-92), que são apresentadas na
Ágil de Projetos, mas permite também a sua implementação 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 Neste contexto, Highsmith (2004, p. 169-209) propõe um con-
Segundo Highsmith (2004, p. 128-131), a fase Especulação tem por junto de práticas divididas em três categorias: entrega segundo os
objetivo a elaboração de um plano de entregas que represente o objetivos, práticas técnicas e comunidade do projeto. Estas práticas
melhor entendimento da equipe de projeto, em um dado momen- podem ser visualizadas na Tabela 4.
to do projeto. A utilização da palavra especulação no lugar de
planejamento está estritamente relacionada ao reconhecimento Prática da Fase Adaptação
do elevado grau de incertezas e de mudanças que caracteriza Se no cenário do Gerenciamento Ágil de Projetos os planos
um projeto-alvo do Gerenciamento Ágil de Projetos. O plano são especulações acerca do futuro, então é grande a necessida-
resultante desta etapa é construído a partir de informações da de de feedbacks frequentes e efetivos para a validação das hipó-
especificação e da arquitetura do produto, dos riscos envolvidos, teses assumidas (HIGHSMITH, 2004, p. 213-215). As adaptações
do padrão de qualidade ou do nível de defeito estabelecido, das dependem do manuseio e entendimento de uma vasta gama
restrições do negócio e dos marcos do projeto. de informações, que incluem o progresso do projeto, os riscos
As práticas de fase Especulação, repetidas a cada ciclo ou técnicos, a evolução dos requisitos do produto e a análise do
iteração, são divididas em duas categorias: estrutura analítica mercado. A equipe de projeto deve avaliar e tomar decisões
do produto e planejamento de entregas (HIGHSMITH, 2004, p. constantes sobre quatro pontos principais:
132-164), sendo retratadas na Tabela 3. • Funcionalidades primárias, segundo a perspectiva da equipe
do cliente;
Práticas da Fase Exploração • Qualidade do produto, de acordo com as perspectivas da
A fase Exploração visa a entrega dos produtos planejados, a equipe técnica;
cada ciclo do projeto, através do gerenciamento da carga de • Desempenho da equipe do projeto;
trabalho e do emprego de práticas e estratégias de mitigação de • Progresso do projeto.
risco apropriadas (HIGHSMITH, 2004, p. 166-168). De acordo
com Highsmith (Ibid.) e Chin (2004, p. 69-81), �����������������
a essência do pa- A fase Adaptação possui apenas uma prática – revisão do
pel do gerente de projetos no Gerenciamento Ágil de Projetos produto / projeto / equipe e ações de adaptação – divida em várias
não é a elaboração de um cronograma detalhado e a preparação subpráticas, como mostra a Tabela 5 (HIGHSMITH, 2004, p.
dos relatórios de progresso (apesar de ambos fazerem parte de 211-231).
seu trabalho), mas sim a criação e o desenvolvimento de uma
equipe de alto desempenho a partir de um grupo de pessoas Prática da Fase Encerramento
e estabelecer um estilo de liderança e gerenciamento que en- O Encerramento do projeto é tanto uma fase como uma prá-
coraje a inovação e incentive a aceitação de situações de risco tica. Como recursos humanos qualificados são normalmente
e de mudanças constantes. escassos, há uma forte tendência por parte das organizações

Categoria Prática Descrição


Estrutura analítica do produto Lista de funcionalidades do produto Expansão da visão do produto, através da definição de seus requisitos, gerando uma lista de funcionalidades do produto
Cartões de funcionalidades Criação de um documento padrão para o registro das funcionalidades e requisitos do produto e das estimativas
de prazo para seu desenvolvimento
Cartões de requisitos de desempenho Documentação dos requisitos de desempenho e operação do produto a ser entregue
Planejamento das entregas Plano de entregas, marcos e iterações 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
Tabela 3. Práticas da fase “Especulação” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 131-164.)
Categoria Prática Descrição
Entrega segundo os objetivos Gerenciamento da carga de trabalho 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
Práticas técnicas Mudanças de baixo custo 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
Comunidade do projeto Aconselhamento e desenvolvimento da equipe 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
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
atividades do projeto
Decisões participativas Fornecimento à comunidade do projeto de práticas específicas para entender, analisar e/ou tomar
decisões ao longo do projeto
Interações diárias com o cliente 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
Tabela 4. Práticas da fase “Exploração” do gerenciamento ágil de projetos (FONTE: ADAPTADO DE HIGHSMITH, 2004, p. 169-209.)

Edição 20 - Engenharia de Software Magazine 27


Prática Descrição Subprática
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. - 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
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; Várias organizações interessadas;


Uma única organização interessada
externas internas
Projetos operacionais Gerenciamento Clássico de Projetos Gerenciamento Clássico de Projetos 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 Gerenciamento Ágil de Projetos
Projetos de desenvolvimento de novas tecnologias / Gerenciamento Clássico de Projetos / Gerenciamento Ágil 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 de inovação, criatividade, que envolvam tecnologia de ponta,
do término de um projeto, sem estes profissionais recebam, equipes de alto desempenho, que estejam sujeitos a incertezas
ao menos, os créditos pela realização. Entretanto, há várias ou inseridos em ambientes de negócio dinâmicos. Highsmith
atividades a serem realizadas na etapa final de um projeto. (2004, p. 4) indica formalmente o uso do Gerenciamento Ágil
A primeira delas é a celebração, que tem dois propósitos de Projetos para o desenvolvimento de software.
fundamentais: reconhecer aqueles que trabalharam muito Chin (2004, p. 13-21) propõe um modelo, apresentado na Ta-
para que o projeto fosse entregue e marcar o encerramento bela 6, para a verificação da aplicabilidade do Gerenciamento
do projeto. A segunda, menos glamorosa, diz respeito à Ágil de Projetos, levando-se em consideração duas dimensões-
limpeza de eventuais itens em aberto, à entrega da docu- chave, a saber:
mentação final e à preparação dos relatórios financeiros e • Tipo de projeto: projetos operacionais (projetos simples e que
administrativos requeridos. Por fim, tem-se a condução de ocorrem regularmente na organização); projetos de desen-
uma retrospectiva do projeto, visando à obtenção e à di- volvimento de novos produtos / processos; ou projetos de
vulgação das lições aprendidas entre as equipes de projeto desenvolvimento de novas tecnologias / plataformas;
(HIGHSMITH, 2004, p. 231-232). • Organizações envolvidas: apenas uma organização interessada
O encerramento de um projeto, seja ele gerenciado segundo no projeto; várias organizações internas interessadas no proje-
a abordagem ágil ou clássica, é fundamental e marca a tran- to; ou várias organizações externas interessadas no projeto.
sição do produto do projeto para a operação da organização
(HIGHSMITH, Ibid.). Nas áreas onde há a possibilidade de escolha, Chin (Ibid.)
sugere que seja feita uma análise do contexto interno e externo,
Aplicações, Resultados e Limitações do Gerenciamento considerando aspectos culturais e a prontidão da organização
Ágil de Projetos e dos principais interessados no projeto para a adoção de um
Diferentemente dos Métodos Ágeis de Desenvolvimento de enfoque ágil, antes da definição da melhor abordagem. Esta
Software, não foram encontrados estudos analisando a eficá- colocação de Chin (Ibid.) é corroborada por Highsmith (2004)
cia, ou mesmo fornecendo indícios de resultados positivos (ou e considera as ponderações de Ambler (2002c), Cohen et al,
negativos) da aplicação do Gerenciamento Ágil de Projetos. 2003; Fowler (2003) e Nerur et al (2005). Isto porque tanto os
Uma explicação para tal situação pode ser atribuída ao fato de Métodos Ágeis como o Gerenciamento Ágil de Projetos fo-
o assunto ser bastante recente. O que se têm são indicações de ram construídos sobre bases, valores e princípios similares e
alguns autores, como Thomsett (2002), Highsmith (2004) e Chin ambos pressupõem que as organizações estejam preparadas
(2004), acerca dos potenciais de aplicação deste novo enfoque do ponto de vista cultural, organizacional e gerencial para a
de gerenciamento de projetos. sua adoção.
Highsmith (op. cit.) e Chin (op. cit.) sugerem a aplicação do Apesar de não haver na literatura menção específica às
Gerenciamento Ágil de Projetos em projetos de desenvolvi- limitações do Gerenciamento Ágil de Projetos, as ressalvas
mento de novos produtos, ou outros que requeiram alto grau feitas por Turk et al (2005) e Nerur et al (2005) com relação aos

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


metodologias ágeis

Métodos Ágeis, em especial quanto à participação dos clientes, apresentação de resultados ao longo de todo o projeto; e do
à questão da negociação de contratos, ao suporte a equipes de controle para adaptação, permitindo alterações substanciais de
projeto distribuídas e à dependência da organização perante escopo a cada iteração, para atender às mudanças de requisitos
os integrantes da equipe de projeto, podem ser transpostas do negócio (THOMSETT, 2002; UDO; KOPPENSTEINER, 2003;
para o Gerenciamento de Projetos, dados os valores e princí- CHIN, 2004; HIGHSMITH, 2004).
pios comuns. Com relação às áreas de conhecimento, também é possível
Cabe fazer uma ressalva, porém, quanto ao tamanho do traçar um paralelo entre Gerenciamento Clássico de Projetos
projeto. Highsmith (2004, p. 85) afirma que os valores e os e o Gerenciamento Ágil de Projetos, em uma adaptação do
princípios do Gerenciamento Ágil de Projetos são aplicáveis a trabalho de Udo e Koppensteiner (2003, p. 6). A avaliação,
projetos de qualquer envergadura e, similarmente, as práticas apresentada na Tabela 8, aponta que praticamente todas as
podem ser empregadas em projetos de diversos tamanhos, áreas de conhecimento são abordadas pelo Gerenciamento
havendo somente a necessidade de adaptação para equipes Ágil de Projetos, porém com um enfoque diferenciado, dada
com mais de 50 integrantes. sua ênfase na entrega de valor ao cliente, na resposta rápida às
necessidades de mudanças e na valorização do indivíduo.
Comparação: Gerenciamento Clássico e
Gerenciamento Ágil de Projetos Considerações Finais
Para finalizar a explanação sobre o Gerenciamento Ágil de Os projetos de desenvolvimento de software são normal-
Projetos é interessante o estabelecimento de uma comparação mente caracterizados por um elevado grau de incertezas
entre ele e o Gerenciamento Clássico de Projetos. Um possível iniciais e, consequentemente, por uma grande dificuldade de
alinhamento entre os enfoques clássico e ágil de gerenciamen- detalhamento do escopo e de elaboração de um planejamento
to de projetos pode ser feito através da comparação entre as completo. Novos processos de negócio, linguagens de progra-
principais características dos grupos de processos propostos mação, ferramentas, arquiteturas e aplicações inovadoras são
pelo PMI (2004) – Iniciação, Planejamento, Execução, Monitora- constantemente introduzidos. Muitos autores afirmam que
mento e Controle e Encerramento – e as fases do Gerenciamento neste cenário, ciclos rápidos de especificação, teste, validação
Ágil de Projetos – Visão, Especulação, Exploração, Adaptação e e implantação podem produzir resultados mais vantajosos que
Encerramento (HIGHSMITH, 2004). Esta comparação tem por o desenho e o planejamento integral de todo o projeto (AUER;
base o trabalho de Udo e Koppensteiner (2003, p. 3), sendo seu MILLER, 2002; BECK, 2000; BECK; FOWLER, 2001; JEFFRIES
resultado apresentado na Tabela 7. et al, 2001; CHIN, 2004; COCKBURN, 2001; SCHAWABER,
A partir das informações da Tabela 7 acima e do exposto 2002; SCHWABER; BEEDLE 2001; HIGHSMITH, 2002; 2004;
ao longo deste artigo, é possível verificar que as diferenças POPPENDIECK; POPPENDIECK, 2003; AMBLER, 2002a;
fundamentais entre o Gerenciamento Clássico de Projetos e o COHEN et al, 2003; FOWLER, 2003; UDO; KOPPENSTEINER,
Gerenciamento Ágil de Projetos residem fundamentalmente 2003). Várias iterações em curtos períodos de tempo tendem a
em dois pontos: na relação “Planejamento x Especulação” e maximizar o aprendizado da organização e a potencializar o
na dualidade “Monitoramento e controle x Adaptação” (UDO; desenvolvimento da equipe de projeto.
KOPPENSTEINER, 2003; HIGHSMITH, 2004; CHIN, 2004). Cohen et al (2003, p. 46-47) escreve que “[...] indubitavelmente
O Gerenciamento Clássico de Projetos, estruturado se- os Métodos Ágeis vieram para ficar”. Entretanto, estes autores,
gundo uma visão de processos, conforme descrito pelo PMI assim como outros (PAULK, 2001; GLASS, 2001; THOMSETT,
(2004) e, anteriormente, defendido por autores como Verzuh 2002; UDO; KOPPENSTEINER, 2003; HIGHSMITH, 2004) acre-
(1999), Kerzner (2002), Maximiano (2002), Dinsmore e Neto ditam que este novo enfoque não ocupará totalmente o espaço
(2004), entre outros, deposita uma grande importância no dos modelos clássicos de desenvolvimento de software, mas
planejamento detalhado do projeto e nos processos formais de sim que as duas abordagens deverão trabalhar em sintonia
monitoramento e controle. Por outro lado, no Gerenciamento (simbiose) no futuro. Embora alguns praticantes enxerguem
Ágil de Projetos, a ênfase é transferida do planejamento para uma grande distância entre os métodos ágeis e os clássicos,
a execução, visando à entrega rápida de valor ao cliente e à outros acreditam que se pode construir uma ponte entre eles,

Grupo de Processos do Gerenciamento Clássico de Processos Fases do Gerenciamento Ágil de Projetos


Iniciação: Autorização de um novo projeto ou fase e definição do escopo preliminar do projeto Visão: Determinação da visão do produto e do escopo inicial do projeto
Planejamento: Planejamento integral e detalhado do projeto Especulação: Desenvolvimento de um plano inicial do projeto, seguido por planejamentos individuais a cada iteração
Execução: Execução do plano do projeto Exploração: Entrega das funcionalidades / produtos previstos a cada ciclo
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 aos novos requisitos do negócio
Encerramento: Formalização do aceite final do projeto Encerramento: Aceites do cliente a cada ciclo ou iteração e formalização do encerramento do projeto ao final
dos trabalhos
Tabela 7. Alinhamento entre os enfoques ágil e clássico de gerenciamento de projetos (FONTE: ADAPTADO DE KOPPENSTEINER e UDO, 2003, p. 3.)

Edição 20 - Engenharia de Software Magazine 29


Áreas de Conhecimento Gerenciamento Clássico de Projetos Gerenciamento Ágil de Projetos
Gerenciamento da Integração do projeto 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
Gerenciamento do escopo do projeto 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
Gerenciamento de tempo do projeto 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
Gerenciamento de custos do projeto 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
Gerenciamento da qualidade do projeto 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
Gerenciamento de recursos humanos do projeto 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
Gerenciamento das comunicações do projeto 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
Gerenciamento de riscos do 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
Gerenciamento das aquisições do projeto 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
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.)

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

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. ______. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-
133, nov 2001b.
BECK, K. Embrance Change with Extreme Programming. IEEE Computer Magazine, [S.l.], Oct 1999,
p. 70-77. 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
______. Extreme programming explained. Boston: Addison-Wesley, 2000.
The University of Maryland, 2003. Disponível em <http://www.thedacs.com/techs/agile/>.
BECK,Kent.et al.Chrysler goes to“extremes”.Oct,1998.Disponível em <http://www.xprogramming. Acesso em abril, 2005.
com/publications/dc9810cs.pdf>. Acesso em julho, 2005.
COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA executivo. Trad. Afonso Celso da
BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em <http:// Cunha Serra. Rio de Janeiro: Campos, 2002.
www.agilemanifesto.org/>. Acesso em janeiro, 2005.
COHN, Martin. The scrum development process. Disponível em <www.mountaingoatsoftware.
BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001. 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 POPPENDIECK. M. Lean programming. Software Development Magazine. May-June, 2001
criativity. Crosstalk, The Journal of Defense Software Engineering, [S.l.], Nov. 2001. Disponível em <http://www.agilealliance.org/articles/articles/LeanProgramming.htm>. Acesso
em julho, 2005.
HIGHSMITH, Jim. Adaptative management: patterns for the e-business era. Cutter IT Journal, [S.l.],
v. XII, n. 9, sep. 1999. 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
De que se trata o artigo?
Professor Assistente das Faculdades Integradas Este artigo apresenta as principais questões sobre a
Barros Melo e do Grupo Universitário Maurício “Há alguns anos atrás, antes de Bill Gates e seus utilização de Pontos por Função em Ambientes ágeis
de Nassau. Mestre em Engenharia da Compu- amigos fundarem a Microsoft, em 1604 para ser que utilizam a técnica de Pontos por Estória (Story
tação pela Universidade de Pernambuco e Pós preciso, William Shakespeare escreveu o livro Me- Points).
Graduado em Melhoria de Processo de Softwa-
dida por Medida, que retratava o relacionamento
re pela Universidade Federal de Lavras (UFLA).
Graduado em Ciência da Computação pela Uni- entre justiça e misericórdia. O livro apresenta um Para que serve?
versidade Federal de Pernambuco. É Certified conto complicado envolvendo autoridades pom- Mostrar que mesmo tendo o propósito de ser apli-
Scrum-Master (CSM), Certified Product-Owner posas de inflexível certeza moral, de delegação de cada em qualquer ambiente de desenvolvimento e
(CSPO) bem como Implementador do Modelo poderes para indivíduos despreparados com iden-
de Melhoria de Processos do Software Brasileiro
independente de tecnologia, essa técnica pode não
tidades ocultas ou enganosas, abuso dos inocen- se mostrar útil em um ambiente ágil de desenvolvi-
MPS.Br (P2 MPS.Br)
tes, virtudes corrompidas, reputações arruinadas mento, devido a características peculiares da técnica
Cristine Gusmão e, claro, as sempre populares luxúrias e ganância. de Análise de Pontos de Função.
cristine@dsc.upe.br Agora, todos concordam que Shakespeare era um
Professora do Departamento de Sistemas e
Computação da Escola Politécnica da Uni-
gênio, mas como ele pode descrever de forma tão Em que situação o tema é útil?
versidade de Pernambuco (POLI - UPE), onde precisa o ambiente moderno de desenvolvimento A procura pelo conhecimento e aplicação de meto-
leciona várias disciplinas na graduação e de software a quatrocentos anos atrás?” dologias ágeis vem aumentando. Desta forma, este
pós-graduação (especialização e mestrado). artigo tem a finalidade de prover (i) um melhor en-
Coordena o PROMISE Project Management [Brindley 2008] tendimento de como e o que acontece quando se uti-
Improvements in Software Engineering - gru-
liza Análise de Pontos por Função (APF) em ambien-
po de pesquisa na área de Gerenciamento de
Projetos e Engenharia de Software. É coorde- tes ágeis; e (ii) apresentar as principais divergências

C
nadora do Curso de Bacharelado em Sistemas omumente ouvimos falar que al- entre estimativas ágeis e APF.
de Informação das Faculdades Integradas gum projeto foi um sucesso por
Barros Melo. Doutora e Mestre em Ciência da ter sido finalizado “quase” no
Computação pela Universidade Federal de
prazo estipulado ou mesmo ter ultrapas- quais podemos identificar e mensurar,
Pernambuco. Graduada em Engenharia Elé-
trica - Eletrotécnica pela Universidade Federal sado “pouco” o custo original [DeMarco e assim constatar o desempenho posi-
de Pernambuco. Pesquisadora associada do 1982]. Esta visão de sucesso está ligada tivo ou negativo em um determinado
Núcleo de Telesaúde – NUTES – HC – UFPE. diretamente a uma série de fatores os contexto.

Edição 20 - Engenharia de Software Magazine 33


Na Engenharia de Software, podemos afirmar que o surgi- O relatório aponta que ainda em 2006, apenas um terço dos
mento desta preocupação com a obtenção de bons resultados projetos de software foram finalizados com sucesso e, mesmo
se deu a partir da conferência de Engenharia de Software da com a evolução demonstrada desde a sua primeira edição
OTAN, onde se percebeu uma grande quantidade de proble- lançada em 1994, ainda existe uma sensação de atraso nesta
mas existentes no contexto do desenvolvimento do Software busca por resultados consistentes.
àquela época, utilizando-se pela primeira vez o termo Crise Acredita-se que um dos fatores para que a indústria de sof-
do Software [Bemer 1968]. tware venha gradativamente melhorando os seus resultados do
Um pouco mais adiante na linha da história, foi percebida ponto de vista comercial e gerencial é a utilização de métricas
a necessidade de se estabelecer um sistema de medição para [Jones 2008]. Contudo só podemos afirmar com segurança que
prover um mecanismo de quantificação do que acontece no as métricas foram as responsáveis por mostrar o tamanho do
processo de desenvolvimento de software. Esta necessidade foi problema em que a indústria de software se encontra.
formalizada por DeMarco [Demarco 1982] em sua famosa frase:
“Não podemos controlar aquilo que não podemos medir” e até mesmo Evolução dos Métodos de Medição e Estimativa
Edward Deming [Deming 1986] quando o mesmo criou o ditado: A indústria de software está beirando a casa dos 60 anos, no
“Em Deus nós confiamos, para todo o mais, tragam-me dados”. qual os 10 primeiros anos, entre 1947 e 1957, representaram a
Assim como Shakespeare acreditava que deveria existir um fabricação de software muito pequena, raro eram aqueles que
balanceamento entre justiça e misericórdia, somos sabedores ultrapassavam 1000 declarações em seu código fonte. Todos
que projetos de TI devem buscar um equilíbrio entre diver- estes programas eram escritos em linguagens de baixo nível,
sos números observáveis, mensuráveis e sempre conflitantes seja assembly ou linguagem de máquina [Jones 2008].
motivações e influências. Mas a observação mais comum em As primeiras tentativas de se medir produtividade, em cerca
ambientes de TI é culpar as métricas ou estremecer diante da de 1950, utilizou a métrica conhecida como linha de código.
possibilidade de ser medido, e às vezes julgados, o que não A técnica, como mostra seu intuitivo nome, era baseada em
muda os resultados desastrosos que acontecem em empresas contar a quantidade de linhas de código de um sistema, e assim
de TI [Brindley 2008]. surgia a primeira métrica de qualidade chamada de Defeitos
Por exemplo, os resultados divulgados pelo Standish Group e por Mil Linhas de Código, que mostravam quantos defeitos
os relatórios conhecidos como “Chaos Report” que mostraram (bugs) um sistema possuía a cada mil linhas de código. Hoje
que quase 30 anos depois da Conferência da OTAN, os resul- esse tipo de métrica é chamada pelo nome de Densidade de
tados da indústria de software ainda não são considerados Defeitos [Jones 2008].
um sucesso. Naquela época, codificar demorava 50% do tempo de cons-
A Figura 1 mostra a evolução dos indicadores de sucesso trução do software, enquanto testar e depurar levava a outros
de projetos de acordo com o “Chaos Report”, onde Sucesso são 40% enquanto o restante das atividades consumia 10% do
aqueles projetos que foram terminados sem estouro de custo, desenvolvimento de software. Contudo, entre 1957 e 1967 esta
prazo e com todos os requisitos desenvolvidos, Desafiados são situação mudou drasticamente com a chegada das linguagens
aqueles onde o custo foi maior do que se previa, ou aqueles de programação de alto nível que eram mais poderosas que as
que foram entregues após o prazo, ou se entregou com menos linguagens de programação assembly [Jones 2008].
requisitos do que o desejado, enquanto projetos cancelados Então, linguagens como Fortran, COBOL e APL começaram a
(Falha) são aqueles finalizados antes da sua conclusão (abor- gerar aplicações comerciais e bancárias que facilmente chega-
tados ou nunca utilizados). 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
Figura 1. Resultados dos Projetos de Software de Acordo com Chaos Report assim nasceu a técnica conhecida como Pontos de Função.

34 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes


metodologias ágeis

Análise de Pontos de Função é uma unidade de media que expressa o valor de negócio
Após o esforço de muitos anos, Albretch e seus colegas que uma funcionalidade de um sistema traz ao usuário.
apresentaram à IBM um novo tipo de métrica conhecida como Isso significa que se o cliente deseja realizar um cadastro que,
Pontos de Função. Essa métrica é baseada em cinco aspectos ao final, envia um email de confirmação ao usuário. Enquanto
do desenvolvimento de software que são: Entradas, Saídas, nós programadores consideraríamos duas funcionalidades (ca-
Requisições, Arquivos Lógicos e Interfaces [Jones 2008]. dastrar e enviar email) o método considera que o enviar email
Após sua utilização por muitos anos na IBM, pontos de função é um processamento a mais na funcionalidade de cadastro, não
foi discutido em público pela primeira vez em um trabalho de podendo ser contado em separado.
Albretch apresentado na Conferência SHARE/GUIDE/IBM na Então, se mensurar o software de forma funcional está ligado
Califórnia, em 1979. diretamente à medição de requisitos funcionais do software,
Essa técnica mede o tamanho funcional do software quan- sendo este do ponto de vista do cliente, Pontos de Função ca-
tificando as funcionalidades do ponto de vista do usuário, tegoriza esses requisitos do usuário em cinco tipos:
baseado apenas no projeto lógico e especificação funcional, • Arquivos Lógicos Internos;
sendo seus principais objetivos [Albretch 1979]: • Arquivos de Interface Externa;
• Medir a “quantidade” de funcionalidade que o usuário • Entradas Externas;
requer e recebe; • Consultas Externas;
• Medir o tamanho do desenvolvimento de software e da • Saídas Externas.
manutenção de forma independente de tecnologia usada para
o desenvolvimento; Cada uma dessas categorias possui seus critérios objetivos
• Prover uma unidade de medição normalizada entre projetos de adequação para saber como um requisito ou funcionalidade
e organizações. se encaixa em uma delas.
Após descobrir sua categoria, é necessário identificar a sua
Em 1983, a associação comercial de clientes da IBM (GUI- complexidade. Para tal, também são usados um conjunto
DE) estabeleceu um grupo de trabalho em pontos de função, de regras objetivas que indica o quão complexa é uma fun-
mas apenas em 1986 se verificou a existência da massa crítica cionalidade. Para todas as categorias existem três níveis de
de utilizadores da técnica, de tal forma que foi decidido criar complexidade: Alta, Média e Baixa.
uma organização sem fins lucrativos voltada exclusivamente Então, cada um desses requisitos é mapeado com uma fun-
para a utilização de pontos de função, e a propagação dos ção de negócio do usuário e segue os critérios para apontar
resultados obtidos com os estudos realizados nesta época. em qual categoria ele se ajusta. Após isso a complexidade é
Esta nova organização foi chamada de International Func- determinada de forma objetiva. A identificação da categoria
tion Point User Group (IFPUG). Essa organização foi originada e complexidade de um requisito determina o seu tamanho
em Toronto e hoje se encontra nos Estados Unidos contendo através de uma pontuação [Albretch 1979].
pouco mais de 3000 afiliados de vinte países diferentes. Após a definição da categoria e complexidade de todos os ele-
O IFPUG atualiza de tempos em tempos o guia para con- mentos do sistema, é obtida a pontuação total do mesmo, sendo
tagem chamado de Manual de Práticas de Contagem (CPM), essa pontuação conhecida como Pontuação Não Ajustada, pois
que hoje está na versão 4.2.1. Vale ressaltar que, para o o sistema como um todo, sofrerá um ajuste na sua pontuação
IFPUG, toda padronização da contagem deve ser indicada de acordo com os requisitos não funcionais do sistema.
pela versão do manual. Esse ajuste baseado nos requisitos não funcionais é conheci-
Devido à alta aceitação e padronização do método, o mes- do na técnica como Fatores de Ajuste. Esses fatores de ajuste
mo se tornou uma norma ISO (ISO 20926) no ano 2000. E, incidem na pontuação do sistema inteiro como um peso que
como sua validação trata apenas dos requisitos funcionais, pode variar de 0,65 até 1,35. Assim, de acordo com as restri-
a técnica é explicita em afirmar que ela mede o tamanho ções do sistema, a pontuação final, chamada de Pontuação
funcional do código, e requisitos não funcionais não inter- Ajustada, pode ser jogada para cima ou para baixo em relação
ferem na contagem [Jones 2008]. à pontuação original.
Desta forma podemos comparar o ponto de função com Dessa forma, Pontos de Função se torna uma métrica padroni-
a unidade de medida metro quadrado: o metro quadrado zada, devido ao seu método objetivo de encontrar a pontuação
é uma unidade padrão que é igual em todo o mundo, mas de um elemento, podendo servir de base comparativa entre
construir um castelo de dez mil metros quadrados na pla- projetos diferentes e até mesmo equipes diferentes, sendo ela
nície é diferente do que construir este mesmo castelo em classificada hoje como métrica para definição de “Tamanho”
montanhas irregulares. Esta diferença do tipo do terreno do software.
equivale aos requisitos não funcionais no desenvolvimento Esta técnica, embora largamente utilizada, possui ainda
de software. algumas lacunas que o manual de contagens não cobre como,
Outro fator a ser considerado, é que a pontuação de uma por exemplo: como contar uma animação em Flash ou como
determinada funcionalidade é dada pelo ponto de vista do contar algoritmos complexos que estão embutidos dentro de
cliente, e não do desenvolvedor, ou seja, um ponto de função outras funcionalidades?

Edição 20 - Engenharia de Software Magazine 35


Medições em Ambientes Ágeis Mesmo sabendo que esse ambiente ideal de trabalho não exis-
Já as metodologias ágeis foram formalizadas em 17 de feve- te, ele pode ser imaginado como base para estimar o tamanho
reiro de 2001, por 17 líderes de desenvolvimento que utiliza- e esforço necessário para o desenvolvimento das funcionalida-
vam metodologias que, até aquele momento, eram conhecidas des de um projeto. Como não é possível identificar com exati-
como metodologias “leves” [Koch 2005]. Essas metodologias dão qual a quantidade de tempo útil a equipe terá durante os
surgiram como descobertas de praticantes que mudavam o trabalhos, propõe-se trabalhar com a idéia de que todo tempo
foco do desenvolvimento baseado engenharia de software de trabalho deve ser considerado útil, utilizando-se assim o
tradicional orientada a processo por uma abordagem mais termo “ideal” para representar o máximo de produtividade.
orientada a pessoas [Boehm & Turner 2004]. Normalmente trabalha-se com duas unidades de “tempos
Então podemos ver que esse novo conceito baseado em ideais” nas estimativas:
resposta rápida a mudanças e pouca documentação seguia Dia ideal: um dia ideal é aquele onde, por exemplo, um
um caminho antagônico ao pregado pela visão orientada a programador produz oito horas ininterruptas de código útil.
planejamento oferecida pelos modelos tradicionais. Schuh Dizemos que uma estória demoraria um dia ideal para ser
define Metodologias Ágeis como um contra movimento desenvolvida quando estimamos em oito horas produtivas de
para trinta anos de crescente uso de processos burocráticos trabalho para que essa estória seja finalizada.
significando a remodelagem da programação dentro da En- Semana ideal: uma semana ideal é aquela onde as quarenta
genharia de Software. horas de trabalho desta semana são totalmente produtivas.
Já Mnkandla & Dwolatzky (2004) afirmam que o Movimento Quando se estima o esforço de uma funcionalidade como
Ágil marcou o surgimento de uma nova disciplina de enge- sendo o de uma semana ideal de trabalho significa dizer que
nharia que modificava os valores do processo de desenvol- quarenta horas produtivas serão suficientes para finalizar o
vimento de software do mecânico (orientado a processos e desenvolvimento desta funcionalidade.
utilizando regras da ciência) para o orgânico (dirigido por
questões sobre pessoas e suas interações). Isso implicava Por se tratar estimativa de esforço, e não de tamanho, esta
um desafio complexo para a Engenharia de Software e para técnica de estimativa será desconsiderada na comparação com
sistemas em ambientes de trabalho que são dinâmicos e a análise de pontos de função.
imprevisíveis.
Diante de tal quebra de paradigma, se fez necessária a Horas por Par
criação de novos métodos de estimativas de “tamanho” de Na segunda edição do livro Extreme Programming Explained
software para este tipo de abordagem, devido ao seu foco em [Beck 2004], Kent Beck sugeriu uma unidade de medida efi-
entregar software de valor ao cliente em detrimento de outras ciente para projetos de iterações muito curtas, XP nesta edição
atividades mais complexas e que tragam menos retorno ao sugeria iterações de uma semana. Esta nova unidade de medida
cliente [Cohn 2007]. representava a quantidade de horas que um par de programa-
Boehm & Turner (2004) afirmam que estimativas em projetos dores conseguiria desenvolver aquela funcionalidade.
que usam métodos ágeis são feitas de maneira diferente das Essa unidade de medida se mostra simples e intuitiva, uma
realizadas em projetos tradicionais por suas características vez que era mais fácil imaginar a quantidade de trabalho re-
diferenciadas, como rápido feedback e iterações curtas. Desta alizada em uma semana e o esforço necessário para concluir
forma, projetos que utilizam abordagens ágeis podem não se as tarefas.
adequar facilmente às técnicas e métodos mais conhecidos Esta medição não chegou a ser largamente implementada, e
de estimativa de esforço. por ser uma estimativa de esforço e não de tamanho, também
As estimativas de tamanho utilizadas nas abordagens ágeis será desconsiderada daqui em diante.
são de cunho subjetivo onde se leva em conta a experiência
do time de desenvolvimento e da “métrica” base que pode Pontos por Estória
ser variável entre times diferentes. As métricas mais comuns Neste contexto, o método de medição de tamanho mais di-
nas abordagens ágeis são [Beck 2000, Beck & Fowler 2000, fundido é a estimativa conhecida como Pontos por Estória (SP)
Beck 2004]: [Cohn 2005]. O Ponto por Estória segue o mesmo princípio da
• Ideal Days (Dias Ideais) APF, ambos determinam valor de negócio de uma funciona-
• Pair Hours (Horas por Par) lidade porém, SP considera esse valor baseado na experiência
• Story Points (Pontos por Estória) subjetiva do time, enquanto Pontos de Função mede elementos
de negócios que são padronizados de forma a não considerar
Dias Ideais nenhum elemento subjetivo.
Quanto tempo o desenvolvedor demoraria a finalizar uma Ponto por Estória é uma unidade de medida que aufere a
funcionalidade, se: complexidade de uma estória ou requisitos, e representa o
• Não houvesse interrupções; quão difícil é desenvolver aquele requisito. Neste caso, um
• Todo o necessário estivesse disponível; ponto é baseado na experiência da equipe, podendo variar de
• O tempo inteiro dele estivesse todo alocado para isto. um time para outro [Cauwenberghe 2005].

36 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes


metodologias ágeis

Percebemos que os pontos, como são chamados, são normal- Podemos citar inicialmente o trabalho de Fuqua (2003). Aqui
mente aplicados de forma relativa e, por esse comportamento o autor realizou um estudo da inserção de Metodologias Ágeis
relativo, possuem valores diferentes entre equipes diferentes que e o uso de Story Points em projetos que utilizavam Pontos de
utilizam XP, ou seja, um “ponto” pode valer 8 horas de desen- Função como técnica de medição.
volvimento em uma equipe A ou 40 horas de desenvolvimento Ele encontrou uma forte resistência em unificar os dois mé-
em uma equipe B. Esse valor pode ser uma política da própria todos uma vez que, enquanto Pontos de Função era apegado
equipe ou pode ser determinado para cada projeto, baseado em apenas às questões funcionais, em Story Points aspectos não
comparação, como demonstrado abaixo [Cauwenberghe 2005]: funcionais eram determinantes na estimativa ideal do tama-
Extreme Programming [Beck & Fowler 2000] define aquilo que nho. Assim, ele encontrou um conflito de objetivos nos dois
conhecemos como User Stories, ou Requisitos do Usuário. Na métodos, desaconselhando sua utilização em conjunto.
prática essas “estórias” são estimadas em pontos por estória, onde Em outro texto sobre o assunto, Caper Jones (2008) afirma
1 ponto é o valor definido pela política da equipe, ou alcançado que, de acordo com sua base empírica, é notado que dois
por comparação. Pontos de Função equivalem em média a um Story Point. Mas
Normalmente se sugere que, na primeira iteração, as estórias vale ressaltar que essa medida é uma média empírica de sua
sejam classificadas de acordo com sua complexidade. Atribua 1 base de dados.
ponto a de menor complexidade e 5 pontos a de maior e defina Uma vez que a quantidade de trabalhos acadêmicos na área se
valores intermediários para as outras estórias. mostrarem insuficientes para formar uma opinião a respeito do
Estime estas estórias restantes de acordo com as estórias já que acontece quando ambas as abordagens estão em conjunto,
estimadas. Por exemplo, se uma estória é 2 vezes mais complexa foi necessário recorrer à indústria para buscar novas evidências
do que outra, ela vale o dobro de pontos da anterior. Essa com- do que acontece nesse tipo de ambiente.
paração de estórias é conhecida como uma técnica chamada de Assim, todas as conclusões listadas daqui para frente foram
triangulação [Cauwenberghe, 2005]. cedidas pela autarquia pública Agência Estadual de Tecno-
Para definir a duração de cada estória é necessário identificar a logia da Informação (ATI) do Estado de Pernambuco (www.
produtividade de cada desenvolvedor. Sempre que uma estória ati.pe.gov.br) que está utilizando Scrum em alguns de seus
for estimada por algum desenvolvedor, deve-se multiplicar pelo projetos, bem como Pontos de Função.
seu fator de carga que inicialmente deve ser considerado com o Inicialmente a ATI considera que as técnicas de Pontos de
valor 1. Função e Pontos por Estória têm o mesmo propósito dentro
Normalmente esse fator de carga vai caindo (para números da organização, que é mensurar o valor de negócio agregado
reais como, por exemplo 0,850), o que significa que a velocidade de uma funcionalidade/sistema. Então, a ATI está tentando
do programador é de 0,85 pontos por dia. definir um relacionamento entre Pontos de Função e Pontos
Outro conceito importante para estimativas é o Yesterday Weather por Estória baseado em sua base histórica, que possui pouco
[Beck, 2000] que propõe estimar a velocidade da equipe na pró- mais de um ano de informações.
xima iteração baseado no que foi feito anteriormente. Na prática, Contudo, as informações se mostram divergentes tanto em
Yesterday Weather indica que, para calcular o número de pontos valores absolutos, ou seja, a conta de quantos Pontos de Função
que cada desenvolvedor irá fazer na próxima iteração, basta olhar vale um Ponto por Estória, e na evolução dos indicadores, ou
para o número de pontos que ele fez na ultima iteração e repetir seja, normalmente há uma tendência inversa de crescimento
esse número. entre esses dois indicadores.
Como podemos perceber, o método é totalmente subjetivo, A principal razão encontrada pela ATI é que Ponto de Função
pois primeiro a equipe precisa definir o que é um ponto, e difere de Ponto por Estória de forma perceptível nos seguintes
essa definição não é baseada em critérios objetivos. Contudo, tópicos elencados abaixo.
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 Funcionalidades em Ponto de Função sempre são analisadas
feito [Cohn 2004]. do ponto de vista do cliente
Se, por um lado, temos uma maneira padronizada para es- Apesar da técnica Pontos por Estória também considerar as
timar o tamanho funcional de um software e, do outro lado, estórias do usuário como requisitos, ela incentiva que estas
temos uma maneira totalmente subjetiva para atingir o mesmo estórias sejam quebradas em estórias menores quando estas
objetivo, temos um problema por não existir qualquer evidência sejam muito grandes. Por exemplo, no seguinte requisito:
prática que ambas podem ou não co-existir dentro de um mesmo - Para o cadastro de um usuário será necessário informar os
ambiente. campos, CPF, nome completo, login e senha. O usuário só será
cadastrado se o seu CPF não apresentar problemas na Polícia
Utilizando Story Points e Pontos de Função no (nada consta), após o seu cadastro o usuário deve receber um
mesmo ambiente email.
Não existem muitos trabalhos publicados com evidências
científicas a respeito da Análise de Pontos por Função em Em Pontos por Estória o time seria incentivado a quebrar a
Metodologias Ágeis. 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; pontuação ajustada será aproximadamente 30% maior do
2. Cadastrar usuário; que na não ajustada.
3. Enviar email ao usuário. Na prática, percebemos que o sistema no cenário (B) é um
sistema totalmente diferente, do ponto de vista técnico, em
Ponto de Função considera a finalidade da ação (Cadas- relação ao sistema do cenário (A), e sua pontuação final
trar o usuário), sendo que esta possui uma validação (nada será ajustada em no máximo 40%, ou seja, se o sistema em
consta) e um processamento (email), mas veja que ainda (A) chegar aos 60 pontos, em B ele chegará ao máximo de
continua sendo apenas uma funcionalidade. 85 pontos.
Então requisitos muito grandes, se tornam muitas estó- Quando tratamos o mesmo problema em Pontos por Estória
rias enquanto nem sempre se tornarão muitos elementos vemos que o tamanho do sistema pode dobrar ou até mesmo
considerados em Ponto de Função, sendo este o fator que triplicar, uma vez que a complexidade do sistema em (B) é
mais estimula divergências entre as técnicas. muito maior do que em (A). Então, a questão dos requisitos
não funcionais do sistema pode, em determinado momento,
Ponto de Função só considera requisitos funcionais nos trazer uma variação disforme nas duas abordagens, dificul-
fatores de ajuste tando a identificação de um comportamento comum.
Como foi mostrado anteriormente, Ponto de Função serve Atente-se para o fato de que neste caso Pontos por Estória
para contar o tamanho funcional de um determinado re- se aproxima mais da pontuação ajustada.
quisito do sistema. Se este requisito é construído de forma No segundo caso de desvio a ser observado, podemos
simplória, ou de forma extremamente complexa, a sua considerar um sistema similar mostrado no cenário ante-
pontuação, na maioria dos casos, será a mesma, ou sofrerá rior, mas que, ao invés de duas entidades (Usuários e Do-
pequenas variações. Essa diferença será corrigida ao final cumentos), apresente 10 entidades e que possua a mesma
da contagem e este ajuste considerará todo o sistema, e não funcionalidade de vincular um usuário a um documento
apenas a funcionalidade medida. apresentada.
Em Pontos por Estória temos que cada requisito é avaliado Contudo, especificamente para esse caso, apenas essa
de acordo com o seu tamanho, ou seja, quanto trabalho funcionalidade (vincular documento a um usuário) terá
aquele requisito representa dentro do desenvolvimento, restrições de desempenho, usabilidade, ajuda on-line, con-
mas também é avaliado de acordo com a complexidade corrência, segurança, utilização de certificação digital e
das tarefas envolvidas. envio de email de confirmação.
Esse tipo de diferença de visão leva a vários problemas Nesse caso, os Pontos de Função não ajustados só apre-
na obtenção de uma função de conversão entre ambas as sentam um prejuízo, podendo este ser muito grande, na
abordagens. A seguir serão mostrados dois casos onde as contagem da funcionalidade de vinculação do documento
diferenças ficam latentes. a um usuário.
Para ilustrar o problema, vamos imaginar um sistema Quando se usa os fatores de ajuste, temos um prejuízo para
de cadastro simples, onde serão cadastrados usuários e o comprador, pois o fator de ajuste foi utilizado no sistema
documentos bem como todas as operações de manutenção inteiro. Pelo que vemos nesse caso, são quarenta funcionali-
dessas entidades (Consultar, Remover, Atualizar), e uma dades de cadastro (Cadastrar, Alterar, Consultar, Remover)
funcionalidade para ligar um usuário a um documento. de dez entidades diferentes que também são ajustadas, na
O cenário de uso (A) desse sistema solicita a construção mesma medida da funcionalidade de vinculação, embora
do mesmo em páginas web, sem restrições de desempenho, não se utilizem de nenhuma das restrições impostas naquela
confiabilidade e usabilidade. Enquanto no Cenário (B), funcionalidade.
além de todo o desejado em (A), existe a restrição operacio- O Ponto por Estória funcionará da mesma forma do que
nal para que sistema garanta até 100 acessos simultâneos, no exemplo anterior, atribuindo pontuações simples às
com requisitos de acessibilidade (para deficientes visuais) funcionalidades de cadastro e a pontuação maior para a
e internacionalização do site, com um menu de ajuda, e vinculação. Mas ainda difere da pontuação não ajustada, e
que o sistema deve ser 24X7 com uma disponibilidade de difere ainda mais da pontuação ajustada.
99,999% do tempo, e cada vez que um usuário é ligado a Nesse caso específico, o Ponto por Estória tende a se
um documento, este tem que sofrer um processo de au- aproximar do fator não ajustado, o que difere do exemplo
tenticação via certificação digital. anterior. Um problema é quando se aproximar de uma
Estes dois cenários (A e B), no ponto de vista da técnica pontuação ou de outra.
de Pontos de Função, terão uma diferença pequena na
pontuação final, quando considerados os pontos não Mudanças
ajustados. Mudanças trazem uma nova dificuldade quando se tenta
Ao se considerar os fatores de ajuste, vemos que a estabelecer uma relação entre Ponto de Função e Ponto por
pontuação ajustada no cenário (A) fica muito parecida Estória. Em Ponto de Função, uma alteração realizada no
com a pontuação não ajustada, enquanto no cenário (B) a sistema é tratada como uma contagem de manutenção que

38 Engenharia de Software Magazine - Uso de Análise de Pontos de Função em Ambientes


metodologias ágeis

hoje sabemos funcionar bem para manutenções evolu- Assim, a única forma de realizar os mapeamentos é, a
tivas do sistema, sendo não aconselhado o seu uso em cada iteração, fazer um mapeamento direto da quantida-
manutenções corretivas. de de Pontos de Função versus Pontos por Estória, após
A questão nesse ponto é que neste tipo de contagem é o término da iteração. Isto dificulta, principalmente no
considerado no cálculo da pontuação todas as inclusões, começo, a utilização dos fatores de ajuste, uma vez que
alterações e conversões necessárias para que a nova restrições podem ser verificadas durante o desenvolvi-
funcionalidade do sistema fique disponível ao cliente. mento do sistema.
Contudo, é considerada também toda parte do sistema
que precise ser excluída do mesmo, e esta deve ser con- Subjetividade da técnica de Ponto por Estória e
tabilizada no resultado final do sistema. Experiência da Equipe
Então se, em uma nova funcionalidade desejada para um Vimos que o Ponto de Função, mesmo com algumas par-
determinado sistema é necessário criar uma entidade A, ticularidades, é calculado de forma objetiva e sem espaço
modificar um tipo de dado de Inteiro para Real em uma pra ambiguidades. Mas, o Ponto por Estória tende a variar
entidade B, ou excluir uma entidade C do sistema, serão durante o desenvolvimento, uma vez que ele depende
contadas na manutenção como se estas entidades A, B e C primeiro daquilo que a equipe definiu o que é um ponto,
tivessem sido criadas por completo neste momento. e segundo, que o total de pontos de uma estória pode ser
Esse fator é agravado se ainda for considerada a criação, mal interpretado por uma equipe, se tornando assim mais
alteração e exclusão das funcionalidades referentes a essas susceptível a variações entre as diversas iterações.
entidades. Por isso que há casos que é melhor para quem
compra em Ponto de Função solicitar que uma funcionali- Conclusão
dade seja desenvolvida por completo, do que alterar uma Vimos que as técnicas Pontos de Função e Pontos por
funcionalidade parecida existente. Estória possuem o mesmo objetivo comum de medir a
Este fator não é considerado em Ponto por Estória, pois quantidade de valor de negócio agregado ao sistema ou a
a técnica considera apenas o tempo e a complexidade de pedaços dele. Contudo, a diferença de cultura que envolve
ajustar a funcionalidade desejada. Pode acontecer tam- estas abordagens as torna duas formas diferentes para
bém, como já falamos anteriormente, que a técnica incenti- avaliar o mesmo indicador dentro do desenvolvimento
va a quebra de estórias grandes em estórias menores, que de software.
estórias de manutenção sejam quebradas tornando mais Nem na literatura nem na organização pesquisada se
difícil o mapeamento entre Pontos de Função e Pontos por encontrou uma forma de conversão entre as unidades,
Estória. Esse tipo de dificuldade acontece em larga escala nem sequer um comportamento comum entre variação
em projetos ágeis que incentivam mudanças. da pontuação entre as mesmas ao longo das iterações que
se seguem no projeto.
Lacunas do Manual de Contagens de Práticas É verificado que o Ponto de Função se aproxima mais da
Outra dificuldade encontrada neste contexto, e que pode realidade financeira dos projetos, se tornando uma métri-
ser considerada relevante, é que o Manual de Contagem ca eficiente para controle de custos e produtividade dos
de Práticas fornecido pelo IFPUG não provê uma maneira times. No caso da ATI, o Ponto de Função deveria servir
de contar todas as nuances existentes no desenvolvimento como uma régua, para medir a variação do tamanho do
de software, principalmente no tocante a requisitos não Ponto por Estória, mas nenhum comportamento comum
funcionais. entre as duas pontuações ainda foi identificado.
Aspectos como Data Warehouse, Internacionalização, Já o Ponto por Estória se mostra uma técnica mais efi-
Animações em Flash, Efeitos Sonoros, Sistema de Ajuda ciente no acompanhamento do projeto e na estimativa
On-Line, Criação de Interfaces, Relatórios disponíveis em de tempo e tamanho das estórias, uma vez que a equipe
mais de um formato de arquivo e Manutenção Corretiva sempre tem uma experiência maior em relação aos prazos
são recomendados em Whitepapers do IFPUG, mas não e à quantidade de trabalho possível em cada estória.
há uma opinião consolidada sobre como contar essas
particularidades.

Pontuação com a soma das partes não é a mesma da Feedback


pontuação final de um sistema em Ponto de Função Dê seu feedback sobre esta edição! eu
s

Em Ponto de Função, a soma das partes do sistema tem, A Engenharia de Software Magazine
sobre e

normalmente, uma pontuação maior do que a contagem tem que ser feita ao seu gosto.
s

ta
do sistema inteiro. Assim, não se pode comparar o total
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
de Pontos por Estórias realizados durante a concepção Dê seu voto sobre este artigo, através do link:
inteira de um sistema e compará-lo com a pontuação final
www.devmedia.com.br/esmag/feedback
em Pontos de Função.

Edição 20 - Engenharia de Software Magazine 39


Referências

[Albretch 1979] Albrecht, A. J. (1979) Measuring Application Development Productivity. In Proc. [Cohn 2004] Cohn, M. (2004) User Stories Applied: For Agile Software Development, Boston:
IBM Applications Development Symposium. GUIDE Int and Share Inc., IBM Corp., Monterey, pp. 83. Addison-Wesley.

[Beck 2000] Beck, K. (2000) Extreme Programming Explained: Embrace Change. Addison Wesley,
[Cohn 2005] Cohn, M (2005) Agile Estimating and Planning, Addison-Wesley.
Reading.
[DeMarco 1982] DeMarco, T. (1982) Controlling Software Projects, Prentice Hall.
[Beck 2004] Beck, K. (2004) Extreme Programming Explained Second Edition. Addison Wesley, Reading.
[Deming 1986] Deming, W. (1986) Out of the Crisis, The MIT Press.
[Beck & Fowler 2000] Beck, K., Fowler, M. (2000) Extreme Programming Planned. Addison Wesley,
Reading. [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.
[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 [Jones 2008] Jones, C. (2008) Applied Software Measurement, MCGraw Hill.

COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels, [Koch 2005] Koch, A. S. (2005) Agile Software Development - Evaluating the Methods for Your
Belgium, pp. 165-181. Organization. Artech House, Boston.

[Boehm & Turner 2004] Boehm, B,.Turner, R. (2004) Balancing agility and discipline: A guide for the [Schuh 2004] Schuh, P. (2004) Integrating agile development in the real world (pp. 1-6). MA:
perplexed 1° ed. Addison Wesley, pp. 165-194. Charles River Media.

[Brindley 2008] Brindley, D. (2008) Foreword. In C. Jones, Software Applied Measurement, Mcgraw [Mnkandla & Dwolattzy 2004] Mnkandla, E., Dwolatzky, B. (2004) Balancing the human and the
Hill, Pp. XVIII. engineering factors in software development. Proceedings of the IEEE AFRICON 2004 Conference
(pp. 1207-1210).
[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


Introdução ao Mantis
Gestão da Manutenção e Configuração de Software através do controle de
mudanças

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.
Renato de Freitas Matos
redematos@hotmail.com Para que serve?
Atualmente é aluno do Curso Superior de Tecno-
O artigo demonstra como as mudanças em
logia em Análise e Desenvolvimento de Sistemas
no Centro de Ensino Superior de Valença (CESVA) software podem ser identificadas, controladas
– Fundação Educacional D. André Arcoverde. Pro- e visualizadas com o uso de aplicações como o
fessor de WebDesign e Programação em cursos Mantis. O Mantis é uma aplicação gratuita para
profissionalizantes. Desenvolve aplicações em Java ser executada no ambiente Web. Tal ferramenta
utilizando o banco de dados PostgreSQL, possui
implementa os conceitos da gestão de configu-
interesse em Engenharia de Software, Banco de
Dados e desenvolvimento de sistemas em Java. ração de software, fornecendo diversos recursos,
como registro e histórico das mudanças durante
Letícia Dias da Silva Evaldo de Oliveira da Silva
a manutenção de software.
let-ds@hotmail.com evaldo@cesjf.br
Atualmente é aluna do Curso Superior de Tecno- Mestre e especialista em Ciência da Computação
logia em Análise e Desenvolvimento de Sistemas pela Universidade Federal de Viçosa. Coordenador Em que situação o tema é útil?
no Centro de Ensino Superior de Valença (CESVA) do Setor de Tecnologia da Informação da Academia Identificação, controle e visualização de
– Fundação Educacional D André Arcoverde. Atua - Colégio Cristo Redentor e do Centro de Ensino Su- mudanças no contexto da manutenção
na área de desenvolvimento de sistemas em Vi- perior de Juiz de Fora (CES/JF). Atua também como e configuração de software, utilizando
sual Basic, com experiência em Bancos de Dados professor do curso de Bacharelado em Sistemas de
ferramentas de apoio para gestão destas
Firebird, PostgreSQL e Access. Tem como foco de Informação e dos cursos de Especialização em Com-
putação do CES/JF, e no Curso Superior de Tecnolo- atividades.
interesse o aprimoramento da linguagem SQL e
aplicações Java, além dos princípios de Qualidade gia em Análise e Desenvolvimento de Sistemas da
e Manutenção de Software. Fundação Educacional D. André Arcoverde (FAA).

Edição 20 - Engenharia de Software Magazine 41


A manutenção de software é a fase do ciclo de vida de desen- Existem outros problemas relacionados à manutenção de
volvimento durante a qual ocorrem modificações no código software como, por exemplo, problemas culturais, ou seja, a
e em qualquer outro artefato de uma aplicação de software, maioria dos profissionais é formada com uma visão essen-
a fim de mantê-lo disponível e em constante evolução. A cialmente focada no desenvolvimento de novas aplicações.
manutenção é executada para corrigir falhas na codificação, Esta afirmação pode ser constatada pelo fato dos modelos de
melhorar o desempenho do software, ou adequá-lo aos novos manutenção não serem, nem tão bem desenvolvidos, nem tão
requisitos conforme as necessidades dos seus usuários (DIAS bem compreendidos como os modelos de desenvolvimento de
e ANQUETIL, 2005). software. Tal atividade também é reconhecida por sua impor-
Desde o início da década de 90, a manutenção de software já tância, até mesmo como disciplina em cursos de graduação e
era considerada como uma atividade consumidora de grande pós-graduação, mas recebe relativamente pouca atenção na
parte dos recursos financeiros, humanos e tecnológicos, dentro literatura técnica, onde novos processos são propostos para
das organizações produtoras de software. A literatura mais melhorar o desenvolvimento de um software novo. É possí-
atual sobre Engenharia de Software (ES) apresenta estudos vel citar os processos iterativos baseados no paradigma da
que esta fase representa cerca de 80% do orçamento total do orientação a objetos, e que muitas vezes pretendem resolver as
ciclo de vida de um software. Portanto, é considerada uma ati- dificuldades da manutenção tratando-a apenas como mais uma
vidade economicamente estratégica durante a vida de qualquer iteração. No entanto, estes novos processos não se aplicam em
software (PRESSMAN, 2006). sistemas legados, desenvolvidos com métodos ou tecnologias
Além desses dados, Dias e Anquetil (2005) enfatizam que ultrapassadas como, por exemplo, sistemas escritos em COBOL
existe um preconceito em relação à atividade de manutenção (JACOBSON, 1999; SOMMERVILLE, 2003; DIAS e ANQUETIL,
de software, pois não deve ser simplesmente considerada 2005; PRESSMAN, 2006).
como uma atividade de correção do código de uma aplicação. Diante dessa discussão, a manutenção de software deve
Pesquisas mostram que apenas 20% dos projetos de manu- ser tratada como uma disciplina, onde os profissionais de
tenção são de correção de erros, e que a grande maioria do TI (Tecnologia da Informação) estarão mais preparados para
trabalho consiste em acrescentar novas funcionalidades a um conhecer a realidade do mercado, tendo conhecimento das
sistema existente, ou adaptá-lo a mudanças externas. Pode-se principais áreas de estudo da manutenção de software como,
considerar, diante destes percentuais, que a manutenção de por exemplo, a configuração de software, engenharia reversa,
software é uma atividade imprescindível, e sem a qual os redocumentação e modelos de gestão para controle de mudan-
sistemas existentes rapidamente se tornariam antiquados em ças. Tais áreas devem ser conhecidas e exploradas como forma
relação ao mundo real. Deste modo, a manutenção de software de amadurecer o processo de manutenção, obtendo o controle
permite que o software evolua, para continuar representando da evolução do software.
fielmente a realidade que eles automatizam. Com base no relato desta seção e na importância da manu-
Pressman (2006) discute que um dos grandes problemas na tenção como fase crítica do processo de desenvolvimento, as
manutenção de software é a alta rotatividade da equipe de próximas seções abordam o conceito de gerência da configura-
desenvolvimento. Ou seja, é provável que a equipe ou pessoa ção e suas principais atividades dentro da manutenção de sof-
que fez o trabalho original não seja mais um desenvolvedor tware. Em seguida, este artigo apresenta a ferramenta Mantis
naquele projeto. Ou várias gerações subsequentes de profis- utilizada por gerentes de configuração e desenvolvedores de
sionais modificaram a aplicação e não fazem mais parte da software no controle e acompanhamento de requisições das
equipe. Diante destes problemas, é importante destacar que mudanças em software.
modificar um software é inevitável, sendo necessário desen-
volver mecanismos para avaliar, controlar, registrar e rastrear Gerência de Configuração de Software
tais modificações. Configuração de um sistema de software é uma coleção de
Outros problemas técnicos e gerenciais podem ser relacio- versões específicas de itens de configuração (hardware, firmware
nados: a complexidade do domínio do problema; obstáculos ou software) que são combinados de acordo com procedimen-
para gerenciar e estabelecer um processo de desenvolvimento tos específicos de construção para servir a uma finalidade
e manutenção; tecnologias ultrapassadas presente nos sistemas particular. A Gerência de Configuração de Software (GCS ou
legados, que continuam em funcionamento e resistem às mo- SCM – Software Configuration Management) é uma coleção de
dificações ou evoluções. atividades projetadas para controlar mudanças e identificar as
Muito dos problemas citados acima são diferentes daqueles alterações feitas em softwares durante o seu desenvolvimento
vividos por desenvolvedores que participam da implementa- e manutenção. Tais atividades se relacionam e contribuem
ção de novos softwares. Durante a fase de manutenção é pos- para definir mecanismos para gerenciar diferentes versões de
sível encontrar documentações mal elaboradas, ou nenhuma software em desenvolvimento, permitindo que seja feita a ras-
documentação. Com isso, os desenvolvedores normalmente treabilidade e auditoria das modificações realizadas (SHARI,
gastam mais tempo analisando o software antes de modificá- HENDLER e PORTER 2007).
lo, prejudicando a entrega das demandas de modificações no Segundo Dart (1991) a GCS é uma disciplina que visa con-
mesmo. trolar a evolução de sistemas de software e propõe técnicas e

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


projeto

ferramentas para a gestão da manutenção de software. Além A GCS possui atividades que devem ser executadas por
disso, estabelece processos para gestão de mudanças com o diversos profissionais com papéis e funções bem distintas.
objetivo de registrar as solicitações para modificar o software, Por exemplo, deve existir em uma equipe de desenvolvimento
tanto para manutenções corretivas ou preventivas, quanto para um gerente de configuração e testadores de software para
controlar a inserção de novos requisitos. Basicamente, a GCS garantir a qualidade do produto que será entregue aos clientes
tem por finalidade responder às seguintes questões básicas: e aos usuários da aplicação.
a) Quais são as mudanças registradas para o sistema? Cada papel deve possuir, de forma bem definida, suas
b) Por que essas mudanças foram registradas? próprias tarefas dentro do processo de gerenciamento da
c) Se o sistema continua íntegro após as mudanças? configuração. Por exemplo, o gerente de projetos tem interes-
ses administrativos, como acompanhar e controlar os prazos
Murta (2006) destaca ainda que a GCS é uma disciplina im- e custos, monitorando o progresso do desenvolvimento,
portante dentro da ES, pois pode contribuir indiretamente para identificando problemas que possam gerar impacto nesse
atender a áreas chave de processo existentes em vários níveis progresso.
de maturidade como, por exemplo, prevenção de defeitos e Os objetivos do gerente de configuração estão relacionados
gerenciamento quantitativo do processo. Contudo, sua maior ao cumprimento de procedimentos e políticas para a criação,
contribuição está no nível 2 do CMM (Capability Maturity Mo- mudanças e testes nos códigos das aplicações, bem como tor-
del), em uma área chave de processo de mesmo nome. nar as informações sobre os projetos mais acessíveis. Além
Vários são os motivos para estudar e adotar a GCS. Atual- disso, esse profissional deve implementar técnicas para man-
mente, grandes aplicações necessitam do controle de versões, ter o controle dos códigos atualizados, criando mecanismos
pois os engenheiros de software devem gerenciar o desenvol- para oficializar os pedidos das mudanças, sendo responsável
vimento de várias aplicações que estão sendo modificadas ao também pela aprovação e autorização das mesmas. O gerente
mesmo tempo e por equipes geograficamente distantes, sendo de configuração cria e compartilha uma lista de tarefas para
pela inserção de novos requisitos, ou por que houve um erro os engenheiros de software, determinando o contexto do
da aplicação em produção. Neste caso, a última versão da apli- projeto de manutenção do software. Além disso, armazena
cação deve ser recuperada, e os componentes que acusaram os e extrai estatísticas sobre os componentes de software, tais
erros devem ser corrigidos ou adaptados. Nessas situações, o como informações que determinam quais são os componentes
engenheiro de software deve estar atento, possuindo técnicas do sistema sofrem mais manutenção.
e ferramentas de controle, pois os componentes corrigidos A meta dos engenheiros de software na gerência de configu-
devem ser alterados e colocados em produção, sem afetar a ração é manter o desenvolvimento e a criação do produto de
integridade e o desenvolvimento da aplicação. software de forma eficiente. Os engenheiros de software usam
Outra motivação diz respeito às dependências que existem en- ferramentas que ajudam a construir um produto de software
tre os componentes de software. Tais dependências muitas vezes consistente, comunicando e coordenando as tarefas que foram
são conhecidas localmente pelos desenvolvedores e analistas da concluídas. Um histórico da evolução de todos os componentes
aplicação. Alguns desenvolvedores que possuem conhecimento deve ser mantido, com o registro dos motivos das mudanças
da configuração interna do software podem abandonar a equipe, e o que realmente foi alterado. Eles também têm a responsa-
ou simplesmente serem realocados para outro setor ou fábrica bilidade de manter as áreas de trabalho usadas para criar,
de software. Desta forma, devem existir meios de compartilhar atualizar, testar e integrar os códigos das aplicações. Por fim,
o conhecimento sobre essas dependências, a fim de facilitar a devem controlar a produção e manutenção de código de acordo
manutenção do software por outros desenvolvedores. com diversas demandas de novos requisitos e a necessidade de
De acordo com Dart (1991) as seguintes atividades sobre a correções geradas por erros do software em produção.
gerência de configuração devem ser consideradas: O testador de software tem o objetivo de certificar se o
1. Identificação: apóia na identificação dos componentes do produto de software foi desenvolvido de forma satisfatória.
software e seus tipos, tornando-os acessíveis para a equipe de Isto envolve testes na versão do produto de software e manu-
desenvolvimento. A identificação também visa o mapeamento tenção do registro dos testes feitos nas versões do produto de
das dependências entre os seus componentes; software e os resultados desses testes (DART, 1991).
2. Controle: estabelece o controle das atualizações e das mudan- Assim como em outras áreas de estudo da ES, a GCS
ças no produto de software no decorrer do seu ciclo de vida. A necessita de soluções de software capazes de auxiliar na
atividade de controle deve possuir mecanismos para gerenciar implementação das atividades relacionadas anteriormente.
e garantir a integridade da configuração do software; Apesar disso, não existe uma definição universal sobre quais
3. Geração de Estatísticas: é a geração dos relatórios de status funcionalidades e requisitos um sistema de GCS deve possuir.
dos componentes e dos pedidos de mudanças. Tais relatórios Pode-se considerar que um software aplicativo que fornece
devem fornecer informações sobre a freqüência em que um controle de versão é um sistema para gerência de configu-
software é modificado; ração. Outros softwares permitem registrar os pedidos de
4. Auditoria e revisão: validação da completude de um produto mudanças, porém muitos não integram estas funcionalidades
e da integridade entre os componentes de software. ao controle de versão.

Edição 20 - Engenharia de Software Magazine 43


De maneira geral, tais sistemas devem possuir os seguintes preenchimento de diversas informações. Além disso, é pos-
requisitos: a) registro das versões dos componentes; b) locali- sível usar o Mantis para acompanhar o processo de alteração
zação das diferenças entre dois códigos modificados; c) reposi- e execução das mudanças, bem como gerar relatórios sobre a
tórios e bibliotecas para armazenar e recuperar componentes; evolução dos pedidos.
e, d) informação sobre os diferentes tipos de componentes.
Outros requisitos podem ser definidos para um sistema de A ferramenta Mantis
GCS, como os requisitos de construção, controle, contagem, Mantis é um aplicativo desenvolvido para ser executado em
processo e equipe. ambiente Web, e pode ser usado para registrar incidentes ou
Sobre os requisitos de construção, os usuários precisam mudanças durante a atividade de manutenção de software.
de meios mais fáceis de implementar o software, tendo a É um aplicativo de código aberto, e é disponibilizado gratui-
funcionalidade de “congelar” o status do produto em algum tamente desde novembro de 2000. É desenvolvido em PHP
momento; mecanismos para otimizar os esforços da constru- podendo utilizar diversos bancos de dados relacionais, como
ção de sistemas a fim de reduzir a necessidade de recompilar MySQL, MS-SQL Server, PostgreSQL ou DB2. O Mantis pode
os componentes e economizar espaço; facilidades de fazer a ser executado em qualquer sistema operacional que suporta
análise dos impactos e prever as ramificações das mudanças; a linguagem PHP, por meio do servidor Apache, podendo
e facilitar de forma mais simples a recuperação e geração de funcionar no Windows ou Linux, por exemplo. As versões
qualquer fase ou parte do produto a qualquer momento (DART, do Mantis são liberadas sob os termos da GNU General Pu-
1991; SHARI, HENDLER e PORTER 2007). blic License (GPL) através do site http://www.mantisbt.org/
Em relação aos requisitos de auditoria, os usuários precisam download.php.
do histórico de todas as mudanças; rastreabilidade entre todos O Mantis é considerado uma ferramenta para GCS, pois
os componentes do produto e suas evoluções; e o log de todos permite registrar, acompanhar e gerar estatísticas das mu-
os detalhes do trabalho feito. danças realizadas durante a atividade de manutenção de
No que diz respeito aos requisitos para contagem e estatís- software. A modificação é relatada, registrada e enviada
ticas, os usuários precisam de mecanismos que registrem as para a equipe de desenvolvimento, onde o gerente de confi-
estatísticas, para examinar o status do produto de software, guração pode acompanhar a execução e o detalhamento das
e gerar mais facilmente relatórios sobre todos os aspectos do mudanças. Através do Mantis também é possível que seja
produto e processo. feito o gerenciamento de comunicações sobre os pedidos de
Sobre os requisitos de controle, os usuários precisam de manutenção, por meio de envio de e-mails e notícias para a
acesso cuidadoso aos componentes do sistema para evitar equipe de desenvolvimento de um determinado projeto de
qualquer mudança errada ou conflito nas mudanças; suporte manutenção de software. Além destas características, esse
on-line para os pedidos de mudança e relatórios dos problemas; software permite o controle de nível de acesso aos pedidos de
meios de acompanhar e controlar os erros encontrados nos manutenção, podendo ser criados perfis e níveis de acesso por
códigos e como, quando e quem desenvolveu o componente projeto de desenvolvimento e manutenção de software. No
com o defeito. entanto, este artigo visa apresentar apenas as funcionalidades
Em relação aos requisitos de processo, os usuários precisam de abertura e controle de mudanças no Mantis, abordando
de suporte para seu ciclo de vida e suas políticas organi- o registro das mudanças, o seu ciclo de vida e os relatórios
zacionais; a habilidade para identificar tarefas para serem existentes. As próximas seções abordam estas funcionalida-
feitas e como e quando elas serão completadas; a habilidade des de forma detalhada.
para comunicar informações apropriadas sobre os eventos
relevantes; e as facilidades para documentar o conhecimento Abertura de mudanças
sobre o produto. A abertura de mudanças no Mantis é tratada como um relato
Finalmente, a respeito dos requisitos de equipe, os usuários de caso, sendo registradas por meio do menu “Relatar Caso”
precisam de áreas de trabalhos específicas; a resolução de existente no menu principal (Figura 1). Para que uma mudança
conflitos quando as mudanças são alteradas ao mesmo tempo, seja relatada, é necessário que a mesma esteja associada a um
a fim de igualar ou mostrar as divergências entre os códigos projeto de software. Tal projeto deve estar previamente cadas-
atualizados, e facilidades para suportar a criação e manutenção trado pelo administrador do sistema. Além dessa característica,
de diversos produtos de software. o Mantis também permite a associação dos usuários inseridos
Com base nos conceitos apresentados anteriormente, a no sistema aos seus respectivos projetos, pois assim que uma
próxima seção apresenta as principais características da fer- mudança for aberta, automaticamente todos os analistas ou
ramenta Mantis, que pode ser usada para registrar incidentes desenvolvedores daquele projeto de software receberão a
e modificações no software, identificando a mudança com o mudança registrada.

Figura 1. Menu Principal do Mantis

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


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


projeto

Figura 7 apresenta um exemplo da tela de resumo, listando segura e com uma maior qualidade, registrando e controlando
todos os projetos cadastrados. Em seguida, a Figura 8 mostra as mudanças que ocorrem no software. Desta forma, os resul-
dois quadros sobre as estatísticas de tempo para casos resolvi- tados obtidos serão um processo de manutenção de software
dos e estatísticas das mudanças por desenvolvedores. 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

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
Figura 7. Resumo de mudanças por projeto 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) –
Figura 8. Estatísticas de Tempo para Casos Resolvidos e Desenvolvedores COPPE-Universidade Federal do Rio de Janeiro, 2006.

Considerações Finais PRESSMAN, Roger S. Engenharia de Software. São Paulo, 6 Ed. McGrawHill, 2006.
O Mantis é uma ferramenta que implementa várias funcionali-
dades que contribuem para a realização das atividades descritas SHAHARI, Hamid Haidarian, HENDLER, James, PORTER, Adam Porter. Software Configuration
por Dart (1991) sobre a GCS. Ou seja, permite a identificação, o Management Using Ontologies. Proceedings of the 3rd International Workshop on Semantic
controle e a extração de dados estatísticos sobre as demandas Web Enabled Software Engineering at the 4th European Semantic Web Conference (ESWC’07),
realizadas. Esta ferramenta possui portabilidade entre vários Innsbruck, Austria, June 6-7, 2007.
ambientes e sistemas operacionais, sendo amplamente utilizada
por equipes e empresas de tecnologia da informação. Tornando- Sommerville, Ian. Engenharia de Software. 6ª. ed. São Paulo: Pearson Addison
se muito útil para os profissionais de TI, o Mantis possibilita que Wesley, 2003.
a fase de manutenção em um software seja realizada de forma

Edição 20 - Engenharia de Software Magazine 47


Atividades Aliadas dos Testes de Software

Melissa Barbosa Pontes De que se trata o artigo?


melissa.pontes@cesar.org.br Este artigo apresenta diversas atividades que
Mestre em Engenharia de Software do Cesar Edu. podem ajudar no direcionamento das ativida-
Certificada em testes de software pelo ISTBQ (In-
ternational Software Testing Qualification Board),
des de testes de software. Para cada ativida-
atualmente trabalha como engenheira de testes de, é apresentada sua definição. Em seguida,
no CESAR (Centro de Estudos e Sistemas Avança- são apresentados alguns benefícios e algumas
dos do Recife), onde desempenha atividades de dificuldades que podem surgir durante sua
definição de processos, liderança e consultoria. É realização.

A
integrante do GrIT (Grupo Independente de Testes
do Cesar) através do qual realiza pesquisas e trei-
qualidade de um software pode
namentos em testes na organização. Possui artigos estar relacionada à existência Para que serve?
e trabalhos publicados em eventos internacionais. de defeitos inseridos durante Fornecer a gerentes, líderes e demais integrantes
É membro integrante da comissão de organização o seu desenvolvimento ou manutenção. de equipes de desenvolvimento e testes de sof-
de EBTS - Encontro Brasileiro de Testes de Software, Entende-se por defeitos uma inconsis-
que já se encontra na quarta edição. Ministra cursos
tware algumas opções para ajudar na condução
de Testes de Software em faculdades.
tência em um componente ou sistema das atividades de testes.
que o impeça de funcionar corretamente
Luiz Fernando Rodrigues Corrêa (Grahan, et al. 2006). Em que situação o tema é útil?
de Barros Dependendo da severidade do defeito Conhecer e aplicar algumas das atividades
luiz.fernando@cesar.org.br encontrado em aplicações, diversos mencionadas neste artigo pode ajudar a
Mestre em Engenharia de Software do Cesar.EDU, podem ser os prejuízos que este pode minimizar os custos de um projeto de de-
especialista em Tecnologia da Informação pela causar aos seus usuários. Alguns artigos senvolvimento de software através do dire-
UFPE, especialista em Planejamento e Gestão Or-
e sites chegam a enumerar o que autores cionamento das atividades de testes.
ganizacional pela FCAP-UPE. Certificado em testes
de software pelo ISTBQ (International Software consideram os piores defeitos de todos
Testing Qualification Board), certificado Sun Certi- os tempos. Um exemplo é a lista feita por
fied Programmer for the Java 2 Platform 1.4, atu- Paul Bourdeaux, publicada em fevereiro • Erros de conversão de unidades, acar-
almente trabalha como engenheiro de sistemas no de 2009, com o título Top Ten Most Infa- retando em grandes prejuízos financei-
CESAR (Centro de Estudos e Sistemas Avançados do
mous Software Bugs Of All Time. ros como a perda da nave espacial Mars
Recife), onde desempenha atividades de identifica-
ção e desenvolvimento/adoção de ferramentas que Entre os defeitos enumerados nestes Climate Orbiter da NASA, em setembro
auxiliem na performance de times de testes. sites e artigos estão: de 1999;

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


Verificação & Validação

• Desvio de rota da sonda Mariner 1, em curso para marte, de um ambiente equivalente ao ambiente de produção, onde o
por erro na transcrição de uma fórmula; sistema será utilizado. Diante de tantas causas que podem levar
• Desintegração do foguete Ariane 5 por causa de um defeito um defeito a chegar ao cliente, não se deve “culpar” o time de
em uma função aritmética. testes por não ter encontrado todos os defeitos, principalmente
porque um dos princípios básicos de testes bem conhecidos na
Uma das maneiras de se identificar os defeitos é através literatura é que é inviável, praticamente impossível, assegurar
das atividades de testes de software. Testes de software são que a aplicação foi 100% testada e não apresenta defeito algum
atividades realizadas em um projeto com o objetivo principal (Grahan, et al. 2006).
de contribuir com a qualidade dos produtos gerados. Para
alcançar este objetivo, a equipe do projeto deve alcançar Benefícios
objetivos menores, como encontrar defeitos nos artefatos do • Ajudam a identificam falhas na cobertura que os ciclos de
projeto, avaliar se o sistema foi construído como deveria, testes dão ao sistema;
analisar o desempenho do sistema em uso para verificar se • Identificam pontos de melhoria no processo utilizado;
está de acordo com o esperado, ou verificar se tudo que foi • Identificam necessidades de capacitação da equipe do pro-
especificado foi realmente desenvolvido, etc. Esses objetivos jeto, não se limitando ao time de testes;
podem mudar de acordo com a estratégia de testes defini- • Antecipam a identificação de defeitos similares aos que
da, mas principalmente de acordo com as fases de testes. escaparam, tornando sua correção menos custosa.
Além disso, os testes de um sistema podem ser de tipos e
abordagens variadas. Isso faz com que as atividades de tes- Desafios
tes representem grande parte dos recursos de um projeto, • Obtenção de informações de defeitos abertos em todas as
chegando a consumir entre 30% e 50% do esforço total de fases de testes do projeto. O acesso a estas informações nem
desenvolvimento (Sommerville, 2004). sempre é possível;
Por isso, quanto mais otimizado o esforço de testes em um • Falta de informação, tais como versão do software e hardware
projeto, maiores são as chances de sucesso. Então, para contri- onde o problema foi identificado. Apesar de serem informa-
buir com a efetividade das tarefas de testes, existem diversas ções simples, estes dados nem sempre são registrados como
atividades que podem ser desempenhadas pela equipe. No deveriam;
entanto, nem sempre o time de testes tem conhecimento da • Interpretação adequada dos relatos de defeitos. Muitas ve-
existência dessas atividades, ou não conhece os benefícios que zes os defeitos são relatados de maneira muito resumida, ou
elas podem trazer para um projeto. confusa, dificultando a sua reprodução.
O foco deste artigo é abordar diversas maneiras de aumentar
as chances de sucesso nos testes de um software, através do Taxonomia dos Defeitos
desempenho de atividades como: análise de defeitos escapa- É a classificação de defeitos em categorias. Esta classificação
dos, análise de causa raiz, taxonomia de defeitos, injeção de serve de base para a identificação dos tipos de defeitos que
faltas, predição e prevenção de defeitos em software. Para cada acontecem no sistema e permite agrupá-los para conhecer
uma das atividades mencionadas, são apresentados alguns melhor o produto e suas áreas de maior risco. Um defeito
benefícios e algumas dificuldades. Não é o objetivo deste artigo pode estar relacionado com uma ou mais categorias. À me-
esgotar todas as possibilidades nesse levantamento. dida que a análise é realizada, mais categorias podem surgir
para que a classificação seja o mais fiel possível à realidade do
Análise de Defeitos Escapados (Escaped Defects projeto. Alguns exemplos de categorias onde defeitos podem
Analysis - EDA) ser enquadrados são: omissão de informação, informações
De acordo com Gilleran (2002), análise de defeitos escapados inconsistentes, erro na geração da informação, pouco nível de
pode ser entendida como sendo a análise dos defeitos que es- profundidade dos testes realizados, falta de entendimento dos
capam de uma fase de testes para outra, bem como a análise objetivos dos testes, dentre outras.
dos defeitos que são encontrados pelos clientes. Entender o
motivo pelo qual os defeitos não foram encontrados no momen- Benefícios
to adequado, isto é, na fase de testes adequada, possibilitam • Embasam a melhoria do processo utilizado no projeto (Ro-
subsídios para a melhoria de artefatos de testes e até a revisão binson, 2008) através do conhecimento dos problemas que
do processo seguido. ocorrem com frequência;
A primeira coisa a ser feita é entender o que motivou o • Ajudam a entender as características do produto;
aparecimento do defeito. Dentre os diversos motivos, pode- • Identificam pontos de melhoria no código do sistema.
mos citar: falta de cobertura apropriada das suítes de testes;
falta de entendimento na execução dos casos de teste; falta de Desafios
conhecimento de funcionalidades do sistema; falta de tempo • Acesso às informações do projeto. Deve haver uma garantia
para executar grande parte dos testes; inexperiência do time de de acesso sempre que necessário aos mesmos tipos de docu-
testes; erros em documentações do projeto; e indisponibilidade 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). • Melhor direcionamento das atividades de testes para áreas
Como geralmente são analisados diferentes tipos de artefatos, da aplicação que apresentam maiores riscos;
deve haver uma padronização nas categorias definidas para • Ide nt i f ic aç ão de p o nto s de mel hor i a no c ó d igo
os defeitos. desenvolvido;
• Análise do progresso do projeto, em termos de percentual
Injeção de Faltas de defeitos encontrados;
Segundo Weber (2007), injeção de faltas em software é uma • Planejamento de desenvolvimento de iterações futuras.
técnica experimental de validação. Injetar faltas para avaliar o
comportamento do sistema pode ajudar a entender como este Desafios
se recupera de falhas. Esta atividade geralmente é realizada • Garant ir que todos os defeitos encontrados serão
através de ferramentas, e de maneira controlada. De outra registrados;
maneira, a análise pretendida poderia ter a sua qualidade • Dificuldade de isolamento da localização exata do módulo
comprometida. Em artigo apresentado no REVVIS (Reunião onde ocorreu o defeito, quando as informações registradas
de Especialistas em Verificação e Validação de Software), no não estão muito precisas;
ano de 2007, Weber menciona algumas ferramentas (injetores • Falta de acesso às informações do projeto, seja por confiden-
de faltas) desenvolvidas por um grupo de pesquisas da UFRGS cialidade ou por falta delas;
(Universidade Federal do Rio Grande do Sul). • Indisponibilidade de recursos alocados. Esta atividade exige
uma criteriosa análise das informações obtidas, e é necessária
Benefícios uma alocação formal para sua condução.
• Permite avaliar o comportamento do sistema na presença
de falhas reais; Confiança na qualidade dos dados coletados é fundamental
• Permite otimizar o esforço de desenvolvimento, já que desen- para a realização de um bom trabalho de predição de defeitos.
volvedores entendem melhor como os defeitos ocorrem; Por isso, a coleta de dados dos projetos deve ser planejada e
• Permite otimizar o esforço de testes (Madeira, 2007); monitorada.
• A injeção das faltas pode ser feita através de ferramentas. Mais detalhes sobre este tema podem ser encontrados no
artigo Predição de Defeitos em Software, publicado na Edição 17
Desafios da Engenharia de Software Magazine.
• Injetar faltas de maneira controlada;
• Discernir entre faltas que realmente são importantes de faltas Prevenção de Defeitos
cuja análise não agrega valor. Segundo Lanier (2004), prevenção de defeitos é o processo
de analisar as causas que originaram estes defeitos com o
A modificação de processos de testes para incluir atividades objetivo de prevenir a ocorrência do problema no futuro. Não
de injeção de faltas já acontece há algumas décadas no Brasil necessariamente as causas que levam a defeitos são analisa-
e em outros países do mundo. O assunto já era tratado na aca- das em um projeto só em uma empresa. O ideal é que sejam
demia no final dos anos 80, mas o foco eram sistemas críticos. analisados vários projetos para identificar se os problemas se
Hoje em dia já é possível encontrar relatos de estudos de caso repetem entre as equipes. Dessa maneira, ações de melhoria
em pequenos sistemas. em um projeto podem servir de exemplos para toda a empresa,
fazendo com que diminua o esforço gasto pelas equipes na
Predição de Defeitos tentativa de resolver o mesmo problema diversas vezes.
É a tentativa de antecipação da localização de defeitos em Prevenir defeitos em um projeto é uma tarefa de melhoria
uma aplicação, antes que eles ocorram, viabilizando ações do processo de desenvolvimento. O nível de maturidade 5 do
corretivas o quanto antes. CMMI inclui atividades de prevenção de defeitos e resume o
A predição de defeitos se dá através da aplicação de técnicas processo da seguinte maneira:
variadas, que analisam informações coletadas dos projetos, e • É feito um planejamento das atividades de predição de
tentam prever o comportamento de versões futuras do códi- defeitos;
go. Modelos de predição podem identificar, por exemplo, se • As causas do aparecimento de defeitos são identificadas;
determinado módulo da aplicação está ou não propenso ao • As causas do aparecimento de defeitos são priorizadas e
aparecimento de defeitos, estimar a quantidade de defeitos eliminadas.
que podem aparecer em um módulo, estimar a densidade de
defeitos ou ainda, identificar quais módulos podem apresentar A eliminação dessas causas deve ser considerada uma ação pre-
maiores quantidades de defeitos. ventiva. Espera-se com isso que este não ocorra mais no futuro.
Prevenção de defeitos é diferente de predição de defeitos. Na
Benefícios prevenção, existem ações para que o defeito não ocorra. Na
• Dá suporte a geração de informações para suporte ao plane- predição, apenas tenta-se antecipar a localização do defeito
jamento das atividades de testes; que já está no código.

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


Verificação & Validação

Benefícios Desafios
• Espera-se uma diminuição no esforço com atividades de • Dependendo de como é realizada, pode se tornar uma
correção de defeitos e manutenção do produto; atividade cara para o projeto;
• Certamente haverá confiabilidade na imagem do produto • Entender que fatores em um projeto influenciam na seleção
no mercado; de casos de teste;
• Cada medida de prevenção tomada contribuirá para a me- • Manutenção da suíte de testes para que o processo de se-
lhoria do processo de desenvolvimento. leção seja confiável.

Desafios Análise de Suítes de Teste


• Identificar oportunidades de treinamentos para a equi- Periodicamente, é fundamental que seja feita uma aná-
pe do projeto baseando-se nos tipos de defeitos que são lise das suítes de testes de um projeto, assim como deve
encontrados; ser feita uma análise dos resultados das execuções das
• Identificar ações que levam a defeitos antes que estes ocorram mesmas e da estratégia de testes utilizada. Esta análise
(Chang, 2006). busca identificar casos de testes problemáticos, testes que
estão sempre passando nas execuções, testes que checam
Priorização de Testes de Regressão funcionalidades que já não existem no sistema ou que
Testes de regressão são os testes realizados em um sistema onde tiveram o seu comportamento modificado.
um dos objetivos é verificar se a inclusão de novas funcionali- Uma vez que os casos de testes são executados, algumas
dades ou a correção de defeitos e outros tipos de modificação inconsistências podem ser reveladas nos roteiros que devem
do código não provocaram efeitos colaterais, introduzindo ser seguidos. Em geral, são encontrados problemas que não
novos defeitos, ou fazendo com que funcionalidades deixem de são pegos em inspeções dos artefatos de teste como um
operar corretamente. Neste contexto, a regressão é feita através caminho errado a ser seguido pelo testador ou um compor-
da execução dos casos de testes existentes. Estudos relatam que tamento diferente do que está escrito no teste. Isso não quer
quando há priorização desses casos de teste, a taxa de detecção dizer, necessariamente, que o software apresenta defeito,
de defeitos aumenta. mas pode indicar que os testes estão com problemas.
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 Benefícios
já registrados, mas nem sempre isso é possível. Por isso, é comum • Identificar casos de testes que estão sempre passando nos
a prática de classificar os casos de teste de uma suíte em níveis de ciclos. Em situações em que é preciso priorizar testes para
prioridade. Por exemplo, pode-se classificar os testes com os níveis a execução, talvez os casos de teste que há algum tempo
variando de 1 a 5, onde os casos de teste que apresentam nível 1 não ajudam a encontrar defeitos possam ser retirados do
podem testar áreas mais críticas do sistema. Dessa maneira, quan- escopo da execução;
do há a necessidade da realização de testes de regressão e não há • Identificar casos de testes que estão sempre falhando. Caso
tempo para a realização de regressão total, pode-se criar um ciclo os testes estejam sempre falhando e os defeitos no software
com os testes considerados mais importantes das suítes. não sejam consertados, há a possibilidade de o teste está
Mas nem sempre é suficiente simplesmente selecionar casos verificando algo que não seja importante para a aplicação;
de testes baseando-se em níveis de prioridade. Geralmente é • Permite avaliar a qualidade da escrita dos casos de
necessário selecionar um subconjunto de testes adequado a um teste.
contexto específico. Vários autores apresentam técnicas de seleção
de casos de testes para regressão. Desafios
Alguns autores priorizam para testes os requisitos da aplicação, • Algumas vezes os resultados de testes de diferentes níveis e
e rastreiam quais casos de teste certificam os requisitos escolhi- fases são conflitantes. Por exemplo, em uma fase A, 65% dos
dos. Outros fatores servem como base para priorização, tais como: testes estão passando. Já na fase B, 95% dos testes passam.
áreas de risco, funções complexas, código muito modificado e Neste caso, uma análise mais aprofundada das suítes das
áreas do código que devem ser cobertas, por exemplo. duas fases deverá ser realizada para avaliar qual das duas
está coerente com a qualidade apresentada pelo software;
Benefícios • Suítes de testes muito grandes (contendo muitos casos
• Aumentam a efetividade da seleção de casos de teste (Li, de teste) podem tornar custosa esta atividade;
2007); • Manter uma matriz de rastreabilidade de requisitos para
• Diminuem os custos da regressão, podendo até diminuir casos de testes sempre atualizada. Dessa maneira, sempre
a quantidade de testes executados em um ciclo, mantendo o que alterações de escopo e funcionalidades forem feitas no
objetivo da execução; projeto, será menos custoso identificar quais testes devem
• Permitem rápido feedback sobre a aplicação; ser retirados de ciclos de execução, ou quais artefatos do
• Permitem a correção de defeitos mais graves o mais cedo projeto devem sofrer modificações impactadas pela alte-
possível, já que os testes são priorizados por risco. 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

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

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
Antonio Mendes da Silva Filho
heurística e percurso cognitivo (ou cognitive

O
antoniom.silvafilho@gmail.com
Professor e consultor em área de tecnologia projeto de qualquer produto re- walkthrough), bem como definir critérios quan-
da informação e comunicação com mais de quer do projetista a habilidade titativos de avaliação da usabilidade de produ-
20 anos de experiência profissional, é autor do de examinar fatores que deter- tos ou serviços.
livros Arquitetura de Software e Programan- minam (1) o tipo de produto que você
do com XML, ambos pela Editora Campus/El-
sevier, tem mais de 30 artigos publicados em
quer desenvolver, (2) a informação que Em que situação o tema é útil?
eventos nacionais e internacionais, colunista será exibida, (3) a interface de usuário, (4) A avaliação da usabilidade de produtos ou
para Ciência e Tecnologia pela Revista Espaço o padrão de uso do produto e a (5) inte- serviços pode ser feita utilizando-se avalia-
Acadêmico com mais de 60 artigos publicados, ração do usuário com o produto. Perceba ção heurística e percurso cognitivo. Entretan-
tendo feitos palestras em eventos nacionais e que esses fatores compreendem a base to, esses métodos não identificam todos os
exterior. Foi Professor Visitante da University
do que é denominado “user experience”. problemas de usabilidade em produtos como
of Texas at Dallas e da University of Ottawa.
Formado em Engenharia Elétrica pela Uni- Mas, o que é user experience? Trata-se da sistemas de software e aplicações web com
versidade de Pernambuco, com Mestrado em experiência do usuário quando interage grande quantidade de funcionalidades, exi-
Engenharia Elétrica pela Universidade Federal com produtos ou serviços. Aqui, produto gindo testes com usuários a fim de capturar
da Paraíba (Campina Grande), Mestrado em pode ser qualquer coisa como, por exem- problemas de usabilidade não identificados
Engenharia da Computação pela University of
plo, um fogão, uma maçaneta de porta, por outros métodos.
Waterloo e Doutor em Ciência da Computação
pela Univesidade Federal de Pernambuco. um painel de automóvel ou um software.

Edição 20 - Engenharia de Software Magazine 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.” Figura 1. Pirâmide da user experience

Este artigo trata de user experience e como essa informação É importante ressaltar que os fatores acima estão diretamente
pode ser usada no projeto e avaliação da usabilidade de relacionados com a experiência do usuário na forma que o
produtos. usuário ‘percebe’ e interage com o produto ou serviço. Isso
compreende a user experience. Nielsen e Norman a definem
Usabilidade dizendo que:
A usabilidade é uma característica de um produto ou ser-
viço que informa quão fácil de usar e aprender esse produto “User experience compreende todos os aspectos da inte-
(ou serviço) é. Em outras palavras, serve como um indicador ração do usuário final com a organização, seus serviços e
de quão intuitivo é utilizar aquele produto (ou serviço). seus produtos. O primeiro requisito para um experiência
Perceba que essa característica influencia diretamente o de usuário é atender às necessidades exatas do cliente de
interesse do usuário em utilizar ou não esse produto ou maneira objetiva. Além disso, há a simplicidade e elegância
serviço. No entanto, em sistemas de software, assim com que geram produtos que são atrativos para o uso. A verda-
em outros produtos, a usabilidade é avaliada não apenas deira experiência de usuário vai além de dar aos usuários
quando o produto está pronto, mas também durante todo o que eles querem ou oferecer características de uma lista
o processo de desenvolvimento visando assegurar o nível de itens solicitados. Visando obter experiência de usuário
desejado de usabilidade. com qualidade nos benefícios de uma organização, deve
Observe que a interface de usuário é determinante em di- haver uma combinação de serviços de varias disciplinas,
versos aspectos. Um resultado direto disso é que as interfaces incluindo engenharia, marketing, projeto industrial e design
bem projetadas aumentam o grau de eficiência com que o gráfico, e projeto de interface.” [Nielsen& Norman Group]
usuário realiza as suas tarefas. Isto tem impacto direto na  
produtividade de uma organização além de satisfação sub- Agora, se você necessita projetar um produto a ser utilizado
jetiva no uso do sistema pelo usuário. E mais, isso também por usuários, você deve trabalhar com a premissa de que usa-
reduz os custos de apoio ao usuário tais como treinamento e bilidade é um requisito essencial deste produto. Para tanto,
atendimento ao usuário. O projeto da interface de usuário de você deve considerar diretrizes de projeto (ou user interface
um produto leva em consideração a experiência do usuário design guidelines), como alguns destacados no quadro de links
na interação com o produto. Em que situações isso acontece? deste artigo, e heurísticas de usabilidade. Essas informações
Quando a interface de usuário se insere naturalmente no servem para guiar o projeto durante seu processo de desen-
ambiente de trabalho do usuário, tornando a realização de volvimento, bem como na inspeção de usabilidade.
tarefas eficiente. Existem diversos métodos de inspeção de usabilidade que
podem ser empregados para avaliar aspectos relacionados
User Experience com a usabilidade de produtos a fim de detectar problemas
O projeto de um produto requer que você (projetista) consi- de projeto e fazer recomendações para a eliminação desses
dere um conjunto de fatores, listados abaixo: problemas. Exemplos de métodos compreendem avaliação
1. O tipo de produto que você quer desenvolver; heurística, percurso cognitivo (cognitive walkthrough) e testes
2. A informação que será apresentada ao usuário; com usuário. Vale ressaltar que problemas de usabilidade
3. A interface de usuário do produto (ou serviço); estão diretamente associados com aspectos da interface de
4. O padrão de uso do produto (ou serviço); usuário do produto. Tais problemas podem resultar em difi-
5. A interação do usuário com o produto. culdade no aprendizado e uso do produto, bem como pode
causar insatisfação do usuário e até mesmo uso ineficiente
O objetivo ao apresentar esses fatores não é o de ser completo, do produto.
mas de identificar ‘fatores’ que contribuem e afetam a expe- Com isso em mente, você, engenheiro de software no papel
riência do usuário (user experience) no ‘uso’ de um produto ou de projetista e avaliador da interface de usuário de um pro-
serviço. Costumo denominar esses fatores como a ‘pirâmide’, duto ou serviço, precisa justificar o que lhe motiva a fazer a
que compreende a base da user experience, como ilustrado na avaliação de usabilidade. A listagem abaixo destaca situações
Figura 1. onde você deve considerar fazer uma avaliação:

54 Engenharia de Software Magazine - User Experience


Verifica ção e Validação

• Identificação dos principais problemas antes de se efetuar • Oferecer recursos de uso eficiente e rápido da interface, tor-
testes com o usuário; nando-a flexível e customizada às necessidades dos usuários;
• Comparação entre projetos para escolher qual projeto • Eliminar informações irrelevantes, visando prover suporte
investir; ao projeto minimalista e à estética;
• Verificação de projeto visando determinar se atende a pa- • Oferecer aos usuários mecanismos de ajuda que lhe permi-
drões projeto e recomendações de guias de estilo; tam reconhecer, diagnosticar e tratar erros;
• Apoio a preparação de testes com o usuário sobre questões • Prover os usuários de documentação e recursos de ajuda
não verificadas no processo de avaliação. baseadas em tarefas dos usuários.

No entanto, as avaliações como, por exemplo, avaliação Mas, há interdependência entre elas, o que implica numa di-
heurística e percurso cognitivo possuem limitações quanto ficuldade para você, em um momento como projetista e noutro
ao grau de ‘cobertura’ de problemas de usabilidade veri- como avaliador, em escolher a melhor alternativa. Isso mostra
ficados. Nessas avaliações, observa-se a interdependência que o usuário é participante essencial do processo. E, nada
entre heurísticas, o que requer a participação do usuário melhor existe para responder a intermináveis argumentos
para indicar qual melhor alternativa a ser adotada. Além (e até discussões) do que dados. Você substitui os argumentos
disso, as avaliações não são boas para tratar preferências e opiniões por dados e números. Perceba que dados fazem as
de grupos, diferenças de ‘culturas’, compromissos aceitá- opiniões sumirem se elas não estiverem baseadas em dados
veis pelos usuários (como apresentação e classificação de e, como conseqüência, o tempo de reuniões de avaliação são
opções, rótulos usados), além de não prover informações reduzidos. Seu tempo agora passa a ser empregado para ana-
suficientes para refinamento de projeto. Essas limitações lisar e interpretar os dados.
de métodos de avaliação devem ser levadas em conta para Agora, se você ainda não está convencido da importância de
fazer testes com usuários, como apresentado a seguir. realizar testes com usuários, lembre-se de que há situações que
envolvem o risco humano ou econômico, onde a participação
Testes de Usabilidade do usuário no processo de inspeção da usabilidade é essencial.
Teste de usabilidade é um método de inspeção da usabilida- Em tais situações, é imperativo a realização de testes com o
de que visa medir a taxa de sucesso que usuários conseguem usuário. Vale ressaltar que os testes são, muitas vezes, empre-
utilizar e/ou aprender a usar um produto ou serviço para gados como atividade complementar no processo de inspeção
realizar tarefas. da usabilidade apoiados na análise e interpretação de dados
Um teste de usabilidade objetiva avaliar se o projeto da como apresentado a seguir.
interface atende às necessidades dos usuários. A pergunta
que agora você pode estar se fazendo é: Análise e Interpretação de Dados
De um modo geral, os testes de usabilidade têm por obje-
Por que testar a usabilidade? tivo coletar dados (durante o teste) os quais são analisados
e interpretados, munindo você (projetista) de informações
A principal motivação para realizar testes com usuário sobre a usabilidade de um produto ou serviço. Dessa forma,
é eliminar uma série de argumentos e discussões sobre quando você realiza testes com usuário, você precisa obter
a forma apropriada de fazer algo. Para exemplificar isso, dados, checando:
lembre-se de que a usabilidade é um elemento norteador • Desempenho dos usuários (i.e. a velocidade na qual eles
do processo de desenvolvimento, isto é, o desenvolvimen- conseguem realizar as tarefas);
to acontece sob a ótica do usuário, buscando apoiar de • Taxa de erros cometidos pelos usuários quando executando
maneira natural a realização de suas atividades. E, para tarefas;
tanto, os projetistas consideram heurísticas de projeto de • Tempo de aprendizagem para uso do produto ou software,
interface, como as heurísticas propostas por Jakob Niel- no qual o usuário começa como iniciante até atingir domínio
sen (disponíveis em http://www.useit.com/papers/heuristic/ no uso do produto;
heuristic_list.html): • Grau de retenção das informações exibidas pela interface
• Exibir o estado do sistema, oferecendo visibilidade do ao longo do tempo e nível de satisfação subjetiva (quando
status; os usuários testados expressam sua satisfação em utilizar o
• Fazer o mapeamento natural entre o sistema e o mundo produto ou software).
real;
• Prover suporte de controle e liberdade de escolha para Embora o teste de usabilidade ajude o projetista a verificar se
usuários; a interface de usuário atende aos critérios pré-definidos, o grau
• Prover consistência e seguir recomendações de padrões; de confiabilidade não é total, pois você pode estar testando
• Priorizar a prevenção de erros de usuários; usuários atípicos e o resultado obtido não pode ser generaliza-
• Minimizar a necessidade de memorização dos usuários, do para toda população de usuários. Além disso, o teste sempre
priorizando o reconhecimento à recordação; 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 • (A velocidade de) desempenho do usuário;
usuários em complemento a outro método de inspeção de • Tempo de aprendizado do usuário;
usabilidade, você quer identificar áreas de problemas que não • Avaliação subjetiva do usuário;
foram capturadas antes, bem como necessita efetuar uma revi- • Retenção do usuário;
são ou ‘ajuste’ no projeto de modo a atender às necessidades • Taxa de erros.
do usuário. Mas, como você deve fazer isso?
Note que você precisa de uma metodologia (isto é, um con- Na interpretação de dados (dos testes com usuários), você
junto de passos) descrevendo as atividades que você precisa (avaliador) deve priorizar os problemas mais severos. Mas,
realizar, a ordem na qual essas atividades devem acontecer, você questiona:
o que cada atividade requer e o que cada atividade produz.
Portanto, sua atividade de testes com usuários compreende Como posso determinar a severidade de um problema de
análise e interpretação de dados. Você deve entender estas usabilidade?
duas atividades como sendo atividades do tipo ‘guia’ dos
testes com usuários. A taxa de severidade de um problema da usabilidade (de um
Nesse sentido, na etapa de análise de dados, você precisa produto ou serviço) pode ser determinada por um conjunto
obter dados quantitativos que lhe permita aferir a usabilidade. de fatores que compreendem:
Para tanto, você deve levantar dados como, por exemplo: • Tempo exigido para completar uma tarefa;
1. Tempo para realizar uma tarefa; • Número de usuários que tiveram ou encontram um
2. Percentual de tarefa concluído; problema;
3. Percentual de tarefa concluído por unidade de tempo; • Impacto negativo da percepção do usuário do produto ou
4. Taxa de sucessos/falhas; serviço;
5. Tempo consumido com erros; • Grau de dificuldade para realizar tarefas usando o produto
6. Percentual de erros; ou serviço (onde você deve considerar difícil se mais de 70%
7. Número de comandos utilizados; dos usuários não conseguem realizar tarefa).
8. Número de comandos disponíveis não utilizados;
9. Freqüência de uso de ajuda (help) ou documentação; Para determinar a criticalidade de erro, você considera que
10. Quantidade de vezes que o usuário lembra comandos (isto a criticalidade é obtida pelo efeito combinado da taxa de seve-
é, retenção ao longo do tempo); ridade com a probabilidade de ocorrência, ou seja:
11. Número de vezes que o usuário expressa satisfação ou Criticalidade do erro = Taxa de severidade + Probabilidade
frustração; de ocorrência
12. Avaliação subjetiva do usuário quanto ao uso do produto
ou serviço. Para exemplificar tudo isso que tem sido apresentado, neste
artigo o foco, deste ponto em diante, recai sobre a interface de
Note que a coleta dos dados acima pode ser feita através de usuário de web sites. Para tanto, um conjunto de princípios
observações em testes com usuários realizados em laboratório que devem ser considerados compreende:
(de usabilidade). Adicionalmente, pode ser feita a obtenção de 1. Mantenha consistência no uso da linguagem e rótulos e
dados por meio da coleta automática do ‘log’ de acesso e uso evite usar jargões;
dos usuários. Tudo isso pode ser complementado com entre- 2. Traga para o primeiro plano (isto é, a tela principal) as in-
vistas e questionários com os usuários. formações mais importantes;
Todavia, é importante ressaltar que a participação do usuário 3. Ofereça palavras chaves para leitura rápida;
em testes é de caráter voluntário e deve ser precedida da devida 4. Evite usar animações ou sons;
assinatura de termo de concordância em fazer parte do teste. 5. Diferencie textos de elementos gráficos (como figuras e ícones);
Também, você (na condição de avaliador) deve esclarecer aos 6. Faça uso de links consistentes e previsíveis;
usuários participantes que o objetivo do teste é de avaliar o 7. Agrupe conteúdo semelhante na mesma página.
produto ou serviço, e não o usuário.
Numa segunda etapa, você precisa interpretar os dados que Nos testes com usuários, você deve seguir um conjunto de
são obtidos com os testes. Portanto, você deve: etapas com o objetivo de realizar os testes. E, para tanto, você
1. Avaliar os dados obtidos segundo critérios de usabilidade; deve fazer:
2. Priorizar problemas de usabilidade mais severos; • Planejamento dos experimentos;
3. Identificar a criticalidade dos erros; • Determinação de tarefas típicas a serem executadas pelos
usuários;
A fase de interpretação visa levantar informações que lhe • Determinação de protocolos e procedimentos a serem
permita aferir a usabilidade da interface de usuário de um seguidos;
produto ou serviço. Para tanto, você deve estar interessado em • Condução da sessão de teste e registro de informações;
avaliar dados baseados em critérios de usabilidade: • Análise e interpretação das informações coletadas.

56 Engenharia de Software Magazine - User Experience


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

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