Análise e Projeto de Sistemas Orientados a Objetos - Métodos Ágeis – Extreme Programming Rogério Lacerda

31/7/2015Rogério Lacerda2 Métodos Ágeis Extreme Programming Conceitos Reuniões Papéis Artefatos Análise e Projeto O.O. Agenda

31/7/2015Rogério Lacerda3 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Conceitos DELIBERADADISCIPLINADA  Abordagem DELIBERADA e DISCIPLINADA para desenvolvimento de Software  Criada por KENT BAECK em 1996 durante o projeto DAIMLER-CHRYSLER (Automóvel) SUCESSOXPSATISFAÇÃO DO CLIENTE  O SUCESSO de XP advém da intensa SATISFAÇÃO DO CLIENTE CLIENTE SATISFEITO SUCESSOPROJETO  CLIENTE SATISFEITO é o melhor indicativo de SUCESSO de um PROJETO

31/7/2015Rogério Lacerda4 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Conceitos METODOLOGIA CLIENTE  METODOLOGIA criada para produzir o software que o CLIENTE precisa quando ele é necessário ENCORAJADESENVOLVEDORES MUDANÇAS DOS REQUISITOS SOFTWARE  XP ENCORAJA os DESENVOLVEDORES a atender as requisições de MUDANÇAS DOS REQUISITOS do SOFTWARE, no momento em que isto acontece

31/7/2015Rogério Lacerda5 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Princípios SIMPLICIDADE  SIMPLICIDADE  COMUNICAÇÃO  FEEDBACK  CORAGEM

31/7/2015Rogério Lacerda6 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PrincípiosSIMPLICIDADE  SOLUÇÃO SIMPLES  Tente sempre desenvolver a SOLUÇÃO mais SIMPLES possível  Muitos projetos perdem muito tempo quando os desenvolvedores destinam muito tempo desenvolvendo uma solução genérica SOLUÇÃOSIMPLESMENTE REQUISITO DO USUÁRIO  A SOLUÇÃO deve responder SIMPLESMENTE um REQUISITO DO USUÁRIO FUNCIONALIDADES  Algumas FUNCIONALIDADES podem nunca vir a serem utilizadas

31/7/2015Rogério Lacerda7 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PrincípiosCOMUNICAÇÃO  CANAL ABERTOCOMUNICAÇÃO EQUIPE DE DESENVOLVIMENTO USUÁRIOS  CANAL ABERTO de COMUNICAÇÃO entre a EQUIPE DE DESENVOLVIMENTO e com os USUÁRIOS COMUNICAÇÃOCHAVESUCESSO  A COMUNICAÇÃO é CHAVE para o SUCESSO

31/7/2015Rogério Lacerda8 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PrincípiosFEEDBACK FEEDBACK  FEEDBACK possibilita que o software evolua  “PERGUNTE AO SOFTWARE, NÃO A UM DOCUMENTO” FEEDBACK  FEEDBACK precisa ser:  CEDO (PRA GENTE DESCOBRIR LOGO SE ESTÁ FAZENDO A COISA CORRETA)  CONCRETO (FEEDBACK ORIUNDO DO CÓDIGO)  CONSTANTE (O CICLO DE DESENVOLVIMENTO TEM QUE SER CURTO)

31/7/2015Rogério Lacerda9 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PrincípiosCORAGEM CLIENTEACONTECENDO  Colocar o CLIENTE a par do que está ACONTECENDO CAPACIDADE DE RESPONDER MUDANÇAS  Acreditar na CAPACIDADE DE RESPONDER a MUDANÇAS APRENDERERROS  APRENDER com os ERROS FEEDBACK  Acreditar no FEEDBACK (NÃO na “TEORIA”)  “JOGAR PARA GANHAR” (NÃO PRA TER UMA DESCULPA)  “FAZER O QUE PRECISA SER FEITO” (JOGAR FORA CÓDIGO RUIM)

31/7/2015Rogério Lacerda10 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosLEVANTAMENTO LEVANTAMENTO ESTÓRIAS DOS USUÁRIOS  O projeto é iniciado em XP com o LEVANTAMENTO das "ESTÓRIAS DOS USUÁRIOS“ ESTÓRIAUSUÁRIO NÃO É TEXTO TÉCNICO  Cada ESTÓRIA é escrita pelo USUÁRIO e consiste de um ou alguns parágrafos de um TEXTO NARRATIVO/DESCRITIVO. NÃO É TEXTO TÉCNICO PROPÓSITONÃO É DEFINIR FUNCIONALIDADEESTIMAR  O PROPÓSITO da estória NÃO É DEFINIR toda a FUNCIONALIDADE de um cenário, mas sim, ESTIMAR como será a complexidade de parte do sistema em quanto tempo isso será desenvolvido DETALHES DA ESTÓRIA CLIENTEINÍCIODESENVOLVIMENTO  Todos os demais DETALHES DA ESTÓRIA serão esclarecidos como CLIENTE, imediatamente ao INÍCIO do DESENVOLVIMENTO

31/7/2015Rogério Lacerda11 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Passos ESTÓRIAS DO USUÁRIO USUÁRIOSESTÓRIAS FUNCIONALIDADE  USUÁRIOS escrevem ESTÓRIAS descrevendo a FUNCIONALIDADE que querem DESENVOLVEDORESTEMPO  DESENVOLVEDORES estimam o TEMPO necessário para implementar cada estória RELEASECONJUNTO DE ESTÓRIAS DISPONIBILIZADAS SIMULTANEAMENTE  Uma RELEASE é um CONJUNTO DE ESTÓRIAS que serão DISPONIBILIZADAS SIMULTANEAMENTE ESTÓRIASIMPORTANTES DIFÍCEISPRIORIDADE  As ESTÓRIAS mais IMPORTANTES e/ou mais DIFÍCEIS têm PRIORIDADE

31/7/2015Rogério Lacerda12 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosPLANEJAMENTO PLANEJAMENTO DO RELEASE  PLANEJAMENTO DO RELEASE, onde será DEFINIDO quais ESTÓRIAS deverão ser desenvolvidas em quais RELEASES RELEASE ITERAÇÃO ITERAÇÃO  Cada RELEASE consiste de um número de iterações. Cada ITERAÇÃO terá um conjunto de estórias implementadas. Em cada ITERAÇÃO  PLANEJE  CODIFIQUE  TESTE  REFATORE  ESCUTE

31/7/2015Rogério Lacerda13 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosPLANEJAMENTO

31/7/2015Rogério Lacerda14 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosPLANEJAMENTO RELEASES PEQUENOSFREQÜENTES  XP preconiza RELEASES PEQUENOS e FREQÜENTES (A CADA 2-3 MESES) DIMENSÕESDESENVOLVIMENTO DE SOFTWARECUSTO, TEMPO, QUALIDADE E ESCOPO  As quatro DIMENSÕES do DESENVOLVIMENTO DE SOFTWARE são CUSTO, TEMPO, QUALIDADE E ESCOPO ESCOPOVARIÁVEL LIVRE  XP tenta manter ESCOPO como VARIÁVEL LIVRE RELEASES  RELEASES são divididas em iterações de 2-3 semanas ITERAÇÃO  Uma ITERAÇÃO alcança algum objetivo (TIPICAMENTE A ADIÇÃO DE NOVA FUNCIONALIDADE) ÚTILNECESSÁRIO PRAZOS DE DESENVOLVIMENTO  Nada é feito que não seja imediatamente ÚTIL e NECESSÁRIO para não impactar os PRAZOS DE DESENVOLVIMENTO

31/7/2015Rogério Lacerda15 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Passos PROGRAMAÇÃO EM PARES “REVISÃO DE CÓDIGOTEMPO TODO”  “Se REVISÃO DE CÓDIGO é legal, vamos fazê-la o TEMPO TODO” PROGRAMAÇÃOPARES  Em XP, a PROGRAMAÇÃO é feita em PARES PARES  PARES mudam com relativa rapidez (EM DIAS) PROGRAMAÇÃO EM PARESCOMUNICAÇÃO APRENDIZADO  PROGRAMAÇÃO EM PARES favorece COMUNICAÇÃO e APRENDIZADO PADRÃO DE CODIFICAÇÃO  Precisa estabelecer um PADRÃO DE CODIFICAÇÃO HÁ CASOS DE REDUÇÃO NO TEMPO DE DESENVOLVIMENTO COM PROGRAMAÇÃO EM PARES

31/7/2015Rogério Lacerda16 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Passos TESTES AUTOMÁTICOS TESTES AUTOMÁTICOSSOFTWARE  TESTES AUTOMÁTICOS são parte do SOFTWARE TESTESREFATORE  TESTES permitem que você REFATORE sem medo de quebrar o código TESTESREDUNDÂNCIA LÓGICA  TESTES representam uma “REDUNDÂNCIA LÓGICA” que você adiciona ao código  Escrevendo TESTES antes da FUNCIONALIDADE, você esclarece DÚVIDAS sobre o que o SOFTWARE deve fazer

31/7/2015Rogério Lacerda17 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosREFATORAMENTO REFATORARMELHORARCÓDIGO  REFATORAR é MELHORAR o CÓDIGO sem alterar sua funcionalidade REFATORA  Antes de uma mudança, você REFATORA o código para que a mudança seja simples de fazer REFATORAÇÃO DESIGNMUDANÇAS FREQÜENTES  REFATORAÇÃO continua possibilita manter um DESIGN adequado, mesmo com MUDANÇAS FREQÜENTES

31/7/2015Rogério Lacerda18 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – PassosREFATORAMENTO REFATORARMELHORARCÓDIGO  REFATORAR é MELHORAR o CÓDIGO sem alterar sua funcionalidade REFATORA  Antes de uma mudança, você REFATORA o código para que a mudança seja simples de fazer REFATORAÇÃO DESIGNMUDANÇAS FREQÜENTES  REFATORAÇÃO continua possibilita manter um DESIGN adequado, mesmo com MUDANÇAS FREQÜENTES

31/7/2015Rogério Lacerda19 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Passos PROJETO SIMPLES PROJETOS FLEXÍVEISMUDANÇAS IMPREVISTASSOFTWARE  PROJETOS FLEXÍVEIS são uma defesa contra MUDANÇAS IMPREVISTAS no SOFTWARE PROJETOS FLEXÍVEISCUSTOS, TEMPO DESENVOLVIMENTOMANUTENÇÃO  PROJETOS FLEXÍVEIS também têm CUSTOS, TEMPO para DESENVOLVIMENTO e MANUTENÇÃO CÓDIGOCOMPLEXOCUIDADO!!!  CÓDIGO fica mais COMPLEXO  CUIDADO!!!  MUITA VEZES A FLEXIBILIDADE NÃO É UTILIZADA NUNCA PROJETO SIMPLES POSSÍVELNECESSÁRIO SUPORTARFUNCIONALIDADE  Como mudança é barata em XP, vamos manter o PROJETO mais SIMPLES POSSÍVEL, modificando-o quando for NECESSÁRIO SUPORTAR mais FUNCIONALIDADE

31/7/2015Rogério Lacerda20 Análise e Projeto O.O. Sistemas de Informação – Métodos Ágeis Extreme Programming – Passos PROBLEMAS EM XP  CONSIDERAR TESTES COMO PARTE NORMAL DO PROCESSO DE DESENVOLVIMENTO  SEMPRE FAZER A COISA MAIS SIMPLES  ADMITIR QUE VOCÊ NÃO SABE  COLABORAR  VENCER RESISTÊNCIA NAS PESSOAS  TIMES GRANDES  SITUAÇÕES EM QUE VOCÊ NÃO PODE MUDAR LIVREMENTE O CÓDIGO

Análise e Projeto O.O. Até a próxima !!!