Com certeza! É de se esperar que entre arranjar tempo pra gerir a equipe, ele também produza algo, alias, até mais que os novatos. Senão bye bye prazos.
[/quote]
Então me desculpe…
Com duas pessoas inexperientes o resultado deste projeto vai depender 99,999999999999% do tempo que o lider vai ter para desenvolver…
É impossivel coordenar uma equipe , aguardar resultados e ainda em cima produzir codigo de qualidade e coeso.
Se eu fosse o lider passaria alguns lapis de cor e algumas folhas em branco para os caras e pedia para eles ficarem desenhando e pintando o projeto todo…
INEXPERIENTE devem ser tratados como INDEXPERIENTES e não como “mão de obra disponivel”
Já passei por coisa parecida, e acho que quem caia nessa situação tá ferrado. A não ser que tenha uma gerencia compreensiva e prazos tranquilos.
A primeira equipe éra mesclada, havia gente sem experiencia e gente com experiencia apenas em manutenção, nunca havia monta um sistema desde o início; a situação éra bem conturbada pois havia muita cobrança e detalhe - Não foi eu quem escolheu os componentes. Comecei com algumas coisas de SCRUM / XP e começou a ocorrer muitas brigas em função da divergencia de opinião, alguns não queria ceder a idéia do outro e tava difícil e bem desgastante; a produtividade éra muito baixa em função do entrosamento ruim. Acabei adotando a arquitetura J2EE que eram o que eles sabiam mesmo sendo por leitura. Montei a proposta da infraestrutura do projeto apresentei à eles; foi aceita após algumas críticas e sugestões que logo depois foram incluidas gerando assim a primeira versão. Logo depois disto eles tinha o “esquema” de trabalho; cada um recebia um funcionalidade para desenvolver éra só pegar a máquina e começar a “fritar” os códigos.
Com isso eu fragmentei a equipe e acabei com as brigas e o dono do projeto conseguia fazer reuniões com cada um da equipe que estava cuidando de determinada funcionalidade, ele adorou o esquema se sentia o dono da bola; éra só mandar incluir uma funcionalidade e ZAZ um maluco já começava a ralar o peito em cima daquilo.
Bom, eu consegui resolver o projeto, mas internamente a coisa ficou ruim, havia muita redundancia de código, o sistema não éra nada otimizado. A equipe não evoluiu nada tecnicamente, sem falar que havia casos do desenvolvedor malandro, só ficava “embassando” e não rendia nada enquanto alguns se matavam. Eu não éra o líder de fato, eu era aquele cara que surge quando tudo esta perdido e a direção é apenas uma, o fundo do poço com muita força.
No outro projeto, no mesmo local, com alguns brigões fora da equipe e novos componentes afim de uma idéia diferente. Conseguimos adotar o XP e o projeto saiu muito melhor mesmo porque eu já tinha uma lista enorme do COMO NÃO FAZER para me basear.
Resumindo, a carga de trabalho e responsabilidade sempre cai em cima de quem sabe mais / está afim nesta hora. Se tiver sorte da equipe ser tranquila, saber discutir ideias, ser colaborativa etc… adote SCRUM / XP. Caso contrario e seu “coro” depender disso pegue o J2EE monta uma receita de bolo (BOLOVO rsrsrs) e bota os macaquinhos pra pressionar os botões quando eles estiverem mais adaptados vc tenta uma…outra coisa.
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.
[quote=Bruno Laturner]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.[/quote]
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.
[quote=chun]
Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?[/quote]
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.
[quote=Marcio Duran][quote=chun]
Alguem aqui bota sua corda no pescoco com iniciantes/amadores ?[/quote]
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.[/quote]
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”.
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.
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.
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.
[quote=Mero_Aprendiz]Bem, queria apenas deixar minha simples opinião.
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[/quote]
A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.
[quote=cmoscoso]
A principio definir diretrizes nao garante que elas serao respeitadas, alem de poder ter o efeito contrario de oferecer uma falsa sensacao de seguranca.[/quote]
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.
