Novo release do Globo Vídeos no ar

Hoje de manhã subimos uma nova versão do GloboVídeos, este é o quarto release seguido onde conseguimos entregar o que planejamos na data acordada com nossos clientes internos, mas neste post não vou falar sobre como o SCRUM tem nos ajudado a criar um super ambiente de trabalho eficiente e cada vez mais produtivo, gostaria de falar um pouco do nosso principal produto para o consumidor, o GloboVídeos.

É muito legal o fato de que estamos introduzindo novas features no produto num ritmo bem razoável, pelo menos um release por mês,  sem degradar a qualidade do software que estamos entregando e servindo cada vez mais vídeos para cada vez mais usuários.

Apenas relembrando um pouco do release plan do produto:

Outubro de 2007 lançamos o GloboVideos 4.2, nele foi introduzido um novo visual com mais cara de Web 2.0 e principalmente lançamos as fundações para os frutos que estamos colhendo agora,  mérito de toda a equipe mas principalmente da liderança do Phillip Calçado que nos ajudou a criar a nova arquitetura do engine de Widgets e a WebMedia API em conjunto com o Guilherme Chapiewski.

Em Dezembro de 2007  migramos nossa plataforma de vídeos on demand de Windows Media para a tecnologia Flash Vídeo.

Em Janeiro deste ano, batemos todos os recordes de audiência com o BBB8, inserimos de volta o botão de full screen e um novo sistema de propaganda em vídeo (veja um exemplo aqui) juntamente com outros ajustes internos.

Hoje entregamos duas novas funcionalidades que os usuários podem perceber mais claramente e era um dos nossos grandes débitos neste mundo de aplicaçoes Web 2.0 e syndication por todos os lados:

• A primeira é a possibilidade de colocar o player de vídeo da Globo.com em qq lugar, quero dizer, agora é possível colocar qq vídeo que esteja na Globo.com em seu blog ou site exatamente como se faz com vídeos do YouTube e outros sites de vídeos do usuário.
• A segunda funcionalidade é uma nova tela de fim de vídeo, ou seja, quando um vídeo chega ao fim é apresentada uma tela com vídeos relacionados e com link para a página e copiar o código embedded do Player.

Agora é continuar trabalhando em cima do próximo release que já esta planejado na parede e com seus devidos post-its colados.

Garantindo datas de entrega em projetos SCRUM

Uma situação muito comum no dia a dia de diversas equipes de desenvolvimento de software e como não deveria deixar de ser também acontece aqui na Globo.com, é quando as equipes de marketing ou produto precisam de uma data garantida para o lançamento de um certo projeto, no entanto, estas mesmas equipes se sentem inseguras quando o ScrumMaster esclarece que o time é que vai estimar o que cabe em cada Sprint  e que cada time possui uma velocidade relativa contada em pontos de complexidade. Nessa hora elas entram em um estado de transe e voltam a pedir o que sempre pediram e a trabalhar da maneira como sempre trabalharam, Ken Schwaber chama este reflexo de “Muscle Memory.

Explicando melhor, quando as pessoas estão sobre pressão em um momento em que estão tentando alguma coisa nova (como por exemplo tocar um projeto usando SCRUM), na primeira dúvida que surge elas tendem a querer voltar a fazer as coisas como sempre fizeram, para muitas pessoas é realmente difícil aceitar que o Time é que define a velocidade de entregas, e neste momento elas requisitam alguma coisa que lhes dê uma segurança de que aquele software será entregue com certeza na data definida, é nessas horas que ouvimos o famigerado pedido “Poxa, não dá pra vcs fazerem um Project bonitinho com as datas e tal”, como se um project fosse o certificado de garantia de que o Time vai entregar alguma coisa em alguma data. Eu cada vez mais acredito que cronogramas não funcionam e não tem como garantir nada.

Em uma situação dessas, em que um produto precisa de um determinado set de funcionalidades e onde está se pedindo uma data formal de entrega, uma solução possível seria adicionar uma margem de segurança (ou buffer) nas estimativas para garantir que as estórias do projeto estarão prontas com certeza e, em seguida, verificar quantos Sprints são necessários para realizar esta entrega.

Este buffer é feito usando as estórias e suas estimativas de complexidade, durante o planejamento de um Sprint o Time evolui sua avaliação a respeito da complexidade de implementação das estórias com base no maior esclarecimento que vai acontecendo nas reuniões do Sprint.

Sendo assim podemos presumir que em um primeiro momento, quanto estamos lendo uma estória pela primeira vez, teremos um grau de precisão na avaliação da complexidade relativamente baixo, por exemplo 50%. Conforme as dúvidas e a arquitetura do sistema a ser utilizada são esclarecidos esta precisão aumenta até que no Sprint Planning 1  deve-se ter, idealmente, uma precisão sobre a estimativa de complexidade em torno de 90%. São estes dois dados que vamos utilizar a estimativa com precisão 50% e a estimativa com precisão 90% para calcular o buffer.

Vamos imaginar o seguinte Sprint Backlog com 4 estórias, e que estas foram estimadas pelo time nas reuniões de levantamento de estimativas(50% de precisão) e posteriormente no Sprint Planning 1(90% de precisão).

Com estes dados em mãos agora podemos calcular o tamanho do projeto adicionando o buffer:

 Complexidade do Projeto = Est. 50% + [(Delta)/2]

onde Delta/2 é o buffer.

Usando os números da tabela acima temos que a complexidade do projeto = 28 +(40/2) = 48 e o tamanho do buffer é de 20 pontos de complexidade, ou seja, quanto maior é a diferença entre a primeira estimativa e a estimativa mais precisa (90%), maior será o buffer.

OK, agora que calculamos o buffer podemos calcular quantos Sprints serão necessários para termos certeza de que o produto será entregue contendo estas 4 estórias. Supondo que a velocidade do time seja de 10 pontos de complexidade por Sprint, então vamos precisar de pelo menos 5 Sprints (48/10) para entregar estas 4 estórias com uma boa margem de segurança.

Como os Sprints possuem duração fixa, na Globo.com por exemplo giram em torno de 15 dias, então podemos garantir que em pelo menos 75 dias (15 dias x 5 Sprints) o produto estará entregue com todas as funcionalidades.

O papel do Product Owner e priorização do Product Backlog

Na semana passada tivemos alguns treinamentos muito legais na Globo.com, foram três dias de curso com o Boris Gloger da Sprint-it, empresa que esta nos ajudando na adoção do SCRUM. Em dezembro passado tivemos uma série de treinamentos com o intuito de apresentar o SCRUM para as diversas áreas da empresa.

Neste ano continuamos este trabalho de formação dos profissionais da Globo.com, porém este novo round de treinamentos foi focado em um dos principais papéis dentro do SCRUM, o Product Owner (PO) e também na formação de Trainers, que realizarão os treinamentos internos para as equipes que passarão a usar SCRUM este ano.

The Scrum roles
© Copyright Conchango 2006

Apenas relembrando o papel do PO, ele é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a ele priorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível, entre as suas responsabilidades estão:

• Criar a visão
• Manter o PB estimado e priorizado
• Priorização do PB, com pelo menos 3 Sprints
• Criar as fronteiras (boundaries) que protegem o Time (Tempo, Orçamento, Visão, Padrões, etc)
• Criar um Release Plan do Produto
• Ser a interface de comunicação com os stakeholders, e outros clientes internos e externos
• Ajudar o ScrumMaster a proteger o Time
• Aceitar ou rejeitar uma funcionalidade no Sprint Review

O PO é quem deve criar a visão, mas esta deve ser compartilhada e refinada com o Time, pois é o time que deve se sentir motivado e desafiado por aquela visão. A visão deve ter algumas características básicas como: ser emocional (criar desejo), deve ser clara e concreta e deve ser difícil de alcançar.

O Product Backlog (PB) é responsabilidade do PO, mas quem deve escrever as user stories é o Time, pois este é que vai executar o Sprint Backlog e se comprometerá em entregar estas user stories, claro que o PO pode ajudar a escrevê-las, mas apenas se o time deixar. Antes deste treinamento eu achava que o PO é quem deveria escrever as user stories. É importante lembrar que o PB é formado por um misto de user stories detalhadas e estimadas e um conjunto de idéias mais amplas e sem muitos detalhes, que serão refinadas e devidamente transformadas em user stories no decorrer do processo. O Time é o responsável por estimar a complexidade das user stories, atribuindo pontos de dificuldade para cada uma delas, que chamamos de Story Points.

É importante ter pelo menos 3 Sprints priorizados e estimados, para que o time não fique “idle” na transição entre um Sprint e outro, recentemente passamos por uma situação assim na entrega de um dos releases do Globo Vídeos, por não ter um PB detalhado e priorizado o time teve de esperar alguns dias para iniciar o Sprint seguinte.

The ScrumFlow

No decorrer de cada Sprint é preciso iniciar os trabalhos de estimativa e planejamento do próximo Sprint, é uma boa prática alocar de 10% a 15% do tempo do Sprint corrente para planejar e detalhar o próximo Sprint. É responsabilidade do PO chamar as reuniões de planejamento e detalhamento dos Sprints (não confunda estas reuniões com o Sprint Planning 1 e 2) e de manter pelo menos 3 Sprints planejados e priorizados, se o PO não realizar estas reuniões o ScrumMaster deve chamar a atenção do PO e em casos extremos assumir esta responsabilidade temporariamente. Cada reunião de planejamento não deve durar mais do que 60 minutos (Timebox) e tem como objetivo manter todos no Time informados sobre possíveis mudanças nas user stories e ajustes de prioridades, além de aumentar a precisão das estimativas feitas anteriormente.

Abaixo segue uma proposta de planejamento para um backlog hipotético que entrega um release a cada 10 dias úteis, aqui vai uma dica do Boris, nunca fazer o Sprint Planning 1 e 2 em uma Segunda-Feira ou depois de um feriado, porque é preciso que todas as partes envolvidas estudem o backlog e se preparem com antecedência para estas reuniões e todos nós sabemos que é muito difícil alguém se planejar durante um final de semana ou feriado. Sendo assim a agenda ficaria assim:

• Segunda-Feira (tarde): Sprint Review e Sprint Retrospective
• Terça-Feira (manhã): Entrega do Release
• Terça-Feira (tarde): Sprint Planning 1 e Sprint Planning 2
• Quarta-Feira: Inicio do Próximo Sprint
• Mais ou menos dois dias depois do inicio do Sprint deve-se marcar uma reunião de planejamento e estimativa do próximo Sprint.
• Mais ou menos dois dias antes do final do Sprint deve-se marcar outra reunião de estimativa do próximo Sprint.

Uma vez escritas e estimadas as user stories o PO deve priorizar o PB, no treinamento aprendemos uma técnica interessante chamada de Relative Benefit. Ela funciona assim: para cada item do Backlog atribui-se um valor para o Beneficio de se ter aquela funcionalidade (variando de 0 a 10) e um valor para Penalidade de não se ter aquela funcionalidade entregue, depois somam-se estes valores e o resultado chamamos de Business Value (BV). Agora dividimos o BV pela Estimativa, que reflete a dificuldade/complexidade para se entregar aquela determinada funcionalidade, por fim o PO reordena o Backlog com base neste resultado, do maior para o menor valor.

Por exemplo, no Backlog acima temos a feature 1 que possui um beneficio baixo (1) , uma penalidade alta(9) e uma complexidade baixa(2), sendo assim o beneficio relativo desta funcionalidade é alto (5) quando comparado relativamente com os outros itens do Backlog. Esta técnica também ajuda a priorizar itens com o mesmo BV, como é o caso da feature 1 e 5, neste caso vemos que a feature 5 possui um Beneficio igual a 5, maior que o beneficio da feature 1. Seguindo este método PB acima ficaria priorizado da seguinte forma:

1. Feature 5
2. Feature 1
3. Feature 3
4. Feature 4
5. Feature 2

Esta é uma técnica muito simples que ajuda a dar uma base concreta para comparação entre as funcionalidades e assim, priorizar corretamente o PB, claro que cada caso é um caso e vão acontecer situações onde um diretor vai pedri prioridade de uma determinada funcionalidade, mas esperamos que esta seja uma exceção e não a regra.

Mas uma das mensagens mais importantes do treinamento foi com relação ao papel do PO de proteger e respeitar o Time, este é uma papel que geralmente o PO não assume e pior, como os PO’s geralmente tiveram uma experiência passada em áreas de marketing ou gerência de produtos , eles tendem a achar que a equipe de tecnologia é devagar e não tem compromisso com o produto e sempre tentam empurrar mais e mais funcionalidades pra cima do time. Isso é natural principalmente nos processos waterfall, mas em um ambiente de utiliza Scrum, esta postura do PO não pode ser aceita. Ele não deve pressionar o time para inserir mais coisas no sprint, o time é que escolhe do PB priorizado o que se compromete a entregar com qualidade até o fim do Sprint. Caso o PO entenda que o time pode entregar mais do que esta entregando, ele deve conversar com o ScrumMaster, pois a produtividade do time é um problema que o ScrumMaster deve resolver. Ao tentar empurrar mais do que o time pode entregar com qualidade, o PO começa a quebrar sua relação de confiança com o time, e o ScrumMaster deve intervir e lembrar o PO de que ele também deve proteger o time.

Globo.com entre os 13 sites indispensáveis no Brasil

Ontem saiu um artigo no IDGNow falando sobre os 13 sites indispensáveis da Internet Brasileira, entre eles estão nomes óbvios como Google, UOL, Flickr (talvez não tão óbvio para os brasileiros), Orkut entre outros, mas fiquei feliz de ver que a Globo.com estava nesta lista.

Veja o artigo aqui: Os 13 sites indispensáveis da Internet Brasileira

O mais interessante é a importância que o artigo dá para os vídeos, que é justamente o que minha equipe é responsável, fiquei muito feliz de ver nosso nome e os elogios para os ajustes de usabilidade e design que a Globo.com esta fazendo, segue um trecho do artigo.

…Mais que isto: além do fator usabilidade dar um banho nos rivais diretos da web brasileira, a Globo.com conta com o evidente apelo da sua gigantesca base de vídeos, sejam eles o capítulo da novela de ontem ou a final do futebol na década de 80…

Estamos fazendo muitas mudanças na empresa para sermos mais ágeis e conseguirmos inovar mais e entregar mais funcionalidades para nossos usuários, uma das maiores mudanças que fizemos recentemente foi a migração da tecnologia de vídeo para o Flash Video e espero poder ter mais e mais coisas para mostrar aos usuários nos próximos meses.

Firefox continua crescendo no Brasil

OK, acho que todos já devem saber que o Firefox continua crescendo e tirando fatia de mercado do IE de forma lenta mas consistente. Para nós que temos blogs ligados a tecnologia é normal verificar que a grande maioria da nossa audiência é composta por usuários do browser da Mozilla, no meu caso aproximadamente 50% dos visitantes são usuários do Firefox e 7% usuários de Safari, o restante fica com o IE.

De qq forma em sites não técnicos e focados na grande “massa” esta não é a realidade, mas no caso do Globo Vídeos venho observado um avanço razoável do Firefox sobre o IE, principalmente nos últimos seis meses. Atualmente estamos com a seguinte distribuição:

• 90.10% de usuários de IE
• 9.3% de Firefox
• Safari e Opera totalizam por volta de 0.5%

Isso não parece ser grande coisa, mas se olharmos o retrato da audiência em Agosto de 2007, tinhamos o Firefox com pouco mais de 5% e o IE com aprox. 94%, ou seja, o IE caiu 4 pontos percentuais e o Firefox cresceu exatos 4 pontos, mostrando nitidamente que houve uma migração dos usuários de um browser para o outro. E ainda não esta refletindo a nossa migração da plataforma de vídeo para Flash, que realizados em meados de dezembro de 2007, o que facilitou bastante a vida de quem utiliza outros browsers que não o IE.

Muito legal saber que mais e mais gente esta usando o browser da Mozilla, neste momento estou testando o beta 2 do Firefox 3, e ele promete ser ainda melhor que a versao 2.0, o novo formato de bookmarks (será chamado de Places e terá uma dinâmica bem diferente), a integração com o Mozilla Weave e o uso da nova versão do Gecko vão tornar o browser ainda mais fácil de usar e rápido na renderização de páginas, estou muito satisfeito com o beta 2, o único ponto negativo até agora é que todos os Extensions do Firefox 2.0 deixaram de ser compatíveis com o FF 3.0, é um saco ter de instalar tudo de novo. De qq forma os desenvolvedores de extensions geralmente se adaptam rapidamente as novas versões e em breve teremos as melhores extensions portadas.

Update 25/01/2008: Em pouco mais de 10 dias após este post, o Firefox mostrou mais uma vez estar forte no crescimento acrescentando mais de 1% de share, seguem novos números de acessos ao Globo Vídeos.

• 89.48% de usuários de IE
• 9.98% de Firefox
• Safari e Opera continuam por volta de 0.5%