Isso costuma ser trazido muito à tona em conversas com amigos e conhecidos pois prefiro trabalhar em startups em oposição à empresas grandes e tradicionais. De alguma forma, startups estão ligadas a profissionais mais comprometidos, o que nem sempre é verdade, e muitas usam esse “status” para exigir longas e estafantes jornadas de trabalho. Ninguém deve se comprometer com esse tipo de vida, seja a empresa uma startup ou não.

Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo. E isso não é exclusivo à startups: esse tipo de atitude é necessária esteja você trabalhando em uma startup com mais três pessoas, em uma corporação gigantesca ou no seu próprio negócio.

Você iniciaria uma empresa para fazer algo em que não acredita? Penso que não. Então por que em um emprego “normal” isso seria diferente? Fazendo uma conta bem básica, são cento e sessenta horas por mês, durante trezentos e sessenta meses (equivalente a trinta anos), o que dá seis anos e meio continuamente fazendo algo que você não dá a mínima.

Enquanto você não inicia seu próprio empreendimento (talvez nunca), a solução é encarar o “trabalho para os outros” como seu empreendimento. Afinal, é isso mesmo o que ele é. O lucro (ou prejuízo) final pode não ficar na sua mão, mas o trabalho que você realizou e a sua satisfação com ele não dependem disso.

Se você não consegue enxergar isso como possível, é um ótimo sinal de que você deve parar de se lamentar e iniciar seu empreendimento. Comprometa-se consigo mesmo, independente do fato de, no momento, você ter um chefe ou ser o chefe.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

“This is one of the reasons I encourage entrepreneurs to bootstrap instead of taking outside money. On day one, a bootstrapped company sets out to make money. They have no choice, really. On day one a funded company sets out to spend money. They hire, they buy, they invest, they spend. Making money isn’t important yet. They practice spending, not making.”

– Jason Fried (37signals) em “Making money takes practice like playing the piano takes practice”

Escrevi dois posts para, no fim das contas, não conseguir expressar a mensagem. Minha falha foi tentar explicar demais o raciocínio ao invés de simplesmente expressar a conclusão (e ainda causei alguns acidentes no caminho). Pronto, através das palavras do Jason Fried, está aí tudo que eu quis dizer sobre o tema.

PS: Sim, os dois posts anteriores foram para o limbo. Como em todo processo criativo iterativo, as tentativas fracassadas podem ser descartadas.

A explicação é simples: no sistema de promoção por mérito, pessoas muito boas em dada especialidade são promovidas para outras áreas, para as quais podem ser menos aptas (claro, isso só ocorre quando a promoção leva o profissional a uma área em que suas habilidades atuais não são fundamentais). Dessa forma, cair nas garras do Princípio de Peter torna-se inevitável, levando a empresa a uma perda geral de eficiência ao longo do tempo.

A solução, segundo os cientistas, é reservar 50% das promoções para os piores profissionais da empresa – a chance de que eles “se encontrem” nos cargos aos quais são promovidos é muito maior.

Que desenvolvedor de software nunca topou com esse tipo de problema? Aquele cara, ótimo desenvolvedor, acaba sendo promovido à gerente (e aceita, seja pela grana, pelo status ou por falta de opção) e é simplesmente um zero à esquerda na função. É claro que isso acontece em qualquer área, mas é nesta em que eu tenho experiência.

Podemos tirar duas lições disso:

• Se, por ser um ótimo desenvolvedor, você for agraciado com uma promoção para outra área, pense duas vezes antes de aceitar – isso pode significar o fim da sua carreira como profissional competente. Se a empresa não lhe der opção (é bem comum que só se consiga um aumento aceitando uma promoção-bomba dessas), procure outro lugar – quando você realmente é competente, escolhas não faltam.
• Se você se tornar um empreendedor, primeiro busque ajuda especializada caso não se sinta à vontade com as tarefas necessárias nesse seu “novo cargo”. Você pode ser um ótimo designer com uma ótima ideia, mas isso não quer dizer que será um bom empresário. Além disso, pense bem na política de promoção que vai utilizar se a empresa for bem sucedida. Um exemplo: pode ser muito mais satisfatório recompensar os bons funcionários com melhorias salariais do que promovê-los a cargos para os quais eles não possuem aptidão.

No entanto, é preciso ter bastante cuidado. Métricas são como muletas: muito úteis quando você não consegue andar sem a ajuda delas mas, se você utilizá-las sem necessidade, vai enfraquecer suas pernas.

Um bom exemplo disso é uma métrica muito utilizada por quem escreve testes: a cobertura de código. É uma ferramenta muito útil quando é preciso “correr atrás” do prejuízo, isto é, adicionar testes a código sem cobertura. Nesse caso, é prática comum estabelecer uma porcentagem de cobertura a ser atingida dentro de um prazo limitado. Mas, se você pratica BDD/TDD consistentemente e não deixa código importante sem cobertura, é realmente necessário confirmar isso com um gráfico ou uma porcentagem?

O uso e confiança cega em métricas mesmo sem necessidade de um amparo como esse pode levar à má aplicação da técnica do desenvolvimento guiado por testes, já que ela passa a ser baseada em um número artificial – é muito fácil ter 100% de cobertura de código com uma suíte de testes ruim. Antes uma suite boa mas que, conscientemente, não passa por cada linha de código do que uma suite que execute cada linha, mas seja um lixo como especificação e ferramenta de refactoring.

Mais um exemplo de fragilidade fica claro no famoso e cantado aos quatro ventos code to test ratio: ao utilizar um framework de testes verboso, é fácil obter uma razão de linhas de teste por linhas de código muito maior do que utilizando um framework mais compacto ou macros. Me desculpe quem utiliza e divulga esse número como algum indicativo de qualidade, mas essa medida é simplesmente ridícula, além de totalmente ilusória.

Não, ainda não sou uma pessoa super-mega-produtiva, mas aqui está como consegui aumentar minha produtividade usando alguns truques (e o incrível sistema operacional que é o Mac OS X em conjunto com ótimas aplicações):

• Não verifique seu e-mail mais de quatro vezes ao dia: se você está esperando algum e-mail importante, peça para quem for enviá-lo que te avise quando isso acontecer, usando, por exemplo, uma SMS;
• Não verifique seu e-mail se você sabe que não estará apto a agir sobre alguma mensagem imediatamente: por exemplo, verificar seu e-mail de trabalho no final da tarde de Sexta – deixe para fazer isso na Segunda;
• Livre-se dos feeds que você assina: você não vai realmente sentir falta deles sem ficar um tempo longe. Se, após alguns dias, você sentir muita falta de ler um deles, assine-o novamente, mas não verifique seus feeds mais do que uma vez ao dia. Essa é uma excelente técnica para descobrir o que é realmente importante dentre tudo que você consome;
• Deixe que as pessoas sejam seu filtro: acredite em mim, se algo é realmente importante (ou banal, mas “quente”), vai chegar a você. Você não precisa ficar garimpando. O recurso de “shared items” do Google Reader é excelente nesse ponto – estou à caminho de usar apenas ele, me livrando de todos os feeds que assino (são por volta de oito hoje). Quando realmente precisar encontrar algo, o Google é seu amigo;
• Desabilite notificações desnecessárias: como muitas do Growl ou os “contadores vermelhos” nos ícones de aplicações na Dock do OS X – mantenha apenas as que você realmente precisa (por exemplo, eu mantenho as notificações do Propane, já que é importante saber o que meus colegas de trabalho dizem no Campfire);
• Não use um monitor muito grande: isso pode parecer estranho, mas pesquisas mostram que, após aproximadamente 26 polegadas, o tamanho do monitor diminui a produtividade. É óbvio: muitas coisas no seu campo visual vão lhe distrair. Use o Spaces e divida as telas de acordo com a tarefa (uma para programação, uma para navegação na internet etc);
• Aumente o espaço livre na sua tela eliminando itens do seu Desktop: configura o Finder para não exibir discos rígidos (eu deixo apenas discos ópticos e dispositivos removíveis). Elimine da Dock as aplicações que você não usa muito frequentemente. Use o QuickSilver ou algo similar para acessar as aplicações e arquivos que você não usa frequentemente, apenas não deixe que eles se empilhem na Dock e no Desktop;
• Elimine da Menu Bar os itens que você não precisa, como o ícone de status do Bluetooth, o indicador AM/PM se você usa o formato americano (é fácil saber isso olhando pela janela), o ícone do Time Machine etc;
• Use o Adium e configure-o para que fique oculto a menos que seja a aplicação ativa (veja aqui: ativo, inativo, configurações 1, configurações 2);
• Use o Fluid para criar SSBs para as aplicações web que você precisa para trabalhar: o motivo para isso é evitar ter um browser repleto de abas abertas te distraindo enquanto você usa uma aplicação para trabalhar. Com as aplicações Fluid você pode focar apenas na tarefa à mão;
• Use o Tags para facilitar o processo de organização e busca de arquivos.

É difícil tomar algumas dessas ações, como se livrar dos feeds que você assina – especialmente porque o número de feeds assinados geralmente é motivo de “disputazinhas” entre nerds/geeks. É estupidez pura, como competir para ver quem dorme menos e fica acordado programando por mais tempo.

De qualquer modo, dê uma chance. Após algum tempo (eu recomendo tentar por, pelo menos, dez dias), você vai sentir falta das coisas que realmente precisa e pode tê-las novamente assim que quiser.

Update: Como bem notado pelo ArthurGeek, a imagem de configuração do Adium para que a lista de contatos se esconda automaticamente estava errada (a que eu chamei de “configuração 2″). Arrumei o link e deixo aqui também: http://yfrog.com/avpicture12xp.

–

Também em inglês.

Dada alguma experiência que possuo com métodos ágeis, aqui vai um guia 100% garantido de como falhar utilizando-os. Todas as recomendações foram vistas em prática e são ótimas receitas para o fracasso, ainda mais quando utilizadas em conjunto:

• Não utilize equipes multi-funcionais
  Separe os membros em equipes de Criação, Desenvolvimento, Infra-estrutura e várias outras, assim como setores em grandes empresas. Mantenha-os distantes, de preferência em salas separadas, dificultando a comunicação (o pilar central dos métodos ágeis) ao máximo – sabemos que basta ficar em mesas separadas para que as pessoas se comuniquem apenas via e-mail, quando muito. Crie processos para que as equipes façam requisições umas às outras, faça com que isso seja demorado: com isso você desestimula qualquer resquício de colaboração.
• Espere até o final da iteração para avaliar as histórias
  Crie um processo de QA intrincado e lento. Faça com que a avaliação das histórias fique para o último dia da iteração – desta forma, se uma história não for aprovada, não haverá tempo para correção, garantindo assim mais um passo rumo ao fracasso.
• Não abrace a mudança
  Crie processos burocráticos com várias etapas, dificulte a resposta rápida e limite os profissionais o mais que puder. Deixe o caos reinar sob a desculpa de que não fará micro-gerenciamento quando, na verdade, não há gerenciamento nenhum. Não escute o que a equipe tem a dizer, esse bando de programadores, designers e administradores de sistemas não tem experiência com gerenciamento de verdade e não sabe o que está dizendo.
• Centralize o controle e as (in)decisões
  Crie comitês para qualquer problema, dos mais simples aos mais complexos. Responsabilize uma pessoa pelo controle de cada comitê, que deve fazer inúmeras reuniões, coletar muita informação e repassar ao responsável. Esse tem a tarefa de levar toda a informação ao “chefe” que, por sua vez, não decidirá nada e criará mais comitês. Dessa forma você garante que nenhuma decisão será tomada e todos os problemas se arrastarão até que se combinem no caos completo.
• Utilize “Agile by the book”
  Leia vários livros sobre Extreme Programming, Scrum, Lean e o que mais estiver na moda. Adote todos os processos do jeito que são descritos – o que, num primeiro momento, é bom, já que não há experiência. No entanto, recuse-se a modificar qualquer detalhe, mesmo que as coisas não estejam funcionando e que a experiência adquirida pela equipe aponte em uma direção diferente. Sempre refute qualquer argumentação com uma citação ao estilo “Ken Schwaber diz que…” (vale qualquer nome “de peso”), afinal Ken Schwaber está trabalhando junto à equipe todos os dias e conhece suas necessidades, correto?

Este é um trabalho em progresso. Quais práticas você adicionaria ao guia?

Waterfall é xadrez: você usa muito tempo para pensar e planejar, fazendo o máximo de esforço para tentar prever cada possível movimento durante o jogo. Dada essa natureza de muito planejamento antes da execução, faz sentido apenas em domínios muito estáveis e conhecidos, sem mudanças na demanda (geralmente em software de alto risco, como para voos espaciais).

Agile é futebol (ou qualquer esporte coletivo): as decisões durante o jogo devem ser tomadas muito rapidamente, sem tempo para análise de todas as possíveis consequências. Por isso, é “ideal” para domínios altamente dinâmicos e instáveis, com constantes alterações na demanda (como software para a web). Outra semelhança muito importante a ser notada é: mesmo que você tenha os melhores jogadores, se a equipe não jogar bem junta, o time não vence.

Assim como nem todos são bons jogadores de futebol ou bons em matemática, nem todos serão bons ou se adaptarão ao desenvolvimento ágil de software.

Note o destaque em negrito na frase acima, pois estou aqui falando de práticas ágeis para o desenvolvimento de software, uma coisa que o Scrum não é (o Scrum é apenas um framework gerencial “ágil”, podendo ser aplicado à projetos de software ou de outros mercados). Extreme Programming já vai além, sendo, essa sim, uma metodologia de desenvolvimento ágil de software (que, por usa vez, usa muitos conceitos gerenciais do Scrum no que diz respeito à comunicação intra e extra-equipe).

Cada metodologia possui um conjunto de princípios básicos, algumas possuem práticas e, outras, formatos bem específicos de documentos a serem seguidos fielmente. Algumas possuem tudo isso junto.

De acordo com o perfil psicológico, social e profissional, é comum que pessoas envolvidas em desenvolvimento de software (gerentes, desenvolvedores, designers, testadores etc) possuam suas preferências quanto à metodologias e práticas. Alguns se dão muito bem apenas com waterfall, outros apenas com agile, uns poucos com ambas e muitas outras. E isso é extremamente normal. As metodologias ágeis são vistas como a salvação do mundo do desenvolvimento de software, principalmente num mercado dinâmico como a internet. Mas, não se engane, nem todos os profissionais conseguem trabalhar num ambiente realmente ágil. Eles são piores do que os que conseguem? Não. São apenas pessoas diferentes.

Ambientes “ágeis” exigem um conjunto de habilidades bem diferentes em relação a outros tipos de ambientes. Geralmente, exigem também muito sacrifício pessoal em detrimento do próprio ego, sendo essa uma das principais barreiras para que se consiga implementar uma cultura de desenvolvimento ágil de software.

Alguns profissionais (desenvolvedores e outros) não estão acostumados e não querem praticar coisas como feedback rápido, desenvolvimento orientado por testes, daily meetings e as outras práticas que as acompanham. Desenvolvimento ágil de software não é apenas escrever centenas de post-its e colá-los num quadro branco ou numa parede. É estar disposto a mudar muitos hábitos e fazer alguns sacrifícios, aceitar algumas “imposições” das metodologias, trabalhar em equipe e para a equipe.

Se a pessoa não se encaixa nesse tipo de mentalidade, tudo bem. Não significa nada em termos de qualidade profissional, mas uma empresa que deseja trabalhar com métodos ágeis definitivamente não é o lugar certo para ela, já que ambos os lados sairão perdendo.

Não existe algo como um “framework BDD”. Tenha em mente que quem pratica ou não o BDD é o desenvolvedor. O que existe são frameworks ou bibliotecas que adicionam uma boa dose de açúcar sintático para facilitar o estilo de escrita para quem deseja praticar essa técnica de testes.

Os maiores proponentes do BDD enfatizam que a maior mudança em relação às técnicas tradicionais é mesmo a sintaxe. Porém, isso não quer dizer que basta utilizar uma sintaxe “mais legível” (o que é discutível também) para pular no vagão do BDD. A sintaxe bonitinha é um auxílio, uma ferramenta com o objetivo de diminuir as dificuldades na transição de um modo de pensar, que é onde a verdadeira diferença reside. Muitas dessas dificuldades são, inclusive, ditas de origem “psicológica”, como a abolição da palavra “test” nos nomes dos métodos para forçar o pensamento no sentido de uma verificação de comportamento ao invés de um teste de estado (medida defendida através da hipótese de Sapir-Whorf).

De fato, posso afirmar que a maior parte das suítes de testes escritas em RSpec, Shoulda ou test/spec que já tive a oportunidade de examinar (seja trabalhando, seja “navegando” por projetos open source – uma grande fonte de aprendizado), falha miseravelmente na tentativa de adotar o BDD, tropeçando feio em erros como verificar estado ao invés de comportamento, testar funcionalidades da linguagem ou framework e, principalmente, overmocking – chegando ao ponto em que um teste não verifica mais nada, apenas mocks e stubs – o que nos leva a testes quebradiços ou testes que não falham mesmo que você apague o código que eles deveriam verificar.

Esse último item leva a um outro ponto importante (e, aqui, uma visão muito pessoal – acredito ser compartilhada por poucos): acredita-se que o uso de mocks configura o uso do BDD, pois estabelecer expectativas em relação à interfaces e, consequentemente, isolar horizontalmente os componentes testados, passa a ser, “automaticamente”, verificação de comportamento. O uso de mocks não estabelece nada além de uma expectativa de interação – uma interface.

Como um classicista evito o uso de mocks (e dublês em geral), reservando-os para onde realmente é difícil ou pouco prático o uso de um objeto real ou, como deveria ser seu principal uso, uma ferramenta de design de código através da qual modelamos interfaces ainda não existentes à medida em que praticamos o TDD (ou seja, escrevemos testes antes da implementação do código real) – e os substituo assim que a classe real é implementada, quando aplicável.

Então, não acredite que por utilizar alguma ferramenta facilitadora, você, instantâneamente, estará praticando BDD. Estude a técnica e a filosofia envolvida e você poderá utilizá-la com qualquer ferramenta para testes.