Posts de May, 2008

[Rafael Silva Pereira] DimP – A Direct Manipulation Video Player

Wednesday, May 28th, 2008

DimPO Aviz, um time de pesquisa do INRIA (Instituto Nacional de Pesquisa em Informática e Automação da França), divulgou recentemente na SIGCHI Conference, um protótipo de um player de vídeo que permite a navegação no vídeo através da manipulação direta do conteúdo. Isto significa que, para realizar um “seek” no vídeo, o usuário pode simplesmente clicar em um objeto do mesmo, e, em seguida, arrastá-lo na direção desejada.

Para implementar este novo tipo de navegação, o player identifica os objetos de uma determinada cena, e, em seguida, mapeia o movimento para cada frame de vídeo, estabelecendo um caminho ao longo do tempo. Assim, ao contrário do que parece, os objetos não são “destacados” do vídeo.

Este conceito de navegação é extremamente interessante, principalmente por ser muito mais intuitivo que o seek tradicional. Para quem quiser mais informações, recomendo bastante a leitura do artigo Video browsing by direct manipulation, que explica com detalhes a implementação.

[Rafael Silva Pereira] DimP - A Direct Manipulation Video Player

Wednesday, May 28th, 2008

DimPO Aviz, um time de pesquisa do INRIA (Instituto Nacional de Pesquisa em Informática e Automação da França), divulgou recentemente na SIGCHI Conference, um protótipo de um player de vídeo que permite a navegação no vídeo através da manipulação direta do conteúdo. Isto significa que, para realizar um “seek” no vídeo, o usuário pode simplesmente clicar em um objeto do mesmo, e, em seguida, arrastá-lo na direção desejada.

Para implementar este novo tipo de navegação, o player identifica os objetos de uma determinada cena, e, em seguida, mapeia o movimento para cada frame de vídeo, estabelecendo um caminho ao longo do tempo. Assim, ao contrário do que parece, os objetos não são “destacados” do vídeo.

Este conceito de navegação é extremamente interessante, principalmente por ser muito mais intuitivo que o seek tradicional. Para quem quiser mais informações, recomendo bastante a leitura do artigo Video browsing by direct manipulation, que explica com detalhes a implementação.

[Rafael Silva Pereira] [Streaming Media East 2008] Novidades e Resumo do Evento

Monday, May 26th, 2008

Na última semana estive no Streaming Media East 2008, em Nova York, para conferir as novidades sobre streaming de mídia na internet, e posso dizer que o evento foi bem legal, e bastante proveitoso, mesmo tendo algumas sessões lamentáveis. Porém, antes de mais nada, gostaria de pedir desculpas pois não consegui atualizar o blog com a freqüência que eu queria, já que, por incrível que pareça, existem mais hot-spots abertos no Rio que em NYC!!!

No primeiro dia de evento, assisti dois workshops de 3hrs cada: “Comparing and Using Video Codecs” e “Microsoft Silverlight”. Estava especialmente interessado no primeiro deles, já que a descrição do workshop dizia que seria apresentada uma comparação entre WMV, VP6 e H.264. Infelizmente fiquei bastante frustrado, e acredito que esta tenha sido a apresentação sobre codecs de vídeo mais rídicula e inútil que eu já vi. O palestrante foi totalmente superficial, não entrando em nenhum detalhe mais específico de nenhum dos codecs. Durante a apresentação, ele ignorou toda e qualquer solução open-source, de qualquer codec, inclusive a libx264, que é sem dúvida nenhuma a melhor implementação de H.264, inclusive quando comparamos com implementações proprietárias. Não citou o ffmpeg ou o mencoder, e ainda desconversou quando foi perguntado à respeito delas. Finalmente, para perder completamente o crédito, apresentou um comparativo de encoders com notas dadas subjetivamente para critérios que ele definiu como importante, ignorando absolutamente todos os métodos objetivos/científicos de avaliação de qualidade (PSNR, SSIM, MSE, etc). Ele ainda criticou bastante o Sorenson, e parecia um representante comercial da On2 querendo vender o VP6, apesar de não ter argumentos quando questionaram sua posição dizendo que o YouTube usa Sorenson.

O segundo workshop, de Silverlight, foi bastante proveitoso, já que confirmou todas as críticas que faço, além de reforçar minhas convicções de que ele é uma porcaria que a Microsoft está tentando empurrar para o mercado. Durante 3hrs, o Silverlight Evangelist não conseguiu fazer sequer um exemplo, conseguiu crashear o IE duas vezes, e desconversou quando pediram um comparativo com o Flash. Como mais da metade dos presentes foi embora antes de 2hrs, acho que todos estão convencidos de que não dá para fazer muita coisa com o Silverlight não, então, se vocês querem um conselho, esqueçam que ele existe.

Apesar de um primeiro dia terrível, o segundo dia valeu por cada centavo pago na inscrição. O keynote de abertura, com o CDO da NBC, foi bem legal, principalmente para saber o que grandes broadcasters como a NBC estão fazendo, e o que eles esperam do mercado. Em seguida, assisti uma mesa redonda sobre a convergência H.264, onde estavam presentes o Product Manager do Flash Media Server e o Video Architect do Yahoo!, além de um representante da Akamai e um da Move Networks. O grande ponto desta sessão foi opinião unânime de que o H.264 é o formato da nova geração de vídeos que irá ser responsável pela convergência de conteúdo entre TV, Internet e Celular. A Adobe está apostando bastante nisso, e certamente a parte de streaming/vídeo vai receber bastante investimento nos próximos anos. Um ponto importante que todos lembraram é a questão do licenciamento do H.264, que será revisado pelo MPEG/LA em dezembro de 2010, e pode impactar bastante à indústria.

Outra sessão bem interessante foi sobre os preços de CDN’s e sobre P2P, onde houve muita discussão sobre a queda que vem ocorrendo nos preços para utilização de CDN’s, e sobre as alternativas para delivery de vídeos, como P2P. Na verdade, o grande problema que todos enxergam no P2P é a necessidade de instalação de um software adicional, que realmente prejudica a experiência do usuário.

No segundo dia, fui à um keynote com o responsável pelo CNNMoney.com, onde ele apresentou como é a estrutura de publicação/produção deles. Apesar de ter uma produção bem pequena (20 vídeos por dia), foi legal ver como é o processo desde a captura no estúdio (com câmeras HD da Sony e Anycast) até a publicação na internet, depois de editar o conteúdo no Final Cut Pro.

Além disso, a pergunta que eu mais ouvi durante todo o evento é como ganhar dinheiro com vídeo na internet, ou seja, como transformar todas as iniciativas, desde VoD até Lifecasting, em um negócio rentável, principalmente através de publicidade. A verdade é que ninguém sabe ao certo como transformar toda a audiência dos sites de vídeo em dinheiro, e estão todos experimentando suas soluções. Neste ponto específico, acho que a Globo.com está com um modelo bem interessante, que deve se firmar no mercado.

Em resumo, valeu bastante a ida ao evento, e recomendo para todos que tiverem algum interesse no mercado de streaming, principalmente para aqueles que estão começando agora.

Se alguém tiver interesse, algumas apresentações do evento estão aqui.

[Rafael Silva Pereira] [Streaming Media East 2008] Novidades e Resumo do Evento

Monday, May 26th, 2008

Na última semana estive no Streaming Media East 2008, em Nova York, para conferir as novidades sobre streaming de mídia na internet, e posso dizer que o evento foi bem legal, e bastante proveitoso, mesmo tendo algumas sessões lamentáveis. Porém, antes de mais nada, gostaria de pedir desculpas pois não consegui atualizar o blog com a freqüência que eu queria, já que, por incrível que pareça, existem mais hot-spots abertos no Rio que em NYC!!!

No primeiro dia de evento, assisti dois workshops de 3hrs cada: “Comparing and Using Video Codecs” e “Microsoft Silverlight”. Estava especialmente interessado no primeiro deles, já que a descrição do workshop dizia que seria apresentada uma comparação entre WMV, VP6 e H.264. Infelizmente fiquei bastante frustrado, e acredito que esta tenha sido a apresentação sobre codecs de vídeo mais rídicula e inútil que eu já vi. O palestrante foi totalmente superficial, não entrando em nenhum detalhe mais específico de nenhum dos codecs. Durante a apresentação, ele ignorou toda e qualquer solução open-source, de qualquer codec, inclusive a libx264, que é sem dúvida nenhuma a melhor implementação de H.264, inclusive quando comparamos com implementações proprietárias. Não citou o ffmpeg ou o mencoder, e ainda desconversou quando foi perguntado à respeito delas. Finalmente, para perder completamente o crédito, apresentou um comparativo de encoders com notas dadas subjetivamente para critérios que ele definiu como importante, ignorando absolutamente todos os métodos objetivos/científicos de avaliação de qualidade (PSNR, SSIM, MSE, etc). Ele ainda criticou bastante o Sorenson, e parecia um representante comercial da On2 querendo vender o VP6, apesar de não ter argumentos quando questionaram sua posição dizendo que o YouTube usa Sorenson.

O segundo workshop, de Silverlight, foi bastante proveitoso, já que confirmou todas as críticas que faço, além de reforçar minhas convicções de que ele é uma porcaria que a Microsoft está tentando empurrar para o mercado. Durante 3hrs, o Silverlight Evangelist não conseguiu fazer sequer um exemplo, conseguiu crashear o IE duas vezes, e desconversou quando pediram um comparativo com o Flash. Como mais da metade dos presentes foi embora antes de 2hrs, acho que todos estão convencidos de que não dá para fazer muita coisa com o Silverlight não, então, se vocês querem um conselho, esqueçam que ele existe.

Apesar de um primeiro dia terrível, o segundo dia valeu por cada centavo pago na inscrição. O keynote de abertura, com o CDO da NBC, foi bem legal, principalmente para saber o que grandes broadcasters como a NBC estão fazendo, e o que eles esperam do mercado. Em seguida, assisti uma mesa redonda sobre a convergência H.264, onde estavam presentes o Product Manager do Flash Media Server e o Video Architect do Yahoo!, além de um representante da Akamai e um da Move Networks. O grande ponto desta sessão foi opinião unânime de que o H.264 é o formato da nova geração de vídeos que irá ser responsável pela convergência de conteúdo entre TV, Internet e Celular. A Adobe está apostando bastante nisso, e certamente a parte de streaming/vídeo vai receber bastante investimento nos próximos anos. Um ponto importante que todos lembraram é a questão do licenciamento do H.264, que será revisado pelo MPEG/LA em dezembro de 2010, e pode impactar bastante à indústria.

Outra sessão bem interessante foi sobre os preços de CDN’s e sobre P2P, onde houve muita discussão sobre a queda que vem ocorrendo nos preços para utilização de CDN’s, e sobre as alternativas para delivery de vídeos, como P2P. Na verdade, o grande problema que todos enxergam no P2P é a necessidade de instalação de um software adicional, que realmente prejudica a experiência do usuário.

No segundo dia, fui à um keynote com o responsável pelo CNNMoney.com, onde ele apresentou como é a estrutura de publicação/produção deles. Apesar de ter uma produção bem pequena (20 vídeos por dia), foi legal ver como é o processo desde a captura no estúdio (com câmeras HD da Sony e Anycast) até a publicação na internet, depois de editar o conteúdo no Final Cut Pro.

Além disso, a pergunta que eu mais ouvi durante todo o evento é como ganhar dinheiro com vídeo na internet, ou seja, como transformar todas as iniciativas, desde VoD até Lifecasting, em um negócio rentável, principalmente através de publicidade. A verdade é que ninguém sabe ao certo como transformar toda a audiência dos sites de vídeo em dinheiro, e estão todos experimentando suas soluções. Neste ponto específico, acho que a Globo.com está com um modelo bem interessante, que deve se firmar no mercado.

Em resumo, valeu bastante a ida ao evento, e recomendo para todos que tiverem algum interesse no mercado de streaming, principalmente para aqueles que estão começando agora.

Se alguém tiver interesse, algumas apresentações do evento estão aqui.

[Danilo Bardusco] Scrum & CMMi

Monday, May 26th, 2008

Na última sexta-feira ( 23/05/08 ) estive em Recife para apresentar a experiência da Globo.com com Scrum.

O Objetivo do evento era discutir até onde Scrum e CMMi eram compatíveis ou antagônicos, e para isso tivemos presenças dos dois lados da moeda.

Boris Gloger concluiu o evento com sua exposição Scrum = CMMi?! A provocation to see the truth”, seguido de um debate/Q&A com o Renato da ISD Brasil.

Em sua apresentação, Boris que além de Certified Scrum trainer também já foi Certificado em CMMi, diz que no nível conceitual Scrum e CMMi são iguais, porém suas implementações no nível tático são totalmente diferentes. Boris recomenda CMMi para corporações grandes e estáveis, onde faz sentido a definição de processos formais que quase não mudam com o passar do tempo. O último slide da sua apresentação resume bem isso. Outro ponto interessante foi a observação de que as novas organizações tendem a ser pequenas, distribuidas e guiadas por mulheres, fato que teve bastante apelo para uma platéia de 68 mulheres e 99 homens.

- Pra quem está procurando uma ferramenta para ajudar a organizar a vida do Scrum Master fica aqui a dica de uma ferramenta promissora, o Fire Scrum produzido pelo pessoal do C.E.S.A.R e liberado sob a licença GPL. Apesar de eu achar que nada substitui o quadro branco com os post-its colados nele, quando se tem muitos times num mesmo projeto, ou times com membros distribuídos fisicamente, uma ferramenta como essa passa a ser fundamental.

- Os slides da minha apresentação estão disponíveis aqui:

pra quem assistiu minha apresentação, dúvidas e comentários são muito bem vindos! Principalmente comentários que me ajudem a melhorar para as próximas.

- Por fim, mas não menos importante, queria agradecer a todo o pessoal de Recife pela simpatia e gentileza com que me receberam, em especial um muito obrigado para a Teresa Maciel do SPIN-Recife, que organizou esse ótimo evento, a Isabela pela recepção, a Cidinha, Eduardo, Marco e todo o pessoal do C.E.S.A.R pelo tour e apresentações.

[Bruno Mentges de Carvalho] O desafio de criar a visão do projeto

Thursday, May 22nd, 2008

No Scrum nosso de cada dia, existe um papel que eu considero o mais difícil de todos: o Product Owner (daqui pra frente, P.O). No Scrum, o P.O. representa o interesse do cliente e é o responsável por definir a visão do projeto, traçar uma estratégia para atingir essa visão incluindo histórias no backlog e definir o que será desenvolvido e entregue nos Sprints pelo time. Ou seja, ele é o responsável direto pelo ROI (Retorno do Investimento).

O meu post hoje foca na visão do projeto e as dificuldades em criá-la, principalmente para um produto já existente, que é o caso da empresa onde trabalho, que há algum tempo resolveu adotar o Scrum.

A visão do projeto é basicamente o que o nome diz: é o motivo para ele existir, sua filosofia e seus conceitos de negócio. No cenário de projetos, existe uma característica que os difere de produtos: projetos tem início, meio e fim. Já para produtos, que é o nosso caso, o P.O. deve não apenas criar uma visão, como também uma expectativa a longo prazo para o produto, e definir limites. Até onde é responsabilidade do produto e até onde queremos chegar.

Essa visão deve ser adaptativa, pois o mundo muda muito rápido, e agilidade em mudar de rumo é vantagem competitiva hoje. Nisso, o Scrum ganha de longe de outras metodologias: você tem entregas em sprints curtos e a próxima entrega ainda será definida, o que dá muita margem para mudanças.

E como fazer quando você quer migrar pro Scrum e você não tinha apenas um stakeholder, de um produto que já existe há pelo menos cinco anos, mas sim vários ?

A primeira coisa a se fazer, acredito, seria pegar todos os requisitos pendentes, ou seja, os já existentes do sistema e organizá-los em histórias, do tipo: “Eu como usuário gostaria de assistir vídeos no linux (em flash)”, ou “Eu como Product Owner gostaria de disponibilizar o player para que outros sites possam incluí-lo (embedded)”. Com todas essas histórias que o produto tinha pela frente postas no papel você consegue ter uma visão geral da direção que o produto estava seguindo.

Descobrindo essa direção você pode: ou se ater à direção atual ou definir uma nova e criar novas histórias para que o produto começe a mudar de direção. O importante é ter essa direção, que não é fácil, diga-se de passagem. Com a direção definida você provavelmente terá agora mais facilidade em estimar o valor de negócio de cada história (valor esse de 0 a 100). O valor de negócio é uma métrica de quanto uma história traria de valor para a empresa em comparação com outra.

Para iniciar essa definição, pegue a história que tenha o menor valor de negócio e estime um número baixo para usar de referência, como 2 por exemplo. Daí, vá pegando as outras histórias e comparativamente dando seus valores de negócio. Rapidamente você terá um quadro bem definido com quais histórias provavelmente você irá atacar nos próximos sprints e conseguirá antever pelo menos 2 ou 3 entregas.

Nisso, é hora de comunicar ao time a estratégia do produto e as histórias que você pretende atacar no futuro próximo. No Sprint Planning 1, que é a primeira de duas reuniões que definem um sprint, o time irá estimar a complexidade que cada história tem e encaixar no Sprint (que no nosso caso leva 2 semanas) aquilo que o time consegue se comprometer em entregar. São também definidos nessa reunião, pelo P.O., o DoD (Definition of Done, ou em português: Definição de Terminado) e os critérios de aceitação.

Com isso tudo feito, é só correr para o abraço. Com o time a par da visão e o sprint definido e bem detalhado, o P.O. poderá ter a certeza que caso ele precise mudar de estratégia, será tão simples como colocar mais itens no backlog do produto, estimar o valor de negócio, re-estimar ou mesmo remover histórias do backlog (não os do sprint atual, claro).

Uma experiência legal que tivemos aqui foi que a nossa P.O. marcou uma reunião para nos passar a visão do projeto, ouvir idéias e ter um feedback do que o time gostaria de sugerir para a plataforma que trabalhamos. O formato da reunião foi o seguinte: Reunimos os dois times que participam do projeto dessa plataforma e de outra plataforma relacionada, misturamos todos e dividimos em dois grupos. Cada grupo teve meia hora para fazer um brainstorm de idéias, colocá-las no papel, sem que ninguém pudesse criticar a idéia do outro, apenas contribuir com as suas. Depois disso (por incrível que pareça, eram 4 folhas A4 de idéias para cada grupo), nós deveríamos discutir as idéias por mais meia hora, eliminando as idéias que fossem claramente ruins. Após essa primeira eliminação e discussão, cada grupo teve 10 minutos para escolher as top 10 idéias.

Foi impressionante como as idéias se mesclavam no final. Das duas listas top 10, conseguimos 12 ou 13 idéias muito boas, e as outras 7 que sobraram eram repetidas. O timebox da reunião foi de 2:30 horas. Em 2 horas e meia conseguimos ver qual a visão a médio e longo prazo da plataforma, ter uma noção muito maior do que é a nossa plataforma para a empresa como um todo e sugerir idéias para melhorar, mudar e acrescentar valor ao projeto.

Off-topic: Como as reuniões estão mais produtivas, depois que adotamos o Scrum… mas isso é assunto pra outro post. Voltando ao tópico e para concluir, esse é o maior desafio, na minha opinião, em uma migração para Scrum: Definir a visão dos projetos.

[Bruno Mentges de Carvalho] O desafio de criar a visão do projeto

Thursday, May 22nd, 2008

No Scrum nosso de cada dia, existe um papel que eu considero o mais difícil de todos: o Product Owner (daqui pra frente, P.O). No Scrum, o P.O. representa o interesse do cliente e é o responsável por definir a visão do projeto, traçar uma estratégia para atingir essa visão incluindo histórias no backlog e definir o que será desenvolvido e entregue nos Sprints pelo time. Ou seja, ele é o responsável direto pelo ROI (Retorno do Investimento).

O meu post hoje foca na visão do projeto e as dificuldades em criá-la, principalmente para um produto já existente, que é o caso da empresa onde trabalho, que há algum tempo resolveu adotar o Scrum.

A visão do projeto é basicamente o que o nome diz: é o motivo para ele existir, sua filosofia e seus conceitos de negócio. No cenário de projetos, existe uma característica que os difere de produtos: projetos tem início, meio e fim. Já para produtos, que é o nosso caso, o P.O. deve não apenas criar uma visão, como também uma expectativa a longo prazo para o produto, e definir limites. Até onde é responsabilidade do produto e até onde queremos chegar.

Essa visão deve ser adaptativa, pois o mundo muda muito rápido, e agilidade em mudar de rumo é vantagem competitiva hoje. Nisso, o Scrum ganha de longe de outras metodologias: você tem entregas em sprints curtos e a próxima entrega ainda será definida, o que dá muita margem para mudanças.

E como fazer quando você quer migrar pro Scrum e você não tinha apenas um stakeholder, de um produto que já existe há pelo menos cinco anos, mas sim vários ?

A primeira coisa a se fazer, acredito, seria pegar todos os requisitos pendentes, ou seja, os já existentes do sistema e organizá-los em histórias, do tipo: “Eu como usuário gostaria de assistir vídeos no linux (em flash)”, ou “Eu como Product Owner gostaria de disponibilizar o player para que outros sites possam incluí-lo (embedded)”. Com todas essas histórias que o produto tinha pela frente postas no papel você consegue ter uma visão geral da direção que o produto estava seguindo.

Descobrindo essa direção você pode: ou se ater à direção atual ou definir uma nova e criar novas histórias para que o produto começe a mudar de direção. O importante é ter essa direção, que não é fácil, diga-se de passagem. Com a direção definida você provavelmente terá agora mais facilidade em estimar o valor de negócio de cada história (valor esse de 0 a 100). O valor de negócio é uma métrica de quanto uma história traria de valor para a empresa em comparação com outra.

Para iniciar essa definição, pegue a história que tenha o menor valor de negócio e estime um número baixo para usar de referência, como 2 por exemplo. Daí, vá pegando as outras histórias e comparativamente dando seus valores de negócio. Rapidamente você terá um quadro bem definido com quais histórias provavelmente você irá atacar nos próximos sprints e conseguirá antever pelo menos 2 ou 3 entregas.

Nisso, é hora de comunicar ao time a estratégia do produto e as histórias que você pretende atacar no futuro próximo. No Sprint Planning 1, que é a primeira de duas reuniões que definem um sprint, o time irá estimar a complexidade que cada história tem e encaixar no Sprint (que no nosso caso leva 2 semanas) aquilo que o time consegue se comprometer em entregar. São também definidos nessa reunião, pelo P.O., o DoD (Definition of Done, ou em português: Definição de Terminado) e os critérios de aceitação.

Com isso tudo feito, é só correr para o abraço. Com o time a par da visão e o sprint definido e bem detalhado, o P.O. poderá ter a certeza que caso ele precise mudar de estratégia, será tão simples como colocar mais itens no backlog do produto, estimar o valor de negócio, re-estimar ou mesmo remover histórias do backlog (não os do sprint atual, claro).

Uma experiência legal que tivemos aqui foi que a nossa P.O. marcou uma reunião para nos passar a visão do projeto, ouvir idéias e ter um feedback do que o time gostaria de sugerir para a plataforma que trabalhamos. O formato da reunião foi o seguinte: Reunimos os dois times que participam do projeto dessa plataforma e de outra plataforma relacionada, misturamos todos e dividimos em dois grupos. Cada grupo teve meia hora para fazer um brainstorm de idéias, colocá-las no papel, sem que ninguém pudesse criticar a idéia do outro, apenas contribuir com as suas. Depois disso (por incrível que pareça, eram 4 folhas A4 de idéias para cada grupo), nós deveríamos discutir as idéias por mais meia hora, eliminando as idéias que fossem claramente ruins. Após essa primeira eliminação e discussão, cada grupo teve 10 minutos para escolher as top 10 idéias.

Foi impressionante como as idéias se mesclavam no final. Das duas listas top 10, conseguimos 12 ou 13 idéias muito boas, e as outras 7 que sobraram eram repetidas. O timebox da reunião foi de 2:30 horas. Em 2 horas e meia conseguimos ver qual a visão a médio e longo prazo da plataforma, ter uma noção muito maior do que é a nossa plataforma para a empresa como um todo e sugerir idéias para melhorar, mudar e acrescentar valor ao projeto.

Off-topic: Como as reuniões estão mais produtivas, depois que adotamos o Scrum… mas isso é assunto pra outro post. Voltando ao tópico e para concluir, esse é o maior desafio, na minha opinião, em uma migração para Scrum: Definir a visão dos projetos.

[Bruno Mentges de Carvalho] Daily Meeting é comprometimento

Monday, May 19th, 2008

Desde que adotamos Scrum na empresa que trabalho, tivemos um impacto enorme no resultado de nossos projetos. A velocidade, conformidade com os requisitos e qualidade dos nossos produtos aumentaram drasticamente. Mas isso não quer dizer que não tivemos nossos problemas ao implementar o Scrum. Hoje quero falar um pouco de uma das mais importantes práticas do Scrum e alguns dos empecilhos que encontramos.

O Daily Meeting é uma reunião do Scrum que ocorre todos os dias e tem as seguintes características:

  • Ela deve ocorrer diariamente e sempre no mesmo horário, que pode ser decidido pelo time no Sprint Planning, e preferencialmente ser sempre pela manhã.
  • O Time e o Scrum Master devem estar presentes.
  • A reunião tem um timebox de 15 minutos e não deve ultrapassar esse tempo.
  • Cada participante do time deve responder a tres perguntas: “O que fiz ontem?”, “O que farei hoje?” e “O que está me impedindo?
  • Todos devem estar de pé. (Afinal, são só 15 minutos)
  • Qualquer um pode assistir a reunião, como chicken* (chicken não pode falar durante a reunião).

Eu faço parte de um time, composto por desenvolvedores, designer e arquiteto da informação. Somos 8 pessoas e o comprometimento e a participação ativa de todos do time é extremamente importante para o sucesso do sprint e consequentemente do projeto como um todo.

O horário oficial de chegada da empresa é as 9:30 da manhã, e nosso time decidiu que o Daily Meeting aconteceria as 10:45. Ainda assim, temos pessoas que chegam atrasado, por motivos diversos. Quando alguém atrasa e não avisa, acontecem diversos efeitos colaterais nocivos ao scrum, como o time não saber se aquela pessoa terminou o trabalho dela, se ela tá tendo problemas ou impedimentos, e o que ela planejava fazer hoje.

Nosso time, em conjunto com o scrum master, começou a elaborar punições. A primeira punição foi que se alguém atrasasse e não tivesse um motivo convincente pra isso (ex. Problemas médicos e tal), o Daily Meeting seria adiantado 15 minutos até o fim do Sprint. Ou seja, alguém atrasou, o Daily Meeting iria pra 10:30, depois 10:15, depois 10:00… até chegar na hora oficial da empresa (9:30).

Essa primeira punição ficou muito rígida, pois não tinha uma contra-moeda pra voltar o tempo e quanto mais cedo o Daily Meeting ficava, mais difícil era de ter todo mundo presente em tempo (trabalhamos num local distante no Rio de Janeiro). Então adaptamos para que se o time ficasse 4 dias sem atrasar, e tivesse alguma penalidade já em prática, essa penalidade seria reduzida em 15 minutos, ou seja, se alguém do time se atrasasse e o daily meeting caísse de 10:45 para 10:30, bastava o time conversar com o cara e o time todo vir 4 dias sem atraso algum para voltar pra 10:45.

Inacreditavelmente isso ainda não funcionou. Ainda assim continuávamos tendo problemas de atraso. Todos sempre esporádicos, mais ainda assim acontecia (no final do Sprint de 10 dias, o daily meeting já estava em 10:15). Todos sentamos pra conversar e ver se não havia ninguém desestimulado, ou com vontade de trocar de time, ou insatisfeito em geral com qualquer coisa, mesmo que pessoal. Após uma longa conversa chegamos a um novo e mais flexível sistema de punição: Se qualquer pessoa for se atrasar por qualquer motivo, deve ligar com pelo menos ~20 minutos de antecedência do daily meeting para o Scrum Master e avisar que vai se atrasar, e contar o que fez e o que está impedindo.

Se isso fosse respeitado, o daily meeting continuaria no mesmo horário e demonstraria que a pessoa estava comprometida em não prejudicar o time todo, mesmo que tivesse um problema qualquer (trânsito, despertador que não toca, sono profundo, etc). E ficaria a cargo do Scrum Master e da gerência controlar quem abusa e quem não abusa de chegar atrasado, ou seja, separar os casos esporádicos dos crônicos e resolver como a empresa achar correto.

Ficamos de usar esse processo flexível nesse sprint para ver como vamos nos sair. Queria saber como você, que também tem esse problema, o enfrenta (E quem não tem, qual a fórmula mágica :P) ? Comente !

UPDATE: (Acertos para refletir o que espero do post)

[Bruno Mentges de Carvalho] Workshop: Modelagem Ágil + Domain Driven Design

Saturday, May 17th, 2008

Tivemos hoje em São Paulo o segundo dia do workshop Modelagem Ágil e Domain Driven Design da Fratech. No primeiro dia, palestrado pelo Manoel Pimentel, foi abordado modelagem ágil e scrum. Foram feitas atividades para demonstrar o que é e o que não é ágil e treinar dois conceitos apresentados durante a palestra: Mind Map Modeling (M3) e UML em Cores.

Particularmente ainda não vejo necessidade de usar UML em Cores. Num mundo cada vez mais ágil, quanto mais detalhes e regras pra uma documentação que deve ser simples e objetiva, menos isso será usado. Em contrapartida, eles apresentaram também a nova buzzword do mercado: Agile Draw, que nada mais é que nossos rascunhos, usando um subset da UML, num whiteboard. Nisso eu acredito :P

O segundo dia foi bem interessante. DDD é um assunto que eu gosto muito, até já li duas vezes o Domain Driven Design do Eric Evans. O palestrante do dia foi Felipe Rodrigues, que também palestrou na QCon 2008 sobre o mesmo assunto. A palestra dele foi muito boa, exemplificando e tentando trazer de maneira mais simples os conceitos não-tão-simples do Domain Driven Design. Tivemos também atividades práticas pra exemplificar o que foi dito.

No mais, o evento foi muito bom. Tive a oportunidade de ver amigos de outros eventos, e trocar experiencias do dia a dia com eles. Amanhã estarei no Falando em Java, que promete.