1. No category

Universidad Nacional del Centro de la
Provincia de Buenos Aires
Facultad de Ciencias exactas
TRABAJO FINAL DE LA CARRERA DE INGENIERÌA DE SISTEMAS
Un enfoque basado en Planning para la
Gestión de Proyectos en Scrum
Alejo Scornaienqui
José Ignacio Durand
Director: Dr. Luis Berdún
Co Director: Dr. Álvaro Soria
Tandil, Año 2016
Dedicatoria
A nuestros padres, novias, familiares y amigos.
Agradecimientos
A los Dres. Álvaro Soria y Luis Berdún, por sus correcciones, sugerencias y dedicación.
A aquellos que colaboraron con ideas.
¡Muchas gracias!
1
Índice general
Introducción .............................................................................................................................. 4
1.1.
Motivación ................................................................................................................. 4
1.2.
Propuesta .................................................................................................................. 5
1.3.
Organización del trabajo............................................................................................ 7
Marco teórico ............................................................................................................................ 9
2.1. Conocimiento en la organización .................................................................................. 9
2.1.1. Gestión del conocimiento (Knowledge Management) .......................................... 10
2.1.2. Amnesia Organizacional ....................................................................................... 12
2.1.3. Memoria Organizacional ....................................................................................... 13
2.2. Administración de proyectos ....................................................................................... 16
2.2.1. ¿Qué es un proyecto? .......................................................................................... 16
2.2.2. Organización basada en proyectos ...................................................................... 17
2.2.3. Gestión de proyectos ............................................................................................ 19
2.2.4. Planeamiento de proyectos .................................................................................. 20
2.3. Métodos Ágiles ............................................................................................................ 22
2.3.1. Manifiesto de Desarrollo Ágil de Software ............................................................ 22
2.3.2. Scrum .................................................................................................................... 25
2.4. Beneficios del uso de las metodologías ágiles............................................................ 27
Propuesta ............................................................................................................................... 29
3.1 Una herramienta para la administración inteligente de proyectos. .............................. 29
2
3.2. Ejemplo conductor ....................................................................................................... 33
3.2.1. Perfiles de usuario ................................................................................................ 33
3.2.2. Etapa 1 - Definición del proyecto .......................................................................... 34
3.2.3. Etapa 2 - Planificación de un sprint ...................................................................... 39
3.2.4. Etapa 3 - Sprint Retrospective .............................................................................. 41
3.2.5. Conclusión ............................................................................................................ 43
Diseño e implementación ....................................................................................................... 44
4.2.1. Definición del Proyecto ......................................................................................... 51
4.2.2. Planificación del Sprint .......................................................................................... 53
4.2.3. Sprint Retrospective .............................................................................................. 55
Resultados Experimentales ................................................................................................... 61
5.1. Criterio de calificación del algoritmo y generación del conocimiento. ......................... 62
5.2. Casos de estudio ......................................................................................................... 64
5.2.1. Caso de estudio 1: Metodología “cascada” vs. Metodología ágil “scrum” ............ 64
5.2.2. Caso de estudio 2: Capacidad de aprendizaje ..................................................... 71
5.2.3. Caso de estudio 3: Capacidad de recuperación ................................................... 76
Conclusiones .......................................................................................................................... 81
6.1. Contribuciones ............................................................................................................. 81
6.2. Limitaciones y trabajos futuros .................................................................................... 83
ANEXO I ................................................................................................................................. 84
Bibliografía ............................................................................................................................. 87
3
Capítulo 1
Introducción
1.1.
Motivación
Las Metodologías Ágiles se han instalado exitosamente en los últimos años en el ámbito
de desarrollo de proyectos de software. Esta perspectiva está mostrando su efectividad en
proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos
de desarrollo, sin perder de vista una alta calidad [Nasir2006].
El uso de estas metodologías beneficia la cooperación y el aprendizaje mutuo. Consideran
la comunicación interpersonal como un pilar, lo que se refleja como "Individuos e interacciones
sobre procesos y herramientas" en el manifiesto ágil. Las empresas que utilizan el diseño ágil
en sus prácticas de trabajo, realizan reuniones de grupo para tener un constante intercambio
de información entre los desarrolladores. Estas prácticas ayudan a la transferencia de
conocimiento.
Debido a que estos métodos ágiles se ejecutan para un único proyecto, muchas veces se
desaprovecha todo el conocimiento aprendido en los proyectos anteriores. En este sentido, uno
de los puntos clave es el conocimiento y la experiencia que el administrador del proyecto va
adquiriendo a medida que se suceden los proyectos, lo cual pasa a ser de mucha utilidad al
momento de realizar uno nuevo. Normalmente, esta experiencia es sólo adquirida por el
administrador y cuando éste deja la organización se la lleva consigo. Esta fuga de
conocimiento se conoce como Amnesia Organizacional (AO).
Debido a lo mencionado anteriormente, surge la inquietud de cómo lograr la persistencia de
dicho conocimiento. En este sentido, la gestión del conocimiento es el proceso que
continuamente asegura el desarrollo y la aplicación de todo tipo de conocimientos y recursos
pertinentes de una empresa, con objeto de mejorar su capacidad de resolución de problemas y,
4
de esta manera, contribuir a la sostenibilidad de sus ventajas competitivas [Andreu & Sieber
1999].
En el contexto de desarrollo de proyectos de software, los ejecutivos de hoy en día
consideran que la solución a la mayoría de estos problemas involucra la obtención de una
mejor gestión de los recursos existentes en la organización. Como parte del intento de lograr
una solución interna, los ejecutivos están atentos a la forma en que las actividades
empresariales se gestionan. En este sentido, la gestión de proyectos es una de las técnicas
involucradas [Kerzner, 2009].
A partir de esto surge la idea de incorporar a las herramientas soporte inteligente para asistir
en el planeamiento y ejecución de proyectos. La idea detrás de estas aproximaciones es
preservar conocimiento sobre las tareas, registrar las razones de decisiones tomadas y
recolectar información relevante a los problemas nuevos.
1.2.
Propuesta
Actualmente, las herramientas de planificación de proyectos tienen éxito en mostrar
información básica del plan, pero no ofrecen soporte en cuanto a la captura de conocimiento y
la asistencia en dicha planificación.
En este contexto, se presenta el desarrollo de una herramienta con la funcionalidad
necesaria para la gestión de los proyectos y optimización de los recursos para lograr un
desempeño eficiente a lo largo del ciclo de vida del mismo. La Figura 1 muestra un esquema
conceptual de la solución propuesta.
5
Figura 1: Esquema conceptual del enfoque
El administrador del proyecto interactúa con la herramienta de gestión de proyectos durante
la etapa de planeamiento. Esta interacción se llevará a cabo utilizando la herramienta Virtual
Scrum [Virtual Scrum 2013], la cual provee un entorno virtual que ofrece a los integrantes de
un equipo de trabajo la posibilidad de llevar a cabo una reunión, aun encontrándose en
distintas estaciones de trabajo, de modo que compartan ideas y opiniones como si estuvieran
ubicados en el mismo lugar físico. La metodología de software soportada por la herramienta de
gestión es Scrum.
La aplicación posibilita al administrador del proyecto de realizar el planeamiento de
diferentes sprints de manera iterativa, seleccionando, en cada iteración, el Sprint Backlog
correspondiente. En primera instancia, la aplicación accede a la información contenida en la
memoria organizacional, para luego proveer la misma al módulo optimizador, el cual retorna un
posible plan de sprint. Para realizar esto, se sigue el enfoque provisto por el Algoritmo de
Planning KMUCPop [Berdun 2009],
el cual provee un agente inteligente que procesa
información histórica sobre recursos, tareas y asignaciones y realiza, en base a ella, cálculos
para decidir las mejores asignaciones posibles entre recursos y tareas.
6
Como paso siguiente, se retoma la interacción entre el administrador del proyecto y la
aplicación. Esta última muestra el plan de sprint generado por el módulo optimizador. El
administrador, puede optar por aceptarlo o no, teniendo la posibilidad de cambiar las
restricciones previamente elegidas. En caso de que el plan de sprint sea aceptado, toda la
información pertinente se almacena en la memoria organizacional, la cual es retroalimentada a
medida que el algoritmo es ejecutado.
Como conclusión, observando la figura se pueden identificar dos componentes principales,
la herramienta de gestión de proyectos y el módulo optimizador. La solución propuesta integra
estos dos componentes. Como resultado de esta integración, el ambiente Virtual Scrum se vea
enriquecido por las funcionalidades provistas por el Algoritmo de Planning. Permite al
administrador del proyecto realizar planificaciones eficientes y aprovechar al máximo las
habilidades de cada recurso, ya que el plan de trabajo resultante reflejará las decisiones
tomadas por el administrador en proyectos anteriores.
1.3.
Organización del trabajo
En esta sección se detalla la estructura general del presente trabajo, brindando una breve
descripción de los temas que se abordan en cada capítulo.

El capítulo 2, titulado Marco Teórico, presenta los fundamentos teóricos utilizados
en esta tesis. Se presentan las principales definiciones y enfoques en el área de la
Gestión del Conocimiento y cómo se relacionan con este trabajo. También se
distingue a uno de los problemas del área, la Amnesia Organizacional, y cómo este
problema afecta a las Organizaciones Basadas en Proyectos. Además, se
presentan el marco teórico sobre la Memoria Organizacional y los diferentes
modelos de Memoria Organizacional presentados en la literatura y cómo estos
modelos contribuyen en el Aprendizaje Organizacional. A su vez se introduce a la
Administración de Proyectos, donde se detallan aspectos como la Gestión y el
Planeamiento de Proyectos. Por otro lado se presentan las Metodologías Agiles y
se hace fuerte hincapié en la utilización de la Metodología Scrum, y se detallan las
7
ventajas de utilizar este tipo de metodologías por sobre el uso de las metodologías
tradicionales.

El capítulo 3 introduce la propuesta de este trabajo. En este se expone la solución
planteada mediante la combinación de una Memoria Organizacional y un algoritmo
que automatiza la planificación de un proyecto, utilizando una herramienta de
administración de proyectos, Virtual Scrum, que sigue la metodología ágil Scrum y
que fue desarrollada por los alumnos de la Facultad de Ciencias Exactas.

El capítulo 4 expone las adaptaciones que se realizaron a los enfoques previamente
mencionados y cómo se realizó la integración de los mismos sobre una herramienta
de administración de proyectos real mostrando los aspectos referidos a la
implementación. A su vez se presenta una demostración de la utilización de la
herramienta ejemplificando cada uno de los aspectos de implementación descriptos
en el capítulo.

El capítulo 5 presenta las evaluaciones experimentales que se le realizaron a la
herramienta, dejando claro a través de análisis y comparaciones los beneficios de
su utilización.

El capítulo 6 presenta las conclusiones obtenidas a partir de la incorporación de la
nueva funcionalidad de planificación de proyectos a la herramienta Virtual Scrum y
las ventajas que esto implica. También se presentan cuáles serán los trabajos
futuros que podrían desarrollarse a partir de este.
8
Capítulo 2
Marco teórico
En el siguiente capítulo se introducen los principales conceptos abordados por el trabajo.
Teniendo esto en cuenta, el capítulo describe estado del arte de la Gestión del Conocimiento y
su importancia para las organizaciones, como así también las problemáticas surgidas a partir
de las fallas en los mecanismos de su captura.
A su vez nos referiremos a la administración de proyectos, centrándonos fundamentalmente
en las Organizaciones Basada en Proyectos, para las cuales está diseñada la herramienta
propuesta.
Este capítulo está organizado de la siguiente manera: la sección 2.1 introduce los conceptos
fundamentales en lo referido al conocimiento, donde se destacaran aspectos sobre su gestión,
los problemas que se afrontan con la pérdida de conocimiento y como el modelo de Memoria
Organizacional contribuye en el aprendizaje organizacional; la sección 2.2 presenta los
conceptos de gestión, administración y planificación de proyectos; la sección 2.3 describe las
características de las Metodologías Agiles en general, para luego enfocarse en Scrum. Por
último en la sección 2.4 se presentan las ventajas de utilizar las metodologías ágiles por sobre
los modelos tradicionales.
2.1. Conocimiento en la organización
En general el conocimiento siempre ha sido importante para las personas y en especial para
las organizaciones en donde la especialización se está volviendo más importante cada día. El
conocimiento organizacional no es fácil de administrar (Stein y Zwass, 1995). El mismo tiene
muchas propiedades, y debido a que la mayoría de éstas están embebidas en la cabeza de la
gente, lo hacen diferente de cualquier activo de la organización. En un plano organizacional, el
9
conocimiento se encuentra tanto dentro de documentos o almacenes de datos, como así
también en rutinas organizativas, procesos, prácticas, y normas.
Específicamente, (Drucker, 1993) propone que el conocimiento debe ser considerado como
medio necesario para la producción en las organizaciones. Además, (Bock, Zmud, Kim y Lee,
2005) proponen que el conocimiento constituye el fundamento de la ventaja competitiva de las
empresas y es el componente clave de valor de las mismas.
A medidas que las organizaciones van abandonando el modelo de organizaciones basadas
en recursos para transformarse en organizaciones basadas en conocimiento (Spender a, 1996)
(Spender y Grant, 1996) (Tsoukas, 1996), el conocimiento como recurso “intangible” pasa a
tomar mayor importancia dentro de la organización. Esta premisa que el “conocimiento es
poder” (Drucker, 1993), proviene del simple hecho de que la acción se considera una
consecuencia del conocimiento.
Por lo tanto es el conocimiento lo que posibilita la acción de los individuos dentro de la
organización. Siguiendo esta línea de razonamiento, se considera que todas las acciones que
realiza un usuario o empleado en la organización poseen razones subyacentes, las cuales
están usualmente basadas en un proceso de razonamiento basado en el conocimiento (Moore,
1985).
Por otro lado, (Alavi y Leidner, 2001) destacan que los conceptos de captura y
comunicación del conocimiento organizacional no son conceptos nuevos por sí mismos, y han
sido llevados a cabo a través de la capacitación del personal, programas de desarrollo del
personal y acceso a la documentación de la organización, como manuales y reportes.
2.1.1. Gestión del conocimiento (Knowledge Management)
Actualmente, el conocimiento es generalmente percibido como un recurso estratégico clave
que poseen las organizaciones, y la gestión del conocimiento se considera crítica para el éxito
organizacional (Ipe, 2003).
10
La premisa básica que toma la Gestión del Conocimiento es que las organizaciones (y sobre
todo las organizaciones que basan su ventaja competitiva en el conocimiento de sus
integrantes) que administren mejor su conocimiento, serán capaces de hacer frente, de manera
más exitosa, a los cambios de los nuevos entornos de negocios.
Para (Awad y Ghaziri, 2004) la Gestión del Conocimiento es un modelo de negocios nuevo y
emergente que tiene al conocimiento como foco de marco de trabajo organizacional.
Claramente esta definición ve a la GC como una “nueva” forma de hacer negocios, en donde el
nuevo factor de competencia es el conocimiento organizacional. Otra definición toma a la
Gestión del Conocimiento como “la captura, organización y almacenamiento del conocimiento y
experiencias de trabajadores individuales dentro de la organización, y el proceso de hacer
disponible esta información para otros en la organización” (Rosenberg, 2002).
Otra definición parecida en cuanto al fin de GC es la de (Alavi y Leidner, 2001) en la que “La
Gestión del Conocimiento es un proceso especificado sistemática y organizacionalmente para
adquirir, organizar y comunicar el conocimiento de los empleados, para que otros empleados
puedan hacer uso de él para ser más eficientes y productivos en sus trabajos”.
Bellinger (Bellinger, 2002) se refiere a la GC como “la captura, retención, reutilización de las
bases para impartir entendimiento a cómo las piezas encajan y cómo se transportan
significativamente a alguna otra persona”. Esta interpretación de la Gestión del Conocimiento
da mucha importancia al aspecto tácito del conocimiento y de su transferencia y posterior
interpretación.
En resumen, la gestión del conocimiento se ha convertido en esencial para la ventaja
competitiva organizacional. En consecuencia, la capacidad de las organizaciones para
almacenar,
transferir
y
expandir
el
conocimiento
en
las
organizaciones
afectará
significativamente la creación de conocimiento y la ventaja competitiva de la organización. Sin
embargo, el rendimiento y el crecimiento del conocimiento requieren de la integración y el
intercambio del mismo. Esto depende de mecanismos de gestión del conocimiento que mejora
la calidad de las decisiones.
11
Numerosas organizaciones han dedicado cada vez más atención a la forma en que la
gestión del conocimiento puede permitir incrementar su rentabilidad y velocidad de crecimiento
de los beneficios. Esto lleva al estudio de en un área particular de la gestión del conocimiento,
la memoria organizacional.
2.1.2. Amnesia Organizacional
La capacidad de las organizaciones para aprender y explotar el conocimiento en virtud de
obtener una ventaja competitiva es un factor crítico de éxito en la economía del conocimiento
(K-economía) (Lietaer, 2002). Sin embargo, a pesar de la importancia que se le da al
conocimiento, las organizaciones son muy vulnerables a los malos resultados debido a la
amnesia organizacional (Conklin, 2001). Esta es uno de los problemas que intenta solucionar la
Gestión del Conocimiento, para lo cual la Memoria Organizacional juega un papel muy
importante.
La Amnesia Organizacional (AO) se produce cuando alguna persona, que posee algún
conocimiento específico y único dentro de la organización, abandona la misma (Kransdorff,
1998) (Kransdorff, A, 2006). Esa persona se lleva consigo el conocimiento tácito que posee, y
que posiblemente lo adquirió durante su transcurso por la organización, y no deja ningún
documento o artefacto que sirva de reemplazo a su experiencia, dejando así a la organización
con un faltante de conocimiento en el área de experiencia de esta persona. Este problema no
sólo se presenta ante la pérdida de una persona, también se produce cuando los procesos de
captura y retención de conocimientos de la organización fallan (Kransdorff, 1998), lo cual
presenta otro desafío a la gestión del conocimiento organizacional, desarrollar mejores
métodos y técnicas de captura, codificación y retención de conocimiento.
La Amnesia Organizacional también está ligada al concepto de aprendizaje organizacional,
ya que las organizaciones pueden adaptarse a los cambios del entorno en el cual se
encuentren inmersas al mismo ritmo que puedan aprender. Por lo cual algunos autores (Azuan,
2002) identifican a la Amnesia Organizacional como una de las barreras que se presentan al
Aprendizaje Organizacional. En este sentido la Amnesia Organizacional es una frase utilizada
12
para describir una situación en la cual el negocio, y otros tipos de organizaciones cooperativas,
pierden la memoria de cómo realizar las cosas (Azuan, 2002).
La literatura de gestión del conocimiento sostiene que el aprendizaje individual no es
suficiente para generar conocimiento útil para la empresa. Las lecciones aprendidas en última
instancia, deben ser difundidas dentro de la organización con el fin de facilitar la adaptación de
la misma (Pedler, 1989), (Redding, 1997), (Hong, 1999), (Farr, 2000).
2.1.3. Memoria Organizacional
El conocimiento explícito posee características deseables para su administración y es por
esta razón que se busca codificar el conocimiento tácito en repositorios, como una Memoria
Organizacional (MO), para la posterior adaptación y reutilización (Goodman y Darr, 1998).
Dentro de las ventajas que se le reconocen a la MO en la literatura se puede citar por
ejemplo que la MO puede ser utilizada como fuente de ventaja competitiva (Wexler, 2001),
(Wexler, M, 2002); (Croasdell, 2001) puede reducir costos en las transacciones de la
organización (Croasdell, 2001), permite a las organizaciones beneficiarse de su historial de
información y del aprendizaje independientemente de los naturaleza transitoria de sus
miembros (Bretón, 2001).
La Memoria Organizacional (Hedberg, 1981) o Memoria Corporativa (Euzenat, 1966) ,
dependiendo del contexto, son modelos que típicamente se concentran en el tipo de
información o conocimiento a ser administrado, y en los procesos para la captura, retención,
posterior acceso y uso de tales conocimientos. En este sentido la MO, haciendo un paralelismo
con la memoria de las personas, se centra en determinar cuáles son los tipos de información
que son relevantes a la organización. También involucra a los procesos de captura de estas
informaciones o conocimiento, los medios necesarios para su efectiva retención, y los
mecanismos que aseguren su recuperación para poder hacer uso en situaciones futuras. Por lo
tanto, la memoria organizacional no es sólo un mecanismo para acumular y preservar
conocimiento, sino que también para su intercambio. A medida que el conocimiento se hace
explícito y es administrado, aumenta la inteligencia organizacional, llegando a ser una base
13
para la comunicación y el aprendizaje. Este puede ser compartido entre los individuos que
trabajan solos, equipos que necesitan una memoria del proyecto, y por la organización en su
conjunto para la coordinación y la comunicación entre los equipos.
Además, la Memoria Organizacional establece las estructuras cognitivas del procesamiento
de la información y la teoría de acción de toda la organización (Hedberg, 1981) . En esta
definición se presenta a la MO no sólo como un repositorio de experiencias organizacionales
sino también determina las formas en las que se debe organizar la información, para poder
entenderla y recordarla de forma efectiva. También ayuda en el proceso de toma de decisiones
al proveer un marco de trabajo en el cual se determinarán los cursos de acción (Jackson y
Klobas, 2008).
En su utilización de los procesos de Gestión del Conocimiento, la Memoria Organizacional
ha tenido significativos aportes en esta área. La Memoria Organizacional ha sido propuesta
como un medio para dar soporte a la retención de conocimiento y la promoción del proceso de
gestión de conocimiento efectivo (Bannon, y Kuutti, 1996). Según (Stein y Zwass, 1995), la
Memoria Organizacional es un medio efectivo por el cual el conocimiento obtenido en el pasado
puede ser aplicado en las actividades actuales. En este sentido, la Memoria Organizacional
tiene como finalidad reutilizar las experiencias que ocurrieron en la organización (Ackerman y
Hadverson, 2000).
Desde estas perspectivas la MO es considerada tanto un repositorio de experiencias
organizacionales en el cual se almacena el conocimiento de los individuos de la organización, y
que tiene como finalidad la utilización de este conocimiento en situaciones futuras, como un
medio para gestionar el conocimiento organizacional, estableciendo los medios y condiciones
necesarias para adquirir, retener, recuperar y proteger el conocimiento de la organización.
Por otro lado, otros autores sostienen que la Memoria Organizacional es tanto una
construcción individual como organizacional (Walsh y Ungson, 1991). En este enfoque de
Memoria Organizacional, los principales aspectos son la Adquisición, Retención
y
Recuperación de los artefactos que formarán parte de la Memoria Organizacional. (Walsh y
Ungson, 1991) hacen una importante distinción entre los contenidos de la Memoria
14
Organizacional, es decir lo que es recordado, y como es recordado. La parte de la Memoria
Organizacional que determina cómo los contenidos son recordados puede incluir a los
individuos, la cultura organizacional, los mecanismos de transformación organizacionales, la
estructura organizacional, los factores ecológicos organizacionales y demás fuentes externas
(Walsh y Ungson, 1991). Además estos autores proponen que la organización puede existir
independientemente de individuos particulares ya que es la interpretación compartida de la
información la que asegura la preservación del conocimiento organizacional, dando lugar a la
aparición del sistema de interpretación organizacional; el cual en cierta forma transciende el
nivel individual.
Otro enfoque de Memoria Organizacional es el presentado por (Guerrero y Pino, 2001), en
el cual se la considera como la agregación de memoria de todos los empleados de la
organización. En este enfoque es necesario prestarle especial importancia a la transferencia de
conocimiento tácito entre los miembros de la organización, ya que todo el potencial de activos
intangibles reside en las personas y la única memoria existente es la memoria “colectiva” de la
organización. Si bien esta visión de la Memoria Organizacional toma a las personas como
fuentes de ventaja competitiva, deja a la organización en una posición en la cual se le dificulta
la protección y reutilización es estos activos estratégicos (Teece, 2000).
El concepto de MO ha evolucionado con el tiempo. Los primeros modelos consideraban a la
MO como un conjunto de documentos y piezas de información provenientes desde el historial
de la organización los cuales residían en un espacio de almacenamiento común y que podían
ser utilizados en decisiones presentes (Stein y Zwass, 1995); (Lehner, 1998). Un segundo
modelo extiende el modelo previo incorporando procesos de generación de información como
parte de la MO, ya que estos proveen el contexto dentro del cual la información es generada
(Lehner y Maier, 2000); (Guerrero y Pino, 2001). Por lo tanto, las experiencias, las
conversaciones, las decisiones, etc. son el soporte de los artefactos de información que forman
parte de la MO. Cualquiera sea el concepto de Memoria Organizacional que se adopte, es
importante contar con un Sistemas de Memoria Organizacional que nos provea los servicios
necesarios para su utilización. Estos sistemas proveen servicios que posibilitan a la
organización localizar expertos dentro de la misma (Maybury, 2001); (Yimam-Seid y Kobs,
15
2003); registrar, recuperar y promover problemas con sus soluciones (también llamadas
“lecciones aprendidas”) (Weber, 2001); (Ackerman y Hadverson, 2000); buscar y extraer
conocimiento desde diferentes fuentes de conocimiento explícito dentro de la organización
(Anand, 1998).
En resumen, la MO describe el conocimiento almacenado que se puede utilizar para la toma
de decisiones presentes (Walsh y Ungson, 1991) y es una herramienta de gestión del
conocimiento que debe apoyar el aprendizaje organizacional (van Heijst, G., van der Spek, R. &
Kruizinga, 1997). Es un poderoso mecanismo para la gestión y creación de conocimiento en la
era de la tecnología de la información (Cross, R., & L. Baird, 2000) (van Heijst, G., van der
Spek, R. & Kruizinga, 1997), (Walsh y Ungson, 1991). Cuando se utiliza con eficacia, la
memoria organizacional ayuda a las empresas a evitar los errores pasados, asegurar el uso
continuo de las mejores prácticas, y aprovechar la sabiduría colectiva de los empleados
pasados y presentes.
2.2. Administración de proyectos
La administración de proyectos es el proceso de combinar sistemas, técnicas y personas
para completar un proyecto dentro de las metas establecidas de tiempo, presupuesto y
calidad.” (Baker, 1999). La administración del proyecto es un tópico fundamental en el
desarrollo del mismo.
2.2.1. ¿Qué es un proyecto?
Según el Project Management Institute un proyecto es un esfuerzo temporal emprendido
para crear un producto, servicio o resultado. La naturaleza temporal de los proyectos indica un
principio y un fin. El fin se alcanza cuando los objetivos del proyecto se han completado o
cuando el proyecto es cancelado, ya que sus objetivos no pueden ser cumplidos, o cuando la
necesidad del mismo ya no existe.
En (Wysocki, 2003) se realiza una definición de proyecto más detallada y puntual: se lo
define como una secuencia de actividades únicas, complejas y conectadas que tienen un
16
objetivo o propósito, y deben ser completadas en un tiempo específico, dentro de un
presupuesto y de acuerdo a una especificación. Como podemos apreciar en ambas
definiciones se habla de objetivos a realizar, tareas involucradas y un intervalo de tiempo.
En este contexto se puede afirmar que un trabajo repetitivo no es un proyecto, sino que es
realizar una tarea simple una y otra vez, de aquí la distinción que las actividades deben ser
“únicas”. Como se mencionó, un trabajo repetitivo no es un proyecto, aunque el límite entre
ambos puede llegar a ser confuso.
Cualquiera sea la definición que se utilice, es posible listar un conjunto de elementos que
resumen las características claves que distinguen a un proyecto (Hughes y Cotterell, 1999),
(Wysocki, 2003):
•
Se involucran tareas no rutinarias.
•
Se requiere planeamiento.
•
Se deben cumplir objetivos específicos.
•
El trabajo es llevado a cabo en varias fases; existe un orden.
•
El trabajo involucra varias especialidades.
•
Los recursos disponibles para ser usados en el proyecto se encuentran restringidos.
2.2.2. Organización basada en proyectos
La estructura de las Organizaciones Basadas en Proyectos (OBP) se ha aplicado en un
gran rango de industrias, como la construcción (Gann y Salter, 1998), las Tecnologías de la
Información (TI) (Boh, 2007), las comunicaciones (Kodama, M, 1999), las automotrices (Clark y
Fujimoto, 1991), los medios de comunicación (Windeler y Sydow, 2001), (DeFillippi y Arthur,
1998), las consultorías y los servicios profesionales (Alvesson, 1995). Esta concepción de
organización se ha propuesto como una forma ideal para la gestión de la creciente complejidad
de los productos, los mercados en rápida evolución, la innovación, y la incertidumbre
tecnológica.
OBP se refiere a una variedad de formas de organización que implican la creación de
sistemas temporales para el desempeño de las tareas del proyecto (DeFillippi y Arthur, 1998)
17
identifican las empresas basadas en proyectos como organizaciones de producción de único
propósito, que contienen todas las funciones de apoyo a la producción dentro de un marco
temporal de la organización del proyecto.
Las definiciones de las Organizaciones Basadas en Proyectos varían, pero todas coinciden
en que los proyectos poseen recursos internos y externos, al igual que funciones individuales
como desarrollo, producción y ventas, y las organizaciones ya establecidas están estructuradas
para ejecutar su negocio como proyectos individuales (Hobday, 2000).
La misión de las organizaciones basadas en proyectos es generar resultados en respuesta
a las demandas específicas de los clientes, estructurando proyectos alrededor de un grupo de
especialistas, miembros de la organización, y ejecutando proyectos dentro de un tiempo y
presupuesto limitado. La empresa u organización entera puede ser pensada como un
conglomerado de organizaciones basadas en proyectos en la cual las rutinas son realizadas
por las diferentes organizaciones (Kodama, 2006).
Administrar o gestionar el conocimiento para mejorar la ventaja competitiva de las
organizaciones, y en especial las Organizaciones Basadas en Proyectos, ha recibido una
excepcional atención en años recientes (Nonaka y Takeuchi, 1995), (Davenport y Prusa, 1998)
(Wiig, 1997) (Blacker, 1995) (Lubit, 2001). Las organizaciones que llevan a cabo sus negocios
en base a proyectos están comenzando a incorporar técnicas provenientes del área de la
Gestión del Conocimiento para mejorar la comunicación y reutilización de conocimiento entre
los miembros de la organización (DeFillippi, 2001) (Prencipe y Tell, 2001). Las Organizaciones
Basadas en Proyectos tienen requerimientos laborales diferentes, ya que los requerimientos de
los proyectos varían de un proyecto al siguiente en cuanto al personal, los materiales y la
información, y estas limitaciones dificultan maximizar el flujo de conocimiento capturado y el
aprendizaje de un proyecto al siguiente (DeFillippi y Arthur, 1998) (Turner y Müller, 2003). La
incorporación de técnicas de Gestión del Conocimiento para hacer frente a estas dificultades
han sido identificadas como una fuente de ventaja competitiva en las Organizaciones Basadas
en Proyectos (Bresnen, 2003).
18
2.2.3. Gestión de proyectos
La gestión de proyectos es la planificación, organización, dirección y control de los recursos
de la empresa para un objetivo relativamente a corto plazo que se ha establecido para
completar las metas y objetivos específicos. Esta brinda conocimiento, habilidades,
herramientas y técnicas a los administradores para ayudarlos a planear y ejecutar proyectos en
tiempo y dentro del presupuesto acordado (PMI, 2004).
La administración del proyecto es un tópico fundamental en el desarrollo del mismo. Años
atrás se tenían muchos conceptos erróneos sobre la administración de proyectos, por ejemplo,
que su aplicación implica mayor cantidad de personas, que incrementa los costos, disminuye la
rentabilidad, genera más problemas de los que resuelve, por citar algunos ejemplos. En la
actualidad ya no se cometen estos errores conceptuales y se reconocen todas las virtudes que
aporta durante la ejecución del proyecto (Kerzner, 2001).
Recursos y actividades son los actores clave en cualquier organización para la realización
de un proyecto. El propósito de la gestión de proyectos es primero encontrar las actividades
necesarias para llevar a cabo el proyecto hasta su fin y en segundo lugar el de asignar recursos
a estas actividades de una manera óptima y planificada.
Figura 2.A: Secuencia de procesos seguida por la mayoría de los proyectos.
Como se muestra en la Figura 2.A, la gestión de proyectos involucra 5 grupos de procesos
llamados
•
Inicio
•
Planeamiento y Diseño
19
•
Ejecución
•
Monitoreo y control
•
Finalización
El proceso Inicio determina la naturaleza y el alcance del proyecto. En la etapa de
planeamiento el proyecto de planea con un nivel de detalle más apropiado.
El principal
propósito de esta etapa es estimar el tiempo, costo, y recursos adecuadamente para estimar el
esfuerzo necesario y poder así calcular los riesgos durante la ejecución.
En el proceso de Ejecución es donde se ejecuta el trabajo. Este está estrechamente
relacionada con el proceso de Monitoreo y Control, ya que su objetivo es asegurar que el
proyecto sea realizado de acuerdo a lo planeado.
La etapa de Finalización incluye la aceptación formal del proyecto, como así también la
evaluación del mismo.
2.2.4. Planeamiento de proyectos
El Planeamiento de Proyectos es una de las principales tareas de la Administración de
Proyectos. Los planes de proyectos están compuestos principalmente por dos estructuras
llamadas Work Breakdown Structure (WBS) y Network Diagram (ND).
WBS es un conjunto de elementos organizados jerárquicamente los cuales son necesarios
para realizar la entrega de los bienes o servicios requeridos (Tausworthe, 1980). El WBS define
las actividades en un orden de detalle jerárquico, las entradas, las salidas, los cronogramas y
las asignaciones de responsabilidades necesarias para poder completar un trabajo.
El Network Diagram o Diagrama de Red define las precedencias entre actividades y su
duración. Esta estructura le permite a un administrador calcular la duración y costo de un
proyecto y por este motivo es tan importante. Las técnicas clásicas de Critical Path Method
(CMP) o Método del Camino Crítico y Program Evaluation and Review Technique (PERT) o
Técnica de Evaluación y Revisión del Programa, trabajan sobre esta estructura para determinar
tanto la secuencia de tereas que afecta a la ejecución del proyecto como el análisis de
20
sensibilidad de las tareas y su impacto en la ejecución del proyecto. CMP es una técnica (o
método) determinista utilizada para estimar el tiempo de cada actividad, mientras que PERT
permite la incorporación del azar al tiempo de completar una actividad. Aunque CMP tiene la
ventaja de ser fácil de entender y utilizar, éste no considera las variaciones de tiempo que
pueden tener un gran impacto en el tiempo total de finalización de proyectos complejos, de la
forma que lo hace PERT.
Generalmente la calidad de los resultados de los proyectos depende, en gran medida, de la
calidad del plan de proyectos utilizado (Armstrong, 1982), y esto último es de especial
importancia para las Organizaciones Basadas en Proyectos (OBP) ya que los proyectos son
una parte importante de sus operaciones diarias. El Project Management Body of Knowledge
(PMBoK) promueve fuertemente destacar la importancia del planeamiento de proyectos (PMI,
2004). La actividad de Planeamiento de Proyectos involucra varias actividades basadas en
conocimiento que tienen impacto profundo en los resultados del plan. Para ayudar a las
personas que realizan planes de proyectos, diferentes herramientas han sido creadas que los
asisten o los ayudan a que sus trabajos sean más fáciles o menos propensos a errores. Se ha
reconocido que la utilización de este tipo de herramientas en la administración de proyectos
tiene un impacto significativo en los resultados de un proyecto sin incrementar la cantidad de
recursos necesario para el proyecto (Kerzner, 2001).
Si bien la asistencia y el entrenamiento pueden ayudar a los administradores a crear planes
de proyectos exitosos, la innovación es una habilidad que los ayuda a resolver nuevos y
desafiantes problemas. La innovación es importante en el planeamiento de proyectos porque
soluciones efectivas y eficientes deben ser encontradas para nuevos proyectos. Si una
organización quiere reutilizar las soluciones que aplica en previos planes de proyectos,
necesita incorporar procedimientos y técnicas que le permitan codificar, almacenar, recuperar y
adaptar estas soluciones a situaciones futuras.
(Basadur y Gelade, 2006) han reconocido la importancia de la gestión del conocimiento en
los procesos creativos como el Planeamiento de Proyectos.
21
A la hora de decidir cómo resolver una tarea, los administradores deben tomar decisiones
basándose en su conocimiento previo y en la experiencia que acumularon durante sus años
como administradores. Estas decisiones están presentes en los planes que generan y el
resultado de estos planes parcialmente depende de estas decisiones. Si queremos reutilizar
este conocimiento, como parte de nuestra estrategia de gestión del conocimiento, necesitamos
describir cuales son las razones o procesos de razonamiento detrás de las decisiones que han
aplicado (por ejemplo, cual es el conocimiento tácito que llevó a esas decisiones). Esta
estrategia de codificación tenderá a mejorar los mecanismos de intercambio de conocimiento
en la organización. Los mecanismos de intercambio de conocimiento (Knowledge Sharing
Mechanisms) son los medios por los cuales los individuos de la organización tienen acceso al
conocimiento e información de otros proyectos (Boh, 2007).
2.3. Métodos Ágiles
Los Métodos Ágiles surgen como una propuesta a los desafíos modernos del desarrollo de
software, donde no es posible aplicar los estrictos métodos clásicos basados en el riguroso
seguimiento de los procesos. De esto surge una serie de propuestas “livianas” que se resumen
como los Métodos Ágiles (MA).
2.3.1. Manifiesto de Desarrollo Ágil de Software
El "Movimiento Agile" en la industria del software vio la luz el día en que el Manifiesto de
Desarrollo Ágil de Software fue publicado en 2001 (Beck et. al, 2001); (Cockburn, 2002). Según
el manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto de software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se comete el error
de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor
crear el equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.
22
Desarrollar software que funciona por sobre conseguir una buena documentación. La
regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata
para tomar una decisión importante. Estos documentos deben ser cortos y centrarse en lo
fundamental.
La colaboración con el cliente por sobre la negociación de un contrato. Se propone
que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.
Responder a los cambios por sobre seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos,
en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo
tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los doce primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto a metas a seguir y organización del mismo. Los principios son:
•
La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporten un valor.
•
Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
•
Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible de entregas.
•
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
•
Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
•
El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
23
•
El software que funciona es la medida principal de progreso.
•
Los
procesos
ágiles
promueven
un
desarrollo
sostenible.
Los
promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
•
La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
•
La simplicidad es esencial.
•
Las mejores arquitecturas, requerimientos y diseños surgen de los equipos organizados
por sí mismos.
•
En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo,
y según esto ajusta su comportamiento.
El objetivo de la creación de los métodos agiles fue esbozar los valores y principios que
deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios
que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos
de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la
documentación que se genera en cada una de las actividades desarrolladas.
Las características de los proyectos para los cuales las metodologías ágiles han sido
especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo
de software; aquellos en los cuales los equipos de desarrollo son pequeños, con plazos
reducidos, requerimientos volátiles, y basados en nuevas tecnologías.
En este contexto, los Métodos Ágiles (MA) dan lugar a la creatividad y a la sensibilidad a los
cambios de condiciones. Algunos de estos son más bien una colección de técnicas y
actividades más que un proceso totalmente definido con roles, responsabilidades, productos y
demás ítems. Los MA toman en cuenta que el desarrollo de software es una actividad humana
y por ese motivo, enfatizan al individuo sobre el proceso.
24
El objetivo de los MA es la entrega continua de software funcional y completamente
testeado, mediante pequeñas y periódicas entregas (releases). Para lograrlo, estas
metodologías ponen el acento en la comunicación, con reuniones diarias cara a cara. Proponen
mantener el nivel de desimantación en el mínimo necesario así como también, una cooperación
estrecha y continua entre el cliente y el desarrollador, en lugar de simplemente negociar los
términos y productos del proyecto.
Los MA responden rápidamente a los cambios en el ambiente, teniendo como principio
básico que los requerimientos del cliente sobre el proyecto y su entendimiento del mismo
cambian casi constantemente. Para adaptarse a estos cambios, los MA proponen iteraciones
rápidas y cortas, con planificación continua, en lugar de trabajar con un gran plan al comienzo
del proyecto. Su estrategia se basa en el desarrollo evolutivo y un ciclo de vida dirigido por
riesgos y el testing, enfatizando en la volatilidad de los requerimientos.
De entre todos los métodos de desarrollo ágil, el más reconocido y utilizado es Scrum,
aunque también son muy utilizados Extreme Programming (programación extrema) y
Lean Programming (programación ligera).
2.3.2. Scrum
Esta metodología fue desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle
(Schwaber, Sutherland & Beedle, 2000). Define un marco para la gestión de proyectos, que se
ha utilizado con éxito durante los últimos años. Está especialmente indicada para proyectos con
un rápido cambio en los requerimientos. Sus principales características se pueden resumir en
dos. En primer lugar, el desarrollo de software se realiza en mediante iteraciones, denominadas
Sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable
que se muestra al cliente. La segunda característica importante son las reuniones a lo largo del
proyecto, entre ellas se destacan las reuniones diarias de 15 minutos del equipo de desarrollo
para coordinación e integración. En la Figura 2.B, se puede observar el ciclo de vida de la
metodología de desarrollo de Software Scrum.
25
Figura 2.B: Ciclo de vida de un proceso con la metodología Scrum.
Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque la
gestión no se basa en el seguimiento de un plan, sino en la adaptación continua a las
circunstancias de la evolución del proyecto.
El desarrollo se inicia desde la visión general de producto, en la cual se consigue un análisis
a alto nivel del alcance general del sistema. Luego, se plantean cuáles son los requerimientos
que se solicitaron para el sistema, ordenándose en lista es conocida como el Product Backlog,
dando detalle solo a las funcionalidades que, por ser las de mayor prioridad para el negocio, se
van a desarrollar en primer lugar, y pueden llevarse a cabo en un periodo de tiempo breve
(entre 15 y 60 días). Cada ciclo de desarrollo es conocido como Sprint y la lista de
requerimientos que se van a desarrollar durante los mismos es conocida como Sprint Backlog.
Cada uno de los Sprints es una iteración que produce un incremento terminado y operativo
del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a
través de reuniones breves de seguimiento llamadas Daily Meeting en las que todo el equipo
revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente.
Finalizado el Sprint, el equipo presenta sus resultados a los Stakeholders. Esta presentación
es la que permite inspeccionar el desarrollo de la funcionalidad y realizar distintos ajustes en el
proyecto.
Asimismo, una reunión de revisión, denominada Sprint Review Meeting, es llevada a cabo
por el equipo desarrollo ante el Product Owner. En esta reunión se presenta el trabajo realizado
26
y se priorizan los requerimientos para el siguiente Sprint. El Scrum Master en esta reunión se
encarga de fortalecer y alentar al equipo a seguir adelante y observar qué elementos del
proceso pueden ser mejorados para lograr mayor eficiencia y comodidad en el trabajo diario.
2.4. Beneficios del uso de las metodologías ágiles.
Resumiendo lo mencionado en la sección anterior, el uso de las metodologías ágiles
proveen ciertas ventajas por sobre los modelos tradicionales, entre las que se pueden
mencionar, como más relevantes:
Entregas constantes
Cuando se lidia con proyectos múltiples y no se aplican metodologías ágil, lo normal es
esperar a que se complete un proceso antes de arrancar con el segundo. Para poder lidiar con
este tipo de operación de proyectos se estila buscar el cómo finalizar entregas lo más pronto
posibles lo cual significa un inmenso riesgo de recorte de funcionalidades o calidad.
El desarrollo con metodología ágil refuerza las entregas múltiples lo cual contra el cliente es
un indicador operante y de cierto modo representaría un capital en trabajo. Como tal se
refuerza más bien la lista de funcionalidades del acuerdo de entrega y en el promedio implica
un enfoque en desarrollar la funcionalidad que se considere más vital para el proyecto desde el
simple inicio.
El desarrollo ágil aumenta la productividad
La producción de software que trabaja alrededor de las necesidades de negocio implica
ingresar conocimiento multidisciplinario en etapas simultáneas. La metodología ágil sirve para
enfocar la atención de los partidos por disciplina en el espacio que se les necesita e
inmediatamente liberar el talento para que puedan moverse entre zonas de trabajo.
Aplicar un sistema de tarea discretas contra las personas que las ejecutan simplifica la
distribución de entrega de información y consecuentemente del mismo sentido de capacidad de
27
control del mismo empleado lo cual resulta en un deseo inherente de procesar las tareas lo
más simple y rápidamente posible.
Simplifica el manejo de la sobrecarga de procesos
Los equipos que trabajan sobre normas y regulaciones han de validar su trabajo
constantemente lo cual representa un doble sentido de trabajo. Las metodologías por iteración
simplifican el proceso de entrega versus validación lo cual además permite adoptar cambios
sobre la marcha del alcance del proyecto.
Mejor perfil de productividad
Los equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo
largo de todo el ciclo de desarrollo. Si no se aplica un sistema ágil se presenta un patrón de
desarrollo tipo “palo de hockey” donde la mayoría del trabajo sucede en las primeras etapas y
ya que anden los equipos se van haciendo ajustes sobre el trabajo anterior. La realidad es que
casi nunca suele suceder que las piezas en equipo terminan trabajando juntos de manera
coherente.
Los equipos ágiles que mantienen un nivel de revisión por unidades discretas de entrega de
trabajo con cada iteración permiten realizar pruebas de rendimiento y sistemas desde el
principio. De este modo, defectos críticos como problemas de integración se descubren antes,
la calidad general del producto es mayor y el equipo funciona de manera más productiva
durante todo el ciclo de desarrollo.
Una mejor gestión del riesgo
No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja con software,
mientras más lejanas sean las entregas contra cliente o equipo más se maximiza el riesgo de
potencial desviación de la entrega contra la definición del proyecto inicial. Las metodologías
ágil permiten repasar en ciclos continuos progreso in media res de entregables y productos
semi-cerrados. Cuando fallan las entregas la metodología ágil permite ajustar el ciclo de trabajo
para enfocar el talento en zonas de mayor o menor riesgo a justificación de defender un
proyecto en su totalidad.
28
Capítulo 3
Propuesta
Las herramientas de gestión de proyectos actuales carecen de funcionalidad que provea a
los usuarios, una planificación eficiente para sus proyectos. En este contexto, se presenta la
herramienta “Intelligent Virtual Scrum” (IVS).
IVS es una herramienta de administración de proyectos, adaptada a la metodología ágil de
desarrollo de software Scrum. IVS ofrece asistencia al Scrum Master a lo largo de las
distintas etapas del ciclo de vida del proyecto: la definición del proyecto, la planificación de un
sprint y la Sprint Retrospective. La figura 3.A muestra un esquema conceptual de IVS.
3.1 Una herramienta para la administración inteligente de proyectos.
Figura 3.A: Esquema conceptual de IVS.
El primer paso del enfoque consiste en la definición del proyecto. En este punto, el
Scrum Master debe proveer a IVS toda la información del proyecto. Esta información consiste
de las personas disponibles para el mismo, el Product Backlog , las restricciones y preferencias
29
sobre el proyecto. El primer paso de la definición consiste en la selección de las personas,
denominadas recursos, que serán las encargas de llevar a cabo las tareas. Cada recurso
posee ciertas habilidades y un nivel de experiencia en cada una de ellas.
Una vez decididos los recursos que participarán del proyecto, el siguiente paso es la
definición del Product Backlog. El Product Backlog consiste en el conjunto de todas las User
Stories del proyecto. Estas User Stories involucran las tareas que deben realizarse, el tiempo
estimado de resolución de cada una y el tiempo máximo que puede usar un recurso para la
resolución de la misma. Así mismo, para que una tarea pueda ser resuelta, es necesario que
los recursos asignados posean ciertos conocimientos puntuales. Estos conocimientos deben
ser especificados por el Scrum Master al momento de detallar la tarea.
Dado que pueden existir varios recursos que posean los conocimientos requeridos, el
Scrum Master puede desear o no que un recurso específico sea el encargado de resolver una
determinada tarea. En este contexto, IVS permite al Scrum Master la especificación de
restricciones y preferencias. Muchas veces estas especificaciones dependen del conocimiento
de la organización, o de lo deseado por el administrador del proyecto en el momento de armar
el plan. Por ejemplo, en un proyecto el administrador puede desear que un recurso desarrolle
(o no) una determinada tarea.
El almacenamiento de la información definida en la etapa de “Definición del proyecto” se
llevó a cabo a partir del enfoque planteado en (Villaverde, 2009). Allí se define el modelo de
una Memoria Organizacional (MO) basada en Perfiles de Usuario, asociados a cada miembro
de la organización que participa en un proyecto. Estos perfiles están compuestos por un
conjunto de características propias de cada usuario. Estas características permiten obtener
patrones de comportamientos de cada uno durante el ciclo de vida del proyecto. La función
principal de la MO consiste en el almacenamiento de los perfiles de usuario junto con toda la
información relacionada a los proyectos sobre los que se ha trabajado.
Una vez definido el proyecto, el siguiente paso del enfoque consiste en la planificación de
un Sprint. Para iniciar esta planificación, el Scrum Master debe seleccionar del Product
Backlog un conjunto acotado de User Stories. Este conjunto define el Sprint Backlog. En este
30
punto, IVS obtiene datos históricos desde la MO, provenientes de sprints y/o proyectos
anteriores, y los utiliza para ofrecer asistencia al Scrum Master en la asignación de los recursos
a las tareas. Estos datos contienen información sobre como fue el desempeño de los recursos
en esos proyectos anteriores. Este desempeño es medido por las calificaciones obtenidas en
base a los criterios que el administrador consideró relevantes. Estos criterios pueden incluir, por
ejemplo, el tiempo que tardó el recurso en realizar la tarea, requerimientos de la misma,
habilidades del recurso y su integración con otros recursos.
Contando con los datos históricos y las tareas incluidas en el Sprint Backlog, IVS se basa en
un Algoritmo de Planning (AP) para realizar la planificación. El algoritmo de planning utilizado
en este trabajo es KMUCPop (Berdún, 2009). KMUCPop es un algoritmo que ve a los
problemas de planificación de proyectos como problemas de planning con preferencias. Un
problema de planning plantea un problema de planificación como un conjunto de estados y
acciones. Una solución a un problema de planning dado es una secuencia de acciones, que al
ser ejecutadas desde un estado inicial, permiten alcanzar el estado final. El agregado de
preferencias y restricciones en el armado de la solución es lo que potencia una solución sobre
otra posible.
En base a la definición anterior, para resolver el problema de planificación de proyectos,
nuestro enfoque transforma la información del proyecto en un conjunto de estados y acciones
de planning. El estado inicial está conformado por el Sprint Backlog, recursos a utilizar,
preferencias y restricciones definidas por el Scrum Master y los datos históricos obtenidos de la
MO. Las User Stories conforman las acciones disponibles para el problema de planning. De
esta forma los recursos requeridos por las User Stories conformaran las precondiciones de las
acciones del problema de planning, y de manera similar los resultados obtenidos en las postcondiciones. Por último, el estado final que se desea alcanzar, es un estado del proyecto en el
cual todas las User Stories definidas hayan sido tratadas. Esto último significa que estas User
Stories podrían ser asignadas a recursos o postergadas para futuros sprints, en caso de que no
sea posible una asignación.
Cuando se solicita la planificación de un sprint, AP intentará alcanzar el estado final
encontrando una asignación de recursos para cada User Story. Se puede decir que AP tratará
31
de ejecutar todas las acciones disponibles cumpliendo, para cada una de ellas, con sus
precondiciones iniciales. AP tratará de realizar estas asignaciones de manera tal de maximizar
la eficiencia de resolución del sprint. Para esto buscará en los datos históricos como ha sido
calificada una asignación previa similar a la que se está evaluando. El objetivo es encontrar la
asignación más adecuada para una tarea, en función de la conveniencia del sprint. Por lo tanto,
debido a que el estado inicial está compuesto por datos históricos y preferencias del usuario,
AP obtendrá un plan de trabajo eficiente y que refleja las decisiones tomadas por el
administrador y en la organización en sprints y proyectos anteriores.
Una vez que AP logra armar una planificación de un Sprint, se muestra al Scrum Master la
solución alcanzada. Esta solución mostrará la asignación de recursos sugerida para cada User
Story, conformando el Sprint Backlog propuesto. En este punto, el Scrum Master analiza la
propuesta y puede tomar diferentes cursos de acción. Puede optar por rechazar la propuesta;
modificar el Sprint Backlog original y realizar una nueva planificación; o directamente aceptar la
propuesta.
En caso de rechazar la propuesta, el Scrum Master puede, o no, realizar una nueva
definición del Sprint Backlog, para luego solicitar una nueva planificación. En caso de solicitar
una nueva planificación incorporando nuevas restricciones, pero sobre el Sprint Backlog
propuesto, se repite el proceso de planificación de manera que el administrador solo lo acepte
cuando se encuentra satisfecho con el resultado. Una vez aceptada la sugerencia, el Sprint
Backlog Propuesto se encuentra listo en la herramienta y se da inicio la ejecución real del
proyecto dentro de la misma.
La última etapa de este enfoque, denominada Sprint Retrospective se inicia en el
momento de la finalización de la ejecución del proyecto. En esta etapa, el Scrum Master debe
realizar la calificación de los recursos. Como se mencionó anteriormente, esta calificación será
utilizada en futuras planificaciones por AP, para realizar asignaciones cada vez más eficientes.
Junto con las calificaciones, el Scrum Master puede tomar otras decisiones que afecten futuras
planificaciones. Por ejemplo, si un recurso tuvo un desempeño destacado, puede optar por
incrementar el nivel que posee el mismo en cada una de sus habilidades, actualizando de esta
manera la información de la organización.
32
Es importante notar que IVS sigue un proceso iterativo. Durante este proceso se almacena
constantemente la información generada producto de la interacción de IVS con el Scrum
Master. Esta información surge principalmente del análisis de las preferencias del Scrum
Master así como de la evaluación de los desempeños de los recursos. El volumen creciente de
información almacenada en la MO permitirá a IVS ofrecer planificaciones cada vez más
certeras, convirtiéndose en una herramienta de gestión de proyectos que satisface las
necesidades de planificación actual de la organización y del Scrum Master.
3.2. Ejemplo conductor
Para facilitar la explicación de cada uno de los pasos del enfoque, en las siguientes
secciones utilizaremos un ejemplo conductor, que consiste en planificar un proyecto para el
desarrollo de una sala de Virtual Scrum, perteneciente a la Universidad 3D. Este ejemplo
servirá para mostrar como interactúa un Scrum Master con IVS durante las diferentes etapas
del planeamiento.
3.2.1. Perfiles de usuario
Como se mencionó al comienzo de este capítulo, el almacenamiento de la información del
proyecto se basa en el enfoque planteado en (Villaverde, 2009). Este enfoque tiene como
objetivo codificar almacenar en la MO Perfiles de Usuarios. Estos perfiles son construidos a
partir de la información que se recolecta producto de la interacción del Scrum Master con la
herramienta durante las distintas etapas del ciclo de vida del proyecto. En cada etapa, la
interacción se produce de diferentes maneras, realizando diferentes acciones. La tabla 3.1
muestra las diferentes acciones que puede realizar el usuario en cada etapa.
ETAPA
ACCIONES
Definición de Product Backlog
Definición del proyecto
Definición de recursos
Definición de roles
Definición de preferencias y restricciones
Planificación del sprint
Sprint Retrospective
Definición de Sprint Backlog
Incorporación de preferencias y restricciones
Calificación de asignaciones
Revalorizar aptitudes técnicas de los recursos
Tabla 3.1.: Interacción del Scrum Master con la herramienta durante las diferentes etapas.
33
Durante cada etapa, la herramienta se enfoca en capturar las acciones realizadas por los
usuarios, las cuales serán utilizadas para generar conocimiento y almacenarlo en la MO. Este
conocimiento servirá como entrada para AP y será utilizado con el fin de conseguir un plan de
trabajo resultante que refleje las preferencias del Scrum Master.
3.2.2. Etapa 1 - Definición del proyecto
En esta etapa el Scrum Master debe proveer a IVS toda la información relacionada al
proyecto sobre el que desea trabajar. Esta información consiste principalmente en la definición
de los recursos disponibles, del Product Backlog y las restricciones y preferencias del Scrum
Master.
El primer paso de la definición del proyecto, consiste en la selección de los recursos que
podrán ser utilizados para la resolución del mismo. Esta selección se realiza sobre un conjunto
de recursos previamente definidos. La tabla 3.2 muestra cada recurso utilizado para este
ejemplo junto con las habilidades que posee cada uno y sus respectivos niveles de experiencia.
RECURSO
Ana
Roberto
Rodrigo
Julio
Aníbal
Martin
HABILIDAD
NIVEL DE EXPERIENCIA
Programación SQL
4
Programación C#
4
Programación SQL
7
Programación C#
7
Programación SQL
10
Programación C#
10
Creatividad
4
Modelado 3D
Creatividad
4
7
Modelado 3D
7
Creatividad
10
Modelado 3D
10
Tabla 3.2.: Recursos involucrados con sus respectivos conocimientos.
En función de las habilidades que posee cada recurso y su nivel de experiencia, IVS es
capaz de determinar los roles que cada recurso puede ejercer. Para llevar a cabo esta tarea,
IVS requiere que previamente estén definidos estos roles en la MO. La definición de un rol,
consiste en un conjunto de habilidades y los niveles de experiencia necesarios para poder
desempeñar dicho rol. Para el ejemplo conductor se utilizó la siguiente definición de roles.
34
ROL
HABILIDAD REQUERIDA
Programador junior
Programador semi-senior
Programador senior
Diseñador gráfico junior
Diseñador gráfico semi-senior
Diseñador gráfico senior
NIVEL MINIMO
NIVEL MAXIMO
Programación C#
1
4
Programación SQL
1
4
Programación C#
4
7
Programación SQL
4
7
Programación C#
7
10
Programación SQL
7
10
Creatividad
1
4
Modelado 3D
1
4
Creatividad
4
7
Modelado 3D
4
7
Creatividad
7
10
Modelado 3D
7
10
Tabla 3.3: Roles y niveles de experiencia requeridos de cada uno
IVS se encarga de definir los roles que puede ejercer cada recurso utilizando el siguiente
criterio: “Si un recurso posee las habilidades requeridas para satisfacer un determinado rol, y
en cada una posee una calificación superior al nivel mínimo requerido por ella, entonces ese
recurso puede ejercer el rol en cuestión.”
Bajo el criterio anterior, para el ejemplo conductor quedan definidos los distintos roles que
puede ejercer cada recurso, como se muestra en la tabla 3.4.
RECURSO
ROLES QUE PUEDE EJERCER
Ana
Programador junior
Roberto
Programador semi-senior / Programador junior
Rodrigo
Programador senior / Programador semi-senior / Programador junior
Julio
Diseñador gráfico junior
Aníbal
Diseñador gráfico semi-senior / Diseñador gráfico junior
Martin
Diseñador gráfico senior / Diseñador gráfico semi-senior / Diseñador gráfico junior
Tabla 3.4 Roles que puede ejercer cada recurso
El segundo paso durante esta etapa consiste en la definición del Product Backlog, que se
trata como un documento de alto nivel para todo el proyecto. Es la definición de todas las
funcionalidades requeridas, las cuales son priorizadas según el criterio del Scrum Master. Esta
definición puede incluir información tal como tiempo estimado de resolución, tiempo límite y
dependencias de otra User Story.
Siguiendo la definición de las metodologías ágiles, cada User Story es dividida en diferentes
tareas de menor complejidad. El Scrum Master es el encargado de definir cada una de las
35
tareas que componen una User Story. La tabla 3.5 muestra el Product Backlog utilizado para el
ejemplo conductor.
USER STORY
TAREA
Diseñar estructura de base de datos
Soporte de persistencia
Implementar altas bajas y modificaciones (ABM)
Diseñar interfaz de login
Desarrollo de login
Implementar funcionalidad para inicio de sesión
Crear imágenes e interfaz
Visualización de panel de planning poker
Implementar script para eventos del mouse
Implementar lógica de panel
Implementar soporte para multijugador
Implementar animaciones del avatar
Implementación de avatar
Agregar control de movimiento
Crear modelo 3D del avatar
Crear modelo 3D de la sala
Implementar sala de juego 3D
Implementar soporte multijugador
Tabla 3.5: Product Backlog.
Durante la definición de una tarea, IVS requiere que el Scrum Master defina los roles
necesarios para lograr la resolución de la misma. Puede ocurrir que determinadas tareas
requieran la utilización de más de un recurso con el mismo rol. Por esto, es necesario
especificar, para cada rol, que cantidad se necesita. La tabla 3.6 muestra cada una de las
tareas previamente definidas junto con el rol requerido para la resolución de la misma y la
cantidad de recursos necesarios.
TAREA
ROL REQUERIDO
CANTIDAD
Diseñar estructura de base de datos
Programador senior
1
Implementar altas bajas y modificaciones (ABM)
Programador semi-senior
1
Diseñar interfaz de login
Diseñador gráfico junior
1
Implementar funcionalidad para inicio de sesión
Programador junior
1
Crear imágenes e interfaz
Diseñador gráfico junior
1
Implementar script para eventos del mouse
Programador junior
1
Implementar lógica de panel
Programador semi-senior
1
Implementar soporte para multijugador
Programador senior
1
Programador semi-senior
1
Diseñador gráfico senior
1
Diseñador gráfico semi-senior
1
Programador semi-senior
1
Crear modelo 3D del avatar
Diseñador gráfico senior
1
Crear modelo 3D de la sala
Diseñador gráfico junior
1
Implementar soporte multijugador
Programador senior
1
Implementar animaciones del avatar
Agregar control de movimiento
Tabla 3.6: Tareas y roles requeridos para su resolución.
36
El último paso de esta etapa consiste en definir preferencias o restricciones de asignaciones
en caso de ser requeridas. El Scrum Master puede definir que para realizar la resolución de
determinada tarea no se utilice a cierto recurso, o caso contrario, que se utilice a un recurso en
particular. La tabla 3.7 muestra las restricciones de asignación de recursos utilizadas para el
ejemplo. En este caso, los recursos Rodrigo y Roberto, no podrán ser asignados a la tarea
“Implementar funcionalidad para inicio de sesión”.
TAREA
RESTRICCION DE ASIGNACION
Implementar funcionalidad para inicio de sesión
Rodrigo
Implementar funcionalidad para inicio de sesión
Roberto
Tabla 3.7: Restricciones de asignación
Para demostrar que AP respeta las restricciones impuestas por el Scrum Master, se optó
por elegir una tarea que pueda ser asignada a más de un recurso. Observando la tabla 3.6 se
puede apreciar que la tarea “Implementar funcionalidad para inicio de sesión” requiere de un
recurso que pueda cumplir el rol de “Programador junior”. En este proyecto, se cuenta con tres
recursos capacitados para cumplir el mencionado rol, Ana, Roberto y Rodrigo. Dado que el
Scrum Master podría considerar que esta tarea debería ser realizada por un programador junior
y no por un programador de más capacidad, IVS brinda la posibilidad de crear estas
restricciones de asignaciones. El Sprint Backlog propuesto por IVS, deberá retornar como
asignación para la tarea en cuestión, al recurso denominado Ana.
De la misma manera que el Scrum Master puede definir restricciones de asignaciones,
también puede definir preferencias. El Scrum Master podría considerar que cierta tarea que
requiere, como mínimo, de un programador semi-senior, debería ser asignada a un
programador senior, ya que la considera por demás importante. Para obligar a AP a realizar
esta asignación, el Scrum Master puede definir la siguiente preferencia.
TAREA
ROL REQUERIDO
Implementar animaciones del avatar
PREFERENCIA DE
ASIGNACION
Programador semi-senior Rodrigo
Tabla 3.8: Preferencias de asignación
37
Observando la tabla 3.4 de esta sección, se puede apreciar que Rodrigo es un programador
senior. AP deberá tener en cuenta esta preferencia de asignación para imponer a este recurso
por sobre la asignación de un programador semi-senior, que sería, en principio, la asignación
más lógica para la tarea involucrada.
Otro tipo de restricciones que permite definir IVS, son las dependencias entre tareas. Estas
dependencias permitirán al Scrum Master definir, por ejemplo, que una tarea no puede
comenzar si otra no ha sido finalizada. IVS ofrece cuatro posibles formas de dependencias con
que se pueden relacionar las tareas:

Finish to Start:
Indica que para poder comenzar a realizar una tarea,
es necesario que la tarea de la cual depende, haya finalizado.

Start to Start:
Indica que para poder comenzar a realizar una tarea,
es necesario que la tarea de la cual depende, haya comenzado.

Start to Finish:
Indica que para poder finalizar una tarea, es necesario
que la tarea de la cual depende, haya comenzado.

Finish to Finish:
Indica que para poder finalizar una tarea, es necesario
que la tarea de la cual depende, haya finalizado.
Durante esta etapa se han enumerado diversas acciones que el Scrum Master puede
realizar. Estas acciones permiten comenzar a definir el Perfil de Usuario del mismo.
Siguiendo el ejemplo conductor, se puede apreciar que el Scrum Master tiene una
preferencia de asignación para la tarea “Implementar animaciones del avatar”. Esta tarea
requiere como rol, un “Programador semi-senior”. Sin embargo, el Scrum Master, optó por
asignar a un recurso con un rol de “Programador senior”. Si esta conducta se repitiera durante
sucesivas planificaciones, el algoritmo podría determinar que el Scrum Master prefiere utilizar
recursos de mayor experiencia que la requerida para determinado tipo de tarea.
Como conclusión, IVS ofrece variadas opciones para la definición de un proyecto. Es
responsabilidad del Scrum Master manipular estas opciones de forma coherente para obtener
resultados factibles. El algoritmo será incapaz de encontrar soluciones cuando se definan, por
38
ejemplo, restricciones contradictorias o preferencias imposibles de cumplir. Habiendo realizado
una definición completa del proyecto, se procede a la etapa de “Planificación de un sprint”.
3.2.3. Etapa 2 - Planificación de un sprint
El primer paso de esta etapa consiste en la definición del Sprint Backlog. El Sprint Backlog
es simplemente un subconjunto de las User Stories definidas en el Product Backlog. El Scrum
Master es el encargado de seleccionar este subconjunto en base a las prioridades de
resolución de cada tarea o en base a criterios del negocio. Para el ejemplo conductor se
definieron dos sprints y se repartieron las User Stories entre ellos como se muestra en la tabla
3.9.
SPRINT
1
USER STORY
Soporte de persistencia
Desarrollo de login
Visualización de panel de planning poker
2
Implementación de avatar
Implementar sala de juego 3D
Tabla 3.9: Sprint Backlogs.
Cuando el Scrum Master solicita la planificación de un sprint, AP obtiene de la MO datos
históricos de desempeños de los recursos. Estos datos pueden provenir tanto de sprints como
de proyectos anteriores. Esta información histórica es de vital importancia para que AP pueda
realizar asignaciones cada vez más eficientes. Como ejemplo, si se requiere que una tarea sea
asignada a un programador senior, AP tratará de asignar, priorizando los programadores senior
disponibles, al recurso que haya tenido un mejor desempeño histórico.
Una vez que AP logra armar una planificación de un Sprint, retorna al Scrum Master el
Sprint Backlog propuesto. Este último consiste en una sugerencia de asignaciones de
recursos a las tareas recibidas en el Sprint Backlog original. Se presenta el Sprint Backlog
propuesto al Scrum Master indicando cada tarea del Sprint Backlog junto con el recurso que fue
asignado para su resolución. Puede suceder que debido a ciertos factores algunas tareas no
tengan una asignación definida. Por ejemplo, la duración definida para los sprints, podría no ser
39
suficiente para lograr la resolución de todas las User Stories que involucran. En este caso, la
propuesta al Scrum Master, sugeriría posponer las User Stories para futuros sprints.
La tabla 3.10 muestra los recursos asignados luego de solicitar las planificaciones de los
sprints definidos en la etapa anterior.
TAREA
RECURSO ASIGNADO
ROL
SPRINT BACKLOG PROPUESTO PARA EL SPRINT 1
Diseñar estructura de base de datos
Rodrigo
Programador senior
Implementar altas bajas y modificaciones
Rodrigo
Programador senior
Diseñar interfaz de login
Implementar funcionalidad para inicio de
sesión
Martin
Diseñador gráfico senior
Ana
Programador junior
SPRINT BACKLOG PROPUESTO PARA EL SPRINT 2
Crear imágenes e interfaz
Julio
Diseñador gráfico junior
Implementar script para eventos del mouse Ana
Programador junior
Implementar lógica de panel
Roberto
Programador semi-senior
Implementar soporte para multijugador
Rodrigo
Programador senior
Rodrigo
Programador senior
Martin
Diseñador gráfico senior
Rodrigo
Aníbal
Programador senior
Diseñador gráfico semisenior
Crear modelo 3D del avatar
Martin
Diseñador gráfico senior
Crear modelo 3D de la sala
Julio
Diseñador gráfico junior
Implementar soporte multijugador
Rodrigo
Programador senior
Implementar animaciones del avatar
Agregar control de movimiento
Tabla 3.10: Sprint Backlogs propuestos
Como se puede apreciar en la tabla 3.10, las tareas del sprint 1 fueron asignadas a recursos
de mayor experiencia. Esto ocurre debido a que AP siempre intenta asignar el mejor recurso
disponible para la realización de una tarea. Como contrapartida, dado que en la etapa de
definición del proyecto se definieron restricciones de asignación para la tarea “Implementar
funcionalidad para inicio de sesión”, la misma fue asignada a un recurso de menor experiencia.
En la figura 3.B. se puede apreciar como IVS ofrece el Sprint Backlog propuesto al Scrum
Master. En este punto, IVS permite tres cursos de acción, rechazar la propuesta, planificar
nuevamente el sprint incorporando nuevas restricciones o aceptar el plan propuesto. Cada una
de estas opciones tendrá una respuesta diferente por parte de la herramienta. El rechazo de la
propuesta no tendrá ningún efecto sobre el proyecto. Éste volverá al mismo estado en el que
40
se encontraba antes de la ejecución del Algoritmo de Planning. La re-planificación incorporará
las nuevas restricciones definidas por el Scrum Master y ejecutará nuevamente el Algoritmo de
Planning. Como resultado se obtendría un plan más acorde a las necesidades del usuario. Por
último la aceptación del plan ocasionará que se avance a la siguiente etapa, en donde el
administrador evaluará las asignaciones de recursos.
Figura 3.B: IVS - Sprint Backlog Propuesto.
Los diferentes cursos de acción que puede tomar el Scrum Master cuando IVS le sugiere un
plan, son utilizados para incrementar el conocimiento sobre su perfil. Siguiendo el ejemplo
conductor, el algoritmo podría determinar una preferencia del Scrum Master por las
asignaciones de recursos de mayor experiencia a tareas que requieren una menor.
3.2.4. Etapa 3 - Sprint Retrospective
La Sprint Retrospective es un mecanismo importante que permite al equipo evolucionar y
mejorar a través del ciclo de vida de un proyecto. Es durante esta etapa donde se identifica
que cosas se realizaron correctamente y cuales se podrían mejorar.
IVS ofrece al Scrum Master la posibilidad de calificar el desempeño de los recursos en las
tareas planificadas. Esta calificación resulta importante para las futuras planificaciones de
sprints, ya que AP tiene en cuenta la información histórica de los proyectos a la hora de realizar
41
nuevas asignaciones. Esto permitirá a IVS ofrecer planificaciones cada vez más eficientes,
convirtiéndose en una herramienta de gestión de proyectos que satisface las necesidades
actuales de planificación.
Siguiendo el ejemplo conductor, se realiza una posible calificación para el Sprint Backlog
propuesto, tal como se muestra en la tabla 3.11.
TAREA
RECURSO ASIGNADO
CALIFICACION
SPRINT BACKLOG PROPUESTO PARA EL SPRINT 1
Diseñar estructura de base de datos
Rodrigo
9
Implementar altas bajas y modificaciones (ABM)
Rodrigo
9
Diseñar interfaz de login
Martin
8
Ana
4
Implementar funcionalidad para inicio de sesión
Tabla 3.11: Calificación de asignaciones
Esta última etapa resulta una de las más importantes para la generación del perfil de
usuario. Es aquí donde el perfil de usuario se refina para determinar con mayor precisión las
preferencias de asignaciones que posee el Scrum Master. Esto puede determinarse en base a
las calificaciones de desempeño de cada recurso. Siguiendo el ejemplo conductor, podría
ocurrir que a lo largo de sucesivas planificaciones el Scrum Master continúe calificando al
recurso Rodrigo con notas altas y al recurso Ana con calificaciones bajas. Bajo este
comportamiento, AP podría determinar, en una futura planificación, una preferencia por parte
del Scrum Master para la asignación de Rodrigo por sobre el recurso Ana.
Con la calificación del desempeño de los recursos se puede dar por finalizado un Sprint,
durante el cual se fue almacenando constantemente la información generada producto de la
interacción con el Scrum Master. Esta información almacenada brindará a IVS un aprendizaje
constante durante la gestión de los proyectos.
42
3.2.5. Conclusión
IVS es una herramienta que facilita la gestión de proyectos que trabajan bajo la metodología
ágil Scrum. Provee un mecanismo automatizado de gestión de recursos. Además brinda una
constante asistencia al usuario a lo largo de las diferentes etapas de planeamiento de un
proyecto. Esta asistencia es posible gracias a un constante aprendizaje de IVS a partir del uso
de Perfiles de Usuarios, propuesto por el enfoque de (Villaverde,2009).
Como se mencionó en el capítulo 2, la Amnesia Organizacional está ligada al concepto de
aprendizaje organizacional. Es por esto que se planteó un enfoque que permitiera obtener una
herramienta capaz de aprender de las interacciones con el usuario. .
Gracias a la integración de los enfoques de (Berdún, 2009) y (Villaverde, 2009) en la
herramienta de administración de proyectos IVS este trabajo presenta una solución al problema
de la Amnesia Organizacional, en el cual el conocimiento es almacenado y reutilizado para
futuros proyectos.
43
Capítulo 4
Diseño e implementación
La arquitectura final de IVS se diseñó en base a la necesidad de crear una herramienta de
gestión de proyectos que ofreciera, además, funcionalidad para la planificación eficiente de los
mismos. En base a esto, se detectó la necesidad de utilizar un algoritmo de planificación que
pudiera realizar esta tarea. Como se mencionó en el capítulo 3, el algoritmo requiere de un
repositorio que se encargue de almacenar los datos históricos del proyecto de manera que
puedan ser reutilizados de forma efectiva.
Se identificaron tres herramientas principales, una herramienta de gestión de proyectos,
una memoria organizacional y un algoritmo de planeamiento de proyectos. Cada una de
estas provee funcionalidades totalmente independientes entre sí. Para lograr construir una
herramienta que provea conjuntamente estas funcionalidades es necesario que cada
componente exponga las suyas de manera que puedan ser accedidas por las demás. Es aquí
donde surge el concepto de servicios, donde estas funcionalidades son expuestas mediante el
uso de interfaces. En base a estas necesidades se optó por utilizar una arquitectura orientada
a servicios (SOA).
SOA es un estilo arquitectónico que se base en la independencia de las plataformas e
infraestructuras tecnológicas, lo que le permite integrarse con sistemas y aplicaciones
diferentes de forma sencilla. Gracias a esta independencia, SOA es un estilo flexible que
permite la reutilización de las tecnologías existentes.
Dado que los componentes deben interactuar entre sí y la naturaleza de cada uno es
diferente, surge la necesidad de crear un componente adicional que permitiera integrar todas
las herramientas, para que puedan trabajar conjuntamente y utilizando un canal común de
comunicación. Este modo de integración permite obtener una arquitectura flexible, que permite
el reemplazo o la adición de componentes sin afectar la estructura existente del sistema. Para
44
lograr esta flexibilidad en la arquitectura, es necesario que la comunicación entre el
componente integrador y el resto de las herramientas se realice de manera transparente e
independiente de la tecnología de cada una. El aislamiento de los componentes fue posible
gracias a la implementación del patrón de integración MessageBus, que permite desacoplar
los componentes que forman una aplicación. MessageBus es una combinación de un modelo
de datos común, un conjunto de comandos comunes y una infraestructura de mensajería que
permite a los diferentes sistemas comunicarse a través de un conjunto compartido de
interfaces. La comunicación entre aplicaciones se logra mediante un bus en común. Los
mensajes son enviados a través de dicho bus, y cada aplicación recibirá el que le corresponda.
En la figura 4.A. se puede apreciar el concepto del patrón MessageBus.
Figura 4.A. IVS. Patrón de integración MessageBus.
4.1. Arquitectura del sistema
En la figura 4.B se muestra la arquitectura de IVS, con las herramientas utilizadas para
cumplir los roles de los componentes mencionados anteriormente. Se utilizó una extensión de
Virtual Scrum (*) como herramienta de gestión de proyectos, KMUCPop como algoritmo de
planificación y una memoria organizacional basada en el enfoque [Villaverde, 2009]. Se eligió
SmartFox Server como componente integrador cumpliendo el rol de MessageBus mencionado
anteriormente.
(*) El detalle de la extensión de funcionalidad realizada a Virtual Scrum se muestra en el Anexo I.
45
Figura 4.B. IVS. Arquitectura del sistema.
Para poder integrar cada herramienta a la arquitectura, es necesario que cada una de ellas
implemente la interfaz definida por el componente integrador SmartFox Server (SFS). Para
esto fue necesario incorporar en cada herramienta un componente denominado, de ahora en
adelante, SmartFox Integrator (SFI). La responsabilidad principal de este último consiste en el
intercambio de mensajes con SmartFox Server. SFI es capaz de interpretar los mensajes
provenientes de SFS y traducirlos de manera que puedan ser interpretados por la herramienta
en la cual fue incorporado. De la misma manera, SFI es capaz de traducir la información
proveniente de la herramienta de modo que pueda ser interpretada por SFS. El componente
SFI es único para cada herramienta y su implementación dependerá de la naturaleza de cada
una de ellas.
Virtual Scrum (VS) es el componente encargado de mantener la interacción con los
usuarios. Tiene como responsabilidad principal brindar al usuario una interfaz amigable para la
administración de proyectos, siguiendo los conceptos de la metodología ágil Scrum. Se
encarga, de proveer funcionalidad básica como la creación de proyectos, tareas y recursos.
Además provee funcionalidad relacionada con la planificación de proyectos. VS permite a los
usuarios trabajar sobre las diferentes etapas del ciclo de vida del proyecto: la definición del
proyecto, la planificación de un sprint y la Sprint Retrospective.
El Algoritmo de planeamiento de proyectos es el componente encargado de ofrecer
asistencia al administrador, estableciendo las asignaciones de recursos requeridas y creación
46
de dependencias necesarias para constituir un plan de trabajo final. Este componente es capaz
de analizar los datos existentes en la memoria organizacional para realizar las planificaciones.
La Memoria Organizacional funciona como repositorio de la arquitectura. Tiene como
responsabilidades principales persistir los eventos del administrador y almacenar el
conocimiento organizacional de manera que pueda ser utilizado de forma efectiva. Toda la
información almacenada en la MO debe estar disponible para ser accedida por el resto de los
componentes. Para esto fue necesaria la creación de una capa de servicios que brinda una
forma bien definida de acceso a la información. Esta capa resulta un elemento clave para el
sistema, ya que todo el intercambio de información pasará a través de ella.
El componente SmartFoxServer tiene como objetivo funcionar como integrador de las
herramientas y hacerlo de modo que las mismas trabajen de manera totalmente independiente
entre sí. En la arquitectura de IVS, SmartFox Server cumple el rol de MessageBus,
permitiendo al resto de los componentes comunicarse adecuadamente.
El diseño flexible de la arquitectura de IVS, permite que cualquiera de los componentes,
puedan ser reemplazados por otro componente de similares características. Para esto, sólo es
necesario que el nuevo componente que quiera incluirse implemente la interfaz definida por
SmartFox Server, mediante la creación del componente SmartFox Integrator. Este elemento
adicional funcionará como nexo de comunicación entre el componente donde se incluya y
SmartFox Server.
La elección de SmartFox Server como componente integrador se debe a que está diseñado
con una arquitectura escalable y de alto rendimiento que puede soportar el acceso en paralelo
de miles de clientes. SFS está orientado hacia plataformas multiusuarios y comunidades
virtuales. Estas características convierten a SFS en un buen aliado del componente Virtual
Scrum, el cual permite a cientos de usuarios trabajar al mismo tiempo en un ambiente virtual.
47
Figura 4.C. Diagrama de clases de IVS.
En la Figura 4.C se puede observar el diagrama de clases del enfoque propuesto. En este
se puede apreciar la integración del algoritmo de planificación, la memoria organizacional y
Virtual Scrum a traves del componente integrador SmartFox Server. Como se puede observar
el diagrama no entra en detalle en la implementación de los componentes integrados, sino que
solo se muestra la interfaz por la que se accede a la funcionalidad brindada por los mismos.
La clase WindowController es la encargada de administrar los eventos generados por el
usuario de Virtual Scrum. Dependiendo del tipo de acción elegida por el usuario, invocará al
método correspondiente de la clase ProjectController. La clase ProjectController se encarga de
armar el objeto que será enviado por la clase SmartFoxIntegratorVS hacia el componente
SmartFoxServer.
48
El componente SmartFox Server se encarga de recibir y reenviar los mensajes provenientes
del resto de los componentes hacia el destino correspondiente. Utiliza para este procedimiento
la clase IVSExtension, que hereda el comportamiento de la clase SFSExtension propia de
SmartFox.
El componente KMUCPop centra su funcionalidad en la clase PlanningService, la cual
provee un método para realizar la ejecución del planning y otros métodos para realizar aceptar
o rechazar el plan propuesto, según se especificó anteriormente.
El último componente de la arquitectura, [Villaverde,2009] es el encargado de mantener
actualizado el repositorio. Para esto utiliza la clase MOService, la cual provee todos los
métodos de acceso a la información necesarios durante el ciclo de vida del proyecto.
El desacople de los componentes se logra gracias al uso de los SFI incluidos en cada uno.
Como se mencionó anteriormente, la implementación de cada SFI dependerá de la naturaleza
del componente en el que se está incluyendo. Para clarificar el funcionamiento de los SFI se
muestran los siguientes diagramas de secuencias. Estos diagramas ejemplifican la
comunicación que se lleva a cabo entre todos los componentes cuando el usuario realiza la
creación de un proyecto.
Figura 4.D.a. Diagrama de secuencia. Envío de un mensaje
49
Figura 4.D.b. Diagrama de secuencia. Recepción de un mensaje.
En la figura 4.D.a se puede apreciar que, en el momento que el usuario inicia la creación de
un proyecto, la clase ProjectController se encarga crear el objeto que será enviado a la clase
SmartFoxIntegratorVS. Esta última, es la clase encargada de empaquetar el objeto recibido de
manera que pueda ser interpretado por la clase IVSExtension incluida en el componente
SmartFoxServer.
En la figura 4.D.b se muestra la interacción entre los componentes cuando SmartFoxServer
recibe el paquete creado por SmartFoxIntegratorVS. La primera tarea que realiza
SmartFoxServer es identificar el destino que tiene el paquete recibido. Para esto utiliza la clase
IVSExtension, que se encarga, además, de reenviar el paquete hacia el destino
correspondiente, en este caso SmartFoxIntegratorMO. Este último es el encargado de
desempaquetar el paquete recibido y reenviarlo hacia la clase MOService en forma de mensaje
que ella pueda interpretar. El último paso consiste en el salvado de la información recibida en el
paquete, tarea realizada por la clase MOService.
50
4.2. Ejemplo conductor
Para clarificar como se produce la interacción entre los distintos componentes de la
arquitectura, se mostrarán diagramas de secuencia siguiendo el ejemplo conductor utilizado en
el capítulo anterior. La explicación se llevará a cabo en base a las tres etapas principales del
ciclo de vida de un proyecto: Definición del Proyecto, planificación de un sprint y Sprint
Retrospective.
Al igual que en el capítulo 3, se mostrarán ejemplos que ayudarán a entender como los
componentes se comunican entre sí, y que tipos de mensajes envían. Estos ejemplos, serán
descriptos en base a diagramas de secuencia simplificados, mostrando las partes del sistema
involucradas, las invocaciones entre ellos, y el orden de las mismas. Para simplificar los
diagramas no se incluyen los mensajes que ocurren entre los componentes integradores, etapa
que fue explicada anteriormente.
Al finalizar la sección, el lector tendrá un panorama claro del resultado final de la integración
de las diferentes aplicaciones. El objetivo es detallar el rol que el componente integrador
cumple dentro de la arquitectura, y demostrar la independencia de las aplicaciones entre sí.
4.2.1. Definición del Proyecto
Como se mencionó en el capítulo 3, en esta esta etapa el Scrum Master se encarga de
proveer información sobre el proyecto, User Stories y sus requerimientos, recursos y sus
habilidades. Para ello, el Scrum Master hace uso de Virtual Scrum y las funcionalidades que
éste provee. El componente Virtual Scrum recolecta la información provista por el Scrum
Master, y se la envía al componente integrador SmartFox en forma de peticiones. Este último,
procesa estas peticiones, redirigiéndolas al componente correspondiente.
51
Figura 4.E Diagrama de secuencia para la definición de un nuevo proyecto.
En el diagrama de la figura 4.E, se puede apreciar que el Scrum Master hace uso de la
funcionalidad de Virtual Scrum para crear un nuevo proyecto. VS recibe el pedido del Scrum
Master, procesa el mensaje de manera que pueda ser interpretado por SmartFox Server y se lo
reenvía. SmartFox Server se encarga de identificar el tipo de solicitud e identifica a que
componente debe reenviarla. En este caso, el destinatario es el componente MO. Este último
es quien realmente se encarga de procesar la petición del Scrum Master. Suponiendo que no
hay ningún tipo de problema en la información provista por el Scrum Master, la MO almacena el
nuevo proyecto.
La interacción entre los componentes es similar ante cada petición del usuario durante esta
etapa. De la misma manera que el Scrum Master realiza la definición del proyecto, define
también los recursos involucrados, crea las tareas involucradas en el proyecto y define sus
preferencias y restricciones.
Como se puede apreciar, el componente del Algoritmo de Planeamiento no tiene
participación en este tipo de transacciones. Esto se debe a que es solo flujo de información que
es almacenada en la MO. La comunicación entre VS y MO es totalmente transparente gracias a
una integración desacoplada, facilitada por el componente SmartFox Server.
52
4.2.2. Planificación del Sprint
En esta sección se explican las interacciones de los componentes de la arquitectura en el
escenario de la planificación de un sprint. Como se mencionó en el capítulo 3, en este
escenario el Scrum Master tiene diferentes cursos de acción posibles. Si el plan otorgado por el
algoritmo no satisface las necesidades de la organización, el Scrum Master puede acomodar
las características del plan para planear nuevamente. Una vez que el plan es aceptado, la
información es almacenada, actualizando las características del perfil del Scrum Master, como
así también información pertinente al proyecto, tareas y los recursos junto a sus habilidades.
La planificación de un Sprint Backlog envuelve a todos los componentes de la arquitectura.
En la figura 4.F, se presenta un diagrama de secuencia que ilustra este escenario. Se muestran
las invocaciones más pertinentes entre las distintas partes del sistema.
Ejecución de Planning
53
Figura 4.F: Diagrama de secuencia para la planificación de un Sprint.
El Scrum Master solicita la planificación del Sprint. Para ello, provee al Virtual Scrum un
listado de User Stories, que representan el Sprint Backlog. Opcionalmente, como se mencionó
en el capítulo 3, el Scrum Master puede ingresar restricciones y preferencias. Cuando esta
solicitud es recibida por AP, comienza la ejecución de diferentes procesos, como la validación
de datos, la recolección de datos históricos, procesamiento de requisitos y preferencias. Como
el diagrama muestra, la recolección de datos se logra, por medio de SmartFox server,
invocando a MO. Finalmente, la ejecución del algoritmo comienza. Una vez que el algoritmo
encuentra una posible solución, envía el Sprint Backlog propuesto al Scrum Master. En este
punto, el Scrum Master puede tomar tres cursos de acción. En este caso se muestra la
secuencia de acciones para el escenario donde el plan propuesto satisface al Scrum Master, y
este decide aceptar el plan propuesto. Llegado este punto, el Scrum Master solicita al VS que
54
el plan sea guardado en el repositorio. VS envía la petición de salvar plan, una vez más, por
medio de SmartFox server. El componente integrador le envía el mensaje a MO, la cual
persistirá la información en su repositorio de datos.
El diagrama de la figura 4.F muestra una secuencia de llamados, la cual involucra a varios
componentes. Estos llamados se realizan utilizando como intermediario al SmartFox Server. El
uso de este intermediario para controlar todos los mensajes provenientes de los componentes
hace que el acople entre ellos sea mínimo. Ningún componente del sistema depende de los
demás para llevar a cabo una comunicación. Esta forma de comunicación permite que los
componentes puedan ser de diferente naturaleza y que cada uno esté completamente aislado
de la naturaleza del componente con el que se comunica.
4.2.3. Sprint Retrospective
Fig. 4.G. Diagrama de secuencia para la etapa Sprint Retrospective.
Luego de finalizado un sprint, el Scrum Master, por medio de VS, realiza la calificación
del desempeño de los recursos. VS envía la información ingresada por el Scrum Master hacia
SmartFox Server, quien entiende que esta información debe reenviarla hacia el componente
MO, invocando al servicio “Qualify Resource”. MO recibe esta solicitud y actualiza la
información del repositorio.
55
4.3.
Herramienta en acción
En esta sección se muestran imágenes de la solución final resultante de la integración de
herramientas previamente mencionadas.
Virtual Scrum es un ambiente 3D que consiste de una sala en la que múltiples usuarios
pueden interactuar con paneles ubicados en las paredes de la misma. Esta sala puede
apreciarse en la figura 4.J. Cada panel muestra información relativa al proyecto sobre el que se
está trabajando y, algunos de ellos, da la posibilidad al usuario de modificar ciertos datos.
Existe un panel que muestra el estado actual de las tareas de cada user story (figura 4.L.) del
product backlog (figura 4.K) y permite al usuario modificar dicho estado cuando, por ejemplo, se
ha finalizado con una tarea. Existen otros paneles entre los que se puede apreciar información
tal como un gráfico de burndown o listado de user stories.
Para poder realizar el armado y planificación de un sprint es necesaria la manipulación de
mucha información. Esta incluye el manejo del product backlog para seleccionar las tareas que
formarán parte del sprint backlog, elegir que recursos estarán disponibles para el sprint sobre el
que se realizará la planificación, etc. Por este motivo, se optó por el uso de ventanas en 2D que
brindan a los usuarios una mejor usabilidad del sistema.
Figura 4.J: Vista de la sala principal de Virtual Scrum.
56
Figura 4.K: Panel de Product Backlog.
Figura 4.L: Panel que muestra el estado actual de cada tarea.
Mediante una de las ventanas, mostrada en la figura 4.M, el usuario puede manipular
toda la información relevante al proyecto y/o sprint que desea planificar. Se brinda la posibilidad
de gestionar tareas, recursos, roles y sprints, así como las habilidades de cada recurso y las
habilidades requeridas en cada rol, lo que permitirá al algoritmo de planeamiento, determinar si
un recurso es apto o no para ejercer determinado rol requerido para la realización de una
determinada tarea. Esto último resulta una pieza clave en la planificación de un proyecto, ya
que el algoritmo siempre trata de asignar, a una tarea, el recurso libre más capacitado para la
resolución de la misma.
57
Figura 4.M: Ventana de gestión de proyectos.
En la figura 4.N. se puede apreciar la ventana por la cual el usuario puede armar el sprint
antes de planificarlo. Para brindar una mayor usabilidad se optó por mostrar, en una lista, todas
las user stories que forman parte del product backlog, y en otra, todas las que forman parte del
sprint backlog. De esta manera, el usuario con sólo presionar un botón puede remover una user
story del sprint backlog para que vuelva a formar parte del product backlog o viceversa.
Figura 4.N: Ventana de armado de sprint backlog para planificación del sprint.
La última ventana relevante de Virtual Scrum, se muestra en las figuras 4.O. Esta ventana
es la que muestra la información devuelta por el algoritmo de planeamiento luego de que el
usuario solicite la planificación de un determinado sprint. En la ventana mencionada se muestra
58
información tal como las user stories propias del sprint planeado con las tareas que involucra
cada una, así como, el/los recurso/s al cual el algoritmo encontró más apto para resolver el
sprint de forma eficiente. Dado que cada recurso puede ejercer diferentes roles de acuerdo a
sus habilidades, en la ventana se muestra también que rol debería ejercer el recurso asignado
para resolver las tareas eficientemente. Se muestra además, la duración estimada de la tarea
(indicada por el Scrum Master) así como la duración que el algoritmo calcula que tardará el
recurso asignado, en resolver la tarea en cuestión, basándose en las habilidades requeridas
para la resolución y en las habilidades propias del recurso. Además se brinda al usuario la
posibilidad de posponer user stories para un próximo sprint y entonces replanear el sprint
nuevamente.
Figura 4.O: Ventanas de resultado del sprint planeado.
59
4.4. Conclusión
Los diagramas de secuencia ilustran un conjunto de aplicaciones heterogéneas que se
comunican por medio de un canal común. Esta comunicación es totalmente transparente ya
que ningún componente debe conocer detalles de implementación del otro. El componente
integrador se comporta como un canal de comunicación común para todas las partes del
sistema.
La combinación del estilo arquitectónico elegido más la utilización de SmartFox Server como
componente integrador, permite que nuevos componentes sean fácilmente integrados a la
arquitectura de IVS, sin afectar a las aplicaciones presentes en la arquitectura. Además, los
componentes de la arquitectura son independientes entre sí: cualquier cambio en alguno de
ellos, no afectará al resto, mientras su componente integrador respete las interfaces definidas
por SmartFox.
60
Capítulo 5
Resultados Experimentales
Al principio de este trabajo, se mencionó que la gestión de un proyecto puede ser llevada a
cabo siguiendo diferentes metodologías de trabajo. En este capítulo se explican los
procedimientos utilizados para probar experimentalmente el desempeño que posee la
combinación de metodologías ágiles junto con las técnicas de Memoria Organizacional y de
Planning sobre una herramienta de administración de proyectos real, y se muestran los
beneficios obtenidos al aplicar dicha combinación por sobre una gestión de proyectos siguiendo
la metodología clásica tipo “cascada”. Se presenta, además, el marco de trabajo propuesto
para simular el ambiente de trabajo y cuáles son las suposiciones tenidas en cuenta para
generar un entorno controlado de experimentación. Como último experimento, se invierten los
criterios de calificación utilizados por el algoritmo. Con esta prueba, se explica el concepto de
capacidad de recuperación, que muestra la adaptación del algoritmo frente a un cambio en el
criterio de calificación.
A lo largo del presente capítulo se podrán observar los resultados obtenidos luego de
diversas ejecuciones del algoritmo de planeamiento utilizando las diferentes configuraciones de
proyectos, pero manteniendo siempre, para cada uno de ellos, los mismos datos de entrada, lo
que permitirá realizar comparaciones claras entre ellos.
Al final de este capítulo, se pondrá a prueba la capacidad de aprendizaje de la herramienta.
Particularmente, se evidenciará que en un ambiente ágil Scrum, la curva de aprendizaje es más
rápida con respecto a la metodología cascada. Se compararán los resultados obtenidos de
estos dos enfoques, utilizando gráficas que permitan visualizar el comportamiento de la
herramienta con respecto a los parámetros de entrada utilizados, lo que permitirá, además,
comprobar experimentalmente la validez de los resultados obtenidos.
61
5.1. Criterio
conocimiento.
de
calificación
del
algoritmo
y
generación
del
Como se mencionó en el capítulo 3, la herramienta va adquiriendo los conocimientos sobre
los recursos a medida que ocurren las diversas ejecuciones de cada sprint. En este contexto,
entre los conocimientos más importantes que puede adquirir la herramienta, se debe mencionar
el desempeño que tuvo un recurso al realizar una determinada tarea. En un ambiente de
trabajo real, este desempeño será evaluado por el encargado de la gestión del proyecto. En
nuestro caso particular, la evaluación del desempeño de un recurso será generada
automáticamente por la herramienta teniendo en cuenta ciertos aspectos como el nivel de las
habilidades del recurso asignado y el rol requerido para la realización de una tarea. Esta
simulación permitirá evaluar el desempeño de la herramienta desde el punto de vista de la
capacidad de aprendizaje y la capacidad de recuperación ante los posibles cambios en el
desempeño de los recursos.
Entre los diferentes escenarios que puede encontrarse el gestor de un proyecto, puede
ocurrir que haya recursos muy capacitados que no cumplan satisfactoriamente con el
requerimiento al cual fue asignado, por lo que la herramienta debe aprender a no volver a
cometer los mismos errores. Como escenario opuesto, puede ocurrir también que un recurso
con poca experiencia resuelva una tarea apropiadamente causando que la herramienta tenga
que aprender de situaciones satisfactorias. La meta que se tiene al plantear estos escenarios
opuestos, es comprobar que la herramienta está preparada para soportar cambios repentinos
en el desempeño de los recursos y aprender de cada una de las posibles situaciones.
En un ambiente real de ejecución de la herramienta, el Scrum Master calificará a los
recursos de acuerdo a diversos factores. Dichos factores, pueden ser el tiempo que le llevo al
recurso finalizar cierta tarea, o la calidad de las soluciones que utilizo. Al mismo tiempo,
diferentes Scrum Masters pueden basarse en diferentes características para calificar a un
recurso. Para simular el proceso de calificación, se estableció que los recursos que,
lógicamente, serían los óptimos para cumplir con una tarea, serán calificados negativamente,
mientras que los recursos asignados más alejados del requerimiento de la tarea serán
calificados positivamente. Por ejemplo, si una tarea solicita un recurso con un alto nivel de
62
habilidad y en la misma se le asigna un recurso junior, este último obtendrá una buena
calificación.
La tabla 5.1 muestra el puntaje de calificación de un recurso con cierto nivel de seniority
cuando es asignado a una tarea con requerimientos de un determinado nivel.
Tarea/Recursos Senior Semi-Senior Junior
Alta
1
4
10
Media
4
1
10
10
4
1
Baja
Tabla 5.1: Criterio de evaluación utilizado para la generación del conocimiento.
La semántica de la tabla se explica a continuación:

Si una tarea tiene como requerimiento que sea realizada por un programador de
altos conocimientos, y se le asigna un recurso Senior, el puntaje será de 1. Este es
el caso del casillero [Tarea=ALTA, Recurso=SENIOR].

La semántica explicada anteriormente, es análoga para el resto de los casilleros. El
mínimo puntaje es 1, y el máximo es 10.
La intención del criterio de calificación, es que el algoritmo aprenda que es mejor asignar
recursos de bajos conocimientos a tareas complejas, y viceversa. Con las sucesivas
ejecuciones, el algoritmo ira “aprendiendo” que, por ejemplo, un recurso Junior es mejor que un
recurso Senior frente a tareas de alta complejidad. Lo opuesto sucederá si la tarea es de baja
complejidad, y el Senior será ponderado por sobre el Junior.
Entre las suposiciones utilizadas para la definición del criterio de evaluación se plantea que
una de las razones por una baja calificación es que el recurso no cumplió con el requerimiento
en el tiempo que fue estimado, por ello se aumenta o disminuye el tiempo real en que la tarea
fue realizada según la calificación que recibieron los recursos en la misma.
Finalmente, para evaluar la calidad de un conjunto de asignaciones para un proyecto/sprint,
se calcularán diferentes métricas del mismo. Se obtendrá el promedio de las calificaciones de
63
los recursos asignados y el tiempo total del proyecto/sprint, lo que permitirá observar el
comportamiento del algoritmo a medida que se va incrementando el contenido de la Memoria
Organizacional.
5.2. Casos de estudio
A fin de medir el beneficio que tendría la utilización de una metodología ágil dentro de una
organización, se define un caso de estudio que compara los resultados de aplicar el algoritmo
de planeamiento a dos proyectos idénticos en cuanto a recursos, tareas y requerimientos, pero
planificando uno de ellos bajo el modelo tradicional de cascada y el otro mediante la
metodología ágil “Scrum”.
Las métricas utilizadas para evaluar los resultados obtenidos es el promedio de las
calificaciones de las tareas y duración total del proyecto. También se analizan resultados
parciales en el caso del análisis de un proyecto Scrum, mostrando los tiempos y puntajes por
sprint. Las métricas para cada tipo de configuración de proyecto, son comparadas mediante el
uso de gráficos y tablas, con el objetivo de mostrar la evolución del aprendizaje del algoritmo.
5.2.1. Caso de estudio 1: Metodología “cascada” vs. Metodología ágil “Scrum”
En esta sección, se compararán las ejecuciones del algoritmo sobre una configuración tipo
“cascada”, con las ejecuciones utilizando la configuración “Scrum”.
La principal diferencia entre estos 2 tipos de configuraciones, es la forma en que Scrum
divide al proyecto en Sprints. Como se explicó en el capítulo 1, la metodología Scrum se basa
en iteraciones denominadas “sprints”, y en cada una de ellas se llevan a cabo un cierto número
de tareas. A diferencia de Scrum, una metodología “cascada”, se caracteriza por una ejecución
ininterrumpida del plan de un proyecto, realizando tarea tras tarea. Los datos obtenidos de este
caso de estudio, demuestran que el algoritmo realiza una mejor planificación en un ambiente
Scrum. Esto se debe a que cada ejecución del algoritmo, contemplara el conocimiento
generado en las ejecuciones anteriores. En cambio, en “cascada”, se planifica el proyecto en
una sola ejecución del algoritmo.
64
5.2.1.A. Configuración del experimento
Para este caso de estudio se utilizaron dos proyectos idénticos, pero se planificaron de
diferentes maneras. En uno de ellos, al que mencionaremos de ahora en más como “proyecto
cascada”, se realizó la planificación de todas las tareas en un único sprint y en el otro proyecto
se realizó la planificación de las mismas tareas, pero divididas en tres sprints, cada uno de los
cuales contendrá algunas de las tareas planificadas en el primer proyecto “cascada”. A este
segundo proyecto lo denominaremos “proyecto ágil”.
La tabla 5.2 muestra las tareas involucradas en cada uno de los proyectos, junto con los
requerimientos de habilidades en cada una de ellas, así como también los recursos disponibles
para ser asignados para su resolución. Se incluye también el sprint al que fueron asignadas
para la ejecución del algoritmo utilizando la metodología ágil.
User Story
Tarea
Requerimientos
Soporte de persistencia
Diseñar estructura de base de datos
Implementar altas bajas y modificaciones
Desarrollo de login
Diseñar interfaz de login
Implementar funcionalidad para inicio de
sesión
Visualización de panel de planning poker en entorno 3D
Crear imágenes e interfaz
Implementar script para eventos del
mouse
Implementar lógica de panel
Implementar soporte para multijugador
Implementación de avatar
Implementar animaciones del avatar
Agregar control de movimiento
Crear modelo 3D del avatar
Implementar sala de juego 3D
Crear modelo 3D de la sala
Implementar soporte multijugador
#
Sprint
1
Programador senior
Programador semi-senior
1
Diseñador gráfico junior
Programador junior
2
Diseñador gráfico junior
Programador junior
Programador semi-senior
Programador senior
2
Programador semi-senior,
Diseñador gráfico senior
Programador semi-senior,
Diseñador gráfico semi-senior
Diseñador gráfico senior
3
Diseñador gráfico junior
Programador senior
Tabla 5.2: Tareas involucradas en cada uno de los proyectos.
En la tabla 5.3 se pueden apreciar los recursos disponibles y los roles que cada uno de ellos
puede desempeñar.
65
Recurso
Rodrigo
Roberto
Ana
Martin
Aníbal
Julio
Roles que puede ejercer
Programador junior, Programador semi-senior, Programador senior
Programador junior, Programador semi-senior
Programador junior
Diseñador gráfico junior, Diseñador gráfico semi-senior, Diseñador gráfico senior
Diseñador gráfico junior, Diseñador gráfico semi-senior
Diseñador gráfico junior
Tabla 5.3: Recursos disponibles para su asignación a tareas, con los roles que pueden ejercer.
5.2.1.B. RESULTADOS Y ANALISIS DEL CASO DE ESTUDIO
Las siguientes evaluaciones corresponden a las sucesivas ejecuciones del algoritmo de
planning, comenzando en un estado en el cual la memoria organizacional se encuentra sin
ningún tipo de conocimiento. El contenido de la misma se irá incrementando a medida que se
ejecuten nuevos sprints, como así también lo hará la calidad de cada una de las asignaciones.
Ejecución Proyecto cascada
En la tabla 5.4 se muestra el resultado de la primera ejecución del algoritmo de planning,
efectuada sobre el “proyecto cascada”. Este caso no cuenta con conocimiento previo en la
memoria organizacional, como así tampoco ningún tipo de preferencia entre recursos, por lo
tanto se asignó el primer recurso disponible que el algoritmo de planning encontró apto para
satisfacer el requerimiento de la tarea.
Tarea
Requerimiento
Recurso
Rol ejercido
Puntaje
Agregar control de
movimiento
Diseñador gráfico
semi senior
Rodrigo
Senior
4
Agregar control de
movimiento
Programador
semi senior
Roberto
Semi-senior
1
Crear imágenes e interfaz
Diseñador gráfico
junior
Martin
Senior
Crear modelo 3D de la
sala
Diseñador gráfico
junior
Anibal
Semi-senior
4
Crear modelo 3D del
avatar
Diseñador gráfico
senior
Martin
Senior
1
Diseñar estructura de
base de datos
Programador
senior
Rodrigo
Senior
1
Diseñar interfaz de login
Diseñador gráfico
junior
Martin
Senior
10
66
10
Implementar animaciones
del avatar
Diseñador gráfico
senior
Martin
Senior
1
Implementar animaciones
del avatar
Programador
semi senior
Rodrigo
Senior
4
Implementar altas bajas y
modificaciones (ABM)
Programador
semi senior
Rodrigo
Senior
4
Implementar funcionalidad
para inicio de sesión
Programador
junior
Rodrigo
Senior
10
Implementar lógica de
panel
Programador
semi senior
Rodrigo
Senior
4
Implementar script para
eventos del mouse
Programador
junior
Rodrigo
Senior
10
Implementar soporte
multijugador
Programador
senior
Rodrigo
Senior
1
Implementar soporte para
multijugador
Programador
senior
Roberto
Semi-senior
4
Tabla 5.4: Proyecto cascada. Asignaciones realizadas por el algoritmo junto con las calificaciones
obtenidas por cada uno de los recursos.
Los puntajes asignados en la tabla 5.4, provienen de la figura 5.1. Por ejemplo, la primera
fila de la tabla, corresponde a una tarea que requiere un recurso semi-senior. El
algoritmo asignó un recurso desempeñando el rol de Senior. De acuerdo a la tabla 5.1, el
puntaje es 4.
Evaluación total del proyecto: ∑ SCORE / cantidad de tareas planificadas = 4.6
Tiempo total en horas hombre: 202 horas.
Ejecución Proyecto ágil
En la figura 5.5 se muestra el resultado de la ejecución del algoritmo de planning, efectuada
sobre el “proyecto ágil”. Este caso tampoco cuenta con conocimiento previo en la memoria
organizacional, como así tampoco ningún tipo de preferencia entre recursos, por lo tanto, se
asignó el primer recurso disponible que el algoritmo de planning encontró apto para satisfacer
el requerimiento de la tarea. Como se mencionó anteriormente, este proyecto cuenta con las
mismas tareas que el de la ejecución anterior, pero divididas en tres sprints, por lo que se
presentan las asignaciones divididas en ellos.
El resultado que se espera obtener en esta ejecución, es que las asignaciones del primer
sprint sean idénticas a las realizadas por el algoritmo en la ejecución anterior, y que las
67
asignaciones de sprints posteriores sean mejor calificadas dado que se conserva el
conocimiento generado en cada una de las planificaciones de los sprints
Tarea
Requerimiento
Recurso
Rol ejercido
Score
Sprint
Diseñar estructura de base de
datos
Programador
senior
Rodrigo
Programador
senior
1
1
Diseñar interfaz de login
Diseñador
gráfico junior
Martin
Diseñador
Gráfico
Senior
10
1
Implementar altas bajas y
modificaciones (ABM)
Programador
semi senior
Rodrigo
Programador
senior
4
1
Implementar funcionalidad para
inicio de sesión
Programador
junior
Rodrigo
Programador
senior
10
1
Agregar control de movimiento
Programador
semi senior
Rodrigo
Programador
Senior
4
2
Agregar control de movimiento
Diseñador
gráfico semi
senior
Martin
Diseniador
Gráfico
Senior
4
2
Crear imágenes e interfaz
Diseñador
gráfico junior
Martin
Diseniador
Gráfico
Senior
10
2
Crear modelo 3D del avatar
Diseñador
gráfico senior
Aníbal
Diseniador
Gráfico Semi
Senior
4
2
Implementar animaciones del
avatar
Programador
semi senior
Rodrigo
Programador
Senior
4
2
Implementar animaciones del
avatar
Diseñador
gráfico senior
Martin
Diseniador
Gráfico
Senior
1
2
Implementar lógica de panel
Programador
semi senior
Rodrigo
Programador
Senior
4
2
Implementar script para
eventos del mouse
Programador
junior
Rodrigo
Programador
Senior
10
2
Implementar soporte para
multijugador
Programador
senior
Roberto
Programador
Semi Senior
4
2
Crear modelo 3D de la sala
Diseñador
gráfico junior
Martin
Diseniador
Gráfico
Senior
10
3
Implementar soporte
multijugador
Programador
senior
Roberto
Programador
Semi Senior
4
3
Tabla 5.5: Proyecto ágil. Asignaciones realizadas por el algoritmo junto con las calificaciones obtenidas
por cada uno de los recursos.
68
Los puntajes asignados en la tabla 5.5, provienen de la figura 5.1. Por ejemplo, la
primera fila de la tabla, corresponde a una tarea que requiere un recurso senior. El
algoritmo asignó un recurso desempeñando el rol de Senior. De acuerdo a la tabla 5.1, el
puntaje es 1.
Evaluación total del proyecto: ∑ SCORE / cantidad de tareas planificadas = 5.6
Tiempo total en horas hombre: 188 horas.
Comparación de las ejecuciones
Como se puede apreciar en base a los resultados obtenidos, la planificación realizada por el
algoritmo mejoró notablemente, tanto en score promedio como en duración de las tareas a
realizar, cuando se planificó el proyecto ágil. Esto se debe a que, entre cada ejecución de un
sprint, se tiene en cuenta la información generada en cada uno de los sprints planificados
previamente, la cual es almacenada en la memoria organizacional.
Analizando las asignaciones efectuadas por el algoritmo en la ejecución del sprint número
uno del proyecto ágil, se puede apreciar que son idénticas a las generadas en el proyecto
cascada. Esto se debe a que al inicio de la ejecución del proyecto ágil no se cuenta con
información previa almacenada en la memoria organizacional, como se
mencionó
anteriormente.
Al realizar la planificación del sprint número dos del proyecto ágil, se puede apreciar que
dos tareas fueron asignadas a diferentes recursos respecto de la ejecución del proyecto
cascada, lo que generó un incremento en el score obtenido, así como también en el tiempo que
llevó realizar las mismas.
Luego se realizó la planificación del sprint número tres en la que el algoritmo, analizando la
información almacenada en la memoria organizacional, comprendió que se podía realizar
mejores asignaciones para dos de las tareas involucradas en el sprint. Estas asignaciones, al
igual que ocurrió con el sprint anterior, permitió mejorar el score promedio del mismo y el
tiempo de realización de las tareas.
A continuación, se presentan las tareas en las que se obtuvo una mejor calificación en la
ejecución del proyecto ágil, respecto del proyecto cascada.
69
TAREA
Agregar control de movimiento
REQUERIMIENTO
Programador semi senior
Recurso asignado proyecto cascada:
Score obtenido:
Roberto (Programador semi-senior)
1
Recurso asignado proyecto ágil:
Score obtenido:
Rodrigo
4
(Programador senior)
En cuanto al tiempo de realización de la tarea, se obtienen los siguientes valores:
Tiempo realización en horas hombre (proyecto cascada) = 19 hs.
Tiempo realización en horas hombre (proyecto ágil) = 15 hs.
En este caso se ve una mejora de 4hs en la metodología Ágil con respecto a Cascada. En el
caso Cascada, al no contar con información histórica, el algoritmo asigno el recurso que
encajaba perfectamente. Luego, en la ejecución Scrum, el algoritmo ya contaba con el puntaje
de la asignación Cascada, e intento mejorarla.
TAREA
Crear modelo 3D del avatar
REQUERIMIENTO
Diseñador gráfico senior
Recurso asignado proyecto cascada:
Score obtenido:
Julio (Diseñador gráfico senior)
1
Recurso asignado proyecto ágil:
Score obtenido:
Martin (Diseñador gráfico semi-senior)
4
Tiempo realización en horas hombre (proyecto cascada): 24 hs.
Tiempo realización en horas hombre (proyecto ágil):
22 hs.
En este caso, la mejora en cuanto al puntaje es igual que el caso anterior. Sin embargo, la
mejora del tiempo no es tan notoria. Esto se debe a que se asignó un recurso Semi Senior, y
en el caso anterior, un recurso Senior.
TAREA
REQUERIMIENTO
Crear modelo 3D de la sala
Diseñador gráfico junior
Recurso asignado proyecto cascada:
Score obtenido:
Martin (Diseñador gráfico semi-senior)
4
Recurso asignado proyecto ágil:
Score obtenido:
Julio (Diseñador gráfico senior)
10
70
Tiempo realización en horas hombre (proyecto cascada) = 12 hs.
Tiempo realización en horas hombre (proyecto ágil) = 6 hs.
Una vez más, se puede ver una mejoría notable en los tiempos. Esto se debe a que la tarea
requería un recurso de pocos conocimientos, y en la ejecución para Scrum se asignó un
recurso Senior.
TAREA
Implementar soporte para multijugador
REQUERIMIENTO
Programador senior
Recurso asignado proyecto cascada:
Score obtenido:
Rodrigo (Programador senior)
1
Recurso asignado proyecto ágil:
Score obtenido:
Roberto (Programador semi-senior)
4
Tiempo realización en horas hombre (proyecto cascada): 24 hs.
Tiempo realización en horas hombre (proyecto ágil):
22 hs.
La ventaja del enfoque Scrum por sobre el Cascada, es la granularidad temporal. En Scrum,
la ejecución del proyecto esta divididas en unidades temporales denominadas sprints. Esto
permite contar con información en la MO al momento de comenzar cada sprint. En el caso del
sprint 1, como se mencionó anteriormente, no se cuenta con información en la MO. Es por ello
que las asignaciones del enfoque Cascada coinciden para las tareas del Sprint 1 en el enfoque
Scrum.
5.2.2. Caso de estudio 2: Capacidad de aprendizaje
Cuando se realiza la planificación de un proyecto, la herramienta guarda información sobre
las tareas involucradas. Dicha información será utilizada en las posteriores ejecuciones, lo que
permitirá lograr mejores asignaciones y un consecuente incremento en el promedio de
calificaciones del proyecto.
Para comprobar que la herramienta cumple con esta característica, se creó un caso de
estudio que involucra cinco proyectos, con exactamente las mismas tareas y requerimientos. El
71
algoritmo fue ejecutado una vez para cada uno de ellos. Se utilizaron las mismas tareas,
requerimientos y recursos del caso de estudio 1, del proyecto Cascada. La MO no contaba con
información previamente almacenada, por lo que la primera vez que se ejecutó el algoritmo, no
se tenía información sobre el desempeño de los recursos, situación que fue cambiando con la
ejecución de los diferentes proyectos. Por lo tanto, los puntajes promedio por tarea y score final
del Proyecto 1, coinciden con los puntajes del caso 1, del proyecto cascada.
En el caso de estudio 1, cuando se analizó el enfoque Scrum, se demostró que el algoritmo
aprendía sobre los recursos. Dicho aprendizaje, iba mejorando entre las sucesivas ejecuciones,
sprint a sprint. Para este caso de prueba, para que el experimento no se vea influenciado por
conocimiento intermedio, se decidió usar un enfoque Cascada, con el fin de demostrar que el
algoritmo aprende en un ambiente de múltiples proyectos.
En la tabla 5.6 se pueden observar los diferentes proyectos, con sus respectivas tareas y el
puntaje promedio obtenido por los recursos que fueron asignados a cada una de ellas.
Score por Tarea
Proyecto 1
Proyecto 2
Agregar control de
movimiento
2.5
4
7
7
7
Crear imágenes e
interfaz
10
10
10
10
10
Crear modelo 3D de la
sala
4
10
10
10
10
Crear modelo 3D del
avatar
1
4
4
4
4
Diseñar estructura de
base de datos
1
1
1
4
1
Diseñar interfaz de login
10
10
10
10
10
Implementar
animaciones del avatar
2.5
2.5
4
7
7
72
Proyecto 3
Proyecto 4
Proyecto 5
Implementar altas bajas
y modificaciones (ABM)
4
4
4
4
10
Implementar
funcionalidad para inicio
de session
10
10
10
10
10
4
1
1
10
10
10
10
10
10
10
Implementar soporte
multijugador
1
4
4
4
4
Implementar soporte
para multijugador
4
4
4
4
4
4.92
5.73
6.07
7.23
7.46
Implementar lógica de
panel
Implementar script para
eventos del mouse
Score promedio del
Sprint
Tabla 5.6: Puntaje obtenido en cada asignación de las tareas involucradas en los diferentes proyectos.
Los puntajes de la tabla 5.6 se calculan en base a la tabla 5.1. En la tabla 5.1, solo se
pueden tener valores 1, 4 o 10. Sin embargo, en la tabla se pueden ver valores decimales,
por ejemplo, para la tarea “Agregar control de movimiento”. Esto se debe a que, para
este análisis, se usa el promedio por tarea. Dicha tarea requería 2 recursos, y el
algoritmo asignó a cada uno 7 y 4 puntos respectivamente. El promedio entre ambas da
5.5 pts.
La tabla 5.6 en la última fila muestra para cada sprint, el Score promedio, que se calcula en
función de los puntajes de cada tarea. El valor del score promedio va en aumento si
comparamos los sprints desde el primero hasta el último. Análogamente, también se ve un
incremento en el puntaje promedio para cada tarea. Por ejemplo, si tomamos como referencia
la tarea “Implementar soporte para multijugador”, en el Sprint 1 tuvo un puntaje de 4, pero en el
Sprint 4 ya alcanzó su máximo.
El incremento del score de las tareas y del score promedio a lo largo de los sprints,
evidencia que el algoritmo va adquiriendo conocimiento sobre los recursos. El conocimiento es
usado por el algoritmo para tratar de mejorar las asignaciones de las tareas, y minimizar los
tiempos del sprint. Al mismo tiempo, el algoritmo se retroalimenta con el conocimiento
generado ejecución a ejecución.
73
Como nota complementaria del análisis, si se observa la tabla 5.6 se puede apreciar que la
tarea “implementar lógica de panel” tuvo una puntuación menor en la segunda y tercera
ejecución del proyecto respecto de la primera, para luego llegar a la puntuación máxima
alcanzada en las últimas dos planificaciones del proyecto. Este comportamiento contrario al
análisis que se viene desarrollando tiene una explicación racional. Dado que el algoritmo
intenta encontrar siempre la mejor planificación posible para cada proyecto en base al
contenido de la memoria organizacional, puede suceder que para mejorar la puntuación
general del proyecto mejorando algunas asignaciones, sea necesario que otras tareas, que
previamente tenían mejores puntuaciones, sean asignadas a recursos menormente calificados.
En otras palabras, se asigna de una peor manera un recurso, para que el asignado
anteriormente esté disponible para realizar otras tareas que implicarán un incremento mayor en
el puntaje promedio del proyecto.
La figura 5.7 muestra cómo se va incrementando el puntaje promedio obtenido por cada uno
de estos proyectos idénticos, hasta lograr obtener una estabilidad que indica que se ha
alcanzado un nivel óptimo en cuanto a las asignaciones efectuadas por el algoritmo.
Figura 5.7: Puntaje promedio obtenido por cada proyecto.
74
Se realiza un análisis similar teniendo en cuenta los tiempos necesarios para llevar a cabo
cada tarea, mostrando el tiempo total del proyecto para cada ejecución del algoritmo. Como era
de esperarse, hay una relación inversamente proporcional entre el puntaje obtenido por cada
una de las tareas y el tiempo total del proyecto, a mayor puntuación obtenida, menor será el
tiempo de ejecución de la tarea.
Las siguientes dos figuras, 5.8 y 5.9, muestran los tiempos para cada Sprint, y la curva de
duración que muestra esta relación inversamente proporcional.
Tiempo por Tarea (horas)
Proyecto 1
Proyecto 2
Proyecto 3
Proyecto 4
Proyecto 5
16.15
20
20
16.15
16.15
Crear imágenes e interfaz
6.4
6.4
6.4
6.4
6.4
Crear modelo 3D de la sala
6.4
6.4
6.4
6.4
6.4
Crear modelo 3D del avatar
16
16
16
16
16
Diseñar estructura de base
de datos
16
16
16
16
16
Diseñar interfaz de login
6.4
6.4
6.4
6.4
6.4
Implementar animaciones del
avatar
19
16
16
16
16
Implementar altas bajas y
modificaciones
16
16
16
16
16
Implementar funcionalidad
para inicio de sesión
6.4
6.4
6.4
6.4
6.4
Implementar lógica de panel
16
16
16
16
16
Implementar script para
eventos del mouse
6.4
6.4
6.4
6.4
6.4
Implementar soporte
multijugador
24
22
22
16
16
Implementar soporte para
multijugador
22
22
16
16
16
Tiempo Total del proyecto
177.15
176
170
160.15
160.15
Agregar control de
movimiento
Figura 5.8: Tiempo de ejecución de cada tarea y tiempo total del proyecto.
75
Figura 5.9: Tiempo promedio de ejecución de cada proyecto.
Comparando los gráficos presentados en las figuras 5.7 y 5.9, puede apreciarse lo
mencionado anteriormente, la relación inversamente proporcional entre el tiempo de ejecución
de cada proyecto y el puntaje promedio obtenido en cada uno de ellos.
5.2.3. Caso de estudio 3: Capacidad de recuperación
En un ambiente de desarrollo de software, sin importar la metodología que se aplique, las
situaciones y condiciones cambian constantemente. La calidad de ejecución de los proyectos,
puede verse afectada por múltiples factores, así sean internos o externos. Por ejemplo, las
tareas pueden verse afectadas por el bajo desempeño de cierto número de desarrolladores, los
clientes pueden cambiar los requisitos a último momento, o algún servicio del cual se
dependencia tiene errores que impiden el desarrollo de nuestro proyecto.
76
Frente a estos factores, el algoritmo irá almacenando la información que le sea provista, y
en función de ella deberá realizar las futuras asignaciones. Particularmente, estamos
interesados en el caso de que un cierto recurso, que en sus últimas asignaciones había tenido
un buen puntaje, empieza a tener performances negativas o viceversa, un recurso que empezó
teniendo actuaciones pobres, empezó a esforzarse y mejorar. Sea cual sea el caso, el
algoritmo tiene que ser capaz de adaptar sus decisiones para dejar de elegir el desarrollador
que empezó a fallar en sus actividades, y elegir al que comenzó a mejorar.
Esta capacidad del algoritmo de adaptarse a los cambios de los recursos, la denominamos
capacidad de recuperación. Representa la capacidad del algoritmo de manipular la memoria
organizacional, de tal forma de adaptarse a los cambios descriptos anteriormente, y aun así
mantener las asignaciones lo más optimas posibles.
En esta sección, se desarrollará un experimento donde se simula una situación de cambio
en las aptitudes de los recursos. Para ello, se invertirán los criterios de calificación, asignando
de forma opuesta. Los resultados serán mostrados de la misma manera que en los capítulos
anteriores.
5.2.3.1 Configuración del proyecto
Para la implementación del caso de estudio se toma como punto de partida el estado del
caso de estudio 2. En ese caso, se planificó 5 veces el mismo proyecto, evidenciando una
mejora entre cada ejecución. Para comenzar este caso de estudio, la MO conseguida en el
caso 2 será reutilizada. El criterio de calificación del caso 2 será alterado, para calificar de
manera inversa, simulando un cambio de las performances de los recursos. Por lo tanto, se
inicia este caso de prueba con una MO que ya contiene información sobre los recursos.
El resultado que se espera obtener con este caso de estudio es que, en el primer proyecto
que utilice este nuevo criterio de calificación, el puntaje promedio obtenido por el mismo baje
notablemente respecto del último proyecto planificado con el criterio de calificación utilizado en
el caso 2.
77
El nuevo criterio de calificación, a diferencia del usado anteriormente, califica las diferentes
asignaciones de manera opuesta. Por este motivo los recursos que obtenían un 10 en sus
calificaciones para un determinado requerimiento ahora serán calificados con un 1. Por el
contrario, los recursos que anteriormente mostraban un desempeño de 1 y 4 presentaran
calificaciones de 10 y 8 respectivamente.
Tarea/Recurso Senior Semi-Senior Junior
Alto
10
8
1
Media
8
10
1
Baja
1
8
10
Tabla 5.9: Nuevo criterio de evaluación para demostrar la capacidad de recuperación
La tabla 5.9 presenta un criterio de calificación opuesto al de la tabla 5.1. La semántica de la
tabla es la misma.
A continuación se presenta la tabla 5.10, mostrando las sucesivas ejecuciones del algoritmo
a lo largo de todos los proyectos con el nuevo criterio de calificación. La última fila de la tabla
brinda la información más pertinente para este experimento, que es el puntaje promedio por
sprint, el cual aumenta ejecución tras ejecución.
Proyectos
Score por Tarea
6
7
8
9
10
11
Agregar control
de movimiento
4.5
8
8
8
8
8
8
8
8
8
8
8
Crear imágenes
e interfaz
1
1
1
1
1
1
1
1
1
1
1
1
Crear modelo
3D de la sala
1
1
1
1
1
1
1
1
1
1
1
1
Crear modelo
3D del avatar
8
8
8
8
8
8
8
8
8
8
8
8
78
12
13
14
15
16
17
Diseñar
estructura de
base de datos
10
8
10
10
10
10
10
10
8
10
10
10
Diseñar interfaz
de login
1
1
1
1
1
1
1
1
1
1
1
1
Implementar
animaciones del
avatar
4.5
4.5
8
8
8
8
8
10
8
10
10
10
1
8
8
8
8
8
8
10
10
10
10
10
1
1
1
1
1
1
1
1
1
1
1
1
Implementar
lógica de panel
1
1
8
8
8
8
8
8
8
8
10
10
Implementar
script para
eventos del
mouse
1
1
1
1
1
1
1
1
8
8
8
10
Implementar
soporte
multijugador
8
8
8
8
8
8
8
8
8
8
8
10
Implementar
soporte para
multijugador
8
8
8
8
8
8
8
8
8
8
8
8
3.84
4.5
5.46
5.46
5.46
5.46
5.46
5.76
6
6.31
6.46
6.76
Implementar
altas bajas y
modificaciones
(ABM)
Implementar
funcionalidad
para inicio de
sesión
Score Promedio
del Sprint
Figura 5.10: Nuevo criterio de evaluación para demostrar la capacidad de recuperación
Como era de esperarse, y como se ha visto a lo largo de todo este capítulo, el puntaje
promedio de cada tarea y el score promedio de cada proyecto va en aumento con las sucesivas
ejecuciones del algoritmo
En la planificación del proyecto número seis, ocurre un abrupto descenso en el promedio de
las calificaciones. Esto es debido a que el conocimiento en la memoria organizacional es
obsoleto, ya que no representa la realidad de la organización, sino lo contrario.
A partir de la planificación del proyecto número siete, se puede ver como la herramienta
empieza a realizar nuevamente el trabajo de almacenar conocimiento en la MO y a utilizar el
mismo para aumentar la calidad de los resultados. Por otra parte, el mecanismo de
79
envejecimiento presente en la MO posibilita "olvidar" paulatinamente parte el conocimiento de
mayor antigüedad, permitiendo conservar la experiencia más reciente y representativa de la
realidad. En la Figura 5.11 se puede contemplar el desempeño del algoritmo a través de los
distintos proyectos. La línea vertical que divide el gráfico entre los proyectos cinco y seis
representa el cambio en el criterio de calificación de las asignaciones.
Figura 5.11: Score promedio por proyecto. Capacidad de recuperación.
Finalmente, luego de sucesivos Sprints la herramienta muestra como es capaz de
recuperarse ante un cambio dramático en la calidad de los recursos, obteniendo resultados
finales muy similares a los capturados en la anterior evaluación.
Como conclusión, luego de las sucesivas planificaciones de los proyectos, la herramienta
muestra como es capaz de recuperarse ante un cambio drástico en la calidad de los recursos,
obteniendo resultados finales muy similares a los capturados en la anterior evaluación. Cabe
destacar, que la curva del score promedio a partir del sprint número 6, crece más lentamente
que entre los sprints 1 y 5. Esto se debe a que la memoria organizacional estaba totalmente
vacía entre los sprints 1 y 5, mientras que a partir del sprint 6, el algoritmo tuvo que asignar
recursos teniendo en cuenta el conocimiento previamente generado en las ejecuciones
anteriores.
80
Capítulo 6
Conclusiones
En este trabajo se desarrolló una herramienta con soporte inteligente que permite una
asistencia a miembros de un equipo en la planificación de actividades y asignación a
responsables en el contexto de un proceso iterativo e incremental. Como punto de partida, se
seleccionó Virtual Scrum, una herramienta de administración de proyectos desarrollada por los
estudiantes de la Facultad de Ciencias Exactas de la UNICEN. A la misma, se le incorporó
asistencia inteligente, implementando en ella los enfoques propuestos en (Villaverde, 2009) y
(Berdún, 2009).El primero enfoque aporta la capacidad de capturar, retener y recuperar la
información relevante a la organización en relación a la administración de proyectos a través de
una Memoria Organizacional (MO) basada en perfiles de usuario. El otro enfoque presenta un
algoritmo de planning para automatizar el planeamiento basándose en el conocimiento
organizacional adquirido por el enfoque anterior. El desarrollo y la integración de estos
enfoques permitieron enriquecer la herramienta con capacidades de asistencia personalizada
para el equipo de desarrollo teniendo como base de conocimiento para tal fin de la Memoria
organizacional. Con lo cual, la asistencia al usuario se determina de acuerdo al conocimiento
logrado a través de la captura y almacenamiento de las decisiones previas del equipo. De esta
forma, se aumenta el conocimiento organizacional y se reduce el impacto que pueda producir la
amnesia organizacional.
6.1. Contribuciones
A lo largo de esta tesis se presentó una herramienta que asiste al administrador de
proyectos en la construcción de un plan de trabajo utilizando el conocimiento adquirido por la
organización. Esta herramienta cuenta con un algoritmo de planificación adaptado para utilizar
el conocimiento de la organización y del equipo de desarrollo para realizar el armado del plan
de trabajo. A su vez cuenta con una memoria organizacional que permite la captura y
almacenamiento del conocimiento generado en la organización. En este sentido, el resultado
81
obtenido no sólo permite alcanzar los objetivos planteados, sino que lo hace acorde a lo
registrado en la memoria organizacional.
La contribución principal de este trabajo es una herramienta que permite armar el plan de
trabajo de un proyecto acorde al conocimiento de la organización y del administrador. Esta
herramienta hace uso de la memoria organizacional en beneficio del proyecto actual en
ejecución, disminuyendo de esta forma la dependencia del conocimiento del administrador.
Esto permite que, ante un nuevo proyecto, el administrador disponga de una herramienta que
le permite aprovechar cada una de las experiencias ganadas durante los proyectos anteriores,
sin la necesidad de que éste haya sido partícipe en los mismos.
Por otra parte, se contribuye en la disminución del efecto que produce la amnesia
organizacional mediante la incorporación de un mecanismo de captura de conocimiento que
actúa de manera no intrusiva recolectando la información generada a partir de la interacción
entre el usuario y la herramienta. A partir de la información adquirida se extrae el conocimiento
mediante la utilización de algoritmos de Machine Learning, que luego será utilizada a la hora de
planificar un proyecto.
Asimismo, otro aspecto también importante es la incorporación del modelo de integración, el
cual introduce gran flexibilidad a la hora de incorporar tanto el algoritmo de planificación, como
la memoria organizacional y Virtual Scrum en una sola herramienta. Este permitirá que trabajos
futuros tengan gran libertad a la hora de reemplazar o extender los principales componentes
que conforman la herramienta desarrollada.
Por otro lado, la integración del enfoque propuesto sobre una herramienta de administración
de proyectos desarrollada íntegramente por los alumnos de la Facultad de Ciencias Exactas,
contribuye en gran medida al crecimiento de un ambicioso proyecto ideado por los docentes de
la Facultad y que tiene como objetivo principal la capacitación de los alumnos en aspectos
claves del mercado laboral como son el trabajo en equipo y el desarrollo de grandes
herramientas que involucran cientos de personas trabajando durante varios años y
continuando, cada año, el trabajo desarrollado por los alumnos involucrados en años
anteriores. En lo personal, es gratificante aportar un granito de arena en este proyecto que
82
permitirá a los alumnos, en algunos años, realizar prácticas virtuales que los capacitarán en la
administración de proyectos y en el uso de metodologías ágiles.
6.2. Limitaciones y trabajos futuros
Actualmente la herramienta sólo captura conocimiento en base a las habilidades del
recurso, los requerimientos de las tareas y las calificaciones obtenidas, sin tener en cuenta
aspectos como el trabajo en equipo, es decir que el desempeño de un recurso para las mismas
tareas puede variar dependiendo el grupo trabajo en el que se encuentra. Por otro lado
tampoco se tienen en cuenta otros aspectos externos como por ejemplo el equipamiento con el
que cuenta cada recurso para realizar su trabajo. La incorporación de un mecanismo de
captura de conocimiento más complejo, que tenga en cuenta los aspectos mencionados
anteriormente, incrementaría aún más la potencia de la herramienta a la hora de planificar
automáticamente.
A la hora de planificar un proyecto la herramienta posee actualmente una restricción en
cuanto al tiempo, donde la duración de un Sprint no puede superar una cota establecida por el
administrador. Sin embargo no cuenta con una restricción que limite el presupuesto a utilizar, la
cual es una de las características principales a tener en cuenta a la hora de planificar un
proyecto. Incorporar restricciones que tengan en cuenta el costo del proyecto ayudará a ajustar
aún más el plan de proyecto a las limitaciones o necesidades de la organización.
En la actualidad la herramienta permite la captura de conocimiento a través de su
utilización. Por este motivo el conocimiento disponible para realizar la planificación automática
de los primeros Sprints resulta muy escaso, y en primera instancia nulo. Dado que una
organización que empieza a utilizar Intelligent Virtual Scrum podría tener conocimiento previo
sería muy conveniente brindar la posibilidad de importarlo manualmente, ya que este
conocimiento previo permitirá obtener resultados acorde a la realidad de la organización, y así
se evitarán los bajos resultados que se obtienen cuando no se cuenta con experiencias previas
almacenadas en la MO.
83
ANEXO I
Virtual Scrum es una plataforma 3D de código abierto, desarrollada por la UNICEN.
Actualmente se encuentra en desarrollo, y año a año sigue siendo modificada y mejorada. El
propósito de esta herramienta es facilitar la administración del ciclo de vida de un proyecto,
permitiendo a los usuarios que interactúen entre sí en un ambiente distribuido. Virtual Scrum,
como su nombre indica, se basa en la metodología ágil de desarrollo de software Scrum. Entre
sus funcionalidades principales, se pueden destacar, en lo que respecta a la metodología
Scrum, la administración de proyectos, tareas y recursos. Además, brinda a los usuarios
canales de comunicación, como un chat integrado, y conexión al mundo de las redes sociales.
La conectividad con el mundo de las redes sociales, y las grandes posibilidades que presenta
su característica de código abierto, hacen de Virtual Scrum una opción atractiva a la hora de
elegir una herramienta para metodologías Scrum.
En el capítulo de 3 de esta tesis, se identificaron tres partes esenciales: la necesidad de una
herramienta de gestión de proyectos, un repositorio de almacenamiento acorde y un
componente de planeamiento que pueda consumir este repositorio. Virtual Scrum aplicaba
perfectamente ante estas necesidades, ya que puede ser modificado a conveniencia para
poder interactuar con el repositorio y el algoritmo de planning. Esto permitió modificarlo de
forma tal de poner cumplir con las necesidades de cada una de las partes identificadas. Para
que Virtual Scrum logre esta interacción, fue necesario el agregado de las siguientes
funcionalidades:
- Interfaz para que desde Virtual Scrum, el usuario pueda seleccionar un conjunto de tareas
a planificar (etapa de definición del proyecto).
- Interfaz para que desde Virtual Scrum, el usuario pueda interactuar con el algoritmo de
planeamiento y sus resultados (etapa de planificación del sprint).
- Interfaz para que desde Virtual Scrum, el usuario pueda calificar a un recurso (etapa de
Sprint Retrospective).
El funcionamiento de cada una de estas etapas fue descrito en el capítulo 4.
84
Para que el usuario pueda realizar la planificación de un sprint, es necesario que cuente con
el listado de sprint disponibles para planear, y el listado de tareas existentes en el backlog. De
esta manera, el usuario podrá elegir que sprint desea planear, y que tareas quiere incluir.
Virtual Scrum logra esto desde el menú Planeamiento. La figura 7.A muestra la interfaz
mencionada.
Figura 7.A. Ventana de armado de sprint backlog y planificación.
Una vez que el algoritmo finaliza el planeamiento para un conjunto dado de tareas, el
usuario debe ser capaz de analizar los resultados arrojados por el algoritmo. Como se
mencionó en el capítulo 3, los resultados pueden satisfacerlo o no, lo que implica que el ciclo
de planeamiento puede tomar 2 cursos: aceptar el plan o realizar un nuevo planning. Si el
usuario elige esta última opción, se le debe proveer una interfaz para que pueda realizar
modificaciones acorde a sus necesidades. La figura 7.B ilustra esta funcionalidad.
Figura 7.B. Ventana de resultados de planificación.
85
Una vez que el usuario ha aceptado un plan para un sprint determinado, es necesario que
se califiquen los recursos que están involucrados en la ejecución de dicho sprint. En el capítulo
3, esta actividad fue denominada como Sprint Retrospective. Es un paso muy importante en el
ciclo de vida de un proyecto, ya que las calificaciones son esenciales para que el componente
de planning tome sus decisiones. El usuario puede calificar a los recursos desde el menú
Calificar. La figura 7.C ilustra esta funcionalidad.
Figura 7.C. Ventana de calificación de asignaciones.
86
Bibliografía
Ackerman y Hadverson. 2000. Ackerman, M. S. y Hadverson, C. A. Reexamining
Organiza-tional Memory. Communications of the ACM, 43(1):58–64. 2000.
Alavi y Leidner. 2001. Alavi, M. y Leidner, D. E. Review: Knowledge Management and
Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS
Quarterly, 25(1):107–136. 2001.
Alvesson. 1995. Alvesson, M. Management of knowledge-intensive companies. Walter de
Gruyter, de Gruyter. 1995.
Anand. 1998. Anand, V., Manz, C. C., y Glick, W. H. An Organizational Memory Approach to
Information Management. The Academy of Management Review, 23(4):796–809. 1998.
Armstrong. 1982. Armstrong, J. S. The Value of Formal Planning for Strategic Decisions:
Review of Empirical Research. Strategic Management Journal, 3(3):197–211. 1982.
Awad y Ghaziri. 2004. Awad, E. M. y Ghaziri, H. M. Knowledge Management. Prentice Hall,
Upper Saddle River, New Jersey 07458, 1st edition. 2004.
Azuan. 2002. Azuan, H. N. Organizational Amnesia: The Barrier to Organizational Learning.
En OKLC. 2002.
Baker. 1999. Baker. Administre sus proyectos. Ed. Pearson Educación. ISBN 970-17-02-808. 1999.
Bannon, y Kuutti. 1996. Bannon, L. J. y Kuutti, K. Shifting Perspectives on Organizational
Memory: From Storage to Active Remembering. En HICSS ’96: Proceedings of the 29th Hawaii
In-ternational Conference on System Sciences (HICSS) Volume 3: Col. 1996.
Basadur y Gelade. 2006. Basadur, M. y Gelade, G. A. The Role of Knowledge Management
in the Innovation Process. Creativity and Innovation Management, 15(1):45–62. 2006.
Beck et. al. 2001. Beck, Kent et. al. THE AGILE MANIFESTO. 2001.
87
Bellinger. 2002. Knowledge Management - Emerging Perspectives. Systems Thinking.
2002.
Berdún. 2009. Berdun, Luis. Un algoritmo de planning para el planeamiento de proyectosTesis Doctora-do – Facultad de ciencias Exactas Universidad Nacional del Centro. 2009.
Blacker. 1995. Blacker, F. Knowledge, Knowledge Work and Organizations: And overview
and Interpretation. Organization Studies, 16:1021–1046. 1995.
Bock, Zmud, Kim y Lee. 2005. Bock, G. W., Zmud, R. W., Kim, Y. G., dan Lee, J. N.
Behavioral Intention Formation in Knowledge sharing: Examining the Roles of Extrinsic
Motivators, Social- Psychological Forces, and Organizational Climate. MIS Quar. 2005.
Boh. 2007. Boh, W. F. Mechanisms for sharing knowledge in project-based organizations.
Information and Organization, 17(1):27–58. 2007.
Bresnen. 2003. Bresnen, M., Edelman, L., Newell, S., HarryScarbrough, y JackySwan.
Social practices and the management of knowledge in project environments. International
Journal of Pro-ject Management, páginas 157–166. 2003.
Bretón. 2001. Berthon, P., Pitt, L., y Ewing, M. Corollaries of the collective: The influence of
organizacional culture and memory development on perceived decision-making context. Journal
of the Academy of Marketing Science, 29(2):135–150. 2001.
Clark y Fujimoto. 1991. Clark, K. B. y Fujimoto, T. Product Development Performance:
Strat-egy, Organization, and Management in the World Auto Industry. Harvard Business School
Press. 1991.
Cockburn. 2002. Cockburn, Alistair. Agile Software Development Joins The “Would-Be”
Crowd. Cutter IT Journal 15(1):TBD_PAGES. 2002.
Cohn. 2006. Mike Cohn. Agile Estimating and Planning. 2006.
Conklin. 2001. Conklin J. "Designing organizational memory", GDSS' working papers,
available at: www.gdss.com/wp/DOM.HTM. 2001.
88
Croasdell. 2001. Croasdell, D. T. It’s Role in Organizational Memory and Learning.
Information Systems Management, 18(1):1–4. 2001.
Cross, R., & L. Baird. 2000. Cross, R., & L. Baird. Technology is not enough: improving
performance by building organizational memory. Sloan Management Review, 41(3), 69-78.
2000.
Davenport y Prusa. 1998. Davenport, T. H. y Prusak, L. Working Knowledge: How
Organiza-tions Manage What TheyKnow. Harvard University Press., Cambridge, MA. 1998.
DeFillippi. 2001. DeFillippi, R. J. Project-Based Learning, Reflective Practices and Learning.
Management Learning, 32(1):5–10. 2001.
DeFillippi y Arthur. 1998. DeFillippi, R. J. y Arthur, M. B. Paradox in project-based
enterprise: the case of film making. California Management Review, 40(2):125–138. 1998.
Drabble. 1995. Drabble, B. Artificial Intelligence for Project Planning. In Proceedings of the
Colloqui-um on Future Developments in Project Management Systems, pp. 311-315. 1995.
Drucker. 1993. Drucker, P. F. Post-Capitalist Society. HarperCollins Publishers, New York,
NY, USA. 1993.
Earl. 2001. Michael Earl. Knowledge Management Strategies: Toward a Taxonomy. 2001.
Euzenat. 1966. Euzenat, J. Corporate memory through cooperative creation of knowledge
basesand hyperdocuments.En Actes 10th knowledge acquisition workshop, páginas 1–18.
1966.
Farr. 2000. Farr, K. "Organizational learning and knowledge managers", Work Study, Vol 49
No. 1, pp. 14-17. 2000.
Gann y Salter. 1998. Gann, D. M. y Salter, A. Learning and Innovation Management in
Project-Based, Service-Enhanced Firms. International Journal of Innovation Management,
2(4):431–454. 1998.
89
Goodman y Darr. 1998. Goodman, P. S. y Darr, E. D. Computer-Aided Systems and
Commu-nities: Mechanisms for Organizational Learning in Distributed Environments. MIS
Quarterly, 22(4):417–440. 1998.
Guerrero y Pino. 2001. Guerrero, L. A. y Pino, J. A. Undertanding Organizational Memory.
En 21st Internacional Conference of the Chilean Computer Science Society, páginas 124–132,
Punta Arenas, Chile.IEEE Computer Society. 2001.
Hedberg. 1981. Hedberg, B. How Organizations Learn and Unlearn. En Nystrom, P. y Starbuck, W.,editores, Handbook of Organizational Design, páginas 3–27. Oxford University Press,
New York. 1981.
Hobday. 2000. Hobday, M. The project-based organisation: an ideal form for managing
com-plex products and systems? Research Policy, 29(7-8):871–893. 2000.
Hong. 1999. Hong, J. "Structuring for organizational learning", The Leaving Organization,
Vol. 6 No. 4, pp. 173435. 1999.
Hughes y Cotterell. 1999. Hughes B. and Cotterell M. Software Project Management.
McGraw Hill, Second Edition edition, ISBN 007 709505 7, 1999. 1999.
Ipe. 2003. Ipe, M. “Knowledge sharing on organizations: A conceptual framework”, Human
Resource Development Review Vol. 2, No. 4, pp. 337-359. 2003.
Ireland. 2006. Lewis R. Ireland. Project Management: Strategic Design and Implementation.
2006.
Jackson y Klobas. 2008. Jackson, P. y Klobas, J. Transactive memory systems in
organiza-tions: Implications for knowledge directories. Decision Support Systems, 44(2):409–
424. 2008.
Ke, Muñoz-Avila. 2004. Xu Ke and Héctor Muñoz-Avila. CaBMA: Case-Based Project
Management Assistant. In Pro-ceedings of the Nineteenth National Conference on Artificial
Intelligence, Sixteenth Conference on Innovative Applications of Artificial Intelligence. 2004.
90
Kerzner. 2001. Kerzner, H. Strategic Planning for Project Management Using a Project
Management Maturity Model. John Wiley & Sons., ISBN 0-471-40039-4, 2001. 2001.
Kerzner, R. 2009. Harold R. Kerzner. Project Management: A Systems Approach to
Planning, Scheduling, and Controlling 10th Ed. 2009.
Kodama. 2006. Kodama, M. Project-based Organization in the Knowledge-based Society:
Innovation by Strategic Communities (Technology Management). Imperial College Press,
London, UK, UK. 2006.
Kodama, M. 1999. Kodama, M. Strategic business applications and new virtual knowledgebased businesses through community-based information networks. Information Management &
Computer Security, 7(4):186–199. 1999.
Kransdorff. 1998. Kransdorff, A. Corporate Amnesia: Keeping Know-How in the Company.
Butterworth-Heinemann. 1998.
Kransdorff, A. 2006. Kransdorff, A. Corporate DNA: Using Organizational Memory to
Improve Poor Decisionmaking. Gower Publishing Limited, London. 2006.
Lehner. 1998. Lehner, F., Maier, R. K., y Klosa, O. Organisational Memory Systems –
Applica-tion of AdvancedDatabase & Network Technologies. En Proceedings of the 2nd Int.
Conf. on Practical Aspectsof Knowledge Management (KAKM98), Basel, Switzer. 1998.
Lehner y Maier. 2000. Lehner, F. y Maier, R. K. How Can Organizational Memory Theories
Con-tribute toOrganizational Memory Systems? Information Systems Frontiers, 2(3-4):277–298.
2000.
Liebowitz. 2001. Liebowitz, J. Knowledge Management and its Link to Artificial Intelligence.
Expert Systems with Applications. 2001.
Lietaer. 2002. Lietaer, B. The Future of Money, Century, London. 2002.
Lubit. 2001. Lubit, R. Tacit knowledge and knowledge management: The keys to
sustainable competitive advantage. Organizational Dynamics, 29(3):164–178. 2001.
91
Maybury. 2001. Maybury, M., D’Amore, R., y House, D. Expert Finding for Collaborative Virtual Environments. Communications of the ACM, 44(12):55–56. 2001.
Moore. 1985. Moore, R. C. A Formal Theory of Knowledge and Action. En Hobbs, J. R. y
Moore, R. C., editores, Formal Theories of the Commonsense World, páginas 319–358. Ablex,
Norwood, NJ. 1985.
Nasir. 2006. Mehwish Nasir. A Survey of Software Estimation Techniques and Project
Planning Practices. 2006.
Nonaka y Takeuchi. 1995. Nonaka, I. y Takeuchi, H. The Knowledge Creating Company:
How Japanese CompaniesCreate the Dynamics of Innovation. Oxford University Press, Oxford,
UK. 1995.
Parthasarathy. 2007. M. A. Parthasarathy. Practical Software Estimation: Function Point
Methods for Insourced and Outsourced Projects. 2007.
Pedler, M. et al, Dodgson. 1989. Pedler, M. et al, Dodgson 1989, "Towards the learning
company", Managment Education and Development, Vol 20 No. 1 pp. 1-8. 1989.
PIM. 2010. Project Management Institute. A Guide to the Project Management Body of
Knowledge 4th edition. 2010.
PMI. 2004. PMI. A Guide To The Project Management Body Of Knowledge (PMBOK
Guides). Project Management Institute, third edition. 2004.
Prencipe y Tell. 2001. Prencipe, A. y Tell, F. Inter-project learning: processes and outcomes
of knowledge codification in project-based firms. Research Policy, 30(9):1373–1394. 2001.
Redding. 1997. Redding, J. "Hardwiring the learning organization". TmMing and
Development. Vol. 51 No. 8, pp. 61-7. 1997.
Rosenberg. 2002. Rosenberg, M. J. E-Learning: Strategies for Delivering Knowledge in the
Digital Age. McGraw-Hill Professional. 2002.
92
Schwaber, Sutherland & Beedle. 2000. Ken Schwaber, Jeff Sutherland and Mike Beedle.
SCRUM: An extension pattern language for hyperproductive software development. 2000.
Spender a. 1996. Spender, J.-C. Making Knowledge the Basis of a Dynamic Theory of the
Firm. Strategic Management Journal, 17(Winter Special Issue):45–62. 1996.
Spender y Grant. 1996. Spender, J.-C. y Grant, R. M. Knowledge and the Firm: Overview.
Strategic Management Journal, 17(Special Issue):5–10. 1996.
Srivastava. 2000. Srivastava,B. Planning the project management way: Efficient planning by
effective integration of causal and resource reasoning in RealPlan. 2000.
Stein y Zwass. 1995. Stein, E. y Zwass, V. Actualizing Organizational Memory with
Information Systems. Information Systems Research, 6(2):85–117. 1995.
Tausworthe. 1980. Tausworthe, R. C. The work breakdown structure in software project
man-agement. Journal of Systems and Software, 1:181–186. 1980.
Teece. 2000. Teece, D. J. Strategies for Managing Knowledge Assets: the Role of Firm
Struc-ture and Industrial Context. Long Range Planning, 33(1):35–54. 2000.
Tsoukas. 1996. Tsoukas, H. The firm as a distributed knowledge system: A constructionist
approach. Strategic Managment Journal, 1996 (Special Winter Issue), 11-25. 1996.
Turner y Müller. 2003. Turner, J. R. y Müller, R. On the Nature of the Project as a
Temporary Organization. International Journal of Project Management, 21(1):1–8. 2003.
van Heijst, G., van der Spek, R. & Kruizinga. 1997. van Heijst, G., van der Spek, R. &
Kruizinga, E. Corporate Memories as a tool for knowledge management, Journal of expert
systems and their applications (in press). 1997.
Villaverde. 2009. Villaverde, Jorge. Codificación de la Memoria Organizacional con Perfiles
de Usuarios- Tesis Doctorado – Facultad de ciencias Exactas Universidad Nacional del Centro.
2009.
93
Walsh y Ungson. 1991. Walsh, J. y Ungson, G. Organizational Memory. Academy of Management Review, 16(1):57–91. 1991.
Weber. 2001. Weber, R., Aha, D. W., y Becerra-Fernandez, I. Intelligent Lessons Learned
Sys-tems. Expert Systems with Applications, 20(1):17–34. 2001.
Weld et. al. 1995. Weld, D. S., Marks, J. and Bobrow, D. G. The Role of Intelligent Systems
in the National Information Infrastructure.. AI Magazine. (16:3), 45-64, 1995. 1995.
Wexler. 2001. Wexler, M. N. The who, what and why of knowledge mapping. Journal of
Knowledge Management, 5(3):249–264. 2001.
Wexler, M. 2002. Wexler, M. N. Organizational memory and intellectual capital. Journal of
Intellec-tual Capital, 3(4):393–414. 2002.
Wiig. 1997. Wiig, K. M. Knowledge Management: An Introduction and Perspective. Journal
of Knowledge Management, 1(1):6–14. 1997.
Windeler y Sydow. 2001. Windeler, A. y Sydow, J. Project networks and changing industry
practices – collaborative content production in the German television market. Organizational
Sci-ence, 22(6):1035–1060. 2001.
Wysocki. 2003. Wysocki R. . Effective Project Management. Wiley Publishing, Third Edition
edition, ISBN 0-471-43221-0, 2003. 2003.
Yimam-Seid y Kobs. 2003. Yimam-Seid, D. y Kobsa, A. Expert-Finding Systems for Organizations: Problem and Domain Analysis and the DEMOIR Approach. Journal of Organizational
Computing and Electronic Commerce, 13(1):1–24. 2003.
94