:: 2web ::

Hoje em dia, a idéia de Intraempreendedorismo (ou intrapreneurship, do inglês) está cada vez mais em evidência. Este profissional, capaz de tomar decisões importantes e identificar pontos fortes e oportunidades de melhoria, mesmo que ainda que não ocupe cargos de gerência, é cada vez mais procurado pelas empresas, indicando que este é um caminho a ser seguido.

Mas o que é intraempreendedorismo?

Como ponto de partida, tomemos a definição da wikipedia:

Intrapreneurship is the practice of entrepreneurial skills and approaches by or within a established organization.

Ou seja, intraempreendedor é aquele que trata a empresa onde trabalha como se fosse a sua. Usando de todo o espírito empreendedor que possua, em busca de oportunidades para o negócio, é aquele que não se atem somente aos limites de sua “função” dentro da empresa, mas que, sim, procura ter a noção do todo e, principalmente, de como melhor contribuir para que a organização atinja seus objetivos.

Mas o que o Scrum tem haver com isso?

Absolutamente tudo! Na verdade, o Scrum depende, fortemente, que os integrantes compartilhem desta visão intraempreendedora.

Hoje aconteceu o segundo e último dia do Workshop de Modelagem Ágil e DDD organizado pela Fratech.

É bem legal a oportunidade de trocar experiências e bater um papo com um pessoal bem legal aqui de São Paulo. É muito bom ver como a adoção de metologias e processos ágeis se dá “no mundo real” além das fronteiras da Globo.com - que era, até então, um dos pouquíssimos lugares em que eu conhecia (direto de quem faz rs) histórias do pessoal que trabalha com agile no Brasil.

O primeiro dia do Workshop foi dedicado aos processos Agile: maneiras de usar modelos UML e extensões dele como forma de comunicação em um projeto ágil. O Manuel Pimentel também apresentou uma proposta de um template para a modelagem e documentação de um projeto de software usando Mapas Mentais para a melhor visualização de diferentes aspectos envolvidos na construção do mesmo. A idéia - a qual ele chama de Mind Map Modeling, ou M3 - pode ser interessante para dar um overview do que acontece em um sistema específico, tanto no aspecto de tecnologia/design quanto no aspecto do domínio da aplicação.

No segundo dia, foi a vez de Felipe Rodrigues apresentar a parte dedicada ao Domain Driven Design e como este se encaixa neste contexto ágil, melhorando a comunicação entre time de desenvolvimento e Domain Experts. Esta palestra foi muito interessante pois, o conhecimento da turma sobre o assunto era bastante heterogêneo mas, mesmo assim, no final das contas, deu pra sentir que a galera conseguiu absorver grande parte do conteúdo, ainda que fosse bem extenso.

As discussões, ao meu ver, foram o melhor da apresentação; foi muito produtiva toda a movimentação que o assunto proporcionou entre os participantes do workshop. As questões e observações que foram aparecendo foram fundamentais para solidificar o conteúdo apresentado. Muito bom mesmo.

Para mim, particularmente, foi uma grande oportunidade, uma vez que pude aprofundar um conhecimento que era, até então, meio superficial. Agora, com certeza, irei tirar o livro do Eric Evans da estante e ler até o final desta vez! rs

Foi muito legal, também, ver o interesse de pessoas que não são de tecnologia, mas, sim, de negócios, por métodos mais eficazes de fazer software que os atenda plenamente - uma prova de que os cases de sucesso das metodologias ágeis e novas formas de desenvolvimento de software já estão chegando aos ouvidos de quem paga por ele, não apenas de quem o produz.

Um grande abraço aí pra galera de sampa - super gente fina - que aguentou esse carioca maluco durante os dois dias em que aconteceu este Workshop!

Ahh… amanhã tem Falando em java e a galera da globo.com aqui, com certeza, estará presente mais uma vez!

Grande abraço e até breve!

Nesta quinta-feira, iremos um pessoal aqui da Globo.com (Bruno Carvalho, Guilherme Chapiewski, Guilherme Cirne entre outros rs) a São Paulo para participar de alguns eventos: o primeiro deles é um Workshop sobre Modelagem Ágil e Domain-Driven Design que acontecerá na sexta e no sábado. Já, no domingo, estaremos no Falando em Java 2008.

Vai ser uma oportunidade bem legal para conhecer esse pessoal de Sampa e rever antigos amigos! Se estiver por perto, dê uma passada lá pois, com certeza, serão grandes eventos!

Um grande abraço e até a próxima!

Atualmente, a empresa mais notória por este tipo de prática, sem sombra de dúvidas, é a Google; é inevitável chegar a conclusão de que, mesmo “trabalhando somente 80% do tempo” (como alguns poderiam pensar) estes caras são muito bons em matéria de produtividade e criatividade.
Este tipo de ambiente (tão almejado pelos desenvolvedores e pessoal de tecnologia) muitas vezes, se torna difícil de se justificar perante a diretoria da maioria das empresas; executivos são pessoas que estão acostumadas com números resultados mais “palpáveis”.

Mas será que este tipo de incentivo se torna  válido apenas quando projetos como Orkut ou o Google Reader emergem da criatividade de seus funcionários? Será que existem somente benefícios diretos desta prática?

Desde que a Atlassian (empresa que criou o Jira, o Confluence dentre outros projetos muito interessantes) anunciou publicamente que iria investir na criação de um projeto de incentivo à criatividade de seus funcionários, os liberando de 20% da sua carga horária para que estes pudessem investir em seus projetos pessoais, muita gente vem comentando por aí.

Este artigo traz excelentes considerações sobre os benefícios diretos e indiretos que este tipo de incentivo pode causar numa organização. Além de todos estes pontos, eu gostaria de ressaltar algumas outras coisas, do ponto de vista de quem trabalha numa empresa onde existe este tipo de política :

Conhecimento gera conhecimento.

Se um funcionário não trabalha em um projeto específico durante 20% do seu tempo, isso não quer dizer que ele não esteja produzindo nada para a empresa - conhecimento, ainda mais hoje em dia, vale ouro. Certamente, através da experimentação nestes projetos pessoais, este mesmo funcionário adquire um conhecimento prático que poderá ser muito útil no seu próximo projeto para a organização.

Certamente, o conhecimento adquirido durante estes projetos pessoais, se multiplica na empresa: aqui na Globo.com, temos os Techtalks, palestras dadas pelos próprios funcionários sobre tecnologias, abordagens ou qualquer coisa que seja relacionada à tecnologia. Seja na forma de palestras, quanto no seu emprego em outros projetos este valioso momento para experimentação e iniciativa pessoal não é perdido - de maneira alguma.

Grandes idéias surgem de onde menos se espera

Este, sem dúvidas, é um dos  argumentos mais comuns para a adoção deste tipo de política. Entretanto, é importante ressaltar que boas idéias vêm em forma de produtos - as vezes uma grande idéia pode surtir efeito na mudança de uma metodologia que pode representar valor para a empresa da mesma maneira.

Pessoas talentosas e auto-motiváveis precisam de um ambiente adequado.

Como nunca, as empresas começaram a ver que para ter um time produtivo de verdade, é preciso investir - e muito! - na qualidade do pessoal, bem como na qualidade do ambiente de trabalho deste. Wiis e Xboxes são elementos cada vez mais comuns nos escritórios por aí (na globo.com temos os dois rsrs) :).

Não somente contratar talentos, é preciso retê-los na organização. Dar um voto de confiança aos funcionários pode ter resultados surpreendentes; formar um ambiente onde a iniciativa pessoal é valorizada e fomentada, realmente, ajuda  bastante tanto na contratação quanto na retenção destes.

Além de implementar esta política, o pessoal da Atlassian resolveu documentar o que for acontecendo neste blog e neste feed. Fica aí a dica para quem quiser saber como é um ambiente deste tipo mais de perto.

Um grande abraço e até a próxima!

Código incompreensível, complexidade desnecessária são problemas que qualquer pessoa que trabalhe com desenvolvimento de software já encontrou e, provavelmente, irá encontrar ainda por diversas vezes em sua vida profissional. Muitas das vezes, nos pegamos pensando de forma já não tão ética: “como é que alguém me escreve um código assim!?” ainda pior é quando nós mesmos é que contruimos código que não somos capazes de manter - “sei lá o que isso aqui faz, é que eu dei um control + c e um control + v naquela função lá e mudei pro que eu precisava”.

Precisava criar uma outra página na aplicação que tinha algumas semelhanças com uma outra já existente - “ah é só copiar o que beltrano fez, retirar a parte do votação, retirar a parte dos comentários, e acrescentar mas umas duas ou outras coisinhas”, me disse o líder técnico. O somatório disso tudo era claro - de igual, só tinha a listagem de produtos mesmo. Beleza, consegui fazer o que precisava mas não entendia muito bem o que estava fazendo.

Dia seguinte, um outro colega que precisava fazer uma outra listagem que não tinha nada a ver com produto, mas tinha algo que lembrava o que tinha feito no dia anterior. Como era comum naquele projeto, este recebeu o mesmo conselho “só copiar o que o Vitor fez e mudar umas coisinhas!”. Era evidente que aquilo não tinha como dar certo, tentei avisar mas não deu muito certo, afinal, “o projeto já estava atrasado”.

O sistema foi desenvolvido quase todo baseado nessas “implementações de referência”. Refactor? Ninguém na equipe cogitaria fazer isso num projeto que nem testes tinham pois “não dava tempo pra fazer essas coisas, o prazo era curto”. O código era absolutamente ilegível e, por diversos momentos, eu me indagava como aquiloa sequer compilava. Naquela situação, nada que eu dissesse adiantaria

As vezes parecia que ía desmoronar…

Depois de tantos ctrl+c e ctrl+v a torto e a direito, mal dava para lembrar que o código que serviu como “referência” para as outras funcionalidades, tinha sido feito às pressas , pela pessoa com menos experiência do time, inclusive. A situação era tão crítica que até alguns comentários de “TODO: Refactor this” foram copiados de um lugar para o outro - refactor este que, logicamente, nunca aconteceu.

Meu conselho é simples, na próxima vez que tiver um código de referência, não faça um copy and paste de tudo, mas o escreva com suas próprias mãos - isso faz com que seja muito mais fácil encontrar trechos que não são necessários na sua solução e ainda ajuda no melhor entendimento do código. Ahhh… e quando for fazer isso, não se esqueça dos testes unitários, claro.

Cada vez mais me preocupo com uma solução eficiente para criar backups dos meus tão preciosos dados; perdia muito tempo organizando, classificando e coletando informações que poderíam ser perdidas facilmente em caso de falha de algum disco ou mídia removível. Vinha pesquisando alguma solução de backup incremental que fizesse com que perdesse menos tempo para fazer esta tarefa e ocupar menos do meu tão precioso espaço

O Time Machine é uma solução fantástica de backup, mas, infelizmente só está disponível para o Leopard. Entretanto, este serviu de inspiração para toda uma comunidade desenvolver uma solução aberta para este problema.

Eis que encontrei o Flyback, uma solução de backup incremental para Linux. O projeto ainda é recente, mas parece ser bastante promissor. Mesmo sem toda a riqueza da interface do Time Machine, o Flyback é bastante funcional e simples de usar.  Estou bem satisfeito com os resultados até agora.

Vale a pena dar uma olhada!

Grande abraço!

Dessa vez, um post mais técnico. Neste artigo, vou explicar como se executar os seus testes em rspec de forma automática e integrada ao sistema de notificações do Gnome.

Uma forma muito interessante de se trabalhar com testes em ruby é através da utilização do Autotest. Para quem não conhece, o Autotest é uma ferramenta que, quando executada na raíz de um projeto um rails, ela fica observando o diretório e, para cada mudança nos arquivos do projeto, ela executa os testes relacionados para certificar que estas não quebraram alguma coisa.

O Rspec é um framework para a Behaviour Driven Development para aplicações em Ruby. Não vou entrar em maiores detalhes por aqui, pois o farei nos próximos artigos quando falarei mais especificamente sobre ele. Por último, o Libnotify é uma biblioteca que, usando o D-BUS, permite que sejam exibidas informações em forma de notificações no ambiente GNOME.

Versões das bibliotecas utilizadas

ZenTest 3.9.1 Rspec 1.1.3 ruby-libnotify 0.3.3

Preparando o ambiente

Na criação deste artigo, foi utilizada a distribuição Ubuntu, em sua versão 7.10 (Gutsy gibbon) . Também assumo que você tenha as bibliotecas essenciais instaladas. Também assumo que você tenha instalado a biblioteca libnotify, para a exibição de mensagens

Caso não as tenha, instale-as com o seguinte comando no terminal. Certifique-se de ter habilitado o repositório multiverse no seu sistema.

Estou assumindo que você tenha instalado, também, o RSpec e o ZenTest. Certifique-se ter as versões mais atualizadas dos dois gems. O ZenTest 3.9.1 não funciona com versões anteriores à 1.1.3 do rspec devido a mudanças no autotest.

Caso não tenha qualquer um dos dois ou não tenha certeza de qual é a versão que você tem disponível em sua máquina, faça a instalação das versões mais recentes com o comando:

* Atenção para as letras maiusculas em ZenTest.

Instalando

Instale a biblioteca de comunicação do ruby:

1º Baixe o ruby-libnotify aqui e descompacte o arquivo para o diretório de sua preferência. No momento em que escrevo este artigo, este se encontra na versão 0.3.3

2º Vá até o diretório e instale o ruby-libnotify com os seguintes comandos.

Configurando as notificações

Para exibir as notificações sobre os resultados dos testes, o ZenTest busca por suas configurações em um arquivo nos seguintes lugares, nesta respectiva ordem:

• Autotest
• AutotestSubClass
• ~/.autotest
• ./.autotest

Por último, um pouquinho de eye-candy :). O script autotest, exibe três ícones para notificar o usuário sobre o resultado dos testes.

• ~/fail.png -> Quando os testes falham
• ~/pending.png -> Quando os testes passam, mas ainda há testes que precisam ser especificados
• ~/pass.png -> Quando os testes são todos executados com sucesso

Eu uso no meu sistema as configurações propostas neste blog e que podem ser baixadas neste link.

Para utilizá-las, descompacte o arquivo autotest-libnotify.zip e mova o conteúdo da pasta autotest-libnotify/ para o seu diretório do usuário.

Aí vai uma screenshot de como ficou o resultado no meu sistema.

A facilidade em se ver o impacto das alterações que fazemos no sistema, no momento em que acabamos de fazê-la, faz com que o desenvolvimento se dê de maneira muito mais fácil e fluida.

A experiência de trabalhar desta forma, fez com que a minha relação com automatização de testes mudasse completamente.

Espero que este post lhe seja útil!

Um grande abraço e até a próxima.

Kurt Schraber postou ontem em seu blog um post em que fala -  em um tom até um pouco contundente - sobre a importância de testes automatizados em aplicações rails. Mesmo se tratando de um blog em lingua inglesa, eu acho que esse tipo de questionamento também vem aparecendo bastante nos foruns e listas de discussões brasileiras, o que é bastante produtivo.

Quando comecei a programar, meu primeiro contato foi com as linguagens dinâmicas. Comecei com ASP e PHP. Me lembro muito bem de como algumas alterações que pareciam tão “inofensivas” causavam problemas que eram muito difíceis de serem encontrados por mim ou, até pior, por outra pessoa que viesse dar manutenção no código. Não que este tipo de problema não aconteça com as linguagens compiladas - se fosse assim, não existia o Junit - mas o fato do código ser compilado, no mínimo, faz com que o programador tenha a segurança de que, ao menos, o código não apresenta erros de sintaxe.

Em ruby é até pior; como saber, antes de executar o código, que a variável x que você espera na função z, contida no módulo xpto, é realmente do tipo y que você havia previsto? Isso sem falar quando se começa a usar meta programação… aí vira um caos total.  O poder que a linguagem nos dá de fazer coisas “mágicas” como remover ou inserir métodos em tempo de execução, até mesmo, em instâncias de classe faz com que seja muito difícil (principalmente se tratando de código legado) de prever tudo o que possa acontecer naquele trecho específico de código só de olhar.

Ao meu ver, o grande benefício dos testes automatizados não é a segurança de que o sistema funciona, mas, sim, o feedback instantâneo que estes nos dão ao fazermos alguma alteração que quebre o funcionamento do mesmo. A segurança que temos de que um código funciona nos casos que são previstos e estão cobertos pelos testes é algo que difícilmente seria conseguido sem eles.

Depois que comecei a tratar os testes do que vinha desenvolvendo com mais atenção, encontrar erros no software era algo muito mais fácil; se o teste que verificava a inclusão de um objeto classe xpto quebrou, os lugares onde devo procurar coisas que estão possívelmente erradas é muito reduzido - ao invés sair a procura de logs, mensagens de erro ou qualquer outra coisa que me possa dar uma dica do que está acontecendo, os testes fizeram este trabalho por mim me indicando o ponto que faz o sistema não se comportandar da forma esperada.

Acho bem interessante ver que assuntos como estes estão sendo cada vez mais discutidos. Sinal de que as pessoas estão começando a dar mais atenção a aspectos tão importantes do desenvolvimento de software: A qualidade e a manutenibilidade do mesmo.

Hoje, pela manhã, foi liberada a atualização do Globo Vídeos que disponibiliza aos usuários a opção de, novamente, assistir os vídeos em tela cheia. Essa funcionalidade havia sido retirada devido a uma decisão de focar na exibição dos vídeos em flash e depois, então, voltar a oferecer outras funções como a de tela cheia, por exemplo. Uma decisão, ao meu ver, muito acertada. Práticas empregadas pelos processos ágeis contribuiram, em muito, para nos dar a segurança necessária para fazermos as coisas desta forma.

Este post do Guilherme Chapiewski e este outro do Tiago Albineli Motta explicam, com mais detalhes, os motivos que levaram a esta priorização dos requisitos.E é com muita felicidade que lhes escrevo essas linhas; como já disse anteriormente, tem sido uma experiência muito gratificante poder participar deste projeto e do primeiro release de 2008 do Globo Vídeos - o início de muita coisa legal que acontecerá neste ano.

Um grande abraço e até próxima!