EPS_T014 Dominio VI: Mejora continua

Plataformas de Aprendizaje Autodirigido

Dominio VI: Mejora continua.

En la mayoría de los proyectos tradicionales, las lecciones aprendidas se recopilan al final del proyecto para que se puedan aplicar en futuros proyectos. Sin embargo, aplicar lecciones a proyectos futuros no agrega valor al proyecto actual. Los proyectos futuros pueden no ser similares a los proyectos pasados. Por lo tanto, Agile tiene como objetivo aprender continuamente durante cada proyecto y aplicar las lecciones aprendidas dentro del proyecto actual.

Varias herramientas, técnicas, conjuntos de conocimientos y habilidades pueden mejorar continuamente los proyectos Agile:

  • Retrospectivas.

Las retrospectivas son reuniones que ocurren al final de cada iteración. Los miembros del equipo comparten lecciones aprendidas para que puedan aplicarse durante la siguiente iteración. Algunas herramientas para identificar y resolver problemas, que se han discutido en detalle en la sección de Detección y Resolución de Problemas, también pueden emplearse en las retrospectivas.

Las sesiones de retrospectiva suelen dividirse en cinco segmentos:

    1. Estableciendo el escenario: Se crea un ambiente abierto en el que se anima a los participantes a comunicarse. Se establece una agenda clara para la discusión. En este segmento, cada miembro del equipo es consciente de sus responsabilidades y actitudes en la retrospectiva, que son: registro, enfoque activado/desactivado, ESVP (Explorador, Comprador, Vacacionista y Prisionero) y acuerdos de trabajo. El ESVP puede ayudar a clarificar las actitudes de los diferentes miembros del equipo hacia la retrospectiva identificándolos como Explorador, Comprador, Vacacionista o Prisionero.
      • Explorador: quieren explorar y descubrir nuevas ideas.
      • Comprador: escucharán a los demás e identificarán ideas en las que les gustaría trabajar.
      • Vacacionista: no están interesados en la actividad de la retrospectiva, pero participan pasivamente.
      • Prisionero: sienten que están obligados a asistir a la retrospectiva.
    1. Recopilación de datos: En este segmento, se recopilan datos sobre lo que ocurrió durante la iteración. Los miembros del equipo deben tener una visión común de las cosas que les gustaría cambiar o mejorar. Actividades como línea de tiempo, triple nickels, histograma de satisfacción, radar del equipo, puntos de código de color y like-to-like se pueden usar para recopilar datos.
    2. Generación de ideas: Una vez recopilados los datos, se examinan en busca de ideas. Actividades que pueden ayudar a generar ideas incluyen lluvia de ideas, diagrama de espina de pescado, identificación de temas y “Cinco Porqués“.
    3. Decidir un curso de acción: Con base en las ideas generadas, los miembros del equipo planifican cómo actuarán de manera diferente en la siguiente iteración. Actividades como temas breves, círculo de preguntas, objetivos SMART y juegos de planificación retrospectiva pueden usarse para crear un plan de acción.
    4. Cierre de la retrospectiva: En el segmento final, los miembros del equipo muestran su agradecimiento mutuo y resumen los cambios que van a implementar en el futuro. Las actividades que se pueden usar para cerrar la retrospectiva incluyen retorno sobre el tiempo invertido, agradecimientos, Plus/Deltas y “Ayudó, Dificultó, Hipótesis“.
      • Ayudó, Dificultó, Hipótesis: Esta actividad consiste en identificar lo que ayudó y dificultó al equipo durante la iteración, y el equipo crea una hipótesis para posibles soluciones.
  • Conocimiento compartido.

Los proyectos ágiles están optimizados para compartir conocimientos. Por ejemplo, los miembros del equipo comparten información durante demostraciones de productos, reuniones diarias, tableros de tareas y colocación del equipo. La comunicación osmótica (escuchar y escuchar conversaciones casualmente) es un subproducto natural del intercambio de conocimientos de los equipos colocados.

Por muy importante que sea el intercambio de conocimientos para los proyectos ágiles, es posible que no ocurra con la frecuencia deseada, porque es posible que el sistema de recompensas de una organización no haya sido diseñado para incentivar el intercambio de conocimientos. Es fácil realizar un seguimiento del desempeño de un individuo y recompensarlo, pero es posible que esto no aumente el desempeño general de un equipo. Por tanto, es importante que el sistema de seguimiento y recompensa se base en el desempeño del equipo.

  • Adaptación de procesos.

A veces, las metodologías ágiles se adaptan al proyecto. Los cambios radicales y el estricto cumplimiento de las metodologías pueden parecer enfoques extremos, porque cada proyecto trae sus propios requisitos y existen riesgos asociados con ambos.

Las diferentes prácticas ágiles están interrelacionadas. Es importante comprender esto antes de modificar una práctica ágil.

Es importante que no nos apresuremos a realizar modificaciones. Debemos asegurarnos de que nuestras razones para modificar la metodología no estén guiadas por la motivación de evitar problemas fundamentales del proyecto.

  • Principios de pensamiento sistémico.

Cualquier modificación de los métodos ágiles debe ir precedida de una comprensión profunda de los entornos en los que funcionan. Los requisitos de un proyecto y la tecnología utilizada para ejecutarlos pueden aumentar la complejidad de los proyectos.

El método ágil se puede utilizar en proyectos sencillos y los métodos tradicionales también pueden funcionar igual de bien. Sin embargo, cuando el proyecto es caótico en términos del enfoque que se debe adoptar, ni Agile ni ningún otro método pueden garantizar el éxito.

  • Análisis de procesos.

El análisis de procesos implica examinar e identificar cualquier problema en las metodologías ágiles o en cualquier modificación.

Alistair Cockburn sugiere una lista de patrones, características y pensamientos que podrían afectar negativamente a las metodologías:

    • Intolerante: Las reglas de cumplimiento no deben imponerse y deben ser elegidas por los propios equipos. Se debe dar un poco de margen de maniobra para que los equipos funcionen.
    • Pesado: Las metodologías que se vuelven pesadas al agregar prácticas y artefactos no necesariamente mejoran la tasa de éxito.
    • Embellecido: Las metodologías pueden embellecerse con el tiempo, pero las adiciones pueden contener errores.
    • Un modelo único: cada proyecto varía en tamaño y puede requerir la adopción de diferentes metodologías. No existe un enfoque único que sirva para todos.
    • No probado: Es mejor modificar o reutilizar metodologías y hacer adiciones sólo cuando sea necesario en lugar de experimentar con metodologías no probadas.
    • Usado una vez: Las metodologías que se han utilizado solo una vez no garantizan el éxito.

También hay algunas señales de éxito que podrían indicar que el enfoque elegido va por buen camino.

    • El producto fue enviado exitosamente.
    • El liderazgo se mantuvo sin cambios durante el proyecto.
    • Los miembros del equipo están dispuestos a utilizar el enfoque nuevamente en otro proyecto, porque lo encontraron efectivo.
  • Aplicación de nuevas prácticas ágiles.

En ocasiones, puede ser necesario modificar las prácticas ágiles y adaptarse a prácticas nuevas y emergentes. Sin embargo, antes de aumentar cualquier práctica es importante considerar lo siguiente:

    • ¿Existe algún problema o causa raíz que deba resolverse? ¿El problema realmente requiere adoptar un nuevo enfoque o se puede solucionar de otra manera?
    • Se deben investigar nuevos enfoques para sus afirmaciones. También deben ser examinados para detectar cualquier efecto secundario.
    • Se debe examinar un nuevo enfoque durante algunas iteraciones antes de implementarlo en todo el proyecto.
  • Procesos de mejora continua.

La mejora continua es una parte integral de los proyectos ágiles y ocurre durante todo el proyecto.

El proceso de desarrollo se refina y mejora continuamente siguiendo el ciclo de planificar, desarrollar, evaluar y aprender.

A medida que continúa la mejora del proceso, el producto también mejora y evoluciona. Los comentarios de los clientes obtenidos después de entregar incrementos dan forma al producto y le permiten mejorar continuamente.

  • Auto evaluación.

Es tan importante evaluar a las personas como evaluar los procesos de desarrollo y los productos. Los equipos autodirigidos necesitan autoevaluar su desempeño a intervalos regulares.

El cuestionario de autoevaluación de James Shore es una buena forma de evaluar el desempeño del equipo. El cuestionario evalúa el desempeño en las siguientes categorías:

    • Pensando.
    • Planificación.
    • Trabajar en colaboración.
    • Desarrollando.
    • Liberar.

Después de calificar cada respuesta en una escala del 1 al 100, los resultados se trazan en un gráfico de araña como el siguiente:

Herramientas y artefactos ágiles.

Los equipos ágiles pueden utilizar varios artefactos para desarrollar software y realizar un seguimiento del progreso. Algunas de las herramientas y artefactos se analizan a continuación:

  • Backlogs e historias de usuario.

Las historias de usuarios son descripciones compactas de la funcionalidad empresarial. Esta herramienta obliga a los equipos a identificar al usuario y el beneficio comercial de cada funcionalidad. Después de crear historias de usuarios, la lista se organiza en un trabajo pendiente.

El formato de una Historia de usuario podría verse así:

Como <rol>, quiero <funcionalidad>, para que el <beneficio empresarial>”.

  • Jerarquía de los requerimientos.

Un proyecto complejo necesita un desglose detallado del trabajo que consta de varios niveles para estimar y planificar el proyecto más fácilmente.

  • Radiadores de información.

Los radiadores de información son técnicas de visualización altamente visibles que se utilizan para rastrear el estado del proyecto. Pueden consistir en cuadros, resúmenes y gráficos relacionados con el proyecto. Los storymaps, que se discutieron anteriormente, son ejemplos de radiadores de información. Otros ejemplos comunes son los gráficos burndown y los gráficos burnup.

  • Gráficos burndown y burnup.

Los gráficos burndown muestran el tiempo estimado necesario para completar el proyecto, mientras que los gráficos burnup muestran el trabajo que se ha entregado hasta el momento. Sin embargo, estos gráficos no son concluyentes ya que solo transmiten el estado y no brindan información sobre la trayectoria del proyecto. Por ejemplo, estos gráficos no explican por qué podría haber habido una desaceleración en un período de tiempo particular.

  • Modelado ágil.

Modelado ágil es un conjunto de técnicas de modelado utilizadas en proyectos Agile. Son modelos “básicos” que ilustran el diseño del producto. Su principal objetivo es promover el debate y ayudar a crear el producto en lugar de ser un modelo del producto final pulido.

Algunos de los métodos de modelado comunes que se pueden utilizar son diagramas de casos de uso, modelos de datos y diseños de pantalla.