Agilismo.................................................................................................................................................

1
Agile...................................................................................................................................................1
Metodologías.........................................................................................................................................1
Cascada..............................................................................................................................................1
Marco de trabajo Agile......................................................................................................................1
Manifiesto Agile.....................................................................................................................................1
Principios Agile..................................................................................................................................1
User Stories...........................................................................................................................................2
Origen................................................................................................................................................2
¿Qué es?............................................................................................................................................2
¿Por qué HU?.....................................................................................................................................2
Beneficios de las HU..........................................................................................................................2
¿Cómo definir una HU?.........................................................................................................................2
Debe ser escrita.................................................................................................................................3
Componentes de una HU...................................................................................................................3
Sesión inicial......................................................................................................................................3
Diferencia entre HU agile y una en Kanban.......................................................................................3

Agilismo
Agile
- Filosofía para tener mejores resultados
- Equipos de alto desempeño
- Una misma línea de motivación
- Buscar puntos de mejora bajo la autorreflexión

Metodologías
Cascada
Por Fases
Cada fase ocurre después de que la fase anterior haya finalizado

Marco de trabajo Agile

Desarrollo iterativo
Incluye todas las fases de desarrollo dentro de la iteración

Manifiesto Agile
Valoramos más:
 - Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
Que:
- Colaboración entre el cliente sobre negociación contractual (ALCANCE)
- Respuesta ante el cambio sobre seguir un plan

Principios Agile
1. Satisfacemos al cliente
2. Aprovechamos los cambios
3. Entregamos productos funcionales y frecuentemente
4. Trabajamos juntos
5. Permanecemos motivados
6. Conversamos cara a cara
7. Medimos los productos funcionando
8. Mantenemos un ritmo constante de forma indefinida
9. Prestamos atención continua a la excelencia técnica
10. Lo hacemos simple
11. Somos auto-organizados
12. Mejoramos continuamente

User Stories

Origen
1998
Piezas del juego
Casos de uso diferentes

¿Qué es?
Definición de una necesidad o requisito a un alto nivel.
Contiene la suficiente información para que los desarrolladores puedan estimar el análisis, esfuerzo,
tiempo y complejidad para construir e implementar dicho requisito

¿Por qué HU?

Las HU siguen los requisitos agiles

- Involucran al equipo en la toma de decisiones

- Se crean y evolucionan a medida que el proyecto avanza
- Son peticiones concretas y pequeñas
- Contiene información imprescindible. Menos, es más
- Apoyan la cooperación, colaboración y conversación entre los miembros del equipo.

Beneficios de las HU
Las HU son las que hacen posible la entrega de software incremental.

Ayudan a:
 - Mitigar los riesgos de retroalimentación retrasada, más sin los incrementos son pequeños
- Lanzamiento de software a producción con frecuencia
- Adaptabilidad y flexibilidad para los desarrolladores con los cambios de opinión sobre los
detalles o la prioridad de programación de cualquier HU que aún no se haya implementado
- Recibir criterios de aceptación claros, precisos y comentarios continuos a medida que se
completa el trabajo.

¿Cómo definir una HU?

Toda necesidad se define como un “Requerimiento”

Debe ser escrita...

En un lenguaje sencillo y práctico

Componentes de una HU
1. Valor para el cliente
2. Esfuerzo estimado
3. Conversación dirigida a conocer información: ¿Por qué? ¿Para?
4. Objetivo de la necesidad
5. Prioridad de cubrir la necesidad
6. Los riesgos de no cubrir la necesidad
a. PMO análisis de riesgos de todo el proyecto
i. En caso de no tener un recurso ¿qué se hace?
b. Product owner y equipo análisis de riesgos de las funcionalidades
7. Resultado esperado

Sesión inicial
Objeti vo
Exponer la necesidad del área de negocios a modo general
Crear un espacio de trabajo colaborativo y participativo entre todos

Involucrados:
- Product Owner
- Stakeholders
- Equipo de trabajo

Diferencia entre HU agile y una en Kanban

- Sprints, se queman
- Kanban, se ejecutan bajo su flujo de proceso

Fases
- INICIO: análisis.
- DESIGN: Arquitectura, planeación y estimación
- CODING: Desarrollo
- TESTING: Pruebas
o En cascada. Desarrollo- pruebas. 1 a 1
 o Despliegue.

Historias de usuario
Estructura
- Cómo <quién>
- Quiero<qué>
- Para<objetivo>
Oraciones breves, sencillas y fáciles de entender

Ejemplo
- Cómo Analista de reclutamiento
- Quiero tener una base de datos de candidatos elegibles
- Para mejorar el proceso de selección

Tips importantes
1. Identificar el rol que lo solicita
2. Identificar lo que quiere, cómo lo quiere
3. Identificar para que lo quiere, en que le ayuda, que problema resuelve
4. Concretar con el mayor de entendimiento la necesidad del usuario para que cualquiera
pueda comprender lo que se quiere
5. Describir los criterios de aceptación, consideraciones.

Mecanismos y técnicas para construir HU

Invest

Permite diseñar los planteamientos de los requerimientos de la mejor manera posible.

Ofrece crear historias de usuario en la definición de objetivos.

Las historias de usuario deben ser totalmente independientes.

Debe evitar crear dependencias de otras historias para evitar provocar de prueba en la planificación.
Se puede reducir para combinarla en una o dividirla en tareas más pequeñas.

Las historias de usuario deben ser negociables, ya que sus detalles serán aclarados en la sesión con
el cliente.
Evitar dar demasiados detalles, ya que limita la conversación, debe estar abierta a discusión e
iteración.

Las historias de usuario deben ser valiosas, agregar valor tangible a los usuarios o cliente.
Una manera para que la HU sea valiosa es que la escriba el usuario.

Las historias de usuario deben poder ser estimada con la precisión suficiente para ayudar al cliente a
priorizar y panificar su implementación.
La estimación generalmente la realizará el equipo de trabajo y está directamente relacionada con el
tamaño de la historia de usuario (una de gran tamaño, es difícil de estimar)
En caso de tener poco conocimiento en la necesidad, se requerirá más fases de conversación hasta
poder entender la funcionalidad, la necesidad y el valor que se requiere.

La HU debe ser lo suficientemente clara y precisa para que el equipo de desarrollo pueda
comprenderla y estimarla.

Las historias de usuarios deben englobar como mucho unas pocas semanas o por días. Una
descripción corta ayuda a disminuir el tamaño de unas historias de usuario facilitando así su
estimación.
HU factible en un tiempo relativamente corto y que no implique demasiada complejidad en una sola
tarea. Esto permitirá entregar una nueva versión de producto con frecuencia.

Las historias de usuario deberían ser capaz de ser probadas.

Si el cliente no sabe cómo probar la historia de usuario significa que no es del todo clara o que no es
valiosa.

SPIDR – TECNICA PARA DIVIDIR USER STORIES

 Invest HU correcta.
 SPIDR 5 pasos como estrategia iterativa e incremental

Spikes (Pruebas de concepto)

Pequeñas pruebas de concepto o prototipo que permiten evaluar la viabilidad de una historia de
usuario.

Ejecución de pruebas de concepto para desarrollar el conocimiento necesario para entender mejor
el alcance de una solución y así reducir la incertidumbre respecto a una HU.

Después de ejecutada la prueba de concepto se podrán tomar las decisiones adecuadas para refinar
o definir el alcance de una historia con bases más sólidas.

Path (Ruta)

Es común que al enfocar unas historias de usuario se presenten varias alternativas o cambios que
puedan tomarse en cuenta como posibles soluciones para alcanzar los objetivos.

Estos cambios pueden agregar complejidad a las HU haciéndolas más grandes. Para poder reducirlas
y hacerlas más pequeñas, utilizar las mismas estrategias.

Interfaces

Varios medios por los cuales un usuario puede interactuar con un sistema, es posible establecer una
estrategia que permita dividir las HU en términos de la diversidad que aporta cada una de dichas
interfaces seccionándolas por tipo de ventana gráfica.

Cada interfaz gráfica puede generarse como una HU.

Esta diversificación puede ser tan extensa como sea necesaria y podrían legar a ser tan específicas,
como simplicidad aporte en la implementación de la funcionalidad.

Data (Datos)
Otra de los pasos utilizados en la técnica SPIDR para la división de HU en elementos más pequeños
viene dada por la gestión de la complejidad según los datos que en estas se utilizan.

Para la complejidad de los datos, lo que se plantea es que la división que se realice facilite la
incorporación de dicha complejidad de manera incrementa y sencilla.

Rules (Reglas)
Utilizar ciertas condiciones de negocio como factor diferenciador.

Propone que, aunque existan ciertas condiciones especiales que deben cumplirse para satisfacer las
necesidades del negocio, las mismas sean incorporadas paulatinamente como aplicaciones
incrementales del alcance inicial y así puedan ser cubiertas.
Pueden incorporarse incrementalmente por Sprint como nuevos requerimientos.