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

Apresentação em tema: "Joaquim Oliveira Grupo de Estudos em Processos 25/06/2002 Comparação entre Metodologias de Desenvolvimento."— Transcrição da apresentação:

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

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

3 3 Roteiro  Metodologias Tradicionais  RUP  OPEN  Catalisys  Comparação

4 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 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 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 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 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 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 10 SCRUM  Fases

11 11 SCRUM

12 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 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 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 Planejar por feature Projetar por feature Construir por feature

15 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 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 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 18 DSDM

19 19 DSDM  Guiado por 9 princípios 1. O envolvimento ativo do usuário é essencial 2. As equipes DSDM devem estar capacitadas a tomar decisões 3. Foco na entrega freqüente de produtos 4. 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 20 DSDM  Guiado por 9 princípios 6. Todas as mudanças durante o desenvolvimento são reversíveis 7. Os requisitos são definidos em um alto nível de abstração 8. Testes são executados durante todo o ciclo de vida 9. Colaboração e cooperação entre os stakeholders é essencial

21 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 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 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 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 25 RUP

26 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 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 28 OPEN

29 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 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 31 OPEN  Ciclos e fases

32 32 OPEN  Builds, releases e deployments

33 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 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 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 36 Comparação

37 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!