SCRUM Y CMMI NIVEL 2 EN GEOCUBA ORIENTE SUR

Ing. Daysel Labañino Griñan1, Msc. Nono Carballo Escalona 2

1 GEOCUBA, Cuba, ileana.antonia@medired.scu.sld.cu. San Fernando # 625 % San Félix y Calvario.
Santiago de Cuba.
2 GEOCUBA, Cuba, nono@cedai.com.cu Bravo Correoso 109 e/ 5 y 6 Santa Bárbara. Santiago de Cuba.

RESUMEN: Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y

puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará
durante un proyecto. El CMM - CMMI (Capability Maturity Model® Integration) es un modelo de
calidad del software que clasifica las empresas en niveles de madurez. En el presente documento
se presentan las características fundamentales de ambos y se realiza un análisis de como se
pueden combinar en una misma empresa para lograr el nivel de madurez 2 de CMMI. Además se
presenta el estado actual de la aplicación de SCRUM en Geocuba Oriente Sur.

Palabras Clave: SCRUM, CMMI, modelo, metodología

ABSTRACT: Scrum is a reference model that defines a set of practices and roles, and can be
taken as a starting point to define the development process to be executed during a project. The
CMM - CMMI (Capability Maturity Model ® Integration) is a software quality model that classifies
companies in maturity levels. This paper presents the key features of both and an analysis of how
they can be combined in the same company to achieve maturity level 2 of CMMI. It also presents
the current status of the Scrum implementation in Geocuba Oriente Sur.

KeyWords: SCRUM, CMMI, model, methodology

INTRODUCCIÓN

El desarrollo de software hoy en día es acelerado debido a la alta demanda del mercado y por
tal motivo deben utilizarse una serie de metodologías, modelos de calidad, procesos, que permitan
organizar, administrar y controlar todo el proceso de desarrollo del mismo. Es importante tener en
cuenta las características principales de cada Empresa o Grupo de desarrollo de software para
aplicar el proceso de desarrollo adecuado. Entre los aspectos a tener en cuenta están estructura,
cantidad de especialistas involucrados, velocidad de desarrollo de cada miembro del equipo de
desarrolladores y del grupo en general, entre otros.
El Grupo de Desarrollo de Software (GDS) de la Unidad de Desarrollo Científico Tecnológica
(UDCT) de GEOCUBA Oriente Sur (GEOCUBA OS) es un equipo pequeño y multidisciplinario que
usa SCRUM como proceso para el desarrollo de software y que busca obtener productos con
mejor calidad y organizar mejor el trabajo antes, durante y después del desarrollo del software.
Jakob Nielsen quien es una de las personas más respetadas en el ámbito mundial sobre
usabilidad en la web, planteó:
…Lanzar un software difícil de usar no sólo significa perder a sus mejores clientes, aquellos
dispuestos a usar sus servicios, sino que estos le advertirán a otros para que no utilicen su
software…
 Como se aprecia es muy importante el factor usabilidad y calidad del producto ya que son
fundamentales en el mercado del software para atraer a los mejores clientes y que estos se sientan
satisfechos con el producto final.
CMMI enseña el camino para alcanzar un nivel de madurez de la organización o un nivel de
capacidad de un área de proceso. Su propósito es proporcionar una guía para mejorar los
procesos de la organización y su habilidad para administrar el desarrollo, adquisición y
mantenimiento de productos y servicios.
CMMI es un modelo que trata sobre qué buenas prácticas mejoran una organización, mientras
que Scrum aporta un cómo implantar esas, u otras, buenas prácticas. CMMI dice, por ejemplo, qué
espera encontrar que se estime, pero no cómo estimar. CMMI dice que espera encontrar un ciclo
de vida, pero no cuál. Scrum aporta, entre otros, un cómo implantar un ciclo de vida iterativo e
incremental.
Con este trabajo se pretende combinar SCRUM con CMMI y adaptarlos al GDS con el objetivo
de mejorar los procesos para entregar productos y servicios de calidad. CMMI define “que” hacer y
SCRUM el “como”.

1. QUÉ ES SCRUM?
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede
tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un
proyecto.

Los artefactos generados son:

- Pila de producto (product backlog).
- Pila de la iteración (sprint backlog).
- Gráfico de avance (burndown graphic).
- Incremento (lo que se desarrolla en el sprint). (Carballo Escalona, 2012)

La pila del producto es un documento de alto nivel para todo el proyecto. Contiene amplias
descripciones de todas las características requeridas, funcionalidades en la wish-list, etcétera.
La pila de la iteración es un documento con gran detalle donde se describe el cómo el equipo va
a implementar los requisitos durante el siguiente sprint. Las tareas se rompen en horas con
ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota
en mayor detalle.
El gráfico de avance es mostrado públicamente en la que aparecen el número de tareas restantes
para el sprint actual, o el número de items en la pila de iteración.
Los roles principales en Scrum son el director de SCRUM (ScrumMaster), que mantiene los
procesos y trabaja de forma similar al director de proyecto, el dueño del producto (ProductOwner),
que representa a los interesados externos o internos (stakeholders), y el equipo de desarrollo.
(Palacio, 2008)
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes
natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un
resultado completo, un incremento de producto final que sea susceptible de ser entregado con el
mínimo esfuerzo al cliente cuando lo solicite.

Scrum permite la creación de equipos auto-organizados impulsando la co-localización de todos los

miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados
en el proyecto. (Palacio, 2008)
 2. QUÉ ES CMM - CMMI?
El CMM - CMMI (Capability Maturity Model® Integration) es un modelo de calidad del software que
clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los
procesos que se realizan para producir software.

Niveles CMM – CMMI

Los niveles CMM - CMMI son 5:

Inicial o Nivel 1: Este es el nivel en donde están todas las empresas que no tienen procesos. Los
presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar
durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del
proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.

Repetible o Nivel 2: Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La
principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado
durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto
en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son:
 Gestión de requisitos
 Planificación de proyectos
 Seguimiento y control de proyectos
 Gestión de proveedores
 Aseguramiento de la calidad
 Gestión de la configuración

Definido o Nivel 3: Alcanzar este nivel significa que la forma de desarrollar proyectos está
definida, que quiere decir que está establecida, documentada y que existen métricas para la
consecución de objetivos concretos.

Los procesos que hay que implantar para alcanzar este nivel son:
 Desarrollo de requisitos
 Solución técnica
 Integración del producto
 Verificación
 Validación
 Desarrollo y mejora de los procesos de la organización
 Definición de los procesos de la organización
 Planificación de la formación
 Gestión de riesgos
 Análisis y resolución de toma de decisiones

Este nivel proporciona muchos beneficios y por tal motivo muchas empresas al llegar a este nivel
no ven la necesidad de ir más allá porque sienten que sus necesidades están cubiertas.

Cuantitativamente Gestionado o Nivel 4: Los proyectos usan objetivos medibles para alcanzar
las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son:

 Gestión cuantitativa de proyectos

 Mejora de los procesos de la organización

Optimizado o Nivel 5: Los procesos de los proyectos y de la organización están orientados a la

mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante
métricas son identificadas, evaluadas y puestas en práctica.

Los procesos que hay que implantar para alcanzar este nivel son:

 Innovación organizacional
 Análisis y resolución de las causas

La implantación de un modelo de estas características es un proceso largo y costoso que puede

costar varios años de esfuerzo. (Gracia, CMM - CMMI. Calidad. Ingeniería de software, 2005)

3. CMM – CMMI Nivel 2.

El nivel 1 de CMMI es el nivel en el que están todas las empresas, ya que solo por el hecho de
existir como empresa de software están en el nivel 1.
Por lo tanto todas aquellas empresas que quieren mejorar su manera de trabajar para conseguir
mejores resultados quieren implantar CMM-CMMI hasta el nivel 2.
Lo que pretende el nivel 2 de CMM-CMMI es conseguir que en los proyectos de la organización
haya una gestión de los requisitos y que los procesos estén planeados, ejecutados, medidos y
controlados.

A continuación se explicarán cada una de las áreas de proceso de este nivel con un poco más de
detalle.

Gestión de Requisitos o Requerimientos

El objetivo de la gestión de requisitos es gestionar los requisitos de los elementos del proyecto y
sus componentes e identificar inconsistencias entre estos requisitos, el plan de proyectos y los
elementos de trabajo.
En este proceso se deben de gestionar todos los requisitos del proyecto, tanto los requisitos
técnicos como los requisitos no técnicos.
Estos requisitos han de ser revisados conjuntamente con la fuente de los mismos así como con las
personas que se encargarán del desarrollo posterior.

Planificación de proyectos
El objetivo de la planificación de proyectos es establecer y mantener planes que definen las
actividades del proyecto.
Las tareas que conlleva la planificación de proyectos son:

 Desarrollar un plan inicial del proyecto

 Establecer una relación adecuada con todas las personas involucradas en el proyecto
 Obtener compromiso con el plan
 Mantener el plan durante el desarrollo del proyecto

El plan incluye estimación de los elementos de trabajo y tareas, recursos necesarios, negociación
de compromisos, establecimiento de un calendario, e identificación y análisis de los posibles
riesgos que pueda tener el proyecto.
El plan de proyectos es una herramienta de trabajo viva que se debe de actualizar con mucha
frecuencia ya que los requisitos cambiarán, habrá que reestimar, habrá riesgos que desaparezcan
y otros que surjan nuevos, habrá que tomar acciones correctivas.

Monitorización y Control de proyectos

El objetivo de la monitorización y control de proyectos es proporcionar una compresión del estado
del proyecto para que se puedan tomar acciones correctivas cuando la ejecución de proyecto se
desvíe del plan.

El documento del plan de proyecto es la base para monitorizar las actividades, comunicar el estado
y tomar acciones correctivas. El progreso se determina comparando los actuales elementos de
trabajo: tareas, horas realizadas, coste y calendario actual, con los estimados en el plan de
proyecto. Una apropiada visibilidad nos permitirá tomar acciones correctivas antes de que el
trabajo real se desvíe mucho del plan.

Estas acciones que se toman, harán que se tenga que rehacer/ajustar nuestro plan de proyectos.

Medición y Análisis
El objetivo de la medición y el análisis es desarrollar y sostener una capacidad de medición que
sea usada para ayudar a las necesidades de información de la gerencia.
Los datos tomados para la medición deben estar alineados con los objetivos de la empresa para
proporcionar información útil a la misma.
Se ha de implantar un mecanismo de recogida de datos, almacenamiento y análisis de los mismos
de forma que las decisiones que se tomen puedan estar basadas en estos datos.
Este sistema tiene que permitir además:
 Planificación y estimación objetiva
 Comparar el rendimiento actual contra el rendimiento esperado en el plan
 Identificar y resolver problemas relacionados con los procesos
 Proporcionar una base para añadir métricas en procesos futuros

Aseguramiento de la calidad
El objetivo del aseguramiento de la calidad es proporcionar personas y gestión con el objetivo de
que los procesos y los elementos de trabajo cumplan los procesos.

Esto se consigue mediante:

 Evaluar objetivamente la ejecución de los procesos, los elementos de trabajo y servicios
contra las descripciones de procesos, estándares y procedimientos.
 Identificar y documentar los elementos no conformes.
 Proporcionar información a las personas que están usando los procesos y a los gestores,
de los resultados de las actividades del aseguramiento de la calidad.
 Asegurar de que los elementos no conformes son arreglados.
 Esta es un área de proceso clave, que a veces no se le da la suficiente importancia, pero
que sin ella no será posible implanta un modelo de calidad.

Gestión de la configuración
El objetivo de la gestión de la configuración es establecer y mantener la integridad de los
elementos de trabajo identificando, controlando y auditando dichos elementos.

Más concretamente mediante:

 La identificación de los elementos de trabajo que componen una línea base.
 Controlando los cambios de dichos elementos.
 Proporcionando formas de construir los elementos de trabajo a partir del sistema de control
de la configuración.
 Mantener la integridad de las líneas base.
 Proporcionar información precisa de los datos de la configuración a desarrolladores y
clientes. (Gracia, CMM - CMMI Nivel 2, 2005)

4. SCRUM y las áreas de proceso de CMMI Nivel 2.

Como se detalla anteriormente las áreas de proceso de CMMI Nivel 2 son 5:

 Gestión de requisitos
 Planificación de proyectos
 Monitorización y control de proyectos
 Medición y análisis
 Aseguramiento de la calidad
 Gestión de configuración

Ahora surge como interrogante ¿Cómo SCRUM desarrolla cada uno de los procesos de CMMI
Nivel 2?
El primero de los procesos (Gestión de requisitos) se lleva a cabo llenando la pila del producto
donde se describen cada una de las funcionalidades del sistema.
La pila del producto está compuesta por historias de usuarios las cuales son desarrolladas y
mantenidas por el dueño del producto y se debe mantener a nivel de negocio.
Las historias no son requerimientos, son expresiones cortas, fáciles de leer y entendibles por todos
que representan pequeños incrementos de funcionalidad desarrollables en días o semanas.
Además las historias no necesitan ser documentadas extensivamente.

Ejemplo de historia de usuario: “Como administrador del sistema debo poder adicionar militantes
para crear el listado de militantes del Comité de Base”

Además de la pila del producto en esta área aparece la pila de la iteración donde se describe con
gran detalle el como el equipo va a implementar los requisitos durante el próximo sprint y se sitúa
en el área de especificación de los requisitos de software necesarios para dar respuesta a las
funcionalidades esperadas por el cliente.

Los requisitos en SCRUM parten de la visión del resultado que se desea obtener; y evolucionan
durante el desarrollo.

El segundo y tercer proceso (Planificación, monitorización y control de proyectos) es

manejado por SCRUM en sus respectivas ceremonias o reuniones.

Estas reuniones son de 3 tipos y sus objetivos son diferentes:

 Planificación del sprint

Es una reunión conducida por el responsable del funcionamiento de Scrum, a la que deben asistir
el propietario del producto y el equipo al completo. La reunión comienza con la presentación del
propietario del producto, en la que expone los resultados que por orden de prioridad necesita.
El objetivo es que todo el equipo conozca las razones y los detalles con el nivel necesario para
poder estimar el trabajo necesario.
En esta reunión se determinan cuáles y cómo van a ser las funcionalidades que se van a
incorporar al producto con el próximo sprint.
En realidad esta reunión consiste en dos: En la primera, se decide qué elementos de la pila del
producto se van a desarrollar. En la segunda se desglosan éstos para determinar las tareas
necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo. La
planificación del sprint no debe durar más de un día. (Palacio, 2008)
  Revisión diaria del sprint
Dicha reunión no debe de pasar los 15 minutos de duración en la que todos los miembros del
equipo comentan las tareas en las que están trabajando, si se han encontrado o prevén
encontrarse con algún impedimento y actualizan sobre el sprint backlog las tareas ya terminadas o
los tiempos de trabajo que les quedan.

 Culminación del sprint

Reunión realizada al final del sprint en la que, el equipo presenta al propietario del producto,
clientes, usuarios, gestores… el incremento construido en el sprint, es decir, entrega el resultado
del desarrollo del sprint. Además genera retro-información entre todos los participantes para
preparar la pila del producto para el inicio del siguiente sprint.
Es una reunión informal donde el equipo no debe invertir más de una hora en prepararla, y lo que
se muestra es el resultado final: terminado, probado y operando en el entorno del cliente. (Palacio,
2008)

En el cuarto de los procesos (Medición y análisis) el cual está pensado en cubrir las necesidades
de la gerencia, es donde se especifican los datos necesarios para proporcionar información útil
para llevar a cabo la medición de manera satisfactoria.

Este sistema tiene que permitir además:

 Planificación y estimación objetiva
 Comparar el rendimiento actual contra el rendimiento esperado en el plan
 Identificar y resolver problemas relacionados con los procesos
 Proporcionar una base para añadir métricas en procesos futuros

SCRUM considera tres fondos de escala, o de zoom con los que se puede medir el trabajo:
 Desarrollo y gestión de la solución técnica.
 Gestión de proyecto.
 Gestión de la organización.
En el primero se puede medir, por ejemplo, complejidad y estructura del código de un programa, en
el segundo, el porcentaje de trabajo realizado, y en el tercero, también por ejemplo, el nivel de
satisfacción laboral.

A partir de las mediciones realizadas se pueden realizar una serie de análisis en correspondencia
con el buen fin del producto y el de los profesionales implicados.

De forma general las mediciones se realizan en correspondencia con el área específica, por
ejemplo: de la organización se mide rendimiento, eficiencia, satisfacción del cliente; del proyecto se
mide esfuerzo, costo y tamaño del mismo; por ultimo del desarrollo en si se mide disponibilidad,
complejidad del diseño y cantidad de fallos.

Es importante destacar que no se deben implantar procesos de medición tan sólo porque sí. Se
deben seleccionar una serie de métricas que sean adaptables a la empresa para poder
incorporarlas a la misma de la manera más fácil posible. Hay que tener en cuenta que cuantas
menos métricas es mejor pues medir el costoso, añade burocracia y el objetivo de SCRUM es
trabajar con la mejor relación valor-simplicidad.

Las métricas se pueden aplicar en el nivel de gestión de la organización, de gestión de los

proyectos o de construcción de la solución técnica.

El quinto de los procesos (Aseguramiento de la calidad) persigue entre otras cosas evaluar la
ejecución de los procesos, identificar, documentar y arreglar los elementos no conformes.

Esta área en ocasiones no se le da la suficiente importancia pero sin ella un modelo de calidad no
sería posible.

En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado,
la gestión de un proyecto Scrum se focaliza en definir cuáles son las características que debe tener
el producto a construir y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo
de desarrollo. Se busca que los equipos sean lo más efectivos y productivos que sea posible.

SCRUM exhibe una serie de beneficios que a la vez contribuyen a la calidad y la competitividad:
1. Gestión regular de las expectativas del cliente y basada en resultados tangibles.
2. Resultados anticipados.
3. Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado,
etc.
4. Gestión sistemática del Retorno de Inversión (ROI).
5. Mitigación sistemática de los riesgos del proyecto.
6. Productividad y calidad.
7. Alineamiento entre el cliente y el equipo de desarrollo.
8. Equipo motivado.

1. Gestión regular de las expectativas del cliente

El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y
cuando espera que esté completado. (Lista de requisitos priorizada y Demostración de los
resultados de proyecto en cada iteración).
2. Resultados anticipados.
El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté
finalizado por completo.
El cliente puede empezar a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un
producto al que sólo le faltan características poco relevantes, puede sacar al mercado un producto
antes que su competidor, puede hacer frente a urgencias o nuevas peticiones de clientes, etc.
(Priorización de requisitos por valor y coste)

3. Flexibilidad y adaptación.
De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los
cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto,
de la velocidad real de desarrollo, etc.
Al final de cada iteración el cliente puede aprovechar la parte de producto completada hasta ese
momento para hacer pruebas de concepto con usuarios o consumidores y tomar decisiones en
función del resultado obtenido. (Replanificación en el inicio de la iteración).

4. Retorno de Inversión.
De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de
obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto. (Priorización de
requisitos por valor).

5. Mitigación de riesgos.
Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en
una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de
manera anticipada. "Si hay que equivocarse o fallar, mejor hacerlo lo antes posible".
La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede
desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en
iteraciones. (Desarrollo iterativo e incremental).

6. Productividad y calidad.
De manera regular el equipo va mejorando y simplificando su forma de trabajar. (Mejora continua,
comunicación diaria del equipo, time boxing, equipo multidisciplinario, estimación de fuerza
conjunta, compromiso del equipo, demostración de resultados).

7. Alineamiento entre el cliente y el equipo de desarrollo.

Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al
negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El
producto se enriquece con las aportaciones de todos. En cada iteración el equipo y el cliente
trabajan juntos.

8. Equipo motivado.
Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas
y cuando pueden decidir organizar su trabajo. (Equipo auto-gestionado, Demostración).

El último de los procesos del Nivel 2 de CMMI (Gestión de Configuración) se define como el
conjunto de procesos destinados a asegurar la calidad de todo producto obtenido durante
cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a través del estricto
control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión
estable de cada elemento para toda persona involucrada en el citado desarrollo. Estos dos
elementos (control de cambios y control de versiones de todos los elementos del S.I.) facilitan
también el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en
cada etapa del desarrollo. La gestión de la configuración se realiza durante todas las fases del
desarrollo de un sistema de información, incluyendo el mantenimiento y control de cambios, una
vez realizada la puesta en producción. (Wikipedia. Gestión de la Configuración, 2013)

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y

administración de datos e información, organizados y listos para su uso posterior, generados para
cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes
categorías: personas, datos y actividades o técnicas de trabajo. (Wikipedia. Sistema de
Información, 2013)

Un sistema de control de versiones debe proporcionar:

- Mecanismo de almacenamiento de los elementos que deba gestionar (ej. archivos de texto,
imágenes, documentación...).
- Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales,
añadir, borrar, renombrar o mover elementos).
- Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos
(normalmente pudiendo volver o extraer un estado anterior del producto).
- Aunque no es estrictamente necesario, suele ser muy útil la generación de informes con los
cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo
de la versión de un conjunto de ficheros, etc. (Wikipedia. Control de Versiones, 2013)
Toda implantación de una metodología tiene un aspecto clave que muchas veces se olvida:
diseñar una adecuada política de gestión de la configuración que de soporte a las actividades de
desarrollo concurrente que el equipo realiza y las verificaciones de calidad que llevan a cabo los
testers.
Además otra cuestión relacionada con la gestión de la configuración, que resulta imprescindible, es
la necesidad de poder trazar nuestros binarios. Esta es una cuestión que a menudo se olvida y que
se hace especialmente importante en los momento de dificultad, cuando nuestro software está
sufriendo problemas: es sumamente difícil depurar un problema con garantías de éxito si no
contamos con la certeza de que en el entorno de depuración contamos con el código fuente, la
información de depuración (generalmente en forma de PDBs) y los binarios que se corresponden
con una determinada entrega.
Otro aspecto vital, sobre todo en las metodologías ágiles, pero cada vez más en cualquier proceso
de desarrollo, es la integración continua: construir nuestro software y ejecutar las pruebas
automatizadas del mismo cada vez que se realiza un check-in.

Cuando se plantea una política de gestión de fuentes, es una buena idea es enumerar los objetivos
que persigue. Los objetivos que persigo, en esta ocasión, por considerarles comunes a todo equipo
ágil son:

 Permitir que los desarrolladores trabajen de manera concurrente y en equipo.

 Permitir que los testers puedan estabilizar el software sin sufrir interferencias por parte de
los desarrolladores.
 Permitir el objetivo de Scrum de conseguir tras cada Sprint “un incremento de funcionalidad
potencialmente entregable”.
 Permitir la corrección de errores encontrados con el mínimo impacto.
 Establecer una nomenclatura para las diferentes ramas. (Geeks.ms, 2009)
 5. SCRUM EN GEOCUBA
A continuación se presenta una tabla donde se muestra como se aplica SCRUM en la Empresa
Geocuba Oriente Sur.

Gestión de Requisitos Se realiza siguiendo los criterios definidos por la metodología.

La planificación del sprint si no está presente el propietario del

producto en la reunión, entonces asiste una persona preparada
en las temáticas necesarias para ejercer como tal.

Planificación En el caso de la reunión diaria que se plantea en la metodología

Monitorización no se realiza. La revisión se hace semanal aunque durante la
Control de proyectos semana si existe algún inconveniente se convoca a un reunión
corta y se eliminan los posibles obstáculos presentes.
La duración de los sprints es de 2 semanas (15 días).
En la reunión final del sprint se presenta el incremento
construido.
En la medición se toman en cuenta: la complejidad y estructura
del código del programa, el porcentaje de trabajo realizado, y el
Medición y análisis nivel de satisfacción laboral.
A partir de los resultados obtenidos en la medición se realizan los
análisis pertinentes.
Se trabaja fundamentalmente en la confección de la
Aseguramiento de la calidad
documentación necesaria.
Se realiza buscando fundamentalmente que las versiones
obtenidas del producto cumplan con lo planificado y para esto se
Gestión de Configuración
lleva a cabo un estricto control de los cambios y la disponibilidad
constante de una versión estable del producto.

Como se puede observar en la Empresa se realizan una serie de cambios para aplicar SCRUM y
para obtener productos con calidad y debidamente documentados. Estos cambios fueron
realizados para adaptar la metodología sin realizar cambios bruscos en la estructura de trabajo
anteriormente implementada en la misma.

CMMI tienen una fortaleza importante, que a la vez es debilidad de las prácticas ágiles: se trata de
las prácticas genéricas, que están presentes en todas las áreas de procesos para que en todas se
consiga:

 Institucionalizar” las formas de trabajo

 Implantar prácticas de ingeniería de procesos.

La institucionalización se refiere a las ventajas de documentar los procedimientos que emplea la

empresa, y disponerlos de forma accesible a todos los interesados; a la necesidad de formar al
personal para que las conozca y sepa emplearlas en el trabajo.

CONCLUSIONES
Los modelos de calidad dicen el QUÉ hay qué hacer, pero no CÓMO hacerlo. CMMI prescribe
formas sobre CÓMO hacer la gestión de la configuración, la planificación del proyecto o la gestión
de los requisitos. También dice: hágalo como usted quiera, siempre y cuando alcance el fin del
área de proceso que venga al caso. Ya en el momento de certificarse es otra cosa porque
entonces hay que demostrarlo y pudiera complicarse.
Una gran empresa, o una pequeña que quiera asentar principios para dar el salto: de personas que
saben programar a empresa que sabe programar, debe incluir procesos para explicitar e
institucionalizar su saber hacer, independientemente de que sean procesos o agilidad.

BIBLIOGRAFIA

Comex Grupo Ibérica. (2008, Diciembre). Implantación del Modelo CMMI nivel 2. Retrieved from
[http://www.grupocomex.com/caso-exito-metodologia-cmmi.aspx?menu=3]

Carballo Escalona, M. (2012). Proceso de desarrollo ágil con Scrum y XP., (pp. 2-87). Santiago de
Cuba.

CMMI Institute. (2009, Mayo 13). CMMI and Scrum. Retrieved from [http://cmmiinstitute.com/cmmi-
getting-started/cmmi-compability/cmmi-and-agile/cmmi-and-scrum/]

Gracia, J. (26 de Noviembre de 2005). CMM - CMMI Nivel 2. Obtenido de

[http://www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php]

Gracia, J. (14 de Agosto de 2005). CMM - CMMI. Calidad. Ingeniería de software. Obtenido de
[http://www.ingenierosoftware.com/calidad/cmm-cmmi.php]

Palacio, J. (2008). Flexibilidad con Scrum. SafeCreative.

Potter, N., & Sakry, M. (2011). Implementing Scrum (Agile) and CMMI. Together.

Wikipedia. (Marzo de 2013). Capability Maturity Model Integration. Obtenido de

[http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration]

SÍNTESIS CURRICULAR DEL AUTOR

Daysel Labañino Griñan, nacido en Santiago de Cuba, Cuba, el 29 de Diciembre del año 1985.
Con un nivel educacional universitario, alcanzado en la carrera de Ingeniería en Ciencias
Informáticas en la Universidad de Ciencias Informáticas en el año 2009. Entre las principales
experiencias se encuentran los proyectos de desarrollo de la Infraestructura de Datos Espaciales
de la República de Cuba, en la aplicación para el control de flotas “Movilweb” y aplicaciones de
gestión empresarial como GESTIMER.
Con dirección particular en San Fernando # 625 entre San Félix y Calvario, municipio Santiago de
Cuba. Provincia Santiago de Cuba. Dirección electrónica: ileana.antonia@medired.scu.sld.cu