A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil de Desenvolvimento de Software LOURENÇO MARCOS-205003.

Apresentações semelhantes


Apresentação em tema: "Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil de Desenvolvimento de Software LOURENÇO MARCOS-205003."— Transcrição da apresentação:

1 Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil de Desenvolvimento de Software LOURENÇO MARCOS & JOSÉ ALEXANDRE Estudantes do Curso de Tecnologia em Análise e Desenvolvimento de Software UNILINS 18/03/2010

2 Sumário Introdução Premissas Básicas do Modelo Tradicional e suas conseqüências Conceito de metodologia Ágil Como avaliar projetos Doentes Metodologias Ágeis. –XP, –SCRUM Resumo 18/03/2010 José Alexandre & Lourenço Marcos 2

3 Premissas Básicas do Modelo Tradicional 18/03/2010 José Alexandre & Lourenço Marcos 3 É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

4 O cenário vivido por muitos 18/03/2010 José Alexandre & Lourenço Marcos 4 Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente formais e controladoras, porém ainda não conseguem obter qualidade. Por quê? Pouca preocupação com as pessoas e a interação entre elas Pouca comunicação com o cliente Custos muito altos Excesso de formalismo Qual a consequência disso? Alta rotatividade No fim o software não serve mais Projeto cancelado Prazos estourados

5 Além disso /03/2010 José Alexandre & Lourenço Marcos 5 muitas empresas vivem em uma situação de total descontrole e falta de qualidade, e não são nada ágeis, vivem o...

6 ... CAOS 18/03/2010 José Alexandre & Lourenço Marcos 6 Mas esse problema não é novo, É assim, que Fevereiro 2001, em Utah 17 caras lançaram o... Estatísticas de projetos indicam que: 31% são cancelados antes de ser complemente entregues; 53% custam quase o dobro (189%) do esperado; Apenas 16% são completados no prazo estimado; Fonte: Chaos Report

7 18/03/2010 José Alexandre & Lourenço Marcos O Manifesto Ágil 7 O que é isso? –Um manifesto que criticava alguns mitos/práticas da engenharia de software e da gerência de projetos adotadas por abordagens tradicionalistas –Foi assinado por 17 pessoas envolvidas com desenvolvimento de software, dentre eles consultores e programadores experientes Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

8 O que é Agilidade? 18/03/2010 José Alexandre & Lourenço Marcos 8 a.gi.li.da.de sf (lat agilitate) 1.Qualidade do que é ágil. 2.Desembaraço, ligeireza, presteza de movimentos. 3.Mobilidade, perspicácia, vivacidade. Geralmente associa-se Agilidade com: –Rapidez, Flexibilidade, Leveza –Resumo: Habilidade para mudar

9 Agilidade e a Engenharia de Software 18/03/2010 José Alexandre & Lourenço Marcos 9 Engenharia de software ágil combina a filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfação de cliente e a entrega incremental de software logo de inicio; isso envolve equipes pequena, altamente motivada;métodos informais; produto de engenharia de software mínimo e simplicidade global do desenvolvimento. As diretrizes enfatizam a entrega em contraposição a analise e ao projeto e a comunicação ativa e continua entre os desenvolvedores e clientes;

10 18/03/2010 José Alexandre & Lourenço Marcos O que diz o Manifesto? Estamos descobrindo melhores maneiras de desenvolver software, fazendo software e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Indivíduos e interações mais que processos e ferramentas. Software que funciona mais que documentação detalhada. Colaboração do cliente mais que negociações contratuais. Responder às mudanças mais que seguir um plano. Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo

11 18/03/2010 José Alexandre & Lourenço Marcos Os 12 Princípios do Manifesto Ágil princípios por traz do Manifesto Ágil –Satisfazer o cliente –As mudanças são bem vindas –Entrega periódica de funcionalidade –Todos juntos –Indivíduos Motivados –Conversas face a face –Medida primária é o software trabalhado –Manter um ritmo constante sempre –Atenção contínua, excelência técnica e bom projeto –Simplicidade –Equipes auto-organizáveis ou auto-gerenciáveis –Reflexão de melhoria regularmente

12 Ter um ambiente de projeto eficaz e eficiente 18/03/2010 José Alexandre & Lourenço Marcos Pessoas X Tecnologia? Conflito? Equipes motivadas e comunicação eficaz Padronização, produtividade, controle e medição ObjetivoNecessidades Ações Vontades Foco nos indivíduos e interações Foco nos processos e ferramentas 12

13 18/03/2010 José Alexandre & Lourenço Marcos ObjetivoNecessidades Ações Vontades Examinando as Premissas Conflito? Equipes motivadas e comunicação eficaz Padronização, produtividade, controle e medição Ter um ambiente de projeto eficaz e eficiente Maior interação causa melhor comunicação Alta interação fortalece o sentimento de equipe Maior interação causa melhor comunicação Alta interação fortalece o sentimento de equipe Processos são essenciais para padronização, monitoramento, medição e controle Ferramentas automatizam partes do processo, facilitam a padronização, aumentam a produtividade e permitem a coleta automática de medidas Processos são essenciais para padronização, monitoramento, medição e controle Ferramentas automatizam partes do processo, facilitam a padronização, aumentam a produtividade e permitem a coleta automática de medidas Equipes motivadas, comunicando- se melhor, produzem com mais qualidade, aumentando a eficácia do processo Um projeto necessita de mecanismos de controle Padronização leva à reutilização, que aumenta a produtividade e diminui os erros Um projeto necessita de mecanismos de controle Padronização leva à reutilização, que aumenta a produtividade e diminui os erros Não é possível ter foco em ambos! Foco nos indivíduos e interações Foco nos processos e ferramentas 13

14 18/03/2010 José Alexandre & Lourenço Marcos ObjetivoNecessidades Ações Vontades Pessoas & Tecnologia! Indivíduos amparados por processos e ferramentas apropriadas, otimizando suas interações Equipes motivadas e comunicação eficaz Padronização, produtividade, controle e medição Ter um ambiente de projeto eficaz e eficiente 14

15 18/03/2010 José Alexandre & Lourenço Marcos Triângulo de Ferro? Responder às mudanças Seguir um plano Conflito? Entregar um produto que o cliente deseja Entregar no prazo e dentro do orçamento Completar um projeto com sucesso ObjetivoNecessidades Ações Vontades 15

16 18/03/2010 José Alexandre & Lourenço Marcos Examinando as Premissas Responder às mudanças Seguir um plano Conflito? Entregar um produto que o cliente deseja Entregar no prazo e dentro do orçamento Completar um projeto com sucesso ObjetivoNecessidades Ações Vontades O cliente e a equipe aprendem durante o projeto Murphy participa ativamente dos projetos O cliente e a equipe aprendem durante o projeto Murphy participa ativamente dos projetos Ter um mapa do caminho ajuda muitíssimo na viagem Sem um plano, como saber quando há mudança? Ter um mapa do caminho ajuda muitíssimo na viagem Sem um plano, como saber quando há mudança? Nenhum cliente fica satisfeito se não obtiver o que deseja, não importando que tenha mudado de idéia durante o projeto É importante ter uma estimativa de prazo e custo, até mesmo para decidir se o projeto é viável Cumprir essas expectativas é um sinal de confiança e competência É importante ter uma estimativa de prazo e custo, até mesmo para decidir se o projeto é viável Cumprir essas expectativas é um sinal de confiança e competência Não é possível conseguir ambos! 16

17 18/03/2010 José Alexandre & Lourenço Marcos Triângulo de Ouro! Entregar um produto que o cliente deseja Entregar no prazo e dentro do orçamento Completar um projeto com sucesso ObjetivoNecessidades Ações Vontades Planejar com Objetivos, Entregáveis e Critérios de Sucesso, abraçando e monitorando a variação 17

18 18/03/2010 José Alexandre & Lourenço Marcos Projetos Doentes: Os Sintomas Atrasos Recursos sobrecarregados Excesso de mudanças Retrabalho Recursos não disponíveis Prioridades mutáveis 18

19 18/03/2010 José Alexandre & Lourenço Marcos As Causas 1. Multitarefa Nociva 2. Lei de Parkinson 3. Síndrome do Estudante 4. Dependência Entre Tarefas 5. Matemática da Gerência de Projetos 19

20 18/03/2010 José Alexandre & Lourenço Marcos 1) Multitarefa Nociva Multitarefa é a execução simultânea de várias tarefas, onde freqüentemente há a interrupção de uma tarefa para trabalhar em outra –Nociva: se houver alguém esperando pela saída da tarefa interrompida –Benigna: se corresponde ao aproveitamento do tempo relativo a alguma espera/execução da tarefa anterior Motivos: –Prioridades que mudam –Falha no planejamento –Tédio em trabalhar numa só tarefa –Atenção dispersa –Síndrome da eficiência –Políticas, métricas, cultura 20

21 18/03/2010 José Alexandre & Lourenço Marcos Por que Aceitamos a Multitarefa? Cultura de manter-se ocupado Impressão de que quantidade aparece mais que qualidade Não sabemos dizer NÃO –Fórmula do sucesso: não sei –Fórmula do fracasso: querer agradar a todo mundo Ter uma carreira de sucesso Demonstrar atitude de posso fazer Cumprir os compromissos Aceitar novas tarefas Completar o trabalho compromissado 21

22 18/03/2010 José Alexandre & Lourenço Marcos O Paradoxo da Multitarefa Intenção: acabar mais tarefas mais rapidamente Conseqüência: todas as tarefas atrasam, e sofrem potencialmente de má qualidade A Preparo B C ABC A B C AB B C A B C ABC A B C 22

23 18/03/2010 José Alexandre & Lourenço Marcos Síndrome do Estudante Quando alguém espera até o último momento possível para iniciar uma tarefa Por que fazer hoje o que eu posso deixar para amanhã? Tenho tempo... A segurança embutida já é consumida antes Tempo Trabalho real na tarefa Data de entrega Tempo da tarefa Segurança Imaginou-se assim... Tempo da tarefa Segurança Mas na realidade foi assim... 23

24 18/03/2010 José Alexandre & Lourenço Marcos A Matemática do Ger. Projetos Duas operações são geralmente feitas: –Adição: cada nível hierárquico adiciona sua própria segurança, pois não confia que a estimativa seja suficiente –Subtração: cada nível desconta uma parcela, pois presume-se que há muita segurança embutida Como não se sabe o fator de inflação/deflação, usa-se o = 8 8+7= 19 Critério Hipotético Universal de Tentativa e Erro 24

25 MetodologiasMetodologias XP – eXtreme Programming XP – eXtreme Programming SCRUM SCRUM LEAN LEAN CRYSTAL CRYSTAL FDD FDD Adaptive Software Development Adaptive Software Development /03/2010 José Alexandre & Lourenço Marcos 25

26 XP – EXtreme Programming Começou a engatinhar 1987 e a se estruturar em 1996 com o projeto C3 da Chrysler Começou a engatinhar 1987 e a se estruturar em 1996 com o projeto C3 da Chrysler Criado pro Kent Beck, que utilizou pela primeira vez em conjunto as práticas que formam a estrutura do Extreme Programming nesse projeto da Chrysler Criado pro Kent Beck, que utilizou pela primeira vez em conjunto as práticas que formam a estrutura do Extreme Programming nesse projeto da Chrysler Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software – Kent Beck Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software – Kent Beck 18/03/2010 José Alexandre & Lourenço Marcos 26

27 XP – EXtreme Programming Valores: Valores: Comunicação Comunicação Simplicidade Simplicidade Feedback Feedback Coragem Coragem Abordagem Incremental Abordagem Incremental 18/03/2010 José Alexandre & Lourenço Marcos 27

28 A quem se destina o – XP ? Grupos de 2 a 10 programadores Projetos de 1 a 36 meses (calendário) De 1000 a linhas de código Papéis: Programadores (foco central)(sem hierarquia) Treinador ou Técnico (coach) Acompanhador (tracker) Cliente 18/03/2010 José Alexandre & Lourenço Marcos 28

29 XP – EXtreme Programming 12 Práticas Planejamento Planejamento Entregas Frequêntes Entregas Frequêntes Metáfora Metáfora Projeto Simples Projeto Simples Testes Testes Programação em pares Programação em pares 18/03/2010 José Alexandre & Lourenço Marcos 29 RefatorarRefatorar Propriedade ColetivaPropriedade Coletiva Integração ContínuaIntegração Contínua 40 horas semanais de trabalho40 horas semanais de trabalho Cliente presenteCliente presente Padronização do CódigoPadronização do Código

30 SCRUMSCRUM O nome é originado da organização de uma equipe de Rugby para o reinicio da partida. O nome é originado da organização de uma equipe de Rugby para o reinicio da partida. Formalizado e implantado no desenvolvimento de software em 1995 por Ken Shwaber Formalizado e implantado no desenvolvimento de software em 1995 por Ken Shwaber A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software 18/03/2010 José Alexandre & Lourenço Marcos 30

31 SCRUMSCRUM O que é de fato? O que é de fato? É um framework de desenvolvimento de produto, sobre um ciclo de vida interativo e incremental É um framework de desenvolvimento de produto, sobre um ciclo de vida interativo e incremental Objetivos: Objetivos: Acompanhamento contínuo Acompanhamento contínuo Iterações curtas Iterações curtas Retorno mais rápido Retorno mais rápido SCRUM NÃO É A BALA DE PRATA! Não garante sozinho o sucesso de um projeto SCRUM NÃO É A BALA DE PRATA! Não garante sozinho o sucesso de um projeto 18/03/2010 José Alexandre & Lourenço Marcos 31

32 SCRUMSCRUM Quais são os papeis envolvidos? Quais são os papeis envolvidos? Product Owner (PO) Product Owner (PO) Scrum Team Scrum Team Scrum Master Scrum Master 18/03/2010 José Alexandre & Lourenço Marcos 32

33 SCRUM Papel do Product Owner Conhece o produto e as necessidades do cliente Conhece o produto e as necessidades do cliente Representa o cliente Representa o cliente Define os requisitos do produto, bem como sua importância e urgência Define os requisitos do produto, bem como sua importância e urgência É responsável pelo retorno do investimento É responsável pelo retorno do investimento 18/03/2010 José Alexandre & Lourenço Marcos 33

34 SCRUM Papel do Scrum Master É o líder servidor É o líder servidor Responsável por remover os impedimentos do time Responsável por remover os impedimentos do time Por remover interferências externas Por remover interferências externas E por garantir o uso correto do Scrum E por garantir o uso correto do Scrum Ensina Scrum aos envolvidos Ensina Scrum aos envolvidos 18/03/2010 José Alexandre & Lourenço Marcos 34

35 SCRUM Papel do Scrum Team Fazem parte do Scrum team todos os desenvolvedores, arquitetos, analistas,... que participam do projeto Fazem parte do Scrum team todos os desenvolvedores, arquitetos, analistas,... que participam do projeto O time é auto-gerenciável e multifuncional ou multidisciplinar (pessoas com diferentes aptidões) O time é auto-gerenciável e multifuncional ou multidisciplinar (pessoas com diferentes aptidões) Decidem junto com o PO o que entra no Sprint Decidem junto com o PO o que entra no Sprint E são responsáveis pelas estimativas de esforço E são responsáveis pelas estimativas de esforço 18/03/2010 José Alexandre & Lourenço Marcos 35

36 ResumoResumo Quem faz? Engenheiros de software e outros interessados no projeto trabalham juntos em uma equipe ágil. uma equipe ágil enfatiza a comunica;ao e colaboração entre todos que a compõem Por que e importante? O ambiente moderno de negócios que cria sistemas baseado em computador e produto software é apressado e sempre mutável. A engenharia ágil apresenta uma alternativa razoável para a engenharia de software convencional para certas categorias de software e certos tipos de projetos de software. As pesquisas mostram que este modelo entrega rapidamente sistemas bem-sucedido. 18/03/2010 José Alexandre & Lourenço Marcos 36

37 ResumoResumo Quais são os passos? O desenvolvimento ágil poderia ser melhor denominado pequena engenharia de software já que as atividades de estrutura permanecem mais elas são reduzidas a um conjunto mínimo de tarefas que leva a equipe do projeto a construção e entrega. Qual é o produto de trabalho? Clientes e engenheiro de software que têm adotado a filosofia ágil tem a mesma impressão - o único produto de trabalho realmente importante e um - incremento de software operacional que é entregue ao cliente na data combinada. Como se tem a certeza que se fez tudo certo? Quando o incremento de software entregue ao cliente lhe satisfaça 18/03/2010 José Alexandre & Lourenço Marcos 37

38 18/03/2010 José Alexandre & Lourenço Marcos 38 Onde Aprender Mais?

39 Obrigado pela Atenção Dispensada ! 18/03/2010 José Alexandre & Lourenço Marcos 39

40 Onde Aprender Mais? [PRESSMAN 02] PRESSMAN, R. S., Engenharia de Software, 5ª Ed., Makron Books, [SEBESTA 99] SEBESTA, R. W., Concepts of Programming Languages, 4th ed., Addison-Wesley, [SOMMERVILLE 00] SOMMERVILLE, I., Software Engineering, 6th edition, Addison- Wesley, [WELLS 04] WELLS, D., Disponível em Visitado em 14/03/2010;. [BECK 99] BECK, K., Extreme Programming Explained: Embrace Change, 1st Edition, Addison-Wesley, [FOWLER 01] FOWLER, M., BECK, K., Disponível em Visitado em 14/03/2010;. 18/03/2010 José Alexandre & Lourenço Marcos 40 Bibliografia


Carregar ppt "Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil de Desenvolvimento de Software LOURENÇO MARCOS-205003."

Apresentações semelhantes


Anúncios Google