ADAPTACIÓN DE UNA METODOLOGÍA ÁGIL DE DESARROLLO DE
66
ADAPTACIÓN DE UNA METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE PARA EL BANCO DE OCCIDENTE JONATHAN RODRIGUEZ FLAKER 2087527 UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA DEPARTAMENTO OPERACIONES Y SISTEMAS PROGRAMA DE INGENIERÍA INFORMÁTICA SANTIAGO DE CALI 2019
Transcript of ADAPTACIÓN DE UNA METODOLOGÍA ÁGIL DE DESARROLLO DE
ADAPTACIÓN DE UNA METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE PARA EL BANCO DE OCCIDENTE
JONATHAN RODRIGUEZ FLAKER 2087527
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE
FACULTAD DE INGENIERÍA DEPARTAMENTO OPERACIONES Y SISTEMAS
PROGRAMA DE INGENIERÍA INFORMÁTICA SANTIAGO DE CALI
2019
ADAPTACIÓN DE UNA METODOLOGÍA ÁGIL DE DESARROLLO DE
SOFTWARE PARA EL BANCO DE OCCIDENTE
JONATHAN RODRIGUEZ FLAKER
Pasantía institucional para optar al título de Ingeniero Informático
Director Orlando Arboleda Molina
Master en Sistemas
UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA
DEPARTAMENTO OPERACIONES Y SISTEMAS PROGRAMA DE INGENIERÍA INFORMÁTICA
SANTIAGO DE CALI 2019
3
Nota de aceptación: Aprobado por el comité de grado en
Cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar
al título de Ingeniero Informático
Jesús Antonio Lemos
_______________ Jurado
Santiago de Cali, 28 de Agosto de 2019
4
CONTENIDO
RESUMEN 9
INTRODUCCIÓN 10
1 PLANTEAMIENTO DEL PROBLEMA 11
2 JUSTIFICACIÓN 14
3 ANTECEDENTES 15
3.1 THE AGILE ALLIANCE 15
3.2 MEJORA DE PROCESOS DE SOFTWARE ÁGIL CON AGILE - SPI PROCESS 15
3.3 IMPLEMENTACIÓN DE METODOLOGÍAS ÁGILES MEDIANTE HERRAMIENTAS AUTOMÁTICAS DE DEFINICIÓN DE PROCESOS 16
3.4 PRACTICAS AGILES PARA EL DESARROLLO DE SOFTWARE EN SEMILLEROS DE INVESTIGACIÓN 17
3.5 GUÍA METODOLÓGICA PARA LA GESTIÓN DE PROYECTOS DE SOFTWARE 17
3.6 UNA METODOLOGÍA ÁGIL PARA EL DESARROLLO DE SOFTWARE EN UNA COMPAÑÍA FINANCIERA 18
4 OBJETIVOS 19
4.1 OBJETIVO GENERAL 19
4.1.1 Objetivos Específicos 19
5 MARCO TEÓRICO 20
5.1 PROCESOS BUROCRÁTICOS Y ÁGILES PARA EL DESARROLLO DE SOFTWARE 20
5.2 DE ATENCIÓN DE PROYECTOS TECNOLÓGICOS DEL BANCO DE OCCIDENTE 23
5
5.3 REGLAMENTACIÓN DIVISIÓN DE TECNOLOGÍA DEL BANCO DE OCCIDENTE. 23
6 METODOLOGÍA 24
6.1 IDENTIFICACION DE PATRONES 25
6.2 DEFINICION SITUACION – PROBLEMA 25
6.3 TRABAJO DE CAMPO 26
6.4 RECOLECCION DE DATOS CUALITATIVOS Y EVALUACIÓN 26
7 DESARROLLO 27
7.1 CARACTERIZACIÓN DE LA SITUACIÓN ACTUAL DE LA ATENCIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE, QUE ATIENDEN LAS UNIDADES GESTORAS DE TECNOLOGÍA DEL BANCO DE OCCIDENTE, BAJO LA METODOLOGÍA TRADICIONAL 27
7.1.1 Proceso Actual 27
7.1.2 Diagnóstico Inicial Del Proceso 31
7.1.3 Demanda De Desarrollo De Software 31
7.2 SELECCIÓN DE LA METODOLOGÍA ÁGIL 33
7.2.1 Proceso De Autoformación 33
7.2.2 Análisis Comparado De Las Metodologías Ágiles Disponibles 36
7.3 IMPLEMENTACIÓN DE UN PROYECTO PILOTO PARA LA ATENCIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE EN LAS UNIDADES GESTORAS DE TECNOLOGÍA DEL BANCO DE OCCIDENTE 46
7.3.1 Caso De Solicitud De Desarrollo: Reexpedición Clave De Tc Por Pin Pad 47
7.3.2 Construcción Del Proyecto Piloto Usando El Scrumboc 47
7.4 EVALUACIÓN DE LOS RESULTADOS PRESENTADOS DURANTE LA EJECUCIÓN DEL PROYECTO PILOTO 54
7.4.1 Evaluación De La Percepción 54
7.4.2 Evaluación Financiera 59
6
8 CONCLUSIONES 65
REFERENCIAS 66
7
LISTA DE FIGURAS
Pág.
Figura 1. Atención de proyectos tecnológicos del banco de occidente. 23 Figura 2. Metodología de la investigación cualitativa. 24 Figura 3. Resultado final de la ponderación de la metodología ágil idónea para el caso del banco. 42 Figura 4. Diagrama de la metodología Scrum. 45 Figura 5. Product backlog cambio de clave por olvido TC. 48 Figura 6. Diagrama de flujo cambio de clave por olvido TC – Proceso propuesto. 49 Figura 7. Diagrama de secuencia cambio de clave por olvido TC – Proceso propuesto. 50 Figura 8. Resultado del desarrollo de software requerido cambio de clave por olvido TC – Proceso propuesto. 52 Figura 9. Presupuesto destinado para el desarrollo de software requerido cambio de clave por olvido TC – Proceso propuesto, sin SCRUMBOC. 53 Figura 10. Variables específicas de diseño de software. 55 Figura 11. Análisis comparados de la percepción de los clientes y usuarios internos respecto del diseño de software antes y después, solos variables y resultados finales. 59 Figura 12. Retorno de la inversión proyecto reexpedición de clave de tarjeta crédito con metodología ágil. 60 Figura 13. Comparación del retorno de la inversión proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional. 61 Figura 14. Comparación del retorno de la inversión en clave de tiempo, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional. 62 Figura 15. Comparación del tiempo de diferencia que tarda en recuperarse la inversión, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional. 63 Figura 16. Comparación del Time to Market, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional. 63
8
LISTA DE TABLAS
Pág.
Tabla 1. Descripción completa de los subprocesos del desarrollo de software
en el Banco de Occidente 29
Tabla 2. Avance de planeación táctica corte a junio 30 de 2017 32
Tabla 3. Propuesta de lectura autoformación 34
Tabla 4. Metodologías identificadas por Herrera y Valencia, Pérez y Alonso 36
Tabla 5. Análisis comparado y ponderado de metodologías agiles: RUP, Agile
modeling, EP, Agile United Process, Kanban y Scrumban 40
Tabla 6. Análisis comparado y ponderado de metodologías ágiles: Crystal
DSDM, ASD, FDD, Scrum y LD 41
Tabla 7. Análisis comparado de la percepción de los clientes y usuarios internos
respecto del diseño de software antes y después 57
Tabla 8. Análisis comparados de la percepción de los clientes y usuarios internos
respecto del diseño de software antes y después, solos variables y resultados
finales 58
9
RESUMEN
En el siguiente informe se podrá encontrar el proceso de la pasantía institucional realizada en el BANCO DE OCCIDENTE, donde se adaptó una metodología ágil a las necesidades de BANCO, además de aplicarla a en un proyecto piloto y de esta manera evaluar los resultados. PALABRAS CLAVES: Metodologías Ágiles, Scrum, Cascada, SCRUMBOC
10
INTRODUCCIÓN
Actualmente el desarrollo de software ha evolucionado en gran medida en muchas organizaciones, debido al constante esfuerzo por adaptarse a las cambiantes necesidades del mercado. Los métodos utilizados para realizar proyectos de software han evolucionado en pro del desempeño de los equipos y de la calidad del producto final. “Actualmente existen nuevas corrientes llamadas metodologías ágiles, que son métodos de desarrollo de software basados en el desarrollo iterativo e incremental” (Martin, 2013)
En el Banco de Occidente existen unidades gestoras de tecnología que atienden los proyectos de Software de cada vicepresidencia, pero con el modelo actual esta atención se da en contextos muy cambiantes y en la mayoría de los casos sin la priorización adecuada. Los proyectos asignados a estas unidades gestoras de tecnología se caracterizan entre otras cosas, por una alta incertidumbre en cuanto a tiempo de finalización y costo total. Estas inconformidades se ven reflejadas en la encuesta de satisfacción del cliente interno (ENSI) que se realiza de manera anual en el Banco de Occidente. Igualmente, existen en el banco, equipos para trabajar proyectos piloto con nuevas metodologías, pero hasta el momento no se ha generado un lineamiento oficial, que estandarice una nueva forma de atender y desarrollar las necesidades tecnológicas al interior del Banco
Este proyecto pretende ofrecer una alternativa metodológica y la medida para el desarrollo de software de manera ágil, que se adecúe a las necesidades actuales del Banco de Occidente, en la que se adapten las mejores características de los métodos ágiles investigados; además de esto se desarrollará un caso práctico aplicando el método diseñado a un proyecto de desarrollo de software del banco.
11
1 PLANTEAMIENTO DEL PROBLEMA
El presente informe de pasantía Institucional se concentra en la situación particular de las unidades gestoras de tecnología del Banco de Occidente y la metodología con la cual atienden las necesidades tecnológicas que llegan desde las diferentes Vicepresidencias de la entidad.
De manera general puede decirse que existen dos metodologías por las cuales determinada unidad gestora de tecnología puede atender los proyectos de sus clientes internos y externos, la tradicional o burocrática o las metodologías ágiles (Andriano, et al, 2012). Podemos decir que cualquiera sea la metodología, el producto de software debe cumplir con características como la funcionalidad para satisfacer los requerimientos del cliente, confiabilidad evitando los posibles fallos o identificarlos apropiadamente y corregirlos, usabilidad en cuanto debe tener una interfaz de usuario adecuada para los clientes y finalmente eficiencia en tanto el producto debe ser capaz de utilizar todos sus recursos y no desperdiciarlos (Tamayo, 2013, p. 15).
En la actualidad las unidades gestoras de tecnología del Banco de Occidente se pueden caracterizar dentro de lo que afirma Pardo y colaboradores (Pardo, Cesar; et al, 2010), como un grupo que atiende los desarrollos de Software en contextos muy cambiantes y en la mayoría de los casos sin la priorización adecuada, además de no ser transmitidos a las unidades con contextos claros de las necesidades del negocio.
Los proyectos asignados a las unidades gestoras de tecnología del Banco de Occidente se caracterizan por una alta incertidumbre en cuanto a tiempo de finalización y costo total, un alto porcentaje de los desarrollos a nivel funcional no cumplen con su cometido, los atrasos y los sobrecostos por diferentes razones son constantes al punto que las vicepresidencias han expresado en conjunto su inconformidad con respecto a los resultados entregados por las unidades que atendieron los proyectos tecnológicos solicitados a lo largo del año 2017. Estas inconformidades se ven reflejadas en la encuesta de satisfacción del cliente interno (ENSI) que se realiza de manera anual en el Banco de Occidente, donde el grado de satisfacción del cliente interno con el área de TI ha descendido en 16 por ciento en los últimos 3 años, llegando a estar este año en el punto más bajo con un 65.3 por ciento. (Banco de Occidente; 2018)
12
Después que las vicepresidencias identifican la necesidad, se generan las solicitudes y se radican para ser atendidos por las unidades gestoras, estos son agrupados por las aplicaciones o por los procesos que se vean implicados en el desarrollo de la solución, lo cual genera que la unidad que los atiende termine especializándose cada vez más en habilidades muy puntuales, lo que conlleva cada vez a generar más silos de conocimiento y dependencia de personas especialistas. Las unidades gestoras de tecnología están conformadas por equipos de trabajo grandes y robustos que se enfrentan a plazos reducidos, requisitos de mejora volátiles, exigencias de rápido retorno de la inversión en los proyectos y de manera general una poca disponibilidad de recursos humanos así como una gran rotación de personal calificado, el cual impacta directamente los tiempos de entrega de los proyectos (Pardo, et al, 2010,p 252).
Dentro de las principales molestias que arrojan los resultados de la encuesta ENSI se encuentran el tiempo de entrega: en tanto el tiempo de entrega promedio de los proyectos de TI con alto impacto para el cliente en el Banco de Occidente es de 8 meses, la satisfacción del cliente, dado que en promedio la calificación actual que asignan los usuario al área de tecnología es de 3,4, siendo esta la más baja en los últimos 5 años y finalmente los controles de cambio, debido a que en promedio cada proyecto del área de TI llega a presentar 3 controles de cambio a razón de una planeación excesiva donde se quiere controlar lo incontrolable. La molestia por parte de los tres Vicepresidentes se incrementa al no ver un plan de reacción inmediato ante estos resultados.
Es por estas razones que el presente trabajo de pasantía institucional está orientado a satisfacer las necesidades de las vicepresidencias del Banco de Occidente, las cuales necesitan una alternativa en cuanto a la atención y desarrollo de sus desarrollos tecnológicos, lo que corresponda con el entorno, forma de trabajo y que agilice la labor y la eficiencia de las unidades de tecnología. También está concebido para mejorar la velocidad con la que los analistas en conjunto con su equipo de trabajo diseñan y crean las aplicaciones que son necesarias.
Por iniciativa de la Vicepresidencia de Servicio al Cliente del Banco, se crearon 2 equipos para trabajar proyectos piloto de una manera diferente (con nuevas metodología) pero hasta el momento no se ha generado un lineamiento oficial por parte de la Vicepresidencia de Tecnología donde se estandarice una nueva forma de trabajar y satisfacer las necesidades tecnológicas del Banco.
13
Dicho lo anterior, surge la pregunta: ¿Cómo adaptar una metodología ágil de desarrollo de software en las unidades gestoras de tecnología del Banco De Occidente?
14
2 JUSTIFICACIÓN
Pasar del modelo tradicional burocrático en el cual se desarrollan los proyectos de software en la actualidad, a uno ágil, considerando que la principal diferencia entre un proceso ágil y uno burocrático se encuentra en la orientación a la entrega de valor, el apoderamiento de los individuos a la reflexión constante sobre la forma de hacer el trabajo, a las características de adaptación la medida de los proyectos, sencillez, fácil aprendizaje y aplicación (Pardo, et al, 2010).
El mayor aporte para la entidad se refleja en el mejoramiento operativo de las diferentes demandas de software que llegan a las unidades gestoras de tecnología del Banco de Occidente. Es una necesidad manifestada desde la presidencia de la organización, adoptar nuevas metodologías de atención de proyectos por parte de las unidades gestoras de tecnología; de manera que permitan tener tiempos más acertados en los planes de trabajo, usuarios finales más satisfechos y un mayor dinamismo de la división de tecnología en caso de que la organización lo requiera. Esta mejor administración metodológica del desarrollo de software permitirá garantizar a los empleados de las unidades gestoras, una manera más fiable, fidedigna y eficiente de trabajo, a la vez que ofrece a los clientes internos y externos un mejor servicio generando tranquilidad y confianza por el trabajo realizado en las unidades gestoras de tecnología del Banco De Occidente.
Se han seleccionado metodologías de desarrollo ágil por su habilidad de responder a ambientes cambiantes, con requisitos de entrega rápida, con equipos que utilizan nuevas tecnologías recorriendo caminos desconocidos anteriormente, ambiente que actualmente es el día a día de la división de Tecnología del Banco de Occidente.
Para la entidad Banco de Occidente sección unidades gestoras de tecnología, el desarrollo de la pasantía institucional representa un aporte sustancial en identificar las necesidades más significativas en materia de demandas y desarrollo de software.
15
3 ANTECEDENTES
El presente capítulo contiene estudios que brindan a la presente investigación, una orientación general en cuanto al problema de las unidades gestoras de tecnología y desarrollo de software, al pasar de aplicar metodologías tradicionales para dicho desarrollo, a otras metodologías denominadas “ágiles”, mejorando la iteración, el trabajo en equipo, las comunicaciones cara a cara, todo en función de lograr un desarrollo de software más acertado acorde a las necesidades del cliente y lograr un equipo de trabajo capaz de responder mejor a los cambios que puedan surgir a lo largo de un proyecto de desarrollo.
En el presente capítulo se presentan documentos que permiten comprender, cómo otros investigadores han solucionado problemas similares en otras organizaciones
3.1 THE AGILE ALLIANCE
Es una organización que dedica sus esfuerzos a la promoción de conceptos relacionados con el desarrollo ágil de software y que producto de su trabajo dio como origen lo que se reconoce como el manifiesto ágil. En el trabajo titulado “Del manifiesto ágil sus valores y principios” (Herrera, 2007) se presenta el concepto de metodologías ágiles, se localiza la reseña del ciclo de vida del software y se analizan las diferentes metodologías tradicionales que son las antecesoras de las metodologías ágiles.
En este documento también se exponen los valores, principios y las implementaciones de las metodologías ágiles, una información importante para la construcción de los marcos de referencia del presente trabajo.
3.2 MEJORA DE PROCESOS DE SOFTWARE ÁGIL CON AGILE - SPI PROCESS
El segundo antecedente procede de una publicación en revista científica en donde se presenta la metodología Agile SPI – Process como un proceso de mejora de procesos basado principalmente en metodologías y principios ágiles, requerimientos livianos y adaptaciones de modelos internacionales. En el artículo se expone el resultado de la implementación de esta metodología en varias MiPyMEs_DS de Iberoamérica y el suroccidente de Colombia.
16
Este trabajo de Pardo y colaboradores (Pardo,2010) claramente se orienta hacia las necesidades de SPI en las MiPyMEs_DS, entendiéndose estas como pequeñas empresas de desarrollo de Software en países de América Latina y no hacía grandes corporaciones, con procesos muy estructurados y con prioridad en la seguridad de la información, sin embargo su apuesta en importante como antecedente de investigación, en primer lugar porque ilustra claramente el contexto en el cual se aplica de manera más idónea una metodología tradicional de desarrollo de software o, por el contrario, una metodología ágil. Esta primera distinción permitirá articular el planteamiento del problema y la justificación del presente trabajo.
Agile SPI – Process es el resultado puntual del trabajo de Pardo y colaboradores (Pardo, 2010), producto de una adaptación de algunos principios y metodologías ágiles para la mejora de procesos, con el fin de beneficiar la gestión de proyectos de SPI en lo que los autores definen como el sector más representativo de la industria del software, las PIMES.
En segundo lugar, este antecedente aporta al conocimiento de ciertas metodologías Ágiles, particularmente las utilizadas en su caso puntual las cuales son Programación Extrema (XP –Extreme Programming), SCRUM y Lean Development. Este aporte permitirá contribuir al desarrollo del marco teórico del presente trabajo.
3.3 IMPLEMENTACIÓN DE METODOLOGÍAS ÁGILES MEDIANTE HERRAMIENTAS AUTOMÁTICAS DE DEFINICIÓN DE PROCESOS
El tercer antecedente toma como objeto de estudio al Laboratorio de Investigación y Desarrollo en Ingeniería y Calidad del Software (LIDICALSO) de la Universidad Tecnológica Nacional – Facultad Regional Córdoba en Argentina para desarrollar un plug-in que permita la definición de un proceso de desarrollo ágil, siendo la última etapa de un sistema de tipo e-learning que capacite a las personas en el proceso de desarrollo de software, un proyecto que pretende contribuir a la definición de un proceso ágil de desarrollo de software, teniendo en cuenta la incorporación de las mejores prácticas de ingeniería previamente estudiadas como claves para el éxito del sector (Adriano, 2012).
17
3.4 PRACTICAS AGILES PARA EL DESARROLLO DE SOFTWARE EN SEMILLEROS DE INVESTIGACIÓN
El cuarto antecedente es un trabajo presentado a la Universidad Pontificia Bolivariana con el fin de optar al título de Ingeniera de Sistemas e Informática, proponiendo como objetivo general todo un conjunto de prácticas ágiles que pueden ser aplicadas en los semilleros de investigación y en grupos universitarios de desarrollo de software, con el fin de que los estudiantes a lo largo de su proceso de aprendizaje adquieran la cultura de la estructuración, la planificación, la ejecución y el seguimiento de los proyectos de ingeniería de software. (Tamayo, 2013)
El valor del aporte de Tamayo (Tamayo, 2013) se encuentra en la descripción que realiza de los diferentes modelos de desarrollo de software, programación extrema, Scrum, desarrollo de software adaptativo y Lean, información clave para la construcción del segundo objetivo consistente en la selección de la metodología ágil de diseño de software idónea, para la situación de los proyectos de desarrollo de software que atienden las unidades gestoras de tecnología del Banco De Occidente.
3.5 GUÍA METODOLÓGICA PARA LA GESTIÓN DE PROYECTOS DE SOFTWARE
El siguiente antecedente procede de la exposición de un trabajo de investigación presentado a la Pontificia Universidad Javeriana de Bogotá. En este antecedente se da cuenta del desarrollo de una guía metodológica que apoye el desarrollo de proyectos de software bajo las buenas prácticas de las metodologías ágiles, mediante el uso integrado de herramientas de software libre. El mayor aporte de este trabajo se consolida en el análisis comparado realizado sobre cuatro de las principales metodologías ágiles disponibles, Scrum, Extreme programming, Discipline agile delivery y Agile Unified Process. Al ser un trabajo que también compara y analiza una con otra para elegir la mejor opción dentro de determinadas variables, su aporte es importante para cumplir con el segundo objetivo de investigación.
18
3.6 UNA METODOLOGÍA ÁGIL PARA EL DESARROLLO DE SOFTWARE EN UNA COMPAÑÍA FINANCIERA
Finalmente, el último trabajo de investigación que se vincula al presente informe de pasantía es un trabajo de Especialización en Gerencia Integral de Proyectos que fue presentado a la Universidad Militar Nueva Granada en 2015.
Este documento tiene gran coincidencia con el presente informe de pasantía, principalmente por aplicar la metodología ágil y además por hacerla en una empresa del sector financiero, considerando que las demandas a nivel de software en estas empresas son muy similares, su valor es relevante para la pasantía.
En este antecedente se plantea una alternativa para mejorar el proceso de desarrollo de una compañía que actualmente utiliza una metodología tradicional el desarrollo de proyectos de software, esta situación le ha generado a la empresa objeto de estudio retrasos en las entregas, mala calidad de los productos terminados y sobrecarga laboral para algunos empleados (Peréz, 2015), como puede observarse son problemas que coinciden con la situación que atraviesan también las unidades gestoras de tecnología del Banco De Occidente.
La investigación del antecedente plantea el uso de metodologías de desarrollo existentes que ya han sido comprobadas como exitosas para la ejecución de este tipo de proyectos y que permiten dar cumplimiento a los requerimientos del cliente, tanto en tiempo como en calidad, aprovechando al máximo los recursos de la organización, la revisión de la solución que (Pérez, 2015) da a la situación del banco permitirá entender aún más el caso del presente informe.
19
4 OBJETIVOS
4.1 OBJETIVO GENERAL
Adaptar una metodología ágil de desarrollo de software para el desarrollo de proyectos de las unidades gestoras de tecnología del Banco De Occidente.
4.1.1 Objetivos Específicos
Caracterizar la situación actual de la atención de proyectos de desarrollo de software, a cargo de las unidades gestoras de tecnología del Banco de Occidente, bajo la metodología tradicional.
Adaptar la metodología ágil idónea, para la situación de los proyectos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco De Occidente.
Implementar un proyecto piloto para la atención de proyectos de desarrollo de software, en las unidades gestoras de tecnología del Banco De Occidente, a partir de la metodología ágil seleccionada.
Evaluar la metodología ágil seleccionada.
20
5 MARCO TEÓRICO
5.1 PROCESOS BUROCRÁTICOS Y ÁGILES PARA EL DESARROLLO DE SOFTWARE
El aspecto principal que distingue a un proceso de desarrollo de software ágil de uno tradicional o burocrático principalmente se encuentra en la orientación a la entrega de valor, el apoderamiento de los individuos sobre el problema a atender, a la reflexión constante sobre la forma como se puede desarrollar el trabajo encargado, a las característica de adaptación a la medida de los proyectos, a la sencillez y al fácil aprendizaje y aplicación del desarrollo final (Pardo, et al, 2010, p. 254).
Dos tipos de procesos existen desde la literatura para el desarrollo de software, los procesos tradicionales también conocidos como burocráticos y los recientemente propuestos como procesos ágiles.
En cuanto al esquema tradicional de SPI (Software Process Improvement) final (Pardo , 2010) afirman que este tipo de esquema demuestra su efectividad principalmente en proyectos de gran tamaño los cuales exigen un riguroso control sobre el “qué” y el “cómo” de las cosas, sin embargo los mismos autores indican que este modelo no es el más indicado para proyectos de desarrollo software que por sus características requieran la reducción drástica de los tiempos de los proyectos y costos relacionados, sin llegar por estas razones a la alteración final de la calidad del mismo. Por otro lado, Pardo y colaboradores (2010) afirman que las metodologías ágiles están orientadas principalmente a proyectos pequeños, usualmente proyectos orientados al valor, a la simplificación de actividades y de manera general a soluciones que revelen un rápido ROI (Return On Investment).
Estas metodologías están principalmente soportadas en lo que se reconoce como el manifiesto ágil, este es un documento que resume en cuatro valores y doce principios las mejores prácticas para el desarrollo de software(Herrera , 2007), este documento de soporte fue construido a partir de la propia experiencia de diecisiete industriales del software que buscaban por objetivo lograr desarrollos más rápidos en conserva de la calidad. La reseña de los principios y valores del manifiesto ágil es expuesta en el trabajo de Herrera y Valencia (2007).
21
Al respecto de los doce principios, se puede dar cuenta de cuatro generales:
Los individuos e interacciones por encima de los procesos y las herramientas
Software funcionando por encima de la documentación
La colaboración del cliente por encima de la negociación del contrato
La respuesta al cambio por encima del seguimiento de un plan
En cuanto al primero de los principios, este busca garantizar una mayor productividad reconociendo el valor mismo del propio recurso humano; tal principio centra en este último el factor primordial para el éxito. Herrera y Valencia (2007) afirman que:
(…) contar con recurso humano calificado con capacidades técnicas adecuadas, facilidades para adaptarse al entorno, trabajar en equipo e interactuar convenientemente con el usuario, da mayor garantía de éxito que contar con herramientas y procesos rigurosos (p. 383)
Dado lo anterior una metodología ágil reconoce que es mayor la importancia del valor de la construcción de equipos de trabajo que las propias herramientas y procesos. Es el equipo el que debe definir su entorno más conveniente, a partir de sus necesidades y sus circunstancias.
En cuanto al segundo principio, el enfoque tradicional se preocupa más por la documentación misma que por el funcionamiento del software, por tanto la metodología ágil reconoce que el fuerte del equipo no debe ser el de la redacción de documentos, por ello este enfoque reconoce su importancia, pero también reconoce que este proceso exige un alto costo representado en tiempo y el desgaste por mantener una documentación completa y actualizada. La clave desde el método ágil es orientarse sólo en la documentación estrictamente necesaria. Herrera y Valencia (2007) afirman que:
(…) La documentación, en las metodologías ágiles procura mecanismos más dinámicos y menos costosos como son la comunicación personal, el trabajo en equipo, la auto documentación y los estándares. (p. 383)
22
En cuanto al tercer principio, esta metodología fractura la distancia que usualmente divide al cliente del desarrollador dada en el método burocrático. “el cliente es quien solicita e indica qué debe hacer el software, y espera los resultados de acuerdo con sus exigencias o expectativas, en los plazos establecidos”. (Herrera y Valencia, 2007, p. 384)
Encontrar un punto de unión entre las dos partes permite romper con la rivalidad y prevención existentes entre uno y otro, pasando de un ámbito de enfrentamiento constante a otro de búsqueda de beneficio común, el del equipo de desarrollo y el del cliente. Herrera y Valencia (2007) afirman que:
La participación del cliente debe ser constante, desde el comienzo hasta la culminación del proyecto, y su interacción con el equipo de desarrollo, de excelente calidad. Es el cliente quién sabe qué es lo que necesita o desea, el más indicado para corregir o hacer recomendaciones en cualquier momento del proyecto. (Herrera y Valencia, 2007, p. 383)
Finalmente, el último principio de las metodologías ágiles discute al respecto de los planes herméticos, propios de los modelos burocráticos o tradicionales. En este principio se reconoce que, en la actualidad, el desarrollo de software se da en un contexto permanente de cambio y transformación, dado por la misma sociedad y los avances tecnológicos y de comunicación propios de la modernidad. Herrera y Valencia (2007) afirman que “las metodologías pesadas con frecuencia caen en la idea de tener todo completo y correctamente definido desde el comienzo. No se cuenta entre sus fortalezas la habilidad para responder a los cambios” (p. 383)
De tal forma, este último principio aboga por aceptar los posibles cambios durante la etapa de ejecución del proyecto, aceptar la necesidad de realizar ajustes sencillos en la personalización del software, eliminar la planificación estricta, reconocer las múltiples variables dispuestas en el juego, y la necesidad de la flexibilidad para lograr la adaptación a los cambios que puedan surgir.
23
5.2 DE ATENCIÓN DE PROYECTOS TECNOLÓGICOS DEL BANCO DE OCCIDENTE
Figura 1. Atención de proyectos tecnológicos del banco de occidente.
Tomado de: Atención de proyectos tecnológicos (Man-APY 061, Vicepresidencia de Tecnología y Operaciones, 2009, p. 3
La estructura de atención de proyectos de la Vicepresidencia de Operaciones y Tecnología cuenta con una unidad de atención para cada Vicepresidencia la cual, de acuerdo a la prioridad o el tamaño de sus requerimientos, definirán la cantidad de personas que la conforman.
5.3 REGLAMENTACIÓN DIVISIÓN DE TECNOLOGÍA DEL BANCO DE OCCIDENTE.
Debido a que el Banco de Occidente actualmente tiene participación en la Bolsa de Valores de los Estados Unidos, todos los desarrollos tecnológicos y el manejo de la información se rigen bajo la reglamentación SOX (Sarbanes Oxley Act). Debido a esto, el Banco en conjunto con el Holding de Empresas cuentan con una división que se encarga de realizar auditoria y el control de la información de todos los desarrollos tecnológicos que se generan de dentro y fuera de la organización. (GAvillan, 2012)
24
6 METODOLOGÍA
La metodología de investigación que vamos a seguir para determinar la metodología de desarrollo ágil a utilizar se denomina de la investigación cualitativa, la cual se caracteriza por ser inductiva (va de lo particular a lo general), ya que presenta un diseño flexible, en la cual se pueden incorporar hallazgos que no se habían previsto inicialmente y que ayudan a interpretar mejor el objetivo estudiado; permite a su vez tener una perspectiva holística, al interesarse por estudiar todos los elementos que rodean la investigación.
Este tipo de investigación busca comprender en vez de establecer relaciones causa efecto, sirviendo como ilustración propia de la investigación, la investigación cualitativa lleva a cabo estudios intensivos a pequeña escala y no propone probar teorías o hipótesis, sino más bien generarlas. (Ruiz, 2012).
Figura 2. Metodología de la investigación cualitativa.
Tomado de: Metodología de la investigación cualitativa. Distrito de Deusto: Universidad de Deusto. Por. Ruiz, J. I. 2012, p. 85
Con el fin de elegir una metodología ágil de desarrollo de software que mejor se adapte a la gestión de proyectos que atienden las unidades gestoras de tecnología del Banco de Occidente, se seguirán las siguientes etapas definidas a
25
continuación; y debido a la prioridad de contar con un resultado tangible y de valor para el Banco, se incluirá al final la etapa de Evaluación.
6.1 IDENTIFICACION DE PATRONES
Se realiza una caracterización de la situación actual de la atención de proyectos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco De Occidente bajo la metodología tradicional.
Reconociendo que el desarrollo de software actual de las unidades gestoras de tecnología del Banco De Occidente se realiza bajo la metodología tradicional, esta primera etapa busca describir cómo es la aplicación de esta metodología identificando la demanda actual de desarrollo de software por periodo, el equipo de trabajo, los tiempos de respuesta, las devoluciones de los desarrollos y sus ajustes, y de manera general determinar las cualidades y rasgos característicos del proceso.
A pesar de contar actualmente con 2 equipos de trabajo en el Banco, a los cuales de manera parcial (medio tiempo) se les asignaron proyectos piloto a trabajar de una diferente explorando nuevas metodologías. Hasta el momento no se ha generado un lineamiento oficial por parte de la Vicepresidencia de Tecnología ni se ha realizado una evaluación formal la cual permita estandarizar una nueva forma de trabajar los proyectos tecnológicos.
Para esta etapa se accederá a una revisión documental, entrevistas y levantamientos de diagramas de flujo entre otros.
6.2 DEFINICION SITUACION – PROBLEMA
A nivel de diseño se realiza la selección de la metodología ágil de diseño de software idónea, para la situación de los proyectos de desarrollo de software que atienden las unidades gestoras de tecnología del Banco de Occidente
Se ha reconocido también la existencia de una serie de metodologías de desarrollo de software denominadas ágiles, entre las que se pueden localizar la
Programación Extrema (XP –Extreme Programming), ASD, Lean Development y Scrum. La necesidad puntual de este capítulo es en primera instancia identificar cada una de estas metodologías y luego, a partir de un análisis principalmente monográfico, seleccionar aquella que se adapta mejor a las necesidades de la
26
atención de proyectos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco De Occidente.
6.3 TRABAJO DE CAMPO
Se realizará la Implementación de un proyecto piloto para la atención de proyectos de desarrollo de software en las unidades gestoras de tecnología del Banco de Occidente, a partir de una metodología ágil
Esta etapa cumple el papel de implementar en el grupo de trabajo y en la empresa misma la idea de investigación. Se sugiere una primera subtapa de diseño en la cual se determinará el nuevo procedimiento para el manejo de proyectos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco de Occidente.
Posteriormente se dará una salida a producción del proyecto en la empresa a modo de prueba piloto. Para ello se determinará el tiempo de acción y los medios para el control, evaluación y reorientación (de ser necesario) de la propuesta para su definitiva implementación.
6.4 RECOLECCION DE DATOS CUALITATIVOS Y EVALUACIÓN
Esta etapa no hace parte de la metodología cuantitativa, pero se incluye para evaluar los resultados presentados durante la ejecución del proyecto piloto, a través de la valoración cuantitativa y cualitativa con el cliente interno (sobre el impacto en cuanto a percepción y presupuesto) e investigar cómo se evalúan las metodologías y someter la metodología ágil seleccionada.
27
7 DESARROLLO
7.1 CARACTERIZACIÓN DE LA SITUACIÓN ACTUAL DE LA ATENCIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE, QUE ATIENDEN LAS UNIDADES GESTORAS DE TECNOLOGÍA DEL BANCO DE OCCIDENTE, BAJO LA METODOLOGÍA TRADICIONAL
El presente capítulo busca caracterizar los detalles de la atención de proyectos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco objeto de estudio, con el fin de conocer cómo se da la demanda de desarrollo de software, cómo está compuesto el equipo de trabajo, como resultaban siendo los tiempos de respuesta, cuáles eran las principales devoluciones de los desarrollos y cómo se daban sus ajustes, y de manera general determinar las cualidades y rasgos característicos del proceso antes de la intervención por parte del pasante.
7.1.1 Proceso Actual
En cuanto al proceso que se aplicaba en la empresa al momento de iniciar la pasantía laboral, el Banco de Occidente contaba con una metodología establecida para el proceso de desarrollo e implementación de productos/servicios en el área de Tecnología, cuyo objetivo principal es asegurar la implementación en tiempo y forma de los requerimientos presentados por las Unidades de Negocio del Banco.
El proceso general está compuesto por seis subprocesos.
DS01 Realizar ingeniería de Requerimientos - Momento en el cual se reciben las necesidades de clientes o usuarios y a partir de estos el equipo de trabajo transcribe sus necesidades en un documento que representa las especificaciones correctas de la necesidad, con el fin de minimizar los problemas que se puedan generar en otra etapa del ciclo de desarrollo por una mala gestión en los requerimientos en el desarrollo de un sistema.
DS02 Diseñar Requerimientos - corresponde con el diseño de la solución, en donde se especifica la forma como se propone solucionar el requerimiento, un momento en donde se define la forma como se construirá el software buscando eficiencia, practicidad, reducción de riesgos y siguiendo los lineamientos definidos por la arquitectura de la aplicación.
28
DS03 Desarrollar Requerimientos - corresponde con el desarrollo de requerimientos, en donde se convierte el diseño en programas ejecutables de la solución propuesta. En este subproceso también se realiza una primera validación de la calidad de éstos desarrollos a través de pruebas iniciales unitarias, es decir probando el correcto funcionamiento de cada uno de los módulos de código por separado, con lo cual se garantiza que cada uno de los módulos funcione correctamente por separado.
DS04 Probar Requerimientos - corresponde al diseño y aplicación de las pruebas funcionales, buscando evaluar cada una de las opciones con las que cuenta el paquete informático. Esta fase por tanto corresponde con las pruebas específicas, concretas y exhaustivas para probar y validar que el software diseñado cumple con el requerimiento solicitado, haciendo lo que debe y, sobre todo, lo que se ha especificado.
En esta fase también se realizan algunas pruebas no funcionales que contemplan las pruebas de desempeño, del sistema, operacionales y conversión de datos que genera la versión a colocar en producción.
DS05 Implementar Requerimiento - corresponde a la implementación de los requerimientos, momento en el cual se coloca en producción la solución definida, desarrollada y certificada por el usuario, se cree que a este momento la puesta en escena del requerimiento está garantizada dadas las pruebas previas. este subproceso también incluye el acompañamiento requerido a los usuarios, clientes o a las áreas impactadas (Procesos y Proyectos, Mesa de Ayuda y Soporte a incidencias) a través de las capacitaciones sobre la solución implementada y el acompañamiento en la transición del cambio.
DS06 Administrar Versiones - corresponde a la administración de las versiones, momento en el cual se establece y mantiene la integridad de la versión de cualquier aplicativo.
Cada uno de los diferentes momentos que antes de la intervención del autor figuraban en el banco para el desarrollo de software, requiere de ciertos entregables y a su vez representa cada uno toda una serie de procedimientos, la tabla 1 representa todo el detalle de cada una de las subfases del desarrollo de software cumpliendo a cabalidad con la caracterización que se pretendía realizar al comienzo de la práctica. A Continuación, el proceso detallado con el que actualmente se desarrolla los requerimientos tecnológicos en el Banco de Occidente.
29
Tabla 1. Descripción completa de los subprocesos del desarrollo de software en el Banco de Occidente
Subproceso Objetivo Entregables Procedimientos
DS01
Realizar ingeniería de
Requerimientos
El objetivo del proceso es generar especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y concreta, las necesidades de los usuarios o clientes, de esta manera minimizar los problemas que se puedan generar en otra etapa del ciclo de desarrollo por una mala gestión en los requerimientos en el desarrollo de un sistema.
Documento de Especificaciones
Casos de Pruebas
Casos de Uso
DS01 - 01 Realizar situación actual
DS01 - 02 Elaborar documento de especificaciones
DS01 - 03 Elaborar casos de pruebas
DS01 - 04 Verificar y validar documentos de especificaciones y casos de pruebas
DS02
Diseñar Requerimientos
El propósito de este proceso es plantear el cómo se le va a dar solución a un requerimiento con el fin reducir riesgos asociados a la construcción del software buscando eficiencia, practicidad, reducción de riesgos y siguiendo los lineamientos definidos por la Arquitectura de la Aplicación.
Documento de diseño
Requerimientos de Infraestructura
Documento de Interfaces
Documentación Arquitectura e Infraestructura
TI - Interfaces de Aplicaciones
Modelo de Datos
DS02 – 01 Definir Arquitectura e infraestructura de la aplicación
· DS02 – 02 DiseñarSolución delRequerimiento
· DS02-03 DiseñarModelo Lógico deDatos
· DS02- 04 DiseñarModelo Físico deDatos
DS03 Desarrollar
Requerimientos
El objetivo del desarrollo de requerimientos es convertir el diseño en programas ejecutables de la solución propuesta, así como validar la calidad de éstos realizando pruebas unitarias.
Documento Técnico de Desarrollo
Documento de conversión de datos
Solicitudes y entrega de fuentes
Solicitudes para actualizaciones a modelo de datos
DS03 – 01 Preparar y desarrollar la Solución
DS03 – 02 Realizar Pruebas Unitarias
DS03 – 03 Gestionar Conversión de Datos
30
DS04
Probar Requerimientos
El propósito de este proceso es ejecutar las pruebas funcionales que incluyen las de aceptación por parte del usuario asignado y las pruebas no funcionales que contempla las pruebas de desempeño, del sistema, operacionales y conversión de datos que genera la versión a colocar en producción.
Certificación de usuario
Lista de Chequeo diligenciada para finalizar pruebas
Manual de Procedimientos y del Sistema
Ficha Técnica (Papelería)
Manual de Contingencia
DS04 – 0 1 Preparar datos de Pruebas
DS04- 02 Ejecutar Pruebas
DS04 – 03 Ejecutar Pruebas de aceptación de Usuario
DS04 – 04 Elaborar y aprobar Manuales
DS05
Implementar Requerimientos
El objetivo de la implementación de requerimientos es colocar en producción en forma exitosa la solución definida, desarrollada y certificada por el usuario. Proporciona ayuda a los Usuarios, áreas impactadas (Procesos y Proyectos, Mesa de Ayuda y Soporte a incidencias) a través de las capacitaciones sobre la solución implementada y el acompañamiento en la transición del cambio.
Plan Hora a Hora
Documentación técnica a Producción
Instructivo soporte a usuarios
Planes de contingencia
Formato Cambios TI
Capacitaciones
Divulgación a usuarios
Informe resultado de la instalación
DS05 – 01 Preparar Implementación
DS05 – 02 Instalar en Producción
DS05 – 03 Brindar soporte en período de estabilización
DS06 Administrar Versiones
El propósito de este proceso es establecer y mantener la integridad de la versión de cualquier aplicativo.
Historia de Fuentes
Instructivo Instalación centralizado
Instructiva instalación distribuida
DS06 – 01 Solicitar Fuentes de versión
DS06 – 02 Administrar Fuentes de Versión
DS06 – 03 Preparar Release para instalar
DS06 – 04 Armar Release
Tabla 1. (continuación)
31
7.1.2 Diagnóstico Inicial Del Proceso
La primera intervención por parte del pasante fue convocar a un equipo interdisciplinar del Banco de Occidente compuesto por 12 personas durante tres días, se logró identificar los siguientes problemas en el proceso actual:
Ausencia de participación de la experiencia del cliente.
Los cronogramas largos con una única entrega.
Los paradigmas con los que funcionaban las subfases correspondenclaramente a un modelo tradicional que no corresponde a la vanguardia en eldesarrollo de software.
Desmotivación general del equipo por no recibir resultados eficientes y unaindependencia general entre las diferentes áreas.
Puntualmente en cuanto al primer problema, se logró identificar que ninguna de las subfases anteriormente descritas, vinculan la experiencia propia del cliente, por tanto, todo el desarrollo estaría basado en una descripción que el cliente o usuario daba en un momento coyuntural, posiblemente en una situación particular que no era suficiente para conocer los antecedentes del problema.
7.1.3 Demanda De Desarrollo De Software
Existen diferentes demandas de software que surgen de acuerdo al desarrollo de la competencia principalmente, entre estas están:
● Reexpedición de claves de tarjeta de crédito y débito● Oficina virtual● Banca móvil Aval● Desarrollos RRHH● Gestión estratégica● Planeación financiera● Entre otros
32
Los diferentes proyectos son medidos a través de indicadores los cuales tiene cortes periódicos y en donde básicamente se mide el cumplimiento o no del proyecto, sin considerar el tiempo que este le ocasione al equipo de desarrollo de software.
A continuación, se muestra el avance de los proyectos para la Vicepresidencia de Operaciones y Tecnología la cual enseña el retraso en 3 de los 4 proyectos, sin importar que estos sean proyectos prioritarios y de alto impacto para la vicepresidencia.
Tabla 2. Avance de planeación táctica corte a junio 30 de 2017
De: Resultados Encuesta Nacional del Cliente Interno. Colombia: Banco de Occidente. Banco de Occidente. 2017.
33
7.2 SELECCIÓN DE LA METODOLOGÍA ÁGIL
Considerando la situación actual del proceso para el desarrollo de software en el banco y reconociendo el conjunto de problemas que se suscitaban:
● La ausencia de un customer journey plenamente identificado
● los cronogramas largos con una única entrega,
● los paradigmas con los que funcionaban las subfases correspondenclaramente a un modelo tradicional que no corresponde a la vanguardia en eldesarrollo de software
● una desmotivación general del equipo por no recibir resultados eficientes
● una independencia general entre las diferentes áreas)
El pasante propuso al equipo de trabajo una formación autónoma en cuanto al paradigma de la metodología ágil para el diseño de software, se reconoció que gran parte del equipo procedía de escuelas que no habían conocido académicamente este paradigma (de hace cerca de diez años) y otros que a pesar de haberlo estudiado en su formación académica, no habían tenido la oportunidad de aplicarlo empíricamente por tanto el conocimiento teórico se habría perdido con el paso del tiempo.
7.2.1 Proceso De Autoformación
En la primera fase de la selección de la metodología ágil de diseño de software, el pasante aprovecho que la disponibilidad de las personas implicadas era del 100% y realizó una propuesta de autoformación a partir de las lecturas, que luego eran validadas de forma colectiva. Estableció para el equipo de 12 personas una meta de apropiación del paradigma a partir de la lectura y para ello recoge una bibliografía sugerida que le permitiría a las personas entender las características del paradigma de metodología ágil. La literatura propuesta fue la siguiente
34
Tabla 3. Propuesta de lectura autoformación
Título del
documento Autor (es) Resumen
Del manifiesto ágil sus valores
y principios
Eliécer Herrera Uribe / Luz
Estela Valencia Ayala
Documento que resume en cuatro valores y doce principios las mejores prácticas para el desarrollo de software, basados en la
experiencia de 17 industriales del software, en procura de desarrollos más rápidos conservando su calidad. Este artículo
presenta de manera general la evolución de las metodologías para el desarrollo de software y una reseña de los valores y principios
del manifiesto ágil.
Una metodología ágil para el
desarrollo de software en una
compañía financiera
Claudia Marcela Pérez Pérez
En el documento se plantea una alternativa para mejorar el proceso de desarrollo de una compañía que actualmente no utiliza
una metodología para la implementación de proyectos de software, al igual como sucede en el Banco de Occidente. Se
propone utilizar metodologías de desarrollo agiles, ya que una de las ventajas de esta estrategia está sobre el producto final el cual
se podrá entregar en el tiempo y con la calidad esperada, utilizando los recursos de manera eficiente y generando mayor
productividad, a su vez, se disminuye el riesgo de futuros defectos o errores que pueden aparecer por la falta de tiempo para realizar
las pruebas correspondientes.
Modelo CMMI y métodos ágiles en la gestión de
proyectos software
Juan Alonso Baldonedo
El trabajo explora la cooperación entre dos áreas de la ingeniería de software aparentemente incompatibles como son el modelo de mejora de procesos CMMI y las metodologías de desarrollo ágiles pueden ser utilizadas de manera cooperativa para mejorar el éxito
de los proyectos software.
La metodología para la autoformación fomentaba en el equipo de análisis una lectura crítica de los tres textos sugeridos, buscando responder principalmente a la pregunta, ¿Por qué sería conveniente adaptar el proceso de diseño de software a una metodología ágil? El grupo de trabajo logró identificar a partir de su proceso de autoformación:
La metodología ágil ya lleva por lo menos más de diez años representando una nueva tendencia en cuanto al desarrollo de software.
35
La metodología ágil se ajusta precisamente a las necesidades de desarrollopor módulos.
Se reconoció que, en el caso de los desarrollos de software en entidadesfinancieras, la demanda de necesidades tiene ciertas características particulares,en primer lugar, hay necesidades de clientes externos e internos que puedengenerar afectaciones entre unos y otros.
Se identificó también que la insistencia por mantener una metodologíatradicional en el diseño está ocasionándole a la empresa altos costos, por otrolado, si se logra estandarizar una metodología de desarrollo para todos losproyectos de software de la compañía, se podría generar una importantereducción de costos, a la vez que se podrían lograr importantes mejoras en losdesarrollos finales tal y como se observó en el trabajo de Pérez (2015) tambiénrealizado sobre una empresa financiera.
Se identificó además que los desarrollos solicitados por clientes y usuariosdel banco usualmente son dados a cambios a lo largo del proyecto, por lo cual lametodología tradicional al ser un método mucho más controlado con mayorcantidad de políticas y normas dificulta un avance rápido. Se identifica tambiénque la metodología tradicional resulta mucho más burocrática lo cualobligadamente genera que exista una mayor cantidad de roles en un mismoequipo de trabajo.
Uno de los principales problemas del método actual coincide precisamente uno de los valores principales que deben soportar el desarrollo de software, los individuos e interacciones por encima de los procesos y las herramientas:
(…) para garantizar una mayor productividad, las metodologías ágiles valoran el recurso humano como el principal factor de éxito. Reconocen que contar con recurso humano calificado con capacidades técnicas adecuadas, facilidades para adaptarse al entorno, trabajar en equipo e interactuar convenientemente con el usuario, da mayor garantía de éxito (Herrera y Valencia, 2007, p. 383)
Finalmente, los participantes en el proceso de autoformación pudieron concluir que existe en el banco un desconocimiento del paradigma actual que lidera los procesos de desarrollo de software, hasta dicho momento se habría venido trabajando con una metodología desactualizada.
36
7.2.2 Análisis Comparado De Las Metodologías Ágiles Disponibles
En la segunda fase para la selección de la metodología ágil de diseño de software, el pasante reconoce la existencia de una serie de metodologías de desarrollo de software denominadas ágiles. La necesidad puntual de este capítulo es en primera instancia identificar cada una de estas metodologías y luego, a partir de un análisis principalmente monográfico producto también de la motivación por la autoformación del equipo, identificar aquella que se adapta mejor a las necesidades de la atención de requerimientos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco De Occidente.
En esta fase se realizará una comparación entre las metodologías ágiles y se seleccionará la metodología idónea a partir del conjunto de buenas prácticas de las metodologías ágiles que se relacionan con el proyecto. Para tal efecto se ha propuesto nuevamente un análisis de las características de las diferentes metodologías que la literatura menciona y de acuerdo a las necesidades puntuales del banco, ponderar numéricamente cada una para así disminuir la subjetividad en la elección de la metodología a utilizar en el proceso.
En la siguiente tabla se muestra las principales metodologías agiles identificadas por los autores citados en este documento. En ella se nota que Alonso (2017) es más reciente y lista mayor cantidad de metodologías.
Tabla 4. Metodologías identificadas por Herrera y Valencia, Pérez y Alonso
Herrera y Valencia (2007) Pérez (2015) Alonso (2017)
Scrum Crystal Methodologies Agile modeling
Crystal Methodologies Dynamic Systems Development Method (DSDM) Adaptive software development
Dynamic Systems Development Method (DSDM)
Adaptive Software Development (ASD) Feature-driven development
Adaptive Software Development (ASD) Scrum Extreme programming
Feature-Driven Development (FDD) RUP Agile United Process
Lean Development (LD) Dynamic systems development method
37
Lean software development
Scrum
Kanban
Scrumban
Estas metodologías son tomadas de casos exitosos aplicados en empresas cuyo modelo de negocio es similar al del Banco de Occidente y que por consiguiente son vigiladas por una entidad gubernamental, la cual aumenta la importancia de los criterios de seguridad y control sobre los desarrollos. A partir de esta indagación se escogieron dichas metodologías para el análisis comparado.
Para tal efecto se diseñó una matriz de ponderación, en la cual se ubican quince variables a ponderar en cada una de las plataformas. La ponderación de las variables se realizaría en dos momentos, en el primero, se realizará una distribución porcentual del peso que cada variable tiene sobre el proceso de desarrollo de software de una manera ágil, en el segundo momento se establece el valor numérico de 1 a 5, que representa la importancia de la variable para el caso específico del diseño de software y los requerimientos del banco, siendo 1 lo menos importante y 5 lo más importante. La multiplicación del peso por la valoración daría la proporción de relevancia de cada variable y al final, su sumatoria, representa el peso ponderado total de cada metodología ágil. De esta forma se propuso escoger de una manera objetiva y mediante la participación de diferentes programadores, la metodología idónea para el caso del banco de occidente.
Las variables para ponderar fueron obtenidas de las lecturas auto-formativas realizadas por el equipo, el cual en común acuerdo selecciono las siguientes quince variables, de las cuales se detallan las aquellas donde se evidencia mayor sensibilidad con la situación actual del Banco:
Facilidad de gestión del proyecto en cada interacción:
Esta es una de las principales problemáticas derivadas de la alta burocracia que actualmente permea el proceso
Mantener comunicación directa con los interesados en el proyecto
Tabla 4. (continuación)
38
En cuanto al mantenimiento de una comunicación directa con los interesados en el proyecto, así como la facilidad de comunicación eficiente entre equipo, el modelo tradicional actual ha ignorado la importancia de la participación del cliente o usuario del desarrollo, haciendo que el proceso derive en cambios profundos luego de terminado, dado que incumple las necesidades reales
Elaboración de pruebas de adaptación
La elaboración de pruebas de adaptación y de manera general la facilidad de pruebas es un aspecto crucial para el equipo de desarrollo del banco, dado que con el modelo tradicional estas solo podían realizarse una vez que el desarrollo culmina, lo cual aumentaba el tiempo de respuesta luego de identificar errores e inconsistencias.
Mantenimiento de la integración del producto
Este factor coincide con la adaptación a los cambios del proyecto y la facilidad para ajustar errores y realizar correcciones,Como la mayoría de los proyectos corresponden a la funcionalidad por módulos, el asunto del mantenimiento de la integración del producto es también relevante para el caso específico del banco.
Facilidad para definir el alcance y objetivo del proyecto
Otros aspectos generales fueron considerados como variables, entre ellos el de facilidad para definir el alcance y objetivo del proyecto, dado que esto depende en gran parte de la participación del cliente.
Identificación de riesgos del proyecto
Facilidad para hacer un diseño simple
Historias de usuario
Adaptación a los cambios
39
Facilidad de comunicación eficiente entre equipo
Facilidad de pruebas
Facilidad para ajustar errores y realizar correcciones
Facilidad en la preparación de los datos y carga inicial del sistema
Percepción de idoneidad desde la literatura consultada
Percepción de idoneidad del grupo
Las dos últimas variables que se consideraron en el estudio, la percepción de idoneidad desde la literatura consultada, es lograda mediante la consulta en documentos académicos y la percepción de idoneidad del grupo, se corresponde a la calificación final solicitada al grupo de 12 personas a las cuales les fue presentada la propuesta.
Para la fase de comparación se realizó una revisión de las diferentes metodologías identificando en cada uno su posible idoneidad de cara a las necesidades de desarrollo de software para el banco. La valoración final fue la siguiente:
40
Tabla 5. Análisis comparado y ponderado de metodologías agiles: RUP, Agile modeling, EP, Agile United Process, Kanban y Scrumban
VARIABLE Peso del criterio
RUP Agile
modeling EP
Agile United Process
Kanban Scrumban
Facilidad de gestión del proyecto en cada interacción 8,00% 3 0,24 4 0,32 3 0,24 4 0,32 3 0,24 4 0,32
Mantener comunicación directa con los interesados en el proyecto 4,00% 3 0,12 4 0,16 2 0,08 3 0,12 2 0,08 3 0,12
Elaboración de pruebas de adaptación 5,00% 2 0,1 3 0,15 4 0,2 3 0,15 4 0,2 2 0,1 Mantenimiento de la integración del
producto 2,00% 3 0,06 4 0,08 5 0,1 4 0,08 5 0,1 5 0,1
Facilidad para definir el alcance y objetivo del proyecto 3,00% 4 0,12 5 0,15 4 0,12 3 0,09 2 0,06 1 0,03
Identificación de riesgos del proyecto 3,00% 4 0,12 5 0,15 4 0,12 4 0,12 3 0,09 2 0,06
Facilidad para hacer un diseño simple 8,00% 4 0,32 3 0,24 2 0,16 4 0,32 3 0,24 5 0,4
Historias de usuario 5,00% 2 0,1 3 0,15 3 0,15 3 0,15 2 0,1 4 0,2
Adaptación a los cambios 11,00% 3 0,33 4 0,44 5 0,55 5 0,55 4 0,44 3 0,33 Facilidad de comunicación eficiente entre
equipo 7,00% 2 0,14 4 0,28 5 0,35 4 0,28 3 0,21 2 0,14
Facilidad de pruebas 11,00% 4 0,44 2 0,22 3 0,33 4 0,44 5 0,55 2 0,22 Facilidad para ajustar errores y realizar
correcciones 15,00% 2 0,3 3 0,45 4 0,6 3 0,45 1 0,15 2 0,3
Facilidad en la preparación de los datos y carga inicial del sistema 8,00% 3 0,24 2 0,16 4 0,32 5 0,4 4 0,32 3 0,24
Percepción de idoneidad desde la literatura consultada 5,00% 4 0,2 3 0,15 3 0,15 4 0,2 1 0,05 1 0,05
Percepción de idoneidad del grupo 5,00% 4 0,2 3 0,15 4 0,2 5 0,25 3 0,15 2 0,1
TOTAL 100,00% 3,03 3,25 3,67 3,92 2,98 2,71
41
Tabla 6. Análisis comparado y ponderado de metodologías ágiles: Crystal DSDM, ASD, FDD, Scrum y LD
VARIABLE Peso del criterio
Crystal DSDM ASD FDD Scrum LD
Facilidad de gestión del proyecto en cada interacción 8,00% 5 0,4 4 0,32 3 0,24 4 0,32 5 0,4 4 0,32
Mantener comunicación directa con los interesados en el proyecto 4,00% 3 0,12 3 0,12 2 0,08 2 0,08 4 0,16 2 0,08
Elaboración de pruebas de adaptación 5,00% 2 0,1 3 0,15 2 0,1 3 0,15 4 0,2 3 0,15 Mantenimiento de la integración del
producto 2,00% 3 0,06 2 0,04 3 0,06 3 0,06 4 0,08 4 0,08
Facilidad para definir el alcance y objetivo del proyecto 3,00% 4 0,12 4 0,12 3 0,09 2 0,06 4 0,12 3 0,09
Identificación de riesgos del proyecto 3,00% 2 0,06 3 0,09 2 0,06 2 0,06 3 0,09 2 0,06
Facilidad para hacer un diseño simple 8,00% 1 0,08 4 0,32 5 0,4 4 0,32 5 0,4 5 0,4
Historias de usuario 5,00% 4 0,2 3 0,15 4 0,2 4 0,2 5 0,25 3 0,15
Adaptación a los cambios 11,00% 5 0,55 2 0,22 3 0,33 4 0,44 5 0,55 4 0,44 Facilidad de comunicación eficiente entre
equipo 7,00% 4 0,28 2 0,14 3 0,21 4 0,28 5 0,35 3 0,21
Facilidad de pruebas 11,00% 3 0,33 3 0,33 4 0,44 3 0,33 5 0,55 2 0,22 Facilidad para ajustar errores y realizar
correcciones 15,00% 2 0,3 4 0,6 5 0,75 3 0,45 5 0,75 4 0,6
Facilidad en la preparación de los datos y carga inicial del sistema 8,00% 5 0,4 2 0,16 2 0,16 2 0,16 4 0,32 3 0,24
Percepción de idoneidad desde la literatura consultada 5,00% 1 0,05 2 0,1 3 0,15 3 0,15 5 0,25 4 0,2
Percepción de idoneidad del grupo 5,00% 2 0,1 2 0,1 2 0,1 3 0,15 5 0,25 2 0,1
TOTAL 100,00% 3,15 2,96 3,37 3,21 4,72 3,34
El resultado final de la ponderación deja como la metodología idónea para el caso del banco a Scrum, sin embargo, otras metodologías también fueron bien calificadas.
42
Figura 3. Resultado final de la ponderación de la metodología ágil idónea para el caso del banco.
En lo que respecta a Crystal Methodologies esta obtuvo una ponderación de 3.15. Se destaca que es una metodología caracterizada por su enfoque en las personas que componen el equipo, indicando que son ellas de las cuales depende el éxito del proyecto, se caracteriza también por la reducción en el número de artefactos producidos (Pérez, 2015, p. 7). Así mismo el método Crystal cree que las habilidades y talentos de las personas, así como la forma en que se comunican, tienen el mayor impacto en el resultado del proyecto. El método Crystal se basa en dos supuestos fundamentales: el primero, que los equipos pueden optimizar sus procesos como su trabajo y convertirse en un equipo más optimizado, el segundo, que los proyectos son únicos y dinámicos y requieren métodos específicos.
Uno de los problemas de esta metodología de cara a las necesidades del banco, es que precisamente existe actualmente una alta concentración en el equipo de trabajo y se ha olvidado el enfoque en el cliente o el usuario.
De Adaptive Software Development (ASD) puede decirse que es un modelo de cual no se requiere establecer formalmente pasos preestablecidos, operando en un cambio constante, una reevaluación, un futuro incierto y una intensa colaboración entre desarrolladores, evaluadores y clientes, El ciclo de vida del modelo según Pérez (2015) tiene tres fases esenciales: especulación, colaboración y aprendizaje. ASD obtuvo una ponderación de 3.37 en el análisis. Si bien el modelo se acerca en algunas de sus características, el equipo del banco no desea dejar demasiado espacio a la especulación, dado que las necesidades
43
de clientes y usuarios del banco realmente se acotan a ciertas especificaciones concretas.
De Feature-Driven Development (FDD) se resalta precisamente lo que carece en ASD, la importancia de los detalles y las características, el modelo FDD destaca la importancia de las características del requerimiento dejando de lado la especulación. La ponderación alcanzada fue de 3.21.
Las calificaciones más bajas las obtuvieron las metodologías DSDM, Kanban y Scrumban
En cuanto a Dynamic Systems Development Method (DSDM), esta es una metodología ágil de carácter iterativo e incremental que se basa principalmente en la metodología de desarrollo rápido de aplicaciones (RAD) ya que se caracteriza por integrar la usabilidad, utilidad y la rapidez. Para el caso de estudio la metodología obtuvo una calificación de 2.96, una de las ponderaciones más bajos del análisis.
Pese al resultado, se reconoce que la metodología Dynamic Systems Development Method (DSDM), tiene cierta cercanía con los intereses del desarrollo de software en el banco, dado que dentro de sus principios se incluyen la colaboración directa y compartida entre los desarrolladores y los usuarios; la autogestión y el empoderamiento y el fomento de la visibilidad y la transparencia a través de la comunicación y la colaboración periódicas entre todos los interesados en el proyecto. Sin embargo, algunos aspectos negativos de cara a las necesidades del banco incluyen, que los entregables de software de trabajo se definen como sistemas que abordan las necesidades comerciales críticas actuales frente a los sistemas que abordan las necesidades futuras menos críticas, así como la entrega frecuente e incremental del software (Peréz, 2015, p. 19-20), situación que para el caso de estudio no es adecuado ya que se requieren productos terminados y funcionales en cada módulo.
En cuanto a Kanban Alonso (2017) indica que esta metodología no establece roles, lo cual es para el equipo de trabajo una necesidad, si bien se requiere dinamismo en la operación, se hace necesario que cada uno de los miembros del equipo tenga claro su rol dentro del proceso. Adicionalmente le literatura demuestra la crítica general a Kanban, asegurando que esta no corresponde con una metodología ágil:
44
“Este método ha sido criticado por algunos autores que no lo consideran un método ágil en sí mismo sino una herramienta que puede complementar a otras metodologías como la programación extrema o Scrum. De la combinación de Scrum y Kanban ha aparecido recientemente una nueva metodología denominada Scrum-ban” (Alonso, 2017, p. 46).
Scrumban es una metodología de desarrollo ágil fruto de la combinación de las metodologías Scrum y Kanban, Scrum como método de trabajo y Kanban para mostrar y visualizar el trabajo pendiente. Se considera una metodología útil para tareas de mantenimiento, pero de débil aplicación en casos de desarrollo como es el caso del banco.
Finalmente, Scrum se consolida como la primera opción luego de la ponderación con un valor de 4.72, la más alta y destacada por encima de cualquier otra metodología. Scrum a la luz de Pérez (2015) se entiende como una metodología ágil que le da importancia al establecimiento de prácticas y reglas, que reconoce la relevancia de la transparencia en el proceso y la adaptación de los requerimientos nuevos que nacen en medio de la construcción de uno o varios desarrollos, tal cual es la necesidad inmediata del banco.
Se considera la más idónea también porque permite crear el producto de diseño dividiéndolo en partes que para el caso del banco serían los módulos, de esta forma la construcción se logra en una secuencia, donde cada equipo se encarga de una parte para así centralizar su atención.
45
Figura 4. Diagrama de la metodología Scrum.
Tomado de: Diagrama de la metodología Scrum. Por. scrummethodology
De acuerdo a los casos de éxito revisados anteriormente y como sugerencia al interior del grupo de trabajo, se le realizarán 3 cambios a la metodología seleccionada, Esto con el fin de generar una más afinada versión de la metodología que se adapte mejor a los procesos existentes al interior del Banco:
Se utilizará un Tablero Kanban en vez del tablero tradicional de Scrum conel fin de tener un flujo continuo de actividades, también tener una mayor guíavisual del trabajo realizado.
Para Banco es muy importante que el estado del proyecto pueda serconocido rápidamente por cualquiera de los stakeholders, para lo cual el grupo detrabajo escogió esta herramienta que además de aportar una gran ayuda visual alequipo, permite que se revise al detalle o a nivel general el estado del proyectocon gran facilidad.
46
Se permitirá modificar la tarea solo hasta antes de entrar en flujo (Kanban)
De acuerdo en la definición de Scrum, al inicio de cada iteración se deben estimar la cantidad de recursos necesarios para que la tarea sea terminada y esta estimación sólo podrá ser modificada al finalizar la iteración. Para nuestro caso decidimos no cerrar la oportunidad de modificar la cantidad de recursos necesarios para terminar la tarea o en su defecto cambiar el enfoque de la tarea misma ya que contamos con mucha incertidumbre a la hora de la estimación inicial.
Se limitará el Wip (work in process o número de tareas que se pueden tener en paralelo en una de las posiciones del tablero) por estado del flujo de trabajo, No por iteración
Como no queremos restringir la colaboración que el grupo pueda proporcionar, limitando el número de tareas que se puedan ejecutar en simultáneo, se acordó con el grupo de trabajo, no limitar el wip de cada iteración. Para objeto de este documento, a la metodología scrum que incluye estos 3 aspectos adaptados a las necesidades del Banco de Occidente le denominaremos SCRUMBOC.
7.3 IMPLEMENTACIÓN DE UN PROYECTO PILOTO PARA LA ATENCIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE EN LAS UNIDADES GESTORAS DE TECNOLOGÍA DEL BANCO DE OCCIDENTE
Esta fase cumple el papel de implementar en el grupo de trabajo y en la empresa misma la idea de investigación. Se sugiere una primera subfase de diseño en la cual se determinará el nuevo procedimiento para el manejo de requerimientos de desarrollo de software, que atienden las unidades gestoras de tecnología del Banco De Occidente a partir de un caso de un requerimiento real de clientes o usuarios, el caso de la expedición de clave de tarjeta de crédito que fue solicitado en enero del año 2018.
47
7.3.1 Caso De Solicitud De Desarrollo: Reexpedición Clave De Tc Por Pin Pad
En el presente capítulo se expone un ejemplo de un caso de desarrollo de software, con el fin de ilustrar la forma como el banco, después de la intervención pasante, podría llegar a realizar los diseños de software. Para el 07 de enero del año 2018, la división comercial solicitó al equipo de la división tecnología, un desarrollo de software con el cual un cliente de tarjeta de crédito, logra realizar el cambio de clave por olvido desde la misma oficina, situación que anteriormente sólo podría realizarse vía correo físico. El departamento de diseño de software relata:
El olvido de las claves de tarjeta de crédito se había convertido en un asunto frecuente, especialmente considerando que muchos de los clientes de tarjeta de crédito corresponden a la población de adultos y adultos mayores. Los clientes reclamaban que por cuenta de la falta de la clave y la dificultad para recuperarla se perdía la oportunidad de utilizar la tarjeta para avances. Muchos incluso habían considerado la idea de adquirir productos de tarjeta de crédito en otros bancos que si brindaban una solución en la oficina misma (División tecnología, 2018).
7.3.2 Construcción Del Proyecto Piloto Usando El Scrumboc
El equipo de trabajo para la prueba piloto estuvo compuesto por el siguiente personal:
Equipo de desarrollo: John Cortes Javier Martínez Paola Mendoza Diana Sánchez
Scrum Máster: Jonathan Flaker
Dueño del producto: Alexander Gómez
Se realizarán 3 sprint, cada uno de 15 días hábiles (3 semanas), los cuales serán descritos a continuación:
El sprint 0, que fue de preparación, incluyó los siguientes aspectos:
48
● Completar y capacitar al equipo ● Obtener excepción para el uso del servicio actual que ofrece FD ● Solicitar transacción de cambio de clave por olvido de TC por oficinas a través
de ATH ENERO ENERO FEBRERO MARZO ABRIL MAYO JUNIO
SPRINT 0: 7 enero a 14 de Febrero
SPRINT 1: 15 de
Febrero a Abril 4
SPRINT 2: 7 Abril 5 a
Abril 30
SPRINT 3: 1 Mayo a
Junio 6
Figura 5. Product backlog cambio de clave por olvido TC.
En el sprint 1 se propuso como objetivo la generación de una funcionalidad en SOFIA (aplicativo Core del Banco usado en las oficinas), donde el usuario pueda cambiar su clave de TC por olvido. En el sprint 2 se propuso la creación de un nuevo proceso donde el cliente se acercará a la oficina para cambiar su clave de TC por olvido y en el sprint 3 se determinó por objetivo la creación de un nuevo proceso donde el cliente se acercará a la oficina en caso de que el CORE no se encuentre en producción después del 20 de abril.
Tres fueron los puntos de mejora continua identificados, el proceso de contratación de la persona de integración, la adquisición de portátiles para el proceso y los tiempos de respuesta de first data que resultaron siendo muy extensos.
Finalmente, el producto de desarrollo de software se entrega a la división del banco mediante un informe escrito denominado “formato de creación de diseño”, el cual ha sido creado para la presente pasantía y denominado para este caso Ti Mtsccq42601 Cambio De Clave Por Olvido Tc Desde Oficina, en el cual se observa el código aplicado al desarrollo, el control de versiones del desarrollo, la descripción del requerimiento, el detalle de los componentes existentes, el detalle de las funcionalidades y finalmente los casos de pruebas unitarias.
49
En cuanto a la descripción del requerimiento, esta relata la necesidad de clientes externos del banco:
Desarrollar las funcionalidades necesarias de manera que permitan disminuir el tiempo de reexpedición de clave de tarjeta crédito con el propósito de mejorar la experiencia del cliente y reducir costos en este proceso, ya que actualmente tiene un promedio de duración de 7 días
Figura 6. Diagrama de flujo cambio de clave por olvido TC – Proceso propuesto.
La figura 6 describe el proceso propuesto para el cambio de clave de tarjeta de crédito por olvido propuesto por el departamento de diseño de software. Se plantea inicialmente una validación biométrica por parte del asesor de barra mediante la aplicación ValidaCyza, el cual ante la positiva de la biometría, procedería a verificar que la tarjeta de crédito esté vigente y activada, luego revisará que si tiene algún bloqueo, este solamente sea por intentos errados de PIN. Dado caso que se cumplan las anteriores condiciones, el asesor de barra
50
imprime la validación biométrica y le asigna el caso a un asesor en caja, llevándole el documento de identificación junto con la respuesta de la biometría. El asesor de caja llamará al cliente para continuar con el proceso de cambio de clave, éste mediante SOFIA (Indicar) habilitará el Pin Pad para que el cliente digite y confirme la nueva clave para su tarjeta de crédito.
Cada uno de los diseños de los requerimientos de software es ilustrado tal y como se observa en la ilustración 6.
En cuanto al detalle de los componentes existentes, la ilustración 4 complementa el requerimiento al ubicar estratégicamente cada uno de los componentes dentro de la secuencia de diseño.
Figura 7. Diagrama de secuencia cambio de clave por olvido TC – Proceso propuesto.
51
En cuanto al detalle de las funcionalidades, el informe detalla la lista de Programas, archivos, paquetes requeridos para cada desarrollo de software específico. En este caso se mención al aplicativo Sofia propio del Banco, en el cual se crea una nueva unidad lógica con los siguientes campos:
● Tipo de tarjeta: Describe si corresponde a una tarjeta Crédito o Debito● Cuenta numero: No aplica● Nro. T. Crédito: Corresponde al número de la tarjeta● Nombre Titular TD: Nombre del titular de la Tarjeta● Tipo id Titular cuenta: Tipo de identificación del titular● Estado Tarjeta: Muestra el estado en el que se encuentra la tarjeta● Nueva Clave: Campo donde se ingresa la nueva clave● Confirmar Nueva Clave: Campo donde se ingresa la nueva clave
Así mismo se describe textualmente el proceso y se ilustra el resultado en pantalla del desarrollo:
Al deslizar la tarjeta de crédito a través del PIN PAD obtendremos el número de la misma en el campo Nro. T Crédito, el cual en el momento de perder el foco dispara la consulta la cual llenara el resto de campos con la información correspondiente. Una vez se tenga todos los campos, se procede a capturar la nueva clave a través del PIN PAD y posteriormente a confirmarla.(División tecnología, 2018).
52
Figura 8. Resultado del desarrollo de software requerido cambio de clave por olvido TC – Proceso propuesto.
53
Figura 9. Presupuesto destinado para el desarrollo de software requerido cambio de clave por olvido TC – Proceso propuesto, sin SCRUMBOC.
54
Tal y como se observa en la figura 9, a todo desarrollo de software le compete un presupuesto debidamente aprobado por el banco, en donde se considera el costo de los desarrollos y además de ello, un porcentaje de imprevistos. En casos anteriores, en el Banco de Occidente, el costo de los imprevistos llegaba a establecerse hasta en un 20% (en el presupuesto sin SCRUMBOC fue del 10%) que casi siempre se gastaba por efectos de sobrecostos en el proceso de diseño.
En la metodología tradicional resultaba prácticamente imposible definir cuánto tiempo le tomará al equipo alcanzar la meta de diseño, adicionalmente el trabajo mediante la metodología tradicional y la burocracia que le caracteriza habría ocasionado problemas no solo de efectividad sino también económicos para la empresa.
7.4 EVALUACIÓN DE LOS RESULTADOS PRESENTADOS DURANTE LA EJECUCIÓN DEL PROYECTO PILOTO
Dos tipos de evaluaciones pueden hacerse para medir el resultado del proyecto piloto de aplicación de metodología ágil para el desarrollo de software en el Banco de Occidente, una evaluación de la percepción del usuario y una evaluación financiera del proyecto. A continuación, se presentan los resultados.
7.4.1 Evaluación De La Percepción
Para la evaluación de la percepción de los resultados de la prueba piloto, se ha propuesto analizar comparativamente la imagen de la división tecnología ante los diferentes clientes internos de la empresa. Se ha obviado indagar sobre el cliente final dado que este desconoce muchos de las variables de diseño, por tanto son los clientes y usuarios internos los que mejor podrían responder ante dicha evaluación de la percepción.
Se propone indagar sobre seis variables específicas relacionadas con el diseño de software, las cuales a su vez se han considerado las de mayor impacto a lo largo de los productos de diseño solicitados a la división, las cuales son:
55
Comprensión de los requerimientos
Variable entendida como la capacidad del equipo por comprender de manera precisa la necesidad generando con esto la menor cantidad de correcciones posibles
Tiempo de respuesta
Variable entendida como el tiempo que le ha tomado a la división el desarrollo del software y la satisfacción por dicho tiempo
Calidad de los diseños Entendida como la percepción de que el producto es exactamente lo que se requería
Cantidad de correcciones Entendida como la cantidad de devoluciones del producto
Vinculación del cliente y del usuario en el diseño
Entendida como la forma como estos fueron vinculados en el proceso logrando con ello un mayor asertividad en el diseño
Satisfacción general Es la percepción general en suma de todas las variables posibles
Figura 10. Variables específicas de diseño de software.
Considerando que la prueba piloto representa un antes y un después en el paradigma de diseño aplicado (de metodología tradicional a metodología ágil), el pasante ha considerado comparar dos mediciones, la primera realizada a principio de año antes de hacer cualquier intervención, y la segunda evaluando el resultado del requerimiento tomado como prueba piloto. La medición se aplicará midiendo de 1 a 5 cada variable calificando con 1 un aspecto muy malo y con 5 un aspecto excelente.
De tal forma los resultados de la percepción representarán en la primera medida, la experiencia de los clientes internos a lo largo del tiempo de cara a los diferentes requerimientos y diseños de software, en la segunda, estrictamente a los
56
resultados de la prueba piloto. Los resultados fueron obtenidos por los siguientes clientes internos:
Canales Electrónicos Vicepresidencia Servicio al Cliente
Productos y Servicios Vicepresidencia de Empresas
Moneda Extranjera
Vicepresidencia de Tarjeta de Crédito
Arquitectura Vicepresidencia de Operaciones y Tecnología
Procesos y Proyectos Vicepresidencia de Servicio al Cliente
Auditoría
Core Banking Systems Vicepresidencia de Operaciones y Tecnología
Comunicaciones Vicepresidencia de Recursos Humanos
Operaciones Oficina Vicepresidencia Recursos Administrativos
57
Tabla 7. Análisis comparado de la percepción de los clientes y usuarios internos respecto del diseño de software antes y después
Siendo 1 muy malo y 5 excelente Responda
ANTES DE LA INTERVENCIÓN, ÚLTIMA MEDICIÓN REALIZADA EN ENERO DE
2018
DESPUÉS DE LA INTERVENCIÓN, MEDICIÓN REALIZADA EN AGOSTO
2018 / preguntas orientadas al caso de la prueba piloto
PREGUNTA PROMEDIO 1 2 3 4 5 6 7 8 9 10 PROMEDIO 1 2 3 4 5 6 7 8 9 10
Califique usted de 1 a 5 la comprensión
de los requerimientos de diseño de software
por parte de la división tecnología
2,4 3 2 3 4 2 3 1 1 2 3 4,2 4 4 3 5 4 5 4 4 4 5
Califique usted de 1 a 5 el tiempo de respuesta de los
requerimientos de diseño de software
por parte de la división tecnología
1,8 2 2 2 1 2 3 2 2 1 1 4,6 4 5 5 5 4 5 4 5 5 4
Califique usted de 1 a 5 la calidad del
diseño de software por parte de la
división tecnología
3,4 4 3 5 4 2 3 4 2 3 4 4,4 4 4 4 5 4 4 5 5 4 5
Califique usted de 1 a 5 la cantidad de correcciones que
debieron realizarse luego del diseño de software por parte
de la división tecnología
2 1 2 3 1 2 3 3 1 2 2 4,8 5 5 5 5 4 5 5 5 5 4
Califique usted de 1 a 5 la vinculación del cliente y del usuario
en el diseño de software por parte
de la división tecnología
2 2 2 1 2 2 1 3 2 3 2 4,6 4 4 5 5 5 4 5 5 4 5
58
Califique usted de 1 a 5 su satisfacción
general en el diseño de software por
parte de la división tecnología
2,6 3 2 3 2 4 1 2 4 3 2 4,3 4 5 3 4 5 5 3 5 4 5
El resultado final demuestra que la percepción en todas las variables analizadas
ha mejorado considerablemente luego de la prueba piloto.
Tabla 8. Análisis comparados de la percepción de los clientes y usuarios internos respecto del diseño de software antes y después, solos variables y resultados finales
VARIABLE ANTES
Promedio DESPUÉS Promedio
Comprensión de los requerimientos
2,4 4,2
Tiempo de respuesta 1,8 4,6
Calidad de los diseños 3,4 4,4
Cantidad de correcciones 2 4,8
Vinculación del cliente y del usuario en el diseño
2 4,6
Satisfacción general 2,6 4,3
TOTAL 2,37 4,48
Tabla 7. (continuación)
59
Figura 11. Análisis comparados de la percepción de los clientes y usuarios internos respecto del diseño de software antes y después, solos variables y resultados finales.
Dado lo anterior se confirma que ha modo de conformidad, la percepción da cuenta de una mejora en la calidad general del proceso de diseño, pasando de una percepción de 2.37 a una de 4.48 siendo 1 la peor percepción y 5 una apercepción excelente.
7.4.2 Evaluación Financiera
La segunda evaluación corresponde al análisis financiero de la intervención usando SCRUMBOC, el cual, debido a la naturaleza financiera de la organización, toma una mayor importancia a la hora de visualizar y entender los beneficios planteados en este trabajo. En primer lugar, se explicará la fórmula de Utilidad que se considera para el presente análisis:
Utilidad = (Cantidad x Precio) - Costos Fijos - Costos Variables
Para la cantidad y precio se ha tomado como base que la prueba piloto representada en el proyecto de reexpedición de clave de tarjeta crédito, logra ahorros en costos y para los costos fijos y variables se ha tomado el presupuesto ejecutado. Denominando Dinero Ahorrado al dinero que el banco invertía en gastos de envío a cada domicilio de los clientes y a la papelería que involucra el proceso de generar una nueva clave de antes de que se implementara el piloto y
60
Dinero Invertido a la cantidad ejecutada en la realización del piloto usando SCRUMBOC, la nueva fórmula de la Utilidad será:
Utilidad = Dinero Ahorrado - Dinero Invertido
Los datos iníciales están mes a mes desde Enero hasta Junio, sin embargo a partir de este último mes se proyectaron valores para poder compararlo frente a un proyecto de TODO o NADA que tardaría en estimación mínimo un año (estimación realizada con antelación) teniendo en cuenta un alcance más amplio, debe recordarse que alcance, tiempo y costo cerrado es lo que rige la planeación tradicional.
Considerando hasta el mes de Agosto, siendo ocho meses de duración (se considera diciembre para ver el punto cero o inicial). El eje vertical representa la Utilidad (Pesos Colombianos) y el horizontal es el tiempo en Meses.
Figura 12. Retorno de la inversión proyecto reexpedición de clave de tarjeta crédito con metodología ágil.
61
Con tres instalaciones en Abril, Junio y Agosto se evidencia que se empieza a recuperar en términos de la fórmula de Utilidad anteriormente indicada. Ahora compararemos con la proyección realizada para el desarrollo del mismo proyecto utilizando la metodología tradicional del Banco de Occidente y el cual además aún no ha tenido ningún beneficio (Azul es SCRUMBOC y Rojo Tradicional)
Figura 13. Comparación del retorno de la inversión proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional.
La diferencia en términos monetarios es de 152.6 Millones de Pesos, es una buena cantidad de dinero que cualquier empresario o gerente querría tener en el bolsillo o evitar gastarlo. Con esto ya se puede afirmar que el proyecto Ágil es un éxito frente a uno tradicional, pero es posible ir más allá y hacer varias proyecciones y ver otros aspectos importantes.
Responder por ejemplo a la pregunta ¿Cuánto tiempo pasara para que el proyecto ágil llegue a su punto de equilibrio?, es decir:
Utilidad = 0 (lo que se ganó es igual a lo que se invirtió)
62
Figura 14. Comparación del retorno de la inversión en clave de tiempo, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional.
De acuerdo a la ilustración anterior, tan solo 2 meses después de su puesta en marcha, el proyecto usando SCRUMBOC ya había superado su punto de equilibrio para empezar a generar Utilidad positiva. Se da una enorme diferencia con respecto al proyecto TODO o NADA, siendo esta diferencia de 247.4 Millones (dinero que ya nunca regresará).
Otra duda que puede surgir es, ¿Cuándo el proyecto tradicional recupera la inversión?, para esto se ha planteado un supuesto y es que el proyecto idealmente terminó según lo estimado inicialmente, un año después
Los resultados en la proyección demuestran que en septiembre (del siguiente año) lograría su punto de equilibrio (Utilidad = 0).
Se han revisado otras tres variables, primero el tiempo de diferencia que tarda en recuperarse, el cual arroja como resultado 11 meses:
63
Figura 15. Comparación del tiempo de diferencia que tarda en recuperarse la inversión, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional.
Así mismo, es posible estimar la diferencia mínima en Time to Market, punto crítico momento donde la competencia puede tener ventaja o desventaja, para este caso son 9 Meses de diferencia.
Figura 16. Comparación del Time to Market, proyecto reexpedición de clave de tarjeta crédito con metodología ágil y metodología tradicional.
64
Suponiendo que la ilustración representa una carrera entre estos dos competidores, metodología tradicional y ágil y el medidor deja de ser los kilómetros, para convertirse en dinero (pesos colombianos), la diferencia final obtenida, da por ganador al proyecto ágil con 418 Millones.
En conclusión, puede decirse que el resultado de la pasantía profesional de cuenta de una intervención que favorece a la empresa, en tanto se demuestra beneficios en la percepción de los clientes y usuarios, y beneficios económicos y financieros para la empresa.
Según el Cono de Incertidumbre de Steve McConell (1997) dicha estimación estaría en una variación desde un -25% hasta un +400% es decir para este caso, entre 9 Meses y 48 Meses (4 años).
Debido a que en el análisis solo se logró tener en cuenta los ahorros alcanzados, en este proyecto, también se generaron ingresos que son bastante complejos de estimar.
La presente representa una medición por proyecto y no por equipo, si se realizará por equipo debería medirse los entregables de los otros desafíos que lograron entregar en meses anteriores, pero se carece de esta información
65
8 CONCLUSIONES
Se logró adaptar una metodología ágil que fue denominada SCRUMBOC, a las necesidades del Banco de Occidente y se utilizó para la realización de un proyecto piloto, cuya evaluación financiera y de percepción fue bastante favorable.
A raíz de los resultados obtenidos en el proyecto piloto, se espera que la aplicación de la metodología SCRUMBOC para el desarrollo de los proyectos de tecnología, logre un cambio positivo en la percepción que tendrán los clientes internos, brindándoles soluciones más acertadas en un menor tiempo y a un costo inferior del requerido si se mantuvieran las metodologías tradicionales.
A pesar de que no se tenía el conocimiento concreto de las metodologías agiles, se está convencido de su aporte efectivo en la dinámica del Banco de Occidente, porque se logra un trabajo multidisciplinario y contacto con las diferentes áreas del banco, que redunda en soluciones informáticas que mejoran significativamente la experiencia de los clientes del banco.
66
REFERENCIAS
Andriano, N; et al. (2012). Implementación de metodologías ágiles mediante herramientas automáticas de definición de procesos. Cordoba Argentina: Departamento de Ing. en Sistemas de Información Universidad Tecnológica Nacional.
Banco de Occidente. (2013). Informe generación valor social. Colombia: Banco de Occidente.
Banco de Occidente. (2017). Resultados Encuesta Nacional del Cliente Interno. Colombia: Banco de Occidente.
Blanco, D., y Cortés, M. (2015). Guía metodológica para la gestión de proyectos de software. Bogotá: Pontificia Universidad Javeriana.
Herrera, E., y Valencia, L. (2007). Del manifiesto ágil sus valores y principios. (U. T. Pereira, Ed.) Revista Scientia et Technica, 13 (34), 381-385.
Martínez Gaviria, V. M. (2010). Impacto del Área de Recursos Humanos del Banco de Occidente en Pereira. Pereira: Universidad Católica Popular del Risaralda.
McConnell, S (1997). Software Project Survival Guide, Microsoft Press.
Pardo, C; et al. (2010). Mejora de procesos de software ágil con Agile - SPI Process. Revista Dyna , 77 (164), 251-263.
Pérez, C. (2015). Una metodología ágil para el desarrollo de software en una compañía financiera. Bogotá: Universidad Militar Nueva Granada.
Ruiz, J. I. (2012). Metodología de la investigación cualitativa. Distrito de Deusto: Universidad de Deusto.
Tamayo, J. (2013). Practicas agiles para el desarrollo de software en semilleros de investigación. Medellín: Universidad Pontificia Bolivariana.
