El marco ágil Scaled ( SAFe ) es un conjunto de patrones de organización y de flujo de trabajo destinado a orientar a las empresas en la escala magras y ágiles prácticas. [1] [2] Junto con Scrum a gran escala (LeSS), entrega ágil disciplinada (DAD) y Nexus, SAFe es uno de un número creciente de marcos que buscan abordar los problemas encontrados al escalar más allá de un solo equipo. [3] [4] SAFe está disponible gratuitamente a través de Scaled Agile, Inc., que conserva los derechos de autor y las marcas comerciales registradas. [5]
SAFe promueve la alineación, la colaboración y la entrega en un gran número de equipos ágiles. Fue desarrollado por y para los profesionales, mediante el aprovechamiento de tres cuerpos principales de conocimiento: desarrollo ágil de software , desarrollo de productos magra , y el pensamiento sistémico . [6]
La referencia principal para el marco ágil escala fue originalmente el desarrollo de un cuadro grande vista de cómo el trabajo fluyó de gestión de producto (u otros grupos de interés ), a través de la gobernabilidad , los programas y los equipos de desarrollo , a los clientes . [7] [8] Con la colaboración de otros miembros de la comunidad ágil, esto se perfeccionó progresivamente y luego se describió formalmente por primera vez en un libro de 2007. [9] El marco sigue desarrollándose y compartiéndose públicamente; con una academia y un esquema de acreditación que apoye a quienes buscan implementar, apoyar o capacitar a otros en la adopción de SAFe.
A partir de su primer lanzamiento en 2011, ya se han lanzado cinco versiones principales [10] mientras que la última edición, la versión 5.1, se lanzó en febrero de 2021. [11]
Si bien SAFe continúa siendo reconocido como el enfoque más común para escalar prácticas ágiles (al 30 por ciento y creciendo), [12] [13] [ página necesaria ] , [14] también ha recibido críticas por ser demasiado jerárquico e inflexible. [15]
Desafíos de escalar principios y prácticas ágiles
Hacer frente a horizontes de planificación más largos
Los equipos de desarrollo generalmente refinan su backlog hasta dos o tres iteraciones por delante, pero en organizaciones más grandes, el equipo de marketing de productos necesita planificar con mayor anticipación sus compromisos con el mercado y las discusiones con los clientes. [16] A menudo trabajarán con un nivel muy alto, una hoja de ruta de 12 a 18 meses, y luego planificarán en colaboración con los equipos durante tres meses de trabajo. [17] Los equipos de desarrollo todavía entrarán en el refinamiento detallado 2-3 iteraciones por delante, y solo entrarán en planes de tareas detallados para la próxima iteración. [18]
Mantenerse ágil en niveles abstractos de responsabilidad
Si bien los equipos de desarrollo tienen una serie de marcos que definen cómo deben ser ágiles, hay muy poco que describa esto para la administración. SAFe ofrece muchos de los mismos principios, como equipos multifuncionales, a los grupos que manejan los niveles más abstractos de responsabilidad y planificación (producto y cartera). [19] SAFe también ha sido criticado por agregar demasiadas prácticas dispares. [20]
Tratar con la autoridad delegada
En Scrum , se espera que el propietario del producto asuma la responsabilidad del ciclo de vida completo 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 quiere una vista de los trabajos pendientes de varios equipos, como la que proporciona un gerente de producto . [21] Aunque SAFe asume que el rol del propietario del producto se asienta con la gestión del producto, no obstante, ha sido criticado por separar a los propietarios del producto en la organización de desarrollo. [22]
Sincronización de entregables
Los marcos ágiles están diseñados para permitir que el equipo de desarrollo sea autónomo y libre para diseñar cómo funcionan. SAFe reconoce que, a la escala de muchas decenas o cientos de equipos de desarrollo, se vuelve cada vez más caótico que los equipos se autoorganicen por completo. [23] Por lo tanto, impone algunas limitaciones a esto, de modo que cuando los equipos están trabajando en el mismo producto, sus entregables pueden sincronizarse mejor para lanzarlos juntos, aunque esta ha sido un área en la que SAFe ha sido criticado. [21] [22]
Permitir tiempo para 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, para que los equipos puedan mejorar sus prácticas y estén listos para el siguiente incremento de planificación. Las ediciones anteriores de SAFe también diseñaron esto para ser 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 significaban que no se podía probar todo hasta el final. SAFe fue criticado por esto ya que representaba un elemento anti-ágil o en cascada, pero estaba en línea con incrementos ajustados de 90 días que suman 13 semanas, y si realiza sprints de dos semanas, necesita seis de ellos más una planificación de una semana o ciclo de endurecimiento. [24] Esto no se incluye en 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 principios lean y ágiles existentes, así como en la observación: [25]
- Adopte una visión económica
- Aplicar el pensamiento sistémico
- Suponga variabilidad; preservar opciones
- Cree incrementalmente con ciclos de aprendizaje integrados rápidos
- Basar los hitos en la evaluación objetiva de los sistemas de trabajo.
- Visualice y limite el trabajo en curso, reduzca el tamaño de los lotes y administre la longitud de las colas
- Aplicar cadencia (sincronización), sincronizar con la planificación multidominio
- Desbloquear la motivación intrínseca de los trabajadores del conocimiento
- Descentralizar la toma de decisiones
- Organízate en torno al valor
El marco SAFe
En SAFe versión 5.0, hay cuatro configuraciones: esencial, portafolio, solución grande y completa: [26]
- Essential SAFe es la configuración más básica. Describe los elementos más críticos necesarios y está destinado a proporcionar la mayoría de los beneficios del marco. Incluye el nivel de equipo y programa (que denomina trenes de liberación ágil o ART).
- Large Solution SAFe permite la coordinación y sincronización entre múltiples programas, pero sin las consideraciones de la cartera. En versiones anteriores de SAFe, este nivel se denominaba flujo de valor .
- Portfolio SAFe incluye preocupaciones por la dirección estratégica, el financiamiento de inversiones y el gobierno esbelto.
- Full SAFe combina los otros tres niveles.
Certificaciones
Scaled Agile proporciona certificaciones que cubren diferentes áreas y niveles de conocimiento. [27]
Ver también
- Scrum de Scrums
Referencias
- ^ 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.
- ^ 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 .
- ^ Linders, Ben (22 de enero de 2015). "Escalado ágil con el marco de entrega ágil disciplinado" . InfoQ . Consultado el 27 de noviembre de 2017 .
- ^ van Haaster, K (2014). Ágil en general: pasando de la paradoja al paradigma . Artículo inédito de la Universidad Charles Sturt.
- ^ "Preguntas frecuentes sobre permisos" . Ágil escalado . Consultado el 13 de julio de 2018 .
- ^ Rey, Michael (2017). "Sirviendo a los clientes federales con SAFe Concepts" (PDF) . La capacidad cuenta las actas de la conferencia .
- ^ Bridgwater, Adrian (7 de agosto de 2013). "Real Agile significa que todo el mundo es ágil" . Dr. Dobb's . Consultado el 27 de noviembre de 2017 .
- ^ Linders, Ben (28 de agosto de 2014). "Muerte por planificación en adopción ágil" . InfoQ . Consultado el 27 de noviembre de 2017 .
- ^ Leffingwell, Dean (2007). Escalado de la agilidad del software: mejores prácticas para grandes empresas . Addison-Wesley. ISBN 978-0321458193.
- ^ "Acerca de Scaled Agile Framework - Una breve historia de SAFe" . Escaló ágil Inc . Consultado el 12 de agosto de 2020 .
- ^ "Novedades de SAFe 5.1 Big Picture" . Escaló ágil Inc . Consultado el 10 de febrero de 2020 .
- ^ "Decimotercer Informe Anual del Estado Ágil" . Encuesta sobre el estado de Agile . CollabNet VersionOne. 2019 . Consultado el 27 de agosto de 2019 .
- ^ Enlace, 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 ciencia a empresa .
- ^ Baptista, Roberto (28 de enero de 2015). "Profissionais brasileiros eo interesse por treinamentos de especialização" . Computerworld Brasil . Consultado el 28 de enero de 2015 .
- ^ Schwaber, Ken (6 de agosto de 2013). "inseguro a cualquier velocidad" . Decirlo como es . Consultado el 11 de noviembre de 2017 .
- ^ Eklund, U; Olsson, H; Strøm, N. (2014). Desafíos industriales de escalar ágilmente en sistemas embebidos producidos en masa . Métodos ágiles. Desarrollo, refactorización, pruebas y estimación a gran escala . Springer International Publishing. ISBN 9783319143583.
- ^ Heusser, Matt (23 de septiembre de 2014). "Métodos de prueba ágiles para múltiples equipos" . SearchSoftwareQuality . Consultado el 27 de noviembre de 2017 .
- ^ Stettina, C; Horz, J (2015). "Gestión ágil de carteras: una perspectiva empírica de la práctica en uso". Revista Internacional de Gestión de Proyectos . 33 (1): 140-152. doi : 10.1016 / j.ijproman.2014.03.008 .
- ^ Laanti, M (2014). Características y principios de Scaled Agile . Talleres XP 2014 . Springer International Publishing.
- ^ Elssamadisy, Amr. "¿SAFe ha resuelto la gran tuerca de adopción ágil?" . InfoQ . Consultado el 11 de noviembre de 2017 .
- ^ a b Vaidya, A (2014). ¿DAD sabe mejor, es mejor hacer LeSS o simplemente estar SEGURO? Adaptación de prácticas ágiles de escalado a la empresa . Extracto de las actas de PNSQC 2014. págs. 8–9.
- ^ a b Maximini, Dominik (11 de septiembre de 2013). "Una mirada crítica sobre SAFe - Scrumorakel - Blog" . Scrum Oracle . Consultado el 27 de noviembre de 2017 .
- ^ Stafford, Jan (9 de diciembre de 2013). "Escalar el desarrollo ágil requiere prácticas definidas, dice el consultor" . SearchSoftwareQuality . Consultado el 27 de noviembre de 2017 .
- ^ Killick, Neil (21 de marzo de 2012). "El horror del marco ágil escalado" . Agile, Scrum, Kanban, Lean y todo lo que se encuentra en el medio . Consultado el 27 de noviembre de 2017 .
- ^ "Principios SAFe Lean-Agile" . Consultado el 19 de febrero de 2016 .
- ^ Rose, Doug (2018). Agilidad empresarial para principiantes . John Wiley e hijos. págs. 87–89. ISBN 9781119446095.
- ^ "Certificación" . Ágil escalado . Consultado el 19 de febrero de 2016 .
Otras lecturas
- Heusser, Matthew (17 de junio de 2015), Introducción al marco ágil escalado , CIO , págs. 1–2 - contiene una revisión de los pros y los contras de la metodología y concluye que es la mitad del camino hacia un sistema totalmente ágil.
- Leffingwell, Dean (2011), Prácticas de requisitos ajustados para equipos, programas y la empresa , Addison-Wesley Professional, ISBN 978-0321635846
- Linders, Ben (15 de enero de 2015), Lean and Agile Leadership with the Scaled Agile Framework (SAFe) , InfoQ
enlaces externos
- Página web oficial