Tópicos. Ritmo sustentável Integração contínua Releases curtos A organização do ambiente de trabalho A equipe de desenvolvimento

Transcrição

1 Práticas do XP

2 Tópicos Ritmo sustetável Itegração cotíua Releases curtos A orgaização do ambiete de trabalho A equipe de desevolvimeto 2

3 Ritmo sustetável 3

4 Trabalho em excesso Segudo Frederick Brooks (1995) o problema mais recorrete os projetos de software é a falta de tempo para fializar o projeto. As restrições de tempo sobre o projeto acabam levado muitas equipes a trabalhar em excesso. Essa solução pode, ao ivés de resolver o problema, piorá-lo. As coseqüêcias vão, desde uma maior letidão a resolução de problemas, até a itrodução de erros o software. 4

5 O ritmo sustetável é mais produtivo O XP recomeda que as pessoas trabalhem oito horas por dia (40h semaais). Isso demostra respeito pela idividualidade e a itegridade de cada membro da equipe. Aumeta a agilidade do projeto. No modelo idustrial, o aumeto do trabalho e da operação das máquias ormalmete aumeta a produção. No desevolvimeto de software este pricípio ão pode ser aplicado, uma vez que se trata de um trabalho que exige muita cocetração e criatividade. 5

6 Itegração cotíua 6

7 Itegração Um software desevolvido em equipe é dividido em partes. Cada programador fica resposável por uma parte, e pelos seus testes. Para que o sistema fucioe é ecessário itegrar as várias partes desevolvidas. Para isso é ecessário covecioar as iterfaces. Em teoria essa estratégia fucioa bem, a prática podem ocorrer os seguites problemas: 7

8 Causas dos problemas de itegração As iterfaces covecioadas ão são respeitadas. Por exemplo, assiatura de métodos ão coferem ou objetos ão se comportam como deveriam. Não houve compreesão por parte de um desevolvedor da iterface do outro. O sistema como um todo é pouco coeso. Quato mais tempo a equipe demora para itegrar, maior é o risco de problemas a itegração (por exemplo as iterfaces podem ser alteradas e ão serem publicadas corretamete para os desevolvedores. 8

9 Itegração cotíua O XP propõe que a equipe itegre e teste o sistema iteiro diversas vezes ao dia. Uma das dificuldades para efetuar essa prática é a compilação e ligação do sistema, que deve ser matido baixo ao logo de todo o projeto. Existem diversas formas de fazer isso: Fazer com que a iterdepedêcia etre os arquivos seja baixa. Fazer com que o compilador só compile os arquivos que tiverem sido editados e utilize diretamete o código objeto para os demais. Trabalhar com a carga diâmica de bibliotecas quado isso for possível. 9

10 Fases pelas quais o código passa 1. Local Primeira fase do desevolvimeto. O par acabou de começar a trabalhar o código e as mudaças que executaram aida ão estão dispoíveis para os outros desevolvedores. 2. Cadidato à liberação O par termiou a sua tarefa e está proto para dispoibilizar o ovo código cotedo suas alterações para os demais desevolvedores. 3. Dispoibilizado o repositório Esta é a versão oficial correte do código. Os teste de uidade executam com 100% de sucesso. As alterações do par se toram dispoíveis para todos os desevolvedores. 10

11 Liberação de mudaças Equato um par programa, outros também estão fazedo alterações e sempre há uma chace de que mais de um par teha editado e alterado o mesmo código. Por isso é importate que exista um processo discipliado para que se possa fazer a liberação de mudaças de forma rápida e com o míimo de risco. 11

12 Passos para a liberação de mudaças 1. Sempre comece a trabalhar com o código mais atual que se ecotra o repositório. 2. Escreva os testes de uidade que são ecessários para a sua tarefa. Os testes de uidade devem ser escritos ates do código. 3. Rode todos os testes de uidade. 4. Coserte qualquer teste que esteja quebrado. 5. Quado todos os testes de uidade estiverem rodado com 100% de sucesso as alterações locais se toram cadidatas a liberação, podedo ser colocadas o repositório. 12

13 Passos para a liberação de mudaças 6. O código que é cadidato a liberação é itegrado com o código atual do repositório. 7. Se o código do repositório tiver sido alterado equato você fazia a mudaça, compare as difereças etre as suas mudaças e o código do repositório. Idetifique as mudaças que tiverem sido adicioadas pelo outro par e itegre estas mudaças com as suas. 8. Uma vez que você teha itegrado as suas mudaças, execute os testes de uidade a máquia de itegração. 9. Quado os testes de uidade estiverem executado com 100% de sucesso, coloque todo o código da máquia de itegração o repositório. 13

14 Máquia separada para a itegração Itegrar em uma máquia separada isola o código o qual você está trabalhado daquele que está o repositório. Ritual de passagem: o código deixa de pertecer ao par que o criou e passa a ser coletivo, estado dispoível para todos os desevolvedores. Apeas um par pode itegrar de cada vez. Ter uma máquia separada ajuda a discipliar a equipe, pois deixa muito evidete quado existe um par itegrado. 14

15 Ferrametas Ferrameta de build: utilizada para compilar todo o sistema e executar outras atividades que se façam ecessárias para que ele possa ser executado. Sistema de cotrole de versão (repositório): armazea todos os códigos fotes do sistema matedo a versão deles. 15

16 Atividades suportadas pelo repositório Idetificar mudaças locais. Mostrar a difereça etre alterações locais e o código que está o repositório. Idetificar quem colocou uma determiada mudaça o repositório e quado isso acoteceu. Fudir mudaças locais com o código que está o repositório. Voltar a versão de um código que já existia o repositório ates da itegração. 16

17 GCVS (Sistema de Cotrole de Versão) 17

18 GCVS - Características Gereciameto de projeto em equipe. Log de todas as alterações realizadas. Histórico de todas as mudaças feitas, isto permite voltar a uma versão aterior em caso de problemas, e ver o que houve de errado com o código. Permite visualizar facilmete o que foi modificado etre duas versões de um arquivo. 18

19 Jakarta ANT (Ferrameta de build) 19

20 Jakarta ANT - Características Ao cotrário do make que utiliza extesões baseadas o shell, utiliza classes Java e seus arquivos de cofiguração são baseados em XML. Portato, é uma ferrameta multiplataforma que foi itegrada a diversos IDEs (ex. Eclipse, Netbeas, Jbuilder etc). 20

21 Releases curtos 21

22 Releases Cada release represeta um cojuto de fucioalidades implemetadas que represetam um valor bem defiido para o cliete e que é colocado em produção para que todos os usuários possam ser beeficiar dele. 22

23 Retoro de ivestimeto Um projeto de software é um ivestimeto. O cliete iveste uma certa quatidade de recursos a expectativa de obter um retoro detro de um certo prazo. Este retoro pode se materializar de diferetes formas, tais como: Aumeto de vedas Melhoria a qualidade de seus produtos Racioalização da produção Redução de custos Abertura de um ovo caal de relacioameto com os clietes 23

24 Fluxo de caixa de um projeto tradicioal 24

25 Fluxo de caixa de um projeto XP 25

26 A orgaização do ambiete de trabalho 26

27 Ambiete de trabalho A forma como a equipe se orgaiza ifluecia diretamete a sua capacidade de adotar as práticas do XP. O XP recomeda que o ambiete de trabalho seja aberto e público de modo que: Todos os membros da equipe possam trabalhar próximos us dos outros; Cada pessoa possa escutar as evetuais pergutas de seus colegas; Seja possível escutar uma coversa acidetalmete em relação à qual um membro da equipe teha uma cotribuição vital. 27

28 Mesas e cadeiras As mesas usadas pelos desevolvedores devem permitir que duas pessoas trabalhem jutas. As cadeiras devem ter braços ajustáveis e sejam ergoômicas. 28

29 Mesas e cadeiras As mesas devem ser arrajadas de modo que ela cosiga aproximar ao máximo os desevolvedores. O ideal é arrumá-las de modo a formar uma área cetral ao redor da qual todos os desevolvedores se posicioem. 29

30 Equipametos Os computadores devem ser velozes, com muita memória, discos rápidos e com grade capacidade de armazeameto. A rede deve ser rápida. Os moitores devem ser grades e com alta qualidade de imagem. Deve haver uma máquia separada para itegração. É recomedável que exista um servidor, acessível também pela Web, para armazear documetações do projeto, mauais etc. 30

31 Mural Serve para a colocação dos cartões da iteração. Neste, deve-se criar três coluas com as seguites iformações: cartões ão-iiciados, cartões em adameto, cartões fializados. 31

32 Quadro braco Usado para apoiar as discussões e debates da equipe. Forece um local o qual a equipe pode fazer desehos e aotações e compartilhá-los facilmete com todos os membros. 32

33 Madametos Represetam regras que devem ser seguidas o projeto. Costuma ser fixados a parede com letras grades. 33