Essa semana, depois de dias cansativos de trabalho, ouvi um comentário interessante sobre o que faz Scrum funcionar. Eu não estava com energia suficiente para conversar sobre o assunto, mas fiquei com um espinho na cabeça, grande o suficiente para me forçar a blogar depois de tanto tempo. O comentário? “Scrum funciona porque faz as pessoas ficarem com vergonha”. Ouvi isso de alguém que sabe e pensa no que fala. A justificativa básica fincava pé na “vergonha” de não entregar – publicamente – software funcionando, de não cumprir – publicamente – os compromissos feitos nas reuniões de planejamento, de ter – publicamente – produtos com qualidade duvidosa. As pessoas sentem isso e assumem a responsabilidade sobre seu trabalho: eu preciso entregar o que prometi; eu não posso mostrar incapacidade de entregar um incremento de software. A vergonha, a separação clara de papéis, de deixar claro quem tem responsabilidade sobre a “vergonha” força as pessoas a seguir em frente.

Bem, eu discordo completamente!

Barry Schwartz, em uma das palestras mais interessantes que já vi, fala sobre nossa perda de sabedoria, de como criamos regras e incentivos falhos. Barry apela para nossas virtudes, para nossa sabedoria prática e alerta: “regras e procedimentos previnem desastres, mas o fazem substituindo-os pela mediocridade”. Nossa percepção, a maior parte do tempo, é a de que precisamos das regras para impedir que pessoas idiotas cometam erros idiotas, mas é uma ilusão achar que existe alguma regra que previna idiotices. O lado escondido da moeda é que as regras com freqüência são barreiras para a sabedoria e o pensamento prático. É difícil, ou mesmo impossível, criar um ambiente a prova de idiotas porque eles exercitam sua idiotice quase que em tempo integral. Aparentemente, para muita gente, também é difícil criar ambientes onde as pessoas possam exercitar a sabedoria.

Agilidade requer uma maneira diferente de pensar. Você não pode considerar o ciclo de Scrum como um conjunto de práticas e regras a seguir, mas como guias, valores e princípios. Você não pode pensar em vergonha pelo não cumprimento das regras. Agilidade não é sobre regras, não é sobre quem deve passar vergonha por um erro. Agilidade é sobre valores, princípios, você não precisa acreditar em mim, basta ler o manifesto. Mas acredite, as pessoas são bem mais impulsionadas por seus valores do que por suas “vergonhas”.  As pessoas lutam por seus valores e princípios, não por vergonha ou regras. As pessoas pensam e evoluem pensando em seus princípios, regras, em geral, são seguidas cegamente e só existe luta para mantê-las quando elas foram a única maneira encontrada para expressar os princípios. Nós precisamos esquecer o que nos trouxe até o ponto de achar que alguém deve passar vergonha. Esqueça isso. Esvazie o copo, recomeçe com mente de iniciante e entenda que Scrum funciona por causa de seus valores. Valores e princípios estão acima das regras e das ordens.


Blog, blog, blog. Meses sem blogar e agora volto para fazer propaganda de interesse aos que moram em Recife e se interessam por Scrum. Amanhã será o primeiro encontro do Scrum User Group Recife, organizado por mim, Igor Macaubas e Ana Roullier. Dados do evento abaixo:

Quando? Quarta-feira, 05/11/2008, às 17:00
Onde? Na sede da SWQuality, no Porto Digital. Mapa aqui.

Confirmem presença enviando email para marcos.silva@gmail.com ou igor@macaubas.com. Esperamos vocês lá. Para quem não está em Recife, faltam apenas alguns ajustes para lançarmos o portal do Scrum User Group Brasil. Mais novidades conforme colocarmos conteúdo por lá.


O quão comum é tentar resolver o problema através de suas conseqüências ao invés de suas causas? Eu tenho visto acontecer com grande freqüência e o resultado é que as soluções apenas causam mais problemas. O que me faz pensar no quanto a cultura da Toyota é interessante ao propor perguntar “por que?” cinco vezes antes de tentar resolver um problema.  É a instituição oficial da análise da causa raiz. Agora, sem esforço, consigo me lembrar de dois casos nos quais a pergunta errada – ou a análise apenas das conseqüências – implicava uma resposta errada com resultados, digamos, indesejados.

Ontem encontrei um artigo sobre quanto tempo um desenvolvedor deve gastar para resolver bugs encontrados em projetos no emprego anterior. A questão basicamente era: “É seu código, seu bug, mas não é mais seu emprego. Quanto tempo gastar para ajudar a resolver?”. Enquanto alguns comentários debandavam para questões legais ou o desenvolvedor agora talvez trabalhar para a concorrência, eu pensava: meu código? Meu bug? Não, obrigado. Ambos não deveriam ser meus. Ambos devem ser de propriedade e responsabilidade do time. Trabalhar em times quer dizer, ou ao menos deveria, que tarefas importantes não devem ficar sob responsabilidade de apenas uma pessoa. É uma maneira efetiva tanto de evitar que o trabalho pare se um individuo se ausentar quanto de permitir que pessoas com conhecimentos diferentes tornem o resultado final melhor. XP leva isso ao extremo ao propor programação em par e propriedade coletiva do código. Não é seu código ou bug e qualquer um dentro do time pode se encarregar da tarefa. Percebeu como faz pouco sentido chamar alguém que já saiu para resolver um problema?

A segunda pergunta era: “fazer a aceitação de um release dá muito trabalho, não seria melhor fazer releases em intervalos maiores?”. Não, não seria. A aceitação só é muito trabalhosa se os testes de aceitação/funcionais são feitos manualmente. O caso não é de aumentar o ciclo para poupar esforço com muitas releases, mas automatizar os testes para que as releases sejam feitas semanalmente, de preferência. Aumentar o ciclo de releases não resolve o problema. Apenas aumenta já que, falta  de automação + ciclos maiores resultará em mais funcionalidades para testar e menos feedback sobre erros. A resposta errada não resolveu o problema, apenas criou outros.

Ambos os casos acima remetem para meu post anterior sobre problemas se tornarem oportunidades. Mas nem sempre é fácil perceber as implicações de respostas erradas, principalmente quando quem as dá não é quem vive os resultados delas, ou sofre os problemas na pele . No fim das contas, as vezes é mais fácil dar as respostas erradas do que fazer as perguntas certas.


Essa mensagem na xprio me fez lembrar de um pensamento que tenho desde que agile apareceu na minha frente: se você desenvolve software da maneira errada, provavelmente esconderá isso dos seus clientes. Ou da maneira como surgiu na minha cabeça (e sem palavrões, claro): se você se esconde do cliente para desenvolver, é porque está fazendo algo de errado. Não que o cliente por perto funcione como vigia quando se trata, por exemplo de XP. O propósito mesmo é ter comunicação direta com quem pensa e entende das necessidades. Em XP o ponto de vista é otimista porque há uma série de práticas para garantir qualidade intrinsecamente. Então, se não há o que esconder, o cliente por perto é um problema que se torna oportunidade.

ps.: o post pequeno e depois de tanto tempo deve ter alguma influência do twitter. 🙂


Assuma, você já deve ter ouvido isso alguma vez na sua vida. Essa é apenas uma daquelas frases incompletas repetidas a ponto de muita gente achar que se trata de uma verdade. Bom, deixe-me esclarecer então que é justamente a falta de completude que torna a frase incorreta. Desenvolvedores não odeiam testar.

Desenvolvedores odeiam testar manualmente.

Eis aí a grande diferença e eu sempre fico incomodado quando pessoas inteligentes deixam de aplicar seu tempo em automação para realizar, vez após vez, testes manuais. Se você ainda perde tempo realizando testes manuais, saiba que eles vêm recheados de problemas: levam mais tempo para serem reproduzidos, são propensos a erros, não aproveitam o que as pessoas têm de melhor, não podem ser expandidos para lidar com outros aspectos do software (como performance, por exemplo) e não indicam exatamente onde a funcionalidade está quebrada.

Nós – como desenvolvedores – trabalhamos para automatizar tanto quanto possível do nosso dia-a-dia e mesmo o dia-a-dia dos clientes. Computadores são ótimos para repetir tarefas, nós sabemos disso, então é realmente incômodo realizar testes manuais porque a sensação é de que algo está errado. Como ninguém com boa saúde mental gosta da sensação de fazer coisas erradas, essa condição passa a incomodar.

Ok, então, desenvolvedores odeiam testar manualmente. O que mais?

Desenvolvedores odeiam testar código escrito antes dos testes porque código escrito assim, via de regra, é difícil de testar, visto que ele não foi feito pensando em testes. Se considerarmos que os testes automatizados nada mais são do que clientes da aplicação, dá para concluir que é difícil, mesmo dentro da própria aplicação, fazer bom uso do código. É o que eu tenho visto acontecer. Código difícil de testar é difícil de usar também. A solução é pensar em design limpo, fácil de usar desde o inicio, escrevendo testes para garantir não apenas o funcionamento, mas também a usabilidade do design. Não fica por aí, você cria tanto uma rede de proteção para prevenir os erros (ao invés de apenas tentar encontrá-los só depois de muito tempo) quanto um ambiente onde mudanças possam acontecer de maneira segura.

Testes manuais ainda são necessários em algum ponto do sistema, mas sempre que possível, não aceite o incômodo de gastar seu tempo assim, eles simplesmente não lhe ajudam a formar um ambiente livre de erros e bugs que matam a produtividade de qualquer time. É preciso ir além da cultura de apenas encontrar erros pois eles têm um custo muito grande de tempo para correção e de impacto na moral do time. Se você sofre com os males causados pela falta de testes, tente provocar mudanças para o bem em seu ambiente de trabalho, afinal, ninguém gosta de jogar para perder.


E eu achando que era querer demais ter algo como Extension Methods em Java, mas eis que o Neal Gafter publicou em seu blog um noticia animadora. O exemplo que ele mostrou é um tanto quanto simples e não dá para ver como a sintaxe vai funcionar:

import static java.util.Collections.sort;

List list = ...;
list.sort();

Ainda bem que não sou o único a pensar que o método “sort” não deveria ser algo externo a java.util.Colletion. Sobre o exemplo, afinal, o que irá diferenciar um simples static import de uma extensão aos métodos? Para mim é uma ótima noticia já que fica mais fácil adotar outras novidades como closures. É esperar para ver.


Open WindowsNão é muito complicado encontrar por aí propostas para tornar Java – a linguagem – mais moderna, com adições de recursos muito úteis em outras linguagens. Hoje o Bruno Borges propôs uma alteração para realizar return do objeto this de maneira mais direta, basicamente é sintax sugar com uso restrito. Algumas semanas atrás foi liberada uma versão preliminar de closures para Java e surgem RFE aos montes para melhorias aqui e acolá. Apesar da evolução benéfica causada pela concorrência com .Net, como linguagem, Java tem boa resistência a adições, além de boa parte delas estarem atrasadas faz algum tempo. Mas não porque outras linguagens foram mais competentes, acontece que há uma diferença muito grande entre nascer com closures e inclui-las depois. Para Java, o atraso fica evidente por causa da imensa quantidade de APIs, frameworks, etc feitos até agora sem que os desenvolvedores pudessem lançar mão dos novos recursos. Quer um exemplo? As APIs de Collections e IO estão congeladas em zero absoluto e ninguém vai se atrever a colocar um novo método sequer em java.util.Collection porque isso quebra código em uma quantidade impraticável.

Essa inércia nos direciona para código pouco interessante, pois metodos como “each“, “findAll“, “collect” seriam estáticos, provavelmente jogados em java.util.Collections. Entretanto, há uma adição que tornaria a adoção de todas as outras mudanças bem mais simples: classes abertas. Classes abertas são uma maneira de evoluir as APIs por fora sem quebrar código existente. .Net tem corrido atrás de algo semelhante usando extension methods e talvez seja a hora de Java tomar – novamente – algumas idéias emprestadas com a concorrência. Esse tipo de recurso também permite que passemos por cima de pequenos erros de design e possamos, por exemplo, transformar isso:

Date now = new Date();
Calendar temp = Calendar.getInstance();
temp.setTime(now);
temp.add(Calendar.MINUTE, minutes);
Date newDate = temp.getTime();

Nisso:

Integer two = 2;
Date now = new Date();
Date newDate = now.add(two.minutes());

Acredite, não é sobre quantidade de linhas, mas sobre clareza e expressividade. Claro, isso envolve outras discussões como interfaces humanas vs interfaces mínimas (a estratégia usada em Java). Só que as “alterações” nas classes não precisariam estar dentro do API padrão, mas sim em código escrito pelos desenvolvedores ou em bibliotecas de terceiros. Estes sim seriam responsáveis por “mover” para java.util.Collection código que com certeza entrará em alguma classe com trocentos métodos para manipular coleções. “De qualquer modo”, talvez seja melhor pensar em outras frentes, especialmente na evolução de Java como plataforma pode oferecer melhor suporte para a infinidade de linguagens disponíveis para a JVM.


Eu havia lido sobre o blog day 2007, mas não foi algo que me chamou atenção o suficiente, então deixei passar batido. Olhei com mais cuidado quando o Thiago Arrais, depois de ser citado pelo José Oliveira, indicou esse blog entre os que ele acompanha. Nada mais justo do que eu citar aqui alguns – cinco também – dos blogs que acompanho com mais atenção. De comum entre eles estão os posts com textos trabalhados com cuidado e publicações com freqüência menor, aquela velha história sobre qualidade e quantidade.

São eles:

Mergulhando no Caos: e não é para devolver a gentileza. Dê uma navegada pelo blog e você verá que os posts são acima da média, com idéias bem elaboradas e descritas de maneira competente. De lambuja você lê acompanhado de uma cabeça voadora, a do Arrais, claro.

Blog da Caelum: nesse blog os desenvolvedores da Caelum se revezam para escrever sobre Java, Padrões de Projeto, Ruby e, faz pouco tempo, Scrum.

* batteries not included: Daniel Martins é um sujeito curioso o suficiente para estudar um mundo de coisas em Java, Ruby, Smalltalk, Groovy e por aí vai. Os posts são geralmente bem completos e com informações para sair do zero caso você não saiba muito sobre os assuntos tratados por ele.

Blog do Guilherme Chapiewsk: Encontrei o blog do Chapiewski – sim eu copiei e colei – através do Phillip Calçado e assinei o feeds logo. A maior partes dos posts trata de agile e testes, vale uma boa olhada.

Code Comics: blog com quadrinhos? Preciso dizer mais o que?


Como desenvolvedores de software nós trabalhamos para criar ferramentas que automatizem ou melhorem tarefas. Escrevemos software para análise de dados financeiros, para gerar relatórios sobre como anda o relacionamento com os clientes e para uma infinidade de propósitos. É bastante natural querermos então automatizar tanto quanto possível do nosso trabalho. Daí criarmos rotinas prontas para compilação, empacotamento, testes e toda e qualquer tarefa que se mostre repetitiva. Se você não faz isso no seu trabalho, saiba que perde tempo a cada execução manual e repetitiva de alguma tarefa que pode ser automática.

Não é de surpreender que, nessa sede de tornar tudo executável com um clique, vez ou outra alguém tente automatizar o que não deve. Afinal, eis aí uma maneira de maximizar a previsibilidade e a eficiência da tarefa: ninguém corre o risco de esquecer um passo importante e acabar com resultados errados. Mas existe a contra mão para não ser automatizada. Uma via intimamente relacionada a tarefas com impacto na maneira de pensar das pessoas.

Deixem-me esclarecer de onde essas alucinações vieram.

Exemplo de prática com impacto nas pessoas: em metodologias agéis, quando pensamos em artefatos tais quais modelos, diagramas e afins, o mais importante não é o artefato em si, e sim o trabalho de criar, o fazer. Por causa disso, usamos artefatos fáceis de gerar – como story cards – e de descartar caso estejam errados. Os cartões têm, claro, seu valor, só que o que importa mesmo é o jogo do planejamento, a reunião na qual eles, os cartões, são escritos. Pode passar despercebido, mas olhar mais para o fazer é uma maneira de criar sinergia porque as pessoas desenvolvem o hábito de, juntas, realizar tarefas.

O outro impacto provocado por quadros com story cards, gráficos burn-down, ou outros artefatos pendurados até onde a vista alcança é que eles impactam as pessoas o tempo todo sobre como o projeto está, desde quando você entra no ambiente até quando sai. Mais ainda, os quadros vão além de serem apenas um snapshot do projeto, eles são um estimulo para o senso de que as tarefas precisam ser terminadas. Ferramentas sem impacto visual, por outro lado, não produzem estimulo na mesma proporção, basta pensar que issues trackers, mesmo os melhores, não estão sempre a vista.

A partir daí você pode imaginar minha surpresa ao ver essa noticia no InfoQ mostrando como um conjunto de artefatos com apelo visual foi substituído por uma ferramenta com – verdade seja dita – alguns recursos pra lá de interessantes, mas, vejam só, longe dos olhos das pessoas, ou ao menos não tão perto assim. Espero que eu não seja o único a perceber que menos informação é irradiada. Talvez ainda faltem as ferramentas certas, ou o hábito de usá-las como se deve, mas acho que, assim como há espaço para mais automatização no que diz respeito a tarefas repetitivas, feitas por maquinas, há espaço para menos automação, para tarefas que requerem aquilo que os serem humanos – ao menos os mais interessantes – têm de sobra: criatividade, curiosidade e tato.


Curiosidade é um comportamento naturalmente questionador, um estado no qual se quer aprender mais sobre algo, um aspecto emocional que direciona para investigação e aprendizado. Essa é uma pequena compilação das definições sobre curiosidade. Provavelmente você pode encontrar outras melhores do que essas, um dicionário de bolso com certeza vai lhe ajudar. Entretanto, para mim, o mais adequado é chamar curiosidade de motor.

Mas por que?

Vamos começar com listas sobre as características fundamentais para se tornar um bom desenvolvedor de software. Há quem diga que fundamental é a habilidade para resolver problemas, que ser preguiçoso (eu não gosto muito dessa palavra para denotar o que se tenta explicar) é um bom começo, enfim, listas e mais listas sobre o assunto. Em todas elas há uma faceta sempre presente, geralmente descrita de maneiras diferentes: a vontade de aprender, o gosto por aprender, o amor por aprender. Gosto de resumir as descrições de aprendizado como curiosidade. Para mim, curiosidade é o motor para me movimentar a ter iniciativa, daí para fazer coisas boas – outras nem tanto – acontecerem, o tal gosto por aprender, saber, descobrir, explorar. Iniciativa, vinda da curiosidade ou não, é o que eu chamo de “não coincidência”, mas espere, eu não vou enveredar por esse caminho, não é o propósito desse post.

Um dos grandes exemplos sobre como curiosidade pode ser benéfica é a Toyota. Lá a solução de problemas é feita com perguntas consecutivas para chegar à causa raiz, algo um bocado mais profundo e efetivo do que apenas apagar os incêndios que surgem no meio do caminho. Assim a Toyota lida com a causa dos problemas uma única vez, ao invés de lidar com as consequências várias vezes. Perguntar “por que” fundamenta a cultura de curiosidade que ajudou a Toyota a crescer sempre, não apenas porque os funcionários resolvem de vez os problemas, mas porque assim as pessoas aprendem, mudam de idéia, aperfeiçoam as que já possuem.

As empresas mais interessantes para trabalhar já perceberam o quanto precisam de pessoas capazes de aprender. Não é mais o caso de requerer um currículo com uma lista de siglas, mas de encontrar alguém que possa fazer essa lista crescer. Isso é imprescindível para software porque não existe uma tecnologia só para resolver todos os problemas, não existe um framework para preencher a vaga em todo e qualquer projeto. Você até pode tentar, afinal, faz sentido usar o que já se sabe, tanto que experiência é o item mais citado nas vagas de emprego. Está aí também o motivo pelo qual as empresas tentam usar uma gama pequena de tecnologias para desenvolver todos os projetos que chegarem à fabrica. Só que isso não precisa ser excludente com olhar pela janela para perceber o quanto outras alternativas podem ser bem mais interessantes, mesmo nos casos onde você já imagina como resolver o problema com o que já conhece.

ps.: Não que esse post seja tão bom assim, mas como curiosidade é importante para mim, resolvi renomear o blog para “Motor Curiosidade”. Acho um nome melhor do que o antigo.