Presentación metodologia agil Cystal Clear

1. Francisco Garat Luque

2. 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

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 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.

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
 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

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 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.

13. “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?

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 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.

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 cabo las pruebas sin estar presentes y
poder probar código indiscriminadamente nos
da una ganancia vital en el tiempo del
proyecto.

19. 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.

20. 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

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