Implementación Ágil

La implementación ágil se realiza de una forma incremental o por fases.

El principal compromiso de la implementación de la metodología ágil es evitar
los obstáculos y problemas asociados a la implementación big bang. La
metodología ágil se basa en la simplicidad, en entregar las funcionalidades
operativas del software lo más rápido posible, empezando por los componentes
más importantes del negocio [1]. La implementación ágil consiste en dos fases:
análisis y realización de Sprint como se muestra en la Figura 4.

A continuación se van a explicar ambas fases detenidamente. [2]

Análisis

Esta fase consiste en 4 pasos:

1. Preparación del proyecto durante el cual se definen los

diferentes elementos, tales como labores,

18 | P á g i n a
 responsabilidades, estándares para la documentación y
requisitos del hardware.

2. Proceso de visualización en el que se identifican

cuidadosamente todos los procesos operativos y procesos
que dependen de condiciones específicas, como seguridad,
autorizaciones e interfaces. Estos resultados serán la base
para la construcción de unos cimientos sólidos para el
proyecto entero.

3. Funcionamiento de referencia del sistema, el cual se basará

en el software de ERP.

4. Fase de evaluación. En esta fase, se determina la prioridad

de los requisitos adicionales y las funcionalidades, en orden
del valor del negocio. Después de esto, el equipo de
implementación estima el esfuerzo que será necesario para
realizar esto y determina la planificación de los sprints para
que se suministren los componentes del sistema.

Realización del Sprint

Esta fase consiste en los 5 siguientes pasos [3]:

1. Reuniones de planificación al comienzo de cada sprint. Se

define el objetivo del sprint entre el propietario y el equipo
de implementación.

2. Realización de los requisitos, de pruebas y documentación.

3. Reuniones diarias del estado del proyecto. En esta fase se

registra el estado del proyecto y se discuten los diversos
obstáculos que el equipo ha podido encontrar.

4. Sesión de prueba del Sprint. Durante esta fase los usuarios y

el equipo IT determinan si los procesos cumplen los
requisitos.

19 | P á g i n a
 5. Se llevará a cabo una revisión del Sprint para comprobar
que se puede mejorar en los futuros sprints.

Productos existentes

Actualmente en el mercado existen muchas opciones de ERP, desde

grandes sistemas para grandes clientes, hasta software libre destinado a
pequeñas empresas, pasando por aplicaciones desarrolladas a medida del
cliente. Entre todas estas alternativas se pueden destacar los siguientes
productos por su relevancia [5]:

20 | P á g i n a
 Metodología de desarrollo

¿Qué es Scrum?

Scrum es una metodología ágil para el desarrollo de software o la

gestión de proyectos. Antes de la definición de Scrum, es imprescindible
entender el concepto de ágil. El desarrollo de software ágil se define como [8]:

Generalmente, el desarrollo de software es una actividad caótica, a

desarrollo de software reside en que el código se escribe muchas veces sin

seguir un plan subyacente, y el propio diseño del sistema se improvisa a partir
de muchas decisiones a corto plazo. De hecho, esto funciona bastante bien
cuando el sistema es pequeño, pero conforme el sistema va creciendo, se va
haciendo más difícil añadir nuevas funcionalidades. Además, también se hacen
predominantes los bugs y aumenta la dificultad de arreglarlos. Para evitarlos, es
necesario una larga fase de pruebas una vez que se han definido todas las
funciones del sistema. Esta fase causa estragos en los cronogramas, ya que la
realización de pruebas y la depuración es imposible de planificar.

El movimiento original de intentar cambiar esto, introdujo la noción de

metodología. Estas metodologías imponen un proceso disciplinado sobre el
desarrollo de software con el objetivo de elaborar un software más predecible y
eficiente. Esto se consigue desarrollando un proceso detallado con especial
énfasis en la planificación, inspirada en otras disciplinas de la ingeniería -
también llamadas metodologías de la ingeniería.

Las metodologías ágiles surgieron como reacción a estas metodologías.

La atracción que sufre mucha gente por estas metodologías viene provocada
por la burocracia que conlleva las metodologías de la ingeniería. Estos métodos
nuevos intentan ofrecer un compromiso eficiente entre procesos,
proporcionando los procesos únicamente necesarios para lograr una
recompensa razonable. El resultado de todo esto son los significativos cambios
que sufren los métodos ágiles frente a los métodos de la ingeniería. La
diferencia más determinante es que estas metodologías se basan en la poca
documentación, normalmente resaltando la poca cantidad de documentos para
una tarea. Se podría decir que están enfocadas al código: siguiente una ruta que
diga que la parte principal de la documentación es el código fuente.

Las metodologías ágiles son flexibles más que predictivas. Los métodos
de la ingeniería tienden a intentar planificar detalladamente una gran parte del
26 | P á g i n a
proceso del software durante un largo periodo de tiempo, lo que funciona hasta
que algo cambia. En cambio, las metodologías ágiles se acogen al cambio
continuo. Intentan ser procesos que se adaptan y prosperan con el propio
cambio.

Por otro lado, las metodologías ágiles están más enfocadas al ser
humano que a los procesos. El objetivo de las metodologías de la ingeniería es
definir un proceso que funcionará bien sin importar quién lo vaya a usar. En
cambio, las metodologías ágiles reivindican que el no usar procesos supondrá el
desarrollo de las habilidades del equipo, de forma que, el papel de un proceso
es dar soporte al equipo desarrollador en su trabajo.

Actualmente hay muchas metodologías ágiles en uso, pero ha sido

necesario el uso de esta metodología para el desarrollo del presente proyecto.
Por lo tanto, es imprescindible hablar de Scrum antes de meterse en la
implementación del mismo.

A continuación se presenta una breve descripción de la metodología

Scrum:

La metodología Scrum para el desarrollo ágil de software representa un

punto de partida de la gestión en cascada. De hecho, Scrum y otro tipo de
procesos ágiles se inspiraron en sus limitaciones. La metodología Scrum enfatiza
en la comunicación y colaboración, el funcionamiento del software, y la
flexibilidad de la que dispone para adaptarse a las emergentes realidades de las
empresas - todos los atributos de los que carecía el modelo de cascada.

¿Qué caracteriza a Scrum?

De todas las metodologías ágiles, Scrum es única porque introduce la

idea del control empírico de los procesos. Esto significa que Scrum utiliza el
progreso real de un proyecto para planificar y concertar los lanzamientos. En
Scrum, los proyectos se dividen en ritmos de trabajo breves, conocidos como
sprints. Normalmente, tienen una, dos o tres semanas de duración. Al final de
cada sprint, el cliente y los miembros del equipo se reúnen para evaluar el
progreso del proyecto y planear los siguientes pasos a seguir. Esto permite que
la dirección del proyecto se ajuste o se reoriente una vez finalizado el trabajo,
sin especulaciones ni predicciones [9].

27 | P á g i n a
 Filosóficamente, este énfasis continuo de evaluar las tareas finalizadas
es el principal causante del éxito que tiene esta metodología entre los
directores y desarrolladores. Pero lo que verdaderamente permite funcionar a
la metodología Scrum es un conjunto de papeles, responsabilidades, y
reuniones.

Los papeles de Scrum

Scrum tiene tres papeles fundamentales: Product Owner (propietario del

producto), Scrum Master (especialista en Scrum) y Team Member (miembros
del equipo) [10].

Product Owner: En Scrum, el Product Owner se encarga de comunicar la

visión del producto al equipo de desarrollo. Él/ella también deben
representar el interés del cliente por medio de los requisitos y la
priorización. Como el Product Owner es el que más autoridad tiene de los
tres papeles en Scrum, también es el que mayor responsabilidad recibe.
En otras palabras, el Product Owner es el individuo que tiene afrontar las
consecuencias cuando un proyecto va mal.

La autoridad y responsabilidad del Product Owner le hace difícil

conseguir el balance correcto de implicación. Como Scrum evalúa la auto-
organización entre equipos, el Product Owner debe luchar por no supervisar
hasta el último detalle. Al mismo tiempo, el Product Owner tiene que estar a la
disposición de las preguntas del equipo.

Scrum Master: El Scrum Master actúa como enlace entre el Product

Owner y el equipo. El Scrum Master no dirige al equipo. Él/ella se encarga
de evitar cualquier barrera que impida al equipo lograr sus objetivos de
sprint. En resumen, este papel hace que el equipo sea creativo y
productivo, a la vez que permite que los logros del equipo sean visibles
ante el Product Owner. El Scrum Master también aconseja al Product
Owner sobre cómo maximizar el ROI (Return Of Investment) para el
equipo.

Team Member: En la metodología Scrum, el equipo es el responsable de

terminar el trabajo. Idealmente, los equipos están formados por siete
miembros multifuncionales, más/menos dos personas. Para proyectos de
software, un equipo habitual sería una mezcla de ingenieros de software,
arquitectos, programadores, analistas, testers, y diseñadores de UIs. En

28 | P á g i n a
cada sprint, el equipo es responsable de determinar cómo va a lograr
acabar el trabajo. Esto garantiza al equipo un grado de autonomía, pero,
al igual que pasa con la situación del Product Owner, esta libertad viene
acompañada por la responsabilidad de cumplir los objetivos del sprint.

La siguiente imagen muestra el flujo habitual de Scrum:

1. Diagrama sencillo del proceso:

Ilustración 4 - Procesos Scrum

29 | P á g i n a
 Capítulo 3: Análisis del sistema

En este apartado, la meta a conseguir es identificar los objetivos que han

de ser alcanzados para el desarrollo del sistema final. Para lograr esto se tomará
como referencia las historias de usuario que representan las necesidades que
deben cubrir las funcionalidades de la aplicación, y de este modo satisfacer las
exigencias del cliente.

Para la realización del proceso de extracción de información relativa a

las necesidades a cubrir se llevará a cabo entre los miembros del equipo de
desarrollo y el propio cliente. Este proceso, gracias a la metodología Scrum, no
se limitará a la fase inicial del proyecto, como ocurriría en un desarrollo clásico
generalmente, si no que se tratará de un proceso iterativo en constante
evolución para poder amoldarse a los requerimientos del cliente de la forma
más eficiente.

Las historias de usuario que se extraigan de las reuniones con el cliente,

describirán una funcionalidad que debe incorporar un sistema de software, y
cuya implementación aporta valor al cliente.

La estructura de una historia de usuario está formada por:

- Nombre breve y descriptivo.

- Descripción de la funcionalidad en forma de diálogo o monólogo

del usuario describiendo la funcionalidad que desea realizar.

- Criterio de validación y verificación que determinará para

considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad
descrita.

Las historias de usuario se descomponen en tareas. Estas tareas son

unidades de trabajo que tienen asignado un esfuerzo estimado y un estado. Por

31 | P á g i n a
lo que es en las tareas en los que se basa la estimación de esfuerzos general del
proyecto.

Definición

Para la definición del sistema, es decir, para la extracción de la

información que ayude a modelar la aplicación según las necesidades del
cliente, se realiza una reunión entre todos los miembros interesados en el
proyecto. En dicha reunión el cliente expone su idea del sistema, que
necesidades debe cubrir y que funciones quiere que le aporte. También los
miembros del equipo técnico aportan su visión para enriquecer la definición
final del sistema a desarrollar. Finalmente con toda la información extraída de la
reunión el Product Owner, el actor que representa la voz del cliente, escribe las
historias de usuario donde se representa formalmente la definición del sistema,
además se extraen las tareas que componen las historias de usuario, se les
asigna un coste (un esfuerzo estimado) y las prioriza. Quedando formado el
Product Backlog que será la base del proyecto a desarrollar.

Es importante aclarar que debido a la naturaleza ágil del proyecto, la

definición inicial del sistema puede verse alterada en el transcurso del
desarrollo del mismo. Ya que como más adelante se verá, el desarrollo se divide
en diferentes etapas o Sprints, entre los cuales se repetirá la reunión entre los
miembros del proyecto, pudiéndose incluir, modificar o eliminar historias de
usuario y/o tareas. Por este motivo el análisis expuesto en este capítulo
únicamente se trata del análisis inicial, y en próximos capítulos se describirán los
análisis correspondientes a la reunión de cada Sprint.

32 | P á g i n a
 Historias de usuario

Las historias de usuario se definirán utilizando el siguiente modelo:

Historia de
Usuario
ID HUXX

Nombre

Prioridad

Riesgo

Descripción

Validación

Donde cada campo tiene el siguiente significado:

- ID:
Se trata del identificador único asignado a este elemento del
proyecto, se seguirá el formato HUXX para las historias de usuario.

- Nombre:
Es nombre corto utilizado para describir muy brevemente la
historia de usuario.

- Prioridad:
Es la preferencia de cara al desarrollo de la historia de usuario
respecto a las demás.
Valores: Alta, media y baja.

- Riesgo:
Se trata de la importancia de la historia de usuario en relación al
conjunto del proyecto. Cuantificando de este modo el daño provocado en
caso de fallo.
Valores: Alto, medio y bajo.
33 | P á g i n a
 - Descripción:
Breve explicación de las intenciones de la historia de usuario.
Debe dejar clara la idea de la propia historia.

- Validación:
Son las condiciones que deben cumplirse una vez la historia está
completamente desarrollada para que se pueda por finalizada.

Historia de
Usuario
ID HU01

Nombre Introducir ventas realizadas.

Prioridad Media

Riesgo Bajo

Descripción Como gestor de ventas quiero introducir las operaciones de venta de artículos
realizadas en el sistema.

Validación - Quiero que la operación quede registrada a nombre de un empleado.

- Quiero que la operación se diferencie por centro y cliente.
- Quiero que cada venta de un tipo de artículo se haga por separado.
- Quiero que en la venta se almacene el precio del artículo en ese
momento.

Historia de
Usuario
ID HU02

Nombre Introducir compras realizadas.

Prioridad Media

Riesgo Bajo

Descripción Como gestor de compras quiero introducir las operaciones de compra de

34 | P á g i n a
 artículos realizadas en el sistema.

Validación - Quiero que la compra se guarde en el sistema.

- Quiero que la compra guarde una relación de proveedor, empleado
que la realiza, el centro de destino y el precio pagado por la compra.

Historia de
Usuario
ID HU03

Nombre Registrar y administrar artículos.

Prioridad Alta

Riesgo Alto

Descripción Como gestor de compras quiero registrar los artículos nuevos en el sistema.

Validación - Quiero poner introducir nuevos artículos en el sistema.

- Los artículos deben agruparse por su tipología.
- Cada artículo tiene asociado un precio de venta.
- Los datos almacenados se pueden modificar posteriormente.

Historia de
Usuario
ID HU04

Nombre Registrar y administrar proveedores.

Prioridad Alta

Riesgo Alto

Descripción Como gestor de compras quiero registrar nuevos proveedores.

Validación - Quiero poder introducir nuevos proveedores en el sistema.

- Cada proveedor debe tener relacionado un nombre, un NIF, un email
y una cuenta bancaria.
- Puede haber almacenados dos proveedores con el mismo NIF.
- Los datos almacenados se pueden modificar posteriormente.

35 | P á g i n a
Historia de
Usuario
ID HU05

Nombre Registrar y administrar centros.

Prioridad Alta

Riesgo Alto

Descripción Como gestor de almacenes quiero disponer de diferentes centros como

destino / origen de las mercancías.

Validación - Quiero poder introducir nuevos centros en el sistema.

- Cada centro debe tener relacionado un nombre, un teléfono, un email
y una dirección física.
- Los datos almacenados se pueden modificar posteriormente.

Historia de
Usuario
ID HU06

Nombre Control de stocks.

Prioridad Alta

Riesgo Medio

Descripción Como gestor de almacenes quiero tener control de los stocks de los artículos
que hay en los centros.

Validación - Quiero incluir nuevos artículos a un centro.

- Quiero aumentar o reducir la cantidad almacenada.
- Quiero poder tener el mismo artículo en varios centros.

Historia de
36 | P á g i n a
Usuario
ID HU07

Nombre Apariencia de la aplicación

Prioridad Baja

Riesgo Bajo

Descripción Como usuario quiero que la aplicación tenga un aspecto simple y sencillo de
manejar.

Validación - Quiero que las ventanas sean reducidas y contengan solo la

información imprescindible.
- Quiero que para entrar en algún modo se abra una ventana
específica.
- Quiero unas funciones básicas (comprar y vender) de fácil acceso.

Historia de
Usuario
ID HU08

Nombre Funcionamiento en Windows

Prioridad Alta

Riesgo Alto

Descripción Como usuario quiero que el sistema funcione en el sistema operativo

Windows 8.1

Validación - Quiero que la aplicación funcione en Windows 8.1

- Diseño de la arquitectura de la aplicación.

Historia de
Usuario
ID HU09

Nombre Importación / Exportación desde Excel

Prioridad Baja

Riesgo Bajo

Descripción Como usuario quiero introducir y extraer datos en formato Excel.

37 | P á g i n a
Validación - Quiero importar datos desde un fichero .xls.
- Quiero exportar datos a un fichero .xls.

Historia de
Usuario
ID HU10

Nombre Base de datos

Prioridad Alta

Riesgo Alto

Descripción Como desarrollador quiero que los datos introducidos sean persistentes.

Validación - Quiero el uso de una base de datos.

- Quiero que a la base de datos se le puedan introducir nuevos datos.
- Quiero que los datos de la base de datos se puedan modificar.
- Quiero que los datos de la base de datos se puedan eliminar.

Tareas

Las tareas que componen las historias de usuario se detallan a

continuación siguiendo el siguiente modelo:

Tarea Txx

Historia de HUxx
Usuario

38 | P á g i n a
Estado

Descripción

Donde cada campo tiene el siguiente significado:

- Tarea:
Es el identificador único para este elemento del proyecto. El

al 99.

- Historia de Usuario:
Toda tarea forma parte de una historia de usuario que se indica
en este campo.

- Estado:
Se trata de la fase en la que se encuentra el desarrollo de la tarea.
Valores: No iniciada, En progreso y Completada.

- Descripción:
Una breve explicación de la finalidad de la tarea.

Tarea T01
Historia de HU03
Usuario
Estado
Descripción Crear interfaz con la BBDD para la tabla artículos en la capa de datos.
DArticulos.cs

Tarea T02
Historia de HU03
Usuario
Estado
Descripción Crear NArticulos.cs en la capa de negocio.

39 | P á g i n a
Tarea T03
Historia de HU03
Usuario
Estado
Descripción Crear tabla artículos en la base de datos.

Tarea T04
Historia de HU03
Usuario
Estado
Descripción Crear procedimientos para consulta e inserción en la tabla artículos.

Tarea T05
Historia de HU03
Usuario
Estado
Descripción Crear tabla grupo_articulos en la base de datos.

Tarea T06
Historia de HU03
Usuario
Estado
Descripción Crear procedimientos para consulta e inserción en la tabla grupo_artículos.

Tarea T07
Historia de HU03
Usuario
Estado
Descripción Crear interfaz con la BBDD para la tabla artículos en la capa de datos.
DGrupo_Articulos.cs

Tarea T08
Historia de HU03
Usuario
Estado
Descripción Crear NArticulos.cs en la capa de negocio.

40 | P á g i n a
Tarea T09
Historia de HU03
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de la tabla artículos.

Tarea T10
Historia de HU03
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de la tabla grupo_artículos.

Tarea T11
Historia de HU05
Usuario
Estado
Descripción Crear la tabla centros en la base de datos.

Tarea T12
Historia de HU05
Usuario
Estado
Descripción Crear los procedimientos en la base de datos para las consultas, inserciones y
modificaciones en la tabla centros.

Tarea T13
Historia de HU05
Usuario
Estado
Descripción Crear DCentros.cs en la capa de datos.

Tarea T14
Historia de HU05
Usuario
Estado
Descripción Crear NCentros.cs en la capa de negocio.

41 | P á g i n a
Tarea T15
Historia de HU05
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de la tabla centros.

Tarea T16
Historia de HU06
Usuario
Estado
Descripción Crear la tabla stocks en la base de datos.

Tarea T17
Historia de HU06
Usuario
Estado
Descripción Crear los procedimientos en la base de datos para las consultas, inserciones y
modificaciones en la tabla stocks.

Tarea T18
Historia de HU06
Usuario
Estado
Descripción Crear DStocks.cs en la capa de datos.

Tarea T19
Historia de HU06
Usuario
Estado
Descripción Crear NStocks.cs en la capa de negocio.

Tarea T20
Historia de HU06
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de la tabla stocks.

42 | P á g i n a
Tarea T21
Historia de HU06
Usuario
Estado
Descripción Controlar que no hay stocks negativos.

Tarea T22
Historia de HU07
Usuario
Estado
Descripción Diseño de la interfaz gráfica de la aplicación.

Tarea T23
Historia de HU10
Usuario
Estado 0.5
Descripción Determinar tablas de la base de datos.

Tarea T24
Historia de HU10
Usuario
Estado 0.5
Descripción Diseño de relaciones entre las tablas de la base de datos.

Tarea T25
Historia de HU04
Usuario
Estado
Descripción Crear la tabla proveedores en la base de datos.

Tarea T26
Historia de HU04
Usuario
Estado
Descripción Crear los procedimientos en la base de datos para las consultas, inserciones y
modificaciones en la tabla proveedores.

43 | P á g i n a
Tarea T27
Historia de HU04
Usuario
Estado
Descripción Crear DProveedores.cs en la capa de datos.

Tarea T28
Historia de HU06
Usuario
Estado
Descripción Crear NProveedores.cs en la capa de negocio.

Tarea T29
Historia de HU06
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de la tabla proveedores.

Tarea T30
Historia de HU01
Usuario
Estado
Descripción Crear NVentas.cs en la capa de negocio.

Tarea T31
Historia de HU01
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de las ventas.

Tarea T32
Historia de HU01
Usuario
Estado
Descripción Crear DVentas.cs en la capa de datos.

44 | P á g i n a
Tarea T33
Historia de HU02
Usuario
Estado
Descripción Crear NCompras.cs en la capa de negocio.

Tarea T34
Historia de HU02
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de las compras.

Tarea T35
Historia de HU02
Usuario
Estado
Descripción Crear DCompras.cs en la capa de datos.

Tarea T36
Historia de HU02
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de las compras.

Tarea T37
Historia de HU09
Usuario
Estado
Descripción Crear plantilla de Excel para cada tabla.

Tarea T38
Historia de HU09
Usuario
Estado

45 | P á g i n a
Descripción Crear DExcel.cs en la capa de datos.

Tarea T39
Historia de HU09
Usuario
Estado
Descripción Crear la interfaz de usuario para la importación de datos desde Excel.

Tarea T40
Historia de HU08
Usuario
Estado
Descripción Diseño de la arquitectura del sistema

Tarea T41
Historia de HU01
Usuario
Estado
Descripción Crear NCliente.cs en la capa de negocio.

Tarea T42
Historia de HU01
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de los clientes.

Tarea T43
Historia de HU01
Usuario
Estado
Descripción Crear DClientes.cs en la capa de datos.

Tarea T44
Historia de HU01
Usuario

46 | P á g i n a
Estado
Descripción Crear la tabla clientes en la base de datos.

Tarea T45
Historia de HU01
Usuario
Estado
Descripción Crear los procedimientos en la base de datos para las consultas, inserciones y
modificaciones en la tabla clientes.

Tarea T46
Historia de HU01
Usuario
Estado
Descripción Crear NEmpleados.cs en la capa de negocio.

Tarea T47
Historia de HU01
Usuario
Estado
Descripción Crear la interfaz de usuario para la gestión de los empleados.

Tarea T48
Historia de HU01
Usuario
Estado
Descripción Crear DEmpleados.cs en la capa de datos.

Tarea T49
Historia de HU01
Usuario
Estado
Descripción Crear la tabla empleados en la base de datos.

Tarea T50

47 | P á g i n a
 Sprints

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos

(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene
que proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable, de manera que cuando el cliente (Product Owner)
lo solicite sólo sea necesario un esfuerzo mínimo para que el producto esté
disponible para ser utilizado. Para ello, durante la iteración el equipo colabora
estrechamente y se llevan a cabo las siguientes dinámicas:

- Cada día el equipo realiza una reunión de sincronización, donde cada

miembro inspecciona el trabajo de los otros para poder hacer las
adaptaciones necesarias, comunica cuales son los impedimentos con que
se encuentra, actualiza el estado de la lista de tareas de la iteración
(Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).
- El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir
con su compromiso y de que no se merme su productividad.

o Elimina los obstáculos que el equipo no puede resolver por sí

mismo.
o Protege al equipo de interrupciones externas que puedan afectar
su compromiso o su productividad.

También existen una serie de restricciones que deben ser tenidas en

consideración:

- No se puede cambiar los objetivos/requisitos de la iteración en curso:

o En la reunión de planificación de la iteración el equipo adquirió el

compromiso de completar en la iteración unos requisitos
concretos, basó su plan y organización en ellos. Cambiar los
objetivos/requisitos de la iteración dificulta la concentración del
equipo, baja su moral y su compromiso.

o El hecho de no poder cambiar los objetivos/requisitos de la

iteración una vez iniciada facilita que el cliente cumpla con su
responsabilidad de conocer qué es lo más prioritario a desarrollar,
antes de iniciar la iteración.

o Notar que Scrum minimiza esta necesidad ya que, por un lado, los
objetivos/requisitos que se están desarrollando eran los más
63 | P á g i n a
 prioritarios justo antes de iniciar la iteración y, por otro lado, las
iteraciones en Scrum son suficientemente cortas (2 o 4 semanas)
como para que la probabilidad de cambios una vez iniciada la
iteración sea mínima.

- Terminación anormal de la iteración:

o Sólo en situaciones muy excepcionales el cliente o el equipo

pueden solicitar una terminación anormal de la iteración. Esto
puede suceder si, por ejemplo, el contexto del proyecto ha
cambiado enormemente y no es posible esperar al final de la
iteración para aplicar cambios, o si el equipo encuentra que es
imposible cumplir con el compromiso adquirido. En ese caso, se
dará por finalizada la iteración y se dará inicio a otra mediante una
reunión de planificación de la iteración.

Sprint Planning

La planificación de las tareas a realizar en la iteración se divide en dos

partes:

- Primera parte de la reunión. Se realiza en un timebox de cómo máximo 4

horas *(aproximadamente):

o El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteración (de
manera que ayude a tomar decisiones durante su ejecución) y
propone los requisitos más prioritarios a desarrollar en ella.

o El equipo examina la lista, pregunta al cliente las dudas que le

surgen, añade más condiciones de satisfacción y selecciona los
objetivos/requisitos más prioritarios que se compromete a
completar en la iteración, de manera que puedan ser entregados
si el cliente lo solicita.

64 | P á g i n a
 - Segunda parte de la reunión. Se realiza en un timebox de cómo máximo 4
horas*. El equipo planifica la iteración, elabora la táctica que le permitirá
conseguir el mejor resultado posible con el mínimo esfuerzo. Esta
actividad la realiza el equipo dado que ha adquirido un compromiso, es el
responsable de organizar su trabajo y es quien mejor conoce cómo
realizarlo.

o Define las tareas necesarias para poder completar cada

objetivo/requisito, creando la lista de tareas de la iteración (Sprint
Backlog) basándose en la definición de completado.

o Realiza una estimación conjunta del esfuerzo necesario para

realizar cada tarea.

o Cada miembro del equipo se autoasigna a las tareas que puede

realizar.

Sprint 0

Se conoce como Sprint 0 a la fase inicial del proyecto donde se dedica

aproximadamente una semana, independientemente del formato, duración,
etc, del resto de sprints. En este Sprint es donde se va a preparar el equipo
tanto tecnológicamente como metodológicamente para que el desarrollo del
proyecto tenga un buen comienzo, en especial en casos en los que se desconoce
la metodología o no se tiene mucha práctica con ella.

El objetivo del Sprint 0 es preparar el conjunto del proyecto desde una

perspectiva:

- Tecnológica.

- Metodológica.

- Organizativa para que el desarrollo del proyecto tenga un buen

comienzo y mejor finalización.

65 | P á g i n a
 Todo ello consiste básicamente en:

- Definir con el cliente. En primer lugar "the product owner", es decir, yo

misma en este caso me estoy ocupando de definir con el cliente las
características y funcionalidades del proyecto con el mayor número de detalles
posibles. Con toda esa información construyo un documento en forma de
historias de usuarios.

- Construir el Product Backlog. Las historias de usuario presentan

unidades que pueden presentarse a los clientes como elementos acabados. Con
ellas construimos el "Product Backlog".

- Reuniones de equipo. Se realiza una reunión con el equipo donde se

presentan las historias de usuario y donde el equipo deberá: identificar lagunas
de información, dificultades técnicas, dependencias entre historias, proponer
creación/división de historias de usuario...

Los motivos para hacerlo de este modo, son que nos aporta las
siguientes ventajas, siendo éstas de gran ayuda en el desarrollo del proyecto,
mejorando la productividad del equipo.

- Obtenemos una definición contrastada con el cliente en forma de

historias de usuarios.

- El equipo participa en la preparación del desarrollo identificando

necesidades, dificultades, ventajas...

- La preparación de cada sprint será más fácil de realizar porque el

equipo conoce con detalle el proyecto.

El Sprint 0 de este proyecto se podría identificar perfectamente con la

fase de análisis descrita en capítulos anteriores de este documento.

Además de eso en el sprint se define la capacidad de trabajo del equipo

por cada iteración. Para ello se han de definir el tamaño de la iteración y el
rendimiento del equipo:

Tamaño del Sprint 2 Semanas (10 días laborables).

66 | P á g i n a
Trabajo por día 4 horas.

Horas por sprint 40 horas.

En este caso la cantidad de horas es relativamente baja para una

iteración puesto que, aunque se simule la existencia de otros miembros en el
equipo para estimaciones, reuniones, etc., debido a la naturaleza del proyecto
el trabajo es realizado realmente por una única persona.

De esta forma para todo lo relacionado con el desarrollo en sí de la

aplicación siempre se tendrá en consideración esta limitación. No siendo así
para situaciones que puedan ser simuladas de forma sencilla y que den al
proyecto un aspecto más real y natural [14].

Primer Sprint

Lo primero que se hace en la iteración es poner sobre la mesa el Product

Backlog conseguido y utilizarlo para estimar. El mostrado aquí es una versión
resumida de las historias de usuario presentadas en el capítulo de análisis.

67 | P á g i n a