Archive for October, 2008

Falando em Agile

October 27, 2008

Tenho certeza que terão muitos posts falando sobre o evento “Falando em Agile 2008”, porém não poderia deixar de expressar minha impressão sobre as palestras que achei mais interessantes.

Para quem se interessar, o objetivo principal de cada palestra pode ser encontrado aqui, logo, focarei mais na minha impressão e opinião pessoal de cada apresentação.

Começando pelo principal. Foi o melhor Coffe Break de todos todos os eventos da Caelum que já participei. =D

No primeiro dia o Danilo Sato e o Francisco Trindade falaram sobre “Agilidade de tartaruga. Métodos ágeis encontram o mundo real”. Eles focaram bastante na idéia de evolução contínua de um processo ágil e como “seguir a receita dos livros” (agile by the book) pode engessar o processo e acabar deixando de lado algo fundamental para um time ágil: a adaptação e melhoria constante do processo. A palestra foi muito interessante pois eles apresentaram exemplos reais de projetos em que participaram e de como o feedback e adaptação ajudam a “moldar” um processo ágil para a realidade daquele cliente ou daquele projeto especificamente. Mas fico um pouco preocupado com interpretações erradas. Imaginem o camarada que está começando a utilizar práticas ágeis e que ainda não conseguiu adaptar-se, por exemplo, à prática de TDD. Ao descobrir que pode adaptar o processo ele logo pensa: “Ahá, sabia que não precisava desse negócio de testar antes de escrever código”. Pronto, acontecerá exatamente o que o Phillip mostrou em sua palestra (continue lendo). Obviamente que não foi isso que o Danilo e o Francisco passaram, mas, sabemos até onde vai a criatividade humana. Alias, segundo o Pedro, a preguiça é o maior motivador para a criatividade humana. Preguiça, escrever testes, gerente que diz “se não tiver tempo não precisa testar” … Sugestivo né! Então fica o alertar: Para adaptar um processo (ágil ou não), primeiro você precisa experimentá-lo, conhecê-lo muito bem e saber exatamente quais as consequencias da exclusão de uma prática.

O destaque do dia foi a palestra do pessoal de Brasilia, da SEA tecnologia. Foi uma palestra muito divertida onde o pessoal mostrou a dificuldade que enfrentaram para introduzir métodos ágeis na Força Aérea Brasileira, um orgão militar bastante consevador, burocrático e cheio de regras e procedimentos rígidos. A todo momento o oficial militar responsável pelo projeto, que participou da aparesentação, contava momentos em que pensou “pronto agora eu vou em cana”. O relato mais curioso foi com relação aos post-its no quadro. Como o Coronel (não me lembro se era esta a patente correta) “não gostava de desorganização” a saída do pessoal foi colar os post-its em folhas A4 e estas no quadro. Guando o Coronel chegava, todos corriam para arrancar as folhas e escontê-las na gaveta. Que situação!

A ultima palestra do dia foi a do Guilherme Chapiewsky da globo.com, com o tema “Liderando equipes agéis”. A palestra do Guilherme foi incrível. Ele conseguiu deixar muito claro como ele lidera e como é a relação entre o lider e a sua equipe. Eu acompanho os blogs do pessoal da globo.com a algum tempo e é nítida, mesmo pra quem está de fora, a mudança de comportamento que o Scrum trouxe para organização. Das 12 palestras realizadas nesses dois dias, 4 foram do (ex-)pessoal da globo.com, e todos mostraram-se muito satisfeitos com a introdução de práticas ágeis. É muito legal vermos o surgimento de lideres jovens como o Guilherme, que não conduzem uma equipe de forma imperativa, “chefeando” mas sim guiando, ajudando e principalmente fazendo parte da equipe, porque geralmente, as equipes não enchergam o gerente como um membro e sim como chefe (Uga-uga!).

O segundo dia teve início com o KeyNote do Alexendre Magno sobre “Scrum em ambientes PMBok”. O Alexandre dispensa apresentações/comentários e como sempre sua palestra foi muito boa. O legal dessa apresentação foi ver como os gerentes de projeto tradicionais destorcem muito as práticas do PMBok, interpretando-as como convêm. O próprio PMBok fala sobre coisas como Rolling-Wave Planning e Progressive Elaboration, que se parecem muito com o nosso desenvolvimento iterativo. Alguém aí já viu algum PMP falando sobre essas coisas? Veja no link dos mesmos para a Wikipedia a importancia que se dá a essas coisas.

Continuando com o case da globo.com, o Danilo Bardusco contou um pouco de como aconteceu o primeiro projeto onde eles utilizaram efetivamente práticas ágeis. Precisavam colocar no ar em 40 dias uma aplicação para o BBB. Todos, inclusive o próprio Danilo, acreditavam que não conseguiriam cumprir esse prazo desenvolvendo software da forma como estavam acostumados a fazer. Quando propôs o uso de Scrum, os próprios membros da equipe, como de costume, continuaram duvidando que seria possível. A solução foi propor uma experiência de 3 dias e, caso não ouvesse evolução, desistiriam do projeto. O resultado foi a adoção de Scrum em todas as equipes da globo.com.

Outra apresentação que merece destaque foi a do Antônio Carlos, do Yahoo. Sua palestra foi um pouco mais específica, focando no papel do Product Owner. Muitas das palestras do evento foram em cima de relatos sobre a experiência na adoção de metodologias ágeis nas empresas. Foi realmente muito legal ouvir essas experiências, uma perspectiva bem diferente e mais prática do que lemos nos livros. Porem uma das coisas que senti falta no evento foram palestras com temas mais técnicos, específicos e práticos, por isso a palestra do Antônio foi diferenciada. Seria bom se tivessemos um evento em formato de Workshops, com simulação de casos reais e trabalhos em grupo.

Por último tivemos a palestra do Phillip Calçado (Shoes). Uma palestra bastante esperada pela maioria e que não deixou a desejar. Apesar do tema parece bem polêmico, “A maldição da fábrica de software ágil”, a apresentação foi bem amena. Depois de alguns minutos ofegantes, após a corrida atras do notebook, o Phillip apresentou dois exemplos de projetos em que teve a oportunidade de participar pela Thoughtworks Austrália e quais foram os problemas que encontraram. Conta Shoes que em um desses projetos, após obterem sucesso em uma parte do projeto, o gerente do projeto resolveu colocar mais pessoas e paralelizar as tarefas. “Nine women can’t make a baby in one month” já dizia Fred Brooks. A conclusão do Phillip, e aí entra o comentário que fiz sobre o tema do Danilo e do Francisco, é que com tantas pessoas no time perdeu-se na comunicação. A comunicação é um dos pilares do desenvolvimento ágil e, com a falta ou deficiência da mesma, torna-se necessária uma documentação formal mais pesada, já que de alguma forma as informações têem de ser transmitidas entre os membros da equipe. Ao tentar transformar o time em uma especie de fábrica, o gerente de projetos não percebeu que estava abrindo mão da comunicação, e isso colocou em xeque o sucesso de um time ágil.

Como em todo bom evento, ao final de cada dia fomos “tomar uma”. Esse é um momento muito interessante, pois temos oportunidade de conhecer pessoalmente várias pessoas que encontramos diariamente nos blogs e foruns. Entre Coffe Breaks e cervejas após o evento tive a oportunidade de conhecer pessoas como o Luiz Aguiar, Luca, Rodrigo Yoshima, Pedro (do Yahoo), Daniel Destro, diversos dos palestrantes e muitas outras pessoas que nem tivemos tempo de perguntar o nome uma das outras.

Quem não pode ir desta fez, não perca os próximos. Sem dúvida são essas coisas que ajudarão a formar seu conhecimento e opinião profissional.

assertEquals para BigDecimal

October 22, 2008

Quando, desenvolvendo software, nos deparamos com alguma situação um tanto quanto bizarra, qual a primeira coisa a se fazer?
Sair correndo para perguntar naquele forum bacana certo? É uma alternativa.
Acho os foruns fantásticos, frequento bastante. São sem dúvida uma ótima fonte de estudo. Porém uma outra solução um pouco mais difícil, demorada, porém menos preguiçosa mais … digamos … nobre, seria perder alguns poucos minutos realizando uma pesquisa.

Hoje, desenvolvendo um “Pet Project” me deparei com uma situação dessas.
Veja o seguinte código:

import java.math.BigDecimal;

import org.junit.Test;
import static org.junit.Assert.*;

public class BigDecimalTest {

	private final BigDecimal n1 = new BigDecimal("13.23");
	private final BigDecimal n2 = new BigDecimal("13.27");

	@Test
	public void should_not_be_equals_using_junit_assert_method()
	{
		assertEquals(n1, n2);
	}

	@Test
	public void should_not_be_equals_using_BigDecimal_equals_method()
	{
		assertTrue(n1.equals(n2));
	}
}

Ambos deveriam falhar correto? Mas não foi o que aconteceu.
Inexplicavelmente o primeiro teste passou. Ficou verdinho! Isso mesmo.
Minha primeira idéia foi uma pesquisa rápida no google (ooohhh), mas não encontrei nada. Talvez não tenha procurado direito, é verdade. Achei mais interessante baixar o código fonte do JUnit e eis que encontro o seguinte trecho de código:

static public void assertEquals(Object expected, Object actual) {
	assertEquals(null, expected, actual);

}

static public void assertEquals(String message, Object expected, Object actual) {
	if (expected == null && actual == null)
		return;
	if (expected != null && isEquals(expected, actual))
		return;
	else if (expected instanceof String && actual instanceof String) {
		String cleanMessage= message == null ? "" : message;
		throw new ComparisonFailure(cleanMessage, (String)expected, (String)actual);
	}
	else
	        failNotEquals(message, expected, actual);
}

private static boolean isEquals(Object expected, Object actual) {
	if (expected instanceof Number && actual instanceof Number)
		return ((Number) expected).longValue() == ((Number) actual).longValue();
	return expected.equals(actual);
}

Veja que o metodo assertEquals delega para o método isEquals cujo faz um instanceOf verificando se os objetos sendo comparados são do tipo Number. Caso sejam, o metodo os transforma em long para depois compará-los.
Bingo. Com isso compara-se apenas a parte inteira do número, logo, aquele primeiro teste passou.

Meu próximo passo foi procurar na lista de bugs do JUnit se este já era um velho conhecido.
Para minha não surpresa lá estava o danado.

Esse problema foi encontrado na versão 4.3.1 do JUnit, que vem no eclipse europa, e já foi corrigido, veja o metodo isEqual da versão 4.5

private static boolean isEquals(Object expected, Object actual) {
	return expected.equals(actual);
}

Agora sim …

Por que eu ainda estava usando o eclipse europa?
Eu sei lá. Só sei que, foi bem mais divertido que postar a pergunta e ficar dando F5 no aguardo da resposta.