Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente é mais importante do que negociação de contratos. Adaptação a mudanças é mais importante do que seguir o plano inicial. WebSite: http://www.agilemanifesto.org/ 1
Metodologias Ágeis Métodos ágeis (AM) é uma coleção de metodologias baseada na prática para modelagem efetiva de sistemas baseados em software. É uma filosofia onde muitas metodologias se encaixam. As metodologias ágeis aplicam uma coleção de práticas, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia. 2
O que são os Modelos Ágeis? Um modelo ágil é um modelo bom o suficiente, nada mais, o que implica que ele exibe as seguintes características: 1.Ele atende seu propósito 2.Ele é inteligível. 3.Ele é suficientemente preciso. 4.Ele é suficientemente consistente. 5.Ele é suficientemente detalhado. 6.Ele provê um valor positivo. 7.Ele é tão simples quanto possível. 3
O que é (e não é) métodos ágeis? 1. É uma atitude, não um processo prescritivo. 2. É um suplemento aos métodos existentes, ele não é uma metodologia completa. 3. É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto. 4. É uma coisa que funciona na prática, não é teoria acadêmica. 4
O que é (e não é) métodos ágeis? (cont.) 5. É para o desenvolvedor médio, mas não é um substituto de pessoas competentes. 6. Não é um ataque à documentação, pelo contrário aconselha a criação de documentos que tem valor. 7. Não é um ataque às ferramentas CASE. 5
Gerenciamento e Desenvolvimento Ágil de Projetos de Software - SCRUM Baseado em material de: Luciano Soares de Souza 6
SCRUM Iterativo e Incremental Resposta às mudanças Maior valor para o negócio Práticas de engenharia livres Framework de processo
Visão Geral do Scrum
Papéis no Scrum
Product Owner Determina a Visão do Projeto Define as funcionalidades Determina o valor de negócio Responsável pelo ROI Prioriza funcionalidades Aceita ou rejeita o resultado do trabalho
Scrum Master Valores e Práticas do Scrum Conduz as reuniões diárias, de planejamento e revisão Resolve os impedimentos Escudo para interferências externas
Time Entre 5 e 10 pessoas Multi-funcional Auto organizável e Auto gerenciável Estima as funcionalidades Define as tarefas Levanta impedimentos (externos)
Product Backlog Criado a partir da Visão do Produto Contém todos os requisitos funcionais e não funcionais Geralmente escritos em User Stories Idealmente representado por itens que agregam valor aos usuários ou cliente Priorizado pelo Product Owner
Product Backlog - Exemplo Backlog item (BLI) Business Value (BV) [BLI001] As a standard user, search for a movie 1000 [BLI002] As a standard user, search for movie reviews 1000 [BLI003] As a standard user, view the top movies 1000 [BLI004] As a standard user, search for theaters 700 [BLI005] As a standard user, search for movie trailers 700 [BLI006] As a standard user, create the user profile 500 [BLI007] As a standard user, edit the user profile 300 [BLI008] Integration with LDAP 100
Sprint Planning 1 Reunião de no máximo 4 horas Revisar o product backlog Determinar o objetivo da sprint Selecionar parte do product backlog Estimar e priorizar IBLs (itens de backlog)
Estimando o Product Backlog 2 1 3
Estimando com Planning Poker 1 2 3
3 5 2 5 8 8 20 13
Sprint Planning 2 É um planejamento tático da equipe Os itens selecionados do Product Backlog são destrinchados em tarefas O resultado final é o Sprint Backlog
Sprint Backlog As tarefas não são atribuídas aos membros do time Cada membro escolhe sua tarefa diariamente Qualquer membro do time pode adicionar ou remover itens do Sprint Backlog (durante o daily meeting)
Sprint Backlog Task Board IBLs Tasks To Do Work In Progress Done [IBL001] [IBL003] [IBL002]
Prioridade Plannings 1 e 2 Alta Histórias A B C D E F O que está dentro do Sprint Não pode ser alterado. - O que está fora do Sprint pode Ser alterado de acordo com a necessidade do cliente. Baixa G H I - Ele pode alterar prioridades, inserir novas tarefas ou retirar tarefas existentes. - Algumas tarefas podem ser inseridas pela equipe. Ex: Montar ambiente para Integração contínua
Sprint Um período de tempo entre 2 a 4 semanas Todos os Sprints devem possuir uma estrutura exatamente igual Funcionalidades construídas a partir dos IBLs selecionados Time define a organização necessária para efetuar o trabalho
Planejamento Sprint X Retrospectiva Apresentação Sprint X Planejamento Sprint X+1 Estrutura de um Sprint Reuniã o diária Reuniã o diária Reuniã o diária Reuniã o diária Reuniã o diária Reuniã o diária Reuniã o diária Reuniã o diária
Reunião Diária Objetivo Cada membro deve responder as seguintes perguntas: 1. O que você fez desde a última reunião diária? 2. O que você pretende fazer até a próxima reunião diária? 3. Existe algum problema que o impeça de realizar suas atividades? Impedimentos reportados aqui Duração 15 minutos (não mais que isso) Sugestão: Todos em Pé Qualquer pessoa pode participar, mas apenas o Scrum Master e os Membros da Equipe pedem falar
Quadro Kanban IBLs Tasks To Do Work In Progress Done [IBL001] [IBL003] [IBL002]
Sprint Burndown
Sprint Review (Demonstração) Objetivo Mostrar o que foi produzido no Sprint Participantes Product Owner, Scrum Master, membros do time, clientes, Usuários, Stakeholders e qualquer pessoa que esteja interessada no resultado da Sprint Qualquer participante pode falar, fazer perguntas ou observações
Sprint Review (Demonstração) Quand o time diz feito, o que isto significa? Conceito de pronto Não esconde trabalho não finalizado para manter a confiança do cliente O resultado da reunião deve ser um entendimento comum sobre o resultado da sprint e o estado do produto
Sprint Retrospective Objetivo Enumerar o que funcionou e o que não funcionou durante o Sprint Participantes Product Owner, Scrum Master e os membros do time Time deve encontrar soluções para os problemas mais críticos
Retrospectiva - Exemplo O que Funcionou Testes Reuniões Diárias O que não funcionou Comunicação entre os membros Alguns membros chegam tarde Faltou melhor planejame nto do Sprint Usuário Distante
O Scrum não é... Não é a bala de prata Não te diz exatamente o que fazer Não resolve todos os seus problemas...... mas ajuda identificá-los de maneira mais fácil
A família Crystal de Métodos Criada por Alistair Cockburn http://alistair.cockburn.us/crystal Editor da série Agile Software Development da Addison- Wesley. 43
Feature Drive Development - Processos O FDD consiste de 5 processos principais: 44
Adaptive Software Development Desenvolvimento Adaptável de Software James A. Highsmith III 2000 45
ASD - Características Iterativo e incremental Sistemas grandes e complexos Arcabouço para evitar o caos Cliente sempre presente Desenvolvimento de aplicações em conjunto (Joint Application development JAD) 46
ASD - Fases O ASD possui ciclos de 3 fases: 47
O futuro das metodologias ágeis % de empresas com mais da metade dos projetos definidos como ágeis 2001: 21% 2002: 34% 2003 (previsão): 50% Metodologias ágeis mais usadas XP: 38% FDD (Feature-Driven Development): 23% ASD (Adaptive Software Development): 22% DSDM: 19% Complexidade dos projetos é similar (rigorosas X ágeis), ágeis trabalham com prazos similares, mas equipes muito menores. http://www.cutter.com/freestuff/apmupdate.pdf