2.0 KiB
User Story
Es utilizado para describir una funcionalidad del sistema desde el punto de vista el usuario. Esto esta directamente relacionado con la relevacion de requerimientos.
Son cortas y no tienen un lenguaje tecnico. Utiliza tanto comunicacion oral como escrita, estas por medio de conversaciones directas con el desarrollador y los papeles del panel.
Que tiene
- Descipcion.
- Criterio de evaluacion.
- Valor -> Maximisa la satisfaccion del cliente.
- Ficha estructural.
- Como (rol) quiere objetivo -> para beneficio.
Lo más clave es
- Descipcion.
- Pruebas / Criterios Aceptacion.
3 C
Cartas
Como las propias de trello o jira. Condensan de forma directa el contenido de la conversacion con lo que se debe hacer.
Conversacion
En esta lo que sucede es que el desarrollador y el manager hablan con el stakeholder. Este ida y vuelta es crucial para llenar los detalles y que el equipo entienda el trabajo a realizarse.
Esto no es una cosa de una vez sino que es un proceso que se mantiene sobre el tiempo para mantener el equipo alineado en el desarrollo.
Confirmacion
Es el paso final, consiste en validar el desarrollo usando un criterio claro. y confirmando que el software cumpla con laos estadares acordados.
Dependencias
Las historias de usuario tienen que ser independientes una de otra.
Bocetos
Crear mocks de las pantallassd que va a ver el usario, una forma adicional de capturar condiciones de satisfaccion de las historias de usuario.
Invest
Independiente
las dependencia entrre las historias crean problema de priorizacion
Negociable
Se debe de definir entre el desarrollador y el usuario
Valuable
tiene que aportar valor al usuario
Estimable
tiene que poderse estimar facilmente
Small
Tiene que entrar en una sola iteracion
Testeable
Tiene que ser testeable
Story points
Story points
Estos son puntos los cuales permiten evaluar cada US de forma independiente de las horas que un equipo le tendria que dedicar. Y se calculan usando la escala de fibonnacci.