 |
| Las historias de usuario consumen historias técnicas Cortesía de Pixabay |
A estos elementos se les llama historias técnicas o enablers (habilitadores), y son cosas como preparar un webserver, implementar un conjunto de tablas en una base de datos que va a ser consumida por varias funcionalidades, elementos de seguridad, escalabilidad, rendimiento, etc. Otros tipos de historias técnicas se centran en resolver deuda técnica y en refactorizaciones, otros en historias de exploración como un análisis técnico o uno funcional que sirve para despejar incertidumbre sobre alguna historia de usuario.
Las historias técnicas se escriben directamente en texto técnico claro y preciso, sin un patrón como ocurre con las historias de usuario. También tienen criterios de aceptación asociados que se comprueban en la revisión de sprint por la audiencia técnica correspondiente.
Aunque el Propietario del Producto sea el responsable de la pila de producto y por tanto de todos sus elementos, en el caso de las historias técnicas los verdaderos "propietarios" son perfiles de carácter técnico como el equipo o un arquitecto. Estos no solo son responsables de la definición de la misma sino también de responder a dudas y preguntas y aclaraciones en la planificación y en la entrega de las historias.
Se pueden identificar diferentes tipos de historias técnicas:
- Arquitectura: construyen elementos como las API's que crean la estructura, funcionamiento e interacción entre distintas las partes del software.
Ejemplo: "Implementar un sistema de login seguro". - Infraestructura de producto: historias que son consumidas directamente por historias de usuario. Esto podría incluir infraestructura nueva y/o modificada, y oportunidades de refactorización originada por alguna necesidad funcional.
Ejemplo: "Preparar los servidores de base de datos y web". - Infraestructura del equipo: historias que respaldan al equipo en su capacidad para entregar software. Suelen ser historias para herramientas y marcos de pruebas, métricas, diseño, planificación... y también pueden implicar que el equipo "desarrolle" o "compre e instale" algo.
Ejemplo: "Preparar un sistema de integración continua" - Refactorización: estas son historias que representan candidatos para refactorizar, como por ejemplo lo es la deuda técnica. Pero no solo el código necesita de refactorización, también puede incluir diseños, automatización, herramientas y cualquier documentación de proceso.
Ejemplo: "Homogeneizar el código de la función de cálculo de préstamos". - Spikes: historias de exploración limitadas en tiempo que dan respuesta a una cuestión, o reúnen información para una toma de decisión posterior o el diseño de una solución.
Ejemplo: "Evaluar Oracle versus SQL/Server".
No se... Tengo mis dudas... si son historias o actividades para desarrollar una historia....
ResponderEliminarGracias por el punto de vista
Hola Marco,
EliminarLas actividades para desarrollar historias son las tareas y son propias de una historia, como por ejemplo crear una tabla, ejecutar una prueba, etc. Preparar un websever o refactorizar una parte del software no son tareas de una historia, es algo más general que va como PBI a la pila de producto, y es a estos elementos a lo que se refiere este post.
A fecha de hoy y con experiencias exitosas (en mi realidad) les daría el siguiente patrón:
If we don't do this < action required>
It will cause this impact
And that will result in and/or
Y priorizaría la pila de producto en base al coste del retraso en lugar de valor. El coste del retraso representa lo que estamos perdiendo por no tener cierta cosa. Lo interesante es que el coste de retraso aplica a historias de usuario y a los habilitadores. Por ejemplo la instalación de un webserver no tiene valor de negocio, pero si tiene coste del retraso, ya las historias de usuario de valor lo consumen y no pueden ser sin este... las historias de usuario a su vez tienen el coste del retraso del valor que no generan mientras no estén funcionando.
Gracias por escribir, un abrazo,
Alex
estas HU de usuario aplican para el concepto de DoD, para mi si porque es la forma como las cierro en la metodología
ResponderEliminarHola Camilo,
EliminarSi aplican, quizá no en todos los criterios de la DoD, y quizás tengan alguno específico. Por ejemplo pudiera ser que para las HUs fuera el Propietario de Producto quien deba de aceptarlas y para las técnicas lo deba de hacer el arquitecto.
Gracias por compartir,
Alex
Consulta. Como se describe una historia si el que me pide la información no un usuario directo sino un sistema
ResponderEliminarHola Diego,
EliminarLas historias de usuario están concebidas para poner foco en las necesidades de los usuarios y generar entendimiento y evitar malentendidos. Entre sistemas, donde los comportamientos están determinados, la comunicación suele basarse en especificaciones técnicas muy claras. Si, por ejemplo, has de construir un webservice para dar esa información, la historia del sistema que la consume suele escribirse con una descripción corta del servicio, las URLs de producción y pruebas, los campos que integran el mensaje de solicitud y los mensajes de respuesta.
Detrás del sistema cliente, el que te pide la información, hay usuarios y lo suyo sería escribir la historia de usuario desde su perspectiva, ya que quien la usa en última instancia es un usuario. Esa historia de usuario acabará refinándose y dividida en otras y entre ellas habrá una historia técnica como la del webservice. El patrón para especificar la historia técnica dependerá de la naturaleza de lo que construyas.
Podrías escribir esta historias de una forma a caballo entre la implementación técnica y la historia de usuario utilizando un patrón tipo "Como [sistema], quiero [objetivo], para poder [beneficio]" y poner las especificaciones en forma de criterios de aceptación... Pero eso no es formal, es una opción que un equipo al que he acompañado ha utilizado y les ha funcionado.
Espero haberte ayudado, gracias por consultar,
Alex