UNIVERSIDADE FEDERAL DO MARANHÃO - UFMA

DEPARTAMENTO DE INFORMÁTICA – DEINF

Engenharia de Software

DESENVOLVIMENTO ÁGIL DE SOFTWARE

Alisson Bispo dos Santos

Arthur Azevedo da Silva

SÃO LUÍS - MA
2016
 SUMÁRIO

1. INTRODUÇÃO ......................................................................................................... 3
2. MANIFESTO ÁGIL .................................................................................................... 4
3. PROGRAMAÇÃO EXTREMA ..................................................................................... 6
4. SCRUM .................................................................................................................... 9
5. FDD ....................................................................................................................... 13
6. MSF....................................................................................................................... 15
7. RUP ....................................................................................................................... 16
Engenharia de Software Desenvolvimento ágil de software

1. INTRODUÇÃO

A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em
curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até
quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as
tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise
de requisitos, projeto, codificação, teste e documentação.

3
Engenharia de Software Desenvolvimento ágil de software

2. MANIFESTO ÁGIL

Algumas prioridades quando se trata de desenvolvimento rápido de Software:

1. A maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software

de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se

adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com
preferência aos períodos mais curtos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e

diariamente, durante todo o curso do projeto.

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte

necessário, e confiar que farão seu trabalho.

6. O Método mais eficiente e eficaz de transmitir informações para um time de desenvolvimento,

é através de uma conversa cara a cara.

7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e

usuários, devem ser capazes de manter indefinidamente, passos constantes.

9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.

4
Engenharia de Software Desenvolvimento ágil de software

Há alguns anos, um grupo de profissionais veteranos na área de software decidiram se reunir em

uma estação de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos.
Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de
software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas
experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando
os projetos davam certo.
Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software,
freqüentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a
descrever abordagens de desenvolvimento que seguissem esses princípios.

O manifesto ágil prioriza o que está destaque, sem desvalorizar o que está a direita:

Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

5
Engenharia de Software Desenvolvimento ágil de software

3. PROGRAMAÇÃO EXTREMA

O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para

desenvolvimento de software criadas ao longo da última década. A mais conhecida delas é o Extreme
Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final
dos anos 90.
Com os novos ventos no mundo do desenvolvimento de software, a sociedade passou a
demandar uma grande quantidade de sistemas/aplicações, com softwares complexos, sistemas
distribuídos e heterogêneos, com requisitos mutantes. Entretanto, infelizmente, não há gente
suficiente para desenvolver tanto software com qualidade.
Para resolver esse impasse, densenvolveram-se métodos ágeis a fim de sanar essa demanda.
Conhecidos como Métodos de Desenvolvimento de Software, foram trazidos por programadores
experientes e consultores em desenvolvimento de software. O método XP deixa o bom programador
livre para fazer o que ele faria se não houvesse regras e força o mau programador a se comportar de
uma forma similar ao bom programador.
Ao analisarmos o modelo tradicional de desenvolvimento de software, temos que:

0. Levantamento de Requisitos
1. Análise de requisitos
2.Desenho de Arquitetura
3.Implementação
4.Testes
5.Produção / Manutenção

Mas, e se a realidade fosse outra?:

A atitude dos desenvolvedores de software seria completamente diferente. Tomaríamos as

grandes decisões o mais tarde possível. Implementaríamos agora somente o que precisamos agora.
Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

6
Engenharia de Software Desenvolvimento ágil de software

Vivemos, hoje, em uma nova realidade com fatores como a orientação a objetos, as técnicas
de refatoração, os testes automatizados, que culminam na prática / cultura de mudanças, em que
aprendemos técnicas e adquirimos experiência em lidar com código mutante.
A quem se destina XP? É interessante aplica-lo em projetos com grupos de 2 a 10
programadores, em projetos de 1 a 36 meses e de 1000 a 250 000 linhas de código. Os papéis
representados seriam os de Programadores , “Treinador” ou “Técnico” (coach), “Acompanhador”
(tracker) e o Cliente.
Os princípios básicos de XP são:
 Feedback rápido
 Simplicidade é o melhor negócio
 Mudanças incrementais
 Carregue a bandeira das mudanças /
não valorize o medo (Embrace change)
 Alta qualidade do código

Um exemplo de projeto XP:

 Fase de Exploração
o Duração: 2 a 6 meses.
o Termina quando a primeira versão do software é enviada ao cliente.
Clientes escrevem “histórias” (story cards).
o Programadores interagem com clientes e discutem tecnologias.
o Experimenta-se diferentes tecnologias e arquiteturas para o sistema.
o Planejamento: 1 a 2 dias.

De forma prática, um programador XP tem os seguintes atos de desenvolvimento:

 Executa testes antigos.
 Busca oportunidades para simplificação.
 Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no
momento.
 Escreve novos testes.
 Enquanto todos os testes não rodam a 100%, o trabalho não está terminado.
 Integra novo código ao repositório.

Um modelo de código XP tem padrões de estilo adotados pelo grupo inteiro. Ele é o mais claro
possível, pois o XP não se baseia em documentações detalhadas e extensas, com comentários
padronizados e programação pareada. Enquanto um escreve, o outro pensa em contra-exemplos,
problemas de eficiência, etc. O código pertence a todos.
A refatoração é uma pequena modificação no sistema que não altera o seu comportamento
funcional, mas que melhora a qualidade não funcional, em aspectos como simplicidade, flexibilidade,
clareza e desempenho. Como exemplo disso temos a mudança de nomes de variáveis, mudança na
interface de objetos, pequenas mudanças arquiteturais, com encapsulamento de código repetido em
novos métodos e etc.
O cliente é o responsável por escrever histórias. Muitas vezes é um programador ou é
representado por um programador do grupo. Ele trabalha no mesmo espaço físico do grupo.

7
Engenharia de Software Desenvolvimento ágil de software

O treinador, em geral, é o mais experiente do grupo. Ele identifica quem é bom no que,
eventualmente faz programação pareada. Interessante que seu papel diminui à medida em que o
time fica mais maduro.
O acompanhador coleta estatísticas sobre o andamento do projeto, mantém histórico do
progresso e faz estimativas para o futuro.
O método Programação eXtrema é uma proposta de desenvolvimento ágil e iterativa. O método
XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de
pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a
melhoria constante do código (re-trabalho). Em geral, o XP não deve ser implementado em grupos
grandes de programadores, ou quando feedback rápido não é possível, por exemplo quando o
sistema demora horas a compilar ou testar.

8
Engenharia de Software Desenvolvimento ágil de software

4. SCRUM

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os
projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um
Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de
desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são
chamadas de Sprints no caso do Scrum.
O Scrum não é um processo padronizado onde metodicamente se segue uma série de etapas
sequenciais e que vão garantir a produção, no prazo e no orçamento, de um produto de alta
qualidade e que encanta os seus clientes. Em vez disso, o Scrum é um framework para organizar e
gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software. Para melhor
entender este conceito. Considerando que o framework seja como a fundação e as paredes de um
edifício, os valores do Scrum, princípios e práticas seriam os principais componentes estruturais. Não
se pode ignorar ou mudar fundamentalmente um valor, princípio ou prática sem o risco de colapso.
O que se pode fazer, porém, é personalizar o interior da estrutura do Scrum, acrescentando
artefatos e recursos até que se tenha um processo que funciona para sua empresa.
As práticas do Scrum podem ser apresentadas da seguinte forma:

9
Engenharia de Software Desenvolvimento ágil de software

Os esforços de desenvolvimento utilizando Scrum consistem em uma ou mais equipes Scrum,

cada uma composta basicamente de três papéis: Product Owner, ScrumMaster e Time de
Desenvolvimento.
O Product Owner é o ponto central com poderes de liderança sobre o produto. Ele é o único
responsável por decidir quais recursos e funcionalidades serão construídos e a ordem em que devem
ser feitos. É responsabilidade dele manter e comunicar a todos os outros participantes uma visão
clara do que a equipe Scrum está buscando alcançar no projeto. Como tal, ele é responsável pelo
sucesso global da solução. Para garantir que a equipe construa rapidamente o que o Product
Owner precisa, ele deve colaborar ativamente com o ScrumMaster e com a equipe de
desenvolvimento e deve estar disponível para responder às perguntas tão logo são feitas.
O ScrumMaster é o responsável por ajudar a todos os envolvidos a entender e abraçar os
valores, princípios e práticas do Scrum. Ele age como um Coach, executando a liderança do processo e
ajudando a equipe Scrum (e o resto da organização) a desenvolver sua própria abordagem do Scrum,
que tenha a melhor performance, respeitando as particularidades da organização.
O ScrumMaster também tem um papel de facilitador. Ele deve ajudar a equipe a resolver problemas e
fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe
contra interferências externas e assume um papel de liderança na remoção de impedimentos
que podem atrapalhar a produtividade.
Normalmente o ScrumMaster não tem autoridade para exercer o controle sobre a equipe, de
modo que este papel não é o mesmo que o papel tradicional do Gerente de Projeto ou Gerente de
Desenvolvimento. O ScrumMaster age como um líder, não como um gerente.
No desenvolvimento tradicional de software são abordados vários tipos de trabalho, tais
como: arquiteto, programador, testador, administrador de banco de dados, Designer, e assim por
diante. No Scrum é definido o papel do Time de Desenvolvimento, que é simplesmente a junção de
todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção,
construção e testes do produto. A idéia principal é que a equipe de desenvolvimento se auto-organiza
para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo
Product Owner. Um time de desenvolvimento tem tipicamente entre 5 e 9 pessoas e seus membros
devem ter coletivamente todas as habilidades necessárias para produzir, com qualidade, software
funcionando. O Scrum pode também ser usado em projetos que exigem equipes muito maiores. No
entanto, ao invés de ter uma equipe Scrum com, digamos, 30 pessoas, seria melhor ter entre 3 ou
mais times scrum, cada um com um time de 9 ou menos pessoas.

10
Engenharia de Software Desenvolvimento ágil de software

As atividades principais do Scrum podem ser organizadas assim:

O Product Owner tem uma visão do que ele quer criar (o grande cubo). Como o cubo pode ser
grande, por meio de uma atividade chamada Grooming ele é dividido em um conjunto de
funcionalidades que são compilados em uma única lista priorizada chamado de Product Backlog.
Então é feito a primeira reunião de Planejamento de Sprint, para definir o Sprint Backlog, que contém
todo o trabalho que será executado durante o Sprint.
O Sprint tem duração média de 2 a 4 semanas e são feitas reuniões diárias de
acompanhamento (Daily Scrum) do trabalho. No Scrum, o trabalho mais importante é sempre feito
primeiro.
O Product Owner, com ajuda do resto da equipe Scrum e as partes interessadas, é o
responsável por determinar e gerir a seqüência deste trabalho e comunicando-o na forma de uma
lista de prioridades conhecida como o Product Backlog. O Product Owner, em conjunto com as
demais partes interessadas no produto, definem os itens do Product Backlog. Em seguida, ele garante
que os itens do Backlog são colocados na seqüência correta(usando fatores como valor, custo,
conhecimento e risco), de modo que os itens de alto valor aparecerão no topo do backlog do produto
e os itens de menor valor em direção ao fundo.
O Product backlog é um documento que está constantemente evoluindo. Os itens podem ser
adicionados, excluídos e revistos pelo Product Owner por conta de mudanças nas condições de
negócios, ou conforme a compreensão da equipe Scrum sobre o produto aumenta. Em geral a
atividade de criar e de refinar os itens do product backlog, estimando o tamanho e esforço de cada
item, é chamada de Grooming.
No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calendário
chamados de Sprints. O trabalho realizado em cada sprint deve criar algo de valor tangível para o

11
Engenharia de Software Desenvolvimento ágil de software

cliente ou usuário. Sprints são timeboxed (de duração fixa) para que tenham sempre um início e fim
com data fixa, e, geralmente, todos eles devem ter a mesma duração.
O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais
do que pode ser concluído em um único e curto sprint. Para determinar quais os subconjuntos de
itens do Product Backlog mais importantes para construir no próximo sprint, o product owner, junto
com o time de desenvolvimento e ScrumMaster, devem realizar o Sprint Planning(planejamento de
sprint ).
Durante o planejamento do sprint, a equipe de desenvolvimento e o product owner devem
chegar a um acordo sobre qual o Objetivo do Sprint. Com este objetivo em mãos, eles determinam
quais os itens do backlog devem ser priorizados para serem executados neste Sprint.
Todos os dias, idealmente no mesmo horário, os membros da equipe de desenvolvimento
devem realizar uma reunião com tempo definido (15 minutos ou menos), chamado Daily Scrum. Esta
reunião também é muitas vezes chamada de Stand-Up Meeting, por causa de uma prática
recomendada para que a reunião seja feita em pé(com a intenção de fazer com que a reunião seja
rápida).
No Scrum considera-se como resultado do Sprint produto ou funcionalidade concluída. Para
saber quando, e como, uma parte do produto ou funcionalidade deve ser considerada concluída nós
utilizamos um documento chamado Definition of Done. Embora, isso varie significativamente de um
extremo ao outro para cada time Scrum, os integrantes devem ter um entendimento compartilhado
do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de
Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no
incremento do produto. O objetivo desta atividade é verificar e adaptar o produto que está sendo
construído. Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e
obter comentários e promover a colaboração
Enquanto o objetivo do Sprint Review é verificar necessidades de adaptações no produto, o
Sprint Retrospective tem como objetivo verificar necessidades de adaptações no processo de
trabalho. A Retrospectiva do Sprint ocorre depois da Revisão da Sprint e antes da reunião de
planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um
mês.

12
Engenharia de Software Desenvolvimento ágil de software

5. FDD

O FDD incorpora muitas das boas práticas de desenvolvimento já reconhecidas pela indústria em
um conjunto coeso. Estas práticas todas são orientadas a funcionalidades, que é um conceito de valor
do ponto de vista do cliente. O principal objetivo do FDD é entregar uma peça de software tangível e
funcional para o cliente em espaços de tempo regulares.
Entre as metodologias ágeis que existiam antes do manifesto ágil, o FDD “Feature Driven
Developement” é uma delas. Concebido originalmente por Jeff de Luca, o FDD surgiu em Singapura,
entre os anos de 1997 e 1999 com base no método Coad (Criado por Peter Coad – 1980/1990) e nos
processos interativos e lean já utilizados por Jeff de Luca.
O FDD busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do
sistema. É pratico para o trabalho com projetos iniciais ou projetos com codificações existentes.
Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada
metodologia. O FDD atua muito bem em conjunto com o Scrum, pois este atua no foco do
gerenciamento do projeto e o FDD atua no processo de desenvolvimento.
O FDD possui cinco processos básicos:
- Desenvolvimento de modelo abrangente (Análise orientada por objetos);
- Construção de lista de funcionalidades (Decomposição funcional);
- Planejar por funcionalidade (Planejamento incremental);
- Detalhe por funcionalidade (Desenho orientado a objetos);
- Construção por funcionalidade (Programação e teste orientado a objetos).

Assim como acontece na metodologia XP, o FDD faz uso de teste de software. Desta forma é
possível utilizar TDD, aliás, é indicada a utilização deste para manter a qualidade do software.
O FDD, assim como a teoria de sistemas afirma, entende que a soma das partes é maior do
que o todo. Desta forma, apesar de criar um modelo abrangente baseado no todo que será
desenvolvido, esta fase inicia-se com o detalhamento do domínio do negócio com divisão de áreas
que serão modeladas. O modelo só está pronto quando todos da equipe estiverem de acordo e o
planejamento é feito com base na lista de funcionalidades. Se fossemos trabalhar com FDD em
conjunto com o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como
histórias de usuários a serem desenvolvidas.
Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este
planejamento é incremental. Isto em conjunto com o Scrum, deve ser analisado como etapa de
desenvolvimento do incremento, então este planejamento é feito com base no que será desenvolvido
naquele incremento.
O que está no backlog da sprint são funcionalidades que serão desenvolvidas durante a sprint
(que pode ser de duas a quatro semanas), estas tarefas são então planejadas com maior rigor, neste
ponto, temos então o planejamento incremental, ou seja, planejamos apenas o que vamos
desenvolver. Nesta etapa os envolvidos no processo resumem-se apenas à equipe, ou seja, os
desenvolvedores, analistas, testadores, etc., que vão atuar no processo. Eles devem selecionar os
itens com base no tempo que eles possuem e nas qualificações atuais da equipe.

13
Engenharia de Software Desenvolvimento ágil de software

Após o planejamento, é feito o detalhamento, nesta fase é de extrema importância que o

desenho esteja de acordo com o que o cliente deseja, então é mantido contato constante com o
cliente, como em todas as metodologias ágeis.
Esta documentação é a base para o desenvolvimento. Não deve-se perder tempo com
documentação que não será utilizada, mas é necessário documentar. Posteriormente inicia-se a fase
de desenvolvimento, esta fase é a etapa de desenvolvimento e teste real.
O desenvolvimento também é incremental, e indica-se a utilização de testes do início ao fim do
processo, além da utilização de integração continua.
Um ponto que diverge do XP é que no FDD é incentivado o desenvolvedor como único
responsável pelo módulo que este desenvolve, já no XP, o código é comunitário.
É possível notar como o FDD pode atuar em conjunto com outras metodologias,
principalmente com o Scrum, encaixando-se perfeitamente como metodologia de engenharia ágil de
software com projeto ágil de software.
Além disso, é possível notar que as boas práticas do FDD podem entrar em embate com o XP,
na forma em que o código é tratado por cada uma das metodologias. Lembrando que as
metodologias possuem características que podem ser adaptadas à necessidade de cada empresa, se
notarmos o foco principal em todas as metodologias, temos o desenvolvimento por incremento, a
comunicação constante com o cliente e a integração continua.

14
Engenharia de Software Desenvolvimento ágil de software

6. MSF

O Microsoft Solutions Framework (MSF) surgiu em 1994 como um conjunto de boa práticas
coletadas pela Microsoft a partir de sua experiência na produção de software e serviços de
consultoria. Desde então, o MSF evoluiu, tornando-se um framework flexível para guiar o
desenvolvimento de projetos de software. Como principais características, temos o estabelecimento
de papéis bem definidos, a definição e implantação das boas práticas em fluxos de trabalho e
atividades.
Foram definidos 7 (sete) princípios do Microsoft Solutions Framework (MSF) para
Desenvolvimento Ágil de Softwares, sendo eles:

1. Parceria com o cliente – Aprovação, acompanhamento e consideração por parte do cliente é a

diferença entre valor de negócio real e fictício. Entender a proposta de valor da sua solução e
comunicá-la efetivamente é um atributo chave de sucesso.

2. Trabalho em direção a uma visão compartilhada – Uma visão compartilhada garante que todos os
membros da equipe enxerguem os objetivos do projeto sob uma mesma ótica.

3. Qualidade é trabalho de todos - Qualidade requer tanto prevenção de “bugs/problemas” quanto

verificação de possíveis soluções. Análise de código e revisões em pares são utilizadas para realizar
estas duas tarefas. Todos os papéis são responsáveis pela prevenção e verificação dos problemas.

4. Manter-se ágil, adaptar-se às mudanças - Quanto mais uma organização procura maximizar o
impacto no negócio de um investimento em tecnologia, mais ela descobre novos ambientes e
desafios. Estes ambientes estão sempre sujeitos a mudanças e a experimentação resulta em novas
descobertas, que podem ou não serem aplicados no projeto.

5. Encorajar comunicação aberta - Para maximizar a efetividade individual dos membros da equipe,
a informação precisa estar prontamente disponível para que assim seja constantemente
compartilhada.

6. Faça da implantação um hábito – A equipe deve estar comprometida em criar um produto de

qualidade, inclusive enquanto realiza mudanças e atualizações. Cada mudança deve ser feita com a
certeza de que o produto deve estar pronto para ser implantado a qualquer hora.

7. Fluxo de valor - Planejamento, execução e medição do progresso e velocidade devem ser

baseados na entrega de valor de negócio sempre agregando valor para o cliente. Atividades que não
agregam valor de negócio devem ser minimizadas e deixadas como segundo plano para o projeto.

15
Engenharia de Software Desenvolvimento ágil de software

7. RUP

Nos últimos anos (nos últimos 10 anos mais ou menos) há discussões a respeito do uso das
metodologias ágeis ou das metodologias iterativas mais tradicionais. As metodologias iterativas mais
utilizadas são o RUP e suas variantes.
No início da década de 80, criou-se um processo unificado para desenvolvimento de software, que
acabou evoluindo para o Rational Unified Process (RUP). Foi realizado um estudo que buscava estudar
as características de vários projetos de software que haviam fracassado para tentar identificar as
principais causas dos erros e elaborar uma forma padronizada e eficiente para o desenvolvimento de
softwares. Com base nisso, e em outros processos de software existentes na época, nasceu o RUP, um
conjunto de boas práticas de desenvolvimento de software.
As metodologias tradicionais de desenvolvimento de software dão muita ênfase ao processo, ao
controle do andamento do projeto através de delivarables (que normalmente são diagramas de
diversos tipos, como diagramas de classes ou diagramas de interação). São muito utilizadas em
fábricas de software, em projetos que envolvem muitos desenvolvedores, e não são sinônimos, mas
estão sempre de mãos dadas com siglas como CMMi, e PMI.
As metodologias ágeis são uma tentativa de refinar as metodologias iterativas, tirando o foco do
processo em si e dando mais ênfase à contribuição das pessoas, dos integrantes do projeto. Trazem
alguns conceitos que as diferenciam radicalmente das metodologias antecessoras, como deixar o
cliente participar mais próximo ao processo, iterações extremamente curtas e grande ênfase em
testes automatizados. Por outro lado, pesquisadores e mesmo defensores dessas práticas não
recomendam times muito grandes para um projeto (e alguns propõem dividir o projeto em
subprojetos e trabalhar com equipes menores).
Mesmo tanto tempo depois da definição de métodos ágeis, da publicação do Manifesto Ágil,
porque ainda há essa discussão? Devido à divergência dos dois, por exemplo:

 Burocracia como requisito: existem clientes que pedem pela burocracia, pelo processo mais
rígido. Só contratam empresas que tenham fábrica de software com CMMi nível 50.
 Maturidade: obviamente existe um número muito maior de projetos bem sucedidos utilizando
metodologias que existem há mais tempo.
 Nível técnico da equipe: no caso de muitos gerentes, ao mesmo tempo que métodos ágeis são
vistos como processos que exigem excelentes programadores, pensa-se das equipes menos do
que convém. Ou para diminuir os custos, contratam programadores ruins a preço de banana.
Quando a equipe não é muito capacitada, o gerente acaba querendo ter mais controle sobre o
processo. Quanto menos a mão de obra precisar pensar, menor o seu risco.

Algumas vantagens são percebidas com o uso das metodologias ágeis:

 Testes automatizados. Quando se precisa fazer uma refatoração mais radical, ou resolver
algum bug ou alteração que surgiu, com poucos cliques em um botão sabe-se qual é o
problema. É infinitamente mais útil ter uma ferramenta que disponibiliza essa informação
sobre o software do que pilhas e pilhas de qualquer tipo de documentação e especificação.
 Integração contínua. Pode ser visto como uma extensão dos testes automatizados. É uma
forma de não deixar para descobrir no dia da entrega que o software não funciona (ou só
funciona se o seu código e o do Juca estiverem separados).

16
Engenharia de Software Desenvolvimento ágil de software

 Iterações curtas. Entregar versões do sistema com mais frequência permite descobrir mais
cedo se o projeo está indo na direção certa. É muito melhor quando isso acontece depois de
duas semanas do que três meses depois. E se realmente quer-se saber se é possível cumprir o
prazo, precisa-se deixar que os desenvolvedores estimem o tempo.

17