Programación extrema

Lanzamiento de la aplicación

2

Lanzamiento de la planificación

En XP, una aplicación o sistema es desarrollado en el contexto del proyecto Un proyecto define todas las características de la

aplicación o sistema El lanzamiento de la planificación es el inicio de cada

proyecto. En XP, un proyecto es divido en unas o más lanzamientos

Cada lanzamiento debe tener suficiente características para dar valor al negocio

Un lanzamiento representa una colección de las userstories que proporciona las características

3

Lanzamiento de la planificación…

Si la colección de user stories en el lanzamiento es un subconjunto de las historias totales de usuario para todo el proyecto, entonces el proyecto tendrá liberaciones múltiples. El intervalo entre lanzamientos normalmente es de 30 a

180 días Sólo el lanzamiento actual es planeado reconociendo los

cambios que pueden ocurrir en el proyecto. Es posible que un cambio de negocio podría ser

significativo para invalidar cualquier plan de lanzamientos futuros.

El lanzamiento de la planificación supone dos fases: exploración y el juego de planificación

4

La fase de exploración

La fase de exploración del lanzamiento de la planificación es donde el análisis, los requerimientos se obtienen y el diseño inicial ocurre.

El objetivo de la fase de exploración es conseguir un entendimiento de alto nivel de lo que el cliente requiere y asocia estos con un coste de desarrollo. Esta fase debe durar de unos cuantos días a una semana

Todas las actividades en esta fase se conservan en alto nivel, incluyendo los requerimientos y diseño Las necesidades se detallan en la iteración de la planificación

El diseño evoluciona tanto como el proyecto evoluciona, con la información que es reunida a lo largo del proceso Para la fase de exploración, sólo se necesita saber lo bastante para

ser capaz de dar las estimaciones

5

La fase de exploración…

En una liberación, el equipo entregara código listo para producción en ciclos más cortos, llamados iteraciones.

Las iteraciones permiten a un equipo dividir una liberación en los trozos más manejables

Las iteraciones deben tener una longitud de dos semanas (esta es una buena longitud de iteración)

6

La fase de exploración…

El cliente definirá necesidades como historias de usuario Estas historias de usuario serán breves, las

cuales acortarán el tiempo para definir todas las características del sistema

Al mantener historias a alto nivel, el equipo puede cubrir muchas historias de usuario en una cantidad corta del tiempo

El resultado de la fase de exploración es una colección de requerimientos a alto nivel capturado como historias de usuario

7

Escribiendo historias de usuario

¿Una historia de usuario es groseramente equivalente a un requerimiento, cual es su diferencia? ¿Las historias de usuario son breves, pero qué significa? Una historia de usuario es tan corta que se ajusta a una tarjeta índice

Las tarjetas son muy táctiles. Se pueden escoger una característica, remover una característica, rotar y dividirla cuando no es de la longitud apropiada

El tamaño de las tarjetas es de 3”x 5” Las tarjetas permiten priorizar las historias de usuario de 1 al n

La tarjeta de historia de usuario tiene un título y unas cuantas oraciones que describen la historia de usuario Las pocas oraciones que se describen en la historia de usuario e sirven de

un recordatorio al cliente sobre el propósito de la historia A menudo se dice que una historia de usuario es una promesa “de una

conversación futura.” Cada historia de usuario contiene uno y sólo una característica del negocio

Componentes de una historia de usuario

9

Componentes de una historia de usuario

La escritura de una historia en contraste con el enfoque tradicional, donde cada requerimiento es escrito en detalle con esmero.

Los requerimientos tradicionales intencionalmente usan verbos a fin de completar los requerimientos

Este nivel del detalle es necesario porque el cliente no esté normalmente disponible para interpretar el requerimiento Muchos principiantes en XP se preocupan que los detalles de las historias

de usuario se pierdan sino se capturan completamente Este miedo se puede superar cuando se comprende que existe muchos

individuos están envuelto en esta fase, es decir todo en el equipo de XP. La probabilidad que olvide todo un detalle importante es mínimo

Además, no existe ninguna regla que prohíbe a las personas tomar notas para recordar la información que ellos sienten que es importante

Es importante recordar es que cada historia de usuario se volverá a visitar de nuevo en la iteración del que forma parte Durante esa iteración, los detalles de la historia de usuario serán

recordados de nuevo si es necesario.

10

¿Quién escribe la historia de usuario?

Todas las historias de usuario están escritas por el cliente El cliente es el responsable de interpretar la historia de usuario El cliente escribe las historias de usuario usando los términos que

entienden Una parte del análisis del proyecto se da cuando se crean las historias de

usuario El cliente empieza describiendo cierta característica del sistema Los demás empiezan hacer preguntas para asegurarse que comprenden lo

que se está pidiendo ¿Qué ocurriría si un cliente ya tiene un conjunto de requerimientos? ¿El cliente

necesita crear las historias de usuario? Sí! El cliente puede crear historias de usuario candidatas de los

requerimientos existentes Entonces la historia de usuario candidata se debe leer a todo el equipo

de XP para determinar si son historias de usuario verdaderamente válidas

11

¿Qué hacen historia de usuario válida?

Durante creación de historia, dos preguntas son consideradas para cada historia de usuario: ¿Los desarrolladores pueden estimar la historia

de usuario? ¿Los probadores de aceptación son capaces de

probar la historia de usuario? Si uno de estos grupos contesta “no”, entonces la

historia de usuario no es bien definida.

12

¿Qué hacen historia de usuario válida?

A veces, los desarrolladores pueden decir que no saben si pueden estimar la historia de usuario. Esto puede ser el caso si los desarrolladores son ignorantes del

aspecto de la tecnología que ellos se proponen usar o del campo de negocio en que están trabajando. En estos casos, los desarrolladores dirán el cliente que ellos

necesitarán “spike” par la historia de usuario. El propósito del “spike” es dar a los desarrolladores cierto nivel de la

comprensión de lo implementará en una historia de usuario. Los desarrolladores generalmente dejan de hablar con el resto del

equipo e investigan el requerimiento. Los desarrolladores deberían tratar de encontrar expertos que les

ayuden a comprender la solución. Por regla general, el “spike” no debe tomar más de un día o dos

para investigar.

Ejemplos de historias de usuario

Tiene un título, una descripción corta, tiene sólo una característica; pero esta historia de usuario es demasiado vaga. Los desarrolladores encontrarán que es difícil estimar y los probadores que no es posible probarlo.

Una historia de usuario que es demasiada vaga

Tiene la forma apropiada. Esta limitado a una característica del negocio. El problema es que define detalles de implementación. ¿Qué razón o ventaja hacen que la historia de usuario defina el uso de Dreamweaver y TomCat? ¿El cliente realmente está seguro? Probablemente no.

Una historia de usuario con muchos detalles

Tiene buen formato. ¿Es estimable y se puede probar? Sí!

Una historia de usuario aceptable

¿Es una buena historia? Desafortunadamente, esta historia de usuario tiene más de una característica de negocio: funcionalidad de búsqueda y selección

Una historia de usuario con muchas características

La solución al problema con la historia anterior es preguntar al cliente para partir la historia de usuario y crea dos nuevas historias, con cada característica en una tarjeta diferente.

Esta historia de usuario es para la característica de búsqueda.

Una historia de usuario resultado de dividir

Una historia de usuario con suficiente información

20

Una historia de usuario con suficiente información

Muestra la otra historia de usuario que se enfoca en capturar la información sobre el comprador

Note que no se lista todos los datos que espera reunirse. Recuerde que una historia de usuario es breve es breve y promete una conversación futura

Cuando los desarrolladores implementan esta historia de usuario, ellos pueden conseguir todas las especificaciones en ese momento

Si la cantidad de detalle de la historia de usuario es adecuada para estimar y probar, esto es todo lo que se necesita

Una historia de usuario que es candidato a spike

22

Una historia de usuario que es candidato a spike

¿Vea si pueda determinar qué tiene de malo la historia de usuario? ¿Qué conoce de la impresora de etiquetas de embalaje? Probablemente no sabe mucho sobre ello.

Necesitar interactuar con el impresor o impresora.

Esta historia de usuario es un candidato para “spike”

23

Estimando historias de usuario

La historia de usuario es estimado colectivamente por los desarrolladores del equipo Todas las estimaciones están en días ideales y

mencionado como puntos de historia

¿Alguna vez ha visto que un cerdo vuela? ¿Qué piensa si nunca tiene que ir a otra reunión, contestar el teléfono, enviar un correo electrónico, o es interrumpido de ninguna forma? ¿Qué ocurriría si sólo tiene que escribir código? Eso es un día ideal

¿Alguna vez tuvo uno? Probablemente no y nunca lo tendrá ¿Y porque estimamos en días ideales?

No se puede predecir todas las cosas que nos “`robaran” tiempo durante un día

La velocidad del equipo y la individual, se ajusta a la cantidad media de actividades que robarán tiempo de cada miembro del equipo

Si en la realidad tiene menos distracciones que el promedio, entonces terminara su trabajo temprano y será capaz de realizar más de trabajo. Su velocidad subirá como consecuencia

Si en la realidad se tiene más distracciones que el promedio, lo opuesto le sucederá

¿Qué es un día ideal?

25

¿Por qué estimar en términos de puntos de historia?

Las estimaciones están en puntos de historia porque no se quiere perturbar emocionalmente en días y horas Un punto de historia es equivalente a un día

ideal. Cuando se en términos de puntos de historia, sólo

son puntos ni más ni Los desarrolladores colectivamente hacen las

estimaciones porque ninguno de ellos sabe con que historia de usuario trabajara, así que es importante que todos coincidan

The Planning Game

La planificación

27

The Planning Game

El planning game es la fase cuando los clientes van de compras

Los clientes tienen que definir las características que necesitan, en forma de historias de usuarios

Los desarrolladores tienen que asignar un costo a cada historia de usuario

Es el momento de seleccionar las historias a entregar.

28

Priorización de la historias

Los clientes priorizan las historias de usuario.

La prioridad es de 1 a n No se priorizan como alto, medio o bajo

porque para la mayoría de los clientes la priorizan como alto

29

Determinación de la velocidad

Una vez que todas las historias de usuario están priorizadas, se necesita decidir cuántos de estas historias se pueden completar. Para hacer esto, se determina la velocidad del equipo

El rastreador del equipo determina la velocidad del equipo basada en la fecha de liberación y el número de recursos de desarrollo a tiempo completo asignado al proyecto También se puede usar recursos de desarrollo por horas

y su velocidad asociada, pero la mayoría de los recursos de desarrollo deben ser a tiempo completo

Los recursos por horas pueden ser impredecibles porque sus prioridades están divididos y a menudo en conflicto con los resultados

La velocidad del equipo es producto de la historia del equipo Los miembros del equipo que completaron satisfactoriamente la liberación

son lo que llegan a firmar un contrato por este lanzamiento Este valor es representado como el número puntos de historias que el

equipo puede firmaren un contrato en un lanzamiento Si el equipo no tiene historia o ciertos miembros de equipo no tienen historia,

puede calcular la velocidad inicial del equipo. Para hacer esto, el primero calcula la velocidad de una iteración sencilla con esta fórmula: (No.Desarrolladores/FactorCarga X

LongitudIteraciónDiaNegocio)(truncado)= VelocidadIteraciónEquipo Por ejemplo, para 8 desarrolladores con dos semanas de iteración, el

cálculo es el siguiente: (8/4 X 10) (Truncado) = 20 En este ejemplo el número de desarrolladores en el proyecto se

divide por 4. El 4 es el factor de carga, el tiempo que los desarrolladores gastan tiempo fuera de la codificación (tales como reuniones, comunicación por correo electrónico, programación por pares y otras)

La longitud de la iteración está en días laborables

Determinación de la velocidad…

31

Determinación de la velocidad…

Para obtener la velocidad de liberación del equipo, multiplique la velocidad de iteración y por el número de iteraciones se propone tener en su liberación No incluya ninguna iteración que no tenga codificación de desarrollo, tal

como una iteración para probar o preparar sólo el desarrollo del entorno. La formula es: No.DesarrolloIteracionesLanzamiento X VelocidadIteraciónEquipo =

VelocidadLliberaciónEquipo Usando el cálculo previo de 20 días ideales como velocidad iteración del

equipo, para seis iteraciones de desarrollo, la velocidad de liberación para el equipo es: 6x20 = 120 días ideales

No equivoque velocidad como un indicador de cuán rápido un equipo completara el trabajo La velocidad es una herramienta de estimación usado para ayudar al

equipo e individuos a refinar sus estimaciones y aparearlos con la realidad La velocidad de un equipo no debe ser usada para comparar dos o más

equipos o individuos

En este punto, cada historia de usuario tiene declarado los números de los puntos de historia, y el equipo de desarrollo ha declarado los números de puntos de historia que el equipo puede completar en una lanzamiento Ahora el cliente necesita escoger una colección de las

historias de usuario que no exceda el número total de puntos de historia

Los clientes a menudo comienzan seleccionado sus historias de usuario con prioridad más altas, pero no están limitados a este método de selección

En realidad, tratan de balancear el número de puntos de historia para la liberación, ellos necesitarán escoger ciertas historias de usuario que tienen menores puntos de historia y baja prioridad

Selección de historias de usuario

33

Lanzamiento del plan

El resultado del lanzamiento de la planificación es lanzamiento del plan que consiste en un conjunto de historias de usuario que tiene los puntos de historia asociados con ellos

Dada la información, los clientes deben ser capaz de determinar si quieren proseguir con el proyecto o no

El mayor beneficio del punto de lanzamiento del proyecto es que se tiene que llegar a una conclusión aproximadamente una semana

En el enfoque tradicional de desarrollo de software, deberían comenzar con la fase de análisis. XP reduce costos para el cliente