Qual desses é mais importante? Equipe qualificada ou boa prática de processo?
Quando digo habilidoso, quero dizer membros lógicos e criativos com boa capacidade de codificação e teste. Bom processo seria a metodologia de desenvolvimento, como ágil, scrum, etc
Se a sua equipe não é habilidosa (como na sua definição), você não conseguirá fazer nada. Neste caso, o processo não importa.
Não há habilidade no sentido de pouca experiência seria outro assunto. Se o seu pessoal é talentoso, mas não tem muita experiência com projetos, um bom processo pode ajudar a evitar problemas. Testes e respostas antecipadas de clientes, como o Agile, provavelmente evitariam muitos problemas em tal situação.
Uma equipe qualificada é mais importante.
Uma equipe sem habilidades com todos os processos certos falhará. Se você não acredita em mim, traga seus processos ágeis / scrum para um departamento diferente (digamos, contabilidade) e veja se eles podem fazer um bom software!
Seu processo de desenvolvimento é tão bom quanto o link mais fraco , então ambos são importantes.
Uma boa equipe que tem um processo desastroso infligido a eles, que sufoca o desenvolvimento ao invés de facilitá-lo, pode acabar menos produtivo do que uma equipe de pobres desenvolvedores ajudados por um bom processo (já vi isso acontecer).
Na minha experiência, no entanto, bons desenvolvedores tendem a gravitar em direção a um fluxo de trabalho mais eficiente, se eles tiverem a autonomia para fazer isso. Ineficiências ou burocracia sem sentido tendem a ser impostas de cima, então um bom gerente / líder de equipe pode ser crítico para evitar que as equipes sejam sufocadas pelo processo.
Outro ponto é que mudar uma equipe é algo que leva tempo, enquanto mudar um processo geralmente é algo que você pode fazer a qualquer momento.
Em peopleware , Tom DeMarco e Timothy Lister falam muito sobre como colocar as equipes em gel , falando sobre crescimento de equipes, em vez de construí-las . Diferentes processos podem colocar barreiras nas equipes gelling ou podem incentivar a equipe a crescer, o que é uma consideração ao desenvolver um processo.
A otimização de um fluxo de trabalho pode ser um processo contínuo, no entanto - problemas ou ineficiências no processo podem ser discutidos e resolvidos à medida que você avança. Se eles funcionam, você pode procurar outras maneiras de melhorar o seu processo, se não, você pode voltar ao modo antigo. Você só precisa ter em mente que o processo é um meio para um fim, não um fim em si .
Em seu ponto final, somente você e sua equipe podem determinar se o Scrum, ou qualquer outra metodologia, atende às suas necessidades. Se você estiver trabalhando em um ambiente de strong queda, a introdução de técnicas ágeis pode apenas causar atrito com outras equipes com as quais você precisa interagir. Da mesma forma, se outras equipes estiverem usando o Scrum, você pode descobrir que adotar isso pode ajudar a interação com essas equipes.
Acho que as pessoas estão perdendo um ponto aqui.
Existe um nível básico de competência que é essencial nos membros da equipe - se você não tem esse nível, então sim, há um problema - no entanto, a questão torna-se o que alguém entende por "hábil". essas pessoas adequadamente competentes como habilidosas?
Se o ambiente e os processos forem bons, esses desenvolvedores competentes oferecerão uma equipe de indivíduos mais qualificados, sem bons processos, porque não trabalharão juntos.
Todo mundo vai à procura de "rockstars" e "ninjas", mas não é isso que a maioria de nós é - bons processos são fazer com que o resto de nós trabalhe com o melhor de nossas habilidades
Como outros apontaram, nenhuma quantidade de processo vai compensar completamente uma equipe que não tem habilidades. No entanto, irá de alguma forma melhorar as coisas. Por exemplo, mas com um processo em andamento que requer que os testes sejam escritos e os testes a serem aprovados, você garantirá que o código produzido produza (até certo ponto).
No entanto, um processo bad pode arruinar os esforços dos desenvolvedores mais altamente qualificados se você permitir que atalhos sejam utilizados e que um código não testado seja liberado (por exemplo). Com isso, quero dizer que, se as pressões da gerência / vendas etc. forçarem os desenvolvedores a contornar as boas práticas, o processo será quebrado. Um bom processo tem que ser aquele que a gerência compra e reconhece e honra.
Habilidades e processos são complementares. Sem você não pode produzir código de qualidade.
Somente ter boas práticas, sem trabalhadores qualificados, é semelhante ao de 1 milhão de macacos em 1 milhão de máquinas de escrever que escrevem todas as grandes obras ... Já vi muitas empresas terceirizadas que usam seus [CMM / ITIL / Ágil / qualquer coisa] pratica com desenvolvedores que não conseguiram se programar em uma embalagem de papel figurativa.
Minha resposta é baseada em algumas suposições
O medo de que um processo que seja muito rígido impeça a equipe de contratar ou manter desenvolvedores altamente qualificados? Ter um processo prejudica a criatividade, a flexibilidade e a entrega no prazo? E se for esse o caso, é um processo ruim ou que precisa de algum ajuste?
Um processo estruturado pode facilitar a manutenção de desenvolvedores menores ou aqueles com tendência a serem descuidados na fila. Bons processos, por definição, são os que retornam os melhores resultados.
Um desenvolvedor "altamente qualificado" que não pode trabalhar em sua equipe ou em seu processo para todos os fins práticos não é especializado. Pessoas qualificadas entregam resultados no contexto dos requisitos. Eu não tenho certeza de quão longe eu estaria disposto a abandonar os padrões para apaziguar algum autoproclamado, guru, prima donna, estrela do rock, ninja, todas as estrelas. Remo mais rápido do que todo mundo no mesmo barco pode ser contraproducente.
Como pessoas técnicas, temos a tendência de julgar as coisas com base em seu mérito técnico. Nossa definição de "importante" é que o software é criativo, elegante e interessante. A definição de "importante" de uma empresa é que o software tem um efeito positivo na receita da empresa. Ter membros qualificados é mais importante pela primeira definição. Ter um bom processo é mais importante pela segunda definição. No entanto, um ser mais importante não implica que o outro seja totalmente sem importância .
O ponto principal da Agile é que o processo deve se ajustar rapidamente para atender às necessidades da empresa e dos desenvolvedores. Se você está fazendo certo, geralmente é benéfico para ambos, mas leva um pouco de tempo para se adaptar. Se você está tentando impor alguma versão ideologicamente "pura" de ágil, você terá problemas.
Tentar implementar um processo perfeitamente é definitivamente a coisa errada a se apontar. O objetivo deve ser criar um software útil, o processo é apenas algo que ajuda você a atingir esse objetivo. Se você alguma vez sentiu que isso realmente está atrapalhando você, você precisa mudar isso (e toda boa descrição do processo enfatiza esse ponto).
Eu acho que para ter sucesso no desenvolvimento de software você precisa ter uma equipe competente e um bom processo. Mas uma equipe competente com um bom processo vai superar uma equipe de especialistas sem nenhum processo (é claro que verdadeiros especialistas não trabalhariam dessa maneira e quase nenhuma empresa tem uma equipe inteira de verdadeiros especialistas). Desenvolvedores incompetentes sem processo são os piores de todos os mundos possíveis. Então, realmente o que você precisa comparar é um bom processo e desenvolvedores competentes e um processo fraco e desenvolvedores competentes e, nesse caso, o bom processo vencerá.
Eu classificaria eles dessa maneira
Agora, o verdadeiro problema está em definir desenvolvedores competentes e bons processos. Um processo formal não é necessariamente bom (veja a cascata) e um desenvolvedor com dez anos de experiência também não é necessariamente bom.
Scrum pode ser um bom processo em um aplicativo legado, também pode ser um processo ruim, o diabo está nos detalhes.
Já existem muitas boas respostas aqui, e por isso não vou tentar responder de forma abrangente à pergunta em todos os aspectos possíveis. Meu próprio julgamento sobre esse assunto dependeria bastante de quão difíceis são os problemas que você está tentando resolver. Isso é óbvio, suponho; Se o seu problema é suficientemente avançado, você precisa de programadores criativos, capazes e perspicazes. O processo não é um substituto. Mas se a sua dieta de projeto é monótona, você certamente pode construir um ambiente onde os desenvolvedores seniores que você tem podem treinar os inexperientes, e você pode usar alguns processos de desenvolvimento de software para fornecer uma estrutura de suporte para que isso aconteça. Contanto que você tenha, talvez, > 50% de desenvolvedores qualificados, será possível fazer com que o projeto avance e desenvolva as habilidades de sua equipe ao mesmo tempo. Isso pressupõe que "hábil" inclui ter algumas habilidades de coaching e, claro, isso nem sempre é verdade.
Com certeza dada uma escolha, eu estabeleceria um piso de habilidades relativamente modesto; Assume apenas desenvolvedores que já trabalharam na manutenção de uma base de código existente com sucesso. Grinding software de porcaria é fácil. Manter uma base de código existente por um período produz insights vitais sobre como criar um bom software.