Lanzamiento de la aplicacin

Programacin extrema

Lanzamiento de la planificacin

En XP, una aplicacin o sistema es desarrollado en el contexto del proyecto Un proyecto define todas las caractersticas de la aplicacin o sistema El lanzamiento de la planificacin es el inicio de cada proyecto. En XP, un proyecto es divido en unas o ms lanzamientos Cada lanzamiento debe tener suficiente caractersticas para dar valor al negocio Un lanzamiento representa una coleccin de las user stories que proporciona las caractersticas

Lanzamiento de la planificacin

Si la coleccin de user stories en el lanzamiento es un subconjunto de las historias totales de usuario para todo el proyecto, entonces el proyecto tendr liberaciones mltiples. El intervalo entre lanzamientos normalmente es de 30 a 180 das Slo el lanzamiento actual es planeado reconociendo los cambios que pueden ocurrir en el proyecto. Es posible que un cambio de negocio podra ser significativo para invalidar cualquier plan de lanzamientos futuros. El lanzamiento de la planificacin supone dos fases: exploracin y el juego de planificacin
3

La fase de exploracin

La fase de exploracin del lanzamiento de la planificacin es donde el anlisis, los requerimientos se obtienen y el diseo inicial ocurre. El objetivo de la fase de exploracin 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 das a una semana Todas las actividades en esta fase se conservan en alto nivel, incluyendo los requerimientos y diseo Las necesidades se detallan en la iteracin de la planificacin El diseo evoluciona tanto como el proyecto evoluciona, con la informacin que es reunida a lo largo del proceso Para la fase de exploracin, slo se necesita saber lo bastante para ser capaz de dar las estimaciones

La fase de exploracin
En una liberacin, el equipo entregara cdigo listo para produccin en ciclos ms cortos, llamados iteraciones. Las iteraciones permiten a un equipo dividir una liberacin en los trozos ms manejables Las iteraciones deben tener una longitud de dos semanas (esta es una buena longitud de iteracin)

La fase de exploracin

El cliente definir necesidades como historias de usuario

Estas historias de usuario sern breves, las cuales acortarn el tiempo para definir todas las caractersticas 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 exploracin es una coleccin de requerimientos a alto nivel capturado como historias de usuario
6

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 tctiles. Se pueden escoger una caracterstica, remover una caracterstica, rotar y dividirla cuando no es de la longitud apropiada El tamao de las tarjetas es de 3x 5 Las tarjetas permiten priorizar las historias de usuario de 1 al n La tarjeta de historia de usuario tiene un ttulo 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 propsito de la historia A menudo se dice que una historia de usuario es una promesa de una conversacin futura. Cada historia de usuario contiene uno y slo una caracterstica del negocio

Componentes de una historia de usuario

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 estn envuelto en esta fase, es decir todo en el equipo de XP. La probabilidad que olvide todo un detalle importante es mnimo Adems, no existe ninguna regla que prohbe a las personas tomar notas para recordar la informacin que ellos sienten que es importante Es importante recordar es que cada historia de usuario se volver a visitar de nuevo en la iteracin del que forma parte Durante esa iteracin, los detalles de la historia de usuario sern recordados de nuevo si es necesario.
9

Quin escribe la historia de usuario?

Todas las historias de usuario estn escritas por el cliente El cliente es el responsable de interpretar la historia de usuario El cliente escribe las historias de usuario usando los trminos que entienden Una parte del anlisis del proyecto se da cuando se crean las historias de usuario El cliente empieza describiendo cierta caracterstica del sistema Los dems empiezan hacer preguntas para asegurarse que comprenden lo que se est pidiendo Qu ocurrira 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 vlidas
10

Qu hacen historia de usuario vlida?

Durante creacin de historia, dos preguntas son consideradas para cada historia de usuario:
Los desarrolladores pueden estimar la historia de usuario? Los probadores de aceptacin son capaces de probar la historia de usuario?

Si uno de estos grupos contesta no, entonces la historia de usuario no es bien definida.

11

Qu hacen historia de usuario vlida?

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 tecnologa que ellos se proponen usar o del campo de negocio en que estn trabajando. En estos casos, los desarrolladores dirn el cliente que ellos necesitarn spike par la historia de usuario. El propsito del spike es dar a los desarrolladores cierto nivel de la comprensin 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 deberan tratar de encontrar expertos que les ayuden a comprender la solucin. Por regla general, el spike no debe tomar ms de un da o dos para investigar.
12

Ejemplos de historias de usuario

Una historia de usuario que es demasiada vaga

Tiene un ttulo, una descripcin corta, tiene slo una caracterstica; pero esta historia de usuario es demasiado vaga. Los desarrolladores encontrarn que es difcil estimar y los probadores que no es posible probarlo.

Una historia de usuario con muchos detalles

Tiene la forma apropiada. Esta limitado a una caracterstica del negocio. El problema es que define detalles de implementacin. Qu razn 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 aceptable

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

Una historia de usuario con muchas caractersticas

Es una buena historia? Desafortunadamente, esta historia de usuario tiene ms de una caracterstica de negocio: funcionalidad de bsqueda y seleccin

Una historia de usuario resultado de dividir

La solucin al problema con la historia anterior es preguntar al cliente para partir la historia de usuario y crea dos nuevas historias, con cada caracterstica en una tarjeta diferente. Esta historia de usuario es para la caracterstica de bsqueda.

Una historia de usuario con suficiente informacin

Una historia de usuario con suficiente informacin

Muestra la otra historia de usuario que se enfoca en capturar la informacin 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 conversacin 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

20

Una historia de usuario que es candidato a spike

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

22

Estimando historias de usuario

La historia de usuario es estimado colectivamente por los desarrolladores del equipo

Todas las estimaciones estn en das ideales y mencionado como puntos de historia

23

Qu es un da ideal?

Alguna vez ha visto que un cerdo vuela? Qu piensa si nunca tiene que ir a otra reunin, contestar el telfono, enviar un correo electrnico, o es interrumpido de ninguna forma? Qu ocurrira si slo tiene que escribir cdigo? Eso es un da ideal Alguna vez tuvo uno? Probablemente no y nunca lo tendr Y porque estimamos en das ideales? No se puede predecir todas las cosas que nos `robaran tiempo durante un da La velocidad del equipo y la individual, se ajusta a la cantidad media de actividades que robarn 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 ms de trabajo. Su velocidad subir como consecuencia Si en la realidad se tiene ms distracciones que el promedio, lo opuesto le suceder

Por qu estimar en trminos de puntos de historia?

Las estimaciones estn en puntos de historia porque no se quiere perturbar emocionalmente en das y horas

Un punto de historia es equivalente a un da ideal.

Cuando se en trminos de puntos de historia, slo son puntos ni ms 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
25

La planificacin

The Planning Game

The Planning Game

El planning game es la fase cuando los clientes van de compras Los clientes tienen que definir las caractersticas 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.

27

Priorizacin 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 mayora de los clientes la priorizan como alto

28

Determinacin de la velocidad

Una vez que todas las historias de usuario estn priorizadas, se necesita decidir cuntos 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 liberacin y el nmero de recursos de desarrollo a tiempo completo asignado al proyecto Tambin se puede usar recursos de desarrollo por horas y su velocidad asociada, pero la mayora de los recursos de desarrollo deben ser a tiempo completo Los recursos por horas pueden ser impredecibles porque sus prioridades estn divididos y a menudo en conflicto con los resultados
29

Determinacin de la velocidad

La velocidad del equipo es producto de la historia del equipo Los miembros del equipo que completaron satisfactoriamente la liberacin son lo que llegan a firmar un contrato por este lanzamiento Este valor es representado como el nmero 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 iteracin sencilla con esta frmula: (No.Desarrolladores/FactorCarga X LongitudIteracinDiaNegocio)(truncado)= VelocidadIteracinEquipo Por ejemplo, para 8 desarrolladores con dos semanas de iteracin, el clculo es el siguiente: (8/4 X 10) (Truncado) = 20 En este ejemplo el nmero 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 codificacin (tales como reuniones, comunicacin por correo electrnico, programacin por pares y otras) La longitud de la iteracin est en das laborables

Determinacin de la velocidad

Para obtener la velocidad de liberacin del equipo, multiplique la velocidad de iteracin y por el nmero de iteraciones se propone tener en su liberacin No incluya ninguna iteracin que no tenga codificacin de desarrollo, tal como una iteracin para probar o preparar slo el desarrollo del entorno. La formula es: No.DesarrolloIteracionesLanzamiento X VelocidadIteracinEquipo = VelocidadLliberacinEquipo Usando el clculo previo de 20 das ideales como velocidad iteracin del equipo, para seis iteraciones de desarrollo, la velocidad de liberacin para el equipo es: 6x20 = 120 das ideales No equivoque velocidad como un indicador de cun rpido un equipo completara el trabajo La velocidad es una herramienta de estimacin 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 ms equipos o individuos

31

Seleccin de historias de usuario

En este punto, cada historia de usuario tiene declarado los nmeros de los puntos de historia, y el equipo de desarrollo ha declarado los nmeros de puntos de historia que el equipo puede completar en una lanzamiento Ahora el cliente necesita escoger una coleccin de las historias de usuario que no exceda el nmero total de puntos de historia Los clientes a menudo comienzan seleccionado sus historias de usuario con prioridad ms altas, pero no estn limitados a este mtodo de seleccin En realidad, tratan de balancear el nmero de puntos de historia para la liberacin, ellos necesitarn escoger ciertas historias de usuario que tienen menores puntos de historia y baja prioridad

Lanzamiento del plan

El resultado del lanzamiento de la planificacin es lanzamiento del plan que consiste en un conjunto de historias de usuario que tiene los puntos de historia asociados con ellos Dada la informacin, 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 conclusin aproximadamente una semana En el enfoque tradicional de desarrollo de software, deberan comenzar con la fase de anlisis. XP reduce costos para el cliente
33