Es importante para mí solo en cuanto a no interferir con el sentido común que esperamos que la mayoría de los profesionales tengan.
Cuando hablamos de control de versiones, existe el argumento de que any version control beats not having anything at all
, este no es el caso con los métodos de desarrollo. Los métodos significan reglas, y las reglas a veces se rompen. He trabajado para compañías que han estado haciendo cosas realmente ridículas durante el tiempo que cualquiera puede recordar, cualquier problema que el procedimiento ridículo que curó desapareció hace mucho tiempo.
Quiero lo siguiente de una empresa:
-
Procedimientos claramente documentados que caben en unas pocas páginas. Si tengo que leer una disertación o (peor) una novela para estar al día, me perderé por mucho tiempo.
-
Evidencia de que la compañía está abierta a cambiar los procedimientos para mejorar. Necesito poder ir a alguien y decirle "Me doy cuenta de por qué estás haciendo [xyz], pero hay una herramienta que hace la mayor parte de eso por ti ahora. ¿Podemos usarla?"
-
Un poco de competencia puede ser bueno y muchas veces es inevitable. Pero, evitaré cualquier tienda donde la competencia se use como un medio principal para motivar a las personas. Si ha codificado algo que envía el número de líneas confirmadas por desarrollador por día a la impresora láser a las 5 PM, no quiero trabajar para usted.
-
Si no ha impedido que las compilaciones en los repositorios bendecidos reciban cambios que rompen dicha compilación, corro como si no. Lo último que quiero hacer a las 5:00 es introducir cambios desde el repositorio maestro para probar mi compilación local, solo para encontrar que estoy arreglando el punto y coma de otra persona.
-
Prefiero saltar a métodos que se asemejan a un método establecido que cayó del árbol ágil. No es obligatorio, pero un sentido de familiaridad ayuda a superar la joroba inicial de tratar de ser productivo sin cometer un error de procedimiento.
Si veo que dedicaré más tiempo a reenviar a los procedimientos que a agradecerles que existan, probablemente dejaré el trabajo.
El otro resonante "oh no, nunca más!" es "Esperamos que también establezca las mejores prácticas para nosotros. Tenemos seis millones de líneas de código y 21 teletrabajadores, ¿deberíamos utilizar una SVN o algo así?" .
Alguien podría divertirse un poco resolviendo eso. No soy ese tipo :)