Como lidar com a inexperiência?

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Bruno Laturner wrote:Por que nessas metodologias a equipe é formada por pessoas que sabem o que estão fazendo, de preferência que sejam especialistas na área, ou proxys para outros times. O objetivo é que elas agreguem valor com o conhecimento delas, que outros membros do time não tem.

Vejo isso como aprender a correr sem ter passado pela fase de engatinhar.

Por outro lado, pequenas partes dele podem ajudar. Por exemplo, XP é outro que não adotaria por inteiro, mas pair programming acho obrigatório. Assim como ter um padrão de codificação, ter releases poucos aos poucos.

Coisas bem fáceis mesmo.

Acho que o nível de exigência ai é de alto nível, não é possível que alguém que não tem a mesma cultura não possa compartilhar, existem ciclos no projeto mesmo sendo com um time de especialista enxuto, visto que saber o que esta fazendo no minimo onde ainda não aconteceu no projeto isso é teorizado antes de proceder, algo como alguém no minimo tem que fazer especificação, ou mesmo tenha que lidar com assunto que seja na ponta desse projeto, nada começa pelo no meio e termina, talvez migração mas ainda assim processos e especificações andam juntos.Outra coisa metodologia é o que vai se aplicar em fase de processo, mas um motivo para ter colaboradores mesmo esses vindo de outros projetos menores.

leandronsp wrote:

chun wrote:Já vi , e já tive alguns projetos afundados por inexperiência de programadores...

Hoje prefiro pagar mais caro a pegar programadores "cheirando leite"

Eu te digo, o resultado do seu trabalho é FRUTO da SUA EQUIPE...

Nao adinata você se esforçar ao maximo se a SUA equipe não acompanhar...

No final OU voce estoura todos os prazos possiveis e imaginaveis , ou vai apresentar um produto sem o menor nivel de coesão.

Os programadores iniciantes agradecem pela chance.

Programadores iniciantes não devem ter chance em projetos... a não ser que sejam projetos simples e sem muito impacto...

Me desculpe, é a mais pura realidade...

Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

chun wrote:
Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

Isso prova o quanto as pessoas não trabalham pelo processo ou sobre qualquer metodologia é pura intuição e praticidade pela sua mão de obra, provavelmente SCRUM é algo que ainda não atingiu maturidade nessas organizações, melhor dizendo nem sabem o que é isso.

Marcio Duran wrote:

chun wrote:
Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?

Isso prova o quanto as pessoas não trabalham pelo processo ou sobre qualquer metodologia é pura intuição e praticidade pela sua mão de obra, provavelmente SCRUM é algo que ainda não atingiu maturidade nessas organizações, melhor dizendo nem sabem o que é isso.

A questão é simples...

Com uma equipe imatura ou de amadores , não espere um resultado profissional...

Tem muito gerente de projeto aí achando que jogar duzias de programdaores inexperientes e cobrar resultados profissionais é algo "normal".

Para evitar isso a regra é simples...

Amadores devem fazer serviço de amadores.

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

s4nchez wrote:

Bruno Laturner wrote:
Que ações você adotaria para gerir essa situação?

Receitinha de bolo básica:

1. Pair programming pra difundir conhecimento
2. Code reviews para manter a qualidade do código
3. Retrospectivas para avaliar os pontos que precisam melhorar

perfeito!

PS: só complementaria com um item, código coletivo, se o Pair Programming for sempre feito isso acaba sendo automático

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

chun wrote:
A questão é simples...

Com uma equipe imatura ou de amadores , não espere um resultado profissional...

Tem muito gerente de projeto aí achando que jogar duzias de programdaores inexperientes e cobrar resultados profissionais é algo "normal".

Para evitar isso a regra é simples...

Amadores devem fazer serviço de amadores.

Se não temos profissionais colaboradores, temos um projeto cuja o dominio é de uma classe eletizada pelos seus interesses, é de responsabilidade da empresa dar treinamento e qualificar o profissional, mas isso é um estado ideal, na regra as coisas funcionam mesmo é no Hacker.

This message was edited 1 time. Last update was at 07/04/2009 10:42:05

A unica forma de lidar com inexperiencia é evitando-a! seja nao contratando programadores inexperientes, ou treinando-os ate que acumulem alguma experiencia.

Em qualquer projeto com prazos e objetivos reais é importante propiciar um ambiente controlado para a realizacao das atividades previstas, portanto vc deve incluir o treinamento como uma dessas atividades e assumir o fato que estara introduzindo ainda mais complexidade ao processo.

This message was edited 2 times. Last update was at 07/04/2009 10:58:56

Bem, queria apenas deixar minha simples opinião.

Bruno Laturner wrote:
Considere que um projeto normalmente vira um desastre quando programadores codificam sem pensar na arquitetura, reuso, etc, estas sendo as últimas preocupações deles.

Nessa situação, o que já vi algumas vezes, os arquitetos do projeto definiram muito bem o que deve, pode, e não pode ser feito. Por exemplo, deve usar o mesmo método para persistir, ou para aplicar a mesma regra de negocio, pode criar algo novo, desde que isso passe pela avaliação de um arquiteto e não pode codificar sem obedecer uma diretriz de programação (isso é ótimo para padronizar código).
Isso não é nivelar por baixo os seus desenvolvedores, mas sim garantir que as coisas tenham um norte na hora de codificar as coisas.
Como diria um amigo meu: Profissionais de elite trabalham para "mamãos" de alta performance.

[]'s
JL

This message was edited 1 time. Last update was at 07/04/2009 11:18:03

Mero_Aprendiz wrote:Bem, queria apenas deixar minha simples opinião.

Bruno Laturner wrote:
Considere que um projeto normalmente vira um desastre quando programadores codificam sem pensar na arquitetura, reuso, etc, estas sendo as últimas preocupações deles.

Nessa situação, o que já vi algumas vezes, os arquitetos do projeto definiram muito bem o que deve, pode, e não pode ser feito. Por exemplo, deve usar o mesmo método para persistir, ou para aplicar a mesma regra de negocio, pode criar algo novo, desde que isso passe pela avaliação de um arquiteto e não pode codificar sem obedecer uma diretriz de programação (isso é ótimo para padronizar código).
Isso não é nivelar por baixo os seus desenvolvedores, mas sim garantir que as coisas tenham um norte na hora de codificar as coisas.
Como diria um amigo meu: Profissionais de elite trabalham para "mamãos" de alta performance.

[]'s
JL

A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.

cmoscoso wrote:
A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.

A criação das diretrizes é para que os desenvolvedores tenham um norte. Um modelo de como fazer as coisas.
Claro que uma revisão de código é bem vinda.
E apenas mais uma coisa. Concordo com você que não garante que elas seram respeitas, mas é sempre bom lembrar que esse tipo de documento e norma da empresa (é sempre bom lembrar que desenvolvedor de softwares também é funcionário) o que deveria ser respeitado como qualquer outra norma, como conhecer a missão e a visão da empresa.
Se um desenvolvedor sabe das normas, e não se esforça para conhece-las e aplica-las, não deve ser um bom funcionario.

[]'s
JL

Notícias, artigos e o maior fórum brasileiro sobre Java