Palestra realizada no FISL 2013 sobre cultura de aprendizagem por Rafael Helm e Guilherme Elias.
Nesta palestra Rafael e Elias falam sobre algumas ações que empresas e equipes podem realizar para disseminar conhecimento entre as pessoas, criando assim um ambiente de aprendizagem e melhoria contínua.
Praticar para evoluir é algo necessário na vida de qualquer pessoa. Desde criança, usamos a prática como forma de aprendizado e evolução, basta você puxar da memória para lembrar como foi necessário praticar até conseguir amarrar os cadarços de um calçado sozinho, sem precisar da ajuda dos pais.
Atletas chamam está prática de “treino”. Atletas treinam quase que diariamente, muitas vezes de forma exaustiva e repetitiva. Se você acha que o jamaicano Usain Bolt (recordista mundial e bi-campeão olímpico nos 100 e 200 metros), atingiu o alto nível através de talento e boa genética (sorte), então de uma olhada neste vídeo e veja como ele treina.
É bem provável que ainda hoje você vai precisar executar alguma tarefa que não se sente confortável, que ainda não praticou o suficiente. Alguém pode te ensinar algo, te dar uma introdução ou até uma explicação bem detalhada; você pode ler livros e fazer treinamentos, mas muitas vezes você só vai aprender de verdade praticando, tentando, treinando, refletindo sobre os erros e acertos, e praticando novamente.
No desenvolvimento de software praticar/treinar é algo mais do que necessário, é obrigatório, é fundamental. Durante toda sua carreira, você precisará passar por ciclos de aprendizado que somente serão concluídos se você praticar.
Não importa se você está aprendendo uma nova linguagem de programação, ou aprendendo TDD, ou aprendendo uma nova forma de escrever requisitos que pode ser através de user stories, ou uma nova forma de estimar requisitos através de user story points e planning poker ou outras formas de estimativa, ou um novo modo de trabalhar em equipe através de Scrum e eXtreme Programming. Não importa o que você está aprendendo, você vai precisar praticar, refletir, e praticar novamente para aprender de verdade.
Assim como no esporte quanto na vida, praticar/treinar dói. Mas acredite, se você insistir e perseverar a dor vai passar, e com o tempo aquela prática que antes te machucava vai se tornar algo agradável. Eu vejo muita gente começar a correr para perder peso, (mesmo odiando correr), mas com o tempo, através da prática gradativa o que antes era algo desconfortável rapidamente deixa de ser algo tão ruim, e mais a frente a pessoa começa a curtir o hábito da corrida, e muitas vezes até começa a acordar mais cedo para correr mais tempo e distâncias maiores.
“Não se preocupe com a perfeição – você nunca irá consegui-la.” (Salvador Dali)
Um ponto importante a ser considerado quando estamos praticando é trabalhar com baby steps, ou seja, pequenos passos de forma gradativa, buscando sempre acertar o próximo passo ao invés de alcançar a perfeição. Desta forma seu aprendizado vai passar por várias pequenas vitórias que vão motivá-lo, e quem sabe, sem perceber, alcançar a perfeição.
No desenvolvimento de software eu vejo uma onda bacana de coding dojo acontecendo dentro de empresas, universidades e eventos, acho isto ótimo. Os coding dojos proporcionam um ambiente saudável de aprendizado, já que a troca de experiências entre os participantes é o ponto forte da atividade, e para pessoas como você que querem aprender e praticar, isto, vamos combinar, é uma enxurrada de motivação.
E você, já praticou hoje? 😉
Em 2010 escrevi este post para o portal iMasters.
Passados 3 anos resolvi puxar o post pra cá e já aproveitei para revisar e complementar alguns tópicos.
Aviso: não se ofenda com o que vai ler a seguir, algumas comparações são na verdade uma provocação, o objetivo aqui é te fazer refletir, para quem sabe melhorar mais a frente – Hansei + Kaizen (Reflexão e melhoria contínua).
— — — — — — — —
Segundo o dicionário da língua portuguesa a definição de profissional é “pessoa que exerce uma certa profissão”.
Então, se você exerce profissionalmente o papel de desenvolvedor de software, logo, você pode ser classificado como um “desenvolvedor profissional”, correto?
Em tese sim!
Digo em tese porque meu conceito (e não é apenas o meu conceito) de desenvolvedor profissional é diferente do que consta no dicionário. Tem muito desenvolvedor amador por ai no mercado, botando banca de super-herói, mas que na verdade gera mais bugs do que features de software.
Mas como podemos diferenciar profissionais de amadores? Algumas dicas:
– Desenvolvedores profissionais planejam suas implementações antes de sair despejando linhas de código na aplicação. Desenvolvedores amadores freqüentemente trabalham com o método de tentativa e erro, ou seja, sem nenhum planejamento prévio ou análise de impacto em outras classes/módulos da aplicação. Não subestime o poder de um fluxograma.
– Desenvolvedores profissionais se preocupam com o desempenho de suas soluções e não apenas se a especificação recebida foi atendida. Desenvolvedores amadores não se preocupam com desempenho, o importante é entregar o que foi pedido, afinal de contas no documento não falava nada em relação a performance.
– Desenvolvedores profissionais produzem códigos legíveis, frequentemente fazem refactoring em seus códigos e são apaixonados pelos livros Clean Code e Clean Coder do Robert C. Martin. Enquanto isto, os desenvolvedores amadores procuram no dicionário o significado da palavra refactoring.
– Desenvolvedores profissionais trabalham com desenvolvimento orientado a testes e criam testes funcionais, ou pelo menos estão ligados no assunto e buscam formas de “conectar” isto ao seu cotidiano. Desenvolvedores amadores não são pagos para testar; Azar do testador, compilou passa pra frente!
– Desenvolvedores profissionais estão atentos para outras atividades do ramo de desenvolvimento de software como análise de requisitos, banco de dados, padrões de projeto, metodologias de desenvolvimento, teste de software, etc. Desenvolvedores amadores apenas programam, isolados de tudo e de todos!
– Desenvolvedores profissionais trazem os problemas a tona sempre que os encontram. Desenvolvedores amadores varrem para debaixo do tapete.
– Desenvolvedores profissionais sempre buscam acertar na primeira vez e para isto não abrem mão da qualidade de código, para eles a qualidade nunca é opcional e está sempre presente. Desenvolvedores amadores evitam a fadiga, praticam pog no dia a dia, e quando a coisa fica feia procuram outro lugar para trabalhar. 😉
E você, é amador ou profissional?
Quantas vezes durante sua carreira você trabalhou na solução de um problema, que na verdade, não existia?
Ou utilizou uma informação incorreta para criar uma funcionalidade em seu software?
Ou tomou alguma decisão baseada em boatos que escutou pelos corredores?
Eu já passei por isto algumas vezes, e provavelmente você também.
O que precisamos fazer é simples: Genchi Genbutsu!
Vá e veja com seus próprios olhos!
Quando um cliente te pedir uma funcionalidade nova, que por exemplo, resolva um problema em sua linha de produção, vá até o cliente e veja com seus próprios olhos como funciona a linha de produção e qual é o problema do cliente.
O ponto aqui é: Vá na origem, observe pessoalmente, verifique dados, em vez de teorizar com base no que os outros te falam.
Quando você vê algo por si mesmo, você entende completamente a situação, e não é traído pelas falhas de comunicação que ocorrem com frequência.
Isto vai exigir que você saia da famigerada zona de conforto, porém reduzindo significativamente o desperdício de energia (e muitas linhas de código) para resolver problemas que não existem. 😉
Henry Mintzberg disse “You cannot create a manager or leader in a classroom“. O contexto vem de uma discussão sobre o mercado precisar de gerentes e não de MBAs. Que os cursos são muito bons para ensinar as práticas que gerentes vão precisar no mercado, pensando em “o que” aplicar… mas isto é diferente das situações de como aplicar, que se ganha com a prática do dia a dia.
Mintzberg também trabalha a questão que todos deveriam conhecer gerenciamento, para então buscar um cargo onde a necessidade de gestão seja um requisito.
O ponto é que a prática é o que nos leva a experiência e a realmente conhecer algum assunto.
Não é a teoria. É a prática. É a experimentação. É o trabalho em campo.
Então, da próxima vez que você entrar em uma sala de aula, lembre-se disto: um treinamento, o trabalho em sala de aula, serve para consciência e reflexão!
Para ganhar experiência, seja em projetos, em técnicas de apresentação e escrita, você precisa enfrentar situações no seu dia a dia. Existem formas de criar estas situações de realidade, exemplo:
O simples fato de participar de ações como estas, vão resultar em experiência. Prática. Esta prática vai ajudar a criar cultura. A criar um ambiente, de puro aprendizado, mas lembre, prático!
No dia 26 de junho de 2010, o Rafael Helm publicou aqui mesmo no Pingos de Agilidade o que era para mim Agilidade. O Rafael pediu para eu mandar em uma frase.
E eu mandei: Atitude, foco em entrega de software, trabalho em equipe e melhoria contínua.
Só que como todo desenvolvedor Clean Code, tudo pode ser refatorado. 🙂
E nesta declaração, se eu for simplificar em algo, como já vi o @KlausWuestefeld fazer com os valores do eXtreme Programming, chegando no Learning and Coolness, entendo que atitude e foco em entrega fazem o resto acontecer.
Vejamos:
Trabalho em equipe não é opcional. Você nunca vai ser melhor do que uma equipe em sinergia. Não quer uma equipe? Pense em um par, pense nos benefícios de ter conhecimento navegando e se tornando algo consciente e consistente entre as pessoas que fazem parte da equipe.
Melhoria contínua também não é opcional. Se sua equipe não melhora, ela sempre vai piorar. Simplesmente não se consegue “manter” a qualidade porque conforme o aumento da base de código, prazos, decisões mal feitas no projeto, novos problemas relacionados a modularidade e outros aspectos no desenvolvimento de software vão ficar mais visíveis. Então melhorar continuamente é algo que se faz sempre.
É a continuidade do processo de questionar aquilo que está sendo feito e buscar sempre melhorar, faz parte da atitude.
E é o que sobra e ao mesmo tempo faz a diferença. A atitude da equipe perante os obstáculos e como ela encara as situações de planejar novas funcionalidades para um produto, como ela encara o feedback ao cliente depois de um problema na operação do produto. Ou ainda como cada pessoa que faz parte da equipe vê a resolução de um defeito.
Se eu foco na entrega de software, quero garantir que o trabalho será o melhor possível, pois ninguém quer ter que trabalhar a noite ou final de semana ajustando algum problema de produção, causado na liberação de versão.
Então focar em entrega exige busca por qualidade, exige melhoria contínua. Só que sem atitude e foco em entregar aquilo que o cliente precisa, pensando em simplicidade, nada ocorre.
Exige aprender novos truques, em buscar novos conceitos como DevOps e Continuous Delivery.
Pingos de Agilidade 