METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE

METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE

CRYSTAL

Introducción

Crystal es una metodología de desarrollo de Software ágil, más que una metolodogía se la considera una familia de metodologías, debido a que se subdivide en varios tipos de metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Es una metodología que ha sido creada por una persona en particular (Alistair Cockburn ) el cuál llego la creó en base al análisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cuál fusionando ambos aspectos dio lugar a una metodología bastante interesante, la cual se presenta a continuación.

Desarrollo de la metodología

Antecedentes

En los inicios de 1990, en un estudio realizado en IBM se llegó a los siguientes acuerdos (Cockburn, 2001). Los equipos exitosos enfatizaban que no habían seguido métodos formales ni herramientas CASE y que habían estimulado la comunicación y los test.

Los equipos con problemas no entendían sus fallas o si habían cumplido con los métodos formales.

Qué es Crystal Clear

Crystal Clear no es una metodología en si misma sino una familia de metodologías con un “código genético” común.

El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza).

Por ejemplo.

• Clear es para equipos de hasta 8 personas o menos.

• Amarillo para equipos entre 10 a 20 personas.

• Naranja para equipos entre 20 a 50 persona.

• Roja para equipos entre 50 a 100 personas.

• Azul para equipos entre 100 a 200 personas.

CC puede ser usado en proyectos pequeños y como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.

En primera instancia se especifican los antecedentes de la metodología, continuando con definiciones que ayudan a estructurar la fundamentación teórica y se termina con las características esenciales de los diferentestipos de Crystal.

La conclusión:

Menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Lo primero son promesas, lo segundo hechos. Cada proyecto necesita sus propios métodos. Alistair Cockburn en lugar de partir solamente de su experiencia personal para construir una teoría de cómo deben hacerse las cosas complementa su experiencia directa con la búsqueda activa de proyectos para ver cómo trabajan.

Él ha explorado a fondo los métodos ágiles, haciendo énfasis en la familia de metodologías Crystal. Es una familia porque cree que los diferentes tipos de proyectos requieren diferentes tipos de metodologías. Él mira esta variación a lo largo de dos ejes: el número de personas en el proyecto, y las consecuencias de los errores.

Cada metodología encaja en una parte diferente, de modo que para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de seis personas.

La familia de metodologías Crystal comparten con la XP una orientación humana, pero esta centralización en la gente se hace de una manera diferente. Alistair considera que las personas encuentran difícil seguir un proceso disciplinado, así que más que seguir la alta disciplina de la XP, Alistair explora la metodología menosdisciplinada que aun podría tener éxito, intercambiando conscientemente productividad por facilidad de ejecución. Él considera que aunque Crystal es menos productivo que la XP, más personas serán capaces de seguirlo.

Alistair también pone mucho peso en las revisiones al final de la iteración, animando al proceso a aplicar técnicas de mejoramiento continuo en forma automática. Su aserción es que el desarrollo iterativo está para encontrar los problemas temprano, y entonces permitir corregirlos. Esto pone más énfasis en la gente supervisando su proceso y afinándolo conforme desarrollan.

Definiciones

Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos.

El desarrollo de software se considera un juego cooperativo de invención y comunicación, 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 políticas de trabajo en equipo definidas.

Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

Características

Las personas, como dispositivos activos, tienen modos de éxito y modos de fallo. Los siguientes son los principales:

• Cuando el número de personas aumenta, también aumenta la necesidad de coordinar.

• Cuando el potencial de daños se incrementa, la tolerancia a variaciones se ve afectada.

• La sensibilidad del tiempo en que se debe estar en el mercado varía: a veces este tiempo debe acortarse al máximo y se toleran defectos, otras se enfatiza la auditoria, confiabilidad, protección legal, entre otros.

• Las personas se comunican mejor cara a cara, con la pregunta y la respuesta en el mismo espacio de tiempo.

• El factor más significativo es “comunicación”.

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 para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100.

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. El otro método elaborado en profundidad es el Naranja, apto para proyectos de duración estimada en 2 años. 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 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 o mensual.

2) Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseñador senior y discutir respecto del tema que se trate.

3) Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.

4) Seguridad personal. Hablar con los compañeros cuando algo molesta dentro del grupo.

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

6) Fácil acceso a usuarios expertos. Tener alguna comunicación con expertos desarrolladores.

Crystal Clear no requiere ninguna estrategia o técnica, pero siempre es útil tener unas cuantas a mano para empezar. Las estrategias comunes a otras Metodologías Ágiles, 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.

2) Victoria temprana. Es mejor buscar pequeños triunfos iniciales que aspirar a una gran victoria tardía

3) Esqueleto ambulante. Es una transacción que debe ser simple pero completa.

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.

En cuanto a las técnicas, se favorecen:

a) Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener visiones más ricas.

b) Talleres de refl exió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.

c) 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 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

...