Requisitos em equipes ágeis: Falando sobre complexidade e incerteza

Se a equipe na qual você trabalha lida com demandas (ex: histórias de usuário, bugs, etc.) que demonstram uma alta variabilidade no lead time ou, em outras palavras, o fluxo de desenvolvimento do time lida com demandas que são entregues rápido demais e outras que levam muito tempo para serem finalizadas, provavelmente você está lidando com um ambiente onde a previsibilidade esteja em baixa (para mais dicas de como analisar o lead time, leia “Looking at Lead Time in a different way” e “Why we love metrics? Learning with Lead time”).

Neste blog post, compartilharei uma técnica que estamos utilizado para auxiliar nossos times e clientes a compreenderem a relação entre complexidade e incerteza quando há a necessidade de se avaliar requisitos no contexto de desenvolvimento de software. Geralmente esse momento acontece antes de uma cerimônia de planejamento (Sprint Planning no Scrum ou Replenishment no método Kanban) ou até mesmo em uma discussão de refinamento das demandas que entrarão no fluxo de desenvolvimento.

Ao longo da nossa experiência com desenvolvimento de software, temos percebido que as equipes não têm o hábito de avaliar um item que será construído antes da entrega do mesmo já estar comprometida com os stakeholders de um projeto ou produto. O grande problema é que tais demandas indefinidas farão com que o processo se torne ineficiente. Os stakeholders não compreenderão a real capacidade de entrega do time e este passará tempo demais tentando estimar o esforço de algo que, por natureza, é imprevisível (leia-se, software).

A técnica que apresentarei a seguir é um método que temos aplicado para criar itens de trabalho que demandam um esforço de trabalho parecido. Tenho proposto esse tipo de abordagem como alternativa para cerimônias como planning poker, com o intuito de reduzir o tempo necessário em se estimar o desenvolvimento de funcionalidades de um software. Por fim, gostaria de agradecer ao Diego Poblete (@dipoblete) por ter me apresentado a primeira versão da matriz.

Matriz de complexidade e incerteza

A matriz de complexidade está estruturada em dois eixos que combinam as análises de complexidade e incerteza de cada demanda que será trabalhada.

Matriz de complexidade e incerteza

O eixo X da matriz representa o quanto de incerteza técnica e de negócio a demanda que está sendo avaliada possui. Já o eixo Y, analisa a complexidade e o esforço para se entregar a demanda.

Na categoria “baixa” do eixo X, estão as demandas bem definidas (os critérios de aceite estão claros) e sem incertezas, técnicas ou de negócios. No eixo Y, estão as demandas que exigem pouco esforço e têm baixa complexidade na sua implementação (exemplo: a equipe está acostumada a trabalhar com demandas parecidas com a que está sendo analisada).

Já na categoria “média” do eixo X, estão elencadas as demanda com poucas incertezas sobre sua implementação ou definição de negócio, e estas incertezas a equipe sabe ou já resolveu antes (exemplo: demandas com vários casos de exceção). No eixo Y, tal categoria representa que as demandas exigirão um esforço considerável para serem completadas, mas que a equipe possui o domínio para desenvolvê-las (exemplo: funcionalidades que exijam integração com sistemas satélites).

Por fim, no eixo X da categoria “alta”, estão as demandas que possuem incertezas relevantes sobre a implementação ou sobre o negócio, o que traz insegurança para os membros da equipe por se tratar de algo onde há um baixo entendimento de contexto (exemplo: nova funcionalidade no produto ou alterações em um software legado). No eixo Y, a atribuição grande representa que as demandas estão muito complexas ou que precisarão de muito esforço para serem concluídas (mais de duas semanas).

As demandas classificadas nos quadrantes 5, 6, 7, 8 e 9, devem ser discutidas e dificilmente estarão prontas para entrarem no fluxo de desenvolvimento da equipe. O motivo? Carregam um alto grau de incerteza que naturalmente acarretará retrabalho, atraso na entrega e outros efeitos não desejados quando estamos em busca de entregas constantes e previsíveis.

Sabendo que o objetivo de toda equipe é buscar um ritmo de entrega sustentável, gostaria de compartilhar algumas dicas úteis para que sua equipe não traga para o fluxo de desenvolvimento demandas com alto índice de incerteza e/ou complexidade:

  1. Faça um bom trabalho de refinamento e discuta o quão pronta a demanda está para entrar no fluxo de desenvolvimento.
  2. Caso a demanda carregue muita incerteza, crie estratégias de investigação para que a equipe ganhe conhecimento técnico ou de negócio. Em determinados momentos, é melhor fazer com que as pessoas tenham tempo para avaliarem e estudarem, ao invés de incluir no fluxo de trabalho uma demanda para ser desenvolvida a qualquer custo.

  3. Caso uma demanda tenha um excesso de incerteza de negócio, busque especialistas para sanarem as dúvidas. Mesmo que por vezes não conheçam o linguajar técnico, tais pessoas são extremamente úteis para descreverem o mundo no qual a solução será útil e tal intercâmbio é saudável para que a equipe evolua.

  4. Exercite a quebra de grandes demandas em pequenas, mesmo que você tenha que lidar com questionamentos de que pequenas entregas não geram valor ao negócio. Quando quebramos a incerteza, estamos reduzindo risco, o que, para mim, representa valor, uma vez que eliminamos desperdício, provamos conceitos abstratos mais rápido e validamos hipóteses complexas fracionadamente.

As demandas classificadas nos quadrantes 1, 2, 3 e 4 geralmente estarão prontas para entrarem no fluxo de desenvolvimento, pois terão tamanhos saudáveis de esforço/complexidade e estarão com baixa ou nenhuma incerteza.

Considerações finais

Estimar dentro do contexto de desenvolvimento de software por vezes é moroso (leva muito tempo) e requer muita energia.

Se você é um Scrum Master, Agile Coach ou trabalha dentro de uma equipe de desenvolvimento de software, em algum momento você terá que planejar o trabalho que passará pelo fluxo de desenvolvimento. Portanto, utilizar técnicas que lhe ajudem a realizar o planejamento o mais rápido possível será sempre bem vindo.

Ao utilizar a matriz, você fará com que as pessoas analisem, em diferentes aspectos, o que precisará ser feito. Além disso, o uso da ferramenta vem otimizado o tempo que temos despendido em reuniões, aumentando a qualidade das discussões entre as pessoas, dado que a comunicação tem fluído melhor entre as pessoas de negócios e da área técnica.

Aplicar a técnica apresentada neste blog post ajudará você a diminuir o lead time das demandas e, como disse anteriormente, será uma ótima forma para substituir outras técnicas de estimativa.

E então, o que achou da matriz? Gostou do formato? Deixe seu comentário abaixo! 🙂


Métricas para Projetos Agile em 7 e-mails

Comments are closed.