METODOLOGÍA DE

DESARROLLO ÁGIL CRYSTAL

Crystal es una metodología de desarrollo de Software ágil y más que una
metodología se le considera una familia de metodologías debido a que se
subdivide en varios tipos de metodologías en función a la cantidad de
personal que vayan a estar en el proyecto. Es una metodología que ha sido
creada por una persona en particular (Alistair Cockburn ).
Él la creó en base al análisis de distintos proyectos de desarrollo de software y
su propia experiencia.
Observación personal de Alistair Cockburn

o La metodología crystal no es una metodología

disciplinada
o Permite intercambiar productividad por fácil
ejecución
o Se aplican técnicas de mejoramiento continuo
o Sirve para encontrar los problemas
tempranamente
o El observa esta metodología en función de las
personas y los errores
o La metodología crystal al igual que xp se
centran en los recursos humanos
 Metodología Crystal
La familia Crystal dispone un código de color para marcar la complejidad de una
metodología:
o Cuanto más oscuro un color, más “pesado” es el método.
o Cuanto más crítico es un sistema, más rigor se requiere.
o Crystal es fácil de aprender en implementar.

CLEAR AMARILLO NARANJA ROJO AZUL

Equipos de 8 Equipos de 10 a 20 Equipos de 20 a 50 Equipos de 50 a Equipos de 100 a
personas o menos personas personas 100 personas 200 personas
Codificación de colores
CLEAR AMARILLO NARANJA ROJO
Codificación de colores
En la figura anterior aparecen unos caracteres (C, D, E y L) e indican las pérdidas
potenciales por fallos del sistema, y lo hacen de la siguiente manera:

C Perdida de confort
por fallas del
D Perdida de dinero
discrecional, es
decir del que
sistema
podemos disponer

E Perdida de dinero
esencial, es decir
dinero que
L De Life en inglés,
vida. Indica la
perdida de vidas
probablemente no por fallas del
es nuestro sistema
 Propiedades de crystal
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 o
mensual (2 semanas y no más de un mes).
Comunicación osmótica
Todos juntos en el mismo cuarto (cara a cara). La comunicación es más barata y mejor
cuanto más “cercana” sea.
Promueve prácticas como el uso de pizarrones, pizarras y espacios destinados a que
todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo.
Mejora reflexiva
Tomarse un pequeño tiempo (unas pocas horas cada semana o una vez al mes) para
pensar bien qué se está haciendo, tomar notas, reflexionar, discutir.
Fácil acceso a usuarios expertos
Tener alguna comunicación con expertos desarrolladores.
Herramientas y Técnicas
• Catalogo simple
• Caso de uso
• Requisito de diseño no funcional
Herramientas • Arquitectura
• Prueba de casos
• Diseño de interfaz de usuario

• Entrevistas de proyectos
• Talleres de reflexión
• Planeamiento Blitz
Técnica • Estimación Delphi con estimaciones de pericia
• Encuentros diarios de pie
• Miniatura de procesos
• Gráficos de quemado
Técnicas
Entrevistas de proyectos
Se suele entrevistar a más de un responsable para tener visiones más ricas.
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.
Planeamiento Blitz
Se escriben las funciones del programa en tarjetas y los programadores estiman
tiempos para cada una de forma independiente entre las mismas.
Estimación Delphi con estimaciones de pericia
Los expertos se reúnen y definen el tamaño del proyecto, fecha de entrega, etc.
 Técnicas
Encuentros diarios de pie
Cinco a diez minutos como máximo. No se trata de discutir problemas, sino de
identificarlos.
Miniatura de procesos
Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día.
La idea es que la gente pueda “degustar” la nueva metodología.
Gráficos de quemado
Son gráficas en las cuales se observan retrasos en las tareas, este gráfico sirve
para tener un control del proyecto y ver en que funciones deben tener mayor
prioridad.
Programación lado a lado
Establece proximidad, pero cada quien se enfoca 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.
Estrategias
Todas describen una forma de tomar ventaja del desarrollo incremental para
establecer valor desde el principio.
 Estrategias
Ni las estrategias ni las técnicas son mandatorias para Crystal Clear. Pero es
bueno tener en cuenta algunas de ellas al momento de empezar a trabajar.

Tres de las estrategias que están más relacionadas son:

o Apuntar a tener "Victorias Tempranas“.
o Arrancar el desarrollo de lo que se denomina un "Esqueleto que Camine“.
o Pensar siempre en hacer "Re arquitectura Incremental" van de la mano.
El poder arrancar el proceso a partir de un esqueleto sobre el cual se irá
agregando funcionalidad en cada una de las entregas ayuda a que se vean los
avances desde el comienzo (aunque sea una simple pantalla de ABM que se
conecta con la base de datos y muestra un solo dato). A medida que se avanza
en el proceso, la re arquitectura permitirá ir agregando más "cuerpo" al
esqueleto inicial.
Roles
Hay ocho roles nominados en Crystal En Crystal Naranja se agregan aun más
Clear: roles:
o Patrocinador. o Diseñador de IU (Interfaz de Usuario).
o Usuario Experto. o Diseñador de Base de Datos.
o Diseñador Principal. o Experto en Uso.
o Diseñador Programador. o Facilitador.
o Experto en Negocios. o Técnico.
o Coordinador. o Analista/Diseñador de Negocios.
o Verificador. o Arquitecto.
o Escritor. o Mentor de Diseño.
o Punto de Reutilización
Ventajas
o Es apropiada para entornos ligeros
o Al estar diseñada para el cambio experimenta reducción
de costo.
o Presenta una planificación más transparente para los
clientes.
o Se definen en cada iteración cuales son los objetivos de
la siguiente.
o Permite tener una muy útil
realimentación de los usuarios.

Desventajas
o Delimita el alcance del proyecto
con el cliente.
En resumen
La guía de trabajo que presenta Crystal Clear es altamente recomendable para
equipos pequeños. Da flexibilidad y prioriza la parte humana (como todas las
Metodologías Agiles), apuntando a lograr eficiencia, habitabilidad y confianza en
los miembros del equipo.
Presta especial importancia a la ubicación física del grupo, donde la
comunicación cumple el principal rol. La entrega frecuente de código confiable y
"funcionando" mantiene el foco y evita distracciones.
El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado
en cada proyecto.
Conclusiones
o Cuantas más personas estén implicadas, más grande debe ser la metodología.
o Si el proyecto tiene mucha densidad, un error no detectado puede ser crítico.
o El aumento de tamaño o densidad añade un coste considerable al proyecto.
o La forma más eficaz de comunicación es la interactiva (cara a cara).
Bibliografía
o Hans Van Vliet, “Software Engineering. Principles and Practice” (Tercera
edición, 2002).
o Ian Sommerville, “Software Engineering” (Sexta Edición, 2001).
o Ivar Jacobson, Grady Booch y James Rumbaugh, “The Unified Software
Development Process” (1999).
o https://metodosdesarrolloagil.wikispaces.com/-+Crystal
INTEGRANTES:
 DANIEL LAURA

 Y E S S I C A S I LV E S T R E

 M E L I S S A TA N TA C A L L E

 KAREN ZALLES