Manual C13936 196 1667465258

Introducción a las metodologías ágiles © IMF
Smart Education
Índice
Introducción a las metodologías ágiles 4
I. Introducción 4
II. Objetivos 4
III. Introducción a las metodologías ágiles 5
IV. Principales metodologías y marcos 6
4.1. Design thinking 6
4.1.1. El proceso de diseño 9
4.1.2. Fases de design thinking 11
4.1.3. ¿Cómo impulsar design thinking en una organización? 14
4.2. Pensamiento Lean 15
4.2.1. 5S 17
4.2.2. 7 mudas 18
4.3. Agile 19
4.3.1. Extreme programming (XP) o programación extrema 21
4.3.2. Crystal methods o métodos Crystal 22
4.3.3. Dynamic systems development methods (DSDM) o métodos dinámicos de desarrollo de sistemas 23
4.3.4. Feature driven development (FDD) o desarrollo basado en características 23
4.3.5. Test driven development (TDD) o desarrollo guiado por pruebas 24
4.3.6. Adaptive software development (ASD) o desarrollo adaptativo de software 24
4.3.7. Domain driven design (DDD) o diseño guiado por dominios 25
4.3.8. Agile unified process (AUP) o proceso unificado ágil 25
4.3.9. Kanban 25
4.3.10. Scrum 28
V. El agilismo. ¿Qué son las metodologías ágiles? 29
5.1. La herencia industrial 29
5.2. La revolución tecnológica 30
5.3. El agilismo y los principios ágiles 32
5.4. Proyectos tradicionales vs. proyectos ágiles 37
5.4.1. La aproximación tradicional a la gestión de proyectos 37
5.4.2. Los marcos de trabajo ágiles 40
5.4.3. Los marcos de trabajo híbridos 42
5.4.4. Criterios para elegir una aproximación ágil frente a la tradicional 43
5.4.5. Los retos de los marcos de trabajo ágiles 46
5.5. Distintas certificaciones ágiles 48
VI. Impacto en el negocio 48
6.1. El impacto en el negocio de la agilidad organizacional 48
VII. Impacto en las organizaciones 50
7.1. “Todo el mundo quiere ser ágil” 50
7.2. Los conocimientos y habilidades necesarios para los proyectos están evolucionando 50
VIII. Casos de éxito 51
8.1. Aspectos de Agile aplicados a proyectos empresariales y start-ups 51
8.2. Proyectos de gestión ágil de diseño de productos 53
8.3. Aplicar Scrum en las aulas: proyectos educativos 55
8.4. Los departamentos de RR. HH. se transforman a Agile 56
8.4.1. “How HR can become agile (and why it needs to)” 56
8.4.2. “RR. HH. se transforma a ‘agile’: un caso de estudio en BBVA” 58
8.5. Proyectos ágiles para servicios 59
8.5.1. Scrum Boosts Effectiveness at the BBC 59
2/104
8.6. Agile en proyectos de públicos y de defensa 60
8.6.1. Owning the Sky with Agile 60
8.6.2. La Oficina de Responsabilidad Gubernamental (GAO, en inglés) 61
IX. Entrega de valor 63
9.1. Enfocarse en las prioridades del negocio 64
9.2. Planificación en entornos ágiles 64
X. Historias de usuario 66
10.1. Historias de usuario, épicas y temas 66
10.2. Estimación por puntos de historia (story points) 69
10.3. Velocidad de un equipo Scrum 72
10.4. Técnicas para estimaciones 72
10.4.1. Planning poker 73
10.4.2. Tamaños de camisetas 77
10.4.3. Velocidad y cronograma 79
10.5. Priorización de las historias de usuario 80
10.5.1. Valor financiero 80
10.5.2. Coste 81
10.5.3. Aporte de conocimiento 81
10.5.4. Riesgo 82
10.5.5. El método MoSCoW 82
10.5.6. Mapeo de historias de usuario 84
XI. Cómo evolucionar hacia una organización ágil 86
XII. Resumen 87
XIII. Anexos 89
Ejercicios 90
Caso práctico 90
Enunciado 90
Se pide 95
Solución 95
Recursos 99
Enlaces de Interés 99
Bibliografía 99
Glosario. 100
3/104
Introducción a las metodologías ágiles

I. Introducción
En el mercado actual de las tecnologías de la información todo el mundo habla sobre Agile y sobre Scrum
como herramientas para la gestión de proyectos, pero ¿qué son estas dos palabras?, ¿de dónde viene
Agile?, ¿qué es Scrum?
Scrum se basa en conceptos muy básicos, pero llevarlo a cabo correctamente puede ser complicado.En
esta unidad, el alumno aprenderá sobre el nacimiento de Agile como filosofía, sobre los conceptos
comunes a los marcos de trabajo ágiles y sobre cómo gestionar un proyecto con éxito cuando tenemos
que adaptarnos constantemente a circunstancias cambiantes.
II. Objetivos
El principal objetivo de esta unidad es que el alumno comprenda cuáles son los principios y valores
fundamentales del pensamiento Agile para, dentro de esta corriente, profundizar en las siguientes unidades
en una de sus metodologías más populares: Scrum.
La agilidad es una filosofía que se comparte y se contagia a través del organigrama de las empresas.
Muchas corporaciones están cambiando su forma de trabajar implementando equipos de trabajo Agile.
Los principios y valores fundamentales del pensamiento Lean y Agile.
Conocer los principales marcos de trabajo y metodologías de Agile.
Entender cómo los marcos de trabajo Agile impactan en los resultados del negocio gracias a la entrega
de valor al cliente de forma temprana, continua e incremental a lo largo del ciclo de vida del proyecto.
Conocer cómo influir en el equipo de proyecto y en el resto de la organización compartiendo los

principios de la agilidad organizacional.
4/104
Enfocar el esfuerzo en la entrega de valor al cliente mediante el desarrollo de sus necesidades del cliente
y del resto de interesados, lo que se llamará historias de usuario.
Estimación y planificación en Agile mediante la priorización de las historias de usuario que componen el
proyecto.
III. Introducción a las metodologías ágiles

La planificación predictiva de proyectos es menos eficaz en entornos de alta incertidumbre. La
combinación tradicional alcance/tiempo/coste para el desarrollo de un nuevo producto o servicio no
siempre se ajusta bien al entorno donde normalmente se llevan a cabo estos proyectos. Durante años esto
ha sido evidente, especialmente en el desarrollo de ingeniería de software, pero no solo en este sector:
Alrededor de dos tercios de los proyectos superan sus estimaciones presupuestarias (Lederer y
Prassad, 1992).
El 64 % de la funcionalidad de los nuevos productos nunca se utiliza o rara vez es útil (Johnson, 2002).
La mayoría de los proyectos superan los términos establecidos en su calendario (Standish, 2001).
5/104
El principal problema que se encuentra en estos proyectos tiene que ver con el hecho de que un enfoque
tradicional de los proyectos (o lo que se llama predictivo o cascada) se centra en la planificación de las
actividades de un proyecto, y rara vez en las funcionalidades que se deben crear con el nuevo proyecto.
Así, se traducen los requisitos en paquetes de trabajo y actividad, para asignarles recursos, una fecha
límite en el calendario y los costos asociados. En resumen, se ha movido el éxito del proyecto a ejecutar
escrupulosamente estas actividades.
Sin embargo, el cliente del proyecto está interesado en las funcionalidades para las que pidió que se
trabajase, y no tanto en lo que se hico para lograrlo.
La segunda derivada de este problema tiene que ver con la revisión de una planificación basada en
actividades. Al enfrentarse a un proyecto retrasado o uno con problemas presupuestarios, hay pocas
alternativas para devolverlo al plan original, entre ellas, la reducción de la calidad. Otros equipos
simplemente se oponen a cualquier cambio en la planificación, como si la parte esencial del proyecto
fuera cumplir con lo planeado, en lugar de satisfacer la necesidad del cliente, a través de cambios en el
proyecto en caso de que sea necesario.
Cuando el proyecto se desarrolla en un entorno de alta incertidumbre este problema aumenta. Por un
lado, es muy complejo determinar las funcionalidades y los requisitos de un nuevo producto o servicio
cuando el cliente no tiene muy claro cómo será el resultado final. Pensando en una start-up , el 90 % de
estas empresas cambian su modelo de negocio durante los primeros cinco años de vida.
Por otro lado, si se cuenta con poca información, o requisitos cambiantes, es complejo estimar las
actividades que muy probablemente sufrirán cambios importantes en las próximas semanas/meses.
IV. Principales metodologías y marcos
4.1. Design thinking

Una de las técnicas más potentes para impulsar la innovación y la creación de nuevas ideas en las
organizaciones es design thinking. Una herramienta que ha adquirido una gran popularidad desde que fuera
desarrollada de forma teórica en la Universidad de Stanford, en California (EE. UU.) a partir de los años
setenta. Luego se trata de una herramienta o marco de trabajo muy actual y con poca historia, pero con
resultados contrastados. Su principal precursor en el ámbito de la empresa y los negocios es Tim Brown,
actual CEO de la consultora de diseño IDEO.
6/104
Según Tim Brown: “Es una disciplina que usa la sensibilidad y métodos de los diseñadores para
hacer coincidir las necesidades de las personas con lo que es tecnológicamente factible y con lo
que una estrategia viable de negocios puede convertir en valor para el cliente, así como en una
gran oportunidad para el mercado”.
Se trata de un método para generar ideas innovadoras que centra su eficacia en entender y dar solución a
las necesidades reales de los usuarios.
Esta forma de trabajar está muy relacionada con la creación de nuevos productos por parte los
diseñadores. Sin embargo, se puede extender su ámbito de aplicación a la creación de servicios, mejora de
procesos y la creación de modelos de negocio. Empresas de todos los sectores, desde tecnológicas como
Google hasta retail como Zara, utilizan esta metodología para incorporar el pensamiento creativo.
Se incluye esta técnica en la unidad dedicada al marco de trabajo Agile porque comparte con el resto la
gestión de proyectos adaptativos y el foco en la satisfacción del cliente a través de la entrega de valor. De
este modo, el design thinking establece unos procesos de pensamiento plenamente orientados al usuario.
En muchas de las técnicas utilizadas a lo largo del proceso los usuarios van a ser protagonistas activos
aportando su punto de vista, expectativas y necesidades.
El segundo punto en común con Agile es que design thinking demuestra una gran capacidad de generar en
muy poco tiempo soluciones innovadoras. Es por ello que esta metodología se haya vuelto tan popular
entre las empresas emprendedoras y start-ups para avanzar y testar rápidamente sus hipótesis y crear una
cultura innovadora dentro de las organizaciones.
Las principales características de esta metodología son las siguientes:
La búsqueda de la innovación centrada en los usuarios. Es necesario generar empatía con las personas
involucradas en el proyecto para entender los problemas, necesidades y deseos de los usuarios
implicados en la solución que se está buscando. La involucración de clientes o usuarios finales minimiza
la incertidumbre y el riesgo de la innovación.
Esta empatía va a facilitar el observar el problema desde el punto de vista del usuario para descubrir las
necesidades no satisfechas dentro de un contexto y las limitaciones de una situación particular.
El trabajo en equipo es clave para crear un ambiente lúdico, poniendo en valor la capacidad de los
individuos de aportar su singularidad al proceso. Se trata de disfrutar durante el proceso, y, gracias a
ello, llegar a un estado mental en el que se dé rienda suelta al potencial creativo de cada individuo.
7/104
La creatividad está potenciada por las distintas técnicas de gran contenido visual y plástico utilizadas en
cada una de las fases del proceso. Se trata de trabajar tanto la parte creativa como la analítica, dando
como resultado soluciones creativas y que se puedan materializar dentro de un contexto razonable.
La iteración de las soluciones, que se van completando con nuevas ideas, probando y ajustando
prototipos que sirven para validar las soluciones antes de asumirse como correctas. El design thinking
fomenta la identificación de fallos durante el proceso de validación para eliminarlos antes de llegar a la
solución deseada.
Lo especial de design thinking es que los procesos de trabajo que habitualmente están reservados a los
diseñadores pueden ayudar a aplicar estas técnicas centradas en el usuario y las personas para crear
soluciones más creativas e innovadoras, tanto en el diseño como en la concepción de modelos de
negocio, productos y servicios.
8/104
Figura 1. Design thinking
Figura 1. Design thinking.

Fuente: Commons. Wikipedia, 2020.
4.1.1. El proceso de diseño
9/104
El proceso de design thinking se divide en cinco etapas: empatía, definición de la solución,

ideación, prototipado y testeo. Estas cinco fases se pueden entender de una forma lineal, o
como un ciclo en bucle, dependiendo del feedback que dé el usuario. Gracias al feedback del
cliente o usuario se puede realizar este proceso de forma iterativa para ajustar cada vez más la
solución final a las necesidades del cliente.
Figura 2. Design thinking.

Fuente: https://xn--designthinkingespaa-d4b.com/ (2020).
Aunque se considera necesario parar por cada una de las fases del proceso al menos en una ocasión, al
realizar el proceso de forma iterativa el facilitador tiene libertad para saltarse o volver sobre alguno de los
pasos si se considera necesario. Es importante tener en cuenta que las cinco fases, etapas o modos no
siempre son secuenciales. No tienen que seguir ningún orden específico y, a menudo, pueden ocurrir en
paralelo y repetirse iterativamente.
El facilitador
La figura del facilitador
La figura del facilitador en un proceso de design thinking tiene muchas similitudes con la del Scrum
master, más orientada a actuar como facilitador del proceso que como especialista del área de
conocimiento del problema que se trate. Hay que tener en cuenta que posiblemente no se cuenten con
los conocimientos técnicos profundos sobre los problemas concretos a los que uno se enfrenta. Es
por ello por lo que el involucramiento de los usuarios y las personas interesadas especialistas en la
materia es esencial. La función del facilitador será, pues, la de ayudar al equipo a sacar el máximo
potencial de cada uno de sus miembros. Sí es importante que conozca en profundidad los
fundamentos y las fases del proceso de design thinking, así como las técnicas utilizadas, para guiar al
equipo en todo el proceso.
10/104
La personalidad y estilo del facilitador
El estilo y personalidad del facilitador y el tipo de proyecto en el que se aplique la metodología de

design thinking pueden influir en las fases de este proceso. Como se ha comentado, no existe una
norma fija sobre cómo realizar todas las fases. De hecho, existen distintas variantes desde el
concepto original practicado por IDEO.
No obstante, todas las variantes de design thinking encarnan los mismos principios y todas ellas cuentan al
menos con estas cinco fases principales:
Figura 3. Design thinking, fases.

Fuente: https://xn--designthinkingespaa-d4b.com/ (2020).
4.1.2. Fases de design thinking
Empatizar
Empatizar con los usuarios o clientes es la forma de extraer el máximo de información acerca del
problema para solucionar. Esta información y los datos asociados proceden de la comunicación,
verbal y no verbal, gracias a actividades y dinámicas en las que estos stakeholders o partes interesadas
deberán participar junto con el equipo de proyecto. En este punto, hay que ser capaces de ver el
problema desde el punto de vista del cliente. Sentir y ponerse en la piel del usuario.
Esta parte del proceso es importante ya que sirve para obtener información de primera mano sobre el
contexto en el que se produce el problema. También habrá que ser capaces de comprender las
expectativas de las partes interesadas para tenerlas en cuenta durante el resto del proceso de diseño.
Para conseguir estos dos objetivos será fundamental realizar un trabajo de campo e investigación.
Existen muchas formas de realizar este trabajo, pero llegado el momento será obligatorio salir de la
oficina, a través del trabajo de campo, para observar el contexto del problema.
Algunas de las técnicas utilizadas en esta fase del proceso de diseño pueden ir desde la propia
observación del usuario en su contexto hasta las entrevistas abiertas, pasando por focus group , o
labores de investigación y benchmark, entre otras. Estas técnicas son típicamente ejercicios divergentes,
en los que aparece mucha información, aparentemente desconexa.
11/104
Es importante en todas estas técnicas que el equipo se muestre como un observador inocente, esto es,
un informador que no intenta influir en el resultado de la investigación en este primer momento.
Definir
Se trata de definir sus necesidades, sus problemas y sus ideas con base en la información que se ha
recopilado en la fase de empatía. Cribar y seleccionar la información realmente útil será clave para
desarrollar planteamientos alternativos y nuevos enfoques que aporten valor.
Tras la etapa anterior de divergencia, en la que se recopila información sin valorar su importancia, en
esta segunda etapa se va a converger esa información en insights . Estos puntos de vista o “revelaciones”
ayudan a prestar atención a aquellos focos que generarán las soluciones al problema, denominados
focos de acción.
Idear
Consiste en crear ideas que desafíen las suposiciones y deriven en soluciones innovadoras. Esta fase
vuelve a ser expansiva y divergente, promoviendo la creación de múltiples ideas/soluciones sobre las
que pueden derivar más iteraciones y versiones.
En este punto, la personalidad del facilitador o diseñador tiene una gran importancia para no convertirse
en un “censor de buenas ideas”, validando únicamente ideas preconcebidas. A veces, ideas
estrambóticas generan soluciones visionarias.
Para generar ideas desde la definición del problema se debe practicar lo que se conoce como reto
creativo, formulando preguntas relacionadas con el foco de acción. Es importante saber hacerse las
preguntas adecuadas y no perder de vista estas preguntas, para las que se están generando soluciones.
Una de las herramientas típicas en esta fase del proceso es el brainstorming. Esta técnica tiene que servir
para generar el mayor número de ideas posible, sin cortapisas por parte del resto de miembros del
equipo. Es importante no emplear elementos de juicio en esta fase. Otros requisitos importantes para
que el brainstorming sea eficaz son, por ejemplo, ser lo más visual posible para comunicar al resto del
equipo todas las ideas de una forma sencilla; animarse a tener ideas locas, que en una segunda derivada
pueden aportar una solución alternativa a la tradicional, o crear la atmósfera adecuada para que todo
fluya y los miembros del equipo se sientan cómodos y libres para aportar sus ideas.
Prototipar
Se trata de configurar un prototipo para transformar las ideas en realidad. La primera solución que
se va a materializar desde las fases más conceptuales no necesariamente será la definitiva al problema,
sino más bien un avance, un paso más, en medio de un ciclo de mejora continua. Construir y hacer
palpables las ideas ayuda a visualizar posibles soluciones, poniendo de manifiesto elementos que se
deban refinar antes de llegar al resultado final.
12/104
Prototipar es, además, la forma más rápida de conectar con el usuario. En las metodologías ágiles la
cultura del prototipado está muy integrada. En este sentido, comparte la filosofía Agile de buscar
procesos cortos e iterativos. No buscando la solución completa al problema en un primer momento,
sino construyendo y entregando al usuario soluciones parciales de una forma temprana y rápida con el
fin de recibir de su parte un feedback valioso acerca de la posible solución. Prototipar es un ensayo
rápido y barato. No es necesario que el prototipo contenga todas las funcionalidades que está pidiendo
el cliente, sino solo aquellas que en un primer momento aportan mayor valor al proceso. Una forma de
fallar de manera veloz o validar las soluciones.
En el caso del diseño de una idea de negocio o nuevo servicio, un prototipo puede ser un servicio
básico que se pueda lanzar al mercado o colgarlo en una landing page con la idea de valorar el tráfico, el
interés del público acerca de este servicio, etc.
Una herramienta típica de esta fase del proceso de diseño es el storyboard de la solución, incluyendo la
interacción del usuario con la solución propuesta. Otras técnicas son el rol playing, un folleto con todos
los servicios que contendrá la solución, pantallazos, o una maqueta de un sitio web sin back office, o
landing page sencilla. En el caso de infraestructuras o construcciones, la labor del prototipado se
complica un poco más. Sin embargo, actualmente se cuenta con tecnología inmersiva, a través de
realidad virtual, modelado 4D, BIM, etc., que hace sentir y percibir todos los aspectos del modelo
virtual como si fuera real.
En cualquier caso, construir con las manos una maqueta de la solución no es perder el tiempo. Si una
imagen vale más que mil palabras, un prototipo vale más que mil ideas. Y sirve de puente o nexo de
unión entre el usuario y el equipo de diseño.
Testear
Es el final de un recorrido de generación de ideas, que han sido aterrizadas en forma de prototipo.
Ideas que han partido de una investigación previa y definición de focos de acción que recogían
aspectos de especial valor para el usuario.
El prototipo servirá de vehículo para validar la solución. Se pasará al modo demo con las distintas
soluciones planteadas. Durante estos test de pruebas se evolucionará la solución en el camino hacia la
excelencia para asegurar la satisfacción del cliente o usuario.
De nuevo en esta fase es crítico el carácter de las personas que componen el equipo de diseño. Se corre
el riesgo de entender esta fase del proceso como una fase de venta de la solución, cuando en realidad lo
importante es escuchar y recibir el feedback del usuario. Se debe obtener la información más genuina
posible para saber si se está conectando con las necesidades y deseos del cliente, o, por el contrario, se
los ha dejado olvidados en momentos previos del proceso. El ego es el principal enemigo del diseñador,
levantándose como una barrera entre el usuario y este.
Al llegar al momento de la verdad, en el que se recibe el feedback del usuario, se pueden plantear tres
escenarios posibles:
13/104
Pasar la solución a producción. El feedback es muy positivo y se puede implementar la solución o

empezar a fabricar el nuevo producto o servicio.
Iterar. La más común, dado que se está en un proceso iterativo en el que se van refinando las
soluciones con cada versión del proceso.
Abandonar el proceso. Tomar la decisión de no go debido al feedback negativo del usuario, estudios
de mercado, o imposibilidades técnicas para materializar las ideas que se tienen en mente.
La calidad del feedback del usuario dependerá de la capacidad que se tenga para empatizar con los
stakeholders .
4.1.3. ¿Cómo impulsar design thinking en una organización?
Se encuentran casos de aplicación de design thinking en organizaciones y empresas de todos los sectores,
desde el diseño y creación de productos hasta la medicina, la arquitectura, ingeniería, los servicios, la
educación o la Administración pública.
Pero para poder poner en práctica un proceso creativo como este primero hay que asegurarse de crear la
cultura y el ecosistema en los que el pensamiento creativo y con opciones al fracaso no esté penalizado. En
este sentido, la labor de los directivos es importante para transmitir esta cultura.
Para lograr los resultados del pensamiento creativo, empoderar al equipo de una organización es de suma
importancia. Esto significa que los managers deben promover una cultura de inventiva e ideas audaces.
Para fomentar el proceso creativo en una organización se pueden considerar los siguientes puntos:
Transmitir una visión que permita a los empleados una mayor asunción de riesgos en el proceso de
experimentación.
14/104
Inspirar el proceso creativo. Los líderes de las organizaciones asumen desafíos, y determinan formas
efectivas de abordar los problemas a medida que surgen de una forma flexible y abierta.
Involucrarse con el proceso creativo. Un líder que está involucrado en el proceso creativo de design
thinking debe estar en contacto con el terreno en todo momento.
Podría decirse que la clave para fomentar el design thinking en la organización está en el liderazgo de los
managers , que deberá animar a probar soluciones alternativas y nuevas vías, la aceptación del propio
fracaso y la flexibilidad para introducir cambios y adaptar los resultados. Todo ello aportando valor al
usuario como centro del proceso.
4.2. Pensamiento Lean
Con anterioridad a las metodologías de desarrollo de sistemas anteriormente descritas, en el mundo de la

manufactura ya se utilizaba la filosofía de trabajo Lean, totalmente compatible con el marco Agile. La
filosofía Lean ha sido ampliamente adoptada por los seguidores del Manifesto Agile, dado que permite
desarrollar una adecuada mentalidad.
La filosofía Lean es un sistema de trabajo de origen japonés que se basa en mejorar de forma
continua la manera en la que se fabrica un producto.
Se podría decir que trata de ajustar la manufactura pensando siempre en eliminar “basuras” que no aporten
valor. Precisamente, de eliminar todo aquello que es superfluo se deriva la utilización del término lean,
procedente del adjetivo inglés que denota algo esbelto, libre de grasas. La filosofía de trabajo Lean tiene
como objetivo eliminar cualquier tipo de tarea que no aporte valor o calidad al producto. De esta manera,
se busca aumentar el valor de cada uno de los pasos de fabricación, reducir lo que se llama “desperdicios”
y mejorar los procesos operativos. Todo ello siempre con el respeto al trabajador como base de la mejora
continua que la filosofía propone.
Para entender el sistema Lean es importante conocer su historia. La idea de esta filosofía se crea en la
mente de Taiichi Ohno, director de la empresa japonesa Toyota que estudió los sistemas de producción
estadounidenses y observó que la fabricación era espectacular pero los desperdicios eran igual de
sorprendentes. Se dio cuenta de que había otra manera de gestionar el almacenamiento, que era donde se
producía el mayor desperdicio. A raíz de este estudio extrae la filosofía Lean, que busca respetar al
máximo la calidad de la fabricación buscando que cualquier actividad que realice el operario tenga valor. La
filosofía hace también referencia al término “mejora continua”, buscando siempre dar valor añadido, el que
busca el cliente.
La mejora continua es la base del espíritu Kaizen. Kaizen es una palabra japonesa que significa literalmente
“cambio bueno” y en la industria es conocida como manera de mejorar la calidad de un proceso de
fabricación.
15/104
Por ejemplo:
Rechazando el estado actual de las cosas.

En lugar de explicar lo que no se puede hacer, reflexionando cómo hacerlo mejor.
Realizando propuestas de mejora.
No buscando la perfección.
Corrigiendo los errores inmediatamente.
Probando, verificando y validando.
En japonés, la palabra muda significa desperdicio. Y esta es otra de las palabras clave dentro del sistema
Lean, dado que es el desperdicio lo que se intenta evitar. Veamos los tipos de desperdicio contra los que
lucha la filosofía Lean:
Transporte.
Inventario.
Movimiento.
Espera.
Sobreproducción.
Procesado extra.
16/104
Defectos.
4.2.1. 5S
La empresa de Ohno, Toyota, creó el sistema de las 5S, en el que hoy se basa la teoría del sistema Lean.
Seiri
Subordinar, clasificar o descartar.
La primera tarea es analizar cuáles son los elementos indispensables de un proceso con la intención de
descartar los que no resulten útiles.
Seiton
Sistematizar, ordenar.
Según se ha realizado en el paso anterior se ordenarán los elementos, nombrándolos correctamente

mediante etiquetaje, ordenándolos en estantes u otros muebles, etc.
Seiso
Sanear, limpiar.
La limpieza es un factor clave en la filosofía Lean. A efectos prácticos, significa que a diario se identificará
y saneará cualquier elemento que pueda perjudicar de alguna manera al proceso productivo.
Seiketsu
Simplificar, estandarizar y volver coherente.
Para crear un proceso sistemático con los tres primeros puntos (seiri, seiton y seiso ). Es decir, una rutina
de clasificación, orden y limpieza.
17/104
Shitsuke
Sostener, disciplinar el proceso.
Sería la “S” que busca mantener el estándar creado en la cuarta “S”, seiketsu.
4.2.2. 7 mudas
La filosofía Lean aplicada al desarrollo de sistemas se denomina Lean Software Development, y la aplicada
a la dirección de proyectos, Lean Project Management. Esta se basa en siete principios de gestión muy
básicos:
Definir el final a entregar.
Trazar la corriente de valor.
Establecer el flujo de la entrega.
Diferir las decisiones (trabajar pull).
Estandarizar la perfección (aplicar las 5S).
Aumentar el aprendizaje.
18/104
Optimizar el conjunto (reducir las 7 mudas).
En un proyecto, la filosofía Lean implica entregar valor muy rápidamente, reducir la duración de cada ciclo
de entrega o de la interacción con el cliente. Ello lleva a un aumento en la productividad, reduciendo
retrasos y ayudando a detectar errores en las primeras etapas del proyecto, disminuyendo, en
consecuencia, la cantidad total del trabajo necesario para finalizar cada uno de los trabajos que quedan por
hacer.
La figura 4 sirve de esquema visual de los siete principios de la filosofía Lean:
Figura 4. Siete Principios de la filosofía Lean.

Fuente: elaboración propia.
4.3. Agile
Los proyectos ágiles son un conjunto de metodologías dirigidas al desarrollo de proyectos que requieren
rapidez y flexibilidad en su proceso; en la mayoría de las ocasiones estos proyectos están vinculados con
el desarrollo de software y el ámbito digital.
Las metodologías ágiles de gestión de proyectos nacieron gracias al dinamismo del mundo empresarial
contemporáneo, en el que los métodos tradicionales de gestión no fueron tan eficientes, y aunque cuentan
con muchas aplicaciones en el mundo de hoy, tienen su origen en los proyectos informáticos.
19/104
Cuando se aplicó la gestión tradicional a los proyectos relacionados con la informática, no se obtuvieron
resultados tan buenos, pues estos requieren de cambios constantes y adaptaciones, de una comunicación
más continua, y de menos planificación, ya que al demandar tantas modificaciones eventualmente los
planes realizados en un primer momento pasan a un segundo plano de importancia.
Figura 5. Historia de Agile
Figura 5. Historia de Agile.

Fuente: Peter Muryshkin. Wikipedia Commons.
Como se puede ver en el diagrama de la figura 5, en la década de los noventa y a principios de los años
dos mil, se aplicaban una serie de metodologías de desarrollo de aplicaciones que, aunque diferían en una
amplia variedad de aspectos, poseían un núcleo ágil. Sus practicantes son los que crearon, redactaron y
suscribieron el Manifiesto Ágil. En la actualidad, todas ellas se siguen utilizando, pero se circunscriben al
sector de desarrollo de sistemas digitales.
Como veremos, Kanban y Scrum han dado el salto fuera de dicho sector y son utilizadas ampliamente por
los directores que gestionan proyectos con ciclo de vida adaptativo, en cualquier sector industrial.
20/104
Figura 6. The Agile Pyramid – Values, Principles and Methods
Figura 6. The Agile Pyramid – Values, Principles and Methods.

Fuente: Flicker AgileLion Institute.
4.3.1. Extreme programming (XP) o programación extrema
La extreme programming (XP) o programación extrema, que fue creada en la Chrysler Corporation, se
utiliza desde la década de los noventa. La XP intenta disminuir el coste de los cambios de las
aplicaciones, controlando su diseño a lo largo de su ciclo de vida. Las características clave de la
XP incluyen desarrollo incremental, horarios flexibles, pruebas automatizadas, comunicación verbal,
diseño evolutivo e involucración de todos los interesados. La XP valora la simplicidad y el valor
agregado de cada función desarrollada, conseguida mediante la comunicación y retroalimentación de los
usuarios finales.
21/104
En el enfoque de la XP hay distintos roles: cliente, desarrollador, rastreador y entrenador. Prescribe

varias prácticas de codificación, desarrollo y análisis de negocio, e incorpora eventos y artefactos para
implementarlas con orden. La XP ha sido muy extensamente aplicada debido a lo bien definidas que
están tales prácticas de ingeniería del software.
No se puede decir que las metodologías ágiles no se planifican. La figura 7 muestra los distintos niveles
en la planificación en XP: la planificación diaria, las iteraciones y los planes de lanzamiento o release
plans.
Figura 7. XP-feedback.
Fuente: SonWells. Wikipedia Commons.
4.3.2. Crystal methods o métodos Crystal
Las metodologías Crystal fueron creadas por Alistair Cockburn a principios de la década de los noventa
para optimizar el desarrollo de software. Los métodos Crystal se centran en las personas, por lo que son
ligeros y fáciles de adaptar a los requerimientos y características específicos del desarrollo. Las variables
del proyecto que juegan un papel importante para determinar el “peso” de la metodología son el tamaño del
equipo de desarrollo y la criticidad del proyecto para la compañía. La criticidad se clasifica en cuatro
niveles: confort (C), discrecional (D), esencial (E) y vital (L). El tamaño del equipo, en cinco niveles, crystal
clear (cristal claro) si no supera los seis, crystal yellow (cristal amarillo) si está entre siete y 20, crystal
orange (cristal naranja) si se encuentra entre 21 y 40, crystal red (cristal rojo) para entre 41 y 80 y crystal
maroon (cristal marrón) si tiene entre 81 y 200.
22/104
Existen, por tanto, 20 métodos Crystal diferentes, con “pesos” específicos. Todos ellos contemplan
cuatro roles: patrocinador ejecutivo (executive sponsor), diseñador líder (lead designer), desarrolladores y
usuarios experimentados. Los métodos Crystal recomiendan numerosas estrategias y técnicas para lograr
agilidad. El ciclo de vida de un proyecto Crystal tiene tres fases: lanzamiento (chartering), entrega (delivery)
y cierre (wrap-up ).
Clear Yellow Orange Red Marrón
Nivel de Vital L6 L20 L40 L80 L200
criticalidad
Esencial E6 E20 E40 E80 E200
Los defectos Discrecional D6 D20 D40 D80 D200
del sistema Confort C6 C20 C40 C80 C200
pueden
causar 1-6 7-20 21-40 41-80 81-200
pérdidas
N. de personas involucradas
4.3.3. Dynamic systems development methods (DSDM) o métodos dinámicos

de desarrollo de sistemas
El marco de métodos dinámicos de desarrollo de sistemas (DSDM), que fue publicado en 1995, es
administrado por el consorcio DSMS. Al principio del proyecto, el DSMS fija el esfuerzo a realizar, en
términos de coste y tiempo, priorizando los entregables del proyecto, mediante la técnica denominada
MoSCoW, en las siguientes categorías: “tiene que tener” (must have), “debería tener” (should have),
“podría tener” (could have) y “no tendrá, por ahora” (won’t have).
El DSDM desarrolla los sistemas mediante un ciclo de vida con seis fases distintas: preproyecto, viabilidad,
fundamentación, codificación e ingeniería, instalación y evaluación.
4.3.4. Feature driven development (FDD) o desarrollo basado en

características
El desarrollo guiado por características (FDD), que fue desarrollado por Jeff De Luca en 1997, se basa en
el principio de que para completar un desarrollo conviene fragmentarlo en pequeñas funciones o
características que puedan ser valoradas por el cliente y que puedan ser realizadas en menos de dos
semanas. El FDD tiene dos principios fundamentales: el desarrollo de software es una actividad humana y
es una funcionalidad valorada por el cliente.
El FDD define seis roles principales:
Director del proyecto.
23/104
Arquitecto jefe.
Gestor del desarrollo.
Jefe de programadores.
Propietarios de clase.
Expertos de dominio, aunados a una serie de funciones complementarias.
El proceso FDD es iterativo, comienza con el desarrollo de un modelo general para crear después una lista
de características y, a continuación, diseñar y crear cada una de ellas.
4.3.5. Test driven development (TDD) o desarrollo guiado por pruebas
El desarrollo guiado por pruebas (TDD), también conocido como “desarrollo priorizando las pruebas”, fue
creado por Kent Beck, uno de los creadores de la XP. El TDD es un método de desarrollo de software que
preconiza desarrollar la cantidad mínima de código necesario para realizar una prueba, antes de seguir
desarrollando.
Todo el proyecto se divide en pequeñas características, que el cliente valora y prioriza, que deben
desarrollarse lo más rápido posible.
Las pruebas se redactan con los requerimientos y especificaciones del cliente. Las pruebas se utilizan para
mejorar el diseño y la redacción del código restante. Las pruebas se desarrollan para actuar en dos
niveles: de aceptación, o acceptance TDD (ATDD), y de desarrollo, o developer TDD (DTDD). Debido a
las numerosas ventajas que ofrece el TDD (tales como resultados fiables, retroalimentación constante y
reducción de los tiempos de depuración o debugging), este método ágil se ha hecho bastante popular.
4.3.6. Adaptive software development (ASD) o desarrollo adaptativo de

software
24/104
El desarrollo adaptativo de software (ASD) es un método para acelerar el diseño y la programación de

aplicaciones creado por Jim Highsmith y Sam Bayer. Los aspectos más destacados del ASD son la
constante adaptación de los procesos de trabajo, el suministro rápido de soluciones a los problemas que
surjan y el desarrollo iterativo e incremental, mediante el uso continuo de prototipos.
El ASD es un método de desarrollo que es muy tolerante al cambio, que renuncia a las planificaciones y
acepta la incertidumbre y el riesgo.
El desarrollo se guía por metas y se basa en ir completando pequeñas características. La primera fase en
este tipo de desarrollo es la especulación, renunciando a la planificación, que va seguida de las fases de
colaboración y aprendizaje.
4.3.7. Domain driven design (DDD) o diseño guiado por dominios
El diseño guiado por el dominio (DDD) es un método de desarrollo ágil que sirve para manejar desarrollos
muy complejos que se implementan a través de un modelo evolutivo. Creado por Eric Evans en el año
2004, el método se articula en torno al diseño de un modelo o “dominio central”. El término dominio se
refiere al área de trabajo en la que el usuario aplica el programa o una funcionalidad. Muchas de estas áreas
son procesadas por lotes y, en consecuencia, se diseña un modelo que se puede utilizar para solventar los
problemas relativos a los dominios de cada lote. Los valores fundamentales del DDD son diseño orientado
al dominio, guiado por el modelo, en lenguaje ubicuo y contexto limitado.
En DDD se lleva a cabo una refinación y refactorización del modelo hasta que sea satisfactorio.
4.3.8. Agile unified process (AUP) o proceso unificado ágil
El proceso unificado ágil (AUP) es una evolución del IBM’s rational unified process o proceso unificado
racional (RUP) de IBM. Desarrollado por Scott Ambler, el método AUP combina técnicas ágiles
contrastadas, tales como el desarrollo guiado por pruebas (TDD), el modelado y la gestión de cambios ágil
y la refactorización de las bases de datos. El AUP se enfoca en funcionalidades de alto valor y modela sus
procesos y técnicas basándose en valores tales como la simplicidad, la agilidad, la personalización, la
autorganización y la interdependencia.
El AUP trabaja con cuatro fases: incepción, elaboración, construcción y transición.
4.3.9. Kanban
Esta metodología funciona mejor con proyectos cortos. Kanban propone una planificación y aplicación
sencilla, sin embargo, es difícil de manejar cuando el volumen de trabajo es elevado o la dificultad de las
tareas a realizar va en aumento.
Aplicados de la manera correcta, estos tres modelos de gestión son beneficiosos en cualquier proyecto, no
solo para la propia organización, sino también para los clientes.
25/104
En las fábricas de Toyota, en las que se aplicaba Lean, se utilizaba una herramienta muy práctica,
denominada Kanban, que facilitaba enormemente la aplicación de los principios de trabajo en dicha
filosofía. Adoptada por los seguidores del Manifesto Agile, se trata de una herramienta muy utilizada a la
hora de aplicar los procedimientos y la técnica del cualquier marco ágil.
La palabra japonesa kanban significa literalmente “panel visible”, y de este se deriva el uso de una ayuda
visual para dar seguimiento a la producción. Al igual que en el caso del modo de pensamiento Lean, fue
Taiichi Ohno, considerado como el padre de los sistemas de producción Toyota (TPS) y los sistemas
just in time (JIP, justo a tiempo), el que introdujo el concepto Kanban. Estos métodos apuntan a que la
producción se base en pull o demanda de los clientes y no en la práctica tradicional push de fabricar
productos e intentar venderlos en el mercado. Es un sistema de arrastre que usa ayudas visuales para
producir justo a tiempo y solo lo necesario. El uso de tarjetas y pizarras es tan eficaz que se ha
convertido en una práctica común, no solo en los sistemas de producción, también en el desarrollo de
sistemas digitales. Por ejemplo, tarjetas de historias de usuario, de tareas, pizarras Scrumban y otras.
La atención prestada a tales métodos fue debida al éxito experimentado en Toyota, empresa líder en
gestión de procesos. Estos facilitan la integración de los principios Lean a través de la transparencia
mediante el uso de métodos de visualización tipo Kanban. La industria del software se percató de que
Kanban podía hacer un cambio real en la forma en la que se producían y entregaban las aplicaciones y
los servicios informáticos. Se demostró que Kanban era conveniente no solo para la industria
automotriz, sino también para cualquier otro tipo de industria.
Kanban
La herramienta Kanban más básica es un tablero compuesto por tres columnas, como se observa en la
figura 8: Por hacer, En proceso y Hecho . Si se aplica bien y funciona correctamente, serviría como una
fuente de información, ya que muestra dónde están los cuellos de botella en el proceso y qué es lo que
impide que el flujo de trabajo sea continuo e ininterrumpido.
26/104
Figura 8. Simple Kanban Board.

Fuente: Jeff.Iasovski Wikipedia Commons.
Hay seis prácticas centrales identificadas que deben estar presentes para una implementación con
éxito de las herramientas de visualización Kanban:
Visualizar el flujo de trabajo
Lo primero y lo más importante es entender qué se necesita realizar en el proceso. Solo después de
entender cómo funciona actualmente el flujo de trabajo, se puede aspirar a mejorarlo haciendo los
ajustes necesarios. Para visualizar el proceso en Kanban, se necesitará un tablero con tarjetas y
columnas. Cada columna del tablero representa un paso en el flujo de trabajo. Cada tarjeta Kanban
representa un elemento de trabajo. Cuando se comience a trabajar en un elemento, se arrastra hasta la
columna Por hacer, y cuando el elemento esté acabado, se mueve hasta la columna Hecho . De esta
forma, se puede fácilmente seguir el progreso y detectar cuellos de botella.
Eliminar las interrupciones
Muchas tareas en la segunda columna pueden dañar seriamente el proceso y podrían provocar
desperdicios. Esta es la razón por la cual Kanban se enfoca en establecer unos límites del trabajo en
proceso (WIP), porque se aplica un sistema de arrastre (pull) sobre todo el flujo de trabajo.
Establecer un número máximo de elementos para la segunda columna asegura que una tarjeta se
“arrastra” a ella solo cuando hay capacidad disponible. Tales restricciones iluminarán rápidamente los
cuellos de botella del flujo para que se puedan identificar y resolver.
Gestionar el flujo
La idea de implementar un sistema Kanban es crear un flujo continuo e ininterrumpido de trabajos. El

flujo refiere al movimiento de elementos de trabajo a través del proceso. Deben interesar tanto la
velocidad como la continuidad del flujo. Idealmente, se querría un flujo rápido e ininterrumpido.
27/104
Fomentar la visibilidad de los trabajos
No se puede mejorar algo que no se entiende, porque no se visualiza. Esta es la razón por la cual el
proceso debe estar bien definido, publicado y promovido. Cuando los trabajadores estén
familiarizados con el proceso que realizan, podrán tomar decisiones con respecto a cómo mejorarlo.
Sincronizar mediante retroalimentación
Para que el cambio positivo ocurra, tenga éxito y sea duradero, se precisan reuniones regulares para
hacer retroalimentación y transferencia de conocimiento. Estas han de ser diarias y de pie, se llevan a
cabo frente al tablero Kanban y cada miembro comparte con los demás lo que hizo el día anterior y
qué va a hacer en el día de hoy. A la hora de sincronizar el equipo también existen reuniones de
revisión de entregas, de revisión de operaciones y de revisión de riesgos. Deben ser regulares, a una
hora fija, con una duración de entre 10 y 15 minutos.
Mejora mediante colaboración
Los equipos que tienen un entendimiento compartido de los flujos de trabajo, los procesos realizados
y los riesgos que conllevan tienen una comprensión compartida de los problemas, son capaces de
sugerir acciones de mejora y pueden acordarlas por consenso.
Kanban es algo más que pegar notas adhesivas en una pizarra, hay que aceptar la transparencia de
filosofía y aplicarla al trabajo diario. Visualizar el flujo de trabajo, establecer los límites del trabajo en
proceso, gestionar el flujo, asegurar que las políticas explícitas y las mejoras se propongan mediante
colaboración es el verdadero poder de Kanban, mucho más de lo que se pueda imaginar de una
herramienta tan sencilla.
4.3.10. Scrum
Scrum es uno de los métodos ágiles más utilizados. Es un marco de gestión adaptable, iterativo, rápido,
flexible y eficaz, diseñado para entregar, rápidamente, valor considerable a lo largo del proyecto.
Scrum pretende garantizar transparencia en la comunicación, así como crear un ambiente de

responsabilidad colectiva. El marco Scrum está estructurado de tal manera que es compatible con el
desarrollo de productos y servicios en todo tipo de industrias y en cualquier tipo de proyecto,
independientemente de su tamaño y complejidad.
28/104
Hirotaka Takeuchi y Ikujiro Nonaka definieron, a mediados de la década de los ochenta, un método
innovador para el desarrollo de productos al que llamaron enfoque “rugby”, “donde un equipo intenta
llegar hasta el final como una unidad, pasando el balón hacia atrás y adelante”, en lugar de hacerlo
secuencialmente, como en una carrera de relevos. Basaron su enfoque en los estudios de casos de diversas
industrias de fabricación. El concepto de un scrum de rugby, donde los dos equipos juntan sus cabezas
para reiniciar el juego, fue utilizado como metáfora de que el desarrollo de productos debe implicar que el
cliente y los desarrolladores junten las cabezas de vez en cuando. Ken Schwaber y Jeff Sutherland
desarrollaron el concepto de Scrum y su aplicabilidad al desarrollo de software en una presentación hecha
en un congreso de programación realizado en 1995 en Austin, Texas. Desde entonces, varios practicantes y
expertos han perfeccionado la mentalidad y el marco Scrum (Rawsthorne y Shimp, 2011; PMI, 2017). En
los últimos años, Scrum se ha convertido en el método de desarrollo de proyectos predilecto de muchas
organizaciones a nivel mundial. Una fortaleza clave de Scrum radica en el uso de equipos interfuncionales,
autoorganizados y facultados que dividen su trabajo en ciclos de trabajo cortos llamados carreras o sprints .
Figura 9. Metodologías Agile.

V. El agilismo. ¿Qué son las metodologías ágiles?
5.1. La herencia industrial

Las metodologías que se pueden denominar ágiles de desarrollo de software nacen en la plenitud de la era
industrial. La producción industrial venía de un modelo de Taylor que funcionaba en su área, pero que
pecaba de ser burocrático, estructurado y muy estricto en las formas.
Con el tiempo, estos métodos de ingeniería industrial fueron adaptándose a la producción de software,
pero no se adaptaban eficazmente al entorno en el que se desarrollaban normalmente este tipo de
proyectos, como, por ejemplo, el modelo en V o en cascada.
29/104
Metodología en cascada
La metodología en cascada es un proceso de ingeniería basado en un modelo lineal de diseño. El

proyecto, o el software, se desarrolla siguiendo un modelo secuencial y estricto donde todas las
decisiones se toman durante las fases iniciales del proyecto: planificación, análisis y diseño. El aspecto
más importante del modelo de cascada es que ninguna de las etapas se puede comenzar antes de que la
fase anterior haya sido completada. El ciclo de vida del software tiene que seguir la secuencia. Una vez
tomadas las decisiones, las fases de desarrollo y de test completan el producto que se entrega al cliente.
Desarrollo en cascada
El modelo de desarrollo en cascada pone todo el énfasis en la planificación del proyecto. Antes de
comenzar a fabricar el producto, un grupo de “expertos” define las pautas que marcarán la dirección del
desarrollo y del test. Este tipo de metodologías son válidas para fabricar coches o maquinarias de forma
industrial, pero no lo son para fabricar software. No se puede tener equipos donde unos piensan y otros
hacen. Y mucho menos desarrollos donde una vez tomada una decisión no se tienen mecanismos para
poder modificarla sin que impacte brutalmente en el producto. La nueva era tecnológica necesita nuevas
formas de trabajo para el desarrollo del software.
5.2. La revolución tecnológica
Los principios en los que se basan las metodologías ágiles que se conocen hoy en día no son nuevos. Las
metodologías iterativas e incrementales para el desarrollo de software existen desde mediados de los años
cincuenta. Por aquel entonces, empresas como IBM hablaban ya de este tipo de desarrollos para algunos
de sus productos.
Fue en los años setenta cuando se pusieron de moda la gestión de proyectos evolutiva y el desarrollo
de software adaptativo. Estos nuevos métodos estaban orientados a aceptar la posibilidad de constantes
cambios en los requisitos del software debidos a la evolución de la comprensión que el equipo de trabajo y
el cliente adquieren durante la codificación del producto.
Takeuchi y Nonaka, en el artículo “The new new product development game”, de 1986, describieron una
nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos
productos comerciales. Este famoso artículo analizaba las características comunes en el proceso de
desarrollo de productos exitosos en los sectores de la automoción, el hardware y la electrónica,
concluyendo que los procesos que diferenciaban estos proyectos, respecto de otros menos exitosos, eran
el enfoque iterativo de prueba y error, el solapamiento de las distintas fases y su gestión por equipos de
desarrollo multidisciplinares y autogestionados.
La figura 10 muestra que este enfoque en el desarrollo de nuevos productos implicaba la interacción
constante del equipo de principio a fin, “desplazando la melé” (scrum), en contraposición al enfoque
secuencial de las metodologías tradicionales.
30/104
Figura 10. “The new new product development game”
Figura 10. “The new new product development game”.

Fuente: Harvard Business Review.
Posteriormente, en la década de los noventa, se comenzó a hablar de metodologías de desarrollo

rápido de software (rapid application development) que, haciendo uso de procesos evolutivos y
apoyadas en entornos de trabajo bien definidos como el proceso unificado, trataban de hacer uso de
patrones de desarrollo que acelerasen la creación de software en una era orientada a la producción
industrial. Estos entornos de trabajo resultaron muy pesados y lentos para un mercado en constante
cambio y, como consecuencia, surgieron tendencias que intentaron hacerlos más ligeros en su gestión.
Los lightweight development methods nacieron a mediados de esta década: metodologías como Scrum
(1996), Crystal clear o programación extrema (XP, 1997) se hicieron cada vez más populares.
Durante la primera década del siglo xxi se creó un grupo de discusión que comenzó a hablar sobre este
tipo de metodologías. Fue en febrero del año 2001 cuando se reunieron en Utah (EE. UU.) 17 expertos
de la industria del software para definir el término Agile o ágil. Juntos, publicaron el manifiesto ágil para
el desarrollo del software. Su objetivo era describir el conjunto de valores y principios que deberían
permitir a los equipos de desarrollo producir software de una forma eficaz, respondiendo a los cambios
que pudiesen surgir a lo largo de un proyecto.
31/104
Esta reunión dio lugar a lo que hoy conocemos como la Agile Alliance, un grupo creado para definir y
guiar las prácticas ágiles, sus términos y elementos, así como las interpretaciones y guías basadas en la
experiencia de una comunidad Agile que se ha ido extendiendo por todo el mundo.
5.3. El agilismo y los principios ágiles

En español se hace uso de la palabra agilismo como una traducción directa del término inglés agile.
También se hace uso de términos como desarrollo ágil de software, metodologías ágiles e incluso,
directamente, del término agile, sin traducción alguna.
El desarrollo ágil de software describe un conjunto de valores y de principios que son aplicables a la
creación del software donde los requisitos y la solución final evolucionan a través de un esfuerzo
colaborativo de equipos multidisciplinares que se gestionan de forma autónoma. El agilismo hace referencia
a procesos de planificación adaptativa, desarrollo evolutivo, entrega pronta y uso de procesos de mejora
continua.
Pero ¿de dónde viene el término agilismo o agile ?
En febrero de 2001, un grupo de 17 profesionales y administradores del sector informático, dedicados

al desarrollo de software, crearon la asociación denominada Alianza Agile (Agile Alliance), dedicada a
discutir los métodos de gestión que les proporcionaban mejores resultados.
32/104
En los debates de estas reuniones se redactó el Manifiesto por el desarrollo ágil de software (Manifesto
for Agile Software Development). Escrito por Fowler y Highsmith (2001), fue suscrito por los 17
miembros de la Alianza Agile con el fin de establecer las bases para alinear cualquier método que llevara
el calificativo de ágil.
Figura 11. Firmantes del Manifiesto por el desarrollo ágil de software.

Fuente: Manifiesto Ágil, 2001.
33/104
El término agile fue popularizado por el Manifesto Agile, que se puede leer traducido al español en la
siguiente figura.
Figura 12. Manifesto for Agile Software Development.

Fuente: Manifiesto Ágil, 2001.
En este manifiesto, escrito por 17 desarrolladores de software en un contexto muy concreto, se

encuentran los cuatro valores que todo agilista debe tener siempre presentes.
5.3.1. Individuos y relaciones sobre procesos y herramientas
Aunque los procesos y las herramientas ayuden a completar un proyecto con éxito, son ante todo las
personas que participan en el proyecto las que determinan cuáles utilizar. Así, las personas son la clave
en cualquier proyecto de desarrollo, y, en consecuencia, el énfasis debe ponerse en ellas y sus
relaciones.
Los proyectos de software van sobre personas y sobre relaciones. Los procesos y herramientas
impuestos por una organización son importantes, pero es mucho más importante tener un equipo
autoorganizado, que esté motivado y que sea capaz de comunicarse y colaborar de una forma sana.
Es más importante construir un buen equipo que construir el entorno de desarrollo. Conceptos como
colocalización de las personas y la programación por parejas facilitan que los individuos se relacionen y
evitan tener un conjunto de expertos que trabajen de forma aislada.
34/104
5.3.2. Software funcionando sobre documentación extensiva
Aunque la documentación es necesaria y útil, el valor real que se entrega al cliente es, ante todo, un
software funcionando correctamente. El enfoque ágil se centra en la entrega pronta y constante de
elementos funcionando, hecha incrementalmente a lo largo del ciclo de vida de desarrollo.
A los clientes les gusta que los proyectos estén bien documentados, pero ellos no pagan por tener un
conjunto de documentos que hablen sobre su producto, sino por un producto que les permita
desarrollar su necesidad de negocio. Tener un software funcionando es mucha mejor carta de
presentación que simplemente entregar documentos a un cliente sobre lo que se va a hacer. La
documentación no es solo hacer uso de un editor de texto, un proyecto de software está bien
documentado cuando su código está bien explicado y descrito.
5.3.3. Colaboración con el cliente sobre negociación contractual
El único que sabe la forma que tiene que adoptar el producto que hay que desarrollar es el cliente. El
equipo de desarrollo trabaja unido con el cliente para evolucionar y desarrollar la aplicación, empleando
un enfoque de valor compartido en el que clientes y desarrolladores son colaboradores. La relación con
los clientes no se puede basar en el cumplimiento del contrato, su participación no debe ser solo al
principio y al final del desarrollo.
Los requisitos han de recopilarse trabajando directamente con el cliente y jamás se podrá hacerlo
exclusivamente al principio de un proyecto. La mejor forma de trabajar en un proyecto de software es
trabajar con el cliente y con los usuarios directamente involucrados y obtener de forma progresiva los
requisitos que se adapten a sus necesidades según evoluciona el producto.
5.3.4. Respuesta ante el cambio sobre seguir un plan
Agilismo es cambio. El desarrollo de software que hace uso de metodologías ágiles debe permitir el
cambio y debe ser capaz de reaccionar rápidamente ante nuevas necesidades del cliente. No importa que
el plan cambie, importa que el producto tenga la forma exacta que necesita el cliente, y el cliente será
capaz de dar esa forma a medida que profundice en el universo del problema que intenta resolver.
En los mercados actuales, donde los requerimientos del cliente, las tecnologías disponibles y los
patrones empresariales experimentan cambios constantemente, es imprescindible abordar el desarrollo
de aplicaciones adaptativamente, permitiendo la incorporación del cambio. No hay que enfatizar en el
seguimiento estricto de un plan que, seguramente, quedará obsoleto muy rápidamente.
Manifiesto Ágil
35/104
5.3.5. Principios derivados del Manifiesto Ágil
Tras los cuatro valores descritos en el Manifesto Agile, los firmantes redactaron los 12 principios que
de ellos se derivan.
1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de

software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos
ágiles aprovechan el cambio para proporcionar una ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al
periodo de tiempo más corto posible.
4. Los responsables del negocio y los desarrolladores trabajamos juntos de forma cotidiana durante
todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el
apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores y
usuarios debemos mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación,
ajustar y perfeccionar su comportamiento en consecuencia.
Principios del Manifiesto Ágil
5.3.6. Aplicar este manifiesto a otros sectores no TI
Las metodologías Agile promueven equipos de trabajo en entornos de adaptación, autoorganizados, y

entregas rápidas que permiten que el cliente se involucre tempranamente en el proyecto.
El término project management 2.0, acuñado por el Dr. Kerzner, recoge todas las tendencias actuales
sobre una gestión de proyectos cada vez más colaborativa, en la que el PM es más un facilitador del
proyecto en un entorno de información abierta y compartida gracias a la tecnología.
Como se puede deducir de los valores y los doce principios del Manifiesto Ágil, la agilidad es un mito.
No precisa realizar unos procesos determinados para afirmar que se están siguiendo los principios
ágiles. De hecho, se podrían aplicar todos estos principios a muchos de los proyectos, sin más,
eliminando la palabra software.
36/104
Para los fundadores de Agile Alliance, no es muy correcto hablar en términos de “ser ágil”, sino más
bien de “llegar a ser ágil”. La agilidad, tal y como se entiende de los documentos y bibliografía
autorizada, es un viaje hacia los principios llamados ágiles. Se trata de pensar, de preocuparse y de llegar
a ser (ágil).
5.4. Proyectos tradicionales vs. proyectos ágiles
El entorno en el que se desarrollan hoy en día muchos de los proyectos se aleja de lo que se puede
considerar un marco estático en el que se es capaz de definir de forma cierta y concreta cuál va a ser el
producto o servicio final resultado del proyecto. Por el contrario, hay costumbre de hablar de entornos
VUCA como el nuevo ecosistema en el que las empresas compiten, y deben desarrollar nuevos productos
y servicios.
Estos entornos se caracterizan por lo siguiente:
Se desarrollan los proyectos en entornos volátiles, en los cuales se puede esperar gran cantidad de
cambios espontáneos de forma imprevista. Estos cambios estarán solicitados por el propio cliente, pero
también por el entorno, los propios colaboradores, las condiciones del mercado, la competencia, etc.
Entornos inciertos en los que nunca se tendrá toda la información respecto al proyecto.
Complejos, en la medida en que, cada vez más, los proyectos tienen derivadas y conexiones con todos
los departamentos de la organización. Existen numerosas interdependencias entre unidades de negocio,
clientes, proveedores, etc., que convierten al proyecto en ejercicios transversales (aunque sea un
proyecto de software).
La ambigüedad obliga a trabajar en situaciones menos cómodas con falta de claridad acerca del
proyecto y sus objetivos. Como se ha visto, habrá demasiados interesados con expectativas diferentes,
y no todos entenderán lo mismo para un proyecto exitoso.
Luego, en estos entornos VUCA, en los que es imposible determinar de forma cerrada el alcance y la
planificación de un proyecto, una aproximación ágil a este puede resultar de gran ventaja.
5.4.1. La aproximación tradicional a la gestión de proyectos
37/104
Como se ha mencionado anteriormente, la metodología tradicional de gestión de proyectos es una herencia

directa del desarrollo de productos industriales a gran escala. En sectores como puedan ser el industrial o
el aeronáutico, los proyectos se planifican con antelación, son revisados por un grupo de expertos, se
estiman su alcance y coste y los llevan a cabo (según un plan predefinido) obreros cualificados capaces de
ejecutar ese plan.
Las metodologías tradicionales de gestión de proyectos proporcionan una estructura ordenada, organizada,
lógica y racional orientada a la ejecución de objetivos. Buscan la creación de entregables y de un producto
cumpliendo la triple restricción del triángulo de acero: tiempo, coste y alcance. El cliente propone un
alcance del proyecto, y el equipo de proyecto estima un coste y una duración, intentando que estas
estimaciones estén dentro de las restricciones que pueda marcar el cliente.
El ejemplo más extendido de metodología tradicional es el modelo en cascada. Este modelo fue presentado
por primera vez por Winston W. Royce en 1970. Royce era un ingeniero que trabajaba para la industria
aeroespacial y presentó este modelo como una forma defectuosa de desarrollar software. Originalmente,
Royce presentó el modelo en cascada como un modelo de dos fases: análisis y diseño. Su modelo fue
adoptado por la industria del software del momento y poco a poco se convirtió en un sistema de gestión
de desarrollo de software estándar dentro de la industria.
El modelo en cascada
El modelo en cascada evolucionado propone un total de cinco etapas que han de ejecutarse de forma
lineal (ninguna etapa puede comenzar sin que la anterior haya terminado) para llevar a cabo un proyecto
de software:
Figura 13. Fases de un proyecto típico en cascada, tradicional o predictivo.

Es en las fases de planificación, toma de requisitos y análisis en las que este modelo invierte más tiempo.
En estas fases, los expertos de negocio y de tecnología deberán definir el plan, la tecnología que se va a
utilizar y los casos de uso que se van a implementar durante el resto de las fases del proyecto. Después, el
equipo de trabajo se centra en cumplir con el plan de proyecto descrito durante las fases iniciales de
análisis y planificación. Por ello, el modelo en cascada necesita hacer un uso exhaustivo de la
documentación sobre todo el ciclo.
Este tipo de metodologías tradicionales, como la que se representan en la figura 13, tienen un gran
problema: es muy costoso enfrentarse a posibles cambios que puedan llegar a mitad del ciclo de
desarrollo. Estas técnicas presuponen que todo lo estimado y planificado está bien y que no habrá que
modificar nada una vez se ponga el plan en ejecución.
38/104
Entre las ventajas que ofrece el uso de un modelo de cascada, están las siguientes:
Al tratarse de un modelo lineal, es fácil de gestionar: métricas, tiempos y costes son gestionados de
forma natural con un modelo de gestión heredado de la producción industrial tradicional.
Permite estimar los recursos necesarios para su implementación: la planificación y la estimación inicial
permiten el cálculo de estos números.
Genera una gran cantidad de documentación que permite comprender mejor el desarrollo y entregar un
producto de mejor calidad al cliente.
Después de cada etapa, existe un conjunto de hitos que se revisan para cerrar el proceso con la calidad
necesaria.
Debido a las características propias de los métodos de gestión de proyectos predictivos o tradicionales,
siguen siendo los más adecuados para una serie de proyectos:
Proyectos relacionados con procesos generales y estables dentro de la organización.
Desarrollo de productos basados en especificaciones cerradas y determinadas, aunque se puedan

producir cambios a lo largo del proyecto. Son proyectos tradicionales aquellos propios del desarrollo
de infraestructuras, construcción, obras públicas, etc.
39/104
Proyectos en sectores donde sea obligatorio recopilar toda la documentación relativa al proyecto y los
procesos que se han llevado a cabo. Como, por ejemplo, proyectos para el desarrollo de
medicamentos, en los cuales una agencia externa auditará toda la documentación extensiva de los
procesos del proyecto; proyectos de desarrollo en automoción, con agencias que validan tanto el
resultado del proyecto como los propios procesos; etc.
Proyectos en los que la gestión de la configuración de la documentación y el proceso de control de

cambios deben estar perfectamente documentados y registrados.
Aquellos proyectos en los que la gestión de riesgos sea un área crítica para el éxito del proyecto.
Es por ello que la principal diferencia entre las metodologías tradicionales de gestión de proyectos y Agile
radica en el papel que juegan las iteraciones durante el proyecto. Los proyectos relacionados con
contenido inmaterial, como el software y el desarrollo de conocimiento, tienen mayor facilidad para iterar, y
aprovechan la flexibilidad que les proporciona Agile. Es evidente que los cambios constantes y las
iteraciones en este tipo de proyectos son asumibles y técnicamente viables. Por el contrario, en los
proyectos cuyo resultado hace un uso intensivo y caro de materiales, como los proyectos de construcción,
las iteraciones son irrealizables por la propia naturaleza del edificio, o el coste derivado de los cambios
durante el desarrollo del proyecto.
5.4.2. Los marcos de trabajo ágiles
Las metodologías ágiles nacen ante la impotencia de los equipos de desarrollo de adaptarse a un cliente y a
una industria en constante cambio. Son metodologías que dan mucha importancia a la capacidad de
respuesta a los cambios, a la confianza en las habilidades del equipo para llevarlos a cabo y a la implicación
del cliente durante todo el proceso de desarrollo del producto.
Las metodologías ágiles permiten tener velocidad ante la toma de decisiones, capacidad de afrontar los
cambios o situaciones imprevistas. Hacen uso de métodos sencillos y visuales, colaborativos y abiertos,
que permiten a todo el mundo comprender el estado del proyecto y participar en él.
Las características de Agile se traducen en una serie de fortalezas, como son las siguientes, que serán
una ventaja en proyectos en los que esta aproximación se adapte bien:
40/104
Reducir la documentación a lo mínimo necesario, convirtiendo el proyecto en un instrumento menos

burocrático y más práctico, enfocado al resultado.
La planificación se enfoca en la entrega temprana del producto mínimo viable, PMV.
Se perciben como procesos más flexibles y adaptables a cada proyecto/organización.
Las metodologías ágiles facilitan el empoderamiento del equipo.
Al carecer de un rol directivo como el project manager, se da más importancia de todo el equipo y a las
dinámicas necesarias para crear un equipo autoorganizado.
Debido a las características de este tipo de aproximación a los proyectos, es el marco idóneo para los
siguientes tipos de proyectos y sectores:
Proyectos de diseño y desarrollo de nuevos productos.
Desarrollo iterativo en que es fundamental lanzar un producto mínimo viable (PMV) lo antes posible al
mercado para su testeo.
Desarrollo de diseño. En proyectos de construcción se puede implementar un enfoque ágil a las fases
relacionadas con el diseño de la solución.
41/104
Proyectos cuyo entregable es la definición de las especificaciones de nuevos productos.
Proyectos en los que sea más importante hacer un seguimiento de la actividad diaria del equipo.
Creación de prototipos.
Figura 14. Waterfall vs. Agile
Figura 14. Waterfall vs. Agile.

Fuente: Share Alike 4.0 International.
En la figura 14 se muestra un esquema similar al que se veía en el artículo de Takeuchi y Nonaka (figura
10). Esta nueva distribución no solo afecta a la distribución de las fases, sino también a los componentes
que tendrá que tener un equipo capaz de realizar todas las fases.
5.4.3. Los marcos de trabajo híbridos
42/104
Muchos proyectos conviene realizarlos aplicando varios tipos de ciclos de vida, por ejemplo, con una
combinación de un ciclo de vida predictivo y otro adaptativo, por lo que se dice que se gestionan mediante
un ciclo de vida híbrido.
Aquellos elementos del proyecto o fases de su ciclo de vida que son bien conocidos o tienen requisitos
bien establecidos y fijados se desarrollan aplicando un ciclo de vida predictivo, mientras que a las fases
que presentan requisitos en evolución, o que se pueden beneficiar del feedback del cliente a lo largo de
distintas iteraciones, se les puede aplicar un marco adaptativo.
Un ejemplo de esta aproximación es el ciclo de vida de diseño y construcción de un edificio, que

normalmente es un ejemplo de planificación en cascada, desde la concepción, el diseño, la
preconstrucción, la construcción y la puesta en operaciones. Sin embargo, la fase de diseño es un buen
momento para utilizar un ciclo de vida adaptativo, volviendo al esquema en cascada una vez se termina esta
fase.
También es el marco de trabajo utilizado por la metodología de desarrollo de sistemas denominada Crystal
methods .
5.4.4. Criterios para elegir una aproximación ágil frente a la tradicional
El modelo tradicional o predictivo presupone un desarrollo y un test controlado porque ha sido

previamente estudiado, estimado y planificado. El proyecto ha quedado definido a la perfección cuando
entra en la fase de desarrollo y nada da lugar a equívoco.
Un problema con la planificación tradicional de los proyectos puede suceder cuando los principales
interesados interpretan las estimaciones del proyecto como compromisos asumidos por ambas partes.
Una estimación, por definición, es la probabilidad que se tiene de que algo ocurra de acuerdo con unos
valores, tiempo o coste normalmente. Una probabilidad no es una fecha concreta ni una cantidad fija de
dinero. El compromiso no puede definirse en términos de probabilidad.
Otra de las razones principales por las que una planificación predictiva no resulta efectiva en entornos
cambiantes es debida a que no se cuenta con la incertidumbre del proyecto. Se asume que los usuarios
del proyecto no van a cambiar sus preferencias, refinar su producto ideal, o no van a aparecer con
nuevas ideas durante la ejecución del proyecto.
La incertidumbre del proyecto también se puede referir a las cuestiones que afectan a las decisiones
técnicas del equipo de proyecto. Las estimaciones y planificación del proyecto dependerán de las
decisiones técnicas sobre la tecnología o las hipótesis que se tomen sobre el proyecto, cuestiones que son
difíciles de concretar al inicio de este.
43/104
Si se miran las predicciones desde un punto de vista técnico: la tecnología cambia, falla, no hace lo que
se creía, necesita parches y reparaciones de terceros y no funciona tan rápido como se pensaba.
Si se miran las predicciones desde un punto de vista de negocio: el cliente no sabe lo que quiere cuando
el proyecto arranca, su forma de ver el producto cambia a medida que comprende el universo de su
negocio y sus necesidades pueden cambiar tan rápido como los servicios que ofrece a sus clientes.
Al enfrentarse a proyectos poco claros y cambiantes, la aproximación predictiva o tradicional, en la que

primero se estima una hipótesis para luego desarrollar esa hipótesis esperando haber acertado en la
predicción del proyecto, no sirve. Considerando lo problemático que resulta cumplir con lo estimado,
resulta lógico que muchos profesionales del entorno Agile se hayan planteado si aporta valor invertir
demasiado tiempo planificando un proyecto. Resulta más lógico pasar directamente a las fases de
desarrollo, sin invertir demasiado tiempo en planificar previamente algo que no se cumplirá.
El modelo Agile no permite volver atrás; si la fase de diseño ha sido mal ejecutada, la fases de desarrollo
y test se convertirán en un infierno.
El cliente nunca sabe lo que quiere. Pero no lo hace por molestar, lo hace porque nunca ha
profundizado lo suficiente en su necesidad de producto hasta que no tiene algo usable entre manos. Por
eso, afirmar que las fases de análisis y diseño son suficientes para describir el producto final es un grave
error: el cliente irá mejorando su propia visión del software a medida que profundice en su conocimiento
sobre el medio.
El cliente en Agile obtiene algo que le aporta valor al negocio lo antes posible.
¡Y qué decir de la documentación del proyecto! Un documento creado durante la fase inicial de análisis
ha de actualizarse constantemente durante toda la vida del proyecto tradicional y, sobre todo, durante las
fases de desarrollo y test. Será ahí donde será posible darse cuenta de los errores por falta de
conocimiento y costará documentar de nuevo en esta fase lo que no se supo hacer en aquel momento.
44/104
Como se verá en esta unidad, las metodologías ágiles ayudarán a resolver de una forma más eficiente
muchos de los problemas planteados por el modelo en cascada tradicional. Especialmente aquellos más
vinculados al cambio y a la relación con el cliente.
METODOLOGÍAS ÁGILES
Las metodologías ágiles permiten una mayor libertad. Al estar orientadas a entregar producto de forma
continua, el cliente verá que su dinero produce código desde el principio. Si bien es cierto que el código
inicial no generará el funcionamiento deseado, también lo es que el cliente puede probar su producto
desde el principio y opinar sobre aquello que le gusta o no le gusta.
Son metodologías especialmente efectivas cuando el objetivo del proyecto no está claramente definido
o cuando el cliente no sabe aún cuáles son las necesidades exactas de su producto. El proceso de
retroalimentación mutuo entre el equipo de desarrollo y el cliente directo facilita que ambos comprendan
sus necesidades y problemas y que el producto final vaya convergiendo hacia un punto común que
satisfaga a todos.
Como la metodología está orientada a dar soporte al cambio, el cliente puede cambiar el rumbo de su
aplicación cuando lo crea conveniente y adaptar así el producto final a sus necesidades a medida que
comprende mejor su caso de negocio.
Obviamente, las metodologías ágiles no son perfectas. No existe aún un mecanismo por el cual se pueda
fabricar software de forma inequívoca. Como consecuencia de su flexibilidad, las metodologías ágiles
pueden mostrar una estructura muy débil. Puede existir laxitud en la planificación del proyecto y el
cliente puede percibir que no hay un plan concreto.
Además, la comunicación, la colaboración y la implicación del cliente son necesarias para garantizar el
éxito del proyecto. Esto puede ser complicado si los equipos que han de trabajar juntos no se muestran
colaboradores.
45/104
Figura 15. Prioridades en las restricciones de las metodologías tradicionales frente a las ágiles
Figura 15. Prioridades en las restricciones de las metodologías tradicionales frente a las ágiles.
Fuente: Share Alike 4.0 International.
A continuación se muestra un esquema de los diferentes enfoques de los marcos tradicionales de gestión
de proyectos frente a Agile:
Metodologías tradicionales Agile

Foco en desarrollar el alcance. Enfocadas en desarrollar a tiempo.
Siguiendo lo planificado. Desarrollar el producto funcionando.
Requisitos/funcionalidades fijas. Funcionalidades negociables.
Director de proyecto command and control. Empoderar al equipo.
Diagrama de Gantt y cronograma. Lista de funcionalidades (product backlog).
Control formal del proceso de cambios. Cambios más dinámicos.
Documentación de todo el proyecto. Documentación concisa.
Predicciones de coste/tiempo. Entrega de valor para el coste.
Mejora con base en KPI. Mejora a través de las personas.
Monitorización del plan. Monitorización de las tareas y funcionalidades.
Énfasis en documentar. Énfasis en la comunicación verbal.
5.4.5. Los retos de los marcos de trabajo ágiles
46/104
Las metodologías ágiles ofrecen una solución fácil de adaptar para casi todos los sectores en función del
tipo de proyectos. Una de sus principales características es su sencillez y flexibilidad, tanto en el
aprendizaje como en la aplicación. Aun así, su adaptación no está exenta de retos a los que habrá que
enfrentarse:
Difíciles de aplicar a equipos muy grandes
En un equipo basado en compartir información y comunicarse de forma exhaustiva, el número de

componentes del equipo multiplica los canales de comunicación y, por tanto, su complejidad. El número
ideal de miembros de un equipo Scrum está entre tres y nueve personas, siendo seis el número de
miembros ideal.
Las funcionalidades del producto cambiarán a lo largo del proyecto
Hay organizaciones y clientes que demandan tener una visión completa del producto desde el inicio del
proyecto, siendo imposible de concretar mediante una aproximación ágil.
Difíciles de aplicar a equipos globales o distribuidos
Difíciles de aplicar a equipos globales o distribuidos, aunque la tecnología facilita este punto a través de
herramientas colaborativas y de comunicación. No obstante, uno de los principios ágiles es fomentar la
comunicación face to face como la principal herramienta de intercambio de información.
Necesitan desarrolladores profesionales
Necesitan desarrolladores profesionales. Los juicios del equipo pueden ser inadecuados si no tienen la
suficiente experiencia técnica.
Complicadas de adoptar en empresas tradicionales en las que haya una política organizacional
muy jerarquizada
Hay muchas organizaciones (y equipos) que no se sienten cómodas frente a la idea de que no exista la
figura del director o responsable del proyecto. Muchas personas se sienten perdidas frente a una
situación en la que la figura del project manager desaparece, dejando sitio a un mar de incertidumbre.
Derivado de lo anterior, el funcionamiento de un equipo ágil dentro de la empresa se basa en la
confianza, gracias a entornos en los que la cultura empresarial fomenta esta actitud.
Necesitan adeptos
Necesitan adeptos —se debe seleccionar bien las personas clave—, capacidad de influir y capacidad de
decidir.
47/104
Figura 16. Ejemplo de uso de un tablero Kanban.

Fuente: Rakuten. Wikipedia Commons.
5.5. Distintas certificaciones ágiles
Son muchas las organizaciones que están proporcionando información, cursos y certificaciones sobre el
agilismo y sobre metodologías como Scrum. Entre las más importantes:
Scrum Alliance, scrumalliance.org. La Scrum Alliance, fundada en 2001, es la organización más

grande y mejor establecida dentro del mundo Scrum. Se dedica a diseminar el pensamiento ágil, así
como las metodologías Scrum, por todo el mundo. Ha generado una comunidad de personas
certificadas con más de 500 000 practicantes en todo el mundo.
Agile Alliance, agilealliance.org.
Scrum.org, scrum.org.
European Scrum, europeanscrum.org.
Project Management Institute, PMI, pmi.org.
VI. Impacto en el negocio
6.1. El impacto en el negocio de la agilidad organizacional
48/104
En última instancia se trata de tomar ventaja de las oportunidades en relación con la competencia. Así
que el beneficio real es lograr desarrollar la estrategia a través de una ventaja competitiva y ganar más
lealtad de los clientes, y, en definitiva, se espera que más ingresos y beneficios, así que se puede seguir
adelante en el desarrollo de la organización.
Esta competitividad se logra mediante revisiones del negocio más rápidas y ciclos de decisión más
cortos, lo que provoca una mayor adaptabilidad del negocio. Basta con pensar en una organización que
tiene departamentos estancos, con planes a 10-20 años vista. Puede haber incrementado su
competitividad mediante mejora continua, mejora de procesos, etc. Pero en la edad de transformación
digital y una intensa competencia, este sistema de organización no puede ser válido. Esta organización,
como todas en este momento, necesita cambiar de estrategia de una forma mucho más ágil y llevar estas
decisiones al plano operativo. En este proceso de “agilización”, el instrumento más importante es el
proyecto, ya sea desde una perspectiva tradicional en casada o una aproximación Agile. El proyecto es
la herramienta de aceleración de la estrategia.
La toma de decisiones en una organización tiene que estar orientada hacia abajo a un nivel que está más
cercano al cliente, más cercano a las personas que pueden tomar esas decisiones con eficacia en el front
line.
La agilidad organizacional está también utilizando la gestión de cambios de una forma más efectiva, más
cercana a las necesidades del cliente. Tradicionalmente los proyectos han luchado para incorporar la voz
del cliente en su trabajo de desarrollo. Las organizaciones que pueden identificar la voz del cliente en
forma más efectiva incorporan este elemento como palanca de cambio a toda la estrategia. Aportar valor
o value driven tiene que ver con aportar valor al cliente, customer driven.
Esto afecta al rol del director de proyecto en la medida en que deberá desarrollar nuevas habilidades y,
en última instancia, implementar nuevas herramientas y recursos que ayuden en sus proyectos. También
hay habilidades y comportamientos que necesitan incorporar en sus proyectos de futuro tecnología
digital y herramientas que mejoran la productividad. Pensando en el futuro debería plantearse la siguiente
pregunta: “¿Qué necesito para lograr personalmente, en cuanto a mi desarrollo, ayudar a la organización
a ser exitosa?”.
49/104
VII. Impacto en las organizaciones

En una entrevista a Mark A. Langley, CEO del Project Management Institute (PMI), por parte del medio
European CEO, expresaba que en los últimos años existe una tendencia creciente a adoptar metodologías o
marcos de trabajo Agile.
7.1. “Todo el mundo quiere ser ágil”
Sin embargo, investigaciones más recientes del PMI muestran que para entregar proyectos con éxito las
organizaciones tienen una necesidad que va más allá de Agile. Deben comprender un enfoque mucho más
amplio respecto de la gestión de proyectos. Langley explica que algunas organizaciones solo buscan una
solución rápida, confundiendo “ágil” con velocidad, en vez de lograr la agilidad en la empresa.
Recientemente, en el trabajo que está haciendo PMI con las organizaciones, se ha identificado lo que se
conoce como el entorno de la entrega de valor. Este concepto incorpora todas las prácticas que un gerente
de proyecto necesita para tener éxito. Esto incluye tanto la administración de proyectos tradicionales como
la incorporación de algunos de los métodos ágiles que utilizan las organizaciones. Por lo tanto, las
organizaciones necesitan integrar el conjunto adecuado de capacidades y prácticas que precisan. Una gama
completa de prácticas que sean capaces de adaptarse al proyecto y al entorno concreto de cada situación.
Lo que aún piensan algunas organizaciones es que aplicando metodologías Agile lograrán transformar la
organización. Pero en realidad es en el nivel de organización o nivel de la empresa donde se puede
conseguir agilidad, adaptabilidad. Es por eso que las organizaciones necesitan incorporar una serie de
prácticas, tanto dentro del proyecto como realmente a través de la organización, para alcanzar el éxito.
El éxito del proyecto comienza con elegir la correcta aproximación que mejor se ajuste al proyecto, el
entorno y la organización que lo ejecuta: una aproximación predictiva, adaptativa o híbrida.
7.2. Los conocimientos y habilidades necesarios para los

proyectos están evolucionando
El entorno en el que operan las empresas cada vez es más complejo, lo que hace que también lo sean sus
proyectos. La manera en que las organizaciones anticipan, entienden y se desenvuelven a través de la
complejidad determina sus éxitos y fracasos.
La profesión del experto encargado de dirigir y gestionar un proyecto, ya sea un Scrum master, product
owner o un project manager, está evolucionando en este escenario complejo. La globalización, los avances
tecnológicos, equipos multidisciplinares, deslocalizados, megaproyectos, etc., están marcando la tendencia
de una nueva generación de directores de proyectos, que pasa del rol de simple técnico que confirma el
estado del proyecto a un rol más estratégico y de liderazgo en la organización.
Según recoge el PMI en su Informe Pulse of Profession – Navigating Complexity, es necesario adquirir
nuevos conocimientos en el área de la dirección de proyectos para tener acceso a las oportunidades
mencionadas.
Cuanto más complejo sea un proyecto, mayores serán las capacidades requeridas por el gestor a su cargo,
y mayor deberá ser su apertura al manejo de la integración de la diversidad, es decir, de las disciplinas,
recursos y otros elementos bajo su responsabilidad.
50/104
Se encuentran casos de uso de Agile y Scrum en organizaciones y empresas de todos los sectores, desde
el diseño y creación de productos hasta la banca, los servicios, la educación o la Administración pública.
Pero para implementar un proceso de cambio organizacional como este, primero hay que asegurarse de
crear la cultura y el ecosistema en los que las opciones para el fracaso no sean penalizadas. En este sentido,
el trabajo de los gerentes es importante para transmitir esta cultura.
VIII. Casos de éxito

Como hemos visto, la aplicación de Agile no está limitada exclusivamente al desarrollo de software. El
pensamiento ágil nunca fue diseñado para limitarse solo al desarrollo de software. La aplicación de este
concepto de gestión de proyectos a procesos y otros tipos de proyectos diferentes al software se puede
observar desde el principio del pensamiento Agile.
8.1. Aspectos de Agile aplicados a proyectos empresariales y

start-ups
Para que un proyecto se pueda considerar un éxito para la organización es imprescindible entender la
componente estratégica de los proyectos. Una fuente importante de proyectos ágiles exitosos no tiene
relación con el software, sino con entender el propio negocio de una forma adaptativa al mercado, iterativa
y con un crecimiento incremental en los servicios ofrecidos.
Uno de los principios fundamentales del pensamiento ágil es algo que se ha promovido en las
implementaciones de proyectos empresariales durante años, especialmente en las start-ups : el beneficio de
un enfoque escalonado en distintas fases o iteraciones.
Una aproximación por iteraciones para la creación de un negocio se centra en el menor alcance que
puede tener en su primera fase, su producto mínimo viable: “¿Cuál es el alcance mínimo que se puede
ofrecer cuyo rendimiento de retorno de la inversión tenga un rendimiento positivo?”. Esta es la pregunta
que se hace al crear una entrega incremental por fases. Es importante asegurarse de que la primera
iteración es algo útil y lo suficientemente útil como para que el mercado lo valore. El primer beneficio de
esta aproximación es lo antes que el cliente puede empezar a recobrar la inversión. La ventaja más oculta
pero crítica es que el cliente será capaz de empezar a dar comentarios después de la primera iteración en
lugar de tener que esperar hasta el final del proyecto. Las posibilidades de que haya cambios en las
expectativas son, por supuesto, enormes, pero las posibilidades de que el proyecto realmente termine
estando más alineado con los requisitos del cliente son igualmente mayores que con una aproximación
tradicional al proyecto.
51/104
Es probable que el enfoque adaptativo para la creación de un nuevo negocio termine entregando algo
que es diferente de lo que se pretendía originalmente. Eso es una desventaja. El enfoque por fases
también es mucho más probable que se cancele una vez que se alcance algún nivel de rendimiento
creciente de los beneficios. El cliente puede estar “suficientemente satisfecho” con dondequiera que el
proyecto haya llegado y cancelar el resto de iteraciones.
En el lado positivo, el enfoque ágil es mucho más probable que ofrezca algo con lo que el cliente estará
satisfecho, y recibiendo valor de negocio al final de cada fase.
La publicación más conocida que recoge esta aproximación a la creación de negocios y start-ups es El
método Lean Startup, de Eric Ries.
Figura 17. Lean Canvas.

Fuente: Ash Maurya. Wikipedia Commons.
52/104
8.2. Proyectos de gestión ágil de diseño de productos
Adobe explica cómo utilizaron Scrum para coordinar con éxito las acciones de un equipo Scrum
distribuido en un entorno compuesto por equipos tradicionales. El título del artículo lo dice todo acerca de
las ventajas que da adoptar un enfoque Agile para el diseño de nuevos productos y su lanzamiento al
mercado:
8.2.1. “How an agile approach enabled success in a hyper-competitive landscape”
Adobe Premiere Pro comenzó una adopción ágil en 2008. Premiere Pro CS5, el primer lanzamiento
con Scrum, representó una mejora en la calidad del producto, la conciliación de la vida laboral y el
trabajo en equipo, y la capacidad de respuesta al mercado. Los usuarios perciben a Adobe como un
referente en el mercado, con soluciones de altísima calidad. Al mismo tiempo, la empresa ha
adoptado un desarrollo sostenible para los miembros del equipo, lo que mejora la percepción interna
de la compañía por los propios empleados.
Creative Suite de Adobe incluye varios otros productos como Photoshop, Illustrator, Acrobat y
muchos más. La suite no es simplemente una colección de productos —hay varias características
que integran los productos cuando se utilizan juntos—. Cada uno de estos productos estaba
desarrollado por equipos diferentes, al mismo tiempo que compartían componentes transversales
desarrollados por otros equipos. Fue necesaria una estrecha coordinación del trabajo de los equipos
que crearon los productos puntuales y los componentes compartidos de Creative Suite.
Los desafíos de coordinación de un sistema tan complejo se hacen más difíciles cuando los equipos
utilizan diferentes enfoques de desarrollo con diversos métodos de planificación, seguimiento,
medición y procesos de cambio. Muchos de estos equipos de trabajo utilizaban aproximaciones
tradicionales a sus proyectos, mientras que otros lo hacían de forma iterativa y ágil. La coordinación
entre los distintos equipos con diferentes ritmos de entrega fue el mayor reto del proyecto.
8.2.2. Agilidad organizacional en el sector de la construcción
53/104
Las fases de diseño de producto habitualmente están enmarcadas en ciclos de vida de proyecto
tradicionales o en cascada. Esto suele estar determinado por el sector de negocio en el que se desarrolla
el producto. La construcción y la arquitectura son ejemplos de sectores tradicionales en los que
raramente se van a encontrar equipos ágiles.
Sin embargo, hay ejemplos novedosos que aprovechan la agilidad organizacional para producir nuevos
servicios y productos que dan respuesta a las necesidades del mercado mucho más rápido de lo que lo
haría cualquier empresa tradicional.
Es el caso de AirBnB y su proyecto Backyard, desarrollado como una start-up al margen de la

actividad normal de la compañía. Se trata de un esfuerzo por diseñar y prototipar nuevas formas de
construcción de casas compartidas, y es un modelo de negocio ágil que triunfa en el sector
tradicional de la construcción.
La principal cualidad de este proyecto es el hecho de que sea el proyecto inmobiliario que puede
transformar el real estate desarrollado por una empresa que no tiene ninguna experiencia en la
construcción. Otro ejemplo de diseño de un producto que puede transformar el sector de la
construcción son las casas prefabricadas planteadas por Ikea.
Otra forma en que se puede encontrar Agile aplicado a proyectos de construcción es a través del uso
de ciclos de vida híbridos. Esta aproximación se aprovecha de las ventajas de ambas
aproximaciones. En un proyecto inmobiliario, normalmente planificado siguiendo un ciclo de vida
tradicional en el que primero se estudia la viabilidad, se diseña, construye y pone en uso una
infraestructura. La fase de diseño, sin embargo, puede desarrollarse de forma incremental, utilizando
Scrum para elaborar el proyecto técnico o diseño de la infraestructura o construcción. Durante esta
fase, el equipo de diseño trabaja junto con el cliente en el diseño de la solución que mejor se adapta a
sus necesidades, entregando en distintos sprints diferentes avances sobre la solución definitiva:
diseño arquitectónico, cálculo estructural, concepto de decoración, etc. Se pueden entender estos
incrementos como distintas capas del diseño que se van superponiendo de forma incremental hasta
definir el diseño del edificio. En cada una de las iteraciones o sprints , el cliente puede validar la
solución propuesta aportando feedback al proceso.
Este proyecto de diseño arquitectónico mediante Scrum fomenta la interacción con el cliente gracias
a la tecnología. Aplicaciones de BIM (building information modeling), realidad virtual, o aumentada,
o modelos virtuales facilitan la comprensión del modelo por parte del cliente, que es capaz de
corregir y adaptar la solución en cada revisión.
54/104
En el siguiente enlace, Pampliega explica con más detenimiento estos y otros ejemplos sobre la
aplicación de las metodologías ágiles al sector de la construcción.
Pampliega, C. “Agilidad organizacional en el sector de la construcción (1/3)". PMideas Project

Management; 28 de octubre de 2022.
8.2.3. Diseño y preconstrucción con Agile
Se puede aplicar Agile a proyectos arquitectónicos donde tiene importancia la preconstrucción de partes
o de todo el edificio. La tecnología asociada a las impresoras 3D y la prefabricación de módulos
arquitectónicos han abierto la posibilidad de plantear el ciclo de vida de la construcción de un edificio
de una forma más flexible y adaptable.
Por ejemplo, ya es posible adaptar el diseño final de una vivienda en bloque de forma individualizada
para cada cliente, modificando acabados y distribuciones en medio del proceso constructivo. Pronto se
podrán construir edificios enteros mediante impresoras 3D, con lo que se eliminarán muchos de los
impedimentos que hacen de la construcción un proceso básicamente en cascada.
¿Cómo se pueden construir módulos prefabricados siguiendo los principios de Agile? En este enlace se
puede ver el ejemplo concreto:
Troy, J. “What Modular Construction can learn from Software developers.” Bisnow; 24 de marzo de
2020.
8.3. Aplicar Scrum en las aulas: proyectos educativos
Las escuelas están utilizando Scrum para ayudar a los estudiantes a aprender de manera más efectiva y
desarrollar sus capacidades de una forma amigable. Para los niños, trabajar en equipo es una forma natural
de interactuar con el entorno y el resto de compañeros, tanto en el parque como en las aulas. A través de
los proyectos, los niños aprenden a desarrollar las habilidades personales que les harán convertirse en
grandes profesionales: trabajo en equipo, resolución de problemas, liderazgo, cooperación, pensamiento
crítico, comunicación, creatividad, etc.
Estas son las habilidades que el Foro Económico Mundial (WEF) recomienda desarrollar en los estudiantes
para afrontar el siglo xxi. Los alumnos deben desarrollar capacidades y habilidades que les hagan capaces
de enfrentarse a los problemas una vez sean adultos, siendo esto más importante que adquirir un extenso
currículum de conocimientos. Una herramienta para que los niños y jóvenes desarrollen estas habilidades
es la gestión de proyectos, y en concreto desarrollar proyectos con Agile/Scrum.
Esta serie de artículos publicados en Scrum.org sobre Scrum in the Classroom/Time for Change
muestra la experiencia de Jochen Krebs, un profesor que aplica Scrum en su escuela, en Holanda, con más
de 180 estudiantes.
Scrum es una herramienta flexible y fácil de utilizar con niños y jóvenes, especialmente en los entornos
escolares. Para ello, se ha desarrollado una versión educativa denominada eduScrum, fácil de implementar
con grupos de niños, desde infantil hasta secundaria. Con eduScrum, los estudiantes trabajan juntos de una
manera enérgica, específica y efectiva.
55/104
Los equipos de estudiantes se autoorganizan de forma autónoma para desarrollar distintos proyectos
educativos. La supervisión del profesor garantiza que los alumnos están alcanzando los conocimientos y
objetivos que se espera a través del currículum. Los equipos trabajan en distintos proyectos a lo largo
de sprints para aprender materias y evolucionar el proceso de aprendizaje. Cada equipo comparte con el
resto del aula los conocimientos adquiridos, de forma que aprenden también a liderar y exponer el
conocimiento, y poner en crisis ideas preconcebidas. Se hace partícipe a toda la clase del trabajo del
resto de equipos, fomentando la cooperación y el espíritu de equipo. Una vez terminado el proyecto,
los equipos de estudiantes y maestros realizan retrospectivas para evaluar el proceso de aprendizaje y
encontrar puntos de mejora.
El resultado de aplicar Agile en las aulas es una mejor calidad de educación, mejores calificaciones,
involucramiento y estudiantes motivados.
Existen muchos ejemplos de escuelas del norte de Europa en las que Scrum es utilizado por los
estudiantes como una forma atractiva y autoorganizada. En este artículo se pueden leer experiencias de
distintas escuelas, como Blueprint High School, en Arizona, EE. UU., o The Asham College, en Alphen
aan de Rijn, en Holanda: “Scrum for Education – Experiences from eduScrum and Blueprint Education.
En este enlace se puede acceder al sitio oficial de eduScrum.
8.4. Los departamentos de RR. HH. se transforman a Agile
8.4.1. “How HR can become agile (and why it needs to)”
Este es el título de un reciente artículo de la Harvard Business Review sobre la gestión de talento.
Es conocido que Agile tiene una gran aceptación en el mundo del desarrollo de software y las
tecnologías del conocimiento. En la mayoría de las empresas, las palabras Agile o Scrum aparecen en
las conversaciones alrededor de la máquina del café de la mano de los ingenieros e informáticos, que los
aplican en sus proyectos de desarrollo de soluciones tecnológicas y nuevos servicios.
56/104
Pero está surgiendo un gran desafío: una vez que los equipos tecnológicos han comenzado a dominar
estas nuevas formas de trabajo, mejorando el tiempo de comercialización, el aprendizaje continuo, la
capacidad de respuesta y la colaboración, a menudo descubren que el ritmo de trabajo que desean se ve
obstaculizado sustancialmente por la falta de agilidad en otros departamentos trasversales, como los de
recursos humanos. Integrar a RR. HH. y otras funciones de apoyo cruciales en el proceso de desarrollo
de productos se ha convertido en el reto de la agilidad organizacional.
En una organización ágil, RR. HH. debe proporcionar los servicios que siempre brinda: contratación de
los equipos, gestión del talento, desempeño del personal, etc. Pero la programación de RR. HH. trabaja
regularmente en ciclos anuales, en vez de ciclos cortos adaptados al ritmo de los sprints de los equipos
ágiles.
Por otra parte, los valores imperantes en los departamentos de RR. HH. heredados del taylorismo tienen
que ver con el individualismo y la consecución de índices de desempeño de alto nivel sobre los que se
calculan las retribuciones y la promoción de los empleados. Mientras que Agile defiende la
colaboración, la atención al cliente, la cultura basada en el equipo y la mejora continua. Aspectos
difícilmente cuantificables según las métricas tradicionales. La retribución y la gestión del talento son un
reto para el escalado de Agile a toda la organización.
Un ejemplo de éxito es el caso de ING, que entendió que este cambio de paradigma obligaba a
reestructurar los organigramas y hasta los incentivos de las personas en sus puestos. En este proceso de
transformación ágil, hasta el 40 % de los empleados de ING cambiaron de puesto de trabajo o se
desvincularon de la empresa al constatar que la mentalidad de muchos de ellos no encajaba en la nueva
cultura empresarial.
Para facilitar un cambio de mentalidad y cultura en la empresa, los empleados de ING visitaron
empresas nativas digitalmente, como Spotify, Netflix y Zappos, para comprender qué hace que sus
culturas sean ágiles, adaptativas y más atractivas para el talento tecnológico. Las habilidades blandas
eran predominantes entre los equipos de estas empresas, necesarios para fomentar un entorno ágil:
curiosidad, humildad y colaboración con el resto del equipo.
57/104
Esta transformación ágil es también una realidad en el banco español BBVA. Además de las áreas
dedicadas a la tecnología, TI y desarrollo de productos, el departamento de Talento y Cultura (el
equivalente a la función de RR. HH.) también adoptó esta filosofía colaborativa para estar alineado con
el resto de departamentos más tecnológicos. En 2016, el banco español creó un primer pool que
trabajaría exclusivamente por proyectos. Hoy en día, cuenta con un equipo de T&C con más de 2000
personas en diez países trabajando con una organización y un modelo de gobierno totalmente ágiles.
8.4.2. “RR. HH. se transforma a ‘agile’: un caso de estudio en BBVA”
BBVA ha dejado atrás las unidades funcionales y jerárquicas del antiguo modelo y ha reorganizado el
equipo de T&C en cuatro grandes grupos:
Front
Como el equipo de business partners que dan apoyo y asesoramiento estratégico a clientes internos.
Hacen las labores de coaches o mentores para los responsables y contacto de los empleados dentro de
la organización.
Disciplinas
Es un equipo de expertos responsables de definir la estrategia y las herramientas del resto de equipos,
como la gestión de talento, comunicaciones, organización, gobernanza de los proyectos, etc.
Comparten las buenas prácticas y mantienen los modelos estandarizados para toda la organización.
Desarrollo de soluciones
Totalmente dedicados a la ejecución de los proyectos y al desarrollo de nuevas soluciones siguiendo la

metodología Scrum. Son equipos multidisciplinares con capacidad de producción de proyectos end-to-
end trabajando en sprints de dos a tres semanas de forma iterativa e incremental que terminan en la
revisión de la solución por parte de los clientes (internos).
58/104
Experiencia de empleado
Grupo de equipos con capacidad de ejecutar todos los procesos end-to-end de la función, y aportar
valor a los clientes internos utilizando Kanban. Al concentrar todos los procesos anteriormente
fragmentados en diferentes unidades, surge de forma clara la oportunidad de dejar de hacer cosas que
ya no aportan valor, aplicar ingeniería de procesos para rediseñarlos con el objetivo de mejorar la
calidad y la eficiencia, y aplicar técnicas de automatización, robótica y machine learning para incrementar
la productividad.
Se puede leer el caso completo en el siguiente enlace de BBVA.
Forcano, R. “RR.HH. se transforma a agile: un caso de estudio en BBVA.” BBVA; 28 de junio de 2018.
8.5. Proyectos ágiles para servicios
Los servicios orientados al público también se pueden mejorar gracias a la aplicación de Agile. Scrum
Alliance publicó su guía Scrum for Services para adaptar la metodología Scrum a los proyectos
particulares en los que el resultado no era un producto (object oriented projects ), sino un servicio.
Los equipos desarrolladores de servicios experimentan beneficios utilizando Scrum al igual que lo hacen
los equipos de desarrollo.
Hay dos diferencias principales con los servicios:
Los equipos de servicio tienen dos fuentes de tareas a gestionar: tareas planificadas e incidentes —por
ejemplo, mantenimiento—. Uno de los desafíos típicos para cualquier equipo de servicio es equilibrar
ambas fuentes, o más bien limitar en la medida de lo posible el mantenimiento posterior para que no se
convierta en una operación sin final. Este es el principal inconveniente por el que muchos proyectos
fracasan al adoptar Scrum: los sprints terminan llenos de tareas propias de mantenimiento u operaciones,
y se pierde el concepto de proyecto con una fecha final de entrega.
Las tareas de servicio son sustancialmente más repetitivas que las tareas de desarrollo. La complejidad
de los proyectos radica en la singularidad de la tarea.
8.5.1. Scrum Boosts Effectiveness at the BBC
La BBC es otro interesante ejemplo de la aplicación de la filosofía Agile a servicios.
59/104
El departamento New Media de la BBC está caracterizado por una gran incertidumbre y un proceso
emergente de nuevo software para dar soporte a los servicios ofrecidos por la BBC. El departamento
decidió usar Scrum para entregar software de manera más efectiva en medio de todo ese cambio e
incertidumbre.
En este interesante vídeo es posible acercarse a la nueva sede de la BBC en Mánchester para descubrir
cómo Agile y el aprendizaje basado en la mejora continua están ayudando a la BBC a entregar mayor valor
a sus clientes.
Creative Grid. BBC Case Study: Working Agile. Archivo de vídeo; 11 de junio de 2015.
8.6. Agile en proyectos de públicos y de defensa

Los proyectos de sistemas militares son algunos de los desafíos de investigación, diseño y fabricación más
caros y complejos del mundo.
El costo de la adquisición militar en todo el mundo se mide en billones de dólares, y durante décadas se
han venido aplicando metodologías tradicionales de gestión de proyectos predictivos para este tipo de
iniciativas en las que la documentación y el control exhaustivo por parte de las Administraciones públicas
son una necesidad imperante. El resultado normalmente son proyectos que se alargan en el tiempo y con
unos sobrecostes a cuenta de las arcas públicas. Los aumentos de costos con cargo a las estimaciones
iniciales pueden estar por encima del 60 %.
Sin embargo, muchas empresas están buscando nuevas formas de desarrollar este tipo de proyectos,
influidas por la falta de recursos y la necesidad de demostrar viabilidad mediante la entrega temprana de
productos con la más alta calidad.
Saab Defense es uno de estos ejemplos. Desde su quiebra como fabricante del sector de la automoción,
mantuvo su marca en el sector aeronáutico y militar. Su situación tiene muchos puntos en común con la
adopción del método Lean por Toyota después de la Segunda Guerra Mundial. La falta de recursos
incentivó la necesidad de aumentar la productividad reduciendo costes y procesos ineficaces. Con la
misma filosofía, Saab ha adoptado un modelo ágil para abordar los proyectos de equipos de hardware y
software para producir un nuevo caza de combate, el JAS 39E Saab Gripen.
Saab está a pocos años del programa de desarrollo del nuevo caza, cambiando la forma de hacer este tipo
de proyectos. Ha adoptado un enfoque ágil para organizarse a sí misma y sus esfuerzos, ofreciendo
resultados más rápidamente, con mayor calidad y a un costo drásticamente menor.
8.6.1. Owning the Sky with Agile
La forma en que Saab está desarrollando este programa aeronáutico y de defensa es un ejemplo de
adaptabilidad a los requisitos del mercado, especialmente en una empresa que no tuvo más remedio que
adaptarse o morir.
60/104
La agilidad en Saab se basa en un principio claro: manejar la variabilidad de un proyecto complejo en el

que más de 100 equipos de ingenieros incluyen variaciones en el proyecto continuamente. Todos ellos
trabajan al mismo pulso de la organización, con sprints de tres semanas que empiezan y terminan el
mismo día para todos los equipos. Saab también encontró la manera de sincronizar los incrementos de
los distintos equipos para que el programa estuviese coordinado a alto nivel, y en el día a día.
Otros puntos que destacar son la priorización de los incrementos que se desarrollan en los sprints ,
planificando estratégicamente las entregas y el desarrollo del producto esperado. Las herramientas
visuales son importantes para comunicar esta planificación, de forma que todos los equipos
comprendan la información del resto de la organización.
Kaizen apoya la mejora continua siguiendo el modelo de producción Lean durante muchos años desde
Toyota. En Saab tiene como objetivo lograr el mismo enfoque sistemático implacable para la mejora, no
solo en la cadena de producción del producto, sino también en el proceso de diseño y desarrollo. La
base para conseguir la mejora continua de los más de 100 equipos en Saab esto es la retrospectiva que
celebran al final de cada sprint, que ofrece una mejora del proceso para que el equipo implemente el
siguiente sprint.
El ejemplo de Saab está muy determinado por la propia cultura y las circunstancias particulares de la
compañía. No siempre la cultura organizacional favorece la adopción de una cultura Agile. El ejemplo de
proyectos directamente ejecutados por la Administración pública tiene sus propios retos relacionados con
factores ambientales difíciles de cambiar.
Se puede encontrar el caso de estudio completo en el siguiente enlace.
Furuhjelm, J; Sertoft, J; Justice, J; Sutherland, J. J. “Owning the Sky wit Agile. Bulding a Jet Fighter Faster,
Cheaper, Better with Scrum.” (s.f.)
8.6.2. La Oficina de Responsabilidad Gubernamental (GAO, en inglés)
GAO proporciona una revisión de los desafíos y factores de éxito para proyectos ágiles dentro del
Gobierno federal de los EE. UU. sobre la base de su investigación de cuatro programas exitosos titulada Ef
fective Practices and Federal Challenges in Applying Agile Methods.
GAO identificó en este estudio 14 retos relacionados con la aplicación de Agile en los proyectos
gubernamentales o públicos:
61/104
Los equipos no están acostumbrados a colaborar.
Los equipos tienen dificultades para autogestionar de forma autónoma su trabajo.
El personal tenía dificultades para comprometerse con un seguimiento más frecuente.
Los equipos tenían dificultades para administrar los requisitos iterativos.
Las agencias del Gobierno tenían problemas para comprometer al personal.
Las revisiones de cumplimiento eran difíciles de ejecutar dentro del periodo de tiempo de cada iteración.
La adopción de nuevas herramientas fue difícil.
Las prácticas de presentación de informes gubernamentales no se alinean con Agile.
Los entornos de los equipos Agile eran difíciles de establecer y mantener.
62/104
Los clientes no confiaban en las soluciones iterativas.
La aproximación Agile no estaba clara para los equipos.
Las prácticas de adquisiciones en los proyectos públicos no son ágiles.
Las revisiones tradicionales del resultado del proyecto no se alinean con Agile.
El seguimiento de estado tradicional de los proyectos no se alinea con Agile.
IX. Entrega de valor

La entrega de valor de forma temprana es la base de la planificación en proyectos de alta incertidumbre en
los que no es posible establecer una planificación realista propia del mundo Agile.
63/104
Figura 19. Tablero Kanban con historias de usuario
Figura 19. Tablero Kanban con historias de usuario.

Fuente: Wikipedia Commons.
9.1. Enfocarse en las prioridades del negocio

Un equipo de proyecto Agile se enfoca en que cada iteración sirva para desarrollar una funcionalidad
utilizable por el cliente. Una parte del proyecto que aporte valor al negocio en el sentido en que se pueda
utilizar, testar o recibir algún beneficio por el hecho de poseerla. Por el contrario, enfocarse en completar
tareas individuales, muchas veces sin conexión entre ellas, no aportaría por sí valor al negocio.
Para comparar la distinta perspectiva desde la que se va a planificar un proyecto Agile hay que ponerse las
zapatillas de correr.
La planificación predictiva de una carrera de diez kilómetros es sencilla. Se sale a correr, y siempre se sabrá
dónde está la línea de meta y cuánto falta para terminar. Se intenta correr lo más rápido que se pueda para
llegar al kilómetro 10 lo antes posible. ¡Predecible!
Y ahora hay que ponerse unas zapatillas Agile. En un proyecto adaptativo no se va a saber exactamente
dónde está la meta, aunque sí que se puede estimar hasta dónde se llegará en un tiempo dado manteniendo
la velocidad cómoda corriendo.
Una carrera Agile sería más bien como intentar llegar lo más lejos posible en 30 minutos, mientras que en
una carrera tradicional se da la meta de diez kilómetros y se lucha por terminar lo antes posible.
La conclusión adaptada a la gestión de proyectos es que cuando no se está seguro de dónde está
exactamente la meta u objetivo del proyecto la planificación se convierte en un proceso en el que se
establecen pequeños objetivos parciales que al final del proyecto se pueden asociar a una meta mayor.
9.2. Planificación en entornos ágiles
64/104
Planificación en ciclos de vida iterativos
En un ciclo de vida iterativo, el alcance del proyecto se determina tempranamente, pero se va mejorando
periódicamente, conforme aumenta la comprensión del producto por parte del equipo del proyecto. El
producto se desarrolla a través de una serie de iteraciones que van añadiendo funcionalidad a este. El
entregable de cada iteración contiene capacidad necesaria y suficiente para que pueda funcionar.
En la planificación con base en distintas iteraciones el resultado del proyecto se desarrolla por versiones.
Los ciclos de vida iterativos proceden por versiones. Cada iteración consiste en ampliar y mejorar los
resultados de la anterior y se realiza a continuación de ella. En todas las iteraciones se aplican los
procesos directivos de todos los grupos con el propósito de entregar una versión más completa del
producto, servicio o resultado final, que se irá construyendo incrementalmente a través de ulteriores
iteraciones. En el cierre de cada iteración el equipo del proyecto puede utilizar información de retorno
para incorporar al producto mejoras o nuevas características que lo adecuen al uso deseado, que se va
reelaborando incrementalmente.
En la mayoría de los ciclos de vida iterativos hay que poseer una visión general del resultado deseado
para todo el proyecto desde el primer momento, para garantizar que el resultado final sea el deseado por
el cliente. También habrá que aclarar el alcance o resultado de cada iteración.
Los ciclos de vida iterativos son generalmente los preferidos cuando una organización necesita reducir la
complejidad de un proyecto y gestionar progresivamente el cambio de objetivos y alcances. Como, por
ejemplo, con el lanzamiento de un proyecto empresarial por medio de la filosofía Lean start-up . Se
procederá a lanzar un modelo de negocio de acuerdo con un producto mínimo viable fácilmente
verificable, para, posteriormente, seguir implementando nuevas funcionalidades.
Los proyectos grandes y complejos se ejecutan con frecuencia de forma iterativa para reducir el riesgo,
al permitir que el equipo vaya incorporando al proyecto la experiencia y lecciones aprendidas adquiridas
en cada una de las iteraciones ya realizadas.
Figura 20. Ciclo de vida iterativo.

Fuente: Flickr. Dave Gray (https://www.flickr.com/photos/davegray/6865783267).
65/104
Planificación incremental
En un ciclo de vida incremental, el entregable se produce a través de una serie de incrementos repetidos
que van añadiendo características sucesivamente. Los ciclos de vida incrementales se desglosan por
incrementos o conjuntos de características. A diferencia del iterativo, el entregable solo obtiene la
capacidad necesaria y suficiente para considerarse operativo después del incremento final. Es el utilizado
por la metodología de desarrollo de sistemas feature driven development (FDD).
Adaptativo = iterativo + incremental
Los ciclos de vida adaptativos pueden ser al mismo tiempo iterativos e incrementales. En estos ciclos, el
alcance se reconsidera, redefine y se aprueba antes del comienzo de cada iteración. El entregable, al final
de cada iteración, contiene capacidad necesaria y suficiente para que sea operativo. Los ciclos de vida
adaptativos, que también se denominan ciclos de vida ágiles, se desglosan por sprints.
Los ciclos de vida adaptativos son muy utilizados en el desarrollo de nuevos productos, por ejemplo, en
el desarrollo muchas aplicaciones de software, pero no solo en el sector TI. El proyecto va
incrementando el valor del resultado en cada iteración, por lo que es un enfoque destinado a responder a
altos niveles de cambio y participación de los actores interesados. El ejemplo más utilizado de este
enfoque es Scrum.
X. Historias de usuario
La planificación en Agile se basa en funcionalidades, expresadas durante el proyecto con base en historias
de usuario. A continuación se va a descubrir cómo definir estas user stories , y cómo estimar la
complejidad para su ejecución, con base en puntos de historia o story points .
10.1. Historias de usuario, épicas y temas
La manera en que el equipo de proyecto registra cada funcionalidad solicitada por el cliente es a través de
las historias de usuario o user stories . Estas obedecen a una regla sencilla, siguiendo el acrónimo INVEST:
66/104
I: independent/independiente
I: independent/independiente (cada funcionalidad se trata independientemente del resto).
La historia de usuario ha de ser entregable por sí misma. No tiene ningún tipo de vínculo con otras
historias de usuario del product backlog.
Las dependencias entre historias de usuario pueden llevar a sufrir un interbloqueo a la hora de
implementarlas, impidiendo que el equipo pueda entregarlas durante un sprint.
Como ejemplo, una historia de usuario que solicita tener una página web de inicio y otra historia de
usuario que pide la máquina que la sirve. Si la segunda historia tarda un sprint, no es posible
comprometerse a ambas puesto que la primera nunca podría entregarse durante el mismo sprint.
N: negociable
N: negociable. Pueden ser siempre reescritas, modificadas e incluso reemplazadas. Si una historia de
usuario es tan rígida que no admite ningún tipo de cambio, es posible encontrarse en una situación en la
que no se pueda entregarla porque exista algún impedimento insalvable que se ha de renegociar.
V: valuable /valiosa
V: valuable/valiosa (que aporte valor al negocio y al proyecto, aporta valor por sí misma).
Implementar historias de usuario sin valor para el usuario final es absurdo, pero puede darse el caso. Un
product owner sin visión sobre el producto podría llegar a pedir funcionalidad que no aporte nada al
producto final.
E: estimable
E: estimable (que se pueda medir y estimar).
El tamaño de la historia de usuario debe ser estimable para el equipo. El equipo ha de ser capaz de decir
cuánto cuesta entregar la funcionalidad. No es posible enfrentarse a historias tan amplias o tan mal
definidas que no se pueda ver el final de la necesidad. Si una historia de usuario no es estimable, se
considerará épica y se trabajará con el product owner para comprenderla mejor o para dividirla en
historias más pequeñas y manejables.
67/104
S: small/pequeña
S: small/pequeña (tan pequeña como sea posible mientras aporte valor y tenga funcionalidad).
Tamaño asequible para el equipo en un sprint. Ninguna historia de usuario debe ser de un tamaño mayor
a lo que el equipo pueda entregar durante un sprint. En caso de serlo, este sería incapaz de terminarla y
de cumplir con la máxima de hacer entrega del producto comprometido durante cada sprint. Si las
historias de usuario son tan grandes que no se puede con ellas, habrá que facilitar al product owner su
descomposición en otras más pequeñas que sí lo sean.
T: testeable
T: testeable (verificable, que pueda comprobarse que funciona y satisface la definición de hecho pactada
con el cliente).
El product owner ha de proporcionar al equipo la descripción necesaria para poder testear la

funcionalidad y verificar así que cumple con la necesidad. Un equipo Scrum puede rechazar historias de
usuario que no sean testeables. El product owner podría moverse a una posición donde nunca acepta la
historia de usuario porque no es de su agrado.
Para definir las historias de usuario habrá que centrarse en el cliente o usuario del producto, para ponerse
en el lugar del otro y definir todas aquellas necesidades que el producto debería solucionar. Todas las
historias de usuario se redactan siguiendo el mismo esquema:
“Como _____________ (stakeholder),
quiero ______________ (tarea),
de modo que ________ (resultado deseado)”.
Se trata de una lista específica de actividades necesarias para que el producto solucione las necesidades del
usuario.
Epic
Si las historias son demasiado complejas o largas, habría de considerarse la manera de acortarlas. A una
historia demasiado larga se la denomina epic , y se divide en historias de usuario más pequeñas y
manejables siguiendo el esquema anterior. En este caso, las historias pueden tener dependencias entre
ellas, que deberían anotarse para tenerlas en cuenta, pero lo ideal es que todas las historias fuesen
independientes para planificar sin contar con dependencias.
68/104
Theme
Un tema o theme puede referirse al departamento que está involucrado en el desarrollo de varias
historias, el área de negocio al que le afectan, interesado, etc. Es una manera de asociar un grupo de
historias de acuerdo con un “tema” común. Por ejemplo, un tema podría ser “comunicación”, con
historias del tipo “compartir en RR. SS.”, “escribir comentarios en el blog”, “escribir artículos
relacionados”, etc.
Definition of done (DoD)
El criterio de aceptación de cada historia de usuario se pacta con el propietario del producto o con el
cliente. Deberían ser resultados medibles, de forma que no hubiese oportunidad de discusión sobre
criterios abstractos de idoneidad del resultado obtenido durante la validación del prototipo. El término
específico para este criterio es la definición de completado o definition of done (DoD).
Product backlog
El conjunto de todas las historias de usuario creadas es la pila de producto o product backlog , y se
prioriza verticalmente con base en el valor que aporta cada historia.
Figura 21. Historia de usuario
Figura 21. Historia de usuario.

10.2. Estimación por puntos de historia (story points)
69/104
La Guía de Scrum (2017) indica que las personas que van a realizar el trabajo deben proporcionar las
estimaciones, pero no dice cómo se deben proporcionar. Deja abierta esa decisión. Una táctica común
utilizada por los equipos de Scrum es estimar usando una unidad de medida conocida como el punto de
historia.
Para más información sobre el uso de puntos de historia, es recomendable la explicación que da
Scrum.org.
Davidson, D. “Why do we use Story Points for Estimating?” Scrum.org; 18 de agosto de 2014.
Las estimaciones en Agile se realizan normalmente a través de dos “unidades” básicas diferentes a las
utilizadas en los proyectos predictivos: puntos de historia (story points ) y días ideales.
Para entender los días ideales hay que tener presente que el tiempo trabajando en el proyecto se ve
interrumpido constantemente por llamadas, correos electrónicos, reuniones, demostraciones,
entrenamiento, arreglar fallos en tareas precedentes, más reuniones, más correos, etc. Luego, la duración de
una historia de usuario podrá ser de n días ideales, pero habrá que traducirlos a la dedicación real que se
pueda aplicar al proyecto.
Los puntos de historia, sin embargo, son una unidad relativa de tamaño. Con esta unidad se expresa la
medida relativa de una historia de usuario, funcionalidad o tarea de trabajo. No importa tanto el valor neto
de lo que significa un punto, sino el tamaño relativo de una historia contra otra ya conocida.
¿Qué beneficios tiene estimar por puntos de historia?
Es mucho más sencillo estimar comparando tamaños que estimar los tiempos que se piensa que se
van a emplear para hacer una historia de usuario. Resulta más sencillo planificar en términos
comparativos o relativos que intentar asignar una cantidad de horas determinada.
Hacer uso de los puntos por historia permite que el equipo mejore estimación tras estimación, ya que
no está pensando en unidades de tiempo, sino en términos comparativos. “Esto es más difícil que
aquello”.
Si el equipo estima en tiempo, cuando su rendimiento mejore, las métricas cambiarán y será más
complicado comprender futuras estimaciones. Si se estima con puntos por historia, el tamaño de las
estimaciones se mantiene, aunque el equipo mejore su rendimiento.
70/104
Las estimaciones de los equipos de Scrum se hacen entre todos los miembros del equipo. No son
los expertos técnicos los encargados de realizar las estimaciones. Cualquier miembro puede tener
información relevante sobre esa historia y, por tanto, su opinión también cuenta. Un grupo de
personas con diferentes perspectivas tendrán una visión del producto y proporcionarán las métricas
desde cada una de sus formas de ver el problema. La estimación es mucho más heterogénea y estará
acordada por consenso de gente con diferente madurez.
El equipo se centra únicamente en estimar cuánto cuesta el incremento de producto que la historia de
usuario necesita. No se estiman reuniones, interrupciones, contratiempos a la hora de implementar la
historia, sino el coste del producto en sí.
Para valorar los puntos de historia se va a considerar un conjunto de conceptos relacionados con el
trabajo en cuestión como los siguientes:
Nivel de esfuerzo necesario para desarrollar el trabajo
El esfuerzo necesario para llevar a cabo la historia de usuario. Es posible encontrar tareas que, si bien
son sencillas de desarrollar, requieren un esfuerzo mayor por tener que hacer más cosas para poder
llevarlas a cabo. Tareas de mayor esfuerzo tendrán más puntos por historia que aquellas que
requieran menos trabajo.
Complejidad para desarrollarlo
La dificultad de la historia de usuario que se está estimando. Historias de usuario más complejas
tendrán más puntos por historia que aquellas que son más sencillas.
Riesgos inherentes
El desconocimiento o incertidumbre para completar la tarea. Esta medida representa la probabilidad

de que algo inesperado pueda aparecer durante la implementación de la historia de usuario. También
contabiliza el desconocimiento que se pueda tener de la historia de usuario. Al fin y al cabo, el
desconocimiento provoca incertidumbre, incrementando así el riesgo de poder terminar con éxito la
historia de usuario. Historias de mayor incertidumbre tendrán mayor número de puntos por historia
que aquellas que tienen menos.
La manera de empezar a usar esta nueva unidad pasa por elegir una historia conocida que se pueda
tomar como referencia porque ya se ha realizado anteriormente. Se puede elegir la más pequeña de todas
y asignarle un valor 1, o bien elegir una historia intermedia y asignarle un valor 5, con lo que se tendrán
historias mayores y también alguna más pequeña.
71/104
Por ejemplo, si se tienen varias historias en las que el trabajo consiste en comerse distintos tipos de
fruta, habrá frutas conocidas, como la manzana, pero también frutas menos comunes, según la latitud,
por lo que puede que se desconozca cuánto esfuerzo llevará comérselas.
Tomando como referencia la manzana con 2 puntos, la mayoría del equipo piensa que le resultaría algo
más fácil comerse unas uvas, o unas fresas, por ejemplo, ya que no hay que pelarlas, y no necesitan
cuchillo para partirlas, etc. Sin embargo, la naranja ya necesita pelarse, por lo que hay que pensar que
lleva algo más de trabajo en comparación con la manzana, pero tampoco mucho más. Sin embargo, la
piña sí es laboriosa. Y mucho más el coco, ya que no saben cómo abrirlo o se necesitan herramientas
que no se tienen en la cocina habitualmente. El kiwi, por ejemplo, va a recibir cero puntos, porque no le
gusta a nadie del equipo y no lo van a comer.
Estimando cómo comer la fruta

FRUTA PUNTOS DE HISTORIA
Kiwi 5 sp
Naranja 0 sp
Fresa 1 sp
Uvas 2 sp
Plátano 3 sp
Manzana 2 sp
Coco 40 sp
Piña 20 sp
Serie modificada de Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100…)
10.3. Velocidad de un equipo Scrum
Como consecuencia del uso de los puntos de historia, se va a utilizar otro concepto para medir el
rendimiento de un equipo Agile a lo largo del proyecto. Para esto se usarán los story points que se verán
más adelante con detenimiento.
10.4. Técnicas para estimaciones
Las estimaciones en Agile no son creadas por una única persona del equipo, sino que son compartidas por
todos los miembros del equipo. La mejor definición de una estimación en Agile sería la siguiente: “El
equipo se compromete a tener completada esta historia de usuario dentro de la próxima iteración
(independientemente de quién sea el encargado final de ejecutarla)”.
Por otra parte, las estimaciones en Agile no las planifica el project manager, ni siquiera el Scrum master,
sino que son desarrolladas por el equipo que se compromete a ejecutar ese trabajo.
72/104
Opinión de experto
Esta herramienta es más utilizada en proyectos adaptativos que en proyectos ágiles, dado que por la
propia composición de los equipos multidisciplinares no suele ser habitual llamar a expertos externos
para analizar y estimar las historias de usuario y sus tareas asociadas.
En un proyecto predictivo la estimación suele estar asociada a las tareas, por lo que tiene sentido llamar
al experto en esa tarea en concreto. Sin embargo, para completar una historia de usuario hará falta tener
más de una habilidad o conocimiento técnico, típicamente distribuido en todo el equipo. Por ello, aquí
el experto no es tanto una persona como todo el equipo trabajando como una melé (Scrum).
Analogía
Hay muchos estudios y evidencias de que las personas son mejores estimando el tamaño relativo de
algo en comparación con otro elemento conocido que estimando su tamaño absoluto.
Las estimaciones por puntos de historia se basan en esta evidencia, y tratan de comparar la complejidad
de una historia en comparación con la complejidad de otra historia pasada ya conocida.
Por tanto, un equipo en Scrum será tan bueno estimando y planificando en la medida en que tenga la
suficiente experiencia como para poder comparar tamaños relativos. Se entiende que un equipo es
sostenible en el tiempo por el conocimiento que atesora y su experiencia. Además, esta experiencia
afecta a su tamaño y componentes del equipo. Si los miembros del equipo cambian, este conocimiento
se pierde en parte.
Disgregación
Dividir el proyecto en secciones más pequeñas y manejables lo hace más fácil de estimar y planificar.
Scrum no prescribe una sola manera para que los equipos estimen su trabajo. Sin embargo, sí solicita
que los equipos no realicen una estimación en términos de tiempo, sino que, en cambio, utilicen una
métrica más abstracta para cuantificar el esfuerzo. Los métodos de estimación comunes incluyen tamaño
numérico (1 a 10), tamaños de camiseta (XS, S, M, L, XL, XXL, XXXL), la secuencia de Fibonacci (1,
2, 3, 5, 8, 13, 21, 34, etc.).
10.4.1. Planning poker
73/104
La mejor herramienta para estimar en entornos Agile es planning poker (Grenning, 2002), mitad juego, mitad
dinámica grupal; esta herramienta fue definida originalmente por Grenning en 2002 y popularizada por Mike
Cohn en Agile Estimation and Planning. Combina las tres herramientas antes comentadas: opinión de
experto, ya que se realiza entre las personas que van a realizar el trabajo; analogía, comparando cada
historia de usuario con historias previas conocidas, y disgregación, al dividir posteriormente los temas o
épicas de grandes dimensiones en historias de usuario más pequeñas y fáciles de estimar.
La principal ventaja de este método es que es muy rápido y sencillo de implementar. Funciona
correctamente de una forma sencilla para equipos Agile (6 ±3 personas), y en proyectos donde es
necesario estimar de una forma rápida no más de 30 historias de usuario.
Cuando un equipo Scrum estima, necesita hacer uso de una escala de estimación que evite el uso de
valores comodín que no faciliten una definición correcta de los puntos por historia. Si, por ejemplo, se
hace uso de un subconjunto limitado de números naturales del 1 al 10, la mente humana suele tender a
utilizar la zona media cuando no sabe qué estimación dar. Esto podría llevar a un proceso de estimación
donde todas las historias de usuario tiendan al 5 y no permitan realmente comprender su tamaño real.
Para mejorar las estimaciones haciendo uso de puntos de historia, los equipos de Scrum utilizan escalas
de números naturales no consecutivos. Entre ellas, la más popular es la escala de Fibonacci modificada.
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Estas escalas obligan a hacer uso de una serie exponencial cuando se está estimando. Este tipo de series
permiten que la estimación crezca mucho más despacio cuando se tiene más detalle sobre los conceptos
que se estiman, mientras que para las zonas desconocidas los valores crecen de una forma mucho más
elevada.
El equipo está obligado a estimar haciendo uso de valores más detallados cuando conoce mejor la
historia de usuario, mientras que para aquellas historias que desconozca deberá hacer uso de valores
más altos, que se disparan cuanto más se mueven hacia la zona de incertidumbre. Ninguna historia
quedará en una zona intermedia de valores: o queda bien definida o quedará estimada con valores tan
altos que no podrá implementarse.
Mediante esta técnica se van a estimar los puntos de historia correspondientes a una serie de historias de
usuario en las que se ha desarrollado el proyecto. Como se ha comentado sobre los puntos de historia o
story points , se va a estimar la complejidad, no el esfuerzo ni la duración de una historia.
74/104
La estimación no va a depender del experto que valore, dado que cada historia no está asignada a nadie
en concreto. Todos los miembros están presentes, y se contará con expertos de todas las áreas
involucradas en el proyecto (Business + IT + Design + Security), de tal forma que se tengan
conocimientos suficientes para valorar todas las historias.
El proceso de votación descrito a continuación evita alargar las negociaciones.
Para poder valorar se utiliza la serie de Fibonacci, en la que los valores al principio de la serie no
implican demasiada diferencia, aumentando esta diferencia a medida que los valores crecen. Con estos
valores se es consciente del principio de la disgregación: es posible equivocarse poco al estimar tareas
pequeñas, pero es más complicado estimar tareas complejas y muy grandes. Cuando esto ocurre, el
equipo puede dividir la historia en historias más pequeñas, fáciles de estimar y comparar contra otras ya
conocidas.
Figura 22. Agile planning poker in person
Figura 22. Agile planning poker in person.

Fuente: Flicker.
75/104
Dinámica grupal
Todos los miembros del equipo de proyecto estiman todas las historias de usuario dado que no se
conoce quién va a realizar la tarea. En un equipo multidisciplinar y autosuficiente es habitual que todos
puedan realizar alguna tarea en algún momento, aunque necesariamente no tengan que ser especialistas
en ese campo (developers , testers , programadores, ingenieros de sistemas, expertos en datos,
diseñadores, analistas, etc.).
Por ello, planning poker evita dos extremos influyentes que afectan a las estimaciones. Por un lado, evita
que el experto especialista en un tema imponga su criterio influyendo en los demás. Esto se evita
creando una votación semioculta, ya que todos levantan su voto al mismo tiempo. Por otro lado,
cualquiera vota sobre todas las historias, aunque no sepa realizar la tarea, de modo que compensa la
opinión del experto técnico. Evita a las personas más influyentes, optimistas o vagos, que ven su
opinión fuera del consenso.
Durante la presentación de cada historia de usuario, se comentan las características del producto. El
equipo hace preguntas, analiza los riesgos, resuelve las dudas sobre las funcionalidades, los aspectos
técnicos, etc.
El resumen de esta discusión lo recoge el Scrum master o project manager.
Como se ha comentado, la votación la realizan todos a la vez a mano alzada, levantando la carta con el
valor que estimen más apropiado para el esfuerzo que será necesario realizar.
Lo normal es que en la primera votación haya discrepancias, valores altos y valores muy bajos, junto
con un cúmulo de valores intermedios. Se deja a las personas que han votado los valores más altos y
más bajo que justifiquen su criterio, aportando al equipo posibles riesgos o alternativas que solo ellos
han visto.
En una segunda ronda, cada miembro reconsidera su votación y la corrige considerando la nueva
información aportada por estos dos miembros del equipo. Así hasta llegar al consenso entre todo el
equipo. En caso de que no se llegue al consenso, el Scrum master puede decidir tomar el valor más
apropiado y continuar con la siguiente historia de usuario.
Con esta herramienta las estimaciones son menos optimistas que con otros métodos, al tener que llegar
a un acuerdo en equipo. El juicio de expertos se ve corregido por la valoración de personas que
posiblemente no tengan los conocimientos técnicos para realizar esa tarea
76/104
Valores de las cartas
Serie numérica de Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100): el uso de la serie de Fibonacci se explica
porque a medida que las historias son mayores también es mayor la diferencia entre una carta y la
siguiente. Hay poca diferencia entre los valores de las cartas pequeñas, mientras que entre las cartas
mayores existe mucha diferencia. En lo pequeño la equivocación es poca al estimar, mientras que en las
historias grandes la estimación se vuelve compleja. Esto lleva a la siguiente reflexión: ¿será mejor dividir
las historias grandes en dos más pequeñas que son más fáciles de estimar?
Una derivada de este problema es la tendencia a eliminar las estimaciones. Muchos desarrolladores
prefieren planificar siempre historias pequeñas, y eliminar el tiempo dedicado a estimar las grandes.
Figura 23. Planning poker.

10.4.2. Tamaños de camisetas
Una alternativa a los puntos de historia es el método de estimación por afinidad, utilizando tamaños
relativos y agrupando aquellas historias con tamaños similares.
Este método utiliza los tamaños de las camisetas (S, M, L y XL), y es muy útil si hay un gran número de
historias que estimar. Normalmente, cuando existen más de 30 historias o épicas se hace primero este
ejercicio antes de utilizar planning poker.
77/104
Figura 24. T-shirts/sp/hours.
Figura 24. T-shirts/sp/hours.

La mecánica es sencilla. Sobre la pared de war room se agrupan aquellas épicas o funciones que se
consideran más sencillas en torno a la S, la referencia de una función normal será M, y L y XL se reservan
para aquellas funciones de mayor dificultad.
78/104
Figura 25. T-shirts
Figura 25. T-shirts .

10.4.3. Velocidad y cronograma
La velocidad será la suma de los puntos de historia asociada a todos los trabajos realizados por el equipo
de proyecto a lo largo de una iteración. Si un equipo ha realizado tareas cuya estimación en puntos de
historia era de 10 puntos, su velocidad es de 10.
Si un equipo ha realizado 10 puntos de historia en la última iteración, parece lógico pensar que en la
siguiente iteración también serán capaces de completar trabajos que conlleven 10 puntos. Esto se cumplirá
independientemente de si trabajan en dos historias de 5 puntos, o en cinco historias de 2 puntos, dado que
el valor de cada punto es relativo, no obedece a ninguna cantidad neta.
Para que esto se consume, hay que cumplir con los requisitos que marca Scrum: la duración de las
iteraciones es siempre la misma, y los equipos son fijos y sostenibles en el tiempo.
79/104
¿Cómo pasar de story points a días del cronograma?
Llegado el momento, habrá que planificar un calendario, o decirle al jefe que se terminará el proyecto
antes de las vacaciones de verano.
“¡Bien hecho! ¿Para cuándo será eso?”.
Así se estima el tamaño con base en puntos de historia, pero se necesita conocer la duración. Por
ejemplo, si la suma de todas las historias de usuario del proyecto es de 100 sp, esta será la estimación
de todo el proyecto. Si dada la experiencia previa del equipo en este y otros proyectos se conoce que
tiene una velocidad de 10 para sprints de dos semanas, no se esperan cambios en el equipo, y se parte
de la hipótesis de que la velocidad no cambiará tal y como va el proyecto, de la estimación de tamaño y
velocidad se puede concluir que el proyecto llevará 10 sprints o iteraciones de dos semanas, o lo que es
lo mismo, 20 semanas en el calendario.
10.5. Priorización de las historias de usuario
Determinar la priorización de las distintas historias de usuario y temas es una parte esencial de la
planificación que debería realizarse entre todo el equipo, junto con el product owner.
Entre los factores a tener en cuenta para la priorización de las historias, están, entre otros:
El valor financiero o económico de poseer una funcionalidad concreta de la historia.
El coste asociado a su desarrollo.
El conocimiento adquirido por el hecho de trabajar y desarrollar esa funcionalidad.
El riesgo y la incertidumbre que se eliminan del proyecto al completar ese trabajo.
10.5.1. Valor financiero
80/104
Es complicado calcular el valor financiero de una historia de usuario o un tema. Este valor va asociado a
la explotación comercial del producto o servicio, y no siempre se será capaz de vincular un beneficio
económico al hecho de conseguir desarrollar una funcionalidad del proyecto. En la asignatura acerca del
inicio del proyecto, se justificaban estos datos financieros respecto a un portafolio de proyectos.
Comparar distintos releases o lanzamientos de partes de un producto vendría a ser un ejercicio similar.
Sí es más fácil intuitivamente asociar las historias y temas a elementos de valor para el negocio: ¿el cliente
podría sacar provecho de tener terminada esta funcionalidad lo antes posible?
10.5.2. Coste
El coste es una de las restricciones clave para el proyecto y suele variar debido a cambios en este. En
el tiempo que pasa desde la planificación de una funcionalidad hasta que se ha completado ese trabajo hay
muchas posibilidades de que el cliente u otro interesado añadan o cambien algo crítico que conlleve
sobrecostes.
La mejor forma de reducir el sobrecoste entre una estimación inicial y el coste final de desarrollar una
historia o funcionalidad es completar ese trabajo lo más tarde posible, evitando los sobrecostes derivados
de cambios en la definición de la historia. De una forma efectiva, cuando ya no quede más tiempo hábil
para introducir cambios al trabajo.
ASAP vs. ALAP
Hacer las cosas cuando no queda más remedio, o as late as possible.
10.5.3. Aporte de conocimiento
Uno de los beneficios que puede aportar una funcionalidad concreta y difícilmente cuantificable como
beneficio financiero es el conocimiento:
Conocimiento acerca del producto o servicio.
Conocimiento acerca del proyecto.
A medida que se avanza en el proyecto aumenta la capacidad para tomar decisiones acertadas con base en
la información que se va consolidando. La incertidumbre acerca del proyecto disminuye, y el cono de
rango de valor de las estimaciones se va acercando a los valores reales y definitivos. También se va
concretando y dejando menos alternativas acerca del diseño y las características técnicas sobre cómo se
construirá el proyecto.
81/104
Las dos fuentes de incertidumbre que se van acotando tienen que ver con el análisis del producto (qué) y el
diseño del proyecto (cómo). En un proyecto predictivo el proceso de análisis de funcionalidades termina
definiendo todos los aspectos del producto para luego pasar a definir cómo se va a realizar. En un
proyecto adaptativo, la definición del producto y la solución técnica para construirlo se van a ir
desarrollando al unísono. La explicación práctica es sencilla: un cliente no deja de tener incertidumbre
acerca del producto hasta que no lo ve construido. El principal riesgo de muchos proyectos es
precisamente construir el producto equivocado, de ahí que poder mostrar partes funcionales del proyecto
al cliente lo antes posible ayude a acotar este riesgo.
10.5.4. Riesgo
Tomando como valor de priorización la eliminación del riesgo que aporta el completar una funcionalidad
concreta, se pueden dar cuatro situaciones:
Hacer primero aquellas funcionalidades que aportan un alto valor al proyecto, y trabajar sobre ellas
elimina riesgos de gran impacto.
Hacer en segundo lugar historias que aportan gran valor al proyecto pero no reducen significativamente
el riesgo del proyecto.
Dejar para el final las historias que no aportan demasiado valor al proyecto, pero tampoco riesgo.
Evitar hacer historias sin valor pero cuya ejecución conlleva mucho riesgo al proyecto.
10.5.5. El método MoSCoW
El método MoSCoW es una técnica de priorización utilizada para llegar a un acuerdo común con las partes
interesadas de un proyecto sobre la importancia que ellos otorgan a cada uno de los requisitos de entrega.
Puede aplicarse para facilitar la priorización del product backlog en Scrum, como en otras metodologías
ágiles.
El término responde al acrónimo de las siguientes palabras en inglés:
82/104
Must have
Must have (debe tener). Aquellos requisitos que son críticos para el éxito del desarrollo actual. Si una
historia must no se finaliza, el proyecto entero se considerará un fracaso.
Should have
Should have (debería tener). Las historias de usuario marcadas con should son importantes, pero no
necesarias para el tiempo de desarrollo cerrado del que se dispone. Los requisitos should se pueden
implementar siempre y cuando no impacten en la no terminación de un requisito must. En caso
contrario, se puede dejarlos de lado e implementarlos si se cuenta con más plazo en el proyecto.
Could have
Could have (podría tener). Historias de usuario deseables, pero no necesarias. Si se llevan a cabo,
podrían mejorar la experiencia del usuario y su satisfacción con un bajo coste.
Won’t have
Won’t have (no va a tener). Historias de usuario con este tag son requisitos conocidos que carecen
de importancia alguna para el release actual del producto. Están en el product backlog como referencia,
pero pertenecen a la parte más profunda de la lista donde no se va a trabajar en la entrega actual.
Las partes interesadas deberán calificar todas las historias de usuario siguiendo estos principios de
clasificación. Todos ellos deberán estar de acuerdo con la clasificación final y esta podrá ser modificada en
cada sprint en concierto con el principio de aceptación de cambio de priorización en la pila del producto o
product backlog de Scrum.
Esta técnica funciona muy bien para enfrentarse a audiencias grandes en el lado del cliente. La clasificación
de las historias siguiendo este criterio es sencilla, entendible para todos y de fácil consenso.
83/104
Figura 26. MoSCoW, votación con stickers o puntos
Figura 26. MoSCoW, votación con stickers o puntos.

Fuente: Wikipedia Commons (https://en.wikipedia.org/wiki/Dot-voting).
10.5.6. Mapeo de historias de usuario
El mapeo de historias de usuario es una herramienta valiosa para el desarrollo de proyectos. Esta técnica
puede ayudar al equipo a mantenerse centrado en los usuarios durante el desarrollo del proyecto, sin
perderse en el entusiasmo por desarrollar las características individuales del producto.
Los mapas de historias de usuario sirven como herramienta de comunicación, y permiten al equipo
mantener mejores conversaciones sobre el proyecto a lo largo del proceso de desarrollo, y especialmente
con el cliente.
En los orígenes del mundo Agile, del desarrollo de software, se utiliza esta potente herramienta visual
para representar todas las funcionalidades de un desarrollo o proyecto de software desde un punto de
vista sistémico, donde se representa el sistema completo basándose en la arquitectura del proyecto y
comprendiendo todas las funcionalidades requeridas.
El objetivo es reorganizar todas las tareas previstas en tres dimensiones: por áreas de desarrollo o
negocio, en el tiempo y según prioridades. Para ello se distribuyen en distintas columnas y se utilizan
cartulinas o fichas de diferentes colores a lo largo de toda una pared o sala de trabajo (war room) con
todos los interesados reunidos.
84/104
En un primer lugar se definen las áreas o temas en columnas verticales que van a representar las grandes
áreas funcionalidades, departamentos que participan en este proyecto o cualquier otro criterio según sea
el proyecto.
Para luego pasar a descomponer en historias de usuario que se irán ordenando secuencialmente
(verticalmente hacia abajo) según la prioridad que se decida, por ejemplo, las de más valor al comienzo.
Se pueden utilizar los colores de los pósits o cartulinas para asignar equipos de trabajo, diferenciar
perfiles técnicos, de funcionales, tareas críticas, etc.
En entornos de proyectos Agile la estructura matricial resultante ayuda a definir las diferentes iteraciones,
o release (lanzamientos de producto o subproductos) de entrega del producto final.
Una limitación de esta potente herramienta visual es el conseguir un espacio físico lo suficientemente
grande y disponible para mantener el user story mapping visible durante todo el proyecto.
Esta herramienta ayuda a tener una visión global del proyecto y a no perder el horizonte de lo que hay
que realizar, a no dispersarse y a que esté todo el equipo en la misma página durante la ejecución del
proyecto.
Aunque se trata de una herramienta aparentemente fácil, su complejidad va implícita con el proyecto.
Aunque generalmente se sabe qué se quiere hacer, cuando se pasa a concretar el cómo hacerlo la
definición de la arquitectura y la solución técnica es menos obvia.
Para el desarrollo del user story mapping es conveniente que el equipo Agile esté guiado por un Scrum
master o Agile coach que, como facilitador, vaya guiando y marcando las pautas a seguir por todo el
equipo. Es esencial la colaboración y participación de todas las personas del equipo de proyecto que
van a construir el user story mapping conjuntamente. Es conveniente, además, que estén presentes
representantes de los departamentos afectados e interesados principales, que ayudarán a definir las
historias de usuario.
85/104
Un desglose de este tipo se realiza en ocasiones en el documento de alcance, o en el de toma de

requisitos. En ocasiones se suelen utilizar hojas Excel u otra herramienta informática específica para
estas tareas. La ventaja de esta dinámica, una vez más, es el componente colaborativo y participativo del
equipo y de todos aquellos interesados del proyecto.
También funciona como herramienta de comunicación y radiador de información, ya que de un simple

golpe de vista, y sin ser parte del proyecto, cualquiera puede ver el avance o cambios significativos en el
“mapa” que indica cómo va el proyecto.
Figura 27. Mapeo de historias de usuario distribuido en distintos lanzamientos del producto
Figura 27. Mapeo de historias de usuario distribuido en distintos lanzamientos del producto.
XI. Cómo evolucionar hacia una organización ágil

Se conoce como agilidad organizacional la capacidad de una organización para detectar y responder
rápidamente a los cambios del mercado, aportando valor al cliente de forma continuada. Esta no es una
tendencia que se pueda considerar de futuro. El número de lanzamientos de nuevas iniciativas y soluciones
se ha incrementado en los últimos veinte años en un cinco por ciento según el estudio Decision Latency
Theory, de Jim Johnson.
En esta línea, el Project Management Institute (PMI) elaboró el informe Pulse of the Profession In-Dept
h Report: Organizational Agility sobre cómo la agilidad está impactando en el éxito empresarial y cómo
incrementar esta capacidad. Aquellas organizaciones que declaraban un aumento en el lanzamiento exitoso
de nuevos proyectos y productos al mercado lo lograban gracias a unas condiciones de mayor flexibilidad,
convirtiéndolas en mejores competidores.
86/104
Además del crecimiento económico, la adaptabilidad y la mayor capacidad de lanzamiento de productos y

servicios con mejores probabilidades de éxito, la agilidad organizacional conlleva un cambio cultural dentro
de las organizaciones. Esto implica que los factores relacionados con las personas, profesionales, usuarios,
etc., son los más determinantes.
El estudio Organizational Agility muestra cómo las empresas estaban abordando un cambio cultural y de
procesos de negocio dirigido a tres ejes fundamentales:
Gestión del cambio
En primer lugar, potenciando una mejor gestión del cambio para adaptarse mejor a las necesidades del
mercado. Las organizaciones eficaces en la gestión del cambio son más ágiles no solo reduciendo el
impacto de cambios provenientes de factores externos, sino también por su mayor capacidad para
capitalizar las oportunidades que se puedan presentar, como nuevas tecnologías, nuevos clientes, etc.
Gestión de riesgos más efectiva y colaborativa
El segundo eje para considerar en este cambio hacia la agilidad es una gestión de riesgos más efectiva y
colaborativa. Cuando las organizaciones se ven obligadas a tomar decisiones rápidas, a veces pueden
perder el control. La gestión eficaz de riesgos ayuda a los ejecutivos y líderes de proyectos a identificar
y mitigar los factores que podrían evitar el éxito.
Conceptos como customer centric o target value design son cada vez más habituales en la
concepción de nuestros proyectos. La colaboración temprana con el resto de interesados del proyecto
facilita la identificación de la mayor parte de riesgos, y su mitigación o eliminación antes de comenzar la
fase de construcción. Del mismo modo, el propio usuario final tiene cada vez más capacidad de
decisión respecto al proyecto, y gracias a la tecnología se puede hacerle partícipe del proyecto.
Gestión profesional de proyectos, programas y portafolios
El tercer eje de aplicación es un mayor uso de prácticas estandarizadas en la gestión de proyectos,

programas y portafolios. Los directivos de todas las empresas solo tienen una cosa en mente: actuar
rápido frente a las condiciones cambiantes económicas, demandas y prioridades de la propia
organización. Pero la gestión de la estrategia y la priorización de qué proyectos poner en marcha y en
qué momento solo se pueden realizar desde una perspectiva profesional y estandarizada. Es
imprescindible una base sólida en gestión de proyectos, programas y carteras de proyectos.
(Este último apartado está basado en el editorial para el número 2018-03 de la revista científica Building
& Management).
XII. Resumen
87/104
Agile y Scrum son términos que la gente suele mezclar y confundir. Pero hay que recordar que Agile y
Scrum son dos cosas que, aun relacionadas, son muy diferentes.
Agile es una creencia, una forma de ser y de ver la vida.
A pesar de sonar algo extraño en el mundo de la IT, es una afirmación completamente cierta. Agile es una
filosofía, una forma de ver la cultura de entrega de proyectos mucho más moderna y sincera que las
metodologías tradicionales. Scrum es un marco de trabajo para el desarrollo ágil de productos de software.
Es muy importante distinguir estos dos términos porque Scrum es algo que cualquier persona puede
aprender mientras que el agilismo es una forma de pensar que no todo el mundo en el ámbito empresarial
está preparado para adoptar. Muchas son las personas que piensan que pueden trabajar en proyectos ágiles
porque comprenden a la perfección Scrum, pero sin una mente ágil que respete los principios básicos es
imposible tener éxito en este tipo de metodologías.
Una persona agilista debe creer en una serie de principios básicos sin los cuales las metodologías ágiles no
pueden funcionar correctamente. Y los principios ágiles no pueden funcionar correctamente sin aplicar lo
siguiente:
Individuos e iteraciones sobre procesos y herramientas.

Software funcionando sobre documentación terminada.
Colaboración del cliente sobre la negociación contractual.
Preferencia por el cambio frente a los planes rígidos.
El término agilismo no representa una metodología en sí misma. El agilismo es un término que define una
nueva forma de afrontar los proyectos de tecnología. A los principios propuestos por esta nueva forma de
pensar se adhieren diferentes marcos de trabajo, como pueden ser las metodologías Crystal, Lean, extreme
programming (XP) o Scrum.
Cada una de estas metodologías propone diferentes formas de trabajar en equipo que cumplen y respetan
los principios básicos del agilismo. Cada una de ellas incluye diferentes artefactos y ceremonias para
desarrollar proyectos de software.
Scrum es una metodología de trabajo donde se aplican, de manera regular, un conjunto de prácticas
recomendadas que están orientadas a respetar los principios básicos de Agile, como son trabajar en
equipo, de forma colaborativa, directamente con el cliente y entregando incrementos de producto en
tiempos regulares. En esta unidad se han analizado los diferentes roles participantes, los artefactos básicos
para implementar Scrum y las ceremonias para activar las interacciones que permitan desarrollar nuevos
productos de una forma ágil.
La más popular entre todas ellas es Scrum, pero las demás existen y están aquí para quedarse. No es
extraño encontrar equipos que hacen Scrum con modificaciones que provienen de un XP y aproximaciones
similares. Lo importante es el producto…, y los principios de respeto y de trabajo que propone el agilismo.
Cómo llevarlos a cabo puede variar de un equipo a otro.
Agile vs. Tradicional project managment
88/104
XIII. Anexos
“The New New Product Development Game”, de Nonaka y Takeuchi (1986).
Este artículo examinó las prácticas en una serie de empresas de fabricación exitosas, como Fuji-Xerox,
Honda, 3M y Toyota. Los autores llamaron la atención sobre la práctica en esas empresas de un
proceso de desarrollo con fases superpuestas (como un sashimi o una melé), en lugar del enfoque
secuencial más antiguo.
Aparece la primera comparación de esta metodología con el término scrum del rugby, donde un equipo
“intenta avanzar como una unidad”.
Pulsa aquí para acceder a la lectura.
The Scrum Guide , de Jeff Sutherland y Ken Schwaber (2017).
Esta guía contiene la definición oficial de Scrum. Esta definición consta de los roles, los eventos, los
artefactos y las reglas de Scrum, descritos por sus fundadores, Ken Schwaber y Jeff Sutherland. La
guía está escrita y desarrollada por ambos, y se ha actualizado desde su versión original.
Scrum y XP desde las trincheras (2.ª ed.), de Henrik Kniberg.
Este documento no pretende representar “el camino correcto” para hacer Scrum. Solo representa una
forma de hacer Scrum, el resultado de un refinamiento constante de más de un año.
Todo en este documento refleja las opiniones subjetivas personales y no es una declaración oficial de
Scrum, aunque los dos fundadores de Scrum avalan este documento desde su prefacio.
89/104
Ejercicios
Caso práctico
Enunciado
Figura 1. Transformación digital y metodologías ágiles
Figura 1. Transformación digital y metodologías ágiles.

Fuente: Autentia.
En este ejercicio se va a utilizar el mapeo de historias para la planificación a alto nivel de un proyecto
concreto.
El caso se basa en una empresa tradicional dedicada a la venta de pan con sus propios despachos o
panaderías.
Los distintos hábitos de consumo de las nuevas generaciones, diferentes gustos y necesidades, así
como distintas preferencias alimentarias, hacen que esta empresa cada vez venda menos pan a través de
sus pequeñas panaderías de barrio.
Por otra parte, los despachos de la panadería son tiendas pequeñas de barrio, con horario comercial
tradicional que ya no se ajusta a las agendas de los nuevos clientes. Estos están más acostumbrados a
comprar pan industrial en los grandes centros comerciales una vez a la semana. Poco a poco han dejado
de bajar a comprar la barra de pan cada día, aunque tengan la panadería debajo de casa.
90/104
También ha aparecido nueva competencia en el despacho de pan. Cada vez existen más
establecimientos de todo tipo que venden este producto, desde gasolineras hasta bazares en los que se
puede comprar casi de todo. Estos establecimientos tienen horarios continuados, con lo que se adaptan
mejor al momento de la compra.
Esto ha hecho caer los ingresos de la panadería tradicional paulatinamente. Venden cada vez menos
barras de pan.
El objetivo del gerente es recobrar el nivel de ventas que solían tener y aumentar así los
ingresos por ventas.
El gerente de la empresa panadera ha oído hablar de la industria 4.0, y piensa que las nuevas tecnologías
pueden ayudar también a su negocio.
Tiene una idea en mente: desarrollar una aplicación informática para que cualquiera pueda comprar pan a
través de Internet. Una aplicación sencilla que facilite al usuario comprar el pan a cualquier hora sin
necesidad de pasarse por la panadería. El pedido podría despacharse bien a través de las tiendas
tradicionales o bien a través de un repartidor que lo llevaría al domicilio del cliente.
Deliberando solo acerca de un usuario, el propio comprador, es fácil pensar en un proceso de compra a
través de la pantalla de la aplicación, que contaría con el botón para pedir pan.
¿Es posible añadir más funcionalidades? También podrían aparecer unos controles para sumar o restar
barras de pan, dar la opción de corregir el pedido, ofrecer otros productos generales, como leche,
galletas, zumos o similar. Podrían ser productos genéricos o, al tener la información del cliente concreto
y su histórico de compras, hacer recomendaciones personalizadas.
Y ¿qué hay de añadir un chat o compartir en redes sociales?
La lista de funcionalidades empieza a alargarse y el gerente cree que seguramente sea caro y se
prolongue mucho en el tiempo el desarrollar un producto así.
91/104
Además, aparecen nuevos problemas. Implementar la tecnología a sus operaciones de venta va a afectar
a otros departamentos. Sería necesario contratar personal de reparto, comprar bicicletas eléctricas o
motocicletas, dotar a los repartidores de algún sistema instantáneo de comunicación, conectar con las
tiendas físicas para organizar los pedidos desde cada despacho más cercano, determinar el catálogo de
productos complementarios o incluso modificar el CRM para personalizarlo para cada cliente, gestionar
las reclamaciones de estos… El nuevo producto de la app va a afectar a todos los departamentos de la
empresa. No puede pensar solo desde el punto de vista del usuario-cliente.
El gerente de la panadería se da cuenta de que implantar algo así va a transformar su organización,

empieza a entender el significado de la transformación digital y sospecha que no va a ser un proceso
barato.
Un enfoque tradicional para desarrollar este proyecto obligaría a pensar en todas las funcionalidades que
se quiere que tenga la nueva aplicación. Definir el alcance del proyecto será una tarea compleja y
deberán estar involucrados todos los departamentos. Y el gerente de la panadería tiene serias dudas de
que sean capaces de cerrar todas las características de un proyecto tan novedoso. Nunca se ha hecho
algo así en la panadería. Tampoco tiene claro que los clientes vayan a aceptar este cambio y adopten el
uso de la nueva aplicación. Será probable que, según vaya avanzando el proyecto, cada responsable vea
con mayor claridad en qué podría ayudar esta aplicación a su departamento.
Por todo ello, el gerente opta por otra aproximación. Se definirá este proyecto de acuerdo con un ciclo
de vida adaptativo, pudiendo desarrollar una versión reducida de la aplicación para después ir
incrementando en sucesivas iteraciones. Esto le permitirá contar con algo sencillo, pero que sirva para
comprobar si la solución es buena y la aceptan los clientes que ha ido perdiendo por el camino.
Product road map
La técnica del mapeo de historias puede ayudar al equipo a mantenerse centrado en los usuarios durante
el desarrollo del proyecto, sin perderse en el entusiasmo por desarrollar todas las características que van
apareciendo en el backlog del producto. El hecho de tener que meditar las historias y ponerse en el rol
de cada usuario particular que va a interactuar con el producto obliga a centrarse en el cliente, ya sea
interno o externo.
La segunda derivada de realizar el mapeo del producto es diferenciar las distintas funcionalidades o
historias de usuario en función del valor que aportan al negocio. En este caso, el objetivo principal de
la panadería es aumentar la venta de pan y generar mayores ingresos con ello.
Con esto en mente, se puede acotar el producto para lanzar una prueba con aquellas funcionalidades
imprescindibles lo antes posible para comprobar que la hipótesis del gerente es correcta.
92/104
El producto mínimo viable es el mínimo de funcionalidad con el que tendríamos que lanzar el producto
al mercado para que permita validar que el este y los usuarios lo reciben y lo aceptan como algo de
valor. Dependiendo de la definición del objetivo, entrarán más o menos características y procesos en
ese producto mínimo viable.
Después de un ciclo de vida corto en el que ideación y construcción irían de la mano, habría un primer
prototipo funcionando. En sucesivos releases se tendría la oportunidad de ampliar las características del
producto con más funcionalidades. Hay que recordar que cada release o lanzamiento de producto
puede estar compuesto por uno o varios sprints , dado que el objetivo de un sprint no será suficiente
para completar un producto con las capacidades mínimas como para sacarlo al mercado.
En ice box podrían quedarse aquellas características que son interesantes, pero no con el suficiente
valor como para dedicar tiempo y recursos a desarrollarlas, al menos de momento.
Los usuarios (clientes, departamentos o roles de negocio) representados en este mapa del producto serán
los siguientes:
Gerencia
Gerencia (supervisor o gerente de la empresa).
Administración
Administración (personal encargado de gestionar facturas, pedidos, clientes, ERP, etc.).
Operaciones
Operaciones (encargado de la tienda o panadería/repartidor).
Soporte
Soporte (departamento de sistemas o informático que da soporte técnico a la aplicación).
93/104
Clientes o usuarios
Clientes o usuarios (tanto los clientes que se hayan registrado en la aplicación como aquellos que la
usen de forma anónima, sin registrarse).
En una reunión de análisis del producto que ha organizado el gerente con todos los encargados de
departamento han salido una serie de funcionalidades o características que podría tener la nueva aplicación
móvil. Se enumeran a continuación solo las funcionalidades. Más adelante tendrás que completar la fórmula
de las historias de usuario pensando en el departamento, rol o “usuario” al que pertenecen.
Descargar app .
Buscar si hay cobertura del servicio.
Buscar información nutricional.
Loguearse.
Registrarse.
Recuperar contraseña.
Visualizar condiciones/texto legal y otros.
Realizar un pedido.
Consultar estado de un pedido.
Cancelar un pedido.
Abrir una incidencia.
Consultar el histórico de pedidos/favoritos.
Aceptar productos propuestos por el sistema CRM.
Añadir un pedido a favoritos.
Añadir productos de la tienda estándar.
Reenviar un pedido favorito.
Realizar pedido diario de pan congelado.
Consultar los pedidos existentes.
Procesar el pedido y entregar al repartidor.
Entregar pedido al cliente.
Registrar incidencia en entrega.
Validar un pedido de muchas unidades.
Validar la devolución de dinero a un cliente.
Realizar un pedido a nombre del cliente.
Consultar el estado de un pedido del cliente.
Iniciar un pedido compensatorio.
Retornar el dinero a un cliente.
Cargar app .
Desarrollar app móvil para Android.
Desarrollar app móvil para Apple.
Cambiar los parámetros del sistema (imagen, precios, tipos, etc.).
Proponer productos a enviar en el mismo pedido.
94/104
Generar factura mensual al cliente.

Generar el informe mensual de rentabilidad (tique vs. histórico).
Por ejemplo, se puede tomar la primera característica y darle un formato de historia de usuario:
Se pide
Deberás desarrollar los siguientes apartados para diseñar un escenario en el que la empresa pueda lanzar al
mercado una aplicación online para la venta de pan. Para ello, considera las características que tendría tu
propuesta de producto mínimo viable.
Completa la definición de cada historia de usuario.
Agrupa las historias en función del usuario al que se refieren: cliente, gerencia, administración, etc.
Distribuye las historias proporcionalmente entre PMV, release 1 y release 2 (alrededor del 30 % de
historias en cada lanzamiento sin entrar a valorar su tamaño o complejidad). Deja en el ice box aquellas
historias que no veas que aporten valor a tu propuesta de solución.
Explica brevemente cuál ha sido el criterio que has seguido para llegar a esa solución.
No hay una solución única. La distribución de los distintos lanzamientos o releases dependerá del criterio
de tu solución. Por ejemplo, puedes priorizar una solución web frente a una app para Android o preferir
Apple como primera opción. Dependerá de tu criterio.
Solución
No existe una única solución. Puede haber tantas soluciones como empresas y aplicaciones. Sí es
necesario que la explicación que se ofrezca sobre la distribución sea coherente y esté alineada con el
objetivo de negocio: aumentar la venta de pan y los ingresos.
La distribución de los distintos lanzamientos o releases dependerá del criterio de tu solución. Por ejemplo,
puedes priorizar una solución web frente a una app para Android o preferir Apple como primera opción.
Dependerá de tu criterio.
95/104
Usuario cliente anónimo
Usuario cliente anónimo:
Descargar app .
Buscar si hay cobertura del servicio.
Buscar información nutricional.
Loguearse.
Registrarse.
Recuperar contraseña.
Visualizar condiciones/texto legal y otros.
Usuario cliente registrado
Usuario cliente registrado:
Realizar un pedido.
Consultar estado de un pedido.
Cancelar un pedido.
Abrir una incidencia.
Consultar histórico de pedidos/favoritos.
Aceptar productos propuestos por el sistema CRM.
Añadir un pedido a favoritos.
Añadir productos de la tienda estándar.
Reenviar un pedido favorito.
Usuario operador (tienda)
Usuario operador (tienda):
Realizar pedido diario de pan congelado.

Consultar los pedidos existentes.
Procesar el pedido y entregar a repartidor.
Usuario operador (repartidor)
Usuario operador (repartidor):
Entregar pedido al cliente.

Registrar incidencia en entrega.
96/104
Usuario gerencia
Usuario gerencia:
Validar un pedido de muchas unidades.

Validar la devolución de dinero a un cliente.
Usuario soporte
Usuario soporte:
Realizar un pedido en nombre del cliente.

Consultar el estado de un pedido del cliente.
Iniciar un pedido compensatorio.
Retornar el dinero a un cliente.
Proponer productos a enviar en el mismo pedido.
Generar el informe mensual de rentabilidad (tique vs. histórico).
Cargar app .
Desarrollar app móvil para Android.
Desarrollar app móvil para Apple.
Usuario administrador
Usuario administrador:
Cambiar los parámetros del sistema (imagen, precios, tipos, etc.).

Generar factura mensual al cliente.
La propuesta de solución que se plantea ha considerado como prioritario lanzar el producto en formato
web, de modo que en un primer momento solo se podrá comprar online a través del sitio web de la
empresa. De esta manera solo se podrá obtener feedback de unos pocos usuarios, que en un principio
serían invitados por la propia empresa, pero puede ser un inicio para probar y testear la solución.
En un segundo desarrollo se priorizará la solución para Android, ya que el departamento de IT tiene más
experiencia en este campo y el proceso de validación de Apple es más largo. Para esta plataforma se
desarrollará en una tercera versión.
97/104
En la primera versión se quiere centrarse en asegurar que se es capaces de servir los pedidos para
generar ingresos. Para ello, solo se necesita que los clientes puedan realizar compras. Ni siquiera será
necesario loguearse. Tampoco descargar ninguna aplicación, dado que lo harán a través de la web. Una
vez que la empresa sea capaz de servir pedidos y facturarlos, se pasará a introducir mejoras en el
servicio.
Estos progresos se desarrollarán en la segunda versión, encaminada a mejorar la percepción del cliente y
su usabilidad a través de la versión móvil para Android.
La tercera versión ya estará disponible en Apple, pese a que el proceso de subirla a Apple Store ha
supuesto más tiempo que la anterior versión. Otras funcionalidades de gestión de clientes, incidencias y
reclamaciones se han visto necesarias una vez que se ha aumentado la carga de solicitudes.
Llegado el momento habrá que plantearse si hay funcionalidades que dejan de tener utilidad en la
aplicación móvil dado que nadie las está demandando, como consultar las características nutricionales
de los productos. De momento, estas historias se quedarán sin desarrollar mientras no se haga otra
versión.
Pulsa aquí para descargar el archivo adjunto.
98/104
Recursos
Enlaces de Interés
https://www.pmi.org/disciplined-agile: Página oficial del área dedicada a Agile del Project Management
Institute: Disciplined Agile. Una base sólida para la agilidad empresarial basada en la solución
Disciplined Agile.
https://www.europeanceo.com/business-and-management/find-the-right-approach-for-every-project/%
20: Entrevista a Mark Langley, CEO del Project Management Institute: “Everybody wants to be
Agile”.
https://www.agilealliance.org/resources/experience-reports/embracing-agile-mindset-for-organisational-
change/%20: Agile Alliance. Embrancing the Agile Mindset for Organizational Change
https://www.scrum.org/:
https://www.scrumalliance.org:
Bibliografía
Adkins, L. Coaching Agile Teams: A Companion for SCRUM Masters, Agile Coaches, and
Project Managers in Transition. London: Pearson Education/Addison Wesley Professional;
2010. :
Ambler, S.; Lines, M. An Executive’s Guide to Disciplined Agile: Winning the Race to
Business Agility. Disciplined Agile; 2017. :
Ambler, S.; Lines, M.; Smart, J. Choose Your WoW!: A Disciplined Agile Delivery Handbook
for Optimizing Your Way of Working (WoW). Disciplined Agile; 2019. :
Anderson, D. J. Kanban: Successful Evolutionary Change for your Technology Business .
Blue Hole Press, 2010. :
Appelo, J. How to change the world: Management 3.0. Jojo Ventures BV; s. f. :
Appelo, J. Management 3.0 Leading Agile Developers, Developing Agile Leaders. Addison-
Wesley Educational Publishers Inc.; s. f. :
Beer, S. Diagnosing the System for Organizations . New York: Wiley; 1985. :
Brooks, F. P. The Mythical Man-month. Prentice Hall; s. f. :
Cockburn, A. Agile Software Development: The Cooperative Game . London: Pearson; 2007.
:
Cohn, M. Agile Estimating and Planning . London: Pearson; 2005. :
Cohn, M. User Stories Applied: For Agile Software Development. London: Pearson; 2004. :
Coplein, J.; Harrison, N. Organizational Patters of Agile Software Development. Pearson
Prentice Hall; 2005. :
Derby, E.; Larsen, D.; Schwaber, K. Agile Retrospectives: Making Good Teams Great.
Pragmatic Bookshelf; 2006. :
Fowler, M.; Highsmith, J.; Cunningham, W.; Beck, K.; Beedle, M. et al. Manifesto for Agile
Software Development. 2001. [En línea] URL disponible en: https://agilemanifesto.org/
(traducción al español por Ángel Medinilla, Andrés Giné y Esther G&oacut:
Hammarberg, M.; Sunden, J. Kanban in Action. Shelter Island, NY, EE. UU.: Manning
Publications; 2013. :
99/104
Highsmith, J. Agile Project Management: Creating Innovative Products . London: Pearson;

2004. :
Johnson, J. ROI – It´s Your Job. The Standish Group International; 2003. :
Kniber, H. Scrum and XP from the Trinches . Lulu.com; 2015. :
Larsen, S. D. Agile Retrospectives. Making Good teams great. Pragmatic Bookshelf; s. f. :
Lederer, A. L. “Nine management guides for better cost estimating”. Communications of the
ACM; 1992. [En línea] URL disponible en: https://doi.org/10.1145/129630.129632 :
Patton, J. User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly
Media; 2014. :
Project Management Institute. Agile Practice Guide Publisher. Newtown Square, Penn.:
Project Management Institute; 2017. :
Project Management Institute. PMI’s Pulse of Profession – Navigating Complexity. Project
Management Institute; 2013. :
Rasmusson, J. The Agile Samurai: How Agile Masters Deliver Great Software . Pragmatic
Bookshelf; 2017. :
Rawsthorne, D.; Doug Shimp, D. Exploring SCRUM: The Fundamentals . CreateSpace
Publishing; 2011. :
Rubin, K. Essential Scrum: A Practical Guide to the Most Popular Agile Process . Addison-
Wesley Signature, 2012. :
Shalloway, A.; Guy Beaver, G.; Trott, J. R. Lean-Agile Software Development. London:
Pearson; 2010. :
Smith, G.; Sidky, A. Becoming Agile in an imperfect world. Manning; 2009. :
Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time . Random House
Business; 2015. :
Sutherland, J.; Coplein, J. O. A Scrum Book. The Spirit of the Game . Pragmatic Bookshelf;
2019. :
Whitaer, K. Principles of Software Development Ledership: Applying Project Management
Principles to Agile Software Development. Centage Learning; 2009 :
Wysocki, R. Effective Project Management. Traditional, Agile. Extreme, Hybrid. Ed. Wiley;
2019. :
Glosario.
Contenedor temporal: Un contenedor temporal de una duración máxima, potencialmente fija. En

Scrum todos los eventos tienen únicamente una máxima duración máxima asignada, excepto el propio
sprint, que tiene una duración fija.
Daily Scrum: Un evento diario, limitado a 15 minutos o menos, para replanificar el trabajo de
desarrollo restante durante el sprint. El evento sirve para que el development team comparta el avance
diario, planifique el trabajo para las próximas 24 horas y actualice consecuentemente el sprint backlog.
Definición de hecho (definition of done —DoD—): Conjunto de expectativas y cualidades que

debe satisfacer un producto para que pueda liberarse a producción.
100/104
Desarrollo ágil: Se fundamenta en ritmos de planificación y ejecución interdependientes. Es

conceptualmente simple, pero requiere un trabajo relativamente complejo al implementarlo en cada
organización hasta institucionalizar la serie de reuniones, prácticas y momentos de entrega que permite
en cada caso encontrar su propio ritmo ágil.
Development team: Grupo de personas responsables de todo el trabajo de desarrollo evolutivo

necesario para crear un incremento liberable del producto no más tarde del final del sprint.
Emergencia: El proceso de pasar a existir o la importancia de hechos imprevistos o el conocimiento

de un hecho previamente desconocido, o el conocimiento de un hecho que se hace visible de manera
inesperada.
Empirismo: Tipo de control de procesos en el que las decisiones se basan en resultados observados,
la experiencia y la experimentación. El empirismo implementa ciclos periódicos de inspección y
adaptación, que requieren y crean transparencia. También conocido como “control de procesos
empírico”.
Estándares de desarrollo: El conjunto de estándares y prácticas que el development team identifica

como necesarios para crear un incremento liberable del producto no más tarde del final del sprint.
Gráfico burn-down: Gráfico que muestra cómo se decrementa el trabajo pendiente durante el
tiempo.
Gráfico burn-up: Gráfico que muestra cómo se incrementa una variable, por ejemplo, valor, durante
el tiempo.
Historia de usuario: Descripción de un requisito del sistema, escrito por el product owner en pocas
líneas, con lenguaje habitual en el entorno del cliente. Las características de implementación habituales
son las siguientes:
Longitud limitada, se puede escribir en una tarjeta o nota adhesiva.

Ampliación para las historias que necesitan información adicional, como textos literales que se
deben integrar en el software, reglas de negocio detalladas, etc.
Criterio o pruebas de validación, inclusión en cada historia del criterio de validación que
empleará el cliente para considerarla terminada.
Entre sus principales beneficios se encuentran los siguientes:
Permite que el equipo tenga una relación cercana con el cliente. Son muy fáciles de mantener.
Facilita la división del proyecto en entregas.
Facilita la estimación del esfuerzo necesario para llevarlas a cabo.
101/104
Impedimento: Un obstáculo o impedimento que bloquea o retrasa al development team y que no

puede resolverse a través de la autoorganización de este. Se plantea antes de finalizar el daily Scrum, y
el Scrum master es el responsable de su eliminación.
Incremento: Un estado del producto potencialmente liberable sobre la base de los incrementos
creados previamente y que, como un conjunto, forman el producto.
Longitud del sprint: El contenedor temporal del sprint, que es de cuatro semanas o menos.
Manifiesto Ágil: Valoramos:
A los individuos y su interacción, por encima de los procesos y las herramientas.

El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, son más valorados los de la izquierda. Fue firmado
por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert
C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.
Meta del sprint: Una frase concisa que expresa el objetivo general de un sprint.
MoSCoW: Criterio empleado para determinar la prioridad de los requisitos (funcionalidades, épicas o
historias de usuario). El enfoque MoSCoW es originario de la metodología DSDM y su nombre está
formado por las iniciales de los cuatro criterios de prioridad que recomiendan (en inglés):
Must have (es necesario).

Should have (es recomendable).
Could have (podría implementarse).
Won’t have (no lo queremos..., quizá en un futuro).
Parte interesada (stakeholder): Una persona externa al Scrum team con un interés en el producto o
un conocimiento de este necesario para la evolución incremental futura del producto.
Predicción: La anticipación de una tendencia futura basada en las observaciones del pasado, como la
parte del product backlog que las personas creen que pueden entregar en un sprint o en futuros
sprints a partir de lo entregado en sprints anteriores.
102/104
Product backlog: Una lista ordenada y cambiante de todo el trabajo que el product owner considera
necesario para crear, mantener y sostener un producto.
Product owner: La persona responsable de optimizar el valor que entrega un producto al expresar y
gestionar incrementalmente todas las expectativas e ideas en un product backlog; el representante
único de todas las partes interesadas.
Producto: Cualquier bien o servicio, tangible o no, consistente en una combinación cohesiva de
características y funciones que proporcionen un valor de extremo a extremo (inicio a fin) en la
solución de un problema específico para los usuarios de dicho producto. Se referencia desde los
términos product owner, product backlog e incremento.
Refinamiento del product backlog: La actividad recurrente dentro de un sprint por la cual el
propietario de producto y el development team añaden granularidad al futuro product backlog.
Scrum (n): Marco de trabajo simple para la entrega de productos complejos (1); marco de trabajo
simple para la gestión de desafíos complejos (2).
Scrum master: Persona responsable de fomentar un entorno basado en Scrum a través de la guía,
entrenamiento, formación y facilitación de uno o más equipos Scrum y sus entornos en el
entendimiento y uso de Scrum.
Scrum team: La combinación de responsabilidades del product owner, el development team y el

Scrum master.
Sprint: Un evento que sirve como contenedor para los demás eventos de Scrum, limitado a cuatro
semanas o menos. El evento permite realizar una cantidad suficiente de trabajo sobre el producto, a la
vez que asegura la inspección, reflexión y adaptación oportunas del producto a nivel estratégico. El
resto de eventos de Scrum son el sprint planning, el Daily Scrum, la sprint review y la sprint
retrospective.
Sprint backlog: Plan evolutivo del trabajo que el development team considera necesario para realizar
la meta del sprint.
Sprint planning: Evento que marca el inicio del sprint, limitado a ocho horas o menos. El evento
sirve al Scrum team para inspeccionar el product backlog considerado más valioso en ese momento y
predecir qué se podrá entregar en el sprint en forma de un backlog de sprint inicial y una meta general
para el sprint.
103/104
Sprint retrospective: evento que marca el cierre de un sprint, limitado a tres horas o menos. El
evento sirve para que el Scrum team inspeccione el sprint que está acabando y establezca la manera
en que trabajará en el siguiente sprint.
Sprint review: Evento que marca el cierre del desarrollo de un sprint, limitado a cuatro horas o
menos. El evento sirve para que el Scrum team y las partes interesadas inspeccionen el incremento, el
avance general y los cambios estratégicos, de manera que permitan al product owner la actualización
del product backlog.
Valores de Scrum: conjunto de cinco valores y cualidades fundamentales que dan soporte al marco
de trabajo Scrum: compromiso, foco, franqueza, respeto y coraje.
Velocidad: indicador popular de la cantidad media del product backlog que se ha convertido en un
incremento entregable de producto durante un sprint por un equipo. La velocidad sirve principalmente
como ayuda al development team, parte del Scrum team, para predecir futuros sprints .
104/104

Manual C13936 196 1667465258

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual C13936 196 1667465258

Cargado por

Copyright:

Formatos disponibles

Introducción a las metodologías ágiles © IMF

Introducción a las metodologías ágiles

Los principios y valores fundamentales del pensamiento Lean y Agile.

Conocer los principales marcos de trabajo y metodologías de Agile.

Conocer cómo influir en el equipo de proyecto y en el resto de la organización compartiendo los

III. Introducción a las metodologías ágiles

IV. Principales metodologías y marcos

4.1. Design thinking

Las principales características de esta metodología son las siguientes:

Figura 1. Design thinking

Figura 1. Design thinking.

4.1.1. El proceso de diseño

El proceso de design thinking se divide en cinco etapas: empatía, definición de la solución,

Figura 2. Design thinking.

La figura del facilitador

La personalidad y estilo del facilitador

El estilo y personalidad del facilitador y el tipo de proyecto en el que se aplique la metodología de

Figura 3. Design thinking, fases.

4.1.2. Fases de design thinking

Pasar la solución a producción. El feedback es muy positivo y se puede implementar la solución o

4.1.3. ¿Cómo impulsar design thinking en una organización?

4.2. Pensamiento Lean

Con anterioridad a las metodologías de desarrollo de sistemas anteriormente descritas, en el mundo de la

Rechazando el estado actual de las cosas.

Subordinar, clasificar o descartar.

Según se ha realizado en el paso anterior se ordenarán los elementos, nombrándolos correctamente

Simplificar, estandarizar y volver coherente.

Sostener, disciplinar el proceso.

Definir el final a entregar.

Trazar la corriente de valor.

Establecer el flujo de la entrega.

Diferir las decisiones (trabajar pull).

Estandarizar la perfección (aplicar las 5S).

Optimizar el conjunto (reducir las 7 mudas).

La figura 4 sirve de esquema visual de los siete principios de la filosofía Lean:

Figura 4. Siete Principios de la filosofía Lean.

Figura 5. Historia de Agile

Figura 5. Historia de Agile.

Figura 6. The Agile Pyramid – Values, Principles and Methods

Figura 6. The Agile Pyramid – Values, Principles and Methods.

4.3.1. Extreme programming (XP) o programación extrema

En el enfoque de la XP hay distintos roles: cliente, desarrollador, rastreador y entrenador. Prescribe

4.3.2. Crystal methods o métodos Crystal

4.3.3. Dynamic systems development methods (DSDM) o métodos dinámicos

4.3.4. Feature driven development (FDD) o desarrollo basado en

El FDD define seis roles principales:

Director del proyecto.

Gestor del desarrollo.

Expertos de dominio, aunados a una serie de funciones complementarias.

4.3.5. Test driven development (TDD) o desarrollo guiado por pruebas

4.3.6. Adaptive software development (ASD) o desarrollo adaptativo de

El desarrollo adaptativo de software (ASD) es un método para acelerar el diseño y la programación de

4.3.7. Domain driven design (DDD) o diseño guiado por dominios

4.3.8. Agile unified process (AUP) o proceso unificado ágil

El AUP trabaja con cuatro fases: incepción, elaboración, construcción y transición.

Figura 8. Simple Kanban Board.

Visualizar el flujo de trabajo

Eliminar las interrupciones

La idea de implementar un sistema Kanban es crear un flujo continuo e ininterrumpido de trabajos. El

Fomentar la visibilidad de los trabajos

Sincronizar mediante retroalimentación

Mejora mediante colaboración