Posts Tagged ‘Globo Vídeos’

Como lidar com defeitos/bugs

Tuesday, December 16th, 2008

Há alguns dias recebi um e-mail com a seguinte dúvida:

Se fosse possível eu gostaria que você falasse um pouco de como funciona para vocês o tratamendo de incidentes em produção e defeitos. Como num ambiente ágil isso é tratado? Eles entram no backlog independente do projeto ou existe um tratamendo especial para fix/test/deploy? Alguma equipe específica faz o fix e corrige os testes unitários se for o caso?

Seria legal ter uma luz a respeito disso.

Como esse era um assunto que eu já estava para falar mesmo, aproveitei o gancho para fazer esse post.

Depois de conversar com muitas pessoas ao longo do tempo, o que eu percebí é que cada um trabalha de um jeito. Eu não acredito que exista uma forma certa ou errada de trabalhar, o que existem são formas diferentes que funcionam melhor ou pior em determinado lugar ou outro. Apesar disso, deve-se tomar cuidado para não criar alguma forma de trabalhar que viole os princípios básicos da metodologia/framework (Scrum no nosso caso). E por último, nem sempre conseguimos fazer dessa forma que vou falar, mas no geral é o que tentamos fazer.

Antes de tudo nós tentamos tratar cada tipo de defeito de acordo com sua gravidade. Para auxiliar, assim que um defeito chega para a equipe nós tentamos enquadrá-lo em uma das 3 categorias de defeitos, que para facilitar a explicação acabei de batizar de defeitos simples, importantes e gravíssimos.

Defeitos simples

São defeitos que têm pouco ou nenhum impacto para o usuário. Para citar um exemplo, nós tivemos recentemente um minúsculo defeito de alinhamento em um dos elementos da página do player do Globo Vídeos. Esse defeito não precisou ser visto imediatamente porque ele não impacta o uso do site e também quase não impacta visualmente, visto que o usuário está prestando muito mais atenção ao vídeo do que no resto.

Neste caso o Product Owner é notificado e a regra de priorização normalmente é “quanto antes corrigirmos isso, melhor”.

Defeitos importantes

São defeitos que não são tão simples como meros detalhes visuais mas que não impedem o produto de funcionar. Por exemplo, tivemos um caso que a Macromedia lançou uma nova major version de plugin do Flash e com isso descobrimos que a nossa verificação de versões tinha um problema. O resultado é que a exibição em tela cheia não funcionava corretamente em alguns casos, mas ainda assim o usuário conseguia ver o vídeo numa pop-up que simulava a tela cheia.

Neste caso temos duas opções. A primeira opção é colocar o defeito no backlog para que ele seja a primeira história a ser trabalhada no próximo Sprint. A segunda opção é como normalmente fazemos hoje em dia: o time sempre trabalha a 80~90% da sua capacidade para que quando esses incidentes aconteçam ele possa “puxar” ou assumir mais histórias – desde que todos se sintam confortáveis para isso. Caso não ocorra nenhum incidente durante o Sprint e sobre algum tempo no final, o time pega outra história qualquer que caiba no tempo que sobrou.

Defeitos gravíssimos

São defeitos que impedem o produto de funcionar. Usando mais uma vez o caso do Globo Vídeos, um defeito gravíssimo poderia ser algo que fizesse com que os vídeos parassem de ser exibidos, ou que alguma página estivesse indisponível, ou qualquer outra coisa que impeça os usuários de usarem o produto. Quando os defeitos desse tipo chegam para nós eles já passaram em 2 ou 3 níveis de suporte, então provavelmente trata-se de algum problema do software mesmo (e não de ambiente, de configuração do usuário, etc.) e precisa ser visto com a maior urgência possível.

Neste caso, o mais apropriado seria cancelar o Sprint imediatamente, planejar rapidamente, iniciar um novo Sprint com este item como o primeiro item a ser resolvido e fazer um release o mais rápido possível para corrigir o problema.

Para falar a verdade nunca tivemos esse terceiro caso depois que começamos a trabalhar de uma forma mais organizada com Scrum e cuidando cada vez mais da qualidade do que é entregue. Sendo bem realista, como trata-se de um defeito que coloca em risco a imagem/credibilidade/audiência/dinheiro da empresa, pode ser que seja mais apropriado parar tudo e dar atenção máxima ao problema sem seguir um script específico, afinal de contas o bom funcionamento da empresa deve estar sempre à frente de qualquer coisa. Se isso acontecesse, acho que eu daria o Sprint como cancelado, re-planejaria e começaria um novo Sprint.

Concluindo

Apesar de tudo isso eu pessoalmente sou favorável a corrigir todo e qualquer bug o mais rápido possível, independente de sua gravidade. Eu sou totalmente contra acumular débito técnico porque já sabemos como isso pode afetar a produtividade e velocidade do time a médio/longo prazo. Porém, como já havia dito, dadas as nossas condições e restrições essa foi a forma que melhor funcionou para a nossa realidade – e para ser franco acho que tem funcionado bem.

Globo Vídeos Mobile

Thursday, September 25th, 2008

Continuando com as novidades para dispositivos móveis, além dos vídeos para iPhone em todo o portal Globo.com agora também temos uma versão do Globo Vídeos otimizada para iPhone! No endereço http://m.video.globo.com os usuários poderão assistir vídeos H.264 numa qualidade excelente!

Nesse site trabalhamos em efeitos de transição que lembram os aplicativos nativos do iPhone, abusamos de Javascript e implementamos algumas funcionalidades específicas dessa versão de Safari, como o efeito de girar o aparelho, por exemplo.

O mais legal disso tudo é que o produto foi quase todo feito do zero em aproximadamente um mês. E quando eu falo que tudo foi feito estou falando desde o desenho do site, da criação de ambientes, instalação de software em servidores, definição de profiles de vídeo e início da produção de conteúdo até o site propriamente dito, que tem uma quantidade respeitável de efeitos visuais e 100% de cobertura de testes automáticos rodando no CruiseControl!

Outro detalhe legal do projeto é que dessa vez decidimos fazer tudo em PHP dada a simplicidade do site e que precisávamos agir muito rápido para entregar alguma coisa em 2 Sprints. Por isso que eu digo que aqui nós somos “agnósticos” de tecnologia – usamos a melhor ferramenta para resolver cada problema. No fim das contas foi uma experiência legal e em termos de arquitetura da aplicação e código acho que foi um dos melhores projetos que já fizemos.

Vídeos para iPhone na Globo.com

Thursday, September 25th, 2008

Se você tem um iPhone e acessou hoje algum site da Globo.com que tem vídeos já deve ter percebido a novidade.

Hoje de madrugada atualizamos a infraestrutura do nosso player de vídeos para oferecer conteúdo em vídeo otimizado para iPhones e iPods Touch! Agora quem navega nesses dispositivos vai ter uma experiência muito mais rica e acesso a muito mais conteúdo em todos os sites da Globo.com, especialmente no Globo Vídeos (o acervo de vídeos disponíveis ainda não é muito grande, mas já estamos trabalhando nisso).

Eu sou suspeito para falar, mas a qualidade dos vídeos ficou excepcional e experiência de uso ficou muito boa!

E aí você pode pensar: com tantas coisas para se fazer, trabalhar em distribuição de vídeos para iPhone não é meio irrelevante? Ahm… não. Mesmo sem ter sido lançado oficialmente no Brasil o Safari do iPhone já está entre os top 10 navegadores/sistemas operacionais que mais acessam alguns dos nossos sites! Aproveitando ainda que o lançamento oficial da Claro e Vivo está marcado para essa próxima sexta-feira (26 de setembro de 2008), já estamos nos preparando.

Em breve teremos ainda mais algumas novidades…

Como estamos indo com a adoção de Scrum na Globo.com

Tuesday, May 27th, 2008

Muita gente têm me perguntado como estamos indo atualmente com a adoção do Scrum na Globo.com. Acho que já é hora de falar alguma coisa sobre isso. Esse não é um case oficial assinado pela Globo.com, são apenas alguns relatos do meu ponto de vista sobre o assunto.

Nossa história no início foi bem parecida com as histórias tradicionais. Sabe aquelas empresas que gastam uma semi-fortuna com uma consultoria para desenhar um processo de desenvolvimento de software? Assim estávamos nós no início de 2007. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido á risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

Resumindo a história, isso não funcionou na Globo.com e acho que existem poucas chances de algo tão complexo assim funcionar em algum lugar. E por incrível que pareça, no fim das contas ninguém havia pensado em nada para resolver o problema principal: como entregar o software que nossos clientes querem no menor tempo e com a maior qualidade possível?

Um pouco de história

Ao contrário do que acontece em muitas empresas, as metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (Extreme Programming) nos projetos. A porta de entrada foi a oportunidade de melhorar a qualidade dos nossos sistemas, pois tinhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Alguns desenvolvedores mais experientes começaram a desenvolver usando desenvolvimento guiado por testes (TDD), e com isso houve uma melhora nítida na qualidade do que era entregue. Aos poucos, enquanto isso acontecia, algumas seções de programação em par aconteciam de vez em quando para difundir o conhecimento e ensinar a técnica a outros programadores, mas ainda de forma muito tímida e sutil (afinal às vezes é difícil convencer que dois programadores fazendo apenas um código é uma coisa boa).

Em seguida foi a vez de organizar as demandas de clientes e os ciclos de desenvolvimento. Lembro-me de ter colocado nessa época o mesmo software em produção quatro vezes em duas semanas, e depois disso o mesmo software foi trabalhado durante dois meses para só depois poder ir novamente para produção. Para piorar, nossos clientes nos traziam todo tipo de demanda que se pode imaginar, sempre em lotes e com prioridade máxima. Por exemplo, acontecia frequentemente do mesmo cliente demandar cinco coisas e todas elas com máxima urgência. Resumindo, os ciclos de planejamento, desenvolvimento e entrega eram totalmente irregulares e afetavam o desempenho de toda a equipe. Explicando todas as dificuldades que tinhamos para nos organizar nesse caos, conseguimos acordar que fariamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teriamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de Scrum com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Me lembro de nessa época alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar Scrum no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabiamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do Scrum.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de Scrum, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões. O Phillip falou bastante sobre essa fase introdutória no seu blog no ano passado.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi colocada em produção em pouco mais de uma hora e na primeira semana nem ouviamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo que acontecia o Globo Vìdeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando Scrum, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos – mais uma prova viva de que o Scrum era uma possível resposta para os nossos problemas. O Danilo inclusive fez uma apresentação sobre esse projeto na semana passada num evento do C.E.S.A.R. em Recife.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de Scrum em massa na Globo.com.

Como estamos hoje

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando Scrum.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar Scrum da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderiamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vinhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo Scrum, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily Scrum, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estouravamos o tempo da reunião discutindo um monte de coisas que não eram necessárias mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com planning poker também evoluiram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de Scrum Of Scrums, onde todos os Scrum Masters se reunem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem.

Definimos o nosso conceito de “done” (finalizado), que é a parte mais divergente entre as equipes. Na equipe de desenvolvimento de vídeos (minha equipe), uma história ou funcionalidade está pronta quando foi desenvolvida (incluindo testes unitários), integrada à base de código, testada novamente (fazemos testes de aceitação com critérios definidos no Sprint Planning ao criar as histórias) e homologada. Como nosso time tem uma pessoa da área de QA, podemos incluir a homologação da aplicação dentro do Sprint (nem todos os times fazem dessa forma).

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time – ele deu excelentes toques importantissimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

Concluindo…

Não só o Scrum como todos as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais. Por conta disso nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou Scrum Masters no caso do Scrum) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

Vídeos da Globo no seu site

Thursday, February 28th, 2008

Agora os vídeos da TV Globo podem estar em todos os lugares! Acabamos de lançar uma nova versão do player do Globo Vídeos, e a partir de hoje os usuários podem embeddar vídeos em seus sites. Além disso, agora temos uma tela no fim dos vídeos onde são sugeridos vídeos relacionados e disponibilizadas algumas opções para compartilhamento, como o código para colocar o player em um site e o link para o vídeo no Globo Vídeos.

O player embedded já existe internamente na Globo.com há algum tempo e muito sites já o usam, como o G1 e o GloboEsporte.com, por exemplo. Porém, ele nunca esteve oficialmente disponível para os usuários e essa era uma das features mais requisitadas da nossa fila. Espero que gostem!

[JBoss World 2008] James Ward: Porting from web 1.0 to RIA

Thursday, February 14th, 2008

James Ward, evangelista da Adobe, fez uma apresentação muito legal sobre como criar Rich Internet Applitacions com Flex, usando back-ends robustos em Java com JBoss.

Essa apresentação teve muito a ver com o artigo que ele publicou no InfoQ sobre como portar aplicações HTML tradicionais para Flex, escrito em conjunto com Shashank Tiwari (mais detalhes no blog do James).

No início ele mostrou um demo sensacional de uma aplicação de seguros que eles migraram de “web 1.0″ para Flex. Realmente o poder das interfaces ricas é impressionante. Outro demo interessante foi do eBay Desktop, que tem uma boa combinação de HTML e Flash (usando o Adobe AIR), resultando em uma interface muito bonita e funcional.

Ultimamente na Globo.com temos trabalhado muito com Flash, por causa do player do Globo Vídeos. Antes disso eu nunca tinha trabalhado com Flash e talvez por isso nunca tenha tido a oportunidade de sentir tão de perto seu potencial. Flash/Flex/AS3/AIR/etc abrem um novo mundo de possibilidades, dando o poder de criar interfaces com usabilidade e interatividade excelentes, e ainda com um forte apelo visual.

Ele apresentou o conceito de “SOARIA” (aliás, quando ele falou isso eu comecei a rir sozinho, parecia que ele estava falando “sorria”). O que ele chama de SOARIA significa SOA + RIA, ou seja, aplicações ricas (RIA) que interagem com o back-end através de serviços (SOA). IMHO, acho essa abordagem muito legal, porque evita aquela dependência cíclica que sempre acaba se formando entre o Flash e a aplicação.

No final, vimos um benchmark interessante, comparando vários modelos de carregamento de dados em aplicações RIA usando Flex, Laszlo e Javascript/Ajax, integradas com serviços SOAP, pure-XML, HTML e JSON. O benchmark analisa como cada um desses modelos impacta em performance, consumo de banda e consumo de memória na máquina cliente. Fiquei surpreso com os resultados… Por exemplo, a aplicação mostra que o Dojo tem uma performance surpreendentemente ruim quando comparado a aplicações Flex, que têm uma performance normalmente superior a todas as outras (atenção, se você for rodar os testes não se esqueça de desabilitar o Firebug antes!).

A Adobe realmente acertou com o Action Script 3, Flex, AIR e todos esses novos produtos que têm sido lançados. Tenho que tirar o chapéu.

Sprint Review e Retrospective com Boris Gloger

Friday, February 1st, 2008

Sprint GoalHoje na Globo.com tivemos a ilustre visita do nosso amigo Boris Gloger! O Boris é um dos maiores especialistas do mundo em Scrum e está ajudando a melhorarmos o processo de desenvolvimento de software na Globo.com. Em dezembro do ano passado ele nos deu o treinamento de Scrum Master e agora ele está no Brasil para fazer alguns treinamentos mais especificos, como o de Product Owner (específico para gerentes de produto entenderem seu papel no Scrum) e Trainers Training (para nós Scrum Masters estarmos aptos a treinarmos pessoas e podermos replicar nosso conhecimento).

Aproveitando que o Boris estava aqui pela Barra da Tijuca, o Antonio conseguiu que ele viesse nos visitar aqui na Globo.com!

Equipe do Globo VídeosNa primeira parte da sua visita, o Boris visitou o desenvolvimento das equipes de Portal e Aplicativos, e o Evandro tirou várias fotos e blogou tudo. Como a segunda foto denuncia, acompanhei tudo de perto! Ouvimos várias dicas e sugestões interessantes para melhorarmos nosso processo, além de termos feito vários bate-papos com alguns times. Fiquei sempre por perto para aproveitar o máximo possível (como chicken, obviamente), porque eu sabia que ele viria com uma dúzia de sacadas expertas e conclusões que são tão óbvias que acabam sendo imperceptíveis. E não deu outra.

Em seguida fomos para a base de WebMedia, onde o Boris acompanhou todo o nosso Sprint Review e Sprint Retrospective. Ele nos acompanhou durante três horas e deu várias dicas de como agir e o que fazer em determinadas situações específicas, além de ter tirado algumas dúvidas que sempre nos perturbam no dia-a-dia.

Boris Gloger e Guilherme ChapiewskiDepois, quando tudo acabou, ele disse que a retrospectiva foi muito boa, e mais uma vez deu várias dicas… A mais importante foi que eu tenho que ser um Scrum Master mais malvado (risada macabra), porque ele me achou bonzinho demais… Por ele o P.O. tinha sido expulso da sala duas vezes, mas eu confesso que ainda não sei fazer isso. Mas fiquei feliz de saber que estamos no caminho certo. Foi uma oportunidade única e inenarrável.

Se alguém quiser ver, tem mais algumas fotos no meu Flickr.

Novo release do Globo Vídeos (agora em tela cheia)

Wednesday, January 30th, 2008

São 05:55 da manhã por aqui e acabamos de subir o primeiro release do Globo Vídeos de 2008. Essa versão é a primeira depois da mudança para Flash vídeo e nós corrigimos diversos detalhes de infraestrutura que ficaram pendentes em 2007. Fizemos bastante coisa, mas não vai dar para ver muita novidade.

Mesmo que esse release tenha sido praticamente só de coisas “internas”, não tivemos como deixar de fora uma das funcionalidades mais requisitadas: os vídeos em tela cheia! Muitos usuários sentiram falta dessa funcionalidade e cheguei até a receber aqui no blog comentários como: “a decisão de tirar a tela cheia merece o prêmio abacaxi da década”.

Acho que isso tudo merece uma explicação.

Tivemos que fazer isso porque estávamos correndo contra o tempo para colocar a infraestrutura de Flash vídeo antes do Big Brother. O BBB é um grande evento para os nossos servidores, eles trabalham um bocado nessa época. O consumo de vídeos aumenta muito e por isso é muito arriscado fazer qualquer mudança grande na infraestrutura neste período, porque se alguma coisa der errado, nossos usuários podem ficar sem ver vídeos (e nós definitivamente não queremos isso).

Como a mudança de Windows Media para Flash envolvia uma quantidade enorme de mudanças, só tínhamos duas opções: ou fazíamos a migração para Flash antes do BBB, ou esperávamos para fazer em abril de 2008, depois que o programa acabasse.

Só o trabalho de infra foi monstruosamente grande… Desde a captura de vídeos com mais qualidade, até a produção em um novo formato (flv) e distribuição dos vídeos usando dezenas servidores totalmente novos com softwares completamente diferentes dos anteriores. Como se isso tudo já não fosse suficiente, precisavamos mudar o player do Globo Vídeos e o player embedded que é usado por inúmeros sites da Globo.com, mantendo compatibilidade com alguns programas que ainda funcionam em Windows Media como os jogos da NBA, por exemplo.

Com tantas coisas pra fazer pela frente, nós tivemos que priorizar a implementação de tudo que era absolutamente necessário para o funcionamento dos novos vídeos em Flash. A tela cheia é uma funcionalidade importante? Sim, ela é muito importante. Só que mais importante que isso é tocar o vídeo. Para viabilizar o projeto, tivemos que tirar absolutamente todas as funcionalidades que não fossem impeditivas para o funcionamento dos novos vídeos. A princípio isso pode parecer ruim, mas nossas práticas com Scrum nos mostraram claramente que essa era a única forma de fazermos o player Flash acontecer.

Posso dizer que essa decisão não foi nem um pouco fácil, porque acabamos tirando uma funcionalidade dos usuários. Mas pode ter certeza que foi uma das coisas que viabilizou a migração dos vídeos para Flash ainda em 2007.

Ficamos sem a tela cheia por pouco mais do que 40 dias. Não foi muito tempo, mas sei que muita gente ficou chateada. Peço desculpas em nome da Globo.com, mas como vocês estão vendo, foi por uma boa causa. :)

Globo Vídeos em Flash!

Wednesday, December 19th, 2007

Globo Vídeos Flash PlayerNem acredito que finalmente o Globo Vídeos mudou para Flash! Desde às 05:53 da manhã de hoje toda a nova infraestrutura de Flash Vídeo da Globo.com está em produção e funcionando muito bem, obrigado. Com isso nós nos igualamos aos maiores players do mercado como YouTube, Yahoo! Video, Metacafe e blip.tv.

Muitas pessoas sempre me perguntavam porque a Globo.com usava Windows Media ao invés de Flash. Não posso entrar nos detalhes dessa decisão mas só para deixar as coisas mais claras, não era uma decisão técnica e sim de negócio. Como usuário do Globo Vídeos eu também sempre estive muito ansioso para que os vídeos fossem em Flash mas infelizmente não era possível. Agora, com todas as arestas aparadas, finalmente estamos disponibilizando vídeos numa tecnologia mais moderna e com muito mais qualidade de imagem do que a versão anterior (e vai melhorar!). Além disso agora passamos a atender também os usuários de Linux e Mac.

O mais legal dessa história toda é que todo o projeto foi implementado em menos de um mês! Esta primeira fase do projeto durou exatamente 4 semanas, desde estudar Flash até a migração de toda a infraestrutura, re-programação do site, produção de vídeos no novo formato, confecção do player e etc. Utilizar um processo de desenvolvimento ágil como Scrum foi essencial para organizar/planejar o trabalho e também possibilitou essa façanha de fazer uma quantidade de trabalho considerável em 4 semanas.

2008 promete. Muitas novidades virão por aí!