¿Qué elementos de trabajo se verían relacionados con el soporte para una solución que ya está en producción?

Nuestro taller continuará con el mantenimiento de un sistema que ya está en producción. Nuestra próxima actualización consiste en corregir un error y crear documentación para que los nuevos miembros que se unan a nuestro equipo puedan entender el sistema. No sé cuáles deberían ser los elementos de trabajo, ya que tenemos un nuevo Team Foundation Server (con plantilla de Scrum) y los superiores quieren que se realice un seguimiento de todo el trabajo en él. ¿Algo como esto funcionaría?:

  • Epic: soporte y actualizaciones del sistema "Echo" de gestión de relaciones con los clientes.
  • Característica: Actualizaciones del sistema.
  • PBI: 1. Como administrador del sistema, quiero comprender el sistema por completo para poder brindar innovación y soporte.
  • Error: 2. No hay validación de roles durante la aprobación de un producto.
  • Tarea: 1. Crear documentación con el proceso de flujo de trabajo del sistema "Echo".
  • Tarea: 2. Refactorizar el código para que la acción de aprobación valide si el rol es correcto para la validación.
Ron Jeffries y Chet Hendrickson hablan sobre historias de usuarios. Una publicación de Ron Jeffries en 2001.
Vi y leí sus enlaces; parece corroborar la idea de ser flexible con las historias pero manteniendo las preguntas de quién, qué y por qué respondidas. Bromeó sobre el formato "As", pero aun así terminó confirmando que necesitaba responder a esas 3 W. Sin embargo, estoy más interesado en cómo los equipos realizan un seguimiento de su trabajo que no está directamente relacionado con el valor empresarial o el propietario del producto, como la creación de documentos, la formación, los nuevos empleados, etc.
Solo el trabajo directamente relacionado con el producto debe ser rastreado en la herramienta. Usarlo como una solución completa de seguimiento del tiempo del trabajador no es el propósito. También tenga cuidado con la falacia de utilización del 100%.

Respuestas (2)

No ha dicho cuánto tiempo dura su sprint, y con solo un par de tareas, el gráfico de trabajo pendiente no le brindará a usted ni a las partes interesadas mucha información. Si puede hacer esto en un par de días como parte de un sprint de limpieza de deuda técnica, creo que probablemente esté bien. De lo contrario, vea si puede dividir las tareas en paquetes de trabajo de 8 horas o menos.

Espero que ayude

Los sprints tienen una duración de 2 semanas, el incremento del programa es de 2 meses. En lo que respecta al trabajo, el error se completó en 2 horas: la documentación de requisitos está demorando unos pocos días hábiles.
Ok, entonces en menos de una semana en total probablemente fue solo una parte del sprint. Creo que estás bien entonces.
OK, me preocupaba que mi PBI realmente no agregara ningún "valor comercial" y, por lo tanto, no sería bueno de la forma en que lo había presentado.

En Scrum, un enfoque común es envolver todo alrededor de las historias de los usuarios.

Tomando tus ejemplos:

Como administrador del sistema, quiero comprender el sistema por completo para poder brindar innovación y soporte.

Esta no es una historia de usuario, es una tarea que podría incorporarse a una historia que brinde valor comercial.

Un enfoque más Scrum sería tener:

Como usuario, quiero que la acción de aprobación valide si tengo el rol validado correctamente para poder completar todas las aprobaciones requeridas

Podría haber varias subtareas en esta historia, que incluyen:

Obtener una comprensión del sistema.

Crear documentación para el sistema.

La idea es centrar su cartera de pedidos en la entrega de valor comercial, pero eso no significa que ignore las tareas necesarias para entregar ese trabajo. Simplemente envuélvalo en las historias de usuario.

Gracias, Barnaby, parece que siempre obtengo dos respuestas muy polarizadas para las Historias de usuario, algunos dicen que es solo por valor comercial, otros son más flexibles al usar historias alternativas como "Como administrador del sistema,...". Incluso en las búsquedas de Google obtengo diferentes respuestas, parece ser solo un enfoque de estilo.
Probablemente sea mejor hacer aquello con lo que el equipo y el Product Owner se sientan más cómodos. Vale la pena señalar que hacer que los elementos de trabajo sean subtareas de las historias no los hace menos importantes. De alguna manera, enfatiza lo importantes que son: NECESITAMOS comprender y documentar el sistema, ya que es fundamental para entregar historias comerciales. Deja de haber una conversación en la que se sugiere que la comprensión/documentación se puede retrasar mientras se entrega el valor comercial.
¿Qué elementos de trabajo se verían relacionados con el soporte para una solución que ya está en producción?
RespuestasAquíPolítica de privacidad1y, 0v