Manifesto gil - Princpios

USP UNIVERSIDADE DO ESTADO DE SO PAULO

Mtodos geis
Alunos: Rogrio Guaraci dos Santos - rgsantos@ime.usp.br Giulian Dalton Luz - gdaltonl@ime.usp.br

Indivduos e interaes so 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. WebSite: http://www.agilemanifesto.org/
2

Mtodos geis (AM) uma coleo de metodologias baseada na prtica para modelagem efetiva de sistemas baseados em software. uma filosofia onde muitas metodologias se encaixam. As metodologias geis aplicam uma coleo de prticas, guiadas por princpios e valores que podem ser aplicados por profissionais de software no dia a dia.

O que so os Modelos geis?

Um modelo gil um modelo bom o suficiente, nada mais, o que implica que ele exibe as seguintes caractersticas:
1. Ele atende seu propsito 2. Ele inteligvel. 3. Ele suficientemente preciso. 4. Ele suficientemente consistente. 5. Ele suficientemente detalhado. 6. Ele prov um valor positivo. 7. Ele to simples quanto possvel.
3 4

O que (e no ) mtodos geis?

1. uma atitude, no um processo prescritivo. 2. um suplemento aos mtodos existentes, ele no uma metodologia completa. 3. uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto. 4. uma coisa que funciona na prtica, no teoria acadmica.
5

O que (e no ) mtodos geis? (cont.)

5. para o desenvolvedor mdio, mas no um substituto de pessoas competentes. 6. No um ataque documentao, pelo contrrio aconselha a criao de documentos que tem valor. 7. No um ataque s ferramentas CASE.

SCRUM
Processo de Desenvolvimento de Software

Scrum um processo para construir software incrementalmente em ambientes complexos, onde os requisitos no so claros ou mudam com muita freqncia.

Em Rugby, Scrum um time de oito integrantes que trabalham em conjunto para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e o time inteiro focando num nico objetivo.

O objetivo do Scrum fornecer um processo conveniente para projetos e desenvolvimento orientado a objetos. A metodologia baseada em princpios semelhantes aos de XP: equipes pequenas, requisitos pouco estveis ou desconhecidos, e iteraes curtas para promover visibilidade para o desenvolvimento.
9 10

No entanto, as dimenses em Scrum diferem de XP. Scrum divide o desenvolvimento em Sprints de 30 dias. Equipes pequenas, de at 7 pessoas, so formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidade (os requisitos, em outras palavras) definidas no incio de cada Sprint. A equipe toda responsvel pelo desenvolvimento desta funcionalidade
11

Todo dia, feita uma reunio de 15 minutos onde o time expes gerncia o que ser feito no prximo dia, e nestas reunies os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento.

12

Fases Sprint

Reunies Dirias
Todos respondem s perguntas:
O que voc realizou desde a ltima reunio? Quais problemas voc enfrentou? Em que voc trabalhar at a prxima reunio?

Benefcios:
Maior integrao entre os membros da equipe Rpida soluo de problemas
Promovem o compartilhamento de conhecimento

Progresso medido continuamente

Minimizao de riscos

Scrum interessante porque fornece um mecanismo de informao de status que atualizado continuamente, e porque utiliza a diviso de tarefas dentro da equipe de forma explicita. Scrum e XP so complementares pois Scrum prov prticas geis de gerenciamento enquanto XP prov prticas integradas de engenharia de software.

13

14

Fases
Planejamento Sprints Ciclos Encerramento
Sprint Backlog Reunio diria do Scrum

Fases de encerramento
24h

Iniciada quando todos os aspectos so satisfatrios (tempo, competitividade, requisitos, qualidade, custo)
30 dias

Acmulo de tarefas pela equipe

Atividades:
Testes de integrao Testes de sistema Documentao do usurio Preparao de material de treinamento Preparao de material de marketing
16

Levantamento de prioridades do produto

Nova demonstrao de funcionalidade

15

Qualidade, Gerenciamento e Testes

Passos e papis bem definidos Gerenciamento de riscos Revises freqentes / dirias Definio de padres Realizao de testes Elaborao de documentao

Controles Backlog Release/Melhoria Mudanas Problemas Solues

Crystal
Processo de Desenvolvimento de Software

17

18

 Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado por Cockburn. As premissas apresentadas para a existncia deste conjunto so:

Todo projeto tem necessidades, convenes e uma metodologia diferentes. O funcionamento do projeto influenciado por fatores humanos, e h melhora neste quando os indivduos produzem melhor. Comunicao melhor e lanamentos freqentes reduzem a necessidade de construir produtos intermedirios do processo
19 20

Crystal/Clear uma metodologia direcionada a projetos pequenos, com equipes de at 6 desenvolvedores. Assim como com SCRUM, os membros da equipe tem especialidades distintas. Existe uma forte nfase na comunicao entre os membros do grupo. Existem outras metodologias Crystal para grupos maiores.
21

Toda a especificao e projeto so feitos informalmente, utilizando quadros publicamente visveis. Os requisitos so elaborados utilizando casos de uso, um conceito similar s estrias de usurio em XP, onde so enunciados os requisitos como tarefas e um processo para sua execuo.
22

As entregas das novas verses de software so feitos em incrementos regulares de um ms, e existem alguns subprodutos do processo que so responsabilidade de membros especficos do projeto.

Grande parte da metodologia pouco definida, e segundo o autor, isto proposital; a idia de Crystal/Clear permitir que cada organizao implemente as atividades que lhe parecem adequadas, fornecendo um mnimo de suporte til do ponto de vista de comunicao e documentos
23 24

A famlia Crystal de Mtodos

Criada por Alistair Cockburn http://alistair.cockburn.us/crystal Editor da srie Agile Software Development da Addison-Wesley.

Feature Driven Development

Desenvolvimento orientado a funcionalidades

Stephen Palmer & John Felsing

25

2002
26

FDD - Caractersticas
Mtodo gil e adaptativo; Foco nas fases de desenho e construo Interage com outras metodologias No exige nenhum processo especfico de modelagem Possui desenvolvimento iterativo Enfatiza aspectos de qualidade durante o processo e inclui entregas freqentes e tangveis Suporta desenvolvimento gil com rpidas adaptaes s mudanas de requisitos e necessidades do mercado
27

FDD - Processos
O FDD consiste de 5 processos principais:

28

FDD Processos (Cont.)

Desenvolver um modelo compreensvel (Develop an
overall model)

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) Especialsta do domnio (Domain experts) Gerente do domnio (Domain manager)

Construir uma lista de funcionalidades (Build a

features list)

Planejar por funcionalidade (Plan By Feature) Projetar por funcionalidade (Design by feature) Construir por funcionalidade (Build by feature)

29

30

FDD - Cargos e Responsabilidades (Cont.)

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)

FDD - Boas Prticas

Modelagem de objetos de domnio (Domain Object Modeling) Explorao e explicao do problema do domnio Resulta em um arcabouo Desenvolver por funcionalidade (Developing by feature) Desenvolvimento e acompanhamento do progresso atravs de da lista de funcionalidades. Proprietrios de classes individuais (Individual class ownership) Cada classe possui um nico desenvolvedor responsvel

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

32

FDD - Boas Prticas (Cont.)

Equipe de funcionalidades (Feature teams) Formao de equipes pequenas e dinmicas. Inspeo (Inspection) Uso dos melhores mtodos conhecidos de deteco de erros. Construes freqentes (Regular Builds) Garantir que existe um sistema sempre disponvel e demonstrvel. Administrao de Configurao (Configuration Manager) Habilita acompanhamento do histrico do cdigo-fonte..

Dynamic Systems Development Method (DSDM)

Mtodo dinmico de desenvolvimento de sistemas
DSDM Consortium - 1994 Jennifer Stapleton - 1997
33 34

DSDM - Caractersticas
Progenitor do XP Arcabouo 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 - Fases
O DSDM consiste de 5 fases:
Feasibility Review Study Funcional Model Iteration

Implementation Design And Build Iteration

36

35

DSDM Fases (Cont.)

Estudo das possibilidades (Feasibility study) Estudo dos negcios (Business study) Iterao do modelo funcional (Functional model iteration) Iterao de projeto e construo (Design and build iteration) Implementao final (Final 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)

37

38

DSDM - Prticas
Usurio sempre envolvido Equipe do DSDM autorizada a tomar decises Foco na frequente 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

Adaptive Software Development Desenvolvimento Adaptvel de Software

James A. Highsmith III 2000
39 40

ASD - Caractersticas
Iterativo e incremental Sistemas grandes e complexos Arcabouo para evitar o caos Cliente sempre presente Desenvolvimento de aplicaes em conjunto (Joint Application development JAD)

ASD - Fases
O ASD possui ciclos de 3 fases:

41

42

ASD Fases (Cont.)

Especular (Speculate) Fixa prazos e objetivos Define um plano baseado em componentes Colaborar (Collaborate) Construo concorrente de vrios componentes Aprender (Learn) 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
43

ASD - Propriedades
Orientado a misses (Misson-driven)
Atividades so justificadas atravs de uma misso, que pode mudar ao longo do projeto

Baseado em componentes (Component-based)

Construir o sistema em pequenos pedaos

Iterativo (Iterative)
Desenvolvimento em cascata (Waterfall) s funciona em ambientes bem definidos e compreendidos. O ASD possui foco em refazer do que fazer corretamente j na primeira vez

44

ASD Propriedades (Cont.)

Prazos pr-fixados (Time-boxed)
Fora os participantes do projeto a definir severamente decises do projeto logo cedo.

ASD - Cargos e Responsabilidades

Este mtodo no descreve cargos em detalhes Executivo responsvel (Executive Sponsor) Participantes de uma sesso (workshop) do desenvolvimento de aplicaes em conjunto (JAD) Facilitador (Facilitator) Liderar e planejar as sesses Escriba (Scribe) Efetuar anotaes Cliente (Customer) Sempre presente Gerente de Projetos (Project Manager) Desenvolvedores (Developers)
45 46

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

Outras Metodologias geis

Extreme Programming Rational Unified Process (RUP)
Considerado uma metodologia gil por alguns autores

Links Relacionados
http://www.agilemanifesto.org/ http://www.dcc.unicamp.br/~ra022247/Arquivos/scrum.pdf http://www.poli.usp.br/pro/procsoft/tproepusp04.pdf http://alistair.cockburn.us/crystal http://www.featuredrivendevelopment.com/ http://www.dsdm.org/ http://www.adaptivesd.com/ http://www.rspa.com/spi/process-agile.html http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf

Open Source Software Development Agile Modeling Pragmatic Programming

www.ime.usp.br/~gdaltonl/ageis.htm
47 48