Ágil

Forma de pensar y actuar

Gestión ágil

La gestión ágil es una serie de técnicas ligeras, eficaces y centradas en las personas,
basado en el Agilismo. Esto implica reconocer que no hay tal cosa como un proceso o
metodología para gestionar proyectos sino más bien que los procesos y metodologías
deben adaptarse a la naturaleza de cada proyecto

La agilidad en Gestión de proyectos

Desde la perspectiva de gestión de proyectos, “Agilidad es la habilidad de crear y responder

a cambios con el fin de obtener beneficios en un ambiente turbulento de negocios”. Con los
objetivos de negocio de: innovación continua, adaptabilidad del valor futuro, mejorar el
tiempo de entrega, adaptabilidad de personas y procesos y resultados confiables.

Metodologías tradicionales

Buscan imponer disciplina al proceso de desarrollo de software y de esa forma volverlo

predecible, eficiente y con énfasis en planeación. El principal problema de este enfoque es
que hay muchas actividades que hacer para seguir la metodología y esto retrasa la etapa de
desarrollo

Metodologías ágiles

Son adaptativas y orientadas a las personas.

Se gestaron como alternativa a las metodologías tradicionales, específicamente para reducir

la carga burocrática propia ellas, en proyectos de pequeña y mediana escala.

Los proyectos ágiles se subdividen en proyectos más pequeños mediante una lista
ordenada de características. Cada proyecto es tratado de manera independiente y
desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre
dos y seis semanas.

En 2001 se crea el Manifiesto por el desarrollo ágil de software, documento en el que se

acuerdan cuatro principios básicos para el desarrollo de software, que establece prioridades
y marca diferencias de fondo frente a los sistemas tradicionales: individuos e interacciones,
por encima de procesos y herramientas; software funcionando, por encima de
documentación extensiva; colaboración con el cliente, por encima de negociación
contractual; y respuesta ante el cambio, por encima de seguir un plan.

Los principios que dan origen al manifiesto implican la satisfacción del cliente mediante
entregas tempranas y continuas de software que funcione; requerimientos cambiantes en
cualquier etapa del proyecto; participación activa del cliente; simplicidad; equipos de
desarrollo motivados y auto-organizados; comunicación efectiva; auto inspecciones; y
adaptación.
El reconocimiento de la necesidad −y la expresión− de un lineamiento común capaz de
hacer posible algún tipo de agrupación entre ellas.

XP: fue desarrollada por Ron Jeffries y Kent Beck. Está enfocado en el desarrollo de
software y, contrario a lo que se podría esperar, su base no es técnica sino humana. Sus
prácticas están organizadas en tres capas: La capa externa tiene que ver con las
actividades de contacto con el mundo exterior. La capa interna tiene que ver con las
actividades técnicas y la capa intermedia tiene que ver con prácticas que interconectan las
otras dos.

DSDM -Dynamic Systems Development Method- es un marco de trabajo creado para

entregar la solución correcta en el momento correcto. Utiliza un ciclo de vida iterativo,
fragmenta el proyecto en periodos cortos de tiempo y define entregables para cada uno de
estos periodos. Tiene roles claramente definidos y especifica su trabajo dentro de periodos
de tiempo.

ASD -Adaptative Software Development- tiene como fundamento la teoría de sistemas

adaptativos complejos. Por ello, interpreta los proyectos de software como sistemas
adaptativos complejos compuestos por agentes −los interesados−, entornos
−organizacional, tecnológico− y salidas −el producto desarrollado−.

La familia de metodologías Crystal se basa en los conceptos de Rational Unified Process

[RUP] y está compuesta por Crystal Clear, Crystal Yellow, Crystal Orange y Crystal Red. La
filosofía de Crystal define el desarrollo como un juego cooperativo de invención y
comunicación cuya meta principal es entregar software útil, que funcione, y su objetivo
secundario, preparar el próximo juego. Existen dos reglas que aplican para toda la familia
Crystal. La primera indica que los ciclos donde se crean los incrementos no deben exceder
cuatro meses; la segunda, que es necesario realizar un taller de reflexión después de cada
entrega para afinar la metodología.

FDD - Feature-Driven Development- tiene como rasgo característico la planeación y el

diseño por adelantado. En consecuencia, el modelo de objetos, la lista de características y
la planeación se hacen al inicio del proyecto. Las iteraciones son incrementos con
características identificadas. FDD se enfoca en las fases de diseño –diseño por
característica– y desarrollo –construcción por característica– siendo estas las etapas del
proceso que se iteran.

Escalado ágil: SAFe (Scaled Agile Framework) es la estructura ágil de escala más popular,
es una estructura desarrollada por Dean Leffingwell para aplicar ágil y lean. SAFe es para
empresas grandes y proyectos grandes. consiste en cuatro capas, desde nivel estratégico
(portafolio) a táctico (solución grande) y operativo (programa y equipo). Nótese también la
integración de estructuras y metodologías lean-agile (Kanban, Scrum, XP).

LESS La segunda estructura más utilizada para el escalado ágil. Fue desarrollada por Bas
Vodde y Craig Larman. Es más ligero que SAFe, LESS está centrado en Scrum. Consiste
en una serie de principios donde persigue simplificar lo que genera sobrecarga al escalar
naturalmente. Promueve lograr más con menos tal que la simplicidad persista, más esfuerzo
se enfoque en genera valor y no en coordinar, reducir segregación, mantener el proceso
simple, incrementar flexibilidad y reducir inventario.
Niveles de vuelo: originado en Kanban, sin embargo, su carácter agnóstico permite verlo
independientemente del contexto de Kanban. 4 niveles: Unidad organzacional con entrada
no coordinada, Unidad organizacional con entrada coordinada, Flujo de valor y Portafolio.

El primer nivel se enfoca en un núcleo (equipo) de manera hermética donde la mejora es

interna. En el nivel dos el equipo influye en sus interfaces no solo a nivel de lo que reciben y
entregan sino en la forma en la que esas interfaces operan dentro de ese contexto. En el
nivel tres se mejora toda la cadena de valor relacionada con ese equipo o proceso. El cuarto
nivel es, una vez que la cadena de valor ya opera bajo lean y Kanban, extender la
experiencia al resto de las cadenas de valor de la organización.

ESTUDIO DE AGILIDAD: Industrias que apuestan por agilidad: el sector financiero y las
telecomunicaciones. Razones para adoptar agilidad. BENEFICIOS CLAROS Y MEDIBLES:
LA MAYOR VENTAJA. ÁREAS QUE HAN ADOPTADO LA FILOSOFÍA AGILE. MARCOS
DE ESCALADO ÁGIL USADOS.

Scrum es una estructura para la gestión de desarrollo de software que reemplaza la gestión
existente en la organización. Su origen, sin embargo, viene del artículo de Hirotaka Takeuchi
e Ikujiro Nonaka titulado “The new new product development game” (1986). Scrum tiene: 3
roles 5 eventos 3 artefactos.

Product Owner • Responsable de maximizar el valor del producto. • Gestión de la cartera de

productos. • Requisitos Definidos. • Priorización. • Comprensión compartida, valor y
visibilidad.

Scrum Master • Asegura que Scrum se utiliza correctamente. • Líder de servicio. • Eliminar
los impedimentos. • Facilitar eventos. • Entrenar al equipo. • Asiste al propietario del
producto con el backlog de Producto.

Equipo de Desarrollo • Genere los incrementos del producto. • Autoorganización •

Multifuncional (reúne todas las competencias necesarias para el desarrollo del product). •
No más de 7-8 personas.

EVENTOS:

Planificación de la entrega. • El alcance completo • Backlog de producto priorizado •

Determinar la duración del sprint.

Planificación del Sprint • Lo que entregamos en ese Sprint. • El equipo de desarrollo

pronostica lo que se puede entregar (estimaciones, capacidad, velocidad) Dos partes:
Estratégico + Táctico. • Al final, el equipo sabrá lo que tiene que construir y cómo.

Scrum diario • Timeboxed: 15 min • Mismo tiempo, mismo lugar. • Equipo de desarrollo +
SM • ¿Qué se ha logrado desde la última reunión? • ¿Qué se hará antes de la próxima
reunión? • ¿Qué obstáculos hay en el camino?

Revisión del Sprint • Al final de Sprint. • Inspecciona el incremento del producto. •

Demuestra el trabajo que se ha hecho. • Todo el equipo. • El Product Owner Rechaza o
Aceptar. • Determina qué hacer a continuación.
Retrospectiva del Sprint • Después de la Revisión del Sprint. • Todo el equipo participa en
una reunión que busca la mejora. • Lo que salió bien, lo bien mal, identificar las
oportunidades de mejora para implementar en el próximo sprint. • Timeboxed con un
facilitador de la reunión.

ARTEFACTOS:

Backlog del Producto (Lista de trabajo ordenada por prioridades para el equipo de
desarrollo)

Backlog del Sprint

Definición de Hecho • Un conjunto de políticas acordadas para determinar si una tarea

puede pasar de un estado del proceso a otro • Establece un entendimiento común. • Es una
forma de comunicarse

Scrum define un evento principal o Sprint (figura 1) que corresponde a una ventana de
tiempo donde se crea una versión utilizable del producto (incremento). Cada Sprint, como
en el rugby, es considerado como un proyecto independiente. Su duración máxima es de un
mes. Un Sprint se compone de los siguientes elementos: reunión de planeación del Sprint,
Daily Scrum, trabajo de desarrollo, revisión del Sprint y retrospectiva del Sprint.

La historia de usuario es un elemento esencial en ágil en general y en Scrum

El alcance para generar el backlog tiene el formato de Historia de Usuario:

La historia de usuario tiene un formato predeterminado que elimina ambigüedad y a partir

del cual las actividades de planificación, comunicación y seguimiento emergen. En la parte
trasera de la tarjeta se especifican los criterios de aceptación.

KANBAN

Kanban es un método para mejorar lo que tenemos, enfocado en la mejora continua de la

organización mediante la mejora de flujo de valor con énfasis en su economía.

El método Kanban se inició en el año 2004 y consiste en seis prácticas.

· La alta visualización: La alta visualización incrementa el entendimiento.

· Limitar la cantidad del WIP (work in progress) mejora la economía del sistema.

· Mejorar colaboradoramente y evolucionar experimentalmente, uso de modelos y el

método científico.

· Gestionar el flujo incrementa la satisfacción del cliente.

· Hacer los procesos explícitos.

· Implementar ciclos de retroalimentación

Con gestión con KANBAN

Considerar siempre el aspecto humano:

Es importante que el tablero de Kanban refleje la realidad del proceso. Puede adoptar
cualquier forma:

Con Kanban logramos previsibilidad: es posible identificar cuellos de botella aún antes de
que sucedan.

DESIGN THINKING:

Es un modo de pensar centrado en las personas y que ha dado origen a un método

quepermite resolver problemas a partir de las necesidades de los usuarios.

Sus ámbitos de aplicación incluyen:desarrollo de productos, servicios, políticas

públicas,intervenciones urbanas, diseño organizacional, manejo de comunidades,
planificación estratégica, entre otros.

Empatía es ponerse en el lugar del otro: ver con su ojos, sentir con su corazón y su
experimentar con sus sentido. La empatía se logra como el resultado de una paciente
observación, de vivir la experiencia sujeta a ser rediseñada, como si fuese nuestra primera
vez(viviéndola), dando cuenta de su contexto y entorno real, y con entrevistas en
profundidad. Observar, Involúcrate, Lo importante es siempre preguntar “¿Por qué?”, Mira y
Escucha, Pídele

Empatizar requiere de preparación y planificación.

Definir: lo siguiente que vamos a plantear es cuál es el problema, La definición del problema
toma la forma de la redacción de una frase, una construcción gramatica, llamada “Punto de
vista” (POV), cuyos elementos son: Usuario + Necesidad + Hallazgo. El POV se establece
de común acuerdo con el equiponde trabajo y se convierte así en el “problemas” accionable
sobre el cual continuará el proceso.

Idear: ahora toca Imaginar posibles soluciones. Ideación es pensar en mil y un soluciones.
La creación de múltiples ideas permite atacar distintos focos: · Pensar sobre soluciones que
son obvias y por lo tanto aumenta el potencial de innovación del set de posibilidades ·
Aprovechar de mejor manera las distintas visiones de cada equipo de trabajo y el trabajo
colectivo · Descubrir áreas inesperadas de exploración creando mayor volumen y mayores
opciones para innovar.

Prototipar: haremos físicas las ideas. Prototipar es hacer físicas las ideas. Los prototipos
pueden ser actuaciones, sketches, 3d, bocetos, ilustraciones… La única regla es consumir
la menor cantidad de recursos y tiempo, de modo que se pueda ver testear las soluciones
que han surgido en la etapa de ideación, lo antes posible.

Formas de hacer prototipos: · Empieza construyendo: Aun cuando no sepas lo que estás
haciendo, el solo acto de recoger un material será suficiente para empezar a andar. · No le
dediques demasiado tiempo a un prototipo: Déjalo ir antes de que te involucres demasiado
emocionalmente. · Identifica las variables: Cada prototipo debe ir respondiendo preguntas
cuando se esté evaluando. · Se debe estar atento a las respuestas de la interacción del
objeto con el usuario. · Trabaja los prototipos con un usuario en la mente: pregúntate ¿Que
esperar evaluar con el usuario? ¿Qué tipo de comportamientos esperas? El contestar estas
preguntas ayuda a tener un punto de vista único sobre la percepción que se va a tener del
diseño que están comenzando.

Testear: Más tarde comprobaremos cómo es la interacción usuario / productos o servicio.

Testear es abrir la conversación en base a prototipos, para extraer información de las
necesidades de los usuarios y de cómo los conceptos generados las satisfacen o no.
Testear es en simple, empatizar pero en base a un “excusa”: El prototipo.

TÉCNICAS:

Herramienta 1: ¿Qué, cómo y por qué? “Qué Cómo y Por qué” son herramientas que
pueden ayudarte a llegar a niveles de observación más pro- fundos. Estas preguntas te
ayudan a moverte desde observaciones concretas de una situación en particular a
emociones más abstractas y a otras motivaciones que están en juego en esa situación.

Herramienta 2: Preparación para la entrevista El tiempo que pasamos con los usuarios es
preciado y necesitamos sacarle el mayor provecho posible.

Herramienta 3: Entrevistar para empatizar Lo que quieres es entender los pensamientos,

emociones y motivaciones de la persona para determinar cómo innovar para él o ella.

Herramienta 4: Comparte y documenta historias.

Herramienta 5: Saturar y agrupar Este método se utiliza para traducir pensamientos y

experiencias a piezas visuales tangibles que ayudarán a informar e inspirar al equipo de
trabajo. Satura el espacio de trabajo que tengas con post-its llenos de temas y conceptos
claves. Se agrupan los conceptos para explorar los temas y patrones que surjan y para
avanzar identificando necesidades significativas.

Herramienta 6: Mapa de empatía Un buen diseño se basa es un profundo entendimiento por

las personas de las cuales estamos diseñando. El mapa de empatía es una herramienta
que nos ayuda a sintetizar las observaciones y descubrir insights inesperados.

Mapa de trayectoria Este método se utiliza para ganar empatía por una persona o mejorar el
entendimiento del proceso por medio de una experiencia es preciso considerar los detalles
de ese proceso para iluminar áreas de potenciales insights. Crear un mapa de trayectoria es
una excelente forma para pensar sistemáticamente sobre los pasos e hitos del proceso.
Este método se puede utilizar para el trabajo de empatía individual o para comunicar y
compartir con los demás.

Herramienta 8: Personas Persona es una representación del usuario que nos revela
quienes son los usuarios, cuales son las actividades que realizan, por que
usan/compran/utilizan uno u otro producto o servicio; cuáles son sus motivaciones y como el
producto/servicio encaja en el contexto de sus vidas.

Herramienta 9: Definir el problema jugando Se define el problema para construir un marco

teórico basado en el desafío de diseño anteriormente trabajado que dará un puntapié inicial
para la generación de ideas.
Herramienta 10: Checklist de lectura crítica Esta herramienta se utiliza para determinar si el
equipo ha alcanzado una definición de problema que sea significativa y única.

Herramienta 11: Pregunta ¿Cómo podríamos? Preguntas “¿Cómo podríamos?” son

preguntas cortas que tienen la particularidad de empezar brianstorms. Estas preguntas se
desprenden de la definición del problema o principios de diseño como semillas para la etapa
de ideas. Genera una semilla lo suficientemente amplia para que haya una gran cantidad de
soluciones y lo suficientemente acotada o limitada para que el equipo tenga ciertos límites
que sean de ayuda.

Herramienta 12: Reglas del brainstorming El brainstorm es una manera excelente de

generar muchas ideas que de lo contrario no se generarían sentados mirando un pedazo de
papel.

Herramienta 13: Guiar el brainstorming El método de guiar y facilitar el trabajo es la clave

para que una labor de brainstorm sea generativa. Se hace esto para desarrollar una gran
cantidad de ideas relacionadas con variados temas.