Valores do Lean Thinking na visão de desenvolvedor
Published: 2021-01-15 13:15:49

Olá, abaixo vou listar os princípios do Lean mas pensando a partir da visão de um desenvolvedor. Devo dizer que os exemplos ou perspectivas que vou pontuar podem não se aplicar diretamente à você, mas se você considerar o princípio em si acredito que possa ser um ponto de partida pra você pensar como pode melhorar o seu processo como desenvolvedor ou em um time.

A intenção não é explicar totalmente mas repassar os princípios, afinal existem diversas documentações oficiais que vão entrar em detalhes e você pode consultar. 

Dito isso, vamos lá! 🤩

-------

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1jqyj5velgoa7ysp20us.png)
##Especificar o valor

*Primeiro é necessário reconhecer qual o valor do nosso produto ou serviço mas a partir do ponto de vista do cliente. O foco é identificar o que de fato agrega valor para ele e aquilo que não agregar, deve ser considerado desperdício.*
 
O resultado desse princípio é **o foco na necessidade do cliente**. Lembrando que o "cliente" não precisa ser alguém de fora, pode ser por exemplo os usuários que utilizam sua ferramenta mesmo dentro da empresa, ou time de gerência que usa o BI que o time interno desenvolveu.
O quanto um app pode impactar positivamente no resultado de uma empresa por exemplo? Que valor uma companhia daria à um software? Um exemplo: uma empresa de transporte de cargas que quer implantar dois softwares:
- Um software de rastreio que vai acompanhar os rastreadores instalados nos caminhões usando triangulação de GPS via 3G.
- Um software para enviar e-mail aos colaboradores no dia de seu aniversário.

Qual o valor que a empresa dá a cada um dessas duas soluções? Nesse exemplo fica óbvio que o primeiro software é o que é mais valoroso, possui mais impacto. Mas nem sempre a percepção é tão óbvia assim *(vou dizer que geralmente não é)*.
E mesmo dentro de uma única solução, teremos requisitos com valores diferentes. Envolver o cliente e entender esses valores é que vai fazer diferença nos próximos passos.

-------

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ikv6852kau8mkj6c3k92.png)

##Mapear o fluxo de valor

*Uma vez identificado o produto/serviço e seu valor para o cliente, o próximo passo é mapear todo o caminho até o cliente.* 

Um produto por exemplo, o processo desde a matéria prima, passando pela produção, embalagem até venda pro cliente. 
Agora falando de desenvolvimento, em uma aplicação podemos pensar em:
- Definição dos requisitos.
- Processo de priorização.
- Implementação.
- Testes e qualidade.
- Liberação em produção.
- Suporte. 

Antes de pensar em otimizar qualquer processo é importante mapear como está sendo feito, porque cada negócio tem suas particularidades as vezes existem processos que podem parecer *estar ali de bobeira*, ou que possa não ser o máximo de otimização mas que para o negócio tenha um motivo para ser daquele jeito. Então antes de pensar em aplicar *Agile*, *Scrum* puro ou outros métodos é importante entender como as coisas estão sendo feitas e se há um porque razoável em ser feito desta maneira. 


-------

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/h5y7fefb9zoibiproxit.png)
##Criar fluxo contínuo
*Otimizar o processo de produção com o objetivo de realizar as tarefas sem nenhuma interrupção.* 

Fluxos com muitos passos onde um depende do outro podem acabar gerando um gap de tempo de espera, então esse princípio vai focar em eliminar esse tempo e também para gerar uma entrega contínua além de buscar reduzir desperdícios. 

Um bom exemplo seria um cenário onde o desenvolvedor recebe um *backlog* enorme com inúmeros requisitos de correção de bugs em uma certa aplicação. Ele então decide resolver todos os bugs levando duas semanas para isso em uma única sprint, e depois liberar um único commit pra aprovação com tudo implementado. O responsável de QA vai levar uma semana apenas pra revisar, sendo realmente bem otimista aqui, digamos que tudo foi aprovado. O cliente teve uma única entrega de diversas correções depois de 3 semanas. 
Para criar um fluxo contínuo o desenvolvedor deveria a cada correção de bug criar um commit e já repassar para QA validar, e este ao aprovar aplicar na *main*. Desta forma temos uma boa linha de produção onde reduzimos o acúmulo e a espera e passamos a fazer entregas constantes ao cliente.

-------

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jdm5wxbal3fejgtwuspo.png)
##Resposta "puxada" do cliente
*Quando a produção é feita conforme a demanda do cliente, sem a necessidade de manter estoque ou armazenar o mínimo possível. Dessa forma evitar desperdícios de espaço, trabalho e tempo.* 

Em um projeto de desenvolvimento, podemos ter ótimas ideias e acabar focando em alguma deles sem que seja uma necessidade ou demanda do cliente. No caso do exemplo da empresa de transporte que citei acima, o time poderia estar focado em uma ideia interna de além dos e-mails de aniversariante, aproveitar pra criar também o recurso pra enviar via Whatsapp pois é um recurso que vai agregar maior valor a ferramenta. **Essa não é uma demanda do cliente**, foco, tempo e esforço estão sendo direcionados para um recurso que ficará em "estoque" na aplicação e que pode até agregar valor à ela, mas não há uma demanda nesse momento. Lembre-se o objetivo é atender ao cliente da maneira mais rápida e eficiente possível levando em conta o valor a partir da perspectiva dele.
 
Claro, exitem recursos que podem agregar tanto valor à ferramenta que a ideia pode ser direcionada à um time de serviços implementar. Mas não vou entrar nesse mérito aqui para justamente não fugirmos do foco.


-------

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bg5yhis1yowfbj31opeo.png)
##Seguir perfeição

*A melhoria contínua é uma constante, sempre melhorar e buscar formas melhores de entregar o valor do cliente.*

Ao ver no processo possibilidades de melhorar, deve ser discutido pelo time. Medidas como:
- Efetuar correções com o objetivo de evitar dívidas técnicas. 
- Refatoramento de código legado.
- Entregar o código sempre melhor do que você recebeu.

Essa última medida inclusive tenho pra mim como um mandamento básico para todo desenvolvedor. Quantas vezes ao fazer manutenção de um código vemos como podemos deixar mais correto, mais limpo ou mais eficiente e deixamos de fazer por pressa ou falta de capricho. Nós temos responsabilidade sobre o que escrevemos e como construtores nunca devemos deixar de pensar em qualidade de código.  

-------

Por hoje é isso. Claro que as ideias acima servem como ínicio para sua reflexão na hora de olhar para si, para seu time e seu negócio e não como normas em si. Recomendo a leitura de conteúdo mais completo sobre Lean, Scrum e também pensar como os dois conceitos podem se dar muito bem juntos.