17 julho 2011

A Sociedade do Dojo e os Grupos de Capoeira - parte 1


Como podemos alavancar socialmente a prática do Dojo por meio do desenvolvimento do sistema de reconhecimento de mérito nas comunidades de Dojo, e o que podemos aprender com a história da Capoeira que possa nos auxliar nessa reflexão?
A sociedade está passando por um choque. O nosso sistema educacional retrógrado não serve mais para sociedade em rede. Ficar sentado numa cadeira desconfortável tentando prestar atenção a uma palestra chata pra depois decorar tudo em casa e responder a uma prova que não prova nada no fim do mês não é mais uma opção.

Mestre Pastinha
Manter um Coding-Dojo nos últimos anos me ensinou muita coisa. Bem mais do que aquilo que pretendíamos aprender codando (o que já foi coisa pra caramba!) O Dojo é uma metodologia educacional muito mais afim com a dinâmica do mundo novo. 

O ambiente participativo, onde todos são iguais e têm a permissão de errar; onde o exemplo substitui a autoridade do professor e a mão na massa substitui a explicação teórica; onde a prática deliberada e a curiosidade do grupo regem a ementa e o currículo - é esse o ambiente de aprendizado do Dojo e é o tipo de coisa que deve orientar a educação do século 21.

Mas essa forma orgânica e holística de aprendizado se choca diretamente com o modo ocidental de ver o mundo. Quando uma pessoa escolhe fazer uma pós graduação (cara, chata, noturna - depois do expediente de trabalho, já cansado - onde ela reconhece que vai aprender muito pouco) ao invés de participar da reunião semanal do Dojo (onde vamos comer pizza e rir um bocado, de graça, e aprender muuuuuito mais), nesse momento o sonho frágil é silenciosamente sufocado pela tradição estúpida da escola pós-industrial.

Ainda que as pessoas sejam apaixonadas pela visão de educação do Dojo, elas acabam optando pelo diploma! O dia só tem 24 horas, então as faculdades privadas medíocres se proliferam e a reuniões de Dojo seguem vazias. É triste =(

Mas não dá pra mudar o mundo todo de uma vez. Temos que pensar globalmente, mas agir localmente. Pode parecer meio ridículo, mas alguém tem que se permitir ser um pouco ridículo, senão a gente paralisa.

A idéia dessa série de posts que inicia aqui é apresentar pouco a pouco o manifesto que tentei proferir na AgileBrazil2011. Vou tentar degustar essa escrita aqui aos domingos de manhã.

Se estiver afim de discutir a respeito, acho que a lista de email  que criamos é mais apropriada que os comentários do blog.


05 julho 2011

Dojo, Capoeira, e muita discussão produtiva!

Esse post é o follow-up do OpenSpace que fizemos no 3o dia da AgileBrazil2011, sobre sistemas de mérito e reputação da Capoeira aplicados ao contexto dos grupos de coding-dojo.

Chegamos ao fim de outro AgileBrazil. O evento desse ano foi muuuuuito rico (pelo menos pra mim)! Um dos pontos altos foi ter apresentado minha palestra sobre Dojo e Capoeira, que rendeu um OpenSpace muito legal onde discutimos sobre o assunto. No evento do ano passado eu já tinha tentado motivar um outro OpenSpace sobre o assunto, mas acho que a idéia ainda precisava de algum amadurecimento e a conversa não vingou... Dessa vez parece que foi =)



O assunto em si, que apresentei na palestra, vou deixar pra um outro post, dedicado, que possa ficar como legado pra posteridade. Mas resumindo muito, apenas pra contextualizar, a proposta que apresentei foi a de desenvolver o sistema de reconhecimento nas comunidades de coding-dojo como alternativa ao modelo de mérito predominante no nosso mercado, baseado em certificações.

A idéia é se espelhar nos sistemas de graduação dos grupos de capoeira, e na história da nossa arte-luta, pra justificar e embasar o cultivo consciente de um mecanismo de reconhecimento que seja coletivo, contínuo, méritocrático e diverso.
A intenção principal é tentar equilibrar os relacionamentos dentro do grupo para talvez aumentar a retenção das pessoas, e a valorização social da prática (com todo o cuidado e a precaução necessários para não desvirtuar a prática e seus valores).

A proposta se concretiza hoje no desenvolvimento do DojoSpot, cuja intenção é funcionar mais ou menos como o StackOverflow, criando um sistema de reputação baseado no comprometimento das pessoas com a prática - só que nesse caso envolvendo a presença e a participação real (não apenas virtual, pelo site) das pessoas nos encontros.

O OpenSpace que organizamos no terceiro dia da AgileBrazil foi incrível! Juntamos umas dez pessoas que discutiram e refletiram sobre a proposta, seus pontos fortes e fracos, e deram várias idéias ótimas para evoluir a coisa.



A intenção agora é reunir os interessados em continuar a discussão nessa lista de emails, que acabei de criar:
 
http://groups.google.com/group/dojo-capoeira

Se vc está interessado, entre lá e se apresente.
Daqui pro fim de semana a gente dá início às discussões.

o/

30 junho 2011

[OpenSpace] Dojo, Capoeira, morte à certificação!

Pra quem está na #AgileBR 2011, estou marcando aqui o OpenSpace pra dar continuidade à discussão que iniciou ontem depois da minha palestra.

O OpenSpace será uma discussão livre sobre o tema - Desenvolvimento do sistema de reconhecimento nas comunidades de coding-dojo como alternativa ao modelo predominante de mérito, baseado em certificações.

Acontecerá amanhã (sexta-feira), no lounge, durante o coffee-break da manhã, às 11:00.
(assim ninguém precisa perder nenhuma palestra...)

Os slides da minha palestra, pra quem ainda não viu:

30 abril 2011

Gestão Pública e Agile: Quem deve mudar?



Tenho andado cada vez mais sem paciência com burocracias, regras sem sentido e culturas organizacionais enferrujadas. Mas sei que volta e meia perco um pouco da razão e pareço arrogante e radical com algumas ironias e sarcasmos. Por isso vou tentar me controlar um pouco nesse comentário.

O que me fez levantar da cama pra escrever nesse sábado foi o texto tuitado pelo @julioprotzek sobre a opinião de um advogado americano a respeito de porque Agile não funciona no setor público.

Já discuti muito esse assunto. É sempre um ponto levantado quando se fala sobre ágil em órgãos púbicos - coisa que fiz um bocado nos dois últimos anos.

Em poucas palavras o argumento é que como processos ágeis não são preditivos - não se comprometem desde o início com o resultado exato que o projeto vai ter no final - eles não se encaixam na estrutura de decisão que as entidades governamentais usam para contratar.

O governo precisa saber exatamente quanto vai custar, quando vai ficar pronto, e o que vai receber, nos mínimos detalhes. Isso por dois motivos: primeiro porque ele precisa comparar os fornecedores candidatos de forma imparcial e transparente, e segundo porque, se alguma coisa der errado, ele precisa ter alguém para responsabilizar.

(Interessante ver que os problemas são os mesmos aqui e lá)



A princípio, o argumento parece fazer sentido, mas acho que possui uma incoerência muito profunda.


As mudanças que a tecnologia da informação vem impondo ao mundo têm nos ensinado muito a respeito das velhas formas que usamos para 'administrá-lo'. O conflito entre pirataria e direitos autorais, entre o conceito trabalhista protestante e a ética hacker, entre a 'liberdade' de imprensa e as mídias sociais e as próprias relações econômicas, comerciais e legais num mundo onde as fronteiras geográficas importam (bem!) menos que as virtuais.

Enfim, o mundo está reaprendendo a viver, agora que a tecnologia expões teias de aranha bem densas na formas como estávamos acostumados a organizar a sociedade.

O processo de criação e engenharia não fica de fora dessa. Métodos iterativos de trabalho, baseados em feedback e confiança, equipes auto-organizadas e processos decisórios participativos são alguns exemplos de mudanças que Agile vem nos apresentando.

Continuar usando técnicas industriais para desenvolver software não vai funcionar! Chega de bater cabeça!

Então quando se diz que Agile não se encaixa nos processos de gestão que órgão públicos utilizam, pergunto: quem deve mudar?

Só pra não perder a oportunidade de ser um pouco sarcástico, deixo esse vídeo muito muito pertinente, em que tropecei agora a pouco quando estava na frente do computador quase quase desistindo de escrever esse texto. Enjoy!



Tuite esse texto.

19 março 2011

Mensagens de commit

Pra muita gente, pensar em mensagens de commit é uma coisa chata. Quando estamos descobrindo uma solução no código, o ato de parar um momento pra "commitar" e ainda ter que pensar numa forma rápida e clara pra descrever o último passo pode parecer quebrar a linha de raciocínio. O mais comum é que a ansiedade em voltar pro código faça o programador deixar essas mensagens em branco ou escrever qualquer baboseira.

Não faça isso!

Quem sofre é a pessoa que precisa depois achar o ponto certo pra reverter uma mudança, pra 'mergear' dois branches, ou pra recuperar uma peça de código que se jogou fora, mas então se percebeu que era útil.

Além disso, faço uma relação direta entre essas paradinhas e a organização pessoal das tarefas. Uma paradinha pra consolidar e deixar clara a finalização de um baby-step na evolução do código é muito muito muito útil. Sobre essa relação entre as mensagens de commit e o processo de organização (GTD, TDD, Pomodoro) prefiro recomendar que assistam à apresentação da cozinha ;-)

Minha dica:

Antes de mais nada, acostume-se com a necessidade de dar paradinhas frequentes e refletir sobre o que foi feito. Se você ainda não faz isso é porque ainda tem muito o que melhorar em suas habilidades técnicas como programador.



A hora de "commitar" é a mesma hora de atualizar seus micro-planos (em cartões, folhas de papel, aquivos txt, mind-maps, whatever), progressos, estimativas, etc.

Além disso, quando for pensar na mensagem de commit, uma boa recomendação é adotar o estado de espírito de quem está tuitando algo, mandando um email "dipé", comunicando o status da tarefa, ou batendo um chat com uma pessoa que está não em outro lugar, mas em outro tempo. Imagine que vc está mandando um SMS para o cara que está revisando o histórico do controle de versão, procurando o ponto exato onde se fez uma determinada mudança.


Como vários outros aspectos da programação, isso é apenas uma questão de disciplina e auto-aperfeiçoamento, que obviamente depende da boa vontade e da intenção em fazer um trabalho bem feito.

Da próxima vez que for comitar código, pense nisso.

o/

24 janeiro 2011

Arrumando a cozinha - Parte 3/3

De pouquinho em pouquinho, consegui enfim terminar de gravar a terceira e última parte da apresentação.

Essa é a parte que, tardiamente, costura as técnicas apresentadas no 1o episódio com a viagem do 2o.

Ficou com menos de 10min, caso isso ajude a te convencer ;-)



Arrumando a cozinha - Parte 3

Aqui está a primeira e a segunda parte, pra quem ainda não viu.

Já que estou chegando ao fim, cabe uma micro-retrospectiva pessoal sobre a apresentação:
- Acho que a analogia que apresentei deve estar cheia de problemas, mas acho que ela, no mínimo, esbarra de leve em algumas coisas bem fundamentais do movimento Ágil.
- Não gostei nada da apresentação que fiz pessoalmente na AgilBrazil2010 (que foi o que motivou essa gravação). Aprendi (mais uma vez) que a qualidade da apresentação, do discurso, das palavras, da postura, etc. são tão (ou mais) importantes quanto o conteúdo. Preparação prévia é fundamental para fazer uma boa apresentação!
- O 1o episódio ficou grande demais e talvez um pouco lento. Acho que aprendi a enxugar um pouco o conteúdo depois dele. Talvez eu o regrave algum dia...
- Acho que a parte 2, embora seja a que mais me interessa, ficou meio mal colocada no meio... Talvez a apresentação toda tivesse ficado mais digerível se essa parte tivesse ficado mais 'leve'...
- Alguns errinhos pequenos sobraram nas narrativas, nas passagens de slides, na codificação de video, e em outros pequenos aspectos. Mas nada que comprometa, acho eu... De qq forma, acho melhor entregar assim que ficar lapidando pro resto da vida... ;-)
- Me desculpem os que não gostaram da música (e até pediram pra tirar). Foi uma preferência pessoal que decidi manter.

De um modo ou de outro, posso dizer que o processo todo foi uma experiência muito legal. Desde a idéia inicial, passando pela estruturação das idéias até a gravação deste último episódio. Fui muito legal (mesmo que vcs não tenham gostado, hehehe).

Bom, cabe dizer por fim que se vc tiver gostado da apresentação, um comentário, crítica ou sugestão são sempre uma ótima forma de retribuir ;-)

01 dezembro 2010

O sorteio do iPod !!!

Gostaria então de agradecer penhoradamente às 10 pessoas que se voluntariaram para experimentar o plugin Besouro e contribuir com o meu trabalho de mestrado, conforme o anúncio que publiquei a 2 semanas!

0 Eduardo Santos Marques
1 Fabricio Nogueira Buzeto
2 Ian Gallina
3 Bruno Rolim
4 Mariana Vivian Bravo
5 Daniel Cukier
6 Laécio Freitas Chaves
7 Adolfo Gustavo Serra Seca Neto
* Hugo Corbucci
8 Saulo Arruda

Vale lembrar que ainda estou aceitando doações de Katas, mesmo sem o sorteio do iPod! Se quiserem colaborar, ou souberem de alguém que ainda pode fazer isso, estou às ordens... E feliz!  :-)

Estou tentando terminar um artigo para submeter à XP2011 até segunda feira, sobre esse experimento. Não vou conseguir analisar os dados de vcs até lá, mas fica o aviso aí... De qq forma, qndo tiver terminado a análise vou submeter os resultados do experimento em outras confs/journals e qndo minha dissertação for terminada aviso aqui tb...

Agora vamos ao que interessa ;-)

Conforme prometido, faremos agora o sorteio do iPod.

Vai funcionar assim:
   - Numerei os participantes aí em cima de 0 a 8 (o Hugo abriu mão do ipod, por isso ficou sem número), conforme a data de preenchimento do formulário, ao final do experimento.
   - No dia 04/dez, sábado próximo, vou pegar o número do bilhete ganhador do 1o prêmio no concurso 4507 da loteria federal.
   - Será o vencedor aquele cujo número corresponder a (número_sorteado MOD 9) :-D

É isso! A sorte está lançada! Que vença o mais sortudo :-P
Mais uma vez obrigado!

o/