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
Top Related