1

Metodologías Agiles
Introducción

Una metodología Ágil es una metodología efectiva par a modelar y

documentar un proyecto de software, es una colección de valores principios y
practicas para modelar software que puede ser aplicados de manera simple y
ligera.

La metodología Agil tiene varios principios que la diferencian sobre las

metodologías tradicionales reflejados en un Manifiesto que enuncia cuatro
valores que son :

1. Los individuos y sus relaciones sobre las personas y los procesos .- con
este principio se hace manifiesto el énfasis de esta metodología sobre
las personas , ya que ellas son de las que depende el éxito o el fracaso
de un proyecto, es a las que se les debe motivar

2. Un Software funcional, que trabaje sobre la documentación mas

completa .- con este principio se trata de decir que lo mas importante es
que el software trabaje , cumpla con las necesidades de negocio, no
hacer de la documentación un fin en si mismo, ya que esta es solo para
dar soporte , no es el objetivo primario del desarrollo, existen
situaciones en donde incluso la documentación podría ser innecesaria,
por ejemplo una pequeña aplicación emergente, que una vez pasada la
emergencia , esta aplicación desaparece, el cargar de documentación
de requerimientos, arquitectura , testeo etc. Podría considerarse de
sobra, sin embargo eso no quiere decir que no es necesaria la
documentación, esta debe existir pero solo la suficiente

3. Colaboración el cliente sobre el contrato de negocio .- Se trata de

colaborar con el cliente el mayor tiempo no de luchar con el sobre un
contracto minucioso , esto puede ser difícil ya que los clientes no están
acostumbrados, ellos están acostumbrados a trabajar sobre un contrato
con el que puedan defenderse si las cosas van mal

4. Ser capaz de responder a los cambios y no obsesionarse sobre el

seguimiento de un plan .-Es tener la capacidad de adaptación, no decir
NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso
hacer un lado la planificación

Estos valores han dado lugar a doce principios que son :

1. La satisfacción del cliente

2. Bienvenida a los cambios que puedan ocurrir

3. Entregar regularmente software que trabaje

 2

4. Gente de negocios y desarrolladores trabajan diariamente en

conjunto

5. Construcción de proyectos alrededor de individuos motivados para

esto

6. Las comunicaciones cara a cara son las mejores

7. Software que trabaje es la mejor medida del progreso

8. Atención continua a la excelencia y al buen diseño

9. Promover el desarrollo sostenible

10.Simplicidad

11.Las mejores arquitecturas, requerimientos , y diseños emergen de

equipos auto-organizados

12.Introspección , los equipos deben regularmente hacerse una revisión

hacia si mismos y sus procesos para intentar mejorar

Modelado Agil

En el modelado Agil se trata de hallar el equilibrio ente exceso de

modelado y carencia de este, se intenta que el modelado no se convierta en
una carga, que sea suficiente para documentar el sistema, se pueden
aprovechar el modelado de un proyecto RUP , esto es la documentación UML,
se intenta promover procesos ligeros.

Con la modelación Agil se siguen tres objetivos que son:

• Promover y definir un grupo de valores, practicas y principios que

ayudan a producir los modelos adecuados

• Orientación de cómo aplicar el modelado de proyectos agiles

• Orientación de cómo aplicar el modelado Agil a otro tipo de procesos o

metodologías (por ejemplo RUP)

Criterios para un meldado Agil

Un modelado Agil debe seguir estos criterios :

• Deben dar valor positivo, deben servir realmente de ayuda para dar un
software funcional

• Deben solo cumplir su propósito y no mas , esto es dar a entenderse solo

con los suficiente, no usar herramientas pesadas, por ejemplo las
ofrecidas por Rational Rose, no ser tan estricto
 3

• Debe ser comprensible para su audiencia, no para todos, el nivel de

detalle debe ser comprensible de acuerdo a la audiencia a la que se le
presente

• Deben ser lo suficientemente precisos

• Deben ser lo suficientemente consistentes , modelos mas detallados que

otros pueden causar confusión a las audiencias a las que van dirigidos.

• Deben ser lo suficientemente detallados, muchos detalles pueden ser

irrelevante de acuerdo a quien se dirige el modelo.

• Tan simples como sea posible.

La documentación de las metodologías agiles debe ser tan simple como

sea posible y de acuerdo a la audiencia a la que vaya dirigida, no es un
modelado tan prescriptivo, no da recetas de diseño, no crea documentación
innecesaria, se puede usar cualquier tipo de diseño o documentación que nos
ayude, puede haber procesos que sea difícil capturarlos con los diagramas
conocidos, pero si otros, una metodología Agil podría asociarlos.

Ejemplos de metodologías consideradas Agil son

• Programación Extrema
• Scrum
• MSF 4.0 Microsoft
• RAD *
• Cristal
• RUP Agil
• Otras ..

En este documento hablaremos de las primeras cuatro metodologías, estas

metodologías pueden combinarse , por ejemplo Programación Extrema y
Scrum , RAD puede integrarse con otras etc.

Aspectos de las Metodologias Agiles

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantación de

una gestión ágil de proyectos como Scrum:

• Cultura de empresa basada en trabajo en equipo, delegación,

creatividad y mejora continua.
• Compromiso del cliente .- Scrum exige del cliente una alta
implicación y una dedicación regular:.
• Compromiso de la Dirección de la organización para resolver
problemas endémicos y realizar cambios organizativos, formando
 4

equipos autogestionados y multidisciplinares y fomentando una

cultura de gestión basada en la colaboración y en la facilitación.
• Compromiso conjunto y colaboración de los miembros del
equipo.
• Relación entre proveedor y cliente .- las dos partes asumen que
habrá cambios para que el cliente obtenga lo que realmente
necesita, no lo que está escrito en un documento
• Facilidad para realizar cambios en el proyecto. Para poder
utilizar Scrum se debe poder ir incorporando requisitos de manera
incremental en el producto del proyecto
• Tamaño de cada equipo entre 5 y 9 personas (con técnicas de
colaboración entre equipos que trabajan en el mismo proyecto).
• Equipo trabajando en un mismo espacio común para maximizar la
comunicación.
• Dedicación del equipo a tiempo completo.
• Estabilidad de los miembros del equipo

Herramientas documentales - Historias de Usuario

En la programación XP, suele utilizarse algo similar a lo utilizado en la

Metodologia RUP, esto es los casos de uso, pero en esta Metodologia, el
concepto cambia, ya no es un formato preciso, es mas anecdótico, se trata de
referir la manera en que los usuarios pueden usar el sistema, las historias de
usuario son escritas para los usuarios no para el equipo de desarrollo

Las historias de Usuario no son requerimientos detallados, pueden

obtenerse durante las iteraciones, como una experiencia de uso del sistema
resultado de una iteracion, deben usar la terminología del usuario , un lenguaje
de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo
tan simple como esto que refleja esta Story Card (que es donde se pueden
apuntar aspectos de historias de usuario) y dice :

Un usuario puede mandar su resumen a través de una pagina Web

Mas importante que una Story Card, que es la parte visible de la historia,
son las conversaciones entre clientes y desarrolladores

Una Historia de Usuario describe una funcionalidad, un propósito de un

sistema o software, son tradicionalmente escritas a mano y se componen de
tres aspectos

1. Uno que describa la historia y como planeación y recordatorio

2. Conversaciones que puedan servir para reflejar detalles de la historia

3. Test que puedan documentar cuando una historia ha sido completada

 5

Puede tenerse un proyecto inicial de historias pero pueden surgir otras

durante todo el proyecto, pueden apilarse historias cortas durante una
iteración para su atención, pueden priorizarse en pilas para su desarrollo en
cada iteración
 6

Metodología Ágil - SCRUM

Introducción

Scrum es una metodología ágil, que puede ser usada para manejar el
desarrollo de productos complejos de software , en esta metodología se usan
practicas iterativas e incrementales. Scrum a sido usado desde proyectos
simples hasta en proyectos de cambios estructurales completos en las
empresas para sus negocios . Scrum incrementa significativamente la
productividad y reduce el tiempo de espera para ver los beneficios así como
facilitar la adaptación de los sistemas desarrollados

Características

Scrum por su proceso iterativo incremental produce un grupo de

funcionalidades en cada fin de iteración. Sus características son:

• Scrum es un proceso agile para el manejo y control del trabajo de

desarrollo

• Scrum es un contenedor de practicas de ingeniería existentes

• Scrum es un enfoque basado en equipos , incrementa el desarrollo

cuando los requerimientos cambian rápidamente

• Scrum es un proceso que controla el caos entre los conflictos de interés

y las necesidades

• Scrum es un camino para mejorar las comunicaciones y maximiza r la

cooperación

• Scrum es un camino para detectar la causa y solucionar cualquier

problema en el desarrollo

• Scrum es escalable desde proyectos simples a proyectos completos

organizacionales, Scrum ha controlado y organizado el desarrollo de
productos y proyectos con miles de desarrolladores e implementadores

• Scrum es la ruta para sentirse bien en el trabajo

Naturalmente Scrum se enfoca en la construcción de proyectos exitosos

en las organización, sin mayores cambios dentro de los 30 días de cada carrera
(ciclo) construyendo una funcionalidad completa y demostrada del producto al
final de cada carrera, Scrum puede implementarse al principio o a la mitad de
un proyecto de desarrollo
 7

Scrum es un conjunto de prácticas interrelacionadas y reglas que

optimizan el entorno de desarrollo, reducen la sobrecarga organizativa, y
sincronizan los requisitos del mercado con los prototipos de cada iteración .
Basado en una teoría de control de procesos moderna, Scrum nos da el mejor
software posible teniendo en cuenta los recursos disponibles, una calidad
aceptable, con las fechas requeridas de liberación. Una funcionalidad del
producto útil es dada cada treinta días como requisito, la arquitectura, y el
diseño aparecen, incluso cuando la tecnologías es inestable aun

Scrum como lo muestra la ilustración se basa en el equipo, en reuniones

diarias presididas por el Scrum máster para establecer el estado del proyecto,
y en la salida cada 30 días de características del proyecto finalizadas y listas
para trabajar, el corazón del Scrum es la iteración, que en cada iteración
presenta una mejora del funcionamiento del producto final, en cada iteración
se evalúa la tecnología y capacidades requeridas, diariamente se pueden
modificar el enfoque si se encuentran nuevas dificultades y tratar de
remediarlas, el corazón del Scrum es la productividad

Fig. Proceso de trabajo del Scrum

Las más de cincuenta organizaciones que han usado el Scrum en miles

de proyectos han tenido siempre mejoras en la productividad , las practicas
existentes son envueltas y mejoradas necesariamente y así dar al usuario o
al mercado los incrementos del producto
 8

Scrum ha sido usado producir productos financieros, productos de

Internet . En cada ejemplo, la organización era incapaz producir productos
utilizables en un período de tiempo largo, así que ingenieros, dirección, e
inversionistas estaban profundamente preocupados. Scrum saco del atolladero
y empezó una entrega de producto incremental, a menudo con un primer
producto de utilizable en el primer trimestre

Scrum aplicado para el desarrollo de productos tuvo su primer referencia

en “El nuevo , nuevo producto para el desarrollo de juegos” (Harvard Business
Review 86116:137-146, 1986) y posteriormente aclarada "The Knowledge
Creating Company" ambos por Ikujiro Nonaka y Hirotaka Takeuchi (Oxford
University Press, 1995. Basados en estas ideas y en la investigación de teoría
de procesos y en colaboración con DuPont Advanced Research Facility,
Scrum fue formulado por primera vez y presentado al OMG ( Object
Management Group) en 1995.

Roles del Scrum

Scrum implementa sus procesos a través de tres roles considerados

fundamentales, todas las responsabilidades de dirección son divididas en estos
roles

El propietario del producto

Este rol, representa a la persona interesada en el estado del proyecto y

el sistema resultante, este es el que se enfoca en que se retorne la inversión
(ROI), el backlog proveído a este rol representa una herramienta poderosa al
proyecto, este lo usa para dar a los requerimientos la mas alta prioridad, estos
mismos son el mas alto valor del negocio , este rol conoce cuales son las
funcionalidades requeridas para resolver la problemática del negocio

Los clientes pueden estables los requerimientos que optimizan el ROI al

inicio del proyecto pero ellos no pueden establecer con sus estimados de
manera precisa los esfuerzos implicados durante el desarrollo del proyecto , la
persona en este Rol es la que ajusta el ROI mas frecuentemente y por eso debe
diferenciársele a la persona cliente

El Scrum máster

Es el responsable de los procesos del Scrum, de que finalicé

exitosamente , el que enseña el Scrum a todos los involucrados, el encargado
de organizar e introducir la cultura del Scrum, descubrir los beneficios
esperados y el que se asegura de que se sigan las reglas y practicas del Scrum.
También puede ayudar al equipo a decidir cuales de los elementos
(backlog) deben desarrollarse en cada iteración (sprint)

El equipo
 9

Es el responsable del desarrollo, deben ser auto-dirigidos, auto-

organizados, son los que sacan las características deseadas (el backlog) en
cada iteración, y son los responsables de esto mismo . Es el equipo el que
decide que parte de la funcionalidad (backlog) debe sacarse en cada
incremento

Implementación de Scrum

1.- Comenzar el proceso de Scrum

Debemos seleccionar al equipo , existe una fabula que ejemplifica el

significado del proceso del Scrum:

“Un cerdo y una gallina se encuentran en la calle. La gallina le dice al

cerdo: ¿por qué no abrimos un restaurante?" El cerdo le dice: "Buena idea,
¿cómo se llamaría el restaurante?" La gallina contesta: "¿Por qué no lo
llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría
comprometido pero tú solamente estarías involucrada”

Según esta fabula el equipo consiste de cerdos (gente a la que se le

asigna el trabajo) y los pollos (las personas interesadas pero que no trabajan
directamente en el ) , identificando los cerdos nosotros podemos componer el
equipo de trabajo

Recomendaciones

• No mas de 6 – 9 miembros por equipo

• Si hay mas miembros , romperlos en grupos

• Cada grupo enfocado en una sola área de trabajo

• Todo el staff trabajara en esta área

2.- Nombrar al Scrum Máster

El Scrum máster es la persona que conduce las reuniones diarias, mide

empíricamente los progresos, toma decisiones y resuelve los problemas de
lentitud o trabajo parado, un ingeniero o un director de marketing puede estar
en esta área, es la persona que hace las preguntas referidas en el diagrama de
proceso del Scrum, que se hizo desde la reunión pasada, que problemas ha
habido y que espera para la próxima reunión

3.-Identificar el acumulado

Acumulado (Backlog ) es todo el trabajo pendiente para un área del

producto , bien definido en sus términos
 10

• Listar todo el trabajo a ser realizado

• Agrupar todo el trabajo que puede hacerse en los 30 días

• En áreas no bien definidas o cambiantes establecer un incremento de

horizonte conocido

• Listar todo el trabajo a ser hecho

• Solo una persona encargada de realizar la priorización de trabajos

• El equipo elige el acumulado para el sprint - periodo de 30 días

• Periodo o sprint es el lapso que se da el Scrum para realizar un

incremento este debe ser de 30 días

• Este acumulado se firma por los miembros del equipo

• Solo este acumulado se trabaja durante el periodo

4.- Establecer y conducir la reunión diaria del Scrum

Diariamente se hace una reunión para checar el status del trabajo, donde el
equipo informa de las actualizaciones , la reunión se enfoca en el trabajo que
se esta realizando

Recomendaciones

• Mismo tiempo y lugar

• Evitar siempre buscar un lugar diario

• Evitar que los miembros del equipo se pregunten siempre donde y

cuando son

• Todos los “pollos” deben saber donde y cuando son

• No debe durar mas de treinta minutos

• El Scrum máster debe preguntar las 3 cuestiones básicas ya dichas

• Scrum máster es el responsable de tomar decisiones y resolver los

problemas de trabajo

• Todas las discusiones a las tres cuestiones postergar a posteriores

reuniones
 11

Ventajas del Scrum

• Se enfoca en equipos de trabajo

• Hay una comunicación diaria

• Ofrece una dirección basada en experiencia y de bajo nivel

• Hace los obstáculos visibles

• Se toman decisiones y se resuelven problemas en tiempo real

Historias de Usuario

Basicamente es la misma referencia que en los proyectos XP, esto es

deben ser breves y describir una funcionalidad del negocio que tenga valor, es
una manera de describir un requerimiento funcional en la metodologia agil al
igual que los casos de uso en las metodologias tradicionales

Se pueden obtner de entrevistas ,de reuniones de lluvia de ideas etc. ,

regularmente se anotan en una simple tarjeta de papel, y se colocan en un
tablero (pizarron)

A estas historias se les da una priorizacion de acuerdo a la importancia, ,

y al alcance proporciandos por el dueño del producto, a la estimacion en
tiempo , horas de trabajo por persona esta cantidad es dada por elquipo de
trabajo,

Historias Tecnicas

Las historia tecnicas se refieren a aquellas historias que no describen

una caracteristica del negocio o que aparentemente no dan valor al negocio, a
estas actividades , como instalar un servidor, documentar el diseño general,
optimizacion y limpieza del codigo, etc.

Estas historias se intentan evitar, una manera es tratando de

convertirlas en historias normales con valor de negocio medible, no siempre es
posible, el intentar priorizarlas junto con el resto de las historias es dificil
porque el dueño del producto no las reconoce , lo que se puede hacer es
mantener una lista aparte, el dueño del producto puede verla pero no
modificarla, las actividades para estas historias se acomodan según convenga
en la agenda del sprint

Se puede o no mantener informado al dueño del producto, aunque lo

mejor es siempre mantenerlo informado

Elaboracion del sprint (carrera corta)

 12

En base a las historias de usuario, las actividades de ingenieria (historias

tecnicas) se definen las actividades a realizar para cada una

La elaboracion del sprint consiste en seleccionar en base a la

importancia de negocio y al estimacion de esfuerzo de ingenieria, las mas
adecuadas y comprometerse a solo elaborar esas durante el sprint

Sprint 0 y el DSDM

Se sugiere hacer un sprint 0, que es donde se hacen los analisis y

diseños previos, es un sprint para trazar la ruta del proyecto. Esto se hace
para poder ir de acuerdo al modelo de procesos DSDM dado por el DSDM
Consotium

DSDM es el acrónimo que da nombre a un modelo de procesos para el

desarrollo de sistemas de software, desarrollado y concebido por el
denominado DSDM Consortium, que se fundó en Inglaterra en 1994, y que
actualmente tiene presencia en Inglaterra, EE.UU. Benelux, Dinamarca, Francia
y Suiza, Es un modelo que estuvo representado en la firma del Manifiesto Ágil.
En 2001, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y
se consideró una metodología ágil; y aunque mantuvo las siglas, cambió la
denominación original (Dynamis Systems Development Method) por
Framework for Business Centred Development

Principios del DSDM

En su versión actual (4.2) el marco de procesos DSDM se basa en 9

principios.

• La implicación activa de los usuarios es imprescindible.

• Los miembros de los equipos de desarrollo DSDM deben tener la

autonomía y potestad necesarias para tomar decisiones.

• Entrega frecuente de incrementos operativos del producto.

• El principal criterio de prioridad, desarrollo y validación de las

entregas incrementales es el objetivos y la salud del negocio.

• El desarrollo iterativo o incremental hace posible obtener la solución

más adecuada a las necesidades del negocio.

• Todos los cambios realizados en el desarrollo son reversibles.

• Los requisitos se establecen a un nivel general

• Las pruebas forman parte del ciclo de desarrollo

 13

• Es imprescindible trabajar con espíritu de colaboración con todos los

agentes implicados en el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDM

El ciclo de desarrollo de DSDM está compuesto de 5 fases, precedidas de un

pre-proyecto y un post-proyecto.

1. Pre-proyecto

2. Estudio de viabilidad

3. Estudio de negocio

4. Iteración de modelado funcional

5. Iteración de diseño y desarrollo

6. Implementación

7. Post-desarrollo

Observando el diseño del modelo de gestión ágil DSDM ( ) vemos que se

incluye antes de comenzar con las iteraciones (funcional - Diseño - e
implementación), un punto de inicio representado por un triángulo de su
diagrama, en este triangulo vemos actividades que son :

• Pre-proyecto
• Estudio de viabilildad
• Estudio de negocio

En ellos se debe realizar:

 14

• Análisis ágil de viabilidad sobre las cuestiones:

• ¿El sistema propuest es técnicamente posible?
• Impacto en el proceso de negocio
• ¿Es DSDM el mejor ciclo de desarrollo para la solución del cliente?
• Análisis previo de los riesgos del proyecto

Y en el "estudio de negocio" :
• comprobar que el cliente dispone de una visión válida de lo que
desea.
• Definir y validar la definición de alto nivel de la arquitectura del
sistema.
• y generar un plan de desarrollo con las líneas de actividades en las
iteraciones del modelo, del diseño y de la implementación.

Este concepto de "validación inicial del proyecto" sería el equivalente al

que la ingeniería del software ortodoxa cubre con el proceso de Adquisición, y
que tiene como finalidad comprobar que todas las luces están verdes, antes de
comenzar , aunque la metodologia agil pura no contiene estas fases el sprint 0
es usado para no romper la filosofia de la metodologia

Elaboracion de la pila de productos (backlog)

El backlog de productos es el corazon del scrum, es una lista priorizada

de requisitos funcionales que pueden ser historias de usuario, cosas que el
cliente quiere con su terminologia,esta lista puede contener varios campos
para cada item o producto,estos serian ID el cual es el identificador unico del
producto, su nombre, la importancia que le da el dueño del producto, la
estimacion en horas, como se puede probar que la funcionalidad esta cubierta
y nota, se pueden agregar mas campos, categoria de actividad (analisis,diseño
etc.), usuario de la actividad etc, regularmente con los primeros seis esta bien
 15

En base a las historias reunidas se seleccionan conforme a varios

criterios (alcance, estimacion, importancia) las que van a ir en el sprint, en
base a estas se definen las actividades que darian cumplimiento a esas
historias , se descomponen en sub-actividades etc

Se pueden elaborar tarjetas de producto en papel, comunmente se

ordenan en un tablero y se van marcando las que se van cumpliendo

El tablero nos indica que tareas estan en el sprint, cuales se estan

realizando y cuales ya estan hechas

Ejemplo de tablero de Sprint

PRINCE2-Otras herramientas de procesos que se pueden utilizar

Es una metodología de gestión de proyectos que cubre la

administración, control y organización de un proyecto. "PRINCE2" es una marca
de la OGC del Reino Unido.En 1996 PRINCE2 fue introducido. La diferencia
principal entre ambas versiones es que PRINCE2 no está orientado solamente a
TIC. PRINCE2 es adecuado para todo tipo de proyectos. PRINCE2 es un método
genérico de administración de proyectos. PRINCE2 puede ser utilizado
conjuntamente con scrum

Modelo de procesos PRINCE2

 16

PRINCE2 Hay ocho procesos, cada uno formado por una colección de
procesos. La colección está basada en fases dentro del proyecto y las distintas
orientaciones en contexto y responsabilidades. Cada proceso de máximo nivel
está dividido en sub procesos.

El uso de componentes de procesos PRINCE2 puede ser util para reducir

riesgos , cuando por ejemplo se comienza a implementar SCRUM

Figura para ilustrar el modelo PRINCE

Sin embargo el uso de actividades de estabilizacion de PRINCE2 tiene un

costo en tiempo, un retraso en los sprint, ya que estas son incluidas dentro de
las actividades de los sprint, Algunas organizaciones enmascaran el proceso
de SCRUM en una fachada de PRINCE2

Herramientas de gestión de la metodología Scrum

Existen en el mercado herramientas de software para llevar a cabo una

gestión de la metodología SCRUM entre estas están scrumdesk
(scrumdesk.com) que tratan de documentar todos los conceptos del proyecto y
de su ciclo de vida, la lista de tareas a ser realizadas (backlog) y las historias
de usuario entre otras
 17

Sin embargo se puede llevar la gestion incluso en una simple hoja de

excel
 18

Ampliando Historias de Usuario (Herramienta de las

metodologías agiles)

Introducción

Las historias de usuario son la herramienta utilizada por las

metodologías agiles para recoger los requerimientos del sistema, su objetivo es
muy similar al de los casos de uso

Las historias de usuario nacen de la necesidad de una mejor

comunicación, de un lenguaje común entre todos los involucrados,
desarrolladores, usuarios etc. , es evitar el dominio del lenguaje de una de las
partes involucradas, por ejemplo si el lenguaje de los desarrolladores
predomina, ellos pierdan la oportunidad de escuchar lo que realmente se
necesita

Anteriormente definimos a las historias de usuario, como la manera en

que los usuarios pueden usar el sistema, las historias de usuario son escritas
para los usuarios no para el equipo de desarrollo, es una narrativa mas
coloquial y menos formal , que por ejemplo la dada en un caso de uso

Las historias de Usuario no son requerimientos detallados, pueden

obtenerse durante las iteraciones, como una experiencia de uso del sistema
resultado de una iteración, deben usar la terminología del usuario , un lenguaje
de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo
simple

Aspectos de las historias de usuario

Una Historia de Usuario describe una funcionalidad, un propósito de un

sistema o software, son tradicionalmente escritas a mano y se componen de
tres aspectos

4. Uno que describa la historia y como un plan y como recordatorio

Este primer aspecto es el que se refleja en la llamada Story Card

(Tarjeta de Historia), que son tradicionalmente escritas a mano, en papel
a manera de nota, buenos ejemplos pudieran ser :

Story Card : historia de usuario en una nota

Un usuario puede mandar su resumen a través de una pagina

Web

Un usuario puede buscar empleo

 19

Una compañía puede publicar nuevas ofertas de trabajo

Un usuario puede limitar a quien pueda ver sus resúmenes

Un ejemplo de una mala nota, una historia de usuario mal hecha pudiera
ser

El programa podría conectarse a la base de datos a través de una

conexión

Es un mal ejemplo porque denota una funcionalidad del programa muy

especifica

5. Conversaciones que puedan servir para reflejar detalles de la historia

Los detalles de las historias de usuario están en las conversaciones, las

conversaciones tratan de responder preguntas acerca de la historia de
usuario un ejemplo de preguntas a contestar para la historia de usuario
1 (búsqueda de empleo) pudiera ser :

¿Qué características del empleo busca el usuario ? ¿ciudad?¿estado?

¿Qué información debe ser desplegada acerca del empleo?
¿Puede guardarse el resultado de la búsqueda de empleo del usuario?
¿Necesita ser miembro de la pagina el usuario ?

La respuesta a estas preguntas pudiera llevar a redactar mas historia de

usuario, siempre será mejor tener historias cortas a largas, sin embargo
no es necesario llegar a extremos, a tratar de llegar a historias mínimas,
solo lo razonable

No es necesario tampoco el llegar a describir la historia de usuario de

manera típica y formal esto es

Usuario puede ver información de un trabajo resultado de una

búsqueda
-Puede ver la descripción
-De donde es el trabajo
-Cual es el salario o rango

El objetivo no es documentarlas en papel, es el discutirlas con el cliente,

tener una conversación de los detalles que se están volviendo
importantes, no es el escribir anotaciones acerca de las discusiones en
las tarjetas de historias
 20

6. Test que puedan documentar cuando una historia ha sido completada

El reverso de una tarjeta de historia (story card) puede servir para

apuntar pruebas que se pueden hacer acerca de la historia, para nuestro
ejemplo de la busque de empleo podemos anotar al reverso por ejemplo

Reverso de Story Card 2 (búsqueda de empleo)

Intentar con una descripción del trabajo vacía

Intentar con una descripción del empleo demasiado larga

Intentar con un salario que no exista

Intentar con un salario de seis dígitos

Estas descripciones son cortas e incompletas, mas pruebas puedes ser

sumadas con el tiempo, el objetivo es enviar información a los
desarrolladores para que sepan cuando una historia es cubierta, es el
conocer las expectativas del cliente acerca de la historia una vez
finalizada

Un proyecto que se este llevando a cabo en base a historia de usuario

puede sentirse distinto, a la toma de requerimientos tradicional, el primer
punto que se nota, es que los clientes o usuarios están involucrados durante
toda la vida del proyecto, las historias de usuario son un buen comienzo para
definir los tipos de usuario del sistema

Puede tenerse un proyecto inicial de historias pero pueden surgir otras

durante todo el proyecto, pueden apilarse historias cortas durante una
iteración para su atención, pueden priorizarse en pilas para su desarrollo en
cada iteración

Puede tenerse un proyecto inicial de historias pero pueden surgir otras

durante todo el proyecto, pueden apilarse historias cortas durante una
iteración para su atención, pueden priorizarse en pilas para su desarrollo en
cada iteración

Planeando liberaciones e Iteraciones

Un lanzamiento o liberación se organiza ya sea planeando una o mas

iteraciones , en este plan de liberación el equipo del cliente intenta priorizar las
historias, de acuerdo al deseo de alguna característica querida por una base de
usuarios o un grupo pequeño y de acuerdo también a la cohesión con otras
 21

historias , el equipo de desarrollo escucha y sugiere acerca de esta

priorización, y no se puede olvidar la importancia de los costos económicos

La priorización de las historias de usuario se refleja en puntos y se tabula

Historia Puntos

A 3

B 5

C 5

D 3

E 1

F 8

Un plan de liberación podría ser

No. Iteración Historias Puntos

1 A,B,C 13

2 D,E,F 12

Ventajas de las historias de usuario sobre la toma tradicional de

requerimientos o casos de uso

Algunas de las ventajas son :

1. Comprensibles para usuarios y desarrolladores

2. Tienen el tamaño justo para la planeación

3. Enfatizan la comunicación verbal sobre la escrita

4. Trabajan para el desarrollo iterativo

5. Fomentan una mejor comprensión acerca de lo que realmente

necesitas

Reuniendo Historias de Usuario

Existe un grupo de técnicas para reunir Historias de Usuario y estas son:

1. Entrevistas .- Esta técnica es la usada por default, es importante

no solo preguntarle al usuario que necesita, entrevistar a usuarios
reales de ser posible
 22

2. Cuestionarios .- Técnica muy útil cuando se tiene demasiados

posibles usuarios, útil para priorizar historias , pero no para
atrapar nuevas, a diferencia de una conversación, el usuario no
presta tanto interés, un buen cuestionario pudiera pedir la opinión
de las características actuales del sistema y cual pudiera no
necesitarse, preguntando el porque de esto mismo, esto pudiera
ayudarnos a priorizar mejor una tarea

3. Observación .- Puede ayudarnos ver como los usuarios utilizan

nuestro software para recoger indicios, siempre que se pueda hay
que hacerlo, aunque no siempre se puede

4. Taller de escritura de historias .- Es una reunión, de clientes,

desarrolladores, usuarios y otros participantes que pueden
contribuir a escribir historias, se trata de que todos escriban
historias como ellos puedan, dejando la priorización para después
23