Entre la XP y el RUP?

No se haga ilusiones, este no es un artículo para ayudarle a decidir entre la metodología XP y el RUP. Es más bien una recomendación para usar XP aunque la quiera decorar como una comparación de equivalencia.

Personalmente creo que la XP es adecuada para cualquier tipo de proyecto y para equipos de cualquier tamaño (muchos piensan que la XP es para equipos muy chicos, de dos a cuatro personas, y para proyectos de corta duración y metas modestas).

En el caso del RUP, sin embargo, la implementación de estos procesos para equipos pequeños o proyectos chicos se convierte en un gasto de tiempo y dinero innecesario.

La mayoría de los equipos que utilizan RUP lo han hecho por varios años y tienen especialistas del proceso que facilitan a los miembros sin experiencia el conocimiento de las prácticas y metodologías. La metodología XP es mucho más fácil de implementar y de aprender, por lo que los equipos jóvenes pueden incorporarla de manera más natural.

El RUP hace un uso intensivo de artefactos de muy diversos tipos, entre ellos, el uso de artefactos de documentación es quizá una de los factores que lo hacen tedioso para algunos. Aquí debo aclarar que el uso intensivo de documentación es una buena práctica que no debe abandonarse incluso en la XP, aunque esta tiene sus propios artefactos, más ágiles y menos protocolarios, pero igual de exhaustivos.

Los ciclos de vida de un proyecto en XP y en RUP no son exactamente iguales, aunque sin duda tienen bastantes similitudes, ambas son metodologías iterativas con probado éxito en el desarrollo de software.

En un proyecto XP la primera fase es llamada “Ápice arquitectónico” (Architectural Spike) corresponde bastante con la “Incepción” del RUP. El ápice arquitectónico de la XP suele ser mucho más rápida que en RUP, donde la incepción puede tener varias iteraciones, sin embargo, ambas buscan lo mismo: conceptualizar de manera general el proyecto. En esta fase suelen presentarse los primeros estimados y es normal que estos sean muy poco precisos.

La fase de “Plan de entregas” de la XP podría verse como la “Elaboración” del RUP, en ambas se presentan los “Guiones de usuario” (XP) o “Casos de uso” (RUP) y se establecen con más claridad los requerimientos del sistema generales. Una de las mayores diferencias es la documentación asociada a estas fases y el estilo de la misma, sin embargo, los casos de uso y los guiones de usuario son, en esencia, lo mismo, descripciones del comportamiento esperado del sistema ante las acciones de los usuarios o actores externos.

Después de esto comienza propiamente el desarrollo, o la elaboración del código en sí. En RUP se le llama “Construcción”, en XP se le considera como el grupo de iteraciones o “Iteración” a secas. Aquí las iteraciones cobran su verdadera importancia y ambas metodologías comienzan cada iteración con guiones de usuario o casos de uso que deberán cumplirse al final de la iteración y con un trabajo de arquitectura. Cada iteración debe ser corta, en XP suelen ser notablemente más cortas que en RUP, pero en ninguno de los dos casos es conveniente que duren más de dos semanas. Cada una tiene entregables claros definidos en los guiones o casos y al final de ellas se debe siempre reestimar el proyecto con la intención de hacer más precisos los estimados generales.

Finalmente en XP se debe cumplir las pruebas de aceptación definidos también en los guiones de usuario donde se cotejan los resultados actuales con lo que se esperaba del sistema. En RUP esta fase se contempla dentro de la Construcción y la “Transición”, su fase final.

En la Transición del RUP o entrega de XP las diferencias pueden ser mayores, para RUP la entrega final debe ser algo mucho más definido, mientras que en XP se realizan entregas continuas y discretas que permiten evaluar el sistema conforme se colocan las versiones finales. Sin embargo, por el esquema iterativo de ambas, las dos metodologías contemplan entregas parciales después de cada iteración para una evaluación y monitoreo continuo.

Proyecto XP

Como podrá usted ver, ambas parecen casi lo mismo, la diferencia está, como ya he dicho, en el nivel de protocolo. En RUP el protocolo puede ser demasiado extenuante para un equipo pequeño y afectar directamente la productividad y velocidad del equipo. En XP no importa el tamaño del equipo, el énfasis está hecho en la comunicación dentro del equipo, incluyendo aquí por supuesto al cliente o usuario; en la velocidad del desarrollo y en la posibilidad de perfeccionar continuamente el código existente.

Algunas de las características de la XP no asociadas a su ciclo de proyecto son el trabajo en parejas, que permite una retroalimentación entre los programadores continua e intensa, la orientación a pruebas del desarrollo, que garantiza que no se escribirá código sin pruebas de funcionalidad y la “Refabricación” (Refactoring) continua. Aquí no quiero tampoco faltar a la verdad, en RUP también se tiene un enfoque de pruebas continuas o incluso orientación a pruebas, y al igual que la XP utiliza la refabricación como una herramienta continua, pero no se les da el mismo énfasis que en XP.

En resumen, la diferencia más importante de XP sobre RUP es la agilidad en el desarrollo, conseguida mediante una comunicación intensiva del equipo en, una confianza en todos los desarrolladores, una disminución notable del protocolo y de las jerarquías dentro y fuera del equipo y una autoevaluación intensiva incluso a nivel de cada desarrollador. Todo esto no está del todo implícito en el ciclo de desarrollo y suele pasarse por alto, pero para algunos de nosotros es lo que hace a la XP tan valiosa como metodología.

Dos libros que pueden aclarar mejor las diferencias entre estas dos metodologías y que sin duda están mejor escritos que esta rápida nota son:

13 thoughts on “Entre la XP y el RUP?

  1. Muy buen artículo. Ahora bien, el soporte al proceso de RUP/UP es mucho mayor, permitiendo que el equipo tenga más herramientas que el simple código. No solo los documentos, sino la definición de las tareas, las disciplinas, los objetivos del ciclo de vida, entre otros conceptos que no son específicos de RUP, pero que se han reunido ahí simplemente porque funcionan bien.

    Yo veo a RUP/UP como el resultado de reunir a las mejores prácticas de desarrollo identificadas en la industria, sin importar su origen.

    Por otra parte, veo a XP como un método de desarrollo interesante e influyente, pero creado como reacción de un equipo que no se adapta a algo estilo RUP… esto es, no es el resultado de un pensar en el desarrollo como profesión, sino en la reacción casi alérgica de programadores individuales.

    En cualquier caso, como digo, muy buen artículo.

  2. Igarcerant, Gracias por el comentario. Me ha causado mucha gracia eso de que la XP es “una reacción casi alérgica” al RUP/UP. Sin duda algo hay de eso, pero como todo, hay dos caras de la misma moneda.

    Es cierto que el RUP/UP es, o al menos se vende como, la unión de las mejores metodologías del desarrollo corporativo de software. Pero así como existen los alérgicos a la penicilina, existen los equipos que se adaptan mejor a metodologías XP o ágiles.

    El punto con el que estoy obligado a estar de acuerdo contigo es en que la XP depende del individuo. Considero que en RUP/UP se tienen estrategias para que la movilidad laboral de los programadores no afecte al proyecto, no tanto por la definición de roles y tareas sino por el minucioso control sobre las mismas. En XP los equipos suelen “depender” de sus miembros. Creo que sólo programadores con experiencia y sólidos conocimientos pueden participar en equipos XP, pues la mayoría de los controles que lleva RUP/UP con sus herramientas y metodologías, en XP lo llevan los programadores individuales.

    Sin embargo, si formas parte de un equipo pequeño con poca movilidad, la XP puede ser una excelente opción en comparación con RUP/UP, ya que no tienes la necesidad de tantos roles distintos y puedes compartir la responsabilidad del proyecto con todos los miembros. Algo difícil de lograr en equipos grandes.

  3. Has dado en un punto interesante (“en el clavo” si me lo permites) en eso de decir que los métodos ágiles dependen de programadores experimentados.

    Es una cuestión que impacta en los costos, ya que al menos aquí, los programadores experimentados son escasos y cotizados.

    Así la cosa, es necesario que las organizaciones desarrollen formas de trabajo que les permita ejecutar sus proyectos con los recursos que tienen. No digo que es posible contratar a estudiantes y vivir de ello, sino que a la larga, es necesario que los procesos de desarrollo tomen en cuanta más aspectos que solo la programación.

    Osea, por decirlo en otras palabras, cuando se toman en cuenta aspectos gerenciales, administrativos y económicos, se termina uno dando cuenta de la habilidad de las metodologías pesadas para proporcionar un marco conceptual en el que cual hallar las solución especifica de procesos y gente, que funcione para uno.

    …uno ya no visto como individuo, sino como empresa.

    Y por cierto, soy el mismo del comentario anterior, simplemente es que actualice mi profile.

    Saludos de nuevo.

  4. Iván,

    No sólo en Venezuela es difícil encontrar buenos desarrolladores, y me imagino que en todo el mundo, los buenos desarrolladores cobran más. Sin embargo, no creo que el costo de un buen desarrollador deba ser un problema.

    Tengo la experiencia de que equipos inexpertos y con conocimientos deficientes pueden ser mucho más costosos que un par de buenos desarrolladores que, si bien cobran más, cometen menos errores y pueden tomar mayores responsabilidades.

    Otro punto es que RUP/UP es una metodología costosa, mucho más que XP, y es que su nivel de protocolo, como bien dices, no está sólo en los documentos, sino en la separación de roles y la necesidad de una planeación mucho mayor, lo que implica no sólo arquitectos (que suelen cobrar más que un desarrollador joven), sino también especialistas en descubrimiento de procesos, recolección de requerimientos, estimados y métricas, pruebas de aceptación, etc. No veo como puedas ahorrar en nómina con RUP/UP respecto a XP. Además del costo de las herramientas.

    Mi punto estaba en el manejo de la movilidad y el costo de la misma. En RUP/UP, cuando un miembro del equipo es reemplazado, el tiempo de aprendizaje es menor (siempre y cuando conozca mínimamente la metodología RUP/UP) y no tiene tantos aspectos subjetivos como en XP. Sin embargo, no creo que sea posible implantar RUP/UP con un equipo formado por personal sin experiencia.

    La gerencia y administración en RUP/UP y XP sin duda es distinta, pero no veo porque XP pueda verse como un obstáculo administrativo o gerencial. Una cosa es que los desarrolladores tengan más responsabilidad y otra que vayan por la libre. En mi experiencia en XP, es necesario mantener un alto nivel gerencial en el proyecto, aunque el rol de “líder de proyecto” propiamente no exista.

    En lo económico, creo que hay que evaluar tanto al proyecto como al cliente. Yo prefiero usar XP, pero si siento que un esquema RUP/UP puede ser más seguro y menos costoso, preferiré RUP/UP.

    Es un gusto mantener esta discusión contigo y prometo escribir un poco más en alguna entrada ahora que tenga un poco de tiempo. También prometo comentar algo en tu Blog, que sin duda es una buena recomendación para quien quiere conocer acerca de la metodología RUP/UP y sus accesorios (muchos compartidos por la XP :P ).

  5. En verdad sería bueno que sigas escribiendo sobre XP ya que tu visión de los métodos ágiles es interesante y por lo que parece, bien educada.

    Desde el marco conceptual que utilizo, el método XP es un Proceso Definido, en el sentido en que sus integrantes (personas, técnicas, productos de trabajo, etc) están bien definidos y es posible comparar la ejecución del proceso de desarrollo contra el plan de acción que se ha prometido al cliente.

    Tomando ya la idea del proceso definido, entonces es necesario saber si las empresas que utilizan XP en verdad están utilizando XP… o simplemente andan dando libre vuelo a lo que los programadores experimentados hacen.

    …espero me comprendas cuando digo que mucha gente rechaza RUP/UP no para asumir XP en realidad, sino para no adoptar proceso definido alguno; y esto es sin duda, un error grave.

    Por otro lado quizás mi preferencia por RUP/UP quede más claro cuando te explique el porque no llamo a XP una metodología… la llamo método ya que es una forma de hacer el trabajo; en tanto que una metodología es un marco conceptual para pensar sobre métodos.

    De hecho, así como XP suele ser mal implantada y lo que queda es gente que solo programa; la forma típica en que RUP/UP es mal implantada es no hacer la adaptación del marco teórico de la metodología al nivel de un método.

    Quizás un poco abstracto… pero la verdad es que un equipo que use XP puede expresar sus acciones en términos de RUP/UP tan fácilmente como uno que declare que ha escogido UP.

    Es decir entonces, que mi preferencia por UP es simplemente porque me permite expresar mis ideas sobre el proceso de desarrollo… mismas que quizás un día alcance a documentar por completo en el blog ;-)

    En ese sentido RUP 7.0 es un paso adelante en verdad interesante. El marco es cada día más amplio y por esto, es cada día más capaz de describir los procesos técnicos ya sean estos de desarrollo, adquisición o soporte. Es decir, una organización que asuma RUP ahora, no solo podrá describir su forma de hacer desarrollo, sino también su forma de hacer otras actividades tales como la adquisición de software para sus clientes (algo que hacemos mucho como consultores en Synergix) y si todos estos procesos están tan bien definidos y documentados como UP… pues imagino que verás las posibilidades de certificación que se le abren a la organización que siga este camino.

    Palabras clave aquí? Maduración de Procesos, Certificaciones de nivel de organización y tecnologías emergentes como SPEM. Sin duda un futuro interesante.

  6. Iván,

    Comparto esa imagen de los grupos de desarrollo, la mayoría no utilizan ninguna metodología, incluso he visto que buenas prácticas básicas como el versionamiento son más bien una iniciativa personal de los programadores y no una práctica del grupo.

    Para hacer como tú, aclaro el porqué de mi preferencia por la XP. Primero trabajábamos como muchos programadores, sin metodología alguna, pero los golpes fueron muchos y dolorosos, así que comenzamos a adoptar un esquema RUP/UP lo que nos dio un control muy poderoso sobre nuestras prácticas, pero también nos quitaba mucho tiempo con los artefactos que, al menos en nuestro caso en perNodis, los clientes tomaban poco en cuenta. El segundo problema fue que nuestros clientes suelen tener poco claros los requerimientos y necesitábamos una metodología que nos permitiese adaptarnos rápidamente a los cambios de requerimientos. Somos un equipo pequeño y la adopción de XP fue un alivio para nosotros, sobre todo en lo que a reactividad ante el cambio se refiere.

    Pero la XP no va sola, hay que llevarla como a cualquier metodología. Depende del equipo tanto como RUP/UP, y depende de una buena planeación, de modelos de dominio y de procesos consistentes y contrastados continuamente con la cultura de negocios del cliente, y de un trabajo continuo.

    Ahora bien, respecto a ver a XP como un proceso, sin duda puede verse así, y aquí quiero recordar a Bertalanffy y a Von Foerster cuando dicen que un sistema es lo que el observador delimite como tal, es decir, los límites de observación determinan la naturaleza de lo observado.

    En el libro (ya me hiciste leer) Project Management with the IBM® Rational Unified Process®: Lessons from the Trenches, Dennis Gibbs menciona que RUP puede incluso implementarse de acuerdo al “manifiesto ágil” firmado entre otros por Kent Beck, creador de la XP. En este sentido es que Beck dice que la XP es más bien una manera de pensar el desarrollo, y por ello mismo es también un marco conceptual, aunque sin duda diferente de RUP/UP, pero no incompatible, como tú mismo ya lo mencionaste.

    Coincido contigo en que muchas empresas y grupos andan por allí diciendo que trabajan con metodologías ágiles sólo para justificar la falta total de metodología y de documentación. Igual existen grupos que dicen apegarse al RUP/UP casi como sinónimo de CMMi, pero que no llevan a la práctica ninguna metodología. Sin embargo, creo, igual que tú, que tanto los exponentes de XP como los de RUP tenemos mucho en común y podemos complementar bastante la visión de un desarrollo responsable y de calidad, cada uno desde nuestra trinchera, pero compartiendo prácticas como el DDD o el TDD, las métricas en código, etc.

    Respecto a la certificación, creo que un enfoque XP junto con un buen manejo de modelado de dominio pueden llevar también a una descripción pragmática de los procesos, aunque las herramientas de RUP/UP para este tipo de artefactos son sin duda envidiables.

  7. Saludos de nuevo,

    Siento que tenemos bastante en común. En particular hemos escogido nuestras metodologías favoritas a partir de una visión educada y critica, lo cual es bueno.

    Ahora que me gustaría compartir contigo las siguientes inquietudes:

    RUP/UP así como CMMi, incluyen entre sus ideas principales la gestión de requisitos. En este enfoque, se ha de contar con medidas dentro del proceso que conduzcan tanto a una identificación temprana de lo que se requiere como de evitar, por medio de las líneas base y trucos similares, que sea posible caer en el cambio continuo y desordenado de los requisitos por parte del cliente.

    Dicha práctica se basa, al menos desde mi punto de vista, en la habilidad de determinar una visión clara y detallada del proyecto, con ayuda de un analista, ya desde el comienzo del mismo.

    Claro que aquí la diplomacia y habilidad interpersonal de los involucrados también influye.

    El desarrollo de una visión se apoya entonces en artefactos bien conocidos, como el Documento de Visión del Sistema (definición, plantilla, etc, en mi blog ;-) ) y eso da lugar a un algo tangible, considerado como un objetivo clave del ciclo de vida del proyecto.

    Entonces, sin entrar en detalles, ¿no esta una forma de atacar los cambios en los requerimientos? Siento que la critica clásica a RUP/UP (no se adapta con agilidad a los cambios del proyecto) no toma en cuenta la existencia de esta práctica.

    Por otra parte, es notable la similitudes de toda metodología una vez que se ha superado la fase de la publicidad de la misma. Todos los procesos de desarrollo se enfrentan a los mismos retos, sean ágiles o normativos, por lo que es necesario, que en todos lados se asuman las llamadas buenas prácticas; notablemente entre ellas, la Gestión de Requisitos.

  8. Un saludo Iván,

    Lo que dices es justamente mi punto. En RUP/UP (y parte de los requerimientos CMMi) se tienen los artefactos de definición del sistema, la visión, los requerimientos y los casos de uso, que si bien pueden sufrir cambios, se intenta por varios medios que esto no suceda o que no sean demasiados los cambios. En XP tenemos artefactos parecidos, mucho menos protocolarios, y mucho más flexibles, esto es, no se suele considerar definitivo una visión o una carta de requerimientos, puesto que uno de los principios es el continuo “refactoring”.

    Si bien es cierto que los cambios desordenados de requerimientos deben ser evitados, no creo que los cambios, por más continuos y agresivos que puedan ser, deban ser evitados. En perNodis tratamos siempre de alentar al cliente a que vaya construyendo el software junto con nosotros (es la idea de la XP), y hasta ahora nos ha funcionado muy bien.

    Me explico. No es que se aliente al cliente a andar dando papalotazos por todos lados cambiando sus requerimientos, pero creemos que el cliente debe poder adaptar sus requerimientos a los cambios de su propio mercado. Por ejemplo, tenemos un cliente que nos pidió el desarrollo de un sistema que utilizaría para comercializar cierto producto. Por razones que no vienen al caso, su comprador canceló la operación y nuestro cliente tuvo que ofrecer el producto con otras empresas. Para esto, requería realizar ciertos cambios que tuvieran en cuenta las prospectaciones de compra que estaban contemplando. Estos cambios afectaron notablemente el desarrollo, sin embargo, no eran un simple capricho, obedecían a una necesidad comercial muy concreta.

    Creo que una definición oportuna de los requerimientos es la mejor guía para comenzar el camino, pero también creo, y esta es una de las razones de mi preferencia por la XP, que fijar el plan de desarrollo por los documentos de visión y de requerimientos iniciales puede restar funcionalidad y adaptabilidad al sistema.

    Sé que en RUP/UP también hay una alta reactividad al cambio, sin embargo, creo que por la gran cantidad de artefactos asociados, en RUP/UP no se puede reaccionar de manera tan ágil a los cambios como en XP. Por supuesto, esto tiene su otro lado de la moneda. RUP/UP es una metodología muy de la mano con CMMi, y como dices, ofrece excelentes ventajas en certificación, por lo que empresas obligadas a seguir CMMi o certificaciones de tipo parecido, se ven más beneficiadas por RUP/UP que por XP o metodologías ágiles.

    Pasando a otro tema, he revisado algunos de los ejemplos de artefactos en pdf que pones en tu blog y debo decir que me parecen excelentes referencias en español para los desarrolladores hispanohablantes. Incluso en metodologías ágiles son útiles referencias así y es la primera vez que veo ejemplos en español (conocía los ejemplos de Microsoft en su MSF y algunos ejemplos en los libros de Craig Larman, pero todos en inglés).

  9. Saludos,

    Sabrás, que cuando me contrataron en Synergix, mi jefe me preguntó sobre cual debiera ser el método de desarrollo apropiado para la empresa. Luego de tomar algunos días para elaborar una propuesta razonada, mi recomendación fue seguir un método normativo tipo RUP por sobre cualquier opción ágil como XP.

    Los puntos que expuse fueron:

    1. Somos una compañía pequeña y el experto al que han contratado se siente mejor y más capaz de implantar RUP por sobre XP. Eso minimiza el riesgo de adopción. De hecho yo venía de implantar RUP en mi trabajo anterior y tenía a mi disposición no solo el conocimiento sino también la documentación, las plantillas y demás vericuetos del RUP.

    2. Somos una compañía pequeña y por eso es probable que deleguemos parte importante de los proyectos en firmas especializadas en programación o redacción técnica; un método robusto como RUP/UP nos da mejor control sobre los contratistas.

    3. El número de herramientas mínimas que se requieren para RUP/UP es pequeño: poco más que los procesadores de texto para los documentos y el ambiente de programación; en tanto que prácticas básicas en XP (esenciales en mi opinión) como las pruebas de regresión o el refactory requieren de software que Synergix no tenia adquirido. El adoptar RUP/UP nos minimizó el costo de adopción.

    4. Nuestros potenciales clientes incluyen al estado venezolano, el cual siente preferencia por los esquemas tipo RUP (mira este link: http://merinde.rinde.gob.ve/) Es decir, el valor de oportunidad es mayor con RUP/UP.

    5. El adoptar RUP/UP es un primer paso interesante hacia el mejoramiento de los procesos empresariales, por lo que ya una vez adoptado tenemos por delante un camino claro sobre certificaciones y futuras mejores prácticas.

    6. … la verdad no lo recuerdo, pero fueron unas pocas más.

    XP es genial, pero lo verdaderamente importante es cual es el conocimiento que tenemos disponible a la hora de la adopción. La decisión de adoptar uno u otro método se debe tomar como decisión estratégica de la dirección de la empresa y no como un capricho de los programadores.

    Eso es lo que pienso que hicimos en Synergix Solutions: tomar una decisión gerencial y propagar de ahí, las tareas y roles del resto del personal; apoyamos el trabajo de todos lo mejor que podemos con plantillas y herramientas (ya hoy en día tenemos bastantes más herramientas que al principio) y alineamos la política de desarrollo con nuestra realidad comercial.

    En retrospectiva, ¿hubo el chance de tener éxito adoptando XP? Definitivamente sí. Pero además de apoyar mi aprecio por RUP, lo que quiero concluir en este comentario es que un método de desarrollo debe ser una decisión consciente, apoyada por la gerencia y debe ante todo, estar rodeada del ingrediente clave: compromiso.

    Finalmente te agradezco la buena opinión por mis plantillas. Las he elaborado con mucho cuidado y cada una tiene por detrás de si bastante trabajo y estudio. Espero seguir publicando sobre el tema hasta tener el cuerpo completo de plantillas públicamente disponible. Tanto Synergix como mi persona, lo vemos como una variación del tema de software libre; solo que esta vez lo que vamos a colaborar para mejorar es el método más que el software.

    Estamos hablando.

  10. Ivan,

    Has tocado un punto muy importante. Los requerimientos metodológicos del cliente en la elección de la metodología de desarrollo.

    No he trabajado nunca con el estado venezolano, pero entiendo tu punto. En México tengo el ejemplo de Televisa, la empresa televisora más grande del país. Resulta que Televisa cotiza en la bolsa mexicana de valores, pero también en la bolsa de Nueva York, por lo que tiene que cumplir con ciertas certificaciones. Una de las condiciones que tienen es que sus proveedores de desarrollo de software deben cumplir con CMMi y en el caso de algunos proyectos, la exigencia es incluso de RUP. En casos así, la elección ya está tomada, la metodología será RUP para cumplir con los requerimientos del cliente y con las certificaciones necesarias.

    Sin duda el hecho de que el equipo o los líderes del mismo se sientan más cómodos con cierta metodología es uno de los puntos de mayor peso en la elección de la misma, pero también hay que tomar en cuenta las presiones del mercado. La exigencia de CMMi, aunque es posible llevarla a buen término con un híbrido de XP, creo que es forzar demasiado las cosas. Cuando se trata de cumplir protocolos como CMMi, mi elección siempre será RUP.

    Como ya he dicho antes, soy un promotor de las metodologías iterativas, entre ellas está, por supuesto, RUP/UP, aunque mi preferencia personal es más del lado ágil con la XP.

    En nuestro caso en perNodis, hemos tenido la suerte de tener clientes que acepten la metodología XP y que se sienten cómodos trabajando así con nosotros.

    Respecto a las herramientas, más allá del editor de código (VS2008) que sí cuesta, casi todas las herramientas que usamos son gratuitas o de bajo costo. En cambio, con RUP, sólo el precio de las herramientas de Rational para diseño UML en Eclipse ya empiezan a espantar.

    Creo que el alto costo de las herramientas de Rational y WebSphere tienen su razón de ser en el aumento en la productividad que representan y son una envidia para los practicantes de la XP, pero con todo, las herramientas, como bien lo has dicho, no lo son todo, lo importante es el equipo humano, y eso, con RUP o con XP, siempre será así.

    Un saludo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s