Em um time de projetos utilizando a metodologia Scrum, seria um pouco “estranho” perguntar:

Qual o papel de XX departamento em um time de Scrum?

Afinal, em um time de Scrum o princípio é de que o time seja multidisciplinar, qual seria a dúvida por tanto?

Bom, talvez em empresas focadas em desenvolvimento de software ou em empresas de menor porte isso seja uma realidade, onde todos do time tenha suas preferências técnicas e sejam melhores em determinadas áreas que em outras, mas no final das contas todos fazem de tudo um pouco, desde html até codificação de EJBs no backend.

Em empresas cujo a herança seja o tradicional departamento/áreas, como: Qualidade (QA), Administração de Banco de Dados (DBA), Layout, Design, Usabilidade, etc….. fica praticamente impossível de se quebrar este paradigma, que na verdade está muito mais atrelado a vaidade dos departamentos (vaidade não no termo pejorativo, afinal, precisamos de especialistas) do que em quebra de paradigma propriamente dito, especialmente se a empresa for de médio a grande porte, afinal a primeira preocupação de quem não acredita/gosta de desenvolvimento ágil seria de medo, pois o status quo está sendo ameaçado. Claro!

Este post foi originado após uma conversa com um grande amigo meu, Fábio Brandão na noite do dia 01/01/2009, (pois é, viciado que é viciado só melhora após a terceira ou quarta linha de código compilado ) a respeito de alguns problemas com papéis/departamentos X Scrum, vou tratar neste post, um detalhe mais específico a respeito do Papel de QA (Qualidade) em um time de Scrum e as idéias que me perturbam a respeito.

Qualidade em Casa (QA em time de QA)

Fique claro que quando digo: papel de QA estou me referindo ao contexto que disse logo acima, onde existe um departamento de Qualidade e que o time de desenvolvedores não necessariamente faz o trabalho de QA.

Eu sempre trabalhei em empresas onde existia um time de qualidade verificando o sistema de forma manual ou automática, navegando pelo sistema, algumas vezes com uma planilha com os pontos de atenção, estes são os pontos que não poderia haver nenhuma fala, chamado risco 0 (risco zero), outra planilha com as novas features implementadas que não precisavam ter necessariamente risco 0, e uma terceira planilha com as issues, onde seria devidamente registrados os erros encontrados.

Após o programador (algumas vezes eu) sinalizar no sistema ou face-2-face que o desenvolvimento estava concluído, entrava em campo o pessoal da qualidade, agora lendo o documento que utilizei para desenvolver o sistema, retestando o sistema, testando as novas funcionalidades e apontando os erros, enquanto o programador (…..eu) já estava em um novo caso de uso, esse cara algumas vezes nem se lembrava mais do código do caso de uso passado, estava com foco total no novo caso de uso.

Passado algum tempo, o produto estava todo codificado e com vários bugs, logo, hora de corrigir os bugs.

Aqueles programadores que mal se lembravam o que haviam jantado na noite passada (provavelmente pizza, pois ficou até tarde na empresa, gerando mais algumas linhas de código sem testes) deveriam começar a corrigir os erros que eles mesmos causaram, que foram levantados pelo pessoal de QA. Agora com um documento mais “enxuto” que continham os erros encontrados.

Após a maratona de correções, com alguma sorte, o pessoal de Qualidade não encontrariam os mesmos erros quando executassem os testes novamente.

Qualidade em time de Scrum?

Acho que em um time de scrum a abordagem de QA em time de QA é totalmente fora de propósito, afinal a equipe de qualidade estaria fazendo apenas o papel de apurador de erros, seria realmente este o propósito de um time de qualidade? Encontrar erros?

Pensando em uma abordagem um pouco mais prática, ágil e proporcional aos excelentes técnicos que trabalham com qualidade, a tarefa devesse ser a de garantir a qualidade de produto como um todo, assim como um programador está apto a desenvolver: frontend, backend, testes unitários, integrados, modelagem de tabelas em objetos, QA deveria minimizar os problemas relacionados ao sistema como um todo, por exemplo: erros visuais, problemas técnicos relacionados a código não performático, erros de escrita em banco de dados, arquitetura, e também negócio.

O trabalho estaria terminado, se fossem encontrados erros nestas esferas.

Mas então o trabalho de QA seria apenas de encontrar erros no sistema? Seria aquele primo chato que sempre aparece quando menos se deseja?

O programador receberia com alegria a notícia de que seu código está errado? Ou que o código recém entregue não está performático?

Eu não acredito nisso, definitivamente eu acredito que esta já é uma evolução do “QA em time de QA”, mas acredito que esteja longe de ser uma boa abordagem.

Qualidade!

Como descrito acima, QA deveria ser um supertime, com:

• Arquitetos da informação, para assegurar de que os textos estão colocados corretamente;
• Webdesigners e Webmasters, para assegurar que o layout esteja de acordo como foi desenhado e implementado por eles e requisitado pelo Product Owner.
• Arquitetos de sistema, para assegurar que a aplicação esteja performática e que todas as regras corporativa para acesso a legados estejam sendo cumpridas.
• Programadores: para assegurar que o código está bem feito, com cobertura de X% de testes unitários, funcionais
• Analistas de negócio: para assegurar que o que foi pedido pelo Product Owner esteja de acordo com o que está sendo codificado.
• Administradores de Dados: assegurando que o modelo desenhado esteja coerente com os padrões da empresa e esteja normalizado
• Administradores de Banco de Dados

Com este super time de qualidade, acho que ficaria difícil justificar financeiramente este time.

Mas se o problema é dinheiro(falta de), o que fazer então?

Eliminar a qualidade do time?

De forma alguma!

Acredito cegamente que se o time, TODOS do time estiverem motivados, balizados com o que deve e o que não deve ser feito especialmente nas áreas em que não são especialistas o time deve servir de seus próprios QA’s.

Em um ambiente propício, onde existe motivação isso acontece de forma natural, onde um programador dá palpite no código do outro programador, o administrador de dados está disposto a alterar o modelo de dados para melhorar o desenvolvimento, o webdesigner trabalha de forma parceira com o programador para definir o que será retornado no JSON da chamada Ajax, o analista de negócio está ao lado do desenvolvimento alertando para os erros cometidos (ainda em tempo de desenvolvimento)

Em um ambiente como este será que é valido se quer o questionamento sobre o papel de QA em um time de Scrum?

Acho que não, pois todos estão AGINDO de forma a assegurar a qualidade técnica e não técnica da solução que está sendo implementada.

Talvez a pergunta correta desde o início desde post devesse ser:

Como motivar um time?

Isto será uma conversa para outro post, mas acho que resposta de forma bem curta seria…………….. Paixão!

PS: Utilizei o time de QA apenas para exemplificar, fica a critério do leitor substituir QA, por AD, DBA, Business, ou qualquer outro time que achar interessante.

No último dia 28 ministrei uma palestra para os alunos da UNIARARAS no II Encontro de Profissionais de TI foi muito legal mostrar para o pessoal um pouquinho de como trabalhamos com JEE e Scrum lá no UOL.

Para todos que se interessarem, a apresentação se encontra publicada no Slideshare e aqui no blog, fiquem a vontade de baixá-lo e replicá-lo!

É isso mesmo, eu não gosto de problemas, assim como eu não gosto de debugar aplicação, assim como eu nao gosto de ser acordado de madrugada porque o sistema parou de rodar o faturamento da empresa, assim como eu não gosto de ficar finais de semana corrigindo problema no sistema porque na segunda feira o pessoal da contabilidade tem que rodar o faturamento!

Não sou daqueles que acorda pela manhã e pensa:

Uau! qual será o problema do dia? Problemas de rede? Problemas com banco de dados? Problemas com a JVM?, hum……. bom mesmo se ocorresse todos eles de uma só vez!

Me lembro de algumas entrevistas, em que meus entrevistadores diziam:

Temos um ambiente desafiador, excelente para pessoas pró-ativas, determinadas a resolver os problemas, auto-motivadas…..

Bom, com o passar do tempo agente vai aprendendo ficando mais maduro quanto as promessas e passamos a interpretar algumas frases como a dita anteriormente como algo do tipo:

Temos vários sistemas cujo o pessoal que desenvolveu não está mais na empresa, os sistemas foram pouco testados por motivo de prazo e temos o caos na terra, precisamos de gente que tenha motivação suficiente para continuar levando o sistema até o fatídico dia em que já tenha ocorrido a depreciação por completo do sistema, e quem sabe se você ainda estiver na empresa quando isso acontecer, quem sabe, você possa utilizar tudo que aprendeu na manutenção deste sistema em um novo projeto.

Não sei para a maioria, mas pelo menos para mim, esta segunda frase soa menos amigável, mas muito mais sincera que a primeira.

Outra forma de “motivar” as pessoas nestas empresas são:

Fique tranquilo, com a quantidade de problemas que temos no sistema, temos emprego garantido para pelo menos 3 anos!

Acredito eu que algumas pessoas lendo este post já possa ter passado por uma situação dessas.

A triste notícia para os que não sao OP (orientados a problemas) é que pessoas que lideram os times OP tendem a investir tempo de menos em testes unitários, funcionais ou integrados e tempo demais em resolução de problemas quando o aplicativo já estiver em produção.

Dificilmente será possível se antecipar a problemas de produção, mas algumas dezenas deles já pode ser antevisto e em tempo de desenvolvimento da aplicação e mais, além de antevisto, podemos testar o comportamento da aplicação quando ( e se ) este problema ocorrer.

O recado aqui é simples:

Teste, Teste, Teste, Teste, Teste, Teste

Não se canse de testar, não se canse de criar cenários de teste para os de integração e aceitação, faça dos testes parte do desenvolvimento, algum tempo será consumido no desenvolvimento de teste, sim isto é verdade no entanto algo que é facilmente mensurável, é quanto de tempo será economizado em debugs, quanto será economizado na redução dos problemas em produção que podem acarretar em um prejuízo financeiro para empresa se isto ocorrer?

Motivação (Mais) para Testes

Faça dos testes unitários um exercício para o desenvolvimento, em um próximo post eu vou detalhar melhor os testes unitários, mas por hora, algo muito válido para ter uma boa motivação a respeito de testes unitários é que UT (unit tests) é tão interessante para o sistema quanto para você mesmo (desenvolvedor), com eles é possível modelar a estratégia de desenvolvimento da classe, serve como um exercício de barreiras para saber exatamente o escopo de onde a funcionalidade chega e onde é sua fronteira, mantendo o desenvolvimento KISS.

Faça com que a criação de testes faça parte do desenvolvimento, me lembro da frase do treinamento que tive de Scrum:

Done means…..

complete a frase com algo do tipo:

• …. não ser incomodado nos finais de semana
• …. não ter que acordar (ou não durmir) nas madrugadas para resolver problemas de sistemas

E a maneira mais simples de completar a frase é:

Teste! Teste! Teste! Teste! Teste! Teste!

English Version:

I don’t like problems! (EN)

It’s truth, I don’t like problems, I don’t like to debug application, I don’t like to wake up early (2AM or 3AM) because the billing application stops to process records. Like I don’t like to stay during all weekend solving problem becaus next mondey guys from billing will send invoice.

I’m not like that people who wake up morning and think:

Wow, what will be big problem today? Infrastructure? Database? Memory and JVM?….. that’s will be great if all those things happen together!

I remember som interviews, when the interviewers said:

We have a very motivated environment, excellent for who likes to solve problems and self-motivated….

Well, passing time we learn about this kind of “promisse”, it it automatic transformed to something like:

We have a system that the guy who created it are no longer on the company, the application was not well tested because we had a small time to develop and now we have a chaos on the earth. We need people who are self-motivated to continu to solve the problems on the application until the day that the company will says: The application is self-payed, we will invest on a new one. And maybe on this day, will could, use all your knowledge earned from mistakes on the application to develop the new one.

It is more sincere than the first phrase don’t you think?

Another way to “motivate”people is:

Stay calm, with all these bugs in the application, we have job for at least 3 years more!

The bad news for who are not PO (problem oriented) is that people who leader teams PO have tendency to inves less time on unit tests, functional tests and integrated tests and too much time in silving the problems (not the cause) when the application already be on production environment.

It’s not simple to foresee problems on production environment but, dozens of them we can foresee during development and more than that, we can test the behavior of the application if it happens in production env!

The message is simple:

Test, Test, Test, Test, Test, Test.

Don’t be tired to test, don’t be tired to create scenarios test for integration and acceptance. Some time will be consumed during development, yes this is truth but this is easy to calculate the cost, just to don’t let the application die during day, when it couldn’t stop.

Motivation (More) for Tests.

Make the creation of the unit test and exercise for development, use it for determinate the scope of the class, the development scope fof that functionality. Use it to discover if the functionality will not broken if you are the one who are changing some lines of code, and even if the functionality is following the KISS method.

I remember a training that I had with Boris Gloger about Scrum, and he said:

Done means….

complete the phrase with some like:

• …. don’t be bothered on the weekends
• …. don’t wake up dawn (or even don’t sleep) to solve problems on the application

And the best way to get it is:

Test! Test! Test! Test! Test! Test!

Nos últimos dois dias (28 e 29 de maio) tivemos um treinamento sobre Scrum / ScrumMaster com ninguem menos que Boris Gloger aqui em São Paulo, foi um evento fechado apenas para os funcionarios do UOL.

Estamos utilizando, a metodologia a algum tempo, por tanto já tinhamos conhecimento de várias táticas e organização de como as coisas devem funcionar, confesso que comecei o treinamento achando que ia ser apenas mais um falando sobre as mesmas coisas que é facilmente encontrado em livros.

Eu estava redondamente enganado, o treinamento foi extremamente dinâmico, com alguns exercícios práticos relacionado ao tema (claro!).

Boris foi extremamente focado, não repassou perguntas com respostas prontas do tipo: “You decide!”, “You tell me”, “What do you thing?”, pelo contrário, respondeu grande parte das perguntas com respostas práticas, sem rodeios.

Começando pelo começo, ele deu uma explicação resumida sobre, qual o papel do ScrumMaster:

- Break rules;
- Remove impediments for the team;

Também discursou sucintamente a respeito de Scrum, de forma mais resumida, mas muito direto disse:
“Scrum is not a silver bullet! Scrum is a good way to show the problems, but they will not be fixed by the methodoligy”

Foi apresentado uma breve explicação a respeito do fluxo do Scrum.

Como ele mesmo disse, ele adora metaforas, uma delas é que a melhor forma de transmitir a informação, é na forma de histórias, então, inclusive citou o Brasil como sendo o grande contador de historias do mundo, vendendo novelas para todo o globo, nós adoramos contar e ouvir hsitorias.

Falou a respeito do Manifesto Ágil, ainda nao convencido a respeito do valor do treinamento, eu achei que seria mais um bonito discurso sobre motivação, e mais uma vez eu estava completamente enganado.

Ele leu o manifesto e explicou a essencia deste, como é de conhecimento de muitos, alguns “bam-bam-bans” se reunirão para discutir nao sobre qual a melhor técnica ágil de desenvolvimento de software e sim, o que todas tinham em comum, o que todas pregavam como sendo os principais valores, e foi sobre estes valores que foi criado o manifesto ágil.

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Scrum Team, mais um conceito do que é o Scrum Team, entre todos os stakeholders que existem na empresa, nem todos fazem parte do Scrum Team, existe apenas 3 papéis:

• Product Owner

• ScrumMaster

• Team

Gerentes, Supervisores, Vendedores, Usuários finais, todos eles se nao estão inclusos em um dos ters papeis citados acima, não fazem parte do ScrumTeam.

Exercícios de Estimates, foram feitos inclusive clarificado muito bem a respeito de estimation:
“It’s not about the time, it’s about the complexity”

Responsabilidades, no inicio do dia 2, falamos a respeito de responsabilidades, ou seja, em cada etapa do processo, quem sao os responsáveis e quem são os responsaveis por dar suporte:

Nível estratégico
-------------------
- Visão            PO    TEAM
- Product Backlog  PO    TEAM
- Priorização      PO    TEAM
- Sizing           TEAM  SM
- Releasmanager    PO    TEAM

Nível Tático
-------------
- Sprint Planning 1     TEAM    PO
- Sprint Planning 2     TEAM    SM
- Daily Scrum           TEAM    SM
- Sprint Review         TEAM    SM
- Sprint Retrospective  TEAM    SM

Uma breve sugestão de como deve ser organizadas as reuniões dos Sprints

-------------------------------
            Sprint 1          |
---------|---|-------------|--|
         |   |             |  |
 Morning |SP1| Daily Scrums|  |
         |   |             |  |
---------|---|-------------|--|
         |   |             |RV|
 Evening |SP2|             |  |
         |   |             |RT|
-------------------------------

Alguns comentários:
- Ele não aconselhou fazer a Review Meeting na sexta feira, e sim na segunda feira, pois se algo der errado o time ainda tem o final de semana para acertar.
- A Retrospective tbem não é aconselhado, fazer na sexta feira, por motivos óbvios, especialmente por que o time nao estaria motivado suficientemente para uma conversa franca na sexta feira .

Daily Scrum, regra numero 1, não apenas do Daily, mas para todo o Scrum: “Time boxed” a Daily deve ser feita no mesmo lugar, todos os dias, no mesmo horário e nao pode durar mais que 15 minutos.
O principal envolvido é o time, a daily não é simplesmente de acompanhamento dos trabalhos pelo PO ou SM, e sim para o time, inclusive, a presença do SM não é obrigatória, como a do time é.
O SM ou o primeito membro do time não deve perguntar (como dito em várias bibliografias):

• What have you ACHIEVED since last meeting?

• What will you ACHIEVE before next meeting?

• What is in your way?

E sim:

• Who will start?

Claro, nas primeiras dailies, as perguntas devem ser feitas, mas durante o projeto, não é mais necessário, pois todo o time sabe o que deve ser dito na meeting, se ocorrer de alguem “esquecer” o que deve ser feito, basta colocar na parede as perguntas .

Monitoring the Sprint, formas de se monitorar o sprint, utilizando os graficos, que podem ser relacionados a progresso de tarefas, progresso de historias e quantos pontos do product backlog já foi “queimado”.

Scaling / Distributed Teams / Larger Scrum, bom este tópico merece um post só para ele, no entando de forma bem resumida, é posivel ter times em localidades diferentes, para evitar “guerra” entre os times, a idéia é misturar os times, ou seja, time1 com membros da localidade A e B time2 com membros da localidade A e B, assim evita a competitividade entre os times.

Fechando o treinamento fizemos um exercicio de 4 sprints, com cartas, baloes, dados e papel, muito interessante e “fun”.
“Fun” foi algo que o Boris fez questão de perguntar depois de todos os exercícios, “Was it fun?”, e o recado no final foi claro, sempre que o time se sente parte da solução e se diverte fazendo algo, a produtividade e qualidade será bem mais satisfatória para todos os envolvidor.

Após com tradicional comprimento “wulf”, nos tornamos os mais novos Certified ScrumMasters!

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Site: http://www.agilemanifesto.org/

Origem

• Inicialmente para fabricação de carros e produtos de consumo.
• Equipes pequenas e multidisciplinares (cross-functional)
• Desenvolvimento Iterativo

Características

• Backlog vivo de trabalho
• Entrega de um conjunto fixo do backlog com iterações curtas (sprints)
• Breve reunião diária de alinhamento e evolução (scrum)
• Breve sessão de planejamento para futuros sprints
• Retrospectiva onde os membros refletem sobre o sprint passado

Scrum Master = Facilitador, não é necessariamente o líder da equipe e sim a pessoa que facilitará o trabalho das demais.

Alertar que o problema não pode ser totalmente entendido ou definido, focando maximizar as habilidades da equipe para responder de forma ágil.
Simplificando

• Agende a demo do software 1 mês antes com o cliente
• Tome 1 mês para deixar o software pronto
• Use o feedback para conduzir os próximos sprints

Práticas

• Clientes se tornam parte da equipe de desenvolvimento
• Entregas freqüentes
• Discussões diárias com a equipe buscando responder as perguntas:
  
  
  • O que fez desde ontem?
  
  
  • O que planejo fazer até amanha?
  
  
  • Algo impeditivo para atingir o objetivo?
• Reuniões com os stakeholders
• Ninguém é penalizado por descobrir um problema
• Locais e horas de trabalhos devem ser energizados, nem sempre “hora extra” significa “maior produtividade”.

Obtidos em: Wikipedia

Resources

Livro sobre Scrum escrito por Ken Schwaber

Ferramenta: ScrumWorks

Como contratar bons programadores

Uma reclamação constante entre programadores é a (falta de) qualidade dos processos de seleção das empresas. Outra reclamação constante é das empresas, sobre a dificuldade de contratar bons programadores. Tentei separar aqui alguns pontos que eu acredito que podem melhorar um processo de seleção de programadores, tanto para empresa quanto para o candidato:

Pague um salário justo. É lógico que reduzir os custos é uma das metas de toda empresa, mas essa é mais uma tentativa de economizar que custa caro no médio prazo. A área de programação tem empregos à vontade para quem tem o mínimo de qualificação - sim, o mínimo é suficiente. Se você paga uma salário baixo, 10% de aumento é uma aumento ridículo em termos reais, o que faz com que uma empresa concorrente possa tirar um funcionário seu em uma fase crítica de um projeto pagando R$ 250,00 a mais. Normalmente as empresas pagam quanto o funcionário quer receber quando ele pede menos que o valor de mercado, e vêem nisso uma grande oportunidade - afinal, foi ele que pediu para ganhar esse salário. Com a internet, sua empresa não conseguirá esconder dele por muito tempo que o salário dele é baixo.

Não minta sobre as condições de trabalho. Ele pode descobrir isso rápido, enquanto ele ainda tem outras entrevistas em aberto. Você corre o risco de perder seu novo funcionário em algumas semanas, e ter que começar o processo de seleção novamente, pedindo pelamordedeus para que os candidatos que não foram escolhidos antes reconsiderem e façam uma nova entrevista ou negociação.

Mostre ao candidato que existe um canal aberto para negociações. Na maioria das vezes a forma mais fácil de ganhar um aumento é arrumar outro emprego e pedir mais. Se não der certo, pelo menos você não brigou com ninguém no seu emprego atual e tudo continua como estava. O risco é menor. Mostre que se ele pedir o dobro do salário e você falar não, isso não vai torná-lo um renegado, só será uma resposta negativa.

Evite testes teóricos longos. Isso é extremamente irritante e demorado, além de você arriscar perder o candidato. A última vez que resolvi mudar de emprego, eu estava fazendo entrevistas em duas empresa, uma na área de segurança da informação e outra na área financeira. Eu tinha preferência pela empresa de segurança, pois era a área que eu mais gostava e tinha mais experiência. Só que o processo seletivo da empresa de segurança era tão horrível (RH, dinâmica de grupo, lentidão, etc), que eu fechei com a empresa da área financeira. A entrevista foi rápida, focada na parte técnica e com a pessoa que seria meu gerente. Dei sorte, já que estou nessa empresa financeira até hoje e gosto muito de trabalhar aqui. Já a empresa de segurança perdeu um funcionário especializado numa área onde não é fácil encontrar profisionais.

Faça uma entrevista mais técnica. Reduza o contato dele com a equipe de RH ao mínimo necessário. Pode parecer um pedante da minha parte (afinal, sou um programador), mas se o candidato quisesse lidar com burocracia ele não seria um programador, teria outra profissão. Faça a primeiro a entrevista técnica, deixe as burocracias para depois. Você só vai conseguir que o candidato fique animado com a sua empresa depois que ele puder saber exatamente o que ele vai fazer, e o pessoal do RH não vai conseguir explicar. Imagine o diálogo:

- É framework 1.1 ou 2.0?
- Acho que é 2.0. É o mais novo, né?
- Sim é o mais novo. Você acessam o Oracle usando OLEDB ou usando o provider nativo?
- É… ã… Não sei.

O candidato vai se sentir muito mais a vontade conversando com outro programador.

Faça o candidato escrever código na entrevista. Nem que você tenha que contratar um programador free lancer só para fazer as entrevistas. Ele não vai codificar no trabalho? Como você sabe como ele se sai fazendo isso antes de vê-lo programando? Peça para ele fazer um programa pequeno, nada que tome mais do que 1:30hs.

Coloque um requisito não negociável no teste de codificação. Crie um requisito que não seja fazer o mais óbvio nem a melhor opção, só para descobrir o quanto o candidato é xiita e o quanto ele respeita o que está sendo solicitado. Exemplos:

• Obrigue-o a usar o Visual C++ 6, mesmo que ele prefira (e possa) usar o 8
• Obrigue-o a não usar generics em C# para manter compatibilidade com o .NET Framework 1.1
• Proiba-o de criar procedures e obrigue-o a colocar as consultas diretamente na aplicação

Você descobrirá logo a quantidade de chilique que você terá que aguentar quando pedir para ele fazer algo que ele não acredita ser o melhor, mas que é requisito do sistema por algum motivo de força maior. Um programador experiente explicaria que não é a melhor forma mas faria o que você pediu.

Faça a primeira entrevista por telefone. Uma primeira entrevista técnica por telefone ajuda muito para filtrar os candidatos não qualificados, com um custo mais baixo. Faça algumas perguntas técnicas básicas e faça que ele resolva algum problema simples, que não envolva escrever código diretamente. Exemplos:

• Como você organizaria uma rotina de backup e quais softwares usaria?
• Que containers da STL você usaria para controlar os usuários conectados em um servidor?
• Como você faria comunicação entre duas threads?
• O que é necessário para um objeto COM+ suportar pooling?
• Que módulos você precisaria para fazer um sistema de pedidos em C# usando MSMQ?
• Quais tabelas seriam necessárias para controlar o saldo e as operações de uma conta bancária?
• Se você trabalhasse em uma fábrica de canetas, como testaria uma caneta no controle de qualidade?

Não acredite cegamente em certificações. Faça o candidato escrever código e pergunte dos projetos que ele já participou e qual o papel dele nesses projetos. Pergunte como ele resolveu os problemas que apareceram durante os projetos. Uma certificação ajuda, mas não resolve, conheço um monte de programadores que têm certificação e são bons programadores, mas também conheço vários que têm certificação mas não conseguem fazer um sistema. Não limite uma vaga somente a profissionais com certificação, a não ser que a Microsoft/Sun/IBM/etc pare de te dar dinheiro por causa disso. Existem MUITOS profissionais bons que não tiraram certificação. E antes que perguntem, eu tenho 3 certificações (C++, C# e VB.NET) e elas são ótimas para encher lingüiça no meu curriculum, da parte técnica não me acrescentaram nada (lembrem-se: minha opinião, meu caso específico, muita gente aprende muita coisa estudando para tirar certificação).

Nada de grandes testes psicológicos ou dinâmica de grupo. Você não está contratando vendedores. Independente da discussão sobre a valia desses testes, você pode espantar bons candidatos. Um programador precisa saber se comunicar como qualquer profissional, mas ele muitas vezes nem terá contato com os clientes. Muitos bons programadores não são bons oradores ou negociadores, não é um requisito da profissão. Se você faz testes psicológicos para reduzir as possibilidades de contratar alguém que desestabilize a equipe e atrapalhe, mude sua estratégia. Contrate todos os bons técnicos que sejam sociáveis somente o suficiente para trabalhar. E comece a demitir mais. Isso mesmo, contrate o candidato, se ele atrapalhar ou for incompetente, demita-o. É mais fácil e sua equipe ficará muito feliz em saber que caso alguém entre para desestabilizar e atrapalhar, a empresa resolverá esse problema rapidamente.

Proporcione o básico: paz pra programar, um micro bom e um salário justo. É só isso que um programador quer. Muitos bons programadores não estão preocupados com planos de carreira ou possibilidade de cargos de gerência (um dos argumentos preferido das “meninas do RH”).

Não prometa nada que não possa cumprir, não use velhos truques. Talvez você consiga contratar um bom programador com promessas falsas, mas não vai conseguir mantê-lo por muito tempo.
Esse texto nao e de minha autoria, foi retirado do blog: 1bit