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.

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:

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.

Qual o tamanho do cache do browser do iPhone?

Esta semana o Yahoo publicou o resultado de alguns testes bem interessantes sobre como o Mobile Safari ( iPhone e iPod Touch) lida com relação ao cacheamento de páginas.

iPhone Cacheability – Making it Stick

Este estudo é bem útil principalmente, se você esta planejando fazer um site com versão mobile que seja compatível com o iPhone, claro que isso não deve ser muita prioridade para a maioria dos desenvolvedores web principalmente no Brasil, já que o número de aparelhos da Apple aqui esta longe de ser representativo.

Segue alguns dados do estudo:

• O Mobile Safari só cacheia componentes de no máximo 25KB
• Componentes já cacheados são renovados usando o algoritmo LRU (least recently used)
• O cache do Mobile Safari conseguiu armazenar no máximo 19 componentes de 25KB, então o tamanho do cache do iPhone gira em torno de 500KB
• O Mobile Safari funciona perfeitamente com componentes “Gzipados”

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.