eXtreme Programming Eduardo Aranha

O surgimento de XP Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software Identificou o que tornava simples e o que dificultava o desenvolvimento de software Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia eXtreme Programming

O que é eXtreme Programming? Metodologia ágil, leve Desenvolvido para: Equipes médias e pequenas (2 a 12 pessoas) Requisitos vagos e em constante evolução Possui um conjunto de valores para nortear desenvolvimento Conjunto de práticas mostra sua estrutura

Foco na satisfação do cliente Desenvolver o que o cliente precisa no momento que é necessário

Manifesto ágil Valorização de: Indivíduos e interação 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

Princípios básicos Comunicação Simplicidade Programadores comunicam-se frequentemente entre si e com os clientes Devem trabalhar na mesma sala, conversar pessoalmente ou através de chats, etc. Simplicidade Projeto do SW é simplificado continuamente Processo adaptado, caso algo não esteja funcionado

Princípios básicos Feedback Cliente está sempre participando do desenvolvimento do sistema Testes de unidade e de aceitação fornecem feedback sobre o sistema Oportunidades e problemas são identificados o mais rápido possível

Princípios básicos Coragem Indicar problemas no projeto, parar quando está cansado, pedir ajuda quando necessário Simplificar código que está funcionado, dizer ao cliente que não será possível implementar um requisito no prazo estimado Seguir o XP como deve ser

Práticas e Regras de XP: Planejamento Estórias de uso Usados como requisitos do sistema Mesmo propósito dos casos de uso, porém menores e mais simples Escritos na linguagem do cliente com o mínimo de detalhes para a estimativa de custos São estimados em “tempo ideal de trabalho” Deve custar entre 1 e 3 semanas de desenvolvimento

Práticas e Regras de XP: Planejamento Jogo do planejamento Planejamento de versões No início do projeto especifica-se que estórias de uso serão implementadas em cada versão Define-se as datas de liberação das versões Versões são divididas em iterações

Práticas e Regras de XP: Planejamento Versões frequentes e pequenas Funcionalidades implementadas são rapidamente entregues ao cliente Permite um feedback mais rápido do cliente reduzindo o impacto de mudanças de requisitos Versão pode ter inclusive uma única iteração

Práticas e Regras de XP: Planejamento Iterações Desenvolvimento dividido em iterações Possuem duração entre 1 e 3 semanas Funcionalidades são entregues no final de cada iteração Prazos devem ser levados a sério, negocie o escopo se for necessário

Práticas e Regras de XP: Planejamento Planejamento de Iterações Feito no início de cada iteração Estórias de uso são escolhidas de acordo com a importância pro cliente e do risco pro projeto Estórias são divididas em tarefas de 1 a 3 dias Tarefas são distribuídas entre programadores e estimadas pelos próprios executores Estimativa preferencialmente baseada no passado Leva-se em conta a programação em pares

Práticas e Regras de XP: Planejamento Planejamento de Iterações (cont.) Estórias são adicionadas ou removidas para completar o tempo da iteração Usa a velocidade do projeto para transformar estimativas em tempo ideal para tempo real

Práticas e Regras de XP: Planejamento Medida da velocidade de projeto Indica a produtividade da equipe no projeto Razão entre a o que foi produzido e o que foi estimado a cada iteração Pode ser medido durante uma iteração Variações dramáticas em mais de uma iteração sugerem renegociação de prazo e escopo das versões

Práticas e Regras de XP: Planejamento Reuniões rápidas (stand-up meeting) Faz a comunicação entre toda a equipe para comunicar problemas, soluções, etc. Reunião feita em pé com poucos minutos de fala para cada integrante

Práticas e Regras de XP: Projeto Simplicidade Projetos simples tomam menos tempo que os complexos Evitar generalizações e abstrações desnecessárias no momento É mais rápido e barato Requisitos mudam frequentemente

Práticas e Regras de XP: Codificação O cliente está sempre disponível Não deve só ajudar a equipe de desenvolvimento Deve ser parte da equipe Comunicação com o cliente é feita em todas as fases de um projeto XP Estórias de uso, planejamento de versões, feedback do sistema, testes de aceitação, etc.

Práticas e Regras de XP: Projeto Cartões CRC Class, Responsibilities, and Collaboration Descrevem as classes e métodos do sistema Permitem a simulação da execução do sistema através da invocação dos métodos das classes

Práticas e Regras de XP: Codificação Programação em pares Duas pessoas programando em um mesmo computador pensam melhor que uma Revezamento: um programa enquanto o outro projeta e faz revisão on-line do código digitado Ganho de qualidade compensa o uso de duplas Auxilia a difusão de conhecimento

Práticas e Regras de XP: Planejamento Rotação de pares de programadores Ajuda ainda mais a eliminar as pessoas consideradas “ilhas de conhecimento” Cada um da equipe passa a conhecer todas as partes do sistema Os pares devem sempre ser encorajados a trabalhar em partes do sistema desconhecidas por eles

Práticas e Regras de XP: Codificação Propriedade coletiva do código Todos são responsáveis por todo código Permite que pessoas forneçam idéias para toda parte do sistema Diminui o risco de possuir pessoas insubstituíveis no projeto

Práticas e Regras de XP: Projeto Criar spike solutions para reduzir riscos Programas muito simples utilizados para verificar o uso determinadas soluções e tecnologias Utilizados para reduzir os riscos técnicos do projeto ou validar as estimativas realizadas

Práticas e Regras de XP: Projeto Não adicionar funcionalidades antecipadamente Requisitos mudam rapidamente Mantém o código limpo de adivinhações sobre o que pode ser usado no futuro Mantém a produtividade

Práticas e Regras de XP: Codificação Código tem sempre que seguir um padrão Mantém o código consistente e uniforme Facilita a leitura e entendimento por outros programadores

Práticas e Regras de XP: Codificação 40 horas semanais Horas extras não remuneradas prejudicam motivação da equipe Ao invés disto, modifique o escopo ou o prazo do projeto

Práticas e Regras de XP: Testes Testes unitários Teste das menores unidades (classes, métodos, ...) Identifica bugs no código Protege o código de manutenções indevidas Automação dos testes paga o custo da criação dos testes

Práticas e Regras de XP: Testes Testes unitários são escritos para detectar bugs identificados Criação do teste unitário que identifique o bug antes de corrigí-lo Bugs tem tendência de ressurgir posteriormente

Práticas e Regras de XP: Codificação Testes antes da codificação Limita o escopo da solução a ser implementada Serve de especificação do código testado Facilita o entendimento do código a ser criado Garante que os testes vão ser criados

Práticas e Regras de XP: Codificação Integração contínua Módulos do sistema são integrados diversas vezes ao dia Todos os testes de unidade são executados Identificação rápida de bugs inseridos Programador sabe que trechos de código foram alterados nas últimas horas

Práticas e Regras de XP: Projeto Fazer refactoring sempre que possível Reestruturação sem acrescentar funcionalidade Remove redundâncias e melhora a qualidade do projeto Retira códigos não utilizados Testes unitários “garantem” que código mantém mesmo comportamento

Práticas e Regras de XP: Testes Execução periódica de testes de aceitação e publicação de score Testes de aceitação criados a partir das estórias de uso a serem implementadas na iteração Clientes verificam a corretude dos testes escritos Devem ser automatizados e regressivos

Dependência entre práticas Algumas práticas possuem inter-dependências Refactoring: Testes unitários Rotação de pessoas: programação em pares Propriedade coletiva de código: refactoring, testes unitários, integração contínua 40h semanais: planejamento junto ao cliente Etc.

Modelagem de XP Site oficial não tem modelo preciso do processo Trabalho realizado por Américo no CIn modela XP usando a meta-linguagem SPEM

Meta-linguagem SPEM Software Process Engeneering Metamodel Padrão formal da OMG aprovado em novembro de 2002 Apoiado pela Rational, IBM, Computer Associates e outras Orientado a objetos, utiliza UML como notação

Principais elementos de SPEM

Principais elementos de SPEM

Diagrama de atividades – Modelagem de XP (parcial)

Diagrama de atividades – Modelagem de XP

Diagrama de atividades – Modelagem de XP

Diagrama de classe – Ponto de vista estático de XP (parcial)

Fluxo de XP mostrado no site oficial

Fluxo de XP

Fluxo de XP

Fluxo de XP

Papeis Oficiais Outros papéis encontrados em sites sobre XP Cliente, programador, testador Outros papéis encontrados em sites sobre XP Tracker, gerente, goldOwner, goalDonor, ...

eXtreme Programming Eduardo Aranha