Extreme Programming

Princípios, valores e práticas

CHRISTIANO MILFONT - cmilfont@gmail.com Fortaleza, Ceará. 26/05/2006

SEAD 2006

ROTEIRO

1. HISTÓRICO.

2. AGILE SOFTWARE DEVELOPMENT.

3. EXTREME PROGRAMMING.

4. A METODOLOGIA.

5. DESENVOLVIMENTO.

6. CONCLUSÃO.

1. HISTÓRICO

ANOS 80

• Anos 80 - década Code-and-Fix.• Ausência de metodologias de desenvolvimento.• Programação procedural e estruturada.• Evolução da programação linear.• Programas são: sequência, decisão e iteração.• Dificuldade de simular relações entre entidades em processos de negócios.

ANOS 90• Linguagem UML.• Processos unificados (UP).• Metodologias Orientadas a Objetos.• Fases bem definidas e controladas.• Analogia com a Engenharia Civil.• Concepção, Elaboração, Construção e Transição.

● Os aspectos que destinguem o processo unificado são três conceitos chaves, as saber:

● Direcionados a casos de usos;

1. HISTÓRICOPROCESSOS UNIFICADOS

● Centrado na arquitetura;● Iterativo e incremental.

PROCESSOS UNIFICADOS● Rational Unified Process (RUP).● Basic Unified Process (BUP).● Enterprise Unified Process (EUP).● Microsoft Solution Framework (MSF).

PROJETOS COM PROCESSOS UNIFICADOS

● Código complexo.● Manutenção difícil.● Baixa produtividade.● Cronograma sempre atrasado.● Insatisfação de todos.● Design degradado.● Documentação defasada,

excessiva e ilegível.● Fracasso no projeto.

2. AGILE SOFTWARE DEVELOPMENT

ORIGENS DOS METODOS AGEIS

• Lendário Projeto C3 - Comprehensive Compensation project – Payroll system (Chrysler).

• Melhores práticas (Design patterns).• Análise Orientada a Objetos.• Manifesto ágil.• Agile Alliance (http://www.agilealliance.org/).

Ron Jeffries Kent BeckWard Cunningham

MANIFESTO AGIL

“Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse

trabalho, passamos a valorizar:

● Software em funcionamento MAIS QUE documentação abrangente;● Indivíduos e interação MAIS QUE processos e ferramentas;● Colaboração com o cliente MAIS QUE negociação de contratos;● Responder a mudanças MAIS QUE seguir um plano.

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.”

METODOS AGEIS

1. Extreme Programming2. Scrum3. Pragmatic Programming4. Feature Driven Development (FDD)5. Crystal6. Adaptive Software Development7. Dynamic Systems Development Method (DSDM)8. Agile Lean Development (LD)

3. EXTREME PROGRAMMING

EXTREME PROGRAMMING

O XP é formado por um conjunto de valores, princípios e práticas.

Os princípios conectam os valores (crenças fundamentais dos processos) às práticas (atividades concretas do cotidiano).

O XP é uma metodologia rigorosa e disciplinada que requer o cumprimento de suas práticas para o sucesso na adoção.

Ao contrário do que os gurus pregam, o XP pode ser usado com CMM e UPs como atestam alguns estudos especificos nos últimos anos.

A preocupação não é com qualidade (que deve natural) e sim com a saúde do sistema (segundo Kent Beck).

VALORES Communication (Comunicação)

Simplicity (Simplicidade)

Feedback

Courage (Coragem)

Respect (Respeito)

• PRINCÍPIOS– Humanity (Humanidade)– Economics (Economia)– Mutual Benefit (Benefício mútuo)– Self-Similarity (Similaridade própria)– Improvement (Progresso)– Diversity (Diversidade)– Reflection (Reflexão)– Flow (Fluxo)– Opportunity (Oportunidade)– Redundancy (Redundância)– Failure (Falha)– Quality (Qualidade)– Babe Steps (Passo-de-bêbê)– Acceptance (Aceite)– Responsibility (Responsabilidade)

Sit Together (Sentem-se juntos)

Whole Team (Equipe completa)

Energized Work (Trabalho energizado)

Pair Programming (Programação em par)

Move People Around (Mova as equipes)

Stories (Histórias)

Weekly Cycle (Ciclo semanal)

Quarterly Cycle (Ciclo trimestral)

Slack (Folga)

Ten-Minute Build (Construir em 10 minutos)

Continuous Integration (Integração contínua)

Test-First Integration (Teste primeiro)

Incremental Design (Design incremental)

Informative Workspace (Ambiente informatizado)

PRÁTICAS PRIMÁRIAS

Real Customer Involvement (Envolvimento real do cliente)

Incremental Deployment (Disponibilização incremental)

Team Continuity (Continuidade da equipe)

Shrinking Teams (Diminuição de equipes)

Root-Cause Analysis (Análise da causa-origem)

Daily Deployment (Disponibilização (entrega) diária)

Negotiated Scope Contract (Contrato com escopo negociável)

Shared Code (Código compartilhado)

Code and Tests (Código e testes)

Single Code Base (Código único)

Metaphor (Metáforas)

Refactoring (Refatoração)

•PRÁTICAS COROLÁRIAS (CONSEQUÊNCIA)

Pay-per-Use (Pague-por-uso)

Design Patterns (Padrões de projeto)

40 Hour Week (40 horas semanais)

Planning Game (Jogo do planejamento)

Stand Up Meetings (Reuniões em pé)

Coding Standards (Padrões de codificação)

4. METODOLOGIA

Fase de exploração;● Compreender e estimar o possível

Fase de planejamento;● Comprometimento das escolhas.

Fase de gerenciamento;● Gerenciamento do progresso na construção.

O jogo do planejamento é um processo circular e iterativo com objetivos, partes jogadas, jogadores e regras para os movimentos permitidos. Cada fluxo circular contínuo apresenta as fases:

JOGO DO PLANEJAMENTO

JOGO DO PLANEJAMENTO

● Definição de Releases e marcos.● Iterações com os clientes em ciclos semanais (marcos).

Não permite mudanças nessas versões.● Ciclo mensais para funcionalidades produtivas

(Releases). Versões funcionais e correções de erros.● Ciclos trimestrais para sistemas ou módulos em

produção. ● Mudanças no escopo de forma simples.● Feedback rápido.● Agilidade no gerenciamento de mudanças.

ITERAÇÕES

ITERAÇÕES

● Presença constante do cliente.● Histórias dos usuários em torno dos requisitos.● Definição entre processos, casos e funções.● História definida a partir de um pedaço de negócio

que possa ser testada, executada e entregue.● Divisão de Stories em Tasks caso necessário.● Documentação simplificada, clara e objetiva.● Definição de metáforas para claro entendimento.

USER STORY (HISTÓRIAS DOS USUÁRIOS)

Real Customer Involvement(Envolvimento Real do Cliente)

ID# 005 Usuario Fulano de tal

<Story name> Correlação de atos

Source:__________________________________________ _________

<Story texto>

Os atos após serem identificados e filtrados na consulta ao acervo do Diário Oficial devem ser correlacionados de forma que se identifique ...

Data início 01/02/2006 Data Fim 08/02/2006

Teste de Aceitação: ID# 011

USER STORY CARD

USER STORY CARD

USER STORY CARD

INFORMATIVE WORKSPACEAMBIENTE INFORMATIZADO

5. DESENVOLVIMENTO

RELEASE PLAN

ITERATION PLAN

INTEGRAÇÃO CONTÍNUA

INTEGRAÇÃO CONTÍNUA

● Condutor e navegador.● Condutor cria testes e refatora.● Navegador avalia atrás de bugs.● Navegador critica código.● Sit Together (sentam-se juntos)● Parceiro força boas práticas.● Parceiro evita dispersão.● Menos prospecção a erros.● Disseminação dos conhecimentos e nivelamento.● Stand up meeting (Reuniões breves em pé).● Confiança no desenvolvimento.

PAIR PROGRAMMINGPROGRAMAÇÃO EM PAR

MOVE PEOPLE AROUNDMOVA AS PESSOAS PELO PROJETO

● Revezamento de pares entre as histórias e iterações.● Maior revisão de códigos e disseminação.● Desenvolvedores podem alterar qualquer código.

MOVE PEOPLE AROUND

MOVA AS PESSOAS PELO PROJETO

HISTÓRIA1 2 3

SegMANHÃ PAULO & JOSÉ PEDRO & CARLOSTARDE PAULO & CARLOS PEDRO & JOSÉ

TerMANHÃ CARLOS & PEDRO JOSÉ & PAULOTARDE CARLOS & PAULO JOSÉ & PEDRO

QuaMANHÃ CARLOS & JOSÉ PEDRO & PAULOTARDE CARLOS & PAULO PEDRO & JOSÉ

QuiMANHÃ PAULO & PEDRO JOSÉ & CARLOSTARDE PAULO & CARLOS JOSÉ & PEDRO

SexMANHÃ CARLOS & JOSÉ PEDRO & PAULOTARDE CARLOS & PAULO PEDRO & JOSÉ

● Todos desenvolvedores são responsáveis pelo código.● Utiliza-se SCM (Source Control Management).● SCM versionam, arquivam e controlam o projeto.● Versões continuam em paralelo sem interromper a evolução do

sistema.

SHARED CODECÓDIGO COMPARTILHADO

SHARED CODECÓDIGO COMPARTILHADO

SHARED CODECÓDIGO COMPARTILHADO

ColaboraçãoResponsabilidadeClasse

AtoAcao

Conhece AtosConhece ações

Conhece motivosCorrelaciona Atos

AtoCorrelato

EXPLORAÇÃO DO DOMÍNIO DA RELEASE EM CRC CARDS

● Objetos que conhecem seus dados e comportamentos● Colaboram entre si e não pulam entre funções.● Só expõem o necessário.● Objetos ativos, e não passivos como tabelas.● Design simples● Implementam estritamente o que o processo define.● Representam os processos de negócios do cliente.● Não se preocupam com arquitetura do sistema.

DOMAIN MODEL

Usando C#

using System;

using System.IO;

public class RemoveArquivosVelhos {

public static void Main(string[] args) {

foreach (FileInfo fi in (new DirectoryInfo (@“\temp\backup”)).GetFiles()) {

if (((TimeSpan) (DateTime.Now - fi.LastWriteTime)).Days > 7) {

fi.Delete();

}

}

}

}

Usando BASH do sistema operacional LINUX→ find /usr -atime +6 -exec rm -f “{}” “;”

SIMPLICIDADE

DOMAIN MODEL

EXEMPLO

FUNCTIONAL TESTS (TESTES FUNCIONAIS)

● ACCEPTANCE TESTS (TESTES DE ACEITAÇÃO).● Os testes de aceitação descrevem as ações e

definem o domínio dos processos que são necessários para validar a história.

● UNIT TESTS (TESTES DE UNIDADE).● Os testes de unidade avaliam cada entidade

participante no teste de aceitação usando refactoring para criar o código funcional.

TEST-DRIVEN DEVELOPMENT

Testes que cruzam os limites de uma classe, invariavelmente são testes que descrevem e definem processos.

ACCEPTANCE TESTSTESTES DE ACEITAÇÃO

UNIT TESTSTESTES UNITÁRIOS

REFACTORINGS

6. CONCLUSÃO

● Problemas:● Saída de pessoal (Risco na implementação).● Dificuldade cultural.● Indisciplina nas práticas da metodologia podem

comprometer o sucesso.● Problemas estruturais na empresa.

● Soluções:. Projeto saudável.● Agilidade nas mudanças.● Menos pontos de manutenção.● Produtividade no ciclo de vida do produto.● Menor incidência de falhas.

REFLEXÃO: MOÇOS BONITOS COMO NÓS

DESENVOLVEM EM JAVA.

DUVIDAS?

● Extreme Programming Explained - Kent Beck● Planning Extreme Programming - Kent Beck and Martin Fowler● Extreme Programming Installed - Ron Jeffries● Extreme Programming Explored - William C. Wake● Agile Software Development - Evaluating the Methods for Your

Organization - Alan S. Koch● Agile Software Development - Alistair Cockburn● Agile Software Development Ecosystems - Jim Highsmith● Applying UML and Patterns - An Introduction to Object-Oriented

Analysis and Design and Iterative Development (3rd) - Craig Larman● Test-Driven Development By Example - Kent Beck● Martin Fowler - Refactoring-Improving the Design of Existing Code● Domain-Driven Design - Tackling Complexity in the Heart of Software -

Eric Evans

APÊNDICEBIBLIOGRAFIA