¿Por qué no podemos hacer nada?

Trabajo en un equipo pequeño, en una empresa mediana, la mayoría de los cuales no está involucrada en el desarrollo de software. Soy el desarrollador más nuevo y menos experimentado y no tenía experiencia profesional o académica en software antes de comenzar, pero estoy bastante satisfecho con lo respetada que es mi aportación y estoy agradecido por haber sido tomado en serio en una etapa tan temprana de mi carrera.

Aún así, siento que debería estar haciendo más con esta generosa cantidad de tiempo aire. Como equipo, parece que tenemos problemas para hacer las cosas. Me gustaría poder sugerir algo para mejorar la situación, y creo que me escucharían si fuera una buena idea, pero no sé qué sugerir.

Las cosas que puedo identificar como problemas incluyen:

• La especificación de las tareas en cuestión es escasa. Esto se debe en parte a que la administración es un cuello de botella y no tenemos el dinero o las personas para comprometerse a resolver los requisitos detallados tanto como nos gustaría. También se debe en parte a que el software que estamos desarrollando es de investigación y el método preciso no está claro hasta que se demuestre y se use para determinar su efectividad.
• Lead Dev es muy aficionado a lo que él llama 'creación de prototipos' hasta el punto de que recientemente comenzó a insistir en que todo está 'prototipado', lo que para el resto de nosotros parece escribir código incorrecto y dárselo a los modeladores para que jueguen. No está claro qué espera que salga de este ejercicio en muchos casos. La implementación 'real' sufre debido a su insistencia en que las buenas prácticas requieren demasiado tiempo para la creación de prototipos. Ni siquiera he comenzado a poder desenredar esta lógica retorcida y no estoy seguro de querer intentarlo.
• Se espera que los modeladores nos digan todo acerca de la metodología deseada con detalles precisos, y se asume con absoluta confianza que lo que ofrecen es teóricamente perfecto. Esto casi nunca es cierto, pero no se toman medidas para rectificar esta situación. Nadie en el lado del modelaje plantea inquietudes de una manera estructurada sobre la que se pueda actuar, ni buscan orientación para aplicar las mejores prácticas. Tampoco se hace nada con respecto a su pasividad.
• He intentado empujar a TDD en el equipo antes, pero me resultó difícil ya que es nuevo para mí y, aunque quienes supervisaron mi trabajo estaban dispuestos a tolerarlo, nadie más ha recibido entusiasmo. No puedo justificar la cantidad de tiempo que paso revolcando y no terminando funciones, por lo que la idea, por el momento, ha sido abandonada. Me preocupa que no se vuelva a recoger, porque a nadie le gusta que le digan cómo hacer su trabajo.
• Ahora tenemos un servidor de integración continua, pero en su mayoría solo se usa para ejecutar pruebas de regresión de varias horas. Se ha dejado abierto que también debería estar ejecutando la unidad de cobertura completa y las pruebas de integración, pero por el momento nadie las escribe.
• Cada vez que planteo el problema de la calidad con el desarrollador principal, obtengo una respuesta al efecto de 'La función de prueba A es sencilla, la función B es mucho más importante para el usuario pero demasiado difícil de probar, por lo tanto, no deberíamos probar la función UNA'. Una vez más, no he avanzado en tratar de desenredar esta lógica.

....Uf. Cuando lo digo así, se ve mucho peor de lo que pensaba. Supongo que, como resulta, este es un grito de ayuda.

Déjame jugar al abogado del diablo por un momento:

La especificación de las tareas en cuestión es escasa ... El desarrollador principal es muy aficionado a lo que llama 'creación de prototipos'

El desarrollador principal es aficionado a la creación de prototipos porque las especificaciones son escasas. Probablemente esto es algo bueno; así es como funcionan las tiendas iterativas.

Se espera que los modeladores nos cuenten todo sobre la metodología deseada con detalles precisos

Esto no funcionará en una tienda iterativa. La naturaleza misma del desarrollo iterativo es que los requisitos a menudo son incompletos. Las iteraciones son lo que se necesita para desarrollar los requisitos.

He intentado empujar TDD en el equipo antes, pero me resultó difícil ya que es nuevo para mí

Esto tampoco funcionará; necesita comprender la tecnología antes de poder evangelizarla. Además, en una tienda iterativa con pocos requisitos, TDD puede ser demasiado caro. Es mejor fomentar una cobertura adecuada de pruebas unitarias.

Ahora tenemos un servidor de integración continua, pero en su mayoría solo se usa para ejecutar pruebas de regresión de varias horas.

Eso puede ser apropiado en una tienda pequeña e iterativa.

Cada vez que planteo el problema de la calidad con el desarrollador principal, obtengo una respuesta al efecto de 'La función de prueba A es sencilla, la función B es mucho más importante para el usuario pero demasiado difícil de probar, por lo tanto, no deberíamos probar la función UNA'

Parece que su tienda tiene algunas limitaciones de tiempo bastante estrictas; te guste o no, estás obligado por esas restricciones.

También parece que proviene de una parte de la industria del software que valora hacer las cosas "de la manera correcta" en lugar de llevar las cosas al mercado primero. No hay nada de malo en eso (de hecho, es admirable), excepto que el primero en comercializar con un software defectuoso es a menudo el ganador. No es justo, pero así es como es.

Me voy a centrar en la creación de prototipos aquí

El problema principal con los prototipos es que están diseñados como prueba de concepto

sin embargo, si no puede construir más sobre el prototipo y necesita reconstruir el producto final desde cero, es posible que no haya construido el prototipo y haya perdido su tiempo construyéndolo

Mi consejo para su equipo es que obtenga cierta calidad y flexibilidad en esos prototipos. Sé que no es posible crear cosas perfectas la primera vez, pero trato de seguir siendo extensible para futuros requisitos

Estas son buenas respuestas. Solo puedo agregar que "tratar de comunicarse" es, en el mejor de los casos, una propuesta dudosa. Los cambios en la forma en que funciona una organización no se producen rápidamente. Cuando sucede, a menudo es como una marea, donde el impulso se acumula desde abajo y desde arriba. Por lo tanto, será más feliz si mantiene sus expectativas bajas y espera la oportunidad de decir cómo se harán las cosas o si desea trabajar con otra organización.

¿Ha identificado a alguien en la empresa que "lo entiende" si es así, prepárese de este tipo y aprenda lo más posible de él. Si no es así, espere su tiempo, comience a aprender y crecer por su cuenta (únase a un proyecto de código abierto o inicie su propio proyecto) y busque un lugar que pueda fomentar su crecimiento.

Lo peor que puede pasar es que te quedes allí y aprendas a hacer las cosas de manera incorrecta. Sí, debería tomarse un poco de pragmatismo, pero un equipo verdaderamente capacitado puede hacer las cosas de la manera correcta y aún así llegar a tiempo con un producto de calidad. Parece que su equipo actual no tiene lo que se necesita y debe comenzar a buscar uno nuevo.