Lições de Scrum para projetos de P&D

Este documento descreve uma adaptação da metodologia ágil Scrum voltada para a Pesquisa Aplicada.

A estrutura e parte do conteúdo da metodologia aqui descrita são derivadas do guia oficial do Scrum, escrito por Ken Schwaber e Jeff Sutherland, os criadores do Scrum, disponível em scrum.org. Este trabalho também é inspirado no método SCORE, ou “SCrum fOr REsearch”, de Michael Hicks e Jeffrey S. Foster ¹.

Autor: Vitor Casadei

---

1. Eventos e Cerimônias do Scrum

1.1 O Sprint

1.1.1 Descrição

Os Sprints são o coração do Scrum, onde ideias se transformam em valor.

São eventos de duração fixa, geralmente de 4 semanas ou menos, para criar consistência. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

Todo o trabalho necessário para alcançar o Research Goal, incluindo a Sprint Planning, as Daily Scrums, a Sprint Review e a Sprint Retrospective, acontece dentro dos Sprints.

Durante o Sprint:

• Nenhuma mudança é feita que coloque em risco o Sprint Goal;
• A qualidade não diminui;
• O Research Backlog é refinado conforme necessário.

1.1.2 Na Prática

Os Sprints permitem previsibilidade ao garantir a inspeção e adaptação do progresso em direção a um Research Goal. Quando o horizonte de um Sprint é longo demais, o Sprint Goal pode se tornar inválido, a complexidade pode aumentar e o risco pode crescer. Sprints mais curtos podem ser usados para gerar mais ciclos de aprendizado e limitar o risco de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado um pequeno projeto; no entanto, no ambiente de pesquisa, muitas linhas de pesquisa podem levar vários sprints para serem concluídas. Por isso, é necessário criar exceções a essa regra e permitir sprints mais flexíveis, nos quais histórias podem ser trabalhadas ao longo de múltiplos sprints e os resultados podem não estar prontos ao final de cada sprint.

Existem diversas práticas para prever o progresso, como burn-downs, burn-ups ou fluxos cumulativos. Embora comprovadamente úteis, elas não substituem a importância do empirismo. Em ambientes complexos, o que vai acontecer é desconhecido. Apenas o que já aconteceu pode ser usado para a tomada de decisões voltadas para o futuro.

Em projetos de pesquisa, haverá casos em que um período fixo é definido para explorar determinado assunto: para uma dada hipótese, o time pode criar uma história e deve concordar sobre o tempo/esforço máximo que será empregado nela. Por exemplo, o time pode concordar que 2 ou 3 sprints podem ser usados para entender melhor um determinado assunto e que, ao final desse período, o time avaliará o conhecimento obtido e decidirá se é necessário e válido continuar a pesquisa. Esse processo é feito durante a Sprint Planning.

Ao final do Sprint, algum tipo de Research Documentation deve ser entregue como forma de perpetuar o conhecimento e servir de base para a escrita de artigos ou para revisitar informações.

1.2 Sprint Planning

1.2.1 Descrição

A Sprint Planning inicia o Sprint, definindo o trabalho a ser realizado durante ele. O plano resultante é criado de forma colaborativa por todo o Scrum Team.

O Owner garante que os participantes estejam preparados para discutir os itens mais importantes do Research Backlog e como eles se relacionam com o Research Goal. O Scrum Team também pode convidar outras pessoas para participar da Sprint Planning e fornecer orientações.

1.2.2 Na Prática

A Sprint Planning aborda os seguintes tópicos:

1.2.2.1 Tópico Um: Por que este Sprint é valioso?

O Owner propõe como a pesquisa pode aumentar seu valor e utilidade no Sprint atual. Todo o Scrum Team então colabora para definir um Sprint Goal que comunique por que o Sprint é valioso para os stakeholders. O Sprint Goal deve ser finalizado antes do término da Sprint Planning.

1.2.2.2 Tópico Dois: O que pode ser feito neste Sprint?

Por meio de discussão com o Owner, os Researchers selecionam itens do Research Backlog para incluir no Sprint atual. O Scrum Team pode refinar esses itens durante esse processo, o que aumenta o entendimento e a confiança.

Selecionar o quanto pode ser concluído em um Sprint pode ser desafiador. No entanto, quanto mais os Researchers souberem sobre seu desempenho passado, sua capacidade futura e sua Definition of Done, mais confiantes eles estarão em suas previsões de Sprint.

1.2.2.3 Tópico Três: Como o trabalho escolhido será realizado?

Para cada item selecionado do Research Backlog, os Researchers planejam o trabalho necessário para criar um Increment que atenda à Definition of Done. Isso geralmente é feito decompondo os itens do Research Backlog em itens de trabalho menores, de um dia ou menos. Como isso é feito fica a critério exclusivo dos Researchers. Ninguém mais determina como eles devem transformar itens do Research Backlog em Increments de valor.

O Sprint Goal, os itens do Research Backlog selecionados para o Sprint, além do plano para entregá-los, são chamados, em conjunto, de Sprint Backlog.

A Sprint Planning tem um timebox máximo de oito horas para um Sprint de um mês. Para Sprints mais curtos, o evento costuma ser mais curto. Geralmente, recomenda-se manter as Sprint Plannings com menos de 2 horas.

1.3 Daily Scrum

1.3.1 Descrição

O propósito da Daily Scrum é inspecionar o progresso em direção ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planejado a seguir.

1.3.2 Na Prática

A Daily Scrum é um evento de 15 minutos para os Researchers do Scrum Team. Os Researchers podem escolher a estrutura e as técnicas que quiserem, desde que a Daily Scrum foque no progresso em direção ao Sprint Goal e produza um plano acionável para o próximo dia de trabalho. Isso cria foco e melhora a autogestão.

As Daily Scrums melhoram a comunicação, identificam impedimentos, promovem tomadas de decisão rápidas e, consequentemente, eliminam a necessidade de outras reuniões.

A Daily Scrum não é o único momento em que os Researchers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre como adaptar ou replanejar o restante do trabalho do Sprint.

Em um ambiente de pesquisa, dependendo do tamanho do Team, pode haver múltiplas Linhas de Pesquisa sendo exploradas ao mesmo tempo. Por isso, recomenda-se ter reuniões específicas entre os envolvidos em cada Linha de Pesquisa para discutir os detalhes da pesquisa.

1.4 Sprint Review

1.4.1 Descrição

O propósito da Sprint Review é inspecionar o resultado do Sprint e determinar adaptações futuras. O Scrum Team apresenta os resultados do seu trabalho aos principais stakeholders, e o progresso em direção ao Research Goal é discutido.

1.4.2 Na Prática

Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado no Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram para definir os próximos passos. O Research Backlog também pode ser ajustado para atender a novas oportunidades. A Sprint Review é uma sessão de trabalho, e o Scrum Team deve evitar limitá-la a uma apresentação.

A Sprint Review é o penúltimo evento do Sprint e tem um timebox máximo de quatro horas para um Sprint de um mês. Para Sprints mais curtos, o evento costuma ser mais curto, por exemplo, uma sessão de uma hora.

1.5 Sprint Retrospective

1.5.1 Descrição

O propósito da Sprint Retrospective é planejar formas de aumentar a qualidade e a efetividade.

1.5.2 Na Prática

O Scrum Team inspeciona como foi o último Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definition of Done. Os elementos inspecionados costumam variar conforme o domínio do trabalho. Premissas que levaram o time por um caminho equivocado são identificadas e suas origens são exploradas. O Scrum Team discute o que funcionou bem durante o Sprint, quais problemas surgiram e como esses problemas foram (ou não) resolvidos.

O Scrum Team identifica as mudanças mais úteis para melhorar sua efetividade. As melhorias de maior impacto são tratadas o quanto antes. Elas podem até ser adicionadas ao Sprint Backlog do próximo Sprint.

A Sprint Retrospective encerra o Sprint. Ela tem um timebox máximo de três horas para um Sprint de um mês. Para Sprints mais curtos, o evento costuma ser mais curto, por exemplo, sessões de 30 minutos a uma hora.

2 Artefatos do Scrum

Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência de informações-chave. Assim, todos que os inspecionam têm a mesma base para adaptação.

Cada artefato contém um compromisso que garante que ele forneça informações que aumentem a transparência e o foco, em relação aos quais o progresso pode ser medido:

• Para o Research Backlog, é o Research Goal.
• Para o Sprint Backlog, é o Sprint Goal.
• Para o Increment, é a Definition of Done.

Esses compromissos existem para reforçar o empirismo e os valores do Scrum para o Scrum Team e seus stakeholders.

2.1 Research Backlog

O Research Backlog é uma lista emergente e ordenada daquilo que se pretende pesquisar. É a única fonte de trabalho assumido pelo Scrum Team.

Os itens do Research Backlog geralmente são planejados para serem concluídos dentro de um sprint. No entanto, no ambiente de pesquisa, muitos itens podem não caber em um sprint e também não podem ser divididos; nesses casos, eles podem levar mais de um sprint para serem concluídos, desde que o Team concorde com um prazo composto por um número máximo de sprints que poderiam ser investidos para concluir o trabalho e reunir o máximo de informação possível durante esse tempo.

O refinamento do Research Backlog é o ato de decompor e detalhar ainda mais os itens do Research Backlog em itens menores e mais precisos. Essa é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os atributos costumam variar conforme o domínio do trabalho.

Os Researchers que realizarão o trabalho são responsáveis pelo dimensionamento.

2.1.1 Compromisso: Research Goal

O Research Goal descreve um estado futuro da pesquisa, que pode servir como alvo para o planejamento do Scrum Team. O Research Goal está contido no Research Backlog. O restante do Research Backlog emerge para definir “o quê” irá cumprir o Research Goal.

O Research Goal é o objetivo de longo prazo do Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.

2.2 Research Documentation

A documentação da pesquisa é uma parte extremamente importante do processo de pesquisa, pois serve como uma possível fonte de informação para pesquisas futuras e também para a escrita de artigos científicos.

Não existe uma forma correta de fazer a documentação, e o Team deve chegar a um acordo sobre a melhor forma de proceder. No entanto, duas abordagens são sugeridas aqui:

1. Um documento escrito para cada sprint, descrevendo o trabalho e o progresso realizados naquele sprint em particular;
2. Um documento que não é organizado por sprints, mas por Linhas de Pesquisa. Ao final de cada sprint, uma nova seção é adicionada à seção apropriada, descrevendo o que foi feito no sprint que terminou.

2.3 Sprint Backlog

O Sprint Backlog é composto pelo Sprint Goal (o porquê), pelo conjunto de itens do Research Backlog selecionados para o Sprint (o quê) e por um plano acionável para entregar o Increment (o como).

O Sprint Backlog é um plano feito pelos e para os Researchers. É um retrato altamente visível e em tempo real do trabalho que os Researchers planejam realizar durante o Sprint para alcançar o Sprint Goal. Consequentemente, o Sprint Backlog é atualizado ao longo do Sprint à medida que mais se aprende. Ele deve ter detalhes suficientes para que possam inspecionar seu progresso na Daily Scrum.

2.3.1 Compromisso: Sprint Goal

O Sprint Goal é o único objetivo do Sprint. Embora o Sprint Goal seja um compromisso dos Researchers, ele oferece flexibilidade quanto ao trabalho exato necessário para alcançá-lo. O Sprint Goal também cria coerência e foco, incentivando o Scrum Team a trabalhar em conjunto, em vez de em iniciativas separadas.

O Sprint Goal é criado durante o evento de Sprint Planning e, em seguida, adicionado ao Sprint Backlog. Enquanto trabalham durante o Sprint, os Researchers mantêm o Sprint Goal em mente. Se o trabalho acabar sendo diferente do esperado, eles colaboram com o Owner para negociar o escopo do Sprint Backlog dentro do Sprint, sem afetar o Sprint Goal.

2.4 Increment

Um Increment é um passo concreto em direção ao Research Goal. Cada Increment é adicionado a todos os Increments anteriores e cuidadosamente verificado, garantindo que todos os Increments funcionem juntos. Para agregar valor, o Increment deve ser utilizável.

Múltiplos Increments podem ser criados dentro de um Sprint. A soma dos Increments é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um Increment pode ser entregue aos stakeholders antes do término do Sprint. A Sprint Review nunca deve ser considerada um portão para a liberação de valor.

O trabalho não pode ser considerado parte de um Increment a menos que atenda à Definition of Done.

2.4.1 Compromisso: Definition of Done

A Definition of Done é uma descrição formal do estado do Increment quando ele atende aos critérios de pesquisa definidos pelo time, ou seja, quando o Team alcança algum resultado na Linha de Pesquisa, quando o tempo definido para ser empregado naquela pesquisa é atingido, ou quando o Team decide que os resultados são satisfatórios.

No momento em que um item do Research Backlog atende à Definition of Done, um Increment nasce.

A Definition of Done cria transparência ao proporcionar a todos um entendimento compartilhado sobre qual trabalho foi concluído como parte do Increment. Se um item do Research Backlog não atender à Definition of Done, ele não pode ser lançado nem mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Research Backlog para consideração futura.

Os Researchers são obrigados a seguir a Definition of Done.