Desarrollo ágil de software: Crystal Clear

Home » Desarrollo ágil de software: Crystal Clear

17424
Crystal es una metodología de desarrollo de Software ágil, que en realidad está considerada como una «familia de metodologías» debido a que se subdivide en varios tipos de metodologías en función a la cantidad de personas que vayan a conformar el proyecto. Creada por Alistair Cockburn.

Crystal Clear es 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. Por ejemplo:

  • Clear es para equipos de hasta 6 personas o menos.
  • Amarillo para equipos entre 7 a 20 personas.
  • Naranja para equipos entre 21 a 40 personas.
  • Roja  para equipos entre 41 a 80 personas.
  • Marron para equipos entre 81 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 diferentes tipos de Crystal.

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
* Tamaño de un equipo (número de componentes)
* Comunicación entre los componentes
* Distintas políticas a seguir
* Espacio físico de trabajo

Los valores o propiedades de CC son:

1) Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente 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.

 

Los roles en CC son:

Patrocinador. 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 modos de operación, información a visualizar simultáneamente, navegación, etc.

Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al menos un  profesional de Nivel 3.

En Metodologías Ágiles 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.

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. Un programa en CC es “diseño y programa”;
sus programadores son diseñadores­ / programadores.

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 la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del proyecto, la lista de Riesgos, etc.

Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo  de varias personas.

Escritor. Produce el Manual de Usuario.

Como todas las metodologías ágiles, se basa en ciclos iterativos de desarrollo incremental, a lo que añade una reunión previa y posterior al ciclo, en la que reflexiona sobre el proyecto y sobre como ha ido ese ciclo. Antes de comenzar el siguiente ciclo al menos dos usuarios finales deben revisar, de forma independiente, lo desarrollado y validarlo.

By | 2017-07-26T16:08:12-03:00 enero 5th, 2015|Categories: General|1 Comment

About the Author:

Comments are closed.