UNIVERSIDAD POLITÉCNICA DE SINALOA

PROGRAMA ACADÉMICO DE

INGENIERÍA EN INFORMÁTICA

Tesina

“Implementación de la metodología Scrum”

Para obtener la acreditación de las estadías

profesionales y contar con los créditos para

el grado de Ingeniero en Informática.

Autor: Kaly Manuel Rojas Salas

Asesor: Dr. Rodolfo Ostos Robles

Mazatlán, Sinaloa 28 de noviembre de 2015

Agradecimientos

Me agradezco a mí por tomar el reto de migrar a otra ciudad a realizar mis prácticas

profesionales y tomar nuevos retos, a mis padres y mis padrinos que gracias a su

apoyo moral y económico pude emprender esta aventura en otra ciudad, familiares

y amigos que me apoyaron en el transcurso de mi carrera y por ultimo a la persona

que durante mis practicas me ofreció su apoyo para que este documento cumpla

con lo necesario para que sea del agrado de aquellos que se interesen en aprender

más sobre una metodología que facilita el desarrollo de software al Dr. Rodolfo

Ostos Robles que durante este tiempo se ha dado la tarea de revisar

minuciosamente cada parte del documento para que quede lo mejor posible,

muchas gracias.

Contenido

Resumen ............................................................................................................................... 10

Introducción ......................................................................................................................... 11

1 Acerca de Jaguar Labs (JL) ................................................................................................. 13

1.1 Misión ......................................................................................................................... 13

1.2 Visión .......................................................................................................................... 13

1.3 Valores ........................................................................................................................ 14

1.4 Servicios ...................................................................................................................... 14

1.5 Tecnologías ................................................................................................................. 14

1.6 Desarrollo móvil .......................................................................................................... 14

1.7 Desarrollo web ............................................................................................................ 14

1.8 Cloud ........................................................................................................................... 14

1.9 Ubicación .................................................................................................................... 14

1.10 Organigrama ............................................................................................................. 16

1.11 Planteamiento del problema .................................................................................... 17

1.11.1 Propuesta de la investigación ............................................................................ 17

1.11.2 Objetivos de la investigación ............................................................................. 17

1.11.3 Objetivo General................................................................................................ 17

1.11.4 Objetivos particulares........................................................................................ 17

1.11.5 Preguntas de la investigación ............................................................................ 18

1.11.6 Hipótesis ............................................................................................................ 18

1.11.7 Limitaciones y supuestos ................................................................................... 18

1.11.8 Relevancia .......................................................................................................... 19

2 Software ............................................................................................................................. 21

2.1 Importancia del software ........................................................................................... 21

2.1.1 La Importancia del Software para la Sociedad .................................................... 23

2.1.2 Beneficios del Software para Sociedad ............................................................... 23

2.1.3 ¿Porque se ha vuelto tan importante? ................................................................ 23

2.1.4 El uso del Software para la Educación ................................................................. 23

2.2 Crisis del software ...................................................................................................... 23

2.2.1 Causas de la crisis del software ........................................................................... 25

2.2.2 Ingeniería del software, la solución. .................................................................... 26

2.2 Ingeniería de software ................................................................................................ 27

2.2.1 Proceso del software ........................................................................................... 28

2.2.2 ¿Qué es un modelo de procesos de software? ................................................... 29

2.2.3 Atributos de un buen software ........................................................................... 29

2.2.4 Código de ética y práctica profesional de la ingeniería de software .................. 30

2.2.5 Fundamentos que afronta la ingeniería de software .......................................... 30

2.3 Metodologías de desarrollo del software .................................................................. 31

2.3.1 EVOLUCION .......................................................................................................... 33

2.4 Metodologías clásicas ................................................................................................. 34

2.4.1 Cascada ................................................................................................................ 34

2.4.3 Evolutivo .............................................................................................................. 36

2.4.5 Prototipos ............................................................................................................ 37

2.5 Metodologías Ágiles ................................................................................................... 40

2.5.1Metodologías para el desarrollo ágil del software............................................... 40

3 Implementación de la metodología Scrum ....................................................................... 53

Preparación para el proyecto ........................................................................................... 60

Planificación de sprint ...................................................................................................... 62

SCRUM diario .................................................................................................................... 64

Show Case ......................................................................................................................... 66

Retrospectiva .................................................................................................................... 69

Conclusión ............................................................................................................................ 72

Referencias ........................................................................................................................... 73

Índice de ilustraciones

Ilustración 1.1 Ubicación de la Empresa. (Obtenida con Google Earth)………15

Ilustración 1.2 Organigrama………………………………………………………..16

Ilustración 2.1. Gráfico de 1979…………………………………………………..26

Ilustración 2.2. Caso de ingeniería de software. ……………………………….27

Ilustración 2.3. Etapas metodología de cascada………………………………..35

Ilustración 2.4. Flujo del prototipo………………………………………………...38

Ilustración 2.5. DAS………………………………………………………………...45

Ilustración 2.6. Proceso Scrum……………………………………………………49

Ilustración 3.1. Team Members. ………………………………………………….54

Ilustración 3.2. Responsabilidades del AM (Planeación)………………………55

Ilustración 3.3. Responsabilidades del AM (Control)……………………………55

Ilustración 3.4. Responsabilidades del AM (Monitoreo)………………………..56

Ilustración 3.5. Responsabilidades del SM (Planeación)………………………56

Ilustración 3.6. Responsabilidades del SM (Monitoreo)………………………..57

Ilustración 3.7. Responsabilidades del SM (Validación)………………………..57

Ilustración 3.8. Responsabilidades del SM (Control)……………………………58

Ilustración 3.9. Flujo del proceso Scrum. ………………………………………59

Índice Tablas

Tabla 2.1. Atributos de un buen desarrollo de software……………………………30

Tabla 2.2. Diferencias entre metodologías………………………………………42

10

Resumen El presente documento ha sido realizado por el estudiante Rojas Salas Kaly Manuel

con la finalidad de concluir con sus estudios de ingeniería en la Universidad

Politécnica de Sinaloa. El trabajo aborda el tema de como las herramientas de

software van evolucionando al paso del tiempo, y como la implementación de una

de las nuevas metodologías hacen ver el cambio en cuestión de flexibilidad a

cambios a comparación de las metodologías iniciales y como se implementa la

metodología Scrum en jaguar Labs.

Desarrollo de software, Metodologías, Scrum.

This document was written by the student Rojas Salas Kaly Manuel order to conclude his engineering studies at the Universidad Politécnica de Sinaloa. The paper addresses the issue of software tools As They evolve over time, and as the implementation of new Methodologies do see change in a matter of flexibility to change Compared to the initial methodology and how the Scrum methodology is implemented in Jaguar Labs. Software development methodologies, Scrum.

11

Introducción La presente tesina es una investigación que tiene como objetivo mostrar como

ayuda la implementación de la metodología Scrum en una empresa de desarrollo

de software, se da a conocer lo que es el software, como fue evolucionando con el

paso del tiempo las herramientas que se utilizaban cuando inicio, los problemas por

los que paso, como se solucionaron esos problemas y cuáles son los procesos que

se utilizan hoy en día.

Los datos se obtuvieron práctica diaria de la metodología Scrum, documentación de

Jaguar Labs y fuentes de libros y páginas de internet.

Este trabajo de investigación presenta los siguientes capítulos:

En el capítulo I se da a conocer información sobre la empresa donde se llevó a cabo

la práctica de la metodología Scrum junto con el planteamiento del problema.

En el capítulo II se lo que es el software y por lo que ha pasado desde que este se

dio a conocer, como su importancia, dificultades, como se superaron esas

dificultades y sus metodologías.

En el capítulo III se muestra los procesos que se implementan en la metodología

Scrum.

12

Capítulo I

Planteamiento del problema

13

1 Acerca de Jaguar Labs (JL) En este capítulo se da a conocer información general de la empresa en la cual se

estará llevando a cabo la práctica de la metodología Scrum, y se abordará el

planteamiento del problema.

Jaguar Labs Mobile Developers es una empresa joven de apenas tres años de

desarrollo de software para móviles y web, la cual cuenta con dos sucursales un

número de empleados de aproximadamente 70 empleados entre ellos

desarrolladores, analistas, diseñadores, líderes de proyecto entre otros roles,

quienes tienen como director al Ing. Siddartha Nava Gallegos.

Jaguar Labs toma su nombre, inspirados en la fortaleza y agilidad de este felino,

que da identidad a nuestro país desde tiempos precolombinos. Orgullosos de

nuestras raíces, Jaguar Labs tiene sus oficinas en Guadalajara, Jalisco, hogar del

60% de la industria TI de México y gran talento creativo. Ciudad, conocida como el

Silicon Valley Mexicano.

Mediante la metodología ágil de SCRUM, se mantiene en continua comunicación

con sus clientes para asegurarse que el trabajo entregado sea el deseado.

Es una firma de tecnología especializada en el desarrollo de aplicaciones móviles,

cuyo principal valor está sustentado en la calidad personal y profesional de sus

colaboradores. Cuenta con la acreditación CMMI, la más reconocida en el mundo,

para llevar a cabo proyectos de desarrollo tecnológico.

Trabajar con Jaguar Labs es una decisión estratégica para las empresas, pues la

ubicación geográfica, accesibilidad del uso horario, idioma y cultura organizacional

acercan eficientemente la relación comercial, a través del uso de un proceso maduro

y disciplinado Nearshore.

1.1 Misión Proveer servicio de alta calidad, utilizando tecnologías de punta y métodos

innovadores, buscando siempre superar las expectativas de nuestros clientes,

además de contar con el equipo más capacitado y motivado para abajar por el

crecimiento personal, prestigio y orgullo de formar parte de ella, y en donde

finamente, la cooperación, trabajo en equipo y respeto sean cimientos de su éxito.

1.2 Visión Ser la empresa líder de México en desarrollo de aplicaciones móviles propis o para

terceros, proporcionando las mejores soluciones y experiencias a nuestros clientes

y contando con el mejor equipo de asociados y socios en el mejor ambiente y formas

de trabajo posibles.

14

1.3 Valores Los valores en JL son:

Excelencia

Confianza

Satisfacción del cliente

Innovación

Balance (Trabajo/vida)

1.4 Servicios JL realiza el proyecto completo, desde el análisis, diseño gráfico, desarrollo, link con

redes sociales, pruebas, bases de datos y servicios web.

1.5 Tecnologías En JL están especializados en tres tipos de servicios que les permiten crear

aplicaciones en diferentes entornos, dispositivos y tecnologías con altos estándares

de calidad que satisfacen las necesidades sus nuestros clientes.

1.6 Desarrollo móvil En JL desarrollan aplicaciones nativas y multiplataforma con la mejor experiencia

de usuario y enfocados en las nuevas tendencias del mercado.

1.7 Desarrollo web JL crea aplicaciones web funcionales y atractivas, con gran experiencia de usuario

(UX) y soporte en diferentes navegadores y plataformas. En cada uno de los

desarrollan se aseguran de brindar el proceso para crear un proyecto totalmente a

la medida.

1.8 Cloud JL genera, de una manera eficiente y rápida, aplicaciones de flujo de trabajo en la

nube. Aplicaciones que hacen la diferencia con una mejor experiencia, que cubren

tus necesidades.

15

1.9 Ubicación JL está ubicado en Av. General Ramón Corona #2455F C.P.45200 Col. La

Mojonera, Zapopan, Jalisco, México

Ilustración 2.1 Ubicación de la Empresa. (Obtenida con Google Earth)

16

1.10 Organigrama En la siguiente imagen se muestra cómo está organizada la empresa JL.

Ilustración 1.2 Organigrama

17

1.11 Planteamiento del problema A causa del uso de metodologías tradicionales las empresas hoy en día llegan a tener problemas con sus clientes a consecuencia a que estas no cuentan con la flexibilidad necesaria para adaptarse a imprevistos de último momento, ya que las metodologías tradicionales esperan a que el producto ya se desarrolle para después verificar fallas y darle el mantenimiento necesario lo que hace subir costos e invertir más tiempo del que se estima, es por lo cual esta investigación dará a conocer a fondo la metodología Scrum/Ágil.

1.11.1 Propuesta de la investigación Dar a conocer a fondo como se da la implementación de la metodología Scrum en una empresa de tecnología, este documento de investigación se orientará a todas aquellas personas interesadas al momento de tener la idea de emprender en el campo de las tecnologías. Además de conocer los métodos que existen para llevarla a cabo, con la finalidad de trabajar con mayor flexibilidad.

1.11.2 Objetivos de la investigación Este trabajo de investigación se ha planeado con distintos objetivos que tienen el

propósito de que la metodología Scrum tenga una mejor difusión. Los objetivos de

esta investigación son los siguientes:

Dar a conocer la metodología Scrum.

Compartir la experiencia con la metodología Scrum.

1.11.3 Objetivo General Para que una empresa pueda tener flexibilidad a la hora de llevar a cabo sus procesos es necesario contar con la implementación de una metodología ágil es por eso que el objetivo general de esta investigación es:

La difusión de como la implementación de la metodología Scrum ayuda a las empresas a tener mejores resultados en sus proyectos.

1.11.4 Objetivos particulares Característicamente las empresas adoptan metodologías y las usan por tiempos indefinidos y se limitan al cambio es por eso que en esta investigación los objetivos particulares son:

Adaptación a la metodología Scrum y dejar atrás a las metodologías tradicionales.

18

Mostrar los beneficios que se obtienen implementando la metodología Scrum.

Trabajar implementando la metodología Scrum para así dar a conocer los procesos ya teniendo experiencia en la implementación de esta.

Mostrar resultados de como ayuda la implementación de la metodología Scrum a una empresa.

1.11.5 Preguntas de la investigación Las preguntas que principalmente se estarán contestando en esta investigación son

las siguientes:

¿Qué es la metodología Scrum? ¿Cuáles son las ventajas de la metodología Scrum sobre las otras metodologías de desarrollo de software? ¿Cómo se implementa la metodología Scrum en una empresa? ¿En qué ayuda la implementación de la metodología Scrum en una empresa?

1.11.6 Hipótesis La falta de la implementación de una metodología para el desarrollo de

software, genera atrasos o un mal cálculo del tiempo estimado en un proyecto

de tecnología. Obteniendo como resultado, que una empresa tenga un mal

desempeño, ocasionado por falta de flexibilidad para hacer cambios a

tiempo, debido a que metodologías tradicionales como la de cascada se

esperan hasta la fase final para corregir errores.

1.11.7 Limitaciones y supuestos

Para que se lleve a cabo la implementación de la metodología Scrum es necesario

contar con un líder y un equipo que lo respalde para que la implementación tenga

éxito y muestre buenos resultados.

La implementación de la metodología Scrum es de gran ayuda en las empresas

debido a que en el desarrollo de software con esta metodología es más flexible que

al usar otro tipo de metodologías como los son la de cascada o la de espiral.

19

1.11.8 Relevancia Al cumplirse esta investigación cualquier lector que tenga acceso a ella tendrá una

nueva perspectiva de cómo se lleva a cabo un proyecto en una empresa, además

de los procesos que se siguen en la metodología Scrum, también quienes formar

parte de ella. Hay que destacar que al conocer esta metodología en esta

investigación, el lector se dará cuenta de los beneficios que tiene el implementar la

metodología Scrum en comparación con el uso de las metodologías de cascada o

espiral.

20

Capítulo II

Marco teórico

21

En este capítulo se analizará el software y sus inicios, evolución y lo que hoy en día

se ha convertido y la importancia que tiene.

2 Software Muchas persona asocian el termino Software con los programas de computadora.

Sin embargo, la definición más amplia donde el software no son los programas, sino

todos los documentos asociados a la configuración de datos que se necesitan para

hacer que estos programas operen de manera correcta. Por lo general, un sistema

de software consiste en diversos programas independientes, archivos de

configuración que se utilizan para ejecutar estos programas, un sistema de

documentación que describe la estructura del sistema, la documentación para el

usuario que explica cómo utilizar el sistema y sitios web que permitan a los usuarios

a descargar la información de productos recientes. Los ingenieros de software se

concentran en el desarrollo de productos de software, es decir, software que se

vende a un cliente.

Existen tipos de productos de software:

Productos genéricos

Son sistemas aislados producidos por una organización de desarrollo y que

se vendan al mercado y que se venden al mercado abierto a cualquier cliente

que le sea posible comprarlos.

Productos personalizados(o hechos a la medida)

Son sistemas requeridos por un cliente en particular, un contratista de

software desarrolla el software especialmente para ese cliente.

Una diferencia importante entre estos diferentes tipos de software es que, en los

productos genéricos, la organización que desarrolla el software controla su

especificación. La especificación de los de los productos personalizados, por lo

general, es desarrollada y controlada por la organización que compra el software.

[1]

2.1 Importancia del software La palabra software se refiere a las instrucciones que se incorporan a un sistema

informático para que este lleve a cabo una determinada función. El campo que se

esconde detrás es inmenso, porque engloba desde pequeñas aplicaciones para

llevar a cabo tareas muy específicas, a archiconocidos sistemas operativos con

capacidad para realizar miles de funciones.

El software es imprescindible para cualquier sistema informático o basado en

informática, puesto que sin él, este no funcionaría. Es el software quien da las

órdenes, quien indica que debe hacer cada máquina con sus elementos, cuando y

22

como. Un ordenador sin software sería simplemente un conjunto de chips, cables,

periféricos e interruptores totalmente inerte y sin función alguna. Es el software

quien ordena todo ese material, lo reconoce, le asigna una función según sus

características, y permite que funcione todo en su conjunto. Imaginemos una

orquesta tocando una pieza: el director sería la parte central del ordenador, los

músicos, el hardware periférico, y el software, la partitura de esa pieza. Está claro

que sin partitura no habrá música, pero también que sin músicos tampoco.

Continuando el símil, si en el caso de las partituras son los compositores quienes

las crean, en el caso de la informática son los programadores, quienes diseñan el

software para que cumpla con la función deseada.

En grandes programas, como por ejemplo los sistemas operativos, existen equipos

de cientos y miles de personas que trabajan en ellos durante largos periodos de

tiempo, sobre todo debido a su complejidad. Y de hecho empresas como Apple,

Microsoft, Google son básicamente empresas dedicadas al software y su desarrollo,

lo cual nos permite hacernos una pequeña idea del valor del software. Contra esta

corriente de grandes empresas que obtienen beneficio económico del software, hay

una corriente mundial que aboga por el software libre o gratuito, pero bueno, esa es

otra historia.

En pocas palabras, el software controla al hardware, aunque evidentemente sin este

último el software tampoco puede funcionar. De hecho cada software suele ser

específico para determinados equipos o máquinas. Si intentas ejecutar un software

para un conmutador de coches en un ordenador, no encontrará ni los mandos de

las puertas, ni los eleva vidrios, ni el aire acondicionado, y por tanto te dará errores,

si es que llega a ejecutarse. Un software adecuado es de vital importancia, pues,

para llevar a cabo la tarea que se quiere hacer de modo correcto. Cuando un

software no funciona bien en un determinado hardware, se habla de

incompatibilidad entre ambos.

La importancia del software radica también en que permite una comunicación entre

el usuario y la máquina, e incluso una interacción entre ambos. Otro ejemplo muy

sencillo; ahora mismo, escribiendo esto, al pulsar un botón del teclado, se activa

automáticamente una serie de órdenes, que permiten identificar que botón se ha

pulsado, traducirlo a lenguaje de máquina, mostrarlo en pantalla para el usuario y

almacenarlo. Así, el software que tengo instalado en mi ordenador se ha ocupado

de todo eso ante un simple gesto mío. Esa es precisamente otra de sus grandes

funciones: facilitar las tareas a los usuarios. Gracias al software se pueden ejecutar

tareas que hace décadas hubiesen llevado años de trabajo, y ello ha supuesto sin

lugar a dudas una revolución mundial en la sociedad moderna. Está tan presente

en nuestra vida cotidiana, que muchas veces pasa desapercibido que no sólo hay

programas y aplicaciones en los ordenadores, sino que la mayor parte de los

electrodomésticos, coches, mandos… llevan su propio software (más o menos

simple) incorporado. [2]

23

2.1.1 La Importancia del Software para la Sociedad El desarrollo de Software, es posiblemente una de las áreas que van avanzando a

pasos agigantados con el paso del tiempo, pero también con mayor discreción, si

bien es cierto que hoy la sociedad puede disfrutar de una gran cantidad

de software con muchísimas funciones, esta nunca se percata de la existencia del

desarrollo del software como tal, para la sociedad el software hoy en día es

importante para poder subsistir, sin importar de donde provenga. Incluso las personas

están tan acostumbrados a hacer uso de diversos tipos de software, que sin ellos el cambio

sería sumamente radical en sus vidas. [3]

2.1.2 Beneficios del Software para Sociedad Hoy en día un teléfono celular puede realizar funciones que jamás imaginaste, puedes automatizar tu vida, programar alertas para saber que hacer a cada hora y que no se te olvide nada, incluso puedes comunicarte con personas en cualquier parte del mundo de forma gratuita, ¿Gracias a qué? Al desarrollo del software móvil que se viene generando desde principios de la década. [3]

2.1.3 ¿Porque se ha vuelto tan importante? La importancia del Software para la sociedad, radica en el uso que las personas le den, no se trata solamente de traer juegos nuevos en un dispositivo de unos miles de pesos, se habla de optimizar tareas, incrementar ganancias, aumentar ingresos, optimizar tiempos, hacer la vida más fácil, gracias a que el software hoy en día nos permite hacer infinidad de cosas. [3]

2.1.4 El uso del Software para la Educación La educación es una de las áreas que se ha visto muy beneficiada con el uso del software, la sociedad actual puede disfrutar de educación a distancia, aprender cosas por internet, obtener títulos profesionales estudiando desde casa, Licenciaturas y Maestrías online, debido principalmente al software de calidad que se ha desarrollado, permitiendo la interconexión del mundo entero, haciendo no solamente que la educación llegue a lugares donde nunca antes había llegado, sino además permitiendo el crecimiento social. [3]

2.2 Crisis del software una vez que se tiene claro lo que es el software y sus características, seguiremos

por lo que ha pasado a lo largo del tiempo y cómo ha evolucionado en base a la

crisis que se le presentado.

La crisis del software se fundamentó en el tiempo de creación de software, ya que

en la creación del mismo no se obtenían los resultados deseados, además de un

gran costo y poca flexibilidad.

Es un término informático acuñado en 1968, en la primera conferencia organizada

por la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de

24

la ingeniería de software. El término se adjudica a F. L. Bauer, aunque previamente

había sido utilizado por Edsger Dijkstra en su obra The Humble Programmer.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas

libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas

son, entre otras, la complejidad que supone la tarea de programar, y los cambios a

los que se tiene que ver sometido un programa para ser continuamente adaptado a

las necesidades de los usuarios.

Además, no existen todavía herramientas que permitan estimar de una manera

exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para

desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea

posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será

necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del

mismo modo, en muchas ocasiones el personal asignado a un proyecto se

incrementa con la esperanza de disminuir el plazo de ejecución.

Englobó a una serie de sucesos que se venían observando en los proyectos de

desarrollo de software:

Los proyectos no terminaban en plazo.

Los proyectos no se ajustaban al presupuesto inicial.

Baja calidad del software generado.

Software que no cumplía las especificaciones.

Código inmantenible que dificultaba la gestión y evolución del proyecto.

Aunque se han propuesto diversas metodologías para intentar subsanar los

problemas mencionados, lo cierto es que todavía hoy no existe ningún método que

haya permitido estimar de manera fiable el coste y duración de un proyecto antes

de su comienzo. [4]

El término “Crisis del Software” fue acuñado a principios de los años 70, cuando la

ingeniería de software era prácticamente inexistente. El término expresaba las

dificultades del desarrollo de software frente al rápido crecimiento de la demanda

por software, de la complexidad de los problemas a ser resueltos y de la inexistencia

de técnicas establecidas para el desarrollo de sistemas que funcionaran

adecuadamente o pudieran ser validados.

La percepción de que esta crisis existía empezó a mediados de los años 60. Una

de las primeras referencias al término, y de las más notables, fue hecha por

E.W.Dijkstra, en el discurso que pronunció durante la entrega del premio Turing en

1972. [5]

25

2.2.1 Causas de la crisis del software Durante finales de los años 50 y principios de los 60, la potencia computacional de

las maquinas era bastante limitada. Es por esto que los programas que se

desarrollaban eran “simples” desde el punto de vista actual. Seguían un proceso de

desarrollo bastante artesanal, sin una metodología o un camino a seguir para su

desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el

desarrollo de Software.

Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma

considerable. Empezaron a aparecer los lenguajes de programación de alto nivel, y

las maquinas necesitaban programas mucho más complejos de los desarrollados

hasta la época. En definitiva, fue un salto tremendo en cuanto a potencial de

hardware, que no fue acompañado por un salto en el desarrollo de software.

En esta época, se empezó a concebir el Software como producto, y se empezaron

a desarrollar algunos proyectos para que funcionaran en las máquinas de la época.

Pero aparecieron importantes problemas, los productos excedían la estimación de

costes, había retrasos en las entregas, las prestaciones no eran las solicitadas, el

mantenimiento se hacía extremadamente complicado y a veces imposible, las

modificaciones tenían un coste prohibitivo en resumen, se desarrollaba software de

mala calidad, ya que la técnica utilizada para desarrollar pequeños programas para

maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este

software acababa en el olvido. Como ejemplo, en el gráfico (Ilustración 2.1) del año

1979, en el que se recoge la inversión en desarrollo de sistemas software en ese

año ($6.8 Millones), y como acabó ese software.

Una de las principales causas de todo esto, si no la principal, era el enfoque dado

al proceso de desarrollo de software, el cual era malo e incluso a veces era

inexistente. En este proceso, solo ¼ del tiempo de desarrollo se dedicaba a las fases

de análisis, diseño, codificación y pruebas, y más de ¾ del tiempo se dedicaba a

correcciones y mantenimiento. Es evidente que dedicándole solo ¼ del tiempo a las

primeras fases, se arrastran errores graves, sobre todo procedentes de las fases de

análisis y diseño, lo que dificultaba muchísimo la implementación, produciendo

constantes paradas y retrocesos para revisar este análisis/diseño.

Para que nos hacer una idea, el conjunto de las fases de análisis y diseño abarcaban

el 8% del tiempo total de desarrollo de software. Además casi el 80% de los errores

se producían en estas dos fases, con lo que se incrementaba el coste de corrección

de errores conforme evolucionaban las fases de manera bestial. Con estos

indicadores estaba claro que algo estaba fallando y que el proceso de desarrollo de

software necesitaba un cambio radical. [5]

26

Ilustración 2.1. Gráfico de 1979

2.2.2 Ingeniería del software, la solución. Porque no hay problema que no tenga solución, viendo el camino directo al

precipicio que estaba llevando el desarrollo de software, había que tomar medidas

para solucionarlo. Y esas medidas se llamaron “Ingeniería del Software”.

La Ingeniería del Software, según R.Pressman, es “Una disciplina que integra

métodos, herramientas y procedimientos para el desarrollo de SW de

computador”. Es decir, es una disciplina que intenta racionalizar el proceso de

desarrollo de software y establecer unas pautas a seguir para el desarrollo que

minimicen tiempo, esfuerzo, y coste de desarrollo y maximicen la calidad del

software. (Más sobre ingeniería de software adelante)

Después de esta crisis, se intentaron establecer estas pautas, aplicándolos a

algunos proyectos y aumentando la inversión. En 1991 se hizo un estudio para

comprobar los resultados de la aplicación de estos métodos, y los resultados fueron

bastante buenos. El 52% de los proyectos se terminaron con éxito, frente al 2% del

año 1979 y el 31,1% se terminó con algunas modificaciones respecto a lo acordado

inicialmente, frente al 3% del año 1979. Pero el resultado más espectacular se

obtuvo en los proyectos abandonados. En 1991 sólo se abandonaron el 16,2% de

proyectos, frente al casi 76% del año 1979. Una reducción increíble de casi el 60%

que no hacía más que confirmar la bondad de estos métodos aplicados al proceso

de desarrollo de software. Había nacido una nueva disciplina, la Ingeniería del

Software,

Para hacer una idea más concreta de lo que abarca la Ingeniería del Software (cosa

que nos ayudará a entender porque fue la solución a esta Crisis del Software),

debemos de centrar nuestra explicación en que la Ingeniería de Software busca

27

principalmente software de calidad, que es aquel software que cumple los requisitos

funcionales y de rendimiento establecidos previamente y consta de unos estándares

de desarrollo bien documentados. Además todos sus factores de calidad deben

cumplirse y tener un buen seguimiento durante todo el proceso de desarrollo

(características operativas, capacidad de soportar cambios y adaptabilidad a

nuevos entornos). Y por último, se incorporan al proceso nuevos modelos de

desarrollo y modificación del ciclo de vida, nuevos paradigmas de programación,

etc. Que hacen que el desarrollo de software sea mucho más metodológico y

estructurado, disminuyendo así notablemente fallos y correcciones costosas. [5]

Para continuar con el siguiente tema esta imagen que resume en unas pocas

imágenes la gran problemática del desarrollo del software.

Ilustración 2.2. Caso de ingeniería de software.

2.2 Ingeniería de software Una vez que se tiene claro cuál fue la solución a la crisis del software hay que

conocer más sobre dicha solución la cual es la ingeniería de software.

La ingeniería de software es una disciplina de la ingeniería que comprende todos

los aspectos de la producción de software desde las etapas iniciales de la

especificación del sistema, hasta el mantenimiento de éste después de que se

utiliza. En esta definición existen dos frases claves:

28

Disciplina de la ingeniería

Los ingenieros hacen que las cosas funcionen. Aplican teorías, métodos y

herramientas donde sean convenientes, pero las utilizan de forma selectiva

y siempre tratando de descubrir soluciones a los problemas, aun cuando no

existan teorías y métodos aplicables para resolverlos. Los ingenieros también

saben que deben trabajar con restricciones financieras y organizacionales,

por lo que buscan soluciones tomando en cuenta estas restricciones.

Todos los aspectos de solución de software

La ingeniería del software no solo comprende los procesos técnicos del

desarrollo de software, sino también con actividades tales como la gestión de

proyectos de software y el desarrollo de herramientas, métodos y teorías de

apoyo a la producción de software.

En general, los ingenieros de software adaptan un enfoque sistemático y organizado

en su trabajo, ya que es la forma más efectiva de producir software de alta calidad.

Sin embargo, aunque la ingeniería consiste en seleccionar el método más apropiado

para un conjunto de circunstancias, un enfoque más informal y creativo de desarrollo

podría ser más efectivo en algunas circunstancias. [1]

2.2.1 Proceso del software Un proceso de software es un conjunto de actividades y resultados asociados que

producen un producto de software. Estas actividades llevadas a cabo por los

ingenieros de software. Existen cuatro actividades fundamentales de procesos que

son comunes para todos los procesos del software. Estas actividades son:

Especificación del software donde los clientes e ingenieros definen el

software a producir y las restricciones sobre su operación.

Desarrollo del software donde el software se diseña y se programa.

Validación del software donde el software se válida para asegurar que es lo

que el cliente requiere.

Evolución del software donde el software se modifica para adoptarlo a los

cambios requerido por el cliente.

Diferentes tipos de sistemas necesitan diferentes procesos de desarrollo. [1]

29

2.2.2 ¿Qué es un modelo de procesos de software? Un modelo de procesos de software es una descripción simplificada de un proceso

del software que presenta una visión de ese proceso. Estos modelos pueden incluir

actividades que son parte de los procesos y productos de software y el papel de las

personas involucradas en la ingeniería de software. Algunos ejemplos de estos tipos

de modelos que se pueden producir son:

Un modelo de flujo de trabajo

Muestra la secuencia de actividades en el proceso de actividades en el

proceso junto con sus entradas, salidas y dependencias. Las actividades en

este modelo representan acciones humanas.

Un modelo de flujo de datos o de actividad

Representa el proceso como un conjunto de actividades, cada una de las

cuales realiza alguna transformación en los datos, muestra como entrada en

el proceso, tal como una especificación, se transforma en una salida, tal

como un diseño. Pueden representar transformaciones llevadas a cabo por

las personas o por las computadoras.

un modelo de rol/acción

Representa los roles de las personas involucradas en el proceso del software

y las actividades de las que son responsables. [1]

2.2.3 Atributos de un buen software Así como los servicios que proveen, los productos de software tienen un cierto

número de atributos asociados que reflejan la calidad de ese software. Estos

atributos no están directamente relacionados con los que software hace. Más bien,

reflejan su comportamiento durante su ejecución y en la estructura y organización

del programa fuente y en la documentación asociada. Ejemplos de estos atributos

(algunas veces llamados atributos no funcionales) son el tiempo de respuesta del

software a una pregunta del usuario y la comprensión del programa fuente.

El conjunto específico de atributos que se espera de un sistema de software

depende obviamente de su aplicación. Por lo tanto, un sistema bancario debe ser

seguro, un juego interactivo debe tener capacidad de respuesta, un interruptor de

un sistema telefónico debe ser fiable, etcétera. Esto se generaliza en el conjunto de

atributos que se muestran en la tabla de componentes del método, la cual tiene las

características de un sistema de software bien diseñado. [1]

30

Tabla 2.1. Atributos de un buen software

2.2.4 Código de ética y práctica profesional de la ingeniería de

software Los ingenieros de software deberán comprometerse a convertir el análisis,

especificación, diseño, implementación, pruebas y mantenimiento de software en

una profesión respetada y benéfica. De acuerdo a su compromiso con la salud,

seguridad y bienestar social, los ingenieros de software deberán sujetarse a los

ocho principios siguientes:

Sociedad*.

Cliente*.

Producto*.

Juicio*.

Administración*.

Profesión*.

Colegas*.

Personal*.

*Para saber más sobre los principios, consulta la página correspondiente a esta referencia. [6]

2.2.5 Fundamentos que afronta la ingeniería de software En el siglo XXI, la ingeniería de software afronta tres retos fundamentales:

Componente Descripción Ejemplos

Descripción del modelo del sistema

Descripciones de los modelos del sistema que desarrollará y la notación utilizada para definir

estos modelos.

Modelos de objetos, de flujo de datos, de máquina de estado,

etcétera.

Reglas Restricciones que siempre implican a los modelos de

sistemas

Cada entidad de un modelo de sistema debe tener un nombre

único.

Recomendaciones Heurística que caracteriza una buena práctica de diseño en este método. Seguir como resultado

un modelo del sistema bien organizado.

Ningún objeto debe tener más de siete subobjetos asociados a el

Guías en el proceso Descripciones de las actividades que deben seguirse para

desarrollar los modelos del sistema y la organización de

estas actividades.

Los atributos de los objetos deben documentarse antes de

definir las operaciones asociadas a un objeto.

31

El reto de la heterogeneidad

Cada vez más, se requiere que los sistemas operen como sistemas

distribuidos en redes que incluyen diferentes tipos de computadoras y con

diferentes clases de sistemas de soporte. A menudo es necesario integrar

software nuevo con sistemas heredados de viejos escritos en diferentes

leguajes de programación. El reto de la heterogeneidad es desarrollar

técnicas para contraer software confiable que sea lo suficientemente flexible

para adecuarse a esta heterogeneidad.

El reto de la entrega

Muchas técnicas tradicionales de ingeniería de software consumen tiempo.

El tiempo que estas consumen es para producir un software de calidad. Sin

embargo, los negocios de hoy en día deben tener una gran capacidad de

respuesta y cambiar con mucha rapidez. Su software de soporte también

debe cambiar con la misma rapidez. El reto de la entrega es reducir los

tiempos de entrega para sistemas grandes y complejos sin comprometer la

calidad.

El reto de la confianza

Puesto que el software tiene una relación con todos los aspectos de nuestra

vida, es esencial que se pueda confiar en él. Esto es especialmente

importante en sistemas remostos de software a los que se accede a través

de páginas web o de interfaces de servicio web. El reto de la confianza es

desarrollar técnicas que demuestren que los usuarios pueden confiar en el

software.

Por supuesto, estos no son independientes. Por ejemplo, es necesario hacer

cambios rápidos en sistemas heredados para proveerlos de una interfaz de servicio

web. Para tratar estos retos, se necesitan nuevas herramientas y técnicas, así como

formas innovadoras de combinación y uso de métodos de ingeniería del software

existentes. [1]

2.3 Metodologías de desarrollo del software En esta sección se abordarán las metodologías que han surgido a lo largo de la vida

del software y que son las más utilizadas desde que se desarrollaron.

32

El concepto de metodología, dentro de la Ingeniería del Software es, sin duda, uno

de los más oscuros y que más confusión produce tanto en estudiantes como en

profesionales involucrados en procesos de desarrollo de software.

Tanto es así, que en muchos proyectos de desarrollo (no todos, por supuesto), la

aplicación de una metodología brilla por su ausencia, siendo éste un concepto casi

desconocido.

Además, la constante innovación tecnológica hace que cada vez sea necesaria la

aplicación de nuevas metodologías adaptadas a los nuevos tiempos y, sin embargo,

siguen figurando en los libros de texto viejas metodologías pensadas para viejos

problemas, cosa que no sería necesariamente mala si las nuevas metodologías

tuviesen también su lugar, pero a menudo no es así.

Afortunadamente, los tiempos van cambiando (aunque no de la misma manera para

todo el mundo). La informática va madurando y tanto algunos profesionales de las

tecnologías de la información como algunos de sus clientes se van dando cuenta

de que se hace necesario seguir unas ciertas pautas predefinidas en el desarrollo

del software de calidad, es decir, llevar un comportamiento metódico en pocas

palabras seguir una metodología.

En todo este tema sólo hay una cosa clara, la ausencia de metodología en el

desarrollo de un proyecto de software garantiza con seguridad también la ausencia

de calidad. [7]

Las metodologías de desarrollo de software también se describen como el conjunto

de herramientas, técnicas, procedimientos y soporte documental para el diseño de

Sistemas de información. En Ingeniería de software cuando se habla de desarrollo

de software se habla de desarrollo de programas y por lo tanto se considera como

una tarea de ingeniería, en el cuál se debe ejecutar una serie de fases, etapas para

obtener un programa que funcione de acuerdo con métodos ya establecidos en

otras disciplinas de ingeniería. Las actividades que los ingenieros de software

realizan se encuentran asociadas a un proceso de software donde intervienen

diferentes elementos (fases, actividades, producto, roles, agentes) que permiten la

definición del software a producir (producto), el desarrollo o el diseño del software,

la validación del software tanto lo interno (requerimientos específicos) como lo

externo (expectativas del cliente), y la evolución del software donde se modifica para

adaptarlo a los cambios.

Por otro lado, Sommerville define que “un método de ingeniería de software es un

enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la

producción de software de alta calidad de una forma costeable”, cabe destacar que

para usar este enfoque se debe manejar conceptos fundamentales tales como;

procesos, métodos, tareas, procedimientos, técnicas, herramientas, productos,

entre otros.

33

Particularmente, una metodología se basa en una combinación de los modelos de

proceso genéricos para obtener como beneficio un software que solucione un

problema. Adicionalmente una metodología debería definir con precisión los

artefactos, roles y actividades, junto con prácticas, técnicas recomendadas y guías

de adaptación de la metodología al proyecto. Sin embargo, la complejidad del

proceso de creación de software es netamente dependiente de la naturaleza del

proyecto mismo, por lo que el escogimiento de la metodología estará acorde al nivel

de aporte del proyecto, ya sea pequeño, mediano o de gran nivel.

2.3.1 EVOLUCION Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron

ciertos métodos que permitían llevar a producir un buen proyecto, estas

metodologías aplicadas eran simples, solo se preocupaban por los procesos mas

no por los datos, por lo tanto los métodos eran desarrollados hacia los procesos. El

modelo de procesos predominaba para los años 60 y consistía en codificar y corregir

(Code-and-Fix), si al terminar se descubría que el diseño era incorrecto, la solución

era desecharlo y volver a empezar, este modelo implementaba el código y luego se

pensaba en los requisitos, diseño, validación y mantenimiento. Los principales

problemas del modelo de procesos son:

Los arreglos se hacen costosos, después de tantas correcciones el código

tenía una mala estructura.

El software no se ajusta a las necesidades del usuario, por lo que es

rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y

modificar.

En la década de los setenta empezó a tomar la importancia de los datos, y para

solucionar sistemas complejos empezó el análisis por partes o etapas, se introducen

la planeación y administración. El modelo en cascada surge como respuesta al

modelo de procesos, este modelo tiene más disciplina y se basa en el análisis,

diseño, pruebas y mantenimientos.

La década de los ochenta es la época marcada por las metodologías dirigida a datos

cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar

los objetos en sí como unidades de información. Para los años 90 se quiere dar

respuesta al entorno siempre cambiante y en rápida evolución en que se han de

desarrollar los programas informáticos, lo cual da lugar a trabajar en ciclos cortos

(como mini-proyectos) que implementan una parte de las funcionalidades, pero sin

perder el rumbo general del proyecto global.

Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en

lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos

durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos

34

van buscando minimizar riesgos y, puesto que los errores más perjudiciales se

producen en los primeros pasos, se comienza ya desde la fase más general del

estudio por analizar los riesgos que significa seguir con las siguientes fases del

desarrollo.

Las metodologías más utilizadas a nivel mundial en orden cronológico:

Década de los 80s

o Structured Systems Analysis and Design Methodology (SSADM) desde

1980.

o Structured Analysis and Design Technique (SADT) desde 1980.

o Ingeniería de la Información (IE/IEM) desde 1981.

Década de los 90s

o Rapid Application Development (RAD) desde 1991.

o Virtual Finite State Machine (VFSM) desde 1990s.

o Dynamic Systems Development Method desarrollado en UK desde 1995.

o Rational Unified Process (RUP) desde 1999.

Año 2000 en adelante

o Extreme Programming (XP) desde 1999.

o Enterprise Unified Process (EUP) extensiones RUP desde 2002.

o Constructionist Design Methodology (CDM) desde 2004 por Kristinn R.

Thórisson.

o Agile Unified Process (AUP) desde 2005 por Scott Ambler. [8]

2.4 Metodologías clásicas

2.4.1 Cascada En Ingeniería de software el desarrollo en cascada, también llamado modelo en

cascada, es el enfoque metodológico que ordena rigurosamente las etapas

35

del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa

debe esperar a la finalización de la etapa anterior.

Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un

sistema mayor el trabajo comienza estableciendo los requisitos de todos los

elementos del sistema y luego asignando algún subconjunto de estos requisitos al

software.

Ilustración 2.3. Etapas metodología de cascada [10]

Etapas de la metodología de cascada

Análisis de los requisitos del software

El proceso de recopilación de los requisitos se centra e intensifica

especialmente en el software. El ingeniero de software (Analistas) debe

comprender el ámbito de la información del software, así como la función, el

rendimiento y las interfaces requeridas.

Diseño

El diseño del software se enfoca en cuatro atributos distintos del programa:

la estructura de los datos, la arquitectura del software, el detalle

procedimental y la caracterización de la interfaz. El proceso de diseño

traduce los requisitos en una representación del software con la calidad

requerida antes de que comience la codificación.

Codificación

36

El diseño debe traducirse en una forma legible para la máquina. El paso de

codificación realiza esta tarea. Si el diseño se realiza de una manera

detallada la codificación puede realizarse mecánicamente.

Prueba

Una vez que se ha generado el código comienza la prueba del programa. La

prueba se centra en la lógica interna del software, y en las funciones

externas, realizando pruebas que aseguren que la entrada definida produce

los resultados que realmente se requieren.

Mantenimiento

El software sufrirá cambios después de que se entrega al cliente. Los

cambios ocurrirán debido a que hayan encontrado errores, a que el software

deba adaptarse a cambios del entorno externo (sistema operativo o

dispositivos periféricos), o debido a que el cliente requiera ampliaciones

funcionales o del rendimiento.

Desventajas

- Los proyectos reales raramente siguen el flujo secuencial que propone el

modelo, siempre hay iteraciones y se crean problemas en la aplicación del

paradigma.

- Normalmente, es difícil para el cliente establecer explícitamente al

principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene

dificultades en acomodar posibles incertidumbres que pueden existir al

comienzo de muchos productos.

- El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto,

no estará disponible una versión operativa del programa. Un error importante

no detectado hasta que el programa esté funcionando puede ser desastroso.

[9]

2.4.3 Evolutivo Propuesto por Mills en 1980. Sugirió el enfoque incremental de desarrollo como una

forma de reducir la repetición del trabajo en el proceso de desarrollo y dar

oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir

experiencia con el sistema. Surge porque en los primeros desarrollos se podía

esperar largo tiempo hasta que el software estuviese listo. Las reglas del negocio

de hoy no lo permiten.

Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación,

desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de

especificaciones abstractas. Éste se refina basándose en las peticiones del cliente

para producir un sistema que satisfaga sus necesidades.

37

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de

exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos

por parte del cliente o del usuario final. Las fases de especificación, desarrollo y

validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

Desarrollo exploratorio

El objetivo del proceso es trabajar con el cliente para explorar sus

requerimientos y entregar un sistema final. El desarrollo empieza con las

partes del sistema que se comprenden mejor. El sistema evoluciona

agregando nuevos atributos propuestos por el cliente.

Prototipos desechables

El objetivo del proceso de desarrollo evolutivo es comprender los

requerimientos del cliente y entonces desarrollar una definición mejorada de

los requerimientos para el sistema. El prototipo se centra en experimentar

con los requerimientos del cliente que no se comprenden del todo. [9]

2.4.5 Prototipos Este modelo consiste en un procedimiento que permite al equipo de desarrollo

diseñar y analizar una aplicación que representa el sistema que sería implementado

(McCracken y Jackson, 1982). Dicha aplicación, llamada prototipo, está compuesta

por los componentes que se desean evaluar. [9]

El software del prototipo se crea, prueba y refina.

El paradigma de construcción del prototipo puede ser conducido con uno o dos

objetivos en mente:

El propósito del prototipado es establecer un conjunto de requerimientos formales

que pueden luego ser traducidos en la producción de programas mediante el uso

de métodos y técnicas de ingeniería de programación, o

El propósito de la construcción del prototipo es suministrar un continuo que pueda

conducir al desarrollo evolutivo de la producción del software. Ambos métodos

tienen sus méritos y ambos crean problemas.

38

Ilustración 2.4. Flujo del prototipo

Etapas del modelo de prototipos

Investigación preliminar.

Colecta y refinamiento de los requerimientos y proyecto rápido:

Análisis y especificación del prototipo.

Diseño y construcción del prototipo.

Evaluación del prototipo por el cliente.

Renacimiento del prototipo.

Diseño técnico.

Programación y test.

Operación y mantenimiento.

Ventajas

Este modelo es útil cuando el cliente conoce los objetivos generales para el

software, pero no identifica los requisitos detallados de entrada,

procesamiento o salida.

También ofrece un mejor enfoque cuando el responsable del desarrollo del

software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de

un sistema operativo o de la forma que debería tomar la interacción

humano-máquina.

39

La construcción de prototipos se puede utilizar como un modelo del proceso

independiente, se emplea más comúnmente como una técnica susceptible

de implementarse dentro del contexto de cualquiera de los modelos del

proceso expuestos. Sin importar la forma en que éste se aplique, el

paradigma de construcción de prototipos ayuda al desarrollador de software

y al cliente a entender de mejor manera cuál será el resultado de la

construcción cuando los requisitos estén satisfechos.

Desventajas

- El usuario tiende a crearse unas expectativas cuando ve el prototipo de

cara al sistema final. A causa de la intención de crear un prototipo de forma

rápida, se suelen desatender aspectos importantes, tales como la calidad y

el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos

a reconstruirlo una vez que el prototipo ha cumplido su función.

- Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le

llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas

elecciones pasen a formar parte del sistema final.[9]

Referente a los que son las metodologías clásicas demostraron ser muy útiles en lo

que fue los inicios de la industria del software, sin embargo en la actualidad no se

adaptan o no son muy funcionales en nuevos proyectos de software, es por eso que

hoy en día se han desarrollado metodologías que se adaptan a los nuevos proyectos

que se desarrollan con una flexibilidad mayor que con las que cuentan las

metodologías clásicas, las cuales se idearon para que el desarrollo del software sea

más agiles las cuales se sabrá más en la siguiente sección.

40

2.5 Metodologías Ágiles El desarrollo ágil de software son métodos de ingeniería del software basados en el

desarrollo iterativo e incremental, donde los requerimientos y soluciones

evolucionan mediante la colaboración de grupos auto-organizados y

multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza

riesgos desarrollando software en lapsos cortos. El software desarrollado en una

unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro

semanas. Cada iteración del ciclo de vida incluye:

Planificación

Análisis de requerimientos

Diseño

Codificación

Revisión

Documentación

Una iteración no debe agregar demasiada funcionalidad para justificar el

lanzamiento del producto al mercado, pero la meta es tener una «demo» (sin

errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a

evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la

documentación. La mayoría de los equipos ágiles están localizados en una simple

oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés).

La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores

de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el

software funcional es la primera medida del progreso. Combinado con la preferencia

por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados

y tratados como "indisciplinados" por la falta de documentación técnica. [11]

2.5.1Metodologías para el desarrollo ágil del software. Actualmente los negocios operan en un entorno global que cambia rápidamente.

Tienen que responder a nuevas oportunidades y mercados, condiciones

económicas cambiantes y la aparición de productos y servicios competidores. El

software es parte de casi todas las operaciones de negocio, por lo que es

fundamental que el software nuevo se desarrolle rápidamente para aprovechar

nuevas oportunidades y responder a la presión competitiva. Actualmente el

desarrollo y entrega de manera rápida son los requerimientos más críticos de los

sistemas. De hecho, muchas organizaciones están dispuestas a obtener una

pérdida en la calidad del software y en el compromiso sobre los requerimientos en

favor de una entrega rápida del software.

Los procesos de desarrollo del software basados en una completa especificación

de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al

desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se

41

descubren problemas con ellos, el diseño o implementación del sistema se tiene

que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el

tiempo un proceso en cascada convencional y el software definitivo se entrega

mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de

negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando

esté disponible el software, la razón original de su adquisición puede ser que haya

cambiado de forma radical que en realidad éste sea inútil. Dicha metodología

combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca

la satisfacción del cliente y la entrega temprana de software incremental, equipos

pequeños con alta motivación, métodos informales y una simplicidad general del

desarrollo. Los procesos de desarrollo rápido de software están diseñados para

producir software útil de forma rápida. Generalmente, son procesos interactivos en

los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.

En los años 80 y principios de los 90, existía una opinión general de que la mejor

forma de obtener un software de calidad era a través de una planificación cuidadosa

del proyecto y de la utilización de métodos de análisis y diseño soportados por

herramientas CASE (Computer Aided Software Engineering). Esta opinión venía

fundamentalmente de la comunidad de ingenieros de software implicado en el

desarrollo de grandes sistemas y que normalmente se componían de un gran

número de programas individuales. Este software era desarrollado por grandes

equipos que trabajaban para compañías diferentes y que a menudo estaban

dispersos geográficamente y trabajaban durante largos periodos de tiempo.

Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeños

y de tamaño medio, el esfuerzo invertido era tan grande que algunas veces

dominaba el proceso de desarrollo del software, es decir, se pasaba más tiempo

pensando en cómo se debía desarrollar el sistema que en cómo programar el

desarrollo y cómo hacer las pruebas pertinentes. El descontento de esto produjo

que varios desarrolladores propusieran nuevos métodos que eran más ágiles.

Aunque estos métodos se basan principalmente en la noción del desarrollo y en las

entregas incrementales, proponen procesos diferentes para alcanzar el objetivo.

En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término "ágil"

aplicado al desarrollo de software. En esta reunión participan un grupo de diecisiete

expertos de la industria del software, incluyendo algunos de los creadores o

impulsores de metodologías de software. Su objetivo fue esbozar los valores y

principios que deberían permitir a los equipos a desarrollar software rápidamente y

respondiendo a los cambios que podrían surgir a lo largo de los proyectos. Se

pretendía ofrecer una alternativa a los procesos de desarrollo de software

tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se

genera en cada una de las actividades desarrolladas. Varias de las denominadas

metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero

les faltaba una mayor difusión y reconocimiento. Tras esta reunión se creó “The

Agile Alliance”, una organización, sin ánimo de lucro, dedicada a promover los

42

conceptos relacionados con el desarrollo ágil de software y ayudar a las

organizaciones para que adopten dichos conceptos.

El punto de partida fue el manifiesto ágil, un documento que resume la filosofía

"ágil". A continuación en la tabla (Diferencias entre metodologías), se muestran las

principales diferencias de una Metodología Ágil respecto a las Metodologías

Tradicionales (llamadas peyorativamente “no ágiles” o “pesadas”). Estas diferencias

que no se refieren sólo al proceso en sí, sino también al contexto de equipo y

organización que es más favorable a cada uno de estas filosofías de procesos de

desarrollo de software. [12]

Metodologías agiles Metodologías tradicionales

Basadas en heurísticas provenientes de producción de código.

Basadas en normas provenientes de estándares seguidos por el entorno de

desarrollo.

Especialmente preparados para cambios durante el proyecto.

Cierta resistencia a los cambios.

Impuestas internamente (por el equipo de desarrollo).

Impuestas externamente.

Proceso menos controlado, con pocos principios.

Proceso mucho más controlado con numerosas políticas normas.

No existe contrato tradicional o al menos es bastante flexible.

Existe un contrato prefijo.

El cliente es parte del equipo de desarrollo. El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio.

Grupos grandes y posiblemente distribuidos.

Pocos artefactos. Más artefactos.

Pocos roles. Más roles.

Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se expresa mediante modelos.

Tabla 2.2. Diferencias entre metodologías.

Si bien la idea de participación del cliente en el proceso de desarrollo es atractiva,

el éxito dependerá de tener un cliente que esté dispuesto y lo más importante pueda

pasar tiempo con el equipo de desarrollo para así presentar a todos los implicados

del sistema, los clientes están sometidos a otras presiones y no pueden participar

plenamente en el desarrollo del software. El cliente es el punto clave, solicita los

requerimientos que se deben de incluir. Los miembros individuales del equipo

pueden no tener la personalidad propia para una participación intensa. Por lo tanto,

es posible que no se relacionen adecuadamente con los otros miembros del equipo.

Priorizar los cambios puede ser extremadamente difícil, específicamente en

sistemas en los que existen muchos implicados.

Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presión

por las agendas de entregas, los miembros del equipo no pueden tener a tiempo las

especificaciones del sistema. Por consiguiente los métodos ágiles tienen que

43

depender de contratos donde el cliente paga por el tiempo necesario para el

desarrollo del sistema en lugar de por el desarrollo de un conjunto de requerimientos

específicos. Siempre y cuando el proyecto vaya caminando en forma, esto

beneficiará tanto al cliente como al desarrollador. Todos los métodos tienen límites

y los métodos ágiles son apropiados para algunos tipos de desarrollo de sistemas.

Son los más idóneos para el desarrollo de sistemas para pequeños negocios y

medianas empresas. No son adecuados para el desarrollo de sistemas a gran

escala con equipos de desarrollo situados en diferentes lugares geográficamente

hablando ya que puede haber complejas interacciones con otros sistemas o

hardware.

Los métodos ágiles no se deben de utilizar para el desarrollo de sistemas críticos

en los que es necesario generar un análisis detallado de todos los requerimientos

del sistema para así comprender mejor sus implicaciones de seguridad o de

protección. El crecimiento de los métodos ágiles y su penetración ocurre a un ritmo

pocas veces visto en la industria: en tres o cuatro años, según el Cutter Consortium,

el 50% de las empresas define como “ágiles” más de la mitad de los métodos

empleados en sus proyectos. Algunas de las metodologías agiles más usadas en la

actualidad son [12]:

2.5.1.1Desarrollo adaptativo de software (DAS)

El desarrollo adaptativo software (DAS) lo propuso Jim Highsmith en 1998 como

una técnica para construir software y sistemas complejos. Los apoyos filosóficos

del DAS se enfocan en la colaboración humana y la organización propia del

equipo. Un enfoque de desarrollo ágil y adaptativo basado en la colaboración es "

una fuente de orden en las complejas interacciones entre disciplina e ingeniería".

El define el ciclo de vida del DAS, como se muestra en la siguiente imagen el cual

incorpora tres fases principales:

1. Especulación

En esta fase se inicia el proyecto y se conduce el ciclo adaptativo de

planeación. Este último utiliza información de inicio del proyecto, es decir, el

enunciado de la misión del cliente, restricciones del proyecto y los requisitos

básicos. Esto permite definir el conjunto de ciclos de lanzamiento que se

requerirán para el proyecto.

2. Colaboración

La gente motivada trabaja de una forma que multiplica su talento y sus salidas

creativas más allá de sus números absolutos. Este enfoque de colaboración

es un tema recurrente en todos los métodos ágiles, pero la cooperación no

es fácil. No solamente es la comunicación, o que la comunicación es parte

44

de ella. No sólo es un asunto de trabajo en equipo, aunque un equipo cuajado

es esencial para la presencia de la colaboración real. No es un rechazo al

individualismo ya que la creatividad individual representa un papel importante

en el pensamiento de colaboración. Esto es, por encima de todo, una

cuestión de confianza. Las personas que trabajan juntas deben confiar entre

sí para:

a) Criticar de forma constructiva.

b) Ayudar sin resentimientos.

c) Trabajar más duro de lo que ya lo hace.

d) Tener el conjunto de actitudes para contribuir al trabajo curso.

e) Comunicar los problemas o preocupaciones en una forma que

conduzca a la acción efectiva.

3. Aprendizaje

Como miembros de un equipo de DAS se comienzan a desarrollar los

componentes integrantes de un ciclo adaptativo, la importancia radica en el

aprendizaje y en el progreso a través de un ciclo completo. De hecho

Highsmith argumenta que los desarrolladores de software a menudo

sobreestima su comprensión (de la tecnología, el proceso y el proyecto), y

que el aprendizaje les podré ayudar a mejorar su grado de entendimiento

real. Los equipos del DAS aprenden de tres maneras:

a) Grupos enfocados.

El cliente o los usuarios finales proporcionan retroalimentación sobre los

incrementos de software que se entregan. Esto indica en forma directa la

satisfacción o la insatisfacción de las necesidades del negocio.

b) Revisiones técnicas formales.

Los miembros del equipo del DAS revisan los componentes del software

desarrollado mientras mejoran su calidad y su aprendizaje.

c) Post mortem

El equipo de DAS se vuelve introspectivo al vigilar su propio desempeño

y proceso con el propósito de aprender acerca de su enfoque y después

mejorarlo.

45

Es importante destacar que la filosofía del DAS es meritoria sin importar el modelo

del proceso empleado. La dinámica de la organización propia los equipos, la

colaboración interpersonal y el aprendizaje individual conducen a los grupos de

proyectos de software con una mayor posibilidad de éxito. [12]

Ilustración 2.5. DAS

2.5.1.2 Metodología XP programación extrema

La programación extrema XP es posiblemente el método ágil más conocido y

ampliamente utilizado. El nombre de XP fue acuñado por Beck, debido a que el

enfoque fue desarrollado utilizando las mejores prácticas del desarrollo iterativo y

con la participación extrema del cliente. La programación extrema (XP), que algunos

consideran una innovación extraordinaria y otros creen cínica En la metodología

extrema, todos los requerimientos se expresan como escenarios (llamados historias

de usuario), los cuales se implementan directamente como una serie de tareas. Los

programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de

escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando

el código nuevo se integra al sistema. Existe un pequeño espacio de tiempo entre

las entregas del sistema.

46

El desarrollo incremental se lleva a través de entregas pequeñas y frecuentes del

sistema y por medio de un enfoque que sirve para la descripción de requerimientos

basado en las historias los clientes o escenarios que pueden ser la base para el

proceso de planificación.

La participación del cliente se lleva a cabo a través del compromiso y del tiempo

completo del cliente en el equipo de desarrollo. Los colaboradores directos de los

clientes participan en el desarrollo y son los responsables de definir las pruebas

necesarias que servirán para la aceptación del sistema. El interés de las personas,

en vez de los procesos, se lleva a través de la programación en parejas, la propiedad

colectiva del código y un proceso de desarrollo sostenible que no implique excesivas

jornadas de trabajo. El cambio se lleva a cabo a través de las entregas regulares

del sistema, un desarrollo previamente probado y la integración continua. El

mantenimiento se lleva a cabo a través de una recta actualización constante para

mejorar la calidad del código y la utilización de diseños sencillos que no prevén

cambios futuros en el sistema.

En XP, los clientes están implicados en la especificación y establecimiento de

prioridades de los requerimientos del sistema. Dichos requerimientos no se

especifica como una lista de funciones requeridas en el sistema. Más bien, los

clientes del sistema son parte fundamental del equipo de desarrollo esto permite

que discutan escenarios con todos los miembros del equipo. Desarrollar

conjuntamente tarjetas de historia (story card) que recogen las necesidades del

cliente. Por ende el equipo de desarrollo intentará implementar esos escenarios en

una entrega futura del software. Un punto fundamental en la ingeniería del soporte

tradicional es que se debe de diseñar para futuros. Esto es que se deben de prever

los cambios futuros y diseñar éste de forma que tales cambios se puedan

implementar fácilmente. La metodología XP ha descartado este principio partiendo

del hecho de que diseñar para el cambio es a menudo un esfuerzo inútil. Con

frecuencia los cambios previstos nunca se materializan y realmente se efectúan

peticiones de cambios completamente diferentes. La metodología extrema aborda

este problema sugiriendo que se debe revisar constantemente el software. Esto es,

que el equipo de programación busca posibles mejoras y las implementa de forma

inmediata así lo que se busca es que siempre sea fácil de entender y cambiar

cuando simplemente nuevas historias. [12]

2.5.1.3 Metodología SCRUM

SCRUM, la cual aplica las mismas premisas conceptuales que XP pero para

resolver un problema ligeramente distinto como es el de desarrollo evolutivo de

aplicaciones. SCRUM es una metodología ágil y flexible que sirve para gestionar el

desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión

para su empresa. Se basa principalmente en construir la funcionalidad de mayor

47

valor para el cliente y en los principios de inspección continua, adaptación, auto-

gestión e innovación.

Con SCRUM el cliente es pieza fundamental en el desarrollo de software, se

entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a

iteración. Asimismo le permite en cualquier momento realinear el software con los

objetivos de negocio de su empresa, ya que puede introducir cambios funcionales

o de prioridad en el inicio de cada nueva iteración. Esta forma de trabajo promueve

la innovación, motivación y el compromiso del equipo que forma parte del proyecto,

por lo que los profesionales encuentran un ámbito propicio para desarrollar sus

capacidades. SCRUM genera algunas ventajas a diferencia de otras metodologías

agiles entre ellas:

Cumplimento de expectativas

El cliente establece sus expectativas indicando el valor que aporta a cada

requisito/historia del proyecto, el equipo los estima y con esta información el

propietario del producto establece su prioridad.

Flexibilidad a cambios

Genera una alta capacidad de reacción ante los cambios de requerimientos

generados por necesidades del cliente o evoluciones del mercado. La

metodología está diseñada para adaptarse a los cambios de requerimientos

que conllevan los proyectos complejos.

Reducción del tiempo

El cliente puede empezar a utilizar las funcionalidades más importantes del

proyecto antes de que esté finalizado por completo.

Mayor calidad del software.

La forma de trabajo y la necesidad de obtener una versión funcional

después de cada iteración, ayuda a la obtención de un software de

calidad superior.

Mayor productividad

Se consigue entre otras razones, gracias a la eliminación de la burocracia y

a la motivación del equipo que proporciona el hecho de que sean autónomos

para organizarse.

Maximiza el retorno de la inversión (ROI)

48

Producción de software únicamente con las prestaciones que aportan mayor

valor de negocio gracias a la priorización por retorno de inversión.

Predicciones de tiempos

Mediante esta metodología se conoce la velocidad media del equipo por

sprint (los llamados puntos historia), con lo que consecuentemente, es

posible estimar fácilmente para cuando se dispondrá de una determinada

funcionalidad que todavía está retrasada.

Reducción de riesgos

El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y

de conocer la velocidad con que el equipo avanza en el proyecto, permite

despejar riesgos eficazmente de manera anticipada.

La totalidad de los requerimientos a desarrollar, denominados historias de usuario

(“user stories”) son divididos en grupos en función de su prioridad relativa para luego

ser implementados en ciclos de esfuerzos relativamente cortos llamados “sprints”;

las tareas son organizadas en el equipo de tal manera que las asignaciones y

prioridades se revisan diariamente en una reunión breve llamada “SCRUM” que le

da su nombre a la metodología. En este enfoque se siguen los principales criterios

del manifiesto generando así liberaciones parciales incrementales del producto que

se está desarrollando. La evidencia es consistente que al abrazar la hoja de ruta y

comprometer las inversiones necesarias para desplegar formalmente esta

metodología también se abordan al mismo tiempo aspectos clave del despliegue de

prácticas maduras de proceso.

En tal sentido SCRUM ha sido exitosamente comparada contra los requisitos a

satisfacer para alcanzar una de evaluación bajo niveles 2 y 3 del modelo CMMI.

Demostrando así que la ejecución rigurosa satisface a la mayoría de los objetivos

necesarios que sirven para obtener estos niveles; las pocas áreas del proceso no

cubiertas directamente por no ser requeridos por SCRUM son en la práctica un

requisito para el correcto desempeño de una organización dedicada a la

construcción de software. [12]

En la siguiente imagen (Ilustración 2.6) se muestra el proceso de la metodología

Scrum.

49

Ilustración 2.6. Proceso Scrum

Y el proceso Scrum se describe a continuación:

El desarrollo se realiza de forma iterativa e incremental. Cada iteración,

denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas,

obteniendo como resultado una versión del software con nuevas prestaciones listas

para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya

construida y se añaden nuevas prestaciones priorizándose siempre aquellas que

aporten mayor valor de negocio

Product Backlog

Conjunto de requisitos denominados historias descritos en un lenguaje no

técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de

inversión considerando su beneficio y coste. Los requisitos y prioridades se

revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning

Reunión durante la cual el Product Owner presenta las historias del backlog por

orden de prioridad. El equipo determina la cantidad de historias que puede

comprometerse a completar en ese sprint, para en una segunda parte de la

reunión, decidir y organizar cómo lo va a conseguir.

Sprint

Iteración de duración prefijada durante la cual el equipo trabaja para convertir

las historias del Product Backlog a las que se ha comprometido, en una nueva

versión del software totalmente operativo.

50

Sprint Backlog

Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting

Reunión diaria de cómo máximo 15 min. En la que el equipo se sincroniza para

trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior,

que hará hoy y si hay impedimentos.

Demo y retrospectiva

Reunión que se celebra al final del sprint y en la que el equipo presenta las

historias conseguidas mediante una demonstración del producto.

Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué

procesos serían mejorables y discute acerca de cómo perfeccionarlos.

2.5.2 Beneficios de aplicar la metodología ágil. RSI superior

Cuando se lidia con proyectos múltiples y no se aplican metodologías ágil, lo normal es esperar a que se complete un proceso antes de arrancar con el segundo. Para poder lidiar con este tipo de operación de proyectos se estila buscar el cómo finalizar entregas lo más pronto posibles lo cual significa un inmenso riesgo de recorte de funcionalidades o calidad. El desarrollo con metodología ágil refuerza las entregas múltiples lo cual contra el cliente es un indicador operante y de cierto modo representaría un capital en trabajo. Como tal se refuerza más bien la lista de funcionalidades del acuerdo de entrega y en el promedio implica un enfoque en desarrollar la funcionalidad que se considere más vital para el proyecto desde el simple inicio.

El desarrollo ágil aumenta la productividad La producción de software que trabaja alrededor de las necesidades de negocio implica ingresar conocimiento multidisciplinario en etapas simultáneas. La metodología ágil sirve para enfocar la atención de los partidos por disciplina en el espacio que se les necesita e inmediatamente liberar el talento para que puedan moverse entre zonas de trabajo. Aplicar un sistema de tarea discretas contra las personas que las ejecutan simplifica la distribución de entrega de información y consecuentemente del mismo sentido de capacidad de control del mismo empleado lo cual resulta en un deseo inherente de procesar las tareas lo más simple y rápidamente posible.

Simplifica el manejo de la sobrecarga de procesos Los equipos que trabajan sobre normas y regulaciones han de validar su trabajo constantemente lo cual representa un doble sentido de trabajo. Las

51

metodologías por iteración simplifican el proceso de entrega versus validación lo cual además permite adoptar cambios sobre la marcha del alcance del proyecto.

Mejor perfil de productividad Los equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo largo de todo el ciclo de desarrollo. Si no se aplica un sistema ágil se presenta un patrón de desarrollo tipo “palo de hockey” donde la mayoría del trabajo sucede en las primeras etapas y ya que anden los equipos se van haciendo ajustes sobre el trabajo anterior. La realidad es que casi nunca suele suceder que las piezas en equipo terminan trabajando juntos de manera coherente. Los equipos ágiles que mantienen un nivel de revisión por unidades discretas de entrega de trabajo con cada iteración permiten realizar pruebas de rendimiento y sistemas desde el principio. De este modo, defectos críticos como problemas de integración se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera más productiva durante todo el ciclo de desarrollo.

Una mejor gestión del riesgo No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja con software, mientras más lejanas sean las entregas contra cliente o equipo más se maximiza el riesgo de potencial desviación de la entrega contra la definición del proyecto inicial. Las metodologías ágil permiten repasar en ciclos continuos progreso in media res de entregables y productos semi-cerrados. Cuando fallan las entregas la metodología ágil permite ajustar el ciclo de trabajo para enfocar el talento en zonas de mayor o menor riesgo a justificación de defender un proyecto en su totalidad. [15]

Una vez que ya se conoce sobre las metodologías clásicas cada vez fueron menos

viables de usar y ver cómo va evolucionando las metodologías con las hoy llamadas

metodologías agiles de las cuales lo que más destaca es su gran flexibilidad que se

adaptan más al desarrollo de software actual, en la siguiente sección se verá la

aplicación de una de ellas y como en el proceso de implementación se obtienen

resultados satisfactorios.

52

Capítulo III

Desarrollo

53

3 Implementación de la metodología Scrum Llego la hora en la que se abordará el tema principal de esta investigación, en la

cual se desarrollará como se lleva el proceso de implementar la metodología Scrum.

Se seleccionó esta metodología ya que es con la que trabaja Jaguar Labs, la cual

se aplica para llevar a cobo los proyectos de desarrollo de software y en base a la

implementación de esta ver los buenos resultados que se ven al aplicarla.

Para empezar se enlistaran los principios del manifiesto ágil:

El software que funciona es la principal medida de progreso.

Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante en forma

indefinida.

La atención continua a la excelencia técnica enaltece la agilidad.

La simplicidad como arte de maximizar la cantidad de trabajo que no se hace,

es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos que se

auto-organizan.

En intervalos regulares, el equipo reflexiona sobre la forma de ser más

efectivo y ajusta su conducta en consecuencia.

La principal prioridad es satisfacer al cliente a través de la entrega temprana

y continua de software de valor.

Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al

desarrollo. Los procesos ágiles se doblegan al cambio como ventaja

competitiva para el cliente.

Entregar con frecuencia software que funcione en periodos de un par de

semanas hasta un par de meses, con frecuencia en los periodos breves.

Las personas del negocio y los desarrolladores deben de trabajar juntos de

forma cotidiana a través del proyecto.

Construcción de proyectos entono a individuos motivados, dándoles la

oportunidad y el respaldo que necesitan y procurándoles confianza para que

realicen la tarea.

54

La forma más eficiente y efectiva es comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara.

Ya que se conocen los principios del manifiesto ágil ahora se conocerán los roles

que maneja la metodología Scrum los cuales son:

Product Owner

Cara del lado del cliente (o en su efecto el Business Analyst) entiende las

necesidades del cliente y que debe hacer el producto.

Stake Holders

Interesados o afectados por el proyecto. Usuarios y/o clientes del producto

final.

Scrum Master

Parte del equipo, Líder, Motiva, Facilita. Couch sobre Scrum. Modera y

administra las juntas. Maneja el burndown y Scrum diario.

Team Members

Determinan las tareas de cada requerimiento o user story. Autónomo, Auto-

administrado, Recomendable que sean de 5 a 7 individuos.

El equipo se ve conformado de la siguiente manera:

Donde los que mayores responsabilidades son el Account Manager (AM) quien es

el responsable del proyecto internamente con el desarrollo y externamente con el

cliente dueño del proyecto y sus responsabilidades son:

Planeación

El AM tiene la responsabilidad de planear las actividades que se llevan a

cabo al iniciar un proyecto, en la siguiente imagen (Ilustración 3.2) se

muestran las actividades a realizar.

Ilustración 3.1. Team Members.

55

Control

El AM tiene la responsabilidad de llevar un control de las actividades que

proceden después de la planeación, las cuales se muestran en la

siguiente imagen (Ilustración 3.3).

Monitoreo

El AM tiene la responsabilidad de estar al pendiente en lo que pasa

durante el ciclo de vida del proyecto y con hecho realizar las actividades

que se muestran en la siguiente imagen (ilustración 3.4).

Ilustración 3.2. Responsabilidades del AM (Planeación)

Ilustración 3.3. Responsabilidades del AM (Control)

56

Y el Scrum Master (SM) quien es el líder del equipo de desarrollo y

responsable de que el equipo realice las actividades del ciclo de vida de

Scrum y sus responsabilidades son las siguientes:

Planeación

El SM tiene la responsabilidad de planear las actividades que va asignar

al equipo de desarrollo y lo que se hará durante el proyecto las cuales e

muestran en la siguiente imagen (ilustración 3.5).

Ilustración 3.4. Responsabilidades del AM (Monitoreo)

Ilustración 3.5. Responsabilidades del SM (Planeación)

57

Validación

El SM tiene la responsabilidad de validar la documentación que se libere en

el ciclo de vida del software y actividades que realice el equipo de desarrollo,

en la siguiente imagen (ilustración 3.6) se muestra las actividades de

validación.

Control

El SM tiene la responsabilidad de llevar el control de los procesos de su

equipo de desarrollo como las que se muestran en la siguiente imagen

(ilustración 3.7).

Monitoreo

Ilustración 3.7. Responsabilidades del SM (Control)

Ilustración 3.6. Responsabilidades del SM (Validación)

58

El SM tiene la responsabilidad de llevar a cabo sus actividades para

monitorear los avances que tiene el desarrollo del software y junto con el AM

llevar realizar actividades que ayuden a identificar riesgos o atrasos en el

proyecto, las actividades del monitoreo se muestran en la siguiente imagen:

Durante el proceso de la metodología Scrum se encuentran las user stories o bien

los requerimientos que se trabajarán en el proyecto, los cuales son descritos por el

Product Owner.

En la siguiente imagen (ilustración 3.9) se muestra el flujo del proceso de Scrum.

Ilustración 3.8. Responsabilidades del SM (Monitoreo)

59

Ilustración 3.9. Flujo del proceso Scrum.

El flujo de los procesos Scrum son los siguientes:

60

Todo empieza cuando se tiene un nuevo proyecto se tiene una junta llamada kickoff,

se llevan a cabo las validaciones de temas trabajados en la junta kickoff y se

procede a la preparación del proyecto.

Preparación para el proyecto Objetivo

Preparar la documentación de requerimientos y diseño gráfico del proyecto

por desarrollar.

Las actividades de este proceso pueden llevar de 1-3 semanas dependiendo

del tamaño del proyecto.

Criterios de entrada.

AM - Integrantes del equipo definidos como mínimo:

SM.

BA.

UI/UX.

SM - Fechas compromiso importantes para el cliente y para el proyecto.

SM - Alcance del proyecto validado.

SM - Niveles de usabilidad.

UI/UX - Manual de identidad del proyecto proporcionado por el PO

(opcional).

Recursos

1. Los necesarios según el rol.

Criterios de adaptación.

2. En caso de que el proyecto sea una segunda versión o continuación de

un proyecto existente previamente.

No es necesario solicitar creación de proyecto en la plataforma de

proyectos.

No es necesario solicitar creación de repositorios.

No es necesario generar especificaciones gráficas.

Pasos

1. SM - Solicitar información del proyecto.

Solicitar a Ventas y/o AM la siguiente información:

WBS y alcance del proyecto.

Nombre, Email, teléfono, Skype, etc. para contactar al PO.

Solicitar a PMO la creación del proyecto en La plataforma de

proyectos (en caso de que no exista).

2. SM - Definir plan de proyecto.

Crear una copia de la plantilla para crear el plan del proyecto

61

Nomenclatura: NombreDeLaEmpresa-Plan de proyecto-

NombreDelProyecto.

Compartir el archivo al departamento de PMO.

3. SM - Configurar proyecto

Asignar "¿Quién es quién?" de los integrantes al proyecto en La

plataforma de proyectos.

Solicitar a PMO la asignación de tareas a todos los integrantes en La

plataforma de proyectos.

Solicitar a PMO creación de repositorios en la plataforma

correspondiente.

Crear "Plan de Sprints" en la plataforma de proyectos.

4. SM - Definir "Release planning" de requerimientos.

Acomodar en cada sprint los requerimientos planeados a

desarrollarse.

5. BA/UI/UX - Definición de diseño gráfico y usabilidad del proyecto.

Definir especificaciones gráficas: fuentes, colores, launcher icon,

logos, etc.

Definir wireframes de pantallas representativas del proyecto: Splash,

Login, menú, logo, formularios, feeds, etc.

6. SM - Levantar, documentar y validar requerimientos

Validar "Plan de proyecto" y "Release planning" con el PO

Convocar a reunión(es) con el PO para la definición de los

requerimientos

Analizar y documentar en "Documento de requerimientos" la

información relevante de cada requerimiento

Analizar "Documento de requerimientos" y "Diseño gráfico" con el

equipo

Validar "Documento de requerimientos" y "Diseño gráfico" con el PO

Criterios de salida.

Plan de proyecto creado.

Release planning definido y validado.

Documento de requerimientos creado.

Diseño y especificaciones gráficas definidas y validadas.

Riesgos de exclusión

62

Si no se realizan las actividades de la preparación del proyecto correctamente

pueden presentarse los siguientes problemas:

El PO o el equipo desconocerán las fechas de inicio y fin del proyecto.

Pérdida de tiempo debido a que el equipo no tendrá información suficiente

para llevar a acabo planeación del SPRINT 1 y subsecuentes.

El PO no habrá validado diseño gráfico y puede existir re-trabajo durante

la fase de desarrollo.

Ya terminada la preparación del proyecto, esto significa que ya se tiene un

documento de requerimientos los cuales se dividirán para acomodarlos en la

planificación de los sprints que el proyecto vaya a durar.

Planificación de sprint Objetivo

Identificar y asignar un tiempo estimado a las actividades a realizar durante

un sprint de desarrollo para materializar requerimientos de un proyecto.

Criterios de entrada

SM - Validar requerimientos.

SM - Revisar documento de requerimientos.

SM - Revisar plan global de proyecto.

SM – Plataforma de proyectos.

Crear Sprint(s)

BA - Publicar documento de requerimientos.

Testing - Release Planning.

Actualizar estatus y Sprint de cada requerimiento.

SM - Convocar a planeación a todos los integrantes del equipo (Mínimo

con 2 días de anticipación).

SM - Asegurar que todos los recursos estén disponibles.

Recursos

Sala de juntas.

Proyector o Televisión para proyectar.

Laptop por cada miembro del equipo.

Criterios de adaptación

Este proceso debe seguirse siempre que existan requerimientos pendientes

por desarrollar o errores de funcionalidad que no permitan liberar una versión

beta para validación por parte del cliente.

63

Los siguientes criterios de adaptación deben aplicarse sobre este proceso

según:

7. (Paso) SM - Definir lugar y horarios de SCRUM diario.

Obligatorio: Si es la planeación del 1er sprint del proyecto.

Opcional: Si el SM tiene un motivo justificado para ejecutarlo.

Pasos

1. SM/PPQA - Verificar que todo el equipo se encuentre presente

Analista (BA).

Desarrollo (Android, iOS y/o Web).

Diseñador.

Tester.

Representante PPQA.

2. SM - Exponer plan del proyecto y release planning.

SM - Identificar fechas de sprint por planear VS deadline del proyecto.

SM - Notificar cambios en la planeación global del proyecto (en caso

de que existan).

SM - Revisar los requerimientos del sprint que se está planeando.

3. BA/SM - Exponer requerimientos del sprint (Documento de

requerimientos).

SM - Exponer nombres de requerimientos a desarrollar en el sprint.

Equipo - Identificar dudas y solicitar aclaración.

Tester - Identificar y documentar casos de prueba prioritarios.

Diseñador - Identificar recursos por desarrollar.

4. Equipo - Planear tareas

Equipo - Identificar tarea y asignarla a un requerimiento o PBI.

Equipo - Asignar estimación inicial (en horas) para concluir cada tarea.

5. SM - Revisar tareas capturadas, checklist:

¿La cantidad horas por miembro del equipo excede el % de horas

asignadas en el proyecto?

Evitar planear de más.

¿La cantidad de horas permite agregar más requerimientos al sprint?

Evitar planear de menos

¿Las tareas tienen faltas de ortografía?

¿Existen tareas capturadas para todos los roles del proyecto?

Siempre cuando sea necesario, BA y SM pueden no tener tareas.

6. SM - Definir lugar y horarios de SCRUM diario

64

Criterios de salida

BA - Minuta de la junta

Documentación de dudas, acuerdos y conclusiones relevantes

tomados durante la reunión.

Interna: Internamente al equipo se puede enviar por correo y/o Skype.

Debe subirse al repositorio.

Externa: Al cliente debe enviarse minuta en el formato oficial de

minutas. Debe subirse a la plataforma de comunicación con el cliente.

SM - Plataforma de proyectos

0 horas pendientes en el sprint anterior.

Horas estimadas del sprint actual.

Cada tarea no debe de exceder de 10 horas.

Todos los requerimientos y PBI tienen uno o varios responsables.

Todas las tareas tienen horas y un solo responsable asignado.

Equipo

Conocen las actividades a realizar durante el sprint.

Riesgos de exclusión

Si no se realiza la planeación del sprint correctamente pueden presentarse

los siguientes problemas:

El SM no conoce el tiempo que cada miembro del equipo tiene planeado

trabajar en el proyecto.

El SM no conoce las actividades por realizar por cada miembro del equipo.

El equipo no conoce o entiende los requerimientos a desarrollar durante

el sprint.

El equipo no tiene certeza de que actividades debe realizar para

completar los requerimientos del sprint.

Una vez planeados los sprints el equipo se pone de acurdo para fijar la hora en la

que se tendrán los Scrum diarios.

SCRUM diario Objetivo

Sincronizar y pronosticar las actividades a realizar para las próximas 24

horas. Inspeccionar el progreso y la tendencia hacia la conclusión del trabajo

planeado del sprint. Mejorar la comunicación, identificar impedimentos y

tomar decisiones respecto al plan del sprint para lograr el cumplimiento de

los compromisos.

Criterios de entrada

65

Horas capturadas en VersionOne (del día anterior).

Horas capturadas en Plataforma de proyectos (del día anterior).

Commit y Push al repositorio (Desarrolladores).

Conocer las reglas del SCRUM diario:

Puntualidad. Todos los miembros del equipo deben estar en el lugar

y hora acordados.

Actitud. Todos los miembros del equipo deben permanecer de pie

(excepto el que dirige el SCRUM) y sin distractores (dispositivos

electrónicos, laptops, celulares, etc.).

Orden. Durante la exposición de estatus, solo un miembro del equipo

puede hablar a la vez.

Respeto. Los miembros del equipo que no están contestando las

preguntas guardan silencio y están atentos a los comentarios de la

persona que habla.

Comunicación. Después que todos los miembros del equipo hayan

dado su estatus, se pueden generar comentarios para aclarar algún

tema relevante del proyecto.

Conocer el estatus de Q&A de las aplicaciones.

Recursos

Lugar de reunión con capacidad para todos los integrantes del equipo (de

pie).

Laptop para el encargado de dirigir la junta.

Criterios de adaptación.

Cuando el SM no esté disponible:

El equipo deberá asignar a un encargado de dirigir el SCRUM diario.

Pasos

1. Verificar que todo el equipo se encuentre presente:

Desarrolladores.

Testing.

Diseño.

BA.

2. Consultar y analizar la gráfica de burndown y scrumboard en VersionOne

Revisar las horas planeadas vs reales.

3. Documentar SCRUM.

Capturar fecha y participantes en el archivo de SCRUM.

Preguntar a cada participante la información solicitada por la plantilla.

Identificar motivos de atrasos, impedimentos o riesgos.

66

Identificar acciones correctivas para atrasos, impedimentos o riesgos.

Identificar y documentar cambios o dudas de requerimientos.

4. Exponer estatus de Q&A de la aplicación

Identificar y programar envío de versiones para Testing.

Mencionar errores relevantes presentes en las aplicaciones.

Asignar prioridades para solución de errores.

5. Discutir cualquier tema relevante relacionado con el proyecto traído a la

mesa por el equipo.

Criterios de Salida

Atrasos, impedimentos y/o riesgos identificados.

Acciones correctivas identificadas.

Todos los integrantes del equipo conocen el estatus actual del sprint.

Cambios a requerimientos identificados.

Dudas de requerimientos que deben aclararse con el equipo y/o PO

(Product Owner).

Riesgos de exclusión.

Si no se realiza el Scrum diario correctamente pueden presentarse los

siguientes problemas:

Que no se tenga suficiente conocimiento del estatus de las tareas

pendientes del equipo.

Que no se detecten a tiempo las acciones correctivas para controlar

los riesgos y eliminar impedimentos.

Que se presenten atrasos en el trabajo y no se terminen todas las

tareas del sprint en tiempo y forma.

Luego de llevar el Scrum diario, antes de que acabe un sprint el equipo debe de

acordar una fecha para realizarle al cliente un show case de lo que se avanzó en el

sprint.

Show Case Objetivo

La presentación de los requerimientos desarrollados durante el sprint y

obtener retroalimentación del Cliente/Product Owner (PO) del avance del

proyecto.

Criterios de entrada

SM - Convocar a show case al cliente y a todos los integrantes del

equipo (Mínimo con 2 días de anticipación)

67

TESTING - Versión probada y aceptada para mostrar al cliente y

candidata para producción

DEV - Programa "My Mobiler" para Android y "Reflector" para iOS

dependiendo de la tecnología requerida

TEAM - Conocer las reglas del SHOW CASE

Puntualidad. Todos los miembros del equipo deben estar en el

lugar, 10 minutos antes de la hora acordados con el cliente

Actitud. Todos los miembros del equipo deben permanecer en

silencio y prestando atención a la demostración, por si surgen

dudas por parte del cliente, la persona más calificada la resuelva

Respeto. Los miembros del equipo que no están contestando la

duda guardan silencio y están atentos a los comentarios de la

persona que habla

Comunicación. Todo el equipo debe conocer las funcionalidades

que se presentarán

SM - En caso de ser Show Case a distancia preparar y probar la

comunicación mínimo 10 minutos antes de la reunión

Recursos

Sala de juntas.

Proyector o televisión para proyectar.

Teléfono.

Laptop para hacer la presentación.

Criterios de adaptación

En caso de presentar Show Case a distancia:

Establecer comunicación con el cliente

o SM - Debe establecer comunicación por vía Skype, video

conferencia (JoinMe o similar) o llamada telefónica

Pasos

1. SM - Verificar que todo el equipo se encuentre presente

Analista (BA)

Desarrollo (Android, iOS y/o Web)

Diseñador

Tester

2. SM - Exponer agenda del show case. Explicar al cliente el objetivo de

la reunión y agrandes rasgos los temas a tratar. Regularmente estos

temas pueden ser:

Requerimientos finalizados y no finalizados en el

sprint recién concluido.

Dudas o ajustes de los requerimientos a desarrollar.

68

Requerimientos a desarrollar en el siguiente sprint.

Información pendiente por entregar de parte del cliente/Product

Owner.

Avance global del proyecto.

3. SM - Presentar avance del proyecto (por cada tecnología)

Exponer la descripción del requerimiento

Mostrar el requerimiento que no se cumplió en caso de tenerlo.

Demostrar en un dispositivo móvil, Tablet o web la funcionalidad

según el requerimiento.

Exponer las funcionalidades que no se lograron o quedaron

incompletas.

4. Aclarar dudas de requerimientos por desarrollar

Exponer los requerimientos por desarrollar, aclarar dudas en caso

de ser necesario.

5. Exponer funcionalidad a entregar en el siguiente Show Case

Mostrar la funcionalidad definida para el siguiente Show Case.

Dar fecha tentativa del siguiente Show Case.

6. Exponer el avance global del proyecto

Exponer estatus global de requerimientos (finalizados, en

desarrollo y por desarrollar).

Exponer plan global del proyecto.

Criterios de salida

Requerimientos implementados aprobados o con retroalimentación

por parte del cliente.

Diseños aprobados o con retroalimentación por parte del cliente.

Dudas de requerimientos resueltas.

Minuta de conclusiones y acciones por realizar.

Riesgos de exclusión

Si no se realiza la presentación de avances del proyecto pueden

presentarse los siguientes problemas:

Que el cliente/Product Owner no esté enterado del avance del

proyecto.

Que no se aclaren dudas de requerimientos y que esto provoque

problemas en la planeación del siguiente sprint debido a que no se

tengan requerimientos confirmados.

Que no se tenga retroalimentación oportuna de los requerimientos

desarrollados y esto provoque retrabajo en el futuro.

69

Una vez que el show case fue presentado al cliente el ultimo día de cada sprint se

lleva a cabo una retroalimentación de cómo trabajo el equipo a la cual se le llama

retrospectiva.

Retrospectiva Objetivo

Analizar el desempeño del equipo con respecto a personas, herramientas,

procesos y comunicación durante el sprint anterior para identificar

oportunidades de mejora a aplicar en los próximos Sprints. Proponer

acciones que mejorarán el desempeño del equipo en próximos Sprints.

Criterios de Entrada

SM - Convocar a retrospectiva a todos los integrantes del equipo (Mínimo

con 2 días de anticipación)

TEAM - Tareas con horas pendientes y estatus actualizados

TEAM - Conocer las reglas de la junta de retrospectiva:

Puntualidad. Todos los miembros del equipo deben estar en el lugar y

hora acordados

Actitud. Todos los miembros del equipo deben permanecer atentos sin

distractores (dispositivos electrónicos, laptops, celulares, etc.)

Respeto. Los miembros del equipo que no están dando su

retrospectiva guardan silencio y están atentos a los comentarios de la

persona que habla

Recursos

Sala de juntas

Proyector o Televisión para proyectar

Laptop (SM) para documentar la retrospectiva

Acceso al archivo de Drive "NombreDeLaEmpresa - Retrospectiva de

todos los proyectos"

Pasos

1. SM/PPQA - Verifica que todos los integrantes del equipo estén presentes:

BA

Desarrolladores (iOS, Android y/o Web)

Diseñador

Tester

Representante de PPQA

2. Team - Cada integrante del equipo debe contestar las siguientes

preguntas:

¿Qué debemos de empezar a hacer?

¿Qué debemos de dejar de hacer?

70

¿Qué debemos de continuar haciendo?

Identificar oportunidades de mejora en procesos, plantillas, etc.

SCRUM diario

Plataforma de proyectos

Plataforma de comunicación con el cliente

Comunicación con el cliente/Product Owner

Comunicación interna del equipo

Identificar planes de acción para aplicar las oportunidades de mejora

3. SM - Exponer estatus de los requerimientos del sprint recién finalizado en

"Release planning"

Team - Actualizar estatus de requerimientos y documentar

comentarios de actividades pendientes por cada requerimiento

Desarrollo: Funcionalidad pendiente de desarrollar

Pruebas: Pruebas pendientes de ejecutar

Estabilización: Errores pendientes de solucionar

Listo: Requerimiento finalizado

4. SM - Hacer SPLIT en Plataforma de proyectos de requerimientos no

finalizados

SM - Analizar cantidad de horas de atraso

Criterios de salida

Minuta de retrospectiva en el drive

Oportunidades de mejoras identificadas para aplicar en el siguiente sprint

Estatus de requerimientos actualizados en el release planning

Sprint anterior con 0 horas pendientes

En caso de que algún integrante no haya estado presente, el SM debe

informarle a dicho integrante las conclusiones a las que se llegaron

durante la reunión

Riesgos de exclusión

Si no se realiza la retrospectiva del sprint pueden presentarse los siguientes

problemas:

Que se sigan cometiendo los mismos errores en Sprints futuros

Que no se conozcan a tiempo los problemas que se tienen en el equipo

Una vez que se llega al objetivo del desarrollo se lanza una versión beta del software

y es publicado en las tiendas de aplicaciones que se especificaron en el documento

de requerimientos, una vez publicado se llevan a cabo las pruebas de aceptación

del usuario, si llega a aparecer algún error este se corrige y una vez que todo salga

como se planeó se libera la versión final y se cierra el proyecto.

71

Una vez que se conoce cómo funcionan los procesos de la metodología Scrum en

Jaguar Labs, se desarrollará como fue la práctica de la metodología Scrum,

desempeñando el rol de Business Analyst (BA).

Una vez que se concretó un proyecto, se seleccionan los integrantes del equipo de

desarrollo de la aplicación un SM, BA, Tester, diseñador y desarrolladores (Android

e iOS).

Ya que se arma el equipo de desarrollo se tiene una junta con el cliente donde se

presenta el equipo con el cliente y viceversa, donde el cliente expone su proyecto,

en esta ocasión es el desarrollo de un videojuego para ayudar a niños sordos de

uno a cinco años para que aprender el lenguaje de señas mexicanas (LSM).

Luego de que la junta se lleve a cabo el BA empieza con el desarrollo del documento

de requerimientos en base a lo que el cliente expuso. En esta ocasión el cliente

proporciona unas diapositivas donde se encontraba lo que el videojuego tenía que

realizar. Una vez terminado el documento de requerimientos, se lleva a cabo una

validación con el SM para checar que los requerimientos son claros y se describan

correctamente.

Con el documento de requerimientos finalizado, el SM junto con el AM realizan una

estimación del tiempo que se va a llevar el ciclo del proyecto, y que requerimiento

va a desarrollarse en que sprint y esto se proyecta en un plan de trabajo.

Con el plan de trabajo terminado, el BA y SM tienen una junta o llamada con el

cliente donde se le presenta el plan de trabajo donde se ven los sprints y los

requerimientos que se estarán trabajando en cada uno de ellos, se lleva a cabo la

validación, al terminar el BA realiza una minuta donde se describe de lo que se habló

en la junta o llamada, la cual se sube a la plataforma en la cual se interactúa con el

cliente con el objetivo de que este enterado de que se va a iniciar a trabajar en su

proyecto.

Una vez que el PO valida el plan de trabajo se lleva a cabo una junta de planeación

donde deben de participar todos los del equipo de desarrollo, donde el BA y el SM

darán a conocer el plan de trabajo y los requerimientos que se estarán trabajando

el primer sprint.

Ya que se realizó la planeación del primer sprint el BA realiza una minuta, el

diseñador se pone a trabajar en las propuestas de las pantallas, los desarrolladores

empiezan a trabajar en la funcionalidad y el Tester queda en espera a que se libere

la primera versión para iniciar a realizar pruebas.

Diariamente se realiza el Scrum diario donde los integrantes del equipo explican

que hicieron el día anterior y comentan lo que harán el presente día,

72

Antes de terminar el sprint se lleva a cabo un show case con el PO para que observe

cómo va el desarrollo del producto hasta el momento y este da sus comentarios al

equipo.

Una vez se lleva acabo el show case el ultimo del sprint se lleva a cabo la

retrospectiva para saber cómo va el equipo se pregunta que se está haciendo bien

y que no con el objetivo de mejorar para el próximo sprint.

Y así se repite los procesos desde la planeación del sprint hasta que se llega a la

ultimo sprint a o si se llega a una versión estable antes de lo que se había estimado.

En este proyecto en general que solo puedo hablar a grandes rasgos se había

estimado una duración de tres meses y medio, pero por la buena comunicación y

las facilidades que ofrece esta metodología se logró terminarlo en dos meses y

medio.

Una vez que se conoce el procesos y los pasos que ayudan a que la metodología

Scrum compruebe su agilidad versus las metodologías clásicas, llevar a cabo estos

procesos s cuestión de buena administración, un equipo y sobre todo una buena

comunicación.

Por lo desarrollado en este capítulo se da a conocer cómo es que uno de las

metodologías que gracias al trabajo en equipo y comunicación se pueden superar

las expectativas iniciales que un proyecto convelle.

Conclusión En base a los tres meses en los que se ha trabajado con la metodología Scrum

en la empresa Jaguar Labs y CartoData se ve como los proyectos llegan de parte

de los clientes con ideas no tan claras y se observa que cuando un equipo se

pone de acuerdo y se brinda apoyo al cliente aterrorizando esas ideas, y se le

muestra en base a una preparación de proyecto la estimación de la fechas en las

cuales su producto se va a desarrollar.

Tras lo aprendido en este periodo como Business Analyst de cómo se leen los

requerimientos que el cliente pide y transformarlos a un requerimiento que los

desarrolladores y el equipo de trabajo endientan, y a lo largo de los proyectos no

dejar de tener comunicación con el cliente es una de las cosas que hace más fácil

y sencilla la aplicación de la metodología Scrum.

73

Una vez terminado este documento se cumplió el objetivo de dar a conocer Scrum

y compartir sobre cómo fue la experiencia de la práctica de esta metodología.

Se logró mostrar porque se dejaron de ser viables las metodologías clásicas debido

a las crisis que el software estaba sufriendo, también se logró mostrar los beneficios

que tienen usar las metodologías agiles.

A lo largo del documento se da respuesta a las preguntas de investigación.

Participar en proyectos en los cuales se superaron las expectativas de tiempos,

aplicando los procesos de la metodología Scrum hacia que todo fuera más sencillo

y dando como enseñanza que el Scrum diario es una muy buena estrategia ya que

en este espacio que el equipo se da, salen los problemas o dudas que se están

dando día a día y en ese momento se busca una alternativa para darle solución.

Al hacer uso de esta metodología se ha comprobado que a comparación de las

metodologías clásicas en la que se perdía mucho tiempo al poner al mantenimiento

del software en la fase final, se ven superadas por Scrum dado que en cada sprint

se está probando y buscando cualquier falla que el software pueda tener para que

sea corregida y conservar el tiempo estimado para el desarrollo del software y no

esperar hasta el final y no saber si el tiempo que se estimó alcanzara para reparar

las fallas que resulten una vez se lleve a cabo el desarrollo.

Referencias [1]Google books, Ingeniería del software - Ian Sommerville, María Isabel Alfonso

Galipienso[online],consultado el 20/Octubre/2015, disponible en: https://books.google.com.mx/books?id=gQWd49zSut4C&printsec=frontcover&dq=

modelos+de+ingenieria+de+software&hl=es-

419&sa=X&ved=0CBAQ6AEwAGoVChMInNuXi_HPyAIVA44NCh3X4wFU#v=one

page&q&f=false

[2] Importancia una guía de ayuda, importancia del software [online], consultado el

11/Noviembre/2015, disponible en http://www.importancia.org/software.php

[3] ok hosting, importancia del software en la sociedad [online], consultado el

11/Noviembre/2015, disponible en http://okhosting.com/blog/la-importancia-del-

software-en-la-sociedad/

74

[4] Wikipedia, crisis del software [online], consultado el 11/Noviembre/2015,

disponible en https://es.wikipedia.org/wiki/Crisis_del_software

[5] blog historia de la informática/museo de la informática/Universitat Politécnica de

Valéncia, la crisis del software, consultado el 11/Noviembre/2015, disponible en

http://histinf.blogs.upv.es/2011/01/04/la-crisis-del-software/

[6] AMC, código de ética y práctica de la ingeniería de software [online], consultado

el 9/Noviembre/2015, disponible en http://www.acm.org/about/se-code-s

[7] La tecla de ESCAPE, metodologías de desarrollo del software [online],

consultado el 13/Noviembre/2015, disponible en

http://latecladeescape.com/h/2015/07/metodologias-de-desarrollo-del-software#

[8] Paradigmas de programación, Metodología de desarrollo de software [online] ,

consultado el 13/Noviembre/2015, disponible en

http://paradigmasiut.blogspot.mx/2013/04/metodologia-de-desarrollo-de-

software.html

[9] metodologías de desarrollo, metodologías clásicas [online], consultado el

14/Noviembre/2015, disponible en http://ithjlmvu2.blogspot.mx/

[10]Google imágenes, Etapas metodología de cascada [online],14/Noviembre/2015,

disponible en http://3.bp.blogspot.com/-

WspokzjjQLQ/T6RSvcmO4SI/AAAAAAAAAF0/AH5CJQqCFH8/s1600/cascada.pn

g

[11] Dos ideas. Personas y software, desarrollo ágil de software [online], consultado

el 18/Noviembre/2015, disponible en

http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

[12] enciclopedia virtual, modelos y metodologías para el desarrollo de software,

consultado el 19/Noviembre/2015, disponible en http://www.eumed.net/tesis-

doctorales/2014/jlcv/software.htm

[13] Universidad Unión Bolivariana, ingeniería de software [online], consultado el 16

disponible en http://ingenieriadesoftware.mex.tl/52682_Metodologias-Agiles.html

[14] tech deployment, beneficios de aplicar metodologías agiles en el desarrollo de

software [online], consultado el 12/Noviembre/2015, disponible en

http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-

metodologias-agiles-en-el-desarrollo-de-software/