Glosario

Metodología de gestión y desarrollo

de proyectos de software con Scrum
En este documento recogemos los términos de uso más frecuente en este
curso que te serán útiles, tanto para el contenido, como para el entendimiento
de todos los recursos complementarios como vídeos o enlaces.

A B C D E F

G H I J K L M N

Ñ O P Q R S T

U V W X Y Z
 -A-
→ Adaptive Software Development (ASD). Es el
modelo de implementación de patrones ágiles para
desarrollo de software, diseñado por Jim Highsmith,
(Adaptive Software Development: A Collaborative Approach
to Managing Complex Systems) que materializa las fases
de la gestión ágil: especulación, colaboración y
aprendizaje.

→ Agile Unified Process (AUP). Es una versión

simplificada de Rational Unified Process, desarrollada por
Scott Amber. Divide el ciclo de desarrollo en 4 fases: inicio,
elaboración, construcción y transición.

→ Agilidad. Marco de desarrollo caracterizado por el

solapamiento de las diferentes fases de ejecución: análisis,
diseño, producción, pruebas e integración, permitiendo la
construcción o modificación del producto de forma continua
a través de la entrega continuada de incrementos discretos
funcionalmente operativos y válidos para su integración y
funcionamiento en el sistema en desarrollo. A diferencia de
la Ingeniería concurrente, la calidad del resultado se basa
en el conocimiento y colaboración de las personas y no en
los procesos o prácticas empleadas.

→ Agilidad técnica. Referida a un equipo u organización,

indica que los procedimientos, tecnología y técnicas de
trabajo empleadas son adecuados para el desarrollo
evolutivo de productos o servicios con ciclos iterativos e
incrementales y aplicación de ingeniería concurrente.
→ Artefacto. Los artefactos del marco de scrum técnico son:
1. Pila del producto: (product backlog) lista de requisitos de
usuario, que a partir de la visión inicial del producto crece y
evoluciona durante el desarrollo. 2. Pila del sprint: (sprint
backlog) lista de los trabajos que debe realizar el equipo
durante el sprint para generar el incremento previsto. 3.
Sprint: nombre que recibe cada iteración de desarrollo. Es
el núcleo central que genera el pulso de avance por
tiempos prefijados (time boxing). 4. Incremento: resultado
de cada sprint.

-B-
→ Backlog grooming. Mantenimiento de la pila del
producto o revisión de la pila del producto. Es la reunión
del propietario del producto con el equipo para mantener
actualizada la pila del producto. Se plantea con un tiempo
máximo prefijado (habitualmente una o dos horas). Esta
reunión sirve para orientar al propietario de producto del
tamaño y estimación previa de las historias que va
incorporando a la pila del producto, y para incrementar el
nivel de concreción de las historias que por su prioridad se
van acercando hacia el próximo sprint.

→ Barco. Técnica o protocolo para usar en reuniones

retrospectivas. Proporciona retroinformación del equipo
para mejorar la eficiencia. El facilitador anima a los
participantes a escribir en etiquetas adhesivas qué cosas
consideran que impulsan la eficiencia y cuáles implican un
rozamiento o freno en el funcionamiento.
→ Burn down. El gráfico de avance o “burndown” es el
gráfico que actualiza el equipo en las reuniones de
seguimiento del sprint, para monitorizar el ritmo de avance,
y detectar de forma temprana posibles desviaciones sobre
la previsión que pudieran comprometer la entrega al final
de sprint.
→ Burn up. El gráfico de producto o gráfico “burn up” es una
herramienta de planificación propia del propietario de
producto que presenta visualmente la evolución previsible
del producto. Proyecta en el tiempo la construcción del
producto, en base a la velocidad del equipo. La proyección
se realiza sobre un diagrama cartesiano que representa en
el eje de ordenadas el esfuerzo estimado para construir las
diferentes historias de la pila del producto, y en el de las
abscisas el tiempo medido en sprints.

-C-
→ Calendario Niko. Propuesto por Akinori Sakata, es un
indicador del nivel de motivación del equipo. Se sitúa en un
lugar visible de la oficina, preferiblemente junto al resto de
indicadores (gráfico de avance, pizarra kanban...) y cada
día los miembros del equipo ponen un adhesivo o dibujan
uno de los tres "smiles" posibles, reflejando su estado de
ánimo con respecto a las tareas del proyecto.
→ Campos de Scrum. Término acuñado por Nonaka y
Takeuchi para definir entornos de trabajo formados por
equipos de tamaño reducido, que comparten un mismo
espacio físico y en los que velocidad y calidad del resultado
se basa en la solvencia profesional de las personas y su
comunicación e interacción directa.
→ Cascada. Ingeniería secuencial. Frecuentemente llamada
"cascada" por la representación gráfica con la que se suele
representar el ciclo de vida de un sistema de software
desarrollado de forma secuencial. En la ingeniería
secuencial cada fase del proceso se desarrolla de forma
consecutiva, de modo que cada etapa de la secuencia no
se inicia hasta que no ha concluido la anterior. Si durante el
proceso se detecta algún error se retrocede hasta la etapa
correspondiente para subsanarlo.

→ CMM-SW. Modelo de Madurez de la Capacidad para el

desarrollo de Software (Capability Maturity Model for
Software, SW-CMM). Es un modelo de procesos para el
desarrollo y mantenimiento de sistemas de software.

→ CMMI. Integración de modelos de madurez de

capacidades o Capability maturity model integration (CMMI)
es un modelo para la mejora y evaluación de procesos para
el desarrollo, mantenimiento y operación de sistemas de
software.

→ Crystal. Concebido por Alistair Cockburn. Este modelo no

describe una metodología cerrada, sino un conjunto de
ellas, junto con los criterios para seleccionar y adecuar la
más apropiada al proyecto. Los parámetros para
determinarla son la criticidad y el tamaño del sistema que
se va a construir.
 -D-
→ Deuda técnica. Neologismo empleado en el sector
profesional TIC para describir la deuda de trabajo que se
adquiere al producir código pobre, incumpliendo prácticas
aconsejadas para el desarrollo de software. Los proyectos
que actúan de esta forma, normalmente para atajar los
tiempos de entrega adquieren una "deuda técnica", cuyos
"intereses" se tendrán que acabar pagando y supondrán
mayor cuantía cuanto más tiempo pase.

→ DSDM. DSDM es el acrónimo que da nombre a un modelo

de procesos para desarrollo de sistemas de software,
concebido por el DSDM Consortium, que se fundó en
Inglaterra en 1994 y que actualmente tiene presencia en
Inglaterra, EE.UU., Benelux, Dinamarca, Francia y Suiza; y
con interés y contactos para futuras representaciones en
Australia, India y China [...]

-E-
→ Epic. Se denomina Epic a una historia de usuario que por
su gran tamaño, el equipo descompone en historias con un
tamaño más adecuado para ser gestionada con los
principios y técnicas ágiles: estimación y seguimiento
cercano (normalmente diario).
→ Equipo de desarrollo. El equipo de desarrollo es uno de
los roles de scrum técnico. Lo forman el grupo de
profesionales que realizan el incremento de cada sprint. Se
recomienda que un equipo scrum tenga no menos de 3 ni
más de 9 personas. En el cómputo del número de
miembros del equipo de desarrollo no se consideran ni el
Scrum Master ni el propietario del producto. No se trata de
un grupo de trabajo formado por un arquitecto, diseñador o
analista, programadores y testers. Es un equipo
multifuncional, en el que todos los miembros trabajan de
forma solidaria con responsabilidad compartida.

→ Estimación de póquer. Es una práctica ágil para

conducir las reuniones en las que se estima el esfuerzo y la
duración de tareas. James Grenning ideó este juego de
planificación para evitar discusiones dilatadas que no
terminan de dar conclusiones concretas.

→ Estimación en la pared. Técnica empleada para estimar

y, opcionalmente priorizar una lista de historias de usuario,
normalmente la pila del producto. Se basa en gestión
visual, situando sobre una pared notas adhesivas con las
diferentes historias de usuario.

→ Estrella de mar. Técnica o protocolo para usar

en reuniones retrospectivas. Proporciona retroinformación
del equipo para mejorar la eficiencia.

→ Eventos. Los eventos o reuniones del marco de scrum

técnico son: Sprint, Reunión de Planificación del sprint,
Scrum diario, Revisión del sprint y Retrospectiva del sprint.
 -F-
→ FDD. Feature-driven development (FDD) es un proceso
para desarrollo de software de forma iterativa e
incremental.

→ Flexibilidad. Un principio básico de la implantación

pragmática de scrum es la flexibilidad, que consiste en que
las prácticas de scrum se adapten a la organización y no al
revés. Se trata en definitiva de realizar una gestión experta
más que una gestión técnica. Una gestión dirigida desde el
conocimiento, experiencia y criterio del gestor y no tanto
una gestión orientada a la búsqueda e implantación del
mejor modelo. Una gestión basada en la persona antes que
en el modelo.

-G-
→ Gestión evolutiva. Se denomina gestión de proyectos
evolutiva al conjunto de técnicas y prácticas empleadas
para conducir la ejecución progresiva de un proyecto: de
forma que genere un mínimo producto viable en el menor
tiempo posible, y a partir de esa primera entrega, lo
mantenga en mejora e incremento continuo.

→ Gestión predictiva. La gestión de proyectos predictiva

es la disciplina que trata de la planificación, organización,
seguimiento y control de los aspectos de un proyecto para
alcanzar los objetivos del mismo de forma segura y
satisfaciendo las especificaciones definidas de plazo y
coste. Se basa en planificación, seguimiento y control.
→ Gráfico de avance. Ver Burn Down.
→ Gráfico de producto. Ver Burn Up.

-H-
→ Historia de usuario. Descripción de una funcionalidad
que debe incorporar un sistema de software y cuya
implementación aporta valor al cliente.

-I-
→ Incremento. El incremento es la parte de producto
producida en un sprint, y tiene como característica el estar
completamente terminada y operativa, en condiciones de
ser entregada al cliente. No se deben considerar como
Incremento a prototipos, módulos o sub-módulos, ni partes
pendientes de pruebas o integración.
→ Incremento continuo. Entrega continua de
funcionalidades al ritmo que se van produciendo,
manteniendo un flujo continuo, sin tiempos muertos ni
cuellos de botella.
→ Incremento iterativo. Avance incremental del proyecto
basado en “pulsos de tiempo” o “timeboxing”. Las entregas
parciales (incrementos) se realizan en ciclos de tiempo
breves (Sprints o iteraciones) de duración prefijada,
normalmente entre una semana y un mes y medio. Al inicio
de cada ciclo se estima cuánto trabajo se puede realizar y
qué parte del proyecto se realizará.
→ Ingeniería concurrente. También llamada ingeniería
paralela o simultánea. Ciclo de desarrollo caracterizado por
la ejecución en paralelo y de forma concurrente de las
diferentes fases de ejecución: análisis, diseño, producción,
pruebas e integración, permitiendo la construcción o
modificación del producto de forma continua a través de la
entrega continuada de incrementos discretos
funcionalmente operativos y válidos para su integración y
funcionamiento en el sistema en desarrollo.

→ Ingeniería secuencial. Ver Cascada

→ INVEST. En 2003 Bill Wake desarrolló un método llamado

INVEST para asegurar la calidad en la escritura de
historias de usuario. El método sirve para comprobar la
calidad de una historia de usuario revisando que cumpla
una serie de características: I - Independent
(independiente), N - Negotiable (negociable), V Valuable
(valiosa), E - Estimable (estimable), S - Small (pequeña), T
- Testeable (comprobable)

→ IPMA. International Project Management Association

(IPMA) es una asociación profesional fundada en 1965 en
Viena, inicialmente con el nombre "International
Management Systems Association" (IMSA). Desarrolla
estándares y guías para la gestión de proyectos cuyo
desarrollo y promoción como profesión tiene por objetivo.

→ ISO 15504. Modelo para la mejora y evaluación de los

procesos de desarrollo y mantenimiento de sistemas y
productos de software.
→ Ingeniería concurrente. También llamada ingeniería
paralela o simultánea. Ciclo de desarrollo caracterizado por
la ejecución en paralelo y de forma concurrente de las
diferentes fases de ejecución: análisis, diseño, producción,
pruebas e integración, permitiendo la construcción o
modificación del producto de forma continua a través de la
entrega continuada de incrementos discretos
funcionalmente operativos y válidos para su integración y
funcionamiento en el sistema en desarrollo.

→ ITIL. Biblioteca de Infraestructura de Tecnologías de

Información (ITIL) es un compendio de conceptos y
prácticas para desarrollo, operación y servicio de
tecnologías de la información. Las recomendaciones de
ITIL se desarrollaron en los 80 por la Central Computer and
Telecommunications Agency (CCTA) del gobierno británico
para disponer de una base de conocimiento estándar para
homogeneizar la diversidad de prácticas propias de los
diferentes proveedores de servicios para la administración
británica.

-L-
→ Lead Time. El tiempo de producción ("lead time" en
inglés) es la latencia o tiempo que transcurre desde que se
inicia un proceso de producción hasta que se completa.
Uno de los objetivos de la manufactura lean o producción
lean es la reducción del tiempo de producción de los
subprocesos de fabricación.
→ Lean. Lean es un sistema de mejoramiento de procesos
de manufactura basado en la eliminación de desperdicios y
actividades que no agregan valor al proceso.

→ Lean Software Development. Este término se refiere a

la aplicación de los principios la manufactura
lean o producción lean en el desarrollo del software. Mary y
Tom Poppendieck fueron quienes lo acuñaron. Gracias a
sus aportes y los de la comunidad ágil, Lean Software
Development está desarrollando un inventario de prácticas
útiles para el desarrollo ágil de software.

→ Ley de Parkinson. Principio que afirma que la duración

de una tarea se alarga hasta completar todo el tiempo que
se tiene disponible para ella. Cuanto más tiempo se tiene,
más se divaga y más alternativas, mejoras o problemas se
plantean. Fué enunciado por Cyril Northocote Parkinson en
1957 en el libro del mismo nombre, como resultado de su
experiencia burócrata en el Servicio Civil Británico.

-M-
→ Manifiesto ágil. En marzo de 2001, 17 críticos de los
modelos de mejora basados en procesos, convocados por
Kent Beck, se reunieron para discutir sobre el desarrollo de
software. En la reunión se acuñó el término “Métodos
Ágiles” para definir a los que estaban surgiendo como
alternativa a las metodologías formales, (CMM-SW, PMI,
SPICE) a las que consideraban excesivamente “pesadas” y
rígidas por su carácter normativo y fuerte dependencia de
planificaciones detalladas, previas al desarrollo.
→ Mantenimiento de la pila del producto. Ver: backlog
grooming.
→ Manufactura lean. Modelo de gestión de la producción
orientado a la creación de un flujo de trabajo continuo, que
utilizando los recursos más ajustados (lean en inglés)
entregue en el menor tiempo posible el pedido del cliente.
Es un modelo simple y efectivo que tiene su origen en
Japón, concebido por Taiichi Ohno, director de procesos de
Toyota.
→ Mapa de historias. Representación visual de una pila de
producto en dos dimensiones. La implementación más
habitual es sobre un tablero kanban. Horizontalmente se
alinean en la parte superior los epics ordenados por
prioridad y bajo ellos se despliegan verticalmente alineado
con cada uno las tarjetas que representan las
distintas historias de usuario que los componen.
→ Mapa de producto. Técnica para estructurar la
funcionalidad del producto, desde los temas hasta
las historias de usuario. Apropiada como método de
análisis y para representar una visión panorámica del plan
del producto.
→ Mínima funcionalidad facturable. Se denomina MFF
al conjunto de funcionalidades de un sistema, que pueden
ponerse en el mercado como una parte del producto
funcional y operativa, y que puede comenzar a
proporcionar un retorno de la inversión. Es un criterio clave
para la descomposición del sistema final en sub-sistemas,
y determinar las prioridades en las que se deben
desarrollar, empleado por los modelos de planificación de
producto basados en el concepto de financiación
incremental.
→ Mínimo Producto Viable. Estrategia consistente en
desarrollar un producto o funcionalidad con las
características mínimas que permiten desplegarlo para
poner el concepto a disposición de los primeros usuarios
interesados (early adopters) y recibir de ellos la
retroinformación para recoger la mayor cantidad de
aprendizaje para su continuidad, validado por los clientes.

-P-
→ Pair programming. Programación en pareja. Es una
técnica empleada en el desarrollo ágil de software,
consistente en trabajar en el mismo equipo dos
programadores. Uno de ellos escribe el código, mientras
que el otro lo supervisa. Ambos van alternando estos roles.
El código desarrollado es más corto y de mayor calidad que
el que realizarían de forma individual, porque el rol de
observador permite la reconsideración y mejora continua
de la estrategia en la dirección del trabajo y de mejoras
sobre el código que el conductor va desarrollando.

→ Parking lot. Plaza de aparcamiento es una represetación

gráfica en la que aparece registrado el tamaño de un tema
o epic, y el porcentaje realizado. Por su formato gráfico
resulta especialmente apropiado para su representación
sobre tarjetas kanban.

→ Personal Software Process. (PSP) o proceso personal

de software, es un conjunto de prácticas para la medición y
gestión del tiempo de trabajo de ingenieros de software
para mejorar su productividad.
→ Pila del producto. En inglés product backlog Lista ágil
de los requisitos del cliente o requisitos del sistema. La pila
del producto es la lista ordenada de todo aquello que el
propietario de producto cree que necesita el producto. Es el
inventario de funcionalidades, mejoras, tecnología y
corrección de errores que deben incorporarse al producto a
través de los sucesivos sprints. Representa todo aquello
que esperan los clientes, los usuarios, y en general, los
interesados. Todo lo que suponga un trabajo que debe
realizar el equipo debe estar reflejado en esta pila.

→ Pila del sprint. Lista de tareas que va a realizar el equipo

en una iteración para construir un incremento.

→ Planificación del sprint. La reunión de planificación del

sprint es uno de los eventos de scrum técnico.

→ Planning poker. Ver estimación de póquer.

→ Plaza de aparcamiento. Ver parking lot.

→ PMBOK. Project Management Body of Knowledge es la

guía más relevante para formación y consulta de la gestión
de proyectos predictiva. La desarrolla el Project
Management Institute (PMI) y comprende dos grandes
secciones: la primera sobre los procesos y contextos de un
proyecto y la segunda sobre las áreas de conocimiento
específico para la gestión de un proyecto.
→ PRINCE2. (Projects in a Controlled Environment) es un
método estructurado para gestión de proyectos predictivos
que tiene su origen en el modelo desarrollado en 1975 por
la CCTA (Central Computer and Telecommunications
Agency). La evolución de ese modelo original tomó en
1989 el nombre de PRINCE y en la actualidad es
desarrollado por la organización británica en la que se
integró la CCTA: OGC (Office overnment Commerce).
→ Procedimiento. Es un conjunto de acciones definidas,
que en combinación con la tecnología y la acción de las
personas, producen resultados esperados, y que pueden
ser: procesos o prácticas.
→ Proceso. Procedimiento que, junto con la tecnología,
aporta el conocimiento clave para lograr el resultado
esperado. En los sistemas de producción que emplean
procesos, las personas "ayudan" al proceso. Las cadenas
de producción industrial emplean procesos.
→ Práctica. Procedimiento empleado en los sistemas de
producción en los que las personas las que aportan el
conocimiento clave para lograr el resultado esperado.
→ Producción lean. Ver Manufactura lean.
→ Product Backlog. Ver Pila de producto.
→ Product canvas. Tablero kanban de producto para mostrar
en un vistazo:
1. El objetivo de la visión del producto o la versión en
desarrollo.
2. Temas e historias previstas.
3. Historias que se están desarrollando en el sprint actual.
→ Product owner. Es uno de los roles de scrum técnico. El
propietario del producto es quien toma las decisiones del
cliente. Su responsabilidad es el valor del producto. Para
simplificar la comunicación y toma de decisiones es
necesario que este rol recaiga en una única persona. Si el
cliente es una organización grande o con varios
departamentos, puede adoptar la forma de comunicación
interna que consideren oportuna, pero en el equipo de
desarrollo solo se integra una persona en representación
del cliente, y esta debe tener el conocimiento suficiente del
producto y las atribuciones necesarias para tomar las
decisiones que le corresponden.

→ Programación en pareja. Ver Pair programming.

→ Propietario del producto. Ver Product owner.

→ Punto de función. También llamado en gestión ágil:

punto de scrum. Unidad de medida relativa que determina
la cantidad de trabajo necesaria para construir una
funcionalidad o historia de usuario.

→ Punto de historia. En inglés: Story Point. Unidad de

trabajo empleada habitualmente en Extreme Programming,
definida por la cantidad de trabajo realizada en un día de
trabajo ideal (tiempo ideal).
 -R-
→ Refactorización. Re-estructuración del código fuente,
alterando su estructura interna, sin modificar el
comportamiento del programa, con la finalidad de "limpiar
el código": mejorar la consistencia interna, claridad,
comprensión en general su calidad. Se recomienda realizar
la refactorización, seguida de pruebas unitarias para
comprobar que no ha cambiado el comportamiento del
código.

→ Requisitos ágiles. La gestión ágil de proyectos trata los

requisitos en cuatro niveles de tamaño: temas, epics,
historias de usuario y tareas.

→ Retrospectiva. Nombre de la reunión en la que el equipo

analiza la forma de trabajo para su mejora continua. Las
reuniones retrospectivas son por tanto una “meta-práctica”
ágil. Aunque es frecuente realizarlas al final de cada sprint,
no deben confundirse con las reuniones de revisión del
sprint. El objetivo de la revisión del sprint es analizar “QUÉ”
se está construyendo, mientras que una reunión
retrospectiva se centra en “CÓMO” lo estamos
construyendo: “CÓMO” estamos trabajando, con el objetivo
de analizar problemas y aspectos mejorables.

→ Revisión del sprint. La reunión de revisión del sprint es

uno de los eventos de scrum técnico.

→ Roles. Los roles en un marco de scrum técnico son:

Propietario del producto, Equipo de desarrollo, Scrum
Master.
 -S-
→ Scrum avanzado. Adaptar las prácticas scrum a las
circunstancias de la propia organización, permite emplear
técnicas de incremento continuo o iterativo; tableros
kanban con el formato más adecuado a cada proyecto, y
en general las prácticas y reglas que mejor encajan en las
circunstancias de cada caso. De esta forma se van
abandonando los renglones de guía de las reglas definidas
y aplicando directamente los valores de scrum.

→ Scrum diario. La reunión de scrum diario es uno de

los eventos de scrum técnico. Reunión diaria breve, de no
más de 15 minutos, en la que el equipo sincroniza el
trabajo y establece el plan para las 24 horas siguientes.

→ Scrum Level. Scrum Level es un modelo de referencia y

buenas prácticas para mejorar la agilidad en la gestión y
producción, proporcionando un método para la evaluación
estructurada de las variables que determinan las
características y grado de agilidad de la organización.

→ Scrum Master. Scrum Master es uno de

los roles de scrum técnico. Es el responsable del
cumplimiento de las reglas de un marco de scrum técnico,
asegurando que se entienden en la organización, y se
trabaja conforme a ellas. Proporciona la asesoría y
formación necesaria al propietario del producto y al equipo.
Realiza su trabajo con un modelo de liderazgo servil: al
servicio y en ayuda del equipo y del propietario del
producto.
→ SEI. Software Engineering Institute (SEI) es un instituto
federal estadounidense de investigación y desarrollo,
fundado por el Congreso de los Estados Unidos en 1984
para desarrollar modelos de evaluación y mejora en el
desarrollo de software, que dieran respuesta a los
problemas que generaba al ejército la programación e
integración de los sub-sistemas de software en la
construcción de complejos sistemas militares. Financiado
por el Departamento de Defensa de los Estados Unidos y
administrado por la Universidad Carnegie Mellon.

→ Seis sombreros para mejorar. Protocolo para usar

en reuniones retrospectivas, desarrollado sobre el método
para discusiones y toma de decisiones en grupo conocido
como "método de los seis sombreros para pensar" o
"método de los seis sombreros”.

→ Sprint. Ciclo de tiempo en el que se desarrolla cada

incremento iterativo del producto. En función de las
características del proyecto y el criterio del equipo, lo
habitual es realizar sprints de duración no inferior a una
semana ni mayor de un mes. Cada sprint produce
un incremento.

→ Sprint Backlog. Ver Pila de sprint.

→ SWEBOK. Acrónimo de "Software Engineering Body of

Knowledge", un documento promovido por la IEEE
Computer Society y desarrollado por la Software
Engineering Coordinating Comité para desarrollar el área
de conocimiento propias de la Ingeniería del Software. Su
objetivo es alcanzar un consenso de las áreas de
conocimiento que debe comprender esta ingeniería.
 -T-
→ Tarea. Unidad de trabajo gestionada por el equipo. Una
tarea tiene asignada una persona para su realización, y es
recomendable que el esfuerzo estimado parara llevarla a
cabo sea como máximo el equivalente al realizable en una
jornada de trabajo.
→ TDD. Desarrollo guiado por pruebas o Test-driven
development (TDD) es una práctica para desarrollo de
software consistente en la repetición de un ciclo breve en el
que primero se codifica un caso para automatizar la prueba
de la función que se quiere programar. A continuación
escribe un código mínimo que debe pasar esa prueba, y a
partir de ahí se va refactorizando el código hasta el nivel de
producto deseado.
→ Tema. Se denomina tema a una colección
de epics relacionados para describir un sistema o
subsistema en su totalidad. Por ejemplo, en un sistema de
software para gestión contable, El cunjunto de epics: "Altas,
bajas y mantenimiento de clientes" "Facturaciones
puntuales y recurrentes", "Consultas de navegación y
acciones de fidelización", "Pedidos", "Devoluciones" se
podrían denominar como el tema de la gestión de clientes.
→ Tiempo de producción. El tiempo de producción ("lead
time" en inglés) es la latencia o tiempo que transcurre
desde que se inicia un proceso de producción hasta que se
completa. Uno de los objetivos de la manufactura lean o
producción lean es la reducción del tiempo de producción
de los subprocesos de fabricación.
→ Tiempo de tarea. Tiempo que se estima necesario para
realizar una tarea en condiciones ideales: sin ninguna
interrupción, llamadas telefónicas, descansos, reuniones,
etc.

→ Tiempo prefijado. "Timeboxing" en inglés. Técnica de

administración de tiempo, comúnmente empleada en los
modelos de gestión ágil, consistente en dividir el trabajo en
tareas con una asignación de tiempo limitado y corto para
su ejecución.

-U-
→ Unified Process. Marco de desarrollo evolutivo de
ingeniería concurrente, de incrementos iterativos, que
solapa las tres fases de desarrollo (elaboración,
construcción y transición) en iteraciones breves de tiempo
cerrado. En determinados proyectos también puede
solaparse la fase previa de inicio.

-V-
→ Velocidad. Con carácter general, en el contexto de
gestión ágil de proyectos, el término velocidad se define
como la cantidad de trabajo realizada en una unidad de
tiempo. En scrum técnico se refiere a la cantidad de trabajo
(puntos de función, puntos de historia...) realizada en un
sprint.
 -W-
→ Work in process. Término inglés (acrónimo WIP) que en
el campo de la manufactura lean, de donde proviene, se
emplea para designar la cantidad de productos a medio
fabricar, que aún no están terminados. Por analogía, en el
uso de tableros kanban para gestión y seguimiento de
proyectos TIC, se emplea el término para indicar las tareas
que se encuentran en una fase del proyecto, pendientes de
pasar a la siguiente fase o de completarse; y en este
entorno el término WIP se suele emplear con la acepción
de límite o número máximo de tareas que pueden llegar a
acumularse en un área determinada. Así por ejemplo, decir
que en un tablero kanban para programación de software,
el área de testing o de pruebas "tiene un WIP de 3" quiere
decir que no puede haber más de tres tareas en la fase
de testing simultáneamente.

→ Work in progress. Término que se suele confundir y

usar erróneamente para designar Work in process.

-X-
→ Xbreed. Metodología Ágil propuesta por Mike Breedle,
que colaboró con Ken Schwaber en la definición de Scrum.
Es una combinación de Scrum para la gestión del proyecto,
y Extreme Programming como prácticas de desarrollo. Esta
es una combinación comúnmente empleada
independientemente de su definición como Xbreed, que
hasta la fecha no ha tenido especial relevancia. También
denominada “Agile Enterprise”.