Sé que el propietario de un producto debe escribir una historia de usuario en scrum.

Una historia de usuario describe una característica para el usuario final.

Pero, ¿quién describe qué necesita desarrollarse técnicamente y cómo debe implementarse?

¿Y dónde se almacena esa información sobre scrum?

¡Eso realmente me interesaría!

Veo una gran falta de conocimiento en nuestra empresa cuando los desarrolladores comienzan a implementar la historia, ¡pero no saben CÓMO implementarla!

Por ejemplo, tienen que lidiar con una API COM heredada y no tienen idea de cómo manejarla, o no tienen tanta habilidad técnica con WPF / WEB o lo que sea.

¿Cómo ayuda Scrum a esa gente a comenzar con la historia del usuario?

No odioso ágil aquí. Desarrollar los detalles de la implementación y determinar las tareas que deben realizarse durante la reunión de planificación del sprint, que convertirá las historias de los usuarios en tareas / requisitos reales para el sprint. El fracaso de muchos procesos ágiles es que la reunión de planificación del sprint en realidad debe ser realizada en gran parte por los desarrolladores ... si solo son los propietarios del producto, simplemente decidirán obtener la luna. Aquí es donde se te ocurre una historia de usuario (bastante nebulosa) como:

As a non-technical user, I need to have a simpler interface with the API

Si bien el propietario del producto define qué historias de usuario son la prioridad más alta, los programadores toman esas prioridades y las convierten en una lista de tareas (llamada reserva de sprint). Aquí es donde te haces una idea de cómo vas a implementar las cosas ... el backlog de Sprint puede ser tan técnico como desees. Aquí también es donde descubrirá "para lograr una API más simple, tendremos que refactorizar esa loca API COM. ¿Alguien sabe cómo usar eso?". Cuando la respuesta sea "Infierno No", comenzará a ver que el alcance de esa historia de usuario puede ser mayor de lo que parece. Dado eso, debería dividir la historia del usuario en las tareas:

• Documentar y comprender la API actual
• Diseñar nueva API
• Implementar nueva API
• Lo que sea...

Dado esto, está bien negociar las historias de los usuarios para dividirlas en cambios más pequeños. La metodología ágil significa que desea acercarse a lo que la persona quiere en pasos incrementales. Entonces puede decir "Oye, mira. No podemos revisar la API en una sola iteración. Vamos a dividirlo en 'Como cliente no técnico, necesito una API bien documentada' ect".

Respuesta corta

El equipo de desarrollo escribe las cosas técnicas. Scrum te ayuda un poco pero no mucho con el desglose técnico resp. comenzar con una historia de usuario. Scrum es casi el único mundo . El desglose técnico es How-World .

El desglose proporcionado por Scrum es:

• Historia de usuario -> Criterios de aceptación

El desglose que la gente suele usar además de esto es:

• Epic -> Historias de usuarios
• Historia de usuario -> Subtareas
• Criterios de aceptación -> Pruebas de aceptación

Además, el equipo podría escribir Tareas técnicas para las cosas que saben que deben hacerse (es decir, instalar IntelliJ IDEA para todos al comienzo del proyecto) pero que no tienen valor comercial.

Para obtener más orientación sobre cómo desglosar el trabajo, busque XP (programación extrema), código limpio , programación pragmática , ingeniería de software , tarjetas CRC , OOP / OOA / OOD , patrones de diseño , refactorización , trabajo efectivo con código heredado , TDD ( Desarrollo guiado por pruebas , BDD (Desarrollo guiado por el comportamiento), ATDD ( Desarrollo guiado por pruebas de aceptación).

Respuesta larga

Cómo piensa Scrum

Qué mundo y cómo mundo

Hay un mundo del qué y un mundo del cómo . Como se sintió correctamente, User Story es para usuarios , generando valor comercial, también conocido como valor secundario en el mundo de lo que . Scrum es principalmente What-World solamente. Dice poco o nada sobre el How-World , básicamente no más que "How-World es responsabilidad del Dev-Team".

User Story vs Task

Por lo general, los elementos de Backlog que son para How-World no se llaman User Story sino Technical Task o Subtask . Muchas herramientas permiten desglosar la historia del usuario del What-World en Subtareas en el How-World .

Cómo ayuda Scrum y dónde termina esa ayuda

La ayuda de Scrum for the How-World termina en algunos puntos de la reunión de planificación de Sprint :

• [Reunión de planificación de Sprint] El equipo descubre un malentendido de la historia si diferentes compañeros de equipo obtienen diferentes estimaciones de Story Point durante el Poker de planificación -> Discusión.
• [Definición de Listo] El equipo no acepta Historias de usuarios que son demasiado grandes (Puntos de historia demasiado altos). Una regla general que se encuentra en muchas definiciones de Ready es que los puntos de historia deben ser inferiores a la mitad de la velocidad del equipo.
• [Definición de Listo] El equipo no acepta Historias de usuarios sin una descripción suficiente de los Criterios de aceptación. Los criterios de aceptación son suficientes si el equipo tiene suficiente confianza sobre cómo comenzar a escribir las pruebas de aceptación.

Algunos consejos sobre el nivel de Scrum

Me pareció útil hacer un desglose de Historias de usuarios en Subtareas durante las reuniones de Refinamiento de la cartera o al menos la segunda parte de la Reunión de planificación de Sprint (para algunos equipos Reunión de planificación 2 de Sprint ).

Con equipos inexpertos, me resultó útil luchar por historias de usuarios atómicos durante el refinamiento de la cartera y la planificación de Sprint. Una historia de usuario atómica es una historia de usuario que no puede desglosarse en historias de usuario más pequeñas sin perder por completo su valor comercial. En general, las historias de usuario no necesitan ser atómicas, acabo de descubrir que me ayuda con equipos sin experiencia.

Y no haga "(Arquitectura | Diseño | Implementación | Prueba) de la Característica X" como Historias de usuarios. Te recomiendo que incluso intentes evitar esto como una subtarea.

Si tengo Historias de usuarios atómicos y parecen necesitar un mayor desglose aparte de los Criterios de aceptación que se implementarán, significa que algo no está funcionando en el nivel óptimo. O la arquitectura es incorrecta / demasiado complicada, es decir, técnica en lugar de orientada a los negocios. O el equipo no tiene experiencia. O ambos. En cualquier caso, se requerirían medidas para mejorar la situación mediante la capacitación y la difusión de conocimientos.

Más allá de Scrum

El Scrum Master más allá de Scrum

Hoy, el Scrum Master se entiende principalmente como un rol gerencial , y eso es una mierda. Originalmente, el Scrum Master era, y defiendo esto, un rol técnico , no un rol de gestión, al igual que el entrenador en XP .

Es demasiado fácil confiar en Scrum y el Scrum Master y, por lo tanto, caer en una gran brecha porque Scrum no dice casi nada sobre el How-World.

Rotación Scrum Master

Idealmente, el Scrum Master rota entre aquellos desarrolladores experimentados que también tienen suficientes habilidades de gestión y comunicación hasta que todos en el equipo vivan "Inspeccionar y adaptarse" tan profundamente que el Scrum Master se vuelve redundante; nadie y todos serían Scrum Master al mismo tiempo.

Pero cuidado, Scrum Mastery es más como cocinar, no como limpiar la mesa y lavar los platos. Es posible que desee rotar quién limpia la mesa y lava los platos, ya que todos podrían hacerlo. Pero no querrá rotar la cocina sobre todos, porque hay personas que no pueden cocinar o no les gusta cocinar, y desea comer buena comida.

Lo bueno de rotar el Scrum Master entre desarrolladores expertos es que es más probable que el equipo aprenda sobre más métodos.

El equipo autoorganizado

Desde la perspectiva de Scrum, el equipo debe descubrirse a sí mismo, idealmente con la ayuda del Scrum Master .

Scrum también solo habla del equipo de desarrollo . Roles como Arquitecto o Ingeniero principal no existen en Scrum. Eso no significa que estén prohibidos, solo significa que Scrum no dice nada sobre ellos. Scrum proclama un equipo autoorganizado , lo que significa que si el equipo declara un arquitecto, el equipo tiene un arquitecto. Eso no está definido por Scrum, pero es compatible con Scrum. No estoy proclamando arquitectos dedicados (trabajé como arquitecto designado durante años, y aunque me gustó, estoy fundamentalmente en contra de la idea de un arquitecto designado), solo estoy dando un ejemplo.

Prueba de aceptacion

Las historias de usuario tienen criterios de aceptación . Estos criterios de aceptación se convierten en pruebas de aceptación

Otras cosas

Para obtener una lista de más cosas para el desglose, consulte ¿Cómo dividir un proyecto de programación en tareas para otros desarrolladores?

Espero que esto ayude.

Quien esté mejor calificado en el equipo debe desglosar los requisitos de los propietarios de productos en historias de usuario accionables. En mi experiencia, hemos utilizado el siguiente enfoque:

• Siempre ha sido un desarrollador que escribe historias basadas en discusiones con propietarios de productos.
• Luego, los desarrolladores estiman estas historias (según los puntos o el tiempo)
• Los propietarios del producto luego deciden cómo se priorizan las cosas.

Si los desarrolladores no saben cómo implementar una historia, uno de estos casos podría ser cierto:

• Es posible que la tarea no sea lo suficientemente clara (agregue más detalles / capturas de pantalla / maquetas)
• Debe desglosarse aún más para que las tareas específicas sean más claras
• Necesita más tiempo para que el desarrollador pueda investigar y aprender cómo implementarlo. (Al estimar esta tarea, agregue más tiempo para dar cuenta de esto)
• El desarrollador no está lo suficientemente calificado para implementarlo y es posible que deba asignarse a otra persona, o el desarrollador debe recibir ayuda de otra persona.

Puede tomar este curso sobre SCRUM en Udemy de forma gratuita y aprender sobre aspectos individuales del proceso SCRUM: https://www.udemy.com/scrum-methodology/

La respuesta breve es esta: el propietario del producto es responsable de crear las historias que el equipo debe entregar. Es el equipo el que decide cómo entregar las historias. Si parte de la entrega involucra algunas historias técnicas, es el equipo el que escribe esas historias. El equipo luego trabaja con el propietario del producto para decidir la prioridad.

Nuevamente, el PO decide qué construir, el equipo decide cómo implementar esas historias.

Este no es un problema ágil. El problema es que el equipo no tiene suficiente conocimiento técnico para completar una historia de usuario (ágil) o un requisito (tradicional). ¿Puede Agile ayudar en esta situación? No, si el equipo no fue seleccionado cuidadosamente y nadie en el equipo tiene suficiente experiencia técnica para realizar sus tareas. Sí, si algunos de los miembros del equipo tienen buenos conocimientos técnicos que pueden ayudar a otros miembros del equipo a realizar sus tareas. Para ese equipo debe ser autoorganizado, y debe saber que es fortaleza y debilidad.

recuerde el siguiente principio ágil.

"Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados"

Esto sucede porque en el entorno ágil, la confianza del equipo es alta y delegan el trabajo entre ellos.