implementación de la metodología scrum para obtener la
TRANSCRIPT
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/