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
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.
Í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.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
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 AmnesiaOrganizacional (AO).
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.
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.
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.
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.
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
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)
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.
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.
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).
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.
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).
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.
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.
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).
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
• 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.
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.
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:
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
• 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.
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
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.
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.
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
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.
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.
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 post-condiciones. 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.
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.
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 del proyecto
Definición de Product Backlog Definición de recursos
Definición de roles
Definición de preferencias y restricciones Planificación del sprint Definición de Sprint Backlog
Incorporación de preferencias y restricciones Sprint Retrospective Calificación de asignaciones
Revalorizar aptitudes técnicas de los recursos
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 HABILIDAD NIVEL DE EXPERIENCIA
Ana Programación SQL 4
Programación C# 4
Roberto Programación SQL 7
Programación C# 7
Rodrigo Programación SQL 10
Programación C# 10
Julio Creatividad 4
Modelado 3D 4
Aníbal Creatividad 7
Modelado 3D 7
Martin Creatividad 10
Modelado 3D 10
Tabla 3.2.: Recursos involucrados con sus respectivos conocimientos.
ROL HABILIDAD REQUERIDA NIVEL MINIMO NIVEL MAXIMO
Programador junior Programación C# 1 4
Programación SQL 1 4
Programador semi-senior Programación C# 4 7
Programación SQL 4 7
Programador senior Programación C# 7 10
Programación SQL 7 10
Diseñador gráfico junior Creatividad 1 4
Modelado 3D 1 4
Diseñador gráfico semi-senior Creatividad 4 7
Modelado 3D 4 7
Diseñador gráfico senior 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.
tareas que componen una User Story. La tabla 3.5 muestra el Product Backlog utilizado para el ejemplo conductor.
USER STORY TAREA
Soporte de persistencia Diseñar estructura de base de datos
Implementar altas bajas y modificaciones (ABM) Desarrollo de login Diseñar interfaz de login
Implementar funcionalidad para inicio de sesión
Visualización de panel de planning poker
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
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 Implementar animaciones del avatar Programador semi-senior 1 Diseñador gráfico senior 1 Agregar control de movimiento 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
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 PREFERENCIA DE
ASIGNACION Implementar animaciones del avatar Programador semi-senior Rodrigo
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.
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 USER STORY
1 Soporte de persistencia
Desarrollo de login
2
Visualización de panel de planning poker 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.
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 Martin Diseñador gráfico senior Implementar funcionalidad para inicio de
sesión 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 Implementar animaciones del avatar Rodrigo Programador senior
Martin Diseñador gráfico senior
Agregar control de movimiento
Rodrigo Programador senior Aníbal
Diseñador gráfico semi-senior
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
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.
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.
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
Implementar funcionalidad para inicio de sesión Ana 4
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.
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. .
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.