Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouCarmem Fidalgo de Almeida Alterado mais de 8 anos atrás
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
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
26
Ferramenta - Kanban
27
Ferramenta
28
XP (eXtreme Programming)
Metodologias Ágeis XP (eXtreme Programming) Pós-Graduação em Engenharia de Software
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.
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.