Metodologías

Agiles
XP y Kanban

Natalia Umaña Nicolás Diaz

Óscar Sánchez Arauth Bonilla
 XP
(Extreme programming)
 ¿Qué es Xp?

La Programación Extrema o XP (Extreme

Programming) es una metodología ágil que
I. Introducción surgió a finales de los años 90.

Permite la creación de sistemas de alta calidad a

través de una estrecha interacción con el cliente,
pruebas continuas y ciclos de desarrollo cortos.

Se enfoca en la mejora de la calidad del software

y la capacidad de respuesta a los cambios en los
requisitos del cliente
 ¿Dónde se recomienda implementar?

En proyectos medianos y en los que las

especificaciones no se puedan obtener hasta
I. Introducción luego de comenzado el proyecto.

En equipos pequeños de desarrollo que no

superen a 20 integrantes.

Proyectos en los que el cliente pueda involucrarse

en el desarrollo de estos desde el inicio hasta el
final, ya que es indispensable que conozca y
apruebe la metodología
 Prácticas esenciales en XP

Entregas limitadas o pequeñas: Implica entregar módulos parciales, probados, estables

y completos para mantener al cliente satisfecho.

Semana de trabajo de 40 horas: Los equipos de XP trabajan intensamente durante una

semana estándar de 40 horas, sin horas extras, para maximizar la productividad y la
energía del equipo.
 Prácticas esenciales en XP

Cliente en el sitio: El cliente participa activamente en el equipo y está presente durante

todo el proceso de desarrollo para asegurar una comunicación fluida y una comprensión
clara de los requisitos.

Programación en Pareja: Aumenta la calidad del código, ahorra tiempo, fomenta la

creatividad y reduce el código fuente al emparejar a los programadores para trabajar
juntos en la misma tarea.
II. Principios y valores de XP
Comunicación
Entendimiento de los requerimientos del cliente
para el producto final, teniendo en cuenta, las
posibilidades, la estructura y los objetivos del
sistema,

Conversaciones cara a cara y directas con sus

stakeholders.

Simplicidad
Evita el derroche.​
Disminuye los costos.​
Mantener el diseño y las funcionalidades que sean
fáciles de usar.​
Priorizar, en lo absoluto, lo que sea necesario para
el Proyecto.
II. Principios y valores de XP
Feedback
Es la socialización y comentarios finales acerca del
proyecto, con el fin, de garantizar los ajustes
rápidos y necesarios.

Coraje
Adaptarse al cambio, al fracaso, aceptar los
feedbacks que realizan los clientes, plantear
sugerencias y tomar las decisiones respectivas
durante el proceso.

Respeto
El trabajo de equipo es muy fundamental para
esta metodología, ya que se colaboren entre sí, se
acepten las diferencias, se colaboren y que tengan
una buena relación
 III. Características

Desarrollo iterativo e incremental: Refactorización del código:

Pequeñas mejoras, unas tras otras. Reescribir ciertas partes del código
para aumentar su legibilidad y
Realización de pruebas unitarias mantenibilidad, pero sin modificar su
continuas: Frecuentemente repetidas comportamiento
y automatizadas, incluyendo pruebas
de regresión La programación extrema apuesta
a lo más sencillo, a hacer algo simple
Corrección de todos los errores: y tener un poco de trabajo extra para
Antes de añadir una nueva cambiarlo si se requiere realizar algo
funcionalidad. complicado y quizás
IV. Roles Posee conocimiento específico en algún tema
necesario para el proyecto, en el que puedan Consultor
surgir problemas.

Coordinar la comunicación entre las distintas partes Inicia y orienta al equipo en la implementación
efectiva de la metodología XP.
Ofrece y gestiona los recursos necesarios
Guía al equipo en la aplicación de las
del proyecto
Coach prácticas de XP y el proceso global.
Manager

Escribe historias de usuario y

Implementa historias de usuario y
pruebas funcionales.
Asigna prioridades a las historias de Customer Programmer estima el tiempo de desarrollo.
Diseña y ejecuta pruebas unitarias
usuario y realiza pruebas de
para el código.
aceptación

Tracker Tester
Ofrece retroalimentación para mejorar Ayuda al cliente con pruebas funcionales
las estimaciones futuras y ejecuta pruebas regularmente.
Verifica el cumplimiento de las estimaciones y el Proporciona herramientas de soporte para pruebas
progreso de cada iteración. y comparte resultados con el equipo.
“El sistema es desarrollado para el cliente, por lo
tanto, el usuario es quien decide que tareas
realizará la aplicación”
 Historias de Usuario (HU)
Las historias de usuario son utilizadas como
herramienta para dar a conocer los
requerimientos al equipo de desarrollo.

V. Son pequeños textos en los que el cliente

Artefactos describe una actividad que realizará el sistema.

La redacción de los mismos se realiza bajo las

terminologías del cliente

No son detalladas

Es indispensable el acompañamiento del

representante del usuario
 Aspectos de las HU

1. Tarjeta: En ella se almacena suficiente información

para identificar y detallar la historia.

2. Conversación: Cliente y programadores discuten la

Como un cliente,
historia para ampliar los detalles.
quiero consultar el
catálogo para poder 3. Pruebas de Aceptación: Permite confirmar que la
encontrar el historia ha sido implementada correctamente.
producto que deseo
comprar
Complementos necesarios

Ingeniería de requisitos Pruebas de aceptación

Descomposición de historias de Cruciales para el éxito de una iteración

usuario en tareas de ingeniería. y el inicio de la siguiente.

Vinculación directa con el desarrollador Proporcionan retroalimentación para

para un acercamiento al código. las próximas historias de usuario.

Realizadas por el encargado de

verificar la funcionalidad esperada.
 Tarjetas CRC
Colaboración entre
(Clase-Responsabilidad-Colaboración)
miembros
conocimiento y diseño
Herramienta de diseño para el desarrollo de
total estructurado
software orientado a objetos.

Facilita la transición del enfoque procedimental

al orientado a objetos al identificar clases y
asignar responsabilidades y colaboraciones a
cada una.

Cada tarjeta representa una clase potencial y

detalla su función y relaciones en el sistema.
V.
Artefactos
Aspectos de las CRC

1. En la parte superior, el nombre de la

clase

2. Debajo, en la parte izquierda, las

responsabilidades de dicha clase. Son
sus objetivos, a alto nivel.

3. A la derecha de las responsabilidades,

los colaboradores, que son otras clases
que ayudan a conseguir cumplir a esta
con sus responsabilidades
VI. Procesos clave de XP
Los procesos claves se dividen en:
Ciclo de vida del proyecto
Etapas

El ciclo de vida del proyecto se refiere a las diferentes fases por las que pasa un proyecto
desde su inicio hasta su finalización, incluyendo la planificación, ejecución y cierre

Las etapas de XP se repiten a lo largo de la fase de ejecución del proyecto en el ciclo de

vida general del proyecto, lo que permite la entrega continua de funcionalidades y la
adaptación ágil a los cambios en los requisitos del cliente.
.
 Comprender las Establecer prioridades y
historias de usuario cronograma de entrega.
iniciales. Planificación Acuerdos sobre el
Prototipado y Exploración contenido y la
de la entrega
familiarización con la estimación de esfuerzo.
tecnología.

Satisfacción completa
Iteraciones de
de las necesidades del
máximo tres
cliente.
Muerte del semanas.
Finalización de la Ciclo de vida Iteraciones Ajustes basados en
documentación y proyecto
retroalimentación
cambios en la
del cliente.
arquitectura.

Soporte al cliente y Pruebas y revisiones

mantenimiento del de rendimiento.
sistema en producción. Mantenimiento Producción Decisiones sobre
Ajustes en la velocidad y nuevas características
estructura del equipo. y cambios.
Etapas
Recopilación de Seguir el principio
requerimientos y "Mantenlo sencillo" (MS)
comprensión del contexto en el diseño de XP.
del negocio. Creación de prototipos
Adquisición de sensibilidad para resolver problemas
sobre las características
Planeación Diseño de diseño y control de
principales necesarias. modificaciones.

Pruebas unitarias
Desarrollo de pruebas
automatizadas para la
Pruebas Codificación unitarias antes de la
detección temprana de
implementación.
errores.
Programación en parejas
Pruebas de aceptación
para resolver problemas
centradas en
en tiempo real y garantizar
características visibles y
la integración continua.
revisables por el cliente.
VII. Métricas
Visión cuantitativa del
Medir y mejorar el proceso de desarrollo de software progreso del equipo, la
calidad del código y la
eficiencia de las prácticas de
Velocidad del equipo (Team velocity) desarrollo
Cantidad de trabajo que un equipo de desarrollo puede
completar en un sprint

TV= Trabajo completado/duración sprint

Tiempo de ciclo (Cycle Time)

Tiempo total que tarda en completarse una tarea desde
su inicio hasta su finalización

TC= T_finalización - T_inicio

VII. Métricas
Visión cuantitativa del
Medir y mejorar el proceso de desarrollo de software progreso del equipo, la
calidad del código y la
eficiencia de las prácticas de
Tasa de defectos (Defect Rate)
desarrollo
Cantidad de defectos encontrados en el software
durante un período específico

TD = N_defectos encontrados / N_casos de prueba ejecutados

Porcentaje de pruebas cubiertas

Cantidad de código que se ha probado en comparación
con el código total

PC= (C_código probado / C_total de código) * 100

VII. Métricas
Visión cuantitativa del
Medir y mejorar el proceso de desarrollo de software progreso del equipo, la
calidad del código y la
eficiencia de las prácticas de
Tiempo promedio entre fallos (MTBF)
desarrollo
tiempo promedio que transcurre entre dos fallos
consecutivos en el software

MTBF = Tiempo total / Número de fallos

Velocidad del proyecto

medida de la capacidad que tiene el equipo de desarrollo
para evacuar las historias de usuario en una determinada
iteración

VP = HU / SPRINT
VIII. Ventajas y Desventajas
Ventajas:
a. Mayor colaboración y comunicación entre los miembros del equipo.​
b. Aborda problemas y desafíos de manera temprana, con el fin, reducir más riesgos de
fracaso en el proyecto.​
c. División del proyectos en iteraciones pequeñas, lo cual aumenta la productividad del
equipo.​
d. Comunicarse con el cliente de manera constante puede perfeccionar o ajustar los
requerimientos del proyecto y mejorar la satisfacción final.

Desventajas:
a. Solo se basa en el desarrollo de software en la cual limita aplicabilidad en proyectos que
no estén relacionados con este tema.​
b. Requiere de un equipo de trabajo comprometido.​
c. Mayor dependencia del cliente en la cual se necesita de una participación proactiva.
 KANBAN
Es una herramienta de procesos
 ¿Qué es Kanban?
Es un enfoque de gestión de proyectos que consiste
en la visualización del trabajo y la optimización del
flujo del trabajo. Además esta metodología es usada
para mejorar la eficiencia y la calidad del trabajo
I. Introducción realizado. Surgió en el año 1950 por un ingeniero
industrial Japonés llamado Taiichi Ohno.

Kanban = “tarjeta” o “señal”

Submetodo de gestión de
operaciones JIT (just in time)
En el momento que se
requiera
Calidad especificada
Sin desprediciar recursos
 II. Principios y valores
Calidad Garantizada: Durante la realización de tareas no debe haber un margen de error,
la idea de esto es hacer las tareas de manera adecuada, ya que no se tiene en cuenta la
rapidez de estas, sino la calidad final de las tareas del proyecto.

Reducción del desperdicio: Se basa en lo justo y necesario del proyecto, pero hacerlo bien.
 II. Principios y valores
Mejora continúa: No es un método de gestión, sino un sistema de mejora en el desarrollo
de proyectos, según los objetivos a lograr.​

Flexibilidad: Se adapta a diferentes entornos de trabajo, producción,fabricación,

desarrollo,etc.
 Kanban y el cumplimiento de reglas
Kanban tiene un enfoque ágil, así como es una
herramienta de desarrollo dotada de reglas:

1. Visualizar el flujo de trabajo:

Divide el trabajo en tareas y anótalas

en tarjetas.

Coloca las tarjetas en columnas que

representen los estados de progreso.

Garantiza que el trabajo esté claro y

visible para todos los miembros del
equipo, asegurándose de que cada
III. miembro tenga tareas asignadas según
las prioridades.
Reglas
 Kanban y el cumplimiento de reglas
Kanban es una metodología ágil, así como una
herramienta de desarrollo dotada de reglas:
2. Limitar el WIP (work in progress)

Número de tareas limitada en cada estado

del flujo de trabajo, sin importar el tamaño
del proyecto (en simultáneo)

Permite evitar cuellos de botella, mantiene

la eficiencia y productividad:

Punto en el que la capacidad se ve

restringida debido a la limitación de
recursos, capacidades o restricciones en
III. el sistema.

Reglas
 Limitar el WIP (work in progress)

Se debe definir cuantas tareas como máximo

puede realizarse en cada fase del ciclo de trabajo

III. Reglas
 Kanban y el cumplimiento de reglas
3. Controlar el tiempo en completar una
actividad (Cycle time), medir el tiempo de
espera

III. Consiste en el monitoreo y control de

métricas que faciliten la mejora continúa
Reglas
IV. Roles
Hacen todo según las indicación y demás.

Equipo

Gestor de
Gestor de prestación Gestionar el flujo de trabajo y las
Entender las necesidades y solicitudes de servicio tareas específicas de un proyecto.​
expectativas de los clientes.​ de servicio
El trabajo debe fluirse de manera
Prioriza los elementos de la reunión.​
eficaz y que se cumplan los
Define las políticas del sistema en la
compromisos de las entregas.​
cual debe coincidir con las
Estar involucrado en la resolución
expectativas de los clientes.​
de los problemas y en la mejora
Evalúa los riesgos del proyecto.
continua de esta metodología.

La metodología en sí no establece ningún rol,

sin embargo se recomienda esta distribucióm
V. Parámetros de control
Mejora continua y calidad

Lead Time (Tiempo de ejecución)

Tiempo desde la solicitud hasta la entrega

Cycle Time (Tiempo de ciclo)

Desde el inicio hasta la finalización de una actividad,
mide el rendimiento del proceso

Optimización clave
Mejora continua y control mediante la optimización de
Lead Time y Cycle Time.
V. Parámetros de control
Mejora continua y calidad

Throughput (Rendimiento de trabajo)

Cantidad de ítems que un equipo puede terminar en un
periodo de tiempo determinado

WIP (Work in progress)

Registro del número promedio de elementos en el
sistema
La cantidad de elementos que ingresaron al sistema y
restar la cantidad de elementos que salieron del sistema
en una unidad de tiempo

5 ítems ingresan - 2 ítems salen / 1 día = 3 ítems /día

Se debe buscar que:

Maximizar el cycle time

maximizar el
throughput
lograr una variabilidad
mínima entre el cycle
time y throughput
VI. Tablero Kanban
Las anteriores reglas mencionadas se reflejan en la utilización y ejecución del tablero
kanban, puesto que:

Proporciona visibilidad de todo el proceso, muestra el trabajo asignado a cada

miembro.

Indica las prioridades de cada tarea

Equilibra la demanda con el rendimiento del trabajo liberado por el equipo,

consiguiendo un ritmo de desarrollo sostenible, un mayor rendimiento junto con
una calidad elevada del producto final (reduce lead time)
.
VI. Tablero Kanban
Se tienen tantas columnas como
estados por los que puede pasar
una tarea.

En el ejemplo las atreas van de la

A a N y el flujo de trabajo tiene 5
fases

Objetivos
Entender el proceso actual de trabajo
Conocer los problemas que puedan surgir
Comunicación abierta
Procesos futuros predecibles
VI. 1. Tarjetas kanban
La identificación de tarjetas y su flujo dentro del proceso de desarrollo es vital:
Se recomienda asignar colores a las categorías de las tarjetas para mejorar la
rápida identificación.
Las tarjetas suelen contener mucha información.
Deben tener el tamaño adecuado
Deben estar actualizadas constantemente
Deben tener la estimación de tiempo que tiene asignada la tarea, además de la
fecha de entrada y salida
VI. 1. Tarjetas kanban
Estas son algunas de las categorías y sus respectivos colores que se recomienda utilizar:

a. Tareas prioritarias: Tarjetas designadas para tareas críticas o urgentes que

requieren atención inmediata.
b. Tareas pendientes: Tarjetas que representan tareas que están listas para ser
abordadas pero aún no se han comenzado.
c. Tareas en progreso: Tarjetas que muestran las tareas en las que el equipo está
actualmente trabajando y que están en proceso de implementación.
d. Tareas completadas: Tarjetas que indican las tareas que han sido finalizadas y que
están listas para su revisión o entrega.
e. Bloqueos o problemas: Tarjetas utilizadas para identificar problemas, obstáculos o
bloqueos que impiden el progreso en una tarea y que requieren atención
inmediata.
f. Tareas planificadas: Tarjetas que representan tareas programadas para su
implementación en el futuro y que aún no se han iniciado
VI. 1. Tarjetas kanban

*Esta metodología se orienta a lo visual, se

pueden utilizar caricaturas, emojis o dibujos
como acompañamiento de las tarjetas

*QTY: Cantidad, en el contexto de la

tarjeta se refiere a la cantidad de
producto

*Location: se refiere a donde está

posicionado el tablero al que pertenece
VII. Fases de la metodología Kanban
Establecer un flujo de
Establecer
trabajo o framework

Definir las fases o los

Definir
estados de las tareas

Agregar las tareas en el

Agregar estado correspondiente
Es iterativo cada vez
Desarrollar las tareas y que se completa un
Realizar
realizar el seguimiento estado de una tarea
sobre el flujo de trabajo

Evaluar, actualizar y mejorar

Evaluar
de manera continua
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
 VIII.
Ejemplo
Herramientas tecnológicas para
Xp y Kanban
 REFERENCIAS

“Aplicacion de kanaban en el desarrollo de un sistema web para administración

del consultorio odontologico fitoc dental” (artículo)
“Aplicación de la metodología kanban en el desarrollo del software para
generación, validación y actualización de reactivos, integrado al sistema
informático de control académico UNACH” (artículo)
“Sistema kanban, como ventaja competitiva en la micro,pequeña y gran empresa”
(artículo)
“Técnicas para el uso de la metodología eXtreme Programming en el desarrollo
de Software” (artículo)
“ Metodologías de desarrollo de software (XP)” (artículo)
“DESARROLLO ÁGIL DE SOFTWARE APLICANDO PROGRAMACIÓN EXTREMA”
(artículo)

GRACIAS