Articulo Scrum Vs Rup

Descargar como doc, pdf o txt
Descargar como doc, pdf o txt
Está en la página 1de 8

Comparativa entre metodologías SCRUM y RUP

Hugo Eduardo Carvajalino Solano


Ingenieria de sistemas
Universidad Francisco De Paula Santander, Ocaña
[email protected]
Resumen- Las metodologías software, donde se almacena Otros métodos proponen que hay que reducir el tiempo
de desarrollo de software ágil toda la información en bases de centrarse en la organización del de creación pero sin dejar de
y flexible a medida que pasa datos, aplicaciones móviles, y equipo de trabajo, incluir al todo la calidad del software.
el tiempo han tomado una haciendo uso en su gran cliente activamente y en arrojar Las metodologías
gran importancia en el mayoría de aparatos resultados satisfactorios más convencionales presentan para
desarrollo de objetivos para electrónicos. rápidamente. este tipo de proyectos los
cubrir las necesidades Independientemente de la siguientes inconvenientes:
planteadas y en la ejecución Entre los objetivos de la metodología es conveniente
de las labores de la ingeniería ingeniería de software están: saber que éstas se eligen e 1. Es necesario conocer desde el
de sistemas específicamente, implementan de acuerdo a la inicio qué desea el cliente.
en especial en el campo de naturaleza del proyecto, 2. No se deben de cambiar los
desarrollo de software y/o ● Mejorar el diseño de direccionando todas las requisitos iniciales puesto que a
ingeniería de software, ya sea aplicaciones o software de metodologías para cumplir con medida que se sigue
para beneficio del equipo de tal modo que se adapten un mismo fin, llegando incluso construyendo el proyecto las
desarrollo como para el de mejor manera a las a combinarse entre sí para modificaciones y la corrección
cliente. De manera general necesidades de las lograr mejores resultados. [1] de los errores es más costosa.
se puede definir a la organizaciones o Además todos los cambios que
metodología de desarrollo finalidades para las cuales En el desarrollo de este artículo se produzcan los sufrirá
ágil como un marco de fueron creadas. se encontrará una presentación económicamente el cliente.
trabajo conceptual de la ● Promover mayor calidad al de la metodología Rational
ingeniería de software que desarrollar aplicaciones Unified Process (RUP) de IBM
promueve interacciones en el complejas. que a pesar de su rigurosidad y
desarrollo a lo largo de todo ● Brindar mayor exactitud alta documentación, es un
el ciclo de vida del proyecto. estándar altamente usado en el
en los costos de proyectos
Dentro de las metodologías de desarrollo de software, también
y tiempo de desarrollo de
desarrollo ágil encontramos la se expondrá la disciplina
los mismos.
metodología SCRUM, la cual SCRUM basada en la rapidez y
● Aumentar la eficiencia de flexibilidad de métodos de
es considerada por los
los sistemas al introducir desarrollos ágiles ampliamente
desarrolladores como la más
procesos que permitan usados en la industria de
flexible y compatible ya que
medir mediante normas productos comerciales.
cumple con las necesidades y
específicas, la calidad del
requisitos que se requieren en Luego se realizará una
software desarrollado,
la ejecución del trabajo; se comparación de ambas
buscando siempre la mejor
puede mencionar que este tipo metodologías (SCRUM- RUP),
calidad posible según las
de metodología está más teniendo en cuenta las ventajas
çnecesidades y resultados
enfocada a personas y no a y desventajas de cada una de
que se quieren generar. Fig. 1. Modelo costo del
procesos, al funcionamiento ellas, dando así a conocer la
del sistemas y no a la ● Una mejor organización de cambio vs tiempo.
equipos de trabajo, en el propuesta híbrida, tomando
documentación, a la como referencia la construcción Fuente:
colaboración y no al área de desarrollo y
de proyectos con las mejores https://mail.google.com/mail
contrato(esto refiriéndose a la mantenimiento de
software. prácticas de las dos /u/0/?
relación con el cliente), y en la metodologías contrastadas. ui=2&view=btop&ver=17cyo
adaptación y no al ● Detectar a través de
pruebas, posibles mejoras Finalmente se darán unas 9bg6h587&q=scrum&qs=tru
seguimiento de planes. Por
para un mejor conclusiones analizando el e&search=query&th=14cc35
otra parte se halla la proceso llevado a cabo durante
metodología RUP, funcionamiento del ee6f95bdd1&qt=scrum.1.scr
software desarrollado. este trabajo. ums.1&cvid=2
considerada como la más
tradicional o estándar usada
para el análisis, Para dar cumplimiento a los
CONTENIDO 3. Se establecen mecanismos
implementación y objetivos de la ingeniería de de control para el proyecto
documentación de sistemas software y poder desarrollar de METODOLOGÍAS que a veces dan sensación de
enfocados a objetos. manera eficiente aplicaciones AGILES inflexibilidad a posibles
móviles y software, se hace cambios y que de hacerlo
necesario implementar Las metodologías ágiles surgen
Palabras Clave- metodologías de desarrollo ágil
incrementaría el coste.
como una alternativa a las
Metodología, RUP, SCRUM, que permitan llevar a cabo la 4. Excesiva documentación
metodología tradicionales las
Desarrollo de software, ejecución y producción de cuales, tal y como acabamos de
que a veces incluso no es
Ingeniería de software. software de manera flexible y ver en los apartados anteriores útil.
compatible, cumpliendo con las son demasiado burocráticas y 5. Quizás este sería el punto
necesidades y requisitos por tanto rígidas para las más importante, “la lentitud”
INTRODUCCIÓN necesarios para su realización. actuales características del del desarrollo. Hoy en día
mercado. para ser competitivos es
Cada metodología existente Años atrás la evolución de los necesario la agilidad y
La ingeniería de software es tiene un enfoque diferente para
una disciplina de la informática productos era lenta y se flexibilidad a la hora de la
la captura de requerimientos y producía siempre en un entorno
que aporta métodos y técnicas creación de los productos.
para su proceso de desarrollo, estable el que apenas había
para desarrollar y diseñar algunas se basan primero en 6. Las metodologías
variaciones.
software de calidad que estén al analizar y documentar los tradicionales se encuentran
frente en la solución de Hoy en día sin embargo el
detalles del sistema, para así entorno en el que se mueve el con las dificultades al final
problemas que se presenten. realizar el diseño, desarrollo y del proyecto, lo que termina
Actualmente las compañías software es demasiado inestable
pruebas de éste. y cambiante por lo que estas retrasando las entregas.
dependen de gran manera del
metodologías no se adaptan, ya
realiza con la figura que todo al principio del
representa al cliente. proyecto.
El representante del cliente 4. Se trabaja en equipo entre
es necesario como elemento el cliente y los
de apoyo para los desarrolladores mediante
desarrolladores puesto que una comunicación casi diaria
será la persona a la que se para evitar errores y
podrán hacer las preguntas documentación innecesaria.
necesarias y que junto con el 5. Eliminar el trabajo que no
resto de personas es necesario y que realmente
involucradas en el negocio no aporta un valor al
comprobarán si se cumplen negocio.
Fig. 2. Modelo impacto del los objetivos. 6. Buscar la mejor técnica y
riesgo vs tiempo. Por lo tanto trabajar con una el mejor diseño para
Fig. 3. Metodología RUP.
Fuente: buena comunicación permite conseguir productos de
Fuente:
https://mail.google.com/mail que se puedan tomar las calidad.
http://rupmetodologia.blogsp
/u/0/? decisiones de forma más 7. Mejorar los procesos y al
ot.com/
ui=2&view=btop&ver=17cyo rápida y aplicarlas. equipo que realiza el
9bg6h587&q=scrum&qs=tru La característica realmente desarrollo. La metodología RUP se destaca
e&search=query&th=14cc35 nueva que aportan estas por:
ee6f95bdd1&qt=scrum.1.scr metodologías es reconocer a METODOLOGÍA RUP
ums.1&cvid=2 las personas como el (RATIONAL UNIFIED ● Forma disciplinada de
principal valor para que un PROCES) asignar tareas y
Todos estos inconvenientes proyecto consiga terminarse responsabilidades
han hecho que las de forma correcta. “El factor RUP fue desarrollado por (quién hace qué,
metodologías clásicas no más importante en el Rational Software y ahora cuándo y cómo)
hayan sido capaces de desarrollo de software no son perteneciente a IBM. Se basa en ● Pretende implementar
las técnicas y las un marco de procesos de trabajo las mejores prácticas
eliminar los fallos y que
que pueden ser adaptados por en Ingeniería de
haya una explosión de herramientas que emplean
las organizaciones que hagan el Software.
creación de software los programadores, sino la desarrollo y por los
orientado a la Web, en la que calidad de los ● Desarrollo iterativo
desarrolladores, seleccionando
se requieren cambios programadores.” (Robert. L. ● Administración de
los elementos más apropiados
constantes, y que los tiempos Class). requisito
del proceso.
de desarrollo sean más Podemos deducir que las El proceso Unificado Rational ● Uso de arquitectura
cortos hacen que aparezca el metodologías ágiles a resulta de una combinación de basada en
diferencia de las varias metodologías y se vio componentes
concepto de “metodología
metodologías tradicionales o influenciado por otros métodos ● Control de cambios
ágil” como una alternativa
atractiva. clásicas son más adecuadas como el espiral. Es una ● Modelado visual del
cuando el entorno presenta metodología que está basada en software
El desarrollo ágil está Objectory, metodología que fue
centrado en la iteración, una cierta incertidumbre o es ● Verificación de la
creada por Ivan Jacobson, y el calidad del software
comunicación y en reducir cambiante. [2] proceso fue desarrollado con la
elementos intermedios. mismas técnicas que el equipo
El desarrollo con En este contexto se podrían de creadores y desarrollo usaba En esta metodología lo que se
interacciones se realiza definir las siguientes para el diseño del software. Se pretende es el desarrollo de un
ventajas: software, en el cual se aplicará
normalmente en porciones usaría UML (Unified Modeling
el PSP (Personal Software
de tiempo pequeñas 1. Gran capacidad de Language).
RUP se basa en tres Process) Proceso de software
denominadas “timeboxes” y respuesta ante los cambios, personal y el CMMI (Capability
se ocupará de desarrollarlas los cuales no se entienden módulos principales que
contestan a las preguntas de: Maturity Model for Integration)
un equipo multidisciplinar como un problema sino Modelo de Madurez de la
como algo necesario para quién hace el proceso, qué
auto organizado, ellos productos de trabajo se van a Capacidad Integrado, en todas
mismo decidirán como que el producto sea mejor y realizar, qué documentos y y cada una de sus fases, que
realizar las tareas de la satisfaga al cliente. modelos se van a producir y están en la realización de los
iteración. Los cambios formarán parte cómo se van a realizar las procesos.
Además el método de del proceso de desarrollo. tareas. [3]
desarrollo ágil fomenta la 2. Las entregas no se hacen El RUP es un producto
al final sino que se hacen desarrollado por Rational
comunicación entre los (IBM), el cual se caracteriza por
miembros del equipo lo que pequeñas entregas. Estas
tener un modelo iterativo e
previene problema que en entregas permiten al cliente incremental, al estar centrado
otra metodología quedan valorar el producto además en la arquitectura y guiado por
escondidos. de ir trabajando con algunas los casos de uso. Incluye
Esta comunicación no solo funcionalidades. artefactos (los cuales son los
se establece de forma cerrada 3. Los ciclos cortos de productos tangibles del proceso
entre los miembros del entrega ayudarán a como por ejemplo, los modelo
equipo sino que también se disminuir los riesgos sobre de casos de uso, el código
fuente, etc.) y los roles (papel
que desempeña cada persona en
un determinado momento, una objetivo que se debe de
persona puede desempeñar conseguir.
distintos roles a lo largo de todo Anthony Crain nos da una
el proceso de la visión de los roles según su
implementación de la grado de detalle, donde en
metodología y por lo tanto del primera instancia se tiene una
desarrollo del software). visión global de la solución y el
rol asociado, y en una nueva
iteración se obtiene el rol
específico:

Tab. 1. Roles de RUP


(Fuente: Blog de Anthony
Crain).

Fig. 5. Fases de la
Fig. 4. Modelo iterativo e metodología RUP.
incremental. Fuente:https://procesosdesoft
Fuente: ware.wikispaces.com/METO
https://www.emaze.com/@A DOLOGIA+RUP
IZQZZZZ
Cada una de estas fases se SCRUM
FASES DE LA desarrollará mediante un ciclo
METODOLOGÍA RUP de interacciones, éstas consisten En el año 1986 Takeuchi y
en hacer un ciclo de vida en Nonaka publicaron el artículo
cascada reducido, en la que el “The New Product
Las fases que forman el ciclo de
flujo de trabajo irá variando Developroent Game” el cual
vida de RUP se dividen en
según la fase en la que se dará a conocer una nueva forma
cuatro:
encuentre. Estas interacciones de gestionar proyectos en la que
son llevadas a cabo bajo las la agilidad, flexibilidad, y la
1. Inicio: Se establece el
disciplinas de: incertidumbre son los elementos
objetivo del sistema y se
principales.
recogen los requisitos del
1) Disciplina de desarrollo Nonaka y Takeuchi se fijaron en
usuario.
empresas tecnológicas que,
2. Elaboración: Se busca reducir
 Requerimientos: Se estando en el mismo entorno en
riesgos y cumplir con la
trasladan las el que se encontraban otras
planificación y coste indicado.
necesidades del empresas, realizaban productos
Se genera una estructura
negocio a un sistema en menos tiempo, de buena
arquitectónica que se puede
automatizado. calidad y menos costes.
ejecutar y que servirá de punto
 Análisis y diseño: Los Observando a empresas como
de partida para después permitir
requerimientos se Honda, HP, Canon...etc., se
desarrollar la disciplina de
trasladan a una dieron cuenta de que el
diseñar, implementar y probar.
arquitectura software. producto no seguía unas fases
3. Fase de construcción:
 Implementación: Se en las que había un equipo
Partiendo de la arquitectura
crea el software especializado en cada una de
elaborada en la fase anterior se
adaptándolo a las ellas, si no que se partía de
realizará casi toda la
necesidades. unos requisitos muy generales y
implementación, creando
el producto lo realizaba un
versiones totalmente  Pruebas: Se
equipo multidisciplinar que
funcionales para comprobar que comprueba que el
trabajaba desde el comienzo del
satisface las necesidades del software actúa de
proyecto hasta el final.
usuario. forma adecuada.
Se comparó esta forma de
4. Transición: Se comprueba
trabajo en equipo, con la
que el software cumple con 2) Disciplina de soporte:
colaboración que hacen los
todas las necesidades y se
jugadores de Rugby y la
realizan feedback con el cliente  Configuración y RUP se define por una serie de
utilización de una formación
para ajustar el software, dado administración de los características denominadas
denominada SCRUM. [4]
una de estas fases contiene cambios. prácticas y que vienen definidas
interacciones necesarias para  Administración de los en “RUP, Best Software
alcanzar los objetivos del horarios y recursos. practices development”.
producto y cada fase tiene un  Ambiente de
objetivo y un hito que indicará desarrollo y su
que el objetivo se ha alcanzado. administración.

Los roles que se definen en


RUP indican las tareas que
tiene que hacer cada uno de los
miembros del proyecto y el
 Auto-enriquecimiento:  Medirá el esfuerzo
Al ser equipos realizado en el
multidisciplinares se proyecto.
ven enriquecidos de
forma mutua, 3. Exploración: Se incrementa
aportando soluciones el producto en el que se añaden
que puedan las funcionalidades de la fase de
complementarse. especulación.

3. Control moderado: Se 4. Revisión: El equipo revisa


establecerá un control suficiente todo lo que se ha construido y
para evitar descontroles. Se se contrasta con el objetivo
basa en crear un escenario de deseado.
“autocontrol entre iguales” para 5. Cierre: Se entregará en la
no impedir la creatividad y fecha acordada una versión del
Fig. 6. Funcionamiento de espontaneidad de los miembros producto deseado. Al tratarse de
del equipo. una versión, el cierre no indica Fig. 8. Ciclo principal de
metodología de trabajo que se ha finalizado el proyecto,
Scrum. SCRUM.
4. Transmisión del sino que seguirá habiendo
Fuente: conocimiento: Todo el mundo cambios, denominados
Fuente:
Fuente: aprende de todo el mundo. Las “mantenimiento”, que hará que https://mail.google.com/mail
https://platzi.com/blog/meto personas pasan de unos el producto final se acerque al /u/0/?
dologia-scrum-fases/ proyectos a otros y así producto final deseado. ui=2&view=btop&ver=17cyo
comparten sus conocimientos a 9bg6h587&q=scrum&qs=tru
Scrum aparece como una lo largo de la organización. e&search=query&th=14cc35
práctica destinada a los ee6f95bdd1&qt=scrum.1.scr
productos tecnológicos y será en Scrum al ser una metodología ums.1&cvid=2
1993 cuando realmente Jeff de desarrollo ágil tiene como
Sutherland aplique un modelo base la idea de creación de COMPONENTES DE
de desarrollo de Software en ciclos breves para el desarrollo, SCRUM
Ease/Corporation. que comúnmente se llaman
En 1996, Jeff Sutherland y Ken iteraciones y que en Scrum se Para entender todo el proceso
Schwaber presentaron las llamarán de desarrollo del Scrum, se
prácticas que se usaban como “Sprints”. describirá de forma general las
proceso formal para el Para entender el ciclo de fases y los roles. Estas fases y
desarrollo de software y que desarrollo de Scrum es roles se detallarán de forma más
pasarían a incluirse en la lista necesario conocer las 5 fases concisa más adelante.
de Agile Alliance. que definen el ciclo de Scrum se puede dividir de
Scrum es adecuado para desarrollo ágil: forma general en 3 fases, que
aquellas empresas en las que el Fig. 7. Ciclo de desarrollo podemos entender como
desarrollo de los productos se 1. Concepto: Se define de forma ágil. reuniones. Las reuniones
realiza en entornos que se general las características del Fuente: forman parte de los artefactos
caracterizan por tener: producto y se asigna el equipo https://mail.google.com/mail de esta metodología junto con
que se encargará de su /u/0/? los roles y los elementos que lo
1. Incertidumbre: Sobre esta desarrollo. ui=2&view=btop&ver=17cyo forman.
variable se plantea el objetivo 9bg6h587&q=scrum&qs=tru
que se quiere alcanzar sin 2. Especulación: en esta fase se REUNIONES
e&search=query&th=14cc35
proporcionar un plan detallado hacen disposiciones con la
del producto. información obtenida y se ee6f95bdd1&qt=scrum.1.scr
ums.1&cvid=2 1. Planificación del Backlog
Esto genera un reto y da una establecen los límites que
autonomía que sirve para marcarán el desarrollo del Se definirá un documento en el
generar una “tensión” adecuada producto, tales como costes y Scrum gestiona estas iteraciones
a través de reuniones diarias, que se reflejarán los requisitos
para la motivación de los agendas. del sistema por prioridades.
equipos. Se construirá el producto a uno de los elementos
fundamentales de esta En esta fase se definirá también
partir de las ideas principales y la planificación del Sprint 0, en
2. Auto-organización: Los se comprueban las partes metodología.
la que se decidirá cuáles van a
equipos son capaces de realizadas y su impacto en el ser los objetivos y el trabajo que
organizarse por sí solos, no entorno. hay que realizar para esa
necesitan roles para la gestión Esta fase se repite en cada iteración.
pero tienen que reunir las iteración y consiste, en rasgos Se obtendrá además en esta
siguientes características: generales, en: reunión un Sprint Backlog, que
 Autonomía: Son los  Desarrollar y revisar es la lista de tareas y que es el
encargados de los requisitos objetivo más importante del
encontrar la solución generales. Sprint.
usando la estrategia  Mantener la lista de
que encuentren las funcionalidades 2. Seguimiento del Sprint
adecuada. que se esperan.
 Auto-superación: Las  Plan de entrega. Se En esta fase se hacen reuniones
soluciones iniciales establecen las fechas diarias en las que las 3
sufrirán mejoras. de las versiones, hitos preguntas principales para
e iteraciones.
evaluar el avance de las tareas retroalimentación dé la salida Fuente: ser modificado, y en caso de
serán: del proceso y así poder revisar y https://jeronimopalacios.com ser necesario introducir
 ¿Qué trabajo se planear cada sprint. /scrum/ cambios estos se harán una
realizó desde la  Usuarios: Es el vez concluido el periodo a
reunión anterior? destinatario final del Definición del proyecto través de la definición de
 ¿Qué trabajo se hará producto. (Product Backlog): Consiste otro sprint backlog.
hasta una nueva  Stakeholders: Las en un documento que recoge
reunión? personas a las que el el conjunto de Entrega: Una vez concluida
 Inconvenientes que proyecto les producirá
un beneficio.
requerimientos que se la ejecución del sprint, se
han surgido y qué hay
que solucionar para Participan durante las asocian al proyecto. Es dispondrá de una porción de
poder continuar. revisiones del Sprint. responsabilidad del Product la aplicación potencialmente
 Managers: Toma las Owner realizar esta definitiva.
3. Revisión del Sprint decisiones finales definición y establecer las
participando en la prioridades de cada Evolución del proyecto
Cuando se finaliza el Sprint se selección de los requerimiento. Es un (Burn down): Es un
realizará una revisión del objetivos yde los documento de alto nivel, que documento que refleja el
incremento que se ha generado. requisitos. contiene descripciones estado del proyecto,
Se presentarán los resultados genéricas (no detalladas), y indicando el volumen de
finales y una demo o versión, que está sujeto a
esto ayudará a mejorar el
requerimientos que en ese
modificaciones a lo largo del momento se encuentran
feedback con el cliente.
desarrollo. pendientes de ser abordados
ROLES (en el product backlog), los
Definición del Sprint requerimientos que en ese
1. LOS CERDOS (Sprint Backlog): Un sprint momento se están
Son las personas que están debe entenderse como un desarrollando (sprint
comprometidas con el proyecto subconjunto de backlog) y los
y el proceso de Scrum. requerimientos, extraídas del requerimientos cuyo
product backlog, para ser desarrollo ya se ha
 Product Owner: Es la Fig. 9. Conformación ejecutadas durante un completado en su totalidad.
persona que toma las equipo Scrum. periodo entre 1 y 4 semanas
decisiones, y es la que Fuente: de trabajo. El sprint backlog Para analizar la evolución
realmente conoce el https://jeronimopalacios.com
negocio del cliente y
sería el documento que del desarrollo del trabajo, la
/scrum/ describa las tareas que son metodología implementa
su visión del
producto. Se encarga necesario realizar para unas reuniones o eventos de
ELEMENTOS DE SCRUM
de escribir las ideas abordar los dicho trabajo enfocadas en un
del cliente, las ordena Los elementos que forman a subconjunto de contexto SCRUM.
por prioridad y las Scrum son: requerimientos. Está es la
coloca en el Product característica principal que  Planificación de
 Product Backlog: lista
Backlog. marca la diferencia entre sprint: Se realiza al
de necesidades del
 ScrumMaster: Es el Scrum y otros modelos para
cliente. principio de cada
encargado de el desarrollo ágil. Es una
 Sprint Backlog: lista ciclo de sprint, y
comprobar que el simple iteración llevada a
de tareas que se está encaminada a
modelo y la
realizan en un Sprint. cabo por los miembros del seleccionar el
metodología funciona.
 Incremento: parte equipo. Un equipo puede conjunto de
Eliminará todos los
añadida o desarrollada completar varios sprints requerimientos del
inconvenientes que
en un Sprint, es un durante el desarrollo del
hagan que el proceso product backlog que
parte terminada y proyecto. Un Sprint inicia
no fluya e interactuará serán abordado, el
totalmente operativa. con un equipo que se
con el cliente y con equipo de trabajo
los gestores. compromete a realizar el que será necesario y
 Equipo De Desarrollo: trabajo y finaliza con la el tiempo que se
suele ser un equipo demostración de un estima (entre 1 y 4
pequeño de unas 5-9 entregable. [5] semanas) para su
personas y tienen
autoridad para desarrollo.
organizar y tomar
decisiones para
Ejecución del Sprint: Sería  Reunión diaria:
conseguir su objetivo. el periodo de entre 1 y 4 Conocida como
Está involucrado en la semanas (periodo definido daily scrum, se
estimación del previamente en base a las realiza al comienzo
esfuerzo de las tareas tareas recogidas en el sprint de cada día en que
del Backlog. backlog) durante el cual el se esté ejecutando
equipo de trabajo abordaría un sprint. Es una
2. LAS GALLINAS las tareas de desarrollo reunión corta, por
correspondientes. Una vez lo general de 15
Aunque no son parte del Fig. 10. Ciclo de desarrollo iniciada la ejecución de un
proceso de Scrum, es necesario Scrum. minutos o más (no
sprint definido, este no podrá más de 30 minutos)
que parte de la
en la que los gran escala que requieren de En la metodología SCRUM
integrantes del interacciones complejas con se realizan reuniones diarias
equipo responden otros sistemas, debido a que las cuales son llamadas
las siguientes estos sistemas requieren de "Daily Scrum" y es donde se
preguntas: un nivel de precisión sostiene una pequeña charla
● ¿Qué has bastante alto y tienen un sobre el estado del proyecto.
hecho desde gran riesgo de construcción. En particular muestran los
la última No sería conveniente impedimentos para progresar
reunión? implementar una que se atraviesan y que la
● ¿Qué metodología ágil para el gerencia debe resolver. [1]
problemas desarrollo de un sistema
has crítico en el cual es necesario
encontrado el análisis detallado de todos
para realizar los requerimientos para
el trabajo comprender su complejidad
previsto? Fig. 11. Eventos de la e implicaciones, debido a la
metodología Scrum. complejidad y la extrema
● ¿Qué planeas precisión que pueda tener la
hacer antes Fuente:
https://www.slideshare.net/li captura de requerimientos,
de la próxima en los cuáles las
reunión?. zandroluzon/scrum-
70358857 metodologías ágiles como
SCRUM ofrecen demasiada
 Revisión de sprint: flexibilidad.
Una vez concluido La metodología Scrum
Con respecto a la
el ciclo de sprint se inicialmente fue desarrollada
planificación, RUP tiene un
mantiene una para la gestión y desarrollo
plan de proyecto formal,
reunión en la que se de software; pero Fig. 12. Metodología Scrum
asociada a múltiples
define qué parte del actualmente también aplica vs metodología Scrum.
iteraciones, el plan es
trabajo previsto se para las siguientes Fuente:
impulsado y definido por
ha completado y actividades: http://www.unbugalavez.net/
una fecha final y también
qué parte 2008/08/scrum-y-rup.html
cuenta con hitos
permanece  Investigar e intermedios; por otro lado,
pendiente. En identificar en scrum no se define
cuanto al trabajo mercados viables, completamente el proyecto CONCLUSIONES
completado se tecnologías y antes de iniciarlo, sino que
realiza una revisión capacidades de Como conclusión general
cada plan de la siguiente podemos decir que cada
(demo) del mismo productos iteración se determina al
al product owner y  Desarrollar metodología es diferente,
final de la iteración actual, posee sus principios, su
otros usuarios que productos y mejoras además el cliente es quien
pudiesen estar modelo de ciclo de vida y
 Liberar productos y determina el momento en
involucrados. por ende sus ventajas y/o
mejoras tantas veces que el proyecto se lleva a desventajas. Por eso, es
como sea posible cabo.
Retrospectiva de sprint: Es importante tener en cuenta
durante el día
una reunión en la que todos Otro punto de comparación qué aspectos se van a
 Desarrollar y necesitar de una metodología
los miembros del equipo entre las dos metodologías
mantener ambientes y de esta forma aplicarla a
realizan una valoración del de software es que el tipo de
en la Nube (en un proyecto tomando los
trabajo realizado en el documentación de RUP hace
línea, seguros, bajo componentes que sean
último sprint, identificando referencia a las
demanda) y otros necesarios para el mismo
puntos de mejora de cara a comunicaciones formales
entornos adaptándolas y aplicándolas.
los siguientes a realizar. El con la finalidad de ser más
operacionales para
objetivo principal es predictivos, mientras que en Por otra parte, es importante
el uso de productos
introducir un componente de SCRUM se enfoca en las
 Mantener y renovar resaltar que dos
mejora continua en el comunicaciones informales metodologías distintas y con
productos. continuas y a la adaptación
proceso. [6] distintos principios pueden
al cambio, con la finalidad convivir, como es el caso del
COMPARATIVA
de ser más adaptivas.
METODOLOGIAS proyecto que presentamos,
Otra diferencia está donde fusionamos las
Ambas metodologías tanto relacionada con las características más
SCRUM como RUP, tienen iteraciones de desarrollo, convenientes de cada una
sus limitaciones y mientras que en RUP tienden para sacar el mayor
debilidades, así pues las a ser pocas y largas que provecho de las mismas y
metodologías ágiles son las finalizan con la entrega de optimizar un nuevo proceso
más adecuadas para un artefacto, en SCRUM de desarrollo de software
proyectos pequeños y tienden a ser muchas pero combinado.
medianos, no son las más frecuentes, llamadas sprints.
adecuadas para sistemas de
I. Referencias

[1] J. S. Villanueva, «Scrum y RUP: Comparativa y propuesta


Metodologica,» ISSN, pp. 39-48, 2014.
[2] M. T. Gallego, «Gestio de proyectos informaticos,»
p. 18, 2015.
[3] F. Lopez, «Metodologías ágiles para gestión de
proyectos,» 11 12 2014. [En línea]. Available:
http://www.conasa.es/blog/metodologias-agiles-para-
gestion-de-proyectos/.
[4] P. agiles, «Scrum,» [En línea]. Available:
https://proyectosagiles.org/que-es-scrum/.
[5] W. Lara, «Platzi,» Platzi, 2015. [En línea]. Available:
https://platzi.com/blog/metodologia-scrum-fases/.
[6] Nateevo, «Nateevo,» 20 09 2012. [En línea]. Available:
http://www.nateevo.com/scrum-la-metodologia-de-
desarrollo-agil-por-excelencia/.
[7] J. S. Villanueva, «Scrum y Rup: Comparativa y propuesta
Metodologica,» ISSN, pp. 39-48, 2014.

También podría gustarte