Domingo de treinamento Scrum

Continuando meu relato sobre o treinamento de Scrum que tivemos na globo.com neste final de semana, agora vou falar do segundo dia.

No fim do sábado estávamos falando sobre os Papéis de Scrum, e foi esse tema que iniciou a manhã de domingo. Já no sábado tivemos bastante discussão sobre como isso estava sendo feito na globo.com e como acreditamos que deveria ser.

A problemática está em torno de que os papéis do processo não são como posições ou cargos na empresa. Pelo que pude perceber com o pouco tempo de empresa e com o contato com o pessoal que participou do treinamento, isso não está tão claro para todos os times. Muitos Scrum Masters eram gerentes no processo cascata, e não aderiram a Agilidade. Vestem a roupa do Scrum mas continuam empurrando o processo.

Isso vai contra a idéia do processo/sistema puxado vs. empurrado. No empurrado, as pessoas são designadas a cumprir tarefas, tem a estrutura hierárquica forçando o funcionamento do sistema, enquanto que no puxado, cada um assume a responsabilidade que lhe cabe.

Uma analogia industrial seria falar de uma fábrica em que uma máquina recebe como entrada matéria-prima e retorna algo processado para seguir para uma nova máquina. As máquinas não estão em sincronia, e se a segunda tem capacidade de trabalho menor que a primeira, teremos a formação de um gargalo.
No processo puxado, a última máquina, quando livre, solicita insumo da anterior, que recursivamente vai pedindo material da máquina que lhe precede.

Retomando os papéis, no Scrum temos o Scrum Master, o Product Owner e a Team/Equipe.
As responsabilidades são as seguintes:

• Scrum Master
• Cuidar da Equipe
• Trabalhar com o Product Owner
• Revomer impedimentos
• Manter o processo funcionando
• Socializar Scrum na Organização

• Equipe
• Estimar o tamanho dos itens do Backlog (conjunto de tarefas a serem realizadas)
• Assumir compromisso com a entrega de um incremento de software funcional
• e entregá-lo
• Manter o seu próprio progresso (com o auxílio do Scrum Master)
• Auto-organizados, responsáveis pela entrega daquilo prometido para o Product Owner

• Product Owner
• Trabalhar numa visão compartilhada
• Levantar requisitos
• Gerenciar e priorizar o Product Backlog
• Aceitar o Software no final de cada interação
• Gerenciar o Release Plan
• Responsável pela lucratividade do projeto (ROI)

Ontem, segunda-feira, tive a oportunidade de conversar com um amigo, o Bruno Nascimento, que é gerente numa empresa de desenvolvimento, sobre essa problemática de quem deve assumir cada responsabilidade. Ele me contou que ele tem que conferir e homologar cada código que um desenvolvedor gera, num trabalho manual e centralizado em suas mãos.

Quer dizer que a responsabilidade do código não está na mão da equipe, e sim do gerente. Esse formato acaba causando o efeito "mijada", quando o gerente é cobrado por um software bugado, e ele então passa a culpa para os seus subordinados (a mijada descendo as escadas...), e por aí vai até chegar no pobre coitado estagiário que estava lá trabalhando insatisfeito, fazendo coisas por obrigação, mas que não interferiam diretamente na vida dele (a não ser pela já esperada mijada).

Essa situação pode ser diferente se a responsabilidade de entregar código testado for da equipe. Eles vão se certificar de fazer seu melhor, e sabem que são os responsáveis diretos pela falha. O problema é que estamos sempre procurando alguém para culparmos, e esse alguém sempre precisa de outro alguém para passar a culpa e tirar o seu da reta... É um processo defensivo, não jogamos para ganhar, e sim para esconder o fracasso que estamos temendo. Devemos jogar para ganhar!

Finalizada a discussão sobre os papéis e como colocar na cabeça dos que não querem ter seu queijo mexido que não podemos continuar com a mentalidade anterior, fizemos uma lista dos impedimentos mais comuns que temos no nosso dia-a-dia. E seguimos falando de como implementar o Scrum, das reuniões de planejamento (Estimation Meeting, Planning Meeting, Daily Meeting, Sprint Review).


Foi o momento para falar do conceito de "done" ou "pronto". Já vi discussões sobre isso em diversas listas sobre Agile, nacionais ou internacionais, e o que acaba acontecendo é que cada um tem uma opinião e que funciona. Alguns consideram pronto quando a equipe termina as tarefas da história, outros quando o P.O. aceita, outros quando está em produção, etc.
O importante é ter um conceito bem definido e difundido dentro da equipe, de forma que todos saibam qual é o objetivo, onde "parar" pois o software já está hmm.... pronto!

Fizemos uma atividade de escrever User Stories (estórias) para um Terminal de Auto-Atendimento, identificando o tipo de usuário a que se destina a estória, a funcionalidade e o benefício que esta traz.

As estórias são "lembretes para um conversa futura". Surgiu com o pessoal de Extreme Programming (XP), como forma de indicar o que o software deve fazer. Seria, para os que querem uma comparação, uma forma simples de declarar os casos de uso.

Então, separados em 4 equipes, escremos os cartões (estórias...) com o que nossos terminais deveriam ter/fazer e, em seguida, cada grupo apresentou suas idéias e como cada uma delas funcionava do ponto de vista do usuário, que benefício ele teria caso aquele estória fosse implementada.

Chegou então o momento em que falamos sobre planejar. No XP sabemos que mais vale o ato de planejar do que seguir um plano (que pode se mostrar incoerente com a realidade).
O Juan Bernabó fez essa distinção através de duas outras palavras: estratégia e tática.
Usou o exemplo de uma guerra: um geral pode definir a estratégia de um ataque anos antes do mesmo ser realizado. A estratégia é o "pra que?". A razão de invadir o país pode ser "para conquistar território", para "lutar contra o terror", etc...

Agora a tática, o "como?", se definida 5 anos antes do ataque, só garante uma coisa: o fracasso. Em pouco tempo o campo de batalha pode mudar drasticamente. Fontes de energia podem ser construídas, bases militares mudam de local, sistemas de comunicação mudam, enfim, não podemos prever como será um país com anos de antecedência... nem mesmo meses..., se o ataque fosse mesmo acontecer, a tática seria definida o mais tarde possível. Vem então mais uma idéia do Lean, de evitar tomar decisões cedo, tomá-las sempre no último momento possível.

Posteriormente falamos das estimativas, e do Planning Poker. Em equipe, estimamos pontos para nosso projeto de caixa eletrônico. Neste momento surgiu alguma dificuldade em acertar o valor relativo que a equipe definia para cada item. Com a ajuda do Juan conseguimos entrar num consenso, poderiam jogar valores sem nos preocupar tanto e ir ajustando os pesos de cada item ao longo das outras estimativas.

Então foi mais ou menos assim: pegamos uma estória por vez, e para aquela história colocávamos na mesa uma carta do Planning Poker, como o valor que julgávamos apropriado (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 ou "?"). Se o conseso fosse imediato, o a complexidade da estória estava definida (lembrando que não estimamos tempo...). Caso houvesse disparidade, os extremos explicavam porque colocaram um valor mais baixo ou alto e então novamente jogávamos as cartas, visando o consenso.

Por fim, para terminar o treinamento, executamos 2 sprints no "Jogo da Velocidade", que nada mais era que o XPGame com um nome diferente!
Foi legal trabalhar em equipe, conhecer pessoas novas e trocar idéias.

Do sábado para o domingo, assisti a um vídeo da palestra do Bardusco sobre a implantação do Scrum na globo.com, que me ajudou a entender melhor "aonde estamos". Já havia lido sobre a transição nos diversos blogs, mas ouvir o Bardusco pareceu mais interessante.

Enfim, um final de semana muito bom! (Enquanto meus amigos da universidade se divertiam em Arraial do Cabo... haha)