Crystal Clear

Francisco Garat Luque

Surgen como alternativa a las metodologías tradicionales

Individuos por encima de herramientas

Reducción de artefactos intermedios

Reducción en la toma de decisiones

Agilidad frente al cambio

Valorar

◦ Individuos vs herramientas

◦ El software que funciona vs documentación exhaustiva

◦ Colaboración con el cliente vs negociación

◦ Respuesta al cambio vs seguimiento del plan

Un cambio bastante importante en cuanto a la demanda del mercado de software, cada vez más orientada a la Web, con uno requisitos muy volátiles, que requieren tiempos de desarrollo cada vez más cortos, dota de mayor relevancia a las metodologías ágiles.

Conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo.

Los tipos de proyectos se clasifican según dos factores: ◦ El número de personas implicadas en el equipo de

desarrollo

◦ El riesgo del proyecto

La familia Crystal dispone de un código de colores para identificar el tipo de metodología, correspondiendo las metodologías más pesadas con los colores más oscuros. Use un equipo para guardar todos los comentarios y las ideas

Los proyectos grandes requieren más comunicación y coordinación con lo que se les asignan colores más oscuros, mientras que los proyectos críticos requieren más esfuerzos en validación y reglas de verificación.

Es la metodología más optimizada y ligera de la familia Crystal.

Pensada para equipos de trabajo pequeños (de una a ocho personas) con una cercanía en sus puestos de trabajo (misma oficina u oficinas adyacentes).

Propiedades más importantes

Entrega frecuente

Comunicación íntima

Mejora reflexiva

Otras propiedades

Seguridad personal (el primer paso en la confianza)

Enfoque

Acceso fácil a los usuarios especialistas

Ambiente Técnico con pruebas automatizadas

Administración de configuración e integración frecuente

Se consigue una valoración objetiva del progreso del equipo.

Los usuarios pueden ir viendo si el software se ajusta a sus requerimientos en etapa de desarrollo. Lo cual favorece la anticipación de cambios en una etapa temprana del proyecto.

Los diseñadores pueden mantener un enfoque salvando así la indecisión del usuario.

El equipo consigue poner a punto su desarrollo y el despliegue del proceso.

El objetivo es que el flujo de información pueda ser captado por cualquier miembro del equipo durante toda la fase de desarrollo. Así conseguimos que cualquier miembro del equipo decida si quiere dar su opinión acerca de una decisión del proyecto o seguir con su trabajo. Esto se consigue obligando al equipo de desarrollo a trabajar en la misma sala, así todos serán conscientes de las decisiones que se toman durante el desarrollo del proyecto.

“Parar de vez en cuando a reflexionar”

Tres preguntas:

¿Qué debemos guardar?

¿Dónde estamos teniendo problemas?

¿Qué es lo que vamos a hacer en la siguiente iteración?

Es el primer paso hacia la confianza

Hablar en confianza:

La incapacidad de llevar a cabo una asignación

La ignorancia de uno mismo

La detección de un error propio

Cada miembro debe tener bien claro en todo momento cuales son las dos prioridades más altas sobre lo que está trabajando.

Nos permite estar mejor concentrados en nuestro trabajo.

Proporciona:

Un espacio donde poder realizar las entregas frecuentes

Un mejor detalle en los requisitos

Más fluidez en el cambio

Reuniones con el usuario cada una o dos semanas con llamadas telefónicas entre dichas reuniones.

Involucrar en el equipo de desarrollo a uno o dos usuarios expertos.

Que los diseñadores sean usuarios aprendices durante un tiempo

Llevar a cabo las pruebas sin estar presentes y poder probar código indiscriminadamente nos da una ganancia vital en el tiempo del proyecto.

Permite a los desarrolladores trabajar separados y a la vez juntos.

Todos los desarrolladores deberían ingresar el código en el que trabajan en un sistema de administración de la configuración, de manera que este se encargue de llevar el control de versiones, documentos, etc.

El sistema se integra muy frecuentemente y se pasa por los test y las pruebas automatizadas. Tres niveles de pruebas: Pruebas con la GUI donde se simulen el ratón

y el teclado Pruebas automatizadas sin la GUI Pruebas de las clases y los módulos

Intentar obtener victorias tempranas.

Arrancar el proyecto desde un “esqueleto que camine” sobre el cual se van añadiendo las funcionalidades.

Pensar siempre en hacer una re-arquitectura incremental.

Radiadores de información

Exploración 360º

Formación de la metodología

Taller de reflexión

Estimaciones Delphi

Encuentros diarios de pie

Programación lado a lado

Patrocinador

Usuario Experto

Diseñador Principal

Diseñador Programador

Experto En Negocios

Coordinador

Verificador

Escritor