Você está na página 1de 29

“Universidad Interamericana Para El Desarrollo”

Asignatura:

Fundamentos De Ingeniería De Software

Carrera:

Ingeniería en tecnologías de la información y comunicación

Investigación: “Implantación De La Programación Extrema”

Presenta:

Edrey Aguilar Ek
00269495

Docente:

Luis A. López Monroy

Cuatrimestre y turno:

2do Cuatrimestre Vespertino

Chetumal, Quintana Roo 16 de marzo de 2018


Índice
Introducción..................................................................................................................................... 1
1. Definiendo XP (Programación Extrema) .......................................................................... 2
2. Implantación de XP (Programación Extrema)................................................................. 2
3. Roles del equipo ..................................................................................................................... 3
4. Historias de usuario .............................................................................................................. 5
¿Qué Son? ................................................................................................................................... 5
¿Para qué se utilizan?............................................................................................................... 5
¿Cómo se redactan las historias de usuario?.................................................................... 5
Estructura de las historias de usuario ................................................................................. 6
5. Pruebas de aceptación ......................................................................................................... 8
El rol del cliente y otros roles en las pruebas de aceptación ........................................ 8
Criterios de aprobación ............................................................................................................ 9
Definir los casos de prueba ................................................................................................... 10
Presentación de los resultados de las pruebas de aceptación ................................... 10
Ejemplo de un caso de prueba de aceptación ................................................................. 11
6. Estimación del peso(priorización) de historias de usuario ...................................... 13
Método de “Puntos de historia” ........................................................................................... 13
Aspectos a tomar en cuenta con los puntos de historia ............................................... 13
¿Cómo hacerlo? ....................................................................................................................... 14
Los valores a utilizar ........................................................................................................... 14
Aspectos a tomar en cuenta: ............................................................................................ 14
Beneficios de estimar en puntos de historia .................................................................... 15
7. Planificación de las iteraciones........................................................................................ 16
Beneficios de planear las iteraciones................................................................................. 16
8. Sesiones de diseño rápido ................................................................................................ 18
Pautas para aprovechar una sesión de diseño rápido................................................... 18
9. Manejo de defectos .............................................................................................................. 19
Tipos de defectos: ................................................................................................................... 19
Diagrama de procedimiento .................................................................................................. 20
Detalle de las actividades ...................................................................................................... 21
Conclusión ..................................................................................................................................... 25
Referencias .................................................................................................................................... 26
Índice De Ilustraciones Y Tablas
ILUSTRACIÓN 1. MODELO XP .................................................................................................................................... 2
ILUSTRACIÓN 2. ESTRUCTURA DE HISTORIA DE USUARIO ................................................................................................. 6
ILUSTRACIÓN 3. PUNTOS DE ITERACION ..................................................................................................................... 13
ILUSTRACIÓN 4. DIAGRAMA DE PROCEDIMIENTO PARA MANEJAR DEFECTOS ...................................................................... 20

TABLA 1. RESUMEN DE LOS DATOS DEL CASO DE PRUEBA “LOGIN”................................................................................... 11


TABLA 2. PASOS Y ACCIONES DEL CASO DE PRUEBA "LOGIN"........................................................................................... 11
TABLA 3. DATOS DE ENTRADA Y RESULTADOS DEL CASO DE PRUEBA "LOGIN" ..................................................................... 12
TABLA 4. RESUMEN DE LOS CASOS Y RESULTADOS DE LAS PRUEBAS DE ACEPTACIÓN ............................................................ 12
Introducción
XP es una de las llamadas metodologías ágiles de desarrollo de software más
exitosas de los tiempos recientes. La metodología propuesta en XP está diseñada
para entregar el software que los clientes necesitan en el momento en que lo
necesitan. XP alienta a los desarrolladores a responder a los requerimientos
cambiantes de los clientes, aún en fases tardías del ciclo de vida del desarrollo.
Extreme Programming (XP) surge como una nueva manera de encarar proyectos
de software, proponiendo una metodología basada esencialmente en la simplicidad
y agilidad.

Pero dentro del desarrollo de esta metodología es donde debemos tener en cuenta
ciertos puntos a la hora de implementarla como lo son: Roles de las personas,
Historias de usuario, pruebas de aceptación, Estimación de peso de las iteraciones,
Pruebas de aceptación, planeación iteraciones, sesiones de diseño rápido y el
manejo de defectos todos los puntos anteriormente mencionados son claves y se
deben conocer para que un proyecto se desarrolle de manera correcta y se permita
obtener beneficios en el desarrollo. No solo basta con saber que es XP o seguir el
esquema de desarrollo que propone, sino que hay que comprender estos puntos ya
que no indican como vamos a trabajar la metodología XP en un proyecto y como
trabajaremos con el cliente realizaremos las pruebas y estimaremos el tiempo en
diseño y corrección de defectos. Para beneficio cliente – desarrollador.
Toda esta información se ha recolectado, estudiado, y filtrado para ser presentada
en la siguiente documentación de investigación a fin de que sea comprensible y
amena para el lector y que no incluya material superfluo que eclipse el
entendimiento de los lectores. La información se ha estructurado de acuerdo a como
se considera se debe leer la información ofreciendo dos índices para acceso rápido
a temas específicos para el lector también se han seguido pautas de documentación
siendo la información clara y concisa, siguiendo las reglas gramaticales. Y se
complementado la información con imágenes para comprender ciertos puntos
importantes en la redacción.

1
1. Definiendo XP (Programación Extrema)
Xtreme Programming de ahora en adelante XP, es una metodología de desarrollo
de software ágil, que considera a las personas como un factor decisivo para lograr
el éxito de un proyecto. Por ser un proceso ágil tiene como principal característica
su adaptación a entornos cambiantes. Esto es posible porque el proceso está
diseñado para adaptarse en forma inmediata a los cambios, con bajos costos
asociados en cualquier etapa del ciclo de vida.
Está diseñada para trabajar en pequeños o medianos equipos de hasta 12
integrantes. Esto fomenta la comunicación e interacción entre sus integrantes,
logrando el trabajo en equipo. De esta forma, es posible reducir el costo de transferir
información entre los mismos, al tener a todo el equipo compartiendo un mismo
lugar de trabajo.
El cliente cumple un rol fundamental en XP,
dirigiendo el proyecto a lo largo del mismo. Este
es quién fija las prioridades, y los
programadores desarrollan lo que es necesario
para ese momento en particular. En pequeñas
iteraciones el sistema va creciendo según los
requerimientos solicitados por el cliente, el cual
puede observar el avance del proyecto en todo
momento.

Ilustración 1. Modelo XP

2. Implantación de XP (Programación Extrema)


Cuando un equipo de desarrollo ha recibido la oferta de desarrollar un proyecto para
un cliente entonces ha llegado la hora de tomar la decisión de ¿Usar una
metodología ágil o una metodología guiada por plan? La gran mayoría de proyectos
se pueden beneficiar mucho del uso de una metodología ágil, pero indudablemente
existen proyectos y entornos en los que es condición, generalmente impuesta por
el cliente o la dirección de la empresa, que el proyecto se desarrolle con más control.
El uso de una metodología ágil como lo es XP (Programación Extrema) implica que
el proyecto se desarrolle con un enfoque y proceso determinado por esta
metodología, sin embargo, el desarrollo de un producto y la implantación del modelo
son cosas distintas. Para implementar el modelo de manera correcta hay que
hacerlo con los pasos y puntos necesarios (Roles del equipo, historias de usuario,
pruebas de aceptación, estimaciones, planeación de iteraciones, sesiones de
diseño rápido y la solución de defectos) y conforme vayamos haciendo la
implementación del modelo en el equipo el desarrollo del producto será más simple.

2
3. Roles del equipo
Programador
Escribe las pruebas unitarias y produce el código del sistema. Define las tareas que
conlleva cada historia de usuario, y estima el tiempo que requerirá cada una.
 Más responsabilidad que en otros modos de desarrollo
 Responsable sobre el código
 Responsable sobre el diseño (refactorización, simplicidad)
 Responsable sobre la integridad del sistema (pruebas)
 Capacidad de comunicación

Cliente
Escribe las historias de usuario (Requerimientos del Software) y las pruebas
funcionales para validar su implementación. Asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en aportar
el mayor valor de negocio.
 Pieza básica en desarrollos XP
 Define especificaciones
 Influye sin controlar
 Confía en el grupo de desarrollo
 Define pruebas funcionales

Encargado de Pruebas
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente,
difunde los resultados en el equipo y es responsable de las herramientas de soporte
para pruebas.
 Apoya al cliente en la preparación/realización de las pruebas funcionales
 Ejecuta las pruebas funcionales y publica los resultados

Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema
necesario para el proyecto. Guía al equipo para resolver un problema específico.
 Apoya al equipo XP en cuestiones puntuales

3
Encargado de Seguimiento (Tracker)
Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe
verificar el grado de acierto entre las estimaciones realizadas y el tiempo real
dedicado, comunicando los resultados para mejorar futuras estimaciones. Recoge,
analiza y publica información sobre la marcha del proyecto sin afectar demasiado
el proceso.
 Supervisa el cumplimiento de la estimación en cada iteración
 Informa sobre la marcha de la iteración en curso
 Controla la marcha de las pruebas funcionales, de los errores reportados, de
las responsabilidades aceptadas y de las pruebas añadidas por los errores
encontrados

Entrenador (Coach)
Es responsable del proceso global. Experto en XP, provee de las guías a los
miembros del equipo para que se apliquen las prácticas XP y se siga el proceso
correctamente. Determina la tecnología y metodologías a usar por el equipo de
desarrollo.
 Experto en XP
 Responsable del proceso en su conjunto
 Identifica las desviaciones y reclama atención sobre las mismas
 Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza)
 Interviene directamente si es necesario
 Atajar rápidamente el problema

Jefe del Proyecto


Es el dueño del equipo y sus problemas. Experto en tecnología y labores de gestión.
Construye el plantel del equipo, obtiene los recursos necesarios y maneja los
problemas que se generan. Administra a su vez las reuniones (planes de iteración,
agenda de compromisos, etc.). No le dice al grupo lo que tiene que hacer, cuando
hacerlo, ni verifica el avance de las tareas.
 Favorece la relación entre usuarios y desarrolladores
 Confía en el equipo XP
 Cubre las necesidades del equipo XP
 Asegura que alcanza sus objetivos

4
4. Historias de usuario
¿Qué Son?
Las “Historias de usuarios” (“User stories”) sustituyen a los documentos de
especificación funcional, y a los “casos de uso”. Estas “historias” son escritas por el
cliente, en su propio lenguaje, como descripciones cortas de lo que el sistema debe
realizar. Las historias de usuario deben tener el detalle mínimo como para que los
programadores puedan realizar una estimación poco riesgosa del tiempo que
llevará su desarrollo.
¿Para qué se utilizan?
Su propósito principal de esta herramienta es la estimación del esfuerzo necesario
para implementar una nueva funcionalidad (Feature), en un software, siguiendo la
definición de “Hecho” (DONE) que defina el equipo.
Adicionalmente, se utilizan como iniciadoras de conversaciones entre
desarrolladores de software y usuarios del área de negocio, las cuales servirán para
identificar los requerimientos del negocio, requerimientos técnicos y para encontrar
los supuestos (premisas) no visibles en una primera aproximación.
Para estas estimaciones, se le asignan unidades de medida a las historias que
representen magnitud y no días reales de duración, tales como: puntos de historia,
días ideales u otra unidad de medida.
¿Cómo se redactan las historias de usuario?
Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la
funcionalidad y el resultado esperado de la aplicación en una frase corta.
Adicionalmente, debe venir acompañada de los criterios de aceptación, no más de
4 por historia, redactado también en una frase que incluya el contexto, el evento y
el comportamiento esperado ante ese evento.
Algunas características deseables de las historias de usuario son:
 Que sean escritas por el usuario o por un analista de negocio que le
represente.
 Frase corta que encaje en una tarjeta de 3 por 5 pulgadas.
 Debe describir el rol desempeñado por el usuario en el sistema, descrito de
forma explícita.
 Debe describir el beneficio para el área de negocio que representa esta
funcionalidad.

5
Estructura de las historias de usuario

Ilustración 2. Estructura de Historia De usuario

 ID: Identificador de la historia de usuario


 Título: Título descriptivo de la historia de usuario
 Descripción: Descripción sintetizada de la historia de usuario
 Estimación: Estimación del coste de implementación en unidades de
desarrollo (estas unidades representarán el tiempo teórico de
desarrollo/hombre que se estipule al comienzo del proyecto)
 Prioridad: Prioridad en la implementación de la historia de usuario respecto
al resto de las historias de usuario. A mayor número, mayor prioridad. Otra
aproximación a la priorización de tareas se hace a través del método
MoSCoW:
o M – Must, se debe completar este requerimiento para finalizar el
proyecto
o S – Should, se debe completar este proyecto por todos los medios,
pero el éxito del proyecto no depende de él.
o C – Could, se debería completar este requerimiento si su
implementación no afecta a la consecución de los objetivos principales
del proyecto.
o W – Would, se puede completar este requerimiento si sobra tiempo de
desarrollo (o en futuras versiones del mismo)

6
 Dependencias: Una historia de usuario no debería ser dependiente de otra
historia, pero a veces es inevitable. En este apartado se indicarían los IDs de
las tareas de las que depende una tarea

Ciclo de vida
El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C”
por sus iniciales en inglés (Card, Conversation, Confirmation):

 Tarjeta (Card), la creación de la tarjeta en sí, con la estructura definida


anteriormente y que sirve para determinar QUÉ se debe hacer y cómo
planificarlo.
 Conversacion (Conversation), representado por pequeños documentos y
anotaciones que sirven para aportar detalles y refinar los datos sobre las
características del requerimiento.
 Confirmación (Confirmation), o pruebas de aceptación. Pruebas
consensuadas entre el cliente y el desarrollador y que el código debe superar
para dar como finalizada la implementación del requerimiento.

7
5. Pruebas de aceptación
Las pruebas de aceptación son pruebas de caja negra definidas por el cliente para
cada historia de usuario, y tienen como objetivo asegurar que las funcionalidades
del sistema cumplen con lo que se espera de ellas. En efecto, las pruebas de
aceptación corresponden a una especie de documento de requerimientos en XP, ya
que marcan el camino a seguir en cada iteración, indicándole al equipo de desarrollo
hacia donde tiene que ir y en qué puntos o funcionalidades debe poner el mayor
esfuerzo y atención.
“Las pruebas de aceptación permiten al cliente saber cuándo el sistema funciona, y
que los programadores conozcan que es lo que resta por hacer.” (Jeffries et al.
2000, 45)
Las pruebas de aceptación tienen una importancia crítica para el éxito de una
iteración. Por lo tanto, el tester debe tenerlas prontas lo antes posible a partir del
comienzo de la iteración, y lograr que el cliente las apruebe para poder
presentárselas cuanto antes al equipo de desarrollo.
El rol del cliente y otros roles en las pruebas de aceptación
En XP las pruebas de aceptación son en última instancia responsabilidad del cliente
ya que deben reflejar los requerimientos y las funcionalidades que se quieren
obtener en cada iteración. Es más, en algunos proyectos realizados con la
metodología XP, el cliente llega a escribir las pruebas de aceptación.
Sin embargo, la mayoría de los clientes, especialmente cuando son externos al
proyecto, son personas muy ocupadas con trabajos de tiempo completo, por lo
tanto, no disponen de demasiado tiempo para dedicarle al proyecto. Además,
generalmente no tienen ni la experiencia ni los conocimientos técnicos necesarios
para escribir correctamente las pruebas de aceptación. Por esta razón el tester debe
reunirse con el cliente para interpretar sus ideas y sus necesidades y luego poder
escribir los casos de prueba correspondientes. También es importante que el tester
guíe al cliente en la definición de los criterios de calidad, realizando diferentes
cuestionarios e identificando lo que es crucial para él.
Es importante también que el cliente especifique criterios de estabilidad y
performance si los mismos son relevantes para la iteración. Por ejemplo, si un
sistema tiene que manejar un gran número de usuarios o transacciones a una
velocidad determinada, el grupo de desarrollo debe aumentar las horas estimadas
para contemplar estas características. En muchos casos, la estabilidad y la
performance del sistema se convierten en historias de usuario independientes.

8
Por otra parte, es responsabilidad del cliente brindar los datos para poder ejecutar
las pruebas de aceptación. Estos datos podrían ser creados o generados
específicamente para las pruebas, pero generalmente los clientes ya cuentan con
archivos o datos reales que pueden poner a disposición del equipo de desarrollo.
Esto permite que estas pruebas sean lo más parecidas posible al ambiente de
producción en donde se va a utilizar el sistema, logrando así una disminución
importante de las fallas detectadas luego de la implantación del mismo. Según
Crispin y Tip House los datos de prueba son tan importantes como las pruebas en
sí mismas.
La mayoría de los clientes no tienen claro en una primera instancia todas las
características de cada historia de usuario. Muchas veces asumen que los
programadores conocen todas sus necesidades, lo que provoca decepción en el
momento en el cual el cliente recibe las funcionalidades implementadas durante la
iteración. Es por esto que el tester debe interactuar con el cliente de manera de no
dejar ningún detalle sin especificar dentro de las pruebas de aceptación.
Crispín propone la revisión de las pruebas de aceptación junto con los
programadores, ya que muchas veces existen pruebas unitarias que se superponen
con alguna prueba de aceptación propuesta por el cliente. Es más, en ocasiones los
programadores sugieren que determinadas pruebas de aceptación se realicen como
pruebas unitarias, logrando así optimizar el esfuerzo.
Criterios de aprobación
En XP las pruebas de aceptación cumplen con el objetivo de indicarnos cuando las
funcionalidades de una iteración han sido completadas exitosamente. A diferencia
de las pruebas unitarias, el criterio de aprobación de las pruebas de aceptación no
tiene que ser necesariamente de 100% de efectividad. Todos sabemos que es
imposible esperar un código totalmente libre de errores, por lo tanto, es necesario
definir un criterio de aprobación para saber cuándo el software está listo para ser
liberado.
El cliente podría demandar que el 100% de los casos de prueba sean exitosos para
pasar de iteración. Sin embargo, como en XP las iteraciones tienen que terminar en
fecha y los tiempos límites de entrega no son negociables, esto provocaría un
tiempo de estimación mayor para cada historia de usuario. Por lo tanto,
generalmente se sugiere que el cliente incluya pruebas de aceptación no críticas.
Si estas pruebas se superan exitosamente generan una cuota extra de confianza
en el cliente, pero si las mismas fallan en el fin de una iteración el cliente puede
decidir repetir dichas pruebas al final de la siguiente iteración aumentando el grado
de criticidad de las mismas.

9
Definir los casos de prueba
Una vez que se comprendieron los requerimientos del cliente para las pruebas de
aceptación estamos en condiciones de comenzar a definir los casos de pruebas.
Cabe recordar que el objetivo de estas pruebas no es tener un conjunto de casos
escritos que cubran el 100% del código, sino poder realizar el testing del sistema
desde el punto de vista del usuario. En XP se considera que las pruebas de
aceptación deben consistir en un conjunto mínimo (no pobre ni insuficiente) de
casos que cubran los requerimientos de negocios fundamentales planteados por el
cliente.
Para escribir los casos de prueba se deben tener en cuenta ciertas consideraciones
importantes. En primer lugar, cada caso debe servir para obtener un feedback
rápido y concreto de cómo se está desarrollando la iteración y el proyecto. Se tienen
que tratar de evitar los casos de pruebas extensos que incluyan un gran número de
pasos. Los casos escritos deben ser concisos y hay que documentar por separado
los pasos del caso y los datos de prueba en sí mismos. Es importante señalar
también que todos los casos de prueba cumplidos con éxito en iteraciones
anteriores se deben seguir cumpliendo en todas las iteraciones, y si se produce un
error, aunque sea en un único paso del caso de prueba se considera que todo el
caso falló.
Presentación de los resultados de las pruebas de aceptación
Otra importante diferencia entre las pruebas de aceptación y las pruebas unitarias
es que para las de aceptación la presentación de lo resultados es importante, en
cambio para las unitarias no tiene mucho sentido ya que siempre se requiere un
100% de efectividad. Beck (2000) recomienda la exhibición de los resultados que
se obtienen al ejecutar las pruebas de aceptación, generando reportes y gráficas
que desplieguen los porcentajes de efectividad obtenidos. Estos índices permiten
evaluar si el equipo de desarrollo está realizando un buen trabajo o no. Es
importante mantener esta información estadística actualizada y visible para todos
los integrantes del proyecto.
Por último, cabe mencionar que XP recomienda la automatización de los casos de
pruebas de aceptación para permitir que sean ejecutados por lo programadores ni
bien tengan una porción del código más o menos terminada. De todas formas, esto
depende de cada caso y del tipo de proyecto, ya que algunas veces el costo de
automatizar los casos de prueba y luego mantenerlos es muy alto y por lo tanto se
opta por la ejecución manual de los mismos. Es muy común que los casos de
pruebas de una iteración no se puedan automatizar en esa misma iteración por
problemas de tiempo, pero a veces esta tarea se puede realizar en iteraciones
siguientes ya que estos casos se van a correr en todas las sucesivas iteraciones.

10
Ejemplo de un caso de prueba de aceptación
A continuación, un ejemplo de un caso de prueba de aceptación En la figura 1 se
muestra el resumen del caso, en la figura 2 se detallan los pasos del caso y las
acciones que se deben llevar a cabo, y en la figura 3 se especifican los datos de las
diferentes pruebas realizadas.

Tabla 1. Resumen de los datos del caso de prueba “login”

Tabla 2. Pasos y acciones del caso de prueba "login"

11
Tabla 3. Datos de entrada y resultados del caso de prueba "login"

El siguiente cuadro de resumen donde presenta tanto gráfica como numéricamente


los casos de pruebas escritos, ejecutados y exitosos.

Tabla 4. Resumen de los casos y resultados de las pruebas de aceptación

12
6. Estimación del peso(priorización) de historias de usuario
Método de “Puntos de historia”
El método de puntos de historia se desarrolló no para obtener un valor en horas de
esfuerzo para el desarrollo de una historia de usuario (cada una de las partes en
que se divide la funcionalidad a desarrollar en las metodologías ágiles) sino como
una manera de dimensionar y relacionar la complejidad de las historias de usuario
con respecto a otras.
Aspectos a tomar en cuenta con los puntos de historia
La medida que utilizamos es el punto historia o story point. Un punto historia es
mezcla de los siguientes aspectos:
 Complejidad: Una historia que es más compleja que otra tendrá más puntos
historia.
 Esfuerzo: Quizás una historia no tiene complejidad, pero si requiere esfuerzo
(ejemplo, cambiar literales en todas las pantallas de la aplicación), también
tendrá más puntos historia que otra más corta.
 Incertidumbre o riesgo: Es la probabilidad de que algo no esperado
aparezca en la historia, siempre por falta de información previa. Aquí no se
cuenta lo que suele ir mal. Por ejemplo, si cada vez que tocamos el módulo
de autenticación rompemos algo, eso no debe reflejarse en la estimación
(porque no queremos tapar los puntos de mejora).
Para las estimaciones en puntos historia el equipo utiliza una escala de estimación.
No es más que una herramienta en forma de panel con ejemplos representativos de
cada medida de estimación. Si utilizamos la escala de Fibonacci modificada de
planning poker, una escala de estimación debería tener más o menos esta
apariencia

Ilustración 3. Puntos de iteración

13
¿Cómo hacerlo?
Como primer paso del proceso, se selecciona una historia de usuario para asignarle
una complejidad nominal que servirá de referencia para catalogar al resto de
historias de usuario: como esta historia es de complejidad X esta otra, que en
comparación es menos compleja, será de complejidad i, donde i es menor que X ó
como esta historia es más compleja será de complejidad j, donde j es mayor que X.
Los valores a utilizar
Los valores que se utilizan para representar la complejidad no tienen un valor
absoluto, sino que su valor es función de su posición en escala.
Se comenzó utilizando la serie de Fibonacci: 1,2,3,5,8,13,21, …, aunque para evitar
que se pensara que hay una precisión matemática en los valores a partir de cierto
número se sustituyeron por otros aproximados: 3,5,8,13,40, 100… (el 1 y el 2 no se
recomienda utilizarlos al no incluir mucha diferencia con respecto al 3).
También se puede utilizar los siguientes valores: Extra Small, Small, Medium, Large,
Extra Large. Como el método se basa en la comparación de historias de usuario ya
realizadas se necesita contar con una línea base de historias realizadas por el
equipo.
Aspectos a tomar en cuenta:
Puntos de Historia no miden horas
La complejidad de las historias, los puntos de historia, no se pueden comparar a
horas de esfuerzo ya que el sentido que tienen es catalogar la dificultad de la tarea.
El número de horas que nos lleve realizarlas dependerá de la capacitación y/o
capacidad de la persona que la lleve a cabo, la carga de trabajo del equipo, etc. y
por ello variará dicho valor dependiendo de la situación.
Medida propia de un sólo Equipo
El principal problema que supone la utilización de los puntos de historia es que son
relativos a cada equipo de desarrollo y por ello no podemos comparar los puntos de
historia medidos por un equipo con los de otros equipos ya que la utilización de los
valores puede ser diferente. Es más, tampoco podemos hacer comparaciones de la
velocidad de desarrollo de cada uno de los equipos por el número de puntos de
historia que hayan implementado ya que podemos estar comparando naranjas con
manzanas.
Planificación Ágil
En una planificación siguiendo metodología ágil, se seleccionan cuantos puntos de
historia se podrán entregar en la siguiente iteración, es decir cuántas historias de
usuario se podrán implementar en función de la productividad del equipo, de la
carga de trabajo y del resto de factores ambientales. Con ello las tareas de
planificación se simplifican y se logran valores bastantes más cercanos a la realidad.

14
Beneficios de estimar en puntos de historia
 Es mucho más sencillo estimar comparando tamaños que estimar el tiempo
que vas a tardar. En consecuencia, las sesiones de estimación acaban antes
(mucho antes si utilizas técnicas como la estimación por afinidad).
 Tienes una evolución de la mejora en el equipo. Si estimas tamaño las
estimaciones se mantienen, aunque el equipo mejore su rendimiento. Si
estimas en tiempo directamente esa medida no la tendrás.
 Elimina el factor optimista de la mayoría de seres humanos (véase falacia de
la planificación y ley de Hofstadter)
 Es más fácil estimar en grupo. Si tienes un equipo heterogéneo con distintos
grados de madurez y experiencia, probablemente haya personas que tarden
más que otras en hacer lo mismo. Estimando el tamaño, llegarás antes a un
consenso.
 También es más fácil porque no tendrás que especular el tiempo que dedicas
a reuniones, interrupciones, contratiempos, etc.

15
7. Planificación de las iteraciones
La planificación de las tareas a realizar en la iteración se divide en dos partes:

Primera parte de la reunión. Se realiza en un time box de cómo máximo 4 horas*:

 El cliente presenta al equipo la lista de requisitos priorizada del producto o


proyecto, pone nombre a la meta de la iteración (de manera que ayude a
tomar decisiones durante su ejecución) y propone los requisitos más
prioritarios a desarrollar en ella.
 El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade
más condiciones de satisfacción y selecciona los objetivos/requisitos más
prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita.

Segunda parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas *:


El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor
resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado
que ha adquirido un compromiso, es el responsable de organizar su trabajo y es
quien mejor conoce cómo realizarlo.
 Define las tareas necesarias para poder completar cada objetivo/requisito,
creando la lista de tareas de la iteración (Sprint Backlog) basándose en la
definición de hecho.
 Realiza una estimación conjunta del esfuerzo necesario para realizar cada
tarea.
 Cada miembro del equipo se auto asigna a las tareas que puede realizar.

* Estos son tiempos máximos en el caso de iteraciones mensuales. En iteraciones


de tamaño menor el tiempo es proporcionalmente inferior, y se puede ir reduciendo
conforme el equipo va ganando experiencia en este tipo de reuniones, aunque
también dependerá de la complejidad a desarrollar en la iteración.
Beneficios de planear las iteraciones
Productividad mediante comunicación y creación de sinergias:
 Todos los miembros del equipo tienen una misma visión del objetivo y se ha
utilizado los conocimientos y las experiencias de todos para elaborar la mejor
solución entregable en el mínimo tiempo y con el mínimo esfuerzo,
eliminando tareas innecesarias, detectando conflictos y dependencias entre
tareas, etc.
Una estimación conjunta es más fiable:
 Dado que tiene en cuenta los diferentes conocimientos, experiencia y
habilidades de los integrantes del equipo.

16
Potenciación del compromiso del equipo sobre el objetivo común de la
iteración:
 Es todo el equipo quien asume la responsabilidad de completar en la iteración
los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se
detecta algún impedimento que bloquea el progreso de la iteración,
especialmente si cuando se está llegando al final de la iteración es necesaria
la participación de todos para poder completar los objetivos comprometidos.
 Es cada una de las personas la que se responsabiliza de realizar sus tareas
(a las que se auto asignó) en los tiempos que proporcionó. Si existe falta de
compromiso con respecto al resto de miembros del equipo se hará muy
evidente en las reuniones diarias de sincronización del equipo (Scrum daily
meeting).

17
8. Sesiones de diseño rápido
Se trata de reuniones en las cuales el equipo y el cliente definen aspectos gráficos
que quieran ser implementados o sustituido dentro del sistema o aplicación tratando
de minimizar el recurso de tiempo y de no prolongar otras iteraciones.
Pero como todos sabemos muchas veces de una reunión de diseño rápido no sale
toda la colaboración ni se saca toda la productividad que uno desearía. Esto sucede
por diversos factores: miembros de la reunión que la acaparan; temas menores que
atascan la productividad; un ambiente inadecuado e incómodo, etc.
Para que esto no ocurra hay que cuidar la calidad de la experiencia de todos los
participantes, desde el stakeholder más valioso al trabajador que se siente poco
valorado en la empresa. Necesitamos que se encuentren cómodos y en un ambiente
acogedor para que den el máximo de sí mismos y consigamos una reunión de
diseño eficaz donde todas las personas se sientan valoradas y escuchadas.
Pautas para aprovechar una sesión de diseño rápido
Cuatro pautas para que una sesión de diseño rápido sea eficaz y se mejore la
calidad de la experiencia de todos los participantes en ella:
1. Demuestra empatía: un buen moderador de reuniones de diseño tiene que
tener empatía con los participantes. Observa, escucha, responde
cortésmente a las preguntas y evita distracciones y la multitarea, es decir,
deja el móvil y el ordenador a un lado durante el tiempo que dure la reunión
de diseño y pon todas tus energías en ella.
2. Gestiona y lleva la conversación durante la reunión: es bueno que pidas
permiso para conducir la reunión y que marques algunas reglas para evitar
distracciones y alargar el tiempo (se supone que tratamos de ahorrarlo):
 evita el uso de tecnología, a menos que sea necesario para
hablar de un tema
 evita cualquier conducta que distraiga (verbal o no verbal)
 escuchar y respeta a la gente cuando hable
3. Dedica tiempo a temas específicos para fomentar la participación: esto
significa que la reunión debe tener pocos temas y más tiempo para dedicarse
a cada uno de ellos.
4. Conecta con la gente en momentos específicos: recomienda comenzar la
reunión preguntando a la gente si alguien tiene alguna duda sobre la reunión,
que deberá responderse adecuadamente antes de comenzar (eso nos
evitará retrasos de tiempo).

18
9. Manejo de defectos
Tiene como objetivo manejar los posibles defectos detectados durante la ejecución
de los servicios de testing acordados. Se entiende por defecto, cualquier error o
carencia en los productos (software y documentación) en su fase de desarrollo.
La formalización de los defectos incluye el conjunto de actividades encaminadas a
registrar, clasificar y asignar los defectos al responsable correspondiente para su
posterior resolución, evitando situaciones de bloqueo que impidan la ejecución de
los servicios acordados. Para llevar un control, se registrarán todos los defectos en
una herramienta para la gestión de defectos.

Tipos de defectos:
 Defectos bloqueantes: Son aquellos defectos, detectados durante la
ejecución de alguno de los servicios, que impiden continuar con su ejecución
de forma total o parcial.
 Defectos no bloqueantes: Son aquellos defectos detectados durante la
ejecución de los servicios, pero que no impiden su ejecución. Dichos defectos
serán asignados inicialmente al Gestor de Proyecto correspondiente, para
que evalúe si realmente se trata de defectos como tal y por tanto requieren
ser resueltos por el Equipo de Proyecto, o si, por el contrario, no deben
considerarse como defectos, y deben ser desestimados.
Por otro lado, se llama subsanación a la acción de corregir un defecto del producto
(software y documentación) dentro de la propia ejecución del servicio, por parte del
equipo de desarrollo. La subsanación del defecto permite:
 Continuar con la ejecución del servicio, en el caso de que sea un defecto
bloqueante.
 Mejorar la calidad del producto entregado de una forma dinámica.
Las subsanaciones de defectos siempre van a ser posibles dentro de ciertos límites
que garanticen el cumplimiento de las planificaciones de ejecución del servicio y
que la ejecución del servicio no se vea desvirtuada por la detección de defectos
bloqueantes de manera ilimitada. Existen dos tipos de subsanaciones:
 Las subsanaciones que implican la modificación de las fuentes del aplicativo.
 Las subsanaciones que no implican la modificación de las fuentes del
aplicativo (normalmente son subsanaciones sobre la documentación).

19
Diagrama de procedimiento

Ilustración 4. Diagrama de procedimiento para manejar defectos

20
Detalle de las actividades

21
22
23
24
Conclusión
Como pudimos conocer durante este trabajo de investigación, la implantación de la
metodología XP (extreme programming) en un equipo de desarrollo es un proceso
que constituye de conocer ciertos puntos que se deben aplica correctamente a lo
largo del desarrollo de un producto de software. Todos estos punto o actividades
son de importancia pues son fundamentales para gestionar el tiempo y que elm
proyecto se desarrolle lo mejor posible.
Hemos identificado cuáles son los roles de las personas dentro de un equipo que
desarrolla en XP, y que la mejor manera de llevar a cabo el levantamiento de
requisitos y necesidades de un cliente es mediante el uso de historias de usuario y
en esta misma investigación nos ha ofrecido el conocimiento para llevar a cabo una
y como debemos estructurarlas, también fueron explicados cuales son los puntos a
tomar en cuenta y como realizar pruebas de aceptación, y como no solo basta con
tener historias de usuario de nuestro cliente a disposición sino que debemos
aprender a priorizar la historias de usuario en pos de clasificarlas en tareas de mayor
o menor peso, a como planear en equipo y bajo las necesidades del cliente las
iteraciones que se implementaran en el proyecto, y de igual manera a realizar
reuniones de diseño rápido que permiten ahorra tiempo en el aspecto del desarrollo
grafico del software y finalmente también se ha proporcionado información sobre el
tratamiento de los defectos en el producto y como tratarlos.
En mi conclusión final y personal, considero que el haber realizado este proyecto de
investigación ha resultado fructífero para la adquisición de conocimientos y que es
una manera más sencilla de comprender correctamente los puntos que se tratan a
la hora de implementar XP, de esta manera la información recopilada se ha filtrado
y se ha presentado de manera amena para el lector en pos de que surta el mismo
efecto de compresión sencilla en ellos. Y que al igual que a su servidor permita el
interés por el tema en cuestion y en el desarrollo mediante Xtreme Programming.

25
Referencias

https://iswugaps2extremeprogramming.wordpress.com/2015/09/14/roles/

https://sites.google.com/site/xpmetodologia/marco-teorico/roles

https://www.slideshare.net/MiquelMora/historias-de-usuario#!

http://www.pmoinformatica.com/2013/04/que-son-las-historias-de-usuario-7.html

https://proyectosagiles.org/2009/06/08/introduccion-estimacion-planificacion-agil/

https://samuelcasanova.com/2017/04/puntos-historia-en-agile/

http://programacionextrema.tripod.com/fases.htm#primeraFase

https://proyectosagiles.org/planificacion-iteracion-sprint-planning/

https://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf

26