27 de Dez de 2023 5 min read Agile

Shape Up – Uma alternativa ao Scrum?

Uma análise, primeiras impressões e experiências do modelo de desenvolvimento de produtos da Basecamp.

Introdução

Recentemente adotamos na squad de um dos nossos clientes o modelo de desenvolvimento conhecido como "Shape Up", divulgado em 2019 no livro Shape Up – Stop Running in Circles and Ship Work that Matters (Pare de correr em círculos e entregue trabalho que importa), de autoria de Ryan Singer. O objetivo é construir as coisas certas por meio de experimentação e aprendizado rápidos, em vez de um grande planejamento inicial. Basicamente, o foco do Shape Up é em lidar com incertezas do que precisa ser construído e apostar nas melhores soluções para os problemas definidos. Diante disso, aqui vai uma breve explicação de como funciona o Shape Up e suas premissas.

Etapas do Shape Up: Shaping, Betting e Building.

O Shape Up possui 3 etapas em seu ciclo de desenvolvimento, que são:

Shaping: Essa primeira fase não é de execução, e sim de levantar o que será construído. Nessa fase, participam pessoas com mais experiência e de diferentes áreas(desenvolvedores, designers, time de negócio) e é definido O QUE será feito, mas não totalmente COMO, levando em consideração os limites, riscos e benefícios que o projeto trará. Esse levantamento deve ser concreto o suficiente para que as equipes saibam o que fazer, mas abstrato o suficiente para que o time tenha espaço para decidir os detalhes da solução.

A fase de Shaping resulta em um documento simplificado chamado Pitch e ele aborda os seguintes elementos:

Resultado (outcome) — O objetivo e indicador que essa ideia impacta.
Oportunidade(s) — A(s) oportunidade(s) que essa ideia endereça.
Apetite — Quanto tempo queremos gastar e como isso limita a solução.
Solução — Os elementos essenciais que desenvolvemos, apresentados de forma que seja fácil para as pessoas entenderem imediatamente.
Riscos — Detalhes sobre a solução que valem a pena ser destacados para evitar problemas.
Exclusões — Qualquer coisa especificamente excluída do conceito: funcionalidades ou casos de uso que intencionalmente não estamos abordando para atender ao apetite ou tornar o problema mais gerenciável.

Betting: É nessa fase que a funcionalidade ou projeto será apresentada aos gestores e outros tomadores de decisão. Junto com o time que fez as definições na fase anterior, eles tomarão decisões do projeto que será executado. Aqui são realizadas apostas, não há uma lista gigante de ideias no backlog para revisar. Não há tempo gasto preparando um acúmulo de ideias antigas. Existem apenas algumas opções bem elaboradas e com risco reduzido para revisar.

Building: Após a priorização dos pitches, é nessa fase que o time entra em ação na construção da solução. E essa é a fase que para mim, mais se diferencia se comparado com o Scrum por exemplo. Vou explicar o porquê.

Cerimônias.

O Shape-up não segue as premissas do Scrum; não existem reuniões diárias, nem planning, review e muito menos retrospectiva. Ao invés de termos o Refinamento, temos a Imersão, que são de 2 á 4 encontros imersivos na qual abordamos o entendimento geral das ideias, esclarecimento de dúvidas e separação do que deve ser feito primeiro(nesse momento, ainda não pensamos em telas ou algo palpável).

Ciclos.

Outra diferença é o tempo de duração do projeto; 6 semanas, período suficiente para construir algo significativo do início ao fim e curto o suficiente para que todos possam sentir o prazo se aproximando, assim, a equipe consegue usar esse tempo com sabedoria, sem questionar a quantidade de horas gastas para cada atividade. Durante esse tempo, o time tem total liberdade para definir suas próprias tarefas, fazerem ajustes no escopo e decidirem como executar o trabalho.

Controle de Qualidade.

Nessa metodologia, a qualidade básica é de responsabilidade da equipe design-programador e o QA entra em cena apenas no final do ciclo para procurar casos extremos fora da funcionalidade principal. E esse é o meu ponto fraco, o que me incomodou nessa metodologia é o simbolismo da atuação do analista de qualidade. Aqui o QA não tem o papel ágil e nem sequer é mencionado em nenhuma das fases abordadas acima. Segundo o Basecamp, “pensamos no controle de qualidade como uma subida de nível, não como um portão ou ponto de verificação pelo qual todo o trabalho deve passar. Estamos muito melhor com o controle de qualidade do que sem ele. Mas não dependemos do controle de qualidade para fornecer recursos de qualidade que funcionem como deveriam”.

Porém, com esse comportamento, vamos de encontro com a teoria da psicologia do teste abordada no Syllabus:

“Um elemento da psicologia humana chamado ‘viés de confirmação’ pode dificultar a aceitação das informações que não concordam com as crenças atualmente mantidas. Por exemplo, como os desenvolvedores esperam que o código esteja correto, eles têm um viés de confirmação que dificulta a aceitação do código incorreto.”

Essa é uma premissa que não seguimos na squad da Endeavor. Aqui por exemplo, o QA participa da equipe de desenvolvimento em todas as etapas do ciclo, não só na entrega final. Além disso, aqui o QA é quem guia a homologação com o cliente.

Cooldown.

Segundo o Shape Up, essa é a definição completa do que seria o cooldown:

“Se realizássemos ciclos de seis semanas consecutivos, não haveria tempo para respirar e pensar no que vem a seguir. O final de um ciclo é o pior momento para se reunir e planejar porque todos estão muito ocupados finalizando projetos e tomando decisões de última hora para entregar no prazo.

Portanto, após cada ciclo de seis semanas, programamos duas semanas para o cool-down. Este é um período sem trabalho programado onde podemos respirar, reunir-nos conforme necessário e considerar o que fazer a seguir.

Durante o cooldown , os programadores e designers das equipes de projeto ficam livres para trabalhar no que quiserem. Depois de trabalhar duro para entregar seus projetos de seis semanas, eles gostam de ter um tempo sob seu controle. Eles o utilizam para corrigir bugs, explorar novas ideias ou experimentar novas possibilidades técnicas.”

Aqui é o respiro da equipe, temos liberdade de regular nosso trabalho da forma que preferirmos. Eu, particularmente, utilizo o tempo de cool-down para pensar na estruturação dos testes automatizados end-to-end e na atualização dos testes de API.

Conclusão

Do meu ponto de vista, foi desafiador trabalhar com essa metodologia, principalmente porque, quando falamos de um problema, quase de imediato já começamos a pensar na solução dele, o que vamos criar de telas e de regras (o que não é a proposta do Shape up). Porém, por outro lado, é incontestável a liberdade que temos ao trabalhar com essa metodologia, desde a concepção inicial até os detalhes da solução, do que realmente deve ser feito e da estruturação do trabalho.

O Shape Up não é um framework, e sim uma série de recomendações de como você pode trabalhar dessa forma, é possível torná-lo acessível no seu próprio contexto de trabalho. Nada é escrito em pedra, o Shape up gira em torno de experimentações e a equipe precisa entrar em consenso sobre o fluxo de trabalho a ser seguido.

Na minha opinião, foi de grande aprendizado entender o contexto do Shape Up e sair daquela visão tão rígida do Scrum(polêmica hihi).

E você, já conhecia o Shape up? Conta pra mim o que você achou :)