Articulometodologiadeprogramacionvol8num3art72016 PDF
Articulometodologiadeprogramacionvol8num3art72016 PDF
Articulometodologiadeprogramacionvol8num3art72016 PDF
net/publication/346060429
CITATIONS READS
3 579
1 author:
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Modelo tecnopedagógico para la continuidad académica del ITVH en tiempos de covid-19 View project
All content following this page was uploaded by Jose Manuel Gomez-Zea on 21 November 2020.
Implementing scrum + rad for the management and development of software projects
in teams with limited and temporary staff
Ciencias computacionales, Gestión de Las metodologías de desarrollo ágil han transformado la manera de construir software; de
proyectos, Métodos Ágiles, Ingeniería métodos rígidos y lentos a procesos flexibles y eficientes. Rad y Scrum son marcos de trabajo
de software ágil que proponen un conjunto de prácticas y roles para: elaborar software de calidad, ob-
tener resultados anticipados, dar flexibilidad y adaptación, permitir el retorno de inversión,
promover la productividad; entregar con frecuencia software que funcione, entre otros. Este
artículo propone un conjunto de buenas prácticas (combinación de la metodología scrum y
el desarrollo rápido de aplicaciones rad) para el análisis, diseño y desarrollo de proyectos de
software de calidad en períodos menores a 60 días, aplicado en entornos con poco personal
o personal eventual. Además, se plantean variables y elementos para su óptimo funciona-
miento y se demuestran en el caso de estudio del departamento de desarrollo del Instituto
Tecnológico de Villahermosa, en Tabasco, México
KEYWORDS: ABSTRACT
Computer science, Project The agile development methodologies have transformed the way we build software;
management, Agile methods, from rigid and slow methods to flexible and efficient processes. Rad and Scrum are agile
Software engineering frameworks that propose a set of practices and roles for develop quality software, obtain
anticipated results, provide flexibility and adaptation, allow the return on investment,
promote productivity, and deliver working software frequently, among others. This paper
proposes a set of best practices (combination of the scrum methodology and the rapid
application development rad) for the analysis, design and development of quality software
projects in periods of less than 60 days, applied in environments with limited staff or staff
eventual. Variables and elements are analyzed for optimum performance in the case study
of the development department of the Villahermosa Institute of Technology, in Tabasco,
México.
Recibido: 31 de julio del 2015 • Aceptado: 11 de noviembre del 2015 • Publicado en línea: 7 de octubre 2016
52
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
53
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
querimientos, diseño de usuario, construcción hasta la deben trabajar juntos de forma cotidiana a través del
fase de corte y cambio. proyecto
5.Construcción de proyectos en torno a individuos
motivados, dándoles la oportunidad y el respaldo que
necesitan y procurándoles confianza para que realicen
la tarea.
6.La forma más eficiente y efectiva de comunicar
información de ida y vuelta dentro de un equipo de
desarrollo es mediante la conversación cara a cara.
7.El software que funciona es la principal medida del
progreso
8.Los procesos ágiles promueven el desarrollo
sostenido.
Fig. 1.- Fases del enfoque Rad. Autor: James Martín. 9.La atención continua a la excelencia técnica
enaltece la agilidad.
A.Características de Rad 10.La simplicidad como arte de maximizar la cantidad
a)Equipos híbridos: Los desarrolladores deben ser de trabajo que no se hace, es esencial.
analistas, diseñadores y programadores en uno. 11.Las mejores arquitecturas, requisitos y diseños
b)Herramientas especializadas: Desarrollo visual, emergen de equipos que se auto-organizan. En intervalos
Herramientas colaborativas, Interfaces estándares, regulares, el equipo reflexiona sobre la forma de ser más
Control de versiones, Calendario grupal y Componentes efectivo y ajusta su conducta en consecuencia [4].
reusables.
c)Timeboxing: Las funciones secundarias son
eliminadas. Técnica que consiste en fijar el tiempo
máximo para conseguir unos objetivos, tomar una
decisión o realizar unas tareas.
d) Prototipos iterativos: Reunión JAD, se reúnen
los usuarios y los desarrolladores. Lluvia de ideas para
obtener un borrador inicial de los requisitos.
e) El facilitador: Tiene clara las metas, prepara la
agenda de asuntos y escribe un reporte final [3].
Fig. 2.- Proceso Scrum. Autor: proyectosagiles.org
2.2.SCRUM
B.Características de Scrum
Es un marco de trabajo para la gestión y desarrollo de
software, que se basa a la adaptación continúa a las cir- El proceso parte de la lista de objetivos/requisitos
cunstancias de la evolución de un proyecto [4]. priorizada del producto, que actúa como plan del
A.Manifiesto Ágil proyecto. En esta lista el cliente prioriza los objetivos
1.Nuestra principal prioridad es satisfacer al cliente a balanceando el valor que le aportan respecto a su coste y
través de la entrega temprana y continua de software de quedan repartidos en iteraciones y entregas. De manera
valor. regular el cliente puede maximizar la utilidad de lo que
2.Son bienvenidos los requisitos cambiantes, incluso se desarrolla y el retorno de inversión mediante la repla-
si llegan tarde al desarrollo. Los procesos ágiles se nificación de objetivos del producto, que realiza durante
doblegan al cambio como ventaja competitiva para el la iteración con vista a las siguientes iteraciones [5].
cliente.
3.Entregar con frecuencia software que funcione, en
periodos de un par de semanas hasta un par de meses,
con preferencia en los periodos breves.
4.Las personas del negocio y los desarrolladores
54
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
Las actividades que se llevan a cabo en Scrum son las Lo del Extreme del nombre de la metodología se debe
siguientes: al hecho de que esta emplea al extremo, las buenas
1.Planificación de la iteración (Sprint Planning). El prácticas de la ingeniería de software [6].
cliente presenta al equipo la lista de requisitos priorizada La XP no se aplica a todos los tipos de proyectos,
del producto o proyecto. El equipo examina la lista, siendo más apropiada para los proyectos con equipos
pregunta al cliente las dudas que le surgen, añade más pequeños y medianos, de dos a doce personas. Sin
condiciones de satisfacción y selecciona los objetivos/ embargo, algunos defienden su uso en grandes
requisitos más prioritarios que se compromete a proyectos, ya que al dividirlos en subproyectos inde-
completar en la iteración, de manera que puedan ser pendientes. Los proyectos largos deben ser partidos en
entregados si el cliente lo solicita. Se realiza en un una secuencia de mini proyectos de autocontenidos,
Timebox de cómo máximo 4 horas. con una duración de una a tres semanas [6].
2.Ejecución de la iteración (sprint). Un proyecto se Según Teles, la XP es un proceso de desarrollo de
ejecuta en bloques temporales cortos y fijos (iteraciones software apropiado para los siguientes proyectos:
de un mes natural y hasta de dos semanas). a)Con requisitos que son vagos y que cambian con
3.Reunión diaria de sincronización del equipo (Scrum frecuencia
Daily Meeting). Cada miembro del equipo inspecciona el b)Desarrollo de sistemas orientados a objetos
trabajo que el resto está realizando c)Equipos pequeños
4.Demostración de requisitos completados (Sprint d)Desarrollo incremental.
Review). Reunión informal donde el equipo presenta al Según Beck la XP está definida por medio de valores,
cliente los requisitos completados en la interacción. principios y prácticas. Los valores describen los objetivos
5.Retrospectiva (Sprint Retrospective). El equipo de largo plazo y definen criterios para obtener el éxito
analiza cómo ha sido su manera de trabajar durante la [7]. Los cinco valores son:
iteración, por qué está consiguiendo o no los objetivos 1.Simplicidad: Se simplifica el diseño para agilizar el
a que se comprometió al inicio de la iteración y por qué desarrollo y facilitar el mantenimiento.
el incremento de producto que acaba de demostrar al 2.Comunicación: Para los programadores el código
cliente era lo que él esperaba o no [5]. comunica mejor cuanto más simple sea. Si el código es
Los roles que se identifican en Scrum son: complejo hay que esforzarse para hacerlo inteligible.
1.Product Owner.- Cliente interno o externo a la El código autodocumentado es más fiable que los
organización. comentarios ya que éstos últimos pronto quedan
2.Scrum Master.- Facilitador o líder del equipo. desfasados con el código a medida que es modificado
3.Team.- Equipo de desarrolladores, es posible hacer 3.Retroalimentación: Al estar el cliente integrado en
scrum con 3 o hasta más de 200 personas. el proyecto, su opinión sobre el estado del proyecto se
Las herramientas que se identifican en scrum son: conoce en tiempo real.
1.Product Backlog. La lista de objetivos/requisitos. 4.Coraje: Una de ellas es siempre diseñar y programar
2.Sprint Backlog. Lista de tareas que el equipo para hoy y no para mañana
elabora en la reunión de planificación de la iteración 5.Respeto: Los miembros respetan su trabajo porque
(Sprint planning) [5]. siempre están luchando por la alta calidad en el producto
y buscando el diseño óptimo o más eficiente para la
2.3 XP solución a través de la refactorización del código.
Características de XP:
La metodología XP se considera una metodología leve 1.Desarrollo iterativo e incremental, pequeñas
de desarrollo de software. Esta es clasificada como mejoras, unas tras otras.
un sistema de prácticas que la comunidad de desa- 2.Pruebas unitarias continuas, frecuentemente
rrolladores de software viene evolucionando para repetidas y automatizadas,
resolver los problemas de entrega de software de 3.Programación en parejas, se recomienda que las
calidad rápidamente, y poder alcanzar las necesidades tareas de desarrollo se lleven a cabo por dos personas en
de negocio que siempre cambian. Esta surgió a partir un mismo puesto.
de ideas de Kent Beck y Ward Cunningham y que fue
utilizada por primera vez en un proyecto piloto en marzo
de 1996, del cual el propio Beck formaba parte.
55
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
4.Frecuente integración del equipo de programación El nombre Crystal deriva de la caracterización de los
con el cliente o usuario. Se recomienda que un re- proyectos según 2 dimensiones, tamaño y complejidad
presentante del cliente trabaje junto al equipo de (como en los minerales, color y dureza).
desarrollo. Por ejemplo, Clear es para equipos de hasta 8 personas,
5.Refactorización del código, es decir, reescribir Amarillo para equipos entre 10 – 20 miembros, Naranja
ciertas partes del código para aumentar su legibilidad y para 20 a 50 personas, rojo es para 50 a 100 personas [8].
mantenibilidad pero sin modificar su comportamiento. El código genético consiste en:
6.Propiedad del código compartida, en vez de dividir 1.Modelo de juegos cooperativos: Este modelo ve al
la responsabilidad en el desarrollo de cada módulo en desarrollo de software como una serie de partidos
grupos de trabajo distintos, este método promueve el que consisten en inventar y comunicar. Cada partido
que todo el personal pueda corregir y extender cualquier es diferente y tiene como objetivo entregar software
parte del proyecto. y prepararse para el siguiente juego. Esto permite al
7.Simplicidad en el código, es más sencillo hacer algo equipo trabajar concentrado y en forma efectiva con un
simple y tener un poco de trabajo extra para cambiarlo si objetivo claro cada vez.
se requiere, que realizar algo complicado y quizás nunca 2.Seleccionar prioridades: conjunto de prioridades y
utilizarlo [7]. principios que sirven de guía para la toma de decisiones:
Roles: a)Eficiencia en el desarrollo, para hacer que los proyectos
1.Cliente: Escribe las historias de usuario y las pruebas sean económicamente rentables.
funcionales para validar su implementación b)Seguridad en lo que se entrega.
2.Programador: Escribe las pruebas unitarias y c)Habitabilidad, hacer que todos los miembros del
produce el código del sistema equipo adopten y sigan las convenciones de trabajo es-
3.Tester: Ayuda al cliente a escribir las pruebas tablecidas por el equipo mismo.
funcionales. Ejecuta pruebas regularmente, difunde 3.Propiedades:
los resultados en el equipo y es responsable de las he- a)Frecuencia en las entregas: entregar al usuario fun-
rramientas de soporte para pruebas. cionalidad “usable” con una frecuencia de entre 2
4.Tracker: Es el encargado de seguimiento. semanas y no más de un mes.
Proporciona realimentación al equipo. Debe verificar el b)Comunicación: Promueve prácticas como el uso de
grado de acierto entre las estimaciones realizadas y el pizarrones, pizarras y espacios destinados a que todos
tiempo real dedicado, comunicando los resultados para (miembros del equipo y visitas) puedan ver claramente
mejorar futuras estimaciones el progreso del trabajo.
5.Entrenador: Responsable del proceso global. c)Crecimiento reflexivo: es necesario que el equipo lleve
Guía a los miembros del equipo para seguir el proceso a cabo reuniones periódicas de reflexión que permitan
correctamente. crecer y hacernos más eficientes.
6.Consultor: Es un miembro externo del equipo con Estas tres propiedades son “obligatorias” para Crystal
un conocimiento específico en algún tema necesario Clear, las siguientes pueden agregarse en la medida de
para el proyecto las necesidades de cada grupo y proyecto.
7.Gestor: Es el dueño de la tienda y el vínculo entre d)Seguridad personal: lograr que cada miembro del
clientes y programadores [7]. team pueda sentirse cómodo con el trabajo y el entorno.
e)Concentración: las entregas frecuentes permiten que
2.4 CRYSTAL CLEAR cada desarrollador puede enfocar de a un problema por
vez evitando dispersiones.
Crystal Clear no es una metodología en si misma sino f)Fácil acceso a usuarios clave: tratar de hacer que el
una familia de metodologías con un “código genético” usuario sea una parte más del equipo es fundamental
común. La idea es poder armar distintas metodologías para ir depurando errores de manera temprana.
para distintos tipos de proyectos. Cada proyecto y or- g)Entorno técnico con: I - Testing automatizado (in-
ganización usará este código genético para generar su corporación, por ejemplo, de UnitTest) - II. Integración
propia metodología [8]. frecuente (uso de herramientas específicas como Cruise
Control).
56
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
57
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
58
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
59
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
60
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
TABLA II
ANALISIS DE VARIABLES EN EL ESCENARIO DOS
61
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
TABLA III
ANALISIS DE VARIABLES EN EL ESCENARIO TRES
Las solicitudes de modificación de sistemas de e)Tamaño y tiempo de proyectos: La tabla IV, muestra los
información existentes, fueron de 2 por semestre, sin módulos identificados y tiempos de desarrollo para el
embargo, el tiempo ocupado para esta actividad era re- sistema de eventos deportivos.
lativamente igual al diseño de un sistema nuevo, ya que
la técnica de programación de los sistemas existentes TABLA IV
era variada, sin patrones de diseño y sin documentación. MODULOS Y TIEMPOS DE PROGRAMACIÓN PARA EL
a)Técnicas de programación: Para este escenario se SISTEMA DE EVENTOS DEPORTIVOS
descartó la posibilidad de crear los módulos desde cero,
así como utilizar un cms y se optó por la implementación
de un framework llamado Yii, porque el lenguaje elegido
fue Php.
b)Espacio de Trabajo: Se estableció una oficina con 7
mesas, un pizarrón y un proyector.
c)Numero de programadores y horarios: Se
reclutaron 2 practicantes y 2 residentes, con horario de
9 a 5 pm establecido para todos, en una segunda fase se
reclutaron 3 practicantes más.
d)Herramientas de apoyo: Se utilizó Netbeans
+ Plugins Yii Framework, MysqlWorkBeanch para
el modelado lógico, Subversión para el control de
versiones, entorno de desarrollo lamp en Linux / Centos,
jira educativo para la gestión del proyecto.
62
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
Para los módulos crud (créate, read, update, delete), TABLA VI MODULOS Y TIEMPOS DE PROGRAMACIÓN
se utilizó una herramienta de scaffolding incluida en PARA EL
el framework yii, su nombre es gii, la cual genera auto- SISTEMA DE CONTROL DEL SEGURO SOCIAL
máticamente los controllers, models, views y forms co- http://sass.itvillahermosa.edu.mx/
rrespondientes al crud [10].
Después de diseñar los módulos de un sistema, estos
son reutilizados en los próximos proyectos, aminorando
el tiempo de desarrollo.
f)Artefactos y documentación: Para este proyecto
se elaboraron: formato de requisitos, roles y actores,
casos de uso, modelo lógico E-R, diccionario de datos y
formatos de pruebas.
6 RESULTADOS
63
Programación Matemática y Software (2016) 8 (3): 52-64. ISSN: 2007-3283
REFERENCIAS
64