Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Facultad de Ingeniería
Escuela de Ingeniería en Ciencias y Sistemas
FACULTAD DE INGENIERÍA
TRABAJO DE GRADUACIÓN
AL CONFERÍRSELE EL TÍTULO DE
1. SCRUM ....................................................................................................1
1.1. Componentes ............................................................................2
1.1.1. Roles ........................................................................2
1.1.1.1. El dueño del producto ............................2
1.1.1.2. El equipo de desarrollo ...........................3
1.1.1.3. Scrum master .........................................3
1.1.2. Artefactos..................................................................4
1.1.2.1. La pila del producto (backlog) ................4
1.1.2.2. La pila del sprint .....................................6
1.1.2.3. Incremento .............................................8
1.1.3. Eventos .....................................................................8
1.1.3.1. Sprint .....................................................8
1.1.3.2. Planificación del sprint ............................8
1.1.3.3. Scrum diario o reunión diaria ................10
1.1.3.4. Revisión del sprint ................................12
1.1.3.5. Retrospectiva .......................................13
1.2. Ciclo de vida ............................................................................13
1.3. Ventajas y desventajas ............................................................16
I
1.3.1. Ventajas ................................................................. 16
1.3.2. Desventajas ............................................................ 17
II
2.4.2. Trello.......................................................................32
2.4.3. Netflix ......................................................................34
CONCLUSIONES .............................................................................................87
RECOMENDACIONES .....................................................................................89
BIBLIOGRAFÍA .................................................................................................91
III
IV
ÍNDICE DE ILUSTRACIONES
FIGURAS
1. Burndown .............................................................................................11
2. Tablero de tareas .................................................................................12
3. Ciclo de vida de scrum .........................................................................14
4. Aplicaciones web .................................................................................20
5. Diseño de una aplicación web ..............................................................23
6. Back-end/Front-end .............................................................................27
7. Google Docs ........................................................................................32
8. Trello.com ............................................................................................34
9. netflix.com ............................................................................................35
10. Ejemplo de avances en el tablero de tareas en el desarrollo de la
aplicación de hoteles, primera reunión diaria .......................................43
11. Ejemplo de avances en el tablero de tareas en el desarrollo de la
aplicación de hoteles, segunda reunión ...............................................44
12. Burndown a la cuarta reunión diaria, asignación de cursos ..................56
13. Encuesta 1: conocer el nivel académico de los encuestados ...............77
14. Encuesta 2: ¿se dedica al desarrollo de software? ..............................77
15. Encuesta 3: ¿qué tipo de metodología prefieren seguir?......................78
16. Encuesta 4: ¿conoce la metodología scrum? .......................................78
17. Encuesta 5: ¿cómo conoció la metodología scrum? ............................79
18. Encuesta 6: personas que sí han utilizado scrum para desarrollar
software ...............................................................................................80
19. Encuesta 7: mayor reto que se enfrenta con la metodología ................81
20. Encuesta 8: los encuestados evalúan scrum como una metodología ...82
V
21. Encuesta 9: ¿están dispuestos a cambiar la metodología que
utilizan? ............................................................................................... 83
22. Encuesta 10: interesados en conocer más la metodología scrum........ 84
TABLAS
VI
XVII. Actividades agregadas a la pila del producto del Sistema de gestión
documental ..........................................................................................69
XVIII. Pila del segundo sprint del Sistema de gestión documental .................69
VII
VIII
LISTA DE SÍMBOLOS
Símbolo Significado
% Porcentaje
IX
X
GLOSARIO
XI
Google drive Servicio ofrecido de forma gratuita por Google que
brinda a los usuarios hasta 15 Gb de espacio de
almacenamiento en la web.
XII
Oracle Herramienta cliente/servidor para la gestión de
bases de datos.
XIII
Sitio web Conjunto de archivos electrónicos referentes a un
tema en particular y que se comparten a través de la
red.
XIV
RESUMEN
XV
observaciones de cambios o mejoras, a las cuales el equipo es capaz de
adaptarse fácilmente.
XVI
OBJETIVOS
General
Específicos
XVII
XVIII
INTRODUCCIÓN
XIX
XX
1. SCRUM
1
TAKEUCHI Hirotaka, NONAKA Ikujiro. The new new product development game. p. 5.
2
BECK Kent; BEEDLE Mike; VAN BENNEKUM Arie; COCKBURN Alistair, CUNNINGHAM
Ward; FOWLER Martin; GRENNING James; HIGHSMITH Jim; HUNT Andrew; JEFFRIES Ron;
KERN Jon; MARICK Brian; MARTIN Rober Cecil; MELLOR Steve; SCHWABER Ken,
SUTHERLAND Jeff y THOMAS Dave. Manifiesto por el desarrollo ágil de software. p. 187.
1
Las personas del negocio y los desarrolladores deben trabajar juntos de
forma cotidiana.
Un software que funciona es la principal medida de progreso.
1.1. Componentes
1.1.1. Roles
2
1.1.1.2. El equipo de desarrollo
3
1.1.2. Artefactos
4
Categoría: una categorización simple para identificar las historias como
backoffice u optimización.
Algún espacio para seguimiento de errores con lo que pudiera quedar de
la siguiente forma.
3
WAKE, Bill. INVEST in good stories, and SMART tasks. http://xp123.com/articles/invest-in-
good-stories-and-smart-tasks/. Consulta: 11 de octubre de 2016.
5
Negociables y negociadas con el equipo de desarrollo: las historias no
pueden ser inamovibles.
6
Es recomendable que las historias más grandes sean detalladas en tareas
más pequeñas, preferiblemente realizables en un día. Esto ayudará al control
del desarrollo del sprint. Cada tarea es asignada, entonces, a un miembro del
equipo para que la lleve a cabo.
Es importante que la pila del sprint sea pública para el equipo; puede
ponerse en una pizarra o en una pared con carteles para que todos la tengan
presente y puedan llevar el control de lo que ya se ha terminado. Durante el
sprint, la lista es actualizada con las tareas se han terminado y el esfuerzo que
hace falta en las tareas pendientes.
7
En el momento en que se define la pila del sprint, es posible aún negociar
con el dueño del producto; es decir, si este desea que se incluyan más historias
en el sprint, se le puede dar la opción de: mover las prioridades de tal forma que
C, D y E entren en el sprint en vez de B; de descomponer B en historias más
cortas, tal vez con distintas prioridades y de este modo entrarían algunas
subhistorias de B y C y D, por ejemplo. Lo importante es que las historias que
abarque el sprint sean siempre totalmente terminadas.
1.1.2.3. Incremento
1.1.3. Eventos
1.1.3.1. Sprint
8
los asistentes debe tener el tiempo suficiente; y se recomienda hacer pequeñas
pausas para relajarse y poder mantener la atención en el tema.
Meta del sprint: debe responder a la pregunta: ¿por qué está haciendo el
sprint?, en palabras que todos entiendan. Debe ser una acción que no se
ha logrado aún para darle sentido al trabajo y recordarle al equipo en
todo momento el porqué de su trabajo. Ejemplos de meta podrían ser:
ganar más dinero, o añadir soporte al backoffice.
Duración del sprint: depende del nivel de compromiso del equipo. Los
dueños del producto los prefieren más cortos y los desarrolladores los
prefieren más largos; es solamente cuestión de comprometerse ambas
partes e ir probando la duración perfecta para el equipo.
Elementos que formarán la pila del sprint: son tomadas de la pila del
producto. El equipo valora cuánto tiempo, ya sea en horas-hombre o
días-hombre, es necesario para cada historia de la pila y así se podrá
definir cuántas historias entrarán en el sprint. La tarea de estimar tiempos
suele ser compleja y pueden existir varias formas para hacerlo; según la
experiencia del equipo pueden basar sus estimaciones en cálculos
informales de cuánto tiempo les tomaría el desarrollo dependiendo de la
9
complejidad de cada historia; también, es posible estimar los tiempos
basados en el historial del equipo, si es que ya tienen tiempo trabajando
juntos o basados en los tiempos del sprint anterior, pueden proyectar el
tiempo que les tomará cada historia; por lo que la estimación más
complicada se da siempre cuando se trata del primer sprint.
10
al contrario, la reunión la dirige el equipo de desarrollo; se trata de socializar la
información, compartir los avances y solucionar problemas.
Figura 1. Burndown
12
del producto sobre las funcionalidades desarrolladas, la identificación de
posibles cambios en los requerimientos y la detección de errores.
1.1.3.5. Retrospectiva
13
Figura 3. Ciclo de vida de scrum
14
en el proceso, se debe considerar la posibilidad de que se llegue a un punto en
el que el equipo definitivamente no logre cumplir con las tareas programadas.
15
El ciclo se rompe o termina luego de la revisión del último sprint, es decir,
cuando ya se han desarrollado todas las historias de la pila del producto y se
presentan al cliente.
1.3.1. Ventajas
Dadas las reuniones diarias del equipo durante el sprint en las que se
plantean los problemas que el equipo pueda estar enfrentando, es
posible proyectar el cumplimiento que se alcanzará en relación al
incremento programado y, de no ser el esperado, es posible modificar el
orden de la pila o tomar algunas acciones correctivas que puedan ayudar
a que se logre cumplir con lo programado.
16
de desarrollo para cuando surjan dudas respecto a las funcionalidades
esperadas.
1.3.2. Desventajas
17
18
2. APLICACIONES WEB
19
Capa inferior: la persistencia de los datos, generalmente almacenados en
bases de datos. Existen varios manejadores de bases de datos: SQL,
MySQL, Oracle, entre otros. Esta última capa puede ser física con un
servidor encargado únicamente de almacenar los datos o simplemente
ser una capa conceptual y que los datos se almacenen en el mismo
servidor web.
20
El servidor ejecuta el código necesario para obtener los datos solicitados
por el cliente y envía estos datos de vuelta al cliente, en su defecto, envía
un mensaje de error.
2.1.1. Ventajas
21
Alta disponibilidad, puede ofrecerse el servicio desde múltiples puntos
para garantizar la disponibilidad.
2.1.2. Desventajas
2.2.1. Definición
22
Definir el aporte que la aplicación tendrá a los usuarios. Qué se les va a
ofrecer y qué necesidades estaría satisfaciendo.
2.2.2. Diseño
23
2.2.2.1. Diseño de la interfaz
Esta parte del diseño amarra el contenido, los usuarios y las políticas de
navegación. Es la forma en que el contenido se estructura y cómo la aplicación
maneja la interacción con el usuario, los mapas de navegación. Existen distintas
formas: la arquitectura lineal, en grid o jerárquica.
24
2.2.2.5. Diseño de navegación
2.2.3. Implementación
2.2.3.1. Front-end
25
JavaScript: lenguaje de programación interpretado del lado del cliente, lo
que significa que para ejecutarse no se necesita hacer otra petición al
servidor; es utilizado para hacer las aplicaciones web más dinámicas, por
ejemplo, al momento de hacer validaciones o agregar dinamismo a los
menús.
2.2.3.2. Back-end
26
Figura 6. Back-end / Front-end
2.2.4. Pruebas
27
Pero cuando se trata de una aplicación web, otro set de pruebas se hace
necesario dada la naturaleza del ambiente web y el uso de este tipo de
aplicaciones. Entre otras, se pueden mencionar las siguientes:
2.2.5. Liberación
28
2.3. Perfil de los involucrados en el desarrollo web
Photoshop
Flash
HTML y CSS
2.3.2. Maquetador
29
Photoshop
HTML y CSS
Javascript
HTML/CSS
Javascript, jQuery, JSON, AJAX
PHP y MySQL
Es el que desarrolla todo el código del lado del servidor. Debe estar
involucrado en todo el proceso de desarrollo, incluyendo el diseño, pues es el
encargado de diseñar la solución desde dentro; se encarga de los procesos de
manejo de datos y de la implementación de la lógica de la aplicación. Sus
herramientas son:
HTML/CSS
Javascript y jQuery
Lenguajes de programación: PHP, Ruby, etc.
Manejadores de bases de datos: MySQL, Oracle, etc.
30
2.3.5. Sysadmin
31
Aunque Google ofrece con su Google Drive espacio de disco para
almacenar los documentos, es posible también descargarlos a cualquier otro
dispositivo y en distintos formatos.
2.4.2. Trello
33
Figura 8. Trello.com
2.4.3. Netflix
34
solicita el servicio dando los datos de la tarjeta de crédito o cualquier otra forma
de pago en línea y el mismo puede cancelarse en cualquier momento.
Figura 9. netflix.com
35
36
3. IMPLEMENTACIÓN DE SCRUM PARA EL DESARROLLO
DE APLICACIONES WEB
37
De esta reunión, se genera, entonces, un listado de requerimientos que
podría quedar de la siguiente forma:
38
simplemente se pone de prioridad 225 se resuelve el problema sin mover
ninguna otra prioridad.
39
Sobre el trabajo del proyecto
o Pila del producto: tendrá el listado de todas las tareas del proyecto,
ordenadas por prioridad.
40
Primera reunión, planificación del primer sprint
Requerimiento Tareas
41
depende de que otra tarea esté terminada para poder iniciarse. Deciden
también quién será el encargado de ejecutar cada tarea.
7 1 Diseño de la página 8 M1 0
7 2 Programación de la página 16 M4 1
7 3 Test de la página 2 M2 2
42
datos. Mientras, tanto demás en el equipo pueden dedicarse a otro proyecto o
algunas otras tareas no relacionadas con este proyecto.
43
Figura 11. Ejemplo de avances en el tablero de tareas en el desarrollo
de la aplicación de hoteles, segunda reunión
Y el proceso se repite en cada reunión diaria, por los 4 días que dura el
sprint.
44
Además, indica que la carga de hoteles para la aplicación ya no se
realizará utilizando un formulario, como lo indicó al inicio, sino que ha
conseguido que de distintas ciudades le envíen un listado de hoteles con la
información de cada uno; estos listados serán archivos de extensión xls (de MS
Excel), pero los datos pueden venir hasta en 3 formatos distintos, dependiendo
las ciudades, por lo que la forma de cargarlos al sitio será subiendo el archivo y
que se haga un parseo de los datos para guardarlos en la base de datos. De
una vez se presentan los formatos.
Este nuevo requerimiento cambia la pila del producto, por lo que habrá
que renegociar el alcance y la duración del proyecto y, si el DP acepta los
términos de la negociación, hay que reorganizar las tareas a realizar.
45
solicitud del DP del cambio en la paleta de colores utilizada, su cuadro de
tareas para este segundo sprint queda de la siguiente manera:
7 1 Cambio de la paleta de 4 M1 0
colores de verde a azul
3 4 Test formato 1 2 M2 3
3 Test formato 2 2 M2 5
6
3 8 Test formato 3 2 M2 7
3 9 Diseño de la pantalla de 3 M1 0
subida de archivos
3 10 Programación de la pantalla 4 M3 9
de subida de los archivos
4 12 Diseño de la pantalla de 5 M1 0
búsqueda y entrega de
resultados
4 13 Programación de la 8 M4 12
búsqueda de hoteles
46
Continuación de la tabla VIII.
4 14 Programación de la pantalla 16 M3 13
de entrega de resultados
4 15 Test de la búsqueda y 3 M2 14
presentación de resultados
47
3.1.1.1. Análisis del ejemplo
48
En este segundo caso de estudio, cambia un poco el escenario, pues se
ha pedido apoyo a la escuela de Ingeniería en Ciencias y Sistemas de dicha
universidad para desarrollo por lo que el dueño del producto, DP en adelante,
es el coordinador del área de desarrollo de sistemas. Cuentan con el apoyo de
un catedrático que, por su experiencia, será el scrum master, SM en adelante.
El equipo de desarrollo está formado por 3 estudiantes del último año de la
carrera de Ingeniería en ciencias y sistemas, en adelante E1, E2 y E3, que
solamente pueden dedicarle medio día (4 horas diarias) al proyecto, pues tienen
otras obligaciones en seguimiento a sus cursos.
Cada curso tiene un listado de cursos que deben aprobarse antes; por lo
que el estudiante no podrá asignarse cursos sin cumplir con los
prerrequisitos.
49
El cuadro de requerimientos por parte del DP es el siguiente:
50
En la reunión de planificación del sprint, el equipo comienza con
descomponer los requerimientos en pequeñas tareas y valorándolas en
términos de horas de trabajo, a lo que se le llama puntos de historia. Al equipo
le tomó dos días terminar la planificación, pues los desarrolladores deben
atender sus cursos, motivo por el cual no pudieron extenderse más de las
cuatro horas que se ha acordado que se dedicarán al proyecto.
51
Tabla X. Desglose de tareas para cada requerimiento, asignación de
cursos en línea
52
Se entiende, entonces, que cada integrante del equipo dedicará 3 días en
la investigación del funcionamiento de la plataforma de la universidad; luego,
otros 2 días en realizar pruebas de integración con la misma.
53
Continuación de la tabla XI.
54
Cabe aclarar que se ha decidido que cada miembro del equipo es el
responsable de probar su trabajo de tal modo que cuando se mueve a la
columna de finalizado es porque está seguro de que funciona como debería
funcionar. Es responsabilidad de cada miembro mover los papelitos de las
tareas que tiene a su cargo para que de esta manera el tablero esté actualizado
todo el tiempo.
55
Entonces, ya han pasado tres días (12 horas por miembro del equipo) y el
trabajo que han avanzado es mínimo ya que solamente han realizado el trabajo
de la base de datos (8 horas) y han avanzado las 6 horas planificadas para el
diseño de todas las pantallas. La situación es crítica y se refleja en el burndown:
56
En la reunión del 8vo día, el equipo ha avanzado en conocer la plataforma
y ha realizado las pruebas de integración. Pero solamente les quedan 3 días de
trabajo que equivalen a 36 horas hombre de trabajo. En casos de retrasos tan
significativos en el sprint, se debe refinar la pila nuevamente y, de ser
necesario, eliminar historias (actividades) del mismo, ya que la duración del
sprint, una vez decidida, no es variable. El equipo, entonces, abarcará
solamente hasta la tarea con id 12, es decir, solamente desarrollarán las
páginas del login y de inicio tanto de estudiantes como de catedráticos, y
presentarán hasta allí el incremento del sprint, dejando fuera las siguientes
tareas:
57
en la cafetería. Es lo que se conoce como retrospectiva. En la reunión surgen
comentarios como:
58
Continuación de la tabla XIII.
59
Ahora bien, si el atraso se debe a la lentitud del equipo o que alguno de
los miembros tuviese razones para ausentarse del proyecto, igual puede
refinarse la pila o hacer cambios de asignación de las tareas, a manera de
compensar para tratar de no afectar el ritmo del trabajo. Incluso se pudiera
evaluar el agregar más personas al equipo.
60
El equipo de desarrolladores del proyecto es un grupo de 2
desarrolladores, D1 y D2 y un coordinador que generalmente actúa como scrum
master, SM. Tienen poco más de 3 años trabajando juntos, lo que indica que
han logrado combinar sus capacidades de tal forma que les ha permitido
desarrollar más de 8 proyectos juntos. Utilizan scrum desde hace poco más de
un año desarrollando en este tiempo 4 proyectos de éxito. Acostumbran hacer
sprints de 1 semana de duración (5 días) con jornadas laborales de 7 horas
diarias.
61
Al estar ingresado, el sistema debe indicarle a la persona destinataria
que tiene un documento nuevo y debe permitirle verlo y descargarlo a su
computadora, anotando la fecha y hora en que lo recibe.
62
Luego de la primera reunión del SM con el DP, acuerdan el desarrollo de
la aplicación para un tiempo máximo de 2 meses, con un cuadro de historias de
usuario de la siguiente forma:
3 Todos los tipos de usuario podrán hacer 400 Se ingresan los parámetros de búsqueda y
búsquedas de documentos. lista los coincidentes con el registro de la
fecha de entrada al sistema.
63
Como en los casos anteriores, la prioridad que se le da a cada historia se
califica con números no correlativos por si en algún momento se decide que
existe otro requerimiento que es más prioritario que el 4 pero menos prioritario
que el 3, y para no mover las prioridades de todos, solamente se encontraría un
número en medio de los dos que ya se tienen en el requerimiento 3 y 4, lo cual,
en proyectos que son muy grandes, evitará confusiones en la reorganización de
prioridades.
2 Diseño de la aplicación. 21
64
Continuación de la tabla XV.
3 10 Pruebas de búsquedas. 3
65
anterior, se seleccionan las siguientes actividades para generar el incremento
en el primer sprint:
Tabla XVI. Pila del primer sprint del sistema de gestión documental
2 Diseño de la aplicación. 21 D1
66
el diseño desde el inicio para luego no perder tiempo en diseñar por módulos la
aplicación como lo pueden preferir otros equipos de trabajo, no hay reglas para
esto.
67
El DP propone algunos cambios en el diseño de la aplicación, pero queda
satisfecho con el incremento que se le ha presentado.
68
Tabla XVII. Actividades agregadas a la pila del producto del sistema de
gestión documental
Tabla XVIII. Pila del segundo sprint del sistema de gestión documental
3 10 Pruebas de búsquedas. 3 D1
En la reunión del día 3, D2 notifica que debe ausentarse los días 4 y 5 por
razones personales, por lo que dejará la tarea 11 sin trabajar. D1 le explica al
equipo que va un poco complicado con sus tiempos también y que no está
seguro de poder terminar lo que se le asignó. El SM puede ver en el burndown
que definitivamente no completarán el incremento planificado con la tendencia
que llevan, por lo que lo mejor en este caso es refinar la pila y dejar fuera las
actividades 11 y 12. Con lo que se aseguran presentar un incremento hasta las
búsquedas de documentos, es menos de lo acordado, pero al menos será
funcional y potencialmente listo para salir a producción.
70
3.3.1. Análisis del ejemplo
71
72
4. ENCUESTA A ESTUDIANTES Y EGRESADOS DE
INGENIERÍA EN CIENCIAS Y SISTEMAS DE LA USAC
73
Aunque muchas personas utilizan indistintamente los términos
egresado y graduado, no significan lo mismo.
74
o En libros/Internet
o Por otras personas
o No he oído de scrum
Siendo 1: muy fácil y 5: muy difícil, ¿qué tan difícil considera que es
adoptar la metodología scrum para el desarrollo?
o 1
o 2
o 3
o 4
o 5
75
¿Estaría dispuesto a cambiar su actual metodología de trabajo por una
que le permita ir generando de forma ágil e incremental, pequeñas partes
funcionales, dándole la posibilidad de verificar los requerimientos y la
calidad de su producto?
o Sí
o No
4.2. Metodología
76
4.3. Resultados
77
De los 80 encuestados, un 70 % se dedica al desarrollo de software: que
un buen grupo para evaluar la metodología scrum en el desarrollo de
aplicaciones.
78
El 56,3 % de los encuestados conoce y ha implementado scrum,
solamente el 16,3 % nunca ha oído ni conoce de la metodología.
79
Figura 18. Encuesta 6: personas que sí han utilizado scrum para
desarrollar software
80
Figura 19. Encuesta 7: mayor reto que se enfrenta con la metodología
81
Figura 20. Encuesta 8: los encuestados evalúan scrum como una
metodología
82
Figura 21. Encuesta 9: ¿están dispuestos a cambiar la metodología que
utilizan?
83
Figura 22. Encuesta 10: interesados en conocer más la metodología
scrum
Entre los puntos más importantes a resaltar está el hecho de que dos
terceras partes: 66,3 % de los encuestados considera que utilizar acrum para el
desarrollo de aplicaciones si puede ayudar a mejorar los procesos.
84
La mayoría de los encuestados, el 53,5 % la considera una metodología
no muy difícil de adoptar; la mayor dificultad la capacidad de definir las historias
que se incluyen en cada sprint, con un 31,6 %, seguido de la dificultad en
mantener la comunicación con el dueño del producto, con un 26,3 %.
85
86
CONCLUSIONES
87
certeza en el tiempo que tomará el desarrollo hasta que esté lista para
salir a producción; la capacidad de medir estos tiempos con exactitud es
una ventaja en los equipos con experiencia en la utilización de scrum,
pues la metodología obliga a hacer este cálculo y luego a evaluarlo de tal
forma que cada vez sea más exacto.
88
RECOMENDACIONES
1. Dado que el cálculo del tiempo que toma el desarrollo de cada historia de
usuario es una de las mayores dificultades que un equipo enfrenta al
implementar scrum, es recomendable que utilicen tiempos de holgura,
sobre todo al principio, mientras el equipo va tomando experiencia y
midiendo su propio ritmo de trabajo para que con el tiempo los cálculos
sean más fáciles y certeros.
89
90
BIBLIOGRAFÍA
5. LUPETTI, Antonio. The woork papers No. 1: structured process you must
know to develop a web application. [En línea]. <https://css-
tricks.com/app-from-scratch-1-design/>. [Consulta: 18 de enero de
2017].
91
6. MATEU, Carles. Desarrollo de aplicaciones web. Barcelona, España:
Eureca media, 2014. 378 p.
92
14. TAKEUCHI, Hirotaka y NONAKA, Ikujiro. The new new product
development game. [En línea]. <https://hbr.org/1986/01/the-new-
new-product-development-game>. [Consulta: 18 de enero de
2017].
16. WAKE, Bill. INVEST in good stories, and SMART tasks. [En línea].
<http:// xp 123.com / articles / invest-in-good-stories-and-smart-
tasks / >. [Consulta: 18 de enero de 2017].
93
94