codificando.com

A Revista Visão Ágil, que sempre apresenta artigos muito interesantes, publicou este mês de outubro a edição número 5 com um artigo meu sobre Os 7 Pecados Capitais de Um time Ágil. O editorial está de parabéns pelo trabalho que fizeram. Realmente a revista ficou ótima.

O Artigo fala um pouco sobre erros comuns de times ágeis. Isso inclui não somente o time, mas P.Os, Scrum Masters e todos os demais envolvidos. Vale a pena conferir.

Os demais artigos também são de excelente qualidade e a leitura dos mesmos é extremamente recomendada.

Meus sinceros agradecimentos ao Manoel Pimentel e Felipe Rogrigues.

Quem não se lembra do comercial da Oi sobre bloqueio de celulares que fez bastante barulho?

O bloqueio as vezes faz parte da vida do Desenvolvedor de Software. Em muitas empresas que trabalhei, tive que conviver com alguns. Foram eles:

• Bloqueio da Internet (Parece mentira, mas trabalhei num lugar onde somente algumas equipes tinham acesso a internet)
• Bloqueio de Instant Message
• Bloqueio de email (Não dava pra acessar o Gmail)
• Bloqueio do Internet Banking
• Bloqueio de alguns sites (Eu não conseguia acessar alguns blogs importantes)
• Bloqueio do Telefone (Não dava nem pra ligar pra casa e em algumas empresas nem telefone na mesa tinha)
• Bloqueio da estação de trabalho (Como que um desenvolvedor que não pode instalar nada no seu computador consegue trabalhar?)
• Bloqueio da Impressora (Tinha senha especial pra imprimir)

Depois de sofrer bastante com esses bloqueios eu me interessei em saber o motivo que leva muitas empresas a trabalhar dessa forma. Apesar do argumento deles ser furado, vou listar o que eu ouvi de diversas pessoas:

• Perda de produtividade (segundo eles, as pessoas perdem muito tempo com coisas inúteis na internet e telefone)
• Falta de foco dos funcionários (Pessoas se desconcentravam facilmente com o IM e outros)
• Desperdício de recursos da empresa. (Gente imprimindo e usando o telefone demasiadamente)

Depois disso, passei a observar o comportamento das pessoas pra ver como cada um se resolvia com essa série de bloqueios. Eis o que percebi:

• A ausência da Internet gerava falta de produtividade, pois os desenvolvedores não conseguiam pesquisar algumas coisas, não tinham forum de discussão e não se mantinham atualizados lendo alguns blogs de tecnologia
• A ausência do Instant Message impedia que um desenvolvedor pedisse ajuda a algum colega que já tenha trabalhado com ele para solucionar um determinado problema.
• A falta do email fazia com que houvessem notebooks com internet móvel espalhados pela empresa para que o pessoal conseguisse ler seus emails.
• A impossibilidade de instalação de softwares na máquina do desenvolvedor fazia com que o mesmo perdesse mais tempo que o necessário para resolver determinados problemas.
• Muitos criaram seu prórpio jeito de burlar isso tudo (Proxys anônimos, senha de admin das máquinas escondido, mais tempo de almoço pra telefonar e imprimir em lan-houses)

E o pior: Essas empresas PERDERAM ÓTIMOS PROFISSIONAIS.

Atualmente eu trabalho numa empresa onde não tem dessas coisas. Aqui nossa internet é totalmente liberada, podemos usar o telefone sem problemas, enviar email a vontade, pagar nossas contas e até mesmo usar o Instant Message (MSN, Yahoo, ICQ, Gtalk), que é considerado por muitos um absurdo.

A conclusão que eu cheguei foi que não importa o que a empresa faça, se o desenvolvedor não quiser trabalhar, ele vai dar um jeito de faze-lo, mesmo que seja burlando as coisas ou simplesmente levando um livrinho e passando o dia lendo na sua mesa.

O que a sua empresa precisa é contratar profissionais de verdade e não pessoas que simplesmente querem um emprego, pois quem quer realmente trabalhar, usa esses recursos a favor da empresa e não contra.

Para aumentar a produtividade e diminuir os custos, recomendo ainda introduzir alguma filosofia de trabalho ágil na sua empresa.

Quem ama não bloqueia !!!

Faz alguns meses que os gujeiros Rodrigo Yoshima e Carlos Villela blogaram sobre o uso errado da tecnologia numa fábrica de pastas de dentes. Para resolver o problema de caixas vazias que passavam desapercebidas numa linha de produção, a empresa comprou uma ultra-mega-power solução que ainda acabou atrapalhando os trabalhadores da fábrica. Mas os próprios trabalhadores se encarregaram de comprar um ventiladorzinho de 20 dólares e dispensar o mega equipamento.

Quem é Brasileiro e principalmente presenciou as corridas de nossos grandes pilotos de Fórmula 1, provavelmente ainda acompanha a categoria, mesmo que exporadicamente. Eu, criado em uma família muito ligada a esportes, com forte inclinação para F1(por que será que meu nome é Emerson? Alguém consegue advinhar? rs), continuo acompanhando os campeonatos, na esperança de que um brasileiro novamente seja campeão mundial.

Eis que no primeiro GP noturno da história da F1 a Ferrari atrapalhou Felipe Massa durante o seu pit-stop com um equipamento ultra moderno que foi desenvolvido para substituir o tradicional pirulito, durante os pit-stops. Esse pirulito foi utilizado por mais de 20 anos e que sempre se mostrou adequado. O novo equipamento fica posicionado em uma altura acima da cabeça do piloto, o que dificulta a visualização em caso de uma nova instrução para parar. O piloto brasileiro perdeu uns 30 segundos pois a mangueira de combustível rompeu-se e sua corrida foi comprometida, inclusive comprometendo a possibilidade de conquiista do campeonato. No pit-stop seguinte, na mesma corrida, a Ferrari voltou a usar o pirulito e no GP seguinte, aposentou de vez a sua engenhoca.

Uma das filosofias que mais gosto para Desenvolvimento de Software nos tempos atuais é KISS. Eu até hoje não sei o motivo de querermos fazer as coisas de forma complicada ao invés de simplificar (eu mesmo já errei muito nisso). Note que simples não significa sem qualidade, mas fazer o suficiente que possa atender a necessidade. As metodologias ágeis da moda como SCRUM / XP falam muito sobre isso. A prática de TDD também tem esse foco, quando prega que devemos fazer o código mais simples possível que atenda a necessidade em questão. E não poderia me esquecer do tão importante princípio de Baby Steps, utilizado em tudo isso que mencionei anteriormente.

Eu sinceramente acho que esse problema é inerente do ser humano e nós é que devemos nos doutrinar pra não cair nessa besteira.

Nesses últimos 2 dias, estive presentei no Rails Summit Latin américa. A organização do evento está de parabéns, principalmente o Fabio Akita, que conseguiu trazer pessoas chave da comunidade Rails mundial. As únicas coisas que senti falta foi uma camiseta do evento e a tradicional livraria, essa última eu tolerei pois ganhei um livro na palestra do Danilo Sato

Até a próxima …

Certa vez, passei por uma situação que acredito que você já passou um dia na sua vida profissional. Tive que implementar uma funcionalidade nova num projeto e precisava alterar diversas partes do código desse projeto para implementar essa funcionalidade. Infelizmente esse projeto não tem uma boa cobertura de testes automatizados. Existem até alguns testes, mas não o suficiente.

Dentro do “possível”, adicionei testes no projeto para melhorar o nível de confiança nas alterações e conseguir trabalhar um pouco mais sossegado quanto a qualidade do que estava sendo desenvolvido. Aproveitei a oportunidade para estimular meus colegas no uso de testes automatizados. Eu poderia simplesmente ignorar os testes e manter o “padrão” atual do projeto, mas como bem disse uma vez o Guilherme Chapiewski num excelente post sobre inclusão de testes num projeto, no momento em que comecei a modificar o código desse projeto foi o momento em que comecei a colocar testes nele.

Nessa experiência, enumerei 3 sintomas que podem ser um indício de que seu código está virando o Código do Pânico. São eles:

1. Classes/Metodos/Atributos que aparentemente não são mais usados não são removidos, pois não existe certeza de que a remoção deles não vai causar problema.
2. Existe um medo enorme em modificar um método. Geralmente cria-se outro que faz “quase a mesma coisa” e com um nome parecido, pois estragar aquele método pode gerar até uma demissão.
3. Desenvolvedores adicionam gambiarras (ou bacalhau pra quem prefere) sem a menor pena, afinal de contas, o código já está cheio delas mesmo.

A maioria dos problemas que tornam o código do seu projeto um Código do Pânico se resolvem com praticas como TDD, mantendo uma boa suite de testes e também retirando as gambiarras do seu código, que quando não removidas, estimulam outros desenvolvedores a adicionar mais um pouco sempre que a pressa pede.

O quanto você tem medo de alterar o código do seu projeto?

Nas empresas que trabalhei até hoje durante a minha carreira, a maioria delas tinha uma coisa em comum: o funcionário tinha que trabalhar para agradar seu chefe, ao invés de trabalhar em favor da empresa.

Nesse momento, surge uma nova definição de processo de desenvolvimento: BDD - Boss Driven Development (Desenvolvimento voltado para o chefe). Basicamente funciona da seguinte maneira:

• Se seu chefe chega cedo, trate de chegar cedo, pois se ele chegar antes de você, é muito ruim e provavelmente você terá problemas com ele
• Se der a hora de você ir embora e por algum motivo ele ainda estiver na empresa, permaneça até ele sair, pois ele pode precisar de você para alguma coisa. Quem sabe pegar um café pra ele?
• Por mais que você saiba que precisa melhorar alguma coisa que não está muito legal no projeto, cuidado ao falar com ele, pois ele pode achar isso uma ofensa, ou até mesmo dizer que a culda disso é sua.
• Se ele pedir pra você ficar fazendo tarefas que nada tem a ver com a sua profissão/aptidão/vocação, não questione, afinal de contas, o segredo para crescer em uma empresa é fazer tudo que o chefe manda e ficar bem caladinho.

Por mais incrível que possa parecer, ainda existem muitas empresas que trabalham dessa forma. Especialmente as famosas consultorias [A-Za-z]{3}.

O BDD relacionado a testes de software é bem mais interessante, não é mesmo?

Graças a Deus onde eu trabalho não é assim.

Quanto mais leio algumas coisas, mais penso que processos empíricos e ágeis serão adotados por quase todos os segmentos existentes hoje.

O Phillip Calçado postou sobre o caso de uma indústria farmaceutica e sua opção por implantar algumas práticas totalmente diferentes do que tinham o costume de usar. O resultado foi o mesmo que temos visto nas empresas de TI que tem abraçado as metodologias ágeis.

O mais engraçado disso tudo é que tem algumas pessoas que por mais que você mostre reultados, elas insistem que isso é uma modinha e que daqui a pouco passa.

Será?!?!?

Na última sexta-feira, deixei a Bradesco Seguros, empresa onde trabalhava pela DTS Consulting para encarar novos desafios.

Gostaria de agradecer aos amigos que me apoiaram bastante e aos meus antigos chefes na Bradesco Seguros, e também da DTS Consulting, que deixaram as portas abertas para um possível retorno futuro.

Há mais ou menos 1 mês atrás, o Bruno Pereira me chamou para uma vaga na Concrete Solutions. Ele me deu ótimas referências da empresa e resolvi aceitar o convite. Após todos os acertos, estou trabalhando alocado aqui na Globo.com, desde o início desta semana.

É um novo desafio na minha carreira, pois terei a oportunidade de trabalhar com SCRUM, o qual fiz um curso em março passado na TeamWare, e num ambiente realmente ágil, que começou com uma iniciativa do Phillip Calçado no ano passado.

Já comecei em um Sprint/Iteração e a coisa está realmente quente. Na semana que vem vou postar sobre o assunto e começarei a postar algumas coisas interessantes sobre Agile/SCRUM, baseado na minha vivência aqui.

Uma discussão que sempre vem a tona no forum do GUJ e em conversas entre colegas de trabalho, é sobre o uso do pattern TO/DTO (Antigo VO, que hoje em dia significa outra coisa). Eis o trecho do livro Core J2EE Patterns:

Transfer Object

Problem
You want to transfer multiple data elements over a tier.

Forces

• You want clients to access components in other tiers to retrieve and update data.
• You want to reduce remote requests across the network.
• You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

O Pattern Transfer Object, foi criado para solucionar os problemas dos Entity Beans (EJB 2.x), quando retornados para outro TIER, geralmente a apresentação, pois geralmente ficam em JVMs separadas. Quando você tenta retornar um Entity Bean, o que é retornado na verdade é um Stub para acesso ao mesmo. Quando são invocados os Getters deste, é aberto uma conexão de rede para cada invocação. Isso é extremamente custoso, gerando um overhead extremamente desnecessário.

Bem, mas nosso papo é tradução certo?

INI-UPDATE: Consegui o livro em português com um colega e estou adicionado a tradução em português também.

Vejamos a tradução para o português:

Transfer Object

Problema
Você deseja transferir diversos elementos de dados sobre uma camada.

Forças

• Você deseja que os clientes acessem componentes em outras camadas para recuperar e atualizar os dados.
• Você deseja reduzir as solicitações remotas ao longo da rede.
• Você deseja evitar a degradação do desempenho da rede causada pelas aplicações muito ruidosas que têm alto tráfego de rede.

Solução
Use um Transfer Object para enviar vários elementos de dados por uma camada.

O leitor atento perceberia que o segundo e terceiro item da seção Forças fala de tráfego de rede e degradação do desempenho da mesma.

FIM-UPDATE

Acontece que, o termo TIER, foi traduzido erradamente no livro em português para camada. O mais correto seria camada física ou nó. Em Java isso pode ser considerado simplesmente “em uma outra JVM”. Essa tradução gera confusão a todo momento. Se você conversar com 10 desenvolvedores, vai perceber que a maioria acredita que TO/DTO pode/deve ser usado entre LAYERS (i.e. camadas lógicas, usadas apenas para organização do software). Eis um grave problema de tradução, pois uma grande parte não sabe a diferença entre LAYER e TIER, e o uso do Pattern dessa forma se mostrou uma solução sem sentido, conforme diversas discussões no próprio GUJ.

Outro grave problema recorrente é a tradução dos livros de Patterns. Pegue por exemplo o PEAA traduzido e veja o Pattern Active Record. O nome do Pattern foi traduzido para Registro Ativo. Parece piada, considerando que um dos maiores valores de um Pattern é a criação de um vocabulário comum.

Em fim, existem diversos outros exemplos ruins, e só quem perde com isso é o leitor.

Mas nem tudo está perdido. Existem sim traduções bem aceitáveis, porém em quantidade extremamente reduzida e demoram a sair. Você está disposto a esperar? Não acha melhor comprar o livro em inglês mesmo?

Mas se eu não domino o inglês?

Sinto informar, mas você vai ficar refém de boas traduções, isso quando tiver tradução. Sem contar os podcasts, como por exemplo os videos disponibilizados no InfoQ. Na verdade, muita coisa não tem tradução e nem vai ter, isso é fato.

Esse cenário serve pra reforçar a idéia de que o inglês na área de TI é fundamental para o profissional se manter atualizado, visto que existem livros que não são traduzidos, e os que são, ou a tradução é horrível, ou demora muito para ser traduzido após o lançamento da versão original.

Mesmo que o cenário mude, ainda assim tem muita coisa que você estará perdendo. Quem sabe um emprego no exterior?

No último fim de semana (13 e 14 de junho/2008), participei com alguns amigos do Workshop de Modelagem ágil e DDD promovido pela Fratech em São Paulo.

O Workshop foi bem interessante, abordando temas atuais e de extrema importância no conhecimento do Desenvolvedor de Software.

No primeiro dia, o foco foi bastante em FDD, M3 e Agile Draw. Foi bem legal esse primeiro dia, pois eu experimentei algumas técnicas que nunca havia tentado. Confesso que não simpatizei muito com a modelagem com as figurinhas, nem muito com a FBS, mas eu vou pensar mais sobre o assunto e tentar me aprofundar um pouco pra tirar melhores conclusões.

Da esquerda pra direita: Colega de verde(rs), Gustavo, Eu, Colega de Branco(rs)

No segundo dia, o foco foi todo vontado para Domain Driven Design e UML em Cores. Foi bem interessante, pois o assunto tem um hype nos dias de hoje e é um assunto bastante motivador também.

A técnica de UML em Cores me ajudou um pouco a identificar algumas coisas em Model Driven Design, mas ainda assim, preciso testar mais pra definir se usarei essa técnica.

No mais gostaria de dar os parabéns ao Felipe Rodrigues e o Manoel Pimentel pelo evento que foi muito legal e tenho certeza que surgirão outros.

Da esquerda pra direita: Adndré, Eu, Felipe, Gustavo e Manoel

O unico problema é ter que se despencar do Rio de Janeiro toda vez, pois aqui estamos meio carentes de coisas do tipo, exceto pelo fato que as ultimas reuniões do RioJUG foram excelentes.