Joaquim Oliveira Grupo de Estudos em Processos 25/06/2002 Comparação entre Metodologias de...

Post on 07-Apr-2016

222 views 4 download

Transcript of Joaquim Oliveira Grupo de Estudos em Processos 25/06/2002 Comparação entre Metodologias de...

Joaquim OliveiraGrupo de Estudos em Processos25/06/2002

Comparação entre Metodologias de Desenvolvimento

2

Roteiro

Metodologias Ágeis eXtreme Programming (XP) SCRUM Crystal Clear Feature Driven Development (FDD) Agile Modeling Dynamic System Development Method (DSDM)

3

Roteiro

Metodologias Tradicionais RUP OPEN Catalisys

Comparação

4

eXtreme Programming

Proposta por Kent Beck Baseia-se em 4 valores...

Comunicação Feedback Simplicidade Coragem

...e 12 práticas Iterativo e incremental. Iterações de 2 semanas.

5

eXtreme Programming Prática 1: Jogo do Planejamento

Planejar rapidamente, sem muitos detalhes, o escopo do próximo release, considerando prioridades de negócios, aspectos técnicos, estimativas. Alterar o planejamento sempre que ele se mostrar inadequado

Prática 2: Releases curtos Colocar um sistema simples em produção rapidamente. Liberar novas

versões em ciclos curtos de tempo

Prática 3: Metáfora Guiar o desenvolvimento através de uma história simples, de

entendimento de todos

6

eXtreme Programming Prática 4: Design Simples

Projetar o mais simples possível.

Prática 5: Teste Testes unitários automáticos, produzidos durante implementação.

Clientes escrevem testes para demonstrar quando os requisitos estão prontos

Prática 6: Refactoring Reestruturar o sistema sem alterar o seu comportamento para

remover duplicação, melhorar comunicação, simplificar ou adicionar funcionalidade

7

eXtreme Programming Prática 7: Programação em Pares

Toda a produção de código é feita por pares de programadores trabalhando na mesma máquina

Prática 8: Collective Ownership Todos podem alterar qualquer parte do código a qualquer momento

Prática 9: Integração Contínua Integrar e construir o sistema várias vezes ao dia, sempre que

uma tarefa é completada

8

eXtreme Programming Prática 10: 40 horas por Semana

Não trabalhar mais que 40hs por semana. Nunca trabalhar horas extra em duas semanas consecutivas

Prática 11: Cliente no local Usuário real é integrante da equipe, trabalha onde a equipe

trabalha e está disponível para responder perguntas a qualquer momento

Prática 12: Padrão de Codificação Escrever todo o código de acordo com um padrão estabelecido,

visando facilitar a comunicação através do código

9

SCRUM

Metodologia em forma de pattern Características

Iterativa e incremental, com iterações de 1 mês (sprints)

Equipes de 6 a 10 pessoas Requisitos em constante mudança (ambiente caótico)

Envolvimento do “cliente” Não estabelece técnicas para o desenvolvimento

10

SCRUM

Fases

11

SCRUM

12

SCRUM

Priorização dos requisitos Importância para o negócio Riscos para o projeto

Acompanhamento freqüente das atividades SCRUM Master

Mediador dos encontros Acompanhar o progresso da equipe

XP@SCRUM

13

Feature Driven Development Proposta por Peter Coad et al. Baseia-se no conceito de feature

“Pequenas funcionalidades que possuam valor para o usuário”

Iterativa e incremental. Iterações de 2 semanas Equipes de 16 a 20 pessoas, divididas em sub-

equipes

14

Composta de 5 atividades principais

Participação de especialistas do negócio Esclarecem o contexto do sistema e priorizam as features

Escalável para grandes equipes Basta ter programadores-chefe suficientes

Feature Driven Development

Desenvolver um modelo

geral

Elaborar uma lista de features

Planejarpor

feature

Projetarpor

feature

Construirpor

feature

15

Crystal Clear

“Caçula” de uma família de metodologias, proposta por Alistair Cockburn

Iterativo e incremental, com iterações fixas Equipes de 3 a 6 pessoas Sistemas que não sejam críticos Define papéis e artefatos “Strong on communication, light on deliverables”

16

Crystal Clear O cliente deve estar envolvido

Esclarece os requisitos sempre que necessário Prioriza o que deve ser feito

A equipe participa do planejamento Requisitos na forma de pequenas descrições Entregas freqüentes, para se obter feedback Não especifica técnicas

Gerenciamento dirigido a milestones e riscos O resto é com a equipe!

17

DSDM

Criado por um consórcio, devido a necessidades da comunidade de RAD

Define O QUE e não COMO Pode ser usado com RUP, XP, etc...

Iterativo e incremental. Iterações de 2 a 6 semanas

Recursos e tempo fixos, escopo negociável

18

DSDM

19

DSDM

Guiado por 9 princípios1. O envolvimento ativo do usuário é essencial2. As equipes DSDM devem estar capacitadas a tomar

decisões3. Foco na entrega freqüente de produtos4. Adequação aos objetivos do negócio é o principal

critério de aceitação 5. O desenvolvimento iterativo e incremental é

necessário para uma solução de negócio precisa

20

DSDM

Guiado por 9 princípios6. Todas as mudanças durante o desenvolvimento são

reversíveis7. Os requisitos são definidos em um alto nível de

abstração8. Testes são executados durante todo o ciclo de vida9. Colaboração e cooperação entre os stakeholders é

essencial

21

Agile Modeling

Modelar de forma simples e eficiente Complementa outras metodologias de

desenvolvimento Um modelo ágil

É fácil de ser entendido É simples Possui precisão e detalhamentos necessários Agrega valor ao projeto

22

Agile Modeling

Valores: comunicação, feedback, simplicidade, coragem e humildade

Alguns princípios Assumir simplicidade “Abraçar” as mudanças Modelar com um propósito Melhoria incremental Obter feedback rápido Conhecer vários modelos

23

Agile Modeling

Algumas práticas Participação ativa do usuário Crie modelos simples, com desenhos simples Utilize os artefatos corretos Modele em pequenos incrementos Modele com outras pessoas Use ferramentas simples Use o código para provar que o modelo está certo

24

RUP

Framework para processos Principais Características

Iterativo e Incremental Guiado por casos de uso e riscos Ênfase na arquitetura

As duas dimensões do RUP Fases Fluxos ou disciplinas

25

RUP

26

RUP

RUP ágil Propostas da Rational

RUP para pequenos projetos Abordagens ágeis para o RUP O RUP de um homem só

dX, de Robert Martin Instância de Craig Larman em “Applying UML and

Patterns”

27

OPEN Framework para processos

Desenvolvimento pelo OPEN Consortium Unificação de várias metodologias: MOSES, SOMA, Firesmith,

Synthesis, etc... Componentes do OPEN Process Framework

Produtos e Produtores Linguagens Unidades de Trabalho Estágios Guias

28

OPEN

29

OPEN

Produtos: qualquer coisa de valor produzida durante o projeto Documentação, código, diagramas, etc...

Produtores: algo que cria, mantém ou avalia um produto Pessoas, equipes, organizações,...

Linguagens: a mídia utilizada para documentar um produto Linguagem natural, UML, Java, SQL, IDL,...

30

OPEN

Unidades de Trabalho Atividade Tarefa Técnica Realização da Tarefa (Task performance)

Estágios Ciclos e Fases Build, release e deployment

31

OPEN

Ciclos e fases

32

OPEN

Builds, releases e deployments

33

Catalysis Forte ênfase em componentes e reuso Usa UML como linguagem de modelagem Princípios Básicos

Abstração Precisão Partes Plugáveis Minimize a mágica Uma e somente uma vez

Conceitos de Modelagem Tipo Colaboração Refinamento

34

Catalysis Níveis de modelagem

Domínio do problema ou do negócio (outside) Especificação do componente (boundary) Implementação do componente (inside)

Tipos de modelos Estáticos: modelam um estado de um objeto, descrito através

de um conjunto de atributos Dinâmicos: modelam as mudanças de estado de um objeto,

descritas através de um conjunto de ações e suas pré e pós-condições

Interativos: modelam a comunicação entre objetos

35

Catalysis

Refinamento dos modelos 7 níveis de refinamento

Ênfase em riscos Iterações curtas feedback constante Várias “caminhos” para seguir o processo

Patterns para vários problemas Catalysis lite

36

ComparaçãoCARACTERÍSTICAS RUP OPEN Catalysis XP Crystal Clear Scrum DSDM Agile Modeling FDD

Iterativo e Incremental S S S S S S S N STamanho da equipe (máximo) N N N 12 6 10 N N NFases de projeto S S N P N S S N SÊnfase na comunicação N N N S S S S S NGuia o modo de execução das atividades S S P S N P N N NExplicitamente apoiado por ferramentas S N S S N N N S NParticipação do cliente P N P S P S S S SComponentização S S S N N N N N NEstabelece a produção de artefatos S S S S S S S S SEstabelece papéis S S N S S S S N SNecessidade de instanciação S S S N P N S P NConcepção de uma arquitetura S N S N P S S S SGuiada por funcionalidades S N P S S S S N SAtaca os riscos cedo S N S P S S N N NDesign simples N N N S N P P S SEquipe participa do planejamento N N N S S S S N NIntegração contínua P N N S N P P N SPequenhos releases P N P S S S S S SProgramação em pares N N N S P P P N PTestes constantes P N S S P P S N SMetáfora N N N S N N P N NPropriedade coletiva do código N N N S P P P S NRefatoramento constante N N S S N P P S PSemana de 40 horas N N N S N N P N NAcompanhamento constante P N P S S S S N SElaboração de Modelos/Diagramas S S S P P S S S S

37

Comparação

Tamanho das Iterações Envolvimento do usuário Planejamento preditivo x adaptativo Riscos técnicos x importância para o negócio Diferentes níveis de abstração na definição das

metodologias Metodologias tradicionais podem ser encaradas

de forma ágil!