Scrum - Projetos Ágeis e Pessoas Felizes

Cesar Brod

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Parte VI

Crônicas do Isolamento Social

Posfácio

A resposta é 42

Capítulo 20 – Antes do primeiro Sprint

Você já tem um Product Backlog e seu Product Owner definido? É hora de estimar e decidir quais ferramentas utilizar no desenvolvimento.

Quando aplico essas dinâmicas como parte de minhas oficinas de métodos ágeis, digo aos participantes que experimentaremos uma relação de amor e ódio e peço que confiem em mim. Essa é a dinâmica que flerta com o ódio pois tirará os participantes da zona de conforto em que entraram, dentro de suas equipes de produto na qual trabalharam na construção do Product Backlog e por meio das quais chegaram a um Mínimo Produto Viável (MVP – Minimum Viaple Product, com o auxílio do Product Vision Board (Capítulo 19).

Aliás, fica aqui uma dica para essas dinâmicas e para a sequência dos trabalhos com métodos ágeis. Você lembra que responder às mudanças é mais importante que seguir um plano, certo? Pode parecer paradoxal dizer isso, mas ao preparar um time Scrum é sempre importante sair da zona de conforto, a ponto da equipe sentir-se confortável até com o desconforto. É por isso que, em todas as dinâmicas que conduzo, não permito o uso de computadores e sempre que possível faço com que os participantes estejam longe de seu ambiente de trabalho (ou ao menos de sua mesa). Como você percebeu, também trabalhamos muito com ferramentas visuais, papéis, notas adesivas, desenhos e muita conversa, coisas que, infelizmente e até hoje, passam ao largo de muitos times de desenvolvimento de produtos. Apresentar essa dinâmica falando sobre esse parágrafo já serve como um antídoto para potenciais reações negativas.

Nesse momento, cada equipe deve ter seu “ambiente” preparado, com os artefatos que auxiliaram na descoberta do produto colados na parede. Eu gosto do seguinte formato: bem à esquerda, o Storyboard (ou Storyboards), logo à direita dele, todo o Product Backlog evidenciado, com o MVP destacado (desenhe uma caixa em torno das histórias que compõem o MVP) e, a seguir, o Product Vision Board. Deixe bastante espaço à direita desses artefatos, pois outros virão a seguir.

Peça que o Product Owner eleito pela equipe dê um passo à frente e aproveite para fazer uma rápida revisão do papel do Product Owner. Ele é a voz do produto, único responsável pelo Product Backlog, possui autoridade sobre orçamentos e retorno do investimento, permitirá que a equipe esteja blindada contra influências externas durante o Sprint. A seguir, peça que todos os demais componentes da equipe se desloquem para a esquerda (eu sempre prefiro que os deslocamentos sejam para a esquerda) e apresentem à equipe, que agora passa a ser de desenvolvedores, o seu novo Product Owner!

É claro que você não iria permitir que as equipes desenvolvessem os próprios produtos que imaginaram, né?

O Product Owner percorrerá os artefatos colados na parede e contará para a equipe a história de desenvolvimento do produto, chegando ao Product Backlog e ao seu MVP. A equipe terá questionamentos que servirão para elucidar certas histórias, agrupando-as em temas ou quebrando histórias grandes (épicos) em histórias menores. Como o tempo não é eterno, o Product Owner deve incentivar a equipe a conhecer todo o Product Backlog, mas deve concentrar-se prioritariamente no MVP. A equipe pode concluir que certas histórias que não estão no MVP podem, de fato, ser pré-requisitos para a realização do mesmo. Uma discussão como essa pode, por exemplo, acontecer:

Equipe: Essa história do MVP – como dono de um pet, desejo visualizar no mapa uma lista de consultórios veterinários próximos ao local onde pretendo morar para que eu possa caminhar até o estabelecimento e ter meu pet atendido caso ele tenha problemas de saúde – apenas pode ser realizada se essa outra – como veterinário, desejo cadastrar minha clínica para que ela possa ser descoberta por donos de pets na minha região – for atendida.

O Product Owner pode responder de duas maneiras:

PO: Vocês estão corretos. Vou trazer a história que é prerrequisito também para o MVP.

ou

PO: Pensei nisso quando da definição do MVP. Nesse momento, para a apresentação aos patrocinadores, vocês trabalharão com uma lista de consultórios veterinários e pet-shops pré-cadastrados.

Enfim, é o Product Owner que tem a palavra final sobre o Product Backlog.

Uma vez feitos os devidos esclarecimentos, a equipe irá pontuar o esforço para o desenvolvimento, com ênfase no Product Backlog. Na vida real, a equipe já terá ideia das ferramentas com as quais irá trabalhar, cada um conhece suas habilidades e seu repertório de projetos anteriores e tudo isso servirá para que ela tenha uma noção do esforço de desenvolvimento de cada história. Para essa dinâmica, apresentaremos para a equipe as ferramentas disponíveis para a prototipia de papel.

Felizmente, a equipe do Laboratório de Tecnologia da Informação Aplicada da UNESP (https://www.ltia.fc.unesp.br/) foi extremamente gentil ao disponibilizar um vídeo, com menos de quatro minutos de duração, onde apresenta, de forma prática e divertida, como usar a técnica da prototipagem em papel. Antes de começar a estimar as histórias, mostre o vídeo que está disponível no YouTube, nesse link: https://youtu.be/k9mTvt0LXgk.

Agora, as equipes devem usar a técnica de estimativa com o Poker do Planejamento descrita no Capítulo 8. Permita mais tempo para a discussão nas histórias do Mínimo Produto Viável: caso um membro da equipe atribua oito pontos e outro atribua um uma determinada história, peça que expliquem sua pontuação e incentive a busca de um consenso. Anote na mesma nota adesiva, onde a história está descrita, a estimativa da mesma, em pontos (pessoalmente, uso o canto superior direito).

Para as histórias que estão no Product Backlog mas que não fazem parte do MVP, a equipe também deve fazer o exercício de pontuação, mas de forma mais grosseira. Não se busca o consenso, apenas uma média para cada história, já que o que buscamos aqui é um “chute” a ser calibrado na evolução da aprendizagem do Scrum e suas estimativas.

Nesse exercício, lembre-se de estabelecer tempos para cada um de seus componentes a fim de evitar parálises e sempre incentivar o ritmo. Meio dia ou um dia deve ser tempo suficiente para concluir essa dinâmica. Em um projeto real, gosto que as propostas dessa dinâmica ocorram como parte do Sprint Zero (Capítulo 11).

Já avise os participantes a trazerem, para a próxima dinâmica, o estojo de materiais de escola de seus filhos ou sobrinhos (lápis de cor, canetinhas coloridas, revistas velhas).

 

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Parte VI

Crônicas do Isolamento Social

Posfácio

A resposta é 42

Utilizamos cookies para melhorar a sua experiência em nosso site. Para mais informações, visite nossa Política de Privacidade.