Propietario de producto que exige horas extras para escribir pruebas unitarias. ¿Cómo puedo abordar esto?

Recientemente, comencé un nuevo proyecto en el trabajo (fue bueno sacudirme el crujido de un viejo proyecto y retomar uno nuevo) y mi equipo y yo estamos presionando más para lograr más prácticas de desarrollo profesional, que incluyen escribir pruebas unitarias. El propietario del producto no está tan impresionado, ya que, en opinión del PO, esto se traduce en un retraso en la entrega de funciones.

El PO (que también es el jefe de mi jefe, lo que genera un poco de conflicto de intereses en mi opinión) está muy molesto por un problema que se coló en nuestro producto de lanzamiento. Estoy señalando que un buen conjunto de pruebas unitarias habría detectado el problema (se necesitaron algunas refactorizaciones adicionales para lidiar con algunos errores de arquitectura de codificadores sin experiencia), y el PO no perdió tiempo en sugerir que "descubrimos cómo gastar algo de calidad". OT sobre la configuración de pruebas unitarias entonces". Nuestro cronograma ya está repleto de solicitudes de funciones y tiempo mínimo para corregir errores y otras tareas de mantenimiento requeridas.

No me inclino a ofrecer horas extras por algo que he aprendido a incluir como parte del proceso de desarrollo estándar en un equipo de profesionales. ¿Cómo comunico que la redacción de pruebas unitarias es una parte necesaria de la responsabilidad diaria del desarrollador? ¿Cómo puedo ayudar a evitar que mi equipo se desmotive cuando se les exigen horas extra?

PD, no sé cómo etiquetar esto, agradecería cualquier ayuda con eso también.

No estoy familiarizado con el término "propietario del producto". ¿Es este su cliente?
Posiblemente relacionado, ya que aborda un aspecto del problema: Workplace.stackexchange.com/questions/7095/…
@DavidK ¡Sí! Perdón por la ambigüedad. Esto es para referirse a la persona propietaria del producto que mi equipo está desarrollando.
@ 404usernotfound No soy un contratista, no estoy seguro de que su enlace ayude (aunque es una buena lectura, gracias).
@JoeStrazzere Soy el líder del equipo y hablo por mí mismo. Me gustaría poder evitar que otros también tengan que hacer horas extra, ya que proteger a mi equipo es parte de mi trabajo (que incluso disfruto).
¿El propietario de su producto sabe qué son las pruebas unitarias?
@Brandin Eso espero. Dediqué treinta minutos a detallarlos en la última reunión de planificación de sprint con la esperanza de comunicar el tipo de deuda técnica que podrían ayudar a salvar.
30 minutos no es suficiente exposición para que alguien asuma el valor que las pruebas unitarias aportan al proceso de desarrollo. Podría intentar mitigar su miedo explicando que no va a probar si el compilador, el tiempo de ejecución o el sistema operativo funcionan correctamente.
¿Qué conflicto de intereses podría haber en ser tanto el propietario del producto como el jefe del jefe?
@Hyperbole tuvo el mismo problema, mi equipo ya no escribe pruebas; simplemente no es posible sin molestar al jefe hasta el punto de ser despedido. Como han dicho otros, simplemente no los haga y cuando la deuda tecnológica comience a surgir, plantee el problema como una discusión para justificar por qué las pruebas unitarias son importantes.

Respuestas (2)

Dado que está utilizando el término propietario del producto, supondré que está utilizando Scrum (o un método relacionado). Si no, ignore esta respuesta por completo.

Si está utilizando scrum, el PO no determina cuánto puede hacer el equipo en un sprint, lo hace el equipo. Si necesita pruebas unitarias que lo ayuden a cumplir con la definición de hecho de la orden de compra, inclúyalas en sus estimaciones puntuales. En scrum, su programa no debe estar "lleno": solo puede obtener tantos puntos en cada sprint, y ese es su programa.

La OP debe establecer la prioridad en función del valor comercial obtenido. Si las correcciones de errores y la deuda técnica no son importantes para el PO, entonces no los pondrán en lo más alto de la lista de prioridades. Pero su equipo tampoco debe ser responsable de ellos. Si el trabajo cumplió con la definición de hecho de la orden de compra (y las pruebas de control de calidad deben incluirse en la definición de hecho), entonces hizo lo que se requería.

Su Scrum Master debe ser el que proteja al equipo tanto de la interferencia del PO como de la interferencia de los superiores, así que involúcrelos.

La definición de Listo de PO se ha negociado para indicar "desarrollo completado pero con control de calidad", en contra de mi buen juicio.
Luego, su Scrum Master debe asegurarse de que sea el PO, no el equipo, quien sea responsable de esa decisión.
@Kathy tiene la idea correcta. OP, debe educar a su jefe sobre por qué las pruebas unitarias son importantes para que él esté de acuerdo. En este momento, él no parece entender el valor de esto, la mejor manera de hacerlo es hacer su enfoque y cuando la deuda tecnológica se acumule, menciónele que es porque ustedes no están haciendo pruebas unitarias. Entonces será más probable que escuche.

Cuando determina el alcance o el tamaño de sus características, ¿desglosa las pruebas unitarias como parte de eso o es un elemento de línea separado? Le sugiero que haga que las pruebas unitarias formen parte de su proceso de desarrollo y luego analice las tareas en consecuencia, sin desglosarlas en el código. Esta función prueba esta función. Simplemente suponga que el esfuerzo de "codificar" una característica incluye escribir los casos de prueba.

Si se le pregunta por qué las cosas tienen un alcance más alto, simplemente indique que el proyecto está creciendo, cuanto más grande sea el proyecto, más funciones costará agregar. Podría informarle sobre TDD (desarrollo basado en pruebas), pero no creo que haga mucha diferencia. Por otro lado, si TDD es parte de su proceso de desarrollo, entonces está todo integrado y no es realmente una cosa separada, es solo la forma en que hace las cosas.

Si está haciendo Agile/Scrum, entonces el PO no debería dictar el cronograma de todos modos, solo debería priorizar y definir las características. Es el trabajo de su equipo darle una línea de tiempo. Si tiene que regresar y hacer algo de limpieza, entonces hay un argumento para el tiempo propio, pero es posible que desee negociar una cierta cantidad de tiempo de "Ingeniería". Donde trabajo ahora, hemos negociado que el 15% de nuestro tiempo se dedique a los esfuerzos de ingeniería. Estas son cosas que hemos identificado internamente como que necesitan arreglo. Podría ser una cuestión de rendimiento que no se nota demasiado ahora, pero que lo será pronto, o podría ser ese módulo que no se hizo bien la primera vez y necesita algo de cariño.

Hacer que UT sea un elemento de línea en una tarea es un riesgo práctico, el PO es muy resistente a cualquier cosa que no tenga un beneficio comercial inmediato y tangible. Incluso después de este defecto importante en un producto publicado, los beneficios de los UT no son algo que el PO esté dispuesto a escuchar.
Dijiste que 'desarrollo hecho' era parte de tu definición de hecho. UT es parte del desarrollo, son casos de prueba escritos por el desarrollador y debe ser parte de su definición de desarrollo, suponiendo que tenga una definición para eso. Es posible que deba presionar esto si desea que se incorpore, por lo que no está listo para el control de calidad hasta que pasen todas las pruebas unitarias. También es código, su PO claramente no entiende el desarrollo de software, así que buena suerte.
@Hyperbole En general, es mejor no mencionar las pruebas unitarias, pero tener una regla general en el equipo de que todo código nuevo o modificado debe tener suficientes pruebas unitarias para cualquier nivel de confianza que necesite y luego volver a estimar todo en función de eso. Sí, algunas historias o tareas que parecen simples de repente se volverán mucho más costosas si tiene que escribir las pruebas unitarias que deberían haber sido escritas previamente (o incluso más costosas si tiene que reescribir el código para que sea comprobable).
Pero ese gasto adicional ahora es el costo de salir de esto y pagar la deuda técnica. Si es realmente desagradable, puede hacer un poco de trampa probando insuficientemente los peores casos ahora, dejando agregar mejores pruebas para más adelante, pero debe seguir avanzando en hacer pruebas. ¶ Lo importante es evitar negociaciones de personas no técnicas sobre cómo escribir el código; el principio XP de que solo las personas que escriben código pueden tomar decisiones sobre cómo escribir código está diseñado expresamente para abordar este problema. Y eso incluye la cantidad de pruebas unitarias que realiza.
Propietario de producto que exige horas extras para escribir pruebas unitarias. ¿Cómo puedo abordar esto?
RespuestasAquíPolítica de privacidad1y, 0v