Soy un desarrollador de nivel medio en una pequeña empresa de unas 15 personas y estoy (apuntando a) liderar un equipo de 3. Me preocupa que mi equipo sufra una desinversión progresiva en el proyecto y la empresa en general, por razones comprensibles. Nuestra empresa no logra crear un entorno amigable para los desarrolladores, en parte debido a problemas de recursos humanos, pero en mi opinión, principalmente debido a problemas de gestión de proyectos. Para ser justos, me quedo porque me gustan los desafíos difíciles cuando se trata de arreglar lo que está roto. Recientemente, también ha habido algunos cambios en la mentalidad del nivel C que me hacen sentir optimista acerca de sugerir un cambio.
Hablando aquí solo de nuestro equipo de 3, tenemos la responsabilidad de mantener una base de código de poco más de 150 000 líneas de código, lo que representa básicamente el backend de un solo producto con subservicios. Como ejemplo de nuestra deuda técnica, más de la mitad de este código está escrito en una versión de idioma obsoleta (Python 2.7) y las tareas para migrar a versiones más nuevas se han planificado durante más de un año y se han extendido a lo largo de 6 meses; todavía no hemos logrado impulsarlo con éxito. Nuestro último sprint estuvo medio lleno de correcciones de errores, lo cual no es inusual. Nuestro código falla con frecuencia y muchos de estos bloqueos ni siquiera llegan a la acumulación. Introduje las pruebas unitarias, pero nuestra cobertura es baja y no mejora. Tenemos revisiones sistemáticas, pero no están encontrando defectos de manera eficiente. Nos vemos empujados a lanzar temprano y con frecuencia, pero puede requerir sincronización con otros equipos para lanzar en sincronía y eso por sí solo ha causado muchos problemas y discusiones. La prueba lleva varios minutos y nuestro bot de integración continua responde en 2 horas, con resultados que a veces están sujetos a interpretación.
Usamos la terminología de Scrum, aunque no implementamos Scrum por completo. Tenemos los rituales, pero se toman muchas libertades con la organización del trabajo, desde fallas urgentes que aparecen en el sprint, tareas especificadas a mitad del sprint, sin Scrum master y más. Los desarrolladores informaron que el CTO les impuso preferencias técnicas a pesar de sus objeciones de que era óptimo.
El líder anterior solicitó un intercambio de equipo, alguien que trabaja en una rama de nuestro equipo está de baja por enfermedad (y sé que esto está relacionado con el trabajo), alguien se fue antes y alguien planea irse en enero. Todo esto ocurrió solo en nuestro equipo, durante un período de 2 años.
Hay explicaciones contextuales a este escenario catastrófico, en la historia de la empresa, en la especificidad de nuestro producto, en la falta de experiencia de nuestros directivos a la hora de gestionar proyectos de software, y en la desinversión y despecho de los propios desarrolladores; pero estoy más interesado en las soluciones que en el análisis, siguiendo el eje de 1. retención de desarrolladores y 2. desarrollo de valor de salida:
Si las personas que hacen que los desarrolladores se vayan o tengan un rendimiento inferior no están bajo su control y no lo escuchan, no puede hacer mucho. Instar a los desarrolladores a permanecer en contra de sus propios intereses no funcionará.
No se puede arreglar la mala gestión desde abajo.
Tal como está la pregunta, es muy amplia, ya que cubre varios aspectos diferentes, como " cómo manejar la deuda tecnológica ", " cómo manejar los errores a mitad de sprint y también aquí ", " cómo motivar a los desarrolladores en ese entorno ".
No hay una bala mágica . Como recuerda Cornelius Fichtner en su PrepCast , debemos comer un Elefante bocado a bocado.
Hay tantos elementos relacionados con la motivación (su elemento n. ° 1) que hay una etiqueta específica para ello y es realmente difícil identificar algo. De cualquier manera, vale la pena aprender más sobre cómo funciona la motivación intrínseca .
Para la entrega de valor (su elemento n. ° 2), deberá utilizar un lenguaje común entre el nivel C y el equipo de desarrollo. Las 4 métricas clave ofrecen un conjunto simple pero poderoso de aspectos para medir, comprender dónde se encuentra y hacia dónde quiere ir.
Además, en un entorno tan complejo (y potencialmente frustrante), sugeriría dedicar un poco de atención no solo a observar dónde se encuentra ahora , sino también a la tendencia a lo largo del tiempo . Es posible que tenga una cobertura de prueba del 5% hoy y esto podría ser realmente frustrante... pero debe pensar que el mes pasado tuvo un 2%. La tendencia (y lo que es más importante, la tendencia positiva) es un verdadero motivador. Cuando hable con el equipo de desarrollo, es posible que desee mostrar la tendencia alcista en lugar de los números sin procesar.
De cualquier manera, establecer expectativas es clave: todos deben ser conscientes de que el equipo deberá dar un paso atrás (es decir, una entrega de negocios reducida o nula durante algún tiempo) para poder avanzar en el futuro.
¿Cuáles son buenas medidas de dónde estamos y cuánto mejoramos?
Desde la perspectiva de Kanban, sugeriría tiempo de entrega, y desde la perspectiva de Scrum, sugeriría velocidad/rendimiento. El tiempo de entrega es la cantidad de tiempo que lleva obtener un trabajo desde que "acaba de comenzar a trabajar en él" hasta que "está listo para funcionar". La velocidad es la cantidad de trabajo que puede realizar en un período de tiempo determinado. Realmente, estas son solo dos formas separadas de visualizar la misma cosa. Sin embargo, podría ser útil tener medidas separadas para ambos, según el gusto de su gerencia. YMMV.
¿Cuáles son buenos indicadores en términos de gestión de proyectos para una situación similar? No estoy buscando una solución de estante como Scrum, sino más bien pautas y pequeños cambios incrementales en la organización que podrían conducir a una mejora.
Desafío del marco: debería estar buscando una solución de estantería... por ahora.
Echa un vistazo a la mentalidad de Shu Ha Ri . El primer paso, Shu, es seguir una guía/proceso/entrenador con precisión . No necesita preocuparse por comprender el por qué en esta etapa; solo debe preocuparse por el qué , el quién , el cuándo y el cómo .
La segunda etapa, Ja, entra solo después de que hayas dominado el seguir tu proceso según el libro . Una vez que haya dominado por completo la mecánica del proceso, comience a preguntar 'por qué' y comience a probar otros procesos relacionados (por ejemplo, ScrumBan), comience a ajustar las partes variables de su proceso definido (por ejemplo, la duración del Sprint).
Luego, finalmente, la etapa Ri es cuando has dominado el qué, quién, cuándo, cómo y por qué. En este punto, puede comenzar a realizar cualquier tipo de cambio que considere necesario, según su comprensión.
Intentar saltar directamente a la etapa Ri es la forma de conseguirlo .
Dicho esto, si es necesario, siéntase libre de comenzar con cambios incrementales en lugar de cambios al por mayor; solo asegúrese de que esos cambios incrementales vayan todos hacia el proceso preciso de manual, porque todavía se encuentra en la etapa Shu, el todo el tiempo. No se preocupe por tratar de mejorar Scrum hasta que primero haya probado Scrum por completo. Ya sea que eso tome una reunión con la gerencia con un mes para probarlo tal como está, o cinco años de cambios incrementales.
Bueno, como un experto en programación experimentado , agregaría que es muy posible que aún no aprecie la verdadera naturaleza de los desafíos técnicos que sus equipos podrían enfrentar.
La versión de su idioma actual podría ser más o menos incompatible (!) con la "versión del mismo idioma superficial" en el que se escribió originalmente este sistema. Sí, "la fundación también se mueve".
Lo que empeora la situación es el hecho de que cada aplicación depende intrínsecamente de "bibliotecas de terceros" que su equipo no desarrolló, pero que también están obligadas a readaptarse a un objetivo en constante movimiento.
Hace aproximadamente un año y medio, tuve que liderar un equipo a través de la desagradable experiencia de rediseñar un sistema muy antiguo (sic...) basado en "OsCommerce" de PHP-5 a PHP-7, literalmente para dar la empresa tiempo suficiente para desmantelarlo. Terminamos cambiando alrededor del 40% del código fuente total en ese sistema... solo para mantenerlo exactamente donde estaba. (Y tuvimos que rediseñar gran parte de la lógica para eludir lo que algún diseñador de lenguaje en algún lugar había decidido que ahora estaba "obsoleto" o completamente eliminado del lenguaje.
La arquitectura del sistema Python es más indulgente, pero los principios feos se mantienen: "su sistema no es el único en juego".
Como estoy seguro de que sabe, ¡se han escrito libros enteros sobre estos temas! He estado leyendo y presentando sobre la literatura de investigación sobre el trabajo en equipo durante años, y creo que proporciona respuestas claras para usted: empodere al equipo para que funcione por sí mismo y concéntrese más en los principios (como el Manifiesto Ágil) que en el proceso. Se ha demostrado empíricamente que estos mejoran la satisfacción laboral, reducen la intención de irse y mejoran el desempeño medible a largo plazo. Mi enfoque está aquí (gratis y de código abierto): Agile autodirigido .
Sin embargo, dado que parece que ha estado ejecutando Scrum durante un tiempo, los primeros pasos podrían ser dejar que el equipo ajuste el proceso para satisfacer mejor sus necesidades. En cada Retro, pregunte al equipo si desea cambiar alguna parte de cómo planifica, realiza un seguimiento y realiza su trabajo. Luego deje que haga los cambios uno a la vez. En el próximo Retro, discuta cómo fue y cómo afectó el rendimiento (bueno y/o malo). Luego mantenga, revise o rescinda ese cambio y decida sobre el siguiente. Aunque esta sección de mi sitio utiliza un lenguaje específico para mi enfoque de la agilidad, los principios se basan en la investigación psicológica y, por lo tanto, deberían aplicarse a cualquier otro enfoque: Personalizar FuSca .
No puedes, porque tu empresa está en una espiral de muerte.
Tiene un proceso de desarrollo fundamentalmente roto y una base de código heredada que debe desecharse y reescribirse desde cero. Esto requerirá mucho tiempo, tiempo que no generará ingresos, y en una empresa tan pequeña como la suya, pasar tanto tiempo sin ingresos hará que la empresa cierre. No importa lo que la gerencia pueda decir para mantenerlo contento, no hay posibilidad de que se embarquen en un curso de acción que directamente mate a la empresa.
Ergo, nunca se gastará el tiempo necesario y la situación seguirá deteriorándose, hasta que llegue a un punto en el que todos los desarrolladores senior que entienden la plataforma se hayan ido por frustración, y los únicos que queden sean los junior que no tienen la experiencia para comprender el lío en el que se encuentran. Y es probable que los jóvenes no creen un buen código, especialmente sin los adultos mayores que los guíen, por lo que el problema solo crecerá.
Lo sentimos, pero esto simplemente no se puede arreglar sin importar cuántas pruebas agregue. Siga el ejemplo de los desarrolladores que ya se dieron cuenta de esto y se fueron: elimine sus pérdidas y encuentre un lugar más sensato para trabajar. Este no es un desafío que puedas superar.
Sarov
david espina