Extreme Programming (XP)

Transcrição

1 Extreme Programmig (XP)

2 Situação da área de desevolvimeto do software Sociedade demada grade quatidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêeos requisitos mutates (todo dia, mês, ao) Mas, ifelizmete, ão há gete suficiete para desevolver tato software com qualidade... 2

3 Problemas Com metodologias de desevolvimeto Supõem que é possível prever o futuro Pouca iteração com os clietes Êfase em burocracias (documetos, formulários, processos, cotroles rígidos, etc.) Avaliação do progresso baseado a evolução da burocracia e ão do código Com software Grade quatidade de erros Falta de flexibilidade 3

4 Como resolver esse impasse? Melhores Tecologias Padrões de Projeto (reutilização de idéias) Compoetes (reutilização de código) Middleware (aumeta a abstração) Melhores Metodologias Métodos Ágeis outras... 4

5 Metodologias de desevolvimeto de software OO Tradicioais Comuidade de Egeharia de Software IEEE/ACM ICSE p.ex. Caregie-Mello SEI RUP, CMM, etc. Ágeis Comuidade de POO ACM OOPSLA p.ex. Illiois, Beck, Cockbur, Jeffries, Cuigham XP, Crystal, Scrum, etc. 5

6 Métodos Ágeis de Desevolvimeto de Software Movimeto iiciado por programadores experietes e cosultores em desevolvimeto de software. Questioam e se opõem a uma série de mitos/práticas adotadas em abordages tradicioais de Egeharia de Software e Gerêcia de Projetos. Maifesto Ágil: Assiado por 17 desevolvedores em Utah em fevereiro/

7 O Maifesto do Desevolvimeto Ágil de Software 1. Idivíduos e iterações são mais importates que processos e ferrametas. 2. Software fucioado é mais importate do que documetação completa e detalhada. 3. Colaboração com o cliete é mais importate do que egociação de cotratos. 4. Adaptação a mudaças é mais importate do que seguir o plao iicial. 7

8 Pricípios do Maifesto Ágil Objetivo: satisfazer o cliete etregado, rapidamete e com freqüêcia, sistemas com algum valor. Etregar versões fucioais em prazos curtos. Estar preparado para requisitos mutates. Pessoal de egócios e desevolvedores jutos. Troca de iformações através de coversas diretas. 8

9 Programação extrema Metodologia de desevolvimeto de software aperfeiçoada os últimos 5 aos. Gahou otoriedade a partir da OOPSLA 2000 (Coferece O Object-Orieted Programmig). Nome pricipal: Ket Beck. 9

10 Visão geral Processo de desevolvimeto de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüêcia Desevolvimeto de sistemas orietados a objetos Equipes pequeas, de 2 até 12 programadores Projetos de 1 a 36 meses De 1000 a lihas de código Desevolvimeto icremetal (ou iterativo) Orgaizado em toro de um cojuto de valores e práticas para assegurar que o cliete receba um alto retoro do ivestimeto em software 10

11 Valores do XP Feedback: o cliete aprede com o sistema que utiliza e re-avalia as suas ecessidades, gerado feedback para equipe de desevolvimeto Comuicação: permite que todos os detalhes do projeto sejam tratados com a ateção e a agilidade que merecem Simplicidade: implemetar apeas aquilo que é suficiete para ateder a ecessidade do cliete Coragem: a equipe precisa ser corajosa e acreditar que, utilizado as práticas e valores do XP, será capaz de fazer o software evoluir com seguraça e agilidade 11

12 Práticas do XP Cliete Presete Jogo do Plaejameto Stad Up Meetig Programação em Par Desevolvimeto Guiado pelos Testes Refactorig Código Coletivo Código Padroizado Desig Simples Metáfora Ritmo Sustetável Itegração Cotíua Releases Curtos 12

13 Características da equipe Gerete de Projeto: resposável pelos assutos admiistrativos do projeto Coach: resposável técico do projeto Aalista de Teste: resposável por ajudar o cliete a escrever os testes de aceitação Redator Técico: ajuda a equipe de desevolvimeto a documetar o sistema Desevolvedor: aalisa, projeta e codifica o sistema 13

14 Desafios do desevolvimeto de software Modelo tradicioal Aálise a equipe faz o levatameto dos requisitos e busca compreedê-los detalhadamete Projeto com base a aálise a equipe projeta a arquitetura do sistema Implemetação a equipe se baseia a arquitetura e a aálise para implemetar as diversas partes do software Teste para verificar se o sistema atede às ecessidades especificadas pelo usuário, a equipe testa o software e faz as correções ecessárias Implatação o sistema é colocado em produção e os usuários fiais passam a utilizá-lo Mauteção até o fim da sua vida, o software poderá sofrer alterações por diversas razões, tais como correção e iclusão de ovas fucioalidades 14

15 Modelo em cascata (Wisto Royce, 1970) 15

16 Premissas Básicas do Modelo Tradicioal É ecessário fazer uma aálise de requisitos profuda e detalhada ates de projetar a arquitetura do sistema. É ecessário fazer um estudo miucioso e elaborar uma descrição detalhada da arquitetura ates de começar a implemetá-la. É ecessário testar o sistema completamete ates de madar a versão fial para o cliete. 16

17 Problemas do modelo em cascata Iflexível divisão do projeto em estágios distitos Isso tora difícil respoder a mudaças os requisitos do cliete Portato, este modelo somete é apropriado quado os requisitos forem bem compreedidos 17

18 O que está por trás deste modelo? Custo de mudaças requisitos deseho testes aálise implemetação produção 18

19 Desevolvimeto Ágil Utilizam o desevolvimeto iterativo (em espiral) 19

20 Premissas do Desevolvimeto Ágil Satisfazer o cliete etregado rapidamete e com freqüêcia, sistemas com algum valor Etregar versões fucioais em prazos curtos Estar preparado para requisitos mutates Pessoal de egócios e desevolvedores devem trabalhar jutos Troca de iformações através de coversas diretas O cliete aprede ao logo do desevolvimeto, à medida que é capaz de maipular o sistema Este apredizado pode ser utilizado para realimetar o processo de desevolvimeto 20

21 O que está por trás deste modelo? Custo de mudaças tempo 21

22 Mais sobre os valores do XP Feedback Comuicação Simplicidade Coragem 22

23 Feedback Realimetação que o cliete forece à equipe de desevolvimeto quado: aprede algo ovo sobre o sistema aprede mais sobre os requisitos aprede mais sobre a forma como os requisitos foram implemetados Realimetação que os desevolvedores forecem ao cliete quado: apresetam estimativas apotam riscos técicos sugerem alterativas de desig 23

24 Comuicação Para que o feedback exista em um projeto de software, é ecessário que a comuicação esteja presete de forma muito itesa Compoetes da equipe e o cliete precisam trocar idéias e iformações para que o software gahe forma e atija os objetivos desejados 24

25 Comuicação Formas de comuicar uma idéia para outra pessoa Coversar face-a-face Telefoe Mesages istatâeas Etc Comuicação face-a-face: iterlocutor leva em cota o coteúdo da fala, gestos, expressão facial, tom de voz etc Existe uma riqueza de elemetos que facilitam a compreesão da ossa mesagem, além de uma diâmica que viabiliza questioametos e respostas 25

26 Comuicação XP procura explorar a comuicação direta etre as pessoas, de modo a dimiuir as falhas de comuicação e evitar retrabalhos desecessários, frutos dessas falhas No XP documetos são usados pricipalmete para registrar o trabalho que já foi executado, ao ivés de discutirem exaustivamete o que deverá ser feito A explicação sobre o que precisa ser feito é forecida pessoalmete face-a-face 26

27 Simplicidade Deve-se desevolver a fucioalidade requerida APENAS COM O SUFICIENTE para que o cliete teha o seu pedido atedido e possa validar se foi atedido da forma como gostaria Trabalho especulativo é evitado: aquele executado utilizado-se premissas sobre as quais ão se tem total certeza Overegieerig também é evitada: criar uma solução excessivamete sofisticada para um dado problema 27

28 Coragem Adoção do XP exige que a equipe de desevolvimeto teha coragem para: Desevolver o software de forma icremetal: uma alteração poderá iserir erro aquiloque viha fucioado até etão. Mater o sistema simples: a equipe precisa acreditar que será capaz de icorporar possíveis ecessidades futuras que ela já visualiza o presete, mas que ão foram especificadas pelo cliete. Permitir que o cliete priorize as fucioalidades: o XP as fucioalidades são especificadas através de estórias. Fazer os desevolvedores trabalharem em par. Ivestir tempo em refactorig: melhorar a qualidade do código do sistema, sem alterar a fucioalidade que ele implemeta 28

29 Coragem Ivestir tempo em testes automatizados. Estimar as estórias a preseça do cliete. Expor o código a todos os membros da equipe: o desevolvedor precisa ter humildade e sereidade para tratar evetuais críticas como um apredizado que o ajudará a melhorar o seu código. Itegrar o sistema diversas vezes ao dia. Adotar um ritmo sustetável: para obter grades saltos de produtividade, os desevolvedores devem começar cada dia de trabalho bem dispostos, criativos, atetos e motivados a fazer um software de alta qualidade. 29

30 Coragem Abrir mão de documetações que servem como defesa: muitas equipes de desevolvimeto jogam para ão perder. Partem da premissa que o projeto passará por vários problemas será ecessário precaver com todo o tipo de documetação para isetar a equipe de qualquer resposabilidade. Propor cotratos de escopo variável: permite que a equipe icorpore o apredizado do cliete a forma de mudaças o software. Propor a adoção de um processo ovo. 30