1.
Scrum
Metodología Ágil

2.
Objetivo del
curso
 Busca transmitir a los participantes el enfoque de Scrum de una
manera práctica para aplicar en su organización, que les permita
implementar este modelo de proceso ágil en el desarrollo de
software aprovechando sus ventajas en las tareas de
administración de proyecto.
 Comprender su metodología, los roles, actividades y artefactos
que le componen.

3.
Audiencia
 Profesionales que participan en proyectos de desarrollo que
deseen una alternativa probada para un desarrollo que responda a
las restricciones de tiempo sin sacrificar el control o la calidad.
 Ingenieros de procesos que deseen agregar prácticas ágiles a sus
procesos de desarrollo des software.
 Administradores de Proyectos que requieran utilizar prácticas
ágiles de administración de proyectos.
 Programadores interesados en desarrollo ágil.

4.
Desarrollo ágil
de software
 Son métodos de ingeniería del software
basados en el desarrollo iterativo e
incremental, donde los requisitos y
soluciones evolucionan mediante la
colaboración de grupos auto
organizados y multidisciplinarios.
 Existen muchos métodos de desarrollo
ágil; la mayoría minimiza riesgos
desarrollando software en lapsos cortos.

5.
Desarrollo ágil
de software
 El software desarrollado en una unidad de
tiempo es llamado una iteración, la cual debe
durar de una a cuatro semanas.
 Cada iteración del ciclo de vida incluye:
planificación, análisis de requisitos, diseño,
codificación, revisión y documentación.
 Una iteración no debe agregar demasiada
funcionalidad para justificar el lanzamiento del
producto al mercado, sino que la meta es
tener una «demo» (sin errores) al final de cada
iteración.
 Al final de cada iteración el equipo vuelve a
evaluar las prioridades del proyecto.

6.
Desarrollo ágil
de software
 Los métodos ágiles enfatizan las
comunicaciones cara a cara en vez de la
documentación. La mayoría de los equipos
ágiles están localizados en una simple oficina
abierta, a veces llamadas "plataformas de
lanzamiento" (bullpen en inglés).
 La oficina debe incluir revisores, escritores de
documentación y ayuda, diseñadores de
iteración y directores de proyecto. Los
métodos ágiles también enfatizan que el
software funcional es la primera medida del
progreso.
 Combinado con la preferencia por las
comunicaciones cara a cara, generalmente los
métodos ágiles son criticados y tratados como
"indisciplinados" por la falta de
documentación técnica.

7.
Algunos
métodos ágiles
 Adaptive Software Development (ASD).
 Agile Unified Process (AUP).
 Crystal Clear.
 Essential Unified Process (EssUP).
 Feature Driven Development (FDD).
 Lean Software Development (LSD).
 Kanban.
 Open Unified Process (OpenUP).
 Programación Extrema (XP).
 Método de desarrollo de sistemas dinámicos (DSDM).
 Scrum.
 G300.

8.
Manifiesto ágil
Individuos e
interacciones
Software que
funciona
Colaboración con
el cliente
Responder ante
el cambio
Procesos y
herramientas
Documentación
exhaustiva
Negociación de
contratos
Seguimiento de
un plan
sobre
sobre
sobre
sobre

9.
Principios del
desarrollo ágil
 Nuestra principal prioridad es satisfacer al cliente a través de la
entrega temprana y continua de software que aporte valor.
 Aceptamos de buen grado cambios en los requisitos, incluso si
llegan tarde al desarrollo. Los procesos ágiles aprovechan el
cambio para la ventaja competitiva del cliente.
 Entregar con frecuencia software que funcione, desde un par de
semanas hasta un par de meses, con preferencia a la escala de
tiempo más corta.
 La gente de negocio y los desarrolladores deben trabajar juntos de
forma cotidiana durante todo el proyecto.

10.
Principios del
desarrollo ágil
 Construir proyectos en torno a individuos
motivados. Darles el entorno y el apoyo que
necesitan y confiar en que ellos conseguirán
hacer el trabajo.
 El método más eficiente y efectivo de
comunicar información hacia y dentro de un
equipo de desarrollo es la conversación cara
a cara.
 El software que funciona es la principal
medida de progreso.
 Los procesos ágiles promueven el desarrollo
sostenido.
 Los promotores, desarrolladores y usuarios
deben ser capaces de mantener un ritmo
constante de forma indefinida.

11.
Principios del
desarrollo ágil
 La atención continua a la excelencia técnica y al buen diseño
mejora la agilidad.
 La simplicidad, el arte de maximizar la cantidad de trabajo que no
se hace, es esencial.
 Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.
 En intervalos regulares, el equipo reflexiona en cómo ser más
efectivo, se afina y ajusta su comportamiento de acuerdo con
esto.

12.
Ejercicio

13.
Historia
 El concepto de Scrumtiene su origen en un estudio de 1986 sobre
los nuevos procesos de desarrollo utilizados en productos
exitosos en Japón y los Estados Unidos (cámaras de fotos de
Canon, fotocopiadoras de Xerox, automóviles de Honda,
ordenadores de HP y otros).
 Los equipos que desarrollaron estos productos partían de
requisitos muy generales, así como novedosos, y debían salir al
mercado en mucho menos del tiempo del que se tardó en lanzar
productos anteriores.

14.
Historia
 Estos equipos seguían patrones
de ejecución de proyecto muy
similares. En este estudio se comparaba
la forma de trabajo de estos equipos
altamente productivos y
multidisciplinares con la colaboración
entre los jugadores de Rugby y su
formación de Scrum (melé en español).
 En la actualidad, Scrum se está utilizando
en diferentes tipos de negocio y,
especialmente, en el desarrollo de
software. La Scrum Alliance es la
organización sin ánimo de lucro que se
encarga de difundir Scrum en este
ámbito.

15.
Principios de
Scrum
 Comunicación verbal directa entre los
involucrados en el proyecto.
 Predisposición y respuesta al cambio.
 Colaboración estrecha con el cliente.
 Desarrollo incremental con entregas
funcionales frecuentes.
 Motivación y responsabilidad de los
equipos por la autogestión, auto-organización
y compromiso.
 Simplicidad gracias a que sólo se usan
artefactos necesarios en la gestión del
proyecto.
 Prefiere el conocimiento tácito de las
personas al explícito de los procesos.

16.
Definición de
Scrum
 Es una metodología ágil y flexible para
gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno
de la inversión para su empresa (ROI).
 Se basa en construir primero la
funcionalidad de mayor valor para el
cliente y en los principios de inspección
continua, adaptación, auto-gestión e
innovación.

17.
Fundamentos
de Scrum
 Es una metodología ágil para desarrollo y mantenimiento de Software.
 Basado en un desarrollo iterativo e incremental.
 Mantiene grupos auto-organizados y multidisciplinares.
 Permite una rápida adaptación a cambios, minimiza costos y tiempos.
 Prevé la adaptación continua a las circunstancias de evaluación del
proyecto.

18.
Fundamentos
de Scrum
 El desarrollo incremental de los requisitos del proyecto en bloques
temporales cortos y fijos (iteraciones de un mes natural y hasta de
dos semanas, si así se necesita).
 La priorización de los requisitos por valor para el cliente y coste de
desarrollo en cada iteración.
 El control empírico del proyecto. Por un lado, al final de cada
iteración se demuestra al cliente el resultado real obtenido, de
manera que pueda tomar las decisiones necesarias en función de lo
que observa y del contexto del proyecto en ese momento. Por otro
lado, el equipo se sincroniza diariamente y realiza las adaptaciones
necesarias.

19.
Fundamentos
de Scrum
 La potenciación del equipo, que se
compromete a entregar unos
requisitos y para ello se le otorga la
autoridad necesaria para organizar
su trabajo.
 La sistematización de la
colaboración y la comunicación
tanto entre el equipo y como con el
cliente.
 El timeboxing de las actividades del
proyecto, para ayudar a la toma de
decisiones y conseguir resultados.

20.
Características
 Equipos auto-organizados.
 El producto avanza en una serie de
“Sprints” de dos semanas a un mes
de duración.
 No hay prácticas de ingeniería
prescritas.
 Utiliza normas generativas para crear
un entorno ágil para la entrega de
proyectos.
 Los requisitos son capturados como
elementos de una lista de “Product
Backlog”.

21.
Beneficios
 Alta capacidad de reacción ante los
cambios de requerimientos
generados por necesidades del
cliente o evoluciones del mercado.
 La metodología está diseñada para
adaptarse a los cambios de
requerimientos que conllevan los
proyectos complejos.
 La metódica de trabajo y la
necesidad de obtener una versión
funcional después de cada iteración,
ayuda a la obtención de un software
de calidad superior.

22.
Beneficios
 Mediante esta metodología se conoce la velocidad media del
equipo por sprint (los llamados puntos historia), con lo que
consecuentemente, es posible estimar fácilmente para cuando se
dispondrá de una determinada funcionalidad que todavía está en
el Backlog.
 El hecho de llevar a cabo las funcionalidades de más valor en
primer lugar y de conocer la velocidad con que el equipo avanza en
el proyecto, permite despejar riesgos eficazmente de manera
anticipada.

23.
Razón de
utilizar Scrum
 Con esta metodología el cliente se entusiasma
y se compromete con el proyecto dado que lo
ve crecer iteración a iteración. Asimismo le
permite en cualquier momento realinear el
software con los objetivos de negocio de su
empresa, ya que puede introducir cambios
funcionales o de prioridad en el inicio de cada
nueva iteración sin ningún problema.
Promueve la innovación, motivación y
compromiso del equipo que forma parte del
proyecto, por lo que los profesionales
encuentran un ámbito propicio para
desarrollar sus capacidades.

24.
Ventajas
 Trabaja con iteraciones rápidas.
 La idea principal es ponerse a trabajar cuanto antes y que el cliente
vaya viendo avances.
 Fácil de implantar.
 Ofrece ventaja competitiva pues se adapta al cambio.
 Evita burocracia y generación de documentos.
 Se obtiene Software con requerimientos exigidos de manera
rápida.
 Creatividad y efectividad del equipo auto administrado y entorno
libre de interrupciones.
 Reuniones dedicadas a problemas recientes.

25.
Desventajas
 Dificultad de aplicación para grandes proyectos.
 Existe delegación de responsabilidades con posibilidad de fallo.
 Se requiere de un agile champion para monitorizar el desarrollo.
 Problemas si el precio y fecha de entrega son cerrados.
 Presuposiciones de equipos formados y motivados, clientes
involucrados en el desarrollo y su participación, y que la
documentación no es necesaria.

26.
Campo de
aplicación
 Software comercial
 Desarrollo de videojuegos
 Desarrollos internos
 Desarrollos bajo contrato
 Aplicaciones financieras
 Aplicaciones certificadas ISO 9001
 Sistemas críticos de soporte vital
 Software de control satelital
 Aplicaciones para Handheld
 Sitios web
 Sistemas embebidos

27.
Ejercicio

28.
Scrum
Framework
 Roles o Componentes:
 Product Owner (Propietario del producto)
 Scrum Master (Scrum Manager)
 Scrum Team (Equipo de desarrollo)
 Stakeholders (Usuarios, Clientes)
 Artefectos o Elementos:
 Product Backlog (Pila de Producto)
 Sprint Backlog (Pila de Sprint)
 Burndown Chart
 Incremento
 Meetings o Reuniones:
 Sprint Planning
 Sprint Review
 Sprint Retrospective
 Daily Scrum Meeting

29.
Roles
Product Owner:
 Define las funcionalidades del producto.
 Representa a los stakeholders (cliente
interno o externo).
 Ajusta funcionalidades y prioridades en cada
iteración.
 Acepta o rechaza el resultado del trabajo del
equipo.
 Es el responsable de obtener el mayor valor
de producto.
 Es el que exige y prioriza los requerimientos
del producto.

30.
Roles
Scrum Master o Scrum Manager:
 Representa a la gestión del proyecto.
 Responsable del funcionamiento y productividad
del equipo de desarrollo.
 Escudo del equipo de interferencias externas.
 Responsable de promover los valores y prácticas
de Scrum.
 Permite la estrecha cooperación en todos los roles
y funciones.
 Se asegura que se sigan los procesos y del
seguimiento de la metodología guiando las
reuniones y ayudando al equipo ante cualquier
problema que pueda aparecer.

31.
Roles
Scrum Team:
 Equipos de 5 a 9 personas,
multidisciplinares y multifuncionales.
 Incluye a los desarrolladores, testers,
diseñadores, analistas.
 Responsables de implementar las
funcionalidades del Product Owner.
 Los miembros deben ser full-time.
 Comprometidos y auto-organizados.
 Solo puede haber cambios de miembros
entre los sprints.
 Grupo de trabajo que desarrollan el
producto Sprint a Sprint.

32.
Roles
Stakeholders (Clientes,
Usuarios):
 Sólo participan directamente en
las revisiones del sprint.
 Hacen posible el proyecto.
 Beneficiarios finales del producto.
 Aportan ideas, sugerencias o
necesidades basados en el
progreso del proyecto.

33.
Artefactos
Product Backlog:
 Lista de requisitos de usuario que se origina
con la visión inicial del producto.
 Idealmente cada tema tiene valor para el
usuario o el cliente.
 Va creciendo y evolucionando durante el
desarrollo por lo que nunca llega a ser una
lista definitiva.
 Todas las tareas, funcionalidades o
requerimientos a realizar.
 Marcadas y priorizadas por el ProductOwner.
 Repriorizadas al comienzo de cada Sprint.

34.
Ejemplo de
Product
Backlog

35.
Artefactos
Sprint Backlog:
 Es una tarea que proviene de una lista
de tareas (Actividades) con una breve
declaración de cuál será el foco del
trabajo durante el sprint.
 Deben realizarse entre 2 y 4 semanas.
 No pueden ser alteradas o
modificadas.
 Es la lista de trabajos a realizar por el
equipo durante el sprint para generar
un avance.

36.
Ejemplo de
Sprint Backlog

37.
Artefactos
Burndown Chart:
 Gráfico que controla el progreso del
sprint y la cantidad restante de
trabajo por hacer.
 Re-estima las tareas o se añaden
nuevas tareas.
 Ayuda a la evaluación del proceso de
cada sprint por parte de los
Stakeholders.

38.
Ejemplo de
Burndown
Chart

39.
Artefactos
Incremento:
 Es el resultado entregado al
final de cada Sprint.

40.
Meetings o
reuniones
Sprint Planning meeting:
 Reunión de planificación del Sprint
Backlog y previa para el inicio de
un Sprint.
 Se priorizan los requerimientos.
 Determina el trabajo y objetivos a
cumplir en la iteración.
 Duración con tiempo máximo de 8
horas.
 Participa: Scrum Master, Scrum
Team y el ProductOwner.

41.
Meetings o
reuniones
Beneficios del Sprint Planning Meeting:
 Productividad mediante comunicación y creación de sinergias:
 Todos los miembros del equipo tienen una misma visión del objetivo y se ha
utilizado los conocimientos y las experiencias de todos para elaborar la mejor
solución entregable en el mínimo tiempo y con el mínimo esfuerzo,
eliminando tareas innecesarias, detectando conflictos y dependencias entre
tareas, etc.
 Potenciación del compromiso del equipo sobre el objetivo común de la
iteración:
 Es todo el equipo quien asume la responsabilidad de completar en la iteración
los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se
detecta algún impedimento que bloquea el progreso de la iteración,
especialmente si cuando se está llegando al final de la iteración es necesaria la
participación de todos para poder completar los objetivos comprometidos.
 Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las
que se autoasignó) en los tiempos que proporcionó. Si existe falta de
compromiso con respecto al resto de miembros del equipo se hará muy
evidente en las reuniones diarias de sincronización del equipo (Scrum daily
meeting).
 Una estimación conjunta es más fiable, dado que tiene en cuenta los
diferentes conocimientos, experiencia y habilidades de los integrantes del
equipo.

42.
Meetings o
reuniones
Sprint Review meeting:
 Reunión informal de revisión del Sprint
con duración de 2 a 4 horas.
 Se realiza al finalizar un Sprint.
 El Scrum Team muestra avances en vivo
al Product Owner.
 Se presentan nuevas funcionalidades y
se genera un feedback del producto.
 La revisión del sprint es el análisis y
revisión del incremento generado.

43.
Meetings o
reuniones
Beneficios del Sprint Review:
 El cliente puede ver de manera objetiva cómo han sido desarrollados
los requisitos que proporcionó, ver si se cumplen sus expectativas,
entender más qué es lo que necesita y tomar mejores decisiones
respecto al proyecto.
 El equipo puede ver si realmente entendió cuáles eran los requisitos
que solicitó el cliente y ver en qué puntos hay que mejorar la
comunicación entre ambos.
 El equipo se siente más satisfecho cuando puede ir mostrando los
resultados que va obteniendo. No está meses trabajando sin poder
exhibir su obra.

44.
Meetings o
reuniones
Restricciones del Sprint Review:
 Sólo se pueden mostrar los requisitos completados, para que el
cliente no se haga falsas expectativas y pueda tomar decisiones
correctas y objetivas en función de la velocidad de desarrollo y el
resultado realmente completado.
 Un requisito no completado quedará como un requisito más a
replanificar.

45.
Meetings o
reuniones
Sprint Retrospective:
 Retrospectiva al finalizar un Sprint y dura aprox. 1 hora.
 El Product owner revisa con el equipo los objetivos iniciales del Sprint
backlog concluido, se aplican cambios y ajustes necesarios.
 Se marcan aspectos positivos (para replicarlos) y los aspectos
negativos (para evitarlos) del Sprint.

46.
Meetings o
reuniones
Beneficios del Sprint Retrospective:
 Incrementa la productividad en el proyecto, la calidad del producto
(cosa que permite hacerlo crecer de manera sostenida) y potencia el
aprendizaje del equipo de manera sistemática, iteración a iteración,
con resultados a corto plazo.
 Aumenta la motivación del equipo dado que participa en la mejora de
proceso, se siente escuchado, toma decisiones consensuadas (y más
sostenibles) para ir eliminando lo que molesta e impide que sea más
productivo.

47.
Meetings o
reuniones
Restricciones del Sprint Retrospective:
 En necesario que el Equipo y el Facilitador dispongan de autoridad,
mecanismos y recursos para ir mejorando su forma de trabajar y el
contexto del proyecto.
 Es frustrante encontrar sistemáticamente los mismos obstáculos y no
poder solucionarlos.

48.
Meetings o
reuniones
Daily Scrum Meeting (Reunión Diaria):
 Es la primer actividad del día con duración aprox. 15 minutos.
 Tarea iterativa todos los días de cada Sprint.
 Se verifica el avance de las tareas y sus planificaciones.

49.
Meetings o
reuniones
Beneficios del Daily Scrum Meeting:
 Aumentar la productividad en el proyecto y potencia el compromiso
de equipo, dado que cada miembro pone de manifiesto delante del
resto:
 Las tareas que pueden afectar a otros miembros del equipo, por que
impactan en su trabajo o por que hay dependencias (especialmente si
existe un retraso).
 Los impedimentos con que se encuentra. El resto de miembros del
equipo pueden ofrecer ayuda a otros en la realización de tareas o para
resolver problemas que ya tuvieron anteriormente. El Facilitador
(Scrum Master) se encargará de solucionar los impedimentos que el
equipo no puede solucionar por sí solo o que le quitan tiempo para
cumplir con su compromiso fundamental de desarrollo de requisitos.
 Las tareas no planeadas que está realizando que el equipo no conoce y
puede que no estén alineadas con el compromiso del equipo, aunque
él crea que lo que está haciendo es lo mejor que se puede hacer.

50.
Meetings o
reuniones
Beneficios del Daily Scrum Meeting:
 Continuación:
 Cuáles son sus necesidades. Cada miembro entiende las necesidades
de los otros miembros del equipo respecto a su trabajo, de manera que
pueden colaborar y adaptar sus trabajos para que den el máximo valor
y no realizar tareas que no proporcionan ningún beneficio al resto del
equipo.
 Cuál es su ritmo de trabajo. Se hace visible si de manera continua un
miembro del equipo está realizando tareas por debajo del rendimiento
esperado. Se evita que una persona señale con el dedo a otra, dado
que la reunión de sincronización pone a todos los miembros del equipo
en la misma situación de tener que explicar en qué tareas están
trabajando.
 Cuáles son los criterios que está utilizando para realizar sus tareas, de
manera que estén alineados con los objetivos comunes del equipo.

51.
Meetings o
reuniones
Beneficios del Daily Scrum Meeting:
 Fomentar el aprendizaje de los miembros del equipo, ya que pueden
ver cómo trabajan los otros según sus especialidades y experiencias.
 Conocer el estado de la iteración, ver si es posible completar los
requisitos a que se comprometió el equipo, en vista de las desviaciones
y de las tareas pendientes.

52.
Meetings o
reuniones
Restricciones del Daily Scrum Meeting:
 La reunión diaria de estado y sincronización del equipo no es para
resolver problemas, los problemas se resuelven después de la reunión.
 No a todos los miembros del equipo les interesan todos los detalles de
cada tema.
 El equipo debe contar con unos criterios consensuados sobre el
proceso de ejecución de las de tareas.
 En la reunión los miembros del equipo programan reuniones entre
ellos donde colaborar sincronizando tareas, ayudando a resolver
problemas, etc.

53.
Meetings o
reuniones
Restricciones del Daily Scrum Meeting:
 No puede haber una persona explicando su estado mientras otras "se
han apartado" de la reunión para comentar un tema particular. Si
apareciese alguna conversación de interés común (que debe ser
rápida), debe poder ser escuchada por todo el equipo sin distraer el
principal objetivo de que todos conozcan en qué están trabajando los
demás. Si la mini conversación no es del interés de todos, debe
hacerse después de la reunión.
 El proceso de ejecución de las tareas debe estar consensuado para
evitar que cada reunión sea una exposición de discrepancias entre los
miembros del equipo.

54.
Ejercicio

55.
Scrum

56.
Prácticas
 Se realizan ciclos (o iteraciones) de duración fija llamadas Sprints.
Se recomienda que la duración de un Sprint sea de 2, 3 o 4
semanas.
 Durante el Sprint el objetivo del equipo es generar un incremento
visible, utilizable, entregable.

57.
Prácticas
 Al inicio de cada Sprint se realiza una Planning Meeting durante la
cual se revisa el Backlog de proyectos (listado de requisitos de alto
nivel pendientes, previamente priorizados por el Product Owner).
 En esta reunión el Product Owner identifica los proyectos que quiere
resolver y los describe al equipo. Entonces, el equipo determina
cuáles de estos proyectos pueden ser comprometidos a completar
para el Sprint.
 Se identifican tareas y cada una es estimada (1-16 horas).
 Realizado colaborativamente, no solo por el Scrum Master.

58.
Prácticas
 Durante el transcurso del Sprint
no se puede modificar el
alcance del mismo, es decir, se
intentará mantener congelados
los requisitos hasta que el
mismo finalice.
 En la práctica, nos hemos
reservado parte de nuestro
tiempo para lidiar con urgencias
que no pueden esperar un ciclo
para ser resueltas.

59.
Prácticas
 Diariamente se realiza una Daily Meeting que no debe durar más de
15 minutos, donde cada persona del equipo comparte las tareas
realizadas, lo que piensa hacer hasta la reunión del día siguiente y si se
ha topado con algún impedimento que no le permita avanzar de
acuerdo a lo comprometido.
 Ésta reunión no es para la solución de problemas.
 Todos están invitados, pero solo los miembros del equipo, Scrum
master y Product Owner pueden hablar.
 Ayuda a evitar otras reuniones innecesarias.
 Será moderado por el Scrum master, y cada miembro del Scrum Team
responde 3 preguntas tomando en cuenta que no es para dar un
reporte de status, si no para tratar compromisos:
 Qué hice ayer?
 Qué tengo voy a hacer hoy?
 Qué dificultades tengo en mi camino?

60.
Prácticas
 Al final del Sprint, luego del Deploy /
Release / Incremento en el producto, se
realiza una Retrospective Meeting durante
la cual el equipo comparte libremente
opiniones sobre las cosas que salieron bien
(y desean repetirse a futuro) y las cosas que
salieron mal (y deben evitarse a futuro).
 Periódicamente, se echa un vistazo a lo que
funciona y lo que no.
 Tiempo aproximado de la reunión de 15 a 30
minutos.
 Todo el equipo participa (Scrum Master,
Product Owner, Scrum Team, posiblemente
clientes y otros).

61.
Ejercicio

62.
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.
 Son utilizadas en las metodologías de desarrollo ágiles para la
especificación de requerimientos (acompañadas de las discusiones
con los usuarios y las pruebas de validación). Cada historia de
usuario debe ser limitada, esta debería poderse escribir sobre una
nota adhesiva pequeña.
 Son una forma rápida de administrar los requerimientos de los
usuarios sin tener que elaborar gran cantidad de documentos
formales y sin requerir de mucho tiempo para administrarlos.
 Permiten responder rápidamente a los requerimientos
cambiantes.

63.
Características
de las Historias
de Usuario
 Independientes unas de otras: De ser necesario, combinar las
historias dependientes o buscar otra forma de dividir las historias
de manera que resulten independientes.
 Negociables: La historia en si misma no es lo suficientemente
explícita como para considerarse un contrato, la discusión con los
usuarios debe permitir esclarecer su alcance y éste debe dejarse
explícito bajo la forma de pruebas de validación.
 Valoradas por los clientes o usuarios: Los intereses de los
clientes y de los usuarios no siempre coinciden, pero en todo caso,
cada historia debe ser importante para alguno de ellos más que
para el desarrollador.

64.
Características
de las Historias
de Usuario
 Estimables: Un resultado de la discusión de una historia de
usuario es la estimación del tiempo que tomará completarla. Esto
permite estimar el tiempo total del proyecto.
 Pequeñas: Las historias muy largas son difíciles de estimar e
imponen restricciones sobre la planificación de un desarrollo
iterativo. 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.

65.
Estructura de
la Historia de
Usuario
 ID: Identificador de la historia de usuario.
 TÍTULO: Título descriptivo de la historia de usuario.
 DESCRIPCIÓN: Descripción sintetizada de la historia de usuario.
 ESTIMACIÓN: Estimación del coste de implementación en unidades de
desarrollo (estas unidades representarán el tiempo teórico de
desarrollo/hombre que se estipule al comienzo del proyecto).
 DEPENDENCIAS: Una historia de usuario no debería ser dependiente de
otra historia, pero a veces es inevitable. En este apartado se indicarían
los IDs de las tareas de las que depende una tarea.

66.
Estructura de
la Historia de
Usuario
 PRIORIDAD: Prioridad en la implementación de la historia de usuario
respecto al resto de las historias de usuario. A mayor número, mayor
prioridad. Otra aproximación a la priorización de tareas se hace a través
del método MoSCoW:
 M – Must, se debe completar este requerimiento para finalizar el
proyecto.
 S – Should, se debe completar este proyecto por todos los medios,
pero el éxito del proyecto no depende de él.
 C – Could, se debería completar este requerimiento si su
implementación no afecta a la consecución de los objetivos
principales del proyecto.
 W –Would, se puede completar este requerimiento si sobra tiempo
de desarrollo (o en futuras versiones del mismo).

67.
Ejercicio

68.
Fuente de
información
 Scrum and The Enterprise por Ken Schwaber
 Agile Software Development Ecosystems por JimHighsmith
 www.agilemanifiesto.org
 www.scrumalliance.org
 www.controlchaos.com
 www.proyectosagiles.org/historia-de-scrum
 Cockburn, Alistair. Agile Software Development. Highsmith Series.
 The New New Product Developement Game, por Hirotaka
Takeuchi (Hitotsubashi University) y Ikujiro Nonaka. Harvard
Business Review, Enero-Febrero de 1986.

69.
Gracias.
L.S.C. Karla Leticia AGUILAR LÓPEZ