Metodologias Ágeis. Aécio Costa

Transcrição

1 Metodologias Ágeis Aécio Costa

2 Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

3 Metodologias Tradicionais Previsão do futuro Pouca interação com os Clientes Ênfase em burocracia (documentos, controles rígidos, formulários e etc.) Avaliação do projeto baseado na evolução da burocracia.

4 Metodologias Tradicionais Em software consideramos: Requisitos estáveis Requisitos futuros são previsíveis gerando... Grande quantidade de erros Falta de flexibilidade

5 Metodologias Tradicionais Processos tradicionais são conhecidos como "pesados". Não receptivos às mudanças. Caráter preditivo, prescritivo, seqüencial, burocrático, rigoroso, orientado a processos e dados, formais e controlado, sucesso é alcançado desde que esteja em conformidade com o que foi planejado. (Pressman, 2006)

6 Metodologias Tradicionais - RUP RUP - Rational Unified Process Processo + Métodos + Linguagem (UML) Framework para gerar processos

7 Metodologias Tradicionais - RUP O que é RUP? Conjunto de atividades bem definidas com responsáveis com artefatos de entrada e saída com dependências entre as mesmas e ordem de execução com modelo de ciclo de vida descrição sistemática de como devem ser realizadas guias (de ferramentas ou não), templates utilizando diagramas de UML

8 Metodologias Tradicionais - RUP Características Principais do RUP O desenvolvimento de sistemas seguindo o RUP é: Iterativo e incremental Guiado por casos de uso (use cases) Baseado na arquitetura do sistema

9 Metodologias Tradicionais - RUP O RUP é iterativo e incremental O ciclo de vida de um sistema consiste de quatro fases: Concepção (define o escopo do projeto) Elaboração (detalha os requisitos e a arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema)

10 Metodologias Tradicionais - RUP O RUP é iterativo e incremental Cada iteração: é planejada realiza uma seqüência de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas geralmente resulta em uma versão executável do sistema é avaliada segundo critérios de sucesso previamente definidos.

11 Metodologias Tradicionais - RUP Fases e iterações

12 Metodologias Tradicionais - RUP Fases e iterações

13 Metodologias Tradicionais - RUP Fases do RUP

14 Metodologias Tradicionais - RUP 6 práticas fundamentais previstas na perspectiva do RUP: 1. Desenvolver software iterativamente 2. Gerenciar requisitos 3. Usar arquiteturas baseadas em componentes 4. Modelar o software visualmente 5. Verificar a qualidade do software 6. Controlar as mudanças do software O RUP leva à criação de um projeto com qualidade satisfatória se todos os envolvidos participarem garantindo a qualidade nos processos em que são responsáveis.

15 Metodologias Tradicionais - RUP O RUP é baseado na arquitetura do sistema Arquitetura visão geral do sistema em termos dos seus subsistemas e como estes se relacionam A arquitetura é prototipada e definida logo nas primeiras iterações O desenvolvimento consiste em complementar a arquitetura A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso.

16 Metodologias Tradicionais - RUP O RUP é baseado na arquitetura do sistema 5 Visões de arquitetura

17 Metodologias Tradicionais - RUP Organização do RUP Fluxos de atividades Atividades passos entradas e saídas guias (de ferramentas ou não), templates Responsáveis (papel e perfil, não pessoa) Artefatos

18 Metodologias Tradicionais - RUP Planejamento e Gerenciamento

19 Metodologias Tradicionais - RUP Elicitação de Requisitos

20 Metodologias Tradicionais - RUP Análise e Projeto (Simplificado)

21 Metodologias Tradicionais - RUP Implementação

22 Metodologias Tradicionais - RUP Testes

23 Metodologias Tradicionais - RUP Verificação da qualidade do software no RUP O RUP assume que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e provê testes nos processos para medir este nível. Artefatos do RUP para a Qualidade

24 Metodologias Ágeis Metodologias Ágeis

25 Metodologias Ágeis Discussão de especialistas em maneiras de melhorar o desempenho dos seus projetos. Scrum, Extreme Programming (XP) e etc. Tornou-se popular em 2001 Aliança ágil e o Manifesto Ágil.

26 Metodologias Ágeis O que a metodologia Ágil valoriza: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano

27 Manifesto Ágil Criadores do Manifesto Ágil

28 Manifesto Ágil - 12 Princípios Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

29 Manifesto Ágil - 12 Princípios O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

30 Manifesto Ágil - 12 Princípios Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

31 Manifesto Ágil Metodologias Utilizadas DSDM Crystal Scrum XP FDD

32 Manifesto Ágil

33 Metodologias Ágeis Características Métodos ágeis compartilham a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Foco na comunicação interativa Redução do esforço empregado em artefatos intermediários. (Cohen et al., 2004)

34 Metodologias Ágeis Aplicabilidade Métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente. Três dimensões chaves da organização: Cultura, pessoas e comunicação.

35 Metodologias Ágeis

36 Metodologias Ágeis Agile vs Waterfall

37 Metodologias Ágeis Métodos ágeis funcionambem quando o problema e asolução são em grande parte desconhecidos. Waterfall não se aplica nestes casos.

38 Metodologias Ágeis

39 Metodologias Ágeis

40 Metodologias Ágeis Uso contínuo

41 Metodologias Ágeis

42 Metodologias Ágeis Precisamos de Software Funcionando!

43 Metodologias Ágeis Resumindo: ágil é mentalidade! Mudança de postura e quebra de paradigmas; Gestão flexibilizada

44 Metodologias Ágeis Resumindo: ágil é mentalidade!

45 Metodologias Ágeis rso_10_anos_ageis_usp_ufpe.pdf

46 Scrum O histórico e o conceito d

47 Scrum 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 Ken Schwaber

48 Scrum

49 Scrum O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

50 Scrum Características do Scrum Equipes que se auto-organizam O produto evolui em uma série de Sprints mensais; Os requerimentos são listados em um Product Backlog Não há prática de engenharia prescrita (o Scrum adequa-se a todas)

51 Scrum Papéis

52 Scrum Product Owner Define as funcionalidades do produto Decide datas de lançamento e conteúdo Responsável pela rentabilidade (ROI) Prioriza funcionalidades de acordo com o valor de mercado Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos

53 Scrum ScrumMaster Representa a gerência para o projeto Responsável pela aplicação dos valores e práticas do Scrum Remove obstáculos Garante a plena funcionalidade e produtividade da equipe Garante a colaboração entre os diversos papéis e funções Escudo para interferências externas

54 Scrum Team Entre 5 e 9 pessoas Multi-funcional Programadores, testadores, desenvolvedores de interfaces, etc. Tempo integral Raras exceções (Ex.: Administrador de Base de Dados) Auto-organizável Idealmente, sem títulos, ainda que possível Trocas só na mudança de Sprints

55 Product BackLog O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto.

56 Scrum Sprints Projetos Scrum progridem em uma série de sprints Similar às iterações do XP Ocorre em um período de duas a quatro semanas Um período constante leva a um melhor ritmo O produto é projetado, codificado e testado durante o sprint

57 Scrum Nenhuma mudança durante o Sprint!

58 Scrum

59 Scrum Sprint Planning A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir O Sprint Backlog é criado Tarefas identificadas e estimadas De forma colaborativa, não apenas feito pelo Scrum Master

60 Scrum Sprint Planning

61 Scrum Daily Scrum Daily Diário 15 minutos Todos em pé! Não é para a solução de problemas Todo mundo é convidado Apenas os membros da equipe, ScrumMaster, dono do produto podem falar Ajuda a evitar reuniões adicionais desnecessárias

62 Scrum Daily Scrum Daily

63 Scrum Board O quadro de tarefas garante visibilidade do status das user stories e tarefas, o mínimo tem 3 colunas (to do - doing - done)

64 Sprint Review Equipe apresenta os resultados obtidos durante o Sprint Tipicamente, demonstração de novas funcionalidades ou sua arquitetura

65 Retrospectiva do Sprint Periodicamente, observe o que funciona e o que não funciona Tipicamente de 15 a 30 minutos Feita após cada Sprint Toda a equipe participa ScrumMaster Dono do produto Membros da equipe Clientes e outros

66 Modelo - Retrospectiva da Sprint

67 Burndown

68 Burndown O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe: story points dias ideais team days etc

69 User Stories User stories devem ser compreensíveis por todos: usuários, cliente e time de desenvolvimento. Itens de Backlog podem ser escritos como User Stories Facilita a priorização Facilita a estimativa

70 User Stories Template para User Story