Lado oscuro ágil

El lector atento hojea la cinta y hace la pregunta: "¿Cuál es, nuevamente, el texto sobre ágil?". Si

Este artículo trata sobre procesos, aspectos técnicos y un poco sobre cuán ágil vive y se implementa en Yandex.Money. Si ha caminado al menos la mitad del camino hasta ser realmente ágil, algunas cosas pueden parecerle obvias, y eso está bien.

Debajo de un gato sobre bancos de pruebas, encerrar a las personas en salas de reuniones y cómo administrar un departamento, cuando todos se dispersaron por los equipos y disfrutaron de la vida.

Y un lector atento preguntará: "¿Por qué el lado oscuro? ¿De qué se trata Darth Vader?" Por desgracia, no, será sobre el lado oscuro de la luna, que era desconocido para la humanidad, hasta que el dispositivo voló para fotografiarlo y mostrárselo a todos.

Cuando implementa ágil, está diseñando un proyecto de exploración lunar, sin saber
que hay al otro lado

Todo comienza con un intento de introducir nuevos procesos de desarrollo.

Scrum, kanban, scrambana o alguna otra bicicleta local no es tan importante.

Los departamentos de desarrollo clásicos generalmente están dirigidos por un administrador de recursos. Él le dice al mundo exterior: "No vayas a los desarrolladores, ve a mí, distribuiré todo aquí ahora". Una vez que dicho gerente asigna por primera vez una secuencia, porque ha aparecido algún cliente especial. Luego hay más clientes de este tipo dentro y fuera de la empresa, comienzan los conflictos, la lucha por los recursos y el gerente tiene que resolverlo todo. También por asignación de hilos.

Java - izquierda, JavaScript - derecha

Este juego continúa hasta un punto crítico, luego de lo cual la compañía acepta la idea de que ahora se necesita con precisión ágil. Aparecen equipos de productos, porque para PO no hay nada más valioso que un recurso dedicado y su propio equipo. El producto está contento porque el equipo en vivo hace que sea más fácil responder por la funcionalidad y asumir la responsabilidad de PNL, el tráfico y otros KPI.

Suena correcto, pero en la vida real, todo está un poco mal.

En la mayoría de los departamentos de desarrollo clásicos, es más rentable trabajar con un monolito. En este caso, se adjuntan todos los atributos: ciclo de lanzamiento en 3-4 semanas, pruebas y montaje largos.

A veces un monolito es normal.

Pero los equipos seleccionados no funcionan así. En general, el mundo llegó a los microservicios debido al hecho de que todos comenzaron a cambiar a pequeños equipos y trabajar en ellos. Sí, esto lleva al hecho de que el código "se extiende" y todo se vuelve más difícil de controlar.

Por otro lado, aceleramos el lanzamiento del producto, implementamos lanzamientos más a menudo, pero tenemos problemas con las pruebas. Y también necesitan ser resueltos de alguna manera.

Reforma de prueba

Si tiene un equipo y un banco de pruebas: todo está en orden, no puede preocuparse (o preocuparse, pero por una razón diferente). A menudo, en tales casos, ni siquiera se considera algo crítico, por ejemplo, una herramienta adicional como el correo o el chat corporativo. Todos están monitoreando de cerca la producción, y también están bien.

Si ya ha volado a la Luna Edgile, entonces el banco de pruebas es algo que ralentizará todo el proceso, y es por eso.

Historia de vida : en una empresa, la entropía en torno a lo ágil comenzó a crecer demasiado rápido. En este punto, los evaluadores ingresaron al horario del único banco de pruebas en el calendario: dividieron el tiempo en espacios de media hora e intentaron de alguna manera controlar el caos.

De hecho, 20 equipos deberían usar el stand, pero no pueden, porque uno de ellos rompió todo

Sobre bancos de pruebas

Érase una vez, teníamos varios monolitos, cada uno con un banco de pruebas, y todos estaban felices. Una vez que hicimos un proyecto complejo para la separación de stands, asignamos equipos y luego hubo 20 stands.

Ahora hay 70 de ellos, pero apuntamos a 200, para que todos, sin cargo, y nadie se ofenda.

Del diálogo con el administrador:
- Dime, ¿dónde está la automatización de la implementación?
- El cálculo una vez cada dos semanas lleva una hora, ¿qué debo automatizar aquí?

De hecho, esto: (200 stands + producción) * (más de 50 componentes) = Mucho esfuerzo para implementar.
Ahora tenemos más de 50 componentes que el robot implementa. Si no fuera por él, entonces todos serían malos.

En esta etapa, la compañía, que se vuelve ágil, tendrá sistemas automatizados para ensamblar y entregar a la producción, el trabajo en equipo mejorará gradualmente y el rendimiento también aumentará, hasta 60-80 lanzamientos por semana, y cada componente se lanzará 2-3 veces al día .

En este punto, todos entienden que el sistema se ha vuelto demasiado grande para que una persona pueda comprenderlo.

En cualquier equipo que admita el monolito, seguramente habrá un par de veteranos. Estuvieron aquí desde el principio y recuerdan todos los errores de todos los tiempos, recuerdan las extrañas decisiones lógicas que el negocio estaba vendiendo.

Historia de vida:
"En general, es normal tratar de llamar a un cliente 3 veces, pero este cliente es especial y tocaremos 100 veces, hay un factor de corrección y no es necesario tocarlo, tóquelo, no es así".

Se gastan tantos recursos para mantener el trabajo de los stands que la operación se vuelve "dorada": multiplique toda la granja por el número de puestos de prueba, agregue producción, se enoje y finalmente llame a los administradores.

Otro monitoreo

Los administradores vendrán y dirán: "Todo está cubierto por el monitoreo en nosotros". Esto está bien, pero con una aclaración: el monitoreo sería bueno para ser personalizado.

Las métricas de "hierro", la cantidad de memoria consumida por Java, la temperatura de todos los núcleos de todos los procesadores; todo esto es útil, pero no siempre ayuda en caso de incidentes con los clientes. Las métricas de negocios tampoco tendrán idea si no las ha personalizado. El mundo es complejo: es raro que todos los clientes ideales usen su API ideal de manera ideal. La gente hace todo, y todos tienen que adaptarse: a veces los clientes son para usted, a veces usted es para los clientes.

Como una central nuclear

Historia de vida : durante mucho tiempo buscamos y solucionamos un error en nuestros productos. Después de eso, uno de los clientes rompió varios procesos en los que se tuvo en cuenta este error.

En esos momentos, debe agregar monitoreo personalizado, porque sin aislar situaciones excepcionales y agregación, simplemente no funcionará. Por lo tanto, por cierto, a menudo hablan y escriben sobre aprendizaje automático y sistemas complejos que definen problemas en lugar de personas.

Una vez cada seis meses, debe realizar revisiones de monitoreo, ya que las expectativas comerciales aumentan con el tiempo. Sucede así: todo se construye y controla en la empresa, y el negocio trae a un nuevo cliente que necesita un SLA un orden de magnitud mayor. Y toda la historia ha terminado.

Si esto se supera, entonces el sistema funcionará bastante bien en todos los casos, excepto en los proyectos "paraguas".

Proyectos Paraguas

Esto, por ejemplo, es la introducción de 54-FZ, cuando el estado dice: "Y reestructurar todos los procesos de efectivo en el país". O cuando el marketing pagaba por el proyecto, el producto todavía tenía que funcionar y funcionar, y la fecha límite era real, y luego lo disparaban. O cuando alguien de la alta gerencia acaba de ingresar, no importa por qué razón, y él también tiene un proyecto con una fecha límite.

Spoiler: pocas personas en el mercado entienden cómo hacerlos. Puede comprar diferentes complementos sobre scrum y kanban, puede leer historias de éxito, pero la práctica muestra que, en teoría, es más costoso hacer tales proyectos. Además, todos estos SAFE y LEAN son caros administrativamente y con recursos, y también requieren competencias costosas y complejas que no están en el mercado.

Historia de vida: Spotify es una de las empresas ágiles ejemplares. En algún momento, se les ocurrió una suscripción familiar, pero no pudieron darse cuenta debido a la dificultad de sincronizar y planificar entre equipos que tienen su propia hoja de ruta y planes. Un año después, Google y Apple lanzaron la suscripción familiar.

Conflictos de sincronización y programación.

El principal problema con los proyectos generales es la sincronización de todos los equipos participantes. Está conectado con el hecho de que a la gente no le gusta negociar.

Esto se manifiesta en muchas cosas, comenzando con scrum, cuando las personas no pueden ponerse de acuerdo en el marco de un departamento de recursos. En ágil, debes sincronizar y coordinar todo lo que sucede con varios equipos. Y si en algún momento deja de requerir que todos trabajen juntos, entonces cada equipo regresa a su rincón oscuro favorito y trabaja de forma independiente. Esto lleva al fracaso.


Hack de vida
Si quedan dos meses antes de la próxima ley, o antes de la campaña publicitaria, o si el jefe lo exige, tome personas de 4 equipos, enciérrelos en una habitación, déles comida y agua y controle. Esto es grosero, pero funciona. Porque si intentas sincronizar por un tiempo limitado, fallarás en el proyecto.

En general, la sincronización es necesaria y sin ella no puedes seguir adelante. Complica la vida de los proyectos con un plazo claro y una gran importancia: los plazos varían del 10% al 50%, y esto a menudo es inaceptable.

¿Cómo gestionar esto?

El líder clásico en el departamento distribuido no entiende cuál es su papel porque le enseñaron el paradigma "Le di tareas a todos", y tengo que trabajar con "No tengo gente en absoluto, ¿por qué estoy en la empresa?".



Lo peor es para los fanáticos del control que no se pierden una sola tarea resuelta por el departamento, organizan revisiones dobles de códigos públicos y controlan literalmente todo. Cuando las personas se distribuyen en equipos, hacen la pregunta: "¿Por qué estoy aquí?". La respuesta es que los desarrolladores de todos los equipos intercambien información, crezcan sincrónicamente en una dirección y el sistema no se arrastre.

En general, cuando tal pregunta suena, el líder necesita ser cambiado o enseñado.

Enseñar porque muchos líderes (incluidos nosotros) nacen de ingenieros, y nadie les ha enseñado habilidades blandas. Creemos que esto es importante, y una vez que llegué a Recursos Humanos y solicité un gran curso de dos años para gerentes, desde lo básico hasta el desempeño y la motivación no financiera.

Cultura en TI

Hay otro punto sutil sobre la agilidad en la organización de equipos. Cuando los desarrolladores acuerdan algo dentro del equipo, pueden comenzar a defender los intereses del equipo, olvidando los intereses de la empresa.



Idealmente, cuando las personas entienden que hay alguien más alrededor de su luna Ajail, un servicio de seguridad con sus propios requisitos; arquitectura que no solo fue inventada; otros equipos cuyos intereses deben ser considerados. Nos esforzamos por identificar, nutrir y alentar tal comportamiento.

Ágil - punta del iceberg

Este camino tiene características importantes.
Mucho tiempo Por ejemplo, DevOps apareció en el mercado hace cinco años, y su implementación ahora costará de 1 a 2 años, dependiendo del tamaño de la empresa. Si comienzas a lidiar con eso cuando tienes líneas en los bancos de pruebas, entonces tienes garantizado seis meses de infierno, porque los administradores se dividirán entre todo.

Caro Puede implementar ágil y avanzar en este camino solo si tiene un negocio fuerte y una compañía fuerte, y comprende que en el futuro aún tendrá que crecer.

No hay personas Agile necesita nuevas competencias, que las personas no tienen tantas. Resulta un círculo vicioso - no hay personas -> todo no está yendo muy bien -> no hay dinero -> no hay ningún lugar de donde sacar gente.

Tres conclusiones

1. No toque los departamentos de desarrollo "clásicos" sin la necesidad. Un sistema híbrido funciona en Yandex.Money: hay un equipo de producto, pero hay departamentos que pueden trabajar de manera efectiva sin agilidad.
   
2. Si no tiene la tarea de reconstruir toda la empresa, pero desea o necesita hacer un nuevo producto más rápido con nuevos enfoques, a veces es más fácil contratar a proveedores externos que trabajen de manera ágil y le den al producto un recurso externo.
   
3. Si la transformación de TI es inevitable, entonces es mejor ponerse de acuerdo en todo "en tierra". Vale la pena concluir una especie de "acuerdo de caballeros" con el liderazgo: que habrá un presupuesto para hardware, personas (para nuevos puestos para administradores de sistemas, probadores y desarrolladores). En cuyo caso, es posible volver periódicamente a este acuerdo y discutir qué se hizo y cómo.
   

Todo lo anterior tiene un problema. Ir hasta el final! = Ven al éxito. No lo pase = garantizado que fallará.

Pero si estás en camino, ¡buena suerte!