DevOps + Agile - Speaker Deck

Slide 1

Slide 1 text

DevOps + Agile Agile Day La Paz 2017

Slide 2

Slide 2 text

Yamil Urbina CloudOps Engineer en Mojix @yamilurbina

Slide 3

Slide 3 text

Entonces, ¿Qué es DevOps?

Slide 4

Slide 4 text

DevOps en pocas líneas • Development + Operations = DevOps • Es un tipo de cultura que se concentra en incrementar la colaboración entre roles • Promueve la eliminación de silos entre equipos • Impulsa que los riesgos sean vistos como oportunidades • Construye calidad desde el inicio

Slide 5

Slide 5 text

Mmmm, ¿y porqué se deberia usar?

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Acto 1: IT arregla el problema

Slide 10

Slide 10 text

Acto 1: IT arregla el problema • Es un bug! • Alguna conﬁguración faltante o errónea • "Alguien manipuló componente X!" • El servidor sólo es manejado por IT o cierta persona

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

Acto 2: Los product managers

Slide 13

Slide 13 text

Acto 2: Los product managers • "Tenemos un sprint por terminar!" • Arreglar el problema a como dé lugar, luego revisamos las causas • Se ignoran problemas que no sean bugs o errores de los desarrolladores • Nosotros (Devs) vs. ellos (IT, Ops)

Slide 14

Slide 14 text

Acto 3: Los desarrolladores

Slide 15

Slide 15 text

Acto 3: Los desarrolladores • Se toman atajos para completar tareas, el código se torna más frágil • Se incrementa el backlog de tareas que podrían mejorar la aplicación • Se prioritizan las tareas prometidas al cliente • La deuda técnica comienza a acumularse... • ...y vendrá con intereses

Slide 16

Slide 16 text

Acto 4: Dev vs. IT Ops

Slide 17

Slide 17 text

Acto 4: Dev vs. IT Ops • Se necesita coordinar actualizaciones con el cliente y con todo el equipo • Las actualizaciones toman mucho tiempo y se hace en horas donde la aplicación no tenga uso • La tensión incrementa entre IT y desarrollo • Las actualizaciones o el arreglo de bugs no son parte del sprint o tienen estimaciones mínimas

Slide 18

Slide 18 text

Acto 5: Frustración • El producto es frágil y tiende a fallar • El tiempo se invierte en apagar incendios • El trabajo planeado no se puede completar • Constantes emergencias y trabajo reactivo • Las tareas comienzan a perder visibilidad • Restaurar la aplicación toma demasiado tiempo

Slide 19

Slide 19 text

El conﬂicto central de IT • Cada organización IT esta presionada a ofrecer de forma simultánea: • Respuestas rápidas a las necesidades urgentes del negocio • Proveer un servicio IT estable, seguro y predecible

Slide 20

Slide 20 text

Cada compañia es una compañia IT... • 95% de las organizaciones tienen un área o componente IT • 50% del presupuesto se usa en gastos relacionados a tecnología • IT usualmente termina como un área burocrática, de difícil manejo y con varios cuellos de botella para la organización

Slide 21

Slide 21 text

Agile para IT

Slide 22

Slide 22 text

¿Puede IT implementar Agile? • Proveer soporte es reactivo y volátil • IT usualmente atiende los incendios que aparezcan durante el día • No se considera al trabajo de IT como parte del proceso Agile • ¿Cómo habilitar sprints con SCRUM para tareas reactivas?

Slide 23

Slide 23 text

Debe existir una mejor manera...

Slide 24

Slide 24 text

Deﬁniciones • IT: Information Technology - todos los aspectos que lleven el manejo y el proceso de la información • Operaciones: El manejo, monitoreo y operación continua de uno o varios productos

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Ops que piensen como devs Devs que piensen como Ops

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Las 3 maneras para implementar DevOps

Slide 30

Slide 30 text

La primera manera: el flujo del sistema (de izquierda a derecha) • Entender el flujo de trabajo • Siempre buscar mejorar la rapidez del flujo • No ignorar los defectos y pasarlos al siguiente proceso • Obtener una apreciación general del sistema

Slide 31

Slide 31 text

Práctica #1: Deﬁnir el trabajo y hacerlo visible • Projectos de negocio: sitios o aplicaciones web para el cliente o el producto en general • Proyectos internos: automatizaciones, probar nuevas herramientas, etc. • Cambios: actualizaciones, mejoras a servidores o bases de datos, etc. • Trabajo no planeado: sitio abajo, hackeos, errores en producción, etc.

Slide 32

Slide 32 text

Práctica #2: Crear procesos de conﬁguración de ambientes • Hacer que los ambientes sean consistentes desde el inicio de un proyecto • Asegurarse que Dev ejecute código en un ambiente de fácil reproducción • Utilizar el mismo ambiente en Dev, QA y Producción

Slide 33

Slide 33 text

Cambiar la política del Sprint Agile: "Al ﬁnal de cada sprint, debemos tener código funcional y también el ambiente en el que corre"

Slide 34

Slide 34 text

La primera manera: resultados • Crear un repositorio compartido para el código y el ambiente • Usar el control de versiones para incluir cambios en conﬁguraciones y componentes del ambiente • Contruir ambientes para Dev, QA, Staging y otros usos que sean consistentes, mucho antes que las pruebas inicien • Reducir los tiempos de actualización • Aumentar la cadencia y agilidad al probar código

Slide 35

Slide 35 text

La segunda manera: Ampliﬁcar los ciclos de feedback • Entender y responder a las necesidades de los clientes, internos y externos • Reducir y ampliﬁcar todos los ciclos de feedback: detener el proceso si es necesario • Crear calidad desde el inicio

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

El cordón Andon de Toyota • Toyota implementó esta señal en sus líneas de ensamblaje para notiﬁcar a toda la planta de defectos o anomalías encontrados durante el ensamblado de sus autos • Jalar el cordón detiene todas las actividades en la planta para concentrarse en resolver y aprender del problema encontrado • Parte de la cultura "Toyota Kata"

Slide 38

Slide 38 text

Resolución del problema • Un líder de equipo visita la planta y pide ver el problema • Se describe el problema y sus posibles causas • Se validan las posibles causas hasta encontrar la razón de la falla • Toda acción se documenta y la solución es aplicada y distribuida a otras plantas para evitar problemas similares • Se reinicia todo el proceso de ensamblaje

Slide 39

Slide 39 text

Práctica #3: Incluir Dev dentro de IT Ops • Incluir a Dev dentro del proceso de resolución de incidentes • Invitar a Dev al análisis y resolución de problemas en sistemas de producción • Comenzar a incluir prácticas de seguridad y desarrollo dentro de IT • Agregar métricas o mensajes que ayuden a la resolución de problemas e incidentes

Slide 40

Slide 40 text

La segunda manera: resultados • Crear user stories para IT y Dev que sean parte de cada sprint Agile y consideren el tiempo necesario para resolver problemas e incidentes • Los defectos y problemas de seguridad se arreglan más rápido • Implementar controles de calidad desde que el desarrollador libera código

Slide 41

Slide 41 text

La tercera manera: una cultura que aliente la experimentación y los riesgos • Cultivar una cultura que aprecie: • La experimentación, tomar riesgos y aprender de fallas y errores humanos • La repetición como prerequisito para dominar ciertas áreas • Mantener la presión en problemas y errores • Tener hábitos que manejen desastres y mantengan la calma ante éstos

Slide 42

Slide 42 text

Práctica #4: Romper cosas seguido y desde el inicio • Practicar acciones destructivas de manera más frecuente para que no sean un problema más adelante • Borrar la BD, eliminar un servidor, simular carga, etc. • Crea stories que mejoren la aplicación ante estos problemas • Dev y Ops no entrarán en crisis durante un incidente, porque ya se conocen ciertos escenarios

Slide 43

Slide 43 text

Práctica #5: Reserva el 20% del sprint a reducir la deuda técnica • Toda aplicación tiene deuda técnica y es importante reconocer las mejoras que necesitan hacerse • Evitar encontrar responsables por código mal implementado, promover una cultura de mejora continua • Una mejora mal implementada puede convertirse en más deuda técnica, reconocer esto y eliminar la iniciativa

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

Una cultura que adopta la innovación • Reserva tiempo para escuchar las ideas de Devs y Ops • Examina cada idea y decide si merecen experimentación • No todas las ideas obtendrán resultados pero es posible aprender de éstas

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Algunos errores cometidos por los product managers • Moverse a DevOps sin preparar a todos los equipos • Asignar el rol de "DevOps Engineer" a cierta persona o personas • Olvidar la seguridad dentro de la cultura • Tratar de encajar las tareas DevOps en el sprint de desarrollo

Slide 49

Slide 49 text

Algunos errores cometidos por los product managers • Asignar toda la experimentación y soporte a los "DevOps" • Establecer rangos de tiempo para la experimentación y la mejora continua • Ignorar el testeo automatizado y el feedback dentro del proceso de desarrollo

Slide 50

Slide 50 text

Libro recomendado • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win "Mejorar en el trabajo diario es aún más importante que hacer el trabajo diario" — Gene Kim