¿Qué es SAFe?
Qué es ágil, muchos lo saben. Un número aún mayor de personas involucradas en TI utilizan la terminología. Más para escuchar sobre Agile.
No todos los que usan con confianza el término ágil para comunicación, crítica, para eso; Para presentar su equipo o compañía de una mejor manera, entienden, por ejemplo, cuál es la diferencia entre SCRUM y Agile; y a menudo ponen un signo igual entre estos dos conceptos diferentes. Pero no hace mucho tiempo, en 2015, también apareció SAFe. ¿Qué es y por qué se necesita?
Una de las ventajas y desventajas importantes de SCRUM, considero que el tamaño prescrito de los comandos es 7 + -2 (o 3-9 datos más recientes de la Guía Scrum ), incluido el propietario del producto.
Por supuesto, 9 profesionales de clase alta y bien motivados son capaces de mucho, pero a veces es necesario construir algo con una gran cantidad de manos, cabezas, ojos y cerebro al final. Inflar equipos es malo, por lo que es necesario aumentar su número, y aquí surge el problema de la comunicación entre equipos, la sincronización del trabajo y SCRUM en sí no ofrece ninguna solución para estas tareas. Hay intentos de usar SCRUM en el nivel de administración de comandos SCRUM (como Jeff Sutherland, uno de los autores del manifiesto Agile aconseja), hay Scrum de gran escala, hay entrega ágil disciplinada, hay mucho más, pero también hay SAFe - Scaled Agile Framework.
SAFe es un marco de gestión de la empresa que requiere la coordinación del trabajo en un determinado proyecto o proyectos relacionados para 5 o más equipos SCRUM. Es decir Esta es una superestructura sobre SCRUM que le permite administrar equipos de 100 o más personas
Beneficio?
En primer lugar, por supuesto, quienes la venden y participan en la capacitación necesitan la metodología. Dave Thomas (uno de los autores del manifiesto Agile) habló bastante bien sobre este tema en GOTO 2015 en su presentación Agile is Dead
En segundo lugar, los departamentos de gestión de programas. Aquellos que anteriormente estuvieron involucrados en la gestión de proyectos recibieron la certificación PMP, dibujaron diagramas de Gantt e implementaron el concepto de gestión hard-soft (con un lado suave para la administración y un lado duro para los artistas). El hecho es que en un SCRUM típico no hay función para ellos, en SAFe sí lo es. Lo mismo se aplica a todo tipo de arquitectos. En SCRUM no hay una función para ellos en SAFe, hay una carrera profesional.
Además, puede ser beneficioso para aquellos dueños de negocios donde los gerentes trabajan en grandes proyectos que devoran una gran cantidad de horas hombre y no pueden (a veces por razones objetivas) hacer que estos proyectos sean independientes.
Muchos desarrolladores con calificaciones inferiores al promedio a menudo para hacer algo, necesitan ser exponencialmente más que los profesionales más experimentados y motivados.
Toda la industria. Porque el número de desarrolladores se duplica cada 5 años (ver el futuro de la programación de tío bob ), cuya consecuencia es que en cualquier momento dado al menos la mitad de los desarrolladores tienen menos de 5 años de experiencia laboral. Si la tendencia no cambia, pero aparentemente no cambia, entonces se requieren procesos que prescriban y formalicen sus funciones de trabajo, mecanismos de interacción entre los participantes y todo el proceso.
Esencia
SAFe es un pastel de capas de varias técnicas ágiles. En el nivel inferior está el SCRUM casi tradicional, con carreras típicas de dos a tres semanas, equipos de 3-9 personas, incluido el propietario del producto. Todos los rituales típicos, que van desde la planificación diaria, de pie y terminando con un informe en retrospectiva. Aunque hay una diferencia clave. El comando deja de ser un módulo independiente totalmente funcional. Y el sprint deja de ser un período de tiempo independiente con un ciclo de vida completo. Los sprints se combinan en incrementos de programa que generalmente consisten en 5 sprints. Es decir si en SCRUM clásico no construimos lo que le gusta al cliente, entonces hacemos la corrección del curso en el próximo sprint, luego en SAFe continuamos avanzando hacia el borde hasta el final del Incremento del Programa, en el peor de los casos, los próximos 4 sprints (por supuesto, exageraré).
En el siguiente nivel, tenemos trenes, el llamado Tren de Liberación Ágil. Hay nuevas funciones para administrar 5 segmentos de sprint: un arquitecto de sistema (el propietario de la arquitectura, es decir, ya no es un equipo), el gerente de producto (el que controla el producto, no el propietario del producto, este último va a PM para obtener asesoramiento) y RTE - El mismo PMP del lejano mundo de la cascada. Aquí, se aplican algunos desarrollos de Kanban, en particular, un tablero, un método para asignar prioridades y, en general, el principio de medir el rendimiento histórico de los equipos (velocidad) y proyectar lo que se construirá al final del intervalo de tiempo en lugar del enfoque con estimaciones y la asignación de plazos para la funcionalidad ya fija ( alcance). Una de las innovaciones es que el último sprint de 5 se declara organizacional y durante el cual se llevan a cabo grandes reuniones (todos los equipos juntos, y esto es 100 o más personas), se lleva a cabo un análisis de la deuda técnica, se realizan planes para el desarrollo de la arquitectura y se sincroniza el trabajo de todos los equipos.
Por encima del nivel del tren, tenemos coordinación entre departamentos, directores y el cliente. Hay más préstamos de Lean Agile, pero se conservan las mismas herramientas de Kanban. Este es un análisis de la viabilidad económica del cambio. Idealmente, cualquier cambio pasa por un análisis preliminar donde se presenta una hipótesis medible sobre el próximo cambio (por ejemplo, si hacemos una tienda en línea desde el centro de datos a la nube, luego, aumentando rápidamente la capacidad en el pico de las ventas estacionales, podemos aumentar el número de transacciones en un 10%) y luego esta hipótesis se confirma no Para empresas de menos de mil millones de dólares, este puede ser el último piso. Aquí se crean planes de trabajo para 12-36 meses (hola planes de cinco años para calidad, cantidad, etc.)
Por encima del nivel de los sistemas grandes está la gestión de cartera. Los fondos se asignan a diversas áreas de negocio. Se utiliza la gestión de cartera ajustada, utilizando la estrategia de desarrollo de la compañía, se seleccionan las áreas de las que puede obtener un retorno. Aquí se toman decisiones sobre comprar o fusionarse con otras compañías. Creación de nuevas líneas de negocio, cierre de antiguas. El presupuesto se ajusta y reasigna regularmente (a diferencia de los planes trimestrales o anuales). Para cada componente de la cartera, se establece un conjunto de métricas más o menos estandarizadas y luego todas se evalúan de acuerdo con ellas. Además de los 3 niveles anteriores, hay rituales especiales para la sincronización cada dos semanas (generalmente): hay un intercambio de estados e indicadores clave.
Dirigido por toda la estrategia. La forma en que se define no se describe en el marco.
Pros
- Un número significativo de herramientas muy buenas (WSJF, Kanban, Gemba, etc.)
- Pasos formalizados y prescritos para SDLC a partir de escribir código (prescrito por TDD) para realizar escaneo estático y CI / CD y alternar funciones. Si cada una de las prácticas es buena o no es otra cuestión, pero al menos hay un plan y todos lo siguen.
- El proceso puede ser entendido, explicado e implementado.
- Cada persona en el marco de este proceso recibe una función bastante estrictamente definida.
- Aumenta la transparencia de la empresa para quienes trabajan en ella.
Desventajas
- Tiempo suficiente para responder a un desajuste de la realidad con las expectativas.
- Se gasta una gran cantidad de dinero y dinero en comunicación y reuniones
- A menudo, las soluciones recomendadas dentro del marco están desactualizadas
Para presentar o no? Creo que si hay una opción, entonces no, es mejor reducir la dependencia entre departamentos y proyectos. Y si no hay otra opción y necesita administrar un gran proyecto, entonces es muy posible.