Problemas del equipo SCRUM distribuido: el entorno de trabajo

Un tema interesante apareció para mí hoy. En un equipo SCRUM distribuido, ¿cuándo comienza a imponer un entorno de trabajo unitario en términos de formato de código, complementos IDE (checkstyle & co), VCS, CI? El equipo se encuentra en una fase exploratoria y el objetivo no es un código de calidad de producción, sino una prueba de concepto. ¿No es una sobrecarga imponer algunas reglas de codificación comunes "a priori", antes de que los miembros del equipo decidan cuáles son realmente relevantes para su trabajo futuro? El uso de este tipo de herramientas es sin duda un gran beneficio porque actúan como una heurística para minimizar la deuda técnica, pero hacer cumplir las reglas como "no hay espacios de rastro" que realmente rompan la construcción de Jenkins me parece una exageración para una fase que debería centrarse más bien en el hielo que en la creación de código de producción.

Mención 1: los prototipos creados serán desechados

Mención 2: aunque deseo que todo se haga desde el principio, estoy totalmente consciente de que no es 100% posible.

Creo que el problema tiene 3 partes:

1. Desea ahorrar deuda técnica / dolores de cabeza en el futuro mediante la aplicación de buenas reglas ahora.
2. No quieres matar la velocidad del equipo empantanando a todos con reglas innecesarias.
3. No conoce exactamente las mejores reglas para implementar, porque el proyecto se encuentra en una fase exploratoria.

He intentado los dos extremos (desde ninguna regla, solo use el mismo control de fuente, hasta una guía de estilo de codificación de 20 páginas + muchos otros procesos)

Lo único que ha funcionado consistentemente es abrazar el mínimo absoluto que sé que necesito y puedo probar que necesito ahora, y revisar el proceso regularmente . (Cada sprint en la retrospectiva es un buen momento para hacerlo) Esto también incluye eliminar las reglas de vestigio.

Supongo que esto realmente depende de los equipos y de cuánto te importa el estilo de control. Estoy de acuerdo en que deberíamos tener algún tipo de reglas para evitar algunos errores innecesarios. Pero algunas reglas son más molestas que productivas. Supongo que debes acordar dentro del equipo qué reglas son necesarias e innecesarias.

Establecer trabajos de Jenkins para checkstyle o firebug también es bueno, pero de nuevo tienes que estar de acuerdo en lo estricto que quieres que sea. He estado en una situación en la que alguien rompió alguna regla de estilo de verificación y evitamos que alguien se comprometa. A la larga, solo molestará a la gente. Nuevamente, si dijiste que las personas no tienen que prestar mucha atención, comenzarán a ignorarlas. Entonces, en mi equipo, estamos de acuerdo en que, siempre y cuando el trabajo de calidad no esté mal roto. Tiene que ser azul antes del final del sprint.

Por lo tanto, mi sugerencia sería programar la reunión para que no pase mucho tiempo creando reglas y discutiendo sobre reglas.

Algunas ideas, los IDE modernos tienen un complemento de estilo de verificación para alertar a las personas cuando se rompen algunas reglas, el equipo puede acordar verificar solo durante la revisión del código antes de comprometerse. Eso también ayuda a mi equipo.

• Cualquier IDE que no te haga desarrollar más rápido no es una herramienta, es un ancla de barco. Tíralo por la borda y nunca mires atrás.
• Si ya tiene una infraestructura CI, úsela desde el día 1. Se lo agradecerá más tarde, incluso si realmente logra desechar su código prototipo.
• Por el contrario, no pierda el tiempo configurando un sistema de CI si no tiene uno. El costo es demasiado alto, y realmente espera comenzar de cero.
• Comience con un VCS en el día 1. Período.

Sugeriría comenzar a implementar el concepto de un ambiente de trabajo unitario una vez que la velocidad del equipo comience a estabilizarse. Esto puede causar algún departamento técnico al comienzo del proyecto, pero siempre hay un departamento técnico al comienzo de cualquier proyecto. :)

Por lo general, tengo éxito al permitir que el aspecto de autoorganización de un equipo presente algo que sea apropiado para ellos y sus requisitos. Básicamente, presente al equipo una descripción de un problema, como la falla de Jenkin Builds, y bríndeles la oportunidad de "solucionarlo".

Esto generalmente resulta en una implementación mínima de una solución, tal como Zachary Yates mencionó en su respuesta.

Me gustaría señalar que contaría a su favor si tiene a alguien de un nivel / posición de habilidad técnica superior que le brinde una guía sutil, solo para ayudar al equipo a no volverse extraño con lo que deciden. :)