Como cumprir prazos de entrega – Parte 3

ÉPICOS E HISTÓRIAS

No Kanban trabalhamos com Épicos e Histórias. Geralmente é criado 1 épico para cada grande demanda que chega ao time. Ao começar a atuar em um novo épico, o time se reuni para analisá-lo e quebrá-lo em histórias (etapas menores).

Como boa prática sempre procura-se quebrar o épico em histórias com aproximadamente o mesmo tamanho (o menor possível). Isto é fundamental para conseguir extrair indicadores gerenciais mais assertivos. Entrarei no detalhe um pouco mais pra frente.

Traduzindo isto para a realidade em que estávamos trabalhando, o Épico corresponde ao projeto e as Histórias correspondem às etapas mapeadas no fluxo de Implantação.

No nosso caso os tamanhos de algumas histórias destoaram das demais, mas isso não é problema, pois como o fluxo é sempre o mesmo teremos um padrão que será seguido em todos os épicos.

Identificamos no nosso fluxo a existência de algumas histórias que serão executadas 1 única vez, enquanto outras podem ser executadas repetidas vezes (uma para cada componente envolvido).

Não entendeu? Vamos considerar que o time de Implantação recebeu um projeto que possua a seguinte topologia.

imagem 1

 

Topologia de uma implantação simples

 

No fluxo de Implantação verificamos a existência de histórias que estão relacionadas ao épico como um todo, vinculadas ao planejamento e/ou entendimento do projeto.  Chamamos o conjunto destas atividades de ‘Planejamento Inicial’. Vejam as histórias que mapeamos nesta fase.

imagem 2

Histórias previstas no Planejamento Inicial

As demais histórias do fluxo de Implantação irão se repetir para cada componente do projeto, ou seja, todas as histórias serão avaliadas para o ‘Server A’, ‘Server B’ e ‘Server C’. De repente não será necessário aplicar todas as histórias em cada componente, mas é obrigatório analisar sua necessidade.  Veja as histórias envolvidas nesta etapa.

imagem 3

Histórias do Componente

Com esta definição é possível começar a utilizar o board do Kanban.

 

CRIANDO O BOARD

O Kanban pode ser aplicado através da simples utilização de um quadro e vários post-its, mas particularmente prefiro o uso de ferramentas. A ferramenta permite extrair indicadores importantes para gestão do time.

Caso você não tenha nenhuma ferramenta em sua empresa indico avaliar o Trello ou o LeanKit. Ambas são muito simples de utilizar e já entregam relatórios que lhe permitem realizar a gestão do processo. O Trello possui uma versão gratuita que pode ser uma boa opção para quem está conhecendo o processo.

Sugiro que inicie com um board simples, sem muitos detalhes no início, pois a mudança de cultura por si só já será um grande desafio. A medida que o time vai se adaptando com o processo você poderá amadurecer seu board, caso sinta necessidade.

No exemplo que apresento na figura 11 lhes mostro a visão mais básica de um board do Kanban. Ele é composto pelas seguintes colunas:

  • To Do: Backlog de histórias já liberadas para trabalho;
  • WIP: Histórias que o time está trabalhando neste momento;
  • Waiting: Histórias que estão presas com equipes externas (liberação de ACL por exemplo);
  • Review: A história que está nesta coluna deverá ser revisada por um analista, não podendo ser o mesmo que a executou na coluna WIP. Apesar de parecer retrabalho é uma atividade relativamente rápida e mitiga muito o risco de falhas no projeto;
  • Done: Histórias já concluídas.

imagem 4

Board criado no Trello

Considero está uma visão básica, mas que lhe permite garantir uma boa condução da implantação. Agora é só colocar para rodar o processo.

 

COLOCANDO PARA RODAR

As histórias não são inclusas de 1 única vez no backlog do time (coluna TO DO). Elas são inclusas a medida que suas dependências são encerradas.

Muitas vezes queremos adiantar o trabalho e desrespeitamos as dependências. Este comportamento pode gerar retrabalho, pois 1 alteração que ocorra nas histórias anteriores que estavam vivas significa ter que rever todas as atividades que foram ‘adiantadas’. Segure seu impulso e não faça isto.

Como estamos indicando alocar mais de 1 analista para atuar em cada projeto, corremos o risco de todas as atividades estarem ‘presas’, seja aguardando atividades de times terceiros ou liberações das dependências. Você consegue evitar esta situação trabalhando com mais de 1 épico de cada vez.

Ambos os épicos estarão quebrados em histórias no board da equipe. O segredo está em não amarrar o analista a histórias de apenas um determinado épico, pois neste caso voltaremos ao cenário inicial. Os analistas da equipe devem atuar em qualquer história disponível no momento, indiferente de qual épico seja.

A quantidade de épicos concorrentes deverá ser avaliada pontualmente, pois irá depender muito do seu fluxo de implantação e do tamanho do seu time.

 

SISTEMA PUXADO

Ao implantar o Kanban o time irá registrar todas as histórias que estão executando no board da equipe. Neste momento existe uma forte tendência de nos depararmos com o cenário apresentado na figura 12, onde o mesmo analista aparece atuando em diversas atividades ao mesmo tempo.

Este comportamento é conhecido como sistema empurrado, isto é, o analista já está atuando em uma história, enquanto vão empurrando outras atividades para ele realizar.

Muitos gestores acreditam que desta forma o time está sendo produtivo, mas não se engane. Foi provado que com esta forma de trabalho a produtividade diminui e o risco de ficar ‘rebarbas’ é maior.

A solução apresentada pelo Kanban é o conceito de sistema puxado.

imagem 6

Sistema Puxado

Neste cenário o analista trabalha em 1 história por vez, sempre focando na coluna da direita para a coluna da esquerda, ou seja, ele irá puxá-las. Trabalhar em 1 história por vez garante maior velocidade e qualidade na entrega. Para detalhes deste assunto indico aprofundar seus estudos nos livros indicados no tópico ‘Métodos Ágeis’.

A prioridade de atendimento deve ser realizada sempre da história mais antiga (coluna da direita) para a história mais nova (coluna da esquerda). Portanto, no board de exemplo apresentado na figura 13, as histórias paradas nas colunas ‘Review’ ou ‘WIP’ devem ser tratadas antes de puxar novas histórias da coluna ‘DO TO’.

Você só terá o Kanban funcionando corretamente quando entender e praticar este conceito.

 

GESTÃO DO DAILY

Para o bom funcionamento do Kanban é fundamental a existência do Daily. O Daily nada mais é do que um acompanhamento rápido realizado no board diariamente para identificar se o fluxo está sendo seguido corretamente.

Neste processo é muito importante a participação de todo o time presencialmente, pois quaisquer dúvidas que venham a surgir devem ser esclarecidas na hora.

Não confunda o daily com reunião de trabalho das atividades. O objetivo não é entrar no detalhe de cada história viva e sim verificar se o processo está ocorrendo conforme previsto. Veja a seguir algumas falhas que você pode identificar no daily:

  • Existem analistas trabalhando em mais de 1 histórias ao mesmo tempo;
  • Estão sendo puxadas novas histórias enquanto existem histórias vivas sem atuação;
  • Histórias estão sendo priorizadas fora da sequência indicada na coluna ‘To Do’;
  • O WIP está muito ‘gordo’;

Estes são apenas alguns exemplos, mas você com certeza se deparará com outras situações.

A medida que o time for ganhando maturidade no processo, o daily tende a ser realizado cada vez mais rápido. Ele é especialmente importante nos primeiros meses de vida do processo, mas você nunca poderá deixar de realizá-lo.

 

ESTRUTURAR EQUIPE EM CÉLULAS

Caso você esteja trabalhando com um time de implantação grande, é provável que você conseguirá ter maior vazão no fluxo proposto, certo? Correto!

Mas na prática nos deparamos com alguns problemas gerados neste cenário, como por exemplo:

  • Gestão do daily complexo. Onera tempo e dificulta alocação de recursos.
  • O board possuirá muitas histórias e irá dificultar o entendimento por parte dos stakeholders envolvidos;
  • Times muito grandes possuem maior reincidência de atritos de relacionamentos na condução do processo;

Visando evitar este tipo de situação sugiro que você crie células reduzidas com no mínimo 2 e no máximo 4 analistas (figura 14). Esta estratégia lhe ajudará na gestão do processo e influenciará na performance do time.

Equipe distribuída em células de 2 a 4 analistas

 

Apenas tome cuidado para que você não gere grupos isolados, as famosas ‘panelinhas’.

Lembre-se que o objetivo deste estudo é justamente desvincular o projeto do analista, sendo assim, nada nos impede de promover a movimentação de analistas entre as células. Isto lhe permite incrementar as células que necessitem agilizar determinadas entregas, além de ajudar na integração entre todos os analistas da equipe.

É possível movimentar analistas entre as células

 

Quando seu time estiver maduro nesta estrutura você realmente estará atuando com a gestão distribuída e o risco de impactar datas devido à ausência de analistas estará mitigada. Mas o mais legal de todo o processo está por vir. A análise dos números.

 

Rodrigo Muniz

Graduado em Sistemas de Informação, com MBA em Gestão Empresarial pela FGV, Rodrigo Muniz trabalha na área da tecnologia da informação desde 1997, atuando em empresas de serviços com foco em administração de infraestrutura e outsourcing de datacenter.