Lean: Amplie o Aprendizado

As origens do Lean estão diretamente ligadas à indústria. Entretanto, os princípios Lean podem ser aplicados diretamente ao desenvolvimento de software.
É preciso deixar claro: Criar software não é um processo produtivo; a atividade é melhor comparada a um processo de desenvolvimento.

Mas qual a diferença?

Entenda o processo de desenvolvimento de software como uma atividade semelhante à do Chef de cozinha, preparando um novo prato. Um processo produtivo seria eu, após ver a receita no programa da Ana Maria Braga, reproduzí-la. Para um, a variação de experiências é extremamente importante para atingir os melhores resultados... para o outro (eu e a Ana Maria), a situação é diferente, variações não são toleradas, sob pena de não ter o prato criado.

O método científico

Software está inserido no grupo de atividades chamadas problem-solving. Isto quer dizer que, de antemão, toda a intenção em criar um software está ligada à resolução de um problema.

Para problemas complexos, é necessário ter o máximo de informação possível para que se possam propor uma solução apropriada. A aborgadem coerente para tal é utilizar o método científico: observe, crie uma hipótese, execute um experimento e verifique se os resultados são condizentes com sua hipótese. O ponto interessante de tal abordagem é que, caso suas hipóteses estejam sempre corretas, você não conseguirá aprender muito. Caso exista uma possibilidade de falha em suas hipóteses, a quantidade de informação adquirida em experimentar será imensamente mais rica.

Existem duas escolas bastante distintas em na área de software:

A primeira motiva um desenvolvedor a ter certeza que todas as suas soluções - design, código, testes- estejam perfeitas à primeira execução. Neste ambiente existe pouco espaço para a geração de conhecimento através da experimentação. Esta abordagem funciona melhor em problemas bem estruturados - normalmente possuem uma única solução já bem conhecida e um caminho preferido para alcançar tal solução. Por exemplo, os principais problemas apresentados em colégios.

A segunda escola afirma ser melhor possuir ciclos rápidos de experimente - teste - corrija do que garantir à primeira vista que um código está perfeito. Citando Edward Yordon:

Um pedaço de lógica em código normalmente precisa ser reescrito três ou quatro vezes para ser considerado um trabalho elegante e profissional. Então por que existe tanta resistência em refatorar código quando estamos sempre felizes em poder revisar documentos várias vezes até chegar a um resultado satisfatório?

A sugestão Ágil

Transforme a experimentação e o feedback numa constante. Permita que os desenvolvedores possam, de forma rápida e barata, tentar formas novas de aumentar sua qualidade e produtividade. Utize os resultados para aprender o máximo que puder e não tenha medo de tomar decisões erradas.

Iterações curtas permitem um feedback instantâneo dos clientes e usuários sobre a satisfação e a utilidade que seu sistema apresenta.

Retrospectivas são um momento importantíssimo do processo de desenvolvimento de software, já que é possível encontrar problemas que afetam a todos numa equipe, que dificilmente seriam percebidos.

"Learning is everything"

[]s