Epicas, Historias de usuario, tareas, refinamiento, DoD, criterios de aceptación Flashcards
En Scrum, se habla de un proceso constante de refinamiento de los elementos del Product Backlog
- Poner al equipo en contexto
El PO debe contar la historia del usuario y el descubrimiento, para que el equipo viva el proceso y todos estemos en el mismo plano. - Transmitir conocimiento
Ademas de lo anterior, el PO es responsable de contar las posibilidades que se hayan valorado para que el equipo pueda empezar a entrar en los detalles - Crear compromiso
El PO cuenta la historia del usuario y el descubrimiento para hacer que el problema sea de todos, y entre todos pongamos una solución.
Cuánto más conocimiento trasmita el PO al equipo, más posibilidades tendremos para satisfacer al cliente.
Jerarquias de elementos:
- Las historias de usuario (US) son breves requisitos o solicitudes
escritas desde el punto de vista del usuario final.
2 . * (Las features son caracteristas del producto, desde la vision del
PO más pequeñas que las Epics pero más grandes que las US)
3 . * Los epics son grandes cantidades de trabajo que se pueden
desglosar en un número de historias más pequeñas
4 . Las iniciativas son conjuntos de epics que conducen hacia un
objetivo común.
5 . Los temas son grandes áreas de enfoque que abarcan a toda la
organización.
- Las historias de usuario (US) son breves requisitos o solicitudes
El Product Backlog no necesariamente tiene que contener épicas.
Que es una epica?
La épica como una gran historia de usuario, que podrá ser dividida en partes más pequeñas las cuales podrán ser entregadas en distintas iteraciones.
Podemos verla como una historia de usuario que aún no se ha detallado, es
demasiado grande o todavía presenta mucha incertidumbre y, por lo tanto, no se puede transformar en un incremento del producto. Lo épico debe desglosarse en historias de usuarios más pequeñas.
Que son las historias de usuario?
Es una representación de un
requerimiento de software escrito en
una o dos frases utilizando el lenguaje
común del usuario.
La estructura de una historia de usuario es:
* Como rol quiero algo para
poder beneficio.
Mencione caracteristicvas de las historias de usuario
Deben cumplir el principio INVEST en sus siglas en inglés, esto es: Independiente, Negociable, Valorable, Estimable, Pequeña (Small) y Testeable
- Independientes una de otras
Dividir y conquistar - Negociables
La discusión con los usuarios debe permitir esclarecer su alcance y este quedar explícito bajo los
criterios de aceptación. - Valoradas por clientes o usuarios
Cada historia debe ser importante para alguno de ellos más que para el desarrollador (concepto de
business value). - Estimables
Un resultado de la discusión de una historia de usuario es la estimación que tomará completarla. - Pequeñas
Generalmente se recomienda la consolidación de historias muy cortas en una sola historia. - Verificables
Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables.
Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada
entrega del proyecto.
Que son las historias de usuario “Spikes” en scrum?
- A veces no estamos seguros sobre cómo desarrollar algo desde un punto de vista técnico.
- En ese caso recurriríamos a un «spike» para investigarlo; una breve actividad de desarrollo para aprender los elementos técnicos necesarios para desarrollar la solución.
- Podemos considerar dos tipos de spikes:
- Spike técnicos: se centran en encontrar el enfoque de desarrollo;
- Spike funcionales: se centran en la creación de prototipos y buscar o
comprender las funcionalidades requeridas
Cuales son los enfoques de refinamiento de historias de usuario?
- “descomposición horizontal” e implica desglosar las historias
por el tipo de trabajo que se necesita hacer, o las capas o componentes que están involucrados. Es decir, el trabajo que se tiene que hacer para la UI, la base de datos, algunos componentes, el front-end y las pruebas se dividen en ítems técnicos en el Backlog. - Una descomposición vertical es más útil, en el que las US se dividen en otras US funcionales más pequeñas (en lugar de tareas técnicas) Software que funciona y US demostrables.
Mencione algunos tipos de refinamiento:
- Refinamiento por
reglas de negocio - Refinamiento por
grado de complejidad - Refinamiento por tipo
de operación - Refinamiento
de un Spike
Que son los criterios de aceptación?
un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de “aceptado/rechazado”
- Son definidos por el PO (a veces con colaboración del equipo).
Mencione ventajas de tener criterios de aceptación:
- Le permite al equipo de desarrollo tener una noción más tangible de la
funcionalidad. - Fuerza al equipo a pensar una dada funcionalidad desde la perspectiva del usuario.
- Remueve ambigüedades de los requerimientos.
- Promueve la calidad del desarrollo desde el momento en que el equipo realiza las entregas de los requerimientos adhiriendo a los criterios de aceptación
- Constituirán la base para los casos de prueba que confirmarán si una dada
funcionalidad está completa y se comporta como era esperado.
Cual es la estructura de un buen criterio de aceptación?
- Los criterios de aceptación deben describir siempre un contexto, un evento y la respuesta o consecuencia esperada del sistema
- La forma más utilizada para describir los criterios de aceptación es conocida como Given (contexto)-When(evento)-Then(consecuencia).
¿Para que sirve el Definition of Done (DoD)?
El equipo puede centrarse en lo que debe ser completado.
Además, se usa para evaluar cuándo se ha terminado el trabajo sobre el incremento de producto.
El DoD es crucial para un equipo altamente funcional en Scrum.
Que el equipo cumpla los criterios del DoD asegurará que se están entregando tareas que están realmente hechas, no sólo en términos de funcionalidad sino también en términos de calidad.
