Crystal

INTRODUCCIÓN E HISTORIA.
* 1990 Alistair Cockburn -> construyó una familia de metodologías
* "Conjunto de muestras que usted ajusta a sus circunstancias"
* Cockburn nombró sus diferentes enfoques después de los cristales geológicos, con piedras más
duras como los diamantes que representan los enfoques más estructurados. Por el contrario, el
enfoque más fluido se llamó Crystal Clear.
Metodología.
* Enfoques varían de acuerdo con tres dimensiones: tamaño del equipo, criticidad, cuál es la
prioridad del proyecto.
* La premisa básica es que cuantas más personas tenga en el equipo, más crítico será el proyecto y
cuanto más regulado sea el tipo de proyecto, más estructurado y rígido debe ser el enfoque.
* Se centra en: Personas, Interacción, Comunidad, Habilidades, Talentos, Comunicaciones.
*Tamaño del equipo:
Crystal Clear – Entre 3 y 8 personas
Crystal Yellow – Entre 10 y 20 personas
Crystal Orange – Entre 25 y 50 personas
Crystal Red – Entre 50 y 100 personas
Crystal Magenta – Entre 100 y 200 personas
Crystal Blue – Entre 200 y 500 personas
Crystal Dark Blue – Más de 800 personas
* Se puede obtener más fiabilidad y calidad en menos tiempo y con menos costo.
* Criticidad:
Es el nivel de daño potencial que el sistema puede causar si no funciona como fue diseñado.
- Comodidad (C)
- Dinero discrecional (D)
- Dinero esencial (E)
- Vida (L)
* Fases:
- Proyecto en sí
- El ciclo de entrega de la unidad
- La iteración
- La semana laboral
- El periodo de integración (30 minutos a 3 días)
- El día de trabajo
- El fragmento de desarrollo de una sección de código, de pocos minutos a pocas horas.
* Roles en Crystal
El enfoque de Crystal define una serie de roles:
- Patrocinador del proyecto.
Produce la Declaración de Misión con Prioridades de Compromiso (Tradeoff). Consigue los
recursos y define la totalidad del proyecto.
- 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.
- Diseñador Principal.
Produce la Descripción Arquitectónica. Debe ser capaz de manejar con fluidez, mezclar e
inventar procedimientos. Tiene roles de coordinador, arquitecto, mentor y programador
más experto.
- 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.
- 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.
- Coordinador.
Con ayuda del equipo produce el mapa del 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.
- Verificador.
Produce el reporte de bugs.
- Escritor.
Produce manual de usuario
Estrategias.
o
o
o
o
o
Exploración 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.
Victoria Temprana.
Es mejor buscar pequeños triunfos iniciales que aspirar a una gran victoria tardía.
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.
Re-arquitectura 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.
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.
Técnicas
o
Entrevistas de proyectos.
o
o
o
o
o
o
o
Se suele entrevistar a más de un responsable para tener visiones más ricas. También es para
ver las prioridades, rasgos deseados, requerimientos más críticos y negociables, que se hizo
bien y que debe preservarse o que no.
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.
Planteamiento 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 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, usualmente
no más largas de tres meses.
Estimación Delphi con estimaciones de pericia.
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.
Encuentros diarios de pie.
La palabra clave es “brevedad”, cinco a diez minutos. No se trata de discutir problemas, sino
de identificarlos.
Miniatura de procesos.
La idea es que la gente pueda “degustar” la nueva metodología.
Gráficos de quemado.
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.
Programación lado a lado.
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.
Propiedades.
Las primeras 3 propiedades son obligatorias para todos los enfoques de la familia Crystal; pero solo
los primeros 3 son obligatorios para Crystal Clear.
1. Entrega frecuente:
La propiedad más importante en cada proyecto es entregar frecuentemente código probado y
funcional a usuarios reales. Si no hace esto, corre el riesgo de descubrir demasiado tarde que ha
producido un producto que nadie necesita.
2.Mejora reflexiva:
Los equipos deben trabajar juntos para descubrir cómo pueden mejorar sus prácticas laborales
futuras.
3.Comunicación osmótica:
La ósmosis es una forma de aprendizaje pasiva y sutil, una absorción gradual de información. las
personas necesitan un poco de espacio y sugiere que los equipos de ubicación conjunta también
tengan un área privada a la que las personas puedan ir.
4.Seguridad personal:
Todos los miembros del equipo deben poder hablar sin temor a ridiculizar o tomar represalias, ya
sea una nueva idea, una preocupación o un problema que estén enfrentando.
5.Enfoque:
Saber en qué trabajar y poder subirse y hacerlo. Esto sugiere una comunicación clara, priorización
de requisitos, establecimiento de objetivos, etc. También significa reducir el cambio de contexto.
6.Fácil acceso a usuarios expertos:
Recibir comentarios de usuarios reales
7.Entorno técnico con pruebas automatizadas, gestión de configuración e integración frecuente:
Estas son herramientas muy específicas para equipos de software que todavía no son comunes en
todos los equipos.
Diferencias con Metodologías Tradicionales.
1 = Tradicional, 2 = Crystal.
* Análisis de requerimientos y planificación:
1. Es una planificación predictiva y “aislada”
2. Es una adaptativa vista en entregas frecuentes y colaboración del cliente.
* Diseño:
1. Es flexible y extensible, modelos y documentación exhaustiva.
2. Es simple: documentación mínima enfocada en la comunicación.
* Codificación:
1. Desarrollo individual con roles y responsabilidades estrictas.
2. Transferencia de conocimiento: La programación en grupo propicia el conocimiento
colectivo.
* Pruebas y puesta en producción:
1. Actividades de control orientada a los hitos.
2. Liderazgo-Colaboración: Empoderamiento y auto-organización.
Conclusiones.
* Los equipos de desarrollo obtienen mejores resultados en un entorno seguro, desde un punto de
vista personal y emocional, y libre de ataques personales. Un concepto clave de Crystal Clear es
tener críticas constructivas, pero no vengativas.
* Cuantas más personas estén implicada, más grande debe ser la metodología.
* Si el proyecto tiene mucha densidad, un error no detectado puede ser crítico.
* El aumento de tamaño o densidad añade un coste considerable al proyecto.
* La forma más eficaz de comunicación es la interactiva (cara a cara).
"Reúna a algunos desarrolladores en paz, amor y armonía; código de envío cada dos meses, y surgirá
un buen software"