Desenvolvimento Ágil aplicado aos Projetos de Software

Apresentação em tema: "Desenvolvimento Ágil aplicado aos Projetos de Software"— Transcrição da apresentação:

1 Desenvolvimento Ágil aplicado aos Projetos de Software
Metodologias Ágeis Desenvolvimento Ágil aplicado aos Projetos de Software Ana paula alves de lima

2 Por que ser ágil? Crescentes pressões do mercado por:
Inovação, Produtividade (prazos cada vez mais curtos), Flexibilidade, Melhoria no desempenho/qualidade dos projetos de desenvolvimento de SW O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.

3 Quem usa isso?

4 História Década de 80 Década de 90
75 anos atrás IIDD – Desenho e desenvolvimento interativo e incremental Aumentar satisfação do cliente Evitar o desencorajamento da Gestão Década de 80 Aprimoramento da Engenharia de Software Diversificação das linguagens de programação Década de 90 Maturação dos processos de desenvolvimento de Software Semente dos modernos processos de Desenvolvimento Ágil especialistas se reúnem nos EUA para discutir modernas formas de se desenvolver Software Estabelecida a Aliança Ágil Manifesto Ágil Princípios comuns compartilhados por todos os métodos de sucesso aplicados pelos especialistas durante suas carreiras

5 Disponível em agilemanifesto.org

6 Guarda Chuva Ágil

7

8 Por que usar?

9 Por que usar? Dos 63% restantes:
2/3 possuem problemas Estouro de Prazo Não atendem as necessidades Estão cheio de defeitos 1/3 é um total fracasso Cancelado/engavetado Nunca colocado em produção ou utilizado pelo cliente Dos casos de sucesso, em geral apenas 20% das funcionalidades são realmente úteis.

10 Por que usar? Suposições de início de projeto
Os requisitos são 100% conhecidos e foram minuciosamente detalhados O Desenvolvedor sabe construir Nada irá mudar ao longo do caminho Realidade que deve ser observada : “Um processo rígido ou resistente a mudanças produz produtos medíocres. Os clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a idéia inicial, ao invés de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor.” [Jeff Sutherland] Idéias, novas tecnologias e opções surgem no decorrer do projeto. Desta forma uma nova idéia não deveria ser mau vista pela equipe/gestor. Sim, as coisas mudam durante o caminho

11

12 SCRUM

13 Por que Scrum? “O Scrum não é um processo previsível, ele não define o que fazer em todas as circunstâncias” KEN SCHWABER (2004) É um framework ágil leve que gerencia e controla o desenvolvimento do software aumentando a produtividade e reduzindo o tempo para obter excelentes resultados; Bastante objetivo Papéis e Responsabilidades bem definidas Fácil adaptação Curva de aprendizado baixa Não é um processo previsível É um framework, um conjunto de práticas O Scrum não vai dizer exatamente o que fazer, não irá resolver todos os seus problemas, mas com certeza os problemas serão mais facilmente identificados.

14 Elementos do Scrum – EQUIPE DE ATÉ 6 PESSOAS
PAPÉIS Product Owner Scrum Master Time REUNIÕES ou CERIMÔNIAS Sprint Planning Daily Scrums Sprint Review Sprint Retrospective ARTEFATOS Product Backlog Sprint Backlog Burndown Chart

15 O que é Sprint No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado. O trabalho é dividido em iterações, que no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas.

16

17 Papéis Define as funcionalidades do produto
Define as datas dos releases Responsável pelo retorno do investimento (ROI) do projeto Prioriza as funcionalidades de acordo com seu valor de negócio Ajusta o product backlog a cada sprint, se necessário. Pode ser o representante de um cliente, ou o próprio cliente. Product Owner (PO)

18 Papéis Time Multi-disciplinar, com 7 (+-2) membros
Define o Sprint e define como será feito o trabalho Tem o direito de fazer o que estiver ao seu alcance para alcançar o Sprint Auto-gerenciado: o time se organiza e se gerencia Demonstra o que foi feito para o Product Owner ao fim de cada Sprint Time

19 Papéis Responsável pelo processo, incluindo a realização do Daily Scrum e datas e horários das reuniões Remove os impedimentos Garante que o time está sempre funcionando e produtivo Facilita a cooperação entre todos os membros do time Protege o time das interrupções externas Scrum Master

20 Reuniões - Sprint Planning
Daily Scrum Sprint Review Sprint Retrospective PLANEJAMENTO Entendimento do Escopo Estimativas de complexidade Definição do Sprint

21 Sprint Planning O Sprint Planning Meeting é uma reunião na qual estão
presentes o Product Owner, o Scrum Master e todo o Time, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog. Coletivamente, o Time e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

22 Reuniões – Daily Scrum Sprint Planning Daily Scrum Sprint Review
Sprint Retrospective 3 PERGUNTAS 1. O que foi feito desde o último DS? 2. O que será feito hoje? 3. O que esta impedindo? Peer-pressure (em pé) Máximo de 15 minutos Comprometimento

23 Reuniões – Sprint Review
Sprint Planning Daily Scrum Sprint Review Sprint Retrospective DEMONSTRAÇÃO Apresentação das funcionalidades Aceitação do Product Owner

24 Reuniões – Sprint Retrospective
Sprint Planning Daily Scrum Sprint Review Sprint Retrospective REVISÃO O que foi bom? O que pode ser Melhorado?

25 Artefatos Product Backlog Sprint Backlog Burndown Chart

26 Product Backlog O Backlog do Produto é uma lista contendo todas as
funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários. A partir dele origina-se o Backlog do Sprint que é o que será feito naquela tarefa.

27 Quadro de Acompanhamento – Sprint Backlog

28 Burn Down Chart O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.

29 XP (eXtreme Programming)
Metodologias Ágeis XP (eXtreme Programming) Pós-Graduação em Engenharia de Software

30

31 Indivíduos e interações ao invés de processos e ferramentas
Software executável ao invés de documentação.

32 Colaboração do cliente ao invés de negociação de contratos.
Respostas rápidas a mudanças ao invés de seguir planos.

33 O Garotinho chamado CLIENTE
Software – Aperto de mão Cliente – Um abraço Garra – Gargalhada Bem Vindos - Palmas

34 O que é o XP? Criar sistemas de melhor qualidade.
Metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Criar sistemas de melhor qualidade. Produzidos em menos tempo e de forma mais econômica que o habitual. Identificou o que tornava simples e o que dificultava o desenvolvimento de software.

35 Como fazer? Pequeno conjunto de valores e práticas
A Programação Extrema é uma das metodologias ágeis mais conhecidas e utilizadas na atualidade. Desenvolvidas para: Equipes médias e pequenas (2 a 12 pessoas); Pequeno conjunto de valores e práticas Baseada em cinco valores, alguns princípios e várias práticas que ocorrem no decorrer das atividades;

36 Comunicação Coragem Feedback Respeito Simplicidade

37 Comunicação Para que um projeto seja um sucesso é necessário muita interação entre as equipes: programadores, clientes e treinador; VS

38 Coragem “A única constante em um projeto de software é a mudança”
Alterar um código em produção sem causar bugs, com agilidade, exige muita coragem e responsabilidade;

39 As respostas às decisões tomadas devem ser rápidas e visíveis.
Feedback Quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar As respostas às decisões tomadas devem ser rápidas e visíveis.

40 Respeito Dá sustentação a todos os demais valores
Todos têm a sua importância dentro da equipe e devem ser respeitados e valorizados.

41 Simplicidade Apenas aquilo que é claramente necessário
É um dos valores mais importantes. Normalmente o que o cliente quer é mais simples.

42 Papéis

43 Acompanhador (ou tracker)
Papéis... Programadores Treinador (ou coach) Acompanhador (ou tracker) Cliente

44 Programadores Foco central da metodologia, mas sem hierarquia.

45 Treinador (coach) Pessoa com experiência
no time, é responsável por lembrar aos outros das práticas e valores do XP.

46 Acompanhador (tracker)
Responsável por trazer informações que mostrem o andamento do projeto que ajudem a tomar decisões de implementação.

47 Cliente O Cliente faz parte da equipe!!

48 Práticas

49 Práticas... Testes Refatoração Programação Pareada (em pares)
Propriedade Coletiva Integração Contínua Semana de 40 horas Cliente junto aos desenvolvedores Padronização do código

50 Testes Desenvolvimento orientado a Testes
Os testes devem ser escritos antes do desenvolvimento.

51 Refatoração Conjunto de técnicas para simplificar, melhorar o código!

52 Programação em Pares Enquanto um programador digita, o outro observa, pensa em melhorias, alternativa.

53 Propriedade Coletiva O código é de todos e ninguém precisa de permissão para modificá-lo Não pertence a um único programador.

54 Integração Contínua Depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada entre todos os desenvolvedores.

55 Semana de 40 horas Trabalhar com qualidade
Programação não rende se o programador não estiver descansado e disposto. Trabalhar com qualidade

56 Cliente junto O cliente não é alguém de fora e sim um membro da equipe.

57 Padronizações Se o time seguir padrões pré-definidos de codificação, mais fácil será manter e entender o que já está feito, reforçando a comunicação.

58 Métodos Ágeis Mais Conhecidos
FDD (Feature Driven Development): Metodologia ágil de desenvolvimento de software guiado por funcionalidades; Metodologia que combina as melhores práticas do gerenciamento ágil de projetos com abordagens completas para ES orientada por objetos; Seu lema é: "Resultados frequentes, tangíveis e funcionais." Técnicas e Projeto de Sistemas – Técnico Subsequente

59 ATIVIDADES 2) Defina o que Scrum.
1) Quais são as principais metodologias ágeis? Cite três. 2) Defina o que Scrum. 3) Quais os principais elementos do Scrum. 4) O que é o XP? 5) Quais seus valores; 6) Cite os papeis da equipe; 7) Cite as práticas.