Posts Tagged ‘Globo.com’

Agile UX: Como trabalhar com os designers

Friday, December 19th, 2008

Seguindo com a série de posts-resposta, vou aproveitar mais um e-mail que recebi para falar de um assunto que é campeão em dúvidas e discussões: como trabalhar com os designers. A questão é a seguinte:

Gostaria de tirar uma dúvida (ou mesmo sugestão) sobre como vcs estão trabalhando ai na Globo.com com os designers, arquitetos de informação, etc, inseridos nos times ágeis.

A empresa onde trabalho tem um “setor” de criação artística muito forte, alias, excelentes profissionais, e eles trabalham independentes praticamente do desenvolvimento.

Devido a maneira da empresa gerir seus projetos – waterfall – eles fazem toda a parte de criação e entregam um wireframe+layout de telas prontos pras equipes de desenvolvimento, ai é cada um por si.

Como estamos fazendo um processo de migração de waterfall pra desenvolvimento ágil, esse ponto específico do pessoal de criação inseridos nas equipes ágeis ainda deixa muitas dúvidas, na maneira que eles podem fazer parte dos times.

Talvez esse tenha sido um dos maiores problemas que tivemos na adoção de Scrum aqui na Globo.com, ou pelo menos é um dos problemas que têm durado mais tempo. Novamente, não acho que exista uma receita de bolo, cada time ou empresa precisa encontrar a melhor forma de trabalhar. Vou me limitar a dar algumas idéias e falar do que temos tentado fazer aqui para integrar desenvolvimento e design.

Por último, vou falar especificamente de Scrum porque é o que usamos aqui (apesar de usarmos também práticas e conceitos de XP e Lean), mas as mesmas idéias servem para outros processos similares.

O ponto de vista do processo

Do ponto de vista do Scrum, o correto seria desenhar a cada história que fosse feita somente as partes da tela necessárias para a conclusão da história.

Fazer todo o design antes nos mínimos detalhes não é o mais indicado porque para isso é preciso fazer um levantamento de requisitos para entender as necessidades e é exatamente assim que funciona a fase de análise e levantamento de requisitos do waterfall (ou seja, o que não queremos fazer).

Outro problema é que se no início de um projeto você só trabalha telas, o que você irá entregar no fim de um Sprint? Com certeza não será software funcionando e toda aquela história de antecipação do ROI vai por água a baixo.

Por fim, um dos objetivos do desenvolvimento com Scrum é produzir software de maneira iterativa e incremental. A cada Sprint deveria ser entregue uma pequena parte do produto funcionando e quando isso é feito, o Product Owner pode chegar em qualquer ponto do projeto e perceber que o investimento em mais um Sprint já não vale mais a pena como valia no início – porque as histórias que sobraram darão um retorno bem menor do que o valor investido em um Sprint – e ele pode decidir que é necessário encerrar o projeto por razões econômicas óbvias e partir para outro.

O ponto de vista do desenvolvedor

Os princípios de desenvolvimento ágil também não deixam dúvidas. Big Design Up Front (BDUF) é coisa de cascateiro, e as práticas de desenvolvimento como Test-Driven Development (TDD) fomentam justamente o desenvolvimento incremental.

Do ponto de vista do desenvolvedor ágil também é um erro desenvolver todo o design antecipadamente.

O ponto de vista do designer

Só depois de muitas conversas com o Cainã Nunes e o André Braz – dois dos melhores “criativos” que temos aqui na Globo.com – é que eu consegui entender o problema de verdade. Eu não sou nem de perto um especialista no assunto (e nem pretendo ser), mas vou tentar explicar o pouco que eu entendo.

Para entendê-los, precisamos entender a diferença entre “design de interface” e “design de UX”.

Desenhar uma tela qualquer é muito fácil. No início da minha carreira quando eu trabalhava em uma agência de desenvolvimento de sites cansei de mudar e algumas vezes até fazer layouts. Depois que você aprende a usar direitinho o Photoshop e o Fireworks é realmente muito muito muito fácil desenhar uma tela, desenhar objetos diversos e entregar qualquer coisa. Não que todos os designers façam isso, mas que é fácil fazer uma tela qualquer é.

O problema é que aqui na Globo.com nós não queremos fazer somente telas. Além do design e beleza em sí, estamos preocupados com a experiência do usuário (a famosa UX). Ao contrário de desenhar uma simples tela, projetar a UX é muito muito muito difícil. Em UX, não basta ter uma tela, ela precisa ser fácil de usar, os usuários precisam querer usá-la e a experiência de uso tem que ser memorável – porque isso fará com que os usuários queiram voltar. Isso é tão difícil de fazer que muitas vezes falhamos, mas essa é a nossa mentalidade e como queremos desenvolver nossos produtos.

Quando falamos de projetar a UX, vários fatores além do Photoshop ou Fireworks estão envolvidos (veja o experience design manifesto para ter uma idéia). Aspectos como ergonomia, sentimento e psicologia entram em cena. Alguns projetos que fazemos são testados exaustivamente com usuários comuns no laboratório de usabilidade, e mesmo assim continua difícil de alcançar o resultado que queremos.

Pense friamente e veja como todas essas “loucuras” fazem muito sentido. Independente do processo que usamos, não é isso que queremos dar para os nossos usuários nos produtos que desenvolvemos?

O problema

O problema é que para projetar a experiência do usuário, os designers acreditam que é difícil (ou impossível) pensar em pequenas partes do site e que é preciso pensar na experiência como um todo. Isso vai totalmente de encontro com a forma que o processo funciona e que os desenvolvedores trabalham…

Para ser muito sincero, eu não entendia porque eles não gostavam da idéia de ir refatorando o design e ir adaptando conforme as partes fossem sendo desenvolvidas. O que eu sempre entendi é que indivíduos e interações devem estar acima do processo, então ao invés de ficar procurando respostas no processo precisamos confiar nessas pessoas – que são especialistas no que fazem – e junto com elas encontrar uma saída.

Isso não nos exime da responsabilidade de fazê-los entender claramente como funcionam os processos e princípios de desenvolvimento ágil para que eles saibam o impacto das suas decisões e ajudem a encontrar uma forma de trabalhar que seja compatível com essa realidade.

Harmonia entre desenvolvimento e criação

Depois de muitas tentativas e erros, a forma de trabalhar mais próxima do ideal que eu consigo enxergar é uma mistura dessas três visões.

Os projetistas de UX podem e devem sempre pensar na visão do todo mas não necessariamente precisam entrar em todos os detalhes de cada uma das telas. Com a visão inicial do projeto os designers já têm muitas informações que precisam para começar a trabalhar na experiência do usuário e devem desde já pensar no produto como um todo, mas mais uma vez, isso não quer dizer que tudo precisa ser feito e pensado nos mínimos detalhes antes do projeto. Abaixo ao BDUF!

Na nossa equipe os designers têm feito sketches, wireframes e desenhos à mão para discutir funcionalidades e usabilidade. Muitas vezes isso é feito durante as discussões do Sprint planning e re-pensado algumas vezes durante o Sprint. Depois, durante o desenvolvimento, a cada história que vai sendo desenvolvida o time vai implementando junto com os designers, que vão fazendo as pequenas partes necessárias para aquela funcionalidade específica e ao mesmo tempo o design da experiência como um todo é continuamente revisto e refatorado para atender à visão do projeto.

A idéia é mais ou menos como a do cone da incerteza: no início do projeto você têm uma vaga idéia de como será na prática a experiência do usuário, e essa certeza vai continuamente aumentando até que depois de algum tempo (mais próximo do fim) você tem certeza absoluta de como ela será.

Ainda não estamos craques em fazer isso mas promete funcionar bem melhor do que tudo que já tentamos.

Concluindo

Você é realmente ágil quando não existe algum processo burocrático que te impede de fazer alguma coisa com mais eficiência. Criar um processo ou ambiente que impeça as pessoas de trabalhar ao invés de facilitá-las vai totalmente de encontro à agilidade.

Para citar um exemplo, o próprio criador do ScrumJeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como algo que dificulta o trabalho (torna menos ágil), portanto, a usabilidade do software tem que ser perfeita. Sendo o design tão crítico e tão importante para o sucesso do projeto, eles decidiram se organizar para trabalhar com definição de telas e criação de protótipos antes do desenvolvimento. E não adianta achar que todos os projetos devem ser assim; cada caso é um caso!

As pessoas precisam conversar mais e entender as motivações das outras e o que as levam à tomada de decisão. Quando você consegue entender de verdade o lado do outro (dos designers no meu caso) você começa a entender quais são as reais motivações para o que ele está fazendo. O designer no meu time não queria atrapalhar o processo fazendo todas as telas antes, ele simplesmente queria fazer um trabalho espetacular de usabilidade e essa era a melhor forma que ele conhecia. Fazer um trabalho excelente de UX foi exatamente o que o gerente de UX pediu para ele e é essa a direção que a empresa quer seguir. Só depois que eu me dispus a entender como funciona a cabeça dele (e de todos os outros de UX) é que eu estou conseguindo pensar de outra forma. Agora existem muito mais chances que a adaptação que estamos fazendo no processo funcione melhor.

Então, respondendo a pergunta do post: como trabalhar com os designers? Pense fora da caixa! Aqui estão algumas idéias e opiniões, mas que eu aconselho é que cada time experimente e encontre a sua resposta.

Se você ficou decepcionado com a resposta e achava que eu ia te dar uma regra para ser seguida sem precisar pensar, talvez você esteja procurando nas metodologias ágeis a resposta errada e precise de alguma outra coisa que dê isso para você.

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.

Zen of Agile Management Workshop + Falando em Agile 2008, aí vou eu!

Monday, October 20th, 2008

Daqui a pouco estou indo mais uma vez para São Paulo para participar de dois eventos bem legais!

O primeiro deles é o workshop “Zen of Agile Management” que está sendo organizado pelo Adail Retamal da Heptagon e será ministrado pelo David Anderson. O David tem algumas opiniões um pouco controversas sobre integração de Agile com CMMI mas mesmo assim ele é um profissional experiente e com certeza tem muito para acrescentar. Acho que as discussões serão muito interessantes e enriquecedoras.

Falando em Agile 2008O segundo é o “Falando em Agile 2008″, que está sendo organizado pela Caelum e será o primeiro grande evento de metodologias ágeis do Brasil. Neste evento vou fazer uma apresentação entitulada “Liderando equipes ágeis”, que é um apanhado de várias apresentações que assistí, livros que lí e experiências que tive liderando equipes ágeis. Estou bastante ansioso pra falar sobre o assunto… espero que todos gostem! Além disso o Danilo Bardusco vai falar sobre a implantação do Scrum na Globo.com e ainda teremos vários outros palestrantes como o Danilo Sato, Phillip Calçado, Antonio Carlos Silveira, David Anderson (sim, ele estará nos dois eventos), a galera da Caelum e muitos outros!

Essa semana ágil promete! Até lá! :D

Java é ruim?

Sunday, October 19th, 2008

Em tempos de Ruby on Rails parece que está na moda falar mal de Java. Na Rails Summit então meus ouvidos chegaram a doer de tanto ouvir falar que Java é ruim, Java é burocrático, bla bla bla e que Ruby on Rails é fantástico, produtivo e sexy. Calma, essa não é mais uma daquelas comparações ridículas de Java versus Ruby on Rails.

Mas ainda ficou a pergunta que não quer calar: Java é ruim mesmo? A resposta, como sempre, é que depende do caso…

Em um projeto de desenvolvimento de software, mesmo antes de começar o desenvolvimento você já tem algumas restrições para escolher tecnologias. A finalidade do software por si só pode já restrigir muito a tecnologia que terá que ser usada.

Por exemplo, se você estiver fazendo um website, provavelmente você não escapará de fazer uma interface em HTML, Flash ou qualquer outra coisa específica para desenvolver uma camada de apresentação web. Provavelmente você não vai querer usar Assembly para fazer a parte server-side, já que não seria muito produtivo (apesar de não ser impossível). Eventualmente esse site pode ser um portal como a Globo.com que têm milhões de acessos por dia e você terá que escolher uma plataforma/linguagem/arquitetura que priorizem performance e favoreçam escalabilidade. Ou então pode ser um site com pouquíssimos acessos e você nem precisará se preocupar com isso…

Ou então você pode precisar fazer um pequeno script para fazer backup automatizado de um banco de dados MySQL. Seria totalmente incoerente usar Delphi, Fortran ou Piet. Provavelmente você vai querer usar algo como Shell script e resolver o problema em meia dúzia de linhas. Alguns bancos como o SQL Server têm mecanismos de agendamento de backup automático que são super fáceis de configurar e usar, portanto nesse caso usar Shell script seria trabalho desnecessário.

Meu ponto aqui é que não dá para dizer que Java (ou qualquer outra coisa) é ruim por sí só. Java pode ser ruim ou bom dentro de um contexto. Por exemplo, em 2005 eu trabalhei num projeto de Call Center à distância via Internet onde precisei desenvolver um softphone e a melhor opção foi usar Java Applets. Além de existirem bibliotecas Java para trabalhar com IAX (que é um protocolo como o SIP, só que proprietário do Asterisk), o usuário não precisava instalar nenhum programa para falar com o Call Center, bastava acessar o site. Eu odeio Applets com todas as minhas forças, mas foi ótimo para esse projeto (eu diria até que foi relativamente fácil). Seria correto então dizer que Ruby on Rails é ruim só porque seria impossível de fazer esse projeto com tanta facilidade? É óbvio que não!!!

Jamais existirá uma única linguagem ou plataforma para resolver todos os problemas. O desenvolvedor de software precisa conhecer vários tipos de ferramenta e saber escolher a melhor delas para resolver cada problema. Que fique claro que eu não sou defensor de Java, Ruby ou de qualquer outra coisa. O caso é que é incoerente dizer que X ou Y é bom ou ruim por sí só; é preciso analisar as opções dentro de um contexto.

Wanted!

Wednesday, October 15th, 2008

Mais uma vez estamos contratando na Globo.com!

A Globo.com vem se transformando ao longo do último ano. Antes eram apenas duas ou três equipes ágeis mas agora estamos com mais de uma dezena de equipes funcionando a todo vapor, por isso dessa vez estamos com mais sabores de vagas e estamos contratando para várias equipes.

As últimas contratações provaram que não adianta contratar pessoas que sejam apenas “boas”. Precisamos contratar os melhores, não importa onde estejam, porque queremos montar equipes de “rockstars”!

Basicamente temos dois tipos de vagas:

Desenvolvedor Júnior/Pleno/Sênior

Os desenvolvedores de software são responsáveis não só por programar novas funcionalidades mas também por planejar, arquitetar, documentar, testar e trabalhar com novas tecnologias o tempo todo. Aqui não separamos o papel de programador do analista de sistemas ou seja lá o que for. Mais do que nunca não queremos desenvolvedores Java, C ou Brainfuck, queremos desenvolvedores multidisciplinares com experiência em websites e aplicativos web, e isso quer dizer que são desenvolvedores capazes de trabalhar com coisas desde HTML, CSS, Javascript e AJAX até programar backends em Java, Ruby on Rails, PHP, Python com Django, Perl ou o que for mais adequado para resolver cada problema. Algumas vezes já precisamos fazer coisas específicas com linguagens como C, C++ ou Erlang, então desenvolver também em linguagens não-web é um diferencial. Além disso, conhecimentos em arquiteturas de serviços (REST especialmente) e sistemas distribuídos são muito desejáveis.

Nossas equipes trabalham de forma ágil usando Scrum e várias práticas de Extreme Programming, então, desenvolvedores que já tenham trabalhado em times ágeis ou que conheçam práticas ágeis de desenvolvimento são altamente desejados. Além disso é essencial conhecer boas práticas de programação, orientação a objetos e design patterns (e quando não usá-los).

Os desenvolvedores também precisam ter algum conhecimento de infraestrutura/redes, Linux ou Solaris e deployment de aplicações em Apache, app servers Java diversos (JBoss, Weblogic, etc) ou app servers Ruby On Rails diversos (mod_rails, Mongrel, etc).

Por último, não damos a mínima se você têm trezentas certificações ou oitocentas faculdades – isso não é um diferencial. O que difere um desenvolvedor júnior de um pleno ou sênior é a experiência dele em outras empresas e projetos.

Líder de equipe

Os líderes de equipe são os responsáveis técnicos pelos projetos e produtos desenvolvidos pelos times. Queremos líderes com bons conhecimentos de arquitetura de software para poder decidir com o time as melhores soluções. É desejável que o líder de equipe entenda de escalabilidade, performance, sistemas distribuídos, sistemas de filas, sistemas de cache, arquitetura de serviços e o que mais vier pela frente. Apesar disso ele não precisa ser o mais experiente ou o mais especialista em todos os assuntos – em alguns times os líderes são mais técnicos e em outros times eles são menos técnicos dependendo das responsabilidades e área de atuação do time. No geral o que se espera é que o líder tenha tantos conhecimentos quanto qualquer desenvolvedor, afinal de contas eles também devem arregaçar as mangas e trabalhar como qualquer um no time quando for necessário (obviamente cuidando para não “podar” ou atrapalhar o time ao invés de ajudar). Resumidamente falando, nenhum dos requisitos para a vaga de desenvolvedor podem “soar como grego” para o líder.

Além disso eles são responsáveis por facilitar o trabalho dos times de desenvolvimento. Como trabalhamos com Scrum, os líderes exercem o papel de Scrum Master e por isso precisam entender muito bem como funciona o Scrum e as metodologias ágeis em geral. Os líderes precisam ajudar os gerentes de produto e o time a trabalharem sem violar os princípios ágeis, respeitando timeboxes, respeitando o desenvolvimento iterativo, ajudando para que o planejamento seja feito de forma ágil e facilitando retrospectivas para ajudar o time a evoluir ao longo do tempo. Eles também precisam ser “coaches” dos seus times, treinando-os para fazerem TDD, estimulando-os a refatorarem código para manter os sistemas manuteníveis e testáveis e garantindo eles têm todo o conhecimento que precisam para desempenhar o seu trabalho. Ainda, apesar de todos os membros do time serem responsaveis por manter a qualidade dos produtos, os líderes de equipe precisam garantir que os times não sejam afogados com novas funcionalidades e acabem introduzindo débito técnico. Qualidade aqui não é negociável e os líderes precisam cuidar para que isso seja sempre verdade.

Os líderes de equipe também são responsáveis por manter as pessoas do seu time, contratar novas pessoas quando for necessário e cuidar para que todos estejam felizes no trabalho. Ah, e para esta função falar inglês não é um diferencial, é obrigatório.

Concluindo…

Sejam líderes de equipe ou desenvolvedores, estamos procurando nerds, geeks, apaixonados por tecnologia e pessoas super atualizadas com as últimas novidades da Internet e do mercado. Nossa empresa é jovem, irreverente e descontraída, e são pessoas exatamente assim que estamos procurando.

A empresa oferece contratação apenas por CLT, com salário de mercado e plano de benefícios. Estamos localizados na Barra da Tijuca (Rio de Janeiro). Damos suporte a pessoas de outros estados que queiram mudar para o Rio.

Se você se enquadra num desses perfis, mande um e-mail para mim (gc at corp.globo.com), com o seu currículo e os nomes dos três últimos livros técnicos que leu. Como temos vários sabores de vagas, me diga qual função você gostaria de exercer, o que você espera dessa oportunidade e com o que você gostaria de trabalhar aqui na Globo.com. Se você já enviou seu currículo para alguma das oportunidades anteriores mas também ficou interessado nessa, por favor envie novamente!

Se você não tem exatamente todas essas características mas se interessou pelas oportunidades e pelo que nós fazemos, não deixe de falar com a gente também.

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…

[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams

Saturday, August 23rd, 2008

Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…

O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.

Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.

A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.

Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!

Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.

Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.

A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.

Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.

A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.

Pense fora da caixa!

Times Scrum trabalhando em vários projetos ao mesmo tempo?

Tuesday, July 29th, 2008

Antes de começamos a trabalhar com Scrum na Globo.com, era comum nossa equipe trabalhar em três ou quatro projetos ao mesmo tempo. Cada projeto era tocado por um time de mais ou menos uma a três pessoas e assim íamos fazendo as coisas.

Depois, com o Scrum, acabamos criando um time um pouco maior (de aproximadamente 9 pessoas) e, pela força do hábito, várias vezes nos pegamos com vontade de trabalhar em dois ou três projetos ao mesmo tempo. Talvez dê vontade de fazer isso para ter a impressão de que as coisas estão acontecendo, mesmo que lentamente, e que os projetos estão andando… Mas será que isso vale a pena? Vejamos.

Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.

Falando de forma simplificada, o retorno sobre o investimento é calculado da seguinte forma: se você investe R$ 100,00 em alguma coisa e no final de um período você ganhou R$ 50,00 por conta deste investimento, você teve 50% de ROI. Sendo mais prático, quando você paga alguém para desenvolver um sistema para você, se você gastar R$ 100.000,00 e ganhar R$ 10.000,00 por mês, você está tendo um ROI de 10% por mês. Neste cenário o sistema se pagará em 10 meses, e a partir daí você passa a ter lucro.

Dito isso, vamos pensar numa situação hipotética. Imagine que um time de Scrum está trabalhando em 3 projetos ao mesmo tempo. Constata-se que no fim de 3 meses o time consegue finalizar e colocar em produção todos os 3 projetos:

Tudo ao mesmo tempo 1

Para conseguir entregar esses 3 projetos, o time teve que trabalhar paralelamente em todos eles, usando sempre 1/3 do tempo de cada Sprint para cada um dos projetos. Desta forma só depois de 3 meses o cliente poderia começar a faturar com seus novos produtos.

A pergunta é: não seria muito melhor se o time tivesse trabalhado de forma serial, focando todo seu tempo e esforço em apenas um projeto e entregando uma coisa de cada vez?

Tudo ao mesmo tempo 2

Trabalhando dessa forma, no fim do primeiro mês o primeiro projeto já poderia entrar em produção, antecipando o faturamento, gerando dinheiro (ROI) para o cliente mais rápido e diminuindo o tempo necessário para recuperar seu investimento. Neste caso, a antecipação da entrega de um dos projetos faz com que o cliente comece a faturar 2 meses antes do que poderia – sem dúvidas o ROI foi maximizado.

Voltando ao ponto inicial, é preciso resistir à tentação de querer trabalhar em vários projetos ao mesmo tempo. O melhor é focar no mais importante deles (ou seja, o que vai gerar mais lucro para a empresa) e trabalhar nele até o fim, passando em seguida para o próximo projeto mais importante e assim por diante.

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.