tarea fundamental del rastreador: ¿Deberían estimarse las tareas o no?

Para dar un trasfondo, somos una empresa de automóviles web que tiene un portal de autos nuevos y usados, algo así como autotrader usa

Tenemos muchas deudas técnicas pendientes, es decir, mover nuestras páginas a una nueva tecnología de backend, actualizar las versiones de varios módulos de código abierto que hemos integrado, modularizar el javascript, etc.

El problema es, ¿debemos dar puntos a estos o no?

Por qué el equipo quiere puntos por tareas:

  1. Hay una gran cantidad de código heredado que, según el equipo, ahora debe considerarse como una característica, ya que la mayoría de los miembros del equipo nunca trabajaron en el momento en que se puso en producción este código heredado.
  2. Dicen que la velocidad mide "qué tan rápido entrega el equipo", ¿por qué no deberíamos contar cosas como explorar nuevas tecnologías como un marco de pruebas unitarias o un nuevo marco de interfaz de usuario como React, actualizar el software existente a versiones superiores, pasar a una mejor tecnología en la velocidad del equipo, ¿No son estas cosas lo suficientemente valiosas en el rápido mundo técnico?
  3. Muchas veces, PO sugiere adoptar un enfoque abreviado en lugar del enfoque técnico ideal, ya sea debido a la presión comercial o para ver rápidamente los resultados. Si el experimento tiene éxito, se debe hacer lo mismo de manera adecuada. Esta es la deuda técnica, ¿por qué no deberíamos contar esto en velocidad?
  4. Automatización del proceso de lanzamiento: esto no afecta la vida de los clientes, por lo que idealmente debería ser una tarea. Pero ahorra tiempo y dolor de cabeza al equipo. ¿Por qué no deberíamos darle puntos?

Por qué no se le debe dar puntos:

  1. Creo que si el equipo es lo suficientemente inteligente como para elegir las tareas correctas de vez en cuando, esto comenzará a aparecer automáticamente en velocidad en futuros sprints. Por ejemplo, si comienzan a usar un marco de prueba de unidad (hecho como una tarea sin puntos), en el futuro, habrá menos errores y el equipo podrá ofrecer más.
  2. Si un equipo tiene que entregar 300 puntos en los próximos 3 meses, y le piden a PO que liquide la deuda técnica en el primer mes, entonces el equipo estaría entregando 0 puntos en el primer mes. Pero el equipo debe elegir historias que eliminen todos los obstáculos técnicos para que el equipo ahora pueda entregar 300 puntos en los próximos 2 meses. Esto motivaría al equipo a elegir las deudas técnicas alineadas con el negocio y no cosas aleatorias para decorar su currículum.
¿En qué se diferencia su pregunta de Por qué Pivotal Tracker desalienta la estimación de puntos para errores y tareas? , y ¿por qué esta respuesta no ayuda en su situación?
@CodeGnome: la respuesta aceptada en este hilo solo analiza los errores. Mi pregunta es solo sobre la tarea y he dado múltiples situaciones para eso.

Respuestas (2)

La respuesta simple sería si el equipo está trabajando en un elemento, entonces debería estimarse. Como ejemplo, si el PO decidió ejecutar un sprint de deuda técnica, sin abordar características nuevas, al final del sprint, si se lanzó el software, ¿por qué no habría una velocidad para este sprint?

El trabajo es trabajo después de todo.

El único problema surge cuando un equipo técnico quiere actualizarse a una nueva tecnología... pero el PO no ve el valor en ello. A veces, está bien ejecutar código antiguo siempre que los procesos comerciales subyacentes se ejecuten y generen valor comercial. (Y el mantenimiento de la misma no es excesivo)

Así que dimensionaría las tareas, da un mejor reflejo de lo que el equipo está haciendo realmente durante un sprint.

Hay una escuela de pensamiento que dice:

No calcule correcciones de errores, tareas y picos.

Esto se debe a que los puntos solo deben otorgarse al trabajo que agrega valor al negocio.

Los desarrolladores deben recibir un incentivo para completar el trabajo más valioso. Obtienen elogios por quemar puntos de la historia porque esas historias representan un valor comercial directo.

Por el contrario, se les alienta a completar las correcciones de errores, las tareas y los picos lo más rápido posible, porque esas actividades no agregan valor directamente y no reciben tanto crédito por completar ese tipo de trabajo.

Se supone que hay una sana tensión entre el negocio y los desarrolladores, y este sistema lo formaliza.

Fuentes:

tarea fundamental del rastreador: ¿Deberían estimarse las tareas o no?
RespuestasAquíPolítica de privacidad1y, 0v