Introdução ao Shape-up

Se você trabalha na área de engenharia de software, e se interessa por gestão de projetos, com certeza já deve ter ouvido falar na metodologia Shape-up ou no produto desenvolvido pelos seus criadores, o Basecamp. Produto que é gerenciado utilizando o Shape-up.

Nesse artigo vou apresentar os principais conceitos dessa metodologia, suas vantagens, pontos de atenção e como ela funciona no dia a dia de um time de engenharia de software.

Então para começar, vamos entender quais são as fases desse processo.

Conhecendo as etapas do processo de shape-up

Shapping

Essa é a primeira fase do processo, que funciona como uma etapa de discovery e refinamento de uma nova feature que o time possa vir a trabalhar no futuro. Nessa fase, o foco é definir limites e entender qual a melhor forma de especificar a feature para que o time possa trabalhar, mas sem fazer uma definição completa, pois um dos princípios é que o time de desenvolvimento tenha liberdade para decidir como vai entregar o que foi solicitado.

A primeira coisa é esboçar como a nova solução ficará dentro do produto, e vale ressaltar que é um esboço mesmo, nada muito concreto, mas também nem tão abstrato. Eles recomendam utilizar um pincel/marcador de ponta grossa e fazer o desenho em um papel. A ideia de utilizar o pincel de ponta mais grossa, é para que não sejam feitos os mínimos detalhes, pois não é um mockup de alta fidelidade, é simplesmente um esboço.

Pitch

É o resultado da etapa de shapping, mas vou deixá-lo destacado no artigo. O documento de pitch, vai conter o esboço, e apenas uma definição macro de como essa feature deverá funcionar dentro do produto. Aqui é muito importante também, focar no que NÃO deve ser feito, para delimitar o tipo de solução que será implementada, sem deixar espaço para o time ficar inventando coisas novas pelo meio do caminho.

No pitch tem alguns pontos importantes que precisam estar bem claros:

• Problema que a nova feature irá solucionar;
• Apetite: que é o quanto o time tem de tempo e disposição de apostar nessa ideia. No shape-up o time trabalha com ciclos de 6 semanas, mais detalhes serão explicados mais à frente;
• Solução: como a nova feature vai solucionar o problema;
• O que fica de fora: aquilo que o time não deve “perder” tempo tentando implementar;
• Rabbit holes: quais armadilhas que o time pode cair.

Rabbit Holes

A fase de rabbit holes (buracos de coelho), é basicamente um mapeamento de problemas que o time pode encontrar durante o desenvolvimento e como podem lidar com isso. A ideia é que o time não cai em uma armadilha de algum imprevisto e não perca tempo tentando pensar como solucionar isso.

Betting Table

Como citei no começo do artigo, o shapping é uma etapa de discovery de algo que o time PODE vir a trabalhar. Mas como funciona isso?

Basicamente são criados vários pitches, e durante a betting table todos os pitches são apresentados e o time escolhe em quais demandas vão apostar esforços. Ou seja, o que eles acreditam que vai gerar mais valor para o produto, e que vale a pena trabalharem pelas próximas 6 semanas.

Os pitches reprovados são descartados, não existe backlog de demandas. O que ocorre é que se um pitch for muito bom, ele pode ser guardado e apresentado no futuro novamente.

Os pontos principais para a seleção dos pitches:

• Ganhos: problemas que são realmente relevantes e que vão trazer um bom retorno para o time.
• Apetite: a demanda realmente cabe no apetite de 6 semanas?
• Comprometimento: o time vai focar esforços durante 6 semanas nessa demanda, então é algo que acreditam que vale a pena investir tempo, focados, sem as interrupções de várias reuniões no dia a dia.
• A solução pensada é realmente atraente?
• O time certo está disponível? Para certas demandas, podem ter pessoas que estejam mais aptas para desenvolverem.

Circuit breaker

A intenção de ter o apetite limitado em 6 semanas é para garantir que o time vai trabalhar na demanda apenas por esse período, mas obviamente que atrasos ocorrem. Se for entendido que o time vai precisar de mais 2 ou 3 dias para finalizar a demanda, com correção de bugs ou para finalizar uma parte pequena, está tudo bem. 

Porém, se for entendido mesmo antes do final que o prazo de 6 semanas não é suficiente para finalizar a demanda, ela é descartada, pois não vale a pena investir mais tempo do que 6 semanas. Se for algo muito relevante para o produto, essa demanda pode voltar para a fase de shapping.

É para isso que o circuit breaker existe, para garantir que o time não vai ficar trabalhando por tempo indeterminado em uma demanda.

Building

Finalmente chegamos a fase de desenvolvimento da demanda. Os times são formados por 2 desenvolvedores e 1 designer – que também constrói a parte do front-end. 

O time trabalha em projetos e não atividades. Por isso, o próprio time é responsável por criar as tarefas que irão trabalhar, e como vão dividir esse trabalho para entregar a demanda no período de seis semanas.

Uma parte interessante dessa fase, é que toda demanda que está sendo desenvolvida fica em um ambiente “público” da empresa, possibilitando que qualquer pessoa da empresa possa acessar e realizar os testes.Isso vai de encontro com a parte dos pitches, já que o pitch pode ser produzido por pessoas de qualquer área, como suporte, financeiro ou qualquer outra.

Entendendo o ciclo de vida

Agora que já falamos de cada etapa do processo, vamos entender o ciclo de vida completo do shape-up.

• Shapping é a fase de refinamento das demandas, e dura até duas semanas;
• Building é a fase de desenvolvimento em si, e dura seis semanas;
• Cool down essa é uma fase de “descanso” para o time de desenvolvimento, ela ocorre junto com a fase de shapping, Aqui os desenvolvedores podem usar seu tempo para estudar, fazer melhorias no código, trabalhar em débitos técnicos e atuar em correções de bugs remanescentes da etapa de building.

Conclusão

A principal ideia por trás do shape-up é ter um processo de desenvolvimento mais dinâmico e adaptável à realidade do dia a dia do desenvolvimento de software. Quem já trabalhou nessa área, sabe que imprevistos acontecem e o segredo é saber se adaptar.

Esse é um dos motivos para trabalharem com ciclos de desenvolvimento com tempo limitado, pois se temos um intervalo de tempo definido, ajustes e cortes no escopo são uma alternativa para lidar com atrasos. Vale lembrar que reduzir o escopo é diferente de diminuir a qualidade da entrega para o cliente. 

Claro que para essa estrutura toda funcionar, esses times de 3 pessoas, contam com desenvolvedores mais experientes. E além disso, os times responsáveis pela fase de building, contam com o apoio de times de segurança e de plataforma, que trabalham para manter o que já existe na solução.

E se você se interessou pelo assunto, basta clicar aqui e acessar o livro do shape-up na íntegra. Até a próxima.