Compartilhe

Silos: visualizando e tratando as dependências do time

23/03/18 - 3 minutos de leitura

Recentemente, enquanto estávamos facilitando um EVDnC, um dos times estava com dificuldade para decidir quais tarefas deveriam ser feitas por quem e quais aquelas deveriam ser feitas em conjunto. Toda hora surgia algo como: “mas eu não sabia que você precisava disso”, “eu fiquei esperando o Back end fazer tal coisa e eles nem olharam para isso”, “Tenho algumas dependências contigo, mas ainda não falei”. Muita discussão e pouco alinhamento.

Era um time com as seguintes especialidades: User Experience (UX) e User Interface (UI), Back end, Front end e Quality Assurance (QA). O quadro Kanban não traduzia as dependências e a história não andava. Bolamos então um quadro diferente.

O Quadro de dependências

Utilizando uma folha de Flipchart, colocamos um círculo para cada especialidade no seu canto.

Em seguida, desenhamos linhas ligando cada especialidade.

Pegamos a história de usuário mais prioritária do Product Backlog, a que estava dando muita discussão e passamos o seguinte desafio: Pessoal, listem em post-its todas as tarefas técnicas que cada especialista precisa fazer para que a história cumpra nossa Definição de Pronto (Definition of Done). Cada especialidade tem a sua cor de post-it.

As tarefas que dependem do especialista e só do especialista ficam dentro do círculo. Todas as tarefas que dependem do trabalho em conjunto com outro especialista devem ficar sobre a linha. Qualquer tarefa que dependa de 3 ou mais especialistas deve ficar no centro do quadro.

A Figura abaixo apresenta o quadro preenchido.

O Quadro de dependências

O Quadro de dependências

A leitura que podemos fazer dela é:

  • UX/UI tem 2 tarefas e não dependem de ninguém;
  • Front end tem 6 tarefas, 2 dependem de UX/UI e 1 depende do Back end;
  • Back end também tem 6 tarefas, 1 depende do UX/UI;
  • QA tem 5 tarefas, 1 depende do Back end e 1 depende de todos os outros.

As movimentações

Quando a dependência for removida, a tarefa poderá ser movida para dentro do círculo do especialista.

Quando a tarefa for concluída, ela deve ser removida do quadro. A História de Usuário está pronta quando todo o quadro estiver vazio.

Tarefas podem surgir ao longo do desenvolvimento ou o time pode descobrir alguma dependência. Todavia cuidado para que isso não se torne uma bengala para o planejamento apressado e mal feito. Novas dependências sempre devem ser comunicadas e combinadas entre as partes.

Acordos

Alguns acordos são necessários

1 – Devemos procurar resolver primeiro as dependências maiores (centro do quadro), depois as dependências menores (retas) e por último as tarefas dos especialistas (dentro do círculo.

2 – Não posso atribuir uma tarefa a outra pessoa. Posso indicar a dependência, mas não escrevo post-its de cores que não são da minha especialidade.

3 – Combine bem o momento em que as dependências serão tratadas. Não espere a Daily Meeting para tal.

E se eu tiver mais especialistas no meu time?

Você pode criar outros formatos de quadro (pentágonos, hexágonos, etc.), mas tenha muito cuidado com tanta especialização no time. Lembre-se da Lei de Brook. A quantidade de interconexões de comunicação é uma explosão combinatória dada pela fórmula.

Fórmula da Lei de Brooks

Lei de Brooks

Trazendo para uma imagem

Exemplificando a Lei de Brooks

Exemplificando a Lei de Brooks

A cada nó de especialista que você acrescenta no time, você acrescenta um overhead de comunicação, aumenta o custo de coordenação, acrescenta complexidade de handoff de histórias e dificulta práticas ágeis importantes como limitação de WIP (Work In Progress, Trabalho em Andamento) e Swarming.

Quer conhecer outras técnicas de facilitação? Inscreva-se no nosso curso de Gestão de Conflitos ou Técnicas Ágeis de Facilitação.
Quer levar a facilitação para dentro da sua empresa? Conheça os modelos de Coaching da K21.

Compartilhe

Escrito por

Avelino Ferreira Gomes Filho

Trainer na K21


Avelino é formado e mestre em Ciência da Computação. Teve uma longa trajetória na T.I. começando como programador e chegando à gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis desde 2008. A partir de 2015 se dedicou a auxiliar outras empresas a adotar tais métodos. Atualmente é Agile Coach e Trainer na Knowledge 21.
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

    Receba mais conteúdos K21

    Deixe aqui o seu nome e email e iremos mante-lo atualizado sobre os conteúdos mais recentes.