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.




Seguir

Obtenha todo post novo entregue na sua caixa de entrada.