Vladimir Caballa Torres

APLICACIN DE UNA METODOLOGIA DE DESARROLLO DE SOFTWARE USANDO CMMI-DEV Y SCRUM CASO: CROSLAND LOGISTICA S.A.C
Tesis de Ingeniera

Lima, Junio 2012

Vladimir Caballa Torres

APLICACIN DE UNA METODOLOGIA DE DESARROLLO DE SOFTWARE USANDO CMMI-DEV Y SCRUM CASO: CROSLAND LOGISTICA S.A.C

Tesis presentada a la Universidad Nacional Mayor de San Marcos, Lima, Per, para obtener el Ttulo de Ingeniero de Sistemas

Orientador: Percy de la Cruz Velez de Villa

UNMSM LIMA JUNIO, 2012

ii

 Vladimir Caballa Torres, 2012. Todos los derechos reservados.

iii

Este trabajo est dedicado a toda mi familia en especial a mi madre que todo me lo dio.

iv

AGRADECIMIENTOS

Al profesor Percy de la Cruz Velez de Villa por su orientacin y dedicacin para que este trabajo cumpla con los objetivos trazados. A todas aquellas personas que indirectamente me ayudaron para culminar este trabajo y que muchas veces constituyen un invalorable apoyo. Y por encima de todo doy gracias a Dios.

APLICACIN DE UNA METODOLOGIA DE DESARROLLO DE SOFTWARE USANDO CMMI-DEV Y SCRUM CASO: CROSLAND LOGISTICA S.A.C
RESUMEN

El presente trabajo pretende brindar una solucin al realizar los proyectos de software y mantenimiento de estos basado en CMMI-DEV y Scrum. El modelo CMMI-DEV y el mtodo de desarrollo gil Scrum son vistos como contradictorios u opuestos pero vamos a dar prueba que juntos pueden trabajar muy bien y complementarse uno al otro. Para poder aplicar esta metodologa primero tenemos que evaluar el nivel de madurez que tiene actualmente la empresa Crosland Logstica S.A.C. para tal motivo tenemos que evaluarla a travs del SCAMPI, Standard CMMI Appraisal Method for Process Improvement, a partir de los resultados obtenidos nosotros nos centraremos en las reas de procesos que no cumplan con el nivel de madurez 2,que es el nivel definido, para poder plantear las mejoras. Dichas mejoras se basaran sobre CMMI, Capability Maturity Model Integration, que son una coleccin de las mejores prcticas que ayuda a las organizaciones a mejorar sus procesos. El desarrollo de desarrollo de software se realizara con Scrum y todos los artefactos que este involucra. El resultado mejorar dramticamente el rendimiento de tecnologa de informacin de la empresa Crosland Logstica. Palabras Clave: CMMI, Scrum, SCAMPI

vi

APLICACIN DE UNA METODOLOGIA DE DESARROLLO DE SOFTWARE USANDO CMMI-DEV Y SCRUM CASO: CROSLAND LOGISTICA S.A.C Abstract

vii

NDICE

CPITULO 1: INTRODUCCIN .................................................................................................................... 11 1.1. 1.2. 1.3. 1.3.1. 1.3.2. 1.4. 1.5. 1.6. 1.7. ANTECEDENTES .................................................................................................................................. 12 DEFINICIN DEL PROBLEMA ............................................................................................................... 12 OBJETIVOS.......................................................................................................................................... 12 OBJETIVO PRINCIPAL ..................................................................................................................... 12 OBJETIVOS ESPECFICOS ................................................................................................................ 12 JUSTIFICACIN ................................................................................................................................... 13 PROPUESTA ......................................................................................................................................... 13 ALCANCE ............................................................................................................................................ 13 ORGANIZACIN DE LA TESINA ............................................................................................................ 14

CAPTULO 2: MARCO TERICO .................................................................................................................. 15 2.1. SCRUM ................................................................................................................................................ 15 2.1.1. Transparencia ...................................................................................................................................... 15 2.1.2. Inspeccin ............................................................................................................................................. 15 2.1.3. Adaptacin............................................................................................................................................ 15 2.2. CMMI-DEV ....................................................................................................................................... 16 2.3. SCAMPI............................................................................................................................................. 16 CAPTULO 3: ESTADO DEL ARTE ............................................................................................................... 18 3.1. TAXONOMA........................................................................................................................................ 18 3.2. CMMI-DEV ....................................................................................................................................... 18 3.2.1. Descripcin Del Modelo CMMI-DEV ................................................................................................ 19 3.2.1.1. Aspectos claves ..................................................................................................................................... 19 3.2.1.2. Implementacin .................................................................................................................................... 22 3.2.2. reas de Proceso del Nivel de Madurez 2 .......................................................................................... 23 3.2.2.1. Gestin De Requerimientos (REQM) ................................................................................................. 23 3.2.2.2. Planificacin De Proyecto (PP) ........................................................................................................... 23 3.2.2.3. Monitorizacin Y Control De Proyecto (PMC) ................................................................................. 24 3.2.2.4. Gestin De Configuracin (CM) ......................................................................................................... 25 3.2.2.5. Medicin Y Anlisis (MA) ................................................................................................................... 25 3.2.2.6. Aseguramiento De La Calidad De Proceso Y Producto (PPQA) ..................................................... 26 3.3. SCRUM ................................................................................................................................................ 27 3.3.1. Roles de Scrum ..................................................................................................................................... 28 3.3.1.1. El ScrumMaster ................................................................................................................................... 28 3.3.1.2. El Propietario del Producto (Product Owner) .................................................................................. 29 3.3.1.3. El Equipo .............................................................................................................................................. 29 3.3.2. Bloques de Tiempo ............................................................................................................................... 30 3.3.2.1. Reunin de Planificacin de la Entrega ............................................................................................. 31 3.3.2.2. El Sprint................................................................................................................................................ 32 3.3.2.3. Reunin de Planificacin del Sprint ................................................................................................... 33 3.3.2.4. Revisin del Sprint ............................................................................................................................... 35

viii

3.3.2.5. Retrospectiva del Sprint ...................................................................................................................... 36 3.3.2.6. Scrum Diario ........................................................................................................................................ 36 3.3.3. Artefactos de Scrum ............................................................................................................................ 37 3.3.3.2. Sprint Backlog y Sprint Burndown .................................................................................................... 39 3.3.3.3. Hecho..................................................................................................................................................... 40 CAPTULO 4: APORTE TERICO ................................................................................................................. 42 CAPTULO 5: APORTE PRCTICO .............................................................................................................. 43 CAPTULO 6: IMPLEMENTACIN ............................................................................................................... 43 CAPTULO 7: CONCLUSIONES Y TRABAJOS FUTUROS ......................................................................... 43 8. REFERENCIAS BIBLIOGRFICAS ....................................................................................................... 44

ix

ndice de Figuras

Figura 1 Crecimiento del Grupo Crosland[Crosland 10] ............................................................................ 11 Figura 2 reas de proceso del nivel 2 [SEI 10] .......................................................................................... 21 Figura 3 Medologia de Scrum [Schwaber, Sutherland 11] ........................................................................ 31

Captulo 1: Introduccin

UNMSM

CPITULO 1: INTRODUCCIN
Desde hace ya unos aos se ha notado, en nuestro pas, un crecimiento sostenido en la economa nacional, donde el sector de venta de vehculos ha ido incrementando. Eso ha llevado al Grupo Crosland tener un crecimiento promedio de casi 30% por un periodo de 10 aos como se ve en la Figura 1. Desde el 2000 la demanda de las motos ha venido incrementndose gradualmente, habiendo aumentado en gran medida los ltimos 5 aos. El Grupo Crosland dedicado a la importacin, ensamblado, venta por mayor y por menor de motos ha sufrido grandes cambios en cmo administrar el negocio y por siguiente el rea de sistemas que da soporte a las reas crticas del negocio ha tenido que gestionar la creciente informacin. Es por esta razn que se ha hecho indispensable aplicar una metodologa de desarrollo de software usando CMMI-DEV y Scrum, que nos permitir gestionar los cambios realizados en el sistema, canalizar los requisitos de los usuarios y llevar un manejo ptimo de los procesos que tiene el rea de sistemas.

Total Grupo Crosland

60,000,000 50,000,000 40,000,000 30,000,000 20,000,000 10,000,000 0 1 2 3 4 5 6 7 8 9 10 Total Grupo

Figura 1 Crecimiento del Grupo Crosland[Crosland 10]

11

Captulo 1: Introduccin

UNMSM

1.1.

Antecedentes

Como se seala anteriormente, hace un tiempo se ha registrado un favorable escenario en la venta de vehculos en el Per, lo que ha provocado un crecimiento en los sistemas de

informacin y el crecimiento del grupo; dicho crecimiento ha generado que cada vez sea ms complejo su sistema actual, SAMI(Sistema Administrativo Modular Integrado), entonces al no poseer un sistema formal de control de gestin de cambio, una canalizacin de los requerimientos de los usuarios, una planificacin de proyecto, se hace indispensable aplicar las buenas prcticas para mejorar las reas de procesos de la empresa y el uso del mtodo de desarrollo Scrum para complementarlo en la gestin de los proyectos de software y el mantenimiento de los sistemas ya desarrollados hasta ahora.

1.2.

Definicin del Problema

El grupo Crosland no cuenta con una gestin de proyectos de software adecuada que permita un buen desempeo del rea de tecnologa de informacin, la gestin de requerimientos no se realiza adecuadamente lo que provoca que el analista-desarrollador no comprenda lo que realmente quiere el usuario del sistema, la planificacin de proyecto no est definida lo da lugar a una falta de monitorizacin y control del proyecto y por ultimo todo eso repercute en la calidad del producto resultante.

1.3.

Objetivos

1.3.1. Objetivo Principal

El objetivo principal de la tesis es Aplicacin de una Metodologa de Desarrollo de Software usando CMMI-DEV y Scrum. Caso:Crosland Logistica S.A.C.

1.3.2. Objetivos Especficos

Medir el nivel de madurez de la empresa Crosland Logistica S.A.C y evaluar las reas de proceso. Mejorar las reas de proceso que presentan debilidades. Dar un enfoque a la cultura de equipo para que el proyecto de resultados. Usar una metodologa de desarrollo gil que permita complementar el modelo que se propone, CMMI-DEV, permitiendo una adecuada gestin de los proyectos a partir de los artefactos que propone Scrum.
12

Captulo 1: Introduccin

UNMSM

Gestionar los requerimientos de los productos y de los componentes del producto. Planificar el proyecto para que nos permita: establecer estimaciones de tiempo, desarrollar un plan de proyecto y tener un compromiso con el plan. Monitorizar y controlar el proyecto que permita comprender el progreso del proyecto. Asegurar la calidad del producto y del proceso que proporcione una visin objetiva al personal y la gerencia.

1.4.

Justificacin

Los procesos de gestin de los sistemas de software sern mejorados y medidos lo que brindara al jefe de rea, y por consiguiente a la gerencia, ndices que permitan evaluar el desempeo del rea de TI. El software desarrollado con la metodologa ser de calidad y tambin ser entregada a tiempo. Con el desarrollo de la tesis nosotros vamos dar al Grupo Crosland no solo la calidad del software sino que tambin lo vamos a hacer de manera planificada. Con lo cual vamos a dar un cambio drstico a lo que es hoy la realidad actual.

1.5.

Propuesta

Implementar una metodologa desarrollo de software que permita al rea de TI de la Empresa Crosland Logstica S.A.C. una planificacin de los proyectos que realiza. Esto ayudara a sacar adelante, sin contratiempos, cumpliendo con los requisitos planteados inicialmente, dentro de los tiempos requeridos y con una calidad aceptable, los proyectos que se llevaran a cabo en esta rea.

1.6.

Alcance

La tesis se va a aplicar a la empresa Crosland Logstica, que da soporte a todo el Grupo Crosland la cual trabaja a nivel nacional, especficamente al rea de TI. Se realizaran las

13

Captulo 1: Introduccin

UNMSM

mejoras de seis de los siete procesos planteados por CMMI-DEV para el nivel de madurez 2. Para la misma rea aplicaremos tambin el Scrum como mtodo de desarrollo agil.

1.7.

Organizacin de la Tesina

La tesis est organizada en siete captulos, los cuales se mencionan a continuacin: En el captulo 2, se realiza el estudio del marco terico de la tesis, enfatizando la literatura sobre CMMI-DEV y Scrum, dando conceptos que se requieren para dar entendimiento a la tesis En el captulo 3, se realiza el estudio del estado del arte y la taxonoma a la que pertenece la tesis. En el captulo 4, vamos a ver el aporte terico, el Benchmarking, el por qu hemos elegido CMMI-DEV y Scrum como base para la tesis.

14

Captulo 2: Marco Terico

UNMSM

CAPTULO 2: MARCO TERICO

Para comprender algunos de los trminos usados en la tesis, tenemos que presentar algunas definiciones. Esto permitir al lector un mejor entendimiento de lo que tratamos en el presente documento.

2.1.

Scrum

Scrum, que se basa en la teora del control emprico del proceso, emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. Scrum no es un proceso o una tcnica para desarrollar o crear productos, sino que es un marco en el que se pueden emplear diversos procesos y tcnicas. El papel de Scrum es hacer aflorar la eficacia relativa de las prcticas de desarrollo empleadas por usted, para que pueda mejorarlas, a la vez que proporciona un marco dentro del cual se pueden desarrollar productos complejos. Existen tres pilares que sostienen toda implementacin del control emprico de procesos.

2.1.1. Transparencia
La transparencia garantiza que los aspectos del proceso que afectan al resultado, son visibles para aquellos que administran dicho resultado. Estos aspectos no slo deben ser transparentes, sino tambin conocidos. Es decir, cuando alguien que inspecciona un proceso cree que algo est hecho, esto debe ser equivalente a su definicin de "hecho". 2.1.2. Inspeccin Se deben inspeccionar con la frecuencia suficiente los diversos aspectos del proceso para que puedan detectarse variaciones inaceptables en el mismo. La frecuencia de inspeccin debe tener en cuenta que todos los procesos se cambian por el propio acto de inspeccin. El dilema se presenta cuando la frecuencia de inspeccin requerida excede la tolerancia del proceso a ser inspeccionado. Afortunadamente, esto parece no aplicar al desarrollo de software.otro factor es la habilidad y la diligencia de la gente que inspecciona los resultados del trabajo.

2.1.3. Adaptacin
15

Captulo 2: Marco Terico

UNMSM

Si el inspector determina, a travs de la inspeccin, que uno o ms aspectos del proceso estn fuera de los lmites aceptables, y que el producto resultante ser inaceptable, debe ajustar el proceso o el material procesado. El ajuste debe realizarse lo ms rpidamente posible para minimizar una desviacin mayor. Hay tres puntos para la inspeccin y la adaptacin en Scrum. La reunin diaria de Scrum se utiliza para inspeccionar el avance hacia la meta de Sprint, y para hacer las adaptaciones que optimicen el valor de la jornada de trabajo del da siguiente. Adems, la Revisin de Sprint y las Reuniones de Planificacin se utilizan para inspeccionar el progreso hacia el Objetivo (la liberacin de una versin) y para hacer las adaptaciones que optimicen el valor del siguiente Sprint. Por ltimo, la Retrospectiva de Sprint se utiliza para revisar el Sprint pasado y determinar qu adaptaciones harn el siguiente Sprint ms productivo, satisfactorio y agradable. El contenido de Scrum se compone de un conjunto de Equipos Scrum y sus roles asociados; as como de Bloques de Tiempo, Artefactos, y Reglas [Schwaber, Sutherland 11].

2.2.

CMMI-DEV

CMMI para el desarrollo es un modelo de referencia que cubre las actividades para el desarrollo de productos y servicios. Organizaciones de muchas industrias, incluyendo la aeroespacial, la banca, hardware, software, la defensa, la fabricacin de automviles, y de las telecomunicaciones, hacen uso de CMMI para el Desarrollo. CMMI para el Desarrollo contiene las prcticas que abarcan la gestin de proyectos, gestin de procesos, ingeniera de sistemas, ingeniera de hardware, ingeniera de software, y otros procesos de apoyo utilizados en el desarrollo y mantenimiento. Use su juicio profesional y el sentido comn para interpretar el modelo para una organizacin. Es decir, aunque las reas de proceso que se describen en este modelo representan conductas consideradas las mejores prcticas para la mayora de los usuarios, las reas de proceso y las prcticas deben ser interpretadas con un conocimiento en profundidad del modelo CMMI-DEV, con las limitaciones de la organizacin y su entorno empresarial.[SEI 10]

2.3.

SCAMPI

El Estndar CMMI Appraisal Method for Process Improvement (SCAMPI) est diseado para proporcionar clasificaciones de calidad de referencia en relacin con los modelos de Capability Maturity Model Integration (CMMI). Es aplicable a una gran variedad de modos de uso de evaluacin, incluyendo tanto la mejora del proceso interno y determinaciones externas de capacidad. SCAMPI cumple todos los requisitos de evaluacin para CMMI (ARC), los requisitos

16

Captulo 2: Marco Terico

UNMSM

para una clase un mtodo de evaluacin y apoya el desarrollo de ISO / IEC 15504 evaluaciones [SEI 12].

SCAMPI permite al patrocinador: Profundizar en la capacidad de ingeniera de una organizacin mediante la identificacin de las fortalezas y debilidades de sus procesos actuales Relacionar estas fortalezas y debilidades del modelo CMMI Dar prioridad a los planes de mejora Centrarse en las mejoras (corregir las debilidades que generan riesgos) que resulten ms beneficiosas para la organizacin, dado su nivel actual de madurez de la organizacin o las capacidades de proceso Derivar clasificaciones de capacidad a nivel, as como un ndice de nivel de madurez Identificar los riesgos de desarrollo / adquisicin con respecto a las determinaciones de la capacidad / madurez .

17

Captulo 3: Estado del Arte

UNMSM

CAPTULO 3: ESTADO DEL ARTE

Las metodologas usadas actualmente en el desarrollo de software nos dan un entendimiento de las mejores prcticas recopiladas a travs de la prctica, formas y entornos de trabajo, que las empresas pueden aplicar en la gestin de proyectos de software para crear mejores productos .

3.1.

Taxonoma

La taxonoma de la tesis est enmarcada en el Programa 5: Ingeniera de Software en la lnea: P5.2 Proceso de Desarrollo de Software, de acuerdo Facultad de Ingeniera de Sistemas e Informtica.

3.2.

CMMI-DEV

Durante las ltimas dcadas, el desarrollo de software y de sistemas que integran otras tecnologas, evidenci la necesidad de un marco en el cual ordenar y sistematizar los procesos de desarrollo y gestin de los proyectos. Durante ms de dos dcadas el Departamento de Defensa de EEUU financi numerosos estudios y apoy la formacin del SEI (Software Engineering Institute, Carnagie Mellow University) para desarrollar modelos con ese objetivo. El modelo CMM (Capability Maturity Model) para el software fue concebido con esta intensin y fue adoptado por la industria convirtindose en el estndar ms utilizado. Buena parte de su expansin fue la adopcin del mismo por parte de las software factories de la India, polo de desarrollo de un crecimiento enorme en los ltimos diez aos. Con la aplicacin del modelo CMM y la experiencia acumulada se detect la necesidad de contar con un modelo ms abarcativo que incluyera el concepto ms amplio de sistema. As surgi el modelo CMMI (Capability Maturity Model Integration) [Paulk,Curtis 91]. El modelo CMM ha servido como marco de referencia para la implementacin de mejoras de procesos en organizaciones en muchas partes del mundo y se han gastado miles de millones de dlares en estas implementaciones. Sin embargo, no todos los resultados han sido alentadores. Algunos informes indican que la cantidad de fracasos es muy alta en la implementacin de estos procesos, llegando al 70 % de las intervenciones. Varias investigaciones han mostrado que buena

18

Captulo 3: Estado del Arte

UNMSM

parte de este porcentaje se debe a que el modelo no contempla los aspectos sociales de las organizaciones que intentan llevar a cabo un proceso de mejoras [Ngwenyama, Nielsen 03]. La conclusin de estos trabajos es que resulta necesario complementar este modelo con otros que contengan los aspectos mencionados. Los analistas coinciden en afirmar que el paradigma del modelo se basa en una visin racional y mecanicista de las organizaciones. El modelo CMM tiene como objetivo el logro de procesos ptimos repetibles en el desarrollo de software. Esto implica un cambio en la forma de pensar y trabajar en el trabajo diario de los desarrolladores. Por esta razn es necesario incorporar en estos procesos aspectos de la cultura de la organizacin donde se implementar, basados en la idea de que la cultura de una organizacin determina lo que se podr y no se podr realizar cuando se plantean cambios [Quinn,McGrant 85].

3.2.1. Descripcin Del Modelo CMMI-DEV 3.2.1.1. Aspectos claves

Los aspectos claves del modelo son, por un lado, la clasificacin de las organizaciones en maduras e inmaduras y, luego, la prescripcin del camino a seguir por una organizacin inmadura para evolucionar y convertirse en una organizacin madura. El modelo entiende por organizacin inmadura aquella que lleva adelante sus proyectos sin una definicin previa de los procesos a seguir. Estos proyectos frecuentemente sobrepasan sus presupuestos y tiempos de terminacin debido a que son iniciados con estimaciones poco realistas, sin una planificacin adecuada, y son llevados adelante sin ningn tipo de gestin. En general estos proyectos no terminan o terminan con una disminucin importante en la calidad esperada del producto. Por organizaciones maduras el modelo entiende a aquellas que desarrollan sus proyectos en forma planeada. El logro de los objetivos del proyecto son asignados al cumplimiento de las reglas preestablecidas. Los presupuestos asignados y el tiempo previsto son los necesarios porque se parte de estimaciones metdicas y basadas en datos de proyectos previos, con roles y responsabilidades bien definidos.

19

Captulo 3: Estado del Arte

UNMSM

Para que una organizacin se convierta en madura debe evolucionar con el tiempo alcanzando sucesivos niveles de madurez. El modelo CMM identifica los siguientes niveles de madurez:

Nivel de Madurez 1 - Inicial Ausencia total de procesos definidos. Nivel de Madurez 2 - Gestionado Procesos de administracin establecidos para lograr el seguimiento de los costos, tareas y funcionalidad. La disciplina est dada por la repeticin en proyectos con aplicaciones similares. Nivel de Madurez 3 - Definido Adems de las definiciones del nivel anterior, son incorporadas actividades de administracin de ingeniera en forma documentada, estandarizada e integradas en una familia de procesos normalizados de la organizacin. Los proyectos utilizan una versin adaptada de esas normas para su desarrollo. Nivel de Madurez 4 - Administrado Se llevan adelante los proyectos en forma controlada con mtricas que permiten mediciones confiables de los procesos y productos. Nivel de Madurez 5 - Optimizado Incluye la mejora continua de procesos a partir de la comparacin y anlisis de mediciones sucesivas de los proyectos.

20

Captulo 3: Estado del Arte

UNMSM

Figura 2 reas de proceso del nivel 2 [SEI 10] El modelo CMMI incorpora al modelo por niveles de madurez de las organizaciones una vista de niveles de capacidad por rea de procesos. La misma est orientada a incluir los casos en los cuales las organizaciones necesitan una capacidad diferenciada por rea de proceso debido a los objetivos de sus negocios. Adems, este modelo enfatiza a lo largo de sus definiciones la relacin de cada una de sus reas de proceso con los objetivos de negocio mencionados. Estos niveles de capacidad son caracterizados genricamente de la siguiente manera:

Nivel de Capacidad 0 Incompleto: rea de proceso sin objetivos. Nivel de Capacidad 1 Ejecutada: Objetivos especficos del rea de proceso son satisfechos. Nivel de Capacidad 2 Administrada: rea de proceso institucionalizada a partir de una poltica organizacional de uso de los procesos.

21

Captulo 3: Estado del Arte

UNMSM

Nivel de Capacidad 3 Definida: rea de proceso institucionalizada a partir de un proceso definido.

Nivel de Capacidad 4 Cuantitativamente Administrada: rea de proceso institucionalizada a partir de una poltica organizacional de la administracin cuantitativa de procesos. Nivel de Capacidad 5 Optimizada: rea de proceso institucionalizada a partir de la optimizacin de sus procesos. En el modelo CMMI las reas de proceso son clasificadas en las siguientes categoras: 1. Process Management 2. Project Management 3. Engineering 4. Support

3.2.1.2. Implementacin
La implementacin de un proceso de mejoras segn el modelo CMMI est compuesto de las siguientes fases: Inicio, en esta fase se relevan los procesos, tareas, actividades y activos con que cuenta la organizacin, as como las polticas generadas por la conduccin de la organizacin. El mtodo que CMMI propone para la realizacin de este relevamiento es SCAMPI (Standard CMMI Assessment Method for Process Improvement). Consiste de un conjunto estructurado de actividades tales como entrevistas, revisin de documentos, presentaciones y anlisis de respuestas a cuestionarios. El resultado de esto es la obtencin de las fortalezas y debilidades, sobre las cuales se elaborar el Plan de Mejoras. El objetivo de esta fase es determinar las fortalezas, debilidades y oportunidades de mejora de la organizacin. Todo esto conducido por los objetivos de negocio de la organizacin. Diseo, basados en las debilidades y fortalezas encontradas en el SCAMPI se elabora el Process Improvement Plan (PI Plan) y los Action Plan (PAs). Piloto, de acuerdo a los objetivos planteados en cada PATs (Process Action Team) y al producto resultante de su trabajo (proceso, tarea, actividad, estndares), se capacita a los miembros del grupo del proyecto piloto y se prueba las prcticas correspondientes. Implementacin, en esta fase se extiende al resto de la organizacin las prcticas llevadas adelante en todos y cada uno de los proyectos piloto.

22

Captulo 3: Estado del Arte

UNMSM

3.2.2. reas de Proceso del Nivel de Madurez 2 3.2.2.1. Gestin De Requerimientos (REQM)
El propsito de Gestin de Requerimientos (REQM = Requirements Management) es gestionar requerimientos de los productos y componentes de producto del proyecto y asegurar alineamiento entre dichos requerimientos y los planes y productos de trabajo del proyecto. Los objetivos son: Los requerimientos se gestionan y las inconsistencias con planes y productos de trabajo se identifican. Desarrollar un entendimiento con quienes proporcionan requerimientos acerca del significado de los requerimientos. Obtener compromiso con los requerimientos de los participantes del proyecto. Gestionar cambios a los requerimientos conforme ellos evolucionan durante el proyecto. Mantener trazabilidad bidireccional entre los requerimientos y productos de trabajo. Asegurar que los planes y productos de trabajo del proyecto permanecen alineados con los requerimientos.

3.2.2.2. Planificacin De Proyecto (PP)

El propsito de Planificacin de proyecto (PP = Project Planning) es establecer y mantener planes que definan las actividades del proyecto. Sus objetivos son: Establecer y mantener estimaciones de parmetros de planificacin de proyecto. Establecer una estructura de divisin del trabajo (EDT) de alto nivel para estimar el alcance del proyecto. Establecer y mantener estimaciones de atributos de productos de trabajo y tareas. Definir las fases del ciclo de vida del proyecto sobre las cuales delimitar el esfuerzo de planificacin.

23

Captulo 3: Estado del Arte

UNMSM

Estimar el esfuerzo y costo del proyecto para los productos de trabajo y tareas con base en una justificacin de estimacin. Establecer y mantener un plan de proyecto como la base para gestionar el proyecto. Establecer y mantener el presupuesto y cronograma del proyecto. Identificar y analizar riesgos del proyecto. Planificar la gestin de datos del proyecto. Planificar los recursos para ejecutar el proyecto. Planificar los conocimientos y habilidades necesarias para ejecutar el proyecto. Planificar la involucracin de las partes interesadas identificadas. Establecer y mantener el plan completo del proyecto. Establecer y mantener los compromisos con el plan de proyecto. Revisar todos los planes que afectan el proyecto para comprender los compromisos del proyecto. Adaptar el plan de proyecto para conciliar recursos disponibles y estimados. Obtener compromiso con las partes interesadas relevantes responsables de ejecutar y apoyar la ejecucin del plan.

3.2.2.3. Monitorizacin Y Control De Proyecto (PMC)

El propsito de Monitorizacin y Control de Proyecto (PMC = Project Monitoring and Control) es proporcionar un entendimiento del avance del proyecto de modo que se puedan tomar acciones correctivas apropiadas cuando el desempeo del proyecto se desva significativamente del plan. Sus objetivos son: El desempeo y avance real del proyecto se monitoriza versus el plan del proyecto. Monitorizar valores reales de parmetros de planificacin de proyecto versus el plan de proyecto. Monitorizar compromisos versus aquellos identificados en el plan de proyecto. Monitorizar riesgos versus aquellos identificados en el plan de proyecto. Monitorizar la gestin de datos del proyecto versus el plan de proyecto. Monitorizar la involucracin de las partes interesadas versus el plan de proyecto. Revisar peridicamente el avance del proyecto, desempeo y problemas.
24

Captulo 3: Estado del Arte

UNMSM

Revisar los logros del proyecto y resultados en hitos seleccionados del proyecto. Las acciones correctivas se gestionan hasta su cierre cuando el desempeo o resultados del proyecto se desvan significativamente del plan. Recolectar y analizar problemas y determinar acciones correctivas para resolverlos. Tomar accin correctiva sobre problemas identificados. Gestionar acciones correctivas hasta su cierre.

3.2.2.4. Gestin De Configuracin (CM)

El propsito de Gestin de Configuracin (CM = Configuration Management) es establecer y mantener la integridad de productos de trabajo usando identificacin de configuracin, control de configuracin, contabilizar el estado de la configuracin y auditorias de configuracin. Se establecen lneas base de entregables identificados de proceso. Identificar elementos de configuracin, componentes y productos de trabajo relacionados a ser colocados bajo gestin de configuracin. Establecer y mantener un sistema de gestin de configuracin y un sistema de gestin de cambios para controlar productos de trabajo. Crear liberar lneas base para uso interno y para entregar al cliente. Realizar seguimiento y control a los cambios a los productos de trabajo bajo gestin de configuracin. Realizar seguimiento a solicitudes de cambio de los elementos de configuracin. Controlar cambios a los elementos de configuracin. Establecer y mantener la integridad de las lneas base. Establecer y mantener registros que describen los elementos de configuracin. Realizar auditorias de configuracin para mantener la integridad de las lneas base de configuracin.

3.2.2.5. Medicin Y Anlisis (MA)

El propsito de Medicin y Anlisis (MA = Measurement and Analysis) es desarrollar y sostener una capacidad de medicin usada para apoyar las necesidades de informacin para gestin. Sus objetivos son:

25

Captulo 3: Estado del Arte

UNMSM

Los objetivos y actividades de medicin estn alineadas con las necesidades y objetivos identificados de informacin. Establecer y mantener objetivos de medicin derivados de las necesidades y objetivos identificados de informacin. Especificar mediciones para resolver objetivos de medicin. Especificar cmo los datos de medicin se obtienen y almacenan. Especificar cmo los datos de medicin se analizan y comunican. Proporcionar los resultados de medicin, que resuelven las necesidades y objetivos identificados de medicin. Obtener datos de medicin especificados. Analizar e interpretar datos de medicin. Gestionar y almacenar datos de medicin, especificaciones de medicin y resultados de anlisis. Comunicar los resultados de medicin y las actividades de anlisis a todas las partes interesadas relevantes.

3.2.2.6.

Aseguramiento De La Calidad De Proceso Y Producto (PPQA)

El propsito del Aseguramiento de la Calidad de Proceso y Producto (PPQA = Process and Product Quality Assurance) es proporcionar al equipo y administracin visibilidad objetiva de los procesos y productos de trabajo asociados. Sus objetivos son: Evaluar objetivamente adherencia del proceso ejecutado y productos de trabajo asociados con las descripciones de proceso, estndares y procedimientos aplicables. Evaluar objetivamente procesos ejecutados seleccionados versus descripciones de proceso, estndares y procedimientos aplicables. Evaluar objetivamente productos de trabajo seleccionados versus descripciones de proceso, estndares y procedimientos aplicables.

26

Captulo 3: Estado del Arte

UNMSM

A los problemas de no conformidad se les hace seguimiento objetivamente y se comunican y se asegura su solucin. Comunicar problemas de calidad y asegurar la solucin de problemas de no conformidad con el equipo y gerentes. Establecer y mantener registros de actividades de aseguramiento de la calidad.

3.3.

Scrum

El marco de Scrum se compone de un conjunto de Equipos Scrum y sus roles asociados; as como de Bloques de Tiempo, Artefactos, y Reglas. Los Equipos Scrum estn diseados para optimizar la flexibilidad y la productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en iteraciones. Cada Equipo Scrum tiene tres roles: 1) El ScrumMaster, que es responsable de asegurar que el proceso es comprendido y seguido 2) El Propietario del Producto (Product Owner), que es responsable de maximizar el valor del trabajo realizado por el Equipo Scrum, 3) El Equipo, que hace el trabajo. El equipo est formado por desarrolladores con todos los conocimientos necesarios para convertir los requerimientos del Propietario del Producto en un incremento potencialmente utilizable del producto al final del Sprint. [Schwaber, Sutherland 11] Scrum emplea bloques de tiempo para crear regularidad. Los elementos de Scrum basados en bloques de tiempo son: la Reunin de Planificacin de la Entrega, la Reunin de Planificacin del Sprint, el Sprint, el Scrum Diario, la Revisin del Sprint, y la Retrospectiva del Sprint. El corazn de Scrum es un Sprint, que es una iteracin de un mes de duracin o menos. La duracin de cada Sprint se mantiene constante a lo largo de todo el esfuerzo de desarrollo. Todos los Sprints utilizan el mismo marco de referencia de Scrum, y proporcionan un incremento de funcionalidad potencialmente utilizable al producto final. Cada Sprint se inicia inmediatamente despus del anterior.

27

Captulo 3: Estado del Arte

UNMSM

Scrum emplea cuatro Artefactos principales. El Product Backlog es una lista priorizada de todo lo que podra ser necesario en el producto. El Sprint Backlog es una lista de tareas para convertir el Product Backlog correspondiente a un Sprint, en un incremento del producto potencialmente entregable. Un Burndown es una medida del backlog restante a travs del tiempo. Un Burndown de Versin mide el Product Backlog restante durante el tiempo correspondiente a una liberacin de una versin. Un Sprint Burndown mide los elementos restantes del Sprint Backlog en el transcurso de un Sprint. Las Reglas sirven de unin para los bloques de tiempo, los roles y los artefactos de Scrum, y se describen en el cuerpo de este documento. Por ejemplo, una regla de Scrum es que slo los miembros del equipo - la gente comprometida a convertir el Product Backlog en un incremento pueden hablar durante un Scrum Diario. En las secciones de "Consejos" que encontrar en este documento se describen formas de aplicar Scrum que no son reglas, sino ms bien sugerencias.

3.3.1. Roles de Scrum

El Equipo Scrum consiste en el ScrumMaster, el Propietario del Producto, y el Equipo. A los miembros del equipo Scrum se les llama "cerdos". El Propietario del Producto es el "cerdo" del Product Backlog. El equipo es el "cerdo" del trabajo del Sprint. El ScrumMaster es el "cerdo" del proceso de Scrum. Todo el resto de personas involucradas son "gallinas". Las "gallinas" no pueden decir a los "cerdos" cmo hacer su trabajo. El smil de las "gallinas" y los "cerdos" viene de la siguiente historia: "Estn juntos una gallina y un cerdo, cuando la gallina dice:" Vamos a abrir un restaurante! " El cerdo se lo piensa y dice, "Cmo llamaremos al restaurante?" La gallina, dice, "Huevos con Jamn!" El cerdo dice: "No, gracias, yo estara comprometido, pero t solamente estaras involucrada"

3.3.1.1. El ScrumMaster
El ScrumMaster es responsable de asegurar que el equipo Scrum se adhiere a los valores, prcticas y normas Scrum. El ScrumMaster ayuda a que el Equipo Scrum y la organizacin adopten Scrum. El ScrumMaster ensea al Equipo Scrum mediante entrenamiento y liderndolo para que sea ms productivo y a construya productos de mayor calidad. El ScrumMaster ayuda a que el Equipo Scrum comprenda y utilice la auto-gestin y a ser multidisciplinar. El ScrumMaster tambin debe ayudar al Equipo Scrum a entregar lo mejor de s mismo, en un entorno de organizacin que posiblemente an no est optimizado para el desarrollo de
28

Captulo 3: Estado del Arte

UNMSM

productos complejos. Cuando el ScrumMaster ayuda a realizar estos cambios, esto recibe el nombre de "eliminar impedimentos." El papel del ScrumMaster es el de servidor y lder del equipo de Scrum. Sin embargo, el ScrumMaster no gestiona al Equipo Scrum; el equipo Scrum es auto-gestionado.

3.3.1.2. El Propietario del Producto (Product Owner)

El Propietario del Producto es la nica persona responsable de gestionar el Product Backlog y asegurar el valor del trabajo que el equipo lleva a cabo. Mantiene el Product Backlog y asegura la visibilidad del mismo para todos. Todo el mundo sabe qu elementos tienen la mxima prioridad, por lo que todo el mundo sabe en qu se va a trabajar. El Propietario del Producto es una persona, no un comit. Pueden existir comits que le aconsejen o le influencien, pero aquellos que quieran cambiar la prioridad de un elemento tendrn que convencerle. Las empresas que adoptan Scrum, pueden encontrarse con el hecho de que Scrum influye en sus mtodos para establecer las prioridades y los requisitos a travs del tiempo. Para que el Propietario del Producto tenga xito, todos en la organizacin deben respetar sus decisiones. Nadie est autorizado a obligar al Equipo a trabajar bajo un conjunto diferente de prioridades, y a los Equipos no se les permite prestar atencin a nadie que diga lo contrario. Las decisiones del Propietario del Producto se hacen visibles en el contenido y la priorizacin del Product Backlog. Esta visibilidad requiere que el Propietario del Producto d lo mejor de s mismo, y hace que Propietario del Producto sea un rol exigente adems de gratificante.

3.3.1.3. El Equipo
Los Equipos de desarrolladores convierten el Product Backlog en incrementos de funcionalidad potencialmente entregables en cada Sprint. Los Equipos tambin son multifuncionales; los miembros del equipo deben tener todas las habilidades necesarias para crear un incremento de trabajo. Los miembros del Equipo a menudo tienen habilidades especializadas, como la programacin, el control de calidad, el anlisis de negocio, la arquitectura, el diseo de la interfaz de usuario o el diseo de bases de datos. Sin embargo, las habilidades que el miembro del Equipo comparte - es decir, la habilidad de tratar con un requisito y convertirlo en un
29

Captulo 3: Estado del Arte

UNMSM

producto utilizable - tienden a ser ms importantes que aquellas que no comparte. Las personas que se niegan a escribir cdigo, ya que son arquitectos o diseadores, no se ajustan bien a los Equipos. Todo el mundo interviene, incluso si eso requiere aprender nuevas habilidades o recordar las antiguas. No hay ttulos en los Equipos, y no hay excepciones a esta regla. Los equipos tampoco contienen sub-Equipos dedicados a reas particulares, como pruebas o anlisis de negocio. Los Equipos tambin se auto-organizan. Nadie - ni siquiera el ScrumMaster - dice al Equipo cmo convertir el Product Backlog en incrementos de funcionalidad entregable. El Equipo busca por su cuenta la mejor forma de hacerlo. Cada miembro del equipo aplica su experiencia a todos los problemas. La sinergia resultante mejora la eficiencia global de todo el Equipo, y la eficacia. El tamao ptimo para un equipo es de siete personas, ms o menos dos. Cuando hay menos de cinco miembros en el Equipo, hay menos interaccin y como resultado hay menos aumento de la productividad. Es ms, el Equipo puede encontrar limitaciones de habilidad en ciertos momentos del Sprint y no poder entregar una porcin entregable del producto. Si hay ms de nueve miembros, el problema simplemente es que se necesita demasiada coordinacin. Los equipos grandes generan demasiada complejidad como para que pueda ser gestionada por un proceso emprico. Sin embargo, nos hemos encontrado con algunos Equipos exitosos que han superado los lmites superior e inferior de este rango de tamao. Los roles del Propietario del Producto y del ScrumMaster no se computan en este rango a menos que sean tambin cerdos, que trabajen en las tareas del Sprint Backlog. La composicin del Equipo puede cambiar al final de un Sprint. Cada vez que se cambian los miembros del Equipo, la productividad obtenida de la auto-organizacin se ve disminuida. Por esta razn se debe tener cuidado al cambiar la composicin del equipo.

3.3.2. Bloques de Tiempo

Los Bloques de Tiempo en Scrum son la Reunin de Planificacin de la Entrega, el Sprint, la Reunin de Planificacin del Sprint, la Revisin del Sprint, la Retrospectiva del Sprint, y el Scrum Diario.

30

Captulo 3: Estado del Arte

UNMSM

Figura 3 Medologia de Scrum [Schwaber, Sutherland 11]

3.3.2.1. Reunin de Planificacin de la Entrega

El propsito de la planificacin de la entrega es establecer un plan y unas metas que los Equipos Scrum y el resto de las organizaciones puedan entender y comunicar. La planificacin de la entrega responde a las preguntas: "Cmo podemos convertir la visin en un producto ganador, de la mejor manera posible? Cmo podemos alcanzar o mejorar la satisfaccin del cliente deseada y el Retorno de la Inversin?. El plan de entrega establece el objetivo de la entrega, el Product Backlog de mayor prioridad, los principales riesgos, y las caractersticas generales y la funcionalidad que va a contener la entrega. Tambin establece una fecha probable de entrega, y el coste, que debera mantenerse si no cambia nada. La organizacin puede inspeccionar el avance y hacer cambios a este plan de entrega en cada Sprint. La planificacin de entrega es completamente opcional. Si los Equipos Scrum empiezan a trabajar sin esta reunin, la ausencia de los artefactos generados en ella se revelar en la forma de
31

Captulo 3: Estado del Arte

UNMSM

impedimentos que hay que resolver. El trabajo necesario para resolver cada impedimento se convertir en un elemento del Product Backlog. Los productos se construyen utilizando Scrum de forma iterativa, de modo que cada Sprint crea un incremento del producto, empezando por lo ms valioso y de mayor riesgo. Ms y ms Sprints van generando incrementos adicionales del producto. Cada incremento es una parte potencialmente entregable de todo el producto. Cuando se han creado los suficientes incrementos de valor para el producto, de utilidad para sus inversores, la versin del producto es entregada. La mayora de las organizaciones ya tienen un proceso de planificacin de entregas, y en la mayora de estos procesos, la mayor parte de la planificacin se realiza al comienzo del proceso, y no se modifica a lo largo del tiempo. En la planificacin de la entrega en Scrum, se definen un objetivo general y los resultados probables. Esta planificacin de entrega por lo general no requiere ms de un 15-20% del tiempo consumido por una organizacin para construir un plan de entrega tradicional. Sin embargo, durante el trabajo en una entrega con Scrum, se realizar planificacin sobre la marcha en cada Revisin del Sprint y Reunin de Planificacin del Sprint, as como diariamente en cada reunin diaria de Scrum. En total, los esfuerzos de planificacin de una entrega de Scrum probablemente consumen muy poco esfuerzo ms que los de la planificacin de entrega tradicional. La planificacin de una entrega requiere estimar y priorizar los elementos del Product Backlog para dicha entrega. Hay muchas tcnicas para hacer esta estimacin y priorizacin, que se encuentran fuera del mbito de Scrum, pero que son tiles cuando se utilizan en combinacin con Scrum.

3.3.2.2. El Sprint
Un Sprint es una iteracin. Los Sprints estn limitados en bloques de tiempo. Durante el Sprint, el ScrumMaster asegura que no se realizan cambios que afecten al Objetivo del Sprint. Tanto la composicin del Equipo como los objetivos de calidad se mantienen constantes durante todo el Sprint. Los Sprints se componen de: la Reunin de Planificacin de Sprint, el trabajo de desarrollo, la Revisin del Sprint, y la Retrospectiva del Sprint. Los Sprints ocurren uno tras otro, sin tiempo entre ellos.

32

Captulo 3: Estado del Arte

UNMSM

Un proyecto se utiliza para lograr un resultado; en desarrollo de software, se utiliza para crear un producto o sistema. Cada proyecto consiste en una definicin de lo que se va a construir, un plan para construirlo, el trabajo realizado de acuerdo con el plan, y el producto resultante. Cada proyecto tiene un horizonte, es decir, el plazo para el que el plan es bueno. Si el horizonte es demasiado lejano, la definicin puede haber cambiado, pueden haber intervenido demasiadas variables, el riesgo puede ser demasiado grande, etc. Scrum es un marco para un proyecto cuyo horizonte no es superior a un mes, y en el cual hay suficiente complejidad para que un horizonte ms largo sea demasiado arriesgado. La previsibilidad del proyecto tiene que ser controlada por lo menos cada mes, y el riesgo de que el proyecto pueda descontrolarse o volverse impredecible, debe contenerse por lo menos cada mes. Un Sprint puede ser cancelado antes de que el bloque de tiempo del Sprint se haya terminado. Slo el Propietario del Producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo, o del ScrumMaster. Bajo qu tipo de circunstancias puede un Sprint ser cancelado? La gerencia puede necesitar cancelar un Sprint si el objetivo del Sprint se queda obsoleto. Esto podra ocurrir si la empresa cambia de direccin, o si cambia el mercado o las condiciones de la tecnologa. En general, un Sprint debe ser cancelado si dadas las circunstancias ya no tiene sentido. Sin embargo, debido a la corta duracin de los Sprints, rara vez tiene sentido hacer esta cancelacin. Cuando un Sprint se cancela, cualquier elemento del Product Backlog que haya sido completado y "hecho", es revisado. Estos elementos son aceptados si representan un incremento potencialmente entregable. Si no es as, el elemento se vuelve a colocar en el Product Backlog con sus estimaciones iniciales. Cualquier trabajo realizado en l se asume como perdido. La cancelacin de un Sprint consume recursos, ya que todo el mundo tiene que reagruparse en otra Reunin de Planificacin de Sprint para iniciar otro Sprint. Las cancelaciones de Sprints son a menudo traumticas para el equipo, y muy poco frecuentes.

3.3.2.3. Reunin de Planificacin del Sprint

Durante Reunin de Planificacin del Sprint la iteracin es planificada. La reunin se restringe a un bloque de tiempo de ocho horas para un Sprint de un mes. Para Sprints ms cortos, se debera
33

Captulo 3: Estado del Arte

UNMSM

reservar para esta reunin un tiempo proporcionalmente menor, aproximadamente el 5% de la longitud total del Sprint (por ejemplo, para un Sprint de dos semanas sera una Reunin de Planificacin de cuatro horas). La Reunin de Planificacin del Sprint y consta de dos partes. La primera parte, un bloque de cuatro horas, es cuando se decide lo que se har durante el Sprint. La segunda parte (otro bloque de cuatro horas para un Sprint de un mes), es cuando el equipo determina cmo se va a convertir esta funcionalidad en un incremento del producto durante el Sprint. Hay dos partes en la Reunin de Planificacin del Sprint: la parte del "Qu?" y la parte del "Cmo?". Algunos Equipos Scrum combinan las dos. En la primera parte, el Equipo Scrum aborda la cuestin del "Qu?". El Propietario del Producto presenta al equipo la parte ms prioritaria del Product Backlog. Trabajan juntos para determinar qu funciones se van a desarrollar durante el prximo Sprint. La informacin de entrada para esta reunin es el Product Backlog, el ltimo incremento del producto, la capacidad del Equipo y el rendimiento anterior del Equipo. La cantidad de Backlog que el Equipo selecciona es una decisin del Equipo. Slo el Equipo puede evaluar lo que puede lograr en el prximo Sprint. Una vez seleccionado el Product Backlog, se define un Objetivo para el Sprint. El Objetivo del Sprint es una meta que se alcanzar mediante la implementacin del Product Backlog. Es una declaracin que sirve de orientacin al equipo acerca de por qu se est construyendo el incremento. El Objetivo del Sprint es un subconjunto del objetivo de la entrega. La razn para tener un Objetivo del Sprint es dar al equipo un margen de maniobra respecto a la funcionalidad. Por ejemplo, el Objetivo para un Sprint podra ser: "Automatizar la funcionalidad de modificacin de la cuenta del cliente mediante de un middleware de transacciones seguras y recuperables." A medida que el Equipo trabaja, mantiene este objetivo en mente. A fin de satisfacer el objetivo, implementa la funcionalidad y la tecnologa. Si el trabajo resulta ser ms duro de lo que el equipo haba previsto, entonces, el equipo colabora con el Propietario del Producto y slo implementa parcialmente la funcionalidad. En la segunda parte de la Reunin de Planificacin del Sprint, el equipo aborda la cuestin del "Cmo?". Durante la segunda mitad de la Reunin de Planificacin del Sprint (bloque de cuatro horas para un Sprint de un mes), el Equipo debe determinar cmo convertir en un incremento, el
34

Captulo 3: Estado del Arte

UNMSM

Product Backlog (el "Qu") seleccionado durante la reunin de planificacin de Sprint. El Equipo por lo general comienza por el diseo del trabajo. Mientras disean, identifican tareas. Estas tareas son las porciones detalladas del trabajo necesario para convertir el Product Backlog en software que funciona. Las Tareas se deben descomponer para que se puedan completar en menos de un da. Esta lista de tareas se llama Sprint Backlog. El Equipo se organiza para asignar y realizar el trabajo contenido en el Sprint Backlog, ya sea durante la Reunin de Planificacin del Sprint, o sobre la marcha durante el Sprint. El Propietario del Producto est presente en la segunda parte de la Reunin de Planificacin del Sprint para aclarar el Product Backlog y ayudar a llegar a posibles acuerdos. Si el Equipo determina que tiene demasiado trabajo, o demasiado poco, puede renegociar el Product Backlog con el Propietario del Producto. El Equipo tambin puede invitar a otras personas a estar presentes, con el fin de proporcionar asesoramiento tcnico o de dominio. En esta reunin, un Equipo nuevo a menudo se da cuenta de que, o bien se hundir, o saldr a flote como un equipo, no individualmente. El Equipo se da cuenta de que debe apoyarse en s mismo. Al aceptar esto, comienza a auto-organizarse para llegar a tener las caractersticas y el comportamiento de un verdadero equipo.

3.3.2.4. Revisin del Sprint

Al final del Sprint, se lleva a cabo una reunin de Revisin de Sprint. Esta es una reunin restringida a un bloque de tiempo de cuatro horas para un Sprint de un mes. Para Sprints de menor duracin, hay que asignar proporcionalmente menos tiempo de la longitud total para esta reunin (por ejemplo, para dos semanas, la Revisin del Sprint sera de dos horas); esta reunin no debe consumir ms de 5% del total del Sprint. Durante la Revisin de Sprint, el Equipo Scrum y las partes interesadas debaten sobre lo que se acaba de hacer. En base a eso, y a los cambios en el Product Backlog que se hayan hecho durante el Sprint, colaboran para determinar las prximas cosas que se podran hacer. Se trata de una reunin informal, en la que la presentacin de la funcionalidad est destinada a fomentar la colaboracin para determinar qu hacer a continuacin. La reunin incluye por lo menos lo siguiente: El Propietario del Producto identifica lo que se ha hecho y lo que no se ha hecho. El Equipo analiza lo que sali bien durante el Sprint y cules son
35

Captulo 3: Estado del Arte

UNMSM

los problemas que encontr, y cmo resolvi estos problemas. El Equipo entonces muestra el trabajo que ha sido completado y responde preguntas. El Propietario del Producto a continuacin, analiza el Product Backlog en su estado actual. Proyecta las fechas probables de finalizacin con distintos supuestos de velocidad. Todo el grupo colabora entonces sobre lo que ha visto y lo que esto significa en cuanto a qu hacer a continuacin. La Revisin de Sprint ofrece una valiosa aportacin a la siguiente Reunin de Planificacin de Sprint.

3.3.2.5. Retrospectiva del Sprint

Despus de la Revisin del Sprint, y antes de la prxima Reunin de Planificacin de Sprint, el Equipo Scrum mantiene una reunin Retrospectiva del Sprint. Es una reunin restringida a un bloque de tiempo de tres horas para Sprints de un mes (asignar tiempo proporcionalmente menor para Sprints de longitud menor). En esta reunin, el ScrumMaster alienta al Equipo Scrum a revisar, en el marco de proceso y prcticas de Scrum, su proceso de desarrollo, para que sea ms eficaz y agradable para el prximo Sprint. Muchos libros documentan tcnicas que son tiles para su uso en las Retrospectivas. El propsito de la Retrospectiva es inspeccionar cmo fue el ltimo Sprint en lo que respecta a las personas, relaciones, procesos y herramientas. La inspeccin debera identificar y priorizar los principales elementos que hayan ido bien y aquellos elementos que si se hiciesen de forma diferente, podran producir mejoras. Entre estos elementos se incluyen la composicin del equipo Scrum, la organizacin de las reuniones, las herramientas, la definicin de "hecho", los mtodos de comunicacin, y los procesos para convertir los elementos del Product Backlog en algo "hecho". Al final de la Retrospectiva del Sprint, el Equipo Scrum debera haber identificado acciones concretas de mejora que se implementarn en el prximo Sprint. Estos cambios se convierten en la adaptacin derivada de la inspeccin emprica.

3.3.2.6. Scrum Diario

Cada Equipo se rene todos los das 15 minutos en una reunin de inspeccin y adaptacin llamada Scrum Diario. El Scrum Diario se lleva a cabo a la misma hora y en el mismo lugar a lo largo de todos los Sprints. Durante la reunin, cada miembro del equipo, explica: 1. Lo que ha conseguido hacer desde la ltima reunin;
36

Captulo 3: Estado del Arte 2. Lo que va a hacer hasta la prxima reunin, y 3. Qu obstculos tiene en su camino.

UNMSM

Los Scrums Diarios mejoran las comunicaciones, eliminan otras reuniones, identifican y eliminan los impedimentos al desarrollo, destacan y promueven la rpida toma de decisiones y mejoran el nivel de conocimiento de los proyectos. El ScrumMaster se asegura de que el Equipo mantiene la reunin. El Equipo es responsable de conducir el Scrum Diario. El ScrumMaster ensea al Equipo a mantener el Scrum Diario breve, mediante la aplicacin de las reglas, y asegurndose de que la gente es breve. El ScrumMaster tambin hace cumplir la regla de que a las gallinas no se les permite hablar ni de ninguna manera interferir en el Scrum Diario. El Scrum Diario no es una reunin de seguimiento del estado del proyecto. No es para cualquiera, sino slo para la gente que trabaja en transformar los elementos del Product Backlog en un incremento (el Equipo). El Equipo se ha comprometido a un Objetivo del Sprint, y a los correspondientes elementos del Product Backlog. El Scrum Diario (con las tres preguntas) constituye una inspeccin de los progresos hacia ese Objetivo del Sprint. Por lo general se mantienen reuniones subsiguientes, para adecuar el trabajo futuro en el Sprint. La intencin es optimizar la probabilidad de que el equipo logre su Objetivo. sta es una reunin clave de revisin y adaptacin en el proceso emprico de Scrum.

3.3.3. Artefactos de Scrum

Los Artefactos de Scrum incluyen: el Product Backlog, el Burndown de entrega, el Sprint Backlog, y el Sprint Burndown.

3.3.3.1. Product Backlog y Burndown de Entrega

Los requisitos para el producto, que el/los Equipo/s est/n elaborando, estn listados en el Product Backlog. El Propietario del Producto es responsable del Product Backlog, de su contenido, disponibilidad y priorizacin. El Product Backlog nunca est completo. La primera versin para el desarrollo, tan slo establece los requisitos inicialmente conocidos, y que son entendidos mejor. El Product Backlog evoluciona a medida que el producto y el entorno en el
37

Captulo 3: Estado del Arte

UNMSM

que se utilizar evoluciona. El Product Backlog es dinmico, ya que cambia constantemente para identificar qu necesita el producto para ser adecuado, competitivo y til. Mientras existe un producto, el Product Backlog tambin existe. El Product Backlog representa todo lo necesario para desarrollar y lanzar un producto exitoso. Se trata de una lista de todas las caractersticas, funciones, tecnologas, mejoras y correcciones de errores que constituyen los cambios que se harn al producto para futuras versiones. Los elementos del Product Backlog deben tener los siguientes atributos: una descripcin, una prioridad, y una estimacin. La prioridad est guiada por el riesgo, el valor y la necesidad. Hay muchas tcnicas para evaluar estos atributos. El Product Backlog est ordenado por prioridad. La parte ms prioritaria del Product Backlog determina las actividades de desarrollo que se llevarn a cabo de forma inmediata. Cuanto mayor sea la prioridad, el elemento es ms urgente, es sobre el que ms se ha pensado, y es el que atesora mayor consenso en cuanto a su valor. La parte ms prioritaria del Product Backlog est ms clara, y tiene informacin ms detallada que el Product Backlog de menor prioridad. Recibe mejores estimaciones, basadas en la mayor claridad y el mayor detalle. Cuanto menor sea la prioridad, menor es el detalle, hasta el punto de que puede hacerse difcil distinguir claramente un elemento de baja prioridad. A medida que se utiliza un producto, que aumenta su valor, y que el mercado proporciona retroalimentacin, el Product Backlog se va revelando como una lista ms amplia y exhaustiva. Los requisitos nunca dejan de cambiar. El Product Backlog es un documento vivo. Los cambios en los requisitos de negocio, las condiciones del mercado, la tecnologa, y el personal, causan cambios en el Product Backlog. Para minimizar la repeticin del trabajo, slo se deben detallar los elementos de ms alta prioridad. Los elementos del Product Backlog que ocuparn a los Equipos en los prximos Sprints tienen un alto nivel de detalle, habiendo sido descompuestos para que cualquier elemento pueda completarse dentro de la duracin del Sprint. A menudo, varios equipos Scrum trabajan juntos en el mismo producto. En ese caso, se utiliza un solo Product Backlog para describir el trabajo futuro en el producto. Se utiliza entonces un atributo del Product Backlog que agrupa a los elementos. La agrupacin puede hacerse por

38

Captulo 3: Estado del Arte

UNMSM

conjunto de caractersticas, por tecnologa o por arquitectura, y es utilizada a menudo por el Equipo Scrum como una forma de organizar el trabajo. El grfico de Burndown de la Entrega registra la suma del esfuerzo restante estimado del Product Backlog a lo largo del tiempo. El esfuerzo se estima en cualquier unidad de trabajo que el Equipo Scrum, y la organizacin, hayan decidido. La unidad de tiempo que se utiliza generalmente es el Sprint. Durante la Planificacin de la Entrega se calculan inicialmente las estimaciones de los elementos del Product Backlog y, tambin posteriormente, a medida que los elementos son creados. Durante la preparacin del Product Backlog las estimaciones son examinadas y revisadas. Sin embargo, pueden ser actualizadas en cualquier momento. El equipo es responsable de todas las estimaciones. El Propietario del Producto puede influir en el Equipo, ayudando a comprender y optar por soluciones de compromiso, pero la estimacin final la hace el Equipo. El Propietario del Producto mantiene publicados el Product Backlog y la grfica de Burndown de Entrega actualizados en todo momento. Se puede trazar una lnea de tendencia en la grfica, basndose en el cambio en el trabajo restante.

3.3.3.2. Sprint Backlog y Sprint Burndown

El Sprint Backlog se compone de las tareas que el Equipo realiza para convertir los elementos del Product Backlog en un incremento "hecho". Muchas de ellas se desarrollan durante la Reunin de Planificacin del Sprint. Constituyen todo el trabajo que el equipo identifica como necesario para cumplir con el Objetivo del Sprint. Los elementos del Sprint Backlog deben descomponerse. La descomposicin debe ser suficiente para que los cambios en curso puedan ser entendidos en el Scrum Diario. El tamao normal para un elemento del Sprint Backlog en el que se est trabajando es de un da o menos. El equipo modifica el Sprint Backlog a lo largo de todo el Sprint, as como la parte de Sprint Backlog adicional que surja durante el Sprint. A medida que se van concretando tareas individuales, se puede descubrir que se necesitan ms o menos tareas, o que una determinada tarea llevar ms o menos tiempo de lo previsto. A medida que es necesario nuevo trabajo, el
39

Captulo 3: Estado del Arte

UNMSM

Equipo lo aade al Sprint Backlog. A medida que se va trabajando o se terminan tareas, se actualizan las horas de trabajo estimado restante para cada tarea. Cuando alguna tarea se revela como innecesaria, es eliminada. Slo el Equipo puede cambiar su Sprint Backlog durante un Sprint. Slo el Equipo puede cambiar el contenido, o las estimaciones. El Sprint Backlog es una instantnea muy visible y en tiempo real del trabajo que el equipo tiene previsto realizar durante el Sprint, y pertenece exclusivamente al Equipo.

3.3.3.3. Hecho
Scrum requiere que los Equipos construyan un incremento de la funcionalidad del producto en cada Sprint. Este incremento debe ser potencialmente entregable, ya que el Propietario del Producto puede decidir liberar la funcionalidad de forma inmediata. Para ello, el incremento debe constituir una porcin completa del producto. Debe estar "hecho". Cada incremento debera ser aditivo a todos los incrementos anteriores, y debera ser probado exhaustivamente, de modo que se asegure que todos los incrementos funcionan en conjunto. Durante el desarrollo del producto, asegurar que una determinada funcionalidad est completada, podra llevar a alguien a asumir que ha sido al menos codificada limpiamente, refactorizada, sometida a pruebas unitarias, construida y sometida a pruebas de aceptacin. Alguien distinto podra asumir tan solo que el cdigo ha sido construido. Si alguien no conoce cul es la definicin de hecho, los otros dos pilares del control emprico de procesos no funcionan. Cuando alguien describe algo como hecho, todo el mundo debe entender qu significa hecho. Hecho define lo que el equipo quiere decir, cuando se compromete a hacer un elemento del Product Backlog en un Sprint. Algunos productos no contienen documentacin, por lo que la definicin de hecho no incluye a la documentacin. Un incremento totalmente hecho incluye todo el anlisis, diseo, refactorizacin, programacin, documentacin y pruebas para el incremento, y para todos los elementos del Product Backlog correspondientes al incremento. Las pruebas incluyen testeo unitario, de sistema, de usuario y de regresin, as como pruebas no funcionales como pruebas de rendimiento, de estabilidad, de seguridad y de integracin. Hecho incluye cualquier internacionalizacin. Algunos Equipos no son capaces en un principio de incluir todo lo requerido para la implementacin en su definicin de hecho. Esto debe quedar

40

Captulo 3: Estado del Arte

UNMSM

muy claro para el Propietario del Producto. Este trabajo restante deber ser hecho antes de que el producto pueda ser implementado y utilizado.

41

Captulo 4: Aporte Terico

UNMSM

CAPTULO 4: APORTE TERICO

42

Captulo 5: Aporte Prctico

UNMSM

CAPTULO 5: APORTE PRCTICO

CAPTULO 6: IMPLEMENTACIN CAPTULO 7: CONCLUSIONES Y TRABAJOS FUTUROS

43

8. REFERENCIAS BIBLIOGRFICAS
Libros [Ngwenyama,Nielsen 03]. Ojelanki Ngwenyama and Peter Axel Nielsen, Competing Values in Software Process Improvement: An Assumption Analysis of CMM From an Organizational Culture Perspective, 2003, Richmond-USA. [Quinn, McGrant 85] R. E. Quinn and M. R. McGrath, The transformation of organizational cultures: A competing values perspective, CA: Sage, Newbury Park, 1985,
[Paulk, Curtis 91] M.C.Paulk, B. Curtis, Capability Maturity Model for Software, Software

Engineering Institute, 1991, Carnegie Mellon-EEUU. [Schwaber, Sutherland 11] Ken Schwaber and Jeff Sutherland, Scrum Guide,2012,USA [SEI 10] Software Engineering Institute, CMMI for Development, SEI Administrative Agent, 2010, USA URL [SEI 12] Software Engineering Institute, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document, http://www.sei.cmu.edu/library/abstracts/reports/01hb001.cfm, consultado el 20 abril del2012.

Documentos [Crosland 10] rea de finanzas, Estados financieros, 2012, Lima, Per

44