Centro Universitário de Lins - Unilins

Apresentação em tema: "Centro Universitário de Lins - Unilins"— Transcrição da apresentação:

1 Centro Universitário de Lins - Unilins
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 18/03/2010 José Alexandre & Lourenço Marcos

2 Sumário Resumo 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

3 Premissas Básicas do Modelo Tradicional
É 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. 18/03/2010 José Alexandre & Lourenço Marcos

4 O cenário vivido por muitos
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 18/03/2010 José Alexandre & Lourenço Marcos

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

6 ... CAOS 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 ... CAOS Nós chamamos de CAOS uma situação perturbadora e desanimadora. Uma situação onde uma empresa utilizando um processo definido ou não trabalha de forma a obter muitos riscos em seus projetos e muitas vezes obtendo um custo muito alto, e ainda sim não conseguindo manter um projeto de boa qualidade interna e externa. Mas esse problema não é novo, É assim, que Fevereiro 2001, em Utah 17 caras lançaram o ... 18/03/2010 José Alexandre & Lourenço Marcos

7 O Manifesto Ágil 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 18/03/2010 José Alexandre & Lourenço Marcos

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

9 Agilidade e a Engenharia de Software
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; 18/03/2010 José Alexandre & Lourenço Marcos

10 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.” 18/03/2010 José Alexandre & Lourenço Marcos

11 Os 12 Princípios do Manifesto Ágil
12 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 18/03/2010 José Alexandre & Lourenço Marcos

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

13 Examinando as Premissas
Equipes motivadas, comunicando-se melhor, produzem com mais qualidade, aumentando a eficácia do processo Maior interação causa melhor comunicação Alta interação fortalece o sentimento de equipe Ações Vontades Objetivo Necessidades Equipes motivadas e comunicação eficaz Padronização, produtividade, controle e medição Foco nos indivíduos e interações Ter um ambiente de projeto eficaz e eficiente Não é possível ter foco em ambos! Conflito? Foco nos processos e ferramentas Um projeto necessita de mecanismos de controle Padronização leva à reutilização, que aumenta a produtividade e diminui os erros 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 18/03/2010 José Alexandre & Lourenço Marcos

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

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

16 Examinando as Premissas
Nenhum cliente fica satisfeito se não obtiver o que deseja, não importando que tenha mudado de idéia durante o projeto O cliente e a equipe aprendem durante o projeto Murphy participa ativamente dos projetos Ações Vontades Objetivo Necessidades Entregar um produto que o cliente deseja Responder às mudanças Completar um projeto com sucesso Não é possível conseguir ambos! Conflito? Entregar no prazo e dentro do orçamento Seguir um plano É 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 Ter um mapa do caminho ajuda muitíssimo na viagem Sem um plano, como saber quando há mudança? 18/03/2010 José Alexandre & Lourenço Marcos

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

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

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

20 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 18/03/2010 José Alexandre & Lourenço Marcos

21 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 Demonstrar atitude de “posso fazer” Aceitar novas tarefas Ter uma carreira de sucesso Cumprir os compromissos Completar o trabalho compromissado 18/03/2010 José Alexandre & Lourenço Marcos

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

23 Mas na realidade foi assim...
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 Data de entrega Imaginou-se assim... Tempo da tarefa Segurança Trabalho real na tarefa Mas na realidade foi assim... Segurança Tempo da tarefa Tempo 18/03/2010 José Alexandre & Lourenço Marcos

24 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+7=19 8 7 1+3+2=8 Critério Hipotético Universal de Tentativa e Erro 1 3 2 18/03/2010 José Alexandre & Lourenço Marcos

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

26 XP – EXtreme Programming
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 “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

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

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

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

30 SCRUM 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 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

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

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

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

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

35 SCRUM Papel do Scrum Team
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) Decidem junto com o PO o que entra no Sprint E são responsáveis pelas estimativas de esforço 18/03/2010 José Alexandre & Lourenço Marcos

36 Resumo Quem faz? Por que e importante?
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

37 Resumo Quais são os passos? Qual é o produto de trabalho?
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

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

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

40 Bibliografia Onde Aprender Mais?
[PRESSMAN 02] PRESSMAN, R. S., “Engenharia de Software”, 5ª Ed., Makron Books, 2002. [SEBESTA 99] SEBESTA, R. W., “Concepts of Programming Languages”, 4th ed., Addison-Wesley, 1999. [SOMMERVILLE 00] SOMMERVILLE, I., “Software Engineering”, 6th edition, Addison- Wesley, 2000. [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, 1999. [FOWLER 01] FOWLER, M., BECK, K., Disponível em Visitado em 14/03/2010;. 18/03/2010 José Alexandre & Lourenço Marcos