A maioria dos sites implementa chamadas AJAX usando o atributo onClick da tag html a. Ex:

  
    Próxima Página
  

Até aí tudo bem. Funciona que é uma beleza, o youtube usa isso, etc. O href=’#’ é usado para não gerar um request pro servidor, usando um recurso simples do html, a âncora.

Se você paginou até a 7a página e quer passar o vídeo para um amigo, com a 7a página selecionada para mostrar alguns vídeos que lá estão, de repente um seu que está ali por exemplo, só com o recurso onClick não seria possível. Teria que pedir para ele paginar e olhar. Mas há uma maneira de fazer isso, e um amigo lá do trabalho, Tiago Motta, fez uma classe javascript que possibilita passar o contexto de todos os boxes da sua página que funcionam com ajax no link para seus amigos.

É o projeto TralhaController: http://github.com/timotta/TralhaController/tree/master

Mas Bruno, comofas/

Esta classe javascript, após você adicionar um observador, ela começa a monitorar a URL do usuário por mudanças na âncora (#). Vamos aos exemplos:

A partir daí o TralhaController passa a monitorar a URL do usuário. Vejamos como montar o link que muda de página no box:

  
    Próxima Página
  

Dessa forma, quando a URL mudar, o observador que programou e adicionou ao TralhaController será notificado e o método update será chamado com a url “http://seu-site-aqui/#pagina_box_videos_relacionados=2″, sem mudar de página, possibilitando que seu observador faça uma chamada ajax atualizando o box.

Até aqui o onClick também faria. A novidade é que se você copiar este link e passar para um amigo, ele conseguirá ver o vídeo/página/qualquer coisa que estava vendo e o box estaria paginado na segunda página, ou seja, o mesmo contexto que você via, o seu amigo também verá pois ao acessar a página seu observador será notificado e atualizará o box com a página certa.

Espero que este projeto os ajude. Ele implementa um padrão de projeto conhecido: O Observer.

O primeiro passo é desabilitar o framework ActiveRecord no arquivo config/environment.rb

# config/environment.rb
Rails::Initializer.run do |config|
  config.frameworks -= [:active_record, :active_resource]
  # outras configuracoes aqui
end

Agora voce deve deletar o arquivo config/database.yml e comentar as seguintes linhas do arquivo spec/spec_helper.rb

# spec/spec_helper.rb
Spec::Runner.configure do |config|
  # config.use_transactional_fixtures = true
  # config.use_instantiated_fixtures  = false
  # config.fixture_path = RAILS_ROOT + '/spec/fixtures/'
  # nao comente outras configuracoes
end

Agora o rspec funcionará numa boa. Você também notará que não conseguirá usar o logger do rails como usava em seus models do ActiveRecord. Para utiliza-lo, basta usar a constante RAILS_DEFAULT_LOGGER. Exemplo:

# app/models/aluno.rb
class Aluno
  def ola
    RAILS_DEFAULT_LOGGER.info "falando ola mundo"
    #PPDD - Passei por aqui driven development
    RAILS_DEFAULT_LOGGER.debug "passei por aqui"
    "Ola mundo"
  end
end

Fica aqui a dica

Identificado o problema, comecei a pensar sobre tudo o que eu fazia durante o dia, sobre o que precisava ser melhorado para que eu pudesse ter mais performance, mais produtividade e gerar mais valor em menos tempo. A primeira coisa que reparei foi que as ferramentas que eu usava estavam me atrapalhando. Olhei em volta e percebi que um dos meus amigos (Vitor Pellegrino) no trabalho usa um editor de texto não usual como IDE e que com aquele editor ele se mantinha mais focado.

Este editor é o emacs. Vitor Pellegrino, como de costume, ficou empolgado em saber que eu queria aprender sobre o emacs, me enviou um monte de material sobre o emacs e se prontificou a me ajudar no que fosse preciso para que aprendesse mais rápido. Inclusive, faço propaganda aqui de um screencast do peepcode sobre o emacs que é muito bom: Emacs Peepcode.

Depois disso, veio a organização do desktop do Ubuntu. A primeira dica foi o projeto dotfiles do Ryan McGeary no github. Nele, há todos os arquivos que começam com ponto (.), ou dotfiles, do seu home guardados no github com um install.rb para instalar no seu terminal linux. Isso facilita muito ao formatar/trocar de micro pois todas as suas configurações ficam lá. Inclusive todas do emacs também. O meu dotfiles no github fica aqui.

Continuando no desktop, configurei meus desktops virtuais para uma matriz 2×3. No primeiro desktop fica o emacs e um terminal. No segundo, tudo de comunicação: email e gtalk/y!, no terceiro fica tudo que me faz procrastinar: basicamente o google reader, no 4o fica o browser onde testo a aplicação que ta sendo desenvolvida no primeiro desktop, no 5o e 6o alguns terminais rodando os servidores/logs/e qualquer lixo que eu resolva abrir. Denovo, dando o mérito a quem é de direito, isso também foi dica do Vitor Pellegrino.

O próximo passo era gerenciar meu tempo melhor. Ainda não tinha achado nada eficiente para resolver esse problema. É engraçado, quando você fica genuinamente querendo resolver um problema para melhorar sua vida e só aí passa a enxergar as soluções a sua volta. Coincidentemente, o @unclebobmartin twittou outro dia sobre a técnica do tomate (Pomodoro Technique). Por mais engraçado e simples que esta técnica possa parecer, resolvi testar, até porque o Uncle Bob e o Jim Weirich, duas pessoas que admiro, a utilizam. Venho tendo muito sucesso, meus amigos até me perguntam se eu estou dentro de um “pomodoro” quando querem falar comigo.

A técnica do pomodoro consiste basicamente em ter um timer (aqueles de cozinha) setado para 25 minutos, o que ele chama de um Pomodoro, e trabalhar em uma tarefa do seu to-do list. Ao acabar o pomodoro, devo descansar 5 minutos antes de iniciar o próximo. A cada 4 pomodoros, descanso 15 minutos. Entre cada pomodoro é a única hora que posso ir para meu desktop da procrastinação (o terceiro desktop), fazer pausa para ir ao banheiro, encher a garrafa de água, enfim, qualquer coisa não relacionada ao trabalho. Existem mais detalhes sobre a técnica, como por exemplo como registrar os pomodoros (to-do list), etc. Recomendo a leitura do livro no site (é gratuito) a quem interessar.

É claro que todas essas escolhas funcionaram para mim, mas podem não funcionar para todos. Não existe uma única maneira eficiente de melhorar sua produtividade, acredito que cada um deve buscar a sua. O mais importante é tentar melhorar continuamente e ser honesto consigo mesmo, identificando o que realmente pode estar atrapalhando tudo (dica: Geralmente é algo que você gosta muito).

Gostaria aqui de agradecer ao pessoal do meu time por todo o apoio, feedback e toda a ajuda para que eu pudesse identificar e implementar tudo isso, em especial agradeço a: Vitor Pellegrino, Guilherme Cirne, Anselmo Alves e Tiago Motta. Sou fã de todos vocês individualmente !

Nos vemos lá.

Product backlog é um documento de alto nível do projeto. Nele é contido todas as features, wish-lists, etc. que o cliente deseja para o sistema descritas de uma maneira bem abrangente e na linguagem do cliente, que chamamos de “histórias”. Cada história contém também uma estimativa de complexidade e o valor de negócio da mesma para o cliente, para facilitar na priorização.

Um exemplo de uma história é o seguinte: “Para poder ter uma experiência melhor assistindo um vídeo, eu como usuário gostaria de poder assistir o vídeo em tela cheia“.

A primeira etapa foi marcar uma reunião com os envolvidos para ouvir deles o que eles tem hoje, o que os atrapalha, e o que eles querem para resolver seus problemas. Do ponto de vista técnico, que é o que vos apresento, o maior desafio é se ater ao “O QUÊ” ao invés do “COMO”. Ouvir o que eles querem fazer, o que eles precisam, o que os atrapalha, etc. Por vezes me peguei com vontade de perguntar se queriam isso dessa ou daquela forma, e precisei me conter para não tirar o foco da reunião.

Depois dessa reunião nós tivemos uma visão mais clara da necessidade de nossos futuros clientes e resolvemos reunir o time e conversar a respeito, visto que serão eles (e eu) que iremos desenvolver o produto. Essa reunião foi muito produtiva pois levantou diversos pontos que ainda precisavam ser trabalhados.

Já aí temos alguns pontos desse nosso processo:

1. Se reunir com o time do cliente e o cliente e ouvir deles os “o quês”
2. Se reunir com o seu time e discutir os pontos levantados
3. Marcar uma reunião com o cliente e o time do cliente para dar este primeiro feedback.

Como podemos ver, a presença do cliente é fundamental. E esse ciclo de reuniões já produz um primeiro feedback. Tivemos uma nova reunião para passar o feedback e atacar os pontos levantados. Tudo isso foi feito em menos de uma semana, o que é o mote das práticas ágeis: ciclos curtos de feedback.

A partir destes 3 pontos já é possível rascunhar um primeiro product backlog. E, como seguimos o scrum e práticas ágeis, isso não é nenhum problema, pois o product backlog é aberto e modificável.

Essa foi a parte 1 do processo de criação do product backlog. Em breve estarei escrevendo o próximo da série, enquanto avançamos com a criação product backlog.

O meu post hoje foca na visão do projeto e as dificuldades em criá-la, principalmente para um produto já existente, que é o caso da empresa onde trabalho, que há algum tempo resolveu adotar o Scrum.

A visão do projeto é basicamente o que o nome diz: é o motivo para ele existir, sua filosofia e seus conceitos de negócio. No cenário de projetos, existe uma característica que os difere de produtos: projetos tem início, meio e fim. Já para produtos, que é o nosso caso, o P.O. deve não apenas criar uma visão, como também uma expectativa a longo prazo para o produto, e definir limites. Até onde é responsabilidade do produto e até onde queremos chegar.

Essa visão deve ser adaptativa, pois o mundo muda muito rápido, e agilidade em mudar de rumo é vantagem competitiva hoje. Nisso, o Scrum ganha de longe de outras metodologias: você tem entregas em sprints curtos e a próxima entrega ainda será definida, o que dá muita margem para mudanças.

E como fazer quando você quer migrar pro Scrum e você não tinha apenas um stakeholder, de um produto que já existe há pelo menos cinco anos, mas sim vários ?

A primeira coisa a se fazer, acredito, seria pegar todos os requisitos pendentes, ou seja, os já existentes do sistema e organizá-los em histórias, do tipo: “Eu como usuário gostaria de assistir vídeos no linux (em flash)”, ou “Eu como Product Owner gostaria de disponibilizar o player para que outros sites possam incluí-lo (embedded)”. Com todas essas histórias que o produto tinha pela frente postas no papel você consegue ter uma visão geral da direção que o produto estava seguindo.

Descobrindo essa direção você pode: ou se ater à direção atual ou definir uma nova e criar novas histórias para que o produto começe a mudar de direção. O importante é ter essa direção, que não é fácil, diga-se de passagem. Com a direção definida você provavelmente terá agora mais facilidade em estimar o valor de negócio de cada história (valor esse de 0 a 100). O valor de negócio é uma métrica de quanto uma história traria de valor para a empresa em comparação com outra.

Para iniciar essa definição, pegue a história que tenha o menor valor de negócio e estime um número baixo para usar de referência, como 2 por exemplo. Daí, vá pegando as outras histórias e comparativamente dando seus valores de negócio. Rapidamente você terá um quadro bem definido com quais histórias provavelmente você irá atacar nos próximos sprints e conseguirá antever pelo menos 2 ou 3 entregas.

Nisso, é hora de comunicar ao time a estratégia do produto e as histórias que você pretende atacar no futuro próximo. No Sprint Planning 1, que é a primeira de duas reuniões que definem um sprint, o time irá estimar a complexidade que cada história tem e encaixar no Sprint (que no nosso caso leva 2 semanas) aquilo que o time consegue se comprometer em entregar. São também definidos nessa reunião, pelo P.O., o DoD (Definition of Done, ou em português: Definição de Terminado) e os critérios de aceitação.

Com isso tudo feito, é só correr para o abraço. Com o time a par da visão e o sprint definido e bem detalhado, o P.O. poderá ter a certeza que caso ele precise mudar de estratégia, será tão simples como colocar mais itens no backlog do produto, estimar o valor de negócio, re-estimar ou mesmo remover histórias do backlog (não os do sprint atual, claro).

Uma experiência legal que tivemos aqui foi que a nossa P.O. marcou uma reunião para nos passar a visão do projeto, ouvir idéias e ter um feedback do que o time gostaria de sugerir para a plataforma que trabalhamos. O formato da reunião foi o seguinte: Reunimos os dois times que participam do projeto dessa plataforma e de outra plataforma relacionada, misturamos todos e dividimos em dois grupos. Cada grupo teve meia hora para fazer um brainstorm de idéias, colocá-las no papel, sem que ninguém pudesse criticar a idéia do outro, apenas contribuir com as suas. Depois disso (por incrível que pareça, eram 4 folhas A4 de idéias para cada grupo), nós deveríamos discutir as idéias por mais meia hora, eliminando as idéias que fossem claramente ruins. Após essa primeira eliminação e discussão, cada grupo teve 10 minutos para escolher as top 10 idéias.

Foi impressionante como as idéias se mesclavam no final. Das duas listas top 10, conseguimos 12 ou 13 idéias muito boas, e as outras 7 que sobraram eram repetidas. O timebox da reunião foi de 2:30 horas. Em 2 horas e meia conseguimos ver qual a visão a médio e longo prazo da plataforma, ter uma noção muito maior do que é a nossa plataforma para a empresa como um todo e sugerir idéias para melhorar, mudar e acrescentar valor ao projeto.

Off-topic: Como as reuniões estão mais produtivas, depois que adotamos o Scrum… mas isso é assunto pra outro post. Voltando ao tópico e para concluir, esse é o maior desafio, na minha opinião, em uma migração para Scrum: Definir a visão dos projetos.

O Daily Meeting é uma reunião do Scrum que ocorre todos os dias e tem as seguintes características:

• Ela deve ocorrer diariamente e sempre no mesmo horário, que pode ser decidido pelo time no Sprint Planning, e preferencialmente ser sempre pela manhã.
• O Time e o Scrum Master devem estar presentes.
• A reunião tem um timebox de 15 minutos e não deve ultrapassar esse tempo.
• Cada participante do time deve responder a tres perguntas: “O que fiz ontem?”, “O que farei hoje?” e “O que está me impedindo?
• Todos devem estar de pé. (Afinal, são só 15 minutos)
• Qualquer um pode assistir a reunião, como chicken* (chicken não pode falar durante a reunião).

Eu faço parte de um time, composto por desenvolvedores, designer e arquiteto da informação. Somos 8 pessoas e o comprometimento e a participação ativa de todos do time é extremamente importante para o sucesso do sprint e consequentemente do projeto como um todo.

O horário oficial de chegada da empresa é as 9:30 da manhã, e nosso time decidiu que o Daily Meeting aconteceria as 10:45. Ainda assim, temos pessoas que chegam atrasado, por motivos diversos. Quando alguém atrasa e não avisa, acontecem diversos efeitos colaterais nocivos ao scrum, como o time não saber se aquela pessoa terminou o trabalho dela, se ela tá tendo problemas ou impedimentos, e o que ela planejava fazer hoje.

Nosso time, em conjunto com o scrum master, começou a elaborar punições. A primeira punição foi que se alguém atrasasse e não tivesse um motivo convincente pra isso (ex. Problemas médicos e tal), o Daily Meeting seria adiantado 15 minutos até o fim do Sprint. Ou seja, alguém atrasou, o Daily Meeting iria pra 10:30, depois 10:15, depois 10:00… até chegar na hora oficial da empresa (9:30).

Essa primeira punição ficou muito rígida, pois não tinha uma contra-moeda pra voltar o tempo e quanto mais cedo o Daily Meeting ficava, mais difícil era de ter todo mundo presente em tempo (trabalhamos num local distante no Rio de Janeiro). Então adaptamos para que se o time ficasse 4 dias sem atrasar, e tivesse alguma penalidade já em prática, essa penalidade seria reduzida em 15 minutos, ou seja, se alguém do time se atrasasse e o daily meeting caísse de 10:45 para 10:30, bastava o time conversar com o cara e o time todo vir 4 dias sem atraso algum para voltar pra 10:45.

Inacreditavelmente isso ainda não funcionou. Ainda assim continuávamos tendo problemas de atraso. Todos sempre esporádicos, mais ainda assim acontecia (no final do Sprint de 10 dias, o daily meeting já estava em 10:15). Todos sentamos pra conversar e ver se não havia ninguém desestimulado, ou com vontade de trocar de time, ou insatisfeito em geral com qualquer coisa, mesmo que pessoal. Após uma longa conversa chegamos a um novo e mais flexível sistema de punição: Se qualquer pessoa for se atrasar por qualquer motivo, deve ligar com pelo menos ~20 minutos de antecedência do daily meeting para o Scrum Master e avisar que vai se atrasar, e contar o que fez e o que está impedindo.

Se isso fosse respeitado, o daily meeting continuaria no mesmo horário e demonstraria que a pessoa estava comprometida em não prejudicar o time todo, mesmo que tivesse um problema qualquer (trânsito, despertador que não toca, sono profundo, etc). E ficaria a cargo do Scrum Master e da gerência controlar quem abusa e quem não abusa de chegar atrasado, ou seja, separar os casos esporádicos dos crônicos e resolver como a empresa achar correto.

Ficamos de usar esse processo flexível nesse sprint para ver como vamos nos sair. Queria saber como você, que também tem esse problema, o enfrenta (E quem não tem, qual a fórmula mágica :P) ? Comente !

UPDATE: (Acertos para refletir o que espero do post)

Particularmente ainda não vejo necessidade de usar UML em Cores. Num mundo cada vez mais ágil, quanto mais detalhes e regras pra uma documentação que deve ser simples e objetiva, menos isso será usado. Em contrapartida, eles apresentaram também a nova buzzword do mercado: Agile Draw, que nada mais é que nossos rascunhos, usando um subset da UML, num whiteboard. Nisso eu acredito

O segundo dia foi bem interessante. DDD é um assunto que eu gosto muito, até já li duas vezes o Domain Driven Design do Eric Evans. O palestrante do dia foi Felipe Rodrigues, que também palestrou na QCon 2008 sobre o mesmo assunto. A palestra dele foi muito boa, exemplificando e tentando trazer de maneira mais simples os conceitos não-tão-simples do Domain Driven Design. Tivemos também atividades práticas pra exemplificar o que foi dito.

No mais, o evento foi muito bom. Tive a oportunidade de ver amigos de outros eventos, e trocar experiencias do dia a dia com eles. Amanhã estarei no Falando em Java, que promete.

Adotar uma maneira diferente de renderizar conteúdo no IE8 pode causar o mesmo problema de quando lançaram o IE7. Mas para contornar isso, eles criaram um mecanismo para informar o browser IE8 a renderizar no formato IE7 via meta-tags no header. Exemplo:

Ou seja, vão mesmo mudar a forma de renderizar para uma forma mais padrão e deixar a compatibilidade com as versões anteriores pra ser especificada programaticamente. Isso nos afeta muito aqui na globo.com visto que nossos sites tem como premissa funcionar em todos os browsers, provavelmente teremos um bom trabalho de adaptação, mas essa notícia me deixa esperançoso.

Eles inclusive consultaram experts como A List Apart e o Webstandars.org! Impressionante, não ?

Estou ansioso pra ver esse IE8.

Aos que sentiram falta da funcionalidade, ela já está no ar. Aproveitem.

Mais uma vez nossa equipe ninja conseguiu entregar tudo com qualidade e dentro do prazo ! Viva o Scrum !