Crystal Clear

La familia Crystal dispone un código de color para marcar la complejidad de una

metodología: cuanto más oscuro un color, más “pesado” es el método. Cuanto más crítico

es un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular

elaborada por Cockburn que se usa en muchos MAs para situar el rango de complejidad

al cual se aplica una metodología. En la figura se muestra una evaluación de las pérdidas

que puede ocasionar la falla de un sistema y el método requerido según este criterio. Los

parámetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas

(L). En otras palabras, la caída de un sistema que ocasione incomodidades indica que su

nivel de criticalidad es C, mientras que si causa pérdidas de vidas su nivel es L. Los

números del cuadro indican el número de personas afectadas a un proyecto, ±20%.

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra

versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes

de metodologías: Crystal Clear (“Claro como el cristal”) para equipos de 8 o menos

integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se promete

seguir con Marrón, Azul y Violeta. La más exhaustivamente documentada es Crystal

Clear (CC), y es la que se ha de describir a continuación. CC puede ser usado en

proyectos pequeños de categoría D6, aunque con alguna extensión se aplica también a

niveles E8 a D10. El otro método elaborado en profundidad es el Naranja, apto para

proyectos de duración estimada en 2 años, descripto en Surviving Object-Oriented

Projects [Coc97b]. Los otros dos aún se están desarrollando. Como casi todos los otros

métodos, CC consiste en valores, técnicas y procesos.

Los siete valores o propiedades de CC [Coc02] son:

1. Entrega frecuente.

Consiste en entregar software a los clientes con frecuencia, no

solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede

ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue,

si es que se consigue algún usuario cortés o curioso que suministre feedback.

2. Comunicación osmótica.

Todos juntos en el mismo cuarto. Una variante especial es

disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la

Oreja. Una reunión separada para que los concurrentes se concentren mejor es

descripta como El Cono del Silencio.

3. Mejora reflexiva.

Tomarse un pequeño tiempo (unas pocas horas cada algunas

semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas,

reflexionar, discutir.

4. Seguridad personal.

Hablar cuando algo molesta: decirle amigablemente al manager

que la agenda no es realista, o a un colega que su código necesita mejorarse, o que

sería conveniente que se bañase más seguido. Esto es importante porque el equipo

puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos

con gentileza y conciliación. Técnicamente, estas cuestiones se han caracterizado

como una importante variable de confianza y han sido estudiadas con seriedad en la

literatura.

5. Foco.

Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo.

Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente

con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea

compelida a hacer otras cosas incompatibles.

6. Fácil acceso a usuarios expertos.

Una comunicación de Keil a la ACM demostró

hace tiempo, sobre una amplia muestra estadística, la importancia del contacto directo

con expertos en el desarrollo de un proyecto. No hay un dogma de vida o muerte

sobre esto, como sí lo hay en XP. Un encuentro semanal o semi-semanal con

llamados telefónicos adicionales parece ser una buena pauta. Otra variante es que los

programadores se entrenen para ser usuarios durante un tiempo. El equipo de

desarrollo, de todas maneras, incluye un Experto en Negocios.

7. Ambiente técnico con prueba automatizada, management de configuración e

integración frecuente.

Microsoft estableció la idea de los builds cotidianos, y no es

una mala práctica. Muchos equipos ágiles compilan e integran varias veces al día.

Crystal Clear no requiere ninguna estrategia o técnica, pero conviene tener unas cuantas a

mano para empezar.

Las estrategias documentadas favoritas, comunes a otros MAs, son:

1. Exploración de 360°.

Verificar o tomar una muestra del valor de negocios del

proyecto, los requerimientos, el modelo de dominio, la tecnología, el plan del

proyecto y el proceso. La exploración es preliminar al desarrollo y equivale al período

de incepción de RUP. Mientras en RUP esto puede demandar algunas semanas o

meses, en Crystal Clear debe insumir unos pocos días; como mucho dos semanas si se

requiere usar una tecnología nueva o inusual. El muestreo de valor de negocios se

puede hacer verbalmente, con casos de uso u otros mecanismos de listas, pero debe

resultar en una lista de los casos de uso esenciales del sistema. Respecto de la

tecnología conviene correr unos pocos experimentos en base a lo que Cunningham y

Beck han llamado Spikes (http://c2.com/cgi/wiki?SpikeSolution).

2. Victoria temprana.

Es mejor buscar pequeños triunfos iniciales que aspirar a una

gran victoria tardía. La fundamentación de esta estrategia proviene de algunos

estudios sociológicos específicos. Usualmente la primera victoria temprana consiste

en la construcción de un Esqueleto Ambulante. Conviene no utilizar la técnica de “lo

peor primero” de XP, porque puede bajar la moral. La preferencia de Cockburn es “lo

más fácil primero, lo más difícil segundo”.

3. Esqueleto ambulante.

Es una transacción que debe ser simple pero completa. Podría

ser una rutina de consulta y actualización en un sistema cliente-servidor, o la

ejecución de una transacción en un sistema transaccional de negocios. Un Esqueleto

Ambulante no suele ser robusto; sólo camina, y carece de la carne de la funcionalidad

de la aplicación real, que se agregará incrementalmente. Es diferente de un Spike,

porque éste es “la más pequeña implementación que demuestra un éxito técnico

plausible” y después se tira, porque puede ser desprolijo y peligroso; un Spike sólo se

usa para saber si se está en la dirección correcta. El Esqueleto debe producirse con

buenos hábitos de producción y pruebas de regresión, y está destinado a crecer con el

sistema.

4. Rearquitectura incremental.

Se ha demostrado que no es conveniente interrumpir el

desarrollo para corregir la arquitectura. Más bien la arquitectura debe evolucionar en

etapas, manteniendo el sistema en ejecución mientras ella se modifica.

5. Radiadores de información.

Es una lámina pegada en algún lugar que el equipo

pueda observar mientras trabaja o camina. Tiene que ser comprensible para el

observador casual, entendida de un vistazo y renovada periódicamente para que valga

la pena visitarla. Puede estar en una página Web, pero es mejor si está en una pared,

porque en una máquina se acumulan tantas cosas que ninguna llama la atención.

Podría mostrar el conjunto de la iteración actual, el número de pruebas pasadas o

pendientes, el número de casos de uso o historias entregado, el estado de los

servidores, los resultados del último Taller de Reflexión. Una variante creativa es un

sistema de semáforos implementado por Freeman, Benson y Borning.

En cuanto a las técnicas, se favorecen:

1. Entrevistas de proyectos.

Se suele entrevistar a más de un responsable para tener

visiones más ricas. Cockburn ha elaborado una útil plantilla de dos páginas con

entrevistas que probó ser útil en diversos proyectos. La idea es averiguar cuales son

las prioridades, obtener una lista de rasgos deseados, saber cuáles son los

requerimientos más críticos y cuáles los más negociables. Si se trata de una

actualización o corrección, saber cuáles son las cosas que se hicieron bien y merecen

preservarse y los errores que no se quieren repetir.

2. Talleres de reflexión.

El equipo debe detenerse treinta minutos o una hora para

reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y

planear para el período siguiente. De aquí puede salir material para poner en un poster

como Radiador de Información.

3. Planeamiento Blitz.

Una técnica puede ser el Juego de Planeamiento de XP. En este

juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o función

visible en cada una. El grupo finge que no hay dependencias entre tarjetas, y las

alinea en secuencias de desarrollo preferidas. Los programadores escriben en cada

tarjeta el tiempo estimado para desarrollar cada función. El patrocinador o embajador

del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos

referidos y el valor de negocio de cada función. Las tarjetas se agrupan en períodos de

tres semanas llamados iteraciones que se agrupan en entregas (releases), usualmente

no más largas de tres meses [Beck01]. Pueden usarse tarjetas CRC. Cockburn

propone otras variantes del juego, como la Jam Session de Planeamiento del

Proyecto3 [Coc02]. Las diferencias entre la versión de Cockburn y el juego de XP son

varias: en XP las tarjetas tienen historias, en CC listas de tareas; el juego de XP

asume que no hay dependencias, el de CC que sí las hay; en XP hay iteraciones de

duración fija, en CC no presupone nada sobre la longitud de la iteración.

4. Estimación Delphi con estimaciones de pericia.

La técnica se llama así por analogía

con el oráculo de Delfos; se la describió por primera vez en el clásico Surviving

Object-Oriented Projects de Cockburn [Coc97b], reputado como uno de los mejores

libros sobre el paradigma de objetos. En el proceso Delphi se reúnen los expertos

responsables y proceden como en un remate para proponer el tamaño del sistema, su

tiempo de ejecución, la fecha de las entregas según dependencias técnicas y de

negocios y para equilibrar las entregas en paquetes de igual tamaño. La descripción

del remate está en [Coc02] e insume tres o cuatro páginas .

5. Encuentros diarios de pie.

La palabra clave es “brevedad”, cinco a diez minutos

como máximo. No se trata de discutir problemas, sino de identificarlos. Los

problemas sólo se discuten en otros encuentros posteriores, con la gente que tiene que

ver en ellos. La técnica se origina en Scrum. Se deben hacer de pie para que la gente

no escriba en sus notebooks, garabatee papeles o se quede dormida.

6. Miniatura de procesos.

La “Hora Extrema” fue inventada por Peter Merel para

introducir a la gente en XP en 60 minutos (http://c2.com/cgi/wiki?ExtremeHour) y

proporciona lineamientos canónicos que pueden usarse para articular esta práctica.

Una forma de presentar Crystal Clear puede insumir entre 90 minutos y un día. La

idea es que la gente pueda “degustar” la nueva metodología.

7. Gráficos de quemado.

Su nombre viene de los gráficos de quemado de calorías de

los regímenes dietéticos; se usan también en Scrum. Se trata de una técnica de

graficación para descubrir demoras y problemas tempranamente en el proceso,

evitando que se descubra demasiado tarde que todavía no se sabe cuánto falta. Para

ello se hace una estimación del tiempo faltante para programar lo que resta al ritmo

actual, lo cual sirve para tener dominio de proyectos en los cuales las prioridades

cambian bruscamente y con frecuencia. Esta técnica se asocia con algunos recursos

ingeniosos, como la Lista Témpana, llamada así porque se refiere al agregado de

ítems con alta prioridad en el tope de las listas de trabajos pendientes, esperando que

los demás elementos se hundan bajo la línea de flotación; los elementos que están

sobre la línea se entregarán en la iteración siguiente, los que están por debajo en las

restantes. En otros MAs la Lista Témpana no es otra cosa que un gráfico de retraso.

Los gráficos de quemado ilustran la velocidad del proceso, analizando la diferencia

entre las líneas proyectadas y efectivas de cada entrega, como se ilustra en las figuras.

8. Programación lado a lado.

Mucha gente siente que la programación en pares de XP

involucra una presión excesiva; la versión de Crystal Clear establece proximidad,

pero cada quien se aboca a su trabajo asignado, prestando un ojo a lo que hace su

compañero, quien tiene su propia máquina. Esta es una ampliación de la

Comunicación Osmótica al contexto de la programación.

Gráficos de quemado – Con necesidad de recortar retrasos (izq.) y con entrega proyectada en término.

Medición realizada en mayo – La fecha de entrega proyectada es el 1° de octubre

El proceso de CC se basa en una exploración refinada de los inconvenientes de los

modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos

entre 1970 y 2000 se describían como secuencias de pasos. Aún cuando se recomendaran

iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación)

los modelos parecían dictar un proceso en cascada, por más que los autores aseguraran

que no era así. El problema con estos procesos es que realmente están describiendo un

workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema

hasta que está integrado y corre. No puede integrar y verificar hasta que el código no está

escrito y corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles

son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese

sentido, aunque no haya sido la intención original.

En lugar de esta interpretación lineal, CC enfatiza el proceso como un conjunto de ciclos

anidados. En la mayoría de los proyectos se perciben siete ciclos: (1) el proyecto, (2) el

ciclo de entrega de una unidad, (3) la iteración (nótese que CC requiere múltiples

entregas por proyecto pero no muchas iteraciones por entrega), (4) la semana laboral, (5)

el período de integración, de 30 minutos a tres días, (6) el día de trabajo, (7) el episodio

de desarrollo de una sección de código, de pocos minutos a pocas horas.

Cockburn subraya que interpretar no linealmente un modelo de ciclos es difícil; la mente

se resiste a hacerlo. Él mismo asegura que estuvo diez años tratando de explicar el uso de

un proceso cíclico y sólo recientemente ha logrado intuir cómo hacerlo. La figura muestra

los ciclos y las actividades conectadas a ellos. Las letras denotan Chartering,

planeamiento de iteración, reunión diaria de pie (standup), desarrollo, check-in,

integración, taller de Reflexión, Entrega (Delivery), y empaquetado del proyecto

(Wrapup).

Hay ocho roles nominados en CC: Patrocinador, Usuario Experto, Diseñador Principal,

Diseñador-Programador, Experto en Negocios, Coordinador, Verificador, Escritor. En

Crystal Naranja se agregan aun más roles: Diseñador de IU, Diseñador de Base de Datos,

Experto en Uso, Facilitador Técnico, Analista/Diseñador de Negocios, Arquitecto,

Mentor de Diseño, Punto de Reutilización. A continuación se describen en bastardilla los

artefactos de los que son responsables los roles de CC, detalladamente descriptos en la

documentación.

1. Patrocinador.

Produce la Declaración de Misión con Prioridades de Compromiso

(Tradeoff). Consigue los recursos y define la totalidad del proyecto.

2. Usuario Experto.

Junto con el Experto en Negocios produce la Lista de Actores-

Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el

uso del sistema, sugerir atajos de teclado, modos de operación, información a

visualizar simultáneamente, navegación, etcétera.

3. Diseñador Principal.

Produce la Descripción Arquitectónica. Se supone que debe ser

al menos un profesional de Nivel 3. (En MAs se definen tres niveles de experiencia:

Nivel 1 es capaz de “seguir los procedimientos”; Nivel 2 es capaz de “apartarse de los

procedimientos específicos” y encontrar otros distintos; Nivel 3 es capaz de manejar

con fluidez, mezclar e inventar procedimientos). El Diseñador Principal tiene roles de

coordinador, arquitecto, mentor y programador más experto.

4. Diseñador-Programador.

Produce, junto con el Diseñador Principal, los Borradores

de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el

Código Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado.

Cockburn no distingue entre diseñadores y programadores. Un programa en CC es

“diseño y programa”; sus programadores son diseñadores-programadores. En CC un

diseñador que no programe no tiene cabida.

5. Experto en Negocios.

Junto con el Usuario Experto produce la Lista de Actores-

Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y

políticas del negocio.

6. Coordinador.

Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de

Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteración y

la Agenda de Visualización.

7. Verificador.

Produce el Reporte de Bugs. Puede ser un programador en tiempo

parcial, o un equipo de varias personas.

8. Escritor.

Produce el Manual de Usuario.

El Equipo como Grupo es responsable de producir la Estructura y Convenciones del

Equipo y los Resultados del Taller de Reflexión.

A pesar que no contempla el desarrollo de software propiamente dicho, CC involucra

unos veinte productos de trabajo o artefactos. Mencionamos los más importantes:

1. Declaración de la misión.

Documento de un párrafo a una página, describiendo el

propósito.

2. Estructura del equipo.

Lista de equipos y miembros.

3. Metodología.

Comprende roles, estructura, proceso, productos de trabajo que

mantienen, métodos de revisión.

4. Secuencia de entrega.

Declaración o diagrama de dependencia; muestra el orden de

las entregas y lo que hay en cada una.

5. Cronograma de visualización y entrega.

Lista, planilla de hoja de cálculo o

herramienta de gestión de proyectos.

6. Lista de riesgos.

Descripción de riesgos por orden descendente de prioridad.

7. Estatus del proyecto.

Lista hitos, fecha prevista, fecha efectiva y comentarios.

8. Lista de actores-objetivos.

Lista de dos columnas, planilla de hoja de cálculo,

diagrama de caso de uso o similar.

9. Casos de uso anotados.

Requerimientos funcionales.

10. Archivo de requerimientos.

Colección de información indicando qué se debe

construir, quiénes han de utilizarlo, de qué manera proporciona valor y qué

restricciones afectan al diseño.

Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los

productos que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP

y Microsoft Solutions Framework. En su comentario a [Hig00b], Cockburn confiesa que

cuando imaginó CC pensaba proporcionar un método ligero; comparado con XP, sin

embargo, CC resulta muy pesado. CC es más fácil de aprender e implementar; a pesar de

su jerga chocante XP es más disciplinado, piensa Cockburn; pero si un equipo ligero

puede tolerar sus rigores, lo mejor será que se mude a XP.