En nuestras clases en directo y cursos de preparación para los programas de certificación DevOps, hemos observado que hay una pregunta que siempre surge. Hoy he preparado esta breve entrada para responderla. La pregunta es «¿Cuáles son las diferencias entre DevOps y Scrum?». También se conoce como «comparación entre DevOps y Scrum».
Artículos de International DevOps Certification Academy™
¿Cuáles son las 6 principales diferencias entre DevOps y Scrum? (Comparación entre DevOps y Scrum)
Hoy voy a repasar las 6 diferencias principales. ¡Vamos allá!
Diferencia 1: Con DevOps se despliega código en producción al final de cada iteración (sprint). Con Scrum, el objetivo es que al final de cada iteración haya código listo para entregar.
Este es uno de los principales inconvenientes de Scrum y uno de los motivos más importantes, si no el primero, por los que falla en muchas organizaciones. Si no despliega código al final de cada iteración, normalmente lo guarda en servidores de preproducción o, peor aún, lo deja en el sistema de control de versiones de código (CVS) hasta que un director de proyectos, que por lo general no sabe nada de ingeniería de software, decide cuándo debe pasar a producción. Conozco grandes bancos y empresas de telecomunicaciones que despliegan en producción cada 6 meses. Parece una broma, pero no lo es. Estos despliegues masivos les cuestan muchos incidentes de máxima prioridad y gravedad en producción, hacen caer la moral y llevan a más empleados a actualizar el currículum. Y eso sin mencionar los reproches ni las disputas políticas entre personas sin formación técnica que buscan a quién culpar por sus propios fallos.
Diferencia 2: Con DevOps, la automatización de pruebas y la integración continua, requisitos para la entrega continua de software, son parte esencial de las prácticas de desarrollo. Con Scrum, la entrega de software se deja para después y queda en manos de personas ajenas al desarrollo, que tienen que planificarla y ejecutarla.
Esta es otra de las debilidades más importantes de Scrum. El proceso de Scrum aporta muy poco o nada a las prácticas de entrega. En DevOps son imprescindibles la canalización de entrega, la automatización de pruebas y una arquitectura de producción que permita desplegar con un clic. El proceso de entrega de software con Scrum existe desde 1986. Hirotaka Takeuchi e Ikujiro Nonaka lo presentaron por primera vez en Harvard Business Review en un artículo titulado «New Product Development Game». Más de 30 años después de esa presentación, se ha avanzado mucho en la forma en que los equipos deberían abordar la entrega de software. Ahora tenemos DevOps para responder a preguntas que Scrum había dejado sin respuesta.
Diferencia 3: Con DevOps, los proyectos se centran en productos y servicios que aportan valor a la organización. Scrum no tiene la madurez necesaria para contribuir a los resultados del negocio.
DevOps considera que los equipos de ingeniería son unidades inteligentes que sacan adelante el trabajo y entregan productos y servicios de software funcionales para atender a los clientes y generar ingresos para la organización. Por desgracia, Scrum no enseña a quienes lo aplican nada sobre madurez empresarial. Si alguna vez pensó que esos rituales «incuestionables» de Scrum, como que no se nos permita sentarnos en la reunión diaria, parecen bien, pero que esos ingenieros tan cualificados y bien pagados se comportan como si estuvieran en un jardín de infancia y el Scrum Master como si fuera su maestro, se debe a que Scrum no les enseña a actuar como profesionales. Con DevOps, todos en una organización de ingeniería actúan como profesionales para aportar valor al negocio, con independencia de su experiencia y conocimientos. Así se evitan discusiones redundantes e inútiles sobre asuntos absurdos como si se permite sentarse en una reunión diaria. ¡Con DevOps, dedica el esfuerzo de proponer ideas a identificar y mejorar las mejores soluciones de software posibles para que su negocio gane más!
Diferencia 4: Con DevOps, todos los ingenieros del equipo se ocupan de la calidad del servicio y del software y de la excelencia operativa. Con Scrum, el aseguramiento de la calidad y las operaciones son tarea de otras personas.
En la mayoría de los equipos Scrum, el aseguramiento de la calidad del software queda en manos de quienes hacen pruebas externas al equipo. Los administradores de sistemas se encargan del despliegue y las operaciones. La desconexión de los equipos Scrum de la calidad de la entrega y de lo que le ocurre realmente al software en producción es otro de los principales motivos por los que muchas organizaciones que adoptaron Scrum tienen dificultades. En DevOps, el aseguramiento de la calidad es responsabilidad compartida de toda la organización de ingeniería de software. Los ingenieros de DevOps que dominan toda la pila tecnológica prestan atención a la entrega, la seguridad, la estabilidad, el rendimiento, la facilidad de mantenimiento, las operaciones y todos los demás aspectos no funcionales, desde la concepción hasta el fin del ciclo de vida del software. Estos equipos reúnen todas las habilidades necesarias para desarrollar y operar software y garantizar su calidad. Están preparados para tener éxito y aportar resultados extraordinarios al negocio.
Diferencia 5: DevOps orienta el diseño de la arquitectura para facilitar la calidad y la entrega continua. Scrum no ofrece orientación para crear software con una arquitectura adecuada.
Scrum no ofrece apoyo ni orientación a los equipos de ingeniería para definir una dirección y una visión arquitectónicas adecuadas. Recuerde que han pasado más de 30 años desde que Hirotaka Takeuchi e Ikujiro Nonaka presentaron Scrum. Con DevOps, los productos, servicios y API de microservicios de la arquitectura deben estar débilmente acoplados. Cada equipo debe responsabilizarse de una sola parte y poder diseñar, desarrollar y desplegar su software de forma independiente. Un mecanismo de alerta temprana incorporado en la canalización debe avisar de forma automática y rápida a los equipos de DevOps sobre los posibles efectos adversos de cualquier cambio registrado.
Diferencia 6: DevOps abarca toda la organización de ingeniería de software para obtener grandes resultados de negocio. Scrum se ocupa únicamente de los desarrolladores.
Scrum se centra en equipos de desarrollo pequeños, de 5 a 9 personas. Según la teoría de Scrum, no pueden ser 10. ¿Por qué? ¡No se sabe! En cualquier caso, este enfoque limitado de la ingeniería de software suele dificultar el encaje de Scrum en las organizaciones porque Scrum no resuelve cómo debe integrarse un equipo Scrum en una organización para aportar valor. DevOps propone formar equipos orientados a productos y servicios. Son equipos independientes, multifuncionales, autónomos, autosuficientes y generalmente pequeños que cubren todas las fases del ciclo de vida de ingeniería de un producto o servicio de software, en vez de las de un proyecto temporal. Abarcan la arquitectura, el diseño, la programación, las pruebas, la experimentación, el despliegue, las operaciones y el mantenimiento. Sí, ha leído bien. ¿Quién puede operar y mantener el software mejor que quienes lo crearon? Nadie. Por eso, no sorprende que los equipos de DevOps más exitosos de Amazon y Netflix no abandonen sus productos y servicios después de publicarlos. También se encargan de operar y mantener el software en sus propios sistemas de producción.
¡Después de leer estas diferencias, ya tendrá claro por qué DevOps se está convirtiendo en la próxima generación de la agilidad!
En unos años, se aceptará plenamente que DevOps abarca Scrum porque organizaciones muy grandes como Google, Amazon, Facebook, Etsy, Netflix y muchas otras ya han adoptado DevOps.
¡Eso significa que pronto llegará a todas partes!
International DevOps Certification Academy™ le ofrece todo lo que necesita para aprender DevOps con facilidad y aprobar el examen de certificación. Si tiene alguna pregunta, mi equipo y yo estaremos a su disposición, como siempre.
La mejor oferta para empezar (¡solo hoy!) >>
Acceda a International DevOps Certification Academy™ >>
P. D.: ¡Seamos sinceros por un momento! Sabemos que hoy no mucha gente lee entradas de blog. Aun así, insistimos en dedicar tiempo a preparar estos contenidos. Si un puñado de personas lee este artículo y aprende algo, consideramos que hemos cumplido nuestra misión de ayudar a la comunidad DevOps en todo el mundo.
¡Muestre su aprecio por el esfuerzo que dedicamos a escribir este artículo para usted! Si ha leído hasta aquí y el artículo le ha resultado útil, deje una opinión más abajo y compártalo con sus contactos.
¡GRACIAS DE ANTEMANO! :)
