extreme Programming Joaquim Filipe Patrícia Macedo Engenharia de Software 2005/06 EST, Setúbal Metodologias de Desenvolvimento de Software

(1)

eXtreme Programming

Joaquim Filipe

Patrícia Macedo

Engenharia de Software 2005/06

EST, Setúbal

Metodologias de Desenvolvimento

de Software

Agenda

Metodologia PREDITIVAS (tradicionais)

UP MSF

Metodologias Adaptativas(Ageis)

XP

(2)

Patrícia Macedo EST de Setúbal - Engenharia de Software 2005-2006

3

Introdução

XP é uma colecção formal de práticas de

desenvolvimento de software.

O custo do software aumenta ao longo do ciclo de vida.

Porquê?

Os requisitos mudam continuamente. Porquê fixá-los

artificialmente?

O software tradicional falha. Como minorar o problema?

Problemas principais: requisitos mal definidos, cliente

pouco envolvido no processo, elevada complexidade, coordenação e integração deficientes.

4

Práticas XP

As práticas recomendadas pela XP não são

novas individualmente. A novidade é na

conjugação e no ênfase extremo que se

coloca na sua utilização.

Resultado desejado:

software de alta qualidade. Sem bugs. De

complexidade mínima. Adaptável.

(3)

5

Equipa de Desenvolvimento

Os papéis principais (roles) são:

Cliente (dono da solução) – tem de compreender

exactamente o que se pretende do software. Não é um técnico.

Programador (técnico) – deve desenvolver código de

elevada qualidade e ter uma apetência pela

descoberta e partilha com a equipa de conhecimento tecnológico.

Coordenador – deve ser capaz de remover bloqueios

que impedem a equipa de progredir. Compreende bem a XP. É também um programador.

Práticas XP

Equipa completa (cliente on-site)

Jogo de planeamento – definição de features e

tempos de desenvolvimento.

Programação em pares – proporciona uma

revisão contínua do código, ajuda a disseminar

conhecimento e treina a comunicação,

aumentando a inteligência do programador.

Exige rotação rápida dos pares.

(4)

7

Práticas XP

Desenvolvimento orientado por testes (

test

driven development: TDD

) – é a prática de

escrever testes unitários antes de escrever o

código.

Os testes devem ser executáveis automaticamente

Para além da validação das intenções, os testes

suportam outras práticas (restruturação e simplismo) e potenciam a comunicação e confiança no software.

8

Práticas XP

Restruturação constante (

refactoring

) – é

o processo de alterar a estrutura do

código sem alterar o seu comportamento.

Remoção de código desnecessário.

Código mais fluido

(5)

9

Práticas XP

Experimentação (

spiking

) – é o teste de

uma teoria ou uma exploração tecnológica

vertical estreita, para dar à equipa

conhecimento aprofundado numa área

necessária ao projecto.

Depois do spike os resultados são partilhados

com toda a equipa

Práticas XP

Integração contínua – depois de terminar cada

tarefa:

O código escrito é integrado na solução completa.

A solução completa é compilada

Todos os testes são executados

Miniza a probabilidade de o projecto falhar por

dificuldade de integração dos módulos

(6)

11

Práticas XP

Reuniões em pé (

stand up meetings: SUM

) –

discussão do progresso do dia anterior e do

plano de cada actividade individual para o dia.

Máximo ½ hora

Estas reuniões proporcionam a possibilidade de

aumentar o conhecimento da equipa.

Permitem ainda detectar e resolver em grupo

dificuldades tecnológicas ou conceptuais pontuais

12

Outras Práticas XP

Passo sustentável (tempo de trabalho fixo)

O cansaço causa erros: menos horas; maior

intensidade

A concentração intensa aumenta a qualidade

O planeamento é mais simples (possível?)

Metáforas – por vezes ajuda a entender o

sistema como algo que se conhece do dia a dia

o que permite

Usar analogias e

(7)

13

Outras Práticas XP

Desenho simples – não incluir no código nada que não

seja essencial.

Releases curtas – para obter feedback do cliente.

Seguir standards de codificação – facilita o refactoring.

Posse colectiva – todo o sistema e o processo de

desenvolvimento são da equipa.

Reciclar – a alteração de requisitos e da tecnologia

obrigam frequentemente a deixar de usar código escrito anteriormente. Menos código – menor a perda.

Abugging – não há bugs aceitáveis.

Outras Práticas XP

Mudança incremental – evitar a instabilidade do

sistema.

Honestidade e abertura – discussão livre e

disponibilidade para ajudar.

Aceitar a Mudança – a única certeza em

software é que ele muda.

Atitude de sucesso – obter uma série de vitórias

(8)

15

Valores XP

Comunicação

Engenharia de software é um trabalho de equipa

Simplicidade

Evitar planear o futuro! Concentração no presente Fazer simples é difícil e demorado

Feedback

Granularidade: minutos a meses.

Através de TDDs, SUMs, cliente: descrição de histórias (story

cards), uso do sistema, etc.

Coragem

Assumir a dificuldade das práticas XP e assegurar resultados Fazer as mudanças necessárias quando necessário

(9)

17

Método, em forma de jogo

Dois papéis: o programador e o colega.

O programador declara qual a função que

pretende programar.

Quanto o programador acaba, declara-o.

O colega dá uma pontuação de 0 a 10 à função.

Por cada ponto abaixo de 10 o colega tem de

explicar como obter o 10.

Trocam de papéis e o processo recomeça.

Regras

Para o colega:

Assegurar-se que o feedback é positivo.

Não fazer comentários pessoais; manter o foco no

programa e não no programador.

Para o programador:

Não esquecer que os comentários se destinam a

melhorar a qualidade do código.

Manter uma atitude de gratidão pela ajuda prestada

(10)

19

Conclusão

O valor combinado do QI de dois

programadores é maior do que o QI de

qualquer deles individualmente, pois em

conjunto conseguem resolver problemas

melhor e mais rapidamente.

A programação em pares é a melhor

aproximação da situação de ter um génio

a programar cada linha de código! ;-)

(11)

21

Divisão de tarefas

Erros típicos:

Tentar resolver um problema complexo de uma só

vez

Tentar copiar a solução de um problema semelhante

Importa:

Encontrar soluções simples, dividindo o problema

complexo em problemas mais simples.

Reduzir a solução do problema a tarefas que

demorem menos de 4 horas, cada.

Escrever as tarefas e o tempo previsto para a sua

realização (exemplo: calculadora)

Método para abordar problemas

reais complexos

Uma história é uma descrição de uma

funcionalidade do sistema. Semelhante a um

“use case” do UML.

1.

O cliente escreve histórias em cartões.

2.

A equipa decompõe cada história e estima o

tempo de desenvolvimento para cada história.

3.

Os objectivos devem ser planeados a diversos

prazos: longo, médio, curto e curtissimo.

4.

As histórias e o plano devem ser revistos

(12)

23

Conclusão

A equipa tem de trabalhar com o cliente para

definir exactamente o que este pretende.

Necessário auto-disciplina e método para

decompor o problema de forma adequada.

Planeamento contínuo, incluindo spiking, testes

e integração no final de cada tarefa unitária.

Codificação apenas das partes essenciais (depois

de encontrar o maior número possível de

componentes já feitos na web)

Desenvolvimento Orientado por

Testes

(13)

25

Abugging

É preferível gastar tempo a evitar bugs do que

gastar tempo em debug...

Se a qualidade do software for elevada desde o

início é mais provável que a qualidade se

mantenha ao longo do tempo.

“Software com zero defeitos” requer

ferramentas e método.

Testes unitários

Desenvolver os testes antes da aplicação

Integração contínua

Testes

Porquê escrever os testes antes?

Criar a oportunidade para desenvolver código

simples (para passar o teste).

Os testes definem as pre- e pos- condições de

uma unidade funcional.

Se os testes forem feitos antes, o código será

automaticamente testável.

(14)

27

Ferramentas

NUnit

É uma biblioteca de classes do framework .NET

Tem uma interface gráfica e uma consola que

permitem correr os testes e ver os resultados

Disponível em http://www.NUnit.org

Funciona com o Visual Studio.NET

Os testes são escritos na mesma linguagem da

aplicação e ficam integrados na aplicação.

28

NUnit

Solution Explorer – Add reference:

Nunit.framework.dll

Nova classe para colocar os testes

using System;

using NUnit.Framework; Métodos especiais:

Setup --- no .NET 2005: TestInitialize TearDown --- no .NET 2005: TestCleanup Atributos:

De classe: [TestFixture] --- no .NET 2005: [TestClass] De métodos de teste: [Test] --- no .NET 2005: [TestMethod]

(15)

29

Separação do código

Business Logic

Classes com as unidades funcionais

GUI

As unidades funcionais podem ser usadas

com diversas interfaces

Testes

Podem ser corridos no GUI da NUnit

Testar GUIs

Problema: Muitas ferramentas encorajam o

desenvolvimento do interface gráfico e depois

incluir o código nos métodos de manipulação de

eventos (

event-oriented coding

).

Esta programação orientada por eventos é:

Dificil de manter, melhorar e testar

Intuitiva; usada em RADs

Necessário: Minimizar a espessura do GUI

Os testes devem ser feitos usando algoritmos

(16)

31

Conclusão

O desenvolvimento orientado por testes é

a base de outras técnicas de XP:

refactoring, releases curtas, integração

contínua, programação em pares e a

propriedade colectiva do código.

Os elementos de uma equipa em que

todos usam TDD têm mais confiança uns

nos outros.

(17)

33

Benefícios do refactoring

O refactoring, mudando a estrutura do

programa sem alterar o comportamento,

pode:

Melhorar substancialmente a legibilidade do

código

Reduzir os custos de mudança

Aumentar a qualidade do código produzido

Refactoring faz parte do processo

Escrever testes Escrever o código Integração Refactoring

(18)

35

Quando não usar refactoring

Não refazer código que não vai mudar.

Não refazer mais do que o necessário

Não refazer código feito por outros apenas

por uma questão de estilo de

programação.

36

Ferramentas

http://www.xtreme-simplicity.net

Visual Studio.NET 2005 traz ferramentas

integradas no IDE.

Extract method

Rename

Encapsulate Field

Extract interface

Etc.

(19)

Spiking

A necessidade de planear o spiking

Spiking = investigar e experimentar tecnologias

necessárias à programação

Impossível conhecer tudo, mesmo numa área limitada

A especialização pode ser prejudicial a médio prazo

Inútil saber tudo sobre um aspecto quando se falha em

aspectos essenciais.

Eficácia vs. Eficiência

Importante adquirir confiança no plano de

(20)

39

Recolha de conhecimento

O resultado do spiking deve ser colocado em

testes.

Documentarm o conhecimento encontrado, para

outros programadores,

Asseguram que o conhecimento é válido e não

desactualizado,

Neste caso os testes podem ser escritos depois

Mais info: http://eXtreme.NET.Roodyn.com

(21)

41

Automatização

Todos os passos que se possa automatizar num processo

repetitivo...

Aumenta a eficiência Evita o erro humano

Compilação e teste do código = construção Processo:

1. Obter a solução oficial a partir de uma localização central. 2. Construir a nova solução incluindo as mudanças mais recentes 3. Correr os testes.

4. Se passar todos os testes, acrescentar o código alterado ao sistema

de controlo de fontes.

5. Reconstruir a solução na localização central e testar de novo 6. Reconstruir o instalador na localização central

Controlo de fontes

O software de controlo de fontes proporciona

um repositório central de código disponível para

toda a equipa.

Permite observar a história

Permite o rollback

A Microsoft oference o Visual SourceSafe

integrado no Visual Studio.Net

O repositório deve ser colocado numa máquina

(22)

43

Máquina de integração

Vantagens de ter uma máquina específica para

integração do código:

Evita conflitos entre (vários) conjuntos de código

construído.

Oferece a toda a equipa de desenvolvimento maior

visibilidade do estado do projecto.

Evita o sintoma NMMF (na minha máquina funciona)

pois o teste é feito em pelo menos 2 máquinas.

44

Processo

(integração em máquinas individuais)

Solução central

Módulos Novos

Integração Correr Testes

Testes Falharam Testes Passaram 2 1 3 4

(23)

45

Processo

(integração também na máquina central)

Solução central

Módulos Novos

Integração Correr Testes

Testes Falharam Testes Passaram 5

Ferramentas de construção (build)

NAnt

É uma ferramenta de construção baseada em ANT

(p/Java baseada em XML)

Pode definir-se diferentes alvos de construção (build

targets)

É uma ferramenta de linha de comandos; para

registar as variáveis de ambient usar o ficheiro de batch: vsvars32.bat

Download de: http://nant.source-forge.net