Metodo agil 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


Metodo agil scrum

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Metodo agil scrum

Similar a Metodo agil scrum (20)

Metodo agil scrum