¿Qué hacer con un equipo de desarrollo que se está muriendo de hambre? [cerrado]

Es una mierda estar en la ruta crítica como desarrollador normal, especialmente si llegas tarde. Cuando eres el desarrollador senior, que el equipo busca liderazgo, es aún peor.

Cuando el trabajo para la mayoría del equipo se detiene esperando alguna pieza crítica, ¿qué debe hacer el resto del equipo? Tenemos acceso limitado a la pieza crítica, por lo que otros simplemente estarán esperando sin importar lo que hagamos. Cuando los demás buscan consejos sobre qué hacer, ¿cuál es una buena respuesta?

Mejore las pruebas unitarias, las pruebas funcionales, la documentación, las herramientas, etc. Hay muchas cosas que se pueden hacer en el tiempo de inactividad mientras se espera que la ruta crítica se ponga al día.

Si bien me gusta la respuesta sobre cómo mejorar las pruebas, la documentación, etc., y es buena, también puede consultarla:

• Al ayudar al componente de ruta crítica, ¿iría más rápido con la programación de equipo / amigo?
• Reestructurar el componente crítico en varios subcomponentes en los que todos pueden trabajar.
• Simula el componente crítico con algo, posiblemente tosco, que básicamente hace el mismo trabajo pero posiblemente no lo suficientemente rápido para la producción.
• Establezca una API para el componente crítico, corríjalo más o menos en piedra y ayude a implementar la funcionalidad básica para ese componente (sujeto a cambios en la implementación pero no a la API).
• Vea si puede tomar versiones tempranas, problemáticas conocidas, del componente crítico para trabajar en el resto del sistema donde la funcionalidad es "lo suficientemente buena por ahora".

También es una buena idea comenzar la fase de "lecciones aprendidas" ahora al registrar que dichos componentes críticos deben iniciarse antes en el proceso de desarrollo, posiblemente antes de que se reúna el resto del equipo.

Necesita un plan de respaldo para su entrega tardía

Si una pieza crítica ya llega tarde, no hay garantía de que no se deslice aún más. ¿Entonces que? ¿Solo esperas por siempre? Ese no es el tipo de respuesta que quiere decirle a la alta dirección.

Construye un simulador

Una forma de gestionar el riesgo es comenzar a trabajar en un simulador (arnés, cuña, trozo, como quiera llamarlo) para tomar el lugar de la pieza crítica que falta.

¿Tiene una interfaz definida? Impleméntalo.

¿Tiene documentación detallada? Imitarlo lo mejor que puedas.

¿Es solo idea de alguien? Vea si puede obtener un prototipo.

Luego, cuando vuelven a pasar el horario ...

De esa forma, cuando vuelven a pasar el horario, tienes un as en el bolsillo trasero para cerrar la brecha. No solo se desbloqueará su equipo (pueden integrarse con el simulador), sino que obtendrá un valioso activo de software.

Si pierden el horario aún más, use el tiempo para escribir pruebas de integración automatizadas (en su simulador, por ahora). De esa manera, cuando entregan lo real, puede ejecutar sus pruebas y detectar cualquier diferencia de comportamiento entre la maqueta y la entrega. Esto te permitirá concentrarte en los puntos que tienes que revisar. Como beneficio adicional, obtendrá rápidamente una idea de cuánto recortaron cuando se les acabó el tiempo.

Si el componente crítico tiene una interfaz conocida y no hay esperanza de hacerlo en poco tiempo, ¿por qué no construir una prueba doble (por ejemplo, un simulacro )?

Esto permitiría al equipo continuar con la codificación, aunque los resultados de la prueba serían un poco menos significativos.

Además del obvio "hacer todas esas cosas que no ha podido hacer hasta ahora", parece que usted y su equipo carecen de la tranquilidad de hacer algo no relacionado con el proyecto tardío. Lo cual es comprensible pero no útil.

Entonces, el verdadero problema puede ser estar relajado al respecto. No estoy diciendo indiferente. Sé consciente de tu responsabilidad, de lo que puedes hacer para ayudar y si eso te deja con tiempo libre, disfrútalo. No puede ni tiene que estar alerta todo el tiempo. Si eres un líder, diría que este debería ser tu mensaje. Transferir tu nerviosismo al equipo no hará un equipo más productivo cuando sea importante.

No dice qué metodología está utilizando, lo que hace que sea difícil aconsejar exactamente.

Donde trabajo si hay un bloqueador, la bomba está haciendo todo lo posible para acelerar el desarrollo.

Considere si podría haber un problema más amplio con usted, ya que el plomo toma demasiado. Sí, la gente te buscará liderazgo técnico, pero eso no significa que algunos de los miembros de tu equipo más capaces no puedan compartir la carga de trabajo si reciben mentores.

Además de esto, ¿hay algún otro trabajo no crítico en el que puedan avanzar? Además, ¿hay algún trabajo que hayan completado que pueda pulirse aún más (refactorizado, eliminar la deuda técnica, documentación, agregar pruebas, etc.).

Si realmente no hay nada, deles algo: pase por registros, construcciones, documentos, planes de prueba, diseños, diagramas, escriba agendas, organice reuniones, celebre sesiones de bolsa marrón, comparta conocimientos, etc. Siempre hay algo que hacer. Si las personas están dispuestas a sentarse sin hacer nada en la moneda de la compañía, esto se debería escalar, ya que claramente no son jugadores de equipo.