La gente quiere ir con DevOps en lugar de Scrum porque quieren ser ágiles pero no pueden cambiar su organización. Muchas personas de la comunidad Agile con las que he interactuado piensan que DevOps solo se trata de herramientas para la entrega continua. Vamos a aprender por qué DevOps no se trata solo de herramientas para la canalización de entrega.
Scrum es solo un marco
Scrum es solo un marco simple para el desarrollo de productos complejos que se basa en valores y principios. Scrum no es una metodología prescriptiva que le dice cómo debe verse su proceso. Scrum está muy centrado en lo que sucede durante el Sprint. Scrum no le dirá cómo debería verse su proceso dentro del Sprint. Scrum es un marco aditivo, lo que significa que Scrum solo te dirá los conjuntos mínimos de lo que necesitas para usarlo. Al igual que cuando necesita instalar un software en su computadora, existe un requisito mínimo para la especificación de la computadora, pero no hay nada de malo en instalar el software en una computadora que esté por encima de la especificación mínima. Entonces, con esta premisa, no es ilegal agregar prácticas que mejoren el flujo de su entrega de valor dentro del Scrum Framework.
DevOps: Lean Thinking, Systems Thinking y Value Stream Mapping
DevOps comienza con el pensamiento sistémico y ve todo el flujo de valor en el sistema en lugar de enfocarse únicamente en la fase de desarrollo, analizando cómo el trabajo entra en el desarrollo (el flujo ascendente) y cómo los trabajos se entregan a los clientes (el flujo descendente). El pensamiento sistémico ve cómo todos los elementos interconectados del sistema se afectan entre sí. En un sistema complejo como una infraestructura corporativa, los elementos no funcionan de forma aislada. Hacer un cambio en un elemento afectará a otro elemento del sistema.
Un flujo de valor es cómo el procesamiento de las solicitudes de los clientes en un resultado tangible fluye de un elemento a otro en todo el sistema. Siempre que hay una solicitud, hay un flujo de valor en el sistema.
Además del pensamiento sistémico, DevOps también se basa en el pensamiento lean. El pensamiento Lean consiste en reducir el desperdicio en la cadena de valor. Cualquier actividad que no tenga valor agregado puede considerarse desperdicio. No voy a dar más detalles sobre Lean y tipos de desperdicio en este artículo.
El pensamiento Lean, el pensamiento sistémico y el mapeo de todo el flujo de valor son importantes y funcionan bien con Scrum porque Scrum se basa en el pensamiento Lean. Esto es lo que hago antes de comenzar Scrum en una gran corporación, ver todo el sistema de manera integral y mapear todo el flujo de valor en el sistema primero en lugar de solo aplicar Scrum al departamento de TI. Kanban es una buena herramienta para visualizar todo el flujo de valor en el sistema.
Cuando usamos Scrum y DevOps, todas las actividades en el flujo de valor, desde las solicitudes de los clientes y el lanzamiento del producto, hasta los entornos de producción y los clientes, ocurren dentro del Sprint. Esto no significa que un Sprint sea una mini cascada donde la implementación solo ocurre al final del Sprint o todo el análisis ocurre al comienzo del Sprint. Usar Scrum con Kanban ayuda a dejar de usar Sprint como mini cascada y avanzar hacia modelos basados en flujo de una sola pieza en el Sprint.
Scrum Team aplicando DevOps: la composición
Los equipos Scrum que adopten DevOps tendrán una forma de trabajo diferente a la de un equipo Scrum que no adopte DevOps. No solo su forma de trabajar es diferente, la composición del equipo también se ve muy diferente.
Scrum dice que el equipo de desarrollo está formado por profesionales que entregan los incrementos potencialmente liberables al final del Sprint. Dado que DevOps ve todo el flujo de valor y utiliza el pensamiento sistémico, los profesionales de Scrum Teams que adoptan DevOps son todos los que procesan el elemento de la lista de productos pendientes (PBI) en todo el flujo de valor de principio a fin. Mucha gente ve que el equipo de desarrollo solo está formado por desarrolladores, por eso muchos piensan que Scrum es solo para la fase de desarrollo.
En un equipo Scrum que adopta DevOps, la composición del equipo incluye a todos, entre otros, personal de marketing, analistas, diseñadores de UI / UX, desarrolladores, personal de operaciones, administradores de sistemas, científicos de datos e ingenieros de confiabilidad del sitio. Todos trabajan juntos de forma colaborativa como una sola unidad para ofrecer valor a sus clientes.
DevOps se trata más de cultura organizacional que de herramientas
Como puede ver, DevOps no se trata de herramientas y automatización en el proceso de entrega. De hecho, como hemos aprendido, las herramientas y la automatización son solo un tercio de DevOps (yo diría que es incluso menos). En general, DevOps se trata de colaboración y propiedad colectiva, se centra en el flujo de la entrega de valor y la cultura de aprendizaje y experimentación. Pero, lamentablemente, muchos proveedores de herramientas posicionan DevOps como herramientas y procesos para la canalización de entrega (los proveedores que he visto en mi mercado están más enfocados en herramientas, pero su experiencia puede ser diferente a la mía). Esto entusiasmará a la gerencia porque muchos gerentes a los que he conocido piensan que después de comprar e instalar las herramientas "DevOps" sin cambiar su organización, su empresa se volverá ágil al instante. Es como poner el carro delante del caballo.
