Análise Técnica no Upstream Kanban

Há mais ou menos um ano introduzimos um novo processo em nosso upstream: a análise técnica dos itens de trabalho. Desta forma trazemos a equipe de desenvolvimento para atuar antes do ponto de comprometimento de cada demanda, usando o conhecimento das pessoas desenvolvedoras para reduzir incertezas que poderiam virar um descarte no downstream. Chamamos isso de Análise Técnica.

O quê?

A Análise Técnica consiste de uma etapa em nosso fluxo de entrega de valor onde a equipe de desenvolvimento concede seu parecer técnico sobre os itens que podem entrar na fila para execução. Traduzindo para o quadro Kanban, significa que há uma etapa de fila, chamada “Pronta para análise técnica”, e uma etapa onde de fato a análise acontece, chamada “Análise Técnica“.

Board no Miro – Upstream Kanban
Fonte: elaborada pelo autor

Por que fazer a Análise Técnica?

• Redução de incertezas técnicas: se ainda há dúvidas sobre a regra de negócio, a viabilidade da implementação, acessos necessários ou quaisquer outros fatores que poderiam bloquear o andamento do trabalho, são levantadas as informações necessárias antes de nos comprometermos com o desenvolvimento da demanda.
• Reaproveitamento de soluções já implementadas: também usamos a etapa de análise para apontar se no sistema já existe alguma parte da implementação que possa ser reaproveitada.
• Geração de opções de solução: a ideia não é criar uma lista de tasks a serem seguidas ou definir detalhes de implementação, porém, em demandas mais complexas, alternativas geralmente são sugeridas para guiar o desenvolvimento.
• Redução de impactos/bloqueios no downstream: se descobrimos, por exemplo, que um serviço necessário ao desenvolvimento da demanda não está disponível, então evitamos que este item fique bloqueado dentro do limite de WIP do downstream.

Quando fazer a Análise Técnica?

• Após síntese e análise de negócios: o propósito e os critérios de aceite da demanda já devem estar definidos.
• Antes do ponto de comprometimento: como é previsto que na análise podem ser detectadas inviabilidades ou fatores de bloqueio, ela é feita antes de nos comprometermos com a execução (entrada no downstream).
• Expedites geralmente pulam: é comum que expedites sejam bugs em produção que precisam de correção imediata. Isso quer dizer que a certeza é alta sobre o que deve ser feito na demanda. Mas isso não é uma regra absoluta: ela ainda pode passar pela análise técnica quando não está claro como o problema será corrigido, como reproduzir o incidente ou se o problema é realmente grave (o que não justificaria uma expedite furando a fila de entrada no fluxo).
  

Como fazer a Análise Técnica?

• Identificação de Inviabilidades Técnicas: quanto antes identificarmos a inviabilidade de uma implementação, melhor. Nesses casos sugerimos alternativas de implementação ao cliente.
• Criação de provas de conceito: em alguns casos, a história pode envolver tecnologias, ferramentas ou integrações que são novidade para a equipe. Nessas situações executamos uma prova de conceito, com a finalidade de garantir que seja possível chegar no objetivo da demanda.

Essa prova de conceito se assemelha bastante ao Spike Solution, do XP, no sentido de que apenas queremos provar uma possível solução, sem necessariamente seguir os padrões do projeto, pois o código gerado será obrigatoriamente descartado. Tratamos esses casos como exceção, já que o foco do upstream não está na solução, mas sim na redução de incertezas. Adicionamos [POC] [mfn](poc é a sigla em Inglês para prova de conceito, ou seja, proof of concept) [/mfn] na frente do título da demanda para identificarmos e limitarmos a concorrência de análises desse tipo.

• Levantamento de pontos de atenção: pessoas desenvolvedoras com mais contexto do projeto podem enumerar pontos a serem levados em conta durante a implementação. Isso pode envolver desde a indicação de código a ser reaproveitado para evitar retrabalho até tasks adicionais que sejam necessárias para o bom funcionamento em produção.
• Sugestões de quebra de histórias: quando identificamos que uma história está muito grande, podemos sugerir a quebra para suavizar o fluxo e diminuir o risco da entrega. A quebra é negociada com nosso analista de negócios e o responsável do lado do cliente.
• Sugestões de arquitetura: algumas histórias podem envolver alterações em várias partes da aplicação, ou mesmo tratarem de um novo recurso que será crítico para o sistema. Nesses casos, usamos a Análise Técnica para sugerir a arquitetura da solução, às vezes inclusive pedindo a opinião da outra parte da equipe.
• Reunião de informações pertinentes: detalhes técnicos como endpoints a serem consumidos, acessos a serviços do cliente, links para documentação, entre outros, são totalmente pertinentes de serem listados antes da demanda entrar em desenvolvimento.
• Passos de teste/reprodução de erros: demandas de falha podem chegar com uma descrição um pouco vaga para a equipe de desenvolvimento. É importante que o erro seja reproduzido durante a análise e seus passos descritos para dar um melhor direcionamento.

Com essas atividades, conseguimos ter uma qualidade maior das demandas que chegam para a fila de entrada da área de comprometimento (downstream), que é de onde a equipe de desenvolvimento puxa o trabalho. Reduzimos o descarte de demandas e bloqueios por impedimentos técnicos dentro de nosso WIP de trabalho comprometido, bem como o custo de cancelamento.

Ah, se você também curte o tema de agilidade e negócios, temos um post sobre esse assunto aqui no blog com o Upstream Kanban, super recomendo você conferir: “Agilidade nos negócios com Upstream Kanban”