Para começar o post, segue esta história sobre gerenciamento que vi no blog do Gustavo Ribeiro:

Todos os dias, uma formiga chegava cedinho ao escritório e pegava duro no trabalho. A formiga era produtiva e feliz. O gerente marimbondo estranhou a formiga trabalhar sem supervisão. Se ela era produtiva sem supervisão, seria ainda mais se fosse supervisionada.

E colocou uma barata, que preparava belíssimos relatórios e tinha muita experiência, como supervisora. A primeira preocupação da barata foi a de padronizar o horário de entrada e saída da formiga.

Logo, a barata precisou de uma secretária para ajudar a preparar os relatórios e contratou também uma aranha para organizar os arquivos e controlar as ligações telefônicas.

O marimbondo ficou encantado com os relatórios da barata e pediu também gráficos com indicadores e análise das tendências que eram mostradas em reuniões.

A barata, então, contratou uma mosca, e comprou um computador com impressora colorida. Logo, a formiga produtiva e feliz, começou a se lamentar de toda aquela movimentação de papéis e reuniões!
O marimbondo concluiu que era o momento de criar a função de gestor para a área onde a formiga produtiva e feliz, trabalhava. O cargo foi dado a uma cigarra, que mandou colocar carpete no seu escritório e comprar uma cadeira especial.

A nova gestora cigarra logo precisou de um computador e de uma assistente (sua assistente na empresa anterior) para ajudá-la a preparar um plano estratégico de melhorias e um controle do orçamento para a área onde trabalhava a formiga, que já não cantarolava mais e cada dia se tornava mais chateada.

A cigarra, então, convenceu o gerente marimbondo, que era preciso fazer um estudo de clima. Mas, o marimbondo, ao rever as cifras, se deu conta de que a unidade na qual a formiga trabalhava já não rendia como antes e contratou a coruja, uma prestigiada consultora, muito famosa, para que fizesse um diagnóstico da situação. A coruja permaneceu três meses nos escritórios e emitiu um volumoso relatório, com vários volumes que concluía: “Há muita gente nesta empresa!”

Então o marimbondo mandou demitir a formiga porque ela andava muito desmotivada e aborrecida.

Então lembrei de uma imagem que ilustra perfeitamente esta fábula e retrata fielmente a “organização” de alguma empresas:

Dividir para conquistar: você está fazendo isso errado!

Quando uma startup passa a vender mais e ter uma procura maior por seus produtos/serviços (o que é bom), uma reação comum da “cúpula” é aumentar o quadro de funcionários visando atender a demanda. Logo surgem os problemas com a organização do pessoal e/ou fluxo de trabalho. A solução mais simplista (e óbvia) é a especialização: fulano faz isso, ciclano faz aquilo, e beltrano gerencia. Logo controles são criados, fluxos validados, centros de custo, documentos, reuniões, atas, comitês, gestão de pessoas e relacionamento, terceirização, cargos, departamentos… e nasce o monstro da burocracia, aka “enterprise”.

Com essa especialização, cada “módulo” (também conhecido como departamento) começa a perder o foco no GRANDE objetivo da empresa e passa a defender apenas seus interesses – a famosa MISSÃO da empresa passa a ser coadjuvante. O resultado? A empresa dobra ou triplica seu quadro de funcionários e na maioria dos casos, seu lucro bruto. Porém agora tem mais despesas com pessoal e gastos extras para manter esse novo modelo “enterprise”. Trocando em miúdos, continua na mesma!

Onde está o erro? Mais uma vez o FOCO está na solução ao invés de PROBLEMA. Se você ler meus posts anteriores vai ver que este é um tema recorrente. Então por que as empresas continuam fazendo as coisas erradas e cometendo os mesmos erros?

Idéias criativas surgem das pessoas diretamente relacionadas com os problemas e não de diretores, contadores, gestores, etc. Esse modelo “enterprise” é um overhead organizacional que só gera ruído e desperdício!

A solução é adotar agile!

SOLUÇÃO!? Mas qual era o PROBLEMA mesmo!? Sim, mais uma vez o foco é a solução ao invés do problema.

Como eu disse nos posts anteriores, acreditar que uma mudança drástica do processo pode mudar a cultura da empresa e pincipalmente as pessoas é o maior erro na adoção de metodologias ágeis. Mudam o processo mas não mudam as pessoas.

De uma forma simples e direta, agile resume-se a quatro valores:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Ou seja, pessoas, software, colaboração e feedback. Simples assim!

O manifesto ágil não cita nada sobre “enterprise”, sobre a implementação. Este é o grande desafio em sua adoção. Como seguir estes valores sem burocratizar e engessar o processo? Como criar uma relação de colaboração com os clientes? Como responder rapidamente a mudanças? Como eliminar o esforço que não agrega valor ao produto e/ou empresa? Como evitar politicagem?

Mantenha-se pequeno!

Otimize! Busque soluções para os problemas que impedem de produzir mais e com mais qualidade. Faça MAIS com MENOS. Foque no O QUE ao invés do COMO. Escale as pessoas verticalmente!

Inove! Não espere conseguir resultados diferentes fazendo sempre a mesma coisa. Busque novidades, opniões, experiências. Ouça seus funcionários, seus clientes. Estude, pesquise, arrisque, erre, acerte… continuamente.

Mantenha o foco! Tenha um GRANDE e único objetivo e certifique-se que todos acreditem nesta filosofia. É importante que todos comprem a idéia e o modus operandis.

Finalizando, este é apenas meu ponto de vista, baseado na minha experiência em diversas empresas grandes e pequenas, vivenciando problemas, errando muito e principalmente aprendendo com os erros dos outros. Agilidade pode funcionar bem em grandes corporações, desde que haja foco e que todos comprem a idéia. Você pode concordar ou não.

Estamos de volta depois de algumas semanas de correria e muito trabalho, o que nos impediu de postar sobre vários assuntos atuais e experiências recentes. Também migramos de empresa. Agora o Roger e eu estamos trabalhando em uma empresa maior, focada em conteúdo digital, desenvolvendo aplicações de grande porte com Ruby e Rails

O evento

Se você não soube do Rails Summit 2009 ou não sabe nem o que é Rails recomendo que acesse este site. Deixando o sarcasmo de lado, a edição 2009 do Rails Summit foi muito boa. As palestras foram excelentes (com algumas poucas exceções). Os coffe-breaks e as locagirls também!

Quem não conseguiu ir este ano pode conferir o que aconteceu e assistir a algumas palestras nos seguintes links:

http://akitaonrails.com/2009/10/17/rails-summit-2009-retrospectiva

http://andrefaria.com/2009/10/15/rails-summit-2009-chad-fowler/

http://andrefaria.com/2009/10/19/rails-summit-gregg-pollack/

http://marciotrindade.com/2009/10/13/rails-summit-2009-parte-1

http://marciotrindade.com/2009/10/14/rails-summit-2009-parte-2

http://marciotrindade.com/2009/10/16/rails-summit-2009-parte-3

Rails não escala

Das palestras técnicas, focadas em Ruby e Rails, destaco a do Gregg Pollac: On The Edge of Rails Performance, que falou sobre algumas ferramentas e plugins para ajudar a melhorar a performance de aplicações Rails.

O estreiante Pratik Naik também deu algumas dicas muito boas para melhoar a performance e falou um bouco sobre suas experiências com Rails.

Para finalizar, o Bruno Miranda fechou falando sobre sua experiência com o desenvolvimento do Cyloop, uma rede social de música, mostrando os problemas enfrentados com escalabilidade e as estratégias utilizadas para resolvê-los.

E claro que não podia deixar de falar da excelente palestra do Fábio Kung sobre metaprogramação com Ruby, apresentando um hands-on, ou seja, <faustao>quem sabe faz ao vivo</faustao>, para criar uma DSL em Ruby e outras técnicas de magia negra como Callbacks, que pretendo abordar com mais detalhes aqui no blog.

Resumindo, projetar aplicações Rails escaláveis não é uma tarefa trivial e deve ser pensada com muito cuidado. Pretendo explorar mais este assunto nos próximos posts do blog.

Agilidade a seu favor

Apesar de ser um evento sobre Rails, um tema predominante foi agile. A largada foi dada pelo Chad Fowler que falou sobre a insurgência Ruby on Rails, incentivando o movimento ágil a “quebrar as regras”, parar de fazer as coisas que sabemos que estão erradas! Também ressaltou que é preciso ter coragem e atitude para rejeitar os moldes corporativos e lutar contra os trolls, os guardiões da cascata.

O Akita realmente surpreendeu com sua palestra “Agile, beyond chaos”. Explicou os princípios do manifesto ágil e comprovou cientificamente o “porque” agile funciona!

A palestra sobre empreendedorismo do Vinícius Teles foi uma verdadeira aula, contando um pouco da sua história, as dificuldades e obstáculos superados até conseguir transformar o Be on the Net em realidade. Resumindo: ganhe dinheiro fazendo o que você gosta e ajudando as outras pessoas a ganhar dinheiro!

Finalizando com chave de ouro, o Obie Fernandez falou sobre a “arte” do desenvolvimento de aplicações. Assim como um artista que precisa praticar muito para atingir a excelência, um programador precisa praticar e codificar muito… “O que você está esperando? Fuck the enterprise!”

Resumindo, falou-se muito sobre agilidade usando ruby e rails como uma ferramenta pragmática. As empresas de software sérias já estão usando Ruby. É a linguagem ideal para o modelo ágil.

Comentários do Roger

Tomei a liberdade de adicionar uma nota neste post do Panachi, pois como participante do Rails Summit 2008, resumidamente notei três coisas do evento:

• A infra estrutura do evento estava muito melhor, mais espaço, mais organização e sem o calor infernal do ano passado. Parabéns para o Akita e o pessoal da Locaweb pelo ótimo trabalho e evento mais uma vez!
• Tivemos ótimas palestras técnicas sobre como melhorar a performance de aplicações Ruby!
• Em 2008 a grande mensagem foi “Participe!”. Ficou bem claro a importância de participar de projetos e contribuir. Este ano, a grande mensagem foi “Fuck the Enterprise!“.

Pretendo neste post falar um pouco da minha evolução na programação e como Ruby e Rails agregaram mais conhecimento e me tornaram um melhor desenvolvedor.

A gente se forma na faculdade e de repente estamos trabalhando como programador em alguma empresa de software. A primeira coisa que você vai concluir é que nada a maioria das coisas que foram ensinadas na faculdade não se aplicam na vida real. Triste realidade…

Mas como um bom programador (que você é) logo começará a se questionar e se interessar por novos assuntos, aprender novos conceitos e técnicas de programação, pois você não se sentirá confortável fazendo as mesmas tarefas repetitivas ou que não sejam otimizadas.

Orientação a objetos

Nada de cachorrinhos ou pessoas com ações como andar, comer, etc. No mundo real, seus problemas são faturas, notas fiscais, relatórios, importadores de arquivos, planilhas… e por aí vai. Seu primeiro desafio será de entender a orientação a objetos de verdade. Mas não se preocupe se isto demorar um pouco pois logo a “lâmpada” acenderá e tudo ficará claro como o dia.

Linguagem e frameworks

Agora você consegue modelar os objetos da sua aplicação mas se depara com assuntos técnicos que podem ser solucionados prontamente utilizando-se frameworks e alguns recursos avançados da linguagem em questão. Logo você estará visitando os sites da documentação do Struts, do Hibernate, do Ant… e descobrirá que o nome Apache, além de tribo indígena, é muito mais do que um servidor Web. Após muitas provas de conceito e algumas noites sem dormir, você será um programador muito produtivo e confiante.

Análise e documentação

Parabéns! Aqui você já pode ser considerado um desenvolvedor. Logo seu destaque na equipe será recompensado com mais trabalho de corno desafiador. Nesta fase sua empresa se parece com uma padaria: “Me vê meio quilo do relatório X”, “Faz dois webservices pra viagem!”, “Aí, saindo uma fornada de casos de uso…”, etc. Logo alguém tem a brilhante idéia de “documentar” tudo desde uma simples alteração no CSS do sistema até complexos e numerosos diagramas e notações daquele novo sistema para integração. No começo a novidade até parece ser uma boa idéia, mas logo você vai descobrir que o que realmente importa é ouvir os problemas dos clientes.

Testes

Se você não teve a sorte de ser orientado desde o começo da sua carreira sobre desenvolvimento guiado por testes, você aprende a importância de testes da melhor maneira possível: tomando na cabeça! Os problemas começam a ficar mais claros. Você fica mais focado na tarefa que está desempenhando e felizmente também cresce profissionalmente com este aprendizado. Você se pergunta como conseguia desenvolver sem testes e por que a linguagem que você utiliza não tem um suporte mais “nativo” a testes.

Metodologia

No decorrer da sua experiência você tentará desempenhar suas atividades de várias maneiras. Quando você faz de tudo um pouco acha que o melhor seria fazer apenas uma tarefa específica mas depois descobre que estava enganado. Neste ponto você provavelmente já experimentou pelo menos duas metodologias de desenvolvimento e saberá identificar as vantagens e desvantagens em cada uma.

Agilidade

Felizmente sua experiência o guia para um caminho mais ágil. Após aprender e aplicar os mandamentos do manifesto ágil e aprimorar seus conceitos e habilidades técnicas, desenvolver aplicações torna-se uma tarefa “natural” que você desempenha com fluência independente da linguagem ou tecnologia utilizada. Suas maiores conquistas se resumem em conseguir contornar um problema tecnológico ou limitação da linguagem, negociar o escopo do projeto com o cliente, implementar a maior cobertura de testes possíveis, automatizar processos durante o desenvolvimento, etc.

Neste ponto você começa a se questionar: o que devo fazer agora para evoluir profissionalmente?

Ruby!

Eis que você conhece Ruby e Rails. A linguagem parece estranha a primeira vista mas após algum tempo dedicado e muito estudo você descobre que é uma ferramenta muito poderosa e produtiva, onde você pode “fluir” com seu desenvolvimento. Você pensa no que quer fazer e faz! Escreve sua “feature”, implementa e roda! Simples e divertido!

Ruby e Rails vieram suprir uma necessidade e/ou carência dos desenvolvedores por simplicidade. Até seu surgimento, desenvolver aplicações nas linguagens populares do mercado era uma tarefa complicada e trabalhosa. Ruby é uma linguagem poderosa. Rails é simples e muito produtivo. Combinação perfeita!

O que você tá esperando? Comece agora mesmo a estudar Ruby e Rails e seja feliz!

UPDATE: para não causar confusão, alterei o título. Lembre-se: Ruby é linguagem e Rails é framework!

Paginação é um recurso simples e indispensável em qualquer aplicação séria. Em se tratando de Rails, a solução mais popular é a gem WillPaginate que basicamente adiciona o método “paginate_” aos models do ActiveRecord e fornece um helper para renderização dos links da paginação nas views.

Instalando a gem:

sudo gem install will_paginate

Para utilizar na aplicação, adicione no final do config/environment.rb:

require 'will_paginate'

Altere o controller para utilizar paginação:

def index
  @posts = Post.paginate :all, :page => params[:page], :per_page => 10
end

E adicione os links da paginação na view:

<%= will_paginate @posts %>

Pronto! Ao clicar nos links da paginação o parâmetro “page” será incluído automaticamente na requisição.

Legal, mas cadê o “ajax”?

Por padrão o WillPaginate não se preocupa com isso. O próprio desenvolvedor recomenda usar javascript para interceptar o “click” dos links e renderizar o resultado na mesma página.

Outra alternativa seria estender a classe responsável por renderizar os links da paginação para utilizar requisições com ajax.

Inclua em app/helpers o arquivo ajax_will_paginate.rb com o código:

class AjaxWillPaginate < WillPaginate::LinkRenderer
  def prepare(collection, options, template)
    @update = options[:update]
    super
  end
  protected
  def page_link(page, text, attributes = {})
    @template.link_to_remote(text, {
      :url     => url_for(page),
      :method  => :get,
      :update => @update
    })
  end
end

Então adicione no final do arquivo config/environment.rb:

  WillPaginate::ViewHelpers.pagination_options[:renderer] = 'AjaxWillPaginate'

E altere a chamada do helper na view para:

<%= will_paginate @posts, :update => 'div_principal' %>

Informe na opção :update o Id de um objeto html que contenha todo o conteúdo da paginação que será substituído nas requisições seguintes.

É importante lembrar que esta solução altera o comportamento de todos os helpers de paginação da aplicação, por isso deve ser utilizada com cautela. Outras soluções parecidas podem ser encontradas aqui.

Rufus é um conjunto de gems utilizado para Workflow e BPM. O rufus-scheduler é a gem responsável pelo agendamento e execução de tarefas (jobs). Se você programa em Java e conhece o Quartz não vai ter dificuldade em utilizá-la.

Instalação:

sudo gem install rufus-scheduler

Utilização:

require 'rubygems'
require 'rufus/scheduler'

scheduler = Rufus::Scheduler.start_new

scheduler.every '5m' do
  puts 'Executando a cada 5 minutos'
end

scheduler.schedule '0 18 * * *' do
  puts 'Executando todos os dias as 18h'
end

Simples assim! Consulte a documentação oficial ou contribua com o código.

Nos últimos anos o mercado de TI cresceu exponencialmente. Surgiram desde pequenas empresas especializadas em construir websites até monstruosas fábricas de software com seus contratos milionários. Algumas com orçamento limitado outras com dinheiro jorrando pelos canos. Umas com problemas por falta de organização outras com problemas burocráticos. Bons profissionais vs. equipes de sobrinhos, habilidade técnica contra enxurradas de documentos… muito fracasso, pouco sucesso.

A meta é coletar as moedas até conseguirmos uma estrela

Surgiram muitas empresas especializadas em desenvolver software ou que têm um software como produto principal. Normalmente, essas empresas se preocupam apenas em satisfazer os investidores e se esquecem dos clientes. Focam em vender e deixam a qualidade de lado. Prezam pela imagem e ignoram os problemas.

É uma triste realidade que essas empresas tenham mais executivos do que programadores. Como diz o Luli Radfahrer, executivos são aqueles seres que se vestem com um pensamento fracassado, usam uma linguagem própria sendo uma mistura de termos que só eles entendem e 20% de palavras em inglês… não vivem os problemas reais da empresa. É como se estivessem em outro mundo: Mario World!

O mundo dos executivos: nuvens sorrindo

A maioria das empresas que têm problemas com desenvolvimento de software ainda estão vivendo na década de 90. Internet ainda é uma palavra assustadora. Programador é apenas um funcionário que sabe o que significam siglas de informática e sabem mexer no computador. Mudança ainda é encarada como algo arriscado, que deve ser planejado, estudado e aprovado pelo presidente, diretoria e gestores. A palavra da vez é processo e seu fiel companheiro é prazo. A burocracia é uma amiga que garante que as coisas não fujam de controle. Nesse cenário não há como fugir do waterfall.

O maior problema do waterfall são os papéis: cada um com sua “especialidade”. Alguém determina que um infeliz funcionário vai ser responsável por “levantar requisitos”. Faz um cursinho de UML e começa a escrever uma quantidade sem fim de Casos de Uso sem ter noção alguma do que seu trabalho afeta no processo. Então a “equipe” começa a ter muito “retrabalho”, uma vez que os clientes não estão satisfeitos com o que está sendo entregue. Logo percebem que devem fazer o “levantamento” mais detalhado e passam a engessar ainda mais o processo com reuniões, assinaturas, etc. Conclusão: tempo e dinheiro desperdiçados e nenhum resultado satisfatório.

Meu trabalho é digitar 4 8 15 16 23 42 a cada 108 segundos

Falta de foco? Profissionais não qualificados? Processo falho? Não apenas isso: não há comunicação, não há troca de experiências. O waterfall favorece o aparecimento da síndrome do funcionário público: “eu sou gerente: eu córdeno, não preciso saber programar”. As decisões geralmente são tomadas por uma única pessoa. Os projetos seguem o modelo de construção civil. Os profissionais se acomodam pois não veem perspectiva, não conhecem o processo completo, não são ouvidos e por isso não são valorizados.

O foco destas empresas está longe de ser tecnologia. Se concentram em suas buzzwords, processos e reuniões e se esquecem do produto, ou seja, o software. Focam mais na solução do que no problema. Fazendo uma analogia, essas empresas são como um barco furado, onde está entrando água mas há pessoas com baldes para retirá-la e mantê-lo flutuando. Se a agua subir muito, contratam mais pessoas para operar os baldes. Enquanto isso, os executivos ficam acenando como se nada tivesse acontecendo. Quando perguntam se há algum problema, nenhum fdp infeliz tem coragem para falar que o problema é o furo no barco!

As empresas que focam em tecnologia e nos profissionais, tipo o Google ou a 37signals, estão se dando bem e mostrando que agilidade não é apenas mais um processo… é algo real e que funciona!

Agilidade é sair fazendo as coisas de qualquer jeito

Diante do cenário caótico das empresas, um grupo de profissionais organizou um movimento a fim de unificar as práticas bem sucedidas e tornar o processo de desenvolvimento mais produtivo e pragmático: o manifesto ágil. Quem freqüenta esse blog sabe que nós somos fãs e seguidores das práticas ágeis, não porque somos fanáticos e acreditamos somente em uma verdade absoluta, mas por que já sofremos muito com projetos e empresas fracassadas, vivenciamos os problemas que compartilhamos neste blog, passamos noites em claro corrigindo código escrito por maus profissionais, acumulamos horas em reuniões suficiente para tirarmos brevê, tivemos que negociar com cliente, com o chefe, fazer entrevista, contratar, gerenciar, analisar, programar, testar… nós sofremos os problemas do waterfall na pele!

O termo agilidade é bem popular atualmente: “precisamos agilizar nosso processo de desenvolvimento”. Como divulgação do manifesto ágil é algo muito positivo, pois mais pessoas podem conhecer e utilizar as práticas ágeis. Mas, como toda fama tem seu lado negativo, não seria diferente neste caso. Muitos profissionais “gafanhoto” estão utilizando esse termo como alavancagem profissional. Já tem gerente falando que RUP é ágil, arquiteto defensor de modelagem UML ágil, diagrama ER ágil, modelo de dados ágil, caso de uso ágil, cronograma ágil, etc. Ou seja, estão distorcendo totalmente o propósito e a filosofia da agilidade.

Como disse o Chapiewski, os programadores estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que fazem uma diferença enorme.

O mercado que não é bobo já percebeu esse movimento migratório e lançou seus cursos de “Gerenciamento de projetos ágeis com MSProject”, “Desenvolvendo aplicações web com agilidade”, “Aprenda a programar com JUnit e TDD”. Não demorou muito para que uma massa de desenvolvedores colocasse o termo ágil em seus currículos. Pretensiosos demais em achar que um cursinho qualquer pode ensinar todo conceito e técnicas ágeis catalogadas por profissionais com décadas de experiência em desenvolvimento de software.

“Estou aprendendo Ruby on Rails por que o mercado está pagando bem“. do dia para a noite surgiram milhares de especialistas ágeis. O cara que programava em .NET ou Java no modelo tradicional (digitador de código), faz um cursinho rápido e de repente começa a desenvolver aplicações numa tecnologia que exige uma enorme bagagem conceitual. Faz tudo errado, pois não sabe realmente o que está fazendo, o projeto fracassa e ainda deixa a tecnologia com má fama. Isso aconteceu com PHP, ASP e está acontecendo com Rails.

Programar é difícil, não é um trabalho para qualquer aventureiro. É preciso estudar muito, se dedicar e principalmente, gostar! Não basta apenas estudar para conseguir uma certificação pois não garante nada. Deve-se viver a programação, participar de fóruns, contribuir com projetos open-source, discutir idéias, ser auto-crítico, ler muito, praticar, apreciar as boas práticas e abolir o que não presta…

Agilidade é propor soluções simples para os problemas

Agilidade não é anarquia, não significa “sair fazendo as coisas de qualquer jeito”, dizer “não” para documentação, etc. É uma mudança de atitude, uma nova maneira de enfrentar os problemas e propor soluções simples e práticas, é ter foco, é saber fazer mais com menos, é automatizar tarefas, é estar comprometido… agilidade é atitude.

Contratamos uma consultoria para implantar Scrum

Scrum é a metodologia da moda. Assim que começou a se popularizar entre a comunidade de desenvolvedores, não demorou muito para o que vários sites e blogs se dedicassem exclusivamente na sua divulgação, apresentando benefícios, artigos, guias, exemplos, certificados para imprimir e pendurar em uma moldura na parede, etc. Logo surgiram as consultorias especializadas em adestramento treinamento e implantação de Scrum nas empresas. Um pouco de política aqui e influência ali até que a INFO Magazine publicasse uma matéria dizendo sua empresa deveria usar Scrum como solução para todos os problemas.

Mais uma vez, a falta de foco e maturidade das empresas distorcem tudo. Muitas empresas “compraram” o Scrum como a solução pronta. Bastar treinar os funcionários, comprar blocos de post-it e tudo passa a funcionar bem e gerar lucro. Pagam um curso de “gerenciamento de projetos com Scrum” para os gerentes. Depois apostam todos as fichas em um projeto “piloto”. Fazem tudo que manda o manual: reuniões diárias, planing-pocker, quadro com post-its, etc. E o projeto… fracassa!

Queimando dinheiro

Então quer dizer que Scrum não funciona? Foi dinheiro desperdiçado? Tanto esforço para nada? Neste caso, devo dizer que sim! Se esqueceram do processo anterior falho, funcionários pouco qualificados e dos líderes sem foco. Escolheram aqueles funcionários mais “experientes” para serem o Scrum Master. Sim, aqueles mesmos que só sabiam escrever casos de uso e diagramas UML. Se esqueceram dos valores, dos princípios, da atitude, do relacionamento com o cliente. O pensamento não mudou, o foco ainda era no processo. Depois de tanto esforço, só deram outro nome o waterfall. Não demorou muito e surgiram os papéis, artefatos, documentos… ou seja, a empresa continua cometendo os mesmos erros!

Não importa a tecnologia ou processo se não souber usá-lo corretamente! E definitivamente Scrum não pode ser encarado como mais um processo bonitinho, com seus papéis, artefatos, bla bla bla. Um processo de software que funciona é aquele onde a equipe está realmente comprometida e tem experiência acumulada para enfrentar e resolver problemas ao longo do desenvolvimento da aplicação. O processo, ou metodologia, será meramente um nome para as práticas que a equipe conhece e utiliza naturalmente.

Resumo

Não há ferramenta, metodologia ou processo que substitua a atitude e experiência de um verdadeiro desenvolvedor ágil. Estude, pratique, esteja comprometido, estude denovo, questione-se, estude novamente. Revise seu código, estude mais um pouco, e principalmente, tenha atitude! Agilidade não é metodologia, é atitude!

Aproveitando o gancho do post anterior sobre manipulação de dependências, decidi dedicar um post apenas sobre este tema, pois acredito ser de grande ajuda para todos desenvolvedores que precisam manter código legado.

Em projetos legados é comum encontrarmos classes Util (aka Helpers) espalhadas por todo o código, fazendo desde coisas simples como formatar datas ou números, até coisas mágicas como cache de objetos, operações com reflection, escrita de logs, etc. Mesmo que tenham sua “utilidade”, são um terror quando falamos de testes! Além de ser um forte indício de um design fraco, as chamadas a seus métodos, geralmente estáticos, geram dependências nas classes que a utilizam.

Este é a estrutura comum (bem simplificada) de uma classe Util com métodos estáticos:

public class MagicUtil {
    public static String getConstanteSecreta() {
        return "VALOR_SECRETO_AMBIENTE";
    }
}

Neste caso, uma boa estratégia para os testes seria encapsular a chamada da classe Util em um método protected, para que seja sobrescrito na classe de teste, assumindo o comportamento desejado. Porém, se a classe Util for largamente referenciada no projeto (o que é comum) seria preciso refatorar todas a classes que a utilizam para escrever um teste completo.

A estratégia proposta é refatorar a classe Util, aplicando o padrão Singleton e transformando os métodos estáticos em métodos de instância, porém mantendo as assinaturas estáticas, que devem referenciar os métodos da instância. Uma vez que a Util pode ser instanciada (mesmo que internamente), é possível manipular seu comportamento através da injeção de um objeto Mock, por exemplo:

public class MagicUtil {
    private static MagicUtil instance = new MagicUtil();
    protected static MagicUtil getInstance() {
        return instance;
    }
    protected static void setInstance(MagicUtil obj) {
        instance = obj;
    }
    public String getConstanteSecretaInstancia() {
        return "VALOR_SECRETO_AMBIENTE";
    }
    public static String getConstanteSecreta() {
        return getInstance().getConstanteSecretaInstancia();
    }
}

Assim, a Util continua com o mesmo comportamento e seu contrato foi mantido. Agora, no seu teste, basta escrever o mock (estendendo a classe e sobrescrevendo os métodos) e injetá-lo na instância interna da Util:

public class ClasseTest {
    @Test
    public void testaMetodoDependenteDeMagicUtil() {
        new MagicUtil() {
            {
                setInstance(this);
            }
            public String getConstanteSecretaInstancia() {
                return "MEU_VALOR_MOCK";
            }
        };
        Assert.assertEquals("MEU_VALOR_MOCK", MagicUtil.getConstanteSecreta());
    }
}

Neste caso a classe anônima (que estende a Util) passa sua própria instância (this) para o método protegido setInstance(). Note que a chamada do método (estático) da Util continua igual ao da classe original, sem o refactoring.

Nos projetos que preciso manter, esta estratégia tem sido muito útil para resolver os problemas das “teias” de Utils. Porém é um recurso paliativo e não deve ser utilizado como o “padrão”. O ideal é sempre evitar classes Utils, lembrando que uma classe deve sempre ter comportamentos bem definidos e o nome já deve indicar sua responsabilidade.

Pela definição de Michael Feather, código legado é código sem testes! Não importa se o código foi escrito semana passada ou alguns anos atrás. Qualquer manutenção será de difícil entendimento por outra pessoa e não haverá garantias de seu funcionamento. Uma vez que não há “controle”, é mais difícil rastrear as alterações; pior do que uma nova funcionalidade que não funciona, é uma funcionalidade antiga que começa a falhar. Este é um risco que um desenvolvedor não pode correr!

Não altere código legado até que seja possível testá-lo

Um dos problemas mais comuns em sistemas legados é a interdependência de classes, ou seja, o alto acoplamento, que sempre está ligado com a baixa coesão. Se estes termos são difíceis de entender, pense em acoplamento como sendo o grau com que as classes referenciam umas as outras e coesão o quanto uma classe está focada em realizar suas responsabilidades.

Para que seja possível testar o comportamento de uma classe “acoplada”, o comportamento de suas dependências precisa ser simulado. Isto normalmente é feito através de objetos falsos, ou mocks, que são injetados na instância da classe em questão. Este padrão é conhecido como Inversão de Controle e Injeção de dependência, onde o controle sobre as dependências da classe são delegados à outro objeto, ou normalmente um container de objetos, responsável por injetar as dependências nas instâncias das classes. Simples, não?! Mas isso será detalhado em outro post…

Voltando para os testes, no post anterior começamos a organizar o projeto automatizando o build e centralizando a execução dos testes para evitar que fiquem “soltos” pelo código. Agora vamos nos concentrar em escrever os casos de teste, refatorando o necessário para lidar com as dependências das classes.

Partindo da premissa que o projeto não possuí nenhum framework de inversão de controle, utilizaremos um certo “padrão” que permite manipular as dependências de uma classe por meio de herança, sem alterar seu comportamento original. A idéia é resolver as dependências da classe através de getters protegidos, que podem ser sobrescritos em uma classe filha no momento do teste. Isso permite que, na classe estendida, o método sobrescrito retorne um objeto mock, por exemplo, com o comportamento esperado para o teste.

Vamos tomar como exemplo, uma classe simples com algumas dependências e responsável por encapsular algumas regras de negócio referentes à Estoque.

public class EstoqueLogic {
    public boolean verificaDisponibilidade(Produto produto, Integer quantidade) {
        EstoqueDAO dao = new EstoqueDAO();
        Estoque estoque = dao.localizaProduto(produto.getCodigo());
        return estoque.getQuantidade() >= quantidade;
    }
}

Da forma como esta classe foi escrita, é impossível testar a regra de disponibilidade independentemente, pois depende do objeto EstoqueDAO para localizar as informações necessárias para o método. Mas com um pequeno refactoring, a responsabilidade de resolver a dependência EstoqueDAO passa a ser responsabilidade da própria classe Estoque:

public class EstoqueLogic {
    public boolean verificaDisponibilidade(Produto produto, Integer quantidade) {
        EstoqueDAO dao = getEstoqueDAO();
        Estoque estoque = dao.localizaProduto(produto.getCodigo());
        return estoque.getQuantidade() >= quantidade;
    }
    protected EstoqueDAO getEstoqueDAO() {
        return new EstoqueDAO();
    }
}

Desta forma, é possível “injetar” um objeto que simule a dependência do EstoqueDAO estendendo a classe e sobrescrevendo o método getEstoqueDAO() para retornar a instância desejada. O teste ficaria mais ou menos assim:

public class EstoqueLogicTest {

    public void testVerificandoDisponibilidadeDeUmProduto() {

        //Criando o objeto EstoqueDAO mock, simulando o comportamento desejado
        final EstoqueDAO estoqueDAOMock = new EstoqueDAO() {
            @Override
            public Estoque localizaProduto(String codigo) {
                Produto produto = new Produto();
                produto.setCodigo(codigo);
                Estoque estoque = new Estoque();
                estoque.setProduto(produto);
                estoque.setQuantidade(5);
                return estoque;
            }
        };

        //Sobrescrevendo o método getEstoqueDAO para retornar o Mock
        EstoqueLogic logic = new EstoqueLogic() {
            @Override
            protected EstoqueDAO getEstoqueDAO() {
                return estoqueDAOMock;
            }
        };

        //Definindo o teste e executando
        Produto produto = new Produto();
        produto.setCodigo("123456");        

        boolean estaDisponivel = logic.verificaDisponibilidade(produto, 10);
        assertTrue(estaDisponivel);

        boolean naoEstaDisponivel = logic.verificaDisponibilidade(produto, 2);
        assertTrue(naoEstaDisponivel);
    }
}

O método getEstoqueDAO() da classe EstoqueLogic foi sobrescrito para retornar o objeto estoqueDAOMock com as informações necessárias para o teste, ou seja, o comportamento das dependências foi simulado, possibilitando que o teste ficasse concentrado apenas da classe Estoque.

Elimine as dependências e teste onde os bugs estão!

Este padrão fornece apenas uma maneira de lidar com as dependências das classes para escrever testes. A dica aqui é manter o foco: defina apenas testes para as funcionalidades que estiver alterando e que exercitem pontos críticos e/ou regras de negócio. Então, refatore apenas as classes necessárias para simular e validar o fluxo destes testes, nem que seja apenas seus “contratos“. Não há necessidade de escrever testes muito granulares nem alterar todas as classes de um sistema legado.

No caso de classes com muitas dependências, o melhor é refatorá-la, separar as responsabilidades e testá-las individualmente. Para classes com dependências de Utils e/ou muitas chamadas à métodos estáticos, uma estratégia parecida pode ser utilizada. Mas estes são assuntos para os próximos posts. Acompanhem!

Imagine o cenário: você caiu de para-quedas naquele projeto que todo mundo na empresa fez gambiarra deu manutenção e agora precisa implementar uma nova funcionalidade. Mesmo que tenha alguma documentação, vai ser inútil neste caso. Então você começa a vasculhar o código e encontra dezenas de classes com nomes parecidos, vários arquivos XML’s dos inúmeros frameworks utilizados anteriormente, TO’s, VO’s, Actions, Utils… ou seja, um lugar cheio de janelas quebradas.

O mais fácil neste caso seria fazer seu trabalho, quebrando mais algumas janelas caso necessário, e cair fora o quanto antes. Mas você, desenvolvedor ágil, sabe que além de ser falta de profissionalismo, você corre o risco de cair novamente no mesmo projeto. Então aproveite a oportunidade para fazer uma pequena faxina e preparar o projeto para escrever os testes das novas funcionalidades que irá desenvolver, garantido assim a qualidade, pelo menos, do seu trabalho.

Durante minha carreira fui obrigado tive a oportunidade de dar manutenção em diversos projetos “frankenstein” de onde adquiri certa experiência para poder “organizar a casa” e trabalhar decentemente no código. É claro que não estou falando em escrever testes para o projeto inteiro, mas pelo menos garantir a qualidade do código que desenvolvi ou irei desenvolver.

Há um certo padrão que todo software de qualidade deve seguir. Além dos padrões e boas práticas como organização do código em pacotes vs. responsabilidade, uma coisa essencial para o projeto é sua construção, ou seja, a forma que o software é “entregue”. Acredito que este seja o primeiro passo para começar a organizar a bagunça de um projeto.

A construção do projeto deve ser automática e desempenhada por uma ferramenta de build como o Ant ou Maven, com tarefas (tasks) e objetivos bem definidos. Normalmente, um build do projeto deve:

1. Preparar o código e dependências
2. Compilar os arquivos fontes
3. Executar os testes
4. Empacotar a distribuição

No exemplo abaixo usarei o Ant, que é a ferramenta de build (para Java) mais popular do mercado e muito simples de utilizar. O importante neste processo é ser pragmático: não perca o foco! Você poderia (e futuramente deveria) utilizar o Maven, mas adequá-lo a um sistema legado não é tão simples quanto parece.

Tendo os objetivos do build definidos, basta escrever o script do Ant. Isso deve ser feito no arquivo build.xml, no root do projeto. As tarefas são definidas pelas tags <target> e podem ser dependentes para garantir a sequencia de execução. Em cada target são definidas as ações executadas, como rodar o compilador (javac), copiar um arquivo, rodar os testes, etc. Uma vez que as tarefas estão configuradas, basta executar o build pelo próprio IDE ou linha de comando.

<project name="frank" default="package">
    <path id="classpath">
        <pathelement location="build/bin"/>
        <fileset dir="src">
            <include name="*.java"/>
        </fileset>
        <fileset dir="lib">
            <include name="*.jar"/>
        </fileset>
    </path>
    <target name="clean">
         <delete dir="build"/>
          <mkdir dir="build"/>
    </target>
    <target name="compile" depends="clean">
        <javac srcdir="src" destdir="build">
            <classpath refid="classpath"/>
        </javac>
    </target>
    <target name="test" depends="compile">
        <junit>
            <classpath refid="classpath"/>
            <batchtest>
                <fileset dir="build" includes="*Test"/>
            </batchtest>
        </junit>
    </target>
    <target name="package" depends="compile, test">
        <war destfile="frank.war" webxml="web/WEB-INF/web.xml">
        <classes dir="build"/>
    </target>
</project>

Neste script estão definidas as tarefas necessárias para executar um build, conforme citei anteriormente. Por enquanto isto será o mínimo necessário para dar suporte as próximas etapas da sua missão. Mesmo que o projeto já tenha um build em Ant aproveite para revisá-lo. Tarefas bem simples e bem definidas são mais fáceis de entender e manter.

Com o build implementado, você não terá mais que se preocupar com o empacotamento do projeto. Agora comece a direcionar seus esforços para escrever os testes. Deixe que o Ant se encarregará de executá-los para você.

No próximo post vou apresentar alguns padrões e práticas de refactoring utilizados para possibilitar escrever testes que dependem de classes legadas do projeto.

Atualmente as metodologias ágeis vêm aparecendo com cada vez mais freqüência nas empresas que desenvolvem software, introduzidas pelos próprios desenvolvedores (o que é mais comum) ou em alguns raros casos pela “cúpula” da empresa, na esperança de melhorar a produtividade e/ou o alto tempo de resposta do fracassado processo cascateiro. Porém, esta “fama” prematura dos métodos ágeis tem gerado mais resultados ruins do que bons. Sua aplicação na vida real, na maioria em muitos casos, ocorre de maneira equivocada, distorcida e desprezando-se os reais valores e princípios que apoiaram o surgimento desta filosofia.

Um exemplo claro de como os valores ágeis estão sendo desprezados distorcidos é o aumento constante de “cursos” e treinamentos de metodologias ágeis. Não é raro eu receber semanalmente vários spams e-mails de escolas de treinamento que ministram cursos de Scrum, XP, preparação para certificação ScrumMaster, técnicas de TDD, DDD, BDD, etc. Infelizmente o que estes cursos não ensinam (como todos os outros) é o verdadeiro significado de “ser ágil”. Fazer um curso de 20 horas de Scrum não o torna um ScrumMaster (você pode até ter um certificado, mas se você realmente é “ágil”, sabe que um certificado é um mero pedaço de papel sem valor).

E assim chegamos à “agilidade cascateira”, onde todos na empresa estufam o peito para falar que seguem práticas ágeis, desenvolvimento orientados à testes, utilizam Scrume para gerenciar os projetos, etc. Na verdade estão apenas praticando um waterfall incremental, cometendo os mesmos erros clássicos da cascata, valorizando os processos ao invés das pessoas, focando em soluções equivocadas ao invés de resolver os problemas dos clientes e assim, difamando e denegrindo a reputação e o propósito do AgileManifesto.

Esse é o cenário ideal para os guardiões cascateiros. É por estes e outros motivos que vemos “flames” oportunistas como The Decline and Fall of Agile começarem a fazer sentido na comunidade. Como disse o Guilherme Chapiewski, as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Utilizar uma metodologia ágil não é desenvolver software de forma anarquista, existe muito conceito e experiência adquirida para sustentar esta filosofia.

Neste blog você já viu várias maneiras de como ser um verdadeiro cascateiro e de como não ser ágil. Já que estamos falando nisso, vamos tentar resumir alguns pontos e características que tornam um desenvolvedor realmente ÁGIL!

Estude, mantenha-se atualizado!

A principal característica de um agilista é sua sede por conhecimento, sua busca incansável por novas técnicas, linguagens, ferramentas, etc. O seguidor ágil lê artigos, revistas, livros e o faz como diversão. Se você não leu pelo menos um livro técnico nos últimos 6 meses, isto é um mal sinal. Faça laboratórios, testes de novos frameworks, bibliotecas, etc. Pet-projects também são uma maneira pragmática de aprender novas formas e técnicas de desenvolvimento. Finalmente, conheça e pratique os princípios e valores do AgileManifesto, tendo-os como seu mantra, seu guia filosófico e seu mentor profissional.

Entenda realmente o problema do seu cliente

Isto parece ser óbvio, mas na maioria das vezes não é. Existem vários perfis de clientes, e é claro que você deve lidar de maneiras diferentes com cada um deles.

Alguns são visionários sonhadores e sempre têm necessidades mirabolantes, sem sentido. Outros são simplistas demais e muitas vezes “ocultam” detalhes importantes. Também existem os pseudo-técnicos, que acham que sabem fazer seu trabalho e já vêm sugerindo como você deve implementar aquela nova funcionalidade.

Reação comum quando há um problema

Como verdadeiro agilista, saber identificar o perfil de seu cliente é o início para um relacionamento de confiança e transparência. Só assim você será capaz de concentrar esforços para resolver seu problema e agregar valor ao produto.

Não tenha medo de mudanças

A única maneira de criar, corrigir ou melhorar algo é com coragem E com mudança. O essencial para mudar algo é saber identificar o que está errado. Por exemplo, você sofre diariamente para fazer o deploy da sua aplicação para homologação. Identificado o problema e uma possível solução, por exemplo, fazer o deploy em .war, você tem duas soluções: ou deixa como está e coloca a culpa na aplicação ou no processo de desenvolvimento (conformismo) ou com muita coragem investe algumas horas e resolve de vez o problema (agilismo).

Quando bater a insegurança, repita: coragem! coragem! coragem!

Coragem: o cão covarde!

Reflita e aprenda com os próprios erros

Existem várias maneiras de você evoluir seu conhecimento, e a maioria dos programadores utilizam somente uma: tomando na cabeça.

Prego só toma na cabeça!

Como um bom seguidor de práticas ágeis, reflita e aprenda com seus erros. Compartilhar seus problemas é a melhor maneira de escolher um solução adequada e ainda espalhar sua experiência entre a equipe para que outras pessoas não cometam o mesmo erro.

Errar é humano. Persistir no erro é burrice. Se você está com problemas, procure por pessoas que já tiveram um problema parecido e aprenda com ele. Não cometa os mesmo erros, e mais importante, não cometa os mesmo erros dos outros!

Resumo

Se tudo que você leu até agora não é novidade, parabéns! Caso contrário comece o quanto antes estudar e principalmente praticar estes conceitos no seu trabalho e na sua vida.

Seja responsável e comprometido com seu trabalho. Esforce-se para fazer o melhor. Faça valer o seu salário. E lembre-se: cuidado com os falsos agilistas!