Hola a todos! Hoy quería hablar sobre los procesos de desarrollo. A medida que la empresa crece, no solo se desarrolla el negocio en sí, sino que también se acumulan problemas en el interior, en particular durante el proceso de desarrollo. A menudo intentan resolverlos introduciendo algunas prácticas y metodologías novedosas. Por desgracia, esta reorganización forzada del proceso de acuerdo con los libros y entrenamientos a menudo conduce a problemas aún mayores: la burla de las personas.
Recientemente hablé en la
conferencia Saint TeamLead Conf 2019 , en un informe sobre cómo pude encontrar una serie de problemas en el flujo de trabajo y luego superarlos gradualmente. Aquí intentaré describir las prácticas más valiosas que me ayudaron no solo a establecer un flujo de trabajo, sino también a dejar de burlarme de los desarrolladores. Los empleados han cambiado su actitud hacia la empresa en general y el proceso de trabajo.
Desafíos del proceso de desarrollo
Entonces, cuando los enfoques ya preparados no dieron resultado, y estábamos cerca de la desesperación, comencé a analizar los procesos y comencé a analizar todo por los huesos. El resultado es una lista de problemas:
- El tablero está sobrecargado de tareas : había un verdadero caos en él. Mirando el tablero, entender los procesos era casi imposible.
- No hubo evaluaciones normales : no sabíamos cómo evaluar correctamente las tareas de acuerdo con el tiempo de entrega, debido a esto, los plazos estaban constantemente en camino, los líderes empresariales se encontraban en desarrollo.
- Establecimos constantemente los plazos : no podíamos decir exactamente cuándo entraría en producción la característica, la mayoría de las veces la lanzamos mucho más tarde de lo planeado debido a factores externos, por ejemplo, el negocio recurrió y solicitó rápidamente hacer alguna función urgente en primer lugar.
- No se entendía cómo acelerar el desarrollo : la contratación de nuevas personas y la carga de ingenieros en un 100% no siempre agilizan el proceso.
- Planificación y tareas urgentes : si con las tareas actuales era de alguna manera posible hacer planes e indicar fechas aproximadas, las tareas urgentes que generalmente salían del negocio rompieron todos los planes.
- Las reuniones llevan mucho tiempo , nuestro error más común: algo no funciona o debemos priorizar las tareas, y reunámonos y debatimos. O reuniones regulares, donde los desarrolladores se sentaron durante una hora o dos y no entendieron lo que estaban haciendo allí.
- El problema de la motivación y la participación de los equipos : a menudo, las autoridades simplemente derribaron algunas innovaciones desde arriba, sin pedir la opinión del equipo de desarrollo, esto no pintó la atmósfera en el equipo.
De hecho, la tarea de cualquier líder, ya sea un TL o un CTO, es que se convierta en el vínculo entre los negocios y el desarrollo.
Para salir de esta situación, recurrimos al método Kanban. ¿Qué nos dice él? Mejoremos lo que ya está allí. Bueno, fuimos a mejorar nuestro proceso de desarrollo.
Poner orden en el tablero
Comenzamos a discutir: si los backenders completaron su tarea y la entregaron al front-end, ¿comenzarán de inmediato? Mirando el tablero, esto es incomprensible. De acuerdo con los principios de Kanban, dividimos cada dirección de desarrollo (teníamos 5 de ellas: backend, frontend, DevOps, QA y diseño) en dos columnas: Do y Done. El problema se hizo evidente de inmediato: nuestro ancho de banda no nos permite hacer tantas tareas como quieran de nosotros.
Kanban también dice: introduzcamos un
límite WIP y limitemos el número de tareas. ¿Cómo establecemos límites? Empíricamente Por supuesto, fallaron un par de veces, pero luego lo recogieron para que no tuviéramos que acumular tareas en el lugar más estrecho. Un beneficio adicional de WIP-limit es un desencadenante, que dice que tan pronto como nos quiten la tarea, podemos tomar lo siguiente. Este es un tipo de sistema de tracción.
¿A qué condujo esto? Los ingenieros comenzaron a estar más atentos a las tareas, porque cuando no pueden resolver un problema, se les aplica un bloqueador. No se pueden realizar más tareas, ya que existe un límite de WIP, los ingenieros deben esperar a que lo ayuden a resolverlo. Existe la posibilidad de quedarse sin tareas.
Cuando comenzamos a analizar en detalle el problema de devolver tareas, resultó que todos las hacen de manera diferente, por ejemplo, alguien escribe pruebas y alguien no. Había reglas al respecto, pero las que habían sido defraudadas por las autoridades. No resolvieron el problema de los desarrolladores. Introdujimos nuevas reglas (
Definición de Hecho ), que están integradas en el tablero. Podrían actuar tanto en alguna columna como en el tipo de tarjeta. Por ejemplo, para una API, necesita el backend para documentar todos los métodos y demás. Las reglas eran accesibles para todos y visibles en el tablero, y lo más importante, provenían de los propios ingenieros y resolvieron sus problemas. Si no se hizo algo, el ingeniero lo vio y fue a hacerlo.
Tareas de grado
No sabíamos cómo evaluar las tareas por plazos, y Kanban nos dice: "No hay estimaciones". Que hacer Acumulamos estadísticas y construimos ese horario. Este es un diagrama espectral, la dependencia del número de tareas en el tiempo.
Comenzamos a estudiarlo, vimos en el gráfico 3 picos que corresponden a tres tipos de trabajo. En base a estos tipos, se desarrolló una clasificación y criterios para dicho trabajo. Introdujimos estos tipos en el tablero de tareas, y luego para cada uno en el proceso, agregamos reglas adicionales. Tenemos lo siguiente:
Acordamos con el cliente, es decir, con la empresa, un acuerdo de calidad de servicio (SLA). Un gerente viene a nosotros y nos pregunta: "¿Y cuánto va a hacer esta función?" No podemos decir cuánto haremos con seguridad, pero podemos decir cuánto tiempo se dedicará a un lote completo de tales tareas. No había necesidad de scrum poker, y dejamos de torturar a las personas con preguntas de tiempo. Acabamos de mirar las estadísticas y llamamos a las fechas para los negocios.
Por supuesto, este enfoque también tenía desventajas. Por ejemplo, esto no funcionó con tareas de un nuevo tipo, para las cuales simplemente no teníamos estadísticas. Fingieron estar en las viejas formas, pero luego acumularon una cantidad suficiente de datos y este problema quedó en nada.
Luego nos enfrentamos con el hecho de que algunas tareas comenzaron a caer en otros tipos de trabajo. Realizamos un poco de investigación y descubrimos que algunas tareas se realizaban mucho más rápido, porque la empresa prometió algo a los socios y les pidió a los desarrolladores que las hicieran con urgencia. Y algunas tareas, por el contrario, no eran tan importantes, se pospusieron. Entonces obtuvimos prioridades, es decir, acuerdos sobre clases de servicio de servicios (CoS), los colocamos en el tablero. Y para que la empresa no lo abuse y no establezca una mayor urgencia para todas las tareas, se han introducido límites horizontales de WIP.
Cómo acelerar el desarrollo
Nuevamente se dirigió a las estadísticas del rastreador de tareas. Descubrimos que muchas tareas dependen del tablero en previsión de mejoras, verificaciones o datos adicionales, es decir, se dieron cuenta de que el desarrollo puede acelerarse. Comenzaron a observar cuántas tareas se están acumulando, cuánto están inactivas y descubrieron que algunas características se desarrollaron menos de lo que esperaban ser aceptadas. Decidimos establecer un día para aceptar las funciones, y se redujo el tiempo para emitir tareas. Y luego sujetamos el CD (Entrega continua) y comenzamos a enviar notificaciones.
Quedó claro que necesitábamos una herramienta para evaluar nuestras mejoras. Decidimos usar el diagrama de flujo acumulativo. En pocas palabras, cómo se construye: asignamos un color a cada centro de trabajo (columnas en el tablero), tomamos estadísticas sobre cuántos elementos (tareas) hay en una unidad de tiempo en una columna y los trazamos en el gráfico, colocándolos uno debajo del otro. En el gráfico, el eje X es el tiempo, el eje Y es el número de tareas.
¿Qué obtuvimos de aquí? Aquí es fácil ver el tiempo de entrega (tiempo de producción): la línea horizontal (el ancho del flujo a lo largo del eje X) comienza con el enunciado del problema y alcanza la etapa de preparación. Por lo tanto, aquí puede ver cómo la tarea pasa por todas las etapas de desarrollo: la línea intersecta todos los colores, cada uno de los cuales corresponde a su etapa. Y también el límite total de WIP de la placa: la altura del flujo a lo largo del eje Y. ¿Cómo aumentar la velocidad de desarrollo? Puede reducir el límite de WIP (es decir, hacer que el flujo en el gráfico sea más estrecho), o puede hacer que nuestro flujo, que se dirige desde el origen a la esquina superior derecha del gráfico, tienda a aumentar aún más (es decir, elevar la dirección del flujo aún más) reducir su ángulo relativo al eje Y). Para dirigir el flujo más fuerte hacia arriba, puede introducir alguna práctica nueva, por ejemplo, implementar Docker o hacer una base de conocimiento conveniente. Esto no tiene que ser una innovación técnica; un nuevo enfoque de gestión también puede dar ese efecto.
Por lo tanto, obtuvimos una herramienta que mostraba claramente qué mejoras funcionan y cuáles no.
Planificación empresarial, tareas urgentes e inútiles.
La planificación del desarrollo empresarial fue el mayor dolor. Que hicimos Después de recibir la tarea del negocio, se realizó una reunión entre el analista y el desarrollador, donde la descompusieron, y el desarrollador propuso soluciones. Como resultado, entendimos cuánto y qué recursos requería la tarea. Y solo entonces el negocio sin nuestra participación hizo sus planes y consideró cuánto podemos lanzar funciones. En Kanban, esto se llama
cadencia de reposición .
En términos relativos, asignamos ranuras de cierto tamaño, de acuerdo con los límites de WIP, donde puede colocar tareas. Cada ranura tiene solo un número limitado de tareas. De otra manera, este método se llama "planificación de copa".
Creamos una herramienta simple para negocios (una tabla en Excel), en la que podía planificar visualmente. Los gerentes pelearon entre ellos, discutieron qué tarea es más importante, y luego vinieron a nosotros y nos dieron las tareas para el desarrollo.
Como ya teníamos limitaciones, el negocio estaba más atento a la elección de tareas, eligió las más importantes y no nos abrumaba con ninguna tontería que se les ocurriera. Y una gran ventaja más: seleccionaron las tareas ellos mismos sin nuestra participación, sin distraer a los desarrolladores a las reuniones, trabajaron en silencio y no pasaron tiempo en las reuniones.
También dirigimos nuestra atención al problema de las tareas urgentes. Comenzaron a analizar estadísticas sobre ellos y se dieron cuenta de que estas tareas no son tan urgentes. Por ejemplo, necesitamos una promoción para el cambio estacional de ruedas de los automovilistas. Sabemos que esto siempre ocurre 2 veces al año. Una vez que se repiten, reservemos espacios para tales tareas en el tablero de antemano. No habrá nada urgente: tomaremos otra tarea de la cola, no nos quedaremos sin trabajo. Como resultado, descubrimos que el 60% de las tareas urgentes en realidad no son urgentes.
Hubo otro problema. A menudo vimos características, que finalmente rechazaron el negocio, porque resultaron ser inútiles desde el punto de vista comercial. Sugerimos que las empresas realicen funciones de MVP que requieren varias veces menos tiempo que el desarrollo convencional. Los comentarios comenzaron a eliminarse mucho más rápido, y los ingenieros comenzaron a darse cuenta de que se trataba de experimentos. Anteriormente, cuando las semanas de trabajo se tiraban a la basura, se preocupaban, envenenaban sus vidas.
Comenzamos a probar el 85% de las características de tal manera que, al final, liberamos mucho tiempo, que luego dedicamos a las hipótesis probadas en la práctica. Ya le trajeron dinero a la empresa. Además, si algo salió mal en el proceso, el cliente de la característica del negocio podría hacer correcciones en una etapa temprana, y no durante todo el ciclo de desarrollo.
Como resultado, se descubrió que no todas las ideas funcionan. Y como no funcionan, entonces no los hagas. Desde entonces, los desarrolladores han dejado de dedicarse al trabajo con monos e hicieron exactamente lo que la compañía aporta dinero.
Reuniones
Las mejoras que introdujimos para ese momento ya habían matado varias reuniones inútiles. Las discusiones de priorización ya no existían, ya que le dimos esto a la empresa, también planeamos sin ingenieros. También abandonamos las redadas de cinco minutos de los gerentes con una solicitud de "ayuda rápida". Solo hubo reuniones realmente necesarias. También introdujimos la regla de que las reuniones ahora están programadas para un momento específico para que todos puedan planificar su horario.
Como resultado, todas las reuniones sobre boltología se transformaron en los siguientes tipos de reuniones:
- cuando un analista quiere discutir un problema específico con un ingeniero, por ejemplo, para encontrar la solución o descomposición óptima;
- cuando algo está atascado en el tablero. En estos casos, nos reunimos y caminamos a lo largo del tablero de derecha a izquierda, preguntando a los ingenieros qué pasó, quién podría ayudar. Es importante que pasamos de tareas y no tratamos de calcular lo que la gente estaba haciendo;
- cuando planificaron tareas para sprint (cadencia para reposición);
- cuando tomaron características;
- Reuniones entre equipos de desarrollo, por ejemplo, cuando se discute el formato API o se deciden qué eventos enviar.
Punto clave: invitamos a las reuniones solo a aquellas personas que estuvieron directamente involucradas en el tema de discusión, y no llamaron a los oyentes nominados, como antes. Los ingenieros han cambiado fundamentalmente su actitud hacia las reuniones, antes no les gustaban, pero ahora es al revés, parecen ser necesarios y útiles para ellos.
Motivación e implicación del equipo.
Todo lo que implementamos: límites de WIP, evaluación de tareas basadas en estadísticas, rechazo de tareas inútiles, etc. descritas anteriormente, condujo a tiempo libre para los ingenieros. ¿Qué harán ahora? El error más grande es que nadie hará nada. Yo mismo he escuchado repetidamente de los chicos: "Hubiera refactorizado este código, de lo contrario la pierna del diablo se rompería". Sí, al principio el ingeniero realmente duerme lo suficiente y descansa durante 2-3 semanas, ¿y luego qué? Se sienta sin tareas, comienza a acercarse a sus colegas con una propuesta de ayuda, ayuda a completar las tareas, luego ambos ya están sentados sin tareas. "Enviemos la corrección de errores": la columna con errores estaba vacía. “Envíe el código que refactorizaremos”: el código se ha vuelto más rápido de escribir, el límite de WIP se puede aumentar. Luego comienzan a implementar CD / CI, escriben una base de conocimiento. Que paso Los ingenieros comienzan a hacer muchas cosas útiles, a las que sus manos no llegaron. Esta es la velocidad que el negocio quiere, pero por alguna razón no puede obtenerla de nadie. Anteriormente, el ingeniero estaba enojado, quería que todos estuvieran detrás de él, y ahora el paradigma humano ha cambiado a: "Ahora, ¿cómo puedo ayudarlo?" El número de iniciativas ha crecido, y todas vinieron desde abajo, no desde arriba. Y al final, resultó ser mucho más útil.
Resumen de los resultados.
- Pudimos encontrar un cuello de botella en el sistema y entender que no podemos hacer más de lo que podemos.
- Dejaron de lanzar a los desarrolladores trabajo inútil y liberaron tiempo para tareas más útiles.
- Cuando los ingenieros no tenían nada que hacer, comenzaron a evaluar mejor las tareas, eliminar errores, comenzaron a automatizar los procesos y apareció una base de conocimiento.
- Los ingenieros dejaron de estresarse y se volvieron más amables.
- Pudimos acelerar 4 veces el lanzamiento de nuevas funciones a través de mejoras, optimización del trabajo (mayores límites de WIP debido a la automatización y mejoras).
- Obtuvimos estadísticas de negocios y una comprensión clara de qué y cómo está pasando con el desarrollo.
- Aprendimos a ahorrar tiempo (rechazo de tareas innecesarias, comenzamos a pensar en las tareas de antemano para evitar factores adicionales, etc.).
- Las reuniones y reuniones se llevaron a cabo cuando realmente se necesitan (se vuelven más flexibles).
- Todos comenzaron a pensar más, el número de iniciativas aumentó. Las iniciativas que nacen en equipos son siempre mejores que las que vienen de arriba. El proceso continuó constantemente y todos se involucraron en él.
Conclusiones
En este artículo e informe, quería llamar la atención no solo sobre las herramientas y los enfoques que apliqué, sino más bien sobre el aspecto más importante, que a menudo pasa desapercibido, pero, en mi opinión, no es menos importante. Comenzamos toda esta perestroika, porque teníamos dolores y queríamos deshacernos de ellos.
Puede implementar algo "en la frente" leyendo libros inteligentes o escuchando un informe sobre metodologías flexibles, por lo que incluso es posible acelerar el desarrollo o los productos funcionarán mejor. Pero a menudo olvidamos que las personas fabrican estos productos, y cuanto mejor hagamos sus vidas, mejores serán sus productos. Por ejemplo, voy con los chicos y les pregunto: “¿Y cuáles son tus dolores? ¿Qué está mal? ”, Antes de comenzar a implementar algo. Y solo gracias a este enfoque, logré hacer lo que el negocio quiere: velocidad y calidad en el desarrollo.
PD: Me dijeron sobre una compañía en Europa, cuando vienes a la oficina allí, puede parecer que reina la anarquía completa: los desarrolladores, como el queso con mantequilla, las consolas de juegos, nadie trabaja. Pero esto es solo a primera vista, hay una atmósfera especialmente creada para que las personas puedan crear y mejorar. En el intervalo entre tareas para el entretenimiento, una rodilla escribió una solución que se implementó posteriormente y comenzó a generar ganancias para la empresa. Espero que nuestra administración rusa se mueva en esta dirección en el futuro cercano. Y si por alguna razón tienes algo mal, piensa en lo que estás haciendo. Bueno, o arroje este artículo al jefe, pero ¿qué pasa si ayuda? :)