Fluxo Unificado: perspectiva de um desenvolvedor – Responsabilidades

Este é o 4º artigo da série sobre o Fluxo Unificado na perspectiva de um desenvolvedor. Então, se você ainda não conferiu os posts anteriores e quer ficar por dentro do assunto, seguem os links:

1º | Fluxo Unificado: Perspectiva de um Desenvolvedor – Motivações
2º | Fluxo Unificado: Perspectiva de um Desenvolvedor – Ações
3º | Fluxo Unificado: Perspectiva de um Desenvolvedor – Resultados

Nos conteúdos anteriores vimos como foi a transição para o modelo Fluxo Unificado e os resultados da mudança, mas o que mantém tudo funcionando? É que irei abordar neste post: as principais responsabilidades inerentes à equipe de desenvolvimento quando trabalhando desta forma.

Autogestão

O sistema é puxado, não empurrado: as pessoas desenvolvedoras não esperam que lhes digam o que fazer, mas sim, quando disponíveis, olham o quadro Kanban da direita para a esquerda verificando se podem ajudar na entrega das demandas em fila, impedidas ou em desenvolvimento.

E caso não haja nenhuma demanda nessas condições onde se possa ou precise dar auxílio, puxa-se a demanda do topo da coluna Ready for Dev.

Se não há o que puxar no downstream, então deve-se olhar se há itens para análise técnica no upstream. Aqui entra um detalhe importante: a análise técnica feita no upstream serve para alimentar um buffer de opções que chamamos de “Inventário de Opções”, onde estabelecemos que devemos sempre ter pelo menos cinco opções para podermos mandar para o downstream.

Se há menos de cinco itens nesse buffer, então a análise técnica vira prioridade para que o sistema não entre em starvation.

Porém, se passando por todo o quadro, não houver o que puxar, isso deve ser avisado à camada de gestão (em nosso caso, o analista de negócios). Aqui a pessoa pode dedicar um tempo a outras atividades como estudos, criação de conteúdo ou análise do processo de contratação, por exemplo, desde que alinhado com a equipe.

Análise Técnica

Nós, da equipe de desenvolvimento da Taller, não atuamos somente no downstream. No upstream fazemos análise técnica das histórias antes de nos comprometermos com o cliente que vamos desenvolvê-la (falando em etapas do nosso board, o ponto de comprometimento se dá quando uma história entra na etapa “Ready for Dev” ou “Pronta para Desenvolvimento”).

Nesta análise, pode ser verificada a viabilidade técnica de implementar o valor da história, a criação de provas de conceito para casos de alta incerteza ou até mesmo um desenho de arquitetura.

A ideia aqui é diminuir a incerteza e levantar a bandeira para possíveis inviabilidades técnicas antes do comprometimento com entrega da demanda. Essa análise deve evitar um nível muito alto de detalhamento, porque não há certeza de que a demanda entrará no fluxo de desenvolvimento.

Por isso, a análise tem de ser sucinta e barata, focando em pontos críticos (disponibilidade de APIs de integração, desempenho, segurança, etc.) e em recolher informação ausente (endpoints necessários para a implementação, detalhamento da regra de negócio, dúvidas sobre o layout, etc.).

Em alguns casos a incerteza pode ser muito alta e algumas possibilidades precisam de comprovação antes do ponto de comprometimento. Nesses casos a análise é mais custosa, pois estaremos desenvolvendo provas de conceito. Esses casos devem ser exceção e sempre alinhados com o time e camada de gestão.

Além disso, a regra é nunca reutilizar código escrito nessas provas, encorajando assim o foco no que precisa ser provado, sem precisar deixar o código perfeitamente alinhado aos padrões do projeto ainda na etapa de análise.

Atenção à saúde do fluxo

Para nós não existe “meu trabalho” e “trabalho do colega”. É tudo nosso trabalho. A autogestão funciona melhor se todos estão sendo responsáveis pela entrega de valor. Além da pessoa desenvolvedora não poder ficar esperando que lhe digam o que fazer, sua atuação deve cobrir todas as etapas do downstream, e não apenas a de desenvolvimento.

Se a história fica bloqueada em homologação, por exemplo, a prioridade de quem é responsável pela história deve ser remover esse bloqueio. Inclusive, o deploy para produção (quando executado pela Taller) é feito pela mesma pessoa ou pelo mesmo par que desenvolveu a história.

No dia a dia a expectativa é de uma cobrança saudável entre os membros da equipe, no sentido de deixar o trabalho visível no quadro Kanban e chamar a atenção para as prioridades, bem como o envelhecimento das demandas. A equipe deve se reorganizar para atender a bloqueios, demandas que estão ficando caras e outros pontos que podem comprometer a saúde do fluxo.

Seguir as políticas

Outro ponto importante quando falamos em autogestão, trata sobre as políticas da equipe. Algumas políticas são de fluxo, como limite de WIP, as políticas de classes de serviço e também as políticas para arrastar uma demanda de uma coluna para a outra no quadro.

Elas podem também ser do método de trabalho, onde entram práticas como a programação em par e escrita de testes. Seja como for, é através de políticas que os colaboradores têm mecanismos para fazer a cobrança entre si, sem ter uma figura de gerente que faça esse papel. Dessa forma, além de “achatar” a hierarquia, as pessoas têm mais noção da importância de seguir as políticas, sem entendê-las como simples ordens.

Vale salientar que nenhuma política é escrita em pedra, e que podem emergir alterações e novas políticas de qualquer colaborador. Muitas de nossas políticas surgiram de problemas levantados pela própria equipe em retrospectivas, por exemplo.

Algumas delas são: horário da daily, o nosso Workshop de Histórias em Done (comentado no segundo artigo da série), a remoção da coluna de QA do quadro Kanban, uso de tags para classificar demandas na análise técnica, entre outras.

Conclusão

Consideramos que parte fundamental de nosso modelo de trabalho é a liderança descentralizada. Isso quer dizer que cada pessoa, em sua esfera de trabalho, tem autonomia para organizar o seu tempo e seu trabalho. Não há um “chefe” que lhe aponte os passos e decida o que acontece com seu tempo.

Isso traz inúmeros benefícios à saúde do fluxo, já que o sistema é puxado e não depende da disponibilidade da camada de gestão para que o trabalho possa ser iniciado. Também beneficia a saúde das pessoas, pois estarão sem a pressão do sistema empurrado. É por causa dessa liberdade que devemos considerar as responsabilidades acima, afinal elas são fundamentais para que o todo funcione e a melhoria contínua permaneça acontecendo.