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

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

Metodologias Ágeis Para o Desenvolvimento de Software

Apresentações semelhantes


Apresentação em tema: "Metodologias Ágeis Para o Desenvolvimento de Software"— Transcrição da apresentação:

1 Metodologias Ágeis Para o Desenvolvimento de Software
ANA PAULA 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 O que são métodos ágeis É uma atitude, não um processo prescritivo.
É um suplemento aos métodos existentes, ele não é uma metodologia completa. É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto. Funciona na prática, não é teoria acadêmica

4 O que são métodos ágeis É para o desenvolvedor médio, mas não é um substituto de pessoas competentes. Não é um ataque à documentação, pelo contrário aconselha a criação de documentos que tem valor. Não é um ataque às ferramentas CASE São baseados em princípios e valores

5 Disponível em agilemanifesto.org

6 Ser ágil é ... Evitar o desperdício Buscar a melhoria contínua
Agregar valor ao que está sendo produzido Colaborar Ser pró-ativo

7 PRINCIPAIS METODOLOGIAS Guarda Chuva Ágil

8

9 Scrum

10 Scrum Em Rugby, Scrum é um time de oito integrantes que trabalham em conjunto para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e o time inteiro focando num único objetivo.

11 Scrum Metodologia para gestão de projetos de desenvolvimento de software. Ideal para equipes de 5 a 9 profissionais. Não existem as figuras de programador, testador, arquiteto, etc. Equipe multidisciplinar Time!

12 Scrum Papéis: Product owner: é um representante do cliente. Responsável pelo levantamento de requisitos (histórias) e manutenção do backlog. Scrum master: é o responsável por garantir que os princípios, valores e regras do Scrum sejam aplicados. Time

13 Papéis Product Owner (PO) 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.

14 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

15 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

16 Scrum Princípios: Aceitar as incertezas Constante planejamento
Trabalhar como um time Equipes auto-gerenciáveis Manter um ritmo de trabalho suportável Entregas freqüentes

17 Práticas Ágeis 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. Geralmente duram de 1 a 4 semanas. Ao final do qual é apresentada uma nova funcionalidade integrada ao sistema

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

19 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.

20 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

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

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

23 Práticas Ágeis Backlog é uma lista das atividades a serem realizadas pela equipe. Os itens que compõe a lista são chamados de histórias Todos podem incluir histórias Somente o Product Owner pode priorizá-las Product Owner pode priorizar novamente no início de cada Sprint

24 KANBAN SPRINT1

25

26 Ferramenta - Kanban

27 Ferramenta

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

29

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

31 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;

32 Comunicação Coragem Feedback Respeito Simplicidade

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

34 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;

35 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.

36 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.

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

38 Papéis

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

40 Programadores Foco central da metodologia, mas sem hierarquia.

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

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

43 Cliente O Cliente faz parte da equipe!!

44 Práticas

45 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

46 Testes Desenvolvimento orientado a Testes
Os testes garantem uma segurança para aplicação, eles informam se o código continua produzindo os mesmos resultados.

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

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

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

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

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

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

53 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.


Carregar ppt "Metodologias Ágeis Para o Desenvolvimento de Software"

Apresentações semelhantes


Anúncios Google