s_10_dis_xp
DESCRIPTION
metodologia XPTRANSCRIPT
Diseño e Implementación de Sistemas
Extreme Programing
Sesión 10
Ing. Gener Zambrano M. Sc.
Historia
Introducción
¿Qué es XP?
XP – características
XP – valores
XP – principios
XP – roles
XP - artefactos
Ciclo de vida de un proyecto XP
XP - prácticas
XP - fases - aplicación de las prácticas
Índice del contenido:
XP – Historia.
La programación extrema o eXtreme Programming (XP) es un
enfoque de la ingeniería de software formulado por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999).
Todo en el software cambia. Los requisitos cambian.
1. El diseño cambia.
2. El negocio cambia.
3. La tecnología cambia.
4. El equipo cambia.
5. Los miembros del equipo cambian. El problema no es el
cambio en sí mismo, puesto que sabemos que el cambio va a
suceder; el problema es la incapacidad de adaptarnos a dicho
cambio cuando éste tiene lugar.
XP – Historia.
Es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de
trabajo. XP se basa en realimentación continua entre el cliente y el
equipo de desarrollo, comunicación fluida entre todos los
participantes, simplicidad en las soluciones implementadas y
coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos
y muy cambiantes, y donde existe un alto riesgo técnico.
¿Como soluciona XP problemas?
• Retrasos y desviaciones: versiones cortas.
• Cancelan el proyecto: entregas periódicas.
• Sistemas deteriorados y defectos: pruebas continuas.
• Requisitos mal comprendidos: cliente dentro del equipo.
• Cambios de negocio: versiones cortas.
• Falsa riqueza de características: realizar tareas prioritarias.
• Cambios de personal: anima el contacto y la integración.
¿Qué es XP?
“Un proceso ligero, de bajo riesgo, flexible, predecible, científico y divertido de desarrollar software”.
Basada en la simplicidad, la comunicación y el reciclado continuo de código.
Conjunto de practicas y reglas empleadas para desarrollar software
En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo.
Principios de actuación claves :
1. Acortar los ciclos de desarrollo
2. Involucrar al cliente desde el principio hasta el final de cada
ciclo.
Se centra en la satisfacción del cliente.
1. Diseñada para entregar el software, a quien lo necesita, en el
momento en el cual lo necesita.
2. Provee los mecanismos necesarios para hacer cambios en los
requerimientos del usuario (incluso bien avanzado el ciclo de
vida del software).
Enfatiza el trabajo en equipo. Gerentes, clientes y
desarrolladores, forman un gran equipo de trabajo, dedicado a
entregar un software de calidad.
XP – características:
XP – características:
XP no es un conjunto de reglas a seguir, sino una forma de trabajar en armonía con los valores personales y organizacionales, que tiene su punto de partida en cinco valores fundamentales que son: Comunicación, Simplicidad, Retroalimentación, Coraje y Respeto.
XP – valores:
La simplicidad consiste en desarrollar sólo el sistema que
realmente se necesita. Implica resolver en cada momento sólo
las necesidades actuales.
Desarrollaremos lo que sea solicitado y necesario.
un diseño y programación simple mejora la calidad de las comunicaciones, pues es más fácil de implementar y entender por todos en el equipo.
Simplicidad
XP – valores:
Una metodología basada en el desarrollo incremental de
pequeñas partes, con entregas y pruebas frecuentes y continuas,
proporciona un flujo de retro-información valioso para detectar
los problemas o desviaciones.
De esta forma los fallos se localizan muy pronto.
La planificación no puede evitar algunos errores, que sólo
se evidencian al desarrollar el sistema.
La retro-información es la herramienta que permite
reajustar la agenda y los planes.
Retroalimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo.
Feedback rápido y continuo
XP – valores:
El coraje implica saber tomar decisiones difíciles. Reparar un
error cuando se detecta. Mejorar el código siempre que tras el
feedback y las sucesivas iteraciones se manifieste susceptible
de mejora.
Tratar rápidamente con el cliente los desajustes de agendas para
decidir qué partes y cuándo se van a entregar.
Se requiere valor para comunicarse con los demás cuando eso
podría exponer la propia ignorancia. Se requiere valor para
mantener el sistema simple, dejando para mañana las decisiones
de mañana. Y, sin un sistema simple, comunicación constante y
retroalimentación, es difícil ser valeroso.
Coraje
XP – valores:
XP pone en comunicación directa y continua a clientes y
desarrolladores. El cliente se integra en el equipo para
establecer prioridades y resolver dudas. De esta forma ve el
avance día a día, y es posible ajustar la agenda y las
funcionalidades de forma consecuente.
Algunos problemas en los proyectos tienen su origen en que
alguien no dijo algo a alguien más sobre algo importante en
algún momento. XP hace casi imposible la falta de
comunicación.
Comunicación
XP – valores:
El valor de respeto incluye el respeto por los demás , así como el
respeto propio.
Los miembros respetan su propio trabajo por siempre luchando
por la alta calidad y la búsqueda para el mejor diseño para la
solución a la mano a través de la refactorización .
Por ejemplo, los desarrolladores nunca deben subir cambios que
impidan la compilación de la versión, que hagan fallar pruebas
unitarias ya realizadas o que de alguna otra forma retrasen el
trabajo de sus pares, esto significa tener respeto por el trabajo (y el
tiempo) de los demás.
Respeto
XP – valores:
XP no es un modelo de procesos ni un marco de trabajo, sino
un conjunto de 12 prácticas que se complementan unas a otras y
deben implementarse en un entorno de desarrollo cuya cultura
se base en los cuatro valores citados
1. Simplicidad de código y de diseño para producir software
fácil de modificar.
2. Reingeniería continua para lograr que el código tenga un
diseño óptimo.
3. Desarrollar estándares de codificación, para comunicar ideas
con claridad a través del código.
4. Desarrollar un vocabulario común, para comunicar las ideas
sobre el código con claridad.
Prácticas de codificación:
Principios de XP:
5. Adoptar un método de desarrollo basado en las pruebas para
asegurar que el código se comporta según lo esperado.
6. Programación por parejas, para incrementar el conocimiento,
la experiencia y las ideas.
7. Asumir la propiedad colectiva del código, para que todo el
equipo sea responsable de él.
8. Integración continua, para reducir el impacto de la
incorporación de nuevas funcionalidades.
Prácticas de desarrollo:
Principios de XP:
9. Integración de un representante del cliente en el equipo, para
encauzar las cuestiones de negocio del sistema de forma
directa, sin retrasos o pérdidas por intermediación.
10. Adoptar el juego de la planificación para centrar en la
agenda el trabajo más importante.
11. Entregas regulares y frecuentes para satisfacer la inversión
del cliente.
12. Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.
Prácticas de negocio:
Principios de XP:
Los roles presentes en esta metodología son los siguientes:
XP - roles:
XP – ciclo de vida de un proyecto XP.
Autor: Kent Beck
Extreme Programming – Proceso y Fases
XP – ciclo de vida de un proyecto XP.
1. Exploración
En esta fase, los clientes plantean a grandes rasgos las historias
de usuario que son de interés para la primera entrega del
producto. Al mismo tiempo el equipo de desarrollo se familiariza
con las herramientas, tecnologías y prácticas que se utilizarán en
el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la
arquitectura del sistema construyendo un prototipo. La fase de
exploración toma de pocas semanas a pocos meses, dependiendo
del tamaño y familiaridad que tengan los programadores con la
tecnología.
XP – ciclo de vida de un proyecto XP.
2. Planificación de la Entrega (Release).
En esta fase el cliente establece la prioridad de cada historia de
usuario, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el
contenido de la primera entrega y se determina un cronograma en
conjunto con el cliente.
Una entrega debería obtenerse en no más de tres semanas. Esta
fase dura unos pocos días. Las estimaciones de esfuerzo asociado
a la implementación de las historias la establecen los
programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programación. Las historias
generalmente valen de 1 a 3 puntos.
XP – ciclo de vida de un proyecto XP.
2. Planificación de la Entrega (Release).
Por otra parte, el equipo de desarrollo mantiene un registro
de la “velocidad” de desarrollo, establecida en puntos por
iteración, basándose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas
en la última iteración.
La planificación se puede realizar basándose en el tiempo o el
alcance. La velocidad del proyecto es utilizada para establecer
cuántas historias se pueden implementar antes de una fecha
determinada o cuánto tiempo tomará implementar un conjunto de
historias. necesarias para su implementación.
XP – ciclo de vida de un proyecto XP.
3. Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser
entregado. El Plan de entrega está compuesto por iteraciones de
no más de tres semanas. En la primera iteración se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creación de esta arquitectura, sin
embargo, esto no siempre es posible ya que es el cliente quien
decide qué historias se implementarán en cada iteración (para
maximizar el valor de negocio).
XP – ciclo de vida de un proyecto XP.
3. Iteraciones
Al final de la última iteración el sistema estará listo para entrar en
producción. Los elementos que deben tomarse en cuenta durante
la elaboración del Plan de la Iteración son: historias de usuario no
abordadas, velocidad del proyecto, pruebas de aceptación no
superadas en la iteración anterior y tareas no terminadas en la
iteración anterior. Todo el trabajo de la iteración es expresado en
tareas de programación, cada una de ellas es asignada a un
programador como responsable, pero llevadas a cabo por parejas
de programadores.
XP – ciclo de vida de un proyecto XP.
4. Producción
La fase de producción requiere de pruebas adicionales y
revisiones de rendimiento antes de que el sistema sea trasladado
al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusión de nuevas características a la
versión actual, debido a cambios durante esta fase. Es posible que
se rebaje el tiempo que toma cada iteración, de tres a una semana.
Las ideas que han sido propuestas y las sugerencias son
documentadas para su posterior implementación (por ejemplo,
durante la fase de mantenimiento).
XP – ciclo de vida de un proyecto XP.
5. Mantenimiento
Mientras la primera versión se encuentra en producción, el
proyecto XP debe mantener el sistema en funcionamiento al
mismo tiempo que desarrolla nuevas iteraciones. Para realizar
esto se requiere de tareas de soporte para el cliente. De esta
forma, la velocidad de desarrollo puede bajar después de la
puesta del sistema en producción. La fase de mantenimiento
puede requerir nuevo personal dentro del equipo y cambios en su
estructura.
XP – ciclo de vida de un proyecto XP.
6. Muerte del Proyecto.
Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del
cliente en otros aspectos como rendimiento y confiabilidad del
sistema.
Se genera la documentación final del sistema y no se realizan más
cambios en la arquitectura. La muerte del proyecto también
ocurre cuando el sistema no genera los beneficios esperados por
el cliente o cuando no hay presupuesto para mantenerlo.
XP – Fases (prácticas):
1. Planeación:
Se escucha los requerimientos, las necesidades de los usuarios,
esta actividad conlleva a la creación de historias de usuario, las
cuales describen la salida necesaria, características y
funcionalidades del software a elaborar, cada historia es colocada
en una tarjeta indizada, así el cliente asigna un valor o prioridad a
determinada historia, tomando como referencia el valor, que la
actividad descrita en la tarjeta, representa para el negocio.
Posteriormente el equipo de trabajo evalúa cada historia y se le
asigna un costo medido en semanas de desarrollo, en el caso que
este sea superior a tres semanas, se solicita al usuario que
descomponga la historia original en otras mas pequeñas y que
puedan ser abarcadas en dicho tiempo.
XP – Fases (prácticas):
1. Planeación:
Una vez llegado a un compromiso sobre las entregas, las historias
son ordenadas según su desarrollo de la siguiente manera:
• Todas las historias se implementarán de inmediato.
• Las historias con más valor y más riesgosas entrarán en la
programación de actividades y se implementarán en primer
lugar.
• Una vez realizada la primera entrega de software (o
incremento), se calcula la velocidad del proyecto, el cual es el
número de historias implementadas para dicha entrega.
XP – Fases (prácticas):
1. Planeación:
• El valor obtenido permite: Facilitar la estimación de las fechas
de entrega y programar actividades para entregas posteriores,
determinar el grado de compromiso para todas las historias
durante el desarrollo del proyecto, ajustando la velocidad de
las entregas.
A medida que se ejecuta el proyecto, el cliente puede agregar mas
historias, cambiar el valor de una ya existente, descomponerla o
eliminarlas, así el equipo de desarrolladores modifica sus planes
y reconsidera las entregas faltantes.
XP – Fases (prácticas):
1. Planeación:
Para el negocio:
Ámbito ¿Qué debe resolver el software?
Prioridad ¿Qué debe ser echo en primer lugar?
Composición de versiones ¿Cuánto es necesario hacer para
aportar valor?
Fechas de versiones ¿Fechas para presencia del software?
XP – Fases (prácticas):
1. Planeación:
Para el desarrollador:
Estimaciones ¿Cuánto lleva implementar una característica?
Consecuencias, informar sobre consecuencias de las
decisiones que adopta el negocio.
Procesos ¿Cómo se organiza el trabajo en el equipo?
Programación detallada: En una versión ¿Qué se resolverá
primero?
XP – Fases (prácticas):
2. Diseño:
Se le da preferencia a la sencillez sobre representaciones más
complejas, así el diseño guía la implementación de una historia
mientras se escribe, se inhibe de agregar funcionalidad adicional,
ya que dicha funcionalidad será agregada después.
Se utilizan las tarjetas CRC (Clase, Responsabilidad,
Colaborador), para identificar y organizar las clases orientadas a
objetos.
XP – Fases (prácticas):
2. Diseño:
En aquellos casos donde se encuentre un problema de diseño
difícil, se recomienda la creación de un prototipo operativo para
esa porción de diseño, implementando y evaluando el prototipo
de diseño, así cuando se implemente la implementación
verdadera, se disminuyen los riesgos.
La programación extrema estimula el rediseño, así el
comportamiento externo del código queda inalterable, pese a las
mejoras realizadas en su estructura interna, al modificar y
simplificar el diseño interno, esto sólo se puede alcanzar gracias a
las ventajas que ofrece la encapsulación y el polimorfismo de la
programación orientada a objetos.
XP – Fases (prácticas):
3. Codificación:
El primer paso de la codificación, no es escribir el código mismo
del desarrollo, al contrario, se elaboran las pruebas unitarias de
cada una de las entregas relacionadas con las historias, de esta
manera el desarrollador centrará sus esfuerzos de programación
en pasar las pruebas previamente elaboradas, es decir, las pruebas
actúan como guías de acción para el programador.
El código se debe integrar como mínimo una vez al día, y realizar
las pruebas sobre la totalidad del sistema.
XP – Fases (prácticas):
4. Pruebas:
Las pruebas unitarias, elaboradas como primer paso en la etapa
de la codificación, se implementan con una estructura que
permita su automatización, para que así puedan implementarse
repetidas veces y con facilidad. Dichas pruebas pueden ejecutarse
a diario con el objeto de corregir cualquier desviación o anomalía
del software a tiempo.
También se acostumbra a ejecutar pruebas de aceptación por
parte del cliente, estas pruebas se centran en las características y
funcionalidades generales del sistema y que son visibles y
auditables por parte del cliente.
XP – Fases (prácticas):
• Las historias de usuario son un conjunto de fichas escritas por el cliente con la ayuda de los desarrolladores para indicar las funciones que debe realizar el sistema, constituyendo el mecanismo base de captura de requerimientos de la programación extrema.
• Cada historia de usuario incluye una breve descripción, entorno a lo que el sistema debe de hacer, es importante procurar no incluir sintaxis técnica, de modo que se centren en las necesidades y no en la especificación del aspecto de las interfaces de usuario ni en la implementación, como base de datos.
• Los clientes ayudan a asegurar que la mayoría de las funcionalidades deseadas para el sistema estén cubierta con las historias.
Historias de usuarios (relatos)
XP – prácticas de la planificación
10/5/2015
Número: 001 Nombre Historia de Usuario: Gestionar Citas
Usuario: Paciente
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)
Descripción:
Los pacientes podrán (previa autenticación) gestionar sus citas, es decir, podrán generar, modificar o anular
sus citas. Para generar una cita el paciente deberá realizar una búsqueda seleccionando la especialidad o
ingresando el nombre del médico, el sistema mostrará las especialidades, médicos, fechas y horas
disponibles de acuerdo a la búsqueda realizada. El paciente deberá seleccionar la fecha y hora para generar
su cita, la cual se guardará en un registro. Además, en la opción Gestionar Citas el sistema mostrará una lista
de las citas pendientes, esto permitirá al paciente modificar o anular una cita; para ello el paciente
seleccionará la cita que desea modificar y podrá cambiar la fecha, hora y/o médico de acuerdo a la
disponibilidad (para ello previamente se debe realizar una búsqueda por médicos), si desea anular la cita
seleccionará la opción Anular Cita.
Observaciones:
El paciente sólo podrá modificar fecha, hora y/o médico.
El sistema permitirá anular la cita sólo si se realiza con un plazo máximo de dos horas de anticipación a la
cita.
Tarjetas de ingeniería
Tarea de Ingeniería
Número Tarea: Historia de Usuario (Nro. y Nombre):
Nombre Tarea:
Tipo de Tarea :
Desarrollo / Corrección / Mejora / Otra
(especificar)
Puntos Estimados:
Fecha Inicio: Fecha Fin:
Programador Responsable:
Descripción:
XP – prácticas de la planificación
• Una metáfora es una historia que todo el mundo puede
contar a cerca de cómo funciona el sistema.
• Hay que buscar unas frases o nombres que definan cómo
funcionan las distintas partes del programa, de forma que
sólo con los nombres se pueda uno hacer una idea de qué es
lo que hace cada parte del programa. Un ejemplo
“Programa de gestión de compras, ventas, con gestión de
cartera y almacén”.
• Las metáforas ayudan a cualquier persona a entender el
objeto del programa.
XP – prácticas del diseño:
Tarjetas CRC:
• Las Tarjetas CRC (Class, Responsibilities and Colaboration)
sirven para diseñar el sistema en conjunto entre todo el equipo
• Una clase es cualquier persona, cosa, evento, concepto, pantalla
o reporte. Las responsabilidades de una clase son las cosas que
conoce y las que realizan, sus atributos y métodos. Los
colaboradores de una clase son las demás clases con las que
trabaja en conjunto para llevar a cabo sus responsabilidades.
XP – prácticas del diseño:
Tarjetas CRC:
Las principales actividades de las tarjetas CRC son:
• Identificación de clases y asociaciones que participan del
diseño del sistema.
• Obtención de las responsabilidades que debe cumplir cada
clase.
• Establecimiento de cómo una clase colabora con otras clases
para cumplir con sus responsabilidades.
• La técnica CRC propone una forma de trabajo,
preferentemente grupal, para encontrar los objetos del
dominio de la aplicación, sus responsabilidades y cómo
colaboran con otros para realizar tareas.
XP – prácticas del diseño:
Tarjetas CRC:
XP – prácticas del diseño:
• Diseño simple:
1. Implementar la solución más simple que pueda funcionar
2. La complejidad innecesaria y el código extra debe ser
removido inmediatamente
3. No agregar nuevas funcionalidades antes de que sean
agendadas, primero centrarnos en lo principal
4. Tiene el menor número de clases y métodos
Se remueve la redundancia, se eliminan las funcionalidades no
necesarias y se rejuvenecen los diseños obsoletos.
XP – prácticas del diseño:
Refactorización (recodificación):
• Es una actividad constante de reestructuración del código con
el objetivo de remover duplicación de código, mejorar su
legibilidad, simplificarlo y hacerlo más flexible para facilitar
los posteriores cambios.
• consiste en hacer el programa mas simple sin perder
funcionalidad.
• No debemos de recodificar ante especulaciones si no solo
cuándo el sistema te lo pidaMejora la estructura interna del
código sin alterar su comportamiento externo
• Nos ahorra tiempo e incrementa la calidad
XP – prácticas del desarrollo:
• Disponibilidad del cliente:
– Un cliente real debe sentarse con el equipo de
programadores, estar disponible para responder a sus
preguntas, resolver discusiones y fijar las prioridades.
– La comunicación oral es más efectiva que la escrita, ya
que esta última toma mucho tiempo en generarse y puede
tener más riesgo de ser mal interpretada.
– Las historias de usuario son escritas por los clientes con la
ayuda de los desarrolladores
XP – prácticas del desarrollo:
Estándares de programación:
Se debe establecer un estándar de codificación aceptado e implantado por
todo el equipo.
Pruebas unitarias: Los programadores continuamente escriben pruebas
unitarias, que deben correr sin defectos para poder continuar desarrollando.
Pruebas funcionales: Los clientes escriben pruebas para demostrar que los
requerimientos se han completado
Crear y mantener un conjunto de pruebas que son ejecutadas, luego de cada
cambio para asegurar la calidad de la línea base.
No debe existir ninguna característica en el programa que no haya sido
probada.
XP – prácticas del desarrollo:
La programación en parejas.
Todo el código de producción se escribe con dos personas mirando
a una máquina, con un solo teclado y un solo ratón.
Cada miembro de la pareja juega su papel: uno codifica en el
ordenador y piensa la mejor manera de hacerlo, el otro piensa mas
estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde
no funcione?, ¿Hay forma de simplificar el sistema global para
que el problema desaparezca?. De esta forma se consigue un
código y diseño con gran calidad.
XP – prácticas del desarrollo:
Propiedad colectiva del código:
• Cualquier programador puede cambiar cualquier parte del
código en cualquier momento.
• Motiva a todos a contribuir con nuevas ideas en todos los
segmentos del sistema,
• Evita que algún programador sea imprescindible para realizar
cambios en alguna porción de código
40 horas por semana:
• Se debe trabajar un máximo de 40 horas por semana
• No se trabajan horas extras en dos semanas seguidas
• El trabajo extra desmotiva al equipo
XP – prácticas del desarrollo:
Realizar pruebas:
Toda característica en el programa debe ser probada, los
programadores escriben pruebas para chequear el correcto
funcionamiento del programa, los clientes realizan pruebas
funcionales. El resultado un programa mas seguro que soporte
cambios en el tiempo.
XP – prácticas de las pruebas:
Las pruebas de aceptación
XP – prácticas de las pruebas:
Ciclo de entregas:
http://www.extremeprogramming.org/
http://xprogramming.com/index.php
Enlaces:
SCRUM, Ken Schwaber & Jeff Sutherland, www.scrumguides.org
Extreme Programming, Kent Beck www.extremeprogramming.org
DSDM (Dynamic Systems Development Method), www.dsdm.org
Lean Programming, Mary Poppendieck, www.poppendieck.com
FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, http://www.agilemodeling.com/essays/fdd.htm
Adaptative Software Development, Jim Highsmith www.adaptivesd.com
Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
Principales metodologías ágiles:
Diseño e Implementación de Sistemas
Extreme Programing
Fin de la sesión 10
Ing. Gener Zambrano M. Sc.