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.

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 ) ? Comente !

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

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

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.

Li calmamente esses dias o artigo sobre o IE8 e fiquei surpreso com a decisão deles de adotarem mais web standards. O maior desafio deles está em não repetir a má experiência que tiveram quando lançaram o IE7. Nesse lançamento, todos os sites que fizeram workarounds dos problemas do IE6 passaram a não renderizar direito no IE7.

Adotar uma maneira diferente de renderizar conteúdo no IE8 pode causar o mesmo problema de quando lançaram o IE7. Mas para contornar isso, eles criaram um mecanismo para informar o browser IE8 a renderizar no formato IE7 via meta-tags no header. Exemplo:

Ou seja, vão mesmo mudar a forma de renderizar para uma forma mais padrão e deixar a compatibilidade com as versões anteriores pra ser especificada programaticamente. Isso nos afeta muito aqui na globo.com visto que nossos sites tem como premissa funcionar em todos os browsers, provavelmente teremos um bom trabalho de adaptação, mas essa notícia me deixa esperançoso.

Eles inclusive consultaram experts como A List Apart e o Webstandars.org! Impressionante, não ?

Estou ansioso pra ver esse IE8.

É galera, saiu. O Globo Vídeos agora tem a opção tela cheia. O post do Guilherme Chapiewski, nosso líder técnico, detalha todas as motivações que nos levaram a ficar pelo menos 40 dias sem a funcionalidade tela cheia.

Aos que sentiram falta da funcionalidade, ela já está no ar. Aproveitem.

Mais uma vez nossa equipe ninja conseguiu entregar tudo com qualidade e dentro do prazo ! Viva o Scrum !

Quando era criança e queria algo, lá pelos meus bons 3 aninhos de idade, eu abria o berro. Chorava, batia pé, derrubava coisas, reclamava até encher o saco de todo mundo e conseguir o que queria. Tudo aquilo que fazia parte das minhas vontades e que não era atendida, era motivo de reclamação e choro, ensurdecedor. Parece que naturalmente, quando criança, aprendemos a perturbar pra conseguir o que queremos.Ao ficar um pouco mais velho, aprendi a fina arte do negativismo. Ao invés de chorar, dava mil opiniões negativas das coisas que não queria fazer, e olhava de cara feia para aquele presente de natal (meias e cuecas) que com certeza alguém com 9 anos de idade não gostaria de ganhar.

Na adolescencia o caos toma conta. Tudo é ruim exceto as suas opiniões, a família já não parece tão perfeita como parecia, e as máscaras caem. Se algo não sai como quer, já viu né… estresse total. Aos pais que passam por essa fase: parabéns.

O ponto que quero chegar é: Aprendemos desde cedo a ser negativos e criticar tudo e todos. Algumas pessoas amadurecem e deixam essa característica de lado, apreciando mais a vida. Outras continuam sendo negativas com tudo e todos.

Só que isso pode ser muito produtivo. Talvez muito mais produtivo do que qualquer opinião positiva. Um exemplo disso está nos comentários do meu post sobre o novo player do Globo Vídeos.

Segue alguns trechos dos comentários abaixo:

“Parabens!!!!(ironico) Com esta mudanca eu nao posso mais assistir os meus videos em tela cheia. Um passo para tras de vcs. Vcs deveriam ter deixado as duas opcoes e agora como faco para assistir meus videos em tela cheia ? … p.s: estou indignado” - Cristiano P. de Carvalho

“Eu sou assinate da Globo Vídeos e fiquei extremamente insatisfeito com essa mudança … Além de o serviço do Globo Vídeos estar lento ao extremo algum ‘gênio’ retirou a opção de ‘tela cheia’ …” - Douglas SVH

Eu particularmente gosto de críticas pois demonstram duas coisas: 1. A pessoa realmente se importa com o que está falando. 2. Faz com que eu me aproxime das reais necessidades dos usuários só com o fato de ouvir essas críticas.

Eu não estou falando que devemos criticar tudo e aceitar todo tipo de crítica, ainda mais as infundadas. Porém, é importante ouvi-las e avaliar se o que a pessoa está dizendo tem valor.

O mau hábito está em criticar sem conhecer. Obviamente a funcionalidade ‘tela cheia’, que foi o motivo dessas reclamações, está nos planos e deve ser lançada em breve. Haviam vários motivos técnicos e de negócio para que essa mudança ocorresse e nós demos um duro danado para fazer ela acontecer e ficar disponível com o mínimo aceitável de funcionalidades.

Minha dica é: Se você tem alguma crítica sobre algo, primeiro verifique se a crítica não pode ser dada em forma de sugestão. Sugerir algo é muito melhor que criticar, e você faz amigos. Uma pessoa que sempre critica as coisas geralmente é evitada.

E cá entre nós, para um mês de desenvolvimento, fizemos um puta de um belo trabalho

Como vocês devem saber, trabalho na Globo.com. Há algum tempo adotamos metodologias ágeis e SCRUM na nossa equipe e hoje, com orgulho, terminamos um projeto em um mês, que envolvia migrar uma infra estrutura pra lá de antiga, aprender uma tecnologia nova (Flash), desenvolver, testar e ter qualidade para termos um player em Flash para os vídeos do Globo Vídeos.

Agora com o player em flash usuários de linux e mac poderão assistir sem problemas nossos vídeos.

Pois é, toda a equipe de WebMedia está de parabéns.

Assim como Guilherme Chapiewski, também fiz o curso de certificação Scrum Master da Sprint iT. Nosso instrutor, Boris Gloger, foi o primeiro Scrum Master treinado por ninguém menos que Ken Schwaber.

O curso foi fantástico, e as atividades foram muito interessantes. O curso realmente mudou muitos conceitos que eu tinha sobre desenvolvimento de software. Saí de lá com muitas idéias e querendo mudar tudo !

Fotos do curso aqui: http://www.flickr.com/photos/bmentges/tags/scrum/

Hoje foi o dia mais interessante do evento. Carlos Villela abriu o dia questionando o porque de determinadas empresas utilizarem Java pra tudo, e foi uma conversa rápida. Logo após, Phillip Calçado palestrou sobre Arquitetura de Software e foi muito interessante pois Phillip consegue envolver bastante a platéia no assunto e explicou porque muitas das escolhas que parecem inteligentes (como Arquiteturas de Referência, por exemplo) são péssimas escolhas.

Depois do Phillip entrou Danilo Sato palestrando sobre Agile Software Development. Tivemos mais uma vez uma excelente apresentação sobre desenvolvimento ágil, que mostra que waterfal não tá com nada ! Acho que todo gerente, diretor e líderes de equipe de desenvolvimento de software deveriam assistir a esta palestra. Imperdível.

Depois disso a galera migrou pra uma churrascaria, e foi muito legal conhecer a galera que foi lá.

Na volta, acabamos chegando no finalzinho da palestra sobre design patterns e ocorreu o evento mais legal: A oficina de arquiteto do Phillip. Juntamos todo mundo em volta de um quadro branco e começamos a dividir o conhecimento que temos em nossos projetos e foi muito, muito legal mesmo ver o que cada um usa em seus projetos, os porques, as vantagens e desvantagens e o mais importante: a experiencia real em produção de cada solução.

Pra finalizar o dia, tivemos uma excelente palestra do Fernando Meyer sobre DSLs, ANTLr e como construir na prática uma DSL.

O evento e os organizadores estão de parabéns. Muito boa a experiência. No fim, eu e Tiago Motta fomos ao aeroporto enfrentando o trânsito padrão de São Paulo, nosso vôo atrasou mais de 30 minutos e fizemos um péssimo pouso com o avião tremendo todo hehe.

Ahhhh Rio de Janeiro, finalmente

Primeiro dia de Conexão Java, e já tenho alguns comentários. Primeiramente o lugar é muito bom. A faculdade Anhembi Morumbi é muito bem organizada, tem uma ótima sala de conferência e um laboratório muito bom também.

Das palestras, assisti todas as 4: Java ME, Scrum, Jboss jBPM e Performance em Aplicações Java. Todas muito boa palestra, exceto a sobre o Jboss jBPM. O palestrante foi bem em explicar um complicado framework, mas eu particularmente não curto bastante palestra sobre frameworks que solucionam problemas específicos, ainda mais sobre um framework em especial e não sobre os conceitos e soluções em volta do problema. Fica parecendo palestra comercial…

Sobre Java ME, foi interessante e o palestrante Thadeu Russo fez um bom overview sobre a plataforma. Já a palestra seguinte, sobre Scrum, o palestrante Alexandre Magno fez uma excelente palestra, com uma boa pitada de humor, e uma boa habilidade em conduzir a platéia ao assunto. Foi muito bom rever os conceitos de Scrum (que temos aplicado na empresa onde trabalho) e avaliar o que estamos fazendo e o que ainda falta fazer para ficarmos 100% scrum compliant.

Tivemos coffee break e o almoço não pode ser em um lugar diferente de BURGER KING. Desde que fui aos EUA e comi lá que queria poder comer no Brasil, porém só tem aqui em São Paulo (espero que por pouco tempo) e era bem pertinho da faculdade.

Ao voltar do almoço, tivemos a palestra do Jboss, que foi um pouco confusa e cheia de dúvidas pois a solução é bem específica e complexa. Logo após teve uma excelente palestra sobre performance de aplicações Java e o assunto é bastante extenso e interessante.

Depois, chamamos um taxi para ir ao hotel, e o taxista se perdeu. Quase fomos parar na radial leste quando o taxista se tocou que o gps tava errado. Fora o trânsito, que pelo amor de Deus, é horrível.

Excelente a experiência até o momento. Pude conhecer figuras conhecidas do GUJ como Luca, Lipe, Villela, dentre outros e as conversas sempre em alto nível. Ah, ganhei do Tiago na sinuca tb ! haha

Bom é isso ae, amanhã tem mais