aula - metodologias Ágeis

Métodos Ágeis de Desenvolvimento de Software

10/04/2023 ©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA

O Que Veremos? Desenvolvimento de Software

Tradicional• Problemas do Desenvolvimento

Tradicional Métodos Ágeis de

Desenvolvimento• Manifesto Àgil• Princípios

Práticas Ágeis XP Scrum Outras Metoologias

Métodos Àgeis de Desenvolvimento de

Software

2


Referências Bibliográficas http://www.agilcoop.org.br/curso_de_verao_2010 http://www.scrumalliance.org/ http://www.extremeprogramming.org/ http://improveit.com.br/scrum http://visaoagil.wordpress.com/ http://amagno.blogspot.com/ http://www.infoq.com/br/

3

http://www.agilcoop.org.br/curso_de_verao_2010

http://www.scrumalliance.org/

http://www.extremeprogramming.org/

http://improveit.com.br/scrum

http://visaoagil.wordpress.com/

http://amagno.blogspot.com/

http://www.infoq.com/br/

Desenvolvimento Tradicional de Software


Novos Ventos no Mundo do Desenvolvimento de Software

Sociedade demanda• Grande quantidade de sistemas/aplicações• Software complexo, distribuído,

heterogêneo• Requisitos mutantes(todo ano, todo mês,

toda semana, todo dia)

5


A Forma Tradicional de Desenvolver Software

6


Problemas da Forma Tradicional de Desenvolver Software – CHAOS Report

7



8



9


Problemas da Forma Tradicional de Desenvolver Software

Supõem que é possivel prever o futuro. Pouca interação com os clientes. Ênfase em burocracias.

• (documentos, formulários, processos, controles rígidos, etc...)

Avaliação do progresso baseado na evolução da burocracia e não do código

Grande quantidade de erros Falta de flexibilidade no software

desenvolvido10


Como Resolver Estes Problemas Melhores tecnologias

• Padrões de projeto (reutilização de idéias)

• Componentes (reutilização de código)• Middleware/frameworks (aumenta a

abstração)

Melhores metodologias• Métodos Àgeis

11

Métodos Ágeis de Desenvolvimento


Métodos Àgeis de Desenvolvimento

Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.

Questionam e se opõem a uma série de mitos práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos.

Manifesto Ágil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001.• http://agilemanifesto.org

13


Manifesto Àgil Indivíduos e interações são mais importantes

do que processos e ferramentas

Software funcionando é mais importante do que documentação detalhada

Colaboração com o cliente é mais importante do que negociação de contratos

Adaptação às mudanças é mais importante do que seguir um plano inicial

14


Manifesto Àgil – Princípios 1/4

Prioridade máxima: satisfazer o usuário através de entrega rápida e contínua de software com valor.

Receber bem requisitos mutantes, mesmo tarde no desenvolvimento. Processos ágeis aguentam mudanças para a vantagem competitiva do consumidor.

Entregar software em funcionamento com frequência, de algumas semanas a alguns meses, dando preferência à menor periodicidade.

15



Pessoas de negócio e desenvolvedores devem trabalhar diariamente durante o projeto.

Construa projetos em volta de indivíduos motivados. Dê a eles o ambiente e o suporte de que eles precisam, e confie que eles farão o serviço.

O método mais eficiente de passar informação para e entre uma equipe de desenvolvimento é conversa cara-a-cara.

16



Software rodando é a principal medida de progresso.

Processos ágeis precisam de desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem aguentar manter um ritmo constante indefinidamente.

Atenção contínua à excelência técnica e bom projeto melhora a agilidade.

17



Simplicidade -- a arte de maximizar a quantidade de trabalho não realizado -- é essencial.

As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficiente, e deve ajustar seu comportamento de acordo.

18

Práticas Ágeis


Práticas Ágeis Comunicação

Negociação

Ciclo de Vida Iterativo

Gerenciamento Ágil

Modelagem Ágil

Visibilidade do Projeto20


Entendendo o Cliente

21


Comunicação Evitar telefone sem fio Desenvolvedores diretamente com o

cliente

22


Negociação

4 variáveis do desenvolvimento de Software

Abordagem tradicional

Fixo

Escopo

Prazo

Custo

Qualidade

Variável

23


Negociação

4 variáveis do desenvolvimento de Software

Abordagem Ágil

FixoVariável

Escopo

Prazo

Custo

Qualidade

24



25



26


Evolução Iterativa de Um Produto

27


Incremental versus Iterativo

28


Gerenciamento Ágil

29


Gerenciamento Ágil

30


Modelagem Ágil

31


Visibilidade de Resultados - KanBan

32



33



34


Alguns Métodos Àgeis



35



Extreme Programming - XP


Extreme Programming - XP

Kent Beck Estados Unidos 1999

XP é leveXP é focado no

desenvolvimento de software

XP funciona em times de qualquer tamanho

XP se adapta bem a requisitos vagos e que

mudam rapidamente37


Desenvolvimento Incremental e Iterativo

38


O Custo da Mudança

39


Ciclo Trimestral e Ciclo Semanal

Ciclo Trimestral Releases

Ciclo Semanal Iterações

40


Ciclo SemanalCliente escreve

estórias

Desenvolvedores Estimam

Cliente Prioriza as estórias

Desenvolvedores constroem tarefas

Desenvolvedores Implementam

Cliente aprova o resultado

Retrospectiva

Jogo do Planejament

o

41


Cliente Escreve Estórias Estórias exprimem o comportamento de

uma funcionalidade geral

Estórias são escritas na linguagem natural

Formato: Who – What - Why

Ex:• No papel de administrador do sistema eu quero

realizar o cadastro de usuários, para armazenar informações de contato: nome, telefone e e-mail.

42


Estimativas – Jogo do Planejamento Objetivo: Estimar custo de

desenvolvimento das estórias. Características:

Cartas Todos fazem estimativas para todas as estórias As estimativas são individuais Tempo (horas/dias)

43


Cliente Prioriza as Estórias

Responsabilidade nas mãos do cliente

“Aguarde e Confie”

Conceito Chave no XP

Limite máximo

44


Construção das Tarefas Ex:

• Estória: No papel de administrador do sistema eu quero realizar o cadastro de usuários, para armazenar informações de contato: nome, telefone e e-mail.

• Tarefas:▪ Modelagem do banco de dados▪ Criar Interface▪ Implementar cadastro

45


Implementação

Programação em par

• Todo o código• Um digita, outro revisa• Redução de bugs• Disseminação do conhecimento• Pressão do par• Simplicidade• Velocidade

46


Implementação Desenvolvimento dirigido a testes

Propriedade coletiva do código

Base de código unificada

Sentar-se junto

RefatoraçãoCoragem

47


Ambiente de Trabalho“Se você não tiver um ambiente razoável para trabalhar, seu

projeto não terá sucesso” (Kent Beck)

Quadro(s) brancos Post-it Cadeiras giratórias Jogos Comida e café Folhas em branco Privacidade

Respeito

48


Reuniões Diárias

49


Acompanhamento

50


Aprovação do Cliente

Feedback

51


Retrospectiva

52


Extreme Programming

Valores

Princípios

Práticas

• Comunicação• Simplicidade• Coragem• Feedback• Respeito

53


Extreme Programming

Valores

Princípios

Práticas

• Auto-semelhança (Self-Similarity)• Benefício Mútuo (Mutal Benefit)• Diversidade (Diversity)• Economia (Economics)• Falha (Failure)• Fluidez (Flow)• Humanismo (Humanity)• Melhoria (Improvement) • Oportunidade (Opportunity)• Passos de Bebê (Baby Steps)• Qualidade (Quality)• Redundância (Redundancy)• Reflexão (Reflection)• Responsabilidade Aceita (Accepted Responsability)

54


Extreme Programming

Valores

Princípios

Práticas

Práticas Primárias• Ambiente Informativo (Informative workspace)• Build de dez minutos (Ten-MinuteBuild)• Ciclo Semanal (Weekly Cycle)• Ciclo Trimestral (Quarterly Cycle)• Desenvolvimento Orientado a Testes (Test-First Programming)• Design Incremental (Incremental Desing)• Equipe Integral (Whole Team)• Folga (Slack)• Histórias (Stories)• Integração Contínua (Continuous Integration)• Programação em Par (Pair Programming)• Sentar-se junto (Sit together) • Trabalho Energizado (Energized Work)

55


Extreme Programming

Valores

Princípios

Práticas

Práticas Corolárias• Análise da Raiz do Problema (Root-Cause Analysis)• Base de Código Unificada (Single Code Base)• Código Coletivo (Shared Code)• Código e testes (Code and Tests)• Continuidade da equipe (Team Continuity)• Contrato de Escopo Negociável (Negotiated12 Scope Contract)• Envolvimento do cliente Real (Real Custumer Involvement)• Equipes que encolhem (Shrinking Teams)• Implantação diária (Daily Deployment)• Implantação incremental (Incremental Deployment)• Pagar por uso (Pay-Per-Use)

56

XP e Riscos no Desenvolvimento de Software


Erros na Programação/Cronograma

• Pequenos ciclos de pedidos• Escopo limitado• Implementação das características

prioritárias ao negócio primeiro

58


Cancelamento do Projeto

• XP pede ao cliente que escolha a funcionalidade que faça maior diferença economicamente.

59


Sistema Não Muito Confiável

• Muitos testes são feitos▪ Desenvolvedores testam função por função▪ Clientes testam funcionalidade por

funcionalidade

60


Má Interpretação do Propósito Final

• O cliente vira parte integral do time

61


Mudança do Que é Desejado para o Sistema

• Implementação em ciclos

62


Scrum - Fases

64


Scrum – Fluxo de Sprint

65


Scrum – Papéis

66


Scrum – Fluxo de Estimativas

67


Scrum – Ferramentas

68


Composição de Métodos Àgeis – Scrum e XP

69

Outras Metodologias


Outras Metodologias FDD – Feature Driven Development Crystal Family DSDM (Dynamic Systems

Development Method) ASD (Adaptative Software

Development)

71

Prática: Jogo do Planejamento


Jogo do Planejamento na prática

Estória 0: No papel de administrador do sistema eu quero realizar o

cadastro de usuários, para armazenar informações de contato: nome, telefone e e-mail.

Estória 1:• O sistema deverá permitir aos usuários cadastrarem notícias.

A notícia deve ter manchete, descrição e conteúdo. O sistema deverá listar todas as notícias.

Estória 2:• A partir da listagem das notícias, o sistema deverá permitir

ao usuário enviar uma notícia para o e-mail de um usuário cadastrado.

73


Obrigado !

74

FDD – Feature Driven Development


FDD

Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionais e as mais extremas, proporcionando uma transição mais suave para organizações mais conservadoras, e a retomada da responsabilidade para as organizações que se desiludiram com as propostas mais radicais.

76


FDD - História 1997-1998, Singapura Contexto: Desenvolvimento de um grande sistema

de empréstimos para um banco internacional Anteriormente, após 2 anos de consultoria, 3.500

páginas de casos de (in)uso e um modelo de objetos com centenas de classes, foi avaliado como impossível

Decisão: Implantação das metodologias de OOAD de Peter Coad e de gerência de projetos de Jeff De Luca

Resultado: 15 meses após a contratação da dupla, 2.000 features entregues por uma equipe de 50 pessoas

77


FDD – Visão Geral

78


FDD- O Que É Feature ? Característica ou funcionalidade Pequena o suficiente para ser implementada no

máximo em 2 semanas Oferece valor para o cliente Mapeia passos em uma atividade de negócio

Pode ser um passo de um caso de uso Às vezes pode ser o próprio caso de uso

Conceito muito próximo ao de um requisito funcional

Modelo: <ação> <resultado> <objeto> Calcular o total de uma venda Autorizar uma transação com cartão de um cliente

79

©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 80

FDD - Processos Desenvolver um Modelo Abrangente

Modelagem dos Processos de Negócio (BPM) Análise Orientada por Objetos (OOA)

Construir a Lista de Features Decomposição Funcional Planejar por Feature

Plano de Desenvolvimento Prioridade, Dependência, Distribuição de Trabalho

Detalhar por Feature Projeto OO (OOD), Estudo Detalhado Construir por Feature

Programação OO (OOP) Inspeção, Testes, Integração


FDD – Processo n°1


FDD – Processo n° 2


FDD – Disciplinas Envolvidas

86


FDD – Papéis

87


FDD – Reportando o Processo

88


FDD – Reportando o Processo

89


Espectro de Metodologias

90

aula - metodologias Ágeis

Technology