¿Por qué no podemos hacer nada?

9

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.

Tom W
fuente
55
¿Qué tan buena es la compañía para sacar el software que el cliente usa y le gusta? En otras palabras, ¿el equipo está obteniendo buenos resultados, a pesar del hecho de que usted no cree que el proceso sea estelar?
Robert Harvey
@Robert Harvey: es difícil para mí juzgar. Los productos son extremadamente específicos, y nosotros (los desarrolladores) recibimos mensajes mixtos. Por un lado, los nuevos clientes en los mercados innovadores están controlando el producto más de lo que originalmente imaginamos y, como consecuencia, encuentran fallas, lo que no parece importarles, ya que explicamos por qué y los solucionamos rápidamente. Por otro lado, algunos grandes clientes institucionales son desconfiados y estamos comenzando a criticarnos por enmendar repetidamente el modelo. El equipo de software es uno de los pocos puntos de equilibrio en la empresa en la actualidad, por lo que nos vemos bien en este momento .
Tom W
1
Solicitaría a los clientes la mayor cantidad de comentarios posibles para llegar a un acuerdo sobre un "modelo" de trabajo básico e intentar solidificarlo un poco. De hecho, puede ser frustrante para los clientes que un modelo cambie, pero si se trata de un software nuevo y de vanguardia, va con el territorio.
Robert Harvey
Buena pregunta. Me di cuenta de que incluso con una audiencia receptiva, el cambio real es difícil, a menos que puedas verlo funcionando en la práctica. Mi consejo es que primero intente enfoques para aumentar su productividad y luego los demuestre para el equipo. Con la práctica, puede ser más rápido en el desarrollo de TDD que escribir / depurar / repetir.
Mike B

Respuestas:

19

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.

Robert Harvey
fuente
Creo que tendrá que abordarlo desde una perspectiva de "deuda técnica". Cada empresa hace estimaciones de tiempo; suponiendo que los suyos ya son bastante buenos, comience a generar un excedente del 10% al 20% en sus estimaciones de tiempo para refactorización y capacitación, y manténgalo firme.
Robert Harvey
Continuar; El desarrollo iterativo es el nombre del juego, tienes razón. El problema es que la iteración se agota antes de que haya terminado porque los modeladores nos dicen vagamente acerca de si lo que hemos codificado es realmente correcto o no. Nadie puede identificar ningún error, así que lo que hemos hecho se envía. Seis meses después resulta estar equivocado. Me gustaría ser capaz de señalar que los modeladores necesitan tener criterios más firmes contra a prueba, pero de nuevo, no lo es su trabajo para decirlo?
Tom W
2
@Tom: siempre y cuando no insistas en las especificaciones comprobables de los modeladores, siempre pueden decirle a tu equipo que se equivocaron. Si van a responsabilizarlo por producir resultados de su modelo, debe responsabilizarlos por proporcionarle especificaciones comprobables para que pueda declarar el éxito. Cada especificación debería haber incorporado algún tipo de prueba "ir, no ir", para que usted y el cliente (o los modeladores) puedan acordar mutuamente que la prueba pasó, sin estar sujeto a interpretación.
Robert Harvey
Muy bien. Desafortunadamente, puede estar obligándome a admitir algo que no quería: que tenemos una falta de competencia. Es evidente en general, pero particularmente con los modelistas. Para algunos aspectos, insistimos en especificaciones firmes, y aún así termina mal. Son científicos, y hablando por experiencia, los científicos tienden a tratar el código como un experimento: corrija los errores a medida que avanza. Para el negocio, esto simplemente no es lo suficientemente bueno y es una cuestión de profesionalismo esperar que lo reconozca.
Tom W
No hay nada de malo en tratar el código como un experimento; eso es parte del proceso iterativo. Pero eventualmente tiene que llegar a "este código acepta estas entradas y se espera que produzca esta salida". Para eso están las pruebas unitarias; forman parte de la especificación. Puedo ver por qué quieres hacer TDD; fuerza las especificaciones en el código ... Pero necesita el apoyo de la cultura corporativa para que funcione, y TDD tiene un aire de "religión" al respecto. No todo es comprobable de esta manera, por lo que al final, es posible que tenga que vivir con cierto grado de incomodidad.
Robert Harvey
2

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

monstruo de trinquete
fuente
Eso es lo que he estado tratando de comunicar por algún tiempo. Resulta que los prototipos suelen ser valiosos y nos enseñan lecciones esenciales sobre la naturaleza del problema. Sin embargo, si esas lecciones se aprenden o no se dejan al azar, y la calidad de la implementación depende de que el desarrollador reconstituya los conocimientos adquiridos de su cerebro, en lugar de usar el prototipo para escribir la especificación. El desarrollador principal dice que lo último debería suceder, luego no se asegura de que así sea.
Tom W
cuando dice que quiere un prototipo, lo que quiere decir es que quiere una versión mínima de trabajo y lo más rápido posible. Esta será la base de la versión final. El problema con el enfoque es que los desarrolladores junior (en general) pueden escribir un buen código o pueden escribir código rápidamente, pero rara vez pueden hacer ambas cosas al mismo tiempo.
Kevin
2
Fred Brooks dijo "Escribe uno para tirar, de todos modos lo harás", eso es tan cierto hoy como lo fue hace 40 años.
mattnz
1

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.

Mike Dunlavey
fuente
1

¿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.

Michael Brown
fuente
"¿Has identificado a alguien en la compañía que" lo entiende "" LOL
Kenzo