Agile br2011 lucabastos-prog10x
11 gostaram1,015 visualizações
A apresentação discute como formar programadores 10x, destacando a importância de qualidades como inteligência e boa comunicação. Aborda a dificuldade de medir produtividade e propõe práticas como programação pareada e revisão de código para ajudar iniciantes a se tornarem melhores programadores. O autor, Luca Bastos, enfatiza que o desenvolvimento ágil e um ambiente de trabalho propício são essenciais para o crescimento das equipes.
Agile br2011 lucabastos-prog10x
- 1. Como formar um programador 10x Luca Bastos luca.bastos@concretesolutions.com.br Agile Brazil 2011 Fortaleza, CE
- 2. A m a i o r r i q u e z a d o h o m e m é a s u a i n c o m p l e t u d e . N e s s e p o n t o s o u a b a s t a d o. P a l av r a s q u e m e a c e i t a m c o m o s o u - e u n ã o a c e i t o. N ã o a g ü e n t o s e r a p e n a s u m s u j e i t o q u e a b r e p o r t a s , q u e p u x a v á l v u l a s , q u e o l h a o r e l ó g i o, q u e c o m p r a p ã o à s 6 h o r a s d a t a r d e , q u e v a i l á f o r a , q u e a p o n t a l á p i s , q u e v ê a u v a e t c . e t c . Pe r d o a i M a s e u p r e c i s o s e r O u t r o s . E u p e n s o r e n o v a r o h o m e m u s a n d o b o r b o l e t a s . M a n o e l d e B a r ro s
- 3. Quem sou: Desenvolvedor do tempo da Carochinha, ávido leitor e praticante sempre interessado em metodologias de desenvolvimento, desde antes de surgirem programação modular, programação estruturada e todas as demais até os dias de hoje. Meninos, eu vi. E vivi.
- 4. Onde trabalho: http://www.concretesolutions.com.br/ A Concrete tem 10 anos com um portfólio de clientes bem variado no Brasil e no exterior. No início a maior demanda do mercado era para soluções de integração e assim foi natural a parceria com os grandes players como Oracle, Red Hat, etc. Atualmente a diversificação é bem grande e temos também ótimos projetos nas áreas de cloud, mobile, web e lean startups de tecnologia. Praticamos e pregamos o desenvolvimento ágil desde 2007. Hoje temos 56% do faturamento usando Scrum e Kanban e só 12% de projetos fechados.
- 5. “Design and programming are human activities; forget that and all is lost.” Bjarne Stroustrup The C++ Programming Language, 2nd Ed, Section11.1, pág.363
- 6. Arbitrariamente vou definir um programador 10x como aquele que sem ser gênio, tem pelo menos um pouco das seguintes qualidades: - inteligente (e com bons princípios éticos), - personalidade que alie GTD a criatividade e mais boa interatividade com time, - sabe programar e conhece as tecnologias do projeto (melhorar aqui é o foco desta apresentação)
- 7. Veremos o que fazer para elevar o nível de um programador iniciante e como criar condições de um dia ele vir a ser um programador 10x.
- 8. Você conhece um programador 10x?
- 9. Melhor dizendo, reconhece um programador 10x?
- 10. Você contrataria alguém como os personagens das fotos seguintes?
- 16. Ops... Desculpa aí Milfont ...
- 17. Origem do meu interesse no tema da apresentação Ligue djá
- 18. Segundo o prof. Robert Glass, no livro de 2002 Facts and Fallacies of Software Engineering Fato 1: O fator mais importante no trabalho com software é a qualidade dos programadores. Fato 2: A diferença entre os melhores e os piores programadores pode ser de até 28 vezes.
- 19. A diferença de produtividade entre programadores já foi motivo de preocupação de estudiosos como Bohem, De Marco, Spolsky e outros.
- 20. Steve McConnell também discute o que é um programador 10x e se é viável medir variações na produtividade Ver último capítulo de Making Software, What Really Works, and Why We Believe It, O’Reilly 2011
- 21. Origem do termo programador 10x Segundo um estudo de 1968 (ver *) Diferenças entre o melhor e o pior entre programadores com 7 anos de experiência, Tempo para “codar” 20x Tempo para debugar 25x Tamanho do código 5x Tempo de execução do código 10x * Making Software, What Really Works, cap.30, What Does 10x Mean? Steve McConnell
- 22. Segundo o mesmo McConnell (*), o tal estudo tem falhas porque compara resultados de programadores usando linguagens de baixo nível com outros usando linguagens de alto nível Tempo para “codar” 20x Tempo para debugar 25x Tamanho do código 5x Tempo de execução do código 10x * Making Software, What Really Works, cap.30, What Does 10x Mean? Steve McConnell
- 23. Porém McConnell (*) repara que a diferença entre os melhores e os piores pode ser considerada como 10x Tempo para “codar” 20x Tempo para debugar Tamanho do código Tempo de execução do código 10 X 25x 5x 10x
- 24. Escolhi usar o termo 10x porque meu conceito de 10x está mais para os bons que podemos formar do que para os pontos extremos excepcionais que poderiam ser os tais 28x.
- 25. Mas eu conheço muitos bem acima do 10x Chegaram lá por diversos motivos dentre eles qualidades pessoais acima da média Vamos ver alguns que quase todos conhecem:
- 27. Não é com estes que estou preocupado É com os novos que contrataremos E supondo que nossos iniciantes são inteligentes, falarei sobre o que fazer para que se tornem 10x em menos tempo
- 29. #Fatos Atualmente está difícil contratar programadores O mercado está aquecido e há poucos disponíveis Mais fácil contratar iniciantes e treiná-los até o nível médio da equipe
- 30. Desafio número 1: Dar condições para o iniciante virar bom programador continuando sendo um ser humano (sem arrogância).
- 31. Opinião do Joel Spolsky: Contrate um super star caso queira um produto acima da média.
- 32. Mas todo mundo conhece um super programador que ninguém quer na equipe.
- 33. Um super piloto de caça nem sempre se sujeitará as normas de segurança de um avião de carreira ou o barão vermelho pode não ter habilidade para conviver com as demais pessoas.
- 34. Desafio número 2: Reconhecer os melhores.
- 35. E como reconhecer os melhores? a) Medindo a produtividade? b) Existem outros meios de reconhecê-los?
- 36. Medir a produtividade Será fácil fazer isto?
- 37. Linhas de código? Mas programadores espertos produzirão mais escrevendo códigos mais longos Lembrando Dilbert: você obtem o que mede
- 38. Pontos de função? Mas código ruim não gera mais pontos de função.
- 39. Número de histórias prontas? Mas e a complexidade diferente de cada uma?
- 40. Então não consigo medir a produtividade? Para mim a resposta é não. Parece até perda de tempo tentar. Concordo com Martin Fowler em http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
- 41. Então como saber se um programador já é 10x? Se não se pode medir Quais serão então os tais outros meios?
- 42. Minha resposta: acompanhamento dia a dia
- 43. Para nossa sorte, os meios de acompanhamento úteis para reconhecer um programador 10x
- 44. São exatamente os mesmos que possibilitam conduzir um iniciante ao conceito 10x
- 45. - Programação pareada - Revisão de código - Compartilhamento de conhecimento, workshops, práticas de dojos, etc. - TDD, boa comunicação, etc.
- 46. Primeiro resultado desta apresentação Não é possível medir a produtividade dos programadores mas se pode avaliar cada um por meio de acompanhamento frequente.
- 47. Esta página foi intencionalmente deixada em branco para que você pense no dia a dia do seu projeto
- 48. Impressões minhas: Algumas práticas do desenvolvimento ágil adequadas a elevar o nível dos iniciantes são deixadas de lado ao estimar um projeto. Nem sempre o ambiente de desenvolvimento facilita o emprego destas práticas.
- 49. No seu projeto ou na sua empresa: - nas estimativas é previsto o pareamento? - ou cada desenvolvedor pega uma tarefa? - e há tempo para revisão de código? - há práticas de disseminação de conhecimento? - o ambiente de trabalho facilita o pareamento? existem baias? As mesas permitem pareamento? - é fácil trocar de par ou os desenvolvedores tem lugar fixo?
- 51. Considerando que uma boa parte dos desenvolvedores trabalha alocado nos clientes, e que dentro do ambiente deles dificilmente conseguimos tempo no projeto e espaço físico ideal, só pode ser pegadinha do Malandro falar destas práticas.
- 52. Mesmo nas empresas cujo objetivo principal é o desenvolvimento de software, nem sempre há espaço físico propício às práticas citadas Também não é fácil encontrar imóveis e móveis ideais
- 53. Muitas vezes por pressões dos clientes ou pelo exíguo time to market do produto, é difícil subtrair tempo do projeto para cuidar dos processos (*) de melhoria contínua e renovação da equipe. * Se não cuidar destes processos, então cuidado com a lei de Brooks: “adicionar pessoas a um projeto atrasado irá atrasá-lo ainda mais”
- 54. Desafio número 3 (este sim o mais difícil) 1. Convencer os gestores das empresas da importância destas práticas. 2. Convencer os clientes que produto feito sob encomenda só será bom e atualizado, se estiver sob um processo de melhoria contínua. Portanto é preciso reservar tempo para isto. 3. Convencer os desenvolvedores de são eles os beneficiados e que também precisam doar tempo.
- 55. O passo 1, ao contrário do que dizem, costuma ser o menos difícil: convencer os chefes. E eles tem acesso e mandato para convencer nossos clientes.
- 56. Porém ninguém se iluda. Muito mais difícil é convencer os colegas, de que são parte interessada no processo de melhoria e atualização e que também devem doar tempo.
- 57. O desafio 3 é convencer convencer convencer ...
- 59. Segundo resultado desta apresentação: É preciso reservar tempo e esforço em prol da melhoria contínua. Alguns podem discordar mas para mim isto não deve ocorrer só por parte da empresa. É preciso convencer o desenvolvedor a também fazer a sua parte.
- 60. Práticas que ajudam a diminuir o gap técnico da equipe e conduzem um iniciante ao conceito 10x
- 61. Relembrando programação pareada • Fred Brooks e Larry Constantine já falavam disto • Diminui o risco e evita o “truck factor” (Ceci Fernandes) • Resultado do código costuma ser mais legível • Ao contrário do que dizem, pode ser feito remoto • Gasta mais tempo. • Cansa mais a cabeça, nem todos suportam mesmo % / dia
- 62. Relembrando revisão de código • Brooks também citava • É uma prática aparentemente esquecida atualmente. • Além de diminuir o “truck factor”, é mais uma chance de descobrir defeitos • Parece funcionar melhor feito em grupo (ou par) • É mais fácil rever pequenos trechos de código em pequenas janelas de tempo
- 63. Relembrando compartilhamento de conhecimento, workshops, práticas de dojos, etc. • Atividades que exigem mais doação dos desenvolvedores do que da direção da empresa • Geralmente feitos fora do horário de trabalho • Em alguns casos contam com participação de desenvolvedores de outras empresas • Estimulam e dão oportunidade de afirmação aos que se oferecem para estudar e apresentar temas
- 64. Relembrando TDD, boa comunicação, etc. • TDD pode diminuir o medo do iniciante de fazer uma grande bobagem que acarrete muitas horas de debug • TDD facilita a revisão de código • TDD retira bloqueios do tipo “se está funcionando não mexe”. Bloqueios deste tipo inibem iniciantes • Boa comunicação é como uma plantinha que precisa ser regada todo dia. Nem sempre todos percebem o exato momento em que a comunicação começa a ter ruídos. O iniciante sofre mais com falha de comunicação
- 65. Terceiro resultado desta apresentação: Práticas populares do XP porém já recomendadas desde a década de 70, junto com ações de disseminação de conhecimento e mais TDD, permitem avaliar a produtividade e elevar o nível médio dos times. De quebra diminuem o risco de falha do projeto e ainda preparam a equipe para maiores desafios
- 66. E o tal programador 10x? Não há como medir a produtividade #fato Dizer que um vale 10 vezes o outro é chute Daí a definição arbitrária do programador 10x no início desta apresentação sem comparar com nenhum outro #constatação
- 67. Moral da história Se não podemos medir, não há como colocar números comparativos. O termo programador 10x significa ... apenas um bom programador (como definido).
- 68. ? luca.bastos@concretesolutions.com.br Você conhece um programador 10x? Obrigado