Archive for the ‘XP’ Category

Maré de Agilidade com Açaí

Friday, November 20th, 2009

Texto produzido pelo grupo Tá Safo!

Para quem ainda não sabe do que se trata , o Maré de Agilidade é um evento itinerante que viaja pelas cidades do Brasil, apresentado assuntos como Extreme Programming (XP), Scrum, Domain Driven Design (DDD), Model Driven Design (MDD), Test-driven Development (TDD), Feature-driven Development (FDD), Gerenciamento Ágil de Projetos (GAP), Lean, e tantos outros. Esses assuntos começam a fazer parte do vocabulário do desenvolvedor de software, no entanto muitas vezes sem a devida capacitação para entendimento e aplicação de tantos conceitos.

Como as ondas de uma maré, o evento já passou por Brasília (setembro/2008 − 1° edição); Salvador (março/2009 − 2° edição) e Fortaleza (agosto/2009 − 3° edição).

Agora em sua 4° edição chegou a vez de Belém, para falar das novas tendências em gerência de projetos e técnicas de desenvolvimento de software que constituem atualmente o grande diferencial de empresas como Apple, Google, Microsoft, Yahoo e Globo.com.

O evento está programado para os dias 26, 27 e 28 de Novembro de 2009, sendo os 2 primeiros dias de mini-cursos, sessões de Dojo e OpenSpace. O 3° dia reservado para palestras e discussões.

Acesse o site do evento: www.maredeagilidade.com.br

Maré de Agilidade - Belém

3º Encontro XPCE - 1º Palestra confirmada

Sunday, September 13th, 2009

Estamos preparando o 3º encontro da comunidade e já confirmamos a primeira palestra com um dos maiores especialistas em testes do Ceará, confiram abaixo:

Palestra: Automação de Testes Funcionais de Software com Selenium

Resumo: Serão discutidos conceitos e fundamentos de automação de testes funcionais e depois será apresentada a ferramenta multiplataforma para automação de testes de sistemas web Selenium. Serão mostradas as características da ferramenta e o passo a passo para sua instalação, gravação e execução de suites de testes. Por fim serão discutidas boas práticas de automação de testes de software e de uso da ferramenta.

Palestrante: Fabrício Dias Alves Lemos

Bacharel em Ciência da Computação pela Universidade Federal do Ceará possui seis anos de experiência em desenvolvimento de software, cinco dos quais aplicando técnicas de automação de testes para sistemas do governo federal e estadual. Atualmente atua como analista de tecnologia da Secretaria da Fazenda do Ceará e mantem o blog http://www.fabriciolemos.org/blog/

Informações sobre o evento:

Título: 3º Encontro XPCE - Comunidade eXtreme Programming do Ceará

Local: Faculdade FA7

Data: 24 de Outubro

Agenda

  1. 08:30 as 09:30 - Palestra em processo de definição
  2. 09:30 as 10:00 - Intervalo
  3. 10:00 as 11:00 - Automação de Testes Funcionais de Software com Selenium - Fabrício Lemos

Hippie Programming

Monday, July 6th, 2009

por Leonardo Eloy

Em 1971, Weinberg dissertou sobre um assunto extremamente relevante para Extreme Programming. No seu tratado The Psychology of Computer Programming, o autor analisou a relação entre um programador e os artefatos que ele produz ao longo de um projeto. Weinberg cunhou o termo Egoless Programing para mostrar que “uma equipe tem responsabilidade coletiva para resolver os problemas com o código”.

Este mesmo conceito serve como uma luva para descrever a Programação em Pares (PP). Sommerville utiliza a pesquisa de Weinberg para justificar uma das principais vantagens de utilizar PP: a idéia de responsabilidade e propriedade comum pelo sistema. Ora, para mim isso só reforça o conceito de foco nos indivíduos e suas interações, ao invés de processos e ferramentas. Porém, esse conceito pode ser distorcido por membros de uma equipe. Imagine aquele programador que é possessivo ao ponto de tomar críticas ao seu código como ofensas pessoais. Não queremos que uma frase como “seu loop foi muito mal colocado” seja interpretada como “você cheira mal”!

Protótipo de programador hippie

Protótipo de programador hippie

Eu gosto de imaginar Weinberg como um programador hippie, muito parecido com o senhor da imagem acima. Em plena década de 1970, o Movimento Hippie mudou a sociedade americana (e por tabela, o resto do mundo). Este movimento foi muito maior que o consumo de drogas e sexo ad hoc, ele popularizou a idéia da diversidade cultural e do respeito ao próximo. Trazendo para o nosso lado, uma das principais desvantagens de fazer PP é pegar aquele cara xiita ou então o indivíduo que adora o modelo Taylorista, que consiste na frase “eu digo, você faz”. Situações assim são péssimas para a produtividade que uma prática de PP poderia trazer ao seu leque de técnicas de engenharia. Quando estamos no controle do teclado ou como observadores e temos que nos relacionar com pessoas assim, como devemos agir? Será que você é assim? O que deveria mudar na sua postura?

É nesse contexto que apresento a Hippie Programming. Apesar de não serem muito afeitos com técnicas de gerenciamento de higiene pessoal, os hippies setentistas são uma fonte infindável de frases e atitudes que muitos de nós poderíamos utilizar no cotidiano. Seguem algumas dicas de como incorporar uma abordagem hippie durante o PP, de acordo com algumas máximas eternizadas durante o movimento:

1. Peace and Love: cabeça aberta. Você provavelmente é xiita ou chato em alguma coisa também! Pare, analise a situação como uma terceira pessoa e faça esta pergunta “eu realmente preciso me impor desta forma?”;

2. Be here now: o foco não é agradar seu colega de PP, sim dar continuidade a uma atividade que envolve programação, porém, por incrível que pareça, pessoas são seres humanos, e todos merecem respeito. Não faça com seu par o que você não gostaria que fosse feito com você. “Esteja aqui agora” é uma advertência para o foco no objetivo, que é cumprir a atividade, mas o respeito pelo seu par deve vir em primeiro lugar;

3. Make love, not war: a tecnologia que você está utilizando é principal meio de atingir os objetivos definidos pela atividade em execução. Os participantes de um PP devem fazer amor com suas tecnologias e ferramentas! Não adianta reclamar que Java não tem ponteiros! :)

4. Drop acid, not bombs: ao encontrar um entrave, procure abstrair o problema antes de tentar algo pela força bruta. Novamente, pare e pense! Caso vocês não consigam encontrar uma solução, parem e discutam sobre o problema, entendam o problema. Antes de pensar na solução você precisa entender a razão pela qual ela está sendo projetada. Essa pode ser a melhor saída, muito melhor do que começar a ler arquivos de log e fazer um “clean & build” no projeto.

E você? Quais são as principais medidas que você acha importante para garantir um bom ambiente ao fazer uma sessão de PP? Deixe sua contribução! :)

Agradeço ao Handerson Frota por revisar e discutir este post comigo.