Entregando no prazo com a Matriz de Dependência

Você tem aquele backlog imenso. O P.O. já fez a priorização. Mas na verdade, ele priorizou apenas as features. Quando você olha o kanban mais de perto, percebe que há trocentas stories a serem feitas dentro de cada feature. E aí? Qual você começa primeiro? É sobre isso que vamos falar hoje.

https://www.trace.com.br/sitenovo/wp-content/uploads/2018/08/productivity-780x448.png

Matriz de dependência

Umas das piores situações durante o desenvolvimento é você descobrir que aquela story que você acabou de desenvolver depende de uma outra que ainda não está pronta. É como se você tivesse construídoo décimo quarto andar de um prédio e só então descobrisse que não existe ainda o 13º.

A matriz de dependência ajuda você a ter essas informações de maneira rápida e visual. Dentre os seus benefícios esta o auxílio no elenco das stories para a sprint. Ao invés de simplesmente selecionar o que cabe na sprint, a matriz te apoia a selecionar as stories de maneira mais inteligente, evitando que o desenvolvimento fique travado por conta de bloqueios de dependências.

Outro ponto positivo é o auxílio aos testers sobre o que testar e em qual ordem. O fator "ordem" é interessante aos testers, uma vez que os insumos gerados para um teste podem ser reaproveitados nos testes seguintes.

Pensando em testes complexos e em evoluções grandes, este pode ser um fator que influenciará bastante no tempo de entrega final.

Mas na minha opinião, um dos maiores benefícios de se construir a matriz de dependência é a possibilidade de traçar o PERT/CPM. Trata-se da fusão de duas metologias de produção que ajudam a equipe na produção de previsões mais realistas sobre o trabalho e sua entrega, subdividindo o trabalho entre os desenvolvedores e identificando os caminhos críticos em suas versões otimistas, mais provável e pior caso. Sobre essa metodologia, quero separar uma postagem específica.

Como construir?

Não é uma tarefa difícil. Basicamente você precisa colocar as stories em coluna, como na imagem. Adicione um índice númerico e o replique na horizontal. Está pronta a matriz. Depois basta apenas preencher. O X marca as dependências impossíveis, já que a Story 1 não pode depender dela mesma. As letras D e O marcam aquilo que é Desejável e Obrigatório respectivamente. Desejável são aquelas stories que não causam bloqueio, mas que de alguma forma facilitam ou a entrega ou o teste. Obrigatórias são aquelas que causam bloqueio, ou no desenvolvimento ou no teste ou ainda em ambos. Minha dica é: não adicione muitas categorias. Isso pode dificultar a leitura e interpretação da matriz.
Você pode ter mais subdivisões (Evoluções -> Features -> Stories) e colocá-las neste board. E optar também por ponderar as suas dependências. Isso pode te ajudar a decidir quais desses elementos pode ser interessante desenvolver primeiro. Eu apenas diria que se as features não tem dependência, não faria sentidos colocá-las no board.

Como ler?

Uma vez que as dependências tenham sido anotadas, você ainda pode quantificar o seu número por Story.

Em geral, as stories devem ser desenvolvidas na ordem de menos para mais dependências. No board de exemplo, as stories 1 e 2 não possuem dependência alguma. Elas poderiam ser feitas primeiro. Em seguida temos as stories 3 e 4. Ambas possuem apenas uma dependência. Isso se considerarmos apenas uma leitura horizontal.

Considerando as colunas, percebemos que a Story 1 causa dependência na Story 3. Por sua vez, a Story 3 causa dependência na Story 4. Aqui a matriz já nos aponta um caminho de desenvolvimento:

Story 1 -> Story 3 -> Story 4

A Story 2 não gera dependência em nenhuma outra. Contudo, por algum motivo o time disse que seria desejável que ela fosse desenvolvida antes da Story 4. Assim um possível caminho seria:

Story 1 -> Story 3-> [Story 2] -> Story 4

Até aqui consideramos apenas uma equipe com um desenvolvedor apenas. Se tivéssemos, por exemplo, dois desenvolvedores na equipe, um caminho natural seria:

Dev1: Story 1 -> Story 3 -> Story 4
Dev2: Story 2->

Poderíamos ter três desenvolvedores também. Ou quem sabe até quatro. Talvez cinco... Neste ponto é que o CPM/PERT e as estimativas fazem a diferença. No caso demonstrado não podemos dividir o trabalho, com segurança, uma vez que não sabemos o nível de complexidade de cada Story. Pode ser que  Story 2 demande muito tempo para ficar pronta. Então ela pode ser feita por fora. Ou o seu custo seja tão irrisório, que compense ser feita primeiro e assim temos a possibilidade de fazer um pair-programming nas stories mais complexas. Ou ainda, as dependências podem ser paralelizadas com o uso de padrões de projeto e interfaces, que permitem o desenvolvimento sem a implementação pronta.

Quando fazer?

Como você pode perceber, estamos na etapa de planejamento das demandas e suas entregas. Ter as stories definidas é condição inegociável para que esse trabalho dê certo. Obviamente novas stories podem surgir durante o desenrolar do ciclo. Isso é normal. Neste caso, o board deve ser atualizado com as novas stories, estimativas e dependências. Do contrário, o esforço inicial pode se perder e o caos ser reinstaurado. Por isso é importante ter alguém responsável por essas atualizações - idealmente o Scrum Master do time.

Como é um processo muito trabalhoso, meu conselho é que você o utilize apenas em projetos grandes. O que define um projeto grande? Isso é muito pessoal e vai do grau de maturidade e/ou expectativa de cada time. Na minha opinião, aquele projeto em que nem todos tem clareza ou sabem de cor as dependências de cada story já tem tamanho suficiente para que uma  matriz de dependência seja indicavel. Se você prevê a alternância de profissionais durante o desenvolvimento (alguém vai sair de férias, por exemplo), a matriz pode servir de grande auxílio.

Minha história

Conheci essas técnicas quando fomos desafiados a desenvolver uma demanda complicadíssima. O prazo que nos foi dado era curto demais e para que o Business Owner pudesse negociar os prazos com o cliente, precisávamos dar insumos e responder às perguntas mais difíceis de serem respondidas: por quê e quando. Uma vez definido o prazo, não poderia haver alteração sob a pena de multa. O nível de confiança do time estava lá embaixo. A demanda em si estava cheia de nebulosidades. Não dava pra responder aos questionamentos do B.O. Mas nós precisávamos.

Foi empreendido um grande esforço para decidir a arquitetura a ser adotada. Assim definimos o como. Depois detalhamos um pouco mais e quebramos as features e stories. Só então estimamos as stories. Foi quando entramos com a matriz de dependência e as coisas ficaram um pouco mais claras. Com o CPM/PERT vimos que era possível entregar a demanda. Obviamente o caminho não foi apenas flores, mas estamos na última semana desta demanda. E mesmo com todos os percalços no caminho, estamos dentro do prazo previsto no início da demanda. Só não com alguma folga, porque esquecemos dos feriados de novembro. #culpaMinha.

Escrevo isso apenas pra dizer pra vocês: vale a pena investir tempo em planejamento e em todas aquelas reuniões [que você pode chamar de chatas] que o time Scrum faz. Sem essas ferramentas, seria impossível vencer este desafio. E vencemos!

Obrigado pela atenção e até a próxima!

*Só um agradecimento ao Vitor Molimoto, que foi quem me apresentou essas metodologias e apoiou nosso time nessa caminhada. Valeu mano!