You are on page 1of 59

UNIVERSIDAD AUTONOMA DE

TAMAULIPAS
DESARROLLO DE APLICACIONES
MÓVILES CON METODOLOGÍAS ÁGILES:
UTILIZANDO SCRUM PARA LA
CONSTRUCCIÓN DE SOFTWARE PARA
ANDROID

TESIS
QUE PRESENTA
ELOY NEGRETE HOZ

EN OPCION AL EXAMEN PROFESIONAL DE
LICENCIADO EN INFORMATICA

REGISTRO NO. 201313
NUEVO LAREDO, TAMAULIPAS, JUNIO DE 2013.

UNIVERSIDAD AUTONOMA DE
TAMAULIPAS

DESARROLLO DE APLICACIONES MÓVILES CON METODOLOGÍAS
ÁGILES: UTILIZANDO SCRUM PARA LA CONSTRUCCIÓN DE SOFTWARE
PARA ANDROID

TESIS

QUE PRESENTA
ELOY NEGRETE HOZ

EN OPCION AL EXAMEN PROFESIONAL DE
LICENCIADO EN INFORMATICA

DIRECTOR DE TESIS:
DR. RAMÓN VENTURA ROQUE HERNÁNDEZ
ASESORES:
ADÁN LÓPEZ MENDOZA, MTI.
SALVADOR MOTA MARTINEZ, MTI.

Agradecimientos

Resumen

En esta tesis se resumen las características de Scrum, una metodología ágil para el
desarrollo de software con equipos auto organizados y se presenta un caso de estudio en
el que un grupo de programadores la utilizó para desarrollar una aplicación móvil en
Java para Android contando con un corto plazo para la entrega final. Se estudiaron
aspectos como la dinámica del equipo de trabajo, la percepción de los involucrados y la
calidad del producto final. Los resultados obtenidos se presentan con enfoques
cuantitativos y cualitativos desde las perspectivas de los participantes e investigadores.

Abstract

This thesis summarizes the characteristics of Scrum, an agile methodology for software
development teams self-organized and presents a case study in which a group of
programmers used to develop a mobile application for Android Java and have a short
term to final delivery. We studied the dynamic aspects such as team work, the
perception of those involved and the quality of the final product. The results are
presented with quantitative and qualitative approaches from the perspectives of the
participants and researchers.

..........5 1.....................1 Reunión de planificación de Sprint....................................................................................................19 2....................11 2..................................4..............................................2 El manifiesto Ágil...........................................8 2.................2..18 2.....10 2.....................4 Experiencias previas con la metodología Scrum....................................................................................27 3..5 Android SO...25 3..... 31 3............................................................ 22 3..............................1 Antecedentes...... 28 3......................................................................................................... 38 ...........4.........2...........................................................................3........................................................22 3.......................4 Iphone OS........... 14 2.................2 Objetivo del trabajo.1 Origen del Problema.........17 2.................................2 El papel del Scrum Master.................................................6 Retrospectiva.....................................................................................................................................4...................................................................................................................3 Windows Mobile (Windows Phone)...... 33 4... 32 CAPITULO IV CASO DE ESTUDIO.......3..................................................... 31 3........4 Daily Scrum.......................................2 Sistema operativo Symbian OS.................................1 Scrum.......................................................................7 CAPITULO II MARCO TEÓRICO............ 5 1...........1 El papel de propietario de un producto.......................................................................................................... 23 3.................................4 Organización de la Tesis...........3 Sistemas operativos móviles................................Índice de contenido CAPITULO I........33 4.3 Metodología utilizada......................................................... 8 2.....................................3...........4..................................................3............3 El papel de los miembros del equipo..28 3.........................10 2........3........................................ INTRODUCCIÓN..................................... 6 1................................ 12 2........................ 9 2....................................2 Justificación de la metodología............................5 Revisión del Sprint.............................................. 21 CAPITULO III SCRUM: UNA METODOLOGÍA ÁGIL......4 El proyecto.................................................................5 Conclusiones......... 20 2................... 36 4.....................4.3................24 3.....2 Los roles de scrum...............................................................................17 2....3 Product Backlog.............................................................................2....1 Descripción...................................1 Sistema Operativo Palm OS..3 Implementación de SCRUM....1 Metodologías agiles........12 2.......2 Presentación.......................................................3 El Sprint................ 6 1....................................................

.13 Entrega del producto......................... 53 Anexo 1.......................................................................................................................................4.........................................................................................................................................................43 4...................................... 45 5.......................................7 Sprint Review.........................1 Conclusiones.............................................9 Segundo Daily Scrum......5 Daily Scrum............... 43 4.................................................................45 5....................................................50 5............. 39 4...........................................................................................................44 CAPITULO V..................45 5..........2 Perspectiva de los investigadores...................................11 Segundo SPrint Review.................................................................................2 Discusión.......8 Sprint Retrospective.......................................................................... 39 4.....................................................................10 Segundo Sprint............................38 4...........1...........................................12 Segundo Sprint Retrospective....... 54 REFERENCIAS...............................6 Primer Sprint.............1 Resultados obtenidos. 41 4.....................................................................4 Sprint planning meeting................1...............................................1 Perspectiva de los participantes........44 4............................................................................................... 51 CAPITULO VI. 55 .... 53 6..........................42 4......................................................................................................42 4..............

el cual contiene los fundamentos de estas metodologías (Letelier. En el mundo actual. las cuales ponen a prueba la capacidad del equipo de trabajo para entregar resultados en función de los principios expresados en el manifiesto ágil (Manifiesto Agil. el desarrollo de aplicaciones móviles responde a un mercado de usuarios con necesidades cambiantes que puede beneficiarse por el uso de metodologías ágiles. 2006). cuya naturaleza se acepta ya que produce oportunidades de ventaja competitiva para al cliente. 2005)l. Todo esto en un escenario de requerimientos cambiantes. se enfatiza el desarrollo rápido de software funcional y útil sin producir documentación innecesaria o adicional. Se busca establecer una mejor relación entre todos los participantes dejando que ellos mismos vayan construyendo el entorno donde desarrollarán el software. se pretende que él sea parte importante del equipo de trabajo y que colabore activamente durante todo el proyecto.1 Antecedentes Las metodologías de desarrollo ágiles se caracterizan por aceptar desde el principio que los requisitos del software son cambiantes por naturaleza y son difíciles de predecir. actual y contextualizada de estas prácticas en la Ingeniería de software.CAPITULO I. También la comunicación con el cliente es esencial. INTRODUCCIÓN 1. diseño y construcción del software en diferentes modelos de carácter iterativo e incrementa (Persman. intercalan actividades de análisis. Algunos de los principios del manifiesto ágil son: los integrantes del equipo de trabajo interactúan entre sí para evaluar el tipo de herramientas que se utilizará durante el proceso. Por otra parte. 2001). 5 . Una recopilación y análisis de antecedentes y experiencias acerca de la aplicación de metodologías ágiles a los desarrollos móviles contribuirá a construir una realidad fundamentada.

la cual cuenta con una mejorada interfaz gráfica y un destacado desempeño con el hardware. todos ellos estudiantes de carreras profesionales de sistemas computacionales e informática. 2012) es uno de los sistemas operativos para dispositivos móviles más nuevos en el mercado mundial. Con esta información. En este trabajo se presentan los resultados obtenidos y también se reflexiona sobre las ventajas y desventajas percibidas por los participantes e investigadores. 1. está desarrollado en la plataforma Linux y fue concebido para su implementación en dispositivos móviles. Scrum se implementó en la construcción de una aplicación móvil con el lenguaje de programación Java para el sistema operativo Android. En la investigación se utilizará un teléfono 6 . su grado de motivación sobre la metodología y la posible aplicación de lo aprendido en proyectos futuros.2 Objetivo del trabajo El objetivo de este trabajo es presentar una evidencia práctica del uso de Scrum (Chris Sims.3 Metodología utilizada La metodología que se utilizó la siguiente: primero. El grupo trabajó en un proyecto de software en el lenguaje Java (Schildt. 2011) en el desarrollo de aplicaciones móviles. En esta etapa también se enfatizó el trabajo existente acerca de la aplicación de metodologías ágiles en el desarrollo de software para entornos móviles. Android (Girones. Para tal efecto. se llevó a cabo un caso de estudio en el que se realizó un ejercicio experimental de desarrollo de software con ocho programadores.0 (Ice Cream Sandwich). La versión a utilizar será la 4.1. Al final se aplicó una encuesta a cada uno de los participantes con el objetivo de analizar su postura. se eligió una metodología ágil (Scrum) y se diseñó un experimento que fue conducido en un grupo de programadores. se condujo una investigación bibliográfica para determinar cuáles son las metodologías ágiles más relevantes y cuáles son sus características principales. 2011) para la plataforma Android implementando la metodología de desarrollo.

7 . se comenta su origen. también se tomarán en cuenta los resultados de la observación de los conductores del experimento 1. En el quinto capítulo se encuentran los resultados obtenidos durante el experimento. se presentan los resultados más relevantes detallados por resultados estadísticos de cada uno de los participantes. lo que permitirá aprovechar mejor las bondades de este sistema operativo. continuando con los sistemas operativos móviles desde sus orígenes y su evolución teniendo énfasis en el sistema operativo Android detallando cada una de sus versiones.inteligente con esta versión de Android. Se evaluarán los productos de software obtenidos por cada grupo. se describe la planificación. la búsqueda del equipo y cada una de las actividades realizadas por ellos. pero también las experiencias adquiridas por cada participante y la dinámica de trabajo de cada grupo.4 Organización de la Tesis Esta tesis tiene la siguiente estructura: En el primer capítulo podemos encontrar una definición de las tesis. sus especificaciones son de las mejores en el mercado de celulares de gama alta. En el tercer capítulo se habla sobre Scrum la metodología utilizada durante el experimento. mostrando cada una de las diferentes perspectivas de la metodología implementada. Para la evaluación del producto final obtenido se aplicarán distintas métricas para cuantificar su calidad y para el resto de los aspectos a estudiar se utilizarán cuestionarios y entrevistas con los participantes. como surgieron y los diferentes tipos que han surgido hasta el momento también se aborda sobre el manifiesto ágil sobre el cual están basadas las metodologías. En cuarto capítulo se encuentra la fase de desarrollo donde se detalla todo el proceso que se realizó durante el experimento. características y cada una de las prácticas que en ella se realizan.

el cual era un estándar.1 Metodologías agiles Las metodologías agiles tienes como las conocemos hoy en día tienen sus orígenes dentro del área de la ingeniería de software. se reunieron 17 grupos de expertos en el área del desarrollo de software. ya se contaba con una noción de los procesos iterativos e incrementales. revisando cada uno de los requisitos 8 . surgieron inicialmente metodologías enfocadas como arquitectos de Extreme Programming. Uno de los objetivos de las metodologías consta de desarrollar una fracción de un software que se desea construir. Durante en una reunión llevada a cabo en el estado de Utah en los Estados Unidos. producto de esta reunión surge el término “agil” implementado para el desarrollo de software. Su objetivo principal fue proyectar los valores y principios los cuales lograrían que los equipos de desarrolladores de software se logren adaptar con facilidad a los diferentes cambien que pudieran legar a surgir durante el proceso de desarrollo logrando la optimización de este. el dueño del producto nos daría a conocer sus opiniones respecto al trabajo realizado. Tiempo atrás a este proceso de evolución de las metodologías se implementaba el modelo de cascada.CAPITULO II MARCO TEÓRICO 2. donde se encontraban también un grupo de personas las cuales crearon e impulsaron las metodologías para el desarrollo de software. así de esta manera. Esta época de progreso en las metodologías se ha considerado como uno de los momentos claves que ayudaron al desarrollo de estas metodologías las cuales ayudaron a los procesos de desarrollo. Anteriormente se contaban con procesos de desarrollo muy poco flexibles los cuales estaban dirigidos por la documentación que se producía en cada una de las actividades.

2 El manifiesto Ágil El manifiesto ágil [Anexo 1] cuenta con valores bien definidos los cuales son la base del desarrollo ágil. A continuación se muestran dichos valores:  Se tiene como prioridad al cliente y las interacciones del equipo de desarrollo. 2. se debe evitar una negociación de sobre los procesos. creando una relación durante el desarrollo con el dueño del producto obteniendo una retroalimentación. también se tiene como objetivo solo realizar el trabajo necesario buscando siempre la simplicidad y el buen diseño. es decir solo cuando se lleguen a tomar decisiones importantes y que estas lo requieran es posible generarlos. ya que es primordial contar con un buen equipo de desarrollo a un buen entorno en el cual trabajar. Durante la planeación muchas personas no consideran al equipo primero y se enfocan en construir el entorno primero esperando que las personas se adapten a este.solicitado para determinar un resultado satisfactorio y no generar pérdidas monetarias al cliente. Esto debe ser todo lo contrario el equipo deben construir su  propio ambiente en el cual desarrollar en cuanto sus necesidades. dejando en segundo lugar el proceso de desarrollo y las herramientas. Con esta implementación se pretende una mejor optimización en los tiempos de entrega dando una entrega continua en tiempos cortos donde se presenta un software funcional. Siempre se debe tener en cuenta el no producir documentos innecesarios. Se debe tener una relación continua con el cliente y el equipo de 9 . La relación con el cliente en fundamental se debe colaborar con el teniendo reuniones e intercambios de ideas. Durante el proceso de desarrollo se encontraran con proyectos donde los diferentes requisitos no están claros del todo o pueden modificarse durante este proceso. las metodologías están diseñadas para adaptarse a estos constantes cambios. Priorizar la entrega de software funcional a obtener una importante documentación. Toma con mayor importancia las personas involucradas durante este proceso. En cuanto a las características de  estos documentos deben ser breves y concisos centrándose en lo importante.

etc. Con el avance de los sistemas operativos y el hardware se generan nuevas formas entorno a la programación. esto puede afectar al resultado de producto. siendo uno de los pioneros en el sistema operativo móvil gracias a esto Palm OS se mantuvo en los principales sistemas operativos dada su simplicidad y su gran utilidad. tiene sus inicios en el año de 1996 con la Palm Pilot. de esta manera se debe tener en cuenta todos estos factores generando una planificación flexible. 2002) fue específicamente diseñado para dispositivos móviles.000 de usuarios registrados en su red de desarrolladores realizando diferentes tipos de proyectos para Palm OS llegando a tener el 80% del mercado estadounidense y el 57% en el mercado del mundo entero. 2.3. gracias a esto en el 2001 Palm OS tenía 100. problemas con las herramientas. creando nuevas aplicaciones que logran aprovechar de mejor manera las capacidades de los dispositivos móviles. Dentro de esta variedad se encuentran diferentes sistemas operativos móviles que han tenido un gran avance en los últimos años. estos son mucho más simples que un sistema operativo para Pc.desarrollo ayudando a la retroalimentación y mejorando el resultado obtenido  siendo más satisfactorio. 2. Dentro de la programación de Paml OS podemos mencionar que las aplicaciones que corren en este sistema operativo son generalmente programas basados eventos de un 10 .1 Sistema Operativo Palm OS El sistema operativo Palm OS (Neil Rhodes. El equipo de desarrollo debe saber adaptarse a los constantes cambios del proyecto.3 Sistemas operativos móviles Al igual que en las PCs los dispositivos móviles utilizan sistemas operativos los cuales permiten administrar la comunicación la comunicación entre el hardware y el usuario. Durante el proceso pueden surgir diferentes cambios y problemas a los cuales se pueden enfrentar ya sean nuevos requisitos. están orientados la comunicación móvil.

2.solo hilo. siendo un sistema operativo de 32 bits ha sido creado para necesidades específicas de los dispositivos móviles de 2G. 2005)fue el resultado de la alianza de varias empresas importantes como lo son Nokia.5 y 3G. o Java. Se debe de elegir con cuidado el lenguaje con que se quiera desarrollar ya que pueden surgir algunas complicaciones. haciendo que los fabricantes de dispositivos móviles puedan diseñar sus sistemas de forma individual. de esta manera para los programadores es más sencillo el aprendizaje de este sistema operativo. 11 . Samsung. La creación de aplicaciones para el sistema operativo Palm OS tienen diferentes lenguajes de programación donde pueden ser desarrolladas como lo son C. Estas aplicaciones estas compiladas en archivos PRC (Palm Resource File) para luego ser descargadas al dispositivo. Visual Basic. LG.3. Symbian OS nos muestra una interfaz de usuario (UI) flexible. En el año de 1997 surgió la versión EPOC32 que luego se convertiría en Symbian OS.2 Sistema operativo Symbian OS Symbian OS (Sales. Estas aplicaciones son compatibles con casi todos los dispositivos que tengan el sistema operativo Palm OS ya que algunos tienen propiedades individuales que pueden codificarse. 2. Sony Ericsson. Tiene sus orígenes en el sistema operativo llamado EPOC32 otro sistema operativo desarrollado para dispositivos. esto quiere de decir que solo una aplicación puede estar ejecutándose a la vez de esta manera si se quiere cerrar solo es necesario ejecutar otra aplicación así Palm OS detendrá la aplicaciones en ejecución y comenzara una nueva. entre otras teniendo un gran éxito en ventas por parte de Nokia. el cual es parte de un conjunto de sistemas operativos que surgieron al final de la década de 1980 y al comienzo de 1990 con el EPOC16. Motorola. C++. El lenguaje más común para desarrollar estas aplicaciones es C como lenguaje de programación y hay otras opciones disponibles que permiten usar frameworks de C++.

hace uso de los recursos de memoria dinámicamente de esta manera poder administrar eficientemente la energía y soportar en tiempo real los protocolos de comunicación y telefonía. 2. siendo lanzado por Bill Gates como apuesta a las plataformas móviles en el año de 1994 lo que se denominaría Windows CE. Piton.3. Algunas otras herramientas para el desarrollo con las cuales podes desarrollar encontramos Microsoft Silverlight una herramienta de tecnología web la cual nos da la opción de crear mediante una estructura flexible que nos permite para crear aplicaciones con funciones multimedia y gráficos vectoriales.3 Windows Mobile (Windows Phone) Windows Mobile (Wildermuth.NET. 2013)pertenece a la familia de Windows CE.4 Iphone OS Sistema operativo (Smyth. A través de los años Windows tuvo una evolución en diferentes dispositivos y ahora con su nueva versión Widows Phone 7 con un gran cambio en su interfaz de usuario. 2.NET Framework. Java. la compañía solamente ha adaptado los frameworks ya existentes encontramos un par de ejemplos. Symbian OS está diseñado para ser un sistema operativo muy ligero. todas ellas basadas en Widows CE.Los desarrolladores pueden utilizar diferentes tipos de lenguajes para desarrollar aplicaciones para este sistema operativo como lo son C++. 2012) móvil que surge con el famoso Iphone de Apple en el año de 2007. . comenzarían a integrarse en el mercado de la telefonía surgiendo el sistema operativo Windows Mobile 2003 Pocket Pc Phone Edition.3. lo que años más tarde se convertiría en la versión PocketPC 2002 siendo un nuevo concepto que tendría como objetivo competir con las PDA’S de Palm. En el área de programación para Windows Phone no ha creado ningún nuevo lenguaje o framework. Como lenguajes para el desarrollo en este sistema operativo podemos encontrar C# y Visual Basic con el . El 12 . trayendo consigo una nueva etapa para los sistemas operativos móviles.

Una de las nuevas funciones en las cuales Iphone Os incursionó en la accesibilidad a aplicaciones las cuales se instalan desde el mismo sistema. Una de las características a destacar de este sistema operativo es la interfaz de usuario y la gran facilidad al utilizarlo siendo muy fluida e intuitiva mediante la utilización de la tecnología Touch Screen la cual ha sido implementada por medio del framework Cocoa Touch. las cuales no dependen de una conexión de internet para poder funcionar aquí es donde radica la diferencia entre estos dos tipos de aplicaciones. Para realizar estas aplicaciones se utiliza xCode en Objetive las cuales son desarrolladas con el SDK del dispositivo. En la parte de desarrollo de aplicaciones para Iphone OS ha tenido mucho éxito gracias a la creación de la AppStore donde la distribución de las aplicaciones es muy buena donde los usuarios pueden o no cobrar por ellas. etc. para lograr esta adaptación Apple removió todas las características del sistema operativo que no eran necesarias para un dispositivo móvil como lo era el Iphone e implementando características que eran propias de la telefonía móvil. gracias a esta flexibilidad brindada por Apple la clave del éxito para la AppStore teniendo una gran respuesta por parte de los usuarios para para desarrollar sus aplicaciones y brindarlas a los demás usuarios algo que no se había hecho antes con tal facilidad y respuesta por parte de los demás sistemas operativos anteriores. En cambio las aplicaciones nativas son aquellas que han sido descargadas de la AppStore para después ser instaladas. siendo esta una de sus más grandes características ya que dichas aplicaciones comprenden diversos usos sacando el mayor provecho al móvil. 13 . PHP. está orientado a objetos. Tenemos que destacar que Objetive C un recurso diferente a Java. el cual es un lenguaje basado en C.Iphone OS fue desarrollado a partir del sistema operativo OS X. cabe destacar que este framework también ha sido desarrollado por la misma Apple. Java. Estas aplicaciones a la vez también son desarrolladas en PHP. Las aplicaciones para Iphone OS pueden ser nativas o webs. NET. ActionScript. NET. La implementación de CSS nos servirá para para dar los detalles finales a nuestra aplicación. con esto nuestra aplicación será ejecutada en el Iphone. estas últimas constan de ser una aplicaciones normales la diferencia radica en que han sido desarrolladas en HTML. etc. CSS y JavaScript. para después escribir el código necesario en HTML. estas aplicaciones son ejecutadas en un servidor y son visualizadas en el navegador de Apple Safari.

0. pocos meses después durante el 2011 saldria el Galaxy Nexus con la versión de Android Icream Sandwich.5 Android SO Android (Burnette. Inc en el 2005 lo que en aquellos años solo representaba una empresa pequeña comparada con Google en el 2003. Lo que Google buscaba era desarrollar un sistema operativo para dispositivos móviles basado en el kernel de Linux donde se pudiera tener una plataforma flexible que contantemente se pudiera actualizar y mejorar. ordenadores portátiles y diferentes dispositivos que ayudan a la internación con estos dispositivos como lo son relojes inteligentes. Google Tv. Este sistema operativo debido a su flexibilidad es utilizado por diferentes empresas en diferentes dispositivos móviles como lo son Smartphone. Durante el inicio de Android la compañía móvil HTC decidió ser la primera en utilizar este sistema operativo en su teléfono HTC Dream. netbooks. Android es el primer sistema operativo de Google en el mercado de la tecnología móvil la cual ya tiene varios años evolucionando constantemente en especial los últimos años con el desarrollo de los Smartphone. tabletas. está basado en Linux pensado su principal razón de desarrollo es la implementación en dispositivos móviles.1. Google decidió colaborar con HTC en el 2010 para desarrollar un nuevo smarthphone lo que dio como resultado Nexus One con la versión de Android 2. Durante ese mismo año Samsung se suma la implementación de Android en sus smarthphones sacando al mercado el Samsung Nexus S con la versión de Android Gingerbread.2. este sistema cuenta con el apoyo de aplicaciones diseñadas con el software middleware. 2008) es uno de los sistemas operativos para móviles más nuevos en el mercado mundial. Actual mente Samsung cuenta con el Samsung Galaxy SIII siendo uno de los smarthphones más potentes del mercado con la versión de Android 4.3. El sistema operativo Android a sido desarrollo por The Open Alience que consta de más de 30 empresas dedicadas al desarrollo tecnológico donde Google es la principal empresa en este proyecto siendo esta ultima la cual adquirió a Android.4 Ice Cream Sandwich donde la 14 . con su salida al mercado en el 22 de octubre de 2008.

1. su diseño muy natural y cómodo como su slogan lo indica “designed for humans”. el cual cuenta con el mayor número de pre-ordenes en la historia de los smarthphones.1 Eclair: Liberado el 26 de octubre de 2009 esta versión de Android ayudo a su popularidad. 1.6 Donud: Es liberado el 15 de septiembre de 2009.1 Banana bread: Es liberado el 9 de febrero de 2009 “todas las aplicaciones son iguales” el SO toma a todas las aplicaciones por igual así se pueden remplazar libremente.interfaz de usuario a sido personalizada por Samsung.0/2. la nueva característica que destaca es la actualización de Android Market. mejorando su diseño haciéndolo más amigable para el usuario y sencillo.5 Cupcake: Liberado de abril de 2009 siendo una nueva actualización con la cual se implementaron nuevas mejoras mejorando la interfaz de usuario mediante la animación de pantallas entre las cuales destaca poder añadir widgets en el escritorio 1. a continuación se describen sus diferentes versiones y características: 1. sistema operativo abierto multi-tarea. Android ha tenido una buena evolución como sistema operativo llegando a tener hacerse de buena parte del mercado en cuanto a dispositivos móviles se refiere. sus diferentes versiones cuentan con numerosas actualizaciones. mejoras y características que lo hacen único. 2. 15 . gracias a esta versión se pudo tener nuestra red social en el dispositivo como Facebook y Twitter.0 Apple pie: Primera versión de Android liberada el 23 de septiembre de 2008. facilita al usuario accesar a las funciones del dispositivo mediante APIs.

2.3 Gingerbread: Lanzada el 6 de diciembre de 2010. una característica importante de esta versión de Android a destacar es la implementación del soporte Near Field Communication. todo el sitema de Android fue optimizado para dar un mayor rendimiento en la vida de la memoria y el desempeño que ofrecía. cuenta con nuevos botones en la interfaz. La gran popularidad que Android ha generado un gran movimiento por parte de los usuarios que desean desarrollar sus propias aplicaciones para este sistema operativo. si se conocen lenguajes como C o C++ entonces no se tendrán problemas al desarrollar en Java ya 16 . 2. Android ha pensado en los usuarios con discapacidad visual.2 Honeycomb: Liberado el 22 de febrero de 2011 la interfaz ha sido mejorada con un nuevo escritorio 3D con widgets rediseñados los cuales ahora cuentan con la característica de redimensionarse de forma manual. los widgets han sido mejorados 4.1 Jelly Bean: En esta nueva versión destaca un nuevo proyecto denominado “Buter” con lo cual se pretende mejorar el sistema operativo mediante el rederizado incrementando la calidad de los graficos en el sistema operativo. ha sido premiada gracias a su gran experiencia de usuario.0 Ice Cream Sandwinch: Esta nueva versión de Android cuenta con una nueva interfaz y nuevas funcionalidades.0 / 3. 4. 3.1 / 3. Jelly Bean permita la entrada externa de braile por medio de plugins.2 Froyo: Fue liberado el 20 de mayo de 2010. la nueva característica del “modo de gesto” la cual permite al usuario navegar de manera confiable atreves del tacto y gestos apoyado por la salida de voz. Para esto se debe de tener un conocimiento básico sobre programación.

La desventaja que se tiene al comenzar a programar en Java para Android es aprender una serie de librerías y componentes que son propios de la plataforma.1 Origen del Problema 17 .que Google lo ha utilizado en muchos de sus proyectos.4. C++ o C# algunas de las opciones con que se cuentan para esto son Mono la cual nos brinda esta opción de desarrollo de aplicaciones aunque la desventaja de este recurso es el costo que tiene al ser de paga. 2. mediante la integración de profesionales y/o estudiantes avanzados que han cursado la licenciatura en sistemas (UNNE) e ingenierías en sistemas de Información (UTN-FRR) actualmente la empresa se encuentra en una etapa del emprendedor creativo en sus inicios. Se puede programar utilizando C.2 Froyo ha te tenido un mayor enfoque hacia esta plataforma de desarrollo mediante el cual logra un mayor poder en su sistema operativo. también nos presenta entornos de desarrollo donde podemos emplear tanto Visual Studio .4 Experiencias previas con la metodología Scrum NoNameSoft (Walter G. Con la implementación de una máquina virtual de Android el código de Mono Android se puede ejecutar en el mismo proceso. Al momento de desarrollar aplicaciones en Android se debe tener en cuenta que está más enfocado a la implementación de Java ya que desde la versión de Android 2. permite desarrollar aplicaciones . esto no representa mucho si se tiene en cuenta la facilidad con que se puede llegar a desarrollar. Surge. donde brinda un servicio de desarrollo de software a esa misma región.0 con C#. una vez creadas las apelaciones pueden corren en otros sistemas operativos sin muchas variantes.NET 4. 2.NET 2010 como MonoDevelop para el desarrollo de aplicaciones. Barrios)es una empresa que se encuentra físicamente en la capital de la provincia de Corrientes en Argentina.

se utilizara una herramienta que sea acorde con el perfil de la empresa y que además se pueda incorporar de forma ágil y flexible con lineamientos y principios de la gerencia para la innovación en su aplicación. se debe de encontrar la manera adecuada para llevar a cabo el proyecto y lograr el éxito en este.2 Justificación de la metodología Como objetivo se tiene fortalecer la gestión operativa de la empresa. el cual fue llevado a cabo por los profesionales de administración de la empresa. Dentro de esto se encuentra el problema de la estimación del presupuesto donde se debe dar una estimación adecuada que esté acorde con los detalles que puedan surgir.4. Éstas representan en la mayoría de los proyectos el 90% de los costos totales. Un factor importante en el desarrollo de software es el trabajo en equipo. Estas son algunas de las ventajas por las cuales se eligió la metodología scrum: • Es simple: Fue fácil trasladar el conocimiento a otros. Gestión de proyectos ineficiente: Este problema se encuentra en el área de desarrollo de software a medida. 2. se pudieron encontrar diferentes problemas y riesgos asociados a estos: 1. Estructura organizacional deficiente: Los fundadores de la empresa cuentan con poca experiencia y/o conocimiento de administración y/o gerencia. que lo comprendan y lo puedan llevar a cabo con mayor facilidad a la práctica. 2. esto quiere decir que los avances del 18 . lo cual si no se tiene una organización en las horas de desarrollo puede recurrir en una perdida grande para la empresa. lo que esto provoca que la empresa se estanque en un cierto nivel de desarrollo de software y crecimiento donde la estructura organizacional no puede permitir un creciente volumen de operación. • Hace hincapié en la visibilidad: Esto es importante para SCRUM que los progresos que se llevan a cabo se puedan ver.Después de un diagnostico organizacional. Durante este proceso de desarrollo se tienen costos de desarrollo lo cual repercute en el costo total. Es necesario un SCRUM Master que el cual llevara a cabo la gestión del equipo que pueda desarrollar su papel el cual es importante para el equipo.

4.3 Implementación de SCRUM Para la implementación de SCRUM consistió de tres epatas las cuales fueron llevadas a cabo después del trabajo de diagnóstico el cual lo realizaron los especialistas en Administración. • Usa roles y normas claras: El SCRUM Master lleva a cabo actividades y flujos de trabajo que ya están definidos explícitamente usando normas claras. 2. Durante el Spring Review el equipo mostrara los avances realizados durante el último Spring es muestra mejor la característica anterior. realizar un seguimiento diario y planificar a corto plazo. tiene como objetivo encontrar los problemas. Se organiza una reunión donde se llevó a cabo la capacitación en la metodología SCRUM. de una manera efectiva ( la cual no puede llegar a durar más allá de 15 minutos). 1. A partir de este punto se puede tomar la decisión de poner en producción lo ya desarrollado para empezar a ver una recuperación de su inversión. Se poden medir los avances en el equipo de trabajo mediante la medición del tiempo de trabajo entre cada Sprints y proyectos que luego facilitan esto ayuda a desarrollar un presupuesto más preciso beneficiando a la empresa. En esta primera etapa el equipo de desarrolladores establecieron las diferentes metodologías aceptando SCRUM para su implementación.proyecto se puedan demostrar y sean funcionales. No tiene protestad sobre el “Que”. De esta manera llegar a optimizar el tiempo • Permite realizar mediciones agiles: Las cuales facilitan la retroalimentación con el equipo de trabajo. siendo esta la más adecuada para fortalecer la gestión de proyectos en la empresa. 19 . • Basado en el compromiso personal: El equipo se compromete a implementar una determinada funcionalidad en un cierto tiempo (por lo general es alrededor de los 15 dias de duración de un Spring). solo sobre el “Cuanto” (cuando podemos hacer en un Sprint) y el “Como” (responsable de la situación técnica)’ • Soluciona los problemas día a día: El Daily SCRUM Meeting ( las reuniones diarias de SCRUM) estas reuniones sirven para .

etc. etc. • SCRUM Master (posición rotativa): Cada miembro se encargó de llevar acabo todos los conceptos aprendidos en la metodología SCRUM.). 3. mensajería instantánea. Durante esta etapa el rol de SCRUM Master no fue asumido en si por ninguna persona del equipo de desarrolladores.4. 2. 20 . 2. Seguimiento del proceso de aplicación de SCRUM en la empresa: este proceso por los facilitadores que estaba constituido por el equipo de administradores. Se creó un servicio web de almacenamiento al que todos tuvieran accesos para llevar a cabo un seguimiento de la documentación del proyecto el cual constaba de planillas de seguimiento de horas de trabajo. De esta forma alcanzar el punto deseado de para los desarrolladores donde se lleva a cabo la implementación de todo lo aprendido en la metodología para luego llevarlo a cabo en un proyecto vigente de la empresa. para luego presentar y dialogar los conceptos de aplicación.4 El proyecto Este proyecto de software fue realizado para una cadena de mueblerías para esto se aplicaron los conceptos previamente establecidos: En teste proyecto se cuentan con diferentes roles: • El dueño del producto (Product Owner): En este caso el dueño del producto se encontraba fuera del área de trabajo asi que se determinó la comunicación via correo electrónico. con el objetivó de que dicho rol sea adoptado por diferentes personas del equipo para su mayor desenvolvimiento en esta metodología.. también se contó con el apoyo de documentación post-planning y los reviews online. Burndown. Skype.SE plantearon los diferentes puntos referentes al Movimiento Ágil en general y en cuanto a la teoría de SCRUM. 4. Aplicaciones de SCRUM a un proyecto vigente: Durante esta parte el equipo de administradores debieron tomar el cargo que facilitadores de SCRUM. esto permitió un mayor aprendizaje por parte del equipo.

Hubo errores durante la planificaciones del primer Sprint esto llevo a una retroalimentación para volver a desarrollar los siguientes. con la cual todas las partes del equipo de desarrolladores estuvieron involucradas. 21 .4. esto demuestra que SCRUM agiliza la gestión de proyectos y optimiza los costos también permite desarrollar software con requerimientos dinámicos. Como meta principal se tuvo comenzar un proceso de formalización de la gestión de proyectos y desarrollar una estructura organizativa dinámica que prepare a la empresa para futuras etapas de crecimiento.• Equipo de desarrollo el cual estaba conformado por los 4 analista-programador: durante todo el proceso de la implementación de SCRUM se tuvo una constante actividad. Gracias a esto hubo un incremento en la experiencia por parte del equipo de desarrollo.5 Conclusiones La unión de actividades entre los licenciandos e ingenieros en sistemas y licenciados en administración logro llevar a cabo la implementación de SCRUM no solo como una práctica lejana en una Pyme y para el desarrollo de software. Durante las primeras reuniones trajeron consigo un aumento en la eficacia de la producción. Durante toda esta implementación de SCRUM se puede decir que ha sido muy positiva. Se llevó a cabo una implementación general y adaptada de todas las prácticas. también como una actividad que ayuda a la estrategia de la Pyme. 2.

diseño y ejecución. El hecho de llevar acabo esta práctica siendo adaptada a la cultura de la empresa y su estructura fue algo muy bien logrado.Algo notable a destacar de esta aplicación de la metodología SCRUM es el notable involucramiento del equipo de desarrollo con el proyecto y las metas fijadas de la empresa. gracias a su flexibilidad esta metodología será incorporada de forma natural. 22 . ya que hubo un gran compromiso y participación de cada miembro en las diferentes partes de la planificación. lo que lleva a la empresa a adoptar totalmente SCRUM para su proyectos a mediano plazo.

de Peter DeGace y Leslie Stahl Hulet.CAPITULO III SCRUM: UNA METODOLOGÍA ÁGIL 3. Una de las características de Scrum es la entrega de porciones incrementales del producto final al término de cada iteración. El artículo describía un equipo de desarrollo de producto que tomaría "un enfoque holístico o rugby Cuando un equipo intenta llegar hasta el final como una unidad. para quien Easel era su primer trabajo de desarrollo fuera de la universidad. que se utilizó por primera vez el rugby "scrum". Los tres serian asignados fundadores del Manifiesto Ágil.1 Scrum Scrum es una metodología ágil en la cual se llevan a cabo una serie de prácticas iterativas cuyo objetivo es que el grupo de desarrolladores trabaje unido. Degrace y Stahl Hulet se vieron influenciados por el famoso artículo de 1986 de Harvard Business Review por Hitoraka Tekeuchi y Nonaka Ikujiro. Sutherland fue sorprendido por las ideas que había encontrado en un libro llamado Problemas perversos. "El Nuevo Juego de Desarrollo de Nuevos Productos". contribuyendo con sus habilidades individuales para la obtención de un software de buena calidad. Scrum es una metodología diseñada para el desarrollo de productos en ambientes complejos en donde se requiere un producto funcional rápidamente. soluciones justas: un catálogo de los paradigmas modernos de ingeniería. vicepresidente de Object Technology en Easel Corporation. quien era un consultor orientado a objetos. cuando Jeff Sutherland. con cambios constantes o con especificaciones ambiguas. El primer equipo de scrum se formó en 1993. El equipo que ayudó a desarrollar la nueva metodología incluyó a Jeff McKenna. de esta manera el cliente puede ir haciendo modificaciones o continuar con el desarrollo del software tal como se tenía previsto originalmente. como metáfora de un nuevo tipo de trabajo en equipo. y John Scumniotales. pasando el balón hacia atrás y hacia adelante" Degrace y Stahl Hulet tomó las ideas que trabajaron en el diseño japonés y la fabricación y empezó a buscar casos 23 . se inspiró para tomar un nuevo enfoque para un proyecto de software crítico.

ya que se basa en lo que ocurre en la cabeza de un desarrollador: "El más simple de todos a la vez. y los inconvenientes fueron la falta de escalabilidad y la dificultad de la transferencia de conocimientos. Sutherland da cuenta detallada de lo que vino después. analista de negocios. desarrollador de software. scrum master y miembros del equipo. 24 . con la esperanza de crear un equipo con los poderes de un multi-cabezas súper programador! Lo llamaron scrum. Un equipo de scrum es probable que necesite todos estos conjuntos de habilidades. diseñador. a partir de la reunión de lanzamiento.análogos en el desarrollo de software. describiendo varias "all-at-once" los sistemas que propusieron fueron superiores a los procesos de cascada lineales. Todos los aspectos del proceso de desarrollo reside en la cabeza de una persona "Los beneficios eran obvios " buena consistencia arquitectónica interna ". 3. probador. sólose reconocen tres papeles distintos: propietario del producto. gerente de producto de lavado de botellas en jefe. Sutherland describió su modelo de una manera mejor.2 Los roles de scrum Los equipos de Scrum incluyen individuos que provienen de muchos ámbitos tradicionales. y puede venir con títulos como: arquitecto. y así sucesivamente. Sutherland y la empresa se puso a diseñar un modelo de desarrollo de software que permitiría a una función de equipo unido como una sola. es un modelo único entregar una aplicación de principio a fin. especialista en documentación.

oficinas.2. e ir directamente a los miembros del equipo en un intento de conseguir sus cosas de forma rápida.3. Es probable que algunos interesados vuelvan a caer en viejos hábitos. mediante la colaboración con 25 .1 El papel de propietario de un producto Un equipo de desarrollo representa una inversión significativa por parte de la empresa. también puede para cambiar la prioridad de los elementos del backlog. Los miembros del equipo pueden aprender a redirigir estas peticiones con réplicas ingeniosamente diplomáticas como: "Esto suena importante. casas. mantener. Hay que pagar salarios. Esto necesariamente significa que el dueño del producto trabajará en estrecha colaboración con las partes interesadas para determinar lo que hay que construir y cuándo. computadoras y software para comprar. mejor de lo que podría obtener de su inversión. solo el propietario del producto está autorizado para solicitar al equipo que trabajo hacer. perfeccionamiento y comunicación de os requisitos. con el fin de ofrecer el máximo valor comercial. También pueden hacerlo indirectamente. El propietario de un producto controla el orden de prioridad de los elementos del backlog del equipo (un documento donde se encuentran todos los requerimientos del producto) En scrum. usted debe llevarlo a nuestro propietario del producto!" El propietario del producto se asegura de que las necesidades de los clientes y usuarios finales son comprendidas por el equipo. La empresa invierte este dinero en el equipo. El dueño del producto puede hacerlo directamente mediante la creación. ya que espera un buen rendimiento.

priorizar los casos de uso por su valor del negocio. así como la magnitud de la tarea. Esto significa que el propietario del producto stará disponible para el equipo. Se tiene registro que equipos que han trabajado de esta manera han fracasado. Es decir. guiando al equipo a niveles altos de cohesión.profesionales de la experiencia de usuario. también sirven tener al propietario del producto en el equipo. en realidad está dirigiendo el proyecto y es el responsable por el valor de negocio que se entrega”. En cualquier caso. con el fin de alinear las muchas preguntas que surgirán durante el sprint (el ciclo de proceso donde se lleva acabo el trabajo). 26 . Esta visión abarca el producto que se está construyendo. para qué se necesita y cómo se va a utilizar Debido a esta tensión. analistas de negocios y expertos en la materia. 3. es importante que el propietario del producto sea un miembro del equipo. decidir cuáles historias de usuario se desarrollarán después. El dueño del producto es el guardián de la visión del producto.2 El papel del Scrum Master El scrum master actúa como un entrenador. es responsabilidad del usuario del producto para asegurarse de que los requisitos están disponibles y entendido por el equipo. la auto-organización y desempeño.2. generalmente no funciona solo tener un desarrollador que trabaje. Simon Baker entrenador ágil elegantemente describe el papel del dueño del producto: "Tienes que reconocer que a través de sus acciones: escribir las historias de usuario y pruebas de aceptación. proporcionar una rápida retroalimentación. Si bien se puede dar una lista de los integrantes del equipo es el equipo mismo el que se auto organiza. Hemos visto algunos ejemplos de equipos que tratan de tener una persona sirviendo como scrum master y el propietario del producto.

un buen scrum master fomenta esta situación y adapta constantemente su estilo a las necesidades para hacer de su enseñanza más bien un direccionamiento. es posible que. El scrum master no es el jefe del equipo. árbitro y abogado. Esto puede deberse a que el scrum master aumenta el rendimiento de todo el equipo. Algunas organizaciones sienten que están siendo más eficientes mediante el uso de contribuyente-scrum master. Ciertamente. La función del scrum master es "mantener el espacio" del equipo mientras vigila de cerca los procesos y avances.El scrum master es buen pastor del equipo. Los impedimentos son cosas que ralentizan el equipo y los problemas vienen en todas 27 . pero esto es estrictamente a través de la influencia. guiar a los otros miembros del equipo (incluido el dueño del producto) a una mejor comprensión de sus roles en el equipo. ya no necesite al scrum master para realizar las reuniones. entre ellas: facilitar las reuniones scrum. no posee una autoridad o "posición de poder". El scrum master es el experto del equipo que ayuda a obtener el máximo valor posible de esta metodología realizando muchas funciones. el scrum master aporta un tipo de liderazgo al equipo. Como el equipo se vuelve de alto rendimiento y más de auto-gestión. facilitador y experto scrum. Vemos muy pocos equipos que se desempeñan tan bien que no pueden beneficiarse de un entrenador a tiempo completo como lo es el scrum master. ayudar al equipo a entender y usar los artefactos de scrum. en un determinado momento. En muchos casos la autoridad en la metodología con que cuenta le dificulta ganarse la clase de intimidad y el acceso necesario para ser un asesor de confianza. Esta es una posición igual en el equipo y tiene responsabilidades diferentes. tutor. Otra función clave del scrum master es eliminar los obstáculos para el equipo. El Scrum master debe evitar convertirse en un "policía" y regañar al equipo por aplicar mal la metodología.

A veces.2. como el código. Tal vez el disco duro de un miembro del equipo se ha estrellado. sino que también son auto-organizables. o incluso instalar una unidad de disco duro de repuesto. Es posible que un scrum master tenga deberes que también contribuyan al proceso de desarrollo facilitándolo. El propietario de producto elige el orden de las historias de usuario. A menudo durante el daily scrum: tal vez un miembro del equipo está bloqueado en espera de que los administradores de bases de datos aprueben un cambio. Los miembros del equipo tienen autoridad total sobre cómo se hace el trabajo. y cuales miembros del equipo trabajaran en cada tarea. Si el equipo está perdiendo el tiempo rellenando informes sin sentido. el scrum master trabajará con la administración para eliminar esta carga. un scrum master debe poner las necesidades y el éxito del equipo por encima de su propia voluntad de contribuir directamente. 3.3 El papel de los miembros del equipo Los equipos de Scrum no solamente son altamente colaborativos. un maestro colaborador-scrum es probable que se centre en conseguir sus propios aportes. y alienta al equipo para encontrar una solución. La teoría es que las personas que hacen el trabajo son las más altas autoridades sobre la mejor forma de hacerlo. Para ser exitoso. y las fechas límite se avecinan. 28 . Sin embargo. el scrum master puede ayudar a conseguir un nuevo equipo. Cuando las cosas se ponen difíciles. por ejemplo. El equipo es el que decide qué herramientas y técnicas se van a utilizar. éste es el momento en que su equipo más necesita de él. el scrum master puede escalar el problema para que lo resuelva. pero solo los desarrolladores pueden decir que tantos son los compromisos que el equipo adquiere en cada entrega. el impedimento es interno al equipo: quizás su falta de pruebas está desacelerando el abajo. El scrum master trabaja para ayudar al equipo a ver el problema. Esto es mucho pedir para alguien que disfruta de su trabajo técnico. Los miembros del equipo hacen la implementación del trabajo y también están a cargo de estimar cuanto trabajo tienen que hacer e implementar.formas y tamaños.

estas áreas individuales no deben ser entendidas como limitaciones que restrinjan el tipo de contribuciones que un miembro del equipo puede realizar. 29 . Durante la segunda parte de la reunión. Cada miembro del equipo aporta habilidades y experiencia diferentes para el equipo.3 El Sprint El Sprint es el ciclo fundamental del proceso de scrum. la sobrecarga de comunicación puede volverse excesiva. la regla común es de siete.En cuanto al número de integrantes en un equipo Scrum.1 Reunión de planificación de Sprint La planificación del Sprint marca el comienzo del sprint. Este criterio es sólo una guía. Estas fortalezas ayudarán al equipo a hacer su trabajo y a concretar las historias de usuario. Si son menos. 3. el equipo identifica las tareas que se deben completar para poder realizar una entrega concordante con las historias de usuario. cuatro semanas es generalmente considerada la máxima duración. consiste en un proceso en el que se desarrollan pequeños trozos del proyecto que se concluirán antes de comenzar con otro sprint. El objetivo de la primera parte es para que el equipo se comprometa a un conjunto de entregas para el sprint. Sin embargo. es un enfoque iterativo para conseguir hacer el trabajo. Las metodologías ágiles comparten una cosa en común. Comúnmente. pero el concepto no es exclusivo de scrum. ciclo o iteración. Si son más de siete. quizá el equipo no tendrá la suficiente variedad de habilidades para hacer todo el trabajo necesario para completar las historias de usuario.3. Un sprint puede ser llamado también Periodo de desarrollo. La longitud más popular de un sprint es entre una y dos semanas. ya que existen reportes de equipos exitosos con más y menos de siete integrantes. esta reunión tiene dos partes. 3.

A continuación. y revisan los criterios de aceptación para asegurarse de que tengan un entendimiento común de lo que se esperaba.1 Primera parte: "¿Qué vamos a hacer?" El objetivo de la primera parte de la reunión de planificación de Sprint es salir con un conjunto de "compromisos". hasta que el equipo siente que no puede comprometerse a trabajar más. los miembros del equipo deciden si pueden comprometer con la historia. el dueño del producto presenta las historias que le gustaría que el equipo completara en el sprint. pero los miembros del equipo que hacen el trabajo real son los que deciden la cantidad de trabajo que puede asumir.El dueño del producto conduce esta parte de la reunión. historias que todo el equipo cree que puede entregar al final del sprint .Se recomienda tener una o dos horas de planificación de Sprint por semana de desarrollo.1. Los miembros del equipo discuten cada historia con el dueño del producto.3. mientras que un sprint de cuatro semanas puede ser planificada en cuatro horas. 30 . Los miembros del equipo consultarán con otras dependencias con respecto a cada uno. por lo que una reunión de dos horas es adecuada para un sprint de una semana. Uno por uno. 3. Este proceso se repite para cada historia. y en general hablarán de lo que se requiere para aplicar la historia. Se debe tener en cuenta la separación de la autoridad: el dueño del producto decide qué historias serán consideradas. en orden de prioridad.

Este enfoque es. Los equipos que luchan varias veces con el exceso de compromisos pueden optar por utilizar una técnica llamada " yesterday`s wheater. es decir. ejecutar los scripts de liberación. La meta es un conjunto de historias que todo el equipo realmente cree que completará en el sprint.. Cuando se trabajó con equipos que no sufren el síndrome de sobreasignación. En estos casos.2 Parte 2: "¿Cómo vamos a hacerlo?" Se debe recordar que las historias son entregables: cosas que nuestros grupos de interés. Con el fin de ofrecer una historia. se recomienda utilizar la velocidad como una guía. 3. escribir texto de ayuda. el diseño de una nueva pantalla. las estadísticas de la cantidad de trabajo realizadas por el equipo en el pasado puede servir como base para realizar una estimación de la cantidad de trabajo a la que el equipo se puede comprometer en el presente sprint. hacer pruebas de caja negra de la nueva característica.3.Muchos equipos nuevos tienden a sobre comprometerse.1. los usuarios y los clientes quieren. obtener el elemento de menú traducido a otros idiomas. para evitar que el número de tareas conlleve a fallos del equipo. añadir nuevas columnas a la base de datos. de auto-corrección. 31 . naturalmente." Cuando se utiliza esta técnica el equipo se compromete a realizar exactamente la misma cantidad de tareas. las tareas son cosas como: obtener información adicional de los usuarios. los miembros del equipo tendrán que completar las tareas. en el sprint anterior.

se lleva a cabo diariamente. Dentro de esta reunión existen tres tipos:  Chica: Solamente los miembros de desarrollo participan. el equipo va a negociar con el dueño del producto para quitar o agregar historias. Esta reunión puede ser adaptada a las preferencias del equipo de desarrollo. El objetivo es encontrar un horario regular con el cual comenzar la reunión. Objetiva: Cada uno de los participantes comparte: Que fue completado desde el último daily scrum Que espera completar para el siguiente daily scrum Que obstáculos están impidiendo mi trabajo 32 . ya que durante el proceso de identificación de las tareas del equipo se dan cuenta que se han inscrito en las historias de más o de menos. las nuevas tareas simplemente se registran y se añade a la lista de tareas para el sprint. Mientras que el equipo hace el mejor esfuerzo para identificar todas las tareas necesarias. Si esto sucede. El equipo también puede necesitar ajustar la lista de historias que se comprometen a realizar. como mucho las  personas que se sientan cómodas dentro del círculo. El daily scrum no  debe de durar más de 15 minutos.4 Daily Scrum El daily scrum es a veces llamada reunión de pie. Breve: Durante esta reunión no se planea solucionar grandes problemas. Cuando esto sucede. Una vez que el trabajo real comienza. se debe recordar que es importante que sólo el equipo tratara con el dueño del producto para quitar o agregar historias. La mayoría de los equipos decides realizar esta reunión al comienzo de un día de trabajo. nuevas tareas saldrán a la luz. pero se mantiene una línea de comunicación abierta para escucharlos. no es realista pensar que la lista generada será completada. Un equipo de alto desempeño puede esperar identificar el 60% el 70% de las tareas durante la reunión de planificación del sprint. 3.El dueño del producto debería estar disponible durante este proceso para responder a las preguntas.

El objetivo de esta reunión es simple. La retrospectiva se lleva a cabo al final de cada sprint. También se muestran las tareas que no se realizaron y las tereas que se lograron completar. Este tambien es un buen momento para reunirse con el dueño del producto y los miembros del equipo para tomar nota de las reacciones que se tuvieron de las pruebas del trabajo entregado. y crear un plan que permita implementar esos cambios. 3. Se debe de asegurar que al llevarse a cabo esta reunión se tiene un producto funcional que mostrar a las partes interesadas. Se recomienda de una hora a dos horas por cada semana de desarrollo. es un tiempo dedicado por el equipo para enfocarse en lo aprendido durante el sprint y como ese aprendizaje puede ser utilizado para mejorar el rendimiento. Esta reunión también es llamada comúnmente como sprint demo.6 Retrospectiva Scrum está diseñado para ayudar a los equipos constantemente inspeccionándolos y adaptándolos. resultando en un mejoramiento en el rendimiento y la felicidad. de esta manera esta reunión debe ser una forma de aprendizaje de todas las partes involucradas en el proceso de desarrollo. Para a duración de esta reunión se recomienda una hora y media por cada semana de desarrollo. identificar una o dos cosas que puedan ser mejoradas. 33 .3.5 Revisión del Sprint Al final de cada sprint el equipo de desarrollo tiene la oportunidad de mostrar el trabajo completado durante el sprint esto se lleva a cabo en la reunión de revisión del sprint.

Durante toda la fase del experimento se mantuvo una medición de diferentes factores los cuales nos permitirían medir el grado de aceptación de la metodología. y luego. Se aplicará a cada integrante después del desarrollo del proyecto Lo contestarán los facilitadores que estarán a cargo de la explicación de cada metodología. al final del desarrollo final del proyecto.CAPITULO IV CASO DE ESTUDIO 4. Factores a medir durante el experimento 34 Detalles Se aplicará el mismo cuestionario dos veces. la aplicación se desarrollaría para el sistema operativo Android para ello se utilizó el lenguaje de programación Java con el entorno de desarrollo Eclipse. Percepción de los participantes sobre la organización del equipo y manera de trabajar Percepción de los facilitadores Cuestionario aplicado a los participantes después del desarrollo experimental Cuestionario aplicado a los investigadores que estarán presentes con cada equipo. Tabla I. . la cual pretendía ayudar a ejercitar el razonamiento matemático al practicar las operaciones aritméticas fundamentales a aprender matemáticas.1 Descripción Se buscó reunir un grupo de alumnos con los conocimientos necesarios en programación con el fin de realizar una aplicación móvil con fines didácticos. Primero antes de iniciar la capacitación. el producto obtenido aplicando una metodología ágil entre otros factores descritos a continuación: TABLA I ¿Qué se desea medir? Percepción de los participantes acerca de las prácticas de las metodologías ágiles ¿Cómo se medirá? Cuestionario aplicado a los participantes acerca de los principios ágiles antes y después del desarrollo experimental. la clave de este experimento fue la implementación de la metodología ágil Scrum.

este curso tuvo una duración de doce horas donde se enseñó cómo crear aplicaciones con diferentes funcionalidades que satisfacían diferentes necesidades. donde habría una persona aplicaría la metodología (Scrum master) y otra ajena al equipo de desarrollo tomo el papel del cliente. Toda la fase del experimento se Una vez contando con un grupo de desarrolladores se aplicó un curso previo en programación utilizando las herramientas que se utilizarían durante el desarrollo del experimento en este caso Java con el entorno Java.Se llevó a cabo una convocatoria donde estudiantes de la licenciatura en informática y de ingeniería en sistemas computacionales contaran con los conocimientos necesarios en el desarrollo de aplicaciones móviles y de programación en Java o C. Al término de este curso se llevaron a cabo una sesión de presentación de la metodología Scrum donde se mostraron sus diferentes rasgos y el papel que cada integrante del grupo de desarrollo tendría durante la fase de desarrollo. se buscan un nivel intermedio ya que se contaba con un tiempo corto de desarrollo para poder trabajar dando así una mejor adaptación al trabajo a realizar. se concluyó con una sesión de preguntas y respuestas la cual sirvió para despejar dudas. TABLA II 35 .

Lista de preguntas para la evaluación de la metodología. Tuvimos problemas para organizarnos Se nos dificultó tomar decisiones Todos los integrantes tuvimos una buena relación durante el desarrollo Tuvimos problemas causados por la relación entre los integrantes del equipo La comunicación entre los integrantes del proyecto fue deficiente Percepción de la Metodología utilizada general La metodología favoreció la participación de todos La metodología utilizada contribuyó a la obtención rápida de un programa final de calidad La metodología utilizada favorece sin duda el desarrollo rápido de aplicaciones móviles El desarrollo de software en general se puede beneficiar con las metodologías agiles Percepción personal Durante el desarrollo me mantuve motivado todo el tiempo Creo que hicimos un proyecto de buena calidad Aprendí cosas nuevas en el desarrollo de este proyecto Estoy motivado a seguir aprendiendo más sobre esta metodología En el futuro buscaré aplicar esta metodología a otros proyectos Tabla II. Percepción personal de las actividades de desarrollo experimental Entendí perfectamente la metodología que utilizamos Entendí perfectamente los requerimientos del proyecto solicitado Al introducir cambios en los requerimientos. sentí que habría que hacer mucho re-trabajo a nuestro proyecto Preferiría que no cambiaran Me desmotiva que el trabajo realizado se tenga que modificar a petición del cliente Tabla III. Criterio Evaluación cuantitativa de Scrum Comunicación entre los integrantes del equipo Motivación de los integrantes del equipo Organización para trabajar Eficiencia general de la metodología Actividades de la ingeniería del software Le dimos más importancia a la programación que a otras actividades En todo momento nos enfocamos en producir un programa que fuera funcional Realizamos actividades para entender bien el problema Hicimos un diseño de la aplicación antes de programar Nuestro diseño inicial se modificó conforme avanzamos en el proceso de desarrollo. En una escala del 0 al 4 ¿cómo calificaría los siguientes aspectos de la metodología de desarrollo que utilizó su equipo? (0 es la mínima puntuación y 4 la máxima). Lista de preguntas para la evaluación de la metodología TABLA III.Dinámica del equipo de trabajo En el desarrollo todos participamos activamente. 36 .

El grupo de desarrollo comento los sobre los requerimientos de la aplicación entablando una sesión de preguntas y respuestas que ayudo a la comprensión de la aplicación solicitada. esta aplicación debía ser utilizada por niños de primaria que los ayudaría a prender sobre matemáticas con juegos simples y una interfaz amigable. 4) Facilidad de entenderla Facilidad de implementarla Facilidad de adaptarla Comunicación entre los integrantes del equipo Motivación de los integrantes del equipo Eficiencia general de la metodología Organización de los integrantes Tabla IV. resta o multiplicación 37 . REQUERIMIENTOS ESPECIFICOS Deberá tener 2 niveles de dificultad: principiante y avanzado. 2 . se muestra a continuación: TABLA V. una de tres modalidades: suma.2 Presentación Al comienzo el cliente del producto se reunió con el grupo de desarrolladores para presentar la propuesta de una aplicación la cual debía cumplir con ciertos requisitos. Aspecto a evaluar Calificación (0. 1. El nivel principiante generará números entre 1 y 200 El nivel avanzado generará números entre 1 y 1000 El usuario podrá seleccionar para cada problema. 4.TABLA IV.3 . Para ayudar a medir este experimento el cliente del producto contaba con una lista de requerimientos la cual nunca se mostró a los desarrolladores y fue utilizada para medir el producto resultante. Lista de preguntas para evaluar la metodología.

La aplicación llevará cuenta de los aciertos La aplicación llevará cuenta de los errores La aplicación debe permitir al usuario la posibilidad de rendirse ante el problema planteado. a las cuales el usuario deberá contestar. Nota: Iniciar un nuevo juego significa empezar de cero y limpiar los valores actuales para los aciertos y los errores. la aplicación deberá mostrar el resultado correcto de la operación actual. Al realizar un acierto. 4. Si el usuario se rinde. la aplicación deberá informar al usuario que hizo un acierto. Al cometer un error.3 Product Backlog Una vez acordado los requerimientos que debía cumplir la aplicación a desarrollar el equipo empezó a desarrollar el product blacklog acordando las descripciones de los requerimientos. la aplicación deberá informar al usuario que cometió un error y que debe intentar nuevamente.La aplicación deberá generar siempre operaciones de dos números con la modalidad seleccionada. La aplicación deberá proporcionar al usuario información breve acerca del nombre del equipo que la programó y la fecha de desarrollo. La aplicación deberá validar las entradas vacías por parte del usuario. Requerimientos para el proyecto final Los requisitos cambiantes de dieron a conocer una vez ya comenzada la fase de desarrollo. se priorizaron cada uno de ellos para dar un orden a realizar. estos consistían en agregar dos nuevos puntos. Si el usuario contesta correctamente. con eso se pudo estimar el tiempo que tomaría realizar cada una de ellas y dar paso al sprint plannig meting. El primero consistía en agregar dos pantallas de interacción con el usuario. en el segundo se mostrarán con detalles los nombres de los desarrolladores de la aplicación. la aplicación emitirá un sonido distintivo de error. a continuación se muestra el product backlog creado por los integrantes del equipo de desarrollo: TABLA VI ID Descripción 38 . La aplicación deberá permitir al usuario la posibilidad de comenzar un nuevo juego en cualquier momento. La aplicación deberá tener una sola pantalla de interacción con el usuario. la aplicación emitirá un sonido distintivo de acierto. Si el usuario contesta incorrectamente. Tabla V.

también se comentó que tenían pensado hacer al día siguiente. diseño gráfico de la aplicación. 4.5 Daily Scrum Durante esta corta reunión un poco más casual que la anterior el equipo de desarrollo y el scrum master se reunieron de pie para platicar sobre las cosas que realizaría cada uno como lo realizaría. diagramas de actividades. 39 . si creían que llegarían a tener algún problema y como pensaban solucionarlo siendo ayudados por el scrum master.4 Sprint planning meeting En esta reunión se dividió en dos partes.1 2 3 4 5 6 7 8 9 10 11 Diagrama de flujo Prueba de escritorio Diseño gráfico de la aplicación Diagrama de actividades Codificarlo Pruebas Niveles 4 operaciones básicas Contador de tiempo Contador de errores Cambiar de operación 12 Sonido al aceptar Tabla VI. Product Backlog 4. prueba de escritorio. Durante la segunda parte el equipo se auto-organizo para decidir quién haría cada una de las actividades comprometiéndose a completarlas al final del sprint. en la primera el equipo se comprometió a realizar las actividades que consideraron más prioritarias para el primer sprint: diagrama de flujo.

El equipo se dividió en tres equipos. se utilizaron imágenes con un sentido caricaturesco e integrando el logo de Android.6 Primer Sprint En esta parte del experimento se comenzó a trabajar en los requerimientos de la aplicación. se optó por tener una interfaz de usuario amigable ya que sería utilizada por niños. se implementó una lógica sencilla donde el usuario elegiría entre diferentes modalidades de dificultad. Comienzo de la fase de desarrollo El segundo equipo conformado por dos integrantes comenzó con el diseño gráfico de la aplicación. uno de ellos comenzó con el diseño del diagrama del flujo con el cual se daría comienzo a crear el funcionamiento de la aplicación. este sprint tuvo una duración de 8 horas. resta y multiplicación). 40 . una vez elegida la dificultad se podría elegir entre 3 diferentes tipos de operaciones matemáticas (suma.4. Fig. 1.

Fig. 2. Continuando con la codificación se realizó una pantalla donde el usuario seleccionaría 41 .Fig. Diseño gráfico de la aplicación. Mientras los dos equipos continuaban con cada una de sus tareas 2 integrantes comenzaron con la codificación de la aplicación. Con respecto a esta integración se puede decir que fue satisfactoria ayudo a el rápido progreso y el desarrollo de relaciones entre los integrantes del equipo mostrando como resultado una mejor respuesta ante los retos de este desarrollo experimental. 3. los equipos de diseño y programación trabajaron en conjunto para decir la cantidad de botones que contendría la aplicación así como las diferentes pantallas que presentaría cada una de las operaciones. Codificación de la aplicación.

todas las tareas programadas para el sprint fueron cumplidas. el equipo tuvo problemas con la parte de codificación eso llevo a que el sprint durara un tiempo mayor al pensado. donde se comentó cada uno de los detalles del desarrollo.7 Sprint Review Una vez finalizado el primer sprint se comenzó con la reunión de sprint review. una vez realizada a operación en esa misma pantalla se mostraría si el usuario había realizado correctamente o incorrectamente la operación . se llegó a una solución permitiendo tener una aplicación funcional lista para presentar al cliente del producto. 4. resta y multiplicación). en cuanto el tiempo de entrega para el primer sprint el equipo se propuso entregar un demo del producto esperando ser aceptado o  recibir cambios. el equipo colaboro entre si buscando información en internet para determinar que lo ocasionaba. se revisaron cada una de las funciones las cuales funcionaban correctamente 42 . Se presentó el trabajo completado al cliente del producto donde se mostraron cada una de las especificaciones requeridas.el nivel de dificultad y la selección de operaciones que desearía realizar (suma. al final de este sprint se presentaron un error en el código el cual ocasionó una mayor duración de esta fase. con esto se dio por terminado el primer sprint. Durante esta reunión se revisaron ciertos puntos:  Se revisó el trabajo que fue completado.

el equipo mostro un mayor animo durante esta reunión el equipo apoyándose mutuamente y dialogando sobre las actividades realizadas y por hacer. 4. se creó una nueva pantalla que mostraría información sobre a aplicación creada. un nuevo modo de dificultad fue agregado. se expusieron ideas donde los integrantes mostraron una aceptación de la metodología e integración del equipo durante las actividades realizadas. el equipo identifico rápidamente los nuevos cambios solicitados por el cliente. 4. también fue modificada del diseño gráfico de la 43 . 4. comentaron las dificultadas por las cuales pasaron durante la fase de la codificación demostrando una nueva experiencia donde se adquirió un conocimiento nuevo el cual fue obtenido de sus errores y la solución de estos. El cliente del producto mostro su punto de vista en cuanto a los resultados mostrados y decidió hacer cambios agregando dos pantallas de interacción con el usuario y un nuevo nivel de dificultad (intermedio). se comentó sobre la parte de codificación donde surgieron diferentes problemas los cuales se pretendía solucionar ese mismo día.9 Segundo Daily Scrum Esta reunión se llevó a cabo durante el segundo día de desarrollo el equipo comento sobre el desarrollo del día anterior platicando sobre los diferentes actividades realizadas.10 Segundo Sprint La duración de este sprint fue relativamente corta de una hora a comparación del primer sprint.8 Sprint Retrospective En esta reunión cada uno de los miembros dejo su impresión del trabajo realizado durante el primer sprint.

11 Segundo SPrint Review Durante este segundo sprint review el grupo de desarrollo. llegaron 44 . intercambiaron sus diferentes experiencias durante este último sprint y durante todo el proceso de desarrollo. El cliente reviso y probó la funcionalidad de la nueva aplicación realizando operaciones sencillas y revisando cada una las funciones solicitas. cajas de texto y botones para un más fácil acceso a la información. 4. Fig. una vez finalizada esta parte. Integración de nuevos cambios en la aplicación. el scrum master y el cliente se reunieron para revisar los nuevos cambios de la aplicación. 4.12 Segundo Sprint Retrospective Esta segunda reunión el equipo satisfecho con su trabajo final. el cliente se mostró satisfecho determinando la aplicación terminada. mostraron sus diferentes puntos de vista sobre como lograron sacar adelante las diferentes dificultades por las cuales se enfrentaron. 4.aplicación ajustando las imágenes.

Fig.a un acuerdo donde se demostró que el equipo tuvo una mayor integración al final de este sprint. esto mediante la auto organización de equipo durante la fase de desarrollo donde ellos mismos formaron equipos para desarrollar cada una de las tareas propuestas. la rotación de integrantes de estos equipos logro una mayor agilidad a la hora de solucionar problemas. 4.1 Resultados obtenidos 45 . Entrega de la aplicación completada al cliente. esto se llevó a cabo gracias a la metodología aplicada. donde cada se adaptó a de acuerdo a sus habilidades. CAPITULO V 5.13 Entrega del producto Esta etapa final del experimento se llevó a cabo dentro del tiempo establecido. todos los integrantes del equipo de desarrollo presentaron la aplicación terminada cumpliendo con todas las especificaciones requerías por el cliente. La aplicación fue probada por una persona ajena al equipo de desarrollo y al cliente que probó la funcionabilidad de la aplicación dando su opinión y puntos de vista. 5.

A pesar de esto.1 Perspectiva de los participantes Los datos estadísticos que se obtuvieron de este caso de estudio se muestran en la Tabla IV. Las ventajas de Scrum que fueron identificadas por los participantes incluyen: participación conjunta en un mismo proyecto. También todos coincidieron en estar motivados a diferentes niveles para seguir aprendiendo más sobre la metodología Scrum y en percibir que el software resultante era de buena calidad. buena división de la carga de trabajo. Los aspectos evaluados con puntuaciones más bajas fueron la organización para trabajar y la eficiencia general de la metodología. En cuanto a la evaluación cuantitativa de Scrum. favoreció la participación de todos. seguido de la comunicación entre los integrantes del equipo. integración del equipo con una manera ágil de trabajar. ayuda mutua. Los integrantes del equipo de desarrollo destacan que tuvieron una buena relación entre ellos y que hubo un buen nivel de participación activa de todos. estos conflictos no llegaron a representar problemas graves en la relación del equipo ni afectaron la comunicación entre los participantes.5. A pesar de que reportaron haber tenido algunas dificultades para tomar decisiones en grupo y para organizarse conjuntamente. Todos los participantes aceptaron haber aprendido cosas nuevas en este desarrollo experimental al mismo tiempo que se mantuvieron motivados durante el proceso. rapidez para terminar el proyecto. algunos participantes se mantuvieron en una opinión neutral al preguntarles si aplicarían esta metodología a otros proyectos en el futuro. desarrollo simultáneo de varias 46 . participación activa y eficiente en el área de fortaleza de cada persona. buena organización y relación con el resto del equipo. Todo el equipo coincidió por unanimidad que Scrum favorece el desarrollo rápido de aplicaciones móviles.1. La mayoría de los participantes concordaron en que la implementación de las metodologías puedes beneficiar a la obtención de resultados en el desarrollo de software en general. el aspecto mejor evaluado fue la motivación para trabajar. También de acuerdo a su percepción. la metodología contribuyó a la obtención rápida de un software de buena calidad y en un menor nivel.

dificultades en la toma de decisiones. Esto se demostró con la aceptación de los cambios continuando con la motivación que ya se tenía durante el desarrollo. inconvenientes con el entorno de desarrollo y con algunos aspectos avanzados de la sintaxis del lenguaje utilizado. Los principales problemas o desventajas que los participantes encontraron en este desarrollo de software en particular fueron: diferentes niveles de habilidades y conocimientos. la manera de socializar entre el equipo. el equipo se mostró neutral en cuanto a la realización de actividades para entenderlos. la mayoría considero que no se tendría que volver a hacer un re-trabajo. El equipo mostró un buen entendimiento de la metodología implementada durante todo el desarrollo.actividades. Cabe destacar que el equipo mostró opiniones divididas al aceptar lo cambios solicitados por el dueño del producto. Durante este proceso el equipo estuvo de acuerdo en modificar el diseño original mostrando una adaptación a los problemas surgidos. Durante la fase de programación los participantes consideraron que el enfoque fue múltiple realizando diferentes actividades durante esta parte del desarrollo. Tabla VII. Durante el encuentro con el dueño del producto hubo un claro entendimiento de las necesidades del cliente ayudando a identificar cada una las características que contendría la aplicación. El equipo de desarrollo durante esta fase se mantuvo enfocado en cumplir el objetivo principal del primer sprint el cuan consistía en entregar un programa funcional para mostrar al dueño del producto. Durante el primer sprint se encontraron con problemas. Al comienzo de la programación el equipo se mostró neutral en cuanto a la realización de un diseño de la aplicación. poca paciencia de algunos integrantes. 47 .

63 .535 Se nos dificultó tomar decisiones 8 1 3 1.75 .744 Todos los integrantes tuvimos una buena relación durante el desarrollo 8 3 4 3.63 .75 .835 3 4 3.518 4 4 4 0 3 4 3.354 Tuvimos problemas causados por la relación entre los integrantes del equipo 8 0 2 .518 3 4 3.88 .63 .88 .744 Tabla VII.463 3 4 3.916 La comunicación entre los integrantes del proyecto fue deficiente 8 0 2 .38 .354 Criterio Dinámica del equipo de trabajo Percepción de la Metodología utilizada general La metodología favoreció la participación de todos 8 La metodología utilizada contribuyó a la obtención rápida de un programa final de calidad 8 La metodología utilizada favorece sin duda el desarrollo rápido de aplicaciones móviles 8 El desarrollo de software en general se puede beneficiar con las metodologías agiles 8 Percepción personal Durante el desarrollo me mantuve motivado todo el tiempo 8 Creo que hicimos un proyecto de buena calidad 8 3 4 3. 8 2 4 3.88 .50 .463 En el futuro buscaré aplicar esta metodología a otros proyectos 8 2 4 3.354 Estoy motivado a seguir aprendiendo más sobre esta metodología 8 3 4 3.88 . Resultados obtenidos: perspectiva de los participantes TABLA VIII 48 .63 .N Evaluación Mínima Evaluación Máxima Media Desviación En el desarrollo todos participamos activamente.38 .518 Aprendí cosas nuevas en el desarrollo de este proyecto 8 3 4 3.744 Tuvimos problemas para organizarnos 8 1 2 1.63 .

25 .50 .63 1.389 Le dimos más importancia a la programación que a otras actividades 8 0 4 1.744 Organización para trabajar 8 2 4 3.75 .463 Entendí perfectamente los requerimientos del proyecto solicitado 8 3 4 3.408 Actividades de la ingeniería del software Percepción personal de las actividades de desarrollo experimental Entendí perfectamente la metodología que utilizamos 8 3 4 3.25 1.75 1.Criterio N Evaluación Mínima Evaluación Máxima Media Desviación 2 4 3.756 Evaluación cuantitativa de Scrum Comunicación entre los integrantes del equipo 8 Motivación de los integrantes del equipo 8 2 4 3.13 1.165 En todo momento nos enfocamos en producir un programa que fuera funcional 8 3 4 3. Resultados obtenidos: perspectiva de los participantes.75 .642 Preferiría que no cambiaran 8 1 4 2.886 Me desmotiva que el trabajo realizado se tenga que modificar a petición del cliente 8 0 2 1.061 Nuestro diseño inicial se modificó conforme avanzamos en el proceso de desarrollo.25 .88 . 8 0 4 3.38 1.63 .756 Tabla VIII.88 .354 Al introducir cambios en los requerimientos.707 Hicimos un diseño de la aplicación antes de programar 8 1 4 3. sentí que habría que hacer mucho re-trabajo a nuestro proyecto 8 0 4 2.00 .354 Realizamos actividades para entender bien el problema 8 2 4 3.707 Eficiencia general de la metodología 8 0 4 3. TABLA IX 49 .

5%) Tabla IX.5%) 1(12.0%) Durante el desarrollo me mantuve motivado todo el tiempo 0(0%) 0(0%) 0(0%) 1(12.5%) 1(12.5%) 1(12. Resultados obtenidos en el cuestionario: tabla de frecuencia TABLA X 50 .0%) 6(75.5%) 7(87%) Tuvimos problemas causados por la relación entre los integrantes del equipo 5(62.0%) Percepción personal 3(37.0%) 6(75.5%) Creo que hicimos un proyecto de buena calidad 0(0%) 0(0%) 0(0%) Aprendí cosas nuevas en el desarrollo de este proyecto 0(0%) 0(0%) 0(0%) 1(12.5%) 0(0%) Todos los integrantes tuvimos una buena relación durante el desarrollo 0(0%) 0(0%) 0(0%) 1(12.5%) 6(75.5%) 2(25. 0(0%) 0(0%) 1(12.5%) 7(87..5%) 2(25.5%) 3(37.5%) La metodología utilizada contribuyó a la obtención rápida de un programa final de calidad 0(0%) 0(0%) 0(0%) 3(37.0%) 0(0%) 0(0%) La comunicación entre los integrantes del proyecto fue deficiente 3(37.5%) Estoy motivado a seguir aprendiendo más sobre esta metodología 0(0%) 0(0%) 0(0%) 2(25.5%) 4(50%) Tuvimos problemas para organizarnos 0(0%) 4(50%) 4(50%) 0(0%) 0(0%) Se nos dificultó tomar decisiones 0(0%) 4(50%) 3(37.5%) 3(37.0%) 0(0%) 0(0%) Criterio Dinámica del equipo de trabajo Percepción de la Metodología utilizada general La metodología favoreció la participación de todos 0(0%) 0(0%) 0(0%) 5(62.0%) En el futuro buscaré aplicar esta metodología a otros proyectos 0(0%) 0(0%) 1(12.5%) 3(37.5%) 5(62.5%) 7(87.Completamen te en desacuerdo En desacuerdo Neutral De acuerdo Completamente de acuerdo (0) (1) (2) (3) (4) En el desarrollo todos participamos activamente.5%) La metodología utilizada favorece sin duda el desarrollo rápido de aplicaciones móviles 0(0%) 0(0%) 0(0%) 0(0%) 8(100%) El desarrollo de software en general se puede beneficiar con las metodologías agiles 0(0%) 0(0%) 0(0%) 2(25.5%) 5(62.

5%) 1(12. A petición de los conductores de la investigación.5%) Evaluación cuantitativa de Scrum Comunicación entre los integrantes del equipo 0(0%) Motivación de los integrantes del equipo 0(0%) 0(0%) 1(12.0%) 0(0%) 1(12. 1(12.0%) 5(62.0%) 4(50. en donde cada integrante del equipo aportó algo al software obtenido.0%) 0(0%) Actividades de la ingeniería del software Percepción personal de las actividades de desarrollo experimental Entendí perfectamente la metodología que utilizamos 0(0%) 0(0%) 0(0%) 2(25.5%) 0(0%) 7(87.0%) 6(75.2 Perspectiva de los investigadores Siguiendo la metodología Scrum.5%) Preferiría que no cambiaran 0(0%) 1(12.5%) 4(50. El grupo de desarrolladores cumplió con los tiempos establecidos para la entregas del software en cada iteración. El cliente aprobó el producto final. una persona completamente ajena al equipo que desconocía la aplicación que se había solicitado hizo 51 .5%) Nuestro diseño inicial se modificó conforme avanzamos en el proceso de desarrollo.0%) 2(25. el cual cumplió con las pruebas especificadas.0%) 3(37.5%) 5(62.5%) Hicimos un diseño de la aplicación antes de programar 1(12.0%) Entendí perfectamente los requerimientos del proyecto solicitado 0(0%) 0(0%) 0(0%) 1(12.0%) 5(62.5%) 6(75. se observó un buen ambiente de trabajo.5%) 0(0%) 0(0%) 2(25.5%) 0(0%) 3(37.5%) Me desmotiva que el trabajo realizado se tenga que modificar a petición del cliente 2(25.5%) 5(62.5%) 1(12.Criterio Completame nte en desacuerdo En desacuerdo Neutral De acuerdo Completamente de acuerdo (0) (1) (2) (3) (4) 1(12.5%) 6(75.5%) 0(0%) 0(0%) 1(12.5%) En todo momento nos enfocamos en producir un programa que fuera funcional 0(0%) 0(0%) 0(0%) 3(37.5%) 0(0%) 0(0%) 0(0%) 7(87.5%) Al introducir cambios en los requerimientos.5%) 1(12.0%) 0(0%) 0(0%) Tabla X.5%) 1(12.5%) 2(25. se logró producir un software que cumplió con los requerimientos establecidos.1.0%) Organización para trabajar 0(0%) 0(0%) 1(12.5%) 2(25.5%) Le dimos más importancia a la programación que a otras actividades 1(12.5%) 3(37. Resultados obtenidos en el cuestionario: tabla de frecuencia 5.5%) 7(87.5%) Realizamos actividades para entender bien el problema 0(0%) 0(0%) 1(12. La aplicación de la metodología fue positiva según la percepción de los investigadores.5%) Eficiencia general de la metodología 1(12. sentí que habría que hacer mucho re-trabajo a nuestro proyecto 1(12.0%) 4(50.

Llegar a acuerdos de equipo en estas condiciones no es tarea fácil. También se debe considerar que el tiempo de desarrollo fue corto (doce horas) y que el equipo estaba formado por ocho personas. Esto puede estar relacionado con la naturaleza no prescriptiva de Scrum. en donde el equipo se debe auto organizar para alcanzar sus objetivos y con el hecho de que no todos los participantes se conocían entre sí. lo cual promovió algunos tiempos libres en algunos integrantes y dio la percepción de que la eficiencia de la metodología podría mejorarse. la organización para trabajar y la eficiencia general de la metodología. El equipo se demoró en tomar decisiones y adoptó una forma de trabajo centralizada en unas cuantas personas responsables. Los investigadores al observar al equipo y su organización para trabajar en este proyecto en concreto. ya que el conocimiento del lenguaje y de las herramientas utilizadas por parte del equipo se ubicó en un nivel básico – intermedio. 5. indicó que le pareció que la interfaz gráfica no era tan sencilla de utilizar y que pudo haber sido más intuitiva. Por otra parte. las principales desventajas que encontraron se refieren a la poca coordinación inicial que puede tener el equipo de desarrollo y al variado nivel de conocimientos y habilidades de los participantes. algunos participantes reportaron haber tenido inconvenientes con el entorno de desarrollo y algunos aspectos del lenguaje. sin embargo.2 Discusión Los integrantes del equipo reportaron una experiencia positiva al aplicar Scrum al desarrollo de aplicaciones móviles. Por otra parte. destacaron los siguientes aspectos positivos: la integración del equipo. Quizá por esta razón algunos integrantes mostraron una postura neutral al considerar aplicar Scrum en otros proyectos futuros. 52 . aceptaron haber tenido algunas dificultades relacionadas con la toma de decisiones.una prueba de usabilidad al software final. la rápida entrega del producto y la sinergia de habilidades diversas. aunque este usuario no tuvo problemas en el manejo de la aplicación desarrollada.

Los alumnos pusieron en práctica conocimientos específicos del área de desarrollo de software relacionados con Android. 53 . la experiencia fue positiva sin duda. El proceso de trabajo conjunto permitió la retroalimentación continua de experiencias que enriqueció a cada uno de los integrantes e hizo crecer al equipo completo. Java y Scrum. desarrollaron habilidades como el trabajo en equipo y la administración del tiempo y valores como la responsabilidad y la honestidad.Desde la perspectiva del proceso enseñanza .aprendizaje.

Como trabajo futuro se plantea la replicación de este desarrollo experimental. Este ejercicio experimental en concreto produjo a tiempo un software que cumplió con los requerimientos funcionales especificados y contó con un equipo de personas motivadas que construyeron nuevos conocimientos y los pusieron en práctica responsablemente. también una rápida implementación de los cabios solicitados. Se llegó a la conclusión de que las metodologías agiles ayudan a el desarrollo de aplicaciones móviles siendo esta una muestra de su adaptabilidad pudiendo ser implementa en distintos proyectos de investigación y desarrollo. primero con estudiantes y después con desarrolladores de software profesionales. aprendieran las herramientas prácticas necesarias para el desarrollo básico de aplicaciones móviles utilizando Java para Android y Scrum. 54 .1 Conclusiones En esta tesis se presentó un caso de estudio en el que se realizó un desarrollo experimental de software con el objetivo de que los programadores involucrados.CAPITULO VI 6. Además de Scrum se propone utilizar otra metodología ágil y una metodología tradicional con el propósito de contrastar los resultados obtenidos. todos ellos estudiantes de carreras profesionales de sistemas e informática. ventajas y desventajas llevando reuniones con intercambio de ideas que fortalecieran los nuevos conocimientos adquiridos. Se presentó la metodología ante los estudiantes mostrando cada una de sus características. Se concluyó que los participantes mejoraron su integración con un grupo de programadores que no conocían a su vez se demostraron adaptarse rápidamente a los diferentes problemas que se presentaron durante la fase de desarrollo. Los resultados obtenidos muestran que Scrum es una metodología que puede favorecer el desarrollo rápido de aplicaciones de buena calidad y que los casos prácticos de estudio son herramientas útiles en el proceso de enseñanza aprendizaje.

La simplicidad. Los promotores. Los responsables de negocio y los desarrolladores trabajamos juntos de forma  cotidiana durante todo el proyecto. o el arte de maximizar la cantidad de trabajo no realizado. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Hay que darles el  entorno y el apoyo que necesitan. Los procesos Ágiles promueven el desarrollo sostenible. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. Aceptamos que los requisitos cambien. Las mejores arquitecturas.  con preferencia al periodo de tiempo más corto posible. El método más eficiente y efectivo de comunicar información al equipo de   desarrollo y entre sus miembros es la conversación cara a cara. es  esencial. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja  competitiva al cliente. Entregamos software funcional frecuentemente. 55 . y confiarles la ejecución del trabajo.Anexo 1 Estos principios son el referente para diferenciar de un proceso ágil de uno tradicional. Los proyectos se desarrollan en torno a individuos motivados. desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante   de forma indefinida. requisitos y diseños emergen de equipos auto-  organizados. incluso en etapas tardías del desarrollo. El software funcionando es la medida principal de progreso.  Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y  continua de software con valor. entre dos semanas y dos meses.

Ciudad de Mexico: McGrawHill. (2005). Letelier. P. Persman. Buenos Aires: Tecnica administrativa. (s. (2004). United States of America. V. Estados Unidos: Cengage Learning. y. de http://sedici. J. Chris Sims. Estados Unidos: O`Relly. (2011). (2013). Symbian Os Internals: Real time kernell programming. C. Agile & Iterative development. de http://agilemanifesto. Pham. Estados Unidos: Ed. Recuperado el 12 de 06 de 2013. (2006). (2002).ar/bitstream/handle/10915/18745/Documento_c ompleto. E. Barrios. Forter: Dymaxicon. España: Editorial Marcombo. H. (2005). SEDICI Repositorio Institucional de la UNLP. United States of America. (2012). The Elements of Scrum. (2012).). Smyth.pdf?sequence=1 Wildermuth. Metodologías ágiles para el desarrollo de software : extreme programing (XP).edu. Dallas. Schildt. Palm Os Programing The developer`s Guide. Girones. M. 56 . A manager´s guide. Setting the stage: Agile and Scrum . (2011). Sales. United States of America: SAGE. Addison Wesley. Field. (2013). L. Iphone IOS 6 Development Essentials. A. (2001). United States of America: Orable. Walter G. Neil Rhodes. (2012). Vision general y entorno de desarrollo. H. A. Java the complete reference. P. Discovering Statistics Using IBM SPSS Statistics.unlp. Essential Windows Phone 8. Estados Unidos: Pearson Education.org/ Burnette. Recuperado el 12 de Junio de 2013. Desarrollo Agil En: Ingenieria de Software. En: El gran libro de Android. J. Hello.REFERENCIAS Manifiesto Agil. Android Introduccing Google`s Mobile Development Platform. Estados Unidos: Simbian. R. J. (2008).f. S. Larman. M. N.