Post on 08-Feb-2016
description
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