Y! Open Hack day - 24h de hacking sem parar.

Depois de ter participado do Falando em Agile 2008, agora gostaria de falar um pouco sobre um outro evento que estou participando. Como vcs sabem recentemente me juntei a equipe do Yahoo! no Brasil e um dos eventos que serão realizados este ano é o Open Hackday. O Hackday surgiu há alguns anos no Yahoo! e sempre foi realizado internamente por funcionários ao redor do mundo, mas recentemente o Y! decidiu abrir o Hackday para qq desenvolvedor que deseje participar. Assim surgiu o Open Hackday, que já passou por diversas cidades ao redor do mundo como Londres, Bangalore, Taiwan e é claro em Sunnyvale. Além dos Internal Hackdays e dos Open Hackdays, ainda há uma iniciativa bem legal do Rasmus Lerdorf (criador do PHP) chamado HackU (ou Yahoo! Hackday University) que é focado em realizar Hackdays em Univerdades e já esteve em Stanford, Waterloo, Carnegie Mellon e mais recentemente Berkeley.

Agora chegou a vez do Brasil sediar o Open Hackday, o evento acontecerá nos dias 08 e 09 de Novembro na Centro Universitário Senac - campus Santo Amaro, totalizando mais de 36 horas de Hacking, TechTalks e muita diversão podem ter certeza. É importante lembrar que, assim como no RailsRumble, os hackers possuem um determinado tempo, no nosso caso 24 horas, para desenvolver suas aplicações.

Na verdade, o Open Hackday é parte de uma estratégia bem maior do Yahoo! que tem o objetivo de abrir seu social graph (mais de 270MM de usuários logados) e suas propriedades (Flickr, Delicious, Yahoo Mail, Profiles, Updates, Upcoming, MyBloglog, entre outros) para desenvolvedores e usuários e assim permitir que estes criem e construam novas aplicações e mashups sobre a infra estrutura do Yahoo. Esta iniciativa de abertura, chamada de Yahoo Open Strategy ou Y!OS, foi anunciada alguns meses atrás, mas esta sendo desenvolvida e preparada internamente há pouco mais de um ano. A primeira versão do Y!OS será lançada nesta semana (27 de Outubro) e conta com muitas coisas legais que tornarão o Open HackDay no Brasil ainda mais legal, pois uma série de recursos novos estarão disponíveis para os hackers Brasileiros em primeira mão.

Não deixe de consultar o Site oficial do HackDay aqui: http://hackday.org

E de dar uma olhada nas documentações das APIs no Yahoo Developer Network: http://developer.yahoo.com

No Twitter sigam o: @brhackday

Falando em Agile 2008 - retrospectiva

Na semana passada estive na Falando em Agile 2008, este foi o primeiro evento oficial ao qual fui como funcionário do Yahoo!. No geral foi tudo excelente e pude reencontrar diversos amigos (@pcalcado, @gchapiewski, @bardusco, @gcirne, @peleteiro) tivemos ótimos batepapos e trocamos várias idéias. Tb foi muito bom poder conhecer algumas pessoas como o Luciano Ramalho, Luca Bastos, Daniel Cukier, Danilo Sato, entre outros.

Para quem assistiu minha palestra, gostaria de agradecer a audiência e abaixo segue SlideShare da minha a apresentação, assim como alguns links que acho interessantes sobre o assunto que falei “O Product Owner e o Product Backlog”.

Links sobre Product Owner e Product Backlog:

• Creating Product Owner Success
• 10 ways to screw up with Scrum and XP
• Prioritizing your Product Backlog
• Becoming an effective product owner
• Priority Filters
• Product Owner Técnico
• Papel do PO e priorização do Product Backlog

Mais uma vez gostaria de parabenizar a iniciativa da Caelum ao realizar este evento, estas iniciativas são vitais para a nossa comunidade e realmente fazem a diferença.

Por favor enviem seus feedbacks, sempre há espaço para melhoramos

Distância ainda é importante

Eu não sou muito a favor do uso de ferramentas eletrônicas no gerenciamento de projetos tocados por equipes ágeis, no entanto, até o momento não tivemos que lidar com grandes distância entre membros de um mesmo time ou entre times na Globo.com. Existem diversas ferramentas digitais que se propõem a ajudar os times que estão distantes, a estruturar melhor a informação, gerar relatórios gerenciais e por ai vai. Algumas destas ferramentas são por exemplo o Mingle da Thoughtworks, o VersionOne, o Jira com Greenhopper entre outros, vc pode ver uma lista mais extensa dessas ferramentas no blog do Wayne Allen.

Ainda acho que tudo se resolve com um bom e velho whiteboard, lembrando um dos princípios do Agile Manifesto “Individuals and interactions over processes and tools“. Se for necessário gerar um report do andamento do projeto (ou do sprint) tire uma foto do whiteboard todos os dias e envie para quem precisa deste report. Não tem nada mais claro para verificar problemas e andamento de um time do que o whiteboard.

Hoje em dia a Globo.com esta recoberta de Whiteboards e os burndown charts podem ser vistos por toda a empresa, o que mostra como as coisas estão mudando por aqui. Mas isso não tira mérito das pessoas que tentam encontrar formas de melhorar o trabalho quando times precisam atuar em um mesmo projeto e estão separados geograficamente.

Nas minhas leituras esporádicas de RSS encontrei um post sobre um projeto interessante do Henrik Kniberg chamado Whiteboard Wiki (http://www.whiteboardwiki.org), que se propõe a recriar online, de uma forma simples e direta, o ambiente de um whiteboard.

De qq forma ainda acho que se vc tiver uma opção de manter o time co-locado, nem pense em outra alternativa, “Take It“. Em linha com isso esta um paper do Gary e Judith Olson chamado Distance Matters, onde eles apresentam um estudo sobre o uso de tecnologia como forma de diminuir os problemas da distância. Abaixo segue a conclusão deste Paper:

Collaborative work at a distance will be difficult to do for a long time, if not forever.There will likely always be certain kinds of advantages to being together. However, as a wide range of collaborative tools emerges, we will find useful ways to use them to accomplish our goals. If at some point in the past we had written a similar article about telegraphy, the telephone, radio, television, or fax machines, we would have had tables that catalog their shortcomings. However, in their own ways, all of them have turned out to have been useful for a variety of purposes, and they worked their ways into social and organizational life in enduring fashion. Indeed, some of the most profound changes in social and organizational behavior in this century can be traced to these tools. The rich repertoire of present and future collaborative technologies will have a similar fate. We will find uses for them, and descriptions of collaborative work in the future will enumerate the emergent social practices that have put these technologies to useful ends. But it is our belief that in these future descriptions distance will continue to matter.

Jeito Google e Jeito Apple de desenvolver produtos

Esta semana comprei a revista Fast Company de março, fazia um bom tempo que não a lia e o tema da capa era super interessante “The World’s 50 most innovative companies“, claro que na capa esta o case do Google. Ao ler a matéria “The Faces and Voices of Google“, achei uma frase dita pela Marissa Mayer que achei muito foda e tem muito a ver com o que eu penso.

“There are two different types of programmers. Some like to code for months or even years, and hope they will have built the perfect product. That’s castle building. Apple is great at it. Others prefer to have something working at the end of the day, something to refine and improve the next day. That’s what we do. The hardest part about indoctrinating people into our culture is when engineers show me a prototype and I’m like, ‘Great, let’s go!’ They’ll say, ‘Oh, no, it’s not ready.’ I tell them, ‘The Googly thing is to launch it early on Google Labs and then to iterate, learning what the market wants–and making it great.’

Some companies think of design as an art. We think of design as a science. It doesn’t matter who is the favorite or how much you like this aesthetic versus that aesthetic. It all comes down to data.”

Eu definitivamente penso em desenvolvimento de produtos com esta filosofia, (apesar de recentemente começar a gostar muito dos produtos Apple:-) acredito muito na premissa que li em uma entrevista do J Allard (head de games da Microsoft e responsável pelo projeto do Xbox) “if it’s a possibility that you may fail, then fail fast and learn“. Desenvolver produtos rapidamente e colocar estes na rua para que possamos pegar o feedback dos usuários o quanto antes e se for necessário fazer ajustes e incrementar mais features ou retirar features que não atendem as demandas dos usuários, é neste metodo mais “Googly” que eu acredito, desenvolvimento continuo e iterativo, com melhoria contínua e constante.

Ficar sentado em cima de um problema pensando anos como resolvê-lo da forma perfeita definitivamente não faz o meu tipo.

Para finalizar mais uma frase Googleneska da matéria, agora de um dos diretores de engenharia David Glazer, responsável pelo desenvolvimento do OpenSocial:

“…When in doubt, do something. If you have two paths and you’re not sure which is right, take the fastest path. What’s true in physics about objects in motion is true when you’re creating a product. It’s easier to keep moving and change course than when you’re sitting and thinking and thinking.”

Cone da Incerteza e SCRUM

Nos últimos meses eu tinha como foco implementar SCRUM na minha equipe, tudo começou com o Phillip Calçado me explicando o conceito de SCRUM, seguido de um curso com o Bloris Gloger que ele e alguns da equipe fizeram, e depois entramos em um caminho sem volta e nos focamos em implementar o SCRUM da melhor forma possível no nosso time. Acho que posso dizer que estamos muito bem neste momento, claro que ainda faltam detalhes mas o time esta andando e esta entregando software de qualidade a cada ciclo de desenvolvimento.

A próxima meta é escalar o SCRUM para toda a empresa, enquanto estava lendo sobre o assunto acabei me desviando e cai em alguns artigos muito interessantes que discutiam um tema que afeta todo e qualquer projeto de desenvolvimento de software: como estimar com precisão o tempo total para se entregar um software em produção?

Acabei caindo na teoria do Cone da Incerteza, que explica o fenômeno onde nós da indístria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.

Esta figura é facilmente associada ao desenvolvimento de um software, ou seja, se começa um projeto sem ter a menor idéia do tamanho dele ai vai se detalhando, escreve-se montanhas de papel com requisitos, desenha-se milhões de telas no Photoshop para fechar o design do projeto, ai finalmente depois de alguns meses é que se começa a escrever software efetivamente. Nestes casos existe uma luta constante para afunilar o cone o mais rápido possível. O grande erro das empresas é fazer um “commitment” com um projeto quando ele esta nas suas etapas iniciais, ao fazer isso elas estão aceitando uma margem de erro de 2x ou 4x nas estimativas, e é neste momento que o projeto começa a ruir.

O que é interessante em metodologias ágeis, como o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se vc perguntar a um desenvolvedor que já esta envolvido em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 6 meses, não fará a menor idéia e vai chutar uma estimativa qualquer pois não há como ter certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e o grande trunfo dos métodos ágeis é de entregar software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças.

Então em um ambiente ágil temos sempre mais certeza sobre as estórias que estão priorizadas para o próximo sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme o Product Backlog vai sendo entregue, mas sempre com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Lembrando que as estórias que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto.

Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza SCRUM teria este formato: