Metodologias Ágeis Para o Desenvolvimento de Software

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 é que projetos falham?

3 Falta de envolvimento do usuário final?

4 Falha no levantamento de requisitos?

5 Cronogramas irreais?

6 Falta de gerenciamento de controle de mudanças?

7 Falta de testes

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

9 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

10 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

11 Quem usa isso?

12 RESPONDA... O que ocorreria onde você trabalha caso:
–Alguma das entregas não forem feitas no prazo? –A meta de orçamento do mês não for atingida? –O desenvolvedor faz uma entrega cujo resultado desagrade o cliente?

13 Disponível em agilemanifesto.org

14 Manifesto Ágil Propõe, através dos seus 12 princípios, uma metodologia de desenvolvimento de software baseada em : forte interação com o cliente; redução e simplificação da quantidade de documentos gerados durante o projeto; entrega freqüente de executáveis

15 Por que usar?

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

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

18 Você é ágil ? Busca ir além do que lhe foi pedido ? Fazer sempre melhor ? Fica esperando que lhe digam o que fazer ? Onde trabalhar ? É capaz de se adaptar ? De lidar com as mudanças ? É colaborativo ? Busca prazer naquilo que faz ? Vê propósito no que faz ? É diligente, inspirador e compreensivo ? Consegue manter equilíbrio entre trabalho e vida pessoal ?

19 OBSERVE... Quem você é ?

20 PRINCIPAIS METODOLOGIAS Guarda Chuva Ágil

21

22 Scrum

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

24 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!

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

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

27 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

28 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

29 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

30 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

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

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

33 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

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

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

36 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

37 KANBAN SPRINT1

38

39 Ferramenta - Kanban

40 Ferramenta

41 Práticas Ágeis Daily Meetings: reuniões diárias de 15 minutos em pé, onde todos respondem às perguntas: O que você realizou desde a última reunião? Quais problemas você enfrentou? Em que você trabalhará até a próxima reunião?

42 Referências Abrahamson, Pekka; Salo, Outi; Ronkainen, Jussi. Agile Software Development Methods: review and analysis. Otamedia Oy, Espoo VT Publications 478. Disponível em Beck, Kent. Extreme Programming Explained: embrace changes. Addison-Wesley, 2000 Freire, Flávia. Desvendando o Scrum. Revista TIDigital pags 36 – 43. abr 2009.

43 Referências Cohn, Mike. User Stories Applied For Agile Software Development. Edt. Pearson. 2004 Costa, Fernando. Agilidade: scrum e xp. Disponível em Kniberg, Henrik. Scrum and XP from the Trenches. Disponível em