Problemas da equipe do SCRUM distribuído: o ambiente de trabalho

Uma questão interessante apareceu para mim hoje. Em uma equipe SCRUM distribuída, quando você começa a impor um ambiente de trabalho unitário em termos de formato de código, plug-ins IDE (checkstyle & co), VCS, CI? A equipe está em uma fase exploratória e o objetivo não é um código de qualidade da produção, mas sim uma prova de conceito. Não é uma sobrecarga impor algumas regras comuns de codificação "a priori" - antes que os membros da equipe decidam quais são realmente relevantes para seu trabalho futuro? O uso desse tipo de ferramenta é certamente um grande benefício, porque eles agem como uma heurística para minimizar a dívida técnica, mas aplicar regras como "sem espaços de fuga" que realmente quebram a construção de Jenkins parece para mim um exagero para uma fase que deve ser focada na formação de gelo do que na criação de código de produção.

Menção 1: os protótipos criados serão jogados fora

Menção 2: embora eu deseje que tudo seja feito desde o início - estou totalmente ciente de que isso não é 100% possível.

Eu acho que há três partes para o problema:

1. Você deseja economizar dívidas / dores de cabeça técnicas no futuro, aplicando boas regras agora.
2. Você não quer matar a velocidade da equipe, atolando todo mundo com regras desnecessárias.
3. Você não sabe exatamente as melhores regras para implementar, porque o projeto está em uma fase exploratória.

Eu tentei os dois extremos (de nenhuma regra, basta usar o mesmo controle de fonte, até uma diretriz de estilo de codificação de 20 páginas + muitos outros processos)

A única coisa que funcionou consistentemente é adotar o mínimo absoluto que sei que preciso e posso provar que preciso agora e revisar o processo regularmente . (Todo sprint na retrospectiva é um bom momento para fazer isso). Isso também inclui a remoção de quaisquer regras vestigiais.

Eu acho que isso realmente depende das equipes e quanto você se importa com o estilo de seleção. Concordo que devemos ter algum tipo de regra para evitar alguns bugs desnecessários. Mas algumas regras são mais irritantes do que produtivas. Eu acho que você tem que concordar com a equipe quais regras são necessárias e desnecessárias.

Definir trabalhos de Jenkins para estilo de verificação ou firebug também é bom, mas, novamente, você precisa concordar com o quão rigoroso deseja que seja. Estive em uma situação em que alguém quebrou alguma regra do estilo de verificação e impedimos que alguém cometa. A longo prazo, isso apenas irritará as pessoas. Novamente, se você disse que as pessoas não precisam prestar muita atenção, elas começarão a ignorá-las. Então, na minha equipe, concordamos que, desde que o trabalho de qualidade não seja muito prejudicado. Tem que ser azul antes do final do sprint.

Portanto, minha sugestão seria: timebox a reunião para que você não gaste muito tempo criando regras e discutindo sobre regras.

Alguns pensamentos, os IDEs modernos têm um plug-in de estilo de verificação para alertar as pessoas quando algumas regras forem violadas, a equipe pode concordar apenas em verificar durante a revisão do código antes de se comprometerem. Isso ajuda a minha equipe também.

• Qualquer IDE que não faça você se desenvolver mais rápido não é uma ferramenta, é uma âncora de barco. Jogue ao mar e nunca olhe para trás.
• Se você já possui uma infra-estrutura de IC, use-a a partir do dia 1. Agradecerá a si mesmo mais tarde, mesmo se você realmente conseguir lançar seu código de protótipo.
• Por outro lado, não perca tempo configurando um sistema de IC, se você não tiver um. O custo é muito alto e você realmente espera começar do zero.
• Comece com um VCS no dia 1. Período.

Sugiro começar a implementar o conceito de ambiente de trabalho unitário quando a velocidade da equipe começar a se estabilizar. Isso pode causar algum departamento técnico no início do projeto, mas sempre há um departamento técnico no início de qualquer projeto. :)

Normalmente, tenho sucesso ao permitir que o aspecto auto-organizacional de uma equipe invente algo que seja apropriado para eles e seus requisitos. Apresente basicamente à equipe uma descrição de um problema, como a falha de Jenkin Builds, e dando a eles a oportunidade de corrigi-lo.

Isso geralmente resulta em uma implementação mínima e simples de uma solução, assim como Zachary Yates mencionado em sua resposta.

Eu observaria que isso contaria a seu favor se você tiver alguém com um nível / posição de habilidade técnica sênior, fornecendo algumas orientações sutis, apenas para ajudar a equipe a não ficar estranha com o que eles decidem seguir. :)