Segue a divulgação de um evento bacana em Gravataí-RS. Se trata de um evento beneficiente, então quem estiver na área j[a tem mais um bom motivo para comparecer…

Olá Pessoal,

Em janeiro, o Curso de Sistemas de Informação da FACENSA (Gravataí), juntamente com o Grupo de Usuários de Metodologias Ágeis (GUMA-RS) estará promovendo uma palestra beneficente sobre Metodologias Ágeis de Software. O assunto trata de um conjunto de metodologias de desenvolvimento de software que trabalham baseadas em um conjunto de princípios e valores, e baseadas em foco no cliente, na equipe e geração de resultados com métricas e atitudes que promovem a melhoria contínua.

Esta palestra vai trazer aos participantes uma introdução ao assunto, permitindo o debate e discussão dos tópicos tratados.

Data: 06 de janeiro de 2009, às 19h30min. A palestra tem duração de 3 horas.

Para esta ação, o Curso de Sistemas de Informação/FACENSA está arrecadando alimentos não perecíveis. A inscrição para a palestra é feita a partir da doação de 2Kg de alimentos. Os alimentos arrecadados serão doados para o Asilo Santa Bárbara (Gravataí).

Mais informações no blog do grupo XP – Rio Grande do SUL.

Saudações!
Já que o WordPress não nos dá a possibilidade de colocar enquetes no site, colocamos no site A Maldita Comédia mesmo!!!

Eu e o Ivan queremos melhorar o conteúdo do site, e com o número grande de pessoas que acessam aceitamos o desafio de perguntar a todos: O que temos que melhorar?!

Votem! Conto com a sinceridade e a compreensão de todos que queremos realmente gerar conteúdo de qualidade!

Obrigado!

Saudações!
Conversando com Ivan, resolvemos criar um post que agregasse o máximo possível de informações úteis sobre TDD, para que possamos avançar nos encontros do CodingDojoFloripa, efetivamente evitando o que houve no último encontro. Assim, compilei uma série de links que tratam do assunto, basicamente escritos aqui no DojoFloripa, com algumas referências externas, também bastante úteis.

Nossa idéia, a partir de agora, é fornecer informações para que no próximo dojo, não precisemos iniciar toda a conversa sobre tdd novamente, garantindo a evolução contínua da complexidade dos encontros. Portanto, aproveitem!! =)

O que é TDD?

• Wikipedia (inglês)
• Scott Ambler(inglês)
• Introdução ao TDD: fazer os testes passarem deve ser a única preocupação agora (português)
• Confusões sobre TDD (português)

Miscelânia:

• Abrace as mudanças em seu software (português)
• Top 5 desculpas para não programar orientado a testes (português)
• TDD vs UML (português)

Videos:

• Tipos de Teste: palestra AgilCoop (português)
• Agile Testing (português/inglês)

TDD na prática:

• Screencast: TDD em Ação (português)
• TDD parte 1: por onde começar (portugês)
• TDD parte 2: Baby Steps e Tratamento de Exceções: (português)
• TDD parte 3: Corrigindo bugs (português)
• CppUnit e Borland C++ Builder6: (português)

Técnicas:

• Fake it (português)
• Trabalhando com stubs: (português)
• Mocks & Stubs, qual a diferença afinal? (português)
• TDD Anti-Patterns (português)

Livros:

• Test Driven Development: A pratical Guide 
•  Refactoring: Improving the design of existingcode
• Test Driven Development by Example 
• Automação e Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções OpenSource e Grauitas (ebook)

Tentaremos manter esse post sempre atualizado e acessível para que todos possam desgrutar do conteúdo. Se você possui alguma referência, entre em contato!

Como praticante de eXtreme Programming desde 2003, não me considero nenhum pioneiro do assunto no Brasil. Antes disso eu já acompanhava o xispe.com.br e via que já existia gente usando XP na prática, coisa que ainda demorei mais de um ano para conseguir.

O interessante mesmo é ver como de lá pra cá muita gente abraçou XP. E se fosse para fazer uma retrospectiva do que eu notei de lá pra cá, eu chamaria atenção que:

• O aumento da comunidade pode significar tanto que XP funciona quanto que as pessoas estão frustradas com seus projetos de software atuais. E eu acredito nas duas opções.
• Muita gente está buscando adaptar XP a processos engessados, ao invés de simplesmente abraçar seus princípios.
• XP abriu as portas para uma série de outras iniciativas ágeis. Scrum é a principal delas.
• O Brasil continua atrasado no que diz respeito a desenvolvimento de software em geral.

Em resumo, me parece que aos poucos a mentalidade dos profissionais de software está mudando e um futuro mais Ágil é inevitável. Que XP seja mesmo só o começo…

Finalmente, depois de algumas semanas, consegui me encontrar com o Eduardo Fiorezi no Skype para gravarmos um podcast sobre Scrum, XP, TDD, Coding Dojo etc. E mal o podcast foi publicado e já está rolando uma discussão interessante com o Vinícius Teles sobre a relação entre XP e Scrum.

Confira o post sobre o podcast ou baixe-o diretamente aqui.

Mais uma vez quero agradecer o Eduardo pelo convite, e espero participar de outros podcasts em breve

Conforme prometido, aqui está o screencast de um exemplo real de TDD. O vídeo tem aproximadamente 14 minutos (expremidos heroicamente em menos de 8MB), e trata um pouco dos seguintes assuntos:

• Organização dos testes no eclipse
• O fluxo de trabalho do TDD (vermelho-verde)
• Desenvolvimento incremental (baby steps)
• Implementar a solução mais simples que funcione (Fake It)
• Como refatorar com maior segurança graças aos testes
• Criação de testes para tratamento de exceções

Tentei usar um exercício extremamente simples para poder me focar mais na maneira de se raciocinar usando TDD. Como este é meu primeiro screencast acredito que ele está longe da perfeição (o áudio teve que ser substituído por legendas, por exemplo), mas espero que seja útil mesmo assim

Assista o screencast TDD em Ação

RCT, ou Relação Código-Teste (Code To Test Ratio) é uma métrica extremamente simples, que permite verificar como andam os testes durante o projeto:

RCT = Linhas de Teste / Linhas de Código

Normalmente o valor obtido varia entre 0, quando não existe nenhum teste, e 1,5, quando se escreve 50% de linhas de teste a mais do que linhas de código. Até hoje não vi muitos projetos passarem deste valor, mas já é bastante normal ver projetos nesta faixa. Veja alguns exemplos no Code to Test Ratio Showdown.

O interessante desta métrica é que ela pode servir para acompanhar a adoção de TDD e verificar se os testes não estão sendo deixados de lado. Por isso ela deve ser coletada periodicamente, e deve-se buscar um valor que varie muito pouco quando a utilização de testes estiver satisfatória.

Atualmente estou trabalhando num projeto onde a RCT é 1.3. Em projetos Ruby on Rails a RCT é facimente obtido via rake stats:

Code LOC: 549 Test LOC: 690 Code to Test Ratio: 1:1.3

O projeto ainda está no começo (pouco mais de 500 linhas de código), mas o meu objetivo é que minha RCT nunca baixe de 1.3, e se possível alcance 1.4 quando eu passar a fazer mais testes de integração

E no seu projeto, quantas linhas de teste você gera para cada linha de código? Se você obter a RCT do seu projeto, divulgue-a nos comentários!

Visão geral do Desenvolvimento Orientado a Testes:

Para extrair o máximo dos testes durante o desenvolvimento, devemos pensar neles como uma ferramenta de comunicação e aprendizado contínuo. Portanto seu foco deve ir além da verificação e pautar o desenvolvimento como um todo.

Objetivo:

Ajudar o desenvolvimento e aumentar a confiança para fazer qualquer modificação no sistema.

Participantes:

• Cliente
• Equipe de Desenvolvimento

Pontos principais:

• Todos os testes devem ser automatizados.
• Os testes são escritos antes mesmo da funcionalidade existir
• Uma User Story está pronta quando todos os Testes de Aceitação passam e não se consegue imaginar mais testes para ela
• O desenvolvimento é feito em pequenos incrementos (“baby steps”)
• O projeto da implementação deve favorecer a confecção de testes
• O Cliente escreve testes de aceitação com ajuda da Equipe de Desenvolvimento. Se isso não é possível é interessante que ele ao menos valide o testes que a Equipe de Desenvolvimento criar
• A depuração de código deve ser substituída por testes sempre que possível
• Busca-se que todos os testes passem sempre. Se algo não está funcionando isto deve ser do conhecimento do Cliente.
• Um novo teste deve ser escrito quando for preciso reproduzir um erro ou esclarecer melhor uma funcionalidade.

Resultados esperados:

• O cliente terá maior confiança que as User Stories que ele definiu estão implementadas
• A equipe terá maior confiança para fazer as mudanças que o cliente pedirá no futuro
• Existirá sempre uma especificação atualizada, representada pelos testes
• O design do software será favorecido pela simplicidade
• A ocorrência de erros diminuirá

Atualização:
(11/05/2007) Novos itens foram adicionados nos Resultados Esperados (agradecimentos ao ViniciusAC)

Visão Geral do Jogo do Planejamento:

É preciso conhecer o problema, levantar os requisitos, estimar o esforço e definir as entregas. A colaboração tanto da Equipe de Desenvolvimento quanto do Cliente é fundamental nesta etapa que será o ponto de partida para um novo ciclo de desenvolvimento.

Objetivo:

Definir os requisitos (User Stories) de maior valor, que deverão ser entregues no final da Iteração ou Release.

Participantes:

• Cliente
• Equipe de Desenvolvimento
• Coach

Pontos principais:

• Um objetivo concreto deve ser definido para a próxima Iteração/Release
• A próxima Iteração/Release deve compreender o que há de mais valioso para o Cliente
• Os requisitos devem ser representados em User Stories utilizando a linguagem do Cliente
• O Cliente deve ter a chance de adicionar ou remover User Stories
• As User Stories devem ser compreendidas pela Equipe de Deenvolvimento
• A Equipe de Desenvolvimento pode quebrar ou unir User Stories com ajuda do Cliente
• Um Glossário pode ser mantido para guardar o significado dos termos mais relevantes
• No Planejamento da Iteração é desejável que as User Stories sejam quebradas em Tarefas técnicas pela Equipe de Desenvolvimento
• O Cliente deve priorizar as User Stories
• A Equipe de Desenvolvimento deve estimar cada User Story/Tarefa
• Equipe de Desenvolvimento e Cliente discutem o que pode ser implementado na próxima Iteração/Release
• A velocidade da equipe deve ser atualizada com base na última Iteração/Release:
  • Velocidade = (Total de Pontos) / Iteração ou Release

Resultados esperados:

• O Cliente estará comprometido a disponibilizar mais informações sempre que necessário
• O Cliente estará comprometido a dar seu feedback durante o desenvolvimento
• A Equipe de Desenvolvimento estará comprometida a entregar o que há de mais valor para o Cliente ao final da Iteração/Release
• A velocidade da Equipe de Desenvolvimento será conhecida

Pretendo começar uma série de posts inspirados no Scrums Checklists, um minibook que resume as principais práticas de Scrum em poucas páginas, numa mistura de TO-DO List, Perguntas Frequentes e Guia de Consulta Rápida. O objetivo não é servir como fonte de aprendizado inicial, mas sim ajudar as pessoas no dia-a-dia de seus projetos.

A intenção é seguir o mesmo formato só que desta vez tratando de eXtreme Programming. Estas checklists serão voltadas para os principais papéis de quem trabalha com XP:

• Desenvolvedores: aqueles que constroem o software (programadores, analistas, testadores, documentadores etc);
• Clientes: aqueles que definem os requisitos (não necessariamente aqueles que estão pagando);
• Coaches: aquele que trabalham para manter XP funcionando 100% o tempo todo.

Em cada checklist pretendo abrir o espaço dos comentários para incluir novas informações ou dúvidas. Na versão em papel dos minibooks também existe um espaço para anotações e convenções definidas pela equipe, mas por enquanto não imagino como incluir algo do gênero na versão deste blog.

Quem puder colaborar com experiências, materiais, críticas, sugestões ou dúvidas será muito bem-vindo.

Update: Confira as checklists disponíveis:

1. Jogo do Planejamento
2. Desenvolvimento Orientado a Testes