Novos Desafios…

September 27, 2009

… na Globo.com!

Desde o início do mês estou fazendo parte de um novo time. Trata-se do Time Beta (Peleteiro, Meyer, Cainã Nunes e eu), responsável pelo desenvolvimento de novos produtos (ou novas versões de produtos existentes). Nosso primeiro produto é o Baixatudo, cujo release inicial já está no ar. Consideramos esse release uma versão bem básica do produto. Temos muito trabalho ainda pela frente e esperamos nos próximos releases entregar um produto cada vez melhor.

O lado ruim dessa mudança é sair do time de webmedia, onde tive a oportunidade de trabalhar com pessoas fodas e aprendi bastante! Nesse tempo que estive lá, trabalhamos em projetos bem interessantes. Além disso, acredito que tivemos algumas evoluções significativas, como:

  • Melhor preparação do backlog, envolvendo os especialistas de UX junto com o PO para deixar as histórias prontas pro time implementar (ainda há muito que melhorar nisso, mas acredito que foi dado um importante primeiro passo). Mais sobre isso em um post que já está tempo demais no meu drafts;
  • Cultura de deixar bem explícito os problemas que estamos enfrentando, com dados concretos, mostrando os impactos no projeto;
  • Grande preocupação com práticas ágeis como programação em par, desenvolvimento outside-in, TDD, BDD, integração contínua, etc. Sempre feito de forma pragmática, ou seja, focado em melhorar o desempenho do time e não por se tratar da última moda.

Por outro lado, no novo time estou bastante empolgado pois volto a exercer um papel mais de desenvolvimento. Tenho certeza que vou aprender e evoluir bastante e espero poder contribuir para o sucesso dos nossos projetos.

Ah, não se esqueça, estamos contratando!


Scrum Gathering Brazil 2009

May 11, 2009

Nesta terça (12/05) e quarta (13/05) estarei no Scrum Gathering Brazil 2009. O evento promete, com apresentações de profissionais nacionais e internacionais.

O que rolar no evento vou postar aqui ou no meu twitter.


Priorização de Histórias

December 7, 2008

Nos métodos ágeis, o Cliente ou Product Owner deve priorizar as histórias que serão desenvolvidas de forma a maximizar o Return On Investment (ROI).

Vamos supor dois cenários de projeto diferentes. Num, o cliente estipula uma data limite para o release do projeto mas não podemos prever quais histórias estarão prontas até lá. No outro, o cliente define o conjunto mínimo de histórias necessário para o release mas não temos como saber quando elas estarão prontas.

No primeiro cenário é bem claro qual a vantagem em priorizar as histórias. Quando chegar a data limite para o release, o time terá desenvolvido as histórias que agregam o maior valor para o cliente. Ficará de fora aquilo que é menos importante.

No segundo cenário poderia se argumentar que a priorização não é importante. Como todas as histórias serão desenvolvidas de qualquer maneira, tanto faz a ordem. Mas isso não é verdade. A priorização nesse cenário é tão importante quanto no anterior.

Em primeiro lugar, a decisão de só fazer o release quando o conjunto de histórias estiver pronto pode mudar. Por exemplo, pode surgir um novo projeto, mais importante, e se decidir por fazer o release com o que estiver pronto. Nesse caso, é importante que o que estiver pronto seja o que agrega mais valor.

Além disso, mesmo que a estratégia inicial seja mantida e o produto só seja lançado quando o conjunto de histórias estiver todo pronto, a priorização é importante para manter o foco no problema que se quer resolver com o produto. Isso ajuda a definir claramente para todos os envolvidos qual a visão para o produto.


Falando em Agile 2008

October 22, 2008

Nesta quinta e sexta-feira (23 e 24/10/2008) estarei em SP para o Falando em Agile, um grande evento sobre métodos ágeis. Organizado pela Caelum, contará com palestras de Guilherme Chapiewski, Phillip Calçado, Antônio Carlos Silveira e Danilo Bardusco, entre outros.

Certamente promete!


Globo Vídeos no seu iPhone

September 25, 2008

Já está no ar uma versão do Globo Vídeos otimizada para iPhone em http://m.video.globo.com. Com direito a efeitos que os usuários deste aparelho já estão acostumados, como transições ao navegar de uma página para outra, e de girar o aparelho.

Graças aos métodos ágeis que usamos aqui na Globo.com, o site foi totalmente desenvolvido em 2 sprints de 2 semanas. Quando digo totalmente, foi desde a infraestrutura necessária para produzir vídeos até o site propriamente dito.

Me arrisco a dizer que é um dos melhores sites para iPhone existentes. Certamente merece todo o nosso respeito tecnológico!

Além disso, agora também é possível assistir no iPhone os vídeos disponíveis nas versões clássicas dos sites da Globo.com, como G1 e Globoesporte. Essa funcionalidade surgiu como um projeto pessoal da nossa equipe sendo lançado agora também.

O Guilherme Chapiewski fala mais em seu blog tanto sobre o Globo Vídeos Mobile quanto sobre os vídeos para iPhone nas versões clássicas dos sites Globo.com, inclusive com screenshots.


Critérios de Aceitação

April 21, 2008

Recentemente escrevi aqui que passamos a definir critérios de aceitação para cada história durante o sprint planning. Os critérios são escritos na parte de trás dos post-its e servem como referência do que deve ser feito para que o Product Owner (PO) considere uma história como aceita.

Um fenômeno interessante que eu e outros membros do time temos observado é que em raríssimas ocasiões durante o sprint nós pegamos um post-it para ler os critérios que estão escritos atrás. À primeira vista pode parecer, então, que essa prática não está trazendo nenhum benefício. Muito pelo contrário. Os resultados que estamos obtendo são muito positivos.

O que acontece é que o valor dessa prática não está nos critérios em si e sim no processo de definí-los. Ao fazermos isso no sprint planning, cria-se um entendimento comum entre todos – time, PO, Scrum Master – evitando que seja entregue algo diferente do que o PO esperava.

É mais ou menos o que ocorre com a cola de uma prova na escola/faculdade. É comum alguém preparar uma cola bastante elaborada e na hora da prova não precisar consultá-la. Isso porque o simples ato de preparar a cola é suficiente para sedimentar bem o conteúdo da matéria, tornando a cola em si desnecessária.


Problemas no Sprint Review

March 21, 2008

Recentemente tivemos um problema aqui na Globo.com em relação ao entendimento de uma história. Basicamente, o time tinha entendido a história de uma forma um pouco diferente do que o Product Owner (PO) tinha solicitado. No Sprint Review, quando as histórias que foram implementadas são demonstradas para o PO, descobriu-se essa pequena discrepância entre os entendimentos do time e do PO. Ou seja, a história da forma como tinha sido implementada não trazia o valor esperado pelo PO. O problema não foi nada muito sério e já temos uma história no próximo sprint para resolvê-lo.

Mesmo assim, esse tipo de surpresa não deve ocorrer em um Sprint Review. Seguindo a idéia dos métodos ágeis de que deve haver uma melhoria contínua, temos duas sugestões que foram aceitas por todos e que estão sendo adotadas já no próximo sprint para avaliarmos se resolvem este tipo de problema.

A primeira é definir critérios de aceitação para cada história. Esses critérios são validados pelo PO e são parâmetros objetivos para que uma história seja aceita ou não. Os critérios são utilizados, também, como input para a definição de testes de aceitação automatizados. Esses testes devem ser escritos no começo de cada história. Depois, o time implementa a história até fazer os testes passar.

A segunda é termos o PO mais presente ao longo do sprint, acompanhando se o que o time está desenvolvendo atende aos critérios de aceitação de cada história. Dessa forma, possíveis erros de entendimento podem ser eliminados mais cedo, evitando surpresas no Sprint Review.