¿Cómo dejar de atrapar los huevos a toda prisa, al mismo tiempo que se caen los plazos? ¿Qué cadena de herramientas elegir para destruir varias tareas a la vez? Revelaremos todo esto en nuestro artículo.

Tratando de atrapar todos los huevos

En aquellos días en que nuestra compañía recién estaba emergiendo en el útero de vidrio de la oficina bañado por el sol, y el equipo tenía solo tres personas (un gerente y dos desarrolladores), entusiastas y ricas en café, no teníamos absolutamente ninguna metodología de gestión de proyectos y actuamos de acuerdo. abordar el trabajo sobre el principio de "una persona - un proyecto". Al mismo tiempo, ni siquiera se trataba del hecho de que los desarrolladores, que interactuaban dentro de la misma tarea, mantenían piezas de código separadas entre sí, y todo el panorama del entorno de desarrollo dependía de la máquina del desarrollador. Como repositorio y sistema de control de versiones, usamos SVN , que en ese momento era más como una carpeta con archivadores zip. A pesar de que SVN es uno de los sistemas de control de versiones más grandes y tiene una comunidad adecuada, su funcionalidad solo nos convenía en términos de preservar el código; de lo contrario, todo era un poco pobre: ​​no había una versión local y la capacidad de fusionar el código. Por lo tanto, comenzamos a buscar algo más adecuado para nuestros apetitos: comenzó el desarrollo del proceso de trabajo. Lo primero que debía abordarse era la planificación y el establecimiento de tareas, así como su distribución entre sí, para alejarse de la monoproyectividad al desarrollo conjunto y el mantenimiento de los plazos. En ese momento, el único tipo de planificación era reuniones con cuadernos. Con este enfoque, antes de la eficiencia y la eficiencia era como la luna en el cosaco, alguien logró notar todo, alguien olvidó u olvidó. Como resultado, la gente abandonó la reunión sin comprender claramente qué y cómo hacer, con un montón de información en sus cabezas y con un par de garabatos en un cuaderno.

Seleccionamos una cadena de herramientas

El primer paso para reducir la entropía del flujo de trabajo fue crear un repositorio normal para trabajar juntos en proyectos y conectar las partes individuales del código. Lanzamos un viejo SVN y creamos GIT en la máquina local de nuestro CEO. Para ver y conectar el código se utilizan utilidades de consola simples. No fue muy conveniente, pero al menos permitió mantener el orden y la transparencia de los cambios en el proyecto.

Todavía tuvimos problemas con la planificación y, como resultado, con los plazos de entrega. Para hacer esto, era necesario encontrar un medio para descomponer las tareas y mostrar el estado de su implementación. Un intento de resolver este problema fue el uso de la aplicación de gestión de proyectos RedMine, a partir de la cual comenzó la evaluación comparativa activa de la cadena de herramientas. La utilidad era adecuada para desarrolladores (capacidades de gestión de proyectos, foros, seguimiento de errores), pero desafortunadamente fue muy difícil para los gerentes. Los desarrolladores tenían que procesar constantemente toda la información (merzhrekvesta, pullrekvesta, etc.) desde el SUV e ingresarla en el programa RedMine , para que los gerentes pudieran seguir el grado de finalización de la tarea. Además de esto, no había suficientes funciones adicionales de gestión de proyectos, por lo que comenzamos a mirar hacia FengOffice .

La herramienta tenía una amplia gama de funcionalidades, lo que hacía posible soñar con el tema de combinar herramientas de comunicación y planificación como un diagrama de Gantt en un solo sistema de trabajo. Sin embargo, con todo el equipo de este producto, los desarrolladores tuvieron que cerrar manualmente las tareas, mientras compilaban estadísticas por su cuenta, ya que no había sincronización automática de las tareas realizadas. Además, la implementación del chat interno se parecía más a una versión anterior similar de ICQ que a un chat corporativo normal, pero para nosotros este momento fue muy importante.

Entendimos que para que todo el mecanismo funcione en armonía, las reuniones simples claramente no son suficientes. Era necesario seleccionar herramientas operativas para establecer comunicaciones cortas que eran necesarias incluso para personas sentadas una al lado de la otra en la misma habitación. Aquí surgen dos puntos: el primero: si lleva a cabo conversaciones breves en el formato habitual, entonces tomarán demasiado tiempo de trabajo, lo que significaría el colapso de todos los plazos y un retraso considerable en el horario, y el segundo, si realiza al menos interacciones cortas, esto conducirá a estrecha comunicación entre los miembros del equipo, inconsistencia de sus acciones, duplicación de código y otros problemas. Por lo tanto, llegamos a una solución simple: transferir micro reuniones a un chat de equipo, lo que le permite comunicarse constantemente sin una fuerte distracción del flujo de trabajo, coordinar las acciones de los desarrolladores y evitar la ejecución repetida de las mismas tareas, así como las disputas sobre quién realizó mejor la tarea. La solución puede parecer obvia y trivial, pero la cuestión no está en los medios de interacción, sino en el enfoque y la calidad del uso de la herramienta. La pregunta era cómo convertir el chat de un lugar para inundaciones y quemaduras en un reemplazo parcial para reuniones y conversaciones personales.

Mientras tanto, el GIT habitual no era suficiente, había una gran falta de una interfaz web. Teníamos dos opciones en el menú: un repositorio privado en GitHub y un repositorio en GitLab. GitLab es gratis, y se lo llevaron. También tiene una comunidad agradable y amigable. Además, GitLab ya tenía un sistema de programación de tareas incorporado y proporcionaba una interfaz conveniente para merzhrekvest. Si trabajó en equipo, entonces probablemente sepa lo importante que es obtener rápidamente una merzhrekvest aprobada. Finalmente, enterramos a FengOffice y nos instalamos en GitLab. Además, en ese momento ya usábamos a Slack como un chat de equipo, y dado el hecho de que GitLab planeó la integración mutua con Slack, y todo esto también era gratis, la elección para nosotros se hizo más obvia que nunca.

Los libros no mienten

Entonces llegó el momento en que fue necesario elegir la metodología más adecuada para nuestra gestión flexible de proyectos. Nos decidimos por dos de los enfoques más desarrollados y populares: Kanban y Scrum. La iniciativa vino enteramente de nuestro CEO, Ilya Bykoni, quien, con el fuego prometedor en sus ojos, habló con el equipo sobre los próximos cambios. Pero para su gran sorpresa, el equipo, al principio, conoció las innovaciones, ya que los espartanos se encontraron con Xerxes, con feroz terquedad de las copias conservadoras. ¿Qué puede hacer, ilusiones, ilusiones, porque en los libros advirtieron ... Un hecho interesante se notó de inmediato que una actitud negativa hacia los nuevos enfoques no se correlaciona con la adecuación y la capacidad de las personas para trabajar. Incluso los jóvenes junes, que se suponía que iban a recoger todo esto fácilmente, se resistieron, argumentando que: "deberían programar mejor durante 15 minutos que pasar este tiempo al día siguiente", "¿por qué necesitan planificación si los plazos son de todos modos? no se ejecutan o se ejecutan, sino con desviaciones "," por qué el desarrollador de la interfaz debería escuchar sobre el back-end ", etc. El hecho es que la metodología de enfoque ágil implica un estilo de trabajo en el que es imposible sentarse sobre los hombros de un desarrollador fuerte y llegar al proyecto sobre sus habilidades, ya que muchas personas están acostumbradas a trabajar, por lo que tales cambios se vuelven para ellos doloroso


Cuando comenzamos a introducir Agile en el trabajo, sentimos plenamente el valor de las comunicaciones cortas y de alta calidad. A menudo sucede que cuando las tareas similares provienen de la entrada del departamento de RnD de varias fuentes, los gerentes de proyecto no pueden detectar duplicados. Y aquí, las interacciones a corto plazo y las manifestaciones diarias, que protegen completamente contra tales problemas, comienzan a jugar un papel muy importante al identificar un terreno común entre los desarrolladores de diferentes equipos. Hay otro punto interesante: la mayoría de los programadores son introvertidos, es decir, cualquier comunicación es microestrés, especialmente cuando se trata de manifestaciones en equipos grandes, donde una persona tiene que hablar con una amplia audiencia de diversos especialistas. Y muchas personas, por temor a tales molestias, no se dan cuenta de que la alternativa para reuniones tan cortas puede ser aún más desagradable que la diaria. Esto será reemplazado por una comunicación constante durante todo el día, en un intento de llevar el trabajo a un proceso controlado. Para nosotros, concluimos que Agile tiene en cuenta la introversión de los desarrolladores y reduce al mínimo las molestias asociadas con la necesidad de comunicación. Por supuesto, para los jóvenes empleados de la empresa, en cualquier caso, esto será estresante durante algún tiempo hasta que profundice en los detalles de su trabajo y conozca al equipo más de cerca, por lo tanto, cuanto más amigable y eficiente sea la cultura Ágil en la empresa, más rápido terminará el proceso de adaptación.

Un palo duele, muchos palos son mortales

Una de las motivaciones clave de un enfoque flexible es que las personas se acostumbran a minimizar sus fallas y errores. El hecho es que si toma la estructura de gestión vertical estándar, el desarrollador es responsable de sus errores ante el jefe inmediato que castiga y "golpea con un palo en la cabeza" si el empleado fakapit o "acaricia la cabeza" si todo se hace con claridad. Es decir, en la estructura vertical, una persona tiene la opción de rebotar debido a relaciones personales o "galletas sabrosas". En Agile, la interacción del equipo se construye horizontalmente, lo que significa que una persona tiene que informar a todo el equipo en las reuniones diarias. Él estúpidamente no tiene suficiente dinero para tantas galletas. Por lo tanto, debes acostumbrarte al hecho de que tus errores serán revisados ​​por tus colegas, y o estarás en un caballo y te echarán pétalos de rosa por el elogio de tu profesionalismo, o estarás debajo de un caballo ... En cualquier caso, este es un fuerte impulso de las habilidades personales de una persona, y Si la atmósfera en la empresa es lo suficientemente cálida, entonces la persona comienza a abrirse lentamente, haciendo una contribución cada vez mayor al ecosistema de su departamento y a la empresa en general. También experimentamos por experiencia el efecto de filtrado de Agile, más de una vez enfrentado a una situación en la que los desarrolladores objetivamente débiles no pueden soportar el análisis constante de sus errores y, en última instancia, simplemente se fusionan si se dan cuenta de que carecen de motivación interna y fortaleza para para cambiar del estado de bagodel al estado de bogacode.

Para resumir

Debo decir que el proceso de configuración de una máquina Agile resultó ser bastante largo y muy estresante, "no podría haberlo hecho sin violencia"; inicialmente, las personas tenían que ser conducidas prácticamente con un palo a las manifestaciones y los eventos diarios, para que las personas comenzaran de alguna manera a expresar su posición sobre las tareas que estaban resolviendo. Aunque constantemente tenemos que "meternos debajo del capó" y jugar con el "motor", ensuciándonos las manos con aceite combustible, vale la pena cuando el equipo aumenta la velocidad y se apresura hacia adelante, recogiendo el punto de control para el punto de control. No detenemos nuestra evolución ni siquiera por un segundo, siempre estamos en el estado de promotores eternos, estudiamos constantemente y modificamos los modelos existentes de gestión e interacción entre los empleados. Una cosa que entendemos absolutamente a ciencia cierta: donde no hay movimiento ni lucha, no hay vida. Como dicen los monjes zen: "Llegué a la cima, continúa el ascenso ..." ¡Buena suerte a todos en tus ascensiones y deja que todos vayan hacia su cima, pase lo que pase!

PD:

Aquí hay una lista de muestra y el momento de los pasos que seguimos:

1. Planificación de la formación ~ 4 meses
2. Trabaja con comunicaciones cortas ~ 1 mes
3. Busque una cadena de herramientas y un desarrollo de flujo de trabajo adecuados ~ 2 meses
4. Elección de metodología ~ 2 meses
5. Introducción de Scrum al flujo de trabajo ~ 8 meses

Y aquí hay una pequeña selección de nuestro CEO:

1. Comprensión ágil - Andrew Stellman y Jennifer Green
2. "El camino del Scrum-Master" - Zuzan Shokhov
3. "Scrum, un método revolucionario de gestión de proyectos" - Jeff Sutherland
4. "Kanban alternativa a Agile" - David Anderson
5. “A la cabeza de la transformación. Aplicación de los principios de Agile y DevOps en toda la empresa "- Harry Gruver y Tommy Mauser