Metodología Scrum

UNIVERSIDAD DE MENDOZA
Facultad de Ingeniería
Ingeniería en Informática
“MÉTODO ÁGIL SCRUM

APLICADO AL DESARROLLO DE UN
SOFTWARE DE TRAZABILIDAD”
María Laura Citón

2006
Asesora: Ing. Graciela Sevilla

Coasesor: Ing. Fabián Contigliani
AGRADECIMIENTOS
En primer lugar, deseo agradecer al Dr. Ing. Salvador Navarria, Decano

de la Facultad de Ingeniería de la Universidad de Mendoza, y por su
intermedio al cuerpo docente y no docente de dicha prestigiosa
institución, que me acompañaron durante toda la carrera.
Deseo brindar un especial agradecimiento a la Ing. Graciela Sevilla y

al Ing. Fabián Contigliani, por su ayuda y dedicación durante la realización
del presente Trabajo Final.
Al Cdor. Mario Gobbi por la información brindada, asesoramiento y buena

predisposición a las consultas realizadas.
A mi familia, a mi novio David y a mis amigos, por sus opiniones y

consejos, que fueron una guía y optimismo estos últimos años.
Y principalmente quiero dedicar este trabajo a mis padres, Dora y Luis, y

a mi hermano Alejandro; gracias a ellos y al gran amor que me brindan,
yo pude realizar y finalizar mi carrera.
RESUMEN
El presente Trabajo Final consiste en aplicar el método ágil Scrum al

desarrollo de un Software de Trazabilidad. La idea del mismo surge a raíz
de la percepción de lo complejo de gestionar eficientemente un proyecto,
con los métodos tradicionales de desarrollo de software, en un ambiente
tan cambiante y turbulento como el de la actualidad.
Como alternativa a las metodologías tradicionales nacen las ágiles, y

dentro de éstas escogimos a Scrum como método ágil para gestionar
nuestro proyecto. Scrum se basa en la adaptabilidad a los cambios como
medio para aumentar las posibilidades de éxito de los proyectos. Su
mayor objetivo es simplificar y minimizar el proceso de desarrollo y
apuntar a lo que realmente importa, la verdadera necesidad del cliente
realizando entregas frecuentes y continuas de software funcional. Tal es
su enfoque hacia la gestión, que deja un vacío metodológico en el área
del proceso.
Para poder implementarlo, entonces, elaboramos un proceso de

desarrollo propio que si bien contiene las cinco etapas habituales del
desarrollo de software, no deja de cumplir con los principios y valores de
las metodologías ágiles. Las etapas del proceso son: planificación,
análisis, diseño, construcción y prueba, e implementación; que para
llevarlas a cabo utilizamos una combinación de diferentes herramientas
de la ingeniería del software.
Haber transitado con Scrum el desarrollo de un proyecto real ha resultado
una experiencia enriquecedora. A través de él se ha logrado controlar la
velocidad de avance del proyecto eficientemente. El cual se terminó
entregando con un retraso admisible de una semana posterior a la fecha
pactada con el cliente.
El hecho de haber terminado el trabajo obteniendo como resultado un

producto funcionando muestra que los objetivos planteados en un
principio se cumplieron. Pero lo más importante, es que se incrementaron
los conocimientos por lo que el trabajo implicó una gran satisfacción
personal.
Método Ágil Scrum
Aplicado al desarrollo de un software de Trazabilidad
ÍNDICE
INTRODUCCIÓN ------------------------------------------------------------------------3
PRIMERA PARTE: MARCO TEÓRICO
1. MÉTODOS ÁGILES-------------------------------------------------------------- 9
1.1. INTRODUCCIÓN ---------------------------------------------------------------------- 9
1.1.1. El dilema del software -------------------------------------------------------------------- 9
1.1.2. El surgimiento de la agilidad -----------------------------------------------------------10
1.2. ¿QUÉ ES UNA METODOLOGÍA ÁGIL? --------------------------------------10
1.2.1. La Alianza Ágil-----------------------------------------------------------------------------11
1.2.2. El Manifiesto Ágil -------------------------------------------------------------------------12
1.2.3. Metodologías ágiles vs. tradicionales------------------------------------------------16
2. SCRUM-----------------------------------------------------------------------------19
2.1. INTRODUCCIÓN ---------------------------------------------------------------------19
2.2. LA ESENCIA DE SCRUM ---------------------------------------------------------20
2.3. ELEMENTOS DE SCRUM---------------------------------------------------------21
2.3.1. Roles-----------------------------------------------------------------------------------------22
2.3.2. Poda de requerimientos-----------------------------------------------------------------25
2.3.3. Product Backlog---------------------------------------------------------------------------25
2.3.4. Sprint-----------------------------------------------------------------------------------------26
2.3.5. Valores --------------------------------------------------------------------------------------35
SEGUNDA PARTE: METODOLOGÍA
3. PROCESO DE DESARROLLO ----------------------------------------------38
3.1. INTRODUCCIÓN ---------------------------------------------------------------------38
3.2. PROCESO ITERATIVO E INCREMENTAL ----------------------------------38
3.3. ETAPAS DEL PROCESO DE DESARROLLO ------------------------------40
3.3.1. Planificación--------------------------------------------------------------------------------40
3.3.2. Análisis --------------------------------------------------------------------------------------40
3.3.3. Diseño ---------------------------------------------------------------------------------------41
3.3.4. Construcción y Prueba ------------------------------------------------------------------41
3.3.5. Implementación ---------------------------------------------------------------------------42
3.4. EDT DEL PROCESO DE DESARROLLO ------------------------------------43
3.5. HERRAMIENTAS --------------------------------------------------------------------44
3.5.1. Técnicas de relevamiento --------------------------------------------------------------44
3.5.2. Work Breakdown Structure (WBS) ---------------------------------------------------44
3.5.3. Casos de uso ------------------------------------------------------------------------------44
3.5.4. Diagrama de actividades----------------------------------------------------------------45
3.5.5. Diagrama de Entidad Relación (DER)-----------------------------------------------45
3.5.6. ScrumWorks -------------------------------------------------------------------------------46
3.5.7. Burndown chart ---------------------------------------------------------------------------47
3.5.8. Clarion 5.5 ----------------------------------------------------------------------------------47
María Laura Citón 1 Universidad de Mendoza

Método Ágil Scrum
TERCERA PARTE: DESARROLLO DE INGENIERÍA

4. PROYECTO TRAZABILIDAD ------------------------------------------------50
4.1. PLANIFICACION INICIAL ---------------------------------------------------------50
4.1.1. Solicitud del proyecto --------------------------------------------------------------------50
4.1.2. El porqué de la solicitud del proyecto------------------------------------------------50
4.1.3. Evaluación de la información deseada ----------------------------------------------52
4.1.4. Situación actual ---------------------------------------------------------------------------55
4.1.5. Estructura de División del Trabajo (EDT)-------------------------------------------56
4.1.6. Conformación del equipo humano----------------------------------------------------57
4.1.7. Estimación del plazo de entrega y precio-------------------------------------------57
4.1.8. Gestión de riesgo -------------------------------------------------------------------------60
4.1.9. Propuesta comercial ---------------------------------------------------------------------61
4.2. HERRAMIENTAS EXISTENTES EN EL MERCADO----------------------62
4.3. COMENZANDO CON SCRUM---------------------------------------------------65
4.3.1. Primer Sprint -------------------------------------------------------------------------------67
4.3.2. Segundo Sprint----------------------------------------------------------------------------71
4.3.3. Tercer Sprint -------------------------------------------------------------------------------74
4.3.4. Cuarto Sprint-------------------------------------------------------------------------------76
4.3.5. Quinto Sprint -------------------------------------------------------------------------------78
4.3.6. Sexto Sprint --------------------------------------------------------------------------------81
ANEXOS
ANEXO A--------------------------------------------------------------------------------84
PROPUESTA COMERCIAL ----------------------------------------------------------------84
ANEXO B--------------------------------------------------------------------------------87
INVESTIGACIÓN-------------------------------------------------------------------------------87
ANEXO C------------------------------------------------------------------------------ 116
ANÁLISIS DEL SISTEMA ----------------------------------------------------------------- 116
ANEXO D------------------------------------------------------------------------------ 141
DISEÑO DEL SISTEMA-------------------------------------------------------------------- 141
CONCLUSIONES ------------------------------------------------------------------- 149
BIBLIOGRAFÍA ---------------------------------------------------------------------- 151

Método Ágil Scrum
INTRODUCCIÓN
En el actual contexto económico, los profesionales en el área de las

tecnologías de la información se encuentran con la responsabilidad de
conducir eficientemente proyectos de gran envergadura, simples o
complejos, cortos o de larga duración, en ambientes cambiantes y
turbulentos.
Todo proyecto tiene una meta: la combinación de recursos de todo tipo,

reunidos en una estructura temporal para cumplir con un objetivo
predeterminado, adaptándose a los cambios que surgen, dentro de los
costos preestablecidos y respetando las especificaciones técnicas que
aseguran la calidad de los resultados.
Este nuevo concepto de lo que se considera hoy en día un proyecto

exitoso, nos lleva a reflexionar acerca de que el esquema “tradicional”
para abordar el desarrollo de software ha demostrado ser efectivo y
necesario en proyectos de gran tamaño (respecto a tiempos y recursos),
donde por lo general se exige un alto grado de formalidad en el proceso.
Sin embargo, este enfoque no resulta ser el más adecuado para muchos
de los proyectos actuales donde el entorno del sistema es muy
cambiante, y se exige reducir drásticamente los tiempos de desarrollo
manteniendo una alta calidad.
A raíz de este planteo surge la inquietud de ahondar en las metodologías

ágiles que nacieron, precisamente, como una alternativa a las
tradicionales. Por estar las metodologías ágiles especialmente orientadas

Método Ágil Scrum
a proyectos pequeños, constituyen una solución a medida para ese

entorno, aportando una elevada simplificación que, a pesar de ello, no
renuncia a las prácticas esenciales para asegurar la calidad del producto.
Se basan en la adaptabilidad de cualquier cambio como medio para
aumentar las posibilidades de éxito de los proyectos.
Las metodologías más características de esta familia son XP (Extreme

Programming), Scrum y Cristal; siendo Scrum la que hemos elegido para
desarrollar en detalle en este trabajo.
Scrum está basado en un proceso constructivo iterativo e incremental

donde las iteraciones tienen duración fija pero corta y el resultado final de
cada una de ellas es un producto funcional que contiene un subconjunto
de los requerimientos del proyecto. Constituyen el núcleo de Scrum, que
divide de esta forma el desarrollo de un proyecto en un conjunto de
pequeñas “carreras” llamadas Sprints. Cada Sprint es guiado por una lista
de funcionalidades priorizadas, que son planificadas con anterioridad.
Dentro de cada Sprint nunca se efectúa nada que no sea necesario para
cumplir los requerimientos del mismo.
Los principales motivos que nos han llevado a la elección de Scrum son:
Es uno de los métodos de gestión de proyectos más innovadores de los

denominados ágiles, ya que se destaca por una gran descentralización
como medio para alcanzar la mayor productividad posible.

Método Ágil Scrum
Es mucho menos conocido que otros métodos ágiles. Posiblemente una

de las causas es la escasa documentación existente, lo que lleva a
pensar que este trabajo puede resultar en un aporte significativo.
No está concebido como un método independiente, sino que se promueve

como complemento de otras metodologías. Enfatiza valores y prácticas de
gestión, sin pronunciarse sobre requerimientos, implementación y demás
cuestiones técnicas; de allí su deliberada insuficiencia y
complementariedad.
Por lo tanto, para el caso del desarrollo de software Scrum necesita ser
completado con algún otro método o procedimiento. A tal fin, se elabora
un proceso de desarrollo propio para llenar ese vacío metodológico. El
proceso es iterativo e incremental para que permita hacer entregas
parciales que se van complementando según avanza el proyecto. Nuestro
proceso respeta las cinco etapas tradicionales de un proyecto pero no
deja de cumplir con los principios y valores de las metodologías ágiles.
Las etapas son: planificación, análisis, diseño, construcción y prueba, e
implementación.
Para llevar a cabo las etapas mencionadas en el párrafo anterior se utiliza

una combinación de diferentes herramientas de la ingeniería del software,
entre las que podemos mencionar: las Estructuras de División del Trabajo
(EDT), los Casos de uso, los Diagramas de Actividades, los Diagramas de
Entidad Relación (DER), ScrumWorks para llevar adelante el seguimiento
del proyecto y Clarion 5.5 que es el lenguaje de programación.

Método Ágil Scrum
A continuación presentamos los objetivos generales que se han planteado

para el desarrollo del presente Trabajo Final.
Ø Conocer el método ágil Scrum para su posterior aplicación a un

proyecto real.
Ø Elaborar un proceso de desarrollo que lo complemente.
Ø Aplicar Scrum al desarrollo de un Software de Trazabilidad.
El porqué de la elección de desarrollar un Software de Trazabilidad y no

de cualquier otra temática se explica a continuación.
A raíz de que comienza a regir a partir del 1º de Mayo de 2005 una

normativa para la comercialización de productos con la Unión Europea -
Reglamento (CE) N° 178/2002; surge la posibilidad de desarrollar un
Software de Trazabilidad para un productor de uva de la zona de Lavalle.
La oportunidad de abordar esta temática de tanto auge en la actualidad

ha resultado de mucho interés, ya que se considera que el marco social,
económico y político de nuestro país hace muy importante a esta práctica
puesto que pretendemos exportar nuestra agroproducción desde un
contexto político observado y hasta a veces cuestionado por el mundo.
Este problema viene a ser asistido por las normas de calidad en general y
por la trazabilidad en particular. Se puede producir alimentos bajo normas
de calidad custodiadas internacionalmente que certifican que los
productos son elaborados bajo un estándar que no depende de la
situación país.

Método Ágil Scrum
Los productores agrarios deberían comenzar a responder a este requisito

de la UE. Es por ello que se desarrollará un Proyecto Trazabilidad que
comprenderá desde la solicitud del cliente hasta la entrega al mismo del
producto terminado.
Se explica a continuación la manera en la que se ha organizado el

Trabajo Final.
Primera Parte: Marco Teórico

Se presenta el contexto en el que surgen las metodologías ágiles, sus
valores, principios, comparaciones con las metodologías tradicionales y
se describe con detalle Scrum.
Segunda Parte: Metodología

Se explica el proceso de desarrollo elaborado para complementar Scrum;
etapas definidas y herramientas utilizadas.
Tercera Parte: Desarrollo de Ingeniería

Se despliega el desarrollo del proyecto, aplicando la metodología y el
proceso de desarrollo explicados en los capítulos anteriores, para
alcanzar el producto final, el Software de Trazabilidad.
Luego, se presentan 4 Anexos que forman parte del desarrollo del

proyecto y que se invita a consultarlos para conocer en detalle el mismo.

PRIMERA PARTE
MARCO TEÓRICO
Método Ágil Scrum
1. MÉTODOS ÁGILES
1.1. INTRODUCCIÓN
1.1.1. El dilema del software
Cualquiera que alguna vez haya sido responsable de conducir un
proyecto de desarrollo de software sabe que no es para nada fácil.
Coordinar y negociar exitosamente con las partes implicadas en el
proyecto desafía al más experimentado líder.
Y si bien, hoy en día, el software es una parte crítica de todo negocio, aún
los proyectos de desarrollo de software sufren de problemas en su gestión
que los pueden llevar directo al fracaso. Los problemas más frecuentes
son:
§ No se adaptan a los cambios.

§ Calidad insuficiente y muy variable.
§ Proyectos que exceden sus tiempos y costos.
Con base en lo anterior se ha llegado a un acuerdo de lo que significa un

proyecto de software exitoso, en tres dimensiones:
ü A tiempo.
ü En presupuesto.
ü Cumpliendo el alcance definido (incluye adaptabilidad a los
cambios y calidad).

Método Ágil Scrum
No es novedad que una forma de resolver los problemas de calidad, y

otros, de un producto es mejorando la forma de construir tales productos.
O sea.... mejorando los procesos.
En una actividad humana como es el desarrollo de software, esto es casi

equivalente a mejorar la metodología que se sigue para construir los
productos.
1.1.2. El surgimiento de la agilidad

Durante el transcurso de los años 90 el ambiente cambiante y turbulento
era cada vez más la regla que la excepción. Por lo tanto surgió la
necesidad de desarrollar metodologías livianas y maniobrables que
pudieran operar en ese ambiente turbulento. Estas metodologías son
conocidas colectivamente hoy en día como “metodologías ágiles”.
1.2. ¿QUÉ ES UNA METODOLOGÍA ÁGIL?

Lo ágil se define (por los mismos agilistas) como la habilidad de
responder de forma versátil al cambio para maximizar los beneficios. Las
metodologías ágiles varían en su forma de responder al cambio, pero en
general comparten las siguientes características:
ü Los individuos y sus interacciones son más importantes que los

procesos y las herramientas.
ü El software que funciona es más importante que la documentación

exhaustiva.

Método Ágil Scrum
ü La colaboración con el cliente en lugar de la negociación de

contratos.
ü La respuesta al cambio en lugar de aferrarse a un plan.
Los valores y principios compartidos por toda la metodología ágil fueron

enunciados en el “manifiesto ágil”, por la “alianza ágil”.
1.2.1. La Alianza Ágil

En una reunión celebrada en febrero de 2001 en Utha (EEUU), nace el
término “ágil” aplicado al desarrollo de software. En esta reunión
participaron un grupo de 17 expertos de la industria del software. Su
objetivo fue esbozar los valores y principios que debían permitir a los
equipos desarrollar software rápidamente y respondiendo a los cambios
que pueden surgir a lo largo del proyecto. Se pretendía ofrecer una
alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rígidos y dirigidos por la documentación que se
genera en cada una de las actividades desarrolladas.
Tras esta reunión se creó The Alliance, una organización dedicada a

promover los conceptos relacionados con el desarrollo ágil de software y
ayudar a las organizaciones para que los adopten. El punto de partida fue
el Manifiesto Ágil, un documento que resume la filosofía ágil.

Método Ágil Scrum
1.2.2. El Manifiesto Ágil

El Manifiesto comienza enumerando los principales valores del desarrollo
ágil. Se valora:
Al individuo y a las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito de
un proyecto de software. Si se sigue un buen proceso de desarrollo, pero
el equipo falla, el éxito no está asegurado; sin embargo, si el equipo
funciona, es más fácil conseguir el objetivo final, aunque no se tenga un
proceso bien definido. Así mismo, las herramientas (compiladores,
depuradores, control de versiones) son importantes para mejorar el
rendimiento del equipo, pero el disponer de más recursos de los
estrictamente necesarios también puede afectar negativamente.
Desarrollar software que funciona más que conseguir una buena

documentación. Aunque se parte de la base de que el software sin
documentación es un desastre, la regla a seguir es “no producir
documentos a menos que sean necesarios de forma inmediata para tomar
una decisión importante”. Estos documentos deben ser cortos y centrarse
en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se
incorpora al equipo de desarrollo, se considera que los dos elementos que
más le van a servir para ponerse al día son: el propio código y la
interacción con el equipo.
La colaboración con el cliente más que la negociación de un

contrato. Las características particulares del desarrollo de software
hacen que muchos proyectos hayan fracasado por intentar cumplir plazos

Método Ágil Scrum
y costes preestablecidos al inicio del mismo, según los requisitos que el

cliente manifestaba en ese momento. Por ello, se propone que exista una
interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y
asegure su éxito.
Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a lo largo del
proyecto (en los requisitos, la tecnología, el equipo) determina también el
éxito o fracaso del mismo. Por lo tanto, la planificación debe ser flexible
para poder adaptarse a los cambios que puedan surgir. Una buena
estrategia es hacer planificaciones detalladas para unas pocas semanas y
planificaciones mucho más abiertas para unos pocos meses.
Los valores anteriores inspiran los doce principios del manifiesto. Éstas
son las características que diferencian un proceso ágil de uno tradicional.
Los dos primeros son generales y resumen gran parte del espíritu ágil.
I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporten un valor. Un proceso es ágil si a
las pocas semanas de empezar ya entrega software que funcione
aunque sea rudimentario. El cliente decide si pone en marcha dicho
software con la funcionalidad que ahora le proporciona o
simplemente lo revisa e informa de posibles cambios a realizar.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que
el cliente tenga una ventaja competitiva. Los cambios en los registros
deben verse como algo positivo. Les va a permitir aprender más, a la
vez que logran una mayor satisfacción del cliente. Este principio

Método Ágil Scrum
implica además que la estructura del software debe ser flexible para
poder incorporar los cambios sin demasiado coste agregado.
Luego existen una serie de principios que tienen que ver directamente con
el proceso de desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas. Las entregas al cliente se insiste en que sean
software, no planificaciones, ni documentación de análisis o de
diseño.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto. El proceso de desarrollo necesita ser guiado por
el cliente, por lo que la interacción con el equipo es muy frecuente.
V. Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo. La gente es el principal factor de éxito, todos los
demás (proceso, entorno, gestión) queda en segundo plano. Si
cualquiera de ellos tiene un efecto negativo sobre los individuos debe
ser cambiado.
VI. El diálogo cara a cara es el método más eficiente y efectivo para

comunicar información dentro de un equipo de desarrollo. Los
miembros de equipo deben hablar entre ellos, éste es el principal
modo de comunicación. Se pueden crear documentos pero no todo
estará en ellos.

Método Ágil Scrum
VII. El software que funciona es la medida principal de progreso. El

estado de un proyecto no viene dado por la documentación generada
o la fase en la que se encuentre, sino por el código generado y el
funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el
50% de los requisitos ya están en funcionamiento.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los

desarrolladores y usuarios deberían ser capaces de mantener el
ritmo de desarrollo durante toda la ejecución del proyecto,
asegurando en todo momento que la calidad es máxima.
Finalmente los últimos principios están más directamente relacionados

con el equipo de desarrollo, en cuanto metas a seguir y organización del
mismo.
IX. La atención continua a la calidad técnica y al buen diseño mejora la

agilidad. Producir código claro y robusto es la clave para avanzar
más rápidamente en el proyecto.
X. La simplicidad es esencial. Tomar los caminos más simples que

sean consistentes con los objetivos perseguidos. Si el código
producido es simple y de alta calidad será más sencillo adaptarlo a
los cambios que puedan surgir.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los

equipos organizados por si mismos. Todo el equipo es informado de
las responsabilidades y éstas recaen sobre todos sus miembros. Es
el propio equipo el que decide la mejor forma de organizarse, de
acuerdo a los objetivos que se persigan.

Método Ágil Scrum
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a

ser más efectivo, y según esto ajusta su comportamiento. Puesto
que el entorno está cambiando continuamente, el equipo también
debe ajustarse al nuevo escenario de forma continua. Puede cambiar
su organización, sus reglas, sus convenciones, sus relaciones, etc.,
para seguir siendo ágil.
Los conceptos subyacentes no son nuevos, aunque toman nueva

importancia a partir del momento que se usan combinados.
1.2.3. Metodologías ágiles vs. tradicionales

A continuación vamos a enumerar las principales diferencias respecto de
las metodologías tradicionales (no ágiles).
El siguiente cuadro recoge esquemáticamente estas diferencias que no se

refieren sólo al proceso en sí, sino también al contexto de equipo y
organización que es más favorable a cada una de estas filosofías de
desarrollo de software.

Método Ágil Scrum
Metodologías Ágiles Metodologías Tradicionales

La planificación del trabajo sólo Trabajo y gestión guiada por un plan
comprende el ciclo en el que se está general del proyecto que comprende
trabajando (normalmente 30 días). todo su ciclo de desarrollo.
Descubrimiento progresivo de Conocimiento detallado de los
requisitos, e incorporación de cambios requisitos antes de comenzar el
en cualquier iteración del desarrollo. diseño del proyecto.
“Refactorización” de código como “Hacerlo bien a la primera”. Evitar la
modelo de trabajo compatible con el re-codificación y el re-trabajo que
punto anterior. supone una pérdida de eficiencia.
Comunicación directa entre los Comunicación formal según el plan
integrantes del equipo (incluidos cliente de comunicación del proyecto.
y usuarios) prefiriendo la verbal directa.
Equipos auto-gestionados. Gestión de equipos y personas
centralizada en el gestor del
proyecto.
No existe contrato tradicional o al Existe un contrato prefijado.

menos es bastante flexible.
El cliente es parte del equipo de El cliente interactúa con el equipo de
desarrollo. desarrollo mediante reuniones.
Grupos pequeños (hasta 20 integrantes) Grupos grandes y posiblemente
y trabajando en el mismo sitio. distribuidos.
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
Menos énfasis en la arquitectura del La arquitectura del software es
software. esencial y se expresa mediante
modelos.
Diferencias entre metodologías ágiles y no ágiles.
Las metodologías ágiles están revolucionando la manera de producir

software, y a la vez generando un amplio debate entre sus adeptos y
quienes por prejuicio no las ven como alternativa a las metodologías
tradicionales.
Aunque los creadores de las metodologías ágiles han suscrito el

manifiesto ágil, y todas ellas coinciden con los principios enunciados
anteriormente, cada una tiene características propias y hace hincapié en
algunos aspectos más específicos.

Método Ágil Scrum
Las metodologías ágiles más populares son: XP (Extreme Programming –

Programación Extrema), Cristal y Scrum. Por ser esta última la elegida
para desarrollar el presente trabajo mencionamos los tres principales
motivos que nos llevaron a su elección.
§ Sirve para gestionar proyectos de cualquier tipo, no solamente

tecnológicos.
§ Deja un vacío en la parte de definiciones del área de ingeniería lo

que permite una elaboración propia para completarla.
§ Tiene escasa documentación por lo que se piensa que este trabajo

puede resultar en un aporte significativo.
A continuación, en el próximo capítulo, de desarrolla en detalle Scrum.

Método Ágil Scrum
2. SCRUM
2.1. INTRODUCCIÓN
Scrum es una metodología ágil de gestión de proyectos cuyo objetivo
primordial es elevar al máximo la productividad de un equipo. Reduce al
máximo la burocracia y actividades no orientadas a producir software que
funcione y produce resultados en periodos muy breves de tiempo. Como
método, Scrum enfatiza valores y prácticas de gestión, sin pronunciarse
sobre requerimientos, prácticas de desarrollo, implementación y demás
cuestiones técnicas. Más bien delega completamente en el equipo la
responsabilidad de decidir la mejor manera de trabajar para ser lo más
productivos posibles.
La palabra Scrum procede de la terminología del juego de rugby, donde

designa al acto de preparar el avance del equipo en unidad pasando la
pelota a uno y otro jugador. Igual que el juego, Scrum es adaptable, ágil,
auto-organizante y con pocos tiempos muertos.
Scrum fue desarrollado por Jeff Sutherland y elaborado más formalmente

por Ken Schwaber. Poco después Sutherland y Schwaber se unieron para
refinar y extender Scrum. Se la ha llegado a conocer como una
herramienta de hiperproductividad. Schwaber se dio cuenta entonces de
que un proceso necesita aceptar el cambio, en lugar de esperar
predictibilidad. Se enfoca en el hecho de que procesos definidos y
repetibles sólo funcionan para atacar problemas definidos y repetibles con
gente definida y repetible en ambientes definidos y repetibles. Toma el
cambio como una forma de entregar al final del desarrollo algo más

Método Ágil Scrum
cercano a la verdadera necesidad del Cliente. Puede ser aplicado

teóricamente a cualquier contexto en donde un grupo de gente necesita
trabajar junta para lograr una meta común.
Se basa en los principios ágiles:
ü Privilegiar el valor de la gente sobre el valor de los procesos.
ü Entregar software funcional lo más pronto posible.
ü Predisposición y respuesta al cambio.
ü Fortalecer la comunicación y la colaboración.
ü Comunicación verbal directa entre los implicados en el proyecto.
ü Simplicidad; supresión de artefactos innecesarios en la gestión del

proyecto.
2.2. LA ESENCIA DE SCRUM

§ Más que una metodología de desarrollo es para gestionar
proyectos, no contiene definiciones en áreas de ingeniería.
§ Con visión de que el trabajo es efectuado por equipos auto-

organizados y auto-dirigidos, logrando motivación, responsabilidad
y compromiso.

Método Ágil Scrum
§ Está basada en un proceso constructivo iterativo e incremental

donde las iteraciones tienen duración fija.
§ Contiene definición de roles, prácticas y productos de trabajo
escritas de forma simple.
§ Está soportada en un conjunto de valores y principios.
Nueva
Sprint Backlog
funcionalidad
Product Backlog
seleccionado
Product Backlog
Requisitos
priorizados
Visión:
ROI – versiones
hitos
El flujo de Scrum
2.3. ELEMENTOS DE SCRUM

§ Roles
Ø Product Owner
Ø Scrum Master
Ø Team (Equipo)

Método Ágil Scrum
§ Poda de requerimientos
§ Product Backlog
§ Sprint
Ø Planificación
Ø Sprint Backlog
Ø Scrum
Ø Estimaciones
Ø Builds continuos
Ø Revisión del Sprint
Ø Reunión retrospectiva
§ Valores
Ø Foco, comunicación, respeto y coraje.
2.3.1. Roles
La dimensión del equipo total de Scrum no debería ser superior a veinte
personas. Si hay más, lo más recomendable es formar varios equipos. No
hay una técnica oficial para coordinar equipos múltiples, pero se han
documentado experiencias de hasta 800 miembros, divididos en Scrums
de Scrum, definiendo un equipo central que se encarga de la
coordinación, las pruebas cruzadas y la rotación de los miembros.
Scrum tiene una estructura muy simple. Todas las responsabilidades del
proyecto se reparten en 3 roles:

Método Ágil Scrum
Ø Product owner (Dueño del producto)

Representa a todos los interesados en el producto final. Sus áreas de
responsabilidad son:
• Financiación del proyecto

• Requisitos del sistema
• Retorno de la inversión del proyecto
• Lanzamiento del proyecto
Es el responsable oficial del proyecto, gestión, control y visibilidad de la

lista de acumulación o lista de retraso del producto (Product Backlog).
Toma las decisiones finales de las tareas asignadas al registro y convierte
sus elementos en rasgos a desarrollar.
Ø Scrum Master (Líder del proyecto)

Responsable del proceso Scrum, de cumplir la meta y resolver los
problemas. Así como también, de asegurarse que el proyecto se lleve a
cabo de acuerdo con las prácticas, valores y reglas de Scrum y que
progrese según lo previsto.
Interactúa con el cliente y el equipo. Coordina los encuentros diarios, y se

encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo
y trabajar a la par.

Método Ágil Scrum
Ø Team (Equipo)
Responsable de transformar el Backlog de la iteración en un incremento
de la funcionalidad del software. Tiene autoridad para reorganizarse y
definir las acciones necesarias o sugerir remoción de impedimentos.
• Auto-gestionado
• Auto-organizado
• Multi-funcional
La dimensión del equipo total de Scrum no debería ser superior a veinte.

El número ideal es diez, más o menos dos. Si hay más, lo más
recomendable es formar varios equipos. No hay una técnica oficial para
coordinar equipos múltiples, pero se han documentado experiencias de
hasta 800 miembros, divididos en Scrums de Scrums, definiendo un
equipo central que se encarga de la coordinación, las pruebas cruzadas y
la rotación de los miembros.
Roles: gallinas y cerdos

El nombre de los miembros del equipo y los externos se deriva de una
típica fábula agilista: un cerdo y una gallina discutían qué nombre ponerle
a un nuevo restaurante; la gallina propuso “Jamón y Huevos”. “No,
gracias”, respondió el cerdo, “Yo estaré comprometido, mientras tú sólo
implicada”.
Scrum diferencia claramente entre estos dos grupos para garantizar que
quienes tienen la responsabilidad tienen también la autoridad necesaria

Método Ágil Scrum
para poder lograr el éxito, y que quienes no tienen la responsabilidad, los

observadores externos, no produzcan interferencias innecesarias.
Comprometido en el proyecto Implicados en el proyecto
§ Dueño del producto § Marketing

§ Equipo § Comercial
§ Scrum Master § Etc.
2.3.2. Poda de requerimientos

La primera actividad es armar una lista exhaustiva de los requerimientos
originales del sistema. Luego se procede a ver qué requerimientos son
realmente necesarios, cuáles pueden posponerse y cuáles eliminarse.
Para ello debe identificarse un representante con capacidad de decisión,
priorizar los requerimientos en base a su importancia y acordar cuáles son
los prioritarios para la fecha de entrega.
La poda de requerimientos es una buena práctica implícita en modelos

ágiles, se hace lo que el cliente realmente desea, no más.
2.3.3. Product Backlog

Con los requerimientos priorizados y podados armamos el Backlog de
Producto. Este es una forma de registrar y organizar el trabajo pendiente
para el producto (actividades y requerimientos).
Es un documento dinámico que incorpora constantemente las

necesidades del sistema. Por lo tanto, nunca llega a ser una lista

Método Ágil Scrum
completa y definitiva. Se mantiene durante todo el ciclo de vida (hasta la

retirada del sistema) y es responsabilidad del Product Owner.
2.3.4. Sprint
Scrum está basado en el control empírico de procesos. Se utiliza cuando
la capacidad de predicción es vaga, la incertidumbre alta o el proceso es
demasiado complejo para ser modelado y definido.
En el enfoque empírico de control de procesos se establecen reglas

simples y se crea una disciplina de inspección frecuente para adaptarse
rápidamente a situaciones imprevistas o problemas.
Control:
C Inspección diaria y
resolución de problemas
E PROCESO S
Entrada: Salida:
Backlog de producto Nuevo incremento
seleccionado Proceso: del producto
Sprint con sus
prácticas y reglas
Un Sprint es el periodo de tiempo durante el que se desarrolla un

incremento de funcionalidad. Constituye el núcleo de Scrum, que divide
de esta forma el desarrollo de un proyecto en un conjunto de pequeñas
“carreras”.

Método Ágil Scrum
• Duración máxima del Sprint : 30 días.
• Durante el Sprint no se puede modificar el trabajo que se ha

acordado en el Backlog.
• Sólo es posible cambiar el curso de un Sprint, abortándolo, y sólo

lo puede hacer el Scrum Master si decide que no es viable por
alguna de las razones siguientes:
- La tecnología acordada no funciona.

- Las circunstancias del negocio han cambiado.
- El equipo ha tenido interferencias.

Método Ágil Scrum
Ø Planificación
Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que
los objetivos no van a cambiar durante el mismo. De esta manera se
atenúa el riesgo.
Aspectos a tener en cuenta sobre la planificación de un Sprint:
• Una determinación general de alcance, frecuentemente basada en

una EDT (Estructura de División del Trabajo).
• Estimaciones de esfuerzo de alto nivel realizadas durante la etapa

de concepción del proyecto.
• Esfuerzo dedicado a labores de soporte o de preparación de los

ambientes requeridos por el proyecto.
• Esfuerzo asociados a las reuniones diarias, de planificación y de

revisión.
• Requerimientos de recursos de infraestructura o logísticos

(máquinas, redes, licencias, papel, pizarras, etc.).
• Habilidades presentes y necesarias en el equipo.
• Restricciones asociadas al conocimiento del negocio, la tecnología

o externas (legales, reglamentarias, estándares, etc.).

Método Ágil Scrum
Rol del Scrum Master durante la planificación:
ü Dirige la planificación.
ü Es vínculo entre el equipo y el Product Owner del proyecto.
ü Registra problemas y riesgos detectados durante la planificación.
ü Registra las tareas, asignaciones y estimaciones.
ü Inicia el Backlog del Sprint.
Ø Sprint Backlog
Trabajo o tareas determinadas por el equipo para realizar en un Sprint.
• Tareas a convertir en producto funcional.
• Las tareas se estiman en una duración entre 1 a 20 horas de

trabajo. Las de mayor duración deben intentar descomponerse en
sub-tareas de ese rango de tiempo.
• La estimación se actualiza día a día.
Ø Scrum diario
Scrum asume que el proceso es complejo y que es necesario
inspeccionarlo frecuentemente, por eso se realiza una reunión diaria de
seguimiento. El encuentro diario impide caer en el dilema señalado por
Fred Brooks: “¿Cómo es que un proyecto puede atrasarse un año? Un día
a la vez”.

Método Ágil Scrum
El foco de la reunión es determinar el avance en las tareas y detectar

problemas o “bloqueos” que estén haciendo lento el progreso del equipo o
que eventualmente impidan a un equipo cumplir con la meta del Sprint. La
idea es que ningún problema quede sin resolver o, por lo menos, sin
iniciar alguna acción de respuesta dentro de las 24 horas después de su
detección.
La reunión es además un espacio definido para que cada miembro del

equipo comunique a los demás el estado de su trabajo y por lo tanto
reafirme el compromiso.
Tips para un buen Scrum diario:
• Todos los días en el mismo sitio y a la misma hora. Con una

duración máxima de 15 minutos.
• Se recomienda que sea la primera actividad del día.
• Deben acudir todos los miembros del equipo.
• Hacer un círculo, permitir que todos vean a todos.

• Mantener el foco.
• Solo habla una persona a la vez y los demás escuchan. No se

permiten interrupciones, entrar y salir, hablar por teléfono, etc.
• Sólo se habla de: ¿En que trabajé ayer? ¿En que voy a trabajar
hoy? ¿Que problemas impiden mi progreso?

Método Ágil Scrum
• No iniciar discusiones muy largas sobre temas técnicos o sobre los

problemas, esto hay que registrarlo y manejarlo después de la
reunión.
• Si están permitidas las preguntas para aclarar el alcance de un

trabajo o de un problema.
• Cuando un miembro informa de algo de interés para otros, o

necesita ayuda de otros, estos se reúnen al terminar la revisión
diaria.
• Las gallinas no pueden intervenir ni distraer, y el Scrum Master

puede limitar el número de gallinas asistentes si lo considera
oportuno.
Rol del Scrum Master durante el Scrum:

ü Dirige la reunión y mantiene el foco.
ü Hace preguntas para aclarar dudas.
ü Registra (escribe o documenta) los problemas para su resolución
después de la reunión.
ü Se asegura que los miembros cuenten con el ambiente adecuado
para la reunión.
Ø Estimaciones
Las estimaciones se realizan por primera vez en la reunión de
planificación al inicio del Sprint. Luego las tareas se re-estiman todos los
días y se registran sus cambios en el Backlog del Sprint; esta actividad
puede ser realizada inmediatamente antes o después del Scrum diario.

Método Ágil Scrum
Algunas claves para la estimación:
• Siempre se realizan estimaciones de esfuerzo, no de duración.
• Siempre se estima el esfuerzo total pendiente para terminar la

tarea, no se estima el esfuerzo consumido.
• Se buscan unidades manejables, lo usual es que estén en un

mínimo de 2 horas y un máximo de 20. Si la tarea es muy corta se
trata de juntarla con otras relacionadas. Si la tarea es muy grande
se trata de descomponerla.
Ø Builds continuos y pruebas básicas

La estrategia que generalmente se utiliza es la de Builds continuos y
“smoke test” (prueba básica para la funcionalidad del sistema).
Se itera por estas fases
El programador Pasa a integración lo Se prueba que no se

libera código. más pronto posible rompa el build.
(diario al menos).

Método Ágil Scrum
Procedimiento de Builds continuos
• Los programadores desarrollan según el Backlog del Sprint, y al

finalizar, notifican al integrador.
• El integrador toma el código y lo integra con el resto del producto.
• Se compila el software y se prueba “por arriba” el producto, para

verificar que no se haya roto.
• Si se encuentran problemas se devuelve al desarrollador.
• Se notifica al equipo que hay una nueva versión “estable” del

código para usar como base.
Ø Revisión del Sprint

El objetivo de la reunión de revisión es presentar el producto o porción del
producto desarrollada por el equipo a los usuarios. La reunión se utiliza
para detectar inconformidades mayores que se vuelven elementos del
Backlog de Producto y que eventualmente se resuelven en el siguiente
Sprint.
A la reunión asisten el equipo, el Scrum Master, el Product Owner y todas

las personas implicadas en el proyecto (gallinas).
Tips para una buena revisión:

• Duración máxima de la reunión: 4 horas.

Método Ágil Scrum
• Preparar la presentación, teniendo en cuenta que lo único que se

presenta es el producto (no Power Point o similares).
• Mantener el foco durante la reunión de revisión, el foco es el

producto solamente.
• Finalidad: presentar al propietario del producto y a las gallinas las

nuevas funcionalidades implementadas.
• Las funcionalidades no implementadas no se presentan.
• Registrar todos los comentarios e inconformidades declaradas de

los usuarios sobre el producto para determinar cuales de ellas
formarán parte del Backlog.
Ø Reunión retrospectiva
Scrum involucra el concepto de mejora continua a través de las reuniones
de retrospección. Las reuniones buscan detectar los puntos positivos y
negativos del Sprint para generar propuestas de mejora para futuros
Sprints.
Las reuniones de retrospección son el concentrador del aprendizaje

organizacional sobre el Scrum. Los puntos positivos y negativos se
registran y se definen ítems de acción para cada uno. Los ítems de acción
definidos se toman en cuenta en los siguientes Sprints.

Método Ágil Scrum
Acuden el equipo y el Scrum Master, y opcionalmente el Product Owner

del Producto.
Tips para una buena retrospección:
• Todos los miembros del equipo responden a dos preguntas:
- ¿Qué cosas fueron bien en el último Sprint?

- ¿Qué cosas se podrían mejorar?
• El Scrum Master anota todas las respuestas.
• El equipo prioriza las mejoras posibles.
• El Scrum Master no proporciona respuestas, sino que ayuda al

equipo a encontrar la mejor forma de trabajar con Scrum.
• Las acciones de mejora localizadas que se puedan implementar en

el próximo Sprint deben introducirse en el Backlog como elementos
no funcionales.
2.3.5. Valores
Foco à Los individuos y sus interacciones son más importantes que el
proceso y las herramientas. La gente es el principal factor de éxito de un
proyecto de software.

Método Ágil Scrum
Comunicación à Scrum pone en comunicación directa y continua a

clientes y desarrolladores. El cliente se integra en el equipo para
establecer prioridades y resolver dudas. De esta forma ve el avance día a
día, y es posible ajustar la agenda y las funcionalidades de forma
consecuente.
Respeto à Scrum diferencia claramente entre dos grupos para garantizar

que quienes tienen la responsabilidad tienen también la autoridad
necesaria para poder lograr el éxito (cerdos), y que quienes no tienen la
responsabilidad, los observadores externos (gallinas), no produzcan
interferencias innecesarias.
Coraje à El coraje implica saber tomar decisiones difíciles. Reparar un

error cuando se detecta. Mejorar el código siempre que el feedback y las
sucesivas iteraciones se manifiesten susceptibles de mejora.

SEGUNDA PARTE
METODOLOGÍA
Método Ágil Scrum
3. PROCESO DE DESARROLLO
3.1. INTRODUCCIÓN
En este apartado se presenta el proceso de desarrollo elaborado para
complementar la metodología Scrum ya que esta no contiene definiciones
en cuestiones técnicas.
Se utiliza un proceso ágil iterativo e incremental que respeta las cinco

etapas tradicionales de un proyecto que facilitan su gestión y control; ellas
son: planificación, análisis, diseño, construcción y prueba, e
implementación. Cómo el objetivo final de la metodología es llegar al éxito
del proyecto se definen, en forma clara, los entregables de cada etapa y
el alcance global, reflejando estos puntos en la planificación de todas las
tareas involucradas.
Se considera que: etapas delimitadas, entregables definidos y tareas

acotadas son claves para el cumplimiento del plan.
3.2. PROCESO ITERATIVO E INCREMENTAL

Este tipo de proceso de desarrollo permite hacer entregas parciales que
se van complementando según avanza el proyecto. De esta manera se
reducen los riesgos y a la vez el cliente va experimentando los resultados
de su proyecto.

Método Ágil Scrum
Dado que los proyectos de software son largos es común dividir el trabajo
en mini proyectos. Cada mini proyecto es una iteración que resulta en un
incremento. Para ser más efectivas las iteraciones deben ser controladas,
es decir deben ser seleccionadas y llevadas a cabo de una forma
planeada.
Se ha propuesto un proceso iterativo para garantizar la realimentación de

información y de requisitos una vez iniciado el desarrollo, así como la
validación continua del sistema. Esto permite que cada iteración
contemple ciclos de desarrollos completos y cortos, y obtener así
rápidamente, una nueva versión con mejoras sobre las versiones
anteriores.
Se ha propuesto un proceso incremental en el sentido de añadir

capacidades y funcionalidades al software de acuerdo con el crecimiento
de las necesidades; con el propósito de obtener el sistema final tras la
realización de diferentes ciclos. El final de cada ciclo proporciona además,
una versión estable del software. Esto permite entregas al cliente de
forma rápida y ágil.
Al entregar partes de la aplicación a tiempo y regularmente, el equipo de

desarrollo también gana y establece credibilidad en su entorno y aumenta
su auto-estima. A la vez que este tipo de estrategia se enfoca más en las
necesidades de los usuarios, instándolos a identificar sus prioridades en
cada etapa del proyecto.

Método Ágil Scrum
A continuación detallamos las etapas por las cuales transita nuestro

proceso de desarrollo y la combinación de herramientas utilizadas en él.
3.3. ETAPAS DEL PROCESO DE DESARROLLO

3.3.1. Planificación
Objetivo: Es la etapa más importante de todas, ya que se define el
proyecto propiamente dicho.
Tareas: Relevamiento preliminar de los procesos del negocio, definición y

secuenciamiento de actividades, definición del alcance, estimación de
tiempos, definición de recursos, análisis de riesgos, estimación de costos.
Entregables: Documento de definición del proyecto o del Sprint.
En esta etapa es importante aclarar que, al comienzo, la planificación se

realiza en forma general para determinar el alcance, la duración y el
precio del proyecto, una vez que el cliente decide llevarlo a cabo, las
siguientes planificaciones son a nivel de iteración, se planifica el Sprint.
3.3.2. Análisis
Objetivo: Obtener todas las definiciones y especificaciones funcionales
para poder llevar adelante las fases de Diseño y Construcción. Es una
etapa clave ya que el alcance y las características de la solución quedan
acordados, lo cual permite mitigar los principales riesgos de un proyecto.

Método Ágil Scrum
Tareas: Afianzamiento de las definiciones funcionales, definición de los

requisitos a través de casos de uso, planificación de las etapas
posteriores y ajuste de los tiempos preestablecidos.
Entregable: Documento de alcance, casos de uso y sus respectivas

descripciones.
3.3.3. Diseño
Objetivo: Generar el modelo de datos para que la solución cumpla con
los requerimientos definidos. El diseño generado deberá contemplar las
posibles modificaciones futuras, crecimiento de la solución, mayor carga e
incorporación de nuevas funcionalidades.
Tareas: Diagrama Entidad Relación (DER), diseño de las interfaces de

usuario, diseño de las integraciones a realizar. Durante esta etapa
también se realizan pruebas para puntos críticos del proyecto.
Entregables: Entre los entregables típicos de esta etapa se encuentran:

DER, esqueleto del software armado, guía de diseño, diseño de la
infraestructura, y la planificación ajustada con la evolución y avances
obtenidos.
3.3.4. Construcción y Prueba

Objetivo: Construir la solución del Release (Sprint), cumpliendo con las
definiciones y especificaciones de los documentos de alcance.

Método Ágil Scrum
Generalmente es la etapa de mayor duración y con mayor dinámica de

trabajo.
Tareas: Programación y desarrollo de todos los componentes y

funcionalidades. Implementación de las estructuras de datos, y sus
procedimientos, elaboración de documentación técnica y ajustes
funcionales, implementación de las integraciones y todas las actividades
necesarias para poner en marcha la solución. En esta etapa se realizarán
las pruebas de usabilidad, funcionalidad y carga de datos.
Entregables: El entregable principal es el incremento de software

funcionando.
3.3.5. Implementación
Objetivo: Disponer del sistema productivo con sus ambientes de
producción, metodología de trabajo y manuales operativos. Se incluye, de
ser necesario, el personal operativo capacitado. Obtención de nuevas
funciones a agregar o posibles errores a reparar.
Tareas: Puesta en marcha de la aplicación en el ambiente de producción,

elaboración de manuales operativos, y todas las actividades relacionadas
al éxito del lanzamiento como la integración del ambiente de producción
con terceras partes, etcétera.

Método Ágil Scrum
Entregables: El sistema productivo con sus manuales operativos, de

mantenimiento y de procedimientos. Esquemas de auditoria y seguridad.
Integraciones con terceras partes operativas. Sistema totalmente
probado.
3.4. EDT DEL PROCESO DE DESARROLLO

Presentamos nuestro proceso de desarrollo a través de una Estructura de
División del Trabajo para verlo gráficamente.
Objetivos
Modelo de
negocio Procesos
Actividades
Planificación
Estimación Alcance
Estimación Tiempo
Especificaciones funcionales
Análisis Requerimientos
Ajuste de tiempos
Proceso de
desarrollo
Modelo de datos
Diseño
Interfases
Releases Programar
Construcción
Integración y pruebas
y Pruebas
Revisión y Retrospección
Puesta en marcha
Implementación
Carga de datos

Método Ágil Scrum
3.5. HERRAMIENTAS
3.5.1. Técnicas de relevamiento
Entrevistas con el cliente y los usuarios; revisión de registros, y
observación.
3.5.2. Work Breakdown Structure (WBS)

Conocida como Estructura de Descomposición de Trabajos (EDT). Es un
organigrama que despliega la estructura de un proyecto y muestra su
organización por fases y niveles de detalle. Cada nivel de descenso
representa un aumento en el nivel de detalle de las descripciones de las
actividades, sirve de lista de comprobación, y determina el alcance
general. Así como también, define los entregables del proyecto. Los
entregables pueden ser etapas o procesos del proyecto (plan del
proyecto, documentación de diseño, etc.) o partes del producto final
(pantallas, ventanas, documentación).
Se irá comentando a lo largo de este punto en cuales de las etapas de

desarrollo se aplican las herramientas explicadas. Entonces, tanto el WBS
como las técnicas de relevamiento mencionadas anteriormente se utilizan
en las dos primeras etapas, o sea para la Planificación y el Análisis.
3.5.3. Casos de uso

Son un método práctico para explorar requerimientos. Ayudan a describir
qué es lo que el sistema debe hacer desde el punto de vista del usuario.
Por lo tanto, consideramos que los casos de uso proporcionan un modo
claro y preciso de comunicación con el cliente.

Método Ágil Scrum
Descripciones de casos de uso: detallan los casos de uso, en ellas se

explica la forma de interactuar entre el sistema y el usuario.
Tanto los casos de uso como las descripciones de los mismos se utilizan
en la etapa del análisis para definir los requisitos.
3.5.4. Diagrama de actividades

Sirven fundamentalmente para modelar el flujo de control entre
actividades. La idea es generar una especie de diagrama en el que se
puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así
como las tareas concurrentes que pueden realizarse a la vez. El diagrama
de actividades sirve para representar el sistema desde otra perspectiva.
Desde un punto de vista conceptual, la actividad es alguna tarea que
debe ser realizada. Por este motivo, en un diagrama de actividades
aparecerán acciones y actividades correspondientes a distintas clases;
colaborando todas ellas para conseguir un mismo fin.
Los diagramas de actividad son similares a los diagramas de flujo

procesales, con la diferencia de que todas las actividades están
claramente asociadas a un caso de uso. También se utilizan en la etapa
del análisis.
3.5.5. Diagrama de Entidad Relación (DER)

Un modelo de datos describe de una forma abstracta cómo se
representan los datos, sea en una empresa, en un sistema de información
o en un sistema de base de datos.

Método Ágil Scrum
Los DER son una herramienta para el modelado de datos de un sistema

de información. Estos diagramas expresan entidades relevantes y sus
inter-relaciones. Formalmente, son un lenguaje gráfico para describir
conceptos. Informalmente, son simples dibujos o gráficos que (si se saben
interpretar) describen la información que trata un sistema de información y
el software que lo automatiza.
Los DER se aplican en la etapa de Diseño.
3.5.6. ScrumWorks
Permite llevar a cabo el seguimiento del proyecto. Es una herramienta de
automatización de procesos ágiles que admite a los equipos auto-
organizarse y aumentar la productividad. Esta herramienta, de acceso
libre y fácil de utilizar, es una aplicación Web que permite compartir la
información entre todo el equipo.
Esta herramienta para la administración del proyecto permite:
§ Manejar dinámicamente el Backlog de Producto haciendo una

estimación inicial del esfuerzo de cada requerimiento identificado
hasta el momento.
§ Definir las tareas y arrastrarlas al Sprint apropiado, donde se irán re-

estimando diariamente.
§ Observar un gráfico por cada Sprint que nos indica la velocidad con la
que avanza el proyecto.

Método Ágil Scrum
Estos gráficos llamados “burndown” no sólo permiten observar el estado

de avance del proyecto, sino también analizar sus comportamientos e ir
aprendiendo para mejorar los Sprints que restan.
3.5.7. Burndown chart

En Scrum se planifica y se mide el esfuerzo restante necesario para
desarrollar el producto. Esta gráfica suele utilizarse en lugar de un
diagrama de PERT debido a que el camino crítico en un desarrollo ágil
cambia diariamente. Esto haría obsoleto el diagrama de PERT cada día.
Es por esto que no es útil una herramienta que modele el camino crítico a
partir de actividades.
La solución es utilizar una técnica que permita medir la velocidad de

desarrollo, para ello se utiliza el criterio del equipo a partir del cual se
calcula diariamente el camino crítico. Esto permite recalcular el plan y la
velocidad en que se realiza el trabajo. En función de esto el equipo puede
trabajar para acelerar o desacelerar el trabajo para cumplir con la fecha
de entrega.
3.5.8. Clarion 5.5

Herramienta capaz de crear programas de 32 bits para Windows 9x, NT,
2000, y XP y para la Internet / Intranet / Extranet desde un único código y
con un diseñador de diccionario de datos integrado. Incluye drivers
nativos a distintos formatos de bases de datos (Oracle, MS SQL, Informix,
Btrieve, Pervasive SQ, ASCII, DOS/Basic, xBase) y bases de datos multi-
usuarios propietarias (Clarion y Topspeed).

Método Ágil Scrum
El generador de aplicaciones junto con una serie de Templates (plantillas)

predefinidos y personalizables y las Clases ABC (Application Builder
Class), trabajan para producir código OOP (Programación Orientada a
Objetos) pre-testeado.
La base de la productividad es el Lenguaje 4GL, que está

específicamente creado para construir aplicaciones de negocios con
bases de datos propias o centralizadas. Se puede acceder virtualmente a
cualquier tipo de datos a través de una combinación de ODBC/ADO y los
drivers nativos de las bases.

TERCERA PARTE
DESARROLLO DE INGENIERÍA
Método Ágil Scrum
4. PROYECTO TRAZABILIDAD
4.1. PLANIFICACION INICIAL

4.1.1. Solicitud del proyecto
El presente proyecto surge de una solicitud realizada por un productor de
uva y propietario de tres fincas ubicadas en el departamento de Lavalle,
quien ha pedido la construcción de un Software de Trazabilidad que le
facilite la tarea de registración de todas las operaciones realizadas
durante el proceso de producción de cada una de sus propiedades, que
permita optimizar el manejo de información en el campo y demostrar que
se cumple con la trazabilidad.
Como todo cliente, y es lógico que así sea, de las dos primeras preguntas
de las cuales espera obtener respuesta son:
¿Para cuándo va a estar listo?

¿Cuánto va a costar?
Para dar respuesta a ellas se decidió tener tres entrevistas con el

potencial cliente con el objetivo de comprender el porqué de la solicitud,
determinar más en detalle sus necesidades, y conocer su situación actual,
entonces, a partir de ello, elaborar la propuesta comercial.
4.1.2. El porqué de la solicitud del proyecto

La solicitud del proyecto de desarrollar un Software de Trazabilidad para
la producción de uva nace a partir de las amenazas que han surgido en el

Método Ágil Scrum
mundo en materia de seguridad que han llevado a EE.UU. y a la Unión

Europea (UE) a adoptar severas medidas en los procedimientos de
importación de productos, especialmente los alimentos para uso humano
y animal. La situación que se presenta en la actualidad parte de un
principio general de prohibición que establece que no se comercializarán
alimentos que no sean seguros, que por definición reglamentaria
comprende tanto aquellos que sean nocivos para la salud, como los que
no sean aptos para el consumo humano.
En el sector agroalimentario la calidad debe constituir, ante todo, una

garantía de protección de la salud humana y, en consecuencia, este
aspecto representa hoy el núcleo alrededor del cual se establecen las
exigencias para la producción y la comercialización de los alimentos.
Este problema viene a ser asistido por las normas de calidad en general y
por la trazabilidad en particular. El 1º de Mayo de 2005 entró en vigencia
la normativa para la comercialización de productos con la Unión Europea,
Reglamento (CE) N° 178/2002 que se refiere específicamente a la
trazabilidad en la producción.
La trazabilidad es un hecho, la UE la ha convertido en un requisito y

contempla distintos procedimientos a seguir. Inclusive, podemos esperar
que otros países le sigan en su requerimiento. La previsión es que la
nueva norma afecta a las etapas de producción, transformación,
elaboración, distribución y comercialización alimentaria.

Método Ágil Scrum
Poco antes de su aplicabilidad, surgen las dudas sobre si todos los

operadores presentes a lo largo de la cadena alimentaria están
preparados para asumir las obligaciones que provienen de la normativa
comunitaria. La preocupación se ha instalado en algunos sectores,
especialmente en la producción primaria, que en algunos supuestos
concretos ya se han manifestado como incapaces de cumplimentarlos en
este breve espacio de tiempo, conocedores de la responsabilidad que
asumen cuando el resto de los eslabones ya han dispuesto medidas para
adaptarse a estos nuevos requisitos normativos.
La trazabilidad, sin embargo, no es la única causa de esta situación de

seguridad, aunque sí es un elemento que contribuye decisivamente y una
herramienta útil para los productores. Las empresas del sector
frutihortícola tienen un importante reto ante los consumidores y ante sí
mismos: pueden contemplar la nueva legislación como un problema o
como una oportunidad para lograr que sus productos sean mejor
valorados y compitan con ciertas ventajas con productos de otros países
que no aplican los estrictos criterios de los que se ha dotado la UE. Si,
además, la aplicación de la trazabilidad permite acceder a mercados
tradicionalmente exigentes como EEUU, las empresas empezarán a
obtener beneficios tangibles y más participación en el mercado.
4.1.3. Evaluación de la información deseada

Una vez comprendido el porqué de la solicitud del proyecto, se
determinan las necesidades del cliente. Es decir, se establecen los
aspectos que debe abarcar el Software de Trazabilidad.

Método Ágil Scrum
No obstante, previo al desarrollo del producto, se hará una pequeña

investigación sobre la producción de uva y vino, sus exportaciones a
países de la Unión Europea; así como también, las normativas vigentes
referentes a la trazabilidad, la importancia de la misma y alternativas para
aplicarla. Esta investigación será el primer entregable que se dará al
cliente.
Con respecto al Software de Trazabilidad debe permitir conocer la historia

de la uva a través del ciclo de producción; identificar el cómo, quién,
cuándo, dónde y por qué se hizo en cualquier etapa de la cadena
agrícola. Debe poder identificar los productos, hasta el momento en que el
operador realice su entrega al siguiente eslabón en la cadena.
El software deberá mantener un registro de las propiedades rurales,

identificando para cada una de ellas sus titulares y/o productores, y para
cada viñedo la distribución de sus cuarteles, origen de los mismos, el tipo
de conducción y las variedades de uva que contempla.
Administrar datos de titulares y/o productores, trabajadores, proveedores

y bodegas.
Administrar las maquinarias y camiones, con sus revisiones técnicas y

seguros de transportes correspondientes.

Método Ágil Scrum
Permitir predefinir las tareas y tratamientos agrícolas habituales a fin de

simplificar su identificación en el momento de su aplicación e indicando,
para cada labor realizada, los insumos, agroquímicos, dosis y métodos
de aplicación utilizados. En todos los casos debe identificarse un
responsable, que se encargue tanto de la operación como de su
respectivo registro.
Registrar en forma rápida y sencilla cada uno de los partes de las tareas
agrícolas que se realizan en la finca, que contienen información como:
tarea que se realizó, duración, trabajador, máquinas y agroquímicos
utilizados.
Registrar en forma rápida y sencilla cada uno de los remitos de cosecha

que se efectúan durante la vendimia, que contienen información como:
finca, cuartel, cosechador, kilos, camión, bodega destino, etc.
Permitir la captura automática del peso de las cajas o bins proveniente de

la báscula. El sistema debe dar la opción de que la captura sea
automática o manual.
Ver la trazabilidad de los productos en ambos sentidos. Realizar consultas

sobre la cosecha de uva y las auditorias.
Administrar usuarios. Permitir diferentes niveles de acceso al sistema.

Método Ágil Scrum
A esta altura ya se cuenta con una noción general de lo que el software

debe realizar, por lo tanto resta conocer realmente cual es la situación
actual del cliente y de sus propiedades.
4.1.4. Situación actual

A continuación se describe la situación actual ante la cual se encuentra el
cliente, es decir, la forma en la que se manejan sus propiedades rurales
hasta el momento.
En dichas propiedades, nunca se ha contado con un sistema informático,

todo queda asentado en papel. Se lleva un registro completo y detallado
del personal. Pero, aparte de ello, son muy pocas la tareas de campo que
se registran, quedando éstas prácticamente reducidas a la etapa de la
vendimia, donde se deja asentada una información mínima de lo que se
ha cosechado. Dicha registración, que se realiza manualmente, queda en
planillas y también en lo que es denominado el Libro de Campo.
Esta manera de operar imposibilita llevar un control de las actividades

realizadas durante todo el proceso de producción y manifiesta la
incapacidad de contar con información rápida y precisa en el momento
que se solicite.
Debido a la época del año en la que nos encontramos (Octubre de 2005),

muy cercanos a la próxima cosecha; el cliente nos ha pedido que el
software esté listo para Marzo de 2006. Por lo tanto contamos con 6

Método Ágil Scrum
meses (Octubre – Marzo) para entregar el software de Trazabilidad

terminado.
4.1.5. Estructura de División del Trabajo (EDT)

Al inicio no se cuenta con mucha información o entendimiento de todos
los requisitos del proyecto para desarrollar un EDT completo. Por lo tanto,
desarrollaremos un EDT de alto nivel que permita obtener una visión
general del alcance del proyecto.
Producto
Investigación
Trazabilidad
Datos generales
Datos
Entidades
Parte agrario
Comprobantes
Software de Remito de cosecha
Trazabilidad
Cosecha
Consultas Trazabilidad
Auditorias
Usuarios
Administrador
Acciones de auditoria

Método Ágil Scrum
4.1.6. Conformación del equipo humano

A la hora de elaborar un presupuesto y calcular la fecha de entrega del
producto final debemos conocer de cuanta gente se dispone para trabajar
en el proyecto.
El equipo de trabajo para llevar a cabo el Software de Trazabilidad estará

conformado solamente por dos personas que cumplen los diferentes
roles. Uno de los miembros del equipo (quien les escribe) hará las veces
de programador y Scrum Master. El otro miembro del equipo efectuará los
roles de Product Owner, Cliente y Usuario final del sistema.
Por lo tanto, hay a una sola persona disponible para trabajar en el

desarrollo del software. El tiempo que se dedicará al mismo es una
jornada de medio día, 20 horas semanales aproximadamente.
4.1.7. Estimación del plazo de entrega y precio

En base al EDT se arma una tabla para obtener una primera estimación
general del proyecto, y poder así determinar su duración y precio. Como
podemos observar en la primera columna se listan las principales
actividades del proyecto y se establecen para cada una de ellas su
esfuerzo expresado en horas que demanda aproximadamente realizar
cada actividad.

Método Ágil Scrum
Actividades Cantidad Esfuerzo (hs) Esfuerzo (hs)

Unitario Subtotal
Planificación 6 4 24
Investigación Producto 1 32 32
Investigación Trazabilidad 1 32 32
ABM de Datos generales 18 8 144
ABM de Entidades 5 12 60
Comprobante Parte Agrario 2 12 24
Comprob. Remito de Cosecha 2 12 24
Consulta de Cosecha 2 16 32
Consulta de Trazabilidad 2 16 32
Consulta de Auditoria 1 20 20
Implementación 5 8 40
Total (horas) 464
Vale la pena aclarar que para estimar las actividades se tuvo en cuenta
que cada una de ellas pasa por las etapas de análisis, diseño,
construcción y prueba. Las etapas de planificación e implementación se
realizan a nivel de Sprint al inicio y al final respectivamente.
Bien, ya sabemos que el proyecto completo demandará una duración

estimada de 464 horas, 64 para la etapa de investigación y 400 para el
desarrollo del software. Ahora falta conocer cual será nuestro costo de
desarrollo por hora y así, poder calcular el precio que se pasará en el
presupuesto.

Método Ágil Scrum
Algunas consideraciones a tener en cuenta son que el software será

desarrollado en forma particular, por lo tanto no se incurrirán en gastos
del tipo alquiler de oficina, impuestos, traslados diarios, etc.
El costo de desarrollo por hora se calcula en base a:
§ Consumo eléctrico por hora: $0,038

§ Consumo de Internet por hora: $0,153
§ Desgaste del equipo: $0,211
Llegamos a la conclusión de que nuestro costo por hora de desarrollo es

de $0,40; lo que al mes equivale a $32,00 (con base en 80 hs
mensuales).
Otro gasto que debe tenerse en cuenta es el traslado cada vez que se
visiten las propiedades rurales, ubicadas aproximadamente a 70 km de la
Ciudad de Mendoza. Se supone que durante los 6 meses de duración del
proyecto se realizarán 8 viajes. Y que el costo de cada uno de ellos será
de $53,00. En el cálculo te tuvo en cuenta, además del combustible,
desgaste del vehículo, seguro, etc.
Podemos decir entonces que la suma de los gastos durante los 6 meses
de duración del proyecto ascenderá a $456,00 aproximadamente.

Método Ágil Scrum
4.1.8. Gestión de riesgo

Todos los proyectos, sin excepción, tienen implícito algún tipo de riesgo. Y
éste no tiene relación alguna con el tamaño del proyecto. La
administración del riesgo es necesaria y consiste en analizarlos y
controlarlos de manera efectiva. Para ello, se identifican los riesgos
potenciales, se valora su probabilidad de ocurrencia y su impacto y se
establece una prioridad según su importancia.
Los criterios de puntuación de riesgos que se han definido para la

probabilidad e impacto son los siguientes: Muy bajo (1); Bajo (2); Medio
(3); Alto (4); Muy alto (5).
Identificación. Análisis cualitativo y cuantitativo del riesgo

Riesgo Probabilidad Impacto Puntaje Prioridad
Cliente no comprometido Media Alto 12 2º
Insatisfacción del cliente Baja Muy Alto 10 3º
Falta de comunicación (cliente) Media Alto 12 2º
Estimación del tamaño baja Media Alto 12 2º
Cambio en el alcance Alta Media 12 2º
Fecha de entrega ajustada Muy alta Media 15 1º
Falta de experiencia técnica y de Alta Baja 8 4º
proyectos
Se ha definido la siguiente política para la selección de estrategias:

Puntaje del riesgo Estrategia
15 - 25 Evitar
6 - 14 Reducir
3-5 Aceptar activamente
1-2 Aceptar pasivamente
Una vez que los riesgos han sido identificados, calculados y priorizados,
se concibe un plan de respuesta para dichos riesgos.

Método Ágil Scrum
Plan de respuesta al riesgo

Riesgo Estrategia Acción
Fecha de entrega ajustada Evitar Renegociar alcance
Firmar los acuerdos de reuniones,
planificación y aceptación de
requerimientos. Fijar un
Cliente no comprometido Reducir
responsable del proyecto por parte
del cliente. Fijar un cronograma de
reuniones.
Fijar un responsable del proyecto
Falta de comunicación con el
Reducir por parte del cliente. Fijar un
cliente
cronograma de reuniones.
Hacer re-estimar el proyecto a un
Estimación del tamaño baja Reducir
colega.
Especificación detallada y firmada
Cambio en el alcance Reducir
por el cliente.
Aumentar la comunicación.
Insatisfacción del cliente Reducir
Desarrollar la relación.
Tomar capacitaciones sobre la
Falta de experiencia técnica y de administración de proyectos.
Reducir
proyectos Consultar a profesionales del
medio.
Este será nuestro plan y las acciones que deberemos tomar para atenuar
los riesgos identificados.
4.1.9. Propuesta comercial

Con toda la información recaudada y analizada hasta el momento se
elabora la propuesta comercial que se entrega a nuestro posible futuro
cliente. La misma se presenta en el Anexo A de esta obra. En resumen, el
presupuesto arrojó los siguientes valores:
§ Precio por hora: $25,00.-

§ Precio total: $11.600,00.-

Método Ágil Scrum
4.2. HERRAMIENTAS EXISTENTES EN EL MERCADO

En el presente apartado se exponen las características más importantes
de algunas de las herramientas que actualmente se encuentran en el
mercado, para ofrecerlas también como una alternativa.
Software: KontrolFrux - Empresa: Arkios (Argentina)

• Captura en tiempo real. Con colectoras de datos portátiles se registran
todos los movimientos de mercadería en la planta.
• Brinda información en tiempo real sobre producción, recursos,

controles de calidad, y analiza la integración del negocio desde las
unidades productivas hasta la llegada a destino del producto.
• Mediante la utilización de códigos de barra y lectores láser, se logra

tener la trazabilidad por unidad productiva.
• Parametrizable para lograr la integración con otros sistemas, tales

como los ERP, u otros desarrollos específicos de la empresa.
• Consulta en línea.
• Precio: $5.000 por cada lugar físico donde se instale el sistema.
Software: e-FLEXWARE Bodegas - Empresa: BEJERMAN (Argentina)

• Administra el trabajo realizado en la viña identificando y asociando los
elementos que intervienen en cada tarea.
• Efectúa un seguimiento estricto de la maduración de la uva.

Método Ágil Scrum
• Permite efectuar comparaciones entre diferentes años.
• Refleja los ingresos a la Bodega indicando para caja viaje de uva su

procedencia.
• El módulo de Producción es uno más que se puede integrar al

Sistema e-Flexware ERP, es decir no es un módulo que pueda
venderse en forma independiente.
• Para un Sistema de gestión monousuario, hay que pensar en una idea

de inversión de aproximadamente $10.000.
Software: Packing - Empresa: COMPUAGRO (Chile)

• Software desarrollado para el control de producción, en línea (tiempo
real), donde la información es minuto a minuto y detallada.
• Control total de Trazabilidad (Caja, Pallet, Bins).
• Control de inventarios de materiales e integración con Agro2000 para

el pago de remuneraciones de acuerdo a la producción del día.
• Herramienta que le permite programar sus embarques, controlando el

cumplimiento del instructivo (el numero de pallet especifico).
• Emite los informes necesarios para las inspecciones SAG y otros.
• Etiquetado de cajas con la información que requiera.
• Cierre de proceso por productor o viñedo.

Método Ágil Scrum
• Precio: $4.500 por cada lugar físico donde se instale el sistema.
Hay que tener en cuenta que a todos los sistemas que hagan captura en
tiempo real, al importe del software hay que sumarle la inversión en la
compra del equipamiento, colectores de datos, etc. para poder llevarla a
cabo.
Luego de haberse realizado un análisis sobre dichas herramientas, se

llega a la conclusión de que todas ellas están orientadas a satisfacer las
necesidades de grandes empresas. Pero la realidad es que existen más
empresas pequeñas que grandes, y las soluciones hasta ahora
presentadas están dirigidas a la parte superior de la pirámide.
Una vez comparadas estas alternativas con nuestro presupuesto, el

cliente decide aceptar la propuesta comercial por las siguientes razones:
ü Desea tener su propio software, elaborado a medida para él.

Considera que las alternativas existentes no se adaptan a lo que
necesita.
ü Quiere tener un software sencillo y fácil de manejar (solución

intermedia).
ü No quiere correr el riesgo de que se conozcan sus datos.

Método Ágil Scrum
4.3. COMENZANDO CON SCRUM

A esta altura nos encontramos en condiciones de comenzar con el
desarrollo del proyecto utilizando Scrum.
El primer paso es comenzar a armar el Backlog de Producto. Inicialmente

colocamos en él los requerimientos de la etapa de investigación, que será
la primera que llevaremos a cabo; luego colocamos los requerimientos
que fueron identificados a partir de los casos de uso en la planificación
inicial del proyecto (que forma parte del análisis) y que luego fueron
priorizados por el cliente.
Como se observa en el siguiente gráfico (leer de abajo hacia arriba), el

Backlog contiene inicialmente todos los requerimientos definidos hasta el
momento estimados en horas de esfuerzo.

Método Ágil Scrum
Backlog del producto
Si bien toda la gestión del proyecto se lleva a cabo con ScrumWorks,

tanto el Backlog de Producto como los Backlogs de Sprints son
dinámicos. Los requerimientos colocados en el Backlog de Producto se
van pasando a los Backlogs de Sprints y las tareas detalladas en éstos se

Método Ágil Scrum
re-estiman diariamente. Por lo tanto, se irán presentando de esta manera

las variaciones del Backlog de Producto y de los Backlogs de Sprints.
4.3.1. Primer Sprint

Planificación
Objetivo: El objetivo del primer Sprint es realizar la investigación sobre la
necesidad y la importancia de la trazabilidad en la producción agraria,
conocer el Reglamento que la define y también el producto sobre el que
se aplicará, más específicamente la producción de uva.
Alcance: El alcance abarca el módulo de Investigación previo al

desarrollo del software.
Como se puede observar en el siguiente gráfico se presenta el primer

Sprint con sus tareas definidas y estimadas en horas, vale aclarar que es
la estimación inicial y que este es el único de tres semanas; los Sprints
restantes serán de 4 semanas.
Como desarrollo de este primer Sprint se presenta el Anexo B. En el cual

se detalla el informe realizado que es el primer entregable del cliente.

Método Ágil Scrum
Backlog de Sprint
Burndown chart

Método Ágil Scrum
En la gráfica, que es el Burndown chart del primer Sprint, puede

observarse cómo se han ido reestimando diariamente las tareas. Entre los
días 14 y 24 de Octubre la línea se hace menos pronunciada, eso denota
un problema o un impedimento que está causando un leve retraso en el
Sprint. En este caso, el motivo de la demora fue tener que buscar y leer
mucha información, que en definitiva, hacían muy lento el avance de la
investigación. Para el día 25 se llevaban 4 días de atraso, por lo tanto, se
optó por trabajar el último fin de semana del Sprint para poder cumplir con
el objetivo del mismo.
Se ha mostrado la reestimación de las tareas aprovechando que es el

Sprint más corto de todos, para los próximos se presentará solamente la
gráfica.
A continuación volvemos a presentar el Backlog de Producto. En el cual

podemos observar que los requerimientos de la etapa de investigación ya
no están y solamente se encuentran los restantes, los del sistema
propiamente dicho. Se recuerda leer de abajo hacia arriba el Backlog de
Producto.
Como los requerimientos ya están priorizados, sólo falta definir cuáles de

ellos conformarán el segundo Sprint.

Método Ágil Scrum
Backlog de Producto

Método Ágil Scrum
4.3.2. Segundo Sprint

Planificación
Objetivo: Comenzar con el desarrollo de los primeros requerimientos que
se encuentran actualmente en el Backlog para obtener la primera versión
funcional del software.
Alcance: El alcance del segundo Sprint abarca parte del módulo de

Datos, se seleccionan las primeras 8 aplicaciones para carga de datos.
Backlog de Sprint
Como puede observarse en el siguiente gráfico se presenta el segundo
Sprint con sus tareas definidas y sus estimaciones iniciales en horas.
Debido a que todos los requerimientos tienen definidas las mismas tareas
(excepto Planificación e Implementación) y a los efectos de que el gráfico
no sea tan extenso se ha desplegado solamente el primer requerimiento.
Las tareas definidas para cada requerimiento transitan por todas las
etapas especificadas en nuestro proceso de desarrollo:
Describir el caso de uso à Análisis

Modelado de datos à Análisis y Diseño
Crear el formulario à Diseño y Construcción
Compilar y Probar à Construcción y Prueba

Método Ágil Scrum
Para ver el análisis y el diseño del sistema se invita a consultar los

Anexos C y D respectivamente, que si bien se fueron construyendo de
forma iterativa, allí se encuentran completos.
Burndown chart

Método Ágil Scrum
En esta gráfica vemos el ritmo al que fue avanzando el segundo Sprint. Al

haberse subestimado algunas tareas pero sobrestimado otras, se
compensaron las horas y se cumplió en tiempo y forma al final del Sprint.
A continuación volvemos a presentar el Backlog de Producto.
Backlog de Producto

Método Ágil Scrum
4.3.3. Tercer Sprint

Planificación
Objetivo: Continuar con el desarrollo de los requerimientos para obtener
la segunda versión funcional del software.
Alcance: El alcance del tercer Sprint abarca parte del módulo de Datos,
se seleccionan 7 aplicaciones más para carga de datos.
Backlog de Sprint

Método Ágil Scrum
Burndown chart
En este Sprint puede observarse que al haber aprendido del Sprint

anterior y tener éste el mismo tipo de requerimientos se logró cumplir con
el objetivo del Sprint sin dificultades.

Método Ágil Scrum
4.3.4. Cuarto Sprint

Planificación
la tercera versión funcional del software.
Alcance: El alcance del cuarto Sprint abarca parte del módulo de Datos,
se seleccionan 8 aplicaciones más para carga de datos.
Backlog de Sprint

Método Ágil Scrum
Burndown chart
Como podemos ver, el ritmo de avance al comienzo de este Sprint se

presenta constante pero hacia la finalización del mismo la gráfica se hace
más irregular lo que significa que se presentaron inconvenientes en una
de las aplicaciones, de todas maneras se llevaron a cabo todas las tareas
planificadas.
En esta oportunidad luego de la implementación surgió un reclamo por un

error en la aplicación Agroquímicos, por lo tanto se incorporó como un
nuevo requerimiento al Backlog de Producto para su corrección. Será el
primer requisito con el que se inicie el siguiente Sprint.

Método Ágil Scrum
Backlog de Producto
4.3.5. Quinto Sprint

Planificación
la cuarta versión funcional del software.
Alcance: El alcance del quinto Sprint abarca, en primer lugar, la

corrección del error, la última aplicación del módulo Datos y el módulo
Comprobantes, son 6 aplicaciones.

Método Ágil Scrum
Backlog de Sprint
Burndown chart

Método Ágil Scrum
En este Sprint, al revés que en el anterior, el avance se hizo muy lento al

comienzo, debido a que llevó más tiempo de lo previsto corregir el error
de la aplicación Agroquímicos. Otro motivo de demora fue que el cliente,
debido al comienzo de la cosecha, no estaba disponible para despejar
dudas y realizar consultas; situación que se regularizó hacia el fin del
Sprint.
De todas maneras, una de las tareas Conocer la Trazabilidad por Tareas

no alcanzó a completarse, por lo tanto volvió como requerimiento al
Backlog. El cual se vuelve a presentar por última vez y los requerimientos
que figuran en él son los que integran el sexto Sprint.
Puede observarse que la suma del esfuerzo da 100 horas, lo que significa
que estamos retrasados aproximadamente 20 horas (1 semana). Se
decide por tal motivo renegociar con el cliente la fecha de entrega y se fija
como nueva fecha el día 7 de abril. Nuestro último Sprint será de 5
semanas para lograr cumplir con el objetivo.

Método Ágil Scrum
4.3.6. Sexto Sprint

Planificación
la quinta y última versión funcional del software.
Alcance: El alcance del sexto Sprint abarca, en primer lugar, completar la

tarea pendiente del Sprint anterior, y realizar el módulo de Consultas, son
5 aplicaciones.
Backlog de Sprint

Método Ágil Scrum
Burndown chart
El último Sprint, como lo muestra la gráfica, sufrió de varias subas y bajas

que se lograron ir compensando para poder alcanzar el objetivo. Una vez
implementada la última versión funcional que completa el producto,
podemos reflexionar acerca del resultado de nuestro proyecto.
El proyecto que en sus inicios fue estimado en 464 horas consumió 488
horas, por lo tanto, la entrega al cliente del último Release se hizo una
semana después de lo presupuestado al comienzo del proyecto.
Pensamos que esta demora puede considerarse aceptable.
La experiencia de haber utilizado Scrum como método para gestionar y

llevar a cabo el seguimiento del proyecto a resultado muy grata. A través
de él se ha logrado controlar la velocidad de avance del proyecto de
forma eficaz. Esto permitió en el último Sprint detectar prontamente el
retraso y comunicarlo al cliente de inmediato para pactar una nueva fecha
de entrega. El hecho de estar organizado y saber lo que realmente
quedaba por delante causó un efecto positivo en el cliente, quien mientras
tanto tenía sobre que trabajar gracias a las entregas mensuales que se le
fueron realizando.

ANEXOS
Método Ágil Scrum
ANEXO A
PROPUESTA COMERCIAL
Mendoza, 3 de Octubre de 2005.-
Sr. Xxx
Presente
A través de la presente me dirijo a Ud. con el fin de hacerle

llegar el presupuesto elaborado a partir de la planificación inicial del
sistema.
Producto: Software de Trazabilidad
Objetivo del sistema

El objetivo es desarrollar una solución específica para pequeños y
medianos productores que permita registrar y controlar todas las
actividades que se efectúan en la propiedad rural.
Un sistema que tenga como premisa fundamental una precisa

identificación de la producción desde el cultivo, los procesos asociados,
la cosecha, así como también el transporte hasta su destino final, la
bodega.
Todo ello resuelto en un entorno gráfico y amigable que permita a quienes

lo operen manejarse con absoluta solvencia desde el primer día.
Alcance del sistema

El alcance del sistema abarcará: desde la preparación de la tierra para el
cultivo hasta el transporte del producto agrario en camiones después de la
vendimia. El desarrollo del sistema comprenderá las siguientes
aplicaciones:
ü Administración de propiedades rurales. Datos sobre las mismas,

administración de cuarteles y titulares por propiedad.

Método Ágil Scrum
ü Administración de titulares. Ver propiedades por titular.
ü Administración de variedades de uva, tipos de conducción del

viñedo y enfermedades de la vid.
ü Administración de personal y sus capacitaciones realizadas.
ü Administración de proveedores.
ü Administración de agroquímicos y métodos de aplicación de

agroquímicos.
ü Administrar maquinarias y camiones con sus respectivas revisiones

técnicas.
ü Administrar compañías de seguro y pólizas de seguro.
ü Administrar tipos de tareas agrarias.
ü Administrar bodegas (clientes) y delegaciones del INV.
ü Administrar usuarios para darles diferentes niveles de acceso al

sistema.
ü Registro de la entrada de las materias primas. Una vez grabada

una nota de entrada no podrá modificarse y solamente el usuario
administrador podrá eliminarla.
ü Registro de diario de tareas realizadas. Una vez grabado un parte

de tareas no podrá modificarse y solamente el usuario
administrador podrá eliminarlo.
ü Registro de la cosecha. Una vez grabado un remito de cosecha no

podrá modificarse y solamente el usuario administrador podrá
eliminarlo.
ü Consulta de cosecha.
ü Consulta de trazabilidad.
ü Consulta de auditoria.
ü Informes de cosecha, de trazabilidad y de auditoria.

Método Ágil Scrum
Límite del sistema

El software abarcará solamente la etapa de producción primaria dentro de
la cadena agroalimentaria, su límite geográfico será la propiedad rural.
Consideraciones técnicas
El desarrollo se llevará acabo con el lenguaje de programación Clarion 5.5
utilizando el motor de base se datos Topspeed. Si bien son herramientas
para operar en un entorno Windows, haciendo los ajustes necesarios,
también se puede correr en Linux.
Requisitos de hardware
Estos son los requisitos mínimos de hardware que deberá tener cada
equipo sobre el que se corra el sistema.
• Intel Pentium lll o AMD K7 (Recomendado Pentium lV o Athlon)

• 128 MB Memoria RAM (Recomendado 256MB de RAM)
• 4 GB de Disco Rígido (Recomendado 8GB de Disco Rígido)
• Resolución de pantalla 800 x 600 (Recomendado 1024 x 768)
Plazo de entrega
A partir de la aceptación de la presente propuesta se realizará una
entrega mensual por cada uno de los 6 meses de duración del proyecto.
Aclaración: las fechas o los plazos pueden variar en caso de que surjan
modificaciones imprevistas durante el desarrollo del sistema.
Remuneración y Forma de pago

Por el desarrollo e implementación del sistema en tres (3) puestos de
trabajo se facturará el total de pesos once mil seiscientos ($11.600,00).
Debido a que el software se irá implementando parcialmente, dicho monto

se cobrará en 6 cuotas iguales de pesos mil novecientos treinta y tres
con treinta y tres centavos ($1.933,33) cada una.
Por estar los montos de la presente propuesta expresados en pesos su

validez es de 14 días corridos a partir de la fecha de la misma.
Sin otro particular, y a la espera de una respuesta, saluda muy

atentamente.
María Laura Citón

Método Ágil Scrum
ANEXO B
INVESTIGACIÓN
INTRODUCCIÓN
La presente investigación se desarrolla al comienzo del proyecto con el
objetivo de conocer el Reglamento que define la trazabilidad y también el
producto sobre el que se aplicará.
La investigación se divide en dos partes, en la primera de ellas se

describe la situación de la producción de uva y vino en nuestro país, y se
realiza un breve análisis sobre las exportaciones a los países que
actualmente exigen la trazabilidad en los productos que importan, entre
ellos, el vino Argentino.
En la segunda parte se detalla la normativa que define la trazabilidad y

sus características más importantes entre las que se encuentran: tipos de
trazabilidad, ventajas de tenerla, fases y alternativas para aplicarla.

Método Ágil Scrum
PRODUCCIÓN DE UVA Y VINO EN ARGENTINA
PRODUCCIÓN DE UVA
La cadena productiva vitivinícola está constituida por un conjunto de
eslabones o fases a partir de la producción de uva. Las uvas son el fruto
de la vid y suelen tener distintos destinos.
El destino más importante en el ámbito nacional e internacional se

canaliza hacia la producción de vinos y mostos. En la Argentina hay que
distinguir entre variedades para vinificar comunes y de alta calidad
enológica.
Otro destino de la uva es el deshidratado para la elaboración de pasas.

En Argentina hay cultivadas variedades de vid específicas para este
destino. Por último, hay un grupo de variedades que han sido
seleccionadas para ser consumidas en fresco, aunque
circunstancialmente pueden ser destinadas a la vinificación o a pasas.
Caracterización de las áreas implantadas con vid

Argentina se posiciona como el principal corazón vitivinícola de América
del Sur. La mayoría de los cultivos se encuentran ubicados en las
provincias de Mendoza y San Juan, que integran la región de Cuyo, la
zona vitivinícola más importante del país.

Método Ágil Scrum
Ubicación: Centro Oeste de la Argentina, al pie de la Cordillera de Los

Andes, entre los 30° a 50º de latitud sur y a una altitud promedio de 500 m
sobre el nivel del mar, en donde se presentan las mejores condiciones de
clima y suelo.
Superficie implantada con vid en Argentina

La provincia de Mendoza es la principal productora de vid, con una
producción que representa el 70% del total nacional. Le sigue la provincia
de San Juan con una porcentaje menor, pero igualmente destacable,
llegando al 22% del total producido. Ambas provincias producen más del
90% del total nacional. Le siguen, La Rioja (4%), Río Negro (1,33%),
Catamarca (1,11%) y Salta (0.91%).
Superficie plantada - Año 2004

Distribución por provincias
Mendoza
San Juan
3,82% 4,07%
La Rioja
Resto
22,72%
69,39%
Fuente INV
Fuente INV
La transformación que ha sufrido el sector vitivinícola abarca todas las

etapas de la cadena productiva. En el plano de la producción primaria se
asiste a una contracción significativa de la superficie implantada, cantidad
de viñedos y producción de uva. Entre 1990 y 2004, la superficie

Método Ágil Scrum
implantada de uva se redujo de 320 mil hectáreas a 210 mil hectáreas y la

cantidad de viñedos pasó de 52.418 a 26.093.
Esta reducción se ve acompañada por una renovación de las

plantaciones, con un acentuado desplazamiento de la uva criolla por
distintas variedades de uvas finas, de superior valor enológico. Se
reconvirtió parte de la superficie implantada con avanzados sistemas de
conducción, tecnologías de riego y de protección y manejo de los cultivos,
además de capacitación de recursos humanos. El conjunto de las
modificaciones en la producción primaria apuntaló un incremento de la
productividad que se ha profundizado desde mediados de la última
década.
PRODUCCIÓN DE VINO
La elaboración de vinos demanda casi la totalidad de la materia prima,
alcanzando casi el 97% en el año 2004.
Producción de uva - Año 2004

Total país - Quintales métricos en %
Consumo en fresco
1,84% 1,63% Pasas
Vinificación
96,53%
Fuente INV

Método Ágil Scrum
Argentina en el mundo
Uvas
ü Superficie cultivada de vid: 210.530 hectáreas (26.093 viñedos) - 10º
en el mundo.
ü Producción de uvas: 8º productor mundial.
ü Exportador de pasas de uva: 10º exportador mundial.
Vinos
ü Elaboración de vinos: 5º productor mundial.
ü Consumo de vinos per cápita: (33 litros anuales) - 6° en el mundo.
ü Exportación de vino: 11º exportador mundial.
ü Exportación de mosto: 1° exportador mundial.
Argentina ocupa una posición destacada entre los países de América del
Sur, aún frente a uno de sus competidores en el mercado externo, Chile.
PAIS Superficie Producción Elaboración Consumo

con Vid de Uva de Vino de Vino
ARGENTINA 52% 48% 61% 69%
CHILE 32% 32% 21% 10%
BRASIL 14% 17% 13% 14%
URUGUAY 2% 3% 5% 6%
PARAGUAY 0% 0% 0% 1%
Fuente: SAGPyA.
Variedades de alta calidad enológica

Como se mencionó anteriormente, la producción de uva fina en las
últimas dos décadas presenta una tendencia creciente. Esta tendencia

Método Ágil Scrum
está motivada por una mayor demanda de uvas de alta calidad enológica
por parte de la industria vitivinícola, con motivo del aumento del consumo
de vinos finos y la disminución de vinos comunes tanto en el mercado
interno como en el externo.
Las variedades para elaborar vinos finos representan aproximadamente el

25% de la superficie con variedades de vinificar. Debido a las excelentes
condiciones agro-ecológicas que presenta Argentina, es posible producir
una amplia gama de estas variedades.
Identificación de la demanda
En el plano internacional se asiste, desde hace ya varios años, a un
proceso de paulatina y persistente contracción en el consumo de vinos
comunes, caída que tiende a constituirse en un rasgo permanente del
sector. Pese a ello, paralelamente se ha verificado una expansión
acelerada en el crecimiento del consumo de vinos finos.
Los países que más participan en el consumo de vino son Luxemburgo

(63 litros al año per capita), Italia (57 litros), Francia (55 litros) y Portugal
(43 litros). Nuestro país 33 litros y ocupando el sexto lugar en el mercado
mundial y el primero en Sudamérica.
En general todos los países con tradición vitivinícola han experimentado

una leve, pero constante baja en el consumo a partir del comienzo de la
década de los noventa y continúa la tendencia, pese a que la calidad de

Método Ágil Scrum
los vinos mejora notoriamente, sin embargo la caída de los valores está
concentrada en los consumidores jóvenes del mundo.
Consumo anual de v inos - Año 2004
Luxemburgo
Italia
Francia
Portugal
España
Argentina
Alemania
Australia
Paises Bajos
Reino Unido
Litros per
0 10 20 30 40 50 60 70 capita
Análisis estadístico de destino

Los principales países importadores de vinos, a nivel mundial, son
Alemania (20,96% del total de las importaciones internacionales) y Reino
Unido (16,32%). Por el contrario, los principales exportadores son Francia
(21% del total de las exportaciones internacionales), Italia (18%) y España
(17%), ubicándose Argentina en el puesto 11 del ranking (exporta el 4%
de la totalidad de las ventas mundiales).
Para establecer la teoría sobre la necesidad de la trazabilidad en la

vitivinicultura Argentina se ha realizado un análisis sobre las
exportaciones, llegando a la conclusión de que los países destinatarios de
nuestros vinos exigen el cumplimiento de la trazabilidad de los mismos.

Método Ágil Scrum
En los últimos 10 años, Argentina experimentó un crecimiento en las

exportaciones de vinos. Tanto si se toman en cuenta los hectolitros
exportados como si se hace lo propio con las divisas pagadas por dichos
hectolitros. Argentina pasó de exportar 1.260.000 hectolitros en 1995 a
1.995.000 en el 2004 en todas sus variedades. Si se toman en cuenta los
valores monetarios, Argentina pasó de exportar U$S 49.000.000 en 1995
a U$S 190.000.000 en el 2004.
Exportaciones totales de vino (1995 - 2004)
2.500.000 Hectolitros $ 200.000

Miles de dólares
2.000.000
$ 150.000
1.500.000
$ 100.000
1.000.000
$ 50.000
500.000
0 $0
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004
Exportaciones Argentinas de Vinos - Año 2004

Principales 12 paises
Hectolitros
250.000 50.000
Miles de dólares
200.000 40.000
150.000 30.000
100.000 20.000
50.000 10.000
0 0
no ay
ay
il
do
ia
am n
Fr a
a
U
Al jos
ca
as
i
ad
ci
po
U
an
us
u
gu
ar
ni
Ba
an
EE
Br
g
an
Ja
R
U
em
ra
ru
es
C
Pa
U
in
is
ei
D
Pa
R

Método Ágil Scrum
Exportaciones Argentinas de Vinos - Año 2004

Paises de la UE
250.000 Hectolitros 35.000

200.000 Miles de dólares 30.000
25.000
150.000 20.000
100.000 15.000
10.000
50.000 5.000
0 0
in ido
Fr ia
nl a
a
ia
Bé a
Po a
a
Es ia
Al jos
es ca
ña
c
ic
ni
d
lic nci
di
ec
l
an
Ita
he
r
an
pa
lg
Ba
n
an
lo
Pa ma
Su
a
U
em
Irl
a
no
Fi
is
ei
úb
R
ep
R
Dirección Nacional de Alimentación, en base a datos del INV.
Tras analizar los datos expuestos podemos deducir que la trazabilidad es

más que importante, ya que el 32,57% de nuestras exportaciones de
vinos son a países de la Unión Europea (UE), dónde la trazabilidad es
obligatoria. Este porcentaje representa U$S 87.754.860, lo que es una
suma más que importante en el área de las exportaciones.
No podemos dejar de mencionar que a EEUU se exporta el 15.23% que

representa U$S 45.266.000.
Podemos decir, en base a estos números, que a partir de Mayo del 2005
una de cada dos botellas de vinos finos exportables a los mercados ya
conocidos por los productores de vinos argentinos deberá tener en orden
su trazabilidad y documentación que respalde sus actividades. De esta
manera, Argentina que ya tiene una fuerte presencia en mercados de
consumo exigente, al contar con la trazabilidad de sus vinos y mostos

Método Ágil Scrum
podrá expandir tanto su oferta de productos como los mercados de

destinos. De allí la importancia de cumplir con este requerimiento de los
mercados.
En esta primera parte de la investigación llegamos a la conclusión que la

eficiencia en los procesos productivos hacen indispensable conocer la
trazabilidad de toda la producción para seguir siendo competitivo. Por
consiguiente, en la producción moderna no se concibe un producto sin
sus datos de trazabilidad. Es por ello que dedicaremos a este tema el
próximo apartado.
TRAZABILIDAD
CONCEPTO GENERAL
Según la definición presente en la Norma ISO 9000:2000, trazabilidad es
“la capacidad para seguir la historia, la aplicación o la localización de todo
aquello que está bajo consideración.”
Para un producto esta relacionada a:

• El origen de los materiales y sus partes.
• La historia del procesamiento.
• La distribución y la localización del producto después de su entrega.

Método Ágil Scrum
REGLAMENTO (CE) N° 178/2002

Esta normativa, que entró en vigencia en Febrero de 2002, pero que es
aplicable a partir del 1 de Mayo de 2005, establece los principios y los
requisitos generales de la legislación alimentaria, crea la Autoridad
Europea de Seguridad Alimentaria y fija los procedimientos relativos a la
seguridad alimentaria.
En el presente apartado se abordarán las siguientes cuestiones:
§ Definición (artículo 3 inciso 15);

§ Trazabilidad (artículo 18);
Definición
El Reglamento 178/2002 del Parlamento Europeo y del Consejo, en su
artículo 3 inciso 15 presenta una definición más específica referida a
productos alimentarios, y expresa:
Trazabilidad es “la posibilidad de encontrar y seguir el rastro, a través de

todas las etapas de producción, transformación y distribución, de un
alimento, un pienso, un animal destinado a la producción de alimentos o
una sustancia destinados a ser incorporados en alimentos o piensos o
con probabilidad de serlo”.
En otras palabras podemos decir que la trazabilidad son aquellos

procedimientos preestablecidos y autosuficientes que permiten conocer el
histórico, la ubicación y la trayectoria de un producto o lote de productos a

Método Ágil Scrum
lo largo de la cadena de suministros en un momento dado, a través de

herramientas determinadas.
Dicha trazabilidad consiste en asociar sistemáticamente un flujo de

información a un flujo físico de mercaderías de manera que se pueda
relacionar en un momento dado la información requerida relativa a los
lotes o grupos de productos determinados.
Artículo 18 – Trazabilidad
1. En todas las etapas de la producción, la transformación y la distribución
deberá asegurarse la trazabilidad de los alimentos, los piensos, los
animales destinados a la producción de alimentos y de cualquier otra
sustancia destinada a ser incorporada en un alimento o un pienso, o con
probabilidad de serlo.
2. Los explotadores de empresas alimentarias y de empresas de piensos

deberán poder identificar a cualquier persona que les haya suministrado
un alimento, un pienso, un animal destinado a la producción de alimentos,
o cualquier sustancia destinada a ser incorporada en un alimento o un
pienso, o con probabilidad de serlo.
Para tal fin, dichos explotadores pondrán en práctica sistemas y

procedimientos que permitan poner esta información a disposición de las
autoridades competentes si éstas así lo solicitan.
3. Los explotadores de empresas alimentarias y de empresas de piensos

deberán poner en práctica sistemas y procedimientos para identificar a las
empresas a las que hayan suministrado sus productos. Pondrán esta

Método Ágil Scrum
información a disposición de las autoridades competentes si éstas así lo

solicitan.
4. Los alimentos o los piensos comercializados o con probabilidad de

comercializarse en la Comunidad deberán estar adecuadamente
etiquetados o identificados para facilitar su trazabilidad mediante
documentación o información pertinentes, de acuerdo con los requisitos
pertinentes de disposiciones más específicas.
5. Podrán adoptarse disposiciones para la aplicación de lo dispuesto en el

presente artículo en relación con sectores específicos de acuerdo con el
procedimiento contemplado en el apartado 2 del artículo 58.
La trazabilidad persigue diferentes objetivos y entre los más importantes

se destacan la seguridad alimentaria, el comercio justo entre
explotadores, y la fiabilidad de la información facilitada a los
consumidores.
Lo que se pretende con la trazabilidad es garantizar que se puede

proceder a retiradas o recuperaciones específicas y precisas de
productos, que es posible facilitar a los consumidores y a los explotadores
de empresas alimentarias información apropiada, que las autoridades de
control pueden llevar a cabo determinaciones del riesgo y que puede
evitarse una mayor perturbación innecesaria del comercio.
El artículo 18 exige a los explotadores de empresas alimentarias que:

Método Ágil Scrum
á puedan identificar quién ha suministrado un producto y quién ha

sido su destinatario;
á pongan en práctica sistemas y procedimientos que permitan poner

esta información a disposición de las autoridades competentes si
éstas así lo solicitan.
Este requisito se basa en el planteamiento «un paso atrás y un paso

adelante», para los explotadores de empresas alimentarias, supone que:
á deberán poner en práctica un sistema que les permita identificar a

los proveedores y a los clientes inmediatos de sus productos;
á se establecerá un vínculo «proveedor-producto» (qué productos han
sido suministrados por qué proveedores);
á se establecerá un vínculo «cliente-producto» (qué productos han

sido suministrados a qué clientes); sin embargo, los explotadores de
empresas alimentarias no tienen que identificar a los clientes
inmediatos cuando éstos sean consumidores finales.
Usuario Usuario Usuario Usuario Usuario
La redacción del artículo 18 hace incidencia en el objetivo y el resultado

previstos sin prescribir la forma de alcanzar ese resultado.

Método Ágil Scrum
Sin embargo, la exigencia de mantener un sistema de Trazabilidad surge

de la siguiente necesidad: cuando se produce un reclamo por inocuidad o
un daño en la salud de un consumidor, el proveedor de un producto debe
poder identificar y retirar (Recall) del mercado todas las unidades que
podrían presentar el mismo problema.
TIPOS DE TRAZABILIDAD
Teniendo en cuenta las definiciones expuestas en el punto anterior, se
pueden describir tres ámbitos de trazabilidad existentes:
Trazabilidad hacia adelante o rastreabilidad: es la capacidad de seguir

el camino de un producto a través de la cadena de abastecimiento,
mientras éste se mueve entre las organizaciones. Los productos son
rastreados rutinariamente en busca de su obsolescencia, manejo de
inventario, propósitos logísticos y, conocer a partir de una materia prima el
producto final del que ha formado parte. Productor à Minorista.
Trazabilidad hacia atrás: es la capacidad de identificar el origen de una

unidad particular o de un lote de productos ubicados dentro de la cadena
de abastecimiento, de acuerdo a referencia de registros que tuvieron lugar
contracorriente en dicha cadena. Los productos se localizan con
propósitos tales como la anulación de los mismos, investigación de
reclamos, u obtener a partir de un producto intermedio o final la
información relevante asociada a un determinado producto hasta llegar al
origen de las materias primas. Minorista à Productor.

Método Ágil Scrum
Trazabilidad interna o de procesos: es la capacidad de trazar a lo largo

del proceso de producción. Por lo tanto, desde el punto de vista de una
organización, la trazabilidad del proceso permitirá vincular los productos
que entran en una empresa con los que salen.
VENTAJAS QUE APORTA LA TRAZABILIDAD

Un buen sistema de trazabilidad en la cadena alimentaria no sólo juega
un importante papel en la protección de los intereses del consumidor, sino
que, además, aporta grandes beneficios para las organizaciones.
ü Lograr un nivel elevado de protección de la vida y la salud de las

personas.
ü Cumplir con las normativas.
ü Obtener información de los proveedores.
ü Controlar la evolución de productos y procesos.
ü Establecer una ventaja competitiva.
ü Detectar, acotar y analizar problemas con gran celeridad.
ü Retirar selectivamente productos con alguna incidencia.
ü Minimizar costos de retiradas de productos.
TIPO DE INFORMACIÓN QUE DEBE REGISTRASE

El artículo 18 no especifica el tipo de información que deben registrar los
explotadores de empresas de alimento. Sin embargo, para cumplir su
objetivo, se considera necesario que se registre la información que se
detalla a continuación. Esta información puede clasificarse en dos
categorías según su grado de prioridad:

Método Ágil Scrum
La primera categoría de información incluye todos los datos que deberán

ponerse a disposición de las autoridades competentes en todos los casos:
§ Datos del proveedor y naturaleza de los productos que suministró.

§ Datos del cliente y naturaleza de los productos que se le
entregaron.
§ Fecha de la transacción / entrega.
La segunda categoría de información incluye otros datos cuyo registro se

recomienda encarecidamente:
§ Volumen o cantidad.
§ Número de lote.
§ Descripción detallada del producto (producto preenvasado o a
granel, variedad de fruta/verdura, producto crudo o transformado).
La información que vaya a registrarse se seleccionará atendiendo a la

actividad de la empresa (naturaleza y tamaño) y a las características del
sistema de trazabilidad.
FASES PARA LA IMPLANTACIÓN DEL SISTEMA

El Artículo 18 del Reglamento 178/2002 impone una obligación genérica
de trazabilidad en cada una de las etapas de la cadena agroalimentaria.
Sin embargo, es importante destacar que el Artículo 18 no impone
específicamente de qué forma, ni a través de qué medios, los operadores
económicos de empresas alimentarias deben conseguir este objetivo.

Método Ágil Scrum
Por ello, los operadores podrán elegir libremente entre una gran variedad
de sistemas y herramientas a su disposición, siempre que cumplan su
objetivo final. Se podrán utilizar desde procedimientos manuales sobre
papel hasta tecnologías con soportes informáticos, electrónicos, de radio
frecuencias etc. Los operadores pueden también elegir la forma de
identificar los productos y la forma de recoger y almacenar la información
citada.
A continuación, y a modo de orientación, se establecen unas pautas de

actuación que cada empresa deberá adaptar a sus circunstancias y
características. Las fases para la correcta implantación del sistema
pueden ser:
Estudiar los sistemas de archivos previos

En primer lugar, se deberá estudiar detenidamente los procedimientos de
archivos (su contenido y sistemática) que este utilizando la organización,
que generalmente son libros o planillas de registro, y evaluar si con ellos
se cumple el objetivo de trazabilidad.
En algunos casos, las empresas pueden encontrarse con que ya están

haciendo todo lo necesario para conseguir la trazabilidad. En otros, podría
ser necesario generar nuevos archivos o adaptar los procedimientos
existentes.
Es importante destacar que un sistema de trazabilidad no tiene porqué ser

complicado. El mejor sistema de trazabilidad para una organización es

Método Ágil Scrum
aquel que encaje con sus actividades de trabajo habituales y permita

registrar la información necesaria a la que luego se pueda acceder de
forma fácil y rápida. Estudiar detenidamente el sistema de trazabilidad de
la empresa permite sacar beneficio de la información que el sistema
genera.
Consultar con proveedores y clientes

Previamente a la implantación del sistema es recomendable:
▬ Consultar con proveedores y clientes.

▬ Pedir consejo a otras partes implicadas: otras empresas,
consultoras, auditores, autoridades de control.
▬ Solicitar sus registros a proveedores y clientes, ya que éstos han
de ser coherentes y acordes entre operadores.
▬ Informarse de si existen recomendaciones o guías voluntarias de
trazabilidad para empresas del sector.
Definir el ámbito de aplicación

El sistema de trazabilidad que se implante en cada empresa desde el
eslabón anterior hasta el eslabón posterior, debe ayudar a mantener la
trazabilidad en toda la cadena alimentaria. Dependiendo de la actividad
dentro de la cadena alimentaria, el sistema puede necesitar: trazabilidad
hacia atrás, interna o de proceso, y/o hacia adelante.
El Artículo 18 sólo impone al operador económico de la empresa

alimentaria la obligación legal de identificar a su proveedor inmediato y a
su cliente inmediato. Sin embargo, debe hacerse la siguiente

Método Ágil Scrum
consideración para que se cumplan los objetivos: en la mayoría de las

actividades desarrolladas por las empresas alimentarias, es necesario
vincular lo que entra con lo que sale o, lo que es lo mismo, disponer de
una trazabilidad interna de forma más o menos desarrollada.
A continuación se cita, a modo de ejemplo, el ámbito de aplicación de

trazabilidad para la producción primaria: requerirán un sistema de
trazabilidad basado en la trazabilidad hacia atrás (ej: recopilar información
sobre el vivero, productos fitosanitarios, biocidas, etc.), interna (ej.
información sobre las labores de cultivo realizadas, con especial
referencia a aquellas prácticas que puedan tener una repercusión sobre la
higiene y seguridad de los cultivos) y trazabilidad hacia adelante
(información del cliente al que se destina el producto agrario).
Definir criterios para la agrupación de productos

Para poder aplicar cualquier sistema de trazabilidad, cada empresa debe
agrupar de alguna forma el conjunto de unidades que produce, fabrica,
envasa o, en términos amplios, maneja y, además, la agrupación debe ser
identificada.
El Real Decreto 1808/91 define lote como: “un conjunto de unidades de

venta de un producto alimenticio producido, fabricado o envasado en
circunstancias prácticamente idénticas”.

Método Ágil Scrum
La composición del lote es un punto crítico en este proceso. Determina la

exactitud de todo sistema de trazabilidad. Cuanto más homogéneos son
los lotes, más exacto será el sistema de trazabilidad.
La empresa del sector primario puede configurar sus agrupaciones según

diferentes criterios, entre los que se pueden encontrar uno o varios de los
siguientes:
§ Periodo de tiempo: horario, diario, semanal

§ Línea de producción
§ Parcela o cuartel
§ Lugar y fecha de captura
En relación con la identificación, existe una gran variedad de sistemas

disponibles, desde etiquetas escritas a mano, hasta códigos de barras y
chip de radio frecuencia. La utilización de identificadores estandarizados,
tales como los códigos de barras EAN para materiales etiquetados que se
comercializan entre empresas, facilita la circulación de los datos a través
de la cadena alimentaria.
Ningún sistema de identificación es adecuado en todas y cada una de las

circunstancias. Y, hasta dentro de una misma empresa puede ser
conveniente utilizar diferentes tipos de identificación.

Método Ágil Scrum
Establecer registros y documentación necesaria

Es conveniente que la documentación del sistema de trazabilidad
implantado en una empresa incluya:
§ Ámbito de aplicación del sistema

§ Descripción y características del mismo
§ Registros de las operaciones efectuadas
§ Procedimiento de revisión y actualización del sistema
En el apartado 3.5 se especificó la información que conviene registrar y

que se señala a continuación a modo de recordatorio.
Trazabilidad hacia atrás:

De quién se reciben los productos / Qué se ha recibido exactamente /
Cuándo / Qué se hizo con los productos cuando se recibieron
Trazabilidad de proceso (interna):

Cuando los productos se dividen, cambian o mezclan / Qué es lo que se
crea / A partir de qué se crea / Cómo se crea / Cuándo / Identificación del
producto final
Trazabilidad hacia adelante:

A quién se entrega / Qué se ha vendido exactamente / Cuándo
Las acciones o la información del producto útil para la trazabilidad pueden

registrarse:

Método Ágil Scrum
§ En hojas de datos sobre papel que acompañan a cada agrupación

a lo largo de todos los procesos con carácter interno dentro de una
misma empresa.
§ Mediante las Tecnologías de Información, que tienen gran

capacidad de archivo en menor espacio y que, además, pueden
incluir: recogida automática de datos y equipamiento, tal como
impresoras de etiquetas y lectores de códigos de barras, que llevan
consigo otras eficiencias operacionales.
Plazo de conservación de los registros

El artículo 18 no prevé un período mínimo de tiempo en el que deberá
conservarse la información, pero se puede considerar que los
documentos comerciales han de conservarse, por lo general, durante
cinco años a efectos fiscales. Este período de cinco años, aplicado a la
información pertinente a efectos de trazabilidad, satisfaría probablemente
el objetivo del artículo 18.
Establecer mecanismos de validación / verificación por

parte de la empresa
Conviene revisar habitualmente el sistema para comprobar que funciona
de forma efectiva y registrar que tal comprobación se ha producido. El
sistema debe evaluarse teniendo en cuenta:
ü la exactitud de la información almacenada,
ü el tiempo de respuesta, que deberá ser el mínimo posible, ya que

pueden existir riesgos para la salud de las personas.

Método Ágil Scrum
Es útil hacer, regularmente, un simulacro de demanda de la información

sobre trazabilidad. Los inspectores, incluso los clientes, pueden participar
y sugerir “casos prácticos” para comprobar que la información de
trazabilidad puede recogerse de forma fiable y rápida.
Por ejemplo, se tomará un producto al azar y se comprobará si se pueden

conocer las materias primas y los procesos tecnológicos sufridos.
También se verá si, a partir de una documentación de una materia prima,
se puede conocer el producto del que ha formado parte y su distribución.
Establecer mecanismos de comunicación inter-empresas

Conseguir la trazabilidad a lo largo de toda la cadena compete a todos los
eslabones. Es responsabilidad de cada uno evitar que se quiebre la
trazabilidad en el eslabón que representa, porque si ello ocurriese pueden
verse perjudicados operadores que estén cumpliendo suficientemente con
el desarrollo del sistema de trazabilidad en su establecimiento.
Muchas empresas ya piden que sus proveedores compartan con ellos la

información sobre trazabilidad. Resulta muy positivo establecer protocolos
o mecanismos comunes sobre cómo compartir la identificación y la
información. Por ello, es muy útil mantener conversaciones con los
proveedores y clientes para acordar entre todos qué información
(composición, origen, etc.), es crítica y para asegurar que se proporciona
de una forma clara y comprensible.

Método Ágil Scrum
HERRAMIENTAS DE TRAZABILIDAD EAN.UCC

La introducción de los estándares EAN.UCC puede mejorar la eficiencia
de registrar e intercambiar información entre los integrantes de la cadena
de abastecimiento. Cuando se los usa juntamente con bases de datos
que contienen registros exactos y puntuales, los estándares EAN.UCC
proporcionan a los participantes de la cadena la capacidad técnica para
ver el origen de un producto, en sus propias localizaciones y a través de
toda la cadena de abastecimiento.
Números Mundiales de Artículo Comercial EAN.UCC

Mientras el aspecto más visible de la numeración del artículo es el código
de barra, ésta es solo una representación de un número, leído por una
máquina. El número es el elemento más importante en el sistema
EAN.UCC, porque identifica el artículo al cual ha sido asignado.
El sistema de numeración EAN.UCC proporciona una unidad mundial y

supera problemas de confusión, duplicaciones y mala interpretación,
porque todos los usuarios del sistema EAN.UCC siguen las mismas
reglas de código. Un número EAN.UCC puede reconocerse, no solo por
las empresas comerciales locales, sino también, por otras operando en el
exterior. Cada número EAN.UCC es único a lo ancho del mundo, por lo
tanto no hay posibilidad de confusión. El sistema de numeración
EAN.UCC también proporciona a los artículos la habilidad para
transportar, dentro de la convención numérica, información extra o de
atributos de los mismos.

Método Ágil Scrum
Códigos de barra EAN.UCC

Los códigos de barra son transportadores de datos. El código de barra se
usa en el sistema EAN.UCC para representar los números EAN.UCC.
Los códigos de barra EAN.UCC permiten la captura automática de datos,

lo que significa una solución comercial clave, dentro de una eficiente
cadena de abastecimiento. La numeración EAN.UCC y el sistema de
codificación de barra, permiten la entrada rápida y exacta de los datos, a
los sistemas de computadora, automatizando el flujo de información
dentro de los procesos comerciales. También permiten la captura
mejorada de datos y la transferencia de información, al tiempo que se
reducen los costos.
El sistema EAN.UCC es la mejor práctica para implementar trazabilidad

porque este estándar es único, global, genérico, voluntario y esta
disponible para el uso de todas las compañías, facilitando la identificación
de productos y el intercambio de información. Si el estándar es utilizado
adecuadamente por todos los eslabones de la cadena de abastecimiento,
se logrará alinear el flujo de producto y el flujo de información, que es la
base del concepto de trazabilidad.
ALTERNATIVAS DE IMPLEMENTACIÓN
Alternativas para implementar un sistema de trazabilidad:
Ø Manual sin sistema de información.

Ø Manual con sistema de información.
Ø Automatizado con código de barras.

Método Ágil Scrum
Trazabilidad Manual (Sin Sistema de Información)

• Se basa en el mantenimiento de registros físicos (por ejemplo planillas)
acerca de los lotes que la empresa produce.
• Implica un buen archivo físico de información para facilitar la búsqueda

cuando se requiere.
• Implica tiempo por parte de la mano de obra en el diligenciamiento de

las planillas y la administración del archivo.
• Cuando la empresa es grande, recuperar la información acerca de un

lote normalmente implica un tiempo significativo.
• Hay riesgo por errores de diligenciamiento de la información en las

planillas.
• Baja inversión de capital en el montaje del sistema.
Trazabilidad Manual (Con Sistema de Información)

• Se basa en el mantenimiento de registros en un sistema de información
• Implica tramitar planillas físicas dentro del proceso, las cuales son
digitadas posteriormente en el sistema.
• Requiere tiempo en el diligenciamiento de las planillas y en la digitación

en el sistema.

Método Ágil Scrum
• La velocidad de respuesta se incrementa dado que el sistema permite

tener información a mayor velocidad.
• Se mantiene el riesgo por errores en el diligenciamiento de las planillas y

por errores de digitación en el sistema.
• Requiere inversiones medianas de capital en el montaje del sistema.
Trazabilidad Automatizada (Con Código de Barras)

• Se basa en el mantenimiento de registros en un sistema de información
• Implica contar con un sistema de información robusto que soporte la

generación y captura de información con código de barras y el
almacenamiento de la información de trazabilidad.
• El tiempo de llenado de planillas y la digitación en el sistema se reduce

por el proceso de captura.
• La velocidad de respuesta se incrementa dado que se puede tener

información en línea (por ejemplo: uso de radiofrecuencia).
• Se reduce el riesgo por errores de digitación, pero se mantiene el riesgo

de errores en el momento de la captura del código de barras.
• Requiere inversiones entre medianas y altas de capital en el montaje del

sistema, el etiquetado de productos y otros elementos del sistema.

Método Ágil Scrum
Comparativa
Alternativa Tiempo Velocidad / Riesgo errores Inversión
(digitación) Confiabilidad (digitación /
de respuesta captura)
Manual Alto Baja Alto Baja
Manual + SI Alto Media Alto Media
Automatizada + CB Bajo Alta Medio Alta
¿Cuál es el mejor sistema para mi empresa?

Alternativa ¿Para quién es adecuada?
Empresas pequeñas con poca vocación
Manual exportadora, que manejan pocas referencias, pocos
lotes de producción y tienen pocos clientes.
Empresas pequeñas con capacidad de inversión en
un sistema de información cuyo mercado exija algo
Manual + SI de velocidad en la respuesta, que manejan varias
referencias, varios lotes de producción y varios
clientes.
Empresas medianas y grandes con vocación
Automatizada + CB exportadora hacia mercados y clientes exigentes,
con muchas referencias y lotes de producción.
Luego de analizar estas tres alternativas se optó por desarrollar la opción

intermedia, es decir, manual con sistema de información, ya es la más
acertada para el tipo de organización para la cual se construirá el
software.

Método Ágil Scrum
ANEXO C
ANÁLISIS DEL SISTEMA
MODELO DE NEGOCIO
Objetivos estratégicos y procesos del negocio
El objetivo de modelar el proceso de negocio es capturar el esquema
general y los procedimientos que gobiernan el negocio. Este modelo
provee una descripción de dónde se va a ajustar el sistema de software
considerado dentro de la estructura organizacional y de las actividades
habituales.
Como un modelo preliminar del negocio, permite al analista capturar los

eventos, las entradas, los recursos y las salidas más importantes
vinculadas con el proceso de negocio. Es posible construir un modelo
completamente trazable mediante la posterior conexión de elementos de
análisis (tales como los casos de uso) a través de conectores de
implementación, desde la generalidad del proceso de negocio a los
requisitos funcionales y eventualmente a los artefactos de software que se
construirán realmente.
El primer paso consiste en capturar los procesos de negocio a partir de

los objetivos principales de la organización. Teniendo en cuenta que éstos
van a ser muy complejos y de un nivel de abstracción muy alto, serán
descompuestos en subobjetivos más específicos. Para cada uno de ellos
se define un proceso de negocio que deberá dar soporte a dicho
subobjetivo. Lo recién expresado lo podemos observar en el siguiente
cuadro.

Método Ágil Scrum
Objetivos estratégicos Subobjetivos Procesos

Registrar datos entrantes.
Cumplir con los Realizar la trazabilidad Registrar proceso de
requisitos legales de los productos producción.
Registrar salida del
producto.
Identificar y ubicar
Optimizar el manejo de
Minimizar los tiempos eficientemente los
la información en el
de retirada de productos productos dentro de la
campo
cadena.
Tener diferentes niveles
Aumentar el control y la
de acceso al sistema.
seguridad de la Realizar auditorias
Conocer movimientos de
información
auditorias.
A continuación se representa, a través de Diagramas de Actividades, los

tres primeros procesos anteriormente definidos, y que serán definitiva los
que nos permitirán llevar a cabo la trazabilidad del producto.
Diagramas de Actividades

Método Ágil Scrum
Este primer diagrama de actividad es a nivel general. A continuación se

realizará la explotación de las actividades Explotación del viñedo y
Vendimia para analizarlas con detalle. Hemos utilizado los Diagramas de
Actividades para explicar el planteamiento funcional del sistema.

Método Ágil Scrum
IDENTIFICACIÓN DE REQUERIMIENTOS
Para llegar a obtener un listado exhaustivo de los requerimientos iniciales
del sistema comenzaremos identificando los casos de uso, se adoptó la
utilización de los mismos porque se considera que aportan una forma
sencilla de comunicación con el cliente.
Actores del sistema
Usuario: actor con ciertas restricciones sobre las

funcionalidades del sistema.
Usuario
Administrador: actor sin restricciones sobre las

funcionalidades del sistema.
Administrador
Relación entre actores: Herencia

Método Ágil Scrum
Casos de uso
Este diagrama de casos de uso de primer nivel permite tener una visión
general de los procesos de la organización, así como también permite
mostrar los límites y el entorno de la organización bajo estudio.
Logearse en el
sistema
Registrar datos
entrantes
Registrar proceso
de producción
Registrar
salida del producto
Identificar y ubicar
efectiva/ los productos
dentro de la cadena
Realizar
auditorias
Ingresar Cambiar
clave clave
Usuario
Explotación del caso de uso Logearse en el sistema.

Administrar Administrar acciones Administra
Proveedore de auditoria r Usuarios
Administrar
Tareas
Manejar Administrar
Agroquímicos Titulares
Manejar Administra
Mét. apl. r Fincas
Manejar Administrar
Maquinaria Administrador
Cuarteles x finca
Conocer Rev.
Administrar
técnicas
Conducc. viñedo
Manejar
Usuario
Camiones
Administra
r
Manejar
Cias. seguros
Manejar
Enferm. vid
Manejar
seguros
Administra
Manejar r Personal
Bodegas
Manejar Conocer Fincas Conocer Titulares Conocer

Delegac. INV x Titulares x Finca capacitaciones x

Método Ágil Scrum
Conocer la
Registrar Trazabilidad
tareas diarias
Usuario
Explotación del caso de uso Registrar proceso de producción.
Pesar cajas
Asentar remito
de cosecha
Consultar
cosecha de
Usuario
Explotación del caso de uso Registrar salida del producto.
Consultar mov. Consultar mov.

auditorias x usuario auditorias x
Consultar mov. Consultar mov.

auditorias x auditorias x
Usuario
Explotación del caso de uso Realizar auditorias.

Método Ágil Scrum
Lista exhaustiva de requerimientos
Ítem Requisitos Orden

1 Ingresar clave 1
2 Cambiar clave 3
3 Administrar titulares 4
4 Administrar fincas 9
5 Administrar cuarteles por finca 10
6 Administrar tipos de conducción del viñedo 7
7 Administrar variedades de uva 6
8 Manejar enfermedades de la vid 8
9 Administrar personal 13
10 Conocer capacitaciones por personal 14
11 Conocer titulares por finca 11
12 Conocer fincas por titular 12
13 Manejar delegaciones del INV 5
14 Manejar bodegas 24
15 Manejar seguros de transportes 22
16 Manejar compañías de seguros 21
17 Manejar camiones 20
18 Conocer revisiones técnicas 23
19 Manejar maquinarias 19
20 Manejar métodos de aplicación de agroquímicos 18
21 Manejar agroquímicos 17
22 Administrar proveedores 15
23 Administrar tareas agrícolas 16
24 Administrar acciones de auditoria 25
25 Administrar usuarios 2
26 Registrar tareas diarias 26
27 Conocer la trazabilidad 33
28 Asentar remito de cosecha 27
29 Consultar cosecha de uva 28
30 Consultar movimientos de auditoria por usuarios 29
31 Consultar movimientos de auditoria por fecha 30
32 Consultar movimientos de auditoria por acción de auditoria 31
33 Consultar movimientos de auditoria por comprobantes 32
Esta lista, armada en conjunto con el cliente, contiene todos los requisitos
del sistema detectados hasta el momento. Se han priorizado según la
importancia que tienen para el cliente teniendo en cuenta la fecha de
entrega. Esto permite convertir un objetivo irrealizable en uno “difícil” pero
realista. Esta lista será en definitiva nuestro primer Backlog de Producto.

Método Ágil Scrum
Descripciones de casos de uso
Id. requisito: R01

Nombre: Ingresar clave
Fecha: 16/12/2005
Descripción:
Permite el ingreso al sistema
Actores:
Usuario / Administrador del sistema
Precondiciones:
Usuario dado de alta en el sistema
Flujo normal:
1. El usuario ingresa su nombre de usuario
2. El usuario ingresa su contraseña
3. El sistema valida los datos introducidos y entra al sistema
Flujo alternativo:
3. El sistema comprueba la validez de los datos, si los datos no son los correctos,
avisa al actor de ello y cierra la ventana.
Poscondiones:
El usuario ingresa al sistema
Referencias: R25
Id. requisito: R02

Nombre: Cambiar clave
Fecha: 16/12/2005
Descripción:
Permite cambiar la clave de ingreso al sistema
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa por medio de una opción del menú
2. El usuario ingresa su nombre de usuario y su contraseña actual
3. El usuario ingresa su nueva clave y la confirmación de ella
4. El sistema valida los datos introducidos y almacena el cambio
Flujo alternativo:
avisa al actor de ello y cierra la ventana.
Poscondiones:
El cambio de clave es almacenado en el sistema
Referencias: R25

Método Ágil Scrum
Id. requisito: R03

Nombre: Administrar titulares
Fecha: 16/12/2005
Descripción:
Permite altas, bajas y modificaciones de titulares de fincas
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de los titulares existentes y los botones Agregar,
Cambiar y Borrar
3. El usuario agrega, modifica, o borra el registro
4. El sistema valida los datos y los almacena
Flujo alternativo:
avisa al actor de ello permitiéndole que los corrija.
Poscondiones:
El nuevo registro, el cambio o la eliminación queda almacenado en el sistema.
Referencias: R04, R17, R19
Id. requisito: R04

Nombre: Administrar fincas
Fecha: 16/12/2005
Descripción:
Permite altas, bajas y modificaciones de propiedades rurales
Actores:
Precondiciones:
Usuario logueado.
Flujo normal:
2. El sistema muestra un listado de las propiedades rurales existentes y los botones
Agregar, Cambiar y Borrar
Flujo alternativo:
Poscondiones:
Referencias: R03, R05, R13, R26, R28

Método Ágil Scrum
Id. requisito: R05

Nombre: Administrar cuarteles x finca
Fecha: 16/12/2005
Descripción:
Permite altas, bajas y modificaciones de cuarteles
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al ABM de fincas y selecciona una de ellas
2. El usuario pulsa el botón Cambiar y luego en la solapa Cuarteles
3. El sistema muestra un listado de los cuartes existentes y los botones Agregar,
Cambiar y Borrar
5. El sistema valida los datos y almacena los cambios
Flujo alternativo:
Poscondiones:
Referencias: R04, R06, R07, R26, R28
Id. requisito: R06

Nombre: Administrar conducción del viñedo
Fecha: 16/12/2005
Descripción:
Permite altas, bajas y modificaciones de los tipos de conducción del viñedo
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de los tipos de conducción ya ingresados y los
botones Agregar, Cambiar y Borrar
Flujo alternativo:
Poscondiones:
Referencias: R05

Método Ágil Scrum
Id. requisito: R07

Nombre: Administrar variedades de uva
Fecha: 16/12/2005
Descripción:
Permite altas, bajas y modificaciones de variedades de uva
Actores:
Precondiciones:
Usuario logueado.
Flujo normal:
2. El sistema muestra un listado de las variedades de uva existentes y los botones
Flujo alternativo:
Poscondiones:
Id. requisito: R08

Nombre: Manejar enfermedades de la vid
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de enfermedades de la vid
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las enfermedades existentes y los botones
Flujo alternativo:
Poscondiones:
Referencias: R21

Método Ágil Scrum
Id. requisito: R09

Nombre: Administrar personal
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones del personal
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado del personal existentes y los botones Agregar,
Cambiar y Borrar
Flujo alternativo:
Poscondiones:
Id. requisito: R10

Nombre: Conocer capacitaciones por personal
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de las capacitaciones por personal
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al ABM de Personal y selecciona un trabajador
2. El usuario pulsa el botón Cambiar y luego en la solapa Capacitaciones
3. El sistema muestra un listado de las capacitaciones existentes de ese trabajador
y los botones Agregar, Cambiar y Borrar
Flujo alternativo:
5. El sistema comprueba la validez de los datos y los almacena.
Poscondiones:
Referencias: R09

Método Ágil Scrum
Id. requisito: R11

Nombre: Conocer titulares por finca
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de los titulares por finca
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al ABM de Fincas y selecciona una de ellas
2. El usuario pulsa el botón Cambiar y luego en la solapa Titulares
3. El sistema muestra un listado de los titulares existentes y los botones Agregar,
Cambiar y Borrar
Flujo alternativo:
Poscondiones:
Referencias: R03, R04
Id. requisito: R12

Nombre: Conocer fincas por titular
Fecha: 19/12/2005
Descripción:
Permite conocer las fincas por titular
Actores:
Precondiciones:
Usuario logueado.
Flujo normal:
1. El usuario ingresa al ABM de Titulares y selecciona una de ellas
2. El usuario pulsa el botón Cambiar y luego en la solapa Fincas
3. El sistema muestra un listado de las propiedades existentes para dicho titular
4. El usuario sale con el botón Aceptar
Flujo alternativo:
No se presenta
Poscondiones:
El sistema vuelve a la pantalla principal del ABM.

Método Ágil Scrum
Id. requisito: R13

Nombre: Manejar delegaciones del INV
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de delegaciones del INV
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las delegaciones existentes y los botones
Flujo alternativo:
Poscondiones:
Id. requisito: R14

Nombre: Manejar bodegas
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de bodegas
Actores:
Precondiciones:
Usuario logueado.
Flujo normal:
2. El sistema muestra un listado de las bodegas ya ingresadas y los botones
Flujo alternativo:
Poscondiones:

Método Ágil Scrum
Id. requisito: R15

Nombre: Manejar seguros
Fecha: 20/12/2005
Descripción:
Permite altas, bajas y modificaciones de seguros de transporte
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al ABM de Camiones y selecciona uno de ellos
2. El usuario pulsa el botón Cambiar
3. El sistema muestra un listado de los seguros existentes para dicho camión y los
Flujo alternativo:
Poscondiones:
Id. requisito: R16

Nombre: Manejar compañías de seguros
Fecha: 19/12/2005
Descripción:
Permite altas, bajas y modificaciones de compañías de seguros
Actores:
Precondiciones:
Usuario logueado.
Flujo normal:
2. El sistema muestra un listado de las compañías ya ingresadas y los botones
Flujo alternativo:
4.El sistema comprueba la validez de los datos, si los datos no son los correctos, avisa
al actor de ello permitiéndole que los corrija.
Poscondiones:
Referencias: R15

Método Ágil Scrum
Id. requisito: R17

Nombre: Manejar camiones
Fecha: 20/12/2005
Descripción:
Permite altas, bajas y modificaciones de camiones
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las camiones existentes y los botones Agregar,
Cambiar y Borrar
Flujo alternativo:
Poscondiones:
Referencias: R03, R15, R18, R28
Id. requisito: R18

Nombre: Conoce revisiones técnicas
Fecha: 20/12/2005
Descripción:
Permite altas, bajas y modificaciones de revisiones técnicas
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al ABM de Maquinarias o al de Camiones y selecciona uno
2. El usuario pulsa el botón Cambiar
3. El sistema muestra un listado de las revisiones técnicas existentes y los botones
Flujo alternativo:
Poscondiones:

Método Ágil Scrum
Id. requisito: R19

Nombre: Manejar maquinarias
Fecha: 20/12/2005
Descripción:
Permite altas, bajas y modificaciones de maquinarias
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las maquinarias existentes y los botones
Flujo alternativo:
Poscondiones:
Id. requisito: R20

Nombre: Manejar métodos de aplicación de agroquímicos
Fecha: 22/12/2005
Descripción:
Permite altas, bajas y modificaciones de aplicación de agroquímicos
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de los métodos de aplicación ya ingresados y los
3. El administrador agrega, modifica, o borra el registro
Flujo alternativo:
Poscondiones:
Referencias: R26

Método Ágil Scrum
Id. requisito: R21

Nombre: Manejar agroquímicos
Fecha: 20/12/2005
Descripción:
Permite altas, bajas y modificaciones de agroquímicos
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa a través de una opción del menú
2. El sistema muestra un listado de los agroquímicos ya ingresados y los botones
3. El usuario agrega, modifica o borra el registro
Flujo alternativo:
Poscondiones:
Id. requisito: R22

Nombre: Administrar proveedores
Fecha: 22/12/2005
Descripción:
Permite altas, bajas y modificaciones de proveedores
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1.El usuario ingresa por medio de una opción del menú
2.El sistema muestra un listado de los proveedores ya ingresados y los botones
3.El usuario agrega, modifica o borra el registro
Flujo alternativo:
4.El sistema comprueba la validez de los datos, si los datos no son los correctos,
Poscondiones:

Método Ágil Scrum
Id. requisito: R23

Nombre: Administrar tareas
Fecha: 21/12/2005
Descripción:
Permite altas, bajas y modificaciones de tareas agrícolas
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las tareas ya ingresadas y los botones Agregar,
Cambiar y Borrar
3. El usuario agrega, modifica o borra el registro
Flujo alternativo:
Poscondiones:
Referencias: R26
Id. requisito: R24

Nombre: Administrar acciones de auditoria
Fecha: 21/12/2005
Descripción:
Permite altas, bajas y modificaciones de acciones de auditoria
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un listado de las acciones de auditoria existentes y los
Flujo alternativo:
Poscondiones:
Referencias: R25

Método Ágil Scrum
Id. requisito: R25

Nombre: Administrar usuarios
Fecha: 21/12/2005
Descripción:
Permite altas, bajas y modificaciones de usuarios
Actores:
Administrador del sistema
Precondiciones:
Usuario logueado
Flujo normal:
1. El administrador ingresa por medio de una opción del menú
2. El sistema muestra un listado de los usuarios ya ingresados y los botones
3. El administrador agrega, modifica, o borra el registro
Flujo alternativo:
Poscondiones:
Referencias: R24
Id. requisito: R26

Nombre: Registrar parte agrario
Fecha: 22/12/2005
Descripción:
Permite altas de los partes agrarios
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra el botón Agregar y luego un parte de tareas en blanco
3. El usuario completa los datos solicitados
Flujo alternativo:
4.El sistema comprueba la validez de los datos, si los datos no son los correctos,
Poscondiones:
El nuevo registro queda almacenado en el sistema.
Referencias: R04, R05, R07, R09, R19, R20, R21, R23

Método Ágil Scrum
Id. requisito: R27

Nombre: Conocer la trazabilidad
Fecha: 21/12/2005
Descripción:
Permite consultar por la trazabilidad de productos
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
2. El sistema muestra un grupo de botones que permiten habilitar o deshabilitar
parámetros
3. El usuario completa los parámetros por los cuales se filtrará la información
4. El sistema valida los datos y muestra la consulta
Flujo alternativo:
borra el campo de datos para que sean ingresados nuevamente.
Poscondiones:
La consulta es desplegada en pantalla.
Referencias: R04, R05, R07, R09, R21, R23, R26
Id. requisito: R28

Nombre: Asentar remito de cosecha
Fecha: 22/12/2005
Descripción:
Permite altas de los remitos de cosecha
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa al remito de cosecha
2. El sistema muestra el botón Agregar y luego un remito de cosecha en blanco.
3. El usuario completa los datos solicitados
Flujo alternativo:
Poscondiones:
El nuevo registro queda almacenado en el sistema.
Referencias: R03, R04, 05, R07, R09, R14, R17

Método Ágil Scrum
Id. requisito: R29

Nombre: Consultar cosecha de uva
Fecha: 22/12/2005
Descripción:
Permite consultar cosecha de uva
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa a través del menú a la consulta de cosecha de uva
2. El sistema muestra un grupo de botones: Titular, Viñedo y Variedad
3. El usuario pulsa el botón elegido y completa los datos solicitados por el sistema
4. El usuario pulsa el botón Procesar
Flujo alternativo:
borra el campo de datos para que sean ingresados nuevamente.
Poscondiones:
La consulta es desplegada en pantalla.
Referencias: R03, R04, R07, R28
Id. requisito: R30

Nombre: Consultar movimientos de auditoria por usuario
Fecha: 22/12/2005
Descripción:
Permite consultar movimientos de auditoria por usuario
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
1. El usuario ingresa a través del menú a la consulta de auditoria
2. El sistema muestra un grupo de botones
3. El usuario pulsa el botón Usuario y completa los datos solicitados por el sistema
Flujo alternativo:
Poscondiones:
El sistema muestra el resultado de la consulta filtrada por usuario.

Método Ágil Scrum
Id. requisito: R31

Nombre: Consultar movimientos de auditoria por fecha
Fecha: 22/12/2005
Descripción:
Permite consultar movimientos de auditoria por fecha
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
3. El usuario pulsa el botón Fecha y completa los datos solicitados por el sistema
Flujo alternativo:
Poscondiones:
El sistema muestra el resultado de la consulta filtrada por fecha.
Referencias: R24, 25
Id. requisito: R32

Nombre: Consultar movimientos de auditoria por acción
Fecha: 22/12/2005
Descripción:
Permite consultar movimientos de auditoria por acción
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
3. El usuario pulsa el botón Acción y completa los datos solicitados por el sistema
Flujo alternativo:
Poscondiones:
El sistema muestra el resultado de la consulta filtrada por acción.
Referencias: R24, 25

Método Ágil Scrum
Id. requisito: R33

Nombre: Consultar movimientos de auditoria por comprobante
Fecha: 22/12/2005
Descripción:
Permite consultar movimientos de auditoria por comprobantes
Actores:
Precondiciones:
Usuario logueado
Flujo normal:
3. El usuario pulsa el botón Comprobante y completa los datos solicitados por el
sistema
Flujo alternativo:
Poscondiones:
El sistema muestra el resultado de la consulta filtrada por los tipos de comprobantes
seleccionados.

Método Ágil Scrum
ANEXO D
DISEÑO DEL SISTEMA
MODELO DE DATOS
En este apartado se presenta el esquema de la Base de Datos del
Software de Trazabilidad.

Método Ágil Scrum

Método Ágil Scrum

Método Ágil Scrum

Método Ágil Scrum
Presentadas todas las tablas de la BD y sus relaciones continuamos con

otros aspectos del diseño.
GUÍA DE DISEÑO
Estructura de layout
Se presenta la estructura de layout de la pantalla principal del sistema. La
misma tiene una distribución muy simple cómo se puede observar en el
diseño siguiente. Donde se observa solamente la barra de menú principal
en la parte superior de la ventana.

Método Ágil Scrum
Look&feel aplicado a la estructura de layout anterior

Método Ágil Scrum
Menús
Se elige este sistema de menú porque se considera que es claro e
intuitivo. Proporciona un mejor entendimiento por parte de los usuarios
quienes suelen estar acostumbrados a su utilización dado que el
desplegable vertical está presente en muchos programas, por ejemplo los
de ofimática.
Menú habilitado Menú deshabilitado
Paleta de colores
Se seleccionaron como colores principales el gris y el azul marino ya que
se considera que son tonos sobrios y elegantes, a la vez que no cansan
tanto la vista luego de varias horas de fijación ante la pantalla.
Textura
Para fondo
Modelo de color: RGB

Rojo: 0 Verde: 0 Azul: 128
Para Títulos de las aplicaciones

Método Ágil Scrum
Tipografía
La tipografía debe ser estándar para que pueda ser visualizada
correctamente en todo tipo de equipos. Se utiliza esta clase de tipografía
para no dificultar la edición de contenidos.
Títulos de aplicaciones: Tahoma negrita 16 pt

Campos: Arial negrita 9 pt
Iconos
Se presentan como ejemplo algunos de los íconos que se utilizan en las
aplicaciones para hacer más intuitiva y amigable la interacción con ellas.
Agregar
Borrar
Procesa
Salir

Método Ágil Scrum
CONCLUSIONES
Haber implementado el método Scrum para el desarrollo de un software

real ha resultado una experiencia gratificante y un aprendizaje constante
en todas las etapas del desarrollo del mismo. El hecho de haber
terminado el trabajo obteniendo como resultado un producto funcionando
muestra que los objetivos planteados en un principio se cumplieron. Pero
lo más importante, es que se incrementaron los conocimientos por lo que
el trabajo implicó una gran satisfacción personal.
El primer objetivo planteado fue adentrarse en las Metodologías Ágiles en

general y en Scrum en particular para conocer el método y poder aplicarlo
posteriormente. Luego de su estudio y análisis se llega a la conclusión de
que su simplicidad en el desarrollo es lo que evita perder de vista el
objetivo. Es sencillo, flexible, y muy enfocado a la verdadera necesidad
del cliente. Es muy amigable a la hora de implementarlo y se cree que es
ideal para los negocios y las actividades de la actualidad que son más
complejos, cambiantes y vertiginosos que antes.
Pero en Scrum no todo es color de rosas, debido a que es un método de

gestión de proyectos (permite gestionar proyectos de cualquier tipo, no
sólo tecnológicos) es que deja un vacío en el área del proceso y delega al
equipo de trabajo esa responsabilidad por completo.
Precisamente por este motivo fue que nos planteamos el segundo

objetivo, elaborar una metodología propia de desarrollo para
complementar esta insuficiencia de Scrum.

Método Ágil Scrum
Nuestro proceso definido con las cinco etapas tradicionales del desarrollo
de software se adaptó muy bien a la filosofía ágil. Y de la combinación de
herramientas utilizadas cabe destacar a ScrumWorks que resultó una
excelente herramienta para hacer el seguimiento diario del proyecto e ir
midiendo constantemente la velocidad de desarrollo. Eso si, para ello hay
que ser perseverante y reestimar diariamente el esfuerzo pendiente de las
tareas.
El desarrollo del Proyecto Trazabilidad que derivó en un Software de

Trazabilidad como producto final se llevó adelante sin mayores
sobresaltos, y podemos arrojar los siguientes resultados sobre el mismo.
De las seis entregas programadas para el cliente, las cinco primeras se
cumplieron en tiempo y forma. Hay que reconocer que en las
estimaciones iniciales de esfuerzo se tuvo, la mayoría de las veces, una
visión un poco pesimista, tal vez por temor a la falta de experiencia se
prefirió holgar un poco los tiempos.
En el último Sprint, el sexto, se detectó al comienzo del mismo que iba a

haber un atraso lo que nos llevó de inmediato a renegociar con el cliente
la última fecha de entrega, la cual se corrió una semana. Esta ha sido
entonces, la demora total que sufrió el proyecto, una semana, creemos
que es un margen de atraso bastante aceptable.
Como conclusión final se quiere exponer que el hecho de ir haciendo

entregas constantes y frecuentes al cliente, no sólo lo mantiene contento,
sino que además aumenta la confianza y la autoestima del desarrollador.
Ir concretando etapas es una motivación para seguir adelante.

Método Ágil Scrum
BIBLIOGRAFÍA
Metodologías ágiles y Scrum

http://www.agilemanifesto.org
http://www.agile-spain.org
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/hetero
dox.asp
CIS. Juan Palacio Bañeres – http://www.navegapolis.net
Material brindado en Curso de Prácticas Ágiles. John Gómez. Dictado en
la UM.
Metodología y Desarrollo del Proyecto

Ingeniería del Software. Un enfoque práctico. Roger S. Pressman
Claves para el Éxito de los Proyectos. Pablo Lledó, Gustavo Rivarola.
Producción de uva y Trazabilidad

http://www.inv.gov.ar/
http://www.alimentosargentinos.gov.ar/
http://www.sagpya.mecon.gov.ar/
http://www.gestiontrazabilidad.com/
http://www.consumaseguridad.com/
Reglamento (CE) n° 178/2002 del Parlamento Europeo y del Consejo.

Metodología Scrum

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodología Scrum

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE MENDOZA

“MÉTODO ÁGIL SCRUM

María Laura Citón

Asesora: Ing. Graciela Sevilla

En primer lugar, deseo agradecer al Dr. Ing. Salvador Navarria, Decano

Deseo brindar un especial agradecimiento a la Ing. Graciela Sevilla y

Al Cdor. Mario Gobbi por la información brindada, asesoramiento y buena

A mi familia, a mi novio David y a mis amigos, por sus opiniones y

Y principalmente quiero dedicar este trabajo a mis padres, Dora y Luis, y

El presente Trabajo Final consiste en aplicar el método ágil Scrum al

Como alternativa a las metodologías tradicionales nacen las ágiles, y

Para poder implementarlo, entonces, elaboramos un proceso de

El hecho de haber terminado el trabajo obteniendo como resultado un

María Laura Citón 1 Universidad de Mendoza

TERCERA PARTE: DESARROLLO DE INGENIERÍA

María Laura Citón 2 Universidad de Mendoza

En el actual contexto económico, los profesionales en el área de las

Todo proyecto tiene una meta: la combinación de recursos de todo tipo,

Este nuevo concepto de lo que se considera hoy en día un proyecto

A raíz de este planteo surge la inquietud de ahondar en las metodologías

María Laura Citón 3 Universidad de Mendoza

a proyectos pequeños, constituyen una solución a medida para ese

Las metodologías más características de esta familia son XP (Extreme

Scrum está basado en un proceso constructivo iterativo e incremental

Es uno de los métodos de gestión de proyectos más innovadores de los

María Laura Citón 4 Universidad de Mendoza

Es mucho menos conocido que otros métodos ágiles. Posiblemente una

No está concebido como un método independiente, sino que se promueve

Para llevar a cabo las etapas mencionadas en el párrafo anterior se utiliza

María Laura Citón 5 Universidad de Mendoza

A continuación presentamos los objetivos generales que se han planteado

Ø Conocer el método ágil Scrum para su posterior aplicación a un

El porqué de la elección de desarrollar un Software de Trazabilidad y no

A raíz de que comienza a regir a partir del 1º de Mayo de 2005 una

La oportunidad de abordar esta temática de tanto auge en la actualidad

María Laura Citón 6 Universidad de Mendoza

Los productores agrarios deberían comenzar a responder a este requisito

Se explica a continuación la manera en la que se ha organizado el

Primera Parte: Marco Teórico

Segunda Parte: Metodología

Tercera Parte: Desarrollo de Ingeniería

Luego, se presentan 4 Anexos que forman parte del desarrollo del

María Laura Citón 7 Universidad de Mendoza

§ No se adaptan a los cambios.

Con base en lo anterior se ha llegado a un acuerdo de lo que significa un

María Laura Citón 9 Universidad de Mendoza

No es novedad que una forma de resolver los problemas de calidad, y

En una actividad humana como es el desarrollo de software, esto es casi

1.1.2. El surgimiento de la agilidad

1.2. ¿QUÉ ES UNA METODOLOGÍA ÁGIL?

ü Los individuos y sus interacciones son más importantes que los

ü El software que funciona es más importante que la documentación

María Laura Citón 10 Universidad de Mendoza

ü La colaboración con el cliente en lugar de la negociación de

ü La respuesta al cambio en lugar de aferrarse a un plan.

Los valores y principios compartidos por toda la metodología ágil fueron

1.2.1. La Alianza Ágil

Tras esta reunión se creó The Alliance, una organización dedicada a

María Laura Citón 11 Universidad de Mendoza

1.2.2. El Manifiesto Ágil

Al individuo y a las interacciones del equipo de desarrollo sobre el

Desarrollar software que funciona más que conseguir una buena

La colaboración con el cliente más que la negociación de un

María Laura Citón 12 Universidad de Mendoza