jump to navigation

O desafio de criar a visão do projeto 22/05/2008

Por: Bruno Mentges de Carvalho , 5 comentarios

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.

Daily Meeting é comprometimento 19/05/2008

Por: Bruno Mentges de Carvalho , 13 comentarios

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:

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)

7 Mitos Sobre Ter Seu Próprio Negócio 14/08/2006

Por: Bruno Mentges de Carvalho , 25 comentarios

Já que há tantos mitos sobre ter seu próprio negócio, especialmente entre aqueles que são empregados há tempos, resolvi escrever sobre os 7 mitos sobre ter seu próprio negócio (ou ser autônomo, freelancer, trabalhar por conta própria, etc).

(Continue lendo…)