Sobre espinas y estrellas en el camino hacia la optimización de los procesos de desarrollo

Sueños sueños

En las frías tardes de otoño, nosotros y los desarrolladores de aplicaciones de visualización en 3D nos reunimos en la cocina ... tomamos café ... y pensamos en ello ... en la organización de referencia del desarrollo.

- Mis amigos en el trabajo ágil para mí: sprints, puntos de historia, todo ...
- Sí, al menos revisaríamos ...



El hecho es que en aquellos días, no fue muy fácil con nosotros. Por ejemplo, almacenar proyectos en git era muy inusual:

• había varios repositorios, y cada parte contenía una parte del proyecto;
• algunos repositorios eran comunes, algunos relacionados solo con algunos proyectos, algunos solo con uno;
• Para obtener una copia de trabajo, tenía que descargar el contenido de todos los repositorios y colocarlos en carpetas específicas.

Como estamos trabajando con gráficos en 3D y luego utilizamos el concepto de "controles + plantillas (la ubicación de los elementos en la pantalla, la lógica de las transiciones)", para ser más específicos, las cosas eran así:

• al trabajar en controles, los commits se dirigían al repositorio con controles básicos y, posiblemente, al repositorio con recursos (si los modelos tridimensionales ya utilizados tendrían que usarse en otro lugar);
• Cuando se trabaja con controles y plantillas (por ejemplo, si fuera necesario reemplazar el fondo de la aplicación en el panel de ayuda), las imágenes tenían que cargarse en el repositorio con recursos y el diseño corregido en el repositorio con plantillas. Si el fondo se hizo con una máscara (estilo único), entonces podrían estar involucrados 3 repositorios.

Con este enfoque, las revisiones de código fueron un lujo para el costo:

• el desarrollo se llevó a cabo en una sola rama;
• Los cambios en una tarea afectaron a varios repositorios y el seguimiento de las confirmaciones relacionadas con cada tarea fue muy problemático.

Como resultado, debido a la falta de la capacidad de "aprender de los errores", intercambiar experiencias, analizar el código del otro durante la revisión, los desarrolladores no pudieron mejorar sus habilidades lo suficientemente rápido. Y para desarrollar aplicaciones "más rápido" - era necesario. Y para mantener la velocidad de desarrollo a un nivel aceptable, en cada nuevo proyecto, las personas se dedicaron a esas tareas que eran similares a las tareas en proyectos anteriores. Es decir si alguien trabajó previamente con un mapa 3D, una y otra vez tenía tareas relacionadas con los mapas, o si alguien alguna vez desarrolló el componente "gráfico", estaba condenado a los gráficos. Y esto tiene su propia lógica, porque más rápido, la tarea la realiza alguien que se ha encontrado con ella de manera similar o idéntica. Como resultado, resultó que los desarrolladores se especializan en cosas específicas y no son intercambiables.

En cuanto a las metodologías de desarrollo y un flujo de trabajo claro, tampoco se aplicaron por varias razones. Comenzando por el hecho de que para esto era necesario dedicar una cantidad considerable de tiempo a pensar en todos los conceptos y procesos de desarrollo, terminando con el hecho de que simplemente no había nadie para traerlo. Ni yo, como el empleado recién llegado, ni los muchachos tenían la autoridad para reorganizarnos. Y solo quedaba gruñir y soñar.

"Donde hay un sueño, siempre hay una oportunidad"

Por supuesto, para mí, como persona que no es indiferente a su trabajo, el objetivo era cambiar la situación. De lo contrario, ¿cuál es el punto de mi actividad, si no puedo influir positivamente en los procesos existentes y proporcionar tales condiciones de trabajo a las personas bajo las cuales pueden revelar sus habilidades y mejorar? El desarrollo de quienes crean la aplicación, que encarnan la idea proyectada en papel, es el desarrollo de los proyectos y de la empresa en su conjunto.

Una buena oportunidad para lograr el objetivo fue una aplicación para desarrollar un nuevo módulo de visualización de nuestra plataforma. Este proyecto no era como los otros, porque No fue el desarrollo de una aplicación en la plataforma, sino la implementación de parte de la plataforma misma. Por lo tanto, aquí no estábamos apegados a ese extraño concepto de almacenar y trabajar con proyectos en muchos repositorios git, lo que me pareció una gran oportunidad para introducir revisiones de código.




Aquí, por cierto, lo que hicimos

Y una buena mañana de invierno, ataqué al arquitecto del proyecto con una propuesta para presentar Gitflow. Al principio, tomó mi idea contradictoria, pero había razones para ello: algunos modelos estándar no siempre son adecuados. Sin embargo, en el proceso de comunicación, se desarrolló la opción más adecuada para este proyecto, que ahora estamos utilizando con éxito.

Nuestro Gitflow modificado es el siguiente:

• hay una rama principal (la llamamos maestra, pero puede dar cualquier nombre para no confundirla);
• hay un sprint en Jira, formado por tareas acumuladas que están unidas por un micro objetivo;
• el desarrollador toma la tarea de la lista de los abiertos dentro del sprint en progreso y crea una rama de características del maestro, indicando el código de la tarea en el nombre de su rama de características (por ejemplo, PLAYER-55);
• tan pronto como se completa el trabajo en la tarea, el desarrollador presenta su trabajo para su revisión: a través de Gitlab crea una solicitud de fusión en master y transfiere la tarea a Jira en revisión con un enlace a la solicitud de fusión en el comentario;
• si se completa la revisión y se cierran todas las discusiones, entonces la tarea en Jira se cierra, la rama de características se fusiona en maestra y se elimina;
• si hay comentarios después de la revisión: en Jira, la tarea se redescubre desde Revisión y el algoritmo se ejecuta desde el principio, excepto que la rama de la característica ya se ha creado.

Cuando todas las tareas están cerradas, entramos en la etapa de lanzamiento:

• la rama de lanzamiento se llama fuera del maestro, que se llama dos dígitos, por ejemplo, release-3.0, donde 3 es el número de versión del proyecto y 0 es el número de rama de lanzamiento (respectivamente, la próxima rama de lanzamiento se llamará release-3.1, etc. );
• Se llevan a cabo pruebas adicionales del candidato de lanzamiento (generalmente el desarrollo de pequeñas demostraciones);
• Si no se encontraron defectos durante la prueba, el candidato de lanzamiento está listo para la producción: el último compromiso en la rama de lanzamiento se marca con una etiqueta de producción que consta de 3 dígitos (por ejemplo, prod-3.0.0, donde 3 es el número de versión del proyecto, 0 - número de rama de lanzamiento, 0 - número de versión de producción), luego la rama de lanzamiento está atascada en el maestro y no se elimina, a diferencia del clásico Gitflow;
• si todavía se encuentran defectos, entonces se registran en Jira como Bug y luego el proceso de corrección de errores es similar a trabajar con una tarea en la rama de características (solo se verifica desde el lanzamiento, no desde el maestro) y cuando todos los errores están cerrados, colocamos la etiqueta de producción, la versión se envía al producto y la rama de lanzamiento se fusiona en maestra, sin ser eliminada.

En caso de que se encuentren errores en la producción, también hay un acuerdo:

• el trabajo en tales errores también se lleva a cabo en la rama de lanzamiento de esta versión de la venta, si las ediciones son extremadamente urgentes, se marcan como hotfix y se llevan a cabo directamente en la rama de lanzamiento con los líderes del equipo;
• de lo contrario, trabajar en tales errores es similar a trabajar en los errores encontrados en el candidato de lanzamiento.

Entonces, ¿por qué exactamente Gitflow y solo eso?

1. Ingresar ramas de características es una forma de introducir una revisión, que le permite compartir experiencias, aumentar el nivel general de calificación del equipo y, lo más importante, como resultado, para evitar que el código final tenga un código de baja calidad que no tiene un estilo común, es difícil de entender y está lleno de errores.
2. Creo que muchas personas están familiarizadas con la situación cuando el proyecto se evalúa de acuerdo con los términos de referencia y las especificaciones, se asigna un presupuesto, se implementa la funcionalidad de acuerdo con los requisitos de la documentación, pero aquí, de la nada, alguien de los jefes generará y escuchará: "Oh, pero agreguemos un par de unicornios aquí, al cliente le gustará "," ¿Y puede hacer una oportunidad para llamar a un amigo en esta región haciendo clic en una región en el mapa? Será una bomba, proceda "," Necesitamos agregar una leyenda "," Ahora la leyenda necesita ser eliminada, y las firmas también "," Eliminar firmas era superfluo, devuélvalo ". Y todo esto es "gratis sin registro y SMS". Y luego, al calcular los costos reales, resulta que tomó demasiado desarrollarlo con un número tan pequeño de tareas (después de todo, las "solicitudes" en Jira generalmente no están registradas, porque no todos los desarrolladores pueden rechazar al jefe o enviarlo a registrar su "solicitud" ", Y esto se puede entender). La introducción de la regla para nombrar sucursales individuales con código Jira y la imposibilidad de fusionar sucursales en maestro sin vincular a Jira elimina la presencia de trabajo no registrado y los conflictos que pueden surgir si el desarrollador "comienza a descargar los derechos", lo que requiere que complete la "solicitud" como una tarea en Jira, y también le permite tener una idea clara de cuánto trabajo se realizó realmente (las tareas en Jira se confirman mediante el código asociado con ellas, el código escrito mediante la comunicación con la tarea registrada).
3. La conexión de Gitflow con Jira en términos de actualización de estados de tareas ayuda a evitar una situación en la que varias personas están haciendo la misma tarea. En el caso de actualizar los estados de acuerdo con su etapa de Gitflow, todos verán que tales y tales tareas ya están en progreso o en revisión, respectivamente, para ellos ya hay ramas de características en las que se escribe el código, y no es necesario que las tome. También es claramente visible quién hace qué y qué funciona puede afectarse entre sí, con quién deben ponerse en contacto y acordar una implementación en particular con mayor frecuencia, de modo que cuando la fusión no tenga que resolver los conflictos de código durante un tiempo largo y doloroso.
4. Dado que estamos desarrollando una plataforma para crear aplicaciones, vale la pena considerar que los productos terminados de alguien dependerán de nuestra política de soportar versiones antiguas de la plataforma e introducir nuevas. Es posible que algunos de los usuarios de la plataforma por alguna razón usen la última versión de la plataforma y encuentren un error relacionado con la plataforma. Si eliminamos las ramas de lanzamiento, no podremos ayudar a nuestros usuarios en tal situación, especialmente si las funciones que utilizan en su versión se eliminan o modifican en la implementación de la nueva plataforma. En consecuencia, guardar ramas de lanzamiento le permite brindar soporte a los usuarios que no trabajan con la última versión de la plataforma.

¿Qué hay de Agile?

Como probablemente ya haya notado, comenzamos a abordar lentamente los principios de desarrollo ágil de scrum, comenzando por dividir las tareas en sprints para micro objetivos.



A continuación se presentaron Planning Poker, Story Points, análisis de velocidad del equipo, retrospectiva.
La participación en Planning Poker y la asignación de Story Points a las tareas le permite al equipo tener una visión más integral del proyecto, la estructura de su arquitectura, lo que generalmente buscamos y cuál debería ser el resultado. Las personas tienen la oportunidad de pensar sistémicamente, y no solo en el marco de sus tareas. Esto afecta favorablemente tanto su desarrollo como profesionales como el proyecto mismo:

• Se ofrecen nuevas funciones útiles, ya que queda más claro para los desarrolladores qué y dónde se puede mejorar en general;
• más a menudo se encuentran errores y fallas que podrían ser claramente visibles solo en el momento de la operación de la plataforma.

Debido a la disponibilidad de datos sobre el número de tareas completadas en el sprint y los Story Points correspondientes, es posible analizar la velocidad del equipo de desarrollo para llevar a cabo estimaciones de planificación y cronometraje más competentes en el futuro.

Es cierto que hay algo de disgusto en el marco de nuestro proyecto a este respecto: la composición del equipo a menudo cambia, porque algunos desarrolladores son retirados periódicamente para proyectos urgentes, reemplazándolos por otros libres de tareas. Debido a esto, la estimación de velocidad se restablece cada vez. Es casi imposible contar en tales condiciones. La única forma en que se les ocurrió es recopilar datos sobre cada composición para 3-4 sprints, y luego tratar de identificar el valor promedio.

"Y vamos rápido" o 3 aplicaciones de demostración completas por un mes

Por supuesto, nadie ha cancelado el desarrollo de aplicaciones. Especialmente si son necesarios para alcanzar los objetivos globales de la empresa. Especialmente si se necesita con mucha urgencia. Y recientemente, la necesidad de una implementación rápida de aplicaciones de demostración para espectáculos ha aumentado significativamente.

Por supuesto, después de haber trabajado en un nuevo paradigma, no quería volver a las viejas conversaciones. Luego decidimos usar partes del nuevo módulo de visualización (como un sistema integrado, aún no estaba completamente preparado para esas tareas), tomando los principios de su desarrollo como guía.
Como todavía no todos los desarrolladores estaban en el tema del flujo de trabajo, y la adaptación de los chicos al nuevo dispositivo de desarrollo era un gran riesgo en términos del momento de nuestras demostraciones "ardientes", tratamos de encontrar un cierto "punto medio" entre el pasado y, con suerte, el futuro. Como resultado, esto es lo que sucedió con el uso parcial de los principios del nuevo módulo de visualización en demos:

1. Pequeños equipos. 2-3 desarrolladores, diseñador, probador y gerente.
2. Desarrollo paralelo (anteriormente se crearon controles primero, luego plantillas con el aspecto y la lógica de la aplicación).
3. Usando tareas como Story in Jira. No había especificaciones claras y conocimientos tradicionales, por lo que recopilé toda la información disponible sobre el comportamiento esperado y la apariencia de la aplicación y la puse todo en Story. Luego fueron probados en ellos, lo que causó una reacción positiva entre los evaluadores, porque toda la información se recopiló en un solo lugar, pero al mismo tiempo se dividió en partes funcionales, lo que facilitó la verificación. Y el equipo en su conjunto no tuvo que leer un montón de texto oficial para comprender correctamente y completar la tarea. Además, a diferencia de los documentos de Word con especificaciones, Story se actualizó más rápido, las personas recibieron rápidamente descripciones con nuevos refinamientos y, en consecuencia, comenzaron a implementarlas más rápido.
4. Gitflow con desarrollo y ramas maestras, pero sin características:

• todo el desarrollo se llevó a cabo en la rama de desarrollo, pero para excluir la presencia de tareas no registradas, cada confirmación debe haber sido marcada con el código de tarea de Jira, en el que se realizó;
• cuando se resolvieron todas las tareas planificadas para el lanzamiento, se estaba armando una nueva compilación: un líder del equipo realizó una revisión de la rama de desarrollo y, si todo estaba bien allí, los cambios se fusionaron en maestro con la asignación de una etiqueta con el número de compilación. Si se revelaron errores graves e irregularidades durante la revisión, el código se envió para revisiones y solo después de que se ingresaron y se volvieron a verificar pasó al maestro.
• las compilaciones se numeraron con dos dígitos, por ejemplo, 0.1 - este es siempre el número de la primera compilación de prueba, donde 0 - significa que pertenece a la versión de producción, 1 - número de compilación. Y así, en el número de cada próxima compilación de prueba, el último dígito aumentó, hasta que el probador y el gerente concluyen que la compilación está lista para la producción. En consecuencia, si esta fue la cuarta versión de prueba (0.4), se convirtió en la primera versión de producción (1.0) y la etiqueta correspondiente se colocó en la rama maestra. Si se detectan defectos en la producción, y la compilación de producción se envió para su edición, el segundo dígito también aumenta al numerar todas las compilaciones posteriores (1.1, 1.2, etc.).

Por lo tanto, en el transcurso de un mes, implementamos 3 aplicaciones de demostración completas, que recibimos críticas positivas y que siguen siendo útiles. Anteriormente, no podíamos implementar tal funcionalidad tan rápido y con tanta gente en el equipo.

En mi humilde opinion

¿Qué pienso personalmente sobre esto?

• Que la organización de los procesos realmente afecta el resultado y que escuchar el mundo de las prácticas de desarrollo, inventado por los propios desarrolladores y orientado a ellos, no es solo "elegante, moderno, juvenil", sino necesario (después de pasar las demostraciones, por primera vez en varios años de práctica, continuamos haciendo el resto) proyectos, y no se sentó hasta la noche otras 2 semanas después del parto, sudando la cara del montón descubierto por defectos vergonzosos del cliente).
• El nivel de caos, malentendidos y estrés en proyectos con un flujo de trabajo claro es menor (las personas están mejor equipadas con información relevante, saben dónde obtenerla si es necesario).
• El uso adecuado de las herramientas de gestión de proyectos afecta el desarrollo de los proyectos mismos y de sus participantes (debido a la optimización del desarrollo en Gitlab, Jira, la introducción de los principios de scrum ágil, se hizo posible intercambiar experiencias en un equipo, bombear habilidades en un equipo, más a menudo el conocimiento y la experiencia de los líderes de equipos junior comenzaron a transferirse y desarrolladores medios).

Aqui esta el secreto

A pesar de las conclusiones anteriores, y algo más se hizo obvio para mí:

- No todos están listos para lo que sueñan.

A veces, cuando observamos algo desde un lado, nos parece que es algo bueno, útil, necesario para el éxito, correcto y de referencia. Pero vale la pena hacer realidad el sueño, tal como lo entendemos: "Esto no es lo que imaginé". Entonces, en el trabajo: parece que ahora te dan las condiciones en las que trabajan las "compañías normales" y florecerás. Pero por desgracia. Y sucede que usted, sin ahorrar energía, trata de dar a las personas algo con lo que soñaron como garantía de éxito, pero no ocurre un milagro: el trabajo aún no se realiza en alta calidad, y comprende que puede haber aceptado lo típico de alguien palabras de apoyo para una conversación en la cocina para aspiraciones y sueños reales.

Entonces, en el proceso de introducción de nuevas reglas y principios, nos enfrentamos no solo con comentarios y resultados positivos, sino también con una percepción negativa de lo que estaba sucediendo. Para algunos, trabajar con Jira y Gitlab parecía una gran molestia, y cambiar esta percepción fue extremadamente difícil hasta que la gente se encontró con una situación problemática que se produjo debido a ignorar el flujo de trabajo generalmente aceptado. Algunas tareas todavía se llevaron a cabo descuidadamente, las descripciones en la historia y las declaraciones de problemas no se tuvieron en cuenta ni se percibieron como "solicitudes personales" y no se realizaron, a pesar de registrarse con Jira con una declaración clara.En general, las compilaciones con implementación de configuración inadecuada o de baja calidad aún salieron a la luz, y algunos errores se reabrieron de compilación a compilación. Aunque el resultado final fue positivo en todas las demostraciones, todavía pensaba en el hecho de que con los responsables del trabajo, que se preocupan por dar el resultado más alto posible, logramos no solo implementar la funcionalidad necesaria, sino también introducir nuevas características, optimizar la aplicación y "Añadir ryushechek". Y con equipos en los que alguien podía permitirse ser demasiado vago o estar menos interesado en lograr el resultado de la más alta calidad, implementamos solo la funcionalidad básica y un par de características pequeñas a pedido adicional del cliente después de la entrega.

Y luego, tal vez, mi conclusión más importante vino a mí:

- No es un proceso, no es tecnología: las verdaderas claves del éxito, sino aquellos que crean, crean, encarnan la idea en realidad: las personas y su actitud hacia su trabajo. Un músico que pone su alma en su trabajo afectará a la audiencia, tocando incluso el instrumento más barato e incómodo. Y dale Stradivari: volverá loco al público. Y hay quienes incluso Stradivarius, al menos, proporcionan el último desarrollo de los principales fabricantes de herramientas: todo parecerá sin importancia.





Puede proporcionar a las personas condiciones cómodas y las mejores tecnologías, pero al final obtienen un resultado insatisfactorio de sus actividades, porque "y así sigue". Y es posible, si no hay las tecnologías más exitosas y, a veces, incluso que obstaculizan la implementación competente, puede obtener un resultado decente, porque aquellos que lo lograron no pueden permitirse el lujo de entregar el trabajo inacabado o mal hecho. Y es muy importante discernir, apoyar a dichos miembros del equipo, para poder escucharlos y crear condiciones favorables para sus actividades.

La tecnología y la organización de los procesos realmente tienen un impacto en el resultado y son muy importantes, pero la clave principal del éxito está en personas talentosas, responsables y orientadas al desarrollo.