Temas
Rational Unified Process (RUP) es una infraestructura de procesos que Rational Software ha perfeccionado a lo largo de
los años y que se ha utilizado ampliamente para todo tipo de proyectos de software, fueran grandes o pequeños.
Recientemente, un número creciente de procesos "ágiles", como eXtreme Programming (XP), SCRUM, Feature-Driven
Development (FDD) y la metodología Crystal Clear, han ido adquiriendo reconocimiento como métodos eficaces para la
creación de sistemas más pequeños. (Vaya a www.agilealliance.org, donde
encontrará más información sobre Agile Alliance).
Las secciones siguientes se han concebido como una ayuda para los equipos de proyecto mediante la evaluación de
prácticas "ágiles" que se hayan hallado en uno de estos métodos para ver cómo las tratan los procesos de desarrollo de
software más completos definidos por RUP (si desea más información acerca de RUP, consulte el capítulo de Introducción a RUP).
La comunidad Agile ha sintetizado ciertas "recomendaciones" que son especialmente aplicables a equipos pequeños y
equipos de proyectos en ubicaciones próximas. Aunque RUP puede emplearse con equipos de proyectos de cualquier tamaño,
puede aplicarse satisfactoriamente a proyectos pequeños. En general, RUP y los procesos de la comunidad Agile tienen
una visión similar de las principales recomendaciones necesarias para desarrollar software de calidad, por ejemplo,
aplicar el desarrollo iterativo y centrarse en los usuarios.
En las secciones siguientes se explica cómo aplicar algunas de las "recomendaciones" identificadas en la comunidad
Agile a proyectos basados en RUP que quisieran beneficiarse de alguna de estas prácticas. En este caso, se centran
específicamente en aquellas prácticas presentadas por la metodología eXtreme Programming (XP). (Si desea más
información sobre XP, consulte el sitio web: http://www.extremeprogramming.org).
Prácticas de XP
XP incluye cuatro "actividades" básicas (codificación, prueba, escucha y diseño), que están muy alineadas con las disciplinas de RUP. Estas actividades de XP se realizan utilizando un conjunto de
prácticas que precisan realizar actividades adicionales, que se correlacionan con algunas otras disciplinas en RUP. Las
prácticas de XP, según Extreme Programming Explained, son:
-
El juego de la planificación: determinar con rapidez el ámbito del próximo release combinando las
prioridades empresariales con los cálculos técnicos. A medida que la realidad se imponga al plan, vaya actualizando
el plan.
-
Pequeños releases: lleve rápidamente un sistema sencillo a producción y, a continuación, vaya publicando
nuevas versiones en ciclos muy cortos.
-
Metáfora: dirija todo el desarrollo con una historia compartida que sea sencilla sobre cómo funciona todo el
sistema.
-
Diseño sencillo: el sistema debería diseñarse de la forma más sencilla posible en todo momento. La
complejidad suplementaria debe eliminarse cuando se detecte.
-
Prueba: los programadores deben escribir pruebas de unidades de forma continua, y deben ejecutarse sin error
antes de continuar con el desarrollo. Los clientes pueden escribir pruebas que demuestren que las características
se han completado.
-
Refactorización: los programadores deben reestructurar el sistema sin modificar su comportamiento para
eliminar la duplicación, mejorar la comunicación, simplificar o añadir flexibilidad.
-
Programación de dos en dos: todo el código de producción se escribe con dos programadores en una máquina.
-
Propiedad colectiva: cualquiera puede cambiar cualquier parte del código en cualquier lugar del sistema en
cualquier momento.
-
Integración continuada: integre y construya el sistema varias veces al día, cada vez que se complete una
tarea.
-
Semanas de 40 horas: no trabaje más de 40 horas a la semana como norma. Nunca realice horas extra de trabajo
dos semanas seguidas.
-
Cliente in situ: incorpore un usuario real al equipo, para que esté disponible en todo momento para
responder preguntas.
-
Estándares de codificación: los programadores deben escribir todo el código de acuerdo con las normas,
insistiendo en la comunicación a través del código.
Las actividades que se realizan como resultado de la práctica "juego de la planificación", por ejemplo, se
correlacionarán fundamentalmente con la disciplina de gestión de proyectos de RUP. Pero algunos temas de RUP, como el
despliegue del software publicado, se encuentran fuera del ámbito de XP. La obtención de requisitos excede en mucho el
ámbito de XP, pues es el cliente quien define y proporciona los requisitos. Asimismo, debido a los proyectos de
desarrollo más sencillos que trata, XP puede abordar sólo ligeramente con cuestiones que cubre RUP con más detalle en
la disciplina de gestión de cambios y configuración y en la disciplina de entorno.
Prácticas de XP compatibles con RUP
En las disciplinas en las que XP y RUP se solapan, las prácticas siguientes, que se describen en XP, pueden emplearse
en RUP, y en algunos casos ya se emplean.
-
El juego de la planificación: la guía de XP para la planificación puede utilizarse para alcanzar muchos de
los objetivos utilizados en la disciplina de gestión de proyectos de RUP para un proyecto que sea muy pequeño. Esto
es muy útil para los proyectos con un nivel bajo de formalidad que no deben producir artefactos formales de gestión
de proyectos de nivel intermedio.
-
Diseño de primera prueba y refactorización: se trata de dos buenas técnicas que pueden aplicarse en la
disciplina de implementación de RUP. En concreto, la práctica de pruebas de XP, que requiere del diseño de primera
prueba, es una forma excelente de clarificar los requisitos con mucho detalle. Como se verá en la siguiente
sección, la refactorización puede no escalar adecuadamente para los sistemas grandes.
-
Integración continuada: RUP da soporte a esta práctica por medio de compilaciones en el nivel de sistema y
de subsistema (dentro de una iteración). Componentes probados en unidades se integran y se prueban en el contexto
del sistema emergente.
-
Cliente in situ: muchas de las actividades de RUP pueden aprovechar en gran medida la presencia de un
cliente in situ como miembro del equipo, lo que reducirá el número de entregas intermedias necesarias, en especial,
de documentos. Al igual que su favorito medio de comunicación entre el desarrollador y el cliente, XP favorece la
opción de la conversación, que depende de la continuidad y de la familiaridad para tener éxito; sin embargo, cuando
un sistema, incluso uno pequeño, tiene que sufrir una transición, se necesitará más que conversaciones. XP permite
abordar este tipo de cuestiones a posteriori mediante, por ejemplo, documentos de diseño al final del proyecto.
Aunque no prohíbe la producción de documentos u otro tipo de artefactos, XP indica que debe producir sólo los que
verdaderamente necesite. RUP coincide, pero lo lleva más allá y describe lo que necesitará cuando la continuidad y
la familiaridad no son ideales.
-
Estándares de codificación: RUP tiene directrices para la programación de artefactos que deben observarse
casi siempre como si fuesen obligatorias. (La mayoría de los perfiles de riesgo de proyectos, al ser uno de los
principales factores de la personalización, harían que lo fuesen).
-
Semana de cuarenta horas: como en XP, RUP sugiere que el trabajar horas extras no debe ser una condición
crónica. XP no sugiere un límite estricto en las 40 horas, pues reconoce distintas tolerancias en las jornadas de
trabajo. Los ingenieros de software son tristemente famosos por sus jornadas con muchas horas extra sin
compensación, simplemente por la satisfacción de ver que han completado alguna parte, y sus responsables no tienen
por qué detener ese impulso de forma arbitraria. Lo que los directores no deben es explotar esta práctica o
imponerla. Deben recopilar constantemente mediciones de las horas trabajadas realmente, aunque no se compensen. Si
el registro de horas trabajadas parece alto durante un periodo extendido, debe investigarse; sin embargo, estas son
cuestiones que resolver en las circunstancias en las que se den, entre el individuo y su director, con un
reconocimiento de las preocupaciones que puedan derivarse para el resto del equipo. Las cuarenta horas no son más
que una guía, pero son una guía muy sólida.
-
Programación de dos en dos: XP sostiene que la programación de dos en dos es beneficiosa para la calidad del
código, y que una vez que se adquiere, se disfruta más de esta habilidad. RUP no describe los mecanismos de la
producción de código de una forma tan granulada, aunque sería ciertamente posible utilizar la programación de dos
en dos en un proceso basado en RUP. RUP es ahora quien proporciona parte de la información sobre programación de
dos en dos, así como el diseño de primera prueba y la refactorización, en la forma de documentación. Obviamente, el
uso de estas prácticas en RUP no es un requisito, sin embargo en un entorno de equipo, con una cultura de
comunicación abierta, significaría la sospecha de que las ventajas de la programación de dos en dos (en términos
del efecto sobre los costes del ciclo vital total) sería difícil de discernir. El personal se reúne para hablar de
los problemas y para resolverlos de una forma muy natural en un equipo que funciona bien, sin estar obligado a
ello.
La insinuación de que el proceso adecuado debe imponerse en el nivel "micro" suele ser mal recibida y puede no ser bien
recibida en algunas culturas de empresa. RUP, por tanto, no aboga por la imposición estricta. Sin embargo, en algunas
circunstancias, el trabajo en pareja, y algunas de las otras prácticas basadas en equipos recomendadas en XP, son
claramente beneficiosas, ya que cada miembro del equipo puede ayudar al otro, por ejemplo:
-
los primeros días de la formación del equipo, cuando las personas se están conociendo
-
los equipos sin experiencia en alguna nueva tecnología
-
los equipos compuestos por personal muy experimentado y por novicios
Prácticas de XP que no escalan adecuadamente
Las prácticas de XP siguientes no escalan adecuadamente para los sistemas grandes (ni XP lo pretende), por lo que las
utilizaremos si lo recomienda RUP.
-
Metáfora: para los sistemas más grandes y complejos, la arquitectura como metáfora no es suficiente. RUP
proporciona una infraestructura de descripción más rica para la arquitectura que no es sólo lo que se describe en
Extreme Programming Explained: "grandes cajas y conexiones". Incluso en la
comunidad de XP, la metáfora se está desechando recientemente. Ya no es una de las prácticas de XP (hasta que
puedan conseguir describirla adecuadamente, tal vez la metáfora pueda serles de ayuda).
-
Propiedad colectiva: es útil si los miembros de un equipo responsable de un sistema pequeño o de un
subsistema están familiarizados con todo su código. Pero si desea o no que todos los miembros del equipo tengan la
misma autorización para realizar cambios en cualquier parte dependerá de la complejidad del código. Suele ser más
rápido (y más seguro) que aplique un arreglo el individuo (o pareja) que esté trabajando en ese momento en el
segmento de código pertinente. La familiaridad con el código, aún con el mejor escrito, en particular si es
complejo en su algoritmia, se reduce rápidamente con el tiempo.
-
Refactorización: en un sistema grande, la refactorización frecuente no es un sustituto de la falta de
arquitectura. En Extreme Programming Explained se afirma que la estrategia de
diseño de XP se parece a un algoritmo que subiera y bajara montañas. Empieza por un diseño sencillo y, a
continuación, lo hace un poco más complejo, y luego otra vez sencillo y luego otra vez más complejo. El problema
con este tipo de algoritmos es alcanzar el punto local óptimo, en el que la situación no puede mejorarse mediante
ningún cambio pequeño, pero un cambio de grandes dimensiones sí podría. En RUP, la arquitectura proporciona la
vista y el acceso a la "montaña alta", para hacer tratables los sistemas grandes y complejos.
-
Pequeños releases: el índice al que un cliente puede aceptar y desplegar nuevos releases dependerá de muchos
factores, y suele incluir el tamaño del sistema que suele estar correlacionado con el impacto empresarial. Un ciclo
de dos meses puede ser demasiado corto para algunos tipos de sistemas; es posible que la logística de despliegue lo
prohíba.
Prácticas de XP que requieren precaución
Finalmente, es posible que una práctica de XP que a primera vista suena potencialmente utilizable en el diseño sencillo
de RUP, precise alguna elaboración y precaución al aplicarla de forma general.
-
Diseño sencillo
XP está muy claramente dirigido a la funcionalidad: las historias de los usuarios se seleccionan, se descomponen
en tareas y, a continuación, se implementan. De acuerdo con Extreme Programming
Explained, el diseño correcto para el software en un momento determinado el que puede ejecutar todas las
pruebas, no tiene lógica duplicada, manifiesta todas las intenciones que son importantes para los programadores y
tiene el menor número de clases y métodos posibles. XP no cree en añadir nada que no sirva para aumentar el valor
empresarial para el cliente.
Esto encierra un problema, relacionado con el problema de las optimizaciones locales, al tratar con lo que RUP
denomina requisitos "no funcionales". Estos requisitos también proporcionan valor empresarial al cliente, pero
es más difícil expresarlos en forma de historias. Algunas de las que en XP se denominan restricciones
pertenecen a esta categoría. RUP tampoco aboga por un diseño que vaya más allá de lo necesario de forma
especulativa, sino que apoya el diseño con un modelo arquitectónico en mente que sea una de las claves del
cumplimiento de los requisitos no funcionales.
Por tanto, RUP coincide con XP que el "diseño sencillo" debe incluir la ejecución de todas las pruebas, pero
con el añadido de que éste incluye pruebas que demuestran que el software cumplirá con los requisitos no
funcionales. Una vez más, esto sólo surge como un tema principal a medida que crecen el tamaño y la complejidad
del sistema, o cuando la arquitectura no tiene precedentes o los requisitos no funcionales muy laboriosos. Por
ejemplo, la necesidad de organizar los datos (para operar en un entorno distribuido heterogéneo) parece hacer
que el código sea excesivamente complejo, pero sigue siendo necesaria en todo el programa.
Correlación de artefactos para un proyecto pequeño
Cuando se personaliza RUP para un proyecto pequeño y se reducen los requisitos de productos
de trabajo según corresponda, ¿cuál es la diferencia con el equivalente de los artefactos de un proyecto XP? En la
Tabla 1 se muestra un conjunto habitual de artefactos RUP en un proyecto RUP pequeño.
Tabla 1: correlación de los artefactos de XP a RUP para un proyecto pequeño
Aunque la granularidad de los artefactos varía en ambos lados, en general los artefactos de RUP para proyectos pequeños
(el tipo que trataría XP sin problemas) se correlacionan bastante bien con los de un proyecto XP.
Tenga en cuenta que la tabla también incluye algunos artefactos que no están cubiertos por XP, pero que son necesarios
en muchos proyectos. Estos incluyen el modelo de
datos y los artefactos relacionados con el despliegue, como el material de soporte del usuario.
Actividades
RUP define una tarea como si fuera trabajo realizado por un rol, sea
utilizando y transformando artefactos de entrada o produciendo artefactos de salida que son nuevos o modificados.
Además RUP enumera estas actividades y las categoriza de acuerdo con las disciplinas de RUP. Estas disciplinas incluyen: requisitos, análisis y diseño,
despliegue y gestión de proyectos (entre otras).
Las actividades están relacionadas en el tiempo mediante los artefactos que producen y consumen: una actividad puede
empezar lógicamente cuando sus entradas estén disponibles (y en un estado adecuadamente maduro). Esto significa que los
pares de actividades de productor y consumidor pueden solaparse con el tiempo, si el estado del artefacto lo permite;
no tienen por qué secuenciarse con rigidez. Las actividades deben proporcionar una sólida guía sobre cómo debe
producirse un artefacto, y también pueden utilizarse para ayudar al gestor de proyectos con la planificación.
Al estar entretejidos en RUP como se describe en términos de ciclo vital, los artefactos y actividades son
"recomendaciones": principios de ingeniería de software con capacidad probada de producir software de calidad
construido según una planificación y un presupuesto previsibles. RUP, a través de sus actividades (y sus artefactos
asociados), da soporte y realiza estas recomendaciones; son temas que se ejecutan en RUP y que mantienen los principios clave que apuntalan RUP. Tenga en cuenta que XP también utiliza la noción
de "prácticas", pero como se verá, no se corresponden de forma exacta con el concepto que en RUP se denomina
recomendación, o práctica recomendada.
XP presenta una vista sencilla y atractiva del desarrollo de software basada en cuatro actividades básicas:
codificación, prueba, escucha y diseño, que deben habilitarse y estructurarse de acuerdo con algunas prácticas de
soporte (como se indica en el capítulo 9 de Extreme Programming Explained). De hecho, como se ha indicado
anteriormente, las actividades de XP tienen un ámbito más cercano a las disciplinas de RUP que a las actividades de
RUP, y buena parte de los que sucede en un proyecto XP (además de las cuatro actividades básicas) proviene de la
elaboración y la aplicación de sus prácticas.
Por tanto, existe un equivalente en XP de las actividades de RUP, pero las "actividades" de RUP no se identifican o
describen formalmente como tales. Por ejemplo, si se observa el capítulo 4 acerca de las historias de los usuarios en
Extreme Programming Installed, se puede leer la cabecera acerca de la definición de
requisitos con historias, escritas en tarjetas, y en todo el capítulo se da una mezcla de descripción de procesos y de
guía acerca de lo que son las historias de usuarios, y de cómo deben producirse (y quién debe hacerlo). Y continúa de
esa forma; en las diversas secciones de los libros de XP (bajo los encabezamientos que
combinan el enfoque de artefacto con el de actividad), se describen tanto las "cosas producidas" como las "cosas
hechas" con varios grados de prescripción y detalle.
El aparentemente alto grado de prescripción de RUP es el resultado de la completitud y la mayor formalidad en su
tratamiento de las actividades y sus entradas y salidas. No es que XP no tenga prescripción pero, tal vez en su intento
de seguir siendo ligero, la formalidad y el detalle se han omitido sin más. La falta de especificidad no es ni una
fortaleza ni una debilidad, pero la falta de información detallada de XP no debe confundirse con la sencillez. No
disponer de detalles puede ser una opción aceptable para los desarrolladores más experimentados, pero en muchos casos,
un mayor número de detalles son de gran ayuda para los nuevos miembros del equipo, que aún no se han adecuado al ritmo
de trabajo con que el equipo enfoca el desarrollo de software.
Con las actividades, igual que con los artefactos, es importante no olvidar lo que se trata de conseguir. Llevar a cabo
una actividad a ciegas no es nunca una práctica recomendable. Las actividades y las directrices asociadas están ahí
para consultarlas cuando sean necesarias para alcanzar los objetivos, pero no debieran utilizarse como excusa para no
tener que determinar lo que se intenta alcanzar. Este espíritu está bien articulado en XP, y estimamos que deberían
aplicarlo todos los usuarios de RUP.
Roles
En RUP, se dice que las actividades las
realizan los roles (o, para ser exactos, los individuos o grupos que desempeñan los roles). Los
roles también son responsables de artefactos concretos; normalmente, el rol responsable crea el artefacto y garantiza
que los cambios efectuados por otros roles (si está permitido) no rompan el artefacto. Un individuo o un grupo de
personas puede desempeñar un rol o varios roles. Un rol no tiene que correlacionarse sólo con una posición o "casilla"
en una empresa.
En Extreme Programming Explained se identifican siete roles aplicables a XP:
programador, cliente, verificador, rastreador, adiestrador, consultor y gran jefe, y se describen sus responsabilidades
y las competencias necesarias en las personas que los desempeñarán. Asimismo, en algunos de los otros libros de XP se hace referencia a estos roles. La diferencia en el número en XP y en RUP
es fácil de explicar:
-
XP no cubre todas las disciplinas de RUP.
-
Los roles de XP son más comparables a los puestos dentro de una empresa (posiblemente asumiendo varias
responsabilidades) que a los roles de RUP. Por ejemplo, el programador de XP de hecho desempeña varios roles de
RUP: implementador, revisor de código e integrador, que necesitan competencias ligeramente distintas.
Roles de XP y RUP en proyectos pequeños
Cuando los roles de RUP se correlacionan con un proyecto pequeño, el correspondiente número de roles similares a los de
XP se reduce a 5 en el número de puestos, o tipos de trabajo. En la Tabla 3 (dibujada a partir de RUP) se muestra esta
correlación con los roles de XP correspondientes.
Tabla 3: correlación de roles de XP con roles de RUP en un proyecto pequeño
Utilización de prácticas de XP con RUP
RUP es una infraestructura de proceso desde la que se pueden configurar procesos concretos y después se pueden crear
instancias de estos. RUP debe configurarse; es un paso obligatorio definido en el propio RUP. Por lo tanto, si se es
riguroso, debe comparar una versión personalizada de RUP con XP, es decir, con RUP personalizado para las
características del proyecto que establece XP explícitamente (y los que se pueden inferir). Ese proceso personalizado
de RUP puede incorporar muchas de las prácticas de XP (como la programación de dos en dos, el diseño con prueba inicial
y la refactorización), pero sigue sin ser idéntico a XP a causa del énfasis de RUP en la importancia de la
arquitectura, de la abstracción (en el modelado), y el riesgo, y su diferente estructura en el tiempo (fases e
iteraciones).
XP está dirigido de forma intencionada a la implementación de un proceso ligero para los proyectos pequeños. Al
hacerlo, también incluye las descripciones (al menos en los libros) que no están completamente elaborados. En una
implementación de XP, siempre habrá aspectos que deben descubrirse, inventarse o definirse sobre la marcha. RUP puede
adecuarse tanto a los proyectos cuya clase y escala se ajusten al ámbito de XP o lo excedan. Como muestran estas
instrucciones, RUP es de hecho muy compatible con la mayoría de las prácticas descritas en la documentación de XP.
No olvide que la esencia de XP es que se centra en la organización, las personas y la cultura. Esto es importante en
todos los proyectos y desde luego puede aplicarse a los proyectos que utilizan RUP. Los proyectos pequeños pueden
beneficiarse mucho del uso conjunto de estas prácticas.
Referencias de procesos Agile
-
eXtreme Programming (XP) (vaya a http://www.extremeprogramming.org/more.html si desea más
información):
-
Extreme Programming Explained: Embrace Change. Kent Beck explica los conceptos y la filosofía
que sostienen esta forma de programación. En este libro se enseñan los conceptos y las razones pero no
los métodos.
-
Refactoring Improving the Design of Existing Code. Martin Fowler escribe el primer volumen serio
sobre refactorización. Se presenta en forma de patrones. Hay muchos ejemplos en Java. En este libro se
enseña a refactorizar y las razones para hacerlo.
-
Extreme Programming Installed. De Ron Jeffries, Chet Hendrickson y Ann Anderson. En este libro
se cubren prácticas específicas de XP con más detalle que en el libro Extreme Programming Explained. En
este libro se enseña a programar a la manera de XP.
-
Planning Extreme Programming. De Kent Beck y Martin Fowler. En este libro se presentan las
últimas ideas acerca de cómo planificar software en un entorno de entregas rápidas. En este libro se
enseña a ejecutar un proyecto de XP.
-
Extreme Programming Examined. De Giancarlo Succi y Michele Marchesi. Documentos presentados en
XP2000. Un conjunto de documentos muy completo que cubre la mayoría de los temas.
-
Extreme Programming in Practice. De Robert C. Martin, James W. Newkirk. Un proyecto real que
utilizó XP es descrito con todo detalle.
-
Extreme Programming Explored. De William C. Wake. Basado en el popular sitio web XPlorations.
Temas específicos explorados al detalle.
-
Extreme Programming Applied: Playing to Win. De Ken Auer y Roy Miller. Experiencias de los
pioneros en la aplicación de XP. Se publicará en septiembre.
Para obtener información sobre otros miembros de Agile Alliance, vaya a http://www.agilealliance.org.
|