¿Qué tipo de historias de usuarios deberían escribirse en las etapas iniciales de un proyecto?

Al comenzar un proyecto, no tiene nada: sin interfaz de usuario, sin capa de datos, nada intermedio. Por lo tanto, una sola historia como "los usuarios deberían poder ver a sus foos" implicará mucho trabajo. Una vez que tenga esa historia, uno como "los usuarios deberían poder editar sus foos" es más realista, pero esa primera historia implicará configurar una capa de interfaz de usuario, una capa de lógica de presentación, una capa de lógica de dominio y una capa de acceso a datos.

Esto no encaja con mi concepto de "tareas": para mí, prefiero tener algo como las siguientes "tareas":

• Mostrar datos ficticios para los foos de un usuario en HTML, derivados de objetos JavaScript.
• Configure una capa lógica de presentación y conéctele los objetos JavaScript.
• Configure una capa lógica de dominio y conéctela a ella.
• Configure una capa de acceso a datos y conéctele la capa lógica de dominio.

¿Todo esto cae bajo la única "historia" anterior? Si es así, siento que las historias no son un marco terriblemente útil en las primeras etapas de un proyecto. Si es así, está bien --- Solo quiero asegurarme de que no me estoy perdiendo algo, ya que realmente estoy tratando de aprender esta metodología ágil lo mejor que puedo.

Esta es una buena pregunta y probablemente hay varias buenas respuestas. Mi opinión es esta:

Una historia es una historia de usuario, por lo que debe definirse en términos que describan cómo beneficia al usuario.

Si Agile y las historias van a funcionar para usted, entonces deberían funcionar incluso en las etapas iniciales. El primer punto es una historia de un solo usuario (aunque redactada un poco de tecnología), pero las otras tres son descripciones de tareas técnicas.

En las etapas iniciales de un proyecto, cuando no tiene los marcos apropiados para hacer que el desarrollo CRUD ( C rea, R ead, U pdate, D elete) sea rápido y fácil, sus historias deben ser mucho más pequeñas e incrementales. piezas.

En lugar de "El usuario debería poder ver a su foo" , algo como esto:

1. El usuario debería poder ver una página con datos de muestra
2. El usuario debería poder ver una página con datos de muestra interactivos
3. El usuario debería poder ver una página con datos de muestra interactivos en vivo

Recuerde que la mayoría de las historias de usuarios que parecen demasiado grandes para desarrollarse en un solo sprint (descubrí que cualquier cosa mayor que aproximadamente 8 puntos de historia, o días de desarrollo, era demasiado grande) probablemente se puede dividir en piezas que todavía son significativas para el usuario.

La historia / característica no tiene que ser comercializable, solo tiene que ser significativa para el propietario del producto. En el caso anterior, se puede poner en algunas piezas demostración rápida para mostrar lo que ha cambiado y cómo esa historia es ahora hecho - por ejemplo, para el # 3, se puede mostrar la página para dos usuarios diferentes con los datos rellenados previamente en la base de datos . En la etapa 2, todos los usuarios verían los mismos datos.

Lo que está preguntando es esencial "¿cómo piensa sobre el espacio del problema" para dividirlo en piezas sensibles, a partir de las cuales puede hacer un diseño.

Ya sea que llame a esto la historia del usuario, o el análisis, o la descomposición, o la especificación, o la recopilación de requisitos ... al final, se reduce a varias cosas que normalmente tendrán cierta iteración.

Necesita obtener de los usuarios lo que quieren. (Probablemente saben algo de lo que quieren y quieren cosas que son inconsistentes pero que aún no pueden ver).

Necesita capturar esto de alguna forma: realmente solo tiene 2 opciones: palabras o imágenes. Ambos tienen poder, úsalos si puedes. En última instancia, las palabras son más poderosas desde el punto de vista de una disputa contractual.

Debe presentar esto de nuevo y buscar un acuerdo.

Algunas personas hacen prototipos visuales tempranos sin negocio u otra lógica detrás. Esta puede ser una técnica poderosa, hasta cierto punto, ya que aún implica una cierta cantidad de movimientos manuales.

Algunos escribirán un guión gráfico, y luego presentarán y explicarán.

Algunos escribirán documentos rigurosos y cuidadosamente analizados.

Cada técnica tiene sus ventajas y desventajas.

El único consejo que daría es: saltar a codificar una solución demasiado pronto suele ser un mal movimiento. Entender QUÉ hacer, para QUIÉN y POR QUÉ, antes de hacerlo, generalmente conlleva menos retrabajo y un desarrollo más rápido.

Cuando hablas de "tareas", me parece una especie de desglose del trabajo, habiendo descubierto lo anterior, qué, quién y por qué. No puede resolver las tareas BIEN hasta que haya entendido la historia del usuario, en un documento, aprobado por el cliente como el alcance del trabajo que va a hacer. Saber lo que tiene que lograr (el resultado) le permite descubrir las tareas (los pasos necesarios para llegar allí).

No escatime en el análisis y la documentación del front-end.

Creo que lo que falta es que las historias de los usuarios tratan de describir cómo el usuario espera usar el sistema. Esta es una forma de determinar los requisitos comerciales . No están diseñados para decirle directamente qué hacer técnicamente, que es lo que parece querer.

Esta es posiblemente una de las partes más importantes de un proyecto. Si no cumple con los requisitos comerciales correctos, el sistema no será de utilidad para los usuarios.