SXP, METODOLOGÍA ÁGIL PARA EL DESARROLLO DE SOFTWARE

SXP, METODOLOGÍA ÁGIL PARA EL DESARROLLO DE SOFTWARE Peñalver, G. Meneses, A. García, S.

Universidad de las Ciencias Informáticas, Ciudad de La Habana, Cuba

Resumen La tendencia hoy en día, es obtener productos de software en el menor tiempo posible y elaborar la documentación necesaria. Por lo que proponer una metodología de procedimientos ágiles para el proceso de producción de software es el objetivo de este trabajo. En la investigación se ofrece una estrategia tecnológica especialmente dirigida para proyectos de pequeños grupos de trabajo, rápido cambio de requisitos o requisitos imprecisos, donde exista un alto riesgo técnico y se orienta a una entrega rápida de resultados y una alta flexibilidad. SXP es un híbrido cubano de metodologías ágiles que tiene como base las metodologías SCRUM y XP que permiten actualizar los procesos de desarrollo de software para el mejoramiento de su producción. Consta de 4 fases: Planificación-Definición, Desarrollo, Entrega y Mantenimiento, cada una desglosada en flujos de trabajo y actividades que generan artefactos. Esta metodología ayuda a fortalecer el trabajo en equipo, enfocados en una misma dirección, permitiendo además seguir de forma clara el avance de las tareas a realizar, a partir de la inserción de procedimientos ágiles que permitan actualizar los procesos de software para el mejoramiento de la producción, aumentando el nivel de interés del equipo. Palabras claves: Ingeniería de Software, Metodologías Ágiles, Proceso de Desarrollo de Software.

Abstract The trend today is to get software products in the shortest time possible and prepare the necessary documentation. As a methodology to propose flexible procedures for the software production process is the objective of this work. The research offers a technology strategy specifically targeted for small projects working groups, rapidly changing requirements or vague requirements, where there is a high technical risk and focuses on rapid delivery of results and high flexibility. SXP is a hybrid of agile methodologies Cuban which is based on Scrum and XP methodologies are available to update the software development processes to improve production. It consists of 4 phases: Planning-Definition, Development, Delivery and Maintenance, each broken down into workflows and activities that generate artifacts.

333

This methodology helps build teamwork, focused in one direction, allowing also clearly follow the progress of the tasks to be performed, from the insertion of flexible procedures for updating the software processes to improve the production, increasing the level of interest of the team. Keywords: Software Engineering, Agile Methodologies, Software Process Development.

Introducción ¿Porqué SXP y no SCRUM y XP? El Grupo Unicornios tiene un marcado objetivo social, garantizar la transición a entornos libres de manera paulatina pero segura, propiciando un ambiente de confianza para aquellos que se someten a tan valiente tarea. Todo proceso de migración conlleva un estudio minucioso de la organización en cuestión, con el objetivo de identificar todas las aplicaciones que en ella se emplean y además son de corte propietaria, para de esta manera encontrar aquellas aplicaciones identificadas ya como alternativas y en caso contrario, pues comenzar un nuevo proyecto para desarrollar el producto al cliente. Esta última variante puede ser enfrentada de dos maneras: Desarrollo de un nuevo sistema, preferiblemente genérico para garantizar que sea extensible a otras organizaciones, o bien puede ser un producto llamado a la medida del cliente, donde el interesado identifica la mayoría de las funcionalidades que debe tener el sistema. Contribuir en el desarrollo de un sistema existente, que en ocasiones puede carecer de funcionalidades o que tienen baja usabilidad. El enfrentamiento a este tipo de evento de desarrollar aplicaciones, consume siempre gran cantidad de tiempo, pues no se deben obviar ciertos pasos ingenieriles de vital importancia para la futura “salud” del producto, tales como la identificación de aplicaciones homólogas con el objetivo de identificar funcionalidades genéricas asociadas a los sistemas, identificar las funcionalidades que proponen sus interesados, el enfoque arquitectónico del sistema, el desarrollo y las pruebas. Todas las actividades anteriormente descritas, consumen bastante tiempo y si a ello le sumamos que este proyecto está incluido dentro de un proceso de migración, el cual también consume gran cantidad de tiempo, estamos frente a un gran problema: ¿cómo lograr la satisfacción de un cliente en un tiempo relativamente corto y garantizando que el producto se ajuste a las normativas de calidad? El grupo de Ingeniería y Análisis de Sistemas, adscrito al Grupo Unicornios, inmersos en dicho problema ha investigado y desarrollado una metodología a la medida que permita soportar desarrollos ágiles de aplicaciones. Centrados en la base canónica sobre la cuál debe reposar todo proceso de desarrollo de software se comenzó el estudio para identificar las metodologías de desarrollo de software y de gestión de proyectos con enfoques ágiles existentes, para posteriormente valorarlas y adaptarlas a nuestras necesidades. En los criterios de selección el equipo tuvo muy en cuenta los resultados y nivel de popularidad que tienen cada una de ella. Hasta el momento antes del estudio el Grupo utilizaba el Proceso Unificado de Rational (acrónimo en inglés RUP, Rational Unified Process; dicho acrónimo lo emplearemos a lo largo del documento), el cual no se consideraba viable puesto que orientaba todo el trabajo ingenieril a una sobre documentación del proyecto que hacía poco gestionable el mismo, además que hacía al grupo dependiente en cierta forma de herramientas CASE de corte propietario como el Rational Rose o Visual Paradigm, o en la búsqueda de las herramientas alternativas, se debían utilizar muchas herramientas que cada una por su parte realizaba lo que las privativas hacen en una sola, 334

siendo esto un gran problema, no tanto por el tema de la comodidad, sino desde el punto de vista de la trazabilidad que tienen todos los artefactos que se generan en dicho proceso, provocando en ocasiones inconsistencias entre los artefactos y una sobre dosis de Gestión de la Configuración y Cambios que ya incidía negativamente en el desarrollo y mantenibilidad de los proyectos y productos respectivamente. Una vez terminado el estudio, es considerado que las metodologías adecuadas para nuestra personalización son extreme programming (XP) y SCRUM. XP fue la metodología candidata para guiar el proceso ingenieril, puesto que le precedía su alto grado de aceptación por la comunidad internacional de desarrollo ágil, además que nos facilitaba una documentación mas discreta y mayor dinamismo para el desarrollo; la idea de las duplas de desarrollo para el grupo de investigadores resultó muy interesante, pues en pequeñas iteraciones dos desarrolladores lograrían hacer, lo que antes un equipo especializado en cada tema debía hacer (analista, arquitecto, diseñador, desarrollador, probador). SCRUM es entonces la metodología ideal para toda la gestión de proyectos, serviría de soporte para acelerar el dinamismo que se identificó en XP, la identificación de los pequeños sprint (iteraciones) y las reuniones con el SCUM Máster todos los días se acercaba mas a la disciplina que se quería alcanzar en el grupo, donde líderes de solución y equipo de desarrollo se reunieran y controlaran los avances e identificaran los posibles riesgos que afectaban de una manera u otra la correcta ejecución del proyecto. Todo lo antes mencionado se aceptó por el equipo de investigadores de manera muy positiva, el nivel de disciplina laboral que se alcanzaría y la productividad de los involucrados en el grupo supuestamente se elevaría; pero se debían realizar ciertos cambios a tanta teoría y práctica probada en entornos reales a nivel internacional antes de ponerlo en práctica en el grupo Unicornios. Algunos elementos que no se han mencionado provocaron esta decisión de readaptación o re-definición del modo de aplicación de ambas metodologías en el grupo y que se mencionarán a continuación. El Grupo Unicornios está adscrito a la Universidad de las Ciencias Informáticas (UCI, acrónimo por el que identificaremos en lo adelante la institución) y su gran masa de involucrados son estudiantes de pregrado organizados y formados por profesores de dicha institución. La composición del estudiantado en ese entonces era de: 

47 % de grados terminales (4to y 5to año de la carrera)



35 % de grado intermedio (3er año de la carrera)



18 % de grados iniciales (1ro y 2do año de la carrera)

La UCI tiene como misión formar Ingenieros Informáticos integrales, los cuales cursan sus asignaturas de pre-grado en curso regular diurno, pero con una vinculación directa en la producción de software, de manera que la formación del mismo sea enriquecida con la experiencia práctica. Un estudiante UCI es formado a lo largo de cinco años y una vez culminada su carrera con la discusión de un Trabajo de Diploma es ubicado a prestar sus servicios en una institución estatal que los haya solicitado. El Grupo Unicornios además de producir y personalizar software para sus clientes y dar soporte a la migración a entornos libres, tiene la responsabilidad y labor educativa de formar profesionalmente a dichos estudiantes. Es por ello que se identificaron la mayor cantidad de problemáticas que pudieran afectar el correcto despliegue y desempeño de la metodología y equipo de desarrollo respectivamente. A continuación las desventajas y ventajas identificadas y en las cuales se debieron enfocar los esfuerzos de personalización de dichas metodologías: 335

Desventajas: La formación de la mayoría de los integrantes del proyecto está en constante evolución, incluso en ocasiones, los mismos si se encuentran en los tres primeros años de la carrera no han vencido la mayoría de las asignaturas curriculares básicas de la carrera, entiéndase: Programación, Base de Datos, Ingeniería de Software y Gestión de Software. Por estar la formación del estudiante en ascenso y constante evolución, es evidente que no todos tienen las habilidades y competencias que debe tener un programador Senior o Máster y trae consigo que no se cuenta con un alto grado de abstracción. Existen grandes probabilidades que un estudiante UCI una vez termine su tránsito por la universidad y se gradúe sea asignado a una institución estatal no vinculada directa o indirectamente con la UCI y evidente con el Grupo Unicornios, por tanto el conocimiento asimilado y generado por el mismo puede considerarse perdido. La documentación discreta que generan ambas metodologías pueden provocar estancamientos en la continuidad de los proyectos una vez que sus integrantes egresen de la Universidad o causen baja del proyecto, Grupo o Universidad por cualquier otra razón. Gran demanda de egresados UCI por parte de las instituciones estatales y bolsa de trabajo del Ministerio de Trabajo y Seguridad Social de la República de Cuba. Ventajas: Los proyectos asociados al Grupo servirán en todo momento de un espacio de formación continua del estudiante. El área temática a la que está asociada el Grupo, el Software Libre, contribuye grandemente a la formación del estudiante, pues el mismo podrá revisar códigos enteros de aplicaciones escritos en comunidades internaciones de gran prestigio y con elevada formación de sus recursos humanos; compartir experiencias en foros de discusión, blog, áreas temáticas de debate masivo, etc. La disposición de una amplia red de ordenadores y servidores que comparten tecnología bastante actual y de gran rendimiento. Presencia de profesores que guían el proceso de enseñanza – aprendizaje de los mismos en la producción. Marcado interés de la institución en el modelo de formación y producción. Contar con un conjunto de profesores y estudiantes aventajadas que pueden impartir cursos de capacitación en materias, técnicas y herramientas que soporten el proceso productivo del Grupo. La formación docente del estudiante está enfocado netamente al aprendizaje apoyado por herramientas soportadas en sistemas operativos GNU/Linux. Aplicar un modelo de formación/capacitación productiva basado en competencias, la cual puede ser aplicada según el año que cursa el estudiante, garantizando que el mismo obtenga habilidades bien definidas en su formación profesional y acorde con la formación docente que le brinda la institución. Se podrán formar a los estudiantes con una cultura laboral de disciplina y alta productividad. Orientación gubernamental de la migración a entornos libres de la sociedad cubana. Presencia de la dirección del Grupo Técnico Nacional para la Migración a Software Libre en la UCI. 336

Las desventajas y ventajas anteriormente expuestas fueron mitigadas y aprovechadas respectivamente por el equipo de investigadores, a continuación nuestras consideraciones y proyecciones: Los profesores son los responsables de la continuidad de los proyectos, en otras palabras, son asignados como líderes y en la mayoría de los proyectos son los analistas y arquitectos de software de las aplicaciones en desarrollo. La documentación discreta que brindan ambas metodologías se refuerza un poco, para garantizar que el conocimiento se comparta, incluso sirva de guía para los de menor formación profesional por encontrarse en grados iniciales e intermedios y para evitar que los que se encuentran en grados terminales una vez egresados de la UCI se lleven consigo el conocimiento y caiga en caos el futuro del proyecto. Se hizo de vital importancia definir un documento de arquitectura donde se describiera la arquitectura del sistema, estrategias de integración con otros sistemas, así como la definición de herramientas y tecnologías de desarrollo a emplear por el equipo de solución. En gran medida los responsables de la definición arquitectónica de los sistemas estará a cargo del profesor designado al proyecto. Se acordó fomentar en la masa productiva la necesidad de utilizar correctamente el repositorio de control de versiones “subversion” y la herramienta de gestión de proyectos “dotProject”, de manera organizada y disciplinada. Con esto la dirección del Grupo puede hacer análisis concretos que le indiquen cómo va la producción, qué proyectos van más aventajados y cuáles más rezagados, para las futuras tomas de decisiones por parte del SCRUM Máster. Planificación, asignación, creación e impartición de cursos de capacitación para el personal del Grupo con vistas a su formación, se concilió que los responsables de los mismos sería de los profesores y estudiantes de pregrado de años terminales en su mayoría, que en el caso de éstos últimos le servirían además en su formación como futuro profesional, pues lo dotarían de habilidades comunicativas que pondrían en práctica más adelante en la presentación de trabajos investigativos a eventos científicos y en la propia defensa de su Trabajo de Diploma para su categorización como Ingeniero en Ciencias Informáticas. En esencia estas fueron las principales proyecciones del grupo de investigadores, en base a esto se conformó la metodología, se definieron sus fases, trabajadores involucrados y artefactos generados, además se liberó un expediente que proyecto que recogería toda la documentación generada; todo un gran reto. Desarrollo La metodología SXP durante sus dos años de despliegue y ejecución ha sido estudiada, refinada, adaptada y aún le queda la profunda convicción al grupo de investigadores de la misma que es perfectible aún más, sin perder de vista su carácter ágil y revolucionador. SXP, es un híbrido cubano de metodologías ágiles, que ofrece una estrategia tecnológica, a partir de la introducción de procedimientos ágiles que permitan actualizar los procesos de software para el mejoramiento de la actividad productiva fomentando el desarrollo de la creatividad, aumentando el nivel de preocupación y responsabilidad de los miembros del equipo, ayudando al líder del proyecto a tener un mejor control del mismo. Consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar el éxito del proyecto. Basada completamente en los valores y principios de

337

las metodologías ágiles expuestos en el Manifiesto Ágil. Como metódo de estimación se utiliza la opinión de expertos y constan con métricas o indicadores para lograr una eficiente calidad. Consta de 4 fases principales: Planificación-Definición donde se establece la visión, se fijan las expectativas y se realiza el aseguramiento del financiamiento del proyecto; Desarrollo, es donde se realiza la implementación del sistema hasta que este listo para ser entregado; Entrega, puesta en marcha; y por último Mantenimiento, donde se realiza el soporte para el cliente. De cada una de ellas se desplegan 7 flujos de trabajo: concepción inicial, captura de requisitos, diseño con metáforas, implentación, prueba, entrega de la documentación, soporte e investigación, el cual se utiliza por el equipo de desarrollo cuando sea necesario, es decir, es un flujo que se puede mover y utilizarlo en cualquier parte del ciclo de vida del proyecto. De estos flujos se realizan numerosas actividades tales como el levantamiento de requisitos, la priorización de la Lista de Reserva del Producto, definición de las Historias de Usuario, diseño, implementación, planificación de las iteraciones y las actividades que se van a realizar para lograr el producto, pruebas, además de las tareas necesarias para realizar las investigaciones para documentar todo el proceso.

Figura 1. Fases y flujos de trabajo de SXP.

Para el trabajo con la metodología es necesario tener en cuenta su guión, donde se especifican las fases con cada uno de los flijos de trabajo y las actividades que de donde se generan los artefactos (los que se encuentran en rojo) que componen el expediente de proyecto el cual se presenta a continuación:  Planificación ↔ Definición (Peñalver, 2008) 338

                   

Entrevista con el cliente (concepción inicial) Plantilla de concepción del sistema. Juego de la planificación. Plantilla Modelo de Historia de Usuario del negocio. Captura de requisitos: Creación de la LRP. Plantilla Lista de Reserva del Producto (LRP). Priorización de la LRP. Definir las historias de usuario. Plantilla Historia de usuario. Asignar las historias de usuario. Plantilla Historia de usuario. (actualizar plantilla, y lo realiza el gerente.) Valoración del esfuerzo. Plantilla Historia de usuario. (actualizar plantilla, y lo realiza el gerente.) Valoración de riesgos. Plantilla Lista de riesgos. Diseño con las metáforas. (El diseñador solo hace lo que defina el analista.) Plantilla Modelo de diseño. Refactorización (eliminar complejidad, diseñar lo más simple que se pueda). Reunión de revisión del diseño.

Desarrollo  Junta de planificación.  Plantilla Cronograma de producción.  Plantilla de Plan de releases.  Definir las historias de usuario a implementar.  Tareas para lograr dicha implementación.  Plantilla de Tareas de Ingeniería.  Implementación.  Estándar de código. Código fuente. Junta de seguimiento (encuentro para hacer el primer chequeo de lo que se esta implementando.)… actividad. Taller técnico (Se evacuan las dudas que tienen cada uno de los participantes del equipo de desarrollo, y se toman decisiones técnicas.)… actividad.  Junta de revisión.  Pruebas  Plan de Pruebas.  Plantilla Caso de Prueba de aceptación.  Entrega  Entrega de la documentación.  Entrenamiento.  Capacitación  Manual de usuario.  Manual de Identidad. 339

  

Manual de desarrollo. Instalación. Marketing

Mantenimiento  Soporte.  Plantilla de Gestión de cambios. Observación: Desde el diseño en la fase de Planificación ↔ Definición y toda la fase de Desarrollo es un ciclo. Las entregas son frecuentes, y existe una refactorización continua, lo que permite mejorar el diseño cada vez que se le añada una nueva funcionalidad. SXP esta especialmente indicada para proyectos de pequeños equipos de trabajo, rápido cambio de requisitos o requisitos imprecisos, muy cambiantes, donde existe un alto riesgo técnico y se orienta a una entrega rápida de resultados y una alta flexibilidad. Ayuda a que trabajen todos juntos, en la misma dirección, con un objetivo claro, y permite además seguir de forma clara el avance del equipo de desarrollo por parte del cliente, de forma que los jefes pueden ver día a día cómo progresa el trabajo. Para la realización de las actividades antes mencionadas la metodología define los siguientes roles: Líder del Proyecto (Scrum Máster) Es un rol de administración que debe asegurar que el proyecto se está llevando a cabo de acuerdo con las prácticas y que todo funciona según lo planeado. Su principal trabajo es remover impedimentos y reducir riesgos del producto. Coordinar y facilitar las reuniones. Asegurar que se consigue los objetivos de la reunión de planificación de la iteración. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración. Gerente (Management) Es el responsable de tomar las decisiones finales, acerca de estándares y convenciones a seguir durante el proyecto. Participa en la selección de objetivos y requerimientos y en la selección del Usuario Interno. Tiene la responsabilidad de controlar el progreso y trabaja junto con el Jefe de Proyecto en la reducción de la Lista de Reserva del Producto. Realiza el seguimiento del progreso de cada iteración. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Puede ocupar el rol de programador máster (líder de desarrollo) durante la etapa de desarrollo. Especialistas Es el responsable del proceso global. Es necesario que conozca a fondo el proceso, ya sea de la metodología utilizada o cualquier otro proceso o elementos de gran importancia para el desarrollo de software. Particularmente es una especialización que está activa, el miembro del grupo de 340

trabajo que la desempeña siempre está ejecutándola y alcanzando un grado mayor de conocimientos en el tema. Ejemplos: Ingenieros de Software, Especialistas de Servicios (migración a software libre, jefe del consejo editorial), Especialistas en diseño gráfico, etc. Consultor Es un miembro externo del equipo con un conocimiento especifico en algún tema necesario para el proyecto, en el que puedan sugerir problemas, además aportan ideas y experiencias para el beneficio del sistema en desarrollo. Esta es una especialización menos activa, quien la ejecuta funciona en este rol por un corto período de tiempo. Está más orientada a roles de desarrollo, y sus ejecutores pueden trabajar en otros roles (en otro equipo) durante el desarrollo del software. Ejemplos: Consultor de desarrollo Web, consultor de desarrollo de escritorio, diseñador de base de datos, etc. Cliente (Customer) El cliente participa en las tareas que involucran la lista de reserva del producto Presentar la Reserva del producto al equipo, enfatizando el valor y prioridades del mismo Definir la meta de la iteración Aprobar las modificaciones en la Reserva del producto y en el alcance de la iteración Miembros del Proyecto (Scrum Team) Es el equipo del proyecto que tiene la autoridad para decidir cómo organizarse para cumplir con los objetivos de un Sprint. Sus tareas son: Estimar esfuerzo, crear la reserva del Sprint, revisar la Lista de Reserva del Producto y sugerir obstáculos que deban ser removidos para cumplir con los items que aparecen. Típicamente es un equipo de entre 5 y 10 personas cada una especializada en algún elemento que conforma los objetivos a cumplir, por ejemplo: Programadores, Diseñadores de Interfaz de usuario, etc. La dedicación de los miembros del equipo debería ser full-time con algunas excepciones. La membresía solo puede cambiar entre sprints (no durante). Programadores (Programmers) Es el encargado de producir el código y escribir las pruebas unitarias. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo. Analista (Analyst) Es el encargado de escribir las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio, todo esto lo realiza junto con el cliente. Diseñadores (Designers) Encargados del diseño del sistema; así como el de los prototipos de interfaces, máximos responsables de la realización del diseño de las metáforas y supervisan el proceso de construcción. Encargado de Pruebas (Tester) 341

Es el encargado de ayudar al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Arquitecto (Architect) Se vincula directamente con el analista y el diseñador debido a que su trabajo tiene que ver con la estructura y el diseño en grande del sistema. Ayuda en el diseño de las metáforas. Gestor de Investigaciones Persona encargada de gestionar todas las tareas investigativas que se desarrollan. Tiene como responsabilidad planificar el desarrollo de las investigaciones, verificar el cumplimiento y calidad de las mismas. Es el responsable de la elaboración del PDI. No necesariamente debe tener conocimientos informáticos, pero si algún dominio de metodología de Investigación. Entre los resultados obtenidos podemos decir que: 

La metodología establece el uso de sistemas automatizados para la generación de algunos artefactos. Y además los recomienda de manera explícita.



Contar con un expediente le permitió sobrevivir, llegar a usarse. Establecerse en el entorno con apoyo legal.



Muy usada en proyectos que no utilizan paradigma orientado a objetos. Fundamentalmente proyectos de Software Libre (SWL) que trabajan con ficheros Bash o C.



La descripción de una historia de usuario suele ser más sencilla que la de un caso de uso.



Positiva para el uso de estudiantes que aprenden ingeniería. En la práctica los estudiantes de años avanzados en la carrera son los únicos que pueden desempeñar el rol de analistas o diseñadores de un software, lo que hace muy improductiva a la fuerza joven, que en ocasiones tiene buenas ideas y energía para desarrollarlas, e incluso muy buena preparación en uno o dos lenguajes de programación.



SXP cuenta con artefactos muy bien definidos para períodos de investigación. En el desarrollo de software libre, para no reinventar la rueda, se hace necesario investigar los proyectos que han intentado hacer lo mismo. En un banco de software disponible de unos 200 000 proyectos, los períodos de investigación suelen ser de unos 3 ó 4 meses. Posterior a ello el equipo comienza siempre a desarrollar partiendo de código ya desarrollado y que fue encontrado durante la investigación. Documentar estos 4 meses de investigación - en pocos artefactos - suele ser productivo para que otros equipos de desarrollo tomen decisiones en menos tiempo. También permite a desarrolladores en entornos académicos obtener publicaciones.



SXP ha sido excelente para equipos pequeños, siempre ha sido recomendado para menos de 20 personas.



La documentación siempre tiene un día o una semana de retraso con respecto al código. Siempre hay más código que documentación. En el entorno UCI con metodología RUP suele haber mucho papel y poco código. Lamentablemente el proceso de revisión y auditorías no tiene un acápite para revisar el código, o sea si usted ha dicho que usa una metodología ágil lo más conveniente sería revisar la Historias de Usuario (HU) que debe

342

haber implementado según el cronograma y hacer al menos pruebas de caja negra a la aplicación para evaluar la veracidad de la documentación. 

Equipos nuevos se han incorporado al desarrollo de un proyecto antiguo en tan solo una iteración (30 días). Por lo general la renovación de un equipo mata al proyecto, lo realentiza tanto como demora en adquirir un líder que hala.



El tiempo en empezar a desarrollar ha sido bajado hasta 14 días, una cifra extraordinaria para el entorno UCI pues los proyectos por lo general pasan más de 2 meses y hasta 9 ó 10 en definición. En este tiempo SXP ha demostrado que puede tener 3 ó 4 versiones ALFA con funcionalidades relevantes, y varias versiones BETAs intermedias a estas.



No ha sido necesario abandonar los diseños anteriores de los analistas. En el criterio particular de los investigadores esto podría tratarse de lo siguiente, o sea la explicación: los analistas tienen poca experiencia de desarrollo. Hacen sus análisis y después en tiempo de implementación, los desarrolladores deben cambiar más del 30% de lo que ya estaba escrito. Esto constituye una demora al proyecto, y un fracaso a la etapa de análisis.



SXP generó su propia documentación basada en 8 tesis, las cuales están en el repositorio de SXP para su consulta todo el tiempo.



Las pruebas en SXP han sido por regla general satisfactorias.



Estableciendo un sistema de trabajo colaborativo SXP tiene una plantilla de Arquitectura que ha pasado por múltiples manos. SXP también tiene asociado el concepto de visión de Arquitectura: Si tu equipo no sabe como hacer este sistema ¡píntalo! Luego programación chatarra... e itera todo eso cada vez que sientas que estás en un escalón superior.

Conclusiones En esta investigación se realizó una metodología de procedimientos ágiles, para los proyectos productivos. Con el estudio del estado en que se encuentran internacionalmente las metodologías ágiles XP y SCRUM, se demostró que son los procedimientos ágiles más utilizados en el proceso de desarrollo de software según sus características. Con la utilización de la metodología en los proyectos de la universidad se ha demostrado un alto nivel de satisfacción por parte de los desarrolladores y miembros del equipo y cliente en general. Se logró que la organización de la documentación de cada uno de los sistemas fuera eficiente, además de que cada uno de los miembros del equipo se mostraba interesado y motivado para el desarrollo. El trabajo era más ágil y mantener al cliente dentro del equipo de desarrollo proporcionó mejores resultados y una mayor satisfacción por parte de los interesados finales del producto. Con la utilización de SCRUM para la gestión, se logra una planificación y organización inigualable; mientras que XP respalda con sus prácticas todo el proceso de desarrollo, obteniéndose de esta forma un proceso de software completo. Mostrar interés en el desarrollo y no en la documentación a llenar priorizó el tiempo para que este fuera empleado por el equipo en otras tareas de importancia, tales así como la atención a las tareas docentes, de estudio independiente entre otras.

343

La generación de los artefactos necesarios e imprescindibles respalda la documentación de cada uno de los sistemas, logrando así que no queden sistemas sin ser analizados y documentados. Con los valores y principios que respaldan las metodologías ágiles se fomentó en cada uno de los miembros del equipo la unidad, el colectivismo y colaboración. El procedimiento ágil SXP contiene la organización de los procedimientos a seguir paso a paso, con la generación de cada uno de los artefactos necesarios para lograr una documentación con el éxito y la eficiencia necesaria que requiere un proceso de software. El líder de proyecto puede llevar un mejor control de las tareas y la planificación de las mismas. Asimismo reconocer la tendencia al compañerismo y solidaridad, no dejando margen al egoísmo e individualidad. Involucrar a los miembros del equipo de desarrollo en las decisiones sobre el proyecto y sus vías de desarrollo, puede ser de gran ayuda a la hora de aumentar la motivación, sin dejar fuera que se logra una mayor interacción con el cliente al ser parte del equipo. Proporcionando una mejor calidad en el producto a entregar.

Referencias 

Peñalver Romero, G.M., “Trabajo de diploma: Metodología ágil para proyectos de software libre”. Ciudad de La Habana, Universidad de las Ciencias Informáticas. 2008.

Correspondencia Ing. Gladys Marsi Peñalver Romero Ing. Sergio Jesus García De La Puente Ing. Abel Meneses Abad Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, Km 2 ½, Rpto Torrens, Boyeros, Ciudad de La Habana, Cuba. Código Postal: 10 800 Correo electrónico: gmpenalver1,[email protected] , [email protected]

344