Metodologías ágiles

Tiempo de lectura: 5 minutos

Se inicia por la necesidad de organizar el trabajo, mejorar el desarrollo, desviaciones, satisfacción del cliente. Las metodologías ágiles se han demostrado más exitosas en ciertos tipos de proyectos de software.

En el enfoque clásico (Métrica, CMMi o RUP) la definición debe ser exhaustiva antes del inicio.

Fase 1: Declaración necesidades cliente
Fase 2: Especificación de los requisitos, escrito ya en lenguaje técnico.

Estructura Métrica:

Planificación
Estudio de viabilidad
Análisis
Desarrollo Diseño
Desarrollo Construcción
Desarrollo Implementación
Mantenimiento

Interfaces que dan soporte al proyecto:

Gestión de proyectos.
Seguridad.
Asesoramiento de la calidad
Gestión de la configuración.

Se caracteriza por:

Planificaciones largas y detalladas
Equipos de desarrollo especializados y jerarquizados
Documentación exhaustiva
Rigidez frente a los cambios de requisitos
Visión mecanicista de las personas que intervienen en el proyecto
Comunicación esporádica con el cliente
Los riesgos del enfoque clásico
- Retrasos en calendario y costes que superan ampliamente la previsión inicial
- Clientes insatisfechos

En enfoque ÁGIL

El manifiesto Ágil:

Valorar más a los individuos y su interacción que a los procesos y las herramientas
Valorar más el software que funciona que la documentación exhaustiva
Valorar más la colaboración con el cliente que la negociación contractual
Valorar más la respuesta al cambio que el seguimiento del plan

Diferencias:

Admisión de incertidumbres en requisitos.
Planificaciones cortas y solapadas, es decir, se planifica todo el proyecto con la información de la que se dispone en el momento y se va actualizando de forma iterativa según aumenta el conocimiento sobre el proyecto.
Metodologías simples.
Equipos multidisciplinares y auto-organizados.
1. Sin jerarquías, lideres no jefes.
2. Equipos autoorganizados se reparten el trabajo.
Poca documentación, el conocimiento está en las personas, doc más exhaustiva.
Flexibilidad: abiertas a los cambios, la evolución y el perfeccionamiento nunca acaba.
Comunicación continua con el usuario.
Las personas son seres emocionales, no son máquinas, y son más importantes que los procesos, y los procesos están al servicio de las personas.

Principales metodologías Ágiles, inscritas en Agile Alliance

AD, Agile Database Techniques
AM, Agile Modeling
ASD, Adaptative Software Development
AUP, Agile Unified Process
Crystal
FDD, Feature Driven Development
DSDM, Dynamic Systems Development Method
Lean Software Development
SCRUM
TDD, Test-Driven Design
Xbreed
XP, eXtreme Programming

Diferencias entre las metodologías clásicas y las ágiles:

Metodologías clásicas	Metodologías ágiles
Requisitos exhaustivos al inicio del proyecto	Admisión de incertidumbres en requisitos
Planificaciones largas y detalladas	Planificaciones cortas y solapadas
Procesos muy definidos y estructurados	Proceso simple
Equipos de desarrollo especializados y muy jerarquizados	Equipos multidisciplinares y auto-organizados
Documentación exhaustiva	Poca documentación
Rigidez frente a los cambios de requisitos	Abiertas al cambio de requisitos
Comunicación esporádica con el cliente	Comunicación continua con el cliente
Visión mecanicista de las personas que intervienen en el proyecto	Visión emocional de las personas que intervienen en el proyecto

SCRUM

Filosofía: de gestión de proyectos, en vez de grandes proyectos con equipos grandes, objetivos mas pequeños y tangibles con pequeños grupos de personas. Significa la Melé, del rugby. Se utiliza sobre todo en proyectos pequeños y medianos.
El Sprint: secuencia de ciclos cortos, como un miniproyecto. Dura de 2 a 6 semanas y conviene no cambiarlo durante el proyecto. En cada Sprint se produce:
- Reunión de planificación del Sprint
- Reunión de seguimiento diario
- Reunión de revisión del Sprint. Al final
- Reunión retrospectiva del sprint, opcional entre dos Sprint.
Pila de sprints: conjunto de funcionalidades que se van a acometer en el sprint. Historias de usuarios pendientes.
Pila del producto: todas las historias de usuario del proyecto.
Reunión de planificación del Sprint:
- Se realiza justo antes del sprint y se seleccionan las historias de usuario que se van a acometer en el sprint. La reunión puede durar 8 horas para sprints de 1 mes.
- ¿Qué historias de usuario se implementan?
  - El orden de prioridad de las historias de usuario las determina el dueño.
  - El tiempo de desarrollo es estimado por el equipo.
  - El equipo de desarrollo evalúa lo que puede realizar durante el sprint.
- ¿Cómo se conseguirá hacer el trabajo?
  - Se realiza un trabajo de diseño para repartir el trabajo. Analizar.
Reunión de seguimiento diario.
- 15 minutos, a la misma hora, se establece la jornada.
- Cada persona explica; avances, que hará hoy, obstáculos.
Reunión de revisión del sprint:
- Se realiza al final del sprint.
- Se hace una demo del sprint.
- El dueño del producto decide que historias están finalizadas y cuáles no.
- Entre todos se actualiza la pila del producto.
- Realizar la demo es muy positivo.
Reunión retrospectiva del Sprint:
- Se realiza después de la reunión de revisión del sprint. Su propósito es la mejora continua:
  - Inspeccionar como fue el último sprint en cuanto a personas, etc.
  - Identificar y ordenar los elementos que fueron bien.
  - Crear un plan para implementar mejoras acordadas.
Cancelación del Sprint:
- Puede cancelarse, solo el dueño puede hacerlo.
Descansos entre Sprints:
- No se puede estar continuamente sprintando… la gente acaba quemada, o es que, si no, realmente está haciendo footing. Además, el descanso sirve para:
  - Reflexionar y asimilar.
  - Que el dueño pueda probar el producto.

La gestión del producto en SCRUM:

Conceptos:
- La pila del producto
- La pila del Sprint y el incremento del Sprint. Incremento es la parte del producto producida en un Sprint.
- Meta del Sprint:

El equipo SCRUM.
- El SCRUM Máster.
- El dueño del producto: es el único responsable de gestionar la pila del producto.
- El equipo de desarrollo:
  - Es auto-organizado, nadie les dice lo que tienen que hacer.
  - Tiene que ser pequeño, entre 3 y 9.
Ventajas e inconvenientes:
- Ventajas: Es simple, fácil de asimilar…
- Inconvenientes: Difícil de aplicar en grandes proyectos, y con coste cerrado.

XP: eXtreme Programming o Programación Extrema

Definición: un conjunto de prácticas interrelacionadas, enfocadas a obtener una funcionalidad correcta. Está centrada en revisar el código de programación y minimiza las fases de análisis y diseño. Dos bloques:
- Relacionadas con el diseño y desarrollo.
- Relacionadas con planificación y organización del proyecto.
El modelo XP:
- Se compone de 4 variables: coste, tiempo, calidad y alcance.
- Tres la eligen agentes externos a los desarrolladores, y la cuarta, en base a los anterior, lo deciden los desarrolladores para ese contexto.
- Se realizan ciclos de desarrollo cortos, denominado iteraciones.
Fases del ciclo de vida de un proyecto XP:
- Fase de exploración: se define el alcance general. Dura 2 semanas.
- Fase de planificación: Fase corta, se acuerda orden de historias de usuario. Se establece el plan de entregas.
- Fase de iteraciones: fase principal, se desarrollan las funcionalidades y al final de cada iteración se genera entregable, historia de usuario finalizada. Al principio de iteración análisis, con el cliente.
- Fase de puesta en producción: se pone en producción cuando está la funcionalidad completa. Pueden ser necesario fine tuning.
Valores en XP:
- Comunicación
- Simplicidad
- Retroalimentación
- Coraje: si hay que cambiar cosas se cambian, no caer en desanimo.
Roles en XP:
- El cliente
- El jefe del proyecto: eq. Scrum máster.
- Los desarrolladores.
Las prácticas XP de diseño y desarrollo del producto
- Diferencia de otras met. Agiles, definición de buenas prácticas en el proyecto.
- Diseños simples
- Estándares de codificación: estilos consensuados, etc.
- Desarrollo dirigido por pruebas, TDD: escribir las pruebas antes de programar. Dos tipos:
  - Unitarias: JUnit, etc.
  - De aceptación: prueba de la historia de usuario.
- Integración continua: las nuevas funcionalidades se publican inmediatamente.
- Refactorización continua
- Metáforas: es la definición del producto, en historia.
Las prácticas XP de planificación y organización del proyecto.
- Versiones pequeñas: no superior a dos meses.
- Planificación continua.
  - Reunión inicial para definir un plan de entregas. El cliente agrupa y ordena las historias de usuario.
  - Reuniones diarias, como en scrum.
- Ritmo de trabajo sostenible.
- El cliente en su sitio: disponible.
- Programación por parejas: se hace así siempre. Se evitan errores, se aprende-enseña, etc. Es bueno cambiar de pareja.
Propiedad colectiva del código: todos puedes tocar lo de todos.
Ventajas de XP:
- Funcionalidad más centrada y satisfacción del cliente.
- Gestión de proyecto flexible.
- Calidad del producto y menos errores.
- Menos polémica con plazos, dado que se va consensuando.
- Equipos de trabajo motivados.
Desventajas:
- Más que una metodología, es un conjunto de prácticas.
- Las metáforas y la programación por pareja genera polémica.

Combinar SCRUM y XP

SCRUM para organización y XP para diseño y programación.

SCRUM
- Pilas de producto y pilas de Sprint.
- Reunión de planificación o lanzamiento del Sprint.
- Reuniones de seguimiento diario.
- Reunión de revisión del Sprint.
- Reunión de retrospectiva de sprint.
XP
- Diseños simples
- Estándares de codificación
- Desarrollo dirigido por pruebas
- Integración continua
- Refactorización continua.
- Programación por parejas.
- Propiedad colectiva del código
- Ritmo de trabajo sostenible.