16/04/2010

Ricardo de Sousa Britto rbritto@ufpi.edu.br

Longe de acordo

Anarquia

Requerimentos

Complexo

Perto de Acordo

Simples
Perto da certeza

Tecnologia

Longe da certeza

Requerimentos

Projeto

Cdigo

Teste

Ao invs de completar uma coisa por vez... ... Metodologias geis fazem um pouco de cada coisa, todo o tempo.

16/04/2010

Indivduos e interaes Software que funciona Colaborao do cliente Resposta mudanas

ao invs de

Processos e ferramentas Documentao abrangente Negociao de contrato Seguir um plano

Extreme Programming (XP) Scrum Crystal ...

XP um processo de desenvolvimento que busca assegurar que o cliente receba o mximo da equipe de desenvolvimento. organizado em torno de um conjunto de valores e prticas que atuam hamnicamente assegurar alta qualidade de software Adequado principalmente para:
Projetos com requisitos vagos e dinmicos; Desenvolvimento orientado a objetos; Equipes pequenas, preferencialmente at 12 pessoas; Desenvolvimento incremental.

Uma equipe que utilize XP composta normalmente pelos seguintes papis:

Gerente de projeto Coach Analista de Teste Redator Tcnico Desenvolvedor

16/04/2010

Gerente de projeto serve de ponte entre a equipe, os clientes e eventuais fornecedores. Ele assegura que as pessoas certas dialoguem dentro da equipe e fora dela. Gerentes de projeto tambm devem monitorar o progresso da equipe e ajud-la a perceber continuamente tudo o que j foi conquistado. Devem motivar os membros da equipe atravs do orgulho de estar construindo um software bem feito. Deve administrar presses externas e comunicar o que est acontecendo a todos os envolvidos no projeto.

o responsvel tcnico do projeto. Possui como principal funo garantir que a equipe siga as prticas recomendadas pelo XP. Deve assegurar, primariamente, o bom funcionamento do processo de desenvolvimento. Pode atuar tambm na implementao do sistema.

Ajudam clientes e desenvolvedores a escrever testes para as histrias, antes mesmo que elas sejam implementadas. Trabalham com os desenvolvedores ao longo da iterao, ajudando-os a automatizar os testes. Quando a equipe no consegue automatizar alguns testes, os analistas de teste os executam manualmente.

Um dos desafios de um projeto XP o ritmo semanal de desenvolvimento. Se a equipe tiver que manter documentos extensos e muito elaborados, ela dificilmente ser capaz de entregar um conjunto significativo de novas funcionalidades a cada iterao. Redatores tcnicos asseguram que a documentao evolua de forma iterativa, atualizando os documentos mais perto do fim das iteraes. Dessa forma, eles descrevem o que foi feito de fato pelos desenvolvedores, ao invs daquilo que eles combinaram que iriam fazer.

a pessoa que analisa, projeta e codifica o sistema. Dentro do XP, no existem divises entre analistas, projetistas, programadores... Cada desenvolvedor exerce diferentes papis em diversos momentos do projeto
Multifuncionalidade

O XP se baseia em 4 valores fundamentais:

Feedback Comunicao Simplicidade Coragem

16/04/2010

Cliente aprende com o sistema que utiliza e re-avalia suas necessidades, gerando feedback para equipe de desenvolvimento. Desenvolvedores geram feedback para cliente apresentando estimativas, riscos tcnicos, alternativas de design... Processo de troca de informao feito mais rapidamente que em metodologias tradicionais.

A comunicao entre cliente e equipe permite que todos os detalhes do projeto sejam tratados com ateno merecida. XP procurar garantir que a comunicao ocorra da forma mais direta e eficaz possvel
Comunicao face-a-face (nem sempre possvel, mas ideal); Comunicao por meio de documentao.

Deve-se implementar apenas o suficiente para atender a cada necessidade do cliente.

Codificar funcionalidades que resolvam os problemas de hoje. Evitar trabalho especulativo;

Implementando apenas o necessrio, o cliente recebe mais rapidamente a funcionalidade

Feedback mais frequentes; Cliente pode utilizar funcionalidade no seu negcio.

16/04/2010

XP uma metodologia nova e muitas de suas premissas contrariam as metodologias tradicionais. A adoo de XP exige da equipe coragem para aplicar seus valores e princpios, de modo a se desenvolver com qualidade.

Cliente presente Jogo do Planejamento Stand up meeting Programao em par Desenvolvimento guiado por testes Refactoring Cdigo coletivo Cdigo Padronizado Design Simples Metfora Ritmo Sustentvel Integrao Contnua Releases Curtos

Metfora do carro em linha reta. Cliente deve conduzir o desenvolvimento a partir do feedback recebido do sistema. importante a presena ativa do cliente de modo a ocorrer a troca de feedback. Esta prtica tambm ajuda na viabilizao da simplicidade do processo (comunicao).
Situao ideal: Cliente sempre disponvel. Realidade: Clientes normalmente so empresas que alocam uma pessoa responsvel pela comunicao (muito ocupada)

O planejamento usado em XP para assegurar que a equipe esteja sempre trabalhando no mais importante, a cada momento do projeto. O XP considera o planejamento uma atividade contnua a ser desempenhada ao longo de todo o projeto. Projetos XP procuram dividir o tempo disponvel para o projeto utilizando dois conceitos: releases e iteraes.

16/04/2010

O XP tem releases que tomam alguns poucos meses, que se dividem em iteraes de duas semanas, que se dividem em tarefas que tomam alguns dias.

O planejamento aloca estrias (fragmentos de funcionalidades) em releases e iteraes. Elas so registradas em pequenos cartes, fceis de serem manipulados pelo cliente e pelos desenvolvedores. Em cada ciclo de release, o cliente controla o escopo, decidindo o que fazer e o que adiar. O trabalho se encaixa no cronograma baseado no valor para o negcio, dificuldade e a velocidade de implementao da equipe

Um release representa um marco no tempo no qual um conjunto coeso de funcionalidades finalizado e lanado para consumo de seus usurios. No espao de tempo de um release a equipe implementa funcionalidades em iteraes curtas e fixas que fornecem cadncia ao processo de desenvolvimento.

Uma iterao um incremento de software til que projetado, programado, testado, integrado e entregue durante um espao de tempo curto e fixo. Este software ser aprimorado em iteraes futuras, mas se trata de cdigo funcionando, testado e integrado desde o incio. Iteraes fornecem um aumento dramtico de feedback em relao ao desenvolvimento de software seqencial.

O final de uma iterao representa um ponto de sincronizao no projeto. o momento no qual o cliente e os desenvolvedores avaliam as funcionalidades produzidas e re-avaliam as prioridades para as iteraes seguintes. Alm disso, permite que eventuais falhas sejam detectadas antes de seguir adiante com o desenvolvimento.

16/04/2010

As funcionalidades so representadas atravs de histrias, que refletem necessidades do cliente. Devem ser suficientemente pequenas para que os programadores possam implementar um pequeno conjunto delas a cada iterao. Uma histria deve ser compreensvel pelo cliente e pelos desenvolvedores, testvel, valiosa para o cliente.

Papel do cliente:
Define as histrias; Decide qual o valor de negcio de cada histria e Decide que histrias sero construdas no release.

Os programadores:
Estimam quanto tempo ser necessrio para construir cada histria; Advertem o cliente sobre riscos tcnicos significativos e Medem o progresso da equipe para fornecer um oramento geral para o cliente.

As estimativas so geradas com base em experincias passadas dos desenvolvedores.

Observa-se as histrias que ainda precisam ser implementadas; Procura-se identificar outras que j tenham sido finalizadas no passado e que sejam semelhantes s histrias que ainda sero desenvolvidas no futuro.

Com o objetivo de assegurar que as partes trabalhem bem em conjunto, o XP utiliza uma breve reunio diria chamada de stand up

meeting. Ela procura alinhar os membros da equipe

informando os resultados obtidos no dia anterior e permitindo que os participantes priorizem as atividades do dia que se inicia.

O melhor guia para estimar o futuro olhar alguma coisa que aconteceu no passado que seja parecida com a coisa futura.

16/04/2010

Projetos XP procuram assegurar que a equipe trabalhe sempre naquilo que mais prioritrio primeiro. Existem diversos ciclos de planejamento e o stand up meeting usado para o planejamento dirio das atividades da equipe. Alm de disseminar informaes sobre o dia anterior, a equipe prioriza o trabalho a ser feito no dia que se inicia. Normalmente rpida e feita com os mebros da equipe em p.

Todo cdigo escrito em par (condutor e navegador) Um digita, enquanto o outro revisa, corrige e sugere Reduo drstica de bugs Disseminao de conhecimento Presso do par Simplicidade Velocidade

Reao inicial a programao em par:

Aumento de gastos (100%)

Problemas:
Presena de programadores com ego excessivamente elevado. Competio entre os membros da equipe.

Realidade:
Pesquisas demonstram que a programao em par eleva o nmero de programador-hora em apenas 15%.

Mesmo com um pequeno aumento nos custos, os resultados da aplicao desta tcnica so muito positivos:
nmero significativamente menor de defeitos menos cdigo para solucionar o mesmo problema resultados mais consistentes

16/04/2010

Projetos XP investem diariamente no aprimoramento do design e na identificao de pontos da arquitetura que estejam se degradando. medida que os problemas so encontrados, eles so corrigidos atravs de uma tcnica conhecida como refactoring. A refatorao o processo de fazer mudanas em um cdigo existente e funcional sem alterar seu comportamento externo.

Os seguintes princpios devem ser levados em considerao na execuo do refactoring:

Simplicidade Em quase todas as reas, um design simples e funcional o melhor design. Clareza O cdigo deve ser fcil de entender por todos aqueles que iro eventualmente trabalhar com ele. Adequao ao uso Todo design deve alcanar o propsito para o qual foi criado. Ausncia de repetio Cdigo idntico jamais deveria existir em dois ou mais lugares. Ausncia de funcionalidades extras Quando o cdigo no mais necessrio, o desperdcio envolvido em mant-lo elevado

Equipes XP normalmente no alocam um tempo especial do projeto para refatorar. Diversas pequenas refatoraes so executadas diariamente, medida que novas funcionalidades so produzidas. Existem trs situaes que so particularmente crticas:
Quando existe duplicao; Quando percebemos que o cdigo e/ou a sua inteno no est clara Quando detectamos code smells, isto , sutis (ou no to sutis) indicaes da existncia de um problema

16/04/2010

Apesar dos aparentes benefcios da refatorao, um problema que pode surgir a velocidade do desenvolvimento. Em princpio, o esforo de refatorao parece representar um re-trabalho e um custo adicional para o projeto. Como os projetos de software normalmente sofrem com prazos curtos, pode ser que simplesmente no haja tempo disponvel para refatorar.

Equipes XP acreditam que refatorar diariamente ajuda a manter um ritmo acelerado de desenvolvimento. H uma falsa percepo de que seja relativamente fcil avanar rapidamente sem refatorao no incio do projeto. A falta de tempo freqentemente usada como desculpa para no refatorar, entretanto a refatorao que no feita imediatamente acaba tendo que ser feita mais tarde(+custos)

Mudanas = risco de bug A adoo da prtica de refatorao s pode ocorrer em projetos que produzam testes automatizados. Uma ferramenta chave que anda de mos dadas com a refatorao, e de fato a torna vivel so os testes automatizados.

Todas as classes e mtodos pertencem equipe e qualquer membro da equipe pode melhorar o que for necessrio. O desenvolvedor no apenas programa em par com diferentes pessoas ao longo do tempo, como tambm tem acesso a todas as partes do cdigo, inclusive aquelas que ele no programou. Alm disso, tem o direito de fazer qualquer alterao que considerar necessria sem ter que pedir permisso.

Os desenvolvedores tm a oportunidade de trabalhar com pessoas diferentes e em partes diferentes do cdigo. Existe um revezamento dirio em ambos os aspectos. Se estabelece mais uma rede de proteo, visto que os programadores podem revisar e alterar o cdigo escrito em diferentes partes do sistema, por diferentes pessoas. Como alteraes no cdigo podem causar erros, a prtica de cdigo coletivo s pode ser adotada com segurana se a equipe investir em testes automatizados.

Esta prtica tambm protege o projeto ajudando a tornar a equipe mais robusta. Os desenvolvedores se habituam a trabalhar nas mais variadas partes do sistema. Se algum ficar doente o desenvolvimento no para. Ningum precisa esperar at que outra pessoa aparea para consertar alguma coisa. A equipe tem razes genunas para manter o cdigo simples ao longo do projeto.

10

16/04/2010

Em projetos XP, os programadores codificam seguindo um padro de cdigo acordado. No importa muito o formato. O que realmente importa que todos os membros da equipe adotem o padro e o utilizem sempre. A adoo de um padro ajuda a simplificar a comunicao, a programar em par e a tornar o cdigo coletivo.

A prpria programao em par e a prtica de cdigo coletivo ajudam a assegurar que a equipe ir seguir o padro adotado. Como o cdigo passa por vrios nveis de reviso, fcil detectar e corrigir qualquer cdigo fora do padro.

Oque mais barato: Previnir ou remediar?

essencial que as equipes de desenvolvimento sejam capazes de reduzir a incidncia de bugs e o custo associado depurao e eliminao dos mesmos. Isso vlido durante o projeto, porm ainda mais relevante durante a manuteno de um sistema. Equipes XP lidam com estes problemas utilizando uma tcnica conhecida como desenvolvimento orientado a testes.

Consiste em escrever um mecanismo de teste automatizado antes de codificar cada histria e cada mtodo do sistema. Trata-se de uma tcnica preventiva utilizada durante todo o projeto e a manuteno. A preveno usada porque antes da questo de como resolver problemas vem a questo de evitar problemas.

11

16/04/2010

Os testes automatizados procuram comprovar que as solicitaes dos usurios esto sendo atendidas de forma correta. Os testes verificam se as histrias continuam funcionando ao longo do tempo. O XP se concentra sobretudo em dois tipos de testes:
Teste de unidade - Tenta assegurar que cada componente do sistema funcione corretamente. Teste de aceitao - Procura testar a interao entre os componentes, as quais do origem s funcionalidades;

So escritos antes de cada mtodo produzido no sistema. a forma utilizada pelos desenvolvedores para saber se o mtodo ir funcionar ou no. Deve haver um teste para cada mecanismo que o desenvolvedor implementar.

Feedback imediato importante porque evita que os defeitos passem muito tempo despercebidos. Depurar costuma ser custoso porque o desenvolvedor esquece o que fez, por que fez e o contexto em torno da funcionalidade que se encontra defeituosa. Quanto mais tempo se passa entre o momento em que o erro introduzido e o momento em que identificado, maior tende a ser o tempo de depurao. O feedback imediato gerado pelos testes de unidade ajuda a reduzir este tempo e, portanto, consegue acelerar a depurao.

Para se ter testes de unidade eficientes, esses testes devem ser automatizados. Se os testes no forem automatizados ou se tomarem muito tempo, eles no sero executados com suficiente freqncia. Grandes lotes de mudanas sero implementados antes de testar, o que tornar muito mais provvel a ocorrncia de falhas. Ser bem mais difcil identificar que mudana fez com que os testes falhassem.

So escritos para assegurar que o sistema como um todo funcione. Eles tipicamente tratam o sistema inteiro como uma caixa preta tanto quanto possvel. Estes testes so escritos pelo cliente ou com a orientao do cliente, pois ele a pessoa que conhece o negcio.

Os clientes escrevem teste para uma histria de cada vez. A pergunta que eles precisam se fazer :
O que necessitaria ser verificado antes que eu tivesse a confiana de que esta histria est finalizada?

Cada cenrio que eles imaginam se transforma em um teste

12

16/04/2010

Novas funcionalidades e eventuais correes inseridas em um cdigo tm o potencial de adicionar novos defeitos no mesmo. Por essa razo, aps cada correo [ou adio de funcionalidade], deve-se executar a base de casos de teste inteira. Desta forma tenta se assegurar que o sistema no foi danificado de uma forma obscura.

Escrever um teste antes de cada histria tambm representa uma forma de aprimorar a anlise sobre as caractersticas dela. A necessidade de implementar um teste fora o desenvolvedor a buscar maiores detalhes sobre o comportamento da funcionalidade. O desenvolvedor se coloca no papel de consumidor e a necessidade de implementar o teste o fora a simplificar a implementao do cdigo de produo.

Equipes XP normalmente so compostas por diversos programadores, trabalhando em pares de acordo com a prtica de cdigo coletivo. Dois problemas prticos:
Sempre que diversos indivduos esto trabalhando na mesma coisa, ocorre uma necessidade de sincronizao. Os pares precisam ser capazes de evoluir rapidamente sem interferir no trabalho uns dos outros.

Os pares trabalham de forma isolada, porm integram o que produzem com a verso mais recente do cdigo de produo, diversas vezes ao dia. Os pares se sincronizam com freqncia medida que terminam pequenas atividades de codificao.

Soluo: Integrao Contnua

Toda vez que um par integra seu cdigo, h um risco de que identifique um erro na integrao. Existe a chance, por exemplo, de que dois pares distintos tenham efetuado alteraes conflitantes em uma mesma linha do cdigo. De um modo geral, os pares procuram descobrir estes eventuais conflitos to cedo quanto possvel.

O processo de integrao serial, isto , somente um par pode integrar o seu cdigo de cada vez. Isso assegura que eventuais erros de integrao estaro sempre relacionados a um nico par Somente aps assegurar que a integrao est perfeita e todos os testes executam com sucesso poder outro par fazer a integrao.

13

16/04/2010

Mais projetos de software saem de curso por falta de tempo do que por qualquer das outras causas combinadas. Quando isso acontece, os projetos normalmente adotam duas estratgias:
a utilizao de recursos no limite mximo a adoo de horas-extras de trabalho.

A sobrecarga da equipe com muitas horas de trabalho leva aos seguintes efeitos colaterais:
Qualidade reduzida; Esgotamento pessoal; Maior rotatividade e Uso ineficaz do tempo durante as horas regulares de trabalho

O XP recomenda que os membros da equipe de desenvolvimento trabalhem apenas durante o tempo regulamentar e evitem horas-extras tanto quanto possvel. Sugere-se tambm que os prazos sejam mantidos fixos e as cargas de trabalho sejam ajustadas (atravs de priorizao) para se adequar aos prazos.

As presses de tempo so tratadas atravs do processo de priorizao e o ajuste do escopo de cada iterao para a real capacidade de entrega da equipe. Como essa capacidade pode variar ao longo do tempo, ela permanentemente monitorada e ajustada medida que o projeto avana.
Quando estiver sobrecarregado, no pense nisso como se no tivesse tempo suficiente;pense nisso como tendo coisas demais para fazer. Voc no pode se conceder mais tempo, mas pode se permitir fazer menos coisas

www.improveit.com.br/xp http://www.xprogramming.com/xpmag/what isxp.htm http://agilemanifesto.org/

14