METODOLOGIAS CRYSTAL EN METODOS AGILES

INTRODUCCION
Las metodologas giles, se han comenzado ha desarrollar hace muy poco tiempo, dentro de
estas encontramos la Metodologa Cristal la cual identifica con colores diferentes cada
mtodo, y su eleccin debe ser consecuencia del tamao y criticidad del proyecto, de forma
que los de mayor tamao, o aquellos en los que la presencia de errores o desbordamiento de
agendas implique consecuencias graves, deben adoptar metodologas ms pesadas. De esta
forma se pretende obtener mayor rentabilidad en el desarrollo de proyectos de software,
Los mtodos Crystal no prescriben prcticas concretas, porque estn en continuo cambio.
PLANTEAMIENTO
Las metodologas giles, son una herramienta que nos facilita en el desarrollo de software,
De esta forma se agilizan los procesos de construccin de proyectos. Tambin se puede
observar que por medio de estas metodologas podemos obtener ms fiabilidad y calidad en
menos tiempo y con menos costo. Estas metodologas dependen de dos factores
importantes como lo son El nmero de personas en el proyecto, y Las consecuencias de los
errores. Su nombre se debe a las facetas de una gema: cada faceta es otra versin del
proceso, y todas se sitan en torno a un ncleo idntico. Dado que el tamao del proyecto
indica el mtodo a utilizar, se estableci una clasificacin por colores, por ejemplo Cristal
Crear (3 a 8 personas), seguido por Yellow (10 a 20 personas), Crystal Orange (25 a 50
personas), y as sucesivamente hasta azul, mientras que la importancia indica la dureza con
que se debe aplicar. Tambin el cdigo matemtico se aplica de forma tabular y se sita un
rango de complejidad al cual se aplica una metodologa.
Tambin podemos encontrar dentro de estas metodologas giles la metodologa llamada
Clear, la cual se basa La ms documentada es Crystal Clear (CC) al igual que la Crystal
Orange apto para proyectos de duracin estimada en 2 aos.
CC puede ser usado en proyectos pequeos y como casi todos los otros mtodos, CC
consiste en valores, tcnicas y procesos. Y las propiedades de CC son Entrega frecuente,
Comunicacin osmtica, Mejora reflexiva, Seguridad personal, foco. Fcil acceso a
usuarios expertos, Tambin estn compuestas por unas tcnicas, procesos, y existen unos
roles para cada persona que integra el desarrollo del software.
Existen software basados en metodologas cristal las cuales Integran estrechamente
capacidades de diseo, modificacin y visualizacin en aplicaciones .NET, Java o COM.
Tambin Permitir a los usuarios finales acceder e interactuar con los reportes a travs de
portales Web, dispositivos mviles y documentos de Microsoft Office. De esta forma
podemos darnos cuenta que la aplicacin de estas metodologas son extremadamente
recomendables en el buen desarrollo de proyectos de software.
DESARROLLO
Se tiene en cuenta que Crystal da vital importancia a las personas que componen el equipo
de un proyecto, y por tanto sus puntos de estudio son:
Aspecto humano del equipo,

Tamao de un equipo (nmero de componentes),

Comunicacin entre los componentes,
Distintas polticas a seguir,
Espacio fsico de trabajo.
Compuesta por una caractersticas importantes como lo son Crystal aconseja que el tamao
del equipo sea reducido (Pocos componentes) Tambin La mejora de la comunicacin entre
los miembros del equipo del proyecto, El Mismo lugar de trabajo Disminuye el coste de
la comunicacin y Mejora individual Mejora global del equipo, de esta forma se tienen en
cuenta las polticas de equipo Se utilizarn polticas diferentes para equipos diferentes
Codificacin por colores de Crystal: esto Dependiendo del tamao del equipo.
3-8
10-20
25-50
50-100
100-200
200-500
800+
Tambin podemos hablar de las herramientas y de los roles de las personas involucradas
Executive Sponsor (Patrocinador Ejecutivo)
Project Manager (Jefe de Proyecto)
Domain Expert (Experto en el Dominio),
Usage Expert (Experto de uso),
Designer-Programmer (Programador Diseador),
UI Designer (UI Diseador),
Tester (Realizador de Pruebas),
Technical (Programador Tcnico)
y las herramientas que son las siguientes, Sampler Catalog, Use Cases, Non funcional
Reqts, Architecture, Tests Cases, Writing Use, Responsabiliy, Program. Despus de esto se
puede hablar de los elementos basicos de las metodologas son los elementos a combinar
para el xito en un proyecto de desarrollo: estos son Quality, Tools, Products, Teams,
Standards, Roles, Activities, Skins, Techniques.
La importancia del tamao de un equipo es algo que no se puede dejar del lado se puede
tener presente que el Desarrollo + Tamao de equipo produce Metodologa ms pesada.
Tambin la importancia de la comunicacin La comunicacin es ms barata y mejor cuanto
ms
cercana
sea.
Crystal recomienda la interaccin cara a cara, por ser ste el mejor mtodo de
comunicacin.
Dentro de esta metodologa podemos encontrar la FDD es un mtodo gil, iterativo y
adaptativo. A diferencia de otras Metodologas giles, no cubre todo el ciclo de vida sino
slo las fases de diseo y construccin y se considera adecuado para proyectos mayores y
de misin crtica. FDD no requiere un modelo especfico de proceso y se complementa con
otras metodologas. Enfatiza cuestiones de calidad y define claramente entregas tangibles y
formas de evaluacin del progreso. FDD consiste en cinco procesos secuenciales durante
los cuales se disea y construye el sistema. La parte iterativa soporta desarrollo gil con

rpidas adaptaciones a cambios en requisitos y necesidades del negocio. Cada fase del
proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida. Tpicamente, la
iteracin de un rasgo emplea de una a tres semanas. Las fases se describen a continuacin:
Desarrollo de un modelo general, Construccin de la lista de rasgos, Planeacin por rasgo,
Diseo por rasgo y Construccin por rasgo. Por medio de estas metodologas podemos
hacer los proyectos mas optimos y con mayor calidad. Lo cual hace que el cliente se sienta
con superior tranquilidad de solicitar un buen desarrollo de software.
CONCLUSIONES
Cuantas ms personas estn implicadas, ms grande debe ser la metodologa.
Si el proyecto tiene mucha densidad, un error no detectado puede ser crtico.
El aumento de tamao o densidad aade un coste considerable al proyecto.
La forma ms eficaz de comunicacin es la interactiva (cara a cara).
En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas
han sido las "balas de plata" para el deseado xito en el desarrollo de software. El proceso
de desarrollo asumido en este contexto llevaba asociada una marcada tendencia hacia el
control del proceso mediante una rigurosa definicin de actividades, artefactos y roles. Este
esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo en
proyectos de gran envergadura donde por lo general se exige un alto grado de ceremonia en
el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los
proyectos actuales donde el contexto es muy cambiante, y en donde se exige reducir
drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En la prctica,
para muchos equipos de desarrollo, ante las dificultades para utilizar metodologas
tradicionales, se lleg a la resignacin de prescindir del "buen hacer" de la ingeniera del
software con el objetivo de ajustarse a estas restricciones. Ante esta situacin, las
metodologas giles aparecen como una posible respuesta para llenar este vaco
metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
metodologas giles constituyen una solucin a medida, con una elevada simplificacin que
a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto.
El tema es de rabiosa actualidad. La curiosidad que siente la mayor parte de ingenieros de
software, profesores, e incluso alumnos, sobre los mtodos giles hace prever una fuerte
proyeccin industrial de las metodologas giles. Por un lado, para muchos equipos de
desarrollo el uso de metodologas tradicionales les resulta muy lejano a su forma de trabajo
actual considerando las dificultades de su introduccin e inversin asociada en formacin y
herramientas. Por otro, las caractersticas de los proyectos para los cuales las metodologas
giles han sido especialmente pensadas se ajustan a unamplio rango de proyectos
industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son
pequeos, con plazos reducidos, requisitos voltiles, nuevas tecnologas, etc. Esto ltimo
abrira interesantes canales de cooperacin entre la industria y la universidad.
Tipos de metodologas de desarrollo de software
Existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del
proceso tradicionales que se centran especialmente en el control del proceso, estableciendo
rigurosamente las actividades involucradas, los artefactos que se deben producir, y las
herramientas y notaciones que se usarn .
Metodologas giles que se centran especialmente en el factor humano o el producto de
software, sea dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo
incremental del software con iteraciones muy cortas. Este enfoque est mostrando su

efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir

drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.
Hay que tener en cuenta que la frase mantener una alta calidad se ve como un objetivo
que personalmente, pienso que se cumple en cierta medida, sea que no se mantiene del
todo. Esto debido a que la optimizacin de tiempo a tiempo drstico que se define en este
texto, no me parece posible del todo.
Las metodologas giles estn revolucionando la manera de producir software, y a la vez
generando un amplio debate entre sus seguidores y quienes por escepticismo o
convencimiento no las ven como alternativa para las metodologas tradicionales.
Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos
desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo
del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una
de las actividades desarrolladas.
METODOLOGAS GILES
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil
aplicado al desarrollo de software.
Esto nos habla que las metodologas agiles de programacin son realmente nuevas, sin
embargo algunos desarrolladores piensan que representan la nueva era del desarrollo de
software.
En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo
algunos de los creadores o impulsores de metodologas de software
El punto de partida es fue el Manifiesto gil, un documento que resume la filosofa gil.
Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas.
Es ms importante construir un buen equipo que construir el entorno.
Desarrollar software que funciona ms que conseguir una buena documentacin.
No producir documentos a menos que sean necesarios de forma inmediata para
tomar un decisin importante.

La colaboracin con el cliente ms que la negociacin de un contrato.

Se propone que exista una interaccin constante entre el cliente y el equipo
de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan.
Se debe ser hbil en responder a los cambios y a los fracasos, la
planificacin no debe ser estricta sino flexible y abierta.
Metodologas giles
Basadas

en

heursticas

Metodologas Tradicionales
provenientes

de Basadas en normas provenientes de estndares

prcticas de produccin de cdigo

Especialmente preparados
durante el proyecto

para

seguidos por el entorno de desarrollo

cambios Cierta resistencia a los cambios

Impuestas internamente (por el equipo)

Proceso mucho
numerosas
polticas/normas

ms

controlado,

Impuestas externamente
con Proceso menos
principios

controlado,

con

pocos

No existe contrato tradicional o al menos es Existe un contrato prefijado

bastante flexible
El cliente interacta con el equipo de El cliente es parte del equipo de desarrollo
desarrollo
mediante reuniones
Grupos pequeos (<10
trabajando en el mismo sitio

integrantes)

y Grupos grandes y posiblemente distribuidos

Pocos artefactos

Ms artefactos

Pocos roles

Ms roles

Menos nfasis en la arquitectura del software

La arquitectura del software es esencial y se

expresa mediante modelos
Tabla 1. Diferencias entre metodologas giles y no gilesDentro de la familia de las
metodologas giles de desarrollo hay una variedad importante. Debemos hacer hincapi en
el hecho de que todas se basan en los 12 principios propuestos en el Manifiesto gil, pero
que cada una explota de manera difrente y en diferente grado cada uno de estos puntos.
De esta manera podemos elegir una de las metodologas giles para cada tipo de proyecto,
de forma que al priorizar ciertos puntos y al conocer las metodologas hacemos un trabajo
mejor acabado y mas rpido.
Crystal Methodologies
Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por
estar centradas en las personas que componen el equipo y la reduccin al mximo del
nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invencin y comunicacin,
limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se
deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de
trabajo en equi
Dynamic Systems Development Method (DSDM)
Define el marco para desarrollar un proceso de produccin de software. Nace en 1994 con
el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas son: es
un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.
Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseo y
construccin, y finalmente implementacin. Las tres ltimas son iterativas, adems de
existir realimentacin a todas las fases.

Adaptive Software Development (ASD)

Feature-Driven Development (FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2
semanas). Se centra en las fases de diseo e implementacin del sistema partiendo de una
lista de caractersticas que debe reunir el software. Sus impulsores son Jeff De Luca y Peter
Coad.
Lean Development (LD)
Definida por Bob Charettes a partir de su experiencia en proyectos con la industria
japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de
telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se
manejan adecuadamente se pueden convertir en oportunidades que mejoren la
productividad del cliente. Su principal caracterstica es introducir un mecanismo para
implementar dichos cambios.
Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo, orientado a los
componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que
propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera
de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda
desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al
cliente. La revisin de los componentes sirve para aprender de los errores y volver a iniciar
el ciclo de desarrollo.

Las metodologas Crystal. Otras metodologas giles que, quizs, te puedan

encajar ms que Scrum

Las metodologas Crystal son una familia de metodologas giles, donde cada
una de ellas est adecuada para un tipo de proyecto. Su creador es el popular
Cockburn uno de los firmantes del manifiesto gil.
Aparte de la popular Scrum, FDD, que vimos hace unos das (te dejo aqu aquel
post de FDD), y las metodologas Crystal tambin sirven para gestionar

proyectos giles, con la diferencia de que ests dos ltimas son menos
extremas y estn pensadas para ms tipologas de proyectos y organizaciones,
destacando especialmente proyectos y empresas grandes.
El nombre de metodologas Crystal viene de que cada proyecto software puede
caracterizarse segn dos dimensiones, tamao y criticidad, al igual que los
minerales se caracterizan por dos dimensiones, color y dureza. Y esta es una
de las bases de las metodologas Crystal: hay una metodologa para cada
proyecto, o la escala de Cockburn (te dejo este post para ampliar este tema).
La otra gran clave de metodologas Crystal, comn a casi todas las
metodologas giles, es que lo ms determinante para el xito, o fracaso, de un
proyecto son las persona (te dejo tambin este post de cuando tratamos este
tema). Una de las claves que determinan el xito (o fracaso) de un proyecto
software.
El que veis en la foto de este post es el libro ms destacado sobre las
metodologas Crystal (te dejo aqu un enlace)
Os dejo a continuacin un resumen de las claves de las metodologas Crystal.
Las metodologas Crystal: Una familia de metodologas giles segn sea tu
proyecto
En las metodologas Crystal, proyectos grandes, que necesitan ms
coordinacin y comunicacin, se asocian con colores ms oscuros. Proyectos en
los que un fallo pueda causar mayores problemas, tambin se asocian con
colores ms oscuros.
As, aparece una familia de metodologas:
Clear, para equipos de hasta 8 personas o menos.
Amarillo, de entre 10 y 20 personas.
Naranja, para equipos entre 20 y 50 personas.
Roja, entre 50 y 100 personas.
etc.
A ms personas en el proyecto, ms coordinacin. A ms criticidad en el
software, ms rigurosidad en el proceso. El factor ms determinante en
cualquier caso, la comunicacin entre los participantes en el proyecto.
Las 7 propiedades de las metodologas Crystal
Las metodologas Crystal cumplen todas ellas con 7 propiedades esenciales, las
siguientes:
1 Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En
funcin del proyecto puede haber desde entregas semanales hasta

trimestrales. Para los que conozcan Scrum: en Scrum las entregas son,
mximo, cada 4 semanas, en las Crystal se contemplan muchas ms opciones.
2 Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a
ir ajustando el proyecto, a ir mejorndolo.
3 Comunicacin osmtica. Traducido al castellano, que el equipo est en una
misma ubicacin fsica, para lograr la comunicacin cara a cara.
4 Seguridad personal. Todo el mundo puede expresar su opinin sin miedos,
tenindosele en cuenta, considerndose su opinin, etc.
5- Enfoque. Perodos de no interrupcin al equipo (2h horas), objetivos y
prioridades claros, definiendo as tareas concretas. Si llevas desde hace
tiempo pasando por este blog, recordars ya comentbamos, tiempo a, aquello
de que el entorno fsico afecta al rendimiento del desarrollador software (te
dejo aquel post).
6 Fcil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP)
no exigen que los usuarios estn continuamente junto al equipo de proyecto
(no todas las organizaciones pueden hacerlo), s que, como mnimo,
semanalmente debe haber reuniones y los usuarios deben estar accesibles.
7 Entorno tcnico con pruebas automatizadas, gestin de la configuracin e
integracin continua.Prcticas comunes en casi todas las metodologas giles,
te dejo un post sobre la integracin continua y el smoke test.
Concluyendo
No he querido alargar ms el post, aunque, como os podis imaginar, las
metodologas Crystal dan para mucho ms. De hecho, en el libro sobre las
metodologas Crystal (te dejo aqu un enlace al libro) se detallan mucho ms
los procesos de las metodologas, errores frecuentes, el detalle del ciclo de vida
iterativo e incremental, etc.
Qudate con que hay ms opciones dentro de la agilidad. Scrum, XP, FDD y
metodologas Crystal, entre otras. Varias soluciones para diferentes problemas,
empresas, y proyectos.