¿Qué hago cuando el líder de mi equipo está rompiendo el esquema de mi base de datos con una versión próxima?

El líder de mi equipo tiene la terrible costumbre de modificar el esquema de la base de datos y hacer cambios que causarían una rotura severa en la base del código (sin consultarme realmente sobre cómo los cambios afectarían la base del código).

Normalmente, viviría con eso, pero tenemos una fecha límite en 2 semanas y esto ha estado sucediendo desde que comencé hace 1 mes y medio. Fui contratado para acelerar el desarrollo del proyecto.

Debido a la fecha límite, ya estoy dedicando más de 60 horas a la semana, y realmente no me queda energía para lidiar con esto (ya lo he intentado de alguna manera). Somos solo un equipo de 2 personas, y además de cambiar la base de datos diariamente, no ha contribuido mucho en el sentido del desarrollo real (codificación).

Actualmente, siento que estoy haciendo todo el trabajo, además de tener que "arreglar" lo que rompe con sus cambios.

¿Cómo se trata esto? Ya he hablado con nuestro gerente sobre su falta de esfuerzo en el departamento de desarrollo. Él ha estado allí 6 meses más que yo, pero he escrito el 95% del código cuando excluye la quinta monstruosidad de la base de datos de forma normal que 'contribuyó'.

¿Alguna sugerencia?

Post mortem:

El viernes tuvimos una discusión con el gerente, y di a conocer mis preocupaciones. Esto condujo a un poco de confrontación, pero en general sentí que el gerente me estaba apoyando. Entonces, al menos tenemos nuestra congelación de datos ahora, veamos cómo va desde aquí.

"La fecha límite es en dos semanas; necesitamos congelar el esquema si vamos a alcanzarlo".

Hablando con el gerente Y el desarrollador en la misma reunión:

"Los cambios en la base de datos y el código deben aparecer simultáneamente. Si cambia la base de datos, también debe cambiar y probar la base del código. De lo contrario, está enviando confirmaciones rotas, lo cual es inaceptable si cumplimos con la fecha límite. Ya no corregiré el código interrumpido por sus compromisos, simplemente retrocederé los cambios y le dejaré una nota por correo electrónico porque no puedo investigar y solucionar problemas fuera del trabajo que me asignaron y todavía espero cumplir con la fecha límite ".

Mucho más difícil si no tienes un plan de prueba ...

Tendrás que ser más contundente y asegurarte de que pronto (como ayer, anteayer o el mes pasado) te instales en un esquema y sigas adelante. No hay una manera sensata de continuar desarrollando una aplicación con una base de datos que sea un objetivo móvil.

Debe confrontarlo y explicarle cómo sus cambios están afectando la base del código y, por lo tanto, las líneas de tiempo del proyecto. Convéncele de que necesita considerar el impacto de sus cambios antes de efectuarlos. También haga que acepte en presencia de su gerente el hecho de que será responsable de cualquier demora que induzca por este comportamiento.

Si el líder del equipo no es una persona razonable (y él / ella no suena razonable a partir de su descripción de su comportamiento), hable con su gerente y explíquele que no cumplirá con la fecha límite con la forma en que van las cosas. Pídale que tome una posición y asegúrese de que el líder de su equipo esté al tanto de esto mediante una reunión donde el gerente establezca las expectativas.

También debe impulsar su caso con respecto a la falta de contribución de su líder de equipo al desarrollo. Ambos problemas deben resolverse para que el proyecto sea un éxito.

Tendrás que imponer cierta moderación a tu equipo, pero puede ser complicado jugar en tu posición en él.

Una forma útil de abordar esto podría ser adoptar un control de cambio documentado más riguroso. Puede jugar esto insistiendo en que en este momento los cambios ad-hoc están poniendo en riesgo su capacidad de administrar las actualizaciones del sistema de una manera que no tenga consecuencias imprevistas y que amenacen la fecha límite (lo cual es cierto). Por lo tanto, insista en que todos los cambios deben venir con documentación que muestre el cambio propuesto y sus efectos en todos los demás códigos y estructuras. Te sorprenderá cuánto reducirá el volumen de cambios que se producen :-)

¿Has tenido una retrospectiva con el equipo? Si no, sostenga uno. Cuando lo haga, identifique los cambios no planificados (mucking con) en la base de datos como un problema. Especifique el costo para usted y para otros en relación con el riesgo y la calidad de la vida laboral. Trabajar continuamente 60 horas por semana no es sostenible. Si no puede mantener su ritmo de desarrollo, no lo está haciendo ágilmente.

Además, ¿está haciendo TDD (desarrollo basado en pruebas) o prueba funcional / regresiva automatizada? Si es así, los cambios en la base de datos deberían resultar en pruebas rotas. Esto debería ayudar a abordar el impacto e identificar el código que debe actualizarse.

En este caso, el líder de su equipo no es " demasiado ágil ", su líder de equipo es un " vaquero ágil ". Mantenga una retrospectiva, identifique lo que salió mal. Priorizarlo alto, luego abordarlo durante la próxima iteración. ¡Eso debería ser una cuerda para tu ágil vaquero!

¿No hubo un problema con usted hace aproximadamente un año? ' El líder de mi equipo dice A.Property = A.Property; está bien '. Parece que la pregunta fue prohibida porque no la veo en mi historial de comentarios. De todos modos, el punto es:

Si siente que todos los líderes de su equipo lo están arruinando con apenas la mitad de su experiencia, probablemente encuentre un trabajo sin uno . Sugeriría intentarlo y convertirse en un líder como otra opción, si aún fuera capaz de hacerlo, ya se le había ofrecido hacerlo.