¿Cómo redacto historias de usuario como desarrollador?

Estoy escribiendo un sistema donde tanto el propietario del sistema como yo somos desarrolladores, y actualmente somos la única fuente de 'solicitudes' o requisitos para el sistema, que me gustaría capturar en las historias de usuarios vinculadas a las características {1}. Mi prioridad urgente ahora es capturar una acumulación acumulable de recursos gestionables. ¿Cómo debo hacer para capturar el nivel de especificaciones técnicas con las que estoy acostumbrado a trabajar en las historias de los usuarios, que no se supone que sean demasiado técnicas?

{1} Estoy evaluando el servicio ágil de gestión de proyectos TargetProcess , y cada historia de usuario debe estar vinculada a una función principal. El sistema parece encajar bien, por lo que esta pequeña restricción es algo con lo que preferiría trabajar antes que evitarlo.

La plantilla de historia típica es muy fácil de visualizar:

As a [ROLE] I need to [WHAT] so that/because [WHY].

Lo interesante es que la importancia de los componentes se invierte.

POR QUÉ es más importante que QUÉ y eso es más importante que PAPEL

Ejemplo usando esta pregunta

Como desarrollador de software, necesito aprender a escribir historias de usuarios para poder completar el trabajo atrasado con borradores para comenzar a discutir las características y obtener puntos asignados.

Algo más ha terminado complicando la intención y la implementación de Historias de usuarios.

Herramientas adicionales (la integración es la mejor)

Las herramientas se pueden usar para capturar información detallada adicional sobre las historias que se capturan al discutirlas para asignar puntos / estimación, pero ese detalle no debe ser parte de la historia misma. Algo tan simple como un Wiki con 1 página por historia para poner detalles / transcripciones de las discusiones es una solución lo suficientemente buena. La hoja de cálculo de Excel es una solución terrible.

Concéntrese en el qué y el por qué y evite el cómo al escribir las historias de los usuarios.

Lo que enfrenta es en realidad un ejercicio muy bueno para todos los desarrolladores. Poder expresar el requisito en términos simples y comerciales es una habilidad importante.

Debe centrarse en el requisito general, como "la necesidad de poder hacer una única selección de una lista desplegable de objetos para que el usuario pueda habilitar la acción Foo" en lugar de especificar el uso de un cuadro combinado o cuadro de lista o lo que sea que desencadene una rutina específica .

Otra forma de abordar esto es fingir que la base / marco de código subyacente es un cuadro negro casi completo. Cada vez que te encuentres diciendo "usar objeto XYZ", puedes autoverificarte preguntando si lo sabrías en un sistema de caja negra.

Actualización:
OMI, está bien poner detalles en un caso de uso que indique el nivel de detalle requerido para la información. Por ejemplo, con un sistema de inscripción es un juego justo para especificar
: apellido; campo obligatorio
: nombre; campo obligatorio
: ID de cuenta; el sistema no generó ninguna entrada necesaria
: signo astrológico; campo opcional: (sugerencia) ¿proporciona una búsqueda al ingresar la fecha de nacimiento?
- etc.

La clave es que no está especificando el cómo técnico para esa información. Si te encuentras diciendo "usa una clase de cadena / matriz de caracteres / o campo varchar" para el apellido, entonces sabes que estás sobreespecificando.

Si es multilingüe, use dos idiomas diferentes como prueba de fuego. Por ejemplo, las cadenas en C son generalmente matrices de caracteres (acter), mientras que C ++, Java y C # (está bien, y casi todos los demás ...) tienen un objeto similar a una cadena real. Si descubre que su especificación se invalida al usar uno de esos idiomas, sabrá que ha especificado en exceso.

Vale la pena señalar que estoy usando específicamente el término Caso de uso en lugar de Historia de usuario , aunque la variante que termino usando es un híbrido de ambos. Mi objetivo de un caso de uso es dar una visión general de lo que está sucediendo (una historia de usuario en el sentido más estricto) pero luego trabajar a través de los actores, los sistemas y la funcionalidad general que se requiere. Mi enfoque está más cerca de lo que Fowler sugiere en ese artículo de Wikipedia en lugar del enfoque de Cockburn.

Así que tendré un caso de uso único (más o menos) para el escenario de inscripción o el elemento de trabajo. Si es realmente complejo, lo dividiría en múltiplos, pero eso no es gran cosa. El caso de uso se puede dividir en tareas individuales según sea necesario. Lo que se arroja a un scrum particular depende de muchas variables, pero no hay nada dentro de este enfoque que le impida tener un componente demostrable al final del scrum.