UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Organização da Informação Projeto Final. extreme Programming

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Organização da Informação Projeto Final

eXtreme Programming

Afonso Carvalho

Felipe de Souza

Rômulo de Brito

Wesley Boaes

Professora: Adriana Vivacqua

RESUMO

O trabalho dá uma visão geral do que é uma metodologia ágil de desenvolvimento e depois mais precisamente descreve a ‗Programação Extrema‘ (a.k.a eXtreme Programming) que é uma metodologia ágil para pequenas e médias empresas.

SÍMBOLOS, ABREVIATURAS, SIGLAS E CONVENÇÕES

XP Programação Extrema – eXtreme Programming

KISS Princípio KISS (Keep It Simple, Stupid) DRY Princípio DRY (Don‘t repeat yourself)

ÍNDICE

INTRODUÇÃO ... 4

CAPÍTULO I - MÉTODOS ÁGEIS. ... 5

I.1-CONCEITOS BÁSICOS E DEFINIÇÃO ... 5

I.1.1 - Princípios ... 6

CAPÍTULO II - A PROGRAMAÇÃO EXTREMA (XP). ... 7

II.1-CONCEITOS BÁSICOS ... 7

II.1.1 - Práticas ... 9 II.1.2 -Equipe ... 12 1.2.1 -Gerente de Projeto ... 12 1.2.2 -Coach ... 12 1.2.3 -Analista de Teste ... 13 1.2.4 -Redator Técnico ... 13 1.2.5 -Desenvolvedor ... 13

I.2-CONSIDERAÇÕES FINAIS ... 14

INTRODUÇÃO

Devido à muito fatores da era atual, em principal a velocidade que as coisas acontecem e que a informação flui, nasceu a necessidade do ser-humano também agilizar seus processos afim de se equiparar ao fluxo intenso que se criou: tudo é rápido no século XXI.

Então, na área de engenharia de software na tentativa de agilizar os processo e desenvolver software de forma mais rápida e eficiente, foram pensandos os métodos ágeis que em determinadas variantes podem ser usados por empresas pequenas, médias e grandes afim de agilizar seus processos.

Vale destacar, que os métodos ágeis não são somente uma aplicação no desenvolvimento de software e podem ser usados para pensar e trabalhar sobre vários outros tipos de projetos.

O objetivo deste trabalho não é indicar caracteristicas intensas nen profundas das metodologias de desenvolvimento ágil tão pouco da programação extrema, nem ser muito extenso, e sim, ser o mais prático e direto possivel afim de quem o leia, tenha base para pensar sobre desenvolvimento ágil e poder de tirar suas próprias conclusões sobre a Programação Extrema.

CAPÍTULO I – Métodos Ágeis.

Os métodos de desenvolvimento ditos ― ágeis‖ (em inglês Agile Modeling, ou AG) visam reduzir o ciclo de vida do software (e por conseguinte acelerar o seu desenvolvimento) desenvolvendo uma versão mínima, seguidamente integrando as funcionalidades por um processo iterativo baseado na escuta do cliente e testes ao longo de todo o ciclo de desenvolvimento. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.

A grande ideia do AG venho apartir da reação contra o ―peso‖ do modelo de desenvolvimento em cascata que era caracterizado por uma pesada regulamentação, pouca flexibilidade, regimentação e micro gerenciamento pesado. O processo para formação do AG originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência.

Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Mais tarde, algumas pessoas formaram a Agile Alliance, uma organização não lucrativa que promove o desenvolvimento ágil.

Os métodos ágeis iniciais—criado a priore em 2000— incluíam Scrum (1986), Crystal Clear, Programação extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995).

I.1.1 - Princípios

Toda metodologia ágil de desenvolvimento se organiza sobre princípios, antes de entrar em qualquer especiação (XP, Scrum) todas elas contam com alguns princípios padrões, não necessariamente todos, mas quase sempre todos eles. Estes são:

 Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;

 Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);

 Softwares funcionais são a principal medida de progresso do projecto;

 Até mesmo mudanças tardias de escopo no projecto são bem-vindas.

 Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;

 Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.

 Design do software deve prezar pela excelência técnica;

 Simplicidade;

 Rápida adaptação às mudanças;

 Indivíduos e interações mais do que processos e ferramentas;

 Software funcional mais do que documentação extensa;

 Colaboração com clientes mais do que negociação de contratos;

CAPÍTULO II – A Programação Extrema (XP)

A Programação Extrema (eXtreme Programming), ou apenas XP, é uma metodologia de desenvolvimento ágil com para pequenas e médias empresas com foco em desenvolvimento de softwares que tem poucos ou vagos requisitos e que esteja em constante mudança (alta flexibilidade).

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas. Isto é, as partes principais (que por padrão costumam ser as maiores) são feitas primeiro.

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo, e este é um dos grandes focos da AG que deve e é mantido em todas as metodologias de desenvolvimento ágil.

Á XP se organiza sobre valores, que são as justificativas de suas práticas e seus princípios.

Como visto na figura:

Valores: 1. Comunicação; 2. Simplicidade; 3. Feedback; 4. Coragem; 5. Respeito Princípios básicos: 1. Feedback rápido; 2. Presumir simplicidade; 3. Mudanças incrementais 4. Abraçar mudanças

9

II.1.1 - Práticas

A XP é conhecida principalmente pelo sucesso e velocidade que ela fornece, e tudo isso não acontece porque elá está apoiada somente sobre alguns valores e princípios. Toda a mágica da XP vem das práticas que ela pregra, que são:

 Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção. Isso obriga o desenvolvimento à ser ágil, visto que, os programadores tão sempre comprometidos à resultados.

 Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. Isto é, o cliente sempre tem acesso parcial do programa e com o contrato flexivel faz com que os programadores se preucupem com a qualidade afim de não cair no desgosto do cliente e um possivel cancelamento do projeto.

 Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente as vezes não é o mesmo que o do programador. E nessa falta de harmonia mental-semantica é preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

 Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta

funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.

 Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento. Todos tem que estar a par das modificações e andamento do projeto.

 Testes de Aceitação (Customer Tests): É uma estrutura procedural de avaliação feita pelo cliente afim de determinar se uma ‘feature’ x irá ser integrada ou não ao sistema.

 Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

 Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. Reuniões sentadas sempre são mais lentas e menos produtivas para o campo que estamos trabalhando. Este também é uma das principais práticas de AG que ficou famosa por causa do SCRUM

(AG).

 Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema, além de ser uma prática diretamente ligada ao valor Coragem.

11

 Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

 Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

 Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

 Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte, isto é aonde é aonde é checado se as rotinas estão sendo implementadas das maneiras mais simples pensadas no momento (KISS Principle) e se não existe código duplicado, e repetição inutil de código que poderia estar existindo como uma função (DRY

Principle).

 Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Vendo e imaginando todas essas práticas e pensando nelas em harmonia, podemos ver claramente o quão eficaz a XP pode ser, mas também, ao mesmo tempo , o quão complicado pode ser aplicar ela.

Isso claramente não se aplica somente a XP, e sim à todas as metodologias àgeis, mas realmente a XP é a unica que precisa ter Coragem, ela é muito intensa quando comparada com outras metodologias e pode ser um desafio muito forte para aqueles programadores que estão saindo agora do desenvolvimento em cascata. Trabalhar com código padronizado, e ter que sacrificar práticas lentas para adota um modo ágil é o maior desafio de todo programador no começo de uma interação com AG.

II.1.2 -Equipe

Em AG, cada membro de uma equipe recebe um papel e junto à esse as suas prioridades e tarefas. Em XP não seria diferente.

1.2.1 Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.

O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.

Para um bom exercício de gerente de projeto é necessário que a pessoa conheça e acredite nos valores e práticas do XP para que possa cobrar isto da sua equipe.

1.2.2 Coach

Pessoa responsável pelas questões técnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e práticas do XP. É de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.

13

1.2.3 Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.

Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.

1.2.4 Redator técnico

Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação. Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

1.2.5 Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.

Naturalmente existe níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming , a tendência é a equipe se tornar uniforme em suas habilidades.

II.2 – Considerações Finais

O método de desenvolvimento ágil é algumas vezes criticado como modelo balbúrdia(quando o programador segue uma metodologia mental baseada na própria experiencia).

O início da Programação Extrema soava como controverso e dogmático, tal como a programação por pares (pair programming) e o projeto contínuo, tem sido alvo particular de muitos críticos. Contudo, muitas destas críticas têm sido vistas pelos defensores dos métodos ágeis como mal entendidos a respeito do AG.

Em particular, a Programação Extrema recebeu as seguintes críticas:

 Falta de estrutura e documentação necessárias;

 Somente trabalhar com desenvolvedores de nível sênior;

 Incorpora de forma insuficiente o projeto de software;

 Requer a adoção de muita mudança cultural;

 Poder levar a maiores dificuldades nas negociações contratuais.

Realmente, nunca vai existir nenhum método perfeito, por isso existem vários e cada empresa deve procurar escolher o que mais se encaixa a cultura dela. Para isso, na documentação dos mais diversos métodos ágeis existe descrições de que cenários são perfeitos para execução deles.

Vale então para finalizar, destacar aqui alguma das caracteristicas ambientais para o bom desenvolvimento da XP:

15

 Mudanças freqüente de requisitos;

 Pequeno número de desenvolvedores;

 Cultura que tem sucesso no caos.

É muito comum em AG ser recomendado um ambiente de baixa criticidade, o que na verdade, não se aplica à XP , afinal esta é um método muito rápido , dinamico e mutável com foco muito especifico em qualidade, e com grande quantidade de feedbacks. Dentro da programação extrema todos devem estar se criticando o tempo todo na busca pela perfeição.

A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo em virtude dos fatos enunciados na Introdução.

Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.

Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.

REFERÊNCIAS BIBLIOGRÁFICAS

Wikipedia.org -> Programação Extrema, Metodologias de Desenvolvimento Agil. Livro: Extreme Programming Explained: Embrace Change.

Agile Manifesto - Manifesto para Desenvolvimento Ágil de Software - http://www.agilemanifesto.org/iso/ptbr/ . Livro: Logicomix: Uma Jornada Épica em Busca da Verdade – Aspectos sobre lógica que auxiliaram na pesquisa do trabalho tal como na escrita.

Livro: The Pragmatic Programmer – O Princípio DRY.

Site: Apresentando XP. Encante seus clientes com Extreme Programming

-