Enfoque ágil de proyecto

Al finalizar esta unidad, conocerás los principios y valores del agilismo, y por qué este

enfoque es más apropiado y utilizado hoy en día para la gestión de proyectos. Conocerás las metodologías ágiles más utilizadas, y las diferencias básicas respecto de la gestión "tradicional" de proyectos.

Introducción al agilismo

Cuando un proyecto no tiene los requisitos claros, cuando el alcance no se puede definir con suficiente detalle para todo el proyecto, o cuando parece probable que se van a dar muchos cambios durante la ejecución del proyecto, se impone un enfoque ágil del mismo, en contraposición al enfoque tradicional...

¿Por qué existe el enfoque "ágil"?

Debemos plantearnos los mitos que existen respecto de la planificación, ejecución y finalmente el éxito o fracaso de múltiples proyectos.

Mito 1

El cliente, solicitante o patrocinador del proyecto sabe exactamente lo que quiere.

Mito 2

Los equipos de trabajo, construcción o desarrollo saben exactamente cómo diseñar, construir y entregar el resultado.

Mito 3

A lo largo del proyecto, y una vez aprobada la planificación, no habrá cambios durante la ejecución del proyecto, o estos tienden a ser mínimos.

A día de hoy, la gran mayoría de responsables de proyectos no estarán muy de acuerdo con estas premisas; entonces, ¿por qué seguir pensando en gestionar proyectos de forma que los cambios se eviten, o en todo caso se "gestionen"?

¿Por qué tanto esfuerzo en determinar un alcance antes de empezar a ejecutar el proyecto, perfectamente detallado y definido?

Entonces, ¿cuál es la realidad de los proyectos?

Realidad 1

El cliente, usuario o patrocinador no sabe realmente lo que quiere hasta que lo ve (IKIWISI: I Know It When I See It).

Realidad 2

Los equipos de trabajo, construcción o desarrollo van descubriendo la mejor forma de ejecutar el trabajo, cuando realmente lo están ejecutando, y pueden aplicar nuevas ideas y mejoras.

Realidad 3

A lo largo del proyecto, cambiarán muchas cosas para beneficio de todos: un avance tecnológico; una nueva competencia en el mercado; un cambio en el comportamiento de usuarios o clientes, etc. Hay que adaptarse a ella para garantizar el éxito del proyecto.

Debemos asumir que, generalmente, existirá incertidumbre; pero si vamos a ejecutar una obra pública, por ejemplo, con un año de duración del proyecto de construcción, ¿acaso sabemos al comienzo si dentro de 8 meses se dará un tifón o una tormenta que hará que los trabajos se detengan?

Por lo tanto, el enfoque ágil se abre camino como nuevo paradigma de éxito para la

gestión de proyectos: si podemos empezar a construir, empecemos cuanto antes.

Ese tipo de incertidumbres existirán, pero no podemos dejar que paralicen la toma de

decisiones. Si tenemos el conocimiento suficiente para planificar, ejecutar y finalizar con

éxito una etapa del proyecto, ¿por qué no llevarlo a cabo, si el producto de dicha etapa

aporta valor?

Éste es el sentido del enfoque ágil de gestión: buscar una entrega temprana del valor de

negocio.

Entrega dirigida por el valor de negocio

Se trata, en esencia, de proporcionar valor de negocio lo antes posible; esto es lo contrario al concepto
"big bang", donde el producto o resultado del proyecto sólo puede ser aprovechado al final del mismo.

Ejemplo: Valor de Negocio

Pensemos en una empresa que quiere montar un portal web de venta de sus productos

online, y se pone en marcha un proyecto con ese objetivo. Si bien el objetivo completo es claro, para conseguirlo es necesario montar un portal web, que incluya el catálogo de productos, que tenga alguna funcionalidad del tipo "carrito de la compra", que permita conexión con una pasarela de pago para poder cerrar la compra, y además un acuerdo con algún partner de transportes que envíe los productos al cliente final.

¿Pero es necesario esperar a tener todo eso para poder generar valor de negocio?

Supongamos que se ha estimado que es necesario 1 año para disponer de esa plataforma completa. Y supongamos que, a los dos meses, se podría tener una plataforma que

solamente incluya el catálogo de productos, pero aún no se pueden comprar.

¿Por qué no empezar a explotar ya ese resultado parcial del proyecto? ¿No sería positivo

que nuestros potenciales clientes sepan que van a poder comprar online? ¿No sería

positivo que puedan conocer ya nuestros productos? ¿No sería positivo aprovechar este

corto plazo para, al menos, existir en un medio online? ¿no podríamos obtener

información valiosa (feedback) sobre si la página web suscita cierto interés o no?

Valores añadidos de la propuesta ágil

No sólo el valor de negocio llega antes gracias al enfoque ágil.

Visibilidad del producto final

¿Qué ocurre con la visibilidad del producto final? O lo que es lo mismo, la confianza que los interesados del proyecto pueden tener en el éxito del mismo.

Si, como en el ejemplo que hemos visto, se entregan partes o versiones del resultado final que son

aprovechables desde etapas tempranas, esta confianza irá en aumento; existen resultados "tangibles" que
se pueden utilizar, que pueden generar ROI, que pueden mejorar nuestra imagen o posición de marca.

Resultado tangible

Un resultado tangible convencerá más y mejor al patrocinador del proyecto (un catálogo online de sus productos) que una extensa documentación de análisis y diseño (hojas y hojas de papel que hablan de un portal online, que muestran un diseño gráfico, una propuesta de funcionalidad...).
Un producto tangible, aunque sea parcial, se puede probar, se puede validar y se puede utilizar mejor que extensas definiciones y diseños en papel.

Riesgo

Al mismo tiempo, el riesgo global disminuye desde etapas tempranas del proyecto: una entrega temprana
permite validar las versiones del producto final muy pronto; se evitan las "sorpresas" al final del
proyecto.

Adaptabilidad

Por el mismo motivo, la adaptabilidad es posible en un proyecto ágil; si optamos por el "enfoque

tradicional", y entregamos una única versión del producto al final del proyecto, ¿qué posibilidades

tenemos de ajustarlo o adaptarlo a alguna nueva necesidad o restricción, cuando el presupuesto ya está agotado y el plazo vencido?

Enfoque ágil vs Enfoque "tradicional"

Desde el punto de vista de gestión del proyecto y del trabajo, ¿qué novedades se introducen con el enfoque ágil respecto del tradicional?

Estilo de gestión no centralizado

El jefe de proyecto no "ordena" al resto del equipo de trabajo lo que debe hacer en cada momento; esa
figura de "jefe de proyecto" no es tal desde el punto de vista del "ordena y manda"; ahora, el estilo
dirección del proyecto se basa en el coaching y en servir de facilitador al resto del equipo de trabajo.

Se promueve el cambio

Los cambios se aceptan, y el proyecto se adapta a ellos: si los cambios sirven para responder a cambios
en el mercado y hacer del proyecto un éxito, no deben evitarse sino promoverse y adaptar la evolución
del proyecto para poder aceptar estos cambios de forma controlada y dirigida al valor final de negocio
del resultado.

Las personas en el centro

El proyecto gira en torno a las personas que lo ejecutan, no sólo en torno a los procesos de gestión; lo
más importante es el aporte intelectual de los expertos, los científicos, los arquitectos, los
desarrolladores, el equipo de pruebas... el conocimiento y experiencia de estas personas aportarán más
valor al proyecto, que la mera ejecución paso a paso de cierta metodología o proceso estricto.

Iterativo e incremental

Trabajo en base a iteraciones breves: no se trata de ejecutar un proyecto de un año con una sola entrega final. Es preferible pensar en ejecutar 12 "pequeños" proyectos de 1 mes cada uno; en cada mes se tendrá un resultado parcial que mejora el resultado anterior, que aporta valor añadido.

Retorno de inversión temprano

ROI en fases tempranas: se espera que los resultados parciales generados en cada iteración generen valor económico, es decir, el ROI no llega sólo al final del proyecto.

Pocas personas en el equipo

Equipos de trabajo pequeños: como mejor se aprovecha el pensamiento ágil es en equipos de personas pequeños, quizá no más de 15 personas, aunque esto es muy variable.

¿Quiere esto decir que no se pueden ejecutar proyectos grandes con un enfoque ágil?

Al contrario: si son necesarias 500 personas, se integrará el trabajo de 50 equipos de 10 personas (por ejemplo), cada uno con un enfoque ágil en su ejecución del trabajo.

Menor Riesgo

Puesto que se hacen entregas desde etapas iniciales del proyecto, y estas son continuas durante todo el proyecto, el destinatario del resultado es consciente del avance y los resultados parciales, con lo que se disminuye el riesgo del "big bang", donde se entrega mucho resultado de una sola vez, y éste puede no ser aceptado.

Cambio en la Triple Restricción

Enfoque Tradicional

Típicamente pensamos en la "triple restricción" de los proyectos tradicionales como una serie de requisitos fijos, que son los que determinan el presupuesto y el plazo del proyecto. Por eso se lleva a cabo una planificación detallada al comienzo: para calcular, en base al alcance definido, cuándo se entregará y con qué costes.

Enfoque Ágil

Ahora bien, en un proyecto ágil, lo que prima por encima de todo es el tiempo disponible y el presupuesto permitido. El alcance se definirá de forma completa conforme avanza el proyecto.

Es un cambio de mentalidad, un ejercicio intelectual de plantearse el proyecto como una generación de valor temprana y continua. A lo largo del tiempo, se van a consumir recursos para proporcionar el valor óptimo en cada etapa (iteración) del proyecto.

Otros principios básicos de la gestión ágil de proyectos

Veamos más ideas troncales del enfoque ágil de gestión y ejecución de proyectos.

Esfuerzo de planificación no concentrado al inicio

El esfuerzo de planificación no se concentra al inicio del proyecto, sino que se distribuye a lo largo del mismo.

Cada iteración es planificada justo antes de su comienzo, así pueden incluirse los cambios que haya surgido recientemente, sin impactar negativamente en el resultado del proyecto; al contrario, aportando valor al mismo (los cambios se adoptan).

Requerimientos definidos sólo a nivel suficiente

Los requerimientos deben estar claros, sí, pero sólo lo suficiente para empezar a trabajar; en el ejemplo del desarrollo de una página web, ¿merece la pena invertir demasiado tiempo en especificar cada detalle de la página web para venta online?

¿Y si empezamos haciendo, y mostrando, una página básica que sirva de prototipo sobre el que ir creciendo?

Colaboración con negocio

Es necesario colaborar directamente con negocio, es decir con aquellas personas que recibirán el producto, o que conocen el objetivo del producto final.

Estas personas deben dirigir las decisiones en cuanto a qué hacer y qué no (no a cómo hacerlo, esta decisión corresponde a los técnicos expertos).

El valor del producto final se mide siempre en términos de negocio, en consecuencia, es negocio quien decide (negocio es el "dueño" del resultado del proyecto).

Evitar el Síndrome del Estudiante

Se evita el "síndrome del estudiante", es decir, dejar demasiado trabajo para el último día antes de la

entrega final; en un enfoque ágil, esta "entrega final" no existe como tal, sino que el proyecto se resuelve en base a una serie de entregas incrementales, una en cada iteración.

Por lo tanto el ritmo de entregas es constante, no concentrado al final.

Evitar la Parálisis por Análisis

Se evita la "parálisis por análisis"; un riesgo típico en proyectos tradicionales es que no se arranca la ejecución del proyecto propiamente dicha, hasta que la especificación de los requerimientos tiene un gran nivel de detalle.

Ejemplo: Parálisis por Análisis

Si el proyecto tiene 4.000 requisitos y una duración de 2 años, ¿aporta realmente valor, en todos los casos, trabajar al inicio en los últimos 100 requisitos que se implementarán el último mes de proyecto, dentro de 23 meses?

¿no parece muy probable que haya cambios que obliguen a redefinir esos requisitos?

El sentido común dice que ahora, al inicio del proyecto, esta definición puede resultar

excesiva y es mejor dedicar más recursos a construir resultados (quick wins) que se

entreguen pronto.

Resumen de diferencias entre los enfoques Ágil y Tradicional

Énfasis

Paradigma ágil: En las personas.

Paradigma tradicional: En los procesos.

Documentación

Paradigma ágil: Sólo la necesaria.
Paradigma tradicional: Exhaustiva.

Estilo del proceso

Paradigma ágil: Iterativo.

Paradigma tradicional: Lineal.

Planificación al inicio del proyecto

Paradigma ágil: Limitada.

Paradigma tradicional: Completa.

Aseguramiento de la Calidad

Paradigma ágil: Centrado en el destinatario del producto. Paradigma tradicional: Centrada en el proceso.

Priorización de requerimientos

Paradigma ágil: Basada en el valor de negocio y adaptado con regularidad. Paradigma tradicional: Fijado en el plan de proyecto.

Organización del equipo de proyecto

Paradigma ágil: Auto-organizado.

Paradigma tradicional: Gestionado por el jefe de proyecto.

Estilo de gestión

Paradigma ágil: Descentralizado (en el equipo).

Paradigma tradicional: Centralizado (en el jefe de proyecto).

Cambios

Paradigma ágil: Se aceptan, adoptan y se adapta el proyecto. Paradigma tradicional: Sistema de gestión de cambios.

Liderazgo

Paradigma ágil: Colaborativo, liderazgo facilitador.

Paradigma tradicional: Ordena y manda (command and control).

Medición del rendimiento

Paradigma ágil: Según el valor de negocio.

Paradigma tradicional: Según el cumplimiento del Plan.

Retorno de Inversión

Paradigma ágil: Desde etapas tempranas, y a lo largo del ciclo de vida del proyecto. Paradigma tradicional: Al final del proyecto.

Manifiesto Ágil. Valores y Principios

El enfoque ágil de dirección y ejecución de proyectos se basa en 4 valores y 12 principios básicos muy simples, pero que suponen el corazón del paradigma ágil. Resulta fundamental comprenderlos a la hora de aplicar cualquier metodología ágil, y ayudan a entender por qué este estilo de gestión se está imponiendo actualmente frente a otros enfoques de gestión de proyectos.

4 Valores

1. Personas y sus interacciones sobre procesos y herramientas.

2. Productos entregables sobre documentación exhaustiva.

3. Colaboración de cliente y patrocinador, sobre negociación de contratos.

4. Responder a los cambios sobre seguir un plan.

12 Principios

1. Nuestra mayor prioridad es satisfacer al cliente, receptor o patrocinador del proyecto.

2. Demos la bienvenida a cambios en los requisitos.

3. Debemos realizar entregas de producto regularmente.

4. Las personas que conocen el negocio y el producto final, deben trabajar de forma colaborativa.

5. Construye proyectos alrededor de individuos motivados.

6. El método más efectivo y eficiente de transmitir información hacia el equipo de trabajo, y también entre los miembros del equipo, es la conversación cara a cara.

7. El producto entregado es la mejor medida del avance del proyecto.

8. El proceso ágil promueve una ejecución de proyecto sostenible.

9. La agilidad funciona mejor prestando atención continuamente a la calidad y la excelencia técnica.

10. La simplicidad es esencial: el arte de maximizar la cantidad de trabajo que puede ahorrarse.

11. Las mejores propuestas técnicas, diseños e ideas surgen de equipos auto-organizados y auto-gestionados.

12. De forma regular a lo largo del tiempo, el equipo de trabajo reflexiona sobre cómo ser más efectivo, y ajusta su método de trabajo para conseguirlo.

Los 4 valores fundamentales del enfoque ágil

Personas y sus interacciones sobre procesos y herramientas

No se trata de que no deban utilizarse procesos y herramientas; por supuesto que deben utilizarse y son necesarios; la cuestión es que debemos prestar una importante atención a lo que dicen las personas.

Si una persona propone un cambio en un proceso, una idea de mejora, debe escucharse y valorarse, no descartar la idea porque no forma parte del proceso estándar.

Y también, tener en cuenta que el trabajo en equipo fomenta las sinergias, es decir, 2 personas trabajando juntas generarán más del doble de nuevas ideas que el total que generan esas 2 personas trabajando por separado.

Productos entregables sobre documentación exhaustiva

Aporta más valor un producto que sólo ofrece una parte de su funcionalidad, que ningún producto pero mucha documentación de diseño sobre el mismo, por ejemplo; el producto mínimo tangible que puede generar ROI es más valorable que los meros documentos descriptivos.

Ejemplo: Resultados entregables

Quizá sea mejor disponer a corto plazo de una carretera de un solo carril, que invertir la misma cantidad de recursos en entregar el diseño de una autopista de 4 carriles... la documentación no permite que circule ningún vehículo (no soluciona un problema de los usuarios), pero un solo carril sí lo hace.

Posteriormente se irán añadiendo carriles adicionales.

Colaboración de cliente y patrocinador, sobre negociación de contratos

Los contratos deben existir, sin duda, son necesarios para que los compromisos firmados estén claros tanto por parte de quien compra el resultado de un proyecto como por quien va a construirlo.

Ahora bien, la cuestión es: ¿cómo se aporta valor real de negocio al producto final? ¿en una mesa de negociación de detalles económicos de un contrato, donde cada una de las partes trata de obtener el máximo beneficio para sí misma? ¿o en una colaboración constructiva por ambas partes, resolviendo los conflictos pensando en todo momento en el valor añadido que se puede conseguir con buenos acuerdos?

Se busca un ambiente colaborativo y constructivo, por encima de uno negociador y

agresivo.

Responder a los cambios sobre seguir un plan

Debemos dar a los cambios el valor que tienen.

¿Por qué un cliente o patrocinador de proyecto solicita un cambio sobre su petición inicial?

Esto no es un "ataque" contra quien está ejecutando el proyecto; al contrario, un cambio es una oportunidad para hacer el proyecto mejor, para conseguir un producto mejor; se puede estar respondiendo a un cambio en el mercado, o a un cambio legislativo de obligado cumplimiento, por ejemplo.

Entonces, el producto final aumentará de valor con la incorporación de estos cambios;

se trata de gestionar el proyecto de forma que el impacto de estos cambios sea positivo

en su conjunto.

Los 12 principios del Manifiesto Ágil

Nuestra mayor prioridad es satisfacer al cliente, receptor o patrocinador del proyecto

Nuestra mayor prioridad es satisfacer al cliente, receptor o patrocinador del proyecto, en base a entregarle desde etapas tempranas y de forma frecuente, versiones del producto final que aporten valor.

El objetivo no es sólo cumplir una planificación porque esto vaya a aportar valor en sí mismo, ni cumplir un presupuesto.

Aunque estas metas se consigan, no habrán servido de nada si el receptor del resultado del proyecto no queda satisfecho.

Demos la bienvenida a cambios en los requisitos

Demos la bienvenida a cambios en los requisitos, aunque sea en etapas avanzadas del proyecto. El proceso ágil recibe los cambios con los brazos abiertos, para beneficio y ventaja competitiva del cliente.

Los cambios tienen como objetivo mejorar el resultado del proyecto, por lo tanto, deben ser comprendidos y adoptados en la medida de lo posible.

Gracias a la planificación progresiva, iremos adaptando el proyecto para incorporar estos cambios a la construcción del producto final.

Debemos realizar entregas de producto regularmente

Debemos realizar entregas de producto regularmente, entre dos semanas y dos meses, pero preferiblemente en el período más corto posible.

Cuanto más corto sea el período entre entregas, mayor visibilidad del avance del proyecto existirá, y mayor valor utilizable desde etapas tempranas.

Esto también permite un feedback continuo que ayude a la mejora continua, que alimente nuevos

requisitos y ajuste la definición del producto final para conseguir el mayor valor de negocio posible.

Las personas que conocen el negocio y el producto final, deben trabajar de forma colaborativa

Las personas que conocen el negocio y el producto final, deben trabajar de forma colaborativa, y si es posible a diario, con los equipos de construcción.

Todas las decisiones que estén relacionadas con la definición del producto final, deben tomarlas las personas que conocen su finalidad, quién lo utilizará, y por qué se está construyendo.

El equipo de trabajo decide cómo se llevan a cabo los trabajos, la planificación detallada, y las herramientas.

Las decisiones de producto las toman los dueños del producto (los solicitantes del mismo).

Construye proyectos alrededor de individuos motivados

Construye proyectos alrededor de individuos motivados. Dales el soporte que necesiten y el mejor ambiente de trabajo posible. Confía en que ellos serán capaces de llevar a cabo el trabajo propuesto.

En un ambiente de trabajo ágil, el "jefe de proyecto" deja de considerarse como tal; esta figura debe ejercer de líder facilitador, eliminando barreras y quitando problemas al equipo de trabajo, preocupándose por proporcionarles aquello que necesiten para desempeñar a cabo su labor.

Ese equipo de trabajo motivado y apoyado por el facilitador conseguirá alcanzar los objetivos del proyecto.

El método más efectivo y eficiente de transmitir información es la conversación cara a cara

El método más efectivo y eficiente de transmitir información hacia el equipo de trabajo, y también entre los miembros del equipo, es la conversación cara a cara.

Está demostrado que la cantidad de información que se transmite en una conversación en persona, es mucho mayor que en email, conversación telefónica o a través de un documento.

Si bien estos medios de comunicación deben utilizarse (a menudo son imprescindibles cuando las personas no están juntas físicamente), debemos promover que los miembros del equipo de trabajo puedan compartir un mismo espacio y el mejor ambiente posible donde intercambiar información.

La "sala de guerra" es el escenario de trabajo ideal para un equipo de proyecto ágil.

El producto entregado es la mejor medida del avance del proyecto

El producto entregado es la mejor medida del avance del proyecto.

Aunque pueden utilizarse técnicas como el valor ganado o cualquier otra para presentar el avance de un proyecto, la evidencia más realista y objetiva del avance es el producto final entregado.

El producto final tangible o utilizable se puede validar y poner en explotación, puede generar ROI; los
documentos, las planificaciones y los informes de seguimiento no pueden generar valor de negocio por
sí mismos.

Una serie de documentos podrían resultar erróneos o inútiles, aunque no pueda comprobarse hasta etapas más avanzadas del proyecto; pero un producto tangible es susceptible de ser aceptado o rechazado y es un resultado real y medible de la situación actual del proyecto.

El proceso ágil promueve una ejecución de proyecto sostenible

El proceso ágil promueve una ejecución de proyecto sostenible. Los sponsors, el equipo de trabajo y los usuarios deben ser capaces de mantener un ritmo de trabajo constante a lo largo del tiempo.

Si el proyecto se prolongase indefinidamente, todos los participantes deberían ser capaces de continuar a la misma velocidad.

El concepto de "velocidad" es importante en el agilismo: significa la cantidad de resultados, producto o funcionalidad que se puede entregar de forma sostenible en cada período de tiempo (iteración).

La agilidad funciona mejor prestando atención continuamente a la calidad y la excelencia
técnica

La agilidad funciona mejor prestando atención continuamente a la calidad y la excelencia técnica.

Uno de los grandes enemigos de la agilidad es el retrabajo. Es decir, tener que "deshacer" algo que ya se consideraba terminado, validado, entregado y funcionando.

Aplicar recursos para conseguir un producto que no aporte más valor de negocio se considera un desperdicio, un no-aprovechamiento del coste incurrido; y esto ocurre cuando se cometen errores técnicos, fallos de cálculo, malos diseños técnicos o implementaciones defectuosas.

Por lo tanto, debe observarse la excelencia técnica en cada decisión de ejecución donde pueda aplicarse.

La simplicidad es esencial: el arte de maximizar la cantidad de trabajo que puede ahorrarse

En este sentido, podemos introducir el concepto de enfoque "Lean" del trabajo: no hacer aquello que no aporta un beneficio real.

No sólo hay que preguntarse ¿qué debemos hacer para conseguir el valor de negocio? Sino también, ¿puedo dejar de hacer cosas que no aportan valor real? ¿Puedo eliminar este "desperdicio"? ¿Puedo simplificar mis procesos, eliminar o simplificar actividades?

Aumentar la eficiencia significa que tendremos más recursos libres disponibles para construir valor real de negocio.

Las mejores propuestas técnicas, diseños e ideas surgen de equipos auto-organizados y auto- gestionados

En la filosofía ágil, el equipo de trabajo (llamado indistintamente "equipo de proyecto") es el eje central del proyecto; debemos crear el ambiente idóneo, y proporcionar los recursos adecuados, para que un equipo experto de construcción y desarrollo pueda dar rienda suelta a sus ideas creativas, a emplear su experiencia de la mejor forma posible, ajustar sus prácticas, técnicas y procesos de trabajo para el mejor beneficio del proyecto.

De forma regular a lo largo del tiempo, el equipo de trabajo reflexiona sobre cómo ser más
efectivo

De forma regular a lo largo del tiempo, el equipo de trabajo reflexiona sobre cómo ser más efectivo, y ajusta su método de trabajo para conseguirlo.

El equipo de trabajo auto-organizado debe enfocarse en la mejora continua de su propio trabajo: de

forma regular (por ejemplo, al final de cada iteración de trabajo, o después de cada entrega de producto intermedio) debe dedicar cierto tiempo a explorar posibilidades de mejora.

En algunas metodologías ágiles existen procesos formales para llevar a cabo estas reuniones de mejora continua, pero en definitiva se trata de reflexionar sobre:

• Qué se está haciendo bien,
• qué se puede hacer mejor,
• qué trabajos se están llevando a cabo que no aportan valor añadido,
• qué oportunidades de mejora existen en los procesos utilizados,
• etc...

Con este conjunto de reflexiones, se confecciona un plan de acción que aplique estas mejoras en las siguientes etapas del proyecto.

Metodologías Ágiles

Aunque existen otras, hay 4 metodologías ágiles que se utilizan muy habitualmente:

Scrum

  Método simple.

  Iterativo e incremental.

  5 valores.

  3 roles.

  3 artefactos.

  5 tipos de reunión.

XP

  13 prácticas de ingeniería.

  5 valores.

  4 actividades.

  4 roles.

Kanban

  1. Comenzar ahora con lo que hay que hacer.

  2. Poner como objetivo pequeños cambios incrementales.

  3. Cada miembro del equipo es un líder.

  4. Mejorar de forma continua y colaborativa.

  5. Todos los implicados ven el proceso claramente.

  6. Limitar el trabajo en curso.

  7. Hacer visible el trabajo.

  8. Visualizar el flujo de trabajo.

  9. Gestionar el flujo de trabajo.

Lean

  Un enfoque, más que una metodología. 

  Eliminar el desperdicio.

  Llevar la simplicidad al máximo.

Scrum

Scrum es un método para solventar problemas complejos, entregando productos que aporten el mayor valor posible.

Es una metodología:

Ligera

Scrum tiene poca teoría, únicamente define algunas reuniones o ceremonias, los roles, y unos pocos principios básicos. El contenido teórico se lee en menos de 5 minutos.

Fácil de entender

Es una metodología abierta, que no propone reglas complicadas ni demasiado específicas en función del proyecto.

Difícil de dominar

La clave es adaptarla correctamente al entorno y al proyecto concreto. Por eso está definido el rol de Scrum Master, que es la figura que domina el método y ayuda a su aplicación y ajuste.

Está basada en procesos empíricos de control, es decir, el conocimiento viene de la experiencia, y se toman decisiones en función de la información que se tiene.

Su enfoque es iterativo e incremental.

Iterativo

En cada sprint, se genera una nueva versión del producto, que mejora la versión del sprint anterior. Se trata de ir refinando y mejorando las propiedades del producto conforme avanza el proyecto.

Incremental

En cada sprint, se añade alguna nueva característica al producto. Se trata de ir añadiendo nuevas capacidades o características al producto conforma avanza el proyecto.

Elementos de Scrum

Sprints

El producto se construye de forma incremental en base a períodos de tiempo cortos, denominados Sprints.

Los Sprints tienen una duración fija y determinada, entre 1 y 4 semanas; mejor cuanto más cortas, es decir mejor 1 semana que 4.

Todos los Sprints tienen la misma duración a lo largo del proyecto.

Definición de Hecho

El equipo de trabajo tiene que encontrar una definición para el concepto de "hecho" -Done-. Cada incremento del producto debe cumplir dicha definición de "hecho" para darlo por finalizado, y poder ser entregado.

La definición de "hecho" puede aplicar a requisitos, sprints, releases, entornos... es decir, en cualquier elemento sobre el que se pueda plantear la cuestión de "¿está finalizado y puede continuar al paso siguiente del proyecto?

Ejemplo: "Hecho" para un requisito

Ejemplo de "Hecho" para un requisito (habitualmente denominadas "historias de usuario"):

* Todo el código escrito sin errores.

* Todas las pruebas unitarias pasadas correctamente.

* Pruebas funcionales pasadas con éxito.

* Documentación del requisito generada.

* Pruebas de aceptación pasadas con éxito.

Ejemplo: "Hecho" para un sprint

Ejemplo de "Hecho" para un Sprint:

* Pruebas de rendimiento pasadas con éxito. 

* Elementos resultantes del sprint integrados. 

* Todos los bugs resueltos.

* Pruebas de integración pasadas con éxito.

Ejemplo: "Hecho" para un despliegue

Ejemplo de "Hecho" para Despliegue en Producción:

* Pruebas de stress pasadas con éxito.

* Pruebas de seguridad validadas.

* Plan de marcha atrás definido.

* Entorno y servicio estable.

Ciclo de Scrum

El proyecto se ejecuta en base a sprints, de duración fija, que se planifican al arrancar cada sprint, con las Daily cada 24 horas.

En cada sprint se resuelve o construye el Sprint backlog, que se integra al final del sprint con el resultado de sprints anteriores, conformando un producto entregable.

Productos

También denominados "artefactos":

- Incremento de producto: un subconjunto del producto que puede ser entregado, con componentes integrados, que funciona.

- Backlog de producto: la lista de requisitos del producto, ordenadas por su prioridad.
- Backlog del Sprint: el plan detallado para el desarrollo durante el sprint siguiente.

Pilares básicos

Transparencia: los interesados comparten un entendimiento común del proyecto, de la visión, y de lo que significa "hecho"

Inspección: a través de los artefactos o entregables (incremento de producto, backlog de producto y backlog del sprint).

Adaptación: a través de las reuniones en Scrum.

Valores

Personas enfocadas en el resultado. Motivación.

Transparencia.
Compromiso.
Respeto.

Reunión Daily Scrum

Reunión con un timebox de 15 minutos, donde el equipo de desarrollo sincroniza sus actividades y crea el plan para las siguientes 24 horas.

En esta reunión, cada miembro del equipo de trabajo debe responder a 3 preguntas:

- ¿Qué hice ayer?

- ¿Qué haré hoy?

- ¿Hay algún impedimento que me evite conseguir mis objetivos hasta mañana?

Reunión Sprint Review (también llamada "demo")

Reunión que se mantiene al final de cada Sprint para inspeccionar el Incremento de Producto, y adaptar el Backlog del producto si es necesario.

Durante el Sprint Review, el equipo de trabajo muestra al resto de interesados qué se ha conseguido en el sprint.

Si los sprints son de un mes, el timebox de la reunión serán 4 horas. Para sprints más cortos, la duración se reduce proporcionalmente.

23/44

Enfoque ágil de proyecto

Reunión Retrospectiva del Sprint

Se inspecciona cómo ha ido el sprint, en lo referente a las personas, sus relaciones, el proceso, y las herramientas.

Se identifican y ordenan los asuntos más importantes, tanto los que fueron bien, como los que suponen una mejora potencial.

Se crea un plan para implementar las posibles mejores detectadas.

Si los sprints son de un mes, el timebox de la reunión serán 3 horas. Para sprints más cortos, la duración se reduce proporcionalmente.

Acciones que se realizan en cada reunión de Scrum

Definición de los principales conceptos de Scrum

Roles en Scrum

En un proyecto ágil, típicamente bajo metodología Scrum, distinguimos 3 roles:

Product Owner

Decide qué se incluye (y qué no) en el backlog del proyecto.

Ordena los ítems en el backlog en función de su prioridad de negocio.

Explica y hace entender al equipo de trabajo en qué consisten esos ítems (historias de usuario). Decide cuándo se deben realizar las entregas.

ScrumMaster

Representa la figura de líder sirviente.

Es el experto en la metodología, guiando y enseñando al equipo a llevarla a cabo adecuadamente.

Soluciona problemas y elimina barreras, facilita el trabajo.

24/44

Enfoque ágil de proyecto

Equipo de desarrollo

Realiza el trabajo necesario para construir y entregar el producto final.

El equipo es un grupo de profesionales con todas las capacidades (en conjunto) para realizar el
trabajo.

Una idea fundamental es que se fomenta la comunicación directa entre el equipo de trabajo y el Product Owner. No se debe pensar que el Scrum Master es el "traductor" del lenguaje de negocio a lenguaje técnico; al contrario, es el equipo de desarrollo el que trabaja directamente con la persona de negocio. El Scrum Master actúa como facilitador de esta relación.

Veamos cómo funciona un equipo Scrum:

Roles en Scrum

Metodología Scrum

XP (Programación Extrema)

XP (del inglés "eXtreme Programming") es una metodología ágil exclusiva para el desarrollo de software.

Al igual que Scrum, considera que los cambios durante el proyecto serán frecuentes, tanto, que se puede llegar a trabajar en iteraciones de 1 sólo día, con entregas y despliegues de los resultados a diario, incluso en períodos más breves de tiempo.

25/44

Enfoque ágil de proyecto

13 prácticas de ingeniería

Equipo compacto.

Juegos de planificación.
Pruebas de usuario.

Entregas (releases) pequeñas. Diseño simple.

Programación por parejas. Refactorización.

Desarrollo dirigido por las pruebas. Integración continua.

Propiedad colectiva del código.
Estándares de codificación.
Metáfora del sistema.
Ritmo sostenible.

5 valores

Simplicidad.

Comunicación.
Feedback.

Motivación.
Respeto.

4 actividades

Codificar.

Probar.

Escuchar.
Diseñar.

26/44

Enfoque ágil de proyecto

4 roles

Líder ágil o coach.
Cliente.

Programador (desarrollador).
Tester.

Prácticas de ingeniería

Equipo compacto

Dentro de XP, el "cliente" no es el que paga la factura, sino el que realmente utiliza el sistema.

XP dice que el cliente debe estar accesible en todo momento y disponible para preguntas.

Por ejemplo, el equipo que desarrolla un sistema de administración financiera debe incluir o tener accesible un administrador financiero.

Juegos de planificación

El proceso principal de planificación dentro de la programación extrema se llama el Juego de Planificación.

El proceso de planificación se divide en dos partes:

Planificación de la release.

Planificación de la iteración.

Pruebas de usuario

Las pruebas de aceptación son propiedad y definidos por el Cliente.

Debemos incluir un punto como "pasar las pruebas del cliente" en la definición de
"hecho".

27/44

Enfoque ágil de proyecto

Entregas (releases) pequeñas

La entrega se realiza a través de frecuentes lanzamientos de funcionalidad en producción creando valor real de negocio.

Los pequeños lanzamientos ayudan al cliente a ganar confianza en el progreso del proyecto.

El cliente ahora puede llegar a sus propuestas futuras sobre el proyecto basado en la experiencia real, sobre un producto tangible, usable (no sobre documentación, como ocurre en los proyectos no ágiles).

Diseño simple

Los programadores deben tomar un enfoque al diseño del software del tipo "lo simple siempre es
lo mejor".

Cada vez que se escribe un nuevo código, el autor debería preguntarse si existe una manera más sencilla de introducir la misma funcionalidad. Si la respuesta es sí, la solución más simple debe ser elegida.

Programación por parejas

También llamada "programación por pares". Todo el código es producido por dos personas que programan en una estación de trabajo (un PC).

Un programador tiene control sobre la estación de trabajo y está pensando sobre todo en la codificación en detalle. El otro programador está más centrado en el panorama general y está continuamente revisando el código que está siendo producido por el primer programador.

Los programadores intercambian estos papeles varias veces al día.

Refactorización

Refactorización es el proceso de cambiar un sistema de software de tal manera que no altera el comportamiento externo del código pero mejora su estructura interna.

28/44

Enfoque ágil de proyecto

Desarrollo dirigido por las pruebas

Dentro de XP, las pruebas unitarias se escriben antes de codificar el código final.

Este enfoque pretende estimular al programador a pensar en las condiciones en las que su código podría
fallar.

Una sección de código fuente está terminada ("done", o hecha) cuando el programador no puede llegar a cualquier otra condición en la que el código pueda fallar.

Integración continua

El equipo de desarrollo siempre debe estar trabajando en la última versión del software.

Los miembros del equipo deben intentar cargar su versión actual en el repositorio de código cada pocas
horas.

La integración continua evitará retrasos más adelante en el ciclo del proyecto, causado por problemas de
integración.

Propiedad colectiva del código

Todo el mundo es responsable de todo el código; esto, a su vez, significa que todo el mundo está autorizado a cambiar cualquier parte del código.

Acelera el proceso de desarrollo, porque si se produce un error en el código cualquier programador puede arreglarlo, pero existe el riesgo de errores introducidos por los programadores que no prevén ciertas dependencias.

Las pruebas unitarias bien definidas solucionan este problema: si las dependencias imprevistas crean errores, cuando se ejecuten pruebas unitarias, se mostrarán fallos.

Estándares de codificación

El estándar de codificación es un conjunto acordado de reglas que todo el equipo de desarrollo acuerda seguir durante todo el proyecto.

El estándar especifica un estilo y un formato consistentes para el código fuente, dentro del lenguaje de programación escogido, así como varias construcciones y patrones de programación que se deben evitar para reducir la probabilidad de defectos.

29/44

Enfoque ágil de proyecto

Metáfora del sistema

La metáfora del sistema es una historia que todo el mundo - clientes, programadores y administradores -
puede decir acerca de cómo funciona el sistema.

Es un concepto de nomenclatura para las clases y los métodos que deberían facilitar a un miembro del equipo adivinar la funcionalidad de una clase / método particular, sólo a partir de su nombre.

Para cada clase o operación, la funcionalidad es obvia para todo el equipo.

Ritmo sostenible

El concepto es que los programadores o desarrolladores de software no deben trabajar más de 40 horas
por semana, y si hay horas extras una semana, que la próxima semana no debe incluir más horas extras.

Este concepto incluye la idea de que las personas realizan mejor y más creativamente su trabajo si están descansados.

Valores en XP

Simplicidad

Recordemos que el diseño simple es una de las premisas que se deben seguir.
También simplicidad en el código, puesto que se aplica la refactorización.

Y simplicidad en la documentación: si el código está bien comentado, el diseño se mantiene simple, y está refactorizado, no será necesario escribir documentación adicional para su comprensión.

Comunicación

El código simple y bien documento comunica a los programadores muy bien qué funcionalidad
persigue.

Las pruebas unitarias comunican por qué se ha elegido ese diseño para el código, y desde luego si funciona correctamente.

Y la comunicación con el cliente es fluida, porque éste forma parte del equipo de trabajo.

30/44

Enfoque ágil de proyecto

Feedback

La retroalimentación por parte del cliente es inmediata, puesto que forma parte del equipo de trabajo.
Esto se refuerza porque las entregas se realizan continuamente en periodos muy cortos de tiempo.

Las pruebas dan feedback en tiempo real sobre el estado de salud del código.

Motivación

Motivación y valentía para centrarse sólo en lo necesario para la entrega de hoy, y no para la de
mañana.

Hay que cumplir entregas todo el tiempo, aunque sean pequeñas. Hay que estar motivado para dar la mejor solución simple para la siguiente entrega.

Y ser persistente para mantener el ritmo sostenible pero necesario para cumplir con las entregas.

Respeto

Los programadores se respetan mutuamente porque nadie puede escribir código que haga fallar código o pruebas de otra persona.

El cliente respeta a los programadores, y los programadores al cliente, puesto que su comunicación es fluida, constante y debe haber entendimiento entre todos.

Actividades en XP

Codificar

El código se construye siguiendo las prácticas de ingeniería recomendadas (programación por parejas, refactorización, estándar de codificación, etc...)

Probar

Es fundamental que el desarrollo sea dirigido por las pruebas, por lo tanto codificar y probar son actividades que van de la mano.

Escuchar

Puesto que se trabaja por parejas, y también conjuntamente con el cliente, las personas del equipo tienen que aprender a escuchar a los demás y a compartir su información y opinión profesional.

Diseñar

Se contempla en todo momento el diseño simple, la refactorización, el respeto al estándar de

codificación, la documentación en el código... estas actividades forman parte del diseño del software.

Roles en XP

31/44

Enfoque ágil de proyecto

Líder ágil o coach

Responsable del proceso global, conocedor de la metodología, y facilitador del trabajo. Guía a los miembros del equipo para seguir el proceso correctamente.

Cliente

Escribe los requisitos (las historias de usuario) y comprueba los criterios de aceptación de los mismos.
Decide la prioridad, según criterios de negocio, de los requisitos para su implementación y entrega.

Programador (desarrollador)

Construye el código y las pruebas unitarias que resuelven los requisitos. En este rol se incluirían todos los perfiles necesarios para ello (programador, analistas programadores, diseñador, maquetador... excepto pruebas funcionales).

Tester

Ayuda al cliente a escribir las pruebas funcionales. Gestiona y utiliza las herramientas para las pruebas funcionales.

Prácticas de Programación Extrema

Programación Extrema

Kanban

Los principios de esta metodología son:

Sigue trabajando a tu manera

El Método Kanban no te pide que cambies tu proceso.

No propone cambios en las prácticas de ingeniería ni una nueva definición de proceso o estilo de
trabajo.

No existe algo como el "Kanban Software Development Process" o el "Kanban Project Management Method".

32/44

Enfoque ágil de proyecto

Pon como objetivo pequeños cambios incrementales

La organización (o el equipo) debe estar de acuerdo en que sus circunstancias actuales justifican un enfoque evolutivo para el desarrollo.

Sin el acuerdo de que un enfoque evolutivo e incremental es el camino correcto hacia adelante, entonces no habrá el ambiente adecuado para una iniciativa Kanban.

Cada miembro del equipo es un líder

Es probable que, lo que la organización actualmente hace, tenga algunos elementos que funcionen bien, y que valga la pena preservar.

Debemos tratar de eliminar el miedo para facilitar el cambio a futuro.

Mejora de forma continua y colaborativa

Hay que buscar el límite de WIP (Work In Progress, o "trabajo en curso") que en última instancia
estimula las ideas sobre problemas de proceso que se pueden solventar o dónde se puede mejorar.
Las cosas que impiden el flujo o introducen perturbaciones en el flujo de trabajo, son las que limitan el
WIP).

El proceso debe estar claro para todos

Sin una comprensión explícita de cómo funcionan las cosas y cómo se hace el trabajo, cualquier discusión de los problemas tiende a ser emocional, anecdótica y subjetiva.

Con un entendimiento explícito es posible pasar a una discusión más racional, empírica y objetiva de las
cuestiones.

Esto es más probable que facilite el consenso sobre las sugerencias de mejora.

Limita el trabajo en curso

Limitar el WIP implica que implementamos un sistema de extracción en parte o en todo el flujo de
trabajo.

El trabajo en progreso en cada estado en el flujo es limitado; es decir, no debemos tener más de un número determinado de tareas en cada estado.

El trabajo debe ser visible

Cuando una tarea es definitivamente "hecha", se debe entregar o mostrar al cliente tan pronto como sea
posible.

33/44

Enfoque ágil de proyecto

Visualiza el flujo de trabajo

Se utiliza un "Kanban" o "Task Board" para buscar cambios de estado en el trabajo, que reflejen el progreso y WIP.

Podremos ver la información y el paso generado de una actividad a la siguiente.

Gestiona el flujo de trabajo

Se monitoriza el trabajo observando el flujo de elementos de trabajo a través de cada estado en el flujo
de trabajo.

Nos interesa la velocidad y la fluidez de ese movimiento (no hay avances bruscos y grandes, sino pequeños y continuos).

Idealmente queremos flujo rápido y fluido.

Flujo rápido y fluido significa que nuestro sistema está creando valor rápidamente, lo cual minimiza el riesgo y evita el coste (de oportunidad) del retraso, y también lo hace de manera predecible.

Veamos algunos ejemplos de kanban en proyectos reales:

Ejemplo 1

34/44

Enfoque ágil de proyecto

Ejemplo 2

Ejemplo 3

Ejemplo 4

35/44

Enfoque ágil de proyecto

Ejemplo 5

Metodología Kanban

Lean

Lean

Más que una metodología, es una filosofía o enfoque de trabajo.

Su origen es el Modelo de Manufactura Lean, es decir aplicado a procesos de fabricación y producción "pull": sólo producen el producto que el cliente necesita, justo cuando lo necesita.

La idea es muy simple: Se centra en hacer obvio lo que añade valor al reducir todo lo
demás.

La idea central es maximizar el valor del cliente y minimizar el desperdicio. Simplemente, lean significa crear más valor para los clientes con menos recursos.

Una organización lean entiende el valor del cliente y enfoca sus procesos claves para aumentarlo continuamente.

Los principios que definen esta filosofía de trabajo son:

- Eliminar residuos.

- Ampliar el aprendizaje.

- Decida lo más tarde posible.

- Entregar lo más rápido posible.

- Capacitar al equipo.

- Ver el conjunto.

36/44

Enfoque ágil de proyecto

El objetivo final es proporcionar valor perfecto al cliente a través de un proceso de creación de valor perfecto que tiene cero residuos.

Lean Start Up

Se trata de extender la metodología o filosofía Lean, al lanzamiento de nuevas empresas al mercado.

Ejemplo: Eliminar stocks

En lugar de hablar de eliminar el desperdicio en el código fuente, por ejemplo, hablamos de eliminar los stocks intermedios en un proceso de distribución y comercialización.

Sus principios son los mismos que el método Lean clásico, resaltando todas aquellas actividades que aportan valor al negocio, y tratando de minimizar, o incluso eliminar, todas aquellas que ralenticen o no aporten valor real.

La idea es ir validando cada aprendizaje de forma continua, experimentando con nuevas ideas en el negocio real y no de forma teórica; e iterando sobre este estilo de funcionamiento.

El gran objetivo es minimizar el riesgo en el lanzamiento de nuevos productos al

mercado, o incluso en la creación de nuevas empresas, aprendiendo del cliente cuando más rápido y barato mejor.

Lean

37/44

Enfoque ágil de proyecto

Relación entre metodologías ágiles

Como vemos en el siguiente gráfico, a menudo no tienen por qué elegirse unas u otras de forma separada.

Es decir, no hay que pensar en términos de "Lean, o Scrum", por ejemplo. Scrum es una metodología
concreta, que nos dice qué reuniones debemos mantener, cuánto duran, qué roles hay en el proyecto, qué
artefactos... Pero todo esto es una forma de hacer específicos y aplicables los principios del agilismo
(entregas continuas, comunicación fluida, simplicidad...). Como por ejemplo, también propone XP.

A la vez, tanto en XP como Scrum, el equipo de trabajo puede (y debe, porque es muy buena práctica)
organizar su trabajo utilizando Kanban, para ver con facilidad las tareas en curso, si hay alguna columna
donde se acumulan muchas tareas (eso es signo de algún problema), si el ritmo de avance es el correcto...

Más aún: en cualquiera de estas combinaciones, aplica la filosofía Lean: no hacer tareas que no aporten valor; maximizar el valor del producto final; no generar desperdicio; mejorar de forma continua...

Si la "unión hace la fuerza", en el caso de las metodologías ágiles se aplica perfectamente.

A su vez, todo este enfoque mental está dentro de lo que podemos denominar "pensamiento sistémico", es decir, pensar en global, en dar la mejor solución al problema completo, eligiendo y afinando las mejores prácticas para ello.

Ejemplo: Sinergia de metodologías

Por ejemplo, un proyecto se organiza en Sprints de 2 semanas, se llevan a cabo las

ceremonias de Scrum, se utiliza un Kanban para la gestión de tareas, se aplican algunas prácticas de ingeniería de XP (programación por pares, desarrollo dirigido por las
pruebas, e integración continua), generando en todo ello el menor desperdicio posible y aumentando el valor del resultado del proyecto.

Uniendo metodologías ágiles

38/44

Enfoque ágil de proyecto

Hemos aprendido

En el enfoque ágil, lo menos claro al arrancar el proyecto es el alcance, puesto que se adoptan los cambios que sea necesario.

El liderazgo ágil se basa en la autogestión de las personas y de su trabajo, no en la figura de un jefe de proyecto.

Las metodologías ágiles tienden a minimizar la documentación y a maximizar los resultados tangibles, mediante quick wins.

El manifiesto ágil es un documento con 4 valores y 12 principios, que sirven de base para una filosofía de trabajo que ha dado lugar a metodologías como Scrum, XP o Kanban.

Los valores ágiles incluyen que las personas son más importantes que los

procesos, los productos más importantes que los documentos, la colaboración
mejor que la negociación, y la respuesta a cambios mejor que seguir un plan
predefinido.

Algunos principios ágiles son las entregas repetidas en breves períodos de

tiempo, potenciar la simplicidad y la excelencia técnica, permitir la autogestión de los equipos de trabajo, o potenciar la comunicación cara a cara.

Scrum es la metodología ágil más utilizada. Se basa en una serie de ceremonias o
reuniones, sprints de duración fija entre 1 y 4 semanas, desarrollo iterativo e
incremental, y contempla las figuras de Scrum Master, Product Owner y Equipo
de Desarrollo.

XP es una metodología que propone una serie de prácticas de trabajo e ingeniería
para el desarrollo de software ágil, con entregas en periodos de tiempo muy
cortos.

Kanban es una metodología que consiste en visualizar el trabajo en curso

mediante un tablero o panel de tareas, limitando el trabajo en curso y haciendo que el seguimiento del avance sea fluido.

Lean significa hacer sólo lo útil, no generar desperdicio, y no perder el tiempo en hacer trabajos que no aporta valor real.

Lean Start Up es la aplicación de la filosofía Lean a la creación de nuevas empresas o al lanzamiento de nuevos productos.

Las metodologías ágiles no son de uso excluyente entre sí; al contrario, es muy buena práctica seleccionar qué parte de cada metodología es más conveniente para nuestro proyecto, y adoptarla.

39/44

Enfoque ágil de proyecto

Actividades prácticas

Prácticas tradicionales y ágiles

Análisis de la ge stión diaria tradicional o ágil

1.Piensa en el proyecto en el que estés trabajando actualmente, o en el último en el que hayas
participado. Haz una lista de las prácticas de gestión más habituales que se llevan a cabo en
el mismo.

Con todo lo que hemos visto en esta unidad, puedes identificar si las prácticas que se están
aplicando en ese proyecto se parecen más a las propias de la gestión tradicional, o a la
gestión ágil:

¿Cómo se planifica?

¿Cómo se hace el seguimiento?

¿Cuántas entregas se hacen durante el proyecto?

¿Se trabaja en base a iteraciones, o con un diagrama de gantt desde el principio? ¿Está el alcance del proyecto determinado de inicio completamente, o se va descubriendo a lo largo del proyecto?

Etc.

40/44

Enfoque ágil de proyecto

Recursos

Videos complementarios

https://youtu.be/PlLHc60egiQ: Vídeo explicativo que narra toda la teoría de Scrum completa en 7
minutos.

https://youtu.be/WtsLl1axTxs: Representación animada de los valores y principios del manifiesto
ágil.

Documentos

Metodología Kanban

https://articulosit.files.wordpress.com/2011/11/kanban.pdf

Descripción detallada de la metodología Kanban.

Enlaces de Interés

Principios del manifiesto ágil

https://agilemanifesto.org/iso/es/principles.html

Relación de los Principios del Manifiesto Ágil.

Enfoque ágil vs tradicional

https://reeelab.com/2014/02/24/agilismo/

Artículo que señala las diferencias entre ambos enfoques de gestión de proyectos.

Método Lean Start Up

https://innokabi.com/metodo-lean-startup/

Artículo descriptivo de la metodología Lean Start Up

Preguntas Frecuentes

41/44

Enfoque ágil de proyecto

1. ¿Se pueden adaptar las metodologías ágiles a cada proyecto y cada empresa?

Sí, pero sólo cuando se tiene experiencia.

Por ejemplo, las 13 prácticas de Programación Extrema están pensadas para aplicarse conjuntamente. Si se elimina alguna de ellas, un equipo inexperto puede perder la noción y el equilibrio del método, y que éste suponga un problema y no una herramienta.

Las metodologías ágiles tienen un contenido teórico muy ligero y son fáciles de comprender, pero se deben aplicar sin modificaciones al inicio. Más adelante el equipo de trabajo irá adaptando y combinando las prácticas de forma más avanzada.

2. ¿El Scrum Master en Scrum es el equivalente al Jefe de Proyecto tradicional?

No. El jefe de proyecto tradicional dirige el trabajo de las personas, presenta la planificación detallada, asigna las tareas, reporta el estado del proyecto... ninguna de estas tareas son realizadas por un Scrum Master; es el propio equipo de trabajo quien se auto organiza.

El Scrum Master facilita el trabajo, enseña el método, propone ajustes al mismo en función del proyecto o de la empresa, o dirige las reuniones si éstas se desvían en tiempo u objetivo.

3. Si se llega al final de Sprint, y quedan unas pocas tareas para finalizar, ¿se alarga el sprint

1 día para finalizarlas?

No. Cada Sprint no puede alargarse de tu timebox definido.

Los requisitos que tienen tareas sin finalizar se consideran "no conseguidos", es decir no "hechos", y por lo tanto no deberían presentarse en el Review Meeting.

El product owner considerará si estos requisitos se retoman en el sprint siguiente (desplazando a otros) o se descartan.

42/44

Enfoque ágil de proyecto

4. Si una reunión, por ejemplo la Daily, se alarga y supera el tiempo establecido, ¿no hay que
respetar su timebox?

El timeboxing es una práctica de obligado cumplimiento. Día a día, hay que enseñar y acostumbrar al equipo de trabajo a respetar los tiempos tope de cada reunión. A largo plazo es la medida más eficiente, y que obliga a centrar el asunto de cada reunión.

El Scrum Master es quien debe decidir sobre este punto y dirigir la reunión hacia su cierre en el tiempo previsto.

Bibliografía

Kanban from the Inside : De Mike Burrows, libro exhaustivo sobre las posibilidades de kanban, sus métricas, variaciones, aplicaciones, valores...

Por un Scrum Popular : De Tobias Mayer y Alan Cyment, comenta distintos enfoques e ideas para conseguir que se utilice Scrum con éxito.

Alosario.

Historias de usuario: Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. Se suelen redactar en la forma de: "Como usuario, necesito la funcionalidad YYY para conseguir SSS".

Parálisis por análisis: La parálisis por análisis es el error típico de ciertos proyectos en donde
nunca se empieza a implementar o a desarrollar prototipos porque el proyecto se ve inmerso en
una permanente fase de análisis previo. Al aspirar a algo perfecto, al final no se acaba consiguiendo
nada concreto.

Pruebas unitarias: Una prueba unitaria es una forma de comprobar el correcto funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o en diseño funcional una función o un procedimiento, en diseño orientado a objetos una clase. Esto sirve para asegurar que cada unidad funcione correctamente y eficientemente por separado.

Iuick wins: Un quick win es un resultado que se obtiene de forma rápida en el tiempo, sin tener
que esperar a que el proyecto consuma gran parte de su calendario. No tiene por qué suponer un
valor de negocio importante, pero sí funciona como demostración del avance y la utilidad del
proyecto, genera confianza en los interesados (sobre todo en los inversores) y se utiliza para
confirmar las expectativas.

43/44

Enfoque ágil de proyecto

ROI: El ROI es de gran utilidad para evaluar esta rentabilidad. Se convierte en la relación entre la inversión de marketing y los beneficios generados, bien sean ventas directas u obtención de clientes potenciales.

Síndrome del estudiante: El síndrome del estudiante es un concepto introducido por Eliyahu M.
Goldratt, en su libro Cadena crítica.1 Se refiere al fenómeno por el cual las personas comienzan a
dedicarse seriamente a una tarea que les fue asignada solamente cuando la fecha de entrega se
acerca. Más específicamente, en los primeros dos tercios del período asignado para la tarea
avanzan un tercio del trabajo, y en el último tercio aceleran y finalizan los dos tercios restantes.
Esto sucede típicamente cuando un estudiante está preparando un examen, de ahí el nombre.

44/44