stringtranslate.com

Marco ágil escalable

El marco ágil escalable ( SAFe ) es un conjunto de patrones de organización y flujo de trabajo destinados a guiar a las empresas en la ampliación de prácticas ágiles y esbeltas . [1] [2] Junto con la entrega ágil disciplinada (DAD) y S@S (Scrum@Scale), SAFe es uno de los cada vez más numerosos marcos que buscan abordar los problemas que surgen al ampliar más allá de un solo equipo. [3] [4]

SAFe promueve la alineación, la colaboración y la entrega entre un gran número de equipos ágiles. Fue desarrollado por y para profesionales, aprovechando tres cuerpos de conocimiento principales: desarrollo de software ágil , desarrollo de productos lean y pensamiento sistémico . [5]

La referencia principal para el marco ágil escalado fue originalmente el desarrollo de una visión general de cómo fluía el trabajo desde la gestión de productos (u otras partes interesadas ), a través de los equipos de gobernanza , programa y desarrollo , hasta los clientes . [6] [7] Con la colaboración de otros en la comunidad ágil, esto se perfeccionó progresivamente y luego se describió formalmente por primera vez en un libro de 2007. [8] El marco continúa siendo desarrollado y compartido públicamente; con una academia y un esquema de acreditación que respalda a aquellos que buscan implementar, apoyar o capacitar a otros en la adopción de SAFe.

Desde su primer lanzamiento en 2011, se han publicado seis versiones principales [9], mientras que la última edición, la versión 6.0, se lanzó en marzo de 2023. [10]

Si bien SAFe sigue siendo reconocido como el enfoque más común para escalar prácticas ágiles (con un 30 por ciento y en aumento), [11] [12] [ página necesaria ] , [13] también ha recibido críticas por ser demasiado jerárquico e inflexible. [14] También recibe críticas por dar a las organizaciones la ilusión de adoptar Agile , mientras mantiene intactos los procesos familiares. [15]

Desafíos de la ampliación de los principios y prácticas ágiles

Cómo afrontar horizontes de planificación más amplios

Los equipos de desarrollo suelen refinar su cartera de pedidos hasta dos o tres iteraciones antes, pero en organizaciones más grandes, el equipo de marketing de productos debe planificar con más anticipación sus compromisos con el mercado y las conversaciones con los clientes. [16] A menudo trabajarán con una hoja de ruta de muy alto nivel, de 12 a 18 meses, y luego planificarán en colaboración con los equipos para tres meses de trabajo. [ cita requerida ] Los equipos de desarrollo seguirán realizando refinamientos detallados con 2 o 3 iteraciones de anticipación, y solo se adentrarán en los planes de tareas detallados para la siguiente iteración. [ cita requerida ]

Mantenerse ágil en niveles abstractos de responsabilidad

Si bien los equipos de desarrollo cuentan con una serie de marcos que definen cómo deben ser ágiles, hay muy pocos que describan esto para la gerencia. SAFe ofrece muchos de los mismos principios, como los equipos multifuncionales, a los grupos que manejan los niveles más abstractos de responsabilidad y planificación (producto y cartera). [ cita requerida ]

Cómo tratar con la autoridad delegada

En Scrum , se espera que el propietario del producto asuma la responsabilidad de todo el ciclo de vida del producto , incluido el retorno de la inversión de las decisiones de desarrollo, así como el rendimiento en el mercado. En los desarrollos a gran escala, la organización desea tener una vista de los registros de varios equipos, como la que proporciona un gerente de producto . [17] Aunque SAFe asume que el rol del propietario del producto recae en la gestión del producto, ha sido criticado por separar a los propietarios del producto en la organización de desarrollo. [18]

Sincronización de entregables

Los marcos ágiles están diseñados para permitir que el equipo de desarrollo sea autónomo y libre de diseñar su forma de trabajar. SAFe reconoce que, a escala de decenas o cientos de equipos de desarrollo, resulta cada vez más caótico que los equipos se autoorganicen por completo. [19] Por lo tanto, impone algunas restricciones a este respecto, de modo que cuando los equipos trabajan en el mismo producto, sus entregables se puedan sincronizar mejor para lanzarlos juntos, aunque esta ha sido un área en la que SAFe ha sido criticado. [17] [18]

Dedicar tiempo a la innovación y la planificación

El ciclo de planificación de SAFe recomienda incluir una iteración adicional después de un lanzamiento, lo que permite a los equipos mejorar sus prácticas y estar listos para el siguiente incremento de planificación. Las ediciones anteriores de SAFe también diseñaron esto para que fuera una iteración de endurecimiento , es decir, para estabilizar o endurecer el producto antes de lanzarlo. Esto se basó en las complicaciones de trabajar con grandes entornos de integración donde las dependencias impedían que se probaran varios asuntos hasta el final. SAFe fue criticado por esto porque representaba un elemento anti-ágil o en cascada, pero estaba en línea con los incrementos lean de 90 días que suman 13 semanas, y si se hacen sprints de dos semanas, se necesitan seis de ellos más un ciclo de planificación o endurecimiento de una semana. [20] Esto no está incluido en las ediciones recientes de SAFe.

Implementación

Principios subyacentes de SAFe

Según sus autores, SAFe se basa en diez conceptos subyacentes, que se derivan de los principios lean y ágiles existentes, así como de la observación: [21]

  1. Adoptar una visión económica
  2. Aplicar el pensamiento sistémico
  3. Suponga variabilidad; preserve las opciones
  4. Construya de forma incremental con ciclos de aprendizaje integrados y rápidos
  5. Base los hitos en la evaluación objetiva de los sistemas de trabajo
  6. Visualice y limite el trabajo en progreso, reduzca el tamaño de los lotes y administre las longitudes de las colas
  7. Aplicar cadencia (sincronización), sincronizar con la planificación entre dominios
  8. Desbloquear la motivación intrínseca de los trabajadores del conocimiento
  9. Descentralizar la toma de decisiones
  10. Organizarse en torno al valor

Se ha criticado a SAFe por agrupar demasiadas prácticas dispares. [22]

El marco SAFe

En la versión 5.1 de SAFe, hay cuatro configuraciones: esencial, cartera, solución grande y completa: [23]

Certificaciones

Scaled Agile ofrece certificaciones que cubren diferentes áreas y niveles de conocimiento. [24]

Véase también

Referencias

  1. ^ Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016). Escalado de métodos ágiles para programas del Departamento de Defensa . Instituto de Ingeniería de Software. CMU/SEI-2016-TN-005.
  2. ^ Athrow, Desiree (29 de enero de 2015). "Por qué la entrega continua es clave para acelerar el desarrollo de software". TechRadar . Consultado el 27 de noviembre de 2017 .
  3. ^ Linders, Ben (22 de enero de 2015). "Escalar Agile con el marco de trabajo Disciplined Agile Delivery". InfoQ . Consultado el 27 de noviembre de 2017 .
  4. ^ van Haaster, K (2014). Agile in the large: Getting from Paradox to Paradigm (Agilidad a gran escala: pasar de la paradoja al paradigma) . Artículo inédito de la Universidad Charles Sturt.
  5. ^ King, Michael (2017). "Servir a los clientes federales con conceptos SAFe" (PDF) . Actas de la conferencia Capability Counts .[ enlace muerto ]
  6. ^ Bridgwater, Adrian (7 de agosto de 2013). "Real Agile Means Everybody Is Agile" (Realmente ágil significa que todos son ágiles). Dr. Dobb's . Consultado el 27 de noviembre de 2017 .
  7. ^ Linders, Ben (28 de agosto de 2014). "Muerte por planificación en la adopción ágil". InfoQ . Consultado el 27 de noviembre de 2017 .
  8. ^ Leffingwell, Dean (2007). Escalado de la agilidad del software: mejores prácticas para grandes empresas . Addison-Wesley. ISBN 978-0321458193.
  9. ^ "Acerca de Scaled Agile Framework: una breve historia de SAFe". Scaled Agile Inc. Consultado el 12 de agosto de 2020 .
  10. ^ "Saluda a SAFE 6.0". Scaled Agile Inc. Consultado el 16 de marzo de 2023 .
  11. ^ "13.º Informe anual sobre el estado de Agile". Encuesta sobre el estado de Agile . CollabNet VersionOne. 2019. Consultado el 27 de agosto de 2019 .
  12. ^ Link, P; Lewrick, M (29 de septiembre de 2014). "Métodos ágiles en una nueva área de gestión de la innovación" (PDF) . Conferencia de marketing de la ciencia a los negocios .
  13. ^ Baptista, Roberto (28 de enero de 2015). "Profissionais brasileiros eo interesse por treinamentos de especialização". Mundo de la informática Brasil . Consultado el 28 de enero de 2015 .
  14. ^ Schwaber, Ken (6 de agosto de 2013). "UnSAFe a cualquier velocidad". Telling It Like It Is ( Diciéndolo como es ). Consultado el 11 de noviembre de 2017 .
  15. ^ Gothelf, Jeff (5 de octubre de 2021). "SAFe no es ágil" . Consultado el 21 de mayo de 2023 .
  16. ^ Eklund, U; Olsson, H; Strøm, N (2014). Desafíos industriales de la escalabilidad ágil en sistemas integrados de producción en masa . Springer International Publishing. ISBN 9783319143583. {{cite book}}: |work=ignorado ( ayuda )
  17. ^ ab Vaidya, A (2014). ¿DAD sabe más? ¿Es mejor hacer menos o simplemente ser más seguro? Adaptación de prácticas ágiles de escalado a la empresa . Extracto de las Actas de PNSQC 2014. págs. 8-9.
  18. ^ ab Maximini, Dominik (11 de septiembre de 2013). "Una visión crítica de SAFe - Scrumorakel - Blog". Scrum Oracle . Consultado el 27 de noviembre de 2017 .
  19. ^ Stafford, Jan (9 de diciembre de 2013). "El desarrollo ágil a gran escala requiere prácticas definidas, afirma un consultor". SearchSoftwareQuality . Consultado el 27 de noviembre de 2017 .[ enlace muerto ]
  20. ^ Killick, Neil (21 de marzo de 2012). "El horror del marco ágil escalable". Agile, Scrum, Kanban, Lean y todo lo que hay entre medio . Consultado el 27 de noviembre de 2017 .
  21. ^ "Principios SAFe Lean-Agile" . Consultado el 19 de febrero de 2016 .
  22. ^ Elssamadisy, Amr. "¿SAFe ha resuelto el problema de la adopción de Agile?". InfoQ . Consultado el 11 de noviembre de 2017 .
  23. ^ Rose, Doug (2018). Agilidad empresarial para principiantes. John Wiley & Sons. págs. 87–89. ISBN 9781119446095.
  24. ^ "Certificación". Scaled Agile . Consultado el 19 de febrero de 2016 .

Lectura adicional

Enlaces externos