sábado, 16 de abril de 2011

Lean - Código perfeito ou evolução constante?

A ideia principal por trás do Lean é a perfeição. Pela perfeição, identificamos, analisamos e melhoramos nosso value stream. Por ela, eliminamos o desperdício e focamos no que realmente agrega valor. Um dos princípios do Lean diz para competir com a perfeição e não com a concorrência. Todos os elementos da natureza evoluem constantemente. Será que existe código perfeito?

É claro que não. Como tudo que é criado, o código sempre pode evoluir. No princípio de sua vida, a necessidade é maior e a evolução ocorre intensamente. Quando o código está maduro, obviamente, evolui lentamente. A questão é: a evolução não para nunca.

Então quando devemos subir o código para produção? Devemos considerar o código pronto quando ele atingir o nível de maturidade que a equipe acha aceitável. O "aceitável", como podemos imaginar, está intimamente ligado ao prazo. Assim, quanto menor o prazo, menor será o grau de maturidade aceitável, trazendo consequências negativas para a qualidade.

Competir contra a perfeição traz uma vantagem óbvia, pois não estabelecemos um teto. Entretanto, tem uma desvantagem não tão óbvia que é a necessidade de critério para estabelecer metas. O ser humano precisa conquistar. Se ficar muito tempo sem uma conquista, acaba frustrado.

No desenvolvimento de software, quem seria o concorrente? Infelizmente, é comum encontrarmos desenvolvedores que competem de forma nociva com outros desenvolvedores. Isso, infelizmente também, é uma característica do ser-humano. Por isso, não é exclusividade de desenvolvedores.

Quando a competição é nociva, as pessoas guardam o conhecimento e têm medo da evolução de outro profissional. É a defesa mais frágil, na minha visão. A fragilidade vem do fato do outro profissional só depender dele. O que vai acontecer quando for ultrapassado?

O que considero uma defesa robusta e firme? O profissional competir contra a perfeição, desafiando-se a cada dia. Quem pensa sempre em evoluir não precisa se defender negando a passagem de conhecimento. Como tem necessidade de evoluir, e as discussões são excelentes ferramentas de evolução coletiva, ensina sem medo, procurando fazer o melhor possível.

Quando ensina, vai perdendo um aluno e ganhando alguém para discutir ideias. Ouço isso desde os tempos de primário. Com o debate, as ideias evoluem e todos ganham, pois os resultados são melhores. Melhorar algo que já é razoável/bom é mais prazeroso que evoluir o que está muito ruim.

A evolução do time é importante para todos e deve ser incentivada. Ontem, conversando com o Rafael Ponte, Daniel Passos e Marcos Sousa, surgiram algumas formas de incentivo, como dojos e palestras frequentes. Não tenho dúvidas que a adoção deste tipo de prática pode nivelar o time de forma eficiente.

3 comentários:

  1. Ótimo post, como sempre!
    Gostei da menção ao ponto que eu sempre bato, de que concorrer contra a perfeição pode ser frustante.
    Devemos sim, sempre buscar a evolução, mas tratando cada melhoria no código como uma vitória.

    ResponderExcluir
  2. Neste artigo você abordou um tema que eu pensava em escrever, algumas pessoas pensam surfar no código perfeito, só que isto não existe.

    Se acham também imunes a erros, só que esquecem que somos seres humanos, e quando eles acontecem seus egos não conseguem admití-los, causando diversos problemas dentro da equipe.

    E, o que piora muito a situação é que estas pessoas são competentes tecnicamente, só lhes falta um pouco de inteligência emocional. É aí que entra o bom gestor de equipe, identificando o problema e trabalhando para minimizá-lo.

    Gostei também quando você relacionou a qualidade com o prazo da entrega. Trabalhei com pessoas que frente a um prazo agressivo ou impossível, trabalhavam como alucinadas. No final ficavam frustadas, ou por não se sentirem satisfeitos com o que foi entregue, ou por se setirem traídos por sua liderança. Enquanto era esperado outra coisa: entregar, dentro de um rítmo razoável de trabalho e com um mínimo de qualidade e segurança, as funcionalidades possíveis.

    A chave aqui é a palavra mínimo, o que posso abrir mão para desenvolver, sem precisar trabalhar 12h+, o máximo de funcionalidades?

    Nunca vi, e acho que nunca verei um desenvolvedor psicopata que aceitasse, na boa e de coração, subir um código fora dos parâmetros de qualidade que ele gostaria. Bom, a não ser que os tempos estejam mudando . . .

    abs

    ResponderExcluir
  3. Bad, fiz uma crítica sutil aos prazos loucos que de vez em quando aparecem. O mais interessante é que, em muitas empresas, quem define o prazo não é quem desenvolve ou vai manter.

    O desenvolvedor deveria estar mais comprometido com a qualidade, pois é a noite de sono e finais de semana dele que estarão em jogo.

    A evolução constante acontece também na manutenção. Quando temos uma alteração para fazer e percebemos algo que hoje podemos fazer melhor, não podemos ficar com medo de refatorar, como vejo constantemente. Refatorar com testes automatizados é mais seguro, então por que não criar testes de unidade para garantir o comportamento daquela porção de código?

    Minha definição de pronto é resolver o requisito do cliente, com o melhor código possível dentro do prazo combinado. Se eu tiver a oportunidade de mexer nesse código novamente e ele for passar por todas as etapas de testes até produção, aproveito para melhorar. Se não possuir tempo para fazer durante o expediente, faço em casa. Isso com meu código ou de qualquer um. Sou desenvolvedor, não posso ter medo de código. Infelizmente esse medo é muito comum.

    Por isso me considero psicopata. Gosto de entregar no prazo e o melhor possível.

    Estou em evolução, por que o código não deveria evoluir também? A cada passo que damos, nosso primeiro código começa a evoluir também. Cada dia que passa, a qualidade do nosso trabalho fica maior. E conseguimos desenvolver em menos tempo. Não vejo desvantagens.

    Enfim, bom conversarmos sobre meus posts por aqui também. =)

    Abraços!

    ResponderExcluir