Metodologias geis

Sabrina Schrhaus
"Manifesto Para o Desenvolvimento
gil de Software"
reunio entre 17 gurus da comunidade de
desenvolvimento

Realizada entre os dias 11 e 13 de
fevereiro de 2001

Estao de esqui nas montanhas de
Utah, Estados Unidos.

Manifesto gil (Princpios)
Indivduos e interaes => mais importantes que
processos e ferramentas.
Software funcionando => mais importante do que
documentao completa e detalhada.
Colaborao com o cliente => mais importante do que
negociao de contratos.
Adaptao a mudanas => mais importante do que seguir
o plano inicial.

Evento ocorrido em 2001
WebSite: http://www.agilemanifesto.org
Metodologias geis
(agile software development ecosystems - ASDEs)
XP (eXtreme Programming)
DSDM ( Dynamic Systems Development Method)
Famlia Crystal
ASD (Adaptive Software Development)
SCRUM
FDD (Feature-driven development)
LD ( Lean Development )
Open Source

Obs: Todos os seus autores com exceo do autor de LD e OpenSource participaram do Manifesto
gil e portanto possuem princpios em comum.
XP (eXtreme Programming)
XP (eXtreme Programming)
Projeto C3 (Chrysler) - Kent Beck, Ward Cunningham and Ron Jeffries
(1996)
http://www.xprogramming.org
Valores:
Comunicao
Simplicidade
Feedback
Coragem
12 Prticas:
Pair Programnig, Refactoring, Simple Design, Test-driven
development
Collective Ownership, Coding Standard, Continuous
Integration, Sustainable Pace
Customer tests, Whole Team, Planning Game, Small
Releases, Metaphor

DSDM (Dynamic Systems Development Method)
Mtodo Dinmico de Desenvolvimento de Sistemas
DSDM (Dynamic Systems Development Method)
Mtodo Dinmico de Desenvolvimento de Sistemas
Proprietria do consrcio DSDM (Reino Unido, 1994)
http://www.dsdm.org/
Ciclo:
Estudo de viabilidade
Estudo do negcio (workshops)
3 ciclos em paralelo, entrelaados
Ciclo do modelo funcional -> anlise e prottipos
Ciclo de design e build -> engenharia do produto
Ciclo de implementao -> implantao operacional
Princpios:
Iteraes fixas (2-6 semanas)
Releases freqentes
Qualidade total
Adaptabilidade a mudanas de requisitos

DSDM
Progenitor do XP
Framework para desenvolvimento rpido
de aplicaes (RAD)
Fixa tempo e recursos ajustando a
quantia de funcionalidades
Pequenas equipes
Suporta mudanas nos requisitos durante
o ciclo de vida

DSDM
O DSDM consiste de 5 fases:


Funcional
Model
Iteration
Feasibility
Review Study
Design
And Build
Iteration
Implementation
DSDM - Cargos e Responsabilidades
Desenvolvedores (Developers)
Desenvolvedores Sniores (Senior Developers)
Coordenador Tcnico (Technical Coordinator
Usurio Embaixador (Ambassador User)
Usurio Consultor (Adviser User)
Visionrio (Visionary)
Executivo responsvel (Executive Sponsor)
Especialsta do domnio (Domain experts)
Gerente do domnio (Domain manager)

DSDM -
Usurio sempre envolvido
Equipe do DSDM autorizada a tomar decises
Foco na freqente entrega de produtos
Adaptao ao negcio o critrio para entregas
Construa o produto certo antes de voc constru-lo
corretamente
Desenvolvimento iterativo e incremental
Mudanas so reversveis utilizando pequenas iteraes
Requisitos so acompanhados em alto nvel
Testes integrados ao ciclo de vida

Crystal
Famlia Crystal/Clear
Alistair Cockburn (IBM anos 90)
http://alistair.cockburn.us/
Cada projeto uma metodologia.
4 parmetros determinam o mtodo de desenvolvimento:
Tamanho da equipe
Localizao geogrfica
Criticalidade/Segurana
Recursos
A recomendao de quais os artefatos, papis e ciclo de
desenvolvimento de um projeto parametrizada.
O processo revisado no fim de cada iterao.

Crystal/Clear
Na verdade um conjunto de metodologias

Voltada para projetos pequenos (at 6 desenvolvedores)

Especificao e projeto so feitos informalmente usando
quadros publicamente visveis.

A metodologia e propositalmente pouco definida. Para
permitir que cada ONG implemente as atividades que
lhes paream mais adequadas. Fornecendo um mnimo
de suporte til a documentao e comunicao.
ASD (Adaptive Software Development)
Desenvolvimento Adaptvel de Software
ASD (Adaptive Software Development)
Desenvolvimento Adaptvel de Software
Jim Highsmith (1997)
http://www.adaptivesd.com/
Sistemas complexos => Resultados imprevisveis
Ciclo:
Colaborao EspeculaoAprendizado
Abordagem:
Do it wrong the first time: erre cedo, corrija cedo, no
potencialize mal-entendidos.
Good enough quality: melhor compromisso entre
dimenses de qualidade (extrnseca e intrnseca) para os
recursos disponveis.
Mecnica: RAD (rapid application development), sesses
JAD (joint application development) com o cliente.

ASD
Ciclos de 3 fases
ASD
Iterativo e incremental
Sistemas grandes e complexos
Framework para evitar o caos
Cliente sempre presente:
Desenvolvimento de aplicaes em conjunto (Joint Application
development JAD)

ASD
Especular
Fixa prazos e objetivos
Define um plano baseado em componentes
Colaborar
Construo concorrente de vrios componentes
Aprender
Repetitivas revises de qualidade e foco na demostrano das
funcionalidades desenvolvidas (Learning loop)
Presena do cliente e especialistas do domnio

Os ciclos duram de 4 a 8 semanas
ASD
Orientado a misses
Atividades so justificadas atravs de uma misso, que pode mudar ao longo
do projeto
Baseado em componentes
Construir o sistema em pequenos pedaos
Iterativo
Desenvolvimento em cascata (Waterfall) s funciona em ambientes bem
definidos e compreendidos.
foco em refazer do que fazer corretamente j na primeira vez.

Prazos pr-fixados

Tolerncia a mudanas (Change-tolerant)
As mudanas so freqentes
sempre melhor estar pronto a adapt-las do que control-las
Constante avaliao de quais componentes podem mudar

Orientado a riscos (Risk driver)
Itens de alto risco so desenvolvidos primeiro



SCRUM
SCRUM
Jeff Sutherland, Ken Schwaber (1993)
http://www.controlchaos.com/

Sprints de 30 dias
Estabilizar requisitos em cada iterao

Scrum (reunio de status) diria (15 min)
Guia o desenvolvimento daquele dia

Foco em gerncia e tracking
Pode ser combinado com mtodos mais prescritivos (ex:
XP@scrum)


XP X SCRUM
SCRUM com princpios semelhantes ao XP:
Equipes pequenas
Requisitos instveis ou desconhecidos
Iteraes curtas para prover visibilidade ao desenvolvimento.
SCRUM com dimenses diferentes de XP:
Scrum divide o desenvolvimento em sprints de 30 dias e reunies dirias de
15 minutos.
As equipes so formadas por pessoas com competncias diferentes:
projetistas, programadores, engenheiros e gerentes de qualidade.
Scrum possui um mecanismo de informao de status atualizado
continuamente e a diviso de tarefas explcita.
SCRUM e XP so complementares pois Scrum prove prticas de
gerenciamento enquanto que XP prove prticas integradas de
engenharia de SW.

FDD(Feature-driven development)
Desenvolvimento Orientado a Funcionalidades
FDD(Feature-driven development)
Desenvolvimento Orientado a Funcionalidades
Jeff DeLuca, Peter Coad
http://thecoadletter.com/download/fddguide/
5 processos:
1- Modelo geral (arquitetura)
2 -Lista de funcionalidades:
Levanta requisitos para todo o projeto
3 Planejamento por funcionalidades:
Define escopo de cada iterao (quais funcionalidades)
Forma times para desenvolver cada funcionalidade.
(A cada iterao):
4 Projeto por Funcionalidades
5 - Construo por Funcionalidades


O FDD consiste de 5 processos principais:


FDD- Cargos e Responsabilidades
Principais
Gerente de projeto (Project Manager)
Arquiteto lder (Chief architect)
Gerente de desenvolvimento (Development Manager)
Programador lder (Chief programmer)
Proprietrio de classe (Class owner)
Especialista do domnio (Domain experts)
Gerente do domnio (Domain manager)
De apoio
Gerente de verso (Release manager)
Guru de linguagem (Language lawyer/language guru)
Engenheiro de construo (Build engineer)
Ferramenteiro (Toolsmith)
Administrador de sistemas (System Administrator)

Adicionais
Testadores (Testers)
Instaladores (Deployers)
Escritores tcnicos (Technical writes)


FDD Boas Prticas
Modelagem de objetos de domnio
Explorao e explicao do problema do domnio
Resulta em um framework
Desenvolver por funcionalidade
Desenvolvimento e acompanhamento do progresso atravs de da lista de
funcionalidades.
Proprietrios de classes individuais
Cada classe possui um nico desenvolvedor responsvel
Equipe de funcionalidades
Formao de equipes pequenas e dinmicas.
Inspeo (Inspection)
Uso dos melhores mtodos conhecidos de deteco de erros.
Releases freqentes
Garantir que existe um sistema sempre disponvel e demonstrvel.
Administrao de Configurao
Habilita acompanhamento do histrico do cdigo-fonte.


LD ( Lean Development )
LD ( Lean Development )
Mary Poppendieck (2000)
http://www.poppendieck.com/

Focado na identificao de gargalos no processo de
desenvolvimento de software
Metfora (boa) de fbrica
Empresta idias de
Qualidade Total, (Deming, anos 50)
Lean Production (Japo, anos 50)
Teoria de Sistemas Dinmicos (MIT, anos 60)
Lean Construction (adaptabilidade na construo civil,
anos 90)

Open Source
Richard Stallman (anos 80), Linus Torvalds (anos 90)
http://www.opensource.org/
Inicialmente, para software bsico
Maintainer:
Orienta o desenvolvimento
Decide o qu vai entrar no software oficial
Catedral X Bazar
Catedral: releases pouco freqentes,
desenvolvimento centralizado (GNU, BSD)
Bazar: releases freqentes, desenvolvimento mais
espalhado (Linux kernel, apache.org)


O futuro das metodologias geis
% de empresas com mais da metade dos projetos
definidos como geis
2001: 21%
2002: 34%
2003 (previso): 50%
Metodologias geis mais usadas
XP: 38%
FDD (Feature-Driven Development): 23%
ASD (Adaptive Software Development): 22%
DSDM: 19%
Complexidade dos projetos similar (rigorosas X
geis), geis trabalham com prazos similares, mas
equipes muito menores.
http://www.cutter.com/freestuff/apmupdate.pdf