Compartir a través de

Implementación de prácticas de Agile que se escalan

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Las organizaciones empresariales adoptan prácticas de Agile por muchas razones. Entre estas razones se incluyen:

  • Reducir el tiempo de comercialización y acelerar la entrega de productos.
  • Mejorar la eficacia de la organización para administrar las cambiantes prioridades.
  • Mejorar la calidad del software y la previsibilidad de las entregas.
  • Mejorar la visibilidad de los proyectos y reducir los riesgos

A medida que crezca la organización, podrá escalar sus prácticas para que sigan siendo ágiles y cumplan los cambiantes objetivos. Para ello, tenga en cuenta estos dos principios rectores:

  • ¿Qué consideran usted, sus equipos y su organización que es triunfar? ¿Cuál es de los siguientes factores es el que más le interesa: entregar a tiempo, la calidad del producto, la previsibilidad o la satisfacción del cliente?
  • Vuelva a los primeros principios, vuelva a los principios y los valores compartidos enumerados en el manifiesto de Agile, tal como ha señalado Ken Schwaber, uno de los fundadores de Scrum:
    • "Los valores y los principios se escalan, pero las prácticas dependen del contexto".
    • "Mantenga los valores, mantenga los principios, piense por usted mismo. Una premisa básica de Agile es que las personas que realizan el trabajo son las que mejor pueden averiguar cómo hacerlo".

Creación de ritmo y flujo

Al adoptar una cadencia compartida y un conjunto de comunicaciones periódicas, se crea un flujo constante de actividad en toda la organización. Entre las prácticas que pueden ayudar a crear ritmo y flujo en organizaciones grandes se incluyen:

  • Cadencia compartida: los sprints y las versiones regulares establecen el ritmo de la empresa. Que todos los equipos trabajen con una cadencia compartida sirve de ayuda en todas las actividades de coordinación y colaboración.
  • Correos electrónicos de sprint: para que tanto la organización como todos los equipos informados sobre el progreso y los planes de los equipos de características, cada uno de estos equipos puede enviar por correo electrónico un resumen de sus resultados de sprint anteriores y los planes de sprint actuales.
  • Demostraciones de sprint: un vídeo que dura entre 2 y 3 minutos e ilustra una nueva característica producida por el equipo. Los vínculos a estos vídeos se pueden incluir en los correos electrónicos de sprint.
  • Reuniones de presentación: para informar a otros equipos y pedir comentarios sobre el software en desarrollo, los equipos presentan el trabajo que han realizado. Realice estas reuniones a intervalos regulares a lo largo de todo el ciclo de vida del proyecto y ábralas a todas las partes interesadas.
  • Correos electrónicos de resumen de errores: para admitir información sobre la calidad del producto y fomentar el mantenimiento de una disciplina de errores, comparta periódicamente métricas de calidad con la organización. Estas métricas pueden incluir errores activos por equipo de características, tendencias de errores y errores por ingeniero.
  • Reuniones de coordinación: mantenga reuniones para coordinar los equipos a intervalos regulares o con la frecuencia necesaria para abordar los distintos objetivos, dependencias y riesgos.

Interacción con clientes

La participación de los clientes a lo largo de todo el ciclo de vida del producto es un principio ágil fundamental. Permita a los equipos interactuar directamente con los clientes en lo que respecta a los conjuntos de características que poseen.

  • Comentarios continuos: cree bucles de comentarios de clientes. Estos bucles pueden adoptar muchas formas:
    • Voz del cliente: facilite a los clientes el envío de comentarios, la aportación de ideas y que voten sobre las características de próxima generación. A menudo los comentarios se realizan a través de un sitio web dedicado.
    • Comentarios sobre los productos: los botones de comentarios que hay en el producto son otra manera de solicitar comentarios sobre la experiencia con el producto o características específicas del mismo.
    • Demostraciones de clientes: demostraciones programadas periódicamente en las que se solicitan a los clientes comentarios que puedan ayudar a dar forma a los productos de próxima generación y mantenerle al día para crear aplicaciones que los clientes quieren consumir.
  • Programas pioneros: estos programas deben desarrollarse con la idea de que todos los equipos puedan querer participar en algún momento. Los usuarios pioneros obtienen acceso a las primeras versiones del software de trabajo y luego pueden aportar sus comentarios. A menudo, estos programas funcionan activando las marcas de características en una lista de usuarios pioneros.
  • Decisiones controladas por datos: busque distintas formas de instrumentar el producto para obtener datos útiles y que se puedan probar varias hipótesis. Ayude a impulsar una cultura que facilite la experimentación y que celebre el aprendizaje.

Mejora de la visibilidad del proyecto

Cuanta más información tengan tanto usted como sus equipos sobre el objetivo, la visión y el progreso del trabajo que se está realizando, mejor preparado estará para reducir los riesgos y administrar las dependencias.

  • Estructura de equipo: independientemente del tamaño que obtenga su organización, estructure su organización en torno a equipos pequeños de 6 a 9 escalas. Cree equipos de características verticales y autónomos agrupados en áreas de administración de cartera.
  • Estructura de descomposición del trabajo: la descomposición de objetivos grandes, características o requisitos en otros más pequeños sigue siendo un aspecto estable de la administración de proyectos. Al descomponer el trabajo en tareas de tamaño similar, los equipos pueden realizar mejores estimaciones e identificar riesgos y dependencias.
  • Vistas consolidadas: use las herramientas de seguimiento en línea para agregar trabajo para obtener conocimientos en los equipos. Cree paneles que muestren el progreso y las tendencias.
  • Reseñas de la experiencia: estas reuniones, que se celebran antes de que comience el desarrollo de las características individuales, sirven para educar sobre el liderazgo en distintos escenarios y prioridades, recopilar comentarios, establecer las expectativas y exponer todos los problemas que se dan entre equipos en lo referente a la característica.

Capacitación del personal de producción

Estos son algunos procedimientos concretos de Agile que se escalan bien y que hacen que los empleados estén más comprometidos y sean más felices y productivos:

  • Liderazgo insertado: capacite tanto a los equipos como a los líderes de la organización para que se puedan organizar y administrar de forma autónoma tanto como sea posible. La autonomía de los equipos aumenta la eficacia y agilidad de los equipo de la organización. Asegúrese de que los equipos tengan el patrocinio corporativo necesario para tener éxito.
  • Reuniones rápidas diarias: también se denominan reuniones de Scrum y ayudan a los equipos a centrarse en lo que necesitan hacer para maximizar su capacidad de cumplir sus compromisos de sprint. A medida las organizaciones que crecen, estas deben considerar la posibilidad de escalonar estas reuniones, con el fin de que la participación entre equipos pueda producirse cuando sea necesario.
  • Scrum de Scrums: en las reuniones rápidas diarias de los miembros de los diferentes equipos de Agile se informa del trabajo completado, los pasos siguientes y los problemas o bloques que se producen dentro de sus equipos representativos.
  • Comunicaciones de los equipos: anime a los equipos a compartir sus procedimientos e instrucciones, a los que todos los equipos pueden acceder a través de la red corporativa. Entre las herramientas comunes que se usan para este fin se incluyen wikis de los equipos, OneNotes o sitios de Markdown.
  • Colaboración: fomente tanto las comunicaciones informales entre equipos como la colaboración dentro de cada equipo. La institucionalización de prácticas, como las revisiones del código, las revisiones de diseño o las revisiones de las especificaciones no solo aumentan la colaboración en equipo, sino que también ayudan a desarrollar competencias corporativas individuales y generales.

Mejora de la cultura de la organización

Para mejorar la eficacia de la organización, preste atención a la cultura que desea crear. Los cambios en la cultura se producen cuando las personas, los equipos y las organizaciones adoptan una o varias prácticas de mejora continua. Estas son algunas prácticas escalables de Agile:

  • Retrospectivas: la formulación de preguntas como: "¿qué ha ido bien?", "¿qué debemos hacer de manera diferente?" y "¿qué debemos dejar de hacer?" ayudan a los equipos a reflexionar sobre cómo pueden mejorar sus procesos y prácticas. Las retrospectivas ayudan a los equipos a exponer lo que funciona bien y las mejoras necesarias. Las retrospectivas se pueden realizar en cualquier momento y lugar. Sin embargo, la institucionalización de ciertas retrospectivas en una cadencia regular ayuda a institucionalizar las prácticas de mejora continua. Por ejemplo:

    • Las retrospectivas de sprint pueden ayudar a los equipos a identificar áreas de mejora con una cadencia regular.

    • Las retrospectivas de lanzamiento pueden ayudar a las organizaciones a identificar áreas para mejorar las comunicaciones, así como la mejora de las prácticas internas y del combustible para la próxima versión.

    • Revisiones operativas: normalmente se realizan mensualmente e incluyen representantes de un flujo de valor completo. Mostrar una cartera de proyectos y otras iniciativas y usar datos cuantitativos y de objetivos diseñan estas retrospectivas para provocar discusiones sobre la dinámica que afectan al rendimiento entre equipos.

      Consulte Agile Retrospective Resource Wiki para obtener ideas, sugerencias y herramientas tanto para planear como para realizar retrospectivas. Consulte también la extensión Retrospectivas de Marketplace.

  • Panel de seguimiento de mejoras: cualquiera puede tener buenas ideas para mejorar los procesos en cualquier momento. Capturar esas ideas para debatirlas y decidir cómo actuar al respecto rápidamente es clave para apoyar los esfuerzos de mejora de procesos.

    Una pizarra blanca proporciona un medio fácil y visual con el que capturar ideas. Además, puede crear un equipo de seguimiento de mejoras y capturar ideas que realice en un panel electrónico.

  • Institucionalizar el uso compartido: compartir procedimientos recomendados y comunicar ideas ayuda a todos los equipos de una organización a crecer y mejorar. El desarrollo de una cultura de aprendizaje es fundamental para apoyar esta y otras actividades de mejora continua. Algunas ideas que se deben tener en cuenta:

    • Wikis internos

    • Listas de distribución internas

    • Semanas de hackatón o un 10 % del tiempo dedicado a las soluciones

    • Un equipo de soporte técnico interno de Agile que apoye a los equipos que empiezan a usar Agile

      El juego de la cultura proporciona un buen recurso para que los administradores de Agile ayuden a los equipos a adoptar Agile y a compartir los procedimientos recomendados.

  • Comunidades de práctica: apoyo a disciplinas comunes internas (por ejemplo, DBA, arquitectos de software o diseño de la experiencia del usuario)

Software de trabajo

"El software de trabajo se debe entregar con cierta frecuencia, entre un par de semanas y un par de meses, pero debe tener preferencia la escala de tiempo más corta."
"El software de trabajo es la medida principal del progreso."
- Manifiesto de Agile

A medida que aumente la cantidad de software, las características y la complejidad, deberá adoptar prácticas que le ayuden a producir soluciones consumibles.

  • Marcas de características: use marcas de características para habilitar o deshabilitar el acceso a las diferentes características. Proporcione soporte técnico para activar las características a los usuarios pioneros, con el fin de obtener comentarios de su trabajo.
  • Series de versiones: proporcione otro tipo de cadencia para entregar una o varias características. Los equipos de características conocen la programación planeada previamente de expansión de las nuevas características y la planean correctamente. Las series de versiones pueden corresponder a la misma cadencia de sprint que se establece para la organización o se producen con otra cadencia. Consulte Marco de Agile escalado para obtener información sobre cómo configurar sprints y sobre las series de versiones.
  • Integración continua: adopte procesos que eliminen el trabajo manual y, en su lugar, automaticen el flujo de software a través de los ciclos de prueba, compilación e implementación.
  • Código abierto interno: incorpore a los equipos de desarrollo internos el valor y la ética que se desarrollan en la comunidad de software de código abierto.

Junto con los procedimientos anteriores, en los siguientes artículos encontrará más instrucciones sobre el escalado de las herramientas de Agile:

Recursos del sector

Prácticas que no se escalan

  • Cálculo de grandes iniciativas: la parte de los métodos de proyectos en cascada implicada en el cálculo de recursos y programaciones. Cuanto mayores sean las iniciativas, menos probable es que estos cálculos sean de valor. A medida que crecen los proyectos, aumenta la probabilidad de que aparezcan riesgos y problemas e impedimentos imprevistos, lo que invalida muchos de los cálculos.
  • Velocidad: aunque la velocidad del equipo puede proporcionar una métrica útil para obtener información de cuánto trabajo puede completar cada equipo durante un ciclo de sprint, no se pueden agregar velocidades de equipos para obtener métricas significativas o útiles. Además, puede acabar resultando problemático usar la velocidad obtenida de muchos equipos para completar de forma confiable las previsiones de largo alcance. Los equipos varían en la forma en que calculan su trabajo y esas variaciones aumentan con el tiempo.
  • Soluciones prescriptivas de arriba abajo: no existe una fórmula única y ninguna solución suele servir para todos los equipos. Apoyar la autonomía del equipo significa permitir que los equipos encuentren sus propias soluciones.