Xp

Slide 1: PrOgRaMaCiOn ExTrEmA Ana Benet Sonia Orozco

Slide 2: Algunas bases de la programación extrema En la programación extrema se da por supuesto que  es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que tiene que hacer ni hacer un diseño correcto al principio. Básicamente la idea de la programación extrema  consiste en trabajar estrechamente con el cliente, haciéndole mini-versiones con mucha frecuencia, y en cada una se debe hacer el mínimo de código y lo más simple posible para que funcione correctamente.

Slide 3: Que es XP XP (eXtreme Programing) nace como nueva  disciplina de desarrollo de software, Kent Beck, su autor, es un programador que ha trabajado en múltiples empresas y que actualmente lo hace como programador en la conocida empresa automovilística DaimlerChrysler. Con sus teorías ha conseguido el respaldo de gran  parte de la industria del software y el rechazo de otra parte. La programación extrema se basa en la  simplicidad, la comunicación y el reciclado, continuo de código, para algunos no es mas que aplicar una pura lógica.

Slide 4: Los cuatro valores. Una de las cosas que nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, etc. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios. Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y estos cuatro valores son: Comunicación  Sencillez  Retroalimentación  Valentía 

Slide 5: Comunicación. La mala comunicación no surge por  casualidad y hay circunstancias que conducen a la ruptura de la comunicación, como aquel jefe de proyecto que abronca al programador cuando éste lo comunica que hay un fallo en el diseño. XP ayuda mediante sus prácticas a  fomentar la comunicación.

Slide 6: Sencillez Siempre debemos hacernos esta pregunta ¿ Qué  es lo más simple que pueda funcionar ?. Lograr la sencillez no es fácil. Tenemos cierta tendencia a pensar en qué programaremos mañana, la próxima semana y el próximo mes. XP nos enseña a apostar, apuesta por hacer una  cosa sencilla hoy y pagar un poco mas para mañana, si es necesario, que hacer una cosa complicada hoy y no utilizarla después. La sencillez y la comunicación se  complementan, cuanto mas simple es tu Sistema menos tienes que comunicar de el.

Slide 7: Retroalimentación. Por medio de pruebas funcionales a nuestro software este nos mantendrá informado del grado de fiabilidad de nuestro sistema, esta información realmente no tiene precio. Los clientes y las personas que escriben pruebas tienen una retroalimentación real de su sistema. La retroalimentación actúa junto con la sencillez y la comunicación, cuanto mayor retroalimentación más fácil es la comunicación. Cuanto mas simple un sistema mas fácil de probar.

Slide 8: Valentía. Asumir retos, ser valientes antes los  problemas y afrontarlos. Nuestro trabajo se asimila al de un escalador cuando hacemos una cima tenemos que volver a bajar para hacer otra cima y así constantemente, planteándonos hacer sistemas cada vez mas sencillos y fiables. La valentía junto con la comunicación y la  sencillez se convierte en extremadamente valiosa.

Slide 9: Principios básicos  Proporcionar una retroalimentación rápida  Adoptar la sencillez  Cambiar progresivamente  Aceptar el cambio  Alentar el trabajo de calidad

Slide 10: Las cuatro actividades básicas Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. ¿ Qué tareas debemos de llevar a cabo para desarrollar un buen software ? Codificar 6. Hacer Pruebas 7. Escuchar 8. Diseñar 9.

Slide 11: Codificar Es la única actividad de la que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar.

Slide 12: Hacer pruebas Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegaras a conclusiones sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza. Programar y probar es mas rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración. Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro.

Slide 13: Escuchar Si los negociantes pudieran programarse su propio software ¿ para que querrían a un programador ? Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

Slide 14: Diseñar El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

Slide 15: Las cuatro variables XP define cuatro variables para proyectos de  software: Coste 2. Tiempo 3. Calidad 4. Ámbito. 5. Además de estas cuatro variables, Beck propone  que sólo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en función de las otras tres.

Slide 16: El coste del cambio. XP propone que si el sistema que empleas hace  que el coste del software aumente con el tiempo debes de actuar de forma diferente a cómo lo haces. XP propugna que esta curva ha perdido validez y  con una combinación de buenas practicas de programación y tecnología es posible lograr que la curva sea la contraria. La tecnología ha sido la clave para el software,  en sentido que ofrece mayor flexibilidad sin programar orientado al objeto sin aumentar el costo del cambio.

Slide 17: Practicas esenciales de XP Estas distinguen a XP de otros enfoques:  Liberación limitada  Semana de trabajo de 40 horas  Alojar la cliente en el sitio  Uso de programación en parejas.

Slide 18: Modelo Ágil Un modelo ágil es aquel modelo que es tan solo lo suficientemente bueno, lo cual implica que exhibe las siguientes características: 1. Satisface su propósito. 2. Es inteligible. 3. Es suficientemente preciso. 4. Es suficientemente consistente. 5. Es suficientemente detallado. 6. Aporta valor positivo. 7. Es lo más simple posible.

Slide 19: Los Valores de AM  Comunicación.  Coraje.  Retroalimentación.  Humildad.  Simplicidad. Además de los valores antes mencionados, la metodología de Modelado Ágil ha adoptado también los valores de la Alianza Ágil (AA) definidos en su manifiesto. Los valores de la AA: 1. Individuos e interacciones más que procesos y herramientas. 2. Software operante más que documentaciones completas. 3. Colaboración con el cliente más que negociaciones contractuales. 4. Respuesta al cambio más que apegarse a una rigurosa planificación. Es importante comprender que aún cuando se deben valorar los conceptos que se encuentran del lado derecho, debemos valorar aún más aquellos que están a la izquierda (presentados en itálicas). Una buena manera de interpretar el manifiesto, es asumir que éste define preferencias, no alternativas.

Slide 20: Principios centrales de AM Asumir simplicidad.  Bienvenido el cambio.  Permitir el siguiente esfuerzo es el objetivo  secundario. Cambio incremental.  Maximizar la inversión de las partes interesadas  en el proyecto. Modelar con un propósito.  Múltiples modelos.  Trabajo de calidad.  Rápida retroalimentación.  El software es el objetivo primario.  Viaje con poco equipaje. 

Slide 21: Modelo SCRUM Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en: propietario del producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y “otros interesados”. Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto, los que según la comparación siguiente (y sin connotaciones peyorativas) Propietario del producto: El responsable de obtener el mayor valor de producto para los clientes, usuarios y resto de implicados. Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto. Scrum Manager: gestor de los equipos que es responsable del funcionamiento de la metodología Scrum y de la productividad del equipo de desarrollo.

Slide 22: Valores Scrum es una “carrocería” para dar forma a los principios ágiles. Es una ayuda para organizar a las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil: Cristal, DSDM, etc. La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona. Delegación de atribuciones (empowerment) al equipo para  que pueda auto-organizarse y tomar las decisiones sobre el desarrollo. Respeto entre las personas. Los miembros del equipo  deben confiar entre ellos y respetar sus conocimientos y capacidades. Responsabilidad y auto-disciplina (no disciplina impuesta).  Trabajo centrado en el desarrollo de lo comprometido  Información, transparencia y visibilidad del desarrollo del  proyecto

Slide 23: ¿ Cuales son los principales problemas a la hora de desarrollar nuestro software ? Cambios de negocio: el Retrasos en la planificación:   problema que resolvía nuestro llegada la fecha de entregar el software éste no esta software ha cambiado y nuestro disponible. software no se ha adaptado. Sistemas deteriorados: el  Falsa riqueza: el software  software se ha creado pero hace muchas cosas después de un par de año el técnicamente muy interesantes coste de su mantenimiento es y divertidas, pero no resuelven tan complicado que el problema de nuestro cliente, definitivamente se abandona ni hace que éste gane mas su producción. dinero. Tasa de defectos: el software  se pone en producción pero los Cambios de personal:  defectos son tantos que nadie después de unos años de lo usa. trabajo los programadores comienzan a odiar el proyecto y lo abandonan.

Slide 24: Conclusiones La liberación limitada permite la  elaboración de los sistemas.  La programación en parejas incrementa la calidad global.  Los clientes en el sitio se benefician mutuamente.  La semana de trabajo de 40 horas mejora la eficacia.  Los recursos y actividades equilibrados dan soporte a los objetivos del proyecto.  Los valores de XP son importantes para su éxito.

Slide 25: GRACIAS  PoR sU aTenCioN!!