Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Metodología XP

Presentación de la Metodología XP
by

Julián Ruiz

on 2 July 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Metodología XP

Introducción a XP
Porqué usar XP
Refactory
Encapsulamiento de subclases
con métodos de fábrica
Las sub clases implementan una interfaz común, pero estas son construidas de forma diferente.
Al hacer esto se ocultan los detalles de la implementación
•FabricaAbstracta: Define el interfaz a cumplir por cualquier fábrica
•Fabrica1 y Fabrica2: Son las clases concretas que fabrican los productos definidos en el interfaz
•ProductoAbstractoA y ProductoAbstractoB: Son los interfaces de los productos con independencia de las familias de los mismos
•ProductoA1, ProductoA2, ProductoB1 y ProductoB2: Son los productos finales creados por las fábricas concretas (Fabrica1 y Fabrica2)
•Cliente: Sin conocer las familias de productos (1 y 2) son capaces de interactuar con todos ellos (A y B)
Creación de clases
Al crear una clase debemos tener dentro de estas solos los métodos que están dentro de su responsabilidad, para métodos que van apareciendo y que tienen alguna relación debemos crear clases auxiliares
Remplacé cálculos condicionales con Strategy
El patrón estrategia permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo dinámicamente según sus necesidades. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varié independientemente de los clientes que lo usan
•IStrategy: declara una interfaz común para todas las variantes de un algoritmo.
•StrategyX: implementa una variante del algoritmo.
•StrategyClient: es el responsable de crear y mantener una referencia a una estrategia concreta.
Patrón Strategy
Patrón Factory
Creación de clases
Extraiga la lógica de los caso-uso hacia Decorators
El patrón decorator, añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender funcionalidad.
Esta nueva funcionalidad se va agregando por medio de nuevas clases y en la clase principal debemos conservar la esencia de la lógica
•Component: Define la interface de los objetos a los que se le puede adicionar responsabilidades dinámicamente
•ConcreteComponent: Define el objeto al que se le puede adicionar una responsabilidad
•Decorator: Mantiene una referencia al objeto Component y define una interface de acuerdo con la interface de Component
•ConcreteDecorator: Adiciona la responsabilidad al componente
Patrón Decorator
Remplace las notificaciones de código por observadores
Es común enviar notificaciones de código, para informar sobre algún cambio, para esto lo ideal es usar el patrón observador, este una dependencia de uno a muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos
•Subject: Conoce a sus observadores, Proporciona una Interfaz para que se suscriban los objetos Observer
•Observer: Define una interfaz para actualizar los objetos que deben ser notificados de cambios en el objeto Subject
•ConcreteSubject: Guarda el estado de interes para los objetos ConcreteObserver, Envia una notificacion a sus observadores cuando cambia su estado
•ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, Guarda el estado que deberia permanecer sincronizado con el objeto observado, Implementa la interfaz Observer para mantener su estado consistente con el objeto observado
Patrón observer
Transforme acumulaciones a un parámetro colectivo
Si tenemos un método que realiza varias operaciones sobre una variable y son operaciones se pueden dividir y agrupar, debemos crear submétodos para la actualización o transformación de las variables
En el primer método creamos una estructura xml en la variable result, esta la llenamos en 3 pasos, el primer paso es la asignación del tag de inicio, el segundo paso agregamos el contenido, y el ultimo paso agregamos un tag de cierre
Métodos compuestos
Para lograr entender la lógica de los procedimientos que creamos, estos se deben transformar en pequeños métodos con el mismo nivel de detalle. Un método compuesto es pequeño, simple y fácil de entender
En esta clase tenemos un único método en el que se realiza todo un proceso, es un método extenso y difícil de entender
Lo que se propone es dividir el proceso anterior para que se pueda manejar a través de 3 métodos, writeOpenTag, writeChildrenTo, writeEndTad, cada uno representa los pasos que se veían en el primera clase
Lo que se propone con métodos compuestos es dividir la lógica, en donde tengamos un mayor número de métodos, pero estos tengan un menor número de líneas, de esta forma la clase se leerá y entenderá de una forma más fácil.
Ajuste de interfaces
Cuando una clase implementa una interfaz y solo usa algunos métodos que esta implementa, se debe usar el patrón adapter para realizar la implementación de esta a través de una nueva interfaz que contenga en su contrato solo los métodos que la clase requiere
•Target: Define el dominio de la interfaz que el cliente usa
•Cliente: Colabora con los objetos conformando la interfaz Target
•Adaptee: Define la Interfaz existente que necesita adaptación
•Adapter: Adapta la Interfaz Adaptee para usar en Target
Patrón adapter
Mejor Calidad del software
Costos
Tiempo
Desarrollos fáciles de Entender
Desarrollos
fáciles de
Mantener
Test antes de Codificar y programación en parejas
XP en 4 minutos
XP Extreme Programming o en español como Programación Extrema y es una metodología de ligera para la elaboración o fabricación de software, la cual tiene como base los pilares o principios del manifiesto ágil bajo un modelo iterativo e incremental.
Desarrollar Software de Calidad
Desarrollar de la forma más rápida posible
Objetivos
Cliente feliz!
Lo planeado para
9 meses se entregó en 4!!!
Producto sin Bugs
Historia de XP
Pruebas
Test Before
Programming
Kent Beck padre de la metodología XP
¿Qué es el Test Before Programming?
¿Qué no es XP?
LOS 4 VALORES DE XP
Beneficios del Test Before Programming
El Mejor Momento Para Encontrar un Error en el Código
Artefactos
Historias de usuario
Pruebas de aceptación
Plan de entregas
Metáfora
Plan de iteración
Estándar de codificación
Pruebas unitarias
Producción de código
XP Build
Visión
Ejecutar Nuestro Conjunto de Pruebas
Cualidades de la Pruebas
XP vs Otros
"The miracle of Collaboration"
"The Art of Agile Development" - Oreilly
Situaciones Entre Código y Conjunto de Pruebas
Código Difícil de Probar
XP se fundamenta en 12 buenas prácticas que son:
12 Prácticas de XP
Por medio de las Historias de Usuario. Lo que no este especificado en el diseño no se implementa.
1. Planificación
Todas las iteraciones deben entregar un producto de valor al cliente.
2. Versiones Pequeñas
Todas los métodos, funciones, variables, relaciones deben nombrarse de forma coherente.
3. Sistema Metafórico
El desarrollo de software siempre se basa en diseño simples, estos diseños son aquellos que ejecutan correctamente todo el diseño de pruebas, el software es usable, funciona correctamente y muestra los resultados esperados, el código no es redundante y aprovecha al máximo las capacidades del hardware donde es desplegado.
4. Diseño Simple
En XP siempre se deben desarrollar los diseños de pruebas antes de programar.
5. Testeo Continuo
El refactoring menciona que el código debe ser simple y claro evitando duplicación de código lo que lo hace díficil de leer, interpretar y mantener
6. Refactoring
Siempre se debe programar en parejas al frente de un solo computador.
7. Pair Programming
El código es de todo el equipo de desarrollo.
8.Propiedad colectiva del código
Siempre se deben tener versiones simples y manejables del sistema, los cambios deben ser integrados continuamente y no acumularlos para realizarlos todos al mismo tiempo.
9.Integración Continua
Largas jornadas de trabajo producen estrés y cansancio en los programadores
10.Semana de 40 horas
El cliente debe entrar a hacer parte del equipo de trabajo del desarrollo del proyecto
11. Clientes en su sitio
Los estándares de codificación son aquellos que permiten entender de manera rápida, fácil y sencilla, el código empleado en el desarrollo de un software.
12. Estándares de Codificación
Roles
Cliente
Coach (Entrenador)
Desarrollador
Tester
XP Tracker
Manager
Escribe las historias de usuario
Escribe o especifica las pruebas de aceptación
Definen el valor del negocio
Podría ser el usuario final del sistema
Interviene directamente de ser necesario
Debe ser experto en XP
Es el responsable del proceso en su conjunto
Alta capacidad de liderazgo
Pieza fundamental en proyectos XP
Estimación de historias de usuario.
Capacidad de comunicación
Responsable de la integridad y el diseño del sistema.
Ayuda al cliente en la preparación de las pruebas funcionales.
Ejecuta las pruebas funcionales y publica los resultados.
Informa sobre la marcha de la iteración en curso
Controla la marcha de las pruebas funcionales
Informa sobre la marcha de la iteración en curso
Asegura que se alcanzan los objetivos
Confía en el equipo XP
Cubre las necesidades del equipo
Favorece la comunicación entre el cliente y el equipo
Comunicación en XP
Encadenación de los constructores
Pair programming
Satisfacción
Calidad
Revisiones contínuas
Solución de problemas difíciles
Aprendizaje
Trabajo en equipo
Beneficios
Define vista de las partes interesadas del producto a desarrollar, se especifica en términos de las necesidades fundamentales de las partes interesadas y características.
Se comunica al equipo el entendimiento general del proyecto y es un indicador
contra el cual todas las decisiones que deben ser validadas.
El cronograma de entregas establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma será el resultado de una reunión entre todos los actores del proyecto.
XP denomina a esta reunión “Juego de planeamiento” (“Planning game”), pero puede denominarse de la manera que sea más apropiada al tipo de empresa y cliente (Reunión de planeamiento, “Planning meeting” o “Planning workshop”.
Una “metáfora” es algo que todos entienden, sin necesidad de mayores explicaciones. La metodología XP sugiere utilizar este concepto como una manera sencilla de explicar el propósito del proyecto, y guiar la estructura y arquitectura
del mismo.
Es muy importante que el cliente y el grupo de desarrolladores estén de acuerdo y compartan esta “metáfora”, para que puedan dialogar en un “mismo idioma”.
Comunicación directa entre el cliente y desarrolladores
XP anima para que se de una comunicación extrema
El cliente hace parte del equipo de trabajo
Refactorización del código
•Cada historia de usuario se registra en papel
•Se cuelgan en las paredes del espacio de trabajo
•El equipo por medio de lluvia de ideas completan las tareas
•Los integrantes se inscriben en las tareas y estiman tiempos
•Facilitar la comunicación entre programadores

•Importancia al trabajar en parejas

•Al ver el código debe parecer que lo escribió la
misma persona
•Lista de historias de la iteración
•Cada historia se divide en tareas
•Las tareas deben ser tan pequeñas que sea muy fácil dar un alcance y estimación razonable
•Tareas máximo de 2 días por persona
Lista de historias de usuario y tareas que serán trabajadas en la iteración
Se usa para garantizar que una funcionalidad específica, trabaje correctamente
•Las pruebas se realizan a nivel de clase

•Para cada clase existe una clase de prueba

•Estas pruebas garantizan que el código funciona de acuerdo a lo que espera el programador

•Genera la confianza necesaria para que se pueda modificar y este siga funcionando
Pruebas unitarias
Es la especificación ejecutable del sistema
que se está construyendo
Producción de código
Documentación del código
•Las prácticas de diseño simple, programación en parejas, refactoring, la propiedad de código colectiva, el desarrollo basado en pruebas y el estándar de codificación, nos lleva a tener la pieza más importante, el código
•Mantenerse el código limpio y sencillo
Solo se desarrolla lo que se necesita
Es el resultado de la integración del
código y el proceso de
construcción
•Mostrar avances concretos de en un sistema en funcionamiento
•Cada “XP Build” incremental, muestra nuevas funciones y asegura que la funcionalidad anterior no se ha roto
•Producir un ejecutable de la aplicación para evaluar su progreso
XP Build
Describe las convenciones que se utilizan para trabajar con el lenguaje de programación
Ciclos muy cortos tras los cuales se muestran resultados.
Opinión del cliente en tiempo real
Implica saber tomar decisiones.
Repara un error cuando de detecta
Mejora el código siempre que este susceptible a mejoras
Full transcript