Adopción de una metodología agil para proyectos de software
89
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. Universidad Europea Miguel de Cervantes México, Agosto 01, 2013 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
description
Trabajo de Tesis, Adopción de una metodología agil para proyectos de software. En la investigación se describe un caso real.
Transcript of Adopción de una metodología agil para proyectos de software
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.
Universidad Europea Miguel de Cervantes México, Agosto 01, 2013
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
i
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.
ii
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
iii
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.
iv
Í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
v
Anexo - Glosario de Términos ..................................................................................................... 79
vi
ÍNDICE DE FIGURAS
Figura 3.1 Modelo Cascada ........................................................................................................ 5 Figura 3.2 Modelo Espiral .......................................................................................................... 7 Figura 3.3 Proceso Scrum ......................................................................................................... 12 Figura 3.4 Ciclo de Vida Extreme Programming .......................................................................... 16 Figura 3.5 Prácticas Extreme Programming ................................................................................ 19 Figura 3.6 Ciclo de Vida ASD .................................................................................................... 22 Figura 3.7 Ciclo de Vida DSDM .................................................................................................. 26 Figura 3.8 Ciclo de Vida FDD .................................................................................................... 30 Figura 3.9 Comparativa Cascada vs Ágil ..................................................................................... 33 Figura 3.10 Factores Impulsan la Adopción de una Metodología Ágil ............................................ 34 Figura 4.1 Resultado Evaluación Metodologías ............................................................................ 37 Figura 4.2 Criterios de Selección del Proyecto Piloto.................................................................... 38 Figura 4.3 Diagrama Estado Antes Adopción Scrum .................................................................... 39 Figura 4.4 Estructura Área Aplicaciones ..................................................................................... 39 Figura 4.5 Roles en Gestion de Proyectos antes de Adopción de Scrum ........................................ 40 Figura 4.6 Herramientas de Team Foundation Server 2010 .......................................................... 41 Figura 4.7 Tipos de Elementos de Trabajo (Work Items) ............................................................. 42 Figura 4.8 Listado de Queries ................................................................................................... 43 Figura 4.9 Roles para Gestión de un Proyecto con Scrum ............................................................ 45 Figura 4.10 Listado de Requerimientos Ordenados ..................................................................... 47 Figura 4.11 Definiendo un PBI en TFS ....................................................................................... 48 Figura 4.12 Sprint Backlog ........................................................................................................ 49 Figura 4.13 Definición Funcional del PBI .................................................................................... 50 Figura 4.14 Casos de Prueba .................................................................................................... 50 Figura 4.15 Definición de los pasos a seguir en un Test Case ....................................................... 51 Figura 4.16 Ejecución de Caso de Prueba .................................................................................. 52 Figura 4.17 Notificación de una Falla ......................................................................................... 52 Figura 4.18 Ciclo de Vida de un PBI en TFS................................................................................ 53 Figura 4.19 Ambientes de Liberación del Producto ...................................................................... 54 Figura 4.20 Lista de Builds generados ....................................................................................... 55 Figura 4.21 Control de Código Fuente en TFS............................................................................. 55 Figura 4.22 Estrategia de Ramas para Liberaciones de Producto .................................................. 56 Figura 4.23 Gráfica de Burndown de Seguimiento al Proyecto ...................................................... 57 Figura 4.24 Gráfica de Velocidad del Equipo ............................................................................... 58 Figura 4.25 Uso de Pruebas Unitarias en el Código Fuente .......................................................... 58 Figura 6.1 Burndown Sprint 1 ................................................................................................... 63 Figura 6.2 Burndown Sprint 2 ................................................................................................... 63 Figura 6.3 Burndown Sprint 3 ................................................................................................... 64 Figura 6.4 Productividad por Puntos de Esfuerzo ........................................................................ 65 Figura 6.5 Velocidad del Equipo ................................................................................................ 66 Figura 6.6 Progreso de las historias de usuario. .......................................................................... 66 Figura 6.7 Defectos Corregidos ................................................................................................. 67 Figura 6.8 Resumen de Builds ................................................................................................... 67 Figura 6.9 Evaluación ROI ........................................................................................................ 69 Figura 6.10 Gráfica de Impacto en la Competitividad en la Adopción de Scrum ............................. 71 Figura 7.1 Encuesta Adopción Scrum ......................................................................................... 75
vii
ÍNDICE DE TABLAS
Tabla 3.1 Comparativa Tradicional vs Ágil .................................................................................. 33 Tabla 4.1 Calificación Metodologías ........................................................................................... 36 Tabla 4.2 Infraestructura de Servidores ..................................................................................... 40 Tabla 4.3 Software Instalado .................................................................................................... 41 Tabla 4.4 Cronograma del Caso de Estudio ................................................................................ 44 Tabla 4.5 Cronograma del Proyecto Piloto. ................................................................................. 44 Tabla 5.1 Variables a Medir ...................................................................................................... 60 Tabla 5.2 Población y Muestra .................................................................................................. 61 Tabla 6.1 Productividad de Valor Entregado ............................................................................... 65 Tabla 6.2 % Errores Calidad Corregidos ..................................................................................... 67 Tabla 6.3 Resultado de lo que se hizo Bien ................................................................................ 68 Tabla 6.4 Resultado de lo que No se hizo bien ........................................................................... 68 Tabla 6.5 Resultado de lo que se puede Mejorar ........................................................................ 68
1
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:
Productividad
Calidad
Valor
Efectividad
Innovación
2 Fuente: Competitive Advantage, Michael E. Porter, The Free Press, 2004. 3 Fuente: The Competitive Advantage of Nations. Michael E. Porter, Harvard Business Review, 1990.
2
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.
3
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. Adaptive Software Development (ASD). 4. 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.
4
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
Fuente: Porter, M. E. (1990). The Competitive Advantage of Nations. Harvard Business Review. 5 Fuente: http://en.wikipedia.org/wiki/Gary_Hamel, en ingles, leído el 8 de agosto 2013
5
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 METODOLOGÍAS TRADICIONALES
3.3.1 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
descripción formal de este modelo fue en un artículo realizado por Winston W Royce6 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:
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.
Especificación de Requerimientos
Diseño
Construcción
Integración
Pruebas
Despliegue
Mantenimiento
6
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
7
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 nunca se concluyen
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 Desconfianza para la realización de proyectos
3.3.2 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
8
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 Fuente: http://www.agilemanifesto.org/, En Inglés, leído 24 de Mayo del 2013. 9 Fuente: http://agilemanifesto.org/principles.html, En Inglés, leído el 24 de Mayo del 2013.
9
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
10
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
11
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
conferencia OOPSLA en 199512. 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
12
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.
13
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 auto-organizados.
o Son Multifuncionales.
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) Encontrar técnicas para gestionar el Product Backlog
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) Facilitar los eventos de Scrum
o 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 (time-
boxes), 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.
14
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.
15
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
16
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 software13. 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.
17
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,
18
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.
19
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:
20
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 El Cliente presenta las funcionalidades requeridas
o 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.
21
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.
22
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 planear-
diseñ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.
23
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.
24
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.
25
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.
26
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.
27
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.
28
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
29
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.
30
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
31
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.
32
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.
33
El modelo ágil más que un proceso es un cambio de mentalidad, es la adopción de valores y
principios ágiles y aplicarlos en los proyectos con los equipos de trabajo.
Muchas organizaciones dedicadas al desarrollo de software actualmente están haciendo el esfuerzo
por incrementar su agilidad al cambio. Existen casos de éxito donde equipos ágiles están
produciendo productos de alta calidad, que entregan valor al negocio en menos tiempo y con un
costo menor en comparación a equipos de trabajo que emplean una metodología tradicional como la
cascada.
En un estudio realizado por Standish Group, quienes se dedican a recolectar información de casos de
fracaso de la vida real en TI (Tecnologías de la Información), publicaron una comparativa, donde se
puede visualizar el porcentaje de éxito en los proyectos donde se han adoptado metodologías ágiles
frente a la tradicional (cascada).
Figura 0.9 Comparativa Cascada vs Ágil
En la siguiente tabla 1 se presenta las 5 características importantes que marcan una diferencia en
eficiencia y efectividad entre las metodologías tradicionales y las ágiles utilizados sobre proyectos
complejos y con una frecuencia alta de cambios en los requerimientos.
Características Tradicional Ágil
Definición de Requerimientos
Análisis y documentación extensa necesaria (SRS, UML diagramas)
Listado de Funcionalidades breve (Lista Ordenada)
Diseño y Arquitectura Se define todo en la etapa de diseño, se plasman en diferentes diagramas.
Se va definiendo poco a poco durante cada iteración, se emplea refactorización
Pruebas Se efectúan cuando el producto ya se tiene terminado en su totalidad.
Se efectúa en cada iteración entregando producto funcional probado.
Interacción con el cliente
En la etapa inicial de requerimientos, en las pruebas funcionales y en el despliegue
En cada momento del proceso.
Comunicación en el equipo
Al final e inicio de cada etapa Comunicación constante
Tiempo de entrega de valor
Años, quizás nunca En semanas, meses o final de iteración.
Tabla 0.1 Comparativa Tradicional vs Ágil
34
Hoy en día debido a la fuerte competencia entre las organizaciones para posicionarse como líder en
el mercado se realizan importantes esfuerzos para innovar y ofrecer al cliente no solo un producto a
un menor precio sino que también a través de la tecnología se busca que el cliente participe en el
proceso de la cadena de valor, seleccionado productos, proveedores y tiempos de entrega a su
conveniencia, a través del uso de plataformas e-bussines. Para lograr éxito en estas nuevas
estrategias es necesario aprovechar la oportunidad del cambio y moverse rápido en la generación de
software que ofrezca la funcionalidad que se busca obtener, para ello es necesario basarse en una
metodología ágil que permita entregar valor en menor tiempo a los clientes y obtener en ese sentido
una ventaja competitiva.
Las metodologías tradicionales no tienen efectividad en la mayoría de estos proyectos, las variables
tecnología, requerimientos y personas son elementos que van cambiando en el transcurso del
tiempo e incrementan la complejidad de los proyectos. Ante estos escenarios es necesario adoptar
otro tipo de paradigmas para la gestión de proyectos de software y la tendencia actual demuestra
que el uso de las metodologías ágiles ha cambiado la manera de abordar estas problemáticas o
áreas de oportunidad.
Como referente, en un estudio realizado por la universidad de Oulu y la universidad politécnica de
Madrid en el 2009 tomando como muestra datos del evento Agile Open Spain (AOS), se tenía el
objetivo de analizar el estado de adopción de las metodologías ágiles en la industria de software
española comparándola con la europea. La muestra europea estaba compuesta por socios
industriales del proyecto Flexi (Flexi es una iniciativa de investigación europea en metodologías
ágiles) por un lado y por otro la industria española que estuvo compuesta por empresas que
asistieron al evento AOS 2009. Los resultados encontrados fueron los siguientes:
Los factores más importantes que motivan la adopción de una metodología ágil son los mostrados
en la siguiente figura.
Figura 0.10 Factores Impulsan la Adopción de una Metodología Ágil
35
Se puede observar como en primer lugar lo que le interesa a las empresas es adoptar una
metodología ágil para mejorar la calidad de su producto y en segundo lugar para incrementar la
productividad en sus equipos de trabajo, es decir, el maximizar estas variables impacta en el
desarrollo de una ventaja competitiva en la organización.
36
Capítulo 4
Metodología Ágil Propuesta
4.1 PROCESO PARA LA GESTIÓN DEL PROYECTO
Selección de la metodología para desarrollo de software.
Esta investigación no consiste en definir un método para la elección de una metodología ágil, sin
embargo, si es importante describir los criterios que se analizaron para elegir Scrum sobre las otras
metodologías en la empresa Cotemar.
Para ello se realizó una evaluación de las metodologías presentadas en el presente estudio de
acuerdo a las siguientes dimensiones:
Usabilidad – Su grado de uso en otras organizaciones.
Adaptabilidad – La respuesta ante el cambio en lugar de seguir un plan.
Calidad – Su capacidad para entregar software funcionando en lugar de documentación
extensiva.
Colaboración – Los individuos y sus interacciones en lugar de procesos y herramientas
Simplicidad – El esfuerzo necesario para que una organización entienda el proceso
Nivel Expertos - Nivel de habilidades técnicas requeridas por el equipo de desarrollo para su
implementación.
En la tabla 4.1 se presentan los resultados de dicha evaluación, para lo cual, para poder asignar un
valor se tomaron en consideración los siguientes factores de cada metodología:
Ciclo de vida
Roles
Artefactos
Practicas
Metodologías Usabilidad Adaptabilidad Calidad Colaboración Expertise
Scrum Alta Alta Alta Alta Media
XP Alta Alta Alta Alta Alta
ASD Baja Alta Alta Alta Alta
DSDM Baja Media Media Media Media
FDD Baja Alta Alta Alta Alta
Tradicional Alta Baja Baja Baja Media
Tabla 0.1 Calificación Metodologías
Los valores asignados para cada calificación son los siguientes:
3=Alta, 2=Media, 1=Baja
En la figura 4.1 se puede visualizarse que el punto más alto es ocupado por Extreme Programming
(XP).
37
Figura 0.1 Resultado Evaluación Metodologías
Aunque XP fue la metodología con la calificación más alta, esto no significa que sea la metodología
idónea para su elección, ya que desde el punto de vista de la organización tiene que evaluarse
factores como la cultura, cantidad de desarrolladores, habilidades técnicas de los desarrolladores y la
relación de la estructura del área actual con respecto a los roles necesarios.
Para el caso Cotemar, se seleccionó Scrum como la metodología ideal por las siguientes razones:
1. El proceso Scrum con sus roles y artefactos se ajusta a la estructura y funciones que se
tienen en el área de aplicaciones en Cotemar.
2. En Scrum no se requiere de un equipo grande de desarrolladores o contar con diferentes
roles. En el caso particular de Cotemar se cuenta con un equipo pequeño de
desarrolladores y el nivel de habilidades es muy variado, además de que no se cuenta con
un rol de arquitecto o jefe de programadores entre ellos.
3. La cultura actual a la que están acostumbrados para trabajar debe cambiar totalmente y
aunque para cualquier metodología ágil significa un cambio radical, existe cierta simpatía
con Scrum que ayudara a reducir la resistencia a este cambio. Por otro lado experimentar
prácticas como la programación en pares puede requerir de más tiempo lo que agrega
riesgo al proyecto.
Selección de un proyecto para adoptar Scrum.
Para este caso de estudio el área de aplicaciones adoptará la metodología ágil Scrum para llevar un
proyecto de software. El proyecto se seleccionó en base a cuatro criterios: tamaño, duración,
importancia y grado de compromiso del negocio.
38
Figura 0.2 Criterios de Selección del Proyecto Piloto
El alcance del proyecto consiste en generar una aplicación para gestión de movilidad salarial que
apoye al proceso que realiza la gerencia de capital humano para realizar ajustes salariales en base al
presupuesto, para identificar el proyecto en el estudio lo llamaremos proyecto: Salary Plan.
Es importante mencionar que el área de aplicaciones apoya la iniciativa de llevar este proyecto con
la nueva metodología Scrum en Cotemar. Actualmente el área de aplicaciones lleva la metodología
cascada, donde se genera un plan de trabajo en fases y el producto o software se entrega en la fase
final de despliegue. Sin embargo, debido a los frecuentes cambios del negocio en los requerimientos
y en la velocidad con que se necesita tener resultados, muchos de los proyectos se quedan a la
mitad y se cancelan. Es por estos motivos que el área de aplicaciones se ve en la necesidad de
adoptar Scrum como metodología ágil con la finalidad de mejorar el proceso de gestión de
proyectos.
La foto Actual del Área.
Antes de iniciar con el proceso de adopción se desarrolló una evaluación de la madurez del área de
aplicaciones en base a buenas prácticas utilizadas en cada fase del proceso para la generación de
software y así tener una foto que represente el antes de la adopción. Esta evaluación se realizó en
base a una serie de entrevistas con todo el equipo de aplicaciones donde se evaluaron prácticas en
las categorías de:
o Gestión de Requerimientos.
o Arquitectura y Diseño.
o Desarrollo
o Pruebas y Aseguramiento de Calidad
o Gestión de la Configuración
o Implementación y Operaciones
La figura de abajo muestra el resultado de estas entrevistas y el nivel de madurez del área de
aplicaciones en el uso de buenas prácticas para el desarrollo de software, donde los niveles indican
que tan crítica es su utilización en la empresa
Nivel Uno - Básico. Es Urgente la adopción de buenas prácticas
Nivel Dos - Estándar. Se busca Mejorar lo que se tiene.
Nivel Tres - Avanzado. Se busca remarcar y afinar lo que se tiene.
39
Nivel Cuatro - Dinámica. Mantenerse en las prácticas.
Figura 0.3 Diagrama Estado Antes Adopción Scrum
Como puede verse el nivel de madurez actual es de cero, es decir, se necesita de manera urgente
cambiar las prácticas y el proceso para el desarrollo de software.
Con estas actividades se puede identificar que no solamente se sigue una metodología errónea para
el desarrollo de software sino que también no se están utilizando buenas prácticas.
Por otra parte y para un entendimiento del funcionamiento del área de aplicaciones, es importante
dar a conocer como está organizada y conocer que roles y funciones se emplean para la gestión de
proyectos.
En la figura puede ver como se estructura el área de aplicaciones según los puestos:
Figura 0.4 Estructura Área Aplicaciones
En la figura de abajo puede verse los roles que participan en la gestión de un proyecto, las personas
que tomen un determinado rol son parte de la estructura del área de aplicaciones.
40
Figura 0.5 Roles en Gestion de Proyectos antes de Adopción de Scrum
Para la preparación de la adopción de la metodología Scrum se llevaron a cabo las siguientes
actividades:
1. Capacitación en la metodología Scrum.
La idea en esta actividad como primer paso en la adopción era que todo el equipo de
aplicaciones conociera este nuevo marco de trabajo, se estableciera un nuevo lenguaje de
comunicación y sobre todo se iniciara el cambio de mentalidad sobre los nuevos valores y
principios que se deberían adoptar.
2. Selección de una herramienta para dar seguimiento a los proyectos.
Como parte de la estrategia de adopción es importante apoyarse de alguna herramienta
tecnológica que facilite el seguimiento y control del proyecto. Para este caso, se decide
implementar la herramienta Team Foundation Server (TFS), ya que la mayoría de los
desarrollos son realizados en .net y se integra al proceso de desarrollo de manera natural.
3. Se implementó una nueva infraestructura de servidores para dar soporte a la
gestión de proyectos.
Cantidad Servidor Descripción
1 Microsoft Team Foundation Server
2010
Servidor que administra la
colección de proyectos.
2 Microsoft SharePoint Server 2010 Servidor para dar seguimiento a
los proyectos
3 Microsoft SQL Server 2008 R2 Servidor para almacenar los
proyectos y los informes.
Tabla 0.2 Infraestructura de Servidores
4. Software utilizado de apoyo para la gestión del Proyecto.
El siguiente listado muestra la relación de software instalado en los equipos clientes del
equipo Scrum para administración y seguimiento del proyecto.
41
Software Descripción
Microsoft Visual Studio 2010
Professional
Software utilizado para llevar el
desarrollo del producto,
administración del proyecto,
control de versiones.
Microsoft Office 2010 Software utilizado para generar
documentos y artefactos para el
proyecto.
Microsoft Test Manager Software utilizado para la gestión
de las pruebas
Tabla 0.3 Software Instalado
5. Taller para integrar Scrum con la herramienta Team Foundation Server (TFS)
Se capacito y llevo un caso práctico en el uso del nuevo marco de trabajo Scrum mediante
la herramienta TFS y el equipo se pueda familiarizar con el proceso y las herramientas.
6. Se realizaron reuniones para dar seguimiento y apoyo a la adopción.
Las reuniones se efectuaron con el objetivo de dar seguimiento a la implementación de
Scrum y sensibilizar a todo el equipo sobre la importancia de entender y aceptar el nuevo
marco de trabajo para la gestión de proyectos, puntualizando los beneficios que se podrían
obtener dentro de la organización a corto plazo.
Gestión a través del Team Foundation Server (TFS).
Antes de iniciar con el proyecto, necesitamos entender el papel de la herramienta TFS para
poder realizar la gestión siguiendo el marco de trabajo Scrum.
Figura 0.6 Herramientas de Team Foundation Server 2010
42
TFS se convierte en la herramienta oficial para la gestión de proyectos en la empresa, a
través de ella, se generan ambientes por proyecto donde se lleva la gestión de los
requerimientos, las tareas, pruebas, control de versiones e informes de seguimiento. Es una
suite de herramientas que brinda el ambiente para que todo el equipo Scrum pueda
trabajar de manera colaborativa, integrando toda la información del proyecto en una base
de datos. Algunos conceptos en la herramienta que se tienen que introducir en el lenguaje
del Equipo Scrum son los siguientes:
Sprint
Es el mismo concepto que se maneja en Scrum y TFS, se define como la duración
de una iteración definida por el Scrum Master.
Work Items.
En TFS el work ítem o elemento de trabajo es la unidad básica de trabajo que se
le asigna a una persona del equipo. Existen diferentes tipos de work ítem, pero los
que vamos a utilizar son los siguientes:
o Product Backlog Item (PBI). Este elemento de trabajo representa un
requerimiento funcional que define el Product Owner para dar seguimiento. En
este elemento se captura su descripción, prioridad, valor y el criterio de
aceptación
o Task. Este elemento, representa una actividad técnica a ejecutar por el Equipo
de Desarrollo, ahí se describe a detalle que trabajo técnico se va a realizar y
cuánto tiempo en horas llevará realizarlo.
o Test Case. Representa el caso de prueba que se tiene que aplicar al PBI para
evaluar el criterio de aceptación. En este caso de prueba se deben definir los
pasos necesarios para evaluar una funcionalidad específica.
o Bug. Este elemento es creado por el Tester cuando en las pruebas se presenta
una falla en la funcionalidad, en el cual se documenta los pasos realizados
cuando se surgió esta falla, de esta manera el Equipo de Desarrollo podrá
darle seguimiento y corregirla.
o Impediment. Elemento que representa una actividad asignada al Scrum
Master para apoyar al equipo a remover obstáculos que impidan el avance del
proyecto.
Figura 0.7 Tipos de Elementos de Trabajo (Work Items)
Queries.
43
o Los queries o consultas son listados predefinidos que nos agrupan la
información de los work ítems para dar seguimiento al estado del
proyecto, algunos queries predefinidos son: Product Backlog, Sprint
Backlog, Impediments, Bugs, TestCases. Otros queries pueden ser
diseñados de acuerdo a alguna necesidad particular.
Figura 0.8 Listado de Queries
Datos generales del Proyecto Piloto.
Objetivos:
o Contar con una aplicación que permita evaluar y realizar ajustes salariales.
o Brindar una interfaz colaborativa con los gerentes.
o Generar reportes y estrategias de autorización del plan de salarios.
Beneficios:
o Eficiencia en el cálculo de nómina
o Reducción de tiempo en la generación de reportes
o Rapidez para la autorización de los Gerentes
Entregables.
o Sistema de Administración de Salary Plan (Salary Plan Management)
o Capacitación al Key User
Factores críticos de éxito.
o Participación activa del Key User
o Disponibilidad de los recursos involucrados
Limitantes.
44
o Tiempo limitado para llevar a cabo el proyecto
Cód. Act.
Actividad Calendario (Meses)
1 2 3 4 5 6
1 Documentar 5 metodologías ágiles X
2 Propuesta de Implementación de Metodología Scrum
X
3 Análisis y Selección de un proyecto de software X
4 Elaborar Documentación del Proyecto X
5 Selección y preparación de herramientas de apoyo X
6 Selección del Equipo de Trabajo X
7 Capacitación en la metodología Scrum X
8 Elaboración del Product Backlog X X X X
9 Elaboración del Sprint Backlog X X X X
10 Definición de las Tareas a realizar X X X X
11 Construcción y Pruebas de Funcionalidades X X X X
12 Seguimiento Diario X X X X
13 Liberación X X X X
14 Revisión del Sprint y Retrospectiva X X X X
15 Documentar resultados X
16 Documentar el nuevo proceso de gestión de proyectos.
X
Tabla 0.4 Cronograma del Caso de Estudio
Sprint 1 Sprint 2 Sprint 3 Sprint 4
# Semanas # Semanas # Semanas # Semanas
Actividades 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Def. Sprint Backog X X X X
Diseño Funcional X X X X
Construcción X X X X X X X X
Pruebas X X X X X X X X
Ajustes X X X X
Sprint Review X X X X
Retrospectiva X X X X Tabla 0.5 Cronograma del Proyecto Piloto.
45
4.2 ROLES INVOLUCRADOS EN SCRUM
Figura 0.9 Roles para Gestión de un Proyecto con Scrum
Scrum Master.
Para este rol se definieron un grupo de personas seleccionadas del equipo de Desarrollo que de
acuerdo a sus capacidades, aptitudes y habilidades técnicas podrán desempeñar este rol de una
forma más natural.
La introducción de este nuevo rol en la gestión del proyecto tuvo algunas complicaciones, ya que
actividades que realizaba el administrador de proyectos las empezaba a realizar el Scrum Master. Sin
embargo para resolver este tipo de conflictos se emitió un documento de responsabilidades de cada
rol y para el Scrum Master el objetivo principal era ayudar al Equipo a que se respetará el proceso
Scrum durante el proyecto.
Para el caso del proyecto piloto se enlistan las actividades en las que el Scrum Master colaboro:
1. Apoyar al Dueño del Producto a definir y a priorizar sus requerimientos
2. Apoyar al Equipo a entender los requerimientos y definir de manera objetiva sus
tiempos.
3. Definir los tamaños de los Sprints de acuerdo a la meta deseada.
4. Apoyar sobre dudas en el TFS para llevar el proceso de Scrum.
5. Monitorear que el proceso se esté llevando correctamente
6. Organizar las reuniones diarias entre el Equipo de Desarrollo y el Dueño del Producto
para enfocar esfuerzos.
7. Resolver impedimentos que puedan afectar el avance del proyecto.
8. Organizar y llevar las reunión de revisión del Sprint y Restrospectiva
9. Apoyar al Dueño del producto para entender los informes de avance y conocer el
estado del proyecto.
10. Apoyar a que el Equipo de Desarrollo y el Dueño del Producto se integrarán.
46
Fue difícil en un inicio introducir el papel de este rol en el proyecto, sin embargo, durante los Sprints
se logró entender que es pieza fundamental para la correcta adopción de Scrum en la organización.
El Dueño del Producto (Product Owner).
Para este rol se seleccionaron a personal del grupo de Funcionales, ya que los funcionales por su
conocimiento e involucramiento con los procesos del negocio, sus capacidades de negociación y
conocimiento en la tecnología eran los candidatos perfectos a desempeñar este rol. La principal
función de este rol era transmitir al equipo la visión y las metas del negocio.
Debido a que el funcional antes se involucraba en definiciones tecnológicas esto represento un reto
para adoptar su nuevo rol. El Dueño del Producto o Product Owner tenía que seguir principalmente
las siguientes actividades:
1. Entender las necesidades del negocio
2. Definir en conjunto con el negocio una lista de requerimientos ordenada de acuerdo a su
prioridad y valor de negocio.
3. Explicar a detalle cada requerimiento al Equipo de Desarrollo
4. Transmitir al equipo de desarrollo la meta a alcanzar en cada Sprint o Iteración.
Otras de las complicaciones en este rol fue que en ocasiones la persona que funge como Scrum
Master tomaba responsabilidades incorrectamente del Dueño del Producto ocasionando confusión
dentro del equipo de trabajo. Sin embargo, gracias a las retrospectivas de los Sprints se pudo
detectar y corregir estas inconsistencias.
El Equipo de Desarrollo o Programadores (Development Team).
Uno de los cambios importantes para los desarrolladores y difíciles de adoptar es que en este nuevo
marco de trabajo ellos no solamente están sentados en su cubículo esperando les llegue el
documento de lo que tienen que construir aislados del mundo exterior. El equipo de desarrollo en
Scrum se vuelve un rol más participativo en el proceso de entender las necesidades del negocio y los
requerimientos del producto que cumplen como solución a estas necesidades. Las actividades más
importantes del Equipo de Desarrollo Scrum son:
1. Entender los requerimientos de la lista ordenada.
2. Sugerir soluciones tecnológicas para cumplir con estos requerimientos.
3. Definir las tareas y los tiempos necesarios para construir las funcionalidades.
4. Codificar, diseñar, probar e implementar parcialidades del producto para el cliente.
5. Colaborar en cada iteración junto con el Dueño del Producto.
6. Apoyarse entre los miembros del equipo para resolver problemas
7. Mejorar el producto en cada iteración y sugerir mejoras en funcionalidades.
Probadores o Testers.
Este rol es parte del Development Team o Equipo de Desarrollo, sin embargo, Se describe en esta
sección ya que sus actividades son parte esencial y critica del ciclo de desarrollo. En el área de
aplicaciones no existe como tal un puesto de Tester y se tomó la decisión de que las pruebas
funcionales y de calidad deberían ser realizadas por el rol funcional, ya que viene ligado a los
criterios de aceptación que el mismo funcional define como dueño del producto.
El Tester realiza las siguientes actividades:
1. Diseñar el plan de pruebas.
47
2. Ejecutar las pruebas en base a los criterios de aceptación y los casos de prueba.
3. Notificar las fallas que puedan presentarse
4. Identificar mejoras y platicarlas con todo el Equipo Scrum.
5. Dar seguimiento a las fallas reportadas hasta que sean reparadas.
Uno de los retos fuertes que se enfrenta el rol de Tester, es la habilidad para colaborar con el equipo
de desarrollo, documentando las fallas, platicando de ellas con el fin de mejorar el producto y no con
el fin de señalar deficiencias en el producto.
4.3 DEFINICIÓN DE LOS REQUERIMIENTOS (PRODUCT BACKLOG)
Esta etapa del Proyecto, el Product Owner tiene la responsabilidad de elaborar el Product Backlog o
lista de requerimientos, para ello tiene entrevistas con el keyuser para conocer la necesidad y
entender los requerimientos funcionales.
En esta etapa no se requiere elaborar documentos pesados como diagramas uml u otro artefacto,
solamente se trata de escuchar al usuario y elaborar un listado de los requerimientos que le gustaría
tener en el sistema. La segunda actividad para completar el Product Backlog es que se tiene que
asignar una prioridad y un valor de negocio a cada requerimiento para dar un orden. Esta definición
se realiza entre el Product Owner y el KeyUser experto del negocio.
El Product Backlog resultante se ingresa en la herramienta TFS para su control y seguimiento:
Figura 0.10 Listado de Requerimientos Ordenados
Esta actividad se realiza en uno o dos días máximo, quizás no se tenga la visión completa de todo el
producto pero lo más esencial debería estar en esta primera versión del Product Backlog.
48
Figura 0.11 Definiendo un PBI en TFS
4.4 PLANEACIÓN DEL SPRINT (SPRINT PLANNING)
Posterior a la elaboración del Product Backlog, el Scrum Master organiza la reunión de la planeación
del Sprint donde participan el Product Owner y el Equipo de Desarrollo. La reunión se divide en 2
partes. En la primera parte, el Product Owner presenta al Equipo de desarrollo cada elemento del
Product Backlog explicando de qué se trata, esto con la finalidad de que los desarrolladores vayan
conociendo la necesidad de negocio y vayan pensando tecnológicamente como deberían construir el
producto. Posteriormente el Equipo de Desarrollo en base al orden asignado a cada elemento del
Product Backlog selecciona los que desea incluir en el Sprint para su construcción.
En la segunda parte de la reunión el Equipo de Desarrollo deberá determinar las tareas necesarias y
su tiempo para poder construir cada elemento del Product Backlog. En la división de las tareas se
deben definir con un tamaño pequeño no mayor a 2 días y el tiempo se debe asignar en horas, esto
es importante ya que permite estimar con una mayor exactitud. En esta parte el Scrum Master debe
cuidar que en la estimación de los tiempos deben participar exclusivamente los desarrolladores, la
principal razón es porque si ellos lo definen se sienten más comprometidos en entregar el producto
en sus tiempos y además de que se les otorga confianza en esas decisiones.
La experiencia en el piloto fue que en el primer Sprint en algunas tareas se tuvo una mala
estimación sin embargo, estos errores se reconocieron y se fueron afinando en los Sprints
siguientes.
El entregable de esta reunión es el Sprint Backlog, que consiste en un subconjunto de elementos del
Product Backlog que al final del Sprint se materializará en un incremento del producto funcional.
Todas las tareas y sus tiempos son registradas en el TFS para su control.
49
Figura 0.12 Sprint Backlog
4.5 DEFINICIÓN FUNCIONAL
Durante la ejecución del Sprint, una de las tareas iniciales es que el Team agregue más información
funcional al PBI o Requerimiento, esta tarea es importante ya que da mayor claridad a los
desarrolladores sobre lo que se espera tener construido, a esta actividad se le conoce como
definición funcional y consta de las siguientes secciones:
a) Restricciones o Constrainst.
Son reglas que se deben aplicar a nivel dato o campo de pantalla, por ejemplo: “que
solamente se acepten números en un campo de texto o que el campo sea obligatorio”.
b) Reglas de Negocio o Business Rules
Son reglas que se deben describir a nivel entidad o flujo de proceso, esto puede aplicar
en la realización de un cálculo, operaciones con fechas, ejecución de eventos u
operaciones con cadenas de texto. Por ejemplo: “Si la cantidad del producto recibido
excede a lo solicitado, se tendrá que notificar al supervisor por un correo electrónico”
c) Atributos y Entidades
Es el listado de las entidades y sus campos con el fin de conocer que información se
requiere almacenar. Por ejemplo: “Entidad Usuarios Campos: Nombre (150), Apellido
(100)”
d) Prototipos
En esta sección se adjunta imágenes del diseño de las pantallas de como espera el
usuario visualizar las pantallas. Es importante mencionar que estos prototipos son para
dar una idea al programador, sin embargo, se puede mejorar durante la construcción.
En esta sección es posible adjuntar otro tipo de artefacto que puedan aportar mayor
claridad, como son formatos o documentos del negocio.
50
Figura 0.13 Definición Funcional del PBI
Una vez que se tiene definido la definición funcional, el equipo de desarrollo tiene la responsabilidad
de analizarlo y aclarar dudas en caso surjan. Con todos estos elementos definidos los desarrolladores
pueden iniciar con la codificación, diseño y pruebas unitarias y empezar a construir un incremento
del producto.
4.6 PRUEBAS
Las pruebas son también una parte esencial, ya que uno de los valores de las metodologías ágiles es
“Entregar Software Funcionando”, esto significa que no tenga fallas. El proceso de las pruebas se
realiza en dos partes.
El primera parte es la planeación y se da al inicio del Sprint, donde el Tester se encargará de definir
los casos de prueba y los criterios de aceptación.
Para este proyecto piloto nos apoyamos de la herramienta Test Manager, dentro la cual se diseñó el
plan para los casos de prueba (test case).
Figura 0.14 Casos de Prueba
51
Parte de la definición del caso de prueba consiste en proporcionar los pasos que se tendrán que
realizar para probar cierta funcionalidad del producto.
Figura 0.15 Definición de los pasos a seguir en un Test Case
En el plan también se incluye definir las plataformas o ambientes sobre las cuales se van a ejecutar
las pruebas, esto con el fin de detectar incompatibilidades del producto en diferentes plataformas.
La segunda parte consiste en ejecutar las pruebas, esta actividad se realiza una vez que el Equipo de
Desarrollo ha generado una versión del Build lista para las pruebas funcionales. En esta actividad el
Tester deberá seguir los pasos definidos en el plan y documentar el resultado de caso paso
ejecutado, en el caso de que todos los pasos se realicen sin que se presenta alguna falla técnica o
de lógica se finalizara y se marcará ese caso de prueba como exitoso.
52
Figura 0.16 Ejecución de Caso de Prueba
Por otro lado en caso de que se presente una falla (Bug), se tendrá que documentar una falla y
notificar al equipo de desarrollo para que lo atienda y se corrija a la brevedad.
Figura 0.17 Notificación de una Falla
Una vez que el equipo de Desarrollo corrija las fallas, se deberá generar una nueva versión del Build
para que se ejecuten nuevamente las pruebas, este proceso finaliza cuando todos los casos de
pruebas definidos no presentan fallas.
Finalmente desde la definición de los requerimientos hasta la etapa de las pruebas, existen una serie
de actividades en las que debe participar todo el equipo Scrum, donde debe existir una buena
relación entre todos los elementos para que este ciclo pueda funcionar de manera efectiva y para
53
que la comunicación y la colaboración puedan darse de manera natural. En la figura 4.18 se
representa el ciclo de vida de las pruebas para desarrollar un producto de calidad.
Figura 0.18 Ciclo de Vida de un PBI en TFS
4.7 REUNIONES DE SEGUIMIENTO
Parte importante del seguimiento del proyecto piloto fueron las reuniones diarias o Daily Scrum. Se
consenso con el equipo realizar estas reuniones al final de cada día, las reuniones fueron dirigidas
por el Scrum Master y en ellas participaron el Equipo de Desarrollo y el Product Owner. La idea de
estas reuniones de no más de 15 minutos era conocer que se había trabajado en el día, si se tuvo
alguna complicación y que se planeaba realizar el día siguiente. En estas reuniones no se resolvían
problemáticas, ni tampoco se definían elementos nuevos, simplemente el Equipo platica del esfuerzo
realizado en el día.
El resultado de estas reuniones fue de mucho éxito en el proyecto, ya que ayudaba a enfocar
esfuerzos, a dar dirección en caso de haber dudas y sobre todo a mantener comunicados a todo el
equipo en cada avance que se daba. Por otro lado apoya al equipo a identificar los obstáculos que
podían impactar el avance del proyecto. Otro beneficio de estas reuniones es que apoyan a tener
una buena detección y control de los riesgos.
Las reuniones de Daily Scrum funcionaron para todo el equipo y ayudo inesperadamente a
incrementar la productividad. Uno de los retos en estas reuniones era evitar que se prolongaran más
de 15 minutos para lo cual el Scrum Master realizó un papel esencial para el correcto cumplimiento
de esta práctica.
En estas reuniones se incluyó al administrador de proyecto, su función de llevar una minuta de lo
que se platicó en las reuniones de Daily Scrum y compartirla a todos posteriormente, también
aporto buenos resultados, permitiendo tener una bitácora de hechos.
54
4.8 LIBERACIÓN DEL PRODUCTO.
Las liberaciones del producto se refieren a los despliegues parciales de las funcionalidades
construidas por el equipo de desarrollo. Las liberaciones de código se llevan a cabo a través de la
generación de Builds que se preparan desde la herramienta TFS. El Build de TFS es un servicio
configurable que de manera automatizada tiene la función de realizar la integración del código
fuente y compilar el producto para tener una versión funcional en algún ambiente compartido.
Para el proyecto piloto se utilizaron tres ambientes diferentes para las liberaciones de los Builds,
como muestra la figura 4.19.
Figura 0.19 Ambientes de Liberación del Producto
Ambiente Dev. Se refiere al ambiente de desarrollo, en este ambiente el Equipo de Desarrollo
realiza el despliegue de sus binarios para realizar sus pruebas funcionales, la generación de los
Builds se realiza varias veces durante el Sprint. Cada vez que se reportan fallas estas se corrigen y
es necesario generar una nueva versión del Build para liberación.
Ambiente QA. Una vez que el producto se ha probado satisfactoriamente en Dev se realiza un
nuevo Build pero ahora es para liberar en el ambiente de Calidad (QA), en este ambiente son los
usuarios quienes van a realizar pruebas con información más real. Si una falla se presenta en esta
ambiente se tendrá que notificar al equipo de desarrollo para que se corrija requiriéndose generar
un nuevo Build.
Ambiente PRD. Este ambiente es el productivo, las liberaciones se realizan cuando el Product
Owner autoriza que el producto no tiene fallas y que ha pasado por los dos ambientes anteriores,
para realizar este despliegue es necesario iniciar un proceso de control de configuración de activos
que en este estudio no tocaremos, sin embargo, si queremos remarcar que en el ambiente
productivo las liberaciones son controladas por el equipo de infraestructura y esto es a través de un
proceso de cambio definido.
Los Builds son configurados en la herramienta TFS por el Equipo de Desarrollo. Cada vez que se
tiene una funcionalidad construida se libera un nuevo Build para las pruebas.
55
Figura 0.20 Lista de Builds generados
Control de Código Fuente.
El control de las versiones y repositorio del código fuente se lleva a través del TFS y en el estudio
nos ayuda a mantener un control sobre los cambios que se van realizando al código durante todo el
proyecto. Contar con este control permite que varios programadores después de codificar y realizar
pruebas unitarias integraran su versión al producto de manera consistente y con una bitácora de
historial de los cambios que se realizaron o que funcionalidad se construyó.
Figura 0.21 Control de Código Fuente en TFS
Para tener una gestión flexible de las versiones del código en los diferentes ambientes, el Equipo de
Desarrollo tuvo que definir una estrategia de ramas (Branches), ya que debido a que cada
despliegue o liberación de versión tenía su ambiente, ya sea, desarrollo, calidad o producción.
Utilizar este esquema permite realizar cambios en paralelo en ambientes diferentes sin que sean
afectados en su desarrollo. En la figura 4.22 se presenta la estrategia de ramas utilizada para el
proyecto piloto.
56
Figura 0.22 Estrategia de Ramas para Liberaciones de Producto
4.9 REVISIÓN DEL SPRINT (SPRINT REVIEW) Y RETROSPECTIVA Al finalizar el Sprint, el Scrum Master organiza una reunión la cual divide en dos partes. En la
primera parte se realiza el Sprint Review, donde el equipo de desarrollo presenta la parte
incremental del producto construido, el objetivo es que tanto el Product Owner como el Key User
retroalimenten a todo el equipo sobre lo que sienten del producto. En esta presentación se reconoció
el trabajo del equipo de desarrollo y se expresaron ideas para mejorar algunas partes del producto.
La segunda parte de la reunión fue la Restrospectiva, en ella se trata de mejorar la productividad y
la eficiencia en el siguiente Sprint, básicamente todo el equipo respondió a tres preguntas básicas:
Que funciono bien?, Que No funciono? Y Que podemos hacer para mejorar?
En nuestro estudio durante los Sprints, las retrospectivas muestran los siguientes resultados:
¿Qué funcionó bien?
o Llevar a cabo el Daily Scrum
o Liberar al Team de actividades externas al proyecto
o El empleo de las herramientas para gestión del proyecto
o El seguimiento que dio la PMO
o Definir en tiempo y con claridad la especificación funcional.
Que no funcionó?
o Falta del diseño funcional en tiempo, provocando indefiniciones en las especificaciones
o No realizar pruebas funcionales en tiempo
o No registrar bugs en tiempo para su reparación
o No estimar correctamente las tareas
¿Qué hacer diferente para mejorar?
o Sensibilizar al Tester de la importancia de realizar las pruebas en tiempo y dar
seguimiento a esta actividad.
o Entrenar al Tester para que cuando identifique un bug en las pruebas lo registre al
momento.
o Que los desarrolladores se apoyen en base a su experiencia para estimar con mayor
exactitud y no dejando esta tarea solo en manos de una persona, apoyándose en la
técnica de póker planning.
57
4.10 HERRAMIENTA PARA MEDICIÓN DE LA PRODUCTIVIDAD
Gráfica Burndown
En nuestro proyecto piloto, mediante el registro en el TFS de las tareas realizadas diariamente se va
trazando una gráfica conocida como BurnDown, mediante está grafica el Equipo Scrum puede ir
monitoreando de manera sencilla, si el avance que se está obteniendo del día a día es lo que se
espera tener. Es una forma de monitorear si la entrega de valor al cliente se está dando en el tiempo
estimado, y en caso de existir un desvío tomar acciones al respecto.
En la gráfica de la figura 4.23, el color verde representa las horas trabajadas en el Sprint y el color
gris las horas por trabajar, la línea roja es la tendencia ideal, es decir, si el color gris está arriba de la
línea roja, representa un atraso en el proyecto. Como se puede ver existieron algunos pequeños
picos que no representaban un atraso importante y que se fue recuperando por el equipo de
desarrollo al final del Sprint.
Figura 0.23 Gráfica de Burndown de Seguimiento al Proyecto
La gráfica de Burndown nos da la visibilidad de que tan productivo está resultando el Sprint en
ejecución.
Velocidad
Otra gráfica que nos ayuda a medir la productividad del equipo de desarrollo, es la de velocidad,
para calcular la velocidad, al definir el Product Backlog el equipo de desarrollo asigna un valor que
represente el esfuerzo necesario para realizar un PBI determinado. Al final de cada Sprint la gráfica
muestra, cuanto esfuerzo se realizó en base al dato estimado para ello, como se ve en la figura 4.24.
58
Figura 0.24 Gráfica de Velocidad del Equipo
Por otro lado, está estadística nos ayuda a estimar futuros esfuerzos en otros Sprints, ya que nos da
una idea de cuánto esfuerzo puede ser manejado por un determinado equipo de desarrolladores.
4.11 HERRAMIENTA PARA ASEGURAMIENTO DE LA CALIDAD En el proyecto piloto los desarrolladores se apoyaron del uso de las pruebas unitarias, a través de
ellas, cada método de las clases desarrolladas es probado de acuerdo a criterios de aceptación
definidos por el Product Owner. La finalidad es reducir la cantidad de errores para no afectar las
futuras liberaciones del producto. En la figura se presenta una muestra del manejo de pruebas
unitarias dentro del ambiente de visual studio la cual es la herramienta donde los desarrolladores
codifican.
Figura 0.25 Uso de Pruebas Unitarias en el Código Fuente
59
Estas se ejecutan de manera automatizada cuando se está construyendo el producto, cuidando que
cada vez que se compile se tenga una versión sin errores.
El empleo de esta herramienta ayudo a tener un desarrollo ágil y con menos errores, ya que, cuando
se liberaba el producto al ambiente de calidad gran número de defectos estaban corregidos gracias a
las pruebas unitarias.
60
Capítulo 5
Metodología de la Investigación
5.1 MÉTODO DE LA INVESTIGACIÓN.
Este estudio experimental es de tipo correlacional ya que se mide el efecto de relación entre la
adopción de una metodología ágil y su impacto en la competitividad en una empresa.
Para ello se elabora un estado del arte para dar sustento a la investigación y el cual es fundamental
para entender las aportaciones de este trabajo. En él se presentan y analizan enfoques como la
competitividad en las organizaciones y se estudian cinco metodologías ágiles, aportando una guía
inicial en la investigación y conocimiento para interpretar los resultados del estudio.
Se empleó el método empírico como estrategia ya que se realizó una amplia investigación con un
estudio de caso detallado, en el cual mediante la selección de un proyecto piloto en la empresa
Cotemar se describe paso a paso la adopción de la metodología ágil Scrum.
Mediante esta evidencia empírica se busca completar este trabajo de investigación y a través de
hechos observables y documentados demostrar los resultados.
Las variables medidas en este estudio fueron:
Variables Sub-variables Relación
La metodología ágil Independiente
El grado de competitividad Productividad
Efectividad
Calidad
Valor entregado
Dependiente
Tabla 0.1 Variables a Medir
Para medir el grado de competitividad necesitamos obtener medidas de la productividad, la
efectividad, la calidad y el valor entregado al negocio, ya que estas variables tienen un impacto
directo en la competitividad de la empresa.
5.2 TÉCNICA DE RECOLECCIÓN DE DATOS
Las técnicas utilizadas para la recolección de datos, consistieron en el empleo de varias
herramientas, en la cual nos apoyamos durante la gestión del proyecto.
Las herramientas utilizadas en el estudio fueron:
Datos Estadísticos
Reuniones de Grupo
Cuestionarios
Entrevistas
Encuestas
61
La información obtenida con cada una de estas herramientas se fue dando en diferentes momentos
del proceso. El caso de los datos estadísticos se fue generando a través del registro de las
actividades en el TFS durante la ejecución de cada Sprint. Las reuniones de grupo se daban al final
del Sprint en la Retrospectiva y los cuestionarios y entrevistas se daban en cualquier momento que
era necesario.
5.3 POBLACIÓN Y MUESTRA
La población en este estudio fueron un grupo de cinco proyectos que se evaluaron de acuerdo a su
tamaño, duración, importancia y grado de compromiso del negocio. La muestra fue un proyecto que
cumpliera con los siguientes parámetros:
Dimensión Valor Deseado
Tamaño Mediano
Duración 3-5 Meses
Importancia Media
Grado Compromiso Media
Tabla 0.2 Población y Muestra
En el caso de estudio el proyecto que cumplió con estas condiciones fue el de Salary Plan, por lo
cual, fue el candidato muestra para adoptar la metodología Scrum y medir sus efectos en las
competitividad.
62
Capítulo 6
Análisis de Resultados
6.1 CUMPLIMIENTO DE LOS OBJETIVOS.
El objetivo de este estudio es demostrar que mediante la adopción de una metodología ágil como
Scrum, se puede mejorar la productividad de los equipos de trabajo, entregando valor en menos
tiempo y productos con mayor calidad.
Los objetivos específicos en este estudio fueron los siguientes:
a) Análisis de las metodologías ágiles más populares en la industria de
software.
En este documento se analizó de manera detallada la historia, el proceso y los roles
que participan en cinco metodologías ágiles.
o Scrum
o XP (Xtreme Programming)
o ASD (Adaptive Software Development)
o DSDM (Dynamic System Development Method)
o FDD (Feature Driven Development)
b) Realizar una comparativa entre metodología tradicional versus ágil
Esta comparativa es importante ya que permite identificar las principales diferencias
entre ambas metodologías y conocer en qué momento se debe aplicar una u otra.
c) Identificar los beneficios de una metodología ágil en los equipos de trabajo.
A través del estudio de las cinco metodologías y de las métricas que nos da el estudio
se pudo constatar los beneficios obtenidos.
d) Adoptar la metodología ágil Scrum a la gestión de un proyecto real.
Se llevó a cabo una descripción detallada de la adopción de Scrum en Cotemar aplicado
a un proyecto piloto.
e) Describir el impacto en la productividad y competitividad después de adoptar
Scrum.
Se realizó un análisis y mediciones de cómo la adopción de Scrum tiene un impacto
sobre la productividad, efectividad, calidad y el valor generado.
63
6.2 MÉTRICAS DEL PROYECTO.
Estadísticas utilizadas para medir la productividad:
o Seguimiento de la gráfica BurnDown.
Nos describe el esfuerzo en horas que está realizando el equipo para construir la parte
incremental del producto. En las figuras se muestra las mediciones de horas
completadas en 3 Sprints.
Figura 0.1 Burndown Sprint 1
Figura 0.2 Burndown Sprint 2
64
Figura 0.3 Burndown Sprint 3
o % Productividad de Valor Entregado.
Este indicador se calcula mediante la información de los puntos de esfuerzo asignados
a cada requerimiento (PBI). Para obtener el resultado se suman los puntos de
esfuerzos completados en el Sprint y este se divide entre los puntos de esfuerzos
planeados.
% Productividad=
∑(Puntos Esfuerzos Completados)/∑(Puntos de Esfuerzos Planeados)
Por ejemplo los puntos de esfuerzo planeados para los Sprints fueron:
No PBI Plan Esfuerzo
Sprint 1 Plan Esfuerzo
Sprint 2 Plan Esfuerzo
Sprint 3
1 1000 200 800
2 800 300 700
3 500 800 700
4 900 500 600
5 500 400 500
6 500 300 700
7 500 400 800
8 500 900 1000
9 600 900 800
10 400 900 800 11 800 1000
12 800 900
13 500 1000
14 600 800
15 500 1000
16 500 900
17 500 600
18 500 500
19 800 500
20 800
65
21 600
22 300
23 700
24 500
25 500
Productividad 93% 95% 89%
Tabla 0.1 Productividad de Valor Entregado
Los marcados en color verde representan los puntos de esfuerzo completados en el
Sprint y los rojos los que no se pudieron entregar.
En la siguiente figura se muestra la estadística de la productividad del equipo en base a
los puntos de esfuerzo trabajados por sprint.
Figura 0.4 Productividad por Puntos de Esfuerzo
o Velocidad del Equipo
Esta estadística de velocidad nos ayuda a responder preguntas tales como, cuanto
esfuerzo puede completar el equipo en un sprint?, cual es la velocidad máxima o
mínima del equipo?.
El responder estas preguntas nos ayuda a estimar en base a los puntos de esfuerzo la
velocidad necesaria que requerimos para cumplir con la entrega de valor a entregar en
un sprint.
66
Figura 0.5 Velocidad del Equipo
o Progreso de las historias de usuario completadas.
Este reporte nos presenta el porcentaje de avance que se tiene completado por cada
historia de usuario o requerimiento comprometido en un sprint. Con este informe se
tiene un panorama del trabajo realizado y grado de valor que se ha generado al
negocio por funcionalidad construida.
Figura 0.6 Progreso de las historias de usuario.
o % Eficiencia en Calidad (EQA).
Este indicador nos da una vista de que tan efectivo está siendo el equipo de desarrollo
para entregar un producto de calidad y funcional. Para obtener esta información se
calcula para cada Sprint mediante la suma de los defectos corregidos y se divide entre
los defectos latentes, es decir, defectos que continúan en el Sprint sin corregir.
%EQA= (Defectos corregidos/ Defectos latentes) x 100
Para el proyecto piloto estos fueron los resultados al final de cada Sprint:
67
Figura 0.7 Defectos Corregidos
Sprint % EQA
1 71%
2 88%
3 86%
Tabla 0.2 % Errores Calidad Corregidos
o Estadística de Builds
Ayuda a determinar el estado de cada Build desplegado en los ambientes. Nos puede indicar los Builds exitosos, o cuales son aquellos que vienen con más cambios en el código o cuales ya están preparados para ser liberados en un ambiente productivo.
Figura 0.8 Resumen de Builds
o Reuniones de Retrospectiva.
En estas reuniones que se dieron al final de cada Sprint, se procuró que entre todo el
equipo hubiera un debate constructivo sobre cómo se puede mejorar como equipo en el
proceso para poder ser más productivos y eficientes.
Se utilizó la técnica Delphi para llegar a los puntos que más impactan al proceso de manera positiva
o negativa, el resultado se presenta en las tablas siguientes:
Que se hizo bien? 1 2 3 4 5
Realizar los Daily Scrums X
Evitar efecto multitarea en los desarrolladores X
Uso de herramientas para gestión del proyecto X
Participación de la PMO en el Daily Scrum X
Definir en tiempo y forma de la especificación funcional X
68
Tabla 0.3 Resultado de lo que se hizo Bien
Que No se hizo bien? 1 2 3 4 5
Realizar pruebas funcionales fuera de tiempo X
Registrar bugs fuera de tiempo para su reparación X
No estimar correctamente las tareas X
Tabla 0.4 Resultado de lo que No se hizo bien
Que podemos mejorar? 1 2 3 4 5
Liberar de tareas paralelas al Tester para que pueda realizar sus
actividades en tiempo.
X
Concientizar al Tester de la importancia de generar bugs.
X
Mejorar la técnica de estimaciones de tiempo en tareas.
X
La interacción directa entre desarrollador y Product Owner sea
más directa y natural.
X
Tabla 0.5 Resultado de lo que se puede Mejorar 5=Fundamental
4=Importante
3=Mantener
2=Da igual
1= Remover
Con esta información recabada entre datos estadísticos, reuniones y cuestionarios, podemos tener
métricas de la productividad, calidad, adaptación y eficiencia de los equipos de trabajo utilizando
Scrum y tomar decisiones oportunas que impliquen realizar acciones que mejoren el proceso.
6.3 RESISTENCIA AL CAMBIO
Es importante conocer cuáles fueron los aspectos de la resistencia al cambio que se dieron durante
el estudio y describir cual fue el impacto sobre el mismo.
El cambio en sí mismo representa un reto para el ser humano, cambiar las cosas a las que se está
acostumbrado genera una reacción de querer regresar a los hábitos conocidos.
En nuestro caso de estudio el equipo que participo en los nuevos roles de Scrum, mostraron en
general una buena actitud al cambio del proceso y fueron positivos tratando de buscar siempre
como mejorar como equipo de trabajo.
Sin embargo, estar acostumbrados a realizar algunas actividades de la forma tradicional y muchas
veces sin darse cuenta, se tenían que tomar acciones para retornar al proceso correcto.
Cambios como:
o Identificar la prioridad de los requerimientos de acuerdo a su valor
o Registrar información de las actividades diariamente
o Realizar las pruebas como actividad en cada Sprint
o Involucrar a los usuarios de forma temprana en los entregables
69
o Aprender estimar en horas en lugar de días.
Fueron algunos puntos en los cuales el equipo tiene que madurar y acostumbrarse para ser más
eficientes en el proceso.
6.4 RETORNO DE INVERSIÓN ASOCIADO (ROI).
Generalmente en todo proyecto se desea que el coste del proyecto sea menor a los beneficios a
obtener y que el ROI se de en un lapso corto de tiempo. En una organización el implementar este
estudio no requiere de una inversión fuerte ya que en la mayoría de los casos se cuenta con la
infraestructura y los recursos necesarios (personas, procesos, habilidades, conocimientos,
herramientas), por otro lado, se espera un retorno de inversión maximizado por los resultados ya
que la organización obtiene una ganancia directa/indirecta a través de la entrega de productos de
mejor calidad y en menor tiempo permitiendo generar una mejor utilidad al negocio.
Para el presente estudio y proyecto piloto denominado Salary Plan, se calcula un impacto alto para el
nivel de ROI, ya que se espera que el proyecto ayude a reducir las problemáticas actuales
relacionadas a la inversión del tiempo que realizan puestos ejecutivos en la gestión de movilidad
salarial y por otro lado evitar posibles errores en tomas de decisión. Se espera que este proyecto
apoye en tener una gestión de salarios más efectiva. En la figura 6.5 se presenta un análisis
estratégico sobre qué tan rentable será el proyecto donde se incluye el retorno de inversión
esperado.
Figura 0.9 Evaluación ROI
70
Con la adopción de Scrum como metodología ágil, el objetivo es entregar valor en corto plazo
proveyendo de las herramientas necesarias al negocio para realizar esta gestión de manera efectiva.
6.5 IMPACTO EN LA COMPETITIVIDAD DE LA ORGANIZACIÓN. Podemos medir el impacto de este estudio basándonos en cinco puntos clave:
Innovación
Productividad
Efectividad
Menor Costo
Calidad
Cada uno de estos puntos representa un impacto en la competitividad, aunque afectan directamente
a procesos internos de la organización, muchas veces estos se ven reflejados en productos y
servicios externos que se entregan al cliente final. Para nuestro estudio el impacto es directamente a
un proceso interno.
Para poder dar un valor a estos puntos y de alguna manera medir el impacto, tenemos que
identificar donde aplica dentro del estudio cada punto.
o Innovación.
El adoptar un nuevo marco de trabajo como Scrum, es una innovación dentro de la
organización, ya que es una nueva forma de obtener resultados diferentes para entregar un
nuevo valor a los clientes.
o Productividad.
La productividad se puede entender como el esfuerzo que realiza un equipo de trabajo para
generar un valor al cliente en un tiempo dado. Una de las premisas de Scrum es entregar
valor en un periodo de no más de 30 días y apoyado de herramientas y procesos que
impulsan a los equipos de trabajo a ser más productivos. En el caso de este estudio se
midió la productividad a través del valor entregado al cliente al final de cada Sprint, además
los daily Scrum ayudaron a detectar en tiempo cualquier desviación y enfocar esfuerzos
para cumplir con el compromiso. Otro aspecto evidente de la productividad es que cada
miembro del equipo durante el Sprint tenía que estas interactuando a diario y ejecutando
actividades para tener un resultado de avance notable al final del día.
o Efectividad.
Este punto se refiere a saber si se logró alcanzar la meta propuesta, si se obtuvo el valor
esperado o que tan efectivos fuimos en el proceso. Parte de la estrategia de Scrum y de las
metodologías agiles es que precisamente se basan en un proceso incremental e iterativo lo
cual permite avanzar hacia el objetivo con entregas parciales del producto sin que el cliente
pierda la visión hacia dónde vamos, eso nos permite ser efectivos en entregar un producto
que resuelve una necesidad del negocio.
o Menor Costo.
71
Se puede entender como la habilidad de generar valor al cliente con el menor esfuerzo o
con el menor uso de recursos posibles. Muchas de los procesos tradicionales como el
cascada quizás en algunos casos resulten efectivos, pero siempre serán costosos, ya que
requieren la gestión de muchos procesos, la generación de mucha documentación y el
esfuerzo de mucha pero mucha gente. Por otro lado las metodologías ágiles como Scrum
basados en sus cuatro valores proponen un marco de trabajo más liviano donde impere la
interacción entre personas, la entrega de producto funcional, colaboración con el cliente y
la adaptación al cambio, basado en esto podemos reducir la cantidad de tiempo que se
desperdicia en crear artefactos, documentos u otro material que lo más probable no
agregue valor al producto. Por otra parte al trabajar en iteraciones pequeñas y tener como
objetivo entregar software funcionando se reducen los riesgos de fallas en ambiente
productivos que resultan mucho más costosas que tenerlas en los ambientes de desarrollo.
o Calidad.
La calidad se puede describir de diferentes maneras, para este estudio, la describiremos
como la habilidad de entregar al cliente un producto que apoye en el logro de sus objetivos
y cuyas funcionalidades lo deje satisfecho. En Scrum parte de sus principios se enfocan en
la calidad del producto algunos por mencionar serían:
1. La prioridad es satisfacer al cliente a través de la entrega temprana y continua
de software que aporte valor.
2. Entregar software funcionando.
Finalmente, si asignamos un valor a cada uno de los puntos anteriores y lo comparamos con los
resultados que se obtienen con la metodología tradicional en proyectos similares, se podría visualizar
el impacto en la competitividad en la adopción de Scrum en Cotemar, como muestra la figura 6.6.
Figura 0.10 Gráfica de Impacto en la Competitividad en la Adopción de Scrum
0
1
2
3
Innovacion
Productividad
Efectividad
MenorCosto
CalidadScrum
Tradicional
72
Capítulo 7
Conclusiones y Recomendaciones
7.1 CONCLUSIONES.
El propósito de esta investigación consistió en incrementar la productividad y la eficiencia de los
equipos de trabajo que participan en proyectos de desarrollo de software, a través, de la adopción
de una metodología ágil como Scrum y de la aplicación de prácticas y herramientas. Para poder
medir el grado de impacto en la organización se obtuvieron métricas cuantitativas y cualitativas de
productividad, efectividad, calidad y valor generado.
Con la adopción de Scrum, se logró:
o Rentabilidad y efectividad.
Esto se traduce a la entrega de valor al negocio en un lapso máximo de 30 días. (Time to
Market), a través de:
a) Estableciendo prioridades de valor en los requerimientos.
b) Realizando entregas parciales funcionales.
c) Empleando técnicas que mejoren la calidad del producto.
o Productividad
Esto tiene que ver con el incremento de la productividad de los equipos de trabajo
mediante el uso prácticas y herramientas como:
a) El empleo de pruebas automatizadas.
b) El uso de la refactorización de código.
c) La motivación y la confianza que se le otorga al equipo de desarrollo para la
toma de decisiones (Empowered Teams).
d) Las reuniones diarias.
o Calidad.
La entrega de un producto funcional de alta calidad se logra gracias al uso de:
a) Pruebas unitarias y pruebas de aceptación.
b) Integración continúa de código para revisión.
c) Retroalimentación constante durante cada iteración (Sprint Review).
d) Retrospectivas del proceso.
o La satisfacción del cliente.
El resultado final de un producto funcional y de valor entregado en un lapso corto de
tiempo impacta desde luego en un cliente cuyas necesidades y expectativas fueron
correspondidas de manera positiva.
Hoy en día las organizaciones se enfrentan a retos cada vez más grandes, se les exige, no solamente
tener una economía sólida, producir productos con calidad y con el mínimo coste sino también otra
característica importante para ser líder es que tiene que ser una organización ágil, en el sentido de
73
que tiene que aprovechar las oportunidades y generar valor a una gran velocidad que la impulse a
tener una ventaja competitiva sobre sus competidores.
En el estudio se demostró que la adopción de una metodología ágil como Scrum para la gestión de
proyectos de software es una opción viable e innovadora que puede llevar a una organización a
incrementar sus niveles de agilidad y competitividad.
Aunque entender la metodología resulte sencillo, la experiencia en este estudio demuestra que es
difícil implementarla y dominarla, existen varios aspectos que se tienen que madurar a través de la
práctica y de cambiar los viejos hábitos, lo cual no se logra con un solo proyecto. Sin embargo, en
este caso de estudio se lograron cambios positivos cuyos beneficios fueron tangibles en la
organización en un corto tiempo.
La metodología Scrum ayuda a minimizar los riesgos del fracaso de un proyecto de software y a
maximizar los esfuerzos de un equipo orientado a entregar un valor al negocio, sin embargo, la
adopción de una metodología ágil no es la bala de plata que resolverá todos los problemas a los que
se enfrentan los equipos en los proyectos de software, muchos de las problemáticas a superar
estarán relacionadas con las habilidades de gestión e interpersonales que posean los miembros de
los equipos. Es un proceso que requiere de habilidades de liderazgo y en la formación de equipos
auto dirigidos con gran cohesión y de alto desempeño.
En qué nivel deberían ser adoptados los métodos ágiles?
Esta pregunta de investigación se refiere a que si podemos continuar con metodologías tradicionales
por un lado y usar métodos ágiles por otro. La respuesta sería que no es recomendable tener
equipos de trabajo llevando dos metodologías con diferente enfoque, ya que esto generaría
conflictos entre los equipos de trabajo, confusiones sobre los modelos y sobre todo causaría malos
entendidos en el uso de cualquier metodología.
Si la organización busca maximizar los beneficios que una metodología ágil pretende ofrecer
entonces la adopción de esta metodología debería darse en un solo nivel aplicándolo a toda el área y
a todos los equipos de trabajo, definiéndose políticas y lineamientos que ayuden a infundir una
nueva cultura de trabajo.
Finalmente de la adopción de Scrum, se pudo aprender que los equipos de trabajo pueden ser más
eficientes y productivos cuando las personas interactúan y toman decisiones de manera frecuente,
no dejando que un plan sea quien de la dirección sino más bien a través de inspecciones frecuentes
se puedan aprovechar los cambios y adecuaciones que generen un valor real al negocio.
El uso de prácticas dentro los equipos de desarrollo como las pruebas unitarias, pruebas de
aceptación e integración continua sin duda son actividades que impulsan la productividad, la calidad
y la rapidez en el desarrollo de software.
Por otra parte los resultados que se obtenían de usar una metodología tradicional no eran aceptables
en un escenario donde los requerimientos y las necesidades van cambiando con gran velocidad y
donde el esfuerzo que se tenía que aplicar en los procesos y artefactos la mayoría de las veces
termina como un desperdicio de tiempo y costo.
74
Como parte del estudio se aplicó una encuesta a las personas que participaron en la adopción de
Scrum en Cotemar, en total participaron 15 personas las cuales tomaron diferentes roles en el
proyecto, los resultados fueron los siguientes:
75
Figura 0.1 Encuesta Adopción Scrum
7.2 RECOMENDACIONES.
Las recomendaciones que en algunos casos se identificaron como mejora y otras que dieron
resultado durante este estudio para una adopción exitosa de una metodología ágil, son las
siguientes:
1. Definir una visión de lo que se quiere conseguir con la adopción de Scrum.
2. Promover y presentar los beneficios que aportará Scrum a la organización.
3. Apoyarse de un experto que guíe la adopción de la metodología.
76
4. Seleccionar un proyecto candidato considerando tamaño, duración, importancia y grado de
compromiso del negocio.
5. Aceptar los cambios con actitud positiva.
En este estudio no se implementaron todas las prácticas ágiles por cuestión del tiempo, sin embargo,
su implementación impulsaría a obtener mejores resultados. La integración continua y la
automatización de pruebas funcionales pueden agregar un mayor incremento en la productividad y
en la calidad del producto final.
77
Capítulo 8
Referencias Bibliográficas
Libros Consultados:
[1] Porter, M. E. (1990). The Competitive Advantage of Nations. Harvard Business Review.
[2] Porter, M. E. (2004). Competitive Advantage. The Free Press. [3] Sutherland, K. S. (2012). Software In 30 Days. John Wiley & Sons, Inc.
[4] Warden, J. S. (2007). The Art of Agile Development. O´Really. [5] Cohn, M. (2010). Succeding with Agile. Ann Arbor, Michigan, USA: Addison-Wesley.
[6] James A. Highsmith, I. (1999). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New Youk, USA: Dorset House Publishing.
[7] Laanti, Maarit. (2012). Agile Methods in Large-Scale Software Development. Oulu, Finland: Universoty of Oulu
[8] Boehm., B. W. (1986). A Spiral Model of Software Development and Enhancement.
Redondo Beach, CA, USA: TRW Defense Syst. Group. [9] Beck, K. (1999). Extreme Programming Explained: EMBRACE CHANGE. Addison-
Wesley. [10] Highsmith, J. (2009). Agile Project Management. Addison-Wesley.
Sitios Web Consultados:
[1] Jarrow, C. (s.f.). Time Management Ninja. Recuperado el 09 de 08 de 2013, de
http://timemanagementninja.com [2] wikipedia. (s.f.). Waterfall Model. Recuperado el 01 de 08 de 2013, de
http://en.wikipedia.org/wiki/Waterfall_model [3] wikipedia. (s.f.). Software Development Process. Recuperado el 02 de 08 de 2013, de
http://en.wikipedia.org/wiki/Software_development_process [4] Library, C. P. (s.f.). Comparing XP and Watefall Software Development Process.
Recuperado el 01 de 08 de 2013, de
http://publications.lib.chalmers.se/records/fulltext/149235.pdf [5] wikipedia. (s.f.). Spiral Model. Recuperado el 02 de 08 de 2013, de
http://en.wikipedia.org/wiki/Spiral_model [6] wikipedia. (s.f.). Wikipedia. Recuperado el 8 de 8 de 2013, de
http://en.wikipedia.org/wiki/Gary_Hamel
[7] Manifesto for Agile Software Development. (2001). Recuperado el 01 de 08 de 2013, de http://www.agilemanifesto.org/principles.html
[8] Sutherland, J & Schwaber, K. (s.f.). La guía de Scrum. Recuperado el 09 de 08 de 2013, de
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf
[9] wikipedia. (s.f.). wikipedia. Recuperado el 10 de 08 de 2013, de
http://en.wikipedia.org/wiki/Extreme_programming#Activities [10] Q, J. M. (s.f.). Programación Extrema XP. Recuperado el 02 de 08 de 2013, de
hhttp://ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20EXTREMA.pdf
[11] Consortium, D. (s.f.). DSDM. Recuperado el 03 de 08 de 2013, de
http://www.dsdm.org/
78
[12] Fowler, M. (s.f.). Is Design Dead? Recuperado el 03 de 08 de 2013, de
http://martinfowler.com/articles/designDead.html [13] nebulon. (s.f.). FDD Processes. Recuperado el 05 de 08 de 2013, de
http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf [14] wikidot. (s.f.). Agile Methods of Software Development (DSDM). Recuperado el 14 de
08 de 2013, de http://dsdmofagilemethodology.wikidot.com/
[15] wikipedia. (s.f.). Dynamic systems development method. Recuperado el 04 de 08 de 2013, de Dynamic systems development method
[16] wikipedia. (s.f.). Feature-driven Development. Recuperado el 05 de 08 de 2013, de http://en.wikipedia.org/wiki/Feature-driven_development
Revistas y Actas de Conferencia Consultadas
[1] (ATI), A. d. (2010). Innovación, Calidad e Ingenierpia de Software. REICIS. [2] Royce, Winston. (1970). Managing The Development of Large Software Systems.
Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28. Los Angeles, USA.
79
Anexo - Glosario de Términos
Artefacto. El término artefacto en relación al desarrollo de software, es un producto tangible resultante del proceso del desarrollo de software. Algunos artefactos como los casos de uso, diagramas de clases u otra documentación ayudan a la descripción de una función, la arquitectura o el diseño del software. ASD (Adaptive Software Development). Metodología desarrollada por Jim Highsmith y Sam Bayer a principios de 1990. 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. Las prácticas de ASD están enfocadas a una adaptación continua. En ASD el ciclo clásico de planear-diseñar-construir es remplazado por un ciclo dinámico de Especular-Colaborar-Aprender ASD (Agile Software Development). Es un grupo de metodologías de desarrollo de software ágil, basadas en métodos iterativos e incrementales. Build. El Build se refiere al proceso de convertir los archivos de código fuente en artefactos que puedan ser ejecutados en otro equipo. Uno de los pasos más importantes en el Build es la compilación, donde el código fuente es convertido a un código ejecutable. Control de versiones. Se llama control de versiones a la gestión de diversos cambios que se realizan sobre los elementos de algún producto. Aunque un sistema de control de versiones se puede realizar de manera manual es recomendable apoyarse de herramientas que faciliten esta gestión. Ejemplos de este tipo de herramientas: Subversión, SourceSafe, TFS, Git. Coste. Es el valor monetario de los consumos de factores que supone el ejercicio de una actividad económica destinada a la producción de un bien o servicio. CRC (Collaborative and Responsability Cards). Las tarjetas de colaboración y responsabilidad permiten al equipo de desarrollo definir el diseño del sistema. Cada tarjeta representa un objeto, las responsabilidades se listan del lado izquierdo y las clases de colaboración se listan del lado derecho. Delphi. Es una técnica que consiste en encuestar a un grupo de expertos de manera iterativa, con el propósito de obtener sus juicios y propuestas, buscando puntos en común y organizando las respuestas para llegar a un consenso de sus opiniones. DSDM (Dynamic Systems Development Method). La metodología de desarrollo de sistemas dinámicos, 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. FDD (Feature Driven Development). Metodología ágil desarrollada por Jeff De Luca y Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. Keyuser. Es el usuario clave o experto del negocio, conoce bien la operación y el proceso. Modelo Waterfall o 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 descripción formal de este modelo fue en un artículo realizado por Winston W Royce en 1970. PMO (Project Management Office). La oficina de proyectos es un departamento que define estándares de proceso, generalmente asociados a la gestión de proyecto. La PMO u oficina de proyectos es encargada de la documentación, dirección y métrica de la ejecución de los proyectos.
80
ROI. El retorno de inversión o ROI, es una razón financiera que compara el beneficio o la utilidad obtenida en relación a la inversión realizada. Scrum. Metodología creada por Jeff Sutherland y Ken Schwaber para el desarrollo y el mantenimiento de software complejos, 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. SDD (Software Design Description). Es un documento que presenta diferentes vistas del diseño del producto. Este documento es elaborado por profesionales de software
SRS (Software Requirements Specification). Documento formal de los requisitos del sistema que describe de forma detallada el comportamiento que un sistema debe tener. El documento incluye casos de uso, requerimientos no funcionales y requerimientos de calidad. TFS (Team Foudation Server). Es una plataforma de colaboración desarrollada por Microsoft para llevar la gestión de un proyecto de software. Esta herramienta permite utilizar plantillas para llevar la gestión de proyectos basados en una metodología ágil. Time to Market. Es el lapso de tiempo que toma desde que el producto es concebido hasta que está disponible para venderse o usarse. UML (Unified Modeling Language). Es el lenguaje de modelado de sistemas de software que se realiza de manera gráfica para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y compuestos reciclados. XP (Extreme Programming). Metodología para desarrollar software creada por Kent Beck, la cual es capaz de adaptarse a los constantes cambios de los requerimientos. La metodología Extreme Programming 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, la simplicidad, la retroalimentación y el coraje.
81
Este documento contiene una licencia CC por/
This document is licensed CC by:
http://creativecommons.org/licenses/by-nc/4.0/legalcode
