Módulo 2.

Enfoques y metodologías en la gestión

de proyectos

En el presente módulo abordaremos los enfoques y metodologías en la gestión de proyectos,

buscaremos entenderlos en su complejidad y desde sus enfoques tradicionales.
Una vez hecho este primer recorrido, podremos entender los nuevos requerimientos del
mercado y abordar las metodologías ágiles en su complejidad.

Video de inmersión

2.1 Complejidad y enfoques tradicionales

2.2 Metodologías ágiles

Anexo: mani esto ágil

GLOSARIO

Video de habilidades

Cierre
Referencias

Descargá la lectura
Lección 1 de 9

Video de inmersión

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms
Lección 2 de 9

2.1 Complejidad y enfoques tradicionales

2.1.1 Complejidad de los proyectos

La complejidad de todo proyecto que debamos gestionar se encuentra condicionada por diversos factores
que determinan que un proyecto sea más o menos complejo. Esos factores son los siguientes:

1 Nivel de conocimiento de las herramientas y medios necesarios para lograr el éxito del
proyecto. Por ejemplo, el nivel de conocimiento sobre la industria en la que se debe
desempeñar el proyecto o de las tecnologías inherentes a él.

2 Nivel de claridad o de detalle en el pedido del proyecto. Por ejemplo, requerimientos poco
detallados o muy detallados, cambiantes o ambiguos por parte del cliente del proyecto.

La Figura 1 muestra los diferentes grados de complejidad de los requisitos a cumplir y de las
herramientas que necesitamos para trabajar según el nivel de conocimiento que tenemos.

Figura 1. Complejidad de los proyectos

 Fuente: Elaboración propia.

¿Cómo gestionamos la complejidad de los proyectos?

Básicamente, podemos agrupar en dos las maneras de manejar la complejidad de un proyecto: con
metodología en cascada o con metodologías ágiles.

Metodología tradicional o en cascada: es una metodología de gestión de proyectos que se aplica en

proyectos simples, en los cuales los requerimientos a cumplir están lo suficientemente bien detallados al
inicio del proyecto, de manera que no sea necesario hacer un segundo análisis más profundo durante la
vida del proyecto. En estos casos, contamos con un conocimiento de las herramientas necesarias para
gestionar el proyecto de manera de evitar reprocesos o complejidades. En otras palabras, aplicar este
tipo de metodología implica tener un conocimiento total y detallado de lo que se pretende lograr al final
del proyecto.
Metodologías ágiles: es una metodología de gestión de proyectos que se aplica en proyectos
complejos, en los cuales el nivel de conocimiento de los requerimientos no es total ni detallado al inicio y
para los cuales no contamos con el nivel de conocimiento necesario sobre las herramientas para
desarrollarlos con normalidad. Se incluyen múltiples revisiones llevadas a cabo de manera minuciosa y
sistemática que permiten ir refinando el proyecto a medidas que avanza.

Figura 2. Relación entre la complejidad de los proyectos y las

metodologías de gestión de proyectos

Fuente: Elaboración propia.

2.1.2 Metodologías tradicionales o en

cascada

Queda claro que los proyectos sencillos pueden llevarse a cabo con una metodología de gestión de
proyectos simple en la que se sigue una sucesión de pasos y secuencias ordenadas para llegar a
cumplir con el objetivo del proyecto. En la Figura 3, se puede ver esta metodología representada de
forma gráfica.
Figura 3. Metodologías tradicionales o en cascada

Fuente: Elaboración propia.

A continuación, se enumeran algunas particularidades a tener en cuenta sobre esta metodología de

gestión de proyectos en cascada.

La intervención del cliente se da dos veces: una al inicio (al definir las necesidades del
proyecto) y otra al final (al recibir los resultados del proyecto).

El proceso es totalmente desconocido para el cliente.

El desarrollo es secuencial; es decir que se avanza en el proyecto a medida que se van

concretando pasos de trabajo. Por este motivo, se la conoce como metodología en
cascada.

Los cambios no son bienvenidos, ya que requieren una gestión muy burocrática.

¿Qué complejidades puede tener esta modalidad de gestión de

proyectos?
El cliente del proyecto no tiene posibilidad de ver un adelanto de lo que será, sino que se encontrará con
el producto terminado tal cual como lo describió varios meses atrás. ¿Y si al ver el producto no era lo
que imaginaba o necesitaba?

Reflexión

¿Cuántas veces alguien sabe todos los detalles de los requerimientos de un proyecto a su inicio? La
respuesta depende del rubro, pero en general, esto sucede muy pocas veces.

Retomando el tema de la complejidad, se puede decir que con esta metodología se debe comenzar el
proyecto con todos los requerimientos muy claros y detallados, porque cualquier cambio implica un alto
costo durante la vida del proyecto. De acuerdo con el rubro del proyecto, esta metodología puede o no
ser apropiada. Hay campos de acción mucho más estables y menos dinámicos que otros. A
continuación, se analizan algunos casos.

Proyectos de construcción: hay pocas probabilidades de que, una vez hechos los
cimientos, el dueño quiera achicar el living de la casa (pero puede pasar).

Proyectos de software: hay muchas probabilidades de que, una vez hecho el análisis del
sistema a construir, el dueño quiera agregar o cambiar funcionalidades.

¿Qué particularidades deben cumplir los interesados de un proyecto

llevado adelante bajo esta metodología de gestión?

Equipo de trabajo
Generalmente, los equipos de trabajo en los proyectos ejecutados en cascada suelen ser especializados.
Esto significa que hay un analista que entiende del rubro y conoce la problemática a resolver, hay un
diseñador de soluciones experto en las herramientas necesarias para ejecutar las tareas, hay gente que
sabe ejecutar las tareas en sí y hay gente que valida, verifica o prueba el producto antes de entregarlo.
Son roles muy separados en los que cada uno hace lo que sabe hacer, con muy poco acople entre ellos.

Intervención del cliente

Como dijimos antes, el cliente prácticamente no participa durante la ejecución del proyecto. Solo forma
parte del proceso al inicio y al final. Una vez comenzado el proyecto, el único objetivo es cumplir con el
plan de proyecto pactado con el cliente.

Control de cambios

La metodología en cascada no es ágil frente a los cambios. Se invierte mucho esfuerzo y tiempo en la
etapa de análisis para conseguir una foto completa y acabada de lo que el cliente necesita. El modelo en
cascada prevé un comité de control de cambios (CCC) encargado de evaluar el impacto de los cambios
que solicite el cliente una vez comenzado el proyecto. El CCC debe autorizar o no el cambio propuesto,
evaluar los desvíos que provoque y volver a estimar las tareas restantes (o el retrabajo) que implique
este imprevisto.

2.1.3 Aplicabilidad a cierto tipo de

proyectos

¿Problemas?

¿Qué problemas tiene esta metodología? Los problemas no son de la metodología en sí, sino que son
relativos al contexto en el que se utilice. Si miramos los resultados de los proyectos en los últimos diez
años, nos encontramos con cifras alarmantes. Tomemos la industria del software para ejemplificar con
números esta situación, aunque podría proyectarse a muchas otras disciplinas.
Según un estudio de la Universidad del Caribe, las cifras que resultan del análisis de cientos de
proyectos son las siguientes.

El 31% de los proyectos se cancelarán antes de que finalicen.

El 53% de los proyectos costarán 189% más de lo que se estimó originalmente.

El 75% de los productos de software grandes tienen fallas. Esto hace que no se usen
porque no cumplen con los requerimientos del cliente.

Pero ¿cuáles son las causas de estos fracasos? Según la misma entidad, son las siguientes:

1 requerimientos incompletos;

2 deficiencia en el involucramiento del usuario;

3 deficiencia de recursos;

4 expectativas no realistas.

¿Dónde nacen estos errores? ¿En qué etapa del proyecto?

el 56% nace en la etapa de análisis.

el 10% nace en la etapa de diseño;

el 7% nace en la etapa de construcción;

el 27% nace en otros momentos del proceso.

Los problemas reales surgen cuando se quiere utilizar una metodología de cascada en proyectos que no
ofrecen las condiciones para que esta funcione correctamente. Esto ocurre en los siguientes casos:

El cliente no tiene claro lo que quiere al inicio del proyecto, solo tiene las ideas principales.

El cliente no participa de la evolución del proyecto, sino que solo espera el final del
proyecto para ver su producto terminado.

El conocimiento de las herramientas para ejecutar el proyecto es

escaso (gráfico de la complejidad).

2.1.4 El mercado pide otra cosa

El mundo y el mercado evolucionan tan rápidamente que así también lo hacen las necesidades de la
gente. Esto hace que sea extremadamente difícil poder determinar el 100% del detalle de lo que se
necesita antes de comenzar un proyecto. Los problemas aparecen al querer continuar utilizando la
misma metodología en proyectos con necesidades dinámicas y cambiantes. La misma agilidad con la
que comenzó a evolucionar el mercado es la que hizo que surgieran las llamadas metodologías ágiles.

En la actualidad, los proyectos demandan uno de los siguientes tipos de gestión

de proyectos.

gestiones estáticas;
metodologías ágiles;

metodologías secuenciales;

metodologías complejas.

SUBMIT
Lección 3 de 9

2.2 Metodologías ágiles

2.2.1 ¿Qué es SCRUM?

Nos toca ahora profundizar sobre las metodologías ágiles para la gestión de proyectos y, el SCRUM es
una de ellas.

¿Qué ocurre cuando no están del todo claros los requerimientos al inicio del proyecto, pero sí se tiene en
claro el objetivo o necesidad final? Este no es un problema aislado, sino que ocurre en la mayoría de las
industrias. El dinamismo con el que se mueven el mercado y el mundo hace que sean muy aisladas las
situaciones en las que se tiene la posibilidad de tener un alcance detallado al iniciar los proyectos.

Las metodologías ágiles han llegado para ayudar con esta situación. A diferencia de las metodologías
tradicionales o en cascada, estos enfoques plantean n ciclos (y no solamente uno). Cada ciclo va
construyendo parcialmente el producto. Siempre hay un resultado por cada ciclo y esto permite que el
cliente tenga la posibilidad de ver la evolución de lo que se está construyendo. Con esto se evitan las
grandes desviaciones que existen cuando no hay intervención de los clientes hasta la finalización del
producto.

En las metodologías ágiles, los cambios son bienvenidos y se plantea una respuesta rápida a esos
cambios. Los integrantes del equipo no tienen conocimientos tan específicos, sino que van ocupando
roles que pueden rotar. Es un ambiente colaborativo, donde todos colaboran con todos.

SCRUM es el nombre que recibe un conjunto de buenas prácticas que buscan ayudar a gestionar de la
mejor manera proyectos complejos. Es decir, escenarios en los cuales no tenemos total control de los
requerimientos ni de las herramientas necesarios para construirlos. SCRUM se basa en los ciclos de vida
iterativos y adaptativos y, además, agrega varias reglas de juego que se deben cumplir si se quiere sacar
todo el provecho posible del uso de estas buenas prácticas y de lo que ellas nos pueden mostrar. Un
SCRUM bien implementado logra llegar a un mejor producto y a un mejor proceso y ambos habrán
madurado cuantitativamente al final del proyecto. Por otra parte, pone especial foco en la intervención del
cliente durante todo el proyecto. Este proyecto es el resultado de una serie de iteraciones cortas cuya
responsabilidad es agregar valor al producto en cada una de ellas.

Figura 4. Ciclo de vida de SCRUM

Fuente: [Imagen sin título sobre el método ágil SCRUM], s. f., https://bit.ly/3d0srrI
En la Figura 4 se describe el proceso de trabajo que propone SCRUM. Vamos por partes. Recordemos
que este enfoque se adapta muy bien a escenarios en donde el cliente sabe la estrategia, pero no tiene
claridad sobre cómo avanzar en el proyecto.

SCRUM es una metodología de gestión de proyectos que brinda:

buenas prácticas;

buenas prácticas, herramientas y roles de gestión;

metodologías secuenciales;

buenas prácticas y roles de trabajo.

SUBMIT

2.2.2 Personas involucradas en un

ciclo SCRUM

¿Quiénes participan de esta metodología?

 1 Product Owner: es el representante del cliente en el proceso y tiene la responsabilidad de
aclarar la necesidad que este tiene.

2 Scrum Master: es el líder del equipo de trabajo; es un facilitador de la gestión de trabajo.

Asegura el foco de gestión del equipo y las prácticas de la metodología SCRUM.

3 Team: es el equipo de trabajo conformado por personas altamente capacitadas que

ejecutarán las distintas tareas del proyecto.

Figura 5. Roles presentes en la metodología SCRUM

Fuente: Elaboración propia.

El equipo debe ser estable durante el proyecto: debe cambiar lo mínimo posible. La autoorganización
lleva tiempo, implica que ya las personas se conocen, que cada uno sabe lo que el otro puede dar, y que
hay una base de confianza establecida e implícita que permite que los quehaceres del día a día fluyan
con mayor naturalidad.

El ciclo de vida de la metodología SCRUM

Luego de haber presentado a los intervinientes, podemos detallar el proceso de trabajo de la siguiente
manera.

1 El Product Owner elabora un documento denominado Product Backlog en el que se incluyen

todas las necesidades, los requisitos y las ideas del cliente.

2 Luego, les presenta ese documento al Scrum Master y al Team en una reunión denominada
Sprint Planning Meeting.

3 Allí se define una primera fase de trabajo que se detalla en un documento denominado
Sprint Backlog y que deberá resolverse en un Sprint (un tiempo que dura entre una y cuatro
semanas).

4 En el Sprint intervienen el Scrum Master y el Team para desarrollar ese producto según las
necesidades del cliente.

5 A diario debe realizarse una reunión, denominada Daily Scrum (de menos de quince minutos
y con la ayuda de un tablero estilo Kanban en el cual las actividades se clasifican en “por
hacer”, “en proceso” y “finalizadas”). En esta reunión, cada miembro del equipo cuenta:

qué hicieron el día anterior;

qué harán el día de hoy;

 qué harán mañana;

qué problemas han encontrado.

6 Al finalizar el Sprint, se lleva a cabo una reunión denominada Sprint Review en la cual
participan todos los roles y revisan el cumplimento de los objetivos del Sprint para poder
entregar el producto.

7 Luego de entregar el producto, se realiza una última reunión denominada Sprint

Retrospective en la que se reúne todo el equipo para analizar:

qué cosas estuvieron bien hechas;

qué cosas podrían haber sido mejores con el fin de mejorar en la

próxima iteración.

8 Por último, se vuelve al Producto Backlog y se inicia nuevamente el Sprint Backlog hasta
contar con todo el producto finalizado.

2.2.3 Actividades y herramientas

Figura 6. Las actividades del SCRUM

 Fuente: Elaboración propia.

En SCRUM, cada iteración entrega valor parcial al producto final. Se dice que debe haber un incremento
del producto al finalizar cada Sprint, ya que se intenta obtener un crecimiento orgánico del producto final.

Resulta oportuno realizar un resumen sobre las herramientas que utiliza la metodología SCRUM.

Figura 7. Las actividades del SCRUM

 Fuente: Elaboración propia.

Figura 8. Tablero de metodología Kanban.

 Fuente: [Imagen sin título sobre Kanban], s. f., https://bit.ly/3f2wA00.

También se pueden considerar algunas herramientas digitales para llevar a cabo el tablero de trabajo.
Una de ellas puede ser Trello (Trello.com), una herramienta digital colaborativa con una dinámica de red
social (con miembros, comentarios, notificaciones, etiquetas, etcétera) que permite organizar tareas en
diferentes tableros, por lo que resulta oportuna para simular los tableros Kanban necesarios para las
Daily Scrum.

Figura 9. Trello (Trello.com)

 Fuente: Captura de pantalla de blog.trello.com.

¿En cuál de las buenas prácticas compartidas por SCRUM es útil tener presente
un tablero que organice las tareas por hacer, las que están en proceso y las que
resta por iniciar?

Kanban.

Daily Scrums.

Sprint Review.

Sprint Planning Meeting.

 SUBMIT

Video 1: Resumen de metodología SCRUM

 #3. SCRUM en Ȳ 6 minutos ȱ | Metodologías Ágiles

Fuente: Cristian Henao (2018). #3. Scrum en 6 minutos – Metodologías Ágiles [Archivo de video]. Recuperado

de https://www.youtube.com/watch?v=HhC75IonpOU
2.2.4 Aplicabilidad para cierto tipo de
proyectos

A modo de repaso, podemos mencionar las siguientes características del enfoque ágil de trabajo.

No es un solo ciclo, sino que son n ciclos (sprints).

Cada ciclo entrega un incremento del producto.

El cliente está involucrado en todo el proceso y al final de cada ciclo puede ver los avances
de esa iteración y dar feedback.

Aplica para proyectos complejos, en los que no hay una claridad total de los requisitos al
inicio del proyecto, sino que se van refinando a medida que este transcurre.

Los interesados en el proyecto están dispuestos a participar activamente durante el

transcurso del proyecto.

Son proyectos donde es bueno, sirve, ayuda ir obteniendo versiones iniciales del producto
final y así asegurar un final como el que todos esperan.
Lección 4 de 9

Anexo: manifiesto ágil

Como se indica en agilemanifesto.org (2011), los siguientes principios representan y resumen el espíritu
de lo que se pretende lograr con el uso de las buenas prácticas de SCRUM:

1 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de

software con valor.

2 Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3 Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.

4 Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

5 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y
el apoyo que necesitan, y confiarles la ejecución del trabajo.

6 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre

sus miembros es la conversación cara a cara.

7 El software funcionando es la medida principal de progreso.

8 Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y

usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9 La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11 Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a
continuación, ajustar y perfeccionar su comportamiento en consecuencia.
(agilemanifiesto.org, 2001, https://bit.ly/2WbuBhh).
Lección 5 de 9

GLOSARIO

1 Metodología tradicional o en cascada: metodología de gestión de proyectos que se aplica

en aquellos proyectos simples en los cuales los requerimientos están bien detallados al
inicio del proyecto y para los que contamos con el conocimiento de las herramientas
necesarias para llevar a cabo el proyecto.

2 Metodologías ágiles: metodología de gestión de proyectos que se aplica en proyectos

complejos, en los que el nivel de conocimiento de los requerimientos no es total ni detallado
al inicio de aquellos y para los que no contamos con el nivel de conocimiento necesario
sobre las herramientas para desarrollar con normalidad el proyecto.

3 SCRUM: una de las metodologías ágiles que comparte un conjunto de buenas prácticas,
roles y herramientas con las que se busca ayudar a gestionar de la mejor manera proyectos
complejos. Se basa en los ciclos de vida iterativos y adaptativos en la ejecución de un
proyecto.

4 Product Owner: representante del cliente en el proceso; tiene la responsabilidad de aclarar

la necesidad de este.

5 Scrum Master: líder del equipo de trabajo, es un facilitador de la gestión de este. Asegura el
foco de gestión del equipo y las prácticas de la metodología SCRUM.

6 Team: equipo de trabajo conformado por personas altamente capacitadas que ejecutarán las
distintas tareas del proyecto.

7 Product Backlog: documento que detalla las necesidades del producto a producir o ejecutar.

8 Sprint Planning Meeting: reunión en la que el Product Owner les presenta el Product
Backlog al Scrum Master y al Team para que puedan elaborar una definición de los
 alcances del próximo ciclo de trabajo (Sprint).

9 Sprint Backlog: documento que detalla lo que se abordará en el Sprint.

10 Sprint: se trata de un ciclo de gestión a lo largo de la ejecución del proyecto y es la parte

fundamental de la metodología SCRUM. Cada uno de estos ciclos de gestión deben durar,
dependiendo de la complejidad de lo que deben desarrollar, entre una y cuatro semanas.

11 Daily Scrum: Se trata de una reunión diaria en la que cada miembro del equipo Team cuenta
qué hizo el día anterior, qué hará el día de hoy, qué hará mañana y qué problemas ha
encontrado.

12 Sprint Review: es una reunión en donde participan todos los roles y revisan el cumplimento
de los objetivos del Sprint para poder entregar el producto.

13 Sprint Retrospective: una reunión en la que se reúne todo el equipo para analizar qué se
hizo bien y qué podría haberse hecho mejor, con el fin de mejorar en la próxima iteración.
Lección 6 de 9

Video de habilidades

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

Steve habla estrictamente de la metodología SCRUM.

Verdadero.

Falso.
 SUBMIT

En este caso, la metodología de trabajo de Apple se asemeja con la SCRUM

debido al sentido colaborativo de trabajo.

Verdadero.

Falso.

SUBMIT

En este caso, la metodología de trabajo de esta exitosa empresa se asemeja

con la SCRUM debido a los siguientes 2 aspectos:

La coordinación de reuniones de seguimiento.

La intervención de su secretaria como Scrum Master.

 La concreción de Daily Scrums.

La intervención de Steve como Product Owner.

SUBMIT

¿Cuál es el rol de Steve Jobs en Apple?

Team.

Scrum Master.

Product Owner.

Product Backlog.

SUBMIT
El rol de Steve en su empresa se asimila al Scrum Master.

Verdadero.

Falso.

SUBMIT
Lección 7 de 9

Cierre

Complejidad de los proyectos

–
La complejidad de todo proyecto que debamos gestionar se encuentra condicionada por diversos
factores que determinan que un proyecto sea más o menos complejo

¿Cómo gestionamos la complejidad de los proyectos?

Básicamente, podemos agrupar en dos las maneras de manejar la complejidad de un proyecto: con
metodología en cascada o con metodologías ágiles.

Metodologías tradicionales o en cascada

–
Queda claro que los proyectos sencillos pueden llevarse a cabo con una metodología de gestión de
proyectos simple en la que se sigue una sucesión de pasos y secuencias ordenadas para llegar a
cumplir con el objetivo del proyecto.
¿Qué complejidades puede tener esta modalidad de gestión de proyectos?
El cliente del proyecto no tiene posibilidad de ver un adelanto de lo que será, sino que se encontrará con
el producto terminado tal cual como lo describió varios meses atrás.

El mercado pide otra cosa

–
El mundo y el mercado evolucionan tan rápidamente que así también lo hacen las necesidades de la
gente. Esto hace que sea extremadamente difícil poder determinar el 100% del detalle de lo que se
necesita antes de comenzar un proyecto.

¿Qué es SCRUM?
–
SCRUM es una metodología de gestión de proyectos que brinda:

buenas prácticas, herramientas y roles de gestión;

SCRUM es una de las metodologías ágiles que comparte un conjunto de buenas
prácticas, roles y herramientas que buscan ayudar a gestionar de la mejor manera
proyectos complejos. Se basa en los ciclos de vida iterativos y adaptativos en la
ejecución de un proyecto.

¿Quiénes participan de un Scrum?

–
Product Owner: es el representante del cliente en el proceso y tiene la
responsabilidad de aclarar la necesidad que este tiene.
Scrum Master: es el líder del equipo de trabajo; es un facilitador de la gestión de
trabajo. Asegura el foco de gestión del equipo y las prácticas de la metodología
SCRUM.
Team: es el equipo de trabajo conformado por personas altamente capacitadas que
ejecutarán las distintas tareas del proyecto.
Lección 8 de 9

Referencias

agilemanifesto.org. (2001). Manifiesto por el Desarrollo Ágil de Software. Recuperado de

https://agilemanifesto.org/iso/es/manifesto.html

Figura 4. [Imagen sin título sobre el método ágil SCRUM]. (s. f.). Recuperada de
https://programaenlinea.net/wp-content/uploads/2016/06/scrum-diagrama.png

Figura 8 [Imagen sin título sobre Kanban]. (s. f.). Recuperada de

https://wiki.kefir.red/farm/wiki.kefir.red/a/ad/Kanban.png
Lección 9 de 9

Descargá la lectura

Módulo 2. Enfoques y metodologías en la gestión de

proyectos.pdf
7.7 MB

Gestión de proyectos - Módulo 2.mp3

8.1 MB