Si no entiende qué es DevOps, aquí tiene un breve resumen. DevOps es un conjunto de prácticas que reducen los temores de los ingenieros y disminuyen el número de fallos en la producción de software. Por lo general, también acortan el tiempo de lanzamiento al mercado — el periodo desde la idea hasta la entrega del producto final a los clientes, lo que permite realizar rápidamente experimentos comerciales..
¿Cómo comenzar una transformación DevOps? En resumen: elegimos el servicio con el que comenzaremos el proceso, identificamos a quienes están relacionados con el servicio, construimos un mapa de flujo de valor, creamos un equipo temporal que se encargará de la transformación al principio y le asignamos tareas. Repetimos el ciclo tantas veces como sea necesario.
Un plan detallado de la transformación DevOps con ejemplos e instrucciones se encuentra en la descripción Andrey Aleksandrov — del ingeniero en la empresa Express42, que asesora sobre el crecimiento de DevOps, acelerando este proceso porque ya ha construido un mapa de los obstáculos. Si cree que la transformación no es necesaria o si su especificidad hace que las prácticas de DevOps no sean adecuadas, utilice el informe como una guía para identificar y eliminar limitaciones.
Si le preocupa la transformación DevOps, entonces tiene una gran empresa y necesita escalar este proceso gradualmente en toda la estructura. Mientras exista la necesidad de transformar un equipo o eliminar alguna limitación, el algoritmo a continuación se puede repetir.
Selección del servicio
Se ha delineado un plan, comenzamos con el primer paso: la elección del servicio. El primer criterio es la vida útil: hay servicios antiguos — legacy, y nuevos. Se puede comenzar tanto con unos como con otros.
Elegir un servicio joven tiene sentido: es nuevo, aún no hay un proceso de trabajo establecido en el equipo que se encarga de él. No hay una gran carga técnica a su alrededor; no necesitamos repararlo todo el tiempo. Podemos hacer con él todo lo que queramos.
En el caso de un servicio antiguo, existen problemas relacionados con el hecho de que cambiar siempre es difícil.Ya hay un conjunto de limitaciones serias, pero, quizás, hay personas involucradas que están dispuestas a hacer cambios — están cansadas y quieren hacer las cosas de manera diferente porque les duele.
Trabajar con un servicio antiguo crea un poderoso precedente en su empresa — se puede cambiar algo. Si ha modificado un servicio nuevo, se lanza a producción 100 veces por hora, y todo va bien, entonces las personas en su empresa pueden decir:
— ¡Es un nuevo servicio! Todo era fácil, intenten hacer algo con nuestro cachivache.
Un servicio legado tiene sentido transformarlo cuando lo haces con alguien, por ejemplo, si has invitado a un consultor externo. Seamos sinceros, la transformación va a desafiar todo lo que se pueda.. Estás experimentando y no sabes a dónde llegarás, qué tecnologías y para qué vas a usar, dónde y qué obstáculos surgirán en los procesos. Por lo tanto, es más fácil cambiar a uno nuevo.
Si lo haces todo tú mismo y la empresa no tiene competencias serias, opta por el nuevo servicio. Si conoces a un consultor externo y tienes recursos, elige el antiguo.
Hay servicios que son solo una interfaz para los usuarios, como un sitio sencillo o una aplicación móvil. Pero hay cuestiones serias como la facturación. Si algo sale mal con la facturación, será complicado solucionarlo. Aquí también tenemos opciones.
Trabajamos ya sea con un servicio crítico, pero ya estamos sufriendo por él, crea limitaciones, o trabajamos con la interfaz. Este es el segundo criterio de elección. De manera similar, hay la posibilidad de atraer a un consultor experimentado; trabajamos con la opción más complicada.
Pero incluso en este caso, no recomendaría hacerlo, porque, hasta que no se entienda con qué trabajar y hacia dónde transformar, tomar algo crítico y reorganizarlo no es una buena idea. Por lo tanto, en este caso preferimos trabajar con la interfaz, cuya falla no es crítica.
A continuación, examinaremos el equipo del servicio. Con aquellos que manejan este servicio, tendremos que trabajar constantemente y colaborar en contacto muy estrecho.
Las personas en el equipo se dividen, en términos generales, en dos categorías: conservadores — viven en el viejo mundo, o simplemente no saben nada sobre DevOps, y innovadores, que traen todas las prácticas modernas. Los segundos no siempre entienden el tema, pero al menos están dispuestos a ello.
Por un lado, los conservadores son personas experimentadas: llevan mucho tiempo en la empresa, conocen todo al detalle, pero no saben sobre las prácticas. Por el otro lado, los innovadores, que han oído algo, pero probablemente no han estado en la empresa tanto tiempo. ¿Con quién es mejor trabajar?
Con los conservadores hay que interactuar de todos modos, ya que es su servicio. Tendremos que comunicarnos con ellos, aclarar la especificidad del servicio, qué se puede hacer de esta manera y qué de otra. Dependemos de sus consultas. Seguramente habrá que encargarles algo, porque ellos conocen su servicio mejor. Por eso, es importante con qué equipo finalmente tendremos contacto.
Es lógico elegir a innovadores para el equipo, porque los conservadores pueden poner obstáculos.
En la práctica, a menudo sucede que las personas conservadoras tienen una experiencia significativa, pero no comprenden cómo avanzar. Simplemente tienen miedo de que, después de la transformación y renovación del servicio, serán despedidos por no ser necesarios. A veces, simplemente por no entender lo que está sucediendo, sabotean el trabajo.
Tuve un caso en el que un chico del equipo reparaba cualquier cosa, porque supuestamente era más crítico que lo que estábamos haciendo en ese momento. Establecemos una tarea: implementar esta parte hoy; no, en el otro extremo del mundo hay un incendio, vamos a repararlo. Trabajar con tales personas es complicado.
Las personas del equipo conservador a menudo ignoran las tareas o las posponen hasta el último momento. Y si, Dios no lo quiera, cometiste un error y les pusiste KPI por la cantidad de tareas completadas, y alguna parte no está incluida en el KPI por alguna razón, entonces no harán nada. En realidad, tendrían razón, porque entonces perderían su bonificación.
Con los innovadores es más fácil, son más leales.Ya han escuchado algo, quieren avanzar, así que ayudarán. Necesitamos personas que estén dispuestas a sufrir un poco al principio: si el servicio cambia, los innovadores serán los que soporten las dificultades como pioneros. Los innovadores quieren lo más nuevo y moderno, y están dispuestos a afrontar las dificultades.
Los conservadores se pueden convertir en creyentes más tarde. Cuando muestres que has cambiado una parte y todo funciona bien, lo más probable es que también quieran probar y acepten la nueva religión DevOps.
En resumen. Si estamos haciendo toda la transformación en nuestra empresa nosotros mismos, entonces elegimos: un nuevo servicio, preferiblemente con una interfaz simple, para no sufrir demasiado por su fallo, y un equipo de innovadores.
Si hay posibilidad de llamar a un consultor externo, en lugar de uno nuevo, tomamos el viejo servicio, del cual ya estamos sufriendo. Las personas que han estado en la transformación durante un tiempo en diferentes compañías han visto varios casos y ya entienden cómo hacer las cosas correctamente y hacia dónde deben dirigirse.
¿Quién está involucrado?
Necesitamos encontrar a todos los que tengan alguna relación con el servicio: desarrolladores, testers, administradores, expertos en seguridad, gerentes y, posiblemente, Product Owners. A pesar de que los Product Owners no son técnicos, tienen relación con el servicio: toman decisiones y establecen tareas.
Todos los que tomen alguna decisión e influyan en lo que sucede con el servicio deben ser encontrados, presentados y comunicados.
¿Para qué los necesitamos? Para saber con quién negociar.Durante la transformación, cuando se cambia el principio habitual de trabajar con el servicio, habrá una serie de problemas. Habrá fallas durante un tiempo mientras probamos nuevos enfoques. La gente debe estar preparada para esto y estar de acuerdo.
Luego, tendremos que construir un Value Stream Map y no podrás hacerlo sin estas personas, porque solo ellos conocen toda la imagen de lo que está sucediendo. Una persona nunca sabe todo lo que ocurre con el servicio.
Ellos aconsejarán a personas para el equipo. Más tarde discutiremos por qué se necesita un equipo separado. Tendremos que incluir a personas de los departamentos existentes. Aquellos que tienen relación con el servicio podrán recomendar colegas que piensen en nuestra dirección, que puedan ayudarnos y que tengan competencia en lo que necesitamos.
Luego, reunimos a todas estas personas de diferentes departamentos en una sala y comenzamos a construir el Value Stream Map.
Construimos el Value Stream Map.
El Value Stream Map es un esquema o mapa que muestra el flujo de valores al cliente.Es todo el proceso desde la generación de la idea hasta su implementación, incluyendo todos los pasos intermedios y cómo el valor finalmente llega a nuestros clientes.
El Value Stream Map es necesario para visualizar todas las etapas del desarrollo,localizar problemas a través de las medidas que existen en el proceso actual y comenzar a eliminarlos, y establecer un objetivo inicial.Este es el lugar donde comenzaremos a hacer algo de verdad.
Métricas
En la literatura sobre Value Stream Map se describen muchas métricas diferentes, pero para empezar, solo necesitamos tres.
Lead Time — retraso/espera. — el tiempo que esperamos. Por ejemplo, un probador espera a que se libere un stand para las pruebas, y durante ese tiempo no puede hacer nada.
Tiempo de Valor Añadido — tiempo de trabajo útil — el tiempo que gastamos en una etapa determinada para crear valor final para el usuario. Por ejemplo, un probador ejecuta su prueba y comienza a verificar algo. Este es el tiempo de trabajo útil, cuando realmente estamos haciendo algo por el producto. Esto es por lo que los clientes pagan: por software de calidad.
%C/A — porcentaje de trabajo aceptado. Tenemos una etapa — desarrollo, la segunda etapa — pruebas. Cuántas características aceptaron los probadores de los desarrolladores, y existe este porcentaje.
Así es como se ve nuestro mapa.
Puede verse de manera diferente dependiendo de la estructura de la organización, la cantidad de departamentos y lo que hagas. Pero en general, en el mapa habrá dos etapas: idea y análisis. En esta etapa se esperan datos, por ejemplo, Lead Time 2 semanas y Tiempo de Valor Añadido 2 días.
Cubrir métricas en todas las etapas.
Backlog — cuántas tareas quedaron después de que los analistas las idearon.
Desarrollo — cuántas semanas los desarrolladores esperaron aclaraciones sobre tareas, stands o equipos — no importa, pero estaban esperando algo. Por ejemplo, 4 días implementan una característica. Aquí aparece la métrica %C/A. Los desarrolladores tomaron del Backlog solo el 80% de las tareas. Ellos consideran que las otras 20% no tienen un Término de Referencia suficientemente claro, y las enviaron para revisión.
Pruebas. En el esquema, LT está asignado 4 días. Por ejemplo, los probadores esperaban la liberación del stand de prueba, VA 2 días realmente están probando algo, y %C/A = 40 %. — solo el 40 % del código o características que enviaron los desarrolladores fueron considerados adecuados por los probadores. Todo lo demás no les gustó por alguna razón.
No entraré en detalle sobre cómo realizar estas mediciones; al final del artículo recomendaremos literatura de la cual se puede aprender sobre ellas.
Lo único que recomendaré es que no confíen en las personas que elaborarán el mapa de flujo de valor con ustedes. Ellos representan cuánto tiempo consumen diferentes procesos, pero estas estimaciones no siempre son precisas, por lo que es mejor medirlo uno mismo.
Tuvimos un caso en el que fuimos al departamento de Operaciones y preguntamos cuánto tiempo lleva implementar una nueva característica en producción. Nos respondieron que 10 minutos, y pensamos: ¿por qué venimos a esta empresa? Resultó que 10 minutos es el tiempo que toma el script que toma el código y lo envía al servidor. Pero antes de eso, la versión permanece tres días en el servidor sin hacer nada; hay una tarea en el Backlog que necesita ser desplegada. Entonces, hay una etapa de espera antes de la etapa de despliegue, donde el proyecto simplemente queda estancado. Si no hubiéramos ido con un cuaderno, no hubiéramos notado la tarea en Jira y no hubiéramos empezado a hacer seguimiento, pensaríamos que todo está bien y que no hay problema.
Por lo tanto, tendrás que realizar las mediciones tú mismo, preferiblemente más de una vez, para tener una idea más cercana a la realidad. Dependiendo del Value Stream Map, tomarás decisiones sobre desde dónde comenzar y qué corregir primero.
Equipo temporal
Muchas empresas que han decidido implementar DevOps crean un equipo, pero no uno temporal, sino uno que existe desde hace varios años. Si consultaras un servicio de DevOps que describe diferentes patrones de estructura organizacional en DevOps, entenderías que esto es un antipatrón.
Cuando un equipo de DevOps existe de manera constante durante varios años, es un gran error, porque DevOps se trata de la comunicación entre departamentos, de rapidez y eficacia.
Si el equipo existe entre departamentos solo para hacer algo separado y dura mucho tiempo, crea una barrera innecesaria. Ahora, en lugar de que el programador vaya directamente al administrador para resolver un problema, primero debe dirigirse al departamento de DevOps, y este último se encargará de avanzar.
Por lo tanto, para comenzar, se debe crear un equipo temporal.. Existirá temporalmente durante seis meses, como máximo un año, dependiendo de la tarea planteada, solo para eliminar una restricción que hemos elegido. Luego morirá. Si elegimos otro punto donde nos duele mucho y entendemos que también necesitamos un equipo separado para ello, lo crearemos de nuevo. Pero en una situación 'permanente', esos equipos no deberían existir; de lo contrario, solo interrumpen la comunicación y asumen tareas completamente distintas, solo para hacer algo. Esas tareas pueden no estar relacionadas en absoluto con DevOps y la transformación. ¿Por qué no delegar esa tarea a los departamentos existentes?
Por qué se necesita un equipo temporal
Conflicto con los procesos actuales. La transformación DevOps implica no solo un cambio en las tecnologías y herramientas que utilizamos, sino en el propio proceso de trabajo, el pensamiento y los valores. Si el equipo trabaja como ya está acostumbrado, no podrá probar otros enfoques.
Estas personas deben vivir bajo otras reglas: ignorar todos los KPI de la empresa, porque están intentando trabajar de manera diferente. Los equipos temporales no llenarán solicitudes para obtener un servidor, sino que irán directamente al departamento encargado, exigiendo que se les proporcione primero lo que necesitan, porque es una tarea prioritaria y porque están intentando vivir de manera diferente. El equipo tiene un conflicto total con todos los procesos actuales. Para que los métodos de trabajo existentes no les obstruyan ahora y ellos no molesten a otros, aislamos a estas personas en un equipo separado.
Evitar la burocracia en los experimentos. En los equipos temporales no hay burocracia, no llenan informes de horas trabajadas, no rinden cuentas a los directivos. Es un mundo completamente separado, donde las personas viven y piensan de manera diferente, y se ocupan de cosas completamente distintas. No hay que interrumpirles innecesariamente.
Trabajo ininterrumpido en el servicio. En el primer punto, elegimos algo sobre lo que experimentaremos. Experimentar y buscar maneras de trabajar mejor es bueno, pero también queremos desarrollar funcionalidades. Si todo el equipo se dedica a la transformación en lugar de a las funcionalidades, comenzaremos a perder ingresos, los errores se quedarán pendientes durante mucho tiempo, lo cual no queremos. Crear un equipo temporal permite experimentar sin detener el trabajo en el producto.
No perder tiempo en tareas laborales. Esto vuelve a ser sobre el producto. Lleva mucho tiempo a la equipo probar otras herramientas y demás. Para que las personas dominen las herramientas, comiencen a implementarlas y las utilicen correctamente, se necesitarán al menos seis meses. Si además se ocupan del producto, esos seis meses se alargarán enormemente. Si las personas trabajan en el producto, nuevamente están lidiando con procesos antiguos: no necesitamos eso.
Por lo tanto, de diferentes departamentos estamos seleccionando personas para formar un equipo separado que se encargará de la transformación del servicio. Como resultado, el servicio funciona, continúa desarrollándose, y al mismo tiempo realizamos algunos experimentos sobre él.
El equipo temporal se ocupa solo de la transformación de DevOps: eliminar las limitaciones que hemos encontrado, y nada más.
El equipo está compuesto por personas versátiles. Esto significa que no solo hemos tomado desarrolladores. No llegamos al servicio y nos llevamos media equipo: no, hemos tomado personas de diferentes departamentos. Hace algunos puntos descubrimos diferentes departamentos y empleados que están relacionados con el servicio que se está transformando. De ellos formamos el equipo, pues debe ser versátil: cambiaremos tanto el proceso de prueba, como el de desarrollo y el de mantenimiento del servicio. Se necesitan diversas competencias.
Normalmente seleccionamos a un desarrollador, un probador y un ingeniero — uno de cada uno, y en conjunto con ellos ideamos una solución que permite vivir de manera diferente.
Es deseable que estas personas tengan autoridad en la organización. Puede que tengamos que llevar a un conservador, aunque no es lo que queremos. Si tenemos una gran empresa, no todos creerán en nuestra idea, y algunos pueden obstaculizarnos, por ejemplo, negándose a asignar un entorno. Aquí es donde se necesitará la 'autoridad': una persona respetada con mucha experiencia, que se ha ganado la buena voluntad de sus colegas. La autoridad de un empleado en el equipo facilitará la tarea y el trabajo del equipo temporal. La gente pensará:
— Ah, este chico genial, que todos conocemos y queremos, se ha incorporado — debe haber algo en DevOps que vale la pena ver.
Establecemos un objetivo
Hemos reunido a las personas, elegido el servicio, observado las limitaciones, determinado a quiénes influiremos. Ahora necesitamos establecer un objetivo y debe ser directamente según SMART — todo como nos gusta.
Específico — específico.
Medible — medible. Este es un punto muy importante de SMART. Si no puedes medir algo, no puedes cambiarlo y comprender qué hiciste mejor o peor.
Alcanzable — alcanzable. Ajusta a tu especificidad. Si eres una empresa grande con una larga historia y una gran carga de responsabilidades, que lanza una versión del producto una vez al año, no podrás alcanzar el lanzamiento de nuevas versiones cada hora en medio año. No se puede hacer. Por lo tanto, establece un objetivo realista que sea alcanzable en un plazo razonable.
Relevante — relevante. Eliminamos solo la restricción que realmente persigue nuestros objetivos actuales.
Limitado en el tiempo — limitado en el tiempo. Si no hay una fecha límite, el equipo hará cualquier cosa: probar 15 tecnologías en lugar de 3, escribir informes enormes, realizar investigaciones inútiles, pulir su implementación hasta el brillo, cuando ya se ha alcanzado el objetivo.
El objetivo lo tomamos usando Value Stream Map — nuevamente reunimos a todas las personas y dibujamos. Pero solo que ahora, sobre la base del anterior Value Stream Map, dibujamos lo que queremos obtener.
Destacamos una restricción que vamos a eliminar de inmediato, y eso es lo que hará el equipo. Por ejemplo, tomé la espera desde que se completa el lanzamiento hasta su despliegue en producción — esta es la restricción más común con la que la gente se acerca a los consultores.
Basándonos en esto, establecemos la tarea: queremos que la espera entre el lanzamiento terminado y la entrada en acción sea de máximo una hora.
Ejemplos de tareas.
- Reducir el Lead Time de pruebas de 4 días a 1 hora.
- Reducir el Value Added Time para pruebas de 2 días a 3 horas.
- Reducir el Lead Time de despliegue de 5 horas a 10 minutos.
- Aumentar el C/A de 50% a 95%, es decir, aumentar la cantidad de características que aceptan los probadores, en otras palabras, mejorar la calidad del trabajo de los desarrolladores.
Ejemplos de tareas no son invenciones — están basados en mediciones que realizamos al desarrollar el Value Stream Map.
Establecemos una tarea similar para nuestro equipo y una restricción de tiempo. Dependiendo de qué tan bien esté todo en tu empresa, estableces diferentes plazos. En promedio, para eliminar la restricción, si las personas están haciendo esto por primera vez y aún no saben con qué tecnologías y cómo resolverán el problema, generalmente lleva medio año.
Planificación corta
Así que nuestro equipo está formado, tiene un objetivo y las personas comienzan a trabajar. Un aspecto importante es la planificación de trabajo a corto plazo: sprints de una a dos semanasy, no más de eso, mejoras medibles cada semana y ajuste de rumbo.
Por ejemplo, a menudo utilizamos el enfoque moving-moving, donde todo el equipo se reúne al comienzo de cada semana, anota en un archivo lo que cada uno hará. Al final de la semana, revisamos: qué se ha hecho y qué no, y si no, por qué, y pensamos en qué hacer a continuación.
Los sprints permiten ajustar el rumbo a tiempo.
Pasamos una o dos semanas probando algo: tecnologías, enfoques, métodos de trabajo, y después de eso medimos de nuevo y vemos: ¿ha mejorado o empeorado con este enfoque? Si ha ido a peor, significa que vamos en la dirección incorrecta, hay que corregir el rumbo: establecer otra tarea, adoptar otra tecnología o hacer algo diferente. Los sprints cortos de 1 a 2 semanas permiten maniobrar y apartarse a tiempo de malas decisiones.
Compartimos éxitos
El equipo alcanza ciertos logros, pequeños o grandes —no importa, siempre hay algún resultado. Todos deben estar al tanto de este resultado: tanto los que están involucrados en DevOps como los departamentos adyacentes. En un mundo ideal, esto debería llegar a todas las personas de la empresa.
¿Por qué? Si queremos transformar no solo una parte de la empresa, eliminar no solo una limitación, sino todas para que la empresa sea ágil, el código fluya rápidamente hasta el cliente y nada se rompa, es necesario que todos sean leales a la idea de DevOps. No podrás aplicar el enfoque a servicios y equipos que son categóricamente opuestos.
Para generar lealtad, debemos contarles a todos que hemos probado esto —tenemos resultados, ¡prueben también! Esto aumentará el interés y la lealtad hacia lo que hacemos, y las personas comenzarán a intentar hacer algo en este momento. Como muestra la práctica, cuando contamos lo que hemos probado y lo que hemos logrado, otros equipos comienzan a preguntar cómo y qué hemos hecho. Observan implementaciones, código, documentación, se acercan con preguntas y tratan de cambiar algo en sus propias áreas.
Es importante hablar sobre lo que has logrado. Así convencerás a los conservadores que querían hacer todo a la antigua, y los transformarás en innovadores.
Total
Elegimos un servicio, como punto de partida —el lugar donde comenzaremos los cambios en la empresa. Identificamos a todos los que tienen alguna relación con el servicio y junto a ellos construimos un Mapa de Flujo de Valor, medimos y observamos dónde y cuáles son las limitaciones.
Creamos un nuevo equipo temporal, que se encargará de resolver la tarea planteada. Basándonos en las mediciones y el Mapa de Flujo de Valor dibujamos un nuevo mapa, donde identificamos la limitación que vamos a abordar. Con base en esta limitación establecemos la tarea, que será asumida por el equipo. La tarea debe ser definitivamente SMART — específica, medible, relevante para las tareas actuales y limitada en el tiempo.
Repetimos el proceso, hasta que transformemos todos nuestros servicios al estado requerido y eliminemos todas las limitaciones.
Bono. Materiales útiles
Para aquellos que han decidido emprender en DevOps por su cuenta.
Proyecto 'Fénix'
El título original es 'The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win'. Es una novela sobre DevOps — la historia de cómo a un empleado lo nombraron jefe de un departamento que siempre estaba en llamas. Al nuevo jefe se le asignó la tarea:
— Tienes unos años para corregir todo, para que finalmente podamos entregar nuestro producto a nuestros clientes de manera rápida y efectiva.
'Proyecto 'Fénix'. Una novela sobre cómo DevOps cambia la vida para mejor' — un libro para todos los gerentes, porque son estas personas las que toman decisiones sobre lo que sucede en la empresa. Si eres ingeniero o programador y deseas que en tu empresa empiece un movimiento y transformación — compra el libro y regálaselo a la gerencia. Esta novela explica todo y se lee rápida y fácilmente.
Guía sobre DevOps
Un libro un poco más complejo. Se publicó hace varios años en inglés con el título 'The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations', pero ahora ya está disponible en ruso. Es un verdadero manual — una guía práctica: cómo realizar mediciones, qué es un Mapa de Flujo de Valor y para qué sirve, hacia dónde deberías moverte y en qué orden. El libro es precisamente para aquellos que quieren hacerlo todo por sí mismos. Lo más importante es que contiene ejemplos de la experiencia de otras empresas.
Por ejemplo, se cuenta cómo una empresa construyó un Value Stream Map y entendió que su limitación no estaba en el producto, sino en que el cajero tenía que ir de la tienda a la oficina vecina para utilizar ese producto. En lugar de resolver el problema con el programa, simplemente compraron tabletas para sus vendedores, y ahora nadie tiene que ir a ningún lado, ya que todas las acciones se realizan en el lugar de trabajo. Conclusión: el Value Stream Map se puede aplicar no solo al software, sino a todos los procesos de la organización.
Acelerar
Título completo: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations". Este es el siguiente nivel: hardcore. El libro se publicó el año pasado, por ahora solo en inglés y trata sobre investigaciones. Los autores, Nicole Forsgren, Jez Humble y Gene Kim, han aplicado diversas prácticas en diferentes empresas durante muchos años y han investigado qué prácticas, cómo y en qué influyen.
En el segundo capítulo, dedicado a las mediciones, se mencionan el Value Stream Map, las métricas que mencioné y otras muchas, además de describir en detalle el proceso de medición. Los autores realizan mediciones utilizando cuestionarios y seguimiento autónomo de tareas. Se explica detalladamente qué métricas deben medirse correctamente, cuáles no deben, y los errores humanos en las mediciones. Si tienes dificultades con las mediciones, consulta el segundo capítulo del libro "Accelerate". Si en tu equipo hay muchas prácticas, pero no está claro qué prácticas aplicar ahora, cuáles después, cuáles realmente funcionan y cuáles no, lee, ahí se explica todo.
La transformación es una cuestión en la intersección de DevOps y la gestión. En algún lugar de esa misma área de intersección entre desarrollo, operaciones y pruebas se encuentran los temas que intentamos discutir en , la misma integración es necesaria para crear un producto de calidad: el tema principal de . La gestión en el festival se presenta — significa que todas las ideas para la transformación se dirigen allí. Únete el 27 y 28 de mayo, integraremos y transformaremos.
Fuente: habr.com
