El éxito de una metodología radica en saber
cuándo, cómo y por qué usarla.
El desarrollo de software ha venido evolucionando en los últimos años, a
causa de las necesidades que requiere la humanidad para hacer más fácil su
diario vivir. No obstante, los ingenieros y los desarrolladores han tenido que
asumir retos importantes, encaminados a brindar un producto software de alta
calidad, que cumpla con las expectativas de usabilidad, integridad, fiabilidad,
eficiencia, flexibilidad, escalabilidad, modularidad y seguridad. Es ahí, donde
toma gran importancia el entender las metodologías de desarrollo de software
como el conjunto de procedimientos, técnicas y un soporte documentado que garantiza un trabajo estructurado, planificado
y controlado en el proceso de elaboración de sistemas de información.
Cuando se emprende
en un proyecto de software, se tiene la convicción, que para crear un producto
de alta calidad, es pertinente escoger una metodología robusta y rigurosa. Por
ejemplo la metodología RUP ( Rational Unified Process) esta es una metodología
que maneja un enfoque de asignación de tareas y responsabilidades dentro de una
organización. Tiene como objetivo principal la aseguración de la producción de
software de alta calidad para satisfacer las necesidades del cliente dentro de
un tiempo prudencial y previsible. Esta metodología está enfocada a la
utilización de diagramas de casos de uso, manejo de los riesgos y de la
arquitectura. Tiende a manejar desarrollos iterativos, el ciclo de vida que
utiliza es espiral para establecer tanto tareas, como fases e iteraciones,
donde es posible manejar complejidad en varias etapas del proyecto.
RUP, presenta unas
fases definidas para completar sus iteraciones, la primera de ellas es la fase
de inicio, centrado en el modelamiento de los requerimientos, buscando siempre
lo que se necesite, para utilizar los recursos, mejorándolo y dándole una
visión del proyecto, la segunda fase es la elaboración centrado en el
desarrollo de los casos de uso tomando
como principio el diseño, la tercera fase que es la de construcción, se lleva a
cabo la construcción del software por
medio de iteraciones que, se utilizan los casos de uso, definiendo su análisis,
luego su implantación y posteriormente las pruebas, finalmente la última fase
es la de transición, donde se busca garantizar que el producto este en óptimas
condiciones para ser entregado al usuario. En cada fase se realizan una serie
de artefactos, que son utilizados para comprender no solo el análisis sino el
diseño de los datos, el primer artefacto es el inicio, para generar un
documento de visión y una especificación de requerimientos, en la elaboración
son los diagramas de casos de uso, en la construcción el documento de
arquitectura que tiene las siguientes vistas, la vista lógica maneja diagrama
de clases y modelo de entidad relación, en la vista de implementación, el
diagrama de secuencia, estados y colaboración, en la vista conceptual el modelo
de dominio y la vista física el mapa de comportamiento del software.
Como toda metodología
tiene unas características que lo identifican,
la primera de ellas es un forma
disciplinada de asignar tareas y responsabilidades, implementar mejores
prácticas de ingeniería de software, manejo de desarrollo iterativo, utiliza la
administración de requisitos, utiliza la arquitectura basada en los
componentes, maneja controles de cambios, maneja un modelo visual de todo el
software, y verifica la calidad del software. Así mismo esta metodología maneja
unos principios claves, como es la adaptación del proceso, donde el proceso se
adapta a las características de la organización, otro es el balanceo de
prioridades, la colaboración entre equipos, con comunicación fluida para
coordinar requerimientos, demostrar el valor iterativamente, se debe motivar el
concepto de reutilización y enfocarse en
calidad.
Sin embargo, RUP
como metodología tradicional, es
renuente a cambios que se puedan dar durante el desarrollo de proyectos de
software que presenten un grado de incertidumbre en un entorno volátil; y que es necesario para ir detectando y
corrigiendo errores que puedan generar múltiples fallas imposibles de manejar
en el sistema de información que se esté construyendo. Por tal razón se busca
metodologías de desarrollo agiles que se ajusten a entornos cambiantes y llenos de presiones;
donde los ciclos de desarrollo sean cortos y se incremente las funcionalidades
en cada iteración, sin afectar la rigurosidad que ofrecen las metodologías
tradicionales.
Al entrar al
contexto de las metodologías ágiles, se debe pensar en que son técnicas que
surgieron como contraparte a métodos del
CMMI, y se han ido expandiendo a gran cantidad de proyectos que hoy día se
trabajan. Muchas compañías optan por ello precisamente por lo “agiles” al
momento de desarrollar rápidamente proyectos en cortos tiempos. Es necesario
tener en cuenta algunos principios que son agrupados en 4 valores. El primero
de ellos son los individuos y la
interacción que tendrá más importancia que las herramientas que se vayan a
utilizar, el segundo de ellos que el software funcione, por encima de
documentación y procesos complejos y exhaustivos, el tercero de ellos se enfoca
en la colaboración con el cliente, ya que se centra en estar siempre con el
cliente, apoyarlo y hacerlo parte del proceso y el cuarto y último es la
respuesta al cambio, donde pueda haber no solo adaptabilidad sino acceso al
manejo de cambios que deban ser necesarios realizar, por encima de cualquier
plan que se haya construido minuciosamente.
Existe un paradigma
al trabajar metodologías ágiles y es que se asocia a que agilidad es sinónimo
de no trabajar documentación o control sobre el proyecto, que es sencillamente
realizar el proyecto, acompañar e incluir al cliente y que todo funcione, esto
no es verdadero, ya que es diferente minimizar todas las tareas que no son
influyentes e importantes en el proyecto para llegar a cumplir todos los
objetivos del proyecto, que hablar solamente de desarrollar, codificar, probar
y hacer funcionar. Esto lleva a pensar que las metodologías ágiles no son
perfectas y no se pueden aplicar en todo momento, dependen principalmente de
donde se desee enfocar y lo que se vaya a aplicar
Un punto a favor de
las metodólogas ágiles son en su mayoría todos aquellos proyectos referentes a
tecnología o llamados tecnológicos, cada una de ellas tiene sus ventajas y
debilidades, inclusive puede darse casos en que una sola metodología pueda no
ser suficiente y se deba apoyar en otra dependiendo las características y
funciones dadas en el proyecto. Algunas de las más reconocidas son las
siguientes:
Metodología
|
Descripción
|
SCRUM
|
Puede ser definido como un marco de
trabajo que brinda herramientas y roles de manera iterativa, para visualizar
el progreso del proyectos y resultados que se vayan generando
|
KANBAN
|
Su foco principal es el trabajo en
curso (Work in Progress), basado en no debe trabajarse algo nuevo en el
proyecto cuando no se haya terminado un proceso anterior o un bloque y este
haya sido finalizado y entregado
|
XP
|
Una de las más comunes y
utilizadas, no solamente en ámbito empresarial, sino académico, busca mejorar
las relaciones interpersonales en el grupo, influyendo en el éxito del
desarrollo del software, promueve que se haga trabajo en equipo, procura un
buen clima de trabajo tanto para todo el grupo, como para los desarrolladores
|
En el momento de
elegir una metodología de desarrollo ágil, se deben tener cuenta algunos puntos
clave como que se va a desarrollar, que tipo de proyecto se iría a realizar,
que debilidades y fortalezas tiene, se recomienda que todos los cambios que se
manejen en metodologías ágiles no deben ser cambios bruscos o fuertes, pero si
pueden adaptarse de pequeños progresos de cambios, otro punto a tener en cuenta
es que el cliente final o el usuario que vaya a utilizar la aplicación juega un
papel clave durante todo el proceso del proyecto, pero si no se tomara el
cliente como parte importante, es mejor desistir de metodologías ágiles
Pero no solamente
se trabajan metodologías ágiles, en algunos casos puede que estas no sean muy
efectivas o sirvan. Las metodologías tradicionales tienen mejor cabida en
proyectos donde se conoce el problema y la solución está bien definida. Si se
conoce el problema, la solución y el entorno, se puede analizar, diseñar y
ejecutar una solución de manera fácil. Los startups son organizaciones
temporales donde pueden moverse en zonas con mucha incertidumbre que busca un
modelo de negocio que pueda ser escalable y replicable. Aquellos startups que
sean capaces de seguir el enfoque Lean, plantea varias hipótesis sobre un
problema que se presente y experimenta diversas formas de solucionarlo, para
hallar la forma correcta, es decir que se trabajan en entornos muy cambiantes,
para estos casos las metodologías agiles juegan un papel muy importante, ya que
pueden realizar gestión de cambio que implican un esfuerzo menor. Por lo que
hay que definir para quien es que metodología y para quien no, todas aquellas
metodologías que se relacionen con Lean Startup se encarga de la construcción,
en cambio las metodologías ágiles se enfocan en el cómo se realizaría
Metodología XP
Revisando algunos las
metodologías ágiles que son influyentes en el medio, se abre la puerta de la
más común de todas y quizás una de las más utilizadas en cualquier ámbito de
desarrollo, y es la metodología XP, esta es definida como un enfoque dado en la
Ingeniería del Software que fue formulada por Kent Beck. XP traduce eXtreme
Programming, o en nuestro vocablo programación extrema, se desvía en trabajar
la factibilidad que la previsibilidad, aquellos que defienden esta metodología
sugieren que los cambios son algo natural y deseable en cualquier proyecto que
se desee realizar, se piensa que es capaz de adaptarse a cambios en cualquier punto vital del proyecto
aproximándose con más realidad al proyecto defiendo requisitos iniciales y
controlando los cambios que se generen. Al analizar esta metodología no se
centra en entregar cambios muy grandes o bruscos, al contrario deben ser
pequeños y controlables, que sean rápidos de desarrollar y actualizar, para que
este pueda ser evaluado en ambientes reales, se considera que las entregas
trabajadas no deben ser mayor a dos a tres semanas máximo. Para entender esta
metodología debe comprenderse en 4
puntos focales, el primero de ellos habla del diseño, este debe ser simple, se
deben cumplir los requerimientos con un programa que sea sencillo se denomina
(Simple Design), que busca cumplir las necesidades inmediatas del cliente, puede
rejuvenecer procesos antiguos y eliminar redundancias. La metáfora viene siendo
el segundo punto que se desarrolla por aquellos que tienen el rol de
programadores desde el inicio, definiendo historias de cómo debe funcionar el
sistema en su totalidad, XP permite trabajar y utilizar estas historias que son
vistos como pequeñas descripciones de un trabajo, reemplazando todos los
diagramas UML. Otro elemento que se trabajan son las tarjetas CRC (Clase,
Responsabilidad, Colaboración) también permiten definir actividades en el
momento del desarrollo. Cada tarjeta puede representar una clase en la
programación que se orienta a objetos definiendo responsabilidades y
colaboradores de esa clase. El tercer punto es la propiedad colectiva del
código, que debe tener propiedad compartida, es decir todos son propietarios
del código, no se destaca el individualismo, se argumenta que entre más gente
se trabaje menos errores deben aparecer. El cuarto y último habla de estándar
de codificación que permite definir la propiedad del código tanto para
escribir, como documentar el código y todas las diferencias de trozos o piezas
de código desarrollada por diferentes equipos. Todos los programadores deben
tener la visión holística para poder unir estos trozos y ver como si un solo
programador hubiera escrito todo el código de manera armoniosa.
Los objetivos en
que se centra la metodología XP, es crear mejores prácticas de todos los
desarrollos hechos en los proyectos, permitir mejorar toda la productividad en
el proyecto, garantizar que la calidad del software supere todas las
expectativas del cliente, y asumir que con niveles de planificación,
codificación y pruebas poder decidir si se está siguiendo el camino que es o
no, para evitar retrocesos enormes. Pero no solamente se centra en el bienestar
del proyecto, sino de todos los programadores, ya que es necesario no agotar a
los programadores, ya que si estos están cansados, podrían escribir código de
menor calidad, se debe minimizar horas extras, mantener al personal fresco,
pueden generar código de calidad y pertinente, es decir se recomienda 40 horas
a la semana.
Entre las
características que trabajan la metodología XP, pueden enfocarse en que esta se
basa en prueba y error para obtener un software que funcione, se fundamenta en
principios, se orienta hacia quien se produce el software y cómo va a ser
utilizado, puede reducir el coste de cambios de ciclo de vida del sistema,
trata de combinar las mejores prácticas para utilizarlas y llevarlas al
extremo. El cliente debe estar bien definido (es decir saber quién es), Los
requisitos pueden ser cambiantes, puede trabajarse en un grupo de 2 a 12
personas trabajándose en parejas, equipo con gran formación y capacidad para
aprender. Los principios que maneja esta metodología son la simplicidad, es
decir resolver todas las necesidades que se muestren en el momento y
desarrollar lo necesario, el feedback, indica que se basa en iteraciones pequeñas con entregas y pruebas, la decisión
es saber tomar decisiones o reparar un error detectado o mejorar el código de
feedback pasados, la comunicación se vuelve fundamental para colocar en
contacto directo a clientes y desarrolladores.
Las prácticas
fundamentales son el equipo completo, ya que todos tienen que ver algo con el
proyecto, se planifica por medio de las historias de usuarios, generando orden
y revisión continua, el test del cliente propone validaciones para realizar
pruebas, pequeñas versiones que pueden ser desarrolladas en pocas semanas, debe
tener un diseño simple, la programación debe darse por parejas, el desarrollo
se guía por pruebas automáticas se
ejecutan con frecuencia, debe realizarse integración continua, es decir cuando
se ejecuten nuevas funcionalidades, compilar y ejecutar, el código es
compartido, se deben respetar normas codificadas, buscar frases para definir la
función de distintas partes del programa y trabajar a un ritmo que pueda ser
constante y sin detenerse.
Las ventajas que
brinda al trabajar la metodología XP, es trabajar la programación organizada,
reduciendo la tasa menor de errores y permitir satisfacer al programador,
facilitar cambios, permitir ahorrar mucho tiempo y dinero, el cliente puede
tener control sobre las prioridades y se hacen pruebas continuas del proyecto,
como todo posee algunos inconvenientes o debilidades donde se recomienda
trabajar en proyectos de corto plazo, requiere un rígido ajustes a todos los
principios del XP, puede de entrada no ser fácil si se está familiarizado con
metodologías tradicionales y generar altas comisiones. Pero trabaja mucho a las
personas y las relaciones entre las personas, se manejan roles específicos como
el programador que puede escribir las pruebas y el código, el cliente escribe
sus historias de usuario y valida el proceso, el tester permitir al cliente
validar las pruebas funcionales, el tracker se encarga de realizar el seguimiento
sobre todo en estimaciones y tiempo real, el entrenador responsable de todo el
proceso global, guiando a todos los miembros del equipo, el consultor que es
externo al equipo pero con conocimientos necesarios para el equipo y proyecto,
y el gestor (Big Boss), que sirve de vínculo entre los clientes y programadores
Metodología SCRUM
Esta metodología
aplica conjuntos de buenas prácticas para trabajar de manera colaborativa en un
equipo, permitiendo alcanzar el mejor resultado posible en el proyecto. Utiliza
un marco de desarrollos ágiles que tienen características como adopción de
estrategias que permite generar un desarrollo incremental, en lugar planificar
y ejecutar completo el producto, tener como factor clave el conocimiento tácito
de las personas que en la calidad de procesos de empleados, a la hora de
pensarse en la calidad del resultado. Uno de sus objetivos principales es
maximizar el retorno invertido para el proyecto en una empresa. Tiene como base
construir la funcionalidad de mayor valor para el cliente o usuario final y
actos seguidos los principios de inspección, adaptación, auto-gestión e
innovación.
Al trabajar SCRUM,
se realizan entregas parciales y regulares del producto finalizado. Está
centrado especialmente en proyectos que son complejos, donde se requiere
obtener resultados muy pronto, donde los requisitos pueden ser cambiantes o no
están muy bien definidos, donde se tiene factores relevantes como la
innovación, competitividad, flexibilidad y competitividad. Posee muchos
beneficios al trabajar esta metodología como el cumplimiento de expectativas,
donde se le permite al cliente establecer las expectativas indicando el valor
de cada requisito, el segundo es que muy flexible y adaptable a cambios, que
puede darse por momentos cambiantes de las necesidades del cliente o evolución
dada en el mercado, el tercero permite reducir el time to market, es decir que
el cliente puede usar las funcionalidades que sean más importantes en el
proyecto sin haberlo finalizado, el cuarto es trabajar una mayor calidad del
software, ya que se realiza un trabajo metódico al obtener un resultado en cada
iteración, el quinto es obtener mayor productividad, por la eliminación de
burocracias y motivar al equipo que sea autónomo para organizarse, el sexto se
enfoca predicciones de tiempos, donde puede conocerse la velocidad del equipo
en los sprint (puntos historia), por lo que permite estimar con facilidad
cuando estará disponible una nueva funcionalidad en el proyecto, y la última
pero no menos importante reducir riesgos, ya que se lleva como prioridad las
funcionalidades de nuevo valor y conocer la velocidad de avance, despejando
riesgos de manera anticipada.
El proceso manejado
en SCRUM el proyecto se realiza en ejecución de bloques cortos y fijos. Cada
iteración debe proporcionar un resultado completo, al igual que en XP, se
manejan las iteraciones en el proyecto, pero con unas pequeñas diferencias,
donde al planificar la iteración se debe tener en cuenta como primer punto la
selección de requisitos, donde el cliente presenta al equipo todos los
requisitos considerados importantes en el proyecto, el equipo busca indagar
cuales requisitos son los más primordiales para comprometerse a completarlos en
la iteración, el segundo punto es ya en planificar la iteración, donde el
equipo realiza una lista de tareas a desarrollar en la iteración, el esfuerzo
se mide de manera conjunta y los miembros del equipo se auto asignan tareas a
cumplir. Cada iteración si tiene contemplada que dure 1 mes, con un plazo
ampliado de 6 semanas máximo, al ejecutar cada iteración se realizan reuniones
de sincronización inspeccionando el trabajo que se ha realizado, para poder
cumplir con los compromisos que han sido adquiridos, en cada reunión se debe
responder a tres interrogantes que son ¿Qué se ha hecho desde la última reunión
de sincronización?, ¿Qué se va a realizar desde este momento? y ¿Qué
impedimentos se van a presentar?. Durante todas las iteraciones el facilitador
tiene la tarea de que verificar que todos los miembros cumplan con sus compromisos
adquiridos, eliminando aquellos obstáculos que el equipo no ha podido superar y
proteger al equipo de interrupciones externas que pueden afectar el avance y
productividad en la iteración. Ya entrando al último día de la iteración se
realiza una revisión que se compone de dos partes, la primera de ellas en
demostrar los requisitos completados al cliente en la iteración, y los
resultados mostrados, teniendo en cuenta cambios y adaptaciones necesarias de
manera objetiva, desde la primera iteración, que permita replanificar el
proyecto, el segundo de ellos es la retrospectiva donde el equipo analiza su
ritmo y forma de trabajo y que problemas u obstáculos pueden impedir avances
sean mínimos como significativos, para ser tenidos en cuenta ay mejorar la
productividad. Al igual que en le metodología XP, se trabajan unos roles
importantes que para este caso se caracteriza en primer lugar el scrum master
es quien lidera al equipo para que pueda cumplir la metodología al pie de la
letra, gestiona todos los impedimentos que intervienen en los avances y trabaja
con el product owner para maximizar el ROI (Inversión de Retorno), el product
owner es el representante de los accionistas y clientes del software focalizado
en parte del negocio en el ROI, traslada la visión del proyecto a todo el
equipo, que formaliza las prestaciones en historias, y el team es el grupo de
profesionales que poseen los conocimientos necesarios, quienes desarrollan el
proyecto de maneja conjunta con las historias.
En SCRUM, se maneja
una documentación específica, uno de ellos se le conoce como el product
backlog, como documento de alto nivel para el proyecto, es un conjunto de
requisitos en el proyecto, que tiene descripciones de funcionalidades de manera
general, solo puede ser abierto y modificado por le product owner. El sprint
backlog es un subconjunto de requisitos desarrollados, se describe como se
implementaría los requisitos durante el spring. Todas las tareas en el sprint
backlog son tomadas por todos los miembros. El burn down chart es una gráfica
mostrada que mide la cantidad de requisitos en el Backlog del proyecto mientras
se comienza cada Spring.
Una vez viendo
estas metodologías, puede concluirse que no todas las metodologías pueden
utilizarse para lo mismo, es decir tiene ciertas restricciones que, permite que
sean empleadas y utilizadas dependiendo del proyecto a trabajar, la prioridad
del proyecto, lo que se quiere hacer, que cada una trabaja un roles diferentes,
un modo único de realizar y ver iteraciones para la entrega del proyecto, que
puede trabajarse para proyectos simples y cortos, o complejos y que requieren
resultados, que puede enfocarse en los miembros del equipo o la calidad del
proyecto y el personal involucrado. Es por ello que debe analizarse de manera
centrada que metodología es la correcta a trabajar dependiendo del proyecto que
se va a cumplir, no cuál sería la mejor.
Bibliografía
Utilizada:
Metodología ágil
·
http://www.javiergarzas.com/metodologias-agiles
·
http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/
Metodología XP
·
http://es.slideshare.net/Piskamen/metodologa-xp
·
https://procesosdesoftware.wikispaces.com/METODOLOGIA+XP
·
https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema
·
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
Metodología SCRUM
·
https://es.wikipedia.org/wiki/Scrum
·
http://proyectosagiles.org/que-es-scrum/
·
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum/proceso-roles-de-scrum.html
Metodología RUP
·
https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
·
http://rupmetodologia.blogspot.com.co/2012/06/fases-de-la-metodologia-rup.html
·
http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
·
http://es.slideshare.net/cortesalvarez/metodologa-rup
Este ensayo se realizó con colaboración de
David Esteban Rodriguez
Jorge Lopez Parra
Juan Pablo Villamil Romero
Julian Eduardo Rincon Rozo
