Supongamos que tiene una pieza de software que sabe que se puede mejorar en varias métricas cuantificables (tiempo de arranque, uso de CPU y memoria, latencia para varias acciones, precisión de las tareas de reconocimiento, etc.), pero no sabe cuánto. - ¿Cómo escribirías historias de usuario?
¿Es mejor adivinar una mejora? (idealmente con el equipo) ¿Simplemente escribir "mejorar tal y tal métrica", sin especificar cuánto?
(Nuestra organización es nueva en Agile y estamos probando Scrum, y descubrí que pasamos demasiado tiempo discutiendo estos detalles y el metatema de cómo formularlos, así que me gustaría saber cómo lo harían otros cubrir esto; no tenemos requisitos formales específicos de nuestro cliente sobre eso, pero sabemos (de pruebas de UX, etc.) que esas mejoras son necesarias para una mejor experiencia de usuario)
Las mejoras en el desempeño son a menudo un ejercicio de compensación de costo-beneficio. El ejecutivo que "solo quiere que sea más rápido" puede considerar que agregar un servidor para aumentar la velocidad en un 50 % es un costo aceptable, pero no dos servidores más para el siguiente aumento del 20 %. Además, normalmente hay muchos enfoques técnicos posibles para mejorar el rendimiento: refactorización de código, cambios de infraestructura, cambio de componentes. Por lo tanto, a menudo se requiere cierto grado de investigación y exploración para descubrir la solución óptima para su situación técnica y comercial actual.
Le sugiero que comience con un pico de tiempo para generar ideas, investigar y posiblemente experimentar con algunos enfoques posibles. (A veces, esto puede incluso revelar algunas soluciones rápidas y sencillas). Luego, informe a las partes interesadas sobre las opciones, cada una con estimaciones aproximadas del costo (en tiempo o dinero) y el beneficio esperado. Entonces se puede tomar una decisión sobre cuál implementar. En ese punto, las historias pueden estar esencialmente en la forma "haz la opción B". Asegúrese de comparar la métrica antes y después para determinar si los costos y beneficios esperados estaban en la marca. Luego, se puede tomar una decisión sobre si proceder con pasos adicionales.
No se pueden inventar objetivos significativos de la nada. En términos pragmáticos, tanto el análisis comercial como los requisitos de experiencia del usuario requieren formular una hipótesis, probar la hipótesis y luego sacar una conclusión procesable (por ejemplo, sus especificaciones) a partir de los resultados.
Su equipo (y, en particular, su Product Owner) no parece tener los procesos correctos para recopilar especificaciones significativas sobre los requisitos no funcionales relacionados con la experiencia del usuario.
Mi pregunta es precisamente sobre cómo hacer buenas historias. Digamos que estás creando un juego y comenzar un nivel lleva dos minutos, lo que frustra a los probadores. La necesidad del usuario es concreta ("¡Maldita sea, quiero que se cargue más rápido!") pero vaga.
Una buena recopilación de requisitos a menudo implica experiencia en la realización de múltiples desgloses hasta llegar a especificaciones procesables. "El tiempo de carga es demasiado lento" no es una declaración accionable. Sin embargo, un objetivo de administración basado en la investigación de la industria (p. ej., "los tiempos de carga deben ser inferiores a 8,3 segundos para mantener el compromiso") o los datos experimentales reales ciertamente pueden convertirse en historias de usuarios.
Un propietario de producto debe trabajar con analistas comerciales (BA) y diseñadores de experiencia de usuario (UX) para construir pruebas. Por ejemplo, el equipo de UX podría desarrollar un producto viable mínimo con tiempos de carga de 5 segundos, 10 segundos y 20 segundos. Luego, un buen equipo de UX recopilaría datos en forma de opiniones o comportamientos humanos comprobables para determinar qué tan "pegajoso" es el producto en diferentes tiempos de carga para ver qué nivel de tiempo de carga conduce a una desconexión real o falta de interés en el producto.
Las historias de usuario son marcadores de posición de conversación entre el equipo de desarrollo y el propietario del producto o los usuarios finales. No son documentos de especificaciones ni sustituyen las habilidades comerciales esenciales. Un gran equipo multifuncional puede incluir experiencia en UX dentro del equipo, pero la mayoría de las veces, la gestión de requisitos de este tipo es realmente externa al equipo y está representada por el propietario del producto.
En otras palabras, su problema no es que tenga problemas para crear las historias de usuario. El verdadero problema es que su equipo (y, en particular, su propietario del producto) no cuenta con los procesos correctos para recopilar especificaciones significativas sobre los requisitos no funcionales relacionados con la experiencia del usuario. Ya sea interno o externo al equipo, la organización debe asegurarse de que esos procesos existan y estén debidamente integrados en el proceso de desarrollo del producto.
A menudo, este tipo de historias provienen de partes interesadas de alto nivel; en nuestro caso, fue el director ejecutivo que se quejó de que el sitio es demasiado lento. Estaba pidiendo un rendimiento de menos de un segundo, que no era realista debido al procesamiento de datos involucrado.
Usamos historias vagas como 'Mejorar el rendimiento de X', que nos dio suficiente objetivo para identificar algunas historias técnicas diferentes que probablemente mejorarían el rendimiento. Luego priorizamos estos en función del esfuerzo y el impacto probable. Luego comenzamos en la parte superior, hasta que llegamos a un punto en el que nuestro propietario del producto estaba satisfecho de que habíamos logrado un impacto positivo suficiente, y el esfuerzo restante superó los beneficios.
No me gusta colocar un objetivo concreto en este tipo de cosas, ya que más adelante puede descubrir que puede lograr el 90 % del camino con el 10 % del esfuerzo, y eso es suficiente. Si el trabajo que ha realizado no ha marcado una diferencia suficiente, definitivamente se volverá a plantear como un problema y tiene la confirmación de que necesita seguir trabajando.
Todd A. Jacobs
emilio