Llegamos a ustedes gracias a:



Reportajes y análisis

SAFe: Presentación del framework agile escalado

[09/07/2015] "El tamaño claramente importa. Probablemente no pueda ejecutar un Proyecto XP (Extreme Programing) con cien programadores. Tampoco con 50, ni con 20. 10 es definitivamente realizable... -Kent Beck, "Programación extrema explicada: adopte el cambio, 1ra edición [fecha de publicación: 2000].

En estos días, algunos equipos de software tienen cientos de programadores. Muchos de ellos están en proyectos de múltiples años y trabajan en programas que están en marcha -software que puede tener una vida de repisa o más de una década. Esos proyectos son complejos, al vuelo y sin un concepto fácil de realizar.

Las metodologías de desarrollo de software agile, en la que los individuos, las interacciones y equipos multifuncionales son valorados sobre procesos, documentación completa y planes grabados en piedra, no han sido otra cosa sino disruptivas para las grandes empresas acostumbradas a los controles ajustados en el desarrollo del software personalizado que deben ejecutar en sus negocios.

Ingrese a SAFe (Scaled Agile Framework), un framework diseñado para permitir a las grandes organizaciones moverse hacia una forma más ágil de trabajar. Por grandes queremos decir más de mil personas en TI, y más de 250 en desarrollo de software.

Reproducida con permiso de © 2011-2015 Scaled Agile, Inc. Todos los derechos reservados.
SAFe en una imagen

Dele un vistazo a la imagen de arriba. Llamada el "gran tablero dentro de la compañía, presenta todo el SAFe en una sola imagen. La visión de portafolio esboza la estrategia y la cadena de valor. El nivel de programa -donde 25-150 personas a la vez trabajan en un programa específico- está bien representado. Debajo del nivel de programa está el nivel de equipo. Históricamente, el scrum, la programación extrema y otros métodos ágiles tienden a enfocarse, y detenerse, en el nivel de equipo humano. SAFe presenta una sola vista unificada del trabajo para ejecutivos, permitiéndoles escarbar en busca de detalles, o escalar para ver tendencias y hacer análisis.

Un equipo en SAFe podría tener de 8 a 10 personas, con todo lo que necesiten para entregar software, de extremo a extremo: requisitos, codificación, evaluación y despliegue. Varios equipos crean lo que SAFe llama un entrenamiento de lanzamiento, el cual se organiza alrededor de un programa (más de eso, abajo). Ese es un proyecto simple, o al menos, un programa de proyectos. Tiene un elemento de línea simple en un presupuesto -la compañía está comprando una cosa específica. Este es el "pequeño proyecto" del cual hablan los ejecutivos. Un portafolio es una colección de estos programas, la cantidad total de dólares del presupuesto dentro de TI que irá a desarrollo de software. SAFe llama a esto "Program Portfolio Management", y sugiere que una oficina tiene la responsabilidad de la estrategia y el financiamiento de la inversión, así como la gestión y financiamiento de programa.

Todos a bordo del tren de lanzamiento

En términos de SAFe, el "Tren de lanzamiento es el equipo de equipos, típicamente de 50 a 125 personas. Como un tren real, el tren de lanzamiento funciona con un cronograma, enviando código a producción con un calendario (el cual describo más adelante como Incremento de Producto), típicamente cada 10 semanas. SAFe sugiere que las personas involucradas en un tren de lanzamiento estarán dedicadas a tiempo completo a ese tren de lanzamiento, sin importar la estructura de reporte.

El tren de lanzamiento soporta un programa de largo plazo que puede tener muchos equipos y proyectos dentro. El equipo se sincroniza, alineando los sprints (ejecución de iteraciones) y los lanzamientos, de modo que el código pueda ser desplegado al mismo tiempo para cada incremento. Las versiones más antiguas de SAFe sugieren un "sprint duro" (o dos), no para pruebas dentro de los equipos, sino para coordinar interfaces entre los equipos. Podría ser mejor pensar en el endurecimiento de los sprints como un paso de transición -algún programa nuevo que los equipos necesitan para hacer que el lanzamiento del tren sea exitoso.

La actividad de planeamiento de lanzamiento hace posible el progreso real.
SAFe

Cada equipo de lanzamiento (recuerde que son de 50 a 125 personas) se reúne una vez al comienzo de cada ciclo de lanzamiento para desarrollar los Objetivos de Incremento de Programa, y los objetivos a nivel de equipo que hacen posible los objetivos de incremento. La reunión típicamente es de dos días de duración. Además, para planear simplemente, la reunión tiene otros beneficios, como permitir al equipo tener una sensación de trabajo en grupo -para crear conversaciones cara a cara que hagan posible el progreso real. La reunión incluye representantes tanto del área de negocios como de tecnología; sobre la marcha del evento los dos grupos se fusionan y se alinean, -nuevamente- reduciendo la fricción y los errores por malos entendidos.

Después de la planificación, el equipo trabaja en el siguiente incremento de programa (PI), y un pequeño equipo debe dirigir o coordinar ese trabajo para tener éxito. SAFe llama a éste el equipo de gestión del lanzamiento, que típicamente está compuesto del Ingeniero del Tren de Lanzamiento (un rol técnico), Gerencia de Producto, y unos cuantos ejecutivos que no están comprometidos a ese programa a tiempo completo. También puede incluir gerentes de desarrollo, evaluadores senior, arquitectos y otros roles en el programa que podrían dar inputs. Este es el grupo que se comunica con grupos externos periódicamente, y toma medidas correctivas cuando hay problemas en el cronograma. SAFe sugiere que el grupo se reúna semanalmente.

SAFe
Un mal código no puede escalar

Una de las afirmaciones públicas de SAFe es que el "mal código no puede escalar". Para evitar el mal código, SAFE sugiere un puñado de prácticas que están orientadas más a la prevención que a las tradicionales pruebas. SAFe comienza con Arquitectura Agile, un elemento importante que está emergiendo en la arquitectura; pero la arquitectura del sistema debe evolucionar más allá de las funciones más nuevas, para hacer posible añadir esas funciones.

Esto incluye la integración continua, colocando la construcción del software y revisiones automáticas en cada check-in. SAFe recomienda hacer evaluaciones primero como filosofía, no solo como unidades de evaluación, sino también a nivel de especificación. Esta práctica de crear ejemplos concretos, bajar a los inputs y los resultados esperados como un solo equipo colaborativo completo es llamado Evaluación Impulsada por Aceptación (Acceptance Test Driven).

Desarrollo en SAFe

SAFe también incluye prácticas de programación extrema clásica como el trabajo en pares, no solo para programadores, sino para muchos roles, junto con refactoring (mejora del diseño del código existente) y propiedad colectiva. La propiedad colectiva de un código se hace más compleja con equipos múltiples, pero también significa que los equipos pueden hacer correcciones en lugar de crear un "ticket", o "hacer el trabajo" por otro equipo. Esto evita que el primer equipo sea bloqueado y tampoco crea problemas de prioridad para el equipo dos -ya que la prioridad del equipo uno y del bloqueador probablemente sea algo que el equipo dos desee tener.

A nivel de portafolio, SAFe busca esencialmente la capacidad de las organizaciones de TI para entregar, y quizás dar soporte/mantenimiento al software en funcionamiento. Las métricas que SAFe sugiere son cosas como compromiso de los empleados, satisfacción del cliente (estos pueden ser internos), agilidad, time-to-market, calidad y la capacidad para trabajar con socios fuera de la organización de software. Estos términos pueden parecer algo ligeros, o cualitativos, pero SAFe ofrece medios específicos, claramente medibles para cada uno de esos términos. Algunos de ellos, como calidad, claramente pueden ser "jugados" -la presencia de esas métricas no elimina la necesidad de gestionar el proceso. Además de estas medidas duras, SAFe sugiere cuadros para gestionar el proceso de un epic individual y un cuadro de barras que muestre el trabajo actual y futuro para comparar el progreso de múltiples epics a la vez.

Donde la mayor parte de organizaciones de desarrollo agile se enfocan en el nivel de equipo, en sprints o iteración, SAFe se enfoca en el programa, el cual puede ser de cinco a 15 equipos. El "sprint de nivel de programa" en SAFe es el Incremento de Programa (PI - Program Increment), antes conocido como el Potentially Shippable Increment (PSI). La meta del PI es cumplir con los objetivos de PI.

Ahora comencemos a ver las piezas de SAFe juntarse: el Planeamiento de Lanzamiento (Release Planning) define los objetivos para el Tren de Lanzamiento Agile, que son incorporados durante el Incremento de Programa.

La principal crítica al PI es la duración. Los ocho sprints de 12 semanas, o los cinco de dos semanas, deja un montón de tiempo entre lanzamientos para tener retroalimentación. Esto significa que el Tren de Lanzamiento se dirige hacia unos pocos lanzamientos grandes por año. La ex directora de Agile Conference, Johanna Rothman, y nueva autora del "Agile and Lean Program Management", sugiere que es posible tener pequeños batches aún en equipos de programas grandes. De la forma que lo propone, "Prefiero pequeños lanzamientos todos los días (si es posible), y mensuales si no son diarios".

¿Es SAFe el final o el principio?

En su entrada de blog del 2013 "UnSAFe a cualquier velocidad, Ken Schwaber afirma que SAFe es esencialmente el Rational Unified Process (RUP) renombrado como agile, y que después del fracaso de RUP en el mercado, la gente de RUP fue hacia agile. Dean Leffingwell, el autor principal de SAFe, fue vicepresidente senior en Rational Software Corporation (ahora una división de IBM), y muchos de los contribuyentes de SAFe tienen antecedentes en Rational o en IBM.

Una fuente de alto nivel sugirió que mientras que el Agile Software Movement salió de la práctica, el RUP, SAFe y otros métodos derivaron de la teoría en primer lugar, pero en lugar de basarse en lo que debería funcionar, se basaron en modelos. Sin embargo, al leer las descripciones de SAFe se tiene una impresión diferente. La mayoría de las piezas de SAFe son conocidas, prestadas de métodos actuales ágiles que funcionan. El paquete y la organización puede que sea nueva, pero la mayoría de las piezas de SAFe son prácticas con cierto éxito detrás de ellas. El argumento de que SAFe se deriva de la teoría tiene menos credibilidad que el argumento de que SAFe es un punto de transición vendido como la meta final.

Una ventaja de SAFe es cuán fácil es hacer la transición al mismo. Uno "solamente entrena a los implementadores clave, al grupo de liderazgo, gestión, y el equipo en unos cuantos días hará un cambio. La nueva estructura se puede acomodar a gerentes, directores, arquitectos, analistas y cualquier otro rol, sin necesidad de transiciones incómodas o cambios de trabajo.

Eso conduce a la preocupación de que SAFe es un paso transicional, solo el primero y el menos doloroso. En una organización en mejora continua, no quedan claros los pasos seis meses o un año después de la transición a SAFe. SAFe puede que sea un buen paso, y una mejora para una organización grande, pero el enfoque de plantilla solamente lo impulsará. Después de eso, las organizaciones necesitan averiguar qué mejoras deberían darse a continuación, y eso requiere un contexto. El coach de agile, Yves Honoulle, lo pone de esta forma: "para la mayoría de estos diría que SAFe va más allá cuando están listos para avanzar, pero no tan lejos como deberían. Con media docena de certificaciones, la Scaled Agile Academy pretende a ofrecer algo para todos.

SAFe ofrece gran diversidad de oportunidades para obtener una certificación. Brinda, desde cursos de dos días como SAFe Agilist (para gestión) y SAFe Practitioner (para gente que es un poco más metida en la práctica, hasta el programa de consultoría de cuatro días y luego el programa completo de consultor/entrenador.