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

Crystal Clear

  • 1.
  • 2.
    Surgen como alternativaa 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
  • 3.
    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
  • 4.
    Un cambio bastanteimportante 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.
  • 5.
    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
  • 6.
    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.
  • 8.
    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).
  • 9.
    Propiedades más importantes  Entrega frecuente  Comunicación íntima  Mejora reflexiva
  • 10.
    Otras propiedades  Seguridadpersonal (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
  • 11.
    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.
  • 12.
    El objetivo esque 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.
  • 13.
    “Parar de vezen 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?
  • 14.
    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
  • 15.
    Cada miembro debetener 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.
  • 16.
    Proporciona:  Un espacio donde poder realizar las entregas frecuentes  Un mejor detalle en los requisitos  Más fluidez en el cambio
  • 17.
    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
  • 18.
    Llevar a cabolas pruebas sin estar presentes y poder probar código indiscriminadamente nos da una ganancia vital en el tiempo del proyecto.
  • 19.
    Permite a losdesarrolladores 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.
  • 20.
    El sistema seintegra 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
  • 21.
    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.
  • 22.
    Radiadores de información  Exploración 360º
  • 23.
    Formación de la metodología  Taller de reflexión  Estimaciones Delphi  Encuentros diarios de pie  Programación lado a lado
  • 24.
    Patrocinador  Usuario Experto  Diseñador Principal  Diseñador Programador  Experto En Negocios  Coordinador  Verificador  Escritor