Para começar escolha a versão de Emacs que mais se adeque ao seu gosto e ao seu sistema operacional, tem até versão para Windows e depois de tê-lo instalado, faça o tutorial para começar a se acostumar com os conceitos fundamentais do Emacs.

Configurando o Emacs para uso geral

Se você estiver usando Emacs no Linux, e eu realmente espero que esteja, na instalação foi criada uma pasta oculta dentro da pasta do seu usuário de nome .emacs.d. Para facilitar a configuração, crie dentro dessa pasta uma outra pasta de nome plugins.

Toda a nossa configuração ficará colocada dentro do seguinte arquivo: /home/<nome_usuario>/.emacs.d/init.el. Como já devem ter lido por aí, a grande vantagem de uso do Emacs é a customização, é como brincar de lego para montar a sua IDE personalizada. Toda a configuração do Emacs é feita em LISP, mas não se preocupe, você não precisa conhecer LISP a fundo para entender esse tutorial, a maior parte dos comandos é bem fácil de entender. Abra esse arquivo no próprio Emacs ou em outro editor de texto de sua preferência. Todos os trechos de código expostos nesse post devem ser colocados dentro desse arquivo de configuração.

Passo 1

Coloque essas linhas abaixo no início do arquivo de configuração.

(add-to-list 'load-path "~/.emacs.d")
(add-to-list 'load-path "~/.emacs.d/plugins")

Essas linhas acima carregam as pastas onde serão procurados os arquivos com extensão .el, que são os arquivos que representam extensões e plugins que usaremos durante esse tutorial.

Passo 2

Agora, vamos baixar o primeiro plugin da nossa configuração, é o ido-mode. Baixe esse arquivo e coloque na pasta ~/.emacs.d/plugins. Depois adicione o seguinte trecho no arquivo de configuração.

(require 'ido)
(ido-mode t)

Esse plugin serve para facilitar a abertura de arquivos dentro do Emacs e também a troca entre os buffers. Como o Emacs pode ser bastante confuso para os iniciantes esse plugin é mais do que recomendado.

Passo 3

(cua-mode t)
(setq cua-auto-tabify-rectangles nil) ;; Don't tabify after rectangle commands
(transient-mark-mode 1) ;; No region when it is not highlighted
(setq cua-keep-region-after-copy t) ;; Standard Windows behaviour

(delete-selection-mode 1)

cua-mode vai servir para deixar o Emacs parecido com qualquer outra IDE comum permitindo usar as teclas de atalho Ctrl + C, Ctrl + V e assim por diante. Só é preciso ter cuidado pois esses atalhos conflitam com alguns outros do Emacs e por isso somente estão ativos quando algum texto está selecionado.

As demais linhas desse passo são opcionais, chamo a atenção para a linha do delete-selection-mode, essa linha faz com que, toda vez que um texto estiver selecionado, qualquer inserção será inserida no lugar do texto selecionado.

Passo 4

[Auto Complete Mode] melhora a funcionalidade de auto-completar do Emacs. A parada é realmente inteligente. Para instalar:

$ cd ~/.emacs.d/plugins/
$ curl http://cx4a.org/pub/auto-complete/auto-complete-1.3.1.tar.bz2 | tar jx
$ cd auto-complete-1.3.1
$ make byte-compile

Para configurar:

(add-to-list 'load-path "~/.emacs.d/plugins/auto-complete-1.3.1/")
(require 'auto-complete-config)
(add-to-list 'ac-dictionary-directories "~/.emacs.d/plugins/auto-complete-1.3.1/ac-dict")
(ac-config-default)

Passo 5

Instale o YASnippet. Esse cara cria um menu no Emacs onde podemos usar um sistema de templates semelhante ao TextMate.

Passo 6

(require 'uniquify)
(setq uniquify-buffer-name-style 'forward)

O último passo dessa customização geral é o uso do uniquify, esse modo é extremamente útil quando começamos a trabalhar com vários arquivos abertos e que alguns tenham nomes iguais.

Configurando o Emacs para programar com Python

Antes de entrar no passo-a-passo de como configurar o Emacs para Python é importante avisar algo. Para não deixar a instalação original de Python no meu Ubuntu ficar poluída com todas as bibliotecas que eu quero instalar, eu instalo uma ferramenta conhecida como virtualenv, e para instalação de pacotes do Python, eu uso uma ferramenta chamada pip. Basicamente, virtualenv é uma ferramenta para criar ambientes isolados de Python, e pip é simplesmente o melhor gerenciador de pacotes Python que eu conheço.

Para essa configuração eu criei um ambiente de Python isolado com virtualenv apenas para servir ao Emacs. Sugiro que, se estiver seguindo esse tutorial, você faça o mesmo. Vamos continuar com o passo-a-passo.

Passo 1

(setq-default indent-tabs-mode nil)  ; use only spaces and no tabs
(setq default-tab-width 4)

Python usa indentação para definição de blocos de código, assim é extremamente importante que usemos essas linhas código para definir o tamanho da indentação e também definir que sempre serão usados espaços ao invés de tabs.

Passo 2

Agora vamos instalar um pacote essencial para uso de Python no Emacs, o nome desse pacote é Pymacs. Se estiver usando Linux, vá até o seu terminal e digite os comandos abaixo:

• Instalação Pymacs (Parte Emacs)

$ curl -L https://github.com/pinard/Pymacs/tarball/v0.24-beta2 | tar zx
$ cd pinard-Pymacs-016b0bc
$ make
$ cp pymacs.el ~/.emacs.d/pymacs.el
$ emacs -batch -eval '(byte-compile-file "~/.emacs.d/pymacs.el")'

• Instalação Pymacs (Parte Python)

$ pip install https://github.com/pinard/Pymacs/tarball/v0.24-beta2

Agora vamos ao arquivo de configuração no Emacs e incluir o seguinte trecho:

(setenv "PYMACS_PYTHON" "~/<caminho_virtualenv>/bin/python")

(autoload 'pymacs-apply "pymacs")
(autoload 'pymacs-call "pymacs")
(autoload 'pymacs-eval "pymacs" nil t)
(autoload 'pymacs-exec "pymacs" nil t)
(autoload 'pymacs-load "pymacs" nil t)

A primeira linha será necessária apenas se você estiver usando o virtualenv.

Passo 3

Nesse passo, vamos instalar o Ropemacs e o Rope. Rope é uma poderosa biblioteca de refactoring para Python, e Ropemacs obviamente um plugin do Emacs para uso do Rope.

Para instalar o Rope e Ropemacs, digite no terminal:

$ pip install http://bitbucket.org/agr/ropemacs/get/tip.tar.gz

No arquivo de configuração do Emacs:

(require 'pymacs)

(pymacs-load "ropemacs" "rope-")
(setq ropemacs-enable-autoimport t)

Passo 4

Chegamos em uma das partes que eu mais gosto do Emacs, análise automática, on-the-fly, do código Python. O responsável por isso é o Flymake que já vem por padrão, a partir da versão 23 do Emacs. O que vamos precisar instalar aqui é o pep8 e o pyflakes que são bibliotecas para análise estática de código-fonte Python.

$ pip install pyflakes pep8

Depois, precisamos configurar o Flymake no Emacs:

(when (load "flymake" t)
  (defun flymake-pyflakes-init ()
    (let* ((temp-file (flymake-init-create-temp-buffer-copy
                       'flymake-create-temp-inplace))
           (local-file (file-relative-name
                        temp-file
                        (file-name-directory buffer-file-name))))
      (list "/home/lslf/<caminho_virtualenv>/bin/pyflakes" (list local-file))))

(add-to-list 'flymake-allowed-file-name-masks
               '("\.py\'" flymake-pyflakes-init)))
(add-hook 'find-file-hook 'flymake-find-file-hook)
(defun my-flymake-show-help ()
  (when (get-char-property (point) 'flymake-overlay)
   (let ((help (get-char-property (point) 'help-echo)))
    (if help (message "%s" help)))))
(add-hook 'post-command-hook 'my-flymake-show-help)
(delete '("\.html?\'" flymake-xml-init) flymake-allowed-file-name-masks)

Passo 5

O último passo desse tutorial, também se refere a análise de código, mas ao invés de análise automática, vamos configurar uma análise de código através de um comando do Emacs.

Primeiro crie um arquivo no caminho ~/.emacs.d/ chamado pychecker.sh. O conteúdo do arquivo será:

#!/bin/bash
~/<caminho_virtualenv>/bin/pyflakes $1
echo "## pyflakes acima, pep8 abaixo ##"
~/<caminho_virtualenv>/bin/pep8 --repeat $1

Agora a configuração do Emacs:

(custom-set-variables
  '(py-pychecker-command "~/.emacs.d/pychecker.sh")
  '(py-pychecker-command-args (quote ("")))
  '(python-check-command "~/.emacs.d/pychecker.sh")
)

Dicas extras

Além de tudo o que foi colocado aí acima, você pode querer ir além e melhorar cada vez mais o seu uso do Emacs, para ficar do seu gosto, aqui vão algumas dicas:

• O Emacs já funciona automaticamente com Subversion, basta aprender a usar;
• Você pode configurar o Emacs para te ajudar com o Django também;
• Coloque o seu diretório ~/.emacs.d sob controle de versão;
• Explore a infinidade de possibilidades de customização do Emacs.

Conclusão

Eu sei que esse tutorial ficou bem longo, mas eu tentei colocar todas as principais dicas de otimização de tempo e produtividade que eu adquiri em pouco tempo usando o Emacs, como eu disse antes, é como brincar de lego para montar a sua IDE, com as funcionalidades que você precisa.

Deixe as suas impressões nos comentários, se houver algum problema, pode entrar em contato que tentarei ajudar o máximo que puder.

Referências

Ryan McGuire: Emacs as a powerful Python IDE

SaltyCrane: My Emacs Python environment

Lei Chen: Setup Perfect Python Environment In Emacs

Jesse Legg: Emacs for Python Programmers: Basics

Jesse Legg: Emacs for Python Programmers #2: Virtualenv, IPython & Daemon Mode

Brandon Rhodes: Installing Python packages for Emacs with virtualenv

Alex Clemesha: Tools of modern Python hacker: Virtualenv, Fabric and pip

Quando já estava quase desistindo de encontrar algo atualizado que atendesse a minha necessidade, eu me deparo com essa biblioteca de nome suds. Fiquei positivamente surpreso ao encontrar uma biblioteca que além de ser atualizada e possuir uma boa documentação, representa toda a simplicidade e praticidade de Python.

Como muitos sabem, o protocolo SOAP é um protocolo de comunicação complicado, mas usando o suds tudo fica muito simples. Vejam só.

Para o nosso exemplo, vamos usar um web service que traz informações sobre a Copa do Mundo (eu sei, estou meio atrasado, mas vá lá, é só um exemplo). O endereço do serviço é: http://footballpool.dataaccess.eu/data/info.wso?WSDL. Vamos agora usar o suds para acessar esse serviço.

from suds.client import Client

url = "http://footballpool.dataaccess.eu/data/info.wso?WSDL"
cliente = Client(url)
print cliente

Simples assim e temos o cliente que representa o serviço com informações sobre a Copa do Mundo carregado em memória. A última linha do código acima serve para listar os métodos que esse serviço disponibiliza. O resultado é esse:

Suds ( https://fedorahosted.org/suds/ )  version: 0.3.9 GA  build: R659-20100219

Service ( Info ) tns="http://footballpool.dataaccess.eu"
   Prefixes (1)
      ns0 = "http://footballpool.dataaccess.eu"
   Ports (1):
      (InfoSoap)
         Methods (41):
            AllCards()
            AllDefenders(xs:string sCountryName, )
            AllForwards(xs:string sCountryName, )
            AllGames()
            AllGoalKeepers(xs:string sCountryName, )
            AllGroupCompetitors()
            AllMidFields(xs:string sCountryName, )
            AllPlayerNames(xs:boolean bSelected, )
            AllPlayersWithRedCards(xs:boolean bSortedByName, xs:boolean bSortedByRedCards, )
            AllPlayersWithYellowCards(xs:boolean bSortedByName, xs:boolean bSortedByYellowCards, )
            AllPlayersWithYellowOrRedCards(xs:boolean bSortedByName, xs:boolean bSortedByYellowCards, xs:boolean bSortedByRedCards, )
            AllStadiumInfo()
            Cities()
            Coaches()
            CountryNames(xs:boolean bWithCompetitors, )
            DateLastGroupGame()
            DateOfFirstGame()
            DateOfLastGame()
            FullTeamInfo(xs:string sTeamName, )
            GameInfo(xs:int iGameId, )
            GameResultCodes()
            GamesPerCity(xs:string sCityName, )
            GamesPlayed()
            GoalsScored(xs:int iGameId, )
            GroupCompetitors(xs:string sPoule, )
            GroupCount()
            Groups()
            NextGame()
            NumberOfGames()
            PlayedAtWorldCup(xs:string sTeamName, )
            RedCardsTotal()
            StadiumInfo(xs:string sStadiumName, )
            StadiumNames()
            StadiumURL(xs:string sStadiumName, )
            Teams()
            TeamsCompeteList()
            TopGoalScorers(xs:int iTopN, )
            TopSelectedGoalScorers(xs:int iTopN, )
            TournamentInfo()
            YellowAndRedCardsTotal()
            YellowCardsTotal()
         Types (38):
            ArrayOfString
            ArrayOftCardInfo
            ArrayOftCoaches
            ArrayOftCountryInfo
            ArrayOftCountrySelectedTopScorer
            ArrayOftGameCard
            ArrayOftGameInfo
            ArrayOftGameResultCode
            ArrayOftGoal
            ArrayOftGroupInfo
            ArrayOftGroupsCompetitors
            ArrayOftPlayerNames
            ArrayOftPlayersWithCards
            ArrayOftStadiumInfo
            ArrayOftTeamCompete
            ArrayOftTeamInfo
            ArrayOftTopGoalScorer
            ArrayOftTopSelectedGoalScorer
            tCardInfo
            tCards
            tCoaches
            tCountryInfo
            tCountrySelectedTopScorer
            tFullTeamInfo
            tGameCard
            tGameInfo
            tGameResultCode
            tGoal
            tGroupInfo
            tGroupsCompetitors
            tPlayerNames
            tPlayersWithCards
            tStadiumInfo
            tTeamCompete
            tTeamInfo
            tTopGoalScorer
            tTopSelectedGoalScorer
            tTournamentInfo

Como podem perceber, esse serviço tem 41 métodos que eu posso acionar para obter informações sobre a Copa do Mundo. Vamos ver como eu posso usar esses métodos.

resultado = cliente.service.RedCardsTotal()
print resultado

O resultado impresso pelo trecho acima é: 17.

Vamos todos dar um viva à simplicidade do Python! :o)

A revista TI Digital do mês março vem com uma matéria de capa com 14 páginas sobre a minha linguagem de programação favorita, Python. E por pura coincidência eu fui um dos convidados a responder algumas perguntas para compor a matéria.

Eu não conhecia a revista antes disso, mas o contato com eles foi sempre muito cordial e a matéria ficou bem bacana, servindo como uma excelente divulgação para a linguagem. Aproveito esse post para colocar aqui as perguntas que a revista me fez e as minhas respostas na íntegra.

Quais foram suas primeiras impressões quando começou a programar em Python? Qual era a linguagem de programação que você utilizava antes?

Eu comecei a utilizar Python em 2005, quando ainda trabalhava no SERPRO. Nessa época eu fui integrado a uma equipe que desenvolvia um sistema para o Ministério da Educação e esse sistema era inteiramente feito em Python. Uma das coisas que mais me impressionou em Python foi o ganho de produtividade em um curto espaço de tempo. Eu não tinha experiência anterior com a linguagem e em apenas 2 dias eu já estava participando ativamente no desenvolvimento de alguns módulos desse sistema.

Anteriormente, eu já havia programado com Java, C#, Visual Basic e ASP e ainda assim, Python também me impressionou bastante pela legibilidade do código-fonte. Quando somos desenvolvedores de software, nós passamos mais tempo lendo código do que propriamente escrevendo, e em Python sempre foi muito fácil entender o código que foi escrito por outro desenvolvedor.

Onde se pode programar Python?

Python pode ser programado em qualquer sistema operacional moderno e até mesmo nos sistemas mais antigos. Em diversas distribuições Linux, como Ubuntu, Fedora, Suse entre outras, o Python já vem instalado nativamente, o mesmo acontece também para o Mac OS X. No caso da plataforma Windows, existem instaladores que podem ser usados para facilmente instalar o Python. Posso destacar que é de longe a linguagem mais portável com que eu trabalhei, e você nem mesmo precisa alterar o código-fonte da sua aplicação para que ela funcione em sistemas operacionais diferentes, isso eu já pude comprovar na prática.

O que é possível desenvolver com o Python?

Python é uma linguagem de programação flexível. Por ser uma linguagem dinâmica e multi-paradigma, Python é ideal para desenvolver desde pequenos scripts para automatização de determinadas tarefas, passando por sistemas web, cliente-servidor, desktop e até mesmo sistemas científicos. Basta dizer que a NASA usa Python, para comprovar o que estou dizendo.

Por que o Python possui duas versões disponíveis para download (Python 2.6.4 and Python 3.1.1)?

Python é uma linguagem um tanto quanto antiga, foi lançada em 1991, e desde a sua criação tem como premissas ser uma linguagem simples, que cabe no nosso cérebro e que procura sempre remover os obstáculos da frente do desenvolvedor para que o mesmo possa se preocupar mais com o conteúdo do que está sendo desenvolvido do que com a linguagem. No entanto, assim como acontece com qualquer linguagem de programação, mesmo Python tendo adotado essas premissas para o seu desenvolvimento, ela foi acumulando alguns "probleminhas" chatos. Para resolver esses problemas e manter uma linguagem simples e que cabe no nosso cérebro, o criador da linguagem resolveu criar a versão 3 de Python quebrando a compatibilidade com a versão anterior (Python 2).

Sendo assim, para manter a compatibilidade com os sistemas antigos criados em Python, foi lançada a versão 2.6 que contém ainda algumas funcionalidades novas da versão 3. E a versão 3, pôde então ser lançada com as novas funcionalidades previstas e sem o compromisso de manter a compatibilidade com as versões anteriores. Com o lançamento dessa nova versão, foi criada também uma ferramenta batizada 2to3 que auxilia na migração de código-fonte criado em Python 2 para Python 3.

O Python pode ser integrado a outras linguagens de programação e ferramentas. Quais são as principais? O que estas integrações oferecem?

As principais integrações de Python são justamente com as plataformas de desenvolvimento que mais fazem sucesso no mercado hoje. Python possui integração com a plataforma Java através de um projeto chamado Jython que está em constante evolução e oferece acesso total as classes Java e permite que código Python seja compilado em classes Java.

Existe também a integração com a plataforma .NET através do projeto IronPython, sendo esse também um projeto bastante evoluído que conta com um console interativo para experimentar trechos de código e conta também com uma IDE específica baseada no Visual Studio da Microsoft. Essa integração permite que você tenha acesso às bibliotecas do .NET Framework usando o Python, ao invés de uma das linguagens da plataforma .NET . Com essa integração nós podemos, por exemplo, criar uma aplicação desktop com a biblioteca .NET padrão (WPF) usando código Python na solução.

Outra integração que ainda está em fase beta, mas que promete ser bem interessante é o PyObjC que é uma integração entre Python e Objective-C, a linguagem utilizada para desenvolver aplicativos para iPhone, iPod Touch e para o recém-lançado iPad. Acho que não preciso nem comentar muito quais serão as vantagens dessa integração né?

Existem alguns fatores tecnológicos q o Python precisa evoluir. Então, o que você sente falta no Python? O que gostaria que fosse diferente na linguagem?

Python possui um conceito muito interessante chamado de "batteries included", o que significa que a biblioteca padrão do Python é muito poderosa, de modo que lhe oferece funcionalidades para diversos tipos de necessidades que venham a surgir para a sua aplicação. Mas mesmo assim, ainda sinto falta em Python de uma biblioteca nativa que seja capaz de lidar com web services por exemplo, existem alguns projetos interessantes nesse sentido, mas acredito que a biblioteca padrão pudesse incorporar essa funcionalidade.

Usar concorrência em Python também ainda é bem rudimentar, e acredito que a linguagem possa evoluir MUITO nesse ponto, não somente na questão de performance que se torna sofrível em alguns casos que você precise lidar com concorrência, como a própria módulo python para esse fim, threading, poderia incluir mais funcionalidades para facilitar a vida de quem precisa programar usando concorrência.

Na parte de orientação a objetos, eu gostaria que Python tivesse uma melhor implementação de encapsulamento, não somente por necessidade minha, mas também para poder "agradar" aos desenvolvedores que tem uma grande experiência com OO e acabam não se acostumando muito bem com o encapsulamento de Python que é bem diferente de Java e .Net, por exemplo.

A comunidade Python ainda não é muito conhecida. Qual a melhor maneira de fazer com que o Python seja mais explorado? O que ainda falta para convencer os programadores sobre o poder do Python?

Outro dia ouvi um colega de trabalho dizer que Python é uma linguagem que deu certo em outros países, mas não funcionou no Brasil. Concordo que isso já pode ter sido verdade algum dia, mas hoje estamos experimentando uma realidade diferente. Muitas empresas no país tem adotado Python para projetos importantes, e acredito que para fazer com que o Python seja mais explorado é importante mostrar que a cena está mudando. É necessário investir em um marketing positivo, ou seja, ao invés de criticar duramente as linguagens que hoje dominam o mercado, precisamos exaltar as características do Python, convencer as pessoas, especialmente aquelas que hoje estão em posição de decisão, de que Python é uma alternativa viável, estável, mais rápida e mais barata do que a maioria das opções que existem hoje.

Convencer os programadores, eu acredito ser a parte mais fácil do processo, mas precisamos de mais eventos técnicos focados em Python para mostrar todas as possibilidades que o Python oferece. Usar um veículo de comunicação como a revista TI Digital com uma matéria de capa sobre Python já mostra que o cenário está mudando rapidamente e favoravelmente à linguagem, isso também ajuda a mostrar para os desenvolvedores que existem alternativas.

A comunidade brasileira tem ajudado de alguma forma para o crescimento e atualização da linguagem?

A comunidade brasileira de Python é fantástica. Hoje nós temos a Associação Python Brasil que promove anualmente uma conferência de Python que cada vez mais tem crescido em qualidade e audiência. E sem contar que temos diversos grupos locais espalhados pelo país, entre eles posso destacar o PythonRio que promove alguns eventos importantes sobre Python durante o ano. Um desses eventos promovidos que merece destaque é o PythonCampus que é uma espécie de caravana de tecnologia que visa integrar os estudantes de diversas universidades do estado com o mercado e com a tecnologia em si.

Se tem algo que tem me deixado cansado ultimamente são as discussões sobre linguagens de programação. Mas as discussões que me deixam cansado não são aquelas discussões construtivas onde linguagens de programação são comparadas para percebermos quais são os pontos fortes e fracos de cada uma. O que tem me incomodado e muito são aquelas discussões juvenis que começam com frases do tipo "a minha linguagem é melhor do que a sua", "a linguagem que você usa vai morrer" e seguem com argumentos fracos e geralmente baseados em suposições infundadas, ou seja, a discussão pelo simples prazer de discutir e não de melhorar algo ou alguém.

Um exemplo, fiz uma pesquisa no Google colocando a frase "java is dead" e a pesquisa retornou 157.000 resultados, boa parte desses são posts em blogs ou artigos em sites de tecnologia estão decretando o fim do Java. Ora bolas, ou estão fazendo isso para atrair visitantes para seus blogs/sites ou são pessimistas de plantão que querem decretar o fim do Java a qualquer custo. Não que eu seja um fã de Java (está longe disso), mas posso citar aqui N argumentos rapidamente que comprovam que a linguagem não vai morrer tão cedo.

Sendo assim, eu resolvi escrever esse post para fazer um apelo: se a sua crítica sobre qualquer linguagem de programação não for construtiva, guarde-a para você ou fale somente para os seus amiguinhos que acham o máximo ouvir os seus argumentos vazios que não levam a lugar nenhum. Vou aproveitar e pedir um outro favor: se estiver no meio de qualquer discussão vazia sobre linguagens de programação, por favor, não alimente-a, seja pessoalmente, em fóruns, em blogs ou em qualquer outro meio de comunicação.

Ao invés de falar mal da linguagem de programação do vizinho, economize esse esforço e empregue-o em aprender uma nova linguagem de programação que você goste, ou em melhorar algum aspecto ou promover a sua linguagem de programação preferida. Acredito que assim estaremos contribuindo para uma comunidade tecnológica melhor.

Errado, por quê?

Primeiro, preciso deixar claro que isso não é exclusividade da empresa onde trabalho, mas pelo que eu tenho conversado com outras pessoas e tenho lido por aí, a maioria absoluta das empresas no Brasil ou no mundo estão fazendo software do jeito errado.

Uma coisa que comprova isso é o Chaos Report, um relatório lançado a cada 2 anos com dados estatísticos sobre como anda o desenvolvimento de software nas empresas ao redor do mundo. Vamos dar uma olhada no gráfico relativo a 2009.

Apenas 32% dos projetos são bem sucedidos, no passado a situação era bem pior, em 1994 apenas 16% dos projetos eram bem sucedidos. Mas ainda assim, eu considero esses números alarmantes. Com toda a dita "maturidade" em desenvolvimento que adquirimos nos últimos anos, com todas as metodologias, processos, certificações e toda a evolução da indústria de software para isso? Sem contar o fato que eu acho que esses números são extremamente otimistas em relação à realidade que eu observo.

Tim Bray, empregado da Oracle, escreveu um artigo sobre isso e não poderia ter colocado o problema de forma melhor:

The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.

Quem conhece pelo menos um pouco das comunidades de software livre ou das empresas da era web 2.0 sabe que isso é uma tremenda verdade. Os desenvolvedores dessas comunidades, em geral, produzem sistemas melhores, mais baratos, em menos tempo e com um custo menor do que a maioria absoluta das grandes empresas que conhecemos atualmente. Tim Bray vai ainda mais fundo na sua crítica:

This is unacceptable. The Fortune 1,000 are bleeding money and missing huge opportunities to excel and compete. I’m not going to say that these are low-hanging fruit, because if it were easy to bridge this gap, it’d have been bridged. But the gap is so big, the rewards are so huge, that it’s time for some serious bridge-building investment.

O que precisamos nos perguntar nesse momento é: por que as coisas estão tão erradas assim com o desenvolvimento de software no meio corporativo? Por que as empresas que possuem todo o capital, todo o "suporte" dos grandes fornecedores não conseguem atingir a excelência no desenvolvimento de software? O momento não é apenas de fazer perguntas, mas sim de buscar as respostas.

Onde está a solução?

Uma das sugestões do Tim Bray, e que deveria ser óbvio pois é um conselho antigo da engenharia de software, é comprar sistemas ao invés de construí-los, sempre que isso for possível, mas isso ainda é uma controvérsia. E muitas vezes a coisa realmente é mais complexa do que imaginamos. Se um software atende a 70% das suas necessidades, o que será melhor, construir um para atender completamente ou solicitar ao fornecedor uma customização? Qual a melhor opção para futuras manutenções nesse software? Isso nem sempre é uma pergunta fácil de responder.

Mas ainda assim. Eu tenho algumas outras sugestões que podem nos ajudar a suceder mais no que tange ao software que desenvolvemos, ou pelo menos, poderemos falhar menos, por assim dizer.

*1) Evite desenvolver sistemas repetidos.0 Falando pela experiência que eu tenho aqui na empresa, acho que temos pelo menos uns 12 sistemas desenvolvidos com o objetivo de reservar salas de reuniões, sim, isso mesmo, reuniões são abundantes no meio corporativo. Mas por que raios eu preciso de 12 sistemas distintos que fazem a mesma coisa, talvez com customizações mínimas aqui ou ali, mas se fazem a mesma coisa é totalmente factível que esses 12 sistemas sejam reduzidos para 1 somente. Esse é apenas um exemplo, entre tantos outros que eu já vi.

2) Fuja das certificações. A não ser que exista uma razão extremamente primordial, pela qual a sua empresa precise de certificações, fuja extremamente delas. Elas vão engessar o seu trabalho, vão proliferar as políticas e padrões dentro da sua empresa, e é quase certo que elas farão a sua empresa gastar desnecessariamente, muito mais dinheiro do que deveria. Então, se aparecer algum consultor mirabolante, falando que a sua empresa de TI ou o seu setor de TI precisa de uma certificação CMMI, ISO 9000 ou qualquer outra, fuja completamente!

3) Esqueça a analogia de fábrica de software. Comparar a construção de um software, um produto abstrato com qualquer outro produto industrial tangível em que você consegue automatizar ou criar uma linha de montagem é a pior comparação possível nos tempos de hoje. Tratar o seu desenvolvedor como o trabalhador de uma fábrica é pior ainda, isso vai apenas desmotivá-lo e fazer com que o trabalho dele fique cada vez mais burocrático e mais lento.

4) Responda rapidamente à mudanças. A natureza do software é ser um produto volátil, os requisitos do software são volatéis, mudam muito rápido. Não tem como mudar isso. O cenário de tecnologia muda muito rápido, as coisas avançam numa velocidade incrível. Aceitar isso e moldar o seu setor de TI ou a sua empresa para responder a essas mudanças é a melhor coisa a se fazer. A não ser que você queira se fechar no seu mundinho pequeno e começar a se debater quando os seus projetos começarem a fracassar.

5) Olhe com atenção e, se possível, copie os bons exemplos das comunidades de software livre e das empresas web. Será que o Google se preocupa em usar UML nos seus projetos? Consegue imaginar o Twitter sendo feito através de um processo em cascata? Existem vários e vários exemplos de sistemas de grande sucesso nessas comunidades, e geralmente essas empresas conseguem a excelência no desenvolvimento de software. É claro que, num ambiente corporativo, muitas vezes você não conseguirá o nível de liberdade que essas empresas ou comunidades conseguem, mas ainda assim, conseguimos aproveitar alguma metodologia, alguma ferramenta, ou alguma outra forma de organização que lhe permita ter mais agilidade, mais responsividade para o produto que entregamos para nossos clientes.

Tim Bray, no final do seu artigo até propõe um experimento interessante. Tente imaginar na sua empresa que você vai solicitar à sua área de desenvolvimento de software que eles desenvolvam uma ferramenta semelhante ao Twitter, ou ao Basecamp, ou ao YouTube com todas as formalidades e processos que a sua empresa prega. Provavelmente chegará à conclusão que não será possível fazer, seria um tremendo fracasso.

Conclusão

A situação no mundo do software corporativo é alarmante. É como aquele paciente que está no CTI respirando por aparelhos, porém existe a perspectiva de melhoras. E cada um de nós, que faz parte desse ambiente, pode fazer algo para mudar, ou pelo menos tentar mudar. Mesmo que não tenhamos poder de decisão, podemos tentar convencer as pessoas que tem para que possamos promover melhorias significativas nesse quadro caótico.

Hoje eu trabalho com programação, mas não de jogos, e ainda tento entender como muita coisa funciona no mundo dos games. Portanto, este post serve para contar um pouco da minha história como um gamer inveterado.

Primeiro Videogame

Meu primeiro videogame foi um Atari 2600, lembro com grande saudosismo de tardes e mais tardes que gastei com meus primos jogando clássicos como River Raid, Enduro, Pitfall e muitos outros jogos de uma época em que tínhamos gráficos pobres e criatividade rica. Eram grandes disputas e grandes discussões para saber quem era o melhor e conseguir chegar ao "final" de jogos que muitas vezes nem tinham fim.

Lembro-me bem quando ia com meu pai ou minha mãe na Casa e Vídeo e ficava babando em cima da sessão de jogos quase implorando que meus pais comprassem ao menos um jogo para mim. Eu era feliz sem pirataria e não me dava conta :-) Outra forma de conseguir jogos naquele tempo era pegar emprestado com seus colegas ou parentes.

Hoje, de vez em quando, baixo alguns emuladores de Atari no computador apenas para relembrar essa época saudosa e os jogos que marcaram a minha introdução ao mundo dos games na infância.

Segundo Videogame

O Turbo Game era um clone do Nintendinho 8 bits (NES) fabricado pela CCE aqui no Brasil. A grande vantagem desse brinquedinho é que ele rodava os jogos japoneses e americanos, que vinham com chips de tamanhos diferentes. Outro videogame famoso nessa época era o Phantom System que tinha quase as mesmas características do Turbo Game.

Nessa época eu já tinha amigos na escola e começava a trocar jogos com eles, ou pegar emprestado. Nesse tempo, começaram a surgir também as locadoras de games que era a salvação para quem tinha pouca grana para comprar os jogos.

Alguns jogos que marcaram essa época foram Super Mario Bros 3, Double Dragon, 1942, Bomberman, Contra, o grande e dificílimo Battletoads, Skate Or Die e outros tantos que eu nem consigo mencionar agora.

E chega a era de 16 bits

É impressionante como a Nintendo dominou por MUITO tempo o mercado de games, que posteriormente teria o seu posto de primeiro lugar tomado pela Sony. Mas o Super Nintendo foi o console de videogame que eu mais joguei. Nessa época eu já estava no Segundo Grau (hoje Ensino Médio) e ainda mantinha o hábito saudável de trocar e alugar jogos para videogame. O controle do Super Nintendo era extremamente suave e fácil de ser utilizado, além de ter introduzido os botões L1 e R1 que melhoraram a jogabilidade significativamente.

Além disso, o Super Nintendo foi o primeiro console que tornou possível trazer franquias famosas das máquinas de fliperama para o nosso videogame doméstico. Jogos como Street Fighter II, Final Fight e Mortal Kombat apareceram no console e fizeram a alegria de vários gamers que como eu gastavam o seu suado dinheiro da mesada em fliperamas no bairro.

Um jogo que eu joguei demais nesse console foi Superstar Soccer. Lembro de disputas memoráveis com colegas de escola nesse jogo e lembro que poucos conseguiam jogar de igual para igual comigo nesse game. Começava nessa mesma época a surgir também os campeonatos de futebol no videogame e foi bem legal participar com os colegas nessa modalidade de jogo.

Jogando no PC

Depois de possuir um Super Nintendo, eu parei de jogar em consoles por um bom tempo e me dediquei a jogar apenas no PC. Foi então que conheci os RPG's e jogos de estratégia em tempo real que fizeram a minha alegria durante um bom tempo. O primeiro Resident Evil joguei no PC, jogos de corrida também eram bem legais de jogar no PC. Mas chegou um certo tempo que era muito chato ter de ficar instalando e desinstalando jogos no PC, formatar o PC MUITAS VEZES por causa dos jogos e então, como eu já tinha começado a trabalhar, resolvi voltar para os consoles. Isso nos leva a próxima fase da minha vida nos games.

Enfim, um Playstation 2

Comprei meu Playstation 2 quando quase todo mundo tinha um. Encomendei o meu pela Internet e fiquei numa angústia danada porque a loja não era muito conhecida e na época os Correios estavam em greve. O meu PS2 era desbloqueado e sim, nessa época eu virei um gamer pirata, todo mundo fazia isso, mas hoje eu não tenho muito orgulho disso na verdade. Não joguei tantos jogos assim no PS2, mas pude finalmente voltar a jogar o bom e velho futebol com a série Winning Eleven (e suas muitas modificações) e conheci um jogo que considero hoje uma das maiores obras-primas da história dos videogames, Metal Gear Solid 3. Revolucionário, inovador, fenomenal, esse jogo conseguiu me prender por um bom tempo na plataforma, e por fim, um dos últimos jogos que me prenderam no PS2 foi Final Fantasy XII, nunca tinha jogado nenhum jogo da série, mas gostei desse e fiquei entretido com ele durante um bom tempo.

Chegamos na era atual

Atualmente sou um homem casado, aliás MUITO bem casado, e possuo basicamente 2 fontes de entretenimento com jogos em casa. Um iPod Touch e depois de negociar com a minha esposa (obrigado amor!), tenho hoje um PS3, e um dos primeiros jogos que fiz questão de ter no PS3 foi Metal Gear Solid 4 e depois adquiri Fifa 10, pois agora Fifa superou a série Winning Eleven/PES como melhor franquia de futebol do mundo dos games. Não sou mais um gamer pirata e sou feliz assim.

Bom, é isso. Fiz esse post mais para guardar como uma memória da minha jornada através de vários consoles até chegar ao ponto em que estamos hoje. Tive a oportunidade de jogar diversos consoles e cada um deles marcou de certa forma, a vida desse que vos fala. É difícil explicar para quem não joga, o fascínio que os videogames causam nas pessoas.

Enfim, quem ler esse post, poste quais consoles já teve e o que o faz ser fascinado por games.

Referências:

Casado Que Joga

100 Melhores Jogos de NES para Jogar Online

7 Gerações de Consoles explicadas

Para contextualizar, já que microgerente não é um termo muito usado aqui no Brasil, microgerente é aquele sujeito que controla obsessivamente os seus subordinados, até mesmo nas tarefas mais pequenas. Eu pedi autorização ao Scott para traduzir o seu texto e publicar aqui no blog. Autorização concedida, segue o texto traduzido.

Prezado microgerente:

Donos de cavalos puro-sangue nunca param seus cavalos durante uma corrida, a cada 10 segundos, para lembrar ao cavalo e ao jockey como eles devem correr, onde está a linha de chegada, ou para dizer quão boa é a idéia de chegar em primeiro. Por que? Porque isso os deixaria muito mais lentos. Apenas um idiota faria isso.

Se você é um gerente, você deve assumir que tem cavalos puro-sangue trabalhando para você. O seu trabalho é dar a eles o que precisam para vencer suas corridas, acordando com eles prazos e premiações, porém, tirando todos os obstáculos do caminho. A não ser que eles comecem a pular cercas ou atacar outros cavalos, você deve deixá-los correr para vencer.

Mesmo que você seja 30% melhor do que alguém que trabalha para você em determinada tarefa, o tempo que toma ficar de olho na sua equipe de hora em hora e solicitar aprovações para decisões triviais custam muito mais em perda de ânimo, paixão pelo trabalho e destruição do respeito próprio dentro de sua equipe do que os 30% que você pensa estar contribuindo. Ninguém consegue trabalhar bem sentindo que está sendo tratado como uma criança idiota. Ter 2 pessoas envolvidas em um trabalho que requer apenas uma é perda de tempo, para todos.

Talvez você não pense que está gerenciando cavalos puro-sangue e que esses precisam de muita ajuda.

Isso é possível.

Mas se você é de fato um microgerente, você começou a se exceder no dia em que começou a gerenciar. Você não tem idéia do potencial das pessoas que trabalham para você. É grande a probabilidade de você estar tratando, pelo menos, um potencial Seabiscuit como se ele fosse um pônei de brinquedo em um conto medieval.

Um saudável, confiante e bem ajustado gerente sabe que o seu trabalho envolve fazer 3 coisas:

1. Contratar cavalos puro-sangue, indicar a linha de chegada e sair do caminho deles a não ser que peçam ajuda.

2. Treinar, ensinar, encorajar e posicionar cavalos extraordinários para maximizar o potencial e aproximá-los ao menos em parte do seu trabalho.

3. Demitir aqueles que nunca conseguem fazer o trabalho necessário sem o seu constante envolvimento para criar espaço para aqueles que conseguem trabalhar bem.

Se você não fizer essas coisas, o fardo do fracasso está sobre você. Bons gerentes atingem todos as três atividades mencionadas acima. Gestores medíocres, ao menos, estão trabalhando para bons objetivos. Entretanto, maus gerentes estão excessivamente distraídos por seus próprios egos, contracheques ou insegurança para reconhecer o quão auto-destrutivos são.

Um fácil teste de gerenciamento é deixar que a sua equipe saiba o quão confiante você é na habilidade que eles tem de realizar o trabalho e oferecer, caso eles queiram, que você esteja cada vez menos envolvido no seu trabalho do dia-a-dia para que eles tenham mais espaço para produzir. Diga-lhes que você está disponível se eles precisarem de você, mas caso contrário, você vai colocar a sua atenção em outro lugar. Veja o que acontece. Segure a sua língua. Não solicite a revisão daquele email. Não insista em regular quem se reúne com quem. Tome um pequeno passo atrás e veja o que acontece.

Existe uma enorme probabilidade de que o mundo não vai acabar. Seus melhores empregados serão mais felizes e mais produtivos, dando a você uma nova energia para investir no restante do seu trabalho ou até mesmo para que em determinados dias você possa ir embora para casa mais cedo. Algumas pessoas de sua equipe vão te surpreender e prosperar com mais autonomia. E para aqueles que não conseguem melhorar ou cometem erros, você não saiu perdendo, pois ainda pode voltar atrás e dar atenção onde é realmente necessário.

Se você estiver temeroso de tentar isso e tem uma lista de desculpas para dizer que isso é uma má idéia, a única coisa que está gerenciando realmente é o seu ego. Porém, você está com medo de admitir que as pessoas podem funcionar muito bem sem a sua aprovação ou intromissão em cada pequena coisa estúpida. Ou, pode ser que você seja uma prova viva do Princípio de Peter, e seria mais feliz e mais útil se parasse de gerenciar e começasse a trabalhar sozinho. Um salário maior não é um troca saudável pois faz você mesmo e sua equipe infelizes.

Bons gerentes são corajosos e confiantes, confiam nas pessoas que gerenciam. Eles querem amadurecer a sua habilidade de julgar e aumentar as suas habilidades, preferindo errar por excesso de confiança do que por confiar pouco. Eles têm prazer em se soltar e dar poder à sua equipe, aceitando que quando alguém que trabalha para eles brilha, eles brilham muito.

No entanto, se você não gosta dessas coisas e luta para confiar em sua equipe, ou não suporta ver uma decisão tomada ou um prêmio ganho sem o seu nome sobre ele, você deve parar de gerenciar pessoas. Você, e todos que trabalham para você serão mais felizes se fizer isso.

Beijos e abraços,

Assinado,

- As pessoas que você está microgerenciando.

Texto original

O que significa liberdade? Charles de Montesquieu tem a sua própria definição: "A liberdade consiste em fazer tudo o que se deve querer e em jamais ser coagido a fazer o que não se deve querer". A Internet trouxe um grande ganho de liberdade para as pessoas, como alguns costumam dizer, "não há liberdade sem conhecimento", e uma das principais propostas da web é tornar disponível a maior quantidade de conhecimento possível para a maior quantidade de pessoas que se consiga alcançar com a tecnologia.

Mas parece que alguns governos e grandes empresas ainda não entenderam isso, querem proibir downloads, pesquisas e em alguns casos partem para a censura explícita e descabida. No entanto, no meio desse mar de ignorância, aparece um caso que me fez ainda ter esperança na liberdade de expressão, e algo que pode fazer as pessoas pensarem um pouco sobre como tratamos a liberdade alheia.

Mark Pilgrim é um conhecido programador e também é escritor. Sua maior obra é o livro Dive Into Python. Esse livro, sobre a linguagem de programação Python, já vendeu muitas cópias no mundo inteiro e inclusive ganhou uma versão em português com tradução de qualidade duvidosa chamada Megulhando no Python, mas isso não vem ao caso.

O interessante dessa história é que ontem Mark relatou em seu blog que outra pessoa simplesmente pegou o seu livro e começou a distribuí-lo por conta própria sem a autorização de sua editora, a Apress. Ele conta que isso causou um alvoroço dentro da editora e no meio da confusão, os executivos descobriram que juridicamente não poderiam fazer nada contra isso. O que acontece é que o livro foi publicado sob uma licença chamada GNU Free Documentation License que dá o direito a qualquer pessoa de publicar e distribuir o livro, bastando para isso, ter os recursos para fazê-lo, haja visto que não é tarefa trivial distribuir um livro, seja ele qual for. Inclusive o livro em questão está disponível na íntegra online para quem quiser acessar e ler. Assim sendo, os executivos da empresa nada podiam fazer, pois não tinham recursos legais para isso.

O que mais me chamou a atenção, foi a opinião do próprio Mark sobre o assunto, em tese ele deveria se sentir mais ofendido com essa situação, como é praxe vermos acontecer em casos como esse, mas ele mesmo escreveu o seguinte.

I enjoy working with publishers because it makes me a better writer. But I don’t write for money; I write for love (or passion, or whatever you want to call it). I choose open content licenses because this is the way I want the world to work, and the only way to change the world is to change yourself first.

Ao invés de censura, frustração, palavras duras ou qualquer outra coisa, vemos aqui uma pessoa contente por sua obra ser reconhecida e estar aberta a todas as pessoas. Ele conclui o seu ponto de vista com as palavras abaixo.

So I am grateful for this anonymous soul who woke up one day and said to herself, “You know what I should do today? I should try to sell copies of that Free book that Pilgrim wrote.” Grateful, because it afforded me the opportunity to remind myself why I chose a Free license in the first place. My Zen teacher once told me that, when people try to do you harm, you should thank them for giving you the opportunity to forgive them. In this case it’s even simpler, because there’s nothing to forgive, just explain. She’s redistributing the work that I explicitly made redistributable. She’s kind of the point.

Obrigado Mark, quem sabe um dia faremos o mundo entender que as coisas mudaram, que o conceito de liberdade está cada vez mais amplo e que todos precisam ter acesso ao conhecimento, afinal de contas, liberdade é conhecimento, não é mesmo?

Tudo começou quando o Joel Spolsky escreveu um artigo em seu blog intitulado The Duct Tape Programmer. E aí a coisa começou a se espalhar, uns gostaram, outros nem tanto. Mas o curioso foi ver a quantidade de blogs que imediatamente levantaram o dedo para dizer como o Joel estava errado, como a comparação era exagerada, como o conceito era falho.

Pelamordedeus! Vamos parar com essa coisa de querermos sempre rotular tudo como certo e errado, poucas coisas na vida são certas e erradas, preto no branco, claro e escuro ou seja lá que comparação você preferir. O segredo é buscar o equilíbrio. E quando falamos em desenvolvimento de software, programação, isso se torna ainda mais verdade. Pouquíssimas coisas estão no terreno do certo e errado, na maioria das vezes, você precisa usar o bom senso (coisa rara hoje em dia) para escolher a forma de trabalho mais apropriada, a tecnologia mais apropriada ou a ferramenta de trabalho mais apropriada.

Assim sendo, ao invés de gastar energia criticando o artigo, vamos pegar a idéia principal e ver como isso pode melhorar a nossa vida, a forma como trabalhamos, para ver se conseguimos fazer melhor o nosso trabalho que é desenvolver software.

Analisando o artigo

No artigo mencionado no início desse post, quando Joel fala sobre o termo "duct tape programmer" ou, numa tradução livre, "programador fita adesiva", faz referência ao livro Coders at Work, que é uma coletânea de entrevistas com programadores experientes e seus respectivos trabalhos.

Nesse livro Joel encontrou a entrevista de Jamie Zawinsky, um dos desenvolvedores do navegador Netscape, e descreveu a Jamie como um "programador fita adesiva". Vejam a definição:

He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.

Sim, a idéia principal exposta aqui é simples: o programador fita adesiva está mais interessado em resolver o problema, em entregar o produto, ao invés de se preocupar em adicionar complexidade em cima de complexidade em cima de complexidade (atenção Java, eu estou olhando para você!).

And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

Sim, para que tenhamos agilidade é necessário aprendermos a dizer "Não!". Não para a complexidade desnecessária, não para funcionalidades que não agregam valor, não para ferramentas que possuem uma curva de aprendizado enorme e que no final agregam pouco ou nenhum valor ao seu trabalho. Foco no principal, foco no que vai resolver o meu problema ou o problema do meu cliente. Esse parágrafo do artigo diz tudo:

Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.” “Yeah,” he says, “At the end of the day, ship the fu**ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

Preciso reforçar essa última frase: não estamos aqui para escrever código, estamos aqui para entregar produtos. Sim, é para isso que somos pagos e essa deve ser a nossa principal preocupação, entregar produtos de qualidade para nossos clientes.

Concluindo

É claro que não devemos pegar esse conceito e tratá-lo como verdade absoluta, está longe disso. Repito mais uma vez, assim como tudo na vida, precisamos analisar isso com equilíbrio. Não adianta entregarmos o produto no prazo, sendo que o mesmo está cheio de erros e com a estrutura comprometida.

Da mesma forma como uma fita adesiva nem sempre resolverá o seu problema e talvez seja necessário usar algo que seja mais complicado, porém mais duradouro, no desenvolvimento de software precisamos realmente avaliar quando resolver os nossos problemas com a solução mais simples possível ou então usar algo um pouco ou muito mais complexo mas que nos trará ganhos maiores e mais duradouros no futuro.

Ficamos muito empolgados com a metodologia, porém, o espaço físico onde trabalhamos não possibilita usarmos as principais ferramentas de Scrum (quadro branco, papel, caneta e post-it). Sendo assim, comecei a pesquisar  algumas ferramentas para uso de Scrum que poderiam ser aplicadas em nossa equipe e nas práticas ágeis que pretendemos adotar.

Escrevi então esse post para listar aqui o resultado prévio dessa pesquisa. Apenas um disclaimer, nossa equipe ainda não adota o Scrum plenamente, nossa idéia é adotar de forma incremental algumas práticas dessa metodologia para que possamos melhorar a maneira como desenvolvemos software. Agora vamos deixar o blá-blá-blá de lado e vamos dar uma olhada nas ferramentas.

Começaremos com uma ferramenta que preza pela simplicidade e pela facilidade de uso, e eu sou um fã da simplicidade.

Para criar um projeto no Scrumy basta digitar no seu browser a url: http://scrumy.com/<nome do projeto> e você já terá o seu espaço criado. Além disso, o que a ferramenta basicamente provê é a criação das user stories e o acompanhamento delas através do painel de tarefas (taskboard). Existe ainda uma versão para chamada Scrumy Pro que lhe permite coordenar múltiplos sprints e múltiplos backlogs, além de prover burndown charts.

Assim como o Scrumy, Pango Scrum também é uma ferramenta online, porém muito mais completa. Auxilia em quase todas as atividades principais do Scrum como Product Backlog, Sprint Backlog, agendamento de eventos e planejamento de sprints. A ferramenta não disponibiliza a funcionalidade para criação de painel de tarefas pois eles pregam que isso deva ser realmente feito na base do papel e post-it. O Pango Scrum é gratuito e assim como muitas outras ferramentas da Web 2.0, está "em fase beta".

Essa talvez seja a melhor das ferramentas que estão aqui listadas, afinal de contas, foi criada pela empresa de um dos maiores evangelizadores de metodologias ágeis, Martin Fowler.

Essa ferramenta possui tudo o que podemos esperar de uma boa ferramenta de Scrum, e melhor ainda, tudo muito bem implementado e com uma usabilidade visível desde o primeiro contato. Além das funcionalidades esperadas, a ferramenta provê um wiki integrado, alertas por e-mail, feeds RSS e muito mais. Porém, como era de se esperar para uma ferramenta desse nível, ela é paga e de acordo com
a tabela de preços, não é barata.

Essa é uma ferramenta muito bem comentada pela web. Possui duas versões, Basic (gratuita) e Pro (obviamente paga). Diferentemente das ferramentas expostas acima, essa ferramenta não roda online e precisa ser instalada. ScrumWorks, depois de instalado, consiste em 2 programas, um servidor e um cliente. O servidor é para ser usado pelo Scrum Master, é onde se realiza todas as tarefas de planejamento do Scrum. A parte cliente é direcionada aos membros da equipe para que possam receber a atualização das tarefas.

Testei rapidamente, e me parece ser uma ferramenta muito boa, apesar de carecer de uma interface mais intuitiva como as outras ferramentas já citadas. A vantagem dessa ferramenta é que ela parece ter um nível de customização bem interessante para equipes que estão continuamente melhorando o seu processo de desenvolvimento.

Chegamos na última ferramenta desse post e da única que é open source. IceScrum está na versão 2. É uma ferramenta bem completa que tem todas as funcionalidades que eu já mencionei nesse post como Product Backlog, Sprint Backlog, planejamento de release, funcionalidades para todos os papéis do Scrum, auxílio ao planning poker, gráficos diversos e muito mais.

A ferramenta parece ter sido muito bem implementada e parece estar em constante evolução. Vale a conferida para quem está interessada em uma ferramenta sem custos de aquisição e que pode agregar bastante valor ao processo de sua equipe de desenvolvimento.

Concluindo...

Gostei muito de todas as ferramentas expostas acima, desde a mais simples até a mais completa. Procurarei olhá-las novamente com mais profundidade e particularmente, vou testar mais de perto IceScrum e Scrumy.

Espero ter ajudado a alguém que assim como eu, tem sempre procurado melhorar o desempenho da sua equipe no que tange a desenvolver software melhor. Como sempre, os comentários estão abertos para dúvidas, críticas, novas sugestões e o que mais quiserem colocar ali.

Atualização: 18 de Agosto de 2011

Essa ferramenta merece uma menção honrosa, pois é a única ferramenta nacional que está ganhando mercado na área de desenvolvimento ágil. Não tive oportunidade de testá-la ainda, mas à primeira vista parece ser uma ferramenta muito boa.

Scrum Half foi desenvolvida pela GPE, uma empresa brasileira com foco em gestão ágil de projetos. Uma das vantagens que percebi na ferramenta, além da mais óbvias que é o idioma, é o fato de ser online e assim, não precisar de instalação. Vale muito a pena dar uma conferida, para quem tiver interesse, a ferramenta é gratuita para uso de até 3 pessoas, mais do que isso, tem uma tabela de preços que pode ser consultada.

Links relacionados:

Stack Overflow: Best Scrum Tools http://stackoverflow.com/questions/35760/best-scrum-tools

All Product Backlog and User Story Management Tools for Agile and Scrum Projects http://www.userstories.com/products