Como programador, ¿le importa qué método utiliza el proceso de desarrollo?

Estoy en el mercado laboral y tengo un conjunto de prioridades para mi próximo trabajo, incluyendo salario, línea de negocio, etc. Sin embargo, una cosa que no está en mi lista de requisitos es la metodología del proceso de desarrollo. Siento que mi trabajo es crear software y veo la estructura del proceso como algo que puedo adaptar, ya sea scrum o cascada o lo que sea.

¿Es la metodología del proceso de desarrollo una prioridad para usted?

Es importante para mí solo en la medida en que no obstaculice 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 alleste 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 tontas desde que tengo memoria, cualquiera que sea el problema que el procedimiento tonto para curar desapareció hace mucho tiempo.

Quiero lo siguiente de una empresa:

• Procedimientos claramente documentados que se ajustan en unas pocas páginas. Si tengo que leer una disertación o (peor) una novela para ponerme al día, me perderé por mucho tiempo.

• Evidencia de que la empresa está abierta a cambiar los procedimientos para mejor. Necesito poder hablar con alguien y decirle "Me doy cuenta de por qué lo estás haciendo [xyz], pero ahora hay una herramienta que hace la mayor parte de eso por ti. ¿Podemos usarla?"

• Un poco de competencia puede ser bueno y, a menudo, 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 comprometidas por día por el desarrollador a la impresora láser a las 5 PM, no quiero trabajar para usted.

• Si no ha evitado que las compilaciones en repositorios bendecidos reciban cambios que rompen dicha compilación, corro como diablos. Lo último que quiero hacer a las 5:00 es introducir cambios del repositorio principal para probar mi compilación local, solo para encontrarme 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 una sensación de familiaridad ayuda a superar el obstáculo inicial de tratar de ser productivo sin cometer un error de procedimiento.

Si veo que pasaré más tiempo resentiendo los procedimientos que agradeciendo que existan, probablemente pasaré el trabajo.

El otro rotundo "¡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 usar un SVN o algo así?" .

Alguien podría divertirse resolviendo eso. No soy ese chico :)

Como desarrollador, me importa que el proceso de desarrollo sea sensato. Varias metodologías de desarrollo diferentes pueden proporcionar un proceso de desarrollo sensato. Por el contrario, una empresa quebrada puede proporcionar un proceso loco, sin importar cómo lo llamen.

Por lo tanto, no me importa particularmente cuál es su "metodología de desarrollo" oficial. Sin embargo, todavía preguntaré sobre esto simplemente porque me da un contexto para hacer preguntas de seguimiento para descubrir qué están haciendo realmente .

Sí, he visto algunas metodologías pobres que no creo que quisiera repetir nuevamente. Como un par de ejemplos, considere estos: ¿Estaría bien con un estilo vaquero para un equipo de una docena de desarrolladores donde todos pueden usar su propio control de fuente, convenciones de codificación, etc.? Sé que no lo haría. ¿Qué tal dónde cambiar una línea de código? Hay una docena de formularios para completar y unas 20 firmas para aceptar el cambio en la producción que puede tomar semanas en realizarse, ya que la aprobación de la alta gerencia puede demorar un tiempo. El "lo que sea" deja las cosas un poco demasiado abiertas para mi mente, pero entonces tal vez soy un poco cínico aquí.

Como desarrollador, no me importa qué metodología sea, siempre y cuando sea la metodología adecuada, la utilizada correctamente.

Entonces, por ejemplo, no me gustaría trabajar para una empresa que hace "codificación de vaqueros" , especialmente si son lo suficientemente ignorantes como para pensar que realmente están haciendo Ágil .

Prefiero lugares que tienen un método de desarrollo que todos puedan seguir.

He trabajado en trabajos que fueron muy frustrantes debido a las opciones de proceso utilizadas para el desarrollo y los negocios en general. En estos días tengo algunos requisitos mínimos para el proceso. Cualquier negocio que no se involucre en esto, considero que está mal administrado y no funcionará. No tengo la paciencia para la idiotez que solía tener, así que me ahorro a mí mismo y a ellos mucho más al saltear esos trabajos.

Siempre que tengamos una cierta apariencia de requisitos razonables, algún representante comercial que sea comprometido y receptivo, y que comprenda que el equipo de desarrollo tiene una gran influencia en las escalas de tiempo, entonces estoy feliz y puedo encajar en cualquier cosa.