Metodologías Ágiles en la Práctica

Metodologías Ágiles en la Práctica Manuel A. Rubio Jiménez

¿Quién soy?
Programador desde hace 18 años
Basic, Modula-2, Pascal, C, C++, Ensamblador, Java, Perl, PHP, Python, Ruby, JavaScript, Erlang...
Desarrollador desde hace 5 años
Metodologías clásicas, Métrica-3, RUP, Scrum, Xtreme Programming, Kan-ban, Lean, DSDM...
Gerente de Desarrollo de Voz en Jet Multimedia España
Red Inteligente (900, 901, 902, 905, 806, ...), sistemas virtuales de telefonía y VoIP.
http://bosqueviejo.net

Desde el principio... La Crisis del Software

Desde el principio... La crisis del software La crisis del software se fundamentó en el tiempo de creación de software , ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad. Es un término informático acuñado en 1968 , en la primera conferencia organizada por la OTAN sobre desarrollo de software , de la cual nació formalmente la rama de la ingeniería de software . Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzos . – Wikipedia

Desde el principio... La crisis del software
Standish Group, resultados de 50.000 proyectos en 1994:
Proyectos fracasados: 84%
Proyectos exitosos: 16%
Después de 10 años, en 2004:
Proyectos fracasados: 71%
Proyectos exitosos: 29%

Las 10 principales causas del fracaso
Escasa participación de los usuarios.
Requisitos y especificaciones incompletas.
Cambios frecuentes en los requisitos y especificaciones.
Falta de soporte ejecutivo.
Incompetencia tecnológica.
Falta de recursos.
Expectativas no realistas.
Objetivos poco claros.
Cronogramas irreales.
Nuevas tecnologías.

¿Las soluciones?

¿Las soluciones?
Metodologías clásicas de Desarrollo del Software
Cascada, Prototipo Rápido, Prototipo Evolutivo, Espiral de Boehm...
Certificados de Calidad de Desarrollo del Software
CMMi, ITIL, Spice, ...
Normas para el Desarrollo de Software
Métrica-3, PRINCE2, ...

El camino a RUP
Usa Orientación a Objetos y UML para el diseño de aplicaciones.
Fue diseñado por Hartman, Boehm y Jacobson. Como un sistema de desarrollo, diseño y documentación de aplicaciones.
Es la metodología más empleada en el desarrollo de aplicaciones para terceros.
Se basa en el uso de herramientas específicas como clave de su éxito.

Asegurando la calidad
Se intenta dar calidad al proceso de creación del software por parte de las empresas.
Surgen normas específicas como:
CMMi en Estados Unidos
Metrica-3 en España
PRINCE2 en UK
ITIL, es el ISO 20000

Problemas de las soluciones

Funcionalidades / Requisitos De las funcionalidades desarrolladas: 7% se usan “siempre” 13% se usan “a menudo” 16% “a veces” 19% “pocas veces” 45% “ NUNCA ” Fuente: Standish Group

El cambio de enfoque

El Manifiesto Ágil Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción por encima de los procesos y las herramientas .
El software que funciona por encima de la documentación exhaustiva .
La colaboración con el cliente por encima de la negociación contractual .
La respuesta al cambio por encima del seguimiento de un plan .
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Los Personajes Kent Beck Xtreme Programming Mike Beedle Scrum Patrones de Diseño Arie van Bennekum DSDM Alistair Cockburn Crystal Methods Ward Cunningham Xtreme Programming Patrones y Antipatrones Martin Fowler Patrones de Diseño Xtreme Programming Jim Highsmith Adaptative Software Development Ron Jeffries Xtreme Programming Jeff Sutherland Scrum

Las metodologías
Gestión de Proyectos
Scrum (Takeuchi y Nonaka, 86)
Crystal Methods (Cockburn, 2004)
DSDM (DSDM Consistorium, 90)
Pragmatic Prog. (Hunt & Thomas, 99)
FDD (Jeff De Luca, 97)
Desarrollo de Software
Xtreme Programming (Beck, 96)
BDD (North, 2003)
DDD (Evans, 2004)

La riqueza oriental
Gestión de Proyectos
Scrum (Takeuchi y Nonaka, 86)
Lean (Poppendieck, 2000)
Kanban (Toyota, 1950s)
Mary Poppendieck Lean Software

Procesos

Scrum, Xtreme Programming y Kanban En la práctica...

Scrum Divide tu Organización voz movilidad especiales
Equipos pequeños.
Interdisciplinarios.
Auto-organizados.

Scrum Roles Marketing y Comercial Dueño del Producto Jefe de Proyecto Scrum Master Analistas / Programadores El resto del equipo El Equipo

Scrum Divide el Trabajo
Entregables pequeños y concretos.
Ordenamos la lista por prioridad.
Estimamos el esfuerzo relativo por elemento.

Scrum Divide el Tiempo
Iteraciones cortas (1 a 4 semanas).
Código potencialmente entregable, demostrado en cada iteración.
Optimiza el plan de entregas y actualiza las prioridades con el cliente.

Scrum El Tablero Visual

Scrum Ciclo de Desarrollo

Scrum La Pila de Producto Historia

Scrum La Pila de Sprint

Scrum Reunión Diaria
Una reunión breve a primera hora (15 ó 20 minutos)
Se hace un balance de intenciones de qué se va a hacer.
Si hay impedimentos, el jefe de proyecto debe ayudar a su eliminación.
Todos deben tener claras sus tareas para ese día.

Scrum Burndown

Scrum Demostración
Se realiza una demostración, para:
Cliente
Dueño de Producto
Otros Equipos
… toda la empresa.
En caso de que el desarrollo no sea funcional, se presentan datos de las mejoras o el valor que aporta el desarrollo.

Scrum Retrospectiva
La reunión puede durar hasta 4 horas (medio día).
Indica las cosas buenas , mejorables y algunas mejoras .
Se votan las mejoras propuestas con objeto de realizarlas en el siguiente sprint.

Xtreme Programming Prácticas

Xtreme Programming Programación por Parejas / Código colectivo
El navegante guía al piloto, piensa en los siguientes pasos.
El código no tiene dueño, es de todos, por lo que se deben de rotar las tareas cada día, o después de completar cada historia.

Xtreme Programming TDD / Refactorización
Las 3 reglas de Uncle Bob :
No escribir código de producción salvo para pasar una prueba fallida.
Escribir solo lo suficiente de una prueba para demostrar un fallo.
Escribir solo el suficiente código de producción para pasar la prueba.
Ciclo de TDD
ROJO : se escribe la prueba y falla (no hay código).
VERDE : se escribe el código para la prueba.
REFACTOR : limpia el código y las pruebas.

Kanban El Tablero Visual 看板

Kanban Equipos

Kanban

Beneficios
Da control sobre la marcha del proyecto.
Genera entregables que generan valor y minimizan el gasto en desarrollo de funcionalidades que no se usen.
Mejora la interacción entre departamentos.
Motiva a los equipos, les da protagonismo.

¿Preguntas?

Referencias
Scrum and XP from the Trenches , Henrik Kniberg.
Kanban and Scrum - making the most of both , Henrik Kniberg.
Flexibilidad con Scrum , Juan Palacio.
Extreme Programming Explained , Kent Beck.
Diseño Ágil con TDD , Carlos Blé.
Comunidades:

Agradecimientos
Universidad de Córdoba
Jet Multimedia, S.A.
Organizadores del evento de la Semana Cultural de Patrón de la Escuela Politécnica .
… y a vosotros, los asistentes del evento.

Metodologías Ágiles en la Práctica Manuel A. Rubio Jiménez

http://bosqueviejo.net	119
http://www.slideshare.net	19
http://webcache.googleusercontent.com	1
http://presentacion.org	1

Metodologías Ágiles en la Práctica

by Manuel Angel Rubio Jiménez on Mar 15, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 140

Statistics

Metodologías Ágiles en la Práctica — Presentation Transcript