Programacin Extrema

Ing. Sebastian Priolo

Metodologas giles
Menos orientadas a los documentos. Orientadas al cdigo. El cambio es bienvenido. Procesos que cambian NO son predictivos Son adaptables

Ejemplos
Programacin Extrema Scrum Crystal Evolutionary Project Management (Evo) Feature Driven Development (FDD) Adaptive Software Development (ASD) Lean Development (LD) Lean Software Development (LSD)

Manifiesto gil

Manifiesto gil
En marzo de 2001, 17 crticos de los modelos de mejora basados en procesos, convocados por Kent Beck, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. Se acu el trmino Mtodos giles.
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Manifiesto gil
Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs de esta experiencia hemos aprendido a valorar:

Manifiesto gil
Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin de contratos Responder ante el cambio sobre seguimiento de un plan

Manifiesto gil
Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que estn a la izquierda.

Individuos e interacciones sobre procesos y herramientas

Conocimiento Adaptar procesos a las personas Creatividad e innovacin

Software que funciona sobre documentacin exhaustiva

Ver y actuar sobre prototipos Feedback Generar ideas Nuevas posibilidades Documentos < Comunicacin Documentos = Barricadas

Colaboracin con el cliente sobre negociacin de contratos

el cliente es un miembro ms del equipo se integra y colabora grupo de trabajo. Los modelos de contrato por obra no encajan

Responder ante el cambio sobre seguimiento de un plan

Entornos inestables factor inherente el cambio y la evolucin ms valiosa la capacidad de respuesta

Valores de gestin gil

Anticipacin y la adaptacin gestin de proyectos ortodoxa: planificacin y control para evitar desviaciones sobre el plan.

Principios giles

Conclusiones
En software la construccin es tan barata que es casi gratis. En software todo el esfuerzo est en el diseo, de modo que requiere de personas creativas y talentosas. Los procesos creativos no se planean fcilmente, de modo que la previsibilidad bien puede ser una meta imposible. Debemos ser muy cautos al usar la metfora de la ingeniera tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.

Programacin Extrema
Kent Beck, 1999. Conjunto de valores, practicas y actividades. Presenta distintos escenarios

Un da en un desarrollo XP
Requerimiento de Usuario

Desarrollar Las Pruebas

Disear

Implementar

Correr las Pruebas

Integrar

Buscar un par

Valores XP
Comunicacin: Crear software requiere de sistemas comunicados. Simplicidad: Empezar con lo necesario y requerido y trabajar desde ah. Retroalimentacion: Del sistema, del cliente, y del equipo. Valentia: Programa para hoy y no para maana. Respeto: El equipo debe trabajar como uno, sin hacer desiciones repentinas

Practicas XP
Conjunto de practicas:
Retroalimentacin a escala fina Proceso contnuo en lugar de por lotes Entendimiento compartido Bienestar del programador

Retroalimentacin a escala fina

Desarrollo Guiado por Pruebas Juego de planificacin Cliente presente Programacin en pares

Proceso contnuo en lugar de por lotes

Integracin continua Refactorar sin piedad Liberacin pequea

Entendimiento compartido
Diseo simple Metfora del sistema Propiedad colectiva del cdigo Convenciones del cdigo

Bienestar del programador

Paso sostenible

Actividades Bsicas
Codificar Hacer pruebas Escuchar Disear

Artefactos XP
Historias del Usuario Tareas de Ingeniera Pruebas de Aceptacin Pruebas Unitarias y de Integracin Plan de la Entrega Cdigo

Historia de Usuario
Historia de Usuario
Nmero: 1 Nombre: Enviar artculo Usuario: Autor Modificacin de Historia Iteracin Asignada: 2 Nmero: Prioridad en Negocio: Alta Puntos Estimados: (Alta / Media / Baja) Riesgo en Desarrollo: Puntos Reales: (Alto / Medio / Bajo) Descripcin: Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artculo. Observaciones:

Tarea de Ingeniera
Tarea
Nmero tarea: Nombre tarea: Tipo de tarea : Desarrollo / Correccin / Mejora / Otra Fecha inicio: Programador responsable: Descripcin: Nmero historia:

Puntos estimados:

Fecha fin:

Prueba de Aceptacin
Caso de Prueba
Nmero Caso de Prueba: Nombre Caso de Prueba: Descripcin: Nmero Historia de Usuario:

Condiciones de ejecucin:

Entradas:

Resultado esperado: Evaluacin:

Relacin entre practicas

Escenarios en XP

Escenarios en XP : Exploracin
Historias de Usuario
Prioridad Riesgo Esfuerzo (puntos)

Definir Historias de Usuario

Elaborar Spikes

Spikes (Bosquejos)

Planificacin de la Entrega
Velocidad de Proyecto (VP) puntos/semana Historias de Usuario Primera Iteracin Segunda Iteracin N-sima Iteracin ltima Iteracin

2a3 semanas Entrega <= 3 meses

Comenzar Iteracin

Historias de la Iteracin

Definir y ordenar Tareas de Ingeniera

Tareas de la iteracin

Programacin

Historias de la Iteracin Tareas de Historias de la iteracin Programacin Diseo en Parejas

Refactoring Programacin Pruebas Unitarias Integracin Pruebas de Integracin Pruebas de Aceptacin

Pruebas de Aceptacin de Historias de la iteracin

Versin del Producto

Pruebas de Aceptacin

Definir Pruebas de Aceptacin

Pruebas de Aceptacin

Corregir errores Definir nuevas Historias Aplicar Pruebas de Aceptacin

Entorno y clima de trabajo

Herramientas

Herramientas
Xplanner Fitnesse MediaWiki Cruise Control Mantis

Resumen y conclusiones

Comparando
Metodologa gil
Pocos Artefactos. El modelado es prescindible, modelos desechables. Pocos Roles, ms genricos y flexibles No existe un contrato tradicional, debe ser bastante flexible Cliente es parte del equipo de desarrollo (adems in-situ) Orientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitio La arquitectura se va definiendo y mejorando a lo largo del proyecto nfasis en los aspectos humanos: el individuo y el trabajo en equipo Basadas en heursticas provenientes de prcticas de produccin de cdigo Se esperan cambios durante el proyecto

Metodologa Tradicional
Ms Artefactos. El modelado es esencial, mantenimiento de modelos Ms Roles, ms especficos Existe un contrato prefijado El cliente interacta con el equipo de desarrollo mediante reuniones Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos Se promueve que la arquitectura se defina tempranamente en el proyecto nfasis en la definicin del proceso: roles, actividades y artefactos Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Se espera que no ocurran cambios de gran impacto durante el proyecto

Cundo utilizar una Metodologa gil?

Tienes ya un proceso? No o existe pero no reacciona bien a los cambios o existe pero el equipo no est contento con l Una Metodologa gil puede ser una buena forma de empezar No involucra gran inversin A los programadores les (suele) gustar A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto

FIN