ENSAYO:" 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 “ágiles” 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
metodologías á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:
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:
·
http://www.javiergarzas.com/metodologias-agiles
·
http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/
·
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
·
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
·
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
COLABORADORES:
JORGE LÓPEZ PARRA
CÓDIGO: 066111033
JULIAN EDUARDO RINCÓN ROZO
CÓDIGO: 066111054
DAVID ESTEBAN RODRIGUEZ GÓMEZ
CÓDIGO: 066111004
JUAN PABLO VILLAMIL ROMERO
CÓDIGO: 066111010
