Proyecto Final de Master

Fredd Darwin Villarreal Escamilla

Adopcin de una metodologa gil para proyectos de software

Caso: Cotemar empresa mexicana que brinda servicios al sector petrolero.

Trabajo de tesis para optar al Grado de: Master en Direccin Estratgica en Ingeniera de Software

Tutor: Dr. Sal Domingo Soriano

Universidad Europea Miguel de Cervantes Mxico, Agosto 01, 2013

Resumen
La ingeniera de software se ha convertido en una disciplina imprescindible en las empresas de hoy en da, una de las principales razones es debido a que la mayora de los proyectos que impulsan la competitividad en las empresas dependen en gran medida de las tecnologas de la informacin en las que viene inmerso el uso de software. Las metodologas giles han marcado en los ltimos aos una tendencia en su adopcin 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 mtodos giles en sus organizaciones. La razn principal de este cambio en las tendencias se debe a que se ha demostrado que el uso de mtodos predictivos o tradicionales para desarrollar software en ambientes donde las necesidades y la tecnologa cambian muy rpido produce resultados caticos. Es necesario cambiar la forma en que se produce software, la relacin existente entre la competitividad de una organizacin y los mtodos giles utilizados, est revelando hoy en da mayores beneficios en las organizaciones. La competitividad de las empresas depende en gran medida de la capacidad de innovacin que se tenga para producir productos y servicios. La innovacin tambin 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 anlisis terico de cinco metodologas giles ms usadas en la industria del software que ayudarn 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 adopcin de la metodologa gil Scrum en un proyecto piloto en la empresa Cotemar, una de las compaas lderes en la industria petrolera en Mxico, donde se experimentan escenarios de negocio que exigen imprescindiblemente una capacidad de innovacin, adaptacin y velocidad de respuesta para entregar valor y calidad a los clientes. Al finalizar la adopcin se presentan estadsticas de datos cuantitativos y cualitativos recogidos durante el proyecto para determinar el impacto en la competitividad de la organizacin.

Palabras clave: Metodologa, Productividad, Scrum, Competitividad, gil.

Fuente: http://www.forrester.com/aboutus, En Ingles, Ledo el 20 de Julio de 2013.

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

Keywords: Methodologies, Productivity, Scrum, Competitiveness, Agile

ii

Agradecimientos

Primeramente le doy gracias a mi Dios quien me brindo las oportunidades y la sabidura para cumplir con esta meta... A los amores de mi vida Karina, Shirel y Adriel, por ser mi motivacin... A mis respetables padres ya que esta tesis es fruto de su esfuerzo por darme una educacin... A mis hermanos, amigos y colegas que siempre estuvieron apoyndome... A todo el equipo TIC en Cotemar que colaboraron en este proyecto y que a travs del trabajo duro, coraje y respeto se lograron resultados increbles.

iii

NDICE
Captulo 1: Introduccin ................................................................................................................ 1 Captulo 2: Objetivo, Hiptesis y Alcance ...................................................................................... 3 2.1 Objetivo General .................................................................................................................... 3 2.2 Objetivos Especficos .............................................................................................................. 3 2.3 Hiptesis de la Investigacin .................................................................................................. 3 2.4 Alcance del Proyecto .............................................................................................................. 3 Captulo 3: Estado del Arte ............................................................................................................ 4 3.1 Competitividad Organizacional .............................................................................................. 4 3.2 La Ingeniera de Software ....................................................................................................... 5 3.3 Metodologas Tradicionales ................................................................................................... 5 3.3.1 Modelo Cascada (Waterfall Model) ....................................................................................... 5 3.3.2 Modelo Espiral........................................................................................................................ 7 3.4 Metodologas giles ............................................................................................................... 8 3.4.1 Manifiesto gil ....................................................................................................................... 8 3.4.2 Capacidad de Adaptacin ....................................................................................................... 9 3.4.3 Productividad en Equipos de Trabajo ................................................................................... 10 3.4.4 Mtodos giles ms 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 Captulo 4: Metodologa gil Propuesta ...................................................................................... 36 4.1 Proceso para la Gestin del Proyecto .................................................................................. 36 4.2 Roles Involucrados en Scrum ............................................................................................... 45 4.3 Definicin de los Requerimientos (Product Backlog) ........................................................... 47 4.4 Planeacin del Sprint (Sprint Planning) ................................................................................ 48 4.5 Definicin Funcional ............................................................................................................. 49 4.6 Pruebas ................................................................................................................................. 50 4.7 Reuniones de Seguimiento ................................................................................................... 53 4.8 Liberacin del Producto. ...................................................................................................... 54 4.9 Revisin del Sprint (Sprint Review) y Retrospectiva ............................................................. 56 4.10 Herramienta para Medicin de la Productividad ................................................................. 57 4.11 Herramienta para Aseguramiento de la Calidad .................................................................. 58 Captulo 5: Metodologa de la Investigacin ................................................................................ 60 5.1 Mtodo de la Investigacin. ................................................................................................. 60 5.2 Tcnica de Recoleccin de Datos ......................................................................................... 60 5.3 Poblacin y Muestra ............................................................................................................. 61 Captulo 6: Anlisis de Resultados ............................................................................................... 62 6.1 Cumplimiento de los Objetivos. ........................................................................................... 62 6.2 Mtricas del Proyecto. ......................................................................................................... 63 6.3 Resistencia al Cambio ........................................................................................................... 68 6.4 Retorno de Inversin Asociado (ROI). .................................................................................. 69 6.5 Impacto en la Competitividad de la Organizacin. ............................................................... 70 Captulo 7: Conclusiones y Recomendaciones ............................................................................. 72 7.1 Conclusiones......................................................................................................................... 72 7.2 Recomendaciones. ............................................................................................................... 75 Captulo 8: Referencias Bibliogrficas .......................................................................................... 77 iv

Anexo - Glosario de Trminos ..................................................................................................... 79

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

vi

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

vii

Captulo 1 Introduccin
1. INTRODUCCIN
Hoy por hoy las metodologas giles estn marcando un cambio en la industria del software, superando a las metodologas 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 generacin de un valor son los beneficios principales de estas metodologas. Los beneficios de la adopcin de una metodologa gil para impulsar el xito de los proyectos de software impactan de manera directa a la competitividad de una organizacin. 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. Segn Michael Porter La ventaja competitiva crece fundamentalmente a partir del valor que una empresa es capaz de crear2. La capacidad para crear valor en los proyectos de software se ha vuelto un desafo en las organizaciones actuales debido a la complejidad de la gestin de los requerimientos en un ecosistema donde las necesidades y la tecnologa cambian a una gran velocidad. A pesar de todos los obstculos y dificultades, vale la pena hacer el esfuerzo, vale la pena cambiar ya que si continuamos con los mismos mtodos y hbitos vamos a obtener el mismo resultado. Uno de los mayores beneficios que las organizaciones obtienen cuando adoptan una metodologa 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 segn Porter El valor producido por la mano de obra3 Para llevar a cabo este trabajo el departamento de Tecnologas de Informacin y Comunicaciones (TIC) en conjunto con el negocio deciden llevar el proceso de adopcin de la metodologa gil Scrum seleccionando un proyecto piloto donde se obtendrn datos que nos ayuden a medir el impacto en la competitividad de la empresa de acuerdo a las siguientes dimensiones: Productividad Calidad Valor Efectividad Innovacin

2 3

Fuente: Competitive Advantage, Michael E. Porter, The Free Press, 2004. Fuente: The Competitive Advantage of Nations. Michael E. Porter, Harvard Business Review, 1990.

Por otro lado Cotemar es una empresa que se caracteriza por innovar y de marcar condiciones de mercado mediante el uso de mtodos y tcnicas, buscando mantener un desempeo eficiente ante sus clientes. La mayora de los proyectos en la organizacin se apoyan en los sistemas de informacin donde el uso de software es fundamental. Desde su fundacin en 1979 Cotemar se ha convertido en un proveedor clave para la industria petrolera siendo su principal cliente Petrleos Mexicanos (Pemex) el sptimo productor de crudo ms grande en el mundo. Cotemar en los ltimos aos ha crecido en infraestructura, gente, procesos y tecnologa, 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 ms eficiente a los cambios y de anticiparse a ellos a exigido buscar mtodos ms 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.

Captulo 2 Objetivo, Hiptesis y Alcance

2.1 OBJETIVO GENERAL

Describir el grado de impacto en la competitividad de Cotemar, empresa mexicana, al adoptar una metodologa gil para la gestin de proyectos de software.

2.2
1. 2. 3. 4. 5.

OBJETIVOS ESPECFICOS

Analizar las metodologas giles ms populares en la industria de software. Realizar una comparativa entre la metodologa tradicional versus gil. Identificar los beneficios de una metodologa gil aplicada a equipos de trabajo. Adoptar la metodologa gil Scrum a la gestin de un proyecto real. Describir el impacto en la productividad y competitividad despus de adoptar Scrum.

2.3

HIPTESIS DE LA INVESTIGACIN

Con la adopcin de la metodologa 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 organizacin.

2.4

ALCANCE DEL PROYECTO

El alcance de este estudio abarca el anlisis de un grupo de 5 metodologas giles las cuales fueron seleccionadas de acuerdo a su xito en la actualidad, siendo estas las siguientes: 1. 2. 3. 4. 5. eXtreme Programming (XP). Scrum. Adaptive Software Development (ASD). Dynamic Systems Development Method (DSDM). Feature Driven Development (FDD).

Posteriormente se adoptar la metodologa gil Scrum en un proyecto piloto para medir los beneficios en la empresa Cotemar. El proyecto seleccionado est relacionado a la planeacin y administracin del presupuesto para los salarios de los empleados de Cotemar. Finalmente se realizar un anlisis de los resultados. Toda la informacin que comprometa las estrategias y planes de la empresa donde se realizar el estudio ser excluida del presente documento por motivos de confidencialidad.

Captulo 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. Segn Michael Porter en su artculo The Competitive Advantage of Nations4 indica que las compaas alcanzan una ventaja competitiva, a travs de acciones de innovacin y se habla de una innovacin en un sentido ms amplio, incluyendo nuevas tecnologas y nuevas formas de hacer las cosas. La innovacin puede manifestarse en el diseo de un nuevo producto, en un nuevo proceso de produccin 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 innovacin creada. La competitividad en una organizacin no solamente se puede basar en la aplicacin de cambios externos sino tambin en los internos. Los cambios internos son aquellos que son impulsados desde el interior de la organizacin 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 innovacin 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 segn Gary Hamel5 como innovacin estratgica. En este trabajo de investigacin 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 tecnologa y otros factores demandan optimizar nuestros procesos y generar un nuevo valor a la organizacin. 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 adopcin de una nueva metodologa para construir software en el cual se basa este estudio, donde a travs de nuevos principios y valores se pueda colaborar de una forma eficiente. Para que una organizacin 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 reduccin de los costos en la ejecucin de los procesos de negocio.
4 5

Fuente: Porter, M. E. (1990). The Competitive Advantage of Nations. Harvard Business Review. Fuente: http://en.wikipedia.org/wiki/Gary_Hamel, en ingles, ledo el 8 de agosto 2013

3.2

LA INGENIERA DE SOFTWARE

La ingeniera de software es una disciplina formada por un conjunto de mtodos, herramientas y tcnicas que se utilizan para desarrollar aplicaciones informticas (software). La ingeniera de software trata de sistematizar los procesos relacionados a la creacin de software con el fin de minimizar los riesgos del fracaso.

3.3
3.3.1

METODOLOGAS TRADICIONALES
MODELO CASCADA (WATERFALL MODEL)

El modelo en cascada es un proceso secuencial de etapas a seguir para el desarrollo de un producto, este modelo se origin para usar en las industrias de construccin y manufactura, aunque la primera descripcin formal de este modelo fue en un artculo realizado por Winston W Royce en 1970 y a consecuencia de no existir un modelo para el desarrollo de software se adopt este como el primer modelo. Las etapas de este proceso o ciclo de vida generalmente se conforman por las siguientes fases:
6

Especificacin de Requerimientos Diseo Construccin Integracin Pruebas Despliegue Mantenimiento

Figura 0.1 Modelo Cascada ANLISIS DE REQUERIMIENTOS.

Esta etapa consiste en recabar la informacin relacionada a la solucin deseada y a las necesidades del usuario final. Este anlisis incluye la definicin del problema, las metas y un claro entendimiento del negocio y sus reglas as como tambin identificar las funciones que el producto final debe considerar. Algunas de las tcnicas a utilizar para reunir esta informacin se basan en entrevistas, observaciones, creacin de prototipos, casos de usos y lluvia de ideas. Los resultados obtenidos son plasmados en un documento conocido como Especificacin de Requerimientos de Software (SRS), el

Fuente: Royce, Winston (1970),"Managing the Development of Large Software Systems", Technical Papers of Western Electronic Show and Convention (WesCon), Los Angeles, USA.

cual servir como entradas para la siguiente etapa del modelo. Los Requerimientos descritos en el SRS deben considerar los funcionales, no funcionales y la descripcin de comportamientos. DISEO.

Esta etapa toma como inicio el SRS de la etapa anterior y en base a ello define como el software debe ser construido. El diseo del software consiste en elaborar la arquitectura de software y hardware necesaria, especificar parmetros de rendimiento y seguridad, seleccionar la plataforma y el lenguaje de desarrollo, gestin de recursos y conectividad de las interfaces. Tambin en esta etapa se define el diseo de la interface de usuario, la navegacin y el acceso al sistema. La salida de este etapa es un documentos llamado Descripcin del Diseo del Software (SDD) el cual servir de entrada a la siguiente etapa del modelo. CONSTRUCCIN.

En esta etapa es donde inicia la construccin del producto tomando como base el SDD y el SRS de las etapas anteriores. En esta etapa el trabajo es realizado por los desarrolladores, diseadores 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. INTEGRACIN.

En esta etapa se integran los mdulos 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 evalan si el sistema cumple con la definicin inicial de los requerimientos. Las pruebas pueden ser categorizadas en pruebas unitarias, pruebas integrales y pruebas de aceptacin. 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 instalacin y uso en un ambiente productivo. El resultado es un documento de instalacin que define las configuraciones y pasos a ejecutar para instalar el producto. MANTENIMIENTO.

Esta ultima etapa del modelo, consiste en realizar ajustes, mejoras y reparacin de defectos al sistema o componentes individuales para mejorar el producto o el rendimiento del mismo. Una caracterstica 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 despus de finalizar cada etapa de otra manera se tendr que retornar, lo que produce el efecto de proyectos que nunca se concluyen. Otra caracterstica de este modelo es que es obligatoria la generacin de documentacin extensa con la finalidad de generar conocimiento al final de cada etapa, pero nuevamente si existe algn

cambio se deber actualizar toda la documentacin generada, lo que requiere invertir grandes cantidades de tiempo en documentacin que generalmente nadie lee. En general este modelo de proceso para la construccin 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 tecnologa de informacin donde actualmente se realiza este estudio los desarrollos de software siguen este modelo y muchas de las problemticas que se presentan en los proyectos son los siguientes: o o o o o Proyectos que nunca se concluyen Proyectos que se concluyen pero al final el producto ya no coincide con el proceso Despus de varios meses sin ver resultados se pierde el inters por parte del cliente Equipos de trabajo desmotivados Desconfianza para la realizacin 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 planeacin, el anlisis de riesgo y la construccin 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 transicin al mantenimiento. El aspecto positivo ms 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

al usuario en el desarrollo del producto desde etapas tempranas. Usando este modelo cascada. Sin embargo, el modelo espiral tiene algunas condiciones restrictivas a seguir: o o o Se requiere dedicar tiempo al anlisis de riesgos en cada iteracin Se requiere de tiempo del desarrollador para minimizar los riesgos Si los riesgos afectan al xito del proyecto el modelo espiral no debe utilizarse.

algunas

funcionalidades pueden ser entregadas al usuario de manera rpida a diferencia del modelo en

3.4

METODOLOGAS GILES

A diferencia del modelo en cascada (waterfall), las metodologas giles o conocidas tambin como desarrollo de software gile (ASD) son iterativas e incrementales, es decir, en cada iteracin, a travs del ciclo de vida del proyecto se entrega una parcialidad funcional del producto. Poco a poco se va desarrollando el producto durante cada iteracin 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 iteracin son la principal razn 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 iteracin 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 ao 2001 varios expertos que haban creado y probado las metodologas giles se reunieron con el objetivo de acordar y definir valores y principios que ayudaran a los equipos de trabajo a desarrollar software de manera eficiente, rpida y con adaptacin ante los cambios, este documento se conoce como el Manifiesto gil8 el cul da el verdadero significado a la palabra gil y consiste de 4 valores: Individuos y sus interacciones sobre procesos y herramientas Software funcionando sobre documentacin extensa Colaboracin con el cliente sobre negociaciones contractuales Respuesta al cambio sobre seguir un plan

Estos valores conforman la mdula principal de cualquier metodologa gil y marca la diferencia sobre las metodologas tradicionales, por otro lado, estos valores dieron origen a 12 principios giles9: 1. 2. La prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software que aporte valor Dar la bienvenida a los cambios, an que se den en el desarrollo. Se aprovechan los cambios para dar una ventaja competitiva al cliente.

8 9

Fuente: http://www.agilemanifesto.org/, En Ingls, ledo 24 de Mayo del 2013. Fuente: http://agilemanifesto.org/principles.html, En Ingls, ledo el 24 de Mayo del 2013.

3. 4. 5. 6. 7. 8. 9.

Entregar software funcionando, de un par de semanas a un par de meses, con la preferencia de un intervalo de corto tiempo. Personas del negocio y desarrolladores deben trabajar juntos diariamente en el proyecto. Construir el proyecto alrededor de individuos motivados. Dar el entorno y el apoyo que necesitan y confiar en ellos para tener el trabajo terminado. El mtodo ms eficiente y efectivo de transmitir informacin dentro el equipo es una pltica cara a cara. El software que funciona es la medida primaria de progreso. Los procesos giles promueven un desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. La atencin continua a los detalles tcnicos y a los buenos diseos mejora la agilidad.

10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de los equipos auto organizados. 12. En intervalos regulares, el equipo reflexiona en cmo llegar a ser ms efectivos realizando ajustes a su comportamiento. Estos principios describen una nueva mentalidad para abordar los proyectos de desarrollo de software, ofreciendo una nueva solucin que se basa en la simplicidad, en la interaccin de personas y en cmo podemos generar valor siendo eficientes. gil significa entregar software que aporte valor, a travs, de la colaboracin cercana de un equipo de trabajo que acepta cambios en los requerimientos con actitud y mentalidad positiva.

3.4.2

CAPACIDAD DE ADAPTACIN

El cuarto valor del manifiesto gil se refiere a la capacidad de adaptacin, es decir, que tan rpido nos adaptamos a los cambios y que tan flexibles somos para aceptar y responder a esos cambios. Para tener una buena capacidad de adaptacin 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 difcil. Segn Mike Cohn uno de los grandes impulsores de las metodologas giles, en su libro Succeeding with Agile10 menciona algunos de los grandes retos que los equipos de trabajo tienen que enfrentar para conseguir una buena adaptacin a los cambios: 1. Aprender nuevas habilidades tcnicas. Es comn 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 necesitarn aprender a evolucionar el diseo de un sistema, es decir, colaborar para mejorar las ideas. Los testers o los de pruebas necesitarn aprender a generar casos de prueba de valor sin generar tanta documentacin y aprendiendo a automatizar las pruebas. 2. Aprender a pensar y trabajar como un equipo. Muchos de nosotros hemos disfrutado trabajar solos, en nuestro cubculo y con nuestros audfonos a todo volumen y poca interaccin con el equipo, Tu desarrolla tu parte y yo har la ma, nos hablaremos cuando integremos las partes, los equipos giles no deben pensar en trminos de tus tareas o mis
10

Fuente: Mike Cohn. 2010, Succeeding with Agile, Addison-Wesley

tareas sino en nuestras tareas. Adoptar esta mentalidad crea un sentido de responsabilidad
compartida que elevar los niveles de colaboracin en el equipo. 3. Aprender a cmo 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 obstculos que puedan afectar el avance de las tareas. Las personas que logren aprender estas habilidades podrn incorporarse fcilmente a los procesos giles de desarrollo de software y tendrn una gran capacidad de adaptacin 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, informacin, tecnologas mediante los cuales podemos generar un valor. Las organizaciones deben prestar mayor atencin a los temas de productividad, por ejemplo implementando en sus modelos de trabajo tcnicas para responder ms rpido a los inevitables cambios. Es notable remarcar que dos de los mtodos 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 ms resultados, hay que darles tambin el derecho a ellos de declinar o no aceptar ir a esas reuniones. 2. Liderar con el ejemplo. Como lder tus acciones deben ser el parmetro 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 comunicacin. La mala comunicacin es uno de los factores que reducen la productividad de los equipos. Se deben establecer de forma clara las expectativas y los canales de comunicacin. 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 da, 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 obstculos. 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 lder de equipo. 6. Proveer de las herramientas apropiadas. Un buen lder debe facilitar de las herramientas adecuadas para que el equipo pueda desempear su trabajo de manera efectiva.

11

Fuente: http://timemanagementninja.com, en Ingles, Ledo el 9 de agosto 2013

10

7.

Proveer de un buen espacio laboral. El lugar de trabajo es un elemento importante a considerar, trabajar en cubculos cerrados, con mala iluminacin, 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 lder tiene que decidir todo entonces se convierte en un cuello de botella afectando la productividad del equipo, por otro lado, el lder 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 obstculos para el equipo, solo queda uno por remover y ese eres t mismo. Habrs 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 tambin estas recomendaciones son de gran ayuda cuando adoptamos una metodologa gil.

3.4.4 3.4.4.1
HISTORIA

MTODOS GILES MS ADOPTADOS SCRUM

Ken Schwaber y Jeff Sutherland

12

presentaron conjuntamente por primera vez Scrum en la

conferencia OOPSLA en 1995 . Scrum es un marco de trabajo para el desarrollo y el mantenimiento de productos complejos que ha sido utilizado desde los aos 90, en el cual las personas pueden afrontar complejos problemas adaptativos, a la vez que entregan productos del mximo valor posible de forma productiva y creativa. Scrum es: Ligero Fcil de entender Extremadamente difcil 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 propsito especfico 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 Espaol, Ledo el 9 de agosto 2013

11

Figura 0.3 Proceso Scrum Scrum se fundamenta en la teora emprica de control de procesos o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basndose en lo que se conoce. Scrum emplea una aproximacin iterativa e incremental para optimizar la predictibilidad y controlar el riesgo. Tres pilares soportan toda implementacin de control emprico de procesos: transparencia, inspeccin y adaptacin. 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 comn para referirse al proceso. Inspeccin. Todo el equipo en Scrum debe inspeccionar frecuentemente los artefactos y monitorear el avance para detectar variaciones no deseables. Adaptacin. Si un inspector detecta que algn aspecto del proceso se desva de los lmites aceptables, y que el producto resultante no ser aceptable, el proceso o el material que estn siendo procesados debern ser ajustados para minimizar desviaciones mayores. ROLES. El equipo Scrum consiste en un dueo 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 diseado para optimizar la flexibilidad, la creatividad y la productividad. Los equipos en Scrum realizan entregas incrementales del producto, asegurando que se tiene una versin potencialmente til y funcional del producto.

12

Dueo 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 gestin incluye: o o o Describir de manera clara los requerimientos. Definir el valor de negocio y la prioridad de cada requerimiento para que el equipo de desarrollo conozca que requerimientos atender primero. Asegurar que el equipo de desarrollo entiende de manera clara cada requerimiento.

El dueo 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 organizacin 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 caractersticas: o o o Son auto-organizados. Son Multifuncionales. 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 lder servil al servicio del equipo Scrum. o Servicios del Scrum Master al Product Owner a) b) c) d) e) o Encontrar tcnicas para gestionar el Product Backlog Comunicar la visin y objetivos del Product Backlog Ensear a crear las historias de usuario Entender el proceso emprico y de adaptacin. Facilitar los eventos de Scrum

Servicios del Scrum Master al Equipo de Desarrollo a) b) c) d) e) Entrenar al equipo de desarrollo en ser auto-organizados y multifuncionales. Formar y liderar a los equipos de desarrollo a crear productos de alto valor. Eliminar impedimentos que afecten el avance del equipo. Facilitar los eventos de Scrum Entrenar al equipo a entender Scrum.

Eventos. En Scrum existen eventos prescritos, con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Se utilizan eventos en la forma de bloques de tiempo (timeboxes), de modo que todos tienen una duracin mxima. Esto asegura que se emplee una cantidad apropiada de tiempo en la planificacin, de forma que no se admita desperdicio en este proceso de planificacin.

13

Adems del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad para la inspeccin y adaptacin de algn aspecto. Estos eventos estn especficamente diseados para habilitar la vital transparencia e inspeccin. La falta de alguno de estos eventos da como resultado una reduccin de la transparencia y constituye una oportunidad perdida para inspeccionar y adaptarse.

Sprint. El corazn 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 Reunin de Planificacin del Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily Scrum), el trabajo de desarrollo, la Revisin del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective). Los Sprints habilitan la predictibilidad al asegurar la inspeccin y adaptacin del progreso hacia un objetivo, al menos en cada mes de calendario. Los Sprints tambin limitan el riesgo al incurrido en el coste de un mes de calendario. Los Sprints contienen y consisten en:

Reunin de Planificacin del Sprint (Sprint Planning Metting) Es en esta reunin de no ms de 8 horas se realiza el plan de que es lo que se va a entregar al finalizar el sprint. La reunin 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 reunin 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 da. 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 reunin que tiene lugar todos los das con una duracin 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 prediccin de lo que realizara antes del siguiente. Bsicamente en esta reunin el equipo de desarrollo responde a tres preguntas: 1. 2. 3. Que se trabajo el da de hoy? Que actividades se planean realizar el dia de maana? Existe algn 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 reunin no es de seguimiento ni tampoco de reporte de estado.

14

El principal beneficio de esta reunin es que mantiene comunicados a todo el equipo Scrum y permite la deteccin temprana de impedimentos. Constituye una reunin clave de inspeccin y adaptacin. Revisin del Sprint (Sprint Review) En esta reunin se realiza un inspeccin sobre el incremento del producto hecho y adaptar el Product Backlog en caso de ser necesario. En esta reunin 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 adems 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 reunin el equipo Scrum se examina as mismo y crea un plan de mejoras para aplicarse en el siguiente Sprint. En esta reunin se examinan a las personas, herramientas y procesos y se busca responder bsicamente a tres preguntas: 1. 2. 3. Que hicimos bien en el Sprint? Que no se hizo bien? 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 prcticas para hacerlos ms efectivos. Al final de esta reunin 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 inspeccin y adaptacin. 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 esttico, durante el proceso de construccin en cada incremento la lista puede ir cambiando y evolucionando para tener un producto ms adecuado, competitivo y til. El product Backlog tiene como atributos su descripcin, su priorizacin y el valor de negocio que aporta. Los cambios en los requerimientos de negocio, las condiciones de mercado o la tecnologa podran generar cambios sobre el Product Backlog. La definicin a detalle de cada elemento del Product Backlog se lleva a tiempo parcial dentro el Sprint entre el Product Owner y el Equipo de Desarrollo. El equipo de desarrollo es el responsable de proporcionar todas las estimaciones para cada elemento de la lista. Seguimiento del Avance (Burndown) En cualquier momento durante el Sprint es posible sumar las horas del trabajo total restante para alcanzar el objetivo y medir el avance. Existen varias tendencias de trabajo consumido como el Burndown Chart que pueden ayudar a predecir el progreso. Sprint Backlog

15

Es el conjunto de elementos seleccionados del Product Backlog para el Sprint, ms un plan para entregar un incremento del producto. Es una prediccin 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 ejecucin 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 estimacin de trabajo restante.

3.4.4.2
HISTORIA

EXTREME PROGRAMMING

El origen Extreme Programming (XP) inicio en los 90s cuando Kent Beck trabajando en un proyecto para Chrysler buscaba una mejor forma de crear software 13. Una de las caractersticas principales de este mtodo que lo diferencia del modelo en cascada es que se basa en la adaptabilidad en lugar de la predictibilidad. La razn 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 metodologa que sea capaz de adaptarse a los constantes cambios de los requerimientos. CICLO DE VIDA. El enfoque de esta metodologa es generar el ms alto valor al cliente de la manera ms rpida posible. A diferencia del modelo en cascada que tiene que seguir de manera secuencial las etapas de planeacin, anlisis y diseo, en XP los programadores hacen todas estas actividades en cada iteracin del desarrollo. La metodologa Extreme Programming o XP inicia con la planeacin y todas las iteraciones consisten de cuatro fases bsicas: Planear, Disear, Codificar y Probar. Los valores primordiales para llevar este ciclo de vida son la comunicacin continua entre el cliente y los programadores, la simplicidad para disear la solucin, la retroalimentacin de las pruebas de aceptacin 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 Ingls, Ledo el 10 de Agosto 2013.

16

PLAN DE LIBERACIN (RELEASE PLANNING). En esta etapa se organiza la reunin de Planning Game donde el cliente se rene 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 liberacin inicial el cual ser la base para la planeacin de las iteraciones.

PLANEACIN DE LA ITERACIN (ITERATION PLANNING). En esta etapa se organiza una reunin para elaborar el plan de las tareas que el equipo de desarrollo necesita realizar para entregar un incremento del producto al final de la iteracin. Para ello el cliente selecciona las historias de usuario del plan de liberacin que desea sean incluidas en la iteracin, 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 tcnico del trabajo que el equipo de desarrollo va a realizar

DISEO (DESIGNING). La iteracin en XP inicia con el diseo, un buen diseo es lo que te permite realizar cambios de manera simple al software sin afectar la funcionalidad. La idea principal del diseo incremental es la simplicidad, es decir, hacer solo lo necesario sin agregar funcionalidad extra que no se necesita en ese momento, emplear buenas prcticas para el diseo de las clases, como estndares de nombres y usar las tarjetas de responsabilidades y colaboracin de clases (CRC), esto permite que los miembros del equipo contribuyan con ideas y considerarlas en el diseo. 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 rene en sesiones rpidas de diseo antes de la iteracin y revisiones de diseo durante la iteracin a travs de la refactorizacin de cdigo. Extreme Programming emplea tcnicas como la integracin continua de cdigo, las pruebas unitarias y la refactorizacin de cdigo.

CODIFICACIN (CODING) Uno de los elementos ms importantes en un proceso de desarrollo de software es el cdigo, 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 programacin en pares (Pair Programming) por dos programadores trabajando juntos en un solo equipo, permite la generacin de cdigo de alta calidad. El cdigo da la oportunidad de comunicar de una forma clara y consistente una idea, esta comunicacin se transforma en aprendizaje y reduce la probabilidad de malas interpretaciones.

DESARROLLO GUIADO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT) XP incluye una serie de prcticas para pruebas. Cada miembro del Equipo, Desarrolladores, Clientes y Testers realizan su propia contribucin para obtener un producto de calidad. Primero los Desarrolladores a travs del desarrollo orientado a pruebas (test-driven development) proveen la primera lnea de defensa, realizando pruebas unitarias automatizadas de cada parte construida, asegurando que el cdigo tecleado no presenta ninguna falla tcnica. Posteriormente el Cliente realiza las pruebas funcionales y de lgica del producto, verificando que el producto realiza lo que se espera que haga y finalmente los Testers mediante pruebas de exploracin buscan fallas. Cuando el Tester identifica la falla,

17

el equipo debe realizar un anlisis de causa raz y considerar como mejorar el proceso para prevenir fallas similares en el futuro. Los Testers tambin son responsables de explorar las caractersticas 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 ms rpida de generar un producto de calidad. PRUEBAS DE ACEPTACIN (ACCEPTANCE TEST) Las pruebas de aceptacin 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 aceptacin fueron exitosas. Una historia de usuario no se considera terminada si alguna de sus pruebas de aceptacin no paso. Es responsabilidad del equipo de desarrollo calendarizar el tiempo en cada iteracin para la correccin de fallas. Es recomendable que estas pruebas de aceptacin sean automatizadas para que sean realizadas de manera ms 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 recproca y bsicamente se basa en la retroalimentacin del cliente durante la fase de desarrollo y sobre todo de las pruebas de aceptacin. Cada retroalimentacin del cliente se convierte en la base para volver a entrar al ciclo de diseo, cdigo, prueba y escuchar, si el cliente est satisfecho con los resultados la iteracin termina en ese momento y el diseo de la nueva iteracin 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 planificacin de la liberacin (relase planning). Son los encargados de transmitir la visin, identificar y describir las historias de usuario, determinar cmo agrupar las funcionalidades en pequeas 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, tambin ayudan a comunicar los requisitos, a travs, de la creacin de pantallas prototipo, en la revisin 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 ms 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 planificacin (Planning Game). Los programadores invierten la mayora del tiempo haciendo programacin en parejas, codificando, realizando pruebas unitarias, refactorizacin y generando incrementalmente el diseo y la arquitectura de la aplicacin. Otras actividades son la correccin de fallas, la preparacin de las liberaciones y de realizar integracin continua. Los programadores tienen que trabajar en conjunto con el cliente para aclarar dudas sobre lo que se tiene que construir.

18

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 codificacin y deben proporcionar informacin 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 bsicamente 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 facilitndoles 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 ms importantes del Coach es ayudar al equipo a interactuar con el resto de la organizacin. Pero sobre todo los coaches ayudan a los miembros del equipo a ser disciplinados, ayudndolos a que sigan las prcticas de gestin de riesgos, desarrollo orientado a pruebas y el uso de diseo incremental. PRCTICAS. Extreme Programming tiene 12 prcticas agrupadas en cuatro reas, derivadas de las mejores prcticas de la ingeniera de software:

Figura 0.5 Prcticas 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 PLANIFICACIN (PLANNING GAME). Es una reunin que ocurre una sola vez por iteracin y se define lo siguiente:

19

Dos preguntas clave en el desarrollo de software: 1. 2. Predecir que se puede lograr en la fecha comprometida Determinar que se puede hacer posteriormente

Prediccin exacta no es necesaria Planeacin de Liberacin XP (Release Planning): o o El Cliente presenta las funcionalidades requeridas Programadores estiman dificultad Iteraciones de 2 semanas Cliente presenta las funcionalidades requeridas Programadores detallan las tareas necesarias Los miembros del equipo se comprometen por las tareas Entregar software funcional al final de la iteracin.

Planeacin de Iteracin XP (Iteration Planning) o o o o o

PRUEBAS DEL CLIENTE (CUSTOMER TEST). El cliente define las pruebas de aceptacin por funcionalidad. El equipo implementa pruebas automatizadas de cada funcionalidad.

LIBERACIONES PEQUEAS (SMALL REALEASES). En cada iteracin el Equipo libera software funcional y probado El cliente puede evaluar y liberar a usuarios finales y proveer retroalimentacin

DISEO SIMPLE (SIMPLE DESIGN). Durante la planeacin y codificacin del software mantener un diseo simple y orientado nicamente a lo que se necesita construir en la iteracin. Los equipos disean y revisan el diseo a travs de la refactorizacin en cada iteracin.

PROGRAMACIN EN PAREJAS (PAIR PROGRAMMING). La codificacin del software debe realizarse en parejas de 2 programadores en el mismo equipo. La resolucin de problemas de cdigo en pares da como resultado una mejor calidad en el cdigo Trabajar en parejas tambin permite transferir conocimiento.

DESARROLLO DIRIGIDO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT O TDD). Equipos usan TDD durante la codificacin probando al momento lo que se construye. Facilidad de producir cdigo probado al 100%

MEJORA DEL DISEO (DESIGN IMPROVEMENT). Refactorizacin de las clases y mtodos diseo. INTEGRACIN CONTINUA (CONTINUOS INTEGRATION). Liberaciones frecuentes del producto funcional, despus de la codificacin y las pruebas automatizadas. utilizando tcnicas y patrones para un mejor

20

PROPIEDAD COLECTIVA DEL CODIGO (COLLECTIVE CODE OWNERSHIP). Cualquier pareja de programadores puede mejorar cualquier cdigo en cualquier momento Todo el cdigo obtiene beneficios de todo el equipo

CODIFICACIN STANDAR (CODING STANDARD). Usar un estndar de codificacin. Todo el cdigo del sistema debe verse como si fuese codificado por una sola persona. el cdigo debe ser familiar para todos

METAFORA (METAPHOR). Los equipos XP deben desarrollar una visin comn 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 iteracin Evitar tiempos extras y mantener el trabajo de 40 horas a las semana Proyectos de marchas forzadas son improductivos y de mala calidad

COMUNICACIN. Una de las causas de que los proyectos fracasen se deben a una mala comunicacin del equipo, XP a travs de las prcticas como la programacin por parejas y el desarrollo dirigido por pruebas permite que programadores y clientes estn siempre comunicados, por otro lado XP usa el rol de Coach quien tiene la funcin de detectar cuando no haya una buena comunicacin y establecer canales claros de comunicacin entre el equipo. SIMPLICIDAD. La simplicidad en XP se enfoca en el diseo y la codificacin de las necesidades que se tengan en el presente y no preocuparse por hacer algo por las futuras. Por otra parte el emplear un diseo y codificacin simple, ayuda a dar claridad y entendimiento del producto a todo el equipo. RETROALIMENTACIN. En XP la retroalimentacin ocurre durante todo el ciclo de vida, por ejemplo durante la planeacin del juego, durante las pruebas unitarias y de aceptacin y en general durante todo el proyecto las mismas prcticas impulsan a tener una clara retroalimentacin del estado del sistema. Una buena retroalimentacin se basa en una buena comunicacin 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 cdigo se puede mejorar siempre, para reconocer cuando algo no funciona y se debe cambiar, coraje para apoyarse de otro miembro del equipo y resolver un problema.

21

3.4.4.3
HISTORIA

ADAPTIVE SOFTWARE DEVELOPMENT (ASD)

Metodologa 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 mtodo fue probado en varios proyectos y durante los siguientes aos se entregaron satisfactoriamente ms de 100 proyectos utilizando estas prcticas. A mediados de los 90 el inters sobre la compleja adaptacin 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 teora 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 prcticas de ASD estn enfocadas a una adaptacin continua. En ASD el ciclo clsico de planeardisear-construir es remplazado por un ciclo dinmico 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 colaboracin 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 planeacin, simplemente reconoce la realidad de la incertidumbre. La especulacin reconoce el carcter incierto de problemas complejos y promueve la exploracin y la experimentacin. En la especulacin se realizan varias actividades de iniciacin y de planeacin pero los 3 artefactos ms importantes a obtener sern elaborar una visin del producto, definir el alcance del proyecto y finalmente obtener un plan de entregas basado en funcionalidades. Primero, la Iniciacin del proyecto involucra definir la visin, los objetivos, las restricciones, la organizacin del proyecto, identificar los requerimientos, los alcances y los riesgos. La iniciacin puede ser realizada en un perodo de dos a cinco das para proyectos pequeos o puede tomar de dos a tres semanas para proyectos grandes. Durante las sesiones de iniciacin los requerimientos pueden ser recolectados con suficiente detalle para identificar funcionalidades y establecer los modelos de objetos, datos u otro modelo arquitectnico.

22

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 nmero de iteraciones y asignar el tamao en tiempo de cada una de ellas. Para proyectos pequeos a medianos las iteraciones puede ser de dos a ocho semanas. El tamao del proyecto y el grado de incertidumbre son dos factores que determinan el tamao de la iteracin. Cuarto. Los miembros del equipo deben definir un tema u objetivo para cada iteracin. Cada iteracin entrega un conjunto de funcionalidades para revisin del cliente. Desarrolladores y clientes asignan las funcionalidades a trabajar en cada iteracin. El criterio ms importante para la asignacin de funcionalidades es que en cada iteracin se debe entregar un conjunto de funcionalidades visibles y tangibles al cliente. En el proceso de asignacin los clientes definen las prioridades de las funcionalidades en base a los estimados, riesgos y dependencia de informacin que el equipo de desarrollo entrega. Colaborar El equipo de desarrollo construye los componentes asignados en la iteracin para entregar funcionalidades construidas (Builds) en un proceso de integracin continua permitiendo que el producto sea visible al equipo de desarrollo. Las pruebas unitarias y la refactorizacin tambin son un proceso continuo en esta etapa. Los administradores de proyecto deben de mantener el control y constante monitoreo del proyecto, facilitando la colaboracin y el desarrollo de actividades concurrentes. Por otra parte se deben de preparan los casos de prueba para la revisin 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 colaboracin es un acto de creacin 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 tcnicos, los requerimientos de negocio y en la toma rpida de decisiones. Aprender En esta fase se renen en un evento llamado quality review, el cliente y el equipo de desarrollo para presentar lo construido en la iteracin. La retroalimentacin 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 iteracin o el producto debe ser preparado para pruebas y liberacin. Otra reunin que tiene cabida en esta fase es la de post-mortem, en la cual se revisa la productividad que se mostr en la iteracin 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 validacin de las funcionalidades y evaluar el resultado de las pruebas. Si se llegarn a presentar fallas estas debern de corregirse. Se debe tomar una decisin si se libera el sistema o se inicia con una nueva iteracin.

23

Existen cuatro categoras generales de cosas a aprender al final de cada iteracin de desarrollo: 1. Resultado de la calidad desde el punto de vista del cliente. La retroalimentacin de los clientes es la prioridad para los proyectos de desarrollo de software adaptables. 2. Resultado de la calidad desde el punto de vista tcnico Los programadores realizan revisiones tcnicas al cdigo o a la arquitectura de manera continua en cada iteracin. 3. El funcionamiento del equipo de entrega y las prcticas que los miembros del equipo utilizan. El equipo se auto examina al final de cada iteracin determinando que es lo que no funciono, que se necesita hacer ms 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 iteracin. La liberacin del producto a un ambiente productivo demanda realizar actividades de despliegue como preparacin de material de entrenamiento, capacitacin de usuarios, configuracin de ambientes y preparacin del sistema. Como parte final, se realiza el cierre del proyecto donde se espera un resumen de lecciones aprendidas de la ejecucin 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 iniciacin del proyecto en actividades de definicin de alcance, anlisis de riesgos y calendario de entregas. Por otro lado debe brindar apoyo durante la ejecucin de la iteracin para apoyar al equipo de proyecto en el avance efectivo de sus tareas. Finalmente son encargados de enviar informes del estado del proyecto.

24

El ciclo de vida de la metodologa ASD sigue 6 caractersticas bsicas: 1. Enfocada a la Misin Las declaraciones de la misin actan como una gua que promueve la exploracin al inicio pero con un estrecho enfoque sobre el curso del proyecto, brindando lmites mas que un destino fijo. La misin provee direccin 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 iteracin. 3. Desarrollo Iterativo El producto se va desarrollando y mejorando, a travs, de las iteraciones ya que los clientes van proporcionando informacin. 4. Tiempos Fijos (Time-Boxed) La prctica del time-boxing o tiempos en plazos fijos para las iteraciones y proyectos, se ha utilizado de manera incorrecta, las fechas lmites usadas para golpear al personal con largas horas o recortando la calidad son una forma de tirana. El time-boxing se trata de enfocar y tomar decisiones difciles para avanzar. En un ambiente en que predominan los cambios es necesario que haya una funcin forzada a conseguir trabajo terminado. 5. Guiada por los Riesgos. Como el modelo en espiral de Barry Boehms, la planeacin para iteraciones adaptables son guiadas por el anlisis 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
HISTORIA

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)

La metodologa de desarrollo de sistemas dinmicos (DSDM), es un marco de trabajo gil para gestin de proyectos de software. Es un mtodo que se apoya en un desarrollo iterativo e incremental, sensible a los requerimientos cambiantes. Fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos en la materia en el desarrollo de sistemas de informacin, combinando las mejores prcticas. El consorcio de DSDM es una organizacin no lucrativa y proveedor independiente, que posee y administra el framework. La primera versin fue terminada en enero de 1995. La versin actualmente en uso (abril de 2006) es la versin 4.2: El framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003. Como extensin del Desarrollo rpido de aplicaciones (RAD), DSDM se centra en los proyectos de sistemas de informacin que son caracterizados por presupuestos cortos y agendas apretadas.

25

DSDM trata los problemas que ocurren con frecuencia en el desarrollo de los sistemas de informacin 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 caractersticas del negocio y la tecnologa. Los expertos del negocio revisan los requerimientos y se desarrolla una lista de prioridades, una definicin del rea, una definicin de arquitectura del sistema y un prototipo general. 2. Iteracin del Modelo Funcional a. Identificar el Prototipo funcional. Determinar que funcionalidades se van a desarrollar en la iteracin. En esta etapa un modelo funcional debe ser elaborado. b. c. d. Acordar un Calendario Acordar como y cuando se va a desarrollar las funcionalidades. Crear un prototipo funcional Desarrollar un prototipo funcional, de acuerdo al calendario y un modelo funcional. Revisar el prototipo funcional. Validar las funcionalidades desarrolladas en el prototipo. El entregable es un documento de revisin funcional del prototipo.

26

3.

Iteracin de Diseo y Construccin a. Identificar prototipo de diseo. 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 implementacin. b. c. Acordar Calendario Acordar cuando y como se realizarn estos requerimientos. Crear prototipo de diseo. Crear el prototipo de diseo que pueda ser entregado a los usuarios finales para fines de prueba. d. Revisar prototipo del diseo. Validacin de la exactitud del sistema diseado. Nuevamente las pruebas y la revisin son las principales tcnicas utilizadas.

4.

Implementacin a. Aprobacin del usuario y Directrices. Los usuarios finales aprueban el sistema probado para la implementacin y las directrices con respecto a la implementacin y uso del sistema creado. b. Formacin de usuarios Entrenamiento del usuario final en el uso del sistema. El entregable es la lista de usuarios entrenados. c. d. Implementacin Implementar el sistema en la ubicacin de los usuarios finales. Revisin del Negocio. Revisar el impacto de la implementacin en el negocio, se mide si se alcanzaron las metas establecidas al principio del proyecto. El entregable es el documento revisin 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 Campen del Proyecto. Es el rol que tiene la habilidad y responsabilidad de comprometer apropiados fondos para la ejecucin del proyecto. VISIONARIO (VISIONARY). Es el nico con la responsabilidad de inicializar el proyecto, asegurndose que se tengan los requerimientos esenciales desde el principio. Los visionarios tienen una percepcin exacta de los objetivos del negocio y del proyecto.

27

USUARIO EMBAJADOR (AMBASSADOR USER). Trae el conocimiento de la comunidad del usuario al proyecto, asegurndose que los desarrolladores reciban la suficiente retroalimentacin 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 gestin del proyecto en general.

COORDINADOR TCNICO (TECHNICAL CO-ORDINATOR). Responsable de disear la arquitectura del sistema y llevar el control tcnico 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 construccin 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, acta como un intermediario para la preparacin y comunicacin.

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 tendrn que

28

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 acrnimo se entiende por: o o o o Must. Este Requerimiento se debe cumplir para alcanzar los objetivos. Should. Hacer lo posible por cumplir con este requerimiento, pero el xito no depende de l. Could. El no contar con este requerimiento no afecta la necesidad del negocio. Wont. Requisito que no ser implementado al final de la iteracin, pero puede ser considerada en otra. PROTOTIPOS (PROTOTYPING). Se refiere a la tcnica 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 participacin 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 creacin de software de buena calidad. Para alcanzar una solucin de buena calidad DSDM promueve las pruebas en cada iteracin. TALLERES (WORKSHOP) Una de las tcnicas claves es reunir a los interesados del proyecto para discutir y analizar requerimientos, funcionalidades para que haya un entendimiento general. MODELADO (MODELING) Tcnica para representar en diagramas un aspecto del sistema o rea del negocio para brindar un entendimiento visual ms fcil de entender a todos los involucrados. GESTIN DE LA CONFIGURACIN (CONFIGURATION MANAGEMENT). Una buena implementacin de esta tcnica es importante por la naturaleza del DSDM, ya que debido a que los productos se entregan con frecuencia a un ritmo muy rpido, es necesario controlar las salidas a produccin que puedan afectar los ambientes productivos.

3.4.4.5
HISTORIA

FEATURE DRIVEN DEVELOPMENT (FDD)

FDD fue creado inicialmente por Jeff De Luca, para satisfacer las necesidades especficas 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 planificacin, el diseo y construccin de las funcionalidades.

29

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 gestin 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 utilizacin 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 bsicas. 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 gua 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. Despus de cada vista del dominio, se arman equipos con personal del dominio y con desarrolladores lderes 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 diseados 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 o o Diagrama de clases Mtodos y atributos identificados Diagramas de secuencia, comportamiento u otro.

PROCESO #2. CONSTRUCCIN 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 lderes 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 categorizacin para la lista de

30

funcionalidades viene de la divisin del dominio realizada en el proceso anterior por los expertos del dominio. Entregables: o o o Listado de reas Por cada rea una lista de actividades de negocio. Por cada paso de la actividad de negocio la funcionalidad que la cumple.

PROCESO #3. PLANIFICACIN POR FUNCIONALIDAD (PLAN BY FEATURE). Actividad para desarrollar el plan de desarrollo. El administrador del proyecto, el administrador de desarrollo y los programadores lderes planean la manera en que las funcionalidades sern implementadas, basndose 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. DISEO POR FUNCIONALIDAD (DESIGN BY FEATURE). Actividad para generar un paquete de diseo funcional. El lder 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 lder de programadores forma un equipo orientado a funcionalidades e identificar a los dueos de las clases. Este equipo se encarga de elaborar los diagramas de secuencia para las funcionalidades asignadas y construyen las clases y mtodos. Una inspeccin del diseo es realizada. Entregable: o o o Documento que integra y describe el paquete de diseo. Diagramas de secuencia. El modelo de objetos actualizado.

PROCESO #5. CONSTRUIR POR FUNCIONALIDAD (BUILD BY FEATURE). Actividad para producir una funcionalidad completa al cliente. Iniciando del paquete diseado en el proceso anterior, los dueos de la clase de desarrollo implementan los elementos necesarios para su clase y soportar el diseo de esta caracterstica. Por ltimos se realizan las pruebas unitarias y se inspecciona el cdigo. Despus de una inspeccin satisfactoria se promueve el cdigo para generar el Build (ejecutable). Entregables: o o o ROLES. PROJECT MANAGER. Clases y mtodos codificados e inspeccionados Clases promovidas a generacin del build La entrega una funcionalidad del producto al cliente.

31

Es el lder 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 diseo arquitectnico del sistema. Diagramas de comportamiento, de secuencias y de clases son parte de los entregables a generar. Debe resolver problemas de diseo que los programadores no puedan resolver. Debe resolver los problemas tcnicos que puedan presentarse antes y durante la construccin. THE DEVELOPMENT MANAGER Es el responsable de liderar a todo el equipo de desarrollo, apoyndolos en la solucin de obstculos 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 anlisis de los requerimientos y actividades de diseo y es responsable de guar a pequeos grupos de desarrolladores. CLASS OWNERS. Son desarrolladores que participan como miembros de pequeos equipos de desarrollo. Ellos son encargados de disear, codificar, probar y documentar las funcionalidades requeridas para el nuevo software. DOMAIN EXPERTS. Son usuarios, clientes o expertos del negocio, cuya funcin 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 metodologas 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 elaboracin de una serie de documentos que son los entregables para poder iniciar con la siguiente etapa. El xito de esta metodologa 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 ms 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 construccin nos llevara a enfrentar ciertas problemticas 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 iteracin se entrega una parcialidad del producto final y en cada nueva iteracin se mejora el producto, abrazando los cambios como una oportunidad de mejora y no como un problema.

32

El modelo gil ms que un proceso es un cambio de mentalidad, es la adopcin de valores y principios giles y aplicarlos en los proyectos con los equipos de trabajo. Muchas organizaciones dedicadas al desarrollo de software actualmente estn haciendo el esfuerzo por incrementar su agilidad al cambio. Existen casos de xito donde equipos giles estn produciendo productos de alta calidad, que entregan valor al negocio en menos tiempo y con un costo menor en comparacin a equipos de trabajo que emplean una metodologa tradicional como la cascada. En un estudio realizado por Standish Group, quienes se dedican a recolectar informacin de casos de fracaso de la vida real en TI (Tecnologas de la Informacin), publicaron una comparativa, donde se puede visualizar el porcentaje de xito en los proyectos donde se han adoptado metodologas giles frente a la tradicional (cascada).

Figura 0.9 Comparativa Cascada vs gil En la siguiente tabla 1 se presenta las 5 caractersticas importantes que marcan una diferencia en eficiencia y efectividad entre las metodologas tradicionales y las giles utilizados sobre proyectos complejos y con una frecuencia alta de cambios en los requerimientos. Caractersticas Definicin de Requerimientos Diseo y Arquitectura Pruebas Interaccin con el cliente Comunicacin en el equipo Tiempo de entrega de valor Tradicional Anlisis y documentacin extensa necesaria (SRS, UML diagramas) Se define todo en la etapa de diseo, se plasman en diferentes diagramas. Se efectan cuando el producto ya se tiene terminado en su totalidad. En la etapa inicial de requerimientos, en las pruebas funcionales y en el despliegue Al final e inicio de cada etapa Aos, quizs nunca gil Listado de Funcionalidades breve (Lista Ordenada) Se va definiendo poco a poco durante cada iteracin, se emplea refactorizacin Se efecta en cada iteracin entregando producto funcional probado. En cada momento del proceso. Comunicacin constante

En semanas, meses o final de iteracin. Tabla 0.1 Comparativa Tradicional vs gil

33

Hoy en da debido a la fuerte competencia entre las organizaciones para posicionarse como lder en el mercado se realizan importantes esfuerzos para innovar y ofrecer al cliente no solo un producto a un menor precio sino que tambin a travs de la tecnologa 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 travs del uso de plataformas e-bussines. Para lograr xito en estas nuevas estrategias es necesario aprovechar la oportunidad del cambio y moverse rpido en la generacin de software que ofrezca la funcionalidad que se busca obtener, para ello es necesario basarse en una metodologa gil que permita entregar valor en menor tiempo a los clientes y obtener en ese sentido una ventaja competitiva. Las metodologas tradicionales no tienen efectividad en la mayora de estos proyectos, las variables tecnologa, 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 gestin de proyectos de software y la tendencia actual demuestra que el uso de las metodologas giles ha cambiado la manera de abordar estas problemticas o reas de oportunidad. Como referente, en un estudio realizado por la universidad de Oulu y la universidad politcnica de Madrid en el 2009 tomando como muestra datos del evento Agile Open Spain (AOS), se tena el objetivo de analizar el estado de adopcin de las metodologas giles en la industria de software espaola comparndola con la europea. La muestra europea estaba compuesta por socios industriales del proyecto Flexi (Flexi es una iniciativa de investigacin europea en metodologas giles) por un lado y por otro la industria espaola que estuvo compuesta por empresas que asistieron al evento AOS 2009. Los resultados encontrados fueron los siguientes: Los factores ms importantes que motivan la adopcin de una metodologa gil son los mostrados en la siguiente figura.

Figura 0.10 Factores Impulsan la Adopcin de una Metodologa gil

34

Se puede observar como en primer lugar lo que le interesa a las empresas es adoptar una metodologa 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 organizacin.

35

Captulo 4 Metodologa gil Propuesta

4.1 PROCESO PARA LA GESTIN DEL PROYECTO

Seleccin de la metodologa para desarrollo de software. Esta investigacin no consiste en definir un mtodo para la eleccin de una metodologa gil, sin embargo, si es importante describir los criterios que se analizaron para elegir Scrum sobre las otras metodologas en la empresa Cotemar. Para ello se realiz una evaluacin de las metodologas 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 documentacin extensiva. Colaboracin Los individuos y sus interacciones en lugar de procesos y herramientas Simplicidad El esfuerzo necesario para que una organizacin entienda el proceso Nivel Expertos - Nivel de habilidades tcnicas requeridas por el equipo de desarrollo para su implementacin. En la tabla 4.1 se presentan los resultados de dicha evaluacin, para lo cual, para poder asignar un valor se tomaron en consideracin los siguientes factores de cada metodologa: Ciclo de vida Roles Artefactos Practicas Metodologas Scrum XP ASD DSDM FDD Tradicional Usabilidad Alta Alta Baja Baja Baja Alta Tabla 0.1 Adaptabilidad Calidad Alta Alta Alta Alta Alta Alta Media Media Alta Alta Baja Baja Calificacin Metodologas Colaboracin Alta Alta Alta Media Alta Baja Expertise Media Alta Alta Media Alta Media

Los valores asignados para cada calificacin son los siguientes: 3=Alta, 2=Media, 1=Baja En la figura 4.1 se puede visualizarse que el punto ms alto es ocupado por Extreme Programming (XP).

36

Figura 0.1 Resultado Evaluacin Metodologas Aunque XP fue la metodologa con la calificacin ms alta, esto no significa que sea la metodologa idnea para su eleccin, ya que desde el punto de vista de la organizacin tiene que evaluarse factores como la cultura, cantidad de desarrolladores, habilidades tcnicas de los desarrolladores y la relacin de la estructura del rea actual con respecto a los roles necesarios. Para el caso Cotemar, se seleccion Scrum como la metodologa ideal por las siguientes razones: 1. 2. 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. 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 pequeo de desarrolladores y el nivel de habilidades es muy variado, adems de que no se cuenta con un rol de arquitecto o jefe de programadores entre ellos. 3. La cultura actual a la que estn acostumbrados para trabajar debe cambiar totalmente y aunque para cualquier metodologa gil significa un cambio radical, existe cierta simpata con Scrum que ayudara a reducir la resistencia a este cambio. Por otro lado experimentar prcticas como la programacin en pares puede requerir de ms tiempo lo que agrega riesgo al proyecto. Seleccin de un proyecto para adoptar Scrum. Para este caso de estudio el rea de aplicaciones adoptar la metodologa gil Scrum para llevar un proyecto de software. El proyecto se seleccion en base a cuatro criterios: tamao, duracin, importancia y grado de compromiso del negocio.

37

Figura 0.2 Criterios de Seleccin del Proyecto Piloto El alcance del proyecto consiste en generar una aplicacin para gestin 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 metodologa Scrum en Cotemar. Actualmente el rea de aplicaciones lleva la metodologa 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 metodologa gil con la finalidad de mejorar el proceso de gestin de proyectos. La foto Actual del rea. Antes de iniciar con el proceso de adopcin se desarroll una evaluacin de la madurez del rea de aplicaciones en base a buenas prcticas utilizadas en cada fase del proceso para la generacin de software y as tener una foto que represente el antes de la adopcin. Esta evaluacin se realiz en base a una serie de entrevistas con todo el equipo de aplicaciones donde se evaluaron prcticas en las categoras de: o o o o o o Gestin de Requerimientos. Arquitectura y Diseo. Desarrollo Pruebas y Aseguramiento de Calidad Gestin de la Configuracin Implementacin 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 prcticas para el desarrollo de software, donde los niveles indican que tan crtica es su utilizacin en la empresa Nivel Uno - Bsico. Es Urgente la adopcin de buenas prcticas Nivel Dos - Estndar. Se busca Mejorar lo que se tiene. Nivel Tres - Avanzado. Se busca remarcar y afinar lo que se tiene.

38

Nivel Cuatro - Dinmica. Mantenerse en las prcticas.

Figura 0.3 Diagrama Estado Antes Adopcin Scrum Como puede verse el nivel de madurez actual es de cero, es decir, se necesita de manera urgente cambiar las prcticas y el proceso para el desarrollo de software. Con estas actividades se puede identificar que no solamente se sigue una metodologa errnea para el desarrollo de software sino que tambin no se estn utilizando buenas prcticas. 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 gestin de proyectos. En la figura puede ver como se estructura el rea de aplicaciones segn los puestos:

Figura 0.4 Estructura rea Aplicaciones En la figura de abajo puede verse los roles que participan en la gestin de un proyecto, las personas que tomen un determinado rol son parte de la estructura del rea de aplicaciones.

39

Figura 0.5 Roles en Gestion de Proyectos antes de Adopcin de Scrum Para la preparacin de la adopcin de la metodologa Scrum se llevaron a cabo las siguientes actividades: 1. Capacitacin en la metodologa Scrum. La idea en esta actividad como primer paso en la adopcin era que todo el equipo de aplicaciones conociera este nuevo marco de trabajo, se estableciera un nuevo lenguaje de comunicacin y sobre todo se iniciara el cambio de mentalidad sobre los nuevos valores y principios que se deberan adoptar. 2. Seleccin de una herramienta para dar seguimiento a los proyectos . Como parte de la estrategia de adopcin es importante apoyarse de alguna herramienta tecnolgica que facilite el seguimiento y control del proyecto. Para este caso, se decide implementar la herramienta Team Foundation Server (TFS), ya que la mayora 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 gestin de proyectos. Cantidad 1 2 3 Servidor Microsoft 2010 Microsoft SharePoint Server 2010 Microsoft SQL Server 2008 R2 Team Foundation Server Descripcin Servidor que administra la coleccin de proyectos. Servidor para dar seguimiento a los proyectos Servidor para almacenar los proyectos y los informes. Tabla 0.2 Infraestructura de Servidores 4. Software utilizado de apoyo para la gestin del Proyecto. El siguiente listado muestra la relacin de software instalado en los equipos clientes del equipo Scrum para administracin y seguimiento del proyecto.

40

Software Microsoft Professional Visual Studio 2010

Descripcin Software utilizado para llevar el desarrollo administracin del del producto, proyecto,

control de versiones. Microsoft Office 2010 Software utilizado para generar documentos y artefactos para el proyecto. Microsoft Test Manager Software utilizado para la gestin 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 prctico 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 adopcin. Las reuniones se efectuaron con el objetivo de dar seguimiento a la implementacin de Scrum y sensibilizar a todo el equipo sobre la importancia de entender y aceptar el nuevo marco de trabajo para la gestin de proyectos, puntualizando los beneficios que se podran obtener dentro de la organizacin a corto plazo. Gestin a travs del Team Foundation Server (TFS). Antes de iniciar con el proyecto, necesitamos entender el papel de la herramienta TFS para poder realizar la gestin siguiendo el marco de trabajo Scrum.

Figura 0.6 Herramientas de Team Foundation Server 2010

41

TFS se convierte en la herramienta oficial para la gestin de proyectos en la empresa, a travs de ella, se generan ambientes por proyecto donde se lleva la gestin 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 informacin 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 duracin de una iteracin definida por el Scrum Master. Work Items. En TFS el work tem o elemento de trabajo es la unidad bsica 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 aceptacin o Task. Este elemento, representa una actividad tcnica a ejecutar por el Equipo de Desarrollo, ah se describe a detalle que trabajo tcnico se va a realizar y cunto 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 aceptacin. En este caso de prueba se deben definir los pasos necesarios para evaluar una funcionalidad especfica. 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 obstculos que impidan el avance del proyecto. descripcin, prioridad, valor y el criterio de

Figura 0.7 Tipos de Elementos de Trabajo (Work Items)

Queries.

42

Los queries o consultas son listados predefinidos que nos agrupan la informacin 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 diseados de acuerdo a alguna necesidad particular.

Figura 0.8 Listado de Queries

Datos generales del Proyecto Piloto. Objetivos: o o o Beneficios: o o o Entregables. o o Sistema de Administracin de Salary Plan (Salary Plan Management) Capacitacin al Key User Eficiencia en el clculo de nmina Reduccin de tiempo en la generacin de reportes Rapidez para la autorizacin de los Gerentes Contar con una aplicacin que permita evaluar y realizar ajustes salariales. Brindar una interfaz colaborativa con los gerentes. Generar reportes y estrategias de autorizacin del plan de salarios.

Factores crticos de xito. o o Limitantes. Participacin activa del Key User Disponibilidad de los recursos involucrados

43

o
Cd. Act.

Tiempo limitado para llevar a cabo el proyecto

Actividad Calendario (Meses)

1 Documentar 5 metodologas giles Propuesta de Implementacin de Metodologa Scrum Anlisis y Seleccin de un proyecto de software Elaborar Documentacin del Proyecto Seleccin y preparacin de herramientas de apoyo Seleccin del Equipo de Trabajo Capacitacin en la metodologa Scrum Elaboracin del Product Backlog Elaboracin del Sprint Backlog Definicin de las Tareas a realizar Construccin y Pruebas de Funcionalidades Seguimiento Diario Liberacin Revisin del Sprint y Retrospectiva Documentar resultados Documentar el nuevo proceso de gestin de proyectos.
Tabla 0.4 Cronograma del Caso de Estudio

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Actividades Def. Sprint Backog Diseo Funcional Construccin Pruebas Ajustes Sprint Review Retrospectiva

Sprint 1 # Semanas 1 2 3 4 X X X X X X X X X X X

Sprint 2 # Semanas 1 2 3 4 X X X X X

Sprint 3 # Semanas 1 2 3 4 X X X X X

Sprint 4 # Semanas 1 2 3 4

X X X X X

X X X X

X X

X X X X

Tabla 0.5 Cronograma del Proyecto Piloto.

44

4.2

ROLES INVOLUCRADOS EN SCRUM

Figura 0.9 Roles para Gestin 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 tcnicas podrn desempear este rol de una forma ms natural. La introduccin de este nuevo rol en la gestin 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. 2. 3. 4. 5. 6. 7. 8. 9. Apoyar al Dueo del Producto a definir y a priorizar sus requerimientos Apoyar al Equipo a entender los requerimientos y definir de manera objetiva sus tiempos. Definir los tamaos de los Sprints de acuerdo a la meta deseada. Apoyar sobre dudas en el TFS para llevar el proceso de Scrum. Monitorear que el proceso se est llevando correctamente Organizar las reuniones diarias entre el Equipo de Desarrollo y el Dueo del Producto para enfocar esfuerzos. Resolver impedimentos que puedan afectar el avance del proyecto. Organizar y llevar las reunin de revisin del Sprint y Restrospectiva Apoyar al Dueo del producto para entender los informes de avance y conocer el estado del proyecto. 10. Apoyar a que el Equipo de Desarrollo y el Dueo del Producto se integrarn.

45

Fue difcil 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 adopcin de Scrum en la organizacin. El Dueo 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 negociacin y conocimiento en la tecnologa eran los candidatos perfectos a desempear este rol. La principal funcin de este rol era transmitir al equipo la visin y las metas del negocio. Debido a que el funcional antes se involucraba en definiciones tecnolgicas esto represento un reto para adoptar su nuevo rol. El Dueo del Producto o Product Owner tena que seguir principalmente las siguientes actividades: 1. 2. 3. 4. Entender las necesidades del negocio Definir en conjunto con el negocio una lista de requerimientos ordenada de acuerdo a su prioridad y valor de negocio. Explicar a detalle cada requerimiento al Equipo de Desarrollo Transmitir al equipo de desarrollo la meta a alcanzar en cada Sprint o Iteracin.

Otras de las complicaciones en este rol fue que en ocasiones la persona que funge como Scrum Master tomaba responsabilidades incorrectamente del Dueo del Producto ocasionando confusin 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 difciles de adoptar es que en este nuevo marco de trabajo ellos no solamente estn sentados en su cubculo 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 ms participativo en el proceso de entender las necesidades del negocio y los requerimientos del producto que cumplen como solucin a estas necesidades. Las actividades ms importantes del Equipo de Desarrollo Scrum son: 1. 2. 3. 4. 5. 6. 7. Entender los requerimientos de la lista ordenada. Sugerir soluciones tecnolgicas para cumplir con estos requerimientos. Definir las tareas y los tiempos necesarios para construir las funcionalidades. Codificar, disear, probar e implementar parcialidades del producto para el cliente. Colaborar en cada iteracin junto con el Dueo del Producto. Apoyarse entre los miembros del equipo para resolver problemas Mejorar el producto en cada iteracin 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 seccin 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 decisin de que las pruebas funcionales y de calidad deberan ser realizadas por el rol funcional, ya que viene ligado a los criterios de aceptacin que el mismo funcional define como dueo del producto. El Tester realiza las siguientes actividades: 1. Disear el plan de pruebas.

46

2. 3. 4. 5.

Ejecutar las pruebas en base a los criterios de aceptacin y los casos de prueba. Notificar las fallas que puedan presentarse Identificar mejoras y platicarlas con todo el Equipo Scrum. 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 sealar deficiencias en el producto.

4.3

DEFINICIN 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 gustara 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 definicin 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 das mximo, quizs no se tenga la visin completa de todo el producto pero lo ms esencial debera estar en esta primera versin del Product Backlog.

47

Figura 0.11 Definiendo un PBI en TFS

4.4

PLANEACIN DEL SPRINT (SPRINT PLANNING)

Posterior a la elaboracin del Product Backlog, el Scrum Master organiza la reunin de la planeacin del Sprint donde participan el Product Owner y el Equipo de Desarrollo. La reunin 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 tecnolgicamente como deberan 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 construccin. En la segunda parte de la reunin el Equipo de Desarrollo deber determinar las tareas necesarias y su tiempo para poder construir cada elemento del Product Backlog. En la divisin de las tareas se deben definir con un tamao pequeo no mayor a 2 das 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 estimacin de los tiempos deben participar exclusivamente los desarrolladores, la principal razn es porque si ellos lo definen se sienten ms comprometidos en entregar el producto en sus tiempos y adems 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 estimacin sin embargo, estos errores se reconocieron y se fueron afinando en los Sprints siguientes. El entregable de esta reunin 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.

48

Figura 0.12 Sprint Backlog

4.5

DEFINICIN FUNCIONAL

Durante la ejecucin del Sprint, una de las tareas iniciales es que el Team agregue ms informacin 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 definicin 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 nmeros 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 realizacin de un clculo, operaciones con fechas, ejecucin 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 electrnico c) Atributos y Entidades Es el listado de las entidades y sus campos con el fin de conocer que informacin se requiere almacenar. Por ejemplo: Entidad Usuarios Campos: Nombre (150), Apellido (100) d) Prototipos En esta seccin se adjunta imgenes del diseo 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 construccin. En esta seccin es posible adjuntar otro tipo de artefacto que puedan aportar mayor claridad, como son formatos o documentos del negocio.

49

Figura 0.13 Definicin Funcional del PBI Una vez que se tiene definido la definicin 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 codificacin, diseo y pruebas unitarias y empezar a construir un incremento del producto.

4.6

PRUEBAS

Las pruebas son tambin una parte esencial, ya que uno de los valores de las metodologas 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 planeacin y se da al inicio del Sprint, donde el Tester se encargar de definir los casos de prueba y los criterios de aceptacin. 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

50

Parte de la definicin del caso de prueba consiste en proporcionar los pasos que se tendrn que realizar para probar cierta funcionalidad del producto.

Figura 0.15 Definicin de los pasos a seguir en un Test Case En el plan tambin 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 versin 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 tcnica o de lgica se finalizara y se marcar ese caso de prueba como exitoso.

51

Figura 0.16 Ejecucin 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 Notificacin de una Falla Una vez que el equipo de Desarrollo corrija las fallas, se deber generar una nueva versin 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 definicin 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 relacin entre todos los elementos para que este ciclo pueda funcionar de manera efectiva y para

52

que la comunicacin y la colaboracin 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 da, 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 ms de 15 minutos era conocer que se haba trabajado en el da, si se tuvo alguna complicacin y que se planeaba realizar el da siguiente. En estas reuniones no se resolvan problemticas, ni tampoco se definan elementos nuevos, simplemente el Equipo platica del esfuerzo realizado en el da. El resultado de estas reuniones fue de mucho xito en el proyecto, ya que ayudaba a enfocar esfuerzos, a dar direccin 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 obstculos que podan impactar el avance del proyecto. Otro beneficio de estas reuniones es que apoyan a tener una buena deteccin 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 ms de 15 minutos para lo cual el Scrum Master realiz un papel esencial para el correcto cumplimiento de esta prctica. En estas reuniones se incluy al administrador de proyecto, su funcin de llevar una minuta de lo que se platic en las reuniones de Daily Scrum y compartirla a todos posteriormente, tambin aporto buenos resultados, permitiendo tener una bitcora de hechos.

53

4.8

LIBERACIN DEL PRODUCTO.

Las liberaciones del producto se refieren a los despliegues parciales de las funcionalidades construidas por el equipo de desarrollo. Las liberaciones de cdigo se llevan a cabo a travs de la generacin de Builds que se preparan desde la herramienta TFS. El Build de TFS es un servicio configurable que de manera automatizada tiene la funcin de realizar la integracin del cdigo fuente y compilar el producto para tener una versin funcional en algn 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 Liberacin 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 generacin 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 versin del Build para liberacin. 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 informacin ms real. Si una falla se presenta en esta ambiente se tendr que notificar al equipo de desarrollo para que se corrija requirindose 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 configuracin 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 travs 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.

54

Figura 0.20 Lista de Builds generados Control de Cdigo Fuente. El control de las versiones y repositorio del cdigo fuente se lleva a travs del TFS y en el estudio nos ayuda a mantener un control sobre los cambios que se van realizando al cdigo durante todo el proyecto. Contar con este control permite que varios programadores despus de codificar y realizar pruebas unitarias integraran su versin al producto de manera consistente y con una bitcora de historial de los cambios que se realizaron o que funcionalidad se construy.

Figura 0.21 Control de Cdigo Fuente en TFS Para tener una gestin flexible de las versiones del cdigo en los diferentes ambientes, el Equipo de Desarrollo tuvo que definir una estrategia de ramas (Branches), ya que debido a que cada despliegue o liberacin de versin tena su ambiente, ya sea, desarrollo, calidad o produccin. 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.

55

Figura 0.22 Estrategia de Ramas para Liberaciones de Producto

4.9

REVISIN DEL SPRINT (SPRINT REVIEW) Y RETROSPECTIVA

Al finalizar el Sprint, el Scrum Master organiza una reunin 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 presentacin se reconoci el trabajo del equipo de desarrollo y se expresaron ideas para mejorar algunas partes del producto. La segunda parte de la reunin fue la Restrospectiva, en ella se trata de mejorar la productividad y la eficiencia en el siguiente Sprint, bsicamente todo el equipo respondi a tres preguntas bsicas: 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 o o o o Llevar a cabo el Daily Scrum Liberar al Team de actividades externas al proyecto El empleo de las herramientas para gestin del proyecto El seguimiento que dio la PMO Definir en tiempo y con claridad la especificacin funcional.

Que no funcion? o o o o Falta del diseo funcional en tiempo, provocando indefiniciones en las especificaciones No realizar pruebas funcionales en tiempo No registrar bugs en tiempo para su reparacin No estimar correctamente las tareas

Qu hacer diferente para mejorar? o o o Sensibilizar al Tester de la importancia de realizar las pruebas en tiempo y dar seguimiento a esta actividad. Entrenar al Tester para que cuando identifique un bug en las pruebas lo registre al momento. 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, apoyndose en la tcnica de pker planning.

56

4.10

HERRAMIENTA PARA MEDICIN DE LA PRODUCTIVIDAD

Grfica Burndown En nuestro proyecto piloto, mediante el registro en el TFS de las tareas realizadas diariamente se va trazando una grfica conocida como BurnDown, mediante est grafica el Equipo Scrum puede ir monitoreando de manera sencilla, si el avance que se est obteniendo del da a da 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 desvo tomar acciones al respecto. En la grfica de la figura 4.23, el color verde representa las horas trabajadas en el Sprint y el color gris las horas por trabajar, la lnea roja es la tendencia ideal, es decir, si el color gris est arriba de la lnea roja, representa un atraso en el proyecto. Como se puede ver existieron algunos pequeos picos que no representaban un atraso importante y que se fue recuperando por el equipo de desarrollo al final del Sprint.

Figura 0.23 Grfica de Burndown de Seguimiento al Proyecto La grfica de Burndown nos da la visibilidad de que tan productivo est resultando el Sprint en ejecucin. Velocidad Otra grfica 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 grfica muestra, cuanto esfuerzo se realiz en base al dato estimado para ello, como se ve en la figura 4.24.

57

Figura 0.24 Grfica de Velocidad del Equipo Por otro lado, est estadstica nos ayuda a estimar futuros esfuerzos en otros Sprints, ya que nos da una idea de cunto 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 travs de ellas, cada mtodo de las clases desarrolladas es probado de acuerdo a criterios de aceptacin 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 Cdigo Fuente

58

Estas se ejecutan de manera automatizada cuando se est construyendo el producto, cuidando que cada vez que se compile se tenga una versin 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 nmero de defectos estaban corregidos gracias a las pruebas unitarias.

59

Captulo 5 Metodologa de la Investigacin

5.1 MTODO DE LA INVESTIGACIN.

Este estudio experimental es de tipo correlacional ya que se mide el efecto de relacin entre la adopcin de una metodologa gil y su impacto en la competitividad en una empresa. Para ello se elabora un estado del arte para dar sustento a la investigacin 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 metodologas giles, aportando una gua inicial en la investigacin y conocimiento para interpretar los resultados del estudio. Se emple el mtodo emprico como estrategia ya que se realiz una amplia investigacin con un estudio de caso detallado, en el cual mediante la seleccin de un proyecto piloto en la empresa Cotemar se describe paso a paso la adopcin de la metodologa gil Scrum. Mediante esta evidencia emprica se busca completar este trabajo de investigacin y a travs de hechos observables y documentados demostrar los resultados. Las variables medidas en este estudio fueron: Variables La metodologa gil El grado de competitividad Productividad Efectividad Calidad Valor entregado 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. Sub-variables Relacin Independiente Dependiente

5.2

TCNICA DE RECOLECCIN DE DATOS

Las tcnicas utilizadas para la recoleccin de datos, consistieron en el empleo de varias herramientas, en la cual nos apoyamos durante la gestin del proyecto. Las herramientas utilizadas en el estudio fueron: Datos Estadsticos Reuniones de Grupo Cuestionarios Entrevistas Encuestas

60

La informacin obtenida con cada una de estas herramientas se fue dando en diferentes momentos del proceso. El caso de los datos estadsticos se fue generando a travs del registro de las actividades en el TFS durante la ejecucin 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

POBLACIN Y MUESTRA

La poblacin en este estudio fueron un grupo de cinco proyectos que se evaluaron de acuerdo a su tamao, duracin, importancia y grado de compromiso del negocio. La muestra fue un proyecto que cumpliera con los siguientes parmetros: Dimensin Tamao Duracin Importancia Grado Compromiso Valor Deseado Mediano 3-5 Meses Media Media Tabla 0.2 Poblacin 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 metodologa Scrum y medir sus efectos en las competitividad.

61

Captulo 6 Anlisis de Resultados

6.1 CUMPLIMIENTO DE LOS OBJETIVOS.

El objetivo de este estudio es demostrar que mediante la adopcin de una metodologa 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 especficos en este estudio fueron los siguientes: a) Anlisis de las metodologas giles ms 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 metodologas giles.

o o o o o

Scrum XP (Xtreme Programming) ASD (Adaptive Software Development) DSDM (Dynamic System Development Method) FDD (Feature Driven Development)

b) Realizar una comparativa entre metodologa tradicional versus gil Esta comparativa es importante ya que permite identificar las principales diferencias entre ambas metodologas y conocer en qu momento se debe aplicar una u otra. c) Identificar los beneficios de una metodologa gil en los equipos de trabajo. A travs del estudio de las cinco metodologas y de las mtricas que nos da el estudio se pudo constatar los beneficios obtenidos. d) Adoptar la metodologa gil Scrum a la gestin de un proyecto real. Se llev a cabo una descripcin detallada de la adopcin de Scrum en Cotemar aplicado a un proyecto piloto. e) Describir el impacto en la productividad y competitividad despus de adoptar Scrum. Se realiz un anlisis y mediciones de cmo la adopcin de Scrum tiene un impacto sobre la productividad, efectividad, calidad y el valor generado.

62

6.2

MTRICAS DEL PROYECTO.

Estadsticas utilizadas para medir la productividad: o Seguimiento de la grfica 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

63

Figura 0.3 Burndown Sprint 3 o % Productividad de Valor Entregado. Este indicador se calcula mediante la informacin 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: Plan Esfuerzo Sprint 1 1000 800 500 900 500 500 500 500 600 400 800 800 500 600 500 500 500 500 800 Plan Esfuerzo Sprint 2 200 300 800 500 400 300 400 900 900 900 1000 900 1000 800 1000 900 600 500 500 800 Plan Esfuerzo Sprint 3

No PBI 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

800 700 700 600 500 700 800 1000 800 800

64

21 22 23 24 25 Productividad 93% 95%

600 300 700 500 500 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 estadstica 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 estadstica de velocidad nos ayuda a responder preguntas tales como, cuanto esfuerzo puede completar el equipo en un sprint?, cual es la velocidad mxima o mnima 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.

65

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 informacin se calcula para cada Sprint mediante la suma de los defectos corregidos y se divide entre los defectos latentes, es decir, defectos que continan 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:

66

Figura 0.7 Defectos Corregidos Sprint 1 2 3 % EQA 71% 88% 86%

Tabla 0.2 % Errores Calidad Corregidos o Estadstica 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 ms cambios en el cdigo o cuales ya estn 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 cmo se puede mejorar como equipo en el proceso para poder ser ms productivos y eficientes. Se utiliz la tcnica Delphi para llegar a los puntos que ms impactan al proceso de manera positiva o negativa, el resultado se presenta en las tablas siguientes: Que se hizo bien? Realizar los Daily Scrums Evitar efecto multitarea en los desarrolladores Uso de herramientas para gestin del proyecto Participacin de la PMO en el Daily Scrum Definir en tiempo y forma de la especificacin funcional X X X X 1 2 3 4 5 X

67

Tabla 0.3 Resultado de lo que se hizo Bien Que No se hizo bien? Realizar pruebas funcionales fuera de tiempo Registrar bugs fuera de tiempo para su reparacin No estimar correctamente las tareas Tabla 0.4 Resultado de lo que No se hizo bien Que podemos mejorar? Liberar de tareas paralelas al Tester para que pueda realizar sus actividades en tiempo. Concientizar al Tester de la importancia de generar bugs. Mejorar la tcnica de estimaciones de tiempo en tareas. La interaccin directa entre desarrollador y Product Owner sea ms directa y natural. 5=Fundamental 4=Importante 3=Mantener 2=Da igual 1= Remover Con esta informacin recabada entre datos estadsticos, reuniones y cuestionarios, podemos tener mtricas de la productividad, calidad, adaptacin y eficiencia de los equipos de trabajo utilizando Scrum y tomar decisiones oportunas que impliquen realizar acciones que mejoren el proceso. Tabla 0.5 Resultado de lo que se puede Mejorar X X X 1 2 3 4 5 X X 1 2 3 4 5 X X

6.3

RESISTENCIA AL CAMBIO

Es importante conocer cules 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 reaccin de querer regresar a los hbitos 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 tenan que tomar acciones para retornar al proceso correcto. Cambios como: o o o o Identificar la prioridad de los requerimientos de acuerdo a su valor Registrar informacin de las actividades diariamente Realizar las pruebas como actividad en cada Sprint Involucrar a los usuarios de forma temprana en los entregables

68

Aprender estimar en horas en lugar de das.

Fueron algunos puntos en los cuales el equipo tiene que madurar y acostumbrarse para ser ms eficientes en el proceso.

6.4

RETORNO DE INVERSIN 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 organizacin el implementar este estudio no requiere de una inversin fuerte ya que en la mayora 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 inversin maximizado por los resultados ya que la organizacin obtiene una ganancia directa/indirecta a travs 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 problemticas actuales relacionadas a la inversin del tiempo que realizan puestos ejecutivos en la gestin de movilidad salarial y por otro lado evitar posibles errores en tomas de decisin. Se espera que este proyecto apoye en tener una gestin de salarios ms efectiva. En la figura 6.5 se presenta un anlisis estratgico sobre qu tan rentable ser el proyecto donde se incluye el retorno de inversin esperado.

Figura 0.9 Evaluacin ROI

69

Con la adopcin de Scrum como metodologa gil, el objetivo es entregar valor en corto plazo proveyendo de las herramientas necesarias al negocio para realizar esta gestin de manera efectiva.

6.5

IMPACTO EN LA COMPETITIVIDAD DE LA ORGANIZACIN.

Innovacin Productividad Efectividad Menor Costo Calidad

Podemos medir el impacto de este estudio basndonos en cinco puntos clave:

Cada uno de estos puntos representa un impacto en la competitividad, aunque afectan directamente a procesos internos de la organizacin, 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 Innovacin. El adoptar un nuevo marco de trabajo como Scrum, es una innovacin dentro de la organizacin, 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 ms de 30 das y apoyado de herramientas y procesos que impulsan a los equipos de trabajo a ser ms productivos. En el caso de este estudio se midi la productividad a travs del valor entregado al cliente al final de cada Sprint, adems los daily Scrum ayudaron a detectar en tiempo cualquier desviacin y enfocar esfuerzos para cumplir con el compromiso. Otro aspecto evidente de la productividad es que cada miembro del equipo durante el Sprint tena que estas interactuando a diario y ejecutando actividades para tener un resultado de avance notable al final del da. 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 metodologas 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 visin hacia dnde vamos, eso nos permite ser efectivos en entregar un producto que resuelve una necesidad del negocio. o Menor Costo.

70

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 quizs en algunos casos resulten efectivos, pero siempre sern costosos, ya que requieren la gestin de muchos procesos, la generacin de mucha documentacin y el esfuerzo de mucha pero mucha gente. Por otro lado las metodologas giles como Scrum basados en sus cuatro valores proponen un marco de trabajo ms liviano donde impere la interaccin entre personas, la entrega de producto funcional, colaboracin con el cliente y la adaptacin al cambio, basado en esto podemos reducir la cantidad de tiempo que se desperdicia en crear artefactos, documentos u otro material que lo ms probable no agregue valor al producto. Por otra parte al trabajar en iteraciones pequeas y tener como objetivo entregar software funcionando se reducen los riesgos de fallas en ambiente productivos que resultan mucho ms 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 seran: 1. 2. La prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software que aporte valor. 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 metodologa tradicional en proyectos similares, se podra visualizar el impacto en la competitividad en la adopcin de Scrum en Cotemar, como muestra la figura 6.6.

Calidad

Innovacio n 3 2 1 0

Productivi dad

Scrum Tradicional

Menor Costo

Efectivida d

Figura 0.10 Grfica de Impacto en la Competitividad en la Adopcin de Scrum

71

Captulo 7 Conclusiones y Recomendaciones

7.1 CONCLUSIONES.

El propsito de esta investigacin consisti en incrementar la productividad y la eficiencia de los equipos de trabajo que participan en proyectos de desarrollo de software, a travs, de la adopcin de una metodologa gil como Scrum y de la aplicacin de prcticas y herramientas. Para poder medir el grado de impacto en la organizacin se obtuvieron mtricas cuantitativas y cualitativas de productividad, efectividad, calidad y valor generado. Con la adopcin de Scrum, se logr: o Rentabilidad y efectividad. Esto se traduce a la entrega de valor al negocio en un lapso mximo de 30 das. (Time to Market), a travs de: a) b) c) o Estableciendo prioridades de valor en los requerimientos. Realizando entregas parciales funcionales. Empleando tcnicas que mejoren la calidad del producto.

Productividad Esto tiene que ver con el incremento de la productividad de los equipos de trabajo mediante el uso prcticas y herramientas como: a) b) c) d) El empleo de pruebas automatizadas. El uso de la refactorizacin de cdigo. La motivacin y la confianza que se le otorga al equipo de desarrollo para la toma de decisiones (Empowered Teams). Las reuniones diarias.

Calidad. La entrega de un producto funcional de alta calidad se logra gracias al uso de: a) b) c) d) Pruebas unitarias y pruebas de aceptacin. Integracin contina de cdigo para revisin. Retroalimentacin constante durante cada iteracin (Sprint Review). Retrospectivas del proceso.

La satisfaccin 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 da las organizaciones se enfrentan a retos cada vez ms grandes, se les exige, no solamente tener una economa slida, producir productos con calidad y con el mnimo coste sino tambin otra caracterstica importante para ser lder es que tiene que ser una organizacin gil, en el sentido de

72

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 adopcin de una metodologa gil como Scrum para la gestin de proyectos de software es una opcin viable e innovadora que puede llevar a una organizacin a incrementar sus niveles de agilidad y competitividad. Aunque entender la metodologa resulte sencillo, la experiencia en este estudio demuestra que es difcil implementarla y dominarla, existen varios aspectos que se tienen que madurar a travs de la prctica y de cambiar los viejos hbitos, 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 organizacin en un corto tiempo. La metodologa 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 adopcin de una metodologa 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 problemticas a superar estarn relacionadas con las habilidades de gestin e interpersonales que posean los miembros de los equipos. Es un proceso que requiere de habilidades de liderazgo y en la formacin de equipos auto dirigidos con gran cohesin y de alto desempeo. En qu nivel deberan ser adoptados los mtodos giles? Esta pregunta de investigacin se refiere a que si podemos continuar con metodologas tradicionales por un lado y usar mtodos giles por otro. La respuesta sera que no es recomendable tener equipos de trabajo llevando dos metodologas con diferente enfoque, ya que esto generara conflictos entre los equipos de trabajo, confusiones sobre los modelos y sobre todo causara malos entendidos en el uso de cualquier metodologa. Si la organizacin busca maximizar los beneficios que una metodologa gil pretende ofrecer entonces la adopcin de esta metodologa debera darse en un solo nivel aplicndolo a toda el rea y a todos los equipos de trabajo, definindose polticas y lineamientos que ayuden a infundir una nueva cultura de trabajo. Finalmente de la adopcin de Scrum, se pudo aprender que los equipos de trabajo pueden ser ms eficientes y productivos cuando las personas interactan y toman decisiones de manera frecuente, no dejando que un plan sea quien de la direccin sino ms bien a travs de inspecciones frecuentes se puedan aprovechar los cambios y adecuaciones que generen un valor real al negocio. El uso de prcticas dentro los equipos de desarrollo como las pruebas unitarias, pruebas de aceptacin e integracin 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 obtenan de usar una metodologa tradicional no eran aceptables en un escenario donde los requerimientos y las necesidades van cambiando con gran velocidad y donde el esfuerzo que se tena que aplicar en los procesos y artefactos la mayora de las veces termina como un desperdicio de tiempo y costo.

73

Como parte del estudio se aplic una encuesta a las personas que participaron en la adopcin de Scrum en Cotemar, en total participaron 15 personas las cuales tomaron diferentes roles en el proyecto, los resultados fueron los siguientes:

74

Figura 0.1 Encuesta Adopcin Scrum

7.2

RECOMENDACIONES.

Las recomendaciones que en algunos casos se identificaron como mejora y otras que dieron resultado durante este estudio para una adopcin exitosa de una metodologa gil, son las siguientes: 1. 2. 3. Definir una visin de lo que se quiere conseguir con la adopcin de Scrum. Promover y presentar los beneficios que aportar Scrum a la organizacin. Apoyarse de un experto que gue la adopcin de la metodologa.

75

4. 5.

Seleccionar un proyecto candidato considerando tamao, duracin, importancia y grado de compromiso del negocio. Aceptar los cambios con actitud positiva.

En este estudio no se implementaron todas las prcticas giles por cuestin del tiempo, sin embargo, su implementacin impulsara a obtener mejores resultados. La integracin continua y la automatizacin de pruebas funcionales pueden agregar un mayor incremento en la productividad y en la calidad del producto final.

76

Captulo 8 Referencias Bibliogrficas

Libros Consultados: Porter, M. E. (1990). The Competitive Advantage of Nations. Harvard Business Review. Porter, M. E. (2004). Competitive Advantage. The Free Press. Sutherland, K. S. (2012). Software In 30 Days. John Wiley & Sons, Inc. Warden, J. S. (2007). The Art of Agile Development. OReally. Cohn, M. (2010). Succeding with Agile. Ann Arbor, Michigan, USA: Addison-Wesley. 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. AddisonWesley. [10] Highsmith, J. (2009). Agile Project Management. Addison-Wesley. [1] [2] [3] [4] [5] [6]

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 gua de Scrum. Recuperado el 09 de 08 de 2013, de https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%20 2011%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.). Programacin Extrema XP. Recuperado el 02 de 08 de 2013, de hhttp://ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20E XTREMA.pdf [11] Consortium, D. (s.f.). DSDM. Recuperado el 03 de 08 de 2013, de http://www.dsdm.org/

77

[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). Innovacin, 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 2528. Los Angeles, USA.

78

Anexo - Glosario de Trminos

Artefacto. El trmino artefacto en relacin 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 documentacin ayudan a la descripcin de una funcin, la arquitectura o el diseo del software. ASD (Adaptive Software Development). Metodologa desarrollada por Jim Highsmith y Sam Bayer a principios de 1990. La teora 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 prcticas de ASD estn enfocadas a una adaptacin continua. En ASD el ciclo clsico de planear-disear-construir es remplazado por un ciclo dinmico de EspecularColaborar-Aprender ASD (Agile Software Development). Es un grupo de metodologas de desarrollo de software gil, basadas en mtodos iterativos e incrementales. Build. El Build se refiere al proceso de convertir los archivos de cdigo fuente en artefactos que puedan ser ejecutados en otro equipo. Uno de los pasos ms importantes en el Build es la compilacin, donde el cdigo fuente es convertido a un cdigo ejecutable. Control de versiones. Se llama control de versiones a la gestin de diversos cambios que se realizan sobre los elementos de algn producto. Aunque un sistema de control de versiones se puede realizar de manera manual es recomendable apoyarse de herramientas que faciliten esta gestin. Ejemplos de este tipo de herramientas: Subversin, SourceSafe, TFS, Git. Coste. Es el valor monetario de los consumos de factores que supone el ejercicio de una actividad econmica destinada a la produccin de un bien o servicio. CRC (Collaborative and Responsability Cards). Las tarjetas de colaboracin y responsabilidad permiten al equipo de desarrollo definir el diseo del sistema. Cada tarjeta representa un objeto, las responsabilidades se listan del lado izquierdo y las clases de colaboracin se listan del lado derecho. Delphi. Es una tcnica que consiste en encuestar a un grupo de expertos de manera iterativa, con el propsito de obtener sus juicios y propuestas, buscando puntos en comn y organizando las respuestas para llegar a un consenso de sus opiniones. DSDM (Dynamic Systems Development Method). La metodologa de desarrollo de sistemas dinmicos, es un marco de trabajo gil para gestin de proyectos de software. Es un mtodo que se apoya en un desarrollo iterativo e incremental, sensible a los requerimientos cambiantes. Fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos en la materia en el desarrollo de sistemas de informacin, combinando las mejores prcticas. FDD (Feature Driven Development). Metodologa gil desarrollada por Jeff De Luca y Peter Coad. Como las otras metodologas adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. Keyuser. Es el usuario clave o experto del negocio, conoce bien la operacin 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 construccin y manufactura, aunque la primera descripcin formal de este modelo fue en un artculo realizado por Winston W Royce en 1970. PMO (Project Management Office). La oficina de proyectos es un departamento que define estndares de proceso, generalmente asociados a la gestin de proyecto. La PMO u oficina de proyectos es encargada de la documentacin, direccin y mtrica de la ejecucin de los proyectos.

79

ROI. El retorno de inversin o ROI, es una razn financiera que compara el beneficio o la utilidad obtenida en relacin a la inversin realizada. Scrum. Metodologa 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 mximo valor posible de forma productiva y creativa. SDD (Software Design Description). Es un documento que presenta diferentes vistas del diseo 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 colaboracin desarrollada por Microsoft para llevar la gestin de un proyecto de software. Esta herramienta permite utilizar plantillas para llevar la gestin de proyectos basados en una metodologa 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 grfica para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar 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 programacin, esquemas de bases de datos y compuestos reciclados. XP (Extreme Programming). Metodologa para desarrollar software creada por Kent Beck, la cual es capaz de adaptarse a los constantes cambios de los requerimientos. La metodologa Extreme Programming consisten de cuatro fases bsicas: Planear, Disear, Codificar y Probar. Los valores primordiales para llevar este ciclo de vida son la comunicacin, la simplicidad, la retroalimentacin y el coraje.

80

Este documento contiene una licencia CC por/ This document is licensed CC by: http://creativecommons.org/licenses/by-nc/4.0/legalcode

81