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.
