Embedded Files
La Programación Extrema es sin duda alguna el método ágil que primero viene a la
mente cuando se habla de modelos heterodoxos y el más transgresor entre ellos. Es, de
acuerdo con el survey de Cutter Consortium, también el más popular entre los MAs: 38%
del mercado ágil contra 23% de su competidor más cercano, FDD. Luego vienen
Adaptive Software Development con 22%, DSDM con 19%, Crystal con 8%, Lean
Development con 7% y Scrum con 3%. Todos los demás juntos suman 9%
Tarjetas CRC del patrón MVC
A mediados de la década de 1980, Kent Beck y Ward Cunningham trabajaban en un
grupo de investigación de Tektronix; allí idearon las tarjetas CRC y sentaron las bases de
lo que después serían los patrones de diseño y XP. Los patrones y XP no necesitan
presentación, pero las tarjetas CRC tal vez sí. Se trata de simples tarjetas de papel para
fichado, de 4x6 pulgadas; CRC denota “Clase-Responsabilidad-Colaboración”, y es una
técnica que reemplaza a los diagramas en la representación de modelos. En las tarjetas se
escriben las Responsabilidades, una descripción de alto nivel del propósito de una clase y
las dependencias primarias. En su economía sintáctica y en su abstracción, prefiguran a lo
que más tarde serían las tarjetas de historias de XP. Beck y Cunningham prohibían
escribir en las tarjetas más de lo que en ellas cabía [BC89]. Nos ha parecido útil ilustrar
las tarjetas correspondientes al Modelo, la Vista y el Controlador del patrón MVC de
Smalltalk, tal como lo han hecho los autores en el texto original. Hemos descripto ese
patrón (o estilo) en el documento sobre Estilos en Arquitectura de Software.
Luego de esa tarea conjunta, Beck comenzó a desarrollar XP mientras Cunningham
inventó el concepto de Wiki Web, el sistema de hipertexto de autoría colectiva antecesor
de los Weblogs. En la década siguiente, Beck fue empleado por Chrysler para colaborar
en el sistema de liquidación de sueldos en Smalltalk que se conoció como el proyecto C3
(Chrysler Comprehensive Compensation). Más tarde se unieron al proyecto Ron Jeffries
(luego ardiente partidario de LSD y del framework .NET de Microsoft) y Martin Fowler,
ulterior líder de Cutter Consortium. Previsiblemente, terminaron desarrollando C3 en una
especie de proto-XP y el proyecto terminó exitosamente. Hay una leyenda negra que
afirma que aunque XP surgió de allí, el proyecto C3 fracasó [Lar04] [Kee03]; lo cierto es
que estuvo en producción durante un tiempo, pero fue reemplazado por otro sistema y los
equipos originales de programación y mantenimiento se disolvieron cuando Chrysler
cambió de nombre y de dueños.
En la gestación de C3 se encuentra no sólo la raíz de XP, sino el núcleo primitivo de la
comunidad ágil. Beck, Cunningham y Jeffries son llamados “the three extremos”, por
analogía con “the three amigos” de UML [Hig00b]. Muchos autores escriben “eXtreme
Programming” para ser consistentes con la sigla, pero Kent Beck siempre lo mayusculiza
como se debe. XP se funda en cuatro valores: comunicación, simplicidad, feedback y
coraje. Pero tan conocidos como sus valores son sus prácticas. Beck sostiene que se trata
más de lineamientos que de reglas:
Gestación de XP, basado en [ASR+02]
1. Juego de Planeamiento.
Busca determinar rápidamente el alcance de la versión
siguiente, combinando prioridades de negocio definidas por el cliente con las
estimaciones técnicas de los programadores. Éstos estiman el esfuerzo necesario para
implementar las historias del cliente y éste decide sobre el alcance y la agenda de las
entregas. Las historias se escriben en pequeñas fichas, que algunas veces se tiran.
Cuando esto sucede, lo único restante que se parece a un requerimiento es una
multitud de pruebas automatizadas, las pruebas de aceptación.
2. Entregas pequeñas y frecuentes.
Se “produccioniza” [sic] un pequeño sistema
rápidamente, al menos uno cada dos o tres meses. Pueden liberarse nuevas versiones
diariamente (como es práctica en Microsoft), pero al menos se debe liberar una cada
mes. Se agregan pocos rasgos cada vez.
3. Metáforas del sistema.
El sistema de define a través de una metáfora o un conjunto
de metáforas, una “historia compartida” por clientes, managers y programadores que
orienta todo el sistema describiendo como funciona. Una metáfora puede interpretarse
como una arquitectura simplificada. La concepción de metáfora que se aplica en XP
deriva de los estudios de Lakoff y Johnson, bien conocidos en lingüística y psicología
cognitiva.
4. Diseño simple.
El énfasis se deposita en diseñar la solución más simple susceptible
de implementarse en el momento. Se eliminan complejidades innecesarias y código
extra, y se define la menor cantidad de clases posible. No debe duplicarse código. En
un oxímoron deliberado, se urge a “decir todo una vez y una sola vez”. Nadie en XP
llega a prescribir que no haya diseño concreto, pero el diseño se limita a algunas
tarjetas elaboradas en sesiones de diseño de 10 a 30 minutos. Esta es la práctica donde
se impone el minimalismo de YAGNI: no implementar nada que no se necesite ahora;
o bien, nunca implementar algo que vaya a necesitarse más adelante; minimizar
diagramas y documentos.
5. Prueba continua.
El desarrollo está orientado por las pruebas. Los clientes ayudan a
escribir las pruebas funcionales antes que se escriba el código. Esto es test-driven
development. El propósito del código real no es cumplir un requerimiento, sino pasar
las pruebas. Las pruebas y el código son escritas por el mismo programador, pero la
prueba debería realizarse sin intervención humana, y es a todo o nada. Hay dos clases
de prueba: la prueba unitaria, que verifica una sola clase, o un pequeño conjunto de
clases; la prueba de aceptación verifica todo el sistema, o una gran parte.
6. Refactorízación continua.
Se refactoriza el sistema eliminando duplicación,
mejorando la comunicación y agregando flexibilidad sin cambiar la funcionalidad. El
proceso consiste en una serie de pequeñas transformaciones que modifican la
estructura interna preservando su conducta aparente. La práctica también se conoce
como Mejora Continua de Código o Refactorízación implacable. Se lo ha
parafraseado diciendo: “Si funciona bien, arréglelo de todos modos”. Se recomiendan
herramientas automáticas. En sus comentarios a [Hig00b] Ken Orr recomienda
GeneXus de ARTech, Uruguay, virtuoso ejecutor de las mejores promesas
incumplidas de las herramientas CASE.
7. Programación en pares.
Todo el código está escrito por pares de programadores.
Dos personas escriben código en una computadora, turnándose en el uso del ratón y el
teclado. El que no está escribiendo, piensa desde un punto de vista más estratégico y
realiza lo que podría llamarse revisión de código en tiempo real. Los roles pueden
cambiarse varias veces al día. Esta práctica no es en absoluto nueva. Hay
El término refactoring, introducido por W. F. Opdyke en su tesis doctoral [Opd92], se refiere “al
proceso de cambiar un sistema de software [orientado a objetos] de tal manera que no se altere el
comportamiento exterior del código, pero se mejore su estructura interna”. Normalmente se
utilizan herramientas automáticas para hacerlo (DMS, GeNexus), y/o se implementan técnicas
tales como aserciones (invariantes, pre- y poscondiciones) para expresar propiedades que deben
conservarse antes y después de la refactoría. Otras técnicas son transformaciones de grafos,
métricas de software, refinamiento de programas y análisis formal de conceptos [MVD03]. Al
igual que sucede con los patrones, existe un amplio catálogo de refactorizaciones más comunes:
reemplazo de iteración por recursión; sustitución de un algoritmo por otro más claro; extracción de
clase, interface o método; descomposición de condicionales; reemplazo de herencia por delegación,
etcétera. La Biblia del método es Refactoring de Martin Fowler, Kent Beck, John Brant,
William Opdyke y Don Roberts [FBB+99].
antecedentes de programación en pares anteriores a XP [Hig00b]. Steve McConnell la
proponía en 1993 en su Code Complete [McC93: 528].
8. Propiedad colectiva del código.
Cualquiera puede cambiar cualquier parte del
código en cualquier momento, siempre que escriba antes la prueba correspondiente.
Algunas veces los practicantes aplican el patrón organizacional CodeOwnership de
Coplien [Cop95].
9. Integración continua.
Cada pieza se integra a la base de código apenas está lista,
varias veces al día. Debe correrse la prueba antes y después de la integración. Hay
una máquina (solamente) dedicada a este propósito.
10. Ritmo sostenible, trabajando un máximo de 8 horas por día.
Antes se llamaba a esta práctica Semana de 40 horas. Mientras en RAD las horas extras eran una best
practice [McC96], en XP todo el mundo debe irse a casa a las cinco de la tarde. Dado
que el desarrollo de software se considera un ejercicio creativo, se estima que hay que
estar fresco y descansado para hacerlo eficientemente; con ello se motiva a los
participantes, se evita la rotación del personal y se mejora la calidad del producto.
Deben minimizarse los héroes y eliminar el “proceso neurótico”. Aunque podrían
admitirse excepciones, no se permiten dos semanas seguidas de tiempo adicional. Si
esto sucede, se lo trata como problema a resolver.
11. Todo el equipo en el mismo lugar.
El cliente debe estar presente y disponible a
tiempo completo para el equipo. También se llama El Cliente en el Sitio. Como esto
parecía no cumplirse (si el cliente era muy junior no servía para gran cosa, y si era
muy senior no deseaba estar allí), se especificó que el representante del cliente debe
ser preferentemente un analista. (Tampoco se aclara analista de qué; seguramente se
definirá en una próxima versión).
12. Estándares de codificación.
Se deben seguir reglas de codificación y comunicarse a
través del código. Según las discusiones en Wiki, algunos practicantes se
desconciertan con esta regla, prefiriendo recurrir a la tradición oral. Otros la resuelven
poniéndose de acuerdo en estilos de notación, indentación y nomenclatura, así como
en un valor apreciado en la práctica, el llamado “código revelador de intenciones”.
Como en XP rige un cierto purismo de codificación, los comentarios no son bien
vistos. Si el código es tan oscuro que necesita comentario, se lo debe reescribir o
refactorizar.
13. Espacio abierto.
Es preferible una sala grande con pequeños cubículos o, mejor
todavía, sin divisiones. Los pares de programadores deben estar en el centro. En la
periferia se ubican las máquinas privadas. En un encuentro de espacio abierto la
agenda no se establece verticalmente.
14. Reglas justas.
El equipo tiene sus propias reglas a seguir, pero se pueden cambiar en
cualquier momento. En XP se piensa que no existe un proceso que sirva para todos
los proyectos; lo que se hace habitualmente es adaptar un conjunto de prácticas
simples a la características de cada proyecto.
Las prácticas se han ido modificando con el tiempo. Originariamente eran doce; de
inmediato, trece. Las versiones más recientes enumeran diecinueve prácticas, agrupadas
en cuatro clases.
Prácticas conjuntas
Iteraciones
Vocabulario Común – Reemplaza a Metáforas
Espacio de trabajo abierto
Retrospectivas
Prácticas de Programador
Desarrollo orientado a pruebas
Programación en pares
Refactorización
Propiedad colectiva
Integración continua
YAGNI (“No habrás de necesitarlo”) – Equivale a Diseño Simple
Prácticas de Management
Responsabilidad aceptada
Cobertura aérea para el equipo
Revisión trimestral
Espejo – El manager debe comunicar un fiel reflejo del estado de cosas
Ritmo sostenible
Prácticas de Cliente
Narración de historias
Planeamiento de entrega
Prueba de aceptación
Entregas frecuentes
Mientras esto se escribe, Ward Cunningham sugiere rebautizar las prácticas como
Xtudios (Xtudes). Oficialmente las prácticas siguen siendo doce y su extensión se basa en
documentos inéditos de Kent Beck. Las prácticas no tratan en detalle el proceso de
entrega, que es casi un no-evento.
Al lado de los valores y las prácticas, XP ha abundado en acrónimos algo extravagantes
pero eficaces, que sus seguidores intercambian con actitud de complicidad. YAGNI
significa “You Aren’t Gonna Need It”; TETCPB, “Test Everything That Can Possibly
Broke”; DTSTTCPW, “Do The Simplest Thing That Can Possibly Work”, etcétera. Del
mismo modo, BUFD (“Big Up Front Design”) es el mote peyorativo que se aplica a los
grandes diseños preliminares de los métodos en cascada, “el Libro Verde” es Planning
Extreme Programming de Kent Beck y Martin Fowler [BF00], y “el Libro Blanco” es
Extreme Programming Explained de Kent Beck [Beck99a]. Todo el mundo en XP sabe,
además, qué significan GoF, PLOPD o POSA. Al menos en la concepción de
Cunningham y Wiki, parecería que quien conoce más mantras y acrónimos, gana.
Beck [Beck99a] sugiere adoptar XP paulatinamente: “Si quiere intentar con XP, por Dios
le pido que no se lo trague todo junto. Tome el peor problema de su proceso actual y trate
de resolverlo a la manera de XP”. Las prácticas también pueden adaptarse a las
características de los sistemas particulares. Pero no todo es negociable y la integridad del
método se sabe frágil. La particularidad de XP radica en no requerir ninguna herramienta
fuera del ambiente de programación y prueba. Al contrario de otros métodos, que
permiten modelado, XP demanda comunicación oral tanto para los requerimientos como
para el diseño. Beck [Beck99b] ha llegado a decir: “También yo creo en el modelado;
sólo que lo llamo por su nombre propio, ‘mentir’, y trato de convertirlo en arte”.
El ciclo de vida es, naturalmente, iterativo. El siguiente diagrama describe su cuerpo
principal:
Ciclo de vida de XP
Algunos autores sugieren implementar spikes (o sea “púas” o “astillas”) para estimar la
duración y dificultad de una tarea inmediata [JAH01]. Un spike es un experimento
dinámico de código, realizado para determinar cómo podría resolverse un problema. Es la
versión ágil de la idea de prototipo. Se lo llama así porque “va de punta a punta, pero es
muy fino” y porque en el recorrido de un árbol de opciones implementaría una opción de
búsqueda depth-first (http://c2.com/cgi/wiki?SpikeSolution).
Entre los artefactos que se utilizan en XP vale la pena mencionar las tarjetas de historias
(story cards); son tarjetas comunes de papel en que se escriben breves requerimientos de
un rasgo, jamás casos de uso; pueden adoptar el esquema CRC. Las tarjetas tienen una
granularidad de diez o veinte días. Las tarjetas se usan para estimar prioridades, alcance y
tiempo de realización; en caso de discrepancia, gana la estimación más optimista. Otros
productos son listas de tareas en papel o en una pizarra (jamás en computadora) y
gráficos visibles pegados en la pared. Martin Fowler admite que la preferencia por esta
clase de herramientas ocasiona que el mensaje entre líneas sea “Los XPertos no hacen
diagramas” [Fow01].
Los roles de XP son pocos. Un cliente que escribe las historias y las pruebas de
aceptación; programadores en pares; verificadores (que ayudan al cliente a desarrollar las
pruebas); consultores técnicos; y, como parte del management, un coach o consejero que
es la conciencia del grupo, interviene y enseña, y un seguidor de rastros (tracker) que
colecta las métricas y avisa cuando hay una estimación alarmante, además de un Gran
Jefe. El management es la parte menos satisfactoriamente caracterizada en la bibliografía,
como si fuera un mal necesario; Beck comenta, por ejemplo, que la función más relevante
del coach es la adquisición de juguetes y comida [Hig00b]; otros dicen que está para
servir café. Lo importante es que el coach se vea como un facilitador, antes que como
quien dá las órdenes. Los equipos de XP son típicamente pequeños, de tres a veinte
personas, y en general no se cree que su escala se avenga al desarrollo de grandes
sistemas de misión crítica con tanta comodidad como FDD.
Algunas empresas han creado sus propias versiones de XP, como es el caso de Standard
& Poor’s, que ha elaborado plantillas para proyectos futuros. XP se ha combinado con
Evo, a pesar que ambos difieren en su política de especificaciones; también se estima
compatible con Scrum, al punto que existe una forma híbrida, inventada por Mike
Beedle, que se llama XBreed [http://www.xbreed.net] y otra bautizada XP@Scrum
[http://www.controlchaos.com/xpScrum.htm] en la que Scrum se usa como envoltorio de
gestión alrededor de prácticas de ingeniería de XP. Se lo ha combinado muchas veces con
UP, aunque éste recomienda pasar medio día de discusión de pizarra antes de programar
y XP no admite más de 10 o 20 minutos. La diferencia mayor concierne a los casos de
uso, que son norma en UP y que en XP se reemplazan por tarjetas de papel con historias
simples que se refieren a rasgos. En las herramientas de RUP ahora hay plug-ins para XP.
Los obstáculos más comunes surgidos en proyectos XP son la “fantasía” [Lar04] de
pretender que el cliente se quede en el sitio y la resistencia de muchos programadores a
trabajar en pares. Craig Larman señala como factores negativos la ausencia de énfasis en
la arquitectura durante las primeras iteraciones (no hay arquitectos en XP) y la
consiguiente falta de métodos de diseño arquitectónico. Un estudio de casos de Bernhard
Rumpe y Astrid Schröder sobre 45 ejemplares de uso reveló que las prácticas menos
satisfactorias de XP han sido la presencia del usuario en el lugar de ejecución y las
metáforas, que el 40% de los encuestados no comprende para qué sirven o cómo usarlas
[RS01]. Las metáforas han sido reemplazadas por un Vocabulario Común (equivalente al
“Sistema de Nombres” de Cunningham) en las últimas revisiones del método.
XP ha sido, de todos los MAs, el que más resistencia ha encontrado [Rak01] [McB02]
[Baer03] [Mel03] [SR03]. Algunos han sugerido que esa beligerancia es un efecto de su
nombre, que debería ser menos intimidante. Jim Highsmith [Hig02a] argumenta, sin
embargo, que es improbable que muchos se entusiasmen por un libro que se titule, por
ejemplo, Programación Moderada. Los nuevos mercados, tecnologías e ideas –piensa
Highsmith– no se forjan a fuerza de moderación sino con giros radicales y con el coraje
necesario para desafiar al status quo; XP, en todo caso, ha abierto el camino.
Page updated
Google Sites
Report abuse