Propuesta Ampliada


Índice Esquemático

1.      Generalidades
1.1.       Introducción
1.2.       Justificación
1.3.       Ficha descriptiva de la propuesta de investigación
Problema de Investigación aplicado a la empresa Tecnoevolución LTDA
1.4.       Descripción del problema
1.5.       Análisis del problema
1.6.       Profundización de la idea.
1.6.1.        Factores que se tuvieron en cuenta para la elección de la Metodología
1.6.2.        Selección del Método SCRUM
2.      Marco de Referencia
2.1.       Antecedentes Del Tema
2.2.       Propósito U Objetivo Del Estudio
2.3.       Límites del estudio
2.3.1. Marco Teórico
2.4.       Definición De Los Términos
2.5.       Supuestos Y Expectativas Del Tema
2.6.       Aporte a la Disciplina
3.      Metodología de la Investigación
3.1.       Diseño de la Investigación
3.1.1.        Tipo de investigación
3.1.2.        Población objetivo
3.1.3.        Técnicas de Investigación
3.1.4.        Diseño
3.1.5.        Recolección de Datos
3.1.6.        Resultados
Conclusión
Apoyo bibliográfico


1. Generalidades


1.1. Introducción



Es importante documentar todos los pasos realizados, en la selección adecuada de la idea, teniendo en cuenta los diferentes factores de investigación y sustentación, con el fin de lograr la aprobación del proyecto en el grupo de trabajo.
De allí la importancia de comprender los conceptos de un Proyecto y su ciclo de Vida para apropiarlos a la metodología de desarrollo ágil a  utilizar, en este caso SCRUM. 
En este documento se presenta  la idea de investigación, diseñada para la compañía Tecnoevolución LTDA, con el fin de adoptar la metodología más adecuada para el desarrollo de sus productos.

1.2. Justificación


De acuerdo a la ley 1341 del 30 de Julio de 2009,  “Por la cual se definen Principios y Conceptos sobre la Sociedad de la información y la organización de las Tecnologías de la información y las comunicaciones – tic”, se tienen en cuenta las herramientas presentadas para promover el Desarrollo de las Tecnologías de la Información.

De acuerdo con el Censo realizado por MinTIC en el año 2014 en Colombia habían 4016 empresas en el sector de las cuales el 80% están ubicadas en la Región Centro, el 4% en la Región Norte, el 6 % en la Región Occidente, el 4% en la Región Oriente, las demás se encuentran dispersas por el resto de la nación, entre los productos ofrecidos se encuentra el Desarrollo de software con un 23%.

El informe del Software Engineering Institute (SEI) del año 2015, Colombia es líder en la región, en la producción de software de calidad en el Modelo CMMI entre los niveles III y V.

De allí que la metodología de desarrollo ágil, ha logrado gran cobertura en el Sector de las Tics, contando con el apoyo de la  Fedesoft y el Sena, que buscan fortalecer y hacer más competitivo el sector del software y TI en Colombia, por medio de un Programa, de Formación Especializada para la implementación del modelo en SCRUM. Con el fin de mejorar el nivel de productividad, lograr altos niveles de calidad y administrar eficientemente los proyectos en las empresas en términos de tiempo y costo.



1.3. Ficha descriptiva de la propuesta de investigación


Línea de Investigación
Ingeniería de Software
Tecnología
Desarrollo de software ágil.
Fuente
Banco de Ideas curso Proyecto de Grado Ingeniería de Sistemas UNAD.
Referencia
ID_IDEA: 001
Descripción
Muchos equipos de desarrollo de software en todo el mundo están implementando nuevos métodos de desarrollo de software ágil como Programación extrema, SCRUM y Kanban. Varios autores han planteado estudios comparativos sobre estos métodos, la idea de esta propuesta de proyecto es investigar a profundidad estos estudios para tener un estado del arte de los métodos de desarrollo de software ágil y plantear recomendaciones a partir de un caso estudio real de una empresa desarrolladora de software colombiana.


Link del Blog  


Problema de Investigación aplicado a la empresa Tecnoevolución LTDA


 1.4. Descripción del problema


Tecnoevolución LTDA es una compañía dedicada a brindar soluciones informáticas al sector financiero, contando con más de 50 módulos que brindan soluciones a las diferentes necesidades que se presentan en el mercado en el que se desenvuelve. Cuenta con más de 15 años de experiencia de atención de sus clientes entre los que se encuentra el banco Colpatria, Fallabella, Banco de Bogotá, Sudameris, BBVA entre otras empresas de pequeña, mediana y gran envergadura. 
La compañía desde sus inicios utiliza como herramienta de desarrollo PowerBuilder que genera código powerscript, esta herramienta fue creada por Sybase Inc, y hace algunos años fue adquirida por SAP. Y gracias a su poder se ha podido usar con motores de base de datos como Oracle y SQL Server. Además, cabe aclarar que éste Framework permite crear programas tres veces más rápido que cualquier otro. La desventaja más grande que tienen los programas creados con PowerBuilder es que su arquitectura se basa en cliente-servidor en sistemas operativos Windows. Y su adaptación al mundo web ha sido un poco complicado, sin embargo, actualmente la compañía está usando una tecnología de visualización de servidores llamada Xoomker, esta funcionalidad, además de administrar aplicaciones de servidor, permite mostrarlas en navegadores Web, en otras palabras, es un escritorio remoto vía web.
Los módulos con los que cuenta Dialogo, que es el nombre de la aplicación de Tecnoevolución, tiene el mismo tiempo de maduración de la compañía. Por esta razón la lógica de su negocio exige gran cantidad de líneas de código y tablas en su base de datos. Actualmente, se está presentando demora e incumplimiento en las entregas de requerimientos nuevos y en la solución de incidencias en casi todos los clientes, gracias a que la compañía se encuentra certificada en CMMI nivel III que en el proceso dónde más se encuentran baches o demoras es el proceso de desarrollo. Por esta razón se está haciendo imprescindible el uso de una metodología de desarrollo ágil que se adapte de la mejor manera con el modelo de mejora y evaluación de procesos en la construcción de software (CMMI).

1.4.1. Página Web de la Compañía

1.5. Análisis del problema




Síntomas
Causas
Pronósticos
Control al pronóstico
1. Falta de documentación de los procesos propios del
1. Desconocimiento de los procesos internos del software.
1. Pérdida de tiempo, por repetición de líneas de
1. Comentarios en las líneas de Código y
Documentación
software.




código.

de cada uno de los procesos realizados.
2. Falta de Capacitación a los Usuarios.

2. Disminución de la operatividad del
equipo de trabajo

2.Insatisfacción de los clientes
2. Establecer políticas de capacitación en metodologías ágiles.
3. Falta de definición de requerimientos.

3. Falta de gestión y administración de los diferentes proyectos.
3. Los equipos de trabajo de la empresa en
desarrollo estarán confundidos.
3. Aplicar estrategias de dirección, control, administración y evaluación de proyectos adecuadas.



1.6. Profundización de la idea.

En la actualidad existen bastantes estrategias y métodos de desarrollo para equipos de trabajo, pero entre las más relevantes se conocen tres métodos de programación ágil.
ü  Programación Extrema
ü  Scrum
ü  Canvan
Sobre estos tres métodos se puede encontrar gran cantidad de información y posiciones que defienden uno o la otra. Lo importante es hallar la más adecuada para la compañía que permita:
•      Mayor desarrollo ágil
•      Empalme perfectamente con la metodología CMMI
•      Permita una mayor comunicación entre los diferentes equipos de trabajo
•      Permita gestionar y sobre todo controlar cada uno de los procesos de desarrollo
Por ahora es importante definir un poco cada metodología para ir entendiendo en que consiste:
En geekytheory se encuentra que: “La programación extrema es una metodología de desarrollo ágil que tiene como principal objetivo aumentar la productividad a la hora de desarrollar un proyecto software. Da prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la burocracia que pueda existir en el entorno de trabajo.” (Geekytheory)
En scrumguides.org, “Un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente. Scrum es: 
•      Ligero
•      Fácil de entender
•      Extremadamente difícil de llegar a dominar 
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos” (Ken Schwabe,r Jeff Sutherland)
Mientras que kANBAN no es una técnica específica del desarrollo software, su objetivo es gestionar de manera general como se van completando tareas, pero en los últimos años se ha utilizado en la gestión de proyectos de desarrollo software. Dice Javier Garzas en su blog.
Antes de seleccionar un método es pertinente investigar más acerca de cada uno de ellos y cual satisface en mayor medida las necesidades de Tecnoevolución.

       1.6.1. Factores que se tuvieron en cuenta para la elección de la Metodología

 •      Información sobre el estado de capacitación del personal de la empresa sobre metodologías ágiles mediante la aplicación de una encuesta de conocimientos.

•      Informe sobre casos de implementación de metodologías ágiles en entornos de desarrollo de software en empresas del sector.

•      Análisis de ventajas y desventajas sobre los dos sistemas de metodología ágil: Scrum y Kanban.

El desarrollo de cada uno de los procesos de la investigación se amparará sobre encuestas y observación en puestos de trabajo y análisis de documentos de implementación en otras empresas del sector.

1.6.2. Selección del Método SCRUM

De acuerdo a los resultados obtenidos en las encuestas y la investigación realizada, se selecciona la Metodología de programación Ágil SCRUM.
Teniendo en cuenta las siguientes características:

ü  Tecnoevolución LTDA,es una empresa de Desarrollo orientada a varios clientes.
ü  La mayoría de los Proyectos son complejos.
ü  Las funcionalidades de Desarrollo deben esperar un mínimo de 2 semanas para estar en producción.

Se debe, proporcionar al cliente un calendario de entregas de funcionalidades de su producto.



2. Marco de Referencia

 

2.1. Antecedentes Del Tema



El concepto de Scrum tiene su origen en un estudio de 1986 [1] sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos partían de requisitos muy generales, así como novedosos, y debían salir al mercado en mucho menos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español).
En 1993 se realizó el primer Scrum para desarrollo de software y en 1995 el proceso fue formalizado. En 2001 un grupo de personas muy relevantes en lo que empezaba a ser el desarrollo ágil escribieron los valores fundamentales de los procesos ágiles.
Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 3 personas desarrollando un producto, como en multinacionales, entre las que se encuentran las siguientes:


Sectores
Ejemplos De Empresas Que Utilizan Metodologías Ágiles Como Scrum 
Media y Telcos
BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia, Palm, Qualcomm, Schibsted, Sony/Ericsson, Telefonica I+D, TeleAtlas, Verizon
Software, Hardware
Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén, IBM, Intel, Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts, Primavera, Proyectalis, Softhouse, Valtech, VersionOne.
Internet
Amazon, Google, mySpace, Yahoo
ERP
SAP
Banca e Inversión
Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch
Sanidad y Salud

Patientkeeper, Philips Medical
Defensa y Aeroespacial
Boeing, General Dynamics, Lockheed Martin

Juegos
Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts
Otros
3M, Bose, GE, UOC, Ferrari


2.2. Propósito U Objetivo Del Estudio
Definir la metodología que permita tener mayor cumplimiento, flexibilidad, reducción de tiempo de desarrollo, mayor calidad de software, mayor productividad, predicción de tiempos y reducción de riesgos en el desarrollo de soluciones informáticas en Tecnoevolución LTDA.
2.3. Límites del estudio
El estudio se limita al análisis e investigación para la implementación y sostenibilidad de la   metodología de desarrollo ágil Scrum.

2.3.1. Marco Teórico


¿Qué es SCRUM?
SCRUM es un proceso de la metodología ágil, en el cual se aplican un conjunto de buenas prácticas en el marco de la metodología ágil, con el fin de minimizar los riesgos durante el desarrollo de un proyecto, permitiendo el trabajo en equipo a fin de obtener el mejor resultado
¿Cómo funciona el proceso?
El proceso está basado en entregas parciales y regulares del producto final, definidas siempre al comienzo de un ciclo o sprint, dichas entregas son priorizadas con base al beneficio que entregan al cliente final.

 

Ilustración 1 - Proceso SCRUM tomado de https://proyectosagiles.org/quees-scrum/

Lo primero que se debe hacer para iniciar un proceso SCRUM es definir el Product Backlog, este se trata de una lista sobre las funcionalidades que deberá cumplir el producto al final de todo el proceso. Dicha lista es elaborada por el Product Owner o propietario del producto, quien es el encargado de tomar las decisiones ante el cliente, dichas funciones están priorizadas según lo que es más y menos importante para el negocio. El objetivo final de definir el Backlog es tener una base de tareas que permitirá realizar cada uno de los Sprints o iteraciones más adelante.
El Sprint Backlog se trata de un subconjunto de ítems del Product Backlog, que son seleccionados por el equipo para realizar durante el Sprint sobre el que se va a trabajar. El equipo establece la duración de cada Sprint.
Sprint Planning Meeting es una reunión que se hace al comienzo de cada Sprint y es donde se define cómo se va a enfocar el proyecto, tomando siempre como base las tareas generales del proyecto ó  Product Backlog y las tareas que se van a seleccionar para el Sprint a iniciar, definiendo así mismo cada una de las etapas y los plazos en los que se realizarán las entregas.
Daily Scrum se trata de una reunión breve, diaria, mientras dura el periodo de Sprint. Se responden individualmente tres preguntas: ¿Qué hice ayer?, ¿Qué voy a hacer hoy?, ¿Qué ayuda necesito? En esta reunión se dan a conocer los inconvenientes presentados con el fin de que se encuentren soluciones prontas y se permita cumplir con las entregas planeadas para cada Sprint, de esta manera se detectan a tiempo y se dan soluciones rápidamente.
Sprint Review es donde se revisa el sprint terminado, y ya debería haber un avance claro y tangible para presentárselo al cliente.
Sprint Retrospective se trata de una reunión, una vez finalizado el Sprint, en donde el equipo revisa los objetivos cumplidos del Sprint terminado. Se anota lo bueno y lo malo, para no volver a repetir los errores. Esta etapa sirve para implementar mejoras desde el punto de vista del proceso del desarrollo, por tal motivo se trata de un proceso de mejora continua, ya que siempre se realiza retroalimentación de lo sucedido durante cada una de las etapas del proceso y del proyecto.

¿Cuáles son los beneficios de usar SCRUM?
•              Productividad, debido a que las entregas se realizan de forma más periódica, por lo que el cliente percibe el avance del mismo
•              Calidad, ya que el seguimiento realizado a cada una de las tareas permite recibir retroalimentación por parte del equipo y del cliente, detectando fallas de manera temprano, pudiendo ser corregidas a tiempo.
•              Seguimiento diario de los avances del proyecto, aumentando de esta forma la interacción constante entre cada una de las partes del equipo desarrollador y del cliente, dando gran tranquilidad a este último debido a que puede percibir el avance que va teniendo el proyecto • Unión y comunicación del equipo con el cliente
•              Mayor flexibilidad en el proceso y en la definición de los productos, y esto suele suceder cuando el cliente no tiene 100% claros los requisitos del sistema final, por lo que a medida que se realizan las reuniones de seguimiento y la retroalimentación de las mismas, estos se van haciendo más claros para cada una de las partes involucradas.

¿Cuáles son los inconvenientes?
A pesar de que se trata de un proceso altamente productivo, también es cierto que presenta ciertos inconvenientes si no se cuenta con todos los aspectos claramente cubiertos y detallados, dentro de los cuales se encuentran:
•              El equipo se puede tentar a tomar el camino más corto con el fin de alcanzar cada uno de los sprints.
•              No es un proceso eficiente si el cliente necesita tener las fechas de todo el proyecto de una forma anticipada.
•              La carga que se genera sobre cada integrante del equipo es pesada, debido al cumplimiento para cada uno de los sprints, por lo que se puede generar stress laboral.
•              Es un proceso que requiere de un equipo auto-organizado y que sea transparente, en donde cada uno de los miembros sepa lo que tiene que hacer cada día, lo que se debe entregar y sepa reportar a tiempo los inconvenientes que se le presentan.
•              Las tareas deben estar muy definidas o de lo contrario la estimación en tiempo y costes no será lo suficientemente exacta al momento de definir entregables.
Aplicaciones de SCRUM
Ahora, se confirma que este proceso realmente puede solucionar muchos de los problemas dentro de los proyectos de desarrollo de software. Traduciéndose en mejora en los procesos, planificación, desarrollo e implementación de los mismos, conduciendo siempre al equipo a una mejora continua.
Con base a lo anterior se hace posible plantear los pasos deseables para implementar SCRUM en un pequeño proyecto y así comprobar cada una de las ventajas y posibles desventajas planteadas:
1.  Elige un responsable de producto.
2.  Elige un equipo.
3.  Elige un Scrum Master.
4.  Elabora y prioriza una lista de objetivos o backlog.
5.  Haz una estimación afinada de la lista de objetivos pendientes.
6.  Planificación de sprints.
7.  Haz que el trabajo sea visible.
8     Scrum Diario. Reunión Diaria de pie.
9     Revisión o demostración del sprint.
10  Retrospectiva del sprint.
11  Empieza inmediatamente el siguiente ciclo de sprints.

2.4. Definición De Los Términos

Backlog grooming y backlog refinement: También llamada revisión de la pila del producto y refinamiento de la pila del producto. Es la reunión del propietario del producto con el equipo para mantener actualizada la pila del producto. Se plantea con un tiempo máximo prefijado (habitualmente una o dos horas) y un objetivo.
Burn up: O gráfico de producto. Es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto. Proyecta en el tiempo la construcción del producto, en base a la velocidad del equipo
Burndown: O gráfico de avance, es el gráfico que actualiza el equipo en las reuniones de seguimiento del sprint, para monitorizar el ritmo de avance, y detectar de forma temprana posibles desviaciones sobre la previsión que pudieran comprometer la entrega al final de sprint. Un vistazo general al trabajo restante (puede tener dos tableros: uno para el sprint y otro para el proyecto general). Este tablero es usualmente contrario en su diseño a lo que usualmente se plasma, aquí se muestra lo que falta por hacer y no lo que se va avanzando.
Daily scrum: La reunión de Scrum diario es uno de los eventos de Scrum técnico. Es una reunión diaria breve, de no más de 15 minutos, en la que el equipo sincroniza el trabajo y establece el plan para las 24 horas siguientes.
Epic: Se denomina Epic a una historia de usuario que, por su gran tamaño, el equipo descompone en historias con un tamaño más adecuado para ser gestionada con los principios y técnicas ágiles: estimación y seguimiento cercano (normalmente diario).
Equipo: Grupo auto organizado enfocado en un objetivo común para hacer el trabajo
eXtreme Programming (XP) o programación extrema: es un conjunto de prácticas ágiles. En donde se considera que las modificaciones de requisitos constantes son un aspecto natural, inevitable e incluso deseable en los desarrollos de software, configurándose de esta forma (como todos los modelos ágiles) en un modelo enfocado en la adaptabilidad antes que en la previsibilidad.
Historia de usuario: Descripción de una funcionalidad que debe incorporar un sistema de software, y cuya implementación aporta valor al cliente
Incremento: El incremento es la parte de producto producida en un sprint, y tiene como característica el estar completamente terminada y operativa, en condiciones de ser entregada al cliente.
Lead time:  O tiempo de producción, es la latencia o tiempo que transcurre desde que se inicia un proceso de producción hasta que se completa.
Mapa de historias: Es una representación visual de una pila de producto en dos dimensiones. La implementación más habitual es sobre un tablero kanban. Horizontalmente se alinean en la parte superior los epics ordenados por prioridad, y bajo ellos se despliegan verticalmente alineado con cada uno las tarjetas que representan las distintas historias de usuario que los componen.
Mapa de producto: Técnica para estructurar la funcionalidad del producto, desde los temas hasta las historias de usuario
Pila del sprint: Lista de tareas que va a realizar el equipo en una iteración, para construir un incremento.
Planificación del sprint: En esta reunión se toman como base las prioridades y necesidades de negocio del cliente, y se determinan cuáles y cómo van a ser las funcionalidades que se incorporarán al producto en el siguiente sprint.
Product Backlog(Cartera de producto): Lista priorizada de resultados/características deseables del producto del proyecto
Product canvas: Tablero kanban de producto para mostrar en un vistazo.
ü  El objetivo de la visión del producto, o de la versión actualmente en desarrollo.
ü  Temas e historias previstas. 
ü  Historias que se están desarrollando en el sprint actual.
Propietario del producto: El propietario del producto es uno de los roles de scrum técnico. El propietario del producto (product owner) es quien toma las decisiones del cliente. Su responsabilidad es el valor del producto.
Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint. Las reuniones retrospectivas son por tanto un una “meta-práctica” ágil.
Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la pila del producto si resulta necesario. Se realiza al final del sprint para comprobar el incremento. No debe durar más de 4 horas, en el caso de revisar sprints largos.
Scrum avanzado: Adaptar las prácticas Scrum a las circunstancias de la propia organización, permite emplear técnicas de incremento continuo o iterativo; tableros kanban con el formato más adecuado a cada proyecto, y en general las prácticas y reglas que mejor encajan en las circunstancias de cada caso.
Scrum Master: Scrum Master es uno de los roles de scrum técnico. Es el responsable del cumplimiento de las reglas de un marco de scrum técnico, asegurando que se entienden en la organización, y se trabaja conforme a ellas. Facilitador que asegura que el equipo es funcional y productivo
Scrum técnico: Modelo de implementación estándar de los principios de desarrollo en "campos de Scrum".
Sprint Backlog (Cartera de sprint): conjunto de trabajos (entendiéndose como lo que se requiere para lograr los resultados o características buscadas en el producto) de la cartera de productos que el equipo acuerda completar en un sprint, dividido en tareas
Sprint Planning: el equipo se reúne con el propietario del producto para elegir un conjunto de características del producto a realizarse durante un sprint
Sprint Retrospectives: el equipo busca maneras de mejorar el producto requerido y el proceso usado en el proyecto.
Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso de avance por tiempos prefijados (time boxing).
Tarea: Unidad de trabajo gestionada por el equipo. Una tarea tiene asignada una persona para su realización, y es recomendable que el esfuerzo estimado parara llevarla a cabo sea como máximo el equivalente al realizable en una jornada de trabajo. Los equipos de trabajo ágiles descomponen en tareas para gestionar y seguir el avance de su ejecución.
Tema: Se denomina tema a una colección de epics relacionados para describir un sistema o subsistema en su totalidad.
Timeboxing: O Tiempo prefijado. Técnica de administración de tiempo, comúnmente empleada en los modelos de gestión ágil, consistente en dividir el trabajo en tareas con una asignación de tiempo limitado y corto para su ejecución.
2.5. Supuestos Y Expectativas Del Tema
Los principales beneficios que proporciona Scrum son: 

•      Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:


ü  Gestión regular de las expectativas del cliente y basada en resultados tangibles.

ü  Resultados anticipados (time to market).

ü  Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc.

ü  Gestión sistemática del Retorno de Inversión (ROI).

ü  Mitigación sistemática de los riesgos del proyecto.


•      Productividad y calidad.
•      Alineamiento entre el cliente y el equipo de desarrollo.
•      Equipo motivado.



Beneficios De Scrum
Cómo Se Consiguen
Gestión regular de las expectativas del cliente
El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado.
El cliente comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta. Se ahorra esfuerzo y tiempo al evitar hipótesis.
El cliente crea y gestiona la lista de requisitos del producto o proyecto, donde quedan reflejadas sus expectativas a nivel de requisitos, valor, coste y entregas.
Al final de cada iteración el equipo demuestra al cliente los requisitos que ha conseguido completar. Tras una inspección del resultado real del proyecto hasta ese momento, y considerando el esfuerzo que ha



 
sido necesario para realizarlo, el cliente solicita los cambios que necesita y replanifica el proyecto.
Resultados anticipados (“time to market”)
El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.
Siguiendo la ley de Pareto (el 20% del esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto al que sólo le faltan características poco relevantes, puede sacar al mercado un producto antes que su competidor, puede hacer frente a urgencias o nuevas peticiones de clientes, etc.
Al inicio de cada iteración el cliente prioriza la lista de requisitos del producto o proyecto en función del valor que le aportan, su coste de desarrollo y los riesgos del proyecto, cambiando los requisitos previstos para reaccionar a cambios de contexto en el proyecto.
El progreso del proyecto se mide en función de los requisitos que el equipo completa en cada iteración.
Flexibilidad y adaptación
De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de desarrollo, etc.
Al final de cada iteración el cliente puede aprovechar la parte de producto completada hasta ese momento para hacer pruebas de concepto con usuarios o consumidores y tomar decisiones en función del resultado obtenido.
Se asume que los cambios son parte natural del proyecto. Toda iteración comienza con una replanificación del proyecto. Esta replanificación no es traumática puesto que Scrum minimiza el número de objetivos/requisitos en que el equipo trabaja (WIP, Work In Progress) a los que caben en una iteración. Todavía no se ha hecho ningún esfuerzo en desarrollar los requisitos de las siguientes iteraciones.




El hecho los requisitos se completen en función del valor que aportan al cliente minimiza la probabilidad de que se produzcan grandes cambios en el transcurso del proyecto.
Retorno de inversión (ROI)

De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto.

Cada iteración el cliente dispone de unos requisitos completados y re planifica el proyecto en función del valor que le aportan los requisitos pendientes respecto del coste de desarrollo que tienen.
Mitigación de riesgos

Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. "Si hay que equivocarse o fallar, mejor hacerlo lo antes posible". El feedback temprano permite ahorrar esfuerzo y tiempo en errores técnicos.
La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones.

Un requisito se debe completar en una iteración. El equipo debe realizar todas las tareas necesarias para completarlo y que esté preparado para ser entregado al cliente con el esfuerzo mínimo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.
Productividad y calidad
De manera regular el equipo va mejorando y simplificando su forma de trabajar.
Los miembros del equipo sincronizan su trabajo diariamente y se ayudan a resolver los problemas que pueden impedir conseguir el objetivo de la iteración. La comunicación y la adaptación a las
Cada iteración el equipo realiza una retrospectiva para analizar su manera de trabajar e identificar los obstáculos que le impiden avanzar al mejor ritmo posible.
Comunicación diaria del equipo Todo miembro del equipo conoce



diferentes necesidades entre los miembros del equipo son máximas (se van ajustando iteración a iteración), de manera que no se realizan tareas innecesarias y se evitan ineficiencias.
Las personas trabajan más enfocadas y de manera más eficiente cuando hay una fecha límite a corto plazo para entregar un resultado al que se han comprometido. La consciencia de esta limitación temporal favorece la priorización de las tareas y fuerza la toma de decisiones.
Las iteraciones (Sprints) son regulares y de un mes para facilitar la sincronización sistemática con otros equipos, con el resto de la empresa y con el cliente.
El equipo minimiza su dependencia de personas externas para poder avanzar (depender de la disponibilidad de otros puede parar tareas).
La estimación de esfuerzo y la optimización de tareas para completar un requisito es mejor si la realizan las personas que van a desarrollar el requisito, dadas sus diferentes especializaciones, experiencias y puntos de vista. Asimismo, con iteraciones cortas la precisión de las estimaciones aumenta.
Las personas trabajan de manera más eficiente y con más calidad cuando ellas mismas se han comprometido a entregar un resultado en un momento determinado y deciden cómo hacerlo, no cuando se les ha asignado una tarea e indicado el tiempo necesario para realizarla.
El equipo se evita caminar mucho tiempo por un camino equivocado que le obligue a realizar un gran esfuerzo
para llegar al objetivo esperado
cómo el trabajo de los otros miembros impacta en el suyo y cuáles son las necesidades de los otros.
Cada actividad de Scrum siempre tiene la misma duración (1 mes, 4 horas, etc.), con lo que las personas aprenden lo que pueden conseguir en este tiempo, cómo organizarse, priorizar tareas y tomar decisiones.
El equipo está formado por todas las personas con las especialidades necesarias para llevar a cabo el proyecto.
En el inicio de la iteración los miembros del equipo estiman de manera conjunta el esfuerzo necesario para completar requisitos y sus tareas.

En el inicio de cada iteración el equipo selecciona los requisitos que se compromete a completar y entregar al final de la iteración (responsabilidad). El propio equipo se organiza (autoridad) identificando las tareas necesarias, su esfuerzo y auto asignándose cada miembro las tareas que se compromete a realizar.
Demostración de resultados preparados para ser utilizados y velocidad sostenida

Por un lado, al final de cada iteración el equipo demuestra al



Se asegura la calidad del producto de manera sistemática y objetiva, a nivel de satisfacción del cliente, requisitos listos para ser utilizados y calidad interna del producto.
cliente los requisitos que ha conseguido completar, de manera que están completamente operativos. Por otro lado, para tener una velocidad de desarrollo sostenida, el equipo necesita desarrollar cada incremento de producto sin tener que revisitar aspectos mal resueltos en iteraciones anteriores.  
Alineamiento entre cliente y equipo

Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos.
Cliente y equipo trabajando “en equipo”

Cada iteración el equipo y el cliente trabajan juntos en la creación de los requisitos del proyecto (en la estimación de la lista priorizada de requisitos del proyecto), en darles detalle (en la reunión de planificación de la iteración) y en el análisis del resultado obtenido (en la demostración de los requisitos completados).
Equipo motivado

Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.
 
Las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen.
 

El equipo es quien se compromete a completar unos requisitos determinados en una iteración y quien mejor sabe cómo desarrollarlos. Por ello es el equipo quien se auto organiza y quien planifica cómo trabajará en la iteración.

Cada iteración el equipo muestra al cliente los resultados que consigue. No está meses trabajando sin poder exhibir su obra.
 


2.6. Aporte a la Disciplina


La investigación realizada, aporta información real y concisa, sobre el tema de estudio, que servirá como base para próximas investigaciones sobre la metodología de Desarrollo ágil Scrum a estudiantes del programa de Ingeniería de Sistema.



3. Metodología de la Investigación


3.1. Diseño de la Investigación




3.1.1. Tipo de investigación:
Cuantitativa.

3.1.2. Población objetivo.

La totalidad de empleados de la empresa, 60 en total.


3.1.3. Técnicas de Investigación


Para esta investigación se decidió realizar una encuesta con preguntas afirmativas o negativas y de Escala Lineal.


3.1.4. Diseño


Para el Diseño y Estructura de la encuesta se tuvieron en cuenta factores que permitieran recopilar la información de forma clara y concisa, sobre los conocimientos básicos que tienen los empleados de la compañía sobre las Metodologías de Desarrollo ágil, especialmente en Scrum.


La encuesta se realizó en un Formulario de Google.
3.1.5. Recolección de Datos
Para la Recolección de Datos se enviara el link de la encuesta de forma masiva a los correos de los empleados de la compañía,





CONCLUSION

La documentación es uno de los factores más importantes de cualquier proyecto, en especial en el Desarrollo de Software, ya que nos permite verificar cada paso del proyecto desde su análisis, investigación, desarrollo, pruebas y ejecución.
En la propuesta de investigación presentada se tuvieran en cuenta diferentes factores, que nos permitieron conocer más a fondo, la implementación de una nueva metodología de Desarrollo en una compañía.