Page 50 - newDATAmagazine | 11>03>2022

veem as ineficiências do processo existente. os tais bugs ou erros, eu esteja disponível, no
Mas o primeiro passo para resolvermos um
problema é admitir e visualizar esse problema.
Limit Multitasking - WIP
Kanban, quando bem aplicado, vai para além
de ter colunas e post it – tem de ter regras. Uma
delas é a limitação de Work in Progress (WIP)
por coluna. Isto leva a que a equipa se deva
focar a fechar o que tem em curso em vez de
simplesmente começar mais uma tarefa, que
nunca é entregue. De forma resumida: Stop
Starting, Start Finishing.
Quantas vezes uma equipa de developers
simplesmente 'acaba' o seu trabalho, fazendo
toda a implementação necessária, e começa
uma nova? E as validações? E o processo de
deploy para produção? Está realmente Done
uma tarefa neste caso? E a quantidade de
vezes que existem bugs ou erros mais à frente
e uma tarefa volta para trás, mas, entretanto, já
temos algo novo nas mãos?
Figura 7 . Exemplo de um quadro sem WIP Limits, e
sem tarefas Done. Fonte: Planview
Uma das coisas que uma equipa deve
sempre fazer é garantir que não há uma coluna
cheia de trabalho pendente, com pouca
capacidade para o fazer, gerando bottlenecks, e
nunca chegando nada a realmente Done.
Soluções? Por exemplo, tornarmo-nos T
Shaped People – lá porque a minha área é dev,
não quer dizer que não consiga fazer pairing
com alguém de testes ou de operações, para
mais rapidamente entregarmos o trabalho em
curso. Isto também leva a que, se aparecerem
50 newDATAmagazine.com
momento, para os corrigir, em vez de já estar
com outra coisa em mãos e ter de fazer
multitasking.
Podemos ainda aplicar o conceito de Slack,
deixar espaço desocupado no nosso tempo –
não temos de estar todos sempre ocupados a
toda a hora, ao contrário do que por vezes nos
querem fazer passar. Ao termos tempo não
alocado, rapidamente conseguimos responder
a pedidos imprevistos (aquela dependência ou
dúvida rápida a outra equipa, produção que
parou subitamente, etc.) e, mais importante,
temos a possibilidade de nos juntar a alguém
da nossa equipa para fazer chegar a Done algo
que estava em curso.
Team Policies as a solid ground
Aliado aos WIP Limits por coluna, temos
também Policies (políticas, normas ou ações)
por coluna.
Estas Policies devem ser sempre o resultado
de conversas e compromissos como equipa.
Não é algo que o chefe disse, algo que o cliente
quer. Estes Stakeholders podem influenciar as
possíveis Policies, mas no final do dia, a
decisão é da equipa.
Estas Policies têm como objetivo tornar
claras as regras do jogo, tornar claro o
processo do trabalho em cada passo, e ainda
tornar claro o modo como a equipa, como um
todo, acordou em trabalhar.
Figura 8 . Exemplo de um quadro com Policies
explícitas por coluna. Fonte: digite