• 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
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)
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
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
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
presionada a ofrecer de forma simultánea: • Respuestas rápidas a las necesidades urgentes del negocio • Proveer un servicio IT estable, seguro y predecible
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
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?
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
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.
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
el código y el ambiente • Usar el control de versiones para incluir cambios en configuraciones 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
y responder a las necesidades de los clientes, internos y externos • Reducir y amplificar todos los ciclos de feedback: detener el proceso si es necesario • Crear calidad desde el inicio
en sus líneas de ensamblaje para notificar 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"
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
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
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
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
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
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
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
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
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
yamilurbina
cbtlibrary
uranoken
tetsuyaooooo
pylapp
signer
lrm
bernhardsvt
masakiokuda
ponponmikankan
tmiket
michaelherold
hatefulcrawdad
sstephenson
caitiem20
reverentgeek
shpigford
kneath
bcantrill
addyosmani
mojombo
eileencodes
