1. Proyecto Final de Master
Fredd Darwin Villarreal Escamilla
Adopción de una
metodología ágil para
proyectos de software
Caso: Cotemar empresa mexicana que
brinda servicios al sector petrolero.
Trabajo de tesis para optar al Grado de:
Master en Dirección Estratégica en
Ingeniería de Software
Tutor:
Dr. Saúl Domingo Soriano
Universidad Europea Miguel de Cervantes
México, Agosto 01, 2013

2. Resumen
La ingeniería de software se ha convertido en una disciplina imprescindible en las empresas de hoy
en día, una de las principales razones es debido a que la mayoría de los proyectos que impulsan la
competitividad en las empresas dependen en gran medida de las tecnologías de la información en
las que viene inmerso el uso de software.
Las metodologías ágiles han marcado en los últimos años una tendencia en su adopción en las
organizaciones dedicadas al desarrollo de software. Estudios recientes realizados por el Forrester
Research1 han demostrado que el 35% de personal de TI encuestado ha manifestado adoptar
métodos ágiles en sus organizaciones. La razón principal de este cambio en las tendencias se debe a
que se ha demostrado que el uso de métodos predictivos o tradicionales para desarrollar software en
ambientes donde las necesidades y la tecnología cambian muy rápido produce resultados caóticos.
Es necesario cambiar la forma en que se produce software, la relación existente entre la
competitividad de una organización y los métodos ágiles utilizados, está revelando hoy en día
mayores beneficios en las organizaciones. La competitividad de las empresas depende en gran
medida de la capacidad de innovación que se tenga para producir productos y servicios. La
innovación también se puede manifestar como el resultado de hacer las cosas de una forma
diferente, de adoptar nuevas formas de producir valor a los clientes.
En este estudio se presenta un análisis teórico de cinco metodologías ágiles más usadas en la
industria del software que ayudarán a establecer las bases conceptuales y a entender los principales
beneficios que aportan. Posteriormente se describe de manera detallada las actividades y las
experiencias de un equipo de personas que participaron en la adopción de la metodología ágil Scrum
en un proyecto piloto en la empresa Cotemar, una de las compañías líderes en la industria petrolera
en México, donde se experimentan escenarios de negocio que exigen imprescindiblemente una
capacidad de innovación, adaptación y velocidad de respuesta para entregar valor y calidad a los
clientes.
Al finalizar la adopción se presentan estadísticas de datos cuantitativos y cualitativos recogidos
durante el proyecto para determinar el impacto en la competitividad de la organización.
Palabras clave: Metodología, Productividad, Scrum, Competitividad, Ágil.
1
Fuente: http://www.forrester.com/aboutus, En Ingles, Leído el 20 de Julio de 2013.
i

3. Abstract
Software engineering has become an essential discipline in business today; one of the main reasons
is because most projects that support competitiveness in companies rely heavily on information
technologies where the use of software comes embedded.
The adoption of agile methodologies in the recent years has been a tangible trend in different
organizations where software is developed. A recent study by Forrester Research shows that 35% of
IT respondents said adopting agile methods in their organizations. The main reason for this change
is because it has been shown that the use of predictive or traditional methods in software
development where the rate of change is high generates chaotic results.
The relationship between the competitiveness and the use of agile methods is revealing ever greater
benefits in organizations today. The competitiveness of companies depends on the ability of
innovation to produce products or services. Innovation can also manifest as the result of doing
things in a different way, to adopt new ways of delivering value for its customers.
This research presents a theoretical analysis of five agile methodologies most used in the software
industry that will help to establish the conceptual basis and understand the key benefits. Afterwards
activities and experiences of a work team are described in the Scrum methodology adoption in a
pilot project in Cotemar Company, one of the leading companies in the oil industry in Mexico, where
innovation, adaptation and responsiveness to deliver value and quality to clients are essential in
business scenarios.
At the end of the adoption, the research presents statistics of quantitative and qualitative data
collected during the project to determine the impact in the competitiveness of the organization.
Keywords: Methodologies, Productivity, Scrum, Competitiveness, Agile
ii

4. Agradecimientos
Primeramente le doy gracias a mi Dios quien me brindo las oportunidades y la sabiduría para cumplir
con esta meta...
A los amores de mi vida Karina, Shirel y Adriel, por ser mi motivación...
A mis respetables padres ya que esta tesis es fruto de su esfuerzo por darme una educación...
A mis hermanos, amigos y colegas que siempre estuvieron apoyándome...
A todo el equipo TIC en Cotemar que colaboraron en este proyecto y que a través del trabajo duro,
coraje y respeto se lograron resultados increíbles.
iii

5. ÍNDICE
Capítulo 1: Introducción ................................................................................................................ 1
Capítulo 2: Objetivo, Hipótesis y Alcance ...................................................................................... 3
2.1
Objetivo General .................................................................................................................... 3
2.2
Objetivos Específicos .............................................................................................................. 3
2.3
Hipótesis de la Investigación .................................................................................................. 3
2.4
Alcance del Proyecto .............................................................................................................. 3
Capítulo 3: Estado del Arte ............................................................................................................ 4
3.1
Competitividad Organizacional .............................................................................................. 4
3.2
La Ingeniería de Software ....................................................................................................... 5
3.3
Metodologías Tradicionales ................................................................................................... 5
3.3.1 Modelo Cascada (Waterfall Model) ....................................................................................... 5
3.3.2 Modelo Espiral........................................................................................................................ 7
3.4
Metodologías Ágiles ............................................................................................................... 8
3.4.1 Manifiesto Ágil ....................................................................................................................... 8
3.4.2 Capacidad de Adaptación ....................................................................................................... 9
3.4.3 Productividad en Equipos de Trabajo ................................................................................... 10
3.4.4 Métodos Ágiles más Adoptados ........................................................................................... 11
3.4.4.1
Scrum ............................................................................................................................... 11
3.4.4.2
Extreme Programming ..................................................................................................... 16
3.4.4.3
Adaptive Software Development (ASD) ........................................................................... 22
3.4.4.4
Dynamic Systems Development Method (DSDM) ........................................................... 25
3.4.4.5
Feature Driven Development (FDD) ................................................................................. 29
3.5
Comparativa Tradicional vs Ágil ........................................................................................... 32
Capítulo 4: Metodología Ágil Propuesta ...................................................................................... 36
4.1
Proceso para la Gestión del Proyecto .................................................................................. 36
4.2
Roles Involucrados en Scrum ............................................................................................... 45
4.3
Definición de los Requerimientos (Product Backlog) ........................................................... 47
4.4
Planeación del Sprint (Sprint Planning) ................................................................................ 48
4.5
Definición Funcional ............................................................................................................. 49
4.6
Pruebas ................................................................................................................................. 50
4.7
Reuniones de Seguimiento ................................................................................................... 53
4.8
Liberación del Producto. ...................................................................................................... 54
4.9
Revisión del Sprint (Sprint Review) y Retrospectiva ............................................................. 56
4.10
Herramienta para Medición de la Productividad ................................................................. 57
4.11
Herramienta para Aseguramiento de la Calidad .................................................................. 58
Capítulo 5: Metodología de la Investigación ................................................................................ 60
5.1
Método de la Investigación. ................................................................................................. 60
5.2
Técnica de Recolección de Datos ......................................................................................... 60
5.3
Población y Muestra ............................................................................................................. 61
Capítulo 6: Análisis de Resultados ............................................................................................... 62
6.1
Cumplimiento de los Objetivos. ........................................................................................... 62
6.2
Métricas del Proyecto. ......................................................................................................... 63
6.3
Resistencia al Cambio ........................................................................................................... 68
6.4
Retorno de Inversión Asociado (ROI). .................................................................................. 69
6.5
Impacto en la Competitividad de la Organización. ............................................................... 70
Capítulo 7: Conclusiones y Recomendaciones ............................................................................. 72
7.1
Conclusiones......................................................................................................................... 72
7.2
Recomendaciones. ............................................................................................................... 75
Capítulo 8: Referencias Bibliográficas .......................................................................................... 77
iv

6. Anexo - Glosario de Términos ..................................................................................................... 79
v

7. ÍNDICE DE FIGURAS
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
3.1 Modelo Cascada ........................................................................................................ 5
3.2 Modelo Espiral .......................................................................................................... 7
3.3 Proceso Scrum ......................................................................................................... 12
3.4 Ciclo de Vida Extreme Programming .......................................................................... 16
3.5 Prácticas Extreme Programming ................................................................................ 19
3.6 Ciclo de Vida ASD .................................................................................................... 22
3.7 Ciclo de Vida DSDM .................................................................................................. 26
3.8 Ciclo de Vida FDD .................................................................................................... 30
3.9 Comparativa Cascada vs Ágil ..................................................................................... 33
3.10 Factores Impulsan la Adopción de una Metodología Ágil ............................................ 34
4.1 Resultado Evaluación Metodologías ............................................................................ 37
4.2 Criterios de Selección del Proyecto Piloto.................................................................... 38
4.3 Diagrama Estado Antes Adopción Scrum .................................................................... 39
4.4 Estructura Área Aplicaciones ..................................................................................... 39
4.5 Roles en Gestion de Proyectos antes de Adopción de Scrum ........................................ 40
4.6 Herramientas de Team Foundation Server 2010 .......................................................... 41
4.7 Tipos de Elementos de Trabajo (Work Items) ............................................................. 42
4.8 Listado de Queries ................................................................................................... 43
4.9 Roles para Gestión de un Proyecto con Scrum ............................................................ 45
4.10 Listado de Requerimientos Ordenados ..................................................................... 47
4.11 Definiendo un PBI en TFS ....................................................................................... 48
4.12 Sprint Backlog ........................................................................................................ 49
4.13 Definición Funcional del PBI .................................................................................... 50
4.14 Casos de Prueba .................................................................................................... 50
4.15 Definición de los pasos a seguir en un Test Case ....................................................... 51
4.16 Ejecución de Caso de Prueba .................................................................................. 52
4.17 Notificación de una Falla ......................................................................................... 52
4.18 Ciclo de Vida de un PBI en TFS................................................................................ 53
4.19 Ambientes de Liberación del Producto ...................................................................... 54
4.20 Lista de Builds generados ....................................................................................... 55
4.21 Control de Código Fuente en TFS............................................................................. 55
4.22 Estrategia de Ramas para Liberaciones de Producto .................................................. 56
4.23 Gráfica de Burndown de Seguimiento al Proyecto ...................................................... 57
4.24 Gráfica de Velocidad del Equipo ............................................................................... 58
4.25 Uso de Pruebas Unitarias en el Código Fuente .......................................................... 58
6.1 Burndown Sprint 1 ................................................................................................... 63
6.2 Burndown Sprint 2 ................................................................................................... 63
6.3 Burndown Sprint 3 ................................................................................................... 64
6.4 Productividad por Puntos de Esfuerzo ........................................................................ 65
6.5 Velocidad del Equipo ................................................................................................ 66
6.6 Progreso de las historias de usuario. .......................................................................... 66
6.7 Defectos Corregidos ................................................................................................. 67
6.8 Resumen de Builds ................................................................................................... 67
6.9 Evaluación ROI ........................................................................................................ 69
6.10 Gráfica de Impacto en la Competitividad en la Adopción de Scrum ............................. 71
7.1 Encuesta Adopción Scrum ......................................................................................... 75
vi

8. ÍNDICE DE TABLAS
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
3.1
4.1
4.2
4.3
4.4
4.5
5.1
5.2
6.1
6.2
6.3
6.4
6.5
Comparativa Tradicional vs Ágil .................................................................................. 33
Calificación Metodologías ........................................................................................... 36
Infraestructura de Servidores ..................................................................................... 40
Software Instalado .................................................................................................... 41
Cronograma del Caso de Estudio ................................................................................ 44
Cronograma del Proyecto Piloto. ................................................................................. 44
Variables a Medir ...................................................................................................... 60
Población y Muestra .................................................................................................. 61
Productividad de Valor Entregado ............................................................................... 65
% Errores Calidad Corregidos ..................................................................................... 67
Resultado de lo que se hizo Bien ................................................................................ 68
Resultado de lo que No se hizo bien ........................................................................... 68
Resultado de lo que se puede Mejorar ........................................................................ 68
vii

9. Capítulo 1
Introducción
1. INTRODUCCIÓN
Hoy por hoy las metodologías ágiles están marcando un cambio en la industria del software,
superando a las metodologías tradicionales y alcanzando un mayor índice de efectividad en el éxito
de proyectos. La velocidad para producir resultados, el desarrollo en la productividad de los equipos
de trabajo, su adaptabilidad ante los cambios y la generación de un valor son los beneficios
principales de estas metodologías.
Los beneficios de la adopción de una metodología ágil para impulsar el éxito de los proyectos de
software impactan de manera directa a la competitividad de una organización.
Podemos entender la competitividad como la capacidad de una empresa de distinguirse de sus
rivales en un determinado sector del mercado obteniendo una ventaja competitiva. Según Michael
Porter “La ventaja competitiva crece fundamentalmente a partir del valor que una empresa es capaz
de crear”2.
La capacidad para crear valor en los proyectos de software se ha vuelto un desafío en las
organizaciones actuales debido a la complejidad de la gestión de los requerimientos en un
ecosistema donde las necesidades y la tecnología cambian a una gran velocidad.
A pesar de todos los obstáculos y dificultades, vale la pena hacer el esfuerzo, vale la pena cambiar
ya que si continuamos con los mismos métodos y hábitos vamos a obtener el mismo resultado.
Uno de los mayores beneficios que las organizaciones obtienen cuando adoptan una metodología
ágil es que se reducen los tiempos de entrega de un producto (time to market) y esto es gracias a
una mayor productividad de los equipos de trabajo. Cuando el valor que se brinda a los clientes,
excede a los costos invertidos para producir el servicio o el producto, entonces se puede decir que se
obtuvo en base a una buena productividad y eficiencia. La productividad es según Porter “El valor
producido por la mano de obra”3
Para llevar a cabo este trabajo el departamento de Tecnologías de Información y Comunicaciones
(TIC) en conjunto con el negocio deciden llevar el proceso de adopción de la metodología ágil Scrum
seleccionando un proyecto piloto donde se obtendrán datos que nos ayuden a medir el impacto en la
competitividad de la empresa de acuerdo a las siguientes dimensiones:


Valor

Efectividad

3
Calidad

2
Productividad
Innovación
Fuente: Competitive Advantage, Michael E. Porter, The Free Press, 2004.
Fuente: The Competitive Advantage of Nations. Michael E. Porter, Harvard Business Review, 1990.
1

10. Por otro lado Cotemar es una empresa que se caracteriza por innovar y de marcar condiciones de
mercado mediante el uso de métodos y técnicas, buscando mantener un desempeño eficiente ante
sus clientes. La mayoría de los proyectos en la organización se apoyan en los sistemas de
información donde el uso de software es fundamental.
Desde su fundación en 1979 Cotemar se ha convertido en un proveedor clave para la industria
petrolera siendo su principal cliente Petróleos Mexicanos (Pemex) el séptimo productor de crudo
más grande en el mundo.
Cotemar en los últimos años ha crecido en infraestructura, gente, procesos y tecnología, es una
empresa que se ha caracterizado por ser innovadora y de marcar las condiciones del mercado, sin
embargo, los retos para adaptarse de manera más eficiente a los cambios y de anticiparse a ellos a
exigido buscar métodos más efectivos para conseguirlo.
El objetivo es impulsar la competitividad de la empresa mediante la entrega de productos de calidad
que agreguen un valor real al negocio y el incremento de la productividad en los equipos de trabajo.
2

11. Capítulo 2
Objetivo, Hipótesis y Alcance
2.1
OBJETIVO GENERAL
Describir el grado de impacto en la competitividad de Cotemar, empresa mexicana, al adoptar una
metodología ágil para la gestión de proyectos de software.
2.2
OBJETIVOS ESPECÍFICOS
1.
Analizar las metodologías ágiles más populares en la industria de software.
2.
Realizar una comparativa entre la metodología tradicional versus ágil.
3.
Identificar los beneficios de una metodología ágil aplicada a equipos de trabajo.
4.
Adoptar la metodología ágil Scrum a la gestión de un proyecto real.
5.
Describir el impacto en la productividad y competitividad después de adoptar Scrum.
2.3
HIPÓTESIS DE LA INVESTIGACIÓN
Con la adopción de la metodología ágil Scrum se busca incrementar la productividad de los equipos
de trabajo para entregar valor en menor tiempo y con mayor la calidad del producto y así alcanzar
una ventaja competitiva en la organización.
2.4
ALCANCE DEL PROYECTO
El alcance de este estudio abarca el análisis de un grupo de 5 metodologías ágiles las cuales fueron
seleccionadas de acuerdo a su éxito en la actualidad, siendo estas las siguientes:
1.
eXtreme Programming (XP).
2.
Scrum.
3.
4.
Adaptive Software Development (ASD).
Dynamic Systems Development Method (DSDM).
5.
Feature Driven Development (FDD).
Posteriormente se adoptará la metodología ágil Scrum en un proyecto piloto para medir los
beneficios en la empresa Cotemar. El proyecto seleccionado está relacionado a la planeación y
administración del presupuesto para los salarios de los empleados de Cotemar.
Finalmente se realizará un análisis de los resultados. Toda la información que comprometa las
estrategias y planes de la empresa donde se realizará el estudio será excluida del presente
documento por motivos de confidencialidad.
3

12. Capítulo 3
Estado del Arte
3.1
COMPETITIVIDAD ORGANIZACIONAL
La competitividad organizacional se puede entender como la capacidad que posee una empresa para
distinguirse de su competencia en un determinado sector.
Según Michael Porter en su artículo “The Competitive Advantage of Nations”4 indica que las
compañías alcanzan una ventaja competitiva, a través de acciones de innovación y se habla de una
innovación en un sentido más amplio, incluyendo nuevas tecnologías y nuevas formas de hacer las
cosas. La innovación puede manifestarse en el diseño de un nuevo producto, en un nuevo proceso
de producción o en una nueva forma de entrenamiento. La ventaja competitiva se posee durante el
tiempo en el que el competidor tarda en responder o competir ante esta nueva idea o innovación
creada.
La competitividad en una organización no solamente se puede basar en la aplicación de cambios
externos sino también en los internos. Los cambios internos son aquellos que son impulsados desde
el interior de la organización se trata de un nuevo modelo de fuerzas y de maneras de hacer las
cosas y que favorezca los recursos y las capacidades que posee la empresa para marcar una
diferencia frente a sus competidores. Mediante la innovación se pueden crear estos nuevos marcos
de competencia creando un nuevo valor para los clientes y dejando fuera a los competidores, a esto
se le conoce según Gary Hamel5 como innovación estratégica.
En este trabajo de investigación se busca innovar en los procesos relacionados al desarrollo de
software, dar un giro de 360 grados a la forma en las que se realizan las cosas y empezar a cambiar,
ya que la misma velocidad de cambio que imponen los clientes, la tecnología y otros factores
demandan optimizar nuestros procesos y generar un nuevo valor a la organización.
Para poder identificar y seleccionar este nuevo proceso hay que responder a las siguientes
preguntas: como incrementar la productividad de las personas que participan en los proyectos de
software?, como mejorar la calidad del producto final?, como entregar en menor tiempo valor al
negocio?
La respuesta a estas preguntas sin duda las encontraremos en la adopción de una nueva
metodología para construir software en el cual se basa este estudio, donde a través de nuevos
principios y valores se pueda colaborar de una forma eficiente. Para que una organización sea
competitiva requiere que su personal y equipos de trabajo sean productivos y flexibles ante los
cambios, por lo que, es primordial cambiar la mentalidad de los equipos de trabajo para adoptar una
nueva forma de hacer las cosas. El impacto en la productividad interna con este nuevo proceso
permitirá generar una ventaja competitiva que se puede percibir hacia el exterior, ya sea en la
entrega de servicios de mejor calidad al cliente o en la reducción de los costos en la ejecución de los
procesos de negocio.
4
5
Fuente: Porter, M. E. (1990). The Competitive Advantage of Nations. Harvard Business Review.
Fuente: http://en.wikipedia.org/wiki/Gary_Hamel, en ingles, leído el 8 de agosto 2013
4

13. 3.2
LA INGENIERÍA DE SOFTWARE
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan para desarrollar aplicaciones informáticas (software). La ingeniería de
software trata de sistematizar los procesos relacionados a la creación de software con el fin de
minimizar los riesgos del fracaso.
3.3
3.3.1
METODOLOGÍAS TRADICIONALES
MODELO CASCADA (WATERFALL MODEL)
El modelo en cascada es un proceso secuencial de etapas a seguir para el desarrollo de un producto,
este modelo se originó para usar en las industrias de construcción y manufactura, aunque la primera
6
descripción formal de este modelo fue en un artículo realizado por Winston W Royce en 1970 y a
consecuencia de no existir un modelo para el desarrollo de software se adoptó este como el primer
modelo. Las etapas de este proceso o ciclo de vida generalmente se conforman por las siguientes
fases:
Especificación de
Requerimientos
Diseño
Construcción
Integración
Pruebas
Despliegue
Mantenimiento
Figura 0.1 Modelo Cascada

ANÁLISIS DE REQUERIMIENTOS.
Esta etapa consiste en recabar la información relacionada a la solución deseada y a las necesidades
del usuario final. Este análisis incluye la definición del problema, las metas y un claro entendimiento
del negocio y sus reglas así como también identificar las funciones que el producto final debe
considerar. Algunas de las técnicas a utilizar para reunir esta información se basan en entrevistas,
observaciones, creación de prototipos, casos de usos y lluvia de ideas. Los resultados obtenidos son
plasmados en un documento conocido como Especificación de Requerimientos de Software (SRS), el
6
Fuente: Royce, Winston (1970),"Managing the Development of Large Software Systems", Technical
Papers of Western Electronic Show and Convention (WesCon), Los Angeles, USA.
5

14. cual servirá como entradas para la siguiente etapa del modelo. Los Requerimientos descritos en el
SRS deben considerar los funcionales, no funcionales y la descripción de comportamientos.

DISEÑO.
Esta etapa toma como inicio el SRS de la etapa anterior y en base a ello define como el software
debe ser construido. El diseño del software consiste en elaborar la arquitectura de software y
hardware necesaria, especificar parámetros de rendimiento y seguridad, seleccionar la plataforma y
el lenguaje de desarrollo, gestión de recursos y conectividad de las interfaces. También en esta
etapa se define el diseño de la interface de usuario, la navegación y el acceso al sistema. La salida
de este etapa es un documentos llamado Descripción del Diseño del Software (SDD) el cual servirá
de entrada a la siguiente etapa del modelo.

CONSTRUCCIÓN.
En esta etapa es donde inicia la construcción del producto tomando como base el SDD y el SRS de
las etapas anteriores. En esta etapa el trabajo es realizado por los desarrolladores, diseñadores de
interfaces y otros expertos usando como herramientas las plataformas y lenguajes definidos en el
SDD. La salida de esta etapa es el producto y componentes construidos.

INTEGRACIÓN.
En esta etapa se integran los módulos y/o componentes desarrollados en la etapa anterior y se
integran para tener el producto completo armado.

PRUEBAS.
En esta etapa se realizan las pruebas tanto para cada componente individual como al producto
integrado. Los casos de prueba son escritos en un documento los cuales evalúan si el sistema
cumple con la definición inicial de los requerimientos. Las pruebas pueden ser categorizadas en
pruebas unitarias, pruebas integrales y pruebas de aceptación. Cualquier defecto encontrado deberá
ser notificado a los desarrolladores para que sea reparada. En esta etapa se deberá generar el
manual de usuario.

DESPLIEGUE.
En esta etapa se prepara el sistema o producto para la instalación y uso en un ambiente productivo.
El resultado es un documento de instalación que define las configuraciones y pasos a ejecutar para
instalar el producto.

MANTENIMIENTO.
Esta ultima etapa del modelo, consiste en realizar ajustes, mejoras y reparación de defectos al
sistema o componentes individuales para mejorar el producto o el rendimiento del mismo.
Una característica de este modelo es que para continuar con la fase siguiente se debe completar la
fase predecesora y cuando surgen cambios en una de las fases es necesario retornar a las fases
anteriores para aplicar los nuevos cambios. Este tipo de modelo es efectivo cuando no suceden
cambios después de finalizar cada etapa de otra manera se tendrá que retornar, lo que produce el
efecto de proyectos que nunca se concluyen.
Otra característica de este modelo es que es obligatoria la generación de documentación extensa
con la finalidad de generar conocimiento al final de cada etapa, pero nuevamente si existe algún
6

15. cambio se deberá actualizar toda la documentación generada, lo que requiere invertir grandes
cantidades de tiempo en documentación que generalmente nadie lee.
En general este modelo de proceso para la construcción de software puede ser adecuado para
proyectos donde los requisitos no cambian y existe un alto grado de predictibilidad del producto
final.
En el área de tecnología de información donde actualmente se realiza este estudio los desarrollos de
software siguen este modelo y muchas de las problemáticas que se presentan en los proyectos son
los siguientes:
o
Proyectos que se concluyen pero al final el producto ya no coincide con el proceso
o
Después de varios meses sin ver resultados se pierde el interés por parte del cliente
o
Equipos de trabajo desmotivados
o
3.3.2
Proyectos que nunca se concluyen
o
Desconfianza para la realización de proyectos
MODELO ESPIRAL
El proceso espiral para desarrollo de software combina el modelo de cascada con el iterativo
generando prototipos, el cual es recomendable para proyectos largos, caros y complicados. Este
modelo fue definido por Barry Boehm7 en 1986 en el cual se realizan liberaciones incrementales del
producto en cada vuelta de la espiral.
Figura 0.2 Modelo Espiral
El modelo se basa en un refinamiento continuo del producto hasta obtener el producto final. Este
modelo sigue las mismas fases del modelo en cascada separados por la planeación, el análisis de
riesgo y la construcción del prototipo. El ciclo de vida de este modelo permite agregar nuevos
requerimientos al producto al final de cada vuelta y permite enfocarse a generar varias liberaciones
facilitando la transición al mantenimiento. El aspecto positivo más evidente es que permite involucrar
7
Fuente: Barry W. Boehm. (1986), “A spiral model of software development and enhancement”,
,TRW Defense Syst. Group, Redondo Beach, CA, USA
7

16. al usuario en el desarrollo del producto desde etapas tempranas. Usando este modelo
algunas
funcionalidades pueden ser entregadas al usuario de manera rápida a diferencia del modelo en
cascada. Sin embargo, el modelo espiral tiene algunas condiciones restrictivas a seguir:
o
Se requiere dedicar tiempo al análisis de riesgos en cada iteración
o
Se requiere de tiempo del desarrollador para minimizar los riesgos
o
Si los riesgos afectan al éxito del proyecto el modelo espiral no debe utilizarse.
3.4
METODOLOGÍAS ÁGILES
A diferencia del modelo en cascada (waterfall), las metodologías ágiles o conocidas también como
desarrollo de software ágile (ASD) son iterativas e incrementales, es decir, en cada iteración, a
través del ciclo de vida del proyecto se entrega una parcialidad funcional del producto. Poco a poco
se va desarrollando el producto durante cada iteración donde el cliente va participando activamente
agregando y cambiando las funcionalidades del producto hasta quedar satisfecho. Estos cambios de
mejora que se van presentando al iniciar cada iteración son la principal razón que dirige al equipo a
entregar un producto con mayor valor. En vez de tratar de seguir un proceso predictivo para obtener
un producto de calidad al final, ASD se enfoca a mantener prototipos de calidad durante cada
iteración del proyecto asegurando de esta manera que al final de proyecto se tenga un producto de
alta calidad que genere valor al cliente.
3.4.1
MANIFIESTO ÁGIL
En el año 2001 varios expertos que habían creado y probado las metodologías ágiles se reunieron
con el objetivo de acordar y definir valores y principios que ayudarían a los equipos de trabajo a
desarrollar software de manera eficiente, rápida y con adaptación ante los cambios, este documento
se conoce como el “Manifiesto Ágil”8 el cuál da el verdadero significado a la palabra ágil y consiste de
4 valores:

Individuos y sus interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensa

Colaboración con el cliente sobre negociaciones contractuales

Respuesta al cambio sobre seguir un plan
Estos valores conforman la médula principal de cualquier metodología ágil y marca la diferencia
sobre las metodologías tradicionales, por otro lado, estos valores dieron origen a 12 principios
ágiles9:
1.
La prioridad es satisfacer al cliente a través de la entrega temprana y continua de
software que aporte valor
2.
Dar la bienvenida a los cambios, aún que se den en el desarrollo. Se aprovechan los
cambios para dar una ventaja competitiva al cliente.
8
9
Fuente: http://www.agilemanifesto.org/, En Inglés, leído 24 de Mayo del 2013.
Fuente: http://agilemanifesto.org/principles.html, En Inglés, leído el 24 de Mayo del 2013.
8

17. 3.
Entregar software funcionando, de un par de semanas a un par de meses, con la
preferencia de un intervalo de corto tiempo.
4.
Personas del negocio y desarrolladores deben trabajar juntos diariamente en el proyecto.
5.
Construir el proyecto alrededor de individuos motivados. Dar el entorno y el apoyo que
necesitan y confiar en ellos para tener el trabajo terminado.
6.
El método más eficiente y efectivo de transmitir información dentro el equipo es una
plática cara a cara.
7.
El software que funciona es la medida primaria de progreso.
8.
Los
procesos
ágiles
promueven
un
desarrollo
sostenible.
Los
patrocinadores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
9.
La atención continua a los detalles técnicos y a los buenos diseños mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de los equipos auto organizados.
12. En intervalos regulares, el equipo reflexiona en cómo llegar a ser más efectivos realizando
ajustes a su comportamiento.
Estos principios describen una nueva mentalidad para abordar los proyectos de desarrollo de
software, ofreciendo una nueva solución que se basa en la simplicidad, en la interacción de personas
y en cómo podemos generar valor siendo eficientes.
Ágil significa entregar software que aporte valor, a través, de la colaboración cercana de un equipo
de trabajo que acepta cambios en los requerimientos con actitud y mentalidad positiva.
3.4.2
CAPACIDAD DE ADAPTACIÓN
El cuarto valor del manifiesto ágil se refiere a la capacidad de adaptación, es decir, que tan rápido
nos adaptamos a los cambios y que tan flexibles somos para aceptar y responder a esos cambios.
Para tener una buena capacidad de adaptación se debe tener conciencia de que el statu quo (estado
del momento actual) ya no es deseable, sin embargo, tomar conciencia de que lo que funcionó en el
pasado, ya no funciona, puede ser algo extremadamente difícil.
Según Mike Cohn uno de los grandes impulsores de las metodologías ágiles, en su libro “Succeeding
with Agile”10 menciona algunos de los grandes retos que los equipos de trabajo tienen que enfrentar
para conseguir una buena adaptación a los cambios:
1.
Aprender nuevas habilidades técnicas. Es común para los desarrolladores que participan en
un proceso de desarrollo ágil descubrir que mientras ellos son buenos en sus trabajos no lo
son siendo ágiles. Ellos requieren desarrollar habilidades que antes no necesitaban, por
ejemplo, los programadores necesitarán aprender a evolucionar el diseño de un sistema, es
decir, colaborar para mejorar las ideas. Los testers o los de pruebas necesitarán aprender a
generar casos de prueba de valor sin generar tanta documentación y aprendiendo a
automatizar las pruebas.
2.
Aprender a pensar y trabajar como un equipo. Muchos de nosotros hemos disfrutado
trabajar solos, en nuestro cubículo y con nuestros audífonos a todo volumen y poca
interacción con el equipo, “Tu desarrolla tu parte y yo haré la mía, nos hablaremos cuando
integremos las partes”, los equipos ágiles no deben pensar en términos de tus tareas o mis
10
Fuente: Mike Cohn. 2010, “Succeeding with Agile”, Addison-Wesley
9

18. tareas sino en nuestras tareas. Adoptar esta mentalidad crea un sentido de responsabilidad
compartida que elevará los niveles de colaboración en el equipo.
3.
Aprender a cómo crear software funcional dentro de periodos cortos de tiempo definidos. El
tiempo definido para las iteraciones representa un reto para el equipo ya que es una nueva
forma de trabajar y dar resultados, dentro de este tiempo se debe entregar software
funcionando al cliente y el equipo debe enfocarse y comprometerse a terminar lo pactado.
Los miembros de equipo deben aprender a remover obstáculos que puedan afectar el
avance de las tareas.
Las personas que logren aprender estas habilidades podrán incorporarse fácilmente a los procesos
ágiles de desarrollo de software y tendrán una gran capacidad de adaptación que les ayudará a
colaborar con los equipos de trabajo y ser ágiles en el proceso.
3.4.3
PRODUCTIVIDAD EN EQUIPOS DE TRABAJO
Podemos entender la productividad como la manera eficiente y efectiva en la que usamos los
recursos tales como el tiempo, gente, información, tecnologías mediante los cuales podemos generar
un valor. Las organizaciones deben prestar mayor atención a los temas de productividad, por
ejemplo implementando en sus modelos de trabajo técnicas para responder más rápido a los
inevitables cambios. Es notable remarcar que dos de los métodos ágiles mayor usados, conocidos
como Scrum y Extreme Programming se originaron de la urgencia de solucionar el problema de la
productividad en los equipos de trabajo. Craig Jarrow autor del popular blog Time Management
Ninja11, recomienda 9 formas para maximizar la productividad de los equipos de trabajo:
1.
Eliminar Reuniones Repetitivas. Cuantas veces involucramos a todos los miembros del
equipo a reuniones que no son importantes para ellos, que solo les quita tiempo que
pueden invertir en otras actividades donde produzcan más resultados, hay que darles
también el derecho a ellos de declinar o no aceptar ir a esas reuniones.
2.
Liderar con el ejemplo. Como líder tus acciones deben ser el parámetro de productividad a
seguir, debes ser un buen ejemplo para el equipo, ya que estas acciones son las que
motivan para seguir una forma de trabajo.
3.
Definir canales de comunicación. La mala comunicación es uno de los factores que reducen
la productividad de los equipos. Se deben establecer de forma clara las expectativas y los
canales de comunicación.
4.
Permitir al equipo cuando sea apropiado definir el momento y el lugar para hacer el trabajo.
Con las herramientas y el internet de hoy en día, lo menos que nos debe preocupar es
cuando y donde sino que el trabajo se haga. Los equipos virtuales son el futuro de la
productividad.
5.
Remover obstáculos. Resolver cualquier impedimento o problema que interrumpa el avance
de las actividades e impida terminar el trabajo en tiempo debe ser uno de los principales
objetivos de un líder de equipo.
6.
Proveer de las herramientas apropiadas. Un buen líder debe facilitar de las herramientas
adecuadas para que el equipo pueda desempeñar su trabajo de manera efectiva.
11
Fuente: http://timemanagementninja.com, en Ingles, Leído el 9 de agosto 2013
10

19. 7.
Proveer de un buen espacio laboral. El lugar de trabajo es un elemento importante a
considerar, trabajar en cubículos cerrados, con mala iluminación, sillas incomodas es un
factor que impacta negativamente la productividad de los equipos de trabajo.
8.
Permite que tu equipo tome decisiones. Un equipo inteligente y auto dirigido es aquel
donde los miembros toman decisiones y participan, de otra manera, si el líder tiene que
decidir todo entonces se convierte en un cuello de botella afectando la productividad del
equipo, por otro lado, el líder debe confiar en las decisiones que tomen los miembros del
equipo y darles la confianza.
9.
Quitarse del camino. Una vez que hayas removido todos los obstáculos para el equipo, solo
queda uno por remover y ese eres tú mismo. Habrás encendido la productividad del equipo
cuando ellos sean auto suficientes.
Estas son 9 formas que podemos aplicar en nuestros equipos de trabajo para potenciar su
productividad pero también estas recomendaciones son de gran ayuda cuando adoptamos
una metodología ágil.
3.4.4
MÉTODOS ÁGILES MÁS ADOPTADOS
3.4.4.1
SCRUM
HISTORIA
Ken Schwaber y Jeff Sutherland
presentaron conjuntamente por primera vez Scrum en la
12
conferencia OOPSLA en 1995 . Scrum es un marco de trabajo para el desarrollo y el mantenimiento
de productos complejos que ha sido utilizado desde los años 90, en el cual las personas pueden
afrontar complejos problemas adaptativos, a la vez que entregan productos del máximo valor posible
de forma productiva y creativa. Scrum es:

Ligero

Fácil de entender

Extremadamente difícil de llegar a dominar
El marco de trabajo de Scrum consiste en los equipos Scrum y en sus roles, eventos, artefactos y
reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es
esencial para el éxito de Scrum y para su uso.
12
Fuente:
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20%20ES.pdf, en Español, Leído el 9 de agosto 2013
11

20. Figura 0.3 Proceso Scrum
Scrum se fundamenta en la teoría empírica de control de procesos o empirismo. El empirismo
asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que
se conoce. Scrum emplea una aproximación iterativa e incremental para optimizar la predictibilidad y
controlar el riesgo.
Tres pilares soportan toda implementación de control empírico de procesos: transparencia,
inspección y adaptación.

Transparencia.
Se refiere a que los aspectos significativos del proceso deben ser claramente entendidos
por los responsables del resultado, es decir, los responsables deben de compartir un
lenguaje común para referirse al proceso.

Inspección.
Todo el equipo en Scrum debe inspeccionar frecuentemente los artefactos y monitorear el
avance para detectar variaciones no deseables.

Adaptación.
Si un inspector detecta que algún aspecto del proceso se desvía de los límites aceptables, y
que el producto resultante no será aceptable, el proceso o el material que están siendo
procesados deberán ser ajustados para minimizar desviaciones mayores.
ROLES.
El equipo Scrum consiste en un dueño del producto (Product Owner), El equipo de Desarrollo
(Development Team), y un Scrum Master. En Scrum los equipos deben ser auto-organizados y
multifuncionales. Los equipos auto-organizados toman decisiones y eligen la mejor forma para llevar
a cabo su trabajo en lugar de ser dirigidos por otros externos al equipo. Los equipos multifuncionales
tienen todas las competencias necesarias para llevar a cabo el trabajo. Este modelo de trabajo está
diseñado para optimizar la flexibilidad, la creatividad y la productividad.
Los equipos en Scrum realizan entregas incrementales del producto, asegurando que se tiene una
versión potencialmente útil y funcional del producto.
12

21. 
Dueño del Producto (Product Owner).
Es el responsable de maximizar el valor del producto y del trabajo del equipo de desarrollo.
El Product Owner es el único responsable de gestionar el Product Backlog o listado de
Requerimientos funcionales. Esta gestión incluye:
o
Describir de manera clara los requerimientos.
o
Definir el valor de negocio y la prioridad de cada requerimiento para que el equipo de
desarrollo conozca que requerimientos atender primero.
o
Asegurar que el equipo de desarrollo entiende de manera clara cada requerimiento.
El dueño del producto es una persona no un comité, todas las decisiones y definiciones que
tome el Product Owner en base al producto deben ser respetadas por todos.

Equipo de Desarrollo (Development Team).
Son los profesionales que tienen la responsabilidad de entregar un incremento del producto
“Hecho”, potencialmente utilizable, al final de cada Sprint.
Al equipo desarrollo se le otorga el poder por parte de la organización para que pueda
gestionar y llevar a cabo su trabajo, esta sinergia produce eficiencia y efectividad en el
equipo. Los equipos de desarrollo deben cumplir con las siguientes características:
o
Son Multifuncionales.
o

Son auto-organizados.
o
No contienen sub-equipos.
Scrum Master.
Es el responsable de que el proceso de Scrum se entienda y que se aplican las reglas
correctamente. Es un líder servil al servicio del equipo Scrum.
o
Servicios del Scrum Master al Product Owner
a)
b)
Comunicar la visión y objetivos del Product Backlog
c)
Enseñar a crear las historias de usuario
d)
Entender el proceso empírico y de adaptación.
e)
o
Encontrar técnicas para gestionar el Product Backlog
Facilitar los eventos de Scrum
Servicios del Scrum Master al Equipo de Desarrollo
a)
Entrenar al equipo de desarrollo en ser auto-organizados y multifuncionales.
b)
Formar y liderar a los equipos de desarrollo a crear productos de alto valor.
c)
Eliminar impedimentos que afecten el avance del equipo.
d)
Facilitar los eventos de Scrum
e)
Entrenar al equipo a entender Scrum.
Eventos.
En Scrum existen eventos prescritos, con el fin de crear regularidad y minimizar la necesidad de
reuniones no definidas en Scrum. Se utilizan eventos en la forma de bloques de tiempo (timeboxes), de modo que todos tienen una duración máxima. Esto asegura que se emplee una cantidad
apropiada de tiempo en la planificación, de forma que no se admita desperdicio en este proceso de
planificación.
13

22. Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de
Scrum constituye una oportunidad para la inspección y adaptación de algún aspecto. Estos eventos
están específicamente diseñados para habilitar la vital transparencia e inspección. La falta de alguno
de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad
perdida para inspeccionar y adaptarse.

Sprint.
El corazón de Scrum es el Sprint, un bloque de tiempo (time-box) de un mes o menos
durante el cual se crea un incremento de producto “Hecho”, utilizable y potencialmente
entregable.
Los Sprints contienen y consisten en la Reunión de Planificación del Sprint (Sprint Planning
Meeting), los Scrums Diarios (Daily Scrum), el trabajo de desarrollo, la Revisión del Sprint
(Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective). Los Sprints habilitan la
predictibilidad al asegurar la inspección y adaptación del progreso hacia un objetivo, al
menos en cada mes de calendario. Los Sprints también limitan el riesgo al incurrido en el
coste de un mes de calendario.
Los Sprints contienen y consisten en:

Reunión de Planificación del Sprint (Sprint Planning Metting)
Es en esta reunión de no más de 8 horas se realiza el plan de que es lo que se va a
entregar al finalizar el sprint. La reunión se divide en 2 partes, en la primera parte el
Product Owner presenta el Product Backlog ordenado y explica cada elemento al equipo de
desarrollo posteriormente el equipo de desarrollo tendrá la responsabilidad de seleccionar
los elementos del Product Backlog que desean integrar en el Sprint, una vez hecho esto el
equipo Scrum tendrá que elaborar el Objetivo del Sprint la cual es una meta a alcanzar al
finalizar el sprint. En la segunda parte de la reunión el Equipo de desarrollo define como
construir el producto y determina el tiempo necesario para cada tarea, los tiempos no
deben ser mayores a un día. Los elementos seleccionados y el plan de tiempo para
construirlos recibe el nombre de Sprint Backlog. Si el equipo de desarrollo determina que
tiene demasiado trabajo o poco trabajo para realizar en el Sprint podrá renegociar con el
Product Owner para realizar los ajustes necesarios al Sprint Backlog.

Scrum Diario (Daily Scrum)
Es una reunión que tiene lugar todos los días con una duración no mayor a 15 minutos, la
idea principal es que el equipo de desarrollo presente las actividades realizadas desde el
último Daily Scrum y haciendo una predicción de lo que realizara antes del siguiente.
Básicamente en esta reunión el equipo de desarrollo responde a tres preguntas:
1.
Que se trabajo el día de hoy?
2.
Que actividades se planean realizar el dia de mañana?
3.
Existe algún impedimento que afecte el avande?
En el Daily Scrum el Equipo de Desarrollo explica al Product Owner y al Scrum Master
como pretende organizarse para lograr el objetivo del Sprint. El Scrum Master es el
responsable de organizar estas reuniones y de aplicar la regla de los 15 minutos, sin
embargo el Equipo de Desarrollo es el responsable de dirigirlas. Esta reunión no es de
seguimiento ni tampoco de reporte de estado.
14

23. El principal beneficio de esta reunión es que mantiene comunicados a todo el equipo Scrum
y permite la detección temprana de impedimentos. Constituye una reunión clave de
inspección y adaptación.

Revisión del Sprint (Sprint Review)
En esta reunión se realiza un inspección sobre el incremento del producto hecho y adaptar
el Product Backlog en caso de ser necesario. En esta reunión participa todo el Equipo Scrum
donde el Product Owner identifique lo que se terminó y lo que no, el Equipo de Desarrollo
habla de los problemas que se tuvieron y como se resolvieron además de que presenta el
incremento del producto hecho. Todo el grupo colabora con comentarios de lo que puede
realizarse en el siguiente Sprint.

Retrospectiva del Sprint (Sprint Retrospective)
En esta reunión el equipo Scrum se examina así mismo y crea un plan de mejoras para
aplicarse en el siguiente Sprint. En esta reunión se examinan a las personas, herramientas y
procesos y se busca responder básicamente a tres preguntas:
1.
Que hicimos bien en el Sprint?
2.
Que no se hizo bien?
3.
Que podemos hacer mejor en el siguiente Sprint?
El Scrum Master debe alentar el equipo, para que mejore en el proceso Scrum, su procesos
de desarrollo y sus prácticas para hacerlos más efectivos. Al final de esta reunión el Equipo
Scrum debe haber identificado mejoras para aplicar en el siguiente Sprint.
Artefactos de Scrum.
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para
proporcionar transparencia y oportunidades para la inspección y adaptación.

Product Backlog
Es una lista ordenada de todos los requerimientos funcionales del producto. El Product
Owner es el responsable de elaborar este documento. Un Product Backlog nunca es
estático, durante el proceso de construcción en cada incremento la lista puede ir cambiando
y evolucionando para tener un producto más adecuado, competitivo y útil. El product
Backlog tiene como atributos su descripción, su priorización y el valor de negocio que
aporta. Los cambios en los requerimientos de negocio, las condiciones de mercado o la
tecnología podrían generar cambios sobre el Product Backlog.
La definición a detalle de cada elemento del Product Backlog se lleva a tiempo parcial
dentro el Sprint entre el Product Owner y el Equipo de Desarrollo. El equipo de desarrollo es
el responsable de proporcionar todas las estimaciones para cada elemento de la lista.

Seguimiento del Avance (Burndown)
En cualquier momento durante el Sprint es posible sumar las horas del trabajo total
restante para alcanzar el objetivo y medir el avance. Existen varias tendencias de trabajo
consumido como el Burndown Chart que pueden ayudar a predecir el progreso.

Sprint Backlog
15

24. Es el conjunto de elementos seleccionados del Product Backlog para el Sprint, más un plan
para entregar un incremento del producto. Es una predicción hecha por el Equipo de
Desarrollo acerca de que funcionalidad formara parte del incremento del producto y del
trabajo necesario para realizarlo. En el Sprint Backlog el Equipo de Desarrollo detalla cada
tarea necesaria para construir el incremento y le asigna el tiempo necesario. Esta lista y su
detalle pueden ir cambiando durante la ejecución del Sprint si el Equipo de Desarrollo lo
considera así. Es importante que el Equipo de Desarrollo vaya actualizando su avances
sobre las tareas realizadas ya que esto actualiza la estimación de trabajo restante.
3.4.4.2
EXTREME PROGRAMMING
HISTORIA
El origen Extreme Programming (XP) inicio en los 90’s cuando Kent Beck trabajando en un proyecto
para Chrysler buscaba una mejor forma de crear software 13. Una de las características principales de
este método que lo diferencia del modelo en cascada es que se basa en la adaptabilidad en lugar de
la predictibilidad. La razón de este enfoque se basa en que el desarrollo de software es un proceso
muy fluido y cambiante, donde no se puede prever la totalidad de los requisitos desde el principio ya
que estos van cambiando durante el proyecto. Por lo tanto el desarrollo de software requiere de una
metodología que sea capaz de adaptarse a los constantes cambios de los requerimientos.
CICLO DE VIDA.
El enfoque de esta metodología es generar el más alto valor al cliente de la manera más rápida
posible. A diferencia del modelo en cascada que tiene que seguir de manera secuencial las etapas de
planeación, análisis y diseño, en XP los programadores hacen todas estas actividades en cada
iteración del desarrollo.
La metodología Extreme Programming o XP inicia con la planeación y todas las iteraciones consisten
de cuatro fases básicas: Planear, Diseñar, Codificar y Probar. Los valores primordiales para llevar
este ciclo de vida son la comunicación continua entre el cliente y los programadores, la simplicidad
para diseñar la solución, la retroalimentación de las pruebas de aceptación y el coraje para enfrentar
los problemas proactivamente y para aceptar los cambios en la fase de desarrollo.
Figura 0.4 Ciclo de Vida Extreme Programming
13
Fuente: http://en.wikipedia.org/wiki/Extreme_programming#Activities, En Inglés, Leído el 10 de
Agosto 2013.
16

25. 
PLAN DE LIBERACIÓN (RELEASE PLANNING).
En esta etapa se organiza la reunión de Planning Game donde el cliente se reúne con el
equipo de desarrollo para presentarle los requerimientos funcionales o historias de usuario.
El equipo de desarrollo organiza las historias de usuario en iteraciones y estima el esfuerzo
necesario para cada una de ellas. Con el esfuerzo estimado y el conocimiento que se tiene
de la importancia de cada funcionalidad el cliente elabora un plan de liberación inicial el
cual será la base para la planeación de las iteraciones.

PLANEACIÓN DE LA ITERACIÓN (ITERATION PLANNING).
En esta etapa se organiza una reunión para elaborar el plan de las tareas que el equipo de
desarrollo necesita realizar para entregar un incremento del producto al final de la iteración.
Para ello el cliente selecciona las historias de usuario del plan de liberación que desea sean
incluidas en la iteración, posteriormente el equipo de desarrollo divide cada historia en
tareas a realizar y le asigna un tiempo estimado para llevarlas a cabo. Con esto se consigue
un plan detallado a nivel técnico del trabajo que el equipo de desarrollo va a realizar

DISEÑO (DESIGNING).
La iteración en XP inicia con el diseño, un buen diseño es lo que te permite realizar cambios
de manera simple al software sin afectar la funcionalidad. La idea principal del diseño
incremental es la simplicidad, es decir, hacer solo lo necesario sin agregar funcionalidad
extra que no se necesita en ese momento, emplear buenas prácticas para el diseño de las
clases, como estándares de nombres y usar las tarjetas de responsabilidades y colaboración
de clases (CRC), esto permite que los miembros del equipo contribuyan con ideas y
considerarlas en el diseño. No es una actividad que se realiza una sola vez en el proyecto,
sino que es una actividad de todo el tiempo. El equipo de desarrollo se reúne en sesiones
rápidas de diseño antes de la iteración y revisiones de diseño durante la iteración a través
de la refactorización de código. Extreme Programming emplea técnicas como la integración
continua de código, las pruebas unitarias y la refactorización de código.

CODIFICACIÓN (CODING)
Uno de los elementos más importantes en un proceso de desarrollo de software es el
código, sin él no existirá un producto funcional. En XP Codificar es una forma de
aprendizaje, es tener un pensamiento y luego probarlo para saber si fue una buena idea.
La programación en pares (Pair Programming) por dos programadores trabajando juntos en
un solo equipo, permite la generación de código de alta calidad. El código da la oportunidad
de comunicar de una forma clara y consistente una idea, esta comunicación se transforma
en aprendizaje y reduce la probabilidad de malas interpretaciones.

DESARROLLO GUIADO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT)
XP incluye una serie de prácticas para pruebas. Cada miembro del Equipo, Desarrolladores,
Clientes y Testers realizan su propia contribución para obtener un producto de calidad.
Primero los Desarrolladores a través del desarrollo orientado a pruebas (test-driven
development) proveen la primera línea de defensa, realizando pruebas unitarias
automatizadas de cada parte construida, asegurando que el código tecleado no presenta
ninguna falla técnica. Posteriormente el Cliente realiza las pruebas funcionales y de lógica
del producto, verificando que el producto realiza lo que se espera que haga y finalmente los
Testers mediante pruebas de exploración buscan fallas. Cuando el Tester identifica la falla,
17

26. el equipo debe realizar un análisis de causa raíz y considerar como mejorar el proceso para
prevenir fallas similares en el futuro. Los Testers también son responsables de explorar las
características no funcionales del software como son el rendimiento y la estabilidad. Cuando
las fallas son corregidas los Desarrolladores deben ejecutar las pruebas automatizadas para
asegurarse de que no ocurren nuevamente. La idea principal de las pruebas en XP es
realizar pruebas mientras se está codificando, esta es la forma más rápida de generar un
producto de calidad.

PRUEBAS DE ACEPTACIÓN (ACCEPTANCE TEST)
Las pruebas de aceptación son escenarios de prueba que define el cliente para cada historia
de usuario, lo cual representa un resultado o comportamiento esperado del sistema. Los
clientes son los responsables de validar que las pruebas de aceptación fueron exitosas. Una
historia de usuario no se considera terminada si alguna de sus pruebas de aceptación no
paso. Es responsabilidad del equipo de desarrollo calendarizar el tiempo en cada iteración
para la corrección de fallas. Es recomendable que estas pruebas de aceptación sean
automatizadas para que sean realizadas de manera más ágil y frecuente.

ESCUCHAR (LISTENING)
Los Desarrolladores deben estar preparados para escuchar a la gente del negocio o al
Cliente, para entender las necesidades y los requerimientos. La actividad de escuchar debe
ser recíproca y básicamente se basa en la retroalimentación del cliente durante la fase de
desarrollo y sobre todo de las pruebas de aceptación. Cada retroalimentación del cliente se
convierte en la base para volver a entrar al ciclo de diseño, código, prueba y escuchar, si el
cliente está satisfecho con los resultados la iteración termina en ese momento y el diseño
de la nueva iteración comienza.
ROLES.
CLIENTE (CUSTOMER).
Los clientes en XP son los responsables de definir que funcionalidades debe tener el software. Su
principal actividad es en la planificación de la liberación (reléase planning). Son los encargados de
transmitir la visión, identificar y describir las historias de usuario, determinar cómo agrupar las
funcionalidades en pequeñas liberaciones, gestionar riesgos y realizar el plan del juego (Planning
Game). Adicionalmente el cliente es responsable de proporcionar a los programadores detalles sobre
los requisitos cuando se lo soliciten, también ayudan a comunicar los requisitos, a través, de la
creación de pantallas prototipo, en la revisión de los trabajos en curso y creando pruebas de usuario
detalladas para clarificar reglas de negocio complejas.
PROGRAMADORES (PROGRAMMERS).
Los programadores son los responsables de encontrar la forma más efectiva de entregar las historias
dentro el plan. Para lograr esto, los programadores deben realizar estimaciones de esfuerzo,
sugieren alternativas y ayudan a los clientes a crear un plan alcanzable para el juego de planificación
(Planning Game). Los programadores invierten la mayoría del tiempo haciendo programación en
parejas, codificando, realizando pruebas unitarias, refactorización y generando incrementalmente el
diseño y la arquitectura de la aplicación. Otras actividades son la corrección de fallas, la preparación
de las liberaciones y de realizar integración continua. Los programadores tienen que trabajar en
conjunto con el cliente para aclarar dudas sobre lo que se tiene que construir.
18

27. VERIFICADORES (TESTERS).
Los Testers ayudan a los equipos XP a producir aplicaciones de calidad. Los Tester deben colaborar
con el Cliente para generar buenos casos de prueba e identificar posibles mejoras al producto. Los
Testers deben realizar pruebas exploratorias para identificar proactivamente posibles fallas antes de
que se finalice la codificación y deben proporcionar información sobre exploraciones que se apliquen
a requerimientos no funcionales como son el rendimiento, la escalabilidad y estabilidad. Cuando los
testers encuentran fallas deben de apoyar a todo el equipo a averiguar la causa, así todo el equipo
puede prevenir que la falla se repita en el futuro.
ENTRENADORES (COACHES).
Los Coaches o Entrenadores son básicamente las personas que se encargan de motivar al equipo a
alcanzar su potencial en lugar de estar asignando tareas. El concepto principal es que los Equipos XP
sean auto-organizados, es decir que tomen sus propias decisiones para ser eficientes. Los coaches
ayudan al equipo a iniciar su proceso facilitándoles un espacio de trabajo compartido y de
asegurarse de que el equipo cuenta con la gente correcta para realizar el trabajo. Ayudan a crear las
condiciones para que el equipo sea productivo. Una de las actividades más importantes del Coach es
ayudar al equipo a interactuar con el resto de la organización. Pero sobre todo los coaches ayudan a
los miembros del equipo a ser disciplinados, ayudándolos a que sigan las prácticas de gestión de
riesgos, desarrollo orientado a pruebas y el uso de diseño incremental.
PRÁCTICAS.
Extreme Programming tiene 12 prácticas agrupadas en cuatro áreas, derivadas de las mejores
prácticas de la ingeniera de software:
Figura 0.5 Prácticas Extreme Programming
EL EQUIPO COMPLETO (WHOLE TEAM).

Todos los contribuidores de un proyecto en XP son un solo equipo.

Debe incluir un representante del negocio. El Cliente.

Los miembros del equipo son programadores, testers, analistas, coaches o entrenadores,
managers.
JUEGO DE LA PLANIFICACIÓN (PLANNING GAME).
Es una reunión que ocurre una sola vez por iteración y se define lo siguiente:
19

28. 
Dos preguntas clave en el desarrollo de software:
1.
Predecir que se puede lograr en la fecha comprometida
2.
Determinar que se puede hacer posteriormente

Predicción exacta no es necesaria

Planeación de Liberación XP (Release Planning):
o
o

El Cliente presenta las funcionalidades requeridas
Programadores estiman dificultad
Planeación de Iteración XP (Iteration Planning)
o
Iteraciones de 2 semanas
o
Cliente presenta las funcionalidades requeridas
o
Programadores detallan las tareas necesarias
o
Los miembros del equipo se comprometen por las tareas
o
Entregar software funcional al final de la iteración.
PRUEBAS DEL CLIENTE (CUSTOMER TEST).

El cliente define las pruebas de aceptación por funcionalidad.

El equipo implementa pruebas automatizadas de cada funcionalidad.
LIBERACIONES PEQUEÑAS (SMALL REALEASES).

En cada iteración el Equipo libera software funcional y probado

El cliente puede evaluar y liberar a usuarios finales y proveer retroalimentación
DISEÑO SIMPLE (SIMPLE DESIGN).

Durante la planeación y codificación del software mantener un diseño simple y orientado
únicamente a lo que se necesita construir en la iteración.

Los equipos diseñan y revisan el diseño a través de la refactorización en cada iteración.
PROGRAMACIÓN EN PAREJAS (PAIR PROGRAMMING).

La codificación del software debe realizarse en parejas de 2 programadores en el mismo
equipo.

La resolución de problemas de código en pares da como resultado una mejor calidad en el
código

Trabajar en parejas también permite transferir conocimiento.
DESARROLLO DIRIGIDO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT O TDD).

Equipos usan TDD durante la codificación probando al momento lo que se construye.

Facilidad de producir código probado al 100%
MEJORA DEL DISEÑO (DESIGN IMPROVEMENT).

Refactorización de las clases y métodos
utilizando técnicas y patrones para un mejor
diseño.
INTEGRACIÓN CONTINUA (CONTINUOS INTEGRATION).

Liberaciones frecuentes del producto funcional, después de la codificación y las pruebas
automatizadas.
20

29. PROPIEDAD COLECTIVA DEL CODIGO (COLLECTIVE CODE OWNERSHIP).

Cualquier pareja de programadores puede mejorar cualquier código en cualquier momento

Todo el código obtiene beneficios de todo el equipo
CODIFICACIÓN STANDAR (CODING STANDARD).

Usar un estándar de codificación.

Todo el código del sistema debe verse como si fuese codificado por una sola persona.

el código debe ser familiar para todos
METAFORA (METAPHOR).

Los equipos XP deben desarrollar una visión común del sistema

Asegurar que todos entiendan como el sistema debe trabajar.
RITMO SOSTENIBLE (SUSTAINABLE PACE).

Trabajar a un ritmo que pueda ser sostenido durante la iteración

Evitar tiempos extras y mantener el trabajo de 40 horas a las semana

Proyectos de marchas forzadas son improductivos y de mala calidad
COMUNICACIÓN.
Una de las causas de que los proyectos fracasen se deben a una mala comunicación del equipo, XP a
través de las prácticas como la programación por parejas y el desarrollo dirigido por pruebas permite
que programadores y clientes estén siempre comunicados, por otro lado XP usa el rol de Coach
quien tiene la función de detectar cuando no haya una buena comunicación y establecer canales
claros de comunicación entre el equipo.
SIMPLICIDAD.
La simplicidad en XP se enfoca en el diseño y la codificación de las necesidades que se tengan en el
presente y no preocuparse por hacer algo por las futuras. Por otra parte el emplear un diseño y
codificación simple, ayuda a dar claridad y entendimiento del producto a todo el equipo.
RETROALIMENTACIÓN.
En XP la retroalimentación ocurre durante todo el ciclo de vida, por ejemplo durante la planeación
del juego, durante las pruebas unitarias y de aceptación y en general durante todo el proyecto las
mismas prácticas impulsan a tener una clara retroalimentación del estado del sistema. Una buena
retroalimentación se basa en una buena comunicación y en la simplicidad.
CORAJE.
El coraje es un valor que todo el equipo debe usar constantemente en el proyecto, para enfrentar los
retos y los problemas que se presenten, los programadores por ejemplo deben tener el coraje para
aceptar que el código se puede mejorar siempre, para reconocer cuando algo no funciona y se debe
cambiar, coraje para apoyarse de otro miembro del equipo y resolver un problema.
21

30. 3.4.4.3
ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
HISTORIA
Metodología desarrollada por Jim Highsmith y Sam Bayer a principios de 1990. En 1992 Jim trabajo
en un proceso iterativo llamado RAD (Rapid Application Development) que evoluciono en ASD
(Adaptive Software Development), este método fue probado en varios proyectos y durante los
siguientes años se entregaron satisfactoriamente más de 100 proyectos utilizando estas prácticas.
A mediados de los 90 el interés sobre la compleja adaptación de los sistemas agrego un fondo
conceptual a los aspectos del equipo y fue el catalizador para el cambio de nombre de RAD a ASD.
La teoría de la complejidad nos ayuda a entender lo impredecible y que nuestra capacidad para
predecir no implica la imposibilidad de avanzar. ASD funciona con el cambio en lugar de luchar
contra él.
CICLO DE VIDA.
Las prácticas de ASD están enfocadas a una adaptación continua. En ASD el ciclo clásico de planeardiseñar-construir es remplazado por un ciclo dinámico de Especular-Colaborar-Aprender. Este ciclo
está dedicado al aprendizaje continuo y orientado a cambiar, revaluar y apuntando a un futuro
incierto con una intensa colaboración entre desarrolladores, administradores y clientes.
Figura 0.6 Ciclo de Vida ASD
Especular.
Especular nos da un espacio para explorar, para darnos cuenta de que nada es seguro que suceda,
para apartarse de los planes sin miedo. Un equipo que especula no abandona la planeación,
simplemente reconoce la realidad de la incertidumbre. La especulación reconoce el carácter incierto
de problemas complejos y promueve la exploración y la experimentación.
En la especulación se realizan varias actividades de iniciación y de planeación pero los 3 artefactos
más importantes a obtener serán elaborar una visión del producto, definir el alcance del proyecto y
finalmente obtener un plan de entregas basado en funcionalidades.
Primero, la Iniciación del proyecto involucra definir la visión, los objetivos, las restricciones, la
organización del proyecto, identificar los requerimientos, los alcances y los riesgos. La iniciación
puede ser realizada en un período de dos a cinco días para proyectos pequeños o puede tomar de
dos a tres semanas para proyectos grandes. Durante las sesiones de iniciación los requerimientos
pueden ser recolectados con suficiente detalle para identificar funcionalidades y establecer los
modelos de objetos, datos u otro modelo arquitectónico.
22

31. Segundo. Se establece el tiempo para el proyecto basado en su alcance, funcionalidades, estimados
y disponibilidad de recursos que resultan del paso anterior.
Tercero. Se debe decidir el número de iteraciones y asignar el tamaño en tiempo de cada una de
ellas. Para proyectos pequeños a medianos las iteraciones puede ser de dos a ocho semanas. El
tamaño del proyecto y el grado de incertidumbre son dos factores que determinan el tamaño de la
iteración.
Cuarto. Los miembros del equipo deben definir un tema u objetivo para cada iteración. Cada
iteración entrega un conjunto de funcionalidades para revisión del cliente.
Desarrolladores y clientes asignan las funcionalidades a trabajar en cada iteración. El criterio más
importante para la asignación de funcionalidades es que en cada iteración se debe entregar un
conjunto de funcionalidades visibles y tangibles al cliente. En el proceso de asignación los clientes
definen las prioridades de las funcionalidades en base a los estimados, riesgos y dependencia de
información que el equipo de desarrollo entrega.
Colaborar
El equipo de desarrollo construye los componentes asignados en la iteración para entregar
funcionalidades construidas (“Builds”) en un proceso de integración continua permitiendo que el
producto sea visible al equipo de desarrollo. Las pruebas unitarias y la refactorización también son
un proceso continuo en esta etapa.
Los administradores de proyecto deben de mantener el control y constante monitoreo del proyecto,
facilitando la colaboración y el desarrollo de actividades concurrentes. Por otra parte se deben de
preparan los casos de prueba para la revisión final en QA y se calendarizan las reuniones para que el
equipo de desarrollo revise la calidad del incremento del producto con los clientes.
La colaboración es un acto de creación compartida que abarca al equipo de desarrollo, administrador
del proyecto, los clientes y consultores externos. En esta actividad debe imperar el respeto y la
confianza para conseguir buenos resultados. Los equipos deben colaborar en los problemas técnicos,
los requerimientos de negocio y en la toma rápida de decisiones.
Aprender
En esta fase se reúnen en un evento llamado “quality review”, el cliente y el equipo de desarrollo
para presentar lo construido en la iteración. La retroalimentación de los clientes y los requerimientos
de mejora deben ser documentados con el fin de que sean considerados en futuras iteraciones. Aquí
se decide si se inicia con la siguiente iteración o el producto debe ser preparado para pruebas y
liberación.
Otra reunión que tiene cabida en esta fase es la de “post-mortem”, en la cual se revisa la
productividad que se mostró en la iteración y la efectividad de las practicas utilizadas. Las mejoras
sugeridas deben ser documentadas para considerar en futuras iteraciones.
En caso de que se decida avanzar a las pruebas de calidad, se deben realizar actividades de
validación de las funcionalidades y evaluar el resultado de las pruebas. Si se llegarán a presentar
fallas estas deberán de corregirse. Se debe tomar una decisión si se libera el sistema o se inicia con
una nueva iteración.
23

32. Existen cuatro categorías generales de cosas a aprender al final de cada iteración de desarrollo:
1.
Resultado de la calidad desde el punto de vista del cliente.
La retroalimentación de los clientes es la prioridad para los proyectos de desarrollo de
software adaptables.
2.
Resultado de la calidad desde el punto de vista técnico
Los programadores realizan revisiones técnicas al código o a la arquitectura de manera
continua en cada iteración.
3.
El funcionamiento del equipo de entrega y las prácticas que los miembros del equipo
utilizan.
El equipo se auto examina al final de cada iteración determinando que es lo que no
funciono, que se necesita hacer más y que se necesita hacer menos. La retrospectiva
motiva al equipo a aprender de ellos mismos.
4.
El estado del proyecto.
Esto permite replantear el esfuerzo para la siguiente iteración.
La liberación del producto a un ambiente productivo demanda realizar actividades de despliegue
como preparación de material de entrenamiento, capacitación de usuarios, configuración de
ambientes y preparación del sistema.
Como parte final, se realiza el cierre del proyecto donde se espera un resumen de lecciones
aprendidas de la ejecución de todo el proyecto.
ROLES.

PATROCINADOR EJECUTIVO (EXECUTIVE SPONSOR).
Es el rol que defiende el proyecto y realiza decisiones clave acerca de las metas y
restricciones del proyecto.

CLIENTE (CUSTOMER).
Persona o grupo de personas expertas en el negocio que tienen la responsabilidad de
transmitir la necesidad y de elaborar el listado priorizado funcionalidades requeridas.

EQUIPO DEL PROYECTO (PROJECT TEAM).
Grupo de personas expertas encargados de construir y de entregar un producto de calidad
al cliente.

ADMINISTRADOR DEL PROYECTO (PROJECT MANAGER).
Persona responsable de apoyar durante la iniciación del proyecto en actividades de
definición de alcance, análisis de riesgos y calendario de entregas. Por otro lado debe
brindar apoyo durante la ejecución de la iteración para apoyar al equipo de proyecto en el
avance efectivo de sus tareas. Finalmente son encargados de enviar informes del estado del
proyecto.
24

33. El ciclo de vida de la metodología ASD sigue 6 características básicas:
1.
Enfocada a la Misión
Las declaraciones de la misión actúan como una guía que promueve la exploración al inicio
pero con un estrecho enfoque sobre el curso del proyecto, brindando límites mas que un
destino fijo. La misión provee dirección para evitar iteraciones que nos lleven de un lado
para otro sin lograr un avance en el proyecto.
2.
Desarrollo guiado por Funcionalidades
El desarrollo se rige por resultados esperados no por tareas, y los resultados son
identificados como software con funcionalidades esperadas y desarrolladas en cada
iteración.
3.
Desarrollo Iterativo
El producto se va desarrollando y mejorando, a través, de las iteraciones ya que los clientes
van proporcionando información.
4.
Tiempos Fijos (Time-Boxed)
La práctica del time-boxing o tiempos en plazos fijos para las iteraciones y proyectos, se ha
utilizado de manera incorrecta, las fechas límites usadas para golpear al personal con largas
horas o recortando la calidad son una forma de tiranía. El time-boxing se trata de enfocar y
tomar decisiones difíciles para avanzar. En un ambiente en que predominan los cambios es
necesario que haya una función forzada a conseguir trabajo terminado.
5.
Guiada por los Riesgos.
Como el modelo en espiral de Barry Boehm’s, la planeación para iteraciones adaptables son
guiadas por el análisis de riesgos.
6.
Tolerante a Cambios
ASD es tolerante a los cambios, no viendo al cambio como un problema sino como una
oportunidad de incorporar cambios para generar una ventaja competitiva.
3.4.4.4
DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)
HISTORIA
La metodología de desarrollo de sistemas dinámicos (DSDM), es un marco de trabajo ágil para
gestión de proyectos de software. Es un método que se apoya en un desarrollo iterativo e
incremental, sensible a los requerimientos cambiantes. Fue desarrollado en el Reino Unido en los
años 90 por un consorcio de proveedores y de expertos en la materia en el desarrollo de sistemas de
información, combinando las mejores prácticas. El consorcio de DSDM es una organización no
lucrativa y proveedor independiente, que posee y administra el framework. La primera versión fue
terminada en enero de 1995. La versión actualmente en uso (abril de 2006) es la versión 4.2: El
framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003.
Como extensión del Desarrollo rápido de aplicaciones (RAD), DSDM se centra en los proyectos de
sistemas de información que son caracterizados por presupuestos cortos y agendas apretadas.
25

34. DSDM trata los problemas que ocurren con frecuencia en el desarrollo de los sistemas de
información en lo que respecta a no respetar los tiempos y sobrepasar el presupuesto.
CICLO DE VIDA.
DSDM consiste de tres fases secuenciales: fase del pre-proyecto, fase del ciclo de vida del proyecto y
fase del post-proyecto.
Fase 1 – El Pre-Proyecto.
En el anteproyecto se identifican los proyectos candidatos o propuestos, el patrocinio del proyecto y
se formaliza el compromiso de llevar a cabo el proyecto.
Fase 2 – El ciclo de vida del Proyecto.
El proceso consiste en cuatro etapas:
Figura 0.7 Ciclo de Vida DSDM
1.
Estudio
a.
Estudio de Factibilidad.
Se analiza si es conveniente utilizar DSDM en el proyecto. En esta etapa se genera
un reporte de factibilidad, un prototipo factible y un plan general que incluye un
plan de desarrollo y una lista de riesgos.
b.
Estudio de Negocio.
Se analizan las características del negocio y la tecnología. Los expertos del negocio
revisan los requerimientos y se desarrolla una lista de prioridades, una definición
del área, una definición de arquitectura del sistema y un prototipo general.
2.
Iteración del Modelo Funcional
a.
Identificar el Prototipo funcional.
Determinar que funcionalidades se van a desarrollar en la iteración. En esta etapa
un modelo funcional debe ser elaborado.
b.
Acordar un Calendario
Acordar como y cuando se va a desarrollar las funcionalidades.
c.
Crear un prototipo funcional
Desarrollar un prototipo funcional, de acuerdo al calendario y un modelo funcional.
d.
Revisar el prototipo funcional.
Validar las funcionalidades desarrolladas en el prototipo. El entregable es un
documento de revisión funcional del prototipo.
26

35. 3.
Iteración de Diseño y Construcción
a.
Identificar prototipo de diseño.
Identificar los requerimientos funcionales y no funcionales que se tienen que
probar en el sistema. Basado en lo anterior elaborar un documento de estrategia
de implementación.
b.
Acordar Calendario
Acordar cuando y como se realizarán estos requerimientos.
c.
Crear prototipo de diseño.
Crear el prototipo de diseño que pueda ser entregado a los usuarios finales para
fines de prueba.
d.
Revisar prototipo del diseño.
Validación de la exactitud del sistema diseñado. Nuevamente las pruebas y la
revisión son las principales técnicas utilizadas.
4.
Implementación
a.
Aprobación del usuario y Directrices.
Los usuarios finales aprueban el sistema probado para la implementación y las
directrices con respecto a la implementación y uso del sistema creado.
b.
Formación de usuarios
Entrenamiento del usuario final en el uso del sistema. El entregable es la lista de
usuarios entrenados.
c.
Implementación
Implementar el sistema en la ubicación de los usuarios finales.
d.
Revisión del Negocio.
Revisar el impacto de la implementación en el negocio, se mide si se alcanzaron
las metas establecidas al principio del proyecto. El entregable es el documento
revisión del proyecto.
Fase 3 – El Post-Proyecto.
El post-proyecto asegura que el sistema opera de manera efectiva y eficiente. Esto se realiza por
medio de actividades de mantenimiento, mejoras, correcciones de acuerdo a los principios DSDM. El
mantenimiento puede verse como un desarrollo continuo basado en la naturaleza iterativa e
incremental del DSDM.
En lugar de finalizar el proyecto en un solo ciclo usualmente el proyecto puede regresar a fases
anteriores para que el producto sea refinado y mejorado.
ROLES.

PATROCINADOR EJECUTIVO (EXECUTIVE SPONSOR).
Conocido como el “Campeón del Proyecto”. Es el rol que tiene la habilidad y responsabilidad
de comprometer apropiados fondos para la ejecución del proyecto.

VISIONARIO (VISIONARY).
Es el único con la responsabilidad de inicializar el proyecto, asegurándose que se tengan los
requerimientos esenciales desde el principio. Los visionarios tienen una percepción exacta
de los objetivos del negocio y del proyecto.
27

36. 
USUARIO EMBAJADOR (AMBASSADOR USER).
Trae el conocimiento de la comunidad del usuario al proyecto, asegurándose que los
desarrolladores reciban la suficiente retroalimentación del usuario durante el proceso de
desarrollo.

ASESOR DE USUARIO (ADVISOR USER)
Puede ser cualquier usuario que represente un importante punto de vista y colabore con
conocimiento al proyecto.

ADMINISTRADOR DEL PROYECTO (PROJECT MANAGER).
Es la persona quien lleva la gestión del proyecto en general.

COORDINADOR TÉCNICO (TECHNICAL CO-ORDINATOR).
Responsable de diseñar la arquitectura del sistema y llevar el control técnico de calidad en
el proyecto.

LEADER DEL EQUIPO (TEAM LEADER).
Lidera al equipo y se asegura que trabajen de manera efectiva.

DESARROLLADOR DE SOLUCIONES (SOLUTION DEVELOPER).
Interpreta los requisitos del sistema y lo modela incluyendo el desarrollo del entregable y la
construcción del prototipo.

PROBADOR DE SOLUCIONES (SOLUTION TESTER).
Realiza las pruebas, notifica las fallas cuando se dan y vuelve a testear cuando estas se
corrigen.

ESCRITOR (SCRIBE)
Responsable de reunir y registrar los requerimientos, acuerdos, y las decisiones que se
toman en los talleres.

FACILITADOR (FACILITATOR)
Responsable de gestionar los talleres, actúa como un intermediario para la preparación y
comunicación.

ROLES ESPECIALISTAS (SPECIALIST ROLES)
Arquitecto de negocio, Administrador de Calidad e Integrador de sistemas.
PRACTICAS IMPORTANTES.

TIEMPO-FIJO (TIMEBOXING).
Es usada para apoyar los objetivos principales de DSDM, para realizar el desarrollo en
tiempo, dentro del presupuesto planeado y con la calidad deseada. La idea principal es
dividir el proyecto en partes, cada una con un presupuesto fijo y una fecha de entrega.
Debido a que el tiempo y el presupuesto es lo único fijo, lo variable entonces son los
requerimientos, así que si un proyecto esta fuera de tiempo o presupuesto se tendrán que
28

37. omitir los requerimientos con menor costo. Esto no significa que se entregue un producto
con funcionalidades faltantes, porque el principio de Pareto dice que el 80% del proyecto
viene del 20% de los requerimientos que son implementados, por lo tanto, el sistema
cumple con las necesidades del negocio y que no hay sistema que se construya perfecto a
la primera.

MOSCOW.
Representa una forma de priorizar requerimientos. Este acrónimo se entiende por:
o
Must. Este Requerimiento se debe cumplir para alcanzar los objetivos.
o
Should. Hacer lo posible por cumplir con este requerimiento, pero el éxito no
depende de él.
o
Could. El no contar con este requerimiento no afecta la necesidad del negocio.
o
Won´t. Requisito que no será implementado al final de la iteración, pero puede
ser considerada en otra.

PROTOTIPOS (PROTOTYPING).
Se refiere a la técnica de realizar prototipos del sistema bajo el desarrollo en las primeras
etapas del proyecto. Permite el descubrimiento de las deficiencias en el sistema y permite
probar antes el sistema. De esta manera permite la participación anticipada de los usuarios,
siendo uno este un factor clave de éxito del DSDM.

PRUEBAS (TESTING)
Un aspecto importante para las metas del DSDM es la creación de software de buena
calidad. Para alcanzar una solución de buena calidad DSDM promueve las pruebas en cada
iteración.

TALLERES (WORKSHOP)
Una de las técnicas claves es reunir a los interesados del proyecto para discutir y analizar
requerimientos, funcionalidades para que haya un entendimiento general.

MODELADO (MODELING)
Técnica para representar en diagramas un aspecto del sistema o área del negocio para
brindar un entendimiento visual más fácil de entender a todos los involucrados.

GESTIÓN DE LA CONFIGURACIÓN (CONFIGURATION MANAGEMENT).
Una buena implementación de esta técnica es importante por la naturaleza del DSDM, ya
que debido a que los productos se entregan con frecuencia a un ritmo muy rápido, es
necesario controlar las salidas a producción que puedan afectar los ambientes productivos.
3.4.4.5
FEATURE DRIVEN DEVELOPMENT (FDD)
HISTORIA
FDD fue creado inicialmente por Jeff De Luca, para satisfacer las necesidades específicas de un
proyecto grande de desarrollo de software de 15 meses y 50 personas en un banco de Singapur en
1997. Jeff De Luca entrego un conjunto de cinco procesos que cubren el desarrollo de un modelo
general, el listado, la planificación, el diseño y construcción de las funcionalidades.
29

38. El primer proceso es influenciado por el enfoque de Peter Coad de modelado de objetos. El segundo
proceso incorpora las ideas de Peter para usar una lista de funcionalidades para la gestión de
requerimientos funcionales y tareas de desarrollo. Los otros procesos y la mezcla de los procesos en
un todo es el resultado de la experiencia de Jeff De Luca. Desde su utilización en el proyecto de
Singapur, ha habido varias implementaciones de FDD.
CICLO DE VIDA.
FDD es un proceso de iteraciones cortas que consta de cinco etapas básicas. Para un estado exacto
de informes y de seguimiento al proyecto de software, se definen milestones o hitos que marquen el
progreso de cada funcionalidad.
Figura 0.8 Ciclo de Vida FDD
PROCESO #1. DESARROLLO DE UN MODELO GENERAL (DEVELOP AN OVERALL MODEL).
En esta etapa se realiza una actividad que engloba a todo el proyecto con los miembros del dominio
(usuarios expertos) y de desarrollo bajo la guía de un modelador de objetos en un rol de arquitecto.
Se tiene una vista a alto nivel del alcance del sistema y su contexto. El detalle de cada vista es
realizada dentro de cada área modelada. Después de cada vista del dominio, se arman equipos con
personal del dominio y con desarrolladores líderes quienes realizan sus propios modelos apoyados de
la vista de dominio. Los equipos presentan sus modelos para compartir puntos de vista y realizar
debates. Uno de los modelos diseñados o la mezcla de ellos son seleccionados por consenso para
que sea el modelo de dominio para esa área. Se agrega el modelo de domino del área al modelo
general, ajustando la forma del modelo si es necesario. El modelo de objeto es actualizado de forma
iterativa.
Entregables:
o
Diagrama de clases
o
Métodos y atributos identificados
o
Diagramas de secuencia, comportamiento u otro.
PROCESO #2. CONSTRUCCIÓN DE UNA LISTA DE FUNCIONALIDADES (BUILD A FEATURE LIST).
Identificar todas las funcionalidades para cumplir con los requerimientos. El equipo se compone por
los programadores líderes que participaron en el proceso anterior para que vayan descomponiendo
funcionalmente el dominio en áreas, las actividades de negocio y los pasos dentro de cada actividad
forman una lista de funcionalidades categorizadas. El primer nivel de categorización para la lista de
30

39. funcionalidades viene de la división del dominio realizada en el proceso anterior por los expertos del
dominio.
Entregables:
o
Listado de Áreas
o
Por cada área una lista de actividades de negocio.
o
Por cada paso de la actividad de negocio la funcionalidad que la cumple.
PROCESO #3. PLANIFICACIÓN POR FUNCIONALIDAD (PLAN BY FEATURE).
Actividad para desarrollar el plan de desarrollo. El administrador del proyecto, el administrador de
desarrollo y los programadores líderes planean la manera en que las funcionalidades serán
implementadas, basándose en las dependencias, las cargas del equipo de desarrollo y en la
complejidad que implica cada una de ellas.
Entregable:
o
Plan de Trabajo con fechas de entrega de las actividades de negocio, recursos asignados, y
fechas de entrega de las áreas.
PROCESO #4. DISEÑO POR FUNCIONALIDAD (DESIGN BY FEATURE).
Actividad para generar un paquete de diseño funcional. El líder de programadores se encarga de
seleccionar un conjunto de funcionalidades de su bandeja de funcionalidades asignadas con la
finalidad de preparar un paquete de trabajo para el desarrollo. Luego el líder de programadores
forma un equipo orientado a funcionalidades e identificar a los dueños de las clases. Este equipo se
encarga de elaborar los diagramas de secuencia para las funcionalidades asignadas y construyen las
clases y métodos. Una inspección del diseño es realizada.
Entregable:
o
Documento que integra y describe el paquete de diseño.
o
Diagramas de secuencia.
o
El modelo de objetos actualizado.
PROCESO #5. CONSTRUIR POR FUNCIONALIDAD (BUILD BY FEATURE).
Actividad para producir una funcionalidad completa al cliente. Iniciando del paquete diseñado en el
proceso anterior, los dueños de la clase de desarrollo implementan los elementos necesarios para su
clase y soportar el diseño de esta característica. Por últimos se realizan las pruebas unitarias y se
inspecciona el código. Después de una inspección satisfactoria se promueve el código para generar
el Build (ejecutable).
Entregables:
o
Clases y métodos codificados e inspeccionados
o
Clases promovidas a generación del build
o
La entrega una funcionalidad del producto al cliente.
ROLES.

PROJECT MANAGER.
31

40. Es el líder administrativo del proyecto, responsable de reportar los avances, administrar los
presupuestos y de gestionar los recursos humanos y materiales.

CHIEF ARCHITECT.
Responsable de elaborar y definir todo el diseño arquitectónico del sistema. Diagramas de
comportamiento, de secuencias y de clases son parte de los entregables a generar. Debe
resolver problemas de diseño que los programadores no puedan resolver. Debe resolver los
problemas técnicos que puedan presentarse antes y durante la construcción.

THE DEVELOPMENT MANAGER
Es el responsable de liderar a todo el equipo de desarrollo, apoyándolos en la solución de
obstáculos que puedan afectar su avance. Resuelve los conflictos que puedan presentarse
dentro del equipo.
CHIEF PROGRAMMER.
Es un desarrollador experimentado que participa en todo el ciclo de vida del desarrollo.
Participa en el análisis de los requerimientos y actividades de diseño y es responsable de
guíar a pequeños grupos de desarrolladores.

CLASS OWNERS.
Son desarrolladores que participan como miembros de pequeños equipos de desarrollo.
Ellos son encargados de diseñar, codificar, probar y documentar las funcionalidades
requeridas para el nuevo software.

DOMAIN EXPERTS.
Son usuarios, clientes o expertos del negocio, cuya función es explicar a los desarrolladores
los requerimientos y necesidades del negocio. Ellos son la base de conocimiento que usa el
equipo de desarrolladores para entregar correctamente el producto.
3.5
COMPARATIVA TRADICIONAL VS ÁGIL
Modelo Tradicional.
Las metodologías tradicionales como la cascada o waterfall se basan en un esquema de fases
secuenciales, donde se utiliza un proceso predictivo de desarrollo de software. En cada etapa del
modelo se tiene que cumplir con la elaboración de una serie de documentos que son los entregables
para poder iniciar con la siguiente etapa. El éxito de esta metodología se basa en el conocimiento
pleno de todos los requerimientos funcionales del producto antes de empezar con la etapa de
desarrollo. Esto nos permite generar un calendario más exacto determinando los costos y recursos
necesarios para poder alcanzar el objetivo del negocio, sin embargo, cualquier cambio que pueda
surgir sobre los requerimientos durante su construcción nos llevaría a enfrentar ciertas problemáticas
de control de cambios.
Modelo Ágil.
El desarrollo ágil se basa en la idea de generar un producto de manera iterativa e incremental,
donde en cada iteración se entrega una parcialidad del producto final y en cada nueva iteración se
mejora el producto, abrazando los cambios como una oportunidad de mejora y no como un
problema.
32