¿Qué es DevOps?

Para algunos, DevOps tiene que ver con la cultura, para otros es una metodología de desarrollo de software en sí misma. Aunque siempre habrá discusiones y definiciones favoritas, en general DevOps ha llegado a englobar una filosofía que hace hincapié en la comunicación, la colaboración y la cooperación entre los desarrolladores de software y las demás partes interesadas del sector de las tecnologías de la información.

¿Por qué DevOps?

En general, se reconoce que el desarrollo real de software, la garantía de calidad y las operaciones de IT son interdependientes y que es necesario garantizar que estas funciones (tradicionalmente siempre independientes desde el punto de vista funcional) trabajen como una sola para garantizar la entrega rápida de productos o servicios que cumplan las normas del sector. Por ello, los conceptos de integración continua (para los desarrolladores), automatización (QA) y entrega continua (operaciones de TI) se han hecho cada vez más populares. Sin embargo, el objetivo sigue siendo el mismo: entregar al usuario final un sistema estable y rico en funciones.

DevOps ha llegado a ser reconocido por incorporar todo un conjunto de herramientas y tecnologías que integran perfectamente el ciclo de vida de la aplicación o del desarrollo de software, desde la especificación hasta el diseño, pasando por el desarrollo, las pruebas y el despliegue. Si se implementan e integran correctamente, estas herramientas permiten la creación continua, la integración continua, las pruebas continuas y el despliegue continuo. Así, DevOps permite el despliegue incremental y continuo de pequeños cambios y actualizaciones de productos y sitios web con un tiempo de inactividad mínimo o nulo. En el mundo actual de la entrega y el consumo de aplicaciones basadas en SaaS, DevOps se ha convertido en un factor de éxito crítico para que los proveedores de tecnología entreguen nuevas características de productos, correcciones de defectos y actualizaciones de rendimiento y seguridad casi en tiempo real.

¿Por qué Kanban para DevOps?

La principal ventaja de Kanban es que anima a los equipos a centrarse en mejorar el flujo del sistema. A medida que los equipos adoptan Kanban, se vuelven buenos en la entrega continua del trabajo que han completado. Por lo tanto, Kanban facilita la realización de lanzamientos de productos incrementales con pequeños trozos de nueva funcionalidad o correcciones de defectos. Esta característica de Kanban hace que se adapte bien a los requisitos de entrega y despliegue continuos de DevOps.

La otra gran ventaja de Kanban es que permite visualizar todo el flujo de valor y garantizar un flujo estable. Le ayuda a combinar los flujos de trabajo de diferentes funciones y actividades, desde el desarrollo hasta la integración/construcción, la prueba, el despliegue y, más allá, la supervisión de la aplicación. Inicialmente, ayudará a sus equipos de desarrollo y operaciones a trabajar de forma colaborativa. Con el tiempo, puede evolucionar hacia un único equipo y un único flujo de trabajo que incluya todas las actividades de desarrollo y operaciones. Kanban le proporciona visibilidad a todo este proceso – y la transformación a una cultura DevOps.

Esta visibilidad garantiza que todo el mundo conozca las etapas por las que debe pasar un elemento de trabajo para que se considere «Hecho y con éxito», lo que tiene notables ventajas –

• Identificar lo que hay que arreglar – el mapeo de su flujo de trabajo le muestra lo que hay que arreglar primero con los procesos que sigue. De hecho, con Kanban, empieza con lo que está haciendo actualmente y luego trata de mejorar continuamente

• Prioridades – Las partes interesadas saben qué elementos de trabajo tienen prioridad con sólo echar un vistazo al «tablero». Así se garantiza que el trabajo correcto/importante se extraiga después de tener en cuenta cómo afecta a la estabilidad general del sistema (elegir el correcto garantiza que se introduzcan las mínimas fricciones). Esto también garantiza que todos los equipos, incluidos los clientes internos, sepan lo que está en consonancia con los objetivos de la empresa.

• El trabajo bloqueado se nota inmediatamente – si hay una dependencia o un problema, los responsables de la toma de decisiones pueden intervenir inmediatamente y averiguar qué hacer a continuación – no hay coste de retroalimentación retrasada
• El sistema «pull» – Kanban le anima a «dejar de empezar y empezar a terminar» – asegura que usted dedica su tiempo a un número mínimo posible de elementos de trabajo a la vez, reduciendo así el cambio frecuente de contexto y la pérdida de productividad. Esto también asegura que el flujo es constante – cuando estás atascado en una tarea, no hay nada que impida a otros tirar de nuevo trabajo es decir, el sistema general es estable
• Automatización – el tablero muestra cómo fluye el trabajo, dónde están los cuellos de botella y cuál es el tiempo de ciclo; en efecto, muestra dónde puede ayudar la automatización y qué debe mejorarse

Kanban no puede sustituir a la estrategia y la intención: es necesario contar con desarrolladores que estén dispuestos a realizar partes de control de calidad y a entender cuántos cambios pueden introducir en el sistema sin interrumpir el flujo, y es necesario que el equipo de operaciones entienda para qué cambios (características) hay que prepararse para garantizar la estabilidad. Sin embargo, puede ayudar en ambos casos: cuando todo el mundo está de acuerdo (literalmente), hay menos tensión y se garantiza que todas las funciones (y personas) sean más eficaces y sepan exactamente lo que hay que hacer.

¿Por qué no Scrum?

Mientras que Scrum puede y funciona bien en entornos de entrega donde la necesidad de entregar puede no ser verdaderamente «continua» (después de todo, usted está trabajando con un mínimo de un ciclo de sprint de 2-3 semanas), la propia naturaleza de Kanban hace que sea más adecuado. Si usted mira la mayoría de las implementaciones de DevOps en el campo – usted encontrará que es difícil de encajar en un sprint estándar. Kanban es más bien pull que push, y el concepto de flujo que constituye su base encaja bastante bien con DevOps. Además, la entrega continua y Kanban funcionan bien juntos: ambos son sistemas «justo a tiempo» que se centran en hacer una cosa bien a la vez (¡la mayor parte del tiempo!). Y, por supuesto, la flexibilidad que aporta Kanban es una ventaja añadida.

¿Cómo se empieza?

• Su equipo de desarrollo puede seguir su propio trabajo en un tablero Kanban separado. Para los fundamentos de un tablero Kanban lee nuestro artículo sobre Tableros Kanban

• Ops puede tener sus propios tableros que giran en torno a la automatización, la producción y el soporte que tienen elementos de trabajo de la forma ‘Mantenimiento’, ‘Implementación’, ‘Soporte de escritorio/servidor’ entre otros
• u flujo de valor general debe ser rastreado en un tablero Kanban separado donde Dev y Ops tienen sus propios carriles. (Consulte nuestra página sobre portfolio kanban para obtener detalles sobre cómo configurar y utilizar tableros jerárquicos).

• No sugeriríamos aplicar DevOps a nivel de historia de usuario. Lo que sea que defina como su MMF (característica mínima comercializable) o Epic, o Release (cualquier unidad realmente) probablemente debería ser WIP limitado, no historias individuales. Es posiblemente la única manera sensata y más fácil de ayudar a mapear y gestionar todo el flujo de valor.

¿Ha adoptado ya DevOps? ¿Está evaluando el uso de Kanban para sus equipos de DevOps? Utilizando SwiftKanban y nuestro producto de integración SwiftSync, podemos ayudarle a poner en marcha su solución DevOps en muy poco tiempo. ¡Simplemente escríbanos a [email protected] o regístrese para una prueba gratuita! Si desea que trabajemos con usted para desarrollar su propia solución DevOps, sólo tiene que decírnoslo.

Si ya está utilizando SwiftKanban y necesita ayuda con la configuración de sus tableros Kanban, póngase en contacto con nosotros en [email protected]