ADOLFO GUSTAVO SERRA SECA NETO

TÉCNICAS ÁGEIS PARA O DESENVOLVIMENTO DE SOFTWARE EM JAVA

Apostila para curso de extensão

ministrado na Universidade Tecnológica

Federal do Paraná.

CURITIBA

2009

Sumário1. Introdução........................................................................................................................................................42. Introdução a Métodos Ágeis............................................................................................................................5

2.1. O Manifesto Ágil.....................................................................................................................................62.2. E se você não conhece Engenharia de Software?....................................................................................7

3. Desenvolvimento Dirigido por Testes.............................................................................................................93.1. Testes Automatizados..............................................................................................................................9

3.1.1. Problemas dos testes manuais..........................................................................................................93.1.2. Benefícios dos testes automatizados..............................................................................................10

3.2 Testes Unitários......................................................................................................................................113.3 O Processo de Desenvolvimento Dirigido por Testes............................................................................123.4 Testes de Aceitação................................................................................................................................14

4. Programação Pareada....................................................................................................................................155. Refatoração....................................................................................................................................................176. Considerações Finais.....................................................................................................................................18Referências........................................................................................................................................................19Outros materiais utilizados................................................................................................................................21

Fonte: http://creativecommons.org/licenses/by-nc-sa/2.5/br/

1. Introdução

Os métodos ágeis para o desenvolvimento de software vieram para ficar. Em minha opinião,

eles apresentam uma forma de desenvolver software de forma divertida e com mais qualidade.

Até o ano 2000, os principais livros de Engenharia de Software sequer mencionavam a

existência de métodos ágeis. De lá para cá, os métodos ágeis tornaram-se tema obrigatório de pelo menos um

capítulo destes livros.

Esta é a primeira versão desta apostila. É um texto em construção. Versões novas serão

liberadas futuramente. Agradeço quaisquer sugestões e indicações de erros, os quais poderão ser enviados

para adolfo@utfpr.edu.br.

Observação: neste documento não segui estritamente as normas da ABNT. Em alguns

momentos usei estas normas mas em outros (por exemplo, na citação de páginas da internet) não as segui. O

objetivo foi facilitar a distribuição deste material em formato digital, permitindo que os links ao longo do

texto sejam clicáveis.

2. Introdução a Métodos Ágeis

O que são Métodos Ágeis? A resposta a esta pergunta depende de uma outra pergunta. Você

sabe o que é Engenharia de Software?

Algumas respostas possíveis:

1. Sim, pois já fiz um bom curso de Engenharia de Software (ES) na Universidade.

2. Sim, pois já li um bom livro sobre Engenharia de Software.

3. Não, apenas desenvolvo software há bastante tempo.

4. Não, estou começando a desenvolver software

5. NDA (se for nenhuma das anteriores, me diga, pois quero saber qual é a sua resposta!!!)

Se você já conhece ES, provavelmente você já leu algum dos livros mais "tradicionais" sobre

Engenharia de Software.

Se colocarmos o termo "Software Engineering" (entre aspas) na Amazon

(http://www.amazon.com) selecionando "Books" na opção de busca, provavelmente os dois primeiros itens

retornados serão:

• Software Engineering: (Update) (8th Edition) by Ian Sommerville

• Software Engineering: A Practitioner's Approach by Roger Pressman

Ambos os livros foram traduzidos para o português. Resultados semelhantes são obtidos em

mecanismos de busca (Google, Bing, Curl) ao se colocar os termos "Software Engineering" e Book. No

Google, os dois primeiros links levam ao livro do Sommerville.

Estes dois livros, que de agora em diante chamarei de "o Sommerville" e "o Pressman" são os

mais tradicionais livros sobre Engenharia de Software.

Se você pelo menos já folheou com atenção estes dois livros, sabe que eles falam de

Engenharia de Software como a aplicação de técnicas/princípios/métodos de engenharias tradicionais (civil,

mecânica, elétricas) na construção de software.

Quando eu estudei por estes livros (e posteriormente quando eu lecionei ES usando estes

livros), na primeira metade da década de 1990, nada se falava sobre métodos ágeis. As mais recentes edições

destes livros possuem capítulos dedicados a estes métodos.

Quem conhece ES deve saber que os Métodos Ágeis (MAs) surgiram em clara oposição à ES

que era preconizada por estes livros. Os MAs surgiram como uma espécie de "revolta" de vários

"praticantes" de desenvolvimento de software (isto é, pessoas que desenvolviam software na prática, seja

como programadores-desenvolvedores, seja como gerentes de projetos) contra o excesso de burocracia dos

métodos "tradicionais" (não tão tradicionais assim pois a Engenharia de Software não é tão antiga quanto

outras engenharias). O primeiro grande passo para a popularização dos MAs foi o lançamento do Manifesto

Ágil.

2.1. O Manifesto Ágil

A “revolta” contra os métodos tradicionais fica clara no chamado Manifesto Ágil (BEEDLE,

2001), que reproduzimos abaixo na sua versão traduzida para o português pela empresa ImproveIt (veja em

http://www.manifestoagil.com.br/ ou em http://improveit.com.br/xp/manifesto_agil):

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e

ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas

• Software em funcionamento mais que documentação abrangente

• Colaboração com o cliente mais que negociação de contratos

• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James

Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve

Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.

©2001, Autores acima citados.

Esta declaração pode ser livremente copiada, sob qualquer forma, mas apenas na sua totalidade

através do presente aviso."

Fica clara a ideia de oposição, não fica? Os quatro itens principais do manifesto são no

seguinte formato (se os reescrevermos): "valorizamos mais X do que Y", onde Y é algo enfatizado pela

Engenharia de Software tradicional.

Não está dentro do escopo deste texto explicar tudo sobre métodos ágeis. Nas referências

vocês encontrarão indicações de leitura para aprender mais sobre métodos ágeis. Sugiro que leiam também

(na mesma página do Manifesto Ágil) os "princípios por trás do manifesto ágil".

2.2. E se você não conhece Engenharia de Software?

Neste caso, é uma excelente oportunidade para começar a desenvolver software da maneira

certa (ou pelo menos da maneira que "eu" acho certo).

Algumas ideias:

• desenvolver software deve ser prazeroso;

• software é algo flexível, relativamente fácil de ser modificado;

• durante o desenvolvimento de um software devemos estar prontos para mudanças de rumo,

principalmente as causadas por mudanças de requisitos (isto é, o "dono" do software, aquele que quer

que o software seja feito, mudou de ideia em relação ao que ele quer que o software faça);

• desenvolver software deve seguir alguns princípios;

• não deve existir nenhuma camisa de força para os desenvolvedores de software. Eles devem ter certa

liberdade sobre o que fazer. Desenvolvedor de software não é pedreiro. É um trabalhador criativo.

Está mais para artista;

• devemos minimizar a quantidade de defeitos (bugs) no software (bem óbvio, não?);

• nem tudo que o "dono" do software quer que seja implementado realmente deve ser implementado.

Muitas vezes o dono quer uma funcionalidade que custa muito mais do que o valor que receberá por

ela. Muitas funcionalidades de softwares existentes nunca são ou raramente são utilizadas;

• “fazer o software certo” é mais importante do que “fazer certo” o software;

• documente apenas o necessário. E o que é o necessário? Você e o seu cliente decidem! Para quê ter

um monte de diagramas UML elaborados com uma ferramenta maravilhosa se eles estiverem

desatualizados em relação ao código?

Para conhecer mais, leia sobre métodos ágeis e conheça alguns métodos específicos (por

exemplo, XP e Crystal). Escolha o que melhor se adequa a você e à sua organização. É possível misturar

métodos, seguir apenas parcialmente alguns métodos. Não é uma camisa de força.

Além disso, compartilhe suas experiências com outras pessoas. Participe de eventos sobre

métodos ágeis. Eles reúnem pessoas apaixonadas por desenvolvimento de software.

Por último, fique sempre com um pé atrás em relação ao marketing. Como em toda e qualquer

área, tem sempre gente querendo lucrar dando um nome diferente a algo que já existe. Por exemplo, tem

gente que chama métodos ágeis de "o Agile". Não vejo necessidade disso. Outro problema já bem

identificado e criticado pela própria comunidade de entusiastas dos MAs são as certificações para Scrum

(veja, por exemplo, http://improveit.com.br/scrum/certificacao).

3. Desenvolvimento Dirigido por Testes

Desenvolvimento Dirigido por Testes (DDT) é uma técnica ágil para o desenvolvimento de

software que preconiza que os testes devem ser escritos antes do código que será testado. Nesta seção, antes

de descrever o que é DDT e como DDT é feito, mostraremos o que são testes automatizados e testes

unitários. Por fim, após apresentar o processo de DDT, discutiremos brevemente testes de integração no

contexto de DDT.

3.1. Testes Automatizados

Testes automatizados são testes que podem ser executados. Isto é, são testes que podem ser

escritos, como quando escrevemos um programa, e depois executados. Em geral, para fazer-se testes

automatizados utiliza-se um arcabouço (framework) para testes automatizados (como, por exemplo, o JUnit

(JUNIT COMMUNITY, 2009)) que se encarrega de facilitar a escrita dos testes, permitir a execução de

suítes de testes e exibir os resultados de forma agradável, entre outras coisas.

Como se fazia teste de software antigamente (isto é, antes da existência dos testes

automatizados)? Executava-se o programa a ser testado com alguma entrada e conferia-se visualmente os

resultados obtidos (CHEQUE, 2008).

E como são feitos testes automatizados? Executa-se um programa (ou script executável) que

roda o programa a ser testado e faz verificações automáticas em cima dos efeitos colaterais obtidos

(CHEQUE, 2008). Isto é, no teste está escrito qual é a saída esperada para um programa dadas certas

entradas. O arcabouço roda o programa que está sendo testado passando as entradas e verifica se a saída é

igual à esperada.

Observação importante: testar NÃO é depurar! Testar é verificar a presença de erros. Depurar

é seguir o fluxo para identificar um erro conhecido (CHEQUE, 2008). Depurar tem papel importante quando

os testes indicam a presença de erros. Mas, de agora em diante, limitaremo-nos a falar de testes.

3.1.1. Problemas dos testes manuais

Por que utilizar testes automatizados? Por que os testes manuais (testes não automatizados) apresentam vários problemas. Vejamos alguns destes problemas (CHEQUE, 2008):

• É difícil repetir os testes;

• É demorado;

• É cansativo;

• Os testes acabam sendo feitos poucas vezes, com poucos casos, com casos muito simples;

• Quando os testes falham, gasta-se muito tempo fazendo a depuração;

• Os erros terminam sendo encontrados tardiamente, gerando pressão, desconforto, estresse, perda de

confiança.

3.1.2. Benefícios dos testes automatizados

E estes são alguns dos benefícios comprovados (ou pretendidos1) com os testes automatizados (CHEQUE, 2008):

• Todos os testes podem ser executados a qualquer momento;

• O código é submetido a testes mais vezes;

• Escrever testes automatizados ajuda a encontrar erros mais cedo;

• Escrever testes automatizados aumenta a velocidade do desenvolvimento;

• Escrever testes automatizados melhora a qualidade do código, diminuindo a quantidade de erros;

• Diminui o tempo gasto com depuração e correção;

• Aumenta o tempo gasto com a validação do software;

• Os desenvolvedores tem mais segurança para fazer mudanças no código, tais como:

• Adicionar novas funcionalidades;

• Corrigir erros (se a correção adicionar um novo erro, os testes pegarão);

• Refatorações;

• Segurança para mudanças externas;

• Mudanças de infra-estrutura;

• Mudanças nas configurações de arcabouços;

• Escrever testes automatizados aumenta a vida útil do software.

1 Obs.: Nem todos estes benefícios podem ser provado. São listados aqui a partir da experiência de

desenvolvedores defensores dos testes automatizados.

3.2 Testes Unitários

Testes unitários são testes em que são testadas unidades individuais de código-fonte

(WIKIPEDIA CONTRIBUTORS, 2009). Em Java, a principal unidade de código-fonte é a classe, portanto

cada teste unitário em Java testa as funcionalidades de uma única classe.

Existem vários arcabouços disponíveis para fazer testes unitários em Java. Os mais conhecidos

são o JUnit e o TestNG (TESTNG COMMUNITY, 2009). Iremos usar o JUnit na versão 4.x.

A melhor forma de entender o que são testes unitários é vendo um exemplo. Apresentarei aqui

um exemplo que é uma variação do exemplo disponível no Livro de Receitas do Junit (JUNIT

COMMUNITY, 2009):

1. @Test

2. public void simpleAdd() {3. Moeda m12BRL = new Moeda(12, "BRL");4. Moeda m14BRL = new Moeda(14, "BRL");5. Moeda esperado = new Moeda(26, "BRL");6. Moeda resultado = m12BRL.add(m14BRL);7. assertTrue(esperado.equals(resultado));8. }

O método acima é um método de teste que testa o construtor e o método add da classe

Moeda. Na linha 1 colocamos a anotação @Test para indicar que este é um método de teste do JUnit. Na

linha 2 definimos a assinatura do método. Nas linhas 3 e 4 criamos dois objetos da classe moeda. O primeiro

objeto representa 12 reais (“BRL” representa “Brazilian Real”, ou seja, “Real Brasileiro”, a moeda do brasil).

O segundo, 14 reais. O objeto esperado (linha 5) representa 26 reais. O objeto resultado é o resultado da

adição de m14BRL a m12BRL, portanto deverá ser 26 reais se a implementação do método add estiver

correta. A chamada a assertTrue na linha 7 verifica isso: ao executar esta classe com o JUnit, se esperado

for igual a resultado, aparecerá a luz verde. Se não for, aparecerá a luz vermelha.

Em que classe deve ficar este teste? Eu sugiro que seja colocado numa classe chamada

MoedaTeste, que ficará numa pasta de código-fonte do projeto chamada tests. A pasta de código-fonte

principal do projeto deve ser chamada de src. Deste modo isolamos o código de teste (que não precisa ser

utilizado para gerar a versão final para o cliente) do código de produção.

Para que este teste seja corretamente compilado são necessários dois imports:

import static org.junit.Assert.assertTrue;

import org.junit.Test;

O primeiro é utilizado para que se possa utilizar o método assertTrue. O segundo, para a

anotação @Test. Para que estes imports possam ser feitos, a biblioteca junit.jar deve estar entre as bibliotecas

do projeto.

O JUnit versão 4.x dispõe de vários outros recursos para a criação de testes unitários, dentre os

quais destacamos:

• Anotação @Before: usada para declarar um método que será executado antes da execução de cada

método de teste. Por exemplo, pode ser usada para criar uma coleção de objetos que são usados por

vários métodos de teste;

• Anotação @After: usada para declarar um método que será executado depois da execução de cada

método de teste;

• Anotações @BeforeClass e @AfterClass: usadas para declarar métodos que serão executados

apenas uma vez antes/depois da execução de todos os métodos de teste;

• Anotação @Ignore: usada para (temporariamente) excluir um teste do conjunto de testes que serão

executados;

• Diversos métodos do tipo assert*, como assertEquals, assertNull, assertSame (ver

http://junit.org/apidocs/org/junit/Assert.html);

• Parâmetro expected: provê uma forma de testar o lançamento de exceções

(expected=AnException.class), onde AnException é o nome da classe da exceção que se espera ser

lançada durante a execução do teste;

• Parâmetro timeout: permite definir um período de tempo (em milissegundos) após o qual o teste falha

se o método de teste não finalizar o seu processamento.

3.3 O Processo de Desenvolvimento Dirigido por Testes

Nas metologias tradicionais, os testes são feitos após a implementação. O objetivo do DDT é

que os testes sejam escritos antes da implementação da funcionalidade para que o projeto das classes que

estão sendo testadas seja feito durante a escrita dos testes.

O processo de utilização do DDT (que é repetido a cada implementação de funcionalidade)

pode ser visto como um processo circular (veja Figura 1):

1. Escreva um teste;

2. Execute todos os testes e acontecerá uma falha;

3. Escreva o código para passar no teste que foi escrito no passo 1;

4. Execute os testes e veja todos os testes passarem (se o código escrito no passo 4 estiver correto);

5. Refatore o código escrito no passo 4.

Figura 1. Uma representação gráfica do ciclo de desenvolvimento sugerido pelo DDT usando fluxogramas.

Fonte: (WIKIPEDIA CONTRIBUTORS, 2009b)

Este processo pressupõe que se esteja escrevendo testes automatizados, isto é, que os testes

possam ser escritos como um programa.

Portanto, no passo 1 é escrito algum teste (um trecho de programa) que verifica alguma

funcionalidade desejada para o sistema (que também será representado como um programa). Um teste (ou

um “caso de teste”), contém em geral uma ou mais entradas e uma ou mais saídas esperadas. Por exemplo,

para testar um sistema que faz cálculos aritméticos básicos (supondo que eles não sejam oferecidos pela

linguagem), podemos escrever um caso de teste que testa a operação de adição (+) dizendo que se

oferecermos 2 e 2 como entrada a saída esperada é 4.

No passo 2 executam-se todos os testes. Aqui supõe-se que já exista um conjunto de testes

para o sistema. Se no passo 1 foi escrito o primeiro teste, este conjunto conterá apenas um teste. Neste

momento, é esperado que o conjunto de testes falhe, pois provavelmente a funcionalidade que será verificada

pelo último teste escrito ainda não foi implementada (está é a ideia do DDT).

No passo 3 escreve-se o código de produção para passar no teste escrito no passo 1. Usamos o

termo “código de produção” para diferenciar do código de teste pois, afinal de contas ambos são código.

Continuando o exemplo do passo 1, aqui implementaríamos o código do método que faz a adição de dois

números.

No passo 4 executam-se novamente todos os testes. Neste momento, é esperado que todos os

testes passem. Caso isso não aconteça, volta-se ao passo 3 para corrigir o código de produção.

Após passar em todos os testes, no passo 5 o código de produção é refatorado, isto é, é

reescrito para que fique mais limpo, mais bonito, mais fácil de entender (ver mais sobre refatoração na seção

5). Se forem feitas mudanças no código de produção que exijam alterações no testes escritos no passo 1,

volta-se ao passo 1. Caso contrário, executam-se novamente todos os testes. Se todos passarem, volta-se ao

passo 1 para criar um novo caso de teste. Se algum teste falhar, vai-se ao passo 3 para corrigir o que deu

errado.

3.4 Testes de Aceitação

Testes de aceitação são testes do tipo caixa-preta, que testam as funcionalidades do sistema

sem conhecer o projeto do sistema. Eles podem verificar a correção do sistema como um todo ou apenas de

uma parte dele (por exemplo, de uma estória). DDT e Testes Automatizados também podem ser utilizados

para fazer testes de aceitação (JAIN, 2008).

Existem arcabouços específicos para automatizar testes de aceitação (por exemplo, o Selenium

(SELENIUM COMMUNITY 2009)), mas em alguns casos simples os arcabouços para testes unitários

podem ser usados para fazer testes de aceitação. Neste caso, basta implementar classes de testes que

instanciem objetos de diferentes classes e que sigam roteiros de interação entre as classes.

4. Programação Pareada

Programação Pareada é a técnica em que dois desenvolvedores desenvolvem conjuntamente e

simultaneamente uma solução para uma tarefa.

A ideia inicial é que dois programadores dividam a mesma máquina para implementar uma

mesma funcionalidade. Um fica de posse do teclado e o outro fica ao lado dando sugestões e apontando

erros.

Antes vamos dar nomes aos bois, digo, aos papéis (WILLIAMS, Laurie APUD NETO, 2009):

• Chamaremos o programador que está controlando o teclado de “piloto” (ou “motorista”);

• E o programador que está observando o trabalho do motorista, identificando problemas, fazendo

perguntas e sugestões é chamado de “co-piloto” (ou “navegador”).

Um (o piloto) controla o teclado e o mouse. O outro (o co-piloto) observa criticamente. Os

dois estão continuamente dialogando. De tempos em tempos, ao longo de uma sessão de implementação, o

controle muda de mãos. E, ao longo de um projeto, os companheiros são trocados de pares.

Vale a pena? Aparentemente não... A empresa usa dois “recursos” em vez de um. Isto é, tem

que pagar o salário de dois desenvolvedores para trabalhar num mesmo problema? Os dois usam o mesmo

computador a maior parte do tempo (o computador do outro programador fica ocioso).

Mas diversas pesquisas (WILLIAMS & KESSLER, 2003), mostraram que a programação

pareada aumenta a qualidade do software. Além disso, as tarefas são completadas em menos tempo (mas não

necessariamente em menos da metade do tempo que um programador sozinho gasta). E tão importante

quanto a programação pareada são a análise pareada e o projeto (design) pareado.

Além disso, o trabalho do programador/desenvolvedor fica menos chato, menos solitário, mais

social. À medida que os pares se acostumam a trabalhar em pares, a produtividade aumenta. A

retroalimentação, o debate e a troca de idéias entre os parceiros diminuem significativamente a probabilidade

de se continuar com um mau design. A presença do outro força cada programador a concentrar-se totalmente

no problema em questão. Cada parceiro ajuda o outro a manter a disciplina de escrever testes primeiro. E

funciona como um treinamento cruzado: um programador ensina o outro.

Quando fica difícil fazer programação pareada? Por exemplo, quando o desenvolvimento é

distribuído e os membros da equipe estão em lugares diferentes. Porém, mesmo neste caso, tendo uma

conexão rápida de internet é possível fazer programação pareada. Basta usar algum sistema que permite a

edição do código de forma simultânea e usar alguma forma de comunicação instantânea (MSN, Google

Talk). Outra dificuldade acontece quando a cultura do país dificulta a proximidade dos programadores. Mas

isto com certeza não se aplica aos brasileiros...

Terminamos esta seção com as palavras de Obie Fernandez, um famoso desenvolvedor,

escritor e blogueiro, proferidas em sua palestra no Rails Summit Latin America 2008: a principal vantagem

da programação pareada é que “quando se está trabalhando em par se trabalha o dia todo. Pois ao trabalhar

sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim

de um dia de programação em par você está cansado, pois você realmente pensou e trabalhou o dia todo. Mas

você fica contente, pois sabe que teve o trabalho realizado”. (FERNANDEZ, Obie APUD MERGULHÃO,

2008).

5. Refatoração

Refatoração é basicamente reescrever código que já está funcionando. Ou seja, temos uma

classe ou método que já faz o que deveria fazer. Mas alguma coisa (que não afeta o resultado da

implementação) não está muito boa. Pode ser algum problema na implementação do método ou na

distribuição de funcionalidade entre as classes. Exemplos de problemas são: classe está muito grande, o

método é muito longo, etc.

Em outras palavras, “refatorar é melhorar o código sem alterar sua funcionalidade. Antes de

fazer uma mudança, você refatora o código para que a mudança seja simples de fazer. Refatoração contínua

possibilita manter um design legal, mesmo com mudanças frequentes.” (CIRNE, Walfredo APUD NETO,

2008).

Os Ambientes Integrados de Desenvolvimento para Java mais utilizados (por exemplo, Eclipse

e Netbeans) dispõem de funcionalidades para facilitar os casos mais comuns de refatoração. É possível, por

exemplo, renomear classes, renomear métodos, incluir/excluir parâmetros em/de métodos, etc. São muitas as

refatorações possíveis.

Um bom catálogo de refatorações possíveis está disponível no livro Refatoração, de Martin

Fowler (FOWLER, 2004). Este livro contém dezenas de “receitas de refatoração”. Alguns exemplos são:

• Extrair Método;

• Mover Método;

• Mover Atributo;

• Extrair Classe.

Extrair Método, por exemplo, transforma uma sequência de comandos num método. Mais

informações sobre as refatorações possíveis podem ser encontradas em (FOWLER, 2009), na seção Catalog.

6. Considerações Finais

Os métodos ágeis estão em constante transformação. Muito do que está escrito aqui poderá

estar desatualizado em questão de meses. Portanto, a minha sugestão é que você se mantenha atualizado

acessando as principais páginas disponíveis sobre métodos ágeis e participando de cursos/eventos ágeis.

Procuro manter alguns links para sites interessantes sobre métodos ágeis na página:

• http://adolfoneto.wikidot.com/metodologias-ageis

Particularmente úteis são os sites da Agilcoop e da InfoQ. Os artigos da Wikipedia (em inglês)

sobre métodos ágeis e temas relacionados em geral são muito bons.

Além disso, estou no Twitter em:

• http://twitter.com/adolfont

onde procuro divulgar eventos, cursos, artigos e posts interessantes sobre métodos ágeis.

Alguns dos twiteiros ágeis que sigo estão na minha lista em:

• http://twitter.com/adolfont/agil

Por fim, eventualmente no meu blog:

• http://professoradolfo.blogspot.com/

publico ou republico artigos sobre métodos ágeis.

Referências

BEEDLE, Mike et al. Agile Manifesto. 2001. Disponível em: <http://agilemanifesto.org/>. Acesso em: 07.

out. 2009.

CHEQUE, Paulo. Introdução a Testes Automatizados. Curso de Verão 2008 - IME/USP. Disponível em:

<http://ccsl.ime.usp.br/agilcoop/files/AgilCoop-Verao08-Testes.pdf>. Acesso em: 07 out. 2009.

FOWLER, Martin. Refatoração: Aperfeiçoando o Projeto de Código Existente. Porto Alegre: Editora

Bookman, 2004. Links: http://bit.ly/32kaxh (página do livro no site da Editora) e http://bit.ly/OI8ok (página

do livro na Livraria Cultura).

FOWLER, 2009. Refactoring site. Disponível em: <http://www.refactoring.com>. Acesso em: 18 nov.

2009.

JAIN, Naresh. Acceptance Test Driven Development. Disponível em:

<http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264>. Acesso em: 18 nov.

2009.

JUNIT COMMUNITY. JUnit. Disponível em: <http://junit.org/>. Acesso em: 18 nov. 2009.

MERGULHÃO, Sylvestre. Rails Summit dia 16: Obie Fernandez. 16 de outubro de 2008. Disponível em:

<http://bit.ly/4qkbOH>. Acesso em: 18 nov. 2009.

NETO, Adolfo. Metodologias Ágeis para o Desenvolvimento de Software. Disponível em:

<http://bit.ly/3WUFfp>. 2008. Acesso em: 18 nov. 2009.

NETO, Adolfo. Programação Pareada. Disponível em: <http://adolfoneto.wikidot.com/programacao-

pareada>. Acesso em: 18 nov. 2009.

SELENIUM COMMUNITY. Selenium. Disponível em: <http://seleniumhq.org>. Acesso em: 18 Nov. 2009.

TESTNG COMMUNITY. TestNG. Disponível em: <http://testng.org>. Acesso em: 18 Nov. 2009.

WIKIPEDIA CONTRIBUTORS. Unit testing. Wikipedia - The Free Encyclopedia. Disponível em:

<http://en.wikipedia.org/w/index.php?title=Unit_testing&oldid=325780704>. Acesso em: Nov. 16, 2009. (a)

WIKIPEDIA CONTRIBUTORS. Test-driven development. Wikipedia - The Free Encyclopedia.

Disponível em: <http://en.wikipedia.org/wiki/Test-driven_development>. Acesso em: Nov. 16, 2009. (b)

WILLIAMS, Laurie; KESSLER, Robert. Pair Programming Illuminated. Addison Wesley, 2003.

Outros materiais utilizados

BECK, Kent; SAVOIA, Alberto. JUnit 4 and Java SE 5: Better Testing by Design. 2006. Disponível em:

<http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1580&yr=2006&track=tools>.

Acesso em: 07. out. 2009.

DEMARCO, Tom. Software Engineering: an idea whose time has come and gone? IEEE Software, p.95-96,

July/August 2009. Disponível em:<http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2009.101>.

Acesso em: 07 out. 2009.

RUSTAM. Thoughts on Extreme Programming. Disponível em: <http://code.az/article/xp>. Acesso em:

18 nov. 2009.

SATO, Danilo; BRAVO, Mariana. Introdução a Métodos Ágeis. Curso de Verão 2008 - IME/USP.

Disponível em: <http://ccsl.ime.usp.br/agilcoop/files/AgilCoop-Verao08-Introducao.pdf>. Acesso em: 07.

out. 2009.

TELES, Vinícius Manhães. Extreme programming: aprenda como encantar seus usuários desenvolvendo

software com agilidade e alta qualidade. São Paulo: Novatec, 2004. 316 p. ISBN 85-7522-047-0.