Perfil MRP

Universidad Autónoma Gabriel René Moreno
Facultad de Ingeniería en Ciencias de la Computación y Telecomunicaciones
“Sistema de Procesos de Producción

Manufactura (MRP)”
Universidad Autónoma Gabriel René
Moreno Grupo 8
Facultad de Ingeniería en Ciencias de la
Computación yINTEGRANTES:
Telecomunicaciones
Justiniano Herrera Alvaro Andres 213091259
Pacheco Ardaya Juan Daniel 212015753
Sosa Pesoa Juan Antonio 210007664
Terrazas Escobar Sergio Ricardo 210010053
DOCENTE:
Ing. Angélica Garzón Cuellar
ASIGNATURA:
Sistemas de Información II (INF412-SA)
FECHA
26/09/2020
Santa Cruz – Bolivia

Índice
1 ASPECTOS GENERALES.................................................................................. 1
1.1 Introducción .................................................................................................. 1
1.2 Antecedentes ................................................................................................. 2
1.3 Descripción Del Problema ............................................................................ 6
1.4 Formulación Del Problema ........................................................................... 9
1.5 Objetivos ....................................................................................................... 9
1.5.1 Objetivo General ..................................................................................... 9
1.5.2 Objeto Especifico .................................................................................... 9
1.6 Alcance ....................................................................................................... 10
1.7 Metodología ................................................................................................ 15
2 ELEMENTOS DEL SISTEMA BASADO EN COMPUTADORAS ............... 19
2.1 Hardware ..................................................................................................... 19
2.1.1 Servidor ................................................................................................. 19
2.1.2 Cliente ................................................................................................... 19
2.1.3 Medios de Comunicación ..................................................................... 19
2.1.4 Otros Dispositivos ................................................................................. 20
2.2 Software ...................................................................................................... 20
2.2.1 Servidor ................................................................................................. 20
2.2.2 Cliente ................................................................................................... 20

2.2.3 Otro software adicional ......................................................................... 20
2.3 Datos ........................................................................................................... 21
2.4 Procesos ...................................................................................................... 23
2.5 Gente / Usuario ........................................................................................... 24
2.6 Documento .................................................................................................. 24
3 TECNOLOGÍA PARA EL DESARROLLO DEL SOFTWARE ...................... 26
3.1 Estrategia para el desarrollo del software ................................................... 26
3.2 Metodología para el desarrollo del software ............................................... 26
3.2.1 Características de la metodología SCRUM .......................................... 26
3.2.2 Características de UML ........................................................................ 28
3.3 Herramientas de desarrollo ......................................................................... 29
3.3.1 Software ................................................................................................ 29
3.3.2 Hardware ............................................................................................... 29
4 POSIBLES COSTOS ......................................................................................... 31
5 POSIBLES BENEFICIOS ................................................................................. 32
5.1 Tiempo ........................................................................................................ 32
5.2 Esfuerzo ...................................................................................................... 32
5.3 Costos.......................................................................................................... 32
6 POSIBLES CLIENTES...................................................................................... 32
7 MODELO DE DOMINIO.................................................................................. 33
CAPITULO 1 MARCO TEÓRICO ......................................................................... 34
1 METODOLOGIA AGIL .................................................................................... 35
1.1 Propósito de Scrum ..................................................................................... 35
1.2 Visión General de Scrum ............................................................................ 35
1.3 El Equipo Scrum (Scrum Team) ................................................................. 36
1.4 El Dueño de Producto (Product Owner) ..................................................... 37
1.5 El Equipo de Desarrollo (Development Team) .......................................... 39
1.6 El Scrum Master ......................................................................................... 43
1.7 Eventos de Scrum ....................................................................................... 44
1.8 El Sprint ...................................................................................................... 45
1.9 Reunión de Planificación de Sprint (Sprint Planning Meeting).................. 46
1.10 Objetivo del Sprint (Sprint Goal) ................................................................ 48
1.11 Scrum Diario (Daily Scrum) ....................................................................... 49
1.12 Revisión de Sprint (Sprint Review) ............................................................ 51
1.13 Retrospectiva de Sprint (Sprint Retrospective)........................................... 52
1.14 Artefactos de Scrum .................................................................................... 53
1.15 Lista de Producto (Product Backlog) .......................................................... 53
1.16 Lista de Pendientes del Sprint (Sprint Backlog) ......................................... 56
1.16.1 Uso de la lista ...................................................................................... 56
1.16.2 El tablero de tareas (Scrum Taskboard) .............................................. 57

1.17 Incremento .................................................................................................. 57
1.18 Transparencia de los Artefactos .................................................................. 58
1.19 Definición de ‘Terminado’ (Definition of ‘Done’) ..................................... 59
1.20 Ventajas y Desventajas ............................................................................... 60
1.21 Valores del Trabajo ..................................................................................... 61
1.21.1 Compromiso ........................................................................................ 61
1.21.2 Foco..................................................................................................... 62
1.21.3 Franqueza ............................................................................................ 63
1.21.4 Respeto ................................................................................................ 64
1.21.5 Coraje .................................................................................................. 65
1.22 Herramientas de Trabajo ............................................................................. 65
DESARROLLO DE SOFTWARE ........................................................................... 68
SAAS (Software as a Service) .............................................................................. 68
Herramientas para el desarrollo (WEB, APP, MÓVIL, BD, SO) ........................ 69
CAPITULO 2 APLICACIÓN DEL MARCO DE TRABAJO SCRUM ................. 70
2 PERSONAS Y ROLES DEL PROYECTO ....................................................... 71
2.1 Personas Y Roles Del Proyecto .................................................................. 71
2.1.1 Product Owner, Team, Scrum Master, Stakeholders, Users ................. 71
2.1.2 Planificación de Actividades y Roles ................................................... 71
2.1.2.1 Sprint 1 ....................................................................................................... 71

2.1.2.2 Sprint 2 ....................................................................................................... 72
2.1.2.3 Sprint 3 ....................................................................................................... 72
2.1.2.4 Sprint 4 ....................................................................................................... 73
2.1.2.5 Sprint 5 ....................................................................................................... 74
2.2 Modelos Para El Desarrollo De Scrum ....................................................... 75
2.2.1 Sprint Planning Meeting (Reunión de planeamiento del Sprint) .......... 75
2.2.2 Pila Sprint (Sprint Backlog) .................................................................. 78
2.2.3 Reunión Diaria (Daily Scrum) .............................................................. 80
2.2.4 Sprint Review........................................................................................ 81
2.2.5 Sprint Retrospective .............................................................................. 81
2.2.6 Planificación de Scrum ......................................................................... 83
2.2.6.1 Elementos Pila de Sprint (Planificación de todas las tareas) ..................... 83

2.2.6.2 Lista de casos de uso (Web y Móvil) .......................................................... 85
2.2.6.3 Paquetes y Casos de Uso............................................................................ 86
2.2.6.4 Artefactos de Scrum ................................................................................... 89
2.2.6.5 Eventos de Scrum (Planificación de reunión diaria, revisión, retrospectiva,
…) 90
2.2.7 Prototipos principales............................................................................ 92
2.2.8 Desarrollo de las fases de Scrum .......................................................... 95
3 CAPITULO 3 REQUERIMIENTOS ................................................................. 96
3.1 Propósito ..................................................................................................... 97
3.2 Ámbito de Sistema ...................................................................................... 97
3.3 Equipo Scrum.............................................................................................. 98
3.4 Funciones del Producto ............................................................................... 98

3.5 Requisitos Específicos ................................................................................ 98
3.5.1 Product Backlog (Inicial) Planificación Inicial..................................... 98
3.5.2 Requisitos Funcionales ....................................................................... 103
3.6 Requisitos No Funcionales ....................................................................... 107
3.7 Restricciones ............................................................................................. 107
3.8 Historias de Usuarios ................................................................................ 107
3.9 Planificación Sprint (Diagrama de Gantt)................................................. 112
CAPITULO 4 DISEÑO .......................................................................................... 114
4.1 Diseño del software utilizando el Modelo C4........................................... 115
4.2 Diseño de Arquitectura de UML............................................................... 116
4.3 Diseño de Datos ........................................................................................ 117
4.3.1 Diseño Lógico de Datos ...................................................................... 117
Diagrama de Clases ........................................................................................ 117
4.3.2 Diseño Físico ...................................................................................... 118
Tabla de Volumen .......................................................................................... 118
5 CAPITULO 5 IMPLEMENTACIÓN .............................................................. 122
5.1 Sprint 1 ...................................................................................................... 124
5.1.1 Personal y Roles del Proyecto............................................................. 124
5.1.2 Planeación de la Iteración y ejecución de tareas de Product Backlog 124
5.1.3 Historias de usuarios y prototipos ....................................................... 128

5.1.4 Desarrollo del Sprint ........................................................................... 132
5.1.4.1 Sprint Planning Meeting .......................................................................... 132

5.1.4.2 Daily Scrum .............................................................................................. 133
5.1.4.3 Sprint Review ........................................................................................... 133
5.1.4.4 Sprint Retrospective ................................................................................. 134
5.1.5 Burndown y BurnUp ........................................................................... 135
5.1.6 Gráfica de esfuerzo y datos de esfuerzo ............................................. 135
5.1.7 Scrum Taskboard ................................................................................ 136
5.2 Sprint 2 ...................................................................................................... 137
5.2.1 Personal y Roles del Proyecto............................................................. 137
5.2.2 Planeación de la Iteración y ejecución de tareas de Product Backlog 137
5.2.3 Historias de usuarios y prototipos ....................................................... 141
5.2.4 Desarrollo del Sprint ........................................................................... 143
5.2.4.1 Sprint Planning Meeting .......................................................................... 143

5.2.4.2 Daily Scrum .............................................................................................. 144
5.2.4.3 Sprint Review ........................................................................................... 145
5.2.4.4 Sprint Retrospective ................................................................................. 145
5.2.5 Burndown y BurnUp ........................................................................... 146
5.2.6 Gráfica de esfuerzo y datos de esfuerzo ............................................. 146
5.2.7 Scrum Taskboard ................................................................................ 147
ANEXOS ................................................................................................................ 148
Caso de Estudio 1 ............................................................................................... 148
Caso de Estudio 2 ............................................................................................... 152

Caso de Estudio 3 ............................................................................................... 154
Bibliografía ......................................................................................................... 157

1
1 ASPECTOS GENERALES
1.1 Introducción
En la actualidad es de vital importancia para toda organización administrar
eficazmente sus recursos tanto materiales como humanos. De hecho, gran parte del éxito de
un negocio depende de esto. Si no planificamos será muy complicado hacer una gestión
eficaz. De aquí la importancia de una correcta y perfecta Planificación de la demanda de
producción.
Se habla de planificación de la demanda porque al conocer cuál es nuestra
capacidad de cubrir un porcentaje de mercado, establecemos la demanda real que pudiésemos
satisfacer, es decir, conocemos el esfuerzo que debemos realizar para crecer y empezar un
proceso de desplazamiento de nuestra competencia.
Se debe seguir la planificación para conseguir los objetivos planteados. KPIs que
pueden ser de crecimiento, de mantenimiento, o de cambio de nicho de mercados, por poner
algunos ejemplos. Sea cual fuere el objetivo, si lo realizamos correctamente mediante
la planificación de la demanda se traducirá en la optimización de los procesos de
producción, y por lo tanto en buena gestión de los recursos. Y conseguiremos nuestro
objetivo.
Pues bien, gracias a todo lo que ha avanzado la tecnología podemos contar con
soluciones de planificación de la demanda que nos ayudan a controlar situaciones en
los procesos de producción.
Llamamos planificación de la demanda al proceso mediante el cual una empresa
coordina, acopla y optimiza todos los elementos que intervienen de una u otra manera en la
elaboración del producto o servicio destinado a los clientes.

2
No es un proceso como cualquier otro. Es, en realidad, la suma de muchos procesos
que tienen lugar en una organización y que afecta, la calidad de los productos y de una mayor
satisfacción de los consumidores, deben mantenerse alineados o al menos bajo unas ciertas
directrices. En eso consiste todo.
La planificación de los materiales o MRP, es un sistema de planificación y
administración, normalmente asociado con un software que planifica la producción y un
sistema de control de inventarios.
Tiene el propósito de que se tengan los materiales requeridos en el momento oportuno
para cumplir con las demandas de los clientes. El MRP, en función de la producción
programada, sugiere una lista de órdenes de compra a proveedores.
Más en detalle, trata de cumplir simultáneamente tres objetivos:
- Asegurar materiales y productos que estén disponibles para la producción y
entrega a los clientes.
- Mantener los niveles de inventario adecuados para la operación.
- Planear las actividades de manufactura, horarios de entrega y actividades de
compra.
1.2 Antecedentes
1.2.1 Características
- Interfaces sencillas y amigables para los usuarios del sistema.
- Visualización de los procesos de fabricación y producción.
- Proveer Sistema de respaldos de los datos (BackUps).
- Aumento de la productividad.
- Control y seguimiento de los productos a lo largo de la producción.

3
- Acceso rápido a consultas y reportes de las distintas operaciones que realiza
el sistema.
1.2.2 Funcionalidades
Nuestro proyecto contará con los siguientes procesos principales:
PLANIFICACIÓN
Listas de materiales maestros, describe la lista de materias primas o
subproductos que se utilizan para fabricar un producto terminado. La estructura
jerárquica permite gestionar listas multinivel de materiales de varios niveles de
los materiales.
Cálculo de temporizadores. El temporizador es el corazón del
sistema del MRP en términos de planificación. Organiza las órdenes de
fabricación basadas en las prioridades (subproductos de fabricación,
fechas requeridas, etc.), lanzamientos de órdenes de compra para los
componentes que faltan y asigna productos en stock.
FABRICACIÓN
Órdenes de fabricación, describe la lista de materias primas que se
utilizarán para cada etapa de producción. La materia prima puede ser consumida
de una sola vez o de forma progresiva durante el proceso de producción. Además,
el software proporciona una gestión de desechos, la producción parcial también
es posible.
Las Órdenes de compra programarán una propuesta para la adquisición
automática del producto que necesita reposición. Esta contratación iniciará una
4
tarea, ya sea una forma de orden de compra para el proveedor, o una orden de
producción dependiendo de la configuración del producto.
Las Órdenes de trabajo son operaciones de fabricación requeridas para
producir o ensamblar productos. Las diferentes Órdenes de trabajo tienen
diferentes efectos sobre los costes de fabricación y planificación, en función de
la carga de trabajo disponible.
REPORTES
“Informe de Trabajo” será una proyección de órdenes de trabajo para
un determinado período. El informe se expresa en horas (para recursos humanos)
o ciclos (para máquinas).
“Variación del valor semanal de las existencias” permite seguir la
evolución del valor de las existencias, de acuerdo al nivel de las actividades de
fabricación (consumo de materias primas, producción de productos terminados,
estimación del valor añadido de las existencias) a medida que avanzan en el
proceso de transformación.
5
1.2.3 Prototipo Interfaz Principal
1.2.4 Resumen
El sistema MRP debe cumplir estos tres objetivos:
- Asegurar que los materiales estén disponibles para la producción y los
productos estén disponibles para su entrega a los clientes.
- Tratar de mantener los niveles de stocks de material y de producto terminado
lo antes posible.
- Planificar actividades de fabricación, órdenes de entrega y compras.

6
1.2.5 Entorno
Nuestro software será desarrollado en entorno web bajo el modelo SaaS
(Software as a Service).
Entre las herramientas serán: PHP – Laravel como lenguaje de
programación y marco de trabajo, XAMPP como plataforma de desarrollo,
MySQL como gestor de base de datos. Visual Studio Code como entorno de
programación.
1.2.6 Conclusión
Como conclusión sabemos que el objetivo final de cualquier empresa es entregar su
producto a sus clientes en el plazo de tiempo más corto posible. Y para poder conseguirlo,
es necesario algún tipo de planificación, y los softwares MRP solucionan estas tareas.
1.3 Descripción Del Problema

En la actualidad existe una amplia gama de manufacturas, cada uno de ellos maneja,
de manera independiente, estrategias de funcionamiento o políticas de negocio que le
permiten desempeñar sus funciones de forma eficiente pensando siempre en brindar un
mejor servicio. Dichas funciones deben ser bien controladas para un mejor manejo de la
información.
Las principales funciones que maneja las manufacturas son de registro inventario,
lista de materiales y producción, en las cuales se trata lograr cumplir las entregas en el
tiempo establecido con el cliente.

7
El proceso de producción inicia con una licitación por parte del cliente, el cual envía
una propuesta, cotización y planos de las piezas que necesita, ya sea por un medio impreso
o electrónico.
Una vez recibida esta solicitud, se reúne un equipo multidisciplinario (producción,
ingeniería y diseño) donde se determina la factibilidad de producir la pieza, haciendo un
análisis del diseño, proceso, materiales, capacidad y disponibilidad de planta para atender
dicha solicitud.
Para la fabricación solicitada del cliente, se elabora un control de producción
listando los componentes que intervienen en el conjunto final (producto final), mostrando
las sucesivas etapas de la fabricación. Aquella lista es precisa y completa de todos los
materiales y componentes que se requieren para la fabricación del producto final. El
registro de cada componente o material que interviene se le asigna un código que lo
identifique, y a cada elemento se le asigna un nivel (en forma descendente). De forma que
el producto final le corresponde el nivel cero. Los componentes o materiales que
intervienen son de nivel uno. Esta información es representada en forma de árbol, en el cual
cada material o componente puede está formado por varios elementos de un nivel inferior.
Se le asigna una ruta de fabricación que interconecta todos estos elementos, desde el nivel
más bajo (materias primas) hasta el producto más alto (producto final), a ello se les asigna
tiempos y cantidades.
La manufactura trabaja con distintas marcas de productos y/o insumos. Maneja un
registro de todos aquellos productos y/o insumos identificados por código. Estos son
agrupados Tipo de Producto, Número de Referencia, Ubicación. El registro de un nuevo
producto, el supervisor se encarga de asignar el código, tiempo de suministro, un stock de
seguridad, el tamaño de lote. También se encarga de recoger las cantidades de cada planta
8
que están disponibles o en curso de fabricación, este último la fecha de recepción de las
mismas.
De ser aprobada la pieza, se envía al cliente una cotización de la misma para que él
autorice su fabricación.
El primer proceso es el de diseño, donde se convierten los planos de las piezas
enviados por los clientes; luego se analizan los herramentales disponibles y faltantes, y se
diseñan las transformaciones de la pieza inicial en cada una de las máquinas por donde ésta
pasará.
El siguiente proceso es el de Ingeniería en el cual se recibe lo formulado por el
proceso de diseño y se establece la logística de producción, es decir, se definen actividades
complementarias necesarias para prever posibles fallos en el desarrollo del proceso de
producción (zonas de almacenamiento y espera).
Luego de definir el flujo de la pieza dentro de la planta, se procede a fabricar
aquella pieza.
El último proceso es el de control de calidad, donde se hace una inspección de la
totalidad de los lotes, haciendo para cada uno de estos un muestreo donde aleatoriamente se
verifica que la pieza cumpla con los requisitos de calidad establecidos por la compañía. El
área de aseguramiento de calidad tiene total autonomía, responsabilidad y apoyo para
detener por razones de control y aseguramiento cualquier material en recepción (productos
para los que se subcontrata alguna operación), producción y despacho que no cumpla con
los requerimientos de calidad exigidos.
Una vez realizada esta inspección, los productos se almacenan para posteriormente
ser despachados.
9
1.4 Formulación Del Problema

Diseñar un sistema de planificación de recursos de fabricación, que facilite la
organización y planificación de la producción útil para cualquier empresa que elabore
productos y/o servicios, con el fin de reducir las deficiencias de la organización.
1.5 Objetivos
1.5.1 Objetivo General
Desarrollar un Sistema de Información para la Planificación de recursos de
fabricación.
1.5.2 Objeto Especifico
• Recolectar información de empresas dedicadas a la producción que tienen

experiencia en la aplicación y uso de los sistemas MRP.
• Analizar las políticas de negocio de los Casos de Estudio teniendo en claro el
ámbito de trabajo.
• Identificar los requisitos funcionales del sistema a través de un análisis en
profundidad de los Casos de Estudio.
• Realizar el análisis de que lenguaje de programación será utilizado para
desarrollar el sistema.
• Diseñar e implementar una base de datos en el sistema gestor de base de datos
MySQL.
• Diseñar una interfaz gráfica que guie intuitivamente al usuario en el proceso de
Gestión de Expedientes, la cual será implementada en el lenguaje de
programación HTML y PHP en la parte web.
• Implementar el sistema en un lenguaje de programación según previo análisis.
• Realizar las pruebas necesarias para justificar el buen funcionamiento del sistema
y/o encontrar posibles fallas y luego eliminarlas.
10
1.6 Alcance
En este sistema MRP contará con los siguientes puntos:
Requisitos Funcionales:
• Gestionar lista de materiales
Nos permitirá hacer seguimiento de la lista de materias primas y/o subproductos
que se llegan a usar y/o se utilizan para fabricar un producto final. Funciones
básicas como:
- Crear Nuevo Producto

Formulario de registro de un producto con código y descripción corta.
- Asignar Componentes
Permite asignar los componentes a un producto si existiese componentes
hijo.
• Gestionar inventario
Nos permitirá hacer seguimiento continuo de todos los insumos y/o productos
que cuente la empresa.
- Registrar almacén
- Asignar productos
El inventario se tomará en cuenta en algunos casos la retro alimentación de los
mismos insumos, en casos en que los insumos no se acaben (como la
construcción de una pieza de una mesa, existen sobras de madera), de modo que
se registrarán como insumos sobrantes o nuevos.

11
• Gestionar reintegro
El inventario se tomará en cuenta en algunos casos la retro alimentación de los
mismos insumos, en casos en que los insumos no se acaben (como la
construcción de una pieza de una mesa, existen sobras de madera), de modo
que se registrarán como insumos sobrantes o nuevos.
• Gestionar orden de producción (fabricación*)
Permitirá describir y detallar la lista de materias primas que se utilizarán para
cada etapa de producción. La materia prima puede ser consumida de una sola
vez o de forma progresiva durante el proceso de producción.
• Gestionar orden de compra
Se listará y se programarán una propuesta para la adquisición automática del
producto que necesita reposición. Esta contratación iniciará una tarea, ya sea una
forma de orden de compra para el proveedor, o una orden de producción
dependiendo de la configuración del producto.
• Gestionar reporte
Será una proyección de órdenes de trabajo para un determinado período. El
informe se expresa en horas (para recursos humanos) o ciclos (para máquinas).
• Gestionar cliente
Nos permitirá obtener la información personal del cliente como ser: Nombre,
12
CI, Dirección, Teléfono, Correo Electrónico. Si se tratase de una empresa se
obtendrá información adicional: NIT, Ubicación (GPS) e información del
titular o encargado de la misma.
• Gestionar proveedor
Nos permitirá obtener la información personal del proveedor como ser:
Nombre, Dirección, Teléfono, Correo Electrónico. Si se tratase de una
empresa se obtendrá información adicional: Ubicación (GPS) e información
del titular o encargado de la misma.
• Gestionar empleado
Nos permitirá obtener la información personal del proveedor como ser:
Nombre, Dirección, Teléfono, Correo Electrónico.
• Gestionar materia prima
Son los registros de toda la materia prima o componente con la cual se fabrica
un artículo ya sea una descripción, tipo o nivel.
• Gestionar orden de aprovisionamiento
Esta Orden de Aprovisionamiento realizada por el encargado del almacén
especifica el producto y las cantidades que hagan falta en stock para la
producción de un artículo, dirigida a los proveedores.
• Gestionar línea de producción
Es la ruta que sigue la construcción o fabricación que sigue un artículo,
también denominado fases de fabricación, tomando como ejemplo la
fabricación de una mesa entre sus niveles estaría: diseño, fabricación de

13
piezas, ensamblado y pintura. Se registrará los procesos o niveles, tiempo total
de la línea y seguimiento de producción.
• Gestionar tiempo laborado
Nos permitirá registrar el tiempo (minutos) que tarda cada proceso o nivel de
una línea de producción.
• Gestionar planificación de producción
La planificación de producción realizada por cada pedido del cliente esta
registra la cantidad del artículo que se desea, el tiempo que tardara en
fabricarse, la fecha aproximada de entrega y una planificación diaria de las
cantidades a producir.
• Gestionar seguimiento de producción
Nos permitirá realizar un seguimiento a un Plan de Producción registrando
observaciones en cada proceso diariamente, ya sea factores internos o
externos de la empresa.
• Gestionar articulo
El artículo es el producto final terminado denominado también como padre,
aunque también estos productos pueden usarse como componente de otros. Se
registrarán el nombre, tipo de producto, precio de compra-venta y proveedor.
• Gestionar almacén
Se registrarán el nombre del almacén dirección y ubicación (GPS) así como el
municipio o estado que se encuentra.
• Gestionar entrega de trabajo

14
Son registros de todas las salidas de materia primas y/o componentes que serán
utilizadas dentro de una Orden de Trabajo. Están serán especificadas en que
cantidad y a que producto serán utilizadas.
• Gestionar departamento
Se registrará información de los departamentos que tiene la empresa como
ser: nombre del departamento, número de trabajadores y encargado.
• Gestionar área
Se registrará información de las áreas que tiene cada departamento como ser:
nombre del área, departamento al que pertenece, número de trabajadores y
encargado.
• Gestionar orden de transferencia
Una Orden de Transferencia se refiere a la transferencia o traspaso, ya sea de
un artículo o materia prima que se realiza de un almacén a otro. Registrando la
cantidad el artículo y/o materia prima el almacén origen y destino.
• Gestionar proceso
Se refiere a una fase de producción, tomando como por ejemplo la
fabricación de una mesa una fase sería la de ensamblado de la mesa. Se
registrará el nombre del proceso, los materiales necesarios para completar la
fase, el tiempo que durará este proceso y observaciones del mismo.
• Gestionar sucursal
Se registrará información de las sucursales que tiene la empresa como ser:
nombre de la sucursal, dirección de la sucursal, número de trabajadores y
encargado.
15
• Gestionar Usuario
Carga, seguimiento y mantenimiento de los distintos usuarios que están directa o
indirectamente relacionados con el sistema. Se les asignará una clave de acceso
y ciertos permisos de acceso al sistema según lo estipule las políticas del
negocio de la empresa. Estas serían el caso del administrador y el supervisor.
Funciones básicas como:
- Crear nuevo usuario
- Actualizar datos de usuario
- Eliminar usuario
- Asignar cargo
- Asignar privilegios
• Gestionar orden de trabajo
Son operaciones de fabricación requeridas para producir o ensamblar productos.
Las diferentes Órdenes de trabajo tienen diferentes efectos sobre los costes de
fabricación y planificación, en función de la carga de trabajo disponible.
1.7 Metodología
Los sistemas MRP son sistemas de información robustos, desarrollados por
metodologías de media a gran escala.
La metodología Scrum es una alternativa positiva, Scrum es un marco de trabajo
ágil que permite que sistemas robustos como MRP sean desarrollados en un tiempo más
reducidos, comparado con las otras metodologías.

16
Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las
personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental
basada en iteraciones y revisiones.
La metodología Scrum cuenta con un equipo de trabajo conformador por: Master
Scrum, Development Team y Product Owner.
El proyecto tomará al azar un Master Scrum (sólo puede ser uno), un Equipo de
Desarrollo (2 o más), y un Product Owner.
El Product Owner gestiona y optimiza el valor del producto, todo ello a través del
Product Back log. Es responsable de conocer todo, generalmente es el dueño del producto a
desarrollar, por lo tanto, será exigente en dar máximo valor al producto en todo.
El Master Scrum gestiona la labor del Equipo de Desarrollo, y facilitar la ejecución
del proceso y sus mecánicas dentro del marco de trabajo. Y facilita las reuniones y eventos
si es necesario.
17
El equipo de trabajo son los encargados de desarrollar el producto, se auto
organizan y deciden cual es la mejor manera de conseguir entregar un incremento de
software al final del ciclo de desarrollo.
Para llevar a cabo cualquier sistema de información, se debe tener un Product
Backlog, que nos permite conocer todas las tareas, casos de usos, requerimientos,
dependencias, todas ellas están representadas en el Product Backlog y este es la fuente
principal de información sobre el producto en Scrum.
Con el Product Backlog, podemos llegar a tener Sprint, un evento a partir de lo
anteriormente mencionado. Un Sprint es un evento de un periodo fijo, con un listado de
tareas (sacadas del Product Backlog) que serán desarrollados dentro del periodo fijo.
Luego surge el Sprint Planning es una reunión que se realiza al comienzo de cada
Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el producto
Backlog y que el equipo de desarrollo seleccione los Product Backlog Ítems en los que va a
trabajar durante el siguiente sprint. Durante esta reunión el Product Owner presenta el
Product Backlog actualizado, que el equipo de desarrollo se encarga de estimar, además de
intentar clarificar aquellos ítems que crean necesarios.
Después, El Sprint Review es una reunión que ocurre al final del Sprint, donde el
Product Owner presenta a los Stakeholders el Incremento terminado para su inspección y
adaptación. Esta reunión, organizada por el Product Owner, es el momento de medir cual es
la situación y actualizar el Product Backlog con nuevas condiciones que puedan afectar al
negocio.
18
El Sprint Review marca la finalización de un Sprint. se revisará el incremento
terminado. Se mostrará el software funcionando en producción y los Stakeholders tendrán
la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El Software
funcionando ha sido validado previamente por el Product Owner, que se ha encargado de
trabajar con el equipo durante el Sprint para asegurarse que cumple con la Definition of
Done y efectivamente hace que el Sprint Goal sea válido. Si no existe software
funcionando, no hay que hacer Sprint Review
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En ella
se hacen transparentes los problemas del equipo y se llegan a acuerdos para solucionarlos.
También se inspecciona y adapta la Definition of Done

19
2 ELEMENTOS DEL SISTEMA BASADO EN COMPUTADORAS
2.1 Hardware
2.1.1 Servidor
NOMBRE VERSION CARACTERISTICA

PROCESADOR Intel Core i5 4460 3 GHz
MEMORIA RAM Kingston ValueRAM DDR3 4GB
DISCO DURO DEL S.O. Hitachi 2.5 Pulg. 5400 rpm 500 GB
DISCO DURO DE Western Digital SE 3.5Pulg 4 TB – SATA 6GB/s –
ALMACENAMIENTO 128MB C.
PLACA BASE AsRock B75M-ITX – Integrada Compatible Windows
8
FUENTE DE CorSair VS450 12Voltios - 450 Watts
ALIMENTACION
CAJA DE SERVIDOR Fractal Design Node 304 6 discos Duros
MONITOR VGA análogo 20’’
UPS APC Smart-UPS 5000VA Duración 14.3 Hrs
2.1.2 Cliente
NOMBRE VERSION CARACTERISTICA

PROCESADOR INTEL CORE I5-7200U 3M CACHE – 3.10 GHZ
MEMORIA RAM KINGSTON DDR3 4GB
TARJETA DE VIDEO NVIDIA GE FORCE GTX 2GB
750 TI
DISCO DURO W ESTERN DIGITAL 1.5 TB
PLACA BASE ASROCK Z77 EXTREME4- COMPATIBLE W INDOWS 8
M
ESTABILIZADOR ATOMLUX MODELO R1000 1000VA – 2 EQUIPOS
CASE DELUX COMBO CASE
MONITOR S AMSUNG LED – 21’’
IMPRESORA CANON MULTIFUNCIONAL WEB HP O FFICE JET 4630
2.1.3 Medios de Comunicación
Debido a que todos los procesos de los distintos departamentos, requieren de una
integra comunicación y colaboración en conjunto, estas actividades deben realizarse en un

20
ambiente común dentro de la misma empresa (en una ubicación físicamente fija) es
necesario conexión de red interna.
2.1.4 Otros Dispositivos
Impresoras
Dispositivos móviles
Lector de huellas
Lector de QR
2.2 Software
2.2.1 Servidor
DESCRIPCIÓN VERSIÓN
SISTEMA OPERATIVO W INDOWS S ERVER 2012 R2
GESTOR DE BASE DE DATOS MySQL
ANTIVIRUS WINDOWS DEFENDER
2.2.2 Cliente
NOMBRE VERSION
SISTEMA OPERATIVO W INDOWS 10
GESTOR DE BASE DE DATOS MySQL
ANTIVIRUS WINDOWS DEFENDER
2.2.3 Otro software adicional
Herramientas y paquetes de Microsoft Office.
Lector de documento PDF.
Navegadores Web.
21
2.3 Datos
DESCRIPCIÓN LOS DATOS A MANEJARSE SERÁN :
USUARIO - Login
- Password
ORDENES DE - Nombre de referencia

PRODUCCIÓN - Fecha Programada
- Responsable de Orden
- Ubicación de Producción
- Producto
- Cantidad de Producto
- Estado (Nuevo, En Espera)
PLANIFICACIÓN DE LA - Nombre de referencia de Orden
ORDEN - Fecha
- Estado de Orden
PRODUCTO - Código (Identificador)

- Nombre Comercial
- Tipo de Producto (Almacenable, Consumible,
Servicio)
- Número de Referencia
- Precio de venta
- Garantía
- Ubicación (abastecimiento, producción,
inventario)
ABASTECIMIENTO - Nombre del Almacén (Identificador)
- Nombre Corto
- Dirección
- Teléfono
- Email
- Ruta
DETALLE DE - Entrega id (Identificador)
ENTREGA - Fecha de Entrega
- Nota
- Vigencia
- Cantidad
INVENTARIO - Cantidad a mano
- Entrada (abastecimiento)
- Estado
- En desarrollo
- Normal
- Fin de ciclo de vida
- Obsoleto
- Responsable de producto
- Ubicación
- Estante
22
- Fila
- Caja
23
2.4 Procesos
NOMBRE DESCRIPCIÓN
PROCESO DE Una lista de materiales es un documento que define la
REGISTRO DE LISTA cantidad de cada componente requerido para fabricar un

DE MATERIALES producto terminado. También incluye el enrutamiento y los
pasos individuales del proceso de fabricación.
PROCESO DE En el momento que la empresa reciba una orden o
REGISTRO DE ORDEN pedido de algún cliente, se procederá a registrar como orden

DE PRODUCCIÓN
de producción con su respectiva fecha programada, y
responsable de producción.
El plan de orden de producción deberá tener en detalle
de cada uno de los ítems que han de ser fabricados,
especificando cantidades y fechas, y posteriormente para
establecer el programa detallado de fabricación.
PROCESO DE En el momento de llegar ordenes de producción se
PLANIFICACIÓN activará la planificación que dispondrá de un calendario por
día, mes o año de todas las tareas que tenga la empresa.
PROCESO DE Se verifica los productos disponibles dentro de la
INVENTARIO empresa con énfasis en el control ubicaciones, la cantidad de
stock, el estado, etc., de los productos.
PROCESO DE Puede usar productos de sub-ensamblaje para
PRODUCTOS simplificar una lista de materiales compleja o para representar

SEMIACABADOS su flujo de fabricación con mayor precisión. Un producto de
24
sub-ensamblaje es un producto fabricado que se utiliza como
componente para fabricar otro.
2.5 Gente / Usuario

GERENTE
Para el funcionamiento de este sistema y la simulación de algunas actividades,
existirá una cuenta interna en la base de datos privilegios. Al iniciar sesión como gerente,
se podrá crear las cuentas para administradoras.
ADMINISTRADOR
Las administradoras tendrán cuentas de sesión del Tipo Administrador, que les
otorgara acceso a todas las funciones del Sistema, excepto a la Opción de Creación de
Cuenta de Administradoras, estos son los encargados de cada sector de la empresa.
SUPERVISOR
Personal que trabaja dentro de las instalaciones de la subsidiaria más precisamente
los almacenes en labores de control y supervisión de productos paquetes y entrega.
2.6 Documento
La documentación se refiere a los diferentes manuales y políticas de manejo y uso
del sistema, que el desarrollador del software entrega o dota al usuario de dicho sistema.
La documentación es el respaldo del sistema, todo sistema debe tener
documentación.
En nuestro caso se implementarán la siguiente documentación al cabo de terminado
el sistema:
Manual del usuario:

25
Es documento de comunicación técnica destinado a dar asistencia a las personas que
utilizan un sistema en particular, contiene tanto una guía escrita como imágenes asociadas.
Como por ejemplo capturas de pantalla de cómo funciona el sistema detalladamente y
sencillamente para llevar a cabo las distintas opciones del sistema.
Tutoriales:
Se describe en detalle el objetivo que presenta el sistema, que está orientado a un
mejor manejo y facilidad de uso por parte de la empresa a quien va dirigido.
Capacitación (cursos de manejo):
Se podrá dotar de cursos presenciales para el manejo del sistema a todos los
gerentes, empleados y usuarios. Para como también se puede recurrir a la web, de acuerdo a
la disponibilidad de tiempo del que disponen los interesados.

26
3 TECNOLOGÍA PARA EL DESARROLLO DEL SOFTWARE
3.1 Estrategia para el desarrollo del software

Se utilizará el proceso unificado de desarrollo de software (SCRUM), el cual es un
marco de trabajo y de actividades necesarias para transformar los requisitos de un usuario
en un sistema de software, el proceso unificado es más que un simple proceso, es un marco
de trabajo genérico que puede utilizarse para una gran variedad de sistemas software, para
diferentes áreas de aplicación, diferentes tipos de organizaciones. Diferentes niveles de
aptitud y diferentes tamaños de proyectos.
3.2 Metodología para el desarrollo del software

3.2.1 Características de la metodología SCRUM
Scrum es un marco de trabajo para desarrollo ágil de software.
Este marco de trabajo define un conjunto de prácticas y roles, que son tomados como
punto de partida para definir el proceso de desarrollo en el que se ejecutará un proyecto.
Se presentó en 1995 y hoy en día, y más del 70% de los equipos de desarrollo de
software en el mundo lo usan. Scrum es simple pero no es fácil, las compañías que
consiguen implementarlo, consiguen mejoras de 4 a 10 veces en productividad, tiempos de
respuestas y competitividad.
La metodología se basa en:
• El desarrollo incremental de los requisitos del proyecto en bloques temporales
cortos y fijos.
• Se da prioridad a lo que tiene más valor para el cliente.
• El equipo se sincroniza diariamente y se realizan las adaptaciones necesarias.

27
• Tras cada iteración (un mes o menos entre cada una) se muestra al cliente el
resultado real obtenido, para que este tome las decisiones necesarias en
relación a lo observado.
• Se le da la autoridad necesaria al equipo para poder cumplir los requisitos.
• Fijar tiempos máximos para lograr objetivos.
• Equipos pequeños (de 3 a 9 personas cada uno).
Sus características principales de Scrum:
• Gestión regular de las expectativas del cliente, resultados anticipados,
flexibilidad y adaptación, retorno de inversión, mitigación de riesgos,
productividad y calidad, alineamiento entre cliente y equipo, por último,
equipo motivado.
• Se hace uso de equipos autodirigidos y autoorganizados.
• Se realiza a diario una reunión de Scrum, que es una reunión de avance
diaria que no dura más de 15 minutos con el objetivo de obtener
realimentación sobre las tareas del equipo y los obstáculos que se presentan.
Imagen del Flujo de trabajo de la metodología Scrum.

28
3.2.2 Características de UML
UML (Lenguaje Unificado de Modelado) es un lenguaje para hacer modelos y es
independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un
método y un lenguaje de modelado. Un método es una manera explícita de estructurar el
pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué
hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos
son utilizados para describir algo y comunicar los resultados del uso del método.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son
los elementos de modelo que representan conceptos comunes orientados a objetos, tales
como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la
asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios
diagramas diferentes, pero siempre tiene el mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o
semántica acerca del elemento de modelo; además proveen mecanismos de extensión para
adaptar o extender UML a un método o proceso específico, organización o usuario.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista.
UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas
las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de
secuencia, de colaboración, de actividad, de componentes y de distribución.
Estos diagramas se pueden diferenciar en tres categorías:

29
Diagramas de Diagramas de Diagramas de

Estructura Comportamiento Interacción
Diagrama de Clases Diagrama de Actividades Diagrama de Secuencia
Diagrama de Componentes Diagrama de Casos de Uso Diagrama de Comunicación
Diagrama de Objetos Diagrama de Estados Diagrama de Tiempos
(UML 2.0)
Diagrama de Estructura Diagrama de Vista de
Compuesta (UML 2.0) Interacción (UML 2.0)
Diagrama de Despliegue
Diagrama de Paquetes
3.3 Herramientas de desarrollo

3.3.1 Software
Para el desarrollo de este sistema utilizaremos los siguientes softwares:
Descripción Versión
Sistema operativo Windows 10
Gestor de base de datos MySQL W ORKBENCH 5.4
Lenguaje de programación PHP, HTML
Plataforma de desarrollo XAMPP
Plataforma de modelado visual ENTERPRISE ARCHITECT V10.0
3.3.2 Hardware
El hardware que se utilizó para desarrollar el sistema tiene las siguientes
características:
30
Descripción Versión
Procesador Intel Core i7-2.50GHZ
Tarjeta madre AsRock 960GM-VGS3 FX
Memoria RAM Kingston 8 GB
Disco duro Toshiba 1 TB
Monitor Samsung 21’’
Impresora Canon MP 280

31
4 POSIBLES COSTOS
ÍTEM COSTO (USD$)
Hardware y activos fijos
Procesador Intel Core i7-2.50GHZ 322.00
Tarjeta madre AsRock 960GM-VGS3 FX 42.00
Memoria RAM KingstoneDDR3 8GB 41.99
Disco duro Seagate HDD 57.00
Monitor Samsung LED 21’’ 129.00
Impresora CANON TS3150 99.00
Escritorio 60.00
Varios 30.00
Software y Licencias
Windows 10 Pro C/Licencia 289.00
Enterprise Architect 13.0 135.00
MySQL Workbench Standard C/Licencia 500.00
ESET INTERNET SECURITY 59.99
Implementación y desarrollo
Implementación y prueba del sistema 350
Tiempo invertido 1000
TOTAL 3114.98
32
5 POSIBLES BENEFICIOS
5.1 Tiempo
Interfaces sencillas y amigables para los usuarios del sistema.
Disminución de los tiempos de espera en la producción y en la entrega.
Aumento de la productividad.
5.2 Esfuerzo
Optimización de los procesos de producción.
Disminución de inventarios
Impedir la duplicación de información.
Mayor Control y seguimiento del producto.
5.3 Costos
Gracias a la combinación de las ventajas de tiempo y esfuerzo se verá resultados
positivos en costo de producción. Visualizados en:
Acceso rápido a consultas y reportes de las distintas operaciones que realiza el
sistema.
Reportes visuales sencillas e intuitivas, que harán énfasis en la reducción de costos.
6 POSIBLES CLIENTES
Los sistemas MRP están pensados para aquellos clientes que produzcan un bien o
servicio dentro de su empresa, como vendrían a ser las manufactureras que realizan trabajos
especiales de bienes de capital, sistemas eléctricos, válvulas de alto rendimiento, o las
manufactureras que deben entregar en tiempos más cortos por mencionar algunas son las
que más se ven beneficiadas con la implementación del MRP.

33
7 MODELO DE DOMINIO
class Modelo de Dominio
Encargado
- codigo: varchar
1 - email: varchar
- id: int
1 - nombre: varchar
- telefono: int
Cliente
- codigo: varchar Direccion Pais

- email: varchar
- id: int - codigo: varchar - codigo: varchar
Telefono 1 1 - descripcion: varchar - id: int
- nit: int
- codigo: varchar - nombreComercial: varchar - id: int - nombre: varchar
- id: int 1..* 1 - razonSocial: varchar 1..* 1
- nro: int
1 1..*
1
Poblacion Prov incia
- codigo: varchar - codigo: varchar

- descripcion: varchar 1..* 1 - descripcion: varchar
- id: int - id: int
1..*
OrdenEntrega
OrdenProduccion OrdenTrabaj o - codigo: varchar
1..* 1 1 - fecha: date 1
- codigo: varchar - codigo: varchar PlanProduccion - id: int
- descripcion: int - descripcion: varchar
1..* - - codigo: varchar - total: float
estado: varchar 1..* 1 - fecha: date
- id: int - id: int - descripcion
1 1 - fechaElaboracion Proceso
- id: int
1 - cantidad: int
1..* - codigo: varchar
DetalleTrabaj o - costo: float
1 - descripcion: varchar
- cantidad: int - id: int
- id: int - tiempoCreacion: float
1..*
1..*
1
1 1
Producto
Modelo ListaMateriales Ruta
- codigo: varchar
- codigo: varchar - compra: float - cantidadFabricacion: int - codigo: varchar
- descripcion: varchar 1 0..* - id: int 1 1..* - cantidadUso: float 1..* 1 - descripcion: varchar
- id: int - nombre: varchar - id: int - id: int
- precioVenta: float
1..*
1..* 1
Empleado
- cargo: varchar
1..
- codigo: varchar
1 - id: int
Fila 1 Prov eedor
- nombre: varchar
- telefono: int - codigo: varchar - ciudad
MateriaPrima
- descripcion: varchar CatalogoProv eedor - codigo
- id: int - codigo: varchar - direccion
- compra: float - estado: varchar
1 1 1..* - id: int 1..* 1 - nit
- id: int - nombre
- nombre: varchar - tiempoEspera: float
- telefono
1..* 1
Almacen Ubicacion
- codigo: varchar - id: int DetallePedido

- descripcion: varchar
1 1..*
- id: int - cantidad: int
1..*
- nroAlmacen: varchar 1..* - id: int
- subtotal: float
1..*
1
1
Estante
- codigo: varchar OrdenPedido

- id: int - codigo: varchar
Estado de la orden:
- estado: varchar
DetalleDiaria * En Espera
- fechaEntrega: date
* Entregado
- cantidad: int - fechaPedido: date
* Cancelado
1 - id: int - id: int
1..*
- total: float
1
1..*
ProduccionDiaria Inv entario
- codigo: varchar 1..* - id: int

- descripcion: varchar - stock: int 1..*
- fecha: date
- id: int
34
CAPITULO 1 MARCO TEÓRICO

35
8 METODOLOGIA AGIL
8.1 Propósito de Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible
de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un
estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al
cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la
calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia,
cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y
solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.
8.2 Visión General de Scrum

Un marco de trabajo por el cual las personas pueden acometer problemas complejos
adaptativos, a la vez que entregar productos del máximo valor posible productiva y
creativamente. Scrum es:
• Ligero
• Fácil de entender
• Extremadamente difícil de llegar a dominar
36
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el
desarrollo de productos complejos desde principios de los años 90. Scrum no es un proceso
o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del
cual se pueden emplear varias técnicas y procesos. Scrum muestra la eficacia relativa de las
prácticas de gestión de producto y las prácticas de desarrollo, de modo que podamos
mejorar.
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos
y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito
específico y es esencial para el éxito de Scrum y para su uso.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las
relaciones e interacciones entre ellos. Las reglas de Scrum se describen en el presente
documento.
Las estrategias específicas para usar el marco de trabajo Scrum son diversas y están
descritas en otros lugares.
8.3 El Equipo Scrum (Scrum Team)

El Equipo de Scrum está comprendido por:
8.3.1 Product Owner (dueño del producto):
A veces es el mismo cliente. En otros casos, especialmente cuando se trata de
proyectos complejos, actúa como su representante directo, el de los usuarios del producto y,
en general, el de todas aquellas partes que tengan algún interés en él. Es el único con la
potestad para decidir las funcionalidades y características del producto.
Tiene un diálogo directo y permanente con el Scrum Máster, que es su nexo directo
con quienes ejecutan las labores. Sólo entra en contacto con el Scrum Team al final de cada
una de las iteraciones para evaluar las entregas parciales.

37
8.3.2 Scrum Máster (director o figura visible del proyecto):
Es el encargado de garantizar que el proceso cumplirá con las directrices del modelo
Scrum. Muchos lo denominan líder de proyecto, pero en realidad es mucho más que eso. Es
el encargado de mantener una visión global del mismo y de emplearse a fondo ante cualquier
circunstancia, sea la que sea. Además, fluctúa entre el plano práctico y el plano directivo; es
decir, interactúa de igual manera con el Product Owner y con los integrantes del Scrum Team
que están a su cargo.
8.3.3 Scrum Team (equipo de trabajo):
Hace referencia al grupo de personas que ejecuta las tareas propuestas. Aquí entran
tanto los arquitectos, ingenieros, programadores, diseñadores y demás profesionales como
las personas que realizan labores administrativas.
Es posible que dentro del Scrum Team surja algún líder o primer responsable;
cuando no es así, esta labor la asume el Scrum Máster. En cualquier caso, es importante que
sus integrantes definan los roles de equipo. Su relación con el Product Owner se reduce a la
presentación de los resultados de cada iteración.
8.4 El Dueño de Producto (Product Owner)

Las responsabilidades del Cliente / Product Owner (que puede ser interno o externo
a la organización que realiza el desarrollo del producto) son:
• Conocer el mercado y los comportamientos de los clientes / usuarios finales, con muy
buena visión de Negocio.
• Ser el representante de todas las personas interesadas (Stakeholders) para conseguir
una buena definición de los objetivos del producto o proyecto y de los resultados
esperados.
• Las “personas interesadas” pueden ser internas o externas a la organización:
promotores del proyecto y usuarios finales.
38
• Idealmente el Product Owner también debería ser algún tipo de usuario, un

consumidor final del producto, para poder experimentar directamente si se consiguen
los beneficios que hipotéticamente le debería aportar.
• Encargarse de que exista una priorización clara del trabajo a hacer. De este modo,
dirige los resultados del proyecto para maximizar su ROI (Return Of Investment):
• Es el propietario de la planificación del proyecto: crear y mantener la lista priorizada
con los requisitos necesarios para cubrir los objetivos del producto o proyecto,
conocer el valor que aportará cada requisito y calcula el ROI a partir del coste de cada
requisito (estimación que le proporciona el equipo).
• Repartir los objetivos/requisitos en iteraciones, de manera que prioriza tanto el
proporcionar beneficios al usuario final como reducir riesgos respecto hipótesis) y
establece un calendario de entregas.
• Antes de iniciar cada iteración, re planificar el proyecto en función de los requisitos
que aportan más valor en ese momento, de los requisitos completados en la iteración
anterior y del contexto del proyecto en ese momento (demandas del mercado,
movimientos de la competencia, etc.).
• Actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones
(es decir, con libertad para decidir qué hacer de manera alineada con los objetivos de
su área de trabajo, que no se vea invalidada por personas en una posición superior).
Colaborar con el equipo para planificar, revisar y dar detalle a los
objetivos de cada iteración:
• Participar en la reunión de planificación de iteración, proponiendo los requisitos más

prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los
requisitos que el equipo se comprometer a hacer.
• Estar disponible durante el transcurso de la iteración para responder a las preguntas
que puedan aparecer.
• No cambiar los requisitos que se están desarrollando en una iteración, una vez está
iniciada.
• Participar en la reunión de demostración de la iteración, revisando los requisitos
completados.
39
• Proporcionar suficiente dedicación para hacer este trabajo (usualmente un Product

Owner no suele poder estar con más de 1-2 equipos, en función del tipo de producto
y equipos).
• Notar que una distancia de 3-5 metros del equipo puede llegar a ser una barrera
demasiado alta para interactuar de manera ágil con el equipo (a menos que se
encuentre físicamente en otra ciudad). Sería difícil de justificar que el Product Owner
esté situado en la misma ciudad y no esté la mayor parte del tiempo sentado con sus
equipos.
Por ello, una buena selección de Product Owner (y un esfuerzo especial en su
coaching de Producto/Cliente) es fundamental para un inicio de transformación ágil
exitoso, es decir, aportar resultados a la empresa de manera más ágil.
8.5 El Equipo de Desarrollo (Development Team)

El equipo en Agile incluye al Cliente / Product Owner y al Facilitador / Scrum
Master. Cuando se habla específicamente de “equipo de desarrollo” se refiere al conjunto
de personas más ‘técnicas’ que de manera conjunta desarrollan el producto del proyecto.
Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así como
de su calidad) en cada iteración y en el proyecto.
Para ir alcanzando un estado de alto rendimiento, este equipo es:
8.5.1 Multidisciplinar.
Agile se basa en ir desarrollando un producto “tangible” de forma iterativa para
obtener FeedBack en intervalos cortos de tiempo sobre si el producto genera en el cliente el
resultado esperado. Para ello, idealmente el equipo no debe depender de otros pues
generaría esperas y retrasos en la entrega de valor (necesidad de coordinación, integración e
incluso falta de ownership), con lo cual sólo se puede hacer con equipos multidisciplinares
y autónomos del resto de la organización. De este modo:

40
o Los miembros del equipo disponen de las habilidades necesarias para poder
identificar y ejecutar todas las tareas que permiten proporcionar al cliente los
requisitos previstos en la iteración.
o Tienen que depender lo mínimo de personas externas al equipo, de manera que no se
ponga en peligro la previsión del trabajo a revisar al final de cada iteración.
o Se crea una sinergia que permite que el resultado sea más rico al nutrirse de las
diferentes experiencias, conocimientos y habilidades de todos, “colaboración
creativa”.
El equipo de desarrollo ágil en ocasiones es llamado Squad al englobar, con una
visión más amplia, cualquier Skill o rol necesario para incluir toda la cadena de valor
dentro del equipo, de modo que todos sus miembros están guiados por el mismo propósito,
conocen al cliente, el dominio y definen conjuntamente problema a solucionar. En función
de las necesidades para desarrollar el producto, el Squad puede incluir a desarrolladores,
UX, Ops, Data, … y, por supuesto, al Product Owner y al Scrum Master.
8.5.2 Tamaño de equipo de 5 a 9 personas.
Para ser ágil, el tamaño del equipo está entre 5 y 9 personas.
✓ Por debajo de 5 personas cualquier imprevisto o interrupción sobre un miembro

del equipo puede comprometer seriamente la previsión de objetivos a mostrar al
cliente / Product Owner al finalizar la iteración.
✓ Por encima de 9 personas, la comunicación y colaboración real entre todos los
miembros se hace más difícil y se acaban formando subgrupos, donde todo el
mundo no está interesado por los mismos objetivos del Sprint (ver los requisitos
de Scrum).
De cualquier manera, se puede trabajar en Scrum con 3 personas y se ha utilizado en
proyectos con centenares de personas, agrupadas en varios equipos. Cuando es necesario
que más de un equipo trabaje de manera ágil en un mismo producto/proyecto, existen
diferentes técnicas que permiten esta colaboración (sincronización regular entre Product
41
Owner; Scrum de Master entre miembros de los equipos; ajustes de las reuniones de Scrum
para hacer algunas más generales/comunes y poder gestionar dependencias conjuntas
[como si se tratase de un fractal de reuniones], siempre completando incrementos de
producto de manera regular. De cualquier modo, hay que recordar que el objetivo final es
conseguir que cada equipo sea el máximo de independiente de los otros para realmente
poder ágiles.
8.5.3 Estable y dedicado.
• Los equipos ágiles trabajan en iniciativas estratégicas (que se mantienen en el tiempo)

o bien van repitiendo tipos de proyectos similares (van ajustando su misión como
equipo). Un equipo de alto rendimiento cuesta tiempo conseguirlo (y después hay que
aprovechar esa performance), es un activo fundamental para la empresa y su building
block básico, con lo cual prevalecerá el interés por mantenerlo por encima de
desmantelarlo.
• Dado que el equipo debe ser estable, sus miembros deben cambiar lo mínimo posible,
para poder aprovechar el esfuerzo que les ha costado construir sus relaciones
interpersonales, engranarse y establecer su organización del trabajo.
• Los miembros del equipo están dedicados a tiempo completo a esa iniciativa o
proyecto, para evitar dañar su productividad por cambios de tareas en diferentes
proyectos, para evitar interrupciones externas, para trabajar todos en las mismas
prioridades y así poder mantener la previsión de lo que se podría entregar en cada
iteración.
8.5.4 Se autoorganizan y piensan juntos:
• Para crear sinergias con qué conseguir un resultado mejor en menos tiempo, en
términos de valor para cliente.
• Para mejorar su proceso de trabajo y el sistema que les rodea, reflexionando
regularmente (por ejemplo, haciendo Retrospectivas) e introduciendo acciones de
mejora en su Backlog de tareas a realizar.
42
• La manera de conseguir esto se basa en compartir información y que sus miembros

confíen entre ellos. Para ello, realiza de manera conjunta las siguientes actividades:
✓ Seleccionar los requisitos que prevén completar en una iteración, de forma que
estén preparados para ser entregados al cliente.
✓ Estimar la complejidad de cada requisito en la lista de requisitos priorizada del
producto o proyecto.
✓ En la reunión de planificación de la iteración, decidir cómo va a realizar su
trabajo:
➢ Seleccionar los requisitos que pueden completar en cada iteración, realizando
al cliente las preguntas necesarias.
➢ Identificar todas las tareas necesarias para completar cada requisito.
➢ Estimar el esfuerzo necesario para realizar cada tarea.
➢ Cada miembro del equipo se auto asigna a las tareas.
• Durante la iteración, trabajar de manera conjunta para conseguir los objetivos de la
iteración. Cada especialista lidera el trabajo en su área y el resto colaboran si es
necesario para poder completar un requisito.
• Al finalizar la iteración:
✓ Demostrar al cliente los requisitos completados en cada iteración.
✓ Hacer una retrospectiva la final de cada iteración para mejorar de forma continua
su manera de trabajar.
8.5.5 Estar sentados juntos.
Todos los miembros del equipo trabajan en la misma localización física, para poder
maximizar la comunicación entre ellos mediante conversaciones cara a cara, diagramas en
pizarras blancas, etc.
✓ De esta manera se minimizan otros canales de comunicación menos eficientes, que

hacen que las tareas se transformen en un “pasa pelota” o que hacen perder el tiempo
en el establecimiento de la comunicación (como cuando se llama repetidas veces por
teléfono cuando la persona no está en su puesto).
43
✓ Notar que una distancia de 3-5 metros entre miembros de un equipo puede llegar a
ser una barrera demasiado alta para favorecer una relación realmente ágil entre ellos,
encontrar soluciones juntos rápidamente y resolver impedimentos. Es decir, a partir
de esa distancia (o si las personas están en otros pisos o edificios de una ciudad) los
efectos pueden ser bastante contraproducentes, equivalentes a tener un equipo
distribuido.
En el caso de equipos remotos, que no trabajen en la misma ciudad, es conveniente

garantizar un tiempo de calidad cara a cara, como mínimo:
• 1-2 semanas para la incepción inicial del proyecto e integración “social” de los
miembros del equipo.
• 2 o más días por iteración, para actividades como Refinements, Retrospectivas o
Planificaciones de iteración.
8.5.6 Interaccionar con Stakeholders.
Este equipo interacciona frecuentemente con los Stakeholders para compartir
conocimiento de negocio, alinear prioridades y medir los resultados del valor entregado al
cliente.
8.6 El Scrum Master

Su principal misión es conseguir un equipo de alto rendimiento (incluyendo al
Cliente / Product Owner y a las relaciones con la organización y Stakeholders). Se encarga
de conseguir el equipo que conozca y sienta los principios y valores de Agile, así como la
teoría y prácticas de Scrum, con el objetivo de que los usen en sus procesos de toma de
decisiones. El Scrum Master actúa como facilitador de reuniones donde pensar de manera
conjunta y quita los obstáculos más allá del equipo que le impiden ser ágil.
De este modo, es el coach y líder al servicio del equipo, llevando a cabo las
siguientes responsabilidades:
44
• Velar por que todos los participantes del proyecto sigan los valores y principios
ágiles, las reglas y proceso de Scrum y guiar la colaboración intra-equipo y con el
cliente / Product Owner) de manera que las sinergias sean máximas. Esto implica:
✓ Asegurar que exista una lista de requisitos priorizada y que esté preparada antes
de la siguiente iteración.
✓ Facilitar las reuniones de Scrum (planificación de la iteración, reuniones diarias
de sincronización del equipo, demostración, retrospectiva), de manera que sean
productivas y consigan sus objetivos.
✓ Enseñar al equipo a auto gestionarse. No da respuestas, si no que guía al equipo
con preguntas para que descubra por sí mismo una solución.
• Quitar impedimentos que el equipo tiene en su camino para conseguir el objetivo de
cada iteración (proporcionar un resultado útil al cliente de la manera más efectiva) y
poder finalizar el proyecto con éxito. Estos obstáculos se identifican de manera
sistemática en las reuniones diarias de sincronización del equipo y en las reuniones
de retrospectiva.
• Proteger y aislar al equipo de interrupciones externas durante la ejecución de la
iteración (introducción de nuevos requisitos, “secuestro” no previsto de un miembro
del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el
compromiso que adquirió sobre los requisitos que completaría en la iteración [notar,
sin embargo, que el equipo debe reservar tiempo para colaborar con al cliente en la
preparación de la lista de requisitos para la próxima iteración].
• Trabajar con otros Scrum Masters y el equipo de transformación / mejora continua
con el objetivo de que la organización sea cada vez más ágil.
Notar que una distancia de 3-5 metros del equipo puede llegar a ser una barrera
demasiado alta para poder descubrir los comportamientos y tipos de relaciones que hay
entre sus miembros, y los impedimentos que les están dificultando el día a día.
8.7 Eventos de Scrum

Los eventos se usan en Scrum para crear un patrón constante y minimizar la
necesidad de reuniones no definidas.

45
Todos los eventos son “time boxeados”, es decir, tienen una duración máxima,
pudiendo acabarse, siempre que se logre el objetivo del evento.
Existen 5 eventos diferentes:

1. Sprint
2. Sprint Planning, o Planificación del Sprint en castellano
3. Daily Scrum, normalmente llamada Daily
4. Sprint Review, o Revisión del Sprint
5. Sprint Retrospective, o Retrospectiva del Sprint
8.8 El Sprint
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de
un mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un resultado
completo, un incremento de producto que sea potencialmente entregable, de manera que
cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para
que el producto esté disponible para ser utilizado. Para ello, durante la iteración el equipo
colabora estrechamente y se llevan a cabo las siguientes dinámicas:
• Cada día el equipo realiza una reunión de sincronización, donde cada miembro
inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias,
comunica cuales son los impedimentos con que se encuentra, actualiza el estado de
la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente
(Burndown charts).
• El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.
• Elimina los obstáculos que el equipo no puede resolver por sí mismo.
• Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.
46
8.8.1 Recomendaciones
Para poder completar el máximo de requisitos en la iteración, se debe minimizar el
número de objetivos/requisitos en que el equipo trabaja simultáneamente (WIP, Work In
Progress), completando primero los que den más valor al cliente. Esta forma de trabajar,
que se ve facilitada por la propia estructura de la lista de tareas de la iteración, permite tener
más capacidad de reacción frente a cambios o situaciones inesperadas.
8.8.2 Restricciones
• No se puede cambiar los objetivos/requisitos de la iteración en curso.

• En la reunión de planificación de la iteración el equipo adquirió el compromiso de
completar en la iteración unos requisitos concretos, basó su plan y organización en
ellos. Cambiar los objetivos/requisitos de la iteración dificulta la concentración del
equipo, baja su moral y su compromiso.
• El hecho de no poder cambiar los objetivos/requisitos de la iteración una vez iniciada
facilita que el cliente cumpla con su responsabilidad de conocer qué es lo más
prioritario a desarrollar, antes de iniciar la iteración.
• Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos
que se están desarrollando eran los más prioritarios justo antes de iniciar la iteración
y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas)
como para que la probabilidad de cambios una vez iniciada la iteración sea mínima.
8.8.3 Terminación anormal de la iteración
Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una

terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el contexto del
proyecto ha cambiado enormemente y no es posible esperar al final de la iteración para
aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso
adquirido. En ese caso, se dará por finalizada la iteración y se dará inicio a otra mediante una
reunión de planificación de la iteración.
8.9 Reunión de Planificación de Sprint (Sprint Planning Meeting)
La planificación de las tareas a realizar en la iteración se divide en dos partes:
47
• Primera parte de la reunión. Se realiza en un TimeBox de cómo máximo 4 horas:

✓ El cliente presenta al equipo la lista de requisitos priorizada del producto o
proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar
decisiones durante su ejecución) y propone los requisitos más prioritarios a
desarrollar en ella.
✓ El equipo examina la lista, pregunta al cliente las dudas que le surgen, añaden más
condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios
que se compromete a completar en la iteración, de manera que puedan ser
entregados si el cliente lo solicita.
• Segunda parte de la reunión. Se realiza en un TimeBox de cómo máximo 4 horas. El
equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor
resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que
ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien
mejor conoce cómo realizarlo.
✓ Define las tareas necesarias para poder completar cada objetivo/requisito, creando
la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de
hecho.
✓ Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
✓ Cada miembro del equipo se auto asigna a las tareas que puede realizar.
Estos son tiempos máximos en el caso de iteraciones mensuales. En iteraciones de

tamaño menor el tiempo es proporcionalmente inferior, y se puede ir reduciendo conforme
el equipo va ganando experiencia en este tipo de reuniones, aunque también dependerá de la
complejidad a desarrollar en la iteración.
8.9.1 Beneficios
Productividad mediante comunicación y creación de sinergias:
✓ Todos los miembros del equipo tienen una misma visión del objetivo y se ha
utilizado los conocimientos y las experiencias de todos para elaborar la mejor
solución entregable en el mínimo tiempo y con el mínimo esfuerzo, eliminando
tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.
Potenciación del compromiso del equipo sobre el objetivo común de la iteración:

48
✓ Es todo el equipo quien asume la responsabilidad de completar en la iteración los

requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta
algún impedimento que bloquea el progreso de la iteración, especialmente si
cuando se está llegando al final de la iteración es necesaria la participación de
todos para poder completar los objetivos comprometidos.
✓ Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las
que se auto asignó) en los tiempos que proporcionó. Si existe falta de compromiso
con respecto al resto de miembros del equipo se hará muy evidente en las
reuniones diarias de sincronización del equipo (Scrum Daily meeting).
Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes
conocimientos, experiencia y habilidades de los integrantes del equipo.
8.10 Objetivo del Sprint (Sprint Goal)

El Sprint Goal es el objetivo más importante que tiene que cumplir el equipo Scrum
durante el sprint. Debe ser alcanzable mediante la realización de un conjunto “coherente”
de ítems del Product Backlog.
Este conjunto puede representar, bien una funcionalidad, bien cualquier otra cosa
que sirva para que el equipo trabaje en una causa común, en lugar de en iniciativas
separadas.
El Sprint Goal sirve de guía al Development Team para saber por qué están
construyendo “este” Incremento. Si durante el sprint se descubre que el trabajo a realizar es
diferente, el Development Team y el Product Owner pueden renegociar el alcance del
Sprint Backlog durante el sprint.
Por otro lado, el Sprint Goal también sirve para que los Stakeholders, el Product
Owner y el Development Team estén alineados respecto a qué es lo más importante, lo más
prioritario. Es decir, guía el trabajo del equipo y determina, en gran medida, las
expectativas de los Stakeholders.

49
Generalmente, los Stakeholders y/o el sponsor estarán satisfechos si el equipo
alcanza el Sprint Goal. No olvidemos que el Sprint Backlog es una predicción del trabajo
que realizará el equipo, mientras que el Sprint Goal es un compromiso.
8.11 Scrum Diario (Daily Scrum)

El objetivo de esta reunión es facilitar la transferencia de información y la
colaboración entre los miembros del equipo para aumentar su productividad, al poner de
manifiesto puntos en que se pueden ayudar unos a otros.
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que
pueden impedir este objetivo) para al finalizar la reunión poder hacer las adaptaciones
necesarias que permitan cumplir con el compromiso conjunto que el equipo adquirió para la
iteración (en la reunión de planificación de la iteración).
Cada miembro del equipo debe responder las siguientes preguntas en un TimeBox
de cómo máximo 15 minutos:
• ¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo que
tenía planeado? ¿Cuál fue el problema?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta
iteración y en el proyecto?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración,
donde se actualiza el estado y el esfuerzo pendiente para cada tarea, así como con el gráfico
de horas pendientes en la iteración.
8.11.1 Beneficios
Aumentar la productividad en el proyecto y potencia el compromiso de equipo,
dado que cada miembro pone de manifiesto delante del resto:

50
✓ Las tareas que pueden afectar a otros miembros del equipo, por que impactan en
su trabajo o porque hay dependencias (especialmente si existe un retraso).
✓ Los impedimentos con que se encuentra. La reunión de sincronización permite
identificar más problemas a tiempo. El resto de miembros del equipo pueden
ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya
tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar
los impedimentos que el equipo no puede solucionar por sí solo o que le quitan
tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.
✓ Las tareas no planeadas que está realizando que el equipo no conoce y puede que
no estén alineadas con el compromiso del equipo, aunque él crea que lo que está
haciendo es lo mejor que se puede hacer.
✓ Cuáles son sus necesidades. Cada miembro entiende las necesidades de los otros
miembros del equipo respecto a su trabajo, de manera que pueden colaborar y
adaptar sus trabajos para que den el máximo valor y no realizar tareas que no
proporcionan ningún beneficio al resto del equipo.
✓ Cuál es su ritmo de trabajo. Se hace visible si de manera continua un miembro del
equipo está realizando tareas por debajo del rendimiento esperado. Se evita que
una persona señale con el dedo a otra, dado que la reunión de sincronización pone
a todos los miembros del equipo en la misma situación de tener que explicar en
qué tareas están trabajando.
✓ Cuáles son los criterios que está utilizando para realizar sus tareas, de manera que
estén alineados con los objetivos comunes del equipo.
✓ Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo
trabajan los otros según sus especialidades y experiencias.
✓ Conocer el estado de la iteración, ver si es posible completar los requisitos a que
se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.
8.11.2 Restricciones
• La reunión diaria de estado y sincronización del equipo no es para resolver problemas,

los problemas se resuelven después de la reunión.
• No a todos los miembros del equipo les interesan todos los detalles de cada tema.
51
• En la reunión los miembros del equipo programan reuniones entre ellos donde
colaborar sincronizando tareas, ayudando a resolver problemas, etc.
• No puede haber una persona explicando su estado mientras otras "se han apartado"
de la reunión para comentar un tema particular. Si apareciese alguna conversación de
interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin
distraer el principal objetivo de que todos conozcan en qué están trabajando los
demás. Si la mini conversación no es del interés de todos, debe hacerse después de la
reunión.
• El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución
de las de tareas
• El proceso de ejecución de las tareas debe estar consensuado para evitar que cada
reunión sea una exposición de discrepancias entre los miembros del equipo.
8.11.3 Recomendaciones
• Realizar la reunión diaria de sincronización de pie, para que los miembros del equipo
no se relajen ni se extiendan en más detalles de los necesarios.
• Realizar las reuniones de colaboración entre miembros del equipo justo después de la
de sincronización.
8.12 Revisión de Sprint (Sprint Review)

Reunión informal donde el equipo presenta al cliente los requisitos completados en
la iteración, en forma de incremento de producto preparado para ser entregado con el
mínimo esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al objetivo
que se pretende cubrir.
En función de los resultados mostrados y de los cambios que haya habido en el
contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya
desde la primera iteración, Re planificando el proyecto.
Se realiza en un TimeBox de cómo máximo 4 horas.
Los Beneficios que otorga el TimeBox:

52
• El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos
que proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que
necesita y tomar mejores decisiones respecto al proyecto.
• El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el
cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.
• El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va
obteniendo. No está meses trabajando sin poder exhibir su obra.
Restricciones
Sólo se pueden mostrar los requisitos completados, para que el cliente no se haga
falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la
velocidad de desarrollo y el resultado realmente completado. Un requisito no completado
quedará como un requisito más a Re planificar.
8.13 Retrospectiva de Sprint (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la calidad del
producto que está desarrollando, el equipo analiza cómo ha sido su manera de trabajar
durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al
inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente
era lo que él esperaba o no:
• Qué cosas han funcionado bien.

• Cuales hay que mejorar.
• Qué cosas quiere probar hacer en la siguiente iteración.
• Qué ha aprendido.
• Cuáles son los problemas que podrían impedirle progresar adecuadamente.
El Facilitador se encargará de ir eliminando los obstáculos identificados que el
propio equipo no pueda resolver por sí mismo.

53
Notar que esta reunión se realiza después de la reunión de demostración al cliente
de los objetivos conseguidos en la iteración, para poder incorporar su FeedBack y
cumplimiento de expectativas como parte de los temas a tratar en la reunión de
retrospectiva
Se realiza en un TimeBox de cómo máximo 3 horas (si la iteración es mensual).
Beneficios
• Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite
hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera
sistemática, iteración a iteración, con resultados a corto plazo.
• Aumenta la motivación del equipo dado que participa en la mejora de proceso, se
siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir
eliminando lo que molesta e impide que sea más productivo.
Restricciones
• En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y
recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es
frustrante encontrar sistemáticamente los mismos obstáculos y no poder
solucionarlos.
8.14 Artefactos de Scrum

En el marco de trabajo Scrum, denominamos Artefacto a aquellos elementos físicos
que se producen como resultado de la aplicación de Scrum. Los tres principales artefactos o
herramientas Scrum son: el Product Backlog, Sprint Backlog, y el Incremento.
8.15 Lista de Producto (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas del
cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es el
responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien
54
proporciona el coste estimado de completar cada requisito). Dado que reflejar las
expectativas del cliente, esta lista permite involucrarle en la dirección de los resultados del
producto o proyecto.
• Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen
expresar en forma de historias de usuario. Para cada objetivo/requisito se indica el
valor que aporta al cliente y el coste estimado de completarlo. La lista está priorizada
balanceando el valor que cada requisito aporta al negocio frente al coste estimado que
tiene su desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).
• En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por
el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos
completados hasta ese momento), en función de la velocidad de desarrollo del (los)
equipo(s) que trabajará(n) en el proyecto. Es conveniente que el contenido de cada
iteración tenga una coherencia, de manera que se reduzca el esfuerzo de completar
todos sus objetivos.
• La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos
o tareas necesarios para mitigarlos.
Antes de iniciar la primera iteración, el cliente debe tener definida la meta del
producto o proyecto y la lista de requisitos creada. No es necesario que la lista termine
completa ni que todos los requisitos estén detallados al mismo nivel. Basta con que estén
identificados y con suficiente detalle los requisitos más prioritarios con los que el equipo
empezará a trabajar. Los requisitos de iteraciones futuras pueden ser mucho más amplios y
generales. La incertidumbre y complejidad propia de un proyecto hacen conveniente no
detallar todos los requisitos hasta que su desarrollo esté próximo. De esta manera, el esfuerzo
de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) está repartido en
el período de ejecución del proyecto. En el caso del desarrollo de un producto, la lista va
evolucionando durante toda la vida del producto (los requisitos “emergen”). En el caso de un
proyecto, conforme éste avance irán apareciendo los requisitos menos prioritarios que falten.
Esto produce varias ventajas:
• Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se puede
iniciar antes el desarrollo y el cliente puede empezar a obtener resultados útiles.
55
• Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el

transcurso del proyecto, dado que el cliente conocerá mejor cuál ha de ser el resultado
a conseguir, o bien por que podrían ser reemplazados por otros.
• Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar
los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.
8.15.1 Iteración de entrega (Release Sprint)
Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta
ese momento, el equipo puede necesitar añadir una iteración de entrega, más corta que las
iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta
el momento de la entrega final y acabar de corregir defectos detectados en la última
demostración.
Idealmente esta iteración de entrega no debería existir (o reducirse a tareas mínimas
dentro de una iteración) si:
• Se ha trabajado con una buena Definición de Hecho durante cada iteración del
proyecto.
• Se hacen entregas muy cortas cada poco tiempo, con lo que la cantidad de cosas a
entregar, integrar y probar es pequeña.
• Se está realizando un esfuerzo de automatización de estas tareas de pruebas, iteración
y entrega durante todo el proyecto (con lo cual se gana en eficiencia y seguridad).
8.15.2 Uso de la lista de objetivos priorizada
• Para medir la velocidad de desarrollo del equipo, ver una progresión constante y
extrapolar la fecha de las entregas, es conveniente seguir las siguientes
recomendaciones:
✓ Los requisitos deben tener un esfuerzo semejante para ser completados.
✓ La estimación de un requisito no debe ser superior a 10 días (si las iteraciones son
de 20 días laborables).
56
• Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste
estimado en función de la incertidumbre de la complejidad de su desarrollo en el
momento de introducirlo en la lista. Este factor de coste se irá ajustando conforme las
iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y
su velocidad de desarrollo con las herramientas y tecnologías que utiliza.
• Si un requisito depende de otro, se coloca en algún punto por debajo del que depende.
• Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las
siguientes iteraciones, indicando el coste pendiente de desarrollo.
• El “origen” permite saber quién podría participar en la definición de un
objetivo/requisito y sería conveniente que estuviese presente en el momento de su
demostración.
8.16 Lista de Pendientes del Sprint (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunión de planificación de la iteración
(Sprint Planning) como plan para completar los objetivos/requisitos seleccionados para la
iteración y que se compromete a demostrar al cliente al finalizar la iteración, en forma de
incremento de producto preparado para ser entregado.
Esta lista permite ver las tareas donde el equipo está teniendo problemas y no
avanza, con lo que le permite tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo
pendiente para finalizarlas y la auto asignación que han hecho los miembros del equipo.
El progreso de la iteración y su velocidad con respecto a tareas u horas pendientes
se muestra mediante un gráfico de trabajo pendiente (Burndown chart).
8.16.1 Uso de la lista
• Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.

• Por ello, signos de falta de foco, problemas o impedimentos serían que se estén
completando objetivos que no son los primeros de la lista, así como tener demasiados
objetivos/requisitos en progreso simultáneamente.
57
• Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.
• Las tareas deben estar identificadas de manera que tengan un coste semejante para
ser completadas, entre 4 y 16 horas. Este tamaño permitirá:
• Que las tareas sean suficientemente pequeñas como para poder detectar progreso o
estancamiento de manera diaria.
• Que las tareas no sean muy pequeñas, que sean suficientemente relevantes, no
generen ruido ni micro gestión.
• Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas
dentro de la iteración.
8.16.2 El tablero de tareas (Scrum Taskboard)
La lista de objetivos a completar en la iteración (Product Backlog Ítems) se puede
gestionar mediante un tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se
ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia
la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada
miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre cada tarea,
de manera que se pueda ver en qué tareas está trabajando cada cual.
El equipo elabora esta lista de tareas en la segunda parte de la reunión de
planificación de la iteración. La lista va evolucionando (nuevas tareas, cambios, estado,
esfuerzo pendiente, …) a medida que la iteración avanza, especialmente durante la reunión
diaria de sincronización.
Este tablón o cuadro de mandos actúa como radiador de información tanto para el
equipo como para cualquier otra persona relacionada con el proyecto.
8.17 Incremento
Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de
software terminado en cada Sprint. Un Incremento es el resultado del Sprint, es la suma de

58
todas las tareas, casos de uso, historias de usuario y cualquier elemento que se haya
desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de
software, aportando un valor de negocio al producto que se está desarrollando.
Construir software de manera ágil se basa en hacerlo de manera iterativa e
incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del
software (planificación, diseño, desarrollo, testeo y entrega) ocurre en 4 semanas o menos.
Por supuesto, no podemos construir toda la funcionalidad que queremos en solo cuatro
semanas y tenemos que buscar la manera de ir entregando los componentes necesarios justo
a tiempo.
8.18 Transparencia de los Artefactos

La transparencia en Scrum es una cualidad fundamental para que el funcionamiento
sea el correcto. Es clave que todos los miembros del equipo Scrum entiendan y conozcan el
rumbo del proyecto. Por consiguiente, es una cualidad imprescindible que los artefactos de
Scrum estén definidos de manera absolutamente clara.
En la medida en que los artefactos no son completamente transparentes, estas
decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar. El
Scrum Master debe trabajar con el Dueño de Producto, el Equipo de Desarrollo y otras
partes involucradas para entender si los artefactos son completamente transparentes. Hay
prácticas para hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos
a aplicar las prácticas más apropiadas si no hay una transparencia completa.
Un Scrum Master puede detectar la falta de transparencia inspeccionando artefactos,
reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias
entre los resultados esperados y los reales. La labor del Scrum Master es trabajar con el
Equipo Scrum y la organización para mejorar la transparencia de los artefactos.

59
Tanto tú, como el equipo de desarrollo, podréis tomar decisiones basadas en
criterios sólidos si los artefactos son transparentes. En consecuencia, y esa debe ser una
labor del Scrum Master, debes asegurarte de que todos los miembros del equipo colaboren
para que haya un entendimiento completo.
Éste no suele ser un proceso inmediato. Se tarda un cierto tiempo en que todos los
miembros del equipo “hablen el mismo idioma”. Sin embargo, desde el primer momento
debes hacer lo posible para aclarar todas las dudas y concretar todos los conceptos
ambiguos.
8.19 Definición de ‘Terminado’ (Definition of ‘Done’)

La Definición de Hecho (Definition of Done) permite:
• Establecer un criterio de calidad, define qué entregables y mínimos de calidad tienen
se tienen que cumplir en TODOS los objetivos / requisitos que se van a ir aceptando
durante cada iteración del proyecto.
• Tener siempre un producto “potencialmente entregable” al Product Owner (cliente)
al finalizar cada iteración, no dejar trabajo pendiente para el final, escondido “debajo
de la alfombra”, que pueda impedir utilizar los resultados del proyecto lo antes
posible.
• Esto permite saber claramente en qué punto real se está del proyecto y tomar buenas
decisiones al respecto sobre lo que se ha conseguido hasta ese momento y lo que
todavía no se sabe con certeza cuándo estará acabado. Con una buena Definición de
Hecho, el cliente podrá tomar decisiones correctas cuando al final de cada iteración
el equipo le haga una demostración de los requisitos completados: cambiar las
prioridades en función de la velocidad de desarrollo, solicitar una entrega del
producto desarrollado hasta ese momento, etc.
• Por otro lado, lo peor que podría suceder es que, aunque el equipo haya ido
presentando todos los objetivos / requisitos completados durante el proyecto (en cada
iteración), se podría dar el caso de que los días previos a una entrega de repente se
60
den cuenta de que hay que hacer mucho trabajo de integración y finalización (que
podría haberse ido haciendo antes, durante el proyecto). Esto también les dificultaría
estimar cuándo tiempo necesitan para acabar de terminar el producto (lo cual pondría
en peligro la fecha de entrega).
La Definición de Hecho se acuerda entre el Product Owner (cliente) y el Equipo de
desarrollo al principio del proyecto y se puede ir mejorando durante su transcurso (si es
necesario precisar más las expectativas en cuanto a calidad global o del proceso de trabajo
o, simplemente, tras una Retrospectiva, para ir consiguiendo una mejor la calidad del
producto final).
8.20 Ventajas y Desventajas

Ventajas de Scrum:
• El cliente puede comenzar a utilizar el producto rápidamente.
• El cliente puede decidir los nuevos objetivos a realizar.
• Se agila el proceso, porque se divide el problema en pequeñas tareas.
• Menos probabilidad de que se den sorpresas o desarrollos inesperados porque el
cliente va viendo poco a poco lo que se está desarrollando.
Desventajas de Scrum:
• Existe la tendencia que si se deja una tarea sin terminar y que por las exigencias del
Dueño del Producto se deban realizar otras nuevas. Estas tareas no terminadas puedan
obstaculizar la planeación de nuevas Sprint y se deba volver al problema original.
• Alto nivel de stress de los miembros del equipo, el desgaste puede ser excesivo y
estresante lo que puede disminuir el rendimiento.
• La necesidad de contar con equipos multidisciplinarios puede ser un problema,
porque cada integrante del equipo debe estar en capacidad de resolver cualquier tarea
y no siempre se cuenta con este perfil en la empresa.
• El equipo puede estar tentado de tomar el camino más corto para cumplir con un
sprint, que no necesariamente puede ser el de mejor calidad en el desarrollo del
producto.
61
8.21 Valores del Trabajo

8.21.1 Compromiso
Este valor ha sido malinterpretado durante mucho tiempo. Muchos lo entendieron
como un contrato estricto no escrito por parte del equipo por el que debían completar, sin
excepción ni excusa alguna, el Sprint Goal y el alcance acordado.
O peor, el Product Owner tomaba por compromiso la exigencia al Development
Team de hacer todo lo que fuera necesario para completar todo el trabajo planificado, aun a
sabiendas del no cumplimiento del DoD (Definition Of Done) y de la consiguiente
generación de deuda técnica.
Sin embargo, compromiso significa que cada miembro del equipo Scrum (es
decir, todos, incluido Scrum Master y Product Owner) hará el máximo esfuerzo posible y
será completamente transparente sobre el progreso del Sprint.
En el mundo del desarrollo software, cualquiera que tenga una mínima experiencia
y se haya enfrentado a un proyecto real del mundo real, sabrá que un compromiso cerrado e
inviolable en alcance sencillamente es imposible y solo conduce a la frustración.
El matiz es muy importante: en el Sprint Planning el equipo hace una predicción del
trabajo que podrá llevar a cabo, no una firma de un contrato con sello lacrado. Compromiso
significa dedicación y se refiere a las acciones y el esfuerzo, no al resultado final.
Por ejemplo, podemos jugar a relacionar este valor con uno de los principios
universales, la Justicia. Si el Product Owner o un miembro del Development Team no
dedica el suficiente tiempo, energía y voluntad a contribuir a la consecución de los
objetivos del equipo, como sí hacen el resto de miembros, ¿sería esta circunstancia justa
respecto del resto de integrantes del equipo que sí están comprometidos?

62
Los miembros de un equipo Scrum se comprometen con los objetivos del equipo,
con la calidad, con aprender, con ser mejores profesionales, con la transparencia, con
autoorganizarse cada vez mejor, con ser proactivos, con la entrega de incrementos, con la
inspección y adaptación, con la mejora continua del DoD, con aportar el máximo valor
posible al producto que desarrollan, con el propio Scrum como framework, e incluso con el
manifiesto Agile y los principios que de él emanan.
8.21.2 Foco
“Begin with the end in mind”, proclama Stephen R. Covey como el segundo hábito
más importante en su libro “The 7 Habits of Highly Effective People”.
Todos sabemos que el enemigo número uno de la productividad es la multitarea, la
dispersión y la falta de concreción en los objetivos que se pretenden alcanzar. Scrum
proclama que todos los miembros del equipo deben enfocarse en el trabajo planificado en
cada Sprint que, en última instancia, permite cumplir los Sprint Goals.
El equipo debe enfocarse en lo que es más importante ahora, sin preocuparse en
exceso por el futuro, que puede ser muy incierto y cambiante. El equipo no debe dedicar
tiempo a tareas que puede que no sean necesarias en el futuro, eso sería tirar tiempo y dinero
a la basura. YAGNI (You Ain’t Gonna Need It) o KISS (Keep It Simple Stupid) pueden
ayudarnos a recordar que debemos mantener el foco.
He hablado con algunos Product Owner preocupados con la dedicación de ciertos

miembros de equipos a determinadas tareas que no estaban incluidas en el Sprint (ni habían
surgido en las REPLANIFICACIONES diarias), simplemente porque habían decidido que
algo podría ser buena idea o podría necesitarse en el futuro.
Aunque es difícil trazar una línea entre, por ejemplo, lo que evita deuda técnica o
aumenta la calidad, y lo que es una pérdida de foco, casi siempre hay que decir tres veces
NO a un trabajo o tarea que no está directamente relacionada con alcanzar el Sprint Goal.
Como regla general, lo mejor es siempre hacer el mínimo trabajo posible que me
permite cumplir el objetivo.
63
Foco es centrarse en cumplir el Sprint Goal y, por extensión, en los ítems del
Product Backlog que forman parte del Sprint. Si el Sprint Goal está bien definido y los
ítems del Product Backlog fueron bien priorizados, entonces el equipo estará trabajando
en entregar el máximo valor posible en cada momento. Eso es foco.
8.21.3 Franqueza
En realidad, la palabra inglesa “OPENNESS” puede traducirse como franqueza,
sinceridad o actitud abierta y receptiva.
Scrum defiende la transparencia como un pilar básico del empirismo sobre el que se
sustenta. Sin transparencia es imposible llevar a cabo la Inspección y la Adaptación. Por
tanto, el Development Team debe ser transparente con el trabajo que realiza, con el
progreso del mismo, y con el conocimiento que adquiere (documentación).
El Product Owner debe facilitar el acceso a la información relevante a los
Stakeholders (Product Backlog, Total Cost of Ownership, etc.). Todos los miembros del
equipo deben facilitar la transparencia en las comunicaciones y la compartición de
información que facilite la colaboración dentro y fuera del equipo.
No solo lo anterior, el equipo debe estar accesible y disponible para interactuar con
los Stakeholders (especialmente en este caso, el Product Owner, por razones obvias) o con
otros miembros de la comunidad (equipos de arquitectura, de seguridad, etc.).
Incluso los miembros del equipo deben estar abiertos a aprender nuevas
habilidades o adquirir nuevos conocimientos que les conviertan en multifuncionales
(cross-functional teams). Los miembros del equipo deben tener una actitud abierta y
proactiva para mejorar sus capacidades y competencias profesionales, lo que además de
contribuir al beneficio del equipo, se traduce en crecimiento personal.

64
8.21.4 Respeto
He de reconocer que la primera vez que leí “respeto” en la Guía Scrum pensé que
consistía en ser educado con los miembros del equipo (¡cómo no!). Pero más adelante
descubrí que el respeto, tal y como lo entiende Scrum y el mundo Agilé, es un concepto
fascinante.
Los miembros de un equipo Scrum respetan el conocimiento, las habilidades y la
experiencia profesional no solo del resto de miembros del equipo, sino también de aquellas
personas con las que se relacionan, sean de su propia organización o de otra.
Los miembros de un equipo Scrum se respetan entre ellos compartiendo
información, fomentando un espíritu colaborador, aprendiendo y tomando decisiones
juntos. Los miembros de un equipo Scrum se respetan entre ellos comprendiendo sus roles
Scrum y la responsabilidad de cada uno dentro del equipo.
Los miembros de un equipo Scrum respetan a los sponsors no desarrollando
“features” que nadie va a usar después. Los miembros de un equipo Scrum respetan a los
sponsors no gastando dinero en cosas que no aportan valor alguno al producto. Los
miembros de un equipo Scrum respetan a los sponsors no dedicando el esfuerzo a tareas
que no aportan ningún valor al producto.
Los miembros de un equipo Scrum respetan a los usuarios escuchándolos,
mostrando interés por sus problemas y dándoles una solución.
Los miembros de un equipo Scrum respetan a la comunidad no permaneciendo
como una isla o una unidad aislada dentro de la organización, sino participando
activamente para transferir conocimiento y experiencia.

65
8.21.5 Coraje
El equipo debe tener coraje para hacer lo correcto. Por ejemplo, considerar el
cambio como algo necesario para adaptarse a un mundo cambiante, a pesar de que a veces
nos obligue a deshacer caminos andados.
Hay que tener coraje para ser capaz de desarrollar el producto sin mirar al futuro
más de lo necesario, centrándote en lo que sabemos que es importante ahora, en lugar de en
lo que podría (o no) ser importante en el futuro.
El equipo debe tener coraje para resolver los impedimentos que puedan surgir en
el camino, anticipando los riesgos, sacando a la luz los problemas y pensando en una
solución. Hay que tener coraje para reconocer los errores cometidos, ser transparentes y
aprender de los mismos.
8.22 Herramientas de Trabajo

Taiga es una herramienta de software libre y código abierto, creada para gestionar y
colaborar en proyectos ágiles, principalmente aquellos que utilizan metodología Scrum y
Kanban, además permite gestionar issues.
De igual manera Taiga posee otros módulos como wiki, videoconferencia (gracias a
una solución de terceros), actualización de equipo y como si fuera poco gracias a su potente
API permite la integración con servicios de terceros como Slack, GitHub, GitLab,
Bitbucket, HipChat, Gogs, Hall entre otros.
Taiga es distribuida bajo la licencia de código abierto Affero GPL, está escrita en
Django (backend) + AngularJS (frontend) y su código fuente está alojado en GitHub para
que sea utilizado por la comunidad.

66
Para comenzar a disfrutar de Taiga debes registrarte de manera gratuita, verificar tu
cuenta mediante el correo electrónico que te envían e iniciar sesión con los datos que
indicaste anteriormente.
La combinación del marco de trabajo SCRUM con la herramienta de gestión de
proyectos Taiga, puede ser aplicado para cualquier proyecto que desees realizar, ya sea a
nivel de desarrollo de programas o en la elaboración de un artículo en tu blog como
mostraremos en el siguiente caso práctico.
El primer paso es crear proyectos (puede ser un proyecto Kanban o un proyecto
Scrum), ambos son plantillas para comenzar un proyecto, pero que puedes ir adaptando
según tus necesidades y gustos. En este caso elegiremos un proyecto Scrum y le daremos
siguiente.
Seguidamente Vamos a dar un Nombre a nuestro proyecto y escribimos una
descripción para el mismo
Una vez creado nuestro proyecto en Taiga lo primero que observamos es el
Backlog, donde podemos añadir las historias de usuario de nuestro proyecto, cada historia
de usuario se estima por lo general en puntos y debemos tener claro que no debería indicar
el tiempo de la tarea, es importante destacar que la estimación en taiga se puede hacer por
roles.
Puedes añadir tantas historias de usuario como necesite tu proyecto, al crear una
nueva historia debes colocar un título, la estimación, el estado, etiquetas y la descripción de
la tarea. Además, puedes segmentar la tarea si es requerida por el equipo o por el cliente.
Una vez creada todas las tareas necesarias que necesita nuestro proyecto, debemos
crear lo que en Scrum se llama Sprint, que es la agrupación de un conjunto de tareas que
67
puede representar un producto funcional y que está planificado se realice en un período de
tiempo determinado.
Un proyecto puede tener tantos Sprint como sean necesarios y cada Sprint debe
tener como resultado un prototipo.
En nuestro caso hemos creado un sólo sprint que tiene un día de duración, pero
normalmente los sprint deben durar de 3 a 4 semanas en el caso de desarrollo de software y
se debe tener un día de descanso entre sprint.
Al sprint hemos añadido todas las tareas antes creadas, Taiga permite hacer esto de
una manera fácil arrastrando y soltando cada tarea en el sprint que deseas. También hemos
priorizado las tareas con lo que determinamos cuál se debe hacer primero.
Taiga nos permite añadir miembros para que colaboren en las tareas, por ejemplo,
un diseñador, para invitar a alguien a colaborar en tu proyecto debes ir al menú de admin y
enviar una invitación a su correo electrónico.
Una vez tengamos nuestro sprint ya planificado y con los miembros ya listos para
comenzar, nos dirigimos a nuestro panel de tareas del sprint que es un Kanban con varias
columnas, las cuales representan cada una lo siguiente:
• Historia de Usuario: Todas las historias de usuario que conforman el sprint.

• Nueva: Cada historia de usuario se puede dividir en tareas.
• En Curso: Son aquellas tareas que se están realizando en este momento.
• Lista para Testear: Son aquellas tareas que están terminadas pero que no se han
probado.
• Cerrada: Son aquellas tareas que han sido terminadas
• Necesita Información: Son aquellas tareas que se necesita una información extra
para poder ser culminada.
68
Las tareas son tomadas por el colaborador que la va a realizar, el cual se encargará
de cambiarla por el estado que le corresponda. La idea es que todo el equipo conozca el
estado del proyecto y trabajen más sincronizados.
El objetivo del sprint es que todas las tareas sean concretadas, Taiga nos ofrece un
gráfico que nos permite ver en todo momento como vamos.
DESARROLLO DE SOFTWARE
SAAS (Software as a Service)

Nuestro sistema MRP será presentado como software como un servicio, que permite
al cliente acceder vía internet al sistema, dándole garantía de disponibilidad inmediata.
Ventajas de SAAS
• No es necesario que el cliente cuente con un área especializada de soporte
para el sistema, por lo que se reducen sus costes y riesgo de inversión.
• La responsabilidad de la operación recae en la empresa IT. Esto significa
que la garantía de disponibilidad de la aplicación y su correcta
funcionalidad, es parte del servicio que da la compañía proveedora del
software.
• La empresa IT no desatiende al cliente. El servicio y atención continua del
proveedor al cliente es necesaria para que este último siga pagando el
servicio.
• La empresa IT provee los medios seguros de acceso en los entornos de la
aplicación. Si una empresa IT quiere dar SaaS en su cartera de productos,
debe ofrecer accesos seguros para que no se infiltren datos privados en la red
pública.
69
• No es necesaria la compra de una licencia para utilizar el software, sino el
pago de un alquiler o renta por el uso del software. Aunque también se dan
casos particulares donde el servicio es totalmente gratuito, como por
ejemplo en el servicio de blogs que brindan diferentes compañías:
Wordpress, Blogger, etc.; es decir, se cuenta con el servicio, se puede
acceder libremente, se garantiza usabilidad y actualidad, pero no se paga por
el servicio.
• Se le permite al cliente completa flexibilidad en el uso de los sistemas
operativos de su preferencia, o al cual pueda tener acceso.
Herramientas para el desarrollo (WEB, APP, MÓVIL, BD, SO)

Para el desarrollo del sistema de información se contará con las siguientes
características:
WEB: HTML, CSS, PHP, Laravel en su versión 6x
APP: Android Studio (Kotlin)
BD: MySQL
SO: Windows 10
Entorno de Desarrollo: Visual Studio Code

70
CAPITULO 2 APLICACIÓN DEL MARCO DE TRABAJO SCRUM

71
9 PERSONAS Y ROLES DEL PROYECTO
9.1 Personas Y Roles Del Proyecto

9.1.1 Product Owner, Team, Scrum Master, Stakeholders, Users
Rol Integrantes
Product Owner Alvaro Andres Justiniano Herrera
Scrum Master Sergio Ricardo Terrazas Escobar
Development Team Juan Antonio Sosa Pesoa
Juan Daniel Pacheco Ardaya
Jefersson Mayta Gallardo
9.1.2 Planificación de Actividades y Roles
9.1.2.1 Sprint 1
Rol Integrantes Tareas Sprint #01
Scrum Master Alvaro Andres Justiniano • A cargo de la realización de

Herrera la planificación del Sprint 1
Product Owner Sergio Ricardo Terrazas • Brindar especificaciones
Escobar sobre lo que se requiere como
Software y las principales
funcionalidades
Development Juan Antonio Sosa Pesoa • Gestionar Usuario
Team
Juan Daniel Pacheco Ardaya • Gestionar Empleado
Gestionar Sucursal
Jefersson Mayta Gallardo • Gestionar Departamento
• Gestionar Área
72
9.1.2.2 Sprint 2
Rol Integrante Tareas Sprint #02

Scrum Master Juan Daniel Pacheco Ardaya • Consultar al Product Owner
sobre ciertas dudas acerca de
ciertas funcionalidades
Product Owner Juan Antonio Sosa Pesoa • Mantenerse accesible a
preguntas del Scrum Master
Development Alvaro Andres Justiniano • Gestionar Almacén
Team Herrera • Gestionar Inventario
• Gestionar Proveedor
Sergio Ricardo Terrazas • Gestionar Materia Prima
Escobar • Gestionar Articulo
9.1.2.3 Sprint 3

Scrum Master Sergio Ricardo Terrazas • Revisar si existe algún
Escobar requerimiento adicional para
incorporar al proyecto
Product Owner Alvaro Andres Justiniano • Verificar si el cliente está
Herrera satisfecho con el prototipo
actual, explicar al Team si
existe algún requerimiento
adicional
Development Juan Daniel Pacheco Ardaya • Gestionar Cliente
Team • Gestionar Orden De
Aprovisionamiento
• Gestionar Orden De Compra
Juan Antonio Sosa Pesoa • Gestionar Ingreso
• Gestionar Egreso
• Gestionar Cargo
73
9.1.2.4 Sprint 4

Scrum Master Juan Antonio Sosa Pesoa • Verificar que ninguno de los
programadores del equipo
tenga dificultades
• Ayudar a equilibrar el
desarrollo del Software en el
Equipo
Product Owner Juan Daniel Pacheco Ardaya • Sugerir cambios si es
necesario
• Explicar las funcionalidades
de manera específica para
evitar cualquier malentendido
Development Sergio Ricardo Terrazas • Gestionar Lista de Materiales
Team Escobar • Gestionar Orden de
Transferencia
• Gestionar Orden de Trabajo
Alvaro Andres Justiniano • Gestionar Reintegro
Herrera • Gestionar Orden de
Producción
• Gestionar Proceso
• Gestionar Línea de
Producción
74
9.1.2.5 Sprint 5

Scrum Master Sergio Ricardo Terrazas • A cargo de la realización de
Escobar la planificación del Sprint 5
• Verificar que ninguno de los
programadores del equipo
tenga dificultades
Product Owner Alvaro Andres Justiniano • Brindar especificaciones
Herrera sobre lo que se requiere como
funcionalidades
Development Juan Antonio Sosa Pesoa • Gestionar Tiempo Laborado
Team • Gestionar Entrega de Trabajo
• Gestionar Seguimiento de
Producción
• Gestionar Planificación de
Producción
Juan Daniel Pacheco Ardaya • Gestionar Reportes
• Administrar Bitácora
• Administrar Backups
75
9.2 Modelos Para El Desarrollo De Scrum

9.2.1 Sprint Planning Meeting (Reunión de planeamiento del Sprint)
Se ha identificado las tareas primordiales, algunas tareas de usuario usuales en un
sistema de información, además de identificar los casos de uso encontrados en los procesos
de un MRP.
Nro. Tarea Descripción

Obtener todos los datos y procesos que se
0.1 Entrevista con Product Owner
incluyen y se utilizan en un sistema MRP.
Comprender las características de la metodología,
Explicar al Product Owner como funciona la
0.2 así como el rol y las tareas que desempeñara el
metodología a usar
Product Owner en el proyecto.
Explicar al Equipo una definición del Definir el alcance y los límites de las tareas que
0.3
problema desarrollara el Equipo en el proyecto.
A cada miembro del equipo se le será asignado un
Asignación de roles a los miembros del
0.4 rol y actividades que deberá realizar en el
equipo
desarrollo del proyecto.
Se elegirán las herramientas y procedimientos de
Preparación del entorno de desarrollo de
0.5 desarrollo más apropiados para realizar el
programación
sistema.
Elaboración y prueba del modelo de dominio en
0.6 Diseñar un modelo de base de datos
un gestor de base de datos.
0.7 Encontrar los casos de uso funcionales Determinar los requisitos funcionales del sistema.
Analizar, Diseñar, Implementar y realizar Pruebas
1 Gestionar Usuario
al caso de uso Usuario.
2 Gestionar Empleado
al caso de uso Empleado.
3 Gestionar Sucursal
al caso de uso Sucursal.
4 Gestionar Departamento
al caso de uso Departamento.
5 Gestionar Área
al caso de uso Área.
6 Gestionar Almacén
al caso de uso Almacén.
76

7 Gestionar Inventario
al caso de uso Inventario.
8 Gestionar Proveedor
al caso de uso Proveedor.
9 Gestionar Materia Prima
al caso de uso Materia Prima.
10 Gestionar Articulo
al caso de uso Articulo.
11 Gestionar Cliente
al caso de uso Cliente.
12 Gestionar Orden Aprovisionamiento
al caso de uso Orden Aprovisionamiento.
13 Gestionar Orden de Compra
al caso de uso Orden de Compra.
14 Gestionar Ingreso
al caso de uso Ingreso.
15 Gestionar Egreso
al caso de uso Egreso.
16 Gestionar Cargo
al caso de uso Cargo.
17 Gestionar Lista de Materiales
al caso de uso Lista de Materiales.
18 Gestionar Orden de Transferencia
al caso de uso Orden de Transferencia.
19 Gestionar Orden de Trabajo
al caso de uso Orden de Trabajo.
20 Gestionar Reintegro
al caso de uso Reintegro.
21 Gestionar Orden de Producción
al caso de uso Orden de Producción.
22 Gestionar Proceso
al caso de uso Proceso.
23 Gestionar Línea de Producción
al caso de uso Línea de Producción.
24 Gestionar Tiempo Laborado
al caso de uso Tiempo Laborado.
77

25 Gestionar Entrega de Trabajo
al caso de uso Entrega de Trabajo.
26 Gestionar Seguimiento de Producción
al caso de uso Seguimiento de Producción.
27 Gestionar Planificación de Producción
al caso de uso Planificación de Producción.
28 Gestionar Reporte
al caso de uso Reporte.
29 Gestionar Bitácora
al caso de uso Bitácora.
30 Gestionar BackUps
al caso de uso BackUps.
78
9.2.2 Pila Sprint (Sprint Backlog)
ID DESCRIPCION DE LA TAREA ESTADO

Hu0-1 Entrevista con Product Owner Propuesto
Hu0-2 Explicar al Product Owner como funciona la metodología a usar Propuesto
Hu0-3 Explicar al Equipo una definición del problema Propuesto
Hu0-4 Asignación de roles a los miembros del equipo Propuesto
Hu0-5 Preparación del entorno de desarrollo de programación Propuesto
Hu0-6 Diseñar un modelo de base de datos Propuesto
Hu0-7 Encontrar los casos de uso funcionales Propuesto
Hu1-1 Elaborar historia de usuario para gestionar usuario Propuesto
Hu1-2 Diseñar interfaz de usuario para gestionar usuario Propuesto
Hu1-3 Implementar historia de usuario de gestionar usuario Propuesto
Hu1-4 Realizar pruebas de implementación de gestionar usuario Propuesto
Hu2-1 Elaborar historia de usuario para gestionar empleado Propuesto
Hu2-2 Diseñar interfaz de usuario para gestionar empleado Propuesto
Hu2-3 Implementar historia de usuario de gestionar empleado Propuesto
Hu2-4 Realizar pruebas de implementación de gestionar empleado Propuesto
Hu3-1 Elaborar historia de usuario para gestionar sucursal Propuesto
Hu3-2 Diseñar interfaz de usuario para gestionar sucursal Propuesto
Hu3-3 Implementar historia de usuario de gestionar sucursal Propuesto
Hu3-4 Realizar pruebas de implementación de gestionar sucursal Propuesto
Hu4-1 Elaborar historia de usuario para gestionar departamento Propuesto
Hu4-2 Diseñar interfaz de usuario para gestionar departamento Propuesto
Hu4-3 Implementar historia de usuario de gestionar departamento Propuesto
Hu4-4 Realizar pruebas de implementación de gestionar departamento Propuesto
Hu5-1 Elaborar historia de usuario para gestionar área Propuesto
Hu5-2 Diseñar interfaz de usuario para gestionar área Propuesto
Hu5-3 Implementar historia de usuario de gestionar área Propuesto
Hu5-4 Realizar pruebas de implementación de gestionar área Propuesto
Hu6-1 Elaborar historia de usuario para gestionar almacén Propuesto
Hu6-2 Diseñar interfaz de usuario para gestionar almacén Propuesto
Hu6-3 Implementar historia de usuario de gestionar almacén Propuesto
Hu6-4 Realizar pruebas de implementación de gestionar almacén Propuesto
Hu7-1 Elaborar historia de usuario para gestionar inventario Propuesto
Hu7-2 Diseñar interfaz de usuario para gestionar inventario Propuesto
Hu7-3 Implementar historia de usuario de gestionar inventario Propuesto
Hu7-4 Realizar pruebas de implementación de gestionar inventario Propuesto
Hu8-1 Elaborar historia de usuario para gestionar proveedor Propuesto
Hu8-2 Diseñar interfaz de usuario para gestionar proveedor Propuesto
Hu8-3 Implementar historia de usuario de gestionar proveedor Propuesto
Hu8-4 Realizar pruebas de implementación de gestionar proveedor Propuesto
Hu9-1 Elaborar historia de usuario para gestionar materia prima Propuesto
Hu9-2 Diseñar interfaz de usuario para gestionar materia prima Propuesto
Hu9-3 Implementar historia de usuario de gestionar materia prima Propuesto
Hu9-4 Realizar pruebas de implementación de gestionar materia prima Propuesto
Hu10-1 Elaborar historia de usuario para gestionar articulo Propuesto
Hu10-2 Diseñar interfaz de usuario para gestionar articulo Propuesto
Hu10-3 Implementar historia de usuario de gestionar articulo Propuesto
Hu10-4 Realizar pruebas de implementación de gestionar articulo Propuesto
79
Hu11-1 Elaborar historia de usuario para gestionar cliente Propuesto

Hu11-2 Diseñar interfaz de usuario para gestionar cliente Propuesto
Hu11-3 Implementar historia de usuario de gestionar cliente Propuesto
Hu11-4 Realizar pruebas de implementación de gestionar cliente Propuesto
Hu12-1 Elaborar historia de usuario para gestionar orden de aprovisionamiento Propuesto
Hu12-2 Diseñar interfaz de usuario para gestionar orden de aprovisionamiento Propuesto
Implementar historia de usuario de gestionar orden de Propuesto
Hu12-3
aprovisionamiento
Realizar pruebas de implementación de gestionar orden de Propuesto
Hu12-4
aprovisionamiento
Hu13-1 Elaborar historia de usuario para gestionar orden de compra Propuesto
Hu13-2 Diseñar interfaz de usuario para gestionar orden de compra Propuesto
Hu13-3 Implementar historia de usuario de gestionar orden de compra Propuesto
Hu13-4 Realizar pruebas de implementación de gestionar orden de compra Propuesto
Hu14-1 Elaborar historia de usuario para gestionar ingreso Propuesto
Hu14-2 Diseñar interfaz de usuario para gestionar ingreso Propuesto
Hu14-3 Implementar historia de usuario de gestionar ingreso Propuesto
Hu14-4 Realizar pruebas de implementación de gestionar ingreso Propuesto
Hu15-1 Elaborar historia de usuario para gestionar egreso Propuesto
Hu15-2 Diseñar interfaz de usuario para gestionar egreso Propuesto
Hu15-3 Implementar historia de usuario de gestionar egreso Propuesto
Hu15-4 Realizar pruebas de implementación de gestionar egreso Propuesto
Hu16-1 Elaborar historia de usuario para gestionar cargo Propuesto
Hu16-2 Diseñar interfaz de usuario para gestionar cargo Propuesto
Hu16-3 Implementar historia de usuario de gestionar cargo Propuesto
Hu16-4 Realizar pruebas de implementación de gestionar cargo Propuesto
Hu17-1 Elaborar historia de usuario para gestionar lista de materiales Propuesto
Hu17-2 Diseñar interfaz de usuario para gestionar lista de materiales Propuesto
Hu17-3 Implementar historia de usuario de gestionar lista de materiales Propuesto
Hu17-4 Realizar pruebas de implementación de gestionar lista de materiales Propuesto
Hu18-1 Elaborar historia de usuario para gestionar orden de transferencia Propuesto
Hu18-2 Diseñar interfaz de usuario para gestionar orden de transferencia Propuesto
Hu18-3 Implementar historia de usuario de gestionar orden de transferencia Propuesto
Hu18-4 Realizar pruebas de implementación de gestionar orden de transferencia Propuesto
Hu19-1 Elaborar historia de usuario para gestionar orden de trabajo Propuesto
Hu19-2 Diseñar interfaz de usuario para gestionar orden de trabajo Propuesto
Hu19-3 Implementar historia de usuario de gestionar orden de trabajo Propuesto
Hu19-4 Realizar pruebas de implementación de gestionar orden de trabajo Propuesto
Hu20-1 Elaborar historia de usuario para gestionar reintegro Propuesto
Hu20-2 Diseñar interfaz de usuario para gestionar reintegro Propuesto
Hu20-3 Implementar historia de usuario de gestionar reintegro Propuesto
Hu20-4 Realizar pruebas de implementación de gestionar reintegro Propuesto
Hu21-1 Elaborar historia de usuario para gestionar orden de producción Propuesto
Hu21-2 Diseñar interfaz de usuario para gestionar orden de producción Propuesto
Hu21-3 Implementar historia de usuario de gestionar orden de producción Propuesto
Hu21-4 Realizar pruebas de implementación de gestionar orden de producción Propuesto
Hu22-1 Elaborar historia de usuario para gestionar proceso Propuesto
Hu22-2 Diseñar interfaz de usuario para gestionar proceso Propuesto
Hu22-3 Implementar historia de usuario de gestionar proceso Propuesto
Hu22-4 Realizar pruebas de implementación de gestionar proceso Propuesto
Hu23-1 Elaborar historia de usuario para gestionar línea de producción Propuesto
80
Hu23-2 Diseñar interfaz de usuario para gestionar línea de producción Propuesto

Hu23-3 Implementar historia de usuario de gestionar línea de producción Propuesto
Hu23-4 Realizar pruebas de implementación de gestionar línea de producción Propuesto
Hu24-1 Elaborar historia de usuario para gestionar tiempo laborado Propuesto
Hu24-2 Diseñar interfaz de usuario para gestionar tiempo laborado Propuesto
Hu24-3 Implementar historia de usuario de gestionar tiempo laborado Propuesto
Hu24-4 Realizar pruebas de implementación de gestionar tiempo laborado Propuesto
Hu25-1 Elaborar historia de usuario para gestionar entrega de trabajo Propuesto
Hu25-2 Diseñar interfaz de usuario para gestionar entrega de trabajo Propuesto
Hu25-3 Implementar historia de usuario de gestionar entrega de trabajo Propuesto
Hu25-4 Realizar pruebas de implementación de gestionar entrega de trabajo Propuesto
Hu26-1 Elaborar historia de usuario para gestionar seguimiento de producción Propuesto
Hu26-2 Diseñar interfaz de usuario para gestionar seguimiento de producción Propuesto
Hu26-3 Implementar historia de usuario de gestionar seguimiento de producción Propuesto
Realizar pruebas de implementación de gestionar seguimiento de Propuesto
Hu26-4
producción
Hu27-1 Elaborar historia de usuario para gestionar planificación de producción Propuesto
Hu27-2 Diseñar interfaz de usuario para gestionar planificación de producción Propuesto
Hu27-3 Implementar historia de usuario de gestionar planificación de producción Propuesto
Realizar pruebas de implementación de gestionar planificación de Propuesto
Hu27-4
producción
Hu28-1 Elaborar historia de usuario para gestionar reporte Propuesto
Hu28-2 Diseñar interfaz de usuario para gestionar reporte Propuesto
Hu28-3 Implementar historia de usuario de gestionar reporte Propuesto
Hu28-4 Realizar pruebas de implementación de gestionar reporte Propuesto
Hu29-1 Elaborar historia de usuario para gestionar bitacora Propuesto
Hu29-2 Diseñar interfaz de usuario para gestionar bitacora Propuesto
Hu29-3 Implementar historia de usuario de gestionar bitacora Propuesto
Hu29-4 Realizar pruebas de implementación de gestionar bitacora Propuesto
Hu30-1 Elaborar historia de usuario para gestionar backups Propuesto
Hu30-2 Diseñar interfaz de usuario para gestionar backups Propuesto
Hu30-3 Implementar historia de usuario de gestionar backups Propuesto
Hu30-4 Realizar pruebas de implementación de gestionar backups Propuesto
9.2.3 Reunión Diaria (Daily Scrum)
Por norma general la reunión diaria se la lleva a cabo en la primera hora de la
jornada, reuniones de no más de 15 minutos, cada día por todo el periodo del Sprint.
En nuestro caso se llevará a cabo dentro de cada 2 días, y cuando se pueda, cada día,
salvo los días festivos.

81
9.2.4 Sprint Review
Se lleva a cabo al final del Sprint, para inspeccionar el incremento y adaptar, si es
necesario, el Product Backlog. El Equipo Scrum y las partes interesadas colaboran durante
la revisión de lo que se hizo en el Sprint del sistema, y todo lo relacionado al MRP:
- Objetivo. - presentar al propietario del producto el trabajo realizado.

- El propietario del producto identifica lo que se ha "hecho" y lo que no se ha
"hecho".
- El equipo de desarrollo discute lo que anduvo bien durante el Sprint, resolviendo
algunas dudas sobre la base de datos para su mejor implementación.
- El equipo de desarrollo demuestra el trabajo que se ha "hecho" sobre el sistema a
desarrollar del MRP.
- El Scrum Master anuncia el lugar (por el momento sólo reuniones virtuales), y la
fecha de la próxima revisión.
9.2.5 Sprint Retrospective
Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un
plan de mejoras para ejecutar durante el siguiente sprint. El propósito de la retrospectiva de
Sprint es:
- Identificar qué cosas podemos cambiar para hacer el trabajo más agradable y
productivo acerca del Sistema a desarrollar, utilizando herramientas para la
implementación en las próximas iteraciones.
- Identificar los temas principales que salieron bien. - Creación de la base de datos,
identificar los casos de uso, algunas restricciones o limitaciones.
- Crear un plan para la implementación de mejoras con respecto a cómo el Equipo
Scrum hace su trabajo. - Podemos mejorar la implementación de algunas tareas de
la lista de trabajo dando una revisión más minuciosa y dar el resultado satisfactorio
del sistema.
82
83
9.2.6 Planificación de Scrum
Inicio del Sprint 4 de agosto, por un periodo de 7 días.
La estimación de las tareas será por horas.
Sólo se tomará los días laborales, por lo tanto, no se tomará los días sábados ni
domingos.
9.2.6.1 Elementos Pila de Sprint (Planificación de todas las tareas)
Nuestra planificación de todas las tareas está estimada en horas.
M X J V L M X
4-ago.
5-ago.
6-ago.
7-ago.
ago.
ago.
ago.
10-
11-
12-
DÍA 1 2 3 4 5 6 7
REAL RESPONSABLE ESTADO
TAREA ESTIMADO
Entrevista con Product Owner 4 0 Terrazas Sergio Pendiente
Explicar al Product Owner como funciona la
metodología a usar 1 0 Terrazas Sergio Pendiente
Justiniano
Explicar al Equipo una definición del problema 4 0 Alvaro Pendiente
Asignación de roles a los miembros del equipo 2 0 Terrazas Sergio Pendiente
Preparación del entorno de desarrollo de Mayta
programación 2 0 Jefferson Pendiente
Diseñar un modelo de base de datos 15 0 Terrazas Sergio Pendiente
Justiniano
Encontrar los casos de uso funcionales 10 0 Alvaro Pendiente
Elaborar historia de usuario para gestionar
usuario 0,5 0 Terrazas Sergio Pendiente
Diseñar interfaz de usuario para gestionar
usuario 1 0 Sosa Juan Pendiente
Implementar historia de usuario de gestionar
usuario 3 0 Sosa Juan Pendiente
Realizar pruebas de implementación de Justiniano
gestionar usuario 2 0 Alvaro Pendiente
empleado 0,5 0 Terrazas Sergio Pendiente
empleado 1 0 Pacheco Juan Pendiente
empleado 3 0 Pacheco Juan Pendiente
gestionar empleado 2 0 Alvaro Pendiente
sucursal 0,5 0 Terrazas Sergio Pendiente
sucursal 1 0 Pacheco Juan Pendiente
84

sucursal 3 0 Pacheco Juan Pendiente
gestionar sucursal 2 0 Alvaro Pendiente
departamento 0,5 0 Terrazas Sergio Pendiente
Diseñar interfaz de usuario para gestionar Mayta
departamento 1 0 Jefferson Pendiente
Implementar historia de usuario de gestionar Mayta
departamento 3 0 Jefferson Pendiente
gestionar departamento 2 0 Alvaro Pendiente
Elaborar historia de usuario para gestionar área 0,5 0 Terrazas Sergio Pendiente
Mayta
Diseñar interfaz de usuario para gestionar área 1 0 Jefferson Pendiente
Implementar historia de usuario de gestionar Mayta
área 3 0 Jefferson Pendiente
gestionar área 2 0 Alvaro Pendiente
Restante 70,5
0
Estimado 70,5 62 53 44 35 26 18 9
85
9.2.6.2 Lista de casos de uso (Web y Móvil)
Número Descripción Web Móvil

01 Gestionar Lista De Materiales X
02 Gestionar Inventario X X
03 Gestionar Reintegro X
04 Gestionar Orden De Producción X
05 Gestionar Orden De Compra X
06 Gestionar Reporte X X
07 Gestionar Cliente X
08 Gestionar Proveedor X
09 Gestionar Empleado X
10 Gestionar Materia Prima X
Gestionar Orden De
11 X
Aprovisionamiento
12 Gestionar Línea De Producción X X
13 Gestionar Tiempo Laborado X
14 Gestionar Planificación De Producción X X
15 Gestionar Seguimiento De Producción X X
16 Gestionar Articulo X
17 Gestionar Almacén X X
18 Gestionar Entrega De Trabajo X
19 Gestionar Departamento X X
20 Gestionar Área X X
21 Gestionar Orden De Transferencia X
22 Gestionar Proceso X
23 Gestionar Sucursal X
24 Gestionar Usuario X X
25 Gestionar Orden De Trabajo X
26 Gestionar Ingreso X
27 Gestionar Egreso X
28 Gestionar Reporte X X
29 Gestionar Bitácora X
30 Gestionar Backup X
86
9.2.6.3 Paquetes y Casos de Uso
pkg Personal
CU2: Gestionar
Empleado
«trace»
CU3: Gestionar
Personal Sucursal
«trace»
«trace»
CU4: Gestionar
Departamento
«trace»
CU5: Gestionar Area
pkg Personal
CU2: Gestionar
Empleado
«trace»
CU3: Gestionar
Personal Sucursal
«trace»
«trace»
CU4: Gestionar
Departamento
«trace»
CU5: Gestionar Area

87
pkg Usuario
CU1: Gestionar
Usuario
Usuario «trace»
«trace»
CU25: Administrar
Bitacora
pkg Reporte
CU24: Gestionar
Reporte
Reportes «trace»
«trace»
CU26: Administrar
Backup
88
pkg Inv entario
CU6: Gestionar
Almacen
CU7: Gestionar
Inv entario
«trace»
«trace»
CU9: Gestionar
Inv entario Materia Prima
«trace»
«trace» CU10: Gestionar

Articulo
«trace»

Reintegro
CU15: Gestionar
Transferencia
89
pkg Planificaion
CU11: Gestionar
Cliente
CU14: Gestionar Lista de
Materiales
CU17: Gestionar Orden de

Produccion
«trace»
«trace»

Proceso
Planificacion «trace»
CU19: Gestionar
«trace» Linea de Produccion
«trace»
CU20: Gestionar
«trace» Tiempo Laborado
«trace»
CU21: Gestionar
«trace» Entrega de Trabaj o
CU22: Gestionar
Seguimiento de
Produccion
CU23: Gestionar
Planificacion de
Produccion
9.2.6.4 Artefactos de Scrum
Los artefactos Scrum generados son todas aquellas tablas que ayudan o permiten el
avance de las tareas de Scrum, pueden estar las tablas, las gráficas de Burndown, etc.
90
9.2.6.5 Eventos de Scrum (Planificación de reunión diaria, revisión, retrospectiva, …)
Daily Scrum
Las reuniones que tuvimos al comenzar el Sprint por motivos externos de varios
integrantes, la realizamos cada 2 días, a las 4pm.
Reunión Diaria | Sprint 1

Día 1 y Día 2 Día 3 y Día 4 Día 5 y Día 6 Día 7
Desarrollador
13-ago. 14-ago. 17-ago. 18-ago. 19-ago. 20-ago. 21-ago.
Final de día del

Falta más Retraso de sprint las tareas
experiencia en la Regular avance avance de las fueron
Pacheco Juan Obs. herramienta de de las tareas, tareas. realizadas con
trabajo. problemas de Tareas tiempo.
Falta conocer sintaxis al crear realizadas de A falta de
más que hace el formulario y apuro, mejorar revisión de las
proceso. vistas. las vistas. vistas.
Falta de
experiencia con
los lenguajes de Poco avance de Avance de las
programación las tareas tareas Las tareas
Sosa Juan Obs. dados. asignadas. mejorable, finales fueron
Falta conocer Al final entrego corregir las entregadas.
más lo que hace las tareas, a validaciones de Falta corregir
el proceso de la falta de una la vista a algunos detalles
tarea. revisión. programar. de la vista.
Falta de
experiencia en Notable mejora
explicar las en avance de Falta mejorar la Finalización de
Mayta
Obs. tareas sus respectivas programación de las tareas muy
Jefferson asignadas a los tareas parte del cliente, tardía.
demás de asignadas. como la Mejorar la
equipo de Mejora de experiencia de programación de
desarrollo. programación. usuario. las vistas.
Sprint Review
La revisión se lo realizo el mismo día al finalizar el Sprint 1.
Stakeholders presentes en la revisión: por el momento solo participamos los
integrantes del grupo, sin los desarrolladores.
Fecha: 21 de agosto de 2020
Hora de inicio: 6:00pm
Hora de finalización: 6:45pm

91
Observaciones: como observación corregir errores ortográficos, cambiar el tamaño
de fuente a más legible, mejorar la línea de llenado al momento de registrar con la tecla
tabular.
Sprint Retrospective
La retrospectiva sprint se lleva a cabo el último día del periodo del Sprint 1.
Se lleva a cabo solo con el equipo scrum, y solo de aspecto de trabajo en equipo.
Puntos tratados:
Con respecto al avance de tareas por cada integrante se ha avanzado demasiado
lento, cabe destacar que cada uno hizo su mejor esfuerzo.
El avance entre el día 3 y 4 ha sido muy favorable, estando cerca de la línea de
tareas estimadas.
Entre los días 5 y 6 el equipo se encontró con un rendimiento bajo, encontrando
problemas al integrar sus ideas y desarrollo.
Falta coordinar aún más los tiempos de entrega de las tareas asignadas por cada
integrante.
Corregir la sintaxis que se usar al desarrollar el código de programación.

92
9.2.7 Prototipos principales

93
94
95
9.2.8 Desarrollo de las fases de Scrum
El desarrollo de Scrum indica 5: la reunión de planificación de Sprint, los Scrums
diarios, el trabajo de desarrollo, la Revisión del Sprint, y la Retrospectiva del Sprint. Que
serán desarrollados en el siguiente capítulo.
Nota: La planificación de sprint será en un día, los scrum diarios serán realizados en
la tarde del día, las estimaciones de las tareas serán horas, la revisión del sprint el mismo
día del último día del sprint.

96
10 CAPITULO 3 REQUERIMIENTOS
97
10.1 Propósito
Propósito general de los requisitos:
Identificar los requisitos específicos del sistema MRP, y mejorar aquellos requisitos
específicos en el Product backlog, detallando con claridad su proceso y finalidad.
Sprint 1:
Captura de requisitos y análisis de un sistema MRP, se junta el Sprint 0 y Sprint 1
en uno solo, para nivelar el avance de la materia.
10.2 Ámbito de Sistema

El sistema de información será desarrollado bajo en modelo SaaS, con algunas
funcionalidades para web o en su versión móvil.
Nota: Las funcionalidades en móvil serán programadas después de las Web, por
tanto, se espera realizarlas después del último sprint.
Los primeros cinco casos de uso serán desplegados en:
Nro. Caso de uso Web Móvil

1 Gestionar Usuario X X
2 Gestionar Empleado X
3 Gestionar Sucursal X
4 Gestionar Departamento X X
5 Gestionar Área X X
98
10.3 Equipo Scrum

El equipo Scrum de nuestro será principalmente de la siguiente manera:
Rol Integrantes Tareas Sprint #01
Scrum Master Sergio Ricardo Terrazas • A cargo de la realización de

Escobar la planificación del Sprint 1
Product Owner Alvaro Andres Justiniano • Brindar especificaciones
Herrera sobre lo que se requiere como
funcionalidades
Development Juan Antonio Sosa Pesoa • Gestionar usuario
Team • Gestionar empleado
Juan Daniel Pacheco Ardaya • Gestionar sucursal
Jefersson Mayta Gallardo • Gestionar departamento
• Gestionar área
10.4 Funciones del Producto

Las primeras funciones del Sprint serán las gestiones administrativas, además de la
fase inicial que comprenden la base de un sistema de información, generando los
respectivos artefactos que indican y da la metodología Scrum.
10.5 Requisitos Específicos

10.5.1 Product Backlog (Inicial) Planificación Inicial
ID id
Story Tarea Tarea DESCRIPCION DE LA TAREA Responsables Estado Sprint
Hu0-1 Entrevista con Product Owner

Explicar al Product Owner como funciona la metodología a
Hu0-2 usar Terrazas
Hu0-3 Explicar al Equipo una definición del problema Sergio,
idS-0 Fase Inicial Justiniano Pendiente 1
Hu0-4 Asignación de roles a los miembros del equipo Alvaro, Mayta
Hu0-5 Preparación del entorno de desarrollo de programación Jefferson
Hu0-6 Diseñar un modelo de base de datos
Hu0-7 Encontrar los casos de uso funcionales
Hu1-1 Elaborar historia de usuario para gestionar usuario
Gestionar Hu1-2 Diseñar interfaz de usuario para gestionar usuario
idS-1 Sosa Juan Pendiente 1
Usuario Hu1-3 Implementar historia de usuario de gestionar usuario
Hu1-4 Realizar pruebas de implementación de gestionar usuario
99
Hu2-1 Elaborar historia de usuario para gestionar empleado

Gestionar Hu2-2 Diseñar interfaz de usuario para gestionar empleado
idS-2 Pacheco Juan Pendiente 1
Empleado Hu2-3 Implementar historia de usuario de gestionar empleado
Hu2-4 Realizar pruebas de implementación de gestionar empleado
Hu3-1 Elaborar historia de usuario para gestionar sucursal
Gestionar Hu3-2 Diseñar interfaz de usuario para gestionar sucursal
Sucursal Hu3-3 Implementar historia de usuario de gestionar sucursal
Hu3-4 Realizar pruebas de implementación de gestionar sucursal
Hu4-1 Elaborar historia de usuario para gestionar departamento
Gestionar Hu4-2 Diseñar interfaz de usuario para gestionar departamento
Mayta
idS-4 Departamen Hu4-3 Implementar historia de usuario de gestionar departamento Jefferson
Pendiente 1
to Realizar pruebas de implementación de gestionar
Hu4-4 departamento
Hu5-1 Elaborar historia de usuario para gestionar área
Gestionar Hu5-2 Diseñar interfaz de usuario para gestionar área Mayta
idS-5 Jefferson
Pendiente 1
Área Hu5-3 Implementar historia de usuario de gestionar área
Hu5-4 Realizar pruebas de implementación de gestionar área
Hu6-1 Elaborar historia de usuario para gestionar almacén
Gestionar Hu6-2 Diseñar interfaz de usuario para gestionar almacén
Almacén Hu6-3 Implementar historia de usuario de gestionar almacén
Hu6-4 Realizar pruebas de implementación de gestionar almacén
Hu7-1 Elaborar historia de usuario para gestionar inventario
Gestionar Hu7-2 Diseñar interfaz de usuario para gestionar inventario
Inventario Hu7-3 Implementar historia de usuario de gestionar inventario
Hu7-4 Realizar pruebas de implementación de gestionar inventario
Hu8-1 Elaborar historia de usuario para gestionar proveedor
Gestionar Hu8-2 Diseñar interfaz de usuario para gestionar proveedor
Proveedor Hu8-3 Implementar historia de usuario de gestionar proveedor
Hu8-4 Realizar pruebas de implementación de gestionar proveedor
Hu9-1 Elaborar historia de usuario para gestionar materia prima
Gestionar Hu9-2 Diseñar interfaz de usuario para gestionar materia prima
idS-9 Materia Hu9-3 Implementar historia de usuario de gestionar materia prima Terrazas Sergio Pendiente 2
Prima Realizar pruebas de implementación de gestionar materia
Hu9-4 prima
Hu10-
1 Elaborar historia de usuario para gestionar articulo
Hu10-
Gestionar 2 Diseñar interfaz de usuario para gestionar articulo
idS-10 Terrazas Sergio Pendiente 2
Artículo Hu10-
3 Implementar historia de usuario de gestionar articulo
Hu10-
4 Realizar pruebas de implementación de gestionar articulo
Hu11-
1 Elaborar historia de usuario para gestionar cliente
Hu11-
Gestionar 2 Diseñar interfaz de usuario para gestionar cliente
Cliente Hu11-
3 Implementar historia de usuario de gestionar cliente
Hu11-
4 Realizar pruebas de implementación de gestionar cliente
Gestionar Hu12- Elaborar historia de usuario para gestionar orden de
Orden de 1 aprovisionamiento
100
Aprovisiona Hu12- Diseñar interfaz de usuario para gestionar orden de

miento 2 aprovisionamiento
Hu12- Implementar historia de usuario de gestionar orden de
3 aprovisionamiento
Hu12- Realizar pruebas de implementación de gestionar orden de
4 aprovisionamiento
Hu13-
1 Elaborar historia de usuario para gestionar orden de compra
Hu13-
Gestionar
2 Diseñar interfaz de usuario para gestionar orden de compra
idS-13 Orden de Terrazas Sergio Pendiente 3
Compra
3 compra
4 compra
Hu14-
1 Elaborar historia de usuario para gestionar lista de materiales
Hu14-
Gestionar
2 Diseñar interfaz de usuario para gestionar lista de materiales
idS-14 Lista de Sosa Juan Pendiente 3
Hu14- Implementar historia de usuario de gestionar lista de
Materiales
3 materiales
Hu14- Realizar pruebas de implementación de gestionar lista de
4 materiales
Hu15-
1 Elaborar historia de usuario para gestionar transferencia
Gestionar Hu15-
Orden de 2 Diseñar interfaz de usuario para gestionar transferencia
Transferenc Hu15-
ia 3 Implementar historia de usuario de gestionar transferencia
Hu15- Realizar pruebas de implementación de gestionar
4 transferencia
Hu16-
1 Elaborar historia de usuario para gestionar orden de trabajo
Hu16-
Gestionar
2 Diseñar interfaz de usuario para gestionar orden de trabajo
idS-16 Orden de Sosa Juan Pendiente 4
Hu16-
Trabajo
3 Implementar historia de usuario de gestionar orden de trabajo
4 trabajo
Hu17-
1 Elaborar historia de usuario para gestionar reintegro
Hu17-
Gestionar 2 Diseñar interfaz de usuario para gestionar reintegro
Reintegro Hu17-
3 Implementar historia de usuario de gestionar reintegro
Hu17-
4 Realizar pruebas de implementación de gestionar reintegro
Hu18- Elaborar historia de usuario para gestionar orden de
1 producción
Hu18- Diseñar interfaz de usuario para gestionar orden de
Gestionar
2 producción
Producción
3 producción
4 producción
101
Hu19-
1 Elaborar historia de usuario para gestionar proceso
Hu19-
Gestionar 2 Diseñar interfaz de usuario para gestionar proceso
Proceso Hu19-
3 Implementar historia de usuario de gestionar proceso
Hu19-
4 Realizar pruebas de implementación de gestionar proceso
Hu20- Elaborar historia de usuario para gestionar línea de
1 producción
Hu20- Diseñar interfaz de usuario para gestionar línea de
Gestionar
2 producción
idS-20 Línea de Pacheco Juan Pendiente 4
Hu20- Implementar historia de usuario de gestionar línea de
Producción
3 producción
Hu20- Realizar pruebas de implementación de gestionar línea de
4 producción
Hu21-
1 Elaborar historia de usuario para gestionar tiempo laborado
Hu21-
Gestionar
2 Diseñar interfaz de usuario para gestionar tiempo laborado
idS-21 Tiempo Pacheco Juan Pendiente 4
Hu21-
Laborado
3 Implementar historia de usuario de gestionar tiempo laborado
Hu21- Realizar pruebas de implementación de gestionar tiempo
4 laborado
Hu22-
1 Elaborar historia de usuario para gestionar entrega de trabajo
Hu22-
Gestionar
2 Diseñar interfaz de usuario para gestionar entrega de trabajo
idS-22 Entrega de Sosa Juan Pendiente 5
Hu22- Implementar historia de usuario de gestionar entrega de
Trabajo
3 trabajo
Hu22- Realizar pruebas de implementación de gestionar entrega de
4 trabajo
Hu23- Elaborar historia de usuario para gestionar seguimiento de
1 producción
Gestionar Hu23- Diseñar interfaz de usuario para gestionar seguimiento de
Seguimient 2 producción
o de Hu23- Implementar historia de usuario de gestionar seguimiento de
Producción 3 producción
4 seguimiento de producción
Hu24- Elaborar historia de usuario para gestionar planificación de
1 producción
Gestionar Hu24- Diseñar interfaz de usuario para gestionar planificación de
Planificació 2 producción
n de Hu24- Implementar historia de usuario de gestionar planificación de
4 planificación de producción
Hu25-
1 Elaborar historia de usuario para gestionar reportes
Gestionar Hu25-
Reportes 2 Diseñar interfaz de usuario para gestionar reportes
Hu25-
3 Implementar historia de usuario de gestionar reportes
102
Hu25-
4 Realizar pruebas de implementación de gestionar reportes
Hu26-
1 Elaborar historia de usuario para administrar bitácora
Hu26-
Gestionar 2 Diseñar interfaz de usuario para administrar bitácora
Bitácora Hu26-
3 Implementar historia de usuario de administrar bitácora
Hu26-
4 Realizar pruebas de implementación de administrar bitácora
Hu27-
1 Elaborar historia de usuario para administrar BackUps
Hu27-
Gestionar 2 Diseñar interfaz de usuario para administrar BackUps
BackUps Hu27-
3 Implementar historia de usuario de administrar BackUps
Hu27-
4 Realizar pruebas de implementación de administrar BackUps
103
10.5.2 Requisitos Funcionales
Identificación Requisito Funcional
idS-1 Gestionar Usuario
Aplicación Web y móvil

Nombre Gestionar Usuario
Tipo de Usuarios Administrador, Gerente
Estimación 6,5 horas
Iteración asignada Sprint 1
Debe tener los métodos que realiza, que se
visualice con colores distintos dependiendo de la
prioridad y etiquetas que describan el llenado
Características
correcto de cada atributo.
1.- Registrar Usuario

2.- Asignar Rol y Permiso
3.- Modificar Usuario
Criterios de 4.- Eliminar Usuario
Asignación 5.- Buscar o visualizar Usuario
Interface amigable, mostrar mensajes de datos

Requerimientos no incorrectos o no permitidos y al tercer intento
funcionales mostrara un ejemplo del dato permitido.
Alta
Prioridad del
Requerimiento
idS-2 Gestionar Empleado
Aplicación Web
Nombre Gestionar Empleado
Tipo de Usuarios Gerente, Empleado
Características
104
1.- Registrar Empleado

2.- Modificar Empleado
3.- Eliminar Empleado
Criterios de 4.- Buscar o visualizar Empleado
Asignación 5.- Ver perfil del Empleado

Baja
Prioridad del
Requerimiento
idS-3 Gestionar Sucursal
Aplicación web
Nombre Gestionar sucursal
Tipo de Usuarios Gerente, Administrador
Características
1.- Registrar Sucursal

2.- Modificar Sucursal
3.- Eliminar Sucursal
Criterios de 4.- Buscar o visualizar Sucursal
Asignación

Baja
Prioridad del
Requerimiento
105
idS-4 Gestionar Departamento

Nombre Gestionar Departamento
Características
1.- Registrar Departamento

2.- Modificar Departamento
3.- Eliminar Departamento
Criterios de 4.- Buscar o visualizar Departamento
Asignación 5.- Asignar Encargado
6.- Cambiar Encargado

Medio
Prioridad del
Requerimiento
idS-5 Gestionar Área

Nombre Gestionar Área
Características
1.- Registrar Área

106
2.- Modificar Área

3.- Eliminar Área
Criterios de 4.- Buscar o visualizar Área
Asignación 5.- Asignar Encargado
6.- Cambiar Encargado

Medio
Prioridad del
Requerimiento
107
10.6 Requisitos No Funcionales

• Mejoras en las fuentes y colores de las vistas.
• Actualización de los lenguajes de programación.
• Utilización de software de control de versiones.
• Utilización de herramientas de hojas de Excel para la documentación.
10.7 Restricciones
• El usuario debe estar identificado mediante un Login antes de poder hacer
uso del sistema de información.
• Cada proceso debe tener su conjunto partes relacionadas entre sí, con un
orden.
• El sistema debe permitir eliminar tuplas erróneas.
• El sistema debe disponer de una personalización de colores y fuentes.
10.8 Historias de Usuarios

Identificación Nombre de Historia
Usuario Cliente
Prioridad en negocio Alta
Programador responsable Sosa Juan
Riesgo en desarrollo regular
Iteración al que pertenece Sprint 1
Esta funcionalidad permitirá asignar claves
de acceso y ciertos permisos de acceso al
sistema.
Descripción
Además de crear ciertos usuarios según lo
requiera.
El administrador podrá visualizar las

transacciones de un determinado cliente.
Solicitar nombre usuario y contraseña.
Condición de Satisfacción
108
Debe estar autorizado para entrar al

sistema.
Validación
Usuario Administrador
Prioridad en negocio Normal
Programador responsable Pacheco Juan
Riesgo en desarrollo Regular
Esta funcionalidad permitirá gestionar los
distintos tipos de empleados que existirán
dentro del sistema. Tendrán claves de
Descripción acceso y ciertos permisos de acceso al
sistema.
Además de crear ciertos empleados según
lo requiera.
El administrador podrá visualizar los
empleados en orden de jerarquía dentro de
la empresa, fecha de antigüedad o
departamento al que pertenezca.
Personal solo autorizado para entrar a la

Validación
visualización de los empleados.
distintos tipos de Sucursales que existirán
dentro del sistema. Tendrán identificación
Descripción
según las políticas de negocio de la
empresa.
109
Además de crear sucursales nuevas si se lo

requiere.
El personal autorizado podrá visualizar las

sucursales en orden de jerarquía dentro de
la empresa, fecha de creación o la
Condición de Satisfacción ubicación.

Validación
visualización de las sucursales creadas
dentro del sistema.
Programador responsable Mayta Jefferson
distintos tipos de Departamentos que
existirán dentro de la empresa. Tendrán
Descripción identificación según las políticas de negocio
de la empresa.
Además de crear departamentos nuevos si
se lo requiere.
El personal autorizado podrá visualizar los

departamentos en orden de jerarquía dentro
de la empresa.
Tamaño del departamento según las
políticas de negocio de la empresa.

Validación
visualización de los departamentos.
110
distintos tipos de áreas existen dentro de la
empresa. Tendrán identificación según las
Descripción
Además de crear nuevas áreas si se lo
requiere dentro de la empresa.

áreas en orden de tamaño dentro de la
empresa.
Condición de Satisfacción Cantidad de personal dentro de un área
empresa.

Validación
visualización de un área.
Pantallas de las tareas realizadas:

111
112
10.9 Planificación Sprint (Diagrama de Gantt)

Nuestra planificación está sujeto a cambios, por posibles mejoras o errores. Con
posible incremento de un 6to sprint.
Diagrama de Gantt | A nivel de Tareas

5-ago. 9-ago. 13-ago. 17-ago. 21-ago. 25-ago. 29-ago. 2-sep. 6-sep. 10-sep. 14-sep. 18-sep. 22-sep.
Fase inicial
Gestionar Empleado
Gestionar Departamento
Gestionar Almacén
Gestionar Proveedor
Gestionar Artículo
Gestionar Orden de Aprovisionamiento
Gestionar Lista de Materiales
Gestionar Orden de Trabajo
Gestionar Orden de Producción
Gestionar Línea de Producción
Gestionar Entrega de Trabajo
Gestionar Planificación de Producción
Gestionar Bitácora
La planificación está prevista para 5 sprint, sujeto a cambios, si se presentan nuevas tareas
primordiales.
Sprint 2
Sprint 5
Sprint 4
Sprint 3
Sprint 1
05-ago
07-ago
09-ago
11-ago
13-ago
15-ago
17-ago
19-ago
21-ago
23-ago
25-ago
27-ago
29-ago
31-ago
02-sep
04-sep
06-sep
Diagrama de Gantt | A nivel de Sprint
08-sep
10-sep
12-sep
14-sep
16-sep
113
18-sep
20-sep
22-sep
114
CAPITULO 4 DISEÑO
115
11.1 Diseño del software utilizando el Modelo C4

Nivel 1 – Contexto
Diagrama de contexto del sistema MRP.
Nivel 2 – Diagrama Contenedor

116
11.2 Diseño de Arquitectura de UML
Diagrama de Secuencia para el proceso nuevo usuario-cliente

sd Cliente
<<CI>> <<CC>> CCliente <<CE>> Cliente <<CE>> Usuario

VCuentaUser
Usuario
Nuevo Usuario()
Nuevo Cliente()
Guardar Datos ()
Guardar Datos ()
Editar()
Verificar Datos ()
Obtener Datos()
Actualizar Datos()
Obtener Datos()
Actualizar Datos ()
117
11.3 Diseño de Datos

11.3.1 Diseño Lógico de Datos
Diagrama de Clases
class Modelo de Dominio
Encargado
- codigo: varchar
1 - email: varchar
- id: int
1 - nombre: varchar
- telefono: int
Cliente
- codigo: varchar Direccion Pais

- email: varchar
- id: int - codigo: varchar - codigo: varchar
Telefono 1 1 - descripcion: varchar - id: int
- nit: int
- codigo: varchar - nombreComercial: varchar - id: int - nombre: varchar
- id: int 1..* 1 - razonSocial: varchar 1..* 1
- nro: int
1 1..*
1
Poblacion Prov incia
- codigo: varchar - codigo: varchar

- descripcion: varchar 1..* 1 - descripcion: varchar
- id: int - id: int
1..*
OrdenEntrega
OrdenProduccion OrdenTrabaj o - codigo: varchar
1..* 1 1 - fecha: date 1
- codigo: varchar - codigo: varchar PlanProduccion - id: int
- descripcion: int - descripcion: varchar
1..* - - codigo: varchar - total: float
estado: varchar 1..* 1 - fecha: date
- id: int - id: int - descripcion
1 1 - fechaElaboracion Proceso
- id: int
1 - cantidad: int
1..* - codigo: varchar
DetalleTrabaj o - costo: float
1 - descripcion: varchar
- cantidad: int - id: int
- id: int - tiempoCreacion: float
1..*
1..*
1
1 1
Producto
Modelo ListaMateriales Ruta
- codigo: varchar
- codigo: varchar - compra: float - cantidadFabricacion: int - codigo: varchar
- descripcion: varchar 1 0..* - id: int 1 1..* - cantidadUso: float 1..* 1 - descripcion: varchar
- id: int - nombre: varchar - id: int - id: int
- precioVenta: float
1..*
1..* 1
Empleado
- cargo: varchar
1..
- codigo: varchar
1 - id: int
Fila 1 Prov eedor
- nombre: varchar
- telefono: int - codigo: varchar - ciudad
MateriaPrima
- descripcion: varchar CatalogoProv eedor - codigo
- id: int - codigo: varchar - direccion
- compra: float - estado: varchar
1 1 1..* - id: int 1..* 1 - nit
- id: int - nombre
- nombre: varchar - tiempoEspera: float
- telefono
1..* 1
Almacen Ubicacion
- codigo: varchar - id: int DetallePedido

1 1..*
- id: int - cantidad: int
1..*
- nroAlmacen: varchar 1..* - id: int
- subtotal: float
1..*
1
1
Estante
- codigo: varchar OrdenPedido

- id: int - codigo: varchar
Estado de la orden:
- estado: varchar
DetalleDiaria * En Espera
- fechaEntrega: date
* Entregado
- cantidad: int - fechaPedido: date
* Cancelado
1 - id: int - id: int
1..*
- total: float
1
1..*
ProduccionDiaria Inv entario
- codigo: varchar 1..* - id: int

- descripcion: varchar - stock: int 1..*
- fecha: date
- id: int
118
11.3.2 Diseño Físico
Tabla de Volumen
CLIENTE
ATRIBUTO TIPO DE DATO LLAVE NULO DESCRIPCIÓN
Código Texto (45) PK No Identificador del cliente
Email Texto (100) No Correo electrónico
Id Entero No Id del cliente del cliente
NIT Entero No Número de identificación tributaria
Nombre
Texto (100) No Nombre Comercial de la Empresa
Comercial
Razón Social Texto (100) No Tipo de Empresa
TELEFONO
Código Texto (45) PK No Códigos de los teléfonos
Id Entero No Identificador de los teléfonos
Número Entero No Número telefónico
ENCARGADO
Código Texto (45) PK No Identificador de la marca
Email Texto (100) No Correo electrónico
Id Entero No Identificador
Nombre Texto (45) No Nombre completo
Teléfono Entero No Número telefónico
ORDEN DE TRABAJO
Código Texto (45) PK No Código de Orden de Trabajo
Descripción Texto (45) No Descripción breve de Orden
Fecha Fecha No Fecha de la Orden
Id Entero No Identificador para el sistema
PRODUCTO
Código Texto (45) PK No Código de producto
Compra Entero con coma No Precio de producto
119
Nombre Texto (100) No Nombre comercial del producto
Precio Venta Entero con coma No Precio de venta del producto
MODELO
Código Texto (45) PK No Código de producto modelo
Descripción Texto (45) No Descripción breve de modelo
LISTA DE MATERIALES
CantidadFabricación Entero No Cantidad de un componente
Cantidad de uso de un
CantidadUso Entero con coma No
componente
Id Entero FK No Identificador de los componentes
RUTA
Código Texto (45) PK No Código único de rutas
Descripción Texto (45) No Descripción breve de rutas
PROCESO
Cantidad Entero No Cantidad específica de un solo proceso
Código Texto (45) PK No Código del Proceso
Costo Entero con coma No Costo del proceso
Descripción Texto (45) No Descripción breve de aquel proceso
Id Entero No Identificar
TiempoCreación Entero con coma No Tiempo estimado del proceso
MATERIA PRIMA
Código Texto (45) PK No Identificador de la Materia prima
Compra Entero con coma No Compra de materia prima
Nombre Texto No Nombre corto de materia prima
120
ALMACEN
Código Texto (45) PK No Código de Almacén
Descripción Texto (100) No Descripción breve de almacén
NroAlmacen Texto (10) No Numero único de almacén
ORDEN DE PEDIDO
Código Texto (45) PK No Código de Orden de Pedido
Estado Texto (10) Si Estado actual de la orden
fechaEntrega Fecha Si Fecha de Entrega
fechaPedido Fecha Si Fecha de pedido
Id Entero Si Identificador de Orden
Total Entero con coma Si Total de sumatoria de Orden
PLAN PRODUCCION
Código Texto (45) PK No Código de Plan de Producción
Descripción Texto (100) No Nombre de la forma de pago
Imagen Imagen No Imagen de la forma de pago
EMPLEADO
Código Texto (45) PK No Código de empleado
Cargo Texto (20) No Tipo de Cargo
Id Entero No Identificación de empleado
Teléfono Entero No Número telefónico
PRODUCCION DIARIA
Código Texto (45) PK No Código de Producción Diaria
Descripción Texto (100) No Descripción mínima de producción
Fecha Fecha No Fecha de producción diaria
121
INVENTARIO
codigoOrdenEntrega Texto (45) PK No Código de Entrega
codigoDetalleDiariaProducto Texto (45) PK No Detalle del producto
codigoDetalleDiariaProduccionDiaria Texto (45) PK No Código de Producción diaria
Stock Entero No Cantidad de producto
122
12 CAPITULO 5 IMPLEMENTACIÓN
123
Desarrollo de las fases de Scrum

a) Lista de Casos de uso del Sprint 1
Gestionar usuario
Gestionar empleado
Gestionar sucursal
Gestionar departamento
Gestionar área
b) Diagrama de Clase del Sprint 1
class Modelo Dominio
Area Departamento
- Codigo: varchar - Codigo: varchar

- Estado: boolean
1..* 1 - Estado: boolean
- Id: int - Id: int
- Nombre: varchar - Nombre: varchar
Empleado
1..*
- Cedula: varchar
- Codigo: varchar Historial Empleado
- Correo Electronico: varchar
- Direccion: varchar - Estado: boolean
- Edad: int 1 1..* - Id: int
- Estado: boolean
- Fecha Nacimiento: date
1..*
- Foto: varchar
- Id: int
- Nombre: varchar
1
- Telefono: int
Sucursal
- Codigo: varchar
- Descripcion: varchar
- Direccion: varchar
- Estado: boolean
- Id: int
- Nombre: varchar
La tabla de usuario no se muestra por privacidad del sistema de gestor bases de datos.
c) Objetivo del Sprint
Poner en marcha el inicio del sistema de información de un MRP, el inicio consta de:
- Página de Inicio
- Inicio de Sesión
- Vista general de las tareas que lleva un MRP
- Las tareas de los Casos de Uso

124
12.1 Sprint 1
12.1.1 Personal y Roles del Proyecto
Rol Integrantes
Product Owner Alvaro Andres Justiniano Herrera
Scrum Master Sergio Ricardo Terrazas Escobar
Development Team Juan Antonio Sosa Pesoa
Juan Daniel Pacheco Ardaya
Jefersson Mayta Gallardo
12.1.2 Planeación de la Iteración y ejecución de tareas de Product Backlog
ID id

Hu0-2 usar Terrazas
idS-0 Fase Inicial Justiniano Pendiente 1
Mayta
Pendiente 1
Hu4-4 departamento
Hu5-1 Elaborar historia de usuario para gestionar área
Gestionar Mayta
idS-5 Hu5-2 Diseñar interfaz de usuario para gestionar área Jefferson
Pendiente 1
Área
Hu5-3 Implementar historia de usuario de gestionar área
125
Hu5-4
Realizar pruebas de implementación de gestionar área
Hu6-1
Elaborar historia de usuario para gestionar almacén
Gestionar Hu6-2
Diseñar interfaz de usuario para gestionar almacén
Almacén Hu6-3
Implementar historia de usuario de gestionar almacén
Hu6-4
Realizar pruebas de implementación de gestionar almacén
Hu7-1
Elaborar historia de usuario para gestionar inventario
Gestionar Hu7-2
Diseñar interfaz de usuario para gestionar inventario
Inventario Hu7-3
Implementar historia de usuario de gestionar inventario
Hu7-4
Realizar pruebas de implementación de gestionar inventario
Hu8-1
Elaborar historia de usuario para gestionar proveedor
Gestionar Hu8-2
Diseñar interfaz de usuario para gestionar proveedor
Proveedor Hu8-3
Implementar historia de usuario de gestionar proveedor
Hu8-4
Realizar pruebas de implementación de gestionar proveedor
Hu9-1
Elaborar historia de usuario para gestionar materia prima
Gestionar Hu9-2
Diseñar interfaz de usuario para gestionar materia prima
idS-9 Materia Hu9-3
Implementar historia de usuario de gestionar materia prima Terrazas Sergio Pendiente 2
Hu9-4 prima
Hu10-
Hu10-
Artículo Hu10-
Hu10-
Hu11-
Hu11-
Cliente Hu11-
Hu11-
1 aprovisionamiento
Gestionar Hu12- Diseñar interfaz de usuario para gestionar orden de
Aprovisiona Hu12- Implementar historia de usuario de gestionar orden de
4 aprovisionamiento
Hu13-
Hu13-
Gestionar
Compra
3 compra
4 compra
Hu14-
126
Hu14-
Gestionar
Lista de
3 materiales
Materiales
4 materiales
Hu15-
Gestionar Hu15-
Transferenc Hu15-
4 transferencia
Hu16-
Hu16-
Gestionar
Hu16-
Trabajo
4 trabajo
Hu17-
Hu17-
Reintegro Hu17-
Hu17-
1 producción
Gestionar
2 producción
Producción
3 producción
4 producción
Hu19-
Hu19-
Proceso Hu19-
Hu19-
1 producción
Gestionar
2 producción
Producción
3 producción
4 producción
127
Hu21-
Hu21-
Gestionar
Hu21-
Laborado
4 laborado
Hu22-
Hu22-
Gestionar
Trabajo
3 trabajo
4 trabajo
1 producción
1 producción
Hu25-
Hu25-
Gestionar 2 Diseñar interfaz de usuario para gestionar reportes
Reportes Hu25-
Hu25-
Hu26-
Hu26-
Bitácora Hu26-
Hu26-
Hu27-
1 Elaborar historia de usuario para administrar BackUps
Gestionar Hu27-
BackUps 2 Diseñar interfaz de usuario para administrar BackUps
Hu27-
128
Hu27-
12.1.3 Historias de usuarios y prototipos
Usuario Cliente
Programador responsable Sosa Juan
Riesgo en desarrollo regular
Esta funcionalidad permitirá asignar claves
de acceso y ciertos permisos de acceso al
sistema.
Descripción
Además de crear ciertos usuarios según lo
requiera.
El administrador podrá visualizar las

transacciones de un determinado cliente.
Solicitar nombre usuario y contraseña.

sistema.
Validación
distintos tipos de empleados que existirán
dentro del sistema. Tendrán claves de
Descripción
acceso y ciertos permisos de acceso al
sistema.
129
Además de crear ciertos empleados según

lo requiera.
El administrador podrá visualizar los
empleados en orden de jerarquía dentro de
la empresa, fecha de antigüedad o
departamento al que pertenezca.

Validación
visualización de los empleados.
distintos tipos de Sucursales que existirán
dentro del sistema. Tendrán identificación
Descripción según las políticas de negocio de la
empresa.
Además de crear sucursales nuevas si se lo
requiere.

sucursales en orden de jerarquía dentro de
la empresa, fecha de creación o la
ubicación.

Validación
visualización de las sucursales creadas
dentro del sistema.
130

distintos tipos de Departamentos que
existirán dentro de la empresa. Tendrán
Descripción identificación según las políticas de negocio
de la empresa.
Además de crear departamentos nuevos si
se lo requiere.
El personal autorizado podrá visualizar los

departamentos en orden de jerarquía dentro
de la empresa.
Condición de Satisfacción Tamaño del departamento según las

Validación
visualización de los departamentos.
distintos tipos de áreas existen dentro de la
empresa. Tendrán identificación según las
Descripción
Además de crear nuevas áreas si se lo
requiere dentro de la empresa.

áreas en orden de tamaño dentro de la
empresa.
131
Cantidad de personal dentro de un área

empresa.
Validación Personal solo autorizado para entrar a la

visualización de un área.
Pantallas de las tareas realizadas:

132
12.1.4 Desarrollo del Sprint
12.1.4.1 Sprint Planning Meeting
Tiempo de Estimación en Horas.
Horas
RESPONSABLE STORY ID
TAREA ESTIMADO
Entrevista con Product Owner 4 Terrazas Sergio Hu0-1
Explicar al Product Owner como funciona la metodología a usar 1 Terrazas Sergio Hu0-2
Explicar al Equipo una definición del problema 4 Justiniano Alvaro Hu0-3
Asignación de roles a los miembros del equipo 2 Terrazas Sergio Hu0-4
Preparación del entorno de desarrollo de programación 2 Mayta Jefferson Hu0-5
Diseñar un modelo de base de datos 15 Terrazas Sergio Hu0-6
Encontrar los casos de uso funcionales 10 Justiniano Alvaro Hu0-7
Elaborar historia de usuario para gestionar usuario 0,5 Terrazas Sergio Hu1-1
Diseñar interfaz de usuario para gestionar usuario 1 Sosa Juan Hu1-2
Implementar historia de usuario de gestionar usuario 3 Sosa Juan Hu1-3
Realizar pruebas de implementación de gestionar usuario 2 Justiniano Alvaro Hu1-4
Elaborar historia de usuario para gestionar empleado 0,5 Terrazas Sergio Hu2-1
Diseñar interfaz de usuario para gestionar empleado 1 Pacheco Juan Hu2-2
Implementar historia de usuario de gestionar empleado 3 Pacheco Juan Hu2-3
Realizar pruebas de implementación de gestionar empleado 2 Justiniano Alvaro Hu2-4
Elaborar historia de usuario para gestionar sucursal 0,5 Terrazas Sergio Hu3-1
Diseñar interfaz de usuario para gestionar sucursal 1 Pacheco Juan Hu3-2
Implementar historia de usuario de gestionar sucursal 3 Pacheco Juan Hu3-3
133
Realizar pruebas de implementación de gestionar sucursal 2 Justiniano Alvaro Hu3-4

Elaborar historia de usuario para gestionar departamento 0,5 Terrazas Sergio Hu4-1
Diseñar interfaz de usuario para gestionar departamento 1 Mayta Jefferson Hu4-2
Implementar historia de usuario de gestionar departamento 3 Mayta Jefferson Hu4-3
Realizar pruebas de implementación de gestionar departamento 2 Justiniano Alvaro Hu4-4
Elaborar historia de usuario para gestionar área 0,5 Terrazas Sergio Hu5-1
Diseñar interfaz de usuario para gestionar área 1 Mayta Jefferson Hu5-2
Implementar historia de usuario de gestionar área 3 Mayta Jefferson Hu5-3
Realizar pruebas de implementación de gestionar área 2 Justiniano Alvaro Hu5-4
12.1.4.2 Daily Scrum
Las reuniones que tuvimos al comenzar el Sprint por motivos externos de varios
integrantes, la realizamos cada 2 días, a las 4pm.
Reunión Diaria | Sprint 1

Desarrollador
Final de día del

Falta más Retraso de sprint las tareas
experiencia en la Regular avance avance de las fueron
Pacheco Juan Obs. herramienta de de las tareas, tareas. realizadas con
trabajo. problemas de Tareas tiempo.
Falta conocer sintaxis al crear realizadas de A falta de
más que hace el formulario y apuro, mejorar revisión de las
proceso. vistas. las vistas. vistas.
Falta de
experiencia con
los lenguajes de Poco avance de Avance de las
programación las tareas tareas Las tareas
Sosa Juan Obs. dados. asignadas. mejorable, finales fueron
Falta conocer Al final entrego corregir las entregadas.
más lo que hace las tareas, a validaciones de Falta corregir
el proceso de la falta de una la vista a algunos detalles
tarea. revisión. programar. de la vista.
Falta de
experiencia en Notable mejora
explicar las en avance de Falta mejorar la Finalización de
Mayta
Obs. tareas sus respectivas programación de las tareas muy
Jefferson
asignadas a los tareas parte del cliente, tardía.
demás de asignadas. como la Mejorar la
equipo de Mejora de experiencia de programación de
desarrollo. programación. usuario. las vistas.
12.1.4.3 Sprint Review

134
Observaciones: como observación corregir errores ortográficos, cambiar el tamaño
de fuente a más legible, mejorar la línea de llenado al momento de registrar con la tecla
tabular.
12.1.4.4 Sprint Retrospective
Puntos tratados:
• Con respecto al avance de tareas por cada integrante se ha avanzado
demasiado lento, cabe destacar que cada uno hizo su mejor esfuerzo.
• El avance entre el día 3 y 4 ha sido muy favorable, estando cerca de la línea
de tareas estimadas.
• Entre los días 5 y 6 el equipo se encontró con un rendimiento bajo,
encontrando problemas al integrar sus ideas y desarrollo.
• Falta coordinar aún más los tiempos de entrega de las tareas asignadas por
cada integrante.
135
• Corregir la sintaxis que se usar al desarrollar el código de programación.
12.1.5 Burndown y BurnUp
80 Burndown Chart
70,5
70 64
61
60
49
50
40 36 35
Restante
30 23 Estimado
20
10
0
0
Gráfica Burndown del sprint 1.
12.1.6 Gráfica de esfuerzo y datos de esfuerzo
GRÁFICO DE ESFUERZO
Esfuerzo Pendiente
HORAS DE TRABAJO PENDIENTES
16
14
12
10
8
6
4
2
0
136
5-ago.
6-ago.
7-ago.
10-ago.
11-ago.
12-ago.
13-ago.
Terrazas Sergio 4 1 6 2 12
Justiniano Alvaro 2 2 4 2 1 3 10
Pacheco Juan 1 4 4
Sosa Juan 1 2 2
Mayta Jefferson 1 1 4 3 3
12.1.7 Scrum Taskboard

137
12.2 Sprint 2
12.2.1 Personal y Roles del Proyecto

Scrum Master Alvaro Andres Justiniano • Consultar al Product Owner
Herrera sobre ciertas dudas acerca de
ciertas funcionalidades
Product Owner Juan Antonio Sosa Pesoa • Mantenerse accesible a
preguntas del Scrum Master
Development Juan Daniel Pacheco Ardaya • Gestionar Almacén
Team • Gestionar Inventario
• Gestionar Proveedor
Sergio Ricardo Terrazas • Gestionar Materia Prima
Escobar • Gestionar Articulo
12.2.2 Planeación de la Iteración y ejecución de tareas de Product Backlog
ID id

Hu0-2 usar Terrazas
idS-0 Fase Inicial Justiniano Terminada 1
idS-1 Sosa Juan Terminada 1
idS-2 Pacheco Juan Terminada 1
idS-3 Pacheco Juan Terminada 1
Mayta
Terminada 1
Hu4-4 departamento
idS-5 Hu5-1 Elaborar historia de usuario para gestionar área Terminada 1
138
Hu5-2 Diseñar interfaz de usuario para gestionar área

Gestionar Mayta
Hu5-3 Implementar historia de usuario de gestionar área Jefferson
Área
Hu5-4 Realizar pruebas de implementación de gestionar área
Nueva
HuE0- Rediseñar la Justiniano
HuE0- Andres
Tarea 2
1 Página web
1 Rediseñar de nuevo la página web En curso
Hu6-1 Elaborar historia de usuario para gestionar almacén
Gestionar Hu6-2 Diseñar interfaz de usuario para gestionar almacén
idS-6 Pacheco Juan En curso 2
Almacén Hu6-3 Implementar historia de usuario de gestionar almacén
Hu6-4 Realizar pruebas de implementación de gestionar almacén
Hu7-1 Elaborar historia de usuario para gestionar inventario
Gestionar Hu7-2 Diseñar interfaz de usuario para gestionar inventario
Inventario Hu7-3 Implementar historia de usuario de gestionar inventario
Hu7-4 Realizar pruebas de implementación de gestionar inventario
Hu8-1 Elaborar historia de usuario para gestionar proveedor
Gestionar Hu8-2 Diseñar interfaz de usuario para gestionar proveedor
Proveedor Hu8-3 Implementar historia de usuario de gestionar proveedor
Hu8-4 Realizar pruebas de implementación de gestionar proveedor
Hu9-1 Elaborar historia de usuario para gestionar materia prima
Gestionar Hu9-2 Diseñar interfaz de usuario para gestionar materia prima
idS-9 Materia Hu9-3 Implementar historia de usuario de gestionar materia prima Terrazas Sergio En curso 2
Hu9-4 prima
Hu10-
Hu10-
idS-10 Terrazas Sergio En curso 2
Artículo Hu10-
Hu10-
Hu11-
Hu11-
Cliente Hu11-
Hu11-
1 aprovisionamiento
Gestionar Hu12- Diseñar interfaz de usuario para gestionar orden de
Aprovisiona Hu12- Implementar historia de usuario de gestionar orden de
4 aprovisionamiento
Hu13-
Gestionar
Hu13-
Compra
3 compra
139

4 compra
Hu14-
Hu14-
Gestionar
idS-14 Lista de Sosa Juan Pendiente 3
Materiales
3 materiales
4 materiales
Hu15-
Gestionar Hu15-
Transferenc Hu15-
4 transferencia
Hu16-
Hu16-
Gestionar
Hu16-
Trabajo
4 trabajo
Hu17-
Hu17-
Reintegro Hu17-
Hu17-
1 producción
Gestionar
2 producción
Producción
3 producción
4 producción
Hu19-
Hu19-
Proceso Hu19-
Hu19-
Gestionar
1 producción
Producción
2 producción
140

3 producción
4 producción
Hu21-
Hu21-
Gestionar
Hu21-
Laborado
4 laborado
Hu22-
Hu22-
Gestionar
Trabajo
3 trabajo
4 trabajo
1 producción
1 producción
Hu25-
Hu25-
Gestionar 2 Diseñar interfaz de usuario para gestionar reportes
Reportes Hu25-
Hu25-
Hu26-
Hu26-
Bitácora Hu26-
Hu26-
Gestionar Hu27-
BackUps 1 Elaborar historia de usuario para administrar BackUps
141
Hu27-
2 Diseñar interfaz de usuario para administrar BackUps
Hu27-
Hu27-
12.2.3 Historias de usuarios y prototipos
HuE0-1 Rediseñar la página web
UsuarioCliente
Prioridad en negocioAlta
Programador responsable Justiniano Alvaro Andres
Riesgo en desarrolloAlta
Se ha creado esta Historia de usuario para
el rediseño de la página web dando
prioridad a un nuevo diseño de un sistema
Descripción
MRP.
Se valora el diseño de limpio e intuitivo.

Debe seguir las normas de interfaz y
experiencia de usuario.

sistema.
Validación
142
143
12.2.4 Desarrollo del Sprint
12.2.4.1 Sprint Planning Meeting
DÍA
RESPONSABLE STORY ID
TAREA ESTIMADO
Rediseñar de nuevo la página web 30 Justiniano Alvaro HuE0-1
Elaborar historia de usuario para gestionar almacén 2 Pacheco Juan Hu6-1
Diseñar interfaz de usuario para gestionar almacén 4 Pacheco Juan Hu6-2
Implementar historia de usuario de gestionar almacén 6 Pacheco Juan Hu6-3
Realizar pruebas de implementación de gestionar almacén 2 Sosa Juan Hu6-4
Elaborar historia de usuario para gestionar inventario 2 Pacheco Juan Hu7-1
Diseñar interfaz de usuario para gestionar inventario 4 Pacheco Juan Hu7-2
144
Implementar historia de usuario de gestionar inventario 6 Pacheco Juan Hu7-3

Realizar pruebas de implementación de gestionar inventario 2 Sosa Juan Hu7-4
Elaborar historia de usuario para gestionar proveedor 2 Pacheco Juan Hu8-1
Diseñar interfaz de usuario para gestionar proveedor 4 Pacheco Juan Hu8-2
Implementar historia de usuario de gestionar proveedor 6 Pacheco Juan Hu8-3
Realizar pruebas de implementación de gestionar proveedor 2 Sosa Juan Hu8-4
Elaborar historia de usuario para gestionar materia prima 2 Terrazas Sergio Hu9-1
Diseñar interfaz de usuario para gestionar materia prima 4 Terrazas Sergio Hu9-2
Implementar historia de usuario de gestionar materia prima 6 Terrazas Sergio Hu9-3
Realizar pruebas de implementación de gestionar materia prima 2 Sosa Juan Hu9-4
Elaborar historia de usuario para gestionar articulo 2 Terrazas Sergio Hu10-1
Diseñar interfaz de usuario para gestionar articulo 4 Terrazas Sergio Hu10-2
Implementar historia de usuario de gestionar articulo 6 Terrazas Sergio Hu10-3
Realizar pruebas de implementación de gestionar articulo 2 Sosa Juan Hu10-4
12.2.4.2 Daily Scrum
Daily Metting Sprint 2

Desarrollador 14- 17- 18- 19- 20- 21- 24- 25-
ago. ago. ago. ago. ago. ago. ago. ago.
Se precisa que
le aumente
Justiniano Falta de vistas Rediseñar y
Obs.
Andres velocidad a la necesarias para Más velocidad terminar lo
hora de continuar las de último de la
programar. tareas. programación. página web.
Terrazas Sergio Obs. Diseño de la Avanzar algo de

vista no la tarea
terminada. asignada. No se avanzo No se avanzo
Pacheco Juan Obs. Diseño de la Avanzar algo de

vista no la tarea
terminada. asignada. No se avanzo No se avanzo
145
12.2.4.3 Sprint Review
Observaciones: como observación corregir el avance de las tareas, se atrasó
demasiado el rediseño de la página web.
Por el momento se ha deseñado conforme a un diseño de un sistema MRP.
12.2.4.4 Sprint Retrospective
Puntos tratados:
• Con respecto al avance de tareas por cada integrante se ha avanzado
demasiado lento, sobre todo por el rediseño de la pagina web.
• Se atrasó las tareas de los demás programadores por motivo de aun no
acabar las tareas anteriores.
• Las tareas atrasadas serán movidas al siguiente sprint.

146
12.2.5 Burndown y BurnUp
120
Burndown Chart
100
100 92
81
80 73 Restante
59 Estimado
60 50
41
40 31
20
0
-20
12.2.6 Gráfica de esfuerzo y datos de esfuerzo
Gráfico de esfuerzo
Esfuerzo…
Horas de trabajo pendientes
16
14
12
10
8
6
4
2
0
147
Gráfico individual
Terraz
as
Sergio 12
10
Horas pendientes
Justini
ano
8
Alvaro
6
Pache
co 4
Juan
2
Sosa
0
Juan
12.2.7 Scrum Taskboard

148
ANEXOS
Caso de Estudio 1
DESKERA MRP
OBJETIVO
La solución Deskera MRP lo ayuda a optimizar todo su proceso de fabricación,
desde la planificación de la producción y la programación del proceso, hasta la calidad,
el cumplimiento y el control de inventario, al tiempo que reduce los costos totales de
fabricación. Fabrica productos terminados a partir de materias primas y entrega pedidos de
ventas a tiempo con una rentabilidad óptima.
ALCANCE
Registrar datos del producto
Predecir los requisitos de material para las órdenes de trabajo y la producción
futura. Agregue nuevos productos y defina características del producto como BOM
multinivel, integración de inventario, fabricación discreta y de procesos, calidad y retro
lavado.
Administrar máquinas de fábrica
Defina máquinas activas y sustitutas, y etiquete máquinas para múltiples procesos,
centros de trabajo y mano de obra. Mapear máquinas a varios grupos de activos y
subgrupos. Gestionar el arrendamiento y la depreciación de máquinas. Monitoree los
horarios de mantenimiento de la máquina y rastree las averías de la máquina con
facilidad.
149
Administrar recursos laborales
Defina diferentes grupos laborales y asigne múltiples habilidades clave. Asigne
mano de obra a máquinas y órdenes de trabajo según su conjunto de habilidades,
resuelva conflictos de recursos y monitoree el costo de los recursos para obtener
resultados óptimos.
Seguimiento de las actividades del centro de trabajo
Cree centros de trabajo, defina la capacidad operativa del centro de trabajo, asigne
máquinas, mano de obra y productos a diferentes centros de trabajo y asigne un
gerente de planta a cada centro de trabajo.
Definir código de enrutamiento
Optimice el enrutamiento de fabricación definiendo la secuencia de enrutamiento
para productos y órdenes de trabajo. Cree plantillas de enrutamiento, códigos de
enrutamiento y asigne diferentes tareas o subtareas debajo de ellos.
Mantener contrato maestro
Mantenga un contrato maestro único para cada cliente con detalles completos
como el contacto del cliente, las condiciones de facturación y pago, y los requisitos de
envío y embalaje.
Administrar órdenes de trabajo
Administre las órdenes de trabajo de fabricación a pedido y fabricación a
pedido. Vincular órdenes de trabajo a órdenes de venta y contratos de venta. Defina
plantillas de enrutamiento, códigos y tareas para cada orden de trabajo. Rastree el estado
en tiempo real de la disponibilidad de componentes y el progreso de la tarea.
Generar programa maestro de producción
Definir un cronograma de producción para el uso de recursos y procesos para
fabricar productos para órdenes de trabajo. Modifique el cronograma de producción para
acomodar las necesidades del cliente.

150
Realizar controles de calidad
Configure parámetros de prueba de calidad para identificar problemas que van
desde la selección del material hasta la prueba del producto final. Inspeccione,
verifique y pruebe productos para garantizar una conformación de calidad.
Monitorear costos
Planifique los costos de fabricación específicos. Vea la diferencia en tiempo real
entre los costos estándar y los costos reales al mismo tiempo que administra varios tipos
de gastos generales de máquinas, materiales y mano de obra.
Planificar la entrega del producto
Mantenga registros de las direcciones de envío y facturación de todos los clientes
y proveedores. Defina métodos de embalaje internos o externos y defina los modos de
envío y entrega.
Pronóstico de demanda
Establezca varios criterios para las previsiones de demanda de productos y redacte
en diferentes plantillas. Ejercer métodos probados en toda la industria para pronosticar la
demanda. Defina pronósticos basados en ventas, órdenes de trabajo, tendencias
estacionales, etc.
151
152
Caso de Estudio 2
BLUESEER
OBJETIVO
BlueSeer ERP fue desarrollado para empresas de fabricación que desean
personalizar y mantener su propio software sin la necesidad de un soporte patentado de alto
costo o los obstáculos del código fuente patentado. El diseño, el conjunto de herramientas y
la disponibilidad de código abierto. lo convierte en un serio competidor para las empresas
que buscan soluciones de software mejores y menos costosas.
ALCANCE
Contabilidad
El módulo de contabilidad proporciona un libro mayor de doble entrada junto con
los módulos estándar Cuentas por cobrar y Cuentas por pagar
MRP
La funcionalidad MRP está estrechamente integrada con las compras, la
producción y el envío para proporcionarle una imagen coherente del estado de su
inventario y los requisitos de pedido.
Distribución
BlueSeer proporciona módulos de almacén / distribución para ayudar a la
distribución e inventario entre almacenes y ubicaciones de envío.

153
Producción
El seguimiento de la producción y los informes son estándar con informes
opcionales en todas las operaciones del producto u operación final, según sus necesidades.
Transporte
Las ofertas, los pedidos de flete y el estado de entrega son funciones disponibles
que se proporcionan mediante transacciones EDI entre transportistas y clientes.
Ventas
Las ventas, el envío y la distribución se simplifican para una operación simple con
informes de contabilidad automáticos y ajustes de uso de inventario al momento del envío.
Una variedad de gráficos e informes está disponible para el análisis de ventas.
Adquisitivo
Los módulos de compras y recepción cuentan con ajustes automáticos de
inventario y marcas de visibilidad de problemas de agotamiento de inventario pendientes.

154
Caso de Estudio 3
KATANA
OBJETIVOS
Katana le dirá automáticamente si tiene suficientes materias primas en stock para
comenzar la producción, cuándo pedir más, qué y cuánto le falta. También puedes comprar
lo que te falta de inmediato.
ALCANCE
Planeación de producción
- Prioridades de arrastrar y soltar para trabajos de fabricación
- Rastree la disponibilidad de los materiales requeridos
- Identificar los riesgos de demora relacionados con los plazos de entrega del
material
155
- Fechas precisas de finalización esperadas
- Obtenga información general del estado de producción en tiempo real desde
el nivel del piso
Control de inventario en tiempo real y optimización
- Control de inventario de productos terminados y materias primas.
- Transacciones de inventario automatizadas
- Control en mano, cantidades de stock comprometidas y esperadas en tiempo
real
- Mantenga niveles de inventario óptimos utilizando puntos de pedido
- Tomar decisiones precisas de fabricación y compra
- Administre fácilmente variantes de productos y materiales.
- Administre el inventario en varios almacenes.
Cumplimiento de pedidos de ventas
- Rastree la disponibilidad de los productos requeridos
- Arrastrar y soltar prioridades de pedidos de clientes
- Hacer a pedido o cumplir con el stock de productos disponibles
- Identifique los riesgos de demora en la entrega y vuelva a priorizar para
cumplir con los plazos
- Sincronice pedidos de ventas de múltiples canales en un solo tablero
Control de fabricación a nivel de piso
- Lista de tareas priorizadas para cada empleado de producción y línea de
producción.
- Lista de selección clara e instrucciones para cada orden de trabajo.
- Estados de "inicio - en progreso - completo" para órdenes de trabajo.

156
Adquisitivo
- Compras a tiempo basadas en requisitos de material claros
- Compra de materias primas faltantes de proveedores
- Rastree los riesgos de demora en la cadena de suministro
Costeo exacto
- Rastree los costos de fabricación reales basados en recetas de productos
(lista de materiales) y operaciones de producción
- Cree recetas de productos de varios niveles con subconjuntos
- Tome decisiones de precios precisas basadas en los márgenes reales del
producto
Integrado con servicios en línea.
- Sincronizar ventas con plataformas de comercio electrónico
- Enviar órdenes de venta a contabilidad para facturación
- Siga comprando sincronizado con la contabilidad

157
Bibliografía
https://es.wikipedia.org/wiki/Proceso_unificado
https://www.deskera.com/mrp/
https://www.blueseer.com/
https://katanamrp.com/

Perfil MRP

Cargado por

Información del documento

Título original

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

Perfil MRP

Cargado por

Copyright:

Formatos disponibles

Universidad Autónoma Gabriel René Moreno

Facultad de Ingeniería en Ciencias de la Computación y Telecomunicaciones

“Sistema de Procesos de Producción

Santa Cruz – Bolivia

1.1 Introducción .................................................................................................. 1

1.2 Antecedentes ................................................................................................. 2

1.3 Descripción Del Problema ............................................................................ 6

1.4 Formulación Del Problema ........................................................................... 9

1.5 Objetivos ....................................................................................................... 9

1.5.1 Objetivo General ..................................................................................... 9

1.5.2 Objeto Especifico .................................................................................... 9

1.6 Alcance ....................................................................................................... 10

1.7 Metodología ................................................................................................ 15

2 ELEMENTOS DEL SISTEMA BASADO EN COMPUTADORAS ............... 19

2.1 Hardware ..................................................................................................... 19

2.1.1 Servidor ................................................................................................. 19

2.1.2 Cliente ................................................................................................... 19

2.1.3 Medios de Comunicación ..................................................................... 19

2.1.4 Otros Dispositivos ................................................................................. 20

2.2 Software ...................................................................................................... 20

2.2.1 Servidor ................................................................................................. 20

2.2.2 Cliente ................................................................................................... 20

2.3 Datos ........................................................................................................... 21

2.4 Procesos ...................................................................................................... 23

2.5 Gente / Usuario ........................................................................................... 24

2.6 Documento .................................................................................................. 24

3 TECNOLOGÍA PARA EL DESARROLLO DEL SOFTWARE ...................... 26

3.1 Estrategia para el desarrollo del software ................................................... 26

3.2 Metodología para el desarrollo del software ............................................... 26

3.2.1 Características de la metodología SCRUM .......................................... 26

3.2.2 Características de UML ........................................................................ 28

3.3 Herramientas de desarrollo ......................................................................... 29

3.3.1 Software ................................................................................................ 29

3.3.2 Hardware ............................................................................................... 29

4 POSIBLES COSTOS ......................................................................................... 31

5 POSIBLES BENEFICIOS ................................................................................. 32

5.1 Tiempo ........................................................................................................ 32

5.2 Esfuerzo ...................................................................................................... 32

1 METODOLOGIA AGIL .................................................................................... 35

1.1 Propósito de Scrum ..................................................................................... 35

1.2 Visión General de Scrum ............................................................................ 35

1.3 El Equipo Scrum (Scrum Team) ................................................................. 36

1.4 El Dueño de Producto (Product Owner) ..................................................... 37

1.5 El Equipo de Desarrollo (Development Team) .......................................... 39

1.6 El Scrum Master ......................................................................................... 43

1.7 Eventos de Scrum ....................................................................................... 44

1.8 El Sprint ...................................................................................................... 45

1.9 Reunión de Planificación de Sprint (Sprint Planning Meeting).................. 46

1.10 Objetivo del Sprint (Sprint Goal) ................................................................ 48

1.11 Scrum Diario (Daily Scrum) ....................................................................... 49

1.12 Revisión de Sprint (Sprint Review) ............................................................ 51

1.13 Retrospectiva de Sprint (Sprint Retrospective)........................................... 52

1.14 Artefactos de Scrum .................................................................................... 53

1.15 Lista de Producto (Product Backlog) .......................................................... 53

1.16 Lista de Pendientes del Sprint (Sprint Backlog) ......................................... 56

1.16.1 Uso de la lista ...................................................................................... 56

1.16.2 El tablero de tareas (Scrum Taskboard) .............................................. 57

1.18 Transparencia de los Artefactos .................................................................. 58

1.19 Definición de ‘Terminado’ (Definition of ‘Done’) ..................................... 59

1.20 Ventajas y Desventajas ............................................................................... 60

1.21 Valores del Trabajo ..................................................................................... 61

1.21.1 Compromiso ........................................................................................ 61

1.21.3 Franqueza ............................................................................................ 63