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