Sooner – extension para ReadItLater no Chrome

2 de novembro de 2010 by Léo Hackin 5 comentários

Salve pessoal,

Já venho brincando e pesquisando sobre desenvolvimento de extensões para Chrome e Safari. Do que era apenas playground, resolvi fazer uma extension bacana para Chrome para utilizar o ReadItLaterList.com.

O ReadItLaterList.com é um site que serve como um repositório de páginas para serem lidas depois. O site hoje conta com inúmeros softwares e extensões em vários softwares para utilização, mas resolvi fazer um para Chrome pois os existentes ou tinham bugs ou não agradavam de imediato.

Desenvolvi então o Sooner, uma extension para Chrome para trabalhar diretamente com o ReadItLaterList.com de forma fácil e que utilizasse as principais funcionalidades do RIL: ver páginas, adicionar e marcar com lidas.

A instalação é simples: basta baixar o arquivo CRX em http://github.com/leohackin/sooner/downloads e dar um duplo clique nele. O Chrome cuida do resto.

A configuração é bem simples também: basta informar os dados de login de sua conta ReadItLaterList na página de opções da extension (clique o botão direto no ícone da extensão) e se o login for feito com sucesso clicar novamente na extension para carregar suas páginas.

O utilização restante de leitura e adição de páginas segue essa simplicidade.

Para adicionar uma página, clique apenas em  ”Add this Page”. Para ler, clique sobre o link da página desejada na lista e para marcar como lida, clique no check verde. Tudo simples e direto.

A extension ainda está em fase de testes e na versão 0.6 e pode apresentar alguns problemas na hora de fazer o primeiro carregamento das páginas se houver muitas páginas. Estou trabalhando para melhorar isso e outras coisas para próxima versão. Para saber de novidades, siga as novidades pelo Github (http://github.com/leohackin/sooner) do projeto ou aqui no blog mesmo no link Sooner. :)

O agradecimento fica à namorada pela paciência, pelo Paulo @Jeveaux pelo incentivo e “cobaia-tester” e aos meninos da @giran_br por simplesmente existirem e proporcionarem tantas risadas e aprendizado contínuo. ;)


Share

Rails Rumble: Uma lição de vida

18 de outubro de 2010 by Léo Hackin 15 comentários

Salve todos,

Não vou ficar falando o que sempre falo: que sumi, que não tive tempo pra postar por causa da correria da Giran e blalablablba! AHE uAHEuhaeuhAE … Estou estudando bastante e agora vou ter bastante coisa pra postar por aqui. :)

Este final de semana participei do Rails Rumble 2010. O Rails Rumble é, resumidamente, um campeonato de programação que desafia as pessoas a construirem uma aplicação em Rails em 48 horas! oO E não é qualquer aplicação, pois eles avaliam beleza, estabilidade, inovação … enfim, é como se você tivesse que fazer um Twitter (ou algo tão inovador) em 48 horas. heheheh

Participei do time Shupla Hadouken dá hadouken ryu! com os brothers recursos da Giran, Almir M3nd3s (@m3nd3s), André Gligli Tagliati (@tagliati) e nosso convidado especial (e que adestrou a gente em vários lances do Rails) Reinaldo JuniorZ (@reinaldojunior).

A Giran patrocinou nosso time e mais mais dois: o Walter Fall e o Blastoise. Provemos o espaço, comida, bebida e o que foi preciso pra deixar todo mundo a vontade.

Porque falei “resumidamente”? Porque o Rails Rumble é, no final das contas, MUITO mais que uma competição.

Preparação = motivação

O  ”katá” para participar do evento foi/é uma puta motivação para quem quer entrar de vez no Rails. Durante um mês o povo da Giran estudou, discutiu, leu e codou bastante em Ruby/Rails. Ver todos se mobilizando em prol de um fim comum é algo que motiva demais até o mais preguiçoso dos programadores.

É fato e até algo psicológico isso: as pessoas se transformam quando estão em grupos e é assim que avaliamos o quanto as pessoas são realmente aquilo que elas dizem ser ou que achamos que elas são. Em todas as esferas possíveis.

Estudei muito (não tanto queria), quebrei a cara, me estressei mas foi algo decisivo para meu aprendizado Railer e do pessoal do meu time:  aprenderam bastante.

Idéia saindo do papel

A aplicação que desenvolvemos foi o Cashr, um gerenciador financeiro pessoal simples. Era uma idéia que já havia implementado no Django mas que não havia levado a frente. Preguiça, falta de tempo e entusiasmo: se já tem tantas aplicações pra quem mais uma?

Foi engraçado mas um dos meninos tinha tido A MESMA idéia. A vibe foi irada e geral. Qual não foi a satisfação e alegria em ver, depois de 48 horas de codação frenética e cansaço e muitas risadas, a aplicação rodando e fazendo MUITO MAIS do que havia imaginado fazer inicialmente.

Quem quiser dar uma sacada no projeto online: http://cashr.r10.railsrumble.com/

Tá dando uns pauzin e tem umas coisas incompletas, mas foi de coração. :)

Gestão de um projeto de 48 horas = desafio!

A largada havia sido dada, todo mundo à postos … e agora? Já tinhamos a idéia do projeto na cabeça e quase saímos meio Extreme Go Horse Development se não fosse a lucidez de fazer um mini Kanban das idéias principais. Mais que uma forma de organização foi uma puta lição de desenvolver de forma ágil, coisa que acredito ser um pre-requisito muito forte para qualquer pessoa que vá participar do Rails Rumble.

Entregar uma aplicação com a pressão de 48 horas, vontade de fazer o melhor e não fazer feio foi uma das lições mais legais que tive nessa esfera. E as pessoas à minha volta também pelo que vi.

Escopamos muita coisa para pouco tempo e braços, mas valew demais todo o esforço.

Extreme Happy Hour

Desde minha época de RPG, eu não tinha oportunidade de um happy hour nerd varando a madrugada tão divertido. Compramos pizzas, 2 Red Bulls pra cada um, refri, suco, biscoitos, Mendoratos … junte tudo isso com 12 nerds tarados em programação e lesados ao extremo e você tem a combinação perfeita para uma virada de madrugada de muito riso, programação e aprendizado.

Isso tudo com direito a Twittcam (você pode ver as gravações aqui), uma flood de twitadas durante a madrugada e tudo mais. O saldo foi cansaço mas aquele sentido de trabalho quase cumprido. IRADASSO.

Um por todos, todos por um

A mobilização das pessoas, até as que não estão acostumadas em trabalhar num time Scrum ou de qualquer metodologia ágil, é impressionante. As pessoas realmente entendem o quanto seu trabalho influencia o resultado não apenas do projeto mas do que o seu colega ao lado fez.

Foi como um XP atômico: pessoas codando frenéticamente, fazendo refactoring, criticando código, complementando o código alheio. Foi sem dúvida uma experiência única no que entendo ter sido uma das mais rápidas e emblemáticas que participei e vi.

Convidamos três pessoas: além do Reinaldo Júnior, chamamos o mestre railer Roberto Soares (@bt1) e o grande André Lima (@vixlima). Muito bacana como os três se integraram aos times e principalmente fizeram a gente perceber mais uma vez como as coisas trabalham bem quando as pessoas já tem um background ágil em suas mentes. Simplesmente fantástico. :)

Eu quero, eu posso

Uma palavra que ficou na minha cabeça desde horas antes de um desafio tão tenso, que expõe demais as pessoas no sentido técnico e psicológico (é a hora das pessoas verem até onde vai seu conhecimento e até onde você é humilde o bastante pra assumir isso ou ensinar as pessoas sem mesquinharias): superação.

Codar por 48 horas (não exatamente, mas pensar nisso por mais até que isso) não é apenas uma auto-superação física ou de stress mental. É superar o medo de não conseguir entregar a tempo, de saber que existem limites seus, de respeitar os limites dos outros de verdade. Superar a constante de que não sabemos tudo o que gostaríamos ou o quanto gostaríamos.

Não é papo de auto-ajuda: o Rails Rumble me fez sim uma pessoa melhor.

Extreme learning

Já falei tanto extreme nesse post que virou buzz. Não é a toa que dizem que uma das melhores formas de aprender Rails é participar do Rails Rumble. Muito aprendizado, muito problema real acontecendo em espaço de minutos e soluções para isso surgindo no vácuo.

Várias pessoas dos times não tinham muita experiência e chegaram no final da maratona falando e demonstrando o que aprenderam de uma forma muito coesa. Impressionante como as pessoas absorvem (e não apenas deixam na cabeça por um tempo) os aprendizados em situações de pressão e decisões que influenciam a vida das outras pessoas.

E no capítulo de hoje eu aprendi …

Nesse exato momento nossa aplicação está sendo avaliada pelos juízes e já recebemos até uma nota legal. :) O que fica aqui pra frente é que os estudos continuam e a coleta de idéias para o ano que vem já começou. SIM! VOU FAZER ESSA DOIDERA DENOVO NO ANO QUE VEM!

Para quem não fez, corra: é uma experiência tão singular quando a primeira balada, a primeira bebedeira (com a ressaca) e o que quer que seja tão significante.

Para quem gostou do Cashr, vamos continuar com o desenvolvimento dele e aceitamos colaboradores para o projeto, principalmente um designer pois tivemos que nos virar haehahe aueuah e.

Simbora! :D


Share

Moving to Python/RubyOnRails

13 de setembro de 2010 by Léo Hackin 20 comentários

Salve people,

Estava com saudades de escrever coisas por aqui bacanas mas estava às avessas com Giran, eventos e tudo mais. É claro que que a desculpa “falta de tempo” não existe quando você está motivado e focado em algo. Continuo motivado com muita coisa, principalmente com o crescimento natural e meio que imposto pela velocidade que as coisas estão acontecendo que pedem cada vez mais uma postura e abordagem que exige muita muita MUITA disciplina.

Mas uma coisa que não me motiva à tempos foi o PHP, não pela linguagem e sim mas todo um entorno que acabavam impactando diretamente na melhoria continua disso.

Frameworks

Larguei o CakePHP pelo CodeIgniter em busca de uma framework mais light e customizável. O CodeIgniter serviu muito bem, mas peca em duas coisas muito importante que era o suporte mais integrado à testes e um ORM bacana. Nem o SimpleTest nem o PHPUnit se mostraram muito bem integrados e o ORM mais bacana que achamos foi o Overzealous DataMapper. São duas boas ferramentas, mas que não atingiram totalmente (e juntas) o objetivo que era ter coisas estáveis pra desenvolver.

A pouco tempo palestrei sobre frameworks, mas acho que tem que melhorar muito até chegar num nível de maturidade legal. Ou seja, isso acaba atrapalhando e muito a questão de trabalhar com todas as ferramentas e técnicas possíveis para o desenvolvimento de aplicações com alto nível de qualidade. Para quem não demanda toda a qualidade que estou/estamos buscando, essas ferramentas são show de bola demais.

Existe uma certa carência de um set de ferramentas que possam trabalhar em conjunto para oferecer a sustentabilidade desejada para um projeto de, digamos, qualidade máxima.

Não estou dizendo que as ferramentas são ruins mas cheguei num ponto em que queria me focar mais no negócio e por isso espero ferramentas que ja estejam maduras o suficiente para que eu possa confiar nelas. Num certo ponto estava me preocupando com questões de estabilidade e funcionamento que eu esperava ja terem sido resolvidas pelos projetos.

Desafio

Por conhecer e programar em PHP a MUITO tempo, cheguei num nível que ou me dedicava ao desenvolvimento de uma ferramenta ou algo mais tenso para manter isso aceso ou partiria para a evangelização da linguagem, o que faço em partes como um dos coordenadores do PHP-ES. Desenvolver um projeto novo é legal, mas prefiro contribuir com os que existem com patchs e o que puder … e desenvolver algo novo deve primar pela idéia em si e não pela tecnologia. E se a idéia é nova, porque não brincar com outra coisa nova?

Mas lá no fundo entrei em loop no que tange aprender mais PHP. E isso, dentro do meu universo pessoal onde mudo e toda hora procuro algo pra fazer, chegou a um ponto que ficou insustentável. Como diria o poeta “Já deu …”.

Comunidade

Acredito que faça dois anos que começamos de fato com os eventos com o PHP-ES e estava tudo indo bem exceto por dois pontos:

  • a falta de mobilização da comunidade em prol de algo que não seja discutir salários e questões banais como sindicalização no forum
  • a falta de interesse do próprio time de coordenação em querer fazer as coisas da melhor maneira, ajudando no dia-a-dia e não apenas não-presencialmente

Não julgo ninguém, mas no fundo fui me sentindo meio que lutando e tentando fazer crescer um Mercado onde as pessoas de certa forma ou não se interessem tanto, enquanto comunidade, ou não estão preocupadas com evolução, isso tanto pessoal quando novamente em comunidade.

Me amarro em fazer eventos e ensinar o pouco que sei sempre, seja por blog, por MSN, em eventos ou o que for mas no caso de eventos é um sentimento meio chato não ver as pessoas se movendo em prol de um objetivo mútuo. Deve ser a idade chegando, mas já havia passado por algo em outras áreas de atuação (fiz muitos eventos de heavy metal que rolavam várias coisas do gênero). Se não existe comunidade, você luta pra fazer crescer uma. Quando já existe e você vê o desinteresse das pessoas, você precisa tomar descisões e a minha vibe é de “estou aqui pra ajudar mas tomar a frente não tão cedo”.

Porque Python/Ruby on Rails?

A escolha do Python e Rails foi a mais natural pois ambas são linguagens de script. Além disso, uma penca de coisas me levaram a escolher essas duas também:

  • comunidade irada
  • frameworks maduras
  • ferramental para testes e tudo mais maduros
  • Orientadas a objeto de verdade
  • Preparadas para o que der e vier

O Python/Django foi uma escolha bacana no sentido de que se pode desenvolver tanto para web quanto para uma pá de outras coisas, até pra iPhone. ;)

O Ruby/Rails foi outra escolha bacana por ser atualmente, sem modismo, uma das (se não a melhor) framework para desenvolvimento web, e que segue “por default” uma filosofia voltada à qualidade e agilidade. Vi várias coisas embasbacantes na QCONSP (vou escrever um post bacana sobre essas coisas) e é motivante ver tanta gente correndo atrás da melhora não apenas da ferramenta mas da comunidade toda em si.

Muitas oportunidades sempre rolaram em relação a desenvolver com elas e acho que chegou a hora de me dedicar a isso com força.

Então PHP nunca mais tio???

Deixar de estudar uma linguagem não é um “nunca mais trabalho com ela” nem coisa do tipo. Tive ótimos feedbacks em relação aos posts de TDD com o Simpletest e pretendo continuar (mas com PHPUnit talvez) com mais algo de Selenium … enfim, coisas mais voltadas à qualidade de código final do PHP do que o desenvolvimento dele em si.

Além de continuar falando sobre PHP em relação à isso, pretendo estar ajudando a comunidade seja como palestras, ajudando os amigos da coordenação com os eventos e todos que ainda puder ajudar ensinando algo porque afinal … eu gostcho!

Enquanto isso, vamos seguindo nossas vidas e seja o que Alah quiser.

Hugs!


Share

Review II WORKSHOP PHP-ES

28 de agosto de 2010 by Léo Hackin 14 comentários

Salve people,

Tava com saudades aqui do blog. Ae uhaeuhAEae A correria na Giran ultimamente está pra lá de frenética e estou estudando muito pra escrever algumas coisas legais aqui e de relevância.

Rolou hoje o II Workshop PHP-ES na UVV e posso dizer que por um lado foi muito foda e pelo outro um pouco triste.

O que foi muito foda

As palestras foram altamente maneiras. Um review muito bacana do rolou está no blog do Xiquin (http://www.franciscosouza.com.br/2010/08/28/ii-workshop-de-php-do-espirito-santo-foi-show), que palestrou sobre CodeIgniter com o André Tagliati, vulgo Gligli. A palestra dos dois, inclusive, foi muito bacana assim como as palestras do Marcelo Raposo sobre práticas mágicas no MySQL e de PDO com o mestre Almir M3nd3s.

Outro ponto foi a abertura do evento para assuntos fora do eixo técnico para ir para o entorno no mundo PHP, como a plafatorma Moodle com o Lucas Coradini (nunca pensei que um designer botaria banca num evento de programadores hehehhe zuera sacanagem) e a metodologia Scrum com o Paulo Jeveaux e o Makoto Hashimoto. A escolha dos assuntos não poderia ser mais feliz, porque nas contas finais eu achei as duas palestras mais informativas pelo público presente.

Este público presente foi outra surpresa: a imensa maioria era de pessoas do interior do estado, como Cachoeiro, São Mateus e Pinheiros. Isso nos mostrou o quanto de espaço pode-se ter junto a um público que geralmente só tem acesso a informação desse tipo vindo pra cá. Tivemos alguns contatos e esperamos levar eventos de PHP para lá.

O evento transcorreu muito bem e no geral foi muito bacana até mesmo pra mim que fui sob efeito de muitas drogas anti-gripais. O sorteio no final foi um show a parte de integração e diversão com direito até a contribuição de um brinde por parte da platéia (valew Fabiano!).

Por último, o apoio PRA LÁ DE F*DA da UVV e do prof. Vinicius Rosalen, que não apenas nos cedeu toda a estrutura para a realização do evento como ajudou com café e rosquinhas pela manhã e a tarde. E também da Giran, pela mobilização geral do pessoal no preparo de conteúdo, palestras para o evento e apoio incondicional na organização do evento.

O que foi meio triste

Palestrar, terminar slides, organizar evento e tocar evento doente é foda. Aliás, qualquer coisa nessa situação é foda. Queria ter estado melhor mas no final das contas estar doente foi apenas um empecilho. :P

Ter no cast de palestrantes uma galera da Giran foi uma honra pra gente, mas por outro lado mostrou uma coisa que quase inviabilizou o evento: não tivemos NENHUMA palestra submetida pelo grupo de usuários que povoa o fórum. Parece que as pessoas preferem discutir coisas abstratas como sindicato de programadores PHP (sic) que movimentar e dar apoio aos eventos da própria comunidade.

Seguindo a lógica, de 260 pessoas inscritas não tivemos nem a metade que seria o normal. E dos que compareceram uma galera era do interior e poucas pessoas da Grande Vitória. Agora não sabemos se há um desinteresse total das pessoas da Grande Vitória por PHP, se os tópicos das palestras foram mal escolhidos ou simplesmente as pessoas se cadastram por diversão. (risos) Isso trouxe um efeito bacana que é agora nossa vontade real de levar esses eventos para o interior.

Enfim …

Para um evento que esteve no limiar do cancelamento por falta de ânimo com um cenário onde nem palestras haviam para fazer o evento, foi um PUTA evento e que me recorda o feeling que eu tinha quando tocava heavy metal em shows que as vezes só sobravam 5 pessoas na frente do palco: você está ali pelas pessoas que ainda acreditam no ideal e no que você acredita e por elas VALE MUITO A PENA.

Simbora.


Share

II Workshop PHP-ES

20 de julho de 2010 by Léo Hackin 3 comentários

Aloha,

E lá vamos nós de novo:  depois de muitas barreiras, desanimo de fórum e até mesmo o pensamento de desistência, é com prazer que a venho confirmar a realização do II Workshop PHP-ES.

O evento acontecerá no dia 28 de agosto (último sábado) na UVV, das 8:30 às 18:00 e  será gratuito: estamos tentando alguns patrocínios para bancar um Coffee break básico mas até segunda ordem vai ser tudo o mais básico possível.

A grade confirma é:

PHPZeiro: Adote um Framework (Léo Hackin)

CodeIgniter: turbinando a produtividade com MVC (Francisco Souza e André Tagliati)

MySQL: Técnicas simples e eficazes para tirar o máximo do seu servidor Mysql (Marcelo Raposo)

PHP Data Object – Interface única de comunicação com SGDBs (Almir “M3nd3s”)

Moodle: fazendo EAD de qualidade com PHP (Lucas Coradini)

Aprendendo a começar um projeto com SCRUM (Time da Giran)

Como sempre, a idéia dos eventos de PHP-ES é agregar conhecimento aos desenvolvedores PHP não só da linguagem mas também em todo o seu entorno. Nesta edição vamos mostrar como as frameworks, como o CodeIgniter e o PDO, podem ajudar na produção de aplicativos de modo mais sustentável. Falando em base de dados, teremos uma palestra de “tunning” e macetes para fazer um ajuste fino do MySQL que foram feitas em cima de uma base de verdade com o DBA dela.

Vamos exibir também um case real e de sucesso feito com o Moodle, uma ferramenta PHP de Ensino a Distancia (EAD). No final do dia teremos um workshop de como iniciar um projeto com Scrum, metodologia ágil que está sendo bastante utilizada em várias empresas de desenvolvimento pela sua flexibilidade.

As inscrições pode ser feitas pelo link no página press-release do evento:

http://www.phpes.org/ii-workshop-php-es/

Estamos ainda à procura de patrocionadores e apoiadores: se estiver interessado ou conheça alguém afim de bancar o coffee break, peça para mandar um e-mail para leohackin@gmail.com ou m3nd3s@gmail.com.

Para mais informações acesse: http://www.phpes.org/ii-workshop-php-es/

Um abraço forte e até lá. :)


Share

#AgileBrazil 2010: Eu fui … e foi foda!

27 de junho de 2010 by Léo Hackin 17 comentários

Salve pessoal,

Resumir num post apenas o impacto de um evento da importância do AgileBrazil 2010 na vida de um desenvolvedor/gestor é complexo mas vou tentar dar apenas uma pequena e humilde visão do que foi isso.

Remontando alguns fatos, a Giran hoje trabalha muito fortemente com metodologias ágeis (Scrum/XP) a mais de um ano: ou seja, desde que montamos ela. heheh Mas é com o passar dos dias, projetos, pessoas, dificuldades e experimentos é que se consegue ter as reais motivações da definição dos valores do Manifesto Ágil e das técnicas usadas para se manter uma empresa ágil…

Mas ser ágil é o quê? Implementar o Scrum, seguir tudo que o manifesto ágil prediz, fazer religiosamente todas as fases antes e durante uma sprint: não quebrar as regras que agilistas e metodologias dizem? Ou seja, respeitar o processo do início ao fim? Você se mantém assim porque sua empresa é realmente ágil ou tornou sua empresa “ágil” apenas para dar um nome mais bonito ou mais hype pro seu “processo” batido do dia-a-dia com incrementos pra tentar levantar o moral da equipe e/ou vender sua empresa como uma empresa “inovadora” ou “jovem”?

É exatamente em eventos como o AgileBrazil que a percepção em relação à isso se torna EXTRAMAMENTE palpável, visível e de um bom senso tão argumentado e lapidado que chega a ser engraçado como as pessoas e as vezes nós mesmos não conseguimos enxergar algo que está na frente do nosso nariz.

A tônica do evento foi uma: você é realmente ágil? Está nessa pela fama | grana | hype ou qualquer coisa que realmente possa fomentar algo positivo pra sua empresa? Bote a mão no coração e pergunte pra si mesmo: porque você quer ser ágil ou se acha ágil?

As flexões mentais em relação à isso foram levadas a cabo por vários dias (no meu caso por dois) e horas, ensinados, desmontados, analisados e remontados por vários e principais nomes do movimento ágil do brasil e no mundo! Sim, O Martin Fowler em pessoa abriu o início das palestras e jogou luz onde geralmente ninguém vê (ou não gosta de ver).

Com uma estrutura de tirar o chapéu, feito na PUC com uma puta estrutura, uma bolsa com caneta, bloco e até caneca, a organização foi impecável em todos os sentidos possíveis. E o networking … essa parte foi um show a parte. Como disse pros brothers da Bluesoft, é muito foda ver as pessoas fora dos quadradinhos do Twitter e ver que elas são muito mais bacanas ao vivo.

Como eram muitas palestras, eu e meus companheiros na expedição (@jeveaux o @makoto_vix) nos separamos para cobrir o máximo de assuntos. Descrever tudo o que conseguimos absorver nesses dois dias ainda está cedo e talvez vire até post mas resumidamente vi:

  • Gente usando BDD/TDD pra substituir boa parte da documentação da descrição de requisitos (coisas que o cliente quer)
  • Como otimizar bastante do processo de TDD e torna-lo mais suave
  • Como ir além no uso do kanban
  • Integrar GTD + Pomodoro + Scrum + Platão (sim, rolou até platão)
  • Nomes de vários livros e sites FODARASSOS
  • Monstros da agilidade andando ali do lado
  • Porque a Giran é ágil …
  • E porque eu quero continuar com ela SEMPRE ágil :)

Se teve partes ruins? A única parte ruim é a saudade de casa, o café que acabou MUITO rápido nos coffee breaks e o cansaço nos aeroportos. Do resto, tudo muito foda. :D

E o que senti de verdade: é MUITO bom estar entre gigantes da agilidade e reconhecer que tenho (temos) que crescer, estudar e amadurecer muito e sempre. E ainda bem que existem eventos como esse pra irmos todo ano e continuar cada vez mais humildes, felizes … e ágeis.

\\// Vida longa e próspera a todos.


Share

Valorize pessoas, não processos

7 de junho de 2010 by Léo Hackin 27 comentários

Já dizia o Manifesto Ágil (e continua dizendo) como um mantra …

Indivíduos e interação entre eles mais que processos e ferramentas

Mas até que ponto nós, não apenas como desenvolvedores mas como pessoas, levamos à cabo como agilistas ou simpatizantes de metodologias ágeis esse princípio? Mais que isso: até que ponto temos consciência de quanto esse princípio rege não apenas processos mas todo o entorno e mais dramaticamente TUDO num projeto quando pensamos que TUDO é usado, avaliado e aprovado por outras PESSOAS.

MUITO MAIS que resultantes de desempenho, produtos de qualidade e projetos mais humanamente sustentáveis, esse princípio trabalha muito intimamente com o sucesso de uma empresa, marca e seus serviços.

Dúvida?

Meu problema com travas elétricas

Quem me conhece, ouvia muito falar uma frase quando pegavam carona comigo (um carro 4 portas) e viam que as travas estava todas manuais: “Vou levar meu carro amanhã pra consertar…“.

O problema não era inteiramente meu: apesar de ser um cara enrolado, existe um processo chamado “Agendamento” da concessionária que:

  • limitava-me a levar o carro bem cedo com um dia pré-agendado
  • me fazia deixar o carro lá e conhecer, em tese, o problema real na parte da tarde e com a possibilidade de pega-lo apenas no outro dia
  • me fazia voltar pro trabalho e sair dele pra pegar o carro de busão

Apesar de tudo, o processo funcionava bem dentro de um certo contexto, pois não precisava enfrentar fila de atendimento, com sorte eles lavariam meu carro (de grátis), seria feito por profissionais (recurso ou indíviduo?) treinados pra mexer com o meu carro e existia um prazo médio (embora pouco confiável) que poderia sair com o carro consertado no mesmo dia.

Os processos são muito importantes, principalmente em empresas de maior porte onde o padrão de qualidade do produto/serviço depende bastante de um fluxo de ações e validações que certifiquem que as coisas vão funcionar bem sempre e de um modo controlado. Em pequenas empresas e pequenos grupos de trabalho, um processo pode ser substituído em partes (ou até totalmente) por indivíduos e interações.

MESMO nas grandes empresas, ainda sim, os indivíduos e interações podem fazer uma extrema diferença na qualidade: afinal, todo processo é suscetível à inconsistências e nesse ponto o indivíduo, com sua experiência e todo tipo de qualidade pessoal, vai fazer diferença.

Então qual o problema/diferencial no processo? São os indivíduos.

Indivíduo #fail: o atendente/consultor (ou quem está na frente)

Liguei para a concessionária e fui atendido por um indivíduo que atendeu-me prontamente, mas com uma certa impessoalidade incômoda, e agendara meu atendimento para as 8:30 de um dia naquela semana. O dia chegou e o alívio/sossego/esperança de não ter que sofrer mais piadas como “[tom irônico] Amanhã né Hackin?” era tão latente que o dinheiro a ser investido na resolução do problema, naquele momento, era o de menos (não, eu não sou rico … quem pode falar coisas sobre ricos é meu amigo @makoto_vix).

Cheguei para o atendimento e o indivíduo atendente me chamou pelo horário, pelo “quem chegou primeiro?” e só depois pelo nome. A contar que não era o único ali, isso passaria batido pelo meu autruísmo exagerado se não fosse pelo tratamento recheado de “Uhun”s, de “Sei”s e sem uma resposta muito convincente ou entendível ao meu “Bom dia!” recheado de dentes: aquele estava sendo um bom dia pra mim, será que pra ele não? Seja lá qual o problema, estava diante de um indivíduo totalmente guiado pelo processo.

Um indivíduo guiado pelo processo é como estar em piloto automático: não importa o que você seja, ele esta ali apenas para dar fluxo ao processo. A dispêndio de energia e atenção se limita apenas ao que é necessário para concluir o processo. Talvez quem você é po$$a significar algo e otimizar um pouco as coisas.

O indivíduo atendente então me passou o número de meu atendimento e pediu-me para que ligasse por volta das 15:00 para saber do meu problema. Será mais econômico ao processo eu ligar para saber sobre meu carro ao invés do indivíduo? Liguei e fui informado que parte do serviço tinha sido feito (tinha pedido também pra alinhar e balancear) e que o problema das travas estava sendo concluído: eu poderia pegar o carro ao final da tarde. A esperança do produto em mãos me fez deixar pra lá uma interação linear e sem contato humano com este indivíduo.

Às 18:25 chegava na concessionária e recebo a notícia de meu indivíduo atendente que o alinhamento do meu carro não tinha sido feito e que não tinham ainda descoberto o problema real das minhas travas: de acordo com indivíduo atendente, o indivíduo técnico estava com a caixa de fusiveis e tudo mais aberto lá. Como o horário de fechamento era às 18:45, apesar de muito chateado – quase puto – resolvi esperar dizendo que precisava do carro e se talvez rolasse dele descobrir algo nesses 20 min: recebi um “talvez, mas eu acho difícil…”.

5 mins depois o indivíduo atendente me informa que o problema poderia ser que as 4 travas elétricas tinham queimado simultaneamente devido a algum curto e que o valor do conserto seria de R$ 1.000,00. Questionei como 4 travas poderiam queimar ao mesmo tempo e a resposta foi um “Eu também achei bem estranho e se quiser posso conferir com o responsável pela oficina amanhã“. Amanhã? Levei o carro sem consertar as travas e voltei para fazer o alinhamento (e perder mais tempo) dois dias depois. Estranhamente uma indivíduo atendente me ligou perguntando porque não havia levado: porque não haviam me ligado assim no mesmo dia para falar sobre meu carro ao invés de me fazerem ir até lá?

A história é meio grande propositalmente para apontar bem os detalhes do atendimento. Podemos detectar alguns problemas propiciados não pelo processo, que possivelmente não tinha problemas salvo algumas melhorias, mas pelo indivíduo que disparou as ações do processo:

  • o tratamento impessoal causou um efeito anti “Efeito UAU! de atendimento” (sou programador, mas aprendi com grandes pessoas grandes coisas – valew Márcio Gomes! – que me fizeram uma pessoa e profissional melhores): não me surpreendeu, nem encantou e isso ajudaria bastante à experiência de uso num todo. Mesmo com um resultado abaixo do esperado ou sem nenhum resultado, minha experiência de uso teria sido boa se a empatia do indivíduo envolvido diretamente em minha interação tivesse sido melhor
  • as pessoas são guiadas muito mais pela sua experiência de uso do que as vezes pelo preço: 1k poderia ser um valor justo por um serviço “especializado” se minha experiência de uso estivesse sendo boa. A insatisfação inicial gerou enfim o questionamento sobre o valor e a vontade de “pexinxar”. Quem nunca parou e comprou algo na primeira loja apenas porque o indivíduo envolvido no processo era tão bom que lhe fez sentir-se seguro com a compra.
  • o indivíduo comprometeu a confiabilidade do processo quando
    • me relatou que meu carro tinha apenas o problema das travas para resolver quando nem o alinhamento havia sido feito
    • demorou 5 mins orçar e relatar um problema que em tese não tinha sido feito nem descoberto por todo um dia mas por “mágica” foi feito em 5 min
  • o indivíduo se aproveitou dos gatilhos e ações do processo para conclui-lo mas de forma a startar apenas mais um processo para quem é dependente dele.

Então, do que adianta investir num processo bem feito se os indivíduos envolvidos na sua execução não estão “comprometidos”?

Várias empresas da área de tecnologia e desenvolvimento ainda acreditam que investir em processos seja melhor para a empresa do que investir nos indivíduos que executam esses processos. Você como empresário ou como desenvolvedor ainda acredita nisso? Tente imaginar algumas situações como:

  • Quanto do seu processo de relacionamento é otimizado pelo indivíduo que se relaciona diretamente com seu cliente, tanto na questão de prazos e requisitos quanto em tudo o que envolve o que não é diretamente relacionado ao processo mas tem TUDO para tornar a conclusão ou qualidade dele excelentes?
  • Quantas descisões são influenciadas pela empatia dos indivíduos envolvidos no processo?
  • Quanto da qualidade final do seu produto é impactado diretamente pelo indivíduo, devido às suas idéias mais que suas certificações?
  • Qual é seu melhor quantitativo de desempenho: um processo que segue seu fluxo de forma correta ou os feedbacks positivos de seus clientes em todas as esferas possíveis?
  • Como você garante que todas as etapas/ações de seu projeto estão gerando o máximo de retorno para o seu cliente? Ligações pós-atendimento de avaliação não conseguem desfazer o pior dos estragos que é a experiência de compra abaixo do UAU! ou até mesmo abaixo do mínimo aceitável para cada cliente.

Imagine-se como um cliente e todas as situações como essas que passei e pergunte-se de forma analítica, pessoal e envolvendo o que você avalia como importante num atendimento:

Na minha empresa o que me traz diferencial são os indivíduos ou meus processos?

Indivíduo #WIN: numa oficina de 5 indivíduos funcionários

Como sou brasileiro e não desisto nunca, aproveitei o feriado para procurar uma oficina. Numa cidade ao lado encontrei uma oficina com 5 indivíduos funcionários, entre eles o indivíduo dono.

Prestativo, um indivíduo funcionário me recepcionou de forma informal mas muito pessoal, perguntando como estava o dia e como poderia me ajudar. Expliquei meu problema e ele de pronto afirmou que quando uma trava parava todas paravam e poderia ser um problema no módulo. Pediu-me 10 min para que um outro indivíduo, que “mexia melhor que ele” com travas, pudesse me atender.

Esperei por 25 mins, mas com 2 ou 3 interações dos indivíduos da oficina me dizendo que não demoraria muito. O processo até aquele momento me parecia simplista e até intuitivo, mas a interação do indivíduo me trouxe uma calma do tipo “Sem problema, vou aproveitar pra ler um livro“. Findada a espera, José me deu bom dia de uma forma humilde e pessoal, abriu o painel onde ficava o módulo, mexeu pra um lado e pro outro vários fios e em 15 min ele me disse: “Deve ter rolado um curto circuito, pois a corrente chega aqui – me apontando a porta – mas as travas não funcionam. Vamos ter que trocar as 4 travas.”.

Minha experiência de uso estava sendo muito bacana, mas lembrar dos R$ 1.000,00 me deram um amargo na boca até que ele disse “O jogo de travas e o serviço fica por R$ 280,00 e você pode pegar no final do dia“. WOW!!!!!

Pára tudo …

  • Atendimento UAU!
  • Preço UAU!!
  • Prazo UAU!!!!!!

Assenti prontamente mas às 18:00, chegando com pontualidade inglesa por sorte, meu carro ainda estava faltando a ultima trava da porta. Durante os testes, um dos indivíduos dissera que o pino da porta da esquerda estava meio enpenada e a porta não tava fechando direito mas que já tinha ACERTADO ela para mim e agora estava “filet”. 40 mins depois do horário dos indivíduos e meu carro estava pronto, com teste geral de lanternas, vidros e tudo mais. Um “Boa noite” cheio de cansaço mas sincero até a ultima vogal.

O processo estava ali escancarado no final das contas:

  • Receber o cliente
  • Verificar o problema
  • Passar orçamento e prazo
  • Executar o serviço

Algo muito próximo e parecido com o da concessionária, mas o que fez a diferença COMPLETAMENTE foram os indivíduos… o José mereceu os R$ 15,00 da gorjeta pra tomar umas na sexta a noite e a oficina minha moral eterna pela ótima experiência de uso que acabara de ter.

  • o indivíduo proporcionou qualidade a um processo que prevê ações definidas mas que cobre apenas em parte a real experiência de uso de um usuário
  • o indivíduo, mais que o processo, é quem de verdade proporcionou a validação positiva do processo
  • processos são inflexíveis, lineares e o que se poderia ter de “inteligência de decisão” são nada mais que algoritmos que não se comparam à empatia e tato que um indivíduo pode ter no momento de uma venda
  • um processo não reconhece um sorriso como um feedback válido para alteração de um fluxo
  • processos podem burlar indivíduos, indivíduos podem ser burlados pros processos, mas é bem mais difícil um indivíduo burlar outro indivíduo (as vezes hahaha)

Construindo uma marca com indivíduos

Depois de tudo isso, podemos ter uma noção melhor do quanto o indivíduo pesa muito mais numa empresa que um processo. Empresas grandes e flácidas tem um grande problema quando trabalham com zilhões de funcionários e não conseguem detectar de forma enfática e hábil quando esses indivíduos fazem perder todo o processo ou pior: não conseguem enxergar quando esses indivíduos é que fazem toda a diferença no atendimento.

Podemos citar aquele garçom que você sempre procura no bar, aquele mecânico que você conhece pelo nome e não pela oficina em que ele trabalha… os indivíduos são nossa referência nos lugares em que vamos e mantemos um link de confiança e segurança. Quando temos pontos qualitativos sob a forma de indivíduos exemplares em nossas empresas, nossa empresa se torna mais pessoal, mais próxima de quem faz nossa empresa crescer: os usuários.

Agora, se a sua empresa é ainda pequena ou seu centro de produção ainda é restrito a um grupo menor, porque você ainda valoriza mais processos do que indivíduos?

É incrível como varios empresários ainda acreditam que os indivíduos são todos substituíveis, como porcentagens num planilha ou recursos no gráticos Gantt, e que os processos da empresa são o suficiente para a empresa continuar saudável … mas será que estabilidade é sinônimo de sucesso ou apenas de “acomodação”. Empresas não quantificam de forma efetiva o quanto de capital social e humano perdem quando deixam de aumentar um salário em R$ 100,00 ou proporcionar um ambiente de trabalho bacana para um indivíduo que pode representar a qualidade que seu processo tenta emular ou manter de forma artificial e não tão efetiva.

Exemplo clássico é a Giran, empresa em que trabalho e que me serve de inspiração para muito do que sempre pensei com meu sócio Jeveaux.

A Giran é construída pelas pessoas que a compõem: idéias, confabulações, inovações, melhorias de gestão, contratações e até o café que tomamos é uma decisão tomada pelos INDIVÍDUOS que temos em nosso time. Nada escapa ao julgamento das pessoas e nossos processos é quem acabam trabalhando a favor dos indivíduos e felizmente não o contrário.

O que a empresa é hoje lá fora é o reflexo do comprometimento e profissionalismo das pessoas que estão lá dentro. A “marca” Giran não é fruto de um processo admirado por todos: as pessoas admiram uma marca pelo que ela proporciona à elas. Em nosso caso, as pessoas sempre nos elogiam pela nossa abordagem, às coisas e problemas que estão à nossa volta de forma transparente, sincera e fluída. E quem faz isso são nossos indivíduos. :)

Indivíduos, Indivíduos …

Depois dessa Bíblia, a flexão mental sobre o quão importante um indivíduo é antes do processo tomou um bom rumo, mas longe de chegar ao tremendo brainstorm que isso pode se tornar dentro de sua empresa, entre seu time ou mesmo com parceiros, sócios e quem mais seja importante.

Alguns funcionários, pessoas ou “recursos” não tem a real noção do que eles são dentro de um organismo tão complexo quanto a experiência de uso que deve ser proporcionada às pessoas que se relacionam com ela.

  • um e-mail áspero de um programador, pode gerar um sentimento nada bacana com um cliente na frente
  • o modo como seus funcionários se comunicam com seus fornecedores e cliente pode estar gerando maus sentimentos
  • um “Bom dia … tudo certo” e um  ”Abraço” no final de um e-mail pode fazer a diferença (para melhor ou pior)

Agora imaginou o quanto você, do outro lado da moeda, já passou por isso e sabe (sinceramente) o quanto isso fez a diferença?

Pense nisso. :)


Share

Giran na QCon SP! #win

8 de maio de 2010 by Léo Hackin 10 comentários

Aloha! Postzin jabá realização de #sonhos! :)

É com IMENSO prazer que a Giran recebeu um convite para apresentar um case de sucesso na QCon SP este ano …… o que é a QCon????

QCon São Paulo – O principal evento de arquitetos e desenvolvedores chega a América Latina. O QCon SP traz, dias 11 e 12 de setembro, ícones internacionais e nacionais de diversas áreas, com apresentações de alto nível técnico. Com sistemas cada vez mais complexos, o QCon aborda não apenas uma única tecnlogia ou aspecto: passa de Java, .NET e Rails até Arquitetura, Design, Cloud, Escalabilidade, Replicação, Cache e casos de sucesso. Serão dois dias com mais de 40 palestras de alto nível.

O case que será apresentado será o da WINE.COM.BR, o maior e-commerce de vinhos da América Latina e eleita esse mês como uma das 5 lojas mais rápidas da internet brasileira dentre as GRANDES. A Giran é responsável pelo desenvolvimento, manutenção, extensão, novas implementações … enfim: exceto pela parte de design, fazemos tudo. =) Hoje MUITO mais que cliente-fornecedor, somos parceiros e amigos e isso é um ingrediente muito importante pra tudo isso dar certo.

Ou seja, é difícil expressar, tanto como desenvolvedor como empresário, o prazer/realização/felicidade que é receber um convite desses depois de um ano de trabalho duro, sério, feito com carinho mas principalmente do jeito que a gente sempre pensou que daria certo… e DEU! :)

O que nos deixa mais felizes ainda, é exteriorizar com fatos CONCRETOS que a Giran é o que é pelas pessoas que estão dentro dela, o que pra muita gente é apenas conversa ABSTRATA. Chegar num ponto desses é apenas uma constatação que existe sim vida (e que vida… hehe) após o SCRUM/Pair Programming/DailyScrum/XBOX/Cerveja-e-refri-na-geladeira/Pessoas-ao-invés-de-recursos-e-porcentagens até num mercado que muita gente critica pela falta de recursos como o do ES.

O case será apresentado pelo irmão-sócio-amigo Paulo Jeveaux e o nosso padawan, em breve Jedi, Gabriel Benz (@glbenz … tá na hora dele fazer um blog) junto com outras palestras com grandes nomes nacionais e internacionais. :)

No blog do Jeveaux tem um post bacana sobre o que será abordado e tudo mais!

Que força esteja com vocês e vida longa e próspera. \\//


Share

Programação em par … 1+1=3

25 de abril de 2010 by Léo Hackin 50 comentários

1+1=3

Aloha! O cálculo parece ser uma piada, mas na prática é o que este pequeno post vai tentar explanar e pontuar: programação em par rende e faz bem ao projeto, seja você uma equipe ágil ou não.

Programação em par (pair programming) é uma das práticas pregadas pela XP (eXtreme Programming) e metodologias ágeis em geral. Pra lá de polêmica (principalmente entre os gerentes de projeto e de “recursos”) a programação em par é o terror das empresas com poucas pessoas e/ou projetos com escopos malucos e sem vivência ágil, mas é exatamente ai que ela pode ser tornar uma puta aliada ao time, à empresa e aos projetos.

Como o próprio nome já diz, a programação em par descreve a prática de desenvolver software em par no mesmo computador: enquanto um programa o outro fica de “papagaio de pirata”, apontando erros, sugerindo coisas e pentelhando o amigo que está desenvolvendo. Elas se revezam no teclado de tempos em tempos e os objetivos disso são muitos.

Um segura, o outro bate

Esse é meu bródi!

João e Joca prontos!

Na vida real isso seria uma covardia, mas estratégicamente falando o fato é que se você entra numa briga com um amigo (principalmente que já chega na voadora) tudo fica MUITO mais fácil: você intimida o inimigo, aumenta a auto-confiança e a chance de ganhar a batalha de forma muito mais rapida e efetiva aumenta dramaticamente.

Num projeto isso soa da mesma maneira: a troca de experiências, fundamentos e principalmente sinergia de aptidões e especialidades eleva o nível de programação. O programador menos experiente ganha experiência e macetes. O programador mais experiente, refina seu conhecimento, encara novas possibilidades apresentadas pelo mais novo e lapida de forma fina conceitos da forma mais didática possível. :)

Então, existem vários pontos e consequências muito positivas quando você, gestor, e você , desenvolvedor “super-homem” e “lobo solitário”, programa em par:

  • a troca de conhecimentos fica transparente entre o par e o modo mais bacana de implementar aquele regra de negócio que “só o João é que sabia”  agora é sabida pelo Pedro, Joca e José;
  • a abdução pelo MSN/Talk/Twitter (ou as coisas que distraem) será bem menor devido à presença do par ao lado pensando “Coé! Vai trabalhar ou não p*rra?”
  • essa é pros gestores não ágeis: programação não é apenas digitação (= trabalho mecanizado) e sim um trabalho de escolha (tentativas corretas ou erradas). E nisso duas pessoas se saem BEM melhor (seja a caminho do #epicwin ou #epicfail).
  • o vínculo pessoal aumenta entre o par e com isso a confiança se fortalece, acabando ou diminuindo o “se fosse eu teria saido melhor”
  • com a confiança aumentada, o par passa a se comprometer ainda mais com o resultado final de forma muito natural, afinal a pessoa não quer deixar seu novo amigo na mão (e nem a oportunidade de fofocar um pouco durante o pareamento)
  • as soluções encontradas tendem a serem melhores documentadas/implementadas
  • psicologicamente, o par sempre vai querer mostrar “o seu melhor” para o outro
  • quando o par não souber resolver nada ele não vai conseguir passar O DIA INTEIRO abrindo e fechando a mesma tela enquanto pensa numa solução: o parceiro geralmente ou auxilia ou no mínimo vira mais um na pesquisa pela solução correta.
  • as barreiras pessoais caem e as pseudo-picuinhas ou viram picuinhas de verdade ou viram uma grande piada entre o par (e com sorte o time) depois de algum tempo
  • é uma das melhores formas que vi até hoje de fazer as pessoas entenderem o que é trabalhar em grupo
  • e por aí vai… :)

Mas eu não tenho time, eu tenho recursos

Muitos amigos/parceiros de outras empresas sempre perguntam pra mim e o pro povo aqui da Giran como trabalhamos porque eles mesmos já tentaram, tentam ou tem curiosidade de implementar metodologias ágeis em seus ambientes de trabalho. Geralmente o que me falam é que lá as pessoas são tratadas como recursos e não como um time.

Num dado momento as pessoas tem suas 8 horas/dia (hellllooow! aumenta isso ai tio!) de trabalho e isso no M$ Project fica lindo: afinal, podemos colocar o Joca alocado 70% do seu dia numa tarefa e 10% em outra e mais 20% numa outra completamente distinta. Ou melhor: podemos fazer o João entregar em 2d 4horas aquele módulo de detecção de XSS NO SITE INTEIRO.

Parte do problema que tento passar pros meus amigos é que as pessoas da empresa não são engrenagens mas sim pessoas, com seus problemas pessoais, limitações técnicas, dias ruins (que não rendem nada) e que nem deveriam ter começado. A partir do momento que os recursos não são considerados como produtores de porcentagens em planilhas mas sim pessoas que implementam escolhas e entregam produtos (resultado dessas esperadas BOAS escolhas), uma parte grande do problema se desfaz e o mundo fica até mais claro. :)

Mas, mesmo enquanto “recursos” (afinal, seu chefe não quer que os cronogramas os enxerguem de forma tão humana porque isso é perder dinheiro), ainda sim a programação em par se apresenta como uma ótima alternativa para driblar algumas limitações impostas pelo modelo manufatureiro (e antiquado) de produzir software:

  • você pode botar um recurso que está produzindo pouco para parear com outro mais “ativo” (ui ui ui) ou com mais moral da equipe interna: o recurso que está “patetando” vai se ligar rapidin e começar a “magicamente” trabalhar mais seja pela pressão do par, seja pelo poder de liderança que esse par vai ter sobre ele (as vezes o cara considera o amigo mais chefe do que você que em tese deveria ter esse poder)
  • liderar é servir: essa dica acima é muito importante quando você desejar criar um líder natural de equipe que faça as peças funcionarem sob alta temperatura sem rangir ou quebrar
  • faça seus recursos parearem ao menos no início de um novo projeto: assim, o alicerce ficará bem conhecido e a tendência do João levantar uma parede de gesso onde o José deveria colocar o quadro ultra-pesado diminui bastante. “Mas você não me falou que tipo de parede era e eu achei que essa iria dar conta do recado… p*rra, você nem pra me dizer que o quadro era tão pesado né?” (sinto cheiro de re-trabalho)
  • fazer par com aquele programador/designer/pessoa-difícil que todo mundo fala que faz tal coisa errada, mal-feita ou que poderia ser melhor vai ser uma maneira muito efetiva de faze-lo começar a trabalhar direito a partir de então
  • juntar dois recursos-difíceis assim pode ser uma ótima oportunidade de fazê-los melhorar em conjunto ou você matar dois coelhos com uma caixa d’água só

Passos de bebê para a programação em par

Bacana, legal! Mas tem gente que vai se perguntar: “Putz! Mas como transformar 8 pessoas em 4 da noite pro dia”. Tem muita gente doida (acho que essa é a palavra) que acha que radicalizar da noite pro dia vai adiantar ou ajudar em algo. Em se falando de programação em par então, isso fica ainda mais frenético. Na Giran mesmo ainda adaptamos continuamente nossa forma de trabalho com SCRUM/XP com idéias vindas do time, de coisas que lemos por ai e que descobrimos durante o dia-a-dia de trabalho. A programação em par foi uma dela e que nos deixa hoje muito contentes em levar à cabo.

Então, gostaria de compartilhar algumas dicas que podem ajudar você a fazer seu time ou seus N recursos a trampar em par e trazer um retorno de produção bacana num curto espaço de tempo, bem como você descobrir que isso NUNCA vai dar certo na estrutura da sua empresa (isso também num curto espaço de tempo):

  • faça pares com um iniciante e um mais experiente para que os conhecimentos trocados seja mais efetivos;
  • num escopo de uma semana, faça as pessoas parearem ao menos uma vez por dia por projeto;
  • se você trabalha com tarefas de um dia, faça as pessoas parearem em ao menos duas delas por semana;
  • um ótimo recurso para temporizar um pareamento é faze-lo em Pomodoros, que são boxes de tempo de 25 min (1 pomodoro = 25 min) em que as pessoas tem que manter o foco. 2 pomodoros são uma ótima pedida para começar um pareamento;
  • pareie pessoas com rendimento baixo com pessoas de rendimento maior (independente do nível técnico) para dar um choque de realidade neles;

Para começar isso já deve dar um pouco de “trabalho” para você, gestor ou líder na equipe, implementar isso de uma forma bacana. Uma forma legal de ajudar nisso, e em vários outros pontos, é você praticar reuniões rápidas matinais de 10 minutos em pé (prática conhecida na XP como Stand-up Meeting) para revisar o que foi feito no dia anterior: nesse ponto você vai identificar até que ponto os pares não apenas trabalharam juntos mas também fomentaram novas idéias e alternativas.

Por enquanto é só pe-pe-pessoal! Boas programações em pares e lembrem-se: programar não é apenas digitar. :)


Share

Maré de Agilidade em VIX

24 de abril de 2010 by Léo Hackin 8 comentários

<pseudo-sufista>
A vibe nerd vai ficar frenética em VIX em Maio. A Faesa vai ficar crowdeada de brothers e ninguem vai mandar o kaô.  :) Por isso eu vou mandar a pala, tá ligado?
</pseudo-surfista>

Acontece no próximo 29 de maio (um sabadão) na FAESA (Av.Vitória) o primeiro Maré de Agilidade em Vitória, carinhosamente chamado de Maré Vix. O evento vem uma semana depois do evento que rolará em BH no dia 22 de maio.

O Maré de Agilidade, que está chegando à sua sexta edição, é um evento itinerante que tem como objetivo disseminar as metodologias ágeis em todo o Brasil. Além do conhecimento, é claro que rolará muito networking entre desenvolvedores e gestores de projetos, negócios sendo fechados, muito café rolando e claro aqueeeeeeeele clima de evento de comunidade que todo mundo conhece. #win

Parafraseando meu brother-sócio-irmão Paulo Jeveaux, “O Maré Vix contará com uma programação bastante recheada e enriquecedora: teremos um dia inteiro com muitas palestras e uma mesa redonda com todos os palestrantes ao final do evento. Dentre os nomes confirmados para o evento, temos: Guilherme Silveira, com a palestra Um produto em duas semanas, Guilherme Chapiewski, Denis Ferrari sobre Domain-Driven Design, Fabrício Vargas Matosfalará sobre TDD e Jeveaux, sobre Negociação de contratos.“.

O evento contará com vários patrocinadores e apoiadores. Entre eles, com muito orgulho estará a Giran. :) #epicwinever

Para quem quiser ver mais detalhes do evento e coisas do tipo, visite o site do evento: www.mare-vix.com.


Share
Get Adobe Flash playerPlugin by wpburn.com wordpress themes