• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile br2011 lucabastos-prog10x-noiteagilcaelum
 

Agile br2011 lucabastos-prog10x-noiteagilcaelum

on

  • 716 views

Apresentação feita na Caelum na Noite Ágil de 09/08/2011

Apresentação feita na Caelum na Noite Ágil de 09/08/2011

Statistics

Views

Total Views
716
Views on SlideShare
716
Embed Views
0

Actions

Likes
1
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile br2011 lucabastos-prog10x-noiteagilcaelum Agile br2011 lucabastos-prog10x-noiteagilcaelum Presentation Transcript

    • Como formar um programador 10x Luca Bastos luca.bastos@concretesolutions.com.br Noite Ágil - Agosto/2011 Caelum SP
    • 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
    • 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.
    • 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 leanstartups de tecnologia. Praticamos e pregamos o desenvolvimento ágil desde 2007.Hoje temos 56% do faturamento usando Scrum e Kanban esó 12% de projetos fechados.  
    • “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
    • Arbitrariamente vou definir um programador 10xcomo aquele que sem ser gênio, tem pelo menosum 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)
    • Veremos o que fazer para elevar o nível de um programador iniciante e como criar condições de um dia ele vir a serum programador 10x.
    • Você conhece um programador 10x?
    • Melhor dizendo, reconhece um programador 10x?
    • Você contrataria alguém como os personagens das fotos seguintes?
    • Ops... Desculpa aí Milfont ...
    • Origem do meu interesseno tema da apresentação Ligue djá
    • Segundo o prof. Robert Glass, no livro de 2002Facts 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.
    • A diferença de produtividade entre programadoresjá foi motivo de preocupação de estudiosos como Bohem, De Marco, Spolsky e outros.
    • 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, WhatReally Works, and Why We Believe It, O’Reilly 2011
    • 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
    • Segundo o mesmo McConnell (*), o tal estudo tem falhasporque compara resultados de programadores usandolinguagens de baixo nível com outros usando linguagensde 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
    • Porém McConnell (*) repara que a diferença entreos melhores e os piores pode ser considerada como10x Tempo para “codar” 20x Tempo para debugar Tamanho do código Tempo de execução do código 10 X 25x 5x 10x
    • Escolhi usar o termo 10x porque meu conceito de10x está mais para os bons que podemos formar do que para os pontos extremos excepcionais que poderiam ser os tais 28x.
    • 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:
    • 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 10xem menos tempo
    • #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é onível médio da equipe
    • Desafio número 1: Dar condições para o iniciante virar bom programador continuando sendo um ser humano (sem arrogância).
    • Opinião do Joel Spolsky:Contrate um super star caso queira um produto acima da média.
    • Mas todo mundo conhece um super programador que ninguém quer na equipe.
    • 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.
    • Desafio número 2: Reconhecer os melhores.
    • E como reconhecer os melhores? a) Medindo a produtividade?   b) Existem outros meios de reconhecê-los?
    • Medir a produtividade Será fácil fazer isto?
    • Linhas de código? Mas programadores espertos produzirão mais  escrevendo códigos mais longos Lembrando Dilbert: você obtem o que mede
    • Pontos de função?  Mas código ruim não gera mais pontos de função.  
    • Número de histórias prontas? Mas e a complexidade diferente de cada uma?
    • Então não consigo medir a produtividade? Para mim a resposta é não. Parece até perda de tempo tentar. Concordo com Martin Fowler emhttp://www.martinfowler.com/bliki/CannotMeasureProductivity.html
    • Então como saber se um programador já é 10x? Se não se pode medirQuais serão então os tais outros meios?  
    • Minha resposta:  acompanhamento dia a dia  
    • Para nossa sorte,  os meios de acompanhamento úteis para reconhecer um programador 10x
    • São exatamente os mesmos  que possibilitam conduzir um iniciante  ao conceito 10x
    • - Programação pareada - Revisão de código  - Compartilhamento de conhecimento,workshops, práticas de dojos, etc.  - TDD, boa comunicação, etc.
    • Primeiro resultado desta apresentaçãoNão é possível medir a produtividade dos programadores mas se pode avaliar cada um por meio de  acompanhamento frequente.
    • Esta página foi intencionalmente deixada em brancopara que você pense no dia a dia do seu projeto
    • 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.
    • 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?
    • Considerando que uma boa parte dos desenvolvedores trabalha alocado nos clientes,e que dentro do ambiente deles dificilmenteconseguimos tempo no projeto e espaço físico ideal,só pode ser pegadinha do Malandro falar destas práticas.
    • 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
    • Blog do @sumeet_moghe http://www.learninggeneralist.com/2011/08/spatial-serendipity-key-to-social.html
    • Blog do @sumeet_moghe http://www.learninggeneralist.com/2011/08/spatial-serendipity-key-to-social.html
    • Nosso ambiente na Concrete SP
    • Muitas vezes por pressões dos clientes ou peloexíguo time to market do produto, é difícil subtrairtempo 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”
    • Desafio número 3 (este sim o mais difícil) 1. Convencer os gestores das empresas daimportância destas práticas. 2. Convencer os clientes que produto feito sobencomenda só será bom e atualizado, se estiversob um processo de melhoria contínua. Portanto é preciso reservar tempo para isto. 3. Convencer os desenvolvedores de são eles osbeneficiados e que também precisam doar tempo.
    • O passo 1, ao contrário do que dizem, costuma sero menos difícil:  convencer os chefes. E eles tem acesso e mandato para convencer nossos clientes.
    • 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.  
    • O desafio 3 é convencer convencer convencer ...
    • 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.
    • Práticas que ajudam a diminuir o gap técnico daequipe e conduzem um iniciante ao conceito 10x
    • 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
    • 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 dedescobrir defeitos•  Parece funcionar melhor feito em grupo (ou par)•  É mais fácil rever pequenos trechos de código empequenas janelas de tempo
    • Relembrando compartilhamento de conhecimento, workshops, práticas de dojos, etc. •  Atividades que exigem mais doação dos desenvolvedoresdo 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 seoferecem para estudar e apresentar temas
    • Relembrando TDD, boa comunicação, etc. • TDD pode diminuir o medo do iniciante de fazer umagrande 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 serregada todo dia. Nem sempre todos percebem o exatomomento em que a comunicação começa a ter ruídos.O iniciante sofre mais com falha de comunicação
    • 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
    • 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 10xno início desta apresentação sem comparar com nenhum outro #constatação  
    • 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).
    • ? luca.bastos@concretesolutions.com.br Você conhece um programador 10x? Obrigado