Quem pode te interromper?

Remédio ou veneno? A diferença está na dose. Eis aqui uma breve reflexão sobre como a tecnologia pode acabar com a sua produtividade.

Não sei você, mas eu sempre tive dificuldade em me concentrar em algumas coisas. Leitura é uma delas. Se alguém passa na rua conversando sobre qualquer coisa que dê pra escutar, lá se vai minha leitura. Por isso eu só leio com fone de ouvido. De preferência ouvindo músicas conhecidas e instrumentais, que não vão surpreender minha mente e tirar minha atenção do texto.

Outras pessoas, como meu irmão, afundam a cara no que quer que estejam lendo e entram numa espécie de transe do qual só saem no terceiro grito, depois de já termos esperneado bastante em sua frente.

Alguns tipos de trabalho exigem um tempo relativamente longo de concentração, para que se possa enxergar toda uma linha de raciocínio até que se alcance os pontos de decisão realmente importantes.


Acontece que ultimamente tem se tornado cada vez mais difícil se concentrar no que quer que seja. Celular, SMS, Messenger, Twitter, Email. São todas ferramentas maravilhosas de comunicação, mas que podem acabar com a produtividade de qualquer um.

O celular é ótimo pra ilustrar isso. Seu celular tem autorização pra te interromper quando... você está lendo? quando está escrevendo? quando vc está no cinema? Quando está em reunião? Quando está no banheiro?! Tem gente que sai correndo, todo borrado, pra atender o celular a tempo...


Somos nós quem determinamos quando e como os meios de comunicação podem nos interromper. Pare pra pensar! A decisão está nas pequenas coisas. Quando seu celular vai pro "silencioso"? Quem tem seu telefone de casa? Vc deixa seu email sempre aberto na janela de trás? Twitter? Messenger?

Em tempos de escassa atenção, saber usar os meios de comunicação pode ser tão importante quanto saber gastar ou aplicar seu dinheiro.

O Trabalho no mundo 2.0

Nessa virada de século, o Trabalho (com T maiúsculo) passa por um processo de reformulação comparável ao que aconteceu na revolução industrial. A demanda por trabalhos criativos e a situação global como um todo mostram a necessidade de reformular os antigos processos e métodos à luz de mudanças importantíssimas que vêm ocorrendo em nossa sociedade, em especial o surgimento da Internet e todas suas consequências. O desenvolvimento de software e a cultura hacker possuem papel fundamental nessa mudança, assim como o próprio uso de computadores e programas pela sociedade. Fazem surgir - dentre outras coisas - novas técnicas, métodos, metodologias e processos de trabalho mais afins com a natureza do que estamos realizando (a sociedade como um todo), as quais cito nesse texto, por enquanto, apenas como fonte de pesquisa, motivação e conselho.

Já faz algum tempo que me interesso por metodologias, processos e coisas assim. Não é a toa que são as palavras no cartão de visitas do blog.

Nos últimos meses, tenho percebido varias coisas novas surgindo e se encaixando à minha frente. Já percebo sua correlação não é de hoje - venho filosofando isso com o Alê e com o Willi desde as primeiras conversas que culminaram no manifesto 2.0 - mas até alguns dias atrás essas coisas ainda não tinham se encaixado como um todo em minha cabeça.

Dentre os últimos arrebatamentos que ajudaram a unir as pontas, pra mim, está sem dúvida esse filme do TED, em que Dan Pink ajuda a distinguir claramente dois tipos de trabalhos (repetitivo e criativo), e de que forma isso influencia nas relações de trabalho.

A palestra do Akita na RailsSummit também se encaixou como uma luva nisso tudo. Mas foi a palestra do Roy Singham no Ágiles2009 quem realmente montou o cubo mágico que venho mastigando por pelo menos dois anos.

Talvez o ponto chave pra mim tenha sido me tocar da amplitude da influencia que o modelo de trabalho sequencial, "industrial", teve sobre a maioria dos processos e atividades realizadas durante o século XX. Já usei bastante em minhas apresentações e textos a imagem de processos sequenciais e a herança que esse modelo teve na indústria de software, mas nunca tinha me tocado do quanto essa influência foi além do nosso mundinho geek.


O modelo de fábrica

O modelo de trabalho industrial influenciou de forma muito marcante praticamente todas as formas de trabalho no último século. Basta pensar na forma como estão estruturados até os processos mais "humanos" de nossa sociedade: educação, alimentação, comunicação, saúde. Pense nos processos administrativos e burocráticos... Todos eles são estruturados em formas de trabalho muito semelhantes às das indústrias têxtil e automobilística. Quanta informação uma atendente precisa dar à outra para que ela continue o trabalho de montar o seu sanduiche?


O modelo de trabalho de fábrica é caracterizado por sua natureza sequencial, composta por especialistas que se comunicam por meio de interfaces estreitas, rígidas, e bem definidas. Os trabalhos realizados por eles, sobrepostos, resultam no produto final. É o que, em computação, chamamos de pipeline.

Esses processos primam pela repetição, monitoramento e visibilidade como ferramentas de controle do tempo, dos custos e do escopo do trabalho. Valorizam a rastreabilidade e o comprometimento de culpados, baseados em métricas objetivas, punições e recompensas. São muito eficazes para trabalhos repetitivos e mecânicos, razão pela qual mudaram a vida humana no último século.

Acontece que os avanços tecnológicos das últimas décadas vêm transformando o trabalho novamente. Seres humanos são cada vez menos necessários para realizar as tarefas repetitivas, e os trabalhos criativos têm se tornado cada vez mais importantes. Nesse novo mundo as velhas formas de trabalho não funcionam muito bem. Pipelines são péssimos para trabalhos criativos e colaborativos, assim como políticas de recompensa e punição, horário controlado, comando e controle, etc.

Nesse cenário, novos processos e métodos estão surgindo que se adequam muito melhor à natureza do trabalho criativo, que ao que tudo indica será uma das faces do século que inauguramos. O Alê chamou essas formas de "2.0". Eu uso também termos como "a nova forma", mas é preciso alertar que não pretendo com isso criar julgamento de valor (embora seja quase impossível não fazê-lo). Nenhuma das duas formas - a velha e a nova - é "melhor" ou "pior" em qualquer aspecto (a menos que queiramos ir mais fundo na discussão). Elas representam papéis diferentes em contextos diferentes.


Um novo modelo

Vejo essas novas formas surgirem com bastante evidência na área do desenvolvimento de software. Muitas delas têm suas origens nas comunidades hackers, que encontraram (criaram) enfim o ambiente necessário para restaurar a ligação entre trabalho e diversão que se perdeu com a ética protestante.

Os hackers despertaram da dormência as sementes da colaboração ao criar os mecanismos práticos que os permitiram botar pra funcionar talvez a mais magnífica criação humana desde sei lá quando: a Internet. Sem falar na infinidade de projetos open-source que existem hoje e sua importância no equilíbrio desse ecossistema.

Com o domínio dos meios de comunicação - e com o poder de recriá-los e transformá-los conforme sua necessidade - os hackers fizeram necessárias revisões de conceitos fundamentais, como os de nacionalidade e propriedade (començando pela intelectual). Sua organização meritocrática e suas motivações lúdicas - ao invés de financeiras - inauguraram (ou pelo menos recuperaram) uma ética que está mudando definitivamente as relações humanas.

Não é por acaso que a sociedade vem passando por outros processos de amadurecimento e conscientização, ligados direta ou indiretamente ao fenômeno da Internet. Ousaria relacionar essa salada toda à questão do "desenvolvimento sustentável", mesmo sabendo que terei que passar por pelo menos dois debates ferrenhos: com meu irmão e com o Sérgio. ;-)

Essa mudança de pensamento, ao que parece, está influenciando cada vez mais outras formas de trabalho e criação humana. Eu mesmo - pra não ir muito longe - já participei de dois trabalhos comunitários de tradução incríveis, especialmente se levarmos em conta que foram realizados por pessoas que nem ao menos se conheciam. Livros e discos não são mais vendidos em lojas, nem distribuídos por editoras e gravadoras. Em muitos casos, mal se sabe quem foram os autores. Imagine o que essa revolução fará (está fazendo) pelo design ou no campo da pesquisa científica.


Não estou obviamente reivinidicando nenhuma superioridade intelectual por parte dos programadores ou coisa assim. Esse pioneirismo não se trata de nenhum privilégio que a área da computação tenha, exceto pelo fato de termos tido a sorte de sermos os que mais estamos confortáveis com os novos canais de comunicação.

Também não estou dizendo que as técnicas citadas abaixo tiveram sua origem nas comunidades hackers. Apenas que foram influenciadas de uma forma ou de outra por essa cultura, e pelas formas de colaboração que dela derivaram.

É como se fossemos os matemáticos e "engenheiros mecânicos" da revolução industrial. (Qual terá sido o canal de comunicação que a indústria passou a dominar com sua revolução?) Com a diferença que os meios e conhecimentos necessários para produzir software hoje são públicos, estão disponíveis a qualquer criança curiosa - à distância de alguns cliques - e se transportam para nossa casa praticamente de graça, como num passe de mágica, com um simples download.


Novas técnicas e ferramentas

Nesse novo modelo de trabalho, algumas técnicas, métodos e processos estão aflorando e ganhando popularidade de forma muito rápida. Essas pequenas ferramentas empíricas retiram o foco de preocupação no trabalho que está sendo realizado e o colocam nas pessoas que o realizam.

Não foram novas máquinas, com tecnologia mais avançada que destacaram os japoneses na indústria automobilística nas últimas décadas. (Aqui está um caso clássico em que o método surgiu na indústria, e só depois foram adaptadas ao desenvolvimento de sistemas.)

As armas fundamentais que destacam as empresas de hoje ao meu ver (especialmente as de software) tratam-se de evoluções metodológicas - não tecnológicas. Processos sociais de organização de tarefas, estruturação mental e social, tratamento de fluxos contínuos de demanda e feedback, manutenção de atenção e estado mental criativo, auto organização de equipes. Essa é a natureza das grandes inovações do trabalho na era da informação. (Acho que não precisa nem comentar sobre a relação disso tudo com o manifesto ágil.)


Fiz aqui uma pequena lista de algumas técnicas e métodos que tenho aprendido (e tentado usar). Vou apenas citá-los, deixando o desenvolvimento dos temas específicos para outros artigos. Já entrou em meu GTD também a criação de uma palestra relacionando esses assuntos e criando o contexto para motivar o interesse nessas coisas. Ela deve aparecer em algumas submissões de trabalhos em eventos sobre agilidade nos próximos meses ;-)

Uma forma breve de descrever um possível objetivo em comum entre elas poderia ser o de organizar o fluxo de demandas e o foco de atenção de pessoas e equipes, tornando o trabalho efetivo por meio do equilíbrio entre planejamento, feedback e adaptação.


Vamos à minha lista:

Scrum

Não precisamos nem falar sobre Scrum, pois está bastante na moda. Embora eu não me dê muito bem com a popularidade repentina que ganhou, nem com as razões que a motivaram, cito ele aqui no lugar do XP por ser especificamente focado no processo organizacional da equipe e no planejamento e acompanhamento de atividades - tema que pretendo relacionar com outras técnicas que serão citadas em seguida. XP trata de outras questões além dessa (pra mim Scrum está contido em XP), então uso o nome Scrum pois acho útil poder me referir apenas a "essa parte específica" do XP.

TDD

Embora não tenha incluído o XP na lista, incluo aqui outra parte dele: o desenvolvimento orientado a testes (e seus desdobramentos). Trata-se de meu principal interesse profissional atualmente, que tomei para objeto de pesquisa em meu mestrado, e que incluo nessa lista por seu aspecto de organização de tarefas e focos de atenção mental, bem relevante à linha de raciocínio que ressaltei aqui.

O desenvolvimento orientado a testes leva a designs mais simples não por qualquer passe de mágica presente na técnica, mas pela organização das atividades e do foco de atenção dos programadores, e pela manutenção da confiança e coragem em mudar o design - todos fatores humanos!

GTD

Esse é o processo de organização pessoal que venho usando desde o início desse ano, e que tem sido pra mim - além de fonte de muita reflexão - motivo de grandes realizações pessoais, tranquilidade, motivação e alegria. Foi ele também o fio condutor principal que começou a costurar essas relações todas em minha cabeça.

É a técnica que organiza o fluxo constante de compromissos e responsabilidades pessoais que nos assola dia a dia. Sem um processo coerente de organização, essa enxurrada de pequenos problemas para resolver afoga a maioria das pessoas que, sem paz de espírito, não conseguem se concentrar no que fazem, perdendo tempo com coisas irrelevantes e deixando de lado as coisas importantes.

O GTD é um método indispensável para empreender, no sentido 2.0.


Pomodoro

Dessa lista essa é a técnica que conheço a menos tempo (umas duas semanas), e talvez a que começou a me ajudar mais cedo. (Basta mencionar que sem ela esse artigo não saía.)

Ouvi falar dela pela primeira vez no Ágiles2009 codificando junto com o BrianMarick.


Mal comecei a ler o livro e já estou viciado em contar tomates ;-) Trata-se da técnica com foco mais pontual, localizado e imediato de todas, que pelo menos pra mim representa o elo que faltava para relacionar GTD, TDD e Scrum de uma forma incrível. A técnica cria uma metáfora clara para a unidade de trabalho (e de estimativa) de forma lúdica e confortável, complementando as demais.


OpenSpaces, BirdsOfAFether, e WorldCafé

Esses são processos cuja finalidade não parece corresponder diretamente àquela dos supracitados, pelo menos à primeira vista, pois são métodos de organização de encontros e reuniões, ao invés de projetos - possuem uma natureza muito semelhante no que diz respeito aos princípios e soluções propostas.

Participei pela primeira vez de seções de OpenSpaces no encontro ágil do ano passado. O WorldCafé me foi apresentado pelo meu irmão antropólogo e tive o prazer de facilitar algumas reuniões assim no planejamento estratégico da SEA.


Coding Dojo

Esse talvez seja o mais estranho item dessa lista, mas garanto (e pretendo mostrar) que possui relações íntimas com várias das outras técnicas/métodos. Essa me interessa ainda mais profundamente por me permitir experimentar com algo que me é de grande interesse - o TDD - além de propiciar grande diversão, aprendizado e fortalecer laços de amizade.


Essa lista não pretende ser exaustiva sob nenhum aspecto. Pretende apenas ilustrar o ponto de vista e apresentar as ferramentas que estão se juntando na MINHA caixa. Servirá muito mais para polarizar a discussão e talvez fazer surgirem outras coisas que podem (e talvez devam) fazer parte dessa coleção.

O que mais me fascina nisso tudo é a relação que percebo entre os princípios que estão por trás dessas técnicas. Pelo menos pra mim, parecem ter emergido todas mais ou menos juntas. Foram todas descobertas empiricamente, longe das grandes empresas e centros de pesquisa.

Pretendo escrever sobre essas relações. Já tenho várias anotações sobre isso. Mas o objetivo desse post, que acho que já foi cumprido, era apenas o de compartihar essa visão geral, para poder me preocupar mais com os detalhes nos próximos posts.

Teste e design

Muita gente que conheço estranharia demais o fato de um artigo como esse estar em um blog sobre testes:

GoogleTestingBlog: How to think about OO

Ouço pessoas falando em reuso, em SOA, em arquitetura, bla bla bla..., sem nunca ter nem mesmo se interessado por coisas como essa.

Se você ainda não sabia, fique sabendo: testes tem tudo a ver com design.

Esse casamento é uma das coisas mais importantes que a indústria de software desenvolveu na última década, e a maioria das pessoas ainda está em discussões como "PHP é ruim, Java é que bom!"

O fato é que discussões riquíssimas, como a apresentada nesse artigo, praticamente não têm nenhum valor se você não escreveu testes automáticos desde o início do seu projeto. Não adianta nada você saber reconhecer um design ruim e conseguir propor outro melhor, se na hora H você não tiver coragem de fazer a mudança, com medo do impacto que isso vai ter.


Acredite. Praticamente 100% dos gatos que existem em todos os códigos do mundo são fruto de atitudes medrosas, fracassadas, do tipo "não véi! vamo mexer nessa parada não... Vamo dexá assim mesmo, senão a gente vai ter que mudar um monte de coisas..."

Então se você ainda estava parolando por aí e não tinha visto o bonde passar, acorde! Não dá pra fazer software de forma séria sem automatizar testes. Não dá! Só você (e os que trabalham com você) ainda não percebeu.

Deixa de ser cabeça dura e presta atenção no que está acontecendo!

O design está morto?

Outro dia um amigo cobrou o final da tradução que eu vinha fazendo do artigo do MartinFowler.

Não vamos mais precisar esperar, o pessoal da InfoQ.br se organizou mais rapido e traduziu o artigo todo.

Não deixem de ler!

Apresentação sobre Agile na Câmara dos deputados

Faz tempo que não reservo um tempinho pra escrever por aqui. Estou cheio de assuntos engatilhados, mas tenho andado meio comprometido demais com coisa demais... :-P

Assim que der eu volto a escrever com mais regularidade.

Por enquanto, aproveito pra deixar publicada aqui essa filmagem que o pessoal fez da palestra que apresentei na Câmara semana passada. Aproveito pra agradecer a gentileza do pessoal ter filmado e me passado.

.

Patterns e XP

Ainda traduzindo...

O exemplo do JUnit me leva inevitavelmente a trazer à tona os patterns. A relação entre patterns e XP é interessante, e é uma questão comum. Joshua Kerievky argumenta que patterns são pouco enfatizados em XP e ele coloca seu argumento eloquentemente, de modo que não preciso repeti-lo. Mas vale notar que para algumas pessoas patterns parecem ser conflituosos com XP.

A essência desse argumento é que patterns são frequentemente usado em excesso. O mundo está cheio de programadores legendários, frescos de sua primeira leitura do GOF que aplicam dezesseis patterns em 32 linhas de código. Me lembro uma tarde, movido por uma deliciosa puro-malte, planejando com Kent um artigo a se chamar "Not Design Patterns: 23 truques baratos". Estávamos imaginando coisas como usar um IF ao invés de uma estratégia. A piada tinha um fundo de verdade, patterns são frequentemente usados em excesso, mas isso não faz deles uma má idéia. A questão é como você os usa.

Uma teoria sobre isso é que as forças do design simples o levarão aos patterns. Muitos refactorings fazem isso explicitamente, mas mesmo sem eles, seguindo a regra do design simples, você chegará aos patterns mesmo que você ainda não os conheça. Isso pode ser verdade, mas será que essa é realmente a melhor forma de fazer isso? É claro que é melhor se você já souber de antemão aonde está indo e se tiver um livro que possa te ajudar com as dificuldades, ao invés de ter que inventar isso tudo por conta própria. Eu certamente ainda vou ao GOF sempre que percebo um pattern surgindo. Para mim o design efetivo implica que precisamos saber o preço que vale a pena pagar por um pattern - isso é sua própria habilidade. Similarmente, como Joshua sugere, precisamos estar mais familiarizados sobre como derivar um pattern gradativamente. A esse respeito XP trata o modo como usamos patterns de modo diferente do usual, mas certamente não remove seu valor.


Mas lendo algumas das listas de e-mail eu tenho o sentimento distinto de que muitas pessoas acham que XP desencoraja patterns, apesar da ironia que a maioria dos proponentes de XP foram lideres do movimento de patterns também. Isso é porque eles viram além dos patterns, ou porque os patterns estão tão impregnados em seus pensamentos que eles nem percebem mais? Eu não sei a resposta para os outros, mas pra mim patterns ainda são vitalmente importantes. XP pode ser um processo para desenvolvimento, mas patterns são a espinha dorsal do conhecimento sobre design, conhecimeno que é valioso tanto quanto o processo. Processos diferentes podem usar os patterns de modos diferentes. XP enfatiza tanto a não utilização de patterns até que eles sejam necessários como evoluir o código do seu modo derivando um pattern por meio de uma implementação simples. Mas patterns são ainda uma peça chave de conhecimento a se adquirir.

Meu conselho aos XPeiros usando patterns seriam:

* Invistam tempo aprendendo sobre patterns
* Concentrem-se em quando aplicar o pattern (não tão cedo)
* Concentrem-se em como implementar o patterns em sua forma mais simples primeiro, então adicione complexidade depois.
* Se você utilizar um pattern, e depois descobrir que não valeu a pena - não tenha medo de tirar ele fora de novo.

Eu acho que XP deveria enfatizar mais o aprendizado sobre patters. Não sei ao certo como encaixaria isso nas práticas de XP, mas tenho certeza de que o Kent pode descobrir um jeito.

Maré de Agilidade - Swell Salvador

Opa,

Só pra avisar que vamos fazer o MaréDeAgilidade versão Salvador-BA.

Ô meu rei, num deixe de participar! :-)