agile methods by alexandre cota mol

67
Universidade Federal de Minas Gerais Instituto de Ciências Exatas Departamento de Ciências da Computação ALEXANDRE COTA MOL Uma Discussão Sobre os Métodos Ágeis de Desenvolvimento de Software Belo Horizonte 2007

Upload: alexandre-cota-mol

Post on 24-Jul-2015

255 views

Category:

Documents


0 download

DESCRIPTION

a discussion of agile software development

TRANSCRIPT

Page 1: Agile Methods by Alexandre Cota Mol

Universidade Federal de Minas GeraisInstituto de Ciências Exatas

Departamento de Ciências da Computação

ALEXANDRE COTA MOL

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

Belo Horizonte2007

Page 2: Agile Methods by Alexandre Cota Mol

Universidade Federal de Minas GeraisInstituto de Ciências Exatas

Departamento de Ciências da ComputaçãoEspecialização em Informática: Ênfase: Engenharia de Software

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

por

ALEXANDRE COTA MOL

Monografia de Final de CursoCEI-ES 0243-T11-2006-1

Prof. Dr. Rodolfo Sérgio Ferreira de ResendeOrientador

Belo Horizonte2007

Page 3: Agile Methods by Alexandre Cota Mol

ALEXANDRE COTA MOL

Uma Discussão Sobre os

Métodos Ágeis de Desenvolvimento de Software

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

Área de concentração: Engenharia de Software

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

Belo Horizonte2007

Page 4: Agile Methods by Alexandre Cota Mol

Folha de aprovação: fornecida pela secretaria do Programa de Pós-Graduação em Ciências da Computação, com as devidas assinaturas do orientador e da banca de avaliação do trabalho.

Page 5: Agile Methods by Alexandre Cota Mol

À todos aqueles que têm ensinado-me a ser uma pessoa melhor a cada dia, pela confiança, por suas palavras motivadoras, pelo carinho,

o comportamento ético, a honestidade, a amizade e por atitudes admiráveis que têm tornado exemplos e práticas em minha vida.

Page 6: Agile Methods by Alexandre Cota Mol

AGRADECIMENTOS

Inicialmente agradeço a Deus pelos dons recebidos.

À minha esposa e aos meus filhos pelo amor incondicional.

Aos amigos e familiares por entenderem a minha ausência durante a especialização.

Aos meus colegas de curso, Felipe, Jefferson e Ricardo, pelas palavras de motivação.

À todos os colegas pela amizade e companheirismo.

Ao meu orientador, Prof. Dr. Rodolfo, pela sinceridade e agilidade em orientar-me.

A todos os professores pela dedicação em transmitir-nos os seus conhecimentos.

Page 7: Agile Methods by Alexandre Cota Mol

"A primeira e a melhor das vitórias é a conquista de si mesmo.” Platão

Page 8: Agile Methods by Alexandre Cota Mol

RESUMO

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

software começaram a ser questionados, devido, entre outros aspectos, ao grande volume

de documentação. Os métodos ágeis ganharam mais atenção com a publicação de um

manifesto em 2001. Métodos ágeis são essencialmente métodos iterativos, incrementais

e evolutivos de desenvolvimento de software, e uma de suas metas é aceitar as mudanças

de requisitos durante o processo de desenvolvimento, promovendo entregas progressivas

de software funcional o mais rápido possível. Os métodos ágeis têm como uma das suas

premissas a participação do cliente no processo de desenvolvimento de software. O

cliente define e prioriza o que será desenvolvido a cada etapa. Apesar de que os métodos

ágeis têm sido classificados como aplicáveis somente a pequenas equipes, existem

alguns exemplos onde foram aplicados a grandes equipes com uma centena de pessoas.

Este trabalho discute os seguintes métodos ágeis Adaptative Software Development,

Crystal Clear, Crystal Orange, Dynamic Systems Development Method, Extreme

Programming, Feature Driven Development, Lean Development e Scrum. Ao término

deste trabalho existem algumas comparações entre estes métodos e o Rational Unified

Process.

Palavras-chave: Método Ágil. Manifesto. Adaptative Software Development. Crystal. Dynamic Systems Development Method. Extreme Programming. Feature Driven Development. Lean Development. Scrum. Desenvolvimento de software iterativo incremental.

Page 9: Agile Methods by Alexandre Cota Mol

ABSTRACT

The agile methods appeared when the traditional software development started being

questioned, due, among several aspects, to the large volume of documentation. The

agile methods got more attention with the publication of a manifesto in 2001. Agile

methods are essentially iterative, incremental and evolutionary software development

methods, and one of their goals is to accept the changes of requirements during the

development process, promoting progressive deliveries of functional software as soon

as possible. The agile methods are based on the customer’s participation in the process

of software development. The customer defines and prioritizes what will be developed

at each phase. Although the agile methods have been classified as applicable only to

small teams, some examples exist where they were applied to teams consisting of

hundreds of people. This work discusses the following agile methods: Adaptative

Software Development, Crystal Clear, Crystal Orange, Dynamic Systems Development

Method, Extreme Programming, Feature Driven Development, Lean Development and

Scrum. At the end of this work there are some comparisons among these methods and

the Rational Unified Process.

Keywords: Agile Method. Manifesto. Adaptative Software Development. Crystal. Dynamic Systems Development Method. Extreme Programming. Feature Driven Development. Lean Development. Scrum. Iterative incremental development of software.

Page 10: Agile Methods by Alexandre Cota Mol

LISTA DE FIGURAS

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

FIG. 2 – AS METODOLOGIAS DO CRYSTAL SÃO NOMEADAS POR CORES (EM INGLÊS)................................................................................................................36

TAB. 1 – MÉTODOS ORDENADOS PELO NÍVEL DE AGILIDADE E O FORMALISMO (ADAPTAÇÃO DE BOEHM, 2003)...............................................60

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

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

TAB. 4 – FORMALISMO IMPOSTO POR CADA MÉTODO (ADAPTAÇÃO DE BOEHM, 2003)...............................................................................................................62

Page 11: Agile Methods by Alexandre Cota Mol

LISTA DE SIGLAS

AM Agile ModelingASD Adaptive Software DevelompentDSDM Dynamic Systems Development MethodFDD Feature-Driven DevelopmentIID Interactive Incremental DevelopmentJAD Joint Application DevelopmentLD Lean DevelopmentOO Object-OrientedOSS Open Source SoftwarePP Programatic ProgrammingPSP Personal Software ProcessROI Return Of InvestmentRUP Rational Unified ProcessTST Team Software ProcessUP Unified ProcessXP Extreme Programming

Page 12: Agile Methods by Alexandre Cota Mol

LISTA DE TABELAS

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

FIG. 2 – AS METODOLOGIAS DO CRYSTAL SÃO NOMEADAS POR CORES (EM INGLÊS)................................................................................................................36

TAB. 1 – MÉTODOS ORDENADOS PELO NÍVEL DE AGILIDADE E O FORMALISMO (ADAPTAÇÃO DE BOEHM, 2003)...............................................60

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

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

TAB. 4 – FORMALISMO IMPOSTO POR CADA MÉTODO (ADAPTAÇÃO DE BOEHM, 2003)...............................................................................................................62

Page 13: Agile Methods by Alexandre Cota Mol
Page 14: Agile Methods by Alexandre Cota Mol

SUMÁRIO

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

2 OS MÉTODOS ÁGEIS ........................................................................................................ 16

2.1 O SURGIMENTO DOS MÉTODOS ÁGEIS ..................................................................................... 16 2.2 O MOVIMENTO ÁGIL ............................................................................................................ 16 2.3 O MÉTODO ITERATIVO INCREMENTAL DE DESENVOLVIMENTO ..................................................... 18 2.4 O DESENVOLVIMENTO EVOLUTIVO .......................................................................................... 20 2.5 O DESENVOLVIMENTO ADAPTÁVEL ......................................................................................... 20 2.6 O DESENVOLVIMENTO ÁGIL .................................................................................................. 20 2.7 CONTRASTES ENTRE MÉTODOS ÁGEIS E MÉTODOS TRADICIONAIS ............................................... 22

2.7.1 Metas Básicas do Projeto .......................................................................................... 24 2.7.2 Tamanho do Projeto ................................................................................................... 24 2.7.3 Ambiente do Projeto .................................................................................................. 24 2.7.4 Relações com o Cliente ............................................................................................. 25 2.7.5 Planejamento e Controle ........................................................................................... 26 2.7.6 Comunicação no Projeto ........................................................................................... 26 2.7.7 Requisitos .................................................................................................................. 27 2.7.8 Desenvolvimento ....................................................................................................... 27 2.7.9 Testes ......................................................................................................................... 28 2.7.10 Clientes .................................................................................................................... 28 2.7.11 Desenvolvedores ...................................................................................................... 29 2.7.12 Cultura ..................................................................................................................... 29

3 UM COMPARATIVO ENTRE DIVERSOS MÉTODOS ................................................ 31

3.1 SCRUM ............................................................................................................................... 31 3.2 ADAPTATIVE SOFTWARE DEVELOPMENT (ASD) ........................................................................ 33 3.3 LEAN DEVELOPMENT (LD) ................................................................................................... 34 3.4 CRYSTAL ............................................................................................................................. 35

3.4.1 Crystal Clear ............................................................................................................. 38 3.4.2 Crystal Orange ........................................................................................................... 41

3.5 EXTREME PROGRAMMING (XP) ............................................................................................ 43 3.6 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) ............................................................ 51 3.7 FEATURE-DRIVEN DEVELOPMENT (FDD) ................................................................................ 55 3.8 ALGUMAS COMPARAÇÕES ENTRE OS MÉTODOS ÁGEIS ................................................................ 59

4 CONCLUSÃO ...................................................................................................................... 63

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

Page 15: Agile Methods by Alexandre Cota Mol

13

1 INTRODUÇÃO

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

têm publicado livros, dissertações e artigos científicos sobre o desenvolvimento ágil de

software. Entre esses autores, vale ressaltar Alistair Cockburn, Andrew Hunt, Barry Bohem,

Graig Larman, Jim Highsmith, Ken Schwaber, Kent Beck, Larry L. Constantine, Martin

Fowler, Pekka Abrahamson, Richard Turner, Robert L. Glass, Stephen Palmer e Ward

Cunningham. Veremos que o desenvolvimento ágil de software geralmente tem sido

conduzido por algum tipo de processo, ou método ágil. Segundo Aurélio Buarque de Holanda

Ferreira, em Novo Dicionário Aurélio – Século XXI, publicado pela Editora Nova Fronteira,

os significados do substantivo “método” e o adjetivo “ágil” são:

Ágil[Do latim agile]Adjetivo 2 g.1. Que se move com destreza; destro, hábil, desenvolto.2. Rápido, desembaraçado, ligeiro, veloz.3. Ativo, expedito, diligente.

Método[Do grego méthodos, ‘caminho para chegar a um fim’]Substantivo masculino.1. Caminho pelo qual se atinge um objetivo.2. Programa que regula previamente uma série de operações que se devem realizar,

apontando erros evitáveis, em vista de um resultado determinado.3. Processo ou técnica de ensino:4. Modo de proceder; maneira de agir; meio.5. Tratado elementar

Portanto podemos inferir que métodos ágeis devam prover processos, maneiras de

agir, para se alcançar o desenvolvimento rápido de software, de forma desembaraçada.

Conforme o Aurélio temos que:

Desembaraçado[Part. de desembaraçar]Adjetivo.1. Isento ou livre de embaraços.2. Ativo, diligente, expedito.

Page 16: Agile Methods by Alexandre Cota Mol

14

3. Livre de acanhamento, de timidez; desinido.

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

desenvolvimento rápido de software, isento ou livre de embaraços para tal”. Partindo-se desta

hipótese, neste trabalho busca-se conhecer alguns métodos ágeis existentes atualmente, suas

características e fatores que possam contribuir para o desenvolvimento ágil de software. Esses

métodos geralmente possuem processos menos rígidos e um volume de documentação menor

que os métodos tradicionais, por isso costumam ser referenciados em algumas publicações

por métodos leves (lightweight). Ao contrário, métodos tradicionais, como é o caso do

Rational Unified Process (RUP), são chamados em algumas publicações de métodos pesados

(heavyweight) (LARMAN, 2003).

Os métodos tradicionais estão centradas em processos e costumam ser

especificados e construídos através de um meticuloso e extensivo plano, e têm o ciclo do

projeto guiado por tarefas ou atividades, como é o caso do RUP. Estão baseados na predição,

e funcionam bem se a concepção do software não sofre nenhuma alteração. Caso contrário, ao

perceber que uma definição não foi a mais acertada, costuma-se resistir às mudanças, o que

pode comprometer a evolução do desenvolvimento. Isso ocorre devido a alguns fatores que

dificultam a realização de especificações para o desenvolvimento de software que sejam

precisos para o futuro, pois conforme Graig Larman (LARMAN, 2003):

Os clientes ou usuários não estão certos do que querem.

Eles têm dificuldade para expressar tudo o que querem e pensam.

Muitos detalhes do que eles querem somente serão revelados durante o

desenvolvimento.

Os detalhes são geralmente complexos para pessoas.

Quando eles vêem o desenvolvimento do produto, eles mudam seus

pensamentos.

Forças externas, como produtos ou serviços de concorrentes, conduzem as

mudanças ou melhorias requeridas.

Os métodos ágeis, ou métodos leves, baseiam-se na adaptação às mudanças, pois

ao levar em consideração fatores como os citados acima, quanto mais se conhece sobre o

problema, melhores poderão ser as soluções encontradas. Os métodos ágeis estão mais

centrados na interação das pessoas envolvidas no desenvolvimento do software, como

desenvolvedores e representantes do cliente, e no compartilhamento de seus conhecimentos

(LARMAN, 2003).

Page 17: Agile Methods by Alexandre Cota Mol

15

O que se percebe é que a indústria de software está otimista com relação aos

métodos ágeis, mas poucos dados estatísticos estão disponíveis, se comparados aos métodos

tradicionais. No entanto, não é objetivo desse trabalho induzir a utilização de métodos ágeis,

pois como disse Alistair Cockburn (COCKBURN, 2006; tradução nossa):

Um erro comum de um metodologista iniciante é acreditar que a última técnica que ele acabou de aprender é a técnica mestre que todas as pessoas teriam que utilizar, [...] há um número continuamente crescente de técnicas úteis no mundo, e portanto seria de responsabilidade de cada profissional em sua especialidade aprender a usá-las. Não faz nenhum sentido que o autor de uma metodologia a ser utilizada por um número variado de pessoas e equipes em diferentes países, diferentes projetos, com diferentes tecnologias deva legislar sobre qual funcionará melhor para essas pessoas e equipes, isso é algo que cada pessoa e equipe deve pesquisar e decidir sobre.

Esse trabalho fornece uma visão geral dos métodos ágeis, que poderá servir de

base para uma pesquisa mais detalhada sobre cada método aqui apresentado, ou ter esse

trabalho como uma referência para a avaliação entre os métodos ágeis que mais se adequam

as necessidades e as características de uma organização. Por isso esse trabalho está dividido

da seguinte forma:

O segundo capítulo fundamenta o que são as métodos ágeis.

O terceiro capítulo fornece uma descrição dos métodos ágeis mais

utilizadas atualmente.

O quarto capítulo traz a conclusão desse trabalho.

Page 18: Agile Methods by Alexandre Cota Mol

16

2 OS MÉTODOS ÁGEIS

2.1 O Surgimento dos Métodos Ágeis

O surgimento dos métodos leves (leightweight) deu-se nos anos 90 quando os

métodos tradicionais (heavyweight) começaram a ser questionados, devido ao grande volume

de documentação que esses costumam gerar. Os métodos leves começaram a tomar força com

o Movimento Ágil, quando passaram a ser mais conhecidos por metologias ágeis (LARMAN,

2003). Um número crescente de organizações adotaram um ou mais métodos ágeis,

produzindo software com menos documentação, sob a condição de mudanças rápidas para a

satisfação dos clientes, mas outras organizações estão preocupadas com os riscos que podem

estar envolvidos com a redução do volume de documentação (BOHEM, 2003). No entanto a

rápida mudança da economia baseada na Internet demanda flexibilidade e velocidade dos

desenvolvedores de software, algo normalmente não associado com o desenvolvimento

tradicional, onde o problema das mudanças imprevistas é piorado pelos longos ciclos de

desenvolvimentos, que podem produzir códigos bem escritos, mas não atender as expectativas

dos usuários (BOHEM, 2003).

2.2 O Movimento Ágil

A indústria de software viu o movimento ágil ganhar espaço com a publicação do

Manifesto for Agile Software Development (Manifesto para o Desenvolvimento Ágil de

Software) em fevereiro de 2001, por um grupo composto por dezessete pessoas, entre

praticantes e consultores. Representantes do Extreme Programming (XP), Scrum, Dynamic

System Development Method (DSDM), Adaptive Software Development (ASD), Crystal,

Feature-Driven Development (FDD), Pragmatic Programming (PP), entre outros

simpatizantes da idéia de que precizavam encontrar uma alternativa aos processos conduzidos

por documentação, os quais possuem processos rígidos de desenvolvimento de software. Esse

grupo nomeou a si mesmos de The Agile Alliance, pois apesar de serem formados por um

grupo de pensadores independentes, e em algumas vezes competidores entre si, concordaram

com o título (CUNNINGHAM, 2007).

O grupo que elaborou o Manifesto foi composto pelas seguintes pessoas: Alistair

Cockburn, Andrew Hunt, Arie Van Bennekum, Brian Marick, Dave Thomas, James Grenning,

Page 19: Agile Methods by Alexandre Cota Mol

17

Jeff Sutherland, Jim Highsmith, Jon Kern, Ken Schwaber, Kent Beck, Martin Fowler, Mike

Beedle, Robert C. Martin, Ron Jeffries, Stephen J. Mellor e Ward Cunningham.

Os valores defendidos por esse grupo são:

Indivíduos e interações ao invés de processos e ferramentas.

Software operacional ao invés de documentação compreensiva.

Colaboração do cliente ao invés de negociação de contrato.

Responder às mudanças ao invés do seguimento de um plano.

A partir desses valores eles criaram doze princípios nos quais estão embasados os

métodos ágeis:

1. Nossa mais alta prioridade é satisfazer o cliente entregando continuamente

e mais cedo software de valor.

2. As alterações de requisitos são benvindas, mesmo que mais tarde durante o

desenvolvimento. Pocessos ágeis aceitam as mudanças como uma

vantagem competitiva do cliente.

3. Entregar freqüentemente software operacional, em um par de semanas ou

um par de meses, com preferência por um período mais curto.

4. Pessoas de negócio e desenvolvedores devem trabalhar juntos diariamente

durante o projeto.

5. Construir projetos com indivíduos motivados. Dando a eles um ambiente e

apóio que eles necessitam, e confiando que eles concluirão o seu trabalho.

6. O método mais eficiente e efetivo de disseminar informação na equipe de

desenvolvimento está na conversação face-a-face.

7. Software operacional é a medida básica de progresso.

8. Projetos ágeis promovem desenvolvimento sustentável.

9. Os patrocinadores, fomentadores, e usuários deveriam manter um relativo

progresso, constante e indefinidamente.

10. Atenção continua para a excelência técnica e o bom desenho melhoram a

agilidade.

11. Simplicidade – a arte de maximizar a quantidade de trabalho realizado – é

essencial.

12. As melhores arquiteturas, requisitos, e desenhos emergem de uma equipe

auto-organizado.

Page 20: Agile Methods by Alexandre Cota Mol

18

A intervalos regulares, a equipe reflete sobre como tornar-se mais efetivo, então

sintonizam e ajustam seu comportamento adequadamente.

Desta forma em cada iteração exige-se relativo esforço dedicado às diversas fases

do projeto – requisitos, desenho, implementação e teste - e ênfase nas mudanças. Métodos

ágeis são um subconjunto de métodos iterativos (LARMAN, 2003).

O desenvolvimento ágil de software requer inovação e responsabilidade, para

poder compartilhar os conhecimentos entre os integrantes da equipe de desenvolvimento e do

cliente, pois o que se objetiva é aproveitar o potencial dos clientes, usuários e

desenvolvedores, adotando um processo o suficiente para manter a qualidade e a agilidade.

(LARMAN, 2003).

2.3 O Método Iterativo Incremental de Desenvolvimento

O método Iterativo Incremental de Desenvolvimento (IID), é a essência de todos

os métodos ágeis, incluindo Scrum e XP. O IID baseia-se na construção de software através de

várias iterações durante o seu ciclo de vida. Cada iteração realiza um mini-projeto composto

por atividades como análise de requisitos, desenho, programação e teste. O objetivo de cada

iteração é a liberação de um um subconjunto do produto final de software, que seja estável,

integrado e testado, parcialmente é um sistema completo. A maioria das liberações são

internas, isto é, uma linha de base para controle da equipe de desenvolvimento. Somente ao

final de todas as iterações é que o produto estará completo, para ser liberado para o mercado

ou o cliente. Para métodos iterativos modernos a duração recomendada de um iteração está

entre uma a seis semanas. A qualidade é fator relevante, e deve ser considerada para o

software resultante em cada iteração, pois trata-se de um subconjunto do sistema final

(LARMAN, 2003).

Alistair Cockburn (COCKBURN, 2006) diz que um erro comum é assumir que

iterações muito curtas são geralmente boas. Uma iteração deveria, em teoria, permitir que:

Os especialistas de negócio trabalhem nos detalhes das características a

serem construídas na iteração.

Que os programadores possam programá-las.

Page 21: Agile Methods by Alexandre Cota Mol

19

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

foi construído está adequadamente correto, e discutir o que precisa ser

alterado.

Os programadores alterem o software conforme o acordado.

Que se repita os dois últimos passos acima até que os especialistas de

negócio, usuários, e patrocinadores tenham as características do software

prontas para entrega.

Pensamento linear, processos preditivos, unificados, e práticas invariáveis não

atendem a volatilidade dos ambientes de desenvolvimento de hoje, de maneiras que o

processo de desenvolvimento de software vêem mudando de antecipatórios para adaptativos.

Por isso, deve ser incorporado a mobilidade, experimentação, e velocidade no

desenvolvimento de software, e realizar várias iterações durante o ciclo de vida poderá

facilitar o processo de desenvolvimento (HIGHSMITH, 2004).

O planejamento das iterações deve ser conduzido pelos riscos do desenvolvimento

e pelas necessidades e prioridades do cliente. Quanto aos riscos, deve-se escolher os

elementos mais difíceis para serem realizados nas iterações iniciais. Enquanto o cliente é o

responsável por definir as características do que e o que se fará na próxima iteração. A

duração das iterações não precisam ser iguais, nem devem ser utilizadas para pressionar os

desenvolvedores a trabalhar longas horas por dia para cumprirem os compromissos até a data

final, mas uma iteração de três meses a seis meses é longa demais. O Scrum recomenda que

um iteração tenha trinta dias do calendário, mas a maioria dos métodos ágeis recomendam

entre uma semana a seis semanas (LARMAN, 2003).

Ambos os métodos IID e Ágil aceitam mudanças, mas não o caos, por isso que os

métodos IID estão comprometidos com a seguinte regra: uma vez que os requisitos para uma

iteração foram escolhidos e se está progredindo no mini-projeto, nenhum patrocinador externo

poderá alterar o trabalho (LARMAN, 2003).

Reflexão é um fator crítico de sucesso evolvendo uma metodologia de sucesso, da

mesma maneira que desenvolvimento incremental é um fator de crítico de sucesso para a

entrega software (COCKBURN, 2006).

Page 22: Agile Methods by Alexandre Cota Mol

20

2.4 O Desenvolvimento Evolutivo

Os requisitos, planos, estimativas e soluções evoluem ou são refinados durante as

iterações, ao invés de completamente definidos e congelados para que num futuro se faça um

refinamento maior (LARMAN, 2003). As empresas necessitam obter resultados dos seus

esforços dedicados ao desenvolvimento de produtos, mas esses resultados não devem vir de

gastos com qualidade (HIGHSMITH, 2004).

2.5 O Desenvolvimento Adaptável

Os elementos se adaptam em resposta a avaliação do trabalho anterior realizado –

avaliação de usuários, desenvolvedores, testes, etc. O objetivo é semelhante ao

desenvolvimento evolutivo, mas sugere um mecanismo evolutivo de avaliação e resposta

(LARMAN, 2003).

Assim como os produtos precisam ser constantemente adaptados à realidade do

mercado, assim também ocorre com as pessoas e os processos. De fato, se nós queremos

produtos adaptáveis, nós primeiramente devemos construir uma equipe adaptável. Não

importa o quanto uma pessoa, equipe ou empresa possa prever o futuro, esse sempre será uma

surpresa para nós (HIGHSMITH, 2004).

2.6 O Desenvolvimento Ágil

Os métodos ágeis de desenvolvimento de software aplicam o desenvolvimento

iterativo e evolutivo, planejamento adaptável, promovendo entregas progressivas, além de

incluir outros valores e práticas que incentivam a agilidade – rápido e flexível em resposta às

mudanças (LARMAN, 2003). Segundo Aurélio Buarque de Holanda Ferreira, em Novo

Dicionário Aurélio – Século XXI, publicado pela Editora Nova Fronteira diz:

Agilidade[Do latim agilitate]Substantivo feminino.1. Qualidade ou caráter de ágil.

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

nos negócios, no desenvolvimento de software, nos esportes, etc. Jim Collins em seu livro

Good to Great apresenta uma escala bidimensional que descreve as características dos

negócios de sucesso. Uma dimensão é a disciplina, e a outra uma atitude empresarial, que em

Page 23: Agile Methods by Alexandre Cota Mol

21

nosso contexto seria a agilidade. Se a pessoa tem disciplina forte, sem agilidade, o resultado é

burocracia e estagnação. Agilidade sem disciplina é o entusiasmo exacerbado de uma

companhia iniciante mesmo sem obter lucro. Grandes companhias têm ambos em medidas

apropriadas para as suas metas (BOEHM, 2003). Agilidade é mais uma atitude que processo,

mais ambiente que metodologia (HIGHSMITH, 2004).

Como os desenvolvimentos de software estão se tornando cada vez maiores e mais

complexos. O ambiente no qual o software é imaginado, especificado e criado está mudando.

Os aspectos de usabilidade e qualidade do software tornaram-se mais críticos. O tempo

necessário para liberação de um software para o mercado pode significar a diferença entre um

produto próspero ou falido (BOEHM, 2003).

Visando diminuir o tempo necessário para a liberação de um software, os métodos

ágeis são a conseqüencia da prototipação rápida e a experiência de desenvolvimento rápido,

como também o surgimento da filosofia que programar é uma arte ao invés de um processo

industrial (BOEHM, 2003).

A natureza da mudança rápida baseada na economia da Internet demanda

flexibilidade e velocidade por parte dos desenvolvedores de software, algo não usualmente

associado com o desenvolvimento conduzido por métodos tradicionais (BOEHM, 2003).

As mudanças ocorrem em quase tudo no software. Os requisitos mudam. Os

desenho muda. O negócio muda. A tecnologia muda. A equipe muda. Os membros da equipe

mudam. O problem não muda, porque a mudança irá acontecer; o problema, ao acontrário, é a

nossa inabilidade para tratar a mudança (BECK, 2004).

As práticas casadas para suportar esses valores variam de acordo ao método ágil

utilizado, mas geralmente baseiam-se em três áreas (BOEHM, 2003):

Comunicação.

Administração.

Técnico.

Uma outra meta dos métodos ágeis é aceitar as mudanças. Se uma mudança é

determinada, como é na maioria dos projetos de desenvolvimento, então use de técnicas que

tirem proveito das mudanças. Se as exigências mudam rapidamente, tenha iterações curtas o

suficiente para atender as exigências atuais. Constantemente integre e faça testes de regressão.

Mantenha o cliente próximo e envolva-os nos processos de planejamento e validação.

Redesenhe quando necessário, mas não desenhe em demasia. Não desenvolva documentação

Page 24: Agile Methods by Alexandre Cota Mol

22

para ser guardada. Concentre totalmente na iteração atual e entregue um produto que satisfaça

o cliente na hora certa (BOEHM, 2003).

Métodos ágeis em geral necessitam de relacionamento com o cliente e usuários do

software sob desenvolvimento. Os requisitos e a validação dependem da descrição do cliente,

priorização, e o refinamento de suas necessidades ao longo do desenvolvimento. O ciclo para

construir funcionalidade é altamente dependente de um cliente informado e envolvido. O

cliente também estabelece os critérios de aceitação e testes (BOEHM, 2003).

Os métodos ágeis exigem uma massa crítica de pessoas altamente motivadas e

instruídas. A documentação e o desenho são mantidos minimos (BOEHM, 2003).

A aceitação cultural dos métodos ágeis é também necessária para iniciar e manter

agilidade, mas há um ceticismo considerável em utilizar métodos ágeis no desenvolvimento

de grandes softwares, complexos ou de segurança crítica. Os métodos ágeis parecem ser a

melhor escolha para software menores. Embora haja grandes projetos documentados, a grande

maioria das experiências são de projetos relativamente pequenos, projetos de cinco a dez

pessoas. Pois em experiências com projetos ágeis utilizando-se cinquenta pessoas necessitam

que aspectos do processo de métodos tradicionais sejam integrados para se obter sucesso com

grandes projetos (BOEHM, 2003). Ao contrário dessa visão de Barry Bohem (BOEHM,

2003), veremos no capítulo 3 deste trabalho que métodos como o Crystal Clear aumentam a

cerimônia para que possam ser aplicáveis a grandes projetos (COCKBURN, 2006), assim

como o método XP tem sofrido adaptações para que possa ser aplicado a projetos maiores (

BECK, 2003).

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

O refinamento ininterrupto é o tema que vem sendo discutido para o

desenvolvimento sustentável de software. O desenvolvimento de software é complexo e tem

que evoluir continuamente através de um longo período de tempo, face as exigências dos

usuários, e um ecossistema composto por mercados, parceiros, tecnologias e concorrentes em

constante evolução. O que torna impossível ao início de um projeto é planejar todas as

mudanças exigidas. Portanto, as equipes têm que planejar-se para as mudanças e implementar

práticas que melhorem as suas habilidades para adaptarsem às mudanças. Essas práticas

devem cobrir como eles gerenciam os seus projetos, como projetam os seus produtos, e

também as práticas utilizadas para desenvolver os seus produtos. Para acomodar essas

mudanças, as equipes precisam do envolvimento do usuário e uma ênfase na reflexão,

Page 25: Agile Methods by Alexandre Cota Mol

23

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

manter o controle do progresso e dos riscos (TATE, 2005). Esses requisitos estão inseridos em

diferentes proporções nos métodos ágeis e tradicionais, e Barry Bohem e Richard Turner

contrastam esses métodos em BOEHM, 2003.

Neste trabalho os contrastes realizados a seguir estão baseados em BOHEM,

2003, pois alguns autores, que desenvolveram seus próprios métodos ágeis, podem não ser

imparciais como esperaríamos que fossem, e desse grupo cita-se aqui: Alistair Cockburn -

Crystal; Bob Charette – Lean Development (LD); James Highsmith – Adaptive Software

Development (ASD); Ken Schwaber e Jeff Sutherland - Scrum; Kent Beck – Extreme

Programming (XP); Jeff DeLuca e Peter Coad – Feature-Driven Development (FDD).

A grande variedade de métodos tornam a comparação entre métodos ágeis e os

métodos tradicionais muito difícil e imprecisa. O desenvolvimento de software depende de

vários fatores como (BOEHM, 2003):

Características da aplicação:

o Metas básicas do projeto.

o Tamanho do projeto.

o Ambiente do projeto.

Características da gestão:

o Relações com o cliente.

o Planejamento e controle.

o Comunicações no projeto.

Características técnicas:

o Requisitos.

o Desenvolvimento.

o Testes.

Características pessoais:

o Clientes.

o Desenvolvedores.

o Cultura.

Page 26: Agile Methods by Alexandre Cota Mol

24

2.7.1 Metas Básicas do Projeto

As metas básicas de um método ágil são software pronto o mais rápido possível e

responsabilidade pela mudança. Métodos ágeis geralmente não analisam o retorno do

investimento (Return Of Investment – ROI) para determinar uma melhor alocação dos

recursos. Os métodos ágeis preferem entregar software rapidamente e aprender pelas

experiências, descobrindo quais as atividades e características adicionam maior valor

(BOEHM, 2003).

As metas básicas dos métodos tradicionais são preditivos, estáveis e de alta

garantia. Os planos, produtos funcionais, e estratégias de verificação e validação dos métodos

conduzidos por planos apoiam as metas básicas. A melhoria de processo foca na predição e a

estabilidade aumentando a capacidade do processo através da padronização, medição e

controle. A predição é baseada em medidas de atividades anteriores. O controle é realizado

quando o progresso atual estiver fora de tolerâncias esperadas (BOEHM, 2003).

2.7.2 Tamanho do Projeto

Atualmente os métodos ágeis parecem funcionar melhor para equipes pequenas ou

médias trabalhando em aplicações relativamente pequenas (BOEHM, 2003). O concenso geral

é que uma coordenação mais rígida e conhecimento compartilhado geralmente previne

equipes com mais de quarenta pessoas. No entanto tem havido alguns sucessos ocasionais

utilizando-se de métodos ágeis para equipes com mais de 250 pessoas. Um dos maiores

projetos que se tem conhecimento tinha mais de 800 desenvolvedores e utilizou Scrum. Um

projeto baseado em métodos ágeis precisam adotar planos tradicionais e especificações para

conseguirem tratar do aumento da complexidade e iterações multi-dimensionais entre os

elementos do projeto (BOEHM, 2003).

Métodos tradicionais conduzidos por planos lidam melhor com projetos grandes.

Os planos, documentação e processos provêem uma melhor comunicação e coordenação de

grandes equipes. Porém uma organização burocrática conduzida por planos que requeiram em

média uma pessoa-mês para obter um projeto autorizado e iniciado não será muito eficiente

em pequenos projetos (BOEHM, 2003).

2.7.3 Ambiente do Projeto

Page 27: Agile Methods by Alexandre Cota Mol

25

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

mudanças, que tenham uma visão de que as organizações são um sistema complexo e

adaptativo, no qual requisitos surgem sem que possam ser previsíveis. Os métodos ágeis

concentram-se na entrega de um software específico, a tempo, que satisfaça completamente

um cliente. Desta forma geralmente o escopo foca-se no produto em mãos e geralmente

ignoram problemas que possam ocorrer mais tarde (BOEHM, 2003).

Os métodos tradicionais funcionam melhor quando os requisitos são amplamente

determináveis previamente (considerando-se prototipação) e permanecem relativamente

estáveis. A taxa de mudança dos requisitos de 1% (um porcento) ao mês é aceitável. Os

métodos conduzidos por planos também cobrem uma gama maior de atividades que os

métodos ágeis. Frequentemente adotados em desenvolvimentos de software contratados, eles

podem especificar as liberações, organizações, investimentos que ocorrem em múltiplos

projetos. Também antecipam (planejam para) as necessidades futuras através de uma

arquitetura e desenho expansível. Esses métodos desenvolvem capacitações em disciplinas

relacionadas como por exemplo engenharia de sistemas e fatores humanos e esperam impactar

um número abrangente de pessoas em diversos níveis na hierarquia organizacional, assim

como foca na melhoria quantitativa dos processos (BOEHM, 2003).

2.7.4 Relações com o Cliente

Os métodos ágeis dependem consideravelmente de que representantes do cliente

estejam dedicados e alocados junto da equipe de desenvolvimento para que se consiga obter

valores para a organização. O cliente representa e deve estar em sincronia com os usuários do

sistema e a equipe de desenvolvimento. O cliente e a equipe de desenvolvimento tratam dos

problemas previsíveis os resolvendo com antecedência e formalizando as soluções em um

acordo documentado. As vantagens são que a equipe de desenvolvimento sabe o que ela tem

que fazer. Os clientes sabem o que eles estão adquirindo. Isso mantém seu conhecimento

operacional e aumenta a sua eficiência ao exercitar protótipos ou rever os planos de progresso

do projeto (BOEHM, 2003).

O contrato torna a interface entre o desenvolvedor e o cliente o ponto mais crítico

para os métodos conduzidos por processo. Um contrato mais detalhado causa um atraso no

início e é mais difícil adaptar-se às mudanças. Enquanto um contrato impreciso pode criar

expectativas incompatíveis, levando a uma relação díficil e sem confiança entre o

desenvolvedor e o cliente. O peor caso é quando passa-se a disputa judicial. Para o projeto ter

Page 28: Agile Methods by Alexandre Cota Mol

26

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

trabalho necessário com os recursos disponíveis e acordados para tal (BOEHM, 2003).

Os métodos ágeis incentivam a participação do cliente para que haja confiança em

seus registros, os software(s) que desenvolvem e a experiência de seus profissionais, e por

isso tem sido mais usado em desenvolvimentos por equipes internas da organização

(BOEHM, 2003).

As pessoas dos métodos tradicionais confiam em seu processo de maturidade para

promover a confiança em seus trabalhos, mas não se deve assumir que um plano documentado

seja a garantia de que o projeto o seguirá (BOEHM, 2003).

2.7.5 Planejamento e Controle

Agilistas estimam que seus projetos demandam aproximadamente 20% (vinte

porcento) do seu tempo planejando e replanejando. A velocidade dos projetos ágeis e a

agilidade vêm em grande parte dos esforços de planejamento do grupo, baseado no

conhecimento compartilhado ao invés de conhecimento documentado como os representados

por planos e especificações. Quando mudanças imprevistas ocorrem, os colaboradores da

equipe podem compartilhar a visão dos objetivos do projeto e a sua compreensão do software

para desenvolver rapidamente e implementar a solução revisada. Porém assim que o projeto

cresce isso pode tornar-se mais difícil. (BOEHM, 2003).

Métodos tradicionais utilizam-se de planos para ancorar os seus processos e

prover uma comunicação mais abrangente. Os planos compõem uma grande porção da

documentação nesses métodos. Os métodos tradicionais confiam em uma abrangente

documentação e um amplo planejamento do produto para manter todos coordenados. Planos

individuais são frequentemente produzidos para atividades específicas e então são integrados

no “plano mestre”. Um esforço considerável é gasto para manter os dados históricos. O plano

é criado e ajustado constantemente. Os planos tornam explícitos as expectativas e os

relacionamentos entre os vários esforços do projeto (BOEHM, 2003).

2.7.6 Comunicação no Projeto

Os métodos ágeis dependem consideravelmente dos conhecimentos interpessoais

para os seus sucessos. Os métodos ágeis geralmente exigem comunicações mais frequentes e

bilaterarais de pessoa para pessoa, face-a-face. Poucas comunicações nos métodos ágeis são

Page 29: Agile Methods by Alexandre Cota Mol

27

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

conhecimento. Os métodos ágeis empregam documentação, mas eles enfatizam em criar o

mínimo essencial (BOEHM, 2003).

Nos métodos tradicionais as comunicações tendem ser unilaterais. As

comunicações são geralmente de uma entidade para outra, ao invés de entre duas entidades. O

conhecimento ao invés de ser compartilhado é normalmente documentado. Infelizmente o

volume de documentação é reforçada pela maioria dos regulamentos de aquisição de software

do governo (BOEHM, 2003).

2.7.7 Requisitos

A maioria dos métodos ágeis expressam os requisitos como ajustáveis e histórias

informais. Os métodos ágeis contam com seus ciclos rápidos de iterações para determinar as

necessidades de mudanças nas funcionalidades desejáveis e para corrigí-los na próxima

iteração. A determinação do conjunto de requisitos de mais alta prioridade a serem incluídos

na próxima iteração é feito de forma colaborativa entre os clientes e os desenvolvedores

(BOEHM, 2003).

Os métodos tradicionais geralmente preferem as especificações formais,

completas, consistentes e testáveis. Esses métodos geralmente têm sido muito mais lentos que

os métodos ágeis para assimilar novos conceitos como requisitos priorizados e a evolução

desses (BOEHM, 2003).

2.7.8 Desenvolvimento

A diferença primária entre práticas de desenvolvimento ágil e conduzidos por

processos estão entre o desenho e a arquitetura do software. Os métodos ágeis defendem o

desenho simples, onde a funcionalidade é implementada. Agilistas encorajam o desenvolvedor

a fazer um desenho mais simples, em toda oportunidade. Isto significa que se o desenho tem

funcionalidades que estão além das necessidades atuais do cliente ou que as antecipam,

dever-se-á gastar esforço extra para removê-las (BOEHM, 2003).

Os métodos tradicionais utilizam o planejamento e o desenho baseado em

arquitetura para acomodar mudanças previsíveis. Este esforço permite aos desenhistas

organizar o sistema de tal forma a tirar vantagem do re-uso de software através de uma linha

de produtos o que pode ter um maior impacto no desenvolvimento rápido (BOEHM, 2003).

Page 30: Agile Methods by Alexandre Cota Mol

28

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

algumas práticas de desenvolvimento ágil que podem rapidamente ser adotados pelos projetos

conduzidos por processos (BOEHM, 2003).

2.7.9 Testes

Os testes são uma forma de validação que os clientes têm especificado o produto

certo e que os desenvolvedores têm construído o produto certo. Isso requer que o código seja

desenvolvido e executado, o qual significa que para longos desenvolvimentos, problemas

serão descobertos mais tarde no ciclo de desenvolvimento, quando são caros para serem

corrigidos. Métodos ágeis tratam desse problema organizando o desenvolvimento em

pequenos incrementos, e aplicando programação em pares (no caso do XP) ou outras técnicas

de revisão para remover defeitos de código assim que são gerados. Os métodos ágeis também

desenvolvem testes executáveis para realizar testes de regressão. Testes automatizados são

recomendados pela maioria dos métodos ágeis (BOEHM, 2003).

Métodos tradicionais tratam de corrigir os problemas de desenvolvimento mais

tarde, e a verificação de consistência de requisitos e as especificações de requisitos o mais

cedo no processo de desenvolvimento. Esses métodos também investem em testes

automatizados planejando e preparando a execução dos testes. Isso cria muita documentação

que pode ficar desatualizada pela mudança dos requisitos. Os testes realizados mais tarde

perdem muitas vantagens em relação aos testes realizados mais cedo, como acontece nos

métodos ágeis (BOEHM, 2003).

2.7.10 Clientes

As maiores diferenças entre os métodos ágeis e os conduzidos por planos está em

que o primeiro enfatiza fortemente ter os representantes do cliente dedicados e alocados no

projeto, enquanto os métodos conduzidos por processos conta com acordos, onde o

desenvolvedor trabalhará baseado no plano contratual e as especificações. O risco para os

métodos ágeis é que seja alocado um representante do cliente que esteja mais disponível ao

invés do mais indicado, por isso é necessário estabelecer critérios para tal (BOEHM, 2003).

Os métodos tradicionais, conduzidos por processos, também necessitam de

representantes de cliente, e beneficiam-se também de suas participações em tempo integral e

em loco. O maior desafio para o cliente é manter o controle de falhas em suas mãos para

Page 31: Agile Methods by Alexandre Cota Mol

29

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

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

2.7.11 Desenvolvedores

Fatores críticos para o sucesso dos projetos que utilizam métodos ágeis incluem a

amizade, talento, habilidade e comunicação. Os métodos ágeis e os tradicionais operam

melhores com uma mistura de habilidades e entendimento dos desenvolvedores, mas os

métodos ágeis precisam de uma predominância de pessoas altamente qualificadas (BOEHM,

2003).

Pesado

Metodologia Ágil Típica

Adaptação(Habilidade, Entendimento)

Metodologia Rigorosa

LeveLeve Pesado

Aperfeiçoamento(Processo, Documentação)

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

2.7.12 Cultura

Em uma cultura ágil as pessoas se sentem confortável e motivadas quando há

muitos degraus de liberdade disponíveis para eles definirem e trabalharem nos problemas.

Onde confia-se em cada pessoa e no trabalho que têm a fazer para o sucesso do projeto. Isso

inclui uma procura for tarefas comuns ou não notadas, para completá-las (BOEHM, 2003).

Na cultura conduzida por planos, as pessoas sentem-se confortáveis e motivadas

quando houver políticas e procedimentos que definem o papel deles no empreendimento. Isso

é mais que um ambiente de produção em série onde as tarefas de cada pessoa são bem

definidas. A expectativa é que eles realizarão as tarefas conforme as especificacões, de forma

Page 32: Agile Methods by Alexandre Cota Mol

30

que os produtos do trabalho deles serão integrados facilmente a outros, mesmo tendo um

conhecimento limitado do que os outros estão fazendo (BOEHM, 2003).

Page 33: Agile Methods by Alexandre Cota Mol

31

3 UM COMPARATIVO ENTRE DIVERSOS MÉTODOS

3.1 Scrum

Scrum foi desenvolvido por Ken Schwaber e Jeff Sutherland (SCHWABER, 2002).

Scrum está baseado no conceito de que o desenvolvimento de software não é um processo

definido, mas um processo impírico com transformações complexas de entrada/saída que

pode ou não ser repetido em diferentes circunstâncias (BOEHM, 2003). Este processo resulta

em flexibilidade, adaptabilidade e produtividade. Scrum não define qualquer técnica de

desenvolvimento de software para a fase de implementação. Scrum concentra em como os

membros da equipe deveriam atuar em ordem para produzir sistemas flexíveis em uma

ambiente de constantes mudanças (ABRAHAMSON, 2002).

O Scrum oferece um meio de introduzir os métodos ágeis no ambiente de

disciplinas dos métodos tradicionais. Utilizando o Scrum para um ou mais componentes do

sistema, a gestão pode alcançar a sua efetividade sem alterar completamente a forma que a

organização normalmente realiza negócios. Scrum tem sido um dos poucos métodos ágeis que

tem sido empregado em projetos maiores. Isso tem sido realizado da mesma forma que

empresas integram equipes de produtos. Uma equipe individual do Scrum faz parte de uma

equipe de escalão mais alto de líderes que cuidam de vários produtos. Mantendo a

comunicação e prevenindo conflitos de desenvolvimento é controlado através da equipe de

coordenação (BOHEM, 2003).

O Scrum enfatiza o gerenciamento de projeto, que é feito pelo Scrum Master

(Scrum Mestre). O seu ciclo de desenvolvimento é de 30 dias, chamado Sprint, o qual é

precedido por uma atividade pre-Sprint (pré-Srpint) e outra atividade post-Sprint (pós-Sprint).

Um reunião diária com duração inferior a 30 minutos (geralmente 15 minutos) permite à

equipe monitorar problemas de estado do projeto e de comunicação. A principal idéia do

Scrum é que os sistemas de desenvolvimento envolvem diversos ambientes e variáveis

técnicas (por exemplo requisitos, prazos, recursos e tecnologias) que podem mudar durante o

processo. Isto torna o processo de desenvolvimento imprevisível e complexo, exigindo

flexibilidade dos processos de desenvolvimento de software para que sejam capazes de

responder às mudanças. Como resultado do processo de desenvolvimento, um software

produzido é útil quando entregue (ABRAHAMSON, 2002).

Page 34: Agile Methods by Alexandre Cota Mol

32

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

melhorias de funções e tecnologias imaginadas para o projeto. São feitas duas reuniões – uma

para decidir as melhorias para o próximo Sprint e uma outra para planejar as atividades. Um

Sprint Goal (Meta do Sprint) é estabelecida, a qual serve com um critério mínimo para o

Sprint e as ações para manter a equipe focada no objetivo como um todo, ao invés de focado

somente nas atividades sob sua responsabilidade (ABRAHAMSON, 2002).

O processo do Scrum inclui três fases: pre-game, development e post-game

(ABRAHAMSON, 2002).

A fase pre-game inclui duas sub-fases: Planejamento e Arquitetura/Desenho de

Alto Nível. O Planejamento inclui a definição do software que está sendo desenvolvido. Uma

lista do Product Backlog é criado, contendo os requisitos que são atualmente conhecidos. A

lista do Product Backlog é constantemente atualizada, com items novos ou adicionais,

estimativas mais precisas e novas prioridades. O Planejamento também inclui a definição da

equipe do projeto, ferramentas e outros recursos, riscos e aspectos de controle, necessidades

de treinamentos e gestão de verificação/aprovação. Em toda iteração, o Backlog do produto é

revisado pelo Scrum Team(s) de maneira a obter o compromisso deles para a próxima iteração

(ABRAHAMSON, 2002).

A fase development (também chamada de game phase) é a parte ágil do Scrum.

Esta fase é tratada como uma caixa-preta onde o imprevisível é esperado. As diferenças de

ambiente e as variáveis técnicas (como prazo, qualidade, requisitos, recursos, implementações

tecnológicas, ferramentas e mesmo os métodos de desenvolvimento) identificados no Scrum

são observados e controlados através de várias práticas do Scrum durante os Sprints

(ABRAHAMSON, 2002).

A fase post-game contém o fechamento da liberação do software. Atinge-se essa

fase quando certifica-se que as variáveis de ambientes como os requisitos foram completados.

Neste caso, não se aceita nenhuma melhoria nova ou adicional. O software está pronto para

ser liberado e a preparação para isso é feita, incluindo atividades como integração, testes e

documentação (ABRAHAMSON, 2002).

Scrum introduz os métodos ágeis em um abiente tradicionalmente disciplinado.

Utilizando-se Scrum o gerenciamento pode alcançar a sua efetividade sem alterar

completamente a forma como a organização realiza os seus negócios (BOEHM, 2003).

Scrum é um dos poucos métodos ágeis que tem alcançado progresso com projetos

maiores, da mesma forma como as organizações têm mantido equipes de produtos integradas.

O treinador individual de uma equipe Scrum faz parte de uma equipe de escalão maior que

Page 35: Agile Methods by Alexandre Cota Mol

33

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

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

3.2 Adaptative Software Development (ASD)

ASD foi desenvolvido por James Highsmith. Muitos dos princípios do ASD estão

baseados nas pesquisas do Highsmith sobre métodos iterativos de desenvolvimento. O seu

antecessor é o RADical Software Development (ABRAHAMSON, 2002).

ASD foca principalmente nos problemas em desenvolvimentos complexos e

extensos. O método incentiva o desenvolvimento iterativo incremental (IID), com constante

prototipação. Fundamentalmente o objetivo do ASD é proporcionar um ferramental que

oriente os projetos para prevenir falhas que possam tornar-se em caos, sem suprimir a

emergência e a criatividade (ABRAHAMSON, 2002).

ASD não possui muitos detalhes de como as coisas são feitas, pois somente esboça

as oportunidades que a equipe de desenvolvimento tem que levar em conta. ASD e a sua

filosofia não colaborativa e não prescritiva podem dificultar o seu emprego em

desenvolvimentos grandes, críticos e relativamente estáveis (BOEHM, 2003).

Um projeto ASD é levado a cabo em ciclos de três-fases. Essas fases são:

Speculate (Especular), Collaborate (Colaborar) e Learn (Aprender). Esses ciclos dinâmicos

fornecem um contínuo ciclo de aprendizado e adaptação à fase do projeto. As características

do ciclo de vida do ASD é que esse está focado na missão, baseado na característica, iterativo,

conduzido por riscos e tolerante às mudanças (BOEHM, 2003). Speculate é utilizado ao invés

de Planejamento. Collaborate enfatiza a importância da equipe desenvolver software

altamente alteráveis. Learn realça a necessidade de reconhecer e reagir aos erros, e o fato que

requisitos também podem mudar durante o desenvolvimento (ABRAHAMSON, 2002).

O ASD é explicitamente orientado a componentes ao contrário de orientado a

tarefas. Isso significa que o foco está mais em seus resultados e qualidades que em tarefas e

processos usados para produzir o resultado. A forma que o ASD conduz isso é através dos

clicos de desenvolvimento adaptativo que contém a fase Collaborate, onde muitos

componentes podem estar sob desenvolvimento simultâneo. Planejamento dos cliclos é parte

do processo iterativo, como as definições dos componentes são continuamente refinados para

refletir alguma nova informação, e para suprir as mudanças nos requisitos dos componentes

(ABRAHAMSON, 2002).

Page 36: Agile Methods by Alexandre Cota Mol

34

Bases para ciclos posteriores são obtidos das revisões repetitivas de qualidade, as

quais focam na demonstração de funcionalidade do software desenvolvido durante o ciclo.

Um importante fator das revisões é a presença do cliente, com um grupo de peritos, chamado

de customer focus-group (group focado no cliente). Porém, as revisões de qualidade são

escassaz, pois somente acontecem ao final de cada ciclo. A participação do cliente geralmente

se faz através de seções de joint application development (JAD), que é essencialmente um

workshop, onde desenvolvedores e representantes do cliente reunem-se para discutir as

características do produto desejado, e para melhorar a comunicação. ASD não propõe uma

agenda para as seções de JAD, mas ressalta a importância de que aconteça no início do

projeto (ABRAHAMSON, 2002).

3.3 Lean Development (LD)

O metodologia Lean Development foi desenvolvido por Bob Charette. Evoluiu

baseada em sua experiência na administração de riscos, princípios e visão dos conceitos

industriais magros de Womack, Jones, e Roos1. Ele entende a agilidade como tolerância a

mudança. Um conceito chave para tal é o “risk entrepreneuringship”, que define a habilidade

de transformar um risco em oportunidade (BOEHM, 2003).

O LD é derivado dos princípios de produção enxuta, a qual reestruturou a indústria

de automóveis no início de 1980. Em LD, Bob estende a tradicional visão de mudança como

um risco a ser controlado com práticas de gestão restritiva para uma visão de mudança como a

produção de “oportunidades” através de um empreendimento de risco. Ele vê o LD como um

veículo de implementação para construir organizações tolerantes às mudanças (HIGHSMITH,

2002).

O LD é constituído de três fases: startup (inicial), steady state (estado fixo) e

transition-renewal (transição-renovação). O LD adiciona a dimensão de domínio ou linha de

produtos, onde o software pode ser reutilizado em vários modelos de produtos genéricos. O

planejamento é realizado na fase inicial (startup), onde os casos de negócio e estudos de

viabilidade são completados. Steady state é a fase da concepção de desenho do software

composto de uma série de pequenos ciclos de desenvolvimento em espiral2. Uma vez

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

Page 37: Agile Methods by Alexandre Cota Mol

35

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

documentação é desenvolvida e entregue na fase de transição (BOEHM, 2003).

Highsmith tem dito que LD representa o primeiro dos métodos ágeis a atingir os

alto executivos. As idéias baseadas em estratégicas, riscos e oportunidades ressoam com os

executivos e a administração. No entanto, o LD é um produto proprietário, da empresa de

Charette, ITABHI, o que pode dificultar a sua adoção, pois incorpora muitas das suas

características, mesmo assim, esse é um dos métodos mais focados em avaliar e alcançar valor

empresarial (BOEHM, 2003).

3.4 Crystal

Alistair diz que escolheu construir uma família de metodologias, junto com

princípios, para serem ajustados às necessidades. Crystal não é um kit de metodologia para

você ajuntar por conta própria, mais um conjunto de exemplos que você ajusta às suas

circunstâncias. Crystal é o nome de uma família de metodologias, e como os cristais, possui

diferentes cores e rigidez, referindo-se ao tamanho e ao nível crítico do projeto (COCKBURN,

2006).

As idéias básicas do Crystal incluem princípios que definem as metodologias que

preenchem os requisitos variáveis dos diferentes projetos (ABRAHAMSON, 2002). Essa

família é composta por membros que são alocados conforme as necessidades dos projetos:

Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, etc

(COCKBURN, 2006). Cada membro da família Crystal é identificado por uma cor –

transparente (Clear), amarelo (Yellow), alaranjado (Orange), vermelho (Red), etc - que indica

o tamanho do projeto e a metodologia que será utilizada, quanto mais escura a cor mais

rigorosa será a metodologia (ABRAHAMSON, 2002).

Crystal sugere que a escolha da cor da metodologia seja feita conforme o tamanho

e o nível crítico do projeto. Grandes projetos geralmente requisitam mais coordenação e

metodologias mais rígidas que projetos menores. Quanto mais crítico for o software que está

sendo desenvolvido, mais rigor será necessário (ABRAHAMSON, 2002). Além das cores, o

Crystal utiliza-se de algumas letras para representar potenciais perdas causados por uma falha

no sistema de desenvolvimento de software:

‘C’ de Confort (Conforto) - indica que o sistema falha devido a defeitos

causados por uma perda de credibilidade do usuário, assim como um

Page 38: Agile Methods by Alexandre Cota Mol

36

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

da vida.

‘D’ de Discretionary money (dinheiro disponível para uso conforme

necessário, cujo uso depende de decisão de alguém com poder de decisão).

‘E’ de Essencial money (dinheiro essêncial – dinheiro indispensável,

absolutamente necessário).

‘L’ de Life (vida).

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

projetos.

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

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

os quais requerem uma metodologia mais rígida. Utilizando a metáfora do Crystal, movendo

para a direita corresponde a escolher uma cor mais escura (quartzo transparente, topaz, rubi,

safira) (COCKBURN, 2006).

Na Figura 2, movendo-se para cima na grade corresponde a uma maior

possibilidade de danos ao sistema e o uso de mais rigor e cerimônia. Utilizando-se a metáfora

do Crystal, movendo-se para cima incrementa-se a dureza (em escala de dureza mineral, o

diamante é a mais dura gema, recebe número de dureza 10 - máxima) (COCKBURN, 2006).

Observe que o quadro referente a E6 na Figura 2 está pontilhado, pois o Crystal

Clear não trata dos aspectos relacionados a projetos onde o dinheiro é essencial, mas a equipe

poderá extender o Crystal Clear para isso (COCKBURN, 2006).

C6

Clear

D6

L6

Yellow

C20

D20

E20

L20

Orange

C40

D40

E40

L40

Red

C80

D80

E80

L40

E6

Page 39: Agile Methods by Alexandre Cota Mol

37

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

Cockburn diz não ter trabalhado nisso ou entrevistado pessoas sobre projetos de vida crítica,

de maneiras que ele não possui informação suficiente para dizer exatamente como um projeto

ágil de vida crítica se parece (COCKBURN, 2006).

Há certas regras, características e valores que são comuns para todos os métodos

da família Crystal. O primeiro de todos é que os projetos sempre utilizam-se de IID com um

ciclo máximo de desenvolvimento de quatro meses, mas preferivelmente entre um a três

meses. A ênfase é a comunicação e a cooperação entre as pessoas. As metodologias do

Crystal não limitam a qualquer prática de desenvolvimento, ferramentas ou tipos de produtos

(software), o qual permite também a adoção de, por exemplo, práticas do XP e Scrum

(ABRAHAMSON, 2002).

Uma restrição das metodologias do Crystal é que elas atendem somente a equipes

situadas em um mesmo local (COCKBURN, 2006).

A filosofia principal do Crystal é que o desenvolvimento de software é usualmente

visto como uma iteração de invenção e comunicação, com um objetivo primário de liberações

de software úteis que funcionem, e um objetivo secundário de preparar a próxima iteração

(COCKBURN, 2006).

Membros da família Crystal compartilham :

Valores e princípios.

Afinação (ajuste) rápida.

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

Centrado nas pessoas e na comunicação.

Altamente tolerante.

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

suportar os componentes humanos. Enquanto reconhece-se a existência de culturas variadas

(COCKBURN, 2006).

Dentro da tolerância da família Crystal a equipe pode escolher trabalhar com um

alto nível de cerimônia ou alta disciplina (adotando partes de PSP ou XP, por exemplo)

(COCKBURN, 2006).

Alguns princípios das metodologias do Crystal são (COCKBURN, 2006):

Page 40: Agile Methods by Alexandre Cota Mol

38

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

produzir códigos executáveis mais frenquentemente e com isto utilizar

melhores canais de comunicação entre as pessoas.

Porque todo projeto é diferente e evolui com o passar do tempo, o conjunto

de convenções que a equipe adota também deve ser amoldado e também

tem que evoluir.

O deslocamento dos gargalos no sistema determinam o uso de trabalho

sobreposto e mantenedores de informações insistentes.

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

O projeto deve utilizar desenvolvimento IID, com incrementos de quatro

meses ou menos (e uma forte preferência seria de um a três meses).

A equipe deve realizar reuniões de pré e pós reflexões a cada IID (com

maior preferência por relizar também reflexões na metade).

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

Utilizar técnicas para afinação da metodologia: fazendo entrevistas de

projeto e um seminário da equipe para converter uma metodologia básica a

uma metodologia própria para o projeto.

Utilizar técnicas para suportar seminários de reflexão.

Alistair Cockburn diz que as duas técnicas podem ser substituícas, caso se tenha

uma outra alternativa para alcançar esses objetivos (COCKBURN, 2006).

3.4.1 Crystal Clear

Crystal Clear é uma metodologia para projetos de categoria-D6. Seria possível

extender o Crystal Clear para projetos de categorias E8 ou D10 com alguma atenção para a

comunicação e testes, respectivamente, mas seria difícil extendê-lo além disso, porque

Crystal Clear não contém estrutura de comunicação para mais pessoas que possa

convenientemente trabalhar em uma mesma sala, e nisso falta os elementos de validação

necessários para vida-crítica do sistema (COCKBURN, 2006).

Page 41: Agile Methods by Alexandre Cota Mol

39

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

salas adjacentes (COCKBURN, 2006).

Os papéis que exigem pessoas separadas são:

Patrocinador.

Desenhista-programador sênior.

Desenhista-programadores.

Usuário (pelo menos em tempo parcial).

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

deve ser o especialista do negócio, e qualquer um dos dois, ou várias pessoas, compartilharão

o papel de cobrador dos requisitos.

O Desenhista-programador sênior é a pessoa chave da equipe. O outros

Desenhistas-programadores podem incluir iniciantes e nível médio, dependendo do que o

Desenhista-programador sênior e o problema podem suportar. Portanto contratar pessoas

experientes ajudará.

A política de padrões são (COCKBURN, 2006):

O software é entregue incrementalmente e regularmente, a cada dois ou

três meses.

O progresso é medido por marcos que consistem em entregas de software

ou maiores decisões, ao invés de documentos escritos.

Há alguma quantia de testes de regressão automatizados que testarão as

funções da aplicação.

Há duas revisões do usuário por liberação de software funcional.

Atividades Downstream iniciam-se assim que as Upstream estejam

estáveis para serem revisadas.

Os seminários de afinação do produto e metodologia acontecem no início e

na metade de cada iteração.

Os padrões de política são obrigatórios, mas substituições equivalentes são

permitidas, como seria o caso se o horário de trabalho do Scrum, XP ou as políticas do ASD

fossem usadas (COCKBURN, 2006).

Os produtos de cada iteração que são produzidos incluem:

Liberação em seqüência.

Agendamento das revisões dos usuários ou entregas.

Page 42: Agile Methods by Alexandre Cota Mol

40

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

Esboços de desenhos e notas como necessário.

Rascunhos das telas.

Um modelo de objeto comum.

Código executável.

Código de migração.

Casos de teste.

Manual do usuário.

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

Modelos para o produto funcional.

Padrões de códigos e interface de usuário.

Padrões e detalhes de testes de regressão.

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

consiste a documentação não é detalhado pelo Crystal. Essa é uma decisão da equipe. A

equipe deve decidir como será apresentado as notas do desenho para os futuros membros da

equipe (COCKBURN, 2006).

As ferramentas mais importante que a equipe pode possuir, além de um

compilador, são esses (COCKBURN, 2006):

Sistema de gestão de versão e configuração.

Um ou vários quadros brancos.

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

exempo, a equipe poderia dicidir utilizar as iterações do Scrum ou do DSDM e políticas

dinâmicas de priorização, as reuniões em pé e diárias do Scrum, programação em par do XP,

etc (COCKBURN, 2006).

Crystal Clear é a metodologia mais tolerante, de baixa cerimônia, e para equipes

pequenas (COCKBURN, 2006).

Page 43: Agile Methods by Alexandre Cota Mol

41

3.4.2 Crystal Orange

Crystal Orange é uma metodologia para projetos de categoria-D40: projetos com

até 40 pessoas, alocadas em um mesmo edifício, tralhando no desenvolvimento de um

software que possa causar perda de dinheiro discricionário (COCKBURN, 2006).

Crystal Orange demanda mais estrutura de equipe e mais coordenação da equipe

do que é necessário para um projeto de 20 pessoas, mas não possui estruturas de sub-equipes

que são necessárias para um projeto de 80 pessoas, e não possui as atividades de verificação

de desenho e código que seriam necessários para sistemas de vida-crítica (life-critical)

(COCKBURN, 2006).

O Crystal Orange tem sido caracterizado como útil para projeto de produção

média em uma instalação industrial, e as características desses projetos são (COCKBURN,

2006):

10 a 40 pessoas.

1 a 2 anos de duração.

O tempo para o mecado é importante.

Há necessidade de comunicação com o pessoal atual e futuro da equipe, e

uma necessidade em manter o tempo e o custo baixos.

Sistemas que não são de vida-crítica (life-critical).

Para um projeto do tipo E50 deve-se extender o Crystal Orange com alguns

elementos de verificações adicionais dos testes ao invés de mover-se para o Crystal Red que

destina-se a projetos com 80 pessoas (COCKBURN, 2006):

Os papéis que exigem pessoas separadas são (COCKBURN, 2006):

Patrocinador.

Especialista de negócio.

Especialista de uso.

Facilitador técnico.

Analista/desenhista de negócio.

Gerente de projetos.

Arquiteto.

Mentor de desenho.

Líder desenhista-programador.

Page 44: Agile Methods by Alexandre Cota Mol

42

Outros desenhistas-programadores.

Desenhista de interface de usuário.

Reuse point.

Escritor.

Testador.

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

Planejamento de sistema.

Monitoramento de projeto.

Arquitetura.

Tecnologia.

Funções.

Infra-estrutura.

Testes externos.

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

Documentação de requisitos.

Sequencia de liberações.

Agenda.

Relatórios de estados.

Documento de desenho da interface do usuário.

Modelos comuns de objetos.

Especificações entre equipes.

Manual do usuário.

Código fonte.

Casos de testes.

Código de migração.

Os padrões de políticas são identicas ao Crystal Clear, exceto que o período das

iterações pode ser extendido para três ou quatro meses. E como no Crystal Clear as políticas

padrões são obrigatórias, mas substituição equivalente é permitida (COCKBURN, 2006).

Page 45: Agile Methods by Alexandre Cota Mol

43

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

e detalhes de testes de regressão são deixados como padrões locais para serem criados e

mantidos pela equipe (COCKBURN, 2006).

3.5 Extreme Programming (XP)

XP é um método bem conhecido; que enfatiza a colaboração, criação rápida de

software e iteração mais cedo, e práticas hábeis de desenvolvimento de software. Ele está

fundamentado em quatro valores (LARMAN, 2003):

1. Comunicação: para o XP os problemas de comunicação prejudicam a

maioria dos projetos. A comunicação entre programadores é promovido

através da programação em pares, reuniões em pé, e o planejamento. A

comunicação é promovida através do envolvimento do cliente (LARMAN,

2003). O XP foca em construir um mútuo entendimento do ambiente do

problema de pessoa-para-pessoa com um mínimo de documentação formal

e a máxima interação face-a-face (HIGHSMITH, 2002).

2. Simplicidade: XP recomenda realizar a coisa mais simples que possa

funcionar. Isso não se aplica somente ao desenho do software, mas a

requisitos e ferramentas de gestão de projetos (LARMAN, 2003).

3. Avaliação (feedback): o XP incorpora as mudanças através de uma

avaliação constante (HIGHSMITH, 2002). Essa prática fornece à equipe e

ao cliente uma avaliação do progresso (LARMAN, 2003). Isso permite

esclarecer e redirecionar as exigências (HIGHSMITH, 2002).

4. Coragem (courage): muitos podem definir coragem como fazer algo certo,

até mesmo quando é pressionado para fazer outra coisa. Se aos valores de

uma equipe não estiverem alinhados, seus membros não serão convencidos

que alguma prática é “certa”, e sem convicção, a coragem não parece tão

importante. É difícil trabalhar motivado para lutar por algo que você não

acredita (HIGHSMITH, 2002). É preciso ter coragem para desenvolver

rápido, e fazer as mudanças assim que surgem (LARMAN, 2003).

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

1. Planejamento (Planning Game): são partes desse planejamento o curto

prazo, iterações de três semanas, atualização freqüente dos planos, e

Page 46: Agile Methods by Alexandre Cota Mol

44

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

um requisito e é descrita em simples cartões). Define o ponto de iteração

entre os clientes e os desenvolvedores, especifacando as responsabilidades

de ambos. O Planejamento inclui o plano de liberações até a liberação final

(HIGHSMITH, 2002).

2. Liberações pequenas e frequentes (Small Releases): toda liberação deve ser

a menor possível, contendo os requisitos mais valiosos para o negócio

(HIGHSMITH, 2002).

3. Metáforas do sistema (Metaphor): XP utiliza os termos metáfora em uma

tentativa de tentar definir um tema global coerente que desenvolvedores e

clientes possam relacionar-se a ele. A metáfora descreve a abrangência do

projeto, enquanto são utilizadas histórias (stories) para descrever

características individuais do projeto.

4. Desenho simples (Simple Design): possui duas partes (1) desenhe as

funcionalidades que tenham sido definidas, ao contrário de fazê-lo para

potenciais funcionalidades futuras, e (2) crie o melhor desenho – como o

mais simples - que permita entregar a funcionalidade. Não importa o

futuro, crie o melhor e mais simples desenho que possa ser entregue hoje

(HIGHSMITH, 2002).

5. Testando (Testing): XP utiliza dois tipos de testes: de unidade e funcional.

Entretanto a prática para os testes de unidade é desenvolvê-los antes de

escrever o código do software. Além disso os testes devem ser

automatizados. Uma vez que o código do software é escrito, é

imediatamente submetido aos testes (HIGHSMITH, 2002).

6. Recodificação frequente (Refactoring): esse é um dos aspectos que

diferencia o XP de outros métodos (HIGHSMITH, 2002). Enquanto RAD

está frequentemente envolvido com um pequeno desenho ou nenhum, XP

considera o desenho continuo, com muito mais atenção à recodificação

(HIGHSMITH, 2002). Para Kent Beck adicionar novas funcionalidades e

recodificar são duas atividades diferentes. A recodificação não alterará a

funcionalidade do software, mas melhora a sua estrutura interna (BECK,

2004).

7. Programação em par (Pair Programming): é um diálogo entre duas pessoas

sentadas enfrente ao mesmo computador, codificando ou programando

Page 47: Agile Methods by Alexandre Cota Mol

45

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

revisando e pensando, criam um contínuo e dinâmico intercâmbio,

refletindo como programar melhor. Programação em par é uma das poucas

práticas de engenharia de software que possui uma aceitação predominante

e que tem sido bem medidos, é inspeção de software. Os seus melhores

resultados são em inspeções em iterações colaborativas para o rápido

aprendizado muito mais que descobrir defeitos. Os seus piores resultados,

são em inspeções que degeneram-se em seções de ataques às pessoas

improdutivas (HIGHSMITH, 2002).

8. Propriedade coletiva (Collective Ownership): concede a qualquer um que

pertença à equipe do projeto a permissão para alterar qualquer código a

qualquer tempo. Essa prática encoraja a equipe inteira a trabalhar de forma

colaborativa (HIGHSMITH, 2002).

9. Integração contínua (Continuous Integration): construções diárias se

tornaram a regra em muitras empresas de software. Enquanto os

especialistas de XP dizem que as integrações diáras são ineficientes,

optando, ao contrário, por construções frequentes em um par de horas. Os

ciclos de avaliação do XP são rápidos – desenvolve o caso de teste,

codifica, integra e testa.

10. 40-horas por semana: corresponde ao desenvolvimento sustentável

(sustainable development) que é uma frase do Manifesto. As horas não são

tudo, mas a prática de 40-horas estabelece uma filosofia, que corresponde

geralmente a uma semana de trabalho (8 horas por dia, por 5 dias na

semana), e se há necessidade de trabalhar além desse período então há

alguma coisa errada, pois devido ao cansaço possívelmente as pessoas

estarão produzindo um trabalho peor. Ainda para Highsmith, sustentável

(sustainable) corresponde ao comprometimento voluntário das pessoas, se

elas gostam de ir para o trabalho, se elas terminam o dia com prazer. As

pessoas têm que trabalhar, mas elas somente obtém ótima performance

estando comprometidas com o projeto e o compromisso só surge de um

senso de propósito (HIGHSMITH, 2002).

11. Toda a equipe junta (On-site Customer): esta prática pede contínuo

envolvimento do usuário com a equipe do projeto (HIGHSMITH, 2002). A

contribuição do cliente inclui uma explicação detalhada das características

Page 48: Agile Methods by Alexandre Cota Mol

46

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

esclarecimentos, e escrever testes de aceitação em colaboração com o

programador (LARMAN, 2003).

12. Padrões de codificação (Coding Standards): com a propriedade coletiva,

frequente recodificacão, e trocas habituais de pares de programação, todos

precisam seguir o mesmo estilo de codificação (LARMAN, 2003).

A média de duração das iterações está entre uma e três semanas, o que é menor que

no Scrum. O XP também possui baixa escala de cerimônia, pois possui somente um pequeno

conjunto, informal, de artefatos, como cartões indexados para resumir características

requisitadas, chamados de story cards (cartões de história) (LARMAN, 2003).

Uma boa atualização da descrição original do XP foi a declaração das

aplicabilidades conhecidas: tinha sido provado que projetos envolvendo aproximadamente 10

desenvolvedores ou menos, e não era aprovado para sistemas críticos. Não obstante tem sido

aplicado com equipes maiores (LARMAN, 2003).

O XP criado por Kent Beck é um método IID que dá ênfase à satisfação do cliente

através do rápido desenvolvimento de software de alto valor, técnicas hábeis e sustentáveis de

desenvolvimento de software, e resposta flexível às mudanças. É indicado para projetos de

equipes relativamente pequenas, normalmente com datas de entregas inferiores a um ano. As

iterações são pequenas – usualmente uma a três semanas (LARMAN, 2003).

XP provê métodos explicitos para programadores, de maneiras que eles podem

mais confidentemente responder às mudanças de requisitos, mesmo mais tarde no projeto, e

ainda produzir código de qualidade. Esses incluem desenvolvimento conduzido por testes,

reescrita do código fonte para melhorar a consistência interna (refactoring), programação em

par, e integração contínua, entre outros. Em contraste a maioria dos métodos, algumas práticas

do XP são verdadeiramente adotadas pelos desenvolvedores (LARMAN, 2003).

XP é muito orientado à comunicação e à equipe; clientes, desenvolvedores, e

gerentes formam a equipe trabalhando em uma mesma sala de projeto para rapidamente

entregar software com alto valor para o negócio (LARMAN, 2003).

Embora muitos métodos evolutivos evitam detalhar especificações e planos que

cubram o ciclo completo da versão, a maioria deles incentivam documentá-los pelo menos

para a próxima iteração. Em contraste o XP enfatiza a comunicação oral para requisitos e

desenhos (LARMAN, 2003).

Page 49: Agile Methods by Alexandre Cota Mol

47

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

premissa é que há um novo, estruturado, e sustentável caminho para seguir com um foco na

produção de codificação rápida e comunicação oral, enquanto evita-se a maioria do overhead

(LARMAN, 2003).

A palavra “extreme” (extremo) no XP originou-se da convicção do Beck que é

muito difícil ter boas coisas no desenvolvimento de software. Que é: adote as boas práticas

conhecidas e “gire o discador até o 10”, ou o nível extremo (LARMAN, 2003). Por exemplo:

Testes são bons, assim que escreva unidades de testes para (quase) todo

código, e testes de aceitação para todas as características.

Revisões de códigos são bons – mesmo próximos das datas de criação –

assim que faça revisões dos códigos em tempo real e todo tempo via

programação em par.

Integração frequente do código com todo os membros da equipe é bom,

assim que faça isso 24/7 com um processo de integração automatizado,

continuo em um computador dedicado.

Iterações curtas e avaliação cedo são bons, assim que iterações com uma

ou duas semanas de duração, se possível.

Maior envolvimento do cliente é bom, assim que traga o cliente para o

projeto em tempo integral, alocado na mesma sala comum do projeto.

Comunicação é bom, assim que tenha todo mundo sentado juntos,

programação em par, incluído o cliente no local, e envolva o cliente

frequentemente no planejamento, guiando e avaliando.

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

codificar, e desenhar. Escute os clientes de perto, enquanto registra os os seus requisitos.

Desenvolva casos de testes . Códifique os objetos (usando pragramação em pares). Desenhe

(ou reconstrua o código fonte sem mudar a funcionalidade) como adicionar mais objetos ao

sistema (HIGHSMITH, 2002). Alguns comentários sobre os ciclos de vida do XP, conforme

definidos por Beck (LARMAN, 2003):

1. Como muitos projetos, XP pode iniciar com exploração. Alguns story

cards (cartões de histórias) podem ser escritos, com estimativas por alto.

Page 50: Agile Methods by Alexandre Cota Mol

48

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

cliente e desenvolvedores completam o story cards com estimativas por

alto, e então decidem o que fazer para a próxima liberação.

3. Para a próxima iteração, no Iteration Planning Game (Planejamento de

Iteração), clientes pegam histórias para implementar. Eles escolhem as

histórias baseados no estado atual, e em suas últimas prioridades para a

liberação. Desenvolvedores então quebram as histórias em várias atividades

pequenas e estimadas. Finalmente uma revisão de todas as atividades

estimadas. Horas extras são seriamente desencorajadas no XP; isto é visto

como um sinal de um projeto não funcional, com aumento da insatisfação

das pessoas, e diminuição da produtividade e qualidade.

4. Desenvolvedores implementa as histórias dentro do período acordado,

continualmente colaborando com o clientes em testes e detalhes de

requisitos.

5. Se não concluído para a liberação, retorna para o item 3 para a próxima

iteração.

Aqui alguns enganos e erros comuns que são cometidos com a utilização do XP

(LARMAN, 2003):

Não ter o cliente no local; ao contrário, utiliza-se de especificações escritas

para a próxima iteração – é normal e aceitável criar especificações escritas

para as iterações se o método adotado é o Scrum, UP, Evo, etc. Um projeto

interativo ou ágil que toma essa decisão funcionam bem, mas é melhor

caracterizado como sendo baseado em outro método que permita requisitos

escritos. O XP evita especificações detalhadas, utiliza-se de comunicação

oral dos requisitos, e ter o cliente no local.

Aplicar um subconjunto de práticas descompensadas; personalizar antes de

utilizar – muitas práticas do XP trabalham como um todo sinérgico, e é um

engano remover uma prática que compensa outra. É por isso que Beck

recomenda fazer tudo que recomenda o XP antes de tentar personalizá-lo.

Não escrever primeiro os testes de unidade – é uma importante prática do

XP. Escrever os testes primeiro influencia como a pessoa concebe,

esclarece e simplifica o desenho.

Page 51: Agile Methods by Alexandre Cota Mol

49

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

qual é o critério de aceitação, e quais as histórias entram em uma liberação

e iteração.

O cliente não ser responsável pelos testes – o cliente não faz os testes de

aceitação, é um dos erros mais comuns.

Ter somente um cliente alocado – o livro original do XP fala de um cliente

alocado na sala de projeto. Kent Beck e líderes do XP têm melhorado isso,

enfatizando que a equipe do cliente necessita ser considerado como um

todo, com requisitos chegando de talvez muitos clientes participando em

Planning Games. Por isso eles têm substituido a prática de cliente alocado

(onsite customer) com toda a equipe junto (whole team together).

Permanecer com um mesmo par na programação em pares por muito

tempo – os pares no XP mudam frequentemente, frequentemente em dois

dias ou menos. Variações também ajudam a disseminar os conhecimentos.

Clientes ou gerentes perseguidores – os programadores irão progredir

lentamente.

Equipe de Garantia da Qualidade não integrado – muitas organizações

possuem uma equipe de garantia da qualidade separado. Uma ou mais

pessoas da equipe de garantia de qualidade necessitam ser envolvidos no

projeto durante todo tempo, normalmente devem escrever os testes de

aceitação em colaboração com o cliente.

Desenvolvimento posterior a documentação está errado – XP não é anti-

documentação, mas prefere a programação se isso for suficiente para obter

sucesso. XP pode apoiar a criação de documentação do desenho para

refletir a base do código existente, uma vez que o programa esteja

completo.

Diagramação é ruim – embora o conselho do XP seja modelagem ou

diagramação mínima, como quinze atas antes de programar, muito menos é

aceitável.

Somente pares de programação jovens – alguns projetos de XP foram

prejudicados quanto a programação de pares quando a maioria dos

participantes eram jovens, sem a paciência ou maturidade para suportar o

trabalho junto de outros.

Page 52: Agile Methods by Alexandre Cota Mol

50

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

um mais rápido ou mais experiente que o seu parceiro deve ser sensível e

compreensível o suficiente para entender a diferença do seu parceiro, e

diminuir a velocidade das suas atividades e explicações.

Não desejar aprender; não desejar explicar — para obter sucesso com a

programação em par, uma atitude aberta para aprender e explicar é

requerido.

Reuniões em pé com duração muito longa ou sem foco – mantenha a

duração menor que vinte minutos, e um estado das atividades, não uma

discussão do desenho e requisitos.

Não ter nenhum testador de aceitação dedicado – uma pessoa é necessária

para trabalhar com o cliente para transformar os seus critérios de aceitação

em testes executáveis. Uma excessão é para projetos muito pequenos –

nesse caso poderia ser uma dedicação de meio período.

O cliente alocado e o líder do projeto não estão alinhados – o cliente e o

líder do projeto precisam estar alinhados.

Iterações muito longas – no XP as iterações deveriam ser de uma a três

semanas.

As iterações não estão limitadas a um bloco de tempo – é um engano

expandir a iteração quando parece que as metas não podem ser atingidas

no prazo original. A estratégia preferida seria remover ou simplificar as

metas da iteração. Então analisar por que as estimativas estavam fora.

A iteração não termina em uma linha de base integrada e testada – uma

iteração não é considerada um sucesso somente se terminar na data

prevista. A meta é que todo o software tenha sido integrado, testado e

gerado uma linha de base.

Planejamento preditivo – é um engano criar, ao começo do projeto, um

plano acreditando que se dispõe extamente das quantidade de iterações que

existirão ao longo do projeto, e o que acontecerá em cada uma delas. Isso é

contrastado com um planejamento ágil, um planejamento adaptável. A

equipe XP e o cliente planejam a próxima iteração, e então planejam as

adaptações de iteração a iteração, baseados na avaliação atual.

Page 53: Agile Methods by Alexandre Cota Mol

51

3.6 Dynamic Systems Development Method (DSDM)

O Dynamic Systems Development Method (DSDM) originou-se em 1994 e se

tornou meta-modelo número um na Inglaterra para desenvolvimentos rápidos de aplicações

(Rapid Application Development – RAD) . É um meta-modelo não proprietário para

desenvolvimentos RAD. DSDM é mantido pelo DSDM Consortium (Consórcio DSDM).

DSDM possui uma significativa infra-estrutura, incluindo vários livros, cursos e grupos de

usuários em vários países, embora a maioria dos usuários estão na Europa (BOHEM, 2003).

Para o DSDM é fundamental fixar tempo e recursos para então ajustar a

quantidade de funcionalidades adequadamente, ao invés de fixar a quantia de funcionalidades

em produto para ajustar o tempo e recursos para tal (ABRAHAMSON, 2002).

O DSDM consiste de cinco fases (ABRAHAMSON, 2002):

1. Feasibility (estudo de viabilidade) : é onde a conveniência de DSDM para o

determinado projeto é avaliado, julgando-se pelo tipo de projeto, assuntos

organizacionais e pessoal, a decisão é tomada, para usar DSDM ou não.

Além disso, essa fase está relacionada às possibilidades técnicas de realizar

o projeto, e os riscos disso. São preparados um relatório de viabilidade e

um plano de descrição para o desenvolvimento. Opcionalmente é

construído um protótipo rápido, caso o negócio e a tecnologia não sejam

bem conhecidos. Essa fase deve demorar poucas semanas.

2. Business Study (estudo do negócio) : é onde as características essenciais do

negócio e tecnologia são analisados. A idéia básica é organizar workshops,

com um número suficiente de clientes experientes, para que sejam capazes

de considerar todos os aspectos relevantes do sistema, e concordar com as

prioridades. Os processos de negócio e os tipos de usuários são descritos

Business Area Definition (Definição da Área de Negócio). É produzido

também a Definição de Arquitetura, e o Esboço do Plano de Prototipação.

A identificação dos tipos de usuários afetados ajudam a envolver o cliente,

bem como as pessoas chaves. Um alto nível de descrição dos processos são

apresentados no Business Area Definition em um formato satisfatório –

Modelo de Entidade e Relacionamento, Modelos de Objetos de Negócio,

etc. Outros dois artefatos são produzidos: Architecture Definition

(Definição de Arquitetura), e o Outline Prototyping Plan (Esboço do Plano

de Prototipação). A Definição de Arquitetura é o primeiro esboço do

Page 54: Agile Methods by Alexandre Cota Mol

52

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

DSDM. O Esboço do Plano de Prototipação deverá declarar as Estratégias

de Prototipação para os estágios seguintes, e um Plano para a Gestão de

Configuração.

3. Functional Model Iteration (modelo funcional de iteração) : essa é a

primeira fase iterativa incremental. Em toda iteração, os conteúdos e as

ações são planejadas para as iterações futuras, as iterações acontecem e os

resultados são analisados para futuras iterações. Analises e codificações são

realizadas. Protótipos são construídos. As experiências ganhas são

utilizadas para melhorar os modelos de análise. Os protótipos são

gradualmente melhorados. Um Modelo Funcional é produzido contendo o

código do protótipo e os modelos de análise. Testes também são essenciais

nessa fase. São também produzidos os seguintes artefatos: Prioritized

Functions (Funções Priorizadas) com a lista das funções que são entregues

no final de cada iteração. Functional Prototyping Review Documents

(Documentos de Revisão de Prototipação Funcionais) coleciona os

comentários dos usuários sobre o atual incremento, que funcionam como

entradas para subsequentes iterações. Non-Functional Requirements

(Requisitos Não-Funcionais) são listados, principalmente para serem

negociados na próxima fase. Risk Analysis of Further Development

(Analise de Riscos de Desenvolvimentos Futuros) é um documento

importante na fase do modelo funcional, pois na próxima fase será mais

difícil tratar os problemas encontrados.

4. Design and Build Iteration (projeto e iteração de construção) : é aqui que o

software é construído. Seu produto final é um software testado que

preenche pelo menos um mínimo de requisitos acordados. O Desenho e a

construção são iterativos, e o desenho e os protótipos funcionais são

revistos pelos usuários, e os desenvolvimentos seguintes sào baseados nos

comentários dos usuários.

5. Implementation (implementação) : é a fase final onde o software é

transferido do ambiente de desenvolvimento para o ambiente de produção.

Os usuários são treinados, e o software entregue a eles. A implementação

pode ser também um fase iterativa. O manual do usuário e uma revisão do

projeto são escritos. Se o software atende a todos os requisitos então

Page 55: Agile Methods by Alexandre Cota Mol

53

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

requisitos que não foram atendidos então o processo pode ser executado

novamente do começo ao fim. Se somente algumas funcionalidades críticas

foram otimidas, o processo pode ser executado novamente desde a iteração

do modelo funcional até as fases adiantes. Se alguns assuntos técnicos não

puderam ser implementados devido a limitação de tempo, agora eles

poderão ser feitos a partir da fase de desenho e construção.

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

As três últimas fases são incrementais e iterativas. São as fases onde o trabalho de

desenvolvimento é feito (ABRAHAMSON, 2002).

Os ciclos do DSDM são pré-definidos por um período de tempo e as iterações

devem terminar dentro desse período. O tempo permitido para cada iteração a ser gasto é

planejado com antecedência. A duração típica de cada iteração está entre poucas dia e algumas

semanas (ABRAHAMSON, 2002).

O ciclo de vida do DSDM fornece forte ênfase às atividades de gestão de projeto.

Planejar é inerente a cada fase, como os planos evoluem baseados nos incrementos e

resultados desses. São definidos planos detalhados. A gestão do tempo é primordial para o

planejamento, monitoramento, e controle. Horários e custos são geralmente controlados

constantemente, com os requisitos a serem implementados. Requisitos são priorizados

utilizando-se de MoSCoW (Must have, Should have, Could have, Want)3. Artefatos são

definidos e descritos para cada fase do DSDM. É fornecido um processo de gestão de risco.

DSDM é projetado para equipes pequenas, mas pode ser escalado para qualquer tamanho de

equipe (BOHEM, 2003).

O DSDM define os usuários e desenvolvedores (ABRAHAMSON, 2002):

1. Desenvolvedores e desenvolvedores sênior: o nível sênior basea-se na

experiência nas atividades sob sua responsabilidade e indica um nível de

liderança na equipe, e apoiam todos da equipe de desenvolvimento –

analistas, desenhistas, programadores e testadores.

2. Coordenador técnico: definem a arquitetura do software. São responsáveis

pela qualidade do projeto, controle do projeto técnico como a utilização da

gestão de configuração.

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

Page 56: Agile Methods by Alexandre Cota Mol

54

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

dos objetivos do negócio, o software e o projeto. A atividade do visionário

é garantir que os requisitos essenciais sejam descobertos o mais cedo

possível, e que o projeto mantenha-se alinhado a esses requisitos.

4. Executivo Patrocinador: é uma pessoa e usuário da organização que tem a

autoridade e responsabilidade financeira. É quem tem toma a última

decisão.

O DSDM define a ideologia e as bases para todas as suas atividades através das

nove práticas (ABRAHAMSON, 2002):

1. É imperativo o involvimento de usuários ativos.

2. A equipe DSDM deve ter autonomia para tomar decisões.

3. O foco está frequentemente na entrega de produtos.

4. A condição a ser atendida para os propósitos do negócio é o critério

essencial para aceitação das liberações.

5. O desenvolvimento iterativo e incremental é necessário para convergir em

uma solução precisa de negócio.

6. Todas as mudanças durante o desenvolvimento são reversíveis.

7. Requisitos são a base em uma alto nível.

8. Testar e integrar através das iterações (lifecycle).

9. Um cooperativismo e uma colaboração proxima compartilhada por todos

os participantes é essencial.

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

desenvolvedor e um usuário - a seis participantes, e pode existir muitas equipes em um

mesmo projeto. DSDM tem sido aplicado em projetos pequenos e grandes. O pré-requisito

para que DSDM possa ser utilizado em um grande projeto, é que um software grande pode ser

dividido em componentes para podem ser desenvolvidos em pequenas equipes

(ABRAHAMSON, 2002).

DSDM tem muitas semelhanças com RUP e TSP, e possui uma quantidade

significativa de estrutura e conta com seu uso de gestão de riscos para realizar para alcançar

maior agilidade que com processos tradicionais. DSDM possui um ênfase maior em uma

interpretação minimalista das suas orientações que no RUP ou TSP (BOHEM, 2003).

Page 57: Agile Methods by Alexandre Cota Mol

55

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

documentação disponíveis para implementá-lo. O método torna-se mais semelhante aos

métodos de desenvolvimento tradicionais e pode ser facilmente adotado em organizações

baseadas em processos (BOHEM, 2003).

3.7 Feature-Driven Development (FDD)

FDD foca em processos simples, modelagem eficiente, e pequena, ciclos iterativos

que entreguem valores para o cliente. Cresceu através das experiências de Jeff DeLuca e Peter

Coad no desenvolvimento de uma aplicação comercial complexa de empréstimos para o

banco de Singapura em 1997-1998. FDD depende consideravelmente de pessoas com bom

conhecimento da área da aplicação (domain knowledge), projeto e desenvolvimento. A sua

meta principal é ter o processo somente como apóio ao invés de dirigir a equipe (BOHEM,

2003).

FDD é um método ágil e adaptativo para desenvolvimento de software. FDD

consiste de cinco processos seqüenciais e provê os métodos, técnicas e diretrizes necessárias

para os patrocinadores do projeto entregarem o software. FDD inclui pápeis, artefatos, metas e

linhas de base necessárias no projeto. FDD se diz adequado para o desenvolvimento de

sistemas críticos. FDD foi usado pela primeira vez em projetos grandes e complexos para

bancos nos anos noventa (PALMER, 2002).

O desenho e a construção do sistema acontecem durante os cinco processos

seqüenciais. Nessa iteração de desenho e construção o FDD permite desenvolvimento ágil

com adaptações rápidas para mudança posteriores nos requisitos e as necessidades de negócio.

Normalmente a duração de uma iteração é de uma a três semanas (PALMER, 2002).

FDD consiste de um conjunto de melhores práticas que são (PALMER, 2002):

Domain Object Modeling (Modelo de Objetos do Domínio): exploração e

explicação do domínio do problema.

Development by Feature (Desenvolvimento por Característica):

desenvolvimento e acompanhamento do progresso através de uma lista de

pequenas funcionalidades decompostas e os benefícios das funções do

cliente.

Page 58: Agile Methods by Alexandre Cota Mol

56

Individual Class Ownership (Propriedade da Classe Individual): cada

classe tem uma única pessoa como responsável pela consistência,

performance e integridade referencial da classe.

Feature Teams (Características da Equipe): refere-se a equipes pequenas

que são formadas dinâmicamente.

Inspection (Inspeção): refere-se ao use a inspeção para garantir a utilização

de melhores práticas e mecanismos de detecção de defeitos

Regular Builds (Construção Regular): construções regulares formam a

linha de base para a qual as características são adicionadas.

Configuration Management (Gestão de Configuração): identificação e

acompanhamento histórico das últimas versões de cada arquivo de código

completado.

Progress Reporting (Relatório de Progresso): o progresso é reportado para

todos os níveis da organização, baseado no trabalho completado.

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

1. Develop and Overall Model (Desenvolva o Modelo Global): nesse

processo os especialistas do domínio estão cientes do escopo, contexto e

requisitos do sistema. É provável que os requisitos documentados como

casos de uso ou especificações funcionais existam nesta fase. Porém, o

FDD não trata especificamente da obtenção e gestão dos requisitos. A

descrição em alto-nível do sistema é feita pelos especialistas do domínio

através de uma seção de walktrhough. O domínio global é dividido em

diferentes domínios de áreas, e seções de walktrhough mais detalhados

acontecem. Após cada walkthrough a equipe de desenvolvimento trabalha

em grupos menores para produzir modelos de objetos para a área de

domínio em pauta. A equipe de desenvolvimento então decide sobre o

modelo de objeto para cada área de domínio. Simultaneamente um modelo

global é construído para o sistema (PALMER, 2002).

2. Build a Features List (Construa uma Lista de Características): os

walkthroughs, modelos de objetos e a documentação dos requisitos são

bons insumos para a elaboração de uma lista de características para o

sistema em desenvolvimento. A equipe apresenta nessa lista os “benefícios

Page 59: Agile Methods by Alexandre Cota Mol

57

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

agrupadas por áreas de domínio.

3. Plan by Feature (Planejar por Características): inclui a criação de um plano

de alto-nível. O conjunto de características após sequenciadas de acordo

com suas prioridades e dependências, são atribuídas ao Programador Chefe.

As classes identificadas no processo “Develop and Overall Model” são

atribuídas aos desenvolvedores. Um cronograma também poderá ser

definido para o conjunto de características.

4. Design by Feature and Build by Feature (Projetar por Característica e

Construir por Característica): um pequeno grupo de características é

selecionado do conjunto de características. A equipe de desenvolvimento

das características selecionadas é constituído pelos proprietários das

classes. Esse processo é interativo, onde as características selecionadas são

produzidas. Poderá haver várias equipes trabalhando em características

específicas. Ess processo inclui atividades de como desenho de inspeção,

codificação, testes, integração e inspeção de código.

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

1. Key roles (Papéis Chaves): essa categoria possui seis papéis:

i. Project Manager (Gerente de Projeto): é o administrador financeiro e

líder do projeto. Tem a última palavra na definição do escopo,

cronograma e equipe do projeto.

ii. Chief Architect (Arquiteto Chefe): é responsável pelo desenho global

do sistema e a realização de seções de desenho com a equipe, e é quem

tomas a decisão final sobre todos os assuntos relacionados ao desenho.

iii. Development Manager (Gerente de Desenvolvimento): lidera o

desenvolvimento diário e deve resolver qualquer conflito que possa

ocorrer na equipe. É responsável por resolver problemas de recursos.

iv. Chief Programmer (Programador Chefe): é um desenvolvedor

experiente, que participa na análise dos requisitos, e o desenho do

projeto. É responsável por liderar pequenas equipes na análise, desenho

e desenvolvimento das novas características. Seleciona as

características do conjunto que serão desenvolvidas na nova iteração.

Page 60: Agile Methods by Alexandre Cota Mol

58

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

programador chefe nas atividades de desenho, codificação, testes e

documentação. É responsável pelo desenvolvimento das classes que lhe

foram atribuídas.

vi. Domain Experts (Especialista de Domínio): pode ser um usuário, um

cliente, um patrocinador, um analista de negócio ou uma mistura

desses. Deve conhecer como os diferentes requisitos do sistema em

desenvolvimento deveriam funcionar. Eles passam esse conhecimento

para os desenvolvedores. Pode haver também o Domain Manager

(Gerente de Domínio) que liderará o Domain Experts e resolver suas

diferenças de opinião.

2. Supporting roles (Papéis de Suporte): essa categoria possui cinco papéis:

i. Release Manager (Gerente de Liberação): controla o progresso do

desenvolvimento, revendo os relatórios de progresso dos

programadores chefes e coordenando perquenas reuniões de progresso

com eles. Ele reporta o progresso para o Project Manager.

ii. Language Lawyer/Language Guru (Especialista em Linguagem): um

membro da equipe responsável profundamente conhecedor de uma

linguagem de programação ou tecnologia específica. É

consideravelmente importante quando a equipe está experimentando

uma nova tecnologia.

iii. Build Engineer (Engenheiro de Construção): é a pessoa responsável

pelas configurações, manutenção e executar o processo de construção,

incluindo as atividades de gerenciamento do controle de versão do

sistema e a publicação da documentação.

iv. Toolsmith (Ferramentista): é um papél para construção de pequenas

ferramentas para desenvolvimento, teste e conversão de dados.

Também pode trabalhar na configuração e manutenção de banco de

dados e sítios Internet para propósitos específicos do projeto.

v. System Administrator (Administrador de Sistema): suas atividades são

configurar, gerenciar e diagnosticar servidores, redes, estações de

trabalho dos ambientes de desenvolvimento e testes.

3. Additional roles (Papéis Adicionais): essa categoria possui três papéis:

Page 61: Agile Methods by Alexandre Cota Mol

59

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

atende os requisitos do cliente.

ii. Deployers: trabalha com a conversão de dados existentes para o

farmato requisitado pelo novo sistema, e participando no entrega de

novas liberações.

iii. Technical Writers (Redator Técnico): prepara a documentação do

usuário.

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

organizações deveriam adotá-lo gradualmente, até que seja inteiramente utilizado com o

avanço do projeto.

Podem ser projetados e implementados múltiplos pacotes através de várias

equipes, permitindo ao FDD ser empregado a equipes e projetos maiores muito mais

facilmente que alguns dos outros métodos ágeis. O FDD enfatiza a importância de bons

profissionais. Enquanto todos os métodos ágeis geralmente aderem às técnicas orientadas a

objetos (OO), FDD especificamente define seus processos e papéis com a tecnolgia OO em

mente (BOHEM, 2003).

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

Baseado em Barry Bohem e Richard Turner (BOEHM, 2003) é apresentado a

seguir um comparativo entre os diversos métodos ágeis apresentados até aqui, além de

métodos conduzidos por processos. Os próprios autores reconhecem que pode haver

discordância com a classificação, mas consideram também que as suas classificações estão

próximas da realidade e podem ser úteis para uma avaliação geral dos métodos listados nas

tabelas a seguir. Nas tabelas foi adicionado o Rational Unified Process (RUP) para se

conseguir um comparativo mais amplo.

Na Tabela 1 a agilidade de cada método é classificada em ordem crescente, do

mais ágil até os conduzido por planos. Os métodos também estão classificados pelo nível de

formalismo exigido, quanto mais alto o nível maior a exigência por planejamento e

documentação (BOEHM, 2003).

Agilidade Método Formalismo1o Scrum 12o Adaptive Software Development (ASD) 1, 2 e 3

Page 62: Agile Methods by Alexandre Cota Mol

60

3o Lean Development (LD) 1, 2 e 34o Crystal 1, 2 e 35o Extreme Programming (XP) 2 e 36o Dynamic Systems Development Method (DSDM) 2, 3 e 47o Rational Unified Process (RUP) 2, 3 e 48o Feature-Driven Development (FDD) 3

Legenda do nível de formalismo1 Muito baixo2 Baixo3 Médio4 Alto5 Muito Alto

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

Page 63: Agile Methods by Alexandre Cota Mol

61

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

orientação específica.

MétodoToda a

empresaUnidades de

negócio

Projetos com multi-

equipes

Projeto com equipe única

Individual

Scrum N/A ~ ~ ~ ~

ASD ~ ~ ~ ~ N/A

LD ~ + ~ N/A N/A

Crystal N/A ~ + + ~

XP N/A ~ N/A + +

DSDM ~ + + + ~

RUP N/A ~ + + N/A

FDD N/A ~ + ~ ~

Legenda: tipo de orientaçãoN/A Não aplicável

~ Parcial+ Detalhada

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

Page 64: Agile Methods by Alexandre Cota Mol

62

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

específica.

Método Conceituação Requisitos DesenhoDesenvolvi-

mentoManutenção

Scrum ~ ~ ~ ~ ~

ASD ~ ~ ~ ~ ~

LD ~ ~ ~ N/A ~

Crystal ~ ~ ~ ~ ~

XP N/A + + + +

DSDM + + ~ ~ ~

RUP + + + + +

FDD N/A N/A + + ~

Legenda: tipo de orientaçãoN/A Não aplicável

~ Parcial+ Detalhada

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

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

MétodoGestão de processo

Práticas técnicas

Risco / Oportunidade

Práticas de medição

Interface com o cliente

Scrum + N/A ~ N/A ~

ASD ~ N/A + N/A ~

LD ~ a + N/A + N/A ~

Crystal ~ a + ~ a + + ~ ~ a +

XP ~ + ~ ~ +

DSDM + ~ + ~ ~

RUP ~ ~ + ~ N/A

FDD ~ + N/A ~ ~

Legenda: tipo de orientaçãoN/A Não aplicável

~ Parcial+ Detalhada

TAB. 4 – Formalismo imposto por cada método (adaptação de BOEHM, 2003).

Page 65: Agile Methods by Alexandre Cota Mol

63

4 CONCLUSÃO

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

software, gostariam que a produção de software fosse feita mais rapidamente, com qualidade e

isento de erros, e é por isso que os processos de melhores práticas visam atender a essas

expectativas, independente se os métodos utilizados são os ágeis ou tradicionais. Cada um

desses métodos possui vantagens e desvantagens. Normalmente as vantagens têm sido

ressaltadas e divulgadas pelos defensores e simpatizantes do próprio método. No

desenvolvimento deste trabalho foi identificado que nem sempre isso é verdade. Esses

defensores e simpatizantes normalmente ressaltam as suas vantagens através do que

consideram ser desvantagens dos outros métodos. Como disseram Barry Boehm e Richard

Turner (BOEHM, 2003; tradução nossa):

Agilidade e disciplina são de fato valores complementares no desenvolvimento de software. Desenvolvedores conduzidos por planos (que utilizam os métodos tradicionais) devem ser ágeis; desenvolvedores ágeis (que utilizam métodos ágeis) devem ser disciplinados. A chave do sucesso é encontrar o equilíbrio entre os dois, o qual varia de projeto para projeto de acordo às circunstâncias e os riscos envolvidos. Desenvolvedores, atraídos para fins opostos através de argumentos comovidos, têm que aprender a dar a cada um o seu valor devido.

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

Software, ao prefaciar (BOEHM, 2003; tradução nossa) diz o seguinte:

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

Page 66: Agile Methods by Alexandre Cota Mol

64

Jim Highsmith diz em seu livro “Agile Project Management: Creating Innovative

Products” (HIGHSMITH, 2004) que agilidade é uma forma de pensar, ao contrário de um

conjunto de práticas e processos, e que equipes ágeis possuem o equilíbrio entre flexibilidade

e organização. Em princípio seria desejável que todo projeto pudesse contar com agilidade,

mas nem sempre equipes ágeis possuem o equilíbrio entre flexibilidade e organização, a

menos que um certo grau de formalismo dos processos e controle sejam adotados, o que

normalmente acontece nos métodos tradicionais, e que têm sido recomendados por alguns

métodos ágeis, como o Crystal e o DSDM.

Através do desenvolvimento deste trabalho ficou claro que existem várias outras

alternativas ao XP e ao RUP, e que, além dos métodos citados aqui, existem outros métodos

que merecem menção: Evo, Agile Modeling (AM), Pragmatic Programming (PP), Open

Source Software (OSS), Personal Software Process (PSP) e Team Software Process (TSP).

As fronteiras entre os métodos ágeis e os tradicionais têm sido reduzidas, pois

métodos como o Crystal, DSDM e FDD, classificados como métodos ágeis, trazem muitas

das características dos métodos tradicionais, como o RUP, sendo adaptáveis aos projetos onde

são aplicados. Apesar de serem citados somente esses métodos ágeis, aqui na conclusão, no

capítulo 3 podemos identificar outros métodos ágeis que possuem algumas características

similares aos métodos tradicionais. Para citar um exemplo de como as fronteiras estão sendo

reduzidas, podemos observar que o Crystal ganha mais formalismo à medida que é

empregado em equipes maiores. Os seus processos se tornam mais rígidos e documentados.

Em contrapartida, observa-se que alguns métodos tradicionais têm reduzido o seu volume de

documentação exigida, ganhando agilidade com a adoção de ferramentas que automatizam

esse processo.

Outros fatores também devem ser considerados, pois nem sempre o volume de

documentação é a causa fundamental da perda de agilidade, assim como processos muito

informais poderão dificultar a contratação dos serviços do desenvolvedor de software por

novos clientes. Alguns fatores poderão contribuir para o aumento da agilidade, como: adotar

padrões de desenvolvimento de software; utilizar ferramentas de desenvolvimento

automatizadas e integradas entre si; contratação de pessoal altamente qualificado; equipe com

cultura mais homogênea; gestão de treinamento e do conhecimento; processos motivacionais;

ambiente de trabalho agradável; liderança ativa; entre outros.

Page 67: Agile Methods by Alexandre Cota Mol

65

REFERÊNCIAS

ABRAHAMSON, Pekka; SALO, Outi; RONKAINEN, Jussi; WARSTA, Juhani. Agile software development methods: review and analysis. Oulu: Espoo, 2002. VTT Publications 478. 107p.

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

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

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

CUNNINGHAM, Ward. Manifesto for agile software development. Disponível em: <http://www.agilemanifesto.org>. Acesso em: 10 jan. 2007.

HIGHSMITH, Jim. Agile project managment: creating innovative products. Addison Wesley Professional, 2004. 312 p. ISBN 0321219775.

HIGHSMITH, Jim. Agile software development ecosystems. Addison Wesley Professional, 2002. 448 p. ISBN 0201760436.

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

PALMER, Stephen R.; FELSING, John M. A practical guide to Feature-Driven Development. New Jersey: Printice-Hall, 2002. ISBN 0130676152.

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

TATE, Kevin. Sustainable software development: an agile perspective. Addison Wesley Professional, 2005. 264 p. ISBN 0321286081.