agile

Vista previa del material en texto

Contenido 
 
Ágil - Inicio 
Ágil - Primer 
Ágil - Manifiesto 
Ágil - Características 
Ágil - Standup diario 
Ágil - Definición de Hecho 
Ágil - Planificación de lanzamiento 
Ágil - Planificación de iteraciones 
Agile: cartera de productos 
Ágil - Términos útiles 
 
 
 
 
 
 
 
 
 
 
Ágil - Primer 
Agile es una metodología de desarrollo de software para construir un software 
de manera incremental usando iteraciones cortas de 1 a 4 semanas para que 
el proceso de desarrollo esté alineado con las necesidades cambiantes del 
negocio. En lugar de un desarrollo de un solo paso de 6 a 18 meses donde 
todos los requisitos y riesgos se predicen por adelantado, Agile adopta un 
proceso de retroalimentación frecuente en el que se entrega un producto 
viable después de una iteración de 1 a 4 semanas. 
 
Roles en ágil 
Scrum Master 
Un Scrum Master es un líder y facilitador del equipo que ayuda a los miembros 
del equipo a seguir prácticas ágiles para que puedan cumplir con sus 
compromisos. Las responsabilidades de un scrum master son las siguientes: 
 Para permitir una estrecha cooperación entre todos los roles y funciones. 
 Para eliminar cualquier bloque. 
 Para proteger al equipo de cualquier perturbación. 
 Trabajar con la organización para seguir el progreso y los procesos de la empresa. 
 Para garantizar que los procesos Agile Inspect & Adapt se aprovechen 
correctamente, lo que incluye 
o Stand-ups diarios, 
o Reuniones planificadas, 
o Manifestación, 
o Revisión, 
o Reuniones retrospectivas, y 
o Para facilitar las reuniones del equipo y el proceso de toma de decisiones. 
Dueño del producto 
Un propietario del producto es el que conduce el producto desde la 
perspectiva empresarial. Las responsabilidades o el propietario del producto 
son las siguientes: 
 Definir los requisitos y priorizar sus valores. 
 Para determinar la fecha de lanzamiento y los contenidos. 
 Asumir un papel activo en la planificación de iteraciones y en las reuniones de 
planificación de lanzamiento. 
 Para garantizar que el equipo esté trabajando en el requisito más valioso. 
 Representar la voz del cliente. 
 Aceptar las historias de usuarios que cumplen con la definición de criterios de 
aceptación definidos y realizados. 
Equipo multidisciplinar 
Cada equipo ágil debe ser un equipo autosuficiente con 5 a 9 miembros y una 
experiencia promedio de 6 a 10 años. Por lo general, un equipo ágil consta de 
3 a 4 desarrolladores, 1 probador, 1 líder técnico, 1 propietario del producto y 
1 scrum master. 
 
El propietario del producto y el Scrum Master se consideran parte de Team 
Interface, mientras que otros miembros son parte de Technical Interface. 
 
 
 
www.postparaprogramadores.com
/ 
 
http://www.postparaprogramadores.com/
http://www.postparaprogramadores.com/
¿Cómo un equipo ágil planifica su trabajo? 
Un equipo ágil trabaja en iteraciones para entregar historias de usuarios donde 
cada iteración es de 10 a 15 días. Cada historia de usuario se planifica en 
función de su prioridad y tamaño de la cartera de pedidos. El equipo usa su 
capacidad (cuántas horas están disponibles con el equipo para trabajar en las 
tareas) para decidir cuánto alcance tienen que planificar. 
 
Punto 
Un punto define cuánto puede comprometerse un equipo. Un punto 
generalmente se refiere a 8 horas. Cada historia se estima en puntos. 
Capacidad 
La capacidad define cuánto puede comprometerse un individuo. La capacidad 
se estima en horas. 
¿Qué es una historia de usuario? 
Una historia de usuario es un requisito que define lo que el usuario requiere 
como funcionalidad. Una historia de usuario puede tener dos formas: 
 Como <Rol de usuario> quiero <Funcionalidad> para que <Valor empresarial> 
 Para <Valor comercial> como <Rol de usuario> quiero <Funcionalidad> 
Durante la planificación del lanzamiento, se proporciona una estimación 
aproximada de una historia de usuario utilizando la escala relativa como 
puntos. Durante la planificación de la iteración, la historia se divide en tareas. 
Relación de historias de usuario y tareas 
 La historia del usuario habla sobre lo que se debe hacer. Define lo que un usuario 
necesita. 
 La tarea habla sobre cómo se debe hacer. Define cómo se implementará una 
funcionalidad. 
 Las historias son implementadas por tareas. Cada historia es una colección de 
tareas. 
 La historia del usuario se divide en tareas cuando se planifica en la iteración actual. 
 Las tareas se estiman en horas, generalmente de 2 a 12 horas. 
 Las historias se validan mediante pruebas de aceptación. 
 
Cuando se hace una historia 
El equipo decide qué significa hacer . Los criterios pueden ser: 
 Todas las tareas (desarrollo, prueba) se completan. 
 Todas las pruebas de aceptación se están ejecutando y se pasan. 
 Ningún defecto está abierto. 
 El dueño del producto ha aceptado la historia. 
 Se puede entregar al usuario final. 
¿Qué son los criterios de aceptación? 
Los criterios definen la funcionalidad, el comportamiento y el rendimiento 
requeridos por una característica para que el propietario del producto pueda 
aceptarla. Define lo que se debe hacer para que el desarrollador sepa cuándo 
se completa una historia de usuario. 
¿Cómo se definen los requisitos? 
Los requisitos se definen como 
 Una historia de usuario 
 Con criterios de aceptación, y 
 Tareas para implementar la historia. 
 
 
 
 
 
Ágil - Manifiesto 
En febrero de 2001, en el complejo de Snowbird en Utah, 17 desarrolladores 
de software se reunieron para discutir métodos de desarrollo livianos. El 
resultado de su reunión fue el siguiente Manifiesto Ágil para el desarrollo de 
software: 
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a 
otros a hacerlo. A través de este trabajo, hemos llegado a valorar: 
 Individuos e interacciones sobre procesos y herramientas 
 Software de trabajo sobre documentación completa 
 Colaboración del cliente sobre la negociación del contrato 
 Responde al cambio sobre el siguiente plan 
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos 
de la izquierda. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Síguenos en Instagram para que estés al tanto de los 
nuevos libros de programación. Click aqui 
 
 
https://www.instagram.com/ppprogramadores/
Doce principios del manifiesto ágil 
 Satisfacción del cliente : se da la máxima prioridad para satisfacer los requisitos 
de los clientes mediante la entrega temprana y continua de software valioso. 
 Cambio de bienvenida : los cambios son inevitables durante el desarrollo de 
software. Los requisitos siempre cambiantes deberían ser bienvenidos, incluso al 
final de la fase de desarrollo. Los procesos ágiles deberían funcionar para 
aumentar la ventaja competitiva de los clientes. 
 Entregue un software que funcione: entregue un software que funcione con 
frecuencia, desde unas pocas semanas hasta algunos meses, considerando una 
escala de tiempo más corta. 
 Colaboración : la gente de negocios y los desarrolladores deben trabajar juntos 
durante toda la vida de un proyecto. 
 Motivación : los proyectos deben construirse alrededor de individuos 
motivados. Proporcione un entorno para apoyar a los miembros individuales del 
equipo y confíe en ellos para que se sientan responsables de hacer el trabajo. 
 Conversación cara a cara: la conversación cara a cara es el método más 
eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro 
de él. 
 Mida el progreso según el software de trabajo: el software de trabajo es la clave 
y debería ser la medida principal del progreso. 
 Mantener un ritmo constante : los procesos ágiles apuntan hacia el desarrollo 
sostenible. El negocio, los desarrolladores y los usuarios deberían poder 
mantener un ritmo constante con el proyecto. 
 Monitoreo : preste atención regular a la excelencia técnica y al buen diseño paramejorar la agilidad. 
 Simplicidad : mantenga las cosas simples y use términos simples para medir el 
trabajo que no se ha completado. 
 Equipos autoorganizados : un equipo ágil debe ser autoorganizado y no 
depender en gran medida de otros equipos porque las mejores arquitecturas, 
requisitos y diseños surgen de los equipos autoorganizados. 
 Revise el trabajo regularmente : revise el trabajo realizado a intervalos regulares 
para que el equipo pueda reflexionar sobre cómo ser más efectivo y ajustar su 
comportamiento en consecuencia. 
Ágil - Características 
Iterativo / incremental y listo para evolucionar 
La mayoría de los métodos de desarrollo ágil dividen un problema en tareas 
más pequeñas. No existe una planificación directa a largo plazo para ningún 
requisito. Normalmente, se planifican iteraciones que varían de un corto 
período de tiempo, por ejemplo, de 1 a 4 semanas. Se crea un equipo 
multifuncional para cada iteración que funciona en todas las funciones de 
desarrollo de software, como planificación, análisis de requisitos, diseño, 
codificación, pruebas unitarias y pruebas de aceptación. El resultado al final de 
la iteración es un producto que funciona y se muestra a los interesados al final 
de una iteración. 
Después de la demostración, se toman los comentarios de revisión y se 
planea incorporarlos al software de trabajo según sea necesario. 
Comunicación cara a cara 
Cada equipo ágil debe tener un representante del cliente, como el propietario 
del producto, en la metodología scrum. Este representante está autorizado 
para actuar en nombre de las partes interesadas y puede responder las 
consultas de los desarrolladores entre iteraciones. 
Un radiador de información (pantalla física) normalmente está ubicado de 
manera prominente en una oficina, donde los transeúntes pueden ver el 
progreso del equipo ágil. Este radiador de información muestra un resumen 
actualizado del estado de un proyecto. 
Bucle de retroalimentación 
El levantamiento diario es una cultura común de cualquier desarrollo 
ágil; También se conoce como scrum diario . Es una especie de breve sesión 
en la que cada miembro del equipo se informa entre sí sobre el estado de lo 
que han hecho, qué hacer a continuación y cualquier problema que enfrenten. 
Ágil - Stand-up diario 
El stand-up diario, como su nombre lo indica, es una reunión de estado diaria 
entre todos los miembros de un equipo ágil. No solo proporciona un foro para 
actualizaciones periódicas, sino que también enfoca los problemas de los 
miembros del equipo para que puedan abordarse rápidamente. El stand-up 
diario es una práctica obligada, sin importar cómo se establezca un equipo 
ágil, independientemente de la ubicación de su oficina. 
¿Qué es el Stand-up diario? 
 Un stand-up diario es una reunión de estado diaria entre todos los miembros del 
equipo y se lleva a cabo aproximadamente durante 15 minutos. 
 Cada miembro tiene que responder tres preguntas importantes: 
o ¿Qué hice ayer? 
o ¿Qué haré hoy? 
o Cualquier impedimento que enfrento ... / Estoy bloqueado debido a ... 
 El stand-up diario es para actualizar el estado, no para ninguna discusión. Para la 
discusión, los miembros del equipo deben programar otra reunión en un momento 
diferente. 
 Los participantes generalmente se paran en lugar de sentarse para que la reunión 
termine rápidamente. 
¿Por qué es importante ponerse de pie? 
Los beneficios de tener un stand-up diario en ágil son los siguientes: 
 El equipo puede evaluar el progreso a diario y ver si pueden cumplir según el plan 
de iteración. 
 Cada miembro del equipo informa a todos sobre sus compromisos para el día. 
 Proporciona visibilidad al equipo ante cualquier retraso u obstáculo. 
¿Quién asiste a un stand-up? 
 El scrum master, el propietario del producto y el equipo de entrega deben asistir al 
stand-up diariamente. 
 Se alienta a las partes interesadas y los clientes a asistir a la reunión y pueden 
actuar como observadores, pero no se supone que participen en combates. 
 Es responsabilidad del scrum master tomar nota de las consultas de cada 
miembro del equipo y los problemas que enfrentan. 
Equipos dispersos geográficamente 
Los stand-ups se pueden hacer de múltiples maneras, en caso de que los 
miembros del equipo ágil estén operando desde diferentes zonas horarias: 
 Seleccione un miembro de forma rotativa, que pueda asistir a la reunión de 
equipos de pie ubicados en diferentes zonas horarias. 
 Tenga un stand-up separado por equipo, actualice el estado del stand-up en una 
herramienta como Rally, SharePoint, Wikis, etc. 
 Tenga preparada una amplia variedad de herramientas de comunicación, como 
llamadas de conferencia, videoconferencia, mensajería instantánea o cualquier 
otra herramienta de intercambio de conocimientos de terceros. 
Ágil - Definición de Hecho 
La definición de hecho para User Story, Iteration y Release se da a 
continuación. 
Historia del usuario 
Una historia de usuario es un requisito que se formula en unas pocas 
oraciones en el lenguaje cotidiano de un usuario y debe completarse dentro de 
una iteración. Una historia de usuario se realiza cuando 
 Todo el código relacionado se ha registrado. 
 Todos los casos de prueba de unidad han sido aprobados. 
 Todos los casos de prueba de aceptación han sido aprobados. 
 El texto de ayuda está escrito. 
 El propietario del producto ha aceptado la historia. 
Iteración 
Una iteración es una colección en tiempo real de historias / defectos de 
usuario para trabajar y aceptar en el lanzamiento de un producto. Las 
iteraciones se definen durante la reunión de planificación de iteración y se 
completan con una demostración de iteración y una reunión de revisión. Una 
iteración también se denomina sprint . Se realiza una iteración cuando 
 La copia de seguridad del producto está completa. 
 El rendimiento ha sido probado. 
 Las historias de usuario se han aceptado o movido a la siguiente iteración. 
 Los defectos se han corregido o pospuesto a la siguiente iteración. 
Lanzamiento 
Un lanzamiento es un hito importante que representa una entrega interna o 
externa de la versión probada y funcional del producto / sistema. Se realiza un 
lanzamiento cuando 
 El sistema está sometido a prueba de esfuerzo. 
 El rendimiento está ajustado. 
 Se realizan validaciones de seguridad. 
 Se prueba el plan de recuperación ante desastres. 
Ágil - Planificación de lanzamiento 
El propósito de la planificación del lanzamiento es crear un plan para entregar 
un incremento al producto. Se realiza después de cada 2 a 3 meses. 
 
¿Quien esta implicado? 
 Scrum Master : el scrum master actúa como facilitador para el equipo de entrega 
ágil. 
 Propietario del producto: el propietario del producto representa la vista general de 
la cartera de pedidos del producto. 
 Equipo ágil: el equipo de entrega ágil proporciona información sobre las 
posibilidades técnicas o cualquier dependencia. 
 Partes interesadas : las partes interesadas, como los clientes, los gerentes de 
programas, los expertos en la materia, actúan como asesores a medida que se 
toman decisiones en torno a la planificación del lanzamiento. 
Prerrequisitos de planificación 
Los requisitos previos de la planificación de lanzamiento son los siguientes: 
 Una cartera de productos clasificada, gestionada por el propietario del 
producto. En general, se toman de cinco a diez características que el propietario 
del producto considera que pueden incluirse en una versión 
 Aportaciones del equipo sobre capacidades, velocidad conocida o sobre cualquier 
desafío técnico. 
 Visión de alto nivel 
 Mercado y objetivo comercial 
 Reconocimiento de si se necesitan nuevos elementos de la cartera de productos 
Materiales necesarios 
La lista de materiales necesarios para la planificación del lanzamiento es la 
siguiente: 
 Agenda publicada, propósito 
 Rotafolios, pizarras, marcadores 
 Proyector, forma decompartir computadoras que requieren datos / herramientas 
necesarias durante la reunión de planificación 
 Datos de planificación 
Datos de planificación 
La lista de datos necesarios para planificar la publicación es la siguiente: 
 Iteraciones anteriores o resultados de planificación de lanzamiento 
 Comentarios de varias partes interesadas sobre el producto, las condiciones del 
mercado y los plazos 
 Planes de acción de versiones anteriores / iteraciones 
 Características o defectos a considerar 
 Velocidad de versiones anteriores / estimaciones. 
 Calendarios organizacionales y personales 
 Aportes de otros equipos y expertos en la materia para gestionar cualquier 
dependencia 
Salida 
El resultado de una planificación de lanzamiento puede ser el siguiente: 
 Plan de lanzamiento 
 Compromiso 
 Problemas, inquietudes, dependencias y suposiciones que se deben monitorear 
 Sugerencias para mejorar los planes de lanzamiento futuros 
Agenda 
La agenda de una planificación de liberación puede ser: 
 Ceremonia de apertura : mensaje de bienvenida, propósito de revisión y agenda, 
herramientas de organización e introducción a patrocinadores de negocios. 
 Visión del producto, hoja de ruta : muestra la imagen grande del producto. 
 Revise las versiones anteriores : debate sobre cualquier elemento que pueda 
afectar el plan. 
 Nombre / tema de la versión : inspeccione el estado actual de los temas de la 
hoja de ruta y realice los ajustes necesarios, si corresponde. 
 Velocidad : presente la velocidad de la versión actual y de versiones anteriores. 
 Programa de lanzamiento : revise los hitos clave y la decisión sobre los plazos 
para el lanzamiento y las iteraciones dentro del lanzamiento. 
 Problemas y preocupaciones : verifique cualquier problema o inquietud y 
regístrelos. 
 Revise y actualice la definición de Hecho : revise la definición de hecho y 
realice los cambios apropiados en función de la tecnología, la habilidad o los 
cambios en los miembros del equipo desde la última iteración / lanzamiento. 
 Historias y elementos a tener en cuenta : presente las historias y características 
de los usuarios de la cartera de pedidos de productos que se considerarán para la 
programación en la versión actual. 
 Determine los valores de tamaño : si se desconoce la velocidad, planifique los 
valores de tamaño que se utilizarán en la planificación de la liberación. 
 El tamaño aproximado de las historias : el equipo de entrega determina el 
tamaño apropiado de las historias bajo consideración y las divide en varias 
iteraciones si una historia es demasiado grande. El propietario del producto y los 
expertos en la materia aclaran las dudas, elaboran los criterios de aceptación y 
hacen divisiones adecuadas de la historia. El scrum master facilita la 
colaboración. 
 Mapear historias a iteraciones : el equipo de entrega y el propietario del 
producto mueven las historias / defectos en las iteraciones según el tamaño y la 
velocidad. El scrum master facilita la colaboración. 
 Nuevas inquietudes o problemas : verifique cualquier problema nuevo basado 
en la experiencia previa y registre lo mismo. 
 Dependencias y suposiciones : compruebe las dependencias / suposiciones 
planificadas durante la planificación de la versión. 
 Comprometer : el scrum master solicita la planificación. El equipo de entrega y el 
propietario del producto lo señalan como el mejor plan y luego se comprometen a 
pasar al siguiente nivel de planificación, es decir, planificación de iteración. 
 Planificación de comunicación y logística : revise / actualice la planificación de 
comunicación y logística para el lanzamiento. 
 Estacionamiento : el estacionamiento de proceso significa que todos los 
elementos deben resolverse o establecerse como elementos de acción. 
 Distribuir elementos de acción y planes de acción : distribuya los elementos de 
acción entre sus propietarios, procese el plan de acción. 
 Retrospectiva : solicite comentarios de los participantes para que la reunión sea 
exitosa. 
 Cerrar : celebra el éxito. 
Ágil - Planificación de iteraciones 
El objetivo de la planificación de iteración es que el equipo complete el 
conjunto de elementos de la cartera de productos de primer nivel. Este 
compromiso tiene un límite de tiempo basado en la duración de la iteración y 
la velocidad del equipo. 
 
¿Quien esta implicado? 
 Scrum Master : el scrum master actúa como facilitador para el equipo de entrega 
ágil. 
 Propietario del producto: el propietario del producto se ocupa de la vista detallada 
de la cartera de productos y sus criterios de aceptación. 
 Equipo ágil: la entrega ágil define sus tareas y establece las estimaciones de 
esfuerzo necesarias para cumplir con el compromiso. 
Prerrequisitos de planificación 
 Los elementos en la cartera de productos están dimensionados y tienen un punto 
de historia relativo asignado. 
 El propietario del producto ha otorgado una clasificación a los elementos de la 
cartera. 
 Los criterios de aceptación se han establecido claramente para cada elemento de 
la cartera. 
Proceso de planificación 
Los siguientes son los pasos involucrados en la planificación de la iteración: 
 Determine cuántas historias pueden caber en una iteración. 
 Divide estas historias en tareas y asigna cada tarea a sus dueños. 
 Cada tarea recibe estimaciones en horas. 
 Estas estimaciones ayudan a los miembros del equipo a verificar cuántas horas de 
tarea tiene cada miembro para la iteración. 
 A los miembros del equipo se les asignan tareas considerando su velocidad o 
capacidad para que no se sobrecarguen. 
Cálculo de velocidad 
Un equipo ágil calcula la velocidad en base a iteraciones pasadas. La 
velocidad es un número promedio de unidades requeridas para terminar 
historias de usuarios en una iteración. Por ejemplo, si un equipo obtuvo 12, 14, 
10 puntos de historia en cada iteración durante las últimas tres iteraciones, el 
equipo puede tomar 12 como velocidad para la siguiente iteración. 
La velocidad planificada le dice al equipo cuántas historias de usuarios se 
pueden completar en la iteración actual. Si el equipo termina rápidamente las 
tareas asignadas, entonces se pueden obtener más historias de usuarios. De 
lo contrario, las historias también se pueden mover a la siguiente iteración. 
Capacidad de tarea 
La capacidad de un equipo se deriva de los siguientes tres hechos: 
 Número de horas de trabajo ideales en un día. 
 Días disponibles de persona en la iteración 
 Porcentaje de tiempo que un miembro está disponible exclusivamente para el 
equipo. 
Supongamos que un equipo tiene 5 miembros, comprometidos a trabajar a 
tiempo completo (8 horas al día) en un proyecto y nadie está de permiso 
durante una iteración, entonces la capacidad de la tarea para una iteración de 
dos semanas será: 
5 × 8 × 10 = 400 horas 
Pasos de planificación 
 El propietario del producto describe el elemento mejor clasificado de la cartera de 
productos. 
 El equipo describe las tareas necesarias para completar el elemento. 
 Los miembros del equipo son dueños de las tareas. 
 Los miembros del equipo estiman el tiempo para terminar cada tarea. 
 Estos pasos se repiten para todos los elementos en la iteración. 
 Si un individuo está sobrecargado con tareas, entonces su tarea se distribuye entre 
otros miembros del equipo. 
Agile: cartera de productos 
Una cartera de productos es una lista de elementos a realizar. Los elementos 
se clasifican con descripciones de características. En un escenario ideal, los 
elementos deben desglosarse en historias de usuarios. 
¿Por qué es importante la acumulación de productos? 
 Está preparado para que se puedan dar estimaciones a todas y cada una de las 
características. 
 Ayuda a planificar la hoja de ruta para el producto. 
 Ayuda a re-clasificar las características para que se pueda agregar más valor al 
producto. 
 Ayuda a determinar qué priorizarprimero. El equipo clasifica el elemento y luego 
crea valor. 
Características de la cartera de productos 
 Cada producto debe tener una cartera de productos que puede tener un conjunto 
de características grandes a muy grandes. 
 Varios equipos pueden trabajar en una sola cartera de productos. 
 La clasificación de características se realiza en función del valor comercial, el valor 
técnico, la gestión de riesgos o la adecuación estratégica. 
 Los elementos de mayor clasificación se descomponen en historias más pequeñas 
durante la planificación del lanzamiento para que puedan completarse en futuras 
iteraciones. 
Ágil - Términos útiles 
Criterios de aceptación 
Son las condiciones establecidas por el propietario del producto o el cliente 
para aceptar que una función sea válida y cumpla con sus requisitos. 
Preparación de pedidos pendientes 
Es un proceso continuo en el que el gerente de producto o el cliente 
administran el trabajo atrasado del producto al recibir comentarios de equipos 
ágiles. Este proceso implica priorizar los elementos de la cartera, dividirlos en 
elementos más pequeños, planificarlos para futuras iteraciones, crear nuevas 
historias, actualizar los criterios de aceptación o elaborar criterios de 
aceptación en detalles. 
Capacidad 
Es la cantidad de trabajo que un equipo puede tomar para completar en una 
iteración. 
Característica 
Una mejora realizada a un producto o capacidad de valor para las partes 
interesadas que se puede desarrollar en un lanzamiento. 
Iteración 
Un elemento de trabajo basado en un tema que puede completarse dentro de 
un cuadro de tiempo y aceptarse dentro del lanzamiento de un producto. El 
trabajo de iteración se define durante la planificación de la iteración y termina 
con una reunión de demostración y revisión. También se denomina Sprint. 
Incremento 
Un incremento es el estado cambiante de un producto a medida que se 
desarrolla gradualmente. Normalmente está representado por hitos o número 
de iteraciones fijas. 
Dueño del producto 
El propietario del producto es miembro del equipo de entrega ágil, responsable 
de recopilar y clasificar los requisitos comerciales en la cartera de 
productos. El propietario de un producto comunica lo que se debe hacer en 
una versión / iteración. Él / ella establece los compromisos y es responsable 
de proteger al equipo de cualquier cambio en los requisitos durante una 
iteración. 
Pila de Producto 
Conjunto de requisitos de productos funcionales y no funcionales. 
Elementos de la cartera de productos 
Pueden ser historias de usuarios, defectos, características que serán 
desarrolladas por el equipo ágil. 
Puntos 
Una unidad común utilizada para establecer el tamaño relativo de historias de 
usuarios, características o cualquier otro elemento de cartera. 
Lanzamiento 
Un cronograma donde se trabaja para respaldar la entrega de incrementos 
comprobables a un software. En scrum, una versión consta de múltiples 
iteraciones. 
Requisito 
Una especificación de un producto de software para satisfacer un contrato o 
funcionalidad establecidos. Las historias de usuario y los elementos de la 
cartera son tipos de requisitos. 
Puntos de historia 
Una unidad utilizada por el equipo ágil para estimar los tamaños relativos de 
las historias y características de los usuarios. 
pique 
Igual que la iteración. 
Caja de tiempo 
Una duración de tiempo fija en la que se desarrollará un producto 
entregable. Normalmente, junto con la fijación de la fecha de inicio y 
finalización de un timebox, también se fija el número de recursos. 
Tarea 
Es una unidad de trabajo que contribuye a completar una historia de usuario 
dentro de una iteración. Las historias de los usuarios se descomponen en 
múltiples tareas y cada tarea se puede dividir entre los miembros del equipo 
que los marcan como propietarios de las tareas. Los miembros del equipo 
pueden asumir la responsabilidad de cada tarea, actualizar las estimaciones, 
registrar el trabajo realizado o las tareas pendientes según lo deseado. 
Historia del usuario 
Un criterio de aceptación enumerado para cumplir ciertos requisitos de un 
usuario. Normalmente se escribe desde la perspectiva de un usuario final. 
Velocidad 
Una medida para ponderar el trabajo aceptado en una iteración o 
timebox. Normalmente es la suma de puntos de historia aceptados en una 
iteración.