• Nenhum resultado encontrado

T27-MétodosÁgeis-ManifestoÁgil,XP,FDD,DSDM

N/A
N/A
Protected

Academic year: 2021

Share "T27-MétodosÁgeis-ManifestoÁgil,XP,FDD,DSDM"

Copied!
5
0
0

Texto

(1)

E

EN

NG

GE

EN

N

HA

H

AR

R

IA

I

A

D

DE

E

S

SO

OF

FT

TW

WA

AR

R

E

E

1 27 3 Metodologias de Desenvolvimento Ágil de Software: XP, FDD e DSDM

T

T

ó

ó

p

p

i

i

c

c

o

o

2

2

7

7

M

M

e

e

t

t

o

o

d

d

o

o

l

l

o

o

g

g

i

i

a

a

s

s

d

d

e

e

D

D

e

e

s

s

e

e

n

n

v

v

o

o

l

l

v

v

i

i

m

m

e

e

n

n

t

t

o

o

Á

Á

g

g

i

i

l

l

d

d

e

e

S

S

o

o

f

f

t

t

w

w

a

a

r

r

e

e

:

:

X

X

P

P

,

,

F

F

D

D

D

D

e

e

D

D

S

S

D

D

M

M

27.1 DESENVOLVIMENTO ÁGIL [Pressman em 2007]

Em 2001, Kent Beck, e mais 16 outros notáveis desenvolvedores, produtores e consultores (conhecidos como a “Aliança Ágil”) assinaram o o “Manifesto for Agile Software Development” (Manifesto para Desenvolvimento Ágil de Software). Eles declararam:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Por meio desse trabalho, passamos a valorizar:

• Indivíduos e interações em vez de processos e ferramentas. • Software funcionando em vez de documentação abrangente. • Colaboração do cliente em vez de negociação de contratos. • Resposta a modificações em vez de seguir um plano.

Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda. Conceito de Métodos Ágeis

Métodos Ágeis é uma coleção de metodologias baseada na prática para modelagem efetiva de sistemas baseados em software, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia. É uma filosofia onde muitas metodologias se encaixam. A Aliança Ágil [Agile, 2003. et al.] define 12 princípios para aqueles que querem alcançar agilidade:

1. Nossa maior prioridade é satisfazer ao cliente desde o início por meio de entrega contínua de software valioso.

2. Modificações de requisitos são bem-vindas, mesmo que tardias no desenvolvimento. Os processos ágeis aproveitam as modificações como vantagens para a competitividade do cliente.

3. Entrega de software funcionando frequentemente, a cada duas semanas até dois meses, de preferência no menor espaço de termpo.

4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.

5. Construção de projetos em torno de indivíduos motivados. Forneça-lhes ambiente e apoio que precisam e confie que eles farão o trabalho.

6. O método mais eficiente de levar informação para e dentro de uma equipe de desenvolvimento é a conversa face a face.

7. Software funcionando é a principal medida de progresso.

8. Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante, indefinidamente.

(2)

Processo Ágil

Um processo ágil de software deve ser adaptado incrementalmente. Uma equipe ágil requer o feedback do cliente, de modo que adaptações apropriadas possam ser feitas. Uma estratégia de desenvolvimento incremental pode ser instituída com um protótipo operacional (protótipos executáveis), que devem ser entregues em curtos períodos de tempo. Essa abordagem iterativa ajuda o cliente a avaliar o incremento de software regularmente.

Aplicação da Metodologia Ágil

Esse Manifesto ocorreu para ser um contraponto as Metodologias de Desenvolvimento Prescritivas. Por exemplo, enquanto que o RUP e CMMI são extremamentes rígidos com altos níveis de controle e forte documentação, as metodologias ágeis caminham ao contrário. Destacamos que, mesmo assim, ela não inflige a uma sólida prática da Engenharia de Software.

C COONNTTRROOLLEE E EqquuiippeessGGrraannddeess A AllttooRRiiggoorr A ACCOOMMPPAANNHHAARR E EqquuiippeessMMééddiiaasseePPeeqquueennaass EEqquuLLiipIIpBBeeEEssRRPPDDeeAAqqDDuueeEEnnaass ( (mmeennoorrqquuee1100ppeessssooaass))

Um dos pontos de aplicação e de destaque na Metodologia Ágil é a liberdade dada para as equipes de desenvolvimento. A declaração de Ken Schwaber define isso da seguinte forma: “A equipe seleciona quanto trabalho acredita que pode realizar dentro da iteração, e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto alguém de fora assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitação das responsabilidades de cumprir os compromissos que ela própria estabeleceu”.

27.2 XP (EXTREME PROGRAMMING)

O modelo ágil mais conhecido é o XP. Usa preferencialmente a abordagem orientada a objetos.

R

(3)

Atividades

O XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades, como foi mostrado anteriormente: Planejamento, Projeto, Codificação e Teste.

Existe uma grande ênfase para o trabalho em duplas, onde um analista experiente trabalha com um novato. O novato trabalha na programação e o analista na revisão.

27.3 FDD – Feature Driven Development (Desenvolvimento guiado por Características) O FDD foi concebido por Peter Coad, teve como premissa criar um modelo prático de processo para a Engenharia de Software Orientada a Objetos.

No entanto, Stephen Palmer e John Felsing aprimoraram o modelo descrevendo um processo ágil e adaptativo que pode ser aplicado a projetos de software tanto a projetos de médio como de grande porte.

A Função Características

A função “características” é relativamente pequena e deve ser acertada diretamente com o cliente:

• As “características” podem ser pequenos blocos de funcionalidade, para que usuários e desenvolvedores possuam melhor controle e entendimento de todo o processo.

• As “características” são organizadas em agrupamento hierárquico relacionada ao negócio. • A equipe estabelece metas, normalmente a cada duas semanas para o desenvolvimento

de novas “características”. Processos

O FDD é o método ágil que mais enfatiza as diretrizes e técnicas de gestão de projetos. O projeto é claro para todos os envolvidos.

O FDD define seis processos (ou marcas de referência) durante o projeto e implementação de uma “característica”:

• Ciclo de desenvolvimento do código; • Projeto;

• Inspeção do projeto; • Codificação;

• Inspeção do código; e

• Promoção para a construção. Cargos e Responsabilidades

• Gerente de projeto (Project Manager) • Arquiteto líder (Chief architect)

• Gerente de desenvolvimento (Development Manager) • Programador líder (Chief programmer)

(4)

Boas Práticas

• Modelagem de objetos de domínio (Domain Object Modeling) o Exploração e explicação do problema do domínio o Resulta em um arcabouço.

• Desenvolver por funcionalidade (Developing by feature)

o Desenvolvimento e acompanhamento do progresso através de da lista de funcionalidades.

• Proprietários de classes individuais (Individual class ownership) o Cada classe possui um único desenvolvedor responsável. • Equipe de funcionalidades (Feature teams)

o Formação de equipes pequenas e dinâmicas. o Inspeção (Inspection)

o Uso dos melhores métodos conhecidos de detecção de erros. • Construções freqüentes (Regular Builds)

o Garantir que existe um sistema sempre disponível e de-monstrável. • Administração de Configuração (Configuration Manager)

o Habilita acompanhamento do histórico do código-fonte.

27.4 DSDM - Dynamic Systems Development Method (Método Dinâmico de Desenvolvimento de Sistemas)

Características

• Progenitor do XP;

• Estrutura para Desenvolvimento Rápido de Aplicações (RAD – Rapid Application Development);

• Fixa tempo e recursos ajustando a quantia de funcionalidades; • Pequenas equipes;

• Suporta mudanças nos requisitos durante o ciclo de vida.

Fases

O DSDM consiste de 5 fases:

• Estudo das possibilidades (Feasibility study) • Estudo dos negócios (Business study)

• Iteração do modelo funcional (Functional model iteration) • Iteração de projeto e construção (Design and build iteration) • Implementação final (Final implementation)

(5)

Cargos e Responsabilidades

• Desenvolvedores (Developers)

• Desenvolvedores Sêniors (Senior Developers) • Coordenador Técnico (Technical Coordinator • Usuário Embaixador (Ambassador User) • Usuário Consultor (Adviser User)

• Visionário (Visionary)

• Executivo responsável (Executive Sponsor) • Especialista do domínio (Domain experts) • Gerente do domínio (Domain manager) Práticas

• Usuário sempre envolvido

• Equipe do DSDM autorizada a tomar decisões • Foco na frequente entrega de produtos

• Adaptação ao negócio é o critério para entregas. “Construa o produto certo antes de você construí-lo corretamente”.

• Desenvolvimento iterativo e incremental

• Mudanças são reversíveis utilizando pequenas iterações • Requisitos são acompanhados em alto nível

• Testes integrados ao ciclo de vida BIBLIOGRAFIA

Referências

Documentos relacionados

Onde ninguém conhece a doença existem estigmas importantes, decorrentes de muitos anos, como é o caso da hanseníase que exigem que o indivíduo muitas vezes

Bem, a resposta “mais exata”, do ponto de vista estatístico, uma vez que o tempo de viagem é uma grandeza aleatória (o tempo de viagem varia em função de fatores

Link para pesquisadores, trabalhos acadêmicos, projetos e cursos relacionados à modernização da gestão pública. Assessoria de Imprensa: +55 (31) 3247-5575 / +55

“Fico muito obrigado a devolver-lhes este favor” ou, sinteticamente, “obrigado”!.. Esta dissertação resgata os últimos cinco séculos deste duplo

Ele pode ser usado para desenhar gráficos de funções matemáticas, permitindo realizar, além do gráfico, outros registros de representações matemáticas como, por exemplo,

menos a correspondente ao ensino elementar fundamental.. Concordam ainda que a educação deverá capacitor todas as pessoas a participar efectivamente de uma sociedade livre, favorecer

A vacina não deve ser administrada a imunodeprimidos, grávidas, menores de 1 ano de idade e hipersensibilidade a algum dos componentes da vacina e terapêutica concomitante

[r]