Estoy en el mercado laboral y tengo un conjunto de prioridades para mi próximo trabajo, incluido el salario, la línea de negocios, etc. Sin embargo, una cosa que no figura 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 a si es scrum o cascada o lo que sea.
¿La metodología del proceso de desarrollo es una prioridad para usted?
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 :)
Como desarrollador, me importa que el proceso de desarrollo sea sensato. Una serie de metodologías de desarrollo diferentes pueden proporcionar un proceso de desarrollo sano. A la inversa, una empresa rota puede proporcionar un proceso demente sin importar cómo lo llamen.
Por lo tanto, no me importa especialmente cuál es su "metodología de desarrollo" oficial. Sin embargo, aún lo preguntaré simplemente porque me da un contexto para hacer preguntas de seguimiento para averiguar qué es lo que realmente están haciendo.
Sí, he visto algunas metodologías deficientes que no creo que me gustaría repetir. Como un par de ejemplos, considere estos: ¿Estaría bien con un estilo de vaquero para un equipo de una docena de desarrolladores donde todos pueden usar su propio control de código fuente, convenciones de codificación, etc.? Sé que no lo haría. ¿Qué hay acerca de dónde cambiar una línea de código, hay una docena de formularios para completar y aproximadamente 20 firmas para aprobar el cambio en la producción que puede tomar semanas en completarse ya que la aprobación de la alta gerencia puede tomar un tiempo? El "lo que sea" deja las cosas un poco demasiado abiertas para mi mente, pero entonces quizás sea un poco cinético aquí.
Como desarrollador, no me importa qué metodología es, siempre que sea una metodología adecuada, se use correctamente.
Por ejemplo, no me gustaría trabajar para una empresa que hace "codificación cowboy" , especialmente si son lo suficientemente ignorante como para pensar que realmente están haciendo Agile .
He trabajado en trabajos que fueron muy frustrantes debido a las elecciones de procesos utilizadas para el desarrollo y los negocios en general. Estos días tengo unos requisitos mínimos para el proceso. Cualquier negocio que no se involucre en esto lo considero 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 una gran cantidad de molestias al saltarme esos trabajos.
Mientras tengamos algo parecido a los requisitos razonables, algún representante de negocios que esté comprometido y receptivo, y un entendimiento de que el equipo de desarrollo tiene una gran participación en los plazos, entonces estoy feliz y puedo encajar en cualquier cosa.
Lea otras preguntas en las etiquetas development-process