Metodologias de Desenv. Ágil – XP – Régis Simão e Ciro Coelho 1/59 Extreme Programming Régis...

Metodologias de Desenv. Ágil – XP – Régis Simão e Ciro Coelho 1/59

Extreme Programming

Régis Simão e Ciro Coelho


Agenda

Introdução

Valores

Ciclo de Vida

Práticas

Documentação

Equipe

Quando não usar XP

Como implantar

Bibliografia


Livros

Introdução


Livros – The XP Series

Introdução


Outras Referências

Site:

www.improveit.com.br/xp

Grupos:

http://tech.groups.yahoo.com/group/xprio

http://br.groups.yahoo.com/group/xprecife

http://tech.groups.yahoo.com/group/xp-rs

http://br.groups.yahoo.com/group/xpnorte

http://tech.groups.yahoo.com/group/xpsc

http://tech.groups.yahoo.com/group/xpbh

http://tech.groups.yahoo.com/group/xpsp

Introdução


Extreme Programming (XP) é um processo de desenvolvimento de software voltado para:

Projetos cujos requisitos são vagos e mudam com freqüência;

Desenvolvimento de sistemas orientados a objetos;

Equipes pequenas, preferencialmente até 12 desenvolvedores;

Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.

Introdução

Fonte: Livro Extreme Programming. Autor Vinícius Manhães Teles


Feedback

Comunicação

Simplicidade

Coragem

Valores


Feedback

Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, gerando feedback para a equipe de desenvolvimento.

É o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente.

Garante que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.

Valores


Comunicação

O XP busca aproximar todos os envolvidos do projeto

Permite que o cliente compartilhe o seu aprendizado com a equipe

Valores

Promover a comunicação face-a-face ou da forma mais rica que for viável.

A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem.


Feedback e Comunicação

Valores


Simplicidade

Temos que implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente.

Ao codificar, deve-se preocupar apenas com os problemas de hoje.

Deve-se deixar os problemas do futuro para o futuro.

As generalizações devem ser feitas quando elas vierem na forma de uma necessidade específica e não como uma especulação.

Valores


Coragem

“A equipe precisa ser corajosa e acreditar que, utilizando as práticas e valores do XP, será capaz de fazer o software evoluir com segurança e agilidade.”

“Em muitos casos, a equipe alterará algo que vinha funcionando corretamente, o que leva ao risco de gerar falhas no sistema.”

TELES, Vinícius M. Extreme Programming.

Novatec Editora, 2006

Valores


Desenvolvimento Tradicional

Desenvolvimento Ágil

Ciclo Semanal

Ciclo de Vida



Ciclo de Vida em Cascata

Forte influência da Revolução Industrial

Software construído linearmente, seguindo uma seqüência de fases

Ciclo de Vida

Definição de Requisitos

Projeto de Software

Implementação e teste de unidade

Integração e teste de sistema

Operação e Manutenção



Ciclo de Vida em Cascata

Base de vários processos de software

Interpretação errada do ciclo de vida do Rational Unified Process (RUP)

Ciclo de Vida



Características do Ciclo de Vida em Cascata

Linearidade

Determinístico

Especialização

Foco na execução

Ciclo de Vida



Categorias de Trabalhadores (Drucker, 1999. In: Teles, 2006)

Trabalhador Manual

Habilidades Manuais

Fácil de Automatizar

Determinístico

Repetitivo

Trabalhador do Conhecimento

Uso intensivo de conhecimento e criatividade

O XP vê o desenvolvimento de software como um processo de uso intensivo de conhecimento e criatividade

Ciclo de Vida



Ciclo de Vida Incremental

Ciclo de Vida

Definir esboço dos requisitos

Atribuir requisitos aos incrementos

Projetar arquitetura do sistema

Desenvolver incremento do sistema

Validar incremento

Integrar incremento

Validar sistema

Sistema incompleto

Sistema final



Ciclo de Vida em Espiral

Ciclo de Vida

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Ciclo de Vida


Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles


Ciclo de Vida

Ciclo Semanal

Definição com o cliente

Desenvolvimento

Teste

Avaliação pelo cliente


Validação parcial com o cliente


Ciclo de Vida

Fonte: Palestra Extreme Programming, abraçando a mudança. Autor Helder da Rocha

Ciclo Semanal

Feedback e Aprendizagem


Práticas

Jogo do Planejamento

Cliente Presente

Stand Up Meeting

Desenvolvimento guiado pelos Testes

Programação por Pares

Refactoring

Código Coletivo

Código Padronizado

Design Simples

Ritmo Sustentável

Integração Contínua

Releases Curtos

Metáfora


Práticas


É uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração.

Visa assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente a cada dia de trabalho.

O projeto é dividido em Releases e Iterações.

Cliente e a equipe podem revisar o planejamento constatemente.

As funcionalidades são descritas em pequenos cartões e são chamadas de Estórias.


Práticas


Exemplos de Estórias (Teles, 2006):

Apresente ao cliente as dez tarifas mais baratas para uma determinada rota (Beck, 2001).

Para cada conta, computar o saldo fazendo a adição de todos os depósitos e a subtração de todas as deduções (Jeffries, 2001).

Produzir um extrato para cada conta, mostrando a data, o número, o beneficiário e a quantia da transação. Segue um extrato de exemplo em anexo – faça o relatório parecer com o exemplo (Jeffries, 2001).

A tela de login deve permitir que o usuário pule o login. Neste caso, o usuário entrará no sistema como guest (Newkirk, 2001).

O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, último nome e filiação). Dois campos de senha para confirmação (Newkirk, 2001).


Práticas


Estórias

São sempre escritas pelo próprio cliente.

Criam um vínculo com o cliente.

Formalizam o pensamento do cliente.

Não têm formato de escrita.

Devem ser limitadas pelo tamanho do cartão, simplicidade.

Podem ser dividas em tarefas, quando muito complexas.

Dão a noção de custo.

Cada desenvolvedor seleciona uma estória ou tarefa a ser feita em um determinado prazo.


Práticas


Estimativas

Estimativa baseada no conceito de Dia Ideal de Desenvolvimento (só para implementação).

Estima-se cada estória com a unidade Ponto (dia ideal de desenvolvimento).

No canto superior esquerdo do cartão, colocam-se os pontos estimados.

No canto superior direito do cartão, ficam os pontos realmente consumidos.

A estimativa deve ser por comparação.

A estimativa deve ser feita em equipe.

O cliente deve sempre participar.

Velocidade é a quantidade de pontos que uma equipe implementou na iteração anterior.


Práticas


Exemplo de Planejamento de uma Iteração de 2 semanas:

2 semanas = 10 dias úteis

1 dia útil para a reunião de planejamento da iteração

1 dia útil para a reunião de encerramento da iteração

Dias úteis disponíveis para o desenvolvimento = 10 – 2 = 8

Números de desenvolvedores = 6 = 3 x 2 = 3 pares

1 par / dia = 1 ponto

1 par em 8 dias = 1 x 8 = 8 pontos

3 pares em 8 dias = 3 x 8 = 24 pontos



Acompanhamento Visual


Não iniciado Em andamento Finalizado

Práticas


Práticas

Cliente Presente

O cliente deve estar presente durante o desenvolvimento.

Presente em:

Reuniões de Planejamento das Releases e das Iterações

Reuniões de Encerramento das Releases e das Iterações

Alguns momentos do desenvolvimento para tirar dúvidas e validar algumas informações.

O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema.

A presença do cliente simplifica a comunicação.


Práticas

Stand Up Meeting

Reunião rápida que a equipe de desenvolvimento faz a cada manhã para avaliar o trabalho do dia anterior e priorizar aquilo que será implementado no dia.

Três perguntas devem ser respondidas por cada desenvolvedor:

O que foi feito no dia anterior?

O que vai ser feito hoje?

Tem algo atrapalhando ou necessário para o trabalho a ser realizado?

Os problemas relatados devem ser tratados fora da reunião!


Práticas

Desenvolvimento Guiado pelos Testes

Os desenvolvedores escrevem testes para cada funcionalidade antes de implementá-las.

Benefícios:

melhoram o entendimento sobre as necessidades do cliente,

projetam melhor as interfaces externas dos métodos e classes e

limitam até onde codificar cada funcionalidades.

Tipos de Testes:

Testes de Unidade sobre cada classe, criado e executado pelo Desenvolvedor

Testes de Aceitação sobre funcionalidade ou estórias, escrito pelo cliente e pelo Analista de Testes, executado principalmente pelo cliente


Práticas


Exemplo de um Teste de Unidade

Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).


Práticas


Exemplo de um Teste de Aceitação

Fonte: Livro Extreme Programming, Autor: Vinícius Manhães Teles


Práticas

Programação em Pares

A implementação é sempre feita por duas pessoas.

Enquanto uma pessoa implementa, a outra avalia o código que está sendo feito, realizando uma revisão constante.

A cada 15 minutos, a pessoa que está implementado passa a fazer a avaliação e a outra implementa.

A cada turno as duplas trocam.


Práticas

Programação em Pares

Benefícios:

Aumenta a produtividade

Melhora a solução

Dissemina conhecimento de negócio

Nivela habilidades

Desafios:

Organização do escritório

Visão gerencial

Relacionamento humano

Competição


Práticas

Refactoring

O refactoring é a técnica de alterar o código sem alterar a funcionalidade.

O objetivo é fazer o código ficar mais simples de ser manipulado.

Anda de mãos dadas com o código coletivo e testes de unidades.

Existem livros específicos sobre técnicas de refactoring.


Práticas

Código Coletivo

Procura evitar “ilhas de conhecimento”.

Quando só uma pessoa conhece uma solução, pode ser um gargalho no desenvolvimento.

Com a programação em pares, os desenvolvedores passam a ser conhecedores de todas as funcionalidades.

Eles têm acesso a todas as funcionalidades, podendo alterá-las sem necessitar de autorização, inclusive fazendo refactoring.


Práticas

Código Padronizado

A equipe deve estabelecer padrões de implementação que devem ser seguidos por todos.

Isto agiliza as manutenções e torna o código mais homogêneo.

Exemplo:

Code Conventions for the Java Programming Language da SUN

Writting Robust Java Code de Scott Ambler

Características de um padrão:

Indentação

Letras maiúsculas e minúsculas

Comentários

Nome


Práticas

Código Padronizado

Quando alguém encontra algo fora do padrão deve-se:

Alertar a equipe o que está fora do padrão e forma correta de fazer.

Fazer refactoring do código, colocando-o no padrão.

Dificuldades

Ter um padrão. Se não tiver, utilize um pronto!

Mudança de hábito.


Práticas

Design Simples

Para ser ágil, a equipe deve optar por um código que seja suficiente para atender as necessidades atuais do cliente.

Necessidades futuras serão atendidas quando elas forem requisitadas, fazendo-se uso do refactoring e testes, por exemplo.

A única coisa constante em um projeto de software é a mudança (Beck, 2000. In: Teles, 2006):

Os requisitos mudam

O design muda

A tecnologia muda

A equipe muda

Os membros da equipe mudam


Práticas

Design Simples

Estratégia do XP para um código simples (Teles, 2006):

Comece escrevendo um teste para funcionalidade a ser desenvolvida.

Faça o design e implemente apenas o suficiente para passar nos testes.

Repita os passos 1 e 2 quantas vezes forem necessárias.

Se você identificar a oportunidade de tornar o design mais simples, faça-o.


Práticas

Design Simples

Ferramentas:

Utilize as ferramentas mais simples.

Se desejar gerar documentações e diagramas, lembre que tem que mantê-las atualizadas.

A documentação sempre tem que refletir o código, senão não serve pra nada!

Documente as decisões importantes.


Práticas

Ritmo Sustentável

Os desenvolvedores devem trabalhar apenas 8 horas por dia.

As horas-extras devem ser evitadas.

Isto para permitir que os desenvolvedores se mantenham atentos, criativos e dispostos a solucionar os problemas.

Sugestão:

08:00 às 08:30 Ler e-mails

08:30 às 09:00 Stand Up Meeting

09:00 às 12:00 Programação em Pares

14:00 às 17:00 Programação em Pares

17:00 às 17:30 Ler e-mails

17:30 às 18:00 Estudo para refactoring


Práticas


Consiste da equipe integrarem seus códigos com o restante do sistema várias vezes ao dia.

Para garantir que o sistema esteja funcionando corretamente após uma integração, é necessário realizar todos os testes (testes de regressão).

Código avança através de três fases:

local,

candidato à liberação e

disponibilizado no repositório

Utilize uma máquina em separado para a integração: backup e “ritual”.


Práticas


Ferramentas:

Ferramenta de build

Sistema de controle de versão

O processo de integração é feito corretamente quando:

Deve ser fácil e rápido obter o código fonte do qual você necessita;

Deve ser fácil e rápido armazenar as suas mudanças;

O repositório deve detectar conflitos e é importante que seja simples resolvê-los;

Não deve haver espera, isto é, se um par precisa editar alguma coisa, ele deve seguir adiante sem que nada o impeça.


Práticas

Releases Curtos

A equipe deve produzir um conjunto pequeno de funcionalidades (release)

Colocar a release em produção rapidamente para que o cliente possa fazer uso das funcionalidades o mais cedo possível.

Durante o projeto, a equipe colocará diversas versões do sistema em produção, gerando um fluxo contínuo de valor para o cliente.

Aumenta Feedback

Aumenta o Retorno do Investimento


Práticas

Releases Curtos



Práticas

Metáfora

A equipe de desenvolvimento transmite idéias complexas de forma simples através de metáforas.

A metáfora do time de futebol para entender a utilização das práticas de futebol


Documentação

Por que documentar?

Permitir que rapidamente um desenvolvedor possa criar ou manter um código.

Até que ponto documentar?

O suficiente para apoiar o código: testes de unidade, testes de aceitação e outras documentações.

Quando documentar?

Próximo da implementação (antes ou depois), para que o negócio não mude enquanto se documenta.

Dentro da mesma iteração.


Documentação

Sugestão de Documentação

Estórias

Testes de Aceitação

Testes de Unidade

Javadoc

Modelo de Classes

Modelo de Dados

Processo de Negócio

Manual do Usuário

Acompanhamento Diário

Acompanhamento do Projeto

Fotos


Gerente de Projeto

Coach

Analista de Teste

Redator Técnico

Desenvolvedor

Equipe


Equipe

Gerente de Projeto

É responsável pelos assuntos administrativos do projetos. Libera a equipe de questões não ligadas ao desenvolvimento. Administra o relacionamento com o cliente, assegurando que o mesmo participe ativamente do desenvolvimento.

Coach

É o responsável técnico pelo projeto. Orienta a equipe nas boas práticas do XP. Pode atuar na implementação, mas a sua função principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.

Analista de Teste

É responsável por ajudar o cliente a escrever os testes de aceitação. Quando o teste não é automático, ele deve executar os testes diversas vezes ao longo das iterações.


Equipe

Redator Técnico

Ajuda a equipe a documentar o sistema. A equipe pode fazer documentação, mas a preocupação principal deve ser o código. O redator é quem faz a maior parte do trabalho de documentação.

Desenvolvedor

É a pessoa que analisa, projeta e codifica. Não existe distinção entre analista, projetista e programadores. O desenvolvedor faz estes diferentes papéis em diversos momentos do projeto.


Quando não usar XP

Sistemas de premiação individuais

Contratos de escopo fechado

Clientes que fazem questão de um grande número de artefatos

Empresas onde os layouts de escritórios são fixos

Quando não se tem apoio das pessoas que decidem

Equipes grandes e espalhadas geograficamente

Situações onde não se tem controle sobre o código (sistemas legados)

Situações onde o feedback é demorado


Como implantar

Uma prática de cada vez

Enfatize o problema mais importante

Dificuldades culturais

Deixar alguém mexer no seu código

Trabalhar em pares

Dificuldades devido a mudança de hábitos

Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível")

Jogar fora código desnecessário

Escrever testes antes de codificar

Refatorar com freqüência (vencer o medo)


TELES, Vinícius M. Extreme Programming. Novatec Editora, 2006.

TELES, Vinícius M. Workshop sobre Desenvolvimento Ágil. 2007.

DA ROCHA, Helder. Palestra sobre Extreme Programming: abraçando a mudança. 2002.

Bibliografia


FIM!!!

Metodologias de Desenv. Ágil – XP – Régis Simão e Ciro Coelho 1/59 Extreme Programming Régis...

Documents

Transcript of Metodologias de Desenv. Ágil – XP – Régis Simão e Ciro Coelho 1/59 Extreme Programming Régis...